idnits 2.17.1 draft-deng-multimob-ps-mobilemulticast-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 282. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '...k, a mobile node MUST join the multica...' RFC 2119 keyword, line 146: '...care-of address, the home agent SHOULD...' RFC 2119 keyword, line 148: '..., the home agent MUST first encapsulat...' RFC 2119 keyword, line 150: '...address and then MUST tunnel the resul...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2008) is 5767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'DSMIPv6' ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track P. Yang 5 Expires: January 14, 2009 Hitachi 6 Q. Wu 7 Tsinghua Univ. 8 July 13, 2008 10 Problem Statement and Requirement: Mobile Multicast 11 draft-deng-multimob-ps-mobilemulticast-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2009. 38 Abstract 40 This document discusses the problem and requirement of multicast 41 solution in the mobile networks. One current issue in mobile 42 multicast solution has been raised and requirements of mobile IPTV on 43 multicast mobility will also be summarized especially for some 44 mechanisms such as the tunneling, service capability and security 45 discussion which is basis of supporting the mobile IPTV applications. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. IP mobility management multicast support in mobile network . . 4 51 2.1. Mobile IPTV multicast framework . . . . . . . . . . . . . 4 52 2.2. Mobile IPv4 support Multicast . . . . . . . . . . . . . . 4 53 2.3. Mobile IPv6 support Multicast . . . . . . . . . . . . . . 5 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 5. Normative References . . . . . . . . . . . . . . . . . . . . . 9 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 58 Intellectual Property and Copyright Statements . . . . . . . . . . 11 60 1. Introduction 62 While more and more operators begin to provide the wireless broadband 63 network systems, the needs for multicast and and broadcast service in 64 mobile network become promising. Recently IPTV might become one of 65 the desirable applications for mobile network. Mobile IPTV service 66 is a kind of A/V services which are combined with interactive data 67 for the related or supplementary information of A/V program using bi- 68 directional wireless broadband links. User can enjoy the downlink 69 A/V stream and access more detailed or value-added information via 70 uplink simultaneously. 72 In the mobile network, Mobile IPv4 (MIPv4)[RFC3344], Mobile 73 IPv6[RFC3775], DSMIP6 [DSMIPv6] and PMIP6[Gundavelli08]is the basic 74 way to support IP mobility management. It allows the mobile 75 nodes(MN) to maintain the reachability while moving in the IP 76 network. After registration to home agent(HA), the packets destined 77 to MN could be routed correctly by using the tunneling mechanism, 78 while MN is away from the home network. 80 But the current IP mobility management mechanism lack of full support 81 of multicast service.This document will illustrate the main issue of 82 them. Since DSMIP6 is principally similar to MIP6, so it will not be 83 illustrated independently in this document. 85 2. IP mobility management multicast support in mobile network 87 2.1. Mobile IPTV multicast framework 89 ITU make detailed description on IPTV architecture and multicast 90 framewroks. Mobile IPTV content delivery infrastructure may consists 91 of four different layers, i.e. Content Source, Core, Metro(Edge), 92 and Access. Content source is where IPTV service contents are 93 originated and they can be placed in either inside or outside of 94 delivery infrastructure. Core is service/network provider_is 95 backbone infrastructure. Metro, in other words Aggregation or Edge, 96 is where it connects and aggregates between core and access. Access 97 is user domain that includes last mile. 99 The transport profile of Mobile IPTV are shown in the picture below: 101 Wired or Wireless 102 | 103 | +.........................................+ 104 +----------+ | . Mobile IPTV Transport Profile . 105 | Mobile | V . +--------+ +------+ +------+ . 106 | IPTV |---------| Access |------| Edge |------| Core | . 107 | Terminal | . +--------+ +------+ +------+ . 108 +----------+ . // || || . 109 . // || || . 110 . +-------------+ || || . 111 . | Content |==============|| || . 112 . | Source | || . 113 . +-------------+ || . 114 +................\\...................||..+ 115 \\ || 116 +----------------+ || 117 | content source |== 118 +----------------+ 120 In the case of IPTV support in mobile network, such architecture will 121 be considered and mapped to the network entity of IP mobility 122 management. 124 2.2. Mobile IPv4 support Multicast 126 Section 4.3 and 4.4 of [RFC3344] discuss the support of multicast and 127 broadcast. In order to receive multicast packet through it's home 128 network, a mobile node MUST join the multicast group in one of two 129 ways. One is based on co-located care-of address, the other is based 130 on the home address (foreign agent care-of address). In both cases, 131 a mobile node tunnels IGMP messages to its home agent, the home agent 132 forwards multicast datagrams down the tunnel to the mobile node. 134 Access network 135 (Wired or Wireless) IP multicast 136 | packets 137 +----+ | | 138 | MN1| V +------+ +------+ | 139 +----+---------------|======|=============| | | 140 +----+ | FA | | HA | V 141 | MN2|---------------|======|=============| |----- 142 +----+ +------+ +------+ 144 Figure 1: Nested tunneling in MIP4 for Multicast 146 In the case of co-located care-of address, the home agent SHOULD 147 tunnel the datagram to this care-of address directly; In the case of 148 foreign agent care-of address, the home agent MUST first encapsulate 149 the datagram in a unicast datagram addressed to the mobile node's 150 home address and then MUST tunnel the resulting datagram (nested 151 tunneling) to the mobile node's care-of address.If there are more 152 than 500 MNs under the same FA, there will be 500 tunnels between HA 153 and FA to transmit multicast packets. 155 2.3. Mobile IPv6 support Multicast 157 In this document, the analysis on multicast of mobile IPv6 will be 158 made only based on mobile IPTV. The Home Agent(HA) may be part of 159 the core function in the mobile IPTV framework. The edge function 160 normally coould be considered as the access gateway(AGW) in the 161 deployment of mobile IPv6 in mobile network. 163 Access network 164 (Wired or Wireless) IP multicast 165 +------+ | packets 166 | | | | 167 | MN | V +------+ +------+ | 168 | |===============|======|=============| | | 169 +------+ | | | | V 170 bi-dictional tunnel | AR | | HA |----- 171 +------+ | | | | 172 | |===============|======|=============| | 173 | MN | +------+ +------+ 174 | | 175 +------+ 177 Figure 2: Nested tunneling in MIP6 for Multicast 179 Notification: it's recommended to have some notification machenism in 180 mobile IPv6. It's useful to do synchronous actions for incoming 181 mobile IPTV service events. 183 By the way, it is recommended that DSMIP6 has similar situation, and 184 Proxy mobile IPv6 will be described in a seperate document. 186 3. Security Considerations 188 Multicast security is one of the most crucial issues in mobile IPTV 189 service such that it is required to provide security capabilities to 190 protect mobile IPTV multicast network from any malicious attempts 191 caused by multicast security holes such as denial of service attacks. 193 After the integration IP mobility management like MIP4, MIP6 with the 194 multicast service, it should not depreciate the security protection 195 of the basic IP mobility management mechanism. 197 4. IANA Considerations 199 This document makes no requests to IANA. 201 5. Normative References 203 [DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and 204 Routers (DSMIPv6)", 205 draft-ietf-mip6-nemo-v4traversal-06.txt (work in 206 progress), November 2007. 208 [Gundavelli08] 209 Gundavelli, S., "Proxy Mobile IPv6", 210 draft-ietf-netlmm-proxymip6-18.txt (work in progress), 211 May 2008. 213 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 214 August 2002. 216 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 217 in IPv6", RFC 3775, June 2004. 219 Authors' Addresses 221 Hui Deng 222 China Mobile 223 53A,Xibianmennei Ave., 224 Xuanwu District, 225 Beijing 100053 226 China 228 Email: denghui02@gmail.com 230 Peng Yang 231 Hitachi 232 301, North Wing, Tower C Raycom Infotech Park 233 2 kexueyuan Nanlu 234 Haidian District 235 Beijing, 100080 236 P.R. China 238 Phone: +861082862918(ext.)328 239 Email: pyang@hitachi.cn 241 Qian Wu 242 Tsinghua Univ. 244 Full Copyright Statement 246 Copyright (C) The IETF Trust (2008). 248 This document is subject to the rights, licenses and restrictions 249 contained in BCP 78, and except as set forth therein, the authors 250 retain all their rights. 252 This document and the information contained herein are provided on an 253 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 254 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 255 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 256 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 257 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 258 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 260 Intellectual Property 262 The IETF takes no position regarding the validity or scope of any 263 Intellectual Property Rights or other rights that might be claimed to 264 pertain to the implementation or use of the technology described in 265 this document or the extent to which any license under such rights 266 might or might not be available; nor does it represent that it has 267 made any independent effort to identify any such rights. Information 268 on the procedures with respect to rights in RFC documents can be 269 found in BCP 78 and BCP 79. 271 Copies of IPR disclosures made to the IETF Secretariat and any 272 assurances of licenses to be made available, or the result of an 273 attempt made to obtain a general license or permission for the use of 274 such proprietary rights by implementers or users of this 275 specification can be obtained from the IETF on-line IPR repository at 276 http://www.ietf.org/ipr. 278 The IETF invites any interested party to bring to its attention any 279 copyrights, patents or patent applications, or other proprietary 280 rights that may cover technology that may be required to implement 281 this standard. Please address the information to the IETF at 282 ietf-ipr@ietf.org.