KR102045842B1

KR102045842B1 - 루프 탐지 및 방지를 포함한 요구 라우팅 재전달 방법

Info

Publication number: KR102045842B1
Application number: KR1020130138901A
Authority: KR
Inventors: 최태상; 신동호; 이종민; 구자령
Original assignee: 한국전자통신연구원; 에스케이텔레콤 주식회사; 주식회사 엘지유플러스; 주식회사 솔박스
Priority date: 2012-11-15
Filing date: 2013-11-15
Publication date: 2019-11-18
Also published as: KR20140063465A

Abstract

콘텐츠 전달망 인터커넥션으로 연결된 복수의 콘텐츠 전달망 중 제1 콘텐츠 전달망이 상위 콘텐츠 전달망의 콘텐츠 전달망 사업자 아이디의 리스트가 포함된 도메인 이름 시스템 요구를 고객으로부터 수신하는 단계, 고객의 요구를 처리할 수 있는지 판단하는 단계, 그리고 고객의 요구를 처리할 수 없는 경우, 콘텐츠 전달망 사업자 아이디 리스트를 바탕으로 요구 라우팅의 루프를 방지하여 재전달하는 단계를 포함하는 요구 라우팅 재전달 방법이 제공된다.

Description

루프 탐지 및 방지를 포함한 요구 라우팅 재전달 방법{Method of request routing re-direction with loop detection and prevention}

본 발명은 콘텐츠 전달 네트워크의 상호 접속 환경에서 루프의 탐지 및 방지를 포함한 멀티로케이션 요구 라우팅을 재전달 하는 방법에 관한 것이다.

콘텐츠 전달망(Content Delivery Network, CDN)은 콘텐츠를 효율적으로 전달하기 위해 복수의 노드를 가진 네트워크에 데이터를 분산 저장하고 고객에게 제공하는 시스템이다. 근래에는 CDN이 한 단계로 연결된 경우, CDN 간 요구 라우팅을 재전달 할 때 루프를 방지할 수 있는 기술이 제공되고 있다. 즉, 하나의 상위 콘텐츠 전달망(upstream CDN Provider, uCDN) 사업자가 하위로 하나의 단계의 콘텐츠 전달망(level 1 downstream CDN Provider, dCDN)과 직접 연결된 경우에 대한 솔루션이 제공되고 있다.

그러나, 가까운 미래에 복수의 CDN 사업자는 다양한 단계와 토폴로지(트리 또는 메쉬 등)로 연결될 것이고, 이 경우, CDN 간 다단계적(cascaded) 요구 라우팅의 재전달, 루프 탐지 및 방지 기술이 필요하다. 하지만, 종래 기술은 하나의 CDN 사업자 후보만을 회신하기 때문에 콘텐츠 전달 품질의 가용성이 보장되기 어렵고, 토폴로지 처리 측면에서도 상대적으로 확장성이 부족하다.

따라서, 본 발명의 실시 예에서는, 복수의 CDN 사업자가 다양한 수준과 토폴로지로 연결된 경우에, 콘텐츠 전달 품질의 높은 가용성(availability)이 보장되고, 루프 탐지 및 방지 기능이 포함된 요구 라우팅을 재전달하는 방법을 제공한다.

본 발명의 한 특징에 따르면, 요구 라우팅을 재전달하는 방법이 제공된다. 상기 요구 라우팅 재전달 방법은, 콘텐츠 전달망 인터커넥션으로 연결된 복수의 CDN 중 제1 CDN이 제1 CDN의 상위 CDN의 CDN 사업자 아이디의 리스트가 포함된 도메인 이름 시스템 요구를 사용자 단말로부터 수신하는 단계, 요구를 처리할 수 있는지 판단하는 단계, 그리고 요구를 처리할 수 없는 경우, 리스트를 바탕으로 요구 라우팅의 루프를 방지하면서 요구 라우팅을 재전달하는 단계를 포함한다.

상기 요구 라우팅 재전달 방법은, 요구를 처리할 수 있는 경우, 전달 노드의 IP주소를 사용자 단말로 전송하는 단계를 더 포함할 수 있다.

상기 요구 라우팅 재전달 방법은, 리스트에 제1 CDN의 CDN 사업자 아이디가 포함되어 있는 경우, 요구 라우팅의 재전달을 중지하는 단계를 더 포함할 수 있다.

상기 요구 라우팅 재전달 방법에서 CDN 사업자 아이디는, CDN 사업자의 이름 및 최대 재전달 홉 개수를 포함할 수 있다.

상기 요구 라우팅 재전달 방법은, 최대 재전달 홉 개수가 0인 경우, 요구 라우팅의 재전달을 중지하는 단계를 더 포함할 수 있다.

상기 요구 라우팅 재전달 방법에서 CDN 사업자의 이름은, 자율 시스템 번호 및 추가 식별자 쌍을 포함할 수 있다.

상기 요구 라우팅 재전달 방법에서 요구 라우팅을 재전달하는 단계는, 제1 CDN의 하위 CDN의 CDN 사업자 아이디가 리스트에 포함되어 있는지 확인하는 단계, 리스트에 하위 CDN의 CDN 사업자 아이디가 포함되지 않은 경우, 하위 CDN 중에서 후보 CDN을 선정하는 단계, 그리고 리스트에 하위 CDN 중 일부 CDN의 CDN 사업자 아이디가 포함된 경우, 일부 CDN을 제외한 나머지 하위 CDN 중에서 후보 CDN을 선정하는 단계를 포함할 수 있다.

상기 요구 라우팅 재전달 방법에서 요구 라우팅을 재전달하는 단계는, 제1 CDN의 CDN 사업자 아이디, 상위 CDN의 CDN 사업자 아이디, 그리고 후보 CDN의 CDN 사업자 아이디가 포함된 네임 서버(name server, NS) 레코드를 사용자 단말로 전달하는 단계를 더 포함할 수 있다.

본 발명의 다른 특징에 따르면, 요구 라우팅을 재전달하는 다른 방법이 제공된다. 상기 요구 라우팅 재전달 방법은, 콘텐츠 전달망 인터커넥션으로 연결된 복수의 CDN 중 제1 CDN이 제1 CDN의 상위 CDN의 CDN 사업자 아이디의 리스트가 포함된 도메인 이름 시스템요구를 사용자 단말로부터 수신하는 단계, 사용자 단말로 제1 CDN의 요구 라우터의 인터넷 프로토콜 주소를 리턴하는 단계, 그리고 사용자 단말로부터 하이퍼텍스트 전송 규약 요구를 수신하는 단계, HTTP 요구를 처리할 수 있는지 판단하는 단계, 그리고 HTTP 요구를 처리할 수 없는 경우, 리스트를 바탕으로 요구 라우팅의 루프를 방지하면서 요구 라우팅을 재전달하는 단계를 포함한다.

