Guest

Cisco Videoscape Distribution Suite for Internet Streaming

Release Notes for Cisco Internet Streamer CDS 3.1.0

  • Viewing Options

  • PDF (353.8 KB)
  • Feedback
Release Notes for Cisco Internet Streamer CDS 3.1.0

Table Of Contents

Release Notes for Cisco Internet Streamer
CDS 3.1.0

Contents

New Features

Wholesale CDN

Session and Bandwidth Quotas per Delivery Service

Cache Storage Priority per Delivery Service

Snapshot Counters

Real-Time Exporting of Transaction Logs for Billing and Analytic Reports

URL Signing per Delivery Service

APIs for Wholesale CDN

Enhancements

getDevices Action Added to DeviceApiServlet API

Custom HTTP Header Authentication for Origin Server

Basic HTTP Header Authentication

Challenged HTTP Header Authentication

API Changes for HTTP Header Authentication

Windows Media Ingest Transaction Log

Enhancement to Reading NAS Metadata

Windows Media Streaming SNMP MIB Enhancements

Per-Request HTTP Headers from Redirected URLs

ABR Session Events

Other Enhancements

System Requirements

Limitations and Restrictions

System Limits and Thresholds

Important Notes

Open Caveats

Content Manager

Web Engine

CDSM

Service Monitor

Network

Acquisition and Distribution

CLI

Multicast Distribution

Resolved Caveats

CDSM

Web Engine

Platform

Upgrading to Release 3.1.0

Documentation Updates

Related Documentation

Obtaining Documentation and Submitting a Service Request


Release Notes for Cisco Internet Streamer
CDS 3.1.0


These release notes cover Cisco Internet Streamer CDS Release 3.1.0-b75.

Revised: August 2012, OL-27550-01

Contents

The following information is included in these release notes:

New Features

Enhancements

System Requirements

Limitations and Restrictions

System Limits and Thresholds

Important Notes

Open Caveats

Resolved Caveats

Upgrading to Release 3.1.0

Documentation Updates

Related Documentation

Obtaining Documentation and Submitting a Service Request

New Features

Release 3.1.0 of the Cisco Internet Streamer CDS introduces the Wholesale CDN feature.


Note Multicast Cloud is an early field trial (EFT) feature. For more information, contact your Cisco account representative.


Wholesale CDN

The Wholesale CDN feature offers the ability to configure delivery services with quotas and send real-time information to the Content Delivery Network Manager (CDNM) for managing wholesale (business-to-business) accounts.

The Wholesale CDN feature provides the following functions:

Session and Bandwidth Quotas per Delivery Service

Cache Storage Priority per Delivery Service

Snapshot Counters

Real-Time Exporting of Transaction Logs for Billing and Analytic Reports

URL Signing per Delivery Service

APIs for Wholesale CDN

Session and Bandwidth Quotas per Delivery Service

Setting session and bandwidth quotas per delivery service in the CDS, and associating a delivery service with a content provider (tenant) in the CDNM, provides the ability to manage multiple tenants with different session and bandwidth requirements in the CDNM.

The per-delivery service session quota limits the maximum number of concurrent sessions for that delivery service. The per-delivery service bandwidth quota limits the maximum bandwidth used to deliver content to clients.

The Service Router (SR) enforces the maximum limits (session quota and bandwidth quota) and tracks usage on each Service Engine (SE). The usage data is aggregated across the delivery service. The SR makes session enforcement decisions upon receiving requests to load balance. If the request for content does not exceed the maximum limit (quota threshold), it is routed to the best SE in the delivery service. If the request for content exceeds the maximum limit, the client receives an appropriate error response.


Note The session and bandwidth quotas do not reserve resources, nor do they guarantee service. The quotas only limit the maximum usage of a delivery service.

Release 3.1.0 only supports session and bandwidth quotas for Web Engine progressive download, Web Engine adaptive bit rate (ABR), and Windows Media Streaming. Session and bandwidth quotas are not supported for Flash Media Streaming and Movie Streamer.


Monitoring Session and Bandwidth Quotas

Information on quota allocation, usage, and denied sessions for each delivery service is sent to the CDNM. The CDN operator can monitor changes to the used quotas based on threshold crossing and session management metrics.

The SR transaction log has new status codes for session and bandwidth quotas being exceeded. The show statistics service-router summary command has new counters under "Requests Not Redirected" for "Session limit exceeded" and "Bandwidth limit exceeded."

Alarms and SNMP Traps

Each SE in the delivery service maintains a session counter and a bandwidth counter. The counters are sent to the SR over the keep-alive messages.

The SR aggregates per-delivery service session and bandwidth counters and generates alarms and SNMP traps when session or bandwidth quotas are reached, and when augmented session or bandwidth quotas are reached. Clear alarms and corresponding SNMP traps are also sent when the quotas and augmented quotas return to normal. New incoming requests are still accepted if the quota threshold has been reached. New incoming requests are rejected if the augmented threshold has been reached. Both the quota thresholds and augmented quota thresholds are configurable per delivery service.

For WebEngine, the concurrent session counter increases when a HTTP session is created and linked to a delivery service, and decreases when the HTTP session is torn down.

The following major alarms are generated by the SR if the quota thresholds are exceeded:

DsSession—Session quota exceeded

DsAugmentedSession—Augmented session quota exceeded

DsBandwidth—Bandwidth quota exceeded

DsAugmentedBandwidth—Augmented bandwidth quota exceeded

The quota threshold alarms include the delivery service ID that triggered the alarm. Whenever one of these alarms is raised or cleared the associated SNMP trap is sent (cdsAlarmMajorRaised and cdsAlarmMajorCleared respectively).

The following new OIDs have been added to the CISCO_CDS_SERVICE-ROUTING-MIB:

cdssrRequestsSessionExceeded—Counter of the number of 499 events (not enough sessions)

cdssrRequestsBandwidthExceeded—Counter of the number of 453 events (not enough bandwidth)

Transaction Log Changes

The status field in the transaction logs now reports the status codes for "not enough bandwidth" (453) and "not enough sessions" (499), and a new field, entry-gen-time, has been added to record the time the log entry was generated. Additional fields have been added to report the user agent, mime type, and client type. Table 1 describes the changes to the transaction logs.

Table 1 Transaction Log Changes 

Transaction Log
Field
Description

Web Engine Custom Format

%>s

Status code added for not enough bandwidth (453) and not enough session (499).

%c

New field. Time, in common log time format, that the log entry was generated.

%p

New field. Client that set up the transport session for the request. The value is one of the following:

Local—Request is from this SE.

Internal—Request is from other SE

External—Request is from end user

ABR per Session

status

Status descriptions added for not_enough_bandwidth and not_enough_session.

status-code

New field. Status code added for not enough bandwidth (453) and not enough session (499).

user-agent

New field. Description of client media player. All user-agent values are enclosed in double quotes (" ").

entry-gen-time

New field. Time, in common log time format, that the log entry was generated.

mime-type

New field. MIME type.

WMT extended-wms-90

c-status

Status code added for not enough bandwidth (453) and not enough session (499).

Entry-Gen-Time

New field. Time, in common log time format, that the log entry was generated.

mime-type

New field. MIME type.

client-type

New field. Client that set up the transport session for the request. The value is one of the following:

Local—Request is from this SE.

Internal—Request is from other SE

External—Request is from end user

Service Router

status

Status code added for not enough bandwidth (453) and not enough session (499).


Quota Reporting

Quota usage reporting is automatically sent whenever a session quota or a bandwidth quota is configured for a delivery service with a setting other than zero (zero means no limits are configured).

To monitor the session counter and bandwidth counter when session quota and bandwidth quota are not configured, check the Force Quota Usage Reporting check box for the delivery service.

To enable Force Quota Reporting, do the following:


Step 1 In the CDSM GUI, choose Services > Service Definition > Delivery Services > General Settings. The General Settings page is displayed.

Step 2 Check the Force Quota Usage Reporting check box to enable the per-delivery service snapshot counter.

Force Quota Usage Reporting is enabled automatically when session quota or bandwidth quota is configured with maximum limits other than zero (zero means no limits are configured). For more information, see the "Configuring Session and Bandwidth Quotas" section.

