Method for implementing intra-cloud and inter-cloud multicast function by virtual instances in public cloud

Abstract

Disclosed is a method for implementing an intra-cloud and inter-cloud multicast function by virtual instances in a public cloud. The present invention mainly solves the issue of supporting a multicast in virtual instances of a public cloud user in a VPC or between VPCs, and also solves the issue of multicast communication between a user offline IDC and cloud-based virtual instances. When multicast members are added to a multicast group, the functions of the cloud-based virtual instances statically adding / leaving the multicast group and dynamically adding / leaving the multicast group by means of an IGMP protocol are supported, so that a cloud-based customer can use a multicast technology service in a service having a multicast requirement, providing the customer with a multicast service having low latency, fast access, and no packet loss. The method is applicable to various fields and live streaming services. The multicast is supported in a virtual network without changing a switch and a router on a computing node of a data center.

Description

A method for implementing intra-cloud and inter-cloud multicast functions using virtual instances in a public cloud

[0001] This application claims priority to Chinese patent application number CN202311712690.9, filed on December 13, 2023, entitled “A method for implementing intra-cloud and inter-cloud multicast functions through virtual instances in a public cloud,” the entire text of which is hereby incorporated by reference. Technical Field

[0002] The present application relates to the field of IT and software development technology, and in particular to a method for implementing intra-cloud and inter-cloud multicast functions by virtual instances in a public cloud. Background Art

[0003] The purpose of this section is to summarize some aspects of the embodiments of the present application and briefly introduce some preferred embodiments. Some simplifications or omissions may be made in this section and the abstract and title of the present application to avoid obscuring the purpose of this section, the abstract and the title of the invention, and such simplifications or omissions shall not be used to limit the scope of the present application.

[0004] In view of the above-mentioned problems and / or existing problems in the existing intra-cloud and inter-cloud multicast designs, this application is proposed.

[0005] Therefore, one of the purposes of this application is to provide a method for virtual instances in a public cloud to implement intra-cloud and inter-cloud multicast functions, which meets the different needs of customers by supporting two methods: statically specifying that multicast members join / leave a multicast group and dynamically joining / leaving a multicast group. The virtual instances on the public cloud support multicast functions without requiring the physical switch or routing device on the host computing node where the virtual instance is located to support the multicast protocol. The cloud platform controller component deployed on the computing node intercepts and parses the IGMP protocol message sent by the customer's virtual instance, and sends it to the cloud platform Server service component, and joins / leaves the virtual instance as a multicast member to the corresponding multicast group and carries the corresponding multicast source address information. , through this method, multicast members can dynamically join and leave the group; while multicast members can statically join or leave the group by calling the API interface provided by the cloud platform. For multicast communication between offline IDC and virtual instances on the cloud, it is only necessary to support the multicast protocol on the dedicated switch at the exit of the public cloud region, introduce the multicast traffic sent by the host in the IDC into the cloud, and then forward it to the multicast gateway through the dedicated gateway, and then distribute the multicast message to the virtual instance on the cloud. The configuration information of the dedicated switch at the exit of the region is automatically configured by the cloud platform. This process does not require support for multicast on the virtual router, related complex configuration, or the introduction of third-party applications for multicast support.

[0006] To achieve the above effects, the present application provides the following technical solution: a method for implementing intra-cloud and inter-cloud multicast functionality in a virtual instance in a public cloud, the method comprising the following steps:

[0007] S1: Network architecture topology of multicast-related components. Compute nodes are interconnected with a multicast gateway cluster, which is responsible for forwarding multicast packets. The multicast gateway cluster is interconnected with a VGW cluster, which forwards multicast packets sent by dedicated lines to the multicast gateway based on multicast routing information.

[0008] S2: Design an object model for multicast domains, multicast groups, and multicast members. In a user tenant, multicast resources are divided into multicast domains, multicast groups, and multicast members. A multicast domain is the range within which multicast data is transmitted.

[0009] S3: The multicast member joins the multicast in the multicast domain;

[0010] S4: On the compute node, the platform controller component intercepts and parses IGMP messages sent by multicast members in the tenant network. It then converts these messages into information about which multicast group the multicast member joins or leaves, which multicast sources it subscribes to, and which multicast domain it joins.

[0011] S5: The flow table pipeline designed on the OVS on the compute node intercepts IGMP messages. The platform controller parses and processes the messages, converts them into actions, and reports them to the platform server.

[0012] S6: After intercepting the IGMP protocol data message, parsing and converting it, it is sent to the controller, which then processes the message.

[0013] S7: The cloud platform server adds the multicast member to the multicast group or removes the multicast member from the multicast group based on the received information;

[0014] S8: In addition to processing the intercepted IGMP messages, the controller also periodically sends IGMP Member Query messages to the relevant virtual instances of the compute node based on the relationships between multicast members and multicast groups stored in the local controller cache.

[0015] S9: Design of multicast gateway forwarding table;

[0016] S10: Send the multicast data message.

[0017] As a preferred solution of the present application, in which: in S1, if the multicast source and multicast members are both on the cloud, regardless of whether the multicast members and the multicast members are in the same VPC or different VPCs, the multicast data packets sent by the multicast source will be forwarded to the multicast gateway, and then the multicast gateway will generate a local forwarding table based on the relationship information of the multicast group and multicast members issued by the cloud platform. After receiving the multicast data packets, the multicast gateway will forward the multicast data packets to different multicast members according to the generated local forwarding table. Through the forwarding of the multicast gateway cluster, the multicast data packets sent by the multicast source will be forwarded to the multicast members in the same VPC or different VPCs, and the multicast traffic outside the cloud will be forwarded to the virtual instance in the cloud through the VGW gateway.

[0018] As a preferred solution of the present application, the multicast domain in S2 is divided into a static multicast domain and a dynamic multicast domain, which respectively represent the way in which multicast members join the multicast group under the multicast domain. In the static multicast domain, multicast members join the multicast group through a cloud platform interface call, and in the dynamic multicast domain, multicast members join the multicast group through the IGMP protocol.

[0019] As a preferred solution of the present application, the model restriction relationship among the tenants, multicast domains, VPCs, multicast groups and multicast members is as follows: a tenant can create multiple multicast domains, each multicast domain specifies the multicast range by setting one or more VPCs, the multicast group addresses in different multicast domains can be repeated, but a VPC can only be added to one multicast domain. Within a multicast domain, it can create multiple multicast groups with different group addresses, a multicast group can join multiple multicast members, and when a multicast member is added to a multicast group, it can specify the multicast source address while specifying the multicast address to subscribe to the multicast sources of interest and the multicast sources of no interest.

[0020] 5. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 4, wherein the specific process of S3 is as follows:

[0021] S301: The tenant first creates a multicast domain and then specifies one or more VPCs during the creation of the multicast domain to define the multicast scope. VPCs can be specified during multicast domain creation, or after the multicast domain is created, the multicast scope can be expanded by adding VPC IDs to the list of VPCs added to the multicast domain. When creating a multicast domain, you also need to specify how members of the multicast group in the domain will join the multicast group and whether the multicast group in the multicast domain is intra-cloud multicast or inter-cloud multicast.

[0022] S302: If the multicast domain specifies that the method for multicast members in the multicast domain to join the multicast group is static joining, a multicast group needs to be created in the multicast domain, a multicast IP address needs to be specified, and then multicast members need to be added to the multicast group.

[0023] S303: If the multicast domain specifies that the way for multicast members to join the multicast group under the multicast domain is dynamic joining, there is no need to create a multicast group. When an IGMPv2 or IGMPv3 join / leave message is sent from a virtual instance within the VPC range of the multicast domain, the cloud platform will automatically sense and analyze the IGMP protocol message on the host node where it is located, and obtain the multicast IP information. If it is IGMPv3, it will also sense<S,G> The performance information is obtained, and the IP address, MAC address, VPC information, and host location information of the virtual instance are obtained. A certain data structure is constructed and reported to the cloud platform server service. The cloud platform server service then automatically creates a multicast group and the multicast members under the multicast group, and persists them in the database according to the model relationship.

[0024] S304: Specify any multicast source in the VPC in the multicast domain to send multicast message information. If a multicast group with the same multicast IP address as the multicast message sent by the multicast source has been statically or dynamically created in the multicast domain, all members of the multicast group can receive the multicast message from the multicast source.

[0025] As a preferred solution of the present application, the flow table program in S5 is specifically as follows:

[0026] #dispatcher flow table:

[0027] table={dispatcher},priority=1000,igmp,reg5=0x7ba2f,

[0028] dl_dst=01:00:5e:00:00:00 / ff:ff:ff:80:00:00,nw_dst=224.0.0.0 / 4, actions=move:NXM_NX_REG5[0..23]->NXM_OF_ETH_DST[0..23],CONTROLLER:65535

[0029] #l2_lookup:

[0030] #Multicast data message outgoing message

[0031] table={l2_lookup},priority=2000,ip,reg5=0x339b9,dl_dst=01:00:5e:00:00:00 / ff:ff:ff:80:00:00

[0032] actions=mod_nw_ttl:64,goto_table:{l3_input}

[0033] #Multicast data packets received by multicast members on this computing node

[0034] #Add multicast processing representation multicast (table=61) between l2_lookup (table60) and ingressct (table70).

[0035] mac:fa:16:3e:37:66:dd is the MAC address of a virtual instance of this computing node

[0036] table={l2_lookup},priority=100,reg5=0xa8af8,dl_dst=fa:16:3e:37:66:ddactions=set_field:0xa8af8->tun_id,set_field:0x19f->reg7,goto_table:{multicast}

[0037] # The multicast member is on this computing node. Change the destination MAC address to the multicast MAC address. MAC address: fa:16:3e:73:81:62 is the MAC address of the multicast member.

[0038] table={multicast},priority=1000,ip,reg5=0x52e1e,dl_dst=fa:16:3e:73:81:62,nw_dst=239.0.0.106actions=set_field:01:00:5e:00:00:6a->eth_dst,goto_table:{ingressct}

[0039] table={multicast},priority=50actions=goto_table:{ingressct}

[0040] #route:

[0041] #Multicast routing table. fe:16:19:41:8e:67 is the MAC address of the linklocal port of mcgw

[0042] table={route},priority=10004,ip,metadata=0x339b900000009,nw_dst=224.0.0.0 / 4

[0043] actions=set_field:fe:16:19:41:8e:67->eth_dst,set_field:0x339b9->reg5,dec_ttl,resubmit(,dispatcher);

[0044] The note for NXM_NX_REG5 indicates that the NXM_NX_REG5 register stores the VNI value. The note for reg7 indicates that the reg7 register stores the ofport value of the virtual instance network card in ovs. Metadata is used to distinguish different subnets.

[0045] As a preferred solution of the present application, the controller obtains the joining / leaving information of the virtual instance by parsing the IGMP Membership Report message of the virtual instance, or sends an IGMP Membership Query to query the information of the multicast group to which the virtual instance belongs, including the multicast message information received from the specified multicast source, and saves the relationship information between the multicast members and the multicast group in the cache of the local controller, and then converts the information into a joining / leaving message sent to the cloud platform, and then converts the message into a multicast member object requesting to be reported to the cloud platform server.

[0046] As a preferred solution of the present application, the message structure is specifically represented as follows:

[0047] type MulticastMemUpdatedMsg struct{

[0048] ctx context.Context

[0049] ofport uint32 / / The identification ID of the virtual instance on this host

[0050] vni uint32 / / VNI of the virtual instance

[0051] fixIp string / / fixIp of virtual instance

[0052] mac string / / Mac of the virtual instance

[0053] underlayIp string / / The underlayIP of the host where the virtual instance is located

[0054] action int / / Action:0:updated;1:Leave

[0055] groupAddresses map[string]*updateGroupInfo / / Multicast group address information carried by the virtual instance}

[0056] As a preferred solution of the present application, the multicast member object parameter in the request parameter reported to the cloud platform server is specifically represented as follows:

[0057] typeMulticastMemberParam struct{

[0058] Vni uint32 `json:"port_vni"`

[0059] FixIp string `json:"fix_ip"`

[0060] Mac string`json:"mac_address"`

[0061] UnderlayIp string`json:"underlay_ip"`

[0062] Cookie uint64 `json:"cookie"`

[0063] MulticastGroups[]*MulticastGroup`json:"multigroups"`

[0064] }

[0065] type MulticastGroup struct{

[0066] McGroupIp string`json:“multigroup_ip”`

[0067] IncludeSips[]string`json:"include_sips"`

[0068] ExcludeSips[]string`json:"exclude_sips"`

[0069] Action int json:"action" / / update,leave

[0070] JoinType int json:"join_type"`

[0071] }.

[0072] As a preferred solution of the present application, the attributes of the multicast forwarding table record designed in the multicast gateway include: Vni, GroupIp, Mask, SourceIp, RemoteVni, HostIp, VmIp, OverlayDmac, ExCount and ExcludeSip, and the specific meaning of each attribute is: Vni is the Vni of the VPC where the multicast source is located, GroupIp and Mask are the multicast group addresses of the multicast message, SourceIp is the multicast source address subscribed by the multicast member, RemoteVni, HostIp, VmIp, OverlayDmac are the vni of the VPC where the multicast member joining the multicast group address is located, and the host Ip, multicast member Ip, and mac address of multicast member, ExcludeSip is the address list of multicast sources that multicast members do not subscribe to, ExCount is the number of multicast source address lists that multicast members do not subscribe to, and S10 is specifically: the controller and VGW gateway on the computing node will obtain the multicast routing of VPC from the cloud platform Server service and forward the multicast message. For multicast communication between the IDC under the cloud and the multicast members on the cloud, after receiving the multicast member addition / leaving group information, the cloud platform Server will automatically send relevant configuration information to the border multicast switch or router of this region, and communicate and interact with the multicast router of the IDC under the cloud through the PIM-SM protocol to introduce multicast traffic into the cloud.

[0073] Beneficial effects of this application:

[0074] 1. This application has a unique mechanism for multicast members to join / leave a multicast group, specifically a method for multicast groups to dynamically manage multicast members. By orchestrating the OVS flow table on the compute node, IGMP join / leave messages sent by multicast members are intercepted and sent to the controller for processing. This process completes IGMP communication within the tenant virtual network, without requiring the switches or routers connected to the compute node host to support the multicast protocol.

[0075] 2. After receiving the IGMP message sent to it, the computing node controller of this application method parses and analyzes the IGMP message information, obtains the VNI of the virtual instance and the multicast group information to be joined / left after processing according to a certain process, and converts it into multicast member and multicast group relationship information based on the multicast model relationship designed by the cloud platform server and reports it to the server, joins the corresponding multicast domain, and persists it, thereby realizing the automatic addition / exit of multicast members to the group. The controller periodically sends IGMP Membership Query messages to the multicast members of this computing node to query the multicast group status of the virtual instance, and periodically converts the relationship information of the multicast members and multicast groups in the controller cache into multicast objects and reports them to the cloud platform server service, thereby solving the problem of loss of multicast protocol message information of the virtual instance and reporting failure caused by network anomalies. This process does not require the virtual routing of the VPC to forward multicast protocol messages;

[0076] 3. The controller on the multicast gateway cluster of this application sends multicast forwarding table records to the multicast gateway data forwarding plane based on the multicast domain, multicast group, and multicast member information persisted by the cloud platform server service. The data forwarding plane forwards multicast messages based on the multicast forwarding table. The design of the multicast forwarding table supports the multicast source forwarding multicast data messages to multicast members in the same VPC and across VPCs.

[0077] 4. This application method supports multicast communication between on-cloud and off-cloud IDC hosts. First, the offline IDC hosts are connected to the on-cloud virtual instances through a dedicated line. Then, the multicast domain is used to define the scope of multicast transmission. The offline IDC hosts and on-cloud virtual instances can be added to the same multicast domain. The VGW issues a multicast route to forward the multicast message to the multicast gateway, which then forwards it to the corresponding multicast members.

[0078] 5. The definition of the multicast model relationship in this application defines the relationship between multicast domains, multicast groups, and multicast members, and associates VPC with multicast domains and adds them to the multicast domain to achieve forwarding communication of multicast messages under the same multicast domain. BRIEF DESCRIPTION OF THE DRAWINGS

[0079] To more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. Those skilled in the art can also derive other drawings based on these drawings without inventive effort. Among them:

[0080] Figure 1 is a schematic diagram of the multicast topology architecture of this application;

[0081] FIG2 is a schematic diagram of the multicast model relationship of this application;

[0082] FIG3 is a schematic diagram of the Pipeline design of the multicast flow table of this application;

[0083] FIG4 is a schematic diagram of the IGMP message processing flow of this application;

[0084] FIG5 is a schematic diagram of the multicast forwarding table of this application;

[0085] FIG6 is a schematic diagram of the multicast routing design field of this application. DETAILED DESCRIPTION

[0086] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are described in detail below in conjunction with the drawings in the specification.

[0087] In the following description, many specific details are set forth to facilitate a full understanding of the present application. However, the present application may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present application. Therefore, the present application is not limited to the specific embodiments disclosed below.

[0088] Secondly, the term "one embodiment" or "embodiment" herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present application. The phrase "in one embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment, nor does it refer to a separate or selective embodiment that is mutually exclusive with other embodiments.

[0089] Example 1

[0090] 1 to 3 , which are the first embodiment of the present application, provide a method for implementing intra-cloud and inter-cloud multicast functionality in a virtual instance in a public cloud, including the following steps:

[0091] S1: Network architecture topology of multicast-related components. Compute nodes are interconnected with a multicast gateway cluster, which is responsible for forwarding multicast packets. The multicast gateway cluster is interconnected with a VGW cluster, which forwards multicast packets sent by dedicated lines to the multicast gateway based on multicast routing information.

[0092] S2: Design an object model for multicast domains, multicast groups, and multicast members. In a user tenant, multicast resources are divided into multicast domains, multicast groups, and multicast members. A multicast domain is the range within which multicast data is transmitted.

[0093] S3: The multicast member joins the multicast in the multicast domain;

[0094] S301: The tenant first creates a multicast domain and then specifies one or more VPCs during the creation of the multicast domain to define the multicast scope. VPCs can be specified during multicast domain creation, or after the multicast domain is created, the multicast scope can be expanded by adding VPC IDs to the list of VPCs added to the multicast domain. When creating a multicast domain, you also need to specify how members of the multicast group in the domain will join the multicast group and whether the multicast group in the multicast domain is intra-cloud multicast or inter-cloud multicast.

[0095] S302: If the multicast domain specifies that the method for multicast members in the multicast domain to join the multicast group is static joining, a multicast group needs to be created in the multicast domain, a multicast IP address needs to be specified, and then multicast members need to be added to the multicast group.

[0096] S303: If the multicast domain specifies that the way for multicast members to join the multicast group under the multicast domain is dynamic joining, there is no need to create a multicast group. When an IGMPv2 or IGMPv3 join / leave message is sent from a virtual instance within the VPC range of the multicast domain, the cloud platform will automatically sense and analyze the IGMP protocol message on the host node where it is located, and obtain the multicast IP information. If it is IGMPv3, it will also sense<S,G> The performance information is obtained, and the IP address, MAC address, VPC information, and host location information of the virtual instance are obtained. A certain data structure is constructed and reported to the cloud platform server service. The cloud platform server service then automatically creates a multicast group and the multicast members under the multicast group, and persists them in the database according to the model relationship.

[0097] S304: A multicast source in a designated VPC in the multicast domain sends a multicast message. If a multicast group with the same multicast IP address as the multicast message sent by the multicast source has been statically or dynamically created in the multicast domain, all members of the multicast group will receive the multicast message from the multicast source.

[0098] S4: On the compute node, the platform controller component intercepts and parses IGMP messages sent by multicast members in the tenant network. It then converts these messages into information about which multicast group the multicast member joins or leaves, which multicast sources it subscribes to, and which multicast domain it joins.

[0099] S5: The flow table pipeline designed on the OVS on the compute node intercepts IGMP messages. The platform controller parses and processes the messages, converts them into actions, and reports them to the platform server.

[0100] S6: After intercepting the IGMP protocol data message, parsing and converting it, it is sent to the controller, which then processes the message.

[0101] S7: The cloud platform server adds the multicast member to the multicast group or removes the multicast member from the multicast group based on the received information;

[0102] S8: In addition to processing the intercepted IGMP messages, the controller also periodically sends IGMP Member Query messages to the relevant virtual instances of the compute node based on the relationships between multicast members and multicast groups stored in the local controller cache.

[0103] S9: Design of multicast gateway forwarding table;

[0104] S10: Send the multicast data message.

[0105] Example 2

[0106] 1 to 6 , there is shown a second embodiment of the present application, which is based on the previous embodiment.

[0107] The network architecture topology of multicast-related components in this embodiment is shown in Figure 1. In the figure, the computing nodes are interconnected with the multicast gateway cluster, which is responsible for forwarding multicast messages. The multicast gateway cluster is interconnected with the VGW gateway cluster, and the VGW can forward multicast messages sent by dedicated lines to the multicast gateway based on multicast routing information. If the multicast source and multicast members are both on the cloud, regardless of whether the multicast members are in the same VPC or different VPCs, the multicast data messages sent by the multicast source will be forwarded to the multicast gateway. The multicast gateway then generates a local forwarding table based on the relationship information between the multicast group and multicast members issued by the cloud platform, and then forwards the multicast data messages to different multicast members. Figure 1 shows the data path for the multicast source in the offline IDC to send multicast messages to the online virtual instance. Figure 1 shows that the multicast source and multicast members are both online, but the multicast members are across VPCs. The difference between Figure 1 and is that the multicast members and multicast source are both in the same VPC. Through the forwarding of the multicast gateway cluster, the multicast data packets sent by the multicast source are forwarded to the multicast members in the same VPC or different VPCs; the multicast traffic outside the cloud is forwarded to the virtual instances within the cloud through the VGW gateway.

[0108] For the topology architecture of Figure 1, this application scheme designs an object model of multicast domains, multicast groups, and multicast members. As shown in Figure 2, in the user tenant, multicast resources are divided into: multicast domains, multicast groups, and multicast members. The multicast domain is the propagation range of multicast data. That is, the transmission range of multicast messages. At the same time, multicast domains are divided into two types: static multicast domains and dynamic multicast domains. They respectively represent the way in which multicast members in the multicast domain join the multicast group. In the static multicast domain, multicast members join the multicast group through the cloud platform interface call; in the dynamic multicast domain, multicast members join the multicast group through the IGMP protocol.

[0109] The model restrictions for tenants, multicast domains, VPCs, multicast groups, and multicast members are as follows:

[0110] A tenant can create multiple multicast domains. Each multicast domain specifies the multicast range by setting one or more VPCs. Multicast group addresses can be repeated in different multicast domains, but a VPC can only join one multicast domain. Within a multicast domain, multiple multicast groups with different group addresses can be created. A multicast group can join multiple multicast members. When adding a multicast member to a multicast group, it can specify the multicast source address and subscribe to the multicast sources it is interested in and the multicast sources it is not interested in. By designing a model and persisting the model object to the cloud platform, computing nodes and network element nodes issue multicast forwarding tables based on the model data and forward multicast data packets to the corresponding multicast members.

[0111] In the multicast model shown in Figure 2, multicast members can join or leave the multicast group statically or dynamically. Static joining is accomplished through cloud platform interface calls, while dynamic joining is accomplished by multicast members sending IGMP messages. The compute node controller intercepts and parses the IGMP messages, then reports them to the cloud platform server service for persistence.

[0112] The process for a multicast member to join a multicast in a multicast domain is as follows:

[0113] Tenants first create a multicast domain and then specify one or more VPCs when creating the multicast domain to define the multicast range. VPCs can be specified when creating the multicast domain, or after the multicast domain is created, the VPC IDs can be added to the list of VPCs added to the multicast domain to expand the multicast range. When creating a multicast domain, you also need to specify how members of the multicast group in the multicast domain will join the multicast group and whether the multicast group in the multicast domain is intra-cloud multicast or inter-cloud multicast.

[0114] If the multicast domain specifies that multicast members in the multicast domain join the multicast group statically, you need to create a multicast group in the multicast domain, specify the multicast IP address, and then add multicast members to the multicast group.

[0115] If the multicast domain specifies that the way for multicast members to join the multicast group under the multicast domain is dynamic joining, there is no need to create a multicast group. When a virtual instance within the VPC range of the multicast domain sends an IGMPv2 or IGMPv3 join / leave message, the cloud platform will automatically sense and analyze the IGMP protocol message on the host node where it is located to obtain the multicast IP information. If it is IGMPv3, it will also sense<S,G> The server automatically creates a multicast group and its members, and persists them in the database according to the model relationship shown in Figure 2.

[0116] In a multicast domain, specify any multicast source in a VPC to send multicast messages. If a multicast group with the same multicast IP address as the multicast source has been created statically or dynamically in the multicast domain, all members of the multicast group will receive the multicast messages from the multicast source.

[0117] In this embodiment, the key to the dynamic joining of multicast members to a multicast group is that the platform controller component on the compute node intercepts and parses IGMP messages sent by multicast members in the tenant network. This information is then converted into information about which multicast group the multicast member joins or leaves, which multicast sources it subscribes to and which it does not subscribe to, and which multicast domain it joins. To accomplish this, this embodiment performs the following operations:

[0118] Design the OVS flow table pipeline on the compute nodes to intercept IGMP messages and report them to the platform controller deployed on the compute nodes;

[0119] The platform controller parses and processes the message, converts it into some actions and reports it to the platform server;

[0120] Figure 3 shows the flow table pipeline designed for OVS on a compute node. When a packet from a virtual instance reaches the dispatcher flow table, it matches the IGMP message based on the protocol and is then sent to the controller via PacketIn. During flow processing, the VPC's VNI information is carried and reported to the controller. The L2 lookup flow table matches the multicast data packet based on the VPC and MAC addresses, and then jumps to the L3 input flow table for processing. Upon reaching the route flow table, the multicast data packet is forwarded to the multicast gateway via a tunnel based on the multicast routing table issued by the platform. If a multicast member is on the compute node, the L2 lookup matches the multicast message and jumps to the multicast flow table. This flow table matches the VNI, multicast IP address, and destination MAC address, and sends the multicast message to the multicast member on the compute node. The Multicast flow table has a special design because on the compute node, the vni + destination mac can determine which virtual instance on the compute node the message is sent to. The purpose of adding multicast IP matching is that in the overlay message sent by the multicast gateway to the multicast member, the destination mac is the mac address of the multicast member. The multicast flow table on the compute node needs to restore the destination mac to the multicast mac based on the multicast IP before sending it to the multicast member. The detailed design of the flow table is as follows:

[0121] #dispatcher flow table:

[0122] table={dispatcher},priority=1000,igmp,reg5=0x7ba2f,

[0123] dl_dst=01:00:5e:00:00:00 / ff:ff:ff:80:00:00,nw_dst=224.0.0.0 / 4, actions=move:NXM_NX_REG5[0..23]->NXM_OF_ETH_DST[0..23],CONTROLLER:65535

[0124] #l2_lookup:

[0125] #Multicast data message outgoing message

[0126] table={l2_lookup},priority=2000,ip,reg5=0x339b9,dl_dst=01:00:5e:00:00:00 / ff:ff:ff:80:00:00

[0127] actions=mod_nw_ttl:64,goto_table:{l3_input}

[0128] #Multicast data packets received by multicast members on this computing node

[0129] #Add multicast processing representation multicast (table=61) between l2_lookup (table60) and ingressct (table70).

[0130] mac:fa:16:3e:37:66:dd is the MAC address of a virtual instance of this computing node

[0131] table={l2_lookup},priority=100,reg5=0xa8af8,dl_dst=fa:16:3e:37:66:ddactions=set_field:0xa8af8->tun_id,set_field:0x19f->reg7,goto_table:{multicast}

[0132] # The multicast member is on this computing node. Change the destination MAC address to the multicast MAC address. MAC address: fa:16:3e:73:81:62 is the MAC address of the multicast member.

[0133] table={multicast},priority=1000,ip,reg5=0x52e1e,dl_dst=fa:16:3e:73:81:62,nw_dst=239.0.0.106actions=set_field:01:00:5e:00:00:6a->eth_dst,goto_table:{ingressct}

[0134] table={multicast},priority=50actions=goto_table:{ingressct}

[0135] #route:

[0136] #Multicast routing table. fe:16:19:41:8e:67 is the MAC address of the linklocal port of mcgw

[0137] table={route},priority=10004,ip,metadata=0x339b900000009,nw_dst=224.0.0.0 / 4

[0138] actions=set_field:fe:16:19:41:8e:67->eth_dst,set_field:0x339b9->reg5,dec_ttl,resubmit(,dispatcher)

[0139] The note for NXM_NX_REG5 indicates that the NXM_NX_REG5 register stores the VNI value. The note for reg7 indicates that the reg7 register stores the ofport value of the virtual instance network card in ovs. Metadata is used to distinguish different subnets.

[0140] After the IGMP data packet is intercepted and sent to the controller, the controller needs to process the message. Figure 4 shows the process of the controller processing IGMP multicast messages. The computing node processes the IGMP message information of the intercepted virtual instance. The IGMP protocol messages supported by the computing node are mainly IGMPv2 and IGMPv3 messages. The controller obtains the virtual instance's group joining / leaving information by parsing the virtual instance's IGMP Membership Report message, or sends an IGMP Membership Query to query the virtual instance's multicast group information, including the multicast message information it receives from the specified multicast source, and saves the relationship information between the multicast members and the multicast group in the local controller's cache. The information is then converted into a message to send to the cloud platform to join / leave the group. The message structure is specifically expressed as follows:

[0141] type MulticastMemUpdatedMsg struct{

[0142] ctx context.Context

[0143] ofport uint32 / / The identification ID of the virtual instance on this host

[0144] vni uint32 / / VNI of the virtual instance

[0145] fixIp string / / fixIp of virtual instance

[0146] mac string / / Mac of the virtual instance

[0147] underlayIp string / / The underlayIP of the host where the virtual instance is located

[0148] action int / / Action:0:updated;1:Leave

[0149] groupAddresses map[string]*updateGroupInfo / / Multicast group address information carried by the virtual instance};

[0150] The message is then converted into a multicast member object that is reported to the cloud platform server. The multicast member object parameters in the request parameters reported to the cloud platform server are specifically expressed as follows:

[0151] typeMulticastMemberParam struct{

[0152] Vni uint32 `json:"port_vni"`

[0153] FixIp string `json:"fix_ip"`

[0154] Mac string`json:"mac_address"`

[0155] UnderlayIp string`json:"underlay_ip"`

[0156] Cookie uint64 `json:"cookie"`

[0157] MulticastGroups[]*MulticastGroup`json:"multigroups"`

[0158] }

[0159] type MulticastGroup struct{

[0160] McGroupIp string`json:“multigroup_ip”`

[0161] IncludeSips[]string`json:"include_sips"`

[0162] ExcludeSips[]string`json:"exclude_sips"`

[0163] Action int json:"action" / / update,leave

[0164] JoinType int json:"join_type"`

[0165] };

