WO2012152771A2

WO2012152771A2 - Content server of a service provider's cdn

Info

Publication number: WO2012152771A2
Application number: PCT/EP2012/058402
Authority: WO
Inventors: Parminder Chhabra; Armando Antonio GARCÍA MENDOZA; Pablo RODRÍGUEZ RODRÍGUEZ
Original assignee: Telefonica, S.A
Priority date: 2011-05-12
Filing date: 2012-05-07
Publication date: 2012-11-15
Also published as: WO2012152771A3; AR091292A1

Abstract

The content server comprises means for communicating with the different entities of the CDN, means for serving content to the CDN end users and further, comprises a DNS module for participating in DNS resolution of end user requests. For some embodiments, the content server further comprises means for behaving as an origin server and for implementing different content server capabilities, and a FLV streamer module for serving live flash content. The content server preferably uses the meta-data of the bucket and of the files in the bucket as a guidance to serve content to a requesting end user.

Description

Content server of a service provider's CDN

Field of the art

The present invention generally relates to a content server of a service provider's CDN, and more particularly to a content server comprising a DNS module for participating in DNS resolution.

Prior State of the Art

The primary function of an end point is to serve content. End points (also referred to as content servers) are designed with the following features in mind:

• Serving a requested content stream. The stream may be throttled to ensure that multiple requests are served by the end point ensuring fairness to requesting end users (each stream may be assigned a pre-defined maximum bandwidth).

• Pre-fetching the content (especially for popular content) from a CDN customer. · Ability to manage all content servers from a central location.

• Any change in a customer's original content is reflected at the end point(s) as soon as possible in the CDN.

• Akamai uses DNS to identify the edge location closest to the requesting end user and then uses consistent hashing to identify the end point (or cache) that is best positioned to serve the content request. Similar techniques have been used for identifying web caches that can best serve the content [3].

• Since most content requests have to be routed within a CDN either via DNS or HTTP redirection, the geo-blocking based on end user request may be performed before the request gets to content servers (end points).

The above are some of the common features in an end point of a CDN service.

In addition, if an end point is peer-to-peer based as in BitTorrent protocol and Rawflow's p2p streaming technology, it has a few additional features:

• The end point first downloads a torrent file that contains information about pieces of the file and the address of the tracker that has information about other peers that have the same file.

• The end point has a neighbourhood manager that keeps track of the peers in its neighbourhood that have the same content. These are peers (other end points) with whom the end point exchanges pieces of the file that it downloads. However, there is no hard rule that these end points may be geographically close or even be in the same network. Recent work in this area [1] attempts to find peers within the same ISP network to reduce transit costs for the ISP.

• An end point downloads content from no more than a fixed number of peers (four in the case of BitTorrent protocol) at the same time.

· The end point preferentially looks for fast peers from whom it can download pieces of the file allowing it download the content file in the shortest possible time.

• In a purely bittorrent client, for video on demand (VoD), the pieces of file are downloaded in random order.

· In bittorrent, peers are penalized if they only download content (i.e., if they behave only as leechers). The bittorrent protocol requires that peers upload files in order to be able to download content at a good rate.

Problems with existing solutions:

From publicly available information, the design of content servers for most

CDNs is inferred as follows:

• If a CDN customer's data is stored at a content server, all of the customer's data is stored in a folder at the content server.

• In P2P based CDNs, such as Rawflow and Octoshape, the end users are required to download the P2P CDN client software. In a CDN based on P2P, the content servers are peers and share data with one another in a P2P fashion. The requesting end users are also treated as peers and share content with one another opportunistically. In P2P based CDNs, the requesting end users first contact a server that serves as an initial contact point. The contact server then helps the end users connect to the content servers that serve the content stream. In parallel, the software at the end users will attempt to connect to other end users to get a portion of the content stream. Expecting end users to download a software application / plugins to be part of the P2P CDN makes such CDNs a poor design choice.

Content servers in other CDNs are very limited in the number and type of tasks they perform besides serving content. They are largely treated as streamers for delivering content of various types. Description of the Invention It is necessary to offer an alternative to the state of the art that covers the gaps found therein, particularly those related to the reduced number and types of tasks or applications that known content servers (or end points) can perform.

To that end, the present invention provides a content server of a service provider's CDN, comprising means for communicating with the different entities of said CDN and means for serving content to the end users.

The content server of the invention, in a characteristic manner, further comprises a DNS module for participating in DNS resolution of a content request.

Said DNS module, for a preferred embodiment, acts as a HTTP re-director as part of the DNS resolution for a user content request. As part of DNS resolution, the end point also engages in identification of PID of the request, and performs consistent hash on the content request.

For other embodiments of the invention, the content server comprises means for behaving as an origin server and/or for implementing different content server capabilities and/or comprises a FLV streamer module for serving live flash content.

In the present description the terms content server and end point will be used without distinction to designate the invention.

Other embodiments of the content server of the invention are described according to appended claims 2 to 21 , and in a subsequent section related to the detailed description of several embodiments.

The content server of the present invention is not subject to the above mentioned hard requirements on how much of a customer's content is stored in a folder. A customer may create as many folders as they like and may associate as much content with each folder as they desire.

The content server of the present invention works in P2P fashion when possible and uses direct download from origin server when necessary. End users are never treated as peers for P2P communication.

