Internet-Draft D. Qi, ed. Intended status: Informational Bloomberg Expires: September 13, 2017 N. Bitar, ed. Nokia T. Boyes Bloomberg S. Palislamovic Nokia A. Lohiya Juniper Expires: September 2017 March 13, 2017 Software-Defined Multicast Network Overlay draft-qi-bitar-intarea-sdn-multicast-overlay-00 Abstract This document describes a framework for IP multicast based on the software defined networking paradigm. The framework enables flexible allocation of multicast responsibilities to designated control and forwarding elements, and provides for multicast path computation and programming of the forwarding plane. The objective of this framework is to enable network operators to support IP multicast in an IP/MPLS core free of Protocol- Independent-Multicast (PIM) and MPLS multicast control. The forwarding paradigm provides for multicast replication over unicast and multicast overlays at designated edges, and for native IP and MPLS multicast replication and forwarding in the core. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Qi-Bitar Expires September 2017 [Page 1] Internet-Draft SDN Multicast Overlay March 2017 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 13, 2017. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction ................................................ 4 2. Terminology ................................................ 4 3. Acronyms ...............................................5 4. Problem Statement ........................................... 6 Qi-Bitar Expires September 2017 [ Page 2] Internet-Draft SDN Multicast Overlay March 2017 5. Multicast SDN Framework Benefits ............................ 8 6. Multicast SDN Framework Guiding Principles and Requirements .10 7. Multicast SDN Framework Architectural Components ............12 8. SDN Multicast Framework .....................................15 8.1. SDN Multicast Operational Models .......................16 8.1.1. Full Multicast SDN Model Operational Overview ......16 8.1.2. Hybrid Distributed-SDN Multicast Model Operational Overview ..................................................18 8.1.3. Cut-Through Operational Mode .......................18 8.2. SDN Multicast Overlay Control Plane Functionalities ....19 8.2.1. Unicast Topology Discovery .........................19 8.2.2. Multicast Topology Discovery .......................20 8.2.3. Resource Utilization Monitoring ....................20 8.2.4. Multicast Group Membership Discovery ...............20 8.2.5. Multicast Sender Discovery .........................21 8.2.6. Multicast distribution tree creation and maintenance ...............................................21 8.2.7. Multicast forwarding programmability ...............22 8.2.8. Entitlement admission control ......................23 8.2.9. Bandwidth Admission control ........................23 8.3. Multicast Functional Components Implementation .........23 8.4. SDN Multicast Management Interfaces ....................24 8.4.1. North-Bound Interface ..............................24 8.4.2. Multicast SDN Functional Component Facing Interfaces ................................................24 8.4.3. Traditional Underlay Network Element Interfaces ....24 8.4.4. Information Model and Data Model of Management Interfaces ................................................25 9. SDN Control Plane ...........................................25 10. Multi-Party Multicast SDN Overlay Interaction ..............25 11. Security Considerations ....................................25 12. IANA Considerations ........................................26 13. References .................................................26 13.1. Normative References ..................................26 13.2. Informative References ................................26 Authors Addresses ..............................................27 Qi-Bitar Expires September 2017 [ Page 3] Internet-Draft SDN Multicast Overlay March 2017 1. Introduction Operators that enable multicast services in their network have traditionally relied on host-based multicast protocols such as Internet Group Management Protocol (IGMP), and core-based multicast protocols such as Protocol Independent Multicast (PIM) with its variants, and more recently MPLS multicast protocols. Some operators have encountered issues with these protocols that have ensued from protocol activities, and perhaps implementation behavior under some scale, that overloaded the control plane of the routing nodes, sometimes effecting scalability, and often leading to network instability. There are four sources for this activity: (1) high dynamicity of group membership, resulting in a high rate of join/leave, (2) refresh of multicast soft state, (3) faulty implementation, and (4) malicious attacks. This document describes a framework for IP multicast based on the software-defined networking (SDN) paradigm. The objective of this framework is to allow an operator to flexibly design IP multicast networks to fit its needs, and minimize network risks. Specifically, it enables an operator to provide for multicast services in its network without PIM or MPLS multicast signaling protocols (i.e., point to multipoint Resource Reservation protocol - Traffic Engineering (RSVP-TE), or Multicast Label Distribution Protocol (MLDP)). The elimination of these protocols from network elements alleviates a good amount of control plane activity often consumed by these protocols to establish and maintain multicast soft sate, minimizing network stability risks and providing for better scale. The SDN control plane described in this framework, provides for (1) processing join and leave requests from receivers (e.g., IGMP, PIM) or applications that request the addition or pruning of receivers, (2) multicast entitlement and bandwidth admission control, (3) the computation of a multicast path if necessary, and (4) the establishment of the necessary forwarding states in the nodes on the computed forwarding path. 2. Terminology This document adopts the following SDN terminology from RFC7426 (SDN: Layers and Architecture Terminology): Qi-Bitar Expires September 2017 [ Page 4] Internet-Draft SDN Multicast Overlay March 2017 - Software-Defined Networking (SDN): A programmable network approach that supports the separation of control and forwarding planes via standardized interfaces. - Forwarding Plane (FP): The collection of resources across all network devices responsible for forwarding traffic. - Control Plane (CP): The collection of functions responsible for controlling one or more network devices. CP instructs network devices with respect to how to process and forward packets. The control plane interacts primarily with the forwarding plane and, to a lesser extent, with the operational plane. Furthermore, this document adopts the following terminology from RFC 7365, Framework for Data Center (DC) Network Virtualization: Tenant: The customer using a virtual network and any associated resources (e.g., compute, storage, and network). A tenant could be an enterprise or a department/organization within an enterprise. Tenant System: A physical or virtual system that can play the role of a host or a forwarding element such as a router, switch, firewall, etc. It belongs to a single tenant and connects to one or more virtual networks (VNs) of that tenant. 3. Acronyms ASM: Any-Source Multicast MSN: Multicast Service Node MSE: Multicast Service Edge MBG: Multicast Border Gateway SSM: Source-Specific Multicast TES: Tenant End System VM: Virtual Machine Qi-Bitar Expires September 2017 [ Page 5] Internet-Draft SDN Multicast Overlay March 2017 VN: Virtual Network VXLAN: Virtual eXtensible LAN DC: Datacenter 4. Problem Statement IP multicast in core IP networks has prevailingly relied on PIM-ASM to establish a multicast tree between the first hop router connected to a sender and the edge routers connected to receivers, and relied on multicast source discovery protocols to discover multicast sources. PIM is a soft state protocol that relies on periodic join refreshes to keep the multicast states alive and its mode of forwarding requires data-driven events. While PIM-SSM removed some of the above issues for PIM-ASM, it is IGMPv3 dependent and requires out-of-band source discovery mechanism. MPLS multicast signaling protocols, namely point to multipoint RSVP-TE, imposes similar control load on MPLS routers. On access links, edge routers process IGMP messages from attached receivers or CPEs, or PIM messages from attached CPEs. These messages signal to edge routers the multicast membership state of the attached devices. IGMP is also soft state, requiring periodic refreshes of join/prune messages to refresh multicast membership state, or queries to clean up stale state. Multicast group activity (joining/leaving a multicast group) could be very dynamic, resulting in a high control message rate that increases with the number of multicast receivers, and is highly dependent on the behavior of these receivers in leaving/joining multicast groups. All this control plane activity is performed on (all) nodes in the network to support multicast, risking network control plane scale and stability. Routers not only run multicast control protocols, but also perform data plane multicast, holding multicast forwarding state and performing packet replication and forwarding. Multicast forwarding state is dependent on the number of multicast groups ((*,G) or (S,G)) and number of outgoing interfaces per multicast group. As receivers join or leave multicast groups, these multicast forwarding entries need to be updated, further adding to a router control plane load. A Qi-Bitar Expires September 2017 [ Page 6] Internet-Draft SDN Multicast Overlay March 2017 large number of (*,G)/(S, G) multicast states and control information push against the resource limit of network routing hardware (e.g., TCAM, CPU). On an edge node where the number of outgoing interfaces could be very large, this activity is further exacerbated. In addition, data replication shares forwarding capacity (processing cycles and bandwidth) with unicast, often mandating the need to control the capacity allocated for multicast and enforcing it. Native multicast protocol procedures do not address the protection of a router control plane and data plane resources from the negative impacts that multicast enablement may have on these resources. Such negative impacts could be the result of malicious activities, misconfigurations, or simply lack of control on legitimate activities. For instance, a receiver may maliciously join a large number of multicast groups and create shared bandwidth bottlenecks if allowed to successfully join these groups. Such a receiver may also generate IGMP reports at a very high frequency, creating an attack on the access router control plane if not properly controlled. A host may also masquerade itself as a source for many multicast groups, resulting in the creation of a large number of forwarding state on the access router and other core nodes. Some router vendors have implemented mechanisms to protect against such attacks (malicious or not) on the router control and data plane, but often these mechanisms are not implemented, partially implemented or not implemented with a consistent behavior let alone configuration as they are vendor proprietary. Lack of consistency poses challenges to network operators when multicast is to be enabled in a multi-vendor environment. Without some type of entitlement that could be defined and uniformly enforced across all edge routers, a rogue multicast sender that knows active multicast groups can send traffic to these groups. The same goes for multicast receivers who may snoop on multicast traffic that they are not entitled to by simply joining the corresponding multicast group(s). Thus, there is a need to define and enforce entitlement for receivers to join multicast groups and for senders to be able to send traffic to multicast groups to protect against the negative impacts that sender and receiver misconfigurations or malicious activities could inflict. Qi-Bitar Expires September 2017 [ Page 7] Internet-Draft SDN Multicast Overlay March 2017 There is need to (1) protect against multicast control plane message attacks that may or may not result in a receiver successfully joining a multicast group, (2) be able to define and enforce entitlement for both receivers of and senders to multicast groups, and (3) to protect against the oversubscription of resources beyond set engineering targets by performing resource (bandwidth and other resources) admission control. Multicast entitlement, admission control and control DDoS protection are hard to implement in existing networks when relying on router vendor implementations as they do not holistically or uniformly address all needs, if any. Finally, there is no multicast management plane or north- bound interface to harness multicast control state and telemetry information that enable monitoring the state of the network and enable controlling the usage of network resources. 5. Multicast SDN Framework Benefits The multicast SDN framework is composed of an overlay control plane that computes multicast distribution paths between senders and receivers per multicast group/channel, and establishes the forwarding path on forwarding elements, enabling the distribution of multicast traffic between these senders and receivers, and provides for increased functionality and flexibility. The multicast overlay control plane on centralized multicast SDN controller(s) alleviates the multicast control plane activities performed by routing nodes in traditional networks. The controller could be an existing controller with multicast capability or a separate multicast controller. The multicast SDN framework provides the following benefits: - By alleviating multicast control protocols and associated processing and states off the distributed traditional routing nodes in a network, the routing control plane of these nodes will have an order of magnitude reduction in complexity and a significant reduction in processing load, Qi-Bitar Expires September 2017 [ Page 8] Internet-Draft SDN Multicast Overlay March 2017 improving network stability and scalability and faster time to recovery from failures. - Much fine grained policy and advanced service enhancements such as multicast control policy (access control, admission control, entitlements and bandwidth), can be implemented directly and consistently in the SDN multicast control plane. This functionality can be and has been implemented in traditional routers but at the expense of additional processing requirements on the control plane and the burden of ensuring consistent implementation across various vendors. - Much fine grained multicast path selection based on various attributes (e.g., bandwidth, diversity, latency) and programming, and various degree of replication, alleviating the current congruency between multicast and unicast topologies and providing flexibility in carving multicast paths for multicast groups and receivers. - Multicasting across Campus, Datacenter, Wide Area Network, and multiple administrative boundaries under the same enterprise control can be implemented with a unified and integrated Management Plane and Control Plane. - Multicasting across administrative boundaries under the control of different enterprises/operators, can be implemented leveraging SDN mechanisms and/or traditional distributed control mechanisms, depending on the capabilities of the neighboring enterprise/operator domains. - Control and/or management plane applications can compute, modify, steer, and program forwarding plane multicast paths, and query and harness state information from the routing nodes performing multicast forwarding using north bound interfaces from these nodes. - Flexible design of the multicast services in the operator network to address operator design principles and the capabilities of the forwarding elements. Qi-Bitar Expires September 2017 [ Page 9] Internet-Draft SDN Multicast Overlay March 2017 - Agnosticism to whether an endpoint, multicast receiver or sender, is a VM, container, or a physical host as they all use the same overlay multicast service mechanisms. - Applications can steer multicast path, query and harness state information from SDN multicast overlays using northbound interfaces. 6. Multicast SDN Framework Guiding Principles and Requirements Following are the requirements that MUST be satisfied by the Multicast SDN framework: - No constraint on the network topology. The SDN framework will need to be aware of the unicast and multicast network topology when it needs to compute unicast and multicast paths that satisfy certain constrains and/or to optimize for network usage resources on these paths. - No constraint on the unicast routing protocol selection in the underlay network. The network may consist of multiple domains with different unicast routing protocols. - Be agnostic to other services in the network (e.g., BGMP/MPLS unicast and multicast Layer2 and Layer3 services, other types of VPN services). That is, it MUST allow new multicast services to be enabled based on this framework in the presence of other services. - Support IPv4, IPv6, and MPLS unicast underlay data plane, providing for edge replication over IPv4, IPv6,or MPLS unicast overlays. - Support IPv4, IPv6, and MPLS multicast data planes, providing for replication over IPv4, IPv6, and MPLS multicast overlays, and for the computation and programmability of the overlay data paths on the underlay as needed. Qi-Bitar Expires September 2017 [ Page 10] Internet-Draft SDN Multicast Overlay March 2017 - Support a BIER [BIER-ARCH] underlay data plane to support multicast replication of multicast packets over BIER type of multicast overlays. - Support a segment-routing (SR) [SR-ARCH] underlay data plane to support edge replication of multicast packets over unicast SR overlays with both IP and MPLS data planes. - Support stitching of multicast packets across domains with the different control and data planes stated in the earlier requirements. - Integrate with network multicast (control and data plane) where operationally feasible resulting in optimum bandwidth utilization in data plane. - Enable decoupling of multicast topology from unicast topology, providing the ability to enable multicast selectively on nodes, and/or carving multicast paths. - Enable select edge data replication nodes, specifically when the first hop router connected to the Multicast sender is not best suited for data replication. - Support existing multicast applications without requiring any modification to these applications, e.g., applications that use IGMP for multicast membership - Support the tunable aggregation of multicast groups on multicast tunnels (where tunnels may be stateful tunnels, or simply encapsulation headers) - Enabling operators to traded-off multicast data plane bandwidth efficiency with multicast data plane and control plane state Qi-Bitar Expires September 2017 [ Page 11] Internet-Draft SDN Multicast Overlay March 2017 - Support multicast admission control on unicast tunnels/paths, multicast tunnels, and path (re-) computation on the underlay. - Support multicast admission control based on entitlement of the receiver to a multicast group or channel - Support programmability of multicast traffic policers and filter policies 7. Multicast SDN Framework Architectural Components Multicast Service Edge (MSE): An MSE connects to tenant end systems (TESs) (hosts) on the access side and to an underlay IP network or IP/MPLS network on the network side. In the forwarding plane, When an MSE receives a user IP multicast packet from a TES on the access side, it replicates the packet on local ports with TES receivers, and encapsulates the IP multicast packet in a unicast packet to a Multicast Service Node (MSN) or a Multicast Border Gateway (MBG) to reach remote multicast receivers. It also receives IP multicast packets encapsulated in unicast packets on the network side, decapsulates the multicast packets and replicates them on local ports to corresponding TES receivers. In the control plane, an MSE connects to a multicast controller that programs the MSE with multicast forwarding entries triggered by management entities or dynamic control protocols. An MSE may receive IGMP or Multicast Listener Discovery protocol (MLD) report/leave packets on the access side. The MSE acts as an IGMP/MLD proxy and sends messages to the multicast SDN controller to inform the controller of local multicast receivers for a multicast group or channel. It may also be statically programmed with multicast entries. An MSE supporting multi-tenancy provides for multicast control and forwarding in a tenant specific virtual routing and forwarding context. It can be implemented in hardware or software. For example, it can be part of a virtual router in a virtualized environment, a kernel or user-plane routing function in physical servers, a physical router, or appliance which performs multicast service functions. Qi-Bitar Expires September 2017 [ Page 12] Internet-Draft SDN Multicast Overlay March 2017 There are multiple ways an MSE can intercept multicast control messages and multicast data packets from TESs when the TESs are receivers and senders, respectively: - MSE is a multicast router on local VLAN - MSE is a designated multicast router for a LAN router. A LAN router (e.g., a Top of rack (ToR) router in a DC) forwards all multicast packets it receives to a designated MSE - MSE is part of virtual switch/router on a virtualized host - MSE is a kernel function and intercepts data frames - MSE resides in a NIC of the TES and intercepts all frames in and out of the NIC. - MSE is a customer edge (CE) router for a local site. Multicast Tunnel TES (MT-TES): An MT-TES is a tenant end system (host), virtual or physical, that may send or receive multicast packets encapsulated in unicast IP/UDP packets and delivers them to local applications based on the UDP port number in the encapsulating header or multicast destination address. Multicast Service Node (MSN): An MSN is the network entity that receives and replicates IP/Multicast packets from/to others MSNs, MBGs, MSEs and MT- TESs in the data plane. An MSN is often designated to serve an MSE with multicast receivers and senders, and/or MT-TESs. There could be more than one MSN serving the same MSE or the same MT- TES. In that case, the selection of the MSN can be based on whether the MSE or MT-TES is sending or receiving multicast packets to/from the network, and/or multicast group address or multicast channel based on the tuple multicast source (S) and multicast group address (G). An MSN may tunnel packets over the underlay network to other MSNs and MBGs using unicast tunnels/unicast header encapsulation, or may forward multicast packets natively on the underlay. An MSN always forwards multicast traffic encapsulated in unicast packets to MSEs and MT-TESs as programmed. On the network side, an MSN may participate in native IP multicast control and forwarding if so configured. The multicast controller MAY also program underlay multicast forwarding entries and the forwarding unicast entries that correspond to the unicast forwarding information in the encapsulating header of the packet carrying multicast packets on the MSN for policy-based routing and forwarding purposes. Alternatively, the unicast packets, encapsulating the multicast Qi-Bitar Expires September 2017 [ Page 13] Internet-Draft SDN Multicast Overlay March 2017 packets, can be forwarded based on underlay dynamic unicast routing, the default behavior. Unlike MSE, MSN does not connect to access networks or TESs. MSN can optimize replication based on latency, bandwidth, QoS, number of multicast states desired or even more specific multicast application requirements. MSN can be implemented in hardware or software. For example, it can be a physical router, or a software appliance which performs multicast service functions. Each MSN has a forwarding plane and a control plane, albeit new control plane functionality and traditional control plane functionality implemented today are relegated to an SDN multicast controller. Multicast SDN Domain (MSD): A multicast SDN domain encompasses forwarding nodes (MSEs, MSNs, and MBGs) and a cluster of one or more multicast SDN controllers that control the programming of tenant multicast forwarding entries on these nodes in addition to underlay core nodes that provide for IP connectivity among these nodes. Multicast Border Gateway (MBG): An MBG is a network forwarding node that sits at the border of a multicast SDN domain and connects to other networks in different domains, which could be either multicast SDN domains or traditional networks with multicast capabilities in the same or different administrative domains. An MBG forwards multicast packets from one domain to another across the boundary and forwards packets to MSNs within its domain. An MBG could also implement MSN functionality, serving MSEs and MT-TESs. As an example, in cloud networking whereby the cloud is composed of multiple data centers (DCs), an MBG may perform the function of a DC multicast gateway to the WAN to provide for the forwarding of multicast traffic originated by one TES in one DC to TESs located in other DCs. In this case, the MBG may use BGP/MPLS Multicast VPN (BGP-MVPN) [RFC 6513] across the WAN. Inside a domain, an MBG may be enabled with traditional IP multicast control and forwarding on the network underlay links to perform underlay multicast forwarding. Alternatively, underlay multicast forwarding entries reachable within the domain may be programmed by the corresponding multicast SDN control plane. Overlay traffic may be tunneled to/from the MBG using unicast tunnels/unicast-header encapsulation or multicast tunnels/multicast header encapsulation. An MBG can be implemented in hardware or software. For example, it can be a physical router, or a software appliance which performs multicast service functions albeit new control plane Qi-Bitar Expires September 2017 [ Page 14] Internet-Draft SDN Multicast Overlay March 2017 functionality and traditional control plane functional implemented today are relegated to an SDN multicast controller. Core Node (CN): A CN is a routing node which provides the underlay interconnectivity among the MSEs, MSNs and MBGs. It provides for unicast IP, MPLS, and SR forwarding and may provide multicast IP, MPLS and/or BIER forwarding. 8. SDN Multicast Framework Figure 1 depicts the SDN multicast framework, specifically the SDN management plane, control plane and data plane functional elements and their interactions. In the full SDN model, control of any data plane element for multicast is under the control of the Multicast SDN control plane. Variants of this model that leverage existing solutions (e.g., BGP-MVPN) are described in this document to fit different deployment models. +------------------------------------+ | | | Management/Application | | | +------------------------------------+ ^ |MApp-C | +-----------------------------------------------+ | | | Multicast SDN Control | | | +-----------------------------------------------+ ^ ^ ^ ^ ^ ^ |MSE-C |MSN-C |MBG-C |MC-C |MSN-C |MTTES-C | | | | | | | | | | | | +----+ +---+ +---+ | +---+ +---+ ( ) +-------+ | TES|---|MSE|----|MSN|----|----| CN|----|MSN|-( )--| MT-TES| +----+ +---+ +---+ | +---+ +---+ ( ) +-------+ IGMP | MLD | +---+ +--|MBG|--+ | +---+ | Qi-Bitar Expires September 2017 [ Page 15] Internet-Draft SDN Multicast Overlay March 2017 | | | | | Network | | | . | | . \+-------+/ | MBG | +-------+ 8.1. SDN Multicast Operational Models 8.1.1. Full Multicast SDN Model Operational Overview This section provides an overview of the full SDN multicast model and describes the transactions and information that needs to be exchanged across the different interfaces, including the interfaces between the multicast SDN controller and the various multicast nodes (MSE, MSN, CN, MBG). Throughout this section it should be assumed that all multicast operations on any of the edge nodes are done in a tenant context. In the case of multi-tenancy, MSEs, MSNs and MBGs must be able to perform destination lookup and forwarding in a virtual routing and forwarding (VRF) context. In addition, they must be able to encapsulate the original multicast packet with a unicast (tunnel) header and additional header information that carries a tenant identifier that can be used to identify the forwarding context at the receiving end. Senders and receivers for a multicast group may be static or dynamic. For each tenant and multicast group, the SDN multicast controller is informed of the sender(s) via the controller northbound management interface (MApp-C) or the MSE connected to the sender(s) via the MSE-C interface. The SDN controller, in the generic case, will select an MSN that will proxy the MSE connected to the sender, and programs the MSE to send the multicast group traffic it receives from the sender(s) to the selected MSN. The SDN controller may select more than one such MSN. The multicast group packets will be delivered to tenant end systems served by other MSEs and MSNs from these selected MSNs. For static TES multicast receivers on a particular group or channel, the SDN controller knows which TESs are members of a multicast group/channel via the MApp-C management interface, and learns the MSE serving the TES via the MApp-C management interface or via dynamic routing. Then for each TES on that multicast group, The SDN controller selects the MSN to serve the corresponding MSE. This selection could be based on certain Qi-Bitar Expires September 2017 [ Page 16] Internet-Draft SDN Multicast Overlay March 2017 criteria that optimize for bandwidth utilization on the path between the MSN and the MSE, and/or resource utilization on the MSN among others. Once an MSN selection is done to serve the MSE, the SDN multicast controller needs to ensure that the selected MSN receives the multicast group/channel traffic. The SDN controller then selects the remote MSN from which it wants to receive the multicast group packets. This latter selection could be based on bandwidth utilization on the path between the two MSNs in question, remote MSN resources, and/or the transport method (multicast or unicast tunnel/tunneling encapsulation). In the case of unicast transport, the remote MSN proxying the sender MSE is programmed via the MSN-C interface with a forwarding entry that results in encapsulating the multicast group packets with a unicast SR, IP or MPLS tunnel or encapsulation header that delivers the packets to the MSN serving the receiver MSE. The MSN serving the receiver MSE is also programmed with an entry that results in forwarding the received multicast packet over another tunnel encapsulation to the destination MSE. Optionally, the MSN serving the receiver MSE may be programmed with the tunnel/encapsulation header information over which the multicast group packets will be delivered (i.e., the sender MSN IP address or MPLS tunnel). Unicast forwarding is based on dynamic routing information, static (policy-based) routing or MPLS signaling in the case of RSVP-TE. In the case of multicast transport, the SDN controller may choose to add a new multicast tree branch to an existing multicast tree or re-compute a new one rooted at the sender. In the case of IP multicast transport, and in the absence of PIM in the core, the SDN controller programs the CNs on the path with the appropriate multicast forwarding entries. The MSE could also optionally be programmed with the tunnel/header encapsulation information over which packets are to be received. For dynamic receivers, a TES may initiate an IGMP report or MLD join message for a multicast group. That message should be received by the MSE. The MSE may act as an IGMP proxy/MLD proxy in which case the MSE, upon receiving the first join message from a connected TES for a multicast group/channel, sends a join message for that multicast group/channel with tenant context to the SDN controller over the MSE-C interface. In case there is requirement for entitlement or bandwidth admission control, the MSE always sends a message to the SDN controller over the MSE-C interface, requesting admission control for the requesting TES for the particular group/channel, including the tenant context. If the request is admitted, the MSE is informed of the admission decision and the transport path setup proceeds as described for the static Qi-Bitar Expires September 2017 [ Page 17] Internet-Draft SDN Multicast Overlay March 2017 receiver case. In the proxy case, when the last receiver leaves a multicast group on the MSE either via an explicit leave, failure to respond to a query or failing, the MSE sends a message to the SDN controller that it no longer has receivers for that group/channel via the MSE-C interface, and the controller may remove the MSN as being a receiver for that group/channel and take appropriate action removing associated forwarding state on other nodes (MSNs, CNs). 8.1.2. Hybrid Distributed-SDN Multicast Model Operational Overview In this model, MSNs and MBGs perform the role of an BGP-MVPN PE with a distributed BGP-MPLS control plane for exchanging receiver information in a tenant network (MVPN) with other MSNs and MBGs. The programmability of the MSNs with the receiver information is done via the SDN controller to create the relevant BGP policies and enable tunneling of multicast traffic to served MSEs. 8.1.3. Cut-Through Operational Mode In the cut-through model, a sender MSE can send multicast packets directly to remote receiver MSE(s), bypassing MSNs and MBGs. That is, MSNs do not proxy for downstream MSEs. In this case, the multicast SDN controller programs a sender MSE via the MSE-C interface with a forwarding entry that results in encapsulating the multicast group packets received at the MSE from the access network with a unicast IP header and a tenant identifier that delivers these packets to remote receiver MSE(s). The receiver MSE is also programmed with an entry that results in forwarding the received multicast packet to downstream multicast receivers. Similarly, Sender MSE can send multicast packets directly to receiver MT-TESs with the same operational procedures. It should be noted that upon operator configuration, a multicast deployment MAY include one or more of the operational models described in the SDN multicast framework section. Qi-Bitar Expires September 2017 [ Page 18] Internet-Draft SDN Multicast Overlay March 2017 8.2. SDN Multicast Overlay Control Plane Functionalities Multicast control is traditionally distributed on network routing elements, and mainly responsible for building and maintaining multicast distribution trees or transport, and configuring the multicast forwarding plane. Control Plane entities may exchange multicast sender or receiver-membership information with each other using network protocols such as MP- BGP or PIM. The full multicast SDN model described in this document alleviates the distributed control plane functions from network elements but preserves the functionalities needed to discover multicast membership and source information, build multicast distribution trees and/or multicast transport tunnels. The SDN Multicast Control plane in the full multicast SDN model Must include the following functionalities: - Unicast topology discovery interconnecting MSEs, MBGs, MSNs and CNs - Multicast topology discovery including MSEs, MSNs, MBGs, and CNs enabled for multicast - Resource utilization monitoring on links and nodes - Multicast group membership discovery and maintenance - Multicast source discovery and maintenance - Multicast distribution tree creation and maintenance - Multicast path selection, instantiation, maintenance and failover - Multicast forwarding programmability The SDN Multicast control plane SHOULD include the following functionalities - Entitlement admission control - Bandwidth Admission control 8.2.1. Unicast Topology Discovery The unicast Topology is needed to discover reachability among MSEs, MSNs and MBGs for MSN selection or MBG selection. In addition, the unicast topology will be needed if traffic is to be carried using any unicast tunneling technology (IP, MPLS, SR with IP or MPLS data planes), or pt-to-pt RSVP-TE. In this Qi-Bitar Expires September 2017 [ Page 19] Internet-Draft SDN Multicast Overlay March 2017 latter case the TE tunnels may be computed by the underlying router. Alternatively, the TE tunnels paths MAY be computed by the SDN controller. The same may apply for Traffic engineered SR paths. The SDN control plane SHOULD always maintain a database of these TE tunnels/paths and associated capacity, irrespective how they are computed, enabling the SDN controller to selectively bind multicast traffic to TE paths. The SDN multicast control plane and network elements that will be used to learn the unicast topology SHOULD support BGP-LS [RFC 7752] or YANG topology data models [Yang-Topology-Model]. The SDN control plane SHOULD learn the unicast topology via BGP-LS or YANG from the network nodes. The SDN controller MUST also learn TES reachability via MSEs using same mechanisms. 8.2.2. Multicast Topology Discovery The SDN multicast control plane MUST have knowledge of all the MSNs, MBGs and MSEs and their multicast resources. In case the core network is also enabled for multicast and the SDN control plane is to compute multicast trees, the SDN control plane MUST know which nodes are enabled for multicast forwarding and enabled for PIM. The Multicast topology is used by the multicast SDN control plane to select MSNs and MBGs and to compute multicast tree paths. The multicast tree could be based on native IP multicast or pt-to-mpt RSVP-TE. The SDN multicast control plane MUST maintain the computed paths and the receivers and senders mapped to them. 8.2.3. Resource Utilization Monitoring The SDN control plane MUST maintain knowledge of the available resources on the nodes that may be impacted resource-wise by being on multicast paths selected by the SDN controller. For instance, the SDN controller MUST maintain the available resources for multicast forwarding entries on MSEs, MSNs and MBGs. In addition, if bandwidth and link utilization is to be considered as part of the path selection, the SDN controller MUST maintain knowledge of the utilization on network links. 8.2.4. Multicast Group Membership Discovery The SDN Controller MUST learns via the MApp-C management interfaces or the MSE-C/MTTES-C interfaces the receivers and senders for each multicast group or channel. Qi-Bitar Expires September 2017 [ Page 20] Internet-Draft SDN Multicast Overlay March 2017 When the list of multicast receivers and senders for each multicast group in a tenant network is known in advance and when multicast session establishment (set of senders and receivers for a multicast group) can be set up ahead of time of actual multicast data delivery, applications can use the multicast SDN controller northbound interface (MApp-C) to populate the list of receivers and senders for the multicast group in the SDN controller. The SDN controller may also have access to a database, or be programmed with information via MApp-C, that associates the receivers and senders with MSEs. 8.2.5. Multicast Sender Discovery The multicast SDN controller MUST learn the set of senders for each multicast group. This information May be learned via the MSE-C/MTTES-C interfaces from MSEs or TESs, or via the MApp-C interface from a management application. The SDN controller could obtain the location of the sender (which MSE a sender is connected to) from routing information, or via MApp-C and MSE-C interfaces. 8.2.6. Multicast Distribution Tree Creation and Maintenance The SDN controller MUST be able to compute a multicast distribution tree. There could be several segments for a multicast distribution tree depending on the capabilities of the network elements, and/or the operator design. Following are the distribution tree types: 1- Distribution Tree Type 1: The distribution tree is rooted at one MSN that receives a multicast group source traffic from an MSE. Then, that MSN encapsulates the multicast traffic with a unicast tunneling header to other MSNs connected to MSEs with receiver TESs for that group, and to other MBGs to reach TES receivers in other domains. 2- Distribution Tree Type 2: The distribution Tree is rooted at one MSN that receives a multicast group source traffic from an MSE. Then, the MSN encapsulates the traffic with a multicast tunneling header or in a multicast tunnel with leaves being other MSNs and MBGs to reach receivers. When an MSN receives the tenant multicast traffic on a multicast tunnel/encapsulated in a multicast tunneling header, it decapsulates the tenant multicast packets and unicast tunnel them to the MSEs with receiver TESs for that group. Qi-Bitar Expires September 2017 [ Page 21] Internet-Draft SDN Multicast Overlay March 2017 In computing the multicast tree, the SDN controller SHOULD take into account constraints on bandwidth and other QoS parameters such as latency, jitter and packet loss in addition to the capabilities of the forwarding plane elements (e.g., native multicast replication support, multicast replication over unicast tunnels, number of multicast entries, bandwidth, etc.) and policies (e.g., which MSN is to serve which MSE, inter-SDN domain policies etc.). A multicast distribution tree is recomputed every time that there is a new edge node (MSE, MSN or MBG) to be added to the multicast tree, or there is an edge node that needs to be pruned out of the multicast tree), adding or removing multicast branches to/from the tree. An SDN multicast controller can map tenant overlay multicast group addresses 1:1 to distinct multicast group addresses in native IP multicast underlay, and program MSNs and MBGs with the appropriate forwarding information. An SDN multicast controller can alternatively map each designated set of tenant overlay multicast group addresses to a unique underlay multicast IP address and accordingly program MSNs and MBGs with the appropriate forwarding information. In this latter case, these tenant overlay multicast groups are aggregated into distinct multicast group address(es) similar to mechanisms in Default or Data MDTs (Multicast Distribution Trees) [RFC 6037]. This aggregation technique can help minimize multicast routing states in native multicast network. 8.2.7. Multicast Forwarding Programmability Subsequent to the (re-) computation of the multicast tree, the SDN multicast controller MUST be able to program the multicast forwarding entries on the forwarding elements: MSE, MSN and MBG. When supporting dynamic receivers and senders, multicast tree (re-)computation and programmability must be done relatively fast so that it does not impact the user experience, creating a significant delay in starting to receive a multicast channel that the user joins. In other cases, multicast receiver applications may also have a requirement on the latency between sending a join to a multicast channel and starting to receive data on that channel. Among other things, forwarding programmability SHOULD enable setting the TTL treatment behavior. Specifically, an ingress MBG SHOULD be configurable Qi-Bitar Expires September 2017 [ Page 22] Internet-Draft SDN Multicast Overlay March 2017 not to copy the Time to Live (TTL) field from SDN overlay multicast packets. Operators should take account of the end-to-end network topology and set the TTL field accordingly. 8.2.8. Entitlement Admission Control When this function is enabled for a given tenant, the SDN multicast controller checks if the requesting receiver is entitled to receive the content of the multicast group/channel it is requesting to join. The SDN controller MAY be programmed with the list of receivers that are allowed to receive traffic from certain source(s), and whereby the receivers may be identified by IP host addresses, IP subnets or other types of identifiers. This entitlement information can be configured on the controller or it may be available through some database or system that has that information. 8.2.9. Bandwidth Admission Control Bandwidth admission control prevents content or subscription overload from senders or receivers as well as provides important security protection by putting upper limits on how much traffic each sender or receiver can send or subscribe to. When this function is enabled, the SDN multicast controller may perform bandwidth admission control when permitting a channel to be delivered to a TES and/or when selecting the multicast channel path. The specification of bandwidth admission control mechanisms is beyond the scope of this framework. 8.3. Multicast Functional Components Implementation MSE, MSN and MBG are functional components that may be co- located on the same router and implemented in different forms (physical, virtual, or applications). For example, MSEs and MSNs can co-locate together in the same physical or virtual router. Qi-Bitar Expires September 2017 [ Page 23] Internet-Draft SDN Multicast Overlay March 2017 8.4. SDN Multicast Management Interfaces 8.4.1. North-Bound Interface MApp-C is a northbound interface from the SDN controller that provides management applications the means to interact with the SDN controller to set and extract multicast configurations and information, respectively. It is independent of individual network devices, vendors or device types. MApp-C interface SHOULD provide a comprehensive and flexible data model and messaging methods that allow these applications to access Multicast SDN Controllers to request the addition or removal of a receiver to a multicast (S,G) channel, the establishment of a multicast distribution tree between specified senders and receivers with potential constraints on bandwidth and QoS for instance, set entitlement rules, and obtain state information pertinent to a multicast group or participants in that multicast group among others. Applications SHOULD have a means to perform these actions across MSDs, each with an SDN controller, with one action rather than separate actions initiated with each of the MSD controllers. 8.4.2. Multicast SDN Functional Component Facing Interfaces MTTES-C, MSE-C, MSN-C, MBG-C are interfaces between a Multicast SDN Controller on one hand and TESs and Multicast SDN forwarding functional components on the other hand. Each interface is specific to the associated functional component, and is used to provide control plane and/or data plane programming of that component and to harness information from that component. 8.4.3. Traditional Underlay Network Element Interfaces CN-C is the interface between Multicast SDN controller and core network elements that provide core forwarding services, as opposed to edge services provided by MSE, MSN and MBG. The purpose of CN-C is to provide for programming of network elements in the core whenever it is possible or necessary, and to extract operational state information from these elements. Qi-Bitar Expires September 2017 [ Page 24] Internet-Draft SDN Multicast Overlay March 2017 8.4.4. Information Model and Data Model of Management Interfaces Both northbound interface and SDN functional component facing interfaces SHOULD be based on RESTCONF [RESTCONF] or NETCONF [RFC6241]. Their data models should be based on YANG. 9. SDN Control Plane The SDN Control plane can be composed of one or more controllers. These controllers will need to cooperate in the establishment of a multicast distribution tree within MSDs and across MSDs. How they cooperate or interact is dependent on the relationship relative to MSDs, ASes, and administrative entities (operators). In this section, the following cases are considered: 1- Intra-MSD, Inter-SDN Controller Interactions 2- Inter-MSD, Intra-AS, Inter-SDN Controller Interactions 3- Inter-MSD, Inter-AS, Intra-operator, Inter-SDN Controller Interactions 4- Inter-MSD, Inter-AS, Inter-operator, Inter-SDN Controller Interactions (this section will be completed in a future update). 10. Multi-Party Multicast SDN Overlay Interaction If multicast senders and receivers are on different multicast SDN overlay vendor solutions, it SHOULD be possible to setup and exchange multicast control states as well as underlying tunneling information. 11. Security Considerations Following are the security considerations that pertain to the multicast SDN framework in this document: 1- The communication channel between any data element and the SDN controller MUST be trusted and secure, with mutual authentication. This applies to all interfaces (MSE-C, MSN-C, CN-C, MTTES-C and MBG-C) in order is to prevent rogue controllers from hijacking multicast traffic, mounting Qi-Bitar Expires September 2017 [ Page 25] Internet-Draft SDN Multicast Overlay March 2017 security attacks on network elements or leaking tenant multicast traffic to other tenants. 2- MSE must have means to cope with tenant end systems misbehavior, malicious or malfunctioning, that may result in control plane attack on the SDN controller, impacting the stability of the system and as a result impacting multicast services. The MSE MUST be able to limit the message rate that could be triggered by tenant end system activity, and the controller MUST be able to limit message rate and routing activity changes at the tenant level as that could result in a DDOS on the multicast services across tenants. 3- The association between a TES and tenant network must be authentic so that traffic eavesdropping is prevented and a TES is not allowed to illegally inject multicast traffic into another tenant network. 4- The SDN controller SHOULD have the means to authorize a TES to join a multicast channel (entitlement). 5- The SDN controller SHOULD have the means to exercise admission control to avoid congestion on network links as causing congestion could be a way to launch a DDOS. 12. IANA Considerations The document does not require any IANA action. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. 13.2. Informative References [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [EDGE-REP] Marques P. et al., "Edge multicast replication for BGP IP VPNs", draft-marques-l3vpn-mcast-edge-01, work in progress, June 2012. Qi-Bitar Expires September 2017 [ Page 26] Internet-Draft SDN Multicast Overlay March 2017 [RFC 6037] E. Rosen, Y. Cai, I. Wijnands, "Cisco Systems Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037. October 2010. [RFC 6513] E. Rosen E., et al. , "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [IGMP-EVPN] A. Sajassi, et al., "IGMP and MLD Proxy for EVPN", draft-sajassi-bess-evpn-igmp-mld-proxy-00, October 17, 2015. [RFC 7716] Z. Zhang, L. Giuliano, E. Rosen, et al., "Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures", RFC 7716, December 2015. [BIER-ARCH] IJ. Wijnands, et al. "Multicast using Bit Index Explicit Replication", draft-ietf-bier-architecture-04, July 18, 2016. [SR-ARCH] C. Filsfils, et al, "Segment Routing Architecture", draft-ietf-spring-segment-routing-11, February 16, 2017. [Yang-Topology-Model] A. Clemm, e al., "A Data Model for Network Topologies", draft-ietf-i2rs-yang-network-topo-12, March 1, 2017. [RFC 7752] H. Greedier, et al., "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, March 2016. [RFC 6241] R. Enns, et al., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RESTCONF] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-17, September 28, 2016. [NVO3-MCAST] A. Ghanwani, et al., "A Framework for Multicast in Network Virtualization Overlays", draft-ietf-nvo3-mcast- framework-05, May 9, 2016. Authors Addresses David Qi Bloomberg EMail: dqi@bloomberg.net Nabil Bitar Nokia EMail: nabil.bitar@nokia.com Truman Boyes Bloomberg EMail: tboyes@bloomberg.net Qi-Bitar Expires September 2017 [ Page 27] Internet-Draft SDN Multicast Overlay March 2017 Senad Palislamovic Nokia EMail: senad.palislamovic@nokia.com Anil Lohiya Juniper EMail: alohiya@juniper.net Qi-Bitar Expires September 2017 [ Page 28]