[0166] The cloud platform server can then add or remove multicast members from the multicast group based on the received information, thus enabling virtual instances to dynamically join or leave the group.

[0167] In the processing flow of Figure 4, in addition to processing intercepted IGMP messages, the controller also periodically sends IGMP Member Query messages to the relevant virtual instances of this computing node based on the relationships between multicast members and multicast groups stored in the local controller cache. At the same time, it also periodically converts the local multicast members and multicast group relationships into multicast member objects that are requested to be reported to the cloud platform server. This is used to compensate for the problem of network anomalies causing failures when multicast members send IGMP or report to the server.

[0168] Design of the multicast gateway forwarding table. Multicast data packets sent by virtual instances are processed by the compute node's flow table, encapsulated into tunnel packets, and forwarded to the multicast gateway. The platform controller on the multicast gateway will issue a multicast packet forwarding table on the local data plane based on the data from the cloud platform server. The forwarding table contains information about multicast members. The multicast gateway forwards multicast data packets to multicast members based on the forwarding table. The attributes recorded in the multicast forwarding table include: Vni, GroupIp, Mask, SourceIp, RemoteVni, HostIp, VmIp, OverlayDmac, ExCount, and ExcludeSip. The specific meaning of each attribute is as follows:

[0169] Vni is the Vni of the VPC where the multicast source is located, GroupIp and Mask are the multicast group addresses of the multicast message, SourceIp is the multicast source address to which the multicast member subscribes, RemoteVni, HostIp, VmIp, and OverlayDmac are the Vni of the VPC where the multicast member joining the multicast group address is located, the host IP, the multicast member IP, and the MAC address of the multicast member, respectively. ExcludeSip is the address list of multicast sources to which the multicast member does not subscribe, and ExCount is the number of multicast source address lists to which the multicast member does not subscribe.

[0170] The VPC where the multicast source is located also needs to be configured with a multicast routing table in order to send out multicast data packets. The controller and VGW gateway on the computing node will obtain the VPC's multicast routing from the cloud platform Server service and forward the multicast packets. For multicast communication between the IDC under the cloud and the multicast members on the cloud, the cloud platform Server will automatically send relevant configuration information to the border multicast switch or router of the region after receiving the multicast member join / leave group information, and communicate and interact with the multicast router of the IDC under the cloud through the PIM-SM protocol to introduce multicast traffic into the cloud;

[0171] This implementation enables multicast support for virtual instances on the public cloud. Beyond the edge switch or router connecting the data center to the VGW gateway, no other switches or routers in the data center need to support multicast, reducing changes to physical network equipment. It also eliminates the need for users to configure multicast switches or routers, simplifying user experience. This platform also supports both static and dynamic joining / leaving of multicast groups for multicast members, meeting diverse customer needs and allowing users to focus on deploying relevant multicast applications within virtual instances.

[0172] In addition, the reference protocols in this application include IGMP protocol: rfc1112, IGMPv2 protocol: rfc2236 and IGMPv3 protocol: rfc337, and the glossary of terms in this application is explained as follows:

[0173] Multicast, also known as multicast or anycast, is a one-to-many communication method that allows a multicast source to send the same message to a group of hosts. The host or hosts that receive the message from the multicast source become multicast receivers, also called multicast members.

