WO2015071914A2

WO2015071914A2 - Multicast data management

Info

Publication number: WO2015071914A2
Application number: PCT/IN2013/000695
Authority: WO
Inventors: Duane Edward Mentze; Balaji Sankaran
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2013-11-14
Filing date: 2013-11-14
Publication date: 2015-05-21
Anticipated expiration: 2016-05-14
Also published as: WO2015071914A3

Abstract

An example method for managing multicast data packets in accordance with aspects of the present disclosure includes receiving an unregistered multicast data packet, identifying a first multicast filter entry in a group prefix table, the first multicast filter entry identifying a set of ports associated with the unregistered multicast data packet, determining presence of a second multicast filter entry in a flow table, the second multicast filter entry identifying a set of ports associated with the registered multicast data packet, choosing the first multicast filter entry or the second multicast filter entry as a chosen multicast filter entry based on the presence of the second multicast filter entry in the flow table, and transmitting the multicast data packet to the set of ports associated with the chosen multicast filter entry.

Description

MULTICAST DATA MANAGEMENT

BACKGROUND

[0001 ] In networking, multicast technology makes it possible to deliver data (e.g. , a message or information) to a group of destination recipients (e.g. , hosts) simultaneously in a single transmission from the source through data network, without having to set up unicast communications, e.g. , one-to-one individual communication between the source and each of the recipients. The recipients which receive data in a multicast group are usually equipment connected to the data network by means of a proxy or a router. When a host wants to receive the information sent by one or several sources of a multicast group, it sends to the closest router, or to an intermediate proxy, a subscription message to subscribe to said group so that the router transmits to it the data arriving through the data network and which has been sent by the sources of the multicast group. Likewise, when a host wishes to stop receiving data sending in the multicast group, it sends to the router or to the proxy an unsubscribe message to stop receiving them .

[0002] The messages exchanged between a host and the closest router to manage membership to a multicast group use the IGMP protocol (internet group management protocol) or the MLD (multicast listener discovery) protocol, according to whether or not the router works with version 4 (IPv4) or version 6 (I Pv6) of the I P protocol (internet protocol), respectively. Switches are introduced to allow the creation of virtual local area networks (VLAN), allowing users to segment their networks without the high costs of routers or low port count of bridges.

BRI EF DESCRI PTION OF THE DRAWINGS

[0003] Example implementations are described in the following detailed description and in reference to the drawings, in which:

[0004] Fig. 1 illustrates an example system to determine an influence score of a brand in accordance with an implementation;

[0005] Fig. 2 illustrates an example computer-readable medium to determine an influence score of a brand in accordance with an implementation; and

[0006] Fig. 3 illustrates an example process flow diagram in accordance with an implementation.

I DETAILED DESCRIPTION

[0007] Various implementations described herein are directed to managing multicast traffic. More specifically, and as described in greater detail below, various aspects of the present disclosure are directed to a manner by which traffic for unregistered multicast groups is pruned.

[0008] Aspects of the present disclosure described herein prune traffic for unregistered multicast groups. The aspects of the present disclosure described herein send the traffic for the unregistered multicast groups only to ports which have requested data. That is, all traffic is forwarded from the data sources towards a querier detected port and a router, but from the querier or the router, the traffic forwarding only proceeds if it has been registered. Accordingly, the unknown multicast flows are not be copied to the processor (e.g. , CPU) of the system.

[0009] Moreover, aspects of the present disclosure described herein allow faster proactive pruning of unknown multicast flows in a network and avoids wasting bandwidth in the network. Moreover, aspects of the present disclosure described herein do not require that all unregistered multicast group entries have to be tracked and maintained in software data structures. Accordingly, software or hardware does not need to monitor or track unknown multicast streams individually. Among other things, this approach may prevent inefficient utilization of hardware and software resources.

[00010] In one example in accordance with the present disclosure, a method for managing multicast data packets is provided . The method comprises receiving an unregistered multicast data packet, identifying a first multicast filter entry in a group prefix table, the first multicast filter entry identifying a set of ports associated with the unregistered multicast data packet, determining presence of a second multicast filter entry in a flow table, the second multicast filter entry identifying a set of ports associated with the registered multicast data packet, choosing the first multicast filter entry or the second multicast filter entry as a chosen multicast filter entry based on the presence of the second multicast filter entry in the flow table, and transmitting the multicast data packet to the set of ports associated with the chosen multicast filter entry.

