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 PDF

Info

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
Application number
KR1020130138901A
Other languages
Korean (ko)
Other versions
KR102045842B1 (en
Inventor
최태상
신동호
이종민
구자령
Original Assignee
한국전자통신연구원
주식회사 솔박스
에스케이텔레콤 주식회사
주식회사 엘지유플러스
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 한국전자통신연구원, 주식회사 솔박스, 에스케이텔레콤 주식회사, 주식회사 엘지유플러스 filed Critical 한국전자통신연구원
Priority to US14/080,874 priority Critical patent/US9331976B2/en
Publication of KR20140063465A publication Critical patent/KR20140063465A/en
Application granted granted Critical
Publication of KR102045842B1 publication Critical patent/KR102045842B1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • H04L45/741Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/20Hop 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

Provided is a method for requesting routing redirection including receiving, through a first content delivery network among a plurality of content delivery networks connected by content delivery network interconnection, a domain name system request including a list of content delivery network provider identifications of higher content delivery networks, from a client; determining whether the request from the client can be processed; and, when the request from the client can not be processed, redirecting the request and preventing a loop of the request routing on the basis of the list of the content delivery network provider identifications.

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention [0002]

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 level 1 downstream CDN Provider (dCDN).

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 claim 1, wherein the request routing re-delivery method comprises: transmitting a domain name system request including a list of CDN carrier IDs of a parent CDN of a first CDN to a first one of a plurality of CDNs connected by a content delivery network interconnection, If the request can not be processed, the step of receiving, in the list, a DNS request further comprising the CDN carrier ID of the selected candidate CDN among the lower CDNs of the first CDN, and redirecting the request to the second CDN of the candidate 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.

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 CDNs 100 are connected to each other through a CDN interconnection (CDNi). The internal functional modules of each CDN provider include a control unit 110, a request routing unit 120, a distribution processor 130, and a logging processor 140.

The control unit 110 may perform necessary initialization operations in the CDN interconnection and request an instruction to be performed by another CDN provider instead. For example, a uCDN provider may request a dCDN provider to search for metadata of a specific content or a specific content, or to modify or delete the content of the content.

The request routing unit 120 can redirect the request message to another CDN in the process of searching for a CDN provider capable of processing the content request of the customer.

The distribution unit 130 can exchange metadata of contents between the CDNs.

The logging unit 140 may store related information generated in the process of transmitting the content, and may transmit summary information of the content. The summary information of the content can be used for CDN performance analysis and fee calculation.

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).

Figure pat00001

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 HTTP 302 redelivery message as follows (S204). At this time, dCDN2, dCDNn, and uCDN are included as candidates in addition to dCDN1, and an HTTP 302 redelivery message is transmitted together.

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 HTTP 302 redelivery message includes the following fields: "peer-uCDN.dCDN1.net", "peer-uCDN.dCDN2.net", "peer-uCDN.dCDNn.net", and "peer-uCDN", which are CDN domains of dCDN1, dCDN2, dCDNn, .uCDN.net ", and the CDN-Provider-ID of the uCDN is included in the URL query string. The reason that the requesting router of the uCDN delivers the request routing to the multi-location through the HTTP 302 redelivery message is to return the one or more candidate CDNs to ensure the availability of the content delivery quality. The user terminal then conveys this message without modifying it in the response HTTP message.

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 HTTP 302 redelivery message received from the uCDN (S208).

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.

Figure pat00002

Figure pat00003

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, dCDN3 320, which has received the request routing again from dCDN2 320, refers to the CDN-Provider-ID list when re-routing the request routing. Since the CDN-Provider-ID does not have its own CDN-Provider-ID in the list, it is determined that the loop has not yet occurred. When the request routing is redelivered, the CDN-Provider-ID of the dCDN1 310 is included in the CDN-Provider-ID list without re-delivering to the parent CDN, dCDN2 320, 310). Therefore, it relays the request routing back to dCDN4 340 or dCDN5 350.

Referring again to FIGs. 2A and 2B, the requesting router of the dCDN 1 determines that the loop does not yet occur because its CDN-Provider-ID is not included in the CDN-Provider-ID list.

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 HTTP 302 redelivery message including the address of the server is transmitted to the user terminal (S209).

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 HTTP 302 redelivery message replacing the CDN domain of the selected forwarding node to the sub-domain to the user terminal (S213).

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 HTTP 302 redelivery message containing the address of the selected server to the user terminal.

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 HTTP 302 redelivery message replaced with a subdomain (of the specified CDN to the acquisition domain of the uCDN) pointing to the selected forwarding node To the user terminal (S514).

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 method for redelivering a request routing,
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:
The method of claim 1,
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:
The method of claim 1,
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 method of claim 1,
The CDN provider ID includes:
The CDN provider names and the maximum number of redirection hops (MaxNumRedHops) of the CDN provider.
5. The method of claim 4,
Stopping re-delivery of the request if the maximum number of redistribution hops is zero
The request routing retransmission method further comprising:
5. The method of claim 4,
The name of the CDN provider,
A request routing redelivery method comprising an autonomous system (AS) number and an additional identifier pair.
The method of claim 1,
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:
8. The method of claim 7,
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 method for redelivering a request routing,
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:
The method of claim 9,
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:
The method of claim 9,
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 method of claim 9,
The CDN provider ID includes:
The CDN provider names and the maximum number of redirection hops (MaxNumRedHops) of the CDN provider.
The method of claim 12,
Stopping re-delivery of the request if the maximum number of redistribution hops is zero
The request routing retransmission method further comprising:
The method of claim 12,
The name of the CDN provider,
A request routing redelivery method comprising an autonomous system (AS) number and an additional identifier pair.
The method of claim 9,
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:
16. The method of claim 15,
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:
A method for redelivering a request routing,
(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:
The method of claim 17,
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:
The method of claim 17,
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:
20. The method of claim 19,
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:
KR1020130138901A 2012-11-15 2013-11-15 Method of request routing re-direction with loop detection and prevention KR102045842B1 (en)

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)

* Cited by examiner, † Cited by third party
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

Patent Citations (4)

* Cited by examiner, † Cited by third party
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