CONTENT REQUEST ROUTING METHOD

- Rockstar Consortium US LP

A method of redirecting content requests among content distribution network peers. In operation, a client sends a request for content to a content distribution network (CDN). When this CDN does not currently have the capacity to deliver the content, the CDN refers to one or more content distribution tables to see if the neighbour peers are able to provide this content. The content distribution table is populated at the time of distribution of the content. When the neighbour peer has this content, the request is redirected to the neighbour peer. In redirecting request, an address of the neighbour peer is appending to the previous address such that each peer receiving the request knows where the request came from and where it has been previously.

Skip to: Description  ·  Claims  · Patent History  ·  Patent History
Description
RELATED APPLICATION

This application is a continuation of co-pending U.S. patent application Ser. No. 10/013,677, entitled “Content Request Routing Method,” which was filed on Dec. 13, 2001, and which is hereby incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The present invention relates to content request routing and is particularly concerned with routing between content network peers.

BACKGROUND OF THE INVENTION

A current Internet draft “Known Mechanisms for Content Internetworking” by F. Douglas et al. provides a useful overview of content internetworking. (Nov. 8, 2001) The use of “Intelligent DNS (IDNS) is discussed as a way to handle request redirection.

Content networks play an important role in the overall architecture of the web. In the Internet today several approaches have been proposed for providing infrastructure, at layers 4 through 7, to get content to end users or user agents in a scalable, reliable, and cost-effective fashion. In this regard, various protocols and appliances have been developed for the location, download, and usage tracking of content. Examples of such technologies include: web caching proxies, content management tools, and intelligent web switches.

In general, a content network can be viewed as a virtual content overlay network in the OSI stack. This content overlay layer enables the delivery of richer services that rely on underlying elements from all 7 layers of the stack to subscribers or end users. Content overlay services rely on layer 7 protocols such as HTTP or RTSP for transport.

However, regardless of the size of a content network, its ability to serve clients and subscribers is limited by economic realities and other factors. Hence, in order to increase the scale, reach and performance of content networks, it is possible to interconnect them. Hence, content internetworking is the interconnection of multiple content networks. In the networking field, content internetworking is also known as content distribution internetworking or content peering.

Content internetworking allows different content networks to cooperate to serve content to end users or user agents. This leads to the ability of content networks to share resources so as to provide larger scale and/or reach to each participant than they could otherwise achieve. In order to be able to interconnect content networks, various architectural components must be introduced. In particular, the interconnection of content networks is achieved through the establishment of common internetworking gateway. The gateway must be able to provide mechanisms to distribute content or inject content into the networks and must also be able to direct user requests between them. The task of directing users requests to various surrogates among the inter-networked content networks is also called request routing and it is done in a content router. It is also possible to define various accounting and authorization schemes for financial settlements. In the literature, a content router is also called a request routing system (RRS).

There are various request routing techniques that could be used within a content router to direct users request for content among internet-worked content networks. At a high-level, these may be classified under: DNS request-routing, transport-layer request-routing, and application-layer request-routing. However, regardless of the technique that is used for request routing, there should exist mechanisms within the content router that insures that the task of directing users requests is performed in a loop free manner.

Among the various request routing techniques, the use of DNS based mechanisms has gained popularity due to the ubiquity of DNS as a directory service. In DNS based request-routing techniques, the content router acts as a specialized DNS server that is inserted in the DNS resolution process. The content router is capable of returning a different set of A, NS or CNAME records based on defined policies, network conditions and cost. Such DNS servers have also been called Intelligent DNS servers (IDNS). In general, within IDNS, the use of CNAME redirection techniques is the preferred method of request routing.

Referring to FIG. 1 there is illustrated in a block diagram an internetworking of a plurality of content distribution networks (CDN). In general, an intelligent DNS (IDNS) system uses a DNS server 18, to redirect, typically via the DNS CNAME response, to an IDNS brokering server 20 within a selected CDN, for example CDNB16. The brokering DNS server 20 monitors the load of other CDNs, CDNC 26, and CDNA 30 within abet of predefined “regions” (e.g., individual countries). Using the IP address of the DNS server 14 making a request, the IDNS brokering server 20 maps the DNS server 14 to a region and selects the CDN that serves that region “best” based on various metrics, for example CDNC 26.

