SDN Architecture for Cable Access Networks Technical Report

Transcription

1 Virtualization and Network Evolution Open Networking SDN Architecture for Cable Access Networks Technical Report RELEASED Notice This Virtualization and Network Evolution technical report is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. You may download, copy, distribute, and reference the documents herein only for the purpose of developing products or services in accordance with such documents, and educational use. Except as granted by CableLabs in a separate written license agreement, no license is granted to modify the documents herein (except via the Engineering Change process), or to use, copy, modify or distribute the documents for any other purpose. This document may contain references to other documents not owned or controlled by CableLabs. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document. To the extent this document contains or refers to documents of third parties, you agree to abide by the terms of any licenses associated with such third party documents, including open source licenses, if any. Cable Television Laboratories, Inc

2 Open Networking DISCLAIMER This document is furnished on an "AS IS" basis and neither CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein. Any use or reliance on the information or opinion in this document is at the risk of the user, and CableLabs and its members shall not be liable for any damage or injury incurred by any person arising out of the completeness, accuracy, or utility of any information or opinion contained in the document. CableLabs reserves the right to revise this document for any reason including, but not limited to, changes in laws, regulations, or standards promulgated by various entities, technology advances, or changes in equipment design, manufacturing techniques, or operating procedures described, or referred to, herein. This document is not to be construed to suggest that any company modify or change any of its products or procedures, nor does this document represent a commitment by CableLabs or any of its members to purchase any product whether or not it meets the characteristics described in the document. Unless granted in a separate written agreement from CableLabs, nothing contained herein shall be construed to confer any license or right to any intellectual property. This document is not to be construed as an endorsement of any product or company or as the adoption or promulgation of any guidelines, standards, or recommendations. 2 CableLabs 06/25/15

3 Document Status Sheet Document Control Number: Document Title: SDN Architecture for Cable Access Networks Technical Report Revision History: V01 - Released 6/25/2015 Date: June 25, 2015 Status: Work in Progress Draft Released Closed Distribution Restrictions: Author Only CL/Member CL/ Member/ Vendor Public Trademarks CableLabs is a registered trademark of Cable Television Laboratories, Inc. Other CableLabs marks are listed at All other marks are the property of their respective owners. 3 CableLabs 06/25/15

4 Open Networking Contents 1 SCOPE Introduction SDN in the Access Network Topics Covered in the Tech Report INFORMATIVE REFERENCES Reference Acquisition TERMS AND DEFINITIONS ABBREVIATIONS AND ACRONYMS SDN AND THE ACCESS NETWORK CCAP High Level Overview of CCAP Benefits of CCAP CCAP Management and Configuration Distributed CCAP Architecture CCAP Management Abstraction (CMA) Network Function Virtualization of CCAP Some General SDN and NFV Concepts and Terms SDN ARCHITECTURE FOR CABLE ACCESS NETWORKS SDN/NFV Integration SDN Controller Northbound and Southbound Interfaces on the SDN Controller CCAP MANAGEMENT ABSTRACTION Need for CCAP Management Abstraction CMA for Distributed CCAP Architectures SELECTED USE CASE WORKFLOWS HSD Bring Your Own Cable Modem L2VPN Third Party ISP Access (TPIA) Lawful Intercept Lawful Intercept Data Lawful Intercept Voice Voice PacketCable PacketCable DSG IPTV DATA MODELS DOCSIS IP HSD Provisioning Packet Classifier YANG Model for DOCSIS Data Model L2VPN Data Model YANG Model for L2VPN TPIA Data Model YANG Model for TPIA Lawful Intercept Data Model CableLabs 06/25/15

5 9.4.1 YANG Model for Lawful Intercept Generic Flow Model (Northbound Data Model) YANG Model for Generic Flow Model OpenDaylight PCMM Plug-in Data Model Traffic Profile Data Model PCMM Traffic Profile Data Model OpenDaylight PCMM Plugin YANG Model NORTHBOUND AND SOUTHBOUND PROTOCOLS PCMM NETCONF XMPP REST (RESTful API) RESTCONF WebSockets Recommendations for Southbound Protocols One Protocol versus Multiple Protocols Static Configuration versus Dynamic Configuration Data Consistency SERVICE FUNCTION CHAINING SFC Architecture Service Chaining Setup through Network Service Header (NSH) SFC Implementation in a DOCSIS Network SFC Initiating from Application SFC Initiating from Home Gateway SFC Initiating from CM SFC Initiating from CCAP/CMTS SFC Initiating from a Proxy Behind CCAP Recommendation DOCSIS 3.1 PROFILE MANAGEMENT APPLICATION Introduction Problem Description Background Problem Statement and Goals High Level Architecture Areas of Focus PMA Use Cases Case 1: New Channel Startup Case 2: Profile Optimization Case 3: Fallback Use Case Push versus Pull Approaches Data Elements and Actions Data/Messaging Scope Messages for the PMA-CMTS Interface PMA Data Backend and Protocols Other PMA Considerations Central Database Multiple Masters Problem Evaluating Profile Changes Policy Definition Data Acquisition Methods Data Volume for Message Exchanges Gaps in the PMA Solution CableLabs 06/25/15

6 Open Networking 13 INTENT-BASED NETWORKING VISION AND ARCHITECTURE Use Cases and Intent-based Order Portals VPN Service Order Scenario Gaming Service Order Scenario Home Security Service Order Scenario Triple Play Service Order Scenario Related Industry Initiatives Group Based Policy Open Networking Foundation (ONF) Common Intent Northbound Interface (NBI) Initiative Network Intent Composition NeMo OpenStack Congress IETF SUPA Conclusions and Recommendations CONTRIBUTION TO OPEN SOURCE CONTROLLERS CONCLUSION APPENDIX I EXAMPLES OF CCAP ABSTRACTIONS APPENDIX II ACKNOWLEDGMENTS List of Figures Figure 1 - SDN Architecture... 9 Figure 2 - Overview of CCAP Figure 3 - SDN Reference Architecture for Cable Access Networks Figure 4 - Internal View of SDN Controller Figure 5 - SDN Reference Architecture and CMA Figure 6 - HSD Workflow Today Figure 7 - HSD Workflow with SDN Figure 8 - L2VPN Workflow Today Figure 9 - L2VPN with SDN Figure 10 - Virtualized Network Topology Figure 11 - TPIA Workflow Today Figure 12 - TPIA with SDN Figure 13 - Slicing Physical Network into Multiple Virtual Networks Figure 14 - TPIA Workflow with SDN, Part Figure 15 - TPIA Workflow with SDN, Part Figure 16 - CBIS Interfaces Figure 17 - CBIS Logical Network Figure 18 - Lawful Intercept Workflow Today Figure 19 - Lawful Intercept Workflow with SDN Figure 20 - Lawful Intercept Signaling and Media Figure 21 - Today s Lawful Intercept Workflow for Voice Figure 22 - Lawful Intercept Workflow for Voice with SDN Figure 23 - PacketCable Call Setup Workflow CableLabs 06/25/15

7 Figure 24 - PacketCable 1.5 Call Setup Workflow with SDN Figure 25 - PacketCable Event Message Architecture with RKS Figure 26 - Event Message Architecture with SDN Replacing RKS Figure 27 - PacketCable 2.0 Voice Call Setup Workflow Today Figure 28 - PacketCable 2.0 Voice Call Setup Workflow with SDN Figure 29 - Overview of Current DOCSIS Set-top Gateway System Figure 30 - DSG Setup Workflow Today Figure 31 - DSG Setup Workflow with SDN Figure 32 - IPTV Setup Workflow Today Multicast Figure 33 - IPTV Setup Workflow Today Unicast Figure 34 - IPTV Setup Workflow with SDN Multicast Figure 35 - IPTV Setup Workflow with SDN Unicast Figure 36 - Use of Data Model in SDN Architecture Figure 37 - DOCSIS Data Model Figure 38 - Packet Classifier Data Model Figure 39 - L2VPN Data Model Figure 40 - TPIA Data Model Figure 41 - Lawful Intercept Data Model Figure 42 - Generic Flow Data Model Figure 43 - Traffic Profile Data Model from Open Daylight SDN Controller Figure 44 - PCMM Traffic Profile Data Model Figure 45 - SFC and the DOCSIS Network Figure 46 -Traffic Flows from DOCSIS Network through Different Service Chains Figure 47 - Different Starting Point of SFC Figure 48 - DOCSIS 3.1 Downstream OFDM Channel Figure 49 - Possible Composition of the Profile Management Application Figure 50 - PMA Data Backend and Protocols Figure 51 - High Level Intent-Based Networking Architecture Figure 52 - Group Based Policy Architectural Components Figure 53 - OpenStack Keystone Supporting SDN Multiple Controllers with Intent Figure 54 - NeMo Relationship to Open Source and IETF Figure 55 - OpenDaylight Architecture Figure 56 - CCAP Abstractions List of Tables Table 1 - HSD Workflow Action and Information Needed Table 2 - L2VPN Information Exchange Table 3 - Information Exchanged for TPIA Table 4 - Information Exchanged for CBIS Table 5 - Information Exchanged for Lawful Intercept Voice Table 6 - Information Exchanged for PacketCable Table 7 - Information Exchanged for PacketCable CableLabs 06/25/15

8 Open Networking Table 8 - Information Exchanged for DSG Table 9 - Information Exchanged for IPTV Table 10 - Southbound Protocols Table 11 - PMA-CMTS Downstream Modulation Profile Messages Table 12 - Downstream OFDM Channel Descriptor Message Table 13 - Downstream Profile Request Message Table 14 - Downstream Profile Descriptor Message Table 15 - OFDM Downstream Spectrum Request Message Table 16 - OFDM Downstream Spectrum Descriptor Message Table 17 - OFDM Downstream Profile Test Request Message Table 18 - OFDM Downstream Profile Test Response Message Table 19 - CM-to-Profile Assignment Request Message Table 20 - CM-to-Profile Assignment Descriptor Message Table 21 - Profile-to-CM Assignment Message Table 22 - Profile-to-CM Assignment Message Table 23 - Service Order Data for New VPN Table 24 - Service Order Data for Adding Location to Existing VPN Table 25 - Example Location Information Table 26 - Service Order Data for Broadband Table 27 - Service Order Data for Voice Table 28 - Service Order Data for TV CableLabs 06/25/15

9 1 SCOPE 1.1 Introduction For the last few years, the networking industry has been interested in the new technology paradigms of Software Defined Networking (SDN) and Network Functions Virtualization (NFV). CableLabs has been investigating SDN and NFV and analyzing how these ideas can help solve various problems in Cable networks. The initial focus of the research was the OpenFlow protocol and the improvements it could bring in solving problems within the Cable Access network. Eventually, as the working group gained understanding of the SDN architecture, the focus shifted toward the most valuable ideas from the SDN space, including the following: Enabling a Software programmable network for an operator (across various access technologies). Dynamic provisioning and management of various network devices from a centralized controller. Improved automation using common APIs to abstract the underlying networks (be it DOCSIS, Ethernet Passive Optical Network (EPoN), etc.). Allow rapid creation of new services based on the platform created. The SDN and NFV technologies can be used individually by a cable operator with various benefits. However, a higher level of benefits will result when SDN and NFV are combined. NFV describes an architecture where functions within a network element, running on proprietary hardware, can be virtualized and moved to generic hardware. SDN is an architecture that abstracts the underlying network and allows the network to be programmatically configured. A separate work effort has been initiated around identifying components within the cable operator s network that can be virtualized. 1.2 SDN in the Access Network Given the benefits of SDN and NFV, the CableLabs Open Networking working group started investigating ideas around making the Cable access network elements, such as the CMTS or Converged Cable Access Platform (CCAP), more Software programmable; i.e., programming services dynamically on the access network devices. Figure 1 below describes an overall architecture for cable access network. Using the CCAP/CMTS architecture as a baseline; the working group identified components that can be potentially virtualized. The group identified data models which capture the configuration information for various services, which can now be set up on the access network via an SDN Controller. Figure 1 - SDN Architecture 9 CableLabs 06/25/15

10 Open Networking The goal of an SDN and NFV is to reduce Operational Expenditure (OPEX) and create a platform that enables faster delivery of new services. MSOs would like to scale the CMTS platform as service requirements increase (power, cooling, and compute processing load). There are multiple aspects of a managing and provisioning of services on a CCAP device and moving certain functionality outside the CCAP to run on MSO cloud. While the PHY functions cannot be virtualized at this point, other functions, (e.g., parts of the MAC, the scheduler, load balancing algorithms, dynamic QoS allocation for video, and others) may be virtualized as functions on a generic server architecture. 1.3 Topics Covered in the Tech Report SDN architecture for cable access network CCAP management abstraction SDN-ized service provisioning workflows and uses cases Data Models: UML and YANG North and southbound protocols analysis and recommendation Service function chaining in cable networks DOCSIS 3.1 profile management as an application Intent-based networking analysis 10 CableLabs 06/25/15

11 2 INFORMATIVE REFERENCES This specification uses the following informative references. [CBIS] Cable Broadband Intercept Specification, CM-SP-CBI2.0-I , June 25, 2015, Cable Television Laboratories, Inc. [C-DOCSIS] [CM-OSSI] [MULPIv3.1] [DSG] [L2VPN] [PCMM] [PKT-DQoS] [PKT-ESP] C-DOCSIS System Specification, CM-SP-CDOCSIS-I , March 5, 2015, Cable Television Laboratories, Inc. Cable Modem Operations Support System Interface Specification, CM-SP-CM-OSSIv3.1- I , June 11, 2015, Cable Television Laboratories, Inc. DOCSIS 3.1 MAC and Upper Layer Protocols Interface Specification, CM-SP- MULPIv3.1-I , June 11, 2015, Cable Television Laboratories, Inc. DOCSIS Set-top Gateway (DSG) Interface Specification, CM-SP-DSG-I , August 8, 2013, Cable Television Laboratories, Inc. Business Services over DOCSIS, Layer 2 Virtual Private Networks, CM-SP-L2VPN-I , May 28, 2015, Cable Television Laboratories, Inc. PacketCable Multimedia Specification, PKT-SP-MM-I , June 29, 2011, Cable Television Laboratories, Inc. PacketCable 1.5 Dynamic Quality-of-Service Specification, PKT-SP-DQOS1.5-I , June 24, 2009, Cable Television Laboratories, Inc. PacketCable 1.5 Electronic Surveillance Specification, PKT-SP-ESP1.5-I , April 12, 2007, Cable Television Laboratories, Inc. [PKT-QoS] PacketCable 2.0 Quality of Service Specification, PKT-SP-QOS-C , March 14, 2014, Cable Television Laboratories, Inc. [PHYv3.1] DOCSIS 3.1 Physical Layer Specification, CM-SP-PHYv3.1-I , June 11, 2015, Cable Television Laboratories, Inc. [RFC 6020] [RFC 6120] IETF RFC 6020, YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF), October IETF RFC 6120, Extensible Messaging and Presence Protocol (XMPP): Core, March [RFC 6241] IETF RFC 6241, Network Configuration Protocol (NETCONF), June [RFC 6455] IETF RFC 6455, The WebSocket Protocol, December [Fielding-2000] Architectural Styles and Design of Network-based Software Architectures; [IETF SUPA] [NeMo] [NI COMP] Simplified Use of Policy Abstractions, NeMo Project, Network Intent Composition, [NSH] Network Service Header, March [ODL] OpenDaylight documentation for PacketCable PCMM Plug-in, 11 CableLabs 06/25/15

12 Open Networking [OpenStack] [RESTCONF] [SFC Architecture] OpenStack Congress, RESTCONF Protocol, draft-ietf-netconf-restconf-04, January Service Function Chaining, June Reference Acquisition Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027; Phone ; Fax ; Internet Engineering Task Force (IETF) Secretariat, Center Oak Plaza, Sterling, VA 20166, Phone , Fax , OpenDaylight software community, OpenStack software community, School of Information and Computer Science at University of California of Irvine, 6210 Donald Bren Hall, Irvine, CA, 92967, 12 CableLabs 06/25/15

13 3 TERMS AND DEFINITIONS This document uses the following terms: Cable Modem Termination System (CMTS) Converged Cable Access Platform (CCAP) Edge QAM (EQAM) Northbound Abstraction Layer OpenDaylight OpenStack Orchestrator RESTCONF SDN Controller Southbound Abstraction Layer YANG A headend component that provides the operator network side termination for the DOCSIS link. A CMTS communicates with a number of cable modems to provide data services. A headend component that provides the functionality of a CMTS and an Edge QAM in a single architecture with greater QAM density and overall capacity. A headend or hub device that receives packets of digital video or data from the operator network. It re-packetizes the video or data into an MPEG transport stream and digitally modulates the transport stream onto a downstream RF carrier using QAM. This is the interface exposed to applications from am SDN controller. The SDN controller provides a set of common APIs to the application layer (typically referred to as the northbound interface). This is described by the application facing information/data model, and needs to be device independent. OpenDaylight is an open source project of a modular, pluggable, and flexible SDN controller platform. OpenStack is a free and open-source cloud computing software platform, it consists of a series of interrelated projects that control pools of processing, storage, and networking resources throughout a data center, managed through a web-based dashboard, command-line tools, or a RESTful API. Coordinates one or more controllers to provide end-to-end service. An HTTP based protocol used to access the data defined in YANG models using the concepts defined in NETCONF. Device manager that implements some or all of the device control plane as well as manage device configuration. This is the interface used by an SDN controller to communicate with network devices. An SDN Controller implements one or more protocols for command and control of the physical hardware within the network (typically referred to as the southbound interface). This is described by the device facing information/data model, and needs to be device specific. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF). 13 CableLabs 06/25/15

14 Open Networking 4 ABBREVIATIONS AND ACRONYMS This document uses the following abbreviations: AMID API BGP BIF BSS BYOCM BW CAPEX CBIS CCAP CGN CLI CM CMA CMC CMTS COPS COTS CPE CSR DCA DHCP DPD DS DSCP DOCSIS DPoE DSG EPL EPoN EQAM EVPL FW GBP GRE HSD HTTP ID Application Manager ID Application Programming Interface Border Gateway Protocol Broadband Interrupt Function Business Support System Bring Your Own Cable Modem Bandwidth Capital Expenditure Cable Broadband Intercept Specification Converged Cable Access Platform Carrier-grade NAT Command-line Interface Cable Modem CCAP Management Abstraction Coax Media Converter Cable Modem Termination System Common Open Policy Service Commercial Off-the-Shelf Customer Premise Equipment Customer Service Representative Distributed CCAP Architecture Dynamic Host Configuration Protocol Downstream Profile Descriptor Downstream Differentiated Services Code Point Data-Over-Cable Service Interface Specification DOCSIS Provisioning of EPON DOCSIS Set-top Gateway Ethernet Private Line Ethernet Passive Optical Network Edge QAM Ethernet Virtual Private Line Firewall Group Based Policy Generic Routing Encapsulation High Speed Data Hypertext Transfer Protocol Identifier 14 CableLabs 06/25/15

