帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
RACF架構優勢探討(下)
RACF真能一統NGN QoS江山?

【作者: 鍾慶豐】   2008年01月17日 星期四

瀏覽人次:【7657】

目前RACF所需面對的問題

不管是RACFs或是後面即將談到的RACS QoS控制架構,均與3GPP有關。3GPP現有的蜂巢式網路或GSM網路基礎,發展了IP多媒體次系統(IMS)來控制IP多媒體服務,包含服務控制、通話區段控制…等等。雖然IMS從GSM網路延伸,但是其概念可應用在任何型態的傳送技術,因此IMS架構也曾被推為一種QoS的控制架構。許多標準制訂團體所提議的QoS架構中,多少存在一些IMS的影子,就連ITU-T也不例外,因此RACF或RACS能與IMS具有很好的通透性。一個IMS的參考架構如(圖四)所示。


《圖四 3GPP的IMS參考架構示意圖》
《圖四 3GPP的IMS參考架構示意圖》

除此架構外,封包式(packet-based)網路有數種較為罕見的端點式QoS控制架構,不過仍以ITU-T RACF架構針對核心網路與存取網路,是最具有遠大企圖心的QoS控制方法。雖然目前RACF的規格中,已指定功能架構與IP層的控制程序,但還有許多開放性的問題需要解決。


一般性控制架構與異質網路環境

一般性QoS架構對異質網路而言,意味著可能需要更多的複雜性,以及面臨嚴格的延展性問題。QoS控制機制可以利用核心網路的效能監控資訊加以簡化。舉例來說,call-by-call的QoS控制機制,可以被控制在只有當網路監控程式偵測到網路的效能出現明顯衰退的情況下,才會被啟動。目前各家的QoS控制機制多與特殊運作條件有關,因此要讓QoS控制機制可以在異質網路上適用,將面臨高度的實作複雜度,網路間的通透性也會受到嚴格考驗。再者,因為QoS控制機制建立基礎在於建立每通呼叫程序,因此核心網路的QoS控制機制將會成為重擔。對QoS實作而言,控制機制的複雜度主要集中在最佳化的問題,因此為了降低複雜度,最好一部份的控制功能可被嵌入於傳送設備中,或者與管理功能結合在一起。


核心網路的安全與可信度

對具備有控制延展性的網路而言,核心網路的流量管理會選擇在流量匯集之處,因此如果核心網路無法運作,勢必影響網路流量之匯集。封包式網路不比傳統電路式傳送網路,因為這種IP網路並沒有一個封包遞送的可信特徵。ITU-T在下一代網路,嘗試去改善此不可信的情況,而傳送MPLS(T-MPLS)與乙太網路的運作、管理與維護,也將被定義以改善網路的可信度,並使封包式網路的監控能力發生效用。對諸如IPTV等新式服務而言,行動網路的QoS控制機制,相對也需要被發展。


與傳送技術有關的QoS問題

在ITU-T的草案建議中,將為核心MPLS(core MPLS)、流量狀態感知技術以及乙太網路技術定義一些與傳送技術有關的QoS控制機制。從整體網路流量工程觀點來看,流量匯集與訊號匯集的一般性架構考量,對於建立一般架構的QoS控制機制而言,非常關鍵。這正是目前一般化工作的主要難題所在,因為此兩因素在網路之間存有差異性。


RACF的功能與功能體

PD-FE、TRC-FE和PE-FE

在RACF運作架構中有二個很重要的功能體(functional entities;FE),一個是策略決策功能體(policy decision functional entity;PD-FE),另一個則是傳送資源控制功能體(transport resource control functional entity;TRC-FE)。PD-FE會依據網路中資源的可用性、使用者的相關資料、服務等級同意書(SLA)以及服務優先順序等,決定是否接受用戶端所提出的要求。TRC-FE則負責監控整個區域網路內的拓樸架構資訊以及資源狀態,用以執行資源式(resource-based)的加入許可策略。TRC-FE的設計主要是用來控制傳送的技術要求,而PD-FE則被用來負責與傳送技術相獨立的其他部分,不過目前TRC-FE內尚未定義網路層第二層的控制能力。


在RACF現有版本裡,將QoS定義在傳送獨立的部分,例如定義在IP層。如果經過PD-FE和TRC-FE的許可,來自客戶端的要求被接受,PD-FE便會傳送一個流量控制資訊到傳送裝置,並對網路內的資源進行必要分配。因此PD-FE藉由控制網路中傳送裝置的方式,也控制網路中的QoS能力。一般PD-FE所控制的傳送裝置就被稱為策略執行功能體(policy enforcement functional entity;PE-FE),策略執行功能體通常位在區域網路的邊界或邊緣上。在一個真實的網路環境裡面,PE-FE可以被實作成各種不同型態的成員存在,例如CMTS或邊界路由器。