The content server of the present invention supports the tracker in the coordination between the various entities of the service provider's CDN.

The key purpose of end points is to serve content. In addition to the primary purpose of serving content, the content server of the invention can be used for a variety of other applications, according to several embodiments:

It acts as a HTTP re-director as part of the DNS resolution for a user content request. This allows the CDN to scale with the number of end points since traffic is distributed across all the end points (for content delivery as well as for DNS resolution).

Performs consistent hash of the URL of the request with a goal of finding the originating region of the end user request. The HTTP re-direction message returns the URL that contains the region information to which the end user must send the subsequent request.

Only the content servers may exchange data in a P2P fashion. The end users who request content from the customers of the CDN service provider are not treated as peers for exchanging content.

o A neighbourhood manager at each end point maintains a list of its neighbours in the same datacenter to aid its neighbours in exchanging content in a P2P manner when possible.

o The neighbourhood manager at each end point also communicates with other neighbours in a staggered manner so as to avoid all neighbours attempting to communicate with one another at the same time. This is important since the end points notify their neighbours once they download a new file.

End points help support different policies for the CDN service provider by enabling different capabilities at the end point in support for such policies.

Content servers may be assigned a variety of capabilities on the fly. These capabilities may be assigned by the tracker in response to implementing a policy in a service provider's CDN. E.g. End points may be reserved for delivering only rtmp or rtsp content, or they may serve only live content, or they may serve both live and VoD content or end points may serve multi- bitrate content.

As geo-blockers. An end point pulls the geo-IP database from the tracker. Prior to serving content, the end point checks to see if the IP address of the requesting end user may be served based on the meta-data of the requested content.

The end points are designed to be self-healing and manage storage automatically. End points participate in authentication, authorization and accounting with the content owner's server. The authentication mechanism may be specified by the content owner at the time the bucket is created and content is uploaded into the bucket.

- The end point has an flv streamer that uses a unique algorithm to serve live flash content. The algorithm uses neighbours in the same datacenter to share (and thus construct) the live stream at each end point participating in live streaming.

Depending on the embodiment, the end point of the invention may be embedded or server based. The end point of the invention is preferably designed to be very lightweight allowing it to be embedded in set-top boxes or servers when needed or in servers when required.

A method for operating a content server at a service provider's CDN comprises using the content server of the invention for handling live flash content, including its delivery to and its receipt from other neighbouring content servers, by performing the following steps:

- The live signal received in the CDN infrastructure is first split into segments at the live splitter, each of duration (say) 5s. Two types of files are created: an hdr file and a hdx file; where said hdr file is a header file that contains properties of the live stream and said hdx file implements a circular buffer that contains a specially designed URLs that signify the segments of the live-stream. The circular buffer can hold 12 URLs with a combined duration of one minute;

- The live splitter receiving the live stream serves as an origin server for live streams;

- The end point requests the live stream from the live splitter in response to an end user request;

- The download manager module at the end point downloads both hdr and hdx files for the FLV streamer module;

- The FLV streamer module receives an updated hdx file with updated URLs via the download manager module from the origin server periodically (every 30 seconds);

- The content server receiving the hdx file downloads the segments listed in the hdx file from the origin server and other content servers in the same datacenter.

- The local content server communicates the existence of newly obtained segments listed in the hdx files via the neighbourhood manager module to neighbouring content servers, thus allowing the neighbouring content servers to request the same segments from the content server instead of downloading them from the origin server;

- the download manager module, first checks if the content segments of the requested files are available in the local disk of the content server and if they are not available in the local disks:

- checking with the neighbourhood manager module to see which of neighbourhood content servers have the segments whose URLs are listed in the hdx files, and:

- if the segments are available in one or more of said neighbour content servers, getting said segment files from any one of the neighbouring content servers, and delivering them to said end user;

- if they are not available in any of said neighbour content servers, getting said segments listed in the hdx file from the origin server, and delivering them to said end user.

Brief Description of the Drawings

The previous and other advantages and features will be more fully understood from the following detailed description of embodiments, with reference to the attached drawings, which must be considered in an illustrative and non-limiting manner, in which:

Figure 1 shows some of the key features of the end point design of the invention, for an embodiment.

Figure 2 shows all the interfaces of the CDN end point of the invention, for an embodiment, where the tracker aids the end points in synchronizing information with other elements of the service provider's CDN.

Figure 3 shows the different modules included in each of the three layers of the end point of the invention, for an embodiment.

Figure 4 shows three end points according to the invention, connected to a CDN manager through a tracker that is responsible for transferring the capabilities to the CDN end points once the policy and capability parameters are set at the CDN manager.

Figure 5 shows a message exchanges in origin server authentication between an end user, the end point of the invention and an origin server, according to an embodiment. Figure 6 shows another embodiment where the end point of the invention is involved in messages exchanged at a high level in a Fast Authentication protocol between an end user and a CDN Customer's AAA server. Detailed Description of Several Embodiments

In this section, the design and features of the end point of the invention are described, for several embodiments.

As Figure 1 shows, the content server of the invention comprises, for the embodiment there illustrated, the next four main functional blocks:

- a DNS resolution block for participating in DNS resolution;

a capabilities block for implementing different content server capabilities; an Origin Server block for behaving as an origin server; and

a Streamer block for serving live flash content.

