CDNI - RFC7336翻譯

CDNI框架

摘要
本文檔提出了CDNI的一個框架。框架的目的是提供對CDNI問題空間的整體描述，和描述CDN互連所需的各類組件之間的
關係。CDNI須要指定接口和機制解決諸如請求路由，分發交換元數據，和CDN之間交換日誌信息。本文檔的目的是概述
每一個接口須要完成的工做，描述這些接口和機制如何適配在一塊兒，而且把詳細規範放到其餘文檔。本文檔結合RFC6707，
廢棄RFC 3466。

本備忘錄的狀態

版權聲明

1.介紹
本文檔提供了互連CDN之間各類必須的組件，擴展了RFC6770和RFC6707中的問題陳述和用例。它用通用術語和大綱描述了必要接口
和機制如何適配在一塊兒造成一個完整的CDN互連繫統。詳細規定放在其餘文檔。本文檔普遍使用消息流示例來講明互連CDN的操做，
可是這些例子應該被認爲是說明性的而不是規定性的。

RFC 3466使用不一樣的術語和模型來表示"Content(distribution) Internetworking (CDI)"。對接口的描述也缺乏規定性。爲了不
混淆，本文檔廢棄RFC 3466(//閱讀本文檔時，須要認爲RFC3466已經被廢棄)。

1.1術語
本文檔使用RFC6707中定義的核心術語，它還介紹了下列術語：

CDN-Domain:一個起始URL(不包括端口和Scheme，// 完整URL中"://"以前的部分稱爲 URL Scheme)的主機名(FQDN)，表示一個給定
CDN服務的內容集合。例如，在URL http://cdn.csp.example/...URL的其餘部分...(//就是一個URL)，CDN-Domain是cdn.csp.example。
CDN-Domain的主要做用是肯定和各類CDNI規則和應用策略相關的一個區域(子集)。例如，一條CDNI元數據記錄能夠被定義爲一些CDN-Domain
相對應的資源集合。

Distinguished CDN-Domain：由CDN分配的CDN-Domain，用於和對等CDN通訊的目的，可是在客戶端請求中是找不到的(//這種CDN
-Domain在客戶端請求中是不存在的，目的是對等CDN之間的通訊)。這種CDN-Domain能夠用於互聯CDN獲取，或者做爲重定向的目標
，並使得一個CDN能夠區分來自對等CDN的請求和終端用戶的請求。

Delivering CDN:最終給終端用戶提供一條內容的CDN。一系列下游CDN的最後一個(//最終給客戶端提供內容的CDN)。

Iterative CDNI Request Redirection(迭代CDNI請求重定向)：當一個上游CDN選擇將請求重定向到下游CDN，上游CDN能夠將這次重定向行爲徹底基於本地決
定(沒有試圖考慮下游CDN如何依次向UA進行重定向)。在這種狀況下，上游CDN把請求重定向到下游CDN的請求路由系統中，後續依
次的這種行爲將會決定如何重定向那個請求：這種方法稱之爲"迭代"CDNI請求重定向。(//即每一個CDN在重定向時，能夠自主決定如
何進行重定向，這樣對UA來講就會有一系列的重定向，就叫作迭代請求重定向，相似於DNS同樣)

Recursive CDNI Request Redirection(遞歸請求重定向):當一個上游CDN選擇把一個請求重定向到一個下游CDN，上游CDN能夠經過
CDNI請求路由重定向接口查詢下游CDN(或者使用以前相似請求緩存的信息)，來發現下游CDN是否想接受這個請求被重定向到它。這
容許上游CDN在重定向到UA時考慮下游CDN的響應。這種方法稱爲"遞歸"CDNI請求重定向。注意下游CDN可能將請求直接重定向到它
裏面的代理服務器，或者下游CDN裏面的其餘組件(或者另外一個CDN)，來適當的處理這個重定向請求。

(//迭代請求重定向:上游CDN直接給UA返回重定向，這樣UA就須要一次次發起請求，直到最終的CDN。
//遞歸重定向請求:上游CDN查詢下游CDN，找到合適的CDN以後給UA返回重定向，這樣UA就直接獲得了最終CDN。
//這個和DNS系統是如出一轍的。)

同步CDNI操做：發生在服務用戶請求的過程當中時CDN之間的操做。即在UA開始嘗試獲取內容和請求被服務器之間發生的操做。

異步CDNI操做：發生在獨立於任何給定的客戶請求以外的CDN之間的操做。例如通告網點信息或者對稍後須要交付內容的預約位。

觸發器接口：CDNI控制接口的子集，包括預約位、從新驗證、清除元數據和內容的操做。這些操做一般由CSP對上游CDN響應的一些操做(觸發器)。

咱們有時候用uCDN和dCDN分別表示上游CDN和下游CDN(見RFC 6707)。

關於本文檔的不一樣觀點，使用了CDN網點的概念。對因而什麼構成了CDN網點的討論，讀者能夠參考[FOOTPRINT-CAPABILITY]。

1.2 參考模型

本文檔使用圖1的參考模型，擴展了以前定義在RFC 6707中的參考模型。(不一樣之處是擴展的模型把請求路由接口拆分爲兩個不一樣的
部分：請求路由重定向接口和網點&能力通告接口，以下所描述)

 

雖然參考模型中的某些接口對CDNI工做組來講已經"超出範圍"(某種意義來講，沒有必要爲這些接口定義新的協議)，咱們注意到我
們在本文檔中解釋CDNI的總體運做時，仍然須要提到這些接口。

咱們也注意到，雖然咱們一般對給定的CSP服務時，只顯示一個上游CDN，可是徹底有可能多個上游CDN服務同一個CSP。事實上，這
種狀況在今天是存在的，單個CSP能夠把它的內容分發給多個CDN。

下面的簡要介紹了五個CDNI接口，對RFC 6707中的定義進行解釋。咱們在第4節更詳細的介紹了這些接口。

-CI：給其餘CDNI接口提供引導和參數的操做，以及包括預約位、從新驗證、清除元數據和內容的操做。後面的操做子集有時候被
統稱爲"觸發器接口"。

-CDNI請求路由接口：決定哪一個CDN(以及可選的CDN中的代理)服務終端用戶的操做。這個接口其實是兩個獨立相關，而且邏輯捆
綁的接口(//即拆分爲了兩個獨立接口，可是邏輯上有關聯)：

*CDNI網點&能力上報接口(FCI)：異步的交換路由信息操做(例如給定CDN的服務網點信息和能力信息)使得一些列的用戶請求可
以對CDN進行選擇。

*CDNI請求路由重定向接口(RI)：對給定的用戶請求選擇一個交付CDN(代理)的同步操做。

-CDNI元數據接口(MI)：管理互連CDN如何交付內容傳輸元數據的接口。CDNI元數據的示例包括地理阻止指令、可用性窗口、訪問控
制機制和清除指令，它可能包括如下：

*管理一系列的用戶內容請求的異步元數據交換操做。
*管理一個指定用戶內容請求行爲的同步操做。

-CDNI日誌接口(LI)：容許互連CDN交換相關的活動日誌。可能包括如下：

*實時交換，適合運行時的流量監控。
*離線交換，適合分析和計費。

對基於CDNI控制接口的觸發器操做和CDNI元數據接口的劃分，某種意義上有些武斷。對這兩種狀況，信息從上游CDN傳送到下游CDN
能夠普遍地被視爲元數據，描述了下游CDN如何管理內容。例如，由CI傳輸的預約位信息，從新驗證，或者清除元數據相似於經過M
I傳輸的發佈更新元數據的信息。即便CI的清除內容操做可能被視爲對那個內容的元數據更新：簡單的說，清除就是指定內容的可
用性窗口結束。這兩個接口有不少共同點，因此至少，須要在二者之間有一致的數據模型。

咱們所描述的區別，和上游如何理解對於從下游CDN響應的"成功應用"的元數據有關(//咱們要描述這種區別，這種區別和上游CDN
收到了下游CDN"成功應用"元數據時如何理解這個消息有關)。這種狀況下的CI，下游CDN返回一個成功狀態消息來保證操做已經成
功完成；例如，內容已經被清除或者預約位。這意味着下游CDN承擔了成功完成所請求的操做的責任。相反，經過CDN的MI傳送的元
數據就沒有這樣的保證。返回成功意味着成功接收了元數據，可是沒有什麼能夠推斷出元數據什麼時候在下游CDN生效，只能推斷出最
終會生效。這是由於全局的元數據同步更新和終端用戶的請求當前在進行中(或當前的進展沒法區別)。顯然，若是"最終"變成了不
肯定的時間，CDN不會被視爲可信的對等體，可是MI承擔的責任不能被明確界定。

最後，有一個實際問題會影響到全部的CDNI接口，那就是是否爲HTTP Adaptive Streaming (HAS)優化CDNI。咱們在本文檔強調和
傳遞HAS內容的具體問題，可是更多的處理此問題的話題，見RFC 6983。

1.3. 本文檔的結構

本文檔的其他部分安排以下：
-第2節描述了一些CDNI的基本構件，特別是重定向用戶請求到一個給定CDN時的各類選項。
-第3節提供了各類CDNI操做的說明性示例。
-第4節描述了主要CDNI接口的功能。
-第5節展現了使用定義的接口，如何實現CDNI的不一樣部署模型。
-第6節描述了CDNI的信任模型，特別是CDNI提出的信任傳遞問題。

2. 構件模塊

2.1. 請求重定向

做爲核心，CDNI要求從一個CDN到另外一個CDN的請求重定向。對於上游CDN收到的任何指定請求，它要麼直接響應請求，要麼把請求
重定向到一個下游CDN。重定向一個請求到一個下游CDN，有兩個主要的機制。第一種是利用DNS域名解析流程，第二種是使用應用
層的重定向機制，例如HTTP 302或者實時流協議(RTSP)的302重定向響應。因爲存在大量包含某種重定向機制的應用層協議，本文
檔將在示例中使用HTTP(和HTTPS)。相似的機制能夠應用到其餘應用層協議中。下面是一個DNS和基於HTTP重定向簡短討論，在第3
節有一些使用的示例(//即這裏只是簡單說明DNS和HTTP重定向，第3節有一些使用示例)。

2.1.1. DNS重定向

DNS重定向基於對相同的DNS名稱返回不一樣的IP地址，例如，平衡服務器負載或者客戶端的網絡位置的緣由。一個DNS服務器，有時
候成爲Local DNS (LDNS)，表明終端用戶解析DNS名稱。LDNS 一次查詢其餘DNS服務器，直到達到CDN-Domain的權威DNS服務器。網
絡運營商一般提供LDNS服務器，儘管用戶能夠自由選擇其餘的DNS服務器(例如OpenDNS, Google Public DNS)。

後一種可能性很重要，由於權威DNS服務器只能看到向它發起查詢的DNS服務器IP地址，而不是原始終端用戶的IP地址。

DNS重定向的優勢是對終端用戶是徹底透明的；用戶向LDNS服務器發送一個DNS名稱，而且獲得一個IP地址。另外一方面，DNS重定向
是有問題的，由於DNS請求來自LDNS服務器，而不是終端用戶。這可能影響到基於用戶位置選擇的精確性。DNS重定向的透明度也是
一個問題，那就是沒有機會考慮到UA或者URL路徑組件的屬性(//即UA的參數或者URL中的屬性，在DNS中是沒法處理到的)。咱們考
慮DNS重定向的兩種主要形式：簡單的和基於CNAME的。

在簡單的DNS重定向中，權威DNS服務器簡單地從一組可能的IP地址中返回其中一個IP地址。應答的選擇能夠基於集合的特性(例如
，服務器的相對負載)或者客戶端的特性(例如，客戶端相對於服務器的位置)。簡單重定向是直接的。僅有的警告是(1)單個DNS服
務器能夠管理的可選IP地址存在限制；(2)下游服務器緩存DNS響應，所以響應中的TTL必須設置一個合適的值，來保持重定向的新
鮮度。

在基於CNAME的DNS重定向中，權威服務器對DNS請求返回一個CNAME，告訴LDNS服務器使用新的名字從新查詢。一個CNAME在DNS命名
空間中，本質是一個符號連接，就像一個符號連接，重定向對客戶端是透明的;LDNS服務器得到CNAME應答而且從新執行查詢。只有
當名字被解析爲IP地址時，纔會將結果返回給用戶。注意DNAME若是獲得普遍支持，將會優於CNAME。

與HTTP重定向想比，DNS重定向的優勢是可緩存的，減小CDN的重定向DNS服務器負載。然而，這種優點也多是一個缺點，尤爲是
當給定DNS解析器不徹底遵依照TTL，這是真實環境中已知的問題。在這種狀況下，一個終端用戶可能在沒有經過上游CDN時，直接
終止於下游CDN，在上游CDN的觀點中，這多是不指望看到的場景。

2.1.2 HTTP重定向

HTTP重定向利用HTTP協議的重定向響應(例如，"302"或者"307")。這個響應使用一個新的URL來替代原始URL。經過適當的改變URL
，服務器可使得用戶重定向到一個不一樣的服務器。HTTP重定向的優勢是(1)服務器能夠改變客戶端URL包含的字段，例如，特定服
務器的DNS名稱，以及正在訪問的原始HTTP服務器;(2)客戶單向服務器發送HTTP請求，所以客戶端的IP地址是可知的，而且能夠用
來選擇服務器;(3)其餘屬性(例如content type, user agent type)對重定向機制是可見的。

正如DNS重定向的狀況同樣，使用HTTP重定向有一些潛在的缺陷。例如，它可能會影響應用行爲;若是URL被改爲一個不容的域名，
瀏覽器將不會發送cookie。另外，這可能也是一個優勢，這會致使HTTP重定向的結果不會被緩存，所以全部的重定向都必須通過上
遊CDN。

3. CDNI操做概述

爲了給CDNI的不一樣組件提供全面的展現，咱們經過一對互連的CDN，製做了一個"一天的生活"的內容項目來達到可用。這將有助於
在一個完整的CDNI解決方案中，說明所須要支持的許多功能。咱們給出了使用基於DNS和基於HTTP的重定向示例。咱們從很是簡單
的例子開始，而後顯示如何添加額外可能的功能，例如重定向的遞歸請求和內容刪除。

在介紹具體示例以前，咱們提出了可能發生的一個高層次的操做試圖。這個高層次概述如圖2所示。注意大多數操做只會涉及下面
顯示的全部消息的一個子集，以及次序和操做次數可能會有很大差別，做爲更詳細的示例說明。

下面顯示了Operator A做爲上游CDN，Operator B做爲下游CDN，前者和CP有關係然後者是Operator A選擇的向終端用戶交付內容的
CDN。這兩個互連CDN的互連關係多是對稱的，可是每一個方向能夠被視爲獨立運做;爲了簡單起見，咱們只展現了一個方向的互連
。(//意思是兩個CDN是對等關係，可是對另外一個CDN來講，每個方向均可以被視爲是單獨運做)

圖中所示操做以下：
1.下游CDNS在任何內容請求被重定向以前，使用FCI上報它的交付網點和能力。
2.在任何內容請求以前，上游CDN使用MI將CDNI元數據預約位到下游CDN，從而對稍後的內容請求作好準備，使得那個元數據可用。
(//上游CDN經過MI給下游CDN發送一個預約位元數據，讓下游CDN作好準備，應對稍後的內容請求)
3.從UA過來的內容請求到達上游CDN。
4.上游CDN可能使用RI從下游CDN同步請求信息，而忽略它的交付能力決定下游CDN是不是一個合適的請求重定向目標。
5.上游CDN經過對UA發送一些響應(DNS，HTTP)把請求重定向到下游CDN。
6.UA向下遊CDN請求內容。
7.下游CDN可能從上游CDN使用MI同步和內容相關的請求元數據，來決定是否服務此內容。
8.若是內容不在下游CDN的緩存中，下游CDN能夠從上游CDN獲取內容。
9.內容從上游CDN傳送到下游CDN。
10.內容從下游CDN傳遞給UA。
11.一段時間後，也許應CSP(未顯示)的要求，上游CDN可使用CI來通知下游CDN清除內容，從而確保該內容不會被再次交付。
12.在由下游CDN進行一項或多項內容交付活動以後，可能經過LI向上遊CDN提供日誌交付動做。

如下部分是更具體的例子，來展現如何結合這些操做進行各類交付、控制和一對CDN之間的日誌操做。

3.1. 準備工做

最初，咱們假設至少有一個CSP和一個表明它進行內容交付的上游CDN進行簽約。咱們並不特別關心CSP和上游CDN之間的接口，除非
注意到它預計會是和"傳統"CDN(非互連)狀況相同。現有的機制例如DNS CNAME或者HTTP重定向(第2節)，能夠用來引導用戶對CSP
的一條內容請求轉到CSP選擇的上游CDN。

咱們假設A提供了一個上游CDN表明CSP服務CDN-Domain cdn.csp.example的內容。咱們假設B提供了一個下游CDN。一個終端用戶在某
個時間請求URL:
http://cdn.csp.example/...rest of URL...

極可能cdn.csp.example只是其餘CDN-Domain(例如csp.op-a.example)的CNAME。儘管如此，如下示例中的HTTP請求假設是上面的示例
URL。(//即雖然請求URL的domain多是一個CNAME形式，可是下面的例子中的HTTP請求仍然假設使用這個URL，而不用考慮CNAME)

咱們的目標是使得CDN B從以上的URL中辨別要服務的內容。在下面的章節中，咱們將瀏覽內容服務的一些場景，以及其餘的CDNI操做
，例以下游CDN的內容清除。

3.2. 迭代HTTP重定向示例

在本節中，咱們使用從一個上游CDN到一下游CDN的HTTP重定向來講明一個簡單示例。這個例子也假設上游CDN和下游CDN都使用了HTTP
重定向；然而，這是獨立於跨CDN的重定向方法的選擇，因此還能夠構造一個替代的例子，仍然顯示從上游CDN到下游CDN的HTTP重定
向，可是仍然使用DNS來處理每一個CDN內部的請求。

對於這個例子，咱們假設A和B已經創建了它們CDN互連的協議，A是上游CDN，B是下游CDN。

該操做容許CDN-Domain peer-a.op-b.example做爲上游CDN到下游CDN重定向的目標。咱們假設這個域的名稱經過某種方式傳達給每一個
CDN(這個能夠經過傳輸層協議的帶外數據或CDNI接口完成)。咱們將此域稱之爲"distinguished" CDN-Domain來傳達，它的使用範圍
僅限於互連機制；這樣的域永遠不會被CSP直接使用。(//這種域名只是在互連機制中使用，每一個互連CDN能夠理解該域名，CSP用不到
這種域名稱爲distinguished CDN-Domain)

咱們假設每一個CDN也贊成一些distinguished CDN-Domain能夠用來從CDN之間獲取CSP的內容。在這個例子中，咱們使用域名
op-b-acq.op-a.example. (//意思是用op-b-acq.op-a.example做爲CDN之間的內容獲取域名，即都使用這個域名獲取內容)

咱們假設operators能夠交換 下游CDN準備服務哪一種請求 信息。例以下游CDN可能準備服務特定地區的客戶請求或者一組IP地址前綴
。這些信息能夠經過傳輸層協議的帶外數據或CDNI接口完成。(//每一個CDN能夠經過CDNI接口來交換每一個CDN的服務範圍)

咱們假定DNS的配置方式以下：

-CP配置爲CDN A做爲cdn.csp.example的權威DNS。(或者對域名cdn.csp.example返回一個CNAME，A是權威DNS服務器)
-配置A後，一個DNS請求op-b-acq.op-a.example，返回Operator A的地址。
-配置B後，一個DNS請求peer-a.op-b.example/cdn.csp.example，返回Operator B的地址。

圖3說明了一個客戶請求http://cdn.csp.example/...rest of URL...的處理流程。

圖中所示的步驟以下：

1.A的DNS解析器爲它的客戶發送DNS請求：CDN-Domain cdn.csp.example。返回A的一個Request Router的IP地址。
2.A的Request Router處理HTTP請求，而且意識到這個終端用戶最好被另外一個CDN服務，特別是由B提供的，所以它返回
一個302重定向消息，這個重定向URL是在在原始URL以前添加由B構造的distinguished CDN-Domain(peer-a.op-b.ex
ample)(注意可能有更復雜的URL，例如將初始CDN-Domain替換成一些不透明句柄)。
(//客戶端請求的是cdn.csp.example/...，重定向爲peer-a.op-b.example/cdn.csp.example/...)
3.終端用戶查詢peer-a.op-b.example域名。B的DNS解析器返回B的Request Router的IP地址。注意若是下游CDN的請求
路由使用DNS來代替HTTP重定向，B的DNS解析器會表現爲一個請求路由器，而且直接返回交付節點的IP地址。
(//下游CDN的請求路由若是使用DNS的話，會直接返回節點IP地址，若是使用HTTP重定向方式，則還要進行一次重定
向)
4.B的請求路由器處理HTTP請求，而且選擇合適的節點服務終端用戶的請求，並返回一個302重定向消息，這個消息使用
子域名替換主機名來指向選擇的交付節點。
(//客戶端請求的是peer-a.op-b.example/cdn.csp.example/...，重定向爲node1.peer-a.op-b.example/cdn.csp.example)
5.終端用戶發送DNS查詢域名node1.peer-a.op-b.example。B的DNS解析器返回交付節點的IP地址。
6.終端用戶向B的交付節點發送內容請求。若是命中緩存，不會走六、七、八、九、10步驟，而且內容數據由交付節點直接返回給
用戶。緩存未命中的狀況下，下游CDN須要從上游CDN(不是CSP)獲取內容。distinguished CDN-Domain
peer-a.op-b.example，這個域名向下遊CDN表示了須要從上游CDN獲取內容;去掉CDN-Domain的前面部分後，獲得原始的CDN-
Domain cdn.csp.example，所以下游CDN能夠驗證這個CDN-Domain屬於一個已知的CDN(避免被欺騙做爲一個開放代理)。而後
進行CDN請求，就是上面說的內部CDN之間內容獲取的CDN-Domain(這種狀況下，就是op-b-acq.op-a.example)。
(//B從A獲取內容時，使用域名op-b-acq.op-a.example，這個域名是經過CDNI接口協商好的)
7.A的DNS解析器處理這個DNS請求，而且返回A的Request Router的IP地址。
(//Request Router就是一個請求調度處理器，用來返回302或者自己就是一個DNS返回節點地址)
8.A的Request Router處理B交付節點的HTTP請求。A的Request Router經過專用的內容獲取域名op-b-acq.op-a.example意識
到這個請求來自一個對等CDN，而不是終端用戶。(注意若是沒有這個特別規定的內容獲取域名，則A把請求重定向到B後就會
有風險，致使無限循環)(//即若是沒有這個特定的域名時，A收到B的內容獲取請求時，又會把該請求重定向到了B)。A的
Request Router從上游CDN中選擇一個合適的交付節點來服務CDN之間的內容獲取請求，而且返回一個302重定向消息，這個
消息把CDN之間的內容獲取域名替換爲A的指向交付節點的子域名。
(//B向A發送op-b-acq.op-a.example請求，重定向爲node2.op-b-acq.op-a.example)
9.A的DNS解析器處理DNS請求(//node2.op-b-acq.op-a.example)，而且返回交付節點的IP地址。
10.B從A獲取內容。A處理URL其他部分的流程(圖上沒有顯示)：提取標識源服務器的信息，驗證該服務器已經註冊，並肯定CP
擁有源服務器。若是須要它可能在給下游CDN返回內容以前，執行本身的內容獲取流程。

這種設計的主要優勢是簡單：每一個CDN只須要知道每一個對等CDN的distinguished CDN-Domain，上游CDN把下游的CDN-Domain
放到URL上面作爲重定向的一部分(第2步)(//在URL前面添加前綴做爲重定向URL)。下游CDN從URL裏面取出CDN-Domain後，獲得
上游CDN能夠正確處理的 CDN-Domain(//意思就是下游CDN把URL前面的部分去掉後，剩下的部分就是上游CDN能夠處理的部分)
。CDN不須要知道其餘CDN URL的內部結構。此外，CDN間的重定向徹底由單個HTTP重定向支持(//意思是CDN間的重定向，一個
HTTP重定向消息就夠了);CDN不須要知道其餘CDN的內部重定向機制(即基於DNS或者基於HTTP)。

一個缺點是終端用戶的瀏覽器被重定向到一個和新的和原始URL域名不一樣的URL。這有時候會對端點的安全或驗證機制產生影響
。例如，若是指望瀏覽器發送任何和那個域名相關的cookie時，重要的是任何重定向URL須要有相同的域名(例如csp.example)
。做爲另外一個例子，一些視頻播放器對跨域策略進行強制驗證，所以須要CDN重定向的域名適應這種需求。這些問題一般是可
以解決的，可是解決方案會使示例變得複雜，所以在本文檔中再也不進一步討論。

咱們注意到這個例子開始說明一些CDNI可能須要的接口，可是這個示例並不須要用到全部的接口。例如，從下游CDN獲取它可
以服務的客戶端IP集合或者地理區域的信息，這關係到請求路由的方面(特別是CDNI網點&能力上報接口)。重要的配置信息例
如重定向的識別名稱和CDN之間的獲取也能夠經過CDNI接口(例如，CDNI控制接口)傳輸。這個例子也展現了現有的基於HTTP的
方法如何用於獲取接口。能夠說，CDNI所需絕對最小元數據是獲取內容所須要的信息，而且這個信息在本例中是經過"in-band"
URL處理，在HTTP 302響應中。這個例子也假定CSP不須要使用任何分發策略(例如時間窗口或者地理限制)或者互連CDN所須要
使用的傳遞處理。所以，這個例子中沒有明確的CDNI元數據接口。也沒有討論明確的CDNI日誌接口。

咱們還注意到，沒有代表如何決定一個請求應該被重定向到下游CDN仍是被上游CDN服務。它能夠簡單的在一個前綴列表中檢查
客戶端IP地址，或者有更復雜的考慮，涉及普遍的因素範圍，例如客戶端地理位置(可能有第三方服務決定)、CDN負載或者特定
的業務規則。

這個例子使用"迭代"CDNI請求重定向方法。也就是說，上游CDN經過把客戶端重定向到下游CDN的Request Router來做爲請求重定
向功能的一部分，而後下游CDN把客戶端重定向一個合適的代理做爲重定向功能的剩餘部分。若是下游CDN的request routing使用
HTTP重定向，這樣終端用戶會體驗兩個連續的HTTP重定向。想比之下，一個可選的方法——"遞歸"CDNI請求重定向有效的把這兩個
連續的HTTP重定向合併成一個，直接給終端用戶發送下游CDN的代理節點。這種"低估"CDNI請求路由方法在下一節討論。

上面的例子使用的HTTP，迭代HTTP重定向機制，能夠以相似的方式在HTTPS上工做。爲了確保終端用戶的HTTPS請求在重定向路徑
中不會被降級爲HTTP，有必要對每一個Request Router，從最初的上游CDN的Request Router到最終的下游CDN的代理，對收到的HTTPS
請求響應一個包含HTTPS URL的HTTP重定向。應該注意的是，使用HTTPS會增長總的重定向流程時間和增長Request Router的負載，
特別是當重定向路徑包括許多重定向，從而許多安全套接字層(SSL/TLS)會話。在這種狀況下，遞歸HTTP重定向機制，以下一節描述
的例子中，或許能夠幫助減小這種問題。

(//3.2說明了迭代HTTP重定向的例子，迭代會產生不少重定向，所以下面介紹遞歸HTTP重定向)

3.3. 遞歸HTTP重定向示例

下面的例子基於前一個示例來講明請求路由接口(具體說是CDNI請求路由重定向接口)啓用"遞歸"CDNI請求路由的用法。咱們創建在
基於HTTP重定向方法上，由於它清楚的說明了原則和好處，可是一樣可能在基於DNS的重定向中執行遞歸重定向。

與前面的例子相反，operators不須要預先贊成，做爲重定向目標服務的CDN-Domain，從上游CDN到下游CDN。咱們假設operators對
CDN之間的用來使下游CDN獲取CSP內容使用的distinguished CDN-Domain達成一致。在這個例子中，咱們使用op-b-acq.op-a.example。
(//意思是CDN之間協商好獲取內容的CDN-Domain，這裏就是op-b-acq.op-a.example)

咱們假設operators也交換 下游CDN準備服務哪一種請求 信息。例如，下游CDN可能準備服務特定區域或者一組IP地址前綴的用戶請求。
這些信息能夠再次由傳輸層協議的帶外數據或者定義的協議提供。

咱們假設DNS按以下方式配置：
-CP配置爲CDN A做爲cdn.csp.example的權威DNS。(或者對域名cdn.csp.example返回一個CNAME，A是權威DNS服務器)
-配置A後，一個DNS請求op-b-acq.op-a.example，返回Operator A的地址。
-配置B後，一個DNS請求node1.op-b.example/cdn.csp.example，返回交付節點的IP地址。注意可能有多個這樣的交付節點。

圖4說明了一個客戶請求http://cdn.csp.example/...rest of URL...的處理流程。(//原文有誤，寫的圖3)

圖中所示的步驟以下：
1.Operator A的DNS解析器處理客戶基於CDN-Domain cdn.csp.example的DNS請求。它返回一個A的Request Router的IP地址。
2.Operator A的Request Router處理HTTP請求，而且意識到這個終端用戶最好被另外一個CDN服務——具體是由Operator B提供的
——因此它向Operator B查詢CDNI請求路由重定向接口，提供包括URL請求的關於請求的信息集合。Operator B響應一個交付
節點的DNS主機名。
(//Operator A向Operator B的請求路由重定向接口發送一些請求信息，Operator B返回它裏面一個代理節點的主機名(子域名))
3.Operator A對從RI獲取到的新的URL，響應一個302重定向消息。
4.終端用戶使用DNS查詢剛收到的域名(node1.op-b.example)。B的解析器返回響應交付節點的IP地址。注意，自從使用RI從B獲
取到交付節點的主機名後，以後不該該有更多的重定向(對比上面描述的迭代方法)。
5.終端用戶從B的交付節點請求內容，可能會未命中緩存。在這種狀況下，須要從上游CDN(非CSP)獲取內容。 distinguished
CDN-Domain op-b.example向下遊CDN標明瞭這個內容須要從另外一個CDN獲取;去掉CDN-Domain(node1.op-b.example/cdn.csp.example)
的前部分後，獲得原始的CDN-Domain cdn.csp.example。下游CDN可能驗證這個CDN-Domain屬於一個對等的CDN(避免被欺騙爲開
放代理)。而後它對CDN之間獲取內容的"distinguished" CDN-Domain發送一個DNS查詢請求，如上面協商的(在這裏是
op-b-acq.op-a.example)。
6.Operator A的DNS處理DNS請求，而且返回Operator A的Request Router的IP地址。
7.Operator A的Request Router處理Operator B的交付節點發來的HTTP請求。Operator A的Request Router經過CDN間的專用內容
獲取域名(op-b-acq.op-a.example)意識到這個請求是來自一個對等CDN而不是一個終端用戶。(注意若是沒有這個特別規定的內容獲取
域名，則A把請求重定向到B後就會有風險，致使無限循環)。Operator A的Request Router從上游CDN中選擇一個合適的交付節點來服
務CDN之間的內容獲取請求，而且返回一個302重定向消息，這個消息把CDN之間的內容獲取域名替換爲A的指向交付節點的子域名。
8.Operator A意識到DNS請求來自對等的CDN而不是一個終端用戶(根據內部的CDN-Domain判斷)，所以返回交付節點的地址。(注意若是沒有
這個特別規定的內容獲取域名，則A把請求重定向到B後就會有風險，致使無限循環)
(//意思就是Operator A根據請求的域名判斷是CDN請求數據仍是終端客戶請求數據，CDN請求則返回交付節點的地址，終端用戶則是以上
流程)。
9.Operator B從Operator A獲取內容。Operator A處理URL其他部分的流程(圖上沒有顯示)：提取標識源服務器的信息，驗證該服務器已經
註冊，並肯定CP擁有源服務器。若是須要它可能在給下游CDN返回內容以前，執行本身的內容獲取流程。

遞歸重定向具備優點(超過迭代重定向)，從終端用戶的角度看更加透明，可是缺點是對其餘CDN暴露更多的內部結構(特別是邊緣緩存服務器
的地址)。想比之下，迭代重定向不須要下游CDN向上遊CDN暴露它的邊緣緩存地址。

這個例子在CDN A和CDN B使用基於HTTP的重定向，可是能夠在每一個CDN中使用基於DNS重定向來構建相似的例子。所以，這裏要拿走的關鍵點
僅僅是終端用戶只看到了某個類型的單個重定向，和以前的例子中(迭代重定向)的兩次重定向相反。
(//意思是這個例子和上面的迭代重定向同樣，在CDN中都使用了HTTP重定向，因此二者僅有的不一樣點就是重定向次數不同)

RI的使用要求請求路由機制被適當的配置和引導，可是這裏沒有描述。更多對接口的引導的討論在第4節提供。

3.4 基於DNS迭代重定向的示例

在本節中，咱們將說明上游CDN到下游CDN(也包括下游CDN和上游CDN內部的請求路由)重定向時使用基於DNS重定向的簡單例子。
正如2.1節指出的，基於DNS的重定向對基於HTTP的重定向具備優點也有缺陷。(優點就是HTTP重定向服務器對終端用戶是透明的
而DNS不是，缺點就是DNS的Request Router看不到客戶端的IP地址)

和以前同樣，Operator A須要獲得下游CDN願意或者有能力服務的請求集合(例以下游CDN的網點包括了哪些客戶端IP前綴或地理
區域)。咱們假定Operator B已經向Operator A公佈了能夠用來構建distinguished CDN-Domain的一些惟一的標識，以下面詳細
解釋。(這個標識只須要在Operator A是惟一的，可是全局惟一的標識符，例如分配給B的自治系統(AS)號碼，用這種方法很容易
實現)。另外，Operator A獲取了Operator B對外可見的重定向服務器的NS記錄。此外，和以前同樣，一個distinguished CDN-D
omain，例如op-b-acq.op-a.example，必須被分配以用來CDN之間的內容獲取。

咱們假定DNS的配置以下：
-CSP配置爲Operator A做爲cdn.csp.example的權威DNS。(或者對域名cdn.csp.example返回一個CNAME，A是權威DNS服務器)
-當上遊CDN發現一個請求更適合被下游CDN服務時，它返回一個CNAME和"b.cdn.csp.example"的NS記錄，"b"是分配給B的惟一
標識符(例如，多是分配給Operator B的AS號碼)。
-下游CDN配置後，一個DNS請求"b.cdn.csp.example"返回下游CDN的交付節點。
-上游CDN配置後，一個DNS請求"op-b-acq.op-a.example"返回上游CDN的交付節點。(//這個是CDN間獲取內容的CDN-Domain)

圖5描述了DNS和HTTP請求的交換。和圖3中主要的不一樣在於缺乏HTTP重定向和對終端用戶的透明度。

圖中所示的步驟以下：

1.Operator A的Request Router處理CDN-Domain cdn.csp.example的DNS請求，而且意識到這個終端用戶最好被另外一個CDN服務。
(這可能取決於用戶LDNS的IP地址，或者下面介紹的其餘信息)。Request Router返回一個DNS CNAME響應——把Operator B的
區別標識符加到原始CDN-Domain的前面(例如b.cdn.csp.example)。
2.終端用戶向Operator A的DNS服務器發送修改後的CDN-Domain(例如b.cdn.csp.example)的查詢。Operator A的Request Router
處理DNS請求而且經過發送一個NS記錄加上指向Operator B的DNS服務器的膠水記錄來返回一個受權記錄b.cdn.csp.example。(
這個額外的步驟是必要的，由於典型的DNS實現不會使用NS記錄當它和CANME記錄一塊兒發送時，所以須要兩部來實現)

(//[1]客戶端向Operator A請求cdn.csp.example，返回cdn.csp.example CNAME b.cdn.csp.example
//[2]客戶端向Operator A請求b.cdn.csp.example，返回b.cdn.csp.example NS ns1.b.cdn.csp.examle
// ns1.b.cdn.csp.examle IN A 192.168.0.1
//第一步不能在響應裏面加上NS和膠水記錄，這樣的話LDNS不會向NS發起查詢
)
3.終端用戶向Operator B的DNS服務器發送修改後的CDN-Domain(例如b.cdn.csp.example)查詢。使用第2步收
到的NS和A/AAAA記錄，這致使B的Request Router返回一個合適的交付節點。(//這裏的終端用戶應該是LDNS)
4.終端用戶向B的交付節點請求數據。請求URL包含域名cdn.csp.example(注意返回的CNAME不會影響到URL)。至
此，交付節點獲得了終端用戶的正確IP地址，而且能夠發送一個HTTP 302重定向若是第2步和第3步的重定向不
正確時(//由於第2和第3步看不到用戶的IP地址，所作的重定向可能不許確)。不然，B驗證這個CDN-Domain是否
屬於一個已知的peer(避免被欺騙)(//意思是根據客戶請求的URL裏面的域名判斷是否來自其餘CDN)。以後它執行
一個如上所說的"內部"CDN-Domain的DNS請求(op-b-acq.op-a.example)。(//獲取內容的CDN-Domain)
5.Operator A意識到DNS請求來自peer CDN，而不是終端用戶(根據域名判斷)，所以返回它裏面一個交付節點的地址。
6.Operator A給下游CDN服務內容。儘管沒有顯示，Operator A處理URL其他部分的流程：提取標識源服務器的信息，
驗證該服務器已經註冊，並肯定CP擁有源服務器。

這種方法的優勢是對終端用戶更加透明，而且對基於HTTP來講，須要更少的往返流程(最壞的狀況下，即DNS沒有緩存
任何所需的信息)。一個潛在的問題是上游CDN依賴於有能力對DNS請求中的終端用戶地址學習正確的服務此用戶的下游
CDN。在標準的DNS操做中，上游CDN將會只獲取到客戶端LDNS的地址，這個地址不能保證和客戶端在同一個網絡(或者
地理區域)。若是不是(例如終端用戶使用了全局DNS服務)，那麼上游DCN將不能肯定服務該用戶的合適的下游CDN。在這
中狀況下，假設上游CDN有能力檢測到那種狀況，一種選擇是，上游CDN對待終端用戶做爲任意用戶，而不去鏈接peer CDN。
另外一個選擇是，上游CDN"退回"到一個基於HTTP重定向策略(即，使用第一方法)。注意這個問題會影響到現有的依靠DNS決定
如何重定向客戶端請求的CDN，可是對於CDNI卻不那麼嚴重，由於LDNS一般和下游CDN在同一個網絡中。

和前面的例子同樣，這個例子部分說明了CDNI中涉及的各類接口。Operator A能夠經過CDNI的網點&能力上報接口動態學習
Operator B願意和有能力所服務的前綴集合或者區域。用於獲取內容的distinguished name和Operator B的標識符也能夠
經過CDNI接口傳輸(或者，另外一個可選擇的方式是靜態配置)。(//有歧義)。和以前同樣，最小的元數據足以獲取內容做爲
重定向流程的一部分，以及標準的HTTP用來CDN之間的內容獲取。本例中沒有明確的討論CDNI日誌接口。

3.4.1.使用DNSSEC的注意事項

雖然可使用DNSSEC結合上面介紹的基於DNS的迭代重定向機制，須要注意的是上游CDN可能須要即時對記錄簽名，當CNAME返
回時，所以這樣的提供簽名，可能對每一個到來的查詢會不一樣。儘管沒有什麼能夠阻止上游CDN執行這樣的即時簽名，這在計算
上是昂貴的。在這種多個下游CDN的狀況下，所以會返回多個不一樣的CNAME，是相對穩定的，一個可選的解決方案是上游CDN對
全部可能的CNAME預先生成簽名。對每一個到來的查詢，上游CDN能夠決定合適的CNAME而且和與它關聯的預生成簽名一同返回。
注意：在後一種狀況下，維護序列號和SOA的簽名多是一個問題，從技術上講，它應該在每次使用不一樣的CNAME時改變(序
列號和SOA前面)。然而，在實踐中，直接的SOA查詢相對較少，上游CDN能夠推遲遞增序列號和對SOA從新簽名，直到它被查
詢，而後即時執行。

(//意思是對CNAME的預先簽名能夠下降計算消耗，每當使用不一樣的CNAME，序列號和SOA簽名都應該更改，然而正常狀況下，
直接請求SOA的狀況不多，因此使用不一樣CNAME時，先不增長序列號和對SOA從新簽名，而是當收到查詢時再執行序列號的增
加操做和SOA重簽名)

注意前一節中第2步中，NS記錄和膠水記錄一般狀況下須要和Operator B管理它們的權威域的記錄相同。即便它們不一樣，也不
會致使DNS解析過程失敗，可是LDNS會首選使用它緩存的權威數據來進行後續查詢。這種先後矛盾的操做是廣泛問題，可是這
種結構是重要的，由於上游CDN將依賴這種特性來使得重定向結果和預期的那樣。通常來講，管理員有責任保持它們的一致性。

(//意思是Operator A回給LDNS的NS和glue記錄和Operator B權威域的記錄不同，這樣LDNS會優先使用緩存的權威數據。雖然
這是個問題，可是上游CDN須要這種機制來進行重定向。zzsb)

3.5 動態網點發現示例

有能力動態發現下游CDN願意和有能力服務的請求集合，這種狀況是有益的。例如，一個CDN當前可能有能力服務一個特定的客戶
端IP前綴集合，可是一段時間後，那個集合可能由於IP網絡的拓撲和路由策略而改變。下面的例子說明了這種能力。咱們選擇使
用基於DNS重定向的示例，可是基於HTTP重定向也能夠很好的使用這個方法。

這個例子和圖5的不一樣之處，只是添加了RI請求(第2步)和對應的響應(第3步)。RI REQ能夠是一個例如"你能夠對這個IP前綴的客
戶端服務嗎?"或者"提供你當前能夠服務的客戶端IP前綴列表"。在任何一種狀況下，Operator A可能會緩存那個響應來避免查詢
相同的問題。或者，另外，Operator B能夠主動上報它願意和有能力表明Operator A的請求集合信息；在這種狀況下，Operator
B能夠主動發佈RR/RI REPLY消息，而非對RR/RI REQ消息的直接響應。(//即不須要收到請求,直接發出響應)(注意從DNS請求中確
定客戶端子網的問題，正如上面描述的，和第3.4節徹底同樣)。

當Operator A收到了RI響應，它如今就能肯定Operator B的CDN是一個合適的下游CDN，所以它重定向時會考慮這個候選CDN。若是
選擇了那個下游CDN，對請求的重定向和服務項以前那樣進行(即在缺乏動態獲取網點能力時的流程)。(//意思就是和以前的流程一
樣，以前介紹的流程都沒有動態獲取網點的步驟)

3.6. 內容清除示例
下面的例子說明了下游CDN如何使用CDNI控制接口獲取一項內容的預約位。在這個例子中，用戶請求一個特定的內容，而且Operator
A到Operator B對這個請求進行相應的重定向，可能(或可能沒有)較早的發生。而後，在某個時間點，上游CDN使用CI請求特定的URL
請求那個內容在下游CDN中刪除。下面的示例圖說明這個操做。應該注意的是，上游CDN一般不知道下游CDN是否緩存了給定的內容項。
可是，它能夠發送內容清除請求來確保沒有剩餘緩存的版本能夠知足任何它可能有的合同義務。

(//就是上游CDN通知下游CDN刪除某個內容項。)

CI用於上游CDN到下游CDN傳輸刪除以前獲取的內容的請求。請求中的URL指定了須要清除的內容。這個例子對應到基於DNS重定向的場景
，如3.4節。若是已經使用了基於HTTP的重定向，清除的URL將是這種格式:peer-a.op-b.example/cdn.csp.example/...

下游CDN指望給上游CDN確認消息，如圖中的CI OK消息，完成目標內容的清除來自下游CDN中的全部緩存服務器。

3.7. 預約位內容獲取示例

下面了例子說明了如何使用CI在下游CDN中預約位一個內容項。在這個例子中，Operator A使用CDNI元數據接口請求那個被特殊URL標識的
內容，預約位到Operator B CDN。
(//上游CDN A使用CI把內容預約位到CDN B中，意思就是提早把內容發送到下游CDN，這樣用戶被重定向到下游CDN時就能夠直接服務內容)

圖中所示的步驟以下：
1.Operator A使用CI向Operator B請求預約位一個由URL指定的特別的內容項。Operator B經過確認響應來表示它願意執行此操做。

第2步和第3步和第3節中第5步和第6步徹底相同，只是這一次的步驟由預約位產生，而不是緩存缺失。
(//意思是第3節是因爲下游CDN沒有命中緩存，因此要從上游CDN獲取內容，而這裏是因爲預約位，從上游CDN獲取內容。雖然觸發方
式不一樣，可是流程是同樣的)

步驟四、五、六、7和第3節中的步驟一、二、三、4徹底同樣。只是這一次，Operator B的CDN能夠在不觸發動態內容獲取時，直接服務終端
用戶的請求，由於下游CDN已經預約位了內容。注意，根據下游CDN的操做和策略，預約位的內容可能被下游CDN預約位到全部的緩存服
務器，或者其中一部分緩存服務器。在後一種狀況下，當緩存的內容沒有被預約位時，CDN間的動態內容獲取可能發生在下游CDN內部;
然而，這種CDN內部的動態獲取不會涉及到上游CDN。
(//預約位而已，若是下游CDN的緩存服務器沒有所有預約位到內容，例如邊緣緩存A預約位到內容，邊緣緩存B沒有預約位，則邊緣B服
務用戶請求時從邊緣A獲取內容，而不是從上游CDN獲取)

3.8. 異步CDNI元數據示例

在本節中，咱們經過一個簡單的示例來講明異步交換CDNI元數據的場景，下游CDN在響應的內容請求以前獲取內容的CDNI元數據。下面
的例子假設CDN之間的重定向基於HTTP，而且使用遞歸的CDNI請求路由，如3.3節所示。然而，CDNI元數據的異步交換一樣適用於基於DNS
的CDN間重定向和迭代請求路由(這種狀況下，CDNI元數據在消息流的處理中可能會稍微有所不一樣)。

(//異步CDNI元數據交換，能夠用於CDN之間基於HTTP或者DNS重定向的場景，和CDN之間遞歸或者迭代請求路由)

圖中所示的步驟以下：
1.Operator A使用CI向Operator B觸發可用性信號。 (//意思是Operator A向Operator B觸發預約位信號)
2.Operator B對此觸發信號回覆確認。
3.Operator B使用MI向Operator A請求最新的元數據。
4.Operator A對請求的元數據進行響應。本文檔不限制CDNI元數據信息的具體形式。對於這個例子的目的，咱們假設Operator A向
Operator B提供的CDNI元數據標識了下面的內容：
*對於被引用CDN-Domain，CDNI元數據對任何內容都是可用的。
*CDNI元數據由交付節點須要強制執行的分發策略或者特定的請求驗證機制(例如，URI簽名或者令牌驗證)。
5.內容請求和日常同樣。
6.CDNI請求路由重定向請求(RI REQ)由Operator A的CDN發佈，如3.3節討論的。Operator B的Request Router能夠訪問和請求內容
相關的CDNI元數據，而且這個內容在1-4步已經被預約位。其可能或可能不會影響到響應。
7. Operator B的Request Router發出一個CDNI請求路由重定向響應(RI RESP)，如3.3節中描述。
8.Operator A執行內容重定向如3.3節中討論的。(//原文有誤，寫成Operator B)
9.收到終端用戶的內容請求後，交付節點檢測到以前獲取的CDNI元數據對請求的內容是可用的。按照本例中指定的CDNI元數據，交付
節點將涉及到在服務內容以前進行適當的請求認證機制(這種詳細的認證沒有顯示)。
10.假設請求認證成功，則像3.3節描述的，進行內容數據服務(可能在CDN間內容獲取以前)。

(//首先Operator A向Operator B發送一個預約位消息，Operator B回覆確認。
//以後Operator B請求內容的元數據，Operator A響應元數據
//以後Operator A收到客戶端的內容請求
//以後Operator A向Operator B發送路由請求重定向，Operator B響應此請求
//以後Operator A給客戶端發送重定向
//以後客戶端向Operator B請求內容 (//此處可能有Operator B向Operator A請求內容的步驟，由於Operator B可能尚未要服務的內容)
//以後Operator B服務內容)

(//異步獲取元數據就是在沒有收到客戶端請求時，主動獲取
//同步獲取就是收到客戶端請求時，觸發獲取)

3.9. 同步CDNI元數據獲取示例
在本節中，咱們經過一個簡單的示例來講明同步獲取CDNI元數據的場景，下游CDN處理第一個請求時，獲取對應內容的CDNI元數據。正如上一節中，
這個例子假設CDN之間使用了基於HTTP的重定向和遞歸的CDNI請求路由(如3.3節所示)，可是動態的CDNI元數據獲取也適用於其餘的各類請求路由類
型。

圖中所示的步驟以下：
1.正常的內容請求。
2.和以前例子同樣的RI請求。
3.在收到CDNI請求路由請求時，Operator B的CDN啓動同步獲取處理終端用戶所需的CDNI元數據。咱們假設元數據服務器的URL在以前經過帶外的手
段獲得。
4.收到CDNI元數據請求後，Operator A的CDN作出響應，建立對Operator B的CDN可用的相應的CDNI元數據信息。這個元數據被Operator B的CDN處理，
在給請求路由請求應答以前(在一個簡單的狀況下，元數據能夠只是一個容許或拒絕的響應，在這種特定的請求中)。
(//意思是A給B發送了一個請求路由請求，B不馬上響應，而是B先請求A的元數據，收到A元數據響應後，最後再響應最開始的請求路由請求)
5.正常響應RI請求。
6.給終端用戶發送重定向消息。
7.Operator B的交付節點收到用戶的請求。
8.交付節點對終端用戶的內容請求觸發額外的CDNI元數據的動態獲取。注意存在不發生此步驟的狀況，例如，元數據已經在以前獲取過。
9.Operator A的CDN響應對Operator B可用的相應的CDNI元數據的CDNI元數據請求。這個元數據影響到Operator B如何處理終端用戶的請
求。
10.服務內容(可能在CDN之間的內容獲取以前)如3.3節所示。 (//由於此時只是獲取到了元數據，可是不必定有內容)

(//內容的CDNI元數據對這個內容進行了描述，例如包括如何服務客戶，上面的流程都在交互元數據，可是沒有交互內容，因此最後一步
給用戶服務內容以前，應該有一個內容獲取的步驟)

3.10 多個上游CDN的內容和元數據獲取
單個下游CDN可能從多個上游CDN收到用戶的請求。當一個下游CDN收到終端用戶的請求，它必須確承認以獲取請求內容的上游CDN的身份。
(//收到用戶請求時，須要知道從哪一個上游CDN獲取用戶請求的內容)

理想狀況下，終端用戶請求的獲取路徑將遵循請求的重定向路徑。下游CDN須要從給它重定向的上游CDN中獲取內容。

肯定採集路徑須要下游CDN對基於終端用戶的請求信息重建重定向路徑。(//即修改用戶請求的url，獲得採集路徑)。對基於重定向的方法：HTTP或者
DNS，這個重建重定向路徑的方法會有所不一樣。(//即基於HTTP重定向的重建重定向方法和基於DNS重定向的重建重定向方法不一樣)

HTTP重定向中，當收到終端用戶請求時，重寫的URL須要包含足夠的信息來使得下游CDN能夠直接或間接地肯定上游CDN。根據URL在重定向時如何被重
寫，HTTP重定向方法能夠被更進一步地細分爲：有站點聚合的HTTP重定向和沒有站點聚合的HTTP重定向。有站點聚合的HTTP重定向隱藏了原始CSP的身
份。沒有站點聚合的HTTP重定向不試圖隱藏原始CSP的身份。使用這兩種方法，重寫的ULR包括了識別接近的鄰居上游CDN的足夠信息。

DNS重定向中，下游CDN收到發佈的URI(而不是重寫的URI)，而且沒有足夠的信息識別合適的上游CDN。下游CDN能夠經過檢查上游CDN發送的CDNI元數據
來縮小範圍，肯定哪一個上游CDN管理着請求內容的託管元數據。若是隻有一個上游CDN託管着請求內容的元數據，下游CDN能夠假設那個重定向請求來自
這個上游CDN而且從這個上游CDN採集內容。若是有多個上游CDN託管着請求內容的元數據，下游CDN可能須要準備好信任任何一個上游CDN來採集內容。
若是下游CDN沒有準備好信任任何上游CDN，那麼須要確保經過使用帶外約定，對於給定的內容，只有一個上游CDN把請求重定向到下游CDN。

內容獲取可能在內容元數據獲取以前進行。若是可能，元數據的獲取路徑應該也跟隨重定向路徑。此外，咱們假設元數據，在基於HTTP重定向時是基於
重寫URI索引的，在基於DNS重定向時是基於發佈的URI索引的。所以，RI和MI是緊密結合的，請求路由的結果(一個指向下游CDN的重寫URL)做爲元數據
查詢的輸入參數。若是內容元數據包括採集內容的信息，那麼MI也和採集接口緊密結合，元數據查詢的結果(採集URL)做爲內容採集的輸入參數。

4.主接口

圖1列出了CDNI工做組範圍內的主要接口，還要其餘幾個。這些接口的詳細規範放到其餘文檔，參見RFC 6707和RFC7337對接口的一些討論。

圖1沒有顯示用戶和CSP之間的接口。雖然對於CDNI來講那個接口不在範圍以內，可是值得強調的是它確實存在而且能夠提供有用的功能，例如端
到端的性能監控和一些認證受權的形式。

還有一個重要的接口，位於用戶和上游CDN以及下游CDN(圖1中表示爲"Request"接口)的請求路由功能之間。正如在以前的例子中看到的，那個接口
能夠用來做爲傳遞元數據的一種途徑，例以下游CDN從上游CDN獲取內容所須要的最小信息。

在本節中，咱們將提供每一個CDNI接口的功能概述，而且討論它們如何配合到總體方案中。咱們也權衡設計調查，探討幾個跨接口的關注點。咱們從
一個權衡影響到全部接口的檢查來開始——in-band或者out-of-band通訊的使用。
(//)

4.1. In-Band接口 VS Out-of-Band接口

在到達各個接口以前，咱們注意到有一個高級別的設計選擇，涉及到現有的in-band通訊信道和定義新的out-of-band接口。

在peer CDN之間，通訊的信息使用現有的in-band協議須要完成各類互連功能。HTTP 302重定向的使用是一個在in-band中(嵌入到URI中)實現請求路
由方面的示例。注意使用現有的in-band協議並不意味着CDNI接口是空的;用來完成各類接口功能的協議仍然有必要指定規則(約定)。

除了HTTP重定向外，還有其餘的in-band通訊。例如，代理服務器使用的許多HTTP指令也能夠用來對peer CDN之間通知各自的緩存活動。其中，一個
特別相關的是If-Modified-Since指令，用來和GET方法一塊兒使用：若是在這個字段指定的時間內請求的對象未被修改，對象的副本將不會被返回，相
反，會返回一個304(not modified)響應。

4.2. 跨接口的考慮

儘管CDNI接口大部分是獨立的，但有一套在全部接口上一致地執行約定。在這之中最重要的是如何命名資源，例如，CDNI元數據和控制接口對給定的指令
如何識別資源集合，或者CDNI日誌接口識別資源集合。

理論上，CDNI接口能夠明確識別每一個獨立的資源，實際中，使用相似的方式命名資源集合(URI集合)。例如，URL集合能夠經過CDN-Domain(即URI起始處的
FQDN)或者URI-Filter(即CDN-Domain包括URL子集的正則表達式)來標識。換句話說，CDN-Domains和URI-Filters提供了一個統一的含義來聚合URL集合(和
子集)，爲其中一個CDNI接口定義操做範圍。

4.3 請求路由接口

請求路由接口包括兩個部分：異步接口用來使下游CDN向上遊CDN上報網點和能力(標識爲FCI)，容許上游CDN決定是否向這個下游CDN重定向特定的用戶請求
；同步接口用來使上游CDN把用戶請求重定向到下游CDN(標識爲RI)。(這有些相似於IP中的路由和轉發)

如第3節所示，請求路由的RI部分能夠由DNS和HTTP實現。命名約定可能由CDN之間的通訊——是否應該路由一個請求或者服務內容來完成。

咱們還注意到，RI在遞歸重定向中起着重要做用，如3.3節所示。它只是用一個重定向步驟(從用戶角度看)，就可使得用戶被重定向到正確的下游交付節點。
這可能對互連CDN的鏈超過兩個CDN時有特別的價值。對RI更進一步的討論，見[REDIRECTION]。

爲了支持這些重定向請求，每一個CDN之間交換附加信息是必須的，這由請求路由的FCI部分處理。根據須要支持的方法，這些可能包括：
-operator的惟一ID(operator-id)或者有區別的CDN-Domain。
-operator的NS記錄，一套對外可見的Request Routers。
-下游CDN的附加能力，例若有能力支持不一樣的CDNI元數據請求。

注意下游CDN願意服務的請求集合，在某些狀況下能夠是靜態的(例如，一組IP前綴)，所以能夠離線交換，甚至能夠做爲對等協議的一部分進行協商。然而，
它可能更具備動態性，這種狀況下有FCI支持的交換會頗有幫助。更進一步的網點&能力上報接口討論能夠看[FOOTPRINT-CAPABILITY]。

4.4 CDNI日誌接口

上游CDN對重定向到的下游CDN的內容交付具備可見性是有必要的。這容許上游CDN根據下游CDN緩存的多個交付內容，對它的客戶進行合適的計費，以及向這些
CP上報準確的流量統計。這是LI的角色。

其餘和CDNI可能相關的操做數據也能夠經過LI交換。例如，下游CDN能夠向上遊CDN上報它獲取的內容數量，和表明上游CDN緩存的內容消耗了多少緩存容量。

流量日誌能夠簡單的離線交換。例如，下面流量日誌和Apache日誌文件格式有些誤差，其中條目包括如下字段：
-Domain 原始服務器的完整域名
-IP address 請求的客戶端的IP地址
-End time 傳輸的結束時間
-Time zone end time的時區
-Method 傳輸的自身命令(例如GET、POST、HEAD)
-URL 請求的URL
-Version 協議版本，例如HTTP/1.0
-Response 表示傳輸結果的響應代碼
-Bytes Sent 發送給客戶端的字節數
-Request ID 此傳輸的惟一標識符
-User agent 用戶代理，若是提供的話
-Duration 以毫秒錶示的傳輸持續時間
-Cached Bytes 從緩存中服務的字節數
-Referrer 客戶端中的referrer字符串，若是提供的話

其中，只有Domain字段對下游CDN是不明確的——它被上游CDN設置爲CDN-Domain，而不是真實的原始服務器。所以，這個字段能夠用來過濾流量日誌，只有和上游
CDN相匹配的條目會被上報到相應的operator。更進一步的LI討論，能夠見[LOGGING]。

一個未解決的問題是誰來過濾。一種選擇是下游CDN過濾它本身的日誌，並向每一個上游CDN直接發送相關的記錄。這須要下游CDN知道屬於每一個上游節點的
CDN-Domain。若是這個信息(CDN-Domain信息)已經被另外一個接口在peer之間(//CDN之間)交換，則能夠直接進行上報。若是(//CDN-Domain信息)不可用，
而且operators 不但願向他們的peer上報CDN-Domain，則第二個選擇是對每一個CDN發送它的非本地流量記錄和它服務的CDN-Domain集合到一個獨立的第三
方機構(即CDN交換)，這個第三方表明每一個參與的CDN負責過濾、合併和分發流量記錄。

第二個未解決的問題是實時流量信息。例如，除了離線的流量日誌，準確的實時流量監控也多是有用的，這是這些信息要求下游CDN每當它從緩存中服務
上游內容時通知上游CDN。下游CDN能夠作這些，例如，每當它收到終端用戶的HTTP GET請求時向上遊CDN發送一個傳統的HTTP GET請求(If-Modified-Since)
。這容許上游CDN記錄那個請求爲實時流量監控的目的。上游CDN也可使用這個信息來驗證後面從下游CDN收到的流量日誌。

在LI中，另外一個折衷的設計是聚合度或數據彙總。一種適合的狀況是HTTP自適應流(HAS)的交付，由於大量的單獨請求會致使大量的日誌信息。這種狀況在
下面討論，可是其餘的聚合形式也多是有用的。例如，可能諸如字節傳遞的批量指標每小時就足夠了，而不是每一個請求的詳細日誌。看起來可能有一系列
的日誌粒度需求，以及指定類型和聚合度所須要的途徑。

4.5. CDNI控制接口

CDNI控制接口最初用於引導其餘的接口。做爲一個簡單的例子，它能夠用來項上游CDN提供下游CDN日誌服務器的地址，以便引導CDNI日誌接口。也能夠用於，
例如創建其餘接口的安全關聯。

CI的另外一個功能是容許上游CDN對下游CDN進行預約位、從新驗證或者清除元數據和內容。這些操做，有時候統稱爲"觸發接口"，更進一步的討論在[CONTROL
-TRIGGERS]。

4.6 CDNI元數據接口

CDNI元數據接口的角色是使得上游CDN向下遊CDN傳輸CDNI分發元數據。這些元數據包括地理-阻塞限制、可用性窗口、訪問控制策略等等。也可能包括便於下
遊CDN採集內容的信息(例如，內容的替代源，從源採集內容時所需的認證信息)。完整的CDNI元數據接口討論，見 [METADATA]。

某些分發元數據可能部分使用in-band的模擬機制。例如，對於任何地理阻塞限制或可用性窗口的狀況，上游CDN能夠選擇只有當下遊CDN上報的交付網點
對請求的URL是可接受時，向下遊CDN重定向請求。一樣，只有噹噹前時間有可用性窗口時纔會被重定向。然而，這種方法會有缺點，例如對阻止在時間窗
口以外的重播，或者利用下游CDN覆蓋比地理-阻塞限制更廣範的網點。

一樣，一些訪問控制的形式也能夠經過每一個使用HTTP指令執行的請求執行。例如，可以對一個有條件的GET請求作出響應，給了上游CDN一個影響下游CDN如何
交付內容的機會。最小的狀況是，上游CDN可使下游CDN以前緩存的內容無效(即清除內容)。

全部這些帶內技術均可以說明上游CDN能夠對一些訪問控制策略作出選擇(以增長CDN之間通訊負載爲代價)，而不是使用MI向下遊CDN受權執行。做爲一個結果
，MI能夠向上遊CDN提供一種方式，來表達它保留執行力的指望。例如，這能夠經過在元數據中包含一個關聯到確地內容的"check with me"標記。這種經過
各類CDN之間的採集協議(例如HTTP)的帶內技術的實現，須要更進一步的研究，而且可能須要小範圍的擴展或者對採集協議改變語義。

4.7. HTTP自適應流的考慮

咱們考慮HTTP自適應流(HAS)和對CDNI接口的影響，由於大對象(例如視頻)被分割成一系列的小的獨立的塊。對接下來每一個說明，更完全的討論包括權衡的可選
設計的概述，能夠見RFC 6983。

首先，對於內容採集和文件管理，對CDNI接口來講已經超出範圍，可是儘管如此，這些關係到總體運行，咱們假設對於處理大量的塊不須要有附加的措施。這意
味着下游CDN對不一樣的塊沒有明確它們之間的關係，而且下游CDN把每一個塊當作獨立的內容項來處理。結果就是上游CDN和下游CDN之間的內容獲取也是發生在每一個
塊的基礎上。這種方法符合RFC 6983中提出的建議，這也代表了未來可能會對這方面進行改進。

(//意思是上游CDN和下游CDN之間的內容獲取，不須要有附加的措施，下游CDN只要當作每一個塊是獨立的就能夠)

第二，關於請求路由，咱們注意到HAS清單文件可能會對請求路由進行干擾，由於清單文件包括指向內容塊位置的URL。爲了確保清單文件不會妨礙CDNI的請求
路由，而且不會對CDNI資源放置過多的負載，要麼清單文件的使用能夠限制於只包括相對URL，要麼上游CDN能夠在清單中更改URL。咱們處理這些問題的方法
是雙重的。做爲強制性要求，每一個CDN須要有能力處理包括相對或者絕對路徑的URL的未更改的清單文件。爲了限制重定向的數量，和CDNI接口的負載，做爲一
個可選的特徵，上游CDN能夠經過使用CDNI請求路由重定向接口獲取的信息來更改清單文件裏面的URL。由於清單文件的修改是一個上游CDN可選的內部過程，
這不須要作一些標準化的工做。

第三，對於CDNI日誌接口，有幾個潛在的問題，包括大量的獨立請求塊可能致使大量的日誌信息，以及關聯相同HAS會話中的塊請求的日誌信息。對於最初的
CDNI規範，咱們的方法是指望參與的CDN經過CDNI日誌接口支持每一個塊的日誌(例如，把每一個塊當作獨立的內容請求，來記錄每一個塊的請求)。可選的，LI可能
包含一個內容採集標識符(CCID)和/或一個會話標識(SID)做爲日誌字段的一部分，從而使應用程序有益於在這種會話級別信息中(例如基於會話的分析)，促進
在每會話日誌中處理每一個塊的關係。這種方法符合RFC 6983中提出的建議，這也代表了未來可能會對這方面進行改進。

第四，對於CDNI控制接口，特別是對給定的CDN清除HAS塊，咱們的方法是指望每一個CDN支持每一個塊的內容清除(例如，把每一個塊當成獨立的內容項來清除)。可選
的，一個CDN能夠支持基於"Purge IDentifier (Purge-ID)"進行內容清除，容許使用一個引用來清除關聯到給定內容採集的全部塊。這個Purge-ID能夠和上面
討論的HAS日誌的CCID結合到一塊兒，或者，能夠保持不一樣。(//意思就是Purge-ID能夠和CCID使用同一個字段，也可使用各自獨立的字段)

4.8 URI重寫

當使用HTTP重定向，內容URI可能被重寫，當重定向發生在上游CDN內部，上游CDN到下游CDN，下游CDN內部。在級聯CDN的狀況下，內容URI可能在每一跳CDN被
重寫。在任何一對uCDN/dCDN之間使用的內容URI，變成了一個能夠涉及到的公共句柄，在他們的CDN之間通訊中不會模糊不清。這個句柄容許上游CDN和下游CDN
使用其餘CDNI接口在上游方向(例如，當使用LI時)和下游方向(例如，當使用MI時)關聯交換的信息。

考慮一對uCDN/dCDN使用HTTP重定向的狀況。咱們對內容URI介紹了下面的術語，來簡化討論：
"u-URI"表示請求中的內容URI，由上游CDN提供；
"ud-URI"表示上游CDN和下游CDN共同句柄的內容URI，從上游CDN重定向到指定的下游CDN的請求。
"d-URI"表示受權的下游CDN提供的請求中的內容URI。

在咱們簡單的成對示例中，"ud-URI"實際變成了一對uCDN/dCDN用來關聯全部CDNI信息的句柄。特別的，對於給定的一對CDN執行HTTP重定向，上游CDN須要對
全部的MI信息交換時，把u-URI映射到ud-URI句柄，而下游CDN須要在LI信息交換時把d-URI映射爲ud-URI句柄。

在級聯的CDN狀況下，傳輸CDN(//中間CDN)在重定向到下游CDN時會重寫內容URI，從而在傳輸CDN和下游CDN之間創建新的句柄，這個句柄和上游CDN到傳輸CDN
的句柄不一樣。傳輸CDN有責任管理句柄之間的映射，因此全部的兩個CDN之間的正確句柄須要使用它們之間的CDNI通訊。

總之，對給定的一對CDN的全部CDNI接口都須要使用"ud-URI"句柄做爲它們內容URI的引用。

5. 部署模型

在本節中，咱們描述了一些可能實現的部署模型經過使用上面描述的CDNI接口。咱們注意這些模型並非全部的，其餘的許多模型也是能夠的。

雖然圖1的參考模型顯示了每側CDNI接口的全部的CDN功能，能夠根據涉及到這些功能的任何子集進行部署，所以只支持CDNI接口的相關子集。正如已經在第3
節指出的，實際的CDNI部署不須要實現全部的接口。這樣的一些部署的例子以下所示。

注意，雖然咱們指的是上游和下游CDN，可是區別適用於特定的內容項和事物。那就是，給定的CDN對於一些事務來講是上游，可是對其餘的事務是下游，取決
於不少因素例如請求客戶端的位置和請求內容中的特殊部分。

5.1 網狀CDN

雖然圖1的參考模型使用一個上游CDN和一個下游CDN顯示了單向的CDN互連，經過這個能夠創建任意的CDNI網絡，例如圖11所示的網狀例子。(支持任意的網狀
模型可能或者可能不在工做組的初始範圍，可是模型容許這樣作)

5.2 CSP和CDN結合

注意咱們的術語是指功能方面，而不是經濟或商業方面。也就是說，當咱們考慮執行功能時，給定的組織可能同時是CSP和一個完整的上游CDN，如圖12所示。

5.3. CSP使用CDNI請求路由接口

做爲另外一個例子，一個CP可能選擇運行它本身的請求路由功能，做爲從多個CDN選擇的途徑。在這種狀況下，CP可能做爲一個CSP和一個特殊受限CDN的結合的
模型。在這種狀況下，如圖13所示，再請求路由的控制面板下，CDNI請求路由接口能夠用於CP操做的受限CDN和完整CDN組織操做的下游CDN之間。CDNI工做範
圍以外的接口能夠用在CP組織的CSP功能實體和完整CDN(做爲上游CDN)組織操做的CDN，做爲CDNI控制面板，而不是請求路由面板(即控制、分發、日誌)。

(//意思是CP的CDN和上游CDN只進行請求路由通訊操做，其餘的操做在CSP和上游CDN的CDNI控制接口完成，而不用經過CP的CDN)
(//這一節說的就是CSP裏面的CDN只使用CDNI的請求路由接口和上游CDN通訊，而其餘的操做仍是常規的CP和上游CDN之間的通訊)

5.4 CDN聯盟和CDN交換

這裏有兩個附加概念，和以前的CDNI不一樣。第一個是CDN聯盟。咱們的觀點是CDNI是更通常的概念，包括兩個或更多的CDN給他們各自的用戶提供內容服務，雖然
聯盟意味着多邊的互聯方案，可是其餘的CDNI方案也是可能的(例如，兩邊對稱，兩邊不對稱)。一個重要的結論是CDNI技術不該該被假定成一個特定的互聯協議
，而是應該足夠通用，容許發展替代的互聯方案。

第二個常常用在CDN聯盟上下文的概念是CDN交換——一個第三方的代理或者交換用來促進CDN聯盟。咱們觀點是一個CDN交換提供有價值的機制來衡量在一個多邊(
聯盟)協議中的多個CDN，可是這個機制是創建在CDNI機制的核心之上。例如，如圖14所示，交換可能對每一個CDN的網點和能力聚合和從新分配信息，以及收集、
過濾和從新分配流量日誌，這是每一個參與者進行互連結算所須要的，可是DCN內部的請求路由、內容分發(包括內部內容採集)、控制，這些在上游CDN和下游CDN
之間涉及到直接的影響——在成對的對等安排的操做(//意思是CDN之間也會有這樣的操做)。轉到圖14，咱們在這個例子觀察到：

-每一個CDN對其餘的CDN支持一個直接的CDNI控制接口
-每一個CDN對其餘的CDN支持一個直接的CDNI元數據接口
-每一個CDN對CDN交換支持一個CDNI日誌接口
-每一個CDN支持CDN交換的CDNI請求路由接口(用於動態聚合和從新分配CDN網點發現信息)和一個對其餘CDN的直接RI(用於實際請求重定向)

(//主要是利用第三方來控制全部的CDN)

注意，CDN交換能夠可選的支持不一樣的功能集合(例如，只記錄日誌，或者記錄日誌和完整的請求路由，或者全部的CDN功能包括內容分發)。全部這些選項都是
IETF CDNI規範所容許的。

6. 信任模型

在CDNI方案中，有許多須要處理的安全問題。實際上，大可能是相似的或者和一個簡單的不互連CDN中是相同的。(//這些安全問題大多相似，或者和獨立的CDN有
相同的安全問題)。在一個標準的CDN環境中(沒有CDNI)，CSP在必定程度上信任一個獨立的CDN執行多種功能。CDN被信任用於分發內容，對終端用戶提供適當的
質量體驗。CSP信任CDN不會損壞或者修改內容。CSP一般信任CDN根據交付內容的數量，提供可靠的記帳信息。CSP也可能信任CDN去執行一些操做，例如使內容
失效和基於肯定原則例如用戶位置和一天的某個時間來限制用戶對內容的訪問，而且CSP使用URI簽名等技術強制對每一個請求執行受權。

一個CSP也信任CDN不會分發CSP的保密信息(例如一個內容項的熱度)或者終端客戶端的保密信息(例如，哪一個用戶看了哪一個內容)。

一個CSP沒有必要對一個CDN徹底信任。CSP在某些狀況下，能夠經過向CDN分發時，採起措施來保護它的內容，例如加密內容而且使用一些帶外方式分發密鑰。
CSP也依靠檢測(可能來自第三方)和上報來驗證CDN充分發揮做用。CSP可使用基於客戶的計算計數來驗證CDN提供的記帳信息時可靠的。HTTP條件請求可能
用來向CSP提供一些對CDN的檢查。換言之，CSP能夠在短時間內信任一個CDN執行一些功能，在大多狀況下，CSP可以驗證這些動做是否被正確執行和採起行動(
例如把內容移動到不一樣的CDN)若是CDN沒有按照指望執行。(//意思就是CSP能夠驗證動做是否執行，若是CDN沒有正確執行，則採起動做)

其中一個信任問題是CDNI提出的傳遞信任。一個CDN和CSP有直接的關係，能夠向另外一個(下游)CDN"外包"交付內容。那個CDN也能夠外包給另外一個下游CDN，等
等。

這種受權鏈中的頂級CDN有負責確保CSP的需求獲得知足。沒有這樣作大概是由於和傳統的單個CDN狀況同樣嚴重。所以，上游CDN本質是信任下游CDN代其執行
功能和CSP信任獨立CDN的方式是同樣的。監控和上報相似的用來驗證下游CDN正確執行。然而，在CSP和終端用戶的路徑之間引入多個CDN會使畫面複雜化。例如
，第三方對CDN執行(或者其餘方面，例如適時失效)的監控可能有能力指出在交付鏈中的某個地方出現了問題，可是不能指出是哪一個CDN出錯了。

總之，咱們假設上游CDN將會向下遊CDN授予必定的信任，可是它會驗證下游CDN是否正確執行，而且若是行爲不正確時採起糾正措施(包括斷絕和那個CDN的聯繫
)。咱們不指望CSP和它的頂級CDN的信任關係和今天獨立CDN的狀況會有所不一樣。然而，在特定的交付鏈中識別CDN的故障，用來監控CDN執行和行爲的更復雜的工
具和技術是有須要的。

咱們指望CDNI的具體接口的詳細設計將須要考慮到信任傳遞問題。例如，明確確認被下游CDN執行的某些動做(例如，內容清除)，可能有助於緩解一些傳遞信任
問題。

7. 隱私考慮
通常來講，CDN有機會從終端用戶收集詳細行爲信息，例如，記錄下載了哪一個文件。然而本文檔描述的互連CDN的概念，不必定容許一個給定的DCN對任何特定用
戶去收集更多的信息，這有可能經過一個CDN到更多的組織共享這些數據。做爲一個例子，CDNI日誌接口的目的是容許下游CDN向上遊CDN共享一些日誌記錄，用
於計費目的和共享流量統計。實際上CDNI接口提供機制來共享這種潛在用戶敏感信息，代表給這些接口包括適當的隱私和保密機制是有必要的。這些機制的定義
在各自的CDN接口文檔中。

8. 安全考慮
雖然獨立的DN引入了各類安全問題，咱們在這裏特別關注CDN互連時會出現的額外問題。例如，當一個CDN有能力表明一個CSP分發內容時，須要考慮這個內容可
能被分發給沒有被認證的團體，而且有機制來處理這樣的擔憂(//非互連CDN的問題，並且有機制處理)。本節咱們的重點是CDNI如何引入了獨立CDN狀況沒有出現
的新的安全問題。對CDNI安全需求的更詳細的分析，見[RFC7337]的第9節。

CDNI出現的許多安全問題都和傳遞信任有關，如第6節描述的。如上面提到的，爲CDNI接口設計的各類接口必須關心附加的風險，那就是一個和CSP沒有直接關係
的CDN如今可能爲那個CSP分發內容。減輕這些風險的機制可能和獨立CDN狀況相似，可是它們的適用性必須在這種更復雜的環境下驗證。

今天的CDN提供了不少手段來控制內容的訪問，例如時間限制，地理阻塞和URI簽名。這些機制必須在CDNI環境中繼續發揮做用，這種考慮可能會影響某些CDNI
接口(例如元數據、請求路由)的設計。更多關於CDNI中URI簽名的信息，見[URI-SIGNING]。

就像單個CDN同樣，每一個對等CDN必須確保不會被做爲一個"開放代理"來表明惡意的CSP分發內容。獨立的CDN一般經過CSP明確的註冊將要服務的內容(或源服
務器)來解決這個問題，簡單地把這些信息傳遞到下游CDN可能會有問題，由於它泄漏了比上游CDN願意指定的更多的信息。(爲此，前面示例中內容獲取的步驟
強制下游CDN從上游CDN檢索內容，而不是直接從源服務器獲取)

解決這個問題有幾種方法。一種是上游CDN對路由到下游CDN的每一個URL，對從共享密鑰生成的簽名令牌編碼，而且下游CDN對基於這個令牌驗證請求。另外一個是
讓每一個上游CDN上報它們服務的CDN-Domain集合，而後下游CDN在緩存和分發關聯對象以前經過這個集合檢查每一個請求。雖然簡單明瞭，這個方法須要operator
泄漏附加的信息，這可能(可能不)是一個問題。

8.1 CDNI接口的安全性

在RFC7337中注意到，全部CDNI接口必須可以在不安全的IP網絡中安全運行。雖然CDNI接口指望可使用現有的應用協議例如HTTP或者XMPP協議實現，咱們也期 望對這些協議的安全機制也能用於CDNI接口。如何保證這些接口的詳細信息在相關的接口文檔中指定。 8.2 數字版權管理 數字版權管理(DRM),有時候也成爲數字限制管理，一般經過CDN分發內容使用。通常來講，DRM依靠CDN分發加密的內容，經過其餘方式(例如直接從CSP到終端用 戶)給用戶分發解密密鑰。爲此緣由，DRM被認爲已經超出範圍[RFC6707] ，而且對CDNI不會產生附加的安全問題。