IGMP协议 一九九八年十二月 2

目 录 一、为什么要多播？ ....................................................................................................................... 3 二、IP多播的应用 .......................................................................................................................... 7 三、IP多播服务模型 ...................................................................................................................... 9 四、IGMPv1 ................................................................................................................................... 14 五、IGMPv2 ................................................................................................................................... 18 六、IGMP版本1和版本2的互操作性 ...................................................................................... 32 3 一、为什么要多播？  当发送同一数据到多个接收者  更好的带宽利用率  减轻主机/路由器的处理负担  接收者的地址不明确 4  单播传送发送数据的多个拷贝，每个拷贝发送到一个接收者  主机发送数据的3个拷贝，网络分别转发至少个不同的接收者  主机一次只能发送至一个接收者  多播传送发送数据的一个拷贝到多个接收者  主机发送数据的一个拷贝，网络在每个接收者的最后可能存在的一跳复制它，在一个给定的网络上每一个包只存在一次。  主机可同时发送数据到多个接收者

单播（Unicast）与多播（Multicast） 5

 在一对多或多对多的环境中，多播传送比单播传送提供了更多优点：  提高效率：有效网络带宽得到了更有效地使用，因为重复数据流被单一传送所代替。  优化性能：需要转发和处理的数据量更少。  分布式应用：在单点传送的情况下，随着需求与应用的增长，多点应用将不太成为可能，因为单点传送中客户数量不能逐步增多。  从图中可以看到，使用单播传送传输率以1:1的比率随客户数据增长，而使用多播传送，传输率不随着客户数量增长而增长。

多播的优点  提高效率：控制网络传输，减轻服务器和CPU负载  优化性能：减少的传输冗余  分布式应用：使多点应用成为可能 6  多播缺点 --大多数的多播应用都是基于UDP的。和类似的单播、TCP应用相比这会导致一些边界作用。 --尽力传送机制会导致一些偶然的包丢失，许多实时多播应用（如音频、视频）可能会受到掉包的影响。同样，在这一类应用的应用层要求丢失数据重传是不可行的。 . 在声音应用中频繁的数据丢失会合声音模糊、失真，严重时会使内容无法理解。 . 在视频应用中适度的掉包有时会由于人眼的影响而得到较好的容忍。然而，即使很小的掉包率也会使一些压缩算法受到很严重的影响。当解压算法在恢复时，画面会模糊或冻结。 --随着基于UDP的多播应用的增长，无拥塞控制将会导致网络整体性能下降。 --由于多播网络拓扑结构的改变包的复制可能会偶然发生。应用程序应该预想到会有偶然发生的复制的包到达并进行相应设计。

多播的缺点 多播是基于UDP（用户数据报协议）的！  尽力传送：数据有可能发生丢失。多播应用不能期望数据得到可

靠的传送而应进行相应的设计。可靠的多播仍只是一个研究领域，期望在这一领域取得更大进展。

 无拥塞避免：缺乏TCP的窗口和slow-start机制可能导致网络拥

塞。如有可能，多播应用应该试图检测并避免拥塞状况。  复制：有些多播协议机制（例如Asserts、Registers和SPT传送）

会偶然产生包的复制，多播应用应设计成可以处理偶然复制的包。 7 二、IP多播的应用 随着对多点应用的需求的增长，许多多点应用逐渐出现： 例如：实时应用包括实况转播，金融数据的发送、共享白板以及视频会议等，非实时应用包括文件传输、数据与文件的复制及video-on-demand等。 多播应用举例： Mbone中的多播应用 1．SDR--会议目录 列出让大家都知道的多播组 登录多播应用 2．VIC--视频会议 H.261视频压缩 3．VAT--音频会议 PCM、DVI、GSM及LPC4压缩 3．WB--白板 共享画图工具 可以输入PostScript图象 使用可靠的多播 几个现有的MBONE多播应用 --会议目录是一个允许参加者观看让大家都知道的多播组工具并登录合适的多播应用以加入一个存在的会议。 --视频会议允许多个参加者交互共享音、视频 --单频会议允许多个参加得交互共享音频 --白板允许多个参加者在一个图文环境中交互合作。 8

SDR--会议目录： VIC--视频会议： VAT--音频会议： 9

WB--白板： 白板使用可靠的多播形式 --为保证关键的图形信息不会丢失可靠的多播是必要的。 --大多数的多播应用只是简单使用UDP及尽力传输(Best-Effort)数据报的机制。

下载Mbone应用 多媒体会议应用档案 包括sdr, vic, vat, wb及其他一些应用程序

URL: http://www.video.ja.net/mice/index.html 多平台支持 SunOS, Solaris, HP, Linux, Windows95 源代码

几个Mbone的多媒体应用可以免费获得： --为合适的平台下载所需要的应用程序。 -可同时获得源代码和二进制代码

三、IP多播服务模型

 RFC1112（多播支持的主机扩展）  每个多播组都由一个D类地址所确认  组成员可出现在Internet的任何地方  成员加入和离开组将此信息通知路由器  发送者和接收者截然不同：例如发送者可以不是组成员  路由器接收来自所有多播组的报文并使用多播路由协议管理组

RFC1112即网际网组管理协议(IGMP) --允许主机加入组以接收多播包 10

--允许用户基于他们运行的应用程序动态登记（加入或离开组） --使用IP数据报传送数据 编址 D类IP地址是动态分配的 多播IP地址代表接收者组，而不是某个单独的接收者。 组成员 接收者可在Internet中密集或松散地分布 接收者可在路由器间使用IGMP协议在任何时间动态加入或离开多播会议。 发送者不需要包适在他们发送的多播组内 多播路由 组分布要求包分布树能有效转发数据到多个接收者 多播路由协议沿着网络路径有效地指挥多播传输—MOSPF、CBT

IP多播服务模型  IP组地址 D类地址的高三位置1（即224.0.0.0），地址范围从224.0.0.0至239.255.255.255  由IANA（Internet Assigned Numbers Authority）分配的众所周知的地址 保留使用：224.0.0.0至224.0.0.255 224.0.0.1 子网内的所有主机（全主机组） 224.0.0.2 子网内的所有路由器（全路由器组） 参见 ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses  短暂地址，动态分配和回收 整个范围：224.0.1.0~238.255.255.255 限制范围：239.0.0.0~239.255.255.255 本地站点范围：239.253.0.0/16 本地组织范围：239.192.0.0/14

IP地址使用D类地址空间 --D类地址是高4位设为1110的IP地址 本地范围地址 --地址从224.0.0.0至224.0.0.255 --由IANA保留为网络协议使用 例： 224.0.0.1 全主机组 224.0.0.2 全多播路由器组 224.0.0.3 全DVMRP路由器组 224.0.0.5 全OSPF路由器组 224.0.0.6 全OSPF DR? 地址在这一范围内的多播包不转发出本地网络，而不考虑到包的TTL 整个范围的地址 地址从224.0.1.0至238.255.255.255 在整个Internet上动态分配 管理范围地址 地址从239.0.0.0至239.255.255.255