組播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樹。