Effective content management begins with knowledge of the content items to be distributed. These target items will traverse the WAN as they travel to the network edge. Understanding the properties of the content items and how the origin server that hosts the content items operates is critical. Knowing the properties of the origin server allows the content administrators to properly configure their portion of the CDN to interoperate with fewer disruptions to the origin server owner.

Some corporate policies might not allow content to be accessed by a protocol other than HTTP over SSL (HTTPS) or the Real-Time Streaming Protocol (RTSP), so the process of acquiring content from the origin server must comply with corporate policy, just as any client accessing content from the origin server must comply with corporate policy.

Continuing the earlier example of the XYZ Corporation, the marketing department posts all of its new product training content to a dedicated streaming media server. The training portal requires that the employee access the content with his desktop media player while accessing the corporate network. To retain control of the content, a digital rights management system has been employed, which will also help prevent media from being distributed outside of the company. In this case, the HTTP transport of streaming media would create a security risk to the content owner and corporation; HTTP is considered insecure, with control at risk of being compromised. Any URLs embedded within a stream could be easily identified while sniffing the traffic flow, for example.

The content administrator must determine which protocols corporate policy requires for content access. After identifying the access method specified by corporate policy, the content administrator can determine whether content acquisition can be done automatically or must be done manually as discussed in the next section. In most cases, HTTP is the most commonly implemented protocol for content acquisition. Authentication at the origin server provides content security, requiring authentication of the user or content acquiring accelerator.

After the issues of content access and authentication have been addressed, the content administrator must then identify whether content acquisition may be a completely automated process or requires manual intervention. Automated content acquisition is the most common approach in today’s CDNs.

For XYZ Corporation, HR documents reside on a dedicated server, within a dedicated directory. All content is accessible via HTTP and carries no unique restrictions; no user authentication is required to access these content items. HR places work safety reports on its web server at the end of each workday, making its new content creation and placement predictable.

For the content administrator responsible for HR content distribution, the easiest approach to distribution would be to configure the CDN to automatically scan the origin web server every evening for new content. A key benefit to a CDN is the ability to initiate the rediscovery process of a host at timed intervals. If HR were to produce new content as often as every few minutes, the CDN allows for configuration to automatically discover content just as quickly.

In some cases, content may be placed on an origin server at far less predictable intervals. In such cases, the administrator must initiate the discovery process manually, by accessing the central management device. If the CDN is a component of a broader content strategy within the corporation, application programming interfaces (APIs) might be used at a higher level within the network. Sending API calls to the CDN management platform allows the administrator to execute a manual discovery process.

To effectively manage the acquisition process, the content on the origin server must be identified and understood. There are two common approaches to targeting content in a CDN prior to acquisition:

Both options have benefits and drawbacks, as described in the following sections.

Content Crawling

HTTP content crawling begins with the designation of a given content URL, which identifies where the content acquiring accelerator starts its discovery process. Just as many popular search engines start with a given URL and spider through any associated links, gathering content, the content acquiring accelerator does the same. The primary difference between the search engine and content acquiring accelerator is that the search engine gathers copies of all content, including HTML text, whereas the content acquiring accelerator gathers copies of only the embedded objects.

Content acquisition via the crawl method includes FTP and CIFS hosts as well. To acquire FTP content, the content acquiring accelerator must have credentials defined prior to accessing the target FTP server. Both the target FTP server host name and valid credentials are required, just as if a user were to access a given FTP server. Server identification and user credentials must be configured via the central management device, instructing the content acquiring accelerator when to crawl the host server, how often to recheck the host server, and how many directories deep from the root directory the content acquiring accelerator may go.

CIFS servers, such as a Microsoft Windows host, or UNIX servers operating Server Message Block (SMB), such as Samba, allow for CIFS content access. The content acquiring accelerator can acquire content via an explicit manifest file or via the crawl method of discovery. As with HTTP, HTTPS, and FTP, CIFS content acquisition supports the ability to define custom port numbers and username and password credentials for authenticated content access. CIFS acquisition also includes the option to define the username’s domain if required by the CIFS server.

Some potential challenges are created by the crawl mechanism. The content administrator’s knowledge of the content that resides on the origin server becomes critical to the success of an automated discovery system. If the administrator accidentally places an item on the server that should not be distributed, or that is excessively large, the content acquiring accelerator will automatically acquire and begin the distribution process of the unintentional content. CDNs allow for safeguards to be in place, limiting the automated crawl process to acquire only content that matches a given file extension, minimum or maximum file size, file creation date, or MIME type. Content acquisition flexibility is critical to effective administration. Figure 5-5 illustrates the logical method of content crawling.

Figure 5-5. Crawl Discovered Objects

Explicit URL Specification

Explicit URL specification carries several benefits to the content administrator. Content portal vendors also benefit from the explicit URL method of content identification. With the use of an explicit manifest file, the content acquiring accelerator parses a predefined list of content URLs, acquiring strictly the content that is identified in the list. If a directory houses thousands of content items, and only ten items are identified within the manifest list, only the ten items identified will be acquired. Explicit manifest files guarantee to the content administrator that only specific content items will be acquired and distributed to the edge serving accelerator.

The manifest file may be hosted from any HTTP-, HTTPS-, or FTP-accessible source. It is critical to the content administrator that the list be accessed from a host that requires valid credentials prior to allowing access to the list. If a user inadvertently gains access to this list, the user will have visibility into every item targeted for distribution, as well as access to any login or password information included in the manifest file itself. A compromised list might provide the curious user access to a corporate announcement, time-sensitive marketing materials, or information about an upcoming event that might directly impact the user. To many enterprises, their employees pose just as much of a security threat as the outside world does to their corporate data. Example 5-1 lists five formatted entries from a sample manifest file.

Example 5-1. Sample Manifest Text

<CdnManifest>
<item-group
    server="cisco"
    ttl="1440"
    type="prepos" >
   <item src="images/logo.gif"/>
   <item src="images/wireless.gif"/>
   <item src="images/connected.gif"/>
   <item src="images/waas.gif"/>
</item-group>
</CdnManifest>

Third-party content portal vendors benefit from the use of the explicit manifest file as well. When the portal automatically creates the explicit manifest file for the CDN, the content acquiring accelerator can parse the portal-generated manifest file and acquire content automatically. For corporate communications, video on demand (VoD) recordings, e-learning materials, and HR policies are commonly created and added to the corporate servers on an ad hoc basis. Acquisition and distribution of the ad hoc content can be completely automated. The content acquiring accelerator can proactively scan for updates to the manifest file at timed intervals.

The CDN may also be instructed to check for an updated manifest file if the content portal application places an API call forcing the reparsing of the manifest file. For content portals that support API communication to CDNs, the content distribution process becomes a function that the portal owners do not need to be aware of. The acquisition and distribution process is automated, allowing job tasks to remain focused on the portal and the quality of the content provided within the portal.

Figure 5-6 illustrates an administrative host initiating an API session with a CDN, triggering the acquisition process. The externally initiated API session informs the central management device that a new manifest file is available. The central management device fetches the manifest file, passing it to the content acquiring accelerator. The content acquiring accelerator parses the new manifest file, fetching the content items listed within the manifest file.

Figure 5-6. API-Initiated Acquisition

Management of two or more platforms may require more than one administrator; as multiple platforms are introduced, an additional administrator per additional platform might be required. One administrator may be responsible for the CDN in general, one for the content functions on the CDN, and potentially one for each of the content portals that the CDN will access as a content source.

In large enterprises, individual media management teams are common. There may be one person representing HR and its portal, one for sales, and one for marketing. To smaller corporations, this may seem excessive, but to large corporations that have thousands of employees, the administrative staff might involve teams of people instead of one person. The more a CDN and portal can be automated, the easier the administrative staff’s job will be, when a single point of contact manages content for a large department.

The ability to effectively and directly manage which content is to be distributed throughout the network requires planning, communication, and an understanding of the application to which the content is associated. Planning involves the content creator, the network administrators, and potentially those who oversee corporate policies. The content owner, CDN system administrators, and any parties interested in traffic that traverses the WAN must all be in communication with each other. Even in automated environments, each party having knowledge of what the others are doing enables each group to interoperate with fewer surprises. If a network outage is planned at the same time as the distribution of critical HR data, for example, this could significantly impact the corporation. Other systems may also be left at a disadvantage, such as the origin web server. If requests cannot be serviced by the edge serving accelerator, they will ultimately go to the origin file server.

It is not implied that CDN administrators should have infinite knowledge of how the application itself functions, but they must be educated on how the content they manage impacts the corporation. Administrators should have an understanding of the concepts that surround the application that users will access and what the application’s role is within the corporation. If the CDNs’ system administrators understand the application, they will be in a position to better manage the network and meet the content owners needs when a concern arises. If the application is something as simple as distributing a daily report, the report has a business value that content administrators must understand. Effective management of content distribution requires knowledge of the content and its value.

If networks were to involve a single data center, with no branch locations, distribution could be as simple as dragging and dropping content from one local server to separate local servers. Managing content distribution in small networks is just as critical as managing content distribution in a global organization. With today’s distributed workforce, the distribution process has traditionally not been so simple. Content might traverse several different types of WAN technologies and cross multiple time zones during the replication process.

Distributed networks now follow geographic hierarchies, which provide an excellent reference point when determining how content should be distributed throughout a given network. Global enterprise networks span multiple countries, and a corporation might have in each country a network operations team that reports to the global headquarters of the corporation. To effectively manage and support content delivery in a global enterprise network, the regional data centers must be aware of any new technologies that reside in their regional data centers or remote branch offices.

