CDNI - RFC 6707 翻譯

　　　　　　　　　　　　　　　　　　CDNI的相關問題陳述

概述
CDN對可緩存內容提供了許多好處：下降交付成本，提升終端用戶體驗，提升交付的魯棒性。對於這些因素，CDN常
用於大規模的內容交付。所以，現有的CDN提供商正在擴大規模，許多網絡服務提供商(NSP)也在部署他們本身的CDN。
通常來講，一個給定的內容項能夠被分發給終端用戶，而不考慮終端用戶的地理位置或者附屬網絡。這個就是鏈接獨立
CDN的動機，這樣每一個CDN就能夠在內容服務提供商(CSP)和終端用戶的端到端操做之間做爲開放的內容交付設施進行互相
操做。然而，當前沒有開放的說明或者標準來促進這種CDN之間的互聯。

1. 介紹
大量的視頻和多媒體內容傳輸在互聯網上迅速增加，預計在將來會持續如此。面對這樣的增加，CDN對可緩存的內容提供
了大量的益處：下降交付成本，提升終端用戶體驗，提升交付的魯棒性。對於這些因素，CDN經常使用於大規模的內容交付。
所以，現有的CDN提供商正在擴大規模，許多網絡服務提供商(NSP)也在部署他們本身的CDN。

通常來講，一個給定的內容能夠被分發給終端用戶，而不考慮終端用戶的地理位置或者附屬網絡。然而，一個特定的CDN
對於其負責分發給定的內容，可能這個CDN的擴展範圍離用戶的位置或者附屬網絡不夠近，或者沒有用戶須要的資源，來
實現用戶的體驗和更加分佈式CDN設施能夠接受的成本。這個就是鏈接獨立CDN的動機，這樣集合的CDN範圍和資源能夠促進
CSP和終端用戶的的端到端的內容交付。做爲一個例子，CSP能夠和權威的CDN簽定受權來分發其內容，以後權威CDN能夠和
其餘的一個或多個下游CDN簽定受權來表明權威CDN分發交付部分或者所有內容。

一個典型的端到端內容交付方案涉及如下的業務流程：
-CSP和EU之間的業務處理，CSP控制終端用戶對內容的訪問受權。
-CSP和受權CDN之間的業務處理，CSP託管CDN表明CSP進行內容分發。
-權威CDN和其餘CDN之間的業務，權威CDN能夠把實際的服務內容分發請求受權給其餘CDN。一個特殊的狀況是這個被
受權的CDN也是提供終端用戶訪問網絡的網絡服務提供商，這種狀況爲了相符的網絡訪問，在終端用戶和NSP之間也
有分開和獨立的業務關係。

CSP和CDN，CDN和CDN之間的業務構成和細節不在本文檔的範圍內。然而，從技術角度來講，這個文檔涉及到當前沒有公開
的說明或標準來促進CDN之間的互聯。

一個可能的CDN之間的端到端內容傳遞流程描述以下：
-受權CDN首先收到來自終端用戶的初始內容請求。
-受權(上游)CDN可能直接讓本身來服務，或者選擇使用CDNI來把請求重定向到位置更合適的下游CDN(例以下游CDN更
接近終端用戶)。
-終端用戶收到權威CDN的重定向響應後，向下遊CDN發起請求。若是須要，下游CDN會從權威CDN獲取用戶要請求的內
容，若是必要的狀況下，權威CDN還會從CSP獲取用戶要請求的內容。(//例如內容要求實時，或者內容過時)

本文檔的目標是歸納CDNI的問題領域。第2節討論了CDNI的使用案例。第3節描述了IETF考慮到的CDNI模型和問題領域。
第4節單獨描述了每一個CDNI接口，突出的實例候選協議來考慮做爲重用或者促進實現CDNI接口。附錄B.2描述了CDNI問題
範圍和其餘相關的IETF工做組和IRTF研究小組的關係。

1.1 術語
本文檔使用下列術語：

權威CDN:與CSP有直接關係的CDN，權威CDN或者權威CDN的下游CDN對該CSP的內容進行分發和傳遞。

互聯CDN(CDNI):一對CDN之間的關係，使得一個CDN能夠表明兩一個CDN提供內容分發服務。CDNI能夠徹底或部分地經過
一系列的接口在一對CDN之間進行通訊實現，爲了實現一個CDN表明另外一個CDN對用戶交付內容。

CDN提供者：操做CDN而且提供內容分發服務的服務提供者，一般被CSP或者另外一個CDN提供者使用。注意一般一個實體能夠
做爲多個角色運行。例如，一個公司能夠同時做爲一個CSP、NSP和CDN。

CDNI元數據：內容分發元數據的子集具備跨CDN的範圍。例如CDNI元數據能夠包含地理封鎖消息(即定義內容能夠被使用或
者阻止的地理區域)，窗口可用性(即定義內容能夠被使用或者阻止的時間窗口)和強制執行的訪問控制機制(例如URL簽名
驗證)。CDNI元數據還可能包含指望的分發策略信息(例如預約位、動態採集)和一個CDN能夠從哪裏、用哪一種方式獲取內容。

內容：任何形式的數字數據。一種在分發和傳遞之間附加的額外限制組成的內容方式是連續媒體(即數據進出之間的時間關係)。

內容分發元數據：內容分發元數據的子集和分發的內容有關。這是一個CDN爲了啓用和控制內容分發的元數據，而且由CDN傳遞。
在CDNI環境中，一些內容分發元數據可能具備CND內的範圍(所以這些數據不須要在CDN之間進行通訊)，而一些內容分發元數據
可能有跨CDN的範圍(所以須要在CDN之間進行通訊)。

CDN:在4到7層之間網絡單元協做，對用戶進行更加有效的內容交付的網絡設施。一般，一個CDN包括一個請求路由系統，一個
分發系統(包括一組代理服務器)，一個日誌系統，和一個CDN控制系統。

內容元數據：關於內容的元數據。內容元數據包括：
1.與內容分發相關的元數據(所以涉及到一個CDN對該內容的傳遞)。咱們將這種元數據成爲"內容分發元數據"。能夠查看
"內容分發元數據"的定義。

2.元數據和實際內容或者內容表述相關聯，而和內容的分發沒有關聯。例如，這種元數據可能包含內容的流派、演員、等級
等相關信息。或者和內容的分辨率、屏幕比例相關的表示信息。

內容服務：CSP提供的服務。內容服務包括完整的服務，不只僅是提供內容項的訪問;例如內容服務還包括任何中間件、密鑰分發
、程序指南等等。這些可能不須要和CDN參與內容的分發和傳遞而和CDN有任何直接交互。

CSP:對終端用戶提供內容服務(經過用戶代理訪問)。一個CSP可能擁有內容服務的部份內容，或者從另外一方獲取的內容權利。

控制系統：CDN提供的包括自舉和控制CDN的其餘組件，處理外部系統的交互的功能(例如處理交付服務的建立/更新/刪除請求，
或者對特定的服務提供請求)。

交付：CDN代理向UA提供的一條內容的傳遞。例如，交付能夠基於HTTP漸進下載或者HTTP自適應流。

分發系統：CDN中負責分發內容分發元數據，也包括存在於CDN中的內容自身的功能。

下游CDN：對於給定的終端用戶請求，由另外一個CDN(上游CDN)把請求重定向到的這個CDN(一對直接互聯的CDN中的一個)。注意在
連續的重定向中，一個給定的CDN能夠當作下游CDN，也能夠當作上游CDN。(例如CDN1-->CDN2-->CDN3,其中的CDN2就是這種狀況)

動態CDNI元數據的採集：在CDNI上下文中，動態CDNI元數據採集表示在內容的請求被上游CDN受權給下游CDN的這個時間點，下游
CDN從上游CDN獲取內容的CDNI元數據(而且在下游CDN中，這個CDNI元數據當前還不可用，當前若是可用就不用進行動態獲取了)
。能夠查看下游CDN和上游CDN的定義。

動態內容採集：動態內容採集表示一個CDN從內容源獲取終端用戶請求的內容。在CDNI上下文中，動態獲取表示一個下游CDN在
一個內容的請求被上游CDN受權給下游CDN的這個時間點，從內容源(包括上游CDN)獲取內容(而且在下游CDN中，這個內容當前還
不可用)。

EU:系統中真實的用戶。一般是一我的，也多是硬件和軟件結合模擬的一我的(例如自動化測試)。

日誌系統：CDN收集測量和記錄分發和傳遞活動的功能。日誌系統的記錄信息被用來各類做用，包括控訴(例如用於CSP)，分析和
檢測。

元數據：元數據通常是關於數據的數據。

NSP：提供給終端用戶網絡鏈接服務的提供商。

OTT：一種服務，例如，使用CDN進行內容交付，由不一樣於運營商的NSP的運營商運營，該服務已附加。

CDNI元數據採集的預約位：CDNI上下文中，CNDI元數據預約位就是下游CDN在內容以前，或者在沒有任何終端用戶請求該內容時
，自主地獲取CDNI元數據。

內容採集預約位：內容預約位就是一個CDN在終端用戶請求該內容以前，或者自主地從內容源獲取內容。在CDNI上下文中，上游
CDN在終端用戶請求以前，或者主動通知下游CDN從內容源(包括上游CDN)獲取內容。

QoE:2.4節定義。

請求路由系統：CDN負責的功能，即CDN收到UA的內容請求，獲取和維護一組候選代理節點或者候選CDN的重要信息，而且選擇一
個合適的代理或者CDN，把用戶重定向到那裏。爲了實現CDNI，請求路由系統必須支持UA從另外一個CDN重定向過來內容請求。

代理：一個設備(一般稱爲緩存)，配合CDN中的其餘元素，在CDN中進行內容分發而且與UA配合完成內容交付。一般，代理會緩存
請求的內容，所以能夠對多個UA的一樣請求直接發送內容，避免了內容在網絡中被屢次傳輸。

上游CDN：對於給定的終端用戶請求，把這個請求重定向到另外一個CDN的這個CDN就是上游CDN。

UA：終端用戶使用的內容服務的軟件。例如瀏覽器，機頂盒，媒體播放器等等。

1.2 CDN背景

假設讀者熟悉CDN的架構、特徵和操做。對於不熟悉CDN操做的讀者，下面的資源可能有用：
-RFC3040描述了CDN構建中的許多組件技術。
-分類中比較了多個CDN的體系結構。
-RFC3466和RFC3570是IETF的CDI工做組輸出的文檔，而且在2003關閉。

注意：本文檔的一些術語和上面相關文檔的術語相似，閱讀這個文檔時，這些術語應該解釋爲1.1節中的定義。

2. CDNI使用案例

隨着視頻業務以及其餘內容交付應用的日益增加，面對成本效益愈來愈多的NSP在部署CDN。

CDN容許在網絡邊緣服務器緩存內容，所以對於給定的內容能夠被CDN代理分發給多個UA，而不用在網絡中屢次傳送。這有助於
下降帶寬成本和提升用戶體驗。CDN也用於多個代理複製熱門內容，使得能夠同時服務於大量用戶。這也幫助了處理突發訪問
和拒絕服務攻擊的狀況。

NSP部署的CDN不只僅受限於NSP支持的自身的內容交付服務，例如電視服務的機頂盒，也用於其餘設備的內容交付，包括PC，平
板，手機等等。

一些服務器提供商在多個地理位置和多個NSP之間運做，這些NSP一般在獨立的CDN之間運做。他們發展本身的服務(例如用戶跨越
附屬的NSP時內容服務的無縫支持)，這樣就須要互連這些CDN;這是CDNI的第一個使用案例。然而，並無公開的規範，也沒有共
同的最佳實踐，定義如何實現這樣的CDN互連。

CSP指望他們的內容能夠被大量的用戶訪問到，這些用戶一般分佈在不一樣地理位置，在保持高質量體驗的同時，不須要這些CDN
提供商保持直接的業務關係(或者擴大當前已有的CDN)。一些NSP正在考慮互連他們各自的CDN，以便這種集體設施能夠知足CSP的
成本效益。這表明了CDNI的第二種使用案例。特別的，這將使CSP受益於在網的交付(即當前NSP擁有的網絡/CDN網點)，不須要CS
P維護全部CDN之間的直接業務關係。再次，CDN提供商(NSP或者頂級CDN運營商)面臨缺乏公開的規範和最佳實踐。

NSP常常在特定的服務或環境部署CDN做爲專用的下降成本的項目。一些NSP爲獨立的服務使用獨立的CDN，例如，可能有一個負責
管理IPTV服務交付的CDN，一個web-TV交付的CDN，和一個向移動終端提供視頻交付的CDN。當NSP須要整合他們的業務時，須要互
連這些CDN，這是CDNI的第三種使用場景。再次，NSP面對着CDN互連的開放接口的缺少。

因爲操做緣由(例如災難，攻擊)或者商業因素，一個頂級CDN可能選擇另外一個CDN(例如一個NSP CDN在線代理)服務用戶請求的子
集(例如用戶的請求附屬於那個NSP)，這是CDNI使用的第四個場景。而且CDN提供商(頂級CDN或者NSP)面臨缺乏公開的規範和最佳
實踐。

CDNI-USE-CASES更深刻的討論了CDNI的使用場景。

3.CDNI模型和IETF的問題區域

這一節討論了IETF在CDNI的問題區域。

互連的CDN在每一個CDN之間涉及到多個不一樣的功能和組件。只有其中一些須要IETF進行額外規範。

一些NSP開始試驗探索是否他們本身的CDN用例能夠用現有的CDN解決，一組這樣的試驗在CDNI-EXPERIMENTS文檔中。這些試驗的
結論是互連CDN一些基本的限制能夠在當前已有的CDN技術中實現，目前缺少的是必要級別的功能沒有標準化的CDNI接口，諸如
本文檔討論的，這阻礙的CDNI的部署。

下面列出的是在一對CDN之間所需的四個接口，構成了CDN互連問題，每一個接口的功能需求，這是當前沒有的標準。做爲CDNI接口
發展的一部分，在CDN互連之間，有必要在識別和命名數據對象的公共機制上達成一致。

術語「接口」的使用意味着包含該協議經過哪一個CDNI數據表示(例如，CDNI元數據對象)交換以及數據的規範表示自己(即每一個對象
有哪些屬性/字段包含，其結構等)。

-CDNI控制接口：該接口容許"CDNI Control"系統在互連的CDN之間通訊。這個接口可能支持如下：
*容許引導其餘CDNI接口(例如接口地址/URL的發現和安全鏈接的創建)。
*容許配置其餘CDNI接口(例如上游CDN指定經過CDNI日誌接口上報的信息)。
*容許下游CDN對於交付能力和策略這些靜態信息進行通訊。
*容許引導CDN之間的內容採集接口(即便這個接口在CDNI工做範圍以外)。
*容許上游CDN對下游CDN進行啓動或者請求特殊的動做。例如，容許上游CDN發起採集內容或者CDNI元數據，或者向下遊CDN
請求清除文件內容和CDNI元數據。

-CDNI請求路由接口：這個接口容許請求路由系統在互連的CDN中通訊，保證終端用戶的請求能夠被上游CDN重定向到下游CDN的代
理服務器，特別的，這個選擇的責任可能跨多個CDN(例如，上游CDN須要有選擇下游CDN的責任，下游CDN須要有選擇代理的責任)
。特別的，CDN路由請求接口的功能被劃分爲如下：
*一個CDNI請求路由重定向接口，在請求重定向到下游CDN之間，容許上游CDN查詢下游CDN。
*CDNI網點&能力通告接口，容許下游CDN向上遊CDN提供(靜態或動態)信息(例如資源，網點，負載)，來使上游CDN處理一系
列的UA請求時，幫助選擇合適的下游CDN。

-CDNI元數據接口：這個接口容許在互連CDN的分發系統通訊，保證CDNI元數據能夠在CDN之間交換。1.1節定義了CDNI元數據。

-CDNI日誌接口：這個接口容許互連CDN的日誌系統通訊，這將容許日誌處理程序運行在多CDN環境。例如，一個上游CDN能夠爲了
執行對CSP的統一記帳或者對多個CDN的結算的目的而從下游CDN收集分發日誌。相似的，一個上游CDN爲了向CSP提供統一的報告
和檢測向下遊CDN收集分發日誌。

注意當前階段是試驗性考慮，根據功能性對四個接口進行分組，這可能在之後的研究以後改變(例如一些功能子集可能從一個接
口轉移到另外一個接口)。

上面列出了一個潛在的問題空間，某種程度上由於爲了鏈接兩個CDN，有一些'接觸點'須要標準化。然而，當前指望CDNI接口不
須要從頭開始定義，而是能夠在很大程度上重用或利用現有協議;這個在第4節討論。

造成CDNI問題區域的接口如圖1所示。

 

如圖1所示，CDN互連之間的內容獲取不在CDNI的範圍；這值得作一些額外的解釋。這樣的決定是本文檔描述的CDNI問題空間僅專
注於定義CDNI的控制平面，所以CDNI數據平面(即實際內容對象的獲取和分發)已經超出本文檔範圍。這樣一個合理的決定是今天
的CDN一般已經使用標準化的協議，例如HTTP,FTP,rsync等來從他們的CSP客戶那裏獲取內容，而且預計互連CDN可使用相同的
協議來獲取內容。所以，內容的獲取已經被認爲解決，而這一切都須要聽從CDNI工做組用CDNI元數據獲取內容制定的規範，描述
了用於檢索內容使用的參數-例如，鏈接IP地址/主機名時，使用什麼協議來檢索內容等等。

4.肯定CDNI問題的範圍

本節概述了CDNI問題空間的工做範圍，在約束條件下如何經過重用或利用現有協議來實現CDNI接口。這個討論並不打算取代任何
工做組的決定做爲更適合的協議、技術和解決方案來選擇實現CDNI接口，可是意圖用一個事實的例證來講明CDNI接口不必從頭
開始建立，並且重用和利用現有的協議是可能的。

第3節在CDNI問題區域內描述了四個CDNI接口(CDNI控制接口，CDNI請求路由接口，CDNI元數據接口，CDNI日誌接口)，這些控制
平面的接口工做在應用層(OSI網絡中的第7層)。首先，這些接口和其餘的許多現有的網絡應用想比，不指望展示獨特的會話、傳
輸或者網絡需求，而是指望CDNI接口能夠定義在現有會話、傳輸、網絡協議之上。

其次，儘管能夠針對CDNI設計一個新的應用協議，咱們下面的分析說明了這是不必的，而且建議經過重用或利用現有的應用協
議(例如，HTTP協議[RFC2616]，XMPP協議[RFC6120])來實現CDNI接口。

4.1 CDNI控制接口

CDNI控制接口容許互連CDN的控制系統進行通訊。目前CDNI控制接口須要支持的精確的iner-CDN控制功能，相比其餘三個CDNI接
口定義的不太完善。

預計對於控制接口，對於其餘CDNI接口，現有的協議能夠被重用或利用。

4.2 CDNI請求路由接口

CDNI請求路由接口可使上游CDN向下遊CDN查詢一個路由功能，來判斷下游CDN是否能夠(願意)接受受權的內容請求。同時也允
許下游CDN在上游CDN的請求路由功能的重定向消息中，控制如何給UA響應。

所以，CDNI請求路由接口是一個至關直接的請求/應答接口，而且能夠在許多請求/應答協議上面實現。例如，可使用經常使用的We
bService方法來實現一個WebService(XML-RPC，已知URI的HTTP請求等等)。這去除了CDNI工做組爲CDNI請求路由接口定義一個新
的請求/應答協議的需求。

此外，正如第3節討論的，CDNI請求路由接口也指望用來下游CDN向上遊CDN提供信息(靜態或動態信息，例如資源、網點、負載)
，當處理後續UA的內容請求時，以便於幫助上游CDN的請求路由系統選擇下游CDN。預計CDNI請求路由功能能夠由CDNI工做組經過
充分利用現有的支持動態分配或者信息可達性(例如，利用現有的路由協議)，或者支持應用層級的拓撲信息查詢(例如，利用應
用層的流量優化(ALTO)[RFC5693])的IETF協議來制定。

4.3 CDNI元數據接口

CDNI元數據接口使下游CDN的分發系統向上遊CDN請求CDNI元數據，以便下游CDN能夠正確處理和響應從CDNI請求路由接口收到的
重定向請求、直接從UA收到的內容請求。

所以CDNI元數據接口和CDNI請求路由接口相似，由於這是一個請求/應答接口，而相對於請求路由重定向請求的直接性，CDNI元
數據搜索可能有更復雜的語法所以會有潛在的附加選項。所以，與CDNI請求路由接口同樣，CDNI元數據接口可能使用經常使用的WebS
ervices方法實現成一個WebService(XML-RPC，已知URI的HTTP請求等等)，或者使用其餘現有協議例如XMPP[RFC6120]。這去除了
CDNI工做組爲CDNI元數據接口定義一個新的請求/應答協議的需求。

4.4 CDNI日誌接口

CDNI日誌接口使得在互連的CDN中交換內容分發的詳細信息和交付活動-例如，交換內容交付的相關日誌記錄，相似web server的
access log日誌記錄。

已經存在的一些協議可能被用來互連CDN交換CDNI日誌，包括SNMP，syslog，FPT，HTTP POST等等。

5. 安全考慮

CDN的內容分發帶有一系列的安全考慮，例如如何在CSP的策略中強制控制EU的內容訪問權限，或者如何信任對CSP的計費目的時
由CDN生成的日誌信息。這些安全方面已經由當前的CDN提供商和CSP的獨立CDN解決。然而，CDN之間的互連經過擴展信任模型到
信任鏈引入了一組新的安全考慮(即CSP信任一個CDN，以後"信任"到其餘CDN)。該機制用來在多CDN環境中下降風險，可能相似於
當前的獨立CDN，可是在這種更復雜的環境中必須驗證可用性。

CDN的互連可能須要對獨立的CDN引入額外的隱私考慮。在一個多CDN的環境中，不一樣的CDN可能屬於不一樣的法律制度，須要執行不
同的隱私需求。這種隱私需求可能會影響CDNI接口交換的信息粒度。例如，下游CDN的日誌系統可能須要在交換包括EU交付詳細
日誌時，使用一些程度的匿名、混淆或者徹底刪除一些字段，而後給上游的CDN。

維護內容自己的安全性，與其向關聯的元數據(包括交付策略)，和CDN之間的分發、交付中的安全性，這些對於CDN提供商和CSP
是相當重要的要求，而且CDN互鏈接口必須提供足夠的機制來維護互連CDN整個系統和任意互連CDN之間信息(內容，元數據，日誌
等等)分發交付的安全。

5.1 CDNI控制接口的安全性

互連CDN經過此接口的信息交換具備敏感性。一對CDN使用這個接口來引導其餘的全部CDNI接口，可能包括創建這些接口的安全機
制。所以，該接口的故障可能會影響其餘的全部接口。上游CDN可使用該接口向下遊CDN預約位或刪除內容或者元數據，一個下
遊CDN能夠向上遊CDN提供管理信息等等。全部這些操做須要保證各個CDN被適當的認證、具備保密性、流動信息的完整性。

5.2 CDNI請求路由接口的安全性

該接口必須使用適當級別的認證和機密性，由於它爲了重定向請求容許一個上游CDN查詢下游CDN，反之，容許下游CDN影響上游
CDN的請求路由功能。

在這個接口沒有適當的安全性時，一個虛假的上游CDN能夠向下遊CDN發送虛假請求，或者讓下游CDN發送上游CDN的虛假隱私信息
。此外，一個虛假的下游CDN能夠影響上游CDN，讓上游CDN把請求重定向到虛假的下游CDN或者另外一個下游CDN，例如，獲取額外
的交付收入。

5.3 CDNI元數據接口的安全性

這個接口容許下游CDN向上遊CDN請求CDNI元數據，所以上游CDN必須保證在發送數據前前者已經被適當的認證過。相反，下游CDN
在請求元數據以前必須對上游CDN進行認證，以確保不會被虛假的上游CDN毒害。CDN之間的信息交換必須保證信息的保密性和完
整性。

5.4 CDNI日誌接口的安全性

日誌數據包含了潛在的敏感信息(EU請求的媒體資源，EU的IP地址，潛在的姓名和帳戶信息等等)。CDN之間移動這些信息必須保
證機密性。對於它能夠做爲跨CDN收費的基礎的觀點，這些信息也是敏感的。所以須要適當級別的保護來防止這些信息防止被損
害、複製和丟失。

6. 致謝

7. 信息參考

附錄 A. 實現CDNI接口的設計考慮

本節擴展了CDNI接口如何重用和利用當前存在的協議，在單獨描述每一個CDNI接口以前，考慮重用或利用示例候選協議實現CDNI接
口。然而，這裏討論的選項純粹是例子，並無提供任何稍後將使用的協議的共識。

A.1. CDNI控制接口

CDNI控制接口容許互連CDNI的控制系統進行通訊。目前CDNI控制接口須要支持的精確的iner-CDN控制功能，相比其餘三個CDNI接
口定義的不太完善。

然而，正如第3節討論的，CDNI控制接口可能須要支持如下相似功能：

-容許上游CDN和下游CDN進行創建、更新或者終止CDNI互連。
-容許引導其餘CDNI接口(例如，協議地址的發現和安全關聯的創建)。
-容許配置其餘CDNI接口(例如，上游CDN指定要經過CDNI日誌接口上報的信息)。
-容許下游CDN發送關於交付能力、資源和策略的靜態信息。
-容許引導CDN之間的內容獲取接口(即便該接口已超過CDNI的工做範圍)。

預計控制接口，對於其餘CDNI接口，能夠重用或利用現有的協議。當控制接口的需求完善後這些將被考慮。

A.2. CDNI請求路由接口

CDNI請求路由接口使得一個上游CDN的請求路由功能向下遊CDN的請求路由功能發起查詢，以決定是否下游CDN能夠(願意)接受授
權的內容請求和容許下游CDN控制上游的請求路由功能在重定向消息中應該如何響應UA(//下游CDN控制上游CDN響應UA的重定向消
息)。

所以，CDNI請求路由接口須要爲上游CDN提供一個上游CDN給下游CDN發送一個"重定向請求"的機制。請求路由接口須要支持在DNS和特定內容應用協議(例如HTTP，RTSP，RTMP等等)之上，上游CDN接收UA請求的初始請求這種需求。

所以，重定向協議預計包含如下信息：

-上游CDN接收UA的初始請求協議(例如DNS，HTTP)。
-UA請求的附加細節，以便下游CDN執行有效的請求路由。對於DNS，一般是DNS解析器的IP地址表明UA發送請求。對於在特定內容
應用協議之上收到的請求，重定向請求可能包含更多和原始UA請求相關的信息，至少指望包括UA的IP地址、和HTTP POST頭部相
當的內容、和HTTP絕對路徑至關的內容(定義在RFC2616)。

CDNI架構須要考慮下游CDN可能不首先收到上游CDN的重定向請求而是直接收到UA的請求，例如：

-用戶代理(或者DNS解析器)可能從請求的路由中緩存DNS或者響應。
-請求路由接口上面的重定向請求的響應多是可緩存的(//緩存了重定向請求的響應)。
-一些CDN可能依靠簡單粗暴的策略，錄入CDN B始終贊成服務CDN A受權的重定向請求，這種狀況下必要的重定向細節會在(CDNI
接口的)範圍外交換，例如配置。

收到重定向請求時，下游CDN將使用請求中提供的信息來決定是否能夠(且願意)接受受權的內容請求，而且須要對上游CDN返回決
定後的結果。

所以，下游CDN的重定向響應預計包括下列信息：

-表示接受或拒絕的狀態碼(可能包含相關的緣由)。
-容許上游CDN重定向的信息。這種狀況下基於DNS請求的路由，預計上游CDN應該返回給DNS解析器DNS記錄(例如CNAME記錄)。在
基於應用的路由請求狀況下，預計返回給UA包括構建特定應用重定向響應的必要信息。對於UA發出的HTTP請求，上游CDN能夠返
回一個含有URI的HTTP 3xx響應。

所以，CDNI請求路由接口是至關直接的請求/應答接口，而且能夠經過任何數量的請求/應答協議實現。例如，它可能使用經常使用的
WebServices方法實現成一個WebService(XML-RPC,對已知URI的HTTP查詢)。這去除了CDNI工做組爲CDNI請求路由接口定義一個新
的請求/應答協議的需求。所以，CDNI工做只剩下制定如下任務：

-使用推薦的請求/應答協議以及CDNI請求路由接口中制定的額外的語法和流程(例如，如何處理格式錯誤的請求/應答)。
-重定向請求和應答的語法(即表示/編碼)。
-重定向請求和應答的語義(即含義和預期內容)。 (//語法和語義，語法是定義表示或者編碼規則，語義是定義表示的含義)

另外，正如第3節討論的，CDNI請求路由接口還指望下游CDN向上遊CDN提供(靜態或動態)信息(例如資源、網點、負載)，以幫助
上游CDN請求路由系統處理一系列的UA內容請求時選擇下游CDN。預計這樣的CDNI請求路由功能能夠由CDNI工做組充分利用現有的
IETF中支持可達性信息的動態分配協議(例如，利用現有的路由協議)或者支持應用級別的拓撲信息請求(例如，利用ALTO)來制定。

A.3. CDNI元數據接口

CDNI元數據接口使得下游CDN的分發系統能夠從上游CDN獲取CDNI元數據，以便下游CDN能夠正確的處理和響應：

-經過CDNI請求路由接口收到的重定向請求。
-直接從UA收到的內容請求。

CDNI元數據接口須要對上游CDN提供一種機制：

-向下遊CDN分發/更新/刪除CDNI元數據。

而且/或者容許下游CDN：

-對CDNI元數據對象直接請求。
-對CDNI元數據進行遞歸請求-例如，可使下游CDN沿着具備內部對象關係的關係樹查詢。

所以CDNI元數據接口相似於CDNI請求路由接口，由於它是一個請求/應答接口。而相對於請求路由重定向請求的直接性，CDNI元
數據搜索可能有更復雜的語法所以會有潛在的附加選項。所以，就像CDNI請求路由接口，所以，與CDNI請求路由接口同樣，CDNI元
數據接口可使用經常使用的WebServices方法實現成一個WebService(XML-RPC，已知URI的HTTP請求等等)，或者使用其餘已有的協議
，例如XMPP[RFC6120]。這去除了CDNI工做組爲CDNI元數據接口定義一個新的請求/應答協議的需求。

所以，CDNI工做組只剩下制定如下任務：

-使用推薦的請求/應答協議以及CDNI元數據接口中制定的額外的語法和流程(例如，如何處理格式錯誤的請求/應答)
-該接口中交換CDNI元數據對象的語法(即表示/編碼)。
-該接口中交換CDNI元數據對象的語義(即含義和預期內容)。
-不一樣CDNI元數據對象表示的關係。

A.4 CDNI日誌接口

CDNI日誌接口使得在互連的CDN中交換內容分發的詳細信息和交付活動-例如，交換內容交付的相關日誌記錄，相似web server的
access log日誌記錄。

在今天的CDN中，日誌記錄用於各類目的。具體來講，CDN使用日誌來對計費和支付系統、實時(近實時)分析系統生成呼叫數據記錄
(CDR)。這些在CDNI日誌接口的應用場景需求，在互連的CDN之間支持有保證而且及時傳遞日誌消息。另外確保收到日誌消息的完整
性也是必要的。

一些已存在的協議可使用在互連的CDN中進行CDNI日誌交換，包括SNMP traps消息、syslog、FTP、HTTP POST等。儘管一些候選
協議可能並不能知足CDNI的全部需求。例如，SNMP traps不支持traps的保證傳遞，所以可能致使日誌記錄丟失，隨之那段交付內
容的CDR和計費記錄不能產生，以及任何分析平臺都看不到那段交付內容。

儘管爲了在CDNI日誌接口之間交換日誌定義一個新協議是沒有必要的，CDNI工做組仍然須要制定：

-推薦使用的協議。
-一組默認的日誌字段和它們的語法語義。
-今天在不一樣的內容交付協議中，尚未一套標準的通用日誌字段，而且在某些狀況下，甚至沒有一套標準的日誌名稱字段和值在
相同交付協議中有不一樣的實現。
-生成觸發日誌的默認生成條件。

附錄B. 附加材料

本節記錄定義一部分CDNI問題陳述相關信息。

B.1 IETF的無目標

下面列出了做者提出的在內容交付CDNI工做範圍外的方面：

-CSP和權威CDN之間的接口(即上游CDN和CSP的交付簽約，或者和下游CDN的簽約)
-交付CDN代理和UA之間的交付接口，例如流媒體協議。
-對給定的CDN的請求路由系統和UA之間的請求接口。現有的IETF協議(例如HTTP、RTSP、DNS)一般由UA從CDN請求內容，以及經過CD
N的請求路由系統重定向UA的請求。CDNI工做組不須要對此目的定義新的協議。然而，CDNI控制面板接口可能會間接影響經過請求
接口的某些信息交換(例如URI)。
-CDN之間的內容獲取接口(即一條內容從一個CDN到另外一個CDN傳遞的數據平面接口)。預計這將使用已有的協議如HTTP或者其餘論壇
中定義的從原始服務器到CDN之間的內容獲取協議(例如基於HTTP的C2參考點(ATIS IIF CoD //ATIS IIF內容點播服務))。本文檔
描述的CDN互連問題空間可能所以只關心在兩個互連CDN的互操做性之間使用的內容獲取協議的協議/協商方面。
-EU/UA認證。EU/UA認證和受權由CSP負責。
-內容準備，包括編碼和轉碼。CDNI架構旨在容許在互連的CDN之間分發，而內容被看作是不透明的。解釋和處理對象，還有代理對
EU之間對這些內容的優化交付是再也不CDNI範圍內的。
-數字版權管理(DRM)。DRM是一個內容保護系統和UA之間端到端的問題。
-處理CDNI日誌的應用(例如計費、分析、上報)。
-CDN內部的接口和協議(即一個CDN內的接口和協議)。
-獨立CDN的可擴展性。CDNI的接口/方法的可擴展性是範圍內的，單獨CDN的如何擴展已超出範圍。
-請求路由系統選擇CDN或者代理的實際算法(然而，當一些須要在CDN之間傳遞特定的參數須要輸入到這些算法時是在範圍內的)。
-代理算法。例如緩存算法和內容獲取方法超出了CDNI工做。內容管理(例如內容刪除)關係到CDNI內容管理策略是在範圍的，可是
當緩存決定再也不緩存一個內容時的內部算法是不在範圍內的。
-元素管理界面。
-互連CDN的商業、交易和法律相關的方面。