IP網絡中泛播技術的分析

2019-11-03 09:06:14

字體：大中小

來源：轉載

供稿：網友

溫昱暉　朱祥華　北京郵電大學培訓中心

　　【摘要】隨著Internet技術的迅速發展，服務質量保證體系逐漸成為人們研究的熱點。在分析比較了泛播的各種實現技術的基礎上，探討了應用于QoS網絡的泛播技術所需要的特征，并分析了在區分服務網絡中實現泛播通信的結構及其特點。

　　關鍵詞：泛播（anycast）　QoS　區分服務

1　前言

　　Internet迅速發展，服務競爭不斷加劇，用戶對Internet的需求不再僅僅是連接，已經包括了對服務質量的要求。要提供有競爭的網絡服務就不得不考慮提高向用戶提供滿足他們服務要求的能力，然而ISP所面對的是地理上廣泛分布而數量又極其龐大的用戶。為了提高網絡服務可應用性，在網絡中提供有效的負載分布，即復制服務器有著非?，F實的意義，例如：www鏡像站點、視頻點播（VOD）、股票服務器、計算服務器、以及互聯網的代理服務器等。為了支持服務器復制，泛播（anycast）技術應運而生，并成為ipv6的標準服務。

　　泛播在IPv6中是這樣定義的：泛播地址被分配到兩個以上的接口（一般指不同IP地址的節點），而發送到這個地址上的分組被路由到“最近”的接口?！白罱钡母拍钍怯陕酚蓞f議決定的，它可以包括路由器跳數、服務器負載、到該服務器的往返時間（RTT，round－trip time）、鏈路的可用帶寬和其它任何提供“最好”特征值（metric）的服務。簡單的可以把泛播理解為將一個泛播地址分配給一組具有相同功能或內容的服務器集合，當客戶需要服務的時候，從該服務器集合中將選出一個離客戶“最近”的服務器來向客戶提供服務。

　　2　泛播實現的兩種技術

　　一般來講，與泛播相關的研究可分為兩類：一是在應用層通過管理手段實現泛播服務，被稱為應用層泛播。另一是在網絡層采用程序和協議完成泛播消息的路由和選址，稱為網絡層泛播。

2．1　網絡層泛播

　　在早期提出的泛播實現方法中，客戶僅需要知道服務的泛播地址，最近的服務器將在路由器上被選擇，這被稱作網絡層的泛播。網絡層泛播基本采用了兩種方法來路由泛播分組。

2．1．1單路徑路由（SPR）

　　對于單路徑路由，所指定的源目的主機對之間的路徑只有一個；也就是說，信息從源端到目的端所經過的路徑是時不變的，除非網絡的拓撲結構發生了變化；單路徑路由簡單并且易實現，已經得到廣泛的應用。例如，在當前的網絡中，最普遍采用的路由算法是最短路徑路由（SPF）算法。

　　單路徑路由可能存在這樣的問題，它可能造成所選擇的路徑過載，從而造成業務流擁塞。這時就提出了多路徑路由來解決這個問題。

2．1．2多路徑路由（MPR）

　　一個多路徑路由算法將業務流拆分到幾個不同路徑上。許多分析已證明業務流被分布到多路徑上，網絡吞吐量和延遲都得到了很大的改善［4］［5］［6］。

　　圖1　泛播名字解析的請求／響應環問題。多路徑路由自身就隱含著路由中存在環的風險，相應的路由算法必須能夠有效的防止環的產生；另一個問題是怎樣從多條路徑中選擇一條，使網絡的特性（如延遲和吞吐量等）能得到有效的改善。幾種方法如SSP、MD、SBT和CBT［1］已經被提出用來解決第一個問題。WRS［1］等可應用于后一個問題的解決。

　　實際上采用多路徑路由，其路由器也需要額外的存儲器來維護使用的多路徑信息，而這往往是巨大的，存儲器尺寸的限制實際會造成分組延遲的增大，最近提出的集成路由（Integrated Routing）［2］的技術被認為可以解決這個問題。

2．2　應用層泛播

　　網絡層泛播是通過規定泛播IP地址的使用來支持泛播服務，而在應用層采用泛播域名（ADN）來支持泛播服務的方法［7］，稱為應用層泛播。應用層泛播服務的功能實現是將泛播域名（ADN）映射到一個或多個（組播或單播）地址上，它不要求對網絡層操作進行改動，這被看作是應用層泛播的重要特征。采用應用層泛播服務的基本結構是用泛播解析器（resolvers）來實現AND到IP地址的映射。客戶按照一個基本的請求／響應環來與泛播解析器進行相互聯系，如圖1所示。一個客戶產生一個泛播請求，而解析器處理這個請求，并且用一個泛播響應來回答。這個系統的關鍵特征是有一個特征值（metric）數據庫，數據庫存儲著有關服務器特性的數據，在基于用戶規定的特性要求基礎上，這些數據被用來在一組服務器中作出一個最佳選擇。同時，一個泛播解析器要實現從ADN到IP地址的映射，必須要維護相關的信息，包括：形成特定泛播組的IP地址和泛播組中的每個成員相關的測量信息。