The IDNS brokering server 20 uses CNAME or NS redirection to other CDNs, or it can forward the DNS request directly to a CDN that will respond to the request directly (not shown in FIG. 1). For example, a client 12 initially contacts (1) its local DNS server 14, which (2) contacts the IDNS brokering server 20, via a DNS server 18. The IDNS brokering server 20 (3) returns either (A) a CNAME or NS record redirecting to another CDN, e.g. GDNC 26, or (B) an A record for an edge server 22 within CDNB 16. (The latter is called a “triangular resolution”.) Eventually, (4) an IP address is returned to the client 12, which then requests (5) the control from server 28 and receives (6) the actual content.

Request-routing systems (RRS) present a “black-box” view of their associated distribution systems. Since in such an environment no CDN possesses a global view of all other CDNs, the request-routing system has to rely on a peer-to-peer model in which each request-routing system is only aware of its direct neighbor.

There are two known methods for redirecting a request between two interconnected request-routing systems. The first method is an interactive method where a RRS directs the request to the next-hest (neighbor) RRS. This continues until a surrogate is finally selected. The second method is recursive where a RRS directs a request to the next-best RRS but expects an answer to return to the client. These two methods are analogous to recursive vs. iterative DNS lookups.

The interactive approach will either find a CDN that will accept the request or it will return a request failed message. With either result, considerable resources are involved with the messaging that is exchanged in this process.

Referring to FIG. 2 there is illustrated a typical exchange for four content delivery networks. A client 40 makes a request via its local access provider that is routed to RRS 42. The RRS 42 then relays the request to a CDNA 44, who refuses the request. The RRS 42 next relays the request to a CDNB 46, who refuses the request. The RRS 42 next relays the request to a CDNC 48, who accepts the request. RRS 42 then provides the client with the DNS of CDNC 48 via its local access provider.

A second method of request redirection is recursive. Here the RRS redirects a request to the next best RRS, but expects the new RRS to return a reply to the client. Either of these methods will work if there is one level of peering. However, if there are multiple levels of peering, these simple redirection schemes may lead to looping, where the request continues to be past among the CDN peers without converging on a CDN that will accept the request.

SUMMARY OF THE INVENTION

An object of the present invention is to provide an improved content request routing method.

Accordingly, the present invention defines peering levels at distribution of content from a content source then tags each redirection of requests with an identifier of the CDN forwarding the request to a peer. Advantageously, the peers only require knowledge of nearest neighbours.

Conveniently, a content by CDN matrix is populated at the time of distribution.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates in a block diagram a known internetworking of a plurality of content distribution networks;

FIG. 2 illustrates a message exchange for request redirection in the internetworking of FIG. 1;

FIG. 3 illustrates an ordered peering of CDN using a method of request redirection in accordance with an embodiment of the present invention;

FIGS. 4a, 4b, and 4c illustrate content distribution tables for nearest peers in accordance with an embodiment of the present invention; and

FIG. 5 illustrates in a flow chart the method of request redirection in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring to FIG. 3 there is illustrated an ordered peering of content distribution networks (CDN) using a method of redistribution in accordance with an embodiment of the present invention. The ordered peering 50 includes content distribution network (CDN), CDNA 60, CDNB 70, CDNC 80, CDND 90, CDNE 100 ordered in peer levels L1 110 and L2 120. Each CDN is coupled to its nearest peer hence CDNA 60 is coupled via 62 its level 1 peer CDNB 70 and via 64 to its level 2 peer CDND 90. Similarly, CDNB 70 is coupled via 72 to its level 1 peer CDNC 80 and to its level 2 peers CDND 90 and CDNE 100, via 74 and 76, respectively. And CDNC 90 is coupled to a level 2 peer CDNE 100 via 92.

