A CDN is a system of distributed servers that deliver content to a user based on the geographic locations of the user, the origin of the requested content, and a content delivery service. The goal of a CDN is to provide efficient delivery of streaming content over HTTP/HTTPS to optimize content delivery and to serve content to end-users with high availability and high performance, while minimizing the traffic on the network.

At its core, a CDN performs two essential functions:

• It caches content at the edge of the network, closer to end users, to reduce the IP video traffic that needs to traverse the core network, delivering a higher quality experience to viewers.

• It positions multiservice, multiprotocol content streaming capabilities at the network edge, allowing the operator to adapt video content for virtually any IP video device close to the user that is consuming it.

By 2020 there will be 11 billion connected video devices, and 82 percent of IP traffic will be video (Cisco Visual Networking Index). To meet that demand, today’s CDN infrastructures must evolve to scale cost-effectively, accelerate feature velocity, and deliver simplified and open management tools. By adopting cloud architecture and agile software development methodology and using best-in-class open-source software, Cisco Media Streamer provides an open and flexible CDN platform that delivers the multiscreen Internet video quality that consumers expect and service providers can deploy.

The Cisco Media Streamer content delivery platform is designed to deliver immersive multiscreen video experiences to managed and unmanaged devices across telco, cable, and mobile access networks. Media Streamer scales cost-effectively to distribute terabits per second (Tbps) of live, on-demand, and time-shifted video. It enables service providers to compete with over-the-top (OTT) video offerings and generate revenue from wholesale CDN services within their infrastructure. Media Streamer is the foundational IP delivery platform for Cisco’s Infinite Video Platform, which provides comprehensive consumer video experiences.

Media Streamer includes all the core elements of management, request routing, load balancing, caching, and analytics to deliver HTTP and HTTPS content at scale and to easily integrate into your network and middleware. Media Streamer builds on Cisco’s more than 10 years of CDN expertise.

Media Streamer caches and delivers web content, software, and streaming media with support for media players using the following HTTP steaming protocols: Apple HTTP Live Streaming (HLS), Microsoft HTTP Smooth Streaming (HSS), Adobe HTTP Dynamic Streaming (HDS), and MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH). Media Streamer supports video on demand (VoD), live video, time-shifted TV (TSTV), progressive download, secure download, and small object caching from a common high-performance HTTP cache. Media Streamer performs sophisticated algorithms for cache selection based on client location, cache availability, cache load, and content requested.

The primary components of a Cisco Media Streamer solution are:

• OMD Director: Cisco OMD Director is a cloud-based CDN management system that provides integrated provisioning, monitoring, analytics, alerting, and role-based management. Cisco OMD Director is implemented to be virtualized and further optimized with microservices in containers. OMD Director is the primary user interface of Cisco Media Streamer.

• OMD Director Portal: An OMD Director portal is optional and does not replace the primary OMD Director Master Controller and Worker nodes. It is intended for customers with downstream Resellers or Content Providers who require access to CDN analytics. An OMD Director portal instance is a separate setup from the primary OMD Director installation, with its own user database. It provides a Director GUI that is limited to working with the CDN analytics dashboards provided by Insights. You cannot manage or view the CDN configuration from an OMD Director portal instance.

• Media Streamer Core Components:

  • OMD Core Traffic Server: A Traffic Server is an HTTP/S proxy cache that is deployed as either an “edge” or “mid-tier” cache server to form a two-tiered CDN hierarchy. Traffic Servers are fast, scalable, extensible using plug-ins, and HTTP/1.1 compliant.

  • OMD Core Traffic Router: A Traffic Router is a CDN load balancer that redirects HTTP(s) client requests to an edge cache to ensure that the end user is connected to the optimal cache. The Traffic Router determines which cache to redirect a request to based on client proximity, cache load, and content affinity. The Traffic Router is authoritative for the CDN domain and it implements DNS and HTTP routing.

  • OMD Core Traffic Ops: Traffic Ops is an open source management system used to configure advanced settings of the Media Streamer CDN.

• OMD Insights: OMD Insights is an application that provides CDN application level insights including operations, content popularity, user consumption, and quality of service (QoS). OMD Insights is based on Splunk and aggregates the log data from all of the Traffic Servers and Traffic Routers.

• OMD Monitor: OMD Monitor is an application that provides in-depth server monitoring, threshold crossing, and alarming based on CPU utilization, port utilization, temperature, disk I/O, and other detailed server metrics.