3　網絡層泛播和應用層泛播比較

3．1　網絡層泛播的局限性

　　網絡層泛播是最早提出的泛播技術，由于最初提出時Internet正處于發展的初期，對網絡服務質量的需求還沒有那么迫切，在盡力而為的網絡中是能夠適應需求的，但是隨著Internet的驚人發展，網絡層泛播技術的一些局限性越來越明顯，需要繼續深入研究解決。這些局限性主要表現在如下幾個方面：

　　·必須為泛播地址分配一部分IP地址空間，對于IPv4，可從現有的地址空間中分配一部分或創建一個獨立的地址空間用于泛播地址，一般在C類地址中［3］。在IPv6中，特別為泛播分配了專有的地址空間［8］。

·泛播地址的使用需要路由器的支持。　

　·發送泛播數據報所選擇的服務器完全由網絡決定，而用戶不能參與。

　　·由于IP是無狀態的，目標是基于每數據報決定的。因此連續的數據報序列可能被發送到具有相同泛播地址的不同主機上。

　　·網絡層雖然能有效地決定最短路徑，但這只能適于這樣的泛播服務：基于最短路徑的特征值（例如：跳數）來選擇最近的服務器。

3．2　應用層泛播的特點

應用層泛播在一定程度上克服了網絡層泛播的局限性，特別是應用層泛播更能適應處理不同的特征值機制，例如服務器吞吐量等其它QoS要求，這對于QoS網絡具有重要的現實意義。在本文的第四部分將繼續探討應用層泛播在QoS網絡中的實現。

　　然而應用層泛播要維護泛播組測量信息，就需要不斷刷新從而增加了信令的負荷。

4　基于QoS網絡中的泛播體系結構

　　基于QoS網絡的泛播服務可這樣定義［9］：假如一個客戶向某個同等（equivalent）服務器集合請求服務，就需要選擇一個滿足客戶QoS要求的服務器和客戶－服務器之間的路徑?？蛻舻恼埱笾辽侔ㄆ谕盏拿趾蚎oS需求。相應的按照客戶的請求從一個服務器集合中選出一個能提供期望服務的服務器。

　　IETF提出了一些滿足QoS要求的服務模型和機制，這其中包括集成服務／資源預留（RSVP）模型、區分服務（DS）模型、多協議標簽交換（MPLS）、流量工程（TE）和基于約束的路由等。本文僅針對區分服務網絡中泛播的應用進行了探討。

4．1　區分服務

　　區分服務將區分域中的路由器分為邊緣路由器和核心路由器。邊緣路由器與終端或其他域的路由器連接。核心路由器則僅僅與所在域的路由器相連。在一個區分服務網絡中，核心路由器僅僅執行一些簡單的操作，而將更加復雜的操作推到了邊緣路由器上。當數據分組進入一個區分域時，它們將在邊緣路由器上被整形、分類、標識和測量等。通過邊緣路由器后，分組按照某種聚合流被標記，以響應一個每跳轉發方式（PHB）。PHB定義了怎樣轉發分組的方式。核心路由器則基于PHB處理分組，也就是說，共享相同PHB的分組將按照相同的方法被處理，在這里所定義的PHB的數量是有限的，從而提高了擴展性。在區分服務網絡中只有提供相應的資源，QoS才能得到保證。資源的管理是通過相鄰區分服務域之間的協商來實現，這被稱為服務級別協定（SLA）。區分服務域正是基于SLA配置它們的邊緣和核心路由器，以向區分服務業務流提供足夠的資源。同樣，通過路徑上所有相鄰的SLA協商，從而實現端到端的QoS。而每個區分服務域中的資源管理則可以由稱為帶寬經紀（Bandwidth Broker，BB）［13］來實現。

4．2　區分服務網絡中泛播結構分析

　　要向泛播客戶提供端到端的QoS保證，就需要在從服務器到客戶的路徑上，發現可用資源并作相應的預留。然而一般區分服務中的BB并不共享資源可用信息，也不在網絡中維護全網的狀態信息。這就需要在BB之間采用信令的方式實現資源的發現和預留。在第二部分中，我們已經討論過應用層泛播技術能夠依據多種測量信息選擇服務器：通過對區分服務網絡中各個服務資源的了解，選擇最適合的服務器域并作出最佳服務器的決定。因此，在QoS服務網絡中要實現泛播服務，應用層泛播無可非議是首選的技術。

4．2．1　區分服務網絡中泛播通信的體系結構