Step 3 Click Submit to save the settings.


Configuring Session and Bandwidth Quotas

To configure session and bandwidth quotas for a delivery service, do the following:


Step 1 In the CDSM GUI, choose Services > Service Definition > Delivery Services > Definition. The Delivery Services Definition page is displayed.

Step 2 Enter the settings as appropriate. See Table 3 for descriptions of the fields.

Table 2 Session and Bandwidth Quota Fields

Field
Description

Session Quota

Maximum number of concurrent sessions allowed for this delivery service. The default is zero, which means no session limits are set for this delivery service.

Session Quota Augment Buffer

Buffer, as a percentage, of the maximum number of concurrent sessions allowed over the Session Quota. If this threshold is exceeded, no new sessions are created until the number of concurrent sessions is below this threshold. The range is from 0 to 1000. The default is 10.

Bandwidth Quota

Maximum bandwidth allowed for this delivery service. The default is zero, which means no bandwidth limits are set for this delivery service.

Bandwidth Quota Augment Buffer

Buffer, as a percentage, of the maximum bandwidth allowed over the Bandwidth Quota. If this threshold is exceeded, no new sessions are created until the bandwidth used is below this threshold. The range is from 0 to 1000. The default is 10.



Note The Delivery Service Quota field has been changed to the Preposition Storage Quota field.


Step 3 Click Submit to save the settings.


Cache Storage Priority per Delivery Service

Assigning a cache storage priority to a delivery service enables the CDN operator with multiple tenants to provide preference settings for keeping cached content for a delivery service. By default, the Content Manager deletes cached content based on popularity (an algorithm involving the number of cache hits, the size of the content object, and the decay of the content object). The cache storage priority setting assigned to a delivery service influences the content popularity and thereby the content that is evicted.

Configuring Cache Storage Priority for a Delivery Service

Each cache storage priority class is identified with a name and has a popularity multiplication factor. The popularity multiplication factor ranges from 0 to 100, where 0 is the lowest priority and 100 is the highest priority. If no cache storage priority classes are defined or assigned to a delivery service, the default multiplication factor of 50 is used.

Following are two examples of how the storage priority class is applied:

Content with a storage priority class of 100 that is accessed once has the same priority as content with a storage priority class of 50 that is accessed twice.

Content with a storage priority class of 0 is always the first to be evicted regardless of how many times the content is accessed.

The storage priority class must first be defined before it can be assigned to a delivery service. To define a storage priority class and assign it to a delivery service, do the following:


Step 1 In the CDSM GUI, choose Services > Service Definition > Storage Priority Classes. The Storage Priority Classes table is displayed.

Step 2 In the task bar, click the Create New icon. The Storage Priority Class Definition page is displayed.

To edit a storage priority class, click the Edit icon next to the storage priority class name.

Step 3 Enter the settings as appropriate. See Table 3 for descriptions of the fields.

Table 3 Storage Priority Class Definition Fields

Field
Description

Class Name

Unique name for the storage priority class.

Storage Popularity Multiplication Factor

Factor used to multiply the popularity of the content by. The range is from 0 to 100, where 0 is the lowest priority and 100 is the highest priority. Content with a Storage Popularity Multiplication Factor of 0 is always evicted first, regardless of popularity calculated. The default is 50.

Comments

Information about the storage priority class.


Step 4 Click Submit to save the settings.

Step 5 Choose Services > Service Definition > Delivery Services > Definition. The Delivery Services Definition page is displayed.

Step 6 From the Storage Priority Class drop-down list, select the storage priority class to assign to the delivery service. The default option sets the Storage Priority Class to 50.

Step 7 Click Submit to save the settings.


If the multiplication factor of a priority class is modified, or the delivery service priority class assignment changed, the change is only applied to new accesses to the content, none of the existing popularity calculations are affected. The storage priority class multiplication factor corresponding to the content is used with each access from the protocol engine. Each access is multiplied with the multiplication factor when updating the popularity.

A priority class definition cannot be deleted if it is assigned to a delivery service. To delete a priority class, first unassign it from all delivery services by changing the setting of the Storage Priority Class, then delete the priority class.

Snapshot Counters

The Snapshot Counter transaction logs for the SR and the SE record usage information per delivery service and can be sent to the CDNM for analytic reporting and billing purposes. For information on configuring the export of these transaction logs, see the "Real-Time Exporting of Transaction Logs for Billing and Analytic Reports" section.

Snapshot Counter Transaction Logs on SR for Session and Bandwidth

The SR Snapshot Counter transaction log records the session and bandwidth usage on the SEs in each delivery service. Each SE sends its own per-delivery service session and bandwidth counters in the keep-alive messages to the SR. Once the SR receives this information, it aggregates the values across all the SEs in the delivery service. Every five seconds the SR writes a log entry to the Snapshot Counter transaction log.

The Snapshot Counter transaction log filename has the following format:

sr_ds_counter_<ipaddr>_yyyymmdd_hhmmss_<>, where

<ipaddr> represents the IP address of the SR

yyyymmdd_hhmmss represents the date and time when the log was created

The Snapshot Counter transaction log file is located in the /local/local1/logs/ds_snapshot_counter/ directory on the SR.

Table 4 describes the fields for the Snapshot Counter transaction log.

Table 4 SR Snapshot Counter Transaction Log Fields

Field
Description

time

Time, in common log time format, the per-delivery service counters were generated on the SE.

se-name

Name of the SE. A value of "-" means the log entry is aggregated for the delivery service.

ds-id

Delivery service ID with "Channel_" as the prefix string.

active-sessions

Number of active sessions for the delivery service.

allocated-bandwidth

Average allocated bandwidth (in bits per second) for the active sessions.


Snapshot Counter Transaction Logs on SE for Storage Usage

The SE Snapshot Counter transaction log on the SE records the storage usage for prefetched content and dynamically cached content. Every 30 seconds the SE writes a log entry to the Snapshot Counter transaction log to record the per-delivery service storage usage.

The snapshot counter transaction log filename has the following format:

se_ds_counter_<ipaddr>_yyyymmdd_hhmmss_<>, where

<ipaddr> represents the IP address of the SE

yyyymmdd_hhmmss represents the date and time when the log was created

The Snapshot Counter transaction log file is located in the /local/local1/logs/ds_snapshot_counter/ directory on the SE.

Table 5 describes the fields for the Snapshot Counter transaction log.

Table 5 SE Snapshot Counter Transaction Log Fields

Field
Description

time

Time, in common log time format, the per-delivery service counters were generated on the SE.

se-name

Name of the SE.

ds-id

Delivery service ID with "Channel_" as the prefix string.

storage-quota-usage-prep

Amount of storage used (in bytes) for prefetched content.

storage-quota-usage-dynamic

Amount of storage used (in bytes) for dynamically ingested content.


Enabling the Snapshot Counter Transaction Log

The per-delivery service snapshot counter transaction log is disabled by default. To enable the per-delivery service snapshot counter transaction log function of a device, do the following:


Step 1 In the CDSM GUI, for an SE, choose Devices > Devices > Service Control > Transaction Logging. The Transaction Logging page is displayed.

For an SR, choose Devices > Devices > General Settings > Notification and Tracking > Transaction Logging. The Transaction Logging page is displayed.

Step 2 Check the Snapshot Counter Log Enable check box to enable the per-device snapshot counter.

Step 3 Click Submit to save the settings.


Real-Time Exporting of Transaction Logs for Billing and Analytic Reports

Transaction logs can be sent real-time from the SE and SR to the CDNM or other export server for use in analytic reports, summary billing records, and detailed transaction records on a per-delivery service basis. The SE and SR use the Splunk Universal Forwarder (UF) to push the transaction logs to the Splunk Lightweight Forwarder (LWF) on the CDNM.


Note The export server, whether the CDNM, other CDN, or different server; must have the Splunk LWF running and configured to receive the transaction log files.


These log files can be opened with a text editor, saved to a local hard drive, and used to generate monthly reports of charges for delivered content for each content provider.

To configure the real-time exporting of the transaction logs, do the following:


Step 1 In the CDSM GUI, for an SE, choose Devices > Devices > Service Control > Transaction Logging. The Transaction Logging page is displayed.