Cisco Open Media Distribution (OMD) Director is a cloud-based element management system that provides provisioning, monitoring, analyzing, alerting, and role-based management for Cisco Media Streamer. OMD Director is a common management system for both Cisco Media Streamer and Cisco Media Broadcaster (multicast ABR live distribution to managed homes). When Cisco Media Broadcaster is deployed with the Cisco Media Streamer solution, a common OMD Director instance is used to provision, monitor, and analyze both the unicast CDN of Media Steamer and the distribution of multicast streams by Media Broadcaster.

Note	For more information on Cisco Media Broadcaster, see Cisco Media Broadcaster Overview.

Cisco OMD Director is the primary user interface for the Cisco Media Streamer solution. It provides a unified interface to seamlessly manage the different components of the Media Streamer platform. OMD Director enables the administrator to rapidly provision new CDNs and caches, and integrates monitoring, alerts, and real-time analytics into a single management tool.

Cisco OMD Director is implemented to be virtualized and further optimized with microservices in containers. Microservices provide modularity between components of the system enabling individual microservices to be replaced, upgraded or scaled up independently of one another. Microservices never share data directly via a database, only through their external APIs and each microservice is responsible for maintaining its own data store.

OMD Director is made up of the following microservices, which are packaged as Docker containers:

• GUI: A user-facing application that makes calls to the provisioning and monitoring services to enable operators to perform various configuration tasks, monitor the data being reported by various system components, and troubleshoot the CDN.

• Provisioning: This microservice is responsible for the software installation and configuration of all servers under the control of OMD Director, which includes the instantiation of new virtual machines (VMs) as needed for the initial system setup or elasticity purposes. It provides backend support for CDN configuration and provisioning operations available via the GUI.

• CDN Manager: The CDN Manager microservice contains much of the business logic inside of OMD Director. This microservice is responsible for the initial setup of the CDN and ongoing updates to CDN topology and delivery services. The CDN Manager microservice communicates with potentially many downstream services such as the Provisioning microservice, Traffic Ops, Sensu, Site24, Insights, and more to accomplish these tasks.

• Monitoring: This microservice is a set of utilities for evaluating the health and performance of the CDN. It exposes an API that aggregates data from the CDN application, Server Health and Element Level Monitoring, Service Level Agreement (SLA) Monitoring, Business Intelligence Analytics, and Quality of Experience Monitoring. While these sources are external to OMD Director, it is the responsibility of OMD Director to integrate them into a single coherent view of network health.

• Alarms: This microservice stores and manages alarms and notifications for OMD Director. It reads monitoring data written to an Influx database by clients and generate alerts if the values exceed configured thresholds. It also manages generated alarms and allows users to adjust thresholds for alarms.

• User Management: This microservice is responsible for securing access to the OMD Director APIs. It authenticates user requests and controls which operations users can execute and it maintains an audit log of all operations performed within the User Management microservice.

• Backup: This microservice is responsible for running the scheduled back ups for the OMD Director databases and performing the OMD Director database restores upon request.

• HA: This microservice is responsible for supporting the high availability (HA) functionality in a high availability OMD Director configuration.

With containers comes the need to manage them. The individual microservices must be started, stopped, upgraded, and monitored. Docker Engine provides CLI tools to manage containers, but only on a single host. OMD Director uses Kubernetes to manage the Docker containers across the nodes in the OMD Director installation.

Cisco OMD Monitor is an application that provides in-depth server monitoring, threshold crossing, and alarming based on CPU utilization, port utilization, disk I/O, and other detailed server metrics for a CDN solution. OMD Monitor enables you to monitor your CDN caching performance including being able to view the key analytics information of all of the CDN Edge caches and Mid caches, system-level statistics for individual cache servers, and CDN alarms that have been generated.

With Cisco OMD Monitor, a Monitor Control node contains the necessary services to provide the following functions:

• Collect metrics and check results from a network of Monitor clients

• Store one month of metric data in an InfluxDB database that is available for querying

• Generate emails for warning and critical alerts

• Provide an Uchiwa GUI to manage and check metrics results and alerts

• Provide a Grafana GUI that displays configurable dashboards with graphs of metrics sourced from an InfluxDB

Currently CDNs are used to rapidly and cost-effectively deliver a wide variety of content to numerous end points. Each CDN generates huge volumes of data in the magnitude of Gigabytes and Terabytes. Considering the size of the CDN, a well-defined solution is required to handle the following:

• Log management

• Capacity planning

• Derive metrics to understand QoS and QoE

• Forecasting exercises

• Infrastructure management

