一種星地協(xié)同的路由協(xié)議處理架構方案*

毛一丁，薛治綱，孫漢汶

(中國空間技術研究院西安分院，西安 710000)

0 引言

衛(wèi)星通信具有覆蓋范圍大、機動靈活、信道質量好等優(yōu)點，已經(jīng)在航空、海事、空間通信、深空探測等多個領域成功應用。隨著衛(wèi)星通信技術的不斷發(fā)展，衛(wèi)星通信已從僅有透明轉發(fā)實現(xiàn)了向星上處理的體制跨越，星上交換技術也經(jīng)歷了從ATM交換到IP交換的發(fā)展過程[1]，而星上IP路由協(xié)議也就逐漸成為研究的熱點。

目前制約衛(wèi)星星上處理類通信體制發(fā)展的主要因素之一是硬件器件的能力。太空中由于溫度變化和輻射效應的影響，使得地面常規(guī)微電子器件無法在太空中正常工作[2-3]，宇航級處理器和存儲器件的容量和工作頻率等通常遠低于普通商用級器件；另一方面，地面成熟路由協(xié)議通常具有協(xié)議開銷大、計算復雜度高等特點[4]。二者的矛盾直接制約了大規(guī)模星地IP路由技術組網(wǎng)的應用[5]。

由于衛(wèi)星具有嚴格的軌道運動特點，并且衛(wèi)星載荷處理能力往往受到較多限制，因此絕大多數(shù)衛(wèi)星IP網(wǎng)絡路由設計都結合衛(wèi)星(群)的運動軌道進行。例如，張曉娜[6]等提出的基于SDN的星地協(xié)同的一體化路由架構，通過結合衛(wèi)星運動軌跡計算生成路由；呂原草[7]等提出的一種星載高速路由器設計方案，用于解決星地多節(jié)點組網(wǎng)條件下的高速路由交換問題；Long等提出的針對雙層LEO/MEO衛(wèi)星網(wǎng)絡的QoS路由算法[8]，該算法通過遺傳算法、蟻群算法等優(yōu)化衛(wèi)星網(wǎng)絡的路由性能。另有文獻[9]中提到的幾種多層路由算法，雖然未涉及星地協(xié)同，但其中提出的復雜路由計算交由資源相對不受限且計算能力更強的節(jié)點完成的處理方式，實際上與星地協(xié)同路由類似。這些路由方案雖然適用于衛(wèi)星組網(wǎng)，但并未適配標準的路由協(xié)議，不能與地面?zhèn)鹘y(tǒng)IP路由協(xié)議直接互聯(lián)互通，特別是當由GEO高通量衛(wèi)星和地面網(wǎng)絡共同組成星地一體化IP網(wǎng)絡時，在衛(wèi)星上實現(xiàn)地面通用路由協(xié)議(如RIP、OSPF等)就顯得尤為重要。2008年投入商業(yè)運行的Spaceway3衛(wèi)星[10]支持大容量星上IP業(yè)務交換，該系統(tǒng)通過一個地面控制中心收集全網(wǎng)路由信息并進行域內(nèi)路由計算，用戶終端只需要實現(xiàn)用戶側的域內(nèi)路由協(xié)議，即可通過與NOCC的交互實現(xiàn)路由信息的更新。雖然其完美的支持了IP業(yè)務，但仍不具備自主運行標準路由協(xié)議的能力。目前已知在衛(wèi)星上實現(xiàn)標準路由協(xié)議的思科18400太空路由器[11]，采用與地面相同的IPv4協(xié)議棧和OSPF路由協(xié)議，可完全不依賴地面路由設備進行星上自主路由，實現(xiàn)與地面路由器完全對等的功能，但由于星上對IP數(shù)據(jù)包處理能力限制，其吞吐量僅為250 Mbps，性能不能滿足未來空間組網(wǎng)需求。

未來衛(wèi)星通信的IP化仍是主流方向，且隨著以空間激光技術為代表的高容量傳輸技術的發(fā)展[12]，天地一體化大規(guī)模組網(wǎng)是未來發(fā)展的趨勢。衛(wèi)星路由與地面路由對等交互是大規(guī)模組網(wǎng)的必要條件，而路由快速計算和收斂，是大規(guī)模組網(wǎng)面臨的重要問題[13]。

