idnits 2.17.1 draft-deng-multimob-pmip6-requirement-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R3 - The mobile node MAY remain agnostic of the multicast mobility management when roaming. In particular, the node MUST not be required to re-subscribe to multicast group(s) after handoff. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R4 - Multicast packet distribution within a PMIPv6 domain MUST not cause MTU-size conflicts on the network layer. In particular, path MTU discovery MUST NOT be required for multicast transmission. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R13 - The protocol MUST be robust against irregular moves of the MN (e.g. ping-pong mobility) and MUST not compromise (unicast) network performance. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-irtf-mobopts-mmcastv6-ps-07 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-13 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group H. Deng 3 Internet-Draft Gang. Chen 4 Intended status: Informational China Mobile 5 Expires: January 14, 2010 T. Schmidt 6 HAW Hamburg 7 P. Seite 8 France Telecom 9 P. Yang 10 Hitachi 11 July 13, 2009 13 Multicast Support Requirements for Proxy Mobile IPv6 14 draft-deng-multimob-pmip6-requirement-02 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on January 14, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 This document summarizes requirements for multicast listener support 63 in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to 64 PMIPv6, multicast mobility management requirements do not request any 65 active participation of the mobile node. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Scenarios of Multicast Support for PMIPv6 . . . . . . . . . . 5 71 3. Requirements for multicast support in PMIPv6 . . . . . . . . . 7 72 3.1. Basic functional requirements . . . . . . . . . . . . . . 7 73 3.2. Multicast performance requirements . . . . . . . . . . . . 7 74 4. Architecture requirements . . . . . . . . . . . . . . . . . . 9 75 4.1. LMA Requirements for multicast support in PMIPv6 . . . . . 9 76 4.2. MAG Requirements for multicast support in PMIPv6 . . . . . 9 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 Many of the current mobile network architectures as well as link 88 layer technologies provide an independent multicast/broadcast support 89 for dedicated group communication services, e.g., based on specific 90 wireless channels. Typically, applications like Internet IPTV, that 91 require voluminous content streams to be distributed to potentially 92 large numbers of receivers, may take benefit of this transport mode. 93 At the same time, with the development of mobile Internet protocols, 94 the need emerged for a seamlessly available multicast solution that 95 makes efficient use of the multipoint transmission technologies 96 deployed by operators [MMCASTv6-PS]. 98 As an example, mobile IPTV channels, which combine Audio/Video 99 programs with interactive data for supplementary information (using 100 bi-directional wireless broadband links), and with potential large 101 audience, may take particular advantage of any multicast/ broadcast 102 mobile support at access networks for downlink distribution of A/V 103 streams. 105 Among IP mobility management protocols, Proxy Mobile IPv6 (PMIPv6) 106 [RFC5213] has been designed to bring IP mobility making the mobile 107 nodes unaware of network layer changes. Functional entities in the 108 PMIPv6 infrastructure are the Local Mobility Anchor (LMA) and the 109 Mobile Access Gateway (MAG). The local mobility anchor is 110 responsible for maintaining the mobile node's reachability state and 111 is the topological anchor point for the mobile node's home network 112 prefix(es). The mobile access gateway performs mobility management 113 operations on behalf of the mobile node. Basically, the mobile 114 access gateway is responsible for detecting the mobile node's 115 movements, to and from the access link, and for initiating binding 116 registrations (i.e. location updates) to the mobile node's local 117 mobility anchor. 119 The current PMIPv6 specification lacks dedicated support of group 120 communication. To facilitate design of a multicast support in future 121 solutions, this document gathers requirements for multicast listener 122 support. In correspondance to PMIPv6, multicast mobility management 123 requirements should not request any active participation of the 124 mobile multicast recipient. 126 2. Scenarios of Multicast Support for PMIPv6 128 According to [RFC5213], two basic routing scenarios exist in PMIPv6: 129 the tunneling mode and local routing. The tunneling mode as 130 displayed in Figure 1 uses IPv6-in-IPv6 encapsulation [RFC2473] 131 (IPv6-in-IPv4 in [PMIPv6v4]) to transfer data between LMA and MAG. 132 Thus two entities are facing an avalanche problem (cf. 133 [MMCASTv6-PS]), the LMA in feeding multicast streams to the MAGs, and 134 the MAG in distributing multicast on air to the mobile nodes. 136 +-------------+ 137 | Content | 138 | Source | 139 +-------------+ 140 | 141 *** *** *** *** 142 * ** ** ** * 143 * * 144 * Fixed Internet * 145 * * 146 * ** ** ** * 147 *** *** *** *** 148 / \ 149 +----+ +----+ 150 |LMA1| |LMA2| 151 +----+ +----+ 152 LMAA1 | | LMAA2 153 | | 154 \\ //\\ 155 \\ // \\ 156 \\ // \\ 157 Unicast Tunnels --> \\ // \\ 158 \\ // \\ 159 \\ // \\ 160 Proxy-CoA1 || || Proxy-CoA2 161 +----+ +----+ 162 |MAG1| |MAG2| 163 +----+ +----+ 164 | | | 165 | | | 166 MN1 MN2 MN3 168 Figure 1: Multicast Scenario in PMIPv6 Tunneling Mode 170 The local routing option has been designed to support direct node to 171 node communication within a PMIPv6 domain. Assuming a locally 172 available content source, the local routing mode may give rise to the 173 scenario visualized in Figure 2. Local routing will resolve tunnel 174 convergence issues at the LMA but not the avalanche problem point to 175 the MAG. 177 +----+ +----+ 178 |LMA1| |LMA2| 179 +----+ +----+ 180 LMAA1 | | LMAA2 181 | | 182 *** *** *** *** 183 * ** ** ** * 184 * * +-------------+ 185 * Local Routing * _____ | Content | 186 * * | Source | 187 * ** ** ** * +-------------+ 188 *** *** *** *** 189 Proxy-CoA1 || || Proxy-CoA2 190 +----+ +----+ 191 |MAG1| |MAG2| 192 +----+ +----+ 193 | | | 194 | | | 195 MN1 MN2 MN3 197 Figure 2: Multicast Scenario for PMIPv6 Local Routing 199 PMIP multicast support must clearly address above issues but should 200 also bring good user experience of multicast mobility. In addition, 201 it is expected that the solution shall inherit from the basics of 202 PMIP scenarios; in particular mobility management should not require 203 to add specific functions to the IPv6 node. In these perspectives, 204 following sections summarize protocol and architecture requirements 205 for multicast support in Proxy Mobile IPv6. 207 3. Requirements for multicast support in PMIPv6 209 This section summarizes the requirements for mobile multicast 210 protocol extensions of PMIPv6. 212 3.1. Basic functional requirements 214 R1 - PMIPv6 multicast mobility management MUST transparently support 215 the reception of Any Source Multicast (ASM) or Source Specific 216 Multicast (SSM) channels. 218 R2 - The mobile node is responsible for initially subscribing to the 219 multicast group(s). 221 R3 - The mobile node MAY remain agnostic of the multicast mobility 222 management when roaming. In particular, the node MUST not be 223 required to re-subscribe to multicast group(s) after handoff. 225 R4 - Multicast packet distribution within a PMIPv6 domain MUST not 226 cause MTU-size conflicts on the network layer. In particular, path 227 MTU discovery MUST NOT be required for multicast transmission. 229 R5 - PMIPv6 multicast mobility management MUST comply with multicast 230 scoping rules and restrictions. 232 R6 - PMIPv6 multicast mobility management MUST equally cover IPv6/ 233 IPv4 only and dual stack nodes. 235 R7 - A multicast solution MUST be compatible with the existing PMIPv6 236 network architecture and protocol structure such as multihoming and 237 vertical handover. 239 3.2. Multicast performance requirements 241 R8 - PMIPv6 transmission SHOULD realize native multicast forwarding, 242 and where applicable conserve network resources and utilize link 243 layer multipoint distribution to avoid data redundancy. 245 R9 - The solution MUST minimize multicast forwarding delays to 246 provide seamless and fast handovers for real-time services. After a 247 handoff, multicast data SHOULD continue to reach the mobile listener 248 at a latency similar to unicast communication. 250 R10 - The PMIPv6 multicast mobility management SHOULD avoid to cause 251 packet loss in addition to unicast handoff. 253 R11 - Multicast mobility SHOULD minimize transport costs on the 254 forwarding link, as well as any additional overhead on the multicast 255 delivery path. 257 R12 - Routing convergence MUST be ensured, even when the MN moves 258 rapidly and performs handovers at a high frequency. 260 R13 - The protocol MUST be robust against irregular moves of the MN 261 (e.g. ping-pong mobility) and MUST not compromise (unicast) network 262 performance. 264 4. Architecture requirements 266 In addition to protocol requirements as listed in the preceeding 267 section, mobile multicast support for listeners MAY lead to 268 requirement on the PMIPv6 architectural entities. These potential 269 issues are sketched in the following sub-sections: 271 4.1. LMA Requirements for multicast support in PMIPv6 273 Multicast Bandwidth Control: LMA should be able to control the total 274 bandwidth of a user port that can be used for multicast service, 275 thereby monitoring the fraction of the total bandwidth consumed by 276 multicast. This requirement may lead to support a range of different 277 service classes with various QoS requirements. 279 Multicast AAA control: AAA functions MAY resident at the LMA, in 280 particular admission control and accounting, MAY be preserved and 281 applicable under multicast services. 283 Multicast forwarding: LMA could forward the multicast through unicast 284 IPv6 header between MN-HoA and LMA. 286 4.2. MAG Requirements for multicast support in PMIPv6 288 It is foreseeable that the MAG has to act as a multicast designated 289 router. Hence support of MLDv2 [RFC3810] or LW-MLDv2 is MAY be 290 required at the MAG. 292 Further MAG-specific requirements can be identified: 294 Access Control: it is required that Access Control based on available 295 resources is supported at the MAG. 297 5. Security Considerations 299 Multicast security is one of the most crucial issues in mobile 300 multicast service such that it is required to provide security 301 capabilities to protect mobile multicast network from any malicious 302 attempts caused by multicast security holes such as denial of service 303 attacks. 305 - The multicast service in PMIPv6 should not degrade the security 306 protection of the basic PMIPv6 AAA mechanism. 308 - Multicast system architecture is required to provide an admission 309 control mechanism to regulate any multicast events. 311 - Multicast system architecture is required to be independent of 312 adjacent domains such that it shall not affect the adjacent multicast 313 domain without permission. 315 - Multicast system architecture is required to provide a mechanism to 316 check integrity of multicast sources prior to service delivery such 317 that it prevents unauthorized source to distribute multicast content. 319 6. IANA Considerations 321 This document makes no requests to IANA. 323 7. Contributors 325 This document is a result of discussions in the multicast support for 326 PMIPv6 design team. The members of the design team that are listed 327 below are authors that have contributed to this document: 329 Pierrick Seite 331 pierrick.seite@orange-ftgroup.com 333 Peny Yang 335 pyang@hitachi.cn 337 Von-Hugo, Dirk 339 Dirk.Hugo@t-systems.com 341 Hitoshi Asaeda 343 asaeda@sfc.wide.ad.jp 345 Thomas C. Schmidt 347 schmidt@informatik.haw-hamburg.de 349 Suresh Krishnan 351 suresh.krishnan@ericsson.com 353 John Zhao 355 john.zhao@huawei.com 357 Matthias Waehlisch 359 mw@link-lab.net 361 Hui Deng 363 denghui@chinamobile.com 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 373 IPv6 Specification", RFC 2473, December 1998. 375 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 376 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 378 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 379 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 381 8.2. Informative References 383 [MMCASTv6-PS] 384 Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 385 Mobility in MIPv6: Problem Statement and Brief Survey", 386 draft-irtf-mobopts-mmcastv6-ps-07 (work in progress), 387 April 2009. 389 [PMIPv6v4] 390 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 391 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13 392 (work in progress), June 2009. 394 Authors' Addresses 396 Hui Deng (Editor) 397 China Mobile 398 53A,Xibianmennei Ave., 399 Xuanwu District, 400 Beijing 100053 401 China 403 Email: denghui02@gmail.com 405 Gang Chen (Editor) 406 China Mobile 407 53A,Xibianmennei Ave., 408 Xuanwu District, 409 Beijing 100053 410 China 412 Email: chengang@chinamobile.com 414 Thomas C. Schmidt (Editor) 415 HAW Hamburg 416 Dept. Informatik 417 Berliner Tor 7 418 Hamburg, D-20099 419 Germany 421 Email: Schmidt@informatik.haw-hamburg.de 423 Pierrick Seite (Editor) 424 France Telecom 425 4, rue du Clos Courtel 426 BP 91226 427 Cesson-Sevigne, 35512 428 France 430 Email: pierrick.seite@orange-ftgroup.com 431 Peng Yang (Editor) 432 Hitachi 433 301, North Wing, Tower C Raycom Infotech Park 434 2 kexueyuan Nanlu 435 Haidian District 436 Beijing, 100080 437 P.R. China 439 Phone: +861082862918(ext.)328 440 Email: pyang@hitachi.cn