新聞中心

EEPW首頁 > 手機與無線通信 > 設計應用 > IPv4-IPv6組播過渡技術

IPv4-IPv6組播過渡技術

——
作者:中國聯(lián)通網(wǎng)站 時間:2006-11-24 來源: 收藏
在下一代互聯(lián)網(wǎng)中,已確定必須實現(xiàn)對組播的支持,并安排了大量的組播地址空間。雖然在開始應用后純節(jié)點會越來越多,但許多節(jié)點依然會因為它們的成功運作而繼續(xù)存在。因此短期內IPv6無法全部替換,兩者必定會在很長一段時間內共存。在這一漫長的共存期中,按照IPv6的部署策略,純IPv6將會區(qū)域性地不斷出現(xiàn)。此時,將呈現(xiàn)出純和純IPv6網(wǎng)絡共同存在,互相交錯的局面。

因此,必須有一套機制來保證IPv4與IPv6節(jié)點能直接通信以實現(xiàn)平滑過渡。目前,已有相當多的過渡技術被提出,但它們只適用于單播通信,還不能適用于組播通信。雖然組播通信的過渡技術尚未成為人們研究工作的重心,但作為一個很有實際應用意義的研究方向,已經(jīng)開始被越來越多的組織和團體關注[1-4]。

1 組播過渡技術

1.1 雙棧技術

雙棧的組播過渡解決方案實際上是純IPv4組播網(wǎng)和純IPv6組播網(wǎng)兩者的疊加。單播中,可以將服務器配置成雙棧,以便純IPv4和純IPv6的主機能夠輕松地訪問它。同樣,組播源也可以配置成雙棧,同時向IPv4組和IPv6組發(fā)送數(shù)據(jù)流,使運行不同協(xié)議棧的所有主機都能接收組播報文。

在雙棧網(wǎng)絡上IPv4和IPv6組播可以同時部署。IPv4和IPv6組播能同時運行在路由器和主機上,并且能同時存在于同一網(wǎng)絡鏈路;路由器也能同時成為IPv4組和IPv6組的匯聚點(RP)。

對于簡單的單源情況,如果數(shù)據(jù)流只存在于一個封閉環(huán)境中,所有潛在接收者都支持同一IP協(xié)議,則源只需要使用這一IP協(xié)議。在更多的開放環(huán)境中,潛在接收者及其支持的IP協(xié)議是未知的,為了確保所有接收者都能夠接收,需要有一個IPv4源和一個IPv6源,此時必須保證兩個源都使用同一源數(shù)據(jù)。

只有少量源時,可以利用雙棧技術,將所有源配置成雙棧,同時向IPv4組和IPv6組發(fā)送報文。但在一個視頻會議中,幾乎每個人都要同時接收和發(fā)送數(shù)據(jù),并且一部分參與者使用純IPv4,另一部分使用純IPv6,在這種情況下雙棧技術將無能為力。另外,使用雙棧技術時,帶寬的耗費將是原來的兩倍。

雙棧技術不需要額外的設備,也不需要對組播數(shù)據(jù)做額外的轉換。因此,是最容易實施的一種方案。適用于應用環(huán)境中不需要IPv4主機與IPv6主機之間進行通信的情況,如內容分發(fā)。

1.2 協(xié)議轉換技術

協(xié)議轉換技術可以在無需改動基礎設施的情況下,使IPv6主機能像與IPv6組播組通信一樣,使用普通的IPv6組播協(xié)議與任何IPv4組播組通信。其核心思想是:在使用一種IP協(xié)議的源和使用另一種IP協(xié)議的宿之間的路徑上放置一個或多個轉換設備。在極少數(shù)的情況下,轉換也在發(fā)送或接收的主機上完成,這主要針對運行在雙棧主機上但僅支持一種IP協(xié)議的應用程序。常用的轉換方法有以下幾種:

(1)

IPv4中,(Reflector)方案在無法全局組播時經(jīng)常被采用。虛擬房間視頻會議系統(tǒng)(VRVS)是一個典型的例子,它在核心網(wǎng)上采用純組播,在無法直接通過組播的區(qū)域設置作為此區(qū)域的組播代理。核心網(wǎng)與轉發(fā)器之間采用單播方式連接,轉發(fā)器與端系統(tǒng)之間可以采用純組播也可以使用單播。

