컨텐츠 전달 네트워크 상호 접속

Content delivery network interconnection

CDNI(Content Delivery Network Interconnecting, CDNI)는 서로 다른 하나를 대신하여 콘텐츠를 전달할 수 있도록 하는 두 개의 독립 콘텐츠 전송 네트워크(CDN) 상호 연결에 필요한 인터페이스와 메커니즘의 집합이다.상호 연결된 CDN은 CSP(콘텐츠 서비스 공급자), CDN, 최종 사용자에게 설치 공간 확장, 인프라 비용 절감, 가용성 향상 등과 같은 많은 이점을 제공한다.여러 활용 사례 중 작은 CDN이 상호 접속할 수 있도록 하고, 글로벌 CSP의 CDN과 경쟁할 수 있는 서비스도 제공한다.

이론적 근거

CDN은 배달비용 절감, 경험의 질 향상(QoE), 배달의 견고성 향상 등 CDN의 많은 이점 덕분에 캐시 가능한 콘텐츠의 대규모 콘텐츠 전달에 인기가 많아졌다.이 때문에 CDN 사업자와 CDN 사업자 사이에 사업·기술협정이 이루어진 경우, CDN 사업자는 인프라를 확장하고 있으며, 많은 ISP(인터넷 서비스 사업자)/네트워크 서비스 사업자(NSP)가 자체적인 CDN을 자체 사용 또는 임대용으로 구축하거나 배치하고 있다.잘 정의된 요청 라우팅, 전달, 인수, 회계 시스템 및 프로토콜이 있는 독립 실행형 CDN은 조만간 풋프린트, 리소스 또는 기능 한계에 직면할 수 있다.CDNI는 별도의 CDN을 활용하여 위치나 첨부 네트워크에 관계없이 CSP에서 최종 사용자에게 컨텐츠의 엔드 투 엔드 전달을 제공하는 것을 목표로 한다.

작동 예

아래 그림과 같이 두 CDN의 상호연결을 고려해 봅시다.ISP-A는 권위 있는 업스트림 CDN(uCDN)을 배치하고 있으며, 그는 CSP와 기술 및 사업협약을 맺었다.CDN-A는 CSP를 대신하여 서비스할 수 있는 권한이 있기 때문에 ISP-B 네트워크의 사용자는 CDN-A(1)에 콘텐츠를 요청한다.The uCDN can either serve the request itself or redirect it to a downstream CDN (dCDN) if, for example, dCDN is closer to the user equipment (UE). If the request is redirected, the interconnected CDNs must provide the requested content to the dCDN. If the content is not available in the uCDN, it can be acquired first from CSP (2) and then submittedCDN(3)의 대리인에게.리디렉션을 따르는 UE는 dCDN (4)에 콘텐츠를 요청하며, 마지막으로 요청된 콘텐츠가 대리인에게 배포된다.

An example of end-to-end content delivery using CDNI.
CDNI를 사용한 엔드 투 엔드 컨텐츠 전달의 예.

이 예에서, 최종 사용자는 서비스 품질(QoS) 향상으로부터 이익을 얻을 수 있고, CSP는 uCDN과 단 하나의 사업과 기술적 합의를 해야 하기 때문에 이익을 얻을 수 있으며, uCDN은 그렇게 광범위한 CDN을 배치할 필요가 없기 때문에 이익을 얻을 수 있으며, dCDN은 약간의 보상을 받을 것이다.납품을 위해올바른 dCDN 선택, 대리인을 선택하는 절차와 알고리즘, 대리인에게 제출할 콘텐츠 획득 절차는 다를 수 있지만 dCDN은 uCDN을 대신해 콘텐츠를 서비스한다.

사용 사례

아래는 CDNI가 제시된 사용 사례의 불완전한 목록이다.[1]사용 사례는 표준화 접근법 사이에 수렴되는 것으로 보인다(표준화 상태 섹션 참조).

풋프린트 확장

풋프린트는 CDN이 콘텐츠를 제공할 수 있는 영역으로 정의된다.CDNI가 구축되면 비 글로벌 CDN 제공업체는 CSP에 확장된 지리적 발자국을 제공할 수 있다.

  • 전달 품질을 저하시킬 수 있다.
  • 콘텐츠를 지리적으로 또는 지형적으로 멀리 떨어진 대리점에서 제공하려는 경우 추가 운송 비용
  • 높은 투자 비용과 낮은 배송량 등 해당 지역에서 정당화되지 않은 대리인을 배치하고 운영한다.

