基于SDN架構(gòu)的IPv6過渡技術(shù)設(shè)計(jì)與實(shí)現(xiàn)

孫 瓊 ，解沖鋒 ，趙慧玲 ，盧緒山 ，劉樹成

（1.中國電信股份有限公司北京研究院 北京 100035；2.華為技術(shù)有限公司 深圳 518129）

1 引言

隨著運(yùn)營商IPv4地址的日益緊缺，IPv4向IPv6過渡已成為運(yùn)營商的必經(jīng)之路。IPv6能夠從根本上解決IPv4地址不足的問題，恢復(fù)業(yè)務(wù)的端到端特性，從而保證業(yè)務(wù)的持續(xù)發(fā)展。然而，IPv4向IPv6過渡并不是一蹴而就的。由于IPv4與IPv6并不兼容，必須引入IPv6過渡技術(shù)才能實(shí)現(xiàn)IPv4到IPv6的轉(zhuǎn)換，一方面實(shí)現(xiàn)過渡期間IPv4地址的復(fù)用，從而節(jié)省IPv4公網(wǎng)地址消耗；另一方面實(shí)現(xiàn)IPv4與IPv6的轉(zhuǎn)換及網(wǎng)絡(luò)的跨越。

雖然過渡技術(shù)有很多種，包括隧道類、翻譯類等，并且適用于不同的應(yīng)用場景，但究其實(shí)質(zhì)均為流表的處理問題，實(shí)現(xiàn)將IPv6地址、端口信息與IPv4地址及端口信息的映射，并按照隧道或翻譯方式予以實(shí)現(xiàn)。該實(shí)現(xiàn)思路與SDN（software defined networking，軟件定義網(wǎng)絡(luò)）的流表處理不謀而合。

SDN采用控制與轉(zhuǎn)發(fā)分離的思路，控制器（controller）具有全局視角，統(tǒng)一實(shí)現(xiàn)策略的制定、流表的下發(fā)等操作，而轉(zhuǎn)發(fā)器（switch）接收來自控制器的請(qǐng)求，執(zhí)行相關(guān)流表的操作。SDN早期是在斯坦福大學(xué)提出的OpenFlow基礎(chǔ)上發(fā)展起來的，目前已廣泛受到包括思科、Juniper、華為等在內(nèi)的業(yè)界主流廠商和運(yùn)營商的深度參與，并有ONF、NFV、ITU-T、IETF、BBF等多個(gè)標(biāo)準(zhǔn)化組織制定相關(guān)標(biāo)準(zhǔn)。

雖然SDN技術(shù)已得到業(yè)界的廣泛關(guān)注，但如何將SDN技術(shù)與IPv6過渡技術(shù)相結(jié)合，從而解決運(yùn)營商在IPv6過渡時(shí)期的復(fù)雜性和業(yè)務(wù)開展問題，目前還沒有進(jìn)行深入研究。本文深入研究了在運(yùn)營商網(wǎng)絡(luò)中將IPv6與SDN相結(jié)合的應(yīng)用場景及實(shí)施優(yōu)勢(shì)，并首次提出了Openv6系統(tǒng)實(shí)現(xiàn)架構(gòu)與關(guān)鍵技術(shù)，重點(diǎn)研究了現(xiàn)網(wǎng)部署實(shí)施的可行性。

2 基于SDN架構(gòu)的IPv6過渡技術(shù)設(shè)計(jì)

2.1 業(yè)務(wù)需求

在IPv4向IPv6過渡時(shí)期，存在多種復(fù)雜的應(yīng)用場景和過渡技術(shù)，運(yùn)營商對(duì)不同的過渡技術(shù)進(jìn)行選擇、切換以及管理時(shí)都會(huì)存在不同的需求。通常，由IPv4向IPv6的過渡需要經(jīng)歷IPv4主導(dǎo)、IPv4/IPv6雙棧以及IPv6主導(dǎo)3個(gè)不同的階段，在不同的階段又有多種應(yīng)用場景并存。因此，在整個(gè)IPv4向IPv6的過渡時(shí)期，存在如下業(yè)務(wù)承載需求。

（1）不同過渡技術(shù)間的切換