針對以上矛盾，設計了一種星地協(xié)同的路由協(xié)議處理架構方案，通過增加星地協(xié)同處理機制，將復雜路由處理由星上移動到地面，以降低IP路由協(xié)議對星載硬件平臺處理能力的要求。

1 星地協(xié)同路由處理方案架構

由于受宇航級器件處理能力的限制，星載IP路由器通常使用CPU處理路由協(xié)議，使用FPGA完成路由表查表和交換功能[14]。即使如此，CPU的處理能力仍然是整個路由器的性能瓶頸，例如一款國產(chǎn)宇航級32位處理器BM3803的頻率僅有70 MHz，遠低于地面同類器件[15]。通過路由與管控聯(lián)合設計，將路由協(xié)議數(shù)據(jù)包通過專用信道發(fā)送到地面進行處理，降低星載CPU處理復雜度，實現(xiàn)星上處理的簡化。

如圖1所示，是星地協(xié)同路由處理方案與傳統(tǒng)方案的對比。圖1(a)是傳統(tǒng)星載IP路由協(xié)議處理載荷方案的組成示意，主要由高速交換及接口FPGA、路由查找FPGA和路由處理CPU組成。其中路由查找FPGA負責根據(jù)指定的目的IP地址查詢路由表，得到對應的出端口；高速交換及接口FPGA負責路由器對外實體接口和路由處理CPU之間數(shù)據(jù)的收發(fā)；路由處理CPU實現(xiàn)了TCP/IP協(xié)議棧，負責與其它對等路由器之間實現(xiàn)完成協(xié)議交互，并生成路由表供路由查找FPGA使用，同時實現(xiàn)星載IP路由協(xié)議處理載荷管理控制功能。圖1(b)是星地協(xié)同路由處理方案架構，與傳統(tǒng)方案不同的是，該方案將原本均在衛(wèi)星側實現(xiàn)的功能拆分為衛(wèi)星側和地面?zhèn)葍刹糠?，將高復雜度的路由協(xié)議處理交由地面處理設備執(zhí)行，衛(wèi)星側僅負責IP報文的查表交換和簡單的管控功能。地面路由協(xié)議處理設備由于沒有宇航級器件使用限制，可采用x86架構和高速SDRAM，極大提升處理能力。

星地協(xié)同路由處理方案在交換及接口FPGA中增加一個數(shù)據(jù)分發(fā)模塊，該模塊的主要功能是將數(shù)據(jù)包按星地專用鏈路和業(yè)務信道幀格式封裝、解封并相互轉換。通過這一模塊可對原有業(yè)務信道傳輸?shù)臄?shù)據(jù)幀屏蔽星地協(xié)同專用鏈路的存在，使新方案與原有方案之間松耦合，并可將星地協(xié)同專用鏈路作為一個對外業(yè)務接口統(tǒng)一處理流程，最大限度兼容已有設計。

(a)傳統(tǒng)路由處理載荷方案

(b)星地協(xié)同路由處理方案

2 星地協(xié)同路由處理方案的設計與實現(xiàn)

2.1 數(shù)據(jù)結構設計

1)路由表結構

由于將協(xié)議處理CPU移至地面?zhèn)?，對于衛(wèi)星側的高速交換與接口FPGA來說相當于增加了一個外部接口，為最大限度沿用原有FPGA結構設計及業(yè)務流程，需在路由表中增加一個指向地面?zhèn)嚷酚蓞f(xié)議處理設備的標志位，新形成的路由表結構如表1所列。

衛(wèi)星側載荷和地面路由協(xié)議處理設備上電初始化時，需要在路由表中添加相關網(wǎng)段默認路由信息，并將其送地面標志位置1，以實現(xiàn)將協(xié)議相關IP包轉發(fā)到地面路由協(xié)議處理設備進行處理。各種路由協(xié)議的IP包均有各自獨特的特征，例如RIP路由協(xié)議封裝在端口號為520的UDP包中、OSPF路由協(xié)議直接封裝在IP協(xié)議類型為89的IP包中等。實際上對于IP單播包，只需要將目的IP地址為本路由器端口IP的數(shù)據(jù)包轉發(fā)到地面路由協(xié)議處理設備處理即可。另外，組播路由協(xié)議及部分單播路由協(xié)議會使用224.0.0.0-224.0.0.255網(wǎng)段的組播地址用于路由協(xié)議或其他下層拓撲發(fā)現(xiàn)協(xié)議等，因此這一網(wǎng)段的組播路由也需要轉發(fā)到地面進行處理。

