idnits 2.17.1 draft-contreras-multimob-msd-00.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2,3,, 4], [1]), 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 date (October 15, 2009) is 5300 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-schmidt-multimob-pmipv6-mcast-deployment-01 == Outdated reference: A later version (-02) exists of draft-sijeon-multimob-mms-pmip6-00 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 Working Group Luis M. Contreras 3 Internet Draft Carlos J. Bernardos 4 Intended status: Experimental Ignacio Soto 5 Expires: April 16, 2010 UC3M 6 October 15, 2009 8 Multicast service delivery in PMIPv6 domains 9 draft-contreras-multimob-msd-00.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 April 16, 2010. 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 A new working group, Multimob, has been chartered for providing an 48 implementation of multicast service distribution to multicast 49 listeners as they move in currently defined Proxy Mobile IPv6 50 (PMIPv6) domains according to RFC 5213 [1]. No protocol modifications 51 or extensions are considered at this stage. 53 Several proposals [2, 3, 4] have been already presented to face this 54 issue. This contribution sums up some of the previous ideas extending 55 them when necessary to overcome some limitations existing on such 56 solutions. 58 Table of Contents 60 1. Introduction.................................................2 61 2. Conventions and terminology..................................3 62 3. Overview.....................................................3 63 4. Unicast and multicast service delivery integration...........4 64 5. Local Mobility Anchor (LMA) operation........................5 65 6. Mobile Access Gateway (MAG) operation........................5 66 6.1. MAG operation as MLD proxy..............................5 67 6.2. MAG operation as multicast router.......................5 68 7. Multicast traffic hand-off process...........................6 69 7.1. Newly-attached MN interrogation.........................6 70 7.2. Multicast context transfer among MAGs...................7 71 7.3. pMAG-assisted handover..................................8 72 7.3.1. Multicast flow encapsulation......................11 73 7.3.2. Multicast flow delivery to the MN from the nMAG...12 74 8. Security Considerations.....................................12 75 9. IANA Considerations.........................................12 76 10. References.................................................12 77 10.1. Normative References..................................12 78 10.2. Informative References................................13 79 11. Acknowledgments............................................13 81 1. Introduction 83 A new working group, Multimob, has been chartered for providing an 84 implementation of multicast service distribution to multicast 85 listeners as they move in currently defined Proxy Mobile IPv6 86 (PMIPv6) domains according to RFC 5213 [1]. No protocol modifications 87 or extensions are considered at this stage. 89 This draft takes as starting point some existing contributions [3, 4, 90 5] to define a comprehensive architecture for multicast traffic 91 delivery in a PMIPv6 domain, introducing a new mechanism to allow 92 fast handover of the multicast flow, thus minimising multicast 93 service disruption when the multicast mobile listener moves across 94 the network. 96 2. Conventions and terminology 98 This document uses the terminology referring to PMIPv6 components as 99 defined in [1]. 101 3. Overview 103 In currently defined PMIPv6 solution [1] two main entities, named 104 Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG), are in 105 charge of managing both Mobile Node (MN) mobility and traffic 106 delivery from/to the MN. 108 The LMA plays a central role in the unicast traffic delivery from/to 109 the MN due that it is responsible of guaranteeing that the MN is 110 reachable through the PMIPv6 domain by means of announcing an 111 available route towards the MN, and forwarding traffic to it. By 112 contrast, it plays a passive role in the mobility process, just 113 pointing out to the MAG which acts as next-hop router to reach the 114 MN. 116 On the other hand, the MAG's main role is to manage the MN node 117 mobility within the PMIPv6 domain, notifying to the LMA the MN's 118 current location as it moves within the PMIPv6 domain. Respect to the 119 unicast traffic delivery, the MAG behaves as a passive element, just 120 forwarding the MN's terminating traffic on the point-to-point link 121 connecting both the MAG and the MN, or forwarding the traffic 122 originated in the MN to the LMA as default router. 124 The case for multicast traffic is slightly different to the unicast 125 one. The IP destination address of multicast packets does not 126 identify the receiver, so the LMA would need additional information 127 to be able to forward the multicast flow to the MNs requiring such 128 content. In order to manage multicast traffic terminated on an MN, 129 the LMA would need to keep the multicast status for every MN 130 subscribing to a content. Nevertheless, the MAG is the element placed 131 as first-hop router for the MNs, and thus, the MAG is the element 132 which directly receives the MLD signalling messages coming from the 133 MNs. It is the element better positioned in the network to maintain 134 the MN multicast status. 136 As consequence of that, in this draft the LMA is considered to manage 137 unicast traffic terminating on the MN, whereas the MAG is considered 138 to manage the multicast one, either if it plays the role of an MLD 139 proxy or a fully-enabled multicast router. 141 This draft takes as starting point some existing contributions [3, 4, 142 5] to define a comprehensive architecture for multicast traffic 143 delivery in a PMIPv6 domain, extending them in three ways: 145 1. An integrated vision of multicast service delivery together with 146 unicast standard process. 148 2. The extension of the MAG role to also consider it to be a fully 149 enabled multicast router. 151 3. A new proposal for minimising multicast service disruption on the 152 handover event between MAGs. 154 4. Unicast and multicast service delivery integration 156 This draft considers that every MN demanding multicast services is 157 previously registered in the PMIPv6 domain based on a unicast IP 158 address as stated in [1]. This registration can be required for 159 several purposes such as remote management, billing, etc. 161 As the registration is required by the network before any multicast 162 service is provided, any MLD message originated by the MN will be 163 discarded until the registration process is finished. This fact also 164 prevents the network from accepting any subscription request or leave 165 sent by the MN during the handover process. 167 In the same way, any subscription request or leave sent by the MN 168 after a detachment procedure is initiated, will be discarded by the 169 network, not being taken into account for multicast traffic 170 management purposes. 172 5. Local Mobility Anchor (LMA) operation 174 As stated above, the LMA will not play any specific role in the 175 multicast traffic management. 177 6. Mobile Access Gateway (MAG) operation 179 As stated above, the MAG will play a central role in the multicast 180 traffic management. The MAG will keep the multicast status of every 181 MN connected to it, and it will handle the multicast traffic 182 accordingly to the MLD messages received on each point-to-point link. 184 Depending on the functionality deployed on the MAG, it is possible to 185 consider the MAG as an MLD proxy or as a multicast router. 187 6.1. MAG operation as MLD proxy 189 When the MAG operates as MLD proxy it is in charge of summarizing the 190 MN's subscription requests and delivering them towards the multicast 191 router that can be reached through the configured proxy's upstream 192 interface. 194 Conceptually, this scenario corresponds to the one described in 195 Figure 1 of [5]. 197 In this draft, just one MLD proxy instance is considered to be 198 running in the MAG, and as consequence, just one interface can be 199 defined as upstream interface. 201 The multicast router connected to the MLD proxy upstream interface 202 could be any router in the network, even one of the routers acting as 203 LMA. In such case, the upstream interface could be defined over the 204 tunnel between the MAG and the LMA, once that tunnel has been set up. 206 6.2. MAG operation as multicast router 208 When a MAG operates as multicast router, it will send PIM messages to 209 build the multicast tree that distributes the content required by a 210 certain MN, if such content is not being received yet on the MAG. 212 Some content (the most popular one according to audience metrics or 213 estimations) could be permanently subscribed at MAG to minimize the 214 signalling involved in the establishment and pruning processes of the 215 multicast tree leafs reaching the MAG. 217 One of the routers participanting in the multicast distribution tree 218 can be one of the routers that acts as LMA in the PMIPv6 domain. In 219 that case, the multicast distribution tree could be extended over the 220 tunnel between MAG and LMA, once that tunnel has been set up. 222 7. Multicast traffic hand-off process 224 As the MN moves and connects to different access networks with the 225 same or different wireless access technology, the network should be 226 able to guarantee the delivery of the traffic following the MN 227 movement. 229 In the case of the multicast traffic, as seen above, the MAG entities 230 have the knowledge about the multicast status (group subscription) of 231 the MNs attached to them. MAG nodes contain enough information to 232 support the handover process minimising multicast service disruption. 234 We describe below some alternatives [4, 5] to facilitate multicast 235 service handover, including a new proposal. 237 7.1. Newly-attached MN interrogation 239 This method, proposed in [4], is based on the fact that MAG entities 240 running an MLD instance have the capability of interrogating mobile 241 hosts to obtain multicast memberships. In this case, an MN entering a 242 new access network under responsibility of a new MAG will be 243 interrogated by the new MAG, which sends an MLD Query towards the MN. 244 Once the MLD Query is received, the MN will provide information about 245 active memberships it has, if any. The MAG will get in this way 246 knowledge of the multicast status for this newly-attached MN. 248 A number of pros and cons can be identified for this method. 250 Pros: 252 o The MAG entity does not require any additional functionality as it 253 already implements MLD capabilities. 255 o The application of this method can be easily integrated within the 256 MN registration process. 258 Cons: 260 o Any new MN attaching the nMAG is interrogated, independently if it 261 maintains or not an active multicast session at that time. 263 o The signalling process wastes resources over the air interface. 265 7.2. Multicast context transfer among MAGs 267 This method, introduced in [5], proposes to trigger a context 268 transfer process of the MN multicast status from the previous MAG 269 (pMAG) to the new MAG (nMAG). As a previous step, the pMAG should 270 predict the path the MN follows as it moves, to correctly identify 271 the candidate nMAG to support the MN connection. 273 A number of pros and cons can be identified for this method. 275 Pros: 277 o There is no additional signalling process over the air interface. 279 o The context transfer method is an standardized process as per [2]. 281 Cons: 283 o The MAG entity requires new functionality to support multicast 284 traffic handovers. 286 o As predictive method, there is no total guarantee of success (the 287 multicast context could not reach nMAG in all cases). 289 o Coordination problems could arise in case of vertical handovers. 291 7.3. pMAG-assisted handover 293 This new proposal considers the fact that the MN keeps the same IP 294 address in the PMIPv6 domain, thus the MN will be always reachable 295 and traceable from the LMA as it moves from one wireless point of 296 attachment to another. 298 The pMAG maintains the multicast status of an MN reconnecting to a 299 nMAG. Before the detachment process, the multicast traffic reaching 300 the MN passes through the pMAG. So, once a pMAG receives a Proxy 301 Binding Ack (PBA) message from the LMA confirming that the MN has 302 been detached from its point-to-point link, the pMAG can be able to 303 temporally forward via the LMA a copy of the multicast content within 304 an unicast flow towards the new location of the MN, once it is 305 registered again in some point of the network. In case the MN is not 306 registered again, the copy will be silently discarded in the LMA 307 until timer expiration. 309 The timer duration has to be long enough to cover the registration 310 process and the content subscription at the nMAG (triggered by 311 periodic MLD reports from the MN). Once the timer expires, the pMAG 312 deletes the MN multicast status state and stops the unicast flow that 313 encapsulates the multicast content. 315 Figure 1 presents the interaction between pMAG, LMA and nMAG. 317 MN pMAG nMAG MR LMA 319 | | | | | 320 1) |<--------------- Multicast Data ---| | 321 | | | | | 322 MN detaches | | | | 323 | MN detachment event | | | 324 | | | | | 325 2) | |---- Proxy Binding Update -------->| 326 | | | | | 327 3) | |<--- Proxy Binding Acknowledge ----| 328 | | | | | 329 4) | |-- Mcast flow encapsulation ------>| 330 | | | | | 331 5) | | |-Proxy Binding Update->| 332 | | | | | 333 6) | | |<--Proxy Binding Ack.--| 334 | | | | | 335 7) | | |<- Mcast flow fwd -----| 336 | | | | | 337 8) |<--- Multicast Data ---| | 338 | | | | 339 | | |-MLDReport>| 340 | | | | 341 | | | |->(PIM join) 342 | | | | 343 | | | |->(S,G) 344 | | | | 345 9) |<--------------- Multicast Data ---| 346 | | | | 347 | | | | 349 Figure 1. pMAG-assisted handover 351 Each step of the process is described as follows: 353 1) A registered MN is receiving a multicast content which has been 354 previously subscribed by standard MLD request from the MN to the 355 currently serving MAG, pMAG. The pMAG keeps the multicast status 356 state of the MN. 358 2) The MN perceives a better radio link and decides to initiate a 359 handover process over a radio access controlled by a new MAG, 360 nMAG. As consequence, pMAG determines a detach event corresponding 361 to this MN, and updates the attachment status of this MN to the 362 LMA by sending a Proxy Binding Update message. From this moment, 363 pMAG would discard any new MLD Report message coming from the MN 364 requesting new content subscription. 366 3) The LMA confirms the reception of the detach process notification 367 by sending a Proxy Binding Acknowledge message to the pMAG. 369 4) After reception of the PBA message, the pMAG encapsulates the 370 multicast flow being served to the MN prior to the detachment 371 event, and temporally forwards it to the LMA. The reason for this 372 is that the MN keeps its IP address through the PMIPv6 domain, and 373 it will be always reachable through the LMA, as soon as the MN is 374 registered again by the nMAG. During the time that the MN is not 375 reachable by the LMA, the LMA will silently discard the 376 encapsulated multicast flow sent by the pMAG. 378 The encapsulation method is described later in this draft. 380 A timer is set up by pMAG to control the duration of multicast 381 flow forwarding via the LMA. The timer value must be at least the 382 maximum time to cover the MN registration process at the MAG and 383 the refreshment of the group membership by the MLD instance at the 384 MN. 386 5) The MN triggers an attachment process in a different MAG, nMAG. 387 This nMAG signals the LMA with the new mobility status of the MN. 389 6) The LMA confirms the new attachment, and configures the routing 390 table accordingly to forward incoming traffic to the MN through 391 the nMAG. At this time, any MLD messages coming from the MN are 392 accepted by the nMAG. 394 7) Once the MN is reachable again, the LMA forwards the encapsulated 395 multicast traffic originally subscribed by the MN to the nMAG. 397 8) The nMAG decapsulates the originally subscribed multicast flow and 398 sends it over the point-to-point link connecting both the nMAG and 399 the MN. With the information contained in the flow, the nMAG is 400 able to build the multicast status of the MN. Additionally, in 401 case the nMAG currently does not have a subscription to the 402 required content, it can trigger a content subscription on behalf 403 of the MN to set up the delivery tree to the nMAG. 405 If the MN sends MLD messages to leave originally subscribed 406 multicast content, the encapsulated multicast flow coming from the 407 pMAG wil be silently discarded until timer expiration. 409 9) The delivery tree reaches nMAG. The multicast content is directly 410 served by the multicast tree. The encapsulated multicast flow 411 coming from the pMAG will be silently discarded until timer 412 expiration. 414 A number of pros and cons can be identified for this method. 416 Pros: 418 o There is no additional signalling process over the air interface. 420 o The multicast traffic is sent towards the MN immediately after the 421 new registration. 423 Cons: 425 o The MAG entity require new functionality to support multicast 426 traffic handovers. 428 o The network temporally supports more traffic. 430 7.3.1. Multicast flow encapsulation 432 The originally subscribed multicast traffic has to be encapsulated 433 from the pMAG to the LMA to forward it to the MN as it moves. The 434 format of the tunnelled flow considered in this draft is the one 435 already described in Figure 1 of reference [3], but with different 436 addressing considerations. Briefly, the format proposed here is as 437 follows: 439 1. One external tunnel, with source address pMAG's Proxy-CoA, and 440 destination address LMA Address (LMAA). 442 2. One internal tunnel, with source address pMAG's Proxy-CoA, and 443 destination address MN-HoA. 445 3. The multicast flow being received by the MN, with source address 446 the IP address of the source injecting the multicast content to 447 the network, and destination address the multicast IP address of 448 the group subscribed by the MN. 450 Once these packets reach the LMA, if a routing entry already exists 451 pointing out to the MN through the nMAG, the external tunnel 452 addressing is modified accordingly: the source address is the LMAA, 453 whereas the destination address is the nMAG's Proxy-CoA. 455 7.3.2. Multicast flow delivery to the MN from the nMAG 457 Here the same behaviour described in section 5 of reference [3] is 458 proposed for the nMAG. 460 After receiving the forwarded original multicast flow from pMAG, the 461 nMAG will analyze the internal tunnel header. In case the source 462 address is a Proxy-CoA address of any neighbouring MAG in the domain, 463 and the destination address is the one of the MN, MN-HoA, the nMAG 464 will determine that a second tunnel exists. The nMAG will remove the 465 internal header and will deliver the original multicast content as is 466 (with multicast source and group addresses) to the MN on the point- 467 to-point link. 469 In this way, the MN is guaranteed to receive the original subscribed 470 multicast flow as before the handover process. 472 This mechanism implies that any MAG within a PMIPv6 domain has to be 473 aware of the Proxy-CoA addresses of the neighbouring MAGs in the 474 domain, to be able to determine the existence of the second 475 (internal) tunnel. The maximum number of IP addresses to take into 476 account would be then equal to the number of MAGs in the domain. 478 8. Security Considerations 480 None. 482 9. IANA Considerations 484 This document makes no request of IANA. 486 10. References 488 10.1. Normative References 490 [1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. 491 Patil, "Proxy Mobile IPv6", RFC 5213, Augurst 2008. 493 [2] J. Loughney, M. Nakhjiri, C. Perkins, and R. Koodli, "Context 494 Transfer Protocol (CXTP)", RFC 4067, July 2005. 496 10.2. Informative References 498 [3] S. Krishnan, B. Sarikaya and TC. Schmidt, "Proxy Mobile IPv6 499 Basic Multicast Support Solution", draft-krishnan-multimob- 500 pmip6basicmcast-solution-00, (work in progress), July 2009. 502 [4] TC. Schmidt, M. Waehlisch, B. Sarikaya, and S. Krishnan, "A 503 Minimal Deployment Option for Multicast Listeners in PMIPv6 504 Domains", draft-schmidt-multimob-pmipv6-mcast-deployment-01, 505 (work in progress), June 2009. 507 [5] S. Jeon, Y. Kim, and J. Lee, "Mobile Multicasting Support in 508 Proxy Mobile IPv6", draft-sijeon-multimob-mms-pmip6-00, (work 509 in progress), July 2009. 511 11. Acknowledgments 513 The research of Carlos J. Bernardos leading to these results has 514 received funding from the European Community's Seventh Framework 515 Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN 516 project), and from the Ministry of Science and Innovation of Spain, 517 under the QUARTET project (TIN2009-13992-C02-01). 519 Authors' Addresses 521 Luis M. Contreras 522 Universidad Carlos III de Madrid 523 Av. Universidad, 30 524 Leganes, Madrid 28911 525 Spain 527 Email: luisc@it.uc3m.es 528 Carlos J. Bernardos 529 Universidad Carlos III de Madrid 530 Av. Universidad, 30 531 Leganes, Madrid 28911 532 Spain 534 Email: cjbc@it.uc3m.es 536 Ignacio Soto 537 Universidad Carlos III de Madrid 538 Av. Universidad, 30 539 Leganes, Madrid 28911 540 Spain 542 Email: isoto@it.uc3m.es