1 / 63

IP 组 播 基 础

内容. IP 组 播 基 础. 1. Geekometer. 内容. 为什么组播? 组播编址 主机-路由器通告: IGMP 组播分发树 组播转发 组播路由协议. 单播 vs 组播. 单播. 服务器. 路由器. 组播. 服务器. 路由器. 组播的优势. 提高 效率 : 控制网络流量，减轻服务器和 CPU 负荷 优化 性能 : 减少冗余流量 分布式应用 : 使多节点应用成为可能. 例如: 收听电台广播流 所有的客户端都接收相同的 8 Kbps 电台广播. 组播. 单播. 0.8. 0.6. 流量. 0.4. Mbps.

akio
Download Presentation

IP 组 播 基 础

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 内容 IP 组 播 基 础 1

  2. Geekometer 内容 • 为什么组播? • 组播编址 • 主机-路由器通告: IGMP • 组播分发树 • 组播转发 • 组播路由协议

  3. 单播 vs 组播 单播 服务器 路由器 组播 服务器 路由器

  4. 组播的优势 • 提高效率: 控制网络流量，减轻服务器和CPU负荷 • 优化性能: 减少冗余流量 • 分布式应用: 使多节点应用成为可能 例如: 收听电台广播流 所有的客户端都接收相同的8 Kbps电台广播 组播 单播 0.8 0.6 流量 0.4 Mbps 0.2 0 1 20 40 60 80 100 客户端数量

  5. 组播的劣势 组播是基于UDP的!!! • 尽力投递:报文丢失是不可避免的。因此组播应用程序不能依赖组播网络进行可靠性保证，必须针对组播网络的这个特点进行特别设计。“可靠组播”目前仍然处于研究阶段。 • 没有拥塞避免机制: 缺少TCP窗口机制和慢启动机制，组播可能会出现拥塞。如果可能的话，组播应用程序应该尝试检测并避免拥塞。 • 报文重复: 某些组播协议的特殊机制（如Assert机制和SPT切换机制）可能会造成偶尔的数据包的重复。组播应用程序应该容忍这种现象。 • 报文失序: 同样组播协议有的时候会造成报文到达的次序错乱，组播应用程序必须自己采用某种手段进行纠正（比如缓冲池机制等）。

  6. 适合于组播的应用 • 多媒体 • 流媒体 • 培训、联合作业场合的通信 • 视频/音频会议 • 数据仓库 • 金融应用（股票） • 任何的“单到多”数据发布应用

  7. 内容 • 为什么组播? • 组播编址 • 主机-路由器通告: IGMP • 组播分发树 • 组播转发 • 组播路由协议

  8. 一个组播组就是一个IP地址，不表示具体的主机，而是表示一系列系统的集合，主机加入某个组播组 即 声明自己接收某个IP地址的报文。 IP组播组地址 224.0.0.0–239.255.255.255 “D”类地址空间 第一个字节的高四位 = “1110” 保留的本地组播组地址 224.0.0.0–224.0.0.255 发送报文时TTL = 1 例如: 224.0.0.1 子网的所有系统 224.0.0.2 子网的所有路由器 224.0.0.4 DVMRP路由器 224.0.0.5 OSPF路由器 224.0.0.13 PIMv2路由器 组播编址

  9. 管理范围地址（Administratively Scoped Addresses） 239.0.0.0–239.255.255.255 私有地址空间 类似于RFC1918的单播地址 不能用于Internet全局传输 用于有限范围内的组播传输 组播编址

  10. 组播编址 IP组播 MAC地址映射 (FDDI和以太网) 32 Bits 28 Bits 1110 239.255.0.1 5 Bits Lost 01-00-5e-7f-00-01 25 Bits 23 Bits 48 Bits

  11. Multicast Addressing IP组播 MAC地址映射 (FDDI和以太网) 注意存在32 IP -> 1 MAC地址重叠 32 - IP组播地址 224.1.1.1 224.129.1.1 225.1.1.1 225.129.1.1 . . . 238.1.1.1 238.129.1.1 239.1.1.1 239.129.1.1 相同的组播MAC地址 (FDDI和以太网) 0x0100.5E01.0101

  12. 内容 • 为什么组播? • 组播编址 • 主机-路由器通告: IGMP • 组播分发树 • 组播转发 • 组播路由协议

  13. 主机-路由器通告: IGMP • 主机如何告诉路由器组播组成员关系-- 通过IGMP协议：Internet组管理协议: • 路由器向直连的所有主机询问组播组成员关系 • RFC 1112 -- IGMP版本1 • Windows 95支持 • RFC 2236 -- IGMP版本2 • Windows98后的版本及大多数UNIX系统 • IGMP版本3目前仍然是一个草案（draft） • draft-ietf-idmr-igmp-v3-03.txt

  14. Host sends IGMP Report to join group 224.1.1.1 H3 H3 报告 主机-路由器通告: IGMP 加入一个组 H2 H1

  15. 路由器周期性地向224.0.0.1发送查询 224.1.1.1 224.1.1.1 224.1.1.1 H2 H3 H1 X X 抑制 报告 抑制 查询 主机-路由器通告: IGMP 维护这个组 • 主机发送单个组的报告 • 组的其他成员监听到报告后抑制报告发送

  16. H3 #1 普遍组查询 #2 主机-路由器通告: IGMP 离开组播组(IGMPv1) H2 H3 H1 • 主机“默不作声”地离开组（不发报告了） • 路由器发送3个普遍组查询(间隔60秒) • 路由器没有收到这个组的IGMP报告 • 组播组超时（离开） (最大可能延迟~= 3分钟)

  17. 224.1.1.1 H3 离开组报告 224.0.0.2 #1 特定组查询 224.1.1.1 #2 主机-路由器通告: IGMP 离开组播组(IGMPv2) H2 H3 H1 • 主机向224.0.02发送离开组消息（包含离开的组） • 路由器向这个组（224.1.1.1）发送特定组查询 • 3秒钟内没有收到该组的报告 • 组224.1.1.1超时（离开）

  18. draft-ietf-idmr-igmp-v3-??.txt 其应用仍然在测试阶段 允许主机指定接收某些网络发送的某些组播组，相比以前的版本，增加了主机的控制能力，不仅可以指定组播组，还能指定组播的源。 IGMPv3

  19. 内容 • 为什么组播? • 组播编址 • 主机-路由器通告: IGMP • 组播分发树 • 组播转发 • 组播路由协议

  20. 组播分发树 最短路径树（基于源的分发树） 源 S1 源 S2 A B F D • 组播路由项 • (S, G), iif, oiflist • S 源地址 • G 组地址 • iif 入接口 • oiifs 出接口列表 C E 接收者 R1 接收者 R2

  21. 组播分发树 最短路径树（基于源的分发树） 源 S1 源 S2 A B F D • 组播路由项 • (S, G), iif, oiflist • S 源地址 • G 组地址 • iif 入接口 • oiifs 出接口列表 C E 接收者 R1 接收者 R2

  22. 共享树 组播分发树 • 组播路由项 • (*, G), iif, oiflist • * 任何源地址 • G 组地址 • iif 入接口 • oiifs 出接口列表 共享分发树 A B F D (RP) (RP) PIM汇聚点 C E 接收者 R1 接收者 R2

  23. 源 S1 源 S2 源树 组播分发树 • 组播路由项 • (*, G), iif, oiflist • * 任何源地址 • G 组地址 • iif 入接口 • oiifs 出接口列表 共享分发树 A B F D (RP) (RP) PIM汇聚点 C E 共享树 接收者 R1 接收者 R2

  24. 组播分发树 • 源树（最短路径树） 占用内存较多O(S x G)，但路径最优，延迟最小 • 共享树 占用内存较少O(G)，路径不是最优的，引入额外的延迟 不同分发树的特征

  25. 内容 • 为什么组播? • 组播编址 • 主机-路由器通告: IGMP • 组播分发树 • 组播转发 • 组播路由协议

  26. 组播转发 • 组播路由和单播路由是相反的 • 单播路由关心数据报文要到哪里去。 • 组播路由关心数据报文从哪里来。 • 组播路由使用 “反向路径转发”机制(RPF, Reverse Path Forwarding)

  27. 组播转发 反向路径转发(RPF) • 何谓RPF? • 路由器收到组播数据报文后，只有确认这个数据报文是从自己到源的出接口上到来的，才进行转发，否则丢弃报文。 • RPF检查 • 在单播路由表中查找到组播报文源地址的路由 • 如果该路由的出接口就是报文的入接口，RPF成功 • 否则RPF失败

  28. 组播转发 举例:RPF检查 源151.10.3.21 RPF检查失败 报文从错误接口到来! 组播报文

  29. 源151.10.3.21 发出的组播数据报文 X 报文从错误接口到达 丢弃数据报文！ 组播转发 看得更仔细点:RPF检查失败 S0 RPF检查失败! S1 S2 单 播 路 由 表 网络 接口 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0 E0 S1

  30. 源151.10.3.21 发出的组播数据报文 数据报文从正确的接口到达! 组播转发 看得更仔细点:RPF检查成功 S0 S1 S2 RPF检查成功! E0 单 播 路 由 表 网络 接口 151.10.0.0/16 S1 198.14.32.0/24 S0 204.1.16.0/24 E0 S1 向所有出接口 (即分发树的下游)转发

  31. 内容 • 为什么组播? • 组播编址 • 主机-路由器通告: IGMP • 组播分发树 • 组播转发 • 组播路由协议

  32. 组播路由vs单播路由 组播路由不是单播路由！是完完全全的新东西，不象OSPF，也不象RIP，不象你熟悉的任何东西。 不过，不要害怕啊，一会儿就懂了。

  33. 组播路由协议的类型 • 密集模式（Dense-mode） • 使用“推”（Push）模型（先给你，可以不要） • 组播数据整网络的泛滥（Flood） • 下游不想接收的话则剪枝（Prune） • 泛滥、剪枝、泛滥、剪枝…周而复始 (通常3分钟折腾一次) • 稀疏模式（Sparse-mode） • 使用 “拉”（Pull）模型（你要了，才给你） • 组播数据只发送到有需要的地方 • 有显式的加入（Join）过程

  34. 组播路由协议一览 • 目前，主要有4个组播路由协议: • DVMRPv3 (草案) • DVMRPv1 (RFC 1075)已经废止。 • MOSPF (RFC 1584) • PIM-DM (Internet草案) • PIM-SM V2 (RFC 2362) • 其他(CBT, OCBT, QOSMIC, SM, 等等)

  35. DVMRP简介 距离矢量组播路由协议（Distance Vector Multicast Routing Protocol），一个较为古老，具有实验性质的协议，现已经不常使用，鲜有厂家设备支持。 • 密集模式协议 • 基于距离矢量 • 类似于RIP • 最大32跳 • DVMRP依赖自己找回来的单播路由: • 进行RPF检查 • 创建“截断广播树”(TBT, 一种组播分发树型结构) • 使用特殊的“毒性逆转”机制 • 使用泛滥和剪枝机制 • 组播数据开始时延TBT向下泛滥 • 当下游不需要该数据时对TBT枝杈进行剪枝 • 剪枝每过一定时间超时，重新延枝杈进行泛滥

  36. DVMRP评价 • 广泛用于MBONE (古老的组播实验网络，很少有人在里面玩儿了) • 慢收敛—类似RIP • 路由器中组播路由状态信息庞杂，到处都是 (S,G) • 不支持共享树 • 最大不能超过32跳 • 不适合于大规模的网络（泛滥剪枝机制、可伸缩性差）

  37. MOSPF (RFC 1584) • 对OSPF单播路由协议的扩展 • OSPF: 路由器使用链路状态通告来获取整个网络的可用链路信息 • MOSPF: 在OSPF链路状态通告中包含组播信息，以此构建组播分发树(每个路由器都维护整个网络的最新拓扑信息) • 组成员关系LSA（链路状态通告）向OSPF路由域整网泛滥，这样MOSPF路由器就可以计算出接口列表 • 使用狄杰克斯特拉算法（Dijkstra algorithm）来计算最短路径树 • 为每个 (SNet, G) 对都需要单独的计算

  38. MOSPF评价 • 与单播路由协议相关，仅在OSPF网络内运行 • 可伸缩性不好 • 每个组播(SNet, G)对都需要使用Dijkstra算法进行计算！ • 不支持共享树 • 不适合于… • 通用的组播网络，其中发送者可能会非常的多 • 如IP/TV—(每个IP/TV客户端都是一个组播源) • 支持厂家较少，市场鲜有使用

  39. PIM可是 好东西啊！ PIM-DM • 协议无关组播（Protocol Independent Multicast） • 支持所有的单播路由协议: 静态路由、RIP、IGRP、IS-IS、BGP、OSPF，总之了，单播路由是什么都没关系。 • 使用逆向路径转发（RPF）机制 • 先向网络泛滥(Flood)，然后根据组播组成员关系进行剪枝 (Prune) • 使用Assert机制来剪枝冗余数据流 • 适合于... • 小规模的网络

  40. 组播数据报文 PIM-DM 泛滥与剪枝 初始泛滥 组播源 网络中的每个路由器 都创建(S, G)! 接收者

  41. 组播数据报文 剪枝消息 PIM-DM 泛滥与剪枝 剪枝不需要的数据流 组播源 接收者

  42. 组播数据报文 PIM-DM 泛滥与剪枝 剪枝之后，看... 组播源 网络中的每个路由器 中仍然保留(S, G)! 泛滥和剪枝过程每3分钟 重复一次!!! 接收者

  43. 2 2 Assert <distance, metric> Assert <distance, metric> 1 • 路由器从其“出接口列表”(oiflist)中的某个接口收到数据 !!! • 只有其中一个路由器应该继续发送数据，以避免重复 1 2 路由器发送 “PIM Assert”消息 PIM-DM Assert 机制 进入路由器的组播数据报文 (RPF检查都成功) S0 S0 E0 E0 • 计算distance和 metric值 • 谁到源的路由最优谁获胜 • 如果distance和 metric相等，IP地址大的获胜 • 输的就停止转发 (剪枝接口)

  44. PIM-DM 评价 • 对于小型网络来说非常有效 • 优势: • 易于配置--总共只有两条命令 • 实现机制简单（泛滥剪枝） • 潜在问题... • 泛滥剪枝过程不够高效 • 复杂的Assert机制 • 控制和数据平面混合 • 导致网络内部的所有路由器上都有(S, G) • 可能会导致非确定性的拓扑行为 • 不支持共享树

  45. PIM-SM (RFC 2362) • 支持共享树和源树 • 假设没有主机需要接收组播数据，除非它们明确地发出了请求（你不说我怎么知道你要呢？你要要你就说嘛，你说要我会给你的，….!@#$#$… :-) ） • 使用“汇聚点”(RP, Rendezvous Point) • 发送者和接收者在RP处进行汇聚 • 发送者的第一跳路由器把发送者注册到RP上（报个到，挂个号） • 接收者的DR（直连网络上的负责人）为接收者加入到共享树 (树根在RP) • 适合于… • 大规模的企业网络 • 是任何网络的优选方案，不管其规模和成员密集程度。（蛮夸张的哦:-)，不过现如今PIM-SM倒真是横扫一切） 这个RP很重要哦！

  46. (*, G) 加入 共享树 PIM-SM 共享树加入 RP (*, G) 仅在共享树 沿途建立 接收者

  47. 组播源 (S, G) 注册 (单播) (S, G) 加入 数据流 源树 PIM-SM 发送者注册 RP (S, G)仅在源树 沿途建立 共享树 接收者

  48. 组播源 (S, G)注册 (单播) 数据流 源树 (S, G) 注册停止 (单播) PIM-SM 发送者注册 RP 数据流从组播源通过 源树到达RP 共享树 RP向第一跳路由器发送注册停止（Register-Stop）消息，停止注册过程 接收者

  49. 组播源 数据流 源树 PIM-SM 发送者注册 RP 源数据流延源树（SPT） 流向RP 从RP开始，数据流延 共享树（RPT）流向接收者 共享树 接收者

  50. 组播源 (S, G) Join Traffic Flow Source Tree PIM-SM SPT 切换 RP Last-hop router joins the Source Tree. Shared Tree Additional (S, G) State is created along new part of the Source Tree. 接收者

More Related