表1 路由表結構

2)專用鏈路幀結構

在星地協(xié)同路由處理方案中，協(xié)議交互的IP包需要在高速交換及接口FPGA和地面協(xié)議處理CPU之間傳輸。由于在這一方案中，衛(wèi)星側并未實現(xiàn)TCP/IP協(xié)議棧，不能在該信道上直接傳輸IP包，且該信道還需將地面生成的路由表傳遞到載荷路由查找FPGA中。因此，需設計一種星地鏈路幀結構以保證不同類型的數(shù)據(jù)均能在星地之間可靠傳輸。

星地鏈路幀結構如圖2所示，包含幀長、幀類型、各部分校驗和凈荷等字段。其中幀類型字段用于標示該幀內(nèi)部凈荷的類別，例如凈荷為IP包則幀類型標示為0x80、ARP包標示為0x86等。包數(shù)量字段用于標示凈荷部分包含的有效數(shù)據(jù)包的數(shù)量，當凈荷為IP包或ARP包時，該字段填1；若為路由表配置信息時，該字段按凈荷實際攜帶條目數(shù)填寫。為了適應不同包長的IP包和配置包，凈荷部分是可變長的，最長不超過1 518 B，這是由于星地之間并非對等TCP/IP架構，凈荷長度設計滿足將最長IP包和MAC幀完整放入，以避免IP分片情況發(fā)生。幀長HEC、幀頭CRC和幀校驗字段分別用于對幀長字段、幀頭部分和整幀內(nèi)容進行校驗，保證幀的正確截取和傳輸。

圖2 星地鏈路幀結構

地面路由協(xié)議處理設備收斂路由協(xié)議后，使用幀類型為0x50或0x55的幀向衛(wèi)星側載荷進行傳輸。如圖3所示，配置的每條路由表長度為20 B，故每個鏈路幀凈荷中最多包含75條路由配置信息，實際包含的條數(shù)須填寫在鏈路幀頭“條數(shù)”字段中。路由刪除與配置方式類似，只需將幀類型由0x50、0x55替換為0xA0、0xA5即可。

圖3 路由表配置幀結構

2.2 處理流程設計

當載荷和地面路由協(xié)議處理設備加電后，根據(jù)地面處理設備初始化的端口信息，向衛(wèi)星側路由查找FPGA配置端口默認路由信息，共直連網(wǎng)段查表使用。正常工作階段，交換及接口FPGA由業(yè)務接口或星地專用鏈路接收數(shù)據(jù)包、判斷數(shù)據(jù)包類型，按如下類別分類處理：

1)IP單播、組播包，送路由查找FPGA查詢路由表，根據(jù)查詢結果按出端口轉發(fā)或送數(shù)據(jù)分發(fā)模塊發(fā)往地面處理；

2)IP廣播包、ARP包，所有端口廣播，同時送數(shù)據(jù)分發(fā)模塊發(fā)往地面處理；

3)路由配置包，將數(shù)據(jù)包送往路由查找FPGA配置星上路由表用于查表轉發(fā)；

4)管理控制包，送往星上管理控制CPU進行處理。

地面數(shù)據(jù)分發(fā)模塊收到星上發(fā)來的數(shù)據(jù)包，解幀后送路由協(xié)議處理設備處理。對于ARP、普通IP包(如ICMP包)等，經(jīng)由TCP/IP協(xié)議棧處理后直接返回響應包，并由地面數(shù)據(jù)分發(fā)模塊組幀后發(fā)回星上，按查表結果轉發(fā)；對于路由協(xié)議包，除經(jīng)由對應的路由協(xié)議處理并返回響應包外，還需將生成(刪除)的路由按對應路由表配置幀格式進行組幀，并發(fā)送到星載設備中，供IP路由交換查表使用。

當?shù)孛鎮(zhèn)群托l(wèi)星側均完成路由協(xié)議收斂和路由配置后，對于絕大多數(shù)普通業(yè)務IP包的轉發(fā)只需要衛(wèi)星側交換及接口FPGA和路由查找FPGA即可完成，無需地面?zhèn)葏⑴c，即與傳統(tǒng)架構處理流程無異。

3 測試驗證

