一种星地协同的路由协议处理架构方案*

毛一丁，薛治纲，孙汉汶

(中国空间技术研究院西安分院，西安 710000)

0 引言

卫星通信具有覆盖范围大、机动灵活、信道质量好等优点，已经在航空、海事、空间通信、深空探测等多个领域成功应用。随着卫星通信技术的不断发展，卫星通信已从仅有透明转发实现了向星上处理的体制跨越，星上交换技术也经历了从ATM交换到IP交换的发展过程[1]，而星上IP路由协议也就逐渐成为研究的热点。

目前制约卫星星上处理类通信体制发展的主要因素之一是硬件器件的能力。太空中由于温度变化和辐射效应的影响，使得地面常规微电子器件无法在太空中正常工作[2-3]，宇航级处理器和存储器件的容量和工作频率等通常远低于普通商用级器件；另一方面，地面成熟路由协议通常具有协议开销大、计算复杂度高等特点[4]。二者的矛盾直接制约了大规模星地IP路由技术组网的应用[5]。

由于卫星具有严格的轨道运动特点，并且卫星载荷处理能力往往受到较多限制，因此绝大多数卫星IP网络路由设计都结合卫星(群)的运动轨道进行。例如，张晓娜[6]等提出的基于SDN的星地协同的一体化路由架构，通过结合卫星运动轨迹计算生成路由；吕原草[7]等提出的一种星载高速路由器设计方案，用于解决星地多节点组网条件下的高速路由交换问题；Long等提出的针对双层LEO/MEO卫星网络的QoS路由算法[8]，该算法通过遗传算法、蚁群算法等优化卫星网络的路由性能。另有文献[9]中提到的几种多层路由算法，虽然未涉及星地协同，但其中提出的复杂路由计算交由资源相对不受限且计算能力更强的节点完成的处理方式，实际上与星地协同路由类似。这些路由方案虽然适用于卫星组网，但并未适配标准的路由协议，不能与地面传统IP路由协议直接互联互通，特别是当由GEO高通量卫星和地面网络共同组成星地一体化IP网络时，在卫星上实现地面通用路由协议(如RIP、OSPF等)就显得尤为重要。2008年投入商业运行的Spaceway3卫星[10]支持大容量星上IP业务交换，该系统通过一个地面控制中心收集全网路由信息并进行域内路由计算，用户终端只需要实现用户侧的域内路由协议，即可通过与NOCC的交互实现路由信息的更新。虽然其完美的支持了IP业务，但仍不具备自主运行标准路由协议的能力。目前已知在卫星上实现标准路由协议的思科18400太空路由器[11]，采用与地面相同的IPv4协议栈和OSPF路由协议，可完全不依赖地面路由设备进行星上自主路由，实现与地面路由器完全对等的功能，但由于星上对IP数据包处理能力限制，其吞吐量仅为250 Mbps，性能不能满足未来空间组网需求。

未来卫星通信的IP化仍是主流方向，且随着以空间激光技术为代表的高容量传输技术的发展[12]，天地一体化大规模组网是未来发展的趋势。卫星路由与地面路由对等交互是大规模组网的必要条件，而路由快速计算和收敛，是大规模组网面临的重要问题[13]。

针对以上矛盾，设计了一种星地协同的路由协议处理架构方案，通过增加星地协同处理机制，将复杂路由处理由星上移动到地面，以降低IP路由协议对星载硬件平台处理能力的要求。

1 星地协同路由处理方案架构

由于受宇航级器件处理能力的限制，星载IP路由器通常使用CPU处理路由协议，使用FPGA完成路由表查表和交换功能[14]。即使如此，CPU的处理能力仍然是整个路由器的性能瓶颈，例如一款国产宇航级32位处理器BM3803的频率仅有70 MHz，远低于地面同类器件[15]。通过路由与管控联合设计，将路由协议数据包通过专用信道发送到地面进行处理，降低星载CPU处理复杂度，实现星上处理的简化。