상기 요구 라우팅 재전달 방법에서 요구 라우팅을 재전달하는 단계는, 후보 CDN의 CDN 도메인, 제1 CDN의 CDN 도메인 및 상위 CDN의 CDN 도메인과, 제1 CDN의 CDN 사업자 아이디가 포함된 HTTP 재전달 메시지를 사용자 단말로 전달하는 단계를 포함할 수 있다.

본 발명의 다른 특징에 따르면, 요구 라우팅을 재전달하는 또 다른 방법이 제공된다. 상기 요구 라우팅 재전달 방법은, 콘텐츠 전달망 인터커넥션으로 연결된 복수의 CDN 중 제1 CDN에게 제1 CDN의 상위 CDN의 CDN 사업자 아이디의 리스트가 포함된 도메인 이름 시스템 요구를 전달하는 단계, 제1 CDN이 요구를 처리할 수 없는 경우, 리스트에, 제1 CDN의 하위 CDN 중에서 선정된 후보 CDN의 CDN 사업자 아이디가 더 포함된 DNS 요구를 수신하는 단계, 그리고 후보 CDN 중에서 제2 CDN으로 요구를 재전달 하는 단계를 포함한다.

상기 요구 라우팅 재전달 방법은, 제2 CDN과의 연결이 실패한 경우, 후보 CDN 중에서 제3 CDN으로 요구를 재전달 하는 단계를 더 포함할 수 있다.

상기 요구 라우팅 재전달 방법은, 제1 CDN의 요구 라우터의 인터넷 프로토콜(internet protocol, IP) 주소를 수신하는 단계, 그리고 제1 CDN의 요구 라우터로 하이퍼텍스트 전송 규약 요구를 전송하는 단계를 더 포함할 수 있다.

이와 같이 본 발명의 한 실시 예에 따르면, 복수의 CDN이 다양한 토폴로지로 연결된 네트워크에서, 각 CDN의 요구 라우터는 복수의 CDN을 후보 CDN으로 선정하여 요구 라우팅을 재전달함으로써, 콘텐츠 전달 품질의 가용성 및 확장성을 모두 보장할 수 있다. 또한, 각 CDN의 요구 라우터는 인접 CDN에서 전송된 메시지에 포함된 CDN-Provider-ID을 이용하여 요구 라우팅의 재전달 시 루프 발생을 탐지하고 방지할 수 있다.

도 1은 본 발명의 실시 예에 따른 콘텐츠 전달망의 상호 접속 환경을 나타낸 도면이다.
도 2a 및 도 2b는 본 발명의 실시 예에 따른 반복(iterative) 절차를 통한 HTTP 기반 요구 라우팅 재전달 방법을 나타낸 도면이다.
도 3은 본 발명의 실시 예에 따른 루프 탐지 및 방지를 수행하는 dCDN을 나타낸 도면이다.
도 4는 본 발명의 실시 예에 따른 반복(iterative) 절차를 통한 DNS 기반 요구 라우팅 재전달 방법을 나타낸 도면이다.
도 5a 및 도 5b는 본 발명의 실시 예에 따른 재귀(recursive) 절차를 통한 HTTP 기반 요구 라우팅 재전달 방법을 나타낸 도면이다.
도 6은 본 발명의 실시 예에 따른 재귀(recursive) 절차를 통한 DNS기반 요구 라우팅 재전달 방법을 나타낸 도면이다.

아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시 예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.

명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서에 기재된 "…부", "…기", "모듈", "블록" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

도 1은 본 발명의 실시 예에 따른 콘텐츠 전달망의 상호 접속 환경을 나타낸 도면이다.

도 1을 참조하면, 복수 개의 CDN(100)은 서로 CDN 인터커넥션(Content Delivery Network interconnection, CDNi)를 통해 연결된다. 그리고 각 CDN 사업자의 내부 기능 모듈은 제어부(110), 요구 라우팅부(120), 분배부(distribution processor)(130), 그리고 로깅부(logging processor) (140)를 포함한다.

제어부(110)는, CDN 인터커넥션시 필요한 초기화 작업을 수행하고, 다른 CDN 사업자로 대신 수행될 명령을 요청할 수 있다. 예를 들어, uCDN 사업자가 dCDN 사업자에게 특정 콘텐츠 또는 특정 콘텐츠의 메타데이터(metadata)의 검색을 요청하거나, 콘텐츠의 내용을 수정 또는 삭제하도록 요청할 수 있다.

요구 라우팅부(120)는, 고객의 콘텐츠 요구를 처리할 수 있는 CDN 사업자를 찾는 과정에서, 요구 메시지를 다른 CDN으로 재전달할 수 있다.

분배부(130)는, 콘텐츠의 메타데이터를 각 CDN 사이에서 주고 받을 수 있다.

로깅부(140)는, 콘텐츠의 전달 과정에서 발생하는 관련 정보를 저장하고, 콘텐츠의 요약 정보를 전달할 수 있다. 콘텐츠의 요약 정보는 CDN 성능 분석 및 요금 산정 등에 사용될 수 있다.

아래에서는 본 발명의 실시 예에 따른 CDN 사업자 아이디(CDN-Provider-ID)를 설명한다. 각 CDN의 요구 라우터는 CDN 사이에서 요구 라우팅을 멀티로케이션(multi-location)으로 재전달하는 과정에서 CDN-Provider-ID를 이용하여 각 CDN 사업자를 식별할 수 있다. CDN-Provider-ID는 ProviderName과 최대 재전달 홉 개수(maximum number of redirection hops, MaxNumRedHops)로 구성된다.

ProviderName은 자율 시스템(autonomous system, AS) 번호 및 추가 식별자 쌍을 포함한다. 추가 식별자 쌍은, 하나 이상의 CDN 사업자가 동일한 AS 번호에 포함되는 경우에 고유성을 보장하기 위해 사용될 수 있는 식별자이다. 예를 들어, CDN의 ProviderName이 100:0인 경우, AS 번호는 100이고, 본 AS 번호를 사용하는 CDN 사업자는 유일하다. 반면, CDN의 ProviderName이 200:1인 경우에는 AS 번호는 200이고, 이 AS 번호를 두 개의 CDN 사업자가 사용 중이며, 이 CDN은 그 중 1번에 해당한다.

