idnits 2.17.1 draft-qi-bitar-intarea-sdn-multicast-overlay-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 30) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 11. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 12. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 837 has weird spacing: '...lticast unica...' -- The document date (July 03, 2017) is 2460 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6241' is mentioned on line 1093, but not defined == Unused Reference: 'RFC3376' is defined on line 1157, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: 'EDGE-REP' is defined on line 1164, but no explicit reference was found in the text == Unused Reference: 'IGMP-EVPN' is defined on line 1175, but no explicit reference was found in the text == Unused Reference: 'RFC 7716' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'RFC 6241' is defined on line 1196, but no explicit reference was found in the text == Unused Reference: 'NVO3-MCAST' is defined on line 1202, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-sajassi-bess-evpn-igmp-mld-proxy-00 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-12 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-17 == Outdated reference: A later version (-11) exists of draft-ietf-nvo3-mcast-framework-05 -- Obsolete informational reference (is this intentional?): RFC 6830 (ref. 'LISP') (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Qi, ed. 3 Intended status: Informational Bloomberg 4 Expires: January 03, 2018 5 N. Bitar, ed. 6 Nokia 8 T. Boyes 9 Bloomberg 11 S. Palislamovic 12 Nokia 14 A. Lohiya 15 Juniper 17 Expires: January 2018 July 03, 2017 19 Software-Defined Multicast Network Overlay Framework 20 draft-qi-bitar-intarea-sdn-multicast-overlay-01 22 Abstract 23 This document describes a framework for IP multicast based on 24 the software defined networking paradigm. The framework enables 25 flexible allocation of multicast responsibilities to designated 26 control and forwarding elements, and provides for multicast 27 path computation and programming of the forwarding plane. The 28 objective of this framework is to enable network operators to 29 support IP multicast in an IP/MPLS core free of Protocol- 30 Independent-Multicast (PIM) and MPLS multicast control. The 31 forwarding paradigm provides for multicast replication over 32 unicast and multicast overlays at designated edges, and for 33 native IP and MPLS multicast replication and forwarding in the 34 core. 36 Status of this Memo 37 This Internet-Draft is submitted to IETF in full conformance 38 with the provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet 41 Engineering Task Force (IETF), its areas, and its working 42 groups. Note that other groups may also distribute working 43 documents as Internet-Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six 45 months and may be updated, replaced, or obsoleted by other 46 documents at any time. It is inappropriate to use Internet- 47 Drafts as reference material or to cite them other than as 48 "work in progress." 49 The list of current Internet-Drafts can be accessed at 50 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed 52 at http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on September 13, 2017. 55 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described 65 in Section 4.e of the Trust Legal Provisions and are provided 66 without warranty as described in the Simplified BSD License. 68 Conventions used in this document 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 70 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 71 "OPTIONAL" in this document are to be interpreted as described 72 in RFC-2119 [RFC2119]. 74 Table of Contents 76 1. Introduction ................................................ 4 77 2. Terminology ................................................ 4 78 3. Acronyms ...............................................5 79 4. Problem Statement ........................................... 6 80 5. Multicast SDN Framework Benefits ............................ 8 81 6. Multicast SDN Framework Guiding Principles and Requirements .10 82 7. Multicast SDN Framework Architectural Components ............12 83 8. SDN Multicast Framework .....................................15 84 8.1. SDN Multicast Operational Models .......................16 85 8.1.1. Full Multicast SDN Model Operational Overview ......16 86 8.1.2. Hybrid Distributed-SDN Multicast Model Operational 87 Overview ..................................................18 88 8.1.3. Cut-Through Operational Mode .......................18 89 8.1.4. Summary of Control an Data Planes Applicable to the 90 SDN Multicast Models and Gaps .............................19 91 8.2. SDN Multicast Overlay Control Plane Functionalities ... 21 92 8.2.1. Unicast Topology Discovery .........................21 93 8.2.2. Multicast Topology Discovery .......................22 94 8.2.3. Resource Utilization Monitoring ....................22 95 8.2.4. Multicast Group Membership Discovery ...............22 96 8.2.5. Multicast Sender Discovery .........................23 97 8.2.6. Multicast distribution tree creation and 98 maintenance ...............................................23 99 8.2.7. Multicast forwarding programmability ...............24 100 8.2.8. Entitlement admission control ......................25 101 8.2.9. Bandwidth Admission control ........................25 102 8.3. Multicast Functional Components Implementation .........25 103 8.4. SDN Multicast Management Interfaces ....................26 104 8.4.1. North-Bound Interface ..............................26 105 8.4.2. Multicast SDN Functional Component Facing 106 Interfaces ................................................26 107 8.4.3. Traditional Underlay Network Element Interfaces ....26 108 8.4.4. Information Model and Data Model of Management 109 Interfaces ................................................27 110 9. SDN Control Plane ...........................................27 111 10. Multi-Party Multicast SDN Overlay Interaction ..............27 112 11. Security Considerations ....................................27 113 12. IANA Considerations ........................................28 114 13. References .................................................28 115 13.1. Normative References ..................................28 116 13.2. Informative References ................................28 117 14.0 Acknowledgments ...........................................30 118 Authors Addresses ..............................................30 120 1. Introduction 121 Operators that enable multicast services in their network have 122 traditionally relied on host-based multicast protocols such as 123 Internet Group Management Protocol (IGMP), and core-based 124 multicast protocols such as Protocol Independent Multicast 125 (PIM) with its variants, and more recently MPLS multicast 126 protocols. Some operators have encountered issues with these 127 protocols that have ensued from protocol activities, and perhaps 128 implementation behavior under some scale, that overloaded the 129 control plane of the routing nodes, sometimes effecting 130 scalability, and often leading to network instability. There 131 are four sources for this activity: (1) high dynamicity of 132 group membership, resulting in a high rate of join/leave, (2) 133 refresh of multicast soft state, (3) faulty implementation, and 134 (4) malicious attacks. 136 This document describes a framework for IP multicast based on 137 the software-defined networking (SDN) paradigm. The objective 138 of this framework is to allow an operator to flexibly design IP 139 multicast networks to fit its needs, and minimize network risks. 140 Specifically, it enables an operator to provide for multicast 141 services in its network without PIM or MPLS multicast signaling 142 protocols (i.e., point to multipoint Resource Reservation 143 protocol - Traffic Engineering (RSVP-TE), or Multicast Label 144 Distribution Protocol (MLDP)). The elimination of these 145 protocols from network elements alleviates a good amount of 146 control plane activity often consumed by these protocols to 147 establish and maintain multicast soft sate, minimizing network 148 stability risks and providing for better scale. 150 The SDN control plane described in this framework, provides for 151 (1) processing join and leave requests from receivers (e.g., 152 IGMP, PIM) or applications that request the addition or pruning 153 of receivers, (2) multicast entitlement and bandwidth admission 154 control, (3) the computation of a multicast path if necessary, 155 and (4) the establishment of the necessary forwarding states in 156 the nodes on the computed forwarding path. 158 2. Terminology 159 This document adopts the following SDN terminology from RFC7426 160 (SDN: Layers and Architecture Terminology): 162 - Software-Defined Networking (SDN): A programmable 163 network approach that supports the separation of control and 164 forwarding planes via standardized interfaces. 166 - Forwarding Plane (FP): The collection of resources across 167 all network devices responsible for forwarding traffic. 169 - Control Plane (CP): The collection of functions responsible 170 for controlling one or more network devices. CP instructs 171 network devices with respect to how to process and forward 172 packets. The control plane interacts primarily with the 173 forwarding plane and, to a lesser extent, with the operational 174 plane. 176 Furthermore, this document adopts the following terminology 177 from RFC 7365, Framework for Data Center (DC) Network 178 Virtualization: 180 Tenant: The customer using a virtual network and any associated 181 resources (e.g., compute, storage, and network). A tenant 182 could be an enterprise or a department/organization within an 183 enterprise. 185 Tenant System: A physical or virtual system that can play the 186 role of a host or a forwarding element such as a router, 187 switch, firewall, etc. It belongs to a single tenant and 188 connects to one or more virtual networks (VNs) of that tenant. 190 3. Acronyms 191 ASM: Any-Source Multicast 192 MSN: Multicast Service Node 193 MSE: Multicast Service Edge 194 MBG: Multicast Border Gateway 195 SSM: Source-Specific Multicast 196 TES: Tenant End System 197 VM: Virtual Machine 198 VN: Virtual Network 199 VXLAN: Virtual eXtensible LAN 200 DC: Datacenter 202 4. Problem Statement 203 IP multicast in core IP networks has prevailingly relied on 204 PIM-ASM to establish a multicast tree between the first hop 205 router connected to a sender and the edge routers connected 206 to receivers, and relied on multicast source discovery protocols 207 to discover multicast sources. PIM is a soft state protocol 208 that relies on periodic join refreshes to keep the multicast 209 states alive and its mode of forwarding requires data-driven 210 events. While PIM-SSM removed some of the above issues for 211 PIM-ASM, it is IGMPv3 dependent and requires out-of-band 212 source discovery mechanism. MPLS multicast signaling protocols, 213 namely point to multipoint RSVP-TE, imposes similar control 214 load on MPLS routers. On access links, edge routers process 215 IGMP messages from attached receivers or CPEs, or PIM messages 216 from attached CPEs. These messages signal to edge routers the 217 multicast membership state of the attached devices. IGMP is 218 also soft state, requiring periodic refreshes of join/prune 219 messages to refresh multicast membership state, or queries to 220 clean up stale state. 222 Multicast group activity (joining/leaving a multicast group) 223 could be very dynamic, resulting in a high control message 224 rate that increases with the number of multicast receivers, 225 and is highly dependent on the behavior of these receivers in 226 leaving/joining multicast groups. 228 All this control plane activity is performed on (all) nodes 229 in the network to support multicast, risking network control 230 plane scale and stability. 232 Routers not only run multicast control protocols, but also 233 perform data plane multicast, holding multicast forwarding 234 state and performing packet replication and forwarding. 235 Multicast forwarding state is dependent on the number of 236 multicast groups ((*,G) or (S,G)) and number of outgoing 237 interfaces per multicast group. As receivers join or leave 238 multicast groups, these multicast forwarding entries need to 239 be updated, further adding to a router control plane load. A 240 large number of (*,G)/(S, G) multicast states and control 241 information push against the resource limit of network 242 routing hardware (e.g., TCAM, CPU). On an edge node where the 243 number of outgoing interfaces could be very large, this 244 activity is further exacerbated. In addition, data 245 replication shares forwarding capacity (processing cycles and 246 bandwidth) with unicast, often mandating the need to control 247 the capacity allocated for multicast and enforcing it. 249 Native multicast protocol procedures do not address the 250 protection of a router control plane and data plane resources 251 from the negative impacts that multicast enablement may have 252 on these resources. Such negative impacts could be the result 253 of malicious activities, misconfigurations, or simply lack of 254 control on legitimate activities. For instance, a receiver 255 may maliciously join a large number of multicast groups and 256 create shared bandwidth bottlenecks if allowed to 257 successfully join these groups. Such a receiver may also 258 generate IGMP reports at a very high frequency, creating an 259 attack on the access router control plane if not properly 260 controlled. A host may also masquerade itself as a source for 261 many multicast groups, resulting in the creation of a large 262 number of forwarding state on the access router and other 263 core nodes. Some router vendors have implemented mechanisms 264 to protect against such attacks (malicious or not) on the 265 router control and data plane, but often these mechanisms are 266 not implemented, partially implemented or not implemented 267 with a consistent behavior let alone configuration as they 268 are vendor proprietary. Lack of consistency poses challenges 269 to network operators when multicast is to be enabled in a 270 multi-vendor environment. 272 Without some type of entitlement that could be defined and 273 uniformly enforced across all edge routers, a rogue multicast 274 sender that knows active multicast groups can send traffic to 275 these groups. The same goes for multicast receivers who may 276 snoop on multicast traffic that they are not entitled to by 277 simply joining the corresponding multicast group(s). Thus, 278 there is a need to define and enforce entitlement for 279 receivers to join multicast groups and for senders to be able 280 to send traffic to multicast groups to protect against the 281 negative impacts that sender and receiver misconfigurations 282 or malicious activities could inflict. 284 There is need to (1) protect against multicast control 285 plane message attacks that may or may not result in a 286 receiver successfully joining a multicast group, (2) be able 287 to define and enforce entitlement for both receivers of and 288 senders to multicast groups, and (3) to protect against the 289 oversubscription of resources beyond set engineering targets 290 by performing resource (bandwidth and other resources) 291 admission control. 293 Multicast entitlement, admission control and control DDoS 294 protection are hard to implement in existing networks when 295 relying on router vendor implementations as they do not 296 holistically or uniformly address all needs, if any. 298 Finally, there is no multicast management plane or north- 299 bound interface to harness multicast control state and 300 telemetry information that enable monitoring the state of the 301 network and enable controlling the usage of network resources. 303 5. Multicast SDN Framework Benefits 304 The multicast SDN framework is composed of an overlay control 305 plane that computes multicast distribution paths between 306 senders and receivers per multicast group/channel, and 307 establishes the forwarding path on forwarding elements, 308 enabling the distribution of multicast traffic between these 309 senders and receivers, and provides for increased 310 functionality and flexibility. The multicast overlay control 311 plane on centralized multicast SDN controller(s) alleviates 312 the multicast control plane activities performed by routing 313 nodes in traditional networks. The controller could be an 314 existing controller with multicast capability or a separate 315 multicast controller. 317 The multicast SDN framework provides the following benefits: 319 - By alleviating multicast control protocols and associated 320 processing and states off the distributed traditional 321 routing nodes in a network, the routing control plane of 322 these nodes will have an order of magnitude reduction in 323 complexity and a significant reduction in processing load, 324 improving network stability and scalability and faster time 325 to recovery from failures. 327 - Much fine grained policy and advanced service enhancements 328 such as multicast control policy (access control, admission 329 control, entitlements and bandwidth), can be implemented 330 directly and consistently in the SDN multicast control 331 plane. This functionality can be and has been implemented 332 in traditional routers but at the expense of additional 333 processing requirements on the control plane and the burden 334 of ensuring consistent implementation across various 335 vendors. 337 - Much fine grained multicast path selection based on various 338 attributes (e.g., bandwidth, diversity, latency) and 339 programming, and various degree of replication, alleviating 340 the current congruency between multicast and unicast 341 topologies and providing flexibility in carving multicast 342 paths for multicast groups and receivers. 344 - Multicasting across Campus, Datacenter, Wide Area Network, 345 and multiple administrative boundaries under the same 346 enterprise control can be implemented with a unified and 347 integrated Management Plane and Control Plane. 349 - Multicasting across administrative boundaries under the 350 control of different enterprises/operators, 351 can be implemented leveraging SDN mechanisms and/or 352 traditional distributed control mechanisms, depending on 353 the capabilities of the neighboring enterprise/operator 354 domains. 356 - Control and/or management plane applications can 357 compute, modify, steer, and program forwarding plane 358 multicast paths, and query and harness state information 359 from the routing nodes performing multicast forwarding 360 using north bound interfaces from these nodes. 362 - Flexible design of the multicast services in the operator 363 network to address operator design principles and 364 the capabilities of the forwarding elements. 366 - Agnosticism to whether an endpoint, multicast receiver or 367 sender, is a VM, container, or a physical host as they 368 all use the same overlay multicast service mechanisms. 370 - Applications can steer multicast path, query and harness 371 state information from SDN multicast overlays using 372 northbound interfaces. 374 6. Multicast SDN Framework Guiding Principles and Requirements 376 Following are the requirements that MUST be satisfied by the 377 Multicast SDN framework: 379 - No constraint on the network topology. The SDN framework will 380 need to be aware of the unicast and multicast network 381 topology when it needs to compute unicast and multicast paths 382 that satisfy certain constrains and/or to optimize for 383 network usage resources on these paths. 385 - No constraint on the unicast routing protocol selection in the 386 underlay network. The network may consist of multiple domains 387 with different unicast routing protocols. 389 - Be agnostic to other services in the network (e.g., 390 BGMP/MPLS unicast and multicast Layer2 and Layer3 services, 391 other types of VPN services). That is, it MUST allow new 392 multicast services to be enabled based on this framework in 393 the presence of other services. 395 - Support IPv4, IPv6, and MPLS unicast underlay data plane, 396 providing for edge replication over IPv4, IPv6,or MPLS 397 unicast overlays. 399 - Support IPv4, IPv6, and MPLS multicast data planes, providing 400 for replication over IPv4, IPv6, and MPLS 401 multicast overlays, and for the computation and programmability 402 of the overlay data paths on the underlay as needed. 404 - Support a BIER [BIER-ARCH] underlay data plane to support 405 multicast replication of multicast packets over BIER type of 406 multicast overlays. 408 - Support a segment-routing (SR) [SR-ARCH] underlay data plane to 409 support edge replication of multicast packets over unicast SR 410 overlays with both IP and MPLS data planes. 412 - Support stitching of multicast packets across domains with 413 the different control and data planes stated in the earlier 414 requirements. 416 - Integrate with network multicast (control and data plane) 417 where operationally feasible resulting in optimum bandwidth 418 utilization in data plane. 420 - Enable decoupling of multicast topology from unicast 421 topology, providing the ability to enable multicast 422 selectively on nodes, and/or carving multicast paths. 424 - Enable select edge data replication nodes, specifically when 425 the first hop router connected to the Multicast sender is not 426 best suited for data replication. 428 - Support existing multicast applications without requiring any 429 modification to these applications, e.g., applications that 430 use IGMP for multicast membership 432 - Support the tunable aggregation of multicast groups on 433 multicast tunnels (where tunnels may be stateful tunnels, 434 or simply encapsulation headers) 436 - Enabling operators to traded-off multicast data plane 437 bandwidth efficiency with multicast data plane and control 438 plane state 440 - Support multicast admission control on unicast tunnels/paths, 441 multicast tunnels, and path (re-) computation on the 442 underlay. 444 - Support multicast admission control based on entitlement of 445 the receiver to a multicast group or channel 447 - Support programmability of multicast traffic policers and 448 filter policies 450 7. Multicast SDN Framework Architectural Components 452 Multicast Service Edge (MSE): 453 An MSE connects to tenant end systems (TESs) (hosts) on the 454 access side and to an underlay IP network or IP/MPLS network on 455 the network side. In the forwarding plane, When an MSE receives 456 a user IP multicast packet from a TES on the access side, it 457 replicates the packet on local ports with TES receivers, and 458 encapsulates the IP multicast packet in a unicast packet to a 459 Multicast Service Node (MSN) or a Multicast Border Gateway 460 (MBG) to reach remote multicast receivers. It also receives IP 461 multicast packets encapsulated in unicast packets on the 462 network side, decapsulates the multicast packets and replicates 463 them on local ports to corresponding TES receivers. In the 464 control plane, an MSE connects to a multicast controller that 465 programs the MSE with multicast forwarding entries triggered by 466 management entities or dynamic control protocols. An MSE may 467 receive IGMP or Multicast Listener Discovery protocol (MLD) 468 report/leave packets on the access side. The MSE acts as an 469 IGMP/MLD proxy and sends messages to the multicast SDN 470 controller to inform the controller of local multicast receivers 471 for a multicast group or channel. It may also be statically 472 programmed with multicast entries. An MSE supporting multi-tenancy 473 provides for multicast control and forwarding in a tenant specific 474 virtual routing and forwarding context. It can be implemented in 475 hardware or software. For example, it can be part of a virtual 476 router in a virtualized environment, a kernel or user-plane 477 routing function in physical servers, a physical router, or 478 appliance which performs multicast service functions. 480 There are multiple ways an MSE can intercept multicast control 481 messages and multicast data packets from TESs when the TESs 482 are receivers and senders, respectively: 483 - MSE is a multicast router on local VLAN 484 - MSE is a designated multicast router for a LAN router. A LAN 485 router (e.g., a Top of rack (ToR) router in a DC) forwards 486 all multicast packets it receives to a designated MSE 487 - MSE is part of virtual switch/router on a virtualized host 488 - MSE is a kernel function and intercepts data frames 489 - MSE resides in a NIC of the TES and intercepts all frames in 490 and out of the NIC. 491 - MSE is a customer edge (CE) router for a local site. 493 Multicast Tunnel TES (MT-TES): 494 An MT-TES is a tenant end system (host), virtual or physical, 495 that may send or receive multicast packets encapsulated in 496 unicast IP/UDP packets and delivers them to local applications 497 based on the UDP port number in the encapsulating header or 498 multicast destination address. 500 Multicast Service Node (MSN): 501 An MSN is the network entity that receives and replicates 502 IP/Multicast packets from/to others MSNs, MBGs, MSEs and MT- 503 TESs in the data plane. An MSN is often designated to serve an 504 MSE with multicast receivers and senders, and/or MT-TESs. There 505 could be more than one MSN serving the same MSE or the same MT- 506 TES. In that case, the selection of the MSN can be based on 507 whether the MSE or MT-TES is sending or receiving multicast 508 packets to/from the network, and/or multicast group address or 509 multicast channel based on the tuple multicast source (S) and 510 multicast group address (G). An MSN may tunnel packets over the 511 underlay network to other MSNs and MBGs using unicast 512 tunnels/unicast header encapsulation, or may forward multicast 513 packets natively on the underlay. An MSN always forwards 514 multicast traffic encapsulated in unicast packets to MSEs and 515 MT-TESs as programmed. On the network side, an MSN may 516 participate in native IP multicast control and forwarding if so 517 configured. The multicast controller MAY also program underlay 518 multicast forwarding entries and the forwarding unicast entries 519 that correspond to the unicast forwarding information in the 520 encapsulating header of the packet carrying multicast packets 521 on the MSN for policy-based routing and forwarding purposes. 522 Alternatively, the unicast packets, encapsulating the multicast 523 packets, can be forwarded based on underlay dynamic unicast 524 routing, the default behavior. Unlike MSE, MSN does not connect 525 to access networks or TESs. MSN can optimize replication based on 526 latency, bandwidth, QoS, number of multicast states desired or 527 even more specific multicast application requirements. 528 MSN can be implemented in hardware or software. For example, it 529 can be a physical router, or a software appliance which performs 530 multicast service functions. Each MSN has a forwarding plane and 531 a control plane, albeit new control plane functionality and 532 traditional control plane functionality implemented today are 533 relegated to an SDN multicast controller. 535 Multicast SDN Domain (MSD): 536 A multicast SDN domain encompasses forwarding nodes (MSEs, 537 MSNs, and MBGs) and a cluster of one or more multicast SDN 538 controllers that control the programming of tenant multicast 539 forwarding entries on these nodes in addition to underlay core 540 nodes that provide for IP connectivity among these nodes. 542 Multicast Border Gateway (MBG): 543 An MBG is a network forwarding node that sits at the border of 544 a multicast SDN domain and connects to other networks in 545 different domains, which could be either multicast SDN domains 546 or traditional networks with multicast capabilities in the same 547 or different administrative domains. An MBG forwards multicast 548 packets from one domain to another across the boundary and 549 forwards packets to MSNs within its domain. An MBG could also 550 implement MSN functionality, serving MSEs and MT-TESs. As an 551 example, in cloud networking whereby the cloud is composed of 552 multiple data centers (DCs), an MBG may perform the function of 553 a DC multicast gateway to the WAN to provide for the forwarding 554 of multicast traffic originated by one TES in one DC to TESs 555 located in other DCs. In this case, the MBG may use BGP/MPLS 556 Multicast VPN (BGP-MVPN) [RFC 6513] across the WAN. Inside a 557 domain, an MBG may be enabled with traditional IP multicast 558 control and forwarding on the network underlay links to perform 559 underlay multicast forwarding. Alternatively, underlay 560 multicast forwarding entries reachable within the domain may be 561 programmed by the corresponding multicast SDN control plane. 562 Overlay traffic may be tunneled to/from the MBG using unicast 563 tunnels/unicast-header encapsulation or multicast 564 tunnels/multicast header encapsulation. 566 An MBG can be implemented in hardware or software. For example, 567 it can be a physical router, or a software appliance which 568 performs multicast service functions albeit new control plane 569 functionality and traditional control plane functional 570 implemented today are relegated to an SDN multicast controller. 572 Core Node (CN): 573 A CN is a routing node which provides the underlay 574 interconnectivity among the MSEs, MSNs and MBGs. It provides for 575 unicast IP, MPLS, and SR forwarding and may provide multicast IP, 576 MPLS and/or BIER forwarding. 578 8. SDN Multicast Framework 579 Figure 1 depicts the SDN multicast framework, specifically the 580 SDN management plane, control plane and data plane functional 581 elements and their interactions. In the full SDN model, control 582 of any data plane element for multicast is under the control of 583 the Multicast SDN control plane. Variants of this model that 584 leverage existing solutions (e.g., BGP-MVPN) are described in 585 this document to fit different deployment models. 586 +------------------------------------+ 587 | | 588 | Management/Application | 589 | | 590 +------------------------------------+ 591 ^ 592 |MApp-C 593 | 594 +-----------------------------------------------+ 595 | | 596 | Multicast SDN Control | 597 | | 598 +-----------------------------------------------+ 599 ^ ^ ^ ^ ^ ^ 600 |MSE-C |MSN-C |MBG-C |MC-C |MSN-C |MTTES-C 601 | | | | | | 602 | | | | | | 603 +----+ +---+ +---+ | +---+ +---+ ( ) +-------+ 604 | TES|---|MSE|----|MSN|----|----| CN|----|MSN|-( )--| MT-TES| 605 +----+ +---+ +---+ | +---+ +---+ ( ) +-------+ 606 IGMP | 607 MLD | 608 +---+ 609 +--|MBG|--+ 610 | +---+ | 611 | | 612 | | 613 | Network | 614 | | 615 . | | 616 . \+-------+/ 617 | MBG | 618 +-------+ 619 Figure 1: SDN multicast framework reference diagram. 621 8.1. SDN Multicast Operational Models 622 8.1.1. Full Multicast SDN Model Operational Overview 624 This section provides an overview of the full SDN multicast 625 model and describes the transactions and information that needs 626 to be exchanged across the different interfaces, including the 627 interfaces between the multicast SDN controller and the various 628 multicast nodes (MSE, MSN, CN, MBG). Throughout this section 629 it should be assumed that all multicast operations on any of 630 the edge nodes are done in a tenant context. In the case of 631 multi-tenancy, MSEs, MSNs and MBGs must be able to perform 632 destination lookup and forwarding in a virtual routing and 633 forwarding (VRF) context. In addition, they must be able to 634 encapsulate the original multicast packet with a unicast 635 (tunnel) header and additional header information that carries 636 a tenant identifier that can be used to identify the forwarding 637 context at the receiving end. 639 Senders and receivers for a multicast group may be static or 640 dynamic. For each tenant and multicast group, the SDN multicast 641 controller is informed of the sender(s) via the controller 642 northbound management interface (MApp-C) or the MSE connected 643 to the sender(s) via the MSE-C interface. The SDN controller, 644 in the generic case, will select an MSN that will proxy the MSE 645 connected to the sender, and programs the MSE to send the 646 multicast group traffic it receives from the sender(s) to the 647 selected MSN. The SDN controller may select more than one such 648 MSN. The multicast group packets will be delivered to tenant 649 end systems served by other MSEs and MSNs from these selected 650 MSNs. For static TES multicast receivers on a particular group 651 or channel, the SDN controller knows which TESs are members of 652 a multicast group/channel via the MApp-C management interface, 653 and learns the MSE serving the TES via the MApp-C management 654 interface or via dynamic routing. Then for each TES on that 655 multicast group, The SDN controller selects the MSN to serve 656 the corresponding MSE. This selection could be based on certain 657 criteria that optimize for bandwidth utilization on the path 658 between the MSN and the MSE, and/or resource utilization on the 659 MSN among others. Once an MSN selection is done to serve the 660 MSE, the SDN multicast controller needs to ensure that the 661 selected MSN receives the multicast group/channel traffic. The 662 SDN controller then selects the remote MSN from which it wants 663 to receive the multicast group packets. This latter selection 664 could be based on bandwidth utilization on the path between the 665 two MSNs in question, remote MSN resources, and/or the 666 transport method (multicast or unicast tunnel/tunneling 667 encapsulation). In the case of unicast transport, the remote 668 MSN proxying the sender MSE is programmed via the MSN-C interface 669 with a forwarding entry that results in encapsulating the 670 multicast group packets with a unicast SR, IP or MPLS tunnel or 671 encapsulation header that delivers the packets to the MSN serving 672 the receiver MSE. The MSN serving the receiver MSE is also 673 programmed with an entry that results in forwarding the received 674 multicast packet over another tunnel encapsulation to the 675 destination MSE. Optionally, the MSN serving the receiver MSE may 676 be programmed with the tunnel/encapsulation header information 677 over which the multicast group packets will be delivered (i.e., 678 the sender MSN IP address or MPLS tunnel). Unicast forwarding is 679 based on dynamic routing information, static (policy-based) 680 routing or MPLS signaling in the case of RSVP-TE. In the case of 681 multicast transport, the SDN controller may choose to add a new 682 multicast tree branch to an existing multicast tree or re-compute 683 a new one rooted at the sender. In the case of IP multicast 684 transport, and in the absence of PIM in the core, the SDN 685 controller programs the CNs on the path with the appropriate 686 multicast forwarding entries. The MSE could also optionally be 687 programmed with the tunnel/header encapsulation information over 688 which packets are to be received. 690 For dynamic receivers, a TES may initiate an IGMP report or MLD 691 join message for a multicast group. That message should be 692 received by the MSE. The MSE may act as an IGMP proxy/MLD proxy 693 in which case the MSE, upon receiving the first join message 694 from a connected TES for a multicast group/channel, sends a 695 join message for that multicast group/channel with tenant 696 context to the SDN controller over the MSE-C interface. In 697 case there is requirement for entitlement or bandwidth 698 admission control, the MSE always sends a message to the SDN 699 controller over the MSE-C interface, requesting admission 700 control for the requesting TES for the particular 701 group/channel, including the tenant context. If the request is 702 admitted, the MSE is informed of the admission decision and the 703 transport path setup proceeds as described for the static 704 receiver case. In the proxy case, when the last receiver leaves 705 a multicast group on the MSE either via an explicit leave, 706 failure to respond to a query or failing, the MSE sends a message 707 to the SDN controller that it no longer has receivers for that 708 group/channel via the MSE-C interface, and the controller may 709 remove the MSN as being a receiver for that group/channel and 710 take appropriate action removing associated forwarding state on 711 other nodes (MSNs, CNs). 713 8.1.2. Hybrid Distributed-SDN Multicast Model Operational 714 Overview 715 In this model, MSNs and MBGs perform the role of an BGP-MVPN PE 716 with a distributed BGP-MPLS control plane for exchanging 717 receiver information in a tenant network (MVPN) with other MSNs 718 and MBGs. The programmability of the MSNs with the receiver 719 information is done via the SDN controller to create the 720 relevant BGP policies and enable tunneling of multicast traffic 721 to served MSEs. 723 8.1.3. Cut-Through Operational Mode 724 In the cut-through model, a sender MSE can send multicast 725 packets directly to remote receiver MSE(s), bypassing MSNs and 726 MBGs. That is, MSNs do not proxy for downstream MSEs. In this 727 case, the multicast SDN controller programs a sender MSE via 728 the MSE-C interface with a forwarding entry that results in 729 encapsulating the multicast group packets received at the MSE 730 from the access network with a unicast IP header and a tenant 731 identifier that delivers these packets to remote receiver 732 MSE(s). The receiver MSE is also programmed with an entry that 733 results in forwarding the received multicast packet to 734 downstream multicast receivers. Similarly, Sender MSE can send 735 multicast packets directly to receiver MT-TESs with the same 736 operational procedures. 738 It should be noted that upon operator configuration, a 739 multicast deployment MAY include one or more of the operational 740 models described in the SDN multicast framework section. 742 8.1.4. Summary of Control an Data Planes Applicable to the SDN 743 Multicast Models and Gaps 745 Table 1: Underlay and overlay control planes applicable 746 to the various SDN multicast models, and gaps (new). 747 ---------------------------------------------------------------- 748 |Model | Multicast Underlay | Multicast Overlay | 749 | | Control Plane | | 750 ---------------------------------------------------------------- 751 | Full SDN | MSE LAN access options: | MSE: MSE-MSDNC (new) | 752 | | IGMP, MLD, PIM, static | MSN: MSN-MSDNC (new) | 753 | | MSE/MSN/MBG/CN-MSDNC (new) | | 754 ---------------------------------------------------------------- 755 | Hybrid | MSE LAN access options: | MSE: MSE-MSDNC (new) | 756 | | IGMP, MLD, PIM, static | MSN: MSN-MSDNC (new) | 757 | | | | 758 | |MSN-MSE: None | MSN & MBG options: | 759 | |Core (MSN-CN-MBG) options: | MBGP (membership) | 760 | | MSDN Control | LISP[LISP][LISP-mcst]| 761 | | IGP (for BIER data plane)| | 762 | | PIM (core multicast IP) | | 763 | | MPLS multicast(MPLS core)| | 764 | | IGP (SR) | | 765 | | | | 766 | | MSDNC-MSDNC (new) | | 767 ---------------------------------------------------------------- 768 |Cut-Though|MSE LAN access options: | MSE options: | 769 | | IGMP, MLD, PIM | MSE-MSDNC (new) | 770 | | | MBGP (membership) | 771 | |MSE options: | LISP | 772 | | None | | 773 | | | | 774 | |Core (MSN-CN-MBG) options: | | 775 | | IGP (BIER data plane) | | 776 | | PIM (core multicast IP) | | 777 | | MPLS multicast(MPLS core)| | 778 | | | | 779 | | Multicast SDN Controller | | 780 | | (MSDNC)-MSDNC (new) | | 781 ---------------------------------------------------------------- 783 ---------------------------------------------------------------- 784 | Underlay Control Plane Protocol Options | 785 |Unicast: BGP OSP/ISIS (SR support) RSVP-TE/LDP | 786 |Multicast PIM IGMP/MLD pt-mpt RSVP-TE/mLDP | 787 ---------------------------------------------------------------- 788 | Overlay Control Plane Protocol Options | 789 | MBP LISP NVo3 (TBD) Multicast SDN (TBD) | 790 ---------------------------------------------------------------- 791 Figure 2: Summary of underlay and overlay control protocol 792 options. 794 Table 2: Underlay and overlay data plane applicable 795 to the various SDN multicast models. 796 ----------------------------------------------------------------- 797 |Model | Multicast Underlay | Multicast Overlay | 798 | | Data Plane | Data Plane | 799 ----------------------------------------------------------------- 800 | Full SDN | MSE LAN access: | MSE LAN access: | 801 | and | IP multicast | Not applicable | 802 | Hybrid | | | 803 | | MSN,MBG and CN options:|MSE-MSN core options: | 804 | | -IP multicast | -IP multicast in IP VXLAN | 805 | | -BIER | or IP/GRE/VPN unicast | 806 | | -IP unicast | -IP multicast in SR VPN | 807 | | -SR | MPLS encap | 808 | | -MPLS unicast | -IP multicast in LISP | 809 | | -MPLS multicast | encap | 810 | | | | 811 | | | MSN/MBG options:: | 812 | | | -IP multicast in IP VXlAN | 813 | | | or IP/GRE/VPN o LISP | 814 | | | unicast | 815 | | | -IP multicast in BIER | 816 | | | -IP multicast in MPLS | 817 | | | VPN multicast | 818 | | | -IP multicast in SR VPN | 819 | | | MPLS | 820 ---------------------------------------------------------------- 821 |Cut-Through| MSE LAN access: | MSE LAN access: | 822 | | IP multicast | Not applicable | 823 | | | | 824 | | MSN,MBG and CN options:|Core(MSE-MSN) options: | 825 | | -IP multicast | -IP multicast in IP VXLAN | 826 | | -BIER | or IP/GRE/VPN unicast | 827 | | -IP unicast | -IP multicast in SR VPN | 828 | | -SR | MPLS encap | 829 | | -MPLS unicast | -IP multicast in LISP | 830 | | -MPLS multicast | uncap | 831 | | | | 832 ---------------------------------------------------------------- 834 ---------------------------------------------------------------- 835 | Underlay Data Plane Protocol Options | 836 | IPv4 IPv6 MPLS BIER SR| 837 |unicast/multicast unicast/multicast unicast/multicast | 838 ---------------------------------------------------------------- 839 | Shim header (carries tenant identifier: | 840 | VXLAN LISP GRE/MPLS MPLS | 841 ----------------------------------------------------------------- 842 | Overlay Data Plane Protocols | 843 | IPv4 multicast IPv6 multicast | 844 ---------------------------------------------------------------- 845 Figure 3: Summary of underlay and overlay data plane protocol 846 options. 848 8.2. SDN Multicast Overlay Control Plane Functionalities 849 Multicast control is traditionally distributed on network 850 routing elements, and mainly responsible for building and 851 maintaining multicast distribution trees or transport, and 852 configuring the multicast forwarding plane. Control Plane 853 entities may exchange multicast sender or receiver-membership 854 information with each other using network protocols such as MP- 855 BGP or PIM. The full multicast SDN model described in this 856 document alleviates the distributed control plane functions 857 from network elements but preserves the functionalities needed 858 to discover multicast membership and source information, build 859 multicast distribution trees and/or multicast transport 860 tunnels. 862 The SDN Multicast Control plane in the full multicast SDN model 863 Must include the following functionalities: 865 - Unicast topology discovery interconnecting MSEs, MBGs, MSNs 866 and CNs 867 - Multicast topology discovery including MSEs, MSNs, MBGs, and 868 CNs enabled for multicast 869 - Resource utilization monitoring on links and nodes 870 - Multicast group membership discovery and maintenance 871 - Multicast source discovery and maintenance 872 - Multicast distribution tree creation and maintenance 873 - Multicast path selection, instantiation, maintenance and 874 failover 875 - Multicast forwarding programmability 877 The SDN Multicast control plane SHOULD include the following 878 functionalities 880 - Entitlement admission control 881 - Bandwidth Admission control 883 8.2.1. Unicast Topology Discovery 884 The unicast Topology is needed to discover reachability among 885 MSEs, MSNs and MBGs for MSN selection or MBG selection. In 886 addition, the unicast topology will be needed if traffic is to 887 be carried using any unicast tunneling technology (IP, MPLS, SR 888 with IP or MPLS data planes), or pt-to-pt RSVP-TE. In this 889 latter case the TE tunnels may be computed by the underlying 890 router. Alternatively, the TE tunnels paths MAY be computed by the 891 SDN controller. The same may apply for Traffic engineered SR 892 paths. The SDN control plane SHOULD always maintain a database of 893 these TE tunnels/paths and associated capacity, irrespective 894 how they are computed, enabling the SDN controller to 895 selectively bind multicast traffic to TE paths. The SDN 896 multicast control plane and network elements that will be used 897 to learn the unicast topology SHOULD support BGP-LS [RFC 7752] or 898 YANG topology data models [Yang-Topology-Model]. The SDN control 899 plane SHOULD learn the unicast topology via BGP-LS or YANG from 900 the network nodes. The SDN controller MUST also learn TES 901 reachability via MSEs using same mechanisms. 903 8.2.2. Multicast Topology Discovery 904 The SDN multicast control plane MUST have knowledge of all the 905 MSNs, MBGs and MSEs and their multicast resources. In case the 906 core network is also enabled for multicast and the SDN control 907 plane is to compute multicast trees, the SDN control plane MUST 908 know which nodes are enabled for multicast forwarding and 909 enabled for PIM. The Multicast topology is used by the 910 multicast SDN control plane to select MSNs and MBGs and to 911 compute multicast tree paths. The multicast tree could be based 912 on native IP multicast or pt-to-mpt RSVP-TE. The SDN multicast 913 control plane MUST maintain the computed paths and the 914 receivers and senders mapped to them. 916 8.2.3. Resource Utilization Monitoring 917 The SDN control plane MUST maintain knowledge of the available 918 resources on the nodes that may be impacted resource-wise by 919 being on multicast paths selected by the SDN controller. For 920 instance, the SDN controller MUST maintain the available 921 resources for multicast forwarding entries on MSEs, MSNs and 922 MBGs. In addition, if bandwidth and link utilization is to be 923 considered as part of the path selection, the SDN controller 924 MUST maintain knowledge of the utilization on network links. 926 8.2.4. Multicast Group Membership Discovery 927 The SDN Controller MUST learns via the MApp-C management 928 interfaces or the MSE-C/MTTES-C interfaces the receivers and 929 senders for each multicast group or channel. 931 When the list of multicast receivers and senders for each 932 multicast group in a tenant network is known in advance and 933 when multicast session establishment (set of senders and 934 receivers for a multicast group) can be set up ahead of time of 935 actual multicast data delivery, applications can use the 936 multicast SDN controller northbound interface (MApp-C) to 937 populate the list of receivers and senders for the multicast 938 group in the SDN controller. The SDN controller may also have 939 access to a database, or be programmed with information via 940 MApp-C, that associates the receivers and senders with MSEs. 942 8.2.5. Multicast Sender Discovery 943 The multicast SDN controller MUST learn the set of senders for 944 each multicast group. This information May be learned via the 945 MSE-C/MTTES-C interfaces from MSEs or TESs, or via the MApp-C 946 interface from a management application. The SDN controller 947 could obtain the location of the sender (which MSE a sender is 948 connected to) from routing information, or via MApp-C and MSE-C 949 interfaces. 951 8.2.6. Multicast Distribution Tree Creation and Maintenance 952 The SDN controller MUST be able to compute a multicast 953 distribution tree. There could be several segments for a 954 multicast distribution tree depending on the capabilities 955 of the network elements, and/or the operator design. Following 956 are the distribution tree types: 958 1- Distribution Tree Type 1: The distribution tree is rooted at 959 one MSN that receives a multicast group source traffic from 960 an MSE. Then, that MSN encapsulates the multicast traffic 961 with a unicast tunneling header to other MSNs connected to 962 MSEs with receiver TESs for that group, and to other MBGs to 963 reach TES receivers in other domains. 964 2- Distribution Tree Type 2: The distribution Tree is rooted at 965 one MSN that receives a multicast group source traffic from 966 an MSE. Then, the MSN encapsulates the traffic with a 967 multicast tunneling header or in a multicast tunnel with 968 leaves being other MSNs and MBGs to reach receivers. When an 969 MSN receives the tenant multicast traffic on a multicast 970 tunnel/encapsulated in a multicast tunneling header, it 971 decapsulates the tenant multicast packets and unicast tunnel 972 them to the MSEs with receiver TESs for that group. 974 In computing the multicast tree, the SDN controller SHOULD take 975 into account constraints on bandwidth and other QoS parameters 976 such as latency, jitter and packet loss in addition to the 977 capabilities of the forwarding plane elements (e.g., native 978 multicast replication support, multicast replication over 979 unicast tunnels, number of multicast entries, bandwidth, etc.) 980 and policies (e.g., which MSN is to serve which MSE, inter-SDN 981 domain policies etc.). A multicast distribution tree is 982 recomputed every time that there is a new edge node (MSE, MSN 983 or MBG) to be added to the multicast tree, or there is an edge 984 node that needs to be pruned out of the multicast tree), adding 985 or removing multicast branches to/from the tree. 987 An SDN multicast controller can map tenant overlay multicast 988 group addresses 1:1 to distinct multicast group addresses in 989 native IP multicast underlay, and program MSNs and MBGs with 990 the appropriate forwarding information. An SDN multicast 991 controller can alternatively map each designated set of tenant 992 overlay multicast group addresses to a unique underlay 993 multicast IP address and accordingly program MSNs and MBGs with 994 the appropriate forwarding information. In this latter case, 995 these tenant overlay multicast groups are aggregated into 996 distinct multicast group address(es) similar to mechanisms in 997 Default or Data MDTs (Multicast Distribution Trees) [RFC 6037]. 998 This aggregation technique can help minimize multicast routing 999 states in native multicast network. 1001 8.2.7. Multicast Forwarding Programmability 1002 Subsequent to the (re-) computation of the multicast tree, the 1003 SDN multicast controller MUST be able to program the multicast 1004 forwarding entries on the forwarding elements: MSE, MSN and 1005 MBG. When supporting dynamic receivers and senders, multicast 1006 tree (re-)computation and programmability must be done 1007 relatively fast so that it does not impact the user experience, 1008 creating a significant delay in starting to receive a multicast 1009 channel that the user joins. In other cases, multicast receiver 1010 applications may also have a requirement on the latency between 1011 sending a join to a multicast channel and starting to receive 1012 data on that channel. Among other things, forwarding 1013 programmability SHOULD enable setting the TTL treatment 1014 behavior. Specifically, an ingress MBG SHOULD be configurable 1015 not to copy the Time to Live (TTL) field from SDN overlay 1016 multicast packets. Operators should take account of the 1017 end-to-end network topology and set the TTL field accordingly. 1019 8.2.8. Entitlement Admission Control 1020 When this function is enabled for a given tenant, the SDN 1021 multicast controller checks if the requesting receiver is 1022 entitled to receive the content of the multicast group/channel 1023 it is requesting to join. The SDN controller MAY be programmed 1024 with the list of receivers that are allowed to receive traffic 1025 from certain source(s), and whereby the receivers may be 1026 identified by IP host addresses, IP subnets or other types of 1027 identifiers. This entitlement information can be configured on 1028 the controller or it may be available through some database or 1029 system that has that information. 1031 8.2.9. Bandwidth Admission Control 1032 Bandwidth admission control prevents content or subscription 1033 overload from senders or receivers as well as provides 1034 important security protection by putting upper limits on how 1035 much traffic each sender or receiver can send or subscribe to. 1036 When this function is enabled, the SDN multicast controller 1037 may perform bandwidth admission control when permitting a 1038 channel to be delivered to a TES and/or when selecting the 1039 multicast channel path. The specification of bandwidth 1040 admission control mechanisms is beyond the scope of this 1041 framework. 1043 8.3. Multicast Functional Components Implementation 1044 MSE, MSN and MBG are functional components that may be co- 1045 located on the same router and implemented in different forms 1046 (physical, virtual, or applications). For example, MSEs and 1047 MSNs can co-locate together in the same physical or virtual 1048 router. 1050 8.4. SDN Multicast Management Interfaces 1051 8.4.1. North-Bound Interface 1052 MApp-C is a northbound interface from the SDN controller that 1053 provides management applications the means to interact with the 1054 SDN controller to set and extract multicast configurations and 1055 information, respectively. It is independent of individual 1056 network devices, vendors or device types. MApp-C interface 1057 SHOULD provide a comprehensive and flexible data model and 1058 messaging methods that allow these applications to access 1059 Multicast SDN Controllers to request the addition or removal of 1060 a receiver to a multicast (S,G) channel, the establishment of a 1061 multicast distribution tree between specified senders and 1062 receivers with potential constraints on bandwidth and QoS for 1063 instance, set entitlement rules, and obtain state information 1064 pertinent to a multicast group or participants in that multicast 1065 group among others. Applications SHOULD have a means to perform 1066 these actions across MSDs, each with an SDN controller, with one 1067 action rather than separate actions initiated with each of the 1068 MSD controllers. 1070 8.4.2. Multicast SDN Functional Component Facing Interfaces 1072 MTTES-C, MSE-C, MSN-C, MBG-C are interfaces between a Multicast 1073 SDN Controller on one hand and TESs and Multicast 1074 SDN forwarding functional components on the other hand. Each 1075 interface is specific to the associated functional component, 1076 and is used to provide control plane and/or data plane 1077 programming of that component and to harness information from 1078 that component. 1080 8.4.3. Traditional Underlay Network Element Interfaces 1082 CN-C is the interface between Multicast SDN controller and core 1083 network elements that provide core forwarding services, as 1084 opposed to edge services provided by MSE, MSN and MBG. The 1085 purpose of CN-C is to provide for programming of network 1086 elements in the core whenever it is possible or necessary, and 1087 to extract operational state information from these elements. 1089 8.4.4. Information Model and Data Model of Management Interfaces 1091 Both northbound interface and SDN functional component facing 1092 interfaces SHOULD be based on RESTCONF [RESTCONF] or 1093 NETCONF [RFC6241]. Their data models should be based on YANG. 1095 9. SDN Control Plane 1097 The SDN Control plane can be composed of one or more 1098 controllers. These controllers will need to cooperate in the 1099 establishment of a multicast distribution tree within MSDs and 1100 across MSDs. How they cooperate or interact is dependent on the 1101 relationship relative to MSDs, ASes, and administrative 1102 entities (operators). In this section, the following cases are 1103 considered: 1104 1- Intra-MSD, Inter-SDN Controller Interactions 1105 2- Inter-MSD, Intra-AS, Inter-SDN Controller Interactions 1106 3- Inter-MSD, Inter-AS, Intra-operator, Inter-SDN Controller 1107 Interactions 1108 4- Inter-MSD, Inter-AS, Inter-operator, Inter-SDN Controller 1109 Interactions 1111 (this section will be completed in a future update). 1112 10. Multi-Party Multicast SDN Overlay Interaction 1114 If multicast senders and receivers are on different multicast 1115 SDN overlay vendor solutions, it SHOULD be possible to setup 1116 and exchange multicast control states as well as underlying 1117 tunneling information. 1119 11. Security Considerations 1120 Following are the security considerations that pertain to the 1121 multicast SDN framework in this document: 1122 1- The communication channel between any data element and the 1123 SDN controller MUST be trusted and secure, with mutual 1124 authentication. This applies to all interfaces (MSE-C, MSN-C, 1125 CN-C, MTTES-C and MBG-C) in order is to prevent rogue 1126 controllers from hijacking multicast traffic, mounting 1127 security attacks on network elements or leaking tenant 1128 multicast traffic to other tenants. 1129 2- MSE must have means to cope with tenant end systems 1130 misbehavior, malicious or malfunctioning, that may result in 1131 control plane attack on the SDN controller, impacting the 1132 stability of the system and as a result impacting multicast 1133 services. The MSE MUST be able to limit the message rate that 1134 could be triggered by tenant end system activity, and the 1135 controller MUST be able to limit message rate and routing 1136 activity changes at the tenant level as that could result in 1137 a DDOS on the multicast services across tenants. 1138 3- The association between a TES and tenant network must be 1139 authentic so that traffic eavesdropping is prevented and a 1140 TES is not allowed to illegally inject multicast traffic into 1141 another tenant network. 1142 4- The SDN controller SHOULD have the means to authorize a TES 1143 to join a multicast channel (entitlement). 1144 5- The SDN controller SHOULD have the means to exercise 1145 admission control to avoid congestion on network links as 1146 causing congestion could be a way to launch a DDOS. 1148 12. IANA Considerations 1149 The document does not require any IANA action. 1151 13. References 1152 13.1. Normative References 1153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1154 Requirement Levels", BCP 14, RFC2119, March 1997. 1156 13.2. Informative References 1157 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and 1158 A. Thyagarajan, "Internet Group Management Protocol, Version 1159 3", RFC 3376, October 2002. 1161 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1162 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1164 [EDGE-REP] Marques P. et al., "Edge multicast replication for 1165 BGP IP VPNs", draft-marques-l3vpn-mcast-edge-01, work in 1166 progress, June 2012. 1168 [RFC 6037] E. Rosen, Y. Cai, I. Wijnands, "Cisco Systems 1169 Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037. 1170 October 2010. 1172 [RFC 6513] E. Rosen E., et al. , "Multicast in MPLS/BGP IP VPNs", 1173 RFC 6513, February 2012. 1175 [IGMP-EVPN] A. Sajassi, et al., "IGMP and MLD Proxy for EVPN", 1176 draft-sajassi-bess-evpn-igmp-mld-proxy-00, October 17, 2015. 1178 [RFC 7716] Z. Zhang, L. Giuliano, E. Rosen, et al., "Global 1179 Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures", 1180 RFC 7716, December 2015. 1182 [BIER-ARCH] IJ. Wijnands, et al. "Multicast using Bit Index 1183 Explicit Replication", draft-ietf-bier-architecture-04, July 1184 18, 2016. 1186 [SR-ARCH] C. Filsfils, et al, "Segment Routing Architecture", 1187 draft-ietf-spring-segment-routing-11, February 16, 2017. 1189 [Yang-Topology-Model] A. Clemm, e al., "A Data Model for Network 1190 Topologies", draft-ietf-i2rs-yang-network-topo-12, March 1, 2017. 1192 [RFC 7752] H. Greedier, et al., "North-Bound Distribution of 1193 Link-State and Traffic Engineering (TE) Information Using BGP", 1194 RFC 7752, March 2016. 1196 [RFC 6241] R. Enns, et al., "Network Configuration Protocol 1197 (NETCONF)", RFC 6241, June 2011. 1199 [RESTCONF] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF 1200 Protocol", draft-ietf-netconf-restconf-17, September 28, 2016. 1202 [NVO3-MCAST] A. Ghanwani, et al., "A Framework for Multicast in 1203 Network Virtualization Overlays", draft-ietf-nvo3-mcast- 1204 framework-05, May 9, 2016. 1206 [LISP] D. Farinacci, et al., "The Locator/ID Separation 1207 Protocol (LISP)", RFC 6830, January 2013. 1209 [LISP-mcst] D. Farinacci, et al., "The Locator/ID Separation 1210 Protocol (LISP) for Multicast Environments", RFC 6831, 1211 January 2013. 1213 14. Acknowledgments 1214 The authors thank Dino Farinacci for his comments and input. 1216 Authors Addresses 1217 David Qi 1218 Bloomberg 1219 EMail: dqi@bloomberg.net 1221 Nabil Bitar 1222 Nokia 1223 EMail: nabil.bitar@nokia.com 1225 Truman Boyes 1226 Bloomberg 1227 EMail: tboyes@bloomberg.net 1229 Senad Palislamovic 1230 Nokia 1231 EMail: senad.palislamovic@nokia.com 1233 Anil Lohiya 1234 Juniper 1235 EMail: alohiya@juniper.net