The TV CDS enables cable operators and multiple service operators (MSOs) to offer VOD and MediaX services to consumer customers over their existing hybrid fiber coaxial (HFC) network, with existing next-generation digital STBs. The TV CDS solution uses a gigabit Ethernet (GE) transport network from the headend to the distribution hub, where the HFC network terminates.
TV CDS grows seamlessly from a single server implementation to multiple servers. As growth continues, TV CDS allows operators to install distributed servers to address concentrations of subscribers while leaving content ingest and management centralized.
Stream Groups can be distributed close to the subscriber and linked back to the central Vault locations by way of the Cisco Cache Control Protocol (CCP). Cisco CCP automatically ensures that any new content that is required by a customer edge device is transferred within a maximum of a 250-millisecond delay to the appropriate edge location; as a result, all content appears local to each edge site, even though most content is stored at the central Vault location.
The TV CDS offers different configurations with regards to network topology, business management systems (BMSs), and streaming modes.
CDS with Vaults and Streamers
In a TV CDS with Vaults and Streamers, MPEG-2 transport stream (TS) video is stored on the Vaults with the associated trick-mode files. Content is transported from the Vaults to the Streamers as needed, by using CCP over gigabit Ethernet networks. Content is sent unicast from the Streamers and delivered to the quadrature amplitude modulation (QAM) devices over gigabit Ethernet or asynchronous serial interface (ASI), and then modulated onto the HFC plant to the subscriber set-top box (STB) for viewing.
CDS with ISVs
For the smallest networks, Cisco packages the CDS in a single server, the Integrated Streamer-Vault (ISV), offering a solution for VOD services with large content libraries but small stream counts.
In a TV CDS with ISVs, MPEG-2 TS video is stored on the ISV servers with the associated trick-mode files. Content is sent unicast from the ISVs and delivered to the QAM devices over a gigabit Ethernet network, and then is modulated onto the HFC plant to the subscriber STB for viewing.
CDS with Caching Nodes
For larger networks, Cisco offers the CDS with Caching Nodes in the Virtual Video Infrastructure (VVI). In a VVI, Caching Nodes are the intermediary fill source for Streamers, which removes a large portion of the distribution traffic from the Vaults.
In a TV VVI, MPEG-2 TS video is stored on the Vaults with the associated trick-mode files. Content is transported from the Vaults to the Caching Nodes as needed, by using CCP over gigabit Ethernet networks. Content is distributed from the Caching Nodes to the Streamers as needed, by using CCP over gigabit Ethernet networks, or by using HTTP over gigabit Ethernet networks. Content is sent unicast from the Streamers and delivered to the QAM devices over a gigabit Ethernet network, and then is modulated onto the HFC plant to the subscriber STB for viewing.
TV CDS Topologies and VVI Topologies
The TV CDS (using Vaults and Streamers, or ISVs) and the TV VVI (using Vaults, Caching Nodes, and Streamers), supports centralized, decentralized, and hybrid gigabit Ethernet network designs. Because the use of Vaults and Streamers separates storage from streaming, streaming requirements can be satisfied on an as-needed basis and the streaming can be centralized or distributed among multiple locations. Caching Nodes separate the ingest and storage of content from the distribution of content, offering greater flexibility and network efficiency.
The TV CDS topology and TV VVI topology can change with the evolving needs of the system operator. If the need to decentralize becomes evident, you can move the Streamers or Vaults to remote hubs without disrupting service. The VVI offers additional flexibility in designing your network. Vaults can be centrally located at a national network, and content may be classified by market (city, state, or a broader region) depending on the AMS or BMS used. Caching Nodes can be located centrally, or distributed closer to the regional networks where the Streamers are located. Using Caching Nodes in the network design takes the distribution traffic off the network backbone.
Caution All Cisco servers are connected through a switch. Because all Vaults, CCP Streamers, and Caching Nodes in the same array exchange heartbeat messages through the cache interfaces, it is important to ensure there is enough bandwidth among switches involved in delivering cache traffic, as well as to support the same aggregated amount of traffic on all cache interfaces.
NoteWhen using ISVs, with the Vault and Streamer functions contained in one server, the only topology possible is centralized.
In a centralized topology, both Vault and Streamer servers are located in either a single video headend or a remote hub. This is the right solution for certain situations, for instance, very small starting systems or where a large amount of bandwidth is available. A centralized topology has advantages in reducing operational cost by placing equipment in one physical location.
The decentralized topology is a hub-and-spoke topology between the headend site and multiple hub sites, where the Vault servers are located at the headend and the Streamer servers are in the hub sites. For a VVI, a decentralized topology provides a three-tiered approach by having the Vaults located in the headend, the Caching Nodes in intermediary sites, and the Streamers in the hub sites. The decentralized topology works well for distributing Streamer Groups close to subscribers. A decentralized topology has advantages in reducing the amount of long-haul fiber transport bandwidth needed—typically by a factor of ten or better.
In a hybrid topology, the Vault servers and backup Streamer servers are located at the headend, with the active Streamers at a remote hub site. If the remote hub site goes down, the Streamers at the headend take over. A hybrid topology blends the advantages of centralized and decentralized topologies that is based on needs of the system implemented.
TV VVI Management
The TV VVI offers two types of management, centralized and split-domain.
In a CDS, Streamers cannot communicate with Streamers in other groups. In a VVI, Streamers in other groups can communicate with each other on an as-needed basis.
All Vaults, Streamers, and Caching Nodes are identified by an array ID, a group ID, and a server ID. In the CDSM GUI, the array ID identifies servers that are part of the same system. The group ID identifies servers that are part of the same group (Vault Group, Cache Group, and Stream Group), and the server ID is a unique number that identifies the server. Table 2-1 lists the CDSM GUI ID names and maps them to the CServer names in the setupfile and .arroyorc files.
Table 2-1 ID Names in the CDSM GUI and CServer Files
Array ID on the Array Name page
Group ID on the Server-Level pages
Stream Group ID on the Server Setup page
Cache Group ID on the Server Setup page
Vault Group ID on the Server Setup page
Stream Group ID on the Configuration Generator page
Centralized management uses one Virtual Video Infrastructure Manager (VVIM) to manage the Vaults, Caching Nodes, and Streamers in a VVI.
Split-domain management uses one VVIM to manage the domain of Vaults and Caching Nodes, and separate managers, the Stream Managers, to manage each domain of Streamers.
In a split-domain VVI that uses HTTP for communication between the Caching Nodes and Streamers, the databases for each domain are separate. The information stored in each database is not shared with the servers in the other domains. The Stream Managers communicate with the VVIM over port 80. If port 80 is not open for communication, the managers cannot communicate with each other and configuration settings need to be uploaded to the Stream Managers from information downloaded from the VVIM.
In a split-domain VVI that uses CCP for communication between the Caching Nodes and Streamers, the database is replicated among all servers in the Vault/Cache domain and the Stream domains. Because the VVI allows intercommunication among different Cache Groups and Stream Groups when CCP Streamers are used, the server ID and group ID must be unique across the system. The Stream Managers communicate with the VVIM by using the database replication.
NoteSplit-domain management is supported in an RTSP environment, and an ISA environment with the Content Storage feature and CCP Streamers.
Content is ingested and stored in the Vault array. The Vault array consists of two or more Vault Groups, which in turn consists of two or more Vaults that are either colocated or distributed to multiple locations across an Ethernet network. Content ingest is initiated by the backoffice based on a subscriber request, and based on schedule or barker channel content. Manual ingest, which is operator initiated, is also offered as an optional feature.
NoteThe ability to differentiate between a DVD asset and a video asset to support ingest, trick-play creation, and streaming of content files as large as 120 GB is supported. The content files could span multiple days.
As the content is ingested into the Vault, any necessary trick-mode files are created. The content and trick-mode files are then mirrored within the same Vault or across the Vault array. The replication of content allows for data recovery should a Vault undergo a failure.
Content is delivered from the Vault array to the Streamer array in response to cache-fill calls from the Streamers to fulfill subscriber requests for VOD content. Content is also distributed across the network in response to scheduled or barker stream content fulfillment.
If a VVI is deployed, content is delivered from the Vault Group to the Cache Group in response to cache-fill calls from the Streamers. The Caching Nodes are explained in more detail in the “Caching Node Workflow” section.
Within the Streamer array are one or more Stream Groups. The following section describes how the Stream Groups deliver streams to the subscriber STBs.
NoteAll servers can be on different subnetworks. However, because of backoffice restrictions, the externalized IP address is constrained to migrate among servers on the same subnetwork. This means the content store server in an Interactive Services Architecture (ISA) environment can migrate only among Vaults that are on the same subnet, and the Setup and Control servers can migrate only among Streamers on the same subnet.
Popularity-based caching reduces the write rate to the storage devices on the Streamer and Caching Node while maintaining the best possible cache-hit rate on the available storage.
To control peak and average write rates to cache (flash or disk storage), the algorithm that determines when content is written to cache is changed so that only content that is likely to be accessed most often is cached. Content is only cached if it is more popular than the least popular content that is currently cached. Otherwise, the content is transmitted from the Vaults to the end-users by way of the cut-through mode, where content is temporarily stored in the Streamer and Caching Node RAM without ever writing it to disk or flash storage, and then streamed directly from the Streamer’s RAM to the end-user. When cache space is needed, the least popular content is evicted from cache first.
The write rate for caching content is determined by the rate at which previously popular content becomes less popular to the point where it no longer makes sense to keep it in cache, and previously unpopular content becomes more popular to the point where it does make sense to keep it in cache. Content popularity is measured by the time-decaying average of the number of play requests on each Global Object Identifier (GOID).
Previously, all content was written to cache (except when overloaded) and the Least Recently Used (LRU) content was evicted first.
With the Popularity-Based Caching feature, only popular content is written to cache and the least popular content is evicted first.
Bandwidth Manager for Thin Pipe
The bandwidth manager controls the traffic leaving the site to any other site and queries all the CDS servers in the site for the thin pipe mapping configuration of each CDS server. One server in the site is elected as the bandwidth manager for all servers in the site. A site is defined by the Site Setup page, which associates groups with a site. Initially, the bandwidth manager allocates bandwidths of whatever the CDS servers have already committed, provided the committed bandwidths are within the pipe bandwidth limits; otherwise, the bandwidth manager allocates a percentage of what is committed. After the initial allocation, the bandwidth manager distributes the bandwidth equally among all the remaining CDS servers in the site.
Each CDS server in each group reports the bandwidth each one is using to the bandwidth manager every ten seconds. The bandwidth threshold for each server has an upper limit of 90 percent and a lower limit of 5 percent. If a server reaches either limit, the server reports this to the bandwidth manager immediately, and does not wait for the ten-second report interval. For example, if the server is given 100 Mbps and the streams that were just started uses 90 Mbps, the upper threshold limit has been reached and the server asks the bandwidth manager for more bandwidth.
A separate entry is maintained for each thin pipe with a list of servers that have the same thin pipe configuration. Servers that belong to the same thin pipe are added and removed as they become reachable or unreachable.
The bandwidth manager service runs on each server in either the primary mode or the passive mode. The one server at the site that is running the primary mode is selected through a discovery mechanism. The primary bandwidth manager maintains all the thin pipes and associated server structures. If the server running the primary bandwidth manager fails or loses connectivity, the newly elected bandwidth manager takes over and when the old primary bandwidth manager becomes available again and connectivity is restored, the thin pipe information and structures are deleted from the old primary.
All bandwidth manager messages are logged in the bwm.log file. The following logging levels are defined (default level is Information):
- Debug Verbose
A Stream Group is a configurable group of Streamers that are designated to serve specified QAM devices, and subsequently, specific service groups. From a session setup and control perspective, there are three logical types of servers in a Stream Group:
- Setup server
- Control server
- Play server
The Setup and Control servers have both a primary and a backup server. The primary server services all messages, while the backup server simply maintains states. If a primary server is unreachable, the backup server takes over control and creates another backup server. Thus, there is always a primary and backup pair of servers for setup and control. The Play server does not have a backup server. However, the Control server selects a new Play server in the event of a failure of the existing Play server.
NoteThe ability to have both a primary and backup server depends on the number of Streamers in the Stream Group.
The Setup and Control server IP addresses are configurable. For an ISA environment, the Setup IP address is the same as the Stream Master IP address. For RTSP, the Setup server and Control server must be the same server. For both ISA and RTSP environments, the Stream Service selects a Streamer in the Stream Group to be the Setup server, and another Streamer (sometimes the same Streamer) to be the Control server.
A Streamer designated as the Setup server interfaces with the backoffice and forwards the setup messages to the appropriate Stream Group that is assigned to the destination service group. One Streamer in the Stream Group that is colocated with the backoffice server is assigned as the primary Setup server. The Setup server receives the setup request from the backoffice and maps the service group.
The Setup server returns the IP address of the Control server, and the STB issues subsequent control messages to this IP address.
The Control server assigns requests to specific Streamers and dynamically migrates streams between Streamers based upon changes in stream states (for example, content splice boundaries, maintenance trickle down, or server failures). One server in the Stream Group is assigned as the primary Control server. The Control server runs the Lightweight Stream Control Protocol (LSCP) proxy in an ISA environment and the Real-Time Streaming Protocol (RTSP) proxy in an RTSP environment.
For each and every setup message received from the backoffice, a CCP message is generated and sent to the Control server. In the initial setup request, the Control server receives the setup parameters but does not choose a Play server. After a control message is received from the STB, the Control server gets performance information (for example, server load) from the potential Play servers within the Stream Group and sends a CCP message to the best candidate. Subsequent control messages, whether from the STB or from the Setup server, are forwarded to the chosen Play server.
The Play server is the Streamer that is assigned to play the stream. This Streamer acquires the content, whether in RAM, a local disk, or a Vault, and ensures guaranteed service delivery of the stream. Every Streamer in a Stream Group is a possible candidate to be the Play server.
Caching Node Workflow
A Cache Group is a configurable group of Caching Nodes that serve content to specified Stream Groups. When a content request is received by a Streamer, the Streamer first checks to see if the content is stored locally, which includes DRAM, disk cache, and Streamers in the same Stream Group. Content on the Streamers is always the most popular content, so user requests are generally served from local storage.
Streamers send cache-fill calls to remote servers for content that is not found locally. The remote servers can be Streamers in other Stream Groups, Caching Nodes in Cache Groups, or Vaults in Vault Groups (Vault Groups must be enabled). The cache-fill source selected, whether another Streamer, Caching Node, or Vault, is based on the network capacity and fill-source capacity (disk and memory), as well as on the preference configured for that group of servers. Caching Nodes could respond to the request with a message stating the content is not currently cached, but there are other fill sources the Caching Nodes can contact (Caching Nodes in other Cache groups, and Vaults).
The Caching Nodes use CCP to communicate with the Vaults, and use either CCP or HTTP to communicate with Streamers.
NoteISA environments only support CCP, while RTSP environments only support HTTP for VVI.
HTTP can be used for communication between the Caching Nodes and the Streamers. The HTTP Streamer communicates with a proxy for locating a fill source and pulling content.
A locate service serves as a proxy for a group of Caching Nodes and Vaults. The service is accessed through a highly available virtual IP address hosted by the Caching Node. The virtual IP address is bound to a fill port (Locate Port).
HTTP Streamers request content by HTTP GET requests to the proxy service (the server with the locate service). The proxy server checks its own storage and peer fill sources (servers in the same group) for the content using extended-CCP. If the content is found, the best source is chosen based on capacity and a redirect response is sent to the chosen server. If the content is not found, a cache-fill request is sent to the remote servers.
After the best server is chosen to send the content to the HTTP Streamer, a single cache-fill port on that server is chosen for the HTTP transfer of the content. This is different from CCP transfers, which could potentially use all cache-fill ports to deliver the content.
HTTP Locate Port
With respect to resiliency, the Locate Port service is similar to the Setup and Control servers. The primary server of the Locate Port service has the locate port IP address bound to an interface. The backup server becomes the primary if the primary fails.
Peer Caching Nodes advertise among themselves about the ability to host the HTTP Locate Port Service, this includes primary, backup, available, and not usable states. Available means the Caching Node can be either a primary or backup if needed. Not usable means that the server cannot host the service; for the HTTP Locate Port, this typically means that there are no usable network ports for the service.
A dedicated network port on the Caching Node is used solely for the HTTP Locate Port service. The primary server determines service availability based on the link status of the dedicated network port. Failover of the service occurs if the network port loses link status. A reestablished link results in the server becoming available.
The CCP Streamers use CCP to communicate with the Caching Nodes. They do not use the proxy address that was assigned to the Locate Port for HTTP Streamers. CCP Streamers load-balance locate requests across fill sources.
The Streamer or Caching Node sends a locate-and-request message from the proxy server. The Proxy server sends a message to the best source to fill the request.
Streamers or Caching Nodes needing content first query peer sources (servers within the same group). Streamers also query local Streamers, if the content is not found, then a request to the remote sources is sent. Remote sources are queried based on a preference list. Sources are grouped and preferences are assigned for each group.
The Vaults ingest content using three different methods:
- FTP pull
- FTP push
- Live capture of MPEG-2 transport streams over UDP
With FTP pull, the original content is kept on an FTP server (catcher), for a period of time and mechanisms are in place to restart ingests until they have successfully completed.
With FTP push, only a window of data is buffered by a device that grooms the live (broadcast) feed and pushes the data to the Vault.
With live capture over UDP, the Vault captures the live multicast feed directly.
nDVR Support for NGOD Deployments
The nDVR feature for the RTSP NGOD deployment provides the following capabilities:
- Streamers can distinguish between requests for VOD content and requests for DVR content
- Streamers route cache-fill requests for VOD content to CDS servers (Vaults, Caching Nodes, and other Streamers)
- Streamers route cache-fill requests for DVR content to third-party sources (nDVR Recorders)
- Streamers generate trick-mode files for DVR content
- Streamers generate GOIDs for DVR content and associated trick-mode and index files
- Streamers support unique copy DVR content
In previous releases, Streamers received cache-fill content from Vaults, Caching Nodes, and other Streamers by way of the Cisco Cache Control Protocol (CCP). For RTSP NGOD deployments, the Streamers received cache-fill content from Vaults, Caching Nodes, and other Streamers by way of the C2 protocol.
Streamers are able to receive cache-fill content from CDS servers (by using CCP or the C2 protocol) and third-party sources. The Streamers can route cache-fill requests to Vaults, Caching Nodes, and other Streamers for VOD content, and to third-party sources for network digital video recorder (nDVR) recordings.
The nDVR feature supports unique copy content distribution from a third-party source (for example, nDVR Recorder) to the Streamer, and from the Streamer to end-user devices, which can be an IP set-top or QAM device.
Each content an end-user requests from a device has a unique title ID. For each content, there are different versions based on the encoding that is compatible with the end-user device (for example, high definition [HD] or standard definition [SD] for a STB or mobile device, as well as resolution formats), which are identified by content IDs. When a request for content is sent from the end-user device to the backoffice, it includes the title ID. The backoffice maps the title ID to the content ID for the content that is compatible with the requesting device. The backoffice uses the content ID when communicating with the Streamers on what content object to stream to the device.
For some CDNs, the content ID is a combination of the ADI Product ID and Asset ID (PAID), and it is used to convey both VOD and DVR content. Other CDNs send the content ID from the backoffice to the Streamers in a URI. For the RTSP NGOD deployment, nDVR content is identified with a URI, and VOD content is identified with a PAID.
Each unique content can have several unique data objects required for playback; such as the normal video object for standard forward playback, video objects for trick-mode content, and an index file used to map playback time offsets to corresponding data offsets within the various video files. This information can be referred to as vendor-specific content metadata, or asset metadata.
The Cisco TV CDS software uses a global object ID (GOID) to identify the different video and index data objects for a unique content. The TV CDS software contains an association of the content ID with the various GOIDs used to store the different objects for the content.
To support nDVR, Streamers use the third-party object identifier in cache-fill requests. The Streamer not only stores the content ID to GOID mappings, but also a GOID mapping to an external object identifier which is generated by the third-party vendor. In addition, to support cache-fill from third-party vendors, Streamers generate the GOIDs. The generated asset metadata is revalidated to ensure specifically that the PAID-to-GOID-to-external object mappings are still valid.
Streamers are used for streaming out regular VOD content sourced from other CDS servers or DVR content sourced from the Recorders. The Streamers route the cache-fill request to the appropriate source based on the content type, which is derived from the asset name space.
A Streamer must know the origin from which the needed object is sourced when performing cache-fill. Normally, a Streamer is configured with static routes for cache-fill. The Streamer must be configured with different source routes for the different content types.
For VOD content, the content identifier is a PAID. For DVR content, the content identifier is a URI, which contains the hostname or IP address of the third-party source (nDVR Recorder).
The C2 protocol is used for cache-fill of DVR content from the nDVR Recorders.
A request for VOD content is identified by the Provider ID and Asset ID (PAID). A request for DVR content is identified by a URI. The Setup server receives the URI or PAID over the R2 protocol in a NGOD RTSP deployment.
The R2 setup request from the backoffice to the Setup server sends a URI for DVR content to be played. The URI includes the routing and protocol information necessary to cache-fill the DVR content. Content is identified by a URI instead of a PAID.
DVR content can be categorized as unique copy or common copy. Unique copy is a recording of content that belongs to a single subscriber. The Streamers perform cache-fill of unique copy recordings directly from the Recorders. Consideration is made such that any unique video content that is cached is only performed for a transitory period.
NoteOnly unique copy DVR content is supported
For unique copy recordings, there is no cache gain benefit of a hierarchical caching system, as the recordings cannot be shared across subscribers; therefore, the CDS servers do not cache unique copy DVR content.
Integration with Legacy VBOs
The nDVR feature integrates with legacy video backoffice (VBO) systems; such as Seachange, Axiom, and Ericsson Openstream.
Dynamic Trick-Mode Files
Normally, trick-mode files are generated by the Vaults at the time of ingest. For DVR content, trick-mode files are generated dynamically by the Streamers.
Trick-mode file generation for DVR content is enabled with the Dynamic Trickmodes field on the Configure > System Level > MPEG Tuning page.
Backoffice Considerations for RTSP Environments
The TV CDS integrates with backoffices in an RTSP environments such as ARRIS nABLE, as well as in environments that are a combination of both ISA and RTSP. The backoffice determines the roles and responsibilities of the TV CDS.
The nABLE backoffice uses a combination of eXtensible Markup Language (XML) over Hypertext Transfer Protocol (HTTP) and RTSP for communication between nABLE Headquarters (HQ) and Real-time (RT) components and the CDS. The HQ communicates file-related requests by using XML/HTTP to the Vault server, as well as server status information requests to both the Streamer and Vault servers. The RT communicates with the Streamer server by way of RTSP to establish session setups for multiple, interchangeable VOD flows (RTSP or DSM-CC).
NoteCurrently, configuring the CDS for integration with the nABLE backoffice is performed by Cisco field engineers. For more information on integration of the CDS with the nABLE backoffice, contact the Cisco technical support department.
Figure 2-1 illustrates how the CDS integrates with the nABLE backoffice.
Figure 2-1 TV CDS Integration into the nABLE Backoffice
The Ingest Steering feature offers the ability to have one backoffice send ingest information to the master Vault, and depending on the product ID, the content is ingested by one of the Vaults in one of the Vault Groups. The backoffice uses the Ingest Manager to ingest packages, including content. As specified in the ADI 1.1 Specification, there is an ADI XML file for each package and the Product ID is one attribute in this ADI XML file.
NoteThe Ingest Steering feature requires that Vault Groups be enabled.
FSI resiliency is supported for Ingest Steering. The Master Vault selects the backup recording server from the same Vault Group as the primary recording server. If there is no available server, other than the primary recording server, then no backup recording is performed.
Figure 2-2 shows a high-level view of Ingest Steering for a single, centralized backoffice and two Vault sites with two Vault Groups each. Each Vault Group ingests content based on the mapping configuration between the product ID and the Vault Group. Each Stream Group has access to all content. The backoffice sends messages to the master Vault Group (Vault Group 1), and depending on the product ID and the ingest steering configured, the content is ingested by one of the Vault Groups.
Content objects on the Site 1 Vault Groups are mirrored among each other, while the content on the Site 2 Vault Groups are mirrored among each other. There should be no mirroring between Site 1 and Site 2.
Figure 2-2 Ingest Steering
Multiple Vault Groups by Stream Service
The Multiple Vault Groups by Stream Service feature supports associating specific Vault Groups with a specific stream service. Each stream service, high definition (HD), standard definition (SD), live ingest, and Video On Demand (VOD) can have a dedicated Vault Group. The ingest policy configured in the Ingest Steering page determines which Vault Group ingests the content for each stream service. The product ID field in the Ingest Steering page identifies what type of stream service the content is for, and the content type is mapped to the associated Vault Group.
Enable both Ingest Steering and Ingest Manager in the CDSM Setup page. Use the product ID field in the Ingest Steering page to determine the stream service type and associate it with the appropriate Vault Group.
The network connections for a TV CDS with Vaults and Streamers, a TV CDS with ISVs, and a TV VVI with Caching Nodes all have different network connections. Table 2-2 lists the different required interfaces for each CDS server. The interfaces are described in the following sections. Figure 2-3 illustrates a TV CDS with Vaults and Streamers. Figure 2-4 illustrates a TV CDS with ISVs. Figure 2-5 illustrates a TV VVI with Caching Nodes.
Table 2-2 CDS Interfaces
1 to 8
1 to 13
1 to 4
1 to 12
1 to 13
1 to 4
NoteTable 2-2 lists the mandatory interfaces for each CDS server. If HTTP Streamers are used in a VVI, each Caching Node must have one interface designated as the Locate interface. Stream Control is an optional interface function. For more information, see the “Configuring the Interfaces” section.
Figure 2-3 shows the different logical networks of a CDS consisting of Vaults and Streamers. The ingest network receives content from the content source by way of an FTP staging server or FTP catcher and the content is ingested by the Vaults. The management network consists of communication between the CDSM and the backoffice, as well as communication with the Vaults, Streamers QAM devices, and STBs. The cache network consists of Vaults and Streamers.
Figure 2-3 Vault and Streamer Network Connections
Figure 2-4 shows the different logical networks of a CDS consisting of ISVs. The ingest network receives content from the content source by way of an FTP staging server or FTP catcher and the content is ingested by the ISVs. The management network consists of communication between the CDSM and backoffice, as well as communication with the ISVs, QAM devices, and STBs.
Figure 2-4 ISV Network Connections
Figure 2-5 shows the different logical networks of a VVI. The ingest network receives content from the content source by way of an FTP staging server or FTP catcher where it is ingested by the Vaults. The management network consists of communication between the CDSM and backoffice, as well as communication with the Vaults, Streamers, Caching Nodes, QAM devices, and STBs.
Figure 2-5 VVI Network Connections
The ingest interface takes in FTP traffic from the content provider at a maximum rate of one gigabit per second. After the Vault server receives URL information about the content from the backoffice by using the management interface, the ingest interface either (1) receives FTP traffic by acting as an FTP client, or (2) receives live data upon receiving a request to act as the FTP server.
When using Layer 2 packet forwarding, to segregate all ingest traffic through the switching fabric, we recommend the use of a port-based VLAN.
The management interface communicates with the network management system (NMS) by way of SNMP, the backoffice by way of ISA commands and also RTSP, and with all Vaults, Caching Nodes, and Streamers in the same array. Information shared among servers in the same array includes the following:
- Host service information
- Domain Name System (DNS) service information
- QAM gateway information
- All ISA information
Management traffic is low volume; however, when using Layer 2 packet forwarding, we recommend using a port-based VLAN to ensure delivery of critical management communications.
The CCP uses the cache interfaces on the Vaults, Caching Nodes, and Streamers to send the following data to the servers in the same array:
- Content sent to the Streamers
- Content mirrored among the Vaults
- Messages containing information used for performance optimization exchanged among all the CDS servers
NoteAll Cisco CDS servers are connected through a switch fabric. Because all Vaults, Caching Nodes, and Streamers in the same array exchange heartbeat messages through the cache interfaces, it is important to ensure there is enough bandwidth among switches involved in delivering cache traffic and to support the same aggregated amount of traffic on all cache interfaces.
When using Layer 2 packet forwarding for cache traffic, we recommend the use of a port-based VLAN.
The cache/stream interfaces on the Streamer server can be used for both cache and streaming traffic. The number of interfaces designated for each traffic type is configurable. If an interface is configured for both cache and streaming traffic, priority is given to the higher-bandwidth stream traffic, provided cache traffic is able to transmit on other interfaces.
When using Layer 2 packet forwarding for cache and stream traffic, we recommend the use of a port-based VLAN.
The streaming interface delivers streaming traffic consisting of MPEG-2 transport streams to STBs by way of QAM devices.
If an interface is configured for both stream and cache traffic, and the jumbo frames feature is not enabled for stream traffic while jumbo frames is enabled for cache traffic, stream traffic uses 1500-byte packets while cache traffic uses jumbo frames.