MaxNumRedHops는 요구 라우팅의 재전달이 허용된 최대 횟수를 의미한다. MaxNumRedHops 값은 요구 라우팅의 재전달이 1회 발생할 때마다 하나씩 감소하여 0이 될 때까지 줄어들 수 있다. MaxNumRedHops 값이 고의적으로 남용되는 것을 막기 위해서 적절할 상한값이 지정될 수 있고, 상한값은 각 CDN 사업자 간의 협상으로 결정될 수 있다.

예를 들어, CDN의 CDN-Provider-ID가 100:0:10인 경우, 이 CDN의 ProviderName은 100:0이고, MaxNumRedHops는 10이다. 즉 이 경우, 허용된 최대 요구 라우팅 재전달 횟수가 10회이다.

CDN 사이(uCDN -> dCDN1 -> dCDN2)에서 요구 라우팅의 재전달이 3번 순차적으로 발생하는 경우를 설명하면, 하이퍼텍스트 전송 규약(hypertext transfer protocol, HTTP) 방식으로 요구 라우팅 재전달이 이루어 질 때, dCDN1은 아래와 같은 유일자원지시기(uniform resource locator, URL)를 통해 CDN-Provider-ID를 dCDN2로 전달한다.

이때, MaxNumRedHops를 CDN-Provider-ID마다 반복해서 표기하는 대신, URL의 마지막에 한 번만 표기함으로써, 유일자원식별자(uniform resource identifier, URI) 문자열(string)의 공간을 절약한다. 본 발명의 실시 예의 이와 같은 CDN-Provider-ID 전달 방식은, HTTP 기반 요구 라우팅 재전달은 물론 도메인 이름 시스템(domain name system, DNS) 기반 요구 라우팅 재전달에도 적용 가능하다. 이때, DNS 기반 요구 라우팅 재전달의 경우에는 CDN-Provider-ID를 대표 이름(canonical name, CNAME) 레코드에 포함시켜 전달할 수 있다.

도 2a 및 도 2b는 본 발명의 실시 예에 따른 반복(iterative) 절차를 통한 HTTP 기반의 멀티로케이션 요구 라우팅 재전달 방법을 나타낸 도면이다.

본 발명의 실시 예에 따른 반복 절차를 통한 HTTP 기반 요구 라우팅 재전달 방법에서는, 각 CDN의 요구 라우터가 모두 사용자 단말과 메시지를 주고 받는다. 또한, 본 발명에서, uCDN은 요구 라우팅을 전달하는 CDN이고, dCDN은 uCDN으로부터 요구 라우팅을 수신하는 CDN이다. 따라서, 도 2, 4, 5 및 6에서 uCDN은 하나만 표시되었지만, dCDN1이 dCDN2로 요구 라우팅을 재전달 할 경우에는 dCDN1이 uCDN이 되고dCDN2가 dCDN이 되고, uCDN과 dCDN은 CDN 사이에서 상대적으로 결정될 수 있다.

도 2a 및 도 2b를 참조하면, uCDN 제공자(provider)의 DNS 리졸버(resolver)는 CDN 도메인인 "cdn.csp.com"을 통해 사용자 단말로부터 전달된 DNS 요구를 처리한다(S201). 이후, 처리 결과로 uCDN의 요구 라우터 모듈의 IP 주소를 사용자 단말에게 리턴한다(S202).

이후, 사용자 단말이 HTTP 도메인인 "cdn.csp.com"을 통해 HTTP 요구를 uCDN의 요구 라우터 모듈로 전달하면(S203), uCDN의 요구 라우터는 dCDN1이 사용자에게 최적의 서비스를 제공할 수 있다고 판단하고, 아래와 같이 HTTP 302 재전달 메시지를 전송한다(S204). 이때, dCDN1 이외에 dCDN2, dCDNn 및 uCDN도 후보로 포함해서 HTTP 302 재전달 메시지를 함께 전송한다.

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"

이 HTTP 302 재전달 메시지는 기존의 URL에 dCDN1, dCDN2, dCDNn 및 uCDN의 CDN 도메인인 "peer-uCDN.dCDN1.net, peer-uCDN.dCDN2.net, peer-uCDN.dCDNn.net, peer-uCDN.uCDN.net"을 스택킹(stacking)하고, uCDN의 CDN-Provider-ID를 URL query string에 포함시킨 것이다. uCDN의 요구 라우터가 HTTP 302 재전달 메시지를 통해 멀티로케이션으로 요구 라우팅을 전달하는 이유는, 하나 이상의 후보 CDN을 회신하여 콘텐츠 전달 품질의 가용성을 보장하기 위함이다. 이후, 사용자 단말은 이 메시지를 응답 HTTP 메시지에 수정하지 않고 담아서 전달한다.

이후, 사용자 단말은 dCDN1의 CDN 도메인인 "peer-uCDN.dCDN1.net"을 이용하여 DNS 룩업(lookup)을 수행한다(S205). 그리고, dCDN1의 DNS 리졸버는 dCDN1의 요구 라우터의 IP 주소를 사용자 단말에게 전달한다(S206).

이후 사용자 단말은 dCDN1의 요구 라우터로 HTTP 요구를 전달한다(S207). dCDN1과의 연결에 실패하면 사용자 단말은 uCDN에게서 받은 HTTP 302 재전달 메시지에 기재된 다른 CDN과 연결을 시도한다(S208).

한편, 사용자 단말로부터 HTTP 요구를 전달받은 dCDN1의 요구 라우터는 두 가지를 선택할 수 있다. 첫 번째, 타 CDN 사업자에게 요구 라우팅을 재전달 할 수 있다. 두 번째, 사용자 단말의 콘텐츠 전달 요구에 대응하여 직접 콘텐츠를 전달할 수 있다. 본 발명의 실시 예에 따르면, dCDN1의 요구 라우터는 두 경우 모두 CDN-Provider-ID를 이용하여 루프 탐지 및 방지 절차를 먼저 수행한다.

본 발명의 실시 예에 따른 루프 탐지 및 방지 절차에 따르면, 요구 라우터는 CDN-Provider-ID의 리스트를 체크한다. CDN-Provider-ID 리스트에 자신의 ID가 있다면, 루프가 발생한 것으로 판단한다. 그리고, MaxNumRedHops 값이 0이라면, 요구 라우팅의 재전달이 더 이상 진행될 수 없는 상태로 판단한다. 아래 알고리즘은 요구 라우터의 루프 탐지 및 방지 절차를 구현한 한 가지 예시이다.