[0001 1] In another example in accordance with the present disclosure, a system is provided. The system comprises a processor, a non-transitory machine readable medium storing instructions, when executed, causes the processor to identify a first multicast filter entry in a group prefix table, the first multicast filter entry pointing to a set of ports for receiving an unregistered multicast data packet, determine presence of a second multicast filter entry in a flow table, the second multicast filter entry pointing to a set of ports for receiving registered multicast data packet, choose between the first multicast filter entry and the second multicast filter entry based on the presence of the second multicast filter entry in the flow table, and transmit the multicast data packet to the set of ports associated with the chosen multicast filter entry.

[00012] In a further example in accordance with the present disclosure, a non- transitory computer-readable medium is provided. The non-transitory computer- readable medium comprises instructions that when executed cause a device to (i) identify a first multicast filter entry in a group prefix table, the first multicast filter entry identifying a set of ports associated with unregistered multicast data packet, (ii) choose between the first multicast filter entry and a second multicast filter entry based on presence of the second multicast filter entry in a flow table, the second multicast filter entry identifying a set of ports associated with unregistered multicast data packet, and (iii) transmit the multicast data packet to the set of ports associated with the chosen multicast filter entry.

[00013] Fig. 1 illustrates an example system 100 in accordance with an implementation. The system 100 may be for providing multicast messages, and may comprise a network system 130 connected to a data source 120 and receivers 150, each of which is described in greater detail below. The network system 130 may comprise at least one router 140 and at least one switch 1 50. It should be readily apparent that the system 100 depicted in Fig. 1 represents a generalized illustration and that other components may be added or existing components may be removed, modified, or rearranged without departing from a scope of the present disclosure. For example, while the system 100 illustrated in Fig. 1 includes only one data source, the system may actually comprise a plurality of data sources, and only one has been shown and described for simplicity.

[00014] The data source 120, which may also be called a host, may be any of various computers or computing devices. For example, the system 100 can be a desktop computer, workstation computer, server computer, laptop computer, tablet computer, smart phone, or the like. The data source 120 may include a processor and memory and help translate input received by, for example, a keyboard from a user 1 10. In one implementation, the system 100 may include any type of processor, memory or display. Additionally, the elements of the system 100 may communicate via a bus, network or other wired or wireless interconnection. [00015] The router 140 may receive data from the data source 120 and may be connected to the switch 150. While Fig. 1 includes only one router, the network system 140 may actually comprise a plurality of routers and only one has been shown and described for simplicity. The router 140 may receive from the data source 120, in the form of IGMP/MLD messages, information specifying which multicast groups the router 140 wants to receive traffic from. In one implementation, the IGMP protocol used may have a querier role. More specifically, a device in this role may queries for multicast members periodically.

[00016] The multicast groups may contain a plurality of recipient devices (e.g. , receivers 162 and 164) interested in receiving a data stream (e.g. , video) from the data source 120. The router 140 may direct multicast traffic to switches having nodes that are intended to receive the .multicast traffic. In another implementation, the router 140 may prune the multicast traffic. More specifically, the multicast router may forward the multicast packets only to one router's output ports over the routes towards the destination hosts which belong to the multicast group.

[00017] The switch 150 may comprise a plurality of ports, and may link network devices together and forwarding (i.e. switching) data from one port to another based on information gleaned from the data packets being transmitted. In one implementation, the switch 150 may provide an internet group management protocol (IGMP) snooping feature. The switch 150 may maintain a map of which links need which multicast streams by following the IGMP network traffic. IGM P snooping may be run on the switch to optimize the multicast forwarding . By dynamically intercepting and analyzing an IGMP message between the data source 120 and the router 140 and the receivers 162 and 164, the switch 150 with IGMP snooping function may determine to which interfaces the multicast data packets of which multicast groups should be forwarded.