상호접속은 다양한 위치에서 많은 CDN을 소유하고 상호운용 가능하도록 만들기를 원하는 대규모 CDN 제공자에게 매력적일 수 있다.

CDNI 설치 공간 확장은 CDN 제공자들이 소수의 ISP의 네트워크에 많은 인기 콘텐츠를 제공하는 사례에도 이롭다.만일 그렇다면, 그러한 CDN의 상호연결이 최종 사용자에게 QoS와 QoE의 개선, ISP의 네트워크의 수신 트래픽의 감소 및 제어, uCDN의 하드웨어 용량과 설치 공간 감소, ISP가 어느 정도 수익을 창출할 수 있도록 할 것이다.

또한, 상호연결된 네트워크는 유목민 최종 사용자가 다양한 기기 및/또는 지리적 지역에 걸쳐 일관된 QoE로 콘텐츠에 접근할 수 있도록 할 수 있다.

오프로드

CDNI는 예기치 않게 급증하는 트래픽(예: CDN을 치수화한 최고점을 초과하는 플래시 군중)을 uCDN과 dCDN 사이에 분산시킬 수 있기 때문에 과부하 처리 시 매우 유용할 수 있다. CDN이 리소스를 공유하면 치수 절감을 통해 이익을 얻을 수 있다.이러한 메커니즘이 제대로 작동하기 위해 uCDN은 오프로드할 수 있는 트래픽 양에 대해 dCDN으로부터 실시간으로 정보를 요구한다.유지보수 또는 특별 이벤트 배포와 같은 계획된 이벤트의 경우 정적 리소스 예약으로 충분할 수 있다.

또한 CDNI는 콘텐츠 제공 및 획득 실패에 대한 복원력을 제공한다.CSP의 대리인과 오리진 서버를 사용할 수 없는 경우, 배포하면 배달 요청이 다른 CDN으로 리디렉션될 수 있다. 마찬가지로, 배포된 CDNI와 마찬가지로 기본 획득 소스가 실패하는 경우, 상호 접속 내의 다른 소스(예: 대체 uCDN)를 사용할 수 있다.이는 결과적으로 콘텐츠 획득 소스 간의 로드 밸런싱을 제공한다.

역량

CDNI는 CDN이 지원할 수 없거나 CDN 공급자가 제공할 의사가 없는 경우 지원되는 범위의 장치와 네트워크 기술을 확장하는 수단이 될 수 있다.예를 들어 CDN 제공자는 HTTP 스트리밍 및/또는 IPv4만 지원하면서 HTTP Adaptive streaming 및/또는 IPv6까지 서비스 포트폴리오를 확장하기를 원할 수 있다.이 확장은 요청된 프로토콜을 제공할 수 있는 CDN과 상호 연결함으로써 실현될 수 있다.마찬가지로 상호연결은 유선 CDN 제공자가 자신의 서비스를 모바일 장치로 확장할 수 있게 할 수 있다.

CDN 제공자가 다른 기술에서 많은 네트워크를 실행하거나, 멀티벤더 전략을 수립하거나, 많은 CSP를 위해 별도의 네트워크를 구축하는 경우, 상호연결이 CDN 간 운영을 단순화하거나 자동화함으로써 기술 및 벤더 상호운용성을 완화할 수 있다.

또 다른 사용 사례는 CDN 제공자의 QoS와 QoE의 개선일 것이다. 만약 최종 사용자에 더 가까운 대리 네트워크와의 상호연결 옵션이 존재한다면 말이다.

CDNI의 인터페이스

IETF(Internet Engineering Task Force) (표준화 상태 섹션 참조)는 그림 2와 같이 기술적 관점에서 CDN 쌍을 상호 연결하는 데 필요한 5개의 인터페이스를 정의한다.인터페이스는 새로운 프로토콜(예: HTTP)을 정의하기 보다는 기존 프로토콜(예: HTTP)을 재사용하거나 활용하는 것을 목표로 하는 애플리케이션 계층에서 작동하는 제어면 인터페이스다.CDNI의 이 모델은 오늘날 CDN은 HTTP, FTP, rsync 등과 같은 표준화된 프로토콜을 이미 사용하고 있기 때문에 컨텐츠 획득, 전달, 요청 인터페이스 및 메커니즘을 정의하지 않는다.상호연결을 통해 선, 망사 또는 시작 위상과 같은 다양한 위상으로 CDN을 연결할 수 있다.CDNI를 구축하기 위해서는 CSP와 uCDN 사이에, uCDN과 dCDN 사이에 추가적인 사업 협정이 수립되어야 한다는 점에 유의해야 한다.이 문서 작성 당시 인터페이스의 세부 운영과 교환 물체의 구조는 표준화 과정 하에 있다.[2][3][4][5][6][7][8]정의된 인터페이스는 다음과 같이 간략하게 설명된다.