OMD Insights can help provide these features. OMD Insights is a comprehensive analytics solution that provides meaningful CDN insights, thereby enabling CDN operators and Content Providers to optimize content delivery by accurately measuring QoS and QoE. OMD Insights is based on Splunk and aggregates the log data from all of the Traffic Servers and Traffic Routers.

OMD Insights provides deep analytics of the OMD environment that is based on mining data from the HTTP log entry of each Traffic Server. This enables OMD Insights to provide comprehensive CDN operational analytics, including analysis of throughput, utilization, and efficiency of video content delivery. It also provides insight into viewer trends. OMD Insights captures real-time data from CDN logs to provide simplified access to actionable data and analytics, so that operation teams can proactively monitor activity and take action before problems occur. It also delivers comprehensive dashboards and trending reports that capture valuable information for CDN capacity planning and delivery optimization. In general OMD Insights provides transaction logging and application level analytics.

Cisco OMD Insights provides the following:

• Centralized log repository

• Configuration of the reporting topology

• Precanned reports and dashboards to help with forecasting exercises

• Near real-time dashboards

OMD Insights is based on Splunk and aggregates the log data from all of the Traffic Servers and Traffic Routers. Splunk is a powerful analytics tool that can be used in various ways. Splunk can turn machine data into valuable insights regardless of what format the data is in. OMD Insights can use the power of Splunk to enable customers to get value from their data.

Cisco OMD Insights provides the following important steps of any analytics solution:

• Gets logs

• Stores logs

• Maintains logs

• Makes Insights available

The MC-controller is an application that runs on a Linux operating system (bare metal, virtualized, or containerized) in the service provider premise. The main functions of the MC-Controller are:

• Distributes the configuration data to the Multicast Sender (MC-Sender) and Multicast Receiver (MC-Receiver).

• Collects stream status messages from MC-Receivers. These messages include channel viewing and streaming statistics.

• Communicates the channel lineup, which defines which streams to distribute on which multicast addresses, to the MC-Senders.

• Communicates to the MC-Receivers which streams to join and the associated multicast addresses (channel lineup).

• Provides two approaches to determine when to multicast a stream: policy-based or popularity-based. The policy-based approach statically configures a stream to multicast; it does not depend on a certain number of viewers to requesting the stream. The popularity-based approach enables streams to start and stop multicasting based on crossing configured concurrent viewer thresholds.

• Exports data to a Cisco Media Broadcaster element management system.

The MC-Controller contains the following subcomponents:

• Broadcaster Configuration Manager (BCM): The BCM retrieves and writes configuration data to the underlying data store (etcd) and versions every stored system configuration. It is the backend to OMD Director, which is the Media Broadcaster configuration management GUI, and is responsible for serving the configuration data to the MCM.

• Multicast Controller Manager (MCM): The MCM polls the BCM at intervals to retrieve configuration data. It is the management component of an MC-Controller and controls the entire Cisco Media Broadcaster system. It also aggregates viewership data received by the SSR.

• Data Store Service (etcd): The etcd service stores all of the configuration data for the BCM.

• Stream Status Receiver (SSR): The SSR handles all of the incoming Stream Status messages and Config Requests from the MC-Receivers, also referred to as the Embedded Multicast Client (EMC). To handle the load of incoming Stream Status messages, there will be many instances of the SSR.

The MC-Sender is an application that runs on a Linux operating system (bare metal, virtualized, or containerized) in the service provider premise. The primary functions of the MC-Sender are:

• Acquires a live ABR stream from the CDN or origin server using unicast HTTP/TCP requests and encapsulates the video data and FEC for multicast distribution.

• Transmits the data packets as a multicast stream to the multicast address group.

• Provides rate pace for the multicast video distribution rate.

• Can optionally provide QoS marking (DSCP) on the multicast data.

The MC-Sender contains the following subcomponents:

• Multicast Server Interface (MSI): Is the interface that the MC-Sender uses to communicate with the MC-Controller.

• Multicast Sender Manager (MSM): Creates, destroys, and configures individual MSA instances to convert a single ABR profile to a multicast stream.

• Multicast Sender Application (MSA): Acts as an HTTP client that pulls ABR content (manifests and segments) from the CDN and then sends out the segments using NAC Oriented Reliable Multicast (NORM) to all of the gateways. Each MSA delivers only one stream. Because each MC-Sender is capable of delivering many streams, an MC-Sender will have many MSAs.