在IPv4向IPv6過渡的不同時(shí)期，需根據(jù)網(wǎng)絡(luò)中當(dāng)前設(shè)備的支持情況、網(wǎng)絡(luò)中IPv4/IPv6流量的變化情況、IPv4剩余地址的數(shù)量等多個(gè)因素，選擇合適的過渡技術(shù)。例如，在網(wǎng)絡(luò)中IPv6支持情況較好、終端對(duì)過渡技術(shù)支持較好時(shí)，可以采用基于IPv6的過渡技術(shù)（如 DS-Lite等），以更好地適應(yīng)將來的發(fā)展；若網(wǎng)絡(luò)中當(dāng)前設(shè)備及終端的IPv6支持能力較低，則可以采用一些基于雙棧的過渡技術(shù)（如NAT444等），以降低對(duì)前期網(wǎng)絡(luò)中IPv6能力的要求。這些技術(shù)的選擇需要因地制宜，不能一概而論。

（2）多種過渡技術(shù)的共存

在IPv4與IPv6的同一過渡時(shí)期，可能存在多種過渡技術(shù)用于不同的應(yīng)用場景。例如，隧道類過渡技術(shù)可解決IPv4地址的后向兼容性問題，翻譯類過渡技術(shù)可以解決IPv4與IPv6應(yīng)用互通的問題。當(dāng)多種過渡技術(shù)共存時(shí)，對(duì)設(shè)備的實(shí)現(xiàn)提出了一定的要求。當(dāng)前設(shè)備在實(shí)現(xiàn)多種技術(shù)共存時(shí)還存在一定程度上的限制，如多技術(shù)疊加時(shí)設(shè)備資源（如存儲(chǔ)空間等）無法靈活共享，需要為不同的技術(shù)開辟一個(gè)獨(dú)立的計(jì)算與存儲(chǔ)空間等。因此，當(dāng)前設(shè)備實(shí)現(xiàn)無法最大程度地充分利用設(shè)備的硬件資源與計(jì)算資源。

（3）統(tǒng)一地址池的管理

在IPv6過渡時(shí)期，不同的設(shè)備、過渡技術(shù)所使用的IPv4地址池通常是單獨(dú)管理的，不同的過渡技術(shù)通過不同的實(shí)例進(jìn)行管理和配置。但由于在IPv6過渡時(shí)期，過渡技術(shù)的共存、選擇和遷移是隨著IPv6和IPv4的流量變化而變化的，因此，需要對(duì)IPv4地址池不斷進(jìn)行調(diào)配，并根據(jù)業(yè)務(wù)量的變化進(jìn)行調(diào)整。此外，由于運(yùn)營商現(xiàn)有的IPv4地址資源已非常零散，多種過渡技術(shù)的引入無疑會(huì)進(jìn)一步加劇地址池的碎片化，使得地址池的管理和維護(hù)更加復(fù)雜。

（4）網(wǎng)絡(luò)設(shè)備的虛擬化

在IPv6過渡時(shí)期，不同的過渡設(shè)備在進(jìn)行相關(guān)的流表處理時(shí)，都需要消耗大量的計(jì)算資源、存儲(chǔ)資源等，用于存儲(chǔ)用戶的映射信息等內(nèi)容，這些內(nèi)容會(huì)隨用戶流量、業(yè)務(wù)狀況的變化而變化。網(wǎng)絡(luò)功能的虛擬化能夠更有效地實(shí)現(xiàn)過渡資源的集約化管理。

（5）服務(wù)質(zhì)量的協(xié)同控制

隨著網(wǎng)絡(luò)智能化技術(shù)的逐步增強(qiáng)，運(yùn)營商在網(wǎng)絡(luò)中實(shí)現(xiàn)業(yè)務(wù)服務(wù)質(zhì)量的動(dòng)態(tài)調(diào)整、路徑優(yōu)化、業(yè)務(wù)自動(dòng)化部署的能力大大提高。然而，隨著IPv6在現(xiàn)網(wǎng)中的引入，網(wǎng)絡(luò)中地址轉(zhuǎn)換點(diǎn)的增加使得用戶、業(yè)務(wù)的識(shí)別與調(diào)整的復(fù)雜度進(jìn)一步增大。

2.2 當(dāng)前主流過渡技術(shù)的模塊化實(shí)現(xiàn)

