组播IP地址
关于组播地址的分类：
224.0.0.0～224.0.0.255为预留的组播地址（永久组地址），地址224.0.0.0保留不做分配，其它地址供路由协议使用；
224.0.1.0～224.0.1.255是公用组播地址，可以用于Internet；
224.0.2.0～238.255.255.255为用户可用的组播地址（临时组地址），全网范围内有效；
239.0.0.0～239.255.255.255为本地管理组播地址，仅在特定的本地范围内有效。
组播也是一种IP包，也有源IP地址，目的IP地址，源IP地址为组播源的服务器IP地址，目的地址为一个特殊的IP地址，它位于 224.0.0.0 - 239.255.255.255 中，由于 224.0.0.0/8用于本地链路，即一跳的组播，239.0.0.0/8 为私有组播地址，所以实际的可用于在互联网上组播地址是225.0.0.0/8 - 238.0.0.0/8，这个组播地址不属于任何服务器或个人，它有点类似一个微信群号，任何成员（组播源）往微信群（组播IP）发送消息（组播数据），这个群里的成员（组播接收者）都会接收到此消息。
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是IGMPv2 以及 PIM SM mode 的一个应用。
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树。