도 3은 본 발명의 실시 예에 따른 루프 탐지 및 방지를 수행하는 CDN을 나타낸 도면이다.

본 발명의 실시 예에서, 각 CDN의 요구 라우터는 위와 같은 루프 탐지 및 방지 알고리즘을 통해 루프를 탐지하고, 루프를 방지할 수 있도록 요구 라우팅을 재전달할 dCDN을 결정한다. 도 3을 참조하면, dCDN2(320)로부터 요구 라우팅을 재전달 받은 dCDN3(320)는 요구 라우팅을 재전달할 때 CDN-Provider-ID 리스트를 참고한다. 일단, CDN-Provider-ID 리스트에 자신의 CDN-Provider-ID가 없으므로 루프는 아직 발생하지 않았다고 판단한다. 그리고, 요구 라우팅을 재전달할 때, 부모 CDN인 dCDN2(320)에게는 재전달하지 않고, dCDN1(310)의 CDN-Provider-ID는 CDN-Provider-ID 리스트에 포함되어 있어서 루프가 발생하게 되므로 dCDN1(310)으로도 재전달 하지 않는다. 따라서, dCDN4(340) 또는 dCDN5(350)로 요구 라우팅을 재전달한다.

다시 도 2a 및 도 2b를 참조하면, dCDN1의 요구 라우터는 자신의 CDN-Provider-ID가 CDN-Provider-ID 리스트에 포함되어 있지 않기 때문에 아직 루프가 발생하지 않은 것으로 판단한다.

본 발명의 실시 예에 따른 루프 탐지 및 방지 알고리즘은 루프를 탐지한 경우와 루프를 탐지한 후의 조치를 모두 지원할 수 있다. 즉, CDN-Provider-ID 리스트에 자신의 CDN-Provider-ID가 포함되어 있는지 여부를 확인함으로써 루프의 발생 여부를 탐지할 수 있고, 루프가 탐지된 경우 요구 라우팅의 재전달을 종료할 수 있다. 이때, 루프 탐지 및 방지 알고리즘은 요구 라우팅의 재전달 및 CDN 사업자간 콘텐츠 획득 과정에 모두 적용될 수 있다.

한편, 요구 라우터는 CDN-Provider-ID의 리스트를 체크한 결과 루프가 발생하지 않았고, 자신이 사용자 단말에게 콘텐츠를 전달할 적절한 CDN이 아닌 경우 요구 라우팅의 재전달을 계속한다. 즉, 요구 라우팅을 재전달할 dCDN 사업자를 선정하고, 자신의 CDN-Provider-ID를 추가한 HTTP 재전달 메시지를 사용자 단말에게 전송한다. 본 발명의 실시 예에 따르면, 요구 라우터가 HTTP 재전달 메시지를 사용자 단말에게 전송할 때에는 각 요구 라우터는 복수의 CDN(멀티 로케이션)을 선정할 수 있다. 이때 CDN이 선정되는 기준은 각 CDN 사업자 사이에서 결정될 수 있으며, CDN 망의 운용 정책에 따라 달라질 수도 있다.

이 경우, 서비스를 수행할 수 있는 dCDN 사업자가 선정되거나, MaxNumRedHops 값이 0이 될 때까지 요구 라우터 사이에서 위 단계가 반복된다. 또는 요구 라우터는 자체적인 정책에 따라 요구 라우팅을 처리할 수 있다. 이 경우 적절한 콘텐츠 전달 서버를 선정하고 이 서버의 주소를 포함하는 HTTP 302 재전달 메시지를 사용자 단말에게 전송한다(S209).

이후, 서비스를 수행할 수 있는 dCDN 사업자를 선정하거나 자체 정책에 따라 콘텐츠 전달 서버를 선정하여, 사용자 단말의 요구를 처리할 수 있는 dCDNn이 결정되면, 사용자 단말은 dCDNn의 CDN 도메인인 "peer-dCDNn-1.dCDNn.net"을 이용하여 DNS 룩업을 수행한다(S210). 이후, DNS 리졸버는 dCDNn의 요구 라우터의 IP 주소를 사용자 단말에게 리턴한다(S211).

이후, dCDNn의 요구 라우터는 사용자 단말로부터 HTTP 요구를 수신하면(S212), 고객의 요구를 제공할 수 있는 전달 노드를 선정한다. 이후, dCDNn의 요구 라우터는 선정된 전달 노드의 CDN 도메인을 서브 도메인으로 교체하는 HTTP 302 재전달 메시지를 사용자 단말에게 전달한다(S213).

사용자 단말은 dCDNn의 전달 노드의 서브 도메인인 "node1.peer-dCDNn-1.dCNDn.net"을 이용하여 DNS 룩업을 수행한다(S214). 이후, dCDNn의 DNS 리졸버는 전달 노드의 IP 주소를 사용자 단말에게 리턴한다(S215).

이후, 사용자 단말은 dCDNn의 전달 노드에게 콘텐츠를 요청한다(S216). 전달 노드의 캐시(cache) 서버에 고객이 요청한 콘텐츠가 있다면, 전달 노드는 사용자 단말에게 콘텐츠를 직접 전송한다.

하지만, 캐시 서버에 콘텐츠가 없다면(cache miss), 전달 노드는 콘텐츠를 uCDN 또는 상위 dCDN에서 가져온 다음 사용자 단말에게 전달한다. 이때, 사용자 단말은 CDN 도메인인 "peer-dCDNn-1.dCDNn.net"을 이용하여 dCDNn로부터 콘텐츠를 전달받을 수 있다.

이후, dCDNn의 전달 노드는 dCDNn-1로 DNS 요구를 보내고(S217), dCDNn-1의 DNS 리졸버는 DNS 요구를 처리하여, dCDNn-1의 요구 라우터의 IP 주소를 dCDNn의 전달 노드로 리턴한다(S218).

그리고, dCDNn-1의 요구 라우터는 dCDNn의 전달 노드로부터 받은 HTTP 요구를 처리한다(S219). dCDNn-1의 요구 라우터는 신뢰할 수 있는 inter-CDN 도메인인 "dCDNn-qcq. dCDNn-1.net"을 통해서 HTTP 요구가 인접 CDN 사업자로부터 온 것임을 인지한다.