當(dāng)前，多種過渡技術(shù)對(duì)用戶側(cè)設(shè)備有不同的要求，如DS-Lite為純IPv6接入過渡技術(shù)，一方面要求用戶側(cè)設(shè)備實(shí)現(xiàn)隧道的封裝等功能，另一方面僅申請(qǐng)IPv6地址即可；NAT444作為雙棧接入過渡技術(shù)，用戶側(cè)設(shè)備通常包括NAT功能，同時(shí)也需要申請(qǐng) IPv4和IPv6地址；MAP、LAFT6過渡技術(shù)則需要在家庭網(wǎng)關(guān)中包含NAT及隧道功能。這些模塊在多種過渡技術(shù)中是可以復(fù)用的。表1、表2分別總結(jié)了當(dāng)前過渡技術(shù)在用戶側(cè)和網(wǎng)絡(luò)側(cè)的相關(guān)功能模塊。

通過多個(gè)功能模塊的疊加、組合和復(fù)用可以實(shí)現(xiàn)多種過渡技術(shù)，通過控制面的策略下發(fā)可以實(shí)現(xiàn)多種過渡的切換，從而可以比較靈活地實(shí)現(xiàn)不同業(yè)務(wù)場景的適配。

表1 當(dāng)前過渡技術(shù)在用戶側(cè)的相關(guān)功能模塊

表2 當(dāng)前過渡技術(shù)在網(wǎng)絡(luò)側(cè)的相關(guān)功能模塊

2.3 基于SDN的IPv6過渡技術(shù)功能架構(gòu)

引入基于SDN的IPv6過渡技術(shù)后的系統(tǒng)架構(gòu)如圖1所示，網(wǎng)絡(luò)邊緣轉(zhuǎn)發(fā)設(shè)備內(nèi)置控制代理（control agent）模塊，用于轉(zhuǎn)發(fā)面與控制面的協(xié)議交互。

·轉(zhuǎn)發(fā)面主要實(shí)現(xiàn)通用IPv6過渡技術(shù)的模塊化操作，統(tǒng)一實(shí)現(xiàn)多種類型過渡技術(shù)的轉(zhuǎn)換處理。轉(zhuǎn)發(fā)面和控制面的協(xié)議交互可以在OpenFlow協(xié)議基礎(chǔ)上進(jìn)行擴(kuò)展，也可以在現(xiàn)有協(xié)議（如RADIUS、Netconf等）基礎(chǔ)上進(jìn)行擴(kuò)展。

·控制面主要實(shí)現(xiàn)不同過渡技術(shù)的下發(fā)、流表/規(guī)則的下發(fā)與控制以及過渡期地址資源的管理。

·應(yīng)用層則主要通過與控制面的交互，實(shí)現(xiàn)對(duì)不同過渡技術(shù)的管理與配置。

2.4 功能模塊組成

基于SDN的IPv6網(wǎng)絡(luò)參考架構(gòu)包括三大功能模塊，分別為:應(yīng)用功能模塊、SDN控制器相關(guān)功能模塊和轉(zhuǎn)發(fā)節(jié)點(diǎn)相關(guān)功能模塊。

（1）應(yīng)用功能模塊

應(yīng)用層主要提供IPv6演進(jìn)技術(shù)插件、地址池及網(wǎng)絡(luò)資源管理、服務(wù)質(zhì)量的動(dòng)態(tài)調(diào)控及其他第三方業(yè)務(wù)的開放功能。

其中，應(yīng)用層為IPv4向IPv6過渡中的各種技術(shù)提供插件，主要是方便靈活配置網(wǎng)絡(luò)轉(zhuǎn)發(fā)節(jié)點(diǎn)，以適應(yīng)過渡技術(shù)的不同場景和不同階段；地址池及網(wǎng)絡(luò)資源管理功能為運(yùn)營商提供地址池管理、資源管理的統(tǒng)一界面，并能夠與控制面交互地址的相關(guān)信息；服務(wù)質(zhì)量的動(dòng)態(tài)調(diào)控與差異化管理功能，為特定用戶、業(yè)務(wù)提供帶寬、路徑的差異化提供能力；第三方業(yè)務(wù)開放接口為第三方提供業(yè)務(wù)管理能力。此外，應(yīng)用層還可提供綜合的業(yè)務(wù)運(yùn)營和管理功能，包括網(wǎng)絡(luò)管理、系統(tǒng)管理、計(jì)費(fèi)、營業(yè)、賬務(wù)和客戶服務(wù)等。

