网聚NO.1

源路由网桥曾经是给IEEE802.1委员会的一个提议，和透明桥接技术相竞争以期成为局域网联接的数据链路层的标准。而当802.1委员会决定采用透明桥接的时候，源路由网桥的推荐者则将这个概念提交给802. 5委员会加以标准化，使其成为802.5局域网互连的方式。在一个时期，透明网桥和源路由网桥是各自独立发展的。但随之而来的需求是要设计一种方式来满足通过透明网桥互联的局域网和通过源路由网桥互联的局域网之间的连接。这种网桥被称作SR-TB（源路由网桥—透明网桥）。这种方式被证明是完备的，尤其是当人们企图创建一个要同时使用这两种网桥的局域网的时候。最终，所有的标准网桥都必须支持透明网桥，而源路由则被作为一个可选配的附加特性。一个附带有源路由报头信息转发的透明网桥被称作SRT（源路由透明）网桥。在这里不厌其烦地讨论源路由有很多原因。这种技术还没有完全被淘汰，许多人仍不得不去理解并掌握它。源路由报头包括在当前的标准中， 802标准看起来仍不打算淘汰它。但最主要的是它的教育意义，可以让我们学习一种不同的方法，不管它的好与坏，它确实给了我们一个洞察协议内部的机会。
纯源路由
源路由网桥的基本思想是：数据包头含路由信息，而该路由信息在源端就已经插入。在源端获取到目地端的路由，必须通过发送一个特殊的包来发现，这个包到达一个路由分支点，就开始复制自己并向任何可能的路径发送一份备份。每份备份收集它的旅行日记，当备份到达最终目的地时，一个路由就被选择好了。当一个站点发现了到达另一个站点的某个路由时，它就把它存放在缓存里，以后的数据包就可以使用它到达目的地。
路由信息报头
通常，局域网上一个数据包的数据链路层报头大致看起来如下图所示：

还有其他字段，譬如SAP与/或协议类型字段、校验和以及特定局域网字段，譬如长度和优先级，但这些字段在此无关。一个源路由包需要在报头里添加额外信息，包括在一个叫做RI（路由信息）的字段中。所以必须要用一种方法对含有附加字段的包和不含有附加字段的包加以区分，否则把用户信息误认为源路由报头信息就麻烦了。区分报头中包含路由信息和不包含路由信息的包的方法是利用前述的数据包格式里的“否则无用”标志位（如果你对源路由不是很熟，最好先暂时不要往下读，而去回顾一下前面所述的数据包结构[有三段，分别是目的、源和数据] ，并判断出这个标志位所在的位置）。这个标志位是一个在源地址段的组播位。原因是没人会从一个组播地址发送包（很幸运，在源路由网桥提议前，还没有哪个应用使用这一位）。如果这一位在源地址中为0，则认为这个包是普通包。反之如果该位被置1，则可认为紧跟在常规数据链路层报头后面的应该被解释为源路由报头。这样，一个没有RI字段的包结构如下所示：

一个有RI字段的包看起来如下图所示：

RI字段包括了额外的源路由信息。它包括如下字段：
. 类型（3位）：有下面三种：
a. 特定路由（这个路由出现在报头中）。
b. 全路径搜索（路由通过搜索包遍历网络收集）。
c. 生成树搜索（路由通过搜索包遍历网络收集，就像全路径搜索一样，但是包只在生成树的分支间遍历）。
. 长度（5位）：指定R I字段所占用的字节数。
. 方向（1位）：指定路由是从右往左遍历还是从左往右遍历。
. 最大帧（3位）：指示最大帧的大小，它的值为下面几个比较常用的包的大小之一（516，1500，2052，4472，8144，11407，17800，65535）。
. 路由：一个双字节序列字段，叫作路由指示器，每个双字节包含一个12位局域网编号和紧跟其后的4位网桥编号，见下图。

网桥编号
在扩展局域网里，每一个局域子网必须分配一个唯一的局域网编号。我们来看看为什么4位的网桥编号是必须的，假设一个路由由一组局域网编号的序列组成，它的拓扑图如下图所示。

如果一个数据包的路由是从LAN A到LAN C，则上面的五个备份都会到达，因为这五个从LAN A到LAN C的网桥都假定自己应该传递这个数据包。如果并行的网桥存在多跳，则传送的备份数将随着中继数目的增长呈指数级增长（见下图）

为了解决这个问题，每个网桥就必须引入4位的编号来和其他连接同一局域网的网桥区分。每个网桥必须为每个端口配置局域网编号并加上网桥编号。网桥序列号的分配必须遵从连接在相同的两个局域网的两个网桥不能使用相同网桥编号的规则。
注意：标准要求为每一个网桥分配一个单独的网桥编号，而不是为每对被网桥连接在一起的局域网分配一个单独的编号。如果网桥有许多端口，并且每个网桥只有一个独立的网桥编号而不是每对端口有一个，则有可能存在一个拓扑结构使得网桥编号无法分配。但这样的恶梦是可以解决的，尤其是当一个网桥有成百上千个端口时。
1. 内部局域网编号
为一个拥有n个端口的网桥配置n2个网桥编号的一个可行办法是把网桥的内部看成是另一个局域网。见下图。