전달 노드가 다른 dCDN에서 콘텐츠를 가져오는 절차에서도, 각 dCDN의 요구 라우터는 요구 라우팅을 멀티로케이션으로 재전달 하여 각 CDN의 캐시에 콘텐츠가 있는지 확인한다. 그리고, 각 dCDN의 요구 라우터는 전달된 CDN-Provider-ID를 기반으로 루프 탐지 및 방지 절차를 수행한다. 루프 탐지 및 방지 절차는 콘텐츠의 가용 여부에 따라 콘텐츠의 가용 여부에 따라 콘텐츠를 제공할 수 있는 CDN 사업자가 결정되거나, 재전달의 수준을 나타내는 MaxNumRedHops 값이 0이 될 때까지 계속하여 수행된다.

만약, 사용자 단말과 uCDN의 중간에 위치한 모든 dCDN의 캐시 서버에서 콘텐츠를 찾을 수 없다면, uCDN의 요구 라우터는 콘텐츠 전달을 위한 적합한 두 번째 전달 노드를 선정하고, 선정된 전달 노드의 서브 도메인 정보를 담은 302 재전달 메시지를 리턴 한다(S220).

이때, 예를 들어 302 재전달 메시지는 아래와 같이 전달될 수 있다.

302 - "node2.dCDN1.acq.uCDNn.net,

node3.dCDN1.acq.uCDNn.net,

origin.csp.com"

이후, uCDN의 DNS 리졸버는 DNS 요구를 처리한 후(S221), uCDN의 전달 노드의 IP 주소를 리턴한다(S222, S225). 이때, 각 전달 노드와 dCDN1 사이에서 연결이 실패될 수 있고(S223, S226), 그 경우 dCDN1은 S220 단계에서 전달받은 302 재전달 메시지에 기재된 다음 전달 노드로 접속한다.

한편, 모든 전달 노드에서 캐시 미스가 발생하면, dCDN1은 최종적으로 csp의 origin 서버로 접속하고(S227), uCDN에 포함된 origin 서버는 dCDN을 경유하여 콘텐츠를 사용자 단말에게 전달할 수 있다(S228, S229).

도 4는 본 발명의 실시 예에 따른 반복(iterative) 절차를 통한 DNS 기반 요구 라우팅 재전달 방법을 나타낸 도면이다.

uCDN의 요구 라우터는, CDN 도메인인 cdn.csp.com을 기반으로 사용자 단말이 전달한 DNS 요구를 처리한다(S401). 이 과정에서 uCDN의 요구 라우터는 타 CDN 사업자가 고객의 콘텐츠 요구를 처리하는 것이 적합함을 인지한다. 따라서, uCDN의 요구 라우터는 원래 CDN 도메인에 dCDN1의 아이디(identification, ID) 및 uCDN의 CDN-Provider-ID를 추가한 CNAME을 사용자 단말에게 리턴한다. 그리고 동시에 dCDN1.cdn.csp.com을 dCDN1의 요구 라우터에 매핑한 네임 서버(name server, NS) 레코드도 같이 리턴한다(S402). 이때, 도 3와 같이 DNS 기반 재전달에서도 HTTP의 경우와 마찬가지로 멀티로케이션 처리가 가능하다. 즉, uCDN은 후보 CDN을 복수 개 선정하여, 복수의 후보 CDN의 CDN-Provider-ID 및 URL을 NS 레코드에 포함시킨 후 요구 라우팅을 재전달할 수 있다.

사용자 단말은 수정된 CDN 도메인인 dCDN1.cdn.csp.com을 사용하여 DNS 룩업을 수행한다(S403). dCDN1의 요구 라우터는 고객의 콘텐츠 요구를 직접 처리할 것인지 아니면 재전달할 것인지 결정하고, 동시에 재전달에서 루프가 발생하는지도 점검한다.

이후, 요구를 처리할 수 있는 dCDN이 결정되거나 MaxNumRedHops가 0이 될 때까지 사용자 단말과 dCDN 사이에 메시지 송수신이 반복된다. 본 발명의 실시 예에서는 dCDNn이 고객의 요구를 처리하는 CDN으로 결정된 경우를 설명한다.

사용자 단말은 수정된 CDN 도메인인 dCDNn.cdn.csp.com을 이용하여 DNS 룩업을 수행하고(S404), dCDNn의 요구 라우터는 적합한 전달 노드의 IP 주소를 사용자 단말에게 리턴한다(S405).

사용자 단말은 dCDNn의 전달 노드로 콘텐츠를 요청한다(S406). 이때, 전달 노드의 캐시 서버에 콘텐츠가 있다면 콘텐츠는 전달 노드에서 사용자 단말에게 직접 전달된다.

하지만, 전달 노드의 캐시 서버에 콘텐츠가 없다면, dCDNn은 상위 부모 dCDN 또는 uCDN에서 콘텐츠를 획득하고, 사용자 단말에게 전달한다. 이때 각 CDN의 요구 라우터에서는 CDN-Provider-ID를 기반으로 루프 탐지 및 방지 절차를 수행한다.

이후, MaxNumRedHops 값이 0이 되거나, 재전달의 반복 횟수와 콘텐츠의 가용 여부에 따라 콘텐츠를 제공할 수 있는 CDN 사업자가 결정될 때까지 콘텐츠를 제공할 수 있는 CDN 사업자를 찾는 과정이 계속된다(S407).

이후, 사용자 단말과 uCDN의 중간에 위치한 모든 dCDN의 캐시 서버에서 콘텐츠를 찾을 수 없다면, uCDN이 콘텐츠 전달 CDN 사업자로 결정된다. uCDN의 요구 라우터는 적합한 전달 노드를 선정하고 선정된 전달 노드의 IP 주소를 리턴한다(S408). 그리고 uCDN은 dCDN을 통해 요청된 콘텐츠를 사용자 단말에게 전달한다(S409).

도 5a 및 도 5b는 본 발명의 실시 예에 따른 재귀(recursive) 절차를 통한 HTTP 기반 요구 라우팅 재전달 방법을 나타낸 도면이다.

uCDN의 DNS 리졸버는 CDN 도메인인 "cdn.csp.com"을 기반으로 사용자 단말로부터 전달된 DNS 요구를 처리한다(S501). 그리고, 처리 결과로 uCDN 사업자의 요구 라우터의 IP 주소를 리턴한다(S502).

본 발명의 실시 예에 따른 재귀 절차를 이용한 HTTP 기반 요구 라우팅의 재전달 방법에 의하면, 사용자 단말이 uCDN의 요구 라우터로 HTTP 요구를 전달하기만 하면, 이후 uCDN은 복수의 dCDN 사업자와의 통신을 통해 최적 dCDN 사업자를 알아내어 사용자 단말에게 전달한다.

