毛一丁,薛治綱,孫漢汶
(中國空間技術(shù)研究院西安分院,西安 710000)
衛(wèi)星通信具有覆蓋范圍大、機(jī)動(dòng)靈活、信道質(zhì)量好等優(yōu)點(diǎn),已經(jīng)在航空、海事、空間通信、深空探測(cè)等多個(gè)領(lǐng)域成功應(yīng)用。隨著衛(wèi)星通信技術(shù)的不斷發(fā)展,衛(wèi)星通信已從僅有透明轉(zhuǎn)發(fā)實(shí)現(xiàn)了向星上處理的體制跨越,星上交換技術(shù)也經(jīng)歷了從ATM交換到IP交換的發(fā)展過程[1],而星上IP路由協(xié)議也就逐漸成為研究的熱點(diǎn)。
目前制約衛(wèi)星星上處理類通信體制發(fā)展的主要因素之一是硬件器件的能力。太空中由于溫度變化和輻射效應(yīng)的影響,使得地面常規(guī)微電子器件無法在太空中正常工作[2-3],宇航級(jí)處理器和存儲(chǔ)器件的容量和工作頻率等通常遠(yuǎn)低于普通商用級(jí)器件;另一方面,地面成熟路由協(xié)議通常具有協(xié)議開銷大、計(jì)算復(fù)雜度高等特點(diǎn)[4]。二者的矛盾直接制約了大規(guī)模星地IP路由技術(shù)組網(wǎng)的應(yīng)用[5]。
由于衛(wèi)星具有嚴(yán)格的軌道運(yùn)動(dòng)特點(diǎn),并且衛(wèi)星載荷處理能力往往受到較多限制,因此絕大多數(shù)衛(wèi)星IP網(wǎng)絡(luò)路由設(shè)計(jì)都結(jié)合衛(wèi)星(群)的運(yùn)動(dòng)軌道進(jìn)行。例如,張曉娜[6]等提出的基于SDN的星地協(xié)同的一體化路由架構(gòu),通過結(jié)合衛(wèi)星運(yùn)動(dòng)軌跡計(jì)算生成路由;呂原草[7]等提出的一種星載高速路由器設(shè)計(jì)方案,用于解決星地多節(jié)點(diǎn)組網(wǎng)條件下的高速路由交換問題;Long等提出的針對(duì)雙層LEO/MEO衛(wèi)星網(wǎng)絡(luò)的QoS路由算法[8],該算法通過遺傳算法、蟻群算法等優(yōu)化衛(wèi)星網(wǎng)絡(luò)的路由性能。另有文獻(xiàn)[9]中提到的幾種多層路由算法,雖然未涉及星地協(xié)同,但其中提出的復(fù)雜路由計(jì)算交由資源相對(duì)不受限且計(jì)算能力更強(qiáng)的節(jié)點(diǎn)完成的處理方式,實(shí)際上與星地協(xié)同路由類似。這些路由方案雖然適用于衛(wèi)星組網(wǎng),但并未適配標(biāo)準(zhǔn)的路由協(xié)議,不能與地面?zhèn)鹘y(tǒng)IP路由協(xié)議直接互聯(lián)互通,特別是當(dāng)由GEO高通量衛(wèi)星和地面網(wǎng)絡(luò)共同組成星地一體化IP網(wǎng)絡(luò)時(shí),在衛(wèi)星上實(shí)現(xiàn)地面通用路由協(xié)議(如RIP、OSPF等)就顯得尤為重要。2008年投入商業(yè)運(yùn)行的Spaceway3衛(wèi)星[10]支持大容量星上IP業(yè)務(wù)交換,該系統(tǒng)通過一個(gè)地面控制中心收集全網(wǎng)路由信息并進(jìn)行域內(nèi)路由計(jì)算,用戶終端只需要實(shí)現(xiàn)用戶側(cè)的域內(nèi)路由協(xié)議,即可通過與NOCC的交互實(shí)現(xiàn)路由信息的更新。雖然其完美的支持了IP業(yè)務(wù),但仍不具備自主運(yùn)行標(biāo)準(zhǔn)路由協(xié)議的能力。目前已知在衛(wèi)星上實(shí)現(xiàn)標(biāo)準(zhǔn)路由協(xié)議的思科18400太空路由器[11],采用與地面相同的IPv4協(xié)議棧和OSPF路由協(xié)議,可完全不依賴地面路由設(shè)備進(jìn)行星上自主路由,實(shí)現(xiàn)與地面路由器完全對(duì)等的功能,但由于星上對(duì)IP數(shù)據(jù)包處理能力限制,其吞吐量僅為250 Mbps,性能不能滿足未來空間組網(wǎng)需求。
未來衛(wèi)星通信的IP化仍是主流方向,且隨著以空間激光技術(shù)為代表的高容量傳輸技術(shù)的發(fā)展[12],天地一體化大規(guī)模組網(wǎng)是未來發(fā)展的趨勢(shì)。衛(wèi)星路由與地面路由對(duì)等交互是大規(guī)模組網(wǎng)的必要條件,而路由快速計(jì)算和收斂,是大規(guī)模組網(wǎng)面臨的重要問題[13]。
針對(duì)以上矛盾,設(shè)計(jì)了一種星地協(xié)同的路由協(xié)議處理架構(gòu)方案,通過增加星地協(xié)同處理機(jī)制,將復(fù)雜路由處理由星上移動(dòng)到地面,以降低IP路由協(xié)議對(duì)星載硬件平臺(tái)處理能力的要求。
由于受宇航級(jí)器件處理能力的限制,星載IP路由器通常使用CPU處理路由協(xié)議,使用FPGA完成路由表查表和交換功能[14]。即使如此,CPU的處理能力仍然是整個(gè)路由器的性能瓶頸,例如一款國產(chǎn)宇航級(jí)32位處理器BM3803的頻率僅有70 MHz,遠(yuǎn)低于地面同類器件[15]。通過路由與管控聯(lián)合設(shè)計(jì),將路由協(xié)議數(shù)據(jù)包通過專用信道發(fā)送到地面進(jìn)行處理,降低星載CPU處理復(fù)雜度,實(shí)現(xiàn)星上處理的簡化。
如圖1所示,是星地協(xié)同路由處理方案與傳統(tǒng)方案的對(duì)比。圖1(a)是傳統(tǒng)星載IP路由協(xié)議處理載荷方案的組成示意,主要由高速交換及接口FPGA、路由查找FPGA和路由處理CPU組成。其中路由查找FPGA負(fù)責(zé)根據(jù)指定的目的IP地址查詢路由表,得到對(duì)應(yīng)的出端口;高速交換及接口FPGA負(fù)責(zé)路由器對(duì)外實(shí)體接口和路由處理CPU之間數(shù)據(jù)的收發(fā);路由處理CPU實(shí)現(xiàn)了TCP/IP協(xié)議棧,負(fù)責(zé)與其它對(duì)等路由器之間實(shí)現(xiàn)完成協(xié)議交互,并生成路由表供路由查找FPGA使用,同時(shí)實(shí)現(xiàn)星載IP路由協(xié)議處理載荷管理控制功能。圖1(b)是星地協(xié)同路由處理方案架構(gòu),與傳統(tǒng)方案不同的是,該方案將原本均在衛(wèi)星側(cè)實(shí)現(xiàn)的功能拆分為衛(wèi)星側(cè)和地面?zhèn)葍刹糠郑瑢⒏邚?fù)雜度的路由協(xié)議處理交由地面處理設(shè)備執(zhí)行,衛(wèi)星側(cè)僅負(fù)責(zé)IP報(bào)文的查表交換和簡單的管控功能。地面路由協(xié)議處理設(shè)備由于沒有宇航級(jí)器件使用限制,可采用x86架構(gòu)和高速SDRAM,極大提升處理能力。
星地協(xié)同路由處理方案在交換及接口FPGA中增加一個(gè)數(shù)據(jù)分發(fā)模塊,該模塊的主要功能是將數(shù)據(jù)包按星地專用鏈路和業(yè)務(wù)信道幀格式封裝、解封并相互轉(zhuǎn)換。通過這一模塊可對(duì)原有業(yè)務(wù)信道傳輸?shù)臄?shù)據(jù)幀屏蔽星地協(xié)同專用鏈路的存在,使新方案與原有方案之間松耦合,并可將星地協(xié)同專用鏈路作為一個(gè)對(duì)外業(yè)務(wù)接口統(tǒng)一處理流程,最大限度兼容已有設(shè)計(jì)。
(a)傳統(tǒng)路由處理載荷方案
(b)星地協(xié)同路由處理方案
1)路由表結(jié)構(gòu)
由于將協(xié)議處理CPU移至地面?zhèn)?,?duì)于衛(wèi)星側(cè)的高速交換與接口FPGA來說相當(dāng)于增加了一個(gè)外部接口,為最大限度沿用原有FPGA結(jié)構(gòu)設(shè)計(jì)及業(yè)務(wù)流程,需在路由表中增加一個(gè)指向地面?zhèn)嚷酚蓞f(xié)議處理設(shè)備的標(biāo)志位,新形成的路由表結(jié)構(gòu)如表1所列。
衛(wèi)星側(cè)載荷和地面路由協(xié)議處理設(shè)備上電初始化時(shí),需要在路由表中添加相關(guān)網(wǎng)段默認(rèn)路由信息,并將其送地面標(biāo)志位置1,以實(shí)現(xiàn)將協(xié)議相關(guān)IP包轉(zhuǎn)發(fā)到地面路由協(xié)議處理設(shè)備進(jìn)行處理。各種路由協(xié)議的IP包均有各自獨(dú)特的特征,例如RIP路由協(xié)議封裝在端口號(hào)為520的UDP包中、OSPF路由協(xié)議直接封裝在IP協(xié)議類型為89的IP包中等。實(shí)際上對(duì)于IP單播包,只需要將目的IP地址為本路由器端口IP的數(shù)據(jù)包轉(zhuǎn)發(fā)到地面路由協(xié)議處理設(shè)備處理即可。另外,組播路由協(xié)議及部分單播路由協(xié)議會(huì)使用224.0.0.0-224.0.0.255網(wǎng)段的組播地址用于路由協(xié)議或其他下層拓?fù)浒l(fā)現(xiàn)協(xié)議等,因此這一網(wǎng)段的組播路由也需要轉(zhuǎn)發(fā)到地面進(jìn)行處理。
表1 路由表結(jié)構(gòu)
2)專用鏈路幀結(jié)構(gòu)
在星地協(xié)同路由處理方案中,協(xié)議交互的IP包需要在高速交換及接口FPGA和地面協(xié)議處理CPU之間傳輸。由于在這一方案中,衛(wèi)星側(cè)并未實(shí)現(xiàn)TCP/IP協(xié)議棧,不能在該信道上直接傳輸IP包,且該信道還需將地面生成的路由表傳遞到載荷路由查找FPGA中。因此,需設(shè)計(jì)一種星地鏈路幀結(jié)構(gòu)以保證不同類型的數(shù)據(jù)均能在星地之間可靠傳輸。
星地鏈路幀結(jié)構(gòu)如圖2所示,包含幀長、幀類型、各部分校驗(yàn)和凈荷等字段。其中幀類型字段用于標(biāo)示該幀內(nèi)部凈荷的類別,例如凈荷為IP包則幀類型標(biāo)示為0x80、ARP包標(biāo)示為0x86等。包數(shù)量字段用于標(biāo)示凈荷部分包含的有效數(shù)據(jù)包的數(shù)量,當(dāng)凈荷為IP包或ARP包時(shí),該字段填1;若為路由表配置信息時(shí),該字段按凈荷實(shí)際攜帶條目數(shù)填寫。為了適應(yīng)不同包長的IP包和配置包,凈荷部分是可變長的,最長不超過1 518 B,這是由于星地之間并非對(duì)等TCP/IP架構(gòu),凈荷長度設(shè)計(jì)滿足將最長IP包和MAC幀完整放入,以避免IP分片情況發(fā)生。幀長HEC、幀頭CRC和幀校驗(yàn)字段分別用于對(duì)幀長字段、幀頭部分和整幀內(nèi)容進(jìn)行校驗(yàn),保證幀的正確截取和傳輸。
圖2 星地鏈路幀結(jié)構(gòu)
地面路由協(xié)議處理設(shè)備收斂路由協(xié)議后,使用幀類型為0x50或0x55的幀向衛(wèi)星側(cè)載荷進(jìn)行傳輸。如圖3所示,配置的每條路由表長度為20 B,故每個(gè)鏈路幀凈荷中最多包含75條路由配置信息,實(shí)際包含的條數(shù)須填寫在鏈路幀頭“條數(shù)”字段中。路由刪除與配置方式類似,只需將幀類型由0x50、0x55替換為0xA0、0xA5即可。
圖3 路由表配置幀結(jié)構(gòu)
當(dāng)載荷和地面路由協(xié)議處理設(shè)備加電后,根據(jù)地面處理設(shè)備初始化的端口信息,向衛(wèi)星側(cè)路由查找FPGA配置端口默認(rèn)路由信息,共直連網(wǎng)段查表使用。正常工作階段,交換及接口FPGA由業(yè)務(wù)接口或星地專用鏈路接收數(shù)據(jù)包、判斷數(shù)據(jù)包類型,按如下類別分類處理:
1)IP單播、組播包,送路由查找FPGA查詢路由表,根據(jù)查詢結(jié)果按出端口轉(zhuǎn)發(fā)或送數(shù)據(jù)分發(fā)模塊發(fā)往地面處理;
2)IP廣播包、ARP包,所有端口廣播,同時(shí)送數(shù)據(jù)分發(fā)模塊發(fā)往地面處理;
3)路由配置包,將數(shù)據(jù)包送往路由查找FPGA配置星上路由表用于查表轉(zhuǎn)發(fā);
4)管理控制包,送往星上管理控制CPU進(jìn)行處理。
地面數(shù)據(jù)分發(fā)模塊收到星上發(fā)來的數(shù)據(jù)包,解幀后送路由協(xié)議處理設(shè)備處理。對(duì)于ARP、普通IP包(如ICMP包)等,經(jīng)由TCP/IP協(xié)議棧處理后直接返回響應(yīng)包,并由地面數(shù)據(jù)分發(fā)模塊組幀后發(fā)回星上,按查表結(jié)果轉(zhuǎn)發(fā);對(duì)于路由協(xié)議包,除經(jīng)由對(duì)應(yīng)的路由協(xié)議處理并返回響應(yīng)包外,還需將生成(刪除)的路由按對(duì)應(yīng)路由表配置幀格式進(jìn)行組幀,并發(fā)送到星載設(shè)備中,供IP路由交換查表使用。
當(dāng)?shù)孛鎮(zhèn)群托l(wèi)星側(cè)均完成路由協(xié)議收斂和路由配置后,對(duì)于絕大多數(shù)普通業(yè)務(wù)IP包的轉(zhuǎn)發(fā)只需要衛(wèi)星側(cè)交換及接口FPGA和路由查找FPGA即可完成,無需地面?zhèn)葏⑴c,即與傳統(tǒng)架構(gòu)處理流程無異。
測(cè)試采用Spirent Testcenter網(wǎng)絡(luò)測(cè)試儀對(duì)兩種路由處理方案的實(shí)際效果進(jìn)行測(cè)試,并進(jìn)行對(duì)比。其中傳統(tǒng)路由處理方案采用CPU為BM3803的硬件平臺(tái),主頻設(shè)置為60 MHz;星地協(xié)同路由處理方案使用x86架構(gòu)實(shí)現(xiàn)。二者均使用開源的Quagga軟路由套件編譯實(shí)現(xiàn)被測(cè)路由協(xié)議。測(cè)試分別針對(duì)RIP、OSPF兩種單播路由協(xié)議和PIM-SM組播路由協(xié)議進(jìn)行,使用Testcenter網(wǎng)絡(luò)測(cè)試儀分別發(fā)布不同條目的外部路由,并建立目的IP為對(duì)應(yīng)外部路由的數(shù)據(jù)流,通過統(tǒng)計(jì)路由發(fā)布時(shí)間和數(shù)據(jù)流成功轉(zhuǎn)發(fā)時(shí)間之間的差值,得出路由協(xié)議收斂時(shí)長。由于GEO衛(wèi)星的星地鏈路雙向傳輸時(shí)延僅約300 ms,并且路由查找及交換處理采用FPGA實(shí)現(xiàn),時(shí)延一般小于5 ms,這兩類時(shí)延與幾十s甚至數(shù)百s的收斂時(shí)間相比差距過大,因此在路由收斂時(shí)間統(tǒng)計(jì)時(shí)將二者忽略不計(jì)。
如圖4所示,是兩種方案下分別發(fā)布RIP路由,路由收斂時(shí)間隨路由條目數(shù)變化結(jié)果圖。從圖中可以看出,當(dāng)發(fā)布的路由條目數(shù)較少時(shí),二者在收斂時(shí)間上沒有過于明顯的差異。但隨著發(fā)布的路由條目逐漸增多,使用BM3803處理器平臺(tái)的傳統(tǒng)路由處理方案收斂時(shí)間明顯快速增加,在2 000條路由時(shí)收斂時(shí)長已超過60 s;3 200條路由時(shí)收斂時(shí)間已不可接受。而使用x86架構(gòu)模擬的星地協(xié)同路由處理方案在發(fā)布4 000條路由時(shí)收斂時(shí)間依然在30 s以內(nèi)。
圖4 RIP協(xié)議收斂時(shí)間隨條目數(shù)變化圖
如圖5所示是OSPF路由的測(cè)試結(jié)果。與圖4類似,OSPF路由收斂時(shí)間結(jié)果與RIP協(xié)議基本呈現(xiàn)相同的變化趨勢(shì),但由于OSPF路由協(xié)議需要根據(jù)收到的LSA計(jì)算路由,處理復(fù)雜度比RIP協(xié)議更高,故體現(xiàn)在測(cè)試結(jié)果上相同的路由條目數(shù)所需的收斂時(shí)間也更長,并且BM3803處理器平臺(tái)在路由條目達(dá)到3 600條時(shí)已無法收斂。
圖5 OSPF協(xié)議收斂時(shí)間隨條目數(shù)變化圖
如圖6所示是PIM-SM組播路由協(xié)議在兩種方案下收斂時(shí)間隨條目數(shù)變化結(jié)果圖。從圖中可以看出,在不同的路由條目數(shù)時(shí)x86架構(gòu)的收斂時(shí)間也明顯優(yōu)于BM3803處理器平臺(tái),但總體收斂時(shí)間在可接受范圍內(nèi)。分析收斂時(shí)間可控的原因一是由于發(fā)布的組播組數(shù)量明顯少于單播路由數(shù)目;二是組播組只從一個(gè)業(yè)務(wù)端口發(fā)布,IP包數(shù)量較少,若同時(shí)從多個(gè)業(yè)務(wù)端口發(fā)布相同的組播組,收到的IP包數(shù)量會(huì)急劇增加,收斂時(shí)間也會(huì)相應(yīng)增長。
圖6 PIM-SM組播協(xié)議收斂時(shí)間隨條目數(shù)變化圖
針對(duì)宇航級(jí)器件能力無法滿足路由協(xié)議處理需求的問題,通過對(duì)不同業(yè)務(wù)與協(xié)議IP包的特點(diǎn)進(jìn)行分析,設(shè)計(jì)了一種星地協(xié)同路由處理方案,同時(shí)設(shè)計(jì)了對(duì)應(yīng)的路由表結(jié)構(gòu)和鏈路幀結(jié)構(gòu),通過業(yè)務(wù)處理星地分擔(dān)的方式,極大減輕星載設(shè)備負(fù)載,實(shí)現(xiàn)處理能力的大幅提升。同時(shí),該方案最大程度繼承了已有硬件設(shè)計(jì)和業(yè)務(wù)流程,避免破壞現(xiàn)有網(wǎng)絡(luò)體制和設(shè)備部署,使得方案在工程上更加容易實(shí)現(xiàn)。通過測(cè)試實(shí)驗(yàn)驗(yàn)證可知,該方案在路由收斂時(shí)間上與原方案相比大幅縮短,避免了因超時(shí)無法收斂導(dǎo)致的路由不可達(dá)問題;并且比原方案能夠正常收斂更多的路由條目,滿足更大規(guī)模網(wǎng)絡(luò)部署需求。從工程應(yīng)用角度看,該方案雖占用了少量星地鏈路,但突破了目前衛(wèi)星IP網(wǎng)絡(luò)的規(guī)模瓶頸,極大提升了網(wǎng)絡(luò)規(guī)模的上限,在大規(guī)模星地協(xié)同組網(wǎng)、一體化網(wǎng)絡(luò)架構(gòu)中具有較高應(yīng)用價(jià)值。