Multicast Listener Discovery (MLD) 简介
Multicast Listener Discovery（简称MLD）是从IGMPv2（Internet
Group Management Protocol version 2）衍生而来，目的是让IPv6 router有能力发现每个连接的link上的multicast
listener（聆听者），并且具体知道这些listener感兴趣的是哪些multicast地址，同时在每个link上建立个别的multicast列表。只要multicast列表发生变化，router就会透过Multicast
Routing Protocol与其它邻近的routers交换这些讯息，以确保multicast封包能适当地传送（或阻断）到multicast
listeners连接的link。（Multicast Routing Protocol不在本书的讨论范围内。）
《请注意》Router只需要知道link上哪些multicast
address有listener，不需要知道listener的身份地址，也不需要知道有多少listeners。
MLD是一个非对称的协议，它分别指定multicast
router及multicast listeners个别的行为。当router也扮演listener角色时，router会同时执行协议的两个部分，包括自己两个角色间的讯息交换。
如果一个router有多个interfaces连接到同一个link，则只需要其中一个interface扮演MLD的router角色。另一方面，如果listener有多个interfaces连接到同一个link，则每个interface都必须扮演MLD的listener角色。
注
|
《须知》每个listener可能落在internet上任何位置，multicast封包的listeners越多，则占用整个internet的带宽越巨。如何有效地管理这些multicast封包为routers首一要务。为了兼顾multicast封包流的管理以及满足客户端的实时服务需求，MLD乃基于以下2个基本原则而设计：
1.
实时处理第一个listener 当连接的link上任何multicast address出现第一个listener时，routers应该实时与邻近的routers交换信息， 尽可能迅速将listener欲接收的multicast封包流引导到此listener链接的link上。
2.
尽量减少带宽不必要的浪费 当有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列表负责转送，不做其它处理。
|
由于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）
这3种类型的message structure格式完全相同如下：
Code 域值固定设为0，接收端忽略其内容。
Checksum ICMPv6的标准checksum值。
Maximum
Response Delay 此字段只对Query
message有意义。它指定listeners回报Report message的最大延迟时间，单位为毫秒。其它类型的MLD
messages将此字段设为0，且接收封包者忽略此字段。变换此域值可让routers调谐“leave
latence（离开延迟）”，即 -- 当有个listener通知停止聆听某个multicast封包流时，router侦测此multicast封包流不存在其它listener所需要的时间（请参考章节“List of timers and default values”Last
Listener Query Interval）。此字段亦可用来调谐突发性的MLD流量（请参考“List of timers and default values”Query
Response Interval）。
Reserved 域值固定设为0，接收端忽略其内容。
Multicast
Address 在General Query messages中，此字段设为0。在Multicast-Address-Specific
Query messages中，此字段设成routers欲查询的multicast address。在Report或Done
messages中，listener利用Multicast Address字段来指明哪个Multicast
Address需要聆听或者停止聆听。
其它字段 MLD信息的长度计算方法为：IPv6表头的Payload
Length域值减去MLD信息前端的所有其它IPv6
extension headers长度。如果MLD信息的长度大于24 octets ，表示还有其它字段存在于MLD信息的后端
，这可能被MLD的未来向后兼容的新版本所定义使用。仅实现MLD版本的node发送的MLD信息长度绝不可超过24
octets，对于收到的MLD信息超过24 octets的部分也必须忽略。在所有情况下，checksum域值的计算必须涵盖整个MLD信息，而非仅仅24
octets。
Multicast Listener Query（Type 130）
Multicast Listener Query message细分2种类型：
- General Query
Querier定期发送General Query来查询link上哪些multicast地址有listener。
- 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的listener查询，其目的地址设为欲查询的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字段设为要回报的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（即FF02::2），来源地址设为发送端的link-local地址，Hop
Limit字段固定设为1。
MLD协议说明
RFC 2710定义了下列协议行为。当读者细细品味其内容后，将不禁赞叹其设计之巧妙。
n Router使用MLD
Query message来查询每个link上哪些multicast address封包有listener。Router的每个link各自维护一张multicast列表，从接收到的Report
messages讯息中的multicast address记录在multicast列表里，同时每个multicast
address配置一个定时器（此定时器的用途稍后会做解释）。请注意， router只需要知道link上哪些multicast
address有listener，不需要知道listener的身份地址，也不需要知道有多少listener。
n 如果router有多个interfaces链接到同一个link，router会固定选择其中一个interface的link-local地址为发送MLD信息的来源地址，并且将该interface设置为可接收所有的multicast
addresses。
n 每个link上的routers分成2种角色：Querier（查询者，负责发送Query
message）或Non-Querier（非查询者，不发送Query
message）。通常1个link只有1个Querier。
所有的router刚启动时会预设自己为Querier。
如果Querier接收到Query message，而且此message的IPv6来源地址的数值比自己的小，此时必须把自己切换为Non-Querier。
如果在 【Other Querier Present Interval】时间内，Non-Querier没收到任何来源地址的数值比自己小的Query
message，则把自己恢复为Querier。Non-Querier会接收到所有的MLD
messages，所以它将保持跟Querier同样的状况以及multicast列表。
n Querier定期每隔【Query
Interval】时间发送General Query，请求listener回报Report
message。为了能快速有效地查询listener的存在，Querier刚启动时第一次发送的General
Query应该以紧密的【Startup Query Interval】间隔时间重复发送，重复次数为【Startup
Query count】。
n 当node接收到General
Query时，会对每个它所聆听的multicast address分别设置不同的定时器（不包含link-local
all nodes、scope 0以及scope 1的multicast
addresses），每个定时器的时间都是从 【0，
Maximum Response Delay】区间中随机取得且内容不同。当接收到General
Query同时某些定时器正在运行中时，如果该定时器的剩余时间大于收到的General Query的Maximum
Response Delay域值，则重新随机设置该定时器，否则继续倒数原来的定时器。如果General Query的Maximum
Response Delay域值为0，则定时器设为0，立即执行定时器到期后的动作。
n 当接收到Multicast-Address-Specific
Query时，如果node是此指定的multicast
address listener，与处理General Query方式相同，对此multicast
address随机设置定时器值。只要任何的定时器到期，就会个别发送对应的Report message，且其IPv6的目的地址为定时器到期的multicast
address。如果node接收到其它node发出的Report（这代表两者希望聆听同一个multicast
address），而且与此Report相同的multicast address的定时器在运转，则停止定时器且不发送该Report。如此可避免Routers重复接收到相同的Report。
n 当router从某个link上接收到Report，如果Report的地址不在此link的multicast列表里，则添加Report的address到multicast列表里，并且设定其定时器值为【Multicast
Listener Interval】 。如果接收到的Report的address已经存在multicast列表里，则重新定时器值为【Multicast
Listener Interval】。如果multicast 列表的address的定时器到期，则表示此address不再有listener，因此将它从列表删除。
n 当node开始聆听某个multicast
address，它应该马上发送该multicast address的Report。
此时此node可能是link上该address的第一个listener，而且发送的Report有可能丢失，因此在【Unsolicited
Report Interval】时间过后，Report应该重复发送1次或2次。（例如：发出第一次的Report后，同时当做接收到该multicast
address的Multicast-Address-Specific Query，并设置适当的定时器值。）
n 当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。如果这个优化功能被实现，其默认值应该设为打开。
n 当Querier接收到Done
message，而且Querier的同一个link上的multicast列表存在这个Done
message的multicast address，Querier会发送Multicast-Address-Specific
Query， 询问link上是否还存在其它的listener。
在特定的时间内如果没收到此address的Report，则表示此address不再有任何listener，因此该address从列表中删除。
n 处于
Non-Queriery状态的router必须忽略Done信息。
n 当Non-Querier收到Multicast-Address-Specific
Query信息，并且它的定时器的设置值大于Query信息中的Maximum Response Delay域值乘上常数【Last
Listener Query Count】。此时，Non-Querier须将它的定时器的设置值更改成后者。
参考文獻
RFC 2710 Multicast Listener Discovery for IPv6
评论
发表评论