（2）SDN控制器相關(guān)功能模塊

控制器層主要包括控制協(xié)議功能、過渡技術(shù)編排、映射表項(xiàng)下發(fā)、對(duì)網(wǎng)絡(luò)資源的管理、網(wǎng)絡(luò)虛擬化以及基礎(chǔ)協(xié)議相關(guān)功能。

其中，控制協(xié)議功能提供對(duì)轉(zhuǎn)發(fā)設(shè)備的控制協(xié)議（如OpenFlow等），與轉(zhuǎn)發(fā)節(jié)點(diǎn)建立控制協(xié)議連接，其他功能模塊可以通過控制協(xié)議對(duì)轉(zhuǎn)發(fā)節(jié)點(diǎn)進(jìn)行控制；過渡技術(shù)的編排功能支持對(duì)指定的過渡技術(shù)進(jìn)行編排，下發(fā)給指定的轉(zhuǎn)發(fā)設(shè)備，并進(jìn)行相應(yīng)的配置管理；網(wǎng)絡(luò)資源管理功能支持對(duì)映射表項(xiàng)、設(shè)備資源占用情況的統(tǒng)計(jì)查詢，并可基于當(dāng)前資源的使用情況確定下發(fā)的轉(zhuǎn)發(fā)設(shè)備列表，以實(shí)現(xiàn)負(fù)載均衡和冗余備份，且能在資源不足時(shí)動(dòng)態(tài)調(diào)整路徑，并下發(fā)給相應(yīng)的轉(zhuǎn)發(fā)器，同時(shí)支持針對(duì)各種IPv6過渡技術(shù)，對(duì)地址資源（包括地址和端口）進(jìn)行統(tǒng)一管理，包括地址的資源分配、地址資源回收、地址資源再分配等；網(wǎng)絡(luò)虛擬化功能能夠?qū)崿F(xiàn)對(duì)網(wǎng)絡(luò)的抽象，屏蔽物理網(wǎng)絡(luò)細(xì)節(jié)。

此外，控制器還可以更細(xì)粒度地控制轉(zhuǎn)發(fā)面映射表，映射表項(xiàng)的下發(fā)支持基于轉(zhuǎn)發(fā)層上送的首個(gè)分組及過渡策略來確定相應(yīng)的映射表項(xiàng)，并下發(fā)給轉(zhuǎn)發(fā)設(shè)備；支持對(duì)特定映射表項(xiàng)的生成、更改與刪除。同時(shí)，網(wǎng)絡(luò)協(xié)議層還可提供傳統(tǒng)路由器具備的路由協(xié)議棧，使SDN控制器能夠代替轉(zhuǎn)發(fā)節(jié)點(diǎn)對(duì)外運(yùn)行傳統(tǒng)路由協(xié)議。

圖1 基于SDN的IPv6過渡體系組網(wǎng)架構(gòu)

（3）網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)節(jié)點(diǎn)功能模塊

網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)節(jié)點(diǎn)功能模塊主要包括基礎(chǔ)路由功能、控制協(xié)議、控制代理、流轉(zhuǎn)發(fā)面及其他支撐模塊。

其中，基礎(chǔ)路由功能運(yùn)行IGP路由協(xié)議，負(fù)責(zé)將基本路由打通，在控制器能夠控制轉(zhuǎn)發(fā)節(jié)點(diǎn)之前，建立控制通道以及網(wǎng)絡(luò)拓?fù)涫占豢刂茀f(xié)議通過與控制器的控制協(xié)議層對(duì)應(yīng)，負(fù)責(zé)與控制器建立和維持控制協(xié)議的連接，如SNMP、OpenFlow等協(xié)議；控制代理負(fù)責(zé)向SDN控制器注冊(cè)、上報(bào)信息，接收SDN控制器下發(fā)的控制信息和轉(zhuǎn)發(fā)表項(xiàng)，并下發(fā)到轉(zhuǎn)發(fā)面以指導(dǎo)轉(zhuǎn)發(fā)；流轉(zhuǎn)發(fā)面可實(shí)現(xiàn)對(duì)報(bào)文的轉(zhuǎn)發(fā)和處理，實(shí)現(xiàn)IPv6過渡映射表的統(tǒng)一存儲(chǔ)和處理。