15 IETF Internet Engineering Task Force IP Internet Protocol IPS Intrusion Prevention System IPTV IP Television JSON JavaScript Object Notation L2VPN Layer 2 Virtual Private Network L3 Layer 3 L4 Layer 4 L7 Layer 7 LEA Legal Enforcement Act MAC Media Access Control MEPID Maintenance Entity Group End Point Identifier MIB Management Information Base MMM MAC Management Message MPLS Multiprotocol Label Switching MSO Multiple System Operator MTA Multimedia Terminal Adapter NBI Northbound Interface NCP Next Codeword Pointer NETCONF Network Configuration Protocol NFV Network Function Virtualization NMS Network Management System NSH Network Service Headers NSI Network Side Interface OCD OFDM Channel Descriptor ODL OpenDaylight ODS OFDM Downstream Spectrum OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiplexing with Multiple Access OLT Optical Line Termination OPEX Operational Expenditure OPT OFDM Downstream Profile Test OSS Operations Support System OSSI Operations Support System Interface PCMM PacketCable Multimedia PCRF Policy and Charging Rules Function PHY Physical Layer PLC PHY Link Channel PMA Profile Management Application PNM Proactive Network Maintenance QAM Quadrature Amplitude Modulation 15 CableLabs 06/25/15

16 Open Networking QoS REST RKS SDN SDP SF SFC SLB SNMP SNR SOAM SSL TCP TPIA UDC US VAN VCC VLAN VM VoIP VXLAN XML XMPP Quality of Service Representational State Transfer Record Keeping Server Software Defined Networking Session Description Protocol Service Flow Service Function Chaining Server Load Balancing Simple Network Management Protocol Signal-to-Noise Ratio Service Operations, Administration, and Maintenance Secure Socket Layer Transmission Control Protocol Third Party ISP Access Upstream Drop Classifier Upstream Virtual Access Node Virtual CCAP Controller Virtual Local Area Network Virtual Machine Voice over IP Virtual Extensible LAN Extensible Markup Language Extensible Messaging and Presence Protocol 16 CableLabs 06/25/15

17 5 SDN AND THE ACCESS NETWORK 5.1 CCAP High Level Overview of CCAP Converged Cable Access Platform (CCAP) combines CMTS core and EQAM functionalities into a single hardware. Combining CMTS core and EQAM functionalities give MSOs flexibility to share QAM ports used for data and video. It also allows a simplified transition to all IP delivery. The CCAP leverages existing technologies, including DOCSIS 3.0, DOCSIS 3.1, Modular Headend Architecture, Ethernet optics, Ethernet Passive Optical Network (EPON) and current HFC architectures; and also can include newer ones. Figure 2 below shows the high level functional blocks present within a CCAP device. Figure 2 - Overview of CCAP Benefits of CCAP CCAP is intended to provide a new equipment architecture option for manufacturers to achieve the Edge QAM and CMTS densities that MSOs require in order to address the costs and environmental challenges resulting from the success of narrowcast services. The CCAP architecture is designed to meet several goals for MSOs: Larger DS and US channel counts to match subscriber BW demands Lower costs per DOCSIS channel Less space required within headend facilities Space savings results in reduced power consumption in the data center Simpler configuration management to support rapid HFC plant changes that will occur over next decade CCAP Management and Configuration There are several methods to manage and configure a CCAP. The first method is the processing of XML configuration files that hold the configuration details for all services on the CCAP. The XML configuration files are generated by YANG modules. The CCAP can also support NETCONF for configuration as defined in [RFC 6241] as well as the traditional command-line interface (CLI). 17 CableLabs 06/25/15

18 Open Networking Distributed CCAP Architecture Distributed CCAP Architecture (DCA) allows the distribution of CCAP PHY or MAC and PHY functions to remote nodes. The distributed CCAP Architecture (Remote PHY, Remote MAC-PHY, etc.) is documented in CableLabs DCA specifications and Technical reports. [C-DOCSIS] and the DCA documents present a logical architecture of distributed deployment and centralized management for the cable broadband access system. The C-DOCSIS specification defines a CMTS with a Coax Media Converter (CMC) in a remote node and a CMC Controller to achieve the DOCSIS CMTS functionality. 5.2 CCAP Management Abstraction (CMA) There are various network devices, which compose the access network, and each need to be configured and managed for MSOs to deploy services. The SDN architecture needs to support legacy and future devices in the access network. There is a need to abstract the underlying CMTS/CCAP/Distributed-CCAP components and the other network devices within the access network. The CMA, as described in Section 7 is an application framework, which abstracts the underlying CMTS/CCAP components to the SDN Controller and supports newer protocols for management and configuration. DCA deployments can use a centralized controller that implements the CMA functions. 5.3 Network Function Virtualization of CCAP It is possible to implement CCAP packet-processing functions inside a virtual machine. This may include MAC level processing as well as DOCSIS scheduling and QoS functions. From an SDN and CMA perspective, such a device can be managed similarly to other distributed architectures. 5.4 Some General SDN and NFV Concepts and Terms This section introduces some general terms and concepts around Software defined Networking and Network Function virtualization. The term virtualization has become overloaded to the point where any form of abstraction or decomposition of functions is coined to as virtualization. The following section attempts to present a finer grained terminology from the point of view of network function virtualization Centralized Architecture: In CMTS/CCAP architecture, the term centralized architecture refers to an integrated CCAP where all the functions of CCAP are implemented in a single device. In the general computing world, a centralized architecture is one where most of the compute power is centered in one location. The mainframe and the cloud are good examples of centralized architectures. Distributed Architecture: In CMTS/CCAP architecture, the term distributed architecture refers to an distributed CCAP where the functions that comprise of CCAP are implemented in several discreet components. In the general computing world, a distributed architecture is one where the compute power is equally distributed in a system. Traditional networking with routing protocols is a good example of a distributed architecture. Centralized and Distributed Architectures: centralizing of functions should not be confused with virtualization and one should not confuse a network architecture with implementation of functions (virtual vs. physical). For example, a physical CCAP packet-shelf can be placed in a central location with remote access nodes to create a centralized architecture that is not based on virtual components. The complement is also true virtualized functions can be distributed. This is sometimes referred to as fog computing where the virtual functions as close to the user. Network Virtualization: The term network virtualization refers to creating an overlay network on top of a physically connected network (also known as underlay ). Software Defined Networking: While the exact definition of SDN is evolving, a common theme is the separation of control and management planes of a network element from the data forwarding. The extent of separation can be varied. The purist view of SDN is to have a controller supporting a protocol with hooks into the forwarding plane (open-flow like) interface on the networking device. This has evolved to other approaches that focus more on the programmability of network devices and services. 18 CableLabs 06/25/15

19 The control/management plane can run in a virtual machine but SDN by itself is not referred to as virtualization. From the SDN controller point of view, it does not matter if the controlled network function is physical or virtual. Virtualization: Originally the term virtualization referred to the simulation a hardware platform. An unmodified binary of a software package can run on this hardware platform simulation natively as if it is running on the original hardware platform. In the context of NFV, the term virtualization focuses on the benefits of running a networking functions over a virtual hardware platform. Independence of the network function from a vendor specific hardware Ability to move network function workloads between hardware platforms 19 CableLabs 06/25/15

20 Open Networking 6 SDN ARCHITECTURE FOR CABLE ACCESS NETWORKS 6.1 SDN/NFV Integration Before diving into the details of how to leverage SDN and NFV technologies in cable, it is important to outline a reference architecture that defines the interaction between the various components. Figure 3 below shows a highlevel architecture. The main concept here is that of a centralized SDN controller; this controller can talk to various access network elements in the MSO s network. The working agreement is that the SDN controller communicates directly to the headend equipment (e.g., CMTS, CCAP, DPoE System) and intermediate nodes (e.g., CMC or Remote PHY), but not directly to the Customer premise equipment (CMs, ONUs, customer devices). The idea is to define the data models needed to configure the network devices and network services, and choose a common southbound protocol to carry this configuration information from the controller to the network devices. This enables the operator to expose a common network API, which can be used to build various applications. The applications reside above the SDN controller and request the SDN controller to configure the network as per the specific needs of the application. Also as parts of the network functionality are moved out of the CMTS to virtual machines into the MSO cloud, an orchestration layer will be needed to manage the various functions, both virtual and physical, and to coordinate with the SDN controller to steer traffic to and from those functions. Figure 3 - SDN Reference Architecture for Cable Access Networks There are multiple points at which a standardized interface can be defined. The main interface / interaction, in the scope of this document at this time, is the southbound interface from the SDN controller to the network devices. Within the MSO access network, the idea is to make this interface the same, regardless of whether the SDN controller is communicating to a CCAP/CMTS device, a C-DOCSIS Controller, or other access network equipment such as DPoE systems. This abstraction enables any application to be written without consideration for the specifics of the underlying network infrastructure. For example, an L2VPN application could connect end points across access networks, and 20 CableLabs 06/25/15

21 the SDN controller will manage configuration of the end points, one of which could be on a DOCSIS network and the other on a EPoN network, and also configure the path in the core network between the end points. The SDN architecture described here for DOCSIS access networks can be easily applied to other access network technologies and pieces of network equipment on the MSO network. Take, for example, an EPoN deployment by an operator; the EPoN systems can be provisioned using the DPoE specifications. An SDN controller could essentially play that role of the DPoE System and a virtual CM, to take in DOCSIS Provisioning commands and translate them to EPoN specific commands, and send them to an existing EPoN OLT system. In this way, legacy equipment with disparate provisioning systems can all be controlled via a Single SDN controller. Again, the key would be to create the needed data models for EPoN systems to make sure the application/service intents can be translated appropriately to the technology which is being configured. The protocol to talk from an SDN controller to the OLT could be something like RESTCONF for some other legacy protocol supported by the OLT, as long as the SDN controller can support that southbound protocol. This can apply to other access technologies as well, e.g., GPoN deployments, new services on top of DOCSIS or PON deployments, Wi-Fi AP provisioning and management, etc. 6.2 SDN Controller Figure 4 shows a high level overview of the SDN controller. The layers within the SDN controller enable it to support multiple applications, multiple devices, and multiple communication methodologies. The Southbound protocols will evolve over time. The idea is to pick some common protocols, which will be used by the access network devices and devices in the core of the network that may be controlled by the centralized SDN controller in the future. As an intermediate step to the future, the idea is to re-use protocols that exist today (even if they are not perfectly optimized for this SDN-ized architecture) to enable faster development and deployment of services. The SDN controller provides abstractions for network devices that can be used by applications to create needed forwarding and device configurations required by services. The SDN controller also provides access to protocols and data models for communicating directly with network elements to create the necessary configurations needed to instantiate a given service. The data models that the SDN controller supports and uses are critical; they form the basis for how new services and applications will be built and deployed. This model aligns with the work that is being done around OpenStack and OpenDaylight. The SDN controller is considered an element manager even in the case of CMA, despite the fact that it s a collection of devices; the CMA presents that collection as a single element to the SDN controller. Figure 4 - Internal View of SDN Controller 6.3 Northbound and Southbound Interfaces on the SDN Controller The service/business logic interfaces are commonly referred to as northbound of the controller and the devicespecific interfaces are referred to as southbound. The SDN controller exposes APIs to the applications; these are the northbound APIs from the perspective of the SDN controller. The SDN controller exposes programmatic 21 CableLabs 06/25/15

22 Open Networking interfaces to each of the network elements it controls; this is the southbound API. This document attempts to define what the southbound APIs would be (in terms of the parameters passed) with the understanding that the northbound APIs exposed to an application would be addressed at a future time. 22 CableLabs 06/25/15

23 7 CCAP MANAGEMENT ABSTRACTION In the SDN Reference architecture below the CCAP/CMTS will support protocols on the NSI side to communicate with the SDN controller. CCAP/CMTSs which support protocols and the data models to enable dynamic configuration of services will bring the level of programmability to the network and enable MSOs to develop applications independent of the underlying access network architecture. There are different methods of implementing the CMA and this section covers some of the use cases. Figure 5 - SDN Reference Architecture and CMA 7.1 Need for CCAP Management Abstraction The permutations and combinations of how a CCAP/CMTS can be distributed within the access network are many. The key is the existence of a CCAP Management Abstraction (CMA) that abstracts the various components of this distributed system into a single, cohesive CCAP platform for the OSS/BSS systems. This is an important point when considering this technical report. The CMA is not the SDN controller that applications are built on top of; at least it is not required to be. The CMA is an application whose function is to create a container around a number of physical and virtual functions and enable them to be managed and provisioned from existing back-office systems, similar to an integrated monolithic CCAP is today. The purpose of the CMA is to abstract the underlying components and division of labor from the back-office systems deployed today in MSO networks. It represents the disparate components under it as an integration monolithic CCAP, enabling its use without modification of existing configuration and management systems. Just like a CMTS or a CCAP, the CMA is a client of the SDN controller and can interface with it using a variety of protocols. SNMP, NETCONF, and PCMM are existing tools deployed today and will be leveraged in the future. 23 CableLabs 06/25/15

24 Open Networking The CMA makes it possible to present small and separate network elements as a single managed entitiy. In that sense, it emulates an integrated CCAP as a single managable entitiy even though it is physically made up of many smaller components. For example, a router + a number of remote nodes + a number of EQAMs will all appear as a single CCAP device. 7.2 CMA for Distributed CCAP Architectures Distributed CCAP architectures define a different CMTS architecture where DOCSIS MAC and PHY can be located in different parts of the access network: at the headend or at a fiber node. The CMA provides an abstraction to the underlying Distributed Architecture. A CMA performs the following functions: Emulates an Integrated CCAP for upper layers of the architecture as mentioned above (e.g., the CMA IP address can be the CCAP management IP address). Supports SNMP agent and command line interface to configure CCAP if needed. Supports network virtualization. Emulates CM behavior for OSS/NMS, via the concept of Virtual CMs. Supports self-management (e.g., self-configuration and self-healing) for a distributed CCAP system. The CMA can be integrated in the headend with CMTS/OLT/router equipment, or can be connected to them using an L2 or L3 network. For example, the CMA can run in a virtual machine in the data center which is connected to the access network equipment via an L3 network. The interface between CMA and the underlying distributed CCAP architecture is left to vendor implementation. The management of distributed CCAP involves a set of concepts. It may involve re-partitioning the functions traditionally performed in an integrated CCAP system and distributing them to other devices in the network. This is coupled with a software application that acts as the controller of this distributed system. The components of this new CCAP system can be either physical edge router, fiber node, etc., and/or virtual application or Virtual Machine (VM) running on an x86 server. This new CCAP architecture will benefit from a new way to provision and manage the device and services on the DOCSIS access network as described in Section CableLabs 06/25/15

25 8 SELECTED USE CASE WORKFLOWS Several service workflows / use cases in the cable operator s network were studied with the purpose of figuring out how these services would be enabled, provisioned, and managed within the SDN Architecture developed so far. The use cases studied were High Speed Data, Layer 2 Virtual Private Network (L2VPN), Third Party ISP Access (TPIA), Lawful Intercept, Voice, and IPTV. The approach was to study current practice of setting up those service types, then to investigate how SDN could streamline various procedures in order to reduce both setup time and unintended errors, and introduce a level of software programmability which is not present today. The information exchanged between network components was gathered for the purpose of developing information models and captured as UML diagrams. From a network management point-of-view, the SDN controller, to a large extent, replaces the element management and part of the network management, but is still below the service and business logic. The role of the SDN controller in many cases is to take a generic service definition (e.g., provide a customer with a 100 Mbps service) and translate it to a device-specific configuration. For example, in the DOCSIS case the SDN controller takes a generic service creation request (100 Mbps speed) and translates it to a DOCSIS service flow with a sustained rate of a 100 Mbps and upstream service flows with other DOCSIS specific parameters. 8.1 HSD Bring Your Own Cable Modem High Speed Data (HSD) service is one of the most common services when a user subscribes to an MSO network. Figure 6 shows the current workflow for HSD using a customer-provided CM. The Customer Service Representative (CSR) is responsible for gathering customer and device information and entering that information into the BSS/OSS system. The current approach requires the CSR to be a middleman between the customer and network components such as BSS/OSS. Figure 6 - HSD Workflow Today 25 CableLabs 06/25/15

26 Open Networking Figure 7 demonstrates the benefit of using SDN in this use case. A customer care web portal replaces the CSR. This web portal collects customer input and then forwards it to the BSS/OSS system. Upon receiving the customer request, BSS/OSS then instructs the SDN controller to set up network components such as the CM, and the CMTS for ordered service. The information needed for such service setup is listed in Table 1. Figure 7 - HSD Workflow with SDN Table 1 - HSD Workflow Action and Information Needed Action Other Information Information for YANG Model (for SDN Controller) Purchase cable modem (CM) None N/A CM initiation and DHCP CM capabilities CM MAC address Static register (CM) register CM Basic CM CM IP MAC and IP configuration DHCP (CPE) Register CPE MAC and IP Enter order for HSD Enter equipment ID with account Validate customer Provide customer s subscriber tiers Update service level CM MAC Account number Payment information IP address(es) or IPv6 prefixes allocated Index of CM MAC, CPE MAC Service template Service ID versus customer ID: CM MAC Tier of Service: translate to DOCSIS QoS parameters Subscriber management: Max CPE, Max number of IP Things from a CM configuration file (SNMP, classifiers, SF, UDCs, etc.) Other miscellaneous parameters Service attributes Method (Static versus Dynamic) Dynamic Dynamic 26 CableLabs 06/25/15

27 Action Other Information Information for YANG Model (for SDN Controller) Update services on CM HSD service active DOCSIS-specific parameters Maximum channels Method (Static versus Dynamic) Dynamic 8.2 L2VPN L2VPN service is used mainly by businesses to communicate across geologically separate campuses. Figure 8 shows the process of ordering an L2VPN service on the DOCSIS network and setting up the network path from the CM. Currently, a new L2VPN service order requires a CSR to enter information into the BSS/OSS system. Upon receiving such order, a network engineer then will configure the NSI path and will create a configuration file to be downloaded to the corresponding CMs. Figure 8 - L2VPN Workflow Today One major issue with the current workflow model is that it comprises two disparate processes: 1) the edge/core side where a pseudo-wire is configured; and 2) the access side where the CMTS is located. This process: a) takes time since each separate organization creates and responds to work tickets; and b) is error prone since it involves the manual exchange of data. SDN improves the workflow by orchestrating the two sides of the network and eliminating manual interventions. Figure 9 shows how SDN can be used for such service order and setup. Similar to the HSD use case, a web portal can replace the CSR and a corresponding SDN application configures the L2VPN path on the NSI side. The information needed for such service setup is listed in Table CableLabs 06/25/15

28 Open Networking Figure 9 - L2VPN with SDN SDN improves the process by dynamically associating a service flow to an L2VPN pseudo-wire. This means that a CM does not need to be rebooted in order to activate an L2VPN service. Ideally, this can be done without changes to PCMM; the DOCSIS service flow would be brought up as a standard flow (using the ODL PCMM/COPS plug-in) and the NSI side pseudo-wire would be brought up using other SDN tools (where even CLI is an acceptable interim way to achieve that). The controller would bind the DOCSIS service flow to the pseudo-wire automatically, thereby achieving a dynamic setup of an L2VPN service. Note that, in this report, only the attachment of the pseudo-wire to the CMTS is covered; there is also an end-to-end setup of the pseudo-wire that can be controlled by SDN; however that is outside the scope of this document. Table 2 - L2VPN Information Exchange Action Other Information Information for YANG Model (for SDN Controller) Order L2VPN Service Order entry and approval Provide circuit parameters Customer contacts/billing info/technical Circuit locations Bandwidth SLA MAC address None CM MAC address (one end or both) CMTS address (one end or both) Type of Service (EPL, EVPL, etc.) Redundancy/protection Method (Static versus Dynamic) N/A Dynamic 28 CableLabs 06/25/15