如图1所示，是星地协同路由处理方案与传统方案的对比。图1(a)是传统星载IP路由协议处理载荷方案的组成示意，主要由高速交换及接口FPGA、路由查找FPGA和路由处理CPU组成。其中路由查找FPGA负责根据指定的目的IP地址查询路由表，得到对应的出端口；高速交换及接口FPGA负责路由器对外实体接口和路由处理CPU之间数据的收发；路由处理CPU实现了TCP/IP协议栈，负责与其它对等路由器之间实现完成协议交互，并生成路由表供路由查找FPGA使用，同时实现星载IP路由协议处理载荷管理控制功能。图1(b)是星地协同路由处理方案架构，与传统方案不同的是，该方案将原本均在卫星侧实现的功能拆分为卫星侧和地面侧两部分，将高复杂度的路由协议处理交由地面处理设备执行，卫星侧仅负责IP报文的查表交换和简单的管控功能。地面路由协议处理设备由于没有宇航级器件使用限制，可采用x86架构和高速SDRAM，极大提升处理能力。

星地协同路由处理方案在交换及接口FPGA中增加一个数据分发模块，该模块的主要功能是将数据包按星地专用链路和业务信道帧格式封装、解封并相互转换。通过这一模块可对原有业务信道传输的数据帧屏蔽星地协同专用链路的存在，使新方案与原有方案之间松耦合，并可将星地协同专用链路作为一个对外业务接口统一处理流程，最大限度兼容已有设计。

(a)传统路由处理载荷方案

(b)星地协同路由处理方案

2 星地协同路由处理方案的设计与实现

2.1 数据结构设计

1)路由表结构

由于将协议处理CPU移至地面侧，对于卫星侧的高速交换与接口FPGA来说相当于增加了一个外部接口，为最大限度沿用原有FPGA结构设计及业务流程，需在路由表中增加一个指向地面侧路由协议处理设备的标志位，新形成的路由表结构如表1所列。

卫星侧载荷和地面路由协议处理设备上电初始化时，需要在路由表中添加相关网段默认路由信息，并将其送地面标志位置1，以实现将协议相关IP包转发到地面路由协议处理设备进行处理。各种路由协议的IP包均有各自独特的特征，例如RIP路由协议封装在端口号为520的UDP包中、OSPF路由协议直接封装在IP协议类型为89的IP包中等。实际上对于IP单播包，只需要将目的IP地址为本路由器端口IP的数据包转发到地面路由协议处理设备处理即可。另外，组播路由协议及部分单播路由协议会使用224.0.0.0-224.0.0.255网段的组播地址用于路由协议或其他下层拓扑发现协议等，因此这一网段的组播路由也需要转发到地面进行处理。

表1 路由表结构

2)专用链路帧结构

在星地协同路由处理方案中，协议交互的IP包需要在高速交换及接口FPGA和地面协议处理CPU之间传输。由于在这一方案中，卫星侧并未实现TCP/IP协议栈，不能在该信道上直接传输IP包，且该信道还需将地面生成的路由表传递到载荷路由查找FPGA中。因此，需设计一种星地链路帧结构以保证不同类型的数据均能在星地之间可靠传输。

星地链路帧结构如图2所示，包含帧长、帧类型、各部分校验和净荷等字段。其中帧类型字段用于标示该帧内部净荷的类别，例如净荷为IP包则帧类型标示为0x80、ARP包标示为0x86等。包数量字段用于标示净荷部分包含的有效数据包的数量，当净荷为IP包或ARP包时，该字段填1；若为路由表配置信息时，该字段按净荷实际携带条目数填写。为了适应不同包长的IP包和配置包，净荷部分是可变长的，最长不超过1 518 B，这是由于星地之间并非对等TCP/IP架构，净荷长度设计满足将最长IP包和MAC帧完整放入，以避免IP分片情况发生。帧长HEC、帧头CRC和帧校验字段分别用于对帧长字段、帧头部分和整帧内容进行校验，保证帧的正确截取和传输。

图2 星地链路帧结构

地面路由协议处理设备收敛路由协议后，使用帧类型为0x50或0x55的帧向卫星侧载荷进行传输。如图3所示，配置的每条路由表长度为20 B，故每个链路帧净荷中最多包含75条路由配置信息，实际包含的条数须填写在链路帧头“条数”字段中。路由删除与配置方式类似，只需将帧类型由0x50、0x55替换为0xA0、0xA5即可。

图3 路由表配置帧结构

2.2 处理流程设计

当载荷和地面路由协议处理设备加电后，根据地面处理设备初始化的端口信息，向卫星侧路由查找FPGA配置端口默认路由信息，共直连网段查表使用。正常工作阶段，交换及接口FPGA由业务接口或星地专用链路接收数据包、判断数据包类型，按如下类别分类处理：

1)IP单播、组播包，送路由查找FPGA查询路由表，根据查询结果按出端口转发或送数据分发模块发往地面处理；