（4）用戶側(cè)轉(zhuǎn)發(fā)節(jié)點(diǎn)功能模塊

用戶側(cè)轉(zhuǎn)發(fā)節(jié)點(diǎn)功能模塊主要包括基本轉(zhuǎn)發(fā)及模塊化實(shí)現(xiàn)、基本模塊的編排、控制代理和監(jiān)測(cè)模塊。

其中，基本轉(zhuǎn)發(fā)及模塊化功能負(fù)責(zé)基本的IPv6轉(zhuǎn)發(fā)、不同基本模塊的實(shí)現(xiàn)（包含NAT、隧道等基本單元模塊）；基本模塊的編排可以支持不同的模塊化組合，并可以接受不同過渡技術(shù)的模式及基于特定模塊的編排；控制代理負(fù)責(zé)向控制器注冊(cè)、上報(bào)信息；監(jiān)測(cè)模塊負(fù)責(zé)對(duì)本地轉(zhuǎn)發(fā)情況、地址端口占用情況進(jìn)行監(jiān)控。

3 關(guān)鍵技術(shù)

3.1 流表選擇性映射技術(shù)

在IPv6過渡技術(shù)中，面向單流的過渡技術(shù) （如DS-Lite、NAT444、NAT64等）是在流表到達(dá)轉(zhuǎn)發(fā)器后才發(fā)起新建流表的請(qǐng)求，這對(duì)于轉(zhuǎn)發(fā)器和控制器之間的設(shè)備接口、帶寬會(huì)有很大的壓力。對(duì)于這類技術(shù)，應(yīng)用SDN技術(shù)的主要優(yōu)勢(shì)在于，可以較為便捷地實(shí)現(xiàn)狀態(tài)信息的設(shè)備間同步。而由于狀態(tài)信息的同步對(duì)于短連接的業(yè)務(wù)和長連接的業(yè)務(wù)會(huì)有較大的差異，短連接的業(yè)務(wù)在連接重新建立后可以繼續(xù)原有的業(yè)務(wù)體驗(yàn)，而長連接的業(yè)務(wù)在連接重新建立后會(huì)中斷原有的業(yè)務(wù)體驗(yàn)。因此，流表選擇性映射技術(shù)可以選擇配置長連接的業(yè)務(wù)，將這類業(yè)務(wù)的映射流量在多個(gè)轉(zhuǎn)發(fā)器之間進(jìn)行同步。

流表選擇性映射機(jī)制的實(shí)現(xiàn)如圖2所示，數(shù)據(jù)流的實(shí)現(xiàn)過程介紹如下:

（1）由編排層向控制器通告需要進(jìn)行狀態(tài)同步的目的地址，并由控制器將該請(qǐng)求下發(fā)給轉(zhuǎn)發(fā)器；

（2）數(shù)據(jù)流到達(dá)轉(zhuǎn)發(fā)器；

（3）轉(zhuǎn)發(fā)器查找本地狀態(tài)同步映射表，若找到，轉(zhuǎn)發(fā)器向控制器請(qǐng)求獲取流表；

（4）控制器向轉(zhuǎn)發(fā)器備份組統(tǒng)一發(fā)送數(shù)據(jù)流；

（5）數(shù)據(jù)流經(jīng)過轉(zhuǎn)發(fā)器轉(zhuǎn)發(fā)。

圖2 流表選擇性映射機(jī)制的實(shí)現(xiàn)

由控制器下發(fā)給轉(zhuǎn)發(fā)器的狀態(tài)同步表項(xiàng)的ACL匹配規(guī)則可以基于特定的目的地址，也可以基于一定的協(xié)議（如TCP及端口等），在收到協(xié)議時(shí)向控制器發(fā)起新建流表的請(qǐng)求。在該方案中，如果控制器發(fā)生宕機(jī)，取消由控制器下發(fā)的ACL匹配規(guī)則，從而可以實(shí)現(xiàn)由SDN轉(zhuǎn)發(fā)器向傳統(tǒng)轉(zhuǎn)發(fā)器的轉(zhuǎn)換。

