7.4　域间多播

所有多播路由协议（也包括所有单播路由协议）都面临着扩展性问题，也就是如何有效地将数据包分发给一组主机。通过前面的学习已经知道，密集模式协议（如PIM-DM和DVMRP）的扩展性都不是很好，根据定义，这类协议假定多播域中的多数主机都是组成员。作为稀疏模式协议的PIM-SM的扩展性相对较好，因为该协议假定多播域中的大多数主机都不是组成员。不过，无论是密集模式协议还是稀疏模式协议，它们的假定条件都局限于单个多播域，也就是说，迄今为止遇到的多播路由协议都可以被认为是多播IGP。

那么在保持每个AS独立性的同时，如何让多播包穿越AS边界呢？

PIM-SM的Internet草案通过定义PMBR（PIM Multicast Border Router, PIM多播边界路由器）来解决该问题。PMBR位于PIM域的边缘，并在域中构建去往所有RP的特殊树枝（如图7-4所示），每个树枝都以一个（,,RP）表项加以表示，其中的两个通配符表示映射到该RP的所有多播源地址和多播组地址。RP从多播源接收到多播流量之后，将其转发给PMBR，再由PMBR转发到邻居域中。对非期望的多播流量来说，由邻居域向PMBR发送剪除消息，再由PMBR发送给RP。

PMBR的主要缺点在于其泛洪/剪除操作机制。事实上，PMBR主要被建议用作将PIM-SM域连接到DVMRP域，由于这种方法的扩展性较差，因而Cisco IOS软件并不支持PMBR。

由于PIM-SM是事实上的IP多播路由协议标准，因而如何在自治系统之间路由多播流量的问题就可以简化为如何在PIM-SM域之间路由多播流量。此时必须解决以下两个问题。

图7-4　PMBR与域中的每个RP都建立一个被称为（,,G）的多播树枝，RP沿着这些树枝将多播流量转发给PMBR

•　当多播源和组成员位于不同域中时，RPF进程必须保持有效；

•　为了维持独立性，一个域不能依赖于另一个域中的RP。

PIM-SM是与协议无关的，因而第一个问题看起来非常容易解决，就像PIM使用单播IGP路由来确定域内的RPF接口一样，此时可以使用BGP路由来确定去往其他自治系统中的多播源的RPF接口。不过在域间传送多播流量时，可能会希望使用与单播流量不同的链路（如图7-5所示），如果多播包到达链路A，BGP显示去往该多播包的源的单播路由是通过链路B，那么RPF检查将失败。虽然静态多播路由可以解决该问题，但很明显不适合大规模应用，因而必须对BGP进行扩展，让BGP路由指示被宣告的前缀是用于单播路由，还是多播RPF检查，或者是两者。

图7-5　AS间流量工程需求可能要求多播流量与单播流量使用不同的链路

碰巧PIM可以利用现有的BGP扩展协议，该扩展后的BGP版本被称为MBGP（Multiprotcol BGP，多协议BGP），有关描述请参见RFC 2283。虽然该BGP扩展的目的是让BGP携带IPv6和IPX等协议的可达性信息，但是也可以让MBGP宣告多播源，因而有时也会不准确地将MBGP中的“M”理解为“多播（Multicast）”而不是“多协议（Multiprotcol）。

MBGP的最常见应用是在同意交换多播流量的服务提供商的NAP中构建对等连接，如图7-6所示，虽然各自治系统可以按图中所示建立单播流量的对等连接，但多播流量必须共享同一个对等点。由于某些前缀可能会同时通过单播和多播NAP进行宣告，因而必须利用MBGP来区分多播RPF路径与单播路径。

注意：　图7-6中所示的多播NAP常常是某些非交换介质，如FDDI。

第二个AS间PIM问题（为了维持独立性，一个域不能依赖于另一个域中的RP）的主要原因是AS不希望依赖于其不能控制的RP。但是如果每个AS都放置自己的RP，那么就必须有相应的协议让不同AS内的每个RP都能与其他RP共享多播源信息（穿越AS边界）并发现其他RP所知道的多播源（如图7-7所示），该协议就是MSDP³（Multicast Source Discovery Protocol，多播源发现协议）。

以下各小节将详细介绍MBGP扩展及MSDP的相关操作。

图7-6　当需要为多播和单播提供不同的对等点时就可以使用MBGP

图7-7　在RP之间运行MSDP之后就可以让每个RP都能发现其他RP所知道的多播源

7.4.1　MBGP

RFC 2283中定义了以下两种新属性，从而将BGP扩展为支持多协议。

•　MP_REACH_NLRI（Multiprotocol Reachable NLRI，多协议可达NLRI），类型14；

•　MP_UNREACH_NLRI（Multiprotocol Unreachable NLRI，多协议不可达NLRI），类型15。

注意：　有关BGP属性类型代码的详细列表请见第2章的表2-7。

这两个属性都是可选非传递性属性。第2章中曾经提到，可选非传递性属性意味着BGP发言者并不需要支持该属性，不支持该属性的BGP发言者不会将它们传递给其对等体。

MP_REACH_NLRI属性用于宣告可行路由，而MP_UNREACH_NLRI用于撤销可行路由，包含在这些属性中的NLRI（Network Layer Reachability Information，网络层可达性信息）是与协议相关的目的地信息，当MBGP用于IP多播时，NLRI总是一个描述一个或多个多播源的IPv4前缀。需要记住的是，PIM路由器并不使用该信息进行包转发，而仅仅用来决定去往某特定多播源的RPF接口。通过这两个新属性，就可以告知BGP对等体某特定前缀是否仅用于单播路由、多播RPF或用于两者。

MP_REACH_NLRI包含一个或多个（地址族信息，下一跳信息，NLRI）三元组，MP_UNREACH_NLRI则包含一个或多个（地址族信息，不可行路由长度，被撤销的路由）三元组。

注意：　MP_REACH_NLRI的完整格式比较复杂，某些字段也与IP多播无关，要想详细了解相关内容请参见RFC 2283。

地址族信息（Address Family Information）包括一个AFI（Address Family Identifier，地址族标识符）和一个Sub-AFI（Subsequent AFI，次AIF）。IPv4的AFI为1，因而对IP多播来说AFI总是被设置为1。Sub-AFI描述的是NLRI是否仅用于单播路由、仅用于多播RPF信息或用于两者（如表7-3所示）。

7.4.2　MSDP的操作

顾名思义，MSDP的作用是发现其他PIM域中的多播源。运行MSDP的好处是本域中的RP可以与其他域中的RP相互交换多播源信息，本域中的组成员则无需直接依赖于其他域中的RP。

注意：　在随后的案例研究中读者将可以了解到为何MSDP对单个域中的多播源信息共享也非常有用。

MSDP使用TCP（端口639）作为其对等连接，与BGP一样，MSDP使用点到点TCP对等连接就意味着必须显式配置每个对等体。如图7-8所示，当PIM DR将某个多播源注册到其RP时，该RP将向其所有的MSDP对等体发送一条SA（Source Active，源有效）消息。

SA消息中包含以下信息。

•　多播源地址。

•　多播组（多播源正向该多播组发送多播包）地址。

•　发信RP的IP地址。

每个收到该SA的MSDP对等体都将该SA泛洪到其对等体（发信路由器的下游邻居）。在某些情况下（如图7-8中AS 6和AS 7的RP），一个RP可能会从多个MSDP对等体接收到同一份SA拷贝，为了防止出现环路现象，RP会检查BGP下一跳数据库以确定去往SA发信路由器的下一跳。如果同时配置了MBGP和单播BGP，那么会首先检查MBGP，之后再检查单播BGP；如果下一跳邻居是该发信路由器的RPF对等体，而且不是在去往RPF对等体的接口上接收到该发信路由器发出的SA消息，那么就丢弃该SA消息。因而将SA泛洪称为对等体RPF泛洪（peer RPF flooding），由于存在对等体RPF泛洪机制，BGP或MBGP必须与MSDP同时运行。

RP接收到SA后，通过查看该多播组的（*,G）出站接口列表中是否有接口来确定其域中是否有该SA的多播组的成员。如果没有组成员，RP就不做任何操作；如果有组成员，则RP将向该多播源发送一条（S,G）加入消息，从而建立起一个穿越AS边界去往RP的该多播源树的树枝。当多播包到达RP之后，就会沿着自己的共享树被转发到该RP所在域的组成员，之后这些组成员的DR就可以利用标准的PIM-SM进程选择加入去往该多播源的RPT树。

图7-8　RP通过SA消息向其MSDP邻居宣告多播源

只要多播源一直向多播组发送多播包，发信RP就会一直以60秒为周期发送（S,G）的SA消息，其他RP接收到SA消息后可以选择缓存该消息。例如，假设某RP从发信RP 10.5.4.3接收到一条关于（172.16.5.4,228.1.2.3）的SA消息，该RP查看其多播路由表之后发现没有多播组228.1.2.3的有效组成员，那么该RP将不再缓存该SA消息，而是将其传送给其对等体（10.5.4.3的下游邻居）。之后，如果该域中的某台主机向该RP发送了一条加入多播组228.1.2.3的请求消息，那么该RP会将去往该主机的接口加入其（*.228.1.2.3）表项的出站接口列表中。但由于没有缓存之前的SA消息，该RP并不知道该多播源，所以在RP向多播源发起加入消息之前必须等待接收下一条SA。

另一方面，如果RP缓存了SA消息，那么该路由器就有了（172.16.5.4,228.1.2.3）表项，从而可以在主机提出加入请求时即可加入该多播源的多播树。这里就有一个折衷问题，一方面是降低加入等待时间，另一方面是缓存可能需要也可能不需要的SA而耗费的内存资源。如果RP属于某个大型MSDP网状网，并且有大量的SA消息，那么应该将内存消耗摆在重点考虑之列。

在默认情况下，Cisco IOS软件不缓存SA，可以使用命令ip msdp cache-sa-state来启用SA的缓存功能，为了减轻可能的内存压力，可以考虑将该命令连接到一个访问列表，指定缓存某些特定（S,G）对的SA消息。

如果某RP有一个正在缓存SA的MSDP对等体，那么通过SA Request（SA请求）和SA Response（SA响应）消息，该RP在不开启SA缓存功能的情况下也能降低加入等待时间。当主机请求加入某多播组之后，该RP会向其缓存对等体发送一条SA Request消息，如果该对等体缓存了该多播组的源信息，那么就在SA Response消息中将该多播源信息发送给该请求RP，该请求RP只是使用SA Response消息中的信息，而不会将该信息转发给其他对等体。如果非缓存RP接收到SA Request消息，则向请求RP发送一条差错消息。

如果希望Cisco路由器能发送SA Request消息，则需要使用命令ip msdp sa-request来指定缓存对等体的IP地址或名字；如果需要指定多个缓存对等体，那么就需要多次使用该命令。

7.4.3　MSDP消息格式

MSDP消息携带于TCP报文段中。两台路由器被配置为MSDP对等体之后，IP地址较大的路由器将侦听TCP端口639，而IP地址较小的路由器则试图主动连接到端口639。

MSDP消息使用TLV（类型/长度/值）格式，一共有5种类型（如表7-4所示），下面将详细描述每种类型的MSDP消息。

1. SA TLV

MSDP RP从IP多播源接收到一条PIM Register（注册）消息之后，会向其对等体发送一条SA消息（图7-9显示了MSDP SA消息的TLV格式），之后每隔60秒就发送一条SA消息，直至多播源不再有效。单条SA消息可以同时宣告多个（S,G）表项。

图7-9　MSDP SA TLV格式

MSDP SA TLV格式的字段定义如下。

•　表项数量（Entry Count）：指定由给定RP地址所宣告的（S,G）表项的数量。

•　RP地址（RP Address）：发信RP的IP地址。

•　保留（Resvered）：被设置为全0。

•　源前缀长度（Sprefix Length）：指定相关联的多播源地址的前缀长度，该长度始终为32。

•　组地址（Group Address）：多播IP地址（相关联的多播源向该多播组发送多播包）。

•　源地址（Source Address）：有效源的IP地址。

1. SA Request TLV

SA Request消息（其格式如图7-10所示）用于向正在缓存SA状态的MSDP对等体请求（S,G）消息，应该仅向缓存对等体发送SA Request消息（非缓存对等体接收到该消息后会返回一条差错通告），并且只能由显式配置的RP发送该消息。

图7-10　MSDP SA Request TLV格式

MSDP SA Request TLV格式的字段定义如下。

•　组前缀长度（Gprefix Length）：指定多播组地址前缀的长度。

•　组地址前缀（Group Address Prefix）：指定多播组地址（该多播组的源信息需要被请求）。

1. SA Response TLV

SA Response消息（其格式如图7-11所示）由缓存对等体发送，它作为SA Request消息的响应消息，向请求对等体提供多播源地址以及与指定组地址相关联的RP地址，其格式与SA消息相同。

图7-11　MSDP SA Response TLV格式

1. Keepalive TLV

图7-12　MSDP Keepalive TLV格式

MSDP连接的主动方（即IP地址较小的对等体）会以一个75秒Keepalive定时器来跟踪MSDP连接的被动方。如果Keepalive定时器到期时仍未从被动方收到MSDP消息，那么主动对等体会重置TCP连接，如果接收到MSDP消息，则重置Keepalive定时器。如果被动对等体没有其他消息需要发送，则发送Keepalive消息，以免主动对等体重置TCP连接。如图7-12所示，Keepalive消息是一个只包含类型和长度字段的24bit TLV。

1. Notification TLV

检测到差错之后路由器会发送Notification消息，图7-13显示了Notification消息的格式。

图7-13　MSDP Notification TLV格式

MSDP Notification TLV格式的字段定义如下。

•　长度=x+5：TLV的长度。其中，x是数据字段的长度，5是前5个8位组。

•　O：打开比特（open bit）。如果该比特被清除，则接收到Notification消息之后就必须关闭该连接。表7-5列出了不同差错子代码的O比特情况。MC表示必须关闭（must close）,O比特始终被清除。CC表示可以关闭（can close）,O比特可以被清除。

•　差错代码（Error Code）：一个表示Notification类型的7比特无符号整数，表7-5列出了差错代码的情况。

•　差错子代码（Error Subcode）：一个提供更详细差错代码信息的8比特无符号整数，如果某差错代码无子代码，则该字段为0。表7-5列出了与差错代码相关联的各种可能的差错子代码。

•　数据（Data）：一个包含了与差错代码和差错子代码相关信息的可变长字段。本章没有完全介绍该数据字段，有关该字段的详细信息可参见MSDP Internet草案。