[00018] More specifically, the switch 1 50 may channel incoming data from any of multiple input ports to the specific output port that may take the data toward its intended destination. The switch 150 may determine from the physical device (multicast group I P) address in each incoming data packet frame which output port to forward it to and out of. For example, the switch 150 may determine from the multicast group I P address in each packet which output port to use for forwarding the intended destination. In one implementation, the switch 150 may perform a plurality of protocol layer functions (e.g., layer 2 function). The switch 150 may consider layer 2 (i.e. , data link layer) when determining how to move data packets around a network. That is, the switch 150 may look at each packet or data unit and determine from a physical address which device a data unit is intended for and switches it out toward that recipient device (e.g. , the receiver 162 or 164). Further, in another implementation, the switch 150 may perform packet forwarding (routing) based on layer 3 (i.e. , network layer) information. The switch 150 may include the ability to logically segment a network into two or more Virtual LANs (VLANs) plus enhanced security controls to prevent unauthorized setup changes.

[00019] In one implementation, the switch 150 may use a flow lookup table 156 if the snooping is performed using a multicast group IP address. An entry may be created in a multicast flow table 156, which may list the outgoing interfaces corresponding to each multicast group. The multicast groups may contain a plurality of recipient devices (e.g. , the receiver 162 and 164) interested in receiving a data stream (e.g. , video) from the data source 120. The multicast group information may be indicated by a multicast IP address. When the multicast data packets of the multicast group are required to be forwarded to a recipient, the recipient may be added to the outgoing interfaces list corresponding to the multicast group in the multicast flow table entry.

[00020] The flow lookup table 156 may have a lookup key of Source IP, Destination Group I P and Source VLAN . The output of the lookup may be a multicast filter table index, i.e. an entry which points to the ports where the packet may be bridged out. In the event that the multicast data packet ingresses a forwarding engine, a lookup is made in the flow lookup table using the ingress VLAN, destination group and source IP . The packet may be forwarded to the ports specified by the multicast filter entry if the outcome of the look-up is successful. On the other hand, if the lookup fails, the packet may be sent to CPU for control plane to further handling.

[00021 ] In some implementations, the switch 1 50 may use a multicast filter table 158. Each entry in the multicast filter table 158 may define a set of ports in a bit mask. In one example, the set of ports may comprise one port in the event that a single multicast router (e.g . , the router 140) or a querier is detected . In another example, the set of ports may comprise a plurality of ports in the event that the network 130 has a plurality of multicast routers or a combination of a multicast router and a separate querier. In a further example, the set of ports may be empty. That is, there may be no ports in the event that there are no multicast routers or queriers detected in the network.

[00022] The data traffic may be forwarded to a port with the bit set. Moreover, in the event of unknown multicast traffic, either one filter per switch, VLAN or group prefix can be used to filter the unknown traffic. In such implementation, the ports set in the multicast filter table 158 may be of router and a querier detected port. In one implementation, the querier detected port may be a port where the switch has identified a querier. In some examples, there may be one querier in a network, and the unregistered traffic may be sent to the multicast router ports and a querier detected port.

[00023] In one implementation, the multicast filter table and the flow lookup table may be programmed by the control plane of the switch 150 by intercepting protocol packets for registered groups and data packets for unregistered groups. The control plane may be implemented in the firmware of the switch 150. The control plane may be the part of a network that carries signaling traffic and responsible for routing. The control plane may serve the forwarding plane, which may bear the traffic that the network exists to carry. In some implementations, the control plane may feed the forwarding plane with what the forwarding plane needs to create forwarding tables.

[00024] In one implementation, the switch 150 may comprise a group prefix table 154. The switch 150 may use the group prefix entry in the group prefix table 154 per VLAN per address family when addressing unregistered multicast packets. The unregistered multicast packets comprise multicast packets addressed to a multicast group identified by an address not stored in the switch 150. When addressing unregistered multicast packets, instead of broadcasting the unregistered multicast packets received from one port to all the other ports (e.g. , instead of tracking every unknown multicast flow on both control plan and forwarding plane and copying to the CPU), the switch 150 uses the group prefix table. The group prefix entry on the group prefix table may have an index, which represents a range of multicast addresses. By providing a range, the default index is identified and points to an entry in a filter table, which provides a list of ports that the multicast packet may be delivered to. The group prefix entry specifies the multicast packet that is associated with the group prefix entry (e.g. , the multicast packet addresses that belong in the range of multicast addresses identified by the group prefix entry).