不同CPE型態的QoS

另外,在RACF中使用者端與用戶端設備(customer premise equipment;CPE)所定義的QoS腳本,不同的CPE類型有著各種不同的QoS發訊能力,而使用者端的CPE型態通常可被歸類為以下三種型態中的其中一種:


  • ●第一型(type I):終端設備沒有QoS的發訊能力。


  • ●第二型(type II):終端設備可以辨識QoS服務等級。


  • ●第三型(type III):終端設備擁有QoS的發訊、路徑方法與能力。



這些不同類型往往也反應其所能使用的QoS策略,對於第一型與第二型的終端設備,以push模式加以控制其QoS。第一型的終端設備的QoS要求,是由SCF所決定,因為該終端設備並不具QoS的發訊能力。如果是第二型的終端設備,因為其存有預設的QoS定義要求,所以並非由SCF來控制QoS等級。至於第三型的終端設備,則會以pull模式加以控制。


push模式或pull模式

因此QoS控制可以用push模式或pull模式,在push模式裡面,一旦QoS要求定義已自SCF接收後,PD-FE會送達QoS策略到傳送裝置(PE-FE)裡。在pull模式中,在PE-FE自終端設備享有具有路徑嵌合QoS發訊能力的傳訊路徑收到QoS訊號後,PD-FE會自PE-FE接收到QoS要求,為了同時支援push與pull模式,在PD-FE及PE-FE之間的參考點,應具有雙向傳遞能力。有關push與pull模式的QoS控制腳本,如(圖五)所示。



《圖五 在push與pull模式的QoS控制腳本示意圖》
《圖五 在push與pull模式的QoS控制腳本示意圖》

push模式流程

在圖五(A)的push模式裡面,每個步驟的通訊內容如下:


  • ●.CPE先提出服務要求給呼叫發訊伺服器(call signaling server;CSS),屬於第一型CPE,或許就不會指定QoS參數。此時,SCF會從應用層來偵測可用合適的QoS參數。


  • ●SCF的功能主要是在識別終端CPE的IP位置及傳送的服務要求,為了識別目標位置,在此或許需要一部CSS代理伺服器(CSS proxy server)。


  • ●終端CPE回應服務要求。


  • ●SCF傳送一個資源要求給核心網路PD-FE,資源要求涵蓋了QoS需求。在圖五中假設SCF可以取得目標CPE的IP位置資訊,當SCF傳送資源要求給PD-FE時,來源與目標IP位置同時也會被指定在訊息之中。


  • ●當PD-FE收到要求後,會基於網路營運者的營運策略做出加入決定(admission decision)。


  • ●若核心網路接受相關要求,PD-FE會傳送一個要求給存取網路PD-FE(當然這),以驗證存取網路之決策,前提是兩個網路中的PD-FE都屬同一網路營運商,或同為一個伺服器。


  • ●核心網路與存取網路的PD-FE,會自TRC-FE確認資源可用性。TRC-FE主要功能在於監控區域網路的可用資源狀態,並回應資源確認要求(resource check request;RCR)。不過此需注意,完成加入決策主要是由兩個功能體來完成,一為PD-FE,另一則為TRC-FE。但這兩者的決策依據略有差異,前者主要是由網路營運者策略做出適當加入決策;後者則依現有的資源可用性來做出決策。


  • ●在存取網路內,PD-FE會和NACF確認所需要的QoS並未超過所授權使用之最大頻寬,而不需要向NACF確認用戶是否有訂購行為,因為此資訊會在CPE連上網路時,自動push給PD-FE。


  • ●在策略確認、資源確認以及訂購確認都完成後,且該要求已被系統允許,PD-FE便會對區域網路內之PE-FE進行適當控管。


  • ●當SCF自PD-FE收到所發出的資源要求回應後,便會對服務要求做出回應。



pull模式流程

如圖五(B)所示,在pull模式下訊號過程其與push模式很類似,但有些差異存在,例如PD-FE不對PE-FE指定資源,而是由CPE以路徑嵌合之QoS訊號對PE-FE直接要求。此外,在pull模式中,QoS控制可以兩階段完成。第一個階段稱為預授權階段(pre-authorization),另一個階段稱為資源分配階段(resource allocation)。


pull模式中的1~9步驟顯示,應用層是以與push模式相同的方式完成QoS發訊,在這些步驟中,提出服務要求前必須先經過預先授權。一般而言,CPE可以藉由回應服務要求過程中取得授權標記。在傳送者取得回應後,來源與目標CPE便可以在開始利用特定路徑傳送QoS訊號前,先交換服務要求的確認訊息。而在步驟11中,CPE會先起始化這些結合QoS訊號的路徑,在收到QoS訊號後,PE-FE會傳送QoS要求給PD-FE,以確認服務是否已被授權。另外,CPE也可能在路徑結合的QoS發訊中,傳送已取得之授權標記(authorization token)。如此,PD-FE只需簡單確認標記值(token value),檢查要求是否符合授權即可。