The end point of the invention has a number of subsystems that handle everything from serving content streams to providing geo-blocking support. An end point also has Storage manager, Download manager, Neighbourhood manager, and Stream Server. The roles of each of these sub-systems, their design and interactions with each other are discussed next.

End Point Interfaces:

The interfaces of an end point and its communication with other elements of the

CDN is detailed in this section.

The end point maintains communication with the tracker and the log server. As Figure 2 shows, the tracker plays a very important role in synchronizing the end points with changes in cost-matrix at topology server, region information from TLD DNS server and file and bucket level meta-data changes at the CDN manager.

- Communication with the Tracker:

All three tables, geodb, regiondb and pidlocdb are periodically sent to the end points as binary files. The tracker gets the regiondb from the DNS server, pidlocdb from the topology server, and the latest copy of the geodb from the content manager.

The end point gets a list of all buckets from the tracker. Since the tracker synchronizes with the CDN Manager and end points synchronize with the tracker frequently, any change in meta-data of buckets is reflected at the end points fairly quickly. The tracker also gets a copy of the geodb database from the CDN manager. The end points get a copy of this database from the tracker.

Tracker and end points:

• allbuckets: This is called to get information about buckets. No information is returned if the buckets have not changed since last request (i.e. no new bucket was created and there was no change in meta-data of any bucket).

end points -> tracker: HTTP GET request

tracker -> end points: HTTP response

· updateNodeStats: Called periodically by end points to report node level statistics (via HTTP POST). In return, a list of active neighbours is piggybacked to the end point.

end points -> tracker: HTTP POST

tracker -> end points: HTTP response to POST and list of active neighbours of the end point serving the statistics.

• updateRegionsdb: Called to get the latest Regiondb. Only new updates are sent rather than the entire database. Every time a new region is created / removed by OBs, the regiondb table is updated. Since end points help resolve DNS requests, the latest regiondb table needs to be propagated to the end points as soon as a new region is created. end points -> Tracker: HTTP GET request

Tracker -> end points: HTTP response with a copy of the regiondb.

• pidlocdb: Called by an end point to return the PID & IP prefix / mask associated with each region in an OB.

end points -> Tracker: HTTP GET request

Tracker -> end points: HTTP response with a copy of the pidlocdb.

• geodb: Called by an end point to get the latest geodb. This is called infrequently (perhaps once a day) since the geolocation database does not change frequently.

end points -> Tracker: HTTP GET request Tracker -> end points: HTTP response with a copy of geodb.

The tracker first synchronizes with all the elements in the CDN eco-system. Subsequently, the end points in the CDN synchronize with the tracker so that they have the latest information to serve content.

Communication with the Log Server:

The log manager periodically sends log files generated at the end point to the log server. The log files contain information at the file level (number of bytes transferred). This information is useful at maintaining file level statistics of the content and for accounting.

End point and log server:

• updateFileStats: This is called to push log files to the log server. Every end point makes this call periodically.

end points -> log server: HTTP POST

The log server collects all the file level statistics from the end points to display current CDN status. This information is also useful for billing and accounting.

End Point Configuration:

The end point configuration file has two primary components. The first component is a set of parameters that configure the end point and enable them to join the CDN infrastructure of the service provider as CDN elements that serve content. The second component comprises a set of parameters that enable content distribution at the end point. When an end point comes up, it reads this configuration file as part of its initialization. Any change in configuration parameters of the end point will take effect at the end point immediately.

- Configuring an end point:

Several parameters are used to configure an end point. These parameters enable an end point to join the CDN of the service provider and serve content. The parameters are:

· trackerUrl - IP address of the tracker • tokenld - public token ID authorized for an end point's IP address. The tracker uses its private key and the IP address of the end point to generate this token.

• logServer - address of the log server

· httpLogDir - Directory where the local log files are stored

• trackerUpdatePeriod - Frequency in seconds with which the end point sends node level statistics (also referred to as NodeStats) to the tracker.

• siteMonitorUpdatePeriod - For managed buckets, it indicates how often the end point polls the content buckets. This determines how quickly any change in a bucket meta-data is passed to the end point.

- Configuring for content distribution:

A number of parameters are geared towards enabling and controlling content distribution at the end point. These are:

• loglevel - This parameter keeps varying levels of logging information at an endpoint: error, warning and info.

• storagemaxspace - This is the maximum storage space in bytes at the end point.

• storageexpirethreshold - This parameter defines the number of seconds after which a file not accessed will be deleted from the end point.

· storagehighthreshold - The disk cleanup operation is launched when the disk space used reaches this percentage of storagemaxspace.

• storagelowthreshold - The disk cleanup operation is stopped when the used disk space falls to this percentage of storagemaxspace.

• storagecheckperiod - Indicates how often it is checked the storage for expired files and to free up space.

• trackerdebug - This field defines whether or not the information received from the tracker should be used for debugging.

• outboundbandwidthlimit - Indicates the maximum outbound bitrate supported by this instance (in KBytes/s). • inboundbandwidthlimit - Indicates the maximum inbound bitrate supported by this instance (in KBytes/s).

• connectioncountlimit - This is the maximum number of simultaneous connections allowed.

· capability - This field indicates the capability of the end point (capability refers to protocols supported as well as whether the end point supports live streaming or VoD).

So, the five parameters storagemaxspace, storageexpirethreshold, storagehighthreshold, storagelowthreshold, storagecheckperiod are used together to manage storage at each end point.

