Multimob Working Group H. Liu
Internet-Draft M. McBride
Intended status: Informational Huawei Technologies
Expires: January 13, 2013 July 12, 2012
IGMP/MLD Optimizations in Wireless and Mobile Networks
draft-liu-multimob-igmp-mld-wireless-mobile-02
Abstract
This document proposes a variety of optimization approaches for IGMP
and MLD in wireless and mobile networks. It aims to provide useful
guideline to allow efficient multicast communication in these
networks using IGMP or MLD protocols.
Requirements Language
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 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2013.
Copyright Notice
Copyright (c) 2012 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
Liu & McBride Expires January 13, 2013 [Page 1]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Characteristics of Wireless and Mobile Multicast . . . . . 3
2.2. Wireless Link Model . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements on IGMP and MLD . . . . . . . . . . . . . . . 5
3. IGMP/MLD Optimization for Wireless and Mobile Networks . . . . 6
3.1. Switching Between Unicast and Multicast Queries . . . . . 6
3.2. General Query Supplemented with Unicast Query . . . . . . 6
3.3. Retransmission of Queries . . . . . . . . . . . . . . . . 7
3.4. General Query Suppression . . . . . . . . . . . . . . . . 7
3.5. Tuning Response Delay According to Link Type and Status . 8
3.6. Triggering Reports and Queries Quickly During Handover . . 9
4. Applicability and Interoperability Considerations . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Liu & McBride Expires January 13, 2013 [Page 2]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
1. Introduction
With the wide deployment of various wireless access techniques and
the tendency to support video applications on wireless networks,
wireless and mobile multicast come to attract more and more interests
from content and service providers, but still face great challenges
when considering dynamic group membership management under constant
update of delivery path introduced by node movement, and high
probability of loss and congestion due to limited reliability and
capacity of wireless links.
Multicast network is generally constructed by IGMP and MLD group
management protocol (respectively for IPv4 and IPv6 networks) to
track valid receivers and by multicast routing protocol to build
multicast delivery paths. This document focuses only on IGMP and
MLD, which are used by a host to subscribe a multicast group and are
most possibly to be exposed to wireless link to support terminal
mobility. As IGMP and MLD were designed for fixed users using wired
link, they do not necessarily work well for different wireless link
types and mobile scenarios, thus should be considered to be enhanced
to be more applicable in these environments.
This memo proposes a variety of optimizations for IGMP and MLD in
wireless and mobile networks to improve network performance, with
minimum changes on the protocol behavior and without introducing
interoperability issues. These solutions can also be applied in
wired network when efficiency or reliability is required.
For generality, this memo does not put limitations on the type of
wireless techniques running below IGMP or MLD. They could be
cellular, WiMAX, WiFi and etc, and are modeled as different abstract
link models as described in section 2.2. Even though some of them
(such as WiFi) have multicast limitations, it is probable that IGMP/
MLD is enabled on the wireless terminal and multicast is supported
across the network. The mobile IP protocol adopted on the core side,
upstream from the access router, could be PMIP, MIPv4, or MIPv6.
2. Requirements
2.1. Characteristics of Wireless and Mobile Multicast
Several limitations should be considered when supporting IP multicast
in wireless and mobile networks, including:
O Limited link bandwidth: wireless link usually has limited
bandwidth, and the situation will be made even worse if high volume
video multicast data has to be carried. Also the bandwidth available
Liu & McBride Expires January 13, 2013 [Page 3]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
in the upstream and downstream directions may be asymmetrical.
O High loss rate: wireless link usually has packet loss ranging from
1% to 30% according to different links types and conditions. Also
when packets have to travel between home and access networks (e.g.
through tunnel), they are prone to loss if the two networks are
distant from each other.
O Frequent membership change: in fixed multicast, membership change
only happens when a user leaves or joins a group, while in mobile
scenario membership may also change when a user changes its location.
O Prone to performance degradation: the possible increased
interaction of protocols across layers for mobility management, and
the limitation of link capacity, may lead to network performance
degradation and even to complete connection loss.
O Increased Leave Latency: the leave latency in mobile multicast
might be increased due to user movement, especially if the traffic
has to be transmitted between access and home networks, or if there
is a handshake between networks.
2.2. Wireless Link Model
Wireless links can be categorized by their different transmission
modes into three typical models: point-to-point (PTP), point-to-
multipoint (PTMP), and broadcast link models.
In PTP model, one link is dedicated for two communication facilities.
For multicast transmission, each PTP link normally has only one
receiver and the bandwidth is dedicated for that receiver. Such link
model may be implemented by running PPP on the link or having
separate VLAN assignment for each receiver. In mobile network,
tunnel between entities of home and foreign networks should be
recognized as a PTP link.
PTMP is the model for multipoint transmission wherein there is one
centralized transmitter and multiple distributed receivers. PTMP
provides common downlink channels for all receivers and dedicated
uplink channel for each receiver. Bandwidth downstream is shared by
all receivers on the same link.
Broadcast link can connect two or more nodes and supports broadcast
transmission. It is quite similar to fixed Ethernet link model and
its link resource is shared in both uplink and downlink directions.
Liu & McBride Expires January 13, 2013 [Page 4]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
2.3. Requirements on IGMP and MLD
IGMP and MLD are usually run between mobile or wireless terminals and
their first-hop access routers (i.e. home or foreign routers) to
subscribe an IP multicast channel. Currently the version in-use
includes IGMPv2 [RFC2236] and its IPv6 counterpart MLDv1 [RFC2710],
IGMPv3 [RFC3376] and its IPv6 counterpart MLDv2 [RFC3810], and LW-
IGMPv3/MLDv2 [RFC5790]. All these versions have basic group
management capability required by a multicast subscription. The
differences lie in that IGMPv2 and MLDv1 can only join and leave a
non-source-specific group, while IGMPv3 and MLDv2 can select
including and excluding specific sources for their join and leave
operation, and LW-IGMPv3/MLDv2 simplifies IGMPv3/MLDv2 procedures by
discarding excluding-source function. Among these versions, (LW-)
IGMPv3/MLDv2 has the capability of explicitly tracking each host
member.
From the illustration given in section 2.1 and 2.2, it is desirable
for IGMP and MLD to have the following characteristics when used in
wireless and mobile networks:
o Adaptive to link conditions: wireless network has various link
types, each with different bandwidth and performance features. IGMP
or MLD should be able to be adaptive to different link model and link
conditions to optimize its protocol operation.
o Minimal group join/leave latency: because mobility and handover may
cause a user to join and leave a multicast group frequently, fast
join and leave by the user helps to accelerate service activation and
to release unnecessary resources quickly to optimize resource
utilization.
o Robust to packet loss: the unreliable packet transmission due to
instable wireless link conditions and limited bandwidth, or long
distance transmission in mobile network put more strict robustness
requirement on delivery of IGMP and MLD protocol messages.
o Reducing packet exchange: wireless link resources are usually more
limited, precious, and congested compared to their wired counterpart.
This requires packet exchange be minimized without degrading protocol
performance.
o Packet burst avoidance: large number of packets generated in a
short time interval may have the tendency to deteriorate wireless
network conditions. IGMP and MLD should be optimized to reduce the
probability of packet burst.
Liu & McBride Expires January 13, 2013 [Page 5]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
3. IGMP/MLD Optimization for Wireless and Mobile Networks
This section introduces several optimization methods for IGMP and MLD
in wireless or mobile environment. The aim is to meet the
requirements described in section 2.3. It should be noted that
because an enhancement in one direction might result in weakening
effect in another, balances should be taken cautiously to realize
overall performance elevation.
3.1. Switching Between Unicast and Multicast Queries
IGMP/MLD protocol uses multicast Queries whose destinations are
multicast addresses and also allows use of unicast Query with unicast
destination to be sent only to one host. Unicast Query has the
advantage of not affecting other hosts on the same link, and is
desirable for wireless communication because a mobile terminal often
has limited battery power [RFC6636]. But if the number of valid
receivers is large, using unicast Query for each receiver is
inefficient because large number of Unicast Queries have to be
generated, in which situation normal multicast Query will be a good
choice because only one General Query is needed. If the number of
receivers to be queried is small, unicast Query is advantageous over
the multicast one.
More flexibly, the router can choose to switch between unicast and
multicast Queries according to the practical network conditions. For
example, if the receiver number is small, the router could send
unicast Queries respectively to each receiver, without arousing other
non-member terminal which is in dormant state. When the receiver
number reaches a predefined level, the router could change to use
multicast Queries. To have the knowledge of the number of the valid
receivers, a router is required to enable explicit tracking, and
because Group-Specific Query and Group-and-Source-Specific Query are
usually not used under explicit tracking [RFC6636], the switching
operation mostly applies to General Queries.
3.2. General Query Supplemented with Unicast Query
Unicast Query also can be used in assistance to General Query to
improve the robustness of solicited reports when General Query fails
to collect all of its valid members. It requires the explicit
tracking to be enabled and can be used when a router after sending a
periodical General Query collects successfully most of the valid
members' responses while losing some of which are still valid in its
database. This may be because these reports are not generated or
generated but lost for some unknown reasons. The router could choose
to unicast a Query respectively to each non-respondent valid receiver
to check whether they are still alive for the multicast reception,
Liu & McBride Expires January 13, 2013 [Page 6]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
without affecting the majority of receivers that have already
responded. Unicast Queries under this condition could be sent at the
end of the [Maximum Response Delay] after posting a General Query,
and be retransmitted for [Last Member Query Count] times, at an
interval of [Last Member Query Interval].
3.3. Retransmission of Queries
In IGMP and MLD, apart from the continuously periodical transmission,
General Query is also transmitted during a router's startup. It is
transmitted for [Startup Query Count] times by [Startup Query
Interval]. There are some other cases where retransmission of
General Query is beneficial which are not covered by current IGMP and
MLD protocols as shown as following.
For example, a router which keeps track of all its active receivers,
if after sending a General Query, fails to get any response from the
receivers which are still valid in its membership database. This may
be because all the responses of the receivers happen to be lost, or
the sent Query does not arrive at the other side of the link to the
receivers. The router could compensate this situation by
retransmitting the General Query to solicit its active members. The
retransmission can also be applied to Group-Specific or Group-and-
Source-Specific Query on a router without explicit tracking
capability, when these Specific Queries cannot collect valid
response, to prevent missing valid members caused by lost Queries and
Reports.
The above compensating Queries could be sent [Last Member Query
Count] times, at the interval of [Last Member Query Interval], if the
router cannot get any feedback from the receivers.
3.4. General Query Suppression
In IGMP and MLD, General Query is sent periodically and continuously
without any limitation. It helps soliciting the state of current
valid member but has to be processed by all hosts on the link,
whether they are valid multicast receivers or not. When there is no
receiver, the transmission of the General Query is a waste of
resources for both the host and the router.
An IGMP/MLD router could suppress its transmission of General Query
if it knows there is no valid multicast receiver on an interface,
e.g. in the following cases:
O When the last member reports its leave for a group. This could be
judged by an explicit tracking router checking its membership
database, or by a non-explicit-tracking router getting no response
Liu & McBride Expires January 13, 2013 [Page 7]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
after sending Group-Specific or Group-and-Source-Specific Query.
O When the only member on a PTP link reports its leaving
O When a router after retransmitting General Queries on startup fails
to get any response
O When a router previously has valid members but fails to get any
response after several rounds of General Queries.
In these cases the router could make the decision that no member is
on the interface and totally stop its transmission of periodical
General Queries. If afterwards there is any valid member joins a
group, the router could resume the original cycle of general
Querying. Because General Query has influences on all hosts on a
link, suppressing it when it is not needed is beneficial for both the
link efficiency and terminal power saving.
3.5. Tuning Response Delay According to Link Type and Status
IGMP and MLD use delayed response to spread unsolicited Reports from
different hosts to reduce possibility of packet burst. This is
implemented by a host responding to a Query in a specific time
randomly chosen between 0 and [Maximum Response Delay], the latter of
which is determined by the router and is carried in Query messages to
inform the hosts for calculation of the response delay. A larger
value will lessen the burst better but will increase leave latency
(the time taken to cease the traffic flowing after the last member
requests the escaping of a channel).
In order to avoid message burst and reduce leave latency, the
Response Delay may be dynamically calculated based on the expected
number of responders, and link type and status, as shown in the
following:
O If the expected number of reporters is large and link condition is
bad, longer Maximum Response Delay is recommended; if the expected
number of reporters is small and the link condition is good, smaller
Maximum response Delay should be set.
o If the link type is PTP, the Maximum Response Delay can be chosen
smaller, whereas if the link is PTMP or broadcast medium, the Maximum
Response Delay can be configured larger.
The Maximum Response Delay could be configured by the administrator
as mentioned above, or be calculated automatically by a software tool
implemented according to experiential model for different link modes.
The measures to determine the instant value of Maximum Response Delay
Liu & McBride Expires January 13, 2013 [Page 8]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
are out of this document's scope.
3.6. Triggering Reports and Queries Quickly During Handover
When a mobile terminal is moving from one network to another, if it
is receiving multicast content, its new access network should try to
deliver the content to the receiver without disruption or performance
deterioration. In order to implement smooth handover between
networks, the terminal's membership should be acquired as quickly as
possible by the new access network.
An access router could trigger a Query to a terminal as soon as it
detects the terminal's attaching on its link. This could be a
General Query if the number of the entering terminals is not small
(e.g when they are simultaneously in a moving train). Or this Query
could also be a unicast Query for this incoming terminal to prevent
unnecessary action of other terminals in the switching area.
For the terminal, it could send a report immediately if it is
currently in the multicast reception state, when it begins to connect
the new network. This helps establishing more quickly the membership
state and enable faster multicast stream injection, because with the
active report the router does not need to wait for the query period
to acquire the terminal's newest state.
4. Applicability and Interoperability Considerations
Among the optimizations listed above, 'Switching between unicast and
multicast Queries'(3.1) and 'General Query Supplemented with Unicast
Query'(3.2) require a router to know beforehand the valid members
connected through an interface, thus require explicit tracking
capability. An IGMP/MLD implementation could choose any combination
of the methods listed from 3.1 to 3.6 to optimize multicast
communication on a specific wireless or mobile network.
For example, an explicit-tracking IGMPv3 router, can switch to
unicast General Queries if the number of members on a link is small
(3.1), can trigger unicast Query to a previously valid receiver if
failing to get expected responses from it (3.2), can retransmit a
General Query if after the previous one cannot collect reports from
all valid members (3.3), and can stop sending a General Query when
the last member leaves the group (3.4), and etc.
For interoperability, it is required if multiple multicast routers
are connected to the same network for redundancy, each router are
configured with the same optimization policy to synchronize the
membership states among the routers.
Liu & McBride Expires January 13, 2013 [Page 9]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
Since the methods only involve the tuning of protocol behavior by
e.g. retransmission, changing delay parameter, or other compensating
operations, they do not introduce additional security weaknesses.
The security consderations described in [RFC2236], [RFC3376],
[RFC2710] and [RFC3810] can be reused. And to achieve some security
level in insecure wireless network, it is possible to take stronger
security procedures during IGMP/MLD message exchange, which are out
of the scope of this memo.
7. Acknowledgements
The authors would like to thank Qin Wu, Stig Venaas, Gorry Fairhurst,
Thomas C. Schmidt, Marshall Eubanks, Suresh Krishnan, J.William
Atwood, WeeSan Lee, Imed Romdhani, Hitoshi Asaeda, Liu Yisong and Wei
Yong for their valuable comments and suggestions on this document.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet
Liu & McBride Expires January 13, 2013 [Page 10]
Internet-Draft IGMP/MLD in wireless/mobile network July 2012
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010.
[RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of
the Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) for Routers in Mobile
and Wireless Networks", RFC 6636, May 2012.
Authors' Addresses
Hui Liu
Huawei Technologies
Building Q14, No.156, Beiqing Rd.
Beijing 100095
China
Email: helen.liu@huawei.com
Mike McBride
Huawei Technologies
2330 Central Expressway
Santa Clara CA 95050
USA
Email: michael.mcbride@huawei.com
Liu & McBride Expires January 13, 2013 [Page 11]