System, device, and method for managing multicast group memberships in a multicast network

Description of equivalent WO 9848343 A1

System, Device, and Method For Managing Multicast Group

Memberships in a Multicast Network

Background

1 . Field of the Invention

The invention relates generally to communication systems and, more particularly, to managing multicast group membership in a multicast network.

2. Discussion of Related Art

In today's information age, there is an increasing demand for access to information using computer networking services such as the Internet. Certain types of information are suitable for use by multiple consumers, for example, news, financial information, and sports scores. These types of information can be packaged by a single producer and transmitted over the computer network to a large number of consumers. A typical way for the producer to transmit the information to the consumers is to duplicate the information and send a copy to each consumer. However, if there are a large number of consumers, these individual transmissions can require a large amount of processing by the producer, and can also require a large amount of network bandwidth.

An improved way for the producer to transmit the information to the consumers is by a multicast service. The multicast service allows the producer to transmit a single message, which is then replicated by the network at appropriate points and delivered to each consumer that is a member of a multicast group. Replication is typically handled by routers in the network, and is done only when needed. For convenience, a router that supports the multicast service is referred to as a multicast router. An overview of IP multicasting can be found in an Internet Draft entitled Introduction to IP Multicast Routing by Semeria and Maufer, which is hereby incorporated by reference.

In order to support the multicast service, each multicast router typically supports at least one multicast routing protocol which is used for exchanging multicast group membership information between the various multicast routers in the network. At the present time, several multicast routing protocols exist. Examples of multicast routing protocols include Distance Vector Multicast Routing Protocol (DVMRP), Multicast Open Shortest Path First (MOSPF), and Protocol Independent Multicasting (PIM). In addition to supporting the multicast routing protocols, each multicast router that has directly connected LANs will typically support the Internet Group Management Protocol (IGMP) as described in Appendix I of Internet RFC 1112 (IGMP Version 1 ) and in an Internet Draft entitled Internet Group Management Protocol. Version 2 by Fenner (IGMP Version 2). A multicast router uses IGMP to learn which multicast groups have members on each of its attached physical networks. The multicast router maintains a database containing a list of multicast group memberships for each of its attached networks, where "multicast group membership" means the presence of at least one member of a multicast group on a given attached network. The multicast router does not maintain a list of all of the group members from its attached networks. For convenience, the list of multicast group memberships is referred to as the "group list." IGMP is used between the multicast router and its directly connected IP hosts (i.e., host computers on the directly connected LANs which support the IP protocol). Using IGMP, the IP hosts can join and leave multicast groups, and the multicast router can monitor the multicast group memberships of its IP hosts. For convenience, the multicast router directly connected to an IP host is referred to as the local router (from the perspective of the IP host), while the other routers in the network are referred to as remote routers.

IGMP defines a number of message types that can be exchanged between the local router and the IP hosts. The IGMP Query message is used by the local router to determine the multicast group memberships for its directly connected IP hosts. The IGMP Membership Report message is sent by an IP host unsolicited when it wants to join a particular multicast group and also in response to an IGMP Query message to report its continued membership in a particular multicast group. The IGMP Leave message is used by an IP host to explicitly remove itself from a multicast group. For convenience, a device which sends IGMP Query messages (e.g., the local router) is referred to as an IGMP Querier, and a device which sends IGMP Membership Report messages and IGMP Leave messages (e.g., an IP host) is referred to as an IGMP Host.

The local router typically sends IGMP query messages to the IP hosts to retrieve group membership information. IGMP defines two types of query messages, specifically a General Query message and a Group-Specific Query message. The General Query message is sent to determine which (if any) of the available multicast groups have at least one member from the local router's directly connected IP hosts. In response to the General Query message, each IP host transmits an IGMP Membership Report message for each of its multicast group memberships. However, since each IP host is typically able to monitor the responses of other IP hosts on the same LAN, an IP host that detects a response from another IP host for a particular multicast group may not transmit an IGMP Membership Report message for that same group. Thus, the local router may receive a single IGMP Membership Report for each multicast group, even if multiple IP hosts are members of the same group.