A CDNI model as defined by the IETF.
IETF에 의해 정의된 CDNI 모델.

제어 인터페이스(CI)

CI는 두 개의 CDN과 다른 CDNI 인터페이스 부트스트랩을 통해 상호연결을 시작하도록 설계되었다.예를 들어, 제어 인터페이스는 로깅 인터페이스를 부트스트랩하기 위해 로깅 서버의 주소를 제공하는 데 사용될 수도 있고, 다른 인터페이스에 대한 보안 연결을 설정하는 데 사용될 수도 있다.또한 uCDN이 dCDN의 메타데이터와 콘텐츠를 전치, 재검증 또는 숙청할 수 있도록 할 수 있다.

요청 라우팅 리디렉션 인터페이스(RI)

지정된 사용자 요청에 대한 전송 dCDN을 리디렉션하고 선택하십시오.이 인터페이스는 제공된 요청에 대한 루프 방지 및 탐지 메커니즘을 제공한다.

FCI(풋프린트 및 기능 광고 인터페이스)

이후 사용자 요청에 대한 dCDN 선택을 지원하기 위해 기능 및 설치 공간에 대한 라우팅 정보의 비동기식 교환 가능.RI와 FCI 인터페이스의 결합은 요청 인터페이스를 나타낸다.

메타데이터 인터페이스(MI)

dCDN이 uCDN에서 컨텐츠 메타데이터를 제공할 수 있도록 허용.메타데이터에는 필요한 권한 부여, 지역 차단, 가용성 창 및 위임 화이트 및 블랙리스트에 대한 정보가 포함될 수 있다.예를 들어 이 정보는 특정 국가에 대한 분포를 제한하거나 성인용 콘텐츠를 심야 시간에만 사용할 수 있도록 할 수 있다.수집된 메타데이터는 나중에 CDNI 리디렉션 및 사용자 컨텐츠 요청 응답에 사용된다.

로깅 인터페이스(LI)

상호연결을 통해 컨텐츠 배포 및 전달 활동 세부사항을 교환할 수 있도록 한다.실시간 교환은 트래픽 모니터링에, 오프라인 교환은 최종 사용자의 과금이나 상호 연결된 CDN 간의 과금 등에 사용할 수 있다.

다운스트림 CDN 선택 기준

dCDN의 선택에는 주로 그 설치 면적과 기능에 대한 정보가 사용된다.설치 공간은 IP 서브넷, 자율 시스템(AS) 번호 또는 국가, 주 및 코드 조합을 사용하여 지정할 수 있다.[9]이 기능은 CDN이 충족시킬 수 있거나 충족시킬 수 없는 특징, 서비스 및 상태를 설명하고 네트워크 및 관리 기능, 캐시 및 리소스에 대한 정보를 포함한다.네트워크 정보는 QoS 또는 지원되는 스트리밍 대역폭에 대한 세부사항을 공개할 수 있다.행정 역량은 설정된 한계와 정책에 대해 알려줄 수 있다.캐시에 대한 데이터는 부하와 가용 자원에 대해 알려줄 수 있다.자원 정보에는 특정 장치 유형으로 비디오를 스트리밍하는 기능과 같이 지원되는 전송 기술 및 콘텐츠 유형이 명시될 수 있다.

uCDN은 풋프린트와 기능에 대한 정보를 고려할 때, 처음에는 풋프린트에 기반한 다음, 다음에는 기능에 기반한 dCDN의 초기 선택을 진행할 수 있다.그러나 그러한 절차들은 차선책정 또는 잘못된 결정으로 이어질 수 있다. 예를 들어, dCDN을 풋프린트에 기초하여 선택할 경우, 요청된 전달 기술을 제공할 수 없다.따라서 좀 더 승인된 절차에는 설치 공간 정보를 기능 요건의 일부로 만드는 것이 포함된다.

다양한 프로토콜은 BGP와 같이, HTTP와 같은 기능에 대한 정보 교환이나, 애플리케이션 계층 트래픽 최적화(ALTO)와 같은 풋프린트와 기능에 대한 정보 교환을 위해 고려된다.[10]

CDN의 컨텐츠 요청 리디렉션