Some administrators may take advantage of Multiprotocol Label Switching (MPLS) peer-to-peer distributed networks, eliminating the need for a hierarchical network topology. When an MPLS peer-to-peer network has been implemented, edge serving accelerators still service their native installed subnet, separate of any other subnet throughout the overall corporate network topology. Depending on the number of service providers used to create the overall peer-to-peer network, several hub-and-spoke CDN topologies might be created as a result. In a single MPLS peer-to-peer network, content distribution can occur via unicast or multicast broadcast, including the ability to apply QoS to the flows between the content acquiring accelerator(s) and edge serving accelerator(s). Although not a requirement of an MPLS network environment, QoS allows class-based queuing and weighted fair queuing of the CDN’s distribution traffic, adding an additional level of traffic shaping and management.

The overall operation of the global CDN commonly remains within the corporate data center, but distributed regional data centers typically require access to the management console to monitor accelerators they have ownership of. Although management technologies such as the Simple Network Management Protocol (SNMP) allow for external probing of devices that reside in the network, any events that SNMP is not equipped to observe are commonly reported at the CDN management device. The ability to quickly identify a hardware or software fault in an edge serving accelerator that may reside 10,000 miles away from the corporate office reduces management’s risk, and reduces downtime to the corporation.

The cost of a network that uses a common service provider throughout the entire extended infrastructure usually is less than the cost of a distributed network that traverses multiple service providers. Although it is outside of the scope of the CDN system administrator to manage the infrastructure, he must be aware of the environment that supports his services. As one example, a U.S.-based corporation employed the services of three individual regional service providers. Although some service providers charge for bandwidth usage as a flat-rate price, this specific corporation used service providers that charged by measured usage. In an environment where bandwidth usage is the pricing model, distribution is most cost effective when content traverses the network only once. For the corporation that used three independent service providers, content distribution was costly because the content traversed two of the three providers’ networks twice. Traffic billing occurred as the content was brought into the service provider’s network and then out to the accelerators at the network’s edge.

Understanding the network’s topology and the cost model behind the network allows the CDN administrator to effectively manage the costs associated with the distribution of content. Although this U.S.-based corporation would have benefited from a single service provider instead of three different service providers, the costing would have become significantly higher if satellite-based networks were implemented. CDNs save on overall network bandwidth consumption and greatly reduce overall costs associated with client access to content. The network itself may always remain an expensive requirement of corporate success, regardless of the addition of a CDN.

CDN administrators must have access to announcements and the schedule for any LAN, WAN, and satellite outages. Outage and maintenance information help the content delivery manager to set delivery expectations with the content owners, reducing potential data outages and employee productivity losses at target locations. Not every network outage is planned, but scheduled events should be known by the CDN manager, to help maintain employee productivity and reduce financial loss.

Table 5-1 illustrates commonly used WAN technologies and their bandwidth offerings available today. Service provider offerings include traditional telecommunications rates, multiple service operator cable modem rates, and digital subscriber line (DSL) rates. Average price models are also shown for reference, but keep in mind that, as with any product, pricing will continually change.

To manage the distribution of content throughout an enterprise network, the network topology must be well understood. This includes a topology mapping of the WAN bandwidth between data centers and remote locations. If remote locations have secondary WAN connections, these too must be identified when planning the distribution topology of the CDN. Router configurations are beneficial for locations that employ secondary WAN connections, allowing for any additional configuration changes to be added to disable content delivery in the event of a failed primary WAN link. If a WAN outage requires that the secondary link be enabled, it is common to find that enterprises disallow content distribution to take place over their secondary WAN links. The already reduced throughput capacity of a secondary link might support only predefined business-critical applications.

With the affordable adoption of broadband services, many small branch locations now employ the offers of their local multiple service operator. Cable modems and digital subscriber lines are affordable connections that offer vast bandwidth improvements over legacy services such as fractional T1 connections. Internet connections that traverse the public Internet add security and content-protection challenges that the use of VPN-enabled routers have helped to address.

The CDN administrator must be aware of the “external” networking services provided by multiple vendors, because each service might offer a differing bandwidth rate. Some locations might support higher speeds than others. Differing speeds might allow content to be distributed to some locations faster than to others. For networks with differing WAN speeds, the ability to manage the distribution of content and the expectations of the content owners become important factors when structuring the support model of the CDN. It is common for administrators to define a flat-rate speed for all remote locations, regardless of their WAN’s throughput capabilities.

The XYZ Corporation has offices in Asia, Europe, and the United States. Many of its U.S. locations are connected to the corporate network via major service providers. Some of the corporation’s smaller branch offices use the local cable company’s cable modem services. Some of the larger locations throughout the United States have satellite uplink capabilities, with access to 5 Mbps of downlink throughput. The corporate data center in New York City employs redundant T3 network connections to the Internet to support the aggregated connections of the United States, Europe, and Asia. In Europe, all remote offices use E1 connections that aggregate in London and then connect to the corporate data centers in the United States. Asia employs fractional T1s to the many manufacturing plants, with an aggregation point in Tokyo. Tokyo directly connects to the corporate data center in the United States. Although central management of the global network exists in the United States, regional management exists in London and Tokyo. Figure 5-7 illustrates a simple high-level master topology for the XYZ Corporation.

Figure 5-7. XYZ Corporation WAN Topology

With the vast differences in WAN bandwidth offerings, the ability to effectively manage the distribution process requires some initial planning. For example, the distribution of a 10-MB file may take 53 seconds on a T1 throughput rated WAN connection. The same 10-MB file might take only 13 seconds when distributed to a remote location that has a 6-Mbps DSL connection. The introduction of cable and DSL services has broadened the remote-access options for corporations and created new expectations of content access performance by the employees who work in those connected offices.

It should never be assumed that remote locations that use public Internet-type connections are using a firewall, but if they are not, they should be. CDNs have the ability to pass traffic through firewalls, without disruption to other services. An edge serving accelerator that resides behind a firewall creates acquisition traffic that appears similar to web traffic created by the other clients that reside behind the firewall. Typically, no special considerations are required at the firewall to allow content delivery to take place through a firewall.

Combining an existing desktop management suite with an accelerator or CDN will provide a significant improvement to the desktop management process. Combining a reliable distribution method with a proven desktop management suite will provide benefits to both administrative teams. The desktop management team will now know that their distribution traffic does not disrupt other business activities, and the CDN administrator will provide direct support to the desktop management team. Both can operate independently of each other, or the desktop management team can be given access to the central management device to coordinate its own distribution activities.

Some branch offices might have several client computers installed, requiring software updates to traverse the WAN independent of the other systems. This model is very inefficient and costly to the WAN’s available resources. Desktop applications such as Microsoft Systems Management Server and Altiris Client Management Suite might apply software, patches, and upgrades to remote branch servers and workstations after hours, to prevent bandwidth contention. These applications might have access to branch systems only during hours when both the network is available and the remote systems are not active in a production environment. Unless patch management is applied locally to each edge system, access to the WAN becomes a requirement.

If the software management system has to share bandwidth with the CDN, it may be most beneficial to integrate the software management system with the CDN solution. An alternative is to implement an accelerator solution in the branch office. The installation of a CDN will allow for a single transfer of the software updates, regardless of the number of clients and servers deployed in the remote branch.

Internet access during business hours is becoming an increasingly costly challenge to the corporation due to reduced employee productivity during normal work hours. Many network administrators have implemented URL filtering solutions in the core of the network to prevent employees from accessing the Internet during business hours. Some allow Internet access, but limit that access to only Internet sites that are deemed appropriate during business hours.

After-hours Internet access is becoming more popular, because employees enjoy the increased bandwidth offered by the corporation’s network. Allowing after-hours Internet access also helps alleviate the spike in Internet access that many corporations observe during the midday lunch period. If after-hours Internet access is allowed, it should be known by the CDN administrator. Internet access is traffic that the CDN must interoperate with, even if the Internet access is not a business-critical use.

WAN traffic trending is the most valuable information a CDN administrator can have access to. These reports provide statistics and trends that are real-world usage patterns. Utilization and traffic flow reports confirm information that the network administrators provide, and occasionally uncover other traffic that network, server, and CDN administrators might not be aware of. If the resources exist within the data center to track and monitor network usage, even by protocol, applications or backups, new uses for the CDN may be uncovered, adding value to the corporation’s investment.

Centralized accelerator management allows administrators to gain visibility into the underlying system that controls and houses prepositioned content. Accelerator management of the dedicated CDN is different from that of the distributed server management model. CDNs require management of not only the operating system that runs on the dedicated accelerator but might also go to a level that involves direct control of any content that resides on the edge serving accelerators. Centralized accelerator management, for the CDN, also requires a method to centrally administer any patches or system upgrades from a single secure console, due to the unification of the operating system and content delivery product itself.

To effectively manage an edge serving accelerator, its security properties, storage configurations, and how the accelerator will interact with the network environment, a centralized management platform is best. For CDNs, the central management device fulfills all device and accelerator-related management needs. Although SNMP-based solutions might offer limited control of an edge serving accelerator, an SNMP approach is a much more generic approach to a given device or accelerator’s control needs. Centralized management that is secure will go far beyond what SNMP v2 and v3 support and will include a more diverse graphical interface. A purpose-built centralized management device will communicate with each edge serving accelerator securely, sending any new configuration and content instructions, while gathering health, content, and utilization statistics simultaneously.

Centralized device management allows for a lower level of control below what content administrators require, taking into consideration storage allocation, disk partitions that may be required, accelerator network settings, streaming media services, authentication, and access control lists (ACLs). Each of these settings will not require the content administrator’s involvement, but will require proper configuration. As an example, if an enterprise-wide directory services administrator from the XYZ Corporation were required to apply a user-focused policy to each user’s object in the network domain, it would be a repetitive process to do so for each employee’s user ID. If an ACL were required for all content accelerators throughout XYZ Corporation’s network, manually setting the ACL would be a very time-consuming process. Centralized accelerator management for remote edge serving accelerators allows for edge serving accelerators to be grouped for easier mass accelerator management, just as the principal of the user group aids administrators in configuring and controlling hundreds or thousands of user account properties.