The Group-Specific Query message is sent to determine if at least one of the directly connected IP hosts is a member of the specified multicast group. At least one IP host that is a member of the specified group will respond to the Group-Specific Query message with an IGMP Membership Report message (again, as for the General Query message, an IP host that is a member of the specified group will only transmit a response if it has not detected a response from any other IP host in the group).

When an IP host wants to be removed from a particular multicast group, it stops reporting its membership in the group (i.e., it does not transmit an IGMP Membership Report for the particular group). By not transmitting an IGMP Membership Report message for a particular multicast group, the IP host implicitly requests removal from the group. An IP host that supports IGMP Version 2 can explicitly request removal from a multicast group by transmitting an IGMP Leave message to the local router. The IGMP Leave message informs the local router that the IP host is no longer a member of the multicast group, and, upon receiving the IGMP Leave message, the local router typically transmits an IGMP Group-Specific Query message to determine if at least one IP host remains a member of the multicast group. FIG. 1 shows a system 100 in which a multicast routing protocol is used between the local router and the multicast network, and IGMP is used for dynamic group registration between the local router and a number of IP hosts (typically personal computers). The overall responsibility for maintaining group membership is divided between the local router and the IP host. The IP hosts act as IGMP Hosts, and the local router acts as an IGMP Querier.

The current model for maintaining group membership across a multicast internetwork forces the local router to participate in one or more of the complicated multicast routing protocols in order to propagate group information to other multicast routers. The existing multicast routing protocols are complex, and, due to this complexity, have been changing frequently. This fact makes each protocol difficult to implement and maintain. Also, since no one protocol has been adopted as a standard for all routers, it is often necessary for a multicast router to support many of the protocols, which adds significant cost to the router.

These same problems exist in a data-over-cable (DOC) system. FIG. 2 shows an exemplary DOC system in which a headend router (i.e., local router) 210 is coupled to a plurality of cable modems 220i through 220_n via a shared channel 230. Each headend router may support thousands of cable modems, with each cable modem representing a single LAN segment having at least one host. As in FIG. 1 above, the headend router must support multicast routing protocols in order to exchange multicast group information over the multicast network.

Therefore, a need remains for a system, device, and method for offloading the multicast routing protocols from local routers in a multicast network. Brief Description of the Drawing

In the Drawing, FIG. 1 shows a multicast network as is known in the art;

FIG. 2 shows a DOC system as is known in the art; FIG. 3 shows an exemplary multicast system in which IGMP spoofing in the local router allows IGMP to be used between the remote router and the local router; FIG. 4 shows an exemplary DOC system in which IGMP spoofing in the headend router allows IGMP to be used between the remote router and the headend router;

FIG. 5 shows an exemplary DOC system in which IGMP spoofing in the headend router allows IGMP to be used between the multicast server and the headend router;

FIG. 6 is a flow diagram for IGMP spoofing in a multicast network;

FIG. 7 is a flow diagram for processing an IGMP Membership Report message received from a multicast host by the IGMP spoofing agent;

FIG. 8 is a flow diagram for monitoring the multicast group memberships by the IGMP spoofing agent;

FIG. 9 is a flow diagram for processing an IGMP Leave message received from a multicast host by the IGMP spoofing agent; FIG. 10 is a flow diagram for processing an IGMP General Query message received by the IGMP spoofing agent from the remote multicast device; FIG. 1 1 is a flow diagram for processing an IGMP Group-Specific Query message received by the IGMP spoofing agent from the remote multicast device; and

FIG. 12 shows a device for spoofing IGMP in a multicast network.

Detailed Description