2)IP广播包、ARP包，所有端口广播，同时送数据分发模块发往地面处理；

3)路由配置包，将数据包送往路由查找FPGA配置星上路由表用于查表转发；

4)管理控制包，送往星上管理控制CPU进行处理。

地面数据分发模块收到星上发来的数据包，解帧后送路由协议处理设备处理。对于ARP、普通IP包(如ICMP包)等，经由TCP/IP协议栈处理后直接返回响应包，并由地面数据分发模块组帧后发回星上，按查表结果转发；对于路由协议包，除经由对应的路由协议处理并返回响应包外，还需将生成(删除)的路由按对应路由表配置帧格式进行组帧，并发送到星载设备中，供IP路由交换查表使用。

当地面侧和卫星侧均完成路由协议收敛和路由配置后，对于绝大多数普通业务IP包的转发只需要卫星侧交换及接口FPGA和路由查找FPGA即可完成，无需地面侧参与，即与传统架构处理流程无异。

3 测试验证

测试采用Spirent Testcenter网络测试仪对两种路由处理方案的实际效果进行测试，并进行对比。其中传统路由处理方案采用CPU为BM3803的硬件平台，主频设置为60 MHz；星地协同路由处理方案使用x86架构实现。二者均使用开源的Quagga软路由套件编译实现被测路由协议。测试分别针对RIP、OSPF两种单播路由协议和PIM-SM组播路由协议进行，使用Testcenter网络测试仪分别发布不同条目的外部路由，并建立目的IP为对应外部路由的数据流，通过统计路由发布时间和数据流成功转发时间之间的差值，得出路由协议收敛时长。由于GEO卫星的星地链路双向传输时延仅约300 ms，并且路由查找及交换处理采用FPGA实现，时延一般小于5 ms，这两类时延与几十s甚至数百s的收敛时间相比差距过大，因此在路由收敛时间统计时将二者忽略不计。

如图4所示，是两种方案下分别发布RIP路由，路由收敛时间随路由条目数变化结果图。从图中可以看出，当发布的路由条目数较少时，二者在收敛时间上没有过于明显的差异。但随着发布的路由条目逐渐增多，使用BM3803处理器平台的传统路由处理方案收敛时间明显快速增加，在2 000条路由时收敛时长已超过60 s；3 200条路由时收敛时间已不可接受。而使用x86架构模拟的星地协同路由处理方案在发布4 000条路由时收敛时间依然在30 s以内。

图4 RIP协议收敛时间随条目数变化图

如图5所示是OSPF路由的测试结果。与图4类似，OSPF路由收敛时间结果与RIP协议基本呈现相同的变化趋势，但由于OSPF路由协议需要根据收到的LSA计算路由，处理复杂度比RIP协议更高，故体现在测试结果上相同的路由条目数所需的收敛时间也更长，并且BM3803处理器平台在路由条目达到3 600条时已无法收敛。

图5 OSPF协议收敛时间随条目数变化图

如图6所示是PIM-SM组播路由协议在两种方案下收敛时间随条目数变化结果图。从图中可以看出，在不同的路由条目数时x86架构的收敛时间也明显优于BM3803处理器平台，但总体收敛时间在可接受范围内。分析收敛时间可控的原因一是由于发布的组播组数量明显少于单播路由数目；二是组播组只从一个业务端口发布，IP包数量较少，若同时从多个业务端口发布相同的组播组，收到的IP包数量会急剧增加，收敛时间也会相应增长。

图6 PIM-SM组播协议收敛时间随条目数变化图

4 结论

针对宇航级器件能力无法满足路由协议处理需求的问题，通过对不同业务与协议IP包的特点进行分析，设计了一种星地协同路由处理方案，同时设计了对应的路由表结构和链路帧结构，通过业务处理星地分担的方式，极大减轻星载设备负载，实现处理能力的大幅提升。同时，该方案最大程度继承了已有硬件设计和业务流程，避免破坏现有网络体制和设备部署，使得方案在工程上更加容易实现。通过测试实验验证可知，该方案在路由收敛时间上与原方案相比大幅缩短，避免了因超时无法收敛导致的路由不可达问题；并且比原方案能够正常收敛更多的路由条目，满足更大规模网络部署需求。从工程应用角度看，该方案虽占用了少量星地链路，但突破了目前卫星IP网络的规模瓶颈，极大提升了网络规模的上限，在大规模星地协同组网、一体化网络架构中具有较高应用价值。