사용자 요청 리디렉션의 경우, 그 중에서도 주로 HTTP와 DNS 리디렉션의 두 가지 메커니즘이 CDN에서 사용된다.

HTTP 방법은 방문할 새 URL을 포함하는 HTTP 리디렉션 응답(예: 302)을 사용한다.새 URL에서 서버 이름을 변경하는 옵션 외에 URL에는 원래 서버의 이름이 포함될 수 있어 대역 내 통신 수단을 제공한다.또한 리디렉션 메커니즘은 대상 대리 선택을 위해 클라이언트의 IP 주소, 요청된 콘텐츠 유형 또는 사용자 에이전트에 대한 정보를 사용할 수 있다.불행히도 URL의 도메인을 변경하면 웹 브라우저가 쿠키를 보내지 않을 것이다.

DNS 리디렉션은 HTTP 방법에 비해 최종 사용자에게 완전히 투명하다.단순 DNS 리디렉션에서 이름에 대한 권한 있는 DNS 서버는 클라이언트의 특성에 따라 IP 주소를 반환한다.결과적으로 반환되는 IP 주소는 다른 요인 중에서도 최종 사용자의 로컬화 또는 대리 서버의 부하에 따라 달라진다.권한 있는 서버가 CNAME 응답을 반환하는 또 다른 DNS 리디렉션 방법이 있다.이로 인해 피어가 새 이름을 사용하여 이름 조회를 재시작해야 한다.캐시된 DNS 응답의 경우 리디렉션의 신선도를 유지하기 위해 Time-to-Live 매개 변수의 적절한 값을 설정한다.이 방법의 단점은 DNS 캐시가 최종 사용자의 IP 주소를 숨긴다는 것이다.

HTTP 및 DNS 기반 리디렉션 방법은 모두 반복적으로 또는 반복적으로 CDNI에서 수행할 수 있다.재귀적 리디렉션은 하나의 UE 리디렉션만 포함하지만 상호연결 실현에 대한 다른 의존성을 가지기 때문에 최종 사용자에게 더 투명하다.상호 연결된 CDN의 수가 2개를 초과하는 경우 단일 UE 리디렉션이 바람직할 수 있다.

컨텐츠 전달 시 CDNI 인터페이스의 모범적 작동

아래 그림에 제시된 시퀀스 다이어그램은 CDNI 및 반복 DNS 리디렉션 작업에 대한 몇 가지 세부사항을 제공한다.표시된 예에서 UE는 주소에서 콘텐츠를 다운로드한다.주로 CDN-A가 주소 csp.com으로 CSP를 대신하여 제공하는 cdn.csp.com/foo,.

An example of iterative DNS redirection of content request in CDNI.
CDNI에서 컨텐츠 요청에 대한 반복 DNS 리디렉션의 예.
  1. 요청 리디렉션에 앞서 CDN-B(dCDN)는 지원되는 설치 공간 및 기능에 대한 정보를 발표한다.
  2. UE는 콘텐츠를 다운로드할 CSP의 도메인에 있는 서버 cdn.csp.com에 대한 DNS 조회를 수행한다.
  3. 도메인 cdn.csp.com을 서비스하는 CDN-A(uCDN)의 요청 라우터는 요청을 처리하고 요청의 소스 IP 주소를 기반으로 최종 사용자가 dCDN에 의해 더 나은 서비스를 받을 수 있음을 인식한다.따라서, 본 요청에 응할 의지와 능력이 있는지 판단하기 위해 dCDN에서 조사를 수행한다.
  4. dCDN이 요청을 처리할 수 있는 경우, uCDN의 요청 라우터는 DNS CNAME 응답을 반환한다.이 응답은 dCDN과 원래 도메인을 나타내는 새로운 도메인(예: b.cdn.csp.com)과 dCDN의 요청 라우터에 이 새 도메인을 매핑하는 NS 레코드를 포함한다.
  5. UE는 새로운 도메인(b.cdn.csp.com)을 이용하여 DNS 조회를 한다.dCDN의 요청 라우터는 적절한 전달 노드의 IP 주소로 이 요청에 응답한다.
  6. UE는 dCDN의 전달 노드로부터 컨텐츠 /foo를 요청한다.이 시점에서, 전달 노드는 UE의 실제 IP 주소와 요청된 콘텐츠에 대한 정보를 수신한다.이전 단계의 재조정이 잘못된 경우, 배달 노드는 HTTP 리디렉션을 수행할 수 있다.
  7. 컨텐츠 /foo에 대한 메타데이터를 dCDN에서 이용할 수 없는 경우, 메타데이터 인터페이스를 사용하여 uCDN에 요청한다.
  8. 요청이 제공되려면, 즉 메타데이터 제한이 충족되고 캐시 누락이 발생하는 경우, dCDN의 전달 노드는 취득 프로세스를 시작해야 한다.배달 노드는 내부 도메인 주소 op-b-acq.op-a.net에 대해 DNS 조회를 한다.uCDN은 요청이 UE가 아닌 dCDN에서 온 것임을 인식하고, uCDN에서 전달 노드의 IP 주소를 반환한다.
  9. 컨텐츠 /foo는 uCDN의 전송 노드로부터 dCDN의 전송 노드로 전달된다.
  10. 컨텐츠 /foo는 dCDN의 전달 노드로부터 UE로 전달된다.
  11. 일정 시간이 지나면 uCDN은 dCDN에 콘텐츠 /foo가 다시 전달되지 않도록 purge하도록 지시할 수 있다.
  12. 콘텐츠가 전달된 후 전송 작업 로그가 uCDN에 제공된다.