즉, uCDN의 요구 라우터는 HTTP 요구를 처리하는 중(S503) dCDN1이 사용자 단말의 요구를 가장 잘 서비스 할 수 있을 것으로 판단하고, dCDN1의 요구 라우팅 인터페이스를 통해서 요청한 콘텐츠의 URL 등 필요한 정보를 포함한 요구 라우팅 인터페이스(request routing interface, RRI) REQ 메시지를 dCDN1으로 보낸다(S504). 이때, 루프 탐지 및 방지를 위해서 uCDN의 CDN-Provider-ID를 제공한다. 그리고, 멀티로케이션 방식으로 요구 라우팅을 재전달하는 경우, uCDN에서 선정한 복수의 CDN 사업자의 CDN-Provider-ID도 함께 제공된다.

dCDN1에서는 루프를 발견하면, 위의 알고리즘에 따라 루프를 처리한다. 루프가 없다면, dCDN1은 전달 노드의 DNS 이름을 사용자 단말에게 보내거나, 다른 dCDN으로 요구 라우팅을 재전달 한다. 이런 요구 라우팅의 재전달은 고객의 콘텐츠 요청에 대한 서비스를 제공할 수 있는 CDN이 결정될 때까지 계속될 수 있다. 따라서, RRI RESP 메시지가 재전달의 반대 방향으로 전송되거나, 재전달의 시발점인 CDN 사업자에게 직접 전달될 수 있다. 접촉 정보는 RRI REQ 메시지에 포함될 수도 있고 부트 스트래핑 과정 동안 미리 설정될 수도 있다(S505).

이후, uCDN의 요구 라우터는 새로운 URL로 리디렉션(redirection) 하는 302 재전달 메시지를 리턴한다(S506).

사용자 단말은 전달 받은 URL(node1.dCDNn.net)의 호스트 이름을 기반으로 DNS 룩업을 수행한다(S507). 그리고, dCDNn의 DNS 리졸버는 해당 전달 노드의 IP 주소를 사용자 단말에게 리턴한다(S508). 이때, 사용자 단말이 CDN 요구 라우팅 인터페이스를 통해서 dCDNn으로부터 전달 노드의 이름을 전달 받았기 때문에, 추가적인 재전달은 발생하지 않는다. dCDNn의 요구 라우터는 사용자 단말의 HTTP 요청을 다른 dCDN으로 재전달하거나, 직접 처리할 수 있다. 다른 dCDN으로 HTTP 요청을 재전달하는 경우, 새로운 dCDN 사업자를 선택하고 선택한 dCND 사업자에게 자신의 CDN-Provider-ID를 추가한 HTTP 재전달 메시지를 보낸다. 하지만, dCDN1이 직접 HTTP 요청을 처리하는 경우, 적절한 콘텐츠 전달 서버를 선정하고, 선정된 서버의 주소를 포함하는 HTTP 302 재전달 메시지를 사용자 단말에게 보낸다.

이후, 사용자 단말은 dCDNn의 전달 노드로 콘텐츠를 요청한다(S509). dCDNn의 전달 노드의 캐시 서버에 요청한 콘텐츠가 있다면, 콘텐츠는 전달 노드에서 사용자 단말에게 직접 전송될 수 있다.

하지만, dCDNn의 전달 노드의 캐시 서버에 요청한 콘텐츠가 없다면, dCDNn은 uCDN 또는 상위 dCDN으로부터 콘텐츠를 가져와야 한다. 각 dCDN의 요구 라우터는 요구 라우팅을 멀티로케이션으로 재전달 하여 각 CDN의 캐시에 콘텐츠가 있는지 확인할 수 있다.

이때, CDN 도메인인 "dCDNn.net"은 콘텐츠를 dCDNn-1로부터 가져와야 함을 의미한다. 각 dCDN은 CDN 도메인을 벗겨내어 원 소속 CDN 도메인이 cdn.csp.com임을 알 수 있다. dCDNn은 본 CDN 도메인이 이미 알려진 CDN 사업자 임을 확인하게 된다. 본 발명의 실시 예에서 dCDNn은 "dCDNn-acq.dCDNn-1.net"을 통하여 dCDNn-1로 콘텐츠를 요청한다(S510).

dCDNn-1의 DNS 리졸버는 DNS 요구를 처리하고, dCDNn-1의 요구 라우터의 IP 주소를 리턴한다(S511).

이후, dCDNn-1의 요구 라우터는 dCDNn의 전달 노드로부터 HTTP 요구를 수신하여 처리한다(S512). dCDNn-1 요구 라우터는 지정된 CDN 도메인 간에 획득된 도메인인 "dCDNn-acq.dCDNn-1.net"을 통해서 콘텐츠 요구가 사용자 단말로부터 온 것이 아닌 인접 CDN으로부터 온 것임을 알 수 있다. 그리고, dCDNn-1 요구 라우터는 CDN-Provider-ID를 바탕으로 루프 탐지 및 방지 프로세스를 수행한다. 이후, 콘텐츠 획득 요구는 MaxNumRedHops 값이 0이 되거나, 재전달의 반복 횟수와 콘텐츠의 가용 여부에 따라 콘텐츠 제공 CDN 사업자가 선택될 때까지 재귀적으로 반복된다.

이후, 사용자 단말과 uCDN의 중간에 위치한 모든 dCDN의 캐시 서버에서 콘텐츠를 찾을 수 없다면, uCDN이 콘텐츠 전달 CDN 사업자로 결정된다(S513). uCDN의 요구 라우터는 CDN 도메인 사이에서 콘텐츠 획득 요구를 처리할 수 있는 적합한 전달 노드를 선택하고, 선택한 전달 노드를 가리키는 (uCDN의 지정 CDN 간 획득 도메인의)서브 도메인으로 교체된 HTTP 302 재전달 메시지를 사용자 단말에게 전송한다(S514).

사용자 단말로부터 DNS 요구를 받은 uCDN의 DNS 리졸버는 DNS 요구를 처리하고(S515), uCDN의 전달 노드의 IP 주소를 리턴한다(S510). 이후, uCDN은 요청된 CDN 도메인으로부터 dCDN을 거쳐 사용자 단말에게 콘텐츠를 제공한다(S517).

도 6은 본 발명의 실시 예에 따른 재귀(recursive) 절차를 통한 DNS기반 요구 라우팅 재전달 방법을 나타낸 도면이다.

