摘要
这是OSPF协议的两份报告中的第一份,这些报告是因特网工程指导组要求的,是用来将一个因特网协议写成标准草案的。OSPF是一个TCP/IP协议族中的一个的路由协议,被设计用于一个自治系统的内部(换句话说,OSPF是内部网关协议)。
这份报告试图总结一下OSPF第二版本的关键特征,它也试图去分析该协议在因特网中将如何运行和扩展。
1.0介绍
这份文档为OSPF V2说明了因特网工程指导组将一份协议升级为标准草案的一些要求。这些要求会被在下文简单的加以总结。文档剩余部分则说明了OSPF V2如何去满足这些要求:
1.1基本
OSPF协议是由Internet任务工程组的OSPF工作小组开发的。
2.0 OSPF协议的关键特征
这部分总结了OSPF的关键特征。OSPF是一个内部网关协议,它被设计用于一个单一自治系统的内部。OSPF使用基于链路状态和SPF算法的技术(其余的路由协议比如RIP则是基于距离向量或者Bellman-Ford算法的)。一个链路状态通告描述了部分OSPF路由区域(自治系统)的情况。这些LSAs在路由区域内传递,形成链路状态数据库。每一个路由都有一个完全一样的链路状态数据库,链路状态数据库的同步依赖于一个可靠的flooding算法。根据这个链路状态数据库,每个路由器通过计算一棵最短路径树建立一个路由表,而最短路径树的根就是进行计算的路由器本身。计算过程通常被称作Dijkstra算法过程。
LSAs是很小的,每一个通告都描述了OSPF路由域的一小部分。也即是:附近的路由器,附近的一个传输网络,一个区域间路由或者一个外部路由。
OSPF协议的其余关键特征如下:
3.0协议开销
这部分试图分析OSPF协议如何在网络中运行和扩展。在本次分析中,我们将会专注在以下四个部分:
l 链路带宽。在OSPF中,可靠的Flooding机制被用来保证路由器之间的链路状态数据库是同步的。链路数据库的单条记录会定期被更新,但是不经常发生(大约30分钟一次),这是在拓扑结构没有变化的时候。而随着网络规模的扩大,Flooding过程所消耗的链路带宽也会一起增加;
l 路由内存。OSPF链路状态数据库可以变得非常大,尤其是当出现很多的外部LSAs的时候,这就需要更多的路由内存
l CPU的使用。在OSPF中,这是由计算最短路径所花时间的长度主导的。它是OSPF系统中路由数量的函数;
l 指定路由的角色。在多路访问网络中指定路由比其他链接到网络的路由会接收和发送更多的包。而且,也会有一些时间花费在:当老的指定路由失效的时候切换到新的指定路由上去(尤其是当指定路由和备份指定路由同时失效的情况)。因为这个原因,你可能会想去限制连接到同一个网络的路由器的数量。
剩余的部分将会分析这些方面,去估计OSPF协议将会在现在和未来产生多大的开销。为了辅助分析,下一部分将会展示一些从实际的OSPF部署中得到的数据。
3.1实际数据
OSPF协议已经被部署到因特网的许多地方,所以可以通过本地网络管理设备从一些实际的实验中收集一些数据。一些数据展示如下表:
表1 相关实际数据
第一行数据显示了三个网络上数据收集的时间,其余的数据简单解释如下:
l Dijkstra频率。在OSPF中,Dijkstra计算仅仅包含属于自治系统的路由和传输网络。Dijkstra算法只会在系统发生变化的时候运行。值得注意的是在这些系统中,Dijkstra运行的其实并不频繁(最频繁的才13分钟一次);
l 外部增减变化频率。在OSPF中,当一个外部路由变化的时候,只有它在路由表中的记录会被重新计算,这就是外部路由变化更新。要注意的是,外部变化发生的频率要比Dijkstra运行的频率高得多(换句话说,外部增减变化节省了很多的运行时间)
l 数据库更新。在OSPF中,链路状态通告每30分钟更新一次。当网络拓扑发生变化的时候新的通告就会被更加频繁的发出去。表格数据显示,即使将网络变化考虑在内,通告还是平均接近30分钟更新一次。这些数据将会在接下来的链路带宽计算中被使用。
l 每一个包中的LSA。在OSPF中,多个LSAs可以被包含在一个链路状态更新或者链路状态告知包里面。表格数据显示,一个包里面平均有3个LSAs。这些数据是将传送出去的LSAs除以广播数量得到的;
l Flooding重传。这里计算了链路状态更新包和链路状态确认包两种包的重传,算出了作为原始包数量的百分比。表中数据显示Flooding工作的很好,重传的包的数量在链路带宽计算中基本可以被忽略。
3.2 链路带宽
在这一部分,我们试图去计算OSPF的Flooding过程消耗了多少的链路带宽。链路带宽的消耗随着OSPF数据库中的通告数量线性增加。我们假定OSPF数据库中主要的通告是来自自治系统外部的LSA。
根据在3.1中的表格数据,任何通告都会在30分钟左右被Flood一次。另外,一个数据包中包含三个通告。一个自治系统外部的LSA是36个bytes大小,加上1/3的头部大小(IP头部大小加上OSPF更新包的大小)是52个bytes。每30分钟传输这个数量的数据,平均速率是23/100bits/s(52*8/30*60)
如果你想把路由通信量限制在总体带宽的5%以下,你就会得到以下数据库的最大值
表2链路速度和数据库的大小
(2087=9.6Kb/s * 5% /(23/100b/s) )
更高的链路速度没有被包括进来,因为其他因素会在链路速度成为问题之前限制数据库的大小(比如路由内存)。值得注意的是,在前面的计算中,数据链路头的大小没有被考虑进去。而且,注意到虽然OSPF数据库中绝大部分是外部路由LSAs,其他的LSAs也还是有大小的。粗略估计,路由链路和网络链路大概是外部链路的三倍大小,总共的链路通告则和外部链路LSAs差不多一样大。
OSPF比起RIP消耗的链路带宽要小得多。这在NSI网络中已经被实际验证。
3.3 路由内存
OSPF的存储需求是由链路状态数据库的大小决定的。根据前面的部分,合理假设数据库中的绝大部分通告是外部LSAs。外部LSAs是36个byte大小,它会被OSPF实现利用一些支持数据存储下来。所以,一个外部LSA尺寸比较准确的估计是64bytes。所以一个有10000条外部LSAs记录的数据库会消耗640kb的路由存储空间。P4200是由足够的存储空间容纳10000条外部LSAs的,并且也有足够的包缓存空间供足够数量的接口使用。
同样需要注意的是,别的LSAs也有一定的尺寸。
3.4 路由CPU
假设随着OSPF路由域的扩大,每个路由的接口数量仍然是有限制的。那么Dijkstra算法的复杂度就是O(n*logn)的,n是路由域中路由的数量。当然,至于到底Dijkstra算法会消耗多少的计算能力,这要看算法的具体实现。
我们没有真的OSPF实现中Dijkstra算法CPU消耗量的具体实验数据。然而,Steve Deering在”MOSPF meeting report”中呈现了Dijkstra算法的结果。他的计算是在DEC5000上进行的,使用斯坦福的网络作为模型。他的图是基于网络的数量而不是路由的数量。但是如果我们推断路由数量和网络数量一致,那么在Steve的实现中200个路由运行Dijkstra算法的时间大约是15ms。
这看上去是一个合理的开销,尤其是当你注意到Dijkstra计算在实际的部署中运行的并不那么频繁。在3.1中展现的三种网络平均13-50min运行一次Dijkstra算法。由于Dijkstra算法运行的并不是那么频繁,所以大致上OSPF比起RIP来可以更少的消耗CPU资源(RIP频繁的更新,要求查询路由表)。
另外一个例子是,MILNET中的路由算法是基于SPF的。MILNET目前有230个结点,路由计算仍始终低于MILNET交换机处理器能力的5%。因为MILNET网络中的路由算法会根据网络负载调整,它会非常频繁的运行Dijkstra算法。然而,需要注意的是MILENET中的路由算法会逐渐的更新SPF树,而OSPF每次计算都会从头开始构建树。
OSPF的域能力提供了一个方法来减少Dijkstra开销,如果它的开销过大的话。路由域可以被分割成很多个域。每次Dijkstra计算的范围以及复杂性都被限制在一个单独的域中了。
3.5 指定路由器的角色
这部分探索了一个单一网络可以容纳的路由器数量的最大值。随着一个网络中路由器数量的增长,OSPF产生的路由通信量也会增加。有一些是建立通信的通信量,大致每隔10秒中每隔路由就会广播一次。这个开销是网络中所有路由一起产生的。然而,由于指定路由在Flooding过程中的特殊角色,指定路由最后肯定会比网络中别的路由产生更多地链路状态更新包。而且,其余的路由只会从指定路由获取链路状态确认包,而指定路由则会接收所有路由的确认包。
所以,如果LAN上协议的通信量成为一个问题的话,问题一定最先在指定路由上被探测到。然而,这样的问题在实际中是不会产生的,因为OSPF产生的路由协议通信量被证明是很小的。而且,如果需要,OSPF的Hello定时器可以被设置来减少网络上的路由协议通信量。在协同工作测试中,13个路由器被放置在一个网络中,而没有任何问题发生。
另外一个问题是,当指定路由失效,新指定路由的切换时间。OSPF有一个备份指定路由以便于当当前的指定路由失效的时候,切换到新的指定路由器不需要需要等到它和所有其余的路由完成同步才能进行。然而,有一些极端稀少的情况是,指定路由和备份指定路由同时失效,则新的指定路由在可以工作之前就需要和其余的路由进行同步。现场实验表明同步过程发生的非常及时。然而,在有很多的路由的网络中这或许会是一个问题。
在LAN中路由数量成为问题这样一个不太可能发生的事情上,也不会因为路由协议通信量或者切换时间成为一个问题,因为LAN可以被切分为几个单独的部分(类似于将AS切成几个域)。
3.6总结
总体看来,限制OSPF系统大小的瓶颈最有可能是路由的内存大小了。我们已经知道,通过特定实现的配置组合,10000条外部LSAs是可以被支持的。其他的实现或许会有所变化。如今的路由已经有越来越多的内存了,而且10000个路由器已经远比最大的现实实现要大得多了。
注意到,在一个路由范围中,是可以有一些别的办法去减少数据库大小的。第一,路由范围可以利用默认路由,减少导入的外部路由的数量、第二,EGP协议可以被使用来在AS之间传递路由信息,而不用依赖IGP(这里是指OSPF)来做路由信息转换;第三,内存不足的路由可以使用末梢区域;最后,如果网络抛弃了平面地址空间,导入OSPF路由范围的外部信息的数量就会被大大的减少。
虽然不大可能,但是仍然有其他因素会限制路由范围的大小,比如:如果链路很慢,那么数据库的大小就会受到限制;如果有网络中有上百个路由,Dijkstra算法就会变的非常昂贵;最后,当有很多的路由在同一个网络中的时候,那么指定路由就会承担过度的负担(这个时候LAN可以被分解成几个单独的LAN)。
4.0 适合的环境
OSPF协议适合大小各异的网络环境。OSPF有以下几个原因特别适合transit自治系统:OSPF可以承受大量的外部路由;使用OSPF,外部信息的导入非常灵活,提供了forwarding address,两种外部路由度量方式以及为了方便管理管理外部路由使用AS数字给它们打上标签的能力。当外部路由变化OSPF可以只进行部分更新的能力使得它在这些网络中变得非常有用。
OSPF也因为它的一系列特征,非常适合更小的,独立的或者stub自治系统:快速集合,等价路径负载均衡,TOS路由,域,等等;
5.0 不适合的环境
OPSF的表达策略能力很有限。基本上来说,它的策略机制只表现在四种路由类型的建立中:域内路由,域间路由,E1,E2。如果一个系统想要更加精细的策略,就将它划分成多个独立的自治系统,使用基于策略的EGP连接它们。