在这个例子里，B有7个端口。与其小心翼翼地为它的每一对局域网连接分配一个网桥编号，不如选择一个不使用的局域网编号，在这里为47，看上去像是B的一个内部局域网。从第17号局域网到第78号局域网看起来好像是经历了三个局域网： 17、47和78。网桥B仅仅是一个任何网络同第48号局域网的联接，所以不必为B分配任何网桥序列号。把它指定为1号网桥就完全可以了，因为仅仅存在从第47号局域网到其他真实局域网的局域网对。这种安排使得路径看上去变长了，但是它确实是唯一一种对付有很多端口的源路由网桥的实用方法。
2. 路由
路由确实是一个交替的局域网和网桥编号序列，总是由一个网络编号开始并结束于一个网络编号。一个局域网编号和一个网桥编号被一起装到一个独立的路由指示器中，其实仅仅就是人为地把信息存储到字节中。把路由看作是(局域网，网桥，局域网，网桥， . . . . . .，网桥，局域网) ，这样理解就简单了。路由是否有效与路由指示器的最后4位网桥编号是不相关的（它们可能是0，但标准中忽略了那个字段，所以不管最后的4位为何值，路由总是有效的）。
3. 建立并行网桥的理由
建立并行网桥（两个或更多的网桥联接同一对局域网）的理由有如下几个：
1) 健壮性：如果一个网桥瘫痪了，其他的还可以继续工作。
2) 提高网桥效能：如果一个网桥不能应付全带宽的传送，就可以将不同类的传送均匀地分布到各个网桥上，达到负载平衡。
3) 低带宽链接：在下图中，B1通过一个慢速的点对点链接和B4通信，B2和B3也类似。在两个局域网中架设网桥，传输必须通过至少其中的一个慢速连接。如果所有的传输都集中在B1-B4的链接上，则传输能力的上限为B1到B4的带宽。但是如果能有一部分传输转移到B2-B3链接上来，则LAN1和LAN2间的整体带宽就提升了。
注意：如果在下图中使用透明网桥，则生成树将会在两个链接（B1-B4或者B2-B3）中挑选一个加入树中，所以所有的传输都只能通过其中一条链接，将负载平衡变得不可能。但是，可能通过使用透明网桥的多级并行低速链接来实现一个交错拓扑（见图“并行链接”）。这个交错拓扑使用并行链接而不是并行桥接。在(图"并行链接")中，B1和B2使用并行链接作为逻辑上的单条高带宽链接。它们必须使用一些桥对桥协议来将数据包安排一个正确的传输顺序。并行网桥（图“并行远程网桥”）比并行链接的链接共享方法（图“并行链接”）具有的优势是并行网桥在网桥异常的时候可以进行操作（通过降低服务来减少带宽）。但是，并行链接配置比并行网桥具有两个优势：

1) 网桥可以控制每条链接的传输量，它们就可以平衡各条链接上的负载。而对并行网桥来说，就只能希望两个端点碰巧通过路径选择使负载分布均匀。
2) 一个很大通信量的会话可以在并行链接上的各条不同链接上传输，到达目的地后按正确的顺序重组，但对于并行网桥来说，这个大通信量的会话只能在一条路径上传输。