29 Action Other Information Information for YANG Model (for SDN Controller) Configure L2VPN path on NSI Configure service parameter and encapsulation Configure service flow Circuit ID/endpoint IDs MEP ID (SOAM) Network topology BGP information for core interaction DOCSIS-specific parameters Max channels, etc. NSI Next hop / Path setup L2VPN encapsulation for CM Encapsulation type (VLAN, MPLS, etc.) Label (provisioning application or autoassigned) L2VPN SF parameters Tier of service: Translate to DOCSIS QoS parameters and classifiers Subscriber management: Max CPE, max number of IP Other parameters for CM Method (Static versus Dynamic) Dynamic 8.3 Third Party ISP Access (TPIA) Canadian Radio-Television and Telecommunications Commission (CRTC) published a rule that mandates Canadian operators to offer Internet access to third party resellers. This rule was instituted to discourage monopoly and to offer consumers more provider choices. TPIA has allowed resellers to provide Internet service without significant investment in a network infrastructure. Figure 10 shows a high level overview of TPIA in a network, in which three resellers are offering Internet services from a single MSO. Figure 10 - Virtualized Network Topology Figure 11 shows the current practice of setting up a TPIA service, which requires collaborative effort between business teams and engineering teams throughout the entire order process. 29 CableLabs 06/25/15

30 Open Networking Figure 11 - TPIA Workflow Today By using SDN as shown in Figure 12, an SDN-aware application running as a web portal can replace the business team for collecting the necessary information from the customer and the external vendors. Furthermore, an SDN controller can configure the various network elements, which is otherwise a manual process done by the engineering team. 30 CableLabs 06/25/15

31 Figure 12 - TPIA with SDN TPIA can utilize a network virtualization technology to slice its physical network into several virtual networks as shown in Figure 13 below. Each virtual network can be wholesaled to different retailers (service providers). Each virtual network has its own data plane and control/management plane. Virtual Network can scale to include geographically dispersed locations. Virtual networks have the following advantages for MSO and service providers: Infrastructure sharing reduces TCO for MSO Brings a new stream of revenue for MSO Save OPEX for SP because service provisioning is simplified Ease of SP network implementation due to the use of the underlying MSO physical network 31 CableLabs 06/25/15

32 Open Networking Figure 13 - Slicing Physical Network into Multiple Virtual Networks Figure 14 and Figure 15 show a detailed view of the TPIA workflow using SDN, starting from initial customer requests to the final establishment of the circuit. The SDN controller and the SDN application mimic the original setup procedure that is conducted by the business team and the engineering team. Figure 14 - TPIA Workflow with SDN, Part 1 32 CableLabs 06/25/15

33 Figure 15 - TPIA Workflow with SDN, Part 2 Table 3 - Information Exchanged for TPIA Service Request Action Other Information Information for YANG Model (for SDN Controller) Customer Address Contract Speed IP Requirements None Order Validation Configure circuit IP block CMTS ID Contract Speed Create circuit Device Configuration Verification of circuit CPE IP Block Uplink VLAN Route DHCP server: Add CPE scope CMTS: CPE IP block, uplink, VLAN Regional switch: L2 Circuit ID, VPLS and or VLAN POI Router: L3 Protocol and VRF configuration Start and stop test Report test Method (Static versus Dynamic) Dynamic Dynamic Dynamic Dynamic 8.4 Lawful Intercept CableLabs has defined two specifications in regards to lawful intercept: Cable Broadband Intercept Specification [CBIS] for data and PacketCable 1.5 Electronic Surveillance Specification [PKT-ESP] for voice. The following sections describe how to use SDN in those two cases. 33 CableLabs 06/25/15

34 Open Networking Lawful Intercept Data Figure 16 illustrates the CBIS functionality surrounding data transport. The three main components are: 1) Mediation, 2) Broadband Intercept, and 3) Collection. Figure 16 - CBIS Interfaces Figure 17 offers a functional breakdown of CBIS operation surrounding data transport starting from a user end point at a MSO network to the collection function end point in the Legal Enforcement Act (LEA) network. CBIS has enough information to create identification tags for the expected data streams. For IPv4, it uses a 5-tuple consisting of source and destination IP addresses, source and destination ports and the protocol field. For IPv6, it adds a flow label to the 5-tuple. When user data is forwarded to the mediation function through the access function, it can be filtered by subject header only or unaltered. Data that matches the identification tag is formatted and passed to the Broadband Intercept Function and then it is forwarded to the Collection Function for further investigation by LEA. Figure 17 - CBIS Logical Network As shown in Figure 18, current lawful intercept practice requires an operator to look up specific customer information in a database to identify the corresponding CM and CMTS. Once a user is identified, the operator configures the access function, the mediation function, and the broadband intercept function for data capture. 34 CableLabs 06/25/15

35 Figure 18 - Lawful Intercept Workflow Today As shown in Figure 19, with an SDN controller and a corresponding application, the configuration of access, mediation and broadband intercept functionality is accomplished with the SDN controller, with instructions from an SDN application. The application replaces the aforementioned operator in the role of collecting user information, querying the database, and identifying the corresponding CM and CMTS. The information needed for such service setup is listed in Table 4. Figure 19 - Lawful Intercept Workflow with SDN 35 CableLabs 06/25/15

36 Open Networking Table 4 - Information Exchanged for CBIS Action Other Information Information for YANG Model (for SDN Controller) LEA to operator Operator to SDN Controller SDN Controller to Mediation Function SDN controller to Broadband Intercept Function Court document Name and address of customer Enable lawful intercept for user 5-tuple to identity the user Time duration Address of mediation function Enable lawful intercept for user Format of data Full packets or packet headers only Out-of-band messages Hashes Enable lawful intercept for user Buffer size Time to buffer LEA address Method (Static versus Dynamic) Lawful Intercept Voice The two subcategories of lawful intercept for voice are: 1) the signaling information (call data), and 2) the media (call content). Figure 20 illustrates the intercept points for both types. Figure 20 - Lawful Intercept Signaling and Media Figure 21 shows the workflow for voice lawful intercept. The intercept request comes from the LEA to the operator and the operator looks up the user. Once the user is identified, the operator configures different network elements for signaling and media capture. 36 CableLabs 06/25/15

37 Figure 21 - Today s Lawful Intercept Workflow for Voice Figure 22 shows lawful intercept with an SDN application (Operator Lawful Intercept application) and an SDN controller. Similar to the data intercept case, the SDN application and controller replaces the operator functionality. The SDN controller configures different network elements for voice capture, with information obtained from LEA via the Operator Lawful Intercept application. The information needed for such service setup is listed in Table 5. Figure 22 - Lawful Intercept Workflow for Voice with SDN 37 CableLabs 06/25/15

38 Open Networking Table 5 - Information Exchanged for Lawful Intercept Voice Action Other Information Information for YANG Model (for SDN Controller) LEA to operator Operator to SDN controller SDN controller to CMTS (Access function) SDN controller to PC 2.0 core SDN controller to Delivery Function Court document Name, address or phone number of customer Name, address, or phone number of customer Enable lawful intercept for user 5-tuple to identify the user Time duration Address of delivery function Enable lawful intercept for user 5-tuple to identify the user Time duration Address of delivery function Enable lawful intercept for user Format of data CC call content CII call identifying information Address of call function Method (Static versus Dynamic) 8.5 Voice PacketCable 1.5 and PacketCable 2.0 specifications were developed by CableLabs and adopted for voice transport services over cable networks. There are differences between these two suites of specifications and the following sections describe the two workflows accordingly PacketCable 1.5 Figure 23 shows the information exchanged between the MTAs, CMTSs, and RKSs from origin and destination side to establish a call. Figure 23 - PacketCable Call Setup Workflow Figure 24 shows an SDN application and an SDN controller replacing the RKS function. 38 CableLabs 06/25/15

39 Figure 24 - PacketCable 1.5 Call Setup Workflow with SDN Figure 25 - PacketCable Event Message Architecture with RKS As shown in Figure 24, for PacketCable 1.5, a progression of call start to call establishment requires the exchange of information between MTAs, CMTSs, and RKSs from both the origin and destination side. As shown in Figure 25, RKSs shoulder the responsibility of communicating to other components, such as billing systems and network elements. These steps comprise a suitable replacement candidate for SDN and a corresponding SDN application. An SDN controller, by design, has topology information, control, and status information for the underlying network element. An SDN application can leverage such information and communicate to the billing system as needed for OSS/BSS. This allows the separation of network configuration information and billing information. Thus network processing can be standardized using known protocols (e.g., OpenFlow, etc.), and the future migration of the network configuration element will be easier. In the meantime, it also allows communication between the SDN application and the existing billing system to be less bounded by the underlying network changes. This also allows seamless communication with other SDN controllers outside of the current MSO domain. Figure 26 shows this design philosophy and Table 6 shows the information needed for such service setup. 39 CableLabs 06/25/15

40 Open Networking Figure 26 - Event Message Architecture with SDN Replacing RKS Table 6 - Information Exchanged for PacketCable 1.5 QoS (SDP) Action Other Information Information for YANG Model (for SDN Controller) Service related DOCSIS QoS parameters SLA (bandwidth, priority, etc.) MAC address IP address Call party name and number Vendor specific Billing Correlation ID MTA MAC addresses MTA IP addresses Audio Code type Audio Code parameters Setup latency and post pickup delay Phone number Device capabilities Dynamic policy changes Multiple concurrent sessions Dynamic adjustment of QoS parameters CM MAC address CMTS MAC address Type of Service Method (Static versus Dynamic) N/A N/A Dynamic 40 CableLabs 06/25/15

41 8.5.2 PacketCable 2.0 In the case of PacketCable2.0, a voice call setup is accomplished via PCMM protocol. PCRF is responsible for setting a flow and negotiating QoS parameters with CMTS and P-CSCF. Figure 27 shows the steps that are needed to make such a call. Figure 27 - PacketCable 2.0 Voice Call Setup Workflow Today By replacing PCRF with an SDN voice application and an SDN controller, as seen in Figure 28, the SDN voice application serves as a translator between P-CSCF and SDN controller for the QoS requests and replies. And SDN controller can setup proper flow via DSx messages accordingly. The information needed for such service setup is listed in Table 7. Figure 28 - PacketCable 2.0 Voice Call Setup Workflow with SDN 41 CableLabs 06/25/15

42 Open Networking Table 7 - Information Exchanged for PacketCable 2.0 Action Other Information Information for YANG Model (for SDN Controller) Method (Static Versus Dynamic) SDP TSpec Bucket depth (b) bytes Bucket rate (r) bytes/second Peak rate (p) bytes/second Minimum policed unit (m) bytes Maximum datagram size (M) bytes RSpec Reserved rate (r) - bytes/second Slack term (S) microseconds IP Flow Direction (in or out) Source and destination IP address and port Protocol Framed IP AVP Dynamic DOCSIS QoS Parameters Subscriber ID CM MAC address CMTS address GateSpec (ToS DSCP markings) Classifiers Identity: MAC address and CM MGMT IP and SF Dynamic 8.6 DSG The DOCSIS Set-top Gateway (DSG) specification defines a method to transport set-top box commands and configurations over a DOCSIS network. Figure 29 provides both a physical and logical view of the various components needed for this type of scenario. 42 CableLabs 06/25/15

43 Figure 29 - Overview of Current DOCSIS Set-top Gateway System As can be seen in Figure 30, current DSG setup requires an operator to configure the DSG server, agent, and client separately. This requires human effort and is subject to various human errors during the process. With a DSG application running on top of an SDN controller, as illustrated in Figure 31, an operator can instruct the SDN controller to configure the DSG server, agent, and client in one pass. Table 8 lists the necessary information elements and actions needed for the SDN controller to accomplish this task. Figure 30 - DSG Setup Workflow Today 43 CableLabs 06/25/15

44 Open Networking Figure 31 - DSG Setup Workflow with SDN Table 8 - Information Exchanged for DSG Action Other Information Information for YANG Model (for SDN Controller) Method (Static Versus Dynamic) SDN controller to DSG server DSG tunnel setup IP address and UDP port number (source and destination) SDN controller to DSG agent DSG server connection setup Multiple DSG servers DSG tunnel setup DSG rule setup (Annex A MIBs) Data Carrier Detect (DCD) 8.7 IPTV As shown in Figure 32 and Figure 33, a Multicast or Unicast service setup involves many interactions among different components in the network. In particular, PCRF/CMTS and PCRF/PCMM components are responsible for setting up a DOCSIS service flow and the corresponding QoS parameters. Thus, an SDN controller can be used to provide this functionality just as in other use cases. This allows for a single generic SDN interface instead of proprietary protocols such as PCMM, and easier interaction with other SDN networks. Figure 34 and Figure 35 show this approach. The information needed for such service setup is listed in Table CableLabs 06/25/15

45 Figure 32 - IPTV Setup Workflow Today Multicast 45 CableLabs 06/25/15

46 Open Networking Figure 33 - IPTV Setup Workflow Today Unicast 46 CableLabs 06/25/15

47 Figure 34 - IPTV Setup Workflow with SDN Multicast 47 CableLabs 06/25/15

48 Open Networking Figure 35 - IPTV Setup Workflow with SDN Unicast 48 CableLabs 06/25/15

49 Table 9 - Information Exchanged for IPTV Action Other Information Information for YANG Model (for SDN Controller) Method (Static Versus Dynamic Protocol) Program requests None Static IGMP Join message NSI: HTTP: wget Subscriber ID Duration Extended classifier Minimum reserved rate PCRF Service Name DOCSIS: COPS: Gate Set AMID Extended classifier DOCSIS parameters Dynamic Channel Leave NSI and DOCSIS: Gate Delete (Gate ID, Tear Down, Gate Delete Acknowledge) Dynamic 49 CableLabs 06/25/15

50 Open Networking 9 DATA MODELS The data models are an organized collection of information elements, and they describe how the information relates to each other. These information elements are parameters, which can be configured for a specific device or service. The data model defines the requirements/parameters needed to setup a service. The data models that the SDN controller supports and uses are critical because they form the basis of how new services and applications will be implemented. Once a data model has been created, it will be used by the SDN controller and the network devices as shown in figure below. The data model is implemented by the SDN controller to expose APIs to the network devices it controls. The network devices implement the same data model to complete the device and service configuration. Figure 36 - Use of Data Model in SDN Architecture One of the enabler for a software programmable network is the configuration and statistics information as described in previous section, which is exchanged between the SDN controller and each of the network devices. An information model or the data model needs to be developed for every network device that needs to be programmed. This data model will include all the data elements, like device settings or service settings, which need to be read by or written from a controller, to enable the devices and services across the network. It will include the elements needed to configure the device on boot-up (day-zero config). More importantly, the data model will also include the data elements which represent the creation of services over those network devices (dynamic-config). For data modeling, YANG is the choice of the networking industry. YANG is the data modeling language used to model configuration and state data manipulated by the NETCONF protocol (see [RFC 6241]), remote procedure calls, and notifications. It is a "human-friendly" modeling language for defining the semantics of operational data, configuration data, notifications, and operations. This document has defined data models for the DOCSIS network, L2VPN, TPIA, Lawful Intercept and a generic flow model. These are shown in Figure 37, Figure 39, Figure 40, Figure 41, and Figure CableLabs 06/25/15

51 9.1 DOCSIS IP HSD Provisioning Figure 37 - DOCSIS Data Model 51 CableLabs 06/25/15

52 9.1.1 Packet Classifier Figure 38 - Packet Classifier Data Model 52 CableLabs 06/25/15