먼저, uCDN의 요구 라우터는, 사용자 단말이 CDN 도메인인 "cdn.csp.com"을 기반으로 전달한 DNS 요구를 처리한다(S601). 이 단계에서 uCDN의 요구 라우터는 고객의 콘텐츠 요청을 dCDN1이 가장 잘 처리할 수 있다고 판단한다. 따라서, uCDN의 요구 라우터는 dCDN1의 요구 라우팅 인터페이스를 통해 dCDN1으로 요구 라우팅을 재전달한다. 이때, uCDN의 요구 라우터는 URL을 포함하는 정보와 uCDN의 CDN-Provider-ID도 제공한다(S602). 그리고 HTTP의 경우와 마찬가지로 uCDN의 요구 라우터는 멀티로케이션 방식도 사용할 수 있다. uCDN의 요구 라우터가 멀티로케이션 방식으로 요구 라우팅을 재전달하는 경우, uCDN에서 선정한 복수의 CDN 후보를 NS 레코드에 포함시켜 전송할 수 있다.

dCDN1의 요구 라우터는 CDN-Provider-ID 리스트를 통해 루프 탐지 및 방지 알고리즘을 실행한다. 루프가 발생하지 않았다면, dCDN1은 적합한 전달 노드의 DNS 이름을 리턴하거나, 다른 dCDN으로 요구 라우팅을 재전달한다. dCDN1이 요구 라우팅을 재전달하는 경우, 사용자 단말에게 콘텐츠를 제공할 수 있는 dCDN이 선택될 때까지 dCDN 사이에서 요구 라우팅이 계속 재전달 될 수 있다. RRI RESP 메시지는 재전달 과정의 역순으로 전달되거나, 재전달을 시작한 최초 CDN 사업자에게 직접 전달될 수 있다. 이때 최초 CDN 사업자와의 연결 정보는 RRI 요청 메시지에 포함되거나 초기화 과정에서 사전에 정해질 수 있다. 본 발명의 실시 예에서는 dCDNn이 콘텐츠 제공 dCDN으로 결정된 경우를 설명한다(S603).

이후, uCDN의 요구 라우터는 CDN 도메인에 dCDNn의 지정 CDN 도메인 ID 및 uCDN의 CDN-Provider-ID가 추가된 CNAME과, "dCDN1.csp.com"을 dCDN1의 요구 라우터에 매핑한 NS 레코드를 사용자 단말에게 리턴한다(S604). 그리고, 멀티로케이션 옵션이 선택된 경우 선택된 후보 CDN의 CDN-Provider-ID로 포함해서 리턴한다.

사용자 단말은 수정된 CDN 도메인인 "dCDNn.cdn.csp.com"을 바탕으로 DNS 룩업을 수행하고(S605), dCDNn의 요구 라우터는 적합한 전달 노드의 IP 주소를 사용자 단말에게 리턴한다(S606).

이후, 사용자 단말은 dCDNn의 전달 노드에게 콘텐츠를 요청한다(S607). 이때, dCDN의 캐시 서버에 콘텐츠가 저장되어 있다면, 전달 노드에서 사용자 단말에게 직접 콘텐츠가 전달된다. 하지만, 캐시 서버에 콘텐츠가 저장되어 있지 않다면, dCDNn은 uCDN 또는 다른 dCDN에서 콘텐츠를 획득하여 사용자 단말에게 전달한다. 이때에도 각 요구 라우터에서는 CDN-Provider-ID를 기반으로 루프 탐지 및 방지 절차를 수행한다. 고객이 요청한 콘텐츠를 제공할 수 있는 CDN 사업자가 결정되거나, 재전달의 반복 횟수를 나타내는 MaxNumRedHops가 0이 될 때까지 dCDN 사이에서 콘텐츠를 찾는 과정이 반복된다(S608).

이때, 모든 dCDN에서 캐시 미스(cache miss)가 발생하면, uCDN이 콘텐츠 전달 CDN 사업자로 결정된다(S609). uCDN의 요구 라우터는 적합한 전달 노드를 선정하여 전달 노드의 IP 주소를 리턴한다(S610). 이후, uCDN은 dCDN을 경유하여 콘텐츠를 사용자 단말에게 전달할 수 있다(S611). 이때, 콘텐츠는 요구 라우팅이 재전달된 경로의 역순으로 dCDN 사이에서 재전달 된다.

위에서 설명한 바와 같이 본 발명의 실시 예에 따르면, 복수의 CDN이 다양한 토폴로지로 연결된 네트워크에서, 각 CDN의 요구 라우터는 복수의 CDN을 후보 CDN으로 선정하여 요구 라우팅을 재전달함으로써, 콘텐츠 전달 품질의 가용성 및 확장성을 보장할 수 있다. 또한, 각 CDN의 요구 라우터는 인접 CDN에서 전송된 메시지에 포함된 CDN-Provider-ID을 이용하여 요구 라우팅의 재전달 시 루프 발생을 방지할 수 있다.

이상에서 본 발명의 실시 예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.

Claims

