通用操作系统交换路由器操作系统实现( 三 )


 
值得注重的是,在交换式路由器中,处理引擎通过交换结构交换的是IP包;而通用操作系统中网络驱动通常处理链路层的帧 。即控制卡驱动模块数据通道对上对下的数据格式是不同的 。因此,在发送数据时控制卡驱动模块需要从得到的链路帧中提取IP包再转发到端口;而接收数据时则对来自端口的IP包进行链路帧封装再向上提交 。以以太网为例,需要恢复的包括源和目标站的物理地址、载荷类型和帧校验[3] 。对于承载IP包的以太帧,显然其目标站物理地址和载荷类型[4]都是已知的 。实现时采用的操作系统是Linux,通过在虚拟网络驱动源代码中进行设置可以使内核不进行帧校验[5] 。所以只有源站物理地址未知 。假如要求硬件给出真实的源站物理地址,则增加了硬件的复杂度;而若在控制卡驱动模块中伪造源物理地址,则可能导致内核的ARP治理混乱 。为简化硬件设计,实现时采用了在控制卡驱动模块中伪造源物理地址的办法,同时修改虚拟网络驱动源代码,重载帧头处理函数[6] 。这样内核ARP表就不受伪造地址的影响,其获取和刷新通过查询端口ARP记录实现 。
2.2 控制通道的功能与实现
控制功能的通信也是基于信元的,其操作包括维护治理和表同步两类 。维护治理主要是进行各种查询,通常通过若干次双向通信完成 。每次通信有效载荷都只有几个字节,由一个信元即可承载 。而表同步则是将上层软件维护的表复制到相关硬件中,包括ARP表、路由和分类表等 。表同步操作涉及大量数据传输,需要由多个信元承载 。控制功能都是针对设备进行的,所以在控制/反馈信元中也必须包括目标设备的物理位置信息 。
在实际运行期间,所有的上层应用和设备之间的控制通信复用控制通道,其特点为:
(1)不同的应用可能同时访问同一设备;
(2)一个应用也可能同时访问多个设备;
(3)同一应用对于同一个设备的操作一般都是顺序的 。
为支持这种复用操作,所有承载控制信息和反馈信息的头部除包括目标硬件的物理位置和操作指令外,还包括命令类型、应用类型信息 。控制/反馈用信元结构如图5所示 。
 
图5中:处理引擎号和端口号,确定设备的物理位置;收/发信元分别为该信元的源端口的和目的端口的对应值;命令码在设备和应用之间定义 。每种可能的操作分配一个代码;应用码在控制卡驱动模块和上层应用之间预定义 。每种可能的应用分配一个代码 。这些应用包含网管、路由维护、硬件维护和ARP信息获取等 。
上层应用通过内核调用陷井(IOCTL)发起控制通道操作,同时给出目标设备物理位置、命令类型代码和应用类型代码 。控制卡驱动模块把这些信息填充到控制信元中再将其发往设备 。设备把这些代码直接复制到反馈信元中,再在后面追加上反馈信息 。控制卡驱动模块为每一种应用分配一个循环缓冲区,把收到的反馈根据应用类型排入相应队列中 。上层应用从其所对应的循环缓冲区中读取反馈信元,然后根据信元中的物理位置信息、命令码就可以确定该反馈对应的原始命令,从而对反馈数据进行适当处理 。这样就实现了各种控制功能对控制通道的复用 。如图6所示 。
3 结论
鉴于传统路由器体系结构和交换式路由器体系结构的区别,通用操作系统及在其上开发的路由软件无法直接应用于交换式路由器 。本文提出的中间层方案可以有效地解决这个问题 。该方案全面考虑了数据通信和治理维护方面的需求,为上层提供了与原有模型基本相同的接口,并使得路由软件在不损失其灵活性和可升级性的条件下直接应用于交换式路由器中 。虽然该方案只是在特定的平台和特定的操作系统上得到了实现,但是不难看出,这种思路对操作系统并没有非凡的依靠性,完全可以移植到其他通用操作系统上 。本文提出的方案已经在国家863项目实用化综合接入系统的高速边缘路由器的研制中取得了良好的实际效果 。本文为国产高性能路由器的软件开发提出了一种高效快捷的解决方案,该方案具有良好的应用前景 。

推荐阅读