Accelerator management of prepositioned storage-related settings for an edge serving accelerator involves discussions with the content owners themselves. Knowing how much content is to be prepositioned is required information, because any partitions related to prepositioned content must coexist with other disk needs as well. Knowing how long the content should coexist with newly added content is also required information for storage utilization purposes. Accelerator- and disk-related management might involve extended storage of transaction logs that are a result of content usage; this is a requirement for some corporations that have compliance regulations in effect. Accelerator management of CDNs that use partitions that support content caching and streaming media impacts how each edge serving accelerator’s storage configuration is defined.

Some general rules exist for determining edge serving accelerator storage needs. The host operating system, cached content needs, streaming media content requirements, and transaction logging all become factors that must be known. In the process of investigating disk needs, consider the following content tendencies:

Accelerator management and live streaming media services are best managed in a centralized or group-based model, with VoD commonly leveraging static accelerator policies. Enabling streaming licenses commonly is applied to either new accelerators that have recently been added to the network or to all accelerators globally throughout the corporation. License keys often are lengthy and cumbersome and are best applied from a central management device.

The alternative to centrally applying licenses is to access the edge serving accelerator’s command-line interface (CLI) and enter the configuration commands manually. The manual process is more prone to operator error, due to the less-streamlined process of keyboard interaction.

Accelerator configurations related to specialized live events, frequent streaming media bandwidth adjustments, and simultaneous session limits are all best handled via centralized accelerator grouping management; area commonalities such as remote users groups, and branch standardized LAN configurations can easily be managed as groups. To effectively deliver a live streaming event to large numbers of remote offices, nonstatic bandwidth changes may be required during the period of the live broadcast, or transitioning from unicast to multicast distribution for a given event.

The ability to centrally control each edge serving accelerator simultaneously will make the administration process significantly easier than accessing each edge serving accelerator locally, specifically when all accelerators must access a common stream source at exactly the same time. In situations that involve live broadcasts, the network administrators may commonly not be involved in the process, other than knowing that an event is pending. Content administrators and content delivery system administrators carry the majority of the responsibility for managing these events, calling in network administrators if an event fails to properly launch at a given remote location.

It is highly recommended that live events be tested several days in advance of the actual event, to ensure network stability. Pre-event testing is especially beneficial for multicast type broadcasts. Redundant streaming sources provide an added level of protection, allowing the CDN to access multiple sources as failover hosts. Prior to the actual live event’s broadcast, many corporations will run a pre-event feed to ensure that all remote locations have adequate access to the event prior to the actual broadcast session. Actively monitoring and managing all edge serving devices during the test event, and prior to the actual event, will allow for any custom changes to be applied to edge serving accelerators before any business-impacting surprises arise.

Network administrators typically are responsible for accelerator management and user authentication and authorization policies. Content administrators must determine whether or not their content requires the enabling of access authentication for a given set of managed content. The role of the content owner differs from the role of the CDN’s edge serving accelerator, which the CDN administrator is responsible for.

Keeping job roles separate, the content owner requires that content requests will be secured behind a prompt for end-user credentials. The system administrator is responsible for the back-end authentication settings related to domain controllers, groups, and domains that facilitate the content owner’s requirement. Each of these settings is configured at the accelerator level, with authentication impacting access to content, the accelerator itself, and the ability to actively configure and manage any accelerator in the CDN. Accelerator management and the ability to remotely manage an edge serving accelerator are functions that are controlled through credential-based validation.

System administrators commonly have a single defined standard for server-based content authentication. The most common methods are NTLM versions 1 and 2, HTTP basic, or an HTTPS form with a set cookie. The edge serving accelerator communicates with the authentication server’s database via the LDAP, NT LAN Manager (NTLM), RADIUS, or TACACS+ protocol. For an edge serving accelerator to properly authenticate a user’s credentials, a challenge is presented by the edge serving accelerator, to determine who the user is that is using the requesting computer. For some Microsoft Windows–based operating systems, the browser provides the user’s credentials on behalf of the user, but only when NTLM is the authentication method used.

The XYZ Corporation has standardized on NTLM throughout its network, due to the dominance of Microsoft servers within the network. The edge serving accelerators have each been configured to direct authentication requests to specific hosts within the network. The system administrators require authentication from the CDN to prevent unauthorized access to content that is specific to different groups defined within their active directory domains.

When configuring the origin server that the user will access for the core HTML or ASP content, many times, the authentication challenge for content access will be issued by the origin server itself. In these cases, the edge serving accelerator might not need to be actively involved in the authentication process if the client must provide valid credentials just to gain access to the portal. This method of authentication is commonly referred to as pass-through authentication, where the edge serving accelerator plays a passive role in the passing of the credentials between the client and the origin server.

If a requesting client is accessing prepositioned content via an edge serving accelerator configured as a proxy, then the edge serving accelerator will issue an authentication challenge to the requesting client. Proxy configurations are described later in this chapter, in the section “Understanding Explicit and Transparent Proxy Modes.” When the requesting client responds to the authentication challenge, the edge serving accelerator communicates with the configured external authentication host, to verify the credentials contained within the user’s response. To the administrator of the CDN, the process of configuring authentication typically involves defining the external host or hosts and enabling the appropriate method of authentication.

The responsibilities of the content administrator and the CDN system administrator differ greatly from the perspective of user authentication. Content owners must only determine if authentication is required for their prepositioned content. The system administrators must configure and control the underlying authentication implementation to support the content owner’s needs. Accelerator management of authentication-related functions is best handled at a central console, by targeting all accelerators collectively or by targeting groups of edge serving accelerators. It is very rare that each remote edge serving accelerator will have its own dedicated external authentication server; in situations where this is the case, each edge serving accelerator must be individually managed either via the central management device or via the edge serving accelerator’s CLI.

A less common method of content request control involves the use of ACLs. ACLs are most commonly applied to network routers and switches but are also supported by content networking accelerators. ACLs execute simple allow or deny type decisions against requests that pass through the edge serving accelerator. Decisions are imposed on content requests based on several factors, which include simple variables such as the source address or the destination address of the traffic passing through the edge serving accelerator. ACLs are not limited to just HTTP traffic, but are applied to a number of protocols. ACLs offer system administrators a level of control over IP, TCP, UDP, GRE, and ICMP traffic types.

For CDN administrators, the process of implementing ACLs should be done centrally. Accessing edge serving accelerators individually via a central management device is the best option for ACL management. Due to the differing subnet address ranges that might exist at each edge location, no two edge serving accelerators may be installed in the same subnet mask. ACLs applied to one edge serving accelerator might be valid for all requests that traverse a given edge serving accelerator, whereas misapplied ACLs might implicitly deny all requests due to no address matches. IP address–type ACLs are among the more basic types of ACLs that exist today.

Extended IP ACLs provide a greater level of control over and visibility into the requests that traverse an edge serving accelerator, by limiting the requests to which the edge serving accelerator will respond to only those that enter specific ports. In addition to the basics supported by ACLs, such as the source and destination IP addressing, extended IP ACLs take into consideration the source and destination ports within the request, specifically content-related ports such as 554, 1755, 21, 22, 80, and 8080. Source and destination port numbers can commonly be correlated to the application that the client may be requesting. When used properly within a corporation, streaming media leverages known port numbers. Nonbusiness-related streaming media requests may be blocked, if the edge serving accelerator does not recognize an approved client, server, and port number traversing the edge serving accelerator. The same accelerator management general rule that applies to basic IP ACLs also applies to extended IP ACLs: each edge serving accelerator may have been installed on a different subnet from where the other accelerators are installed, requiring differing ACLs for each edge serving accelerator.

Accelerator management via SNMP is one of the most common methods for accelerator monitoring. Management via SNMP allows for visibility into each edge serving and content acquiring accelerator, including management and routing devices. At the first instance of a detected fault, or event, the edge serving accelerator has the ability to announce a trap. A trap is sent to an SNMP management host or station, which is a device that operates independently of the content delivery network. Many corporations implement SNMP management applications to allow for centralized monitoring of all network devices, including file servers and storage hosts.

SNMP supports three different versions: version 1, version 2c, and version 3. SNMP version 1 is the least common within the corporate network today, due to limitations in traffic security and authentication. The opportunity for unauthorized visibility into a given device is most likely due to version 1’s “in the clear” model of communication. SNMP versions 2c and 3 are recommended over version 1, due to their inherent support for encrypted and authenticated communications.

SNMP monitoring is not a utility for content administrators; system administrators will have more interest in the information provided from SNMP management. Some of the more important information made available from SNMP monitoring includes disk-related data, such as read, write, and failure-related events. At a minimum, storage-related events should be tracked via SNMP, due to the storage-centric nature of the edge serving accelerator. Software and system events may be tracked from the central management device, but if storage-related events with a negative impact occur, the administrator must be made aware of the event at the soonest possible opportunity.

Management of the CDN’s usage statistics, bandwidth savings, and transaction log generation are all topics that involve both the system administrator and the owner of the prepositioned content. Each topic potentially provides business-critical information. If the executive management of a corporation requires all employees to watch a designated video on demand to ensure procedural compliance, access to prepositioned media must be tracked. With the growing requirements for procedural compliancy, information consumption tracking is critical.

Operating system recovery, patch management, and device software management are the responsibility of the content delivery system administrator. These underlying device management obligations will not impact the content owner’s responsibilities, and are viewed as system-related tasks. Unlike the model of distributed general-purpose file servers, server management may involve several teams, including content, application, and data owners.

Content delivery devices and their related accelerators are based on an operating system and appliance combination; true appliances use purpose-structured operating systems that are the foundation for a purpose-built content-hosting application. The concept of operating system patch management does not apply to the appliance model of accelerator operating system management. The most common method of host patch management is to apply an updated software image to the content accelerator.