測試采用Spirent Testcenter網(wǎng)絡測試儀對兩種路由處理方案的實際效果進行測試，并進行對比。其中傳統(tǒng)路由處理方案采用CPU為BM3803的硬件平臺，主頻設置為60 MHz；星地協(xié)同路由處理方案使用x86架構實現(xiàn)。二者均使用開源的Quagga軟路由套件編譯實現(xiàn)被測路由協(xié)議。測試分別針對RIP、OSPF兩種單播路由協(xié)議和PIM-SM組播路由協(xié)議進行，使用Testcenter網(wǎng)絡測試儀分別發(fā)布不同條目的外部路由，并建立目的IP為對應外部路由的數(shù)據(jù)流，通過統(tǒng)計路由發(fā)布時間和數(shù)據(jù)流成功轉發(fā)時間之間的差值，得出路由協(xié)議收斂時長。由于GEO衛(wèi)星的星地鏈路雙向傳輸時延僅約300 ms，并且路由查找及交換處理采用FPGA實現(xiàn)，時延一般小于5 ms，這兩類時延與幾十s甚至數(shù)百s的收斂時間相比差距過大，因此在路由收斂時間統(tǒng)計時將二者忽略不計。

如圖4所示，是兩種方案下分別發(fā)布RIP路由，路由收斂時間隨路由條目數(shù)變化結果圖。從圖中可以看出，當發(fā)布的路由條目數(shù)較少時，二者在收斂時間上沒有過于明顯的差異。但隨著發(fā)布的路由條目逐漸增多，使用BM3803處理器平臺的傳統(tǒng)路由處理方案收斂時間明顯快速增加，在2 000條路由時收斂時長已超過60 s；3 200條路由時收斂時間已不可接受。而使用x86架構模擬的星地協(xié)同路由處理方案在發(fā)布4 000條路由時收斂時間依然在30 s以內(nèi)。

圖4 RIP協(xié)議收斂時間隨條目數(shù)變化圖

如圖5所示是OSPF路由的測試結果。與圖4類似，OSPF路由收斂時間結果與RIP協(xié)議基本呈現(xiàn)相同的變化趨勢，但由于OSPF路由協(xié)議需要根據(jù)收到的LSA計算路由，處理復雜度比RIP協(xié)議更高，故體現(xiàn)在測試結果上相同的路由條目數(shù)所需的收斂時間也更長，并且BM3803處理器平臺在路由條目達到3 600條時已無法收斂。

圖5 OSPF協(xié)議收斂時間隨條目數(shù)變化圖

如圖6所示是PIM-SM組播路由協(xié)議在兩種方案下收斂時間隨條目數(shù)變化結果圖。從圖中可以看出，在不同的路由條目數(shù)時x86架構的收斂時間也明顯優(yōu)于BM3803處理器平臺，但總體收斂時間在可接受范圍內(nèi)。分析收斂時間可控的原因一是由于發(fā)布的組播組數(shù)量明顯少于單播路由數(shù)目；二是組播組只從一個業(yè)務端口發(fā)布，IP包數(shù)量較少，若同時從多個業(yè)務端口發(fā)布相同的組播組，收到的IP包數(shù)量會急劇增加，收斂時間也會相應增長。

圖6 PIM-SM組播協(xié)議收斂時間隨條目數(shù)變化圖

4 結論

針對宇航級器件能力無法滿足路由協(xié)議處理需求的問題，通過對不同業(yè)務與協(xié)議IP包的特點進行分析，設計了一種星地協(xié)同路由處理方案，同時設計了對應的路由表結構和鏈路幀結構，通過業(yè)務處理星地分擔的方式，極大減輕星載設備負載，實現(xiàn)處理能力的大幅提升。同時，該方案最大程度繼承了已有硬件設計和業(yè)務流程，避免破壞現(xiàn)有網(wǎng)絡體制和設備部署，使得方案在工程上更加容易實現(xiàn)。通過測試實驗驗證可知，該方案在路由收斂時間上與原方案相比大幅縮短，避免了因超時無法收斂導致的路由不可達問題；并且比原方案能夠正常收斂更多的路由條目，滿足更大規(guī)模網(wǎng)絡部署需求。從工程應用角度看，該方案雖占用了少量星地鏈路，但突破了目前衛(wèi)星IP網(wǎng)絡的規(guī)模瓶頸，極大提升了網(wǎng)絡規(guī)模的上限，在大規(guī)模星地協(xié)同組網(wǎng)、一體化網(wǎng)絡架構中具有較高應用價值。