idnits 2.17.1 draft-sijeon-multimob-direct-routing-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6424]), 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 11, 2011) is 4672 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) ** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029) == Outdated reference: A later version (-06) exists of draft-zuniga-multimob-smspmip-05 Summary: 2 errors (**), 0 flaws (~~), 3 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 Younghan Kim 4 Intended status: Standards Track Soongsil University, Korea 5 Expires: January 11, 2012 July 11, 2011 7 PMIPv6 Multicasting Support using Native Infrastructure 8 draft-sijeon-multimob-direct-routing-pmip6-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. The list of current Internet-Drafts is at 19 http://datatracker.ietf.org/drafts/current/. 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 January 11, 2012. 34 Copyright Notice 36 Copyright (c) 2011 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. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 To support IP multicasting in PMIPv6 domain, [RFC6424] has been 64 determined as a base solution. This solution requires all the LMA to 65 forward multicast packets to MAG via PMIPv6 tunnel. This approach 66 creates a tunnel convergence problem. To resolve the issue, the 67 current MULTIMOB WG charter is trying to draw a solution about how to 68 separate multicasting routing from a mobility anchor. To address the 69 issue, we propose the local routing approach that makes the direct 70 connection between MAG and multicast router. The advantages of the 71 proposed local routing solution are compared with the base solution 72 and dedicated LMA approach. In addition, we present the applicability 73 of local routing solution depending on several constraints. 75 Table of Contents 77 1. Introduction.....................................................4 78 2. Terminology and Functional Components............................5 79 3. Local Routing Solution...........................................6 80 3.1. Architecture.................................................6 81 3.2. Handover Procedure...........................................7 82 4. Comparison with Base Solution, Dedicated LMA, and Local Routing..8 83 4.1. Tunnel Convergence...........................................8 84 4.2. Complexity in LMA............................................8 85 4.3. Packet Overhead..............................................8 86 4.4. Another Advantage............................................9 87 5. Applicability....................................................9 88 6. Message Header...................................................9 89 6.1. MLD Query....................................................9 90 6.2. MLD Report..................................................10 91 6.3. Multicast Packet............................................10 92 7. IANA Considerations.............................................11 93 8. Security Considerations.........................................11 94 9. References......................................................11 95 9.1. Normative References........................................11 96 9.2. Informative References......................................12 97 Authors' Addresses.................................................13 99 1. Introduction 101 PMIPv6 is a network-based IP mobility protocol that requires no host 102 stack involvements; it provides enhanced mobility performance 103 compared to host-based approaches like MIPv6, FMIPv6. However, 104 current PMIPv6 specification does not explicitly address the method 105 of multicasting communications [RFC5213]. 107 To support multicasting in PMIPv6 domain, the base solution proposes 108 deployment option [RFC6424], which places multicast routing on LMA. 109 MAG receives a multicast stream from LMA by using PMIPv6 tunnel. It 110 is simply derived from PMIPv6 specification and requires no 111 modification to PMIPv6 components and MNs. However, the base solution 112 introduces a tunnel convergence issue in case a MAG receives the same 113 multicast packets from more than one LMA. This causes severe network 114 bandwidth. To avoid a tunnel convergence problem, the current 115 MULTIMOB WG charter is trying to d a solution on how to separate 116 multicasting routing from the mobility anchor. As potential 117 techniques, two kinds of approaches have been presented: a dedicated 118 mobility anchor and local routing. 120 The concept of dedicated LMA is to assign dedicated multicasting LMA 121 to each MAG. This approach resolves tunnel convergence issues but 122 introduces tunnel avalanche problem because M-LMA needs to replicate 123 data streams to all MAGs. It imposes a heavy burden on the M-LMA to 124 process and forward tunnel packets. Additionally, it makes severe 125 packet tunneling overhead. 127 In this draft, we propose a local routing solution that a MAG 128 receives multicast packets directly from MR without any tunnel. This 129 solution can completely solve tunnel-related performance issues by 130 placing MLD proxy on a MAG and allowing multicast connectivity 131 between the MAG and MR. With the description of local routing 132 operation, we present the comparisons of a few of candidate solutions 133 in terms of performance. In addition, we also check the applicability 134 of local routing depending on several constraints. 136 2. Terminology and Functional Components 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC2119. 142 o Mobile Node (MN) 144 o Previous Mobile Access Gateway (P-MAG) - The MAG that manages 145 mobility related signaling for a MN before handover. 147 o New Mobile Access Gateway (N-MAG) - The MAG that manages mobility 148 related signaling for the MN after handover 150 o Multicast Router (MR) 152 o MLD Proxy (M-Proxy) 154 3. Local Routing Solution 156 3.1. Architecture 158 Multicast Tree 159 : 160 : || - PMIPv6 Tunnel 161 +----------+ +----------+ | - Multicast Data Path 162 | LMA | | MR | 163 +----------+ +----------+ 164 ||\\ /| 165 || \\ / | 166 || \\ / | 167 || \\ / | 168 || \\/ | 169 || / \\ | 170 || / \\ | 171 || / \\ | 172 +----------+ +----------+ 173 | P-MAG | | N-MAG | 174 |(M-Proxy) | |(M-Proxy) | 175 +----------+ +----------+ 176 : : 177 +------+ +------+ 178 | MN | -----> | MN | 179 +------+ +------+ 181 Figure 1. Direct routing solution for PMIPv6 Multicasting 183 Figure 1 shows the proposed local routing architecture using native 184 multicasting infrastructure [I-D.deng-multimob-pmip6-requirement]. To 185 forward IGMP/MLD signaling and multicast packets, a MLD proxy 186 function defined in [RFC4605], SHOULD be placed on a MAG. This 187 solution is much simpler than the base solution and easy to deploy 188 because multicasting functions are totally separated from mobility 189 anchor by using a native multicasting infrastructure. 191 3.2. Handover Procedure 193 Multicast 194 MN P-MAG N-MAG LMA MR Tree 195 | | | | | | 196 | | | | | | 197 |<----------|<-- Multicast Data--------------|<-------| 198 | | . | | | | 199 | | . | | | | 200 | | . | | | | 201 Link->| Handover | | | | 202 Disconnected Detection | | | | 203 | | | | | | 204 | | | | | | 205 | | MN Attachment | | | 206 | | | | | | 207 | | | | | | 208 |------ Rtr. Sol. ----->| | | | 209 | | | | | | 210 |<----- MLD Query ------| | | | 211 | | | | | | 212 |------ MLD Report ---->| | | | 213 | | | Aggregated | | 214 | | |--- MLD Report ---->| | 215 | | | | | | 216 | | | | | | 217 |<----------------------|<-- Multicast Data--|<-------| 218 | | | | | | 219 | | | | | | 220 | | | Proxy | | | 221 | | |--Binding->| | | 222 | | | Update | | | 223 | | | | | | 224 | | | Proxy | | | 225 | | |<-Binding--| | | 226 | | | Ack. | | | 227 | | | | | | 229 Figure 2. Handover procedure in direct routing architecture 231 Figure 2 shows the handover operation in local routing architecture. 232 When an MN hands off to the N-MAG from the P-MAG, the N-MAG detects 233 the newly arrived MN and transmits an MLD query message to the MN. 234 After receiving the MLD query message, the MN sends an MLD report 235 message that includes the multicast group information. The N-MAG then 236 sends an aggregated MLD report message to the MR. When the N-MAG 237 receives the multicast packets from the MR, it then simply forwards 238 them without tunnel encapsulation. The N-MAG updates the MN's 239 location information to the LMA by exchanging PBU/PBA signaling 240 messages. 242 4. Comparison with Base Solution, Dedicated LMA, and Local Routing 244 In this section, we compare the direct routing with the base solution 245 [RFC6424] and dedicated LMA [I-D.zuniga-multimob-smspmip] in terms of 246 performance, ease of deployment, and other factors. 248 4.1. Tunnel Convergence 250 In the base solution, the MR function is combined with LMA. Thus, all 251 the packets are delivered to MNs through PMIPv6 tunnel between MAG 252 and LMA, which raises the tunnel convergence problem. because a MAG 253 may receive the same multicast packets from several LMAs. Dedicated 254 LMA and the proposed direct routing have different approaches; 255 however, they can avoid the tunnel convergence issue. 257 4.2. Complexity in LMA 259 In the tunnel-based approaches, a LMA needs to deal with MLD 260 signaling, join/leave procedure, and tunnel packet processing (i.e., 261 encapsulating/decapsulating and tunnel packet lookup) as well as the 262 role of mobility anchor. When using a dedicated entity, these 263 complexities can be reduced but cannot be avoided completely. On the 264 other hand, the direct routing is absolutely not affected by these 265 complexities. 267 4.3. Packet Overhead 269 Using native multicasting infrastructure, local routing does not make 270 tunneling overhead for multicast data delivery while tunnel-based 271 approaches require 40 bytes of IP tunnel header per packet. According 272 as packet arrival rate increases, the overhead becomes much severe. 274 4.4. Another Advantage 276 When we consider that MNs move to non-PMIPv6 domains from PMIPv6 277 domains as described in [I-D.von-hugo-multimob-future-work], the 278 direct routing approach can provide a compatible method because it 279 does not depend on PMIPv6 tunnel for multicasting operation. 281 5. Applicability in Visited Network 283 If a multicast listener is in visited network, the local routing can 284 be applied on the condition that there are a multicast peering 285 entities, e.g., content delivery network (CDN), inter-domain 286 multicast routing like BGMP [RFC3913] or MBGP [RFC4765] in visited 287 network. At that time, the multicast channel used in home network MAY 288 be different in visited network therefore, the listener MAY need to 289 wait a time for joining the channel informed from visited network but 290 this latency can be reduced through handover optimization technique 291 with multicast context transfer. 293 In particular, the source in which the multicast listener is 294 interested and the receiver are in same visited network, the local 295 routing is used efficiently than tunnel-based multicast transmission 296 technique using home subscription because local routing provides much 297 optimized routing path for delivering multicast data transmission 298 regardless of the number of channels and receivers. 300 6. Message Formats 302 This section describes source and destination address of MLD 303 signaling messages. The interface A-B means that an interface on node 304 A, which is connected to node B. 306 6.1. MLD Query 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Interface | Source Address | Destination Address | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | MR-MAG | MR link local | [RFC2710], [RFC3810] | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | MAG-MN | MAG link local | [RFC2710], [RFC3810] | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 6.2. MLD Report 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Interface | Source Address | Destination Address | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | MN-MAG | MN link local | [RFC2710], [RFC3810] | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | MAG-MR | MAG link local | [RFC2710], [RFC3810] | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 6.3. Multicast Packets 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Interface | Source Address | Destination Address | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | MR-MAG | Streaming Source Addr. | Multicast Group Addr. | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | MAG-MN | Streaming Source Addr. | Multicast Group Addr. | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 7. IANA Considerations 338 TBD. 340 8. Security Considerations 342 This document does not discuss any special security concerns in 343 detail. The protocol of this document is built on the assumption that 344 all participating nodes are trusted each other as well as there is no 345 adversary who modifies/injects false messages to corrupt the 346 procedures. 348 9. References 350 9.1. Normative References 352 [RFC2710] S. Deering, W. Fenner, B. Harberman, "Multicast Listener 353 Discovery (MLD) for IPV6", IETF RFC 2710, October 1999. 355 [RFC3810] R. Vida, and L. Costa, "Multicast Listener Discovery 356 Version(MLDv2) for IPv6", IETF RFC 3810, June 2004. 358 [RFC5213] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and 359 B. Patil, "Proxy Mobile IPv6", IETF RFC 5213, August 2008. 361 [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet 362 Group Management Protocol (IGMP) / Multicast Listener 363 Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD 364 Proxying")", IETF RFC 4605, August 2006. 366 [RFC6424] T. Schmidt, M. Waehlisch, and S. Krishnan, "Base 367 Deployment for Multicast Listener Support in PMIPv6 368 Domains", IETF RFC 6424, April 2011. 370 9.2. Informative References 372 [RFC3913] D. Thaler, "Border Gateway Multicast Protocol (BGMP): 373 Protocol Specification," IETF RFC 3913, September 2004. 375 [RFC4765] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, 376 "Multiprotocol Extensions for BGP-4," IETF RFC 4765, 377 January 2007. 379 [I-D.deng-multimob-pmip6-requirement] 380 H. Deng, T. Schmidt, P. Seite, and P. Yang, "Multicast 381 Support Requirements for Proxy Mobile IPv6", draft-deng- 382 multimob-pmip6-requirement-02.txt (work in progress), July 383 2009. 385 [I-D.zuniga-multimob-smspmip] 386 J. C. Zuniga, A. Rahman, L. M. Contreras, C. J. Bernardos, 387 and I. Soto, "Support Multicast Services Using Proxy Mobil 388 IPv6," draft-zuniga-multimob-smspmip-05.txt (work in 389 progress), March 2011. 391 [I-D.von-hugo-multimob-future-work] 392 D. von Hugo, H. Asaeda, B. Sarikaya, and P. Seite, 393 "Evaluation of further issues on Multicast Mobility: 394 Potential future work for WG MultiMob", draft-von-hugo- 395 multimob-future-work-02.txt (work in progress), Juney 396 2010. 398 Authors' Addresses 400 Seil Jeon 401 Soongsil University 402 4F Hyungnam Engineering Bldg. 424, Sangdo-Dong, 403 Dongjak-Gu, Seoul 156-743 Korea 404 Phone: +82-2-820-0841 405 E-mail: sijeon@dcn.ssu.ac.kr 407 Younghan Kim 408 Soongsil University 409 11F Hyungnam Engineering Bldg. 1107, Sangdo-Dong, 410 Dongjak-Gu, Seoul 156-743 Korea 411 Phone: +82-2-820-0904 412 E-mail: yhkim@dcn.ssu.ac.kr