组播MSDP-原理介绍+报文分析+配置示例-RFC3618

本文详细介绍了MSDP(MulticastSourceDiscoveryProtocol)协议,它是用于PIM-SM环境下的组播源发现机制。内容涵盖MSDP的基本概念,如源RP、SA-cache,以及重要的程序定时器。此外,还讨论了PIM-SM的工作原理和MSDP如何防止环路与次优路径。通过理解报文结构和MSDP的状态机,读者可以更好地掌握组播网络的跨域通信机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

个人认为,理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息,更加便于理解协议。

在这里插入图片描述常用组播协议架构图。

因此本文将在MSDP协议(Multicast Source Discovery Protocol,组播源发现协议)RFC文档及报文的基础上进行介绍,以详细介绍组播协议MSDP。

其他相关资料

这里需要说明的是MSDP的使用条件是PIM-SM环境下,而PIM-SM一般又是基于ASM模型的。下文将对其进行介绍。
RFC3618文档本身只有19页,也推荐大家去阅读原文。

目录

1.组播基础内容

1.1.组播IP

传统网络进行地址分配时,将IPv4网络分为5类

A类:1.0.0.0 - 126.0.0.0
B类:128.0.0.0 - 191.254.0.0
C类:192.0.0.0 - 223.255.255.0
D类:224.0.0.0 - 239.255.255.255

2进制的前4个bit固定为1110:
Note:224(十进制)=1110 0000(2进制);239(十进制)=1110 1111(2进制)

E类:240.0.0.0-239.255.255.255,保留地址

其中 D 类地址称为组播 IP。虽然目前 CIDR(Classless Inter-Domain Routing,无类域间路由) 和 VLSM(Variable Length Subnet Mask,可变长子网掩码) 的出现淡化了 IP 分类,但组播 IP 范围并未发生变化。

其中组播IP又可进行如下划分
224.0.0.0-224.0.0.255:预留永久组播地址,通常为协议所使用。

224.0.1.0-231.255.255.255 和 233.0.0.0-238.255.255.255:ASM(Any Source Multicast) 模型使用。

232.0.0.0-232.255.255.255:SSM(Source-Specific Multicast) 模型使用。

239.0.0.0-239.255.255.255:本地管理组地址,也即私网组播IP。

需要说明的是,上述仅是 IPv4 组播地址的一个大致分类。其中还包含了保留组播地址、网络间控制组播地址等。感兴趣者可查阅相关资料。

常用协议组播地址

组播地址使用者
224.0.0.1所有主机及路由器监听地址
224.0.0.2所有路由器监听地址
224.0.0.4DVMRP协议使用
224.0.0.5
224.0.0.6
OSPFv2协议使用
224.0.0.9RIPv2协议使用
224.0.0.12DHCP协议特定场景使用
224.0.0.13PIM协议使用
224.0.0.14RSVP协议特定场景使用
224.0.0.18VRRPv2协议使用
224.0.0.22IGMPv3协议使用
224.0.0.251mDNS协议使用
224.0.0.252Link-local Multicast Name Resolution协议使用

关于其他 IPv4 组播地址的使用,感兴趣者可查阅 IANA 发布的《IPv4 Multicast Address Space Registry》等相关资料。

1.2.组播MAC

通常的 MAC 地址为 48bits,6 字节。
1@:第一个字节的最后 1 个 bit = 1,表明该MAC为组播MAC,否则为单播MAC。
2@:MAC 地址的前三个字节 24bits 称为 OUI (Organizationally unique identifier,厂商标识),需要向 IEEE 购买分配。后 24bits,由厂家自行分配。
3@:组播 MAC 由于没有明确的目的主机,因此规定 组播MAC由组播IP映射 而来。

映射规则如下
1@:IPv4 Multicast MAC 的高 24 bit = 01‑00‑5E,已分配给 IANA 规划使用。
2@:IPv4 Multicast MAC 的后 23 bit 由组播 IPv4 的后 23bit 直接映射而来。也即实际取值为 01‑00‑5E‑00‑00‑00 至 01‑00‑5E‑7F‑FF‑FF。
3@:IPv4 Multicast MAC 的第 25 位 bit 固定为0。
4@:组播 IPv4 实际上有 32 - 4 = 28bits (固定前缀 1110),因此存在 5bits 数据无法进行对应。
因此实际上每 2^5 = 32 个组播 IPv4 对应一个组播 MAC。在这里插入图片描述而且由于错配的 bit 位是高 bit 位的 IP,所以通常对应同一个组播 MAC 的 32 个 IP 是不连续的。需要进行 2 进制转换。
例如:224.1.0.1、224.129.0.1、225.1.0.1、225.129.0.1、226.1.0.1、226.129.0.1、…、239.1.0.1、239.129.0.1 具有相同的组播 MAC = 01-00-5e-01-00-01。
关于 IANA 分配使用的其他 MAC 情况,可查看《IANA OUI Ethernet Numbers》等相关资料。
自动换行
IPv6 的组播 IP 和组播 MAC,情况稍有变化:
IPv6 组播 MAC 地址的高16位为 0x3333,低 32 位为 IPv6 组播地址的低 32 位。常用的 IPv6 组播地址为 ff00::/8。感兴趣者可查阅 IANA 发布的《IPv6 Multicast Address Space Registry》等相关资料。

4@:此外还有协议规定组播 MAC。
例如,某些协议组播 MAC 以 01-80-C2 开头:01-80-C2-00-00-00 用于 STP BPDU,01-80-C2-00-00-14 和 01-80-C2-00-00-15 用于集成 ISIS 等。

点击此处回到目录

2.MSDP简介

2.1.MSDP背景介绍

MSDP 协议(Multicast Source Discovery Protocol,组播源发现协议) 主要是用于在组播跨域场景下进行使用。

在正式介绍 MSDP 协议前,有必要进行相关内容的铺垫说明。
1@MSDP 的跨域
在工程应用上,势必上要存在多个 PIM-SM 网络。而每个 PIM-SM 网络却并不一定都有组播源。
而 MSDP 的作用在于建立 MSDP 对等体去通告/发现整个大网中组播源的存在,而直接与组播源建立联系。这就是组播源发现。

2@MSDP的PIM-SM场景
MSDP 仅适用于 PIM-SM 环境下,这是由于 PIM-DM 的特性所导致的。
@:PIM 协议作为协议无关组播路由,只需依照单播表并进行相应的 RPF 检查即可。
@:并且PIM-DM 是 PUSH 推流方式,只要有 PIM 邻居存在就可推送组播流。这种方式默认认为网络中所有 PIM 邻居都有接收者存在,会 PUSH 组播流。因此即使跨域,只要域间可以建立 PIM 邻居就可推流。

关于PIM-SM环境相关内容,可参考博客组播PIM-原理介绍+报文分析+配置示例

@:相反PIM-SM 是 PULL 拉流方式。组播源/第一跳PIM组播路由器需要知晓网络中 RP 的存在,以单播方式去主动通知 RP。RP 反向向组播源拉流进行 (S,G) 表项建立。
其中的关键在于组播源/第一跳PIM组播路由器需要知晓网络中RP的存在。而跨域场景下,这是很难做到的。

2.2.MSDP相关概念

@源RP
源 RP(originating RP) 通常指的是逻辑上距离组播源最近的 RP,并承担着向其他域发送 Source-Active 组播源消息的责任。此时建立的 MSDP 对等体,也称源MSDP对等体

与 “源MSDP对等体” 相近的概念的还有接收端MSDP对等体中间MSDP对等体。其实分别指的就是承担接收者作用的MSDP和传输MSDP Source-Active消息的MSDP对等体。

@Source-Active 组播源状态消息:当 PIM-SM 域的 RP首次知晓组播源的存在时,将构建 MSDP Source-Active 组播源状态消息,并将其发送给 MSDP peer。

所有发起/接收 Source-Active 消息的 RP 都必须直接或通过中间 MSDP 对等体与其他 RP 建立 MSDP 对等关系。

Source-Active 组播源状态消息应当包含:组播源,组播组和(源)RP。

@SA-cache
SA-cache 也即 Source-Active 缓存,主要用于降低新对等体邻居接入组播的等待时延网络分析/故障定位减少协议网络风暴等。
MSDP Speaker 必须缓存 SA 消息。

在这里插入图片描述cache-sa-enable 开启SA-cache功能。默认开启。

@MRIB:对于 MSDP 环境下,势必可能有多个 PIM-SM 域。这就会导致组播环路和次优路径。因此针对这种情况,MSDP 定义了 MRIB(Multicast RPF Routing Information Base,组播RPF路由信息基础) 的相关概念。这是一张通过单播路由表或其他路由协议形成的组播拓扑表。

当收到指向源 RP 的 Source-Active 组播源状态消息时,记录收到的该 MSDP Peer。RP 将其与 MRIB 进行比较,将丢弃 non-RPF 对等体发送的 Source-Active 组播源状态消息。

RPF(Reverse Path Forwarding,逆向路径转发) 指的是,组播路由器接收到组播流量时进行检查。
这一过程是指:

  • 首先,记录收到组播流量的端口(上游端口)和组播流量的源地址。
  • 随后,检查到达发送该组播流量的组播源的路由表(单播路由表)。如果路由转发表中记录到达该组播源的端口为接收该组播流量的端口时,允许接收该流量。

这里的RPF规则可与MRIB表结合理解。

@MSDP的flood-and-join过程

  • MSDP 仅接受来自 RPF-peer 的指向始发 RP 的 Source-Active 组播源状态消息。 并随后将该消息转发到其他所有的 MSDP 对等体。

  • 当 MSDP 对等体收到新的 Source-Active 组播源状态消息时,它会确定自身 PIM-SM 域中是否有任何组成员对Source-Active 组播源状态消息中携带的组播信息条目感兴趣。
    在这种情况下,RP 会触发指向组播源的 (S,G) 的加组消息,并形成 RP 到组播源 (S,G) 表项的 SPT 源路径树。后续组播数据包通过此树分支到达 RP,并沿域内的 RPT 共享路径树向下转发。这一过程与 PIM-SM 的加组过程相同。

  • 如果任何 RP 对 Source-Active 组播源状态消息携带的组播组条目不感兴趣,他们可以忽略 SA 消息。 否则,它们将加入组播分发树。

MSDP 对等体通常也是其自身 PIM-SM 域的 RP。

@Intermediate MSDP Peers:中间媒介作用的MSDP对等体。

  • Intermediate MSDP Peers 不为其他PIM-SM域创建 Source-Active 消息,可以转发来自其他PIM-SM域创建的 Source-Active 消息。
  • 一般来说 RP 只为自己注册的组播源产生 Source-Active 消息。

@SA Filtering and Policy:描述对 Source-Active 消息的筛选过滤原则。

  • 在传输作用的PIM-SM域中传递 Source-Active 消息时,不能过滤。
  • 过滤原则可以使用 MBGP 进行控制。
  • 描述 (S,G) 组播消息的 Source-Active,不能传出该G组播组的边界。

在这里插入图片描述import-source 用来在MSDP创建Source Active消息时,限制本域内被通告的活动源信息。acl用于指定组播数据包的源目的IP。

@Encapsulated Data Packets
RP可以封装来自源的组播数据。这允许在向源的域构建组播树之前接收小突发组播流量。一般来说该数据封装于 Source-Active 消息中。具体的封装则需要进行深究。

在这里插入图片描述encap-data-enable 可用于在Source Active消息中封装组播数据报文。

2.2.1.MSDP的基本原理

@:借用 TCP 协议 639 端口完成验证加密,协议可靠和协议保活。

在这里插入图片描述//使用639在TCP的三次握手阶段进行认证,TCP认证通过才可以建立MSDP会话。

@:网络中 RP(这里肯定指的是逻辑上最靠近组播源的RP) 之间建立 MSDP 对等体。因为对于 PIM-SM 来说,需要每个 PIM 域的 RP 向组播源进行注册拉流建立 (S,G) 表项。

最少需要每个PIM-SM域的RP去进行组播源信息的交互。其他则不强制要求。
每个PIM-SM域的RP逻辑上可以认为是每个接收者的组播源。因此MSDP对RP的对等体要求实际上是有好处的。

@:网络中的 RP 接收 MSDP 消息,决定是否接收相应组播源的数据,并向其他 MSDP-peer 发送。

flood-and-join过程
SDP的 Source-Active 报文中携带(S,G)消息以及创建该 Source-Active 消息的源RP地址,其他域的RP接收到 Source-Active 消息后进行决定 Source-Active 有效性和是否转发。
RP接收到有效的RP消息后,会主动向G的S进行PIM-SM的拉流操作发送PIM-SM的join 报文。

点击此处回到目录

2.2.2.Peer-RPF转发

MSDP 的 Peer-RPF Forwarding 概念比较重要,在此重点进行说明。如果发现 Source-Active 消息是从RPF对等体发出的,则接收该 Source-Active 消息并向其他对等体转发。否则丢弃。
类似于PIM协议中的RPF检查。
Peer-RPF转发的基本原理
主要用于在使能了MSDP网络上转发 Source-Active 消息的原则。这一原则的作用类似于BGP的路由防环。
具体来说是指将Source-Active 消息中携带的RP信息接收该SA消息时的MSDP对等体进行比较,并给出如下原则:
1@:Multicast RPF Routing Information Base (MRIB)是组播拓扑表。MRIB可以由MBGP、组播静态路由、单播路由形成。
2@:Peer-RPF Route 是 MRIB 为 Source-Active 消息中源 RP 的最佳路由下一跳。Source-Active 发起 RP 的 Peer-RPF Route 用于选择接受 Source-Active 的对等体。
具体来说有如下SA的RPF检查规则
1@:收到发送 Source-Active 的 MSDP 对等体邻居是该 Source-Active 消息中 RP 的地址;
2@:从静态 RPF 对等体到来的 Source-Active 消息;

在这里插入图片描述static-rpf-peer用于指定静态的RPF MSDP peer。对于静态的RPF MSDP peer不进行Source-Active消息的RPF检查。事先要有MSDP对等体才可将该对等体配置为静态RPF对等体。

3@:只拥有一个远端 MSDP 对等体;
4@:来自 Mesh Group 对等体的 Source-Active 消息不再向属于该 Mesh Group 的成员转发,但向该 Mesh Group 之外的所有对等体转发。
5@:到达源RP的 MRIB 需要跨越多个 AS 时,接收从下一跳 AS 中的对等体发出的 Source-Active 消息。此时如果该 AS 中存在多个远端 MSDP 对等体,则优选 IP 地址最高的对等体发来的 Source-Active 消息。

2.3.MSDP的Mesh Group和Any-cast RP

mesh Group
当网络中存在多个MSDP对等体时,可能存在 Source-Active 的大量无效泛洪,因此 MSDP 定义了 RP 之间全互联的 Mesh Group 的概念。

  1. 接收到一个 Source-Active 消息时,如果该 Source-Active 消息来自 Mesh Group 内部成员,则不进行RPF检查,直接接收。同时也不再向Mesh Group内其他成员转发。
  2. 如果该 Source-Active 消息来自 Mesh Group 外部成员,则对该 Source-Active 消息进行 RPF 检查。如果检查通过,向 Mesh Group 内其他所有成员转发。

Mesh Group:属于同一个Mesh Group的所有成员之间必须两两建立MSDP对等体连接。在这里插入图片描述peer mesh-group 命令用来将一个MSDP对等体加入全互联组。
//需要说明的是Mesh-Group是一个本地概念,并且需要先于该对等体建立MSDP连接。

Any-cast RP
Any-cast RP 主要用于实现同一个 PIM-SM 域的 RP 冗余机制并可加快 RP 的收敛。
即在同一个 PIM-SM 域内设置多个具有相同地址的 RP,并且在这些 RP 之间建立 MSDP 对等体关系,从而实现 RP 路径最优及负载分担。

Any-cast RP的原理:
1@:组播源向距离最近的RP进行注册,建立路径最优的SPT;接收者向距离最近的RP发起加入,建立路径最优的RPT。

通常通过单播路由的cost最小来实现距离最近。

2@:每个 RP 上只需维护 PIM-SM 域内的部分源/组信息。其他PIM组播路由器都指向距离自己最近的 RP。
3@:当某 RP 失效后,原先在该 RP 上注册或加入的组播源或接收者会自动选择就近的 RP 进行注册或加入操作。

需要说明的是
@:Any-cast RP是一个逻辑概念,需要事先进行网络规划。是在配置上没有明确体现的。
@:当设备对收到的 Source-Active 消息进行RPF检查时,如果发现对端RP的地址与本地RP的地址相同,就会丢弃该 Source-Active 消息。必须为 Source-Active 消息指定一个与实际RP的地址不同的逻辑RP地址(即逻辑接口上的RP地址),以通过RPF检查。
而在PIM下指定额外相同的C-RP地址。也即此时两台Any-cast RP至少需要两个Loopack,一个作为BSR,一个作为RP。并且BSR不同,但RP相同。
因此必须手动另外指定RP地址。如下命令在Any-cast RP场景下必须配置:
自动换行在这里插入图片描述originating-rp 用于 RP 在形成 Source-Active 消息时指定接口地址。

点击此处回到目录

3.MSDP协议基本原理

3.1.报文简介

整个MSDP协议都以TLV方式进行编码,
Type:类型,8bits。
Length:长度,16bits。MSDP整个字段的长度,单位字节。
Value:值,可变长。

常用的格式:
Type=1:IPv4 Source-Activet,传递 Source-Active 消息和组播消息。
Type=2:IPv4 Source-Active Request,主动请求指定组G的(S,G)列表。
Type=3:IPv4 Source-Active Response,对Source-Active Request消息的响应。
Type=4:KeepAlive,保持MSDP对等体的连接关系。只在对等体之间无其他协议报文交互时才发送。
Type=5:Reserved (Previously: Notification)。
Type=6:MSDP traceroute in progress,对 Source-Active 消息的RPF传递路径进行检测。
Type=7:MSDP traceroute reply,对 Source-Active 消息的RPF传递路径进行检测。
6和7类型MSDP报文暂不进行介绍。

Type=1:IPv4 Source-Activet
在这里插入图片描述Type:1字节,固定为 1。
Length:2字节,整个MSDP字段的长度。(不包含IP/TCP等头部信息的长度。)

Legnth = X + Y = 8 + 12*Entry Count的字节数。
X 固定为8。
如果Y为 0,则表示没有封装 Entry。Y 是封装的 IP 数据包标头中 total length 字段的值。如果 Source-Active 消息中有多个(S,G)条目,则只有最后一个条目可能具有封装数据,并且它必须在封装的 IP 数据包的报头中反映源地址和目标地址。

Entry Count:1字节,(S,G)消息数量。
RP Address:4字节,产生该MSDP-Source-Active 消息的源端RP。

Reserved:3字节,保留字段必须至0。
(S,G) Block:(S,G)的具体条目信息,12字节。
Sprefix Len:1字节,源地址相关的路由前缀长度且必须置为32。
Group Address:4字节,组地址。
Source Address:4字节,源地址。

在这里插入图片描述MSDP IPv4 Source-Active TLV报文示例。

Type=4:KeepAlive
在这里插入图片描述固定为两部分组成:
Type:1字节,固定为 4。
Length:2字节,报文字段的长度固定为3。

在这里插入图片描述MSDP KeepAlive TLV报文示例。Keepalive报文不需包含实际的Value值,因此报文是固定的。

3.2.MSDP的程序定时器

2003 年发布的《RFC3618-Multicast Source Discovery Protocol的5.Timers》中定义了 6 种协议定时器,在此处进行简单介绍:
1@SA-Advertisement-Timer:MSDP的 Source-Active 报文通告间隔定时器。
1@:只要组播源仍在发送数据吗,RP 必须周期性泛洪 Source-Active 消息,以通告组播源的存在。同时可用于其他 SA-Cache 的保活。当配置了 MSDP 进程时,RP 就启动该定时器。
2@:Source-Active 消息应一次涵盖了 RP 所有知晓的可用组播源。//超出包大小限制的原因除外。
3@: SA-Advertisement 周期必须为 60s。但源 RP 应在首次创建 (S,G) 后立即触发 SA 消息的传输。

2@SA Cache Timeout:SA缓存超时
也称 SA-State Timer/SA状态定时器。
1@:MSDP 对等体上收到 Source-Active 消息后启动,本地用于记录组播信息 (S,G) 等。Source-Active 消息中的每个组播信息 (S,G) 等条目,都与该定时器关联。
2@:(S,G) SA-State Timer 到期前收到 (S,G) Source-Active 消息,则刷新定时器。
3@:该定时器必须不小于SA-Advertisement-Period+SA-Hold-Down-Period

在这里插入图片描述sa-cache-holdtime 用来配置SA缓存的生存期。默认360s。

4@Peer Hold Timer
对等体维护定时器。
1@:用于维护 MSDP 对等体关系。对等体建立时启动定时器,关系结束时删除。
2@:收到任意 MSDP 报文时刷新。
3@:RFC给出了规定值。必须不小于3S,推荐使用75s。

在这里插入图片描述peer hold-time-interval用于配置MSDP peer表项的生存期。默认90秒。

5@KeepAlive Timer
保活定时器。
1@:用于维护 MSDP 对等体关系。对等体建立时启动该定时器,关系结束时删除。
2@:倒数为 0 时发送 MSDP Keepalive 消息,并重置定时器。
3@:RFC给出了规定值。必须不小于1S且必须小于Peer Hold Timer,推荐使用 60s。

在这里插入图片描述peer keepalive-interval 用于指定MSDP peer保活消息的发送周期。默认60s。

6@ConnectRetry Timer
连接重传定时器。
1@:具有更小 IP 的 MSDP 对等体的状态机从INACTIVECONNECTING状态转变时启动。转变为ESTABLISHED状态时或无对等体时删除。
2@:RFC给出了规定值。应该等于30S。每个对等体关系都单独指定该定时器。

在这里插入图片描述timer retry用来配置MSDP peer的连接请求重试周期。默认30s。

3.3.MSDP状态机

MSDP 协议使用 TCP 作为传输层协议,Port 使用 639。具有更小 IP 的一端作为 MSDP 建立 TCP 会话的发起者,更大IP的一端作为 MSDP 的监听者。

如果两端同时发起TCP会话则也只保留 IP 更大的一端发起的会话。

MSDP的状态机主要有以下几种:DisableInactiveConnectingListenEstablish
其状态机切换如下图所示:
在这里插入图片描述在该图中,所对应的事件Event和动作Action为:
Event
E1:发起与对等体P的建立连接请求
E2:自身IP小于对等体P
E3:自身IP大于对等体P
E4:TCP会话建立完成(Active端)
E5:TCP会话建立完成(Passive端)
E6:重传定时器触发
E7:与对等体P的关系撤销
E8:Hold 维护定时器触发
E9:探测到MSDP报文格式错误
E10:探测到其他错误
Action
A1:为MSDP分配程序资源
A2:TCP的Active端启动重传定时器
A3:TCP的Passive端进入监听状态
A4:删除重传定时器,发送Keepalive报文,启动Keepalive保活定时器和Hold维护定时器
A5:发送Keepalive报文,启动Keepalive保活定时器和Hold维护定时器
A6:不在尝试建立TCP的Active主动端连接,回收为MSDP分配的资源
A7:不在尝试建立TCP的Passive被动端连接,回收为MSDP分配的资源
A8:关闭TCP连接,回收为MSDP分配的资源
A9:丢弃数据包。
在MSDP程序上除以上说明外,还有两种特殊的事件需要进行说明
特殊对等体事件:该事件发生于Established状态,并且不造成状态机的改变;
独立的对等体事件
@:Source-Active 通告定时器触发—>发送 Source-Active 报文(周期性的),并重置Keepalive定时器
@:监听到新的活跃组播源S信息—>发送 Source-Active 报文,并重置Keepalive定时器
@:Source-Active 状态定时器触发—>特定事件,一般处理动作是删除SA-Cache缓存

点击此处回到目录

4.配置实例

在这里插入图片描述这里只提供了AR2和AR3设备的关键配置,有能力者可自行进行其他P和PE设备的配置。有需要者可私信联系提供模拟器源文件及配置。

sysname AR2
pim
 c-bsr LoopBack1
 c-rp LoopBack1
#
msdp
 peer 4.4.4.4 connect-interface LoopBack1
#
//指定建立MSDP对等体。其他底层配置略。

拓扑本身比较简单,这里简单说明下MP-BGP传递组播路由的情况
这里利用 MP-BGP 建立了 Multicast 路由关系,传递了 MPBGP 组播路由。

在这里插入图片描述BGP传递组播路由示例。

常用检查命令
在这里插入图片描述display msdp用于查看常用的msdp查询命令。

更新

点击此处回到目录

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Key Words to Reflect Requirements. . . . . . . . . . . . . . . 3 3. Test Set Up. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Test Considerations. . . . . . . . . . . . . . . . . . . 4 3.1.1. IGMP Support. . . . . . . . . . . . . . . . . . . 5 3.1.2. Group Addresses . . . . . . . . . . . . . . . . . 5 3.1.3. Frame Sizes . . . . . . . . . . . . . . . . . . . 5 3.1.4. TTL . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.5. Trial Duration. . . . . . . . . . . . . . . . . . 6 4. Forwarding and Throughput. . . . . . . . . . . . . . . . . . . 6 4.1. Mixed Class Throughput . . . . . . . . . . . . . . . . . 6 4.2. Scaled Group Forwarding Matrix . . . . . . . . . . . . . 8 4.3. Aggregated Multicast Throughput. . . . . . . . . . . . . 9 Stopp & Hickman Informational [Page 1] RFC 3918 Methodology for IP Multicast Benchmarking October 2004 4.4. Encapsulation/Decapsulation (Tunneling) Throughput . . . 10 4.4.1. Encapsulation Throughput. . . . . . . . . . . . . 10 4.4.2. Decapsulation Throughput. . . . . . . . . . . . . 12 4.4.3. Re-encapsulation Throughput . . . . . . . . . . . 14 5. Forwarding Latency . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Multicast Latency. . . . . . . . . . . . . . . . . . . . 16 5.2. Min/Max Multicast Latency. . . . . . . . . . . . . . . . 18 6. Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Group Join Delay . . . . . . . . . . . . . . . . . . . . 20 6.2. Group Leave Delay. . . . . . . . . . . . . . . . . . . . 22 7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Multicast Group Capacity . . . . . . . . . . . . . . . . 24 8. Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Forwarding Burdened Multicast Latency. . . . . . . . . . 25 8.2. Forwarding Burdened Group Join Delay . . . . . . . . . . 27 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. Contributions. . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值