接入網路A透過核心網路與接入網路B的溝通

前面兩個情境都是屬於同一個 Access Network 內部的連線交換，在本節中，

考慮到的是一個跨 AN 的連線。其中又將細分為兩個情境：

1. AN 中不具備 Policy Based 的 QoS 機制。

2. AN 中具備 Policy Based 的 QoS 機制。

4.4.1 接入網路不具備PBNM QoS機制

在此情境中，MT1 欲與另一個 Access Network 的 MT2 進行 FTP 連線。但在 其個別的 AN 中，並無具備 Policy Based 的 QoS 機制，因此，為了達到 Policy Based 的 QoS 保證，我們必須透過上層 Core Network 的 QoS Broker 來幫我們達到這樣 的機制。

圖 十六 AN 不具備 PBNMS 之網路架構圖

這個情境與 4.2 的情境作法類似，主要是利用 ANBroker 複製封包傳遞到 CNBroker 的作法。流程如下所示：

圖 十七 實驗 3-1 流程

1. 當 MT1 欲與 MT2 進行 FTP 連線，AR1 收到來自 MT1 的 Request 時，所 先留住所有來自 MT1 的封包，並將這 Request 封包複製一份，然後傳送 目的端改為上層 CN 的 CNBroker。

2. CNBroker 收到封包後，根據封包內容去查詢 PBNMS 裡面的 Policy 規 則。

3. 確定規則之後，CNBroker 會同時對兩個 ANBroker(ANBroker1 及

4. 當兩個 ANBroker 收到各自封包後，再針對其目的 AR 來作網路決定與 設定。

5. AR1 及 AR2 會各自回報其狀況給該 AN 中的 Broker。

6. 各 ANBroker 再回報給 CNBroker。

7. 留在 AR1 的 FTP 封包正式經由 AN1 傳到 CN，然後再傳輸到 AR2，最 後傳到 MT2 手中。

此情境大致上的作法與 4.2 相同，不同的是跨 AN 的傳輸，因此 CNBroker 必須同時掌握兩個 AN 的使用狀況，並且同時對兩個 ANBroker 來作網路設定，

以便提供相對的 QoS 保證。

4.4.2 接入網路具備PBNM QoS機制

在此情境中，在各 AN 中的 Broker 具備有 Policy Based QoS 的機制，因此，

與 4.3.1 情境所不同的，就是各 AN 內部可以獨自根據其內部網路的設定、內部 網路的政策等因素來設定，但也因此在政策上的傳遞、政策上的設定，以及 CN 與 AN 間，或不同 AN 間的政策衝突問題等，會比 4.3.1 情境來的複雜許多。

圖 十八 AN 具備 PBNMS 之網路架構圖

由於各 AN 的用途不同，因此其要求的 QoS 保證也不同。因此在整個網路 架構中，CN 中的政策將擁有一個基本要求、較寬鬆的保證，而個別的 AN 則根 據自己內部網路的設定及用途，來設定屬於自己的政策。然而下層 AN 的政策設 定，除了本身以外，也需考慮上層 CN 的設定，當政策衝突發生時，以兩者中較 上層的網域之政策標準為主。舉例來說，當今天 AN1 與 CN 的政策發生了衝突 時，則 AN1 必須以 CN 的政策為主。

當跨 AN 的情況發生時，除了前述所提到的，須遵守較上層的政策之外，兩 個不同的 AN 也可能有不同的政策設定，也因此可能會有衝突產生。發生這種情 況時，本論文的作法是，利用 CNBroker 來當作一個中介者，來協調三方的政策 衝突。

圖 十九 實驗 3-2 流程

在本論文當中，面對這樣的情況時，CNBroker 的著手點在於收到來自 AR1 的 Request 封包時。當收到來自 AR1 的 Request 封包後，CNBroker 會先查詢自 己 PBNMS 的政策，但此時並未作 Decision 的動作，而是化身成 Client 的角色，

同時對來源端的 ANBroker 及目的端的 ANBroker 發出一個 Request。這個步驟的 目的在於，可以對來源端及目的端做政策的協調，如果沒有這個步驟的話，

CNBroker 僅僅與來源端 ANBroker 作協調，這樣則可能不符合另一個 AN 的政策 設定。

當兩個 ANBroker 收到了 Request 封包時，則會查詢自己網域中的政策設定，

並依據連線內容來作 QoS 保證，並把決定之後的設定傳回 CNBroker。此時 CNBroker 在收到兩個 ANBroker 的設定後，再根據先前所查詢的政策決定結果，

將政策內容的設定作交集，最後取得的決定結果再向兩個 ANBroker 來作設定。

而收到網路設定檔的兩個 ANBroker 則又各自將其 AN 作設定，以提供 QoS 保證，