Patent Description:
The present disclosure relates generally to communicating local sources and network capability information to external networks to automatically configure and connect multicast networks managed by separate network controllers.

Cloud computing provides users with access to computing resources to fulfill users' computing resource needs. In some examples, service providers can manage and provide cloud computing resources to users to fulfill their needs without the users having to invest in and maintain their own computing infrastructure. Cloud computing often involves the use of networks of data centers which house servers, routers, and other devices that provide computing resources to users such as compute resources, networking resources, storage resources, database resources, application resources, and so forth. Users may be allocated portions of computing resources across a number of networks using virtualization technology. The virtualized portions, or virtualized networks, of the computing networks may be utilized to allow a host (or "source node") to transmit data to a single host (or "destination node"), to all hosts, or to a subset of all hosts as a group transmission, also referred to as a multicast group transmission. For example, a corporation can utilize the virtualized network of computing resources to host a video conference, where data is broadcast from a source to recipients of a respective multicast group.

To support a multicast data transmission using cloud computing, a network controller may be utilized to automate configuration, connection, and operations of the computing resources across physical servers in a cloud computing network. To effectively route the data transmission from a source node to various destination nodes of a group, the network controller may track what resources have been placed on what physical servers in order to determine a topology of a network and route data efficiently. For example, a controller may determine that a new destination node has been disposed in the network and may maintain an address and/or operating attributes associated with the destination node. The controller may then identify a multicast group the destination node desires to join. The controller may then configure a route to transmit the data from the source node to the destination node. However, transmission of data from a source node, in a first network where the controller is disposed, to a destination node, disposed in a second network having a separate controller, may lead to difficulties when broadcasting a multicast data transmission to a group of destination nodes disposed across the multiple networks.

To effectively manage a multicast group of destination nodes across multiple networks, the controller of a first network having a source node must be aware of all of the destination nodes in order to configure a path for the data transmission. When a destination node is disposed in a second network that is separate from the first network, the controller of the first network has no knowledge of the destination node disposed in the second network. Additionally, the controller of the second network has no knowledge of the source node disposed in the first network. While utilizing a network controller to manage a multicast group of destination nodes and configure a data transmission route from a source node to the destination nodes is effective in a single network for various reasons, configuring a data transmission route from a source node to destination nodes in the same multicast group but located in different networks suffers from various limitations.

<CIT> discloses a packet based software defined network supporting multicast.

This disclosure describes a method of utilizing Software-Defined-Network (SDN) controllers and network border leaf switches of cloud computing networks to send, receive, and store in respective virtual memory, a table of external sources to configure a data transmission route for a multicast group. The method includes receiving, at an SDN controller in a first network, a request from a source node to coordinate a data transmission to a multicast group of destination nodes. The source node may be disposed in the first network. The method may further include determining, at the SDN controller, that at least one destination node in the multicast group of destination nodes is in a second network that is separate from the first network. The method may further include identifying, at the SDN controller, a first border node in the first network communicatively coupled to a second border node in the second network. The method may further include sending, from the SDN controller and to the first border node, an advertisement message including an indication of an address of the source node, a group address associated with the multicast group of destination nodes, and network capability information associated with the first network. The method may further include causing, by the SDN controller, the first border node to send the advertisement message to the second border node.

Additionally, or altematively, the method includes receiving, at an SDN controller in a first network, a request from a destination node to join a multicast group of destination nodes receiving a data transmission. The destination node may be disposed in the first network. The method may further include sending, from the SDN controller and to a border node in the first network, a request to discover a source node associated with the multicast group of destination nodes. The method may further include receiving, at the SDN controller and from the border node, a discovery notification of the source node, disposed in a second network separate from the first network and associated with the multicast group of destination nodes. The discovery notification may include an indication of an address of the source node, a group address associated with the multicast group of destination nodes, and network capability information associated with the second network. The method may further include configuring, at the SDN controller, a route for the data transmission from the border node to the destination node based at least in part on the network capability information associated with the second network.

Additionally, or alternatively, the method includes receiving, at a first border node disposed in a first network and from a second border node disposed in a second network, an advertisement message. The advertisement message may include an indication of an address of a source node hosting a data transmission to a multicast group of destination nodes, a group address associated with the multicast group of destination nodes, and network capability information associated with the second network. The source node may be disposed in the second network. The method may further include storing, in a database associated with the first border node, the address of the source node, the group address, and the network capability information in association with the second border node. The method may further include receiving, at the first border node and from an SDN controller disposed in the first network, a request to discover the source node associated with the multicast group of destination nodes. The method may further include sending, from the first border node and to the SDN controller, a route configuration message including the address of the source node, the group address, and the network capability information.

Additionally, the techniques described herein may be performed by a system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the method described above.

Generally, a Software-Defined-Networking (SDN) controller is designed to control a network of devices in one or more datacenters and utilize protocols to instruct network switches, running on physical server(s) within a cloud computing network, where to send data within the cloud computing network. The cloud computing network may include one or more spine network switches. A spine network switch may be running on a virtual machine hosted on a physical server within the cloud computing network and may be in communication with one or more leaf network switches. A leaf network switch may be running on another physical server within the cloud computing network The SDN controller may be utilized to send data using various techniques, for example, allowing a source node to send data to a subset of destination nodes as a group transmission, also referred to as a multicast group transmission. The SDN controller may track when resources have been placed on physical servers, forming a node in the network, in order to determine a topology of the network. The SDN controller may also detect where source nodes and destination nodes associated with a multicast group are within the network. The SDN controller may configure the network to set up a path for a flow of data with guaranteed bandwidth.