該方案不僅可以大大降低基于每流狀態(tài)的DS-Lite/NAT444方案中控制器的處理壓力，同時(shí)也適用于與現(xiàn)有過渡設(shè)備的共存，當(dāng)控制器發(fā)生宕機(jī)時(shí)不會(huì)受到較大的影響。

3.2 地址池自動(dòng)化管理技術(shù)

當(dāng)一個(gè)控制器同時(shí)管理多個(gè)轉(zhuǎn)發(fā)器時(shí)，多個(gè)轉(zhuǎn)發(fā)器的地址池可以采用虛擬化管理的方式實(shí)現(xiàn)，即將一個(gè)地址池劃分為多個(gè)子地址池單元，控制器在收到一個(gè)關(guān)于新建狀態(tài)表項(xiàng)的請(qǐng)求時(shí)，基于不同的過渡技術(shù)在不同的地址池單元中進(jìn)行分配，地址池單元可以不連續(xù)排列，從而可以提高地址池的整體利用率，如圖3所示。

3.3 設(shè)備狀態(tài)組管理

為了實(shí)現(xiàn)轉(zhuǎn)發(fā)器間的負(fù)載均衡和冗余備份，需要在控制器中建立轉(zhuǎn)發(fā)器的負(fù)載均衡組和冗余備份組。其中，位于負(fù)載均衡組內(nèi)的轉(zhuǎn)換設(shè)備具有近乎相同的狀態(tài)表數(shù)量，狀態(tài)信息不在多個(gè)設(shè)備間共有；位于冗余備份組內(nèi)的轉(zhuǎn)換設(shè)備同時(shí)保存相同的狀態(tài)表，如圖4所示。

4 試驗(yàn)與驗(yàn)證

為了驗(yàn)證該架構(gòu)的性能，在真實(shí)環(huán)境中進(jìn)行測(cè)試，測(cè)試環(huán)境如下:

圖3 地址池自動(dòng)化管理技術(shù)示意

圖4 設(shè)備狀態(tài)組管理示意

·在運(yùn)行Open vSwitch的普通商用硬件上實(shí)現(xiàn)基于SDN架構(gòu)的IPv6過渡技術(shù)；

·IPv6過渡技術(shù)的應(yīng)用運(yùn)行在配置為Intel Xeon E5-2407 CPU、32 GB內(nèi)存的計(jì)算機(jī)上；

·數(shù)據(jù)面運(yùn)行在配置為Intel Core i5-2400 CPU、4 GB內(nèi)存的計(jì)算機(jī)上；

·所有硬件平臺(tái)上安裝64 bit CentOS作為操作系統(tǒng)。該系統(tǒng)部署在一個(gè)約有1000人使用的網(wǎng)絡(luò)中，系統(tǒng)架構(gòu)如圖5所示。

收集了一周工作時(shí)間時(shí)的數(shù)據(jù)，數(shù)據(jù)呈現(xiàn)如圖6、圖7所示。圖6展示了對(duì)于用戶體驗(yàn)的重要參數(shù)——流建立時(shí)間的驗(yàn)證，流建立時(shí)間指用戶建立一個(gè)新的會(huì)話需要消耗的時(shí)間，如用戶打開一個(gè)新網(wǎng)頁所需的時(shí)間。圖6（a）展示了在不同的時(shí)間段收集到的流建立時(shí)間的數(shù)據(jù)，圖6（b）展示了該數(shù)據(jù)的統(tǒng)計(jì)結(jié)果，即流建立時(shí)間小于0.7 ms的百分比?？梢钥闯?，該架構(gòu)的流建立時(shí)間是可商用、可部署的。

類似的，圖7展示了另一個(gè)重要參數(shù)——數(shù)據(jù)面的分組時(shí)延，這個(gè)參數(shù)可以反映用戶真實(shí)的體驗(yàn)，如VoIP的時(shí)延情況。圖7（a）展示了在不同時(shí)間段收集到的數(shù)據(jù)面的分組時(shí)延的數(shù)據(jù)，圖7（b）展示了該數(shù)據(jù)的統(tǒng)計(jì)結(jié)果，即數(shù)據(jù)面的分組時(shí)延小于4 ms的百分比?？梢钥闯?，該架構(gòu)的數(shù)據(jù)面分組時(shí)延同樣是可商用、可部署的。