In operation, a client 130 sends a request 132 addressed {www.a.com/α} for content α to CDNA 60. However, CDNA 60 does not currently have the capacity to deliver this content. So it refers to its content distribution table 134 to see if the neighboring peers are able to provide this content. The CDNA 60 sees that it has a level I peer, CDNB 70 that has the α content and forwards the request to CDNB 70 addressed (www.a.b.com/α).

The CDNB 70 is also too busy to handle the request and determines from its distribution table 138 that its level 1 peer CDNC 80 does not have the content α, however its level 2 peer CDND 90 does. In this case, the CDNB 70 forwards the request 140 addressed, www.a.b.d.com/α, to the CDND 90. The CDND 90, is also too busy to handle the request so consults its distribution table 142 and determines that the only two peers having content α are CDNA 60 and CDNB 70, but the address ww.a.b.d.com/α shows that these two peers have already refused the request. At this point CDND 90 returns a network busy request refused message 144 to the client 130.

Referring to FIGS. 4a, 4b, and 4c, there is illustrated the content distribution tables of CDN A, B, and D, respectively of FIG. 3. Each distribution table is populated at the time of distribution of the content. Also at the time of content distribution, peering levels are established. In the present example only two levels, level 1 and level 2, are shown. Also for convenience the content distribution tables show a single table for a plurality of different content. Various implementations of content tables are possible. For example content tables could include all content from a particular content source. Alternatively, a table could exist for each content.

In the example above, the initial CDN peer was CDNA. If the CDN peer had been CDN B, the addressing of the re-routed request would be www.b.nextpeer.com. Hence, the re-routed request has the general form:

    • www.<1stpeer>.<next peer>.<peer of next peer>.com.

Referring to FIG. 5, there is illustrated in a flow chart the request redirection method in accordance with an embodiment of the present invention. The method begins with a decision block 200 asking whether the address CDN has capacity to fill the content request. If YES, a process block 202 sends an affirmation reply to the client and content transfer begins. If NO, a process block 204 reviews a distribution table to determine what peer has the requested content. A decision block 206 determines if a neighbour peer has content α. If no neighbor peer has the content, a refuse request message is sent to the client, as represented by a process block 208. lf a neighbor peer is found to have the content, the request is forwarded, as represented by a process block 210, appending the peers address to the previous address. In this way, each peer receiving the request knows where the request came from, and where it has been previously. This becomes increasingly important as the number of redirections required increases and as the number of peer levels increase.

Claims

1. A method of redirecting content requests among peer content distribution network nodes, the method comprising:

providing, at a first content distribution network node, information identifying content contained on each peer content distribution network node of the first content distribution network node;
receiving, at the first content distribution network node, a content request comprising an identification of requested content;
responsive to a determination that the first content distribution network node will refuse the content request, determining, from the information identifying the content contained on each peer content distribution network node of the first content distribution network node, whether a second content distribution network node is a candidate for providing the requested content; and
when the second content distribution network node is the candidate for providing the requested content, redirecting the content request from the first content distribution network node to the second content distribution network node.

2. The method of claim 1, wherein:

when the content request received by the first content distribution network node has been refused by at least one refusing content distribution network node, the content request received by the first content distribution network node comprises information identifying the at least one refusing content distribution network node; and
determining whether the second content distribution network node is the candidate for providing the requested content comprises determining, from the information identifying the content contained on each peer content distribution network node of the first content distribution network node and from the information identifying the at least one refusing content distribution network node, whether the second content distribution network node contains the requested content and is not a refusing content distribution network node.

3. The method of claim 2, wherein determining whether the second content distribution network node is the candidate for providing the requested content comprises:

determining, from the information identifying the content contained on each peer content distribution network node of the first content distribution network node and from the information identifying the at least one refusing content distribution network node, a plurality of peer content distribution network nodes that contain the requested content and that are not refusing content distribution network nodes; and
selecting one of the plurality of peer content distribution network nodes as the second content distribution network node.