In an example, an SDN controller may discover a topology of a first network that the SDN controller is disposed in. In some examples, the SDN controller may discover where each network element of the first network is and how they are linked. Once the SDN controller has determined a topology of the first network, the SDN controller may discover which network elements (or nodes) are configured as a source for a multicast data transmission, and which nodes are configured as a destination for the multicast data transmission. When the SDN controller has discovered the topology of the first network and has discovered the source nodes and destination nodes of a multicast group, the SDN controller may configure a route for the data transmission from the source node to each of the destination nodes of the multicast group. Additionally, or alternatively, the SDN controller may configure the route to ensure the data is being transmitted through a route with a guaranteed bandwidth. However, in some examples the multicast group includes a destination node disposed in a second network. While the SDN controller of the first network has the ability to determine the topology of the first network in which it is disposed, the SDN controller does not know the topology of the second network, and thus is unaware of the destination node disposed in the second network. Additionally, an SDN controller disposed in the second network may be able to determine the topology of the second network but does not know the topology of the first network, and thus is unaware of the source node disposed in the first network. Accordingly, these limitations result in challenges presented when connecting source nodes and destination nodes for a multicast data transmission across multiple networks (or sites).

This disclosure describes techniques for network border leaf switches to maintain respective external sources databases such that source nodes in a first network can be connected to destination nodes in a second network for a multicast data transmission across the networks. Further, an SDN controller disposed in a network may communicate with a respective network border leaf switch to utilize network capability information stored in an external sources database associated with the border leaf switch to configure a route for a multicast data transmission across multiple networks. According to the techniques and mechanisms described herein, each network may have an SDN controller and one or more network border leaf switches that are communicatively coupled to one or more network border leaf switches of an additional, separate network.

The network border leaf switches may be communicatively coupled using various network protocols, such as, for example, a Border Gateway Protocol (BGP), a Secure Border Gateway Protocol, (S-BGP), a Secure Origin Border Gateway Protocol (soBGP), a Border Gateway Multicast Protocol (BGMP), a Multicast Source Discovery Protocol (MSDP), or an Inter-Domain Routing Protocol (IDRP), or anything of the like. Each network border leaf switch in a cloud computing network may maintain an external sources database containing information about the additional network border leaf switches to which they are communicatively coupled to. The external sources database may include an address of a network border leaf switch, a source node identifier, multicast group identifiers, and network capability information stored in association with a respective network border leaf switch. The network border leaf nodes may communicate this information utilizing an enhanced version of a Source Active A-D Route type, such that this route type includes one or more Multicast Capabilities fields in a Type Length Values (TLV) format. The Multicast Capabilities field may include information used to specify details of a network, such as bandwidth associated with the network, a Differentiated Services Code Point (DSCP) value, and/or a priority of the network.

Once a local source begins a multicast data transmission, a respective SDN controller disposed in the same network (the first network) may receive a notification indicating as much. At this point the SDN controller may be unaware of all of the destination nodes, such that the SDN controller does not know if the destination nodes are local or remote to the first network. The SDN controller may then send a local source discovery message to leaf nodes configured as border switches in the first network, such that they are communicatively coupled to additional border switches in another network (the second network). The network border leaf switches may then advertise the local source discovery message to all the external network border leaf switches to which they are coupled. Upon receiving a local source discovery message, the network border leaf switch may cache the information included in the discovery message in a respective external source database. Additionally, or altematively, a local destination node may send, to an SDN controller disposed in the same network, a request to join a multicast group. In some examples, the request to join the multicast group may include an identifier of the multicast group. At this point, the SDN controller may be unaware of the source node, such that it does not know if the source node is local or remote to the network. The SDN controller may send a source discovery request to all the local network border leaf switches. A local network border leaf switch may receive this message and check in its respective external sources database to identify a source node associated with the multicast group. In some examples, a source node is not found, and the message is cached while the destination node remains waiting for a source to be discovered. In some examples, a source node is identified in the external sources database, and a source discovery notification is sent from the network border leaf switch to the SDN controller. The source discovery notification may include network capability information, such as bandwidth associated with the network and a priority associated with the multicast group and/or network. The SDN controller may then perform a bandwidth calculation and determine a path between this network border leaf switch and a switch where the local destination node is connected.

In an example cloud computing network, a first SDN controller, a first border leaf node, and a second border leaf node may be disposed in a first network. Additionally, or altematively, a second SDN controller and a third border leaf node may be disposed in a second network separate from the first network. In some examples, the first border leaf node may be communicatively coupled to the third border leaf node. Additionally, or alternatively, the second border leaf node may be communicatively coupled to the third border leaf node. In some examples, the first SDN controller may receive a notification from a local switch in the first network where a source node is connected, the notification notifying the SDN controller of the presence of the source node as a sender for a multicast data transmission to a multicast group of destination nodes. In some examples, the SDN controller may determine that a destination node in the multicast group is remote from the network. Additionally, or altematively, the SDN controller may identify the first and second border leaf nodes and send a local source discovery message to the first and second border leaf nodes. The local source discovery message may include, for example, an Internet Protocol (IP) address associated with the source node, an IP address and/or identifier associated with the multicast group, an indication of network bandwidth capabilities, and/or priorities associated with the network and/or multicast group. In some examples, the SDN controller may cause the first and second border leaf nodes to send the advertisement message to the third border leaf node. Additionally, or altematively, the first border leaf node may send the advertisement message to the third border leaf node. Additionally, or altematively, the second border leaf node may send the advertisement message to the third border leaf node. In some examples, the third border leaf node may maintain a local database including a table of external sources. In some examples, the third border leaf node may store the information included in the advertisement message in the external sources table in association with the border leaf node from which the message was received. For example, the third border leaf node may store the information included in the advertisement message received from the first border leaf node in association with the first border leaf node. Additionally, or alternatively, the third border leaf node may store the information included in the advertisement message received from the second border leaf node in association with the second border leaf node.