5 部署與實(shí)施考慮

基于SDN的IPv6過渡技術(shù)在部署時(shí)要充分考慮與現(xiàn)有網(wǎng)絡(luò)設(shè)備的兼容性，如圖8所示。IPv6過渡技術(shù)的流表可以本地生成，也可以采用首個(gè)分組上送的方式由控制器生成。

圖5 真實(shí)環(huán)境中的系統(tǒng)架構(gòu)

圖6 流建立時(shí)間

圖7 數(shù)據(jù)面的分組時(shí)延

圖8 基于SDN的IPv6過渡技術(shù)的部署

在實(shí)際部署時(shí)，考慮到IPv6過渡設(shè)備會(huì)在SDN技術(shù)完全成熟前進(jìn)行部署，因此需采用分階段的部署策略，具體介紹如下。

第一階段，現(xiàn)網(wǎng)中已部署部分IPv6過渡設(shè)備，此時(shí)基于SDN的IPv6過渡設(shè)備可以首先在網(wǎng)絡(luò)側(cè)新增設(shè)備中實(shí)現(xiàn)。在過渡技術(shù)的選擇上，盡可能與已部署的過渡技術(shù)保持一致。針對(duì)新引入的過渡技術(shù)，可以首先在新設(shè)備中支持。此外，控制器可采用在同一城域網(wǎng)內(nèi)集中式部署的模式，增加協(xié)議接口適配模塊，以實(shí)現(xiàn)與現(xiàn)有設(shè)備的互通。該階段由于全網(wǎng)并沒有完全支持SDN技術(shù)，對(duì)于某些新業(yè)務(wù)的開展，只能指定在特定的設(shè)備和路徑中予以實(shí)現(xiàn)。

第二階段，逐漸在家庭網(wǎng)關(guān)中引入SDN技術(shù)，從而可以更好地適配新業(yè)務(wù)的發(fā)展。同時(shí)，可逐步升級(jí)現(xiàn)網(wǎng)中的已有設(shè)備，使得控制器能夠完全掌握全網(wǎng)的資源配置情況，同時(shí)編排層也能完成與現(xiàn)網(wǎng)支撐系統(tǒng)的配合，且對(duì)用戶的實(shí)際端口及地址的使用情況有了更為清晰的認(rèn)識(shí)。此時(shí)可逐漸根據(jù)實(shí)際需求調(diào)整特定過渡技術(shù)的選擇以及對(duì)部署位置、資源進(jìn)行靈活調(diào)配。

第三階段，全網(wǎng)逐漸全面引入SDN技術(shù)，為了更好地支撐IPv6的發(fā)展，在SDN技術(shù)中也會(huì)更多地引入網(wǎng)絡(luò)智能化、虛擬化等技術(shù)，以更好地支持物聯(lián)網(wǎng)、云計(jì)算、移動(dòng)互聯(lián)網(wǎng)等應(yīng)用的發(fā)展。

1 Bagnulo M,Matthews P,Beijnum I.Stateful NAT64:Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers.draft-ietf-behave-v6v4-xlate-stateful-11(Work in Progress),March 30,2010

2 Huang B,Deng H.Prefix NAT:Host based IPv6 Translation.draft-huang-behave-pnat-01 (Work in Progress),February 19,2010

3 Boucadair M,Jacquenet C,Grimault J L,et al.Deploying Dual-Stack Lite (DS-Lite)in IPv6 Network.draft-boucadairdslite-interco-v4v6-03(Work in Process),February 24,2010

4 Li X,Bao C,Chen M,et al.The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition.draft-xli-behave-ivi-07(Work in Progress),January 6,2010

5 Li X,Bao C,Zhang H.Address-Sharing Stateless Double IVI.draft-xli-behave-divi-01(Work in Process),October 26,2009

6 Bush R.The A+P Approach to the IPv4 Address Shortage.draftymbk-aplusp-05,October 27,2009