Creating a caching solution within a Legacy (VEMS) or Standalone DME deployment is discussed in this topic.

Although, a major focus of the feature is to allow access to HLS or HDS content created in another DME, the mechanism is generally the same for all HTTP accessed content. This is accomplished by creating a configuration of parents and alternate sources (i.e. siblings) on each DME. Then a client is directed to a DME located in the same zone by providing the URL of the local DME. It is not uncommon to have different sources for different types of HTTP content. Given that the most common and efficient way to configure the caching network is to configure parent relationships, the configuration allows different parent configuration for each major type of HTTP content.

The goal of configuring the caches on each DME in a network is to allow a client in any subnet (i.e. a "zone" in the VEMS context) to access content hosted by an HTTP server elsewhere in the network. Although, a major focus of the feature is to allow access to HLS or HDS content created in another DME, the mechanism is generally the same for all HTTP accessed content. This is accomplished by creating a configuration of parents and alternate sources (i.e. siblings) on each DME. Then a client is directed to a DME located in the same zone by providing the URL of the local DME. It is not uncommon to have different sources for different types of HTTP content. Given that the most common and efficient way to configure the caching network is to configure parent relationships, the configuration allows different parent configuration for each major type of HTTP content.

As shown on the System Configuration > Caching page, each DME configuration consists of parents for each of a number of types of HTTP content, one Default Parent, and multiple Alternate Sources. Each of these IP addresses must be unique.

When the DME receives a request for HTTP content it will first determine if the content is cached locally. It will then try to find the content by completing the following steps:

Content Specific Parents are checked before the Default Parent. Each parent may follow the same process trying to locate the content. Once the content is found, it is delivered to the requesting client through the discovery path. Each DME in the path will also cache the content to allow provide more efficient delivery to other requestors.

For many simple caching matrices, configuring the Default Parent is all that is required. Note that HLS/HDS/Smooth Streaming/DASH playlists are never cached since in the case of a live events, the playlists are constantly updated.

The image below shows a sample network diagram of multiple DMEs with one DME in each zone. In general, the goal is (1) to allow any DME to be a source of appropriate HTTP content, and (2) to allow clients in any subnet to access appropriate HTTP created in any other DME.

Multiple DME Configuration (Sample Network Diagram)

 

When configuring a DME, the first step is to designate one Content Specific Parent for each content type. Also identify a Default Parent for the DME for content not explicitly handled by one of the other parents.

In the following example for simplicity, only a Default Parent for each DME is defined- no Content Specific Parents. When Content Specific Parents are present, separate caching matrices exist for each content type.

In order to minimize the amount of required information, the master parent (DME A) should be at the "center" of the caching mesh, although you can actually designate any DME as the master. Each DME should designate as its parent the DME most efficiently on the path to the master parent. The master parent should designate all other DMEs that may be generating content as Alternate Sources (i.e. siblings).

It is recommended (but not required) that any DMEs which can not be efficiently accessed on the master parent path, be entered as Alternate Sources.

The table below shows the recommended configuration for the image displayed above.

In another example, suppose a client co-located with DME E in the image above wants to access an HLS stream initiated on DME G. Since this configuration defines DME A as the Master Parent, the ultimate path for content delivery would be as follows (with asterisks showing where caching occurs):

DME G* > DME E > DME D > DME A* > DME D* > DME E*

Note that if DME G was designated as an alternate source for DME E, the path would simply be: DME G* > DME E*. Although this example designates a DME as master parent (as often happens if the content to be cached is HLS or HDS where content is not sourced from a DME, e.g. Smooth Streaming), the master parent will likely be an HTTP server.

In the VBrick ecosystem, a VBrick H.264 encoder can generate a Smooth Stream to a Microsoft IIS server that can then deliver it to multiple Silverlight clients or to DME caching engines. Since IIS servers do not utilize the same caching protocols as the DME, an IIS server cannot be used as an alternate source.

Beginning with DME v.3.12, the DME is able to retrieve, cache and distribute (to viewers) HLS streams from external sources. This allows customers to utilize their DMEs for caching and distribution of HLS streams from CDNs. This feature currently only supports retrieval, caching, and distribution of Akamai HLS streams. Further, this feature is only for VEMS customers, as Rev utilizes these settings for distribution of live Conference.

As an example, in this scenario, the DME receives an HLS request (m3u8/manifest or video chunk) from a viewer/player. The DME identifies the stream as an Akamai stream. The DME will pull the requested content from Akamai, cache it, and deliver the content to the player. Other subsequent requests are pulled from the local DME cache, Mesh, directly from Akamai (in this order) and delivered to those players. Manifest files are only minimally locally cached (< 2 seconds), while video chunks are kept longer. This feature allows customers to better leverage their Akamai investment jointly with their on premise DME investment

The configuration of this feature requires knowledge of the Akamai publishing hostnames, and the ability to identify a unique string, identificationString, within the URL. While a simple string will work, the identificationString will also take a Regular Expression.

For example, your Akamai playback URL may be:

The URL provided to the DME (from a player) would be:

Note the parallelism/similarity highlighted in the two URLs – this is necessary for the feature to work. In this example, the hostname would be myCompany.akamaihd.net. The identificationString (regular expression) must be supplied which will uniquely identify (to the DME) incoming HLS playback URLs. In this example, the identificationString we use is \/i\/ -- which will uniquely identify the ‘/i/’ within the playback URL. Any URL with that string will be processed as an Akamai HLS playback URL.

These settings (hostname and identificationString) are specified on the Cache page within the DME vbadmin GUI. Entering them requires the following format:

Special attention should be paid to make sure that the notation matches this format, including the double colon separators, without spaces.

For example, the following will treat any HLS (http or https) URL that contains ‘/i/’ to be serviced by myCompany.akamaihd.net publishing point.

Once entered, you can hover over the field to review the ports and identificationString.

Special note about identificationString: The identificationString must uniquely match the playback URL associated with one and only one Akamai hostname. If more than one Akamai hostname is configured, the identificationString must be sufficiently unique to differentiate between playback URLs. For example, the following entries:

Both of these entries match the following presented URL:

The system would use the myCompany-1.akamaihd.net publishing point as opposed to the myCompany-1.akamaihd.net version. This illustrates and stresses the need for unique identificationString across all entries.