idnits 2.17.1 draft-schmidt-multimob-pmipv6-base-source-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 : ---------------------------------------------------------------------------- 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 date (October 31, 2011) is 4560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2710' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 464, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T C. Schmidt 3 Internet-Draft HAW Hamburg 4 Intended status: Informational M. Waehlisch 5 Expires: May 3, 2012 link-lab & FU Berlin 6 M. Farooq 7 HAW Hamburg 8 October 31, 2011 10 Mobile Multicast Sender Support in PMIPv6 Domains with Base Multicast 11 Deployment 12 draft-schmidt-multimob-pmipv6-base-source-01 14 Abstract 16 Multicast communication can be enabled in Proxy Mobile IPv6 domains 17 by deploying MLD Proxy functions at Mobile Access Gateways, and 18 multicast routing functions at Local Mobility Anchors. This document 19 describes the support of mobile multicast senders in Proxy Mobile 20 IPv6 domains that is provided by this base deployment scenario. 21 Mobile sources remain agnostic of multicast mobility operations. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 3, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Source Mobility Details . . . . . . . . . . . . . . . . . . . 7 67 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 7 68 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 7 69 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 7 70 4.3.1. Local Mobility Anchors Operating PIM . . . . . . . . . 7 71 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.5. Efficiency of the Distribution System . . . . . . . . . . 9 73 4.6. Multicast Availability throughout the Access Network . . . 9 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 11 81 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 87 [RFC3775] by network-based management functions that enable IP 88 mobility for a host without requiring its participation in any 89 mobility-related signaling. Additional network entities called the 90 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 91 responsible for managing IP mobility on behalf of the mobile node 92 (MN). An MN connected to a PMIPv6 domain, which only operates 93 according to the base specifications of [RFC5213], cannot participate 94 in multicast communication, as MAGs will discard group packets. 96 Multicast support for mobile listeners can be enabled within a PMIPv6 97 domain by deploying MLD Proxy functions at Mobile Access Gateways, 98 and multicast routing functions at Local Mobility Anchors [RFC6224]. 99 This base deployment option is the simplest way to PMIPv6 multicast 100 extensions in the sense that it neither requires new protocol 101 operations nor additional infrastructure entities. Standard software 102 functions need to be activated on PMIPv6 entities, only, on the price 103 of possibly non-optimal multicast routing. 105 This document describes the support of mobile multicast senders in 106 Proxy Mobile IPv6 domains as it is provided by the base deployment 107 scenario [RFC6224]. Mobile Nodes in this setting remain agnostic of 108 multicast mobility operations. This document discusses implications 109 on multicast routing, but does not address specific optimizations and 110 efficiency improvements of multicast routing for network-based 111 mobility as discussed in [RFC5757]. 113 2. Terminology 115 This document uses the terminology as defined for the mobility 116 protocols [RFC3775], [RFC5213] and [RFC5844], as well as the 117 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 119 3. Overview 121 The reference scenario for multicast deployment in Proxy Mobile IPv6 122 domains is illustrated in Figure 1. 124 +-------------+ 125 | Multicast | 126 | Listeners | 127 +-------------+ 128 | 129 *** *** *** *** 130 * ** ** ** * 131 * * 132 * Fixed Internet * 133 * * 134 * ** ** ** * 135 *** *** *** *** 136 / \ 137 +----+ +----+ 138 |LMA1| |LMA2| Multicast Anchor 139 +----+ +----+ 140 LMAA1 | | LMAA2 141 | | 142 \\ //\\ 143 \\ // \\ 144 \\ // \\ Unicast Tunnel 145 \\ // \\ 146 \\ // \\ 147 \\ // \\ 148 Proxy-CoA1 || || Proxy-CoA2 149 +----+ +----+ 150 |MAG1| |MAG2| MLD Proxy 151 +----+ +----+ 152 | | | 153 MN-HNP1 | | MN-HNP2 | MN-HNP3 154 MN1 MN2 MN3 155 Multicast Sender + Listener(s) 157 Figure 1: Reference Network for Multicast Deployment in PMIPv6 with 158 Source Mobility 160 An MN in a PMIPv6 domain will decide on multicast data transmission 161 completely independent of its current mobility conditions. It will 162 send packets as initiated by applications, using its source address 163 with Home Network Prefix (HNP) and a multicast destination addresses 164 chosen by application needs. Multicast packets will arrive at the 165 currently active MAG via one of its downstream local (wireless) 166 links. A multicast unaware MAG would simply discard these packets in 167 the absence of a multicast forwarding information base (MFIB). 169 An MN can successfully distribute multicast data in PMIPv6, if MLD 170 proxy functions are deployed at the MAG as described in [RFC6224]. 171 In this set-up, the MLD proxy instance serving a mobile multicast 172 source has configured its upstream interface at the tunnel towards 173 MN's corresponding LMA. For each LMA, there will be a separate 174 instance of an MLD proxy. 176 According to the specifications given in [RFC4605], multicast data 177 arriving from a downstream interface of an MLD proxy will be 178 forwarded to the upstream interface and to all but the incoming 179 downstream interfaces with appropriate forwarding states for this 180 group. Thus multicast streams originating from an MN will arrive at 181 the corresponding LMA and directly at all mobile receivers co-located 182 at the same MAG. Serving as the designated multicast router or an 183 additional MLD proxy, the LMA forwards data to the fixed Internet, if 184 forwarding states are maintained through multicast routing. If the 185 LMA is acting as another MLD proxy, it will forward the multicast 186 data to its upstream interface, and based upon the downstream 187 interfaces' subscriptions accordingly. 189 In case of a handover, the MN (unaware of IP mobility) can continue 190 to send multicast packets as soon as network connectivity is 191 reconfigured. At this time, the MAG has determined the corresponding 192 LMA, and IPv6 unicast address configuration with PMIPv6 bindings have 193 been performed. Multicast packets arriving at the MAG are discarded 194 until the MAG has completed the following steps. 196 1. The MAG SHOULD determine whether the MN is admissible to 197 multicast services, and stop here otherwise. 199 2. The MAG adds the new downstream link to the MLD proxy instance 200 with up-link to the corresponding LMA. 202 As soon as the MN's uplink is associated with the corresponding MLD 203 proxy instance, multicast packets are forwarded again to the LMA and 204 eventually to receivers within the PMIP domain (see the call flow in 205 Figure 2). In this way, multicast source mobility is transparently 206 enabled in PMIPv6 domains that deploy the base scenario for 207 multicast. 209 MN1 MAG1 MN2 MAG2 LMA 210 | | | | | 211 | | Mcast Data | | | 212 | |<---------------+ | | 213 | | Mcast Data | | | 214 | Join(G) +================================================>| 215 +--------------> | | | | 216 | Mcast Data | | | | 217 |<---------------+ | | | 218 | | | | | 219 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 220 | | | | | 221 | | |--- Rtr Sol -->| | 222 | | |<-- Rtr Adv ---| | 223 | | | | | 224 | | | < MLD Proxy Configuration > | 225 | | | | | 226 | | | MLD Query | | 227 | | |<--------------+ | 228 | | | Mcast Data | | 229 | | +-------------->| | 230 | | | | Mcast Data | 231 | | | +===============>| 232 | | | | | 233 | | Mcast Data | | | 234 | |<================================================+ 235 | Mcast Data | | | | 236 |<---------------+ | | | 237 | | | | | 239 Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP 241 These multicast deployment considerations likewise apply for mobile 242 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 243 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 244 IPv4 multicast is handled by an IGMP proxy function at the MAG in an 245 analogous way. 247 Following these deployment steps, multicast traffic distribution 248 transparently inter-operates with PMIPv6. It is worth noting that a 249 MN - while being attached to the same MAG as the mobile source, but 250 associated with a different LMA, cannot receive multicast traffic on 251 a shortest path. Instead, multicast streams flow up to the LMA of 252 the mobile source, are transferred to the LMA of the mobile listener 253 and tunneled downwards to the MAG again (see Appendix A for further 254 considerations). 256 4. Source Mobility Details 258 Incorporating multicast source mobility in PMIPv6 requires to deploy 259 general multicast functions at PMIPv6 routers and to define their 260 interaction with the PMIPv6 protocol in the following way. 262 4.1. Operations of the Mobile Node 264 A Mobile Node willing to send multicast data will proceed as if 265 attached to the fixed Internet. No specific mobility or other 266 multicast related functionalities are required at the MN. 268 4.2. Operations of the Mobile Access Gateway 270 A Mobile Access Gateway is required to have MLD proxy instances 271 deployed corresponding to each LMA, taking the corresponding tunnel 272 as its unique upstream link, cf., [RFC6224]. On the arrival of a MN, 273 the MAG decides on the mapping of downstream links to a proxy 274 instance and the upstream link to the LMA based on the regular 275 Binding Update List as maintained by PMIPv6 standard operations. 276 When multicast data is received from the MN, the MAG MUST identify 277 the corresponding proxy instance from the incoming interface and 278 forwards multicast data upstream according to [RFC4605]. 280 The MAG MAY apply special admission control to enable multicast data 281 transition from a MN. It is advisable to take special care that MLD 282 proxy implementations do not redistribute multicast data to 283 downstream interfaces without appropriate subscriptions in place. 285 4.3. Operations of the Local Mobility Anchor 287 For any MN, the Local Mobility Anchor acts as the persistent Home 288 Agent and at the same time as the default multicast upstream for the 289 corresponding MAG. It will manage and maintain a multicast 290 forwarding information base for all group traffic arriving from its 291 mobile sources. It SHOULD participate in multicast routing functions 292 that enable traffic redistribution to all adjacent LMAs within the 293 PMIPv6 domain and thereby ensure a continuous receptivity while the 294 source is in motion. 296 4.3.1. Local Mobility Anchors Operating PIM 298 Local Mobility Anchors that operate the PIM routing protocol 299 [RFC4601] will require sources to be directly connected for sending 300 PIM registers to the RP. This does not hold in a PMIPv6 domain, as 301 MAGs are routers intermediate to MN and the LMA. In this sense, MNs 302 are multicast sources external to the PIM-SM domain. 304 To cure this defect common to all set-ups of subsidiary domains not 305 running PIM, the LMA should act as a PIM Border Router and activate 306 the Border-bit. In this case, the DirectlyConnected(S) is treated as 307 being TRUE for mobile sources and the PIM-SM forwarding rule "iif == 308 RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 309 interface from MAG to LMA is considered as not part of the PIM-SM 310 component of the LMA (see A.1 of [RFC4601] ). 312 4.4. IPv4 Support 314 An MN in a PMIPv6 domain may use an IPv4 address transparently for 315 communication as specified in [RFC5844]. For this purpose, LMAs can 316 register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide 317 IPv4 support in access networks. Correspondingly, multicast 318 membership management will be performed by the MN using IGMP. For 319 multicast support on the network side, an IGMP proxy function needs 320 to be deployed at MAGs in exactly the same way as for IPv6. 321 [RFC4605] defines IGMP proxy behaviour in full agreement with IPv6/ 322 MLD. Thus IPv4 support can be transparently provided following the 323 obvious deployment analogy. 325 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 326 SHOULD choose multicast signaling according to address configurations 327 on the link, but MAY submit IGMP and MLD queries in parallel, if 328 needed. It should further be noted that the infrastructure cannot 329 identify two data streams as identical when distributed via an IPv4 330 and IPv6 multicast group. Thus duplicate data may be forwarded on a 331 heterogeneous network layer. 333 A particular note is worth giving the scenario of [RFC5845] in which 334 overlapping private address spaces of different operators can be 335 hosted in a PMIP domain by using GRE encapsulation with key 336 identification. This scenario implies that unicast communication in 337 the MAG-LMA tunnel can be individually identified per MN by the GRE 338 keys. This scenario still does not impose any special treatment of 339 multicast communication for the following reasons. 341 Multicast streams from and to MNs arrive at a MAG on point-to-point 342 links (identical to unicast). between the routers and independent of 343 any individual MN. So the MAG-proxy and the LMA SHOULD NOT use GRE 344 key identifiers, but plain GRE encapsulation in multicast 345 communication (including MLD queries and reports). Multicast traffic 346 sent upstream and downstream of MAG-to-LMA tunnels proceeds as 347 router-to-router forwarding according to the multicast forwarding 348 information base (MFIB) of the MAG or LMA and independent of MN's 349 unicast addresses, while the MAG proxy instance re-distributes 350 multicast data down the point-to-point links (interfaces) according 351 to its own MFIB, independent of MN's IP addresses. 353 4.5. Efficiency of the Distribution System 355 In the following efficiency-related issues are enumerated. 357 Multicast reception at LMA In the current deployment scenario, the 358 LMA will receive all multicast traffic originating from its 359 associated MNs. There is no mechanism to suppress upstream 360 forwarding in the absence of receivers. 362 MNs on the same MAG using different LMAs For a mobile receiver and a 363 source that use different LMAs, the traffic has to go up to one 364 LMA, cross over to the other LMA, and then be tunneled back to the 365 same MAG, causing redundant flows in the access network and at the 366 MAG. 368 4.6. Multicast Availability throughout the Access Network 370 There may be deployment scenarios, where multicast services are 371 available throughout the access network independent of the PMIPv6 372 infrastructure. Direct multicast access at MAGs may be supported 373 through native multicast routing within a flat access network that 374 includes a multicast router, via dedicated (tunnel or VPN) links 375 between MAGs and designated multicast routers. 377 Multicast traffic distribution can be simplified in these scenarios. 378 A single proxy instance at MAGs with up-link into the multicast cloud 379 will serve as a first hop gateway into the multicast routing domain 380 and avoid traffic duplication or detour routing. However, mobility 381 of the multicast source in this scenario will require some multicast 382 routing protocols to rebuild distribution trees. This can cause 383 significant service disruptions or delays (see [RFC5757] for further 384 details). 386 5. IANA Considerations 388 This document makes no request of IANA. 390 Note to RFC Editor: this section may be removed on publication as an 391 RFC. 393 6. Security Considerations 395 This draft does not introduce additional messages or novel protocol 396 operations. Consequently, no new threats are introduced by this 397 document in addition to those identified as security concerns of 398 [RFC3810], [RFC4605], [RFC5213], and [RFC5844]. 400 However, particular attention should be paid to implications of 401 combining multicast and mobility management at network entities. As 402 this specification allows mobile nodes to initiate the creation of 403 multicast forwarding states at MAGs and LMAs while changing 404 attachments, threats of resource exhaustion at PMIP routers and 405 access networks arrive from rapid state changes, as well as from high 406 volume data streams routed into access networks of limited 407 capacities. In addition to proper authorization checks of MNs, rate 408 controls at replicators MAY be required to protect the agents and the 409 downstream networks. In particular, MLD proxy implementations at 410 MAGs SHOULD carefully procure for automatic multicast state 411 extinction on the departure of MNs, as mobile multicast listeners in 412 the PMIPv6 domain will not actively terminate group membership prior 413 to departure. 415 7. Acknowledgements 417 The authors would like to thank (in alphabetical order) Jouni 418 Korhonen and Stig Venaas for advice, help and reviews of the 419 document. Funding by the German Federal Ministry of Education and 420 Research within the G-LAB Initiative is gratefully acknowledged. 422 8. References 424 8.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 430 Listener Discovery (MLD) for IPv6", RFC 2710, 431 October 1999. 433 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 434 Thyagarajan, "Internet Group Management Protocol, Version 435 3", RFC 3376, October 2002. 437 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 438 in IPv6", RFC 3775, June 2004. 440 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 441 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 443 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 444 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 445 Protocol Specification (Revised)", RFC 4601, August 2006. 447 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 448 "Internet Group Management Protocol (IGMP) / Multicast 449 Listener Discovery (MLD)-Based Multicast Forwarding 450 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 452 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 453 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 455 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 456 Mobile IPv6", RFC 5844, May 2010. 458 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 459 Deployment for Multicast Listener Support in Proxy Mobile 460 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 462 8.2. Informative References 464 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 465 2", RFC 2236, November 1997. 467 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 468 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 469 and Brief Survey", RFC 5757, February 2010. 471 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 472 "Generic Routing Encapsulation (GRE) Key Option for Proxy 473 Mobile IPv6", RFC 5845, June 2010. 475 Appendix A. Evaluation of Traffic Flows 477 TODO 479 Appendix B. Change Log 481 The following changes have been made from version 482 draft-schmidt-multimob-pmipv6-base-source-00: 484 1. Added specifics of PIM directly connected neighbor requirements 485 for sources 487 2. Updated references 489 3. Editorial improvements 491 Authors' Addresses 493 Thomas C. Schmidt 494 HAW Hamburg 495 Berliner Tor 7 496 Hamburg 20099 497 Germany 499 Email: schmidt@informatik.haw-hamburg.de 500 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 502 Matthias Waehlisch 503 link-lab & FU Berlin 504 Hoenower Str. 35 505 Berlin 10318 506 Germany 508 Email: mw@link-lab.net 510 Muhamma Omer Farooq 511 HAW Hamburg 512 Berliner Tor 7 513 Hamburg 20099 514 Germany 516 Email: omer.farooq@ymail.com