[0174] A multicast domain is the range within which multicast packets are transmitted. On a public cloud, one or more VPCs can form a multicast domain.

[0175] A multicast group is a multicast message transmission range consisting of the same multicast address. Multicast members can join / leave the multicast group and subscribe to multicast messages sent from a specified source with the same multicast address.

[0176] A multicast member is a host or virtual instance that joins a multicast group;

[0177] A multicast address is a Class D IP address with the first four bits being 1110. The CIDR mask can be expressed as 224.0.0.0 / 4. The IP value range is 224.0.0.0-239.255.255.255. A multicast address generally appears in the destination address of a message and cannot be the source IP address of a message.

[0178] Multicast MAC address: The first three bytes are 01:00:5e, and the last three bytes are related to the multicast IPv4 address. Specifically, the 25th bit is always 0, and the remaining 23 bits are the last 23 bits of the multicast IP address.

[0179] Multicast protocols include:

[0180] Layer 2 multicast protocols: IGMP Snooping, multicast VLAN, etc.

[0181] Layer 3 multicast protocols: IGMP (v1-v3), PIM-SM, MSDP, MBGP, BIER, MLD, MLD Snooping, BIERv6, etc.

[0182] The IGMP protocol, or Internet Group Management Protocol, is responsible for managing IPv4 multicast membership. There are three versions of the IGMP protocol: IGMPv1, IGMPv2, and IGMPv3. IGMP messages are encapsulated in IP messages, and the protocol type in the IP message header is 2.