网桥算法
从网桥的观点上来说，有四种类型的数据包需要处理：
1) 没有R I字段的包，被称作透明包。
2) 特定路由包。
3) 全路径搜索包。
4) 生成树搜索包。
本节讨论一个网桥怎么处理这些数据包
1. 透明数据包
纯源路由网桥明确忽略没有RI字段的数据包。为了避免当一个局域网同时有源路由和透明网桥连接时引起混淆，透明网桥标准要求一个透明网桥忽略具有RI字段的数据包。这样透明包就可以由透明网桥处理，具有RI字段的数据包就可以交由源路由网桥处理。
2. 特定路由包
假设网桥B在端口P1收到一个特定路由包，这个端口连接到一个B认为是“X”的局域网上，B检查它的报头中的方向标志位，然后按适当的方向扫描路由寻找局域网X。如果下面所有的条件成立，B将将所有的数据包传递到端口P2：
1) X出现在路由里。现在假设紧随X的网桥编号是Bn，而紧接着X的下一个局域网的编号是Y。
2) B通过端口P 2连接的局域网的编号是Y。
3) B对应端口（P1,P2）对的网桥编号是Bn（或者B对任何端口对都使用同一个网桥编号Bn）。
4) Y并不出现在路由的其他任何地方（否则，一个包将会被无休止地重复生成。）。
3. 全路径搜索包
假设网桥B在端口P1收到一个全路径搜索包，这个端口连接到一个B认为是“X”的局域网上。
一个端系统起初发送这个路由里没有任何中继信息的全路径搜索包。B必须首先检查这个包是否收集到了一个路由。如果RI字段只包含了包类型和标志位而没有实际的中继信息，则B对除P1以外的每个端口做以下操作：
1) B把路由初始化成“X，Bn，Y”，其中Y是B为端口P连接所设定的局域网编号，Bn是B对应端口（P1，P2）对的网桥编号（或者如果对每个端口对，存在一个桥宽的网桥编号而不是一个特定的网桥编号，则就简单地用B的网桥编号）。
2) B调整最大帧字段的值为该字段上端系统所指定的最小值，并把该值配置为B在P和P1上的最大可能帧。
3) B重新计算包内的CRC（循环冗余校验），因为这个包已经被修改过了。
4) B把这个包传递到P。
如果所有的全路径搜索包都通过其他的网桥（长度字段在6～28个字节之间，包含6和28），则P1接收到所有的全路径搜索包，所以B对除端口P1以外的每个端口P做下面的操作。如果下面的判定正确，B把P1端口的包传送到P（B把这个端口与编号为Y的局域网相联）
1) 收集到的路由信息的最后一跳是X（如果不是，B扔掉这个包，并记录错误）。
2) Y始终不出现在收到的路由中。
在把包传递到端口P之前，B作如下操作：
1) B通过给R I报头的长度字段加2来调整R I字段的长度。
2) B把它自己的网桥编号写到路由指示器字段的低4位，该字段包含局域网编号X。
3) B把Y添加到后面，作为下一个局域网的编号。
4) 如果B内设置为端口P的最大帧可能值比最大帧字段指示的当前值小，则B调节最大帧字段。
5) 因为数据包被修改，B重新计算CRC。
如果接收到的全路径搜索包中的路由为完整的，则丢弃该数据包。
4. 生成树搜索包
生成树搜索包和普通的透明包的功能一样。它在一棵生成树中传输。生成树搜索帧的一个明显应用是在组播包的传送中。组播包不能确定路由，因为它们要被传送到多个目的地。这时利用全路径搜索就显得不合适了，因为每个组播包的多份拷贝要被传送到每一个局域网。除了组播包的情况，标准从未澄清过什么时候应该使用组播包。一个端系统怎样去发现一个路由可以有很多可能的方案。其中一个是，会话的发起者用生成树搜索方式发出第一个包，目的地收到后给一个包含全路径搜索的回应。这样就可以由源端而不是目的端来选择路由了。
网桥处理生成树搜索包的方法和处理全路径搜索包的方法是几乎一样的。只有两点不同：
1) 网桥不检查在所收集的路由中是否已经有输出L A N。
2) 网桥只有当一个生成树搜索包到达生成树包含的某个端口时才接受它，并且仅仅把它传递到生成树里指定的其他端口。

SR-TB网桥
假设一个扩展局域网组被简单地分为两个部分：只通过透明网桥相连的为一部分，只通过源路由相联的为另一部分。而连接这两部分的设备就被称为S R - T B网桥（见下图）。虽然这种概念看起来好像老得即将入土了，但理解为啥还需要这个东西仍旧很有意义。

基本上，这样一个设备决定着哪些包需要被转发、哪些需要删除以及哪些需要添加一个源路由的报头（见下图）。

从TB端口发出的包
当从透明网桥局域网组出发的包到达SR-TB时，SR-TB网桥必须决定是否应该转发它（见下图）。

如果目的端被SR-TB网桥的TB部分认为是TB端口应该接收的一个地址，则SR-TB网桥不转发这个包（见下图）。

如果一个到目的端的路由已经被网桥的SR端储存在缓存里，这个网桥将会使用缓存里的路由把它当作特定路由转发包转发。如果缓存里没有目的端信息，则SR-TB无条件转发这个包。下面有几个选择：
1) 把它当作全路径搜索包转发。
2) 把它当作生成树搜索包转发。
3) 把包存放在缓存里，启动路由找寻例程，并当发现到目的地的路由时，转发这个包。
4) 扔掉这个包（希望用户能把它归因于局域网的拥塞），启动某种路由找寻例程，假设源端会重发这个包，如果它重要的话。如果幸运，当重发的包到达时，到达目的端的路由也已经找到。
这些选择取决于路由怎样被发现，这些永远也不会被标准化。SR-TB网桥获得到结点S的路由有两种可能的方法：
1) 收到从S端发出的特定路由包。
2) 从由S端发出的全路径搜索包中选择一个路由。
一个路由被储存后，保持它时有一个问题。SR-TB网桥并不需要知道使用这个路由转送到S端的包是否真的到达了。上一层并不能告之某个路由已经失效。这样，只有两种可能来从缓存条目里删除它：
1) 在一个指定的时间内，没有一个从S端发出的包（该包中的路由和缓存里的相吻合）到达，则删除该路由。
2) 不管接受的是什么业务流,仍要定期删除到S的路由。
这两种方案都不是很令人满意。如果路由删除过快，重新寻找路由的负荷就显著增加。同样，路由更改得越快，则用错路由导致数据包转发失败的可能性也越大。如果定时器设得过慢，一个已经失效的路由会被保存很久。

从SR端口发出的包
要处理SR端发出的包，用透明网桥互联的网络的每一端只分配一个局域网编号。甚至在一个TB端有多达成百上千个局域网，仍旧只要给它一个局域网编号，使它在SR端看来像是一个单独的局域网。见下图。