The operating system used in an appliance-based model does not include many of the extras that are found within a generic operating system, including games, additional enabled ports, or non-content-related services. For example, the use of various ports and services on a dedicated appliance that supports ports related to Microsoft Windows host name resolution may interfere with legitimate client to server communications. Excessive ports and services become a security risk if left inadvertently active, and in some cases might interfere with other, non-content-related services.

The ability to centrally manage the software that resides on edge serving accelerators is critical to the success of the system administrator’s role. Accelerator software management is not a function of the content administrator’s job responsibilities, other than possibly coordinating the distribution of the software upgrade image itself. From the central management device, the acquisition, distribution, and scheduling of a software image upgrade can all be centrally controlled. CDNs support the ability to distribute their own images, without the need of compact discs or other portable media methods. In the event that software upgrades must be done locally, edge serving accelerator can leverage their local CD-ROM drive to source the software upgrade image. Flexible CDNs present several options to the system administrator, based on business needs and processes.

When used within a CDN, the CIFS protocol becomes a read-only access method at the network edge. Do not confuse the CDN’s implementation of CIFS with the CIFS implementation found within an accelerator; accelerators allow for bidirectional access of content over the CIFS protocol. CDNs are a one-way distribution process; if content write access to an edge serving accelerator were allowed, a content mismatch between the edge serving accelerator and the origin server would exist.

CDNs have the ability to acquire content via CIFS and make the prepositioned content available via CIFS. Access to prepositioned content may be protected by user authentication, just as with other web-based protocols. Delivery of content that has been made available via a CIFS share should be compared to that of a network-accessible CD-ROM or DVD-ROM device, on which the user has access to the content only as read-only data.

CIFS distribution is very popular with enterprises that require the ability to distribute documents that have been converted to read-only formats, such as Adobe Corporation’s Acrobat format. These documents might be corporate policies, customer records, or even images that the employee will never require write access to. CIFS-accessible content on the network appears just as any other file server access appears during network analysis.

Bandwidth throttling or throughput rate limiting of CIFS-accessible traffic is not common, due to the slow nature of the CIFS protocol and the amount of excessive overhead that is native to the protocol. Although CDNs support CIFS as an access method, a WAN optimizing accelerator will offer much better performance, with bidirectional content access as needed.

HTTP is the most common access protocol used by clients of a CDN. HTTP is a one-way protocol at the network edge and is most commonly used by web browsers as an access application. HTTP is a very flexible and network-forgiving protocol, allowing for network disruptions, high latency, and slow-throughput environments.

The nature of HTTP allows for edge serving accelerators to impose throughput throttling at the edge without disrupting the ability for an application to function. Throttling is most important at the network edge if content objects are significantly large. A document may be several hundred megabytes in size and traditionally transfer very slowly over the WAN. This slow transfer disrupts the performance of the WAN, but has little effect on the performance of the LAN. If the same large file is requested from an edge serving accelerator that resides on the client’s LAN, the high burst of traffic might be disrupting to the LAN. CDNs allow for maximum throughput ratings to be applied to HTTP to prevent LAN saturation.

HTTP traffic interoperates with other LAN traffic very well. If the network becomes saturated with other traffic, HTTP accepts what little network bandwidth is available. If the network has an inconsistent amount of available throughput throughout the day, the protocol just adapts to what is available. HTTP traffic commonly does not receive preferential treatment on the network, unless a quality of service (QoS) policy has been explicitly created for the content being distributed throughout the network.

To the benefit of HTTP, many applications have been written to take advantage of the protocol, outside of the web browsing software market. Desktop software and patch management applications commonly take advantage of HTTP, placing requests to their local edge serving accelerator for software and patch-related content. Database applications also leverage HTTP as a transport mechanism, due to the forgiving nature of the protocol and the ability to eliminate dedicated software-based applications from every accessing client. HTTP allows for distribution and access to nontraditional formats, such as spreadsheets, documents, and software applets. Throttling of these objects might become critical to the network administrator if LAN access becomes a limitation. Throttled content access will still perform at significantly faster rates than what may be available via the remote location’s WAN connection.

HTTPS has become increasingly popular within enterprise and government networks. The selection and implementation of HTTPS is unique; protocol selection commonly involves predetermined technical business decisions. Content that has been acquired and prepositioned via HTTPS commonly involves sensitive corporate records, confidential data, or customer-related records. Unlike HTTP, HTTPS access requires a valid client certificate and key to gain access to the edge serving accelerator. Once a session has been established via HTTPS, any authentication and access control must be satisfied.

HTTPS should not be confused with other authentication methods; HTTPS is merely the access protocol. The traffic that traverses the LAN within an HTTPS session is encrypted, which prevents others on the network from “sniffing” and “inspecting” the traffic between the client and edge serving accelerator.

HTTPS offers many benefits, mostly security related. HTTPS requires valid server certificates and client keys to exist on the edge serving accelerator and requesting client. If the edge negotiation process fails between the two devices, then access to the accelerator is denied. Protocol negotiation occurs prior to the actual request for content.

There are two different methods of HTTPS implementation on an edge serving accelerator:

Software-based HTTPS decryption requires that the edge serving accelerator process the certificate and key negotiation within the accelerator’s processor and RAM. As additional HTTPS sessions are established, additional system resources are consumed with each session. Software-based HTTPS processing is considered least efficient to the edge serving accelerator, with resource consumption increasing with each simultaneous connection.

Hardware-based HTTPS processing is considered more efficient than software-based decryption, due to the dedicated hardware components that process only HTTPS traffic. With a dedicated HTTPS hardware component installed within the edge serving accelerator, the edge serving accelerator continues to have less-impacted processor and memory resources available.

With the growing adoption of HTTPS, applications must be ported from HTTP to HTTPS, and valid certificates of authority must be created for the application servers and edge serving accelerators. If a valid certificate is not available, the security and control of the content may be compromised. Transitioning from HTTP to HTTPS creates added potential costs to the corporation, although some corporations allocate additional funding for security-related functions. Enabling of software-based HTTPS processing does not incur any additional software costs to the CDN system administrator, because this functionality will already exist within the system.

FTP access of prepositioned content is very uncommon within the enterprise. FTP, by nature, is known to be nonfriendly to networks that have limited bandwidth. CDNs bypass the WAN limitations that FTP creates by acquiring the content from an FTP server and by distributing the content under the CDN’s bandwidth and time-of-day control functions. Due to the traditional challenges imposed by FTP over the WAN, it is not common for enterprises to start using this protocol once the CDN has been implemented.

FTP distribution of content may be leveraged for some applications that still call for the protocol’s usage. If an application that calls on FTP as its content transport is used, the content request might be intercepted by the edge serving accelerator, which would access the file locally. File servers that are accessible via FTP may be accessed by content acquiring accelerators for the process of content prepositioning to the network edge. The process is one-way when used with a CDN, not allowing files to be pushed back into the data center. If bidirectional FTP transfers are a requirement, then a WAN optimizing accelerator must be implemented.

Although the use of FTP within the corporate network still exists today, it is used less commonly than other protocols. UNIX systems and some legacy applications still use FTP today. Over the course of time, many of these applications are expected to evolve into using more common protocols such as HTTP and CIFS for file exchanges between the client and server, and between servers.

The Real-Time Streaming Protocol is a streaming protocol implemented by Microsoft for its Windows Media Server, by Apple for its Apple Darwin Streaming Server (QuickTime), and by RealNetworks for its Helix Server. Although a standard exists today for this protocol, the implementations by each vendor differ enough to make each server and client function incompatible. For Microsoft’s RTSP implementation, this protocol is the default protocol for streaming media for the current release of Windows Media Player. With the retirement of the MMS protocol, Microsoft has identified RTSP as the standard protocol for streaming media between a media server and client. Following Microsoft’s lead, the same rule applies between an edge serving accelerator and requesting client’s media player.

Although each vendor’s products will continue to evolve into noncompatible inter-vendor solutions, each of the three vendors supports its own flavor of RTSP. All vendors have common minimum components to support RTSP, each component becoming a requirement within an enterprise network. Specification and management of the following components is commonly outside of the scope of the content delivery system administrator’s duties, and is otherwise owned by the department overseeing the content creation:

In addition to the encoding process and any related hardware and software, content encoding should meet the following criteria:

An encoder is a generic requirement for streaming media, but might not be the actual source of content for a CDN. A media server might exist between the encoder and content acquiring accelerator. In cases where the server is the encoder as well, then the content acquiring accelerator accesses the encoder as its content source. Matching CODEC are required for proper stream sessions to exist between the server and content acquiring accelerator. Unless the content is progressively downloaded via HTTP, the content acquiring accelerator must recognize the RTSP protocol and CODECs required by the media server or encoder. Native acquisition of RTSP content might be a security requirement, depending on the nature of the content and the security issue of media server exposure when streaming over HTTP. Protocol requirements at the encoder or server should carry down to the edge serving accelerator and the sessions that are exchanged with the end client media player.

The XYZ Corporation presently supports Microsoft Windows Media Player as the standard media player at every desktop. Prior to the deployment of the CDN, the network administrators had no way of providing a quality video experience over the corporate WAN. With the use of the CDN comes the ability to natively stream Windows Media content over RTSP, both live and prepositioned to the branch locations. Prior to the CDN deployment, streaming media tests proved poor results, with low-bit-rate streaming providing postage stamp–sized video at the client’s media player. The prepositioned content now supports encode rates high enough to present full-screen video, with pause, fast forward, and rewind functions coming from the use of RTSP.

Content delivery networks that support TFTP typically are used to deliver content to a client audience that does not include the traditional client computer. TFTP is most commonly used for uploading and upgrading software onto routers and switches. TFTP is not a common daily use protocol within an enterprise network, due to common transport of custom applications that require manual installation on each participating device. By definition, files that transfer via TFTP cannot exceed 32 MB in size. This limitation is defined as part of the protocol’s standards, so CDNs follow this defined limitation. Some third-party applications allow for content larger than 32 MB to be transferred, but the CDN will not allow transfers to exceed the defined 32-MB standard.

