System and method for converting request between different multicast protocols in communication network

The present invention relates generally to data communication, and more particularly to systems and methods for interfacing between routers and hosts on which the Internet group management protocol operates.

Digital media services provide subscribers with access to downloadable video information such as television programs, movies, audio programs, and text-based information streams. In general, subscribers selectively access these services via a connection to a communication network. In a network, services are provided by one or more sources of information. Routers in the network are coupled to both the source and the subscriber, and the router provides a link interface that allows the source to send services to the intended subscriber in the network.

Generally, multicast transmission is used when a service is provided to a particular list of subscribers in the network. In multicast transmission, one router sends a message to multiple destinations. For multicast transmissions, the router needs group information that identifies the members of the group that will receive the specified multicast transmission. In an Internet Protocol (IP) v4 network, Internet Group Management Protocol (IGMP) commands are sent from the host to the router in the network to manage IP multicast transmission. IGMP is an evolving protocol. As that standard evolves, the Internet Engineering Task Force (IETF) has announced RFC1112, named "Host Extensions for IP Multicasting," RFC2236, named "Internet Group Management Protocol, Version 2," and "Internet Group Management." It publishes many IGMP specifications such as RFC3376 named "Protocol, Version 3". All such specifications are incorporated herein by reference. IGMP version 2 is configured to interoperate with Protocol Independent Multicast-Sparse Mode (PIM-SM) multicasting. IGMP version 3 adds the ability for Protocol Independent Multicast-Single Source Multicast (PIM-SSM) multicasting. PIM-SSM offers simplified processing in both the data plane and the control plane than PIM-SM. Unfortunately, some mapping configurations in IGMPv3 are not compatible with IGMPv2. This is a problem when a legacy host that only recognizes IGMP version 2 protocol commands is connected to a network that uses PIM-SSM.

<nplcit num="1"><text>RFC1112 named "Host Extensions for iP Multicasting"</text></nplcit><nplcit num="2"><text>RFC 2236 named "Internet Group Management Protocol, Version 2"</text></nplcit><nplcit num="3"><text>RFC 3376 named "Internet Group Management Protocol, Version 3"</text></nplcit>

<p> Therefore, legacy protocols need methods and equipment that support multicast group transmission that provides PIM-SSM compatibility.</p>

<p> In a first aspect, a method is provided in which a request in one protocol is generated from another request made in another protocol. The request pertains to a change of membership to a group, and the group pertains to the services provided by the host of the telecommunications network. This method involves receiving another request, identifying the target group from another request, identifying the host associated with the target group, and making a request that includes a reference to the target group and the associated host. Includes generating with a different protocol than another protocol. In this way, another request identifies the group and does not uniquely identify the associated host.</p><p> Services in this way can be associated with multicast transmission in the network.</p><p> In this way, hosts can be identified by accessing the data that associates all hosts with all of the groups that make up the network.</p><p> In this way, data can be made accessible by each router in the network.</p><p> In this way, instances of data can be stored locally on each router.</p><p> In this way, each instance of data can be updated by a network manager computer associated with the network.</p><p> In this way, another protocol can follow the IGMP version 2 configuration and the request can follow the IGMP version 3 configuration.</p><p> By this method, another request can be generated on the requesting host of the network and received by the router connected to the requesting host.</p><p> In this way, the transfer table associated with the group can be updated to reflect the request.</p><p> A second aspect provides a system that manages and transforms a request in one protocol from another request made in another protocol. In that system, the request pertains to a change of membership to a group, and the group pertains to the services provided by the host of the telecommunications network. The system has a module that receives another request, data that associates all hosts with all of the networked groups, and an identification module that uses that data to identify the hosts associated with the target group, and the target. It includes a generation module that selectively generates requests containing references to groups and associated hosts. In this system, another request identifies the group and not the associated host uniquely.</p><p> This system allows data to be accessible from each router in the network.</p><p> In this system, instances of data can be stored locally on each router. Each instance of data can be updated by a network manager computer associated with the network. Another protocol can follow the IGMP version 2 configuration and the request can follow the IGMP version 3 configuration.</p><p> The system may further include an evaluation module and a blocking module. The evaluation module uses the membership information associated with the host and target group to evaluate access to the target group for another request. The blocking module selectively blocks the generating module from generating the request if another request has inaccessible access.</p><p> A third aspect provides a method of evaluating and transforming a request received by a protocol. In that method, the request relates to joining the group, and the group relates to the services provided by the host of the communication network. This method makes a request by receiving the request, identifying the target group from the request, identifying the host associated with the target group, and using the host and membership information associated with the target group. Evaluate access to the target group and block the request if the request does not have access to the target group, and block the request if access is accessible to the target group and related Includes generating other requests, including references to hosts. In this method, the request identifies the group, not the associated host uniquely.</p><p> This method can have requirements related to multicast transmission in the network. Another protocol can follow the IGMP version 2 configuration and the request can follow the IGMP version 3 configuration.</p><p> In another aspect of the invention, various combinations and portions of the above aspects are provided.</p><p> The above and other aspects of the invention will become clearer from the following description of the particular embodiment and the accompanying drawings which merely illustrate the principles of the invention. In the figure, similar elements are indicated by similar reference codes, and some reference codes have a unique alphabetic suffix added to identify specific examples of similar elements.</p><p> The following description and embodiments thereof are provided for the purpose of showing examples of specific embodiments of the principles of the present invention. These examples do not limit such principles and are shown for illustrative purposes. In the following description, similar elements are designated by the same reference numerals throughout the specification and drawings.</p>