SR-TB网桥能够接收三种类型的包：
1) 特定路由。
2) 生成树搜索。
3) 全路径搜索。
前两种类型的处理很简单。如果SR-TB网桥收到一个特定路由的包，它的局域网编号指示它应该被转发到TB端，则SR-TB网桥先去掉源路由报头再转发这个包。如果SR-TB网桥收到一个生成树搜索包，它去掉源路由报头，并将它转发到网络的TB端的端口。而第三种的处理就非常困难。如果SR-TB网桥收到一个全路径搜索包，并且如果这个包的发送者期待目标端的回应，SR-TB网桥必须代表目标端做出回答。如果SR-TB网桥查到TB端存在目标，则它通过加入TB端的局域网编号来回答，并且沿着相反的方向发出一个特定路由包。如果SR-TB网桥没有查到目标的位置，就除去源路由报头，并将这个全路径搜索包转发到网络的TB端，并期望目标能够回答。SR-TB网桥允许为目标获得一个缓存入口，从而如果后面的全路径搜索包接二连三的到达，它可以做出反应。SR-TB网桥的协议先天混乱，因为发现路由的协议没有标准化。没有一个明显的方法，所有的策略都互相作用，绞在一起。
环
如下图指出的，SR-TB网桥可以组成一个环。下面列出几个实质的策略来防止它的发生：

1)整个扩展的局域网（SR网桥、SR-TB网桥和TB网桥）都作为一棵生成树的一个实例。这种做法存在生成树会在生成的时候断开某个网组的危险。此外，网组内的站点间不得不通过SR-TB网桥或其他类型网组来通信，由此而降低了这个网组内部的性能。
2)SR-TB网桥能够在它们内部成生成树中独立的实例。在这种情况下，SR-TB网桥会打破这个循环。而各个网组仍然保持完整。

SRT网桥
你能够设计一个网络，它的某些独立的网段由一个源路由网桥联结在一起，某些由一个透明网桥联结在一起，然后它们再由一个SR-TB网桥联结在一起。但这种策略证明不能令人满意。SR-TB网桥有一些不能解决的问题（当它们的路由缓存里有无效的路由时，功能上会有“黑洞”；它们的路由寻找策略必须兼容所有可能的源路由端系统实现）。还有个约束是当这两种网桥系统都桥接到FDDI（光纤分布式数据接口）上时，这两个网桥都不能工作。对此有个富有戏剧性的解决方案：源路由的提出者和SRT提议达成了一个标准，它抛弃了纯源路由网桥。源路由从802.5标准中删去，而改成透明网桥的一个可选择的“加强”。
这意味着只有两种标准类型的网桥：
1) 透明网桥。
2) SRT网桥，能够做源路由的透明网桥。
但是，虽然纯源路由网桥不被标准所支持，但并没有使它们在这个世界上消失。所以SRT的提议并不简化网桥世界，这就意味着四种类型的网桥将共存：SR、TB、SR-TB和SRT。一旦理解了透明网桥和纯源路由网桥， SRT网桥就很好理解了。SRT网桥就像纯路由网桥那样处理具有RI字段的数据包，并像透明网桥那样处理没有RI字段的数据包。用户可以创建一个任意混合这两种网桥（TB和SRT）的网络。如果某个端系统出于某种原因想要采用源路由，它可以尝试用那种途径来发现一个到目标的路由。如果这种途径失败，它总可以使用透明数据包通过生成树与目标通信。任意混合SRT和TB网桥存在着一个潜在的严重问题。一个站点在尝试通过源路寻找路由时会产生问题的情况下还是用源路由寻找，以期获得一个比使用透明包通过生成树方式寻找有个更好的路由。如果网桥中只有一部分是SRT网桥，源路由只能在这些SRT网桥中有效。有了这种约束，最好的源路由也有可能远不如生成树方式。

端系统算法
源路由标准总是使端系统操作开放，这样,端系统可以利用多种方法建立和维护路由。这种不制定唯一策略的作法是因为所有提出的策略都可圈可点。没有一个策略脱颖而出。在我看来，尽管这种可塑性也许不错，但在这种情况下最好标准还是选择其中的一种算法。否则，每个各自的端系统实现被迫要考虑各种五花八门的策略，显然这样将不能协同工作。如果两个源路由端系统分别由两个不同的组织来设计，必须考虑源路由查找策略的兼容性。如果至少有一种可以在所有情况下都能工作的很好的策略，它就要成为一个标准，而不去管某些可以在特定的环境下工作的更好的策略。如果没有一个策略能够应付所有的端系统，就不得不怀疑源路由这种网桥机制能否继续使用了。本节讨论和比较各种已经提出的策略。它并没有明确回答“我的端系统该怎么工作？”的问题。因为没有制定端系统的标准。但是，本节提出了在设计能够使用源路由的端系统时应该考虑的问题。很重要的一点，任何策略都要允许可以使用源路由的端站点与其他使用透明包的端站点之间能够通信。还有一点也很重要，就是即使两个端站点可以实现通过源路由来通信，但如果它们之间至少存在一个只能支持透明包的网桥，两个端点间就只能通过透明包来通信。