IPv4-IPv6組播轉發(fā)器在IPv4和IPv6組播之間進行轉換(Reflect),而不是在單播與組播之間進行轉換。給定IPv4組地址和端口及IPv6組地址和端口,轉發(fā)器將同時加入兩個組并監(jiān)聽相應的端口,從一個組接收到的所有數(shù)據(jù)將重新發(fā)送(Resend)至另一組。

按照IPv6的過渡進程,轉發(fā)器可以有以下兩種部署方案:當內容提供者所使用的協(xié)議沒有被廣泛支持,并且主機或應用程序不支持雙協(xié)議時,轉發(fā)器位于源附近;當接收者使用不同于源的另一種協(xié)議時,那么在接收者附近放置轉發(fā)器也是非常有效的。

轉發(fā)器方案主要缺陷是性能較低,不能支持大規(guī)模的組播應用。另外它必須為每個會話都啟用一個實例,即使沒有接收者,它仍執(zhí)行接收重發(fā)的過程。

因為上述的局限,轉發(fā)器可以被用來為多個組播組工作,但同時工作的會話數(shù)量有限。如果利用轉發(fā)器在網(wǎng)絡上提供服務,用戶必須聯(lián)系管理員,申請在有限的時間內分配一個會話;或者可以像隧道代理(Tunnel Broker)一樣,使用Web認證等輔助措施來使會話分配過程自動化。

(2)

組播過渡技術的發(fā)展晚于單播過渡技術,因此大部分組播過渡技術都不同程度地借鑒了單播過渡技術的思想。雙棧技術自然毋須多言,因為它在組播過渡技術與單播過渡技術中完全是一致的。轉發(fā)器技術工作于傳輸層,從而避免了報頭轉換,這與單播過渡的TCP-UDP中繼技術的思想是一致的。IPv4-IPv6組播則是一種類網(wǎng)絡地址轉換/協(xié)議轉換(NAT-PT)的方案。

NAT-PT[5]主要是針對單播提出的,并不能完全適用于組播。根據(jù)NAT-PT的思想,結合組播自身的特性優(yōu)化改進,從而形成適合組播的IPv4-IPv6過渡技術。

網(wǎng)關的思想是將IPv4組播地址通過加上指定“/96”的前綴嵌入到IPv6地址中,從而每一個IPv4組播地址都有一個相應的IPv6組播地址;同樣,每個IPv6地址也都和一個IPv4地址對應。參與組播過渡的IPv4與IPv6地址之間是一一映射的關系,這是IPv4-IPv6組播網(wǎng)關一個至關重要的特性。正是因為這個特性,協(xié)議轉換的工作才能夠順利地進行。

網(wǎng)關可以部署在IPv4和IPv6網(wǎng)絡的邊界,也可以放置在雙棧網(wǎng)絡中。它可用于單個站點或組織,也可以作為服務在大型網(wǎng)絡上提供。需要的話,甚至可以為同一網(wǎng)絡部署多個網(wǎng)關。

網(wǎng)關的主要不足有兩點:對IPv4組播的組成員及源的有效期不敏感、IPv4只能訪問給定前綴的IPv6組。

網(wǎng)關最大的優(yōu)勢在于提供IPv4和IPv6組播的相互通信機制,使用網(wǎng)關可以建立同時存在IPv4和IPv6的多方視頻會議,并可進行全雙向連接。NAT-PT已逐漸成為主要的單播過渡方案,與之相近的網(wǎng)關組播過渡方案無疑是適用性最廣泛的過渡方案之一。

(3)其他過渡技術

6over4過渡技術將IPv4網(wǎng)絡當作具有組播功能的一條鏈路,通過IPv6組播地址和IPv4組播地址的映射關系實現(xiàn)IPv6協(xié)議的鄰居發(fā)現(xiàn)功能,使孤立IPv6主機之間形成IPv6互聯(lián)。這種單播過渡機制本身就是采用IPv4組播作為其底層載體,用于IPv6組播時,只將其目的地址映射到專私用組播地址域??239.0.0.0/8。因為6over4過渡技術本身并未大規(guī)模地應用,基于它的組播技術很少被提及。

應用層組播(ALM)在應用層實現(xiàn)組播功能,而不是在網(wǎng)絡層實現(xiàn)組播功能。其實際是一種疊加于單播網(wǎng)絡的邏輯網(wǎng)。因此,ALM的過渡由應用層來保證。它的過渡問題最終歸結為單播IPv6過渡。NAT-PT+ALG是在現(xiàn)有NAT-PT的基礎上加入組播應用層網(wǎng)關(ALG)以滿足組播的需求。韓國的ETRI項目和以及歐洲的GTPv6項目曾經(jīng)提出過這種方案。