Additionally, or altematively, the second SDN controller may receive a request from a local switch in the second network where a destination node is connected, the request requesting to join a multicast group as a destination node (i.e., configured to receive a data transmission). In some examples, the request may include an address of the multicast group (i.e., an IP address of the multicast group and/or an identifier associated with the multicast group). The SDN controller may send a source discovery request to the third border leaf node. Additionally, or altematively, the SDN controller may send a source discovery request to all border leaf nodes disposed in the second network. The third border leaf node may query its respective local database for an external source associated with the multicast group. In some examples, an external source is not found, and the source discovery request is cached as long as the destination node remains active in the network. Additionally, or alternatively, an external source (the source node) is found in the external sources table. In some examples, the source node may be identified in multiple entries of the external sources table, such that there are multiple border leaf connections to reach the source node (i.e., the first border leaf node and the second border leaf node). In some examples, the third border node may identify the source node in association with the first border leaf node. Additionally, or altematively, the third border leaf node may identify the source node in association with the second border leaf node. The third border leaf node may send a source discovery notification to the second SDN controller indicating an identifier (or address) of an external border leaf node, an identifier of the multicast group, an identifier of the source node, and/or network capability information associated with the first network. In some examples, when the third border leaf node discovers the source node in association with multiple border leaf nodes, the third border leaf node may send respective source discovery notifications. When the second SDN controller receives the source discovery notification(s), the SDN controller may compare the respective network capability information associated the first and second border leaf nodes to identify a path with available bandwidth and install routes in the second network accordingly to form a path from the third border leaf node to the local switch in the second network where the destination node is connected. Once the SDN controller forms the path, a Protocol Independent Multicast (PIM) join is sent to the first network, and the data transmission is pulled from the first network to the second network.

In some examples, in order to identify a path install routes capable of handling the multicast data transmission, the SDN controller may compare the respective network capability information associated with the first and second border leaf nodes to identify whether utilizing the first border leaf node is more favorable than utilizing the second border leaf node to form the path. For example, the SDN controller may utilize the network capability information to determine that the first border leaf node has more available bandwidth than the second border leaf node and may determine that installing a path utilizing the first border leaf node is more favorable than installing a path utilizing the second border leaf node. Additionally, or altematively, the SDN controller may utilize the network capability information to determine that the first border leaf node has a higher priority in the network than the second border leaf node and may determine that installing a path utilize the first border leaf node is more favorable than installing a path utilizing the second border leaf node. Additionally, or altematively, the SDN controller may utilize any of the information included with the network capability information to make a determination as to which border leaf node is more favorable than the border leaf nodes available to form the path.

As described herein, a computing resource (or a node) can generally include any type of computing resources, such as, for example, physical resource(s) associated with physical servers and/or physical links in a network. Additionally, or altematively, the physical resource(s) may be apportioned or allocated to a virtual resource implemented by virtualization techniques, such as containers, virtual machines, virtual storage, and so forth, where the virtual resource(s) may utilize the allocated portions of the physical resources of the physical servers in the network. Further, although the techniques described as being implemented in data centers and/or a cloud computing network, the techniques are generally applicable for any network of devices managed by any entity where computing resource(s) are provisioned. In some instances, the techniques may be performed by a scheduler or orchestrator, and in other examples, various components may be used in a system to perform the techniques described herein. The devices and components by which the techniques are performed herein are a matter of implementation, and the techniques described are not limited to any specific architecture or implementation.

The techniques described herein provide various improvements and efficiencies with respect to broadcasting local sources and network capability information to external networks. For instance, the techniques described herein may provide network information of external sources to local SDN controllers and allow for a multicast data transmission across multiple cloud computing networks that are separate from one another. By maintaining a database of external sources and various network capability information at respective local border leaf nodes, the SDN controller may configure a path for a flow of data with a guaranteed bandwidth across multiple networks that are separate from one another, which was not previously possible.

Certain implementations and embodiments of the disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, the various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. The disclosure encompasses variations of the embodiments, as described herein.

<FIG> illustrates a system-architecture diagram <NUM> of an example flow for broadcasting local source discovery messages indicating a source node address and network capability information within a cloud computing network <NUM>. The cloud computing network <NUM> may comprise one or more data centers <NUM> that include various networking components, such as, a Software-Defined-Networking (SDN) controller <NUM>, spine network switches <NUM>, leaf network switches <NUM>, which might be referred to as "leaf nodes," border leaf network switches <NUM>, which might be referred to as "border leaf nodes," and physical servers <NUM>. In some examples, the data center(s) <NUM> may be located across geographic areas, and the cloud computing network <NUM> may be a distributed network through which users (often customers) may interact via user devices to manage or otherwise interact with service provided by the cloud computing network <NUM>.

The cloud computing network <NUM> may provide on-demand availability of computing system resources of physical server(s) <NUM>, such as data storage, computing power (e.g., CPU, GPU, etc.), networking, databases, etc., without direct active management by users. In some examples, the cloud computing network <NUM> may be managed and maintained by a service provider such that users do not have to invest in and maintain the computing infrastructure for their computing resource needs. Generally, a user may be provided access to, or allocated use of, a portion of the computing resources of physical server(s) <NUM> in the cloud computing network <NUM>. The cloud computing network <NUM> may scale, such as by spinning up resources or spinning down resources, based on demand for the individual users. The portions of the cloud computing network <NUM> may be allocated using hardware virtualization such that portions of the cloud computing network <NUM> can be configured and managed by the user (e.g., security configuration, load balancing configuration, etc.). However, the cloud computing network <NUM> need not be managed by a service provider, and can be managed by any entity, including the user themselves that run the applications or services.

In some examples, physical server(s) <NUM> may host one or more virtual machines. Each virtual machine may be configured to execute one of various operations and act as one or more virtual components for the cloud computing network <NUM>, such as, for example, resources <NUM>. In some examples, the physical server(s) <NUM> may host any number of virtual machines. In some examples, physical server(s) <NUM> in the cloud computing network <NUM> may host a multicast data source <NUM> node. Additionally, or altematively, physical server(s) <NUM> in the cloud computing network may host a multicast data destination <NUM> node. Additionally, or altematively, physical server(s) <NUM> in the cloud computing network may host an external sources <NUM> database.

