Abstract:
A system and method for provisioning multicast groups based on broadcast domain participation includes a server. The server includes one or more multicast traffic producers collectively participating in a plurality of first broadcast domains and a multicast group including identifiers of other servers that participate in any of the first broadcast domains. Each of the multicast traffic producers participates in one or more of the plurality of first broadcast domains. The server is configured to direct multicast traffic associated with any of the first broadcast domains to each of the other servers identified in the multicast group.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 13/485,697 filed on May 31, 2012, the full disclosure of which is incorporated by reference herein in its entirety and for all purposes. 
     
    
     BACKGROUND 
       [0002]    1. Technical Field 
         [0003]    The present disclosure relates to multicast transmissions in a network virtualization environment and, in particular, to scaling the number of broadcast domains utilized for multicast transmissions in a network virtualization environment. 
         [0004]    2. Discussion of Related Art 
         [0005]    As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems. 
         [0006]    Sever virtualization is placing increasing demands on the physical network infrastructure. The number of MAC addresses available for utilization throughout the switched network may be insufficient to handle the potential attachment of the substantial increase in virtual machines (VMs), each with its own MAC address within the network. 
         [0007]    In some environments, the VMs may be grouped according to Virtual LAN (VLAN) associates. In a data center, there may be thousands of VLANs to partition traffic according to specific groups that a VM may be associated with. The current VLAN limit of 4094 may be wholly inadequate in some of these situations. In some cases, the Layer 2 network may scale across the entire data center or between data centers for efficient allocation of compute, network, and storage resources. Using traditional approaches such as the Spanning Tree Protocol (STPP) for a loop free topology can result in a large number of disabled links. 
         [0008]    Data centers host multiple tenants, each with their own isolated set of network domains. It is not economical to realize this type of structure over dedicated infrastructure for each tenant, and therefore shared networks are commonly utilized. Further, each tenant may independently assign MAC addresses and VLAN IDs leading to potential duplication on a physical network as a whole. 
         [0009]    One of the functions that places a large burden on such a network is multicasting in network virtualization environments. Multicasting to a group of nodes across the network may not be easily available with the networking hardware available. Further, multicasting may overburden the network with traffic being directed through many branches and arriving at unrelated nodes unnecessarily. 
         [0010]    Therefore, there is a need for network structures that allow for efficient usage of the physical network by multiple users each with multiple virtual machines. 
       SUMMARY 
       [0011]    In accordance with embodiments of the present invention, a method for handling multicast traffic is presented. A method of handling multicast traffic according to some embodiments of the present invention includes forming IP multicast (IPMC) groups of hypervisors based on broadcast domains; and directing multicast traffic from a broadcast domain on a source hypervisor to hypervisors that are members of the IPMC group. 
         [0012]    An information handling system according to some embodiments of the present invention includes an ingress table that directs network traffic according to a hypervisor association; and an egress table that directs network traffic according to the hypervisor association. 
         [0013]    These and other embodiments will be described in further detail below with respect to the following figures. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]      FIG. 1  illustrates at a high level IP multicast for Level 2 (L2) Broadcast Traffic. 
           [0015]      FIG. 2  illustrates a network environment according to some embodiments of the present invention. 
           [0016]      FIG. 3  illustrates a network environment according to some embodiments of the present invention. 
           [0017]      FIG. 4  illustrates distribution of table construction in a network environment such as that illustrated in  FIG. 2 . 
           [0018]      FIG. 5  illustrates IPMC table construction according to some embodiments of the present invention. 
           [0019]      FIGS. 6A and 6B  illustrate a packet transport through a network configure according to some embodiments of the present invention. 
       
    
    
       [0020]    The drawings may be better understood by reading the following detailed description. 
       DETAILED DESCRIPTION 
       [0021]    Embodiments of the present invention typically operated within Layers 2 and 3 of the network, although other layers may also be included. Layer 2 refers to the data link and involves encoding and decoding individual data packets. Layer 2 furnishes the transmission protocol knowledge and management and handles errors in the physical layer, flow control and frame synchronization. Layer 3 is the network layer and provides switching and routing for the packets of Layer 2. 
         [0022]    For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components. 
         [0023]      FIG. 1  illustrates a common network environment  100 . Network environment  100  includes several information handling systems, including routers and switches. As shown in  FIG. 1 , a router  110  routes network traffic to a number of network virtualization enabled servers, of which servers  102 ,  104 , and  106  are illustrated. Router  110  may represent both routers and switches and may include the top-of-rack (TOR) switches coupled to servers  102 ,  104 , and  106 . Each of servers  102 ,  104 , and  106  may host a large number of virtual machines (VMs), of which a small number are illustrated in  FIG. 1 . As shown in  FIG. 1 , server  102  includes VMs  108 - 1  through  108 -N 1 ; server  104  includes VMs  110 - 1  through  110 -N 2 ; and server  106  includes VMs  112 - 1  through  112 -N 3 . N 1 , N 2 , and N 3  can be any integer number. It should be noted that not all of the VMs on a particular server are associated with the same tenant. Further, VMs for a particular tenant may be distributed across multiple ones of servers  102 ,  104 , and  106 . 
         [0024]    Each of servers  102 ,  104 , and  106  includes a hypervisor. The hypervisor controls access by each of the virtual machines on the server to the resources of the server. The hypervisor further assures that security between virtual machines operating on the server is observed and directs network traffic to individual ones of the virtual machines. 
         [0025]    Additionally, each of the VMs can be classified by subscription to various broadcast domains. A multicast from one VM to a particular broadcast domain may result in network traffic throughout network environment  100 . The resulting high volume of network traffic, much of which may be directed towards non-recipients, can substantially slow network environment  100 . With multicast protocols, network virtualization technologies require highly scalable multicast capabilities because of the large number of tenant broadcast domains. Traditional network protocols may not scale sufficiently to handle multicast communications on a network environment such as environment  100 . Further, hardware support for a bi-directional Protocol Independent Multicast (BiDir PIM) suite of routing protocols may not be available. 
         [0026]      FIG. 2  illustrates a network environment  200  according to some embodiments of the present invention. As shown in  FIG. 2 , network virtualization servers  202 ,  204 , and  206  are coupled to Top-of-Rack (TOR) switches  208 ,  210 , and  212 , respectively. TOR switches  208 ,  210 , and  212  are each coupled to Aggregators  214  and  216 . Aggregators  214  and  216  are coupled to core routers  218  and  220 . As shown in  FIG. 2 , each of servers  202 ,  204 , and  206  are coupled to NV (broadcast domain) provisioning system  222 .  FIG. 2  may illustrate a portion of a much larger networking environment. 
         [0027]    A virtual machine on server  206  may communicate with a virtual machine on server  202 , for example, through TOR  212 , one of aggregators  214  and  216 , potentially through one or both of core routers  218  and  220 , and then back down to TOR  208  and finally into server  202 . Multicast transmissions originating from a virtual machine on any of the servers  202 ,  204 , and  206  is distributed through network environment  200  to other virtual machines that are part of the same broadcast domain. 
         [0028]    NV provisioning system  222  tracks and records broadcast domain membership information. As shown in  FIG. 2 , NV provisioning system  222  can learn the broadcast domain information by extracting or learning from tables in environment  200  that control routing of multicast traffic. Further, provisioning system  222  can snoop the Internet Group Management Protocol (IGMP) network traffic at an edge switch, for example at TORs  208 ,  210 , and  212 . By listening to the conversations between servers  202 ,  204 , and  206  and TORs  208 ,  210 , and  212 , respectively, provisioning system  222  can maintain a map of network domains for multicast traffic and multicast traffic can be filtered to go to the domains that include members, and not to domains that do not have recipient members. This can prevent the flooding of network environment  200  with multicast traffic directed toward limited numbers of recipients. 
         [0029]    The conventional method of providing a broadcast distribution is to create an IP multicast group (IPMC) per broadcast domain. However, as provided in some embodiments of the present invention, to more efficiently utilize network environment  200  IP multicast groups may be defined in terms of physical server or hypervisor connectivity. 
         [0030]    Network environment  200  may include any number of network broadcast domains, which can be designated by the set of broadcast domains {NV 1 , NV 2 , NV 3 , . . . }. The hypervisor on each of servers  202 ,  204 , and  206  can thereby participate in any number broadcast domains in the set of broadcast domains. Therefore, a list of broadcast domains in which a particular hypervisor H i  participates can be created, where H i  denotes a hypervisor operating on one of the servers such as servers  202 ,  204 , or  206 , for example. The list for each hypervisor H i  is, then, H i ={NVa, NVb, NVc . . . }, where NVa, NVb, and NVc are broadcast domains that are elements of the set of broadcast domains {NV 1 , NV 2 , NV 3  . . . } in which hypervisor H i  participates. It should be noted that hypervisor H i  participates in a broadcast domain NV d  if any of the virtual machines of hypervisor H i  are members of broadcast domain NV d . 
         [0031]    In some embodiments, IP multicast groups G i  can then be created based on the basis of interacting hypervisors H i . In particular, if the intersection of the set of broadcast domains associated with H j  and the set of broadcast domains associated with H i  is not a null set (zero) ({H i ∩H j }≠{0}} then H i  receives multicasts (*,G j ) and H j  receives multicasts (*,G i ). The group G i  includes hypervisor H j  and the group G j  includes hypervisor H i . In other words, H i  and H j  belong to the same hypervisor group and multicasts sent from a domain associated with H i  get sent to H j  and multicasts sent from a domain associated with H j  get sent to H i . The number of multicast groups in the core and aggregation layer (cores  218  and  220  and aggregators  214  and  216  in  FIG. 2 ) are equal to the number of hypervisor instances in the network independent of the number of broadcast domains represented. Traffic to individual virtual machines can then be handled by the hypervisor itself once it receives traffic directed to that hypervisor. 
         [0032]    In this fashion, the number of groups G in the core and aggregation layers can be kept to a reasonable number and a course multicast distribution method can be implemented. Each of the routers, for example TORs  208 ,  210 , and  212 , aggregators  214  and  216 , and cores  218  and  220  in  FIG. 2 , keeps a table of all of the groups so that multicasts (*,G) messages are routed to the appropriate hypervisors accordingly. Additionally, since the traffic for a particular multicast group is generated by a particular hypervisor instance (e.g., traffic for group G i  is generated by hypervisor H i , which is operating on a particular server), a source specific multicast tree can be calculated. 
         [0033]    In some cases, certain broadcast domains may carry heavy broadcast traffic loads. In such cases, receipt of network traffic by unintended receivers for those broadcast domains is not efficient. For example, consider the case where the set of broadcast domains for hypervisor H i ={NV a , NV b } and the set of broadcast domains for hypervisor H j ={NV a , NV c }. In that case, hypervisor H i  is a member of broadcast group G j  and therefore hypervisor H i  receives (*, G j ) traffic. However, that means that hypervisor H i  receives broadcast traffic from the broadcast domain NV c , even though hypervisor H i  does not include broadcast domain NV c . Hypervisor H i  then processes, and ultimately drops, the traffic from broadcast domain NV c . If broadcast domain NV c  carries heavy broadcast traffic, hypervisor H i  may be overburdened by the need to process and discard this traffic. 
         [0034]    In some embodiments, dedicated distribution trees can be developed. In this case, (*,G) can be listed in intermediate routers and (S,G), where S indicates source, in edge routers. The sending hypervisor server can choose one of the multiple unicast IP addresses as an IP source address in the encapsulation of the L2 multicast broadcast packet. In some embodiments, there may be a default IP source address unless that address is specified by a particular tenant. In either case, intermediate routers (e.g., aggregation and core routers) keep the (*,G) entries for scalability purposes. Edge routers, however, may keep an (S, G) table to enable fine grain broadcasts. This edge router behavior can be in TORs  208 ,  210 , or  212  or may be in a virtual switch of servers  202 ,  204 , or  206 , or performed between a combination of edge routers. 
         [0035]    In that fashion, the final edge router can perform a tenant ID inspection in the packet and perform the appropriate broadcast. In this fashion, unwanted broadcast traffic can be avoided with a fine grain multicast distribution. In some embodiments, some broadcast domains can have dedicated IP multicast sessions (S,G) in the network and these sessions may utilize source specific multicast trees. 
         [0036]    In some embodiments, dedicated distribution trees can be avoided. Unintended hypervisor receivers of broadcast domains can be eliminated if the sending and receiving hypervisors have the same network virtualization broadcast domains. Consider the case where hypervisor H i ={NVa, NVb} and hypervisor H j ={NVa, NVb, NVc}. As discussed above, H i  is a member of group G j  and therefore H i  is a receiver of (*, G j ) traffic. Therefore, broadcast traffic for NV c  reaches H i . However, because all of the broadcast domains in H i  are also members of H j , H j  will not receive unintended traffic from H i . 
         [0037]      FIG. 3  illustrates another networking environment  300  according to some embodiments of the present invention. As shown in  FIG. 3 , network environment  300  includes spines  310  and  320 . Each of spines  310  and  320  are coupled to leafs  330 ,  340 , and  350 . Leafs  330 ,  340 , and  350  are each coupled to a group of servers. Leaf  330  is coupled to server group  360 , leaf  340  is coupled to server group  370 , and leaf  350  is coupled to server group  380 . Server group  360  includes servers  362 ,  364 , and  366 . Server group  370  includes servers  372 ,  374 , and  376 . Server group  382  includes servers  382 ,  384 , and  386 . Each of the servers includes a hypervisor. It should be noted that there may be any number of individual servers coupled to each of leafs  330 ,  340 , and  350 . Further there may be any number of leafs coupled to any number of spines. 
         [0038]    Hypervisors in a rack can participate in an infinite number of network virtualized broadcast domains and can communicate with a number of other hypervisors equal to the IPMC table size in the top-of-rack component, in  FIG. 3  leafs  330 ,  340 , and  350 . Spines  310  and  320  can scale out multicast sessions by effective distribution. For example, Spine  310  can include distribution tables {IPMCa, IPMCb, IPMCc} while Spine  320  can include distribution tables {IPMCx, IPMCy, and IPMCz}. The distribution sets in Spine  310  and Spine  320  can be different, or may overlap. Consequently, the total IPMC table size is equal to Count Of {Spine  310  tables U Spine  320  tables}. 
         [0039]      FIG. 4  illustrates organization of IPMC tables according to some embodiments of the present invention. As illustrated in  FIG. 4 , NV provisioning system  222  tracks the multi-cast groups on broadcast domains as discussed above. Further, provisioning system  222  keeps track of IGMP group joins and pruning of broadcast domains in TORs  208 ,  210 , and  212 . The IPMC distribution tables can be kept and distributed at aggregators  214  and  216 . 
         [0040]      FIG. 5  illustrates table construction at each of the levels of network environment  200 . As shown in  FIG. 5 , servers  202 ,  204 , and  206  keep a table  502  that includes relationships for network traffic in both egress (out of server the server) and ingress (into the server) direction. As shown in  FIG. 5 , in table  502  associated with the hypervisor of server  202  traffic from virtual machines VM 1   510  and VM 3   512 , both of which are in related network domains, point to (S1, G1). In table  502 , Egress traffic from (S1, G1) is linked to virtual machines VM 1   510  and VM 3   512 , which belong to the same network domains. The ingress part of table  502  lists traffic to (S1, G1) from Broadcast Domain VLAN x (BRCT Vx). Table  504  is provided in TOR  208 , which is coupled to server  202 . In Table  504 , the ingress path is listed such that (*, G1) is directed to paths Port a, VLAN×(Pa, Vx), and port b VLAN y (Pb, Vy), for example. The egress path is listed such that (S1, G1) is directed to the same physical and virtual address (Pa, Vx), (Pb, Vy). Table  506 , which is provided in aggregator  214 , includes the table entry (*,G1) directed to (Pa, Vx), (Pb, Vy). Further, Table  508 , which is provided in core  218 , includes the table entry (*, G1) which directs to (Pa, Vx), (Pb, Vy). 
         [0041]      FIGS. 6A and 6B  illustrate a packet walk through network environment  200  according to some embodiments of the present invention.  FIGS. 6A and 6B  illustrate a multicast packet originating at virtual machine  602 , which resides on server  202 . The packet is received by virtual machine  604 , which resides on server  206 . 
         [0042]    As shown in  FIG. 6A , packet  606 , which is generated by virtual machine  602 , is encapsulated into packet  608  by server  202 . Packet  608  includes packet  606  in its payload version, and adds a tenant ID T1, sets the destination address as G1 (the group associated with the hypervisor on server  202 ), and sets the source address to S1 according to the ingress lookup table on server  202 . Packet  608  is then transmitted to TOR  208 . TOR  208  utilizes the ingress lookup table for (*, G) and transmits packet  610  to aggregator  214 . Aggregator  214  utilizes the ingress lookup table (*,G) and transmits packet  612  to core  218 . Core  218  utilizes the lookup table (*, G) and transmits packet  614  to core  220 . As shown in  FIG. 6A , packets  608 ,  610 ,  612 , and  614  are the same and are routed through environment  200  according to the appropriate look-up tables. 
         [0043]    As shown in  FIG. 6B , core  220  utilizes lookup table (*, G) and transmits packet  616  to aggregator  216 . Aggregator  216  utilizes lookup table (*, G) and transmits packet  618  to TOR  212 . TOR  212  checks lookup table (S, G) and transmits packet  620  to server  206 . Server  206  then checks the tenant ID, and unpacks packet  620  to retrieve packet  624 . Server  206  then transmits packet  624  to virtual machine  604 . 
         [0044]      FIGS. 6A and 6B  provide an example of the rout of a multicast transmission from virtual machine  602  to virtual machine  604  according to some embodiments of the present invention. One skilled in the art will recognize that other routing paths through environment  200  are available for transmissions between virtual machines  602  and  604 . 
         [0045]    In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the invention as set for in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.