The MC-Receiver, also referred to as the Embedded Multicast Client (EMC), is an application that can be integrated into the STB or home router that resides in the managed home of the service provider and runs in the CPE middleware operating system. The primary functions of the MC-Receiver are:

• Streams HTTP/TCP unicast video to HTTP ABR media player.

• Implements a proxy cache toward the HTTP media player.

• Acquires (ingests) ABR video using multicast or unicast, with transparent switching, and fills the proxy cache.

• Caches reliable fragmented HTTP video (HLS, DASH, and HSS)

• Provides packet error repair using in-band FEC when possible, and falls back to unicast HTTP retransmit from CDN.

• Streams to in-home multiple media player clients a common stream or multiple unique streams.

  The MC-Receiver intercepts ABR fragment requests from the end clients (iPads, iPhones, and STBs) and does one of the following:

• If the MC-Receiver has already received the requested content via multicast and still has it in its local cache, it will serve that content back to the end clients (iPads, iPhones, and STBs) without forwarding the request upstream to the CDN.

• If the MC-Receiver does not have a copy of the content in its cache, then it proxies the request upstream to be fulfilled by the CDN. When the response is returned from the CDN, the MC-Receiver will cache this content in its local cache so that it can provide the content for future requests from downstream clients for the same content.

The MC-Receiver consists of the following components:

• Proxy Service: Intercepts requests from downstream end user ABR clients and serves them using data from the local cache of the CPE (if available). If the content is not in the local cache of the CPE, the proxy requests the content from the CDN using unicast. The Proxy service will receive the configuration from the MC-Controller, which will determine which streams can be delivered using multicast. For any ABR client requests that can be delivered using multicast, the Proxy service will start a Multicast Receiver for that stream. When the ABR client stops watching the stream, the Proxy services will stop the Multicast Receiver for that stream. The Proxy Service can be thought of as part of the Control Plane.

• Multicast Receiver: The Multicast Receiver uses NORM with FEC to receive multicast content from the MC-Sender. After the content is received, the proxy service stores it in the local cache on the CPE. The MC Receiver will leave a multicast stream when no requests from any player has been received for certain amount of time. The Proxy service will determine when a Multicast Receiver needs to be started and stopped. The Multicast Receiver can be thought of as part of the Data Plane.

What content is delivered by the Cisco Media Broadcaster deployment is defined using a channel lineup. A channel lineup defines where to find the content, and what address and bit rate will be used for multicasting the content. The channel lineup is stored in the MC-Controller and is communicated to the MC-Sender via a StartMulticastReq message. When the MC-Sender receives a StartMulticastReq message, the MC-Sender sends an HTTP request for the manifest to the CDN. After receiving the manifest file, the MC-Sender starts to request the segments that are defined in the manifest and transmits them via reliable multicast (NORM) over the video network interface. MC-Sender continues the same operation of getting the latest manifest, requesting for segments based on the manifest and transmitting them via multicasting for a given video stream until the MC-Controller sends a StopMulticastReq message.

Channel lineups are configured in OMD Director and can also be imported into OMD Director using a CSV file.

For more information on configuring the channel lineups, see the Cisco Media Broadcaster User Guide.

A Broadcasting Group identifies which MC-Controllers and MC-Senders work together to provide multicasting services for a group of channels. All of the MC-Controllers and MC-Senders in a broadcasting group will use the same filtering rules and server specific settings. Broadcasting groups are part of the high availability (HA) solution of Media Broadcaster.

Cisco Media Broadcaster provides a fully redundant solution for the MC-Controllers and MC-Senders. Media Broadcaster supports an Active/Standby HA solution for the MC-Controller components. For the MC-Senders, all MC-Senders run simultaneously, but handle different multicast streams. If an MC-Sender becomes unavailable, all of the multicasting streams that were running on that MC-Sender are automatically redistributed to by the MC-Controller to the remaining MC-Senders based on the bandwidth usage of each MC-Sender.

To deploy Cisco Media Broadcaster, there are certain requirements that must be met in the proposed deployment network:

• Multicast v1: The access network (i.e. the network between the MC-Sender and gateways) must support traffic sent over multicast v1 all the way to the gateways. This is necessary to propagate the traffic from the MC-Senders to all of the gateways downstream.

• HLS, DASH, and HSS: Currently the Cisco Media Broadcaster supports HLS, DASH, and HSS ABR formats.

To operate correctly, the MC-Receiver must function as a proxy through which all media player requests must pass. This is necessary so that the proxy can intercept content requests and have the opportunity to fulfill the requests from the content in its local cache.