In some examples, a virtual machine may be configured to execute one of various operations and act as a network border leaf switch <NUM>. A network border leaf switch <NUM> may be communicatively coupled to one or more network border leaf switches <NUM> and configured to forward communications between cloud computing network(s) <NUM> and/or data center(s) <NUM>. For example, network border leaf switch <NUM>(a)(<NUM>) may be configured to route communications between data center <NUM>(a) and data center <NUM>(b) within the cloud computing network by means of communicating with network border leaf switch <NUM>(b)(<NUM>). Additionally, or altematively, network border leaf switch <NUM>(a)(<NUM>) may be configured to route communications between data center <NUM>(a) and data center <NUM>(b) within the cloud computing network by means of communicating with network border leaf switch <NUM>(b)(<NUM>). Additionally, or alternatively, a virtual machine executing a network border leaf switch <NUM>(b)(<NUM>) may include an allocated virtual memory configured as an external sources database <NUM> attached to the respective network border leaf switch <NUM>(b)(<NUM>). The external sources database <NUM> may be configured to store information about the additional network border leaf switches <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) that are communicatively coupled to the network border leaf switch <NUM>(b)(<NUM>), and remote from. Additionally, or altematively, the external sources database <NUM> may include an address of a network border leaf switch <NUM>, a multicast data source <NUM> identifier, multicast group identifiers, and/or network capability information stored in association with a respective border leaf switch <NUM>.

Generally, the number of resources <NUM> may scale based on a number of users <NUM> interacting with the cloud computing network. The users <NUM> may comprise one or more of individual users, groups of users, organizations, businesses, or other entities that interact with the cloud computing network <NUM> via respective user devices. The user devices may be any type of computing device capable of connecting to the cloud computing network <NUM> via a suitable data communications network <NUM> such as, but not limited to, a laptop or desktop computer, a tablet computing device, a server computer, a television, or a mobile telephone. Administrative users employed by the operator of the cloud computing network <NUM>, such as administrators managing the operation of the cloud computing network <NUM>, might also connect with, manage, and utilize resources provided by the service provider network <NUM> in a similar fashion.

The users <NUM> may provide input data <NUM> via the network(s) <NUM> to interact with the service that is supported by the resources <NUM> running on the servers <NUM>. For example, the users <NUM> may submit requests to process data, retrieve data, store data, and so forth such that virtual machines hosting the resources <NUM> are spun up or spun down to process the requests based on demand.

An SDN controller <NUM>(b) disposed in a network may communicate with a respective border leaf switch <NUM>(b)(<NUM>) to utilize network capability information store in an external sources database <NUM> associated with the border leaf switch <NUM>(b)(<NUM>) to configure a route for a multicast data transmission across multiple networks, data centers <NUM>, and/or sites. Each SDN controller <NUM> may have one or more network border leaf switches <NUM> that are communicatively coupled to one or more border leaf switches <NUM> of an additional, separate network. The network border leaf switches <NUM> may be communicatively coupled using various network protocols, such as, for example, a Border Gateway Protocol (BGP), a Secure Border Gateway Protocol, (S-BGP), a Secure Origin Border Gateway Protocol (soBGP), a Border Gateway Multicast Protocol (BGMP), a Multicast Source Discovery Protocol (MSDP), or an Inter-Domain Routing Protocol (IDRP), or anything of the like. Each network border leaf switch <NUM> in a cloud computing network <NUM> may maintain an external sources database <NUM> containing information about the additional network border leaf switches <NUM> to which they are communicatively coupled to. The external sources database <NUM> may include an address of a network border leaf switch <NUM>, a multicast data source <NUM> identifier, multicast group identifiers, and network capability information stored in association with a respective network border leaf switch <NUM>. The network border leaf switches <NUM> may communicate this information utilizing an enhanced version of a Source Active A-D Route type, such that this route type includes one or more Multicast Capabilities fields in a Type Length Values (TLV) format. The Multicast Capabilities field may include information used to specify details of a cloud computing network <NUM>, such as bandwidth associated with the network, a Differentiated Services Code Point (DSCP) value, and/or a priority of the network.

When a local multicast data source <NUM> begins a multicast data transmission, a respective SDN controller <NUM>(a), disposed in the same network (associated with a data center <NUM>(a)), may receive a notification a notification indicating as much. At this point the SDN controller <NUM>(a) may be unaware of the destination nodes associated with a multicast group (G1), such that the SDN controller does not know if the destination nodes are local or remote to its respective network. For example, multicast data destination node <NUM> is remote from SDN controller <NUM>(a), and thus, SDN controller <NUM>(a) is unaware that multicast data destination node <NUM> is associated with the multicast group (G1). SDN controller <NUM>(a) may then send a local source discovery message to local leaf switches configured as border leaf switches <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) (also referred to as border leaf nodes) in the same network. The leaf nodes may be configured as border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) such that they are communicatively coupled to additional border leaf node(s) <NUM>(b)(<NUM>) in a separate network. The border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) may then advertise the local source discovery message to all the external border leaf nodes <NUM>(b)(<NUM>) to which they are coupled. Upon receiving a local source discovery request message, the border leaf node <NUM>(b)(<NUM>) receiving the discovery message may cache the information included in the discovery message in a respective external sources database <NUM>. In some examples, the local source discovery message may include an address and/or an identifier of the multicast data source <NUM>, an address and/or an identifier of the multicast group (G1), and/or network compatibility information associated with the network in which the multicast data source <NUM> is disposed.

