Multicast Listener Discovery (MLD) 簡介
- 2015/05/11
- 18:44
Multicast Listener Discovery
Multicast Listener Discovery（簡稱MLD）是從IGMPv2（Internet Group Management Protocol version 2）衍生而來，目的是讓IPv6 router有能力發現每個連接的link上的multicast listener（聆聽者），並且具體知道這些聆聽者感興趣的是哪些multicast位址， 同時在每個link上建立個別的multicast listener列表。只要multicast listener列表發生變化，router就會透過Multicast Routing Protocol與其它鄰近的routers交換這些訊息，以確保multicast封包能恰當地傳送或阻斷到multicast listeners連接的link。（Multicast Routing Protocol不在本書的討論範圍內。）
MLD是一個非對稱的協議， 它分別指定multicast router及multicast listeners個別的行為。當router也扮演listener角色時， router會同時執行協議的兩個部分，包括自己兩個角色間的訊息交換。
如果一個router有多個interfaces連接到同一個link，則只需要其中一個interface扮演MLD的router角色。 另一方面，如果listener有多個interfaces連接到同一個link，則每個interface都必須扮演MLD的listener角色。
須知，multicast封包的listeners越多，則佔用整個internet的頻寬越巨，如何有效地管理這些multicast封包為routers首一要務。為了兼顧multicast封包的管理以及滿足用戶端的即時服務需求，MLD乃基於以下2個基本原則而設計：
MLD Packet Structure
MLD是ICMPv6的子協議， 也就是說，MLD是整個ICMPv6信息的子集合。MLD message封包由IPv6表頭、Hop-by-Hop Options擴充表頭及MLD message組成如下：
請注意， MLD messages的目的地位址都是使用multicast位址來完成信息交換，所以包含Hop-by-Hop Options擴充表頭是必要的。Hop-by-Hop Options擴充表頭用來告知router必須對封包做進一步處理，Router Alert Option值為0的Hop-by-Hop Options擴充表頭告知router其為MLD message，藉此可跟一般的multicast封包流區隔。一般的multicast封包不包含Hop-by-Hop Options擴充表頭，router只依據multicast routing table負責轉送，不做其它處理。
由於MLD message的交換僅限於同一個link的範圍，RFC 2710規定所有的MLD封包的IPv6來源位址必須為發送端的link-local位址，並且IPv6表頭的Hop Limit欄位必須設為1。 MLD的接收者尤其是router必須檢查這2個欄位，不符合的封包則丟棄不處理。如此可防止MLD messages流竄到別的links，造成整個MLD機制大亂。
MLD Messages
MLD message共有3種類型：
Code 欄位固定設為0。
Maximum Response Delay 欄位只對Query message有意義。它指定listener回報Report message的最大延遲時間，單位為毫秒。其它類型的MLD messages將此欄位設為0，且接收封包者忽略此欄位。
在Report或Done messages中，listener利用Multicast Address欄位來指明哪個Multicast Address需要聆聽或者停止聆聽。
Multicast Listener Query（Type 130）
Multicast Listener Query message細分2種類型：
這2種類型是藉由Multicast Address欄位值來區分： General Query設為0，Multicast-Address-Specific Query則設為欲查詢的multicast address。
在IPv6表頭中，來源位址設為發送端的link-local位址，Hop Limit欄位固定設為1。General Query須向link上所有的nodes查詢，其目的位址設為link-scope all- nodes address（即FF02::1）。 Multicast-Address-specific Query只需向此multicast address的聆聽者查詢，其目的位址設為欲查詢的multicast address。
Multicast Listener Report（Type 131）
Listeners發送Report message的時機如下：
Multicast Address欄位設為要回報的multicast address。
IPv6的目的位址設為要報告的multicast address，來源位址設為發送端的link-local位址，Hop Limit欄位固定設為1。
Multicast Listener Done（Type 132）
Node用Done message來告知routers停止聆聽指定的multicast address。
Multicast Address欄位設為要停止聆聽的multicast address。
IPv6的目的位址設為link-scope all-routers address，來源位址設為發送端的link-local位址，Hop Limit欄位固定設為1。
MLD協議說明
RFC 2710定義了下列協議行為。當讀者細細品味其內容後，將不禁讚歎其設計之巧妙。
更多相關內容請參考紙本書《IPv6通訊協定中文編譯》
參考文獻
RFC 2710 Multicast Listener Discovery for IPv6
Multicast Listener Discovery（簡稱MLD）是從IGMPv2（Internet Group Management Protocol version 2）衍生而來，目的是讓IPv6 router有能力發現每個連接的link上的multicast listener（聆聽者），並且具體知道這些聆聽者感興趣的是哪些multicast位址， 同時在每個link上建立個別的multicast listener列表。只要multicast listener列表發生變化，router就會透過Multicast Routing Protocol與其它鄰近的routers交換這些訊息，以確保multicast封包能恰當地傳送或阻斷到multicast listeners連接的link。（Multicast Routing Protocol不在本書的討論範圍內。）
MLD是一個非對稱的協議， 它分別指定multicast router及multicast listeners個別的行為。當router也扮演listener角色時， router會同時執行協議的兩個部分，包括自己兩個角色間的訊息交換。
如果一個router有多個interfaces連接到同一個link，則只需要其中一個interface扮演MLD的router角色。 另一方面，如果listener有多個interfaces連接到同一個link，則每個interface都必須扮演MLD的listener角色。
須知，multicast封包的listeners越多，則佔用整個internet的頻寬越巨，如何有效地管理這些multicast封包為routers首一要務。為了兼顧multicast封包的管理以及滿足用戶端的即時服務需求，MLD乃基於以下2個基本原則而設計：
- 即時處理新的聆聽者 當任何multicast address的第一個listener加入時， routers應該即時與鄰近的routers交換信息， 迅速將listener欲聆聽的multicast封包流引導到此listener鏈接的link上。
- 盡量減少頻寬不必要的浪費 當有listener停止聆聽某個multicast封包時， router須即時探測該listener鏈結的link上是否還有其它listener欲接收此multicast封包。 如果沒有其他listeners存在，則應該即時與鄰近的routers交換信息，盡速阻斷此mutilcast封包流到該link，減少不必要的頻寬浪費。
MLD Packet Structure
MLD是ICMPv6的子協議， 也就是說，MLD是整個ICMPv6信息的子集合。MLD message封包由IPv6表頭、Hop-by-Hop Options擴充表頭及MLD message組成如下：
請注意， MLD messages的目的地位址都是使用multicast位址來完成信息交換，所以包含Hop-by-Hop Options擴充表頭是必要的。Hop-by-Hop Options擴充表頭用來告知router必須對封包做進一步處理，Router Alert Option值為0的Hop-by-Hop Options擴充表頭告知router其為MLD message，藉此可跟一般的multicast封包流區隔。一般的multicast封包不包含Hop-by-Hop Options擴充表頭，router只依據multicast routing table負責轉送，不做其它處理。
由於MLD message的交換僅限於同一個link的範圍，RFC 2710規定所有的MLD封包的IPv6來源位址必須為發送端的link-local位址，並且IPv6表頭的Hop Limit欄位必須設為1。 MLD的接收者尤其是router必須檢查這2個欄位，不符合的封包則丟棄不處理。如此可防止MLD messages流竄到別的links，造成整個MLD機制大亂。
MLD Messages
MLD message共有3種類型：
- Multicast Listener Query（ICMPv6 Type 130）
- Multicast Listener Report（ICMPv6 Type 131）
- Multicast Listener Done（ICMPv6 Type 132）
Code 欄位固定設為0。
Maximum Response Delay 欄位只對Query message有意義。它指定listener回報Report message的最大延遲時間，單位為毫秒。其它類型的MLD messages將此欄位設為0，且接收封包者忽略此欄位。
在Report或Done messages中，listener利用Multicast Address欄位來指明哪個Multicast Address需要聆聽或者停止聆聽。
Multicast Listener Query（Type 130）
Multicast Listener Query message細分2種類型：
- General Query Querier定期發送General Query來查詢link上哪些multicast位址有聆聽者。
- Multicast-Address-Specific Query 當Querier接收到Done message時，立即發送Multicast-Address-Specific Query來查詢link上是否還有nodes聆聽同一個multicast位址。
- Multicast-Address-Specific Query 當Querier接收到Done message時，立即發送Multicast-Address-Specific Query來查詢link上是否還有nodes聆聽同一個multicast位址。
這2種類型是藉由Multicast Address欄位值來區分： General Query設為0，Multicast-Address-Specific Query則設為欲查詢的multicast address。
在IPv6表頭中，來源位址設為發送端的link-local位址，Hop Limit欄位固定設為1。General Query須向link上所有的nodes查詢，其目的位址設為link-scope all- nodes address（即FF02::1）。 Multicast-Address-specific Query只需向此multicast address的聆聽者查詢，其目的位址設為欲查詢的multicast address。
Multicast Listener Report（Type 131）
Listeners發送Report message的時機如下：
- 當接收到General Query時， 將所有聆聽的multicast addresses利用Report message個別回報給routers。
- 當接收到Multicast-Address-Specific Query messages時，listener只回報指定的multicast address。
- 當有應用程式要求接收某個multicast address時，會立即發送Report message。
- 當接收到Multicast-Address-Specific Query messages時，listener只回報指定的multicast address。
- 當有應用程式要求接收某個multicast address時，會立即發送Report message。
Multicast Address欄位設為要回報的multicast address。
IPv6的目的位址設為要報告的multicast address，來源位址設為發送端的link-local位址，Hop Limit欄位固定設為1。
Multicast Listener Done（Type 132）
Node用Done message來告知routers停止聆聽指定的multicast address。
Multicast Address欄位設為要停止聆聽的multicast address。
IPv6的目的位址設為link-scope all-routers address，來源位址設為發送端的link-local位址，Hop Limit欄位固定設為1。
MLD協議說明
RFC 2710定義了下列協議行為。當讀者細細品味其內容後，將不禁讚歎其設計之巧妙。
- Router使用MLD Query message來查詢每個link上哪些multicast address封包有聆聽者。Router的每個link各自維護一張multicast列表，從接收到的Report messages訊息中的multicast address記錄在multicast列表裡，同時每個multicast address配置一個計時器（此計時器的用途稍後會做解釋）。請注意，router只需要知道link上哪些multicast address有聆聽者，不需要知道聆聽者的身份位址，也不需要知道有多少聆聽者。
- 每個link上的routers， 分成2種角色： Querier（查詢者，發送Query message）或Non-Querier（非查詢者，不發送Query message）。通常1個link只有1個Querier。 所有的router剛啟動時會預設自己為Querier。 如果Querier接收到Query message， 而且此message的IPv6來源位址的數值比自己的小， 此時必須把自己切換為Non-Querier。如果在特定的時間內， Non-Querier沒收到任何來源位址的數值比自己小的Query message，則把自己恢復為Querier。Non-Querier會接收到所有的MLD messages，所以它將保持跟Querier同樣的狀況及multicast列表。
- Querier定期發送General Query，請求listener回報Report message。為了能快速有效地查詢listener的存在，Querier剛啟動時第一次發送的General Query應該重複發送幾次。
- 當node接收到General Query時，會對每個他所聆聽的multicast address分別設置不同的計時器，每個計時器的時間都是隨機取得且內容不同。當接收到Multicast-Address-Specific Query時，如果node是此指定的multicast address聆聽者，就會對此multicast address隨機設置計時器值。只要任何的計時器到期， 就會個別發送對應的Report message，且其IPv6的目的位址為計時器到期的multicast address。如果node接收到其它node發出的Report（這代表兩者希望聆聽同一個multicast address），而且與此Report相同的multicast address的計時器在運轉，則停止計時器且不發送該Report。如此可避免Routers重複接收到相同的Report。
- 當router從某個link上接收到Report，如果Report的位址不在此link的multicast列表裡，則添加Report的address到multicast列表裡，並且設定其計時器值為某個特定值。如果接收到的Report的address已經存在multicast列表裡，則將其計時器值重置某個特定值。如果multicast 列表的address的計時器到期，則表示此address不再有聆聽者，因此將它從列表刪除。
- 當node開始聆聽某個multicast address，它應該馬上發送該multicast address的Report。 此時此node可能是link上該address的第一個聆聽者，而且發送的Report有可能丟失，因此RFC 2710建議該Report應該重複發送1次或2次。 重複發送的方法是發出Report後， 同時當做接收到該multicast address的Multicast-Address-Specific Query，並設置適當的計時器值。
- 當node停止接收某個multicast address時，應該馬上發送Done message，其multicast address欄位設為欲停止聆聽的位址，且IPv6目的位址設為link-scope all-routers address（即FF02::2）。如果此node最近的該multicast address的Report因為接收到其它node發出Report而被抑制沒發送，則極可能有其它node仍在聆聽此multicast address。此種情況下可以選擇不發送Done message。如果這個優化功能被實現，其預設值應該設為打開。
- 當Querier接收到Done message， 而且Querier的同一個link上的multicast列表存在這個Done message的multicast address，Querier會發送Multicast-Address-Specific Query， 詢問link上是否還存在其它的聆聽者。 在特定的時間內如果沒收到此address的Report， 則表示此address不再有任何聆聽者，因此該address從列表中刪除。
更多相關內容請參考紙本書《IPv6通訊協定中文編譯》
參考文獻
RFC 2710 Multicast Listener Discovery for IPv6
