| < draft-ietf-multimob-igmp-mld-tuning-05.txt | draft-ietf-multimob-igmp-mld-tuning-06.txt > | |||
|---|---|---|---|---|
| MULTIMOB Working Group H. Asaeda | MULTIMOB Working Group H. Asaeda | |||
| Internet-Draft Keio University | Internet-Draft Keio University | |||
| Intended status: Informational H. Liu | Intended status: Informational H. Liu | |||
| Expires: September 8, 2012 Q. Wu | Expires: September 27, 2012 Q. Wu | |||
| Huawei | Huawei | |||
| March 7, 2012 | March 26, 2012 | |||
| Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless | Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless | |||
| Networks | Networks | |||
| draft-ietf-multimob-igmp-mld-tuning-05 | draft-ietf-multimob-igmp-mld-tuning-06 | |||
| Abstract | Abstract | |||
| IGMP and MLD are the protocols used by hosts and multicast routers to | IGMP and MLD are the protocols used by hosts and multicast routers to | |||
| exchange their IP multicast group memberships with each other. This | exchange their IP multicast group memberships with each other. This | |||
| document describes the ways of IGMPv3 and MLDv2 protocol optimization | document describes the ways of IGMPv3 and MLDv2 protocol optimization | |||
| for mobility, and aims to become a guideline for tuning of IGMPv3/ | for mobility, and aims to become a guideline for tuning of IGMPv3/ | |||
| MLDv2 Queries and timer and counter values. | MLDv2 Queries and timer and counter values. | |||
| Status of this Memo | Status of this Memo | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on September 8, 2012. | This Internet-Draft will expire on September 27, 2012. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2012 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 3, line 11 ¶ | skipping to change at page 3, line 11 ¶ | |||
| 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 | |||
| Appendix A. Unicasting General Query . . . . . . . . . . . . . . 11 | Appendix A. Unicasting General Query . . . . . . . . . . . . . . 11 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 1. Introduction | 1. Introduction | |||
| The Internet Group Management Protocol (IGMP) [1] for IPv4 and the | The Internet Group Management Protocol (IGMP) [1] for IPv4 and the | |||
| Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the | Multicast Listener Discovery Protocol (MLD) [2] for IPv6 are the | |||
| standard protocols for hosts to initiate joining or leaving of | standard protocols for hosts to initiate joining or leaving of | |||
| multicast sessions. These protocols must be also supported by | multicast sessions. These protocols must be also supported by | |||
| multicast routers or IGMP/MLD proxies [6] that maintain multicast | multicast routers or IGMP/MLD proxies [5] that maintain multicast | |||
| membership information on their downstream interfaces. Conceptually, | membership information on their downstream interfaces. Conceptually, | |||
| IGMP and MLD work on both wireless and mobile networks. However, | IGMP and MLD work on both wireless and mobile networks. However, | |||
| wireless access technologies operate on a shared medium or a point- | wireless access technologies operate on a shared medium or a point- | |||
| to-point link with limited spectrum and bandwidth. In many wireless | to-point link with limited spectrum and bandwidth. In many wireless | |||
| regimes, it is desirable to minimize multicast-related signaling to | regimes, it is desirable to minimize multicast-related signaling to | |||
| preserve the limited resources of battery powered mobile devices and | preserve the limited resources of battery powered mobile devices and | |||
| the constrained transmission capacities of the networks. The motion | the constrained transmission capacities of the networks. The motion | |||
| of a host may cause disruption of a multicast service initiation and | of a host may cause disruption of a multicast service initiation and | |||
| termination in the new or previous network upon its movement. Slow | termination in the new or previous network upon its movement. Slow | |||
| multicast service activation following a join may incur additional | multicast service activation following a join may incur additional | |||
| delay in receiving multicast packets and degrade reception quality. | delay in receiving multicast packets and degrade reception quality. | |||
| Slow service termination triggered by a rapid departure of the mobile | Slow service termination triggered by a rapid departure of the mobile | |||
| host without leaving the group in the previous network may waste | host without leaving the group in the previous network may waste | |||
| network resources. | network resources. | |||
| When IGMP and MLD are used with mobile IP protocols, the proximity of | When IGMP and MLD are used with mobile IP protocols, the proximity of | |||
| network entities should be considered. For example, when bi- | network entities should be considered. For example, when bi- | |||
| directional tunnel is used with the mobility entities described in | directional tunnel is used with the mobility entities described in | |||
| [7][8], the mobile host experiences additional latency, because the | [6][7], the mobile host experiences additional latency, because the | |||
| round-trip time using bi-directional tunnel between mobility entities | round-trip time using bi-directional tunnel between mobility entities | |||
| is larger comparing to the case that a host and an upstream router | is larger comparing to the case that a host and an upstream router | |||
| attach to a LAN. | attach to a LAN. | |||
| This document describes the ways of tuning the IGMPv3 and MLDv2 | This document describes the ways of tuning the IGMPv3 and MLDv2 | |||
| protocol behavior on multicast router and proxy side for wireless and | protocol behavior on multicast router and proxy side for wireless and | |||
| mobile networks, including query and related timers tuning. The | mobile networks, including query and related timers tuning. The | |||
| selective optimization that provides tangible benefits to the mobile | selective optimization that provides tangible benefits to the mobile | |||
| hosts and routers is given by keeping track of downstream hosts' | hosts and routers is given by keeping track of downstream hosts' | |||
| membership status and varying IGMP/MLD Query types and values to tune | membership status and varying IGMP/MLD Query types and values to tune | |||
| the number of responses. The proposed behavior interoperates with | the number of responses. This document does not make any changes to | |||
| the IGMPv3 and MLDv2 protocols. | the IGMPv3 and MLDv2 protocls and only suggests optimal settings for | |||
| the configurable parameters of the protocols in mobile and wireless | ||||
| environments. | ||||
| 2. Terminology | 2. Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
| document are to be interpreted as described in RFC 2119 [3]. | ||||
| In this document, "router" means both multicast router and IGMP/MLD | In this document, "router" means both multicast router and IGMP/MLD | |||
| proxy. | proxy. | |||
| 3. Explicit Tracking of Membership Status | 3. Explicit Tracking of Membership Status | |||
| Mobile hosts use IGMP and MLD to request to join or leave multicast | Mobile hosts use IGMP and MLD to request to join or leave multicast | |||
| sessions. When an adjacent upstream router receives the IGMP/MLD | sessions. When an adjacent upstream router receives the IGMP/MLD | |||
| Report messages, it recognizes the membership status on the link. To | Report messages, it recognizes the membership status on the link. To | |||
| update the membership status reliably, the router sends IGMP/MLD | update the membership status reliably, the router sends IGMP/MLD | |||
| Query messages periodically, and sends Group-Specific and/or Group- | Query messages periodically, and sends Group-Specific and/or Group- | |||
| and-Source Specific Queries when a member host reports its leave. | and-Source Specific Queries when a member host reports its leave. | |||
| IGMP/MLD Query is therefore necessary to obtain the up-to-date | IGMP/MLD Query is therefore necessary to obtain the up-to-date | |||
| membership information, but a large number of the reply messages sent | membership information, but a large number of the reply messages sent | |||
| from all member hosts MAY cause network congestion or consume network | from all member hosts may cause network congestion or consume network | |||
| bandwidth. | bandwidth. | |||
| The "explicit tracking function" [9] is the possible approach to | The "explicit tracking function" [8] is the possible approach to | |||
| reduce the transmitted number of IGMP/MLD messages and contribute to | reduce the transmitted number of IGMP/MLD messages and contribute to | |||
| the efficiency of mobile communications. It enables the router to | the efficiency of mobile communications. It enables the router to | |||
| keep track of the membership status of the downstream IGMPv3 or MLDv2 | keep track of the membership status of the downstream IGMPv3 or MLDv2 | |||
| member hosts. That is, if a router enables the explicit tracking | member hosts. That is, if a router enables the explicit tracking | |||
| function, it does not always need to ask Current-State Report | function, it does not always need to ask Current-State Report | |||
| message's transmission from the receiver hosts since the router | message's transmission from the receiver hosts since the router | |||
| implicitly recognizes the (potential) last member host when it | implicitly recognizes the (potential) last member host when it | |||
| receives the State-Change Report reporting a leave. The router can | receives the State-Change Report reporting a leave. The router can | |||
| therefore send IGMP/MLD Group-Specific and Group-and-Source Specific | therefore send IGMP/MLD Group-Specific and Group-and-Source Specific | |||
| Queries LMQC/LLQC times (see Section 4.3 for LMQC/LLQC) only when it | Queries LMQC/LLQC times (see Section 4.3 for LMQC/LLQC) only when it | |||
| skipping to change at page 4, line 41 ¶ | skipping to change at page 4, line 41 ¶ | |||
| Enabling the explicit tracking function is advantageous for mobile | Enabling the explicit tracking function is advantageous for mobile | |||
| multicast, but the function requires additional processing capability | multicast, but the function requires additional processing capability | |||
| and possibly a large memory for routers to keep all membership | and possibly a large memory for routers to keep all membership | |||
| status. Especially when a router needs to maintain a large number of | status. Especially when a router needs to maintain a large number of | |||
| receiver hosts, this resource requirement is potentially impacted. | receiver hosts, this resource requirement is potentially impacted. | |||
| Therefore, in this document it is recommended that adjacent upstream | Therefore, in this document it is recommended that adjacent upstream | |||
| multicast routers enable the explicit tracking function for IP | multicast routers enable the explicit tracking function for IP | |||
| multicast communications on wireless and mobile networks, if they | multicast communications on wireless and mobile networks, if they | |||
| have enough resources. If operators think that their routers do not | have enough resources. If operators think that their routers do not | |||
| have enough resources, they MAY disable this function on their | have enough resources, they may disable this function on their | |||
| routers. Note that whether routers enable the explicit tracking | routers. Note that whether routers enable the explicit tracking | |||
| function or not, they need to maintain downstream membership status | function or not, they need to maintain downstream membership status | |||
| by sending IGMPv3/MLDv2 General Query messages as some IGMPv3/MLDv2 | by sending IGMPv3/MLDv2 General Query messages as some IGMPv3/MLDv2 | |||
| messages MAY be lost during transmission. | messages may be lost during transmission. | |||
| 4. Tuning IGMP/MLD Timers and Values | 4. Tuning IGMP/MLD Timers and Values | |||
| 4.1. Tuning IGMP/MLD General Query Interval | 4.1. Tuning IGMP/MLD General Query Interval | |||
| IGMP and MLD are non-reliable protocols; to cover the possibility of | IGMP and MLD are non-reliable protocols; to cover the possibility of | |||
| a State-Change Report being missed by one or more multicast routers, | a State-Change Report being missed by one or more multicast routers, | |||
| "hosts retransmit the same State-Change Report messages [Robustness | "hosts retransmit the same State-Change Report messages [Robustness | |||
| Variable] - 1 more times", at intervals chosen at random from the | Variable] - 1 more times", at intervals chosen at random from the | |||
| range (0, [Unsolicited Report Interval]) [1][2]. Although this | range (0, [Unsolicited Report Interval]) [1][2]. Although this | |||
| behavior increases the protocol robustness, it does not guarantee | behavior increases the protocol robustness, it does not guarantee | |||
| skipping to change at page 5, line 39 ¶ | skipping to change at page 5, line 39 ¶ | |||
| the IGMP/MLD Query message, for the case that a router enabling the | the IGMP/MLD Query message, for the case that a router enabling the | |||
| explicit tracking function potentially operates a large number of | explicit tracking function potentially operates a large number of | |||
| member hosts such as more than 200 hosts on the wireless link. This | member hosts such as more than 200 hosts on the wireless link. This | |||
| longer interval value contributes to minimizing traffic of Report | longer interval value contributes to minimizing traffic of Report | |||
| messages and battery power consumption for mobile hosts. | messages and battery power consumption for mobile hosts. | |||
| On the other hand, this document also proposes 60 to 90 seconds for | On the other hand, this document also proposes 60 to 90 seconds for | |||
| the [Query Interval] value for the case that a router enabling the | the [Query Interval] value for the case that a router enabling the | |||
| explicit tracking function attaches to a wireless link with higher | explicit tracking function attaches to a wireless link with higher | |||
| capacity. This shorter interval contributes to quick synchronization | capacity. This shorter interval contributes to quick synchronization | |||
| of the membership information tracked by the router but MAY consume | of the membership information tracked by the router but may consume | |||
| battery power of mobile hosts. | battery power of mobile hosts. | |||
| If a router does not enable the explicit tracking function, the | If a router does not enable the explicit tracking function, the | |||
| [Query Interval] value would be its default value, 125 seconds. | [Query Interval] value would be its default value, 125 seconds. | |||
| In situations where Mobile IPv6 [8] is used, when the home agent | In situations where Mobile IPv6 [7] is used, when the home agent | |||
| implements multicast router functionality and multicast data packets | implements multicast router functionality and multicast data packets | |||
| are tunneled to and from the home agent, the home agent MAY want to | are tunneled to and from the home agent, the home agent may want to | |||
| slow down Query periodicity. It happens, for example, when the home | slow down Query periodicity. It happens, for example, when the home | |||
| agent detects network congestion. In this case, the home agent | agent detects network congestion. In this case, the home agent | |||
| starts forwarding queries with the default [Query Interval] value and | starts forwarding queries with the default [Query Interval] value and | |||
| increases the value in a gradual manner. | increases the value in a gradual manner. | |||
| 4.2. Tuning IGMP/MLD Query Response Interval | 4.2. Tuning IGMP/MLD Query Response Interval | |||
| The [Query Response Interval] is the Max Response Time (or Max | The [Query Response Interval] is the Max Response Time (or Max | |||
| Response Delay) used to calculate the Max Resp Code inserted into the | Response Delay) used to calculate the Max Resp Code inserted into the | |||
| periodic General Queries. Its default value is 10 seconds expressed | periodic General Queries. Its default value is 10 seconds expressed | |||
| skipping to change at page 6, line 29 ¶ | skipping to change at page 6, line 29 ¶ | |||
| tuning scenarios for tuning the [Query Response Interval] value in | tuning scenarios for tuning the [Query Response Interval] value in | |||
| different wireless link conditions; one scenario is for a wireless | different wireless link conditions; one scenario is for a wireless | |||
| link with a lower capacity of network resource or a lossy link, and | link with a lower capacity of network resource or a lossy link, and | |||
| the other scenario is for a wireless link with enough capacity or | the other scenario is for a wireless link with enough capacity or | |||
| reliable condition for IGMP/MLD message transmission. | reliable condition for IGMP/MLD message transmission. | |||
| Regarding the first scenario, for instance, when a multicast router | Regarding the first scenario, for instance, when a multicast router | |||
| attaches to a bursty IEEE 802.11b link, the router configures the | attaches to a bursty IEEE 802.11b link, the router configures the | |||
| longer [Query Response Interval] value, such as 10 to 20 (sec). This | longer [Query Response Interval] value, such as 10 to 20 (sec). This | |||
| configuration will reduce congestion of the Current-State Report | configuration will reduce congestion of the Current-State Report | |||
| messages on a link but MAY increase join latency and leave latency | messages on a link but may increase join latency and leave latency | |||
| when the unsolicited messages (State-Change Record) are lost on the | when the unsolicited messages (State-Change Record) are lost on the | |||
| router. | router. Note that as defined in Section 4.1.1 of [1], in IGMPv3, the | |||
| 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 | ||||
| with "0b10001001", which is divided into "mant=0b1001" and | ||||
| "exp=0b000". | ||||
| The second scenario MAY happen for a multicast router attaching to a | The second scenario may happen for a multicast router attaching to a | |||
| wireless link having higher capacity of the resource or a point-to- | wireless link having higher capacity of the resource or a point-to- | |||
| (multi-)point link such as an IEEE 802.16e link, because IGMP/MLD | (multi-)point link such as an IEEE 802.16e link, because IGMP/MLD | |||
| messages do not seriously affect the link condition. The router can | messages do not seriously affect the link condition. The router can | |||
| seek Current-State Report messages with the shorter [Query Response | seek Current-State Report messages with the shorter [Query Response | |||
| Interval] value, such as 5 to 10 (sec). This configuration will | Interval] value, such as 5 to 10 (sec). This configuration will | |||
| contribute to quickly (at some level) discovering non-tracked member | contribute to quickly (at some level) discovering non-tracked member | |||
| hosts and synchronizing the membership information. | hosts and synchronizing the membership information. | |||
| 4.3. Tuning Last Member Query Timer (LMQT) and Last Listener Query | 4.3. Tuning Last Member Query Timer (LMQT) and Last Listener Query | |||
| Timer (LLQT) | Timer (LLQT) | |||
| skipping to change at page 7, line 6 ¶ | skipping to change at page 7, line 11 ¶ | |||
| Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last | Shortening the Last Member Query Timer (LMQT) for IGMPv3 and the Last | |||
| Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave | Listener Query Timer (LLQT) for MLDv2 contributes to minimizing leave | |||
| latency. LMQT is represented by the Last Member Query Interval | latency. LMQT is represented by the Last Member Query Interval | |||
| (LMQI), multiplied by the Last Member Query Count (LMQC), and LLQT is | (LMQI), multiplied by the Last Member Query Count (LMQC), and LLQT is | |||
| represented by the Last Listener Query Interval (LLQI), multiplied by | represented by the Last Listener Query Interval (LLQI), multiplied by | |||
| the Last Listener Query Count (LLQC). | the Last Listener Query Count (LLQC). | |||
| While LMQI and LLQI are changeable, it is reasonable to use the | While LMQI and LLQI are changeable, it is reasonable to use the | |||
| default values (i.e., 1 second) for LMQI and LLQI in a wireless | default values (i.e., 1 second) for LMQI and LLQI in a wireless | |||
| network. LMQC and LLQC, whose default value is the [Robustness | network. LMQC and LLQC, whose default value is the [Robustness | |||
| Variable] value, are also tunable. Therefore, LMQC and LLQC MAY be | Variable] value, are also tunable. Therefore, LMQC and LLQC can be | |||
| set to "1" for routers enabling the explicit tracking function, and | set to "1" for routers enabling the explicit tracking function, and | |||
| then LMQT and LLQT are set to 1 second. However, setting LMQC 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 to 1 increases the risk of missing the last member; LMQC and | |||
| LLQC SHOULD be set to 1 only when network operators think that their | LLQC ought to be set to 1 only when network operators think that | |||
| wireless link is stable enough. | their wireless link is stable enough. | |||
| On the other hand, if network operators think that their wireless | 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 | link is lossy (e.g., due to a large number of attached hosts or | |||
| limited resources), they MAY set LMQC and LLQC to "2" for their | limited resources), they can set LMQC and LLQC to "2" for their | |||
| routers enabling the explicit tracking function. Although bigger | routers enabling the explicit tracking function. Although bigger | |||
| LMQC and LLQC values MAY cause longer leave latency, the risk of | LMQC and LLQC values may cause longer leave latency, the risk of | |||
| missing the last member will be reduced. | missing the last member will be reduced. | |||
| 4.4. Tuning Startup Query Interval | 4.4. Tuning Startup Query Interval | |||
| The [Startup Query Interval] is the interval between General Queries | The [Startup Query Interval] is the interval between General Queries | |||
| sent by a Querier on startup. The default value is 1/4 of [Query | sent by a Querier on startup. The default value is 1/4 of [Query | |||
| Interval]; however, in this document it is RECOMMENDED that the use | Interval]; however, a shortened value such as 1 second would help | |||
| of its shortened value such as 1 second since the shorter value would | ||||
| contribute to shortening handover delay for mobile hosts in, e.g., | contribute to shortening handover delay for mobile hosts in, e.g., | |||
| the base solution with PMIPv6 [10]. Note that the [Startup Query | the base solution with PMIPv6 [9]. Note that the [Startup Query | |||
| Interval] is a static value and cannot be changed by any external | Interval] is a static value and cannot be changed by any external | |||
| signal. Therefore operators who maintain routers and wireless links | signal. Therefore operators who maintain routers and wireless links | |||
| MUST properly configure this value. | need to properly configure this value. | |||
| 4.5. Tuning Robustness Variable | 4.5. Tuning Robustness Variable | |||
| To cover the possibility of unsolicited reports being missed by | To cover the possibility of unsolicited reports being missed by | |||
| multicast routers, unsolicited reports are retransmitted [Robustness | multicast routers, unsolicited reports are retransmitted [Robustness | |||
| Variable] - 1 more times, at intervals chosen at random from the | Variable] - 1 more times, at intervals chosen at random from the | |||
| defined range [1][2]. The QRV (Querier's Robustness Variable) field | defined range [1][2]. The QRV (Querier's Robustness Variable) field | |||
| in IGMP/MLD Query contains the [Robustness Variable] value used by | in IGMP/MLD Query contains the [Robustness Variable] value used by | |||
| the querier. The default [Robustness Variable] value defined in | the querier. The default [Robustness Variable] value defined in | |||
| IGMPv3 [1] and MLDv2 [2] is "2". | IGMPv3 [1] and MLDv2 [2] is "2". | |||
| skipping to change at page 8, line 15 ¶ | skipping to change at page 8, line 16 ¶ | |||
| 4.6. Tuning Scenarios for Various Mobile IP Networks | 4.6. Tuning Scenarios for Various Mobile IP Networks | |||
| In mobile IP networks, IGMP and MLD are used either with three | In mobile IP networks, IGMP and MLD are used either with three | |||
| deployment scenarios; (1) running directly between host and access | deployment scenarios; (1) running directly between host and access | |||
| router on a wireless network, (2) running between host and home | router on a wireless network, (2) running between host and home | |||
| router through a tunnel link, and (3) running between home router and | router through a tunnel link, and (3) running between home router and | |||
| foreign router through a tunnel link. | foreign router through a tunnel link. | |||
| When a receiver host connects directly through a wireless link to a | 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 | foreign access router or a home router, the tuning of the IGMP/MLD | |||
| protocol parameters SHOULD be the same as suggested in the previous | protocol parameters should be the same as suggested in the previous | |||
| sections. The example of this scenario occurs when in Proxy Mobile | sections. The example of this scenario occurs when in Proxy Mobile | |||
| IPv6 (PMIPv6) [7], the mobile access gateway, whose role is similar | IPv6 (PMIPv6) [6], the mobile access gateway, whose role is similar | |||
| to a foreign router, acts as a multicast router or proxy. | to a foreign router, acts as a multicast router or proxy. | |||
| The second scenario occurs when bi-directional tunnel established | The second scenario occurs when bi-directional tunnel established | |||
| between host and home router is used to exchange IGMP/MLD messages | between host and home router is used to exchange IGMP/MLD messages | |||
| such as in [8][11]. There are difficulties in tuning the parameters | such as in [7][10]. There are difficulties in tuning the parameters | |||
| in this situation, because the tunnel link condition is diverse and | in this situation, because the tunnel link condition is diverse and | |||
| changeable. When a host is far away from the home router, the | changeable. When a host is far away from the home router, the | |||
| transmission delay between the two entities MAY be longer and the | transmission delay between the two entities may be longer and the | |||
| packet delivery MAY be more unreliable. Thus the effects of the | packet delivery may be more unreliable. Thus the effects of the | |||
| IGMP/MLD message transmission through a tunnel link SHOULD be | IGMP/MLD message transmission through a tunnel link ought to be | |||
| considered during the parameter setting. For example, the [Query | considered during the parameter setting. For example, the [Query | |||
| Interval] and [Query Response Interval] could be set shorter to | Interval] and [Query Response Interval] could be set shorter to | |||
| compensate the transmission delay, and the [Robustness Variable] | compensate the transmission delay, and the [Robustness Variable] | |||
| could be increased for possible packet loss. | could be increased for possible packet loss. | |||
| The third scenario occurs in [10], in which the mobile access gateway | The third scenario occurs in [9], in which the mobile access gateway | |||
| (i.e., foreign router) acts as the IGMP/MLD Proxy [6] in PMIPv6 [7]. | (i.e., foreign router) acts as the IGMP/MLD Proxy [5] in PMIPv6 [6]. | |||
| Through the bi-directional tunnel established with the local mobility | Through the bi-directional tunnel established with the local mobility | |||
| anchor (i.e., home router), the mobile access gateway sends summary | anchor (i.e., home router), the mobile access gateway sends summary | |||
| reports of its downstream member hosts to the local mobility anchor. | reports of its downstream member hosts to the local mobility anchor. | |||
| Apart from the distance factor that influences the parameter setting, | Apart from the distance factor that influences the parameter setting, | |||
| the [Query Response Interval] on the local mobility anchor could be | the [Query Response Interval] on the local mobility anchor could be | |||
| set to a smaller value because the number of the mobile access | set to a smaller value because the number of the mobile access | |||
| gateways is much smaller compared to that of the host and the chances | gateways is much smaller compared to that of the host and the chances | |||
| of packet burst is low for the same reason. And the power | of packet burst is low for the same reason. And the power | |||
| consumption due to a lower query interval is not an issue for the | consumption due to a lower query interval is not an issue for the | |||
| moble access gateways because the mobile access gateways are usually | moble access gateways because the mobile access gateways are usually | |||
| skipping to change at page 9, line 14 ¶ | skipping to change at page 9, line 16 ¶ | |||
| dynamically adjusting these timers and values is out of scope of this | dynamically adjusting these timers and values is out of scope of this | |||
| document. | document. | |||
| 5. Destination Address of Specific Query | 5. Destination Address of Specific Query | |||
| IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined | IGMP/MLD Group-Specific and Group-and-Source Specific Queries defined | |||
| in [1][2] are sent to verify whether there are hosts that desire | in [1][2] are sent to verify whether there are hosts that desire | |||
| reception of the specified group or a set of sources or to rebuild | 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 | the desired reception state for a particular group or a set of | |||
| sources. These specific Queries build and refresh multicast | sources. These specific Queries build and refresh multicast | |||
| membership state of hosts on an attached network. These specific | membership state of hosts on an attached network. | |||
| Queries SHOULD be sent to all desired hosts with specific multicast | ||||
| address (not the all-hosts/all-nodes multicast address) as their IP | Group-specific queries are sent with an IP destination address equal | |||
| destination addresses, because hosts that do not join the multicast | to the multicast address of interest, as defined in [1][2]. Using | |||
| session do not pay attention to these specific Queries, and only | the multicast group of interest in the specific query is preferred in | |||
| active member hosts that have been receiving multicast contents with | this environment because hosts that do not join the multicast session | |||
| the specified address reply IGMP/MLD reports. | 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. | ||||
| 6. Interoperability | 6. Interoperability | |||
| IGMPv3 [1] and MLDv2 [2] provide the ability for hosts to report | IGMPv3 [1] and MLDv2 [2] provide the ability for hosts to report | |||
| source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can | source-specific subscriptions. With IGMPv3/MLDv2, a mobile host can | |||
| specify a channel of interest, using multicast group and source | specify a channel of interest, using multicast group and source | |||
| addresses in its join request. Upon its reception, the upstream | addresses in its join request. Upon its reception, the upstream | |||
| router that supports IGMPv3/MLDv2 establishes the shortest path tree | router that supports IGMPv3/MLDv2 establishes the shortest path tree | |||
| toward the source without coordinating a shared tree. This function | toward the source without coordinating a shared tree. This function | |||
| is called the source filtering function and is required to support | is called the source filtering function and is required to support | |||
| Source-Specific Multicast (SSM) [4]. | Source-Specific Multicast (SSM) [3]. | |||
| Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2 | Recently, the Lightweight-IGMPv3 (LW-IGMPv3) and Lightweight-MLDv2 | |||
| (LW-MLDv2) [5] protocols have been defined as the proposed standard | (LW-MLDv2) [4] protocols have been defined as the proposed standard | |||
| protocols in the IETF. These protocols provide protocol simplicity | protocols in the IETF. These protocols provide protocol simplicity | |||
| for mobile hosts and routers, as they eliminate a complex state | for mobile hosts and routers, as they eliminate a complex state | |||
| machine from the full versions of IGMPv3 and MLDv2, and promote the | machine from the full versions of IGMPv3 and MLDv2, and promote the | |||
| opportunity to implement SSM in mobile communications. | opportunity to implement SSM in mobile communications. | |||
| This document assumes that both multicast routers and mobile hosts | This document assumes that both multicast routers and mobile hosts | |||
| MUST be IGMPv3/MLDv2 capable, regardless whether the protocols are | are IGMPv3/MLDv2 capable, regardless whether the protocols are the | |||
| the full or lightweight version. And this document does not consider | full or lightweight version. And this document does not consider | |||
| interoperability with older version protocols. One of the reasons | interoperability with older version protocols. One of the reasons | |||
| not being interoperable with older IGMP/MLD protocols is that the | not being interoperable with older IGMP/MLD protocols is that the | |||
| explicit tracking function does not work properly with older IGMP/MLD | explicit tracking function does not work properly with older IGMP/MLD | |||
| protocols because of a report suppression mechanism; a host would not | protocols because of a report suppression mechanism; a host would not | |||
| send a pending IGMP/MLD report if a similar report was sent by | send a pending IGMP/MLD report if a similar report was sent by | |||
| another listener on the link. | another listener on the link. | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| This document has no actions for IANA. | This document has no actions for IANA. | |||
| 8. Security Considerations | 8. Security Considerations | |||
| This document neither provides new functions or modifies the standard | This document neither provides new functions or modifies the standard | |||
| functions defined in [1][2][5]. Therefore there is no additional | functions defined in [1][2][4]. Therefore there is no additional | |||
| security consideration provided. | security consideration provided. | |||
| 9. Acknowledgements | 9. Acknowledgements | |||
| Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, | Luis M. Contreras, Marshall Eubanks, Gorry Fairhurst, Dirk von Hugo, | |||
| Imed Romdhani, Behcet Sarikaya, Stig Venaas, Jinwei Xia, and others | Imed Romdhani, Behcet Sarikaya, Stig Venaas, Jinwei Xia, and others | |||
| provided many constructive and insightful comments. | provided many constructive and insightful comments. | |||
| 10. References | 10. References | |||
| 10.1. Normative References | 10.1. Normative References | |||
| [1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. | [1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. | |||
| Thyagarajan, "Internet Group Management Protocol, Version 3", | Thyagarajan, "Internet Group Management Protocol, Version 3", | |||
| RFC 3376, October 2002. | RFC 3376, October 2002. | |||
| [2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 | [2] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 | |||
| (MLDv2) for IPv6", RFC 3810, June 2004. | (MLDv2) for IPv6", RFC 3810, June 2004. | |||
| [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", | |||
| Levels", March 1997. | ||||
| [4] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", | ||||
| RFC 4607, August 2006. | RFC 4607, August 2006. | |||
| [5] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group | [4] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group | |||
| Management Protocol Version 3 (IGMPv3) and Multicast Listener | Management Protocol Version 3 (IGMPv3) and Multicast Listener | |||
| Discovery Version 2 (MLDv2) Protocols", RFC 5790, | Discovery Version 2 (MLDv2) Protocols", RFC 5790, | |||
| February 2010. | February 2010. | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [6] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet | [5] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet | |||
| Group Management Protocol (IGMP) / Multicast Listener Discovery | Group Management Protocol (IGMP) / Multicast Listener Discovery | |||
| (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", | (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", | |||
| RFC 4605, August 2006. | RFC 4605, August 2006. | |||
| [7] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., | [6] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., | |||
| and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. | and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. | |||
| [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in | [7] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in | |||
| IPv6", RFC 6275, July 2011. | IPv6", RFC 6275, July 2011. | |||
| [9] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership | [8] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership | |||
| Tracking Function for Multicast Routers", | Tracking Function for Multicast Routers", | |||
| draft-ietf-pim-explicit-tracking-00.txt (work in progress), | draft-ietf-pim-explicit-tracking-00.txt (work in progress), | |||
| October 2011. | October 2011. | |||
| [10] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment | [9] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment | |||
| for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) | for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) | |||
| Domains", RFC 6224, April 2011. | Domains", RFC 6224, April 2011. | |||
| [11] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", | [10] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", | |||
| RFC 5944, November 2010. | RFC 5944, November 2010. | |||
| Appendix A. Unicasting General Query | Appendix A. Unicasting General Query | |||
| 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 consideration when the | ||||
| new version or modification of IGMP and MLD protocols are considered | ||||
| in the future. | ||||
| IGMPv3 and MLDv2 specifications [1][2] describe that a host MUST | IGMPv3 and MLDv2 specifications [1][2] describe that a host MUST | |||
| accept and process any Query whose IP Destination Address field | accept and process any Query whose IP Destination Address field | |||
| contains any of the addresses (unicast or multicast) assigned to the | contains any of the addresses (unicast or multicast) assigned to the | |||
| interface on which the Query arrives. In general, the all-hosts | interface on which the Query arrives. In general, the all-hosts | |||
| multicast address (224.0.0.1) or link-scope all-nodes multicast | multicast address (224.0.0.1) or link-scope all-nodes multicast | |||
| address (FF02::1) is used as the IP destination address of IGMP/MLD | address (FF02::1) is used as the IP destination address of IGMP/MLD | |||
| General Query. On the other hand, according to [1][2], a router MAY | General Query. On the other hand, according to [1][2], a router may | |||
| be able to unicast General Query to the tracked member hosts in | be able to unicast General Query to the tracked member hosts in | |||
| [Query Interval], if the router keeps track of membership information | [Query Interval], if the router keeps track of membership information | |||
| (Section 3). | (Section 3). | |||
| Unicasting IGMP/MLD General Query would reduce the drain on battery | Unicasting IGMP/MLD General Query would reduce the drain on battery | |||
| power of mobile hosts as only the active hosts that have been | power of mobile hosts as only the active hosts that have been | |||
| receiving multicast contents respond the unicast IGMP/MLD General | receiving multicast contents respond the unicast IGMP/MLD General | |||
| Query messages and non-active hosts do not need to pay attention to | 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 | the IGMP/MLD Query messages. This also allows the upstream router to | |||
| proceed fast leaves (or shorten leave latency) by setting LMQC/LLQC | proceed fast leaves (or shorten leave latency) by setting LMQC/LLQC | |||
| skipping to change at page 12, line 10 ¶ | skipping to change at page 12, line 18 ¶ | |||
| hosts do not retransmit the same join requests (i.e., unsolicited | hosts do not retransmit the same join requests (i.e., unsolicited | |||
| Report messages), they lose the chance to join the channels unless | Report messages), they lose the chance to join the channels unless | |||
| the upstream router asks the membership information by sending | the upstream router asks the membership information by sending | |||
| General Query by multicast. It will be solved by using both unicast | General Query by multicast. It will be solved by using both unicast | |||
| and multicast General Queries and configuring the [Query Interval] | and multicast General Queries and configuring the [Query Interval] | |||
| timer value for multicast General Query and the [Unicast Query | timer value for multicast General Query and the [Unicast Query | |||
| Interval] timer value for unicast General Query. However, using two | Interval] timer value for unicast General Query. However, using two | |||
| different timers for General Queries would require the protocol | different timers for General Queries would require the protocol | |||
| extension this document does not focus on. If a router does not | extension this document does not focus on. If a router does not | |||
| distinguish the multicast and unicast General Query Intervals, the | distinguish the multicast and unicast General Query Intervals, the | |||
| router SHOULD only use and enable multicast General Query. | router should only use and enable multicast General Query. | |||
| Also, unicasting General Query does not remove multicasting General | Also, unicasting General Query does not remove multicasting General | |||
| Query. Multicast General Query is necessary to update membership | Query. Multicast General Query is necessary to update membership | |||
| information if it is not correctly synchronized due to missing | information if it is not correctly synchronized due to missing | |||
| Reports. Therefore, enabling unicast General Query SHOULD NOT be | Reports. Therefore, enabling unicast General Query should not be | |||
| used for the implementation that does not allow to configure | used for the implementation that does not allow to configure | |||
| different query interval timers as [Query Interval] and [Unicast | different query interval timers as [Query Interval] and [Unicast | |||
| Query Interval]. If a router does not distinguish these multicast | Query Interval]. If a router does not distinguish these multicast | |||
| and unicast General Query Intervals, the router SHOULD only use and | and unicast General Query Intervals, the router should only use and | |||
| enable multicast General Query. | enable multicast General Query. | |||
| Authors' Addresses | Authors' Addresses | |||
| Hitoshi Asaeda | Hitoshi Asaeda | |||
| Keio University | Keio University | |||
| Graduate School of Media and Governance | Graduate School of Media and Governance | |||
| 5322 Endo | 5322 Endo | |||
| Fujisawa, Kanagawa 252-0882 | Fujisawa, Kanagawa 252-0882 | |||
| Japan | Japan | |||
| End of changes. 48 change blocks. | ||||
| 66 lines changed or deleted | 73 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||