4. The method of claim 3, wherein redirecting the content request from the first content distribution network node to the second content distribution network node comprises adding, to the information identifying the at least one refusing content distribution network node of the redirected content request, information identifying the first content distribution network node as a refusing content distribution network node.

5. The method of claim 4, wherein:

the content request received by the first content distribution network node comprises an address associated with the first content distribution network node;
the information identifying the at least one refusing content distribution network node is encoded in the address; and
adding, to the information identifying the at least one refusing content distribution network node of the redirected content request, the information identifying the first content distribution network node as a refusing content distribution network node comprises adding information identifying the first content distribution network node to the address of the content request redirected to the second content distribution network node.

6. The method of claim 5, wherein the address comprises a set of refusing content distribution network node identifiers.

7. The method of claim 6, wherein the set is ordered according to an order in which the refusing content distribution network nodes refused the content request.

8. The method of claim 6, wherein the address is a uniform resource locator.

9. The method of claim 2, wherein:

the content request received by the first content distribution network node comprises an address associated with the first content distribution network node; and
the information identifying the at least one refusing content distribution network node is encoded in the address.

10. The method of claim 9, wherein the address comprises a set of refusing content to distribution network node identifiers.

11. The method of claim 10, wherein the set is ordered according to an order in which the refusing content distribution network nodes refused the content request.

12. The method of claim 10, wherein the address is a uniform resource locator.

13. The method of claim 1, wherein determining whether the second content distribution network node is the candidate for providing the requested content comprises determining that no peer content distribution network node is a candidate for providing the requested content.

14. The method of claim 13, comprising sending a content request refusal message indicating that the requested content will not be provided.

15. The method of claim 13, wherein:

when the content request received by first content distribution network node has been refused by at least one refusing content distribution network node, the content request received by the first content distribution network node comprises information identifying the at least one refusing content distribution network node; and
determining that no peer content distribution node is a candidate for providing the requested content comprises determining, from the information identifying the content contained on each peer content distribution node of the first content distribution node and from the information identifying the at least one refusing content distribution network node, that no peer content distribution network node both contains the requested content and is not a refusing content distribution network node.

16. The method of claim 15, wherein:

the content request received by the first content distribution network node comprises an address associated with the first content distribution network node; and
the information identifying the at least one refusing content distribution network node is encoded in the address.

17. The method of claim 16, wherein the address comprises a set of refusing content distribution network node identifiers.

18. The method of claim 17, wherein the set is ordered according to an order in which the refusing content distribution network nodes refused the content request.

19. The method of claim 17, wherein the address is a uniform resource locator.

20. The method of claim 1, wherein redirecting the content request from the first content distribution network node to the second content distribution network node comprises adding to the content request an indication that the content request was refused by the first content distribution network node.

21. The method of claim 1, wherein the content request received by the first content distribution network node comprises an address associated with the first content distribution network node.

22. The method of claim 1, wherein providing the information identifying the content contained on each peer content distribution network node of the first content distribution network node comprises providing at least one distribution table at the first content distribution network node, the at least one distribution table associating content items with peer content distribution network nodes containing the content items.

23. The method of claim 22, wherein providing the at least one distribution table at the first content distribution network node comprises providing a separate distribution table for each of a plurality of content items on the first content distribution network node.

24. The method of claim 22, wherein:

the at least one content distribution table at the first content distribution network node lists the peer content distribution network nodes according to a peering hierarchy; and
when a plurality of peer content distribution network nodes contains the requested content and does not comprise refusing content distribution network nodes, the first content distribution network node preferentially selects the second content distribution network node based on the peering hierarchy.
Patent History
Publication number: 20130218958
Type: Application
Filed: Apr 10, 2013
Publication Date: Aug 22, 2013
Applicant: Rockstar Consortium US LP (Plano, TX)
Inventor: Rockstar Consortium US LP
Application Number: 13/860,092
Classifications
Current U.S. Class: Client/server (709/203)
International Classification: H04L 29/08 (20060101);