在PD-FE完成授權確認後,會傳送門閘控制(gate control)訊號到PE-FE功能體,以開啟閘道並分配網路資源。在PE-FE中,路徑結合式的QoS發訊能力,可被實作成終端式、探索式或是代理伺服模式。為了考量延展性,在這幾種不同形式的實作態樣中,終端式與代理模式是較好的選擇。不同的模式對CPE型態與能力亦有所要求,例如對CPE而言,push mode只需要應用層的發訊能力,因此控制程序也相對比較簡單。當第三型CPE終端裝置有路徑嵌合發訊能力(path coupled signaling)時,其QoS的控制可採pull mode。


DSL論壇的QoS標準

@內文DSL論壇提出的TR-094技術報告有關多種服務遞送骨架之家庭網路基礎建設部分,QoS標準主要將焦點放在數位用戶線存取網路資源時的一些資源控制策略。DSL網路流量控制是根據上游網路的差異性服務,亦即,家庭門閘與路由門閘(routing gateway)將資料流量分類為具有差異性服務流量或是一般網路流量。當封包送出網路時,便會鑑別流量型態,因此工作重點在於對家庭網路資源的控制,因此家庭網路中的門閘(gateway)以及網路端的多頻存取伺服器(bRoadband Access Server;BRAS),便成為很重要的網路成員。在DSL網路環境中的QoS,採用集中管理式,而非像Cable網路一樣採取按通(call-by-call)的方式來調整QoS。


Cable Lab的QoS標準

與ITU-T所提議之RACFs架構、以及ETSI所提議之RACS不同的QoS控制架構,還有PackerCable與DSL論壇的資源控制架構。這兩個均將焦點集中在特定的傳送技術,例如HFC網路或DSL網路。


ITU-T與ETSI在處理QoS問題時,已將一般化的概念納入設計之中,將有助於建立統一QoS標準。亦即,PacketCable多媒體QoS策略,是為了因應在cable網路上提供多媒體服務、所發展而來的一種可信控制策略。此架構定義了一種策略式(policy-based)媒體控制服務遞送骨架。控制策略的依據包含按時或按量的資料授權和基本安全架構與資源審計機制(resource auditing mechanism)等等。這種為了光纖與銅纜混合網路(hybrid fiber and coaxial network;HFC network)所定義的動態QoS控制架構,便稱為DQoS(dynamic QoS)架構,只針對HFC網路適用。


DQoS定義了呼叫設定訊號與DOCSIS介面的動態QoS控制。建立控制呼叫的呼叫管理伺服器(call management server;CMS)與門閘控制器(gateway controller;GC),扮演著重要地位。CM與CMTS之間的頻寬保證,由呼叫設定訊號加以動態保留。CMS或GC可以利用觸發網路第二層或第三層QoS訊號的方式,藉由發送命令至CM、CMS或是多媒體終端裝置(multimedia terminal adapter;MTA)的方式,保留所需要的HFC網路頻寬。


後來改版的DQoS,均考慮MTA的型態,不管是嵌入式MTA或是獨立式MTA,DQoS架構均有所變動以切合需要。DQoS 2.0特別針對3GPP以SIP-based為基礎的呼叫設定、發展IP多媒體次系統(IP multimedia subsystem;IMS)的通透性,量身訂作合適的QoS架構。


RACF與RACS的異同點

一般而言RACF與RACS非常類似,除均演變自IMS架構外,這兩個團體在制訂此標準時也頻繁互動,因此在功能上沒有太大的歧異。RACS的存取網路資源控制主要發生於第二層,在控制腳本上遠比RACF少很多,若將兩者比較,看似RACS只是RACF的一個次集合而已。但兩個標準還是有些殊異之處,其中便是控制區域(control region)的範圍。在RACF的控制區域範圍,包含存取網路與核心網路。


所謂的存取網路定義,依據J. Song及M. Y. Chang等人的論述,乃指當網路流量已沒有動態路徑存在、而被匯集或分散的區域;而核心網路(core network)乃指IP路由開始的區域。RACF亦同時涵蓋固定與行動網路,並且比RACS定義有更多可用的控制腳本。而在RACS的控制區域範圍裡面,包含存取網路(access network)以及核心網路的邊界,不過核心網路不在RACS的關心焦點之內,因此並不需要知道核心網路的拓樸資訊(topology information),RACS只關心固定網路而不包含行動網路,RACS的架構如(圖六)所示。



《圖六 ETSI的RACS架構概圖》
《圖六 ETSI的RACS架構概圖》