53 9.1.2 YANG Model for DOCSIS Data Model module DOCSISConfig { namespace "urn:cablelabs:params:xml:ns:yang:sdn"; prefix DOCSISConfig; import ietf-inet-types { prefix inet; revision-date ; import ietf-yang-types { prefix yang; revision-date ; organization "Cable Television Laboratories, Inc."; contact "Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado U.S.A. Phone: Fax: mibs@cablelabs.com"; reference ""; revision { typedef ethernet-protocol-id-type { type enumeration { enum other { value 1; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum none { value 2; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum ethertype { value 3; description "A value of 'ethertype' means that the rule applies only to frames that contain an EtherType value. Ethertype values are contained in packets using the DEC-Intel- Xerox (DIX) encapsulation or the [RFC 1042] Sub-Network Access Protocol (SNAP) encapsulation formats."; enum dsap { value 4; description "A value of 'dsap' means that the rule applies only to frames using the IEEE802.3 encapsulation format with a Destination Service Access Point (DSAP) other than 0xAA (which is reserved for SNAP)."; enum mac { value 5; description " A value of 'mac' means that the rule applies only to MAC management messages for MAC management messages."; enum all { value 6; description "A value of 'all' means that the rule matches all Ethernet frame. If the Ethernet frame contains an 802.1P/Q Tag header (i.e., EtherType 0x8100), this attribute applies to the embedded EtherType field within the 802.1p/Q header."; 53 CableLabs 06/25/15

54 Open Networking description "This enumerates the set of formats of the layer 3 protocol ID in the Ethernet frame."; grouping PacketClassifierEncodings-group { list PacketClassifierEncodings { key Reference Identifier; leaf Reference { type int8; leaf Identifier { type uint16; leaf SfReference { type uint16; leaf SfIdentifier { type uint32; leaf RulePriority { type uint8; choice Encodings { case MplsPacketClassifierEncodings { leaf TrafficClass { type uint8; leaf Label { type uint32; case Ipv6PacketClassifierEncodings { leaf TCRangeandMask { type int32; leaf IpFlowTable { type int32; leaf NextHeaderType { type int16; leaf SourceAddressV6 { type inet:ipv6-address; leaf SourcePrefixLengthV6 { type int8; leaf DestinationAddressV6 { type inet:ipv6-address; leaf DestinationMaskV6 { type int8; case Ipv4PacketClassifierEncodings { leaf TosRangeAndMask { 54 CableLabs 06/25/15

55 type uint32; leaf IpProtocol { type uint16; leaf SourceAddressV4 { type inet:ipv4-address; leaf SourcePrefixLengthV4 { type int8; leaf DestinationAddressV4 { type inet:ipv4-address; leaf DestinationMaskV4 { type int8; case IcmpV4V6PacketClassifierEncodings { leaf TypeStart { type int32; leaf TypeEnd { type int32; case TcpUdpPacketClassifierEncodings { leaf SourcePortStart { type int16; leaf SourcePortEnd { type int16; leaf DestPortStart { type int16; leaf DestPortEnd { type int16; case EthernetPacketClassifierEncodings { leaf DestinationMacAddress { type yang:mac-address; leaf SourceMacAddress { type yang:mac-address; leaf EtherDsapMacType { type int32; grouping SubscriberMgmt-group { container SubscriberMgmt { 55 CableLabs 06/25/15

56 Open Networking leaf SubMgmtMacAddress { type yang:mac-address; leaf SubMgmtIpV4Address { type inet:ipv4-address; leaf SubMgmtIpV6Address { type inet:ipv6-address; leaf SubMgmtPrefix { type inet:ipv6-address; leaf SubMgmtPrefixLength { type int8; grouping DsServiceFlow-group { list DsServiceFlow { key DsFlowId; leaf DSMaxSustainedTraffRate { type int32; leaf DsPeakTraffRate { type int32; leaf MaxDsLatency { type int32; leaf DsResequencing { type boolean; leaf DsFlowReference { type int8; leaf DsServiceClassName { type string; leaf DsFlowId { type int32; leaf DsQosParamSetType { type int8; leaf DsSFReqAttrMask { type int32; leaf DsServiceId { type int16; leaf DsSFForbidAttrMask { type int32; leaf DsSFAttrAggrRuleMask { type int32; 56 CableLabs 06/25/15

57 leaf DsAppId { type int32; leaf DsAggrSFRef { type int16; leaf DsMESPRef { type int16; leaf DsTrafficPriority { type int8; leaf DsMaxTraffBurst { type int32; leaf DsMinResTraffRate { type int32; leaf DsAssumedMinResRatePacketSize { type int8; leaf DsTimeOutActiveQoSParam { type int8; leaf DsTimeOutAdmitQoSParams { type int8; leaf DsIPTOSOverwrite { type string; leaf DsMinBuffer { type int32; leaf DsTargetBuffer { type int32; leaf DsMaxBuffer { type int32; leaf DsSFtoIATCProfileNameRef { type string; leaf DsSfAqmDisable { type int8; leaf DsSfAqmLatencyTarget { type int8; grouping UsServiceFlow-group { list UsServiceFlow { key UsFlowId; 57 CableLabs 06/25/15

58 Open Networking leaf UsPeakTraffRate { type int32; leaf UsMaxConcatenatedBurst { type int16; leaf UsSfSchedulingType { type int8; leaf UsFlowReference { type int8; leaf UsServiceClassName { type string; leaf UsFlowId { type int32; leaf UsServiceId { type int16; leaf UsQosParamSetType { type int8; leaf UsSFReqAttrMask { type int32; leaf UsSFForbidAttrMask { type int32; leaf UsSFAttrAggrRuleMask { type int32; leaf UsAppId { type int32; leaf UsAggrSFRef { type int16; leaf UsMESPRef { type int16; leaf UsTrafficPriority { type int8; leaf UsMaxTraffBurst { type int32; leaf UsMinResTraffRate { type int32; leaf UsAssumedMinResRatePacketSize { type int8; 58 CableLabs 06/25/15

59 leaf UsTimeOutActiveQoSParam { type int8; leaf UsTimeOutAdmitQoSParams { type int8; leaf UsIPTOSOverwrite { type string; leaf UsMinBuffer { type int32; leaf UsTargetBuffer { type int32; leaf UsMaxBuffer { type int32; leaf UsSFtoIATCProfileNameRef { type string; leaf UsSfAqmDisable { type int8; leaf UsSfAqmLatencyTarget { type int8; leaf UsReqTxPolicy { type int32; leaf UsNominalPollInterval { type int32; leaf UsToleratedPollJitter { type int32; leaf UnsolicitedGrantSize { type int16; leaf UsNominalGrantInterval { type int32; leaf UsToleratedGrantJitter { type int32; leaf UsGrantsPerInterval { type int8; leaf UsUnsolicitedGrantTimeRef { type int32; leaf UsMultToContentionReqBackoffWin { type int8; 59 CableLabs 06/25/15

60 Open Networking leaf UsMultToNumOfBytesReq { type int8; container DocsisCfg { list DocsisCfg { key ChannelId; leaf DownstreamFrequency { type int32; leaf ChannelId { type int8; leaf NetworkAccessCtrl { type boolean; default false; leaf VendorId { type string; leaf SoftwareUpgradFileName { type string; leaf MaxNumCpes { type int8; leaf TftpServerTimestamp { type int32; leaf TftpCMIpv4Addr { type inet:ipv4-address; leaf TftpCMIpv6Addr { type inet:ipv6-address; leaf MaxNumClasifiers { type int32; leaf PrivacyEnable { type boolean; default false; leaf SubscriberMgmtControl { type string; leaf SoftwareMgmtFilterGroups { type string; leaf SubscriberMgmtControlMaxCpeIpv6 { type int16; leaf EnableTestMode { type boolean; 60 CableLabs 06/25/15

61 default false; leaf SoftwareUpgradeTftpServerIpv4Addr { type inet:ipv4-address; leaf SoftwareUpgradeTftpServerIpv6Addr { type inet:ipv6-address; leaf DefaultUpstreamTargetBuffer { type int16; leaf CmUpstreamAqmDisable { type int8; leaf MacAddressLearningControl { type boolean; leaf MacAddressLearningHoldoffTimer { type int8; leaf CmMacAddress { type yang:mac-address; leaf CmIpV4Address { type inet:ipv4-address; leaf CmIpV6Address { type inet:ipv6-address; list EnergyMgmt { key EmId; leaf EmId { type int16; leaf FeatureControl { type int32; leaf CyclePeriod { type int16; leaf ModeIndicator { type int8; uses PacketClassifierEncodings-group; uses SubscriberMgmt-group; uses DsServiceFlow-group; uses UsServiceFlow-group; 61 CableLabs 06/25/15

62 9.2 L2VPN Data Model Figure 39 - L2VPN Data Model 62 CableLabs 06/25/15

63 9.2.1 YANG Model for L2VPN module L2Vpn { namespace "urn:cablelabs:params:xml:ns:yang:sdn"; prefix L2Vpn; import ietf-inet-types { prefix inet; revision-date ; import ietf-yang-types { prefix yang; revision-date ; organization "Cable Television Laboratories, Inc."; contact "Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado U.S.A. Phone: Fax: mibs@cablelabs.com"; reference ""; revision { typedef ethernet-protocol-id-type { type enumeration { enum other { value 1; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum none { value 2; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum ethertype { value 3; description "A value of 'ethertype' means that the rule applies only to frames that contain an EtherType value. Ethertype values are contained in packets using the DEC-Intel- Xerox (DIX) encapsulation or the [RFC 1042] Sub-Network Access Protocol (SNAP) encapsulation formats."; enum dsap { value 4; description "A value of 'dsap' means that the rule applies only to frames using the IEEE802.3 encapsulation format with a Destination Service Access Point (DSAP) other than 0xAA (which is reserved for SNAP)."; enum mac { value 5; description " A value of 'mac' means that the rule applies only to MAC management messages for MAC management messages."; enum all { value 6; description "A value of 'all' means that the rule matches all Ethernet frame. If the Ethernet frame contains an 802.1P/Q Tag header (i.e., EtherType 0x8100), this attribute applies to the embedded EtherType field within the 802.1p/Q header."; 63 CableLabs 06/25/15

64 Open Networking description "This enumerates the set of formats of the layer 3 protocol ID in the Ethernet frame."; container L2Vpn { list L2Vpn { key VpnId; leaf VpnId { type uint32; leaf ESafeDHCPSnooping { type uint32; leaf CMIterfaceMaskSubType { type uint32; leaf AttachementGroupId { type binary; leaf SourceAttachmentIndividualId { type binary; leaf TargetAttachmentIndividualId { type binary; leaf L2VPNSADescriptorSubType { type binary; leaf PseudowireSignaling { type binary; leaf DsId { type uint64; choice NSIEncapsulationSubType { case ET802.1Q { leaf Tag { type uint32; case ET802.1ad { leaf SPVLanId { type uint32; leaf CustVLanId { type uint32; case ET802.1ah { leaf BackboneServiceITagTCI { type uint32; leaf DestBEBMacAddress { type yang:mac-address; 64 CableLabs 06/25/15

65 leaf BTag { type uint16; leaf Itag { type uint16; leaf Ipcp { type uint8; leaf Idei { type uint8; leaf Iuca { type uint8; leaf ISIDBackboneServiceInstanceId { type uint64; leaf BTagTPId { type uint16; leaf Bpcp { type uint8; leaf Bdei { type uint8; leaf Bvid { type uint16; leaf Stpid { type uint16; case ETMpls { leaf PseudoWireId { type uint64; leaf PeerIpAddrV4 { type inet:ipv4-address; leaf PeerIpAddrV6 { type inet:ipv6-address; leaf PseudoWireType { type uint8; leaf BackupPseudoWireId { type uint64; leaf BackupPeerIpAddrV4 { type inet:ipv4-address; 65 CableLabs 06/25/15

66 Open Networking leaf BackupPeerIpAddrV6 { type inet:ipv6-address; case ETL2TpV3 { leaf InetAddressType { type uint32; leaf L2TIpAddrV4 { type inet:ipv4-address; leaf L2TIpAddrV6 { type inet:ipv6-address; list BgpAttribute { key VpnId; leaf VpnId { type uint32; leaf RouteDistinguisher { type uint64; leaf RouteTargetImport { type uint64; leaf RouteTargetExport { type uint64; leaf CEIdVeId { type uint32; leaf Attribute { type string; list SoamSubType { key MepId; leaf MepId { type uint32; leaf MdLevel { type uint8; leaf MdName { type string; leaf ManName { type string; leaf RemoteMepId { type uint32; leaf RemoteMdLevel { 66 CableLabs 06/25/15

67 type uint8; leaf RemoteMdName { type string; leaf RemoteManName { type string; container FaultMgmtConfig { leaf ContinuityCheck { type uint8; leaf Loopback { type uint8; leaf LinkTrace { type uint8; container PerformaceMgmtConfig { container FrameDelay { leaf FrameDelayMeasEnable { type boolean; leaf FDOneWayTwoWay { type boolean; leaf FDTransmissionPeriodicity { type uint32; container FrameLoss { leaf FrameLossMeasEnable { type boolean; leaf FLTransmissionPeriodicity { type uint32; 67 CableLabs 06/25/15

68 Open Networking 9.3 TPIA Data Model Figure 40 - TPIA Data Model YANG Model for TPIA module TPIA { namespace "urn:cablelabs:params:xml:ns:yang:sdn"; prefix TPIA; import ietf-yang-types { prefix yang; revision-date ; import DOCSISConfig{ prefix DOCSISConfig; revision-date ; organization "Cable Television Laboratories, Inc."; contact "Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle 68 CableLabs 06/25/15

69 Louisville, Colorado U.S.A. Phone: Fax: reference ""; revision { container TPIA { list TpiaCcap { key SubInterface Vlan; leaf SubInterface { type int32; leaf Vlan { type int32; uses DOCSISConfig:SubscriberMgmt-group; list PerSubscriberConfigParams { key PSMacAddress; leaf PSMacAddress { type yang:mac-address; leaf CmUsAqmDisable { type int32; leaf MacAddressLearningCtrl { type int32; uses DOCSISConfig:PacketClassifierEncodings-group; uses DOCSISConfig:DsServiceFlow-group; uses DOCSISConfig:UsServiceFlow-group; 69 CableLabs 06/25/15

70 Open Networking 9.4 Lawful Intercept Data Model Figure 41 - Lawful Intercept Data Model YANG Model for Lawful Intercept module DataLI { namespace "urn:cablelabs:params:xml:ns:yang:sdn"; prefix DataLI; import ietf-inet-types { prefix inet; revision-date ; organization "Cable Television Laboratories, Inc."; contact "Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado U.S.A. Phone: Fax: mibs@cablelabs.com"; reference ""; revision { typedef ethernet-protocol-id-type { type enumeration { enum other { value 1; 70 CableLabs 06/25/15

71 description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum none { value 2; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum ethertype { value 3; description "A value of 'ethertype' means that the rule applies only to frames that contain an EtherType value. Ethertype values are contained in packets using the DEC-Intel- Xerox (DIX) encapsulation or the [RFC 1042] Sub-Network Access Protocol (SNAP) encapsulation formats."; enum dsap { value 4; description "A value of 'dsap' means that the rule applies only to frames using the IEEE802.3 encapsulation format with a Destination Service Access Point (DSAP) other than 0xAA (which is reserved for SNAP)."; enum mac { value 5; description " A value of 'mac' means that the rule applies only to MAC management messages for MAC management messages."; enum all { value 6; description "A value of 'all' means that the rule matches all Ethernet frame. If the Ethernet frame contains an 802.1P/Q Tag header (i.e., EtherType 0x8100), this attribute applies to the embedded EtherType field within the 802.1p/Q header."; description "This enumerates the set of formats of the layer 3 protocol ID in the Ethernet frame."; container DataLI { list CMTSEnableDataLI { key LIid; leaf LIid { type uint32; leaf InterceptDuration { type uint32; leaf InterceptDuration2 { type uint32; choice MediationFunctionAddress { case MediationFunctionV4 { leaf MediationFunctionAddressV4 { type inet:ipv4-address; case MediationFunctionV6 { leaf MediationFunctionAddressV6 { type inet:ipv6-address; choice FlowDescriptor { 71 CableLabs 06/25/15

72 Open Networking case IPv4Tuple { leaf IPv4Source { type inet:ipv4-address; leaf IPv4Dest { type inet:ipv4-address; leaf IPv4SourcePort { type uint32; leaf IPv4DestPort { type uint32; leaf IPv4Protocol { type ethernet-protocol-id-type; case IPv6Tuple { leaf IPv6Source { type inet:ipv6-address; leaf IPv6Dest { type inet:ipv6-address; leaf IPv6SourcePort { type uint32; leaf IPv6DestPort { type uint32; leaf IPv6Protocol { type ethernet-protocol-id-type; leaf FlowLabel { type string; 72 CableLabs 06/25/15

73 9.5 Generic Flow Model (Northbound Data Model) The Generic Flow model is intended to reside between the application layer and the SDN controller. Generic Flow consists of common features that can be used across different access technologies. Generic Flow is made up of the following: Policy: This includes data rates (Min, Max, CIR), DSCP markings, Application ID (from PCMM), or this could translate to the Service Class Name Object in DOCSIS. IP Address Information (IP Flows): This could take the form of classifiers or IP source and destination addresses; destination addresses can be multicast addresses. A pattern for this might be to use the PktClass object from DOCSIS which contains L2, L3, and L4 classification elements. Service Chain Information: This might be represented as Opaque data that might be used in some of the Chaining decisions; e.g., Bearing traffic information (Video downstream/upstream, Voice, SIP signaling). Direction: Uni-directional flows need to account for direction. Also upstream flows have a different set of parameters than downstream flows (e.g., in DOCSIS). 73 CableLabs 06/25/15

74 Figure 42 - Generic Flow Data Model 74 CableLabs 06/25/15

75 9.5.1 YANG Model for Generic Flow Model module sdn { namespace "urn:cablelabs:params:xml:ns:yang:sdn"; prefix sdn; import ietf-inet-types { prefix inet; revision-date ; import ietf-yang-types { prefix yang; revision-date ; organization "Cable Television Laboratories, Inc."; contact "Postal: Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado U.S.A. Phone: Fax: mibs@cablelabs.com"; reference ""; revision { typedef octet-data-type { type string { pattern "([0-9a-fA-F]{2)*"; description "A derived type representing the lexical value space of XML Schema hexbinary defined as 'each binary octet is encoded as a character tuple, consisting of two hexadecimal digits ([0-9a-fA-F]) representing the octet code.' Please note that length constraints on this derived type needs to be in multiples of 2 to avoid conflicts between length and pattern space"; reference "[XML-Schema] hexbinary"; typedef ethernet-protocol-id-type { type enumeration { enum other { value 1; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum none { value 2; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum ethertype { value 3; description "A value of 'ethertype' means that the rule applies only to frames that contain an EtherType value. Ethertype values are contained in packets using the DEC-Intel- Xerox (DIX) encapsulation or the [RFC 1042] Sub-Network Access Protocol (SNAP) encapsulation formats."; enum dsap { value 4; description "A value of 'dsap' means that the rule applies only to frames using the IEEE802.3 encapsulation format with a Destination Service Access Point (DSAP) other than 0xAA (which is reserved for SNAP)."; enum mac { value 5; 75 CableLabs 06/25/15

76 Open Networking description " A value of 'mac' means that the rule applies only to MAC management messages for MAC management messages."; enum all { value 6; description "A value of 'all' means that the rule matches all Ethernet frame. If the Ethernet frame contains an 802.1P/Q Tag header (i.e., EtherType 0x8100), this attribute applies to the embedded EtherType field within the 802.1p/Q header."; description "This enumerates the set of formats of the layer 3 protocol ID in the Ethernet frame."; typedef enet-mode { type enumeration { enum other { value 1; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum enet-tagged-mode { value 2; enum enet-raw-mode { value 3; typedef encapsulation-type { type enumeration { enum other { value 1; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum ieee8021q { value 2; enum ieee8021ad { value 3; enum mplspw { value 4; enum ieee8021ah { value 5; typedef direction-type { type enumeration { enum other { value 1; description "The value of other is used when a vendor-extension has been implemented for this attribute."; enum up { value 2; enum down { value 3; enum bidir { value 4; 76 CableLabs 06/25/15

77 container sdn { list subscriberlist { key subscriber-id; leaf subscriber-id { type string { length "1..255"; leaf subscriber-name { type string { length "1..255"; leaf account { type string { length "1..255"; list service { key service-id; min-elements 1; leaf service-id { type uint16 { range " "; leaf service-name { type string { length "1..255"; list flow { key "flow-id"; leaf flow-id { type uint16 { range " "; leaf direction { type enumeration { enum upstream { value 1; enum downstream { value 2; leaf latency { type uint32; leaf dot1pbits { type ccap-octet-data-type { length "2..100"; leaf max-rate { type uint64; leaf min-rate { type uint64; 77 CableLabs 06/25/15

78 Open Networking list classifier-parameters { key "classifier-id"; min-elements 1; leaf classifier-id { type uint16 { range " "; leaf ip-tos-low { type ccap-octet-data-type { length "2"; default 00; description "This attribute represents the low value of a range of ToS (Type of Service) octet values. The IP ToS octet, as originally defined in [RFC 791], has been superseded by the 6-bit Differentiated Services Field (DSField, [RFC 3260]) and the 2-bit Explicit Congestion Notification Field (ECN field, [RFC 3168]). This attribute is defined as an 8-bit octet as per the DOCSIS Specification for packet classification. "; leaf ip-tos-high { type ccap-octet-data-type { length "2"; default 00; description "This attribute represents the high value of a range of ToS octet values. The IP ToS octet, as originally defined in [RFC 791], has been superseded by the 6- bit Differentiated Services Field (DSField, [RFC 3260]) and the 2-bit Explicit Congestion Notification Field (ECN field, [RFC 3168]). This attribute is defined as an 8-bit octet as per the DOCSIS Specification for packet classification. "; leaf dscp { type octet-data-type { length "2"; default 00; description "8 bit value: most significant 3 bits are priority, next 3 are drop classifier, last two are ECN."; leaf ip-tos-mask { type ccap-octet-data-type { length "2"; default 00; description "This attribute represents the mask value that is bitwise ANDed with ToS octet in an IP packet, and the resulting value is used for range checking of IpTosLow and IpTosHigh."; leaf ip-protocol { type uint16 { range "0..257"; default 256; description "This attribute represents the value of the IP Protocol field required for IP packets to match this rule. The value 256 matches traffic with any IP Protocol value. The value 257 by convention matches both TCP and UDP."; choice address-family { mandatory true; case ipv4 { container ipv4 { leaf source-ipv4-subnet { type inet:ipv4-prefix; mandatory true; description "This attribute specifies the value of the IP Source Address required for packets to match this rule and which bits of a packet's IP Source 78 CableLabs 06/25/15

79 Address are compared to match this rule. An IP packet matches the rule when the packet's IP Source Address bitwise ANDed with the mask value defined by the prefix equals the InetSrcAddr value. "; leaf dest-ipv4-subnet { type inet:ipv4-prefix; mandatory true; description "This attribute specifies the value of the IP Destination Address required for packets to match this rule and which bits of a packet's IP Source Address are compared to match this rule. An IP packet matches the rule when the packet's IP Destination Address bitwise ANDed with the mask value defined by the prefix equals the InetDestAddr value."; case ipv6 { container ipv6 { leaf source-ipv6-address { type inet:ipv6-prefix; mandatory true; description "This attribute specifies the value of the IP Source Address required for packets to match this rule and which bits of a packet's IP Source Address are compared to match this rule. An IP packet matches the rule when the packet's IP Source Address bitwise ANDed with the mask value defined by the prefix equals the InetSrcAddr value. "; leaf dest-ipv6-address { type inet:ipv6-prefix; mandatory true; description "This attribute specifies the value of the IP Destination Address required for packets to match this rule and which bits of a packet's IP Source Address are compared to match this rule. An IP packet matches the rule when the packet's IP Destination Address bitwise ANDed with the mask value defined by the prefix equals the InetDestAddr value."; leaf flow-label { type uint32 { range " "; default 0; description "This attribute represents the Flow Label field in the IPv6 header to be matched by the classifier. The value zero indicates that the Flow Label is not specified as part of the classifier and is not matched against packets."; leaf source-port-start { type inet:port-number; default 0; description "This attribute represents the low-end inclusive range of TCP/UDP source port numbers to which a packet is compared. This attribute is irrelevant for non- TCP/UDP IP packets."; leaf source-port-end { type inet:port-number; default 65535; description "This attribute represents the high-end inclusive range of TCP/UDP source port numbers to which a packet is compared. This attribute is irrelevant for non- TCP/UDP IP packets."; leaf destination-port-start { type inet:port-number; default 0; description "This attribute represents the low-end inclusive range of TCP/UDP destination port numbers to which a packet is compared. This attribute is irrelevant for non-tcp/udp IP packets."; 79 CableLabs 06/25/15

80 Open Networking leaf destination-port-end { type inet:port-number; default 65535; description "This attribute represents the high-end inclusive range of TCP/UDP destination port numbers to which a packet is compared. This attribute is irrelevant for non-tcp/udp IP packets."; leaf destination-mac-address { type yang:mac-address; default 00:00:00:00:00:00; description "This attribute represents the criteria to match against an Ethernet frame MAC address bitwise ANDed with DestMacMask."; leaf destination-mac-mask { type yang:mac-address; default 00:00:00:00:00:00; description "An Ethernet frame matches an entry when its destination MAC address bitwise ANDed with the DestMacMask attribute equals the value of the DestMacAddr attribute."; leaf source-mac-address { type yang:mac-address; default FF:FF:FF:FF:FF:FF; description "This attribute represents the value to match against an Ethernet frame source MAC address."; leaf ethernet-protocol-id { type ethernet-protocol-id-type; default none; description "This attribute indicates the format of the layer 3 protocol ID in the Ethernet frame."; leaf ethernet-protocol { type uint16; default 0; description "This attribute represents the Ethernet protocol type to be matched against the frames. For EnetProtocolType set to 'none', this attribute is ignored when considering whether a packet matches the current rule. If the attribute EnetProtocolType is 'ethertype', this attribute gives the 16-bit value of the EtherType that the packet needs to match in order to match the rule. If the attribute EnetProtocolType is 'dsap', the lower 8 bits of this attribute's value need to match the DSAP byte of the packet in order to match the rule. If the Ethernet frame contains an 802.1p/Q Tag header (i.e., EtherType 0x8100), this attribute applies to the embedded EtherType field within the 802.1p/Q header."; leaf user-priority-applies { type boolean; default false; leaf user-priority-low { type uint8 { range "0..7"; default 0; description "This attribute applies only to Ethernet frames using the 802.1p/Q tag header (indicated with EtherType 0x8100). Such frames include a 16-bit Tag that contains a 3-bit Priority field and a 12-bit VLAN number. Tagged Ethernet frames need to have a 3-bit Priority field within the range of PriLow to PriHigh in order to match this rule."; leaf user-priority-high { type uint8 { range "0..7"; default 7; description "This attribute applies only to Ethernet frames using the 802.1p/Q tag header (indicated with EtherType 0x8100). Such frames include a 16-bit Tag that contains a 3-bit Priority field and a 12-bit VLAN number. Tagged Ethernet frames need to have a 3-bit Priority field within the range of PriLow to PriHigh in order to match this rule."; leaf vlan-id { type uint16 { 80 CableLabs 06/25/15

81 range " "; default 0; description "This attribute applies only to Ethernet frames using the 802.1p/Q tag header. Tagged packets need to have a VLAN Identifier that matches the value in order to match the rule."; list tunnel-parameters { key "vlan-id"; leaf vlan-id { type uint32; leaf encapsulation { type encapsulation-type; leaf ethernet-mode { type enet-mode; container endpoints { choice address-family { mandatory true; case ipv4 { container ipv4-endpoints { leaf first-endpoint { mandatory true; type inet:ipv4-address; leaf second-endpoint { mandatory true; type inet:ipv4-address; case ipv6 { container ipv6-endpoints { leaf first-endpoint { mandatory true; type inet:ipv6-address; leaf second-endpoint { mandatory true; type inet:ipv6-address; case mac { container mac-endpoints { leaf first-endpoint { mandatory true; type inet:mac-address; leaf second-endpoint { mandatory true; type inet:mac-address; list cpe { key cpe-mac-address; min-elements 1; leaf cpe-mac-address { 81 CableLabs 06/25/15

82 Open Networking type yang:mac-address; description "The MAC address of the cpe."; leaf ipv4-address { type inet:ipv4-address; list ipv6 { key ipv6-address; leaf ipv6-address { type inet:ipv6-address; leaf device-type { type string { length "1..32"; leaf vendor-id { type ccap-octet-data-type { length "64"; list cpe-flow { key flow-id; min-elements 1; leaf flow-id { type leafref { path "../../../service/flow/flow-id"; 9.6 OpenDaylight PCMM Plug-in Data Model [PCMM] (currently in the ODL Lithium release) consists of thirteen modules and two features that will be pared down to a single feature during the next Beryllium release. The bundles included in feature set "featurespacketcable" that were originally built to leverage the OpenFlow modules will be deprecated. The bundles included in feature set "features-packetcable-policy" are fully functional and working as designed. This approach has been deemed the proper architecture for managing PCMM QoS, and this simplified model will be the best path to use for extension in the future. 82 CableLabs 06/25/15

83 9.6.1 Traffic Profile Data Model Figure 43 provides a graphical representation of the flow-model based PCMM plug-in data model. Figure 43 - Traffic Profile Data Model from Open Daylight SDN Controller PCMM Traffic Profile Data Model Figure 44 provides a graphical representation of the PCMM traffic profile data model. This diagram is also available here: 83 CableLabs 06/25/15

84 Figure 44 - PCMM Traffic Profile Data Model 84 CableLabs 06/25/15

85 9.6.3 OpenDaylight PCMM Plugin YANG Model module packetcable { namespace "urn:packetcable"; prefix "pcmm"; import ietf-yang-types { prefix yang; import ietf-inet-types { prefix inet; description "This module contains the PCMM Converged Cable Access Platform (CCAP) definitions"; organization "OpenDaylight Project"; revision { description "Initial revision of PCMM CCAP definitions"; // Global typedefs typedef service-class-name { type string { length "2..16"; description "The Service Class Name is MUST be 2-16 bytes."; typedef service-flow-direction { type enumeration { enum us { value "1"; description "Upstream service flow."; enum ds { value "2"; description "Downstream service flow."; description "This value represents the service flow direction."; typedef tp-protocol { type uint16 {range "0..257"; description "This value represents the IP transport protocol (or Next Header) where 256 is any protocol and 257 is TCP or UDP"; typedef tos-byte { type uint8; description "TOS/TC byte or mask"; // CCAP devices container ccap { list ccaps { description " CCAP devices are known by their network name which is any string. Each CCAP device has a network address:port, a list of subscriber IP subnets, and a list of available Service Class Names. "; key "ccapid"; leaf ccapid { type string; description "CCAP Identity"; uses ccap-attributes; grouping ccap-attributes { description " 85 CableLabs 06/25/15

86 Open Networking Each CCAP device has a COPS connection address:port, a list of subscriber IP subnets, and a list of available Service Class Names. "; container connection { leaf ipaddress { type inet:ip-address; description "IP Address of CCAP"; leaf port { type inet:port-number; description "COPS session TCP port number"; default 3918; container amid { leaf am-tag { type uint16; description "Application Manager Tag -- unique for this operator"; leaf am-type { type uint16; description "Application Manager Type -- unique for this AM tag"; leaf-list subscriber-subnets { type inet:ip-prefix; leaf-list upstream-scns { type service-class-name; leaf-list downstream-scns { type service-class-name; leaf response { type string; description "HTTP response from the PUT operation provided by the API"; // PCMM QoS Gates container qos { description " PCMM QoS Gates are organized as a tree by Application/Subscriber/Gate: Each Application is known by its appid which is any string. Each Subscriber is known by its subid which is a CPE IP address in either IPv4 or IPv6 format. Each Gate is known by its gateid which is any string. The subscriber's CPE IP address is used to locate the CCAP device that is currently hosting the the CM that is connected to the subscriber's device. Therefore, it is not necessary for the PCMM applications to know the topology of the CCAP devices and CMs in the network path to their subscriber devices. well as a list Note that each CCAP entry contains a list of connected subscriber IP subnets as of all Service Class Names (SCNs) available on the CCAP device. "; uses pcmm-qos-gates; grouping pcmm-qos-gates { list apps { key "appid"; leaf appid { type string; description "Application Identity"; 86 CableLabs 06/25/15

87 address"; list subs { key "subid"; leaf subid { type string; description "Subscriber Identity -- must be a CM or CPE IP list gates { key "gateid"; leaf gateid { type string; description "Qos Gate Identity"; uses pcmm-qos-gate-attributes; grouping pcmm-qos-gate-attributes { uses pcmm-qos-gate-spec; uses pcmm-qos-traffic-profile; uses pcmm-qos-classifier; uses pcmm-qos-ext-classifier; uses pcmm-qos-ipv6-classifier; leaf response { type string; description "HTTP response from the PUT operation provided by the API"; grouping pcmm-qos-gate-spec { container gate-spec { leaf direction { type service-flow-direction; description "Gate Direction (ignored for traffic profile SCN)"; leaf dscp-tos-overwrite { type tos-byte; description "Optional DSCP/TOS overwrite value"; leaf dscp-tos-mask { type tos-byte; description "Optional DSCP/TOS overwrite AND mask"; grouping pcmm-qos-traffic-profile { container traffic-profile { leaf service-class-name { type service-class-name; description "The Service Class Name (SCN). This SCN must be preprovisioned on the target CCAP"; grouping tp-port-match-ranges { leaf srcport-start { type inet:port-number; description "TCP/UDP source port range start."; leaf srcport-end { type inet:port-number; description "TCP/UDP source port range end."; leaf dstport-start { type inet:port-number; description "TCP/UDP destination port range start."; 87 CableLabs 06/25/15

88 Open Networking leaf dstport-end { type inet:port-number; description "TCP/UDP destination port range end."; grouping pcmm-qos-classifier { container classifier { leaf srcip { type inet:ipv4-address; description "Source IPv4 address (exact match)"; leaf dstip { type inet:ipv4-address; description "Destination IPv4 address (exact match)"; leaf tos-byte { type tos-byte; description "TOS/DSCP match"; leaf tos-mask { type tos-byte; description "TOS/DSCP mask"; leaf protocol { type tp-protocol; description "IPv4 transport protocol"; leaf srcport { type inet:port-number; description "TCP/UDP source port (exact match)."; leaf dstport { type inet:port-number; description "TCP/UDP destination port (exact match)."; grouping pcmm-qos-ext-classifier { container ext-classifier { leaf srcip { type inet:ipv4-address; description "Source IPv4 address match"; leaf srcipmask { type inet:ipv4-address; description "Source IPv4 mask"; leaf dstip { type inet:ipv4-address; description "Destination IPv4 address match"; leaf dstipmask { type inet:ipv4-address; description "Destination IPv4 mask"; leaf tos-byte { type tos-byte; description "TOS/DSCP match"; leaf tos-mask { type tos-byte; description "TOS/DSCP mask"; leaf protocol { type tp-protocol; description "IPv4 transport protocol"; uses tp-port-match-ranges; 88 CableLabs 06/25/15

89 grouping pcmm-qos-ipv6-classifier { container ipv6-classifier { leaf srcip6 { type inet:ipv6-prefix; description "Source IPv6 prefix match in <address/len> notation"; leaf dstip6 { type inet:ipv6-prefix; description "Destination IPv6 prefix match in <address/len> notation"; leaf tc-low { type tos-byte; description "TC low range match"; leaf tc-high { type tos-byte; description "TC high range match"; leaf tc-mask { type tos-byte; description "TC mask"; leaf next-hdr { type tp-protocol; description "IPv6 Next Header"; leaf flow-label { type uint32 { range " "; description "IPv6 Flow Label (20 bits)"; uses tp-port-match-ranges; 89 CableLabs 06/25/15

90 Open Networking 10 NORTHBOUND AND SOUTHBOUND PROTOCOLS There are many protocols that facilitate communication between an SDN controller to the application and to the underlying network element, e.g., CMTS, CCAP, etc. To simplify SDN controller implementation there is a desire to standardize on one or two applicable communication mechanisms. In this section, each individual protocol is summarized in terms of its current applicability, strengths, and weaknesses. At the end of this section, a recommendation is presented that accommodates both the current usage and also future development in light of SDN and NFV adoption in the networking industry PCMM Packet Cable Multimedia (PCMM) was considered a mechanism for the southbound protocol from the SDN controller to the network elements or to the CMA. PCMM is currently implemented on all CMTS platforms, and a simple extension is needed to transport data from the SDN controller to network elements or to the CMA. While PCMM would work on the DOCSIS network, it has a few disadvantages. The Common Open Policy Service (COPS) protocol used in PCMM is only available on the DOCSIS network and not adopted by other network elements such as switches or routers. Thus its deployment will depend on a wider adoption of the protocol within the industry NETCONF NETCONF protocol (see [RFC 6241]) provides mechanisms to install, manipulate, and delete configuration of network devices. It is designed to reduce programing effort involved in automating device configuration. NETCONF is based on secure transport and uses Extensible Markup Language (XML) based data encoding for configuration and state data as well as for protocol messages. The choice of data model language is independent. YANG (see [RFC 6020]) is a recommended NETCONF modeling language, which introduces advanced language features for configuration management. NETCONF provides mechanisms for multi-action transaction management and two-phase commit. The NETCONF protocol is based on a Remote Procedure Call (RPC) model. The base protocol specifies a set of RPCs that clients invoke to manipulate configuration data stores e.g., get-config, edit-config, copy-config, etc. The data modules implemented by the managed device specify additional RPCs that can be used by clients to manipulate specific device configuration and state data. The RPCs applicable to each data module are specified as part of the YANG definition of the module. The advantage of NETCONF is that it supports a robust configuration change transaction involving a number of devices, and NETCONF is already implemented in network devices such as routers and switches by some major equipment vendors XMPP The Extensible Messaging and Presence Protocol (XMPP) [RFC 6120] is an open source technology for real-time communication, using XML as the base format for exchanging information. In essence, XMPP provides a way to send small pieces of XML from one entity to another in close to real time. XMPP is used in instant messages, group chat, and social networking applications. Currently, there is no known implementation of XMPP in the cable infrastructure domain REST (RESTful API) Representational State Transfer (REST) [Fielding-2000] is a client-server based protocol providing a stateless, cacheable, and redundant system with a uniform interface for exposing data resources directly to clients. Web services that comply with all of the above conditions are considered RESTful. REST interfaces are modeled on the CREATE, READ, UPDATE, and DELETE (CRUD) storage functions and implement them utilizing the HTTP transport protocol methods of POST, GET, PUT, and DELETE. Other HTTP 90 CableLabs 06/25/15

91 methods such as OPTIONS/PATCH/HEAD can also be supported. REST is a set of pull-based interface principles, layered on top of the HTTP communication standard. It inherits the requirements and limitations of HTTP but is loose in how the HTTP mechanisms apply to data resources. REST doesn't have a native notification mechanism so most developers layer in WebSockets, Server-Sent Events or Long-Polling for asynchronous client-notification support. Authorizations for RESTful transactions are typically done either using Http Basic Auth, OAuth or a shared predefined key. Since this information is passed in an unsecured manner, it is recommended that REST interfaces always are connected via SSL (HTTPS). Procedure calls follow a typical URL pattern of host, port, resource and HTTP method, followed by an optional data body typically carrying either an XML or JSON datagram when required. URL encoding of parameters is also seen frequently in lieu of a datagram, typically in relation to GET and PUT methods. The major advantage of a REST API is platform independence. Since all communications are via HTTP leveraging the web services infrastructure, RPC calls are machine independent and data formats are well defined, especially when using either XML or JSON. REST APIs are also easy to expose to Web Browser AJAX calls so are often seen in the context of an Internet Single-Page Application. REST APIs also make good translation layer APIs bridging system, language or solution specific programming interfaces and granting access to those interfaces via a universally accessible front end. Drawbacks of the REST model include a lack of consistency in implementations. Since there is no standard, each solution that offers a REST API can have specific and unique usage requirements that force the consumer to develop custom interfaces for each supported API. This can lead to confusion in terminology, usage, and implementation and careful analysis of the particular REST API documentation is required RESTCONF RESTCONF (see [RESTCONF]) is an HTTP based protocol used to access the data defined in YANG models using the concepts defined in NETCONF. It also uses and inherits many of the benefits of a RESTful interface but requires a higher level of uniformity in implementation. RESTCONF provides a simple subset of NETCONF functionality and designed to co-exists and be compatible with NETCONF. RESTCONF supports both XML and JSON for data type encoding. RESTCONF relies on Transport Layer Security (TLS) to provide privacy and data integrity between the two communication endpoints. RESTCONF is currently an IETF draft. Similar to RESTful API, RESTCONF uses CRUD operations on YANG defined models via the HTTP verbs: OPTIONS, HEAD, GET, POST, PUT, and DELETE. RESTCONF also integrates HTML5 Server-Sent Events for asynchronous notifications to clients. The RESTful interface implemented by RESTCONF contrasts to the RPC-based method of NETCONF. The RESTCONF protocol operates on a hierarchy of resources, each of which represents a manageable component within the device. RESTCONF resources are accessed via well-defined URIs and the HTTP methods mentioned above. For example, a NETCONF <get-config> RPC operation is implemented with a RESTCONF HTTP GET method and a NETCONF <edit-config> operation=create RPC operation is implemented with a RESTCONF HTTP POST operation. For compatibility with YANG managed data modules that export application-specific RPC actions for NETCONF, RESTCONF supports use of the HTTP POST method to invoke those RPC calls. RESTCONF significantly reduces the transaction complexity of NETCONF. Each action on a resource is assumed to commit automatically on successful application and RESTCONF removes the option of two-phase commit. These simplifications make a RESTCONF based interface much easier to develop against, often leading to an increased "feature velocity". In addition, RESTCONF leverages wide pool of developers familiar with the RESTful web-client development model and the rich toolset available for developing and debugging HTTP-based applications. RESTCONF is currently supported by ODL but not yet exposed as a southbound plug-in/protocol. 91 CableLabs 06/25/15

92 Open Networking 10.6 WebSockets The WebSocket protocol, [RFC 6120], is a TCP-based data transport protocol that leverages the web services infrastructure of HTTP. It is designed to create a duplex data stream between two remote systems over an HTTP proxy. The sequence begins as an HTTP upgrade request, which specifies a new URL schema (ws:// or wss://) and finalizes the web socket connection. Data transmission can be text or binary based. The message format is not specified in the RFC, although there is support at the protocol layer for a number of sub-protocols. WebSockets also provides for extensibility. Two extensions have been formally defined: encryption and multiplexing. The advantage of a WebSockets solution is that it can leverage the existing web services infrastructure on the network and therefore does not require a lot of custom overhead. Web sockets address the longstanding issue with HTTP/HTML being a transactional interface with no persistent interface. All major browsers support web socket interfaces today. Drawbacks of the WebSockets implementation include a heavier server load as the server needs to maintain open connections to its clients, an un-optimized data path bolted on top of HTTP infrastructure, and older web proxies that fail to handle the protocol correctly. Tunneling overcomes the failure of web proxies to adequately handle the WebSockets data stream, and the server load can be resolved with load balancing and more powerful hardware Recommendations for Southbound Protocols The SDN controller can support multiple southbound protocols which can communicate to various types of network devices that support different protocols. The main usage of these protocols is for Service Orchestration and Provisioning One Protocol versus Multiple Protocols An MSO has the option of choosing a single protocol or multiple protocols for southbound communication needs, from the SDN controller to the CMTS, CMA, or other network equipment. MSOs would like to pick a single protocol which works to communicate across majority of devices in the MSO network. The group has general consensus around HTTP based protocols Static Configuration versus Dynamic Configuration Interactions between the SDN controller and the CCAP device can be thought of in two ways: persistent configuration and Transactional configuration. The persistent configuration doesn't need to change often (e.g., CMTS device configuration) while the transactional configurations (e.g., QoS for gaming or voice sessions) are more ephemeral in nature and need a lighter weight protocol. NETCONF, considered best for static or persistent configurations, is also known as Day0 configuration, because it gives a higher level of control over transaction-level concerns. RESTCONF should be used for more dynamic configuration needs as it simplifies the SDN controller code-base by removing transaction-level concerns. Table 10 - Southbound Protocols Transport Protocols Data Format Usage Model NETCONF YANG Day 0 Configuration RESTful API JSON, XML Day 1 Configuration RESTCONF XML-YANG, JSON-YANG Day 1 Configuration 92 CableLabs 06/25/15

93 Data Consistency Data consistency may be an issue when a device is written to by multiple protocols, which all have access to the same configuration item. Some of the considerations here are: 1. Allow access based on time/state domain. For example, allow NETCONF for initial setup and RESTCONF for the remainder of the running session. 2. Allow access based on device. For instance, legacy devices can use PCMM while new devices can use NETCONF/RESTCONF. 3. Allow access based on functionality. In this manner, data models and data elements are partitioned into several access groups for respective protocols. This seems to be a preferred approach among vendors and MSOs as it is in line with current configuration needs. To summarize, during the initial setup stage, the recommendation is to use NETCONF for bulk configuration. Once the device is in its running state, RESTCONF is used for dynamic configuration of services. The options above do not totally mitigate the multiple access issue. Yet, by combining time-wise segregation and functional segregation, one can reach a reasonable solution for this. In addition, multiple access to the same data element is not a new situation in current practice, thus vendors need to consider a each particular use case and construct appropriate solutions. 93 CableLabs 06/25/15

94 Open Networking 11 SERVICE FUNCTION CHAINING 11.1 SFC Architecture The term service function chaining (SFC) has emerged to describe the deployment of an aggregate of services that are applied to a specific customer's traffic. SFC uses both Software Defined Networking (SDN) and Network Function Virtualization (NFV) paradigms. Service Function Chaining provides the ability to define an ordered list of a network services (e.g., firewalls, load balancers). These service are then linked together in the network to create a service chain. Service Function Chaining allows operators to provide additional services to customers. It defines the needed data path manipulation to route the traffic through the Service Functions which are implemented in the network. Services such as firewall and parental control, which are embedded in the home router and managed by the customer, can now reside in the MSO network and be managed by the MSO. Other services such as video optimizer or carriergrade NAT (CGN) can be implemented as a service on the network path. A service chain is essentially a policy construct: a series of service functions that a customer packet must traverse. For example, a service chain may define that all TCP port 80 traffic must pass through a firewall (FW), then intrusion prevention (IPS), and finally server load balancing (SLB). Figure 45 - SFC and the DOCSIS Network SDN technology can intelligently chain service functions, so that traffic from each subscriber only traverses a particular set of service functions as defined by the policy for that particular subscriber. One can apply service chaining policies to operator/user defined services. For example, an operator can configure a service chaining policy such that only web traffic is sent to a content optimization service. The solution can be integrated with a management and orchestration system to simplify configuration and management of service chains the traffic path for any arbitrary flow can be dynamically changed by simply changing the policy associated with that flow the SDN controller automatically programs routers, switches and application servers in the network. Using the capability to selectively steer certain portions of the network traffic to a specific set of services provides operators the benefit of optimally utilizing compute and network resources, thereby relieving them from having to continuously overprovision service-function capacity. 94 CableLabs 06/25/15

95 With the use of open interfaces and an open platform, service providers can now benefit from and contribute to the rapid pace of innovation in the SDN ecosystem and count on unparalleled multi-vendor interoperability in a service provider network. The service function chaining technology also allows service providers to rapidly introduce and scale services Service Chaining Setup through Network Service Header (NSH) Existing models used for the insertion of services suffer from a number of limitations. Today, the required service functions that must be applied to traffic for a given service are physically inserted on the data-forwarding path between communicating peers, and traffic is directed through them using VLANs and policy-based routing techniques. Consequently, services are coupled to the physical network topology creating constraints on service delivery and potentially inhibiting the network operator from optimally utilizing their service resources. New application deployment or the addition of new services into the network is constrained, and this practice limits scale, capacity, and redundancy. If the necessary service functions are not available to support a new application, then the network operator has no other option but to deploy additional hardware resources or reconfigure the network to accommodate the new service requirements. Furthermore, services are not easily moved, created or removed, even when virtualized service functions are deployed. This rigidity is the antithesis of highly elastic service environments that require rapid creation, destruction or movement of the service functions required for application delivery. Additionally, the transition to virtual platforms requires an agile service insertion model that supports elastic and very granular service insertion, and postfacto modification; that is, supports the movement of service functions and application workloads in the existing network, all while retaining the network and service policies and the ability to easily bind service policy to granular network-centric identifiers such as per-subscriber/per-tenant/per-vpn state. These factors provide strong motivation for a simplified and flexible service insertion model that optimizes the use of existing service resources, by allowing them to be shared and accessed in a manner that is completely independent of the underlying physical and routing topology of the network, while still being controlled by operatorspecified policy. This may be realized by moving to a model where the functions involved in the delivery of a service are not required to reside on the default data path and specific traffic is instead steered through them, wherever they are deployed. This form of service deployment is commonly referred to as service chaining. Service chaining, using Network Service Headers (NSH), builds on an overlay-only service chain and addresses the shortcomings encountered with existing service deployment models. A fundamental principle is the notion that each service function within a given network domain is an independent resource that may be utilized. Therefore, the concept of a service function evolves: rather than being viewed as a bump in the wire, each service function becomes a resource within a specified administrative domain that is available for consumption. As such, service functions have a network locator and a variable set of attributes that describe the function offered. The combination of locator and attributes is used to construct a service chain, and, as with the overlay-based model, instantiation of the chain into the network is achieved using a service path that provides the overlay topology. NSH provides a consistent model for the sharing of information and context between network nodes and between service functions. NSH effectively creates a service plane by decoupling service chaining from the underlying network infrastructure, and enables the construction of complex service chains and the ability to carry additional metadata in the data plane. NSH headers are designed to be easily implementable across a range of network devices, both physical and virtual, including hardware-forwarding elements. Because service functions can and will be deployed in networks with a range of transport encapsulations, including under and overlays, NSH headers are designed to be carried between the transport encapsulation and the original packet payload. The NSH is added by a service classification function a device or application. The classification function determines which packets require servicing, and correspondingly which service path to follow to apply the service functions for the associated service chain. NSH creates a dedicated service plane that addresses many of the limitations of existing service chaining technology previously highlighted. More specifically, NSH enables: 95 CableLabs 06/25/15

96 Open Networking 1. Topological Independence: Service forwarding occurs within the service plane via a network overlay, and therefore the underlying network topology does not require modification. Service functions have a locator (e.g., IP address), to receive/send data within the service plane; the NSH contains an identifier that is used to uniquely identify a service chain, and the service functions within that service chain. 2. Service Chaining: NSH contains path information needed to create a service chain. Furthermore, NSH provides the ability to monitor and troubleshoot a service chain, end-to-end via service-specific OAM messages. Service chain information can be used by administrators (via a traffic analyzer, for example) for verification (account, ensure correct chaining, provide reports, etc.) of the service chain specifics of packets being forwarded along a service chain. 3. Metadata Sharing: NSH provides a mechanism to carry shared metadata between service functions, and between network devices and service functions. The semantics of the shared metadata is communicated via a control plane to participating nodes. Examples of metadata include classification information used for policy enforcement and network context for forwarding post-services. 4. Transport Agnostic: NSH is transport independent and can be used with overlay and underlay forwarding topologies SFC Implementation in a DOCSIS Network This section describes the different points within the home and the DOCSIS network in which SFC packet marking can start. The problem statement is to figure out what is needed on the DOCSIS Network (CM/CMTS) to enable Service Function Chaining / Marking of traffic flows, as it crosses the Service Function Edge to the SFC domain Figure 46 -Traffic Flows from DOCSIS Network through Different Service Chains The starting points where the traffic is classified and marked may differ as described below but the end point is the same, as all traffic destined for the SFC domain will end at the SFC edge, as shown in Figure CableLabs 06/25/15

97 Figure 47 - Different Starting Point of SFC SFC Initiating from Application An application can initiate SFC directly. This option is the most granular and most accurate when it comes to selecting a service chain because there is no second-guessing as to what the application needs. The downside is, of course, that it requires changes to the application software and the host OS it is utilizing. The application can be the starting point on the SFC. There are two methods from the application. The first is the overlay method which creates a tunnel (or a virtualconnection) from the application to the SFC edge. In this scenario, everything from the application would be sent to the SFC. The DOCSIS network would not be aware of the application contents and there would be no classification done on the DOCSIS Network (CM/CMTS). This method would not work if the application needed to leverage the DOCSIS QoS mechanism or QoS mechanism from the CMTS to the SFC edge. The second scenario is to mark the application so that the DOCSIS network and core network is aware. An example of this would be an MSO-provided VoIP service. The application would mark the traffic so that proper QoS could be applied on the DOCSIS network, and from the NSI side of CMTS to the SFC edge. Other MSO-provided applications, such as Video On Demand or home security, can leverage the QoS mechanism on DOCSIS and the rest of the network SFC Initiating from Home Gateway The home gateway is part of the home network and, while it might not have the ability to explicitly tag flows based on applications, it still has good visibility into information, such as the type of devices in the home and some information related to identify the user, for example, by using Wi-Fi authentication. Using this information, it should be relatively easy to tag different flows with different SFCs; for example, devices that are defined as kid devices can be tagged with SFC that requires parental control while parent devices can skip it. In the context of a home gateway, it s important not to confuse a tunnel that the home gateway might initiate with SFC. The two concepts are unrelated. A tunneling option from the home would be to use an overlay technique such as VXLAN or GRE tunnel from the gateway to the SFC edge SFC Initiating from CM Initiating SFC from the CM is not a desirable option. Implementing SFC in the CM would not scale and there is no added value. The SFC Marking functionality that can be done on the CM can also be done on the CMTS (as described in Section ). From a granularity and feature point of view, it does not offer advantages over the CCAP/CMTS initiated SFC as described in the next section SFC Initiating from CCAP/CMTS It is fairly straightforward to associate DOCSIS upstream service flows with SFC from a data plane processing point of view. Having said that, one has to remember that service flows and service chains are different (and also unrelated to tunnels as mentioned in Section ). A DOCSIS service flow is a traffic lane that may or may not 97 CableLabs 06/25/15

98 Open Networking be associated with a particular application. It is possible to tag traffic such that different applications have different service flows that map to corresponding SFC. However, one should be careful not to create an inflation of service flows as a result. It is better to use service flows to create a coarse separation of traffic; for example, video versus data versus voice, that can serve as a hint for further analysis in case it is needed (see Section ). On the downstream side, the CMTS terminates a service chain. One can view the QoS that the CMTS applies as the end of the service that SFC defines; however, the CMTS would still use packet classification rules rather than inspecting the SFC header directly in order to do that. As a future extension, that CMTS can inspect SFC headers directly SFC Initiating from a Proxy Behind CCAP A proxy behind CCAP, a device such as a DPI appliance (physical or virtual), can analyze packet streams and dynamically assign SFC based on the inspected traffic. The upstream classification to DOCSIS service flows can serve as a hint to the appliance. Most importantly, if the tagging is applied correctly, some flows can skip the appliance altogether, resulting in a simpler and less expensive inspection device. For example, a home surveillance camera with a dedicated service flow can be directed immediately to the correct SFC Recommendation In the short term, initiating the SFC from an external device seems the easiest since it has no dependencies on existing equipment. The next phase would be initiating SFC from the CMTS, since this is a cost-effective solution relative to changing home gateways or CM. SFC from the home gateway seems to be an in-between solution, not being as cost-effective as the former solutions but not being as granular as the application initiated SFC. Each starting point has pros and cons. The application starting point is very granular and there is doubt about whether the traffic should go through the SFC domain or not. Starting SFC from the application is useful when the operator has full control over the application. The downside to this method is that it is limited at this point; however, as MSOs start to expand into the home network, using an overlay technique may be the easiest to implement. Unfortunately, it does not take full advantage of the DOCSIS network and the rest of the MSO s network. Further research is needed where the applications leverage the DOCSIS and the core network, not the preferred network. As stated before, starting from the CM doesn t scale. Legacy CMs might not support it, and using it does not offer any advantages. Finally, a combination of using the home gateway and the CMTS might be the best option available right now. More research is needed to identify what is needed between the home gateway and the CMTS, but this option allows SFC to take advantage of the DOCSIS network and the core network. 98 CableLabs 06/25/15

99 12 DOCSIS 3.1 PROFILE MANAGEMENT APPLICATION 12.1 Introduction The SDN controller will implement a common set of protocols to talk with different network devices. This allows the MSO to start focusing on creating better services that run as applications above the SDN controller and let the controller configure or program each network device appropriately. There are two kinds of applications that an MSO can create and deploy: Applications that provide service to the end customer; Applications that provide network services to the MSO. DOCSS 3.1 Profile Management belongs to the second class of applications that can be enabled by an SDN infrastructure and is the focus of this section. There are many DOCSIS features that are part of the CMTS but not directly tied to the DOCSIS protocol. DOCSIS 3.1 introduced many new features into the access network, including variable bit loading across a channel and the use of multiple modulations profiles for downstream and upstream channels, and upstream probes to check the quality of the upstream OFDMA signal. The configuration, initiation logic and compute processing needed to optimize some of these functions (e.g., downstream profile setup or load balancing of CMs) are not an intrinsic part of the DOCSIS MAC and PHY layers. This allows the functionality to be moved out of a CMTS and implemented as an application running outside the CMTS. This application can communicate with the CMTS or the CMs to gather the needed information, process the data, and make intelligent decisions to set up the CMTS as needed. The various applications implemented externally communicate with the CMTS to optimize the overall network performance. To realize this profile management application, the basic steps are to develop the data models and a protocol to convey that information back and forth. The new physical layer described in [PHYv3.1] allows each subcarrier in a channel to use a different modulation order, organized as a "modulation profile". A well-designed, optimized set of modulation profiles allows a channel to operate with a lower SNR margin, potentially allowing a channel to operate at an overall higher throughput. The application that implements this optimization logic can be external to a CMTS, enabling the most efficient use of profiles across channels and CMs. For an operator, it also allows uniform operation of such algorithms across different CMTS platforms. This approach fits the architecture we have developed in this technical report. An SDN controller supporting the appropriate data models to represent the information needed, and supporting the appropriate southbound protocols to configure a CMTS will be a prerequisite. Also, the SDN controller through a Northbound API will expose the needed functionality to communicate with the DOCSIS network to the Profile Management application Problem Description Background DOCSIS 3.1 introduced the concept of modulation profiles for OFDM channels. A modulation profile is a list of modulation orders, defined for each subcarrier within a channel. A CMTS can define multiple modulation profiles for use on a channel, where the profiles differ in the modulation orders assigned to each subcarrier. A CMTS can assign different downstream and upstream modulation profiles for different groups of CMs. 99 CableLabs 06/25/15

100 Open Networking Figure 48 - DOCSIS 3.1 Downstream OFDM Channel Problem Statement and Goals Determining the best modulation profile to use on a channel is difficult, given the number of CMs and the differences in signal quality that they experience. The Profile Management Application (PMA) is designed to help operators determine what the best modulation profiles are for each channel, given the channel characteristics seen by each CM on the network. Currently the focus is only on downstream modulation profiles; upstream profiles will be considered at a later time. The goal of changing profiles is mainly to: Increase throughput per CM Maximize network capacity Minimize errors The tasks an external Profile Management Application (PMA) will perform are as follows: 1. Create a set of optimized modulation profiles for use on a channel by selecting the best modulation order for each subcarrier based on the channel quality measured at the CMs using the channel profile test. (For all CMs) 2. For a new CM and periodically, find the best fit among existing modulation profiles and recommend modulation profile usage. (Per CM) 3. Create backup profiles or downgrade a CM based on errors on a certain profile. For example, based on CM performance and SNR margin, provide a better modulation profile for a CM. (Per CM) The application will make suggestions for the above three steps, but it is the CMTS s responsibility to actually implement the changes on the DOCSIS network. The PMA could also be responsible for figuring how and when to roll out profile changes, in accordance with MSO policy, but ultimate control remains with the CMTS. In the future, we can also envision the possibility that the PMA will be responsible and maintain control of how all the profiles are actively managed. An additional use case to consider is how to determine CMTS profiles to CM population mapping to optimize network capacity. 100 CableLabs 06/25/15

101 High Level Architecture This following network entities are depicted in the high-level architecture shown in Figure 49 below: Profile Mangement Application (PMA): Responsible for gathering the data it needs to make profile decisions. It interacts with the CMTS through the SDN controller to initiate modulation profile tests, provide new or optimized modulation profiles, and provide suggestions or commands to use these modulation profiles. SDN Controller: Mediation/Network Control layer between the applications and the DOCSIS network devices (CMTSs and CMs). Responsible for exposing the profile information from the CMTS/CMs and the profile actions available to the PMA. Also responsible for implementing the communitcation protocols to configure the DOCSIS devices and receive information from the network. CMTS: Responsible for assigning CMs to use a given modulation profile based either on internal logic or commands originating from the PMA. Source of data for the PMA on network conditions, current configuration, and outcomes of modulation profile testing. CMs: Use the modulation profile specified by the CMTS. Act as a source of channel quality data for the PMA. Figure 49 - Possible Composition of the Profile Management Application At a high level, the PMA makes requests of the CMTS to get information from the CMTS, which in turn sends out MAC Management Messages (MMMs) to the CMs to collect the needed information and send it back to the PMA. The PMA also makes recommendations on the profiles to the CMTS, which the CMTS configures CMs to use at an appropriate time Areas of Focus The primary areas of focus in developing the PMA are: Define PMA actions, that is, work that is done by the PMA to determine the set of modulation profiles that provides the best overall throughput on a channel. Information needed by the PMA to analyze channel conditions across the CMs and perform its functions. The secondary areas of focus are: How to get the needed information How to effect the changes from PMA on CMTS How to monitor the effect of changes on a CMTS 101 CableLabs 06/25/15

102 Open Networking 12.3 PMA Use Cases The current assumption for the PMA is a pull model, where the PMA has to explicitly query the CMTS or the CMs (or ask the SDN controller to make the query) in order to get the information it needs. A push model might be better. In other words, the CMTS is expected to inform the PMA (or tell the SDN controller which tells the PMA) whenever something changes, e.g., when a channel comes up or goes down, when CMs arrive or leave, when CM statistics are updated, when some sort of high error rate condition is flagged, and so forth. This may prove to be easier on the CMTS. With the pull model, the PMA must constantly query the CMTS to find out if anything has changed, and the CMTS has to keep responding to the same queries over and over even if everything is the same. In contrast, the push model means the CMTS mostly sends out information only when something has changed Case 1: New Channel Startup The new channel startup case (e.g., on initial deployment), is when the allocated spectrum is changing or when OCD parameters have been changed. Here the CMTS is just starting up the channel and so the channel has no CMs on it. At this point no transmissions are taking place, as the system is just initializing. (Note: this is not the only way to start up a channel.) CMTS requests a set of new profiles for the new channel. PMA requests information from CMTS: Requests OCD parameters (including configuration about excluded bands), Requests list of profiles active on the channel and CMs assigned to each channel; there will be none, so no further information needs to be requested. PMA may get other information from places other than the CMTS: E.g., it may have previous history for this plant segment/frequency range from DOCSIS 3.0 channels/cms that have used it, Or from an earlier DOCSIS 3.1 channel, Or from PNM metrics such as spectrum captures gathered from other devices using other frequencies on the plant. PMA responds to the CMTS request with a list of profiles to be used as a starting point for the new channel: Since there are no CMs on the channel, no profile assignments to CMs are sent Case 2: Profile Optimization After completion of Case 1, the CMTS distributes DPDs and CMs begin to join the channel. The CMTS will assign each CM a set of profiles on its own, as the PMA initially would probably be too slow to be in the CM initialization/startup path. At this point, data can be gathered from and about the devices actually using the channel. After some period of time, it would be desirable to have the current set of profiles analyzed to see if it can/should be optimized to better match the conditions affecting devices actually present. There are two ways to work this under the pull model, as described below CMTS Initiated The CMTS may initiate profile optimization because (a) an operator manually instructs the CMTS to do so, or (b) the CMTS has some sort of internal metrics that trigger a request for profiles to be optimized. For example, a certain time period has elapsed, a certain number of new CMs have joined and/or old CMs have left, relative utilization of profiles has gotten unbalanced past a certain point (e.g., some profiles largely unused), and so forth PMA Initiated The advantage of the PMA initiating profile optimization is that the CMTS would not have to include any sort of internal metrics to trigger a request. Instead, the PMA would monitor items such as those described in Section and decide when optimization is in order. Put another way, the PMA s job would be not only to calculate optimized profiles, but also to determine when optimization should be considered. This seems like a logical thing to ask the PMA to do rather than the CMTS. 102 CableLabs 06/25/15

103 A downside of this is that with a pull model, the PMA must frequently query the CMTS (say every 1 minute or 15 minutes or up to once an hour) for a list of profiles and assigned CMs. This is an example of a case where a push model would be lighter-weight whenever a new CM joins, the CMTS sends information about it, and if no new CMs have joined, it doesn t have to constantly answer queries about it. With either model, the PMA would probably want traffic statistics at frequent intervals (say tenths of seconds to a minute) and it would want to keep a history of these statistics. However, this is probably already being monitored by an NMS, so the PMA most likely could get it from there Steps to Optimize the Profile(s) For option 1, CMTS Initiated: The CMTS sends a request to the PMA for optimization of profiles for the channel. For option 2, PMA Initiated, the above step is skipped. Instead, the PMA decides it is going to do an optimization without any explicit message to that effect. Everything else is the same. Using the pull model, the PMA requests the information it needs to ensure that its data is current: The PMA requests OCD parameters; the CMTS responds with this information. The PMA requests list of profiles and CMs assigned to each; the CMTS responds with this information. The PMA requests DPD information for each profile; the CMTS responds with this information. The PMA requests OCD information from each active CM; this could either be requested from the CMTS or from the CMs directly. The PMA may want other CM performance-related information; e.g., FEC statistics, packet counts (total/errored), etc. Perhaps it could get this from the CM or from the NMS. The PMA may want profile traffic statistics (e.g., transmitted byte counts) these might also come from the NMS. After gathering all this information, the PMA comes up with a list of profiles and a list of CMs to be assigned to each profile. Now the PMA is expected to manage the process of changing over to the new profiles. Most likely it (and the operator) will want some amount of profile testing done prior to switching over to the new profiles. So the PMA may perform these steps: If all 16 profiles on a CMTS are already in use, the PMA will first have to free up some profiles so that they can be configured for testing. The PMA will tell the CMTS to move CMs off of a few profiles. The PMA sends the CMTS a list of profile assignments for certain CMs to move all CMs away from profiles that are to be decommissioned. Once all CMs are moved, the PMA tells the CMTS to delete the now-unused profile(s). NOTE: In DOCSIS there isn t a formal way to delete a profile. However, once no CMs are using a profile, its DPDs can disappear. Or, if the PMA is going to start using these profiles for something else right away, it could just tell the CMTS to do a DPD change. Either way, the PMA tells the CMTS to add a new profile or to change a currently unused profile to be one of the new profiles it wants to test. The PMA tells CMTS to perform OPT testing on the new profile with a CM or CMs that it expects will be able to use the new profile. If the testing is successful, the PMA tells CMTS to assign the profile to the CM and goes on to the next CM. Once all desired CMs have been moved to the first new profile, the PMA can repeat this process for subsequent profiles, until all CMs have been moved. 103 CableLabs 06/25/15

104 Open Networking If at any point problems are encountered, the PMA will alter its plan as needed. For example, if a particular CM doesn t perform well enough in the profile (OPT) tests (too many FEC errors or whatever), the PMA may decide that it will instead move that CM to a lower or different new profile. This could even be part of the strategy; run profile tests on a profile which is optimistic for the CM in question, and see if it works. Recall that profile tests (OPTs) will typically take 3-10 seconds to run. Switching to a new set of profiles affecting many CMs/flows should be expected to take multiple tens of minutes or more Case 3: Fallback Use Case In the Fallback use case, a CM has been operating for some time on a channel (may be a short time or a long time) but begins experiencing errors. Here it is expected that the CMTS is the first line of defense. When the condition is detected (e.g., using CM-STATUS), the CMTS may/should take action right away to move the CM to a different profile. Involving the PMA might take too long; it is better to quickly move the CM to a profile that gives it some (less efficient) service than to let it continue to lose packets. If the PMA has listed backup profiles in the profile-to-cm assignments, the CMTS could first move the CM to the backup profile, otherwise it could move the CM to profile A or to whatever other profile it thinks will work. After this has been done, the CMTS might ask the PMA to intervene: The CMTS sends a request to the PMA for a new profile for a specific CM. Under pull model, the PMA now requests the latest information about the channel: OCD (OFDM Channel Descriptor) List of profiles and CMs assigned DPDs for profiles Then the PMA requests latest information about the CM; e.g., ODS (may get this from CMTS or CM). The PMA also collects any other information such as traffic statistics from NMS, PNM information, etc. It may also want to examine its history of previous profile assignments for the CM. The PMA processes information and comes up with a recommendation. This could involve leaving the CM where it is, choosing a different profile for the CM from among those currently configured, or setting up a new profile and moving the CM and possibly other CMs over to it. Whatever it decides, it uses the same set of commands described in Section to accomplish its goals Push versus Pull Approaches A push approach makes sense for some scenarios but not all. Specifically, anything reflecting channel properties or CM state should be pushed. This includes OCD and DPD information, profile/cm assignments, and CM join/leave. These things cannot change without the CMTS knowing and so there s no point in having the PMA ask repeatedly for this information. It may ask at wide intervals (say hourly) to ensure nothing got missed but it should not have to poll every 10 seconds to stay up-to-date. A pull approach probably makes more sense for measurement results such as OPT or ODS. The PMA will want to be able to decide when it needs new information or when the information it has previously stored is sufficiently recent. This is not to say the CMTS couldn t push these things if it had them and wanted to. For example, if it does an OPT test on a CM for its own reasons, it might make sense for it to share the results with the PMA. However, for these items, the PMA can t assume that nothing has changed since the last set of results, so it s fair to expect it to ask for what it needs when it needs it Data Elements and Actions A Profile Management Application (PMA) needs to exchange information with CCAP devices (CMTSs and CMs). This includes gathering information about OFDM channel parameters and performance, as well as providing CCAP devices with OFDM channel modulation profile configuration decisions based on analyzing the gathered data. A PMA does this continuously to adapt to the changing conditions of OFDM channels and the CMs that use them. 104 CableLabs 06/25/15

105 There is no need to do modulation profile management for the DOCSIS 3.1 PLC. The need for NCP modulation profile management is to be determined later. In this section, we focus only on the data modulation profile management. NOTE: This section covers only the downstream modulation profile management for now. The upstream profile management will be worked out at a later time Data/Messaging Scope This section defines the message content across the PMA and CMTS interface. NOTE: The PMA to CM interface is defined in [CM-OSSI]. Potential enhancement to that interface should belong to DOCSIS 3.1 OSSI. The type of information that is used by PMA may fall into one of the following categories: OFDM channel parameters and statistics This includes the OFDM channel configuration parameters and error statistics from both the CMTS and the CMs. DOCSIS network topology and subscriber information Information such as the fiber node layout, the CM association with service groups, could be useful for the PMA, as well as other SDN applications. Topographical and other cable plant information Topographical and other cable plant information that is used by PNM could also be useful for the PMA. In this section, we focus on only the first category listed above, OFDM channel parameters and statistics Messages for the PMA-CMTS Interface This section defines the type of messages and the message contents needed for the PMA-CMTS interface. Table 11 provides a list of messages that are used for downstream channels. Table 11 - PMA-CMTS Downstream Modulation Profile Messages Message Downstream OFDM Channel Descriptor Downstream Profile Request Downstream Profile Descriptor Downstream Spectrum Request Downstream Spectrum Desciptor Downstream Profile Test Request Downstream Profile Test Response CM-to-Profile Assignment Request CM-to-Profile Assignment Descriptor Profile-to-CM Assignment Request Profile-to-CM Assignment Descriptor Description Conveys the configured channel parameters for a downstream DOCSIS 3.1 channel. Either a request from the CCAP for a new profile or a request from PMA for the details of an existing profile. Provides the configuration details of a modulation profile. Request from the PMA for the RxMER values for a channel from a given CM. Conveys the per subcarrier RxMER measurements for a channel from a given CM. Request from the PMA for the CCAP to test a specified modulation profile. Conveys the results of the test of a modulation profile on a specified CM. Request for a list of CMs that are assigned a specified modulation profile. Provides a list of CMs that are or are to be associated with a modulation profile. Request for a list of the profiles that are assigned to a CM. Provides a list of channels and modulation profiles that are assigned or should be assigned to a CM 105 CableLabs 06/25/15

106 Open Networking Although a PMA may manage multiple CMTSs, we assume that each CMTS can be uniquely identified by its host IP address, which is in each message s IP packet header. So the message content defined here is within the context of a single CMTS. This section does not imply that the interface needs to use TLV-based messages. The intent of this section is to tease out the needed information exchange Downstream OFDM Channel Descriptor The PMA needs to have the OFDM channel parameters as configured on the CMTS. The Downstream OFDM channel descriptor is for OFDM parameters that are common across profiles. This message is from the CMTS to the PMA. This message closely resembles the OCD message defined in DOCSIS 3.1 MULPI (most fields are copied from [MULPIv3.1]). Table 12 - Downstream OFDM Channel Descriptor Message Name Type Length (bytes) Value IfIndex Integer (Int32) 4 Config change count Unsigned Byte 1 Note: OCD parameters same as in Table 6-63 in [MULPIv3.1] Downstream Profile Request When sent from the CMTS to the PMA, this message is used by the CMTS to request the PMA to provide a new set of profiles, or the details of a specific profile identified by profile ID, for a downstream OFDM channel. When sent from the PMA to the CMTS, this message requests the current profiles being used on the CMTS to be sent to the PMA. An IfIndex of 0 indicates a request for all the profiles and all downstream OFDM channels on a given CMTS. A Profile ID of 0xFF indicates a request for all profiles on the downstream OFDM channel specified by the IfIndex. Table 13 - Downstream Profile Request Message Name Type Length (bytes) Value IfIndex Integer (Int32) 4 Profile ID Unsigned Byte Downstream Profile Descriptor When sent from the CMTS to the PMA, this message is used to inform the PMA which modulation profile is currently being used on the CMTS. When sent from the PMA to the CMTS, this message is used to inform the CMTS of the profile computed by the PMA. In this case, the configuration change count is ignored. Table 14 - Downstream Profile Descriptor Message Name Type Length (bytes) Value IfIndex Integer (Int32) 4 Profile ID Unsigned Byte 1 Profile attributes Unsigned Int 2 Bits definitions to indicate if the profile is used for multicast, voice, etc. Configuration change count Unsigned Byte Note: Subcarrier assignment TLV as defined in Table 6-64 and 6-65 in [MULPIv3.1]. 106 CableLabs 06/25/15

107 Profile descriptors may be sent from the CMTS to the PMA, or from the PMA to the CMTS, with or without the Downstream Profile Request message OFDM Downstream Spectrum Request This message is used by the PMA to request that the CMTS send an ODS-REQ to a CM. If the CM MAC address is a broadcast address, then the request is for the CMTS to send ODS-REQ to all the CMs on the OFDM channel. Table 15 - OFDM Downstream Spectrum Request Message Name Type Length (bytes) Value CM MAC address MacAddress 6 IfIndex Integer (Int32) OFDM Downstream Spectrum Descriptor This message is sent from the CMTS to provide the PMA, the RxMER values for a given CM. It serves the same purpose as the ODS-RSP message defined in [MULPIv3.1]. This message may be sent from the CMTS to the PMA either unsolicited or in response to the OFDM Downstream Spectrum Request message. Table 16 - OFDM Downstream Spectrum Descriptor Message Name Type Length (bytes) Value CM MAC address MacAddress 6 Timestamp (time of day) UnsignedInt 4 Time the measurement was done by the CM IfIndex Integer (Int32) 4 Note: ODS-RSP encodings as specified in Table 6-66 in [MULPIv3.1] OFDM Downstream Profile Test Request This message is for the PMA to request that the CMTS send an OPT-REQ message to the specified CMs to test a modulation profile on a channel. A broadcast CM MAC address indicates a request to send the OPT-REQ to all CMs on the OFDM channel. A list of CM MAC addresses indicates a request to send the OPT-REQ to all the CMs in the list. Table 17 - OFDM Downstream Profile Test Request Message Name Type Length (bytes) Value CM MAC address list MacAddress 6 * N IfIndex Integer (Int32) 4 Profile ID Unsigned Byte 4 Op code Unsigned Byte 1 1 Start 2 Abort Note: OPT-REQ TLV encodings as specified in Table 6-67 in [MULPIv3.1]. 107 CableLabs 06/25/15

108 Open Networking OFDM Downstream Profile Test Response This message is how the CMTS informs the PMA of the downstream profile test results for a CM. If the request was sent to multiple CMs, one response will be sent for each CM that received the request. Table 18 - OFDM Downstream Profile Test Response Message Name Type Length (bytes) CM MAC address MacAddress 6 Timestamp (time of day) Unsigned Int 4 IfIndex Integer (Int32) 4 Profile ID Unsigned Byte 1 Value Status Unsigned Byte Testing 2 - Profile Already Testing from Another Request 3 - No Free Profile Resource on CM 4 - Max Duration Expired 5 - Aborted 6 - Complete 7 - Profile already assigned to the CM All other values reserved Note: OPT-RSP TLV encodings as in Table 6-68 in [MULPIv3.1] CM-to-Profile Assignment Request This message is used to request a list of CMs that are assigned to a profile. When sent from the CMTS to the PMA, it lists the suggested CM to profile assignment computed by the PMA. When sent from the PMA to the CMTS, it provides the current CM to profile assignment on the CMTS. Table 19 - CM-to-Profile Assignment Request Message Name Type Length (bytes) Value IfIndex Integer (Int32) 4 Profile ID Unsigned Byte CM-to-Profile Assignment Descriptor This message is used to provide a list of CMs that are assigned to a profile. When sent from the CMTS to the PMA, it describes the current CM to profile assignment used on the CMTS. When sent from the PMA to the CMTS, it describes the suggested CM to profile assignment as recommended by the PMA. The profile change count is ignored in this case. This message may be sent with or without the CM-to-profile assignment request. Table 20 - CM-to-Profile Assignment Descriptor Message Name Type Length (bytes) Value IfIndex Integer (Int32) 4 Profile ID Unsigned Byte 1 Profile change count Unsigned Byte 1 Change Count from within DPD Profile attributes Integer (Int32) 32 bit mask Bit definitions to indicate if the profile is used for multicast, voice, etc. A list of tuples: (CM MAC address, CM state) MacAddress, Unsigned Byte 6+1 CM MAC address CM operstatus 108 CableLabs 06/25/15

109 Profile-to-CM Assignment Request This message is used to request a list of modulation profiles that are assigned to a CM. When sent from the CMTS to the PMA, it requests the PMA to suggest the modulation profile to modem assignment for the CM. When sent from the PMA to the CMTS, it requests the current modulation profile to CM assignment on the CMTS for the specified CM. Table 21 - Profile-to-CM Assignment Message Name Type Length (bytes) Value CM MAC address MacAddress Profile-to-CM Assignment Descriptor This message is used to provide a list of downstream OFDM channels and modulation profiles assigned to a CM. When sent from the CMTS to the PMA, it describes the current profile to CM assignment used on the CMTS for that CM.When sent from the PMA to the CMTS, it describes the suggested modulation profiles to CM assignment as computed by the PMA. The profile change count is ignored in this case, and the tuple can be defined differently to exclude the profile change count. This message may be sent with or without the profile-to-cm assignment request. Table 22 - Profile-to-CM Assignment Message Name Type Length (bytes) Value CM MAC address MacAddress 6 A list of (IfIndex, Profile ID, profile attributes, profile change count) Integer (Int32), Unsigned Byte, Integer (Int32), Unsigned Byte ( ) * n Additional DOCSIS Network and CM Information Additional information from the CMTS may be useful to the PMA, for example: CM time offset to indicate the CM distance from the CMTS. Fiber node configuration and modem service group assignment to indicate the location of the CM. Whether such messages should be defined within PMA or in the wider scope of PNM will be defined in future PMA Configuration Additional information may be useful to configure the PMA, for example: Constraints on profiles, e.g., the upper limit of the range of bit loading values a profile may take. Constraints on a CM s bit loading ranges. Number of subcarrier blocks. Other information that can be exchanged at boot time that is not channel-specific, e.g., topology information. 109 CableLabs 06/25/15

110 Open Networking 12.5 PMA Data Backend and Protocols Figure 50 - PMA Data Backend and Protocols Figure 50 shows the various protocols and locations/devices from which the data needed for a PMA application can be obtained Other PMA Considerations Central Database The information exchange between the CMTS and the PMA is the key enabler for this application. This information can be exchanged in real time between the PMA and the CMTS. Another approach to ease the communication burden on the reporting entities could be to implement a central database which is updated with all the information. An SDN controller could host a master database to capture all the information exchange needed for this application. This database can hold all the information needed by a PMA, the profiles used and their details, which CMs are using which profiles, historical profile, and usage information. This gets updated every so often by the CMTS or by pulling data from other sources (e.g., PNM data) Types of Data Needed There are various kinds of information needed by a PMA to compute the optimal profiles. All the data needed can be stored in a database accessed by the SDN controller, so that it could be used by multiple applications. The following is a list of the different kinds of data that can be useful to store in a database: CMTS registration information (when it connects with an SDN controller) PMA initial configuration information Current CMTS OFDM channel configurations List of all CMs that are online List of profiles in use by each CM 110 CableLabs 06/25/15

111 Historical data: e.g., profile configurations which were used, not accepted etc. Signal Quality Analytics for each Downstream Channel on the CMTS: MER info from CMs Data obtained from the OPT-RSP messages from a CM (see [MULPIv3.1]) Statistics: FEC statistics (e.g., LDPC), CRC statistics, and MAC Layer statistics Proactive Network Maintenance (PNM) data from a CM (see section on PNM in [PHYv3.1]) Data from the Symbol Capture function on a CM and a CMTS; this data can be used to figure out the transfer function of a channel Multiple Masters Problem Once a PMA application is implemented, there can be more than one entity that can configure profiles to be used. In this case, both the CMTS and the PMA have the ability to calculate optimal profiles and configure the needed changes on the plant. The current design assumes that the PMA essentially makes suggestions or recommendations to the CMTS, which the CMTS can choose to implement or decline. At this point, the higher level understanding is that the CMTS can be autonomous, i.e., it does not have to use the PMA for all the use cases described previously, all the time (or for any of the use cases). In the future, a model where the PMA takes over absolute control of managing all the profiles on the CMTS can be considered Evaluating Profile Changes Once the PMA and CMTS implement the profile changes, the system needs to be monitored and evaluated on the effect of the changes. The throughput of each individual CM and the packet errors need to be measured to evaluate how each CM is performing on their assigned profiles. The network capacity also needs to be monitored and measured to evaluate if the profile changes were optimal in terms of maximizing the network capacity. These responsibilities will typically be shared between the CMTS and the PMA. This would require real time responsiveness on the PMA and implementation of intelligent algorithms, which can be configured with policies from the operator Policy Definition Changing a profile could cause temporary traffic interruptions for a CM. There are many situations in which a PMA or a CMTS will not be able to make a change to the profile assigned to a CM. This may be because the CM is running services like video streaming or supporting a voice call at that moment and service continuity is more important to the operator at that time compared to the positive effects of a profile change. All of these use cases need to be captured as a set of policy rules. These would be exposed as APIs for Policy Enforcement, for Policy Deployment, and for status reporting. This policy will be defined by an MSO during initialization of the PMA. During runtime, the CMTS or the PMA will check for service interruption policy (or other conditions) before implementing a profile change Data Acquisition Methods The choice for the PMA is to either reuse existing mechanisms of data retrieval from the CM or the CMTS, or to require support of new protocols such as RESTCONF (as described in this technical report) on a CMTS. The data from the CMTS and the CMs can be acquired in one of many ways. These include SNMP MIB reads, MAC Management messages, FTP data out of CM to a PNM server, or all the data and commands flow through the RESTCONF interface on the CMTS. There needs to be further analysis and design of what are the best mechanisms for sending data back and forth between a CMTS and the PMA Data Volume for Message Exchanges The relevant messages for profile management are described in the following subsections Downstream Profile Descriptor There is one downstream profile descriptor per profile, and it consists of: MMM header + 1 byte DS Channel ID + 1 byte profile ID + 1 byte config change count 111 CableLabs 06/25/15

112 Open Networking Subcarrier assignment TLV varies, up to 255 bytes Transmission frequency: On PLC: ms On Profile A: ms OFDM Downstream Spectrum ODS-REQ: MMM header + 1 byte DS channel ID ODS-RSP: MMM header + 1 byte DS channel ID ODS-RSP-MP TLV size: (see Table 6-66 of [MULPIv3.1]) = N = N+11 bytes (N 7680) Per-CM and-per-ofdm channel Transmission time is vendor dependent Will need to store the RxMER received OFDM Downstream Profile Test OPT-REQ : MMM header + 2 bytes reserved + 1byte DS Channel ID + 1byte profile ID + 1byte opcode OPT-RSP : MMM header + 2 bytes reserved + 1byte DS Channel ID + 1byte profile ID + 1byte opcode 2N + 59 bytes (15419 bytes for N=7680) Data Volume Estimate The approximate number for each CM and each profile is about 20 bathe scale factors are: Number of DOCSIS 3.1 CMs, e.g., 10K CM would be 200 MB. Number of profiles, if we keep track of all candidate profiles for each CM. Number of historical copies stored. E.g., 20 kb * 10K CMs * 10 profiles * 10 historical copies = 20 GB for one CMTS Gaps in the PMA Solution The design of the PMA needs further analysis in the following areas: Initialization of the PMA and CMTS needs to be worked out. How does the PMA decide when to update profiles on a CMTS/CM: The PMA needs to decide when a CM should move to a lower or higher profile, this would be the PMA vendor s trade secret. The PMA could initiate a test on the current channel/rxmer (using MMM or PNM), get the required information, and then figure out recommendations on new profiles. CMTS vendors need to investigate the mechanics of implementing support for a PMA application function on an existing CMTS platform. Specifically, when to kick off DOCSIS messages based on commands from the PMA and how to extract information from MMMs, etc. As the team develops the PMA application further and the data models mature, these gaps will be addressed. 112 CableLabs 06/25/15

113 13 INTENT-BASED NETWORKING VISION AND ARCHITECTURE The traditional model for operating networks involves modeling the network topologies and protocols to implement the network. Intent based networking by contrast involves modeling the applications (or workloads) and their interactions to enable automation logic to drive the conversion to a network implementation. Intent-based networking involves translating Intent expressed in a high level language applicable to the applications into parameters applied to the northbound interface (NBI) of a network controller that implements the network state needed to deliver the desired behavior. A simplified cable-centric architectural diagram is shown below. Figure 51 - High Level Intent-Based Networking Architecture The Intent Engine may be part of the SDN controller. Intent-based networking simplifies the task for network managers who only need to specify the distributed workload s behaviors and communications requirements instead of requiring detailed network configuration expertise and understanding network protocols and equipment interfaces. Users select what they want via a web portal or app. The intent engine invokes algorithms/rules at run time to give the user what they want. In practice the network state is automatically realized end-to-end without manual intervention at run time or having to program detailed network implementation specifics at design time. This extensible interface will support creation of rules and constraints with associated Intent algorithms to a diversity of use cases. Support is planned for both hard constraints, e.g., bandwidth (Mb/s), latency (ms), etc. and soft constraints, e.g., high quality, lowest-latency. The Intent controller is responsible for re-computing and reporting the state of fulfillment of system intent whenever the state of the intent repository or the state of the network changes. Constraints can be added to do things such as ensuring efficient use of routing capacity taking into account demand and bottlenecks, minimizing energy consumption, maximizing equipment utilization, delivering requested bitrate, requested latency, in service system expansion/contraction, advanced security features, etc. How to present the users with choices, how to articulate Intent and how to translate it into actionable network configuration commands is the problem being addressed by a variety of projects and organizations. This document provides an introduction to Intent-based networking and an overview of the leading industry activities. It also provides recommendations on next steps for MSOs to begin the journey to realize the benefits of Intent-based networking Use Cases and Intent-based Order Portals MSO order portals will evolve to accommodate intent-based services and this will be a rich topic for innovation and service provider differentiation. Networks basically provide two capabilities: connectivity (i.e., forwarding/filtering/isolation rules) and Quality of Service (QoS). It is useful to consider a representative set of use 113 CableLabs 06/25/15

114 Open Networking cases which illustrate the opportunities and challenges for implementation of Intent-networking. Three high-level descriptive use cases are given here which span the connectivity and QoS. Each use case could be described as a hierarchy of three levels: at the highest level, the user has something in mind that she/he wants to accomplish. The next level is an application the user interacts with to express intent and the final level is whatever underlying network commands the intent gets translated into. Specification of Intent algorithms and translation to the commands required to configure the network infrastructure is the problem being addressed by a number of industry forums as detailed later in this report. And existing domainspecific languages supporting today s OSS/BSS systems could also be mapped to an intent system to enable existing environments to start to move towards Intent-based networking VPN Service Order Scenario VPN is a popular business service provided by MSOs as it can be bundled with other services such as Internet Access, and with options such as a managed router. It can be described by Intent-based networking as a relationship between customer locations or groups joining a VPN as a single entity. The relationship can be fine-tuned; for example this group can communicate with that group but not others, etc. At the user level, the user might describe his requirement as "I want the network port in my home office to act like it's a port on the corporate LAN at work." At the application level, an operator might provide a web portal for customers to use to set up their services. From her home, the user starts a browser and connects to the web portal. She may need to input some parameters like a company ID, security code, and desired bit rate. At the network provisioning level, for example, if the user is served by a DOCSIS network, the result might be commands to implement a L2 or L3 VPN service. There can be several types of VPN service orders: new, change, disconnect, and inflight change/modification. In this example, we provide only new and change service orders. The new service order is to create a complete VPN. The change service order can be many things, such as add new location to an existing VPN. The following tables illustrate the kinds of data that would be applied at the network provisioning level to implement various types of VPN service order. Table 23 - Service Order Data for New VPN # Name Type Note 1 Customer ID Table Table 2 Class of Service Platinum/Gold/Bronze This SLA will be translated to VPN QoS such as max delay/loss, and activated to identified devices. 3 Location(s) List of references to location data 4 Topology Hub-Spoke/Full Mesh/Partial Mesh If hub and spoke, indicate which location is hub. Partial mesh requires more information. 5 Internet Gateway Yes/No If customer wants to access Internet from the VPN. 6 Delivery date Date Desired delivery date of the VPN for the customer. Table 24 - Service Order Data for Adding Location to Existing VPN # Name Type Note 1 VPN Service ID Existing VPN 2 Location References to location data 3 Delivery date Date Desired delivery date of the VPN for the customer. 114 CableLabs 06/25/15

115 Table 25 - Example Location Information # Name Type Note 1 Location Address Street address Note that this is not translated by BSS to the SDN controller. 2 Access service required? Yes/No Yes if new access (e.g., GPON), no if use existing access (e.g., DOCSIS). 3 Existing access provider Existing access ID(s) Multiple if back-up required 4 Existing access type GigE, GPON, DPOE, etc. For encapsulation type. 5 Access redundancy Yes/No If new access service is required. 6 Access Bandwidth CE ID Management IP address The assumption is to use existing access service, delivered 7 to a router that the provider knows and so can configure. 8 CE Interface ID Like Ether Gaming Service Order Scenario At the user level a gaming service order could be expressed by the user as: "I just bought a new network-based game for my smartphone and I want to get very fast responses when I press the buttons." At the application level, the Intent system would know how to speak the necessary protocols to ask a network for what it needs specifically a reservation for a low-bandwidth, very-low-latency flow. The network commands, for example over DOCSIS, would configure a service flow with the desired parameters for bandwidth, priority, and maximum latency. Other access technologies and other parts of the network would be configured accordingly Home Security Service Order Scenario At the user level, a security service order could be expressed by the user as: "I have a home security system with video monitoring that I can access remotely. I want to be able to zoom in to get high-resolution video while I'm watching, but I don't want it to use hi-res all the time because that would exceed my monthly data plan cap." At the application level, the user interfaces to the application managing the security system to remotely view camera activity, control the zoom, and log out when he's done. The application responds by changing the amount of data it is recording/sending; it also knows the protocols needed to communicate with an Intent engine to request the bandwidth needed to support the desired zoom level. The network commands, for example over DOCSIS, would ultimately result in a Dynamic Service Change command to change the security application's Service Flow to increase or decrease the bandwidth as needed. Matching service changes would also be made for other parts of the data path Triple Play Service Order Scenario Triple play service means Broadband, Voice and TV or any combination, along with Value Added Services (VAS). Triple play service is provided on top of an access service (e.g., DPoE). There are some dependencies, for example, Voice or Video cannot be ordered without Broadband. At the user level a triple-play service order could be expressed by the user as: "I want a broadband service and a TV service, but I don t want a voice service. At the application level, the user interfaces to the application managing the triple play system and selects from a menu of offers. Offers could include different broadband speeds including QoS and latency options, a variety of TV bundles and voice. In addition, value-added services could be added such as voice mail, parental controls, etc. new value added services can be created from a bundle of services. For example: If TV program is on and there is phone call, show caller ID on the TV screen. If I am watching TV and the front door is opened, show security camera video on my TV screen. Intent-based networking can make these easier to be invoked by a customer portal and therefore more attractive to customers. 115 CableLabs 06/25/15

116 Open Networking The following tables illustrate the kinds of data that would be applied at the network provisioning level to implement various types of triple-play service order. Note that service orders invoking an SDN controller may have more details provided by the BSS, such as the type and MAC address of the CM that was dispatched to the customer location. Table 26 - Service Order Data for Broadband # Name Type Note 1 Customer ID Table Table 2 Street address This is not translated to the SDN controller, as it s used by BSS only. Rather, after the CPE (CM or ONT) is sent and deployed, its ID is used. 3 Upstream bandwidth 4 Downstream bandwidth 5 Number of public IP addresses 6 Data volume cap 7 Delivery date Date This can be a Value Added Service (VAS), e.g., residential customers who want to host content could request a fixed public IP address. Table 27 - Service Order Data for Voice # Name Type Note 1 Customer ID Table Table 2 Number of lines/tns This is not translated to the SDN controller, as it s used by BSS only. Rather, after the CPE (CM or ONT) is sent and deployed, its ID is used. 3 LNP Phone number (s) Customer existing phone numbers (by their existing Voice provider) to port in 4 Voice mail This is just one example of Features. Other can be 3-way conf. call, Caller ID, etc. 5 Access service ID Existing high speed data service if this is VoIP 6 Long Distance Provider ID 7 Delivery date Date Desired delivery date of the VPN for the customer Table 28 - Service Order Data for TV # Name Type Note 1 Customer ID Table Table 2 TV Package(s) This is not translated to the SDN controller, as it s used by BSS only. Rather, after the CPE (CM or ONT) is sent and deployed, its ID is used. 3 Number of TVs /Terminals TV Everywhere is another option. 4 Access service ID Existing broadband service if this is VoIP. 5 DVR Size Gb 6 Delivery date Date Desired delivery date of the VPN for the customer. 116 CableLabs 06/25/15

117 13.2 Related Industry Initiatives There are a number of industry initiatives whose goals are to create Intent capabilities for networks. This section provides an overview of these industry activities. It is not intended to be an exhaustive list or to rank any of the activities in terms of relevance. The field is extremely dynamic with new insights and solutions being developed constantly as SDN evolves. This review provides a brief description for a number of the higher profile industry efforts. Links are provided to access more detailed information Group Based Policy Group Based Policy (GBP) is a full Intent System. It utilizes a declarative language and API generated from its Intent data model. This allows consumers of the Intent System to contract the network services through a simple expression of intent, and without requiring detailed knowledge of the underlying network infrastructure. Using an Intent specific data model, GBP separates the consumer s Intent functional requirements from any implementation details of the network infrastructure. Today there are group based policy projects in both OpenDaylight (ODL) and OpenStack projects. The architecture itself consists of two main sets of components: The Intent Data Model; Process how the objects in the model relate to one another to fulfill the expressed Intent. The provisioning of the expressed Intent into concrete configuration is automated. Renderers perform the Intent Automation function. Renderers are where the details of how to implement the policies reside. A single system might support a number of renderers; each supporting different features or methods to deliver a requested policy. The Open Daylight project has developed two renderers, one for Open VSwitch (OVS) Overlays and another for OpFlex. 1 The most important elements used to represent high-level abstractions are the endpoints, endpoint groups, contracts, and policies. An endpoint is simply a network endpoint. Typically this relates to a workload or application instance. Most importantly, each endpoint includes a set of properties and values. An endpoint group is a set of endpoints that is defined based upon the endpoints sharing a common set of properties and values. An endpoint can be included in more than one endpoint group. A contract is associated between two endpoint groups, where one is identified as a provider of the contract, the other a consumer of the contract, and a policy or set of policies. The policies, or rules, will be applied to traffic that moves from any endpoint in the provider group to any in the consumer group. In Figure 52 below, repositories of endpoints, policies, etc., are defined, as are active contracts. The active contracts describe how policies are to be applied to traffic between pairs of endpoints (directional). These are then processed in renderers to define actual configuration updates that make the policies real CableLabs 06/25/15

118 Open Networking Figure 52 - Group Based Policy Architectural Components When an application expresses its intent in these terms, the application need know nothing about the actual network actions to deliver on the intent. In fact, the request will be portable if renderers exist to support the contract on other network infrastructure. More information on GBP can be found on the OpenDaylight and OpenStack websites. Status Group Based Policy has been a part of OpenDaylight since the Helium release and will be enhanced with new features in the OpenDaylight Lithium release, scheduled for late June, Future releases are in planning and are receptive to requirements Open Networking Foundation (ONF) Common Intent Northbound Interface (NBI) Initiative The ONF NBI working group is seeking to unite all of the emerging intent projects with a project to define a common, infrastructure and controller agnostic NBI Information Model. Work is currently ongoing to define an NBI and to build reference implementations of it across several open source networking projects. Currently work is ongoing to create software artifacts in the ONF Repository that define Information Models for multiple open source projects that implement the NBI. The OpenDaylight Network Intent Composition (NIC) project, ONOS NIC project, and OpenStack have development work supporting this initiative in order to prove the infrastructure-agnostic benefits of the Intent approach. The implementation of the common NBI in the OpenDaylight NIC project has been developed in such a way that several existing intent-like projects can be mapped as backend implementations of the common intent NBI. 118 CableLabs 06/25/15