Multicast technology is being increasingly favored to provide rich content over a network. Multicast is a mechanism for transmitting data from a single source (for example, a server) to multiple receivers (for example, personal computers) on a network. Multicast packets are replicated down appropriate paths in a network to create the most efficient routing mechanism possible. The sender may send a data packet once, even if the packet is to be delivered to multiple receivers.
The following detailed description references the drawings, wherein:
Multicast technology may be used by organizations to send data (especially, multimedia content) over a network. Multicast technology may allow host computer systems, who have subscribed to a particular content data flow of a content server, to receive the content. Host systems may signify their willingness to receive a particular data from a content server by joining a particular multicast group. Once host systems join a particular group, a multicast distribution tree may be created for that group. The flow of data from a multicast source system to receiver devices may be managed by a multicast protocol. Some non-limiting examples of protocols that may be used to manage flow of data in a multicast system may include Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD) protocol, Protocol Independent Multicast (PIM), and Distance Vector Multicast Routing Protocol (DVMRP).
IP multicast may allow content providers to offer high quality service to customers while efficiently utilizing network bandwidth. However, a multicast deployment may face scaling challenges. The number of new devices that are getting included in an enterprise network are increasing every day. For example, Bring Your Own Device (BYOD) concept or Internet of Things (IoT) devices are putting additional constraints on the existing multicast resources. In an example deployment of an IP multicast protocol in a LAN, the protocol application may maintain the multicast group information and program the hardware filters on network devices to define the multicast data traffic behavior. Hardware filters may be provided as a port map where the intended ports to receive the multicast traffic are programmed. The number of hardware filters in a network device may be limited by the ASIC type. However, there's no limit on the number of multicast groups (for example, standard or static multicast groups) that may be added to a network device (e.g., a network switch). As per current behavior, whenever an IGMP/MLD join is received for a new group, a new hardware filter is allocated. As every individual group consumes a filter, the number of joins that are supported is limited by the number of filters available in a network device. A large number of IGMP join messages may lead to hardware filter exhaustion and device failure in the event of a crash. This is not a desirable scenario.
To address this issue, the present disclosure describes various examples for managing multicast scaling. In an example, a determination may be made at a network device (e.g., a network switch) whether more than a pre-defined percentage of ports of a virtual LAN (VLAN) are associated with an IP multicast group. In response to the determination that more than a pre-defined percentage of ports on the VLAN are associated with the IP multicast group, a flood filter may be programmed on the network device for the VLAN. And, a hardware filter previously associated with the IP multicast group may be disassociated. The proposed solution provides a mechanism for optimizing hardware filters in a network device.
Source system 110, network device 112, and client computing devices 118 and 120, may be communicatively coupled, for example, via a computer network 130. Such a computer network 130 may be a wireless or wired network. Such a computer network 130 may include, for example, a Local Area Network (LAN), a Wireless Local Area Network (WAN), a Metropolitan Area Network (MAN), a Storage Area Network (SAN), a Campus Area Network (CAN), or the like. Further, such a computer network 130 may be a public network (for example, the Internet) or a private network (for example, an intranet). In an example, computer network 130 may be an IPv4 or IPv6 network. In an example, computer network 130 may be used to transmit and route multicast content.
Source system 110 may be any type of computing device capable of reading machine-executable instructions. Examples of the computing device may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like. In an example, source system 110 may host multicast content. Multicast content may include, for example, data, image, audio, video, multimedia, and other like content. Multicast content may be shared with host computer systems (also known as multicast subscribers) through network device 112.
Network device 112 may include, for example, a router, a virtual router, a network switch, and a virtual switch. In an example, network device 112 may be a multicast router. Network device 112 may be used to route multicast data from source system 110 to a client computing device(s) (for example, 118 and 120).
In an example, network device 112 may include a plurality of hardware filters. The number of hardware filters in a network device may be limited by the ASIC type. In an example deployment of an IP multicast protocol in a LAN, the protocol application may maintain the multicast group information and program the hardware filters on network device 112 to define the multicast data traffic behavior. The number of hardware filters available on a network device (for example, 112) to process IP multicast messages (for example, a join message) may depend on the type of network device. In an example, up to 2048 hardware filters may be available on network device 112 for processing IP multicast messages of an IP multicast protocol (for example, IGMP and MLD). If multiple VLANs are configured, each filter may be counted once per VLAN in which it is used. Hardware filters may be provided as a port map where the intended ports to receive the multicast traffic are programmed. Network device 112 may support a plurality of VLANs.
Client computing devices 118 and 120 may each be any type of computing device that is capable of executing machine-readable instructions. Examples of the computing device may include, without limitation, a server, a desktop computer, a notebook computer, a tablet computer, a thin client, a mobile device, a personal digital assistant (PDA), a phablet, and the like. Client computing devices 118 and 120 may each include a client or multicast application for receiving multicast data from a source system (for example, 110).
Multicast technology may allow client computing devices (for example, 118 and 120), who may have subscribed to a particular content data flow of a source system (for example, 110), to receive content from the source system. Client devices (for example, 118 and 120) may signify their willingness to receive a particular data from a content server by joining a particular multicast group. Once client devices join a particular group, a multicast distribution tree may be created for that group. The flow of data from a multicast source system to receiver devices over network 130 may be managed by a multicast protocol. Examples of multicast protocol may include Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) protocol.
IGMP and MLD may be used between client computing devices (for example, 118 and 120) and a multicast router (for example, 112) to request data for a given multicast group. Routers may use IGMP or MLD to build their multicast routing table.
The Internet Group Management Protocol (IGMP) is an Internet protocol that may be used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to any neighboring multicast routers. The protocol may be used between end systems (hosts) and a multicast router to request data for a given multicast group.
Multicast Listener Discovery (MLD) protocol is a component of the Internet Protocol Version 6 (IPv6) suite. MLD may be used by IPv6 routers for discovering multicast listeners on a directly attached link, much like IGMP is used in IPv4.
Protocol Independent Multicast (PIM) is a family of multicast routing protocols for Internet Protocol (IP) networks that provide one-to-many and many-to-many distribution of data over a network. PIM is not dependent on a specific unicast routing protocol. PIM can make use of any unicast routing protocol in use on the network.
In an example, network device 112 may include a determination engine 132, a program engine 134, and a filter engine 136.
Engines 132, 134, and 136 may each include any combination of hardware and programming to implement the functionalities of the engines described herein. In examples described herein, such combinations of hardware and software may be implemented in a number of different ways. For example, the programming for the engines may be processor executable instructions stored on at least one non-transitory machine-readable storage medium and the hardware for the engines may include at least one processing resource to execute those instructions. In some examples, the hardware may also include other electronic circuitry to at least partially implement at least one engine of network device 112. In some examples, the at least one machine-readable storage medium may store instructions that, when executed by the at least one processing resource, at least partially implement some or all engines of network device 112. In such examples, network device 112 may include the at least one machine-readable storage medium storing the instructions and the at least one processing resource to execute the instructions.
In an example, determination engine 132 on network device 112 may determine whether more than a pre-defined percentage of ports of a virtual LAN (VLAN) are associated with an IP multicast group. VLAN technology may allow an enterprise to extend the reach of their corporate networks across a Wide Area Network (WAN). VLANs may enable a LAN to be partitioned based on functional requirements while maintaining connectivity across all devices on a network. VLAN groups network devices and enables them to behave as if they are in one single network.
In an example, determination engine 132 may carry out the determination by first identifying ports of a VLAN. Determination engine 132 may identify which of the VLAN ports are associated with an IP multicast group. Determination engine 132 may then identify the total number of VLAN ports associated with the IP multicast group, and use the identified number to determine the percentage of VLAN ports that are associated with an IP multicast group. Determination engine 132 may compare the determined percentage with a pre-defined percentage to determine whether the number of VLAN ports associated with an IP multicast group is more than the pre-defined percentage.
In an example, determination engine 132 may identify a VLAN port associated with an IP multicast group by determining whether the port has received an IGMP join message. When an IGMP client connected to a switch port wants to receive multicast traffic from a specific group, it may join the group by sending an IGMP join message to the network. In another example, determination engine 132 may identify a VLAN port associated with an IP multicast group by determining whether the port has received a MLD protocol join message. Hosts may join multicast groups by sending MLD report messages (join messages). In a further example, determination engine 132 may identify a VLAN port associated with an IP multicast group by detecting an IGMP querier on the port. If there is no multicast router in a VLAN to originate the queries, an IGMP snooping querier may be configured to send membership queries. An IGMP snooping querier may send out periodic IGMP queries that trigger IGMP report messages from hosts that want to receive IP multicast traffic. In a still further example, determination engine 132 may identify a VLAN port associated with an IP multicast group by detecting a PIM router on the port.
In response to a determination that more than a pre-defined percentage of ports on the VLAN are associated with the IP multicast group, program engine 134 may program a flood filter on network device for the VLAN. As used herein, a flood filter may refer to a global filter with all ports set. The flood filter may flood a received IP multicast packet to each port of network device 112 except the port it came in from.
In an example, determination engine 132 may determine whether more than a pre-defined percentage of ports of a VLAN are associated with an IP multicast group by comparing a port map of the VLAN with a port map of the hardware filter previously associated with the IP multicast group. If the port map of the VLAN and the port map of the hardware filter previously associated with the IP multicast group are same, program engine 134 may program a flood filter on network device for the VLAN. As used herein, a port map may include a list of outbound ports for forwarding data (for example, IP multicast data). In another example, if a new IGMP join message is received on a new port, or if a port is moved out of a VLAN, program engine 134 may program a flood filter on network device for the VLAN, if more than a pre-defined percentage of ports of a VLAN are associated with an IP multicast group.
After a flood filter has been associated with the VLAN, filter engine 136 may disassociate a previously associated hardware filter from the IP multicast group. Thus, a hardware filter that was earlier associated with the IP multicast group may be disassociated from the IP multicast group by filter engine. The previously associated hardware filter may include a hardware filter on network device that is reserved for managing data traffic related to the IP multicast group. The data traffic may relate to an IP multicast protocol. Disassociating the hardware filter may enable the released hardware filter to be used for another task, for example, for another IP multicast group.
Network device 200 may be, for example, a router, a virtual router, a network switch, and a virtual switch. In an example, network device 200 may be a multicast router. Network device 200 may be used to route multicast data from a source system to client computing device (i.e. multicast receivers).
In an example, network device 200 may include a determination engine 232, a program engine 234, and a filter engine 236. In an example, determination engine 232, program engine 234, and filter engine 236 may perform functionalities similar to those described earlier in reference to determination engine 132, program engine 134, and filter engine 136 of
In an example, determination engine 232 may determine whether more than a pre-defined percentage of ports of a virtual LAN (VLAN) are associated with an IP multicast group. In response to a determination that more than the pre-defined percentage of ports on the VLAN are associated with the IP multicast group, program engine 234 may program a flood filter for the VLAN. Filter engine 236 may then disassociate a previously associated hardware filter from the IP multicast group.
At block 304, in response to the determination that more than a pre-defined percentage of ports on the VLAN are associated with the IP multicast group, a flood filter may be programmed on the network device for the VLAN. At block 304, a hardware filter previously associated with the IP multicast group may be disassociated.
For the purpose of simplicity of explanation, the example methods of
It should be noted that the above-described examples of the present solution is for the purpose of illustration. Although the solution has been described in conjunction with a specific example thereof, numerous modifications may be possible without materially departing from the teachings of the subject matter described herein. Other substitutions, modifications and changes may be made without departing from the spirit of the present solution. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the parts of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or parts are mutually exclusive.