什么时候寻找路由
一个端系统什么时候尝试寻找到另一个端系统的路由呢？一个可能是当端系统要向目标传送一个数据包而缓存里没有现成的路由时它就要尝试去寻找路由。假设只有部分网桥和端系统实现了源路由（但所有端系统和网桥都必须实现透明路由），则一些目标只能通过透明桥接到达。因此，重要的是任何策略都要：
1) 如果源路由不能查出到某个目标的路由，不要声明这个不能到达的目标。
2) 如果路由不在缓存里，不要不断地尝试寻找目标的源路由。
如果端系统希望向目标传输一个数据包，而缓存里没有到目标的路由，并且端系统在最近的一段时间里没有尝试去寻找到目标的路由，则可以开始寻找到目标的路由。切记必须把近来尝试寻找目标的路由而失败的记录写下来。在这种情况下，那些只能通过透明网桥到达的站点的存在不会引起源端不断地查找路由。如果在端系统的通信过程是面向连接的，自然在每个会话初始化时就尝试查找路由。但是，它也许宁愿使用上次会话时保存在缓存里的路由而不在已经有路由记录的情况下尝试重新查找一个新的到目标的路由。如果一个连接不再工作了，它也许会要求尝试在声明一个连接终止前查找一个新的路由，因为有可能目标本身仍旧可以到达，但以前到目标的路由已经失效。现在假设发现了一个到目标的路由D，但是已经有了一个更好的路由。一个端系统到底是应该周期性地尝试寻找更好的路由呢?还是应该仅在当前缓存里的路由失效的情况下尝试寻找路由？
假设一个端系统S已经和目标D进行会话，随后发现一个到D的路由（或者是一个新的源路由）。在这种情况下，从S发送到D的数据包可以被乱序传递，因为在以前的源路由（或者透明的传送，因此是基于生成树的路由）上传送的数据包和在新的源路由上传送的数据包走的是不同的路由。乱序的数据包有可能会有问题，那就看你用的是什么应用系统了。假设一个路由不再工作，端系统使用L L C类型1（无连接）。有三种可能的方法来确定废弃的路由已经从缓存中删除。
1) 假设一个面向连接的运输层运行在一个端系统上，并提供运输层和维护路由缓存的进程P之间的接口。这个接口允许运输层在一个连接中断或者重联失败时告之P去删除缓存中的路由。
2) 如果在一段时间内没有收到D传来的数据，则在路由缓存中删去到D的路由。
3) 从缓存中记录这个路由开始起指定的一段时间后，不管用没有用这个到D的路由，都将其删除。
第一种可能在下面两个条件下可以实现：
. 一个面向连接的运输层在运行；
. 一个在运输层和维护路由缓存的进程间的接口。
这个策略不能发现一个存在着的更好的路由，如果信息传输是单向的，它也不会工作，因为源端永远也不可能知道它的包是否已经到达了目标端。如果路由缓存是维护在别的节点上，而不是在这个源端，则这个策略也不能工作。譬如在SR-TB网桥上，就有可能是这样的。那个设备必须代表透明扩展局域网中所有的端系统来保存源路由。因为从端系统到设备间没有协议来告诉设备一个路由失效了，所以这个设备不知道数据包到指定目标端的成功与否。第二个策略（如果不能周期性地通过回应数据包的确认，则删除路由）必须小心地使用，因为从S到D的路由也许同D到A的路由不一样。如果从D出发或到达D使用不同的路由，一个到D的路由必须假设是基于从D端发出的回应。但是，如果每当一个数据包到达时就把路由和缓存里的对比一下，会把端系统搞垮。而且，这种策略不能发现一个更好的路由。当端系统找到一个有效的路由时，不管它有多么不理想，端系统还是会使用这个路由。第三个策略（周期性地删除路由，不管用没用到它）也必须小心地使用，因为它有可能会引起端系统在会话时找到一个新的路由，从而有可能引起数据包的无序。而且要选择一个合适的时间间隔也很困难。如果间隔太短，网络会一直忙于寻找路由。如果间隔太长，一个无效的路由就会导致数据包在无法忍受的很长一段时间里陷入一个“黑洞”中。注意在第二种策略中，会使用一个相当短的时间间隔。只要会话的数据包通过一个有效的路由到达得比缓存值快，缓存里的值就不会被删，直到会话结束。

怎样发现一个路由
如果下面几种情况下查找路由的协议有所不同，需要不同的策略以便于重新尝试，就很值得使用源路由或是透明的通信。
1) 目标也许完全关闭。
2) 目标也许是开着但只能通过透明桥接。
3) 目标可以使用源路由到达，而且到达目标使用的源路由的路径比生成树要好。
4) 目标可以使用源路由到达，但到达目标使用的源路由的路径比生成树要差。
注意，因为源路由是一个可以替代透明网桥的技术而不是一个可有可无的功能，一个合理的策略是使一个端系统先尝试透明地建立连接（如果两个站点在同一局域网上，则肯定有效），如果连接失败，则尝试寻找一个源路由。当又强制转为透明桥接后，同样的策略继续工作，但它不再尝试寻找路由（除非一个目标停机或无法连接上），因为可以到达的目标将会一直透明地连接上。
1. 路由寻找策略1
源端发送一个到目标的全路径搜索包。目标接收到多个搜索包的备份，并按照收集来的路由将这些备份指定路由（将方向位置反）后作为指定路由包回馈。如果目标在缓存里已经有了一个到源端的路由，则它不储存新路由，也不修改它自己的路由缓存。这个策略允许源端来选择路由（见下图）。