Prior Art System With reference to Figure 1, network 100 is shown. Aspects of network 100 are shown to illustrate systems of the prior art and embodiments of the present invention.

In prior art systems, network 100 connects a network element to another network element via the cloud 102. In particular, the network cloud comprises a set of routers 104 connected by a communication link 108. As shown in the figure, the cloud 102 includes routers 104A, 104B, 104C, 104D, and 104E. When data traffic is sent from the source device to the destination device via the network cloud 102, communication paths must be defined through the various routers 104.

The architecture of network 102 is preferably IP. Therefore, the address configuration and path generation configuration of data traffic follow the IP configuration. Therefore, when establishing a path, the path goes from the source device to the destination device in multiple segments by continuously finding routers capable of sending data traffic to neighboring routers in the segment of the communication path to the destination device. It will be extended. Each router has a routing table 112 that provides a map of the topology of the network cloud 102 to help each router identify the next segment of the routing path for data traffic received. The network manager 110 is connected to the cloud 102 and serves to maintain and update the routing table 112 for each router 104. The network manager 110 is connected to each router 104 in the cloud 102 via a communication link 108.

Host 106 is a computing device, and each host has an IP address. Each host 106 is connected to a router 104 that provides a connection point for the host 106 to network 100. For example, hosts 106A and 106D are connected to network 100 via router 104A, hosts 106B and 106C are connected to network 100 via router 104B, host 106E is connected to router 104E, and host 106F is connected to router 104E. Connected to router 104C. The connection is established via the connection link 108. In other embodiments, the communication link between the host and its connecting router is an asymmetric digital subscriber line, an Ethernet® connection, a local multipoint data service (LMDS), or an asynchronous transfer mode (ATM) passive optical. A wideband communication link such as a network (APON) may be used.

Some hosts can be used as storage sites for services (such as hosts 106B and 106D), and some hosts can be computers (hosts 106E and 106F) or set-top boxes (hosts 106A and 106C). Use set-top boxes to request services such as multicast group transmission from other hosts. When configured to receive multicast transmissions, the set-top box issues one or more requests to the router, which connects the set-top box to network 100 and the programming information selected by the user. Receive the multicast transmission corresponding to. In such a configuration, when the user watching TV changes channels, the set-top box relays information about the channel change to the connecting router. In essence, the set-top box informs the connecting router that the previously displayed channel is no longer being requested and a new multicast data stream corresponding to the channel selected by the user is being requested. It is also possible to configure a personal computer as a host to request a multicast group in the same way as a set-top box. Each of the hosts can be activated or deactivated at various times, and each of the hosts can request one or more multicast groups at the time of activation.

The prior art uses network 100 to provide some access to digital video distribution services. A user of television 114 accesses network 100 and requests remote host 106 to download a particular video program provided by the service. The user has a display device (such as a television) and a set-top box 106A connected to network 100. Set-top box 106A is the host and generates and sends network requests for user-initiated video programs. When the user wants to download a video program, he / she accesses a menu (generally displayed on television 114) and selects the desired video program from that menu. The set-top box 106A then issues a video program reception request to the network. The request sent by the set-top box 106A is received by the router 104A, which is the connection point to the network 100. Router 104A needs to forward the request to network 100 towards the source of the video program. In network 100, the host that provides the video program is host 106B.

In network 100, hosts 106B and 106D use the IP multicasting protocol to have network 100 deliver the program to the requesting set-top box or computer. Multicasting offers the advantage of protecting bandwidth usage in Network 100. In multicasting, the host repeatedly sends the same data to its router, and then sends one copy of the multicast data to that server once, rather than having that router send the data to each subscriber service. can do.

An IP multicast session is defined by sending a packet to a held multicast IP address. Multicast IP addresses, in IPv4, include addresses within the Class D range, including addresses from 224.0.0.0 to 239.255.255.255. Therefore, by examining the source and destination IP addresses from the packet's IP header, the router can determine which link 108 the packet will be multicast through. Multicast addresses identify specific transmission sessions rather than specific physical destination hosts. This ensures that the host can participate in an ongoing multicast session.

In the prior art, there are three protocols that manage the interaction between the host and router running the multicast protocol. 1. IGMPv2 interoperating with the standardized legacy protocol PIM-SM network 2. IGMPv3 interoperating with the recently standardized protocol PIM-SM network 3. Another recently standardized solution, PIM-SSM IGMPv3 that interoperates with the network.

The following example shows how Protocol # 3 works, where IGMPv3 requests are translated into PIM-SSM requests. To help perform video program multicast, each router maintains a host multicast forwarding table (MFT) associated with each video program. Each entry in the table has two components. The first component provides information about the program being multicast, including the IP address of the group and the source host of the program. The second component is a list of outgoing links (108) associated with the program. Table A is a typical multicast forwarding table for router 104B in network 100.<tables num="1"><img file="JP2004208302A_D0001.tif" /></tables>The MFT may be included as part of the routing table 112. The MFT needs to be updated as multicast destinations are added and removed from the group. During multicast routing, routers communicate with each other to exchange information about multicast group membership information with neighboring routers.

Using IGMPv3, host 106A generates JR (S, G) to router 104A. Here, S is the IP address of host 106B and G is the group IP address of ABC. Router 104A queries the unicast routing table for address S to determine that a backup path to the source exits link 108A to router 104D. Using PIM-SSM, STB router 104A generates a join request command with syntax JR (S, G). The operation of Router 104D is similar to that of Router 104A, except as described. Table B shows the resulting multicast forwarding table on Router 104B, highlighting the changes.<tables num="2"><img file="JP2004208302A_D0002.tif" /></tables>

As described in detail below, an embodiment is provided that provides another system that incorporates IGMPv2 via a PIM-SSM network.

Details of One Embodiment In general, the present invention provides a system and a method for processing a multicast group subscription of a multicast distribution group. When a router receives a request to join a multicast group, but no identification of the source of the group is provided, the router responds by retrieving information from the group source table to identify the source of the group. The router then creates a request to join the distribution group and sends the request along with the source information to the router associated with the group.

With reference to FIG. 1 again, the following example shows an operating mode of the embodiment. Unfortunately, legacy set-top boxes such as the set-top box 106A can only generate IGMPv2 protocol commands and therefore cannot execute IGMPv3 join request commands. In embodiments, an interface mechanism is provided that allows a legacy system to interface with a network that uses PIM-SSM using the IGMPv2 protocol. In an embodiment, when the legacy set-top box 106A generates an IGMPv2 JR (*, G) request, the request is sent to the STB router 104A, which then sends the corresponding PIM-SSM. Generate a JR (S, G) request. Therefore, when the STB router 104A receives the JR (*, G) request, it needs to identify the source S of the group G. After the source is identified, the join request JR (S, G) is sent to the source host 106 according to standard PIM-SSM procedures. In general, PIM-SSM operation is based on a unidirectional tree, the root of the tree is the source and the leaves of the tree are the receivers. Source-specific multicast (SSM) defines a pair-identified "channel" of (S, G) from source S at SSM destination address G. The tree that models the group is called the source-only tree, or the shortest path tree (SPT).

An example of the configuration and use of SPT in the case of (S1, G1) according to the embodiment is shown. Network 100 has a receiver / host 106A on subnetwork 116A (addressed 190.1.1/24). The source S1 is associated with the subnet 116B and has the address S1 = 100.1.1/24, G1 = 232.1.1.1. When the multicast receiver 106A wants to receive group G1 traffic from source S1, it needs to send a notification to subnetwork 116B. Receiver 106A may send an IGMPv2 or IGMPv3 message to router 104A to enforce this notification. In this example, router 104A is the designated router in the subnet 116A. Router 104A tracks the groups accessed by receiver 106 within subnet 116A in the tree information base (TIB). When router 104A receives an IGMP message from receiver 106A, router 104A creates an (S1, Gl) entry on its TIB and then places Ethernet® interface E0 on its outgoing interface list. This list is a list of interfaces that are participating in the group.