Additionally, or alternatively, a local multicast data destination node <NUM> may send, to an SDN controller <NUM>(b) disposed in the same network, a request to join a multicast group (G1). In some examples, the request to join the multicast group (G1) may include an identifier of the multicast group. At this point, the SDN controller <NUM>(b) may be unaware of the multicast data source node <NUM>, such that it does not know if the multicast data source node <NUM> is local or remote to the network that the SDN controller <NUM>(b) is disposed in. For example, multicast data source node <NUM> is remote from SDN controller <NUM>(b), and thus, SDN controller <NUM>(b) is unaware that multicast data source node <NUM> is associated with the multicast group (G1). The SDN controller <NUM>(b) may send a source discovery request to all of the local border leaf nodes <NUM>(b)(<NUM>). The local border leaf node <NUM>(b)(<NUM>) may receive this message and check in its respective external sources database <NUM> to identify a multicast data source node (S1) <NUM> associated with the multicast group (G1). In some examples, a multicast data source node <NUM> is not found, and the message is cached while the multicast data destination node <NUM> remains waiting for a multicast data source node <NUM> to be discovered. In some examples, a multicast data source node <NUM> is identified in the external sources database <NUM>, and a source discovery notification is sent from the border leaf node <NUM>(b)(<NUM>) to the SDN controller <NUM>(b). The source discovery notification may include network capability information, such as bandwidth associated with the network and a priority associated with the multicast group (G1) and/or network. The SDN controller may then perform a bandwidth calculation and determine a path between this border leaf switch <NUM>(b)(<NUM>) and a switch <NUM>(b)(N) where the local destination node is connected.

At "<NUM>," a local multicast data source (S1) <NUM> may begin a multicast data transmission. The SDN controller <NUM>(a) in the same network may receive a notification from a local leaf switch (or node) <NUM>(a)(<NUM>) where the multicast data source <NUM> is connected. In some examples, the notification may indicate that the local multicast data source <NUM> has started a multicast data transmission. Additionally, or altematively, the notification may indicate that the local multicast data source <NUM> has begun sending traffic. Additionally, or altematively, the notification may indicate a presence of the multicast data source node <NUM> as a sender for a multicast data transmission to a multicast group (G1) of destination nodes.

At "<NUM>," the SDN controller <NUM>(a) may then identify all of the local network leaf nodes that are configured as border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>), such that they are communicatively coupled to at least one remote border leaf node <NUM>(b)(<NUM>) disposed in a separate network. Additionally, or alternatively, the SDN controller <NUM>(a) may determine that a destination node associated with the multicast group (G1) is remote from the network that the SDN controller <NUM>(a) is disposed in.

At "<NUM>," the SDN controller may send a local source discovery message to the local border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) that were identified in step "<NUM>. " In some examples, the local source discovery message may include, for example, an Internet Protocol (IP) address associated with the multicast data source node <NUM>, an IP address and/or identifier associated with the multicast group (G1), an indication of network bandwidth capabilities, and/or priorities associated with the network and/or multicast group.

At "<NUM>," the SDN controller <NUM>(a) may cause the border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) to send respective local source discovery messages to the attached border leaf node <NUM>(b)(<NUM>) disposed in the separate network. In some examples, after the border leaf node <NUM>(b)(<NUM>) receives the local source discover message(s) from the communicatively coupled border leaf node(s) <NUM>(a)(<NUM>), <NUM>(a)(<NUM>), the border leaf node <NUM>(b)(<NUM>) may store the information included in the local source discovery message in the external sources database <NUM>. In some examples, the border leaf node <NUM>(b)(<NUM>) may store the information in association with the respective border leaf node(s) <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) from which the message was received.

In some examples, the example flow may continue from step "<NUM>" of <FIG> to step "<NUM>" of <FIG>. Additionally, or alternatively, the example flow may begin from step "<NUM>" of <FIG> and continue from step "<NUM>" of <FIG> to step "<NUM>" of <FIG>.

<FIG> illustrates a system-architecture diagram <NUM> of an example flow for receiving a request for a multicast data destination node <NUM> to discover a multicast data source node (S1) <NUM> associated with a multicast group (G1) and various network capability information to configure a route for a multicast data transmission.

A local multicast data destination node <NUM> may send, to an SDN controller <NUM>(b) disposed in the same network, a request to join a multicast group (G1). In some examples, the request to join the multicast group (G1) may include an identifier of the multicast group. At this point, the SDN controller <NUM>(b) may be unaware of the multicast data source node <NUM>, such that it does not know if the multicast data source node <NUM> is local or remote to the network that the SDN controller <NUM>(b) is disposed in. For example, multicast data source node <NUM> is remote from SDN controller <NUM>(b), and thus, SDN controller <NUM>(b) is unaware that multicast data source node <NUM> is associated with the multicast group (G1). The SDN controller <NUM>(b) may send a source discovery request to all of the local border leaf nodes <NUM>(b)(<NUM>). The local border leaf node <NUM>(b)(<NUM>) may receive this message and check in its respective external sources database <NUM> to identify a multicast data source node (S1) <NUM> associated with the multicast group (G1). In some examples, a multicast data source node <NUM> is not found, and the message is cached while the multicast data destination node <NUM> remains waiting for a multicast data source node <NUM> to be discovered. In some examples, a multicast data source node <NUM> is identified in the external sources database <NUM>, and a source discovery notification is sent from the border leaf node <NUM>(b)(<NUM>) to the SDN controller <NUM>(b). The source discovery notification may include network capability information, such as bandwidth associated with the network and a priority associated with the multicast group (G1) and/or network. The SDN controller <NUM>(b) may then perform a bandwidth calculation and determine a path between this border leaf switch <NUM>(b)(<NUM>) and a switch <NUM>(b)(N) where the local multicast data destination node <NUM> is connected.

In some examples, the example flow below may continue from step "<NUM>" of <FIG> to step "<NUM>" of <FIG>. Additionally, or altematively, the example flow may begin from step "<NUM>" of <FIG> and continue from step "<NUM>" of <FIG> to step "<NUM>" of <FIG>.