The parameters outboundbandwidthlimit, inboundbandwidthlimit and connectioncountlimit are used by the end point to infer the network level health of the end point.

In addition, the end point also supports any parameters needed to run the consistent hash ring [3].

Individual Modules:

The end point design has three primary layers: the low level core, the network layer and the CDN layer. Figure 3 shows the three primary layers and modules in each of the three layers.

At the core level, a number of modules are defined that provide services to both network and CDN layer. The dispatcher provides a mechanism for managing a queue of work items. The logger provides a common method for logging across all modules in all layers of the end point. Other core services include methods for opening and closing files, reading and writing to a buffer etc.

The network layer defines modules for communicating with other entities in the

CDN eco-system. Since the end points participate in DNS resolution process, the invention has a DNS module, a TCP and HTTP module to manage network connections. This layer also has a throttling module that provides per-connection throttling when serving content to the end users. This is useful since every piece of content comes with a maximum download rate as specified by the content owner. The throttling module ensures that the CDN end point does indeed respect the contract.

The end point has a number of modules at the CDN layer. These modules are responsible both interaction between various modules within the same end point, interaction between different elements of the CDN infrastructure and communication between and end point and the requesting end user. These modules are the bucket manager, storage manager, neighbourhood manager, downloader, geo-blocker, tracker connector, flv streamer and HTTP streamer (really a stream server). These modules are described in more detail since they form the core of this document, namely the architecture and functioning of the end point.

- Bucket Manager:

This module keeps track of all the buckets to manage in an end point. The bucket manager will fire off events on receiving a new bucket snapshot from the tracker so that appropriate actions regarding changes in the bucket are taken. If the meta-data of file(s) in a bucket have changed, or a new bucket is added, this entity uses the downloader to update content or add content if content pre-positioning is requested. If a bucket is disabled (or deleted), the files within the bucket are disabled (or deleted) as well. Similarly, if a bucket is enabled, all files within the same bucket are ready for distribution to requesting end users.

- Storage Manager:

When a file is downloaded to the disk at the end point, it is downloaded one block at a time. Before it is stored, the integrity of the downloaded block is checked. Once the integrity check is successful, the block is stored to the disk.

The Storage manager maintains statistical information for all files in a bucket in a

CDN. It maintains statistics about the number of bytes of each file transferred in each bucket and disk usage statistics. The storage manager retrieves the file handle for a stored file that can be used by sendfile to serve the file to a requesting end user. The storage manager is also responsible for performing self-management of storage at end points by deleting files that are not in use. The storage manager can also retrieve any file and bucket level information at an end point.

- Neighbourhood Manager:

The neighbourhood manager at an end point keeps a list of all its neighbours that are in the same datacenter. The tracker provides the list of neighbourhood IP addresses to an end point. The neighbourhood manager keeps track of all neighbours that may have a certain file. On receiving a new file, the neighbourhood manager pushes this information to its neighbours using rpc process (either using HTTP POST, or message passing or signalling). This has two consequences: If the content is available at an end point in the same datacenter, another end point that needs the same content can get the content from the same datacenter (rather than relying on the origin server). This results in reduced load at the origin server.

When an end point updates its node statistics information to the tracker, the tracker acknowledges the receipt of the node statistics and also sends a list of neighbourhood IP addresses to the end point. Since an end point sends its statistics to the tracker periodically, it gets an updated list of its active neighbours very frequently.

When an end point receives a list of neighbours, it waits for time duration between [0-10] seconds before opening a connection to its neighbours. This allows for the neighbours to connect first. It also avoids two neighbours connecting to one another simultaneously, thus avoiding duplication of effort. Thus, the end points in the same datacenter maintain an open connection with one another allowing for the neighbourhood managers to exchange content information with one another quickly. - Downloader:

This module at the end point is responsible for all access to the Internet (be it to the neighbourhood nodes or the origin server) to get files from the neighbourhood nodes or the origin server.

Any time a file is requested, the downloader first looks for the file in the local disk by querying the storage manager. If the file is not available locally, the downloader queries the neighbourhood manager. If none of the neighbours have the requested file, the request reverts to the downloader. The downloader then gets the requested file from the origin server. The algorithm may be described as follows:

On request for a file,

if requested file is available locally,

Call sendfile and transmit file to the requesting end else if neighbours (in the same datacenter) have the file

/* This is the call to the neighbourhood manager */

Get the file from the neighbour (s)

Send file to the end user

else

Get the file from the origin server Send file to the end user

The origin server always contains a master copy of the content. The downloader can always get the copy of content from the origin server if all else fails.

The downloader does admission control at the end point. It uses the following algorithm:

On request for a file,

If request for the same file from another end user is outstanding,

Place the request in a queue

/* This avoids the origin server to be hit with multiple requests for the same file from the same end point */

Once the content is available at the disk,

Serve the end user that made the first request for the content .

Empty the waiting queue and serve the remaining waiting end users .

However, care is taken to ensure that the end point does not attempt to serve more connections than the available bandwidth since each end user needs to be served content at no more than the maximum rate (as specified by the content owner in the file / bucket meta-data).

- Geo-Blocker:

This module is responsible for ensuring that the content is shown only for the duration and in those geographic areas that the content owner/content provider desires. For a request arriving from a DNS server authoritative in a sub-zone, the end point identifies the country of origin of the ISP DNS resolver. If the end point deems that requested content must not be shown in the country of origin of the request (based on the meta-data of the content bucket or file), it returns an error message to the requesting end user. - Tracker Connection:

All end points keep an open connection to a tracker. The tracker really acts as a load balancer. The tracker collects statistics from all end points. In order to do this, the tracker polls end points for node statistics about every 30s. Each end point posts both the usage statistics (CPU usage, connection count, disk usage) and the file statistics (outbound bytes, file name) to the tracker.

- HTTP Streamer (Stream Server):

Once content is available on the disk, the stream server is responsible for serving content to the end users. It does so using HTTP/1.1 downloads.

If multiple end users are queued up at the downloader, the stream server is responsible for opening the connection and serving content to all the requesting end users. The number of end users a stream server can serve is limited only by the bandwidth.

- FLV Streamer:

The FLV Streamer is designed to specially handle the flash files. A separate system in the CDN infrastructure, the live splitter, acts as the origin server for a live stream. The live splitter is designed to split a given live FLV signal into segments, each of a specified duration, say 5 seconds. As part of this process, two files are created, hdr and hdx.

The hdr file is a header file and contains file properties like resolution, bit-rate, expiry time etc. All live content expires quickly. The hdx file is really a circular buffer that contains specially designed URL that signifies live-streaming.

The FLV Streamer uses the downloader in a special way. The downloader first downloads both the hdr and the hdx files. The flv streamer uses the downloader to get files in the hdx.

Once an end point downloads a file, the existence of the new file is conveyed to all the neighbours via the neighbourhood manager. Each neighbour now knows the existence of a new file at a given end point. So, not all neighbours go to the origin server to download all files in the hdx. With a random delay of [0-2] seconds, each of the neighbours makes a request of each file in the hdx.

The downloader first checks if requested file is available in the local disks. If it is not available in the local disk, it checks with the neighbourhood manager to see from which neighbour to get the data. Only as a last resort does the downloader get the data from the origin server. If there are a large number of neighbours, by introducing the random delay, this scheme allows for neighbours to get the files listed in the hdx largely from one another without all end points overwhelming the origin server. The values of segment size and random delay interval are used for illustration purpose. These values in no way restrict the scope of the invention.

- Consistent Hashing Support at the End Point:

Consistent hashing provides hash table functionality in a way that addition or removal of an end point does not significantly change the mapping of content to end points. Consistent hashing is a very scalable way of distributing changing quantity of content to a changing population of end points. The requests received may then be distributed among the end points.

The end point serves as a redirector for a client request. As part of this redirection, the end point needs to identify the partition id that may best serve the content. This identification is performed using consistent hashing at the end points. The redirection helps an end point identify another end point in the same region as the requesting end user. Subsequently, the tracker uses the end point statistics to determine the least loaded end point that is best positioned to serve the end user. End Point Capabilities:

Every end point has associated with it, a bit field that identifies the supported content formats for both live streaming and VoD. Any change in the capabilities field affects the kind of content that an end point may serve.

- Assigning capability:

Capabilities of an end point may be changed on the fly. End points may support a variety of video formats and may support either VoD or live streaming or both. A CDN service provider may want to dimension the CDN end points to implement different policies.

In order to support the tracker policies, the end point in the CDN supports various capabilities. These capabilities are part of the configuration file for content distribution by the end point.

CAPABILITIES FORMAT: It is a bit mask indicating in each bit the supported type of service (1 : supported). The format is as follows:

bit 0 HTTP native

bit 1 RTMP native

bit 2 RTMP bit 3 Smooth Streaming

bit 4 I phone Streaming

bit 5 RTSP

bit 6 VoD (Video on Demand)

bit 7 Live Streaming

bit 8 Redirect (CDN Control bit)

Consequently, valid capabilities format ranges from 0 to 51 1.

- End Point Policies:

Policies supported by the tracker for CDN's customers are implemented at the end point.

The tracker is required to support policies of the CDN service provider as shown in Figure 4. Examples of such policies are: reserving end points for live streaming only, exclusively reserving an end point for a customer, reserving some end points to serve content from some buckets alone.

Managing Storage at End Points:

A Storage Manager runs at the end points. The storage manager is responsible for maintaining all the low-level file information in a bucket (including information at the block level for files being sent and received). The Storage Manager is also responsible for managing total disk space consumed at an end point and performs cleanup as needed. As a result, storage at an end point is self-managed. As part of this, the following four features were implemented. The primary purpose of these features is to ensure content integrity and availability of disk space when needed at the end points.

- Ensuring zero reference to a file before deletion:

An end point has finite storage. The end point ensures that if an end user is downloading or viewing a content file, the same file is not removed from the hard disk of the end point. This is accomplished by maintaining a reference count parameter for every file in every bucket. The same reference count is incremented when an end user starts downloading a content file. The reference count is decremented once the end point has finished downloading the entire file. In the event that a file needs to be removed from the hard disk, the method that removes the file ensures that the reference counter is zero before attempting to remove the file from the disk.

If a file is identified for deletion

If reference count for the file is not zero

Wait for the reference count to go to zero (wait for the end user(s) to finish downloading the content)

Delete the file in the bucket

