| 利用RSVP保障IP Phone語音品質 |
| 前言打過IP Phone的人，都知道通話品質要好，QoS的功能少不了。但是談到QoS，還真是一門很大的學問，所以先用些許篇幅說明一下QoS的理論基礎，然後再進入RSVP的主題。 IP封包QoS的模式可以簡單分成Best-Effort、分類型DiffServ (Differentiated Services)跟整合型InServ (Integrated Services)三種，以使用的比例來說，仍以Best-Effort為最大，譬如今日網路人口最多的Internet，因為ISP頂多擋掉P2P的流量外，沒有實施什麼複雜的管制措施，所以幾乎不強調什麼服務品質的保證。 其次為DiffServ，簡單是其特點，在網路的出入口首先把封包分成不同型態的Class，然後個別Class給予有差異的SLA (Service Level Agreement)與標記(Marking)。簡單來說，SLA與標記可以由路徑上的路由器沿用部份或整個自行定義與操作，重點是這些路由器彼此之間並沒有特別或強制的約定存在。換句話說，end-to-end的QoS是獨立切開再串聯的。因為這種作法是各自為政，所以有著高彈性以及不受限制的好處，如同數據網路理論的Connection-less模式，封包走的路徑並不需先預定，也不見得是固定的。因為DiffServ的模式簡單不複雜，可以完全應用在私人廣域網路的範圍。值得說明的是，嚴格而言，DiffServ的QoS模式並沒有達到完全的保障，如果網路的建置上有oversubscription的情況，end-to-end QoS的SLA條件滿足與否仍是無法完全事先預估的。 最後為InServ的模式，其類似電信網路的Connection-Oriented的模式，如同發話方拿起電話撥號，待對方鈴響接起後才開始交談，然而事前必須先完成許多複雜的步驟。此模式不以封包分類為基準，而是以可以預測的需求為觸發因子；傳送前路徑上的路由器必須事先溝通過，同意建立合乎滿足條件的路徑與預留頻寬，否則不予發生作用。例如[圖1]左邊的PBX交換機，欲建立一個20Kbps的頻寬及20ms延遲SLA條件的資源保留到右邊的PBX交換機，其間有一段一段的交談與共識必須先進行。  圖1：InServ由發話端到收話端的Call Setup模式 雖然InServ看起來SLA的滿足度最佳，但是仍不比DiffServ比較能商業化，因其網路架構可大可小，同時也可以避開不同營運商個別策略與相容性的因素；相對的，InServ的實施也需要有相當的條件，通常僅用於單一大型營運商內部骨幹網路，利用MPLS Traffic Engineering對複雜的多重路徑做流量工程的優化。 一、RSVP Messages的Call Flow簡介InServ的服務模式需要透過資源預留協議(RSVP, Resource ReSerVation Protocol)的信令協定來完成，其中必須注意RSVP的信息是單方向hop by hop建立資源預留的。RSVP主要的信息有PATH、RESV (Reservation-Request)、Error and Conformation及Teardown四種。PATH跟RESV分別是RSVP從Source端與Destination端之間傳遞hop by hop建立需求跟回應的訊息，例如[圖2]，再以Error and Conformation的訊息做確認與否；Teardown的訊息為移除原先PATH或RESV的狀態之用。  圖2：RSVP PATH與RESV messages的示意圖 以[圖3]為例子，假設PC1已建立某頻寬的traffic到PC2，所走的路徑經由R1 R 5 R6 R3 R4等5個Hop Router，其中已將R6跟R3之間的頻寬耗用到只剩下6Kbps。  圖3：PC1已建立頻寬預留至PC2 當PC3預申請建立24Kbps的頻寬到PC4，所走的路徑經由R 5 R6 R3 R8等4個Hop Router，但是R6與R3之間的頻寬出現瓶頸已不足預留一個新的24Kbps頻寬出來，如[圖4]。故R6回傳R5時RESV時伴隨著Bandwidth unavailable的Reservation-Request error message。PC3必須放棄這條路徑，將原先的PATH及RESV的狀態Teardown，另尋建立R 5 R2 R3 R8的中繼站。在此可以看出RSVP的特性可允許去回不同路，因為資源的保留是針對單向而計算的。  圖4：PC3欲申請建立24Kbps的頻寬至PC4 二、CAC允諾控制 對即時與延遲敏感的Voice/Video UDP流量，其表現模式與純Data的TCP/UDP大不相同，QoS以DiffServ模式的做法，通常把Voice及Video放入Strict Priority Queue或提高 DSCP(Differentiated Services Code Point)、Precedence或MPLS EXP之類標計值的方式，讓即時的Traffic能比純Data優先送出。雖然把服務的封包類型做出差異化的處理方式，但是仍有其極限，無法面面俱到。譬如說，對處理即時的封包的Queue Buffer大小也不能太大，愈大的Buffer Size會導致Delay增加，而Buffer Size縮小又會增加封包的遺失率。不管是何種類型的訊務，都要建立一套阻塞控制(Congestion Control)的退場機制，以避免量過大超過負荷，導致發生Packet Loss的現象，降低原有的品質。 管理Voice及Video的流量最合適的阻塞管理方法就是運用允諾控制(CAC; Call Administration Control)。在電路交換網路上，因為具有Connection Oriented的特性，Call的多寡會受到Physical Trunks的通道數量所限制，故不至於影響到即有的通話品質。然而對於分封交換的網路跑VoIP的服務，因為頻寬是分享共用的，如果只限VoIP流量總量而不限通話總數，一但超過流量的上限，多增加一通新的通話，就會開始影響即有通話的語音品質，如[圖5]所示。在DiffServ的QoS Domain上，值得注意此問題的嚴重後果，免不了要加頻寬來解決。  圖5：電路交換網路與分封交換網路CAC的比較 思科把RSVP的技術整合到統合通訊的產品線內，利用RSVP的技術來補強即有CAC允諾控制的完整性，藉由RSVP在有限資源的IP廣域網路頻寬上限制通話撥通與否，讓新建立通話的頻寬不要超過運用頻寬的上限，以阻塞管理來保證穿過廣域網路撥打的IP Phone通訊品質。 三、思科統合通訊的架構介紹說明 思科統合通訊的產品線由語音及IP通信產品及應用組成，可簡單分為四塊(如[圖6]所示)：
思科把RSVP的功能發展在呼叫處理(Call Processing)與底層網路基礎設施( Infrastructure)兩者的設備，為統合通訊網路的部署佈建提供了通訊允諾控制與服務品質QoS的保證，從而提高了Any to Any通訊的可靠性。  圖6：思科統合通訊的組成架構 四、Cisco 統合通訊早期CAC的限制 IP語音電話的設計以中央集權的呼叫處理所佔的比例很高，例如較適用於台灣的用戶，對於分公司與總公司或分公司對分公司之間的話務限量，統合通訊版本5.0以前CAC的做法是以地區為基準(Location-Based)的控制，定義各點的頻寬及語音/影像所使用Codec的型式，來限制各地區之間的通話數量，如[圖7]所示。如果通話數超過上限的，便轉到PSTN上。但是這種方式過於僵化，原因是中央端的Communication Manager缺乏對各點網路架構的敏感度與了解，一但有網路發生斷線，切到備援線路時，如果備援線路受限於較低頻寬的限制，有可能就先把備援線路頻寬給塞暴，也不會轉到PSTN上，對通話品質產生影響。  圖7：早期以地區為基準(Location-Based)的CAC控制架構 因此Communication Manager需要藉重Cisco IOS路由器RSVP Agent的智慧，透過路由器與Communication Manager交換動態的訊息，才能在廣域網路端點對通話數運用CAC，做到嚴謹的QoS控管。架構如[圖8]所示。  圖8：新一代Communication Manager與RSVP Agent CAC架構 五、RSVP Agent的介紹 Cisco 2600XM, 2691, 2800, 3700及3800系列路由器的IOS 12.4(6)T功能提供了RSVP Agent的Feature，RSVP Agent向Communication Manager註冊後，然後以SCCP的通訊協定被Communication Manager管理著。Communication Manager能利用IETF RFC 2205標準的RSVP信號協定，隨網路的變化來動態調整IP廣域網路的頻寬預留，尤其合用於層次更是複雜的網路。尤其當影像電話因頻寬不足無法同時滿足通影像及語音，可以犧牲影像而保語音，避免以往馬賽克又跳針的辛苦。各種機型的RSVP Session容量數也有差異，下表是以路由器純扮演RSVP Agent的角色，CPU Time到達75%的容量數列表。
至於為什麼需要RSVP Agent?如果不透過RSVP Agent，就必須由終端設備自行發出RSVP的Request了。因為終端設備(IP Phone, H.323 Device等)不見得都有支援RSVP這種頻寬預留的能力，因此終端設備需要透過像RSVP Agent這樣的角色來升級至支援RSVP，以達成End-to-end頻寬預留的功能。再者，一般LAN上的通訊用不上CAC，平常只有在進出廣域網路的通訊才有其CAC發揮的意義，故RSVP Agent的存在有其必要性。 六、RSVP Messages具穿透性 Communication Manager利用廣域網路端點Gateway的一對RSVP Agent Sender/Receiver當做眼線，如果廣域網路中間某段的網路如果不支援RSVP，仍不至於讓RSVP的messages封包給擋掉，也不需要建立GRE Tunnel或VPN之類的批步，因為對不懂RSVP封包的路由器，會以一般的IP封包來處理，只是RSVP-unaware的路由器頻寬夠，就不影響RSVP功能的延續。如[圖9]所示。 Communication Manager的RSVP通話允諾控制在建立之初，所提出預留的頻寬會比較大，原因是Codec的取樣頻率不一定，在Call Setup之初用Worst Case來計算，在Call Setup完成之後，就回復實際值了。例如一通G.711的Voice Call在LAN上的頻寬為80Kbps，在RSVP Initial時，是以96Kbps的頻寬來要求的，當建立完成後，所佔的頻寬會回降成80Kbps。若是384Kbps的影像，在Call Setup初期要預留410Kbps的頻寬。  圖9：RSVP Messages具廣域網路的穿透性 七、RSVP Agent的特徵與優勢 除了上述RSVP的一些立論基礎外，因篇幅有限，還有一些RSVP Agent的特徵及優勢僅做簡單的文字說明如下： 1. 可整合DiffServ QoS，修改封包的DSCP(Differentiated Services Code Point)值。 2. 支持SIP、SCCP、H.323、MGCP的呼叫信號協定(Signaling Protocol)。 3. 具有Reservation Retry的能力，可強制必須有足夠的頻寬才通話，連Try數次失效後放棄，或持續嘗試；也可以不強制，即無法先預留頻寬，然後以Best Effort Call再送出。 4. 支援影像與語音的頻寬預留，假如頻寬不夠同時支援影像時，可允許只通Voice。 總結 RSVP技術提供了Call Setup必要的授權管理，以確保Voice跟Video的通話在有限網路資源的可用性。同時不依賴終端用戶設備，以降低IP Phone Client的複雜度。 此外，RSVP提供了Communication Manager除了早期Location-Based之外的另一種通話允諾控制的選項，它的優勢在於RSVP可以知曉網路的實際頻寬使用，以及適用於多層次複雜的網路架構，即使其中有不支援RSVP的節點存在，增加了設計上的彈性。 (文章出處:麟瑞科技 http://www.ringline.com.tw/support/techpapers/network-security/158-rsvpip-phone-.html) |
