演讲活动实施方案 演讲比赛活动方案

下面是好好范文网小编收集整理的演讲活动实施方案 演讲比赛活动方案，仅供参考，欢迎大家阅读！

IPTV就是组播的应用：

IPTV里的一个电视频道对应一个组播IP， 假设CCTV1 对应的组播IP =238.1.1.1 ，IPTV节目源IP=1.1.1.1，就以238.1.1.1 为目的地址封装发送，这里有两个问题需要解决：

IPTV组播源不知道收看此节目的用户在哪里？

收看此节目的用户不知道IPTV组播源在哪里？

用户IPTV机顶盒只知道节目组播地址为238.1.1.1 ，至于谁是这个节目源（IP=1.1.1.1）并不清楚。

于是就引入了一个中介机构（RP），Rendezvous Point，RP点，组播的汇聚点，RP IP = 2.2.2.2 ，组播源通过单播隧道的方式把组播238.1.1.1 发给 RP，简称组播源的注册。

机顶盒静态配置了RP IP = 2.2.2.2，知道RP会有组播数据，于是就向RP（ 2.2.2.2）申请加入这个238.1.1.1 的组，于是RP就把自己收到的注册组播源数据发送给机顶盒，这个就是基于RP的 树，RPT。

机顶盒收到第一个组播包，定睛一看，原来组播源是1.1.1.1，于是发一个申请给1.1.1.1 ，申请加入238.1.1.1，这就是基于源的 树，SPT。即然已加入了SPT ，就不需要RPT 了，向RP申请退出就可以了。

着重强调一点：一旦组播用户（接收者）知道了组播源，那RP的任务就算完成了，RP的存在就是为了组播接收者发现组播源，组播用户会加入路径更优的SPT树，会申请退出路径不是最优的RPT树，避免收到两份组播的复制。

IPTV是电信独立的IP网络，部署起来很容易；但是如果在全球网络里部署组播，将会遇到很多挑战。

如果想了解IGMPv3 以及PIM SSM 请回复，会继续更新。

想深入学习的童鞋请继续

------------------------------------

IP multicast 组播

在组播的世界里，我们又见到了树的概念，关于树，你一定会有似曾相识的感觉，二层交换网络就有树的概念了，那个树我们称之为：生成树，spanning tree，尽管这个树中文名称有点别扭，但它就是一棵树。

喜爱大自然的童鞋仔细观察一棵树，会发现一棵树，有根，主干，树杈，叶子，水分通过根，源源不断地输送到主干，树杈，然后到达叶子。水分在从根扩散到叶子的过程中，一直是单向的，没有水倒流的现象，即使水有倒流，也不会有环路，因为树的结构是发散的，没有物理的树杈的交织，自然不会发生环路。

网络科学家发现了这个规律，有一个大胆设想，如果把树的拓扑结构用于二层交换网络，在二层网络里选择一个根（root bridge)，其它交换机当作树的树杈，每个树杈自然有一个根末梢（root port)，这个就是交换机的上游接口，除了根末梢，其它的接口都是下游接口，至于下游接口是畅通的、还是阻断的，取决于到根的路径成本，谁更接近根，谁就畅通（Forwarding) ，即常说的Designated Port; 谁远离根，谁就需要被阻断（Blocked), 即常说的 Non Designated Port。通过这种仿生的机制，可以有效地避免网络环路。

今天我们主题并不是spanning tree，而是组播树。至于为什么要有树的概念，上文已经阐述，为了避免潜在的网络环路，那我们来谈谈组播树的概念。

组播第一个挑战就是组播的接收者（Receiver）不知道组播源在哪里，换句话说，就是不知道组播源的IP地址，如果知道了，可以直接向这个IP地址发送加入组播的请求，那一切就简单了，组播可以直接推送到组播的接收者。这仅仅是一个美好的假设，事实是接收者无从知道组播源的IP地址。

为了克服这个困难，引入了一个中介机构（RP），Rendezvous Point，RP点，组播的汇聚点。

为了更便于阐述这个复杂的过程，假定：

Multicast Source IP: 1.1.1.1

Multicast Group IP : 238.1.1.1

Rendezvous Point IP: 2.2.2.2

IGMPv2: Host chat with Router

PIM Sparse Mode: Router chat with Router

于是组播源就把组播238.1.1.1封装在一个单播（source IP 1.1.1.1，destination IP 2.2.2.2) 发给RP，我们称之为组播源的单播注册。

虽然组播的接收者不知道组播源在哪里，但他们深深地知道，他们所在的广播域里的路由器一定知道，而路由器如果静态配置RP，或动态发现RP，可以知道RP在哪里，可以间接的知道组播源在哪里。这就是美其名曰的：曲线救国！

于是组播接收者用IGMPv2发送一个广播请求，这个广播域里的路由器听到了这个广播请求，查询自己的单播路由表，可以知道谁是通向RP的上游路由器，然后发送一个PIM Join请求给上游，上游路由器按照相同的方式把这种Join 请求一级一级的中继到RP，RP简单地将收到Join请求这个接口放入组播出接口列表（OIL），然后把组播仅仅复制（Replication)一份从OIL发送出去。PIM Join 在层层向上中继的过程，路由器已经形成一个上下游的关系，越是靠近RP的路由器，为上游；而远离RP的路由器，为下游。这其实就是一种树，因为树的根是RP，我们称这种组播树为基于RP的树，即RP-Based Tree，简称RPT。

当组播接收者直连的路由器收到第一个组播，就知道组播源在哪里？为什么？因为组播包里的源IP告诉我们的啊！于是向组播源IP发起了一个新的PIM Join请求，为什么要这样啊？是不是画蛇添足啊？好，我们来分析一下：

组播先从组播源发到RP，然后再从RP顺着RPT树一级一级向下游扩散，直到到达组播的接收者，这条路径有点绕，因为先要绕到RP，所以不是最优路径。既然RP的存在是为了组播的接收者发现组播源，那一旦这个任务完成了，也就没有必要再走这条有点绕路的路径了，为什么不直接走组播源到达组播接收者的路径呢？省时、省力、省路径！于是组播接收者的直连路由器向着组播源1.1.1.1的方向，如何知道？查询单播路由表啊，然后顺着朝向1.1.1.1 的方向发送 Join 请求，也是一级级向着上游发请求，直到到达组播源1.1.1.1，这个有上下游关系也是组播树，因为树的根是组播源，我们称之为：基于源的树，Source Path Tree，简称SPT。

即然加入了SPT树，收到了组播数据，就没有必要赖在RPT树上，否则将会收到两份复制，这实在没有必要。于是组播接收者直连的路由器向RP提出leave 请求，RP将收到 leave 请求的这个接口从OIL列表里删掉，即不会再复制组播数据了。

忘了一个细节，RP在接收到组播源的单播注册，会发一个单播停止消息给组播源，即 Register Stop 消息，既然RP已经知道组播源在哪里了，继续单播注册就没有必要了。同时RP也会朝着组播源1.1.1.1 的方向发送Join请求，请求加入SPT树。