隧道技術將一種協(xié)議的組播報文封裝在另一協(xié)議報文中,從而可以實現(xiàn)組播的跨網(wǎng)傳輸。雖然目前不是所有的隧道過渡技術都支持組播,但在加入需要額外的功能代碼后,很多都可以支持。所有的隧道技術均是基于雙棧的,因此不能實現(xiàn)純IPv6主機和純IPv4主機之間的通信。

2 多播轉換網(wǎng)關模型

多播轉換網(wǎng)關(MTG)模型是基于Linux2.4內核的網(wǎng)關協(xié)議轉換方案原型。

MTG模型在網(wǎng)絡中的部署如圖1所示,MTG部署在IPv4和IPv6網(wǎng)絡的邊界。MTG模型將IPv4網(wǎng)絡和IPv6網(wǎng)絡視為地位對等的兩個異構網(wǎng)絡。從網(wǎng)關向兩邊看,一邊是純IPv4網(wǎng)絡,另一邊是純IPv6網(wǎng)絡。網(wǎng)關的工作對IPv4和IPv6而言也是對等的:IPv6主機可以加入組播源位于IPv4網(wǎng)絡的組播組,IPv4主機也可以加入組播源位于IPv6網(wǎng)絡的組播組。

 

                        mtg模型在網(wǎng)絡中的部署

在IPv4中,MTG作為IPv6的代理,參與IPv4的組播;同樣,MTG在IPv6中則作為IPv4的代理。圖中MTG既可理解為單個雙棧設備,也可理解為一個雙棧網(wǎng)絡。在MTG系統(tǒng)內部,兩個代理之間進行協(xié)議轉換。

2.1 模型結構

圖2虛線框部分給出了MTG的模型結構。主要由IPv4組播代理(MP4)、IPv6組播代理(MP6)、組播協(xié)議轉換器(MT)、地址映射器(AM)、簡單網(wǎng)絡管理協(xié)議(SNMP)接口、MTG管理信息庫(MIB)組成。

                 mtg的模型結構

 

(1)IPv4組播代理

IPv4組播代理作為IPv6接收節(jié)點的代理加入IPv4組播組,接收從IPv4流出的組播報文,再將報文轉交給組播協(xié)議轉換器。IPv4組播代理的主要工作包括:向IPv4網(wǎng)絡發(fā)送Internet組管理協(xié)議(IGMP)消息,向IPv4網(wǎng)絡發(fā)送組播數(shù)據(jù),從IPv4網(wǎng)絡接收組播報文。向IPv4網(wǎng)絡發(fā)送IGMP消息包括響應IGMP查詢、主動向路由器發(fā)送未經(jīng)同意的成員關系報告以及主動發(fā)起離開組信息。接收組播報文時,必須進行有效性檢查,如IPv6中所有主機都已離開該組播組,則報文不再向組播協(xié)議轉換器轉交,并立即向IPv4發(fā)起離開組信息。

(2)IPv6組播代理

IPv6組播代理作為IPv6接收節(jié)點的代理加入IPv4組播組,接收從IPv6流出的組播報文,再將報文轉交給組播協(xié)議轉換器。因為MTG在IPv4和IPv6中部署情況不同,IPv6組播代理的工作與IPv4有所區(qū)別。IPv6組播代理的工作主要包括:接收IPv6主機的組播監(jiān)聽發(fā)現(xiàn)(MLD)成員報告(作為組播指定路由器時)、接收協(xié)議無關組播(PIM)加入消息、向IPv6網(wǎng)絡發(fā)送組播數(shù)據(jù)、從IPv6網(wǎng)絡接收組播報文。MTG在IPv6中不再作為普通的主機,而是成為IPv6的組播路由器和RP,因此更多地表現(xiàn)出路由器的行為。當IPv6中沒有IPv4組播接收者時,MTG能夠獲知并做出反應,離開IPv4組。這是IPv4組播代理所無法做到的,因此,IPv6組播數(shù)據(jù)總是無條件地被轉交給組播協(xié)議轉換器,并被向IPv4網(wǎng)絡中發(fā)送。

(3)組播協(xié)議轉換器