The algorithm for deleting a file after ensuring zero reference is described above. - Ensuring integrity of downloaded content:

Files that belong to a managed bucket are downloaded at the end point from the origin server. These files may be arbitrarily large. However, the entire file is not downloaded by the end point before checking for content integrity. To ensure content integrity, while the file is being downloaded, the SHA1 values of 1 MB blocks are calculated at the end point. These SHA1 values are compared against the meta-data SHA1 values of each of the individual 1 MB blocks. If an error is discovered, the blocks are requested again.

- Auto-cleanup of disk:

An end point receiving a continuous stream of requests implies that either the content is in the disk / cache and can be served with minimal delay or it would have to be gotten from the Origin server / other end point(s). Left unchecked, it will not be long before the disk is full. The storage manager ensures that there is always sufficient storage for new requests to be served.

End points define two parameters storageFreeUpHighThreshold for maximum threshold and storageFreeUpLowThreshold for a minimal threshold in the end point configuration file. If an end point reaches 90% (say, maximum threshold) of its storage capacity, it initiates an auto-cleanup that removes files from disk using the LRU policy. The process of removing files from the disk continues until the disk is only 70% (say, the minimum threshold) full. This process of removing files automatically in the face of storage crunch by the storage manager at the disk allows to the end points to be self- managed.

