idnits 2.17.00 (12 Aug 2021) /tmp/idnits64033/draft-ietf-pim-multiple-upstreams-reqs-08.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 (November 9, 2018) is 1282 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational CJ. Bernardos 5 Expires: May 13, 2019 Universidad Carlos III de Madrid 6 H. Asaeda 7 NICT 8 N. Leymann 9 Deutsche Telekom 10 November 9, 2018 12 Requirements for the extension of the IGMP/MLD proxy functionality to 13 support multiple upstream interfaces 14 draft-ietf-pim-multiple-upstreams-reqs-08 16 Abstract 18 The purpose of this document is to define the requirements for a MLD 19 (for IPv6) or IGMP (for IPv4) proxy with multiple interfaces covering 20 a variety of applicability scenarios. The referred scenarios, while 21 describing not sophisticated service situations, present cases that 22 existing technology does not allow to solve in a simplistic manner. 23 This document is then intended to serve as input for future documents 24 defining the support of multiple upstream interfaces by IGMP/MLD 25 proxies being compliant with the aforementioned requirements. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 13, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Scenarios of applicability . . . . . . . . . . . . . . . . . 5 65 4.1. Fixed network scenarios . . . . . . . . . . . . . . . . . 6 66 4.1.1. Multicast wholesale offer for residential services . 6 67 4.1.1.1. Requirements . . . . . . . . . . . . . . . . . . 6 68 4.1.2. Multicast resiliency . . . . . . . . . . . . . . . . 7 69 4.1.2.1. Requirements . . . . . . . . . . . . . . . . . . 7 70 4.1.3. Load balancing for multicast traffic in the metro 71 segment . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1.3.1. Requirements . . . . . . . . . . . . . . . . . . 8 73 4.1.4. Network merging with different multicast services . . 8 74 4.1.4.1. Requirements . . . . . . . . . . . . . . . . . . 8 75 4.1.5. Multicast service migration . . . . . . . . . . . . . 9 76 4.1.5.1. Requirements . . . . . . . . . . . . . . . . . . 9 77 4.2. Mobile network scenarios . . . . . . . . . . . . . . . . 10 78 5. Summary of requirements . . . . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 9.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The aim of this document is to define the functionality that an IGMP/ 90 MLD proxy with multiple upstream interfaces should have in order to 91 support different scenarios of applicability in both fixed and mobile 92 networks. IGMP/MLD proxis are a generic solution very much deployed 93 in existing carrier networks. An extension to them in the sense of 94 supporting multiple upstream interfaces can provide a more flexible 95 and lightweight solution than other potential alternatives that could 96 face more complexities (like multi-domain routing in the case of PIM, 97 or the need of some external elements -e.g., controllers- if the 98 coordination of actions required lays outside the proxy). 100 The functional behavior of an IGMP/MLD proxy with multiple upstream 101 interfaces here described is needed in order to simplify node 102 functionality and to ensure an easier deployment of multicast 103 capabilities in all the use cases described in this document. 105 For doing that, a number of scenarios are described, representing 106 current deployments and needs from operator's networks. From that 107 scenarios, certain requirements are identified as needed to simplify 108 operational situations, enable optimized service delivery, etc. 109 Those represent functional requirements to be satisfied by IGMP/MLD 110 proxies with multiple upstream interfaces. These functional 111 requirements reflect the need of coordinating actions from a single 112 element in the network (i.e., the IGMP/MLD proxy), optimizing the 113 delivery of the content within the network at any time. 115 Any Source Multicast (ASM) [RFC1112] and Source-Specific Multicast 116 (SSM) [RFC4607] represent different service models at the time of 117 subscribing to multicast groups by means of IGMPv3 [RFC3376], 118 [RFC5790] and MLDv2 [RFC3810]. When using ASM a receiver joins a 119 group indicating only the desired group address to be received. In 120 the case of SSM, a receiver indicates the specific source address as 121 well as a group address from where the multicast content is received. 122 Both service models are taken into account along this document, and 123 the specific requirements are derived from them. 125 2. Terminology 127 This document uses the terminology defined in [RFC4605]. 128 Specifically, the definition of Upstream and Downstream interfaces, 129 which are repeated here for completeness. 131 Upstream interface: A proxy device's interface in the direction of 132 the root of the tree. Also called the "Host interface". 134 Downstream interface: Each of a proxy device's interfaces that is 135 not in the direction of the root of the tree. Also called the 136 "Router interfaces". 138 3. Problem statement 140 The concept of IGMP/MLD proxy with several upstream interfaces has 141 emerged as a way of optimizing (and in some cases enabling) service 142 delivery scenarios where separate multicast service providers are 143 reachable through the same access network infrastructure. Figure 1 144 presents the conceptual model under consideration. 146 downstream upstream 147 interface interface A 148 | | 149 | | _______________ 150 | +-------+ v / \ 151 | | O-------( Multicast Set 1 ) 152 +----------+ v | IGMP/ | \_______________/ 153 | Listener |------| MLD | _______________ 154 +----------+ | Proxy | / \ 155 | O-------( Multicast Set 2 ) 156 +-------+ ^ \_______________/ 157 | 158 | 159 upstream 160 interface B 162 Figure 1: Concept of IGMP/MLD proxy with multiple upstream interfaces 164 This document is focused on both fixed and mobile network scenarios. 165 Applicability of IGMP/MLD proxies with multiple upstream interfaces 166 in mobile environments has been previously identified as beneficial 167 in scenarios as the ones described in [RFC6224] and [RFC7287]. 169 In the case of fixed networks, multicast wholesale services in a 170 competitive residential market require an efficient distribution of 171 multicast traffic from different operators or content providers, i.e. 172 the incumbent operator and a number of alternative providers, on the 173 network infrastructure of the former. Existing proposals are based 174 on the use of PIM routing from the metro/core network, and multicast 175 traffic aggregation on the same tree. A different approach could be 176 achieved with the use of an IGMP/MLD proxy with multiple upstream 177 interfaces, each of them pointing to a distinct multicast router in 178 the metro/core border which is part of separated multicast trees deep 179 in the network. Figure 2 graphically describes this scenario. 181 downstream upstream 182 interface interface A 183 | | 184 | | _______________ 185 | +--------+ v / \ 186 | | Aggr. O-------( Multicast Set 1 ) 187 | | Switch | \_______________/ 188 +----+ v | | (e.g. from the Incumbent 189 | AN |-------| (IGMP | Operator) 190 +----+ | /MLD | _______________ 191 (e.g. | Proxy) | / \ 192 DSLAM | O-------( Multicast Set 2 ) 193 /OLT) +--------+ ^ \_______________/ 194 | (e.g. from an Alternative 195 | Provider) 196 | 197 upstream 198 interface B 200 Figure 2: Example of usage of an IGMP/MLD proxy with multiple 201 upstream interfaces in a fixed network scenario 203 Since those scenarios can motivate distinct needs in terms of IGMP/ 204 MLD proxy functionality, it is necessary to consider a comprehensive 205 approach, looking at the possible scenarios, and establishing a 206 minimum set of requirements which can allow the operation of a 207 versatile IGMP/MLD proxy with multiple upstream interfaces as a 208 common entity to all of them (i.e., no different kinds of proxies 209 depending on the scenario, but a common proxy applicable to all the 210 potential scenarios). 212 4. Scenarios of applicability 214 Having multiple upstream interfaces creates a new decision space for 215 delivering the proper multicast content to the subscriber. Basically 216 it is now possible to implement channel-based (i.e., leveraging on 217 multicast group IP address) or subscriber-based (i.e., referenced to 218 the subscriber IP address) upstream selection, according to 219 mechanisms or policies that could be defined for the multicast 220 service provisioning. 222 This section describes in detail a number of scenarios of 223 applicability of an IGMP/MLD proxy with multiple upstream interfaces 224 in place. A number of requirements for the IGMP/MLD proxy 225 functionality are identified from those scenarios. 227 All the exemplary scenarios here described are based on the support 228 of two upstream interfaces. However, all of them are applicable also 229 to the support of more than two upstream interfaces. 231 4.1. Fixed network scenarios 233 Residential broadband users get access to multiple IP services 234 through fixed network infrastructures. End user's equipment is 235 connected to an access node, and the traffic of a number of access 236 nodes is collected in aggregation switches. 238 For the multicast service, the use of an IGMP/MLD proxy with multiple 239 upstream interfaces in those switches appears as a simple and 240 straightforward solution. 242 4.1.1. Multicast wholesale offer for residential services 244 This scenario has been already introduced in the previous section, 245 and can be seen in Figure 2. There are two different operators, the 246 one operating the fixed network where the end user is connected 247 (e.g., typically an incumbent operator), and the one providing the 248 Internet service to the end user (e.g., an alternative Internet 249 service provider). Both can offer multicast streams that can be 250 subscribed by the end user, independently of which provider 251 contributes with the content. 253 Note that it is assumed that both providers offer distinct multicast 254 groups. However, more than one subscription to multicast channels of 255 different providers could take place simultaneously. 257 4.1.1.1. Requirements 259 o The IGMP/MLD proxy should be able to deliver multicast control 260 messages sent by the end user to the corresponding provider's 261 multicast router. 263 o The IGMP/MLD proxy should be able to deliver multicast control 264 messages sent by each of the providers to the corresponding end 265 user. 267 o The IGMP/MLD proxy should be able to support ASM and SSM at the 268 time of requesting the content. Since the use case assumes that 269 each provider offers distinct multicast groups, the IGMP/MLD proxy 270 should be able to identify inconsistencies in the SSM requests, 271 that is, the case in which for an (S, G) request the source S does 272 not deliver a the group G. 274 4.1.2. Multicast resiliency 276 In current PIM-based solutions [RFC7063], the resiliency of the 277 multicast distribution relays on the routing capabilities provided by 278 protocols like PIM [RFC7761] and VRRP [RFC5798]. A simpler scheme 279 could be achieved by implementing different upstream interfaces on 280 IGMP/MLD proxies, providing path diversity through the connection to 281 distinct leaves of a given multicast tree. 283 It is assumed that only one of the upstream interfaces is active in 284 receiving the multicast content, while the other is up and in standby 285 mode for fast switching. The objective is to avoid video delivery 286 affection that could imply play out interruption or buffering on the 287 user side. Service parameters like the ones defined in [Y.1540] 288 (such as packet loss ratio) or in [RFC4445] (like the delay factor) 289 can be considered as parameters to be assesed from the service 290 perspective. For instance, [TECH.3361-1] could be considered as a 291 SLA framework to be satisfied in this case. 293 4.1.2.1. Requirements 295 o The IGMP/MLD proxy should be able to deliver multicast control 296 messages received in the active upstream to the end users, while 297 ignoring the control messages of the standby upstream interface. 299 o The IGMP/MLD proxy should be able of rapidly switching from the 300 active to the standby upstream interface in case of network 301 failure, transparently to the end user. 303 o The IGMP/MLD proxy should be able to deliver IGMP/MLD messages 304 sent by the end user (for both ASM and SSM modes) to the 305 corresponding active upstream interface. 307 4.1.3. Load balancing for multicast traffic in the metro segment 309 A single upstream interface in existing IGMP/MLD proxy functionality 310 [RFC4605] typically forces the distribution of all the channels on 311 the same path in the last segment of the network. The metro and 312 backhaul network is usually built using ring topologies. The devices 313 in the ring implement IGMP/MLD functionality to join the content. 314 Multiple upstream interfaces could naturally help to split the 315 content demand, alleviating the bandwidth requirements in the overall 316 metro segment by allowing some of the channels to follow the 317 protection path, where spare capacity is vacant under normal 318 conditions. This will allow, for instance, to absorb traffic peaks 319 when a high number of channels (more than the expected on average) is 320 requested. 322 4.1.3.1. Requirements 324 o The IGMP/MLD proxy should be able to deliver multicast control 325 messages sent by the end user to the corresponding multicast 326 router which provides the channel of interest. 328 o The IGMP/MLD proxy should be able to deliver multicast control 329 messages sent by each of the multicast routers to the 330 corresponding end user. 332 o The IGMP/MLD proxy should be able to decide which upstream 333 interface is selected for any new channel request according to 334 defined criteria (e.g., load balancing). 336 o In the case of ASM, the IGMP/MLD proxy should be able to balance 337 the traffic as a function of the group G requested. In the case 338 of SSM, the load balancing mechanism could also consider the 339 source S for the decision. In any case, the criteria will follow 340 the olicies defined by the network operator. Such policies can be 341 influenced by the user requesting the service, for instance 342 through the subscription to some channels being offered by a third 343 party (which has reached an agreement with the provider for 344 delivering that content in its network). 346 4.1.4. Network merging with different multicast services 348 In some network merging situations, the multicast services provided 349 before in each of the merged networks are maintained for the 350 respective customer base (usually in a temporal fashion until the 351 multicast service is redefined in a new single offer, but not 352 necessarily, or not in short term, e.g. because of commercial 353 agreements for each of the previous service offers). 355 In order to assist that network merging situations, IGMP/MLD proxies 356 with multiple upstream interfaces can help in the transition 357 simplifying the service provisioning and facilitating service 358 continuity. 360 4.1.4.1. Requirements 362 o The IGMP/MLD proxy should be able to deliver multicast control 363 messages sent by the end user to the corresponding multicast 364 router which provides the channel of interest, according to the 365 service subscription. 367 o The IGMP/MLD proxy should be able to deliver multicast control 368 messages sent by each of the multicast routers to the 369 corresponding end user, according to the service subscription. 371 o The IGMP/MLD proxy should be able to decide which upstream 372 interface is selected for any new channel request according to 373 defined criteria (e.g., service subscription). 375 o For this use case, the usage of SSM can simplify the decision of 376 the IGMP/MLD proxy. For ASM the decision should be assisted by 377 further information like the service to which the end user is 378 subscribed (e.g., taking into account what is the original network 379 from where the end user was part previous to the network merge 380 situation). 382 4.1.5. Multicast service migration 384 This scenario considers the situation where a multicast service needs 385 to be migrated from one upstream interface to another upstream 386 interface (e.g. because of changes inside the service provider's 387 network). The migration should be "smooth" and without any service 388 interruption. In this case the multicast content is initially 389 offered in both upstream interfaces and the proxy dynamically 390 switches from the first to the second upstream interface, according 391 to certain policies, and enabling to shut down the first upstream 392 interface once the migration is completed. 394 4.1.5.1. Requirements 396 o The IGMP/MLD proxy should be able to deliver multicast control 397 messages sent by the end user to the corresponding multicast 398 router before and after the service migration. 400 o The IGMP/MLD proxy should be able to deliver multicast control 401 messages sent by each of the multicast routers to the 402 corresponding end user, according to the situation of the user 403 with respect to the service migration. 405 o The IGMP/MLD proxy should be able to decide which upstream 406 interface corresponds to each user, according to the situation of 407 the user with respect to the service migration, i.e., the status 408 of the user with respect the platform migration as purely 409 operational situation while transitioning from one platform to 410 another in a smooth manner. 412 o The IGMP/MLD proxy should be able to decide which upstream 413 interface corresponds to each ASM or SSM request, according to the 414 situation of the group and source included in the request with 415 respect to the service migration. 417 4.2. Mobile network scenarios 419 Mobile networks offer different alternatives for multicast 420 distribution. 422 One of them is defined by 3GPP [TS23.246] for the Multimedia 423 Broadcast Multicast Service (MBMS). In this case, a MBMS gateway 424 (MBMS GW) is connected to multiple evolved Node B (eNodeB) -- which 425 are the base stations connecting the mobile handsets with the network 426 wirelessly [TS36.300] -- for data distribution by means of IP 427 multicast. The MBMS GW delivers the IP multicast groups. The eNodeB 428 joins the appropriate group multicast address allocated by the MBMS 429 GW to receive the content data. At this distribution level, an IGMP/ 430 MLD proxy could be part of the transport infrastructure providing 431 connectivity to several distributed eNodeBs. The potential scenarios 432 from this case do not essentially differentiate from the ones 433 described for the fixed network scenarios, so the same situations and 434 requirements apply. 436 Another alternative is given by Proxy Mobile IPv6 (PMIPv6) protocol 437 for IP mobility management [RFC5213]. PMIPv6 is one of the 438 mechanisms adopted by the 3GPP to support the mobility management of 439 non-3GPP terminals in future Evolved Packet System (EPS) networks. 440 PMIPv6 allows a Media Access Gateway (MAG) to establish a distinct 441 bi-directional tunnel with different Local Mobility Anchors (LMAs), 442 being each tunnel shared by the attached Mobile Nodes (MNs). Each 443 mobile node is associated with a corresponding LMA, which keeps track 444 of its current location, that is, the MAG where the mobile node is 445 attached. As the basic solution for the distribution of multicast 446 traffic within a PMIPv6 domain, [RFC6224] makes use of the bi- 447 directional LMA-MAG tunnels. The use of an MLD proxy supporting 448 multiple upstream interfaces can improve the performance and the 449 scalability of multicast-capable PMIPv6 domains, for both multicast 450 listener and multicast source mobility. Once again, the potential 451 scenarios in this case are contained into the ones described for the 452 fixed network scenarios, so the same situations and requirements 453 apply. 455 5. Summary of requirements 457 Following the analysis above, a number of different requirements can 458 be identified by the IGMP/MLD proxy to support multiple upstream 459 interfaces. The following table summarizes these requirements. 461 +---------+-----------+-----------+-----------+-----------+-----------+ 462 |Functio- | Multicast | Multicast | Load | Network | Network | 463 |nality | Wholesale | Resiliency| Balancing | Merging | Migration | 464 +---------+-----------+-----------+-----------+-----------+-----------+ 465 |Upstream | | | | | | 466 |Control | X | X | X | X | X | 467 |Delivery | | | | | | 468 +---------+-----------+-----------+-----------+-----------+-----------+ 469 |Downstr. | | | | | | 470 |Control | X | X | X | X | X | 471 |Delivery | | | | | | 472 +---------+-----------+-----------+-----------+-----------+-----------+ 473 |Active / | | | | | | 474 |Standby | | X | | | | 475 |Upstream | | | | | | 476 +---------+-----------+-----------+-----------+-----------+-----------+ 477 |Upstr i/f| | | | | | 478 |selection| | | X | X | | 479 |per group| | | | | | 480 +---------+-----------+-----------+-----------+-----------+-----------+ 481 |Upstr i/f| | | | | | 482 |selection| | X | | | X | 483 |all group| | | | | | 484 +---------+-----------+-----------+-----------+-----------+-----------+ 485 | | | | | | | 486 | ASM | X | X | X | X | X | 487 | | | | | | | 488 +---------+-----------+-----------+-----------+-----------+-----------+ 489 | | | | | | | 490 | SSM | X | X | X | | X | 491 | | | | | | | 492 +---------+-----------+-----------+-----------+-----------+-----------+ 494 Figure 3: Functionality needed on IGMP/MLD proxy with multiple 495 upstream interfaces per application scenario 497 6. Security Considerations 499 All the security considerations in [RFC4605] are directly applicable 500 to this proposal. 502 7. IANA Considerations 504 There are no IANA considerations. 506 8. Acknowledgements 508 The authors would like to thank (in alphabetical order) Alvaro 509 Retana, Thomas C. Schmidt, Stig Venaas and Dirk von Hugo for their 510 comments and suggestions. 512 9. References 514 9.1. Normative References 516 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 517 RFC 1112, DOI 10.17487/RFC1112, August 1989, 518 . 520 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 521 "Internet Group Management Protocol (IGMP) / Multicast 522 Listener Discovery (MLD)-Based Multicast Forwarding 523 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 524 August 2006, . 526 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 527 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 528 . 530 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 531 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 532 Multicast - Sparse Mode (PIM-SM): Protocol Specification 533 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 534 2016, . 536 9.2. Informative References 538 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 539 Thyagarajan, "Internet Group Management Protocol, Version 540 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 541 . 543 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 544 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 545 DOI 10.17487/RFC3810, June 2004, 546 . 548 [RFC4445] Welch, J. and J. Clark, "A Proposed Media Delivery Index 549 (MDI)", RFC 4445, DOI 10.17487/RFC4445, April 2006, 550 . 552 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 553 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", 554 RFC 5213, DOI 10.17487/RFC5213, August 2008, 555 . 557 [RFC5790] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet 558 Group Management Protocol Version 3 (IGMPv3) and Multicast 559 Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, 560 DOI 10.17487/RFC5790, February 2010, 561 . 563 [RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) 564 Version 3 for IPv4 and IPv6", RFC 5798, 565 DOI 10.17487/RFC5798, March 2010, 566 . 568 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 569 Deployment for Multicast Listener Support in Proxy Mobile 570 IPv6 (PMIPv6) Domains", RFC 6224, DOI 10.17487/RFC6224, 571 April 2011, . 573 [RFC7063] Zheng, L., Zhang, J., and R. Parekh, "Survey Report on 574 Protocol Independent Multicast - Sparse Mode (PIM-SM) 575 Implementations and Deployments", RFC 7063, 576 DOI 10.17487/RFC7063, December 2013, 577 . 579 [RFC7287] Schmidt, T., Ed., Gao, S., Zhang, H., and M. Waehlisch, 580 "Mobile Multicast Sender Support in Proxy Mobile IPv6 581 (PMIPv6) Domains", RFC 7287, DOI 10.17487/RFC7287, June 582 2014, . 584 [TECH.3361-1] 585 European Broadcasting Union, "Service Level Agreement for 586 media transport services", EBU TECH.3361-1, September 587 2014. 589 [TS23.246] 590 "TS 23.246 Multimedia Broadcast/Multicast Service (MBMS); 591 Architecture and functional description (Release 14) 592 V14.1.0.", 3GPP TS 23.246 V14.1.0 , December 2016. 594 [TS36.300] 595 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) 596 and Evolved Universal Terrestrial Radio Access Network 597 (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 598 10.11.0, September 2013. 600 [Y.1540] ITU-T, "Internet protocol data communication service - IP 601 packet transfer and availability performance parameters", 602 ITU-T Y.1540, July 2016. 604 Authors' Addresses 606 Luis M. Contreras 607 Telefonica 608 Ronda de la Comunicacion, s/n 609 Sur-3 building, 3rd floor 610 Madrid 28050 611 Spain 613 Email: luismiguel.contrerasmurillo@telefonica.com 614 URI: http://lmcontreras.com/ 616 Carlos J. Bernardos 617 Universidad Carlos III de Madrid 618 Av. Universidad, 30 619 Leganes, Madrid 28911 620 Spain 622 Phone: +34 91624 6236 623 Email: cjbc@it.uc3m.es 624 URI: http://www.it.uc3m.es/cjbc/ 626 Hitoshi Asaeda 627 National Institute of Information and Communications Technology 628 4-2-1 Nukui-Kitamachi 629 Koganei, Tokyo 184-8795 630 Japan 632 Email: asaeda@nict.go.jp 634 Nic Leymann 635 Deutsche Telekom 636 Germany 638 Email: n.leymann@telekom.de