For an SR, choose Devices > Devices > General Settings > Notification and Tracking > Transaction Logging. The Transaction Logging page is displayed.

Step 2 Enter the settings as appropriate. See Table 6 for descriptions of the fields.

Table 6 Splunk Universal Forwarder Fields

Field
Description

Export Enable

Enables the automatic export of the selected transaction logs to the designated export server.

Monitors

Check the check boxes of the type of transaction logs to export. The All check box means all transaction logs are exported.

Export Server and Port

IP address and port number of the CDNM, CDN, or other export server that is to receive the transaction log files. A maximum of three export servers can be specified. The default port number is 9998.


Step 3 Click Submit to save the settings.


URL Signing per Delivery Service

The Wholesale feature introduces the ability to configure URL signing and validation at the delivery service level for all protocol engines, except Movie Streamer.

The Service Rule XML file has been modified to support delivery service-based URL signing, URL signature validation, and URL signature generation for Windows Media Streaming live requests (.asx). The CDSRules.xsd and the CDSM GUI validation have been updated to reflect this change. The Service Rule XML files that were created in previous releases are still valid in Release 3.1.0.


Note All Windows Media Streaming per-device service rules configured for URL signature and validation must be converted to the per-delivery service Service Rule XML file. This change only applies to the generate-url-signature and validate-url-signature service rule actions for Windows Media Streaming. The other service rule actions (allow, block, no-cache, redirect, refresh, replace, and rewrite) still use the per-device service rule configuration for Windows Media Streaming. See the "Converting Old Windows Media Streaming Service Rules for URL Signing and Validation" section for more information.

Movie Streamer still uses the per-device configuration for all service rules.


The following new attributes have been added to the Rule_Validate element:

key—Unique URL signature key that is up to 16 characters. For symmetric key URL validation.

public-key—URL where the public key file is located. For asymmetric key URL validation.

symmetric-key—Key (16 bytes) used for AES encryption of the signed URL. For asymmetric key URL validation.

The following new attributes have been added to the Rule_UrlGenerateSign:

key—Unique URL signature key that is up to 16 characters. For symmetric key URL validation.

private-key—URL where the private key file is located. For asymmetric key URL validation.

symmetric-key—Key (16 bytes) used for AES encryption of the signed URL. For asymmetric key URL validation.

The key ID owner and key ID number fields apply to the per-device configuration of URL Signing (Devices > Devices > Service Control > URL Signing). For compatibility, key ID owner and key ID number are required for the UrlGenerateSign action and are set to 1 when the URL signing key is specified in the Service Rule XML file. If the URL signing key is specified by using the URL Signing page or the url-signature command for each SE, the UrlGenerateSign action will find the key by the key-id-owner and key-id-number specified in the RuleUrlGenerateSign action, and the Rule_Validate action will find the key by the KO (key-id-owner) and KN (key-id-number).

The following rules apply for Rule_Validate and Rule_UrlGenerateSign actions:

key-id-owner and key-id-number are required attributes for the UrlGenerateSign action

Only http is supported as the protocol attribute value for Rule_UrlGenerateSign; all other values have no affect.

Rule_Validate supports http, rtsp, and rtmp as the protocol attribute value.

Following is an example of the Service Rule XML file configured with a symmetric key (also known as shared secret):

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
  <Revision>1.0</Revision>
  <CustomerName>Cisco</CustomerName>
  <ApplyAllTier>yes</ApplyAllTier>
  <Rule_Patterns>
    <PatternListGrp id = "grp1">
      <Domain>cds.cisco.com</Domain >
    </PatternListGrp>
  </Rule_Patterns>
<Rule_Actions>
    <Rule_UrlGenerateSign matchGroup="grp1" protocol="http" key-id-owner="1" 
key-id-number="1" key="cisco123" timeout-in-sec="50" />
    <Rule_Validate matchGroup="grp1" key="cisco123" protocol="all" 
error-redirect-url="http://wwwin.cisco.com" />
  </Rule_Actions>
</CDSRules>
 
   

Following is an example of the Service Rule XML file configured with an asymmetric key (also known as public key):

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
  <Revision>1.0</Revision>
  <CustomerName>Cisco</CustomerName>
  <ApplyAllTier>yes</ApplyAllTier>
  <Rule_Patterns>
    <PatternListGrp id = "grp1">
      <Domain>cds.cisco.com</Domain >
    </PatternListGrp>
  </Rule_Patterns>
<Rule_Actions>
    <Rule_UrlGenerateSign matchGroup="grp1" protocol="http" key-id-owner="1" 
key-id-number="1" private-key="http://10.74.61.69/vod/private_key.txt" 
symmetric-key="ciscociscociscoc" timeout-in-sec="50" />
    <Rule_Validate matchGroup="grp1" public-key="http://10.74.61.69/vod/public_key.txt" 
symmetric-key="ciscociscociscoc" protocol="all" 
error-redirect-url="http://wwwin.cisco.com" />
  </Rule_Actions>
</CDSRules>
 
   

Converting Old Windows Media Streaming Service Rules for URL Signing and Validation

This section provides examples of converting the generate-url-signature and validate-url-signature service rule actions for Windows Media Streaming to the Service Rule format.

Perform URL Signature Generation on Requests

The following example shows the commands for configuring a service rule that performs URL signature generation on requests from the domain wmtvod.com using the old mechanism:

SE (config)# url-signature key-id-owner 1 key-id-number 1 key cisco123
SE (config)# rule enable
SE (config)# rule action generate-url-signature key-id-owner 1 key-id-number 1 
pattern-list l protocol http 
SE (config)# rule pattern-list 1 domain wmtvod.com
 
   

The Service Rule XML file for the above rule is as follows:

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
   <Revision>1.0</Revision>
   <CustomerName>Cisco</CustomerName>
   <ApplyAllTier>yes</ApplyAllTier>
    <Rule_Patterns>
      <PatternListGrp id = "grp1">
         <Domain>wmtvod.com</Domain >
      </PatternListGrp>
   </Rule_Patterns>
 
   
   <Rule_Actions>
      <Rule_UrlGenerateSign matchGroup = "grp1" protocol = "http" key="cisco123" 
key-id-owner="1" key-id-number="2" timeout-in-sec="30"/>
   </Rule_Actions>
</CDSRules>
 
   

Perform URL Signature Validation on Requests

The following example shows the commands for configuring a service rule that performs URL signature validation on requests from the domain, wmtvod.com using the old mechanism:

SE (config)# rule enable
SE (config)# rule action validate-url-signature error-redirect-url www.cisco.com 
pattern-list 1  protocol all
SE (config)# rule pattern-list 1 domain wmtvod.com
 
   

The Service Rule XML file for the above rule is as follows:

<CDSRules xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="schema\CDSRules.xsd">
  <Revision>1.0</Revision>
  <CustomerName>Capricious</CustomerName>
  <Rule_Patterns>
    <PatternListGrp id = "grp1">
      <Domain>wmtvod.com</Domain>
    </PatternListGrp>
  </Rule_Patterns>
  <Rule_Actions>
    <Rule_Validate matchGroup = "grp1" protocol = "all" key="cisco123"                 
error-redirect-url="http://www.cisco.com"/>
  </Rule_Actions>
</CDSRules> 
 
   

APIs for Wholesale CDN

The following APIs have been modified or added to support the configuration and monitoring of the Wholesale feature:

Storage Priority Class—StoragePrioClassApiServlet API has been added with create, modify, and delete actions, and getStoragePrioClass action has been added to the ListApiServlet

Quota Usage Reporting—New parameters have been added to the following actions of the ChannelApiServlet:

createDeliveryService

modifyDeliveryService

createDeliveryServiceGenSettings

modifyDeliveryServiceGenSettings


Note All parameters, except actions, are case sensitive.


If the action parameter is missing or cannot be recognized, an error code and the API usage syntax is returned.

Storage Priority Class API

The new StoragePrioClassApiServlet API has been added to create, modify, and delete a storage priority class.

Syntax

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui. StoragePrioClassApiServlet...

This servlet performs one or more of the following actions:

createStoragePrioClass

modifyStoragePrioClass

deleteStoragePrioClass

createStoragePrioClass