If currentStorageUsed > storageFreeUpHighThreshold Do until currentStorageUsed < storageFreeUpLowThreshold {

Identify the least recently used file among all files and buckets.

Delete the identified file.

- Auto disabling of buckets and files:

All buckets have a special meta-data parameter that allows the CDN customer to specify if a bucket can be disabled on a certain date and content removed from the bucket. The bucket level parameter can be overwritten at the file level. This allows for easy auto-cleanup of buckets at end points.

Downloading Content:

The end point gets content from either the origin server or other end point(s). If the content is received from another end point (peer in the same datacenter), the content is received from a single peer.

In this document, the Peer-to-Peer (P2P) communication between two end points in the same datacenter refers to single source download. The complexity of multi-source download within the same datacenter is not needed since the datacenters are well dimensioned and the content transfer is over a LAN, guaranteeing a higher bandwidth download when compared to a download over a WAN. Two end points in the same datacenter are referred to as peers and downloads between them as peer-to- peer or P2P downloads.

Authentication, Authorization and Accounting Support:

End points in the service provider's CDN provide a variety of techniques to enable content owners protect their content from unauthorized access.

There are three main authentication schemes: token-based / URL-based and Fast authentication.

- Token / URL Based Authentication:

The token / URL authentication methods rely on using a token as a secret key to authenticate end user access or use a combination of token and cookie as URL to authenticate the content request between the end point and the content owner. The token-based authentication mechanism is used to grant access to content based on a signed request. It is defined by bucket meta-data parameters. Here, the token is sent as part of the request.

In URL authentication, end user credentials (in the form of IP address and cookie parameters) are used to authenticate the end user with a content owner's Authentication, Authorization and Accounting (AAA) server.

The URL and token authentication / authorization schemes are designed with the following scenarios in mind:

• Forbid a URL to be used from more than one IP address.

· Restrict number of simultaneous downloads from an IP address.

• Forbid reuse of URLs. URLs are invalid once the content is downloaded.

• Disallow the use of a URL after a period of time.

• Stop serving content to certain IPs based on download quotas.

• Stop serving video after expiration of certain time (content has been viewed for certain duration).

• Provide a mechanism for cookie pass-through for some customers.

- Support for Origin server Authentication:

Figure 5 shows the messages exchanged (at a high level) for Basic and Digest authentication mechanisms. In both authentication mechanisms, the end point authenticates pre-defined credentials (as part of bucket meta-data) to the origin severs.

As seen in the figure, the credentials are sent from the end point to the origin server. Once authenticated, the end point serves the content to the requesting end user. To aid accounting and billing at the content owner, the end point also has the ability to send the necessary information (in the form of bytes transferred) to the AAA server at the content owner.

- Fast Authentication protocol support:

The fast authentication protocol support is designed to allow the content owner to define any authentication token they desire to use (token may be per content file), and perform fast authentication and authorization and provide real-time accounting.

Figure 6 shows the communication between the end user and the authentication server supporting fast-authentication. In order to support this protocol, the CDN customer provides the IP address and port number of AAA server with whom the end point communicates.

As it is shown in Figure 5, when an end point gets a content request, it takes the credentials from the request and sends it to the CDN customer's AAA server. Once authorized, the CDN end point will start serving the requested content. Once the end point finishes serving a file, it will send the accounting information (bytes transferred) to the CDN customer's AAA server. During the content transfer, the end point updates accounting information periodically (about once a minute) to allow the AAA server to make useful decisions.

Security at End Points:

As in any CDN, the end points of the service provider's CDN may be the target of a variety of Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks.

Since each end point participates in the DNS resolution for the CDN, the load for the DNS resolution is distributed among all of the end points resulting in a distribution of load in resolving a content request.

Each end point has a list of all files and buckets from the origin server. This list is kept up to date. This ensures that frivolous requests for content files are rejected by the end point right away.

On receiving a content request

Check if content URL bucket and file exists

If file exists, perform a Consistent Hash of the function return HTTP redirect to the requesting end user else

return an error (invalid request) to the requesting end user

When an end point receives a DNS resolution request, it may result in an HTTP redirect either to a different region within the same OB or a HTTP redirection to a different OB. Regardless, the end point performs a consistent hash on the URL of the content.

The end points are a very key part of the CDN infrastructure and like any other entity, may be subject to a Denial of Service. A particularly malicious attack may occur if an end user requests content that does not exist. An end user could either infer IP addresses of the end points or could merely send file download requests to the CDN.

The end points get a copy of the files. xml from the Origin Server that contains a list of all the managed buckets in the CDN infrastructure. The frequency with which the end point gets the files. xml file is determined by the sitemonitorupdateperiod parameter of the configuration file at the end point.

The end points aid the CDN infrastructure in DNS resolution. The end points send a HTTP 302 Redirect message to the end user to help localize a datacenter that is best positioned to serve the requested content. Before it does this, it checks to see if the requested file is part of managed buckets (i.e., the content file exists in files. xml). If it is not, the end point returns an error (HTTP 404) to the requesting end user. Since the request load for DNS resolutions is shared by end points in the CDN infrastructure, this scheme ensures that no single end point will be overwhelmed. By catching frivolous requests early, the CDN infrastructure can be protected. Advantages of the Invention:

The end point of the invention is designed to be more than just a content server. It is designed to be a key part of the CDN infrastructure that participates in signalling and helps the infrastructure scale by acting as a load-balancer for processing incoming DNS requests. Some of its advantages are mentioned next:

• Two end points (or nodes) in the same datacenter use P2P communication to exchange data. This P2P communication is single source. When one node in a datacenter receives a new file, it broadcasts information to other nodes in its neighbourhood announcing the availability of the file. So, if the neighbours in a datacenter need the file, they first check with other nodes in the same datacenter. If the neighbouring nodes have the file, the file replication proceeds via single source P2P communication. This reduces load at the origin server.

• The end point maintains a list of all files in the origin server of an OB. This allows them to guard against frivolous requests arriving directly at the end points.

• In order to support the tracker policies, an end point in the CDN infrastructure supports various capabilities. The capabilities determine the type of requests (and hence the buckets that will be mapped to the end points) served by the end point. The end point software may be embedded in set-top boxes or Wi-Fi routers or run on server hosts when required.

The end points may communicate with set-top boxes and deliver VoD or live stream content in response to an end user request.

Any change in meta-data of a CDN customer's content is reflected at the end points within seconds. The end point is able to adjust to new content distribution requirements on the fly.

o A live stream originally configured for distribution in Spain may be streamed in Brazil with a simple API call at the entry point. Similarly, a CDN customer (and content owner) can enable multi- bitrate on a piece of content via a simple API call.

All end points participate in the DNS resolution process. This allows for a nice distributed architecture that allows the CDN to scale with the number of end points.

End points are administered via a tracker and may be brought down or brought up via API calls at the tracker.

End points are assigned capabilities. A tracker may assign content (via buckets) to end points that have the necessary capabilities. For example, a live bucket may be associated with an end point only if it has the 'Live' bit enabled in its capabilities field.

An end point uses P2P to download a requested content file when possible (if an end point in the same datacenter has the same content). The end point downloads the file from the origin server when necessary. Only end points in the same datacenter act as peers and participate in P2P communication. The end users are not treated as peers for exchanging data.

An end point is not bounded by a fixed number of neighbours to share content in a P2P manner. Since the number of end points in a datacentre is bounded, the maximum numbers of such neighbours that are free to share this content are also bounded.

Ability to assign a whitelist and blacklist of IP addresses to each bucket (or file within each bucket). The CDN customer who uploads the content makes this assignment. This gives additional control over content to the content owner. Whenever any node receives a new file, the information about the file is conveyed to all the neighbours. However, every node does not contact its neighbours all at once. Instead, by waiting anywhere between [0-10]s, it gives its neighbours a chance to talk to it first. This avoids all neighbours attempting to talk to one another all at once.

The FLV streamer at the end point that serves real-time traffic uses a unique algorithm that uses its neighbourhood end points to download content when possible thereby avoiding going to the origin server for every piece of content allowing the live streaming to scale. The advantage of using its neighbours in the same datacenter is that data exchange on the LAN can proceed rapidly. This helps reduce load at the origin server in the OB for the live streaming of flash content.

A person skilled in the art could introduce changes and modifications in t embodiments described without departing from the scope of the invention as it defined in the attached claims.

ACRONYMS

ADSL Asymmetric Digital Subscriber Line

CDN Content Distribution Network

DNS Domain Name Service

DoS Denial of Service (a kind of security attack)

DDoS Distributed Denial of Service Attack (a form of security attack)

PoP Point of Presence

OB Operating Business

TLD Top Level Domain

FTP File Transfer Protocol

HTTP HyperText Transfer Protocol

MD5 Message-Digest algorithm 5

URL Uniform Resource Locator

ISP Internet Service Provider

TTL Time To Live

DSLAM Digital Subscriber Line Access Multiplexer

DHT Distributed Hash Table

PI D Partition Identifier

RPC Remote Procedure Call

LAN Local Area Network

WAN Wide Area Network REFERENCES

[1] P4P: A Portal for Proactive Providers Participating in P2P. At http://cs- www.cs.yale.edu/homes/yong/p4p.html

[2] M. J. Freedman, E. Freudenthal, and D. Mazieres, "Democratizing

Content Publication with Coral." In Proc. NSDI, San Francisco, CA, March 2004.

[3] Karger, D.; Sherman, A.; Berkheimer, A.; Bogstad, B.; Dhanidina, R.;

Iwamoto, K.; Kim, B.; Matkins, L; Yerushalmi, Y. (1999). "Web Caching with Consistent Hashing". Computer Networks 31 (1 1 ): 1203-1213

Claims

'\ - Content server of a service provider's CDN, comprising means for communicating with the different entities of said CDN and means for serving content to the CDN end users, characterised in that it further comprises a DNS module for participating in DNS resolution.

2.- A content server as per claim 1 , comprising three primary layers: a low level core layer, a network layer and a CDN layer, where said network layer contains said DNS module.

3.- A content server as per claim 2, where said DNS module acts as a HTTP re- director as part of the DNS resolution for an end user content request.

4. - A content server as per claim 3, wherein said DNS module performs consistent hash of the URL of the request with a goal of finding the end points in the datacenter that have the requested content and lookup the partition ID database to identify the originating region of the end user request.

5. - A content server as per claim 4 or 5, wherein said DNS module returns a HTTP re-direction message with the URL that contains the correct region to which the end user must send the subsequent request.

6. - A content server as per any of the previous claims, further comprising means for behaving as an origin server and/or for implementing different content server capabilities.

7. - A content server as per claim 1 , comprising three primary layers: a low level core layer, a network layer and a CDN layer, where said CDN layer contains a downloader module with a download manager responsible for all of the content server's access to Internet, to get files from one or more other neighbourhood content servers or from the CDN origin server in the same operating business as said content server.

8. - A content server as per claim 1 or 7, comprising three primary layers: a low level core layer, a network layer and a CDN layer, where said CDN layer contains a neighbourhood module with a neighbourhood manager, where said neighbourhood manager module keeps a list of IP addresses of all its neighbouring content servers in the same datacenter, and uses said list to keep track of content files in its neighbouring content servers, and on receiving a new content file, pushes the information about said newly received file to its neighbouring content servers.

9. - A content server as per claim 8, where said neighbourhood manager module communicates with other neighbouring content servers in a staggered manner so as to avoid the condition that all of the said neighbourhood content servers attempt to communicate with one another simultaneously.

10. - A content server as per claim 1 , comprising three primary layers: a low level core layer, a network layer and a CDN layer, where said CDN layer contains a configuration module responsible for managing said different content server capabilities.

1 1. - A content server as per claim 10, wherein said configuration module reads a configuration file with two primary components:

- a first component formed by a set of parameters that configure the content server and enable it to join the CDN infrastructure of the service provider; and

- a second component comprising a set of parameters that enable content distribution at the content server.

12. - A content server as per claim 1 1 , where said second component of the configuration file comprises a variety of capabilities to be assigned/modified/enabled on the fly in order to support different policies as specified by the CDN service provider and enable different CDN services at the content server.

13. - A content server as per claim 1 1 , where said content server reads said configuration file as part of its initialization, and when a change in the parameters of said configuration file is detected.

14.- A content server as per claim 1 , further comprising a FLV streamer module for serving live flash content.

15. - A content server as per claim 14, comprising three primary layers: a low level core layer, a network layer and a CDN layer, where said CDN layer contains said FLV streamer module for serving live flash content that employs an algorithm that uses neighbours in the same datacenter to share segments of the live stream and later, construct the live stream from segments at each content server participating in live streaming of flash content.

16. - A content server as per claim 15, where said FLV streamer module handles merging of segments of the live stream that are received from the download manager of the downloader module.

17. - Content server as per any of claims 2, 7, 10 or 15, where said CDN layer also has the following modules that enable a variety of services at the content server:

- a bucket manager module,

- a storage manager module,

- a geo-blocker module, - a tracker connection module, and

- an HTTP stream server module.

18. - A content server as per claim 17, where said bucket manager module keeps track of all the buckets managed at the content server, by performing at least one of the following actions:

- firing off events on receiving a new bucket snapshot from the tracker in the same region as the content server so that appropriate actions regarding changes in the bucket can be taken;

- checking if meta-data associated with file(s) in a bucket have changed or if a new bucket is added, and if so updating the information included in said snapshot of bucket meta-data; and

- checking if a bucket is disabled or deleted and if so, disabling and deleting the files within the bucket, and

- checking if a bucket is enabled, and if so, making all files within the bucket ready for distribution to requesting end users.

19. - A content server as per claim 17 or 18, where said geo-blocker module is responsible for ensuring that the content is shown only in those geographic areas as specified in the bucket and file level meta-data that the content creator/content provider desires by geo-blocking a requesting end user from accessing the content, either VoD or live-streaming, based on his IP address.

20. - A content server as per any of the claims 17 to 19, where said tracker connection module is responsible for keeping an open connection to a tracker of the same region as the content server and for posting both system level statistics and file statistics to said tracker to allow the latter to act as a load balancer for all content servers in the region.

21. - A content server as per any of the claims 17 to 20, where said HTTP stream server module is responsible for serving content to the end users once content is available in the disk at the content server and if multiple end users are queued up at the downloader manager module for the same content, the HTTP stream server module in conjunction with the download manager is responsible for opening connections and serving content to all the requesting end users.