At "<NUM>," a local multicast data destination node <NUM> may send a request to join a multicast group (G1) to an SDN controller <NUM>(b) disposed in the same network. In some examples, the request may include an IP address and/or an identifier of the multicast group (G1). The SDN controller <NUM>(b) may receive the request to join the multicast group (G1) from the multicast data destination node <NUM>. At this point, the SDN controller <NUM>(b) may be unaware of a multicast data source node <NUM>, such that the multicast data source node <NUM> is remote from the SDN controller <NUM>(b).

At "<NUM>," the SDN controller <NUM>(b) may then identify all of the local network leaf nodes that are configured as local border leaf node(s) <NUM>(b)(<NUM>), such that they are communicatively coupled to at least one remote border leaf node <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) disposed in a separate network. Additionally, or altematively, the SDN controller <NUM>(b) may determine that the multicast data source node <NUM> associated with the multicast group (G1) is remote from the network that the SDN controller <NUM>(b) is disposed in. The SDN controller <NUM>(b) may send a source discovery request to the local border leaf node(s) <NUM>(b)(<NUM>). In some examples, the source discovery request may include, for example, an IP address and/or an identifier associated with the multicast group (G1).

At "<NUM>," the local border leaf node <NUM>(b)(<NUM>) may check in the attached external sources database <NUM> to identify a multicast data source node (S1) <NUM> associated with the multicast group (G1). In some examples, a multicast data source node <NUM> is not found, and the message is cached while the multicast data destination node <NUM> remains waiting for a multicast data source node <NUM> to be discovered. Additionally, or altematively, a multicast data source node <NUM> associated with the multicast group (G1) is identified in the external sources database <NUM>, and a source discovery notification is sent from the border leaf node <NUM>(b)(<NUM>) to the SDN controller <NUM>(b). In some examples, the source discovery notification may include network capability information, such as bandwidth associated with the network and a priority associated with the multicast group (G1) and/or network.

At "<NUM>," the SDN controller <NUM>(b) may then perform a bandwidth calculation and determine a path between this border leaf switch <NUM>(b)(<NUM>) and a switch <NUM>(b)(N) where the local destination node is connected and configured a route for the multicast data transmission. In some examples, the SDN controller <NUM>(b) may configure the route to ensure the data is being transmitted through a route with a guaranteed bandwidth required for the data transmission.

<FIG> illustrate flow diagrams of example methods <NUM>, <NUM>, and <NUM> and that illustrate aspects of the functions performed at least partly by the cloud computing network <NUM> as described in <FIG> and <FIG>. The logical operations described herein with respect to <FIG> may be implemented (<NUM>) as a sequence of computer-implemented acts or program modules running on a computing system and/or (<NUM>) as interconnected machine logic circuits or circuit modules within the computing system.

The implementation of the various components described herein is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules can be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations might be performed than shown in the <FIG> and described herein. These operations can also be performed in parallel, or in a different order than those described herein. Some or all of these operations can also be performed by components other than those specifically identified. Although the techniques described in this disclosure is with reference to specific components, in other examples, the techniques may be implemented by less components, more components, different components, or any configuration of components.

<FIG> illustrates a flow diagram of an example method <NUM> for a Software-Defined-Networking (SDN) controller <NUM>(a) in a first cloud computing network to advertise a multicast data source node <NUM> and various network capability information associated with the first network to a second cloud computing network, utilizing one or more border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) disposed in the first network and communicatively coupled to one or more border leaf nodes <NUM>(b)(<NUM>) disposed in the second network. In some examples, the method <NUM> may be performed by a system comprising one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method <NUM>.

At <NUM>, a Software-Defined-Networking (SDN) controller <NUM>(a) in a first cloud computing network may receive a request from a multicast data source node <NUM> to coordinate a data transmission to a multicast group (G1) of destination nodes. In some examples, the source node may be disposed in the first network. Additionally, or altematively, the SDN controller may receive a notification from a network switch <NUM>(a)(<NUM>) where the multicast data source node <NUM> is connected, indicating that the multicast data source node <NUM> has started sending traffic to the multicast group (G1).

At <NUM>, the SDN controller <NUM>(a) may determine that at least one multicast data destination node <NUM> in the multicast group (G1) of destination nodes is in a second network that is separate from the first network.

At <NUM>, the SDN controller <NUM>(a) may identify a first border node <NUM>(a)(<NUM>) in the first network and communicatively coupled to a second border node <NUM>(b)(<NUM>) in the second network. Additionally, or altematively, the SDN controller <NUM>(a) may identify one or more border nodes <NUM>(a) in the first network and communicatively coupled to one or more second border nodes <NUM>(b) in the second network.

At <NUM>, the SDN controller <NUM>(a) may send, to the first border node <NUM>(a)(<NUM>), an advertisement message. In some examples, the advertisement message may include an indication of an address and/or and identifier of the multicast data source node <NUM>, an address and/or an identifier associated with the multicast group of destination nodes (G1), and/or network capability information associated with the first network. Additionally, or alternatively the SDN controller <NUM>(a) may send the advertisement message to one or more border nodes <NUM>(a) in the first network.

At <NUM>, the SDN controller may cause the first border node <NUM>(a)(<NUM>) to send the advertisement message to the second border node <NUM>(b)(<NUM>). Additionally, or altematively, the SDN controller <NUM>(a) may cause one or more border nodes <NUM>(a) to send the advertisement message to one or more second border nodes <NUM>(b) disposed in the second network.

<FIG> illustrates a flow diagram of an example method <NUM> for a Software-Defined-Networking (SDN) controller <NUM>(b) in a first cloud computing network to discover a multicast data source node <NUM> disposed in a second, remote network, and various network capability information of the second network to configure a route for a multicast data transmission from a border leaf node <NUM>(b)(<NUM>) to a network switch <NUM>(b)(N) connected.

At <NUM>, a Software-Defined-Networking (SDN) controller <NUM>(b) in a first cloud computing network may receive a request from multicast data destination node <NUM> to join a multicast group of destination nodes (G1) receiving a data transmission. In some examples, the multicast data destination node <NUM> is disposed in the first network.