Creates a storage priority class.

Parameters:

Name—Class name (required)

Factor—Storage multiplication factor (required)

Comments—Comments (optional)

Return:

The newly created storage priority class with a StoragePriorityClass ID.

Syntax:

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.StoragePrioClassApiServlet?action=
createStoragePrioClass&name=<Class_Name>&factor=<storage_popularity_factor>[&comments=<comments>]

modifyStoragePrioClass

Modifies a storage priority class.

Parameters:

Storage priority class—Record ID of the storage priority class (required)

Name—Class name (optional)

Factor—Storage multiplication factor (optional)

Comments—Comments (optional)

Return:

The modified storage priority class.

Syntax:

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.StoragePrioClassApiServlet?action=
modifyStoragePrioClass&storagePriorityClass=<storagePriorityClass_ID>[&name=<Class_Name>&factor=<storage_popularity_factor>&comments=<comments>]

deleteStoragePrioClass

Deletes a storage priority class.

Parameters:

Storage priority class—Record ID of the storage priority class (required)

Return:

None.

Syntax:

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.StoragePrioClassApiServlet?action=
deleteStoragePrioClass&storagePriorityClass=<storagePriorityClass_ID>

Get Storage Priority Class

The getStoragePrioClasses uses the ListingApiServlet and lists the storage priority classes and their StoragePriorityClass IDs.

Parameter

Either a list of StoragePriorityClass IDs or the keyword all is required.

Return

A list of all storage priority classes specified and their details.

Syntax

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.ListApiServlet?action=
getStoragePrioClasses&param=all | <storagePriorityClass_name>, <storagePriorityClass_name>, ...

Quota Usage Reporting

New parameters have been added to the following actions of the ChannelApiServlet:

createDeliveryService

modifyDeliveryService

createDeliveryServiceGenSettings

modifyDeliveryServiceGenSettings

The syntax of the getDeliveryServices action of the ListApiServlet has not changed, but the output lists the following new output fields:

SessionQuota—Session quota

SessionQuotaAugBuf—Session quota augmentation buffer

SandQuota—Bandwidth quota

BandQuotaAugBuf—Bandwidth quota augmentation buffer

StoragePriorityClassId—Storage priority class ID

createDeliveryService

The following new optional parameters have been added to this action:

sessionQuota—Session quota

sessionQuotaAugBuf—Session quota augmentation buffer

bandQuota—Bandwidth quota

BandQuotaAugBuf—Bandwidth quota augmentation buffer

StoragePriorityClass—Storage priority class ID

modifyDeliveryService

The following new optional parameters have been added to this action:

sessionQuota—Session quota

sessionQuotaAugBuf—Session quota augmentation buffer

bandQuota—Bandwidth quota

BandQuotaAugBuf—Bandwidth quota augmentation buffer

StoragePriorityClass—Storage priority class ID

createDeliveryServiceGenSettings

The following new optional parameters have been added to this action:

QuotaUsageReporting—Force quota usage reporting when bandwidth and session quotas are not configured for the delivery service

modifyDeliveryServiceGenSettings

The following new optional parameters have been added to this action:

QuotaUsageReporting—Force quota usage reporting when bandwidth and session quotas are not configured for the delivery service

Enhancements

The following enhancements have been added in Release 3.1.0:

getDevices Action Added to DeviceApiServlet API

Custom HTTP Header Authentication for Origin Server

Windows Media Ingest Transaction Log

Enhancement to Reading NAS Metadata

Windows Media Streaming SNMP MIB Enhancements

Per-Request HTTP Headers from Redirected URLs

ABR Session Events

getDevices Action Added to DeviceApiServlet API

The getDevices action has been added to the DeviceApiServlet to provide information about the devices in the CDS.

Parameters

Type—Type of device (required) is one of the following: DG (device group), SE, SR, CDSM, or all

Name—Device name

ID—Device ID

Return

Returns information about all the devices that are the specified device type.

Syntax

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.DeviceApiServlet?action=
getDevicess&type=<all|DG|SE|SR|CDSM>[&name=<device_name>][&id=<device_ID>]

Custom HTTP Header Authentication for Origin Server

Release 3.1.0 supports custom HTTP header authentication for the Origin server. This feature provides a way for the Origin server to authenticate HTTP requests by the following methods:

Basic HTTP Header Authentication

Challenged HTTP Header Authentication

Basic HTTP Header Authentication

The basic HTTP header authentication method uses a shared key between the Origin server and the Content Acquirer of the delivery service. Each HTTP request to the Origin server includes the shared key in the HTTP header.

To configure the basic HTTP header authentication for an Origin server, do the following:


Step 1 In the CDSM GUI, choose Services > Content Origins. The Content Origin table is displayed.

Step 2 Click the Edit icon next to the Content Origin name you want to modify. The Content Origin page is displayed.

To create a new Content Origin, click the Create New icon in the task bar.

Step 3 From the HTTP Authentication Type drop-down list, select Basic Authentication. The Basic HTTP Header Authentication fields are displayed.

Step 4 In the HTTP Authentication Header field, enter the name of the HTTP authentication header.

Step 5 In the HTTP Authentication Shared Key field, enter the shared key. The shared key must be at least 16 characters and must be composed of TEXT characters defined in RFC 2616 HTTP/1.1. The range is from 16 to 128 characters.

Step 6 Click Submit to save the settings.


Challenged HTTP Header Authentication

The challenged HTTP header authentication method uses a shared secret key between the Origin server and the Content Acquirer of the delivery service. The authentication message does not display the secret key. The shared secret key uses a random challenge string and cryptographic hash algorithm.

The random challenge string is composed of TEXT characters defined in RFC 2616 HTTP/1.1 and is the same length as the secret key. Following is the process that occurs for the challenged HTTP header authentication method:

1. A binary XOR between the challenge string and the secret key is created.

2. The authentication value is created by using the cryptographic hash of the XOR value.

3. The following authentication headers are added to the HTTP request that is sent to the Origin server:

Header with challenge string

Header with authentication value

4. The hashing algorithm is implemented and the name of the hashing function is included in the HTTP header.

5. The prefix name (identified as HPFX in this scenario) of the authentication HTTP header is used to construct the following header names:

Challenge string header—HPFX-CSTR

Authentication value header—HPFX-AUTH

Hashing function header—HPFX-HASH

6. When the Origin server receives the request, it must do the following:

a. Compute a binary XOR between the HPFX-CSTR header value and the secret key configured in the CDS.

b. Compute the authentication value with the cryptographic hash in the HPFX-HASH header.

c. Grant access if the Origin server computed authentication value and the authentication value header (HPFX-AUTH) match (both are lower case).

To configure the challenged HTTP header authentication for an Origin server, do the following:


Step 1 In the CDSM GUI, choose Services > Content Origins. The Content Origin table is displayed.

Step 2 Click the Edit icon next to the Content Origin name you want to modify. The Content Origin page is displayed.

To create a new Content Origin, click the Create New icon in the task bar.

Step 3 From the HTTP Authentication Type drop-down list, select Challenged Authentication. The Challenged HTTP Header Authentication fields are displayed.

Step 4 In the HTTP Authentication Header Prefix field, enter the prefix of the HTTP authentication header.

Step 5 In the HTTP Authentication Shared Secret Key field, enter the shared secret key. The shared secret key must be at least 16 characters and must be composed of TEXT characters defined in RFC 2616 HTTP/1.1. The range is from 16 to 128 characters.

Step 6 In the HTTP Authentication Hashing Function drop-down list, select MD5 as the hashing algorithm for the shared secret key.

Step 7 Click Submit to save the settings.


API Changes for HTTP Header Authentication

The following new optional parameters have been added to createContentOrigin and modifyContentOrigin:

httpAuthType—HTTP Authentication Type (none, basic, or challenged)

httpAuthHeader—Authentication header

httpAuthSharedKey—Authentication shared key (16-128 TEXT characters as defined in RFC 2616))

httpAuthHeaderPrefix—Authentication header prefix

httpAuthSharedSecKey—Authentication shared secret key (16-128 TEXT characters as defined in RFC 2616))

httpAuthHashFunc—Hashing function (only MD5 is supported)