这种策略有它的弊端。如果一个单一的全路径搜索包产生X个备份，这个策略则会产生2X个数据包，因为每个到达目标的全路径搜索包会产生从目的到源端的包。而且，如果源端是客户机而目标是一个拥有很多客户机的服务器，则这个服务器将会应付每个客户机发出的众多中断，而使其性能大打折扣。这种策略有可能会寻找路由失败，原因有几个：目标关机或只能通过透明包到达；全路径搜索包或者其回馈包在拥塞的网桥中丢失。源端必须选择是否用另一个全路径搜索包再一次尝试，还是通过透明包来尝试到达路由，或者放弃。
2. 路由寻找策略2
第二种策略除了源端在发送全路径搜索包之前先透明地发出一个专门的“要求路由”包，并等待一个从目的端的回应以外，和第一种策略一样。相比第一种策略，这种策略具有的好处是，它在源端发送大量加重网络负担的全路径搜索包之前先确定目的端是确实开机的状态。关于这个策略的论文作为投稿提交给802.1，后者采纳了这个使用专门包的建议，但把它留给端系统的实现者来单独地开发一个兼容的“要求路由”包。这是一个非常清楚的事例标准必须详细说明端点操作的严格细节使不同的供应商提供的端系统能够协同工作。允许每个实现者灵活地定义自己的专门包是没有作用的。
3. 路由寻找策略3
在这种策略里（见下图），源S向目标D透明地发送了一个专门的要求路由包。D以一个全路径搜索包回馈。S选择路由。

这种策略比第一种具有的好处是它只产生了一半的通信量。像第一种策略一样，它允许源端选择路由。这种策略的一个缺点就是如果要求路由包在生成树在重新生成时发送，寻找路由将会失败。它也不能区分一个目标是关机状态还是只能通过透明包到达。
4. 路由寻找策略4
第四种策略除了目的端需要用下面两个包来回馈接收到的要求路由包外，和第三种策略是一样的：
1) 一个全路径搜索包。
2) 一个透明的要求路由回应。
这个策略允许源端发现目的端可以通过非源路由的方式到达。这个策略要求目的端传送两个数据包作为对一个收到的数据包的回应。这样就需要源和目的端要同时实现兼容的要求路由应答包。
5. 路由寻找策略5
源端传送一个全路径搜索包。目的端选择一个路由并只回应一个指定了所选路由的包。源端储存收到的指定路由包中的路由。（见下图）

这种策略要求站点根据收到的特定路由包来存储路由信息。同时它也要求目的端负责选择一个路由。策略5所需的传输量是策略1的一半。

6. 路由寻找策略6
策略6是最简单的一种（我只是附带提及）。一般使用透明网桥。并不包含路由缓冲区。这种策略的优点是：简单、不断工作和无须发现整个网络的路由。缺点是：如果存在某个到特定目的端更好的源路由，源端不会尝试去发现它。但我认为，让一个站点来判断用源路由方法和用生成树算法发现路由哪个更优是不大可能的一件事。策略6的另外一个缺点是：端站点不能得到通过该路由到达目的站点的最大包大小（而源路由算法可以）。第3个缺点是：数据传输只能在生成树上进行，不能扩散到其他路径上。但是，我认为源路由算法中的这些优点，并不意味着它会增加端站点的复杂度或者增加发现路由所需的带宽。

通过目的端发现路由
前面讨论的几种策略中，并没有提及目的端是如何发现路由的。在某些方案中，目的端可以发现可能的一些路由，然后选择并保存其中一个。但是如果目的端所选择的到源端的路由跟源端选择的到目的端的路由不一样，则两个端系统都不能根据它从另一端所收到的包来确定它保存在缓冲区中的路由是否正确。或者，目的端可以等到它需要发送包给源端，换句话说，目的端可以当成源端一样按同样策略进行路由寻找。但这种方法还是会产生不对称的路由。而且它还会制造出大量的包，因为源端和目的端都需要发出全路径搜索包。另外一种可能的方法是，目的端通过接收特定的路由包来学习路由。这种方法的好处是路由对称。缺点是路由发现处理程序需要检查收到的每一个数据包。如果到端系统S的路由已经保持在缓冲区中了，而新收到一个从S发送过来的包，该包里的路由和缓冲区中的不一致，则目的端可以选择覆盖或者保留原来缓冲区中的路由。

路由选择
假定某个端站点收到多个全路径搜索包的备份，这个站点该怎么选择一条路由呢？ 802标准又一次把这个问题留给了端站点自行解决。以下列出了几种可能性：
1) 选择第一个收到的包，理论上它通过的是最快的路径。
2) 选择经过的路径上允许包尺寸最大的那个包。
3) 选择经过最少跳数的包。
4) 选择前面所述的综合。例如：从满足一定包尺寸的包中选出最早到达的那个包；或者，从在一定时间范围内到达的包中选出经过跳数最少的那个包。
5) 选择最近到达的包（注意：这是一个糟糕的主意）。

源路由与透明网桥
假定需要你对源路由网桥和透明网桥的技术优点做出评价，或者你正在决定选择一个方案来适应你自己的网络。你会用哪些条件来进行判断呢？

