KR20140063465A - Method of request routing re-direction with loop detection and prevention - Google Patents
Method of request routing re-direction with loop detection and prevention Download PDFInfo
- Publication number
- KR20140063465A KR20140063465A KR1020130138901A KR20130138901A KR20140063465A KR 20140063465 A KR20140063465 A KR 20140063465A KR 1020130138901 A KR1020130138901 A KR 1020130138901A KR 20130138901 A KR20130138901 A KR 20130138901A KR 20140063465 A KR20140063465 A KR 20140063465A
- Authority
- KR
- South Korea
- Prior art keywords
- cdn
- request
- provider
- request routing
- list
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
- H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/20—Hop count for routing purposes, e.g. TTL
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
The present invention relates to a method for redelivering a multi-location request routing including detection and prevention of loops in an interconnection environment of a content delivery network.
A Content Delivery Network (CDN) is a system that distributes data to a network having a plurality of nodes to provide contents to a customer in order to efficiently deliver contents. Recently, a technique has been provided to prevent loops when redirecting CDN-to-CDN routing when a CDN is connected in one step. In other words, a solution is provided for a case where an upstream CDN Provider (uCDN) provider is directly connected to a
However, in the near future, multiple CDN operators will be connected to various stages and topologies (such as a tree or mesh), in which case there is a need for redistribution of cascaded request routing, loop detection and prevention techniques. However, since the conventional technology only returns one CDN provider candidate, the availability of the content delivery quality is hardly guaranteed, and the scalability is relatively inadequate in terms of topology processing.
Therefore, in the embodiment of the present invention, when a plurality of CDN providers are connected at various levels and topologies, high availability of the content delivery quality is ensured and the request routing including the loop detection and prevention function is re-delivered ≪ / RTI >
According to one aspect of the invention, a method is provided for redelivering a request routing. The request routing redelivery method comprising: receiving from a user terminal a domain name system request in which a first one of a plurality of CDNs connected by a content delivery network interconnection includes a list of CDN carrier IDs of a parent CDN of a first CDN; And if the request can not be processed, re-transmitting the request routing while preventing the loop of the request routing based on the list.
The request routing re-delivery method may further include transmitting the IP address of the forwarding node to the user terminal when the request can be processed.
The request routing re-delivery method may further include stopping redelivery of the request routing if the CDN carrier ID of the first CDN is included in the list.
In the request routing re-delivery method, the CDN provider ID may include the name of the CDN provider and the maximum number of forwarding hops.
The request routing re-delivery method may further include stopping the redelivery of the request routing when the maximum number of redeliverable hops is zero.
In the request routing re-delivery method, the name of the CDN provider may include an autonomous system number and an additional identifier pair.
Wherein the step of redelivering the request routing in the request routing redistribution method comprises the steps of: checking if the CDN carrier ID of the lower CDN of the first CDN is included in the list; if the CDN carrier ID of the lower CDN is not included in the list, A step of selecting a candidate CDN among the lower CDNs and a step of selecting a candidate CDN among the lower-level CDNs except for some CDNs if the list includes the CDN business ID of some of the lower-level CDNs.
The step of re-routing the request routing in the request routing redistribution method comprises: transmitting a name server (NS) record including the CDN carrier ID of the first CDN, the CDN carrier ID of the parent CDN, and the CDN carrier ID of the candidate CDN To the user terminal.
According to another aspect of the present invention, another method of redirecting request routing is provided. Wherein the request routing re-delivery method comprises: receiving from a user terminal a domain name system request in which a first one of a plurality of CDNs connected by a content delivery network interconnection includes a list of CDN carrier IDs of a parent CDN of a first CDN, Returning the Internet Protocol address of the requesting router of the first CDN to the terminal, receiving a hypertext transfer protocol request from the user terminal, determining whether it can handle the HTTP request, , Then redistributing the requesting routing while preventing the looping of the requesting routing based on the list.
The request routing re-delivery method may further include transmitting the IP address of the forwarding node to the user terminal when the request can be processed.
The request routing re-delivery method may further include stopping redelivery of the request routing if the CDN carrier ID of the first CDN is included in the list.
In the request routing re-delivery method, the CDN provider ID may include the name of the CDN provider and the maximum number of forwarding hops.
The request routing re-delivery method may further include stopping the redelivery of the request routing when the maximum number of redeliverable hops is zero.
In the request routing re-delivery method, the name of the CDN provider may include an autonomous system number and an additional identifier pair.
Wherein the step of redelivering the request routing in the request routing redistribution method comprises the steps of: checking if the CDN carrier ID of the lower CDN of the first CDN is included in the list; if the CDN carrier ID of the lower CDN is not included in the list, A step of selecting a candidate CDN among the lower CDNs and a step of selecting a candidate CDN among the lower-level CDNs except for some CDNs if the list includes the CDN business ID of some of the lower-level CDNs.
Wherein the step of redelivering the request routing in the request routing redistribution method comprises the steps of: redirecting the request redirection message to the request redirection method, wherein the redirection request message includes the CDN domain of the candidate CDN, the CDN domain of the first CDN and the CDN domain of the parent CDN, To the user terminal.
According to another aspect of the present invention, another method of redelivering a request routing is provided. The method of
The request routing redelivery method may further include redirecting the request to the third CDN out of the candidate CDNs if the connection with the second CDN fails.
The method further includes receiving an internet protocol (IP) address of the requesting router of the first CDN, and transmitting a hypertext transfer protocol request to the requesting router of the first CDN .
The request routing redelivery method may further include redirecting the request to the third CDN out of the candidate CDNs if the connection with the second CDN fails.
According to an embodiment of the present invention, in a network in which a plurality of CDNs are connected in various topologies, a requesting router of each CDN selects a plurality of CDNs as candidate CDNs and re-transmits the request routing, Scalability can be guaranteed. In addition, the requesting router of each CDN can detect and prevent a loop occurrence in the redelivery of the request routing by using the CDN-Provider-ID included in the message transmitted from the adjacent CDN.
1 is a diagram illustrating an interconnection environment of a content delivery network according to an embodiment of the present invention.
FIGS. 2A and 2B are diagrams illustrating a method of re-transmitting an HTTP-based request routing through an iterative procedure according to an embodiment of the present invention.
3 is a diagram illustrating a dCDN performing loop detection and prevention according to an embodiment of the present invention.
4 is a diagram illustrating a DNS-based request routing re-delivery method through an iterative procedure according to an embodiment of the present invention.
5A and 5B are views illustrating a method of re-transmitting an HTTP-based request routing through a recursive procedure according to an embodiment of the present invention.
FIG. 6 is a diagram illustrating a DNS-based request routing re-transmission method through a recursive procedure according to an embodiment of the present invention.
Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily carry out the present invention. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. In order to clearly illustrate the present invention, parts not related to the description are omitted, and similar parts are denoted by like reference characters throughout the specification.
Throughout the specification, when an element is referred to as "comprising ", it means that it can include other elements as well, without excluding other elements unless specifically stated otherwise. Also, the terms " part, "" module," " module, "and " block" refer to units that process at least one function or operation, Lt; / RTI >
1 is a diagram illustrating an interconnection environment of a content delivery network according to an embodiment of the present invention.
Referring to FIG. 1, a plurality of
The
The
The
The
Hereinafter, a CDN-Provider-ID according to an embodiment of the present invention will be described. The requesting router of each CDN can identify each CDN provider using the CDN-Provider-ID in the course of redelivering the request routing between the CDNs to the multi-location. The CDN-Provider-ID consists of the ProviderName and the maximum number of redirection hops (MaxNumRedHops).
The ProviderName includes an autonomous system (AS) number and an additional identifier pair. Additional identifier pairs are identifiers that can be used to ensure uniqueness when one or more CDN providers are included in the same AS number. For example, if the ProviderName of the CDN is 100: 0, the AS number is 100 and the CDN provider using this AS number is unique. On the other hand, if the ProviderName of the CDN is 200: 1, the AS number is 200, and this AS number is in use by two CDN providers, and this CDN is one of them.
MaxNumRedHops is the maximum number of times that request routing is allowed to be redelivered. The MaxNumRedHops value is decremented by one each time the redelivery of request routing occurs, and can be reduced to zero. An appropriate upper limit can be specified to prevent the MaxNumRedHops value from being intentionally abused, and the upper limit can be determined by negotiation between each CDN provider.
For example, if the CDN's CDN-Provider-ID is 100: 0: 10, then the ProviderName of this CDN is 100: 0 and MaxNumRedHops is 10. That is, in this case, the maximum number of permitted re-transmissions of the requested routing is 10 times.
CDN (uCDN -> dCDN1 -> dCDN2), the request routing is re-forwarded three times in succession. When the request routing re-transmission is performed by the hypertext transfer protocol (HTTP) , dCDN1 sends the CDN-Provider-ID to dCDN2 through the following uniform resource locator (URL).
At this time, instead of repeatedly marking MaxNumRedHops for each CDN-Provider-ID, it saves the space of a uniform resource identifier (URI) string by marking it once at the end of the URL. The CDN-Provider-ID delivery scheme of the embodiment of the present invention can be applied to redistributing demand-based routing based on a domain name system (DNS) as well as HTTP-based request routing re-delivery. At this time, in case of DNS-based request routing redelivery, CDN-Provider-ID can be included in the canonical name (CNAME) record.
FIGs. 2A and 2B are diagrams illustrating a method of redirecting an HTTP-based multi-location request routing through an iterative procedure according to an embodiment of the present invention.
In an HTTP-based request routing re-delivery method through an iterative procedure according to an embodiment of the present invention, all requesting routers of each CDN exchange messages with user terminals. Also in the present invention, the uCDN is the CDN carrying the requesting routing and the dCDN is the CDN receiving the requesting routing from the uCDN. Thus, although only one uCDN is shown in Figs. 2, 4, 5 and 6, when dCDN1 re-transmits the requested routing to dCDN2, dCDN1 becomes uCDN, dCDN2 becomes dCDN, and uCDN and dCDN are relatively determined between CDN .
Referring to FIGS. 2A and 2B, a DNS resolver of a uCDN provider processes a DNS request transmitted from a user terminal through CDN domain "cdn.csp.com" (S201). Then, as a result of the processing, the IP address of the requesting router module of the uCDN is returned to the user terminal (S202).
Thereafter, when the user terminal transmits the HTTP request to the requesting router module of the uCDN through the HTTP domain "cdn.csp.com" (S203), the requesting router of the uCDN judges that the dCDN1 can provide the optimum service to the user And transmits an
302 - "peer-uCDN.dCDN1.net/cdn.csp.com?uCDN-Provider-ID,
peer-uCDN.dCDN2.net/cdn.csp.com?uCDN-Provider-ID,
peer-uCDN.dCDNn.net/cdn.csp.com?uCDN-Provider-ID,
peer-uCDN.uCDN.net/cdn.csp.com?uCDN-Provider-ID "
The
Thereafter, the user terminal performs DNS lookup using "peer-uCDN.dcdn1.net" which is the CDN domain of dCDN1 (S205). The DNS resolver of the dCDN1 transfers the IP address of the requesting router of the dCDN1 to the user terminal (S206).
Thereafter, the user terminal transmits an HTTP request to the requesting router of the dCDN 1 (S207). If the connection with the dCDN1 fails, the user terminal attempts connection with another CDN described in the
On the other hand, the requesting router of the dCDN1 that receives the HTTP request from the user terminal can select two types of requesting routers. First, request routing can be redirected to other CDN providers. Second, the content can be delivered directly in response to the content delivery request of the user terminal. According to the embodiment of the present invention, the requesting router of the dCDN1 first performs the loop detection and prevention procedure using the CDN-Provider-ID in both cases.
According to the loop detection and prevention procedure according to the embodiment of the present invention, the requesting router checks the list of CDN-Provider-IDs. If the CDN-Provider-ID list has its own ID, it is determined that a loop has occurred. If the value of MaxNumRedHops is 0, it is determined that the re-transmission of the request routing can not proceed any further. The following algorithm is one example of implementing the loop detection and prevention procedure of the requesting router.
3 is a diagram illustrating a CDN that performs loop detection and prevention according to an embodiment of the present invention.
In an embodiment of the present invention, the requesting router of each CDN detects the loop through the loop detection and prevention algorithm as described above and determines the dCDN to redeliver the request routing so as to prevent the loop. Referring to FIG. 3,
Referring again to FIGs. 2A and 2B, the requesting router of the
The loop detection and prevention algorithm according to the embodiment of the present invention can support both the detection of a loop and the detection of a loop. That is, it is possible to detect whether a loop is generated by checking whether the CDN-Provider-ID list includes its own CDN-Provider-ID, and to terminate the redelivery of the request routing when a loop is detected. At this time, the loop detection and prevention algorithm can be applied to both the redelivery of the request routing and the content acquisition process between the CDN providers.
On the other hand, the requesting router checks the list of CDN-Provider-ID, and if the loop does not occur and it is not the proper CDN to deliver the content to the user terminal, the requesting router continues to pass back the request routing. That is, the dDNN provider to re-transmit the request routing is selected, and an HTTP redelivery message having its own CDN-Provider-ID is transmitted to the user terminal. According to the embodiment of the present invention, when the requesting router transmits an HTTP redelivery message to the user terminal, each requesting router can select a plurality of CDNs (multi-location). In this case, the criterion for selecting a CDN can be determined among the CDN operators, and it may be changed depending on the operation policy of the CDN network.
In this case, the above steps are repeated among the requesting routers until the dCDN provider capable of performing the service is selected or the MaxNumRedHops value becomes zero. Alternatively, the requesting router may process the requesting routing according to its own policy. In this case, an appropriate content delivery server is selected and an
Then, when a dCDN operator capable of performing a service is selected or a content delivery server is selected according to its own policy, and a dCDNn capable of handling a request of the user terminal is determined, the user terminal transmits a peer-dCDNn -1.dcdnn.net "to perform DNS lookup (S210). Thereafter, the DNS resolver returns the IP address of the requesting router of the dCDNn to the user terminal (S211).
Thereafter, when the request router of the dCDNn receives the HTTP request from the user terminal (S212), it selects a delivery node capable of providing the customer's request. Thereafter, the requesting router of the dCDNn forwards the
The user terminal performs DNS lookup using "node1.peer-dCDNn-1.dCNDn.net" which is a subdomain of the forwarding node of dCDNn (S214). Thereafter, the DNS resolver of the dCDNn returns the IP address of the forwarding node to the user terminal (S215).
Then, the user terminal requests the content node of the dCDNn (S216). If there is content requested by the customer in the cache server of the delivery node, the delivery node directly transmits the content to the user terminal.
However, if there is no content in the cache server (cache miss), the forwarding node fetches the content from the uCDN or higher dCDN and then delivers it to the user terminal. At this time, the user terminal can receive the contents from the dCDNn using the CDN domain "peer-dCDNn-1.dcCDnn.net".
Then, the forwarding node of dCDNn sends a DNS request to dCDNn-1 (S217), and the DNS resolver of dCDNn-1 processes the DNS request and returns the IP address of the requesting router of dCDNn-1 to the forwarding node of dCDNn S218).
Then, the requesting router of dCDNn-1 processes the HTTP request received from the forwarding node of the dCDNn (S219). The requesting router of dCDNn-1 recognizes that the HTTP request comes from the neighboring CDN provider through the trusted inter-CDN domain "dCDNn-qcq.dCDNn-1.net".
Even in the procedure in which the forwarding node fetches the contents from another dCDN, the requesting router of each dCDN re-transmits the request routing to the multi-location to check whether there is content in the cache of each CDN. The requesting router of each dCDN performs a loop detection and prevention procedure based on the delivered CDN-Provider-ID. The loop detection and prevention procedure is continuously performed until a value of MaxNumRedHops, which indicates the level of redelivery, is determined by the CDN provider capable of providing the content according to availability of the content depending on availability of the content.
If the contents server can not be found in the cache server of all the dCDN located between the user terminal and the uCDN, the requesting router of the uCDN selects the second forwarding node suitable for content delivery, 302 re-delivery message (S220).
At this time, for example, the 302 redelivery message may be delivered as follows.
302 - "node2.dCDN1.acq.uCDNn.net,
node3.dCDN1.acq.uCDNn.net,
origin.csp.com "
Then, the DNS resolver of the uCDN processes the DNS request (S221) and returns the IP address of the forwarding node of the uCDN (S222, S225). At this time, the connection between each transfer node and the dCDN1 may fail (S223, S226). In this case, the dCDN1 connects to the next transfer node described in the 302 redelivery message transmitted in step S220.
On the other hand, when a cache miss occurs in all the forwarding nodes, the dCDN1 finally accesses the origin server of the csp (S227), and the origin server included in the uCDN can deliver the contents to the user terminal via the dCDN (S228, S229 ).
4 is a diagram illustrating a DNS-based request routing re-delivery method through an iterative procedure according to an embodiment of the present invention.
The requesting router of the uCDN processes the DNS request transmitted by the user terminal based on the CDN domain cdn.csp.com (S401). In this process, the requesting router of the uCDN recognizes that it is appropriate for other CDN operators to handle the content request of the customer. Therefore, the requesting router of the uCDN returns a CNAME to the user terminal in which the ID of the dCDN1 and the CDN-Provider-ID of the uCDN are added to the original CDN domain. At the same time, a name server (NS) record mapping dCDN1.cdn.csp.com to the request router of the dCDN1 is also returned (S402). At this time, as shown in FIG. 3, the multi-location process is also possible in the DNS-based redelivery as in the case of HTTP. That is, the uCDN can select a plurality of candidate CDNs, incorporate CDN-Provider-IDs and URLs of a plurality of candidate CDNs into the NS record, and re-transmit the requested routing.
The user terminal performs DNS lookup using the modified CDN domain dCDN1.cdn.csp.com (S403). The requesting router of dCDN1 decides whether to process the content request of the customer directly or to resend it, and at the same time checks whether the loop occurs in the redelivery.
Thereafter, the transmission / reception of the message between the user terminal and the dCDN is repeated until the dCDN capable of handling the request is determined or MaxNumRedHops becomes zero. In the embodiment of the present invention, the case where the dCDNn is determined as the CDN that handles the customer's request will be described.
The user terminal performs a DNS lookup using the modified CDN domain dCDNn.cdn.csp.com (S404), and the requesting router of the dCDNn returns the IP address of the appropriate forwarding node to the user terminal (S405).
The user terminal requests the contents to the delivery node of the dCDNn (S406). At this time, if there is content in the cache server of the transfer node, the content is directly transferred from the transfer node to the user terminal.
However, if there is no content in the cache server of the forwarding node, dCDNn acquires the content from the parent dCDN or uCDN and delivers it to the user terminal. At this time, the request router of each CDN performs the loop detection and prevention procedure based on the CDN-Provider-ID.
Thereafter, the process of finding a CDN provider capable of providing contents until the value of MaxNumRedHops becomes 0, or until the CDN provider capable of providing contents according to the number of repetition of re-delivery and contents available is continued (S407) .
Thereafter, if the contents can not be found in the cache server of all the dCDNs located between the user terminal and the uCDN, the uCDN is determined as the content delivery CDN provider. The requesting router of the uCDN selects an appropriate forwarding node and returns the IP address of the selected forwarding node (S408). Then, the uCDN transmits the content requested through the dCDN to the user terminal (S409).
5A and 5B are views illustrating a method of re-transmitting an HTTP-based request routing through a recursive procedure according to an embodiment of the present invention.
The DNS resolver of the uCDN processes the DNS request transmitted from the user terminal based on the CDN domain "cdn.csp.com " (S501). Then, the IP address of the requesting router of the uCDN provider is returned as a result of the processing (S502).
According to the method of redirecting the HTTP-based request routing using the recursion procedure according to the embodiment of the present invention, when the user terminal transmits an HTTP request to the requesting router of the uCDN, the uCDN is transmitted through communication with a plurality of dCDN providers Finds the best dCDN provider and delivers it to the user terminal.
That is, the requesting router of the uCDN judges that the dCDN1 can best service the request of the user terminal while processing the HTTP request (S503) and requests the request including the necessary information such as the URL of the requested content through the request routing interface of the dCDN1 And sends a request routing interface (RRI) REQ message to dCDN1 (S504). At this time, CDN-Provider-ID of uCDN is provided for loop detection and prevention. In addition, when re-routing the request routing by the multi-location scheme, CDN-Provider-IDs of a plurality of CDN providers selected by the uCDN are also provided.
If dCDN1 finds a loop, it processes the loop according to the above algorithm. If there is no loop, dCDN1 sends the DNS name of the forwarding node to the user terminal or redirects the request routing to the other dCDN. This redirection of the request routing can continue until the CDN is determined which can provide the service for the customer's content request. Thus, the RRI RESP message may be transmitted in the opposite direction of redistribution, or may be delivered directly to the CDN provider, which is the origin of redistribution. The contact information may be included in the RRI REQ message or may be set in advance during the bootstrapping process (S505).
Thereafter, the requesting router of the uCDN returns a 302 redelivery message that redirects to the new URL (S506).
The user terminal performs DNS lookup based on the host name of the delivered URL (node1.dcdnn.net) (S507). Then, the DNS resolver of the dCDNn returns the IP address of the forwarding node to the user terminal (S508). At this time, since the user node receives the name of the forwarding node from the dCDNn through the CDN request routing interface, no further redelivery occurs. The requesting router of dCDNn can either redirect the HTTP request of the user terminal to another dCDN or directly handle it. When redirecting an HTTP request to another dCDN, it chooses a new dCDN provider and sends an HTTP redelivery message to the selected dCND operator with its CDN-Provider-ID added. However, if dCDN1 directly handles HTTP requests, it selects an appropriate content delivery server and sends an
Then, the user terminal requests content to the delivery node of the dCDNn (S509). If there is content requested to the cache server of the forwarding node of the dCDNn, the content may be transferred directly from the forwarding node to the user terminal.
However, if there is no requested content in the cache server of the forwarding node of dCDNn, then dCDNn must fetch the content from the uCDN or higher dCDN. The requesting router of each dCDN can re-route the request routing to the multi-location to see if there is content in the cache of each CDN.
At this time, the CDN domain "dCDNn.net" means that the content should be fetched from dCDNn-1. Each dCDN peels off the CDN domain and finds that the original CDN domain is cdn.csp.com. dCDNn will confirm that this CDN domain is already known CDN provider. In the embodiment of the present invention, the dCDNn requests content from dCDNn-1 through "dCDNn-acq.dCDNn-1.net" (S510).
The DNS resolver of dCDNn-1 processes the DNS request and returns the IP address of the requesting router of dCDNn-1 (S511).
Thereafter, the requesting router of dCDNn-1 receives and processes the HTTP request from the forwarding node of the dCDNn (S512). The dCDNn-1 request router can know that the content request comes from the neighboring CDN that is not from the user terminal through "dCDNn-acq.dCDNn-1.net" which is the domain obtained between the designated CDN domains. Then, the dCDNn-1 requesting router performs a loop detection and prevention process based on the CDN-Provider-ID. Thereafter, the content acquisition request is repeated recursively until the value of MaxNumRedHops becomes 0, or until the content providing CDN provider is selected according to the number of repetition of re-delivery and availability of the content.
Thereafter, if the contents can not be found in the cache server of all the dCDNs located between the user terminal and the uCDN, the uCDN is determined as the contents delivery CDN provider (S513). The requesting router of the uCDN selects an appropriate forwarding node capable of handling the content acquisition request between the CDN domain and sends an
The DNS resolver of the uCDN receiving the DNS request from the user terminal processes the DNS request (S515) and returns the IP address of the forwarding node of the uCDN (S510). Then, the uCDN provides the content from the requested CDN domain to the user terminal via the dCDN (S517).
FIG. 6 is a diagram illustrating a DNS-based request routing re-transmission method through a recursive procedure according to an embodiment of the present invention.
First, the requesting router of the uCDN processes a DNS request that the user terminal delivers based on the CDN domain "cdn.csp.com" (S601). At this stage, the requesting router of the uCDN determines that the dCDN1 can best handle the request of the customer's content. Therefore, the requesting router of the uCDN relays the requesting routing to the dCDN1 through the requesting routing interface of the dCDN1. At this time, the requesting router of the uCDN also provides the information including the URL and the CDN-Provider-ID of the uCDN (S602). As in the case of HTTP, the requesting router of the uCDN can also use the multi-location method. If the requesting router of the uCDN redirects the request routing by the multi-location method, it can transmit the multiple CDN candidates selected by the uCDN by including it in the NS record.
The requesting router of dCDN1 executes the loop detection and prevention algorithm through the CDN-Provider-ID list. If no loop has occurred, dCDN1 returns the DNS name of the appropriate forwarding node or redirects the request routing to another dCDN. If dCDN1 relays the request routing, the request routing may continue to be redirected between the dCDNs until a dCDN capable of providing content to the user terminal is selected. The RRI RESP message may be delivered in the reverse order of the redelivery process, or may be delivered directly to the original CDN carrier that initiated redelivery. At this time, the connection information with the first CDN provider may be included in the RRI request message or may be predetermined in the initialization process. In the embodiment of the present invention, a case where dCDNn is determined as a content-providing dCDN is explained (S603).
After that, the requesting router of the uCDN sends a CNAME to which the CDN domain ID of the dCDNn and the CDN-Provider-ID of the uCDN are added to the CDN domain, and a NS record in which "dCDN1.csp.com " is mapped to the requesting router of the dCDN1, (S604). If the multi-location option is selected, it returns as CDN-Provider-ID of the selected candidate CDN.
The user terminal performs DNS lookup based on the modified CDN domain "dCDNn.cdn.csp.com" (S605), and the requesting router of the dCDNn returns the IP address of the appropriate forwarding node to the user terminal (S606).
After that, the user terminal requests content to the delivery node of the dCDNn (S607). At this time, if the content is stored in the cache server of the dCDN, the content is directly transferred from the transfer node to the user terminal. However, if the content is not stored in the cache server, the dCDNn acquires the content from the uCDN or another dCDN and delivers it to the user terminal. At this time, each requesting router performs a loop detection and prevention procedure based on the CDN-Provider-ID. The process of finding the content among the dCDNs is repeated until the CDN provider who can provide the content requested by the customer is determined or MaxNumRedHops indicating the repetition frequency of redelivery is 0 (S608).
At this time, if a cache miss occurs in all the dCDNs, the uCDN is determined to be a contents delivery CDN provider (S609). The requesting router of the uCDN selects an appropriate forwarding node and returns the IP address of the forwarding node (S610). Thereafter, the uCDN may transmit the content to the user terminal via the dCDN (S611). At this time, the content is redirected between the dcNNs in the reverse order of the route to which the request routing is redirected.
As described above, according to the embodiment of the present invention, in a network in which a plurality of CDNs are connected in various topologies, a requesting router of each CDN selects a plurality of CDNs as candidate CDNs, And scalability can be ensured. In addition, the requesting router of each CDN can prevent the loop from occurring in the redelivery of the request routing by using the CDN-Provider-ID included in the message transmitted from the adjacent CDN.
While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, It belongs to the scope of right.
Claims (20)
A first CDN among a plurality of CDNs connected to a contents delivery network (CDN) interconnection (CDN interconnection, CDNi) is connected to a CDN provider identification (CDN-Provider-ID) of a parent CDN of the first CDN Receiving a domain name system (DNS) request including a list from a user terminal,
Determining if the request can be processed, and
If the request can not be processed, re-transferring the request while preventing the loop of the request based on the list
/ RTI > wherein the request routing re-delivery method comprises:
Transmitting the IP address of the forwarding node to the user terminal if the request can be handled
The request routing retransmission method further comprising:
Stopping redistribution of the request if the CDN carrier ID of the first CDN is included in the list
The request routing retransmission method further comprising:
The CDN provider ID includes:
The CDN provider names and the maximum number of redirection hops (MaxNumRedHops) of the CDN provider.
Stopping re-delivery of the request if the maximum number of redistribution hops is zero
The request routing retransmission method further comprising:
The name of the CDN provider,
A request routing redelivery method comprising an autonomous system (AS) number and an additional identifier pair.
The step of re-
Checking whether a CDN carrier ID of a lower CDN of the first CDN is included in the list,
Selecting a candidate CDN among the lower CDNs when the list does not include the CDN business ID of the lower CDN, and
Selecting a candidate CDN among the remaining lower CDNs except for the partial CDN when the CDN business ID of some of the lower CDNs is included in the list
/ RTI > wherein the request routing re-delivery method comprises:
The step of re-
Transmitting a name server (NS) record including a CDN provider ID of the first CDN, a CDN provider ID of the upper CDN, and a CDN provider ID of the candidate CDN to the user terminal
The request routing retransmission method further comprising:
A first CDN among a plurality of CDNs connected with a contents delivery network (CDN) interconnection (CDN interconnection, CDNi) is connected to a CDN provider identification (CDN-Provider-ID) of a parent CDN of the first CDN Receiving a domain name system (DNS) request including a list from a user terminal,
Returning an internet protocol (IP) address of the requesting router of the first CDN to the user terminal, and
Receiving a hypertext transfer protocol (HTTP) request from the user terminal,
Determining whether the HTTP request can be processed, and
If the HTTP request can not be processed, re-propagating the request while preventing a loop of the request based on the list
/ RTI > wherein the request routing re-delivery method comprises:
Transmitting the IP address of the forwarding node to the user terminal if the request can be handled
The request routing retransmission method further comprising:
Stopping redistribution of the request if the CDN carrier ID of the first CDN is included in the list
The request routing retransmission method further comprising:
The CDN provider ID includes:
The CDN provider names and the maximum number of redirection hops (MaxNumRedHops) of the CDN provider.
Stopping re-delivery of the request if the maximum number of redistribution hops is zero
The request routing retransmission method further comprising:
The name of the CDN provider,
A request routing redelivery method comprising an autonomous system (AS) number and an additional identifier pair.
The step of re-
Checking whether a CDN carrier ID of a lower CDN of the first CDN is included in the list,
Selecting a candidate CDN among the lower CDNs when the list does not include the CDN business ID of the lower CDN, and
Selecting a candidate CDN among the remaining lower CDNs except for the partial CDN when the CDN business ID of some of the lower CDNs is included in the list
/ RTI > wherein the request routing re-delivery method comprises:
The step of re-
Forwarding an HTTP redelivery message including the CDN domain of the candidate CDN, the CDN domain of the first CDN, the CDN domain of the parent CDN, and the CDN carrier ID of the first CDN to the user terminal
/ RTI > wherein the request routing re-delivery method comprises:
(CDN Provider ID) of the upper CDN of the first CDN to the first CDN among a plurality of CDNs connected by a contents delivery network (CDN) interconnection (CDN interconnection, CDNi) Forwarding a domain name system (DNS) request containing the list,
If the first CDN is unable to process the request, receiving in the list a DNS request further comprising a CDN carrier ID of the selected candidate CDN among the lower CDNs of the first CDN, and
Redistributing the request to a second one of the candidate CDNs
/ RTI > wherein the request routing re-delivery method comprises:
If the connection with the second CDN fails, redirecting the request to the third CDN of the candidate CDN
The request routing retransmission method further comprising:
Receiving an internet protocol (IP) address of a requesting router of the first CDN, and
Transmitting a hypertext transfer protocol (HTTP) request to the requesting router of the first CDN;
The request routing retransmission method further comprising:
If the connection with the second CDN fails, redirecting the request to the third CDN of the candidate CDN
The request routing retransmission method further comprising:
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/080,874 US9331976B2 (en) | 2012-11-15 | 2013-11-15 | Method of request routing re-direction with loop detection and prevention |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020120129733 | 2012-11-15 | ||
KR20120129733 | 2012-11-15 |
Publications (2)
Publication Number | Publication Date |
---|---|
KR20140063465A true KR20140063465A (en) | 2014-05-27 |
KR102045842B1 KR102045842B1 (en) | 2019-11-18 |
Family
ID=50891419
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
KR1020130138901A KR102045842B1 (en) | 2012-11-15 | 2013-11-15 | Method of request routing re-direction with loop detection and prevention |
Country Status (1)
Country | Link |
---|---|
KR (1) | KR102045842B1 (en) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050010662A1 (en) * | 2003-07-10 | 2005-01-13 | Arvind Prabhakar | System and method for guarding against infinite loops from multi-point redirects in a multi-threaded environment |
US20100223364A1 (en) * | 2009-02-27 | 2010-09-02 | Yottaa Inc | System and method for network traffic management and load balancing |
US20110280153A1 (en) * | 2010-05-13 | 2011-11-17 | Futurewei Technologies, Inc. | System, Apparatus for Content Delivery for Internet Traffic and Methods Thereof |
KR20120087872A (en) * | 2009-07-01 | 2012-08-07 | 레벨 3 커뮤니케이션즈 엘엘씨 | Flexible token for use in content delivery |
-
2013
- 2013-11-15 KR KR1020130138901A patent/KR102045842B1/en active IP Right Grant
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050010662A1 (en) * | 2003-07-10 | 2005-01-13 | Arvind Prabhakar | System and method for guarding against infinite loops from multi-point redirects in a multi-threaded environment |
US20100223364A1 (en) * | 2009-02-27 | 2010-09-02 | Yottaa Inc | System and method for network traffic management and load balancing |
KR20120087872A (en) * | 2009-07-01 | 2012-08-07 | 레벨 3 커뮤니케이션즈 엘엘씨 | Flexible token for use in content delivery |
US20110280153A1 (en) * | 2010-05-13 | 2011-11-17 | Futurewei Technologies, Inc. | System, Apparatus for Content Delivery for Internet Traffic and Methods Thereof |
Also Published As
Publication number | Publication date |
---|---|
KR102045842B1 (en) | 2019-11-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10931738B2 (en) | Point of presence management in request routing | |
US11632420B2 (en) | Point of presence management in request routing | |
US10523783B2 (en) | Request routing utilizing client location information | |
US9734472B2 (en) | Request routing utilizing cost information | |
US9794216B2 (en) | Request routing in a networked environment | |
US20190044787A1 (en) | Point of presence management in request routing | |
EP2266064B1 (en) | Request routing | |
Carofiglio et al. | From content delivery today to information centric networking | |
US9331976B2 (en) | Method of request routing re-direction with loop detection and prevention | |
US9160703B2 (en) | Request routing management based on network components | |
US20140289319A1 (en) | Request routing using popularity information | |
US20140304386A1 (en) | Routing client requests | |
US20190037044A1 (en) | Content distribution and delivery optimization in a content delivery network (cdn) | |
KR102045842B1 (en) | Method of request routing re-direction with loop detection and prevention | |
KR20220075985A (en) | System ndn-based communication supporting mobility of publisher and method for the same |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A201 | Request for examination | ||
E902 | Notification of reason for refusal | ||
E701 | Decision to grant or registration of patent right | ||
GRNT | Written decision to grant |