idnits 2.17.1 draft-sijeon-multimob-mms-pmip6-02.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-multimob-pmipv6-base-solution]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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, 2010) is 5167 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 (-07) exists of draft-ietf-multimob-pmipv6-base-solution-00 == Outdated reference: A later version (-02) exists of draft-von-hugo-multimob-future-work-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Seil Jeon 3 Internet-Draft Soongsil University, Korea 4 Intended status: Standards Track Younghan Kim 5 Expires: September 4, 2010 Soongsil University, Korea 6 March 4, 2010 8 Mobile Multicasting Support in Proxy Mobile IPv6 9 draft-sijeon-multimob-mms-pmip6-02.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 4, 2010. 34 Copyright Notice 36 Copyright (c) 2010 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. Please review these documents carefully, as they 45 describe your rights and restrictions with respect to this document. 46 Code Components extracted from this document must include Simplified 47 BSD License text as described in Section 4.e of the Trust Legal 48 Provisions and are provided without warranty as described in the 49 Simplified BSD License. 51 Abstract 53 To support IP multicasting in PMIPv6 domain, [I-D.ietf-multimob- 54 pmipv6-base-solution] has been submitted as a base solution that 55 locates MR on the LMA and uses the PMIPv6 tunnel between LMA and MAG 56 for MLD messages. In this draft, we present the direct routing 57 solution that uses the direct connection between MAG and MR, and 58 locates the MLD forwarding proxy function on MAGs. The proposed 59 direct routing solution is compared with the base deployment 60 solution. 62 Table of Contents 64 1. Introduction.....................................................4 65 2. Terminology and Functional Components............................5 66 3. Direct Routing Solution..........................................6 67 3.1. Architecture.................................................6 68 3.2. Handover Operation...........................................7 69 4. Comparison with Base Deployment Solution and Direct Routing Soluti 70 on...............................................................8 71 4.1. Tunnel Convergence Problem...................................8 72 4.2. Complexity in LMA............................................8 73 4.3. Other Advantage..............................................8 74 5. Message Header...................................................9 75 5.1. MLD Query....................................................9 76 5.2. MLD Report...................................................9 77 5.3. Multicast Packet.............................................9 78 6. IANA Considerations.............................................10 79 7. Security Considerations.........................................10 80 8. References......................................................10 81 8.1. Normative References........................................10 82 8.2. Informative References......................................11 83 Author's Address...................................................12 85 1. Introduction 87 To support multicasting service in PMIPv6 domain, it is required to 88 determine which multicasting function should be placed on which 89 PMIPv6 component. From such a point of view, mobile multicasting 90 solutions could be classified into two categories: a MR co-located 91 LMA approach and a MR separated LMA approach. In the former case, the 92 MR function is placed on LMA and the IGMP/MLD forwarding proxy 93 function [RFC4605] is located on MAG. The MR co-located LMA approach 94 is proposed a base solution [I-D.ietf-multimob-pmipv6-base-solution] 95 without any modifications of [RFC5213]. But it introduces the tunnel 96 convergence problem that a MAG may receive same multicast packets 97 from several LMAs, which leads to waste of network bandwidth usage. 98 In this draft, we propose a MR separated LMA approach without any 99 load on LMA, which allows MAGs to receive multicast packets directly 100 from MRs. So, it has not tunnel convergence problem and reduces the 101 complexity on the LMA. Moreover, this solution could be also used in 102 the environment that is not applied with PMIPv6 protocol. 104 2. Terminology and Functional Components 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119] 110 o Mobile Node (MN) 112 o Previous Mobile Access Gateway (P-MAG) - The MAG that manages 113 mobility related signaling for a MN before handover. 115 o New Mobile Access Gateway (N-MAG) - The MAG that manages mobility 116 related signaling for the MN after handover 118 o Multicast Router (MR) 120 o MLD Forwarding Proxy (MF-Proxy) 122 3. Direct Routing Solution 124 3.1. Architecture 126 Multicast Tree 127 : 128 : || - PMIPv6 Tunnel 129 +----------+ +----------+ | - Multicast Data Path 130 | LMA | | Local MR | 131 +----------+ +----------+ 132 ||\\ /| 133 || \\ / | 134 || \\ / | 135 || \\ / | 136 || \\/ | 137 || / \\ | 138 || / \\ | 139 || / \\ | 140 +----------+ +----------+ 141 | P-MAG | | N-MAG | 142 |(MF-Proxy)| |(MF-Proxy)| 143 +----------+ +----------+ 144 : : 145 +------+ +------+ 146 | MN | -----> | MN | 147 +------+ +------+ 149 Figure 1. Direct Routing Solution for PMIPv6 Multicasting 151 Figure 1 shows the proposed mobile multicasting solution for Proxy 152 Mobile IPv6. There is no multicast routing function on the LMA. We 153 call it the direct routing solution based on local routing scenario 154 described in [I-D.deng-multimob-pmip6-requirement]. This solution has 155 not tunnel convergence issue caused by a MAG receives the same 156 multicast packets from several LMAs. To forward IGMP/MLD signaling 157 and multicast packets, a MAG needs only the MLD forwarding proxy 158 function defined in [RFC4605]. This solution is more simple than the 159 base deployment solution and easy to deploy because LMAs are 160 separated from multicast operation. 162 3.2. Handover Operation 164 Multicast 165 MN P-MAG N-MAG LMA MR Tree 166 | | | | | | 167 | | | | | | 168 |<----------|<-- Multicast Data--------------|<-------| 169 | | . | | | | 170 | | . | | | | 171 | | . | | | | 172 Link->| Handover | | | | 173 Disconnected Detection | | | | 174 | | | | | | 175 | | | | | | 176 | | MN Attachment | | | 177 | | | | | | 178 | | | | | | 179 |------ Rtr. Sol. ----->| | | | 180 | | | | | | 181 |<----- MLD Query ------| | | | 182 | | | | | | 183 |------ MLD Report ---->| | | | 184 | | | Aggregated | | 185 | | |--- MLD Report ---->| | 186 | | | | | | 187 | | | | | | 188 |<----------------------|<-- Multicast Data--|<-------| 189 | | | | | | 190 | | | | | | 191 | | | Proxy | | | 192 | | |--Binding->| | | 193 | | | Update | | | 194 | | | | | | 195 | | | Proxy | | | 196 | | |<-Binding--| | | 197 | | | Ack. | | | 198 | | | | | | 200 Figure 2. Handover Operation for Direct Routing Solution 202 Figure 2 shows the handover operation for direct routing solution. 203 When an MN hands off to the N-MAG from the P-MAG, the N-MAG detects 204 the newly arrived MN and transmits an MLD Query message to the MN. 205 After receiving the MLD Query message, the MN sends an MLD Report 206 message that includes the multicast group information. The N-MAG then 207 sends an aggregated MLD Report message to the MR. When the N-MAG 208 receives the multicast packets from the MR, it then simply forwards 209 them without tunnel encapsulation. The N-MAG needs to update the MN's 210 location information to the LMA by exchanging PBU/PBA signaling 211 messages. 213 4. Comparison with Base Deployment Solution and Direct Routing Solution 215 In this section, we compare the direct routing solution with the base 216 deployment solution [I-D.ietf-multimob-pmipv6-base-solution] in terms 217 of performance, easiness in deployment and others. 219 4.1. Tunnel Convergence Problem 221 In the base deployment solution, the MR function is combined with 222 LMA. Thus, all the packets are delivered to MNs through PMIPv6 tunnel 223 between MAG and LMA, which raises the tunnel convergence problem 224 because a MAG may receive the same multicast packets from several 225 LMAs. The proposed direct routing solution does not introduce tunnel 226 convergence problem because a MAG is directly connected to only one 227 MR. 229 4.2. Complexity in LMA 231 In the base deployment solution, the MR function is combined with LMA 232 that should process the MLD messages and perform the join/leave 233 procedure with other multicast routers accordingly. The complexity 234 will increase as the number of multicast channels increases. 236 4.3. Other Advantage 238 When we consider the MN's handover case from PMIPv6 domains to non- 239 PMIPv6 domains as described in [I-D.von-hugo-multimob-future-work], 240 we could also use the direct routing solution because it does not 241 depend on PMIPv6 tunnel for multicasting operation. 243 5. Message Formats 245 This section describes source and destination address of MLD 246 signaling messages. The interface A-B means that an interface on node 247 A, which is connected to node B. 249 5.1. MLD Query 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Interface | Source Address | Destination Address | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | MR-MAG | MR link local | [RFC2710], [RFC3810] | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | MAG-MN | MAG link local | [RFC2710], [RFC3810] | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 5.2. MLD Report 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Interface | Source Address | Destination Address | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | MN-MAG | MN link local | [RFC2710], [RFC3810] | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MAG-MR | MAG link local | [RFC2710], [RFC3810] | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 5.3. Multicast Packets 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Interface | Source Address | Destination Address | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | MR-MAG | Streaming Source Addr. | Multicast Group Addr. | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | MAG-MN | Streaming Source Addr. | Multicast Group Addr. | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 6. IANA Considerations 281 TBD. 283 7. Security Considerations 285 This document does not discuss any special security concerns in 286 detail. The protocol of this document is built on the assumption that 287 all participating nodes are trusted each other as well as there is no 288 adversary who modifies/injects false messages to corrupt the 289 procedures. 291 8. References 293 8.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC2710] S. Deering, W. Fenner, B. Harberman, "Multicast Listener 299 Discovery (MLD) for IPV6", IETF RFC 2710, October 1999. 301 [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery 302 Version(MLDv2) for IPv6", IETF RFC 3810, June 2004. 304 [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and 305 B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, Augurst 306 2008. 308 [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet 309 Group Management Protocol (IGMP) / Multicast Listener 310 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD 311 Proxying")", IETF RFC 4605, August 2006. 313 8.2. Informative References 315 [I-D.deng-multimob-pmip6-requirement] 316 H. Deng, T. Schmidt, P. Seite, and P. Yang, "Multicast 317 Support Requirements for Proxy Mobile IPv6", draft-deng- 318 multimob-pmip6-requirement-02.txt (work in progress), July 319 2009. 321 [I-D.ietf-multimob-pmipv6-base-solution] 322 T.C. Schmidt, M. Waehlisch, S. Krishnan, "Base Deployment 323 for Multicast Listener Support in PMIPv6 Domains", draft- 324 ietf-multimob-pmipv6-base-solution-00.txt (work in 325 progress), February 2010. 327 [I-D.von-hugo-multimob-future-work] 328 D. von Hugo, H. Asaeda, B. Sarikaya, P. Seite, "Evaluation 329 of further issues on Multicast Mobility: Potential future 330 work for WG MultiMob", draft-von-hugo-multimob-future- 331 work-01.txt (work in progress), February 2010. 333 Author's Addresses 335 Seil Jeon 336 Soongsil University 337 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 338 Dongjak-Gu, Seoul 156-743 Korea 339 Phone: +82 2 814 0151 340 E-mail: sijeon@dcn.ssu.ac.kr 342 Younghan Kim 343 Soongsil University 344 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, 345 Dongjak-Gu, Seoul 156-743 Korea 346 Phone: +82 2 820 0904 347 E-mail: yhkim@dcn.ssu.ac.kr