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

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

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

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

1　前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5　結(jié)束語(yǔ)

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