IP網(wǎng)絡(luò)中泛播技術(shù)的分析

溫昱暉　朱祥華　北京郵電大學(xué)培訓(xùn)中心

　　【摘要】隨著Internet技術(shù)的迅速發(fā)展，服務(wù)質(zhì)量保證體系逐漸成為人們研究的熱點。在分析比較了泛播的各種實現(xiàn)技術(shù)的基礎(chǔ)上，探討了應(yīng)用于QoS網(wǎng)絡(luò)的泛播技術(shù)所需要的特征，并分析了在區(qū)分服務(wù)網(wǎng)絡(luò)中實現(xiàn)泛播通信的結(jié)構(gòu)及其特點。

　　關(guān)鍵詞：泛播（anycast）　QoS　區(qū)分服務(wù)

1　前言

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

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

2　泛播實現(xiàn)的兩種技術(shù)

　　一般來講，與泛播相關(guān)的研究可分為兩類：一是在應(yīng)用層通過管理手段實現(xiàn)泛播服務(wù)，被稱為應(yīng)用層泛播。另一是在網(wǎng)絡(luò)層采用程序和協(xié)議完成泛播消息的路由和選址，稱為網(wǎng)絡(luò)層泛播。

2．1　網(wǎng)絡(luò)層泛播

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

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

　　對于單路徑路由，所指定的源目的主機(jī)對之間的路徑只有一個；也就是說，信息從源端到目的端所經(jīng)過的路徑是時不變的，除非網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)發(fā)生了變化；單路徑路由簡單并且易實現(xiàn)，已經(jīng)得到廣泛的應(yīng)用。例如，在當(dāng)前的網(wǎng)絡(luò)中，最普遍采用的路由算法是最短路徑路由（SPF）算法。

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

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

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

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

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

2．2　應(yīng)用層泛播

　　網(wǎng)絡(luò)層泛播是通過規(guī)定泛播IP地址的使用來支持泛播服務(wù)，而在應(yīng)用層采用泛播域名（ADN）來支持泛播服務(wù)的方法［7］，稱為應(yīng)用層泛播。應(yīng)用層泛播服務(wù)的功能實現(xiàn)是將泛播域名（ADN）映射到一個或多個（組播或單播）地址上，它不要求對網(wǎng)絡(luò)層操作進(jìn)行改動，這被看作是應(yīng)用層泛播的重要特征。采用應(yīng)用層泛播服務(wù)的基本結(jié)構(gòu)是用泛播解析器（resolvers）來實現(xiàn)AND到IP地址的映射�？蛻舭凑找粋�基本的請求／響應(yīng)環(huán)來與泛播解析器進(jìn)行相互聯(lián)系，如圖1所示。一個客戶產(chǎn)生一個泛播請求，而解析器處理這個請求，并且用一個泛播響應(yīng)來回答。這個系統(tǒng)的關(guān)鍵特征是有一個特征值（metric）數(shù)據(jù)庫，數(shù)據(jù)庫存儲著有關(guān)服務(wù)器特性的數(shù)據(jù)，在基于用戶規(guī)定的特性要求基礎(chǔ)上，這些數(shù)據(jù)被用來在一組服務(wù)器中作出一個最佳選擇。同時，一個泛播解析器要實現(xiàn)從ADN到IP地址的映射，必須要維護(hù)相關(guān)的信息，包括：形成特定泛播組的IP地址和泛播組中的每個成員相關(guān)的測量信息。

3　網(wǎng)絡(luò)層泛播和應(yīng)用層泛播比較

3．1　網(wǎng)絡(luò)層泛播的局限性

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

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

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

　·發(fā)送泛播數(shù)據(jù)報所選擇的服務(wù)器完全由網(wǎng)絡(luò)決定，而用戶不能參與。

　　·由于IP是無狀態(tài)的，目標(biāo)是基于每數(shù)據(jù)報決定的。因此連續(xù)的數(shù)據(jù)報序列可能被發(fā)送到具有相同泛播地址的不同主機(jī)上。

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

3．2　應(yīng)用層泛播的特點

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

　　然而應(yīng)用層泛播要維護(hù)泛播組測量信息，就需要不斷刷新從而增加了信令的負(fù)荷。

4　基于QoS網(wǎng)絡(luò)中的泛播體系結(jié)構(gòu)

　　基于QoS網(wǎng)絡(luò)的泛播服務(wù)可這樣定義［9］：假如一個客戶向某個同等（equivalent）服務(wù)器集合請求服務(wù)，就需要選擇一個滿足客戶QoS要求的服務(wù)器和客戶－服務(wù)器之間的路徑。客戶的請求至少包括期望服務(wù)的名字和QoS需求。相應(yīng)的按照客戶的請求從一個服務(wù)器集合中選出一個能提供期望服務(wù)的服務(wù)器。

　　IETF提出了一些滿足QoS要求的服務(wù)模型和機(jī)制，這其中包括集成服務(wù)／資源預(yù)留（RSVP）模型、區(qū)分服務(wù)（DS）模型、多協(xié)議標(biāo)簽交換（MPLS）、流量工程（TE）和基于約束的路由等。本文僅針對區(qū)分服務(wù)網(wǎng)絡(luò)中泛播的應(yīng)用進(jìn)行了探討。

4．1　區(qū)分服務(wù)

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

4．2　區(qū)分服務(wù)網(wǎng)絡(luò)中泛播結(jié)構(gòu)分析

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

4．2．1　區(qū)分服務(wù)網(wǎng)絡(luò)中泛播通信的體系結(jié)構(gòu)

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

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

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

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

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

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

5　結(jié)束語

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

參考文獻(xiàn)

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．

摘自　北極星電技術(shù)網(wǎng)