요구 라우팅을 재전달하는 방법으로서,
복수의 콘텐츠 전달망(contents delivery network, CDN) 중 제1 CDN이 상기 제1 CDN의 상위 CDN의 CDN 사업자 아이디(CDN Provider identification, CDN-Provider-ID)의 리스트가 포함된 도메인 이름 시스템(domain name system, DNS) 요구를 사용자 단말로부터 수신하는 단계,
상기 DNS 요구를 처리할 수 있는지 판단하는 단계, 그리고
상기 DNS 요구를 처리할 수 없는 경우, 상기 리스트에 따라 상기 DNS 요구가 상기 복수의 CDN 내에서 루프되는 것을 방지하면서 상기 DNS 요구를 재전달하는 단계
를 포함하고,
상기 복수의 CDN은 CDN 인터커넥션(CDN interconnection, CDNi)으로 연결되어 있는, 요구 라우팅 재전달 방법.
제1항에서,
상기 DNS 요구를 처리할 수 있는 경우, 전달 노드의 IP주소를 상기 사용자 단말로 전송하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제1항에서,
상기 리스트에 상기 제1 CDN의 CDN 사업자 아이디가 포함되어 있는 경우, 상기 루프가 발생한 것으로 판단하고 상기 DNS 요구의 재전달을 중지하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제1항에서,
상기 CDN 사업자 아이디는,
상기 CDN 사업자의 이름(CDN Provider names) 및 최대 재전달 홉 개수(maximum number of redirection hops, MaxNumRedHops)를 포함하는 요구 라우팅 재전달 방법.
제4항에서,
상기 최대 재전달 홉 개수가 0인 경우, 상기 DNS 요구의 재전달을 중지하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제4항에서,
상기 CDN 사업자의 이름은,
자율 시스템(autonomous system, AS) 번호 및 추가 식별자 쌍을 포함하는 요구 라우팅 재전달 방법.
제1항에서,
상기 DNS 요구를 재전달하는 단계는,
상기 제1 CDN의 하위 CDN의 CDN 사업자 아이디가 상기 리스트에 포함되어 있는지 확인하는 단계,
상기 리스트에 상기 하위 CDN의 CDN 사업자 아이디가 포함되지 않은 경우, 상기 하위 CDN 중에서 후보 CDN을 선정하는 단계, 그리고
상기 리스트에 상기 하위 CDN 중 일부 CDN의 CDN 사업자 아이디가 포함된 경우, 상기 일부 CDN을 제외한 나머지 하위 CDN 중에서 후보 CDN을 선정하는 단계
를 포함하는 요구 라우팅 재전달 방법.
제7항에서,
상기 DNS 요구를 재전달하는 단계는,
상기 제1 CDN의 CDN 사업자 아이디, 상기 상위 CDN의 CDN 사업자 아이디, 그리고 상기 후보 CDN의 CDN 사업자 아이디가 포함된 네임 서버(name server, NS) 레코드를 상기 사용자 단말로 전달하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
요구 라우팅을 재전달하는 방법으로서,
복수의 콘텐츠 전달망(contents delivery network, CDN) 중 제1 CDN이 상기 제1 CDN의 상위 CDN의 CDN 사업자 아이디(CDN Provider identification, CDN-Provider-ID)의 리스트가 포함된 도메인 이름 시스템(domain name system, DNS) 요구를 사용자 단말로부터 수신하는 단계,
상기 사용자 단말로 상기 제1 CDN의 요구 라우터의 인터넷 프로토콜(internet protocol, IP) 주소를 리턴하는 단계, 그리고
상기 사용자 단말로부터 하이퍼텍스트 전송 규약(hypertext transfer protocol, HTTP) 요구를 수신하는 단계,
상기 HTTP 요구를 처리할 수 있는지 판단하는 단계, 그리고
상기 HTTP 요구를 처리할 수 없는 경우, 상기 리스트에 따라 상기 DNS 요구가 상기 복수의 CDN 내에서 루프되는 것을 방지하면서 상기 DNS 요구를 재전달하는 단계
를 포함하고,
상기 복수의 CND은 CDN 인터커넥션(CDN interconnection, CDNi)으로 연결되어 있는, 요구 라우팅 재전달 방법.
제9항에서,
상기 DNS 요구를 처리할 수 있는 경우, 전달 노드의 IP주소를 상기 사용자 단말로 전송하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제9항에서,
상기 리스트에 상기 제1 CDN의 CDN 사업자 아이디가 포함되어 있는 경우, 상기 루프가 발생한 것으로 판단하고 상기 DNS 요구의 재전달을 중지하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제9항에서,
상기 CDN 사업자 아이디는,
상기 CDN 사업자의 이름(CDN Provider names) 및 최대 재전달 홉 개수(maximum number of redirection hops, MaxNumRedHops)를 포함하는 요구 라우팅 재전달 방법.
제12항에서,
상기 최대 재전달 홉 개수가 0인 경우, 상기 DNS 요구의 재전달을 중지하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제12항에서,
상기 CDN 사업자의 이름은,
자율 시스템(autonomous system, AS) 번호 및 추가 식별자 쌍을 포함하는 요구 라우팅 재전달 방법.
제9항에서,
상기 DNS 요구를 재전달하는 단계는,
상기 제1 CDN의 하위 CDN의 CDN 사업자 아이디가 상기 리스트에 포함되어 있는지 확인하는 단계,
상기 리스트에 상기 하위 CDN의 CDN 사업자 아이디가 포함되지 않은 경우, 상기 하위 CDN 중에서 후보 CDN을 선정하는 단계, 그리고
상기 리스트에 상기 하위 CDN 중 일부 CDN의 CDN 사업자 아이디가 포함된 경우, 상기 일부 CDN을 제외한 나머지 하위 CDN 중에서 후보 CDN을 선정하는 단계
를 포함하는 요구 라우팅 재전달 방법.
제15항에서,
상기 DNS 요구를 재전달하는 단계는,
상기 후보 CDN의 CDN 도메인, 상기 제1 CDN의 CDN 도메인 및 상기 상위 CDN의 CDN 도메인과, 상기 제1 CDN의 CDN 사업자 아이디가 포함된 HTTP 재전달 메시지를 상기 사용자 단말로 전달하는 단계
를 포함하는 요구 라우팅 재전달 방법.
요구 라우팅을 재전달하는 방법으로서,
복수의 콘텐츠 전달망(contents delivery network, CDN) 중 제1 CDN에게 상기 제1 CDN의 상위 CDN의 CDN 사업자 아이디(CDN Provider identification, CDN-Provider-ID)의 리스트가 포함된 도메인 이름 시스템(domain name system, DNS) 요구를 전달하는 단계,
상기 제1 CDN이 상기 DNS 요구를 처리할 수 없는 경우, 상기 리스트에, 상기 제1 CDN의 하위 CDN 중에서 선정된 후보 CDN의 CDN 사업자 아이디가 더 포함된 DNS 요구를 수신하는 단계, 그리고
상기 후보 CDN 중에서 제2 CDN으로 상기 DNS 요구를 재전달 하는 단계
를 포함하고,
상기 복수의 CDN은 CDN 인터커넥션(CDN interconnection, CDNi)으로 연결되어 있는, 요구 라우팅 재전달 방법.
제17항에서,
상기 제2 CDN과의 연결이 실패한 경우, 상기 후보 CDN 중에서 제3 CDN으로 상기 DNS 요구를 재전달 하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제17항에서,
상기 제1 CDN의 요구 라우터의 인터넷 프로토콜(internet protocol, IP) 주소를 수신하는 단계, 그리고
상기 제1 CDN의 요구 라우터로 하이퍼텍스트 전송 규약(hypertext transfer protocol, HTTP) 요구를 전송하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.
제19항에서,
상기 제2 CDN과의 연결이 실패한 경우, 상기 후보 CDN 중에서 제3 CDN으로 상기 DNS 요구를 재전달 하는 단계
를 더 포함하는 요구 라우팅 재전달 방법.