　　區分服務網絡中泛播通信的結構［9］是基于解析器和服務器代理（server agents）來實現的。在每個包含有泛播客戶的域中都有一個解析器，一個完整的泛播組可以共享一個服務器代理；而一個服務器代理可被多個泛播組共享，如圖2和圖3。在客戶方面，服務器的選擇是相當簡單的：當客戶需要訪問服務時，它與自己域中的解析器聯系，請求服務器地址，解析器回答一個能滿足客戶QoS請求的服務器地址。接著客戶向服務器發出請求后，服務器開始發送數據。至于解析器，首先必須評估域中的客戶需求，并與服務器代理或BB聯系，做出服務器選擇決定并預留資源。服務器代理要從每個服務器處收集動態QoS信息。任何時候服務器負載發生顯著變化時，服務器將向服務器代理推出刷新消息，以實現動態QoS信息的收集。通過解析器、服務器代理和BB之間的信令，從服務器域到客戶域按照QoS需求實現了資源預留。在這個結構中，根據信令方向，可分為前向信令（forward signaling）和后向信令（backward signaling）。

4．2．2　前向信令和后向信令的比較

　　在前向信令中（圖2所示），解析器向服務器代理請求選擇一個服務器域并預留資源。服務器代理首先選出資源可用的服務器域列表，然后以一定的次序與列表中的每一個服務器域的BB聯系，直到滿足QoS要求的資源被預留。

　　在后向信令中（如圖3），解析器也向服務器代理請求，得到資源可用的服務器域列表，然后向自己所在域的BB請求，從所得到的候選服務器域中獲得一個或多個資源預留。

　　可見，后向信令是從客戶域“流向”服務域；而前向信令則是由服務域到客戶域，這就要求路徑上的每個BB都要決定信令的方向。由圖4比較可知，后向信令要比前向信令更加有效，這是因為：一、后向信令消息是基于根方向的。消息被發送到每個鏈路上，因此總的信令消息個數減少。二、后向信令“修剪”無效的鏈路（資源不充足的鏈路）要比前向信令更快更有效。由圖4（a）可知，前向信令“修剪”無效鏈路，僅僅是“修剪”了一條旁枝或是葉。

　　不過，后向信令也需要BB的額外支持，即BB能用上行信令數據流代替下行數據流。這是因為一般從發送方到接收方的路徑和從接收方到發送方的路徑是不同的，需要尋找一條上行路徑，以便BB向那里發送信令消息，因此后向信令在某種程度上要稍微復雜些。

5　結束語

　　區分服務的研究主要集中在不同的PHB特性的定義上［12］，而域內服務配置方案的設計，即在配置網絡節點時應使哪些流得到特殊對待、資源的使用應遵循什么原則，還有待深入的研究。至于泛播通信，雖然IETF提出較早［3］，但也就是最近幾年隨著Internet的迅猛發展，泛播通信在提高網絡資源的利用率，提供多媒體通信的端到端QoS保證上有其獨特作用，才又引起學術界的廣泛關注，不過它的實現方式還存在廣泛的爭議，網絡層泛播和應用層泛播應用條件同樣需要深入的研究討論。

參考文獻

1　D．Xuan，W．Jia．，＂A Routing Protocol for Anycast　　Messages，＂IEEETrans．Paral＆Sys．vol11．no．6．June 2000．

2　W．Jia，D．Xuan，and W．Zhao，．＂Integrated RoutingAlgorithms for Anycast Messages，＂IEEE Trans．Commun．，Jan．2000．

3　C．Partridge，T．Mendez，andW．Milliken．，＂HostAnycastingService，＂RFC1546，Nov．1993．

4　I．Cidon，R．Rom，＂Multi－Path Routing Combined with　Resource Reservation，＂Proc．IEEEINFOCOM＇97，Apr．1997．

5　A．Jean－Marie and L．Gun，＂Parallel Queues with　Resquencing，＂J．ACM，vol．40，no．5，Nov．1993．

6　A．Jean－Marieand Z．Liu，＂AStochastic Comparison forQueuing Modelsvia Random Sumsand Intervals，＂J．Advanced　　Applied Probabilities，no．24，1992．

7　S．Bhattacharjeeetal．，＂applicationLayAnycasting，＂Proc．IEEEINFOCOM＇97，Apr．1997．

8　R．Hinden and S．Deering，＂IP version 6 addressingarchitecture，＂RFC1884，December1995．

9　F．Hao，Z．EllenandA．Mostafa．，＂QoSRoutingforAnycastCommunications：Motivation and an Architecture for Diffserv　Networks，＂IEEETrans．Commun，June 2002．

10　X．Xipengand N．Lionel．，＂InternetQoS：ABigPicture，＂IEEENetwork，March／Apirl1999．

11　S，Blake，etal．＂AnArchitectureforDifferentiatedServices，＂RFC2475，Dec．1998．

12　IETFDifferentiated Services Working Group Chater．http：／／www．ietf．org／charters／diffserv－charter．html．

13　K．Nichols，V．Jacobson，and L．Zhang，＂ATwo－BitDifferentiated Services Architecture for the Internet，＂RFC2638，July 1999．

摘自　北極星電技術網

上一篇：IP VPN在電信運營網絡中的實現

下一篇：IP網絡拓撲自動發現