Two common alternatives to TFTP are HTTP and FTP. Many newer routers and switches support software update transfers via these more common protocols. For routers and switches that require TFTP as the default transfer protocol, the CDN will support the distribution of the update images to the edge serving accelerators.

A router or switch that requires a TFTP-sourced upgrade image can request the content via TFTP from the edge serving accelerator. No content is pushed from the edge serving accelerator to the target router or switch device. The XYZ Corporation administrators will be using the TFTP serving function of their CDN to preposition software images for their routers and switches, allowing for centralized control of their global network. Previously, XYZ hired consultants to perform the software upgrades while on site at each remote branch location.

Live streaming is typically more sensitive to network congestion than VoD streaming. Live streaming commonly involves the streams traversing the WAN, whereas VoD may only traverse the LAN. For live streaming, at least one stream must successfully traverse the WAN from the content acquiring accelerator to the edge serving accelerator. In the case where the live stream cannot traverse the WAN without loss, the end clients experience disrupted video streaming. When considering live streaming, the encode rate must be less than the smallest WAN link that the stream must traverse. If the encode rate exceeds the slowest link, the video playback will be disrupted, and appear as choppy, or create excessive client buffering.

Video-on-demand playback of content that has been prepositioned will allow for higher encode rates to be used. The limitations imposed by the WAN are eliminated. A higher encode rate increases the overall LAN traffic if multiple users access the content at the same time and if the LAN experiences high volumes of traffic, is a non-switched (hub) environment, or operates at less than a 100 Mbps rating; then the streaming media playback performance may be degraded. Edge serving accelerators can limit the amount of streaming traffic introduced to the LAN, by limiting the number of sessions, limiting the maximum bandwidth per session, or capping the cumulative amount of bandwidth consumed in total. These settings are options to the system administrator. Unlike HTTP, streaming throughput cannot be throttled down to accommodate other traffic on the LAN; variable bit rate (VBR) encoding provides one form of control for network congestion. Any traffic that disrupts the flow of streaming media will likely disrupt the playback experience within the client’s media player or browser plug-in, stepping down to a lesser encoding rate.

To the client, native protocol usage for VoD streaming facilitates the ability to utilize their media player’s controls. For VoD, native controls allow the client to communicate with the edge serving accelerator and to properly handle client commands such as pause, fast forward, and rewind.

Other functions that improve the client’s wait time for requested content include Fast Start and Fast Cache from Microsoft Windows Media Server. Fast Start allows the client’s media player to begin playback immediately, reducing buffering times. Fast Cache populates the media player’s cache as fast as the network will support the high-speed delivery of the content to the client’s media player. The burst of Fast Cache preloaded content eliminates the potential for observed network disruption that might occur during traditional streaming to the client. Starting with the Windows Media Player version 9 release, Fast Cache and Fast Start functionality is supported. It is recommended that client PCs that are requesting content from an edge serving accelerator support a minimum of version 9 of Windows Media Player.

The origin server or host that the content acquiring accelerator must access might have unique safeguards to protect its content. One such method is the use of authentication cookies. Consider a web server that issues a valid cookie to a user once they have provided valid credentials to the server. It is that cookie which is required for any subsequent content requests. If the cookie is not present for subsequent requests, the user will either be prompted to reauthenticate with the server or be denied access to any additional content. When acquiring content, the cookie method of control is becoming more and more popular for large content-hosting portals. For the content acquiring accelerator to gather content from such a site, the accelerator must have the ability to present valid credentials, and also interoperate properly with the cookie that is recognized by the origin or host server.

One such method is to embed a valid and trusted cookie within the manifest file used by the content acquiring accelerator. This cookie, along with valid credentials, allows the content acquiring accelerator to place an initial authenticated request with the origin server or host, and then place subsequent content requests that include a valid cookie. Knowing that the manifest file now carries protected information, the manifest file itself must be protected from external threats. With access to the manifest file, a potential hacker would have all the needed information to gain access to the given content. For this reason, the content acquiring accelerator supports the ability to retrieve the manifest file from an external host over HTTP or HTTPS, with the inclusion of valid credentials at the time of the manifest file’s fetch. A manifest file should never be placed on a given host without protection in front of the manifest file.

All information contained within the file identifies all content to be prepositioned by a given content administrator. Because each content administrator might be working with their own manifest file, several manifest files might be in use at any one time.

Content that is hosted on existing corporate servers was positioned on the given server as part of an existing business process. This process is commonly a well-defined procedure. The introduction of a CDN will not disrupt this procedure. Web administrators become accustomed to specific procedures, many times including corporate security processes to place the content on a given portal.

For the XYZ Corporation, only two people within the organization have the authority to place content on the HR portal. Content posting will not take place until the content has been approved by a management team, to eliminate any potential liability concerns. The posting process is well defined, stating exactly how to transfer the content, where to place the content, and, how to enable access to the content. There is even a corporate policy defined for the process of enabling the content on the portal. These policies are not uncommon for large corporations; misplaced or inappropriate content may be costly to a corporation.

CDNs do not require that web masters and portal owners make changes to their content-posting procedures. Authenticated content acquisition and cookie-based access allow the content acquiring accelerator to interact with the origin server, web portal, or host just as any other user on the network would. CDNs should not disrupt a procedure that is known and trusted within the corporation today.

The content acquiring accelerator acquires content from two types of servers:

The first, the origin server, is the most common source of content to a content acquiring accelerator. This origin server treats the content acquiring accelerator just as any other client accessing the server. The URLs associated with each acquired content item will match exactly what the users will be requesting on the network. In this case, the acquired content is served by edge serving accelerators with no URL address translation.

For content acquisition from a secondary host, the URLs will differ from those requested by the client. In many cases, the secondary host allows only a select number of users to access the host, and might even limit access to content acquiring accelerators. Content acquisition from a secondary host requires that the URLs associated with the actual origin server be defined. If the domain name associated with the actual domain is not defined within the CDN, then the CDN will have no way of matching client requests to content that has been prepositioned to edge serving accelerators.

There are benefits to implementing a secondary host to provide content to select users and the CDN. First, it allows content acquiring accelerators to interact with a defined host that has lower network and storage utilization than a production intranet portal server. Second, it provides a staging point for content prior to its availability on the corporate intranet server. A staging site allows for the site and associated content to be tested prior to being enabled in a live production environment. Staging sites are also used by corporations that require limited or restricted external access to internal intranet sites. If CDNs have been implemented outside of the corporation, for either the public Internet or subsidiary corporations, then the staging site may be the only source of content for those external content consumers.

Acquired content consumes disk space. Some acquired content will undoubtedly be larger than other content. For example, video on demand consumes large amounts of space per file. Smaller content, such as text files, might require very little disk space. Content owners should evaluate several key factors when defining a size limit for content that is to be distributed throughout the CDN. It is common for the lower limit to range between 50 and 100 KB in size. Content sized less than the limit will be suitable to traverse the WAN for each user’s individual request. When content distribution and accelerator functions coexist within the network, the smaller objects will become reactively cached. Only a single request to populate the nonprepositioned items at the edge is required.

For larger content, objects are commonly less than 2 GB in size. Objects larger than this are usually recovery images for desktop systems, or VoD content that uses a high encoding rate and has a long running time.

System administrators are not responsible for defining object size standards, but they must be involved in allocating any storage space that the content administrator requires.

XYZ Corporation’s departments each have differing storage needs. Human resources requires at least 10 GB of storage space on each edge serving accelerator, marketing requires 25 GB of storage space on each accelerator, and sales requires 75 GB of storage on each accelerator. In total, 110 GB of storage space is required on each edge serving accelerator to meet all three departments’ needs. Storage space cannot overlap, so the system administrator must allocate a total of 110 GB of space on each system for prepositioned content. It is recommended that the system administrator add 25 percent additional space for content “growth,” in the event a given department’s needs change. Figure 5-9 illustrates the differing space needs for static objects placed at an edge serving accelerator.

Figure 5-9. Static Object Storage Needs

Content acquisition for each of sales, marketing, and HR will function independently of content acquisition for the other departments, all while accessing the same centralized management device. Content administrators from each group have access to and control over their own group’s content processes through their own dedicated portals. If HR makes changes to its manifest file and initiates a manual rediscovery of content on its origin server, sales’ and marketing’s manifest files will not be accessed. Content administrators have the ability to define which content items carry a higher priority than other items within their given group.

Content administrators do not have control over when the acquired content will be distributed out to the edge locations. The time-of-day and bandwidth settings are owned by the system administrator. Separation of system and content administrator responsibilities becomes much more logical when considering that all three different departments within the XYZ Corporation might be competing for shared storage and distribution bandwidth. Although each group works for the same corporation, the well being of each group’s content is the respective group’s primary concern. If HR had the ability to set a higher priority for its content than what is set for the content of sales and marketing, the overall CDN would become a focal point of corporate political unrest. The system administrator controls the priority levels of each group’s distribution process. HR most commonly has the highest priority during the acquisition and distribution processes, followed by sales and then marketing.

If each edge serving accelerator in a CDN obtains its content by accessing the origin server or secondary host directly, this architecture is based on a direct fetch model. The direct fetch model requires that each edge serving accelerator operate completely independent of other content accelerators, acquiring content from origin servers in the data center. No two accelerators interact or share content. Figure 5-10 illustrates the direct fetch model.

Figure 5-10. Simple Direct Fetch Topology

Allowing all edge serving accelerators to communicate directly with the origin server has positive and negative points.

A distributed hierarchy is the foundation for a scalable CDN. With a distributed hierarchy in place, content acquisition occurs at a single location within the network and content is distributed effectively to each edge location once. If the network involves several hub-and-spoke regional data centers, each hub becomes a new layer of the CDNs’ hierarchy. Figure 5-11 illustrates a sample CDN based on XYZ Corporation’s corporate topology within the United States.