At <NUM>, the SDN controller <NUM>(b) may send, to a border node <NUM>(b)(<NUM>) in the first network, a request to discover a multicast data source node <NUM> associated with the multicast group of destination nodes (G1).

At <NUM>, the SDN controller <NUM>(b) may receive, from the border node <NUM>(b)(<NUM>), a discovery notification of the multicast data source node <NUM>. In some examples, the multicast data source node <NUM> may be disposed in a second network separate from the first network and associated with the multicast group of destination nodes (G1). In some examples, the discovery notification may include an indication of an address and/or an identifier of the multicast data source node <NUM>, a group address and/or an identifier associated with the multicast group of destination nodes (G1), and/or network capability information associated with the second network.

At <NUM>, the SDN controller <NUM>(b) may configure a route for the data transmission from the border node <NUM>(b)(<NUM>) to the multicast data destination node <NUM>. In some examples, the SDN controller <NUM>(b) may configured the route based at least in part on the network capability information associated with the second network. In some examples, the network capability information may include information used to specify details of a network, such as bandwidth associated with the network, a Differentiated Services Code Point (DSCP) value, and/or a priority of the network.

<FIG> illustrates a flow diagram of an example method <NUM> for a network border leaf node <NUM>(b)(<NUM>) disposed in a first network and communicatively coupled to one or more network border leaf nodes <NUM>(a)(<NUM>), <NUM>(a)(<NUM>) disposed in a second, remote network, to discover a multicast data source node <NUM> disposed in the second network, and various network capability information associated with the second network and used to configure a route for a multicast data transmission from the border leaf switch <NUM>(b)(<NUM>) to a switch <NUM>(b)(N) where the local multicast data destination node <NUM> is connected.

At <NUM>, a first border node <NUM>(b)(<NUM>) disposed in a first network may receive, from a second border node <NUM>(a)(<NUM>) disposed in a second network, an advertisement message. In some examples, the advertisement message may include an indication of an address and/or and identifier of a multicast data source <NUM> an address and/or an identifier of the multicast group (G1), and/or network compatibility information associated with the network in which the multicast data source <NUM> is disposed. In some examples, the source node is disposed in the second network.

At <NUM>, the first border node <NUM>(b)(<NUM>) may store, in an external sources database <NUM> associated with the first border node <NUM>(b)(<NUM>), the address and/or identifier of the multicast data source <NUM>, the address and/or identifier of the multicast group (G1), and/or the network capability information in association with the second border node <NUM>(a)(<NUM>).

At <NUM>, the first border node <NUM>(b)(<NUM>) may receive, from a Software-Defined-Networking (SDN) controller <NUM>(b) disposed in the first network, a request to discover the multicast data source <NUM> associated with the multicast group of destination nodes (G1). In some examples, the request may include an indication of the address and/or identifier of the multicast group (G1).

At <NUM>, the first border node <NUM>(b)(<NUM>) may send, to the SDN controller <NUM>(b), a route configuration message. In some examples, the route configuration message may include the address and/or identifier of the multicast data source <NUM>, the address and/or identifier of the multicast group (G1), and/or the network capability information.

<FIG> is a computing system diagram illustrating a configuration for a data center <NUM> that can be utilized to implement aspects of the technologies disclosed herein. The example data center <NUM> shown in <FIG> includes several server computers 602A-602E (which might be referred to herein singularly as "a server computer <NUM>" or in the plural as "the server computers <NUM>") for providing computing resources. In some examples, the server computers <NUM> may include, or correspond to, the servers <NUM> described herein.

The server computers <NUM> can be standard tower, rack-mount, or blade server computers configured appropriately for providing the computing resources described herein. As mentioned above, the computing resources provided by the cloud computing network <NUM> can be data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the servers <NUM> can also be configured to execute a resource manager capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer <NUM>. Server computers <NUM> in the data center <NUM> can also be configured to provide network services and other types of services.

In the example data center <NUM> shown in <FIG>, an appropriate LAN <NUM> is also utilized to interconnect the server computers 602A-602E. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between data centers <NUM>, between each of the server computers 602A-602E in each data center <NUM>, and, potentially, between computing resources in each of the server computers <NUM>. It should be appreciated that the configuration of the data center <NUM> described with reference to <FIG> is merely illustrative and that other implementations can be utilized.

In some examples, the server computers <NUM> may each execute one or more resources <NUM> that support a service or application, such as, for example, a multicast data source <NUM>, and/or multicast data destination <NUM>, provisioned across a set or cluster of servers <NUM>. The resources <NUM> on each server computer <NUM> may support a single application or service, or multiple applications or services (for one or more users).

In some instances, the cloud computing network <NUM> may provide computing resources, like application containers, VM instances, and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources provided by the cloud computing network <NUM> may be utilized to implement the various services described above. The computing resources provided by the cloud computing network <NUM> can include various types of computing resources, such as data processing resources like application containers and VM instances, data storage resources, networking resources, data communication resources, network services, and the like.

Each type of computing resource provided by the cloud computing network <NUM> can be general-purpose or can be available in a number of specific configurations. For example, data processing resources can be available as physical computers or VM instances in a number of different configurations. The VM instances can be configured to execute applications, including web servers, application servers, media servers, database servers, some or all of the network services described above, and/or other types of programs. Data storage resources can include file storage devices, block storage devices, and the like. The cloud computing network <NUM> can also be configured to provide other types of computing resources not mentioned specifically herein.

The computing resources provided by the cloud computing network <NUM> may be enabled in one embodiment by one or more data centers <NUM> (which might be referred to herein singularly as "a data center <NUM>" or in the plural as "the data centers <NUM>"). The data centers <NUM> are facilities utilized to house and operate computer systems and associated components. The data centers <NUM> typically include redundant and backup power, communications, cooling, and security systems. The data centers <NUM> can also be located in geographically disparate locations. One illustrative embodiment for a data center <NUM> that can be utilized to implement the technologies disclosed herein will be described below with regard to <FIG>.