HTTP 적응 스트리밍

CDNI 규격에서 다루면, HTTP 적응 스트리밍(HAS)의 지원이 특히 실현된다.큰 물체는 작은 독립 덩어리로, 예를 들어 비디오와 같은 일련의 작은 독립 덩어리로 분해되는데, 이 덩어리들 사이에는 아무런 관계가 없는 것처럼 인식된다.결과적으로, 콘텐츠 획득과 청크 퍼지기는 킥크 단위로 수행된다.CDNI 로드를 줄이기 위해 규격은 상대적 균일 자원 로케이터(URL)를 허용하거나 HAS를 통해 배포된 자원의 매니페스트 파일에서 절대 URL을 수정한다.

보안

CDNI의 보안은 선택 사항이며, CDN의 기능으로 지원된다. CDNI의 보안에는 콘텐츠 기밀 보호, 인증된 동료 통신 및 데이터 원본 인증이 포함된다.CDN 간의 링크 신뢰성에 의문이 제기될 경우 데이터 원본 인증은 매우 중요하다.시큐러티는 CDNI에 구축된 프로토콜의 보안 버전(예: HTTPS)으로 전환하여 실시한다. 일반적으로 시큐어 프로토콜을 통해 CDNI를 구축하면 컨텐츠 취득 및 유통에도 시큐어 프로토콜이 활용된다.

보안과 관련된 추가적인 문제는 다른 국가에서 교환된 로그와 관련된 다양한 최종 사용자 개인 정보 보호 요구 사항 또는 CDN에서 배달 비용 충전을 위한 로그의 진위 여부일 수 있다.예를 들어, 제어 인터페이스의 손상은 다른 인터페이스를 손상시킬 수 있는 반면, 손상된 로깅 인터페이스는 충전 시 부정 행위를 가능하게 할 수 있다.

표준화 상태

IETF, ETSI(European Telecommunications Standards Institute), ATIS(Alliance for Telecommunications Industry Solutions) 및 OCEAN(Open Contentent Aware Networks, OCEAN)과 같은 많은 조직과 프로젝트가 CDNI 인터페이스 및 방법의 표준화를 진행 중이거나 진행 중에 있다.용어뿐만 아니라 정의된 인터페이스의 규격 사이에 불일치와 차이가 있다.

ETSI 규격은 3개의 CDNI 인터페이스를 설명한다[13].첫 번째 것, 상호접속 제어는 ETSI의 제어와 로깅 인터페이스의 결합을 지도화하는 것처럼 보인다.그 다음, 요청과 콘텐츠 제어는 ETSI의 요청 라우팅과 메타데이터 인터페이스의 결합을 차례로 맵핑하는 것으로 보인다.세번째는 콘텐츠 인터페이스의 유통이다.

OFEAN 프레임워크는 제안된 CDNI의 개방형 인터페이스와 프로세스를 철저히 명시한다.[14][15]이 문서는 추가 비즈니스, 취득 및 내부 메타데이터 인터페이스를 정의한다.또한, ETSI에 의해 정의된 메타데이터 인터페이스는 9개의 인터페이스를 가진 참조 모델을 야기하는 2개의 더 전문화된 인터페이스로 분할된다.

