[要約] RFC 6636は、モバイルおよびワイヤレスネットワークのルーターにおけるIGMPおよびMLDの動作を調整するためのガイドラインです。このRFCの目的は、モバイルおよびワイヤレスネットワーク環境でのマルチキャスト通信の効率を向上させることです。
Internet Engineering Task Force (IETF) H. Asaeda
Request for Comments: 6636 Keio University
Category: Informational H. Liu
ISSN: 2070-1721 Q. Wu
Huawei
May 2012
Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks
モバイルおよびワイヤレスネットワークのルーター用のインターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナー探索（MLD）の動作の調整
Abstract
概要
The Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values.
インターネットグループ管理プロトコル（IGMP）とマルチキャストリスナー探索（MLD）は、ホストとマルチキャストルーターがIPマルチキャストグループメンバーシップを相互に交換するために使用するプロトコルです。このドキュメントでは、モビリティのためのIGMPv3およびMLDv2プロトコルの最適化を実現する方法について説明し、IGMPv3 / MLDv2クエリ、タイマー、およびカウンター値のチューニングのガイドラインになることを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6636.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6636で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Explicit Tracking of Membership Status ..........................3
4. Tuning IGMP/MLD Timers and Values ...............................4
4.1. Tuning the IGMP/MLD General Query Interval .................4
4.2. Tuning the IGMP/MLD Query Response Interval ................5
4.3. Tuning the Last Member Query Timer (LMQT) and Last
Listener Query Timer (LLQT) ................................6
4.4. Tuning the Startup Query Interval ..........................7
4.5. Tuning the Robustness Variable .............................7
4.6. Tuning Scenarios for Various Mobile IP Networks ............7
5. Destination Address of a Specific Query .........................8
6. Interoperability ................................................9
7. Security Considerations .........................................9
8. Acknowledgements ................................................9
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................10
Appendix A. Unicasting a General Query ............................11
The Internet Group Management Protocol (IGMP) [1] for IPv4 and the Multicast Listener Discovery (MLD) [2] protocol for IPv6 are the standard protocols for hosts to initiate joining or leaving of multicast sessions. These protocols must also be supported by multicast routers or IGMP/MLD proxies [5] that maintain multicast membership information on their downstream interfaces. Conceptually, IGMP and MLD work on both wireless and mobile networks. However, wireless access technologies operate on a shared medium or a point-to-point link with limited spectrum and bandwidth. In many wireless regimes, it is desirable to minimize multicast-related signaling to preserve the limited resources of battery-powered mobile devices and the constrained transmission capacities of the networks. The motion of a host may cause disruption of multicast service initiation and termination in the new or previous network. Slow multicast service activation following a join may incur additional delay in receiving multicast packets and degrade reception quality. Slow service termination triggered by a rapid departure of the mobile host without first leaving the group in the previous network may waste network resources.
IPv4のインターネットグループ管理プロトコル（IGMP）[1]およびIPv6のマルチキャストリスナー探索（MLD）[2]プロトコルは、ホストがマルチキャストセッションの参加または離脱を開始するための標準プロトコルです。これらのプロトコルは、ダウンストリームインターフェイスのマルチキャストメンバーシップ情報を維持するマルチキャストルーターまたはIGMP / MLDプロキシ[5]でもサポートされている必要があります。概念的には、IGMPとMLDは、ワイヤレスネットワークとモバイルネットワークの両方で機能します。ただし、ワイヤレスアクセステクノロジは、スペクトルと帯域幅が制限された共有メディアまたはポイントツーポイントリンクで動作します。多くのワイヤレス体制では、バッテリ駆動のモバイルデバイスの限られたリソースとネットワークの制約された伝送容量を維持するために、マルチキャスト関連のシグナリングを最小限に抑えることが望まれます。ホストの動きにより、新しいネットワークまたは以前のネットワークでのマルチキャストサービスの開始と終了が中断する可能性があります。結合後のマルチキャストサービスのアクティブ化が遅いと、マルチキャストパケットの受信に追加の遅延が発生し、受信品質が低下する可能性があります。最初に前のネットワークのグループを離れずにモバイルホストの急速な離脱によって引き起こされる遅いサービスの終了は、ネットワークリソースを浪費する可能性があります。
When IGMP and MLD are used with mobile IP protocols, the proximity of network entities should be considered. For example, when a bidirectional tunnel is used with the mobility entities described in [6] and [7], the mobile host experiences additional latency because the round-trip time using a bidirectional tunnel between mobility entities is larger compared to the case where a host and an upstream router attach to a LAN.
IGMPおよびMLDがモバイルIPプロトコルで使用される場合、ネットワークエンティティの近接性を考慮する必要があります。たとえば、双方向トンネルが[6]と[7]で説明されているモビリティエンティティで使用されている場合、モビリティエンティティ間の双方向トンネルを使用するラウンドトリップ時間は、ホストと上流ルーターはLANに接続します。
This document describes ways to tune IGMPv3 and MLDv2 protocol behavior -- on the multicast router and proxy side -- concentrating in particular on wireless and mobile networks, including the tuning of queries and related timers. This selective optimization provides tangible benefits to mobile hosts and routers by keeping track of the membership status of downstream hosts, and of various IGMP/MLD Query types and values, in order to appropriately tune the number of response messages. This document does not make any changes to the IGMPv3 and MLDv2 protocols and only suggests optimal settings for the configurable parameters of the protocols in mobile and wireless environments.
このドキュメントでは、マルチキャストルーターとプロキシ側でIGMPv3およびMLDv2プロトコルの動作を調整する方法について説明します。クエリと関連するタイマーの調整を含め、特にワイヤレスネットワークとモバイルネットワークに集中しています。この選択的な最適化は、応答メッセージの数を適切に調整するために、ダウンストリームホストのメンバーシップステータスとさまざまなIGMP / MLDクエリのタイプと値を追跡することにより、モバイルホストとルーターに具体的なメリットをもたらします。このドキュメントでは、IGMPv3およびMLDv2プロトコルに変更を加えることはなく、モバイルおよびワイヤレス環境でのプロトコルの構成可能なパラメーターの最適な設定のみを提案しています。
In this document, "router" means both a multicast router and an IGMP/ MLD proxy.
このドキュメントでは、「ルーター」はマルチキャストルーターとIGMP / MLDプロキシの両方を意味します。
Mobile hosts use IGMP and MLD to make a request to join or leave multicast sessions. When an adjacent upstream router receives the IGMP/MLD Report messages, it recognizes the membership status on the link. To update the membership status reliably, the router sends IGMP/MLD Query messages periodically, and sends Group-Specific and/or Group-and-Source-Specific Queries when a member host reports its leave. An IGMP/MLD Query is therefore necessary to obtain up-to-date membership information, but a large number of the reply messages sent from all member hosts may cause network congestion or consume network bandwidth.
モバイルホストはIGMPおよびMLDを使用して、マルチキャストセッションへの参加または離脱を要求します。隣接するアップストリームルータはIGMP / MLDレポートメッセージを受信すると、リンクのメンバーシップステータスを認識します。メンバーシップステータスを確実に更新するために、ルーターはIGMP / MLDクエリメッセージを定期的に送信し、メンバーホストが離脱を報告したときに、グループ固有またはグループとソース固有のクエリを送信します。したがって、最新のメンバーシップ情報を取得するにはIGMP / MLDクエリが必要ですが、すべてのメンバーホストから送信された多数の応答メッセージがネットワークの輻輳を引き起こしたり、ネットワーク帯域幅を消費したりする可能性があります。
The "explicit tracking function" [8] is a possible approach to reduce the transmitted number of IGMP/MLD messages and contribute to the efficiency of mobile communications. It enables the router to keep track of the membership status of the downstream IGMPv3 or MLDv2 member hosts. That is, if a router enables the explicit tracking function, it does not always need to request transmission of a Current-State Report message from the receiver hosts, since the router implicitly recognizes the (potential) last member host when it receives the State-Change Report message reporting a leave. The router can therefore send IGMP/MLD Group-Specific and Group-and-Source-Specific Queries LMQC/LLQC times (see Section 4.3) only when it recognizes that the last member has left the network. This reduces the transmitted number of Current-State Report messages.
「明示的追跡機能」[8]は、IGMP / MLDメッセージの送信数を減らし、モバイル通信の効率化に貢献するための可能なアプローチです。これにより、ルーターはダウンストリームのIGMPv3またはMLDv2メンバーホストのメンバーシップステータスを追跡できます。つまり、ルーターが明示的な追跡機能を有効にしている場合、ルーターは状態ホストを受信したときに（潜在的な）最後のメンバーホストを暗黙的に認識するため、受信側ホストからの現在状態レポートメッセージの送信を常に要求する必要はありません。休暇を報告する変更報告メッセージ。したがって、ルーターは、最後のメンバーがネットワークを離れたことを認識した場合にのみ、IGMP / MLDグループ固有およびグループおよびソース固有のクエリLMQC / LLQC時間（セクション4.3を参照）を送信できます。これにより、送信されるCurrent-State Reportメッセージの数が減ります。
Enabling the explicit tracking function is advantageous for mobile multicast, but the function requires additional processing capability and, possibly, substantial memory for routers to store all membership status information. This resource requirement is potentially impacted, especially when a router needs to maintain a large number of receiver hosts. Therefore, this document recommends that adjacent upstream multicast routers enable the explicit tracking function for IP multicast communications on wireless and mobile networks, if they have enough resources. If operators think that their routers do not have enough resources, they may disable this function on their routers. Note that whether or not routers enable the explicit tracking function, they need to maintain downstream membership status by sending IGMPv3/MLDv2 General Query messages, as some IGMPv3/MLDv2 messages may be lost during transmission.
明示的な追跡機能を有効にすると、モバイルマルチキャストに有利になりますが、この機能には、追加の処理機能と、場合によっては、ルーターがすべてのメンバーシップステータス情報を格納するための大量のメモリが必要です。特にルーターが多数のレシーバーホストを維持する必要がある場合、このリソース要件は潜在的に影響を受けます。したがって、このドキュメントでは、隣接するアップストリームマルチキャストルーターが十分なリソースを持っている場合、ワイヤレスネットワークとモバイルネットワークでIPマルチキャスト通信の明示的な追跡機能を有効にすることを推奨しています。オペレーターがルーターに十分なリソースがないと考えた場合、ルーターのこの機能を無効にすることができます。一部のIGMPv3 / MLDv2メッセージは送信中に失われる可能性があるため、ルーターが明示的な追跡機能を有効にするかどうかにかかわらず、ルーターはIGMPv3 / MLDv2 General Queryメッセージを送信してダウンストリームメンバーシップのステータスを維持する必要があります。
IGMP and MLD are unreliable protocols; to cover the possibility of a State-Change Report being missed by one or more multicast routers, hosts retransmit the same State-Change Report messages ([Robustness Variable] - 1) more times, at intervals chosen at random from the range (0, [Unsolicited Report Interval]) [1] [2]. Although this behavior increases the protocol's robustness, it does not guarantee that the State-Change Report reaches the routers. Therefore, routers still need to refresh their downstream membership information by receiving a Current-State Report, as periodically solicited by an IGMP/MLD General Query sent in the [Query Interval] period, in order to enhance robustness of the host in case of link failures and packet loss. This procedure also supports situations where mobile hosts are powered off or moved from one network to another network managed by a different router without any notification (e.g., a leave request).
IGMPとMLDは信頼できないプロトコルです。 1つ以上のマルチキャストルーターが状態変更レポートを見逃す可能性をカバーするために、ホストは同じ状態変更レポートメッセージ（[堅牢性変数]-1）を、範囲（0、 [一方的なレポートの間隔]）[1] [2]。この動作によりプロトコルの堅牢性が向上しますが、状態変更レポートがルーターに到達することは保証されません。したがって、リンクの場合のホストの堅牢性を高めるために、[Query Interval]期間に送信されるIGMP / MLD General Queryによって定期的に要求されるように、ルーターは現在の状態レポートを受信してダウンストリームメンバーシップ情報を更新する必要があります。障害とパケット損失。この手順は、モバイルホストの電源がオフになっている場合や、通知（脱退要求など）なしで別のルーターによって管理されている別のネットワークに移動した場合にも対応しています。
The [Query Interval] is the interval between General Queries sent by the regular IGMPv3/MLDv2 querier; the default value is 125 seconds [1] [2]. By varying the [Query Interval], multicast routers can tune the number of IGMP/MLD messages on the network; larger values cause IGMP/MLD Queries to be sent less often.
[クエリ間隔]は、通常のIGMPv3 / MLDv2クエリアによって送信される一般的なクエリの間隔です。デフォルト値は125秒です[1] [2]。 [クエリ間隔]を変更することにより、マルチキャストルーターはネットワーク上のIGMP / MLDメッセージの数を調整できます。値が大きいほど、IGMP / MLDクエリの送信頻度が低くなります。
This document proposes a [Query Interval] value of 150 seconds by changing the Querier's Query Interval Code (QQIC) field in the IGMP/ MLD Query message, for the case where a router that enables the explicit tracking function potentially operates a large number of member hosts, such as more than 200 hosts on the wireless link. This longer interval value contributes to minimizing Report message traffic and battery-power consumption for mobile hosts.
このドキュメントでは、明示的な追跡機能を有効にするルーターが多数のメンバーを操作する可能性がある場合のために、IGMP / MLDクエリメッセージのクエリアのクエリ間隔コード（QQIC）フィールドを変更して、[クエリ間隔]の値を150秒にすることを提案しています。ワイヤレスリンク上の200を超えるホストなどのホスト。この長い間隔の値は、モバイルホストのレポートメッセージトラフィックとバッテリー電力消費を最小限に抑えるのに役立ちます。
On the other hand, this document also proposes a [Query Interval] value of 60 to 90 seconds for the case where a router that enables the explicit tracking function attaches to a higher-capacity wireless link. This shorter interval contributes to quick synchronization of the membership information tracked by the router but may consume battery power on mobile hosts.
一方、このドキュメントでは、明示的な追跡機能を有効にするルーターが大容量の無線リンクに接続する場合の[クエリ間隔]の値を60〜90秒にすることも提案しています。この短い間隔は、ルーターによって追跡されるメンバーシップ情報の迅速な同期に役立ちますが、モバイルホストのバッテリー電力を消費する可能性があります。
If a router does not enable the explicit tracking function, the [Query Interval] value would be its default value -- 125 seconds.
ルーターが明示的な追跡機能を有効にしていない場合、[クエリ間隔]の値はデフォルト値（125秒）になります。
In situations where Mobile IPv6 [7] is used, when the home agent implements multicast router functionality and multicast data packets are tunneled to and from the home agent, the home agent may want to increase the query interval. This happens, for example, when the home agent detects network congestion. In this case, the home agent starts forwarding queries with the default [Query Interval] value and increases the value in a gradual manner.
モバイルIPv6 [7]が使用されている状況で、ホームエージェントがマルチキャストルーター機能を実装し、マルチキャストデータパケットがホームエージェントとの間でトンネリングされる場合、ホームエージェントはクエリ間隔を増やしたい場合があります。これは、たとえば、ホームエージェントがネットワークの輻輳を検出したときに発生します。この場合、ホームエージェントはデフォルトの[クエリ間隔]値でクエリの転送を開始し、徐々に値を増やします。
The [Query Response Interval] is the Max Response Time (or Max Response Delay) used to calculate the Max Resp Code inserted into the periodic General Queries. Its default value is 10 seconds, expressed as "Max Resp Code=100" for IGMPv3 [1] and "Maximum Response Code=10000" for MLDv2 [2]. By varying the [Query Response Interval], multicast routers can tune the burstiness of IGMP/MLD messages on the network; larger values make the traffic less bursty, as the hosts' responses are spread out over a larger interval, but will increase join latency when a State-Change Report (i.e., join request) is missing.
[クエリ応答間隔]は、定期的な一般クエリに挿入される最大応答コードを計算するために使用される最大応答時間（または最大応答遅延）です。デフォルト値は10秒で、IGMPv3 [1]の場合は「Max Resp Code = 100」、MLDv2 [2]の場合は「Maximum Response Code = 10000」で表されます。 [Query Response Interval]を変更することにより、マルチキャストルーターはネットワーク上のIGMP / MLDメッセージのバースト性を調整できます。ホストの応答はより長い間隔で分散されるため、値が大きいほどトラフィックのバースト性は低くなりますが、状態変更レポート（つまり、結合要求）がない場合は結合の待ち時間が長くなります。
According to our experimental analysis, this document proposes two scenarios for tuning the [Query Response Interval] value in different wireless link conditions: one scenario is for a wireless link with lower resource capacity or a lossy link, and the other scenario is for a wireless link with enough capacity or whose condition is reliable enough for IGMP/MLD message transmission.
実験的分析によると、このドキュメントでは、さまざまなワイヤレスリンク条件で[クエリ応答間隔]値を調整するための2つのシナリオを提案します。1つはリソースキャパシティの低いワイヤレスリンク、または損失の多いリンク、もう1つはワイヤレス十分な容量のあるリンク、またはIGMP / MLDメッセージの送信に十分信頼できる状態のリンク。
Regarding the first scenario, for instance, when a multicast router attaches to a bursty IEEE 802.11b link, the router configures a longer [Query Response Interval] value, such as 10 to 20 (seconds). This configuration will reduce congestion of the Current-State Report messages on a link but may increase join latency and leave latency when the unsolicited messages (State-Change Records) are lost on the router. Note that as defined in Section 4.1.1 of [1], in IGMPv3, a Max Resp Code larger than 128 represents the exponential values and changes the granularity. For example, if one wants to set the Max Response Time to 20.0 seconds, the Max Resp Code should be expressed as "0b10001001", which is divided into "mant=0b1001" and "exp=0b000".
最初のシナリオに関しては、たとえば、マルチキャストルーターがバースト性のIEEE 802.11bリンクに接続する場合、ルーターは10〜20（秒）などの長い[クエリ応答間隔]値を構成します。この構成により、リンク上のCurrent-State Reportメッセージの輻輳が軽減されますが、ルーターで迷惑メッセージ（State-Change Records）が失われた場合、参加の待ち時間が長くなり、待ち時間が残ることがあります。 [1]のセクション4.1.1で定義されているように、IGMPv3では、128より大きい最大応答コードは指数値を表し、粒度を変更します。たとえば、最大応答時間を20.0秒に設定する場合、最大応答コードは「0b10001001」として表現する必要があり、「mant = 0b1001」と「exp = 0b000」に分割されます。
The second scenario may happen for a multicast router attaching to a wireless link having higher resource capacity or to a point-to-(multi-)point link such as an IEEE 802.16e link because IGMP/MLD messages do not seriously affect the condition of the link. The router can seek Current-State Report messages with a shorter [Query Response Interval] value, such as 5 to 10 (seconds). This configuration will contribute to (at some level) quickly discovering non-tracked member hosts and synchronizing the membership information.
2番目のシナリオは、IGMP / MLDメッセージが次の状況に深刻な影響を与えないため、リソースキャパシティの高いワイヤレスリンクまたはIEEE 802.16eリンクなどのポイントツー（マルチ）ポイントリンクに接続しているマルチキャストルーターで発生する可能性があります。リンク。ルーターは、[クエリ応答間隔]の値が5〜10（秒）などの短い現在状態レポートメッセージをシークできます。この構成は、（ある程度）追跡されていないメンバーホストをすばやく検出し、メンバーシップ情報を同期するのに役立ちます。
4.3. Tuning the Last Member Query Timer (LMQT) and Last Listener Query Timer (LLQT)
4.3. 最終メンバークエリタイマー（LMQT）および最終リスナークエリタイマー（LLQT）のチューニング
Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave latency. LMQT is represented by the Last Member Query Interval (LMQI) multiplied by the Last Member Query Count (LMQC), and LLQT is represented by the Last Listener Query Interval (LLQI) multiplied by the Last Listener Query Count (LLQC).
IGMPv3のラストメンバークエリタイマー（LMQT）とMLDv2のラストリスナークエリタイマー（LLQT）を短縮すると、脱退待ち時間を最小限に抑えることができます。 LMQTは、Last Member Query Interval（LMQI）にLast Member Query Count（LMQC）を掛けたもので表され、LLQTはLast Listener Query Interval（LLQI）にLast Listener Query Count（LLQC）を掛けて表されます。
While LMQI and LLQI are changeable, it is reasonable to use the default value (i.e., 1 second) for LMQI and LLQI in a wireless network. LMQC and LLQC, whose default value is the [Robustness Variable] value, are also tunable. Therefore, LMQC and LLQC can be set to "1" for routers that enable the explicit tracking function, and then LMQT and LLQT are set to 1 second. However, setting LMQC and LLQC to 1 increases the risk of missing the last member; LMQC and LLQC ought to be set to 1 only when network operators think that their wireless link is stable enough.
LMQIとLLQIは変更可能ですが、ワイヤレスネットワークのLMQIとLLQIにはデフォルト値（つまり1秒）を使用するのが妥当です。デフォルト値が[Robustness Variable]値であるLMQCとLLQCも調整可能です。したがって、明示的な追跡機能を有効にするルーターのLMQCとLLQCを「1」に設定すると、LMQTとLLQTが1秒に設定されます。ただし、LMQCおよびLLQCを1に設定すると、最後のメンバーが欠落するリスクが高くなります。 LMQCとLLQCは、ネットワークオペレーターがワイヤレスリンクが十分に安定していると考えている場合にのみ、1に設定する必要があります。
On the other hand, if network operators think that their wireless link is lossy (e.g., due to a large number of attached hosts or limited resources), they can set LMQC and LLQC to "2" for their routers that enable the explicit tracking function. Although bigger LMQC and LLQC values may cause longer leave latency, the risk of missing the last member will be reduced.
一方、ネットワークオペレーターは、ワイヤレスリンクに損失があると判断した場合（たとえば、接続されているホストの数が多いかリソースが限られているため）、明示的な追跡機能を有効にするルーターのLMQCとLLQCを「2」に設定できます。 。 LMQCとLLQCの値を大きくすると、脱退までの待ち時間が長くなる可能性がありますが、最後のメンバーを見逃すリスクは軽減されます。
The [Startup Query Interval] is the interval between General Queries sent by a querier on startup. The default value is 1/4 of [Query Interval]; however, a shortened value, such as 1 second, would help contribute to shortening handover delay for mobile hosts in, for example, the base solution with Proxy Mobile IPv6 (PMIPv6) [9]. Note that the [Startup Query Interval] is a static value and cannot be changed by any external signal. Therefore, operators who maintain routers and wireless links need to properly configure this value.
[Startup Query Interval]は、起動時にクエリアによって送信される一般的なクエリの間隔です。デフォルト値は[クエリ間隔]の1/4です。ただし、1秒などの短縮された値は、たとえばプロキシモバイルIPv6（PMIPv6）を使用した基本ソリューション[9]で、モバイルホストのハンドオーバー遅延を短縮するのに役立ちます。 [Startup Query Interval]は静的な値であり、外部信号によって変更できないことに注意してください。したがって、ルーターとワイヤレスリンクを維持するオペレーターは、この値を適切に構成する必要があります。
To cover the possibility of unsolicited reports being missed by multicast routers, unsolicited reports are retransmitted ([Robustness Variable] - 1) more times, at intervals chosen at random from the defined range [1] [2]. The QRV (Querier's Robustness Variable) field in the IGMP/MLD Query contains the [Robustness Variable] value used by the querier. The default [Robustness Variable] value defined in IGMPv3 [1] and MLDv2 [2] is "2".
迷惑なレポートがマルチキャストルーターで見逃される可能性をカバーするために、迷惑なレポートは、定義された範囲[1] [2]からランダムに選択された間隔で、より多く（[Robustness Variable]-1）再送信されます。 IGMP / MLDクエリのQRV（Querier's Robustness Variable）フィールドには、クエリアが使用する[Robustness Variable]値が含まれています。 IGMPv3 [1]およびMLDv2 [2]で定義されているデフォルトの[Robustness Variable]値は「2」です。
This document proposes "2" for the [Robustness Variable] value for mobility when a router attaches to a wireless link having lower resource capacity or a large number of hosts. For a router that attaches to a higher-capacity wireless link known to be reliable, retransmitting the same State-Change Report message is not required; hence, the router sets the [Robustness Variable] to "1".
このドキュメントでは、ルータがより低いリソース容量または多数のホストを持つ無線リンクに接続する場合のモビリティの[Robustness Variable]値に「2」を提案しています。信頼性が高いことがわかっている大容量の無線リンクに接続するルーターの場合、同じ状態変更レポートメッセージを再送信する必要はありません。したがって、ルータは[Robustness Variable]を「1」に設定します。
In mobile IP networks, IGMP and MLD are used with three deployment scenarios: (1) running directly between a host and access router on a wireless network, (2) running between a host and home router through a tunnel link, and (3) running between a home router and foreign router through a tunnel link.
モバイルIPネットワークでは、IGMPとMLDは3つの展開シナリオで使用されます：（1）ワイヤレスネットワーク上のホストとアクセスルーター間で直接実行、（2）トンネルリンクを介してホストとホームルーター間で実行、（3）トンネルリンクを介してホームルーターと外部ルーターの間で実行されます。
When a receiver host connects directly through a wireless link to a foreign access router or a home router, the tuning of the IGMP/MLD protocol parameters should be the same as suggested in the previous sections. The example of this scenario occurs when in PMIPv6 [6], the mobile access gateway, whose role is similar to a foreign router, acts as a multicast router or proxy.
レシーバーホストがワイヤレスリンクを介して外部アクセスルーターまたはホームルーターに直接接続する場合、IGMP / MLDプロトコルパラメーターのチューニングは、前のセクションで提案したものと同じである必要があります。このシナリオの例は、PMIPv6 [6]で、外部ルーターと同様の役割を持つモバイルアクセスゲートウェイがマルチキャストルーターまたはプロキシとして機能する場合に発生します。
The second scenario occurs when a bidirectional tunnel established between a host and home router is used to exchange IGMP/MLD messages [7] [10]. Tuning the parameters is difficult in this situation because the condition of the tunnel link is diverse and changeable. When a host is far away from the home router, the transmission delay between the two entities may be longer and the packet delivery may be more unreliable. Thus, the effects of IGMP/MLD message transmission through a tunnel link ought to be considered when parameters are set. For example, the [Query Interval] and [Query Response Interval] could be set shorter to compensate for transmission delay, and the [Robustness Variable] could be increased to compensate for possible packet loss.
2番目のシナリオは、ホストとホームルーター間に確立された双方向トンネルを使用してIGMP / MLDメッセージを交換する場合に発生します[7] [10]。この状況では、トンネルリンクの状態が多様で変更可能であるため、パラメーターの調整は困難です。ホストがホームルーターから離れていると、2つのエンティティ間の伝送遅延が長くなり、パケット配信の信頼性が低下する可能性があります。したがって、パラメータを設定するときは、トンネルリンクを介したIGMP / MLDメッセージ送信の影響を考慮する必要があります。たとえば、[クエリ間隔]と[クエリ応答間隔]を短く設定して伝送遅延を補正し、[ロバストネス変数]を大きくしてパケット損失の可能性を補正できます。
The third scenario occurs in [9], in which the mobile access gateway (i.e., foreign router) acts as the IGMP/MLD Proxy [5] in PMIPv6 [6]. Through the bidirectional tunnel established with the local mobility anchor (i.e., home router), the mobile access gateway sends summary reports of its downstream member hosts to the local mobility anchor. Apart from the distance factor, which influences the parameter setting, the [Query Response Interval] on the local mobility anchor could be set to a smaller value because the number of mobile access gateways is much smaller compared to the number of hosts, and the chance of packet burst is low for the same reason. Additionally, the power consumption due to a lower query interval is not an issue for the mobile access gateways because the mobile access gateways are usually not battery-powered.
3番目のシナリオは[9]で発生し、モバイルアクセスゲートウェイ（つまり、外部ルーター）はPMIPv6 [6]でIGMP / MLDプロキシ[5]として機能します。モバイルアクセスゲートウェイは、ローカルモビリティアンカー（つまり、ホームルーター）で確立された双方向トンネルを通じて、そのダウンストリームメンバーホストのサマリーレポートをローカルモビリティアンカーに送信します。パラメータ設定に影響する距離係数とは別に、モバイルアクセスゲートウェイの数はホストの数と比較してはるかに少ないため、ローカルモビリティアンカーの[クエリ応答間隔]の値を小さく設定できます。同じ理由でパケットバーストの割合は低くなっています。さらに、モバイルアクセスゲートウェイは通常バッテリ駆動ではないため、クエリ間隔の短縮による電力消費は、モバイルアクセスゲートウェイにとって問題ではありません。
Ideally, the IGMP/MLD querier router adjusts its parameter settings according to the actual mobile IP network conditions to benefit service performance and resource utilization. It would be desirable for a home router to determine the aforementioned timers and values according to the delay between the initiating IGMP/MLD Query and the responding IGMP/MLD Report. However, describing how these timers and values can be dynamically adjusted is out of scope for this document.
理想的には、IGMP / MLDクエリアルーターは、実際のモバイルIPネットワークの状態に応じてパラメーター設定を調整し、サービスのパフォーマンスとリソースの使用率を向上させます。ホームルーターは、開始IGMP / MLDクエリと応答するIGMP / MLDレポートの間の遅延に従って、前述のタイマーと値を決定することが望ましいでしょう。ただし、これらのタイマーと値を動的に調整する方法を説明することは、このドキュメントの範囲外です。
IGMP/MLD Group-Specific and Group-and-Source-Specific Queries defined in [1] and [2] are sent to verify whether there are hosts that desire reception of the specified group or a set of sources, or to rebuild the desired reception state for a particular group or a set of sources. These specific queries build and refresh the multicast membership state of hosts on an attached network.
[1]および[2]で定義されたIGMP / MLDグループ固有およびグループ固有およびソース固有のクエリは、指定されたグループまたはソースのセットの受信を希望するホストがあるかどうかを確認するため、または必要な再構築するために送信されます特定のグループまたはソースのセットの受信状態。これらの特定のクエリは、接続されたネットワーク上のホストのマルチキャストメンバーシップ状態を構築および更新します。
Group-Specific Queries are sent with an IP destination address equal to the multicast address of interest, as defined in [1] and [2]. Using the multicast group of interest in the specific query is preferred in this environment because hosts that do not join the multicast session do not pay attention to these specific queries, and only active member hosts that have been receiving multicast contents with the specified address reply to IGMP/MLD Reports.
[1]と[2]で定義されているように、グループ固有のクエリは、対象のマルチキャストアドレスと等しいIP宛先アドレスで送信されます。マルチキャストセッションに参加しないホストはこれらの特定のクエリに注意を払わず、指定されたアドレスでマルチキャストコンテンツを受信しているアクティブなメンバーホストのみが応答するため、この環境では特定のクエリで対象のマルチキャストグループを使用することが推奨されます。 IGMP / MLDレポート。
IGMPv3 [1] and MLDv2 [2] provide the ability for hosts to report source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can specify a channel of interest, using multicast group and source addresses in its join request. Upon its reception, the upstream router that supports IGMPv3/MLDv2 establishes the shortest-path tree toward the source without coordinating a shared tree. This function is called the source-filtering function and is required to support Source-Specific Multicast (SSM) [3].
IGMPv3 [1]およびMLDv2 [2]は、ホストがソース固有のサブスクリプションを報告する機能を提供します。 IGMPv3 / MLDv2を使用すると、モバイルホストは、参加要求でマルチキャストグループと送信元アドレスを使用して、対象のチャネルを指定できます。受信すると、IGMPv3 / MLDv2をサポートするアップストリームルータは、共有ツリーを調整することなく、送信元への最短パスツリーを確立します。この機能は送信元フィルタリング機能と呼ばれ、送信元固有のマルチキャスト（SSM）をサポートするために必要です[3]。
Recently, the Lightweight IGMPv3 (LW-IGMPv3) and Lightweight MLDv2 (LW-MLDv2) [4] protocols have been defined as the proposed standard protocols in the IETF. These protocols provide protocol simplicity for mobile hosts and routers, as they eliminate a complex state machine from the full versions of IGMPv3 and MLDv2 and promote the opportunity to implement SSM in mobile communications.
最近、軽量IGMPv3（LW-IGMPv3）および軽量MLDv2（LW-MLDv2）[4]プロトコルが、IETFで提案されている標準プロトコルとして定義されています。これらのプロトコルは、IGMPv3およびMLDv2のフルバージョンから複雑なステートマシンを排除し、モバイル通信にSSMを実装する機会を促進するため、モバイルホストおよびルーターにプロトコルの簡素化を提供します。
This document assumes that both multicast routers and mobile hosts are IGMPv3/MLDv2 capable, regardless of whether the protocols are the full or lightweight version. This document does not consider interoperability with older protocol versions. One of the reasons for this lack of interoperability with older IGMP/MLD protocols is that the explicit tracking function does not work properly with older IGMP/MLD protocols because of a report-suppression mechanism; a host would not send a pending IGMP/MLD Report if a similar report was sent by another listener on the link.
このドキュメントでは、プロトコルがフルバージョンかライトウェイトバージョンかに関係なく、マルチキャストルータとモバイルホストの両方がIGMPv3 / MLDv2対応であることを前提としています。このドキュメントでは、古いプロトコルバージョンとの相互運用性については考慮していません。この古いIGMP / MLDプロトコルとの相互運用性の欠如の理由の1つは、レポート抑制メカニズムのために、明示的な追跡機能が古いIGMP / MLDプロトコルで適切に機能しないことです。同様のレポートがリンク上の別のリスナーによって送信された場合、ホストは保留中のIGMP / MLDレポートを送信しません。
This document neither provides new functions nor modifies the standard functions defined in [1], [2], and [4]. Therefore, no additional security considerations are provided.
このドキュメントは、[1]、[2]、および[4]で定義されている新しい関数を提供することも、標準関数を変更することもありません。したがって、セキュリティに関する追加の考慮事項はありません。
Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, Imed Romdhani, Behcet Sarikaya, Stig Venaas, Jinwei Xia, and others provided many constructive and insightful comments.
Luis M. Contreras、Marshall Eubanks、Gorry Fairhurst、Dirk von Hugo、Imed Romdhani、Behcet Sarikaya、Stig Venaas、Jinwei Xiaなどが、建設的で洞察に満ちた多くのコメントを提供しました。
[1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[1] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[2] Vida、R.、Ed。、and L. Costa、Ed。、 "Multicast Listener Discovery Version 2（MLDv2）for IPv6"、RFC 3810、June 2004。
[3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[3] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、RFC 4607、2006年8月。
[4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010.
[4] Liu、H.、Cao、W。、およびH. Asaeda、「Lightweight Internet Group Management Protocol Version 3（IGMPv3）and Multicast Listener Discovery Version 2（MLDv2）Protocols」、RFC 5790、2010年2月。
[5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[5] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「Internet Group Management Protocol（IGMP）/ Multicast Listener Discovery（MLD）-Based Multicast Forwarding（ "IGMP / MLD Proxying"）」、RFC 4605、2006年8月。
[6] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[6] Gundavelli、S.、Ed。、Leunji、K.、Devarapalli、V.、Chowdhury、K.、and B. Patil、 "Proxy Mobile Ipp 1"、Rfak 2、August 2009。
[7] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[7] Perkins、C.、Ed。、Johnson、D。、およびJ. Arkko、「Mobility Support in IPv6」、RFC 6275、2011年7月。
[8] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Work in Progress, April 2012.
[8] 浅枝浩久、N。レイマン、「IGMP / MLDに基づくマルチキャストルーターの明示的なメンバーシップ追跡機能」、作業中、2012年4月。
[9] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[9] Schmidt、T.、Waehlisch、M。、およびS. Krishnan、「プロキシモバイルIPv6（PMIPv6）ドメインでのマルチキャストリスナーサポートの基本展開」、RFC 6224、2011年4月。
[10] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[10] パーキンス、C。、編、「IPv4のIPモビリティサポート、改訂」、RFC 5944、2010年11月。
This appendix describes the possible IGMP and MLD protocol extensions for further optimization in mobile and wireless environments. It might be beneficial to include the following considerations when a newer version or modification of IGMP and MLD protocols is considered in the future.
この付録では、モバイル環境とワイヤレス環境でさらに最適化するために可能なIGMPおよびMLDプロトコル拡張について説明します。将来、IGMPおよびMLDプロトコルの新しいバージョンまたは変更を検討する場合は、以下の考慮事項を含めることが有益な場合があります。
IGMPv3 and MLDv2 specifications [1] [2] explain that a host must accept and process any query whose IP Destination Address field contains any of the addresses (unicast or multicast) assigned to the interface on which the query arrives. In general, the all-hosts multicast address (224.0.0.1) or link-scope all-nodes multicast address (ff02::1) is used as the IP destination address of an IGMP/ MLD General Query. On the other hand, according to [1] and [2], a router may be able to unicast a General Query to the tracked member hosts in [Query Interval], if the router keeps track of membership information (Section 3).
IGMPv3とMLDv2の仕様[1] [2]は、ホストが、クエリが到着するインターフェイスに割り当てられたアドレス（ユニキャストまたはマルチキャスト）のいずれかを含むIP宛先アドレスフィールドのクエリを受け入れて処理する必要があることを説明しています。一般に、全ホストマルチキャストアドレス（224.0.0.1）またはリンクスコープ全ノードマルチキャストアドレス（ff02 :: 1）は、IGMP / MLD一般クエリのIP宛先アドレスとして使用されます。一方、[1]と[2]によると、ルーターがメンバーシップ情報を追跡している場合（セクション3）、ルーターは[クエリ間隔]で追跡されたメンバーホストに一般クエリをユニキャストできる可能性があります。
Unicasting an IGMP/MLD General Query would reduce the drain on the battery power of mobile hosts, as only the active hosts that have been receiving multicast contents respond to the unicast IGMP/MLD General Query messages and non-active hosts do not need to pay attention to the IGMP/MLD Query messages. This also allows the upstream router to proceed with fast leaves (or shorten leave latency) by setting LMQC/LLQC smaller because, ideally, the router can immediately converge and update the membership information.
マルチキャストコンテンツを受信しているアクティブホストのみがユニキャストIGMP / MLD一般クエリメッセージに応答し、非アクティブホストは支払う必要がないため、IGMP / MLD一般クエリをユニキャストすると、モバイルホストのバッテリー電力の浪費が減少します。 IGMP / MLDクエリメッセージに注意してください。また、理想的には、ルーターがすぐに収束してメンバーシップ情報を更新できるため、LMQC / LLQCを小さく設定することで、上流ルーターが高速脱退を続行（または脱退待ち時間を短縮）できるようになります。
However, there is a concern regarding the unicast General Query: if a multicast router sends a General Query "only" by unicast, it cannot discover potential member hosts whose join requests were lost. Since the hosts do not retransmit the same join requests (i.e., unsolicited Report messages), they lose the chance to join the channels unless the upstream router asks for membership information by sending a multicast General Query. This concern will be solved by using both unicast and multicast General Queries and configuring the [Query Interval] timer value for multicast General Query and the [Unicast Query Interval] timer value for unicast General Query. However, using two different timers for General Queries would require a protocol extension that is beyond the scope of this document. If a router does not distinguish multicast and unicast General Query Intervals, the router should only use and enable multicast General Queries.
ただし、ユニキャストの一般クエリに関して懸念があります。マルチキャストルーターが一般クエリをユニキャストで「のみ」送信した場合、参加リクエストが失われた潜在的なメンバーホストを検出できません。ホストは同じ参加要求（つまり、非送信請求レポートメッセージ）を再送信しないため、上流ルーターがマルチキャスト一般クエリを送信してメンバーシップ情報を要求しない限り、ホストはチャネルに参加する機会を失います。この問題は、ユニキャストとマルチキャストの両方の一般クエリを使用し、マルチキャスト一般クエリの[クエリ間隔]タイマー値とユニキャスト一般クエリの[ユニキャストクエリ間隔]タイマー値を構成することで解決されます。ただし、一般クエリに2つの異なるタイマーを使用するには、このドキュメントの範囲を超えるプロトコル拡張が必要になります。ルーターがマルチキャストとユニキャストの一般クエリ間隔を区別しない場合、ルーターはマルチキャスト一般クエリのみを使用して有効にする必要があります。
Also, the unicast General Query does not remove the need for the multicast General Query. The multicast General Query is necessary for updating membership information if the information is not correctly synchronized due to missing reports. Therefore, the unicast General Query should not be used for an implementation that does not allow the configuration of different query interval timers such as [Query Interval] and [Unicast Query Interval]. If a router does not distinguish these multicast and unicast General Query Intervals, the router should only use and enable multicast General Queries.
また、ユニキャストの一般クエリでは、マルチキャストの一般クエリは不要です。欠落しているレポートのために情報が正しく同期されない場合、マルチキャスト一般クエリはメンバーシップ情報を更新するために必要です。したがって、[クエリ間隔]や[ユニキャストクエリ間隔]などの異なるクエリ間隔タイマーの構成を許可しない実装では、ユニキャスト一般クエリを使用しないでください。ルーターがこれらのマルチキャストとユニキャストの一般クエリ間隔を区別しない場合、ルーターはマルチキャスト一般クエリのみを使用して有効にする必要があります。
Authors' Addresses
著者のアドレス
Hitoshi Asaeda Keio University Graduate School of Media and Governance 5322 Endo Fujisawa, Kanagawa 252-0882 Japan
ひとし あさえだ けいお うにゔぇｒしｔｙ Ｇらづあて Ｓちょおｌ おｆ めぢあ あんｄ ごゔぇｒなんせ ５３２２ えんど ふじさわ、 かながわ ２５２ー０８８２ じゃぱん
EMail: asaeda@wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~asaeda/
Hui Liu Huawei Technologies Co., Ltd. Building Q14, No. 156, Beiqing Rd. Beijing 100095 China
Hui l IU hu Aはテクノロジー株式会社の建物Q14、No。156、i青RDです。北京100095中国
EMail: helen.liu@huawei.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue Yuhua District Nanjing, Jiangsu 210012 China
Wuhu AのQはテクノロジー株式会社です。101ソフトウェアアベニューY U塗装区NaN京、江蘇210012中国
EMail: bill.wu@huawei.com