idnits 2.17.1 draft-sarikaya-multimob-overwireless-ps-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 4, 2009) is 5532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3314' is defined on line 389, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-04) exists of draft-asaeda-multimob-igmp-mld-mobility-extensions-01 == Outdated reference: A later version (-07) exists of draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04 == Outdated reference: A later version (-09) exists of draft-irtf-mobopts-mmcastv6-ps-06 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Informational D. von Hugo 5 Expires: September 5, 2009 Deutsche Telecom Laboratories 6 March 4, 2009 8 Group Management Protocol Operation Over Wireless Problem Statement 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 Multicast mobility using existing IETF protocols is inefficient. 48 This document looks at the principal shorcomings in IGMP/MLD that 49 arise from operating over three wireless links, IEEE 16e used in 50 Mobile WiMAX, IEEE 802.11 used in Wi-Fi networks and 3GPP. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IGMP/MLD Operation over 802.16e . . . . . . . . . . . . . . . 3 57 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 58 4. IGMP/MLD Operation over 3GPP evolved packet system (EPS) . . . 6 59 4.1. Mobility between evolved 3G and non-3G access . . . . . . 6 60 4.2. Multicast support in evolved 3GPP . . . . . . . . . . . . 7 61 4.3. IGMP/MLD Support in Evolved 3GPP . . . . . . . . . . . . . 8 62 4.4. Problem Statement . . . . . . . . . . . . . . . . . . . . 9 63 5. IGMP/ MLD on IEEE 802.11 Links . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 More and more operators are beginning to provide the wireless 75 broadband network services such as Mobile IPTV. Mobile IPTV service 76 is a kind of audio/video (A/V) service which is combined with 77 interactive data for the related or supplementary information of A/V 78 program using bi-directional wireless broadband links. Users can 79 enjoy the downlink A/V stream and request more detailed or value- 80 added information via uplink simultaneously. Mobile IPTV service, 81 which can also be described as place-shifting IPTV service, is to 82 ensure continuous and original IPTV experiences for the users who 83 move to the other place from where he or she was originally 84 subscribed for [ITUIPTV]. 86 Apart from Mobile IPTV which is considered "the killer application", 87 content broadcasting and streaming over audio and video conferencing, 88 online multiplayer gaming are applications of IP multicast technology 89 for mobile users. 91 In this document we will describe the problem of optimizing IGMP/MLD 92 operation over wireless technologies. Among the vast array of 93 underlying wireless technologies, we have selected three: IEEE 94 802.16e [802.16e] which is used in Mobile WiMAX, IEEE 802.11 which is 95 used in Wireless LAN or Wi-Fi deployments world-wide and 3GPP's 96 Evolved Packet System (EPS). This documents elaborates on some of 97 the problems discussed in [I-D.irtf-mobopts-mmcastv6-ps] and in 98 [I-D.asaeda-multimob-igmp-mld-mobility-extensions]. It also states 99 some newly emerging problems. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14 [RFC2119]. 107 This document uses the terminology defined in [RFC3775], [RFC3376], 108 [RFC3810]. 110 3. IGMP/MLD Operation over 802.16e 112 WiMAX Forum Release 1.5 has defined Multicast Broadcast Services 113 architecture. This architecture was based on Phase 1 requirements 114 defined by the service providers working group. 116 Figure 1 illustrates the key components of WiMAX Multicast Broadcast 117 Services (MCBCS) architecture. 119 Mobile | Access Network | Service Provider 120 Multicast User| | (Edge + Core Network) 122 +-----+ 802.16e +-----+ +------+ +------------+ 123 | MN |-- link --| BS |-----+Access+---+Interface+------ | MCBCS | 124 +-----+ +-----+ |Router| to | Server | 125 | IGMP | CSN | IGMP | 126 +--+---+ +------------+ 127 +-----+ +-----+ | /\ 128 | MN |------------| BS |--------+ || 129 +-----+ +-----+ || 130 +-------+ 131 |Content| 132 |Source | 133 +-------+ 135 Figure 1: IGMP/MLD on IEEE 802.16e Links 137 Mobile nodes (MN) attach to a base station (BS) through wireless 138 interfaces. The Access Router (AR) located in the access service 139 network (ASN) is the first IP hop router of MNs. MN as the multicast 140 receiver uses the access network to receive the content coming from 141 the content network where the multicast source is located. The MCBCS 142 server in the connectivity service network (CSN) handles different 143 multicast content programs, multicast sessions, data encryption 144 support as well as IP multicast group management. Multicast enabled 145 core is assumed. MCBCS uses link layer multicasting defined by IEEE 146 however it also allows unicast tunneling where multicast is not 147 supported. 149 MCBCS considers broadcast services as pre-provisioned and requires 150 the service joining procedure always initiated by the network. In 151 network initiated join, MN immediately starts receiving the multicast 152 data after entering into the network. MN initiated join using IGMP 153 join message is also defined as an optional procedure. 155 In the current MCBCS specification, IGMP is required in two places: 156 MCBCS server and the AR which is the primary node that manages link 157 layer multicast/broadcast (MBS) zones called primary MBS distribution 158 Data Path Function. MCBCS server does group management of all 159 multicast groups served by various content sources in the core 160 network. MBS Distribution DPF does group management to make sure 161 that it is connected to the multicast tree that originates in the CSN 162 as a leaf. MBS Distribution DPF also behaves like a multicast source 163 for the MBS zone it serves to which other nodes join. 165 IGMP needs to be supported at the MN also. MN then can join/ leave 166 multicast groups at will not requiring MN to join at the network 167 entry. However MN is required to have subscribed to the service 168 already. 170 3.1. Problem Statement 172 First downlink/uplink multicast related problems will be stated 173 followed by Phase 2 requirements related problems. 175 IEEE 802.16e [802.16e] supports downlink multicast from the base 176 stations to MNs. Multicast traffic is carried at the link layer in 177 connections identified by multicast version of Connection Identifier 178 [RFC5121] called multicast CID which is 12 bits long. 180 Uplink multicast from MN to BS is not defined in [802.16e]. 182 The following are the problems based on downlink/uplink multicast: 184 o Transmission of IP packets via service specific convergence 185 sublayer is defined in [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs] 186 for IPv4 and [RFC5121] for IPv6. Mapping of the multicast group 187 address which is in the destination address field of IPv6/v4 188 datagram to a field in MAC header such as multicast CID is 189 currently not defined in both documents. Because of this it is 190 not guaranteed that multicast datagrams belonging to the same 191 multicast group would be carried using the same multicast CID 192 downlink. 193 o Duplicating multicast datagram for each member MN in the group and 194 then sending them unicast is proposed as a possible approach in 195 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs]. It is suggested that 196 the multicast destination address is converted into MN IPv4 197 unicast address during the downlink packet duplication. Such an 198 approach might break applications that are based on receiving 199 multicast datagrams. 200 o Regarding uplink multicast support, since the link between MN and 201 AR is point-to-point, it makes it necessary for the AR to become 202 the multicast source. In case of a mobile MN that would mean all 203 ARs should have this capability. This makes it difficult to have 204 multicast source mobility support in 802.16e links. 206 Phase 2 requirements relevant to IGMP/MLD include: 208 o MN initiated activation of additional MCBCS sessions while 209 delivering the MCBCS program. 210 o Dynamic multicast group support enabling applications like multi- 211 player games. 213 o MCBCS Layer-2 security. 215 Based on Phase 2 requirements we can state the following problems for 216 group management protocols on IEEE 802.16e links: 218 o IGMP/MLD routers generate unsolicited group membership reports. 219 When such a message is generated destined to a mobile node and if 220 the mobile node is in dormant mode then MN has to be waken up 221 using the idle mode and paging system before delivering the 222 message. It is undesirable to wake up a dormant mobile node 223 unless there is an arrival of a new call. 224 o Dynamic multicast group support means MN can join a multicast 225 group even if it was not previously subscribed to such a service. 226 MN in this case has to be authenticated and authorized. Usually 227 network entry triggers such actions. In this case authentication 228 and authorization needs to be triggered by IGMP/MLD join message. 229 o Unlike DHCP which also defines messages exchanged on the local 230 link, IGMP/MLD lacks security. 232 4. IGMP/MLD Operation over 3GPP evolved packet system (EPS) 234 3GPP Release 8 (LTE/SAE) has defined Multimedia Broadcast/Multicast 235 Service (MBMS) architecture in 3GPP TS 23.246 [23246] and 236 corresponding enhancements for GPRS towards the evolved Radio Access 237 Network (RAN) in 3GPP TS 23.401 [23401]. Whereas within 3GPP an 238 optional use of the GPRS Tunneling Protocol (GTP) for mobility 239 support is described in 3GPP TS 23.401 [23401], in 3GPP TS 23.402 240 [23402] the architecture enhancements for non-3GPP accesses (e.g., 241 via IEEE technology) are described containing the concept that EPS 242 supports both IETF-based network- and host-based mobility management 243 mechanisms (e.g., PMIP, MIP) via several interfaces. 245 4.1. Mobility between evolved 3G and non-3G access 247 Figure 2 illustrates a possible handover between 3G eUTRAN access and 248 non-3G IP access during a multicast session. 250 Mobile | Access Network | 3G Service and Core Network Provider 251 Multicast | | 252 User | | 254 +-----+ eUTRAN +-----+ +-------+ +------------+ 255 | MN |-- link --| eNB |-----+Serving+----------------------+ PCRF | 256 +-----+ +-----+ |Access | | | 257 |Gateway| | | 258 +--+----+ +-+----------+ 259 S5/S8 | 260 | | 261 +-----+ +-----+ +--+----+ | /\ 262 | MN |--non-3G----| AP |-----+ | | || 263 +-----+ link +-----+ | PDN +------------------------+ || 264 |Gateway| +-------+ 265 +-------+ |Content| 266 |Source | 267 +-------+ 269 Figure 2: Mobility between 3GPP EPS links and non-3GPP access 271 PCRF is the element for dynamic control of policy and charging 272 required for QoS preservation. Interface between PDN Gateway and 273 serving Access Gateway which is S5 in case of same operator and S8 in 274 case of different operators for 3G and non 3G access is assumed to be 275 PMIP-based. Then serving Access Gateway is a Mobile Access Gateway 276 (MAG) according to PMIPv6 [RFC5213] but needs not to. The PDN GW 277 includes the LMA functionality according to PMIPv6 [RFC5213]. 278 According to 3GPP TS 23.402 [23402] the Serving GW does not require 279 full MAG and full LMA functionality. 281 4.2. Multicast support in evolved 3GPP 283 3GPP TS 23.246 [23246] provides a reference architecture for Evolved 284 Packet System with E-UTRAN (MBMS Broadcast Mode only) shown in 285 Figure 3. 287 Mobile | Access Network | 3G Service and Core Network Provider 288 Multicast | | 289 User | | 290 +-------+ 291 | PDN | 292 +-------+ +------------+ |Gateway| 293 +-----+ eUTRAN +-----+ |Serving+----+ MBMS1 | +---+---+ 294 | MN |- link -| eNB |--|Access | +------------+ | 295 +-----+ +-----+ |Gateway| +-----+----+ 296 | +----+------------+ | | +-------+ 297 +-------+ | MBMS2 +---+ eBM-SC +--+Content| 298 +------------+ +----------+ | source| 299 +-------+ 301 Figure 3: MBMS architecture for LTE 3GPP eUTRAN 303 The eBM-SC (evolved Broadcast-Multicast Service Centre) uses both 304 MBMS Bearers and EPS Bearers (over two different interfaces between 305 MBMS2 and eMB-SC). MBMS1 functions include: 306 o Session control of MBMS bearers to the E-UTRAN access (including 307 reliable delivery of Session Start/Session Stop to E-UTRAN); 308 o Transmision of Session control messages towards multiple eNBs; 309 o Provision of an interface to the MBMS2 function: it receives MBMS 310 service control messages and the IP Multicast address for MBMS 311 data reception from MBMS2 function over this interface. 313 MBMS2 functions include: 314 o Provision of an interface for entities using MBMS bearers (via 315 eMB-SC) through user plane and control plane reference points 316 o IP multicast distribution of MBMS user plane data to eNB; 317 o Content synchronization for MBMS over Single Frequency Networks; 318 o Header compression for MBSFN MBMS data; 319 o Allocation of an IP Multicast address to which the eNB should join 320 to receive the MBMS data. This IP Multicast address is provided 321 to the eNB via MBMS1 function; 323 It is still under discussion how these functions are allocated to 324 functional entity/entities of the Evolved Packet System. The MCE 325 (Multi-cell/Multicast Co-ordination Entity) is neither shown in the 326 figure nor defined in 3GPP TS 23.246 [23246]. 328 4.3. IGMP/MLD Support in Evolved 3GPP 330 TBD. 332 4.4. Problem Statement 334 TBD. 336 5. IGMP/ MLD on IEEE 802.11 Links 338 Multicast address mapping into Layer 2 MAC address for IEEE 802.11 339 follows the Ethernet model. The lower 23 bits of the 28-bit 340 multicast IPv4 address are mapped into the 23 bits of available 341 Ethernet address space. Like in the case of IEEE 802.16e there is 342 ambiguity in delivering packets which will result in delivering 343 packets to hosts that subscribed to a different multicast group. 345 MAC address corresponding to multicast IPv6 address is derived from 346 the four low-order octets. There is a similar problem of ambiguity 347 in the delivery which requires the network software in the host to 348 discard the packets from unsubscribed multicast groups. 350 Without power save mode (dormant mode in 802.11) multicast packets 351 are delivered after each beacon with a default interval of 100ms. If 352 power save mode is enabled, multicast traffic is delivered after 1,2, 353 or 3 beacon intervals. Therefore beacon interval settings and 354 Delivery Traffic Indication Message (DTIM) should be adjusted for 355 optimum performance. 357 802.11 access points support different data rates. For multicast 358 traffic the lowest rates, e.g. 1Mbps are chosen to accomodate various 359 group members. 361 As in 802.16e, IGMP/MLD unsolicited membership report messages would 362 either wake up the mobile in power save mode because DTIM period is 363 usually smaller than power save period. 365 As in 802.16e, authentication support and security are needed in 366 IGMP/MLD especially for enterprise wireless LANs. 368 6. Security Considerations 370 This draft introduces no additional messages. Compared to [RFC3376], 371 [RFC3810] and [RFC3775] there is no additional threats to be 372 introduced. 374 7. IANA Considerations 376 None. 378 8. Acknowledgements 380 TBD. 382 9. References 384 9.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third 390 Generation Partnership Project (3GPP) Standards", 391 RFC 3314, September 2002. 393 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 394 Thyagarajan, "Internet Group Management Protocol, Version 395 3", RFC 3376, October 2002. 397 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 398 in IPv6", RFC 3775, June 2004. 400 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 401 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 403 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 404 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 406 9.2. Informative References 408 [23246] "3GPP TS 23.246 V8.2.0, Multimedia Broadcast/Multicast 409 Service (MBMS); Architecture and functional description 410 (Release 8).", 2008. 412 [23401] "3GPP TS 23.401 V8.2.0, General Packet Radio Service 413 (GPRS) enhancements for Evolved Universal Terrestrial 414 Radio Access Network (E-UTRAN) access (Release 8).", 2008. 416 [23402] "3GPP TS 23.402 V8.4.1, Architecture enhancements for non- 417 3GPP accesses (Release 8).", 2009. 419 [802.16e] "IEEE Std 802.16e: IEEE Standard for Local and 420 metropolitan area networks, Amendment for Physical and 421 Medium Access Control Layers for Combined Fixed and Mobile 422 Operation in Licensed Bands", October 2005. 424 [I-D.asaeda-multimob-igmp-mld-mobility-extensions] 425 Asaeda, H. and T. Schmidt, "IGMP and MLD Extensions for 426 Mobile Hosts and Routers", 427 draft-asaeda-multimob-igmp-mld-mobility-extensions-01 428 (work in progress), July 2008. 430 [I-D.ietf-16ng-ipv4-over-802-dot-16-ipcs] 431 Madanapalli, S., Park, S., Chakrabarti, S., and G. 432 Montenegro, "Transmission of IPv4 packets over IEEE 433 802.16's IP Convergence Sublayer", 434 draft-ietf-16ng-ipv4-over-802-dot-16-ipcs-04 (work in 435 progress), November 2008. 437 [I-D.irtf-mobopts-mmcastv6-ps] 438 Fairhurst, G., Schmidt, T., and M. Waehlisch, "Multicast 439 Mobility in MIPv6: Problem Statement and Brief Survey", 440 draft-irtf-mobopts-mmcastv6-ps-06 (work in progress), 441 February 2009. 443 [ITUIPTV] "IPTV Service Scenarios", May 2007. 445 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 446 Madanapalli, "Transmission of IPv6 via the IPv6 447 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 448 February 2008. 450 Authors' Addresses 452 Behcet Sarikaya 453 Huawei USA 454 1700 Alma Dr. Suite 500 455 Plano, TX 75075 457 Email: sarikaya@ieee.org 459 Dirk von Hugo 460 Deutsche Telecom Laboratories 461 Deutsche-Telekom-Allee 7 462 64295 Darmstadt, Germany 464 Email: dirk.von-hugo@telekom.de