<FIG> shows an example computer architecture for a server computer <NUM> capable of executing program components for implementing the functionality described above. The computer architecture shown in <FIG> illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The server computer <NUM> may, in some examples, correspond to a physical server <NUM> described herein.

The computer <NUM> includes a baseboard <NUM>, or "motherboard," which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") <NUM> operate in conjunction with a chipset <NUM>. The CPUs <NUM> can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer <NUM>.

The chipset <NUM> provides an interface between the CPUs <NUM> and the remainder of the components and devices on the baseboard <NUM>. The chipset <NUM> can provide an interface to a RAM <NUM>, used as the main memory in the computer <NUM>. The chipset <NUM> can further provide an interface to a computer-readable storage medium such as a read-only memory ("ROM") <NUM> or non-volatile RAM ("NVRAM") for storing basic routines that help to startup the computer <NUM> and to transfer information between the various components and devices. The ROM <NUM> or NVRAM can also store other software components necessary for the operation of the computer <NUM> in accordance with the configurations described herein.

The computer <NUM> can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network <NUM>. The chipset <NUM> can include functionality for providing network connectivity through a NIC <NUM>, such as a gigabit Ethernet adapter. The NIC <NUM> is capable of connecting the computer <NUM> to other computing devices over the network <NUM> (or <NUM>). It should be appreciated that multiple NICs <NUM> can be present in the computer <NUM>, connecting the computer to other types of networks and remote computer systems.

The computer <NUM> can be connected to a storage device <NUM> that provides non-volatile storage for the computer. The storage device <NUM> can store an operating system <NUM>, programs <NUM>, and data, which have been described in greater detail herein. The storage device <NUM> can be connected to the computer <NUM> through a storage controller <NUM> connected to the chipset <NUM>. The storage device <NUM> can consist of one or more physical storage units. The storage controller <NUM> can interface with the physical storage units through a serial attached SCSI ("SAS") interface, a serial advanced technology attachment ("SATA") interface, a fiber channel ("FC") interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

The computer <NUM> can store data on the storage device <NUM> by transforming the physical state of the physical storage units to reflect the information being stored. The specific transformation of physical state can depend on various factors, in different embodiments of this description. Examples of such factors can include, but are not limited to, the technology used to implement the physical storage units, whether the storage device <NUM> is characterized as primary or secondary storage, and the like.

For example, the computer <NUM> can store information to the storage device <NUM> by issuing instructions through the storage controller <NUM> to alter the magnetic characteristics of a particular location within a magnetic disk drive unit, the reflective or refractive characteristics of a particular location in an optical storage unit, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this description. The computer <NUM> can further read information from the storage device <NUM> by detecting the physical states or characteristics of one or more particular locations within the physical storage units.

In addition to the mass storage device <NUM> described above, the computer <NUM> can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer <NUM>. In some examples, the operations performed by the cloud computing network <NUM>, and or any components included therein, may be supported by one or more devices similar to computer <NUM>. Stated otherwise, some or all of the operations performed by the cloud computing network <NUM>, and or any components included therein, may be performed by one or more computer devices <NUM> operating in a cloud-based arrangement.

By way of example, and not limitation, computer-readable storage media can include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media includes, but is not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically-erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory fashion.

As mentioned briefly above, the storage device <NUM> can store an operating system <NUM> utilized to control the operation of the computer <NUM>. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device <NUM> can store other system or application programs and data utilized by the computer <NUM>.

In one embodiment, the storage device <NUM> or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer <NUM>, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer <NUM> by specifying how the CPUs <NUM> transition between states, as described above. According to one embodiment, the computer <NUM> has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer <NUM>, perform the various processes described above with regard to <FIG>. The computer <NUM> can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

The server computer <NUM> may support a virtualization layer <NUM>, such as one or more virtual resources <NUM> executing on the server computer <NUM>, such as, for example, a multicast data source <NUM> and/or a multicast data destination <NUM>. In some examples, the virtualization layer <NUM> may be supported by a hypervisor that provides one or more virtual machines running on the server computer <NUM> to perform functions described herein. The virtualization layer <NUM> may generally support a virtual resource that performs at least portions of the techniques described herein. The border leaf node <NUM> may send and receive various data and provide it to components. For instance, the border leaf node <NUM> may receive a local source discovery message containing data indicating an address and/or identifier of a multicast data source node <NUM>, and store an association between the border leaf node <NUM> from which it was received and the multicast data source node <NUM> to later configure a route for a multicast data transmission to a multicast data destination node <NUM>.

While the invention is described with respect to the specific examples, it is to be understood that the scope of the invention is not limited to these specific examples. Since other modifications and changes varied to fit particular operating requirements and environments will be apparent to those skilled in the art, the invention is not considered limited to the example chosen for purposes of disclosure, and covers all changes and modifications which do not constitute departures from the true spirit and scope of this invention.

Claim 1:
A method (<NUM>) for a Software-Defined-Networking, SDN, controller (<NUM>(a)) to advertise a multicast data source node (<NUM>), the method comprising:
receiving (<NUM>), at a SDN controller (<NUM>(a)) in a first network (<NUM>(a)), a request from a source node (<NUM>) to coordinate a data transmission to a multicast group of destination nodes, wherein the source node is disposed in the first network;
determining (<NUM>), at the SDN controller, that at least one destination node (<NUM>) in the multicast group of destination nodes is in a second network (<NUM>(b)) that is separate from the first network;
identifying (<NUM>), at the SDN controller, a first border node (<NUM>(a)(<NUM>)) in the first network communicatively coupled to a second border node (<NUM>(b)(<NUM>)) in the second network;
sending (<NUM>), from the SDN controller and to the first border node, an advertisement message including an indication of an address of the source node, a group address associated with the multicast group of destination nodes, and network capability information associated with the first network; and
causing (<NUM>), by the SDN controller, the first border node to send the advertisement message to the second border node.