idnits 2.17.1 draft-sijeon-netlmm-mms-pmip6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 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 seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2009) is 5521 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) == Outdated reference: A later version (-03) exists of draft-zhao-multimob-pmip6-solution-02 -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Seil Jeon 3 Internet-Draft Univ. of Soongsil, Korea 4 Expires: September 7, 2009 Younghan Kim 5 Univ. of Soongsil, Korea 6 March 7, 2009 8 Mobile Multicasting Support in Proxy Mobile IPv6 9 draft-sijeon-netlmm-mms-pmip6-01.txt 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 7, 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 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 To support IP-based group mobile communication, such as mobile IPTV, 49 IP multicasting is required. Two major constraints in mobile 50 multicasting are the tunnel convergence problem and high handover 51 latency. To reduce the constraints, several mobile multicasting 52 schemes based on Mobile IP have been proposed. To meet requirements, 53 we present a multicasting architecture and fast handover scheme for 54 Proxy Mobile IPv6 (PMIPv6). 56 Table of Contents 58 1. Introduction.....................................................3 59 2. Conventions & Terminology........................................3 60 3. PMIPv6 Multicasting Architecture.................................4 61 4. Handover Operation...............................................4 62 5. Message Formats..................................................4 63 6. IANA Considerations..............................................5 64 7. Acknowledgment...................................................6 65 7. Security Considerations..........................................6 66 8. Acknowledgment...................................................6 67 9. References.......................................................6 68 9.1. Normative References.........................................6 69 Author's Address....................................................8 71 1. Introduction 73 High performance of wireless technologies enable multimedia streaming 74 service such as IPTV audio/video stream. Since these services are 75 based on group communication, IP multicasting is also required. 76 Traditional IP multicast mechanisms, including multicast routing and 77 membership management protocols, have been designed for static hosts 78 [2]. Moreover, up to now, IP mobility protocols for mobile 79 multicasting depended on host-based Mobile IP variants (Mobile IP and 80 Fast Mobile IPv6). However, Mobile IP variant protocols require 81 modifications to a applied solution on mobile devices and IP 82 reconfiguration during handoff. The Proxy Mobile IPv6 (PMIPv6) in [3] 83 does not require any mobility related protocol and IP reconfiguration 84 in the same PMIPv6 domain. With the strength of PMIPv6, several 85 service solutions are described in [4]. However, the solution needs 86 to solve two major constraints which are the tunnel convergence 87 problem and high handover latency [5]. Thus, we present a 88 multicasting architecture and fast handover operation considering the 89 requirements for PMIPv6. 91 2. Terminology and Functional Components 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [1]. 96 o Mobile Node (MN) 98 o Previous Mobile Access Gateway (P-MAG) - The MAG that manages 99 mobility relaged signaling for a MN before handover. In this 100 document, a MAG and Access Router (AR) are collocated 102 o New Mobile Access Gateway (N-MAG) - The MAG that manages mobility 103 related signaling for the MN after handover 105 o Multicast Router (MR) 107 o MLD Forwarding Proxy (MF-Proxy) 109 o PMIPv6 Multicast Context Transfer (MCT) - It is transmitted by the 110 P-MAG forecasting MN's destination to the N-MAG. This message 111 includes a MN ID, a MN home network prefix and a P-MAG IP address, 112 and multicast group address of the MN executing handoff. 114 3. PMIPv6 Multicasting Architecture 116 Multicast Core Tree 117 : 118 : 119 | 120 +----------+ +----------+ 121 | LMA | | Local MR | 122 +----------+ +----------+ 123 | | 124 |-----------------+ | 125 | | | 126 | +------------------| 127 | | | | 128 +----------+ | | +----------+ 129 | P-MAG |---+ +----| N-MAG | 130 |(MF-Proxy)| |(MF-Proxy)| 131 +----------+ +----------+ 132 : : 133 +------+ +------+ 134 | MN | -----> | MN | 135 +------+ +------+ 137 Figure 1: Multicasting architecture in PMIPv6 domain 139 To design PMIPv6-based multicasting services, we should consider the 140 position of the multicast router (MR). If a LMA contains the MR 141 function, it introduces a tunnel convergence problem similar to 142 Mobile IP variant bi-directional tunnel schemes. To solve the 143 problem, we separate the MR function from the LMA. Moreover, if a MAG 144 has a MR function and a local MR is connected with MAGs, the routing 145 update overhead degrades the performance of PMIPv6 components due to 146 frequent MNs' movement. Thus, Figure 1 shows the proposed PMIPv6 147 multicasting architecture where the MAG only contains a MLD 148 forwarding proxy function using the IGMP/MLD forwarding proxy [6] 149 proposed by the IETF. This model can solve the tunnel convergence 150 problem and reduce the routing processing overhead. 152 4. Handover Operation 154 MN P-MAG N-MAG LMA MR Multicast Tree 155 | | | | | | 156 | | | | | | 157 Link->| Handover | | | | 158 Disconnected Detection | | | | 159 | | | | | | 160 | |--PMIPv6-->| | | | 161 | | Multicast | | | | 162 | | Context | | | | 163 | | Transfer | | | | 164 | | | | | | 165 | | |-MLD Membership Report>| | 166 | | | | | | 167 |---- L2 Attachment --->| | | | 168 | | | Proxy | | | 169 | | |--Binding->| | | 170 | | | Update | | | 171 | | | | | | 172 | | | Proxy | | | 173 | | |<-Binding--| | | 174 | | | Ack. | | | 175 | | | | | | 176 |<--------------------------Multicast Data------------------| 177 | | | | | | 178 | | | | | | 180 Figure 2: Fast multicast handover procedure using PMIPv6 182 Directly applying a PMIPv6 handover scheme to the proposed network 183 model leads to service disruption due to the latency cased by MLD 184 query/report. To solve this problem, we propose a fast handover 185 scheme using the context transfer mechanism. Figure 2 shows handover 186 operation. When a MN hands off, the MAG with MLD forwarding proxy 187 predicts an MN's movement direction and transfers the multicast 188 context message, which includes the MN ID, the MN home network 189 prefix, the current MAG address, and the multicast group address. 190 Then, the N-MAG checks whether it is a receiving node of multicast 191 data corresponding to the group requested by the P-MAG. If this is 192 not the case, it joins the group by sending a MLD report. 194 5. Message Formats 196 TBD 198 6. IANA Considerations 200 TBD 202 7. Security Considerations 204 This document does not discuss any special security concerns in 205 detail. The protocol of this document is built on the assumption 206 that all participating nodes are trusted each other as well as there 207 is no adversary who modifies/injects false messages to corrupt the 208 procedures. 210 8. Acknowledgment 212 This work was supported by the IT R&D program of MKE/IITA. [Research 213 on Ubiquitous Mobility Management Methods for Higher Service 214 Availability] 216 8. References 218 8.1. Normative References 220 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 221 Levels", BCP 14, RFC 2119, March 1997. 223 [2] R. Vida, and L. Costa, "Multicast Listener Discovery Version(MLDv2) 224 for IPv6," IETF RFC 3810, June 2004. 226 [3] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. 227 Patil, "Proxy Mobile IPv6", IETF RFC 5213, Augurst 2008. 229 [4] Y. K. Zhao, P. Seite, "The Solution for PMIPv6 Multicast Service," 230 draft-zhao-multimob-pmip6-solution-02.txt, November 2008. 232 [5] I. Romdhani, M. Kellil, and H. Lach, "IP Mobile Multicast : Chal- 233 lenges and Solutions," IEEE Communications Surveys & Tutorials, 234 vol. 6, no. 1, pp. 18-41, 2004. 236 [6] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet Group Man- 237 agement Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 238 Multicast Forwarding ("IGMP/MLD Proxying")", IETF RFC 4605, August 239 2006. 241 Author's Addresses 243 Seil Jeon 244 University of Soongsil in Seoul 245 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 246 Dongjak-Gu, Seoul 156-743 Korea 247 Phone: +82 2 814 0151 248 E-mail: sijeon@dcn.ssu.ac.kr 250 Younghan Kim 251 University of Soongsil in Seoul 252 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 253 Dongjak-Gu, Seoul 156-743 Korea 254 Phone: +82 2 820 0904 255 E-mail: yhkim@dcn.ssu.ac.kr