带宽费用
网络中的路径数是指数级的。理论上，一个全路径搜索包会在整个网络的每条路径上产生一个备份。从而，理论上，一个全路径搜索包的备份的数目就会以指数级增长。在网络的连接比较充分的情况下，指数级增长更快。基本上，每次都有一个选择（如果某个LAN上有多个网桥，或者某网桥有多个端口），包的数目等于原来的包数乘以选择的次数。最大路由长度是14个路由指定器，但实际上在一条路径中有26个可选择的点（每一个路由指定器包括一个LAN序号和一个网桥序号，这就是为什么会有路由指定器大约2倍的选择点。为什么是26个选择点，而不是28个选择点呢？这是因为第一项必须是源端的LAN序号，这是固定的项。而最后一项是网桥关于最后路由指定器的一部分，为空白）。当一个全路径搜索包在某个LAN上传输时，该LAN上的所有网桥都会收到一个备份。然后每个网桥都会向它所连接的其他端口发送一个该包的备份的备份。某单一端节点试图与另一个端节点之间开始会话将产生的包数是与每个LAN上的平均网桥数的13次方和每个网桥上的平均端口数（大于2个）的13次方的积同阶的一个数。即使目的端与源端之间只需经过2个路由就到达了，但在全路径搜索包完成它的分裂复制之前，不能终止该算法。
在我看来，任何一个端节点希望与其他端节点通信时，都会发生这种指数级的费用，这是源路由算法的一个致命的缺点。在小的简单树型拓扑结构中，网桥只有2个端口，指数级的增长费用还不会很严重。但是人们建立的透明网桥可以有几百个端口，我们简直无法想象有几百个端口的网桥会对源路由算法带来什么后果。即使一个网络中只有2个这样的网桥，全路径搜索包的增殖也会带来严重的后果。源路由网桥还会使用额外的带宽，因为它的头部比较大，但和包数量的指数级增长相比，还不算很糟糕。透明网桥也没有最优地利用带宽；它们浪费了拓扑结构的一个子集的带宽，而不是使用最优的路由，而且在缓冲区条目建立之前就开始发送不必要的包。但是它们浪费的带宽比源路由算法逊色多了。

配置难易度
透明网桥可以说是真正地即插即用。虽然有很多参数供网络管理人员在某特定情况下进行配置以调整性能，但除非有特别要求，否则不要这么做。
相对地讲，源路由算法需要为每个LAN都指定一个序号，并为每个网桥配置每个端口的LAN序号以及为它连接的每一对LAN配置一个4位的网桥序号（虽然对拓扑结构进行约束可以使网桥在它所连接的每一对LAN之间只有唯一的4位序号）。错误的配置可能导致回路，甚至严重的数据包的重复。

普遍性
源路由需要端节点的支持。从而，没有源路由算法的端节点不能让它们的包通过一个（纯源路由）源路由桥接。这些站点还可以跟本地LAN上的其他站点进行通信，但不能跟远程LAN上的任何站点之间进行通信。另一方面，透明网桥并不完全透明，特别是在连接不同类型的LAN时。如果网络管理人员规定每个端节点只能使用所有LAN上允许的最小的包，那么包的大小就不再成为问题。或者，在端系统上允许某种智能程序，选择出最佳的包大小。使用FDDI上的优先级字段来表明从源到目的端所经过的路径，该包桥接通过一个802.3LAN。虽然使用这种方法并不甚好，但它确实做到了，并且在一些FDDI的站点上配置，使得它们可以在可能时使用大包。源路由网桥处理包大小问题相当公平，因为当某条路由被发现时，该路径上的最大包尺寸也就知道了。但是，使用路由上最大包大小的信息也不是一件很容易的事情。它需要底层的源路由处理程序和运输层处理程序（由它负责决定包的大小）之间共享该信息。如果某个源路由在传输连接中发生变化，很多端站点的实现不能改变包的大小。

网桥的费用和性能
起初的时候，源路由算法声称比透明网桥算法更简单、更便宜，且性能更高。即便这是正确的，网络中的端节点数目大大地超过了网桥的数目，因而为确保性能而增加的网桥所导致的费用跟整个网络所需的费用相比是微不足道的。由于源路由算法要求更复杂的端节点，这会增加端节点的费用。当把附加的节点费用乘以节点数目时，所得的结果将大大超过增加网桥带来的费用。然而，透明网桥的实现表明，透明网桥能够在合理的价格范围内提供适当的性能。现在人们已经不再讨论透明网桥是否会更昂贵或者速度更慢。

改善源路由网桥的方法
源路由网桥有两个缺点。一个是需要对它进行配置，另一个是路由发现时所耗费的指数级费用。针对这两个问题，我提出了以下建议。即使对实现者来说这个提议已经为时过晚了，但我觉得这是一个有意义的构思。