組播協(xié)議轉換器對IPv4組播報文和IPv6組播報文進行相互轉換。它主要工作于網(wǎng)絡層,在IPv4和

 
IPv6間進行報頭轉換,必要時還要對報文分片轉發(fā)。

由圖2可見,整個模型的核心模塊是組播協(xié)議轉換器,它主要負責在IPv4和IPv6報頭間轉換。表1為IPv4和IPv6報頭字段轉換表。

         ipv4和ipv6報頭字段轉換表

 

IPv6中8位業(yè)務類型(Traffic Class)字段目前并未有標準草案做出規(guī)范,但它與IPv4中8位服務類型(ToS)字段的作用是相似的,主要用于提供某種區(qū)分服務。目前MTG對此作等值轉換,方便IPv4中基于服務類型的服務質量(QoS)工作能在IPv6中繼續(xù)。另外MTG對此提供擴展接口,可以根據(jù)需要調節(jié)轉換策略。

IPv6中跳限度(Hop Limit)字段與IPv4中生存時間(TTL)字段的作用是一致的,用于限制報文的傳播范圍。它的處理與業(yè)務類型和服務類型的轉換處理是相同的,也使用等值轉換,并提供擴展接口。對于非指定源組播(SSM)而言,源地址的轉換使用MTG的固定IPv4單播地址或固定IPv6單播地址。從IPv6接收者的角度,網(wǎng)關是所有IPv4數(shù)據(jù)重發(fā)的源;從IPv4的角度,網(wǎng)關也是所有IPv6數(shù)據(jù)重發(fā)的源。對于SSM,同一個組可能同時用于多個頻道,從而存在多個源,因此無法使用一個固定組播源地址,必須為它在地址映射器中分配新地址。

宿地址即組播組地址。IPv4向IPv6轉換時,使用IPv6組播前綴標識??FFxy::/96[6],并將IPv4組播組地址置于低32位。當IPv4組播地址是一個由全球Internet編址中心(GINA)永久分配的組播地址時,組播前綴標識中x標記置為“0”,否則為“1”;當使用SSM時,組播前綴標識中變量x標記置為“3”。組播前綴標識中y按IPv4組播前綴和標準草案RFC2365中定義的IPv6域值的映射進行轉換。IPv6向IPv4轉換時,必須根據(jù)x和y確定地址類型,再從地址映射器中分配IPv4組播組地址。注意,IPv6的會話公告協(xié)議(SAP)地址必須轉換為FF0y::2:7FFE形式。當IPv4的組播會話地址在224.2.128.0?224.2.255.255內時,SAP地址一般為224.2.127.254;其他情況可參見標準草案RFC2974中的具體定義。

另外,組播協(xié)議轉換器還向應用層提供回調接口鏈,滿足應用層協(xié)議轉換的要求。默認的應用層回調用于SAP報文的協(xié)議轉換。

(4)地址映射器

地址映射器為IPv4和IPv6維護一個單播地址池和一個由IPv4和IPv6地址對組成的地址映射表。IPv4地址池用于IPv6節(jié)點在IPv4域中的臨時IPv4地址,IPv6地址池用于IPv4節(jié)點在IPv6域中的臨時IPv6地址。它們被通告給IPv4/IPv6單播路由器,以便發(fā)送給他們的報文能夠被轉發(fā)給網(wǎng)關及通過逆向路徑轉發(fā)(RPF)檢查。

地址映射器涉及3類地址的分配:IPv4組播組地址、IPv4 SSM源地址、IPv6 SSM源地址。當需要分配一個IPv6地址對應一個IPv4地址(IPv4源地址)時,地址映射器從地址映射表中選擇一個合適的IPv6地址返回;當沒有一個合適的項對應IPv4單播地址時,地址映射器從IPv6地址池中選擇返回一個IPv6單播地址,并向地址映射表中注冊一個新的項;當沒有一個合適的項對應IPv4組播地址時(IPv4目的地址),地址映射器向表中注冊一個包含IPv4組播組地址和對應IPv6地址的新項。IPv4地址的分配與之類似。

(5)SNMP接口

SNMP接口分為內部接口和外部接口。內部接口主要為內部模塊與MIB交互提供一套完整的方法。外部接口則為用戶提供管理MTG的方法。用戶可使用標準SNMP命令獲知MTG的當前運行狀態(tài)和動態(tài)更改部分的可調參數(shù)。

(6)MTG管理信息庫