유료 ATIS 표준 및 기술 보고서는 CDNI에 대한 사용 사례 및 높은 수준의 요구사항을 정의한다.자유롭게 이용할 수 있는 추상화에 따르면, 이 규격들은 다른 측면들 중에서도, 두 개의 CDN 제공자들 사이에 콘텐츠를 분배하기 위한 수단으로 멀티캐스트를 사용하고 CDN 제공자들을 결합하기 위한 기초로서 두 개의 CDN 제공자들의 상호연결은 CDN 연합을 형성하기 위해 다룬다.[18]

참고 항목

추가 읽기

  • S. Puopolo, M. Latouche, F.르 포슈르, 그리고 J. 데포르.CDN(Content Delivery Network) 연합 SP가 컨텐츠에 굶주린 소비자를 위한 경쟁에서 이길 수 있는 방법, 2011년.
  • A. 파탄과 R.Buya. 컨텐츠 전달 네트워크의 분류 및 조사.기술 보고서, GRIDS-TR-2007-4, 그리드 컴퓨팅 및 분산 시스템 연구소, 호주 멜버른 대학교, 2007년 2월.

참조

  1. ^ a b G. 버트랜드, E. 스테판, T. 버브리지, P. 고막리, K. 마, G.왓슨컨텐츠 전달 네트워크 상호 접속의 이용 사례.RFC 6770(정보), 2012년 11월.
  2. ^ a b L. 피터슨과 B.Davie. CDN 상호접속 프레임워크. 초안-ietf-cdni-framework-06(Active Internet-Draft), 2013년 10월.
  3. ^ B. 니븐 옌킨스, F.르 포슈르와 N. 비타르.CDNI(Content Distribution Network Interconnect) 문제 성명.RFC 6707(정보), 2012년 9월.
  4. ^ F. Le Faucher, G. Bertrand, I. Oprescu, R.피터코프스키CDNI 로깅 인터페이스. 초안-ietf-cdni-loging-08(Active Internet-Draft), 2013년 10월.
  5. ^ K. 렁과 Y. 리.CDNI(Content Distribution Network Interconnect) 요구사항. 초안-ietf-cdni-requirement-11(Active Internet-Draft), 2013년 10월.
  6. ^ R. 머레이와 B.니븐 옌킨스CDNI 제어 인터페이스 / 트리거. 초안-ietf-cdni-cdni-control-트리거-01(Active Internet-Draft), 2013년 10월.
  7. ^ B. 니븐-젠킨스, R. 머레이, G. 왓슨, M. 콜필드, K. 렁, K.Ma. CDN 인터커넥트 메타데이터. 초안-ietf-cdni-metadata-03(Active Internet-Draft), 2013년 10월.
  8. ^ 단화. 왕, B.니븐 옌킨스, 샤오얀.그, 첸.Ge, Wei.Ni. CDN 인터커넥션을 위한 라우팅 리디렉션 인터페이스 요청. 초안-ietf-cdni-redirection-01(Active Internet-Draft), 2013년 10월.
  9. ^ J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K.Ma. CDNI 요청 라우팅:풋프린트와 기능 의미론. 초안-ietf-cdni-footprint 기능-semantics-01(Active Internet-Draft), 2013년 10월.
  10. ^ E. 스테판과 S.엘루즈.CDN 인터커넥션을 위한 ALTO 세션. 초안-단계-cdni-alto-session-ext-04(Active Internet-Draft), 2013년 10월.
  11. ^ R. van Brandenburg, O. van Deventer, F.르 포슈르, 그리고 K.렁. HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnect(CDNI) 모델. RFC 6983(정보제공), 2013년 7월.
  12. ^ 미디어 컨텐츠 배포(MCD), CDN 상호 접속, 사용 사례 및 요구 사항.기술 보고서, ETSI, 2012.TS 102 990.
  13. ^ CDN 상호접속 구조기술 보고서, ETSI, 2013.TS 182 032.
  14. ^ D3.1 OHEAN 기능 아키텍처 및 개방형 인터페이스 규격.Ocean, 2012년 기술 보고서.
  15. ^ D2.2 Open Content Awaren Networks의 제공 가능한 최종 요구사항Ocean, 2013년 기술 보고서.
  16. ^ CDN 상호접속 사용 사례 규격 및 상위 수준 요구 사항.ATIS, 2011년 기술 보고서.ATIS-0200003
  17. ^ CDN 상호접속 활용 사례 및 멀티캐스트 기반 콘텐츠 배포 요건ATIS, 2012년 기술 보고서.ATIS-0200004
  18. ^ CDN 상호접속 사용 사례 및 다당연방 환경의 요구사항ATIS, 2012년 기술 보고서.ATIS-0200010.

외부 링크