idnits 2.17.1 draft-contreras-multimob-multiple-upstreams-00.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 15, 2012) is 4204 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-multimob-pmipv6-ropt-01 == Outdated reference: A later version (-03) exists of draft-ietf-multimob-fast-handover-01 == Outdated reference: A later version (-07) exists of draft-schmidt-multimob-fmipv6-pfmipv6-multicast-06 == Outdated reference: A later version (-09) exists of draft-ietf-multimob-pmipv6-source-01 Summary: 0 errors (**), 0 flaws (~~), 5 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 Telefonica I+D 4 Intended Status: Proposed Standard Carlos J. Bernardos 5 Expires: April 18, 2013 Universidad Carlos III de Madrid 6 October 15, 2012 8 Extension of the MLD proxy functionality to support multiple 9 upstream interfaces 10 draft-contreras-multimob-multiple-upstreams-00 12 Abstract 14 This document presents different scenarios of applicability for an 15 MLD proxy running more than one upstream interface. Since those 16 scenarios impose different requirements on the MLD proxy with 17 multiple upstream interfaces, it is important to ensure that the 18 proxy functionality address all of them for compatibility. 20 The purpose of this document is to define the requirements in an MLD 21 proxy with multiple interfaces covering a variety of applicability 22 scenarios, and to specify the proxy functionality to satisfy all of 23 them. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Scenarios of applicability . . . . . . . . . . . . . . . . . . 4 67 4.1 Applicability to multicast listener mobility . . . . . . . 4 68 4.1.1 Single MLD proxy instance on MAG . . . . . . . . . . . 4 69 4.1.1.1 Requirements . . . . . . . . . . . . . . . . . . . 5 70 4.1.2 Remote and local multicast subscription . . . . . . . . 5 71 4.1.2.1 Requirements . . . . . . . . . . . . . . . . . . . 6 72 4.1.3 Dual subscription to multicast groups during handover . 6 73 4.1.3.1 Requirements . . . . . . . . . . . . . . . . . . . 7 74 4.2 Applicability to multicast source mobility . . . . . . . . 7 75 4.2.1 Support of remote and direct subscription in basic 76 source mobility . . . . . . . . . . . . . . . . . . . . 7 77 4.2.1.1 Requirements . . . . . . . . . . . . . . . . . . . 8 78 4.2.2 Direct communication between source and listener 79 associated with distinct LMAs but on the same MAG . . . 8 80 4.2.3.1 Requirements . . . . . . . . . . . . . . . . . . . 9 81 4.2.3 Route optimization support in source mobility for 82 remote subscribers . . . . . . . . . . . . . . . . . . 9 83 4.2.3.1 Requirements . . . . . . . . . . . . . . . . . . . 9 84 4.3 Summary of the requirements needed . . . . . . . . . . . . 10 85 5 Functional specification of an MLD proxy with multiple 86 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 12 88 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 89 8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 91 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 93 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 96 1 Introduction 98 The aim of this document is to specify the functionality that an MLD 99 proxy with multiple upstream interfaces should have in order to 100 support a set of different scenarios of applicability that have been 101 identified on the MULTIMOB working group. Such functional 102 specification is required to ensure the compatibility of the MLD 103 proxy instances deployed in PMIPv6 domains. 105 To do that, a set of requirements are firstly identified to satisfy 106 the different scenarios where an MLD proxy instance with multiple 107 upstream interfaces can be potentially applied. 109 2. Terminology 111 . 113 3. Problem statement 115 The concept of MLD proxy with several upstream interfaces has emerged 116 within the MULTIMOB working group as a way of optimizing (and in some 117 cases enabling) service delivery scenarios in both multicast listener 118 and source mobility cases. 120 Since those scenarios can motivate distinct needs in terms of MLD 121 proxy functionality, it is necessary to consider a comprehensive 122 approach, looking at the possible scenarios, and establishing a 123 minimum set of requirements which can allow the operation of a 124 versatile MLD proxy with multiple upstream interfaces as a common 125 entity to all of them (i.e., no different kinds of proxies depending 126 on the scenario, but a common proxy applicable to all the potential 127 scenarios). 129 4. Scenarios of applicability 131 The use of an MLD proxy supporting multiple upstream interfaces can 132 improve the performance and the scalability of multicast-capable 133 PMIPv6 domains. 135 4.1 Applicability to multicast listener mobility 137 Three sub-cases can be identified for the multicast listener 138 mobility. 140 4.1.1 Single MLD proxy instance on MAG 141 The base solution for multicast service in PMIPv6 [2] assumes that 142 any MN subscribed to multicast services receive the multicast traffic 143 through the associated LMA, as in the unicast case. As standard MLD 144 proxy functionality only supports one upstream interface, the MAG 145 should implement several separated MLD proxy instances, one per LMA, 146 in order to serve the multicast traffic to the MNs, according to any 147 particular LMA-MN association. 149 A way of avoiding the multiplicity of MLD proxy instance in a MAG is 150 to deploy a unique MLD proxy instance with multiple upstream 151 interfaces, one per LMA, without any change in the multicast traffic 152 distribution. 154 4.1.1.1 Requirements 156 These are the requirements identified so far: 158 - The MLD proxy should be able of delivering the multicast control 159 messages sent by the MNs to the associated LMA. 161 - The MLD proxy should be able of delivering the multicast control 162 messages sent by each of the connected LMAs to the corresponding 163 MN. 165 - The MLD proxy should be able of routing the multicast data 166 coming from different LMAs to the corresponding MNs according to 167 the MN to LMA association. 169 - The MLD proxy should be able of maintaining a 1:1 association 170 between an MN and LMA (or downstream to upstream). 172 4.1.2 Remote and local multicast subscription 174 Standard MLD proxy definition, with a unique upstream interface per 175 proxy, does not allow the reception of multicast traffic from 176 distinct upstream multicast routers. In other words, all the 177 multicast traffic being sent to the MLD proxy in downstream traverses 178 a concrete, unique router before reaching the MAG. There are, 179 however, situations where different multicast content could reach the 180 MLD proxy through distinct next-hop routers. 182 For instance, the solution adopted to avoid the tunnel convergence 183 problem in basic multicast PMIPv6 deployments [3] considers the 184 possibility of subscription to a multicast source local to the PMIPv6 185 domain. In that situation, some multicast content will be accesses 186 remotely, through the home network via the multicast tree mobility 187 anchor, while some other multicast content will reach the proxy 188 directly, via a local router in the domain. 190 4.1.2.1 Requirements 192 These are the requirements identified so far: 194 - The MLD proxy should be able of delivering the multicast control 195 messages sent by the MNs to the associated upstream interface 196 based on the location of the source, remote or local, for a 197 certain multicast group. 199 - The MLD proxy should be able of delivering the multicast control 200 messages sent either local or remotely to the corresponding MNs. 202 - The MLD proxy should be able of routing the multicast data 203 coming from different upstream interfaces to a certain MN 204 according to the MN subscription, either local or remote. Note 205 that it is assumed that a multicast group can be subscribed either 206 locally or remotely, but not simultaneously. However more than one 207 subscription could happen, being local or remote independently. 209 - The MLD proxy should be able of maintaining a 1:N association 210 between an MN and the remote and local multicast router (or 211 downstream to upstream). 213 - The MLD proxy should be able of switching between local or 214 remote subscription for per multicast group according to specific 215 configuration parameters (out of the scope of this document). 217 4.1.3 Dual subscription to multicast groups during handover 219 In the event of an MN handover, once an MN moves from a previous MAG 220 (pMAG) to a new MAG (nMAG), the nMAG needs to set up the multicast 221 status for the incoming MN, and subscribe the multicast channels it 222 was receiving before the handover event. The MN will then experience 223 a certain delay until it receives again the subscribed content. 225 A generic solution is being defined in [4] to speed up the knowledge 226 of the ongoing subscription by the nMAG. However, for the particular 227 case that the underlying radio access technology supports layer-2 228 triggers (thus requiring extra capabilities on the mobile node), 229 there could be inter-MAG cooperation for handover support if pMAG and 230 nMAG are known in advance. 232 This could be the case, for instance for those contents not already 233 arriving to the nMAG, where the nMAG temporally subscribes the 234 multicast groups of the ongoing MN's subscription via the pMAG, while 235 the multicast delivery tree among the nMAG and the mobility anchor is 236 being established. 238 A similar approach is followed in [5] despite the solution proposed 239 there differs from this approach (i.e., there is no consideration of 240 an MLD proxy with multiple interfaces). 242 4.1.3.1 Requirements 244 These are the requirements identified so far: 246 - The MLD proxy should be able of delivering the multicast control 247 messages sent by the MNs to the associated upstream interface 248 based on the handover specific moment, for a certain multicast 249 group. 251 - The MLD proxy should be able of delivering the multicast control 252 messages sent either from pMAG or the multicast anchor to the 253 corresponding MNs, based on the handover specific moment. 255 - The MLD proxy should be able of handle the incoming packet flows 256 from the two simultaneous upstream interfaces, in order to not 257 duplicate traffic delivered on the point-to-point link to the MN. 259 - The MLD proxy should be able of maintaining a 1:N association 260 between an MN and both the remote multicast router and the pMAG 261 (or downstream to upstream). 263 - The MLD proxy should be able of switching between local or 264 remote subscription for all the multicast groups (from pMAG to 265 multicast anchor) according to specific configuration parameters 266 (out of the scope of this document). 268 4.2 Applicability to multicast source mobility 270 A couple of sub-cases can be identified for the multicast source 271 mobility. 273 4.2.1 Support of remote and direct subscription in basic source 274 mobility 276 In the basic case of source mobility, the multicast source is 277 connected to one of the downstream interfaces of an MLD proxy. 278 According to the standard specification [1] every packet sent by the 279 multicast source will be forwarded towards the root of the multicast 280 tree. 282 However, linked to the mobility listener problem, there could be the 283 case of simultaneous remote subscribers, subscribing to the multicast 284 content through the home network, and local subscribers, requesting 285 the contents directly via a multicast router residing on the same 286 PMIPv6 domain where the source is attached to. 288 Then, in order to provide the co-existence of both types of 289 subscribers, an MLD proxy with two upstream interfaces could 290 simultaneously serve all kind of multicast subscribers. 292 Basic source mobility is being defined in [6] but the solution 293 proposed there does not allow simultaneous co-existence of remote and 294 local subscribers (i.e., the content sent by the source is either 295 distributed locally to a multicast router in the PMIPv6 domain, or 296 remotely by using the bi-directional tunnel towards the mobility 297 anchor, but not both simultaneously). 299 4.2.1.1 Requirements 301 These are the requirements identified so far: 303 - The MLD proxy should be able of forwarding (replicating) the 304 multicast content to both upstream interfaces, in case of 305 simultaneous remote and local distribution. 307 - The MLD proxy should be able of handling control information 308 incoming through any of the two upstream interfaces, providing the 309 expected behavior for each of the multicast trees. 311 - The MLD proxy should be able of routing the multicast data 312 towards different upstream interfaces for both remote and local 313 subscriptions that could happen simultaneously. 315 - The MLD proxy should be able of maintaining a 1:N association 316 between an MN and both the remote and local multicast router (or 317 downstream to upstream). 319 4.2.2 Direct communication between source and listener associated with 320 distinct LMAs but on the same MAG 322 In a certain PMIPv6 domain can be MNs associated to distinct LMAs 323 using the same MAG to get access to their corresponding home 324 networks. For multicast communication, according to the base solution 325 [2], each MN <-> LMA association implies a distinct MLD proxy 326 instance to be invoked in the MAG. 328 In these conditions, when a mobile source is serving multicast 329 content to a mobile listener, both attached to the same MAG but each 330 of them associated to different LMAs, the multicast flow must 331 traverse the PMIPv6 domain from the MAG to the LMA where the source 332 maintains an association, then from that LMA to the LMA where the 333 listener is associated to, and finally come back to the same MAG from 334 where the flow departed. This routing is extremely inefficient. 336 An MLD proxy with multiple upstream interfaces avoids this behavior 337 since it allows to invoke a unique MLD proxy instance in the MAG. In 338 this case, the multicast source can directly communicate with the 339 multicast listener, without need for delivering the multicast traffic 340 to the LMAs. 342 4.2.3.1 Requirements 344 These are the requirements identified so far: 346 - The MLD proxy should be able of forwarding (replicating) the 347 multicast content to different upstream or downstream interfaces 348 where subscribers are present. 350 - The MLD proxy should be able of handling control information 351 incoming through any of the upstream or downstream interfaces 352 requesting a multicast flow being injected in another downstream 353 interface. 355 - The MLD proxy should be able of maintaining a 1:N association 356 between an MN and any of the upstream or downstream interfaces 357 demanding the multicast content. 359 4.2.3 Route optimization support in source mobility for remote 360 subscribers 362 Even in a scenario of remote subscription, there could be the case 363 where both the source and the listener are attached to the same 364 PMIPv6-Domain (for instance, no possibility of direct routing within 365 the PMIPv6, or source and listener pertaining to distinct home 366 networks). In this situation there is a possibility of route 367 optimization if inter-MAG communication is enabled, in such a way 368 that the listeners in the PMIPv6 domain are served through the 369 tunnels between MAGs, while the rest of remote listeners are served 370 through the mobility anchor. 372 A multi-upstream MLD proxy would allow the simultaneous delivery of 373 traffic to such kind of remote listeners. 375 A similar route optimization approach is proposed in [7]. 377 4.2.3.1 Requirements 378 These are the requirements identified so far: 380 - The MLD proxy should be able of forwarding (replicating) the 381 multicast content to both kinds of upstream interfaces, inter-MAG 382 tunnel interfaces and MAG to mobility anchor tunnel interface. 384 - The MLD proxy should be able of handling control information 385 incoming through any of the two types of upstream interfaces, 386 providing the expected behavior for each of the multicast trees 387 (e.g., no forwarding traffic on one inter-MAG link once there are 388 not more listeners requesting the content). 390 - The MLD proxy should be able of routing the multicast data 391 towards different upstream interfaces for both remote and route 392 optimized subscriptions that could happen simultaneously. 394 - The MLD proxy should be able of maintaining a 1:N association 395 between an MN and both the remote and local MAGs (or downstream to 396 upstream). 398 4.3 Summary of the requirements needed 400 After the previous analysis, a number of different requirements can 401 be identified by the MLD proxy to support multiple upstream 402 interfaces. The following table summarizes these requirements. 404 +----------------------------------------------------+ 405 | Scenarios | 406 +--------------------------+-------------------------+ 407 | Mulicast Listener | Mulicast Source | 408 +---------+--------+--------+--------+--------+--------+-------+ 409 | | Single| Remote | Dual | Direct |Listener| Route | 410 |Functio- | MLD |& local | subscr.|& remote|& source|optimi.| 411 |nality | Proxy | subscr.| in HO | subscr.| on MAG | | 412 | | (4.1.1)|(4.1.2) | (4.1.3)|(4.2.1) |(4.2.2) |(4.2.3)| 413 +---------+--------+--------+--------+--------+--------+-------+ 414 |Upstream | | | | | | | 415 |Control | X | X | X | X | X | X | 416 |Delivery | | | | | | | 417 +---------+--------+--------+--------+--------+--------+-------+ 418 |Downstr. | | | | | | | 419 |Control | X | X | X | | X | | 420 |Delivery | | | | | | | 421 +---------+--------+--------+--------+--------+--------+-------+ 422 |Upstream | | | | | | | 423 |Data | | | | X | | X | 424 |Delivery | | | | | | | 425 +---------+--------+--------+--------+--------+--------+-------+ 426 |Downstr. | | | | | | | 427 |Data | X | X | X | | X | | 428 |Delivery | | | | | | | 429 +---------+--------+--------+--------+--------+--------+-------+ 430 |1:1 MN to| | | | | | | 431 |upstream | X | | | | | | 432 |assoc. | | | | | | | 433 +---------+--------+--------+--------+--------+--------+-------+ 434 |1:N MN to| | | | | | | 435 |upstream | | X | X | X | X | X | 436 |assoc. | | | | | | | 437 +---------+--------+--------+--------+--------+--------+-------+ 438 |Upstr i/f| | | | | | | 439 |selection| | X | | | | | 440 |per group| | | | | | | 441 +---------+--------+--------+--------+--------+--------+-------+ 442 |Upstr i/f| | | | | | | 443 |selection| | | X | | | | 444 |all group| | | | | | | 445 +---------+--------+--------+--------+--------+--------+-------+ 446 |Upstream | | | | | | | 447 |traffic | | | | X | | X | 448 |replicat.| | | | | | | 449 +---------+--------+--------+--------+--------+--------+-------+ 450 Table I. Functionality needed on MLD proxy with multiple 451 upstream interfaces per application scenario 453 5 Functional specification of an MLD proxy with multiple interfaces 455 . 457 6 Security Considerations 459 . 461 7 IANA Considerations 463 . 465 8 Conclusions 467 Through this document several scenarios of applicability of an MLD 468 proxy with multiple upstream interfaces have been presented. 470 . 472 9 Acknowledgements 474 The authors thank Stig Venaas for his valuable comments and 475 suggestions. 477 The research of Carlos J. Bernardos leading to these results has 478 received funding from the European Community's Seventh Framework 479 Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL 480 project), being also partially supported by the Ministry of Science 481 and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 482 13992-C02-01). 484 10 References 486 10.1 Normative References 488 [1] B. Fenner, H. He, B. Haberman, and H. Sandick,"Internet Group 489 Management Protocol (IGMP) / Multicast Listener Discovery (MLD)- 490 Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, 491 August 2006. 493 10.2 Informative References 495 [2] T.C. Schmidt, M. Waehlisch, and S. Krishnan, "A Minimal 496 Deployment Option for Multicast Listeners in PMIPv6 Domains", 497 RFC6224, April 2011. 499 [3] J.C. Zuniga, L.M. Contreras, C.J. Bernardos, S. Jeon, Y. Kim, 500 "Multicast Mobility Routing Optimizations for Proxy Mobile 501 IPv6", work in progress, draft-ietf-multimob-pmipv6-ropt-01, 502 September 2012. 504 [4] L.M. Contreras, C.J. Bernardos, I. Soto, "PMIPv6 multicast 505 handover optimization by the Subscription Information 506 Acquisition through the LMA (SIAL)", work in progress, draft- 507 ietf-multimob-fast-handover-01, July 2012. 509 [5] T.C. Schmidt, M. Waehlisch, R. Koodli, G. Fairhurst, "Multicast 510 Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", work 511 in progress, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-06, 512 May 2012 514 [6] T.C. Schmidt, S. Gao, H. Zhang, M. Waehlisch, "Mobile Multicast 515 Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", work in 516 progress, draft-ietf-multimob-pmipv6-source-01, July 2012. 518 [7] J. Liu, W. Luo, "Routes Optimization for Multicast Sender in 519 Proxy Mobile IPv6 Domain", work in progress, draft-liu-multimob- 520 pmipv6-multicast-ro-02, July 2012. 522 Authors' Addresses 524 Luis M. Contreras 525 Telefonica I+D 526 EMail: lmcm@tid.es 528 Carlos J. Bernardos 529 Universidad Carlos III de Madrid 530 EMail: cjbc@it.uc3m.es