Figure 5-11. XYZ Corporation Major U.S. Locations

Figure 5-11 displays a network that is a single-level hierarchy. The origin server resides in the corporate data center, and the content acquiring accelerator resides within the same data center. This network has two remote branch locations, in Chicago and Los Angeles, which are the first level of the distribution hierarchy. In this model, content is acquired by the content acquiring accelerator, and distributed to all first-tier locations based on the time-of-day and bandwidth settings defined by the administrator. This model is an oversimplified example of how the CDN appears, but is an accurate representation of the core required accelerators.

Building upon Figure 5-11, the system administrator should consider adding additional edge serving accelerators to the remote branch office in Chicago. The office staff exceeds the capabilities of a single edge serving accelerator, so two additional accelerators have been added to this location. Several edge serving accelerators will not create additional content distribution traffic on the WAN, due to the intelligent nature of the CDN. Just as a hierarchy exists between the data center in New York City and the Chicago branch office, the CDN has the ability to create a hierarchy within a given location. Figure 5-12 provides a closer look at the hierarchy within the Chicago office. Note that one accelerator has become the parent accelerator and the other two accelerator have become children of the parent accelerator.

Figure 5-12. Location Hierarchy Model

With a multitiered network established, the traffic flows in a hierarchical network gain several beneficial features. The content that is distributed between New York City and Chicago and between New York City and Los Angeles is encrypted by default. The distribution may or may not traverse the public Internet at any given point, so encryption becomes important when distributing electronic corporate assets. The administrator now has the ability to take advantage of the bandwidth throttling between accelerators, preventing WAN saturation from the content process. Time-of-day control between locations also becomes a configurable option to the administrator, allowing distribution to occur at different times, based on the differing time zones that each location resides in.

Expanding beyond XYZ Corporation’s three major U.S. locations, the international map shown in Figure 5-13 illustrates the expansion of the CDN to include the corporate offices in London and Tokyo. Each regional location supports several children locations in the overall XYZ Corporation hierarchy.

Figure 5-13. International Regional Hubs

As shown in Figure 5-13, the topology map illustrates Europe’s regional hub in London and related downstream branch offices. The offices in Brussels, Berlin, Zurich, and Amsterdam each feed from the regional hub via E1 connections. Although Brussels, Berlin, Zurich, and Amsterdam are all children locations of the London office, none of the children locations are aware of each other. Peer children locations are only aware of their parents, which prevents the possibility of content distribution occurring between children locations, a situation that could consume twice the desired amount of bandwidth to a given child location. They each acquire content from a common parent location, London. Multiple accelerators may reside within the data center in London, providing redundancy and scalability as needed. Even with a redundant model, a single content acquiring accelerator acquires content from New York City, sharing with all other accelerators within the London data center. Downstream locations, such as Amsterdam, Brussels, and Berlin, each acquire their content from any of the accelerators located within London. If multiple accelerators exist in a parent location, the children accelerators will load-balance across all accelerators resident in the parent’s location.

If an edge serving accelerator must be replaced due to a physical failure, two options exist for populating content onto the replacement accelerator:

The benefit of prestaging replacement accelerators within the data center is that it allows a replacement accelerator to be fully populated prior to installation. This benefit does not come without the added cost of procuring and staging additional standby hardware in the data center. When an accelerator is shipped from the data center, the system administrator has the ability to preconfigure the replacement accelerator, making it a true plug-and-play replacement.

If an accelerator cannot be preconfigured, the installer must apply the basic configuration to the edge serving accelerator at the time of installation. Once the replacement accelerator has communicated with its central management device, all content will be populated onto the accelerator via its nearest parent. If the accelerator located in Berlin has failed, the replacement accelerator will acquire all content from the nearest parent location, in London.

The second option is commonly tied to a service contract, where the replacement accelerator is shipped directly from the vendor. Both options allow for a replacement accelerator to be used, easing the replacement process at the remote location.

Distributed hierarchies allow for regional hubs to provide content to downstream children locations, while preserving WAN bandwidth between major distribution points. Replacing an accelerator that has failed in Berlin will not consume any content distribution bandwidth between New York City and London. All content serving accelerators in the hierarchy preserve their assigned content, even if the accelerator will not be servicing content requests by any local clients.

Figure 5-14 illustrates how content that has been distributed from New York City to Tokyo resides on both locations, as well as in Beijing. The content in focus is Chinese marketing content, which originated in New York City. When building the distributed hierarchy, the content will reside on each accelerator that participates in the hierarchy. In this example, the content will reside on accelerators in New York City, Tokyo, and Beijing. Tokyo may house the content purely as part of the distribution process, and it might never be requested by a user that is local to the Tokyo data center. The offices throughout China may utilize Beijing as their regional hub for the entire country.

Figure 5-14. Asia Distributed Hierarchy

Expanding on the example in Figure 5-14, Figure 5-15 shows a fourth layer of the hierarchy, providing content from Beijing to children locations in the cities of Jinan and Shanghai.

Figure 5-15. Fourth-Level Distribution Tier

A general rule that applies to distributed networks is that IT support staff resources diminish with each additional WAN segment between the core data center and branch location. This general rule applies to XYZ Corporation as well, so the network administrators have prestaged replacement accelerators within the data center, including the regional data centers, to support expedited accelerator replacement. If an edge serving accelerator is preloaded with all content and has all network-related settings predefined, the installation in a remote location such as Jinan will be days quicker than applying a configuration to a new accelerator and waiting for the accelerator to repopulate all content from the nearest parent in Beijing. The volume of content on the accelerator will likely consume several gigabytes of space, which could involve several days of time just to repopulate the content to the replacement accelerator.

The XYZ Corporation has offices in all but a very few time zones, some with a 12-hour time zone difference from New York City. With regional data centers in New York City, Tokyo, and London, time zone based distribution is much easier to manage. Time-of-day availability can be broken up into two blocks:

From each regional data center to its children locations, the time-of-day windows are closer together. Bandwidth settings may be very low during overlapping working hours, but distribution will still occur. Bandwidth controls are best interpreted when the settings are being applied between locations, and not between individual accelerators. Each accelerator is assigned to a specific location. Multiple accelerators may share this location, but no accelerator can become a part of more than one location. A location may be a given floor of a building, a building itself, a city, state, or even country. A location is a logical assignment, or grouping, set by the system administrator.

Once the time-of-day windows have been established between each of the locations, bandwidth allocation settings are required. XYZ Corporation’s WAN encompasses time zones that span the globe, and its system administrator must be aware of network utilization across each of the WAN links that the corporate network uses. If any of the smaller branches use offerings from their local cable company or telephone company, these links will also need to be investigated. Some links might not be active after working hours. During the content distribution process, the link must be stable and faster than a telephone-based dial-up connection.

While investigating the network’s abilities, each location’s network components should be well understood. Some network vendors’ routers and switches are not capable of supporting multicast traffic, a limitation that could impact distribution or live streaming events. Many corporations and their networks are a collection of acquisitions and mergers, each having potentially different network hardware. If the hardware is not standardized to a common vendor, or even to a common device type for each role, understanding the network’s limitations will be a time-consuming task. CDNs support mixed distribution environments, allowing for islands of multicast traffic as needed. Unlike multicast distribution, unicast requires little to no research; if the network can pass IP traffic, unicast distribution has met its only requirement.

Unicast distribution is a one-to-one session between a content acquiring accelerator and a child accelerator. Two people that share a conversation with each other are participating in a unicast session. Unicast distribution is the most common method of distribution between accelerators, due to several different factors, including the WAN’s abilities, potential licensing costs, and ease of management.

If one network device within the path of the CDN does not support multicast, that given hierarchical branch of the network must use unicast. Networks may contain mixed environments of unicast and multicast, but will most commonly establish a standard of one over the other. Unicast distribution is more common in networks that use terrestrial services, and least common in networks that use satellite services at their remote locations.

As the default method of the CDN, unicast distribution does not require any additional distribution licenses for any accelerators. Third-party vendors who provide multicast functionality require a license fee and associated key when multicast is implemented. The availability of CDNs that support license-free unicast functionality is one of the more appealing reasons why corporations select unicast over multicast within their network, even if multicast is an option to them.

The functionality of unicast distribution is based on dedicated Secure Sockets Layer (SSL) sessions between the parent and child accelerators. If SSL is not desired, then the administrator has the ability to easily switch to HTTP as an alternative. Both SSL and HTTP sessions are options with unicast content distribution. Unicast sessions are based on standard protocols, recognized today by network administrators.

There are no additional settings associated with the actual configuration of a unicast distribution setting. The SSL and HTTP protocols accommodate network latency and throughput disruptions. System administrators can influence unicast distribution only by setting bandwidth settings higher or lower; content administrators have no control over the unicast distribution, other than selecting which content will be distributed over the CDN.

Unicast distribution applies to all types of content, including streaming media. Streaming media is classified as either video-on-demand content or live streaming media. For live streaming media, as the name implies, a unicast session is established between the parent and child accelerators, supporting a single media stream between accelerators. Unicast streams are commonly split at the edge serving accelerator, serving simultaneous users behind the accelerator. Stream splitting media over a unicast session preserves the WAN. Splitting of a unicast stream commonly involves multiple unicast streams to multiple clients that reside behind the edge serving accelerator.

Administrators must consider several factors when implementing unicast distribution. A given parent accelerator’s child fan-out limitations and the impact of high-loss networks are both factors that can impact the success of the distribution process. All CDN accelerators are subject to a limitation in the number of edge serving accelerators they can directly serve via unicast. A given parent accelerator may support a fan-out of several hundred child accelerators. Consulting a vendor-authored best practices guide will prevent the architecting of a poorly designed network.