[0183] A multicast gateway is a node in a public cloud platform consisting of one or a group of hosts that is responsible for forwarding multicast messages according to the forwarding table.

[0184] Intra-cloud multicast means that both the multicast source and multicast members are on the public cloud platform, and the transmission range of multicast messages is within the virtual network within the region;

[0185] Inter-cloud multicast means that the multicast source and multicast members can be located on the public cloud platform or in the user's offline IDC. The multicast source location is not limited to the public cloud region.

[0186] OVS is a virtual switch implementation software.

[0187] It is important to note that the construction and arrangement of the present application shown in a number of different exemplary embodiments are merely illustrative. Although only a few embodiments are described in detail in this disclosure, it should be readily understood by those who refer to this disclosure that many modifications are possible (e.g., the size, scale, structure, shape and proportion of various elements, as well as parameter values ​​(e.g., temperature, pressure, etc.), mounting arrangements, use of materials, color, changes in orientation, etc.) without departing substantially from the novel teachings and advantages of the subject matter described in this application. For example, an element shown as integrally formed may be composed of multiple parts or elements, the position of the element may be inverted or otherwise changed, and the nature or number or position of the discrete elements may be altered or changed. Therefore, all such modifications are intended to be included within the scope of this application. The order or sequence of any process or method steps may be changed or reordered according to alternative embodiments. In the claims, any "means plus function" clause is intended to cover the structure described herein that performs the function, and is not only structurally equivalent but also equivalent structures. Without departing from the scope of this application, other replacements, modifications, changes, and omissions may be made in the design, operating conditions, and arrangement of the exemplary embodiments. Therefore, the present application is not limited to the specific embodiments, but extends to various modifications that still fall within the scope of the appended claims.

[0188] Additionally, in order to provide a concise description of example embodiments, all features of an actual embodiment (ie, those features not relevant to the best mode presently contemplated for carrying out the application or those not relevant to implementing the application) may not be described.

[0189] It will be appreciated that in the development of any actual implementation, as in any engineering or design project, numerous implementation-specific decisions may be made. Such a development effort may be complex and time-consuming, but will be a routine task of design, fabrication, and production for those of ordinary skill having the benefit of this disclosure without undue experimentation.

[0190] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present application and are not intended to limit the present application. Although the present application has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present application may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present application, and all of these should be included in the scope of the claims of the present application.

Claims

1. A method for implementing intra-cloud and inter-cloud multicast functionality in a virtual instance in a public cloud, characterized in that: The method comprises the following steps: S1: Network architecture topology of multicast-related components. Compute nodes are interconnected with a multicast gateway cluster, which is responsible for forwarding multicast packets. The multicast gateway cluster is interconnected with a VGW cluster, which forwards multicast packets sent by dedicated lines to the multicast gateway based on multicast routing information. S2: Design an object model for multicast domains, multicast groups, and multicast members. In a user tenant, multicast resources are divided into multicast domains, multicast groups, and multicast members. A multicast domain is the range within which multicast data is transmitted. S3: The multicast member joins the multicast in the multicast domain; S4: On the compute node, the platform controller component intercepts and parses IGMP messages sent by multicast members in the tenant network. It then converts these messages into information about which multicast group the multicast member joins or leaves, which multicast sources it subscribes to, and which multicast domain it joins. S5: The flow table pipeline designed on the OVS on the compute node intercepts IGMP messages. The platform controller parses and processes the messages, converts them into actions, and reports them to the platform server. S6: After intercepting the IGMP protocol data message, parsing and converting it, it is sent to the controller, which then processes the message. S7: The cloud platform server adds the multicast member to the multicast group or removes the multicast member from the multicast group based on the received information; S8: In addition to processing the intercepted IGMP messages, the controller also periodically sends IGMP Member Query messages to the relevant virtual instances of the compute node based on the relationships between multicast members and multicast groups stored in the local controller cache. S9: Design of multicast gateway forwarding table; S10: Send the multicast data message.

2. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 1, wherein: In S1, if the multicast source and multicast members are both on the cloud, regardless of whether the multicast members are in the same VPC or different VPCs, the multicast data packets sent by the multicast source will be forwarded to the multicast gateway. The multicast gateway then generates a local forwarding table based on the relationship information between the multicast group and multicast members issued by the cloud platform. After receiving the multicast data packets, the multicast gateway forwards the multicast data packets to different multicast members according to the generated local forwarding table. Through the forwarding of the multicast gateway cluster, the multicast data packets sent by the multicast source are forwarded to the multicast members in the same VPC or different VPCs, and the multicast traffic outside the cloud is forwarded to the virtual instance in the cloud through the VGW gateway.

3. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 2, wherein: The multicast domain in S2 is divided into a static multicast domain and a dynamic multicast domain, which respectively represent the way in which multicast members join the multicast group under the multicast domain. In the static multicast domain, multicast members join the multicast group through a cloud platform interface call. In the dynamic multicast domain, multicast members join the multicast group through the IGMP protocol.

4. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 3, wherein: The model restriction relationship between tenants, multicast domains, VPCs, multicast groups, and multicast members is as follows: a tenant can create multiple multicast domains. Each multicast domain specifies the multicast range by setting one or more VPCs. The multicast group addresses in different multicast domains can be repeated, but a VPC can only join one multicast domain. Within a multicast domain, it can create multiple multicast groups with different group addresses. A multicast group can join multiple multicast members. When adding a multicast member to a multicast group, it can specify the multicast source address and subscribe to the multicast sources of interest and the multicast sources of no interest at the same time as specifying the multicast address.

5. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 4, wherein: The specific process of S3 is as follows: S301: The tenant first creates a multicast domain and then specifies one or more VPCs to define the multicast scope. VPCs can be specified when creating the multicast domain, or after the multicast domain is created, the VPC ID can be added to the list of VPCs added to the multicast domain to expand the multicast scope. When creating a multicast domain, the tenant also needs to specify how members of the multicast group in the multicast domain will join the multicast group, and whether the multicast group in the multicast domain is intra-cloud multicast or inter-cloud multicast. S302: If the multicast domain specifies that the method for multicast members in the multicast domain to join the multicast group is static joining, a multicast group needs to be created in the multicast domain, a multicast IP address needs to be specified, and then multicast members need to be added to the multicast group. S303: If the multicast domain specifies that the way for multicast members to join the multicast group under the multicast domain is dynamic joining, there is no need to create a multicast group; IGMPv2 or IGMPv3 join / leave group messages are sent in the virtual instance within the VPC range of the multicast domain. The cloud platform will automatically sense and analyze the IGMP protocol message on the host node where it is located to obtain the multicast IP information. If it is IGMPv3, it will also sense<S,G> The server automatically creates a multicast group and its members, and persists the data in the database according to the model relationship. S304: Specify any multicast source in the VPC in the multicast domain to send multicast message information. If a multicast group with the same multicast IP address as the multicast message sent by the multicast source has been statically or dynamically created in the multicast domain, all members of the multicast group can receive the multicast message from the multicast source.

6. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 5, wherein: The flow table program in S5 is specifically as follows: #dispatcher flow table: table={dispatcher},priority=1000,igmp,reg5=0x7ba2f, dl_dst=01:00:5e:00:00:00 / ff:ff:ff:80:00:00,nw_dst=224.0.0.0 / 4, actions=move:NXM_NX_REG5[0..23]->NXM_OF_ETH_DST[0..23],CONTROLLER:65535 #l2_lookup: #Multicast data message outgoing message table={l2_lookup},priority=2000,ip,reg5=0x339b9,dl_dst=01:00:5e:00:00:00 / ff:ff:ff:80:00:00 actions=mod_nw_ttl:64,goto_table:{l3_input} #Multicast data packets received by multicast members on this computing node #Add multicast processing representation multicast(table=61) between l2_lookup(table60) and ingressct(table70); mac:fa:16:3e:37:66:dd is the MAC address of a virtual instance of this computing node table={l2_lookup},priority=100,reg5=0xa8af8,dl_dst=fa:16:3e:37:66:dd actions=set_field:0xa8af8->tun_id,set_field:0x19f->reg7,goto_table:{multicast} # Multicast members are on this compute node, and the destination MAC address is changed to the multicast MAC address. mac: fa:16:3e:73:81:62 is the MAC address of the multicast member table={multicast},priority=1000,ip,reg5=0x52e1e,dl_dst=fa:16:3e:73:81:62,nw_dst=239.0.0.106actions=set_field:01:00:5e:00:00:6a->eth_dst,goto_table:{ingressct} table={multicast},priority=50actions=goto_table:{ingressct} #route: #Multicast routing table; fe:16:19:41:8e:67 is the MAC address of the linklocal port of mcgw table={route},priority=10004,ip,metadata=0x339b900000009,nw_dst=224.0.0.0 / 4 actions=set_field:fe:16:19:41:8e:67->eth_dst,set_field:0x339b9->reg5,dec_ttl,resubmit(,dispatcher); The note for NXM_NX_REG5 indicates that the NXM_NX_REG5 register stores the VNI value. The note for reg7 indicates that the reg7 register stores the ofport value of the virtual instance network card in ovs. Metadata is used to distinguish different subnets.

7. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 6, wherein: The controller obtains the virtual instance's joining / leaving group information by parsing the virtual instance's IGMP Membership Report message, or sends an IGMP Membership Query to query the information of the multicast group to which the virtual instance belongs, including the multicast message information received from the specified multicast source, and saves the relationship information between the multicast members and the multicast group in the local controller's cache, and then converts the information into a joining / leaving group message sent to the cloud platform, and then converts the message into a multicast member object requesting reporting to the cloud platform server.

8. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 7, wherein: The message structure is specifically expressed as follows: type MulticastMemUpdatedMsg struct{ ctx context.Context ofport uint32 / / The identification ID of the virtual instance on this host vni uint32 / / VNI of the virtual instance fixIp string / / fixIp of virtual instance mac string / / Mac of the virtual instance underlayIp string / / The underlayIP of the host where the virtual instance is located action int / / Action:0:updated;1:Leave groupAddresses map[string]*updateGroupInfo / / Multicast group address information carried by the virtual instance} 9. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 8, wherein: The multicast member object parameter in the request parameter reported to the cloud platform server is specifically represented as follows: typeMulticastMemberParam struct{ Vni uint32 `json:"port_vni"` FixIp string `json:"fix_ip"` Mac string`json:"mac_address"` UnderlayIp string`json:"underlay_ip"` Cookie uint64 `json:"cookie"` MulticastGroups[]*MulticastGroup`json:"multigroups"` } type MulticastGroup struct{ McGroupIp string`json:"multigroup_ip"` IncludeSips[]string`json:"include_sips"` ExcludeSips[]string`json:"exclude_sips"` Action int json:"action" / / update,leave JoinType int json:"join_type"` }。 10. The method for implementing intra-cloud and inter-cloud multicast functionality using a virtual instance in a public cloud according to claim 9, wherein: The attributes recorded in the multicast forwarding table designed in the multicast gateway include: Vni, GroupIp, Mask, SourceIp, RemoteVni, HostIp, VmIp, OverlayDmac, ExCount and ExcludeSip, and the specific meaning of each attribute is: Vni is the Vni of the VPC where the multicast source is located, GroupIp and Mask are the multicast group addresses of the multicast message, SourceIp is the multicast source address subscribed by the multicast member, RemoteVni, HostIp, VmIp, OverlayDmac are the Vni of the VPC where the multicast member joining the multicast group address is located, host IP, multicast member I p, and the mac address of the multicast member, ExcludeSip is the address list of the multicast source that the multicast member does not subscribe to, ExCount is the number of the multicast source address list that the multicast member does not subscribe to, and the S10 is specifically: the controller and VGW gateway on the computing node will obtain the multicast route of the VPC from the cloud platform Server service and forward the multicast message. For multicast communication between the IDC under the cloud and the multicast members on the cloud, after receiving the multicast member joining / leaving group information, the cloud platform Server will automatically send relevant configuration information to the border multicast switch or router of this region, and communicate and interact with the multicast router of the IDC under the cloud through the PIM-SM protocol to introduce multicast traffic into the cloud.

Images