As discussed above, the need remains for a system, device, and method for offloading the multicast routing protocols from local routers in a multicast network. The present invention works by replacing the multicast routing protocols in the local router with an IGMP spoofing agent. The local router continues to act as an IGMP Querier on its host interfaces (i.e. on the local LAN connections to the directly connected IP hosts). However, instead of using a multicast routing protocol to exchange multicast group membership information with the remote router, the local router and remote router use IGMP. The remote router takes on the functions of an IGMP Querier, while the IGMP spoofing agent in the local router takes on the functions of an IGMP Host. The IGMP spoofing agent appears to the remote router as a single IGMP Host, and uses the multicast group membership information maintained by the local router to act as a proxy on behalf of its directly connected IP hosts. The IGMP spoofing agent joins a multicast group if at least one of its directly connected IP hosts is a member of the group, and leaves the multicast group when the last of its directly connected IP hosts leaves the group.

The drawing shows a number of applications for IGMP spoofing in a multicast network. FIG. 3 shows an exemplary multicast system 300 in which IGMP spoofing in the local router allows IGMP to be used between the remote router and the local router. FIG. 4 shows an exemplary DOC system 400 in which IGMP spoofing in the headend router allows IGMP to be used between the remote router and the headend router. FIG. 5 shows an exemplary DOC system 500 in which IGMP spoofing in the headend router allows IGMP to be used between the multicast server and the headend router. In these exemplary embodiments, the IGMP spoofing agent performs standard IGMP Host functions in order to consolidate the multicast group memberships for the multicast hosts and present them to the remote multicast device as a single IGMP Host. IGMP spoofing reduces the cost and complexity of the local router, since the local router need not support any of the multicast routing protocols. IGMP spoofing can also reduce the cost and complexity of the remote multicast device (e.g., the remote router or server), which is only required to support IGMP on the network interface to the local router. If the remote multicast device is a multicast server, then the multicast server need not support any of the multicast routing protocols, so the cost and complexity of the multicast server is reduced.

A flow diagram for IGMP spoofing in a multicast network is shown in FIG. 6. The logic maintains a group list indicating the multicast group membership status for the number of multicast hosts. When at least one of the multicast hosts requests membership in a multicast group, the logic establishes a multicast group membership with the remote multicast device on behalf of the multicast hosts. The logic maintains the multicast group membership with the remote multicast device so long as at least one of the multicast hosts remains a member of the multicast group. When all multicast hosts have left the multicast group, the logic cancels the multicast group membership with the remote multicast device so that the remote multicast device no longer sends multicast messages to the IGMP spoofing agent. The logic also responds to status inquiries from the remote multicast device as a proxy on behalf of the number of multicast hosts. When a multicast host requests membership in a multicast group, the IGMP spoofing agent checks the database to determine if the specified multicast group is in the group list. If the multicast group is in the group list, then no action is needed to add the multicast host to the group. However, if the multicast group is not in the group list, then the IGMP spoofing agent adds the multicast group to the group list and sends an IGMP Membership Report message to the remote multicast device specifying the multicast group.

A flow diagram for processing an IGMP Membership Report message received from a multicast host by the IGMP spoofing agent is shown in FIG. 7. The logic is the same whether the IGMP Membership Report message is received unsolicited or in response to an IGMP Query message. The logic begins in step 710 and, upon receiving an IGMP Membership Report message from a multicast host in step 720, proceeds to step 730 where it checks the database to determine whether the multicast group is in the group list. If the multicast group is not in the group list (NO in step 740), then the logic adds the multicast group to the group list, in step 750, and sends an IGMP Membership Report message to the remote multicast device in order to request membership in the multicast group, in step 760. The logic terminates in step 799.

