Patent ID: 12237938

DETAILED DESCRIPTION

FIG.1is a block diagram illustrating an embodiment of an Internet Group Management Protocol (IGMP) network10. As shown, the IGMP network10includes a server12, a router14, one or more switches16-1,16-2, . . . ,16-m(e.g., Layer 2 (L2) switches), and a plurality of hosts18-1,18-2, . . . ,18-n. In some embodiments, the IGMP network10may include multiple routers14. The router14includes a plurality of interfaces20-1,20-2, . . . ,20-mconfigured for communication with each of the respective switches16-1,16-2, . . . ,16-mto enable multicasting to different switches16based on various membership criteria.

The server12may be configured as a local server, cloud edge server, etc.; the router14may be configured as an IGMP querier device; and the switches16may be configured as IGMP snooping devices. In some embodiments, the router14may be configured as both an IGMP querier device and an IGMP snooping device. In some embodiments, the router14, switches16, and hosts18may be part of a Virtual Local Area Network (VLAN)22or multiple VLANs (e.g., L2 VLANs).

The protocols defined with respect to IGMP and IP multicasting (e.g., the RFCs described above) may be configured to operate in Layer 3 (L3), such that L2 snooping can be performed in parallel with L3 operation to snoop on L3 IGMP activity. It may be noted that this snooping is not specifically defined by the IGMP protocol.

FIG.2shows an example of a timing sequence24in which the transmissions of messages and data throughout the IGMP network10are depicted. Upon the occurrence of a reboot (or restart) procedure, the components of the VLAN22are configured to exchange messages to re-enter configuration data into hardware or memory of the router14and/or switch16to enable the system to resume multicast streaming services that had been interrupted by the reboot procedure. That is, the router14, a corresponding switch16, and a corresponding set of hosts18can share messages to allow the router14to determine which hosts18are currently members of the FD (or host group) for receiving multicast streams. For example, the reboot procedure may correspond to a restart of the entire VLAN22, a restart of one or more components (e.g., the router14, a corresponding switch16, etc.) of the VLAN22, a restart of a software package, a restart of a software container, a restart after a node upgrade or firmware download, or a restart of other types of related hardware or software components operating in the VLAN22.

A first set of messages26is sequentially transmitted from the router14to the switch16as General Query (GQ) IGMP messages. This first set of messages26is labelled GQ1, GQ2, . . . , GQx, where x is equal to the number of FDs, and where each FD represents a host group membership for receiving specific multicast streams. It may be noted that GQ1is transmitted first, followed by GQ2, and so on until all GQs are transmitted to the L2 switch16. Upon receiving GQ1, GQ2, . . . , GQx, the switch16is configured to forward a second set of messages28, which include the GQ1, GQ2, . . . , GQx messages, to the hosts18to query the hosts18as to whether each of the hosts18wishes to remain as a member of one or more FDs, if the host18wishes to join one or more FDs, and/or if the host18wishes to leave one or more FDs.

The hosts18then replies to the requests (e.g., second set of messages28) with a third set of messages30, which is defined as Membership Report (MR) messages for reporting the membership status of the respective hosts18. As shown, the x hosts18associated with the FD sends MR1, MR2, . . . , MRx, respectively to the switch16. Thereafter, the switch16sends the MR1, MR2, . . . , MRx messages as a fourth set of messages32to the router14. At this point, the router14is configured to process the response or MR messages to determine which hosts18are members of the various FDs. Then, the router14is configured to send request messages as a fifth set of messages34to the server12to enable the server12to continue the process of streaming the multicast data36to the hosts18according to the updated membership criteria that has be rediscovered following the reboot procedure.

It may be noted from the timing sequence24ofFIG.2that there may be a significant amount of delay from the transmission of the first set of messages26to the actual streaming of the multicast data36. This is the delay that is caused by the order in which the router14(querier) starts generating the query. The larger the scale of the VLAN, the greater the delay.

Therefore, the present disclosure is configured to reduce the delay, particular for higher-priority multicast streams. As suggested above, the conventional systems use an arbitrary configuration scheme to order each of the sets of messages26,28,30,32,34. Therefore, higher priority queries (e.g., GQs26,28), responses (e.g., MRs30,32), and requests34may be transmitted after lower priority queries, responses, and requests. As such, this may lead to important streams being dropped or delayed beyond an acceptable time lag. The systems and methods of the present disclosure are therefore configured to reorder the messages26,28,30,32,34(e.g., queries, responses, and requests) according to a “predetermined priority.” Thus, the present disclosure defines the use of a novel “priority field” that can be used in association with an IGMP environment to prioritize multicast streams, and therefore optimize the timeliness of higher-priority streams.

Again, the conventional systems do not provide any solutions with respect to “prioritizing” multicast streams at the router14(e.g., IGMP querier device) and/or switch16(e.g., L2 IGMP snooping device). Thus, with un-prioritized streams and no way to enter configuration data in the querier device, the router14of the conventional systems may add undesired delay during session stabilization (after a rebooting procedure) for the higher-priority multicast streams. Therefore, as explained in more detail below, the systems and methods of the present disclosure are configured to reorder the GQs26,28, MRs30,32, and streaming requests34to expedite the higher priority streams. Therefore, rather that order the 1 through x messages in an arbitrary manner, the present disclosure describes embodiments in which the messages can be rearranged to provide an order where the highest priority streams are handled first, followed by the next highest priority streams, and so on to the lowest priority streams. Since hardware resources may usually be limited and since a VLAN may include multiple subscription and/or streaming memberships, the router14is configured to handle the messages based on priority such that if any “join” messages are dropped, because of insufficient hardware, only the lowest priority messages would be dropped and the higher priority messages would be preserved.

Also, at the switch16(e.g., IGMP snooping device), after the reboot/restart procedure, prolonged flooding may be observed, until the hardware entries are complete, which may result in higher bandwidth consumption and may threaten network information security (e.g., Denial of Service (DoS), Distributed DoS (DDoS), etc.) for important streams. These issues may have a greater impact in the case of a scaled setup when there are dozens or hundreds of IGMP querier interfaces20and corresponding IGMP snooping devices (e.g., switches16) enabling multiple FDs.

FIG.3is a block diagram illustrating an embodiment of a router40(e.g., the router14) configured as an IGMP querier device, as is described with respect toFIGS.1and2. In the illustrated embodiment, the router14may be a digital computing device that generally includes a processing device42, a memory device44, Input/Output (I/O) interfaces46, a network interface48, and a database50. It should be appreciated thatFIG.3depicts the router40in a simplified manner, where some embodiments may include additional components and suitably configured processing logic to support known or conventional operating features. The components (i.e.,42,44,46,48,50) may be communicatively coupled via a local interface52. The local interface52may include, for example, one or more buses or other wired or wireless connections. The local interface52may also include controllers, buffers, caches, drivers, repeaters, receivers, among other elements, to enable communication. Further, the local interface52may include address, control, and/or data connections to enable appropriate communications among the components42,44,46,48,50.

It will be appreciated that some embodiments described herein may include or utilize one or more generic or specialized processors (“one or more processors”) such as microprocessors; Central Processing Units (CPUs); Digital Signal Processors (DSPs): customized processors such as Network Processors (NPs) or Network Processing Units (NPUs), Graphics Processing Units (GPUs), or the like; Field-Programmable Gate Arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application-Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry configured to,” “logic configured to,” etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Moreover, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming a computer, server, appliance, device, at least one processor, circuit/circuitry, etc. to perform functions as described and claimed herein. Examples of such non-transitory computer-readable medium include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by one or more processors (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause the one or more processors to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

In some embodiments, the router14may include an IGMP prioritizing program54, which may be implemented in any suitable combination of software and/or firmware in the memory device44and/or hardware of the processing device42. The IGMP prioritizing program54may include logic, code, and/or instructions for enabling the processing device42to perform various prioritization processes as described in the present disclosure for prioritizing higher classes of multicast streams using any number of classification levels. In particular, the IGMP prioritizing program54may be configured to prioritize the VLAN22on a number of levels, such as:I. IGMP querier interface level;II. IGMP querier multicast stream level (based on the interface of level I);III. Forwarding Domain (FD) level of the IGMP snooping device; andIV. Multicast streaming level (based on the FD of level III).
It may be noted that the first two levels are related to configuring the router14(e.g., IGMP querier device) and the last two levels are related to configuring the switch16(e.g., IGMP snooping device).
I. Configuring the Interfaces of the IGMP Querier Device

To overcome the problems with the conventional systems, the router40provides a solution based on a priority field that allows a user to enter a value per querier interface and per multicast group level (FIG.5). The below code is an example of sample configuration data for defining three classes of priority (i.e., a “platinum” class, a “diamond” class, and a “gold” class):

config# igmp querier instance <instance-name>interfaces interface <interface-name>priorityclass-platinumclass-diamondclass-gold

FIG.4is a flow diagram illustrating an embodiment of a process60for creating a first set of databases to be used to prioritize the interfaces20-1,20-2, . . . ,20-mof the router14shown inFIG.1or interfaces of the router40ofFIG.3. The process60includes the step of receiving a request to configure a router as an IGMP querier in an IGMP environment, as indicated in block62. Alternatively, if the router is already configured as an IGMP querier, block62may include modifying the router as needed based on a request to do so. The request may be a user request to establish the router in a VLAN as an IGMP querier.

The process60further includes determining if the querier is to be configured with the highest level of classification (e.g., “platinum”), as indicated in the condition block64. If so, the process60goes to block66, which includes the step of creating or updating an entry in a platinum-class database that the querier is to be configured with this priority level, and then the process60goes to block74. If it is determined in condition block64that the classification is not platinum, then the process60goes to condition block68, which includes the step of determining if the querier is to be configured with a next highest level of classification (e.g., “diamond”). If so, the process60goes to block70, which includes the step of creating or updating an entry in a diamond-class database that the querier is to be configured with this priority level, and then the process60goes to block74. If it is determined in condition block68that the classification is not diamond, then the process60goes to block72, which includes the step of creating or updating an entry in a next highest level of classification (e.g., “gold”), and then the process60goes to block74. As indicated in block74, the process60includes completing the configuration request.

Although the process60includes the classifying the queriers or querier interfaces according to three different levels or groups of priority, it should be noted that any number of classification or levels may be used. Also, the classifications or levels may also include any suitable names to distinguish one from another. Furthermore, similar classification names (e.g., platinum, diamond, gold, silver, etc.) may be used in the following examples as well. In some cases, these classifications may be the same and may be stored in the same databases or alternatively may be stored in different sets of databases or stored in different parts of the databases.

II. Configuring Multicast Groups of the IGMP Querier Device

FIG.5is a flow diagram illustrating an embodiment of a process80for creating a second set of databases to be used to prioritize multicast groups at each of the IGMP querier interfaces, as prioritized with respect to the process60ofFIG.4. Therefore, in addition to the querier interface priority process described with respect toFIG.4, the router40can further prioritize the multicast groups on each respective querier interface20using a user configurable priority. For example, below is a sample configuration:

config# igmp querier instance <instance-name>interfaces interface <interface-name>join-multicast-groups multicast-group <group-address>priorityclass-platinumclass-diamondclass-gold

The process80includes blocks82-94that may be similar to the corresponding blocks62-74shown inFIG.4. However, instead of classifying the IGMP querier (or IGMP querier interfaces), the process80is configured to classify the multicast group associated with each of the previous classified IGMP queriers. Again, the databases may include a second set of database or may be the same set as described with respect toFIG.4. Thus, the process80creates multicast group database as shown for querier interface database creation or for updating the databases described above.

FIG.6is a diagram illustrating an embodiment of a database layout100including the first and second sets of databases described with respect to the processes60and80ofFIGS.4and5, respectively. The database layout100includes the IGMP querier databases102,104,106, wherein database102corresponds to the “platinum-class” database described with respect to block66shown inFIG.4, database104corresponds to the “diamond-class” database described with respect to block70, and database106corresponds to the “gold-class” database described with respect to block72. Each of the databases102,104,106may each be configured with an additional layer of databases108,110,112, wherein each of the databases108corresponds to the “platinum-class” database described with respect to block86shown inFIG.5, database110corresponds to the “diamond-class” database described with respect to block90, and database112corresponds to the “gold-class” database described with respect to block92.

Thus, the processes60,80may be executed at any time before a reboot procedure to establish the priorities of each of the IGMP queriers, querier interfaces, and/or multicast streams. Thereafter, when the system is rebooted, the router40may reference the databases102,104,106,108,110,112to determine the established priorities. The router40can then use these various priorities represented by the databases102,104,106,108,110,112for querier interface entry creation/modification as described below with respect toFIGS.7and8.

FIG.7is a flow diagram illustrating an embodiment of a process120for entering configuration data into the hardware of an IGMP querier device (e.g., router14,40) after a system reboot. For example, the reboot may include a restarting of the router14,40, the IGMP snooping device (e.g., switch16), and/or the entire VLAN22. The process120is adapted to enter the configuration data into hardware in order to prioritize the interfaces20of the IGMP querier device or router14as established in the process60described with respect toFIG.4.

Upon detecting a reboot scenario, the process120is configured to “replay” or access the configuration data from the databases102,104,106(if any) so as to use this data as needed for re-entering into hardware of the router or IGMP querier device, as indicated in block122. The process120then includes the step of determining whether there are any entries present in the platinum database102(or highest priority database), as indicated in condition block124. If there are no entries in this database, the process120skips ahead to condition block130. However, if entries are found in this database, the process120proceeds to block126, which includes the step of creating or entering a first (or next) database entry associated with the relevant configuration data into the hardware of the IGMP querier device. Then, the process120determines whether there are more entries in the platinum database102, as indicated in condition block128. If there are no more entries in this database, the process120proceeds to condition block130. Otherwise, if more are found, the process120loops back to block126to create or enter the next database entry into hardware.

As indicated in condition block130, the process120includes the step of determining whether there are any entries present in the diamond database104(or next highest priority database). If there are no entries in this database, the process120skips ahead to condition block136. However, if entries are found in this database, the process120proceeds to block132, which includes the step of creating or entering a first (or next) database entry associated with the relevant configuration data into the hardware of the IGMP querier device. It should be noted that this entry will follow the entries already entered with respect to the higher priority configuration data. Then, the process120determines whether there are more entries in the diamond database104, as indicated in condition block134. If there are no more entries in this database, the process120proceeds to condition block136. Otherwise, if more are found, the process120loops back to block132to create or enter the next database entry into hardware.

As indicated in condition block136, the process120includes the step of determining whether there are any entries present in the gold database106(or next highest priority database). If there are no entries in this database, the process120skips ahead to block142. However, if entries are found in this database, the process120proceeds to block138, which includes the step of creating or entering a first (or next) database entry associated with the relevant configuration data into the hardware of the IGMP querier device. It should be noted that this entry will follow the entries already entered with respect to the higher priority configuration data. Then, the process120determines whether there are more entries in the gold database106, as indicated in condition block140. If more are found, the process120loops back to block138to create or enter the next database entry into hardware. Otherwise, if there are no more entries in this database, the process120proceeds to block142, which includes the step of completing the database replay into hardware.

Thus, the process120ofFIG.7includes the IGMP querier hardware entry creation after system restart/reboot. Usually, a customer may use a dedicated querier interface per FD for streams based on service class (e.g., platinum, diamond, gold, silver, etc.) to keep a priority on a per-querier-interface level. This will ensure the fast handling of all data for the querier interfaces, including, for example, initial configuration, configuration modification, operational update, or any other static or dynamic changes on the querier interface. Querier interface priority will ensure faster delivery of GQs for priority groups which will minimize the delay in stream delivery to hosts.

There may be some advantages to having priority at a per-querier-interface level. First, faster handling of the higher-priority querier interface will ensure the faster delivery of GQs for priority streams which will enable the faster handling of “join” requests for priority streams and may result in faster delivery of priority streams. Also, it will ensure a better experience for prime users. Second, faster handling of the higher-priority querier interface will ensure the fast filtering for multicast groups. This may help to avoid unnecessary flooding of traffic with premium class streams and may also save network bandwidth and resources. In the case of limited resources on the IGMP querier device, priority will ensure that the “join” requests for premium class stream should not get dropped due to resource unavailability. In this case, the querier may decide to drop lower priority streams as needed and allow higher priority hosts to join the stream.

FIG.8is a flow diagram illustrating an embodiment of a process150for entering configuration data into the hardware of the IGMP querier device (e.g., router14,40) after a system reboot. Again, the reboot may include the restarting of the IGMP querier device, IGMP snooping device, and/or the entire VLAN22. The process150is adapted to enter the configuration data into hardware in order to prioritize multicast streams as established in the process80described with respect toFIG.5. It may be noted that blocks152-172of the process150ofFIG.8includes similar actions with respect to block122-142of the process120ofFIG.7. However, instead of prioritizing the IGMP querier devices (e.g., routers14) and IGMP querier device interfaces (e.g., interfaces20), the process150is configured to prioritize the multicast streams of each of the IGMP querier devices or IGMP querier device interfaces. Also, instead of retrieving data from databases102,104,106, the process150is configured to retrieve data from the respective databases108,110,112.

Thus, the process150can use the prioritized databases108,110,112for the creation, modification, or entry of multicast group data into the hardware of the IGMP querier device. The process150handles the creation of multicast groups per IGMP querier.

Multicast group priority will ensure prioritized handling per querier interface for any kind of group specific operations (e.g., configurational update, operational update, etc.). Per group prioritization will ensure a faster delivery of GQs and thus enable multicast streaming much faster from a dedicated source in case of Source Specific Multicast (SSM). Having priority at per-multicast-group level for querier interface may include certain advantages. For example, faster multicast group entry creation in hardware may ensure faster delivery of GQs for prioritized streams, which may result in faster session stabilization with hosts. Also, this may enable faster application of SSM filtering. Furthermore, prioritizing per-multicast-group levels may ensure the processing of host's “join” requests in case of limited resources available on the IGMP querier device.

Thus, section I and II above relate to prioritizing with respect to IGMP querier devices, IGMP querier device interfaces, and multicast streams at the IGMP querier device level. In some embodiment, the prioritization on this querier device level may be sufficient to enforce the desired prioritization in a VLAN. Nevertheless, the following sections III and IV describe optimization on the IGMP snooping device level. That is, the IGMP snooping devices (e.g., switches16) may also be subjected to various prioritization procedures of the present disclosure to further optimize the VLAN22.

III. Configuring the FDs of the IGMP Snooping Device

To overcome some of the issues of the conventional system, certain “groups” (e.g., Forwarding Domains (FDs), multicast groups, host groups, etc.) at the IGMP snooping device level may also be prioritized. For example, according to some embodiments of the present disclosure, one solution may be based on this priority field, which may be a user-configured value or selection based on the using providing input on a per-FD level and/or a per-group level. Below is an example of a sample configuration:

config# igmp-snooping instance <fd-name> igmp-snooping-configpriorityclass-platinumclass-diamondclass-gold

FIG.9is a flow diagram illustrating an embodiment of a process180for creating a third set of databases to be used to prioritize FDs of the IGMP snooping device (e.g., switch16shown inFIGS.1and2). Again, the first and second sets of databases are related to the IGMP querier device interfaces and associated multicast groups. The process180includes blocks182-194that may be similar to corresponding blocks62-74shown inFIG.4and/or the corresponding blocks82-94shown inFIG.5. However, instead of classifying IGMP queriers, querier interfaces, or multicast groups associated with the IGMP interfaces, the process180is configured to classify the FDs associated with the IGMP snooping devices (e.g., switches16).

FIG.10is a flow diagram illustrating an embodiment of a process200for creating a fourth set of databases to be used to prioritize multicast groups at each of the IGMP snooping devices, which may be based on the FDs prioritized with respect to the process180ofFIG.9. Therefore, in addition to the FD priority process described with respect toFIG.9, the IGMP snooping devices (e.g., switches16) can further prioritize the multicast groups on each respective FD using a user configurable priority. The process200includes blocks202-214that may be similar to the corresponding blocks62-74shown inFIG.4, the corresponding blocks82-94shown inFIG.5, and/or the corresponding blocks182-194shown inFIG.9. However, instead of classifying the FDs, the process200is configured to classify the multicast groups associated with each of the previous classified FDs. The databases may include a fourth set of databases or may be the same set as described with respect toFIG.9. Thus, the process200creates multicast group databases as shown for IGMP snooping device database creation or for updating the databases described herein.

FIG.11is a diagram illustrating an embodiment of a database layout220including the third and fourth sets of databases described with respect to the processes180,200ofFIGS.9and10, respectively. The database layout220may include the FD databases222,224,226, wherein database222corresponds to the “platinum-class” database described with respect to block186shown inFIG.9, database224corresponds to the “diamond-class” database described with respect to block190, and database226corresponds to the “gold-class” database described with respect to block192. Each of the databases222,224,226may each be configured with an additional layer of databases228,230,232, wherein each of the databases228corresponds to the “platinum-class” database described with respect to block206shown inFIG.9, database230corresponds to the “diamond-class” database described with respect to block210, and database232corresponds to the “gold-class” database described with respect to block212.

Thus, the processes180,200may be executed at any time before a reboot procedure to establish the priorities associated with each of the IGMP snooping devices, such as FD classifications and multicast group (e.g., host group) classifications. Thereafter, when the system is rebooted, the IGMP snooping device (e.g., switches16) may reference the databases222,224,226,228,230,232to determine the established priorities. The IGMP snooping device can then use these various priorities represented by the databases222,224,226,228,230,232for snooping device entry creation/modification into hardware of the snooping devices as described below with respect toFIGS.12and13.

FIG.12is a flow diagram illustrating an embodiment of a process240for entering configuration data into the hardware of the IGMP snooping devices (e.g., switch16shown inFIGS.1and2) after a system reboot. Again, the reboot may include the restarting of the IGMP querier device, IGMP snooping device, and/or the entire VLAN22. The process240may be adapted to enter the configuration data into the hardware in order to prioritize the FDs as established in the process180described with respect toFIG.9. It may be noted that blocks242-262of the process240ofFIG.12may include similar actions with respect to block122-142of the process120ofFIG.7and/or the blocks152-172of the process150ofFIG.8. However, instead of prioritizing the IGMP querier devices, interfaces, and other parameters associated with the IGMP querier devices, the process240is configured to prioritize the FDs of each IGMP snooping device.

Also, the process240is configured to retrieve data from the databases222,224,226as established with respect to the process180ofFIG.9and shown inFIG.11. Thus, the process240can use the prioritized databases222,224,226for the creation, modification, and/or entry of FDs into the hardware of the IGMP snooping devices for installing the relevant configuration data therein. The process240handles the creation of the FDs per IGMP snooping device.

Usually, customers may use a dedicated VLAN for streams based on service class (e.g., platinum, diamond, gold, silver, etc.) so keeping a priority on a per-FD level will ensure the fast handling of the data (e.g., initial configuration, configuration modification, operational update, or any other static or dynamic changes) on the FD. The FD priority will ensure faster delivery of multicast streams with minimum impact on services.

Some advantages of having priority at the per-FD level may include the following. First, faster hardware entry creation may enable the processing of “join” requests faster and may send these toward the server12via the router14with minimum delay, which may result in faster connection stabilization between the server12and hosts18, thus improving the overall user experience associated with the hosts18. Also, this may act as a support of querier interface priority and help in faster session stabilization with hosts18in the embodiments in which the same device is used to act as both the IGMP querier device and IGMP snooping device.

Another advantage of per-FD level prioritization is that faster hardware entry creation may ensure the fast filtering for multicast groups. For example, this may avoid unnecessary flooding of traffic in premium class FDs. It may also save network bandwidth and resources. Also, faster hardware entry creation may minimize the exposure of premium streams to unknown hosts, which may help in reducing the threats in network security (e.g., DoS, DDoS, etc.). In the case of limited device resources, the FD level priority may ensure the entry creation for premium class FDs, such that any necessary dropping may be applied to lower priority FDs.

IV. Configuring the Priority of Multicast Streaming of the IGMP Snooping Devices FDs

FIG.13is a flow diagram illustrating an embodiment of a process270for entering configuration data into the hardware of the IGMP snooping device (e.g., switches16shown inFIGS.1and2) after a system reboot. Again, the reboot may include the restarting of the IGMP querier device, IGMP snooping device, and/or the entire VLAN22. Also, similar to the process240ofFIG.12, the process270may operate on the IGMP snooping devices. The process270may be adapted to enter the configuration data into the hardware in order to prioritize multicast groups as established in the process200described with respect toFIG.10. It may be noted that blocks272-292of the process270ofFIG.13may include similar actions with respect to block122-142of the process120ofFIG.7, the blocks152-172of the process150ofFIG.8, and/or the blocks242-262of the process240ofFIG.12. However, instead of prioritizing the IGMP querier devices, querier interfaces, and FDs, the process270is configured to prioritize the multicast groups associated with each FD configured inFIG.12.

Also, the process270is configured to retrieve data from the databases228,230,232as established with respect to the process2000ofFIG.10and shown inFIG.11. Thus, the process270can use the prioritized databases228,230,232for the creation, modification, and/or entry of multicast groups (e.g., host groups) into the hardware of the IGMP snooping devices for installing the relevant configuration data therein. The process270handles the creation of the multicast groups per FD in each of the respective IGMP snooping devices.

Furthermore, the prioritization of the groups in a FD may rely on user configurable priority input on per-multicast-group basis. Below is a sample configuration:

config# igmp-snooping instance <fd-name>group <group-address> group-configpriorityclass-platinumclass-diamondclass-gold

The IGMP network10can use similar methods to create multicast group databases as shown for the FD database creation described above. This may result in the overall database layout220ofFIG.11. The process270can utilize the databases228,230,232in a similar way as described above for multicast group per querier interface as described in the process150ofFIG.8. Multicast group priority (or host group priority), in each FD, may ensure the prioritized handling of any kind of multicast group specific operation (e.g., configurational update, operational update, etc.). Per-multicast-group prioritization will ensure a faster delivery of multicast streams from a dedicated source in case of SSM.

Some advantages of having priority at per-multicast-group level in a FD are described in the following. For example, faster group entry creation in a FD will ensure faster delivery of prioritized streams. Also, this may enable faster application of SSM filtering. This may also avoid flooding of source specific streaming to other hosts results in bandwidth and resource conservation.

FIG.14is a flow diagram illustrating an embodiment of a process300for prioritizing multicast streams in an IGMP environment. In response to a reboot scenario, the process300includes the step of querying a plurality of hosts (e.g., hosts18) regarding membership in a plurality of IGMP multicast streams according to predefined priority levels, as indicated in block302. Next, the process300includes the step of receiving membership reports from the plurality of hosts, as indicated in block304. The process300also includes the step of requesting a server (e.g., server12) to restart the IGMP multicast streams according to the predefined priority levels, as indicated in block306.

According to some embodiments, the process300may be implemented by a router (e.g., router14) that is configured to act as an IGMP querier device. The reboot scenario may include a) a reboot of the router itself, b) a reboot of a Layer 2 (L2) switch (e.g., one of the switches16) acting as an IGMP snooping device in the IGMP environment, and c) a reboot of a VLAN (e.g., VLAN22) defining the IGMP environment. Each of the IGMP multicast streams may include one of a static stream and a dynamic stream. The predefined priority levels may be entered as service class priorities by a user, such as a network operator.

Furthermore, the process300may also include the step of recording the predefined priority levels of the IGMP multicast streams in a plurality of databases before detecting for the reboot scenario. The process300may further include the step of utilizing data entries in the plurality of databases to recreate configuration information in hardware of the router. The step of recreating the configuration information in the hardware of the router may be adapted to provide session stabilization after the reboot scenario. The plurality of databases may include a first set of databases associated with prioritization on an IGMP querier device level, a second set of databases associated with prioritization on a multicast group level related to the IGMP querier device, a third set of databases associated with prioritization on a Forwarding Domain (FD) level related to an IGMP snooping device, and a fourth set of databases associated with prioritization on a multicast group level related to the IGMP snooping device. The process300may also prioritize the IGMP multicast streams based on the predefined priority levels classifying interfaces of the IGMP querier device and prioritize the IGMP multicast streams based on the predefined priority levels classifying the multicast groups of the interfaces of the IGMP querier device. Furthermore, the process300may also prioritize the IGMP multicast streams based on predefined priority levels classifying FDs associated with each of a plurality of IGMP snooping devices and prioritize the IGMP multicast streams based on predefined priority levels classifying multicast groups of each of the FDs.

The step of receiving the membership reports (block304) may include receiving one or more messages from one or more hosts to join or leave multicast groups associated with the IGMP multicast streams. The step of requesting the server to restart the IGMP multicast streams according to the predefined priority levels (block306) may include prioritizing the IGMP multicast streams to reduce the exposure of higher-priority IGMP multicast streams to Denial of Service (DoS) attacks. The plurality of hosts, for example, may be user devices, Internet Protocol television (IPTV) devices, and/or display devices.

According to some embodiments, the FDs, in simpler terms, may refer to a Virtual Switch Instance (VSI) of a VLAN (VLAN/VSI) which has different ports, interfaces, or flow-points as members attached to them. An incoming packet on a port, interface, or flow-point may be switched to different ports using a MAC table. In the case of multicast packets with multicast MAC addresses, or if a MAC entry is not present in the MAC table, packets may be sent out to all ports, interfaces, flow-points of the same VLAN/VSI only. This is what “forwarding domain” may refer to.

A multicast group may refer to host groups and/or multicast traffic streams that particular hosts are interested in listening to (or subscribing to). Whenever a join message is received and there is no multicast group created, the router may be configured to create a new multicast group in the hardware. Also, the router may add the host to the hardware such that this host will receive the stream for consumption and no other host, even though there may be multiple flow-points in the same VLAN/VSI from which the join message came. This may essentially be considered to be a subset of VLAN/VSI that is created on the basis of IGMP packets.

The benefit of the L2 switches16is that not every packet is multicast to every host. That is, the multicast process is different than a broadcast process in which all hosts would receive packets. Thus, the L2 switch reduces the traffic by understanding the multicast groups. Without this IGMP snooping, the multicast streams coming from the server would eventually flood all the hosts in the network. So, by controlling the multicast groups, the switch16is configured to reduce a streaming scenario from a broadcast-type stream (that goes to all hosts) to a multicast-type stream (that has a defined multicast domain). Only those hosts that want the stream from that particular server will get the stream. Similarly, when an end-user is watching television using a host configured as an IPTV, for example, the end-user uses the IPTV to have it tuned to a specific channel and it does not need to receive data packets for every single channel, just the one the end-user is interested in or watching.

One of the keys of the present disclosure is to reorder the GQs26,28, membership reports30,32, and streaming requests34as shown inFIG.2from the 1 through x messages to an order that is based on the added priorities described in the present disclosure, which may not necessarily be the 1 through x order. In some respects, this reordering optimizes the higher-priority streams and allows these streams to be handled first. Then, the lower-priority streams can be processed later. This allows the user to decide the order.

The systems and methods described in the present disclosure include many points of novelty with respect to conventional IGMP systems. For example, the present disclosure allows a user to configure the priority on a per-querier-interface level and on a per-multicast-group level on the IGMP querier device. The present disclosure also allows the user to configure the priority on a per-FD level and on a per-multicast-group level on the IGMP snooping device. Before the system is detected for reboot or restart scenarios, the systems and methods are configured to create prioritized databases by entering configured data based on user-defined priorities of different multicast streams or multicast groups. Priority may be selected and recorded in the databases with respect to IGMP querier interfaces, FDs, and multicast groups. Then, after a reboot is detected, the databases can be accessed in a predefined order, based on priority, to reinstall configuration information into the hardware components of the IGMP querier device and/or IGMP snooping devices to give quicker attention to the higher-priority multicast groups. Thus, the embodiments of the present disclosure are configured to solve a real-world use case that, until now, has not been solved. During IGMP querying and snooping, it was found that conventional systems experienced issues for which the root cause was delay in hardware entry of configuration information. Therefore, the embodiments of the present disclosure are intended to help resolve potential issues in a customer's network.

Although the present disclosure has been illustrated and described herein with reference to various embodiments and examples, it will be readily apparent to those of ordinary skill in the art that other embodiments and examples may perform similar functions, achieve like results, and/or provide other advantages. Modifications, additions, or omissions may be made to the systems, apparatuses, and methods described herein without departing from the spirit and scope of the present disclosure. All equivalent or alternative embodiments that fall within the spirit and scope of the present disclosure are contemplated thereby and are intended to be covered by the following claims.