圖六顯示了RACS的功能簡易架構,在此有兩個QoS執行點(enforcement point),一個位在網路層第二層的終點,另一個位在核心網路邊界上。RACS架構的QoS機制,被放在網路層的第三層,獨立於各種傳送技術。當QoS控制單元、例如存取資源、加入控制功能或服務策略決定功能傳送一個命令給傳送裝置時,QoS控制乃以推送模式(push mode)來完成。此外RACS也定義如何控制位在存取網路或核心網路邊界上的IP節點,存取資源(access resource)與加入控制功能(admission control function)的功能體,則稱為A-RACF,可基於存取網路資源的狀態來決定加入與否,並且服務策略決定功能(service-based policy decision function;SPDF)會完成策略式決策,以及有關核心網路邊界的控制。


後語

本文著重描述一般化標準的QoS控制架構RACF,學界與業界由於著重的焦點不同,在此QoS控制架構中有多種不同的標準制訂主體存在。這些標準制訂主體包含DSL論壇(DSL forum)、Cable Lab、ITU-T以及ETSI…等等。


在ITU-T的下一代網路(next generation network;NGN)架構中,提供了一般性的架構骨架,以涵蓋這些不同標準制訂主體的標準。其他主體標準多著眼於特殊問題,因此,要瞭解一般化的QoS標準,ITU-T的資源與加入控制功能(resource and admission control functions;RACFs)規範具有很大的參考價值。


以上所談的QoS控制流程描述,僅是其中一種方法,實務上亦常存在各種不同的QoS控制流程腳本。例如供核心網路與存取網路使用的PD-FE,亦可能採同一模式,不一定要分設兩組。而SCF也可以和核心網路與存取網路的多個PD-FE進行通訊,以避免受限於兩個網路營運商之間的PD-FE通訊。至於功能體的實體位置應該在哪裡,此乃實作問題。這些不同功能體在不同機器中,也可以同設在單一實體內,例如一個區段邊界控制器(session border controller)通常會與PD-FE、SCF以及PE-FE等功能體,一同放在一個實體裝置內。


另外,代理模式(proxy mode)也可以被用在降低發訊量上,如此PE-FE可以選擇是否匯集這些QoS訊號,在pull模式中的資源控制處理比push模式更為複雜。此外,pull模式需要有路徑結合的CPE QoS發訊能力,然而在pull模式下,資源控制處理雖然比較複雜一點,但是網路資源的使用卻比較有效率,這是因為保留網路資源是在第二階段才會實行所致。在RACF規範中,也定義了網路位址以及通訊埠的移轉(port translation)控制功能,從網路策略角度來看,NAPT會被用在隱藏網路位址的細節,或解決位址空間的不足問題。目前在ITU組織目有關不同的QoS研究主題,分屬不同的研究群組負責,如(表三)所示。


(表三) ITU有關不同的QoS研究主題分責群組

功能

次選項

負責單位

動態QoS控制能力

1.資源與加入控制

2.效能需求的發訊能力

3.QoS機制的相互影響

4.不同網路領域間的考量

5.基礎建設與引導手冊

SG 11、SG 13

客觀效能

1.網路效能類別的建立

2.網路效能之分配

SG 12、SG 16

效能測量與管理

SG 4、SG 12、SG 13

效能的評估

SG 12


ITU-T以自己的NGN(next generation network)架構為基礎,定義了一些QoS控制功能,在此架構中的重要概念之一,便是傳送與服務之間的獨立性。ITU-T將NGN架構切割為傳送組織層面(transport stratum)與服務組織層面(service stratum),希望藉由這樣的切割,保持架構開發的彈性與系統應用上的通透性。未來ITU-T的RACF架構,是否有能力一統QoS江山,非但攸關網路媒體科技的發展方向,同時也宣示了下一代網路多媒體NGM(next generation multimedia)時代的真正來臨。


相關文章
C-ITS: LTE-V2X與ETSI ITS-G5比較
5G時代加速到來,晶片大廠佈局一覽
從C-V2X到5G
802.11n穩紮穩打!
網路通訊用IC的設計技巧(下)
相關討論
  相關新聞
» 從創新到落地!精誠AGP攜手8家新創搶攻企業AI商機
» Rohde & Schwarz 行動通訊測試高峰會聚焦無線通訊最新發展 – 現已提供線上回放
» 精誠「Carbon EnVision雲端碳管理系統」獲台灣精品獎銀質獎 善盡企業永續責任 賺有意義的錢
» 善用「科技行善」力量 精誠集團旗下奇唯科技榮獲「IT Matters 社會影響力產品獎」
» 昕力資訊展現台灣科技實力 參與台灣、波蘭衛星應用合作發展MOU


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.18.188.130.151
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw