idnits 2.17.1 draft-schmidt-multimob-pmipv6-mcast-deployment-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 16, 2009) is 5305 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-17 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-09) exists of draft-irtf-mobopts-mmcastv6-ps-08 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: BCP M. Waehlisch 5 Expires: April 19, 2010 link-lab & FU Berlin 6 B. Sarikaya 7 Huawei USA 8 S. Krishnan 9 Ericsson 10 October 16, 2009 12 A Minimal Deployment Option for Multicast Listeners in PMIPv6 Domains 13 draft-schmidt-multimob-pmipv6-mcast-deployment-02 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and 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 April 19, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes deployment options for activating multicast 52 listener functions in Proxy Mobile IPv6 domains without modifying 53 mobility and multicast protocol standards. Similar to Home Agents in 54 Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast 55 subscription anchor points, while Mobile Access Gateways provide MLD 56 proxy functions. In this scenario, Mobile Nodes remain agnostic of 57 multicast mobility operations. 59 Requirements Language 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC 2119 [RFC2119]. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 7 72 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 7 73 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 8 74 4.4. A Note on Explicit Tracking . . . . . . . . . . . . . . . 9 75 5. Message Source and Destination Address . . . . . . . . . . . . 9 76 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 [RFC3775] by 89 network-based management functions that enable IP mobility for a host 90 without requiring its participation in any mobility-related 91 signaling. Additional network entities, i.e., the Local Mobility 92 Anchor (LMA), and Mobile Access Gateways (MAGs), are responsible for 93 managing IP mobility on behalf of the mobile node (MN). 95 With these routing entities in place, the mobile node looses 96 transparent end-to-end connectivity to the static Internet, and in 97 the particular case of multicast communication, group membership 98 management as signaled by the Multicast Listener Discovery protocol 99 [RFC3810], [RFC2710] requires a dedicated treatment, see 100 [I-D.deng-multimob-pmip6-requirement]. 102 Multicast routing functions need a careful placement within the 103 PMIPv6 domain to augment unicast transmission with group 104 communication services. [RFC5213] does not explicitly address 105 multicast communication, whereas bi-directional home tunneling, the 106 minimal multicast support arranged by MIPv6, cannot be applied in 107 network-based management scenarios: A mobility-unaware node will 108 experience no reason to initiate a tunnel with an entity of mobility 109 support. 111 This document describes deployment options for activating multicast 112 listener functions in Proxy Mobile IPv6 domains without modifying 113 mobility and multicast protocol standards. Similar to Home Agents in 114 Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast 115 subscription anchor points, while Mobile Access Gateways provide MLD 116 proxy functions. Mobile Nodes in this scenario remain agnostic of 117 multicast mobility operations. Accrediting the problem space of 118 multicast mobility [I-D.irtf-mobopts-mmcastv6-ps], this document does 119 not address optimization potentials and efficiency improvements of 120 multicast routing in network-centered mobility, as such solutions 121 would require changes to the base specification of [RFC5213]. 123 2. Terminology 125 This document uses the terminology as defined for the mobility 126 protocols [RFC3775] and [RFC5213], as well as the multicast edge 127 related protocols [RFC3810] and [RFC4605]. 129 The reference scenario for multicast deployment in Proxy Mobile IPv6 130 domains is illustrated in Figure 1. 132 +-------------+ 133 | Content | 134 | Source | 135 +-------------+ 136 | 137 *** *** *** *** 138 * ** ** ** * 139 * * 140 * Fixed Internet * 141 * * 142 * ** ** ** * 143 *** *** *** *** 144 / \ 145 +----+ +----+ 146 |LMA1| |LMA2| Multicast Anchor 147 +----+ +----+ 148 LMAA1 | | LMAA2 149 | | 150 \\ //\\ 151 \\ // \\ 152 \\ // \\ Unicast Tunnel 153 \\ // \\ 154 \\ // \\ 155 \\ // \\ 156 Proxy-CoA1 || || Proxy-CoA2 157 +----+ +----+ 158 |MAG1| |MAG2| MLD Proxy 159 +----+ +----+ 160 | | | 161 MN-HNP1 | | MN-HNP2 | MN-HNP3 162 MN1 MN2 MN3 164 Figure 1: Reference Network for Multicast Deployment in PMIPv6 166 3. Overview 168 An MN in a PMIPv6 domain will decide on multicast group membership 169 management completely independent of its current mobility conditions. 170 It will submit MLD Report and Done messages following application 171 desires, thereby using its link-local source address and multicast 172 destinations according to [RFC3810], or [RFC2710]. These link-local 173 signaling messages will arrive at the currently active MAG via one of 174 its downstream local (wireless) links. A multicast unaware MAG would 175 simply discard these MLD messages. 177 To facilitate multicast in a PMIPv6 domain, an MLD proxy function 178 [RFC4605] needs to be deployed on the MAG that selects the tunnel 179 interface corresponding to the MN's LMA for its upstream interface 180 (cf., section 6 of [RFC5213]). Thereby, each LMA upstream interface 181 defines an MLD proxy domain at the MAG, containing all downstream 182 links to MNs that share this LMA. According to standard proxy 183 operations, MLD signaling of the MN will be consequently forwarded 184 under aggregation up the tunnel interface to its corresponding LMA. 186 Serving as the designated multicast router or an additional MLD 187 proxy, the LMA will transpose any MLD message from a MAG into the 188 multicast routing infrastructure. Correspondingly, the LMA will 189 implement appropriate multicast forwarding states at its tunnel 190 interface. Traffic arriving for groups under subscription will 191 arrive at the LMA, which it will forward according to all its group/ 192 source states. In addition, the LMA will naturally act as an MLD 193 querier, seeing its downstream tunnel interfaces as multicast enabled 194 links. 196 At the MAG, MLD queries and multicast data will arrive on the 197 (tunnel) interface that is assigned to a group of access links as 198 identified by its Binding Update List (cf., section 6 of [RFC5213]). 199 As specified for MLD proxies, the MAG will forward multicast traffic 200 and initiate related signaling down the appropriate access links to 201 the MNs. In proceeding this way, all multicast-related signaling and 202 the data traffic will transparently flow from the LMA to the MN on an 203 LMA-specific tree, which is shared among the multicast sources. 205 In case of a mobility handover, the MN (unaware of IP mobility) will 206 refrain from submitting unsolicited MLD reports. Instead, the MAG is 207 required to maintain group memberships in the following way. On 208 observing a new MN on a downstream link, the MAG sends a General MLD 209 Query. Based on its outcome and the multicast group states 210 previously maintained at the MAG, a corresponding Report will be sent 211 to the LMA aggregating group states according to the proxy function. 212 Additional Reports can be omitted, whenever multicast forwarding 213 states previously established at the new MAG already cover the 214 subscriptions of the MN. 216 After Re-Binding, the LMA is not required to issue a General MLD 217 Query on the tunnel link to refresh forwarding states. Multicast 218 state updates SHOULD be triggered by the MAG, which aggregates 219 subscriptions of all its MNs (see the call flow in Figure 2). 221 MN1 MAG1 MN2 MAG2 LMA 222 | | | | | 223 | Join(G) | | | | 224 +--------------->| | | | 225 | | Join(G) | | | 226 | |<---------------+ | | 227 | | | | | 228 | | Aggregated Join(G) | | 229 | +================================================>| 230 | | | | | 231 | | Mcast Data | | | 232 | |<================================================+ 233 | | | | | 234 | Mcast Data | Mcast Data | | | 235 |<---------------+--------------->| | | 236 | | | | | 237 | | < Movement to MAG2 & PMIP Binding Update > | 238 | | | | | 239 | | |--- Rtr Sol -->| | 240 | | | | | 241 | | | MLD Query | | 242 | | |<--------------+ | 243 | | | | | 244 | | | Join(G) | | 245 | | +-------------->| | 246 | | | Aggregated Join(G) 247 | | | +===============>| 248 | | | | | 249 | | Mcast Data | | | 250 | |<================================================+ 251 | | | | Mcast Data | 252 | | | |<===============+ 253 | Mcast Data | | | | 254 |<---------------+ | Mcast Data | | 255 | | |<--------------+ | 256 | | | | | 258 Figure 2: Call Flow of Multicast-enabled PMIP 260 These multicast deployment considerations likewise apply for mobile 261 nodes that operate with its IPv4 stack enabled in a PMIPv6 domain. 262 PMIPv6 can provide an IPv4 home address mobility support 263 [I-D.ietf-netlmm-pmip6-ipv4-support]. Such mobile node will use 264 IGMPv3 [RFC3376] signaling for multicast, which is handled by an IGMP 265 proxy function at the MAG in an analogous way. 267 Following these deployment steps, multicast management transparently 268 interoperates with PMIPv6. It is worth noting that multicast streams 269 can possibly be distributed on redundant path, leading to duplicate 270 traffic arriving from different LMAs at one MAG, and causing multiple 271 data transmissions from a MAG over one wireless domain to different 272 MNs. 274 4. Deployment Details 276 Multicast activation in a PMIPv6 domain requires to deploy general 277 multicast functions at PMIPv6 routers and to define its interaction 278 with the PMIPv6 protocol in the following way: 280 4.1. Operations of the Mobile Node 282 A Mobile Node willing to manage multicast traffic will join, maintain 283 and leave groups as if located in the fixed Internet. No specific 284 mobility actions nor implementations are required at the MN. 286 4.2. Operations of the Mobile Access Gateway 288 A Mobility Access Gateway is required to assist in MLD signaling and 289 data forwarding between the MNs which it serves, and the 290 corresponding LMAs associated to each MN. It therefore needs to 291 implement an instance of the MLD proxy function [RFC4605] for each 292 upstream tunnel interface that has been established with an LMA. The 293 MAG decides on the mapping of downstream links to a proxy instance 294 (and hence an upstream link to an LMA) based on the regular Binding 295 Update List as maintained by PMIPv6 standard operations (cf., section 296 6.1 of [RFC5213]). 298 On the reception of MLD reports from an MN, the MAG MUST identify the 299 corresponding proxy instance from the incoming interface and perform 300 regular MLD proxy operations: it will insert/update/remove a 301 multicast forwarding state on the incoming interface, and state 302 updates will be merged into the MLD proxy membership database. An 303 aggregated Report will be sent to the upstream tunnel of the MAG when 304 the membership database (cf., section 4.1 of [RFC4605]) changes. 305 Conversely, on the reception of MLD Queries, the MAG proxy instance 306 will answer the Queries on behalf of all active downstream receivers 307 maintained in its membership database. Queries sent by the LMA do 308 not force the MAG to trigger corresponding messages immediately 309 towards MNs. Multicast traffic arriving at the MAG on an upstream 310 interface will be forwarded according to the group/source-specific 311 forwarding states as acquired for each downstream interface within 312 the MLD proxy instance. 314 In case of a mobility handover, the MAG will continue to manage 315 upstream tunnels and downstream interfaces as foreseen in the PMIPv6 316 specification. However, it MUST assure consistency of its up- and 317 downstream interfaces that change under mobility with MLD proxy 318 instances and its multicast forwarding states. The MAG will observe 319 the arrival of a new MN by receiving a router solicitation message or 320 by an upcoming link. To learn about multicast groups subscribed by a 321 newly attaching MN, the MAG sends a General Query to the MN's link. 322 In case, the access link between MN and MAG goes down, interface- 323 specific multicast states change. Both cases may alter the 324 composition of the membership database, which then will trigger 325 corresponding Reports towards the LMA. Note that the actual 326 observable state depends on the access link model in use. 328 A MN may be unable to answer MAG multicast membership queries due to 329 handover procedures. Such occurrence is equivalent to a General 330 Query loss. To prevent erroneous query timeouts at the MAG, MLD 331 parameters SHOULD be carefully adjusted to the mobility regime. In 332 particular, MLD timers and the Robustness Variable (see section 9 of 333 [RFC3810]) MUST be chosen to be compliant with the time scale of 334 handover operations in the PMIPv6 domain. 336 In proceeding this way, the MAG is entitled to aggregate multicast 337 subscriptions for each of its MLD proxy instances. However, this 338 deployment approach does not prevent multiple identical streams 339 arriving from different LMA upstream interfaces. Furthermore, a per 340 group forwarding into the wireless domain is restricted to the link 341 model in use. 343 4.3. Operations of the Local Mobility Anchor 345 For any MN, the Local Mobility Anchor acts as the persistent Home 346 Agent and at the same time as the default multicast querier for the 347 corresponding MAG. It implements the function of the designated 348 multicast router or a further MLD proxy. According to MLD reports 349 received from a MAG (on behalf of the MNs), it establishes/maintains/ 350 removes group/source-specific multicast forwarding states at its 351 corresponding downstream tunnel interfaces. At the same time, it 352 procures for aggregated multicast membership maintenance at its 353 upstream interface. Based on the multicast-transparent operations of 354 the MAGs, the LMA experiences its tunnel interfaces as multicast 355 enabled downstream links, serving zero to many listening nodes. 356 Multicast traffic arriving at the LMA is transparently forwarded 357 according to its multicast forwarding information base. 359 On the occurrence of a mobility handover, the LMA will receive 360 Binding Lifetime De-Registrations and Binding Lifetime Extensions 361 that will cause a re-mapping of home network prefixes to Proxy-CoAs 362 in its Binding Cache (see section 5.3 of [RFC5213]). The multicast 363 forwarding states require updating, as well, if the MN within a MLD 364 proxy domain is the only receiver of a multicast group. Two cases 365 need distinction: 367 1. The mobile node is the only receiver of a group behind the 368 interface at which a De-Registration was received: The membership 369 database of the MAG changes, which will trigger a Report/Done 370 sent via the MAG-to-LMA interface to remove this group. The LMA 371 thus terminates multicast forwarding. 373 2. The mobile node is the only receiver of a group behind the 374 interface at which a Lifetime Extension was received: The 375 membership database of the MAG changes, which will trigger a 376 Report sent via the MAG-to-LMA interface to add this group. The 377 LMA thus starts multicast distribution. 379 In proceeding this way, each LMA will provide transparent multicast 380 support for the group of MNs it serves. It will perform traffic 381 aggregation at the MN-group level and will assure that multicast data 382 streams are uniquely forwarded per individual LMA-to-MAG tunnel. 384 4.4. A Note on Explicit Tracking 386 IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with 387 explicit tracking, which allows routers to monitor each multicast 388 receiver. This mechanism is not standardized yet, but widely 389 implemented by vendors as it supports faster leave latencies and 390 reduced signaling. 392 Enabling explicit tracking on downstream interfaces of the LMA and 393 MAG would track a single MAG and MN respectively per interface. It 394 may be used to preserve bandwidth on the MAG-MN link. 396 5. Message Source and Destination Address 398 This section describes source and destination addresses of MLD 399 messages. The interface identifier A-B denotes an interface on node 400 A, which is connected to node B. This includes tunnel interfaces. 402 5.1. Query 403 +===========+================+======================+==========+ 404 | Interface | Source Address | Destination Address | Header | 405 +===========+================+======================+==========+ 406 | | LMAA | Proxy-CoA | outer | 407 + LMA-MAG +----------------+----------------------+----------+ 408 | | LMA-link-local | [RFC2710], [RFC3810] | inner | 409 +-----------+----------------+----------------------+----------+ 410 | MAG-MN | MAG-link-local | [RFC2710], [RFC3810] | -- | 411 +-----------+----------------+----------------------+----------+ 413 5.2. Report/Done 414 +===========+================+======================+==========+ 415 | Interface | Source Address | Destination Address | Header | 416 +===========+================+======================+==========+ 417 | MN-MAG | MN-link-local | [RFC2710], [RFC3810] | -- | 418 +-----------+----------------+----------------------+----------+ 419 | | Proxy-CoA | LMAA | outer | 420 + MAG-LMA +----------------+----------------------+----------+ 421 | | MAG-link-local | [RFC2710], [RFC3810] | inner | 422 +-----------+----------------+----------------------+----------+ 424 6. IANA Considerations 426 This document makes no request of IANA. 428 Note to RFC Editor: this section may be removed on publication as an 429 RFC. 431 7. Security Considerations 433 This draft does neither introduce additional messages nor novel 434 protocol operations. Consequently, no new threats arrive from 435 procedures described in this document in excess to [RFC3810] and 436 [RFC5213] security concerns. 438 8. Acknowledgements 440 This memo is the outcome of extensive previous discussions and a 441 follow-up of several initial drafts on the subject. The authors 442 would like to thank Gorry Fairhurst, Stig Venaas, Jouni Korhonen and 443 Liu Hui for advice and reviews of the document. 445 9. References 446 9.1. Normative References 448 [I-D.ietf-netlmm-pmip6-ipv4-support] 449 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 450 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 451 (work in progress), September 2009. 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 457 Listener Discovery (MLD) for IPv6", RFC 2710, 458 October 1999. 460 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 461 Thyagarajan, "Internet Group Management Protocol, Version 462 3", RFC 3376, October 2002. 464 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 465 in IPv6", RFC 3775, June 2004. 467 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 468 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 470 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 471 "Internet Group Management Protocol (IGMP) / Multicast 472 Listener Discovery (MLD)-Based Multicast Forwarding 473 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 475 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 476 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 478 9.2. Informative References 480 [I-D.deng-multimob-pmip6-requirement] 481 Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, 482 "Multicast Support Requirements for Proxy Mobile IPv6", 483 draft-deng-multimob-pmip6-requirement-02 (work in 484 progress), July 2009. 486 [I-D.irtf-mobopts-mmcastv6-ps] 487 Fairhurst, G., "Multicast Mobility in MIPv6: Problem 488 Statement and Brief Survey", 489 draft-irtf-mobopts-mmcastv6-ps-08 (work in progress), 490 August 2009. 492 Authors' Addresses 494 Thomas C. Schmidt 495 HAW Hamburg 496 Berliner Tor 7 497 Hamburg 20099 498 Germany 500 Email: schmidt@informatik.haw-hamburg.de 501 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 503 Matthias Waehlisch 504 link-lab & FU Berlin 505 Hoenower Str. 35 506 Berlin 10318 507 Germany 509 Email: mw@link-lab.net 511 Behcet Sarikaya 512 Huawei USA 513 1700 Alma Dr. Suite 500 514 Plano, TX 75075 515 USA 517 Email: sarikaya@ieee.org 519 Suresh Krishnan 520 Ericsson 521 8400 Decarie Blvd. 522 Town of Mount Royal, QC 523 Canada 525 Email: suresh.krishnan@ericsson.com