The IGMP spoofing agent also monitors the multicast group memberships of its multicast hosts by periodically sending status inquiries (i.e. IGMP Query messages) to the multicast hosts. Specifically, the IGMP spoofing agent uses standard IGMP Querier functions to determine which (if any) of the multicast groups in the group list are no longer needed. For each unneeded group, the IGMP spoofing agent deletes the group from the group list and, if IGMP Version 2 is supported, sends an IGMP Leave message to the remote multicast device requesting removal from the multicast group. A flow diagram for monitoring the multicast group memberships by the IGMP spoofing agent is shown in FIG. 8. The logic begins in step 810 and proceeds to step 820, where the logic uses standard IGMP Querier functions to determine which (if any) of the multicast groups in the group list are no longer needed. For each unneeded group (YES in step 830), the logic deletes the group from the group list, in step 840, and sends an IGMP Leave message to the remote multicast device requesting removal from the multicast group (if IGMP Version 2 is supported), in step 850. When all unneeded groups have been removed from the group list (NO in step 830), the logic terminates in step 899.

As discussed above, multicast hosts that support IGMP Version 2 can explicitly request removal from a multicast group by sending an IGMP Leave message to the local router. A flow diagram for processing an IGMP Leave message received from a multicast host by the IGMP spoofing agent is shown in FIG. 9. The logic begins in step 910 and, upon receiving an IGMP Leave message in step 920, proceeds to step 930 where it uses standard IGMP Querier functions to determine if at least one of the multicast hosts supported by the local router remains a member of the multicast group. If there are no remaining members in the multicast group (NO in step 940), then the logic deletes the multicast group from the group list, in step 950, and sends an IGMP Leave message to the remote multicast device requesting removal from the multicast group (if IGMP Version 2 is supported), in step 960. The logic terminates in step 999.

In addition to maintaining the status of multicast group memberships for the multicast hosts, the IGMP spoofing agent also responds to status inquiries from the remote multicast device as a proxy on behalf of the multicast hosts. The remote multicast device sends IGMP Query messages to the IGMP spoofing agent as part of its IGMP Querier functionality. The IGMP spoofing agent responds to the status inquiries using standard IGMP Membership Report messages. A flow diagram for processing an IGMP General Query message received by the IGMP spoofing agent from the remote multicast device is shown in FIG. 10. The logic begins in step 1010 and, upon receiving an IGMP General Query message in step 1020, accesses the database to obtain the group list, in step 1030, and sends an IGMP Membership Report message to the remote multicast device for each multicast group in the group list. The logic terminates in step 1099.

A flow diagram for processing an IGMP Group-Specific Query message received by the IGMP spoofing agent from the remote multicast device is shown in FIG. 11 . The logic begins in step 1110 and, upon receiving an IGMP Group-Specific Query message in step 1120, proceeds to step 1130 where it checks the database to determine if the specified multicast group is in the group list. If the multicast group is in the group list (YES in step 1 140), then the logic sends an IGMP Membership Report message to the remote multicast device for the multicast group, in step 1 150, and terminates in step 1 1 99.

FIG. 12 shows a device 1200 for spoofing IGMP in a multicast network. The device 1200 includes a network interface 1210 for interfacing with another multicast device (such as a remote multicast router or server) or a multicast network. The device 1200 also includes a host interface 1230 for interfacing with a number of multicast hosts. An IGMP spoofing agent 1220 performs IGMP Querier functions over the host interface 1230 for managing the multicast group memberships for the multicast hosts, and performs IGMP Host functions over the network interface 1210 for acting as a proxy on behalf of the multicast hosts. The IGMP spoofing agent 1220 maintains multicast group membership information for its attached multicast hosts in a database 1240 which is updated each time a group membership is established or canceled.

While the IGMP spoofing technique has been described as relating to the headend router of a DOC system or other local router, it will be apparent to a skilled artisan that the present invention can also be used in other devices such as a remote router, a remote access server, or an IP switch. When the IGMP spoofing technique is used in a remote router, the remote router will manage the multicast group memberships for its directly attached local and remote routers that also support IGMP spoofing.

The present invention may be embodied in other specific forms without departing from the spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. What is claimed is: