Name

PacketCable PCMM

Develop a PacketCable PCMM/COPS southbound plugin and supporting modules to allow the OpenDayLight controller to provision CMTS as a network element that manages service flows with dynamic QoS.

Repo Name

packetcable

SCTE demo and ODL staged source can be found at GitHub.

Description

Packet Cable MultiMedia (PCMM) provides an interface to control and management service flow for CMTS network elements. A service flows constitute a DOCSIS data path between a CMTS and a subscriber's cable modem (CM) guaranteed application specific quality of service (QoS), known as Dynamic Quality of Service (DQoS). PCMM offers (MSOs) the ability to deliver new services using existing cable infrastructure. MSOs have already begun to apply PCMM technology for expanding their multimedia service offerings.

PCMM Overview

The PCMM architecture comprises the following components:

• The Application Manager, which specifies QoS requirements to the Policy Server on a per-application basis.

• The Policy Server, which allocates network resources per subscriber and per application, ensuring that consumption meets MSO priorities.

• The Cable Modem Termination System (CMTS), which enforces policies according to bandwidth capacity.

• The Cable Modem, which resides on the client side and connects the client's network to the cable system.

PacketCable Multimedia defines a service delivery framework that provides general-purpose QoS, event-based accounting, and security functionality founded upon the mechanisms defined in PacketCable 1.x. However, due to the broader spectrum of applications and services addressed by this initiative, each of these functional areas has been revisited and generalized for the present purposes. Telephony-specific requirements and interfaces (e.g., call signaling, PSTN interconnection and electronic surveillance) are not part of PacketCable Multimedia, while core functionality such as QoS resource management mechanisms, has been enhanced. Throughout this process, one of the primary objectives of this work has been to leverage and reuse as much of the existing body of PacketCable 1.x investment, knowledge base, and technical functionality as possible. Key features of the described Multimedia service delivery framework include:

• Simple, powerful access to DOCSIS QoS mechanisms supporting both time and volume-based network resource authorizations,

• Abstract, event-based network resource auditing and management mechanisms,

• A robust security infrastructure that provides integrity and appropriate levels of protection across all interfaces.

The goal of this project is to utilizes the OpenDayLight controller platform as for the Application Manager and parts of the Policy Server and leverage the as many existing components offered by the platform.

The initial southbound transport has been written to the following version of the specification: http://www.cablelabs.com/wp-content/uploads/specdocs/PKT-SP-MM-I05-091029.pdf

Scope

• Provision a CMTS and an associated Cable Modem to form a Subscriber service for which (service) flows can be established and metered.

• Flow Programmer match-only for managing DOCSIS (service) flows

• Northbound APIs for provisioning CMTS network elements

  • HTML Provisioning Interface or some Python RESTful examples

• Northbound APIs for provisioning Service Flow values and types

• Northbound APIs for provisioning QoS (or metering) parameters

• SAL extensions for DOCSIS specific data model and configuration APIs

• Southbound PCMM/COPS transport plugin

Non-Goals

• Functional COPS driver

• CMTS PCMM COPS emulator

• Configuring a CMTS using Netconf

Work Flow Example

• Restful POST from Cable SDN Application Logic to DOCSIS Abstraction Layer to add a new CMTS

• Restful PUT from Provisioning App to Cable SDN Application Logic

• Restful PUT from Cable SDN Application Logic to Flow Programmer to Create Flow

• Flow Programmer Dispatches Request to SAL

• SAL Routes Message to South Bound PCMM/COPS Plugin Based on Node Type

• PCMM/COPS Plugin Forms a Gate Message to Create a Service Flow and Sends via COPS to CMTS

• DSx control message is sent to the Cable Modem

• A Flow Status is is returned to Cable SDN Application Logic

For example, add L2VPN Attributes (ID/Type/Value Encapsulation types, VLAN ID, etc).

• PCMM/COPS Plugin forms a Gate Message to Modify a Service Flow

• DSx control message is sent to the Cable Modem

Design Details

DOCSIS SDN Application Logic

This component is introduced at the Network Applications Orchestrations and Services layer. The component is proposed as an application responsible for the workflow logic that represents the use cases of interest: L2VPN, Buffer Management, Service Flow QoS Management, and general configuration automation.

Flow Programmer

This standard components exists at the Controller Platform layer and is responsible for programming flows at network elements that register support for flow management. It adheres to this FlowProgrammer Restful API.

See PCMM Augmented FlowProgrammer

DOCSIS Abstraction Layer

This component is introduced at the Controller Platform layer. This component manages the DOCSIS (and PCMM) specific attributes, such as store and change the default QoS values that are applied to Service Flows, and addition and removal of CMTS network elements. This module exports a DOCSIS specific northbound RESTful API as part of ODL architecture.

PCMM/COPS

This component is introduced at the Southbound Interfaces & Protocol Plugins layer. This component is responsible for the PCMM/COPS/PDP functionality required to service requests from PacketCable Manager and FlowManager. Requests are transposed into PCMM Gate Control messages and transmitted via COPS to the CMTS. This plugin adheres to the PCMM/COPS/PDP functionality defined in the CableLabs specification.

Information and Data Models

Developing a Model

Information and Data Models

OpenDayLight Models

Model Driven SAL Reference

Developing a Model

CMTS Inventory

CTMS Inventory Provisioning model is a draft adopted from OF-Config and contains some parameters for the future features that include interfacing to being able receive SNMP traps, read/write SNMP oid and configure using CLI. These services might even be provided by another southbound plugin. Unlike Openflow, discovery is not derived from a switch and provisioning is top down.

Flow Match Types and is a modification of the existing Openflow match action as a result of the comparison with Openflow.

Service Types are the northbound methods.

Flow Traffic Profile represents the various DOCSIS service flows that can be created.

PacketCable Service represents the northbound RPC service.

OpenDayLight Metering

QoS (or Metering) are parameters pertaining to a service flow types. Is there a way to extended OF metering to adopt DOCSIS Dynamic QoS?

• Metering References

  • Meter Types

  • Meter Management

  • Meter Statistics

•  

  • Meter Service

PCMM Traffic Profile

PCMM Service Flow Types

Openflow Match Action and PCMM Service Flow Comparison

The following tables are comparisons with Openflow and PCMM ServiceFlows types. IPv6 is considered part of this comparison.

Openflow Match

Openflow Action

PCMM COPS Information Model

The CableLabs PCMM Specification defines the COPS PDP to PEP interface via a message set and set of object definitions. The objects carried in the COPS message set can be viewed as the PCMM COPS Information Model for the PCMM COPS interface between the Policy Manager and CMTS. The objects are represented in the table below.

Use Cases

Proactive QoS

Predefined flows with known quality of service parameters.

Reactive QoS

Use OpenFlow packetin to trigger a PCMM and Openflow flow creation.

Proof of Concept

On 21 October 2013, a proof of concept PCMM southbound plugin was demonstrated at SCTE. This demonstration “shows” network flow manipulation by controlling DOCSIS video traffic flows from ODL and applying different PCMM metering parameters to creating a video image that was either degraded or high quality.

Research

Using Netconf to configure CCAP

See Yang for CCAP

CCAP and DOCSIS 3.1 CMTS YANG Model Support

Since both devices optionally support the NETCONF protocol, these cable devices also optionally support YANG data models which are translated into mandatory supported XML Schema data models. The OpenDaylight framework also uses YANG models for their data model representation and tooling.

CCAP PCMM Configuration Management Information Model

The CableLabs CCAP specification defines a UML Class Diagram Information Model for configuration management of PCMM in the CCAP device. This is represented in the figure below.

The above Information Model is translated into the YANG configuration management data module and corresponding XML Schema. Therefore, these objects and attributes can be provisioned via XML configuration files and optionally, if supported, via NETCONF messaging.

CCAP

Latest (2014-04-02) CCAP Yang file.
Error creating thumbnail: Invalid thumbnail parameters

CCAP

CCAP events

Using SNMP for SubscriberID (Cable Modem) Discovery

What is required in defining a service flow is the SubscriberID (or IP address). It would be useful to discover the Cable Modems (CM) that are being hosted and managed by a provisioned CMTS.

http://www.cisco.com/en/US/docs/cable/cmts/mib/reference/guide/ubrmibb.html

^{<docsIfCmtsCmStatusValue> <name>Registerd Modems</name> <method>walk</method> <source>value</source> <direction>output</direction> <oid>.1.3.6.1.2.1.10.127.1.3.3.1.9</oid> </docsIfCmtsCmStatusValue> DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.2.1 docsIfCmtsCmStatusMacAddress.1 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.2.2 docsIfCmtsCmStatusMacAddress.2 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.2.3 docsIfCmtsCmStatusMacAddress.3 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.3.1 docsIfCmtsCmStatusIpAddress.1 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.3.2 docsIfCmtsCmStatusIpAddress.2 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.3.3 docsIfCmtsCmStatusIpAddress.3 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.4.1 docsIfCmtsCmStatusDownChannelIfIndex.1 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.4.2 docsIfCmtsCmStatusDownChannelIfIndex.2 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.4.3 docsIfCmtsCmStatusDownChannelIfIndex.3 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.5.1 docsIfCmtsCmStatusUpChannelIfIndex.1 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.5.2 docsIfCmtsCmStatusUpChannelIfIndex.2 DOCS-IF-MIB 1.3.6.1.2.1.10.127.1.3.3.1.5.3 docsIfCmtsCmStatusUpChannelIfIndex.3}

Expressing Support and Interest in Project

• Prasanna Mucharikar (Cisco)

• Mohammad Kabir Chowdhury (Comcast)

• Joshua Sholes (Comcast)

• Sameer Patel (Comcast)

• Jeff Finkelstein (Cox)

• Sangeeta Ramakrishnan (Cisco)

• Brian Otte (CableLabs)

• Alon Bernstein (Cisco)

• Eduardo Jacob (The University of the Basque)

• Jeff Pedigo (Applied Broadband)

• Jason Schnitzer (Applied Broadband)

Resources Committed (developers committed to working)

• Thomas Kee irc:xsited

Initial Committers

• Thomas Kee irc:xsited

Vendor Neutral

• No vendor package names in code

• No vendor branding / trademark present in code or output of build

• No vendor branding / trademark present in documentation

Meets Board Policy (including IPR)