Since router 104A must create a new (S1, G1) state, it must send a join request (S1, G1) command to router 104 upstream towards source S1. Router 104A queries the multicast topology table to determine where to send the message. In this example, router 104A sends a join request (S1, G1) message to router 104D. Thus, the join request (S1, G1) message travels hop-by-hop towards S1 in group G1, and each router 104 it passes through instantiates the (S1, G1) state. Finally, the join request (S1, G1) message reaches S1, or router 104, which already has a (S1, G1) join state.

Similarly, receiver 104 may request to leave the group. If all receivers 104 in the subnet 202 leave the group, router 104, the designated router, sends a prune (S1, G1) message to source S1 in multicast group G1.

In an embodiment, all source and group information is stored in each router 104. Management of source and group information is performed by Network Manager 110, which is a computer on Network 100. The source and group information is preferably composed of tables. NetworkManager 110 maintains the contents of the table to ensure that the information in the table is delivered to all routers 104 in network 100. In an embodiment, network manager 110 can deliver the table over link 108 using any known method.

Table C is an example of a table of network source and group information. Any changes (additions and removals) to Table C should be delivered to all Routers 106. For example, if a new channel (such as FOX) starts sending from a video server, the network management operator modifies table C to include the group and source address of the new channel, and then updates the table for each router. Need to be delivered to.<tables num="3"><img file="JP2004208302A_D0003.tif" /></tables>

Using source and group information, in the embodiment, using router 104A as a typical communication device to perform the generation, from the JR (*, G) IGMPv2 command to JR (S, G). Generate PIM-SSM command. Router 104A has internal hardware and software modules that generate commands. In particular, the modular aspects are implemented on a state machine.

First, router 104A receives an IGMPv2 JR (*, G) message from host 106A. Router 104A needs to determine the addressing information for the program's host. To do this, Router 104A accesses the source and group information tables. Since the STB router knows the identification of group G, the interrelated source S can be identified from the source and group information tables. With the source S information, the STB router 104A constructs a PIM-SSM join request to place the source address on the PIM-SSM JR (S, G) as determined from Table B as the "S" IP address. The PIM-SSM is sent to the link determined by the query for address S in the unicast routing table. This is link 108 to router 104D.

To facilitate the distinction between groups, it is preferred that a unique multicast address be provided to each group within the multicast group to allow IGMPv1 / v2 join requests.

In embodiments, source and group information is used with a "reverse path transfer" (RPF) reference, as specified in the PIM-SM and PIM-SSM standards. According to the PIM-SM standard, reception of (*, G) participation results in a special router-based special RPF check in the network called Rendezvous Point (RP). As mentioned above, this step does not need to be performed in the embodiments, and therefore does not need to be performed. In the embodiment, after examining the source and group information to determine the source address (S), the source address (S) information is used to perform an RPF query to determine the outgoing interface used to reach the address S. In this example, the outgoing interface to reach address S (10.1.2.3) is link 108A, which is the link to router 104D. In the embodiment, a data path is configured such that the received (S, G) packet on link 108A is sent out towards host 106A. The embodiment then sends a PIM-SSM join request (S, G) to router 104D via link 108A.

Router 104D receives the PIM-SSM join request (S, G) and passes the request to its state machine making another RPF query for source address S1. The state machine determines that the outgoing interface to reach address S is link 108B leading to router 104B. The embodiment constitutes a data path such that a (S, G) packet received over link 108B is transmitted to link 108A.

The embodiment then sends a PIM-SSM join request (S, G) to router 104B via link 108B. Router 104B receives the request and passes the request to its state machine, which makes a third RPF query to source address S. This determines that the outgoing interface to reach address S is link 108C towards host 106B. In the embodiment, a data path is configured such that the (S, G) packet received via the link 108C is sent to the link 108B. Here, (S, G) traffic from host 106B traverses network 100 and reaches host 106A.

For disconnect requests, follow a similar protocol. The disconnect request must follow the same multicast tree topology as the join request.

With reference to FIG. 2A, the operation mode of the router 104A is shown in more detail. Router 104A has line cards 202A, 202B, and 202C that provide interface points to other external devices such as router 104 and host 106. In particular, the line card 202A provides (i) a connection to host 106A via communication link 108F and (ii) a connection to router 104D via communication link 108A. Line card 202B provides a connection to host 106D over link 108D. In addition to the links and hosts shown in Figure 1, in Figure 2A, line card 202C provides additional connections to additional host 106G via link 108G and additional connections to additional host 106H via link 108H. Shown as having. In addition, the router 104A has a control module 204 that provides processing of transfer information. The external device joins the group managed by router 104A in the order of host 106B, router 104D, host 106G, and host 106H. Finally, host 106D sends an IP packet to group address G1. When host 106D joins a group, it sends an IGMP join message to join group G1. The line card 202B then detects the participation message and provides it to the line card 202A. It will be appreciated that other routers can be provided for embodiments that do not use line cards.

Referring to FIG. 1, another embodiment provides selectively executable multicast to protect the network against service attacks related to multicast traffic. Another device, in addition to the video server, can send multicast traffic with the same group address (S', G) at different source addresses. When the set-top box joins the group (*, G) to indicate a request to connect to the (S, G) traffic from the video server, this feature will refer the traffic received by the set-top box to ((S, G). S, G) Limit to traffic. (S', G) or any other (*, G) traffic is not sent to the set-top box.

For example, the ABC channel is carried at group address 239.0.0.1 carried by source host 106B, using source address 10.12.3, which is an authorized carrier for multicast traffic at group address 239.0.0.1. Another host 106D in the network is rogue or maliciously transmitting over group address 239.0.0.1. Host 106D must do this at its source address 10.2.3.4. Since there are no subscribers to this rogue channel, traffic is terminated and not forwarded by Router 104A. No other host can attempt to join this rogue channel, as the group address 239.0.0.1 is mapped to the source address 10.12.3 on each router. No request is generated for group address 239.0.0.1 with source address 10.2.3.4.

Specifically, referring to FIG. 2B, one embodiment also provides a transmission security feature that blocks unauthorized multicast transmission. This security feature uses a conversion process that transforms an IGMPv2 join request (*, G) into an IGMPv3 join request (S, G) to evaluate an unknown malicious source and give a given multicast. Exclude from group transmission. Multicast source addresses can be configured via the CLI. This feature can be used to prevent denial of service (DOS) attacks on network sources that support multicast traffic.

As mentioned above, router 104 has a line card 202 that provides a connection point between each host 106 and router 104 connected to router 104. Within each line card 202, an interface 204 is provided that can be selectively activated or deactivated by the router 104, depending on the configuration of the equipment configuration. In an alternative embodiment, the interface 204 can be controlled remotely. When interface 204 is deactivated, data traffic received through interface 204 is not forwarded by router 104 to any other point in the network. Such data traffic is simply dropped by Router 104.

With reference to Figures 1 and 2B, the following is an example of a packet being dropped when received from a multicast source (host 106 or other router 104).

-If the multicast group associated with router 104A, for example group G1, is empty, there is no interface associated with it. When host 106D sends an IP packet through interface 204 to router 104A, the interface becomes infeasible because group G1 is empty, and the packet is received by host 106D through interface 204A, router 104A. Will be sent to. Interface 204B becomes infeasible as a multicast source. Therefore, the multicast packet received from host 106D is dropped by router 104A.

When interface 204A becomes infeasible and host 106F initiates an IGMP join request (host 106A, G1), router 106C sends a PIM-SSM join request (104A, G1) to router 104A and interface 204A. Is not feasible as a multicast source, so no multicast forwarding tree is created. Therefore, the multicast packet received from host 106C is dropped by router 104A.

If group G2 is configured on router 104A but has no receiver associated with it and host 106E sends an IP packet to multicast group address G2, router 104E sends the packet through interface 204A. And forward to router 104A. But here, group G2 on router 104A has no members. Therefore, because there is no receiver, Router 104A drops the packet.

Host 106D uses IGMPv2 to send an IGMP join request (G2). However, the group (hosts 106D, G2) is not configured on router 104A. Since the source of G2 is unknown, the multicast forwarding tree is not created, so the packet is dropped by Router 104A.

It should be understood that other configurations of Router 104A can be provided to prevent DOS attacks.

The above embodiments have been described with some degree of specificity for the purpose of explanation. Engineers in the art will appreciate that various modifications and modifications can be made to the embodiments disclosed herein without departing from the scope of the invention.

<figref num="1">It is a block diagram of a communication network including a host and a router operating by one Embodiment of this invention.</figref><figref num="2A">It is a block diagram of the router of the communication network of FIG. 1 which shows the operation mode of embodiment of FIG.</figref><figref num="2B">FIG. 3 is a block diagram of the router of FIG. 2A showing another operational aspect of the embodiment of FIG.</figref>

Code description

100 Network 102 Network Cloud 104A, 104B, 104C, 104D, 104E Router 106A, 106B, 106C, 106D, 106E, 106F, 106G Host 108 Communication Link 110 Network Manager 112 Routing Table 114 TV 116A, 116B, 202 Subnetwork 202A, 202B, 202C Line Card 204 Control Module 204 Interface