[00025] The group prefix table 154 may be introduced in an application specific integrated circuit (ASIC) 152. The ASIC 152 may be a hardware chip that determines what port to forward data to. In one implementation, the ASIC 152 may allow to add 1024 Group Prefix entries in the group prefix table 154. In one implementation, the ASIC 152 may perform layer 2 and layer 3 functions to transfer data between network entities and possibly provide a way to detect and correct errors that may happen in the physical layer. If the group prefix table 154 is supported in the forwarding ASIC 152, the ASIC 152 may program an [224.0.0.0/4, ingress VLAN index] in the group prefix table 154. The entry may cover an entire range of multicast addresses (224.0.0.0 to 239.255.255.255). The entry may point to a hardware filter that contains router and querier detected ports either per VLAN or across all VLAN .

[00026] I n one implementation, where the number of VLANs is more than number of entries that can be programmed in the group prefix table 154, IGMP and MLD subsystems can program the entries for the VLANs. Each of the subsystems may maintain a counter recording the number of unknown streams in a VLAN. As a result, the group prefix table 154 may be efficiently used and have entries for the VLANs which have large number of unknown multicast flows.

[00027] The receivers 162 and 164 may be any of various computers or computing devices. For example, the receivers 162 and 164 can be a desktop computer, workstation computer, server computer, laptop computer, tablet computer, smart phone, or the like. In alternative examples, the receivers 162 and 164 may be, for example, a television in case of requesting a video or a telephone in case of requesting an audio or video conference. In one implementation, the receivers 162 and 164 may belong to a designated multicast group comprising of receivers interested in receiving a data stream (e.g. , video) from the data source 120. The receivers 162 and 164 indicate their interest by sending an IGMP host report. The IGMP message may contain information such as S denoting multicast source and G denoting the identifier of the multicast group. Further, the report message may include a group address field (i.e. , - group destination address) carrying a multicast IP address indicating the specific multicast group. In one example, the multicast IP address may be a class D IP address (e.g. , IPv4), in the range between 224.0.0.1 and 239.255.255.255. In another example, the multicast IP address may be an IPv6 address and have a multicast full range of FF00::/8. I n one implementation , the router 140 may be responsible for delivering the data from the source 120 to the receivers 162 and 164.

[00028] Fig. 2 illustrates a block diagram illustrating an example application specific integrated circuit (ASIC) 200 in accordance with an implementation. It should be readily apparent that the ASIC 200 illustrated in Fig. 2 represents a generalized depiction and that other components may be added or existing components may be removed, modified, or rearranged without departing from a scope of the present disclosure.

[00029] The ASIC 200 comprises a processor 210, a machine readable medium 220 encoded with instructions, each of which is described in greater detail below. The components of the computer may be connected via buses. The ASIC 200 may be any of a variety of computing devices, such as a workstation computer, a desktop computer, a laptop computer, a tablet or slate computer, a server computer, or a smart phone, among others.

[00030] The processor 210 may retrieve and execute instructions stored in the machine readable medium 220. The processor 210 may be, for example, a central processing unit (CPU), a semiconductor-based microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) configured to retrieve and execute instructions, other electronic circuitry suitable for the retrieval and execution instructions stored on a computer readable storage medium, or a combination thereof. The processor 210 may fetch, decode, and execute instructions stored on the machine readable medium 220 to operate the ASIC 200 in accordance with the above-described examples. The machine readable medium 220 may be a non- transitory computer-readable medium that stores machine readable instructions, codes, data, and/or other information. The instructions, when executed by processor 210 (e.g. , via one processing element or multiple processing elements of the processor) can cause processor 210 to perform processes described herein.

[00031 ] In certain implementations, the machine readable medium 220 may be integrated with the processor 210, while in other implementations, the machine readable medium 220 and the processor 210 may be discrete units.

