1 IP組播基礎
IP組播技術有效地解決了單點發送、多點接收的問題。組播源只發送一份數據，被傳遞的信息在距組播源盡可能遠的網絡節點才開始被復制和分發，並且只發送給需要該信息的接收者。
說明：
本章所涉及的交換機和交換機圖標，是指使能了二層組播功能的路由器。
- 1.1 IP組播簡介
介紹IP組播的定義、目的和受益。 - 1.2 原理描述
介紹IP組播的基本概念、組播服務模型、組播地址和組播協議。 - 1.3 應用場景
介紹IP組播的應用場景。
1.1 IP組播簡介
介紹IP組播的定義、目的和受益。
定義
作為IP傳輸三種方式之一，IP組播通信指的是IP報文從一個源發出，被轉發到一組特定的接收者。相較於傳統的單播和廣播，IP組播可以有效地節約網絡帶寬、降低網絡負載，所以被廣泛應用於IPTV、實時數據傳送和多媒體會議等網絡業務中。
目的
傳統的IP通信有兩種方式：單播（Unicast）和廣播（Broadcast）。
- 對於單播通信，信息源為每個需要信息的主機都發送一份獨立的報文。
- 對於廣播通信，信息源將信息發送給該網段中的所有主機，而不管其是否需要該信息。
如果要將數據從一台主機發送給多個主機而非所有主機，可以采用廣播方式，也可以由源主機采用單播方式向網絡中的多台目標主機發送多份數據，如圖1-1所示。
- 采用單播方式時，網絡中傳輸的信息量與需要該信息的用戶量成正比。當需要該信息的用戶數量較大時，信息源需要將多份內容相同的信息發送給不同的用戶，這對信息源以及網絡帶寬都將造成巨大的壓力。因此，該傳輸方式不利於信息的批量發送，只適用於用戶稀少的網絡。
- 采用廣播方式時，不需要接收信息的主機也將收到該信息，這樣不僅信息的安全性得不到保障，而且會造成同一網段中信息泛濫。因此，該傳輸方式不利於與特定對象進行數據交互，同時會浪費大量的帶寬。
由上述可見，傳統的單播和廣播通信方式不能有效地解決單點發送、多點接收的問題。
組播（Multicast）可以很好的解決點到多點的數據傳輸，如圖1-2所示，源只發送一份數據，網絡中只有需要該數據的主機（目標主機HostA和HostC）可以接收該數據，其他主機（HostB）不能收到該數據。
- 相比單播，由於被傳遞的信息在距信息源盡可能遠的網絡節點才開始被復制和分發，所以用戶的增加不會導致信息源負載的加重以及網絡資源消耗的顯著增加。
- 相比廣播，由於被傳遞的信息只會發送給需要該信息的接收者，所以不會造成網絡資源的浪費，並能提高信息傳輸的安全性。
受益
組播適用於任何“點到多點”的數據發布，主要包含以下幾方面：
- 多媒體、流媒體的應用。
- 培訓、聯合作業場合的通信。
- 數據倉庫、金融應用（股票）。
IP組播技術在ISP提供的互聯網信息服務中已經得到了應用。例如：在線直播、網絡電視、遠程教育、遠程醫療、網絡電台和實時視/音頻會議等。
1.2 原理描述
介紹IP組播的基本概念、組播服務模型、組播地址和組播協議。
1.2.1 組播基本概念
組播傳輸的特點是單點發送，多點接收。如圖1-3所示為組播的傳輸模型示意圖，網絡中存在信息發送源Source，感興趣的用戶HostA和HostC提出信息需求，Source發出的數據只有HostA和HostC會接收到。
- 組播組：用IP組播地址進行標識的一個集合。任何用戶主機（或其他接收設備），加入一個組播組，就成為了該組成員，可以識別並接收發往該組播組的組播數據。
- 組播源：信息的發送者稱為“組播源”，如圖1-3中的Source。一個組播源可以同時向多個組播組發送數據，多個組播源也可以同時向一個組播組發送報文。組播源通常不需要加入組播組。
- 組播組成員：所有加入某組播組的主機便成為該組播組的成員，如圖1-3中的HostA和HostC。組播組中的成員是動態的，主機可以在任何時刻加入或離開組播組。組播組成員可以廣泛地分布在網絡中的任何地方。
- 組播路由器：支持三層組播功能的路由器或交換機，如圖1-3中的各個Router。組播路由器不僅能夠提供組播路由功能，也能夠在與用戶連接的末梢網段上提供組播組成員的管理功能。
表1-1以收看某電視頻道的節目為例來類比IP組播中的概念。
| 順序 |
電視節目傳輸過程 |
組播方式傳輸過程 |
|---|---|---|
| 1 |
電視台向頻道內發送數據 |
組播源向組播組發送數據 |
| 2 |
觀眾打開電視機選擇到這個頻道 |
接收者主機加入該組播組 |
| 3 |
電視機播放該頻道電視節目 |
主機接收到發送給這個組的數據 |
| 4 |
觀眾可以隨時控制電視機的開關和頻道間的切換 |
主機可以動態加入或退出組播組 |
1.2.2 組播服務模型
組播服務模型的分類是針對接收者主機的，對組播源沒有區別。組播源發出的組播數據中總是以組播源自己的IP地址為報文的源地址，組播組地址為目的地址。而接收者主機接收數據時可以對源進行選擇，因此產生了ASM（Any-Source Multicast）和SSM（Source-Specific Multicast）兩種服務模型。這兩種服務模型使用不同的組播組地址范圍。
ASM模型
ASM模型僅針對組地址提供組播分發。一個組播組地址作為一個網絡服務的集合，任何源發布到該組地址的數據得到同樣的服務。接收者主機加入組播組以后可以接收到任意源發送到該組的數據。
為了提高安全性，可以在路由器上配置針對組播源的過濾策略，允許或禁止來自某些組播源的報文通過。最終從接收者角度看，數據是經過篩選的。
ASM模型要求組地址必須整個組播網絡中唯一。“唯一”指的是同一時刻一個ASM地址只能被一種組播應用使用。如果有兩種不同的應用程序使用了同一個ASM組地址發送數據，他們的接收者會同時收到來自兩個源的數據。這樣一方面會導致網絡流量擁塞，另一方面也會給接收者主機造成困擾。
SSM模型
SSM模型針對特定源和組的綁定數據流提供服務，接收者主機在加入組播組時，可以指定只接收哪些源的數據。加入組播組以后，主機只會收到指定源發送到該組的數據。
SSM模型對組地址不再要求全網唯一，只需要每個組播源保持唯一。這里的“唯一”指的是同一個源上不同的組播應用必須使用不同的SSM地址來區分。不同的源之間可以使用相同的組地址，因為SSM模型中針對每一個（源，組）信息都會生成表項。這樣一方面節省了組播組地址，另一方面也不會造成網絡擁塞。
1.2.3 組播地址
為了使組播源和組播組成員進行通信，需要提供網絡層組播，使用IP組播地址。同時，為了在本地物理網絡上實現組播信息的正確傳輸，需要提供鏈路層組播，使用組播MAC地址。組播數據傳輸時，其目的地不是一個具體的接收者，而是一個成員不確定的組，所以需要一種技術將IP組播地址映射為組播MAC地址。
IPv4組播地址
IANA（Internet Assigned Numbers Authority，互聯網編號分配委員會）將D類地址空間分配給IPv4組播使用。IPv4地址一共32位，D類地址最高4位為1110，因此地址范圍從224.0.0.0到239.255.255.255，具體分類及含義見表1-2。
| 地址范圍 |
含義 |
|---|---|
| 224.0.0.0～224.0.0.255 |
永久組地址。IANA為路由協議預留的IP地址（也稱為保留組地址），用於標識一組特定的網絡設備，供路由協議、拓撲查找等使用，不用於組播轉發。常見的永久組地址如表1-3所示。 |
| 224.0.1.0～231.255.255.255 233.0.0.0～238.255.255.255 |
ASM組播地址，全網范圍內有效。
說明：
其中，224.0.1.39和224.0.1.40是保留地址，不建議使用。 |
| 232.0.0.0～232.255.255.255 |
缺省情況下的SSM組播地址，全網范圍內有效。 |
| 239.0.0.0～239.255.255.255 |
本地管理組地址，僅在本地管理域內有效。在不同的管理域內重復使用相同的本地管理組地址不會導致沖突。 |
| 永久組地址 |
含義 |
|---|---|
| 224.0.0.0 |
不分配 |
| 224.0.0.1 |
網段內所有主機和路由器（等效於廣播地址） |
| 224.0.0.2 |
所有組播路由器 |
| 224.0.0.3 |
不分配 |
| 224.0.0.4 |
DVMRP（Distance Vector Multicast Routing Protocol，距離矢量組播路由協議）路由器 |
| 224.0.0.5 |
OSPF（Open Shortest Path First，開放最短路徑優先）路由器 |
| 224.0.0.6 |
OSPF DR（Designated Router，指定路由器） |
| 224.0.0.7 |
ST（Shared Tree，共享樹）路由器 |
| 224.0.0.8 |
ST主機 |
| 224.0.0.9 |
RIP-2（Routing Information Protocol version 2，路由信息協議版本2）路由器 |
| 224.0.0.11 |
移動代理（Mobile-Agents） |
| 224.0.0.12 |
DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）服務器/中繼代理 |
| 224.0.0.13 |
所有PIM（Protocol Independent Multicast，協議無關組播）路由器 |
| 224.0.0.14 |
RSVP（Resource Reservation Protocol，資源預留協議）封裝 |
| 224.0.0.15 |
所有CBT（Core-Based Tree，有核樹）路由器 |
| 224.0.0.16 |
指定SBM（Subnetwork Bandwidth Management，子網帶寬管理） |
| 224.0.0.17 |
所有SBM |
| 224.0.0.18 |
VRRP（Virtual Router Redundancy Protocol，虛擬路由器冗余協議） |
| 224.0.0.22 |
所有使能IGMPv3（Internet Group Management Protocol, Version 3，因特網組管理協議）的路由器 |
| 224.0.0.19 ～ 224.0.0.21 224.0.0.23 ～ 224.0.0.255 |
未指定 |
IPv6組播地址
IPv6地址長度是128位，在RFC4291中對組播地址的定義如圖1-4所示。
和IPv4組播地址相比，IPv6組播地址有了明確的Group ID字段用於標識組播組。
-
FF：最高8位為11111111，標識此地址為組播地址。即IPv6組播地址總是以FF開頭。
-
Flags字段（4位），用來標識組播地址的狀態。其含義如下：
表1-4 Flags取值及含義取值
含義
0
表示是IANA指定的常用組播地址，也叫保留組地址
1
表示是ASM范圍的組播地址
2
表示是ASM范圍的組播地址
3
表示是SSM范圍的組播地址
其他
未分配
-
Scope字段（4位）：用來標識組播組的應用范圍，例如是只包含同一本地網絡、同一站點、同一機構中的節點，還是包含全球地址空間內的任何節點。其含義如下：表1-5 Scope字段的取值及含義
取值
含義
0、3、F
保留
1
節點（或接口）本地范圍（node/interface-local scope）
2
鏈路本地范圍（link-local scope）
4
管理本地范圍（admin-local scope）
5
站點本地范圍（site-local scope）
8
機構本地范圍（organization-local scope）
E
全球范圍（global scope）
其他
未分配
- Group ID（112位）：組播組標識號。用來在由Scope字段所指定的范圍內唯一標識組播組，該標識可能是永久分配的或臨時的，這由Flags字段的T位決定。
固定的IPv6組播地址的范圍及含義如表1-6。
| 范圍 |
含義 |
|---|---|
| FF0x::/32 |
保留組地址，具體請參見表1-7。 |
| FF1x::/32（x不能是1或者2） FF2x::/32（x不能是1或者2） |
ASM組播地址，全網范圍內有效。 |
| FF3x::/32（x不能是1或者2） |
缺省的SSM組地址范圍，全網范圍內有效。 |
| 范圍 |
IPv6組播地址 |
含義 |
|---|---|---|
| 節點（或接口）本地范圍 |
FF01::1 |
所有節點（接口）地址 |
| FF01::2 |
所有路由器地址 |
|
| 鏈路本地范圍 |
FF02::1 |
所有節點地址 |
| FF02::2 |
所有路由器地址 |
|
| FF02::3 |
未定義的地址 |
|
| FF02::4 |
DVMRP路由器 |
|
| FF02::5 |
OSPF IGP Routers |
|
| FF02::6 |
OSPF IGP DR |
|
| FF02::7 |
ST路由器 |
|
| FF02::8 |
ST主機 |
|
| FF02::9 |
RIP路由器 |
|
| FF02::A |
EIGRP路由器 |
|
| FF02::B |
移動代理 |
|
| FF02::D |
所有PIM路由器 |
|
| FF02::E |
RSVP封裝 |
|
| FF02::1:1 |
Link Name |
|
| FF02::1:2 |
所有DHCP代理 |
|
| FF02::1:FFXX:XXXX |
Solicited-Node地址，XX:XXXX表示節點IPv6地址的后24位 |
|
| 站點本地范圍 |
FF05::2 |
所有路由器地址 |
| FF05::1:3 |
所有DHCP服務器 |
|
| FF05::1:4 |
所有DHCP中繼 |
|
| FF05::1:1000～FF05::1:13FF |
服務位置 |
IPv4組播MAC地址
以太網傳輸IPv4單播報文的時候，目的MAC地址使用的是接收者的MAC地址。但是在傳輸組播數據時，其目的地不再是一個具體的接收者，而是一個成員不確定的組，所以要使用IPv4組播MAC地址，即IPv4組播地址映射到鏈路層中的地址。
IANA規定，IPv4組播MAC地址的高24位為0x01005e，第25位為0，低23位為IPv4組播地址的低23位，映射關系如圖1-5所示。例如組播組地址224.0.1.1對應的組播MAC地址為01-00-5e-00-01-01。
IPv4組播地址的前4位是固定的1110，對應組播MAC地址的高25位，后28位中只有23位被映射到MAC地址，因此丟失了5位的地址信息，直接結果是有32個IPv4組播地址映射到同一MAC地址上。例如IP地址為224.0.1.1、224.128.1.1、225.0.1.1、239.128.1.1等組播組的組播MAC地址都為01-00-5e-00-01-01。網絡管理員在分配地址時必須考慮這種情況。
IPv6組播MAC地址
IPv6組播MAC地址的高16位為0x3333，低32位為IPv6組播地址的低32位。如圖1-6所示，是IPv6組播地址FF01::1111:1的MAC地址映射舉例。
1.2.4 IPv4組播協議
在IP組播傳輸模型中，發送者不關心接收者所處的位置，只要將數據發送到約定的目的地址，剩下的工作就交給網絡去完成。網絡中的組播設備必須收集接收者的信息，並按照正確的路徑實現組播報文的轉發和復制。在組播的發展過程中，形成了一套完整的協議來完成此任務。
IPv4網絡中使用的組播協議如表1-8所示。
| 協議 |
功能 |
備注 |
|---|---|---|
| 組播組管理協議IGMP（Internet Group Management Protocol） |
IGMP是負責IPv4組播成員管理的協議，運行在組播網絡中的最后一段，即三層網絡設備與用戶主機相連的網段內。IGMP協議在主機端實現組播組成員加入與離開，在上游的三層設備中實現組成員關系的維護與管理，同時支持與上層組播路由協議的信息交互。 |
到目前為止，IGMP有三個版本：IGMPv1、IGMPv2和IGMPv3。 所有IGMP版本都支持ASM模型。IGMPv3可以直接應用於SSM模型，而IGMPv1和IGMPv2則需要SSM Mapping技術的支持。 |
| 協議無關組播PIM（Protocol Independent Multicast） |
PIM作為一種IPv4網絡中的組播路由協議，主要用於將網絡中的組播數據流發送到有組播數據請求的組成員所連接的組播設備上，從而實現組播數據的路由查找與轉發。 PIM協議包括PIM-SM（Protocol Independent Multicast Sparse Mode）協議無關組播-稀疏模式和PIM-DM（Protocol Independent Multicast Dense Mode）協議無關組播－密集模式。PIM-SM適合規模較大、組成員相對比較分散的網絡；PIM-DM適合規模較小、組播組成員相對比較集中的網絡。 |
在PIM-DM模式下不需要區分ASM模型和SSM模型。
在PIM-SM模式下根據數據和協議報文中的組播地址區分ASM模型和SSM模型：
|
| 組播源發現協議MSDP（Multicast Source Discovery Protocol） |
MSDP是為了解決多個PIM-SM域之間的互連的一種域間組播協議，用來發現其他PIM-SM域內的組播源信息，將遠端域內的活動信源信息傳遞給本地域內的接收者，從而實現組播報文的跨域轉發。 |
只有PIM-SM使用ASM模型時，才需要使用MSDP。 |
| 組播邊界網關協議MBGP（MultiProtocol Border Gateway Protocol） |
MBGP實現了跨AS域的組播轉發。適用於組播源與組播接收者在不同AS域的場景。 |
- |
| IGMP Snooping |
IGMP Snooping功能可以使路由器工作在二層時，通過偵聽上游的三層設備和用戶主機之間發送的IGMP報文來建立組播數據報文的二層轉發表，管理和控制組播數據報文的轉發，進而有效抑制組播數據在二層網絡中擴散。 |
與IGMP對應，IGMP Snooping就是IGMP協議在二層設備中的延伸協議，可以通過配置IGMP Snooping的版本使路由器可以處理不同IGMP版本的報文。 |
1.2.5 IPv6組播協議
IPv6網絡中使用的組播協議如表1-9所示。
| 協議 |
功能 |
備注 |
|---|---|---|
| 組播偵聽者發現協議MLD（Multicast Listener Discovery） |
MLD是負責IPv6組播成員管理的協議，運行在組播網絡中的最后一段，即三層組播設備與用戶主機相連的網段內。MLD協議在主機端實現組播組成員加入與離開，在三層設備上實現組成員關系的維護與管理，同時支持與組播路由協議的信息交互。 |
到目前為止，MLD有兩個版本：MLDv1和MLDv2。 MLDv2版本可以直接應用於SSM模型，而MLDv1則需要通過使用SSM Mapping機制來支持SSM模型。 MLD可以理解為IGMP的IPv6版本。兩者的實現方式具有類比性，如MLDv1可以類比IGMPv2，MLDv2可以類比IGMPv3。 |
| PIM（IPv6） |
PIM（IPv6）作為一種IPv6網絡中的組播路由協議，主要用於將網絡中的組播數據流引入到有組播數據請求的組成員所連接的路由器上，從而實現組播數據流的路由查找與轉發。 PIM（IPv6）協議包括PIM-SM（IPv6）和PIM-DM（IPv6）兩種模式。PIM-SM（IPv6）適合規模較大、組成員相對比較分散的網絡；PIM-DM（IPv6）適合規模較小、組播組成員相對比較集中的網絡。 |
在PIM-DM（IPv6）模式下不需要區分ASM模型和SSM模型。
在PIM-SM（IPv6）模式下根據數據和協議報文中的組播地址區分ASM模型和SSM模型：
|
| MLD Snooping |
MLD Snooping功能可以使路由器工作在二層時，通過偵聽上游的三層設備和用戶主機之間發送的MLD報文來建立組播數據報文的IPv6二層轉發表，管理和控制組播數據報文的轉發，進而有效抑制組播數據在二層網絡中擴散。 |
MLD Snooping可以理解為IGMP Snooping的IPv6版本。 |
1.3 應用場景
介紹IP組播的應用場景。
1.3.1 在IPv4網絡中部署組播
本節介紹IPv4網絡中幾個典型的組播業務場景以及組播協議和特性在這些場景中的應用位置。
注意：
請務必根據網絡實際情況和具體的業務需求，有針對性的定制配置方案。本節僅介紹基本業務功能的部署。
說明：
部署IPv4組播業務前，首先確保網絡中IPv4單播路由正常。
單PIM域內組播
在一個小型網絡中，所有的設備和主機都在一個PIM組播域內，此時的組播業務基本部署如圖1-7所示。
| 部署協議 |
應用位置 |
目的 |
|---|---|---|
| PIM （必選） |
組播域內三層組播設備的所有接口，包括RouterA、RouterB、RouterC的所有接口。 具體配置請參見4 PIM（IPv4）配置。 |
將組播數據流從組播源Source發送到與有組播需求的用戶相連的RouterB和RouterC上。 |
| IGMP （必選） |
三層組播設備與用戶連接側接口，包括RouterB、RouterC的用戶側接口。 具體配置請參見2 IGMP配置。 |
實現組播組成員加入與離開組播組，RouterB和RouterC維護與管理組成員。 |
| IGMP Snooping （可選） |
三層組播設備與用戶主機之間的SwitchA的VLAN內。 具體配置請參見9 IGMP Snooping配置。 |
IGMP Snooping通過偵聽RouterB和HostA之間發送的IGMP報文建立組播數據報文的二層轉發表，從而管理和控制組播數據報文在二層網絡中的轉發。 |
跨PIM-SM域組播
為了便於控制和管理組播資源（組播組、組播源和組播成員），需要對組播資源在域間進行隔離，從而形成一個個隔離的PIM-SM域。如果不同的PIM-SM域之間需要組播數據互通，就要部署MSDP協議，如圖1-8所示。
說明：
PIM-SM模式在使用SSM模型的情況下不需要使用MSDP協議。
| 部署協議 |
應用位置 |
目的 |
|---|---|---|
| PIM-SM （必選） |
各PIM-SM域內三層組播設備的所有接口，包括RouterA～RouterF的所有接口。 具體配置請參見4.7.2 配置PIM-SM（IPv4）。 |
將組播數據流從組播源Source1和Source2發送到與有組播需求的用戶相連的RouterF上。PIM-SM采用接收者Host主動加入組播組、然后組播數據通過匯聚點RP發送信息到接收者的方式完成組播傳輸。 |
| IGMP （必選） |
各PIM-SM域內三層組播設備與用戶連接側接口，即RouterF的用戶側接口。 具體配置請參見2 IGMP配置。 |
實現組播組成員加入與離開組播組，RouterF維護與管理組成員。 |
| MSDP （必選） |
需要互連的各個PIM-SM域中的匯聚點RP，包括RouterC和RouterD。 具體配置請參見6 MSDP配置。 |
實現組播源信息在PIM-SM1和PIM-SM2域間傳遞，PIM-SM2中的Host可以接收到Source1的數據。 |
| IGMP Snooping （可選） |
三層組播設備與用戶主機之間的SwitchA的VLAN內。 具體配置請參見9 IGMP Snooping配置。 |
IGMP Snooping通過偵聽RouterF和Host之間發送的IGMP報文建立組播數據報文的二層轉發表，從而管理和控制組播數據報文在二層網絡中的轉發。 |
跨AS域組播
說明：
跨AS域部署MBGP協議前，首先部署AS域間的BGP功能。
| 部署協議 |
應用位置 |
目的 |
|---|---|---|
| PIM-SM （必選） |
各PIM-SM域內三層組播設備的所有接口，包括RouterA～RouterH的所有接口。 具體配置請參見4.7.2 配置PIM-SM（IPv4）。 |
將組播數據流從組播源Source1和Source2發送到與有組播需求的用戶相連的RouterB和RouterH上。PIM-SM采用接收者Host主動加入組播組、然后組播數據通過匯聚點RP發送信息到接收者的方式完成組播傳輸。 |
| IGMP （必選） |
各PIM-SM域內三層組播設備與用戶連接側接口，包括RouterB和RouterH的用戶側接口。 具體配置請參見2 IGMP配置。 |
實現組播組成員加入與離開組播組，RouterB和RouterH維護與管理組成員。 |
| MBGP （必選） |
需要互聯的各個AS域中的邊緣組播設備，包括RouterA和RouterF。 具體配置請參見配置MP-BGP。 |
實現組播源Source1和Source2與組播接收者跨AS域通過獨立於單播路由表的組播路由表進行數據傳輸。 |
| MSDP （必選） |
需要互連的各個PIM-SM域中的RP，包括RouterA、RouterD、RouterF。 具體配置請參見6 MSDP配置。 |
實現組播源信息在PIM-SM1、PIM-SM2和PIM-SM3域間傳遞。 |
1.3.2 在IPv6網絡中部署組播
本節介紹IPv6網絡中典型的組播業務場景以及組播協議的應用位置。
注意：
請務必根據網絡實際情況和具體的業務需求，有針對性的定制配置方案。本節僅介紹基本業務功能的部署。
說明：
部署IPv6組播業務前，首先確保網絡中IPv6單播路由正常。
| 部署協議 |
應用位置 |
目的 |
|---|---|---|
| PIM（IPv6） （必選） |
在組播域內三層組播設備的所有接口，包括RouterA、RouterB、RouterC的所有接口。 具體配置請參見5 PIM（IPv6）配置。 |
將組播數據流從組播源Source發送到與有組播需求的用戶相連的RouterB和RouterC上。 |
| MLD （必選） |
在三層組播設備與用戶連接側的接口，包括RouterB和RouterC的用戶側接口。 具體配置請參見3 MLD配置。 |
實現組播組成員加入與離開組播組，RouterB和RouterC維護與管理組成員。 |
| MLD Snooping （可選） |
在三層組播設備和用戶主機之間的二層設備SwitchA上。 具體配置請參見10 MLD Snooping配置。 |
MLD Snooping通過偵聽RouterB和HostA之間發送的MLD報文建立組播數據報文的二層轉發表，從而管理和控制組播數據報文在二層網絡中的轉發。 |
1 IGMP 協議
IGMP用來動態的將各個主機注冊到特定局域網中的一個組播組中。主機向本地的組播路由器發送IGMP消息來表明自己所屬的組播組。在IGMP協議中，路由器偵聽IGMP消息並周期的發出查詢，以發現某個子網上哪些組是活動的，哪些是不活動的。
IGMP消息在IP數據報內發送，用IP協議號2來標識。同時，將IP存活時間(TTL)字段值設定為1，因此IGMP信息處於本地范圍本子網內傳送並且不會被路由器轉發。
1989年，IGMP版本1(RFClll2)第一次詳細定義了IGMP規范。后來施樂公司對最早的IGMP版本1進行了大幅更新，產生了IGMP版本2(RFC2236)。到目前為止IGMP版本3規范己經稱為IETF正式標准(RFC3376)，通用的是IGMPv2。IGMPvl實現簡單，但是有離開延遲過大和選擇查詢路由器需要依賴組播路由協議的缺點，IGMPv2對此進行了改進。IGMPv3協議的主要目的是支持源特定組播，並進一步對IGMPv2進行完善。
1.1 IGMPv1協議
1.1.1 IGMPv1的工作原理
在IGMPvl中定義了基本規則、組成員查詢機制和報告機制。當某接收主機希望接收到某個組播組的數據時，它會向本地鏈路上的查詢路由器發送加入消息，通知查詢路由器本機希望申請加入的組播組;查詢路由器收到加入消息之后，把這條消息加入到查詢路由器所維護的狀態列表，同時向源發起建立組播分發樹的請求;查詢路由器在設定的周期內發起組成員查詢消息;接收主機收到查詢消息之后，會向查詢路由器發送報告消息來應答查詢，否則查詢路由器會認為不存在接受主機;主機如果想離開某個組播組，就對路由器的查詢保持沉默，經過一定時間，路由器便知道子網內沒有組成員了。
1.1.2 IGMPv1報文格式
IGMPvl報文格式如圖2-4所示，
圖2-4 IGMPv1報文格式
其主要內容包括：
（1） 版本字段表示IGMP協議的版本號，在IGMP中置為1.
（2） 類型字段，在IGMPv1中，只有兩個值:
取值為0x11，表示該報文為成員關系查詢（Membership Query），主要是由路由器使用。
取值為0x12，表示該報文為成員關系報告(Membership Report)，主要是主機使用。
（3） 校驗和字段用於數據報文的校驗。
（4） 組地址字段。當用於成員關系查詢時，本字段置為0，並被主機忽略;當用於成員關系報告時，本字段包含組播組地址。
IGMPv1報文在網絡中傳輸完整的報文格式如圖2-5：
圖2-5 在網絡中傳輸的IGMPv1報文
1.1.3 IGMPv1工作過程
在IGMPv1中，路由器利用查詢一響應過程來確定在本地子網中是否有加入某個組播組的主機存在，如果有，則這台路由器就要完成向本子網組播數據包的功能;如果沒有，則這台路由器就不必向此子網轉發組播包。路由器周期性地向子網上的所有主機發送組播成員關系查詢報文，希望加入某個組播組的主機就響應該查詢，發送一個組播成員關系報告報文到子網上，在IGMP報文的組地址地段中加入想要加入的組播組的地址。路由器接收到來自主機的成員關系報告報文后，就知道了在該子網上有主機要加入組播組，組播組地址在報文中可以獲得，接下來，路由器就會根據所使用的路由協議建立起相應的轉發狀態。
當一個子網上有多台主機想加入同一個組播組時，就可以利用報告響應抑制功能，來減少子網中的重復信息傳遞。處理流程如下:
主機接收到IGMP成員關系查詢報文后，對加入的每個組播組啟動一個倒數計時器。當計時器的值為0時，主機發送IGMP成員關系報告報文，通知路由器子網內仍有處於活動狀態的組播接收者。當計時器到達0之前，若主機接收到來自其他主機發送的同一組成員關系報告報文，那么它就停止與該計時器得到的數，重新計時，這樣，就避免了發送同一個成員關系報告報文給路由器。
如果在一個子網中有多個組播路由器，那么多個路由器都發送IGMP查詢報文是一種浪費，所以應當確定一個路由器作為查詢路由器就可以了。但是在IGMPv1中，沒有提供選舉查詢路由器的機制，而是把這一任務留給了組播路由協議。由於不同的協議使用不同的選舉機制，會造成在一個子網中出現多個查詢路由器，這也是IGMPv1的缺點之一。
但是IGMPv1的另一個缺點是缺乏顯式的離開方式。當一台主機想要離開一個組播組時，並不顯式地表示出來，而只是不再對路由器的查詢報文進行響應。當一個網段內某個組播組的最后一個成員退出后，路由器還會繼續組播這個組的數據，直到一段時間內路由器接收不到任何來自該組的成員響應，才會知道該組已經沒有接收者了，然后停止轉發該組的組播數據報文。因此，路由器中需要為子網中的每一個組維護一個計時器。當路由器接收到某台主機發送的報告報文時，就會將該組的計時器清零;當某個組的計時器超時后，就說明在本網段上已經沒有接收者，於是停止轉發該組報文。
下面是工作過程圖解：
1) 組成員加入
圖2-6 IGMPv1組成員加入
2) 查詢與響應
圖2-7 IGMPv1組成員查詢
3) 響應抑制機制
圖2-8 IGMPv1響應抑制機制
4) 組成員離開
圖2-9 IGMPv1組成員離開
1.2 IGMPv2協議
1.2.1 IGMPv2的工作原理
IGMPv1的主要缺點是離開延遲過大和選擇查詢路由器需要依賴組播路由協議進行。針對這些缺點，IGMPv2做了相關的改進。在IGMPv2中，增加了離開組的報文格式，當主機想要離開某個組播組時，不必等待路由器發出查詢報文，而是可以直接向路由器發送成員關系報告報文，這樣可以有效地縮短離開延遲。另外在IGMPv2中，還明確了查詢路由器的選舉機制。除此之外，IGMPv2的工作原理與IGMPv1基本一致
1.2.2 IGMPv2的報文格式
IGMPv2的報文格式如圖2-10所示：
圖2-10 IGMPv2報文格式
它在IGMPvl的基礎上，進行了兩處改動:一個是將v1的版本字段和類型字段進行了合並;另一個是增加了最大響應時間字段 (MaxResponseTime)。其主要內容如下:
(1)類型字段，在兼容IGMPv1的基礎上，IGMPv2中新增了兩種報文類型。
·0xll:成員關系查詢。與IGMPv1不同，IGMPv2的查詢分為兩種類型:①通用查詢 (GeneralQuery)，組地址字段置為全0，對所有的組進行組成員查詢;②特定組查詢 (GrouPpecificQuery)，針對特定組進行組成員查詢，組地址字段置為特定組的地址。
·0x12:IGMPv1成員關系報告(為了向后兼容IGMPv1)。
·0x16:IGMPv2成員關系報告。
·0xl7:離開組。
(2)最大響應時間字段，只有在成員關系查詢報文中有效，主機必須在最大響應時間到達之前發出成員關系報告報文。通過該值，路由器可以調節組成員的離開延遲。
(3)校驗和字段，與IGMPv1中的一樣。
(4)組地址地段，與IGMPv1中的基本一樣，當采用特定組查詢時，該字段存放要查詢的組播組的地址。
IGMPv2報文在網絡中傳輸完整的報文格式如圖2-11：
圖2-11 在網絡中傳輸的IGMPv2報文格式
1.2.3 IGMPv2工作過程
查詢一響應過程與IGMPv1基本相同，但是有兩點改進:①增加了特定組查詢，特定組查詢的目的是為了讓路由器知道一個特定組在子網內是否還有組成員，以便判斷是否還需要轉發該組的數據報文;②IGMPv2的成員關系報告的類型代碼不一樣。
IGMPv2的組成員加入與 IGMPv1中的完全一樣。IGMPv2離開過程與IGMPv1相比有了較大的改進。主機離開一個組時，需要顯式地發送一個離開報文給路由器。其過程如下:
要離開的主機發送一個離開報文給子網上所有路由器(目的地址224.0.0.2)，查詢路由器接收到離開報文后，會立即發送一個特定組查詢到子網上。如果子網上還有該組的成員，則會發回一個響應報文;如果子網上己經沒有該組的成員，則沒有主機回應，於是路由器就知道己經沒有該組成員了，就停止轉發該組的數據。
在IGMPv1中，選擇查詢路由器依賴於組播路由協議；而在IGMPv2中，明確了選擇查詢路由器的機制。其過程如下:
開始時，子網上的每個路由器都假定自己就是查詢路由器，發送一個通用查詢報文給所有主機(目的地址224.0.0.1)。每個路由器都可以接收到來自其他路由器的報文，然后進行IP地址的比較，具有最低IP地址的路由器就成為查詢路由器;非查詢路由器啟動一個計時器，無論何時接收到來自當選的查詢路由器的通用查詢報文，就將計時器復位。如果計時器超時，就認為當選的查詢路由器發生故障，轉向開始重新選擇。計時器的取值一般為查詢間隔的2倍
圖解工作過程如下：
1）組成員加入
圖2-12 IGMPv2組成員加入
2）查詢與響應
圖2-13 IGMPv2組成員查詢與響應
3）查詢器選舉
圖2-14 IGMPv2查詢路由器選擇
4）成員離開
圖2-15 IGMPv2組成員離開
1.3 IGMPv3協議
1.3.1 IGMPv3的工作原理
IGMPv3的提出，主要是為了配合源特定組播的實現，即組播組成員可以指定接收或指定不接收某些組播源的報文。這樣主機就可以有選擇性接收來自某個特定組播源的數據包，而不是被動接收該組中所有組播源的數據包。IGMPv3的這一特性，可以實現源特定組播SSM技術。源特定組播(Source Specific Multicast，SSM)是一種區別於傳統組播的新的業務模型，SSM保留了傳統PIM-SM模式中的主機顯式加入組播組的高效性，但是跳過了PIM-SM模式中的共享樹和RP規程。SSM直接建立由(S，G)標志的一個組播最短路徑樹。SSM的一個(S，G)對也被稱為一個頻道(Channel)。PIM-SSM是對傳統PIM協議的擴展，使用SSM，用戶能直接從組播源接收組播報文，需要匯聚點(RP)的幫助。
IGMPv3在IGMPvl/v2的基礎上提供了額外的源過濾組播功能(Source FilteredMulticast，SFM)。在IGMPvl/v2中，主機只根據組地址來決定加入某個組，並從任何一個源接收發給該組地址的報文。具有源過濾組播功能(SFM)的主機使用IGMPv3來表示主機所希望加入的組播組，同時還表示該主機所希望接收的組播源的地址。主機可以使用一個包括列表(Inclusion List)或一個排除列表 (Exclusion List)來表示對源地址的限制。即組播組成員可以指定接收或指定不接收某些組播源的報文。這樣主機就可以有選擇性接收來自某個特定組播源的數據包，而不是被動接收該組中所有組播源的數據包。
1.3.2 IGMPv3的報文格式
IGMPv3的報文類型有以下幾種:
0xll:成員關系查詢報文 (MembershipQeury)。
0x22:版本3成員關系報告報文(version 3 Membership Report)
0x12:版本1成員關系報告報文(version 1 Membership Report)
0x16:版本2成員關系報告報文 (version 2 Membership Report)
0x17:版本2離開報文 (version 2 LeaveGroup)。
報文類型的值填寫在報文中的類型字段。在IGMPv3中，查詢報文和報告報文格式有較大差異，需要分別描述。圖2-16為查詢報文的格式
圖2-16 IGMPv3查詢信息格式
(1)類型字段，設置為0xll，代表該報文為查詢報文。
(2)最大響應時間字段，指明了主機發出響應的最長時間。
(3)組地址字段，功能與IGMPv2一樣，可以用於通用查詢和組特定查詢。
(4)s字段，置為1時，其他路由器不對該報文進行處理。
(5)QRV字段，查詢路由器的健壯值(Querier’s RobustnessVariable)，該值影響計時器和重試次數的取值。
(6)QQIC字段，查詢路由器的查詢間隔碼(Querier’s QueryIntervalCode)，該值影響查詢路由器的查詢間隔時間，非查詢路由器按照此值更新自己的缺省值。
(7)源地址數目字段，該值表在這個報文中包含了多少個源地址。當進行通用查詢(GeneraQuery)或者組特定查詢 (GroupSpecific Query)時，該值置為0;當進行特定組和源查詢 (Group Source pecific Query，用於PIM一SSM)時，該值為源特定地址的數目。雖然該值最大可為65536，但是實際上受限於數據鏈路層的MTU，例如在以太網上，1P數據報最長為1500字節，除去IP報頭的24字節和IGMP報頭的12字節，剩余1464字節，所以最多包含366(1464/4)個源地址。
(8)源地址地段。
IGMPv3查詢信息報文在網絡中傳輸完整的報文格式如圖2-17：
圖2-17 在網絡中傳輸的IGMPv3查詢報文格式
IGMPv3報告報文的格式較為復雜，如圖2-18所示。
圖2-18 IGMPv3偵聽者報告格式
(1)類型字段，置為0x22，表示該報文為IGMPv3報告報文。
(2)組記錄數目字段，表示此報文中包含的組記錄數目。
(3)組記錄字段。包含若干個組記錄，每個組記錄長度不固定，其內容如圖2-19：
圖2-19 IGMPv3組記錄格式
①組記錄類型字段，表示該組記錄中包含的數據的類型，目前定義了六種類
型，分別是:
·MODE IS INCLUDE。表示該主機的過濾模式為INCLUDE.也就是說，后面列出的地址都是主機想要接收的組播源地址。
·MODE IS EXCLUDE。表示該主機的過濾模式為EXCLUDE，也就是說，后面列
出的地址都是主機想要拒絕的組播源地址。
·CHANGE TO INCLUDEMODE。表示該主機的過濾模式從EXCLUDE切換為INCLUDE模式。
·CHANGE TO EXCLUDEMODE。表示該主機的過濾模式從INCLUDE切換為EXCLUDE模式。
·ALLOW NEW SOURCES。表示該主機中新增的想要接收的源地址。
·BLOCK OLD SOURCES。表示從該主機中刪除的不想接收的源地址。
②輔助數據長度字段，在組記錄的最后，可以增加以4字節為單位的輔助數據，如果沒有輔助數據，則置為0。
③源地址數目字段，表示該記錄中包含了多少個組播源地址。
④組地址字段，與源地址共同表示特定源組播。
⑤源地址字段，每個長度為32bits。標志源地址，數目由源地址數目字段表示。
⑥輔助數據字段。為將來的應用預留，在IGMPv3中並不需要。一台主機在發送報告報文的時候，應當把自己的源IP地址包含在IP數據報中，當主機還沒有獲得IP地址的時候，可以使用0.0.0.0作為源IP地址，支持IGMPv3的路由器必須接收來自0.0.0.0的數據報。主機的IGMP報文的目的地址標志為224.0.0.22，代表子網中所有支持IGMPv3的路由器。
1.3.3 IGMPv3的主要改進
IGMPv3除了支持原特定組播外，其工作原理與IGMPv2相比，並沒有本質的改變，只是在某些地方做了改進和優化。以下列出了IGMPv3的主要特點和改進:
①支持源特定組播SSM;
②向后兼容IGMPvl和IGMPv2;
③主機可以定義要接收的組播源地址;
④非查詢路由器可以與查詢路由器保持參數值同步;
⑤最大響應時問從25.5s增加到53min，適合於較大的網絡;
⑥輔助數據字段為將來的應用預留了空間;
⑦關系成員報告報文發送給目的地址224.0.0.22，可以幫助二層交換機更有效地實現IGMP監聽 (IGMPSnooping)功能;
⑧報告報文中可以包含多個組記錄，可以有效地減少網絡通信量;
⑨在IGMPv3中，取消了前面版本中的響應抑制功能，主要原因是:
第一，使用響應抑制時，路由器只知道子網上是否有組成員，而不知道有幾個組成員，以及成員是哪些主機:取消響應抑制，路由器就可以記錄每一個組成員的信息，可以開發一記賬等增值服務功能。
第二，許多網橋或者二層/三層交換機在實現IGMP監聽功能時，為了避免響應抑制，一般不轉發網段問的IGMP報文。取消了響應抑制后，可以簡化這些設備的設計。
第三，取消響應抑制后，主機不必處理來自其他主機的報文，簡化了主機的實現。在查詢報文中，增加S標志位，可以提高系統的健壯性。
IGMPv3報告報文在網絡中傳輸完整的報文格式如圖2-20：
圖2-20 在網絡中傳輸的IGMPv3報告報文
2 MLD協議
IPv6的組管理協議被稱為MLD(組播監聽者發現)。1999年，MLD版本l(RFC2710)被IETF發布。2004年，MLD版本2(RFC3810)標准出台，后一個版本可以向前一個兼容。MLD協議是專門針對基於IPv6的組播組管理協議。因為MLD使用全新的ICMPv6的報文格式，所以MLD協議就是ICMPv6協議的一個子集。MLD消息使用鏈路本地IPv6源地址發送，其跳數被限制為1。MLD消息的封裝格式如圖2-21所示:
圖2-21 MLD消息封裝格式
以下分別描述MLD協議的兩個版本以及MLDSnooping，其中對於MLDSnooping的詳細描述見第三章。
2.1 MLDv1協議
2.1.1 MLDv1的工作原理
MLDvl協議是從IGMPv2協議中派生出來的，其運行機制和IGMPv2協議相同，專門用於IPv6組播群組的管理，其主要是應用於ASM模式組播路由協議的組管理工作。
對於運行MLD協議的路由器，其接口要監聽由IPv6組播地址產生的所有鏈路組播地址。路由器為它所在的每一條鏈路維護一個列表。表項有此鏈路中存在的組成員的組播地址，以及該地址相應的定時器。路由器周期性地發送通用請求 (general query)，以查詢該鏈路上是否存在某組播地址的組成員。節點收到路由器發送的常規請求后，經過隨機時延后發出組播監聽報告。這樣是為了防止所有的節點都在同一時間發出報告分組，從而造成網絡的突發性阻塞。當路由器收到鏈路上的報告分組時，如果報告地址不在路由器的列表上，則加入該項，否則計時器重新置位。如果某個地址的計時器過期，則從列表中刪除。當節點要加入一個組播組時，主動發送組播監聽報告，向路由器報告組成員的存在。節點退出組播組時，發送完成分組，刪除有關路徑。當請求狀態的路由器從鏈路上接收到一個完成消息，如果消息中的組播地址在路由器的列表上，路由器發送一個特定組播地址查詢。如果一段時延后沒有報告分組，則認為該組播地址在此鏈路上沒有組成員了。
2.1.2 MLDv1報文格式
MLDv1的報文格式如圖2-22所示：
圖2-22 MLDv1報文格式
(1)類型字段，MLDvl有如下三種報文類型：
·組播偵聽查詢消息(Type=130)，分為兩種類型:①通用查詢(GeneralQuery)，組地址字段置為全0，對所有的組進行組成員查詢;②特定組查詢(Group Pecific Query)，用於判斷一個特定的組播地址在本地鏈路上是否有組播偵聽者。
·組播偵聽報告消息(Type = 131)
·組播偵聽完成消息(Type = 132)
(2)編碼字段，初始值為0。
(3)校驗和字段。
(4)最大響應時間字段，只有在組播監聽者查詢報文中有效，主機必須在最大響應時間到達之前發出成員關系報告報文。通過該值，路由器可以調節組成員的離開延遲。
(5)組地址字段，在通用組查詢中，置為0;在特定組查詢時，該字段存放要查詢的組播組的地址。在報告和完成報文中，分別用於存放主機要加入和離開的組地址。
MLDv1報文在網絡中傳輸完整的報文格式如圖2-23：
圖2-23 在網絡中傳輸的MLDv1報文
以上這些查詢消息和應答消息報文有三種不同的報文交互方式：
第一種交互方式是由路由器發起的。路由器作為詢問者向與其相連接的所有主機發送一個一般查詢消息報文。其目的地址是FF02::1。主機收到此消息后，應答一個包含當前組播地址狀態記錄的報文消息，此報文告訴路由器此主機希望接收哪個組播組或者哪些源發來的數據。
第二種交互方式是由主機發起的。當一個主機離開一個組播組時，它就要向路由器發送組播偵聽者完成消息，該消息包括一個狀態改變一記錄。路由器收到此消息后，向其相連的鏈路上發送一個特定組播地址查詢，詢問是否還有主機加人了此特定的組。
第三種交互方式是由路由器發起的。如果在路由器的組播地址表中某一個組播地址的相關定時器超時后，仍然沒有收到主機發來的包含狀態變化記錄的組播偵聽者報告消息，路由器則向所有主機發送一個特定組查詢消息，確認該組播組是否還有組播偵聽者。
2.1.3 MLDv1工作流程
當一個網段內連接有多台路由器運行MLDvl協議時，必須選舉一台路由器作為查詢路由器，其余的自然成為非查詢路由器。選舉的機制是:地址最小的路由器當選。非查詢路由器中有一個其他查詢路由器存在計時器，當該計時器到期仍沒有收到來自查詢路由器的報文，則認為該查詢路由器失效，重新開始新的選舉。
路由器定期向子網內所有的主機廣播查詢報文(目的地址為FF02::1)，目的是獲得主機的報告報文。在路由器剛開始工作時，會快速連續地發送查詢報文，以便盡快搜集到子網內的組成員信息。
當主機接收到一個查詢報文后，就為每一個要接收的組地址啟動一個延遲定時器。定時器的值在[0，最大響應時間]之間取一個隨機數。如果查詢報文中的最大響應時間字段被置為0，則定時器立刻到期。定時器到期后，主機會發送一個報告報文給路由器，通知路由器主機想接收的組播組地址。
如果一台主機在定時器還未到期時，就收到其它主機通告路由器的報告報文，則讀取該報文的組地址，如果和自己需要通告的組地址相同，則立刻停止相應的定時器，並不再發送關於該組地址的報告報文，這樣就可以避免多台主機發送相同內容的報告報文給路由器，這種機制稱為“響應抑制”。路由器收到來自主機的報告報文后，查看其中的組地址，如果該地址未在路由器的組地址列表中，則將其添加到組地址列表中，同時為其啟動一個相應的定時器；如果該地址已經在路由器的組地址列表中，則將相應的定時器恢復最大值。如果一個組地址的定時器到期了，則說明該組地址在子網內已經沒有接收者了，路由器會將此組地址從列表中刪除。
當一台主機想要加入某個組播組時，可以不必等待路由器的查詢報文，而是直接向路由器發送報告報文。為了保障該報文的可靠性，一般會進行重傳。當一台主機想要離開某個組播組時，必須發送一個離開報文給子網內的路由器。路由器收到離開報文后，會首先查看該組地址是否在組地址列表中，如果在，則發送一個特定組地址查詢給子網內的所有主機。在一定的時間內，路由器收不到來自主機的應答，則會認為該組已經沒有接收者，於是將該組地址從列表中刪除。非查詢路由器會忽略所有的離開報文。
2.2 MLDv2協議
MLDv2從IGMPv3中發展過來，和MLDvl相比，增加了IGMPv3所具有的源過濾功能，不僅能夠支持ASM模式組播路由協議，而且還能夠支持基於IPv6的SSM模式組播路由協議。
MLDv2在MLDv1的基礎上添加了源組播 (Source Specific Multieast)的概念，主機可以組播源報告(Group-Source Report)報告感興趣的源，路由器則只轉發該鏈路上所有組成員感興趣的源所發送的報文。當主機想退出某組播源時，主機發送離開組播源報告(Group-Source Leave)，查詢者在接收到該報告后可以發送指定組播源請求，確認是否仍有組成員關心該組播源。MLDv2支持源過濾 (SourceFiltering)，因此比MLDvl具備更高的可管理性和安全性。此外MLDv2還可以與MLDvl兼容。
2.2.1 工作原理
MLD協議的目的是使每一個組播路由器知道在本地鏈路上監聽者對哪些組播地址和源地址感興趣。被MLD收集到的信息提供給在路由器上運行的任何組播路由協議，來保證組播數據包被傳遞到組播組成員。組播路由器只需要知道在一個鏈路上，至少有一個節點正在監聽從一個特定的源發給一個特定組播地址的數據包，它不需要知道有多少個這樣的節點。
MLDv2是一個不對稱的協議，它包括分離的兩部分:針對組播地址偵聽者部分(監聽組播數據包的主機或者路由器)和組播路由器部分。它為組播地址偵聽者和組播路由器定義了不同的行為。當執行“組播路由器”功能時，收集組播路由協議所需要的組播偵聽者信息;當執行“組播地址偵聽者”功能時，通知本身和其他鄰居組播路由器他的偵聽狀態。需要注意的是，一個組播路由器可以本身是一個或者多個組播地址的偵聽者，執行“組播路由器”和“組播地址偵聽者”雙重功能。
組播地址監聽者在所有的支持組播的接口上執行MLDv2協議的“組播地址監聽者”功能。
組播路由器在它的每一個接口上執行MLDv2協議的“組播路由器”功能。如果在同一個子網上具有不止一個組播路由器，組播路由器將運行查詢者選舉機制來選擇一個組播路由器來充當查詢路由器。在這個子網上的所有的組播路由器都在監聽由組播地址監聽者發送的消息，並且維護相同的組播監聽信息狀態，以便於當目前的查詢路由器不能工作時，接替查詢路由器的工作，但是只有查詢路由器在子網上能夠發送周期的消息和被觸發的查詢消息。
2.2.2 MLDv2報文格式
為了支持以上的功能，MLDv2除了兼容支持MLDvl所有的三種報文:組播偵聽查詢(MLD消息類型值為130)，包括一般查詢和特定組播地址查詢:組播偵聽報告(MLD消息類型值為131);組播偵聽完成(MLD消息類型值為 132)外，還增加了MLDv2查詢消息(一般的查詢、特定組播地址查詢，特定組播地址和源查詢)和“偵聽者報告”報文。“偵聽者報告”報文是向鄰居路由器報告當前的組播偵聽狀態，或者聲明偵聽狀態變化情況。
綜上，MLDv2消息中的所有消息如下:
n 兩種類型的MLDv2消息：
l 組播偵聽查詢(類型值=130)
l Version 2組播偵聽報告(類型值=143)
n 為保證和MLDvl的兼容，MLDv2還要支持以下兩種消息:
l Versionl組播偵聽報告(類型值=131)[RFC2710]
l versionl組播偵聽完成(類型值=132)[RFC2710]
以下詳細介紹兩種類型的MLDv2消息內容。
a) MLDv2偵聽查詢消息
組播偵聽查詢消息是在請求狀態的路由器發出來的，它用來查詢鄰居接口的偵聽狀態。它的消息格式如圖2-24所示:
圖2-24 MLDv2偵聽查詢消息
(1)編碼
被發送者初始化為0，接收者被忽略。
(2)校驗和
標准的ICMPv6校驗和;算它，它需要計算整個消息，包括IPv6的偽造報頭。為了計算它，首先把它設置為0。收到包后，要先驗證后處理。
(3)最大響應延遲
最大響應延遲編碼域指定了在發送響應報告的允許的最大延遲。實際時間叫做最大響應延遲，單位為毫秒。它們之間編碼方式如下:
l 如果最大響應延遲編碼<32768，則最大響應延遲=最大響應延遲編碼。
l 如果最大響應延遲編碼>=32768，則最大響應延遲編碼構成如圖2-25所示:
圖2-25 最大響應延遲編碼構成圖
而且最大響應延遲=(mant| 0x1000) << (exp+3)。
值比較小的最大響應延遲允許MLDv2路由器調整“離開潛伏期”(鏈路上最后一個節點停止偵聽某個特定的組播地址到路由協議認為對於這個地址沒有偵聽者的時間)。值比較大的最大響應延遲，尤其是編碼的那些，是用來調整在鏈路上的爆炸性的MLD消息的傳輸。
(4)預留
被發送者初始化為0，被接收者忽略。
(5)組播地址
對於一般的查詢消息，組播地址為0。對於特定組地址或者特定組地址和源的查詢消息來說，組播地址被設置成需要查詢的地址。
(6)S Flag(抑制路由器端的處理)
如果設置成1，則表示對於所有接收在收到查詢消息時抑制計時器更新。不過，並不抑制選舉查詢者和主機端對一類查詢消息的處理，這類查詢是路由器請求實現組播偵聽者的功能。
(7)QRV(查詢者活躍變量)
如果非0，那么查詢者活躍變量域包含查詢者使用的活躍變量值。如果活躍變量大於7(查詢者活躍變量域的最大值)，查詢者活躍變量域被設置為0。
路由器把近期收到的查詢消息中的查詢者活躍變量值設置為自己的活躍變量值，除非近期收到的查詢消息中多數的查詢者活躍變量值都為0。在多數的查詢者活躍變量值都為0的清況時，就使用缺省值，或者靜態配置特定的值。
(8)QQIC(查詢者查詢間隔編碼)
查詢者查詢間隔編碼域指定了查詢者使用的查詢間隔。實際間隔被叫作查詢者查詢間隔(QQI)，它是以秒為單位的。它們之間的轉換如下:
l 如果QQIC<128，那么QQI=QQIC。
l 如果QQIC>=128，則查詢者查詢間隔編碼構成如圖2-26所示:
圖2-26 查詢者查詢間隔編碼構成圖
而且QQI = (mant | 0x10) << (exp+ 3)。
不是當前查詢者的組播路由器把最新收到的查詢消息中的QQI值作為自己的查詢間隔時間，除非近期收到的查詢消息中多數的QQI值都為0。在都為0情況時，就使用缺省值
(9)源個數(N)
源個數(N)指出在當前處在查詢的源地址的個數。在一般查詢消息或者特定組播地址的查詢消息中源個數都為0，在特定源和組地址的查詢消息中不為0。源個數的大小由鏈路上可傳輸的最大報文決定。例如，在Ethernet上，可傳輸的最大報文是1500字節，攜帶路由警報選項的8字節的Hop-By-Hop擴展頭和40字節的IPv6頭一共48字節;源個數域前的MLD頭共28字節，這樣留給源個數域的有1424字節，所以源個數最大為89(1424/16)。
(10)源地址[i]
源地址[i]域是指向n的單播地址，n既是源個數域中的值。
(11)附加數據區
如果收到的查詢消息中的IPv6頭的負載長度域指定了需要有附加數據存在時，執行MLDv2時必須包含附加字節，用來確認收到MLD消息的校驗和，否則就忽略附加字節。當發送查詢消息時，一定不含附加消息。
(12)查詢變量
查詢消息中有三類查詢變量:
l “一般查詢消息”是查詢路由器發出的，用來查詢相連的鏈路上哪個組播地址有偵聽者。組播地址和源個數都為0。
l “特定組地址查詢消息”是查詢路由器發出的，用來查詢相連的鏈路上某個特定的組播地址是否有偵聽者。在特定組地址查詢消息中，包括希望查詢的組地址，源個數為0。
l “特定組地址和源查詢消息”是查詢路由器發出的，用來查詢相連的鏈路上某個特定的組播地址並且是來自特定的源的消息是否有偵聽者。在特定組地址和源查詢消息中，包括希望查詢的組地址，源地址列表包含關注的源地址。
(13)查詢消息源地址
所有MLDv2的查詢消息的源地址為可用的IPv6鏈路本地地址。如果節點(路由器或主機)收到的來自不明的地址的查詢消息，或者不是可用的IPv6鏈路本地地址時，它就丟棄這個消息，同時記錄警報。
(14)查詢消息目的地址
在MLDv2協議中，一般查詢消息是發給鏈路內所有節點的地址的(FF02::1)。特定組地址查詢消息和特定組地址和源查詢消息都發給希望查詢的組地址。同時節點必須接收和處理所有的IP目的地址是任意的單播或組播地址的查詢消息，這樣有利於調試。
MLDv2偵聽查詢報文在網絡中傳輸完整的報文格式如圖2-27：
圖2-27 在網絡中傳輸的MLDv2偵聽查詢報文
b) MLDv2組播偵聽報告
MLDv2組播偵聽報告是IP節點發送的，它可以用來向鄰居報告當前的偵聽狀態和以身改變接口上的組播偵聽狀態。消息格式如圖2-28所示:
圖2-28MLDv2組播偵聽報告報文
組地址記錄的消息格式如圖2-29所示：
圖2-29 組地址記錄的消息格式
(1) 類型字段，在MLDv2偵聽報告置為143。
(2) 預留，被發送者初始化為0，被接收者忽略。
(3) 校驗和
標准的ICMPv6校驗和;它需要計算整個消息，包括IPv6的偽造報頭。為了計算它，首先把它設置為0。收到包后，要先驗證后處理。
(4) 組播地址記錄個數(M)
組播地址記錄個數(M)指出在當前偵聽報告中的組播地址一記錄的個數。
(5) 組播地址記錄
組播地址記錄是由來自報告發送的接口的發送者偵聽每個組播地址的信息組成。具體記錄如下:
① 記錄類型
當前狀態報告是用來在收到查詢消息的接口上節點發出的消息。它報告接口對於每一個組地址的當前的偵聽狀態。以下兩類，如表2-2所示
表2-2 當前狀態報告類型
| 值 |
名字 |
作用 |
| 1 |
包括模式 |
指明在當前的接口上對於特定的組地址的過濾模式是包括模式的。相應的源地址域是對於特定的組地址的列表必須為非空。 |
| 2 |
排除模式 |
指明在當前的接口上對於特定的組地址的過濾模式是排除模式的。如果組地址列表為非空，則組地址域包含接口的對於特定組地址的源列表。 |
過濾模式變化報告是接點在本地的接口層對於特殊的組地址狀態變化時引起的IPv6 Multicast Listen請求而發出的報告，這種報告無論源地址是否發生變化都要發送。只有狀態變化的接口才發送這類的報告。以下兩類，如表2-3所示：
表2-3 過濾模式變化報告
| 值 |
名字 |
作用 |
| 3 |
變為包括模式 |
指明在當前的接口上對於特定的組地址的過濾模式轉變為包括模式的。如果組地址列表為非空，則組地址域包含接口的對於特定組地址的新的源列表。 |
| 4 |
變為排除模式 |
指明在當前的接口上對於特定的組地址的過濾模式轉變為排除模式的。如果組地址列表為非空，則組地址域包含接口的對於特定組地址的新的源列表。 |
源列表改變報告是節點發出的，當源列表改變，過濾模式和組地址不改變時會觸發發送此消息。以下兩類，如表2-4示
表2-4 源列表改變報告
| 值 |
名字 |
作用 |
| 5 |
允許新的源 |
指明在當前組地址記錄中的源地址域需要增加新的源。若是在包含模式下，則把這些源加入到列表中。若是在排除模式下，則把這些源從列表中刪除。 |
| 6 |
阻止舊的源 |
指明在當前組地址記錄中的源地址域需要刪除舊的源。若是在包含模式下，則把這些源刪除到列表中。若是在排除模式下，則把這些源從列表中刪除加入。 |
② 附加數據長度
附加數據長度域包含在當前在偵聽報告中的附加數據長度，單位是字(32bits)。如果為0，則表示沒有附加數據。
③ 源個數(N)
源個數(N)指出在當前在偵聽報告中的源地址記錄的個數。
④ 組播地址
組播地址域包含組播偵聽報告中有的組播地址。
⑤ 源地址[i]
源地址[i]域是指向n的單播地址，n既是源個數域中的值。
⑥ 輔助數據區
如果存在輔助數據區，那么它是用來補充說明組播地址報告的。在MLDv2協議中沒有定義間接尋址數據，所以不需要包括輔助數據區。因此設置輔助數據區為0，收到時也忽略。留出這樣一部分輔助數據區是為了以后能夠擴展MLD。
MLDv2組播偵聽報告報文在網絡中傳輸完整的報文格式如圖2-30：
圖2-30 在網絡中傳輸的MLDv2組播偵聽報告報文
2.2.3 MLDv2工作過程
MLDv2的工作過程可以分成三部分：一是偵聽者端建立“組播偵聽狀態”；二是偵聽者端和路由器端之間交換各種報文；三是路由器端建立偵聽者狀態列表。
a) 建立偵聽狀態
偵聽者根據自身的需要指定它所感興趣的組播組和組的源地址，建立自身的偵聽狀態，即加入列表或排除列表，然后主動或被動通知鄰居組播路由器它的偵聽狀態。
偵聽者執行MLDv2協議的“偵聽部分”的功能。無論節點上的接口是否在同一鏈路上.每個接口上都會執行偵聽者功能。運行在偵聽節點上層的協議或者應用通過“套接字組播狀態”函數IPv6 Multicast Listen告知接口啟用或禁用組播功能。
IPv6MuhieastListen的格式如下：
IPv6MulticastListen(套接口，接口，IPv6組播地址，過濾模式，源列表)
套接口：用來區分節點內不同的組播請求實體(如進程用程序等)。
接口：表示一個本地網絡接口.通過該接口可以啟用或禁用組播功能。
IPv6組播地址：表示請求加入的組播地址。如果一個接口接收多於一個組播的分組，IPv6Multicast Listen就會被每個組播單獨調用。
過濾模式：過濾模式分為“INCLUDEMODE”(包含模式)和“EXCLUDEMODE”(排除模式)兩種。
源列表：一個無序的地址列表，可以為空。
除了“套接字組播狀態”之外，節點必須維護或計算出每個接口的組播偵聽狀態，稱為“接口組播狀態”，表示為(IPv6組播地址，過濾模式，源列表)。“接口組播狀態”從“套接字組播狀態”推導出來。從“套接字組播狀態”導出“接口組播狀態”的一般規律如下：根據具有相同接口(IPv6組播地址)的“套接字組播狀態”記錄，推導出一個“接口組播狀態”。
(1)若有“套接字組播狀態”記錄處於排除模式，那么“接口組播狀態”的過濾模式就是“排除模式”，且“源地址列表”等於所有“排除模式”“套接字組播狀態”記錄中的源地址列表的交集，減去所有“包含模式”“套接字組播狀態”記錄中的源地址列表。
(2)若所有“套接字組播狀態”記錄都是“包含模式”，那么“接口組播狀態”就是“包含模式”，且“源地址列表”等於所有“套接字組播狀態”記錄中源地址列表的並集。
偵聽者通過上述算法可以建立起自己的“接口組播狀態”。當接口收到組播分組之后，就會根據應用或者進程的“套接字組播狀態”判斷是否將數據分組傳給上層。MLDv2報文不受源地址過濾影響，能夠被所有的主機或路由器處理。
b) 交換各種報文
偵聽者端和路由器端之間交換各種報文是協議的重要部分，在此過程中計時器會保持各個功能實體的可用性，若計時器到期會重新選舉新的偵聽者和查詢器。
同一子網內的運行MLDv2協議的路由器首先通過1P地址最小的接口為查詢接口的“查詢器選舉機制”選舉出一台“查詢器”(Querierrouter)，其余的路由自然成為非查詢路由器(Non-Querier router)。被當選為“查詢器”的接口周期性的在子網內發布一般查詢報文，觸發性地發布特定組播地址查詢報文和特定組播地址和源查詢報文，查詢鄰居接口的組播偵聽者發出的組播偵聽狀態路由器周期性地發送一般查詢報文，以查詢該鏈路上是否存在某組播地址的組成員。
在接收到收到路由器發送的一般查詢報文后，節點經過[0，最大響應時間〕之間的隨機時延后發出組播偵聽報告，通過“當前狀態報告”報告自己的“接口組播狀態”。經過隨機時延是為了防止所有的節點都在同一時間發出報告分組，從而避免網絡的突發性阻塞。當偵聽者端改變自己的接口組播狀態時，如想要加入某個組播組時或改變對某個源的接收狀態，就可以不必等待路由器的查詢報文，而是直接向路由器發送報告報文。如果節點狀態發生變化，會立刻發送並重傳“狀態變化報告”。在舊的“狀態變化報告”重傳過程中.如果又有新的狀態變化發生，這個新的狀態變化就會和原來的狀態變化合並，然后組成新的“狀態變化報告”重新發送，同時重置“重傳次數”。節點新舊狀態的變化引起的狀態變化報告算法表如表2-5所示：
表2-5狀態變化報告算法表
| 舊狀態 |
新狀態 |
狀態改變報告 |
| 包含(A) |
包含(B) |
允許(B-A)，阻止(A-B) |
| 排除(A) |
排除(B) |
允許(A-B)，阻止(B-A) |
| 包含(A) |
排除(B) |
變成排除(B) |
| 排除(A) |
包含(B) |
變成包含(B) |
在表中A和B為源地址列表，“包含”和“排除”指的是接口過濾模式，“允許”的意思是希望偵聽的新增的源地址列表，“阻止”的意思是希望不再偵聽的舊的源地址列表。
路由器收到偵聽者針對某組播的“狀態變化報告”后，查詢器會發送“組播地址指定查詢”或者“組播地址和源地址指定查詢”，以確定鏈路上是否還有其他偵聽者，如果在“查詢超時時鍾”超時之前，收到其他偵聽者的“當前狀態報告”，則重置計時器。否則將修改相應的“組播偵聽者狀態”。
c) 建立偵聽狀態列表
通過偵聽來自偵聽者的報告報文，子網內所有路由器維持相同的“組播偵聽狀態”。當路由器收到鏈路上的報告分組時，如果報告地址不在路由器的列表上，則加入該項，否則計時器重新置位。路由器為它所在的每一條鏈路維護一個列表，除了組播地址列表外，還維護着每個組播地址相關的過濾模式、源地址列表、該地址相應的源計時器等信息。如果某個計時器過期，則把相應的表項從列表中刪除。
通過收到的偵聽者報告，路由器(包括查詢器和非查詢器)可以在其接口上建立自己的“組播偵聽者狀態”信息表。與偵聽者不同，如果路由器有多個接口處於同一子網內，則只在其中一個接口建立“偵聽者狀態”信息。“偵聽者狀態”由過濾模式、過濾時鍾和源地址列表三部分組成。如果鏈路上某一組播的所有偵聽者都是“包含模式”。則接口處於該組播的“包含模式”，用INCLUDE(A)表示。其中A表示源地址列表，INCLUDE(A)稱為“包含列表”。如果“包含模式”偵聽者發送了包含特定源地址的“當前狀態報告”或者“狀態變化報告”，該源地址就會被加入到“包含列表”中。“包含列表”中每一個源地址都有“源地址時鍾”，一旦“包含模式”偵聽者發送報告證實自己在偵聽着某一特定源地址.“源地址時鍾”就會被更新。如果“包含列表”中的“源地址時鍾”由於長時間得不到更新而到期，該源地址就會從“包含列表”中刪除。這稱為“軟離開”機制。
除了“軟離開”之外，還有一種“快速離開”機制。當“包含模式”偵聽者通過“狀態變化報告”聲明不再偵聽特定源地址時，鏈路上所有的路由器就會降低該源地址的“源地址時鍾”。隨后查詢器會發出“組播地址和源地址指定查詢”，用以驗證該鏈路是否還有該源地址的偵聽者。如果“源地址時鍾”到期，該源地址就會從“包含列表”中刪除。
如果鏈路上存在處於“排除模式”的偵聽者，則接口處於該組播的“排除模式”。收到第一個“排除模式”偵聽者的報文時起，路由器就設定該組播的“過濾時鍾”。每當“排除模式”偵聽者通過“當前狀態報告”證實自己的偵聽狀態時，“過濾時鍾”被更新。當一個“包含模式”偵聽者，通過“狀態變化報告”聲明自己變為“排除模式”時，該“過濾時鍾”也會被更新。如果“過濾時鍾”過期，路由器便將偵聽者狀態切換成“包含模式”。處於“排除模式”的路由器接口。偵聽者狀態由符號Exclude(X，Y)表示，其中X表示“請求列表”，Y表示“排除列表”。除了“排除列表”之外所有的源地址發出的組播分組，都會被路由器轉發。雖然“請求列表”對於轉發分組沒有任何影響，但是路由器必須保持“請求列表”。原因如下：
(1)為了標明“包含模式”偵聽者所偵聽的源地址。當鏈路中沒有“排除模式”偵聽者時，能及時將路由器轉換成“包含模式”。這種轉換不應該中斷向該組播“包含模式”偵聽者傳輸的數據流。當路由器切換成“包含模式”時。“請求列表”中的源地址被轉移到“包含列表”中，“排除列表”被刪除。
(2)用來對原來沒有“排除”的源地址進行快速的“排除”。如果路由器接收到一個特定源地址請求的報告。源地址就會被加入到“請求列表”，源地址時鍾被賦值.隨后查詢器發出“組播地址和源地址指定查詢”。用以檢測該鏈路上是否還有對這些源地址感興趣的節點。如果源地址的時鍾就會到期時。仍沒有偵聽者響應。這時，這些源地址就會從“請求列表”移到“排除列表”。從這時起，該源地址就會被路由器阻斷[15]。