Network Working Group B. Sarikaya
Internet-Draft Huawei USA
Intended status: Informational D. von Hugo
Expires: September 5, 2009 Deutsche Telecom Laboratories
March 4, 2009
Group Management Protocol Operation Over Wireless Problem Statement
<draft-sarikaya-multimob-overwireless-ps-00.txt>
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 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 September 5, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Sarikaya & von Hugo Expires September 5, 2009 [Page 1]
Internet-Draft Mobile Multicast March 2009
Abstract
Multicast mobility using existing IETF protocols is inefficient.
This document looks at the principal shorcomings in IGMP/MLD that
arise from operating over three wireless links, IEEE 16e used in
Mobile WiMAX, IEEE 802.11 used in Wi-Fi networks and 3GPP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IGMP/MLD Operation over 802.16e . . . . . . . . . . . . . . . 3
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5
4. IGMP/MLD Operation over 3GPP evolved packet system (EPS) . . . 6
4.1. Mobility between evolved 3G and non-3G access . . . . . . 6
4.2. Multicast support in evolved 3GPP . . . . . . . . . . . . 7
4.3. IGMP/MLD Support in Evolved 3GPP . . . . . . . . . . . . . 8
4.4. Problem Statement . . . . . . . . . . . . . . . . . . . . 9
5. IGMP/ MLD on IEEE 802.11 Links . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Sarikaya & von Hugo Expires September 5, 2009 [Page 2]
Internet-Draft Mobile Multicast March 2009
1. Introduction
More and more operators are beginning to provide the wireless
broadband network services such as Mobile IPTV. Mobile IPTV service
is a kind of audio/video (A/V) service which is combined with
interactive data for the related or supplementary information of A/V
program using bi-directional wireless broadband links. Users can
enjoy the downlink A/V stream and request more detailed or value-
added information via uplink simultaneously. Mobile IPTV service,
which can also be described as place-shifting IPTV service, is to
ensure continuous and original IPTV experiences for the users who
move to the other place from where he or she was originally
subscribed for [ITUIPTV].
Apart from Mobile IPTV which is considered "the killer application",
content broadcasting and streaming over audio and video conferencing,
online multiplayer gaming are applications of IP multicast technology
for mobile users.
In this document we will describe the problem of optimizing IGMP/MLD
operation over wireless technologies. Among the vast array of
underlying wireless technologies, we have selected three: IEEE
802.16e [802.16e] which is used in Mobile WiMAX, IEEE 802.11 which is
used in Wireless LAN or Wi-Fi deployments world-wide and 3GPP's
Evolved Packet System (EPS). This documents elaborates on some of
the problems discussed in [I-D.irtf-mobopts-mmcastv6-ps] and in
[I-D.asaeda-multimob-igmp-mld-mobility-extensions]. It also states
some newly emerging problems.
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 BCP 14 [RFC2119].
This document uses the terminology defined in [RFC3775], [RFC3376],
[RFC3810].
3. IGMP/MLD Operation over 802.16e
WiMAX Forum Release 1.5 has defined Multicast Broadcast Services
architecture. This architecture was based on Phase 1 requirements
defined by the service providers working group.
Figure 1 illustrates the key components of WiMAX Multicast Broadcast
Services (MCBCS) architecture.
Sarikaya & von Hugo Expires September 5, 2009 [Page 3]
Internet-Draft Mobile Multicast March 2009
Mobile | Access Network | Service Provider
Multicast User| | (Edge + Core Network)
+-----+ 802.16e +-----+ +------+ +------------+
| MN |-- link --| BS |-----+Access+---+Interface+------ | MCBCS |
+-----+ +-----+ |Router| to | Server |
| IGMP | CSN | IGMP |
+--+---+ +------------+
+-----+ +-----+ | /\
| MN |------------| BS |--------+ ||
+-----+ +-----+ ||
+-------+
|Content|
|Source |
+-------+
Figure 1: IGMP/MLD on IEEE 802.16e Links
Mobile nodes (MN) attach to a base station (BS) through wireless
interfaces. The Access Router (AR) located in the access service
network (ASN) is the first IP hop router of MNs. MN as the multicast
receiver uses the access network to receive the content coming from
the content network where the multicast source is located. The MCBCS
server in the connectivity service network (CSN) handles different
multicast content programs, multicast sessions, data encryption
support as well as IP multicast group management. Multicast enabled
core is assumed. MCBCS uses link layer multicasting defined by IEEE
however it also allows unicast tunneling where multicast is not
supported.
MCBCS considers broadcast services as pre-provisioned and requires
the service joining procedure always initiated by the network. In
network initiated join, MN immediately starts receiving the multicast
data after entering into the network. MN initiated join using IGMP
join message is also defined as an optional procedure.
In the current MCBCS specification, IGMP is required in two places:
MCBCS server and the AR which is the primary node that manages link
layer multicast/broadcast (MBS) zones called primary MBS distribution
Data Path Function. MCBCS server does group management of all
multicast groups served by various content sources in the core
network. MBS Distribution DPF does group management to make sure
that it is connected to the multicast tree that originates in the CSN
as a leaf. MBS Distribution DPF also behaves like a multicast source
for the MBS zone it serves to which other nodes join.
Sarikaya & von Hugo Expires September 5, 2009 [Page 4]
Internet-Draft Mobile Multicast March 2009
IGMP needs to be supported at the MN also. MN then can join/ leave
multicast groups at will not requiring MN to join at the network
entry. However MN is required to have subscribed to the service
already.
3.1. Problem Statement
First downlink/uplink multicast related problems will be stated
followed by Phase 2 requirements related problems.
IEEE 802.16e [802.16e] supports downlink multicast from the base
stations to MNs. Multicast traffic is carried at the link layer in
connections identified by multicast version of Connection Identifier
[RFC5121] called multicast CID which is 12 bits long.
Uplink multicast from MN to BS is not defined in [802.16e].
The following are the problems based on downlink/uplink multicast:
o Transmission of IP packets via service specific convergence
sublayer is defined in [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]
for IPv4 and [RFC5121] for IPv6. Mapping of the multicast group
address which is in the destination address field of IPv6/v4
datagram to a field in MAC header such as multicast CID is
currently not defined in both documents. Because of this it is
not guaranteed that multicast datagrams belonging to the same
multicast group would be carried using the same multicast CID
downlink.
o Duplicating multicast datagram for each member MN in the group and
then sending them unicast is proposed as a possible approach in
[I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]. It is suggested that
the multicast destination address is converted into MN IPv4
unicast address during the downlink packet duplication. Such an
approach might break applications that are based on receiving
multicast datagrams.
o Regarding uplink multicast support, since the link between MN and
AR is point-to-point, it makes it necessary for the AR to become
the multicast source. In case of a mobile MN that would mean all
ARs should have this capability. This makes it difficult to have
multicast source mobility support in 802.16e links.
Phase 2 requirements relevant to IGMP/MLD include:
o MN initiated activation of additional MCBCS sessions while
delivering the MCBCS program.
o Dynamic multicast group support enabling applications like multi-
player games.
Sarikaya & von Hugo Expires September 5, 2009 [Page 5]
Internet-Draft Mobile Multicast March 2009
o MCBCS Layer-2 security.
Based on Phase 2 requirements we can state the following problems for
group management protocols on IEEE 802.16e links:
o IGMP/MLD routers generate unsolicited group membership reports.
When such a message is generated destined to a mobile node and if
the mobile node is in dormant mode then MN has to be waken up
using the idle mode and paging system before delivering the
message. It is undesirable to wake up a dormant mobile node
unless there is an arrival of a new call.
o Dynamic multicast group support means MN can join a multicast
group even if it was not previously subscribed to such a service.
MN in this case has to be authenticated and authorized. Usually
network entry triggers such actions. In this case authentication
and authorization needs to be triggered by IGMP/MLD join message.
o Unlike DHCP which also defines messages exchanged on the local
link, IGMP/MLD lacks security.
4. IGMP/MLD Operation over 3GPP evolved packet system (EPS)
3GPP Release 8 (LTE/SAE) has defined Multimedia Broadcast/Multicast
Service (MBMS) architecture in 3GPP TS 23.246 [23246] and
corresponding enhancements for GPRS towards the evolved Radio Access
Network (RAN) in 3GPP TS 23.401 [23401]. Whereas within 3GPP an
optional use of the GPRS Tunneling Protocol (GTP) for mobility
support is described in 3GPP TS 23.401 [23401], in 3GPP TS 23.402
[23402] the architecture enhancements for non-3GPP accesses (e.g.,
via IEEE technology) are described containing the concept that EPS
supports both IETF-based network- and host-based mobility management
mechanisms (e.g., PMIP, MIP) via several interfaces.
4.1. Mobility between evolved 3G and non-3G access
Figure 2 illustrates a possible handover between 3G eUTRAN access and
non-3G IP access during a multicast session.
Sarikaya & von Hugo Expires September 5, 2009 [Page 6]
Internet-Draft Mobile Multicast March 2009
Mobile | Access Network | 3G Service and Core Network Provider
Multicast | |
User | |
+-----+ eUTRAN +-----+ +-------+ +------------+
| MN |-- link --| eNB |-----+Serving+----------------------+ PCRF |
+-----+ +-----+ |Access | | |
|Gateway| | |
+--+----+ +-+----------+
S5/S8 |
| |
+-----+ +-----+ +--+----+ | /\
| MN |--non-3G----| AP |-----+ | | ||
+-----+ link +-----+ | PDN +------------------------+ ||
|Gateway| +-------+
+-------+ |Content|
|Source |
+-------+
Figure 2: Mobility between 3GPP EPS links and non-3GPP access
PCRF is the element for dynamic control of policy and charging
required for QoS preservation. Interface between PDN Gateway and
serving Access Gateway which is S5 in case of same operator and S8 in
case of different operators for 3G and non 3G access is assumed to be
PMIP-based. Then serving Access Gateway is a Mobile Access Gateway
(MAG) according to PMIPv6 [RFC5213] but needs not to. The PDN GW
includes the LMA functionality according to PMIPv6 [RFC5213].
According to 3GPP TS 23.402 [23402] the Serving GW does not require
full MAG and full LMA functionality.
4.2. Multicast support in evolved 3GPP
3GPP TS 23.246 [23246] provides a reference architecture for Evolved
Packet System with E-UTRAN (MBMS Broadcast Mode only) shown in
Figure 3.
Sarikaya & von Hugo Expires September 5, 2009 [Page 7]
Internet-Draft Mobile Multicast March 2009
Mobile | Access Network | 3G Service and Core Network Provider
Multicast | |
User | |
+-------+
| PDN |
+-------+ +------------+ |Gateway|
+-----+ eUTRAN +-----+ |Serving+----+ MBMS1 | +---+---+
| MN |- link -| eNB |--|Access | +------------+ |
+-----+ +-----+ |Gateway| +-----+----+
| +----+------------+ | | +-------+
+-------+ | MBMS2 +---+ eBM-SC +--+Content|
+------------+ +----------+ | source|
+-------+
Figure 3: MBMS architecture for LTE 3GPP eUTRAN
The eBM-SC (evolved Broadcast-Multicast Service Centre) uses both
MBMS Bearers and EPS Bearers (over two different interfaces between
MBMS2 and eMB-SC). MBMS1 functions include:
o Session control of MBMS bearers to the E-UTRAN access (including
reliable delivery of Session Start/Session Stop to E-UTRAN);
o Transmision of Session control messages towards multiple eNBs;
o Provision of an interface to the MBMS2 function: it receives MBMS
service control messages and the IP Multicast address for MBMS
data reception from MBMS2 function over this interface.
MBMS2 functions include:
o Provision of an interface for entities using MBMS bearers (via
eMB-SC) through user plane and control plane reference points
o IP multicast distribution of MBMS user plane data to eNB;
o Content synchronization for MBMS over Single Frequency Networks;
o Header compression for MBSFN MBMS data;
o Allocation of an IP Multicast address to which the eNB should join
to receive the MBMS data. This IP Multicast address is provided
to the eNB via MBMS1 function;
It is still under discussion how these functions are allocated to
functional entity/entities of the Evolved Packet System. The MCE
(Multi-cell/Multicast Co-ordination Entity) is neither shown in the
figure nor defined in 3GPP TS 23.246 [23246].
4.3. IGMP/MLD Support in Evolved 3GPP
TBD.
Sarikaya & von Hugo Expires September 5, 2009 [Page 8]
Internet-Draft Mobile Multicast March 2009
4.4. Problem Statement
TBD.
5. IGMP/ MLD on IEEE 802.11 Links
Multicast address mapping into Layer 2 MAC address for IEEE 802.11
follows the Ethernet model. The lower 23 bits of the 28-bit
multicast IPv4 address are mapped into the 23 bits of available
Ethernet address space. Like in the case of IEEE 802.16e there is
ambiguity in delivering packets which will result in delivering
packets to hosts that subscribed to a different multicast group.
MAC address corresponding to multicast IPv6 address is derived from
the four low-order octets. There is a similar problem of ambiguity
in the delivery which requires the network software in the host to
discard the packets from unsubscribed multicast groups.
Without power save mode (dormant mode in 802.11) multicast packets
are delivered after each beacon with a default interval of 100ms. If
power save mode is enabled, multicast traffic is delivered after 1,2,
or 3 beacon intervals. Therefore beacon interval settings and
Delivery Traffic Indication Message (DTIM) should be adjusted for
optimum performance.
802.11 access points support different data rates. For multicast
traffic the lowest rates, e.g. 1Mbps are chosen to accomodate various
group members.
As in 802.16e, IGMP/MLD unsolicited membership report messages would
either wake up the mobile in power save mode because DTIM period is
usually smaller than power save period.
As in 802.16e, authentication support and security are needed in
IGMP/MLD especially for enterprise wireless LANs.
6. Security Considerations
This draft introduces no additional messages. Compared to [RFC3376],
[RFC3810] and [RFC3775] there is no additional threats to be
introduced.
7. IANA Considerations
None.
Sarikaya & von Hugo Expires September 5, 2009 [Page 9]
Internet-Draft Mobile Multicast March 2009
8. Acknowledgements
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
9.2. Informative References
[23246] "3GPP TS 23.246 V8.2.0, Multimedia Broadcast/Multicast
Service (MBMS); Architecture and functional description
(Release 8).", 2008.
[23401] "3GPP TS 23.401 V8.2.0, General Packet Radio Service
(GPRS) enhancements for Evolved Universal Terrestrial
Radio Access Network (E-UTRAN) access (Release 8).", 2008.
[23402] "3GPP TS 23.402 V8.4.1, Architecture enhancements for non-
3GPP accesses (Release 8).", 2009.
[802.16e] "IEEE Std 802.16e: IEEE Standard for Local and
metropolitan area networks, Amendment for Physical and
Medium Access Control Layers for Combined Fixed and Mobile
Operation in Licensed Bands", October 2005.
[I-D.asaeda-multimob-igmp-mld-mobility-extensions]
Sarikaya & von Hugo Expires September 5, 2009 [Page 10]
Internet-Draft Mobile Multicast March 2009
Asaeda, H. and T. Schmidt, "IGMP and MLD Extensions for
Mobile Hosts and Routers",
draft-asaeda-multimob-igmp-mld-mobility-extensions-01
(work in progress), July 2008.
[I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]
Madanapalli, S., Park, S., Chakrabarti, S., and G.
Montenegro, "Transmission of IPv4 packets over IEEE
802.16's IP Convergence Sublayer",
draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04 (work in
progress), November 2008.
[I-D.irtf-mobopts-mmcastv6-ps]
Fairhurst, G., Schmidt, T., and M. Waehlisch, "Multicast
Mobility in MIPv6: Problem Statement and Brief Survey",
draft-irtf-mobopts-mmcastv6-ps-06 (work in progress),
February 2009.
[ITUIPTV] "IPTV Service Scenarios", May 2007.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Email: sarikaya@ieee.org
Dirk von Hugo
Deutsche Telecom Laboratories
Deutsche-Telekom-Allee 7
64295 Darmstadt, Germany
Email: dirk.von-hugo@telekom.de
Sarikaya & von Hugo Expires September 5, 2009 [Page 11]