[00032] Further, the computer readable medium 220 may participate in providing instructions to the processor 210 for execution. The machine readable medium 220 may be one or more of a non-volatile memory, a volatile memory, and/or one or more storage devices. Examples of non-volatile memory include, but are not limited to, electronically erasable programmable read only memory (EEPROM) and read only memory (ROM). Examples of volatile memory include, but are not limited to, static random access memory (SRAM) and dynamic random access memory (DRAM). Examples of storage devices include, but are not limited to, hard disk drives, compact disc drives, digital versatile disc drives, optical devices, and flash memory devices.

[00033] As discussed in more detail above, the processor 210 may be in data communication with the machine readable medium 220, which may include a combination of temporary and/or permanent storage. The machine readable medium 220 may include program memory that includes all programs and software such as an operating system, user detection software component, and any other application software programs. The machine readable medium 220 may also include data memory that may include multicast group information, various table settings, and any other data required by any element of the ASIC 200.

[00034] In one implementation, the machine readable storage medium (media) may have instructions stored thereon/in which can be used to program the ASIC 200 to perform any of the processes of the embodiments described herein. Group prefix table instructions 222 can cause the processor 210 to perform a look-up on the group prefix table. The group prefix table comprises group prefix entries, which specify a range of multicast addresses. When the multicast data packet is received at the group prefix table, it is determined whether the multicast group (e.g. , destination IP address) of the multicast data packet is within the range of the multicast IP addresses specified by the group prefix entry on the group prefix table. If the multicast group address is within the range, the filter index (i.e. , unkmcastFilterlndex) for the multicast data packet may be identified. The group prefix table returns a filter index, which is then used to identify a list of ports where the network traffic is forwarded to.

[00035] The flow table instructions 224 can cause the processor 210 to identify a list of receivers (e.g. , recipient devices) that need the network traffic. The output of applying the instructions may be a multicast filter table index, i.e. , entry which points to the ports where the packet may be delivered to. The filter table instructions 226 can cause the processor 210 to forward network traffic to ports that have the bit set identified based on filter index information returned by using the flow entries on the flow table or the group prefix entries on the group prefix table.

[00036] Fig. 3 illustrates a flow diagram illustrating an example packet flow 300 for an unknown multicast flow in accordance with an implementation. In one example, the packet flow 300 may be implemented in an ASIC forwarding engine (e.g. , the ASIC 200 illustrated in Fig. 2). It should be readily apparent that the flow 300 illustrated in Fig. 3 represents a generalized depiction and that other components may be added or existing components may be removed, modified, or rearranged without departing from a scope of the present disclosure.

[00037] In the event of an unknown multicast packet 305 entering ASIC forwarding engine, the ASIC runs a lookup on group prefix table at block 310. As shown in group prefix table 315, the lookup at the group prefix table may be performed based on a key, which includes a VLAN identification and the group prefix. More specifically, the group prefix represents a range of addresses. If the multicast group (e.g., destination I P) is within the prefix range, the multicast packet may be mapped to the range. Moreover, the output of the table is unkmcastFilterindex, which is an Index which identifies the set of ports where the packets may be bridged out to. Such index is used for unregistered multicast packets. If the lookup succeeds (e.g. , the unkmcastFilterindex is not empty), the unknown multicast filter index may be used to forward the packet.

[00038] At block 320, the ASIC may proceed with a lookup on the flow table. The flow table may take ingress VLAN, source address and destination group address as key and upon lookup, returns a multicast filter index. More specifically, table 325 illustrates the lookup performed based on the lookup key comprising source I P, destination group IP and source VLAN. The output of the lookup on the flow table is knownmcastFilterindex, which is an index that points to a set of ports to where the packets may be delivered to. Such index is used for registered multicast packet. That is, knownmcastFilterindex may be used for forwarding traffic to receivers that have registered for the traffic.

