第一章 概述
單播是相互感興趣的主機雙方進行通信的方式，主機不能接收對其不感興趣的其它主機發送的信息，屬於點對點通信。
廣播是主機向子網內所有主機發送信息，子網內所有主機都能收到來自某臺主機的廣播信息，屬於點對所有點的通信。
組播則介於兩者之間，是主機向一組主機發送信息，存在於某個組的所有主機都可以接收到信息，屬於點對多點通信。
下邊用張圖表示這三種方式的數據傳輸：
（圖來源CSDN，作者：楓飄瞬間）
第二章 二層組播基礎概念
在前面的介紹中，我們討論了用多播的方式解決新型流媒體業務的好處，在該部分中，我們結合一個實際的網絡給出一些多播的基礎概念， 掌握這些基礎概念是深入掌握多播技術的前提。
2.1 網絡實例
有下面一個網絡需求：
在圖中，媒體流服務器通過以太網交換機LSWA ，跟核心路由器 GSRA 連接起來，並啟動流媒體進程，不斷的以多播 IP 地址 224.10.10.10 發送媒體流。 GSRA 和 GSRB 之間採用以太網連接起來， GSRB 通過以太網交換機 LSWB 連接了許多終端，其中兩臺終端需要媒體流服務器播放的媒體流。
下面我們仔細分析每一個步驟，在分析的過程中引入並介紹一些基礎的組播概念。
2.2 組播 MAC地址和組播 IP 地址
在前面的介紹中，我們提到了媒體流服務器不斷的以多播 IP 地址 224.10.10.10 發送媒體流， 224.10.10.10 這個 IP 地址就是一個多播 IP 地址。按照 IP 協議規定，位於224.0.0.1—239.255.255.255 範圍內的 IP 地址都是多播地址。所謂多播地址，實際上是一個邏輯的概念，在網絡上，沒有一個計算機的 IP 地址是一個多播 IP 地址，多播 IP 地址僅僅代表了一個邏輯的組，加入該組的終端設備可以以該組所在的多播地址為目的 IP 地址來發送數據，這時候，發送的數據不是針對某個具體主機的， 而是針對一組機器，想接收這個多播數據流的計算機，只要傾聽接收到的每個數據報，判斷該數據報的目的 IP 地址是不是組播組的 IP 地址即可。若是，則接收，否則丟棄。
為了更好的理解組播 IP 地址的概念，我們舉一個例子，如下面的網絡圖所示：
主機A（最左邊的一臺計算機）不斷的以組播IP地址 224.10.10.10 送數據，這時候主機B（中間計算機）想接收組播組 224.10.10.10 的數據，於是它就會監聽每個收到的數據報，判斷該數據報目的 IP 地址是不是 224.10.10.10，如果不是則丟棄，如果是則接收下來送到上層處理。
這裡牽涉到了一個問題：主機 B 的哪個模塊判斷接收到的數據報是不是組播數據報，並且是不是針對組 224.10.10.10 的數據報？答案是主機 B 的 IP 模塊。我們看一下一臺計算機接收數據的過程：
1、數據鏈路層把接收到的數據幀剝掉鏈路層頭後送給 IP 層（至於數據鏈路層怎樣接收數據幀，在後面會詳細探討） ；
2、IP 模塊維護一張接收列表（該列表是 IP 地址組成的結合） ，每當接收到一個數據報（鏈路層送上來的） 後， 便把數據報的目的 IP 地址提取出來， 然後跟接收列表中的 每個 IP地址比較，如果有一項匹配，則接收該數據，並向上層傳送，否則丟棄；
3、如果一臺主機想加入一個多播組（加入與否由上層應用決定） ，比如你想看網絡電視頻道， 這時候你需要啟動一個應用程序， 並告訴該應用程序網絡電視頻道的組播 IP 地址，該應用程序就會向 IP 模塊註冊，請求加入組播組。 IP 模塊於是在自己維護的接收列表裡添加一項（ 同時也告訴數據鏈路層自己加入了一個組播組，並附帶上組播組地址 ），添加的這項就是組播組的組播 IP 地址。這樣每當接收到目的地址是該組播 IP 地址的數據報的時候，IP 模塊就接收下來，並向上層傳送。
4、如果一臺主機想退出組播組，比如你終止了電視頻道接收程序，於是該程序在退出的時候會告訴 IP 模塊，自己不再接收組播組的數據，並告訴 IP 模塊組播組的組撥 IP 地址，於是 IP 模塊就把該組播地址從接收列表中刪除，這樣以後如果再接收到該組播組的數據報的話，因為接收列表裡沒有匹配的項目，所以 IP 模塊就丟棄該數據報。
經過上面的分析可以看出，問題的關鍵在於 IP 模塊維護的接收列表。通常情況下（主機沒有加入任何組播組） ，該列表裡只有兩項，即主機自己的 IP 地址和廣播 IP 地址（255.255.255.255 ），這樣主機只能接收針對自己的數據報和廣播數據報。
細心的讀者可以看出一個問題，就是數據鏈路層如何接收組播數據幀呢？原來，數據鏈路層的接收過程跟IP層原理一致，即數據鏈路層也有自己的接收列表（不過該列表的內容不是IP地址，而是MAC地址），每當 IP 模塊收到上層應用的加入組播組的請求之後， IP模塊就會向數據鏈路層通告（上面提到過） ，通告的時候攜帶了組播組的 IP 地址，於是數據鏈路層就會把 IP 地址進行適當的變換，變換的結果就是一個組播 MAC 地址，於是數據鏈路層把這個組播 MAC 地址插入自己的接收列表裡面，以後每當有數據幀到來的時候，數據鏈路層就會把數據正的目的 MAC 地址跟接收列表裡的每項內容進行比較， 遇到任何匹配的一項就接收下來，並向 IP 層傳送。
這樣又引出了兩個問題： 數據鏈路層如何區分單播 MAC 地址跟組播 MAC 地址？數據鏈路層做一個 IP 地址跟組播 MAC 地址的影射，這個影射是怎樣的？
首先解釋第一個，一般情況下，單播 MAC 地址的最高字節的最低比特為 0，而組播MAC 地址的最高字節的最低比特為 1，如下所示：
這樣數據鏈路層就可以根據該比特判斷收到的數據幀是不是一個組播數據幀。下圖是第二個問題的答案：
從可以看出，MAC地址跟 IP 地址的低 23 比特是對應的， 比如 IP 模塊告訴數據鏈路層軟件 ，自己加入了一個組播組224.10.10.10 ， 則數據鏈路層形成一個MAC地址01--00--5E--0A--0A--0A （取組播 IP 地址低 23 位，高位為上面介紹的規則），並加入接收地址列表中。
到此為止，我們分析了網絡層和數據鏈路層對組播的處理過程，為了更加深理解，我們舉一個實際中的例子，還是同樣的網絡拓撲：
假設圖中從左到右計算機依次叫做 PCA ，PCB， PCC，並假設 PCA 上運行媒體流服務器發送程序，以組播地址 224.10.10.10 來不停的發送電視頻道數據流。
開始的時候，PCB和PCC都沒有接收該數據流， 於是在 PCB，PCC 的數據鏈路層和網絡層的接收列表中都沒有針對 224.10.10.10 組播地址的接收項， 從而當數據鏈路層接收到一個數據幀，該該數據幀的目的 MAC 地址是 01--00--5E--0A--0A--0A 的時候，因為接收列表中沒有該地址， 所以在數據鏈路層就被丟棄（到這裡，讀者應該能體會到， 組播數據在數據鏈路層就可以被隔離， 而廣播數據則必須到達網絡層才能判斷出是否需要丟棄， 這也是使用組播而不使用廣播的最大好處） 。
這時候，假設 PCB 計算機的一個用戶想收看網絡電視頻道了，於是該用戶啟動一個程序（比如， WINDOWS 平臺下的 WMPLAYER ），並告訴該程序接收 224.10.10.10 組播組的數據流。於是發生下列事情：
1、該應用程序通過操作系統調用接口（ API 函數）告訴該 PC 機的 IP 模塊，自己想接收224.10.10.10 組播組的數據（也就是說要加入組播組 224.10.10.10）；
2、IP 模塊接收到該加入請求後， 便把組播組地址 224.10.10.10 加入自己的接收列表中，同時向數據鏈路層發送一個請求， 告訴數據鏈路層自己想接收 224.10.10.10 組對應的數據流；
3。數據鏈路層接收到 IP 模塊的這個請求後，根據組播 MAC 地址跟組播 IP 地址的影射規則，把組播 IP 地址 224.10.10.10 影射成組播 MAC 地址 01--00--5E--0A--0A--0A ，然後加入自己的接收列表，到此動作完成 。
完成上述動作後， PCB 就可以接收組播組 224.10.10.10 的數據流了。如果這時候用戶不想繼續看網絡電視了 （比如用戶關閉應用程序） ，則應用程序在退出的時候會通知網絡層，自己退出組播組 224.10.10.10 了，於是網絡層會把自己的接收列表中 224.10.10.10 項刪除，並通知數據鏈路層刪除相應的列表項目。
到此為止，我們對組播 IP 地址跟組播 MAC 地址做了個詳細的介紹，並詳細分析了各個協議模塊怎麼處理組播數據的。
2.3 二層組播協議
在上面介紹的幾個例子中，我們使用了以太網交換機連接許多主機終端，並假設以太網交換機按照廣播的形式發送組播數據， 即以太網交換機每當接收到一個組播數據報， 就向所有的端口上轉發（除去接收端口） 。如下所示：
還是原來的命名規則， 計算機從左到右依次為 PCA，PCB，PCC。這樣當交換機從PCA所在端口接收到 PCA 發出的組播數據幀後， 就向 PCB，PCC 所在端口轉發。 這時候假設 PCB在接收組播數據流， 而 PCC 沒有接收組播數據流， 於是 PCC 就可能接收到一些多餘的數據（雖然這些數據在數據鏈路層就被隔離掉了，但畢竟不是理想的做法） 。
理想的做法是，交換機只向需要組播數據的端口設備轉發組播數據流，比如PCB需要數據，則僅僅向PCB 轉發。回憶我們以前講解以太網技術的時候，曾經講解了交換機的轉發過程，交換機是根據內部的一張CAM表來做出轉發決定的， 我們可以從概念上理解CAM表是這樣構成的： { 目的 MAC 地址，出口集合 } ，在單播情況下，交換機根據數據幀的目的MAC 地址查找 CAM 表，找到一個出口（在單播情況下，出口集合中只有一個元素） ，然後把這個數據幀從該出口轉發出去。
交換機上的這個 CAM 表同樣適用於組播的情況，這時候，目的 MAC 地址就是一個組播 MAC 地址（其特點和形成過程嚴格按照前面介紹的規則） ，而出口集合就可能不是一個元素了，可能是多個元素的集合。還是假設上面的例子，假設開始的時候只有 PCB 接收數據，則交換機創建一個轉發項（01--00--5E--0A--0A--0A ， {B} ）（假設 PCB 連接交換機的 B端口），並按照該轉發項轉發組播數據流，這樣 PCC 就不能收到無用的數據流了。
這時候假設 PCC 也加入了組播組 224.10.10.10，於是交換機修改自己的轉發表，把轉發項（ 01--00--5E--0A--0A--0A ，{B} ）修改成 （01--00--5E--0A--0A--0A ，{B ，C} ）（假設 PCC連接交換機的 C 端口），這樣每當交換機從 PCA 接收到一個數據幀，就根據這個轉發項，複製成兩份，一份給 PCB，一份給 PCC。
大家對交換機上的組播轉發項已經很清楚了，這時候又一個問題出現了：交換機根據什麼創建組播轉發項， 並對組播轉發項的出口集合做出修改？回憶單播的情況下， 交換機是根據學習來獲得單播轉發表的，在組播情況下，學習能否奏效？
其實在組播情況下， 學習是不行的， 因為在單播情況下的學習， 是針對數據幀的源 MAC地址進行的，而組播 MAC 地址不可能出現在數據幀的源 MAC 地址位置上（組播 MAC 地址出現的唯一位置就是數據幀的目的 MAC 地址），所以根本無法學習。這時候我們必須想一些其他辦法來解決該問題，這些辦法就是二層組播協議。
第一種辦法，也是最容易理解的辦法就是 GMRP（通用組播註冊協議） ，該協議需要計算機的網卡的配合。 該協議這樣運行， 每當計算機加入一個多播組的時候， 計算機同時給交換機發送一條 GMRP 加入消息，該消息攜帶的內容之一就是計算機加入的組播組的 MAC地址。這樣交換機會根據不同的情況而採取不同的動作：
1、如果交換機上沒有創建針對該組播 MAC 地址的轉發項，則創建一個轉發項，把出口集合初始化為連接發出請求的計算機的端口，以後就根據這個轉發項進行數據轉發；
2、如果交換機上已經有了針對該組的轉發項， 則交換機僅僅把連接發出 GMRP 加入請求的計算機端口加入轉發項的出口列表裡面即可。
這種方式簡單明瞭，容易理解，但需要計算機網卡驅動程序的支持，目前來說，很少網卡能有這種能力，所以應用不是很廣泛。
另外一種應用很廣泛的協議是 IGMP 窺探，這種協議是建立在 IGMP 協議上的，在介紹這種協議之前，我們先介紹一下 IGMP 協議。
所謂 IGMP ，即 INTERNET 組管理協議，是用於主機跟路由器之間交互的一種協議，為了說明這種協議出現的背景，請參考下面的圖示：
一般情況下，路由器是不轉發組播數據流的，即路由器假設自己的本地網絡上不存在組播數據流的接收端， 這樣的假設是符合實際情況的。 在圖中， 媒體流不停的發送電視頻道數據， 這些數據被路由器阻隔， 所以到達不了本地網絡。 假設本地網絡上有一臺計算機想接收該媒體服務器發出的數據流， 這時候該計算機必須告訴路由器自己的需求， 這樣路由器才能把組播數據流引入本地網絡。計算機告訴路由器使用的這種協議就是 IGMP 協議。
IGMP 協議第一版主要有兩種消息： 主機加入消息和成員查詢消息， 這兩種消息分別從主機和路由器發出。其中， 主機加入消息是計算機用來告訴路由器， 自己想加入某個組播組的，而成員查詢消息是路由器發出，用來查詢網絡上是否還有某個組播組的成員的。以上圖為例，分析一下 IGMP 協議的運行過程：
1、本地網絡上的一臺主機加入了一個多播組G，於是該主機發出一個 IGMP 加入消息給路由器，告訴路由器自己想加入組播組G，於是路由器開始從上游引入組播組G的數據到本地網絡；
2。路由器轉發組播組 G 的數據一段時間後， 會發出一個查詢消息，看網絡上是否還存在組播組 G 的成員（因為有可能剛才加入的那臺主機已經退出組播組了） ，加入組播組的成員要重新發布 IGMP 加入消息來作為成員查詢消息的響應， 如果沒有組播組的成員了， 路由器將收不到響應， 這時候路由器將再次進行查詢嘗試， 如果還沒有主機應答， 路由器就認為網絡上已經沒有針對組播組 G 的主機了，於是停止轉發組播組 G 的數據；
3。路由器發出組播組成員查詢消息後，只要收到一臺主機的響應，則路由器就必須繼續轉發組播組 G 的數據，不能因為網絡上接收端的數目少而停止發送。
這樣 IGMP 協議就很清楚了，我們來看一下 IGMP 窺探協議是怎樣工作的。
IGMP 窺探是這樣的，交換機分析每個接收到的組播數據幀（ IGMP 加入消息是以組播方式發送的） ，看該數據正是否是一個 IGMP 加入消息，如果是，則從該消息中就可以判斷出發出該消息的主機想加入的組播組，根據該組播組的 IP 地址形成組播 MAC 地址，並把接收到該消息的端口加入出口列表，這樣一個組播轉發項就創建完成了。
完成之後，交換機把剛才攔截的 IGMP 消息再不加改變的轉發出去。這樣不停的窺探，交換機就可以掌握網絡上的組播成員情況， 並反映在自己內部的組播轉發表裡， 以後就根據創建的組播轉發表來進行數據的轉發。
IGMP 窺探存在一個嚴重的問題， 就是交換機必須分析每個組播數據幀， 判斷該數據幀是否是 IGMP 加入消息， 如果是，則進行進一步分析，否則轉發。 這樣對一些低性能的交換機來說， 是一項很繁重的任務， 所以該協議不適合低端交換機， 而適合一些核心層的骨幹交
換機。
第三章 三層組播基礎概念
在前面部分的介紹中，我們集中在了對二層組播基礎概念的介紹上，在本章中，我們引入一些三層組播的基礎概念，在這些概念的基礎上，簡單介紹目前流行的組播路由協議（注意跟二層組播協議的區分） 原理及應用場合， 使讀者對這些協議有個大致的瞭解，併為以後詳細學習這些組播路由協議打下基礎。
3.1 組播轉發項，組播樹和RPF檢查
為了引入這些概念，我們首先看一個實際的網絡圖：
在該圖中，路由器 MR1 連接了一臺多播數據源，該數據源不停的播放多播數據，MR2和 MR3 連接的本地網絡都有數據接收端， MR4 的本地網絡沒有數據接收端。這樣 MR1 在轉發多播源數據的時候，就只需向 MR2 和 MR3 轉發即可，沒有必要再轉發給 MR4 。這樣我們可以通過在路由器 MR1 上創建三層轉發項來完成， 三層轉發項可以是這樣的結構：（S，IIF ，G， {S0，S1， ...} ），其中S是組播數據源的 IP地址， IIF 是到達組播源 S 所使用的接口，即在單播方式下，路由器如果要給組播源 S 發送數據，則通過 IIF 接口發送，而 G 則是組播組地址， {S0 ， S1，。。。 } 是一個出口集合。這個轉發項的含義很明確，就是當路由器接收到一個數據報後，把這個數據報的源 IP 地址和目的 IP 地址（該目的 IP 地址是一個組播地址） 讀出來， 跟轉發項匹配， 如果有一個轉發項的源地址跟組播組地址相同，則把這個數據報向出口集合中所有的接口轉發 （需要注意的是， 在把數據包發送出去之前， 還需要進行一個 RPF 檢查，只有通過了才轉發，否則丟棄） 。
網絡上所有路由器的三層組播轉發項串接起來，就構成了一棵組播轉發樹，比如，在下面的圖形中，MR1 的組播轉發項為（S，E0，G，{S0，S1} ）（其中S0，S1 連接MR2和MR3路由器），MR2組播轉發項為（S，S0，G，{E0} ），MR3 組播轉發項為（ S，S0，G，{E0} ），這樣就構成下面的樹狀結構（以紅色線條標出） ：
可以看出，這棵樹是以數據源為根的，所以叫做源組播樹（還有一種組播樹叫共享組播樹，後面介紹） 。組播數據就是沿著這棵樹向下流動的。
在介紹了組播轉發項和組播樹之後， 我們看一個在三層組播中的一個非常重要的概念：RPF（反向路徑轉發）檢查。為了解釋RPF檢查提出的原因，請參考下面的示例：
在這個簡單的網絡結構中，流媒體服務器不斷的發送出組播數據流，這樣跟流媒體服務器連接到同一個以太網交換機上的兩個路由器就都會接收並轉發該組播數據流。 於是一個問題出現了：路由器 MR 會從兩個接口 S0， S1 上分別收到相同的組播數據流，這個時候MR 選取哪個組播數據流並進行轉發呢？如果 MR 把兩個組播數據流都進行轉發， 肯定是不合適的，假設組播數據流是一個電視頻道，這樣必然引起圖象的重複出現，嚴重影響畫面。
於是我們可以這樣選擇： 選擇一個組播流，該組播流從組播源到路由器經過的路徑最短。比如在上面的網絡中，我們讓路由器 MR 選擇從接口 S0 進入的組播流，因為 S0 直接連接了組播數據源，而 S1 的組播數據源則經過了另外一臺路由器。然而路由器怎樣知道從哪個接口進入的數據流是最近的呢？答案是查找單播路由表。
到此為止，大家對 RPF 檢查的背景一定有印象了，下面我們給出 RPF 檢查的定義： 支持組播的路由器每當接收到一個組播數據報，首先把組播數據報的源 IP 地址提取出來，然後根據這個源 IP 地址查自己的單播路由表，查找的結果是一個接口，如果該接口跟接收到報文的接口相同， 則根據多播轉發表來轉發該組播數據報， 如果不相同， 則丟棄該組播數據報。
RPF 檢查是三層組播中一個最重要的特性，正是它的存在，才把組播轉發表和單播轉發表結合了起來，在進行組播數據轉發的時候，把單播轉發表作為參考依據。而且 RPF 檢查確保了到達的數據流不會重複， 也確保了到達的數據流對網絡的影響最小 （因為數據流是通過最短的路徑過來的） 。
3.2 組播路由協議
在上面我們介紹了組播轉發表的概念，組播路由器在進行組播數據的轉發的時候，就是依該轉發表為基礎來進行數據轉發的， 需要注意的是， 在進行組播數據轉發的時候， 還需要做一個重要的動作： RPF 檢查。
現在的一個問題是：組播路由器上用於組播數據轉發的組播轉發項是如何建立起來的？答案是組播路由協議。
跟單播路由協議一樣，組播路由協議用於建立路由器上用於組播數據轉發的組播轉發項。目前常用的組播路由協議有 DVMRP ， PIM-DM ， PIM-SM 等。在介紹這些協議之前，首先引入兩個概念：剪枝和嫁接。
考慮下面的圖形：
組播路由器 MR 從接口S0，S1 上分別接收到組播數據，然而經過 RPF 檢查後，S1上接收到的組播數據被丟棄了， 因為在單播路由表中通往流媒體服務器的接口是 S0。但是 RPF檢查是發生在MR上的，連接 MR S1接口的路由器（假設為RT1）卻不知道 MR 不需要從自己那裡接收數據流，因而一直不停的把數據流發給 MR 。這樣不但浪費鏈路帶寬資源，而且浪費 MR 的系統資源，因為 MR 路由器必須做 RPF 檢查。因此，一個有效的辦法就是讓RT1 停止從該接口上轉發組播數據流， 這可以通過一個特殊的消息 — 剪枝來解決， 具體過程是這樣的：
當 MR 路由器從接口 S1 接收到組播數據報後， 馬上進行 RPF 檢查，如果失敗，則 MR路由器丟棄接收到的組播數據報，並通過 S1 接口給上游路由器（在這裡就是 RT1）發送一個剪枝消息，告訴上游路由器停止轉發該組的數據。這樣當 RT1 接收到這個請求後，就不再從該接口轉發數據流。 RT1 是通過修改自己內部的多播轉發表來做到這一點的， 回憶一下多播轉發表的結構， RT1 路由器僅僅在多播轉發表的出口集合中把相應接口刪除即可。
瞭解了剪枝消息後，嫁接消息就很簡單了，它跟剪枝消息剛好相反，是用來通知上游路由器，讓上游路由器把組播數據轉發給自己，比如，在上面的圖形中， MR 路由器的接口S0 由於某種原因 DOWN 掉了，這時候 MR 路由器會通過 S1 接口給上游路由器發送一個嫁接消息， 接收到該嫁接消息後， RT1 路由器回重新發組播數據流給 MR 路由器 （通過在多播轉發表中把連接 MR 路由器的接口加入出口集合來實現），這樣在 MR 上會通過 S1 接收到組播數據流，這時候 MR 上進行 RPF 檢查就不會失敗了，因為 S0接口 DOWN 掉，通往媒體流服務器的單播路由項會自動的切換到 S1 接口上（通過動態路由協議完成） 。
其實，組播路由協議可以理解為剪枝和嫁接消息的集合，任何組播路由協議都是由這兩個消息作為基礎的，只不過不同的路由協議發出該消息的時機不同罷了。
上面介紹的時候，提到了 RPF 檢查，並提到， RPF 檢查需要路由器的單播路由表，這個說法嚴格來說其實是不正確的， 因為要分兩種情況： 對於某些協議（比如 PIM-DM ，PIM-SM等），這些協議在進行 RPF 檢查的時候直接使用路由器用於轉發單播數據的路由表， 即這些協議信任路由器的單播路由協議，這種多播協議叫做協議無關多播協議（也就是 PIM 的由來，即 Protocol Independ Multicast Protocol ），還有一些協議，比如DVMRP等，它們在進行RPF檢查的時候，是根據自己建立的一個單播路由表進行的， 所有這些多播路由協議至少有兩部分構成：一部分用於單播路由表的建立（該單播路由表跟路由器用來轉發單播數據的路由表不同，它僅僅用於 RPF 檢查），另外一部分用於組播路由表的建立。比如 DVMRP ，它實際上集成了一個 RIP 模塊，使用該 RIP 模塊來建立用於 RPF 檢查的單播路由表。
下面我們看一下 PIM 協議， PIM （協議無關多播路由協議）分為 DM （密集模式）和SM（稀疏模式），密集模式往往用於一些企業網等網絡帶寬資源比較豐富的場合下，而稀疏模式則用於網絡帶寬比較緊張的大型網絡中，比如 INTERNET ，下面我們結合一個網絡拓撲圖形來分析這兩種協議的本質不同：
假設多播路由器 MR1 和 MR2 運行的是 PIM-DM 協議，這樣每當 MR1 接收到媒體流服務器發送過來的組播數據後，它就會通過串口 S0 發送給 MR2，而不管MR2 需要不需要這些組播數據流。當MR2 不需要組播數據流的時候，MR2會通過一個剪枝消息通知MR1，讓 MR1 停止發送組播數據流，這樣 MR1 接收到 MR2 的剪枝消息後，會暫停發送組播數據流，一段時間後（該時間一般是 3 分鐘，但可以配置） ，如果在這段時間內沒再次接收到MR2 發送過來的剪枝消息，則重新開始發送數據流。所以，如果 MR2 不想接收 MR1 發送過來的組播數據流的話， 則必須不停的週期性的發送剪枝消息該 MR1 ，即不停的 “阻止 ”MR1給自己發送組播數據流。
如果 MR1 和 MR2 運行的是PIM-SM 協議，則情況就完全兩樣了，這時候，MR1 總是假設MR2不需要組播數據流，於是根本不給 MR2 發送從媒體流服務器接收到的數據流，這時候如果 MR2 想接收媒體流服務器發送的數據流的話，必須通過一個嫁接消息告訴MR1，自己想接收組播數據流了， MR1 才開始給 MR2 發送組播數據流，不過一段時間後（該時間可以配置），如果沒有再次接收到來自 MR2 的嫁接消息，則停止發送組播數據流。所以，如果 MR2 想持續不斷的接收媒體流服務器發送過來的數據流，則必須不停的週期性的給MR1 發送嫁接消息，也就是說，不停的向 MR1“索取 ”組播數據流。
理解上面“阻止 ”和“索取 ”的含義，是理解DM和SM區別的關鍵。
其實，PIM-DM 和PIM-SM的區別還有一個重要的方面，就是 PIM-DM 一開始就使用源組播樹轉發數據，而 PIM-SM 開始的時候使用共享的組播樹發送組播數據，如果組播數據量到了一定程度， 則轉換為源組播樹來完成組播數據的轉發。
共享組播樹是這樣的，即整個網絡選擇一箇中心點，組播流數據首先發送到該共享的中心點（ RP）上，然後由 RP 完成數據的轉發。默認情況下， RP 是不轉發組播數據流的，所以如果一個路由器想接收組播數據流，則必須向共享中心點註冊，這樣當 RP 接收到你註冊的組播組的數據後，才向註冊路由器轉發。
下面我們以一個簡單的拓撲圖說明註冊的過程：
圖中，RP即整個網絡的共享中心點，這樣假設 MR2 想接收來自媒體流服務器的組播數據流，則必須首先向 RP 註冊（假設所有路由器都是運行 PIM-SM 協議）。下面說明 MR2的註冊過程：
1、MR2創建組播轉發項（ *，G，S0， {E0} ）（假設媒體流服務器在組播組G內轉發數據， MR2 通過 E0 接口連接本地網絡），並通過S0接口向 MR1 發送一個嫁接消息，該嫁接消息中包含了RP的IP 地址；
2、MR1 接收到 MR2 發送過來的嫁接消息後，如果存在關於（ * ，G）的轉發項，則僅僅把 S0 接口加入轉發項的出口列表即可，否則 MR1 首先創建轉發項（ *， G，S1，{S0} ），並通過 S1 接口向 RP 路由器發送嫁接消息；
3、如果 RP 路由器上存在組播轉發項（ *， G），則僅僅把出口 S0 加入出口列表，如果不存在該轉發項，則創建轉發項（ * ，G，E0，{S0} ），這樣當接收到媒體流服務器發送過來的組播數據流後，就根據該轉發項進行轉發 （這裡需要提出的是，如果路由器接收到一個組播數據報， 然而自己組播轉發表內沒有關於該組播數據報的轉發項的話， 丟棄收到的組播數據報）。
在上面的過程中，所有轉發項的源都是以 *代替， * 代表任何組播數據源，即創建該組播轉發項的路由器對組播數據源的具體位置不關心。那麼這時候就存在一個問題： 組播路由器是根據什麼來進行組播數據的RPF檢查的呢？原來，PIM-SM 協議的路由器在進行RPF檢查的時候，不是採用組播數據報的源 IP 地址，而是根據 RP 路由器的 IP 地址來進行的。