The limits of a unicast fan-out are influenced by traffic other than the content-related traffic. Administrative and system traffic all have affects the parent accelerator’s ability to talk to large numbers of children accelerators. The management and monitoring traffic operates on defined timed intervals. Each of these intervals uses a default that has been determined to be optimal for a standard CDN. Each of the management and monitoring settings may be altered, for fine-tuning of the overall network’s performance. For example, the default distribution monitoring setting of the central management device might establish a session every 5 minutes with each edge serving accelerator. This timed interval, when spread across 300 accelerators, might create a significant amount of traffic for the parent accelerator that all 300 accelerators communicate with. Increasing the monitoring intervals from their defaults to broader ranges will increase parent accelerator resources to allow for more content delivery functionality when large fan-out environments exist.

If a content transfer exceeds a predefined time-of-day window, a unicast session will allow the transfer to continue at the point at which the session was disrupted the day prior. The child accelerator places virtual hash marks on the content, and leverages these hash marks as the stop and start points for the distribution. Transfer fault tolerance is unique to the unicast distribution model.

Multicast content distribution involves a single parent accelerator broadcasting bits of content to multiple child accelerators simultaneously. Each child accelerator reassembles the bits of broadcast content into the original content’s form. As a analogy, the speaker at a conference presents from a podium to a seated audience of attendees. The presentation is a one-way presentation, with all persons in the audience listening to each individual word, reassembling these words into meaningful sentences.

Multicast is the best method of distribution for a single location to broadcast content destined for prepositioning simultaneously to multiple locations. Multicast is a function that adds additional costs to the CDN’s purchase. The administrator must do research prior to enabling multicast to achieve a very good understanding of the network devices and their abilities. For terrestrial networks and satellite networks, the preparedness of the administrator might be the difference between a successful and failed multicast distribution of content.

Multicast distribution of prepositioned content within the enterprise network is unique. Some administrators enable multicast distribution in sections of the network, prior to enabling the distribution from end to end. Large corporations most commonly have a satellite network in place, or some form of satellite access during selected times of the day or night.

Consider a television satellite broadcast, from a corporate headquarters to remote branch offices. For video communications, this method works very well, and involves a prescheduled time of day for the event. The satellite time is reserved and the video broadcast is distributed to any remote location that has the proper satellite decoding hardware in place. For content delivery, the edge serving accelerator resides behind the satellite-enabled router or proprietary IP-enabled device. Just as employees tune into the corporate broadcast at a predefined time, the edge serving accelerator joins the multicast broadcast at an administratively defined time.

Unlike unicast distributions, which replicate content only once to each edge serving accelerator, in multicast distributions, parent accelerators will re-broadcast or “carousel” the broadcast several times to all edge serving accelerators. The reason the content is redistributed is that the initial transmission might be disrupted by factors related to the satellite link, weather, and pure timing in the network.

For example, if you were to miss the first 5 minutes of your favorite TV show, you cannot go back and watch those first 5 minutes. Consumers accept this misfortune as a fact of life. For multicast distributed content, such losses are unacceptable. If the edge serving accelerator is unable to join the initial feed of the satellite (for example, due to excessive weather at the time the broadcast started), the accelerator must have access to the content that was missed. Therefore, once a broadcast has completed a full broadcast carousel, a second carousel begins. During each carousel, any edge serving accelerators that have missed a portion of the content will communicate this fact to their broadcasting parent accelerator.

When edge serving accelerators check in with their parent accelerators, the session established between the two is an SSL-based session. Most satellite implementations support one-way broadcasts. The SSL session requires some form of terrestrial connection from the remote location and the data center where the parent accelerator resides. During these sessions, the child accelerator communicates to the parent accelerator that an additional carousel session is required for a given piece of content.

If a child accelerator cannot join a multicast broadcast within an administratively defined time frame, the child accelerator reverts to establishing a unicast session with its parent accelerator. For many corporations that use multicast, the connection timeout limit is 30 minutes. Once switched to unicast, the transfers abide by the time-of-day settings established by the system administrator. Unfortunately, the unicast session will attempt to establish a session over whatever routed path is available, many times, a link that supports throughput ratings at or below that of the satellite connection.

Some of the administratively adjustable settings include defining the address range to be used for the broadcast, setting the number of carousels to be used by the sending accelerator, and defining how many packets will be applied to an error correction block. The administrator must also determine how much bandwidth the broadcast accelerator will consume for the actual distribution broadcast.

239.0.0.0 addresses are recommended for multicast broadcasts. There are subnet ranges within the broader range of addresses that should not be used. Table 5-2 lists the IP address ranges identified as unusable for multicast broadcasts and gives the reason they should not be used. These address ranges should not be considered, due to conflicts with various operating system, hardware, and software vendors’ products.

Carousels that the broadcast parent accelerator supports will range from one to several million carousels sessions. Most corporations will not use more than five carousels within their network, due to the amount of time required for the accelerators to access the satellite network.

Forward error correction (FEC) within a multicast environment prevents errors from occurring during the reassembly process of a content broadcast. FEC is a set of packets that represents a segment of broadcast content, calculated at the sending parent accelerator. The FEC set of packets is also used to validate the content set that the child accelerator has just received. The default number of FEC packets per broadcast is 16, but the range supported goes as low as 2 packets and as high as 128 packets. If a custom configuration is used, the settings may go as low as zero. The default setting of 16 packets is most appropriate for small to midsize child accelerator; higher settings create additional processor workload on the child accelerator.

Bandwidth settings of a multicast broadcast are independent of the distribution bandwidth settings only if the bandwidth schedule is not defined. The multicast-specific bandwidth setting is a system administrator–defined bandwidth value, which applies only to a continuous setting for 7 days per week, and 24 hours per day. If these settings must be altered, then the standard time-of-day scheduler should be used. Multicast throughput settings may be as low as 10 kbps, with the upper limitation being subject to network availability.

Licensing of edge serving accelerators requires a valid unique activation key. The process of entering the activation key involves either command-line access to the parent and child accelerators or access to the central management device. Once enabled, all functions of the multicast distribution are enabled. Centralized key management is the quickest method of applying a license key to all edge serving accelerators that will participate in the multicast distribution process. Content distribution via multicast is not the same as multicast broadcasts of live streaming media. The two technologies are not associated with each other, requiring different product licenses.

Two types of content distribution traffic traverse the network:

Depending on the type of network that the content distribution will traverse, one setting may be required over the other. The default setting for content distribution is encrypted for all sessions. The type of network that the content traverses often is the influencing factor in determining whether to send all content encrypted or in the clear. If the network includes services exposed to the public Internet, such as a cable modem, DSL, or fiber-connected service, encryption is required. Other factors include the sensitivity of the content and its target audience. Content that contains a sensitive corporate message, for example, requires protection during the entire content distribution process, and therefore requires encryption.

Encrypted content distribution functions similar to a protected transmission session between a parent and child accelerator. During this session, the communication is encrypted via SSL, the default protection method. Only the parent and child share a valid key for the session, and no other accelerators may gain access to the communication.

Encrypted content sessions are most valuable when the communication between accelerators must traverse a network that includes the public Internet or part of a corporate network where employees might try and gain access against corporate policy. There is a common saying that there are two threats to corporate information security: those on the outside, and those that are already employed by the corporation. The default setting is encrypted content distribution, which protects the distribution sessions from both threats. The system administrator has to knowingly disable the security settings for content distribution between accelerators. Disabling the setting has no impact on the performance of the overall CDN.

The underlying protocol within the secure session is HTTPS, which allows the secure distribution to accommodate network performance disruptions. If a network disruption occurs that stops the secure distribution of content, the session is re-established when the network becomes stable again. The port numbers associated with the secure distribution differ from those of standard SSL-based traffic. SSL sessions default to port 443, whereas secure administration sessions are based on port 8443.

Insecure content distribution does not apply any encryption method to the flow between the parent and child accelerators. Content distribution traffic appears on the network just as any other HTTP traffic does. Null cipher distribution, or intentionally disabling encryption, exposes the same risks as any other nonsecure web traffic that traverses a corporate intranet. For this very reason, many corporations standardize on the default encryption method of content distribution. The system administrator must establish the setting for encrypted or insecure content distribution. At the time the system administrator establishes the properties of the content over which the content administrator will have control, encryption is defined as either enabled or disabled for all content under the control of the content administrator.

Video-on-demand content commonly averages 30 minutes in length for most single content items. Many portals leverage a single large content item for each module or section hosted from a given content portal, leveraging time offsets within the portal. A time offset allows the client’s media player to access content with a specified time designation from the beginning of the file.

If one large video contains several chapters, the portal may provide a URL that contains an offset, directing the user to join the 30-minute video at the 21-minute mark. Other functions that benefit the user include the ability to fast forward, rewind, skip, or pause the playback of content. These functions all enable the user to review content, or bypass content that they have already watched previously. In the case of Windows Media content, the RTSP protocol is desired. RTSP communications between the client’s media player and the edge serving accelerator allow the client to actively interact with the media stream.

To content creators, and content administrators, digital rights management is extended to the edge serving accelerator when the native RTSP protocol is used. Credentials validation and access control are major issues to content administrators who must distribute content that contains sensitive data. Corporate announcements and company meetings are two very common subjects that media services teams must support. Digital rights management allows the corporation to both distribute the content and closely control the content at the same time. Digital rights management applies to RTSP streams of VoD content and is commonly implemented via transparent authentication with NTLM.

In a server-centric unicast environment, where all clients access a common dedicated media server in the data center, the server itself might become overloaded with client requests. The most common message a streaming media user sees is buffering, which indicates the server has exceeded its capacity, or cannot deliver the stream at an adequate rate. Buffering implies that the client cannot obtain the stream at a rate that is equal to the rate at which the content was encoded. In a server-centric unicast model, too many users on a common server can cause this message to be displayed within the requesting client’s media player. This message might also appear on the client’s media player if the WAN cannot support the number of clients requesting their own unicast streams.