[00039] At block 330, it is determined whether the flow entry is present in the flow table. The lookup in the flow table may be successful if the packet belongs to a registered multicast flow (e.g. , knownmcastFilterindex is not empty). Accordingly, if the lookup succeeds in the flow table, at block 335, unkmcastFilterindex is not used, and the packet may be forwarded using the multicast index pointed by the flow table entry value (e.g. , FE. KnownmastFilterl ndex). If the lookup is not successful, at block 340, it is determined whether the group prefix entry is present in the table. In the event that the group prefix entry is not present, at block 345, the packet may be sent to the control plane for further handling . In the event that the group prefix entry is present in the table, at block 350, the packet may be forwarded using the multicast index pointed by the group prefix entry value (e.g. , GPE. unkmastFilterlndex). The multicast filter table 355 shows the port map when the table is looked up based on the filter index key. For example, for filter index 1 , the port map is 01 101 1 ..001 , and for filter index 2, the port map is 1 1 1 1 1 1 . .000. With this approach, the unknown multicast packet flow may not enter the CPU. At block 360, the packet is transmitted to the ports present in the port map pointed by the filter index in the multicast filter table 355.

[00040] The present disclosure has been shown and described with reference to the foregoing exemplary implementations. It is to be understood, however, that other forms, details, and examples may be made without departing from the spirit and scope of the disclosure that is defined in the following claims. As such, all examples are deemed to be non-limiting throughout this disclosure.

I 0

Claims

WHAT IS CLAIMED IS:

1. A method for managing multicast data packets, comprising:

receiving an unregistered multicast data packet;

identifying a first multicast filter entry in a group prefix table, the first multicast filter entry identifying a set of ports associated with the unregistered multicast data packet;

determining presence of a second multicast filter entry in a flow table, the second multicast filter entry identifying a set of ports associated with the registered multicast data packet;

choosing the first multicast filter entry or the second multicast filter entry as a chosen multicast filter entry based on the presence of the second multicast filter entry in the flow table; and

transmitting the multicast data packet to the set of ports associated with the chosen multicast filter entry.

2. The method of claim 1 , wherein the first multicast filter entry is an unknown multicast filter index.

3. The method of claim 1 , wherein second multicast filter entry is a known multicast filter index.

4. The method of claim 1 , wherein the set of ports identified by the second multicast filter entry provides a list of ports for receiving the registered multicast data packet.

5. The method of claim 1 , wherein the set of ports identified by the first multicast filter entry provides a list of ports the unregistered multicast data packet are forwarded to.

6. The method of claim 1 , wherein the unregistered multicast data packets comprise multicast packets addressed to a multicast group identified by an address not stored in group prefix table.

7. The method of claim 1 , wherein the group prefix table provides a range of multicast group I P addresses for the unregistered multicast data packet.

8. The method of claim 1 , wherein the flow table comprises a lookup key of source I P, destination group IP and source VLAN .

9 The method of claim 8, wherein determining the presence of the second multicast filter entry in the flow table further comprises performing a look-up at the flow table using the look-up key.

10. The method of claim 1 , wherein the set of ports are determined via a filter table based on the chosen multicast filter entry, and wherein the filter table outputs a port map for each filter entry.

1 1 . The method of claim 10, further comprising performing a look-up at the filter table using the chosen multicast filter entry as a key.

12. A switch for providing multicast data packet across a data network, comprising:

a processor;

a non-transitory machine readable medium storing instructions, when executed, causes the processor to:

identify a first multicast filter entry in a group prefix table, the first multicast filter entry pointing to a set of ports for receiving an unregistered multicast data packet;

determine presence of a second multicast filter entry in a flow table, the second multicast filter entry pointing to a set of ports for receiving registered multicast data packet;

choose between the first multicast filter entry and the second multicast filter entry based on the presence of the second multicast filter entry in the flow table; and

transmit the multicast data packet to the set of ports associated with the chosen multicast filter entry.

13. The switch of claim 1 1 , further comprising a network interface coupled to the data network for receiving at least one packet flow.

I

14. The switch of claim 1 1 , further comprising a plurality of network ports for sending and receiving the unregistered multicast data packet.

15. A non-transitory computer-readable medium comprising instructions that when executed cause a switch to:

identify a first multicast filter entry in a group prefix table, the first multicast filter entry identifying a set of ports associated with unregistered multicast data packet;

choose between the first multicast filter entry and a second multicast filter entry based on presence of the second multicast filter entry in a flow table, the second multicast filter entry identifying a set of ports associated with unregistered multicast data packet, and