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 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]