The streaming traffic must coexist with other traffic traversing the same WAN link. To overcome these challenges, VoD content should be prepositioned to the edge serving accelerator. There will be fewer simultaneous content requests in the remote branch than observed on a media server that resides within the corporate data center. The barriers created by the WAN will also be eliminated, due to the edge serving accelerator’s ability to serve content onto a network with significantly higher throughput abilities.

A CDN has the ability to serve hundreds or thousands of users from a single media server, by requesting a single stream from the server’s publishing point. To the client, the streams occur without buffering messages, and with no disruption to the client’s viewing experience. During an important live corporate broadcast, employees are more likely to participate in the entire session if there are no disruptions to the streaming service.

Network congestion increases with each client request that arrives at a Windows Media Server; the CDN establishes only a single session with the server. The single session established by the content acquiring accelerator is streamed to all subscribing accelerators, and split off to any requesting clients that reside below an edge serving accelerator. A structured distribution model allows for the streamed traffic to create a predictable amount of utilization on the WAN. WAN predictability is based on the known encoding rate of the streaming media session.

For redundancy within a given streaming media event, the content acquiring accelerator may point to a secondary publishing point for the same stream, or to a load-balancing switch with several media servers residing behind the switch. A secondary content acquiring accelerator may be enabled to provide a secondary source for all downstream content serving accelerators. The stream server software or hardware vendor might recommend a secondary publishing point, to reduce the risk of oversubscription of the primary streaming server. Some vendors support the ability to cluster several media servers behind a single common URL, while others support the ability to implement distributed media servers within the data center. The content acquiring accelerator can acquire content from any one of these media server implementations.

A load-balancing switch appears as a single media source or host to the content acquiring accelerator. A load balancer can hide the fact that several media servers reside behind the single source. It is common to use a load-balancing switch to support an increased number of client content requests, and to safeguard against a single point of failure at the media server. Load-balancing switches are not limited to streaming media, but rather include load-balancing support for all types of web content that a CDN supports.

Many corporations standardize on a specific version of media player. The version of media player deployed to all employee computers is unlikely to be the absolute latest release, but rather is commonly one or two versions old. The most common reason for using a legacy version of media player is to ensure compatibility with existing content and with the operating system installed on the employee computers. Newer versions of media players might not support legacy protocols that are deployed within the corporate network, and might contain software instabilities.

As an example of compatibility, in the latest release of Microsoft Windows Media Server and Media Player, the MMS protocol is no longer supported, unless over HTTP. Microsoft has replaced MMS with RTSP as the standardized protocol. Corporations that have thousands of links based on MMS throughout their corporate intranet pages face upgrading their URLs to reflect proper protocols, and must test for compatibility with the version of media player applied to client computers. If a media server cannot stream content over the defined protocol, the target audience might experience a disruption of service. CDNs have also made the transition from MMS to the standardized RTSP protocol, providing a streaming service that is in alignment with the broader streaming media market.

Demand for streaming media by corporate executives is one of the primary driving factors in its adoption today. This demand is motivated in part by increasing pressure from employees for more direct information about the status of their corporate employer. Executives are finding that their direct communication with employees improves morale and helps address employee perception of the company’s initiatives. Some executive management teams provide monthly or quarterly live communications to their employees. Although most executives prerecord the live event the day before its actual broadcast, the demand is known to exist for live broadcasts to employees.

Although proper streaming media usage requires a license fee to support native protocols such as RTSP, executives recognize that paying this license fee is a worthwhile investment to achieve their communications objective. Without the required license, the stream would be disrupted, and would show poorly within the employees’ media players.

The live streaming events can occur over unicast or multicast broadcast sessions, both requiring streaming licenses for all participating accelerators involved in the streaming session. License fees are structured in such a way that the system administrator must determine what the overall throughput need is of the edge serving accelerator, and license the accelerators accordingly. Licenses are not based on the number of requesting clients; licenses are based on the overall volume of content serving traffic.

Multicast broadcasts allow a single broadcast session to span the corporate network, under the guidance of distributed serving accelerators. If a corporate executive’s broadcast is going to use multicast, a test session should be thoroughly tested throughout the network. Any limitations or obstacles should be addressed prior to the broadcast, with the network administrative team involved in the test session.

Sometimes multicast obstacles may be outside the control of the network administrators. For example, the network infrastructure of some service providers cannot properly handle multicast traffic. Service provider–imposed limitations typically require the streaming session to use unicast instead of multicast. Many service providers cannot quickly make changes to their infrastructure to instantly support multicast within their hosted network. The CDN allows for multicast streams to be converted to unicast streams within the accelerator. There are many corporations who do successfully use a pure multicast broadcast model today. In a hierarchical network, transition might occur within a regional data center, transitioning a unicast stream into a multicast stream, or a multicast stream into a unicast stream for network compatibility.

Unicast streaming is the most common streaming used in the corporate network today, with fewer in number supporting multicast today. Unicast streaming is not hardware or WAN dependent of the network’s abilities to deliver the stream session. For a remote branch with several users, the edge serving accelerator has the ability to aggregate all users’ requests for a common stream into a single WAN stream. Stream aggregation does not disrupt the service to any users located behind the edge serving accelerator. The only real limitation that users behind the edge serving accelerator may face will be LAN defined limitations set by the system administrator. Aggregate streaming prevents WAN saturation, unless the single session which the edge serving accelerator is accessing exceeds the throughput capabilities of the WAN.

Live streaming is the least likely of streaming media events for a corporate executive to use. Many executives record their live event the day before the actual event takes place. Once the live event has been encoded, the content may be placed out on all edge serving accelerators in preparation for the next day’s live event. A function provided by the CDN allows the edge serving accelerator to broadcast a prepositioned content item as if it were a live event. Commonly referred to as a “live rebroadcast,” the edge serving accelerators begin broadcasting the content at a predefined start time. To the clients on the LAN, the live rebroadcast appears as if an actual live event were taking place.

An alternative to a live corporate broadcast is to provide access to a prerecorded corporate event as a video on demand. Following this model, the executive will once again records their message in the days prior to the actual announcement. Once the encoded content is prepositioned to all edge serving accelerators, access to the media is restricted until a predefined date and time. Once the date and time arrives, the content becomes accessible on the edge serving accelerator. If a user requests the content prior to the defined date and time, the user may be redirected to a predetermined URL.

Content that is to be prepositioned for a live rebroadcast, or video on demand, can be encoded at a rate higher than what is supported by the WAN. When the content has been prepositioned to the edge serving accelerator, the distribution occurs over a throttled session. The throttled distribution session will have no impact on requesting clients; the distribution session is not intended for access by client media players. Corporations who preposition executive messaging to the edge of the network have an advantage in the quality of their content. Prepositioned content appears better than other video events that occur over the corporate network due to the lack of the WAN’s limitations. Content which may commonly be delivered at 128 Kbps over the WAN can now be served to edge clients at rates significantly higher. The higher encoding rates allow for a significantly better viewing experience at the end user’s media player.

General content explicit proxy mode (CDNs) storage is by far the easiest to calculate, due to the known static size of each object to be prepositioned. There are three methods that can be leveraged to conserve the space consumed during the calculation process:

First, only preposition content that is larger than a defined minimum size. Some corporations allow content to be served directly from the origin server if the size is less than 50 to 100 KB, whereas other corporations have a threshold that is significantly larger. The majority of content items served from a corporate intranet server are smaller than 50 KB.

Second, check to make sure that none of the content that is to be prepositioned already exists in other directories on the origin server. Even though the content is located in more than one directory, the replication of duplicate content will consume excess space on the edge serving accelerators. Web portals and intranet sites that reuse a common content item should all reference the object from a single location. By consolidating the URLs to a common single object, the CDN will distribute the object only once. For users that do not access the CDN, their local browser will benefit from an object that resides in the browser’s local cache, and services subsequent page’s matches.

Third, consider applying application-based compression to the objects at the origin server. Methods such as gzip allow the origin server to apply compression to objects before they are served to requesting clients or content acquiring accelerator s. This method applies to all types of content served from the origin server. Web browsers natively support decompression of gzip compressed content. Content such as Microsoft PowerPoint presentations can become excessively large when high-resolution graphics are inserted. Presentation applications support the ability to apply compression to the images that reside within the presentation itself. Oversized images and embedded objects create excessively large files that will consume the same amount of space on edge serving accelerators. Application-based compression reduces the size of the content by as much as 75 percent.

The three common encoding formats used within the enterprise today include

Each encoding format supports multiple rates. Table 5-3 illustrates the calculated size of a given piece of content encoded in the MPEG 1 format; calculations are based on common time lengths of an encoding session. Common encoding rates for MPEG 1 are shown for reference

Table 5-4 illustrates the calculated size of a given piece of content encoded in the MPEG 2 format; calculations are based on common time lengths of an encoding session. Common encoding rates for MPEG 2 are shown for reference.

Table 5-5 illustrates the calculated size of a given piece of content encoded in the MPEG 4 format; calculations are based on common time lengths of an encoding session. For MPEG 4, it is important to note that not all MPEG 4 content is created equally, with each content encoder using a different compression technique. Common encoding rates for MPEG 4 are shown for reference. MPEG 4 is the most common encoding format within the enterprise today, because nearly all employee computers’ operating systems will include a media player that supports RTSP streaming, and the MPEG 4 format.

Table 5-6 shows calculated content delivery times for four common content object sizes and eight common WAN connection throughput rates. The table provides reference timings based on availability of exactly the bandwidth rating shown. However, a WAN link rated at 1.5 Mbps (T1) typically does not allow the entire 1.5 Mbps to be consumed for the distribution process. The emphasis within the following chart focuses on fractional rates below the T1 throughput rating, representing smaller throughput ratings which the content distribution session will be allowed to consume.