- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- BOB登陆 人才研學中心
- 關於我們
MLD是Multicast Listener Discovery Protocol（組播偵聽者發現協議）的簡稱，它用於IPv6路由器在其直連網段上發現組播偵聽者。組播偵聽者（Multicast Listener）是那些希望接收組播數據的主機節點。
路由器通過MLD協議，可以了解自己的直連網段上是否有IPv6組播組的偵聽者，並在數據庫裏做相應記錄。同時，路由器還維護與這些IPv6組播地址相關的定時器信息。
MLD路由器使用IPv6單播鏈路本地地址作為源地址發送MLD報文。MLD使用ICMPv6（Internet Control Message Protocol for IPv6，針對IPv6的互聯網控製報文協議）報文類型。所有的MLD報文被限製在本地鏈路上，跳數為1。
到目前為止，MLD有兩個版本：
l MLDv1（由RFC 2710定義），源自IGMPv2
l MLDv2（由RFC 3810定義），源自IGMPv3
所有版本的MLD協議都支持ASM（Any-Source Multicast，任意信源組播）模型；MLDv2可以直接應用於SSM（Source-Specific Multicast，指定信源組播）模型，而MLDv1則需要在MLD SSM Mapping技術的支持下才能應用於SSM模型。
MLDv1主要基於查詢和響應機製完成對IPv6組播組成員的管理。
當一個網段內有多台IPv6組播路由器時，由於它們都能從主機那裏收到MLD成員關係報告報文（Multicast Listener Report Message），因此隻需要其中一台路由器發送MLD查詢報文（Query Message）就足夠了。這就需要有一個查詢器（Querier）的選舉機製來確定由哪台路由器作為MLD查詢器，其選舉過程如下：
(1) 所有MLD路由器在初始時都認為自己是查詢器，並向本地網段內的所有主機和路由器發送MLD普遍組查詢（General Query）報文（目的地址為FF02::1）；
(2) 本地網段中的其它MLD路由器在收到該報文後，將報文的源IPv6地址與自己的接口地址作比較。通過比較，IPv6地址最小的路由器將成為查詢器，其它路由器成為非查詢器（Non-Querier）；
(3) 所有非查詢器上都會啟動一個定時器（即其它查詢器存在時間定時器Other Querier Present Timer）。在定時器超時前，如果收到了來自查詢器的MLD查詢報文，則重置該定時器；否則，就認為原查詢器失效，並發起新的查詢器選舉過程。
圖1 MLD查詢響應示意圖
如圖1所示，假設Host B與Host C想要收到發往IPv6組播組G1的IPv6組播數據，而Host A想要收到發往IPv6組播組G2的IPv6組播數據，那麼主機加入IPv6組播組以及MLD查詢器（Router B）維護IPv6組播組成員關係的基本過程如下：
(1) 主機會主動向其要加入的IPv6組播組發送MLD成員關係報告報文以聲明加入，而不必等待MLD查詢器發來的MLD查詢報文；
(2) MLD查詢器（Router B）周期性地以組播方式向本地網段內的所有主機和路由器發送普遍組查詢報文（目的地址為FF02::1）；
(3) 在收到該查詢報文後，關注G1的Host B與Host C其中之一（這取決於誰的延遲定時器先超時）——譬如Host B會首先以組播方式向G1發送MLD成員關係報告報文，以宣告其屬於G1。由於本地網段中的所有主機都能收到Host B發往G1的報告報文，因此當Host C收到該報告報文後，將不再發送同樣針對G1的報告報文，因為MLD路由器（Router A和Router B）已知道本地網段中有對G1感興趣的主機了。這個機製稱為主機上的MLD成員關係報告抑製機製，該機製有助於減少本地網段的信息流量；
(4) 與此同時，由於Host A關注的是G2，所以它仍將以組播方式向G2發送報告報文，以宣告其屬於G2；
(5) 經過以上的查詢和響應過程，MLD路由器了解到本地網段中有G1和G2的成員，於是由IPv6組播路由協議（如IPv6 PIM）生成（*，G1）和（*，G2）組播轉發項作為IPv6組播數據的轉發依據，其中的“*”代表任意IPv6組播源；
(6) 當由IPv6組播源發往G1或G2的IPv6組播數據經過組播路由到達MLD路由器時，由於MLD路由器上存在（*，G1）和（*，G2）組播轉發項，於是將該IPv6組播數據轉發到本地網段，接收者主機便能收到該IPv6組播數據了。
當一個主機離開某IPv6組播組時：
(1) 該主機向本地網段內的所有IPv6組播路由器（目的地址為FF02::2）發送離開組（Done）報文；
(2) 當查詢器收到該報文後，向該主機所聲明要離開的那個IPv6組播組發送特定組查詢（Multicast-Address-Specific Query）報文（目的地址字段和組地址字段均填充為所要查詢的IPv6組播組地址）；
(3) 如果該網段內還有該IPv6組播組的其它成員，則這些成員在收到特定組查詢報文後，會在該報文中所設定的最大響應時間（Maximum Response Delay）內發送成員關係報告報文；
(4) 如果在最大響應時間內收到了該IPv6組播組其它成員發送的成員關係報告報文，查詢器就會繼續維護該IPv6組播組的成員關係；否則，查詢器將認為該網段內已無該IPv6組播組的成員，於是不再維護這個IPv6組播組的成員關係。
MLDv2的原理與MLDv1基本相同，並新增了以下特性：
MLDv2增加了針對IPv6組播源的過濾模式（INCLUDE/EXCLUDE），使主機在加入某IPv6組播組G的同時，能夠明確要求接收或拒絕來自某特定IPv6組播源S的IPv6組播信息。當主機加入IPv6組播組時：
l 若要求隻接收來自指定IPv6組播源如S1、S2、……發來的IPv6組播信息，則其報告報文中可以標記為INCLUDE Sources（S1，S2，……）；
l 若拒絕接收來自指定IPv6組播源如S1、S2、……發來的IPv6組播信息，則其報告報文中可以標記為EXCLUDE Sources（S1，S2，……）。
如圖2所示，網絡中存在Source 1（S1）和Source 2（S2）兩個IPv6組播源，均向IPv6組播組G發送IPv6組播報文。Host B僅對從Source 1發往G的信息感興趣，而對來自Source 2的信息沒有興趣。
圖2 指定源組的IPv6組播流路經
如果主機與路由器之間運行的是MLDv1，Host B加入IPv6組播組G時無法對IPv6組播源進行選擇，因此無論Host B是否需要，來自Source 1和Source 2的IPv6組播信息都將傳遞給Host B。
當主機與路由器之間運行了MLDv2之後，Host B就可以要求隻接收來自Source 1、發往G的IPv6組播信息（S1，G），或要求拒絕來自Source 2、發往G的IPv6組播信息（S2，G），這樣就隻有來自Source 1的IPv6組播信息才能傳遞給Host B了。
運行MLDv2的組播路由器按每條直連鏈路上的組播地址（per multicast address per attached link）來保持IPv6組播組的狀態。IPv6組播組的狀態包括：
l 過濾模式：保持對INCLUDE或EXCLUDE的狀態跟蹤。
l 源列表：保持對新增或刪除IPv6組播源的跟蹤。
l 定時器：表示IPv6組播地址超時後切換到INCLUDE模式的過濾定時器、關於源記錄的源定時器等。
運行MLDv2的組播路由器通過偵聽接收者主機的狀態，記錄和維護網段上加入到源組的主機的信息。
下麵以MLDv2為例對MLD的報文類型進行介紹：
MLD查詢器通過發送MLD查詢報文來了解相鄰接口的組播偵聽狀態。MLD查詢報文的格式如圖3所示，圖中深藍色部分為MLDv1的報文格式，各字段的含義如表1所示。
圖3 MLDv2查詢報文格式
表1 MLDv2查詢報文各字段含義
字段 | 描述 |
Type = 130 | 報文類型，130代表查詢報文 |
Code | 初始化為0 |
Checksum | 標準的IPv6校驗和 |
Maximum Response Delay | 主機發送報告報文前允許的最大響應時間 |
Reserved | 保留字段，初始化為0 |
Multicast Address | l 普遍組查詢中，此字段設置為0 l 特定組或特定源組查詢中，此字段設置為待查詢的IPv6組播組地址 |
S | 標識位，表示路由器接收到查詢報文後是否對定時器更新進行抑製 |
QRV | 查詢器的健壯性變量（Querier’s Robustness Variable） |
QQIC | 查詢器發送普遍組查詢報文的查詢間隔（Querier’s Query Interval Code） |
Number of Sources | l 普遍組查詢或特定組查詢中，此字段設置為0 l 特定源組查詢中，此字段表示查詢報文中包含的源地址個數 |
Source Address( i ) | 特定源組查詢中的IPv6組播源地址（i＝1, 2, …, n，其中n表示源地址的個數） |
主機通過發送MLD報告報文來彙報當前的組播偵聽狀態。MLD報告報文的格式如圖4所示，各字段的含義如表2所示。
圖4 MLDv2報告報文格式
表2 MLDv2報告報文各字段含義
字段 | 描述 |
Type = 143 | 報文類型，143代表報告報文 |
Reserved | 保留字段，發送時設置為0，接收時忽略此值 |
Checksum | 標準的IPv6校驗和 |
Number of Multicast Address Records | IPv6組播地址記錄的個數 |
Multicast Address Record( i ) | 組播地址記錄，表示主機在接口上偵聽到的每個IPv6組播地址信息，包括記錄類型、IPv6組播地址、IPv6源地址等（i＝1, 2, …, m，其中m表示IPv6組播地址記錄的個數） |
MLD SSM Mapping通過在路由器上配置SSM靜態映射規則，從而為運行MLDv1的接收者主機提供對SSM模型的支持。
SSM模型要求在接收者主機所在的網段，路由器能夠了解主機加入IPv6組播組時所指定的IPv6組播源。如果接收者主機上運行的是MLDv2，則可以在MLDv2的報告報文中直接指定IPv6組播源的地址；如果某些接收者主機隻能運行MLDv1，則在MLDv1的報告報文中無法指定IPv6組播源的地址。這種情況下需要通過在路由器上配置MLD SSM Mapping功能，將MLDv1報告報文中所包含的（*，G）信息映射為（G，INCLUDE，（S1，S2...））信息。
在如圖5所示的IPv6 SSM網絡中，Host A、Host B和Host C上分別運行MLDv1和MLDv2。在不允許將Host A和Host B升級為MLDv2的情況下，若要為Host A和Host B也提供SSM組播服務，則需在Router A上配置MLD SSM Mapping功能。
配置完成後，當Router A收到來自主機的MLDv1報告報文時，首先檢查該報文中所攜帶的IPv6組播組地址G，然後根據檢查結果的不同分別進行處理：
(1) 如果G不在IPv6 SSM組地址範圍內，則提供ASM組播服務。
(2) 如果G在IPv6 SSM組地址範圍內：
l 若Router A上沒有G對應的MLD SSM Mapping規則，則無法提供SSM組播服務，丟棄該報文；
l 若Router A上有G對應的MLD SSM Mapping規則，則依據規則將報告報文中所包含的（*，G）信息映射為（G，INCLUDE，（S1，S2...））信息，可以提供SSM組播服務。
& 說明：
MLD SSM Mapping不對MLDv2的報告報文進行處理。
在一些簡單的樹型網絡拓撲中，邊緣設備上並不需要運行複雜的IPv6組播路由協議（如IPv6 PIM），可以通過在這些設備上配置MLD Proxying（MLD代理）功能，使其代理下遊主機來發送MLD報文及維護組成員關係，並基於該關係進行IPv6組播轉發。在上遊設備看來，配置了MLD Proxying功能的設備（稱為MLD代理設備）不再是一個IPv6 PIM鄰居，而隻是一台主機。
如圖6所示，MLD Proxying模型中定義了以下兩種接口類型：
l 上行接口：又稱代理接口，指MLD代理設備上運行MLD Proxying功能的接口，即朝向組播分發樹樹根方向的接口。由於該接口執行MLD協議的主機行為，因此也稱為主機接口（Host Interface）。
l 下行接口：指MLD代理設備上除上行接口外其它運行MLD協議的接口，即背向組播分發樹樹根方向的接口。由於該接口執行MLD協議的路由器行為，因此也稱為路由器接口（Router Interface）。
MLD代理設備上維護著一個組成員關係數據庫（Membership Database），將所有下行接口維護的組成員關係記錄都存到這個數據庫中。組成員關係記錄的結構如下：（Multicast-address，Filter-mode，Source-list），每條記錄都是各下行接口上具有相同組地址的成員關係記錄的合集。
上行接口正是依據這個數據庫來執行主機行為——當收到查詢報文時根據當前數據庫狀態響應報告報文，或者當數據庫變化時主動發送報告或離開報文；而下行接口則執行路由器行為——參與查詢器的選舉、發送查詢報文並根據報告報文維護組成員關係等。
售前谘詢
售後谘詢
人工在線谘詢
