One document matched: draft-wu-multimob-igmp-mld-tuning-01.txt
Differences from draft-wu-multimob-igmp-mld-tuning-00.txt
Network working group Q. Wu
Internet Draft H. Liu
Category: Informational Huawei
Created: May 18, 2010
Expires: November 2010
Proposal for Tuning IGMPv3/MLDv2 Protocol Behavior in Wireless and
mobile networks
draft-wu-multimob-igmp-mld-tuning-01
Abstract
This document proposes a variety of optimization approaches for
tuning IGMPv3 and MLDv2 designed to provide useful guideline to
allow wireless multicast communication in wireless networks using
the current IGMP/MLD protocols.
Conventions used in this document
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
Wu,et al Expires November 18, 2010 [Page 1]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 15, 2009.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction.....................................................3
2. Evaluation of current versions of IGMP and MLD...................4
3. Impact of wireless and mobility on IGMP/MLD......................5
3.1. Comparison analysis between wired and wireless multicast....6
3.2. Link models analysis for wireless multicast.................7
3.3. Characteristic requirements of wireless multicast...........9
4. IGMP/MLD tuning optimization for Wireless or Mobile Network.....10
4.1. Router behavior for tuning optimization....................10
4.1.1. Explicit Tracking of hosts............................10
4.1.2. Report Suppression for the hosts......................13
4.1.3. Query Suppression for the routers.....................13
4.1.4. Minimizing General Periodical Query Frequency by.......
increasing interval each time................................13
4.1.5. Collecting membership by Using General Query with......
Unicast Query................................................14
4.1.6. Multiple Retransmission of Queries on packet loss.....14
4.1.7. Avoiding packet bursts by tuning the scope of Queries.15
4.1.8. Filtering unwanted multicast packets based on link type.
............................................................15
4.1.9. Tuning Response Delay according to link type and status.
............................................................16
Wu,et al Expires November 18, 2010 [Page 2]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
4.1.10. Switching Between Unicast Query and Multicast Query.16
5. Security Considerations........................................17
6. Acknowledgement................................................17
7. References.....................................................17
7.1. Normative References......................................17
7.2. Informative Referencess...................................18
Authors' Addresses................................................19
1. Introduction
Multicasting is more efficient a method of supporting group
communication than unicasting. However, it has seen slow commercial
deployment by ISPs and carriers for limited number of applications
and the complexity of the architecture design [DEPLOY]. Along With
the wide deployment of different wireless networks, multicast
communication over wireless network comes to attract more and more
interests from content and service providers, but still faces great
challenges when considering it to keep up with node movement and
frequent topology change and providing efficient service in the new
wireless environment, e.g., dynamic group membership and constant
update of delivery path due to node movement is highly required in
the wireless network.
On the other hand, unlike shared-medium wired LAN, some of wireless
networks, e.g. Wireless 802.11 WLAN offer limited reliability and
consume more power and cost more transmission overhead, in the worse
case, it is more prone to cause congestion.
Considering the existing multicast communications is designed only
for fixed users using wired link, it does not work well for all the
wireless link types. Therefore IGMP/MLD protocol should be enhanced
or tuned to adapt to wireless environment to meet the reliability
and efficiency requirements in the scenarios described in [REQUIRE].
This memo proposes a variety of optimization approaches for tuning
IGMP/MLD protocols in wireless or mobile communication environment.
It aims to make the minimum tuning without introducing obvious
changes on the protocol behavior. These solutions can also be used
in wired network when efficiency and reliability are required. They
are discussed in detail in Section 4.
Wu,et al Expires November 18, 2010 [Page 3]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
2. Evaluation of current versions of IGMP and MLD
As described in [RFC5757], the default timer values and counter
values specified in IGMPv2/MLDv1[2236][2710] or IGMPv3/MLDv2
[RFC3376][RFC3810] were not designed for the mobility context. This
may result in a slow reaction of the multicast-routing
infrastructure following a client join or leave. This issue can be
addressed by tuning these parameters for the expected packet loss on
a link.
IGMPv2 [RFC2236] and MLDv1 [RFC2710] only support ASM communication
mode. They do not support SSM subscription, which may limit their
widespread deployment in practical multicast network. IGMPv3
[RFC3376] and MLDv2 [RFC3810] and their lightweight version LW-
IGMPv3/LW-MLDv2 [RFC5760] support all the features of ASM and SSM
communication. Comparing with ASM mode, SSM [RFC4607] mode allows
only sources specific multicast delivery and reduce the demand on
the network and improve security by so limiting the source.
Therefore SSM mode is much better to be candidates for wireless and
mobile networks than their previous versions.
IGMPv3/MLDv2 Explicit join and leave Reports are the messages sent
unsolicitedly when a host intends to join or leave a group. They
are beneficial for ensuring satisfactory user experience and must be
guaranteed to improve service performance and to optimize resource
use. Current IGMPv3 and MLDv2 provide the reliability for these
messages by simple retransmission, which is not adequate from both
the robustness and efficiency aspects [ROBUST]. This issue can be
enhanced by acknowledgement-retransmission in [ACK][IGMP-ACK].
In IGMPv2 [RFC2236] and MLDv1 [RFC2710], host suppression is used to
suppress duplicated multicast listener reports on the link. In
IGMPv3 and MLDv2 host suppression mechanism is removed. Instead,
Explicit Tracking for per-host tracking is adopted.
Without host suppression, it is possible for a multicast router to
explicitly keep track the membership of all multicast hosts in the
access network using explicit tracking. And because the router has
record of each user in its state database or listener node table, it
is possible to eliminate the need for query timeouts when receiving
leave messages and simplify the Query mechanism by reducing both the
unnecessary Queries and reports generated on a network.
On the other hand, without host suppression, the report count in
response to a Query is not small, if the number of active receivers
on the network is large. Even though the protocols enable the
Wu,et al Expires November 18, 2010 [Page 4]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
reports on an interface to be merged, further optimizations are
still required to improve the efficiency and to reduce bandwidth
consumption.
In summary, it is desirable to choose IGMPv3/MLDv2 or LW-
IGMPv3/MLDv2 as the basis for optimization of IGMP/MLD to adapt to
wireless and mobile networks. But the performance still needs to be
improved by carefully tuning the Query Interval and other variables
to adapt to wireless and mobile scenarios. Also some enhanced
mechanism with no protocol changes can be employed as well.
Considering an enhancement in one direction might introduce side
effects in another one, balances should be taken carefully to avoid
defects and improve protocol performance as a whole, the comparison
between IGMPv2/MLDv1 and IGMPv3/MLDv2 is illustrated in figure 2.
+---------------------+----------------------+-------------------+
| Issues | IGMPv2/MLDv1 | IGMPv3/MLDv2 |
+---------------------+----------------------+-------------------+
|Default Timer and | Not designed for | Not designed for|
|Robustness Variable | Mobility context | Mobility context|
| | Need to be tuned | Need to be tuned|
+---------------------+----------------------+-------------------+
| | | |
| Explicit Tracking | Not Support | Support |
| | | |
+---------------------+----------------------+-------------------+
| ASM and SSM | Only Support ASM | |
| Subscription | Subscription | Both Support |
+---------------------+----------------------+-------------------+
| | | |
| Explicit Join | | |
| and Leave | Support | Support |
| | | |
+---------------------+----------------------+-------------------+
| | | |
|Host Suppression | Support | Not Support |
+---------------------+----------------------+-------------------+
Figure 1. Comparison between IGMPv2/MLDv1 and IGMPv3/MLDv2
3. Impact of wireless and mobility on IGMP/MLD
This section first evaluates the impact of wireless on mobility on
IGMP/MLD by comparing wireless multicast with wired multicast and
comparing different wireless link models. And then gives the
characteristics requirement of wireless multicast.
Wu,et al Expires November 18, 2010 [Page 5]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
3.1. Comparison analysis between wired and wireless multicast
Existing multicast support for fixed user can be extended to mobile
users in wireless environments. However applying such support to
wireless multicast is difficult for the following five reasons.
O Various types of links: Wireless link is usually asymmetrical link
and is restricted to unidirectional data retransmission. The
performance also varies with each link type.
O Limited Bandwidth: In contrast with wired multicast, wireless
multicast usually has limited bandwidth. Also the bandwidth
available in upstream direction and downstream direction may not
be equal.
O Large packets Loss: In contrast with wired multicast, wireless
multicast has large packet loss that range between 1%~30% based on
the links.
O Frequent Membership change: In the wired multicast, membership
change only happens when a user leave or joins a group while in
the wireless multicast, membership changes may also occur when a
user changes the location.
O Reliability: Due to possible unwanted interaction of protocols
across layers, the wireless network may be overwhelmed with
excessive traffic. In worse case, this may lead to network
performance degrading and network connection complete loss.
O Increased Leave Latency: Unlike wired multicast, the leave latency
in the wireless multicast will be increased with user movement.
Figure 2 shows the details for the difference between wired
multicast and wireless multicast.
+--------------+---------------------+----------------------------+
| | Current wired | Wireless |
| Issues | Multicast | multicast |
+--------------+---------------------+----------------------------+
| | | Possible asymmetrical |
| | Symmetrical and | and/or unidirectional links|
|Type of links | fixed Characteristic| of varying performance and |
| | Broadcast links in | point-to-point links in |
| | LANs | cellular and PCS |
+--------------+---------------------+----------------------------+
| | | |
Wu,et al Expires November 18, 2010 [Page 6]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
| Bandwidth | Plentiful | Limited and variable |
| | | amount |
+--------------+---------------------+----------------------------+
| | | |
| Loss of | Frequent(<1%) | Frequent and variable |
| Packets | | (1%-30% based on links) |
+--------------+---------------------+----------------------------+
| | | |
| Membership | Only when a user | Also when a user moves |
| Changes | leaves and joins | to another location |
| | a group | |
+--------------+---------------------+----------------------------+
| | | More complex due to |
| | Possible use of a | wireless links and user |
| Reliability | transport-layer | mobility; possible unwanted|
| | protocol(such as the| interaction of protocols |
| | Multicast File | at transport and link |
| | Transfer Protocol) | layers |
+--------------+---------------------+----------------------------+
| | | Increase due to |
|Leave Latency | not changed by | user movement |
| | user movement | and delayed or |
| | | lost packet |
-------------------------------------+----------------------------
Figure 2. Comparison between wired multicast and wireless multicast
3.2. Link models analysis for wireless multicast
As described in section 3.1, there are various type of wireless links.
Each link type has different feature and performance. In this document,
we categorize the wireless link type into three typical link models:
O PTP link model
O PTMP link model
O Broadcast link model
Point to Point link model is the model with one dedicated link that
connects exactly two communication facilities. In this model, each
link has only one receiver and the bandwidth is dedicated for each
receiver. Also one unique prefix or set of unique prefixes will be
assigned to each receiver. Such link model can be accomplished by
running PPP on the link or having separate VLAN for each receiver.
Wu,et al Expires November 18, 2010 [Page 7]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
PTMP link model is the model with multipoint link which consist of a
series of receivers and one centralized transmitter. Unlike P2P link
model, Bandwidth and prefix in this model are shared by all the
receivers on the same link. Therefore Duplicate Address Detection (DAD)
should be performed to check whether the assigned address is used by
other receivers.
Broadcast link model is the model with the link connecting two or
more nodes and supporting broadcast transmission. Such link model is
quite similar to PTMP link model. The obvious difference to the PTMP
link model is Broadcast link model only provide downlink common
channels for each user while P2MP link model also provide dedicated
uplink channel for each user.
Figure 3 shows the details for the difference between different
wireless link models.
+---------------+-----------------+---------------+---------------+
| Features | PTP | PTMP | Broadcast |
| | link model | link model | link model |
+---------------+-----------------+---------------+---------------|
| | | Common | |
| Shared link/ |Dedicated uplink | downlink | |
| Dedicated link|and downlink | channels and |common downlink|
| |channels for each| dedicated | Channel for |
| |user | uplink |each user |
| | | channels for | |
| | | each | |
| | | user | |
+---------------+-----------------+---------------+---------------|
| | | Prefix shared | Prefix shared |
| Shared Prefix | Per Prefix for | by all | by all |
| /Dedicated | each receiver | receivers | receivers |
| Prefix | No need DAD |DAD is required|DAD is required|
+---------------+-----------------+---------------+---------------|
| | | | |
|Shared Service | | | |
| Support | Not Support | Support | Support |
| | | | |
+---------------+-----------------+---------------+---------------|
| | Only one node | Link Layer | Broadcast |
| | On the link | Multicast | Support |
| | Forward | Support | at L2 |
| link layer | multicast | using | using switch |
| Broadcast | packets to | Backend | |
| Multicast | the only | (e.g.,AR) | IGMP/MLD |
Wu,et al Expires November 18, 2010 [Page 8]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
| Support | receiver | IGMP/MLD | Snooping |
| | on the | Snooping | at switch |
| | link | at AR | |
+---------------+-----------------+---------------+---------------|
| | | | |
| | | | Ethernet |
| Ethernet | Not support | Not support | Support By |
| link Support | | | Implementing |
| | | | Bridge |
| | | | |
+---------------+-----------------+---------------+---------------+
Figure 3. Wireless Link Models Analysis
3.3. Characteristic requirements of wireless multicast
Due to the impacts of wireless on IGMP/MLD described in the section
3.1, it is desirable for IGMP and MLD to have the following
characteristics when used in wireless and mobile networks [REQUIRE]:
o Adaptive to different link mode: IGMP and MLD are originally
designed for wired multicast and some of their processing is not
applicable to wireless multicast, e.g., asymmetrical link, limited
bandwidth, larger packet loss rate, increased leave latency. Also
Wireless and mobile network has various link types, each of them has
different bandwidth and performance. Therefore IGMP/MLD protocol
behavior should be tuned to adapt to different link model.
o Minimal Join and Leave Latency: Fast join and leave of a
subscriber helps to improve the user's experience during channel
join and channel zapping. Fast leave also facilitates releasing of
unused network resources quickly. Besides, mobility and handover
may cause a user to join and leave a multicast group frequently,
which also require fast join and leave to accelerate service
activation and to optimize resource usages.
o Robustness to packet loss: Wireless link has the characteristic
that packet transmission is unreliable due to instable link
conditions and limited bandwidth. For mobile IP network, packets
sometimes have to travel between home network and foreign network
and have the possibility of being lost due to long distance
transmission. These network scenarios have more strict robustness
requirement on delivery of IGMP and MLD protocol messages.
o Minimum packet transmission: Wireless link resources are usually
more precious and limited compared to their wired counterpart.
Minimizing packet exchange without degrading general protocol
Wu,et al Expires November 18, 2010 [Page 9]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
performance should also be emphasized to improve efficiency and make
good use of network capacity and processing capability.
o Avoiding packet burst: Large number of packets generated within a
short time interval may have the tendency to deteriorate wireless
network conditions. IGMP and MLD when using in wireless and mobile
networks should be optimized if their protocol message generation
has the potential of introducing packet burst.
4. IGMP/MLD tuning optimization for Wireless or Mobile Network
As mentioned in section 2, IGMPv3/MLDv2 or LW-IGMPv3/MLDv2 are
recommended to be used as the basis for optimization of IGMP/MLD to
adapt to wireless and mobile networks. In this section, taking
these characteristics requirement into account, we will discuss
several optimization approaches for tuning of IGMP and MLD in the
wireless environment. The optimizations try to minimize the packet
transmission for both the Reports and Queries, and at the meanwhile
take the factor of improving reliability into account, with minimum
cost. The different link types are also considered when varying
behavior and parameters.
4.1. Router behavior for tuning optimization
IGMPv3 and MLDv2 have three kinds of Queries: General Query
periodically sent to all multicast receivers, Group Specific Query
sent when a receiver leaves a (*,G) group, and Source-and-Group
Specific Query sent when a receiver leaves an (S,G) group. These
Queries have different functional scope. They are used to fetch and
refresh the downstream membership information by being responded by
solicited reports.
This section lists the possible optimization approaches for Query
messages. The solutions are not intended to be adopted altogether
or simultaneously, but can be taken selectively according to the
scale and conditions of the operating network.
4.1.1. Explicit Tracking of hosts
In the IGMPv2/MLDv1, the multicast listener reports are suppressed
if the same report has already been sent by another host in the
network which is also referred to as host suppression. As described
in the A.2 of [RFC3810], the suppression of multicast listener
reports has been removed in MLDv2 due to the following reasons:
Wu,et al Expires November 18, 2010 [Page 10]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
O Routers may want to track per-host multicast listener status on an
interface. This enables the router to track each individual host
that is joined to a particular group or channel and allow minimal
leave latencies when a host leaves a multicast group or channel.
o Multicast Listener Report suppression does not work well on
bridged LANs. Many bridges and Layer2/Layer3 switches that
implement MLD snooping do not forward MLD messages across LAN
segments in order to prevent multicast listener report suppression.
o By eliminating multicast listener report suppression, hosts have
fewer messages to process; this leads to a simpler state machine
implementation.
o In MLDv2, a single multicast listener report now bundles multiple
multicast address records to decrease the number of packets sent.
In comparison, the previous version of MLD required that each
multicast address be reported in a separate message.
In these reasons, one important reason is for per-host tracking at
the router which is also referred to as explicit tracking. Explicit
tracking is used to explicitly keep track the membership of all
multicast hosts in the access network which simplifies the Query
mechanism by reducing both the unnecessary Queries and reports
generated on a network.
When explicit tracking is enabled on a router, the local replication
can be used by the router to inspect incoming join and leave
requests, record or refresh the membership state for each host on
the interface, and take appropriate action to each received report.
In the meanwhile, the router builds a table to track which channel
being forwarded to each port. If the channel being requested to view
is already being received at the router, it can replicate the stream
and forward to this new requester which ensure good response time,
but we should note that the router must ensure enough bandwidth
available to service the request.
By using the tracking table mentioned above, the router also has the
capability to learn if a particular multicast address has any
listeners on an attached link or if any of the sources from the
specified list for the particular multicast address has any
listeners on an attached link or not. Such capability can also be
accomplished by using Group specific Query or Source-and-Group
Specific Queries, i.e., the Group Specific and Source-and-Group
Specific Queries, which are sent to query other members when a
member leaves, are unnecessary because the router has already known
Wu,et al Expires November 18, 2010 [Page 11]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
who are active on the interface using explicit tracking. Therefore
it is desirable that Group Specific Query is eliminated when
explicit tracking is used. But this does not mean that explicit
tracking can not be used with General periodical Query and current
state report in response to General Query. In some cases (e.g.,
explicit join and leave message from hosts are lost), the Explicit
tracking may depend on current state report to refresh the
membership state by sending General Query. But different from using
Group specific Query, General Query is periodical message sent by a
router to all multicast receivers and used by the router to refresh
the existing state at the router in each Query interval. Therefore
explicit tracking may update membership state periodically by using
periodical IGMP/MLD Query.
The main benefits of using explicit tracking without Group specific
Query or Source-and-Group Specific Queries are that it provides:
O minimizing packet number and packet burst: Elimination of Group and
Source-Group specific Queries in case a member leaves a group will
reduce the great number of transmitted Group Specific Queries. And
finally the total number of Reports in response to Group Specific
Queries can be drastically reduced.
O Minimal leave latencies: That is to say, a router configured with
IGMPv3/MLDv2 and explicit tracking can immediately stop forwarding
traffic if the last host to request to receive traffic from the
router indicates that it no longer wants to receive traffic.
O Faster channel changing: The channel change time of the receiver
application depends on the leave latency, that is to say, single host
can not receive the new multicast stream before forwarding of the old
stream has stopped.
O Reducing Power consumption: Due to elimination of the suppression
of multicast listener reports, the host does not need to hear and
suppress the duplicated report message which is beneficial to mobile
hosts that do not have enough battery power.
On the other hand, when explicit tracking is enabled at the router,
the router may consume more memory and processing overhead to store
the membership state of all hosts on the interface, especially when
explicit tracking is used with General Query. This issue can be
optimized by separation of processing state changing report and
current state report. That means the router with explicit tracking
support will not send General Query to refresh membership state at
this router and only take action to the state change report, e.g.,
Wu,et al Expires November 18, 2010 [Page 12]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
explicit join report and explicit leave report which is beneficial to
reduce leave latency. The current state report can be processed by
another router who sends the period Query.
4.1.2. Report Suppression for the hosts
The large number of Reports and bad link condition may result in
packets burst. This packet burst can be mitigated by having the
router aggregate the responses (membership reports) from multiple
clients. The router can intercept IGMP/MLD reports coming from hosts,
and forwards a summarized version to the router only when necessary.
Typically this means that the router will forward IGMP/MLD membership
reports as follows:
- Unsolicited membership reports (channel change requests) are
forwarded only the first subscriber joins a multicast group, or the
last subscriber leaves a multicast group. This tells the router to
begin or stop sending this channel to this router.
- Solicited membership reports (sent in response to an query) are
forwarded once per multicast group. The router may also aggregate
multiple responses together into a single membership report.
4.1.3. Query Suppression for the routers
The large number of Queries and bad link condition may result in
packets burst. This packet burst can be mitigated by having the
downstream router intercept and response to IGMP/MLD Queries packets
sent by upstream router. Typically this means that the router will:
- Never send a specific query to any client, and
- Forward general queries only to those clients receiving at least
one multicast group
4.1.4. Minimizing General Periodical Query Frequency by increasing
interval each time
As described in [RFC3376][RFC3810], General Queries is sent
periodically by the Querier with fixed interval, to learn multicast
address listener information from an attached link. This General
Query can be slowed down when a router can not collect successfully
all the members' report responses in the meanwhile the network
congestion is going to happen [ADAPTIVE]. Its basic behavior is: the
router after sending a Query, if acquires the response from the
receiver, refreshes its state database and stop the querying
Wu,et al Expires November 18, 2010 [Page 13]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
retransmission process, or if after a time interval fails to get the
report response, resends a Query with an increased (e.g. double)
interval. This process can be repeated [Robustness variables] times,
each time the retransmission is arranged in a prolonged time
interval, till the router receives the response, or determines the
receiver is unreachable and then stops the sending of the Query
ultimately.
This query retransmission with incremental interval enables the
router to reduce the total packet retransmission times in the same
time period comparing with retransmission for multiple times with
fixed interval. Therefore it can be used to improve the robustness
of the solicited report and of the Query in case of network
congestion. The variable time interval and the termination
condition should be configurable and could be set according to
actual network condition.
4.1.5. Collecting membership by Using General Query with Unicast Query
As described in [RFC3376] and [RFC3810], a node MUST accept and
process any Query whose IP Destination Address field contains
unicast address. That is to say, Unicast Query should be allowed in
some cases which may benefit the battery power consumption on mobile
terminals. It also can be used with General Query to improve the
robustness of solicited reports when General Query that is used to
collect membership information fails. Its basic behavior is: a
router after sending a periodical Query collects successfully all
the members' report responses except for one or two which are
currently still valid in its database. This may be because the non-
respondent ones silently leave the network without any notification,
or because their reports are lost due to some unknown reason. The
router in this case could choose to unicast a Query respectively to
each non-respondent receiver to check whether they are still alive
for the multicast reception, without affecting the majority of
receivers that have already responded. Optionally, unicast Queries
could be resent in incremental interval, as described in section
4.2.1.
4.1.6. Multiple Retransmission of Queries on packet loss
As described in [RFC3376] and [RFC3810], Group specific Query and
Group-and-Source specific Query, can be retransmitted several times
within a given time interval. And also described in [RFC3376] and
[RFC3810], General Query can be retransmitted [Startup Query Count]
with [Startup Query Interval].In some case, a router which keeps
track of all its active receivers, if after sending a Query, may fail
Wu,et al Expires November 18, 2010 [Page 14]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
to get any response from any receiver. And it may derive that this
Query might have been lost before reaching the other end of the link.
In such case, the router could choose to compensate this situation by
sending another Query to solicit its active members and setting the
retransmission times and one new timer for retransmission. When the
retransmission timer expires and the response from receiver has not
arrived, then another Query will be retransmitted.
4.1.7. Avoiding packet bursts by tuning the scope of Queries
General Query is sent by a router periodically to all multicast
receivers belonging to all groups and all source-groups and will
probably result in burst response and link congestion if the
receiver number on the link is large, even if Delay response is used.
Therefore large number of reports within a specified time interval
should be avoided if the number of the receiver on the link is large.
A router can tune the scope of its periodical Queries according to
the network conditions and user scale. For example, if the receiver
number is small, the periodical General Queries for all multicast
receivers can be used; if the number of the multicast receiver on a
link is large, the router could choose to send Group Queries to a
(*,G) group with different time interval or send Source-Group
Specific Queries to an (S,G) group with different time interval. In
this case the router tunes its behavior by transmissions of these
two Queries when the number of receivers is large instead of
triggering them when a member reports its leave. Also using Group
Specific Queries or Source-Group Specific Queries sent in different
time interval has the advantages of avoiding packet bursts and the
response report from unrelated group when the receiver number is
large.
4.1.8. Filtering unwanted multicast packets based on link type
When the network needs to deliver packets to the receiver, the
receiver may be in the dormant mode. In such case, Paging capability
will be used to establish connection with the network when the
receiver is waken up. Before the connection is established, packets
destined to a receiver in dormant mode are buffered at the Access
router. However the multicast capability within a link may cause for
a receiver to wake up for unwanted multicast packet. This can be
avoided by filtering the multicast packets and delivering the
packets to only for receivers that are listening for particular
multicast packets. As point-to-point link model has only one node
on the link, they do not have any effect on the dormant mode. The
Wu,et al Expires November 18, 2010 [Page 15]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
broadcast link model and point to multipoint link model may have the
multicast capability, which requires filtering at the access node to
support the dormant mode for the receivers.
4.1.9. Tuning Response Delay according to link type and status
As described in IGMPv3/MLDv2, a longer Maximum Response Delay will
spread Report messages over a longer interval which can greatly
reduce possibility of MLD traffic burstiness. However, a longer
Maximum Response Delay in Multicast Address Specific and Multicast
Address and Source Specific Queries extends the leave latency (the
time between when the last listener stops listening to a source or
multicast address and when the traffic stops flowing.) In order to
avoid burstiness of MLD traffic and reduce leave latency, we can
first use explicit tracking with Group Specific Query eliminated to
minimize leave latency.
And then the Response Delay may be dynamically calculated based on
the expected number of Reporters for each Query and link type and
link status.
O If the expected number of Reporters is large and link condition is
bad, the system administrator MUST choose the longer Maximum
Response Delay; If the expected number of Reporters is small and the
link condition is good, the administrator may choose the smaller
Maximum response Delay. In this case, the MLD traffic burstieness
can be reduced.
o Another case is if the link type is PTP which means the resource
is dedicated for one receiver on each link, then the Maximum
Response Delay can be chosen smaller, if the link type is shared
medium link or P2MP, then the Maximum Response Delay can be
configured larger.
4.1.10. Switching Between Unicast Query and Multicast Query
IGMP/MLD protocols define the use of multicast Queries whose
destination addresses are multicast addresses and also allow use of
unicast Queries with unicast destination. The unicast Query is sent
only for one destination and has the advantages of not affecting
other host on the same link. But in some cases(e.g., during the
Queries on startup)using unicast Query instead of multicast
Query ,the number the valid multicast receiver on the same link may
be large, i.e., numerous Queries will be generated for each member,
which will not be an efficient use of link resources. In this case
Wu,et al Expires November 18, 2010 [Page 16]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
the normal multicast Query will be a good choice because only one
Query needs to be sent for the receivers.
The router can choose to switch between unicast and multicast Query
according to the practical network conditions. For example, if the
receiver number is small, the router could send unicast Queries
respectively to each receiver to solicit their membership states,
without arousing other host which is in the dormant state. when the
receiver number reaches a predefined level, the router could change
to use multicast Queries. The router could make the switching
flexibly according to practical conditions to improve the efficiency.
5. Security Considerations
They will be described in the later version of this draft.
6. Acknowledgement
The authors would like to thank WeeSan Lee, Imed Romdhani, Stig Venaas,
Gorry Fairhurst, Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan,
J.William Atwood, Hitoshi Asaeda, Liu Yisong and Wei Yong for their
valuable comments and suggestions on this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", RFC 2119, March 1997.
[RFC1112] Deering, S. "Host Extensions for IP Multicasting", RFC1112,
August 1989.
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, November 1997.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2(MLDv2) for IPv6", RFC 3810, June 2004.
Wu,et al Expires November 18, 2010 [Page 17]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight IGMPv3 and
MLDv2 Protocols", RFC5790, February 2010.
7.2. Informative Referencess
[DEPLOY] C. Diot, B. Levine, B. Lyles, H. Kassem and D. Balensiefen.
"Deployment Issues for the IP Multicast Service and
Architecture" ,IEEE Networks Magazine's Special Issue on Multicast,
January, 2000
[REQUIRE] H. Liu, Q. Wu, H. Asaeda and TM. Eubanks, "Mobile and
Wireless Multicast Requirements on IGMP/MLD Protocols", draft-liu-
multimob-igmp-mld-mobility-req-03.txt, March 2010.
[ROBUST] A. Sen Mazumder, "Facilitating Robust Multicast Group
Management", NOSSDAV'05, June 13-14, 2005, Stevenson, Washington,
USA.
[ACK] Nikaein, N. and Bonnet, C. "Wireless multicasting in an IP
environment" In Proceedings of the 5th International Workshop on
Mobile Multimedia Communication MoMuc'98 (Berlin, Germany, Oct. 12-
14). IEEE Computer Society Press, 1998.
[IGMP-ACK] H. Liu, Q, Wu, "Reliable IGMP and MLD Protocols in
Wireless Environment", draft-liu-multimob-reliable-igmp-mld-00.txt,
February 2010.
[ADAPTIVE] I. Romdhani, J. Munoz, H. Bettahar, and A. Bouabdallah,
"Adaptive Multicast Membership Management for Mobile Multicast
Receivers", IEEE, 2006.
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast
Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief
Survey", RFC 5757, February 2010.
Wu,et al Expires November 18, 2010 [Page 18]
Internet-Draft Tuning IGMPv3/MLDv2 Protocol Behavior May 2010
Authors' Addresses
Qin Wu
Huawei Technologies Co., Ltd.
Site B, Floor 12, Huihong Mansion,No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-25-84565892
Email: sunseawq@huawei.com
Hui Liu
Huawei Technologies Co., Ltd.
Huawei Bld., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
Email: Liuhui47967@huawei.com
Wu,et al Expires November 18, 2010 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:42 |