源路由网桥的自动配置
需要配置的项是：LAN的序号和并行网桥序号（用来区别同一对LAN之间的网桥）。我们希望有某台计算机可用来负责指定这些编号。如果这台计算机关闭（go down）了，立即有新的一台来代替它。我们希望已故的序号分发者能保存所有已经被分发的序号。以下是具体的做法：
. 与序号分配者保持一致。生成树算法通过大家一致认可的某台计算机来实现。如果旧的“死亡”，则找台新的来代替它。这台计算机也就是生成树算法中的根网桥。
. 与请求LAN序号者保持一致。这一点，生成树算法也很容易就做到了。合理的选择是该LAN上的指定网桥。
. 确保网桥能够与根通信。合理的假设是，生成树算法中的配置信息内所包含的根ID是根的MAC地址。如果根因为某些原因想用其他数据作为MAC地址，则可以在生成树算法的配置信息中增加一个字段—根网桥的MAC地址。
. 通过指定网桥向根网桥请求来得到LAN的序号。请求中应该包含该网桥的ID和它的端口号。由于网桥不止连到一个LAN上，根需要为每个LAN都指定一个LAN序号，因而端口号很重要。
. 确定LAN上所有网桥都知道该LAN的序号。由于指定网桥会周期性地发送配置信息，合理的办法是在其中附加上LAN序号。注意到即便没有自动配置，增加这个字段来确保该LAN没有被错误配置（LAN上的网桥所配置的LAN序号不一致）也是很有用的。如果在配置信息内增加一个字段比较困难，可以让指定网桥在LAN上周期性地发送一个新的消息类型，用于告诉其他网桥该LAN序号。
. 根网桥负责维护一张表<ID，端口，LAN序号>。这样，即使指定网桥发生了故障或者丢失了LAN序号，LAN的序号也还能被保留下来（如果LAN的序号改变，端系统的路由缓冲区可能会发生问题）。
. 让指定网桥周期性地重新注册分配的LAN序号。这样做有两个原因：一是如果这个数字不再使用，可让它再次循环；二是确保该序号没有被分配给其他网桥（万一根网桥发生了故障，或者根网桥维护的表发生了错误，或者选择了新的根网桥而新的根网桥不知道这张表的信息）。
. 新选定的根网桥应该等重新注册的消息到来后才开始分配LAN序号。这是防止它把已指定给某LAN的序号再指定给其他的LAN。
. 让新选定的指定网桥注册原来的LAN序号，包括原来那个指定网桥的ID和端口号。由于根网桥会认为它是把这个序号分配给了原来的指定网桥，从而使得LAN可以保持它原来的LAN序号。
. 如果网桥不知道原先分配的那个LAN序号，要求根查看表，可能的话，重新分配给它原来的序号。如果指定网桥发生了故障，丢失了LAN序号，然后又重新加入生成树中，在这种情况下，根就可以记住原来分配给该指定网桥的LAN序号，重新把这个序号分配给它。
在大多数情况下，这种方案都是正确的。LAN序号可以被保持下来，即使根网桥发生了变化；或者指定网桥发生了变化，而该LAN上的所有网桥都会使用这个LAN序号，且在整个网络上，不会出现重复的LAN序号。但在下面一种情况下还是可能出错：如果LAN上本来只有一个网桥，它发生了故障，然后另外一个网桥加入了这个LAN，这时就无法判断这个LAN是否和原来的LAN相同，因而它会申请分配一个新的LAN序号。然后端节点的源路由就受到了影响。但很可能的一件事是，当LAN上没有网桥时，所有的路由都失败了，且全部被抛弃。在自动配置并行网桥序号时也可以使用同样的机制。根网桥维护一张匹配表：＜LAN，LAN序号，并行网桥序号>，指出哪个网桥ID已经被分配给一对LAN之间的并行网桥。同样，网桥需要通过周期性的重新注册来更新表的信息，并且，如果某个网桥发生了故障，或者丢失了原来的序号，它还可能重新分配到原来的那个序号。

使指数级的开销固定
我们希望数据传输经过的路由是好的路径（为了保持源路由优于透明网桥，把路由限制在生成树范围内进行）。我们也希望能找到一种解决方案，不影响那些已经使用了源路由桥接的站点。我们需要对这些网桥进行调整。例如，网桥上需要运行一个链接状态路由协议（link state routing protocol），从而它们可以计算从每个LAN到它们之间的最优路径，且解决不同的全路径搜索包。
建议如下：
. 让每个网桥计算自己到每个LAN之间的最佳路径。这可以通过链接状态算法来实现。每个链接状态包中的链接状态信息包括以下内容：产生LSP的网桥ID，网桥所链接的LAN序号，该网桥在每一对LAN之间的并行网桥序号。或者你也可以用一个内部的LAN序号来替代并行网桥序号。
. 让不同的网桥以不同方式处理全路径搜索包。当一个源端发送一个全路径搜索包时，其内部的路由会被清空。指定网桥以外的其他网桥应该忽略这些全路径搜索包，也就是说这些网桥不再转发这类包。而指定网桥则应该做如下几条：
. 创建一个新的包，叫做最佳路径发现（OPF，optimal path finder）包，包括源的MAC地址、源的LAN序号以及原来的目的MAC地址。OPF包的包头必须说明它是一个生成树搜索包（而不是全路径搜索包），且必须有一个特定的可被所有网桥处理的目的组播地址。
. 每个网桥B都将收到OPF包（一次，通过生成树算法）。除了向生成树端口转发OPF包外，对于B被设为指定网桥的每一个LAN L，B都创建一个全路径搜索包，其中包含的是从源LAN到L的最佳路径，再发送到L。对于端节点，这个包看起来就像一个普通的全路径搜索包。
注意：虽然OPF包只出现在生成树上，但B所计算的从源LAN到目的LAN的路径并不强制为生成树上的路径。它可能是链接状态路由算法所计算的最佳路径。
. 网桥如果发现了一个非空的全路径搜索包，将不再转发它。
这么做的结果是，当S发送了一个全路径搜索包后，包含了从源LAN到该LAN的好路径的单个搜索包会出现在所有LAN上。