MTG管理信息庫提供MTG運行所需的環(huán)境配置和記錄MTG當前運行狀態(tài)。

2.2 MTG的工作流程

下面以一視頻會議為例說明MTG的工作流程。

IPv4中兩名參與者F1和F2,IPv6中也有兩名參與者S1和S2。其中F1為會議的組織者。所有參與者都運行會話描述協(xié)議(SDR)或類似SAP的監(jiān)聽器獲取會話信息。MTG的IPv4和IPv6地址分別為202.112.25.214和3FFE:3206:1000::19D6。同時將MTG配置為IPv6組播指定路由器。

參與者F1首先向224.2.127.254:9875公告會議信息,通知其他會議參與者使用224.5.5.5作為會話地址,并同時向IPv4發(fā)送視頻/音頻流。

參與者F2通過SDR直接收到該SAP公告,并啟動

 

組播會議工具。此時F1和F2可以進行會話。當SAP公告到達MTG,MP4將其轉交至MT,MT對其進行報頭轉換,源地址轉換為MTG的固定IPv6地址3FFE:3206:1000::19D6,宿地址為FF0E:0::2:7FFE。并調用應用層回調函數(shù)解析出組播會話地址224.5.5.5,然后從AM取得對應的IPv6地址FF1E::224.5.5.5,在應用層上對其攜帶的信息進行修改。MT再將已轉換的SAP報文轉交給MP6,將之發(fā)送到IPv6網(wǎng)絡。SAP第一次到達時,AM會更新映射表。

參與者S1和參與者S2收到SAP公告之后,發(fā)起MLD成員報告。MP6收到MLD報告之后,轉交給MT,MT將MLD報告轉換成IGMP成員報告,通過MP4向IPv4發(fā)送成員關系報告,并加入224.5.5.5組。至此,4個參與者均加入組播會話。

MP4接收到參與者F1發(fā)出的IPv4組播報文,并轉交給MT,MT對其進行報頭轉換,源地址轉換為MTG的固定IPv6地址3FFE:3206:1000::19D6,宿地址224.5.5.5轉換為對應的IPv6地址FF1E::224.5.5.5,再經(jīng)由MP6組播給參與者S1和參與者S2。MP6接收到參與者S1和參與者S2發(fā)出的IPv6組播報文,并轉交給MT,MT對其進行報頭轉換,源地址轉換為MTG的固定IPv4地址202.112.25.214,宿地址FF1E::224.5.5.5轉換為對應的IPv4地址224.5.5.5,再經(jīng)由MP4組播給參與者F1和參與者F2。當參與者S1和參與者S2都退出時,MP4不再向MT轉交該組組播報文。

當不使用SAP時,會話地址202.5.5.5必須通過人工傳達或Web公布等方法告之所有會議參與者。管理員或者被授權的終端用戶通過SNMP外部接口注冊202.5.5.5組播組,并取得IPv6映射地址FF1E::224.5.5.5。IPv6用戶使用FF1E::224.5.5.5地址加入組播會話。

3 結束語

要使IPv4主機與IPv6主機進行組播通信,必須做諸如轉發(fā)器(在傳輸層)或網(wǎng)關(在網(wǎng)絡層)之類的協(xié)議轉換工作。

MTG在實現(xiàn)網(wǎng)關基本功能的基礎上,對網(wǎng)關作了一定程度的改進。網(wǎng)關對IPv4組播的組成員及源的有效期不敏感的問題,可以通過使MTG同時成為IPv4的組播路由器,而使MTG具有獲知組成員狀態(tài)的能力;對于網(wǎng)關中IPv4只能訪問給定前綴的IPv6組,從MTG模型結構可以看出,在附加前綴的基礎上,通過可管理的靜態(tài)地址映射,消除了IPv4對IPv6的訪問限制。

MTG還對網(wǎng)關方案未曾具體涉及的問題進行了探討。根據(jù)標準草案RFC2365,加入對不同協(xié)議間組播管理域的映射;通過SNMP接口和擴展MIB,將網(wǎng)關的管理標準化。另外在底層實現(xiàn)上,MTG采用了逐級細化的處理流程,增加了可配置的網(wǎng)關的擁塞控制策略和報文調度策略,可根據(jù)QoS和流量控制要求對高速緩存中的報文進行可控調度。

使用MTG,可以有效實現(xiàn)IPv4-IPv6組播互通。



評論


相關推薦

技術專區(qū)

關閉