createContentOrigin Syntax:

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.ChannelApiServlet?action=createContentOrigin&name=<contentOrigin_name>&origin=<origin_server>&fqdn=<fqdn> [&contentBasedRouting=<true|false>][&nasFile=<nasFile_ID>][&wmtAuth=
<basic|ntlm|digest|negotiate>][&httpAuthType=<none|basic|challenged>][&httpAuthHeader=
<auth_header>][&httpAuthSharedKey=<auth_shared_key>][&httpAuthHeaderPrefix=
<auth_header_prefix>][&httpAuthSharedSecKey=<auth_shared_secret_key>][&httpAuthHashFunc=
<MD5>] [&description=<description>]

modifyContentOrigin Syntax:

https://<cdsmIpAddress>:8443/servlet/com.cisco.unicorn.ui.ChannelApiServlet?action=modifyContentOrigin&contentOrigin=<Content Origin_ID>[&name=<Content Origin_name>][&origin=
<origin_server>][&fqdn=<fqdn>][&contentBasedRouting=<true|false>][&nasFile=<nasFile_ID | none>][&wmtAuth=<none|basic|ntlm|digest|negotiate >][&httpAuthType=<none|basic|challenged>]
[&httpAuthHeader=<auth_header>][&httpAuthSharedKey=<auth_shared_key>]
[&httpAuthHeaderPrefix=<auth_header_prefix>][&httpAuthSharedSecKey=<auth_shared_secret_key>]
[&httpAuthHashFunc=<MD5>][&description=<description>]

Windows Media Ingest Transaction Log

The Windows Media Ingest transaction log is a new log file that is used to record the details about dynamically ingested content. The Windows Media Ingest transaction log can be used by the CDNM to generate statistics on gigabytes used for cache-fill of dynamically ingested content by the Windows Media Streaming engine.

The Windows Media Ingest transaction log filename has the following format:

wmt_ingestlog_clf_<ipaddr>_yyyymmdd_hhmmss_<>, where

<ipaddr> represents the IP address of the SR

yyyymmdd_hhmmss represents the date and time when the log was created

The Windows Media Ingest transaction log file is located in the /local/local1/logs/wmt_ingest_clf/ directory on the SE.

Table 7 describes the fields for the Windows Media Ingest transaction log.

Table 7 Ingest Transaction Log Fields 

Field
Description

Time

Time the request was sent by Windows Media Streaming to the upstream SE or origin server.

URL

Requested URL, including the query string, sent by Windows Media Streaming.

FailOverSvrList

Hierarchical route look-up information to the upstream SE or origin server. When a cache route look-up is performed for the request, the list of upstream SEs and origin server contacted to fetch the content is included in the log entry.

ServerIP

IP address of the SE or origin server from which the content is downloaded. This is obtained from the FailOverSvrList.

BytesRead

Number of bytes downloaded from the upstream SE or origin server.

AssetSize

Size of the asset (in bytes) requested.

DownloadTime(Seconds)

Time, in seconds, to download the incoming stream.

Status-Returned

Status code returned from the upstream SE or origin server.

ConnectionInfo(LocalPort|ConnectTime|Retry|Reuse)

Connection information. This field has the following values:

LocalPort—Local port used by the SE to talk to upstream

ConnectTime—Time at which the connection was established

Retry—Number of retries on the connection

IngestStatus

Displays the ingest status. This field has the following value:

FAIL

SUCCESS


Enhancement to Reading NAS Metadata

Metadata for content stored on network-attached storage (NAS) devices is now fetched. Metadata is associated with a content file. The metadata for a content file is stored as <file>.metadata, in the same directory as the content file. For example, if the content file is located at /datap1/vod/flv/sample.flv, the metadata file is located at /datap1/vod/flv/sample.flv.metadata.


Note NAS is only supported in lab integrations as proof of concept.


It is assumed that the content store (NAS) has the metadata of the content that is to be stored as a separate file with name such as <content_name>.metadata in the same directory location. It is also assumed that the format of the file complies with the following rules:

File format is a simple text file with each line of the file having an attribute name and an associated attribute value separated by a colon (:). No spaces are allowed anywhere in the meta file. Format and pattern for the meta file is as follows:

<attribute1>:<value1>

<attribute2>:<value2>

<attribute3>:<value3>

Basic attributes supported are as follows:

expires

s-maxage

max-age

must-revalidate

proxy-revalidate

etag

content-type

content-encoding

age

retry-after

Any header attributes other than the basic attributes listed are considered custom and are written into the client response header.

Windows Media Streaming SNMP MIB Enhancements

The CISCO-SERVICE_ENGINE-MIB has been updated to include all the Windows Media statistics that are displayed in the show statistics wmt all command. The new OIDs have been added to cdsWmtGroup.

Per-Request HTTP Headers from Redirected URLs

When the CDS is integrated with products such as the Content Adaptation Engine (CAE), SEs are used to serve over-the-top content. In such scenarios, the CDS provides HTTP headers similar to that of the Origin server. The information in the HTTP header can be unique to a user session.

The CAE retrieves this information from the Origin server response and provides it as a query parameter within the URL. This information is intact when received by the SE following redirections from the CAE and SR. The Web Engine retrieves the "_resp_hdrs_" value from the received URL. The retrieved value is % unescaped, and parsed for use when serving the content.

As indicated in RFC-2396, a query parameter cannot contain the reserved characters ;/?:@&=+,$ and thus are escaped using % encoding. The query string must have the "_resp_hdrs_" tag. A URL with the "_resp_hdrs_" tag has the following format:

http://<URL to serve>?_resp_hdrs_=<strings to include in the http headers>

Following is an example of a URL with the "_resp_hdrs_" tag and value:

http://nas_url_to_serve?_resp_hdrs_=Set-Cookie%3A%20ff%3DrlsBo4v%3B%20path%3D/%3B%20domain%3D.site.com

ABR Session Events

In addition to the session close event that generated a log entry in Release 3.0.0, Table 8 describes the supported session events for an ABR session in Release 3.1.0.

Table 8 ABR Session Events

Session Event
Description

Bitrate Upshift

Bitrate of requested fragment is faster than the previously requested fragment.

Note ABR Session log does not support HLS bitrate shift event.

Bitrate Downshift

Bitrate of requested fragment is slower than the previously requested fragment.

Note ABR Session log does not support HLS bitrate shift event.

Session Stop

Client has not sent a request for the last ten seconds.

Session Close

There has been no session activity for the duration of the configured session idle time (SessionIdleTimeout parameter is configured in Service Rule XML file).

Note Supported in Release 3.0.0.


The following events generate a transaction log entry:

Bitrate Upshift

Bitrate Downshift

Session Stop

Session Close

Other Enhancements

Other enhancements in Release 3.1.0 consist of the following:

All user-agent values are now enclosed in double quotes (" ") in the transaction logs for Web Engine, Windows Media Streaming, Flash Media, Streaming, and Service Router.

System Requirements

The Internet Streamer CDS runs on the CDE205, CDE220, and the CDE250 hardware models, as well as two UCS models.

Table 9 lists the different device modes for the Cisco Internet Streamer CDS software, and which CDEs support them.

Table 9 Supported CDEs

Device Mode
CDE205
CDE220-2G2
CDE220-2S3i
CDE250 (all models)
UCS C200
UCS C210

CDSM

Yes

No

No

No

Yes

No

SR

Yes

Yes

No

No

Yes

No

SE

Yes

Yes

Yes

Yes

No

Yes

SR—Proximity Engine standalone

Yes

Yes

No

No

No

No


The new CDE250 models (CDE250-2S8, CDE250-2S9, and CDE250-2S10) have four interfaces at 10 gigabit Ethernet speeds and four interfaces at gigabit Ethernet speeds (plus two additional gigabit ethernet interfaces for management).

The new CDE250 models only support the SE device mode and have the following storage capacities:

CDE250-2S8—24 x 300 GB 2.5 SSD

CDE250-2S9—12 x 600 GB 2.5 SSD

CDE250-2S10—24 x 600 GB 2.5 SSD

The Cisco UCS models (UCS C200 and UCS C210) and the Cisco Internet Streamer Release 3.1 software are sold separately and ship independently of each other.

CDE250-2S6 and CDE250-2M0 platforms have four interfaces at 10 gigabit Ethernet speeds and four interfaces at gigabit Ethernet speeds (plus two additional gigabit ethernet interfaces for management).

The CDE220-2S3i platform has a total of 14 gigabit Ethernet ports in this CDE. The first two ports (1/0 and 2/0) are management ports. The remaining 12 gigabit Ethernet ports can be configured as two port channels. See the Cisco Content Delivery Engine CDE205/220/250/420 Hardware Installation Guide for set up and installation procedures for the CDE220-2S3i and the Cisco Internet Streamer CDS 2.6 Software Configuration Guide for information on configuring the Multi Port Support feature.

The CDE220-2G2 platform has a total of ten gigabit Ethernet ports. The first two ports (1/0 and 2/0) are management ports. The remaining eight gigabit Ethernet ports can be configured as one port channel. See the Cisco Content Delivery Engine CDE205/220/250/420 Hardware Installation Guide for set-up and installation procedures for the CDE220-2G2.

The CDE205 can run as the CDSM, SR or SE. See the Cisco Content Delivery Engine CDE205/220/250/420 Hardware Installation Guide for set-up and installation procedures for the CDE205.


Note For performance information, see the release-specific performance bulletin.


Limitations and Restrictions

This release contains the following limitations and restrictions:

There is a 4 KB maximum limit for HTTP request headers. This has been added to prevent client-side attacks, including overflowing buffers in the Web Engine.

Standby interface is not supported for Proximity Engine. Use port channel configuration instead.

There is no network address translation (NAT) device separating the CDEs from one another.

Do not run the CDE with the cover off. This disrupts the fan air flow and causes overheating.


Note The CDS does not support network address translation (NAT) configuration, where one or more CDEs are behind the NAT device or firewall. The workaround for this, if your CDS network is behind a firewall, is to configure each internal and external IP address pair with the same IP address.

The CDS does support clients that are behind a NAT device or firewall that have shared external IP addresses. In other words, there could be a firewall between the CDS network and the client device. However, the NAT device or firewall must support RTP/RTSP.


System Limits and Thresholds

This release has the following limits and thresholds:

Service Router Limits and Thresholds

Service Monitor Limits and Thresholds

Web Engine Limits and Thresholds

CDSM Limits and Thresholds

RTSP Gateway and Movie Streamer

Windows Media Streaming

Flash Media Streaming

Service Router Limits and Thresholds

The Service Router has memory-related limits and thresholds. Memory usage of the Service Router depends on the number of coverage zone entries, the number of Content Origin servers, the distribution of subnets in the Coverage Zone file, and the number of Service Engines in the CDS. From our tests using a sample Coverage Zone file, we have observed that we can support 20,000 Coverage Zone entries with 26 SEs, and 40 Content Origins servers.


Note The number of Coverage Zone entries, SEs, and Content Origin servers are subject to change depending on the Coverage Zone configured.

We recommend keeping the memory usage (both virtual and resident) below 1.5 GB.


Frequent configuration updates could cause memory fragmentation, which raises the memory usage.

Service Monitor Limits and Thresholds

When the Service Monitor thresholds are exceeded, an alarm is raised on the respective device and an SNMP trap is sent to the CDSM. The parameters monitored and thresholds for each component or protocol engine can be modified. The default thresholds are as outlined below.

Following are the parameters that are monitored on each device (SE, SR, and CDSM) and the default threshold setting of each parameter:

CPU—80 percent

Memory—80 percent

Kernel memory—50 percent

Disk usage—80 percent

Disk failures—75 percent

Augmentation alarms—80 percent

Following are the parameters that are monitored only on the SE, along with default threshold setting of each parameter:

Windows Media Streaming thresholds—90 percent

Flash Media Streaming thresholds—90 percent

Movie Streamer—90 percent%

Maximum number of concurrent sessions—200

Maximum Bandwidth—200,000 kbps

NIC bandwidth—90 percent

Burst Count—1

Web Engine Limits and Thresholds

The Web Engine has the following limits and thresholds:

Memory Usage

Session Limits

CAL Limits

Memory Usage

In Release 2.5.9, the memory threshold on each SE is 3.2 GB. If the threshold is exceeded, the memory_exceeded alarm is raised and trickle mode is enabled. In Release 2.5.9, the admission control is based on 30,000 session and 3.2 GB of memory.

In Release 2.6.1, the memory threshold on each SE is 3.2 GB. If the threshold is exceeded, the memory_exceeded alarm is raised. In cases where the memory reaches 3.7 GB, trickle mode is enabled and eventually the Web Engine is restarted. The above memory values, and the 20,000-60,000 sessions and 100,000 open file/socket descriptor (FD) limit are used for admission control in Release 2.6.1.

Session Limits

Web Engine supports the following session-threshold limits:

49,800 session count for the CDE250

15,000 session count for all other CDEs

The max_session_exceeded alarm is raised if the session-threshold limit is reached. If further requests are sent to the SE even when the session threshold is reached, the Web Engine attempts to process the requests but does not accept any more requests when the request count reaches 60,000 on a CDE250, and 20,000 on all other CDEs.

CAL Limits

Outstanding CAL Lookup threshold is 25,000 on the CDE250 and 15,000 on all other CDEs. The WebCalLookupThreshold alarm is raised on reaching this threshold limit.

Outstanding CAL disk Write threshold is 3,000 CAL requests (create, update, delete, popularity update) on the CDE250, and 1,500 on all other CDEs. The WebCalDiskWriteThreshold alarm is raised on reaching this threshold.

Other CAL thresholds are as follows:

File Descriptor usage threshold is 85 percent

TEMPFS usage threshold is 80 percent

Active datasource threshold is 2,000


Note CAL-related thresholds and the File Descriptor-related thresholds are introduced in Release 2.6.1.

Web Engine thresholds are also applicable to adaptive bit rate (ABR) streaming.


CDSM Limits and Thresholds

The CDSM has the following limits and thresholds:

RPC Connections

File Synchronization

CDSM Availability (primary and standby)

SE Configuration Change Synchronization

RPC Connections

A maximum of 40 RPC connections are supported among the managed devices (SE, SR, standby CDSM, and primary CDSM). The RPC connection maximum is defined in the httpd.conf.rpc configuration file located in the /state directory.

File Synchronization

The primary CDSM checks for file updates and synchronization with the managed devices (SE, SR, and standby CDSM) every ten minutes.

CDSM Availability (primary and standby)

The SE and SR check for the availability of the primary and standby CDSM on a regular interval; however, if the CDSM does not respond, the SE and SR use an exponential-backoff call for retrying the connection.

The exponential backoff call means that if the CDSM does respond to the first attempt, the SE or SR sleep for ten seconds before trying again. If the second attempt does not succeed, the wait time doubles (20 seconds), if that attempt does not succeed, the wait time doubles again (40 seconds). The wait time doubles every attempt (10, 20, 40, 80, and so on) until the maxWaitingTime of 320 seconds.

SE Configuration Change Synchronization

The period of time before the local configuration manager (LCM) on an SE sends a configuration change to the primary CDSM is a maximum of 2.25 times the polling rate. The polling rate is configurable through the CDSM GUI (System > Configuration > System Properties, System.datafeed.pollRate).

RTSP Gateway and Movie Streamer

The default RTSP Gateway transactions per second (tps) is 40. There are no other limits to the RTSP Gateway.

The Movie Streamer default maximum concurrent session is 200 and the default maximum bandwidth is 200 Mbps.

Windows Media Streaming

Windows Media Streaming has the following limits and thresholds:

Windows Media Streaming recommended concurrent remote server sessions 300


Note Regarding concurrent remote server sessions, if all requests are unique cache-miss cases, Windows Media Streaming can reach up to 1000 sessions of 1 Mbps file each. Windows Media Streaming can sustain 1000 remote server sessions at most if the Content Origin server can respond, but the recommended value is 300.


Windows Media Streaming transactions per second is 40 (because of the RTSP Gateway limitation).

Memory threshold 3 GB

CPU threshold is 80 percent

Flash Media Streaming

With the basic license, Flash Media Streaming the default maximum concurrent sessions is 200 and the default maximum bandwidth is 200 Mbps.

Buying more licenses can increase the concurrent sessions and maximum bandwidth as follows:

CDE220-2G2 and CDE220-2S3—15,000 concurrent sessions and 8 Gbps maximum bandwidth

CDE250-2M0—40,000 concurrent sessions and 40 Gbps maximum bandwidth

We recommend that the Flash Media Streaming process memory usage not exceed 3 GB resident set size (RSS). If the memory usage for Flash Media Streaming exceeds 3 GB RSS, a threshold exceeded alarm is raised.


Note RSS is the portion of a process that exists in physical memory (RAM), as opposed to virtual memory size (VSIZE), which includes both RAM and the amount in swap. If the device has not used swap, the RSS number is equal to VSIZE.


Important Notes

To maximize the content delivery performance of a CDE205, CDE220, or CDE250, we recommend you do the following:

1. Use port channel for all client-facing traffic.

Configure interfaces on the quad-port gigabit Ethernet cards into a single port-bonding interface. Use this bonding channel, which provides instantaneous failover between ports, for all client-facing traffic. Use interfaces number 1 and 2 (the two on-board Ethernet ports) for intra-CDS traffic, such as management traffic, and configure these two interfaces either as standby or port-channel mode. Refer to the Cisco Internet Streamer CDS 2.6 Software Configuration Guide for detailed instruction.

2. Use the client IP address as the load balancing algorithm.

Assuming ether-channel (also known as port-channel) is used between the upstream router/switch and the SE for streaming real-time data, the ether-channel load balance algorithms on the upstream switch/router and the SE should be configured as "Src-ip" and "Destination IP" respectively. Using this configuration ensures session stickiness and general balanced load distribution based on clients' IP addresses. Also, distribute your client IP address space across multiple subnets so that the load balancing algorithm is effective in spreading the traffic among multiple ports.


Note The optimal load-balance setting on the switch for traffic between the Content Acquirer and the edge Service Engine is dst-port, which is not available on the 3750, but is available on the Catalyst 6000 series.


3. For high-volume traffic, separate HTTP and WMT.

The CDE205, or CDE220 performance has been optimized for HTTP and WMT bulk traffic, individually. While it is entirely workable to have mixed HTTP and WMT traffic flowing through a single server simultaneously, the aggregate performance may not be as optimal as the case where the two traffic types are separate, especially when the traffic volume is high. So, if you have enough client WMT traffic to saturate the full capacity of a server, we recommend that you provision a dedicated server to handle WMT; and likewise for HTTP. In such cases, we do not recommended that you mix the two traffic types on all CDE servers which could result in suboptimal aggregate performance and require more servers than usual.

4. For mixed traffic, turn on the HTTP bitrate pacing feature.

If your deployment must have Streamers handle HTTP and WMT traffic simultaneously, it is best that you configure the Streamer to limit each of its HTTP sessions below a certain bitrate (for example, 1Mbps, 5Mbps, or the typical speed of your client population). This prevents HTTP sessions from running at higher throughput than necessary, and disrupting the concurrent WMT streaming sessions on that Streamer. To turn on this pacing feature, use the HTTP bitrate field in the CDSM Delivery Service GUI page.

Please be aware of the side effects of using the following commands for Movie Streamer:

Config# movie-streamer advanced client idle-timeout <30-1800>
Config# movie-streamer advanced client rtp-timeout <30-1800>
 
   

These commands are only intended for performance testing when using certain testing tools that do not have full support of the RTCP receiver report. Setting these timeouts to high values causes inefficient tear down of client connections when the streaming sessions have ended.

For typical deployments, it is preferable to leave these parameters set to their defaults.

5. For ASX requests, when the Service Router redirects the request to an alternate domain or to the origin server, the Service Router does not strip the .asx extension, this is because the .asx extension is part of the original request. If an alternate domain or origin server does not have the requested file, the request fails. To ensure requests for asx files do not fail, make sure the .asx files are stored on the alternate domain and origin server.

Open Caveats

This release contains the following open caveats:

Content Manager

CSCua08680

Symptom:

When the clear-cache-all command is entered, sometimes the content is not completely deleted. This is because the Content Manager is not aware of all the content cached by the Web Engine.

Conditions:

When the Web Engine creates more than three million objects and the slow scan (slowscan) process has just finished running, some content is not known by the Content Manager.

Workaround:

The next round of slowscan (every 12 hours) picks up the content that was unknown by the Content Manager. After that, the clear-cache-all command works.

Web Engine

CSCub00586

Symptom

Session-based Encryption with a single key per session (default configuration) does not work for HLS use case. HSS use case has no impact because the manifest for HSS is out-of-band.

Conditions:

When HLS encryption is enabled with a single key for a session (user).

Workaround:

To enable HLS Session-based Encryption with a single key, when the HLSEncryptionEnable parameter is set to 1 in the Service Rule XML file, configure HLSMaxKeysPerSession =1 and HLSKeyRotationFragmentInterval =1. This enables HLS encryption with a single key for the entire session.

CSCtz10789

Symptom:

Web Engine process fails to start.

Conditions:

Web Engine fails to start when restarted manually.

Workaround:

Retry. Reload the Web Engine.

CDSM

CSCub73729

Symptom:

When using the API to create a live program, the <attribute> element value contains an unreachable URL, which means the CDSM cannot get this SDP file defined within the URL. Following is an example of a URL that is unreachable, which causes the SR to go offline and the CDSM to hang for awhile:

<attribute value='unicastPushSDP:http://172.17.39.107/broadcast.sdp'/>
 
   

Conditions:

This issue happens when the XML file defines an unreachable <attribute> URL.

Workaround:

Make sure the URL is reachable.

Service Monitor

CSCub77092

Symptom:

Service Monitor process coredumps because of memory overflow.

Conditions:

When downgrading the software image from Release 3.1 to Release 2.5.9.

Workaround:

None.

Network

CSCub77171

Symptom:

The device goes into kernel debugger mode (kdb) during a stress test.

Conditions:

The device tries to assign the auto-configuration IPv6 ipaddress to the interface bond0, but the router complains that the IPv6 address is a duplicate.

Workaround:

Disable IPv6 address auto-configuration on bond0.

Acquisition and Distribution

CSCub52883

Symptom:

The correct play length is not displayed for .wmv files.

Conditions:

When .wmv files are prefetched, the play length is displayed as 00:00:00.

Workaround:

None.

CLI

CSCub79952

Symptom:

CDSM GUI and CLI are unable to disable the Splunk backend process, which means the Splunk backend process stays in running state after SE is restarted. The Splunk backend process does not have any effect unless the export hosts or monitors are configured.

Conditions:

Restart SE when the splunk enable command is in running configuration.

Workaround:

The CLI running configuration and the CDSM GUI are unable to save the splunk enable command, which is in disabled status. Re-enable splunk after SE reload.

Multicast Distribution

CSCub60908

Symptom:

In Release 3.1, there is a Unicast Multicast Option field in Delivery Service Definition page. There are three options for it: Unicast Only, Multicast Only, and Multicast Unicast.

In Release 3.0, there is no such field. The distribution type is always unicast.

If Multicast Only is configured in Release 3.1 and the system is downgraded to Release 3.0, the distribution type is not automatically changed back to unicast.

The svcnomcastenable alarm is raised on all SEs. This alarm is not valid in Release 3.0 and should not be raised. Deleting the delivery service clears this alarm.

Conditions:

This issue occurs when the Unicast Multicast Option field is set to Multicast Unicast or Multicast Only for a delivery service in Release3.1, then the system is downgraded to Release 3.0.

Workaround:

There is a downgrade script for this issue. Contact your Cisco representative for a copy of the script. After downgrading the CDSM, do the following:

1. Use FTP to upload the script to the CDSM and place it in downgrade folder. If this folder does not exist, create it.

2. Stop CMS by entering the no cms enable command.

3. Run the script with the following command:

cms database downgrade script downgrade/Downgrade3_1_to_3_0
 
   

4. Start CMS by entering the cms enable command.

CSCub65253

Symptom:

In Release 3.1, there is a Unicast Multicast Option field in Delivery Service Definition page. There are three options for it: Unicast Only, Multicast Only, and Multicast Unicast.

In Release 3.0, there is no such field. The distribution type is always unicast.

If Multicast Only is configured in Release 3.1 and the system is downgraded to Release 3.0, the distribution type is not automatically changed back to unicast.

If the following command is entered on the SE:

show distribution delivery-service delivery-service-name <delivery service name>
 
   

The output shows that the distribution type is Multicast Unicast or Multicast Only.

This is only a display issue. The distribution process still works in the unicast distribution way.

Conditions:

This issue occurs when the Unicast Multicast Option field is set to Multicast Unicast or Multicast Only for a delivery service in Release3.1, then the system is downgraded to Release 3.0 and the show distribution command is entered.

Workaround:

There is a downgrade script for this issue. Contact your Cisco representative for a copy of the script. After downgrading the CDSM, do the following:

1. Use FTP to upload the script to the CDSM and place it in downgrade folder. If this folder does not exist, create it.

2. Stop CMS by entering the no cms enable command.

3. Run the script with the following command:

cms database downgrade script downgrade/Downgrade3_1_to_3_0
 
   

4. Start CMS by entering the cms enable command.

Resolved Caveats

The following caveats have been resolved since Cisco Internet Streamer CDS Release 3.1.0. Not all the resolved issues are mentioned here. The following list highlights the resolved caveats associated with customer deployment scenarios.

CDSM

CSCtc48460

Symptom:

In the Device Group home page, the "Pages configured for this device group" section does not show all menu items whose pages have been configured the device group settings.

Conditions:

Device Group with several configured pages.

Web Engine

CSCtz27194

Symptom:

When 24 IPv6 addresses are added to one interface and 12 or more IPv6 addresses are added another interface using a script (that is, apply all of them together), a Web Engine crash is seen occasionally.

Conditions:

This is seen only when a large number of IPv6 addresses (more than 24) are applied to more than one interface using a script. It is not seen when 24 IPv6 addresses are applied to just one interface. Or, when addresses are applied using the CLI.

Platform

CSCua50262

Symptom:

When converting a CDE250-2S10 to a CDE250-2S9, the show disk details command still show the 24 SSDs for a CDE250-2S10, instead of the 12 SSDs for the CDE250-2S9.

Conditions:

This happen when changing the CDE250 from a CDE250-2S10 to a CDE250-2S9.

In a CDE250-2S9, there are 12 INTEL SSDSA2BW60 600G external SSD from disk00 slot to disk11 slot.

In a CDE250-2S10, there are 24 INTEL SSDSA2BW60 600G external SSD in disk00 slot to disk23 slot.

The show disk details command displays the disk slots and hard drive type installed in each slot.

Upgrading to Release 3.1.0

Release 3.1.0 supports upgrades from Release 2.5.9, Release 2.5.11, Release 2.6.x, and Release 3.0.x.


Note If your CDS software is older than Release 2.6.1 and you have CDE205 and CDE220 platforms in your system, you must check that the partition size (specifically, disk 00/02), on each CDE205 and CDE220 in your system is larger than 0.5 GB. To check the partition size, enter the show disks detail command. If the disk00/02 partition is not larger than 0.5 GB, you must upgrade the CDE to Release 2.6.1 before upgrading to Release 3.x.


If your CDS is running an older release than Release 2.5.9, you need to upgrade to Release 2.5.9 or 2.5.11 before upgrading to Release 3.1.0.

When upgrading from Release 2.5.9 or 2.5.11, all content is erased. For Service Engines, this means that prefetched metadata and content need to be redistributed from upstream SEs after the upgrade, and that cached content is not preserved. Additionally, Flash Media Streaming service rules must be converted from device-based service rules to the Service Rule XML file. For more information on upgrading from Release 2.5.9 and 2.5.11, see the Cisco Internet Streamer CDS 2.6 Software Upgrade Guide (http://www.cisco.com/en/US/docs/video/cds/cda/is/2_6/upgrade_guide/upgrade.html).

We strongly recommend that you upgrade your CDS network devices in the following order:

1. Multicast sender Service Engines

2. Multicast receiver Service Engines

3. Edge Service Engines

4. Middle-tier Service Engines

5. Content Acquirers

6. Service Routers

7. Standby CDSMs (Upgrade before primary when using the GUI only.)

8. Primary CDSM


Note When using the CDSM GUI to upgrade from Release 2.5.9, 2.5.11, or 2.6.1 to Release 3.1.0, after you upgrade the standby CDSM, if you switch roles of the standby CDSM and primary CDSM to maintain an active CDSM, the old primary CDSM is now the standby CDSM, and the old standby CDSM is now the primary CDSM. At this point, you must use the CLI to upgrade the new standby CDSM. The primary CDSM GUI cannot upgrade the standby CDSM.

Alternatively, if you do not switch roles of the standby CDSM and primary CDSM, you can use the CDSM GUI to upgrade the primary CDSM. The primary CDSM loses connectivity with the CDS devices for a short time during the upgrade, but this is not service affecting.

When using the CDSM GUI to upgrade from Release 2.6.3 and later releases to Release 3.10, after you upgrade the standby CDSM, if you switch roles of the standby CDSM and primary CDSM to maintain an active CDSM at all times, the new primary CDSM GUI can be used to upgrade the new standby CDSM.


For more information on the upgrade procedure, see the Cisco Internet Streamer CDS 3.1 Software Configuration Guide.

After the upgrade procedure starts, do not make any configuration changes until all the devices have been upgraded.

Documentation Updates

The following document has been added for this release:

Release Notes for Cisco Internet Streamer CDS 3.1.0

Cisco Internet Streamer CDS 3.1 Software Configuration Guide

Cisco Internet Streamer CDS 3.1 Command Reference Guide

Cisco Internet Streamer CDS 3.1 Alarms and Error Message Guide

Cisco Internet Streamer CDS 3.1 API Guide

Related Documentation

Refer to the following documents for additional information about Cisco Internet Streamer CDS 3.1:

Cisco Internet Streamer CDS 3.1 Software Configuration Guide

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_1/configuration_guide/icds31confg.html

Cisco Internet Streamer CDS 3.0-3.1 Quick Start Guide

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_0/quick_guide/ISCDSQuickStart.html

Cisco Internet Streamer CDS 3.1 API Guide

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_1/developer_guide/iscds31APIGuide.html

Cisco Internet Streamer CDS 3.1Command Reference Guide

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_1/command_reference/Command_Ref.html

Cisco Internet Streamer CDS 3.1 Alarms and Error Messages Guide

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_1/message_guide/message_guide.html

Cisco Internet Streamer CDS 3.0--3.1 Software Installation Guide for non-CDEs

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_0/install_guide/Non_CDE_IS_3_0_Software_Install.html

Cisco Content Delivery System 3.x Documentation Roadmap

http://www.cisco.com/en/US/docs/video/cds/overview/CDS_Roadmap3.x.html

Open Source Used in Cisco Internet Streamer CDS 3.1

http://www.cisco.com/en/US/docs/video/cds/cda/is/3_1/third_party/open_source/OL-25149-01.pdf

Cisco Content Delivery Engine 205/220/250/420 Hardware Installation Guide

http://www.cisco.com/en/US/docs/video/cds/cde/cde205_220_420/installation/guide/cde205_220_420_hig.html

Regulatory Compliance and Safety Information for Cisco Content Delivery Engines

http://www.cisco.com/en/US/docs/video/cds/cde/regulatory/compliance/CDE_RCSI.html

Cisco UCS C200 Installation and Service Guide

http://www.cisco.com/en/US/docs/unified_computing/ucs/c/hw/C200M1/install/c200M1.html

Cisco UCS C210 Installation and Service Guide

http://www.cisco.com/en/US/docs/unified_computing/ucs/c/hw/C210M1/install/C210M1.html

The entire CDS software documentation suite is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps7127/tsd_products_support_series_home.html

The entire CDS hardware documentation suite is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps7126/tsd_products_support_series_home.html

The Cisco UCS C-Series Rack Servers documentation is available on Cisco.com at:

http://www.cisco.com/en/US/products/ps10493/prod_installation_guides_list.html

Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.

This document is to be used in conjunction with the documents listed in the "Related Documentation" section.