Device for managing multicast groups

The present invention is included in the field of multicast technology in data networks. Specifically, the present invention relates to a method of managing multicast traffic in a data network, in which a source sends data addressed to at least one multicast group and a plurality of hosts send the multicast group. The data sent by one or more of the sources to be sent is received from the router, and the host and the router are, for example, an IGMP protocol (Internet group management protocol) or an MLD (multicast listener discovery) protocol. To enable host-router multicast communication by communicating with each other using a communication network such as, the host wishes to receive data sent by the source of the list with respect to the multicast group. The host can define an inclusion source list to indicate and an exclusion source list to indicate that it wants to receive traffic from all sources of the multicast group except the sources in the list.

The present invention also relates to an apparatus to which the method is applied.

Multicast technology allows unicast communication, or one-to-one individual communication, to be sent from a single source to many receivers over a data network without the need to set up between the source and each receiver. .. To this end, the source sends the data in the form of a data packet to a single address associated with a multicast group that can be registered for reception by the device wishing to be the receiver of the data transmission. This address, also called a multicast address or multicast group address, is an IP (Internet Protocol) address chosen within the range reserved for multicast applications. Data packets sent by the source to the multicast address are then replicated within different network routers so that they can reach receivers that are subscribed to the multicast group.

A data transmission receiver in a multicast group is generally a device connected to a data network using a proxy or router. Hereinafter, the general term host will be used to refer to the device. The host may be, for example, a computer or a set-top box connected to a television set.

When a host wants to receive information sent by one or more sources in a multicast group, it sends a registration message to the nearest router or intermediate proxy to register for reception in that group, which causes the router to send data. Transmits data arriving through the network and sent by the source of the multicast group to the host. Similarly, when the host wishes to stop receiving data transmissions in the multicast group, it sends a deregistration message to the router or proxy to stop receiving the transmissions.

Whether the message exchanged between the host and the nearest router manages the belonging to the multicast group is that the router works with version 4 (IPv4) or version 6 (IPv6) of the IP protocol (Internet Protocol). Depending on the case, use the IGMP protocol (Internet Group Management Protocol) or MLD (Multiplex Listener Discovery) protocol, respectively.

If there is a proxy between the host and the router, that proxy also uses the IGMP / MLD protocol to exchange multicast group belonging messages with the host, the closest router or other intermediate proxy. In these cases, the proxy can receive requests to register or unregister with the multicast group from different hosts, and by assembling these requests, it will send IGMP / MLD message traffic to the router. Reduce.

In addition, routers exchange messages between routers to define routing control that allows data to be efficiently routed from a source to hosts registered for reception in a multicast group. To this end, routers use specific protocols, including the very well-known PIM-SM (Protocol Independent Multicast-Sparse Mode).

In short, the router receives information from the host in the form of an IGMP / MLD message that specifies from which multicast group it wants to receive traffic, and sets up routing to such host to accept the traffic requested by the host. To do this, for example, use the PIM-SM protocol to communicate with other routers.

All of the protocols mentioned are defined and documented by the Internet Engineering Task Force (IETF).

The IGMP protocol version currently in use is IGMPv3, which is published online by the IETF in the RFC3376 specification (B. Cain et al., Engineering Task Force, Network Working Group, Request for Comments3376, October 2002). , Available from the Internet address http://tools.ietf.org/html/rfc3376).

For the MDL protocol, the currently used version is MDLv2, which is the RFC 3810 specification published online by the IETF (R.Vida et al., Engineering Task Force, Network Working Group, Request for Comments3810, June 2004). Monthly. Currently available at the Internet address http://tools.ietf.org/html/rfc3810).

The behavior of IGMP proxies using the IGMP / MLD protocol is the RFC 4605 specification published online by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4605, August 2006, currently Internet address. (Available from http://tools.ietf.org/html/rfc4605).

The PIM-SM protocol used for communication between routers is the RFC 4601 specification published online by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4601, August 2006, currently on the Internet. It can be found at the address http://tools.ietf.org/html/rfc4601).

Multicast technology was initially implemented primarily to be applied to a many-to-many communication model known as ASM (All Source Multicast). This communication model allows a large number of users to communicate with each other, allow any of the users to send data and receive data from everyone else. A typical ASM application is a multi-communication call over the Internet.

Multicast technology was subsequently implemented to be applied to a one-to-many communication model known as SSM (Source Specific Multicast). In this communication model, a single source sends data to many receivers. Radio and television over the Internet are SSM applications. For this reason, interest in SSM is currently very high.

Prior to the IGMP protocol version, the host could not select the data sending source that it wanted to register for reception in the multicast group, and could only register or unregister with the group for all sources. The message that the host sent to the router was very simple. That is, Join (G) is used to receive traffic from the multicast group G, and Leave (G) is used to stop receiving traffic. Therefore, earlier IGMP protocol versions did not allow SSM.

Source selection in a multicast group by the host is now possible in the IGMPv3 version of the IGMP protocol, and SSM is now possible. For this purpose, the host can send two types of IGMP messages:

INCLUDE message: Consists of an indication of the source IP address of the source from which the host wants to receive the data. In terms of the RFC 3376 specification, the IP addresses of these contained sources are called INCLUDE sources.

-EXCLUDE message: Consists of an indication of the source IP address of the source that the host does not want to receive data. In this case, the host is interpreted as wanting to receive data sent by all sources except the source indicated as excluded in the message. Also in the terms of the RFC3376 specification, the IP addresses of these excluded sources are called EXCLUDE sources.

To save memory, data traffic, or for other reasons, in the IGMPv3 version, each network interface and multicast group can only operate in one of the following two modes and can be switched from one to the other. Was decided. The two modes are the INCLUDE mode in which the network interface defines the INCLUDE source list in it, or the EXCLUDE mode in which the network interface defines the EXCLUDE source list in it.

The network interface can receive multiple different requests for each multicast group G1. Each request contains an INCLUDE or EXCLUDE source list for the same multicast group. To eliminate this situation and maintain the constraint that each network interface can only operate in either INCLUDE or EXCLUDE mode, the IGMPv3 protocol states that network interfaces must apply the following rules:

Rule 1: If any of the data sources in group G1 are EXCLUDE, then the network interface operates in EXCLUDE mode for group G1, and the source list for the network interface is the intersection of the EXCLUDE source list minus the sources in the INCLUDE list. is there.

Rule 2: If all sources are INCLUDE sources, the network interface operates in INCLUDE mode for group G1, and the source list for the network interface is the union of all INCLUDE sources.

Later, by describing a plurality of embodiments of the present invention, it will be understood that these rules significantly complicate communication.

With ASM multicast, if a host wants to receive traffic from a particular multicast group G, it needs to resolve the following technical issues: That is, the host only knows the address of the multicast group G, not the source IP address of that group G that is sending the data. There are different multicast communication protocols between routers that solve this problem in different ways. Today, the PIM-SM protocol is primarily applied, designating routers called rendezvous points (hereafter RP routers) as routers responsible for all sources of a single multicast domain (a group of routers that use the same RP router). Solve the problem by doing. To find the source IP address, each router sets up a first multicast communication with the RP router, which causes the RP router to send the requested multicast traffic to each router. When the router receives the first multicast traffic data, it discovers the source IP address. The final router, the router that receives IGMP messages directly from the host, then attempts to receive data directly from the source using an SPT tree (shortest path tree) that sets up the shortest path through the network, called the SPT path. .. When the router begins to receive data in the form of a copy both through the RP router and directly by the SPT path, it disconnects from the RP router and maintains only direct communication via the SPT path.

With SSM, there is no problem finding the source IP address of the multicast group. This is because the user himself chooses the source from which he wants to receive the multicast traffic. Therefore, the host only needs to show the source IP address to the router or proxy. As a result, SSM can eliminate multiple technically complex problems that are characteristic of ASM. Specifically, it is possible to eliminate the technically complex problems associated with finding the source IP address. For example, in SSM, the router does not need to use the RP router because it can know the source IP address indicated by the host when registering for reception in the multicast group. Therefore, SSM can apply algorithms that are more efficient than those used today.

The aforementioned rules for the IGMPv3 protocol prevent these benefits of SSM systems from being exploited. When operating in EXCLUDE mode, the network interface does not know the source IP address and is therefore forced to find the IP address through the RP router, as described above for ASM, making the routing process for ASM more complicated. There is a drawback that it becomes.

The IETF recently announced a new proposal to modify the IGMPv3 and MLDv2 version specifications of the IGMP and MDL protocols in an attempt to eliminate the shortcomings mentioned, which is the RFC 4604 specification published online by the IETF. (H. Holbrook et al., Engineering Task Force, Network Working Group, Request for Comments4604, August 2006, currently available at the Internet address http://tools.ietf.org/html/rfc4604). The proposed fix basically consists of reserving a range for the SSM multicast address and prohibiting hosts in the SSM multicast system from sending EXCLUDE messages. This constraint prevents the host from listening to other new sources in the same multicast group, thus unnecessarily hindering the full development of SSM.

Several patents or patent applications are known that propose different improvements in multicast communication. U.S. Patent No. 6434622, U.S. Patent No. 6785294, U.S. Patent No. 6977891, U.S. Patent Application Publication No. 2003/0067917, U.S. Patent Application Publication No. 2005/0207354, U.S. Patent Application Publication No. 2006/0120368, U.S. Patent Publication No. 2006/0182109 and WO2006 / 001803A1 are listed. However, none of these solves the problems mentioned above.

A main object of the present invention is to provide an improved system for managing multicast communication in a data network, which is particularly applied to SSM communication.

An object of the present invention is to improve the efficiency of routing between a data transmission source and a host requesting reception of the data transmission.

Another object of the present invention is to enable the implementation of the above system in the form of improved host-router multicast communication protocols based on existing protocols and in a manner adapted to previous versions of these protocols. is there.

To this end, methods have been developed to manage multicast traffic in the types of data networks mentioned at the beginning. This method follows the communication protocol that allows host-router multicast communication. The host stores two separate records for each multicast group and network interface: an inclusive source record containing an inclusive source list and an excluded source record in an excluded source list. Each host's network interface sends a message to the router containing source list information for the host's inclusion source records and / or source list information for the host's exclusion source records for a single multicast group. The router stores two separate records for each multicast group: an inclusive source record that contains inclusive source list information and an excluded source record that contains excluded source list information. When the router receives a message from the host through the network interface of the router that contains information about the inclusion source list and / or information about the exclusion source list, the inclusion source record of the router and / or the router. The exclusion source record is updated for each multicast group.

The present invention intends that the message sent by each host's network interface to the router is a status message that includes a source list of the host's inclusion source records and a source list of the host's exclusion source records. ..

The present invention is a state change message sent when the message sent by the network interface of each host to the router is sent when the host detects a change in the included source record of the host or a change in the excluded source record of the host. And the state change message contains one or two data blocks for each multicast group, each of which is information about modifying the source list of the contained source record or modifying the source list of the excluded source records. It is also intended that each of the data blocks contains a field indicating whether the data block relates to a modification of the containing source list or an exclusion source list.

The router advantageously uses the information about the contained source list contained in the received message to request the data traffic sent by the contained source.

If the network interface is the host's network interface, then include and exclude source records are retained for each socket and each multicast group that use the network interface, and the contents of the include source record for the socket and the exclusion for the socket. Inclusion source records and exclusion source records, which are updated based on the source records, respectively, are retained for the network interface.

In an advantageous embodiment, the status message arriving at the router's network interface includes instructions on how the router must apply to set up a routing tree from the inclusion source to the router. Preferably, in order to incorporate the instruction into the state message, the state message points to a multicast address that is out of range reserved for the multicast address, and the router detects that the indicated multicast address is out of range. Then, it is interpreted that the multicast address includes the instruction, and the instruction is read out in the form of a numerical code included in the multicast address.

The communication protocol between the router and the host is preferably a version of the IGMP protocol (Internet Group Management Protocol) or MLD (Multiplex Listener Discovery) protocol, in which the status message sent by the network or device interface. May include an inclusive source list and an excluded source list in the same message.

The present invention also relates to a network device conforming to the method according to the present invention, wherein the network device includes a network interface and is suitable for operating in an exchange line between the host and the router. · Holds inclusive and excluded source records for each multicast group · Send a message to the proximity network interface to the router, including information on the source list of the included source records and / or information on the source list of the excluded source records for the multicast group. -When the network interface of the network device receives a message from another network interface containing information about the inclusion source list and / or information about the exclusion source list, the inclusion source record and / or the exclusion source record is obtained. It is characterized by storing executable instructions to be updated for a multicast group.

The present invention also relates to a device conforming to the method according to the invention, wherein the device has a network interface and is suitable for operating as a host, for each socket using the network interface, and for each multicast group. A containment source record and an exclusion source record are held for the purpose, and the inclusion source record and the exclusion source record are updated based on the contents of the inclusion source record for the socket and the exclusion source record for the socket for the network interface, respectively. It is characterized by storing executable instructions for holding.

The present invention also relates to a router conforming to the method according to the present invention. · Holds two separate records for each multicast group: inclusion source records and exclusion source records. When the router receives a message through the router's network interface that contains information about the inclusion source list and / or information about the exclusion source list, the inclusion source record and / or the exclusion source record for each multicast group. Update It is characterized by storing an executable instruction for.

The router preferably uses the information in the inclusion source list contained in the message received by the router to request data traffic sent by the inclusion source from other routers.

To request the data traffic sent by the inclusion source, the router preferably uses the PIM-SM (Protocol Independent Multicast-Sparse Mode) protocol.

In a preferred embodiment, upon receiving a message informing the host that it no longer wants to receive traffic from a particular multicast group and a particular inclusion source, the router determines if there is an exclusion source record for the multicast group. If the record exists and does not include an exclusion source with the same IP address as the inclusion source, the router continues to carry the traffic for the particular multicast group and the particular inclusion source, and the traffic Do not send "group and source specific query" type messages in the IGMP protocol to find out if there is another host that still wants to receive.

In a preferred embodiment, the router also receives the message to update the information about the exclusion source record requesting that traffic from a particular source and multicast group be blocked, and the router receives the multicast. If the router includes a containment source that has the same IP address as the source requesting blocking, the router refers to the particular multicast group and said. Do not send a "group and source specific query" type message in the IGMP protocol to continue carrying the traffic of a particular source and to find out if there is another host that still wants to receive the traffic.

Other advantages and features of the present invention can be found in the description below. In the description below, non-limiting characters will be used to refer to preferred embodiments of the invention with respect to the accompanying drawings.

<figref num="1">A basic example of a multicast system in a data network is shown.</figref><figref num="2">A detailed example of a multicast system in a data network is shown.</figref><figref num="3">Indicates the format of an "affiliation inquiry" message sent by a router to a host in the IGMPv3 protocol, i.e. both the IGMPv3 protocol and the modified IGMP protocol according to the invention.</figref><figref num="4">Indicates the format of the "affiliation report" message sent by the host to the router in both the IGMPv3 protocol and the modified IGMP protocol according to the invention.</figref><figref num="5">Indicates the internal format of the "group record" data block contained in each "affiliation query" or "affiliation report" message in the IGMPv3 protocol.</figref><figref num="6">The format of the "affiliation report" message corresponding to the message sent by the DSLAM 240 to the router 260 in the system of FIG. 2 when the modified IGMP protocol according to the invention is applied is shown.</figref>

Figure 1 shows a basic example of a multicast system in a data network. In this embodiment, three hosts 101, 102, 103 are connected to the data network via CPE 104, 105 (CPE: customer premises equipment). A CPE is a terminal connected to a network located on the subscriber access line side, and communicates using, for example, a DSL (Digital Subscriber Line) modem. Host 101 is connected to CPE104 on a subscriber line, and hosts 102 and 103 are both connected to another CPE105 on another subscriber line. The CPE 104, 105 are connected to a DSLAM 106 (DSLAM: Digital Subscriber Line Access Multiplexer) that directs traffic from different CPE 104, 105 to the router 108 via a switch 107, and the router 108 is connected to the IP (Internet Protocol) network 109. Be connected. Another router 110 is connected to another point on IP network 109, which collects data packets sent by multiple sources 111, 112 of the multicast group.

For clarity, FIG. 1 shows a single group formed by multiple hosts 101, 102, 103 connected to router 108, and a single group consisting of sources 111, 112 connected to router 110. .. Of course, a multicast system actually consists of a large number of these groups and groups.

Figure 1 also shows the scope of each of the IGMP and PIM-SM protocols. That is, the IGMP protocol is applied to the communication between the receiving host and the router via the CPE and DSLAM, and the PIM-SM protocol is applied to the communication between different routers via the IP network.

In this example, the router operates on the IPv4 version of the IP protocol, so it is assumed that this system will use the IGMP protocol. However, the reasons given also apply to systems that use the MLD protocol (IP protocol version IPv6).

CPEs and DSLAMs are devices that can perform an IGMP proxy function that consists of receiving multiple IGMP requests and assembling these requests to reduce the amount of IGMP messages sent to the router. .. This behavior is described in the IETF RFC 4605 specification mentioned at the beginning.

The basic operation of the multicast system shown in Fig. 1 is as follows.

Hosts 101, 102, and 103 send multiple IGMP messages to CPE 104, 105 to identify the multicast address of the group and the source address of the source of the data that the host wants to receive. As in the case of CPE105 in the embodiment of FIG. 1, a CPE receiving multiple IGMP messages from different hosts assembles these IGMP messages and sends a single IGMP message to the DSLAM. The DSLAM106, on the other hand, receives IGMP messages from different CPEs, in this case CPE 104, 105, assembles these messages, and for each multicast group only the INCLUDE or EXCLUDE source is shown in the IGMP message through switch 107. And send it to router 108.

Router 108 receives an IGMP message sent by DSLAM106 via switch 107 and is specified in the IGMP message received by router 108 by communicating with other IP network routers using the PIM-SM protocol. Set up a routing through the IP network that allows the data sent by the source to reach router 108.

In the prior art, router 108 does not always know the source IP address specified by the host, as shown below in a more detailed embodiment. This information is lost when the network interface assembles the IGMP message originally sent by the host. Therefore, Router 108 must find the source IP address by applying a complex and somewhat inefficient process.

Multicast system operation example to which the conventional method is applied (IGMPv3 protocol) Figure 2 details the multicast system and the different communications required for this system to operate.

In order to clarify the principle and advantages of the present invention based on FIG. 2, the operation by the prior art applying the IGMPv3 protocol will be first described. Then, the operation according to the present invention will be described with reference to this same chart of FIG.

The host 200 is a personal computer PC on which two applications 201 and 202 that can request multicast traffic are executed. Computer 200 is equipped with a network card 203 that is connected to CPE208, which is connected to DSLAM240.

Hosts 220 and 225 are two personal computer PCs equipped with network cards 222 and 223 connected to a single CPE228, respectively, and the CPE228 is connected to the DSLAM240. A single application 221, 226, which can request multicast traffic, respectively, runs within computers 220, 225, respectively.

Host 231 is an STB (set-top box) decoder connected to a television set 230 that allows reception of television channels via the Internet. The decoder 231 is equipped with a network card 232 connected to the CPE229, which is connected to the DSLAM240.

The DSLAM240 is connected to the router 260 via the switch 250. Router 260 is connected to an IP network formed by other routers, routers 261, 262, 263, 264, 265, 266, 267, 268 in this example.

Router 264 sets up routing between an RP (Rendezvous Point) router, that is, a multicast group sending source and a host that wants to receive sending from these sources when the host does not know the source's IP address. It is a router used by the PIM-SM protocol.

In the example of FIG. 2, there are five sending sources 295, 296, 297, 298, 299 belonging to the single multicast group G1. For simplicity, the following description refers to these sources by their respective IP addresses, S1, S2, S3, S4, and S5, as shown in FIG.

Sources S1, S2, and S3 are connected to the IP network via router 266, and sources S4 and S5 are connected via router 262.

Applications 201 and 202 running within host 200 want to receive data transmissions in multicast group G1, but each application wants to receive transmissions from different sources as follows:

-Application 201 wants to receive the transmission from sources S1 and S2, and makes an INCLUDE ({S1, S2}; G1) type request for that purpose.

-Application 202 wants to receive deliveries from all sources except S4, and makes an EXCLUDE ({S4}; G1) type request for that purpose.

Network card 203 is a network interface that must combine different socket states associated with applications 201, 202 that apply the IGMPv3 protocol rules. Since one of the sockets operates in EXCLUDE mode, network interface 203 will only operate in EXCLUDE mode, sending the message EXCLUDE ({S4}; G1) to CPE208.

Theoretically, sending an EXCLUDE ({S4}; G1) message would eliminate the need to send an INCLUDE ({S1, S2}; G1) message. This is because the first message implicitly includes all sources except S4, and therefore includes sources S1 and S2. However, by operating in this way, the useful information contained in the IGMP message sent by application 201, that is, the IP addresses of sources S1 and S2, has been lost.

The EXCLUDE ({S4}; G1) message sent by network card 203 is transmitted to DSLAM240 without the source information being modified by CPE208. This is because the DSLAM240 only receives IGMP messages from one origin.

Application 221 running in computer 220 makes an INCLUDE ({S5}, G1) type request indicating that it wants to receive a send from source S5. The network card 222 only receives requests from the socket with which application 221 is associated, so there is no need to combine multiple requests. Therefore, the network card 222 sends an IGMP message containing the same information as the request of application 221, that is, an INCLUDE ({S5}, G1) message to CPE228.

Application 226 running inside computer 225 makes an INCLUDE ({S3}, G1) type request indicating that it wants to receive a send from source S3. The network card 223 only receives requests from the socket with which application 226 is associated, so there is no need to combine multiple requests. Therefore, the network card 223 sends an IGMP message containing the same information as the request of application 226, that is, an INCLUDE ({S3}, G1) message to CPE228.

CPE228 acts as an IGMP proxy, applying IGMPv3 protocol rules to combine messages sent by network interfaces 222 and 223, respectively. Since all received messages are INCLUDE type messages, network interface 228 will only operate in INCLUDE mode and will carry the message INCLUDE ({S3, S5}; G1) to the DSLAM240.

STB231 sends an INCLUDE ({S1}, G1) message indicating that it wants to receive the send from source S1. Since the DSLAM240 receives an IGMP message from a single origin, the CPE229 transmits this message as is to the DSLAM240.

Therefore, the DSLAM240 receives the following three IGMP messages. EXCLUDE from CPE208 ({S4}; G1) INCLUDE from CPE228 ({S3, S5}; G1) INCLUDE ({S1}, G1) from CPE229

The DSLAM240 is a proxy that must combine these different messages by applying the IGMPv3 protocol rules. Since one of the messages received for multicast group G1 is an EXCLUDE type message, network interface 240 will only operate in EXCLUDE mode for the multicast group G1 and will be sent from all sources in group G1 except S4. Is transmitted to the router 260 through the switch 250 with the message EXCLUDE ({S4}; G1) indicating that the router 260 must transmit to the DSLAM 240.

Router 260 then communicates with other IP network routers using the PIM-SM protocol to receive data sent by the source requested in the IGMP message, which is the entire source of multicast group G1 except source S4. .. The PIM-SM protocol allows the setup of two routing tree types: an RPT (Rendezvous Point Tree) tree centered on an RP router (in this case, Router 264) and an SPT (Shortest Path Tree) that sets up the shortest path. It is a complicated protocol. An RP router is a router designated by the PIM-SM protocol as a router responsible for recognizing the IP addresses of all the sources of a multicast group. Initially, the router 260 always receives traffic from the multicast group through the RPT tree because only the RP router knows the source IP address. When certain conditions described below are met, the router 260 uses the SPT tree and ceases transmission through the RP tree.

In the example of FIG. 2, when the RPT tree is first used, the router 260 receives the send from the source S1, S2, S3 through the dotted path 281 and sends from the source S5 through the dotted path 282. Receive. Therefore, the router 260 receives data through the longest path, not through the shortest path by the SPT tree, which is paths 291 and 292 shown by the solid lines.

Router 260 does not know the IP address of the containing source because it just received the EXCLUDE ({S4}; G1) message from DSLAM240. Therefore, Router 260 cannot use the SPT tree directly to request traffic from inclusive sources. As mentioned at the beginning, this is a serious drawback. Another drawback is the fact that if the router operates only in SSM multicast, it will not receive EXCLUDE messages. Furthermore, if the router is a simplified router that can only connect directly to the source, it cannot connect directly if it does not know the IP address of the source.

The conditions given by the PIM-SM protocol for switching a specific channel (S, G), that is, the channel defined by the source S in multicast group G, from the RPT tree to the SPT tree are the RFC4601 specification, specifically the RFC4601 specification. It is detailed in Section 4.2.1, "Last Hop Switchover to the SPT," which defines a function called CheckSwitchToSpt (S, G).<img file="JP2010531586A_D0001.tif" />#Note: Restarting KAT will result in SPT switching. Set KeepaliveTimer (S, G) to Keepalive_Period

The CheckSwitchToSpt (S, G) function has a configurable and non-configurable part defined by the configurable "SwitchToSptDesired (S, G)" function. Switching from the RPT tree to the SPT tree takes place when both parts of the condition are met.

Normally, a configurable "SwitchToSptDesired (S, G)" function establishes a threshold for the amount of traffic from source S so that switching from the RPT tree to the SPT tree is not performed if the threshold is not exceeded. Used for.

The non-configurable parts that form part of the PIM-SM protocol programming code are:<img file="JP2010531586A_D0002.tif" />

This non-configurable condition is that if there is a router network interface that has received an IGMP message called INCLUDE (S, G), or if it receives an IGMP message indicating that it wants to receive traffic from all Group G sources. If there is a network interface of the router that has already been completed and the network interface has not received the IGMP message EXCLUDE (S, G), the router simply switches a specific channel (S, G) from the RPT tree to the SPT tree. It stipulates that. This non-configurable condition pertains only to IGMP messages, so the only router that can initiate a switch to the SPT tree and set up a direct connection to the channel (S, G) ingress router is an IGMP message. The receiving router, that is, the router 260 in the embodiment of FIG. Routers that do not receive IGMP messages directly through the network interface do not meet this condition so that they do not initiate a switch to the SPT tree.

In the embodiment of FIG. 2, the only message received by the router 260 is EXCLUDE ({S4}, G1), which does not satisfy the non-configurable condition. Therefore, router 260 cannot switch from the RPT tree to the SPT tree, and traffic will continue to pass the longest paths 281, 282 through the RP router 264 instead of going through the shortest paths 291, 292. In this way, the traffic is delivered in a rather inefficient way, unnecessarily overloading the RP router.

In short, this example shows that applying IGMPv3 protocol rules to combine INCLUDE and EXCLUDE type messages adversely affects the efficiency of routing systems. It will be readily appreciated by those skilled in the art that this situation will also occur in other multicast systems with different combinations than those shown in Figure 2.

Modified IGMP Protocol According to the Invention The present invention solves these problems by applying a modified IGMP protocol so that the network interface can transmit the message sent by the host without losing the information contained in the message.

The modified IGMP protocol according to the invention differs from the IGMPv3 protocol in that the network interface can operate in dual mode. That is, the interface separately stores and transmits the information contained in the INCLUDE type IGMP message and the information contained in the EXCLUDE type IGMP message.

The modified IGMP protocol according to the present invention will be described later. For ease of explanation, the description of the IGMPv3 protocol according to the RFC3376 specification of the IETF mentioned at the beginning is referred to, and only the changes in the modified IGMP protocol with respect to the IGMPv3 protocol are described in detail. The parts not described in detail correspond to the IGMPv3 protocol and are within the understanding of those skilled in the art.

The description is summarized in the following sections. 1) Interface description / state information / source assembly method 2) How to delete the status record 3) Rules for deriving network interface records 4) Description of IGMP message 5) Behavior when record information changes 6) Behavior when the host receives the "affiliation inquiry" message 7) Explanation of protocol for router 8) Compatibility with IGMPv3 hosts 9) Improved IGMP proxy

1) Interface description / state information / source assembly method The RFC3376 specification for the IGMPv3 protocol states that the system must support IGMP messages with the following functions and allow the host to select a multicast data source. IPMulticastListen (socket, interface, multicast-address, filter-mode, {source-list}) With the above function

A "socket" is a parameter that allows you to distinguish between different applications running in your system and calls the IPMulticastListen function. For example, it could be a different application running within a single computer connected to a data network.

An "interface" is a local identifier for a network card or network interface that indicates a multicast data source to receive.

"Multicast-address" is the address of the multicast group.

"Filter-mode" is a network interface mode that may be either INCLUDE or EXCLUDE. In INCLUDE mode, the network interface defines the source-list as INCLUDE, which means that traffic sent by all sources on the list must be sent. In EXCLUDE mode, the network interface defines the source-list as EXCLUDE, which means that traffic must be sent from all sending sources in the multicast group except the sources on the list. means.

A "source-list" is an INCLUDE or EXCLUDE source list.

The RFC3376 specification explicitly states that there can be only one filter-mode, which may be INCLUDE or EXCLUDE, for a particular socket, network interface, and multicast group combination.

The system saves a state record for each active socket. This record contains the following information: (interface, multicast-address, filter-mode, {source-list})

For each socket, the record filter-mode can only be INCLUDE or EXCLUDE.

The system also keeps records for each network interface. This record contains the following information: (multicast-address, filter-mode, {source-list})

For each network interface and multicast group, the record filter-mode can only be INCLUDE or EXCLUDE. The record for each network interface is derived from the socket record. If a record on a network interface must result from a combination of different records, the rules listed at the beginning and posted below apply.

Rule 1: If any of the data sources in group G1 is EXCLUDE, then the network interface will have an EXCLUDE filter-mode for group G1, and the source list for the network interface will take the source for the INCLUDE list from the EXCLUDE source list. It is a common part that was drawn.

Rule 2: If all sources are INCLUDE type sources, the network interface will have INCLUDE filter-mode for group G1 and the source list is the union of all INCLUDE sources.

So far, we have described the characteristics of the IGMPv3 protocol according to the RFC3376 specification.

The modified IGMP protocol according to the invention maintains the same structure of the IP MulticastListen function of the IGMPv3 protocol. IPMulticastListen (socket, interface, multicast-address, filter-mode, {source-list}) However, for each socket and each network interface, the difference is that the system stores two records, one for EXCLUDE filter-mode and one for INCLUDE filter-mode.

Therefore, the system stores two records for each socket. INCLUDE record: (interface, multicast-address, INCLUDE, {source-list}) EXCLUDE record: (interface, multicast-address, EXCLUDE, {source-fist}) It also stores two records for each network interface and multicast group. INCLUDE record: (multicast-address, INCLUDE, {source-list}) EXCLUDE record: (multicast-address, EXCLUDE, {source-list})

If there is only an INCLUDE source, or only an EXCLUDE source, the system needs only one record. However, if there are different calls to the IPMulticastListen function for the same multicast group with INCLUDE and EXCLUDE source information, the system does not mix the information as is done in the prior art using the IGMPv3 protocol. Store information in records.

Each call to the IPMulticastListen function replaces the contents of the record for a particular multicast group, and if there is no record, the function call creates a record (which, for example, calls the function for the first time for the multicast group). Sometimes happens).

2) How to delete the status record In the IGMPv3 protocol, an INCLUDE-type message with an empty source list, namely INCLUDE ({}, G1), is sent to clear records for a particular group G1. In addition, records in EXCLUDE mode for a particular group G1 will automatically switch to INCLUDE mode after a period of time without the need to send any message. Therefore, records in the IGMPv3 protocol have a non-zero timer for each multicast group when the record state is EXCLUDE. When the timer reaches zero, the record switches from EXCLUDE mode to INCLUDE mode.

In the modified IGMP protocol according to the invention, the same mechanism as in the IGMPv3 protocol is used to clear the INCLUDE records of a particular group G1. That is, an INCLUDE type message with an empty source list, ie INCLUDE ({}), is sent.

To automatically clear EXCLUDE records for a particular group G1, in the modified IGMP protocol, the EXCLUDE records also have a timer for each multicast group, as in the IGMPv3 protocol, but the behavior is from INCLUDE mode to EXCLUDE mode. It's simpler because you don't have to switch. That is, when the timer reaches zero, the EXCLUDE record is simply erased.

The modified IGMP system optionally adds a new mechanism for erasing EXCLUDE status records more quickly, which applies to: -Host record: Updated with the IPMulticastListen function. -Proxy and router records: Updated with IGMP messages.

A new filter-mode parameter called Filter_Delete_Exclude has been incorporated into the modified IGMP protocol to clear EXCLUDE records using the IPMulticastListen function. The IPMulticastListen function knows that when it receives a call with this parameter, it must clear the EXCLUDE record from the multicast group indicated by multicast-address.

To clear EXCLUDE records from proxies and routers using IGMP messages, a new value for the Group Record Type field in the Affiliation Report message is defined in the modified IGMP protocol with the following brief description: ..<img file="JP2010531586A_D0003.tif" />

This new value is added to values 1-6 (Section 4.2.12 of the RFC 3376 specification) in the "Group Record Type" field that already exists in the IGMPv3 protocol with the following shorthand description.<img file="JP2010531586A_D0004.tif" />In the above, x is a list of source IP addresses.

3) Rules for deriving network interface records As shown in Section 1), the modified IGMP protocol makes it possible to store two records for each network interface and multicast group. INCLUDE record: (multicast-address, INCLUDE, {source-list}) EXCLUDE record: (multicast-address, EXCLUDE, {source-list}) Above, multicast-address is the address of the multicast group and source-list is the list of sources.

As with the IGMPv3 protocol, network interface records are derived from socket records. However, applying the modified IGMP protocol makes the process much simpler because there is no need to mix INCLUDE and EXCLUDE sources in a single multicast group.

The modified IGMP protocol applies the following rules to each network interface and multicast group.

Rule 1: For each multicast group, each INCLUDE record on a network interface contains the union of all sources of INCLUDE records on sockets using said network interface.

Rule 2: For each multicast group, each EXCLUDE record on a network interface contains the intersection of the sources of EXCLUDE records on sockets that use said network interface.

4) Description of IGMP message For simplicity, this section assumes that there is no IGMP proxy between the router and the host. The behavior of the IGMP proxy will be described later in Section 9.

For communication between the host and router, the modified IGMP protocol uses the same messages as the IGMPv3 protocol described in Section 4 of the RFC3376 specification, with modifications as described below.

FIG. 3 shows the format of a message sent by a router to a host in the IGMPv3 protocol, i.e. in both the IGMPv3 protocol and the modified IGMP protocol according to the invention. These messages are called "affiliation inquiry" messages. The format shown in Figure 3 applies to both the IGMPv3 protocol and the modified IGMP protocol.

Figure 4 shows the format of the message sent by the host to the router in the IGMPv3 protocol. These messages are called "affiliation report" messages. The format shown in Figure 4 applies to both the IGMPv3 protocol and the modified IGMP protocol.

Figure 5 shows the internal format of a data block called a "group record" contained in each "affiliation report" message. The Group Address field contains the multicast group address. The Source Address field contains information about the source. The "Number of Sources" field indicates the number of "Source Address" fields present in each "Group Record". The format shown in Figure 5 applies to the IGMPv3 protocol.

The modified IGMP protocol uses the same message format as for the IGMPv3 protocol when sending "affiliation report" messages, but later if there are also INCLUDE and EXCLUDE sources for the same multicast group. Two "group records" are sent, as shown in Figure 6 discussed. Since these sources are not mixed and there can be two records for each network interface and multicast group, the system should carry a message with two "group records" for a single multicast address or group. Can be done. That is, one of the "group records" transmits information about the INCLUDE source and the other transmits information about the EXCLUDE source.

In the IGMPv3 protocol, the router sends a "general inquiry" type "affiliation inquiry" message to ask the host about the status of the host. In response to this message, the host sends a "status record" type "affiliation report" status message. This mechanism is maintained in the modified IGMP protocol, but the "status record" messages sent by the host are for a single multicast group, one in INCLUDE mode and one in EXCLUDE mode. Can include "group records". INCLUDE or EXCLUDE modes are identified by the contents of the "Record Type" field, respectively, as in the IGMPv3 protocol. Record type = 1 = MODE_IS_INCLUDE Record type = 2 = MODE_IS_EXCLUDE

Therefore, information about the two records is transmitted within a single "current record" message.

In the IGMPv3 protocol, the host sends a "Source-List-Change record" message to report the changes that have occurred to the INCLUDE and EXCLUDE sources. Unlike the "Current Record" message, the "Source-List-Change Record" message is not sent in response to the "Affiliation Inquiry" message sent by the router, but the source record has changed. Sent by the host to indicate.

In the modified IGMP protocol, as in the IGMPv3 protocol, the host also sends a "Source-List-Change record" message, with the following differences: Since there can be two records (INCLUDE and EXCLUDE records) for a single multicast group, the "Source-List-Change record" message must indicate which of the two records it refers to. To that end, the modified IGMP protocol defines four new "group record" types with the following abbreviations:<img file="JP2010531586A_D0005.tif" />In the above, x is a list of source IP addresses.

The new "group record types" 8 and 9, ie ALLOWIN (x) and BLOCKIN (x) expressions, are used to send a message to add or remove elements from the source list in the INCLUDE record, respectively.

The new "group record types" 10, 11, respectively, the ALLOWEX (x) and BLOCKEX (x) representations are used to send messages that allow or block traffic sent by source x.

FIG. 6 shows an embodiment of a affiliation report message corresponding to a message sent by the DSLAM 240 to the router 260 in the chart of FIG. 2 when the modified IGMP protocol according to the invention is applied. The content of this message will be explained in detail later. The DSLAM240 acts as an IGMP proxy located between the router 260 and the hosts 200, 220, 225, 231. Therefore, in this case, the above description of the IGMP message between the router and the host applies by replacing the host with DSLAM240. The IGMP proxy behaves as a host when communicating with the IGMP router and as an IGMP router when communicating with the host.

The records stored in each device of FIG. 2 when the modified IGMP protocol according to the present invention is applied are shown below.

In PC200, when applications 201 and 202 use socket 1 and socket 2, respectively, the status records of socket 1 and socket 2 are as follows, respectively. INCLUDE record: (Interface 203, Group G1, INCLUDE, {S1, S2}) EXCLUDE record: (Interface 203, Group G1, EXCLUDE, {S4})

The state record of network interface 203 of PC200 that matches the state of network interface of CPE208 is as follows. INCLUDE record: (Group G1, INCLUDE, {S1, S2}) EXCLUDE record: (Group G1, EXCLUDE, {S4})

In PC220, when application 221 uses socket 1, the status record of socket 1 is as follows. INCLUDE record: (Group G1, INCLUDE, {S5})

In PC225, when application 226 uses socket 1, the status record of socket 1 is as follows. INCLUDE record: (Group G1, INCLUDE, {S3})

After assembling the source, the status record of the network interface of CPE228 acting as an IGMP proxy is as follows. INCLUDE record: (Group G1, INCLUDE, {S3, S5})

In STB231, the status record of network interface 232 that matches the status of network interface of CPE229 is as follows. INCLUDE record: (Group G1, INCLUDE, {S1})

Each of CPE208, 228, and 229 sends its IGMP messages to the DSLAM240, which reassembles these messages but does not mix the INCLUDE and EXCLUDE sources.

After assembling the source, the status record of the DSLAM240's network interface acting as an IGMP proxy looks like this: INCLUDE record: (Group G1, INCLUDE, {S1, S2, S3, S5}) EXCLUDE record: (Group G1, EXCLUDE, {S4})

In response to the "general inquiry" message sent by router 260, DSLAM240 sends to router 260 the message shown in Figure 6 analyzed below.

"Type" == 0x22 indicates that it is a "affiliation report", and "number of group records" = 2 indicates that two data blocks or "group records" are sent for the same multicast group G1. One "group record" contains information about the INCLUDE source and the other contains information about the EXCLUDE source. The first "group record" has a "record type" equal to 1. This means that it is of type MODE_IS_INCLUDE, that is, it contains information about the INCLUDE source. In this data block, the "number of sources" is equal to 4, which means that information on 4 INCLUDE sources will be sent. The multicast group G1 is shown in the Multicast Address field. The four fields "source address [1]" to "source address [4]" contain information about the four INCLUDE sources, namely S1, S2, S3, S5. A second "group record" with a "record type" equal to 2 is shown at the bottom. This means that it is of type MODE_IS_EXCLUDE, that is, it contains information about the EXCLUDE source. "Number of sources" is equal to 1, which means that information about one EXCLUDE source will be sent. The multicast group G1 is shown in the Multicast Address field. The Source Address [1] field contains information about the EXCLUDE source, S4.

Router 260 is receiving complete information on all sources. Here, the requirements given by the PIM-SM protocol for switching the RPT tree to the SPT tree are met as described below.

The SwitchToSptDesired (S, G) condition of the PIM-SM protocol is the configurable part of the switching condition for switching the channel (S, G) from the RPT tree to the SPT tree, where the first data packet is sourced through the SPT tree. It is set by default so that this condition is met when it arrives from. The non-configurable condition of the switching condition is satisfied whenever the modified IGMP protocol is applied. This is because routers that are interested in incoming traffic from source S will always be receiving the IGMP message INCLUDE (S, G), or will want to receive traffic from all sources in group G. This is because the IGMP type message indicating "EXCLUDE (S, G)" is not received.

Therefore, when the modified IGMP protocol is applied, any router that has received a traffic request for a source can proceed to the SPT tree and receive traffic from that source through the shortest path.

Therefore, in the example of FIG. 2, the traffic sent by the sources S1, S2, and S3 will go through the shortest path 291 and the traffic sent by the source S5 will go through the shortest path 292.

The router 260 can optionally connect directly to the SPT tree of each of the sources S1, S2, S3, and S5 from the beginning. Because we know the IP addresses of these sources, we can use the SPT tree directly. For that, it is enough to always make the SwitchToSptDesired (S, G) function true.

In addition, each host can optionally indicate to router 260 in the actual IGMP message when each source must initiate a switch from the RPT tree to the SPT tree. Therefore, according to the present invention, a multicast address field in which a message is placed instead of a multicast address is used outside the range of the multicast address. For example, the first 2 bytes of a multicast address are set to 0 and the next 2 bytes are used to send messages to the router. The following meanings are associated with these next two bytes. 100 = Connect directly using SPT tree 200 = Use router default settings, evaluate SwitchToSptDesired (S, G) function and decide to switch to SPT tree 300 = Always use RPT tree and never switch to SPT tree

If the router detects that the address is outside the range of the multicast address and the router must switch these 4 bytes from the RPT tree to the SPT tree in the multicast address contained after the same "group record". Interpret as a message indicating the method of.

5) Behavior when record information changes In the modified IGMP protocol, if the state record of the network interface for a particular multicast group changes, the system transmits such change by sending the "Source-List-Change record" message shown in the previous section. You just have to do it.

This process is more complex with the IGMPv3 protocol because the system must take into account filter-mode and possible changes to this mode. In the modified IGMP protocol, information from INCLUDE and EXCLUDE sources is stored and transmitted separately, so there is no such complexity.

6) Behavior when the host receives the "affiliation inquiry" message In the IGMPv3 and modified IGMP protocols, the router sends a message to the host, called the "affiliation inquiry" message, which tells the host about the multicast groups and channels it wants to receive. In the modified IGMP protocol, the host sends a response message to the router similar to that sent by the IGMPv3 protocol, with the difference that information about the INCLUDE and EXCLUDE sources is sent separately.

Multiple timers are used to prevent the host from responding at the same time, and these timers delay the response so that it delivers the host's response during the time slot specified in the "affiliation query" message. This works the same as for the modified IGMP protocol and the IGMPv3 protocol.

There are three types of "affiliation query" messages: "general query", "group specific query" and "group and source specific query".

"General inquiry" type messages are sent by the router at regular intervals (125 seconds by default), so that all hosts want to receive them by sending "affiliation report" messages called "status records". Notify about multicast groups and channels. The message for the host to respond to a "general query" request contains a block of data called a "group record". This data block can take the following two types. Record type = 1 MODE_IS_INCLUDE Record type = 2 MODE_IS_EXCLUDE

As shown above, multiple data blocks called "group records" as shown in Figure 5 are sent in a single message or in a "affiliation report" as shown in Figure 4. In Figure 5, the first field of the "group record" is the "record type" field that indicates the meaning of each data block (in the example of Figure 5, the "record type" field is the field shown as "type". is there).

In the IGMPv3 protocol, each multicast group can only be in the INCLUDE or EXCLUDE state, so each host only sends one "group record" for each multicast group, whose "record type" is INCLUDE or EXCLUDE. It has a value of 1 or a value of 2 depending on the state of the group.

With the modified IGMP protocol, the host may need to send two "group records" for a single multicast group as a result of the fact that information from INCLUDE and EXCLUDE sources is stored and sent separately. That is, the first "group record" has a record type = 1 and notifies the INCLUDE source, and the second "group record" has a record type = 2 and notifies the EXCLUDE source. This can be seen in Figure 6 where there are two "group records" for the same multicast group G1.

The same differences as above exist for "group specific query" and "group and source specific query" type messages. That is, when replying to these messages, the host can use the two "group records" to send information separately from the INCLUDE and EXCLUDE sources.

7) Explanation of protocol for router The behavior of the modified IGMP protocol is very similar to that of the IGMPv3 and MLDv2 protocols. Therefore, the same names used in the RFC3376 specification (IGMPv3 protocol) and RFC3810 specification (MLDv2 protocol) mentioned at the beginning will be used later to help understanding.

The main difference between the prior art IGMPv3 and MLDv2 protocols is that in the modified IGMP protocol, the router has two state records for each multicast group: INCLUDE and EXCLUDE records.

The modified IGMP protocol allows the router to further utilize the routing algorithm as a result of the router receiving detailed information about the INCLUDE and EXCLUDE sources from the host. The router runs the IGMP protocol on all networks to which the router is directly connected. If a multicast router has multiple network interfaces connected to the same network, it only needs to run the protocol on one of the network interfaces connected to that network. Unlike the IGMPv3 protocol, in the modified IGMP protocol, routers do not operate in INCLUDE or EXCLUDE mode alone for each multicast group and network interface. Therefore, the router does not need all the mechanisms that allow the router to change from INCLUDE mode to EXCLUDE mode and vice versa.

For each network card or network interface, and multicast group, routers that use the modified IGMP protocol store information from the multicast INCLUDE and EXCLUDE sources separately in two records. INCLUDE record: (multicast-address, INCLUDE, {source list and timers}) EXCLUDE record: (multicast-address, group-timer, EXCLUDE, {source list and timers}) In the above record, {source list and timers} is a list of elements (source-address, source-timer), source-address is the source IP address, and source-timer is the timer associated with the source. ..

timer is a variable in memory that contains a value that regularly decreases over time until it reaches zero.

Therefore, the two INCLUDE and EXCLUDE records stored in the router contain one source-timer associated with each source-address.

As explained above in Point 2 on how to erase records, each EXCLUDE record associated with a multicast group is EXCLUDE when a certain amount of time elapses without the router receiving a report with an EXCLUDE type traffic request. It also contains a group-timer used to remove state records.

As explained above, the router periodically sends messages to the host, called "affiliation inquiry" messages, as shown in Figure 3, which allows the host to receive multicast traffic for groups and sources. Reply notification of. The host can also send a message to the router to request multicast traffic without waiting for the host to send an "affiliation inquiry" message.

After sending a "Group Specific Inquiry" or "Group and Source Specific Inquiry" message, the router uses a timer to ensure that all hosts have had enough time to reply to the message. .. The value of the timer gradually decreases over time, and when the router receives an "affiliation report" message from the host, the router restarts the corresponding timer.

The timer in the INCLUDE record works as follows. That is, for a particular network interface, a particular multicast group, and a particular inclusion source address, as long as the source-timer is greater than zero, the router will carry multicast traffic from the channel (source, multicast group) over said network interface. Subsequently, when the source-timer reaches zero, the router stops transmitting the traffic and removes the source from the INCLUDE source list for that multicast group.

The timers in the EXCLUDE record work in the same way, with the difference that the EXCLUDE sources fall into two lists. That is, a first list called the "request list" that contains sources whose source-timer has a value greater than zero, and a second list called an "exclusion list" that contains sources whose source-timer has a value greater than zero. Is.

For each group Gi, the router carries all the traffic requested by the INCLUDE source. If there are additional EXCLUDE records for group Gi, the router removes the EXCLUDE source from the "exclusion list" and further carries all the remaining traffic for group Gi.

The reason for the existence of a "request list" is that in a network with multiple hosts sending messages to routers, there can be conflicts between requests from different hosts. This happens, for example, when a host requests traffic from a particular source and another host requests traffic other than that source. For example, host 1 sends a first EXCLUDE ({S1}, G1) message, and then another host 2 in the same Ethernet network sends a second EXCLUDE ({S1, S2, S3}, G1) message. To the same router. Upon receiving the second message, if the router puts the source {S1, S2, S3} of the second message in the "exclusion list", host 1 wants to receive all traffic except the traffic from source S1. Therefore, the reception of traffic from the sources S2 and S3 that we wanted to receive will be stopped. To avoid this problem, the router puts only the intersection between the source set of new messages and the source set that was in the "exclusion list" before receiving the message in the "exclusion list". The remaining EXCLUDE sources go into the "request list" and the router optionally "groups and sources identify" to ask if there are hosts that still want to receive traffic from sources S2, S3 in group G1. Send an "inquiry" message to the host.

The principle for classifying EXCLUDE sources into two lists, the "request list" and the "exclusion list", according to the value of the source-timer is similar to that applied in the IGMPv3 and MLDv2 protocols. The RFC 3810 specification (MLDv2 protocol) mentioned at the beginning contains an explanation of this principle.

Table 1 (at the end of this document) shows the behavior of improved routers that apply the modified IGMP protocol according to the invention. In the initial state, the router has an INCLUDE source for a particular multicast group G and therefore has an EXCLUDE source, so it has two state records for said multicast group G. In Table 1, "State 1" in the first column indicates the initial state of the router's INCLUDE and EXCLUDE records. The "message" in the second column indicates the content of the "affiliation report" message received by the router. The "state 2" in the third column indicates the state of the record of the router after receiving the "affiliation report" message. The fourth and last column, "action," indicates the action to be taken after the router receives the "affiliation report" message. The table contains 6 rows separated by dotted lines. Each row in the table is an example of router operation that is based on the initial state and depends on the messages received by the router.

Table 1 points to each multicast group G individually. Each multicast group G has its own INCLUDE and EXCLUDE status records that are affected by messages received by the router with respect to said G group.

In Table 1, the following names are used. (A + B) means the union of source sets A and B. -(A * B) means the intersection of source sets A and B. -(AB) means source set A minus the source found in B. INCLUDE (A) indicates that the router has an INCLUDE record with a source set called A. -EXCLUDE (X, Y) indicates that the router has an EXCLUDE status record because it has an EXCLUDE source. -X is a "request list". -Y is an "exclusion list". -GMI is a parameter called "group affiliation interval" that includes the time value. A value of 250 seconds is used by default. -LMQT is a parameter called "last member query time" that includes a time value. This is the time the host must reply to a "group and source specific query" type message. After this time, if no host replies that they are interested in this data, the router will stop transmitting the data. -T (S) is the source timer of the source S. -GT is a "group timer", that is, an EXCLUDE record timer for the entire multicast group. SEND Q (G, S) means that the router sends a "group and source specific query" message to the host to find out if there are still hosts interested in the source S of multicast group G. .. When this action is taken, the router also lowers the source S timer to the LMQT value. When the router receives a message in response that indicates interest in any of the sources S, it initializes the timer value of the source with the interested host to an initial value equal to GMI.

A further advantage of the modified IGMP protocol is that the router sends a "source and group specific query" type message so that the message can be erased even if all the sources are removed, and some sources are removed from the source list of the messages. It is to be able to query two INCLUDE and EXCLUDE records before removing them.

Therefore, when the router receives a BLOCKIN (B) type message as shown in the example shown in row 4 of Table 1, it applies to the same group G before performing the action SEND Q (G, A * B). You can check for EXCLUDE records and remove all sources not in the "exclusion list" from message Q (G, A * B). That's because not on the "exclusion list" means that someone is requesting those sources using an EXCLUDE message.

In the same way, when the router receives a BLOCKEX (B) type message as in the example shown in row 6 of Table 1, the router queries the source list of the INCLUDE record and uses that information in the INCLUDE record. You can remove the source found in message Q (G, BY).

These two investigations can eliminate a large number of "group and source specific query" messages, resulting in reduced traffic in the network and the number of messages that hosts and routers have to process.

8) Compatibility with IGMPv3 hosts Routers that use the modified IGMP protocol, hereafter referred to as improved routers, can communicate with hosts that use the IGMPv3 protocol. For example, an Ethernet network can have a host operating according to the IGMPv3 protocol, a host connected to its own network, and a host operating according to the modified IGMP protocol according to the present invention.

To that end, the improved router can handle new messages in the modified IGMP protocol, as well as messages used by the IGMPv3 and MLDv2 protocols used in the modified IGMP protocol.

When the improved router receives an ALLOW (B) type message, it behaves as if it had received an ALLOW IN (B) message for the source on B in the INCLUDE record, and for the source on B that has an EXCLUDE state record. Acts as if an ALLOWEX (B) message was received.

If the source on B of the ALLOW (B) message is contained in both the router's INCLUDE and EXCLUDE records, the router behaves as if it had received two ALLOWIN (B) and ALLOWEX (B) messages, or this. It can be set to behave as if only one of the two messages was received. You can choose between these two options in your router configuration.

Cases where the router receives a BLOCK (B) type message are treated in the same way. That is, the behavior of the router can be configured to behave as if it had received two BLOCKIN (B) and / or BLOCKEX (B) messages.

When the router receives a TO_IN (B) message, it treats the message as if it were an IS_IN (B) message. This is because the router can operate in dual mode, so there is no need to switch from INCLUDE mode to EXCLUDE mode and vice versa.

Similarly, when the router receives a TO_EX (B) message, it treats the message as if it were an IS_EX (B) message.

9) Improved IGMP proxy The improved IGMP proxy according to the invention differs from the IGMP proxy defined in the RFC 4605 specification mentioned at the beginning in that it stores and transmits information about INCLUDE and EXCLUDE sources separately.

The improved IGMP proxy can store two records for each network interface and multicast group. INCLUDE record: (multicast-address, INCLUDE, {source list}) EXCLUDE record: (multicast-address, EXCLUDE, {source list})

The function of an IGMP proxy is to assemble messages received from its network interface connected to a host and send messages assembled or summarized by a network interface that connects the IGMP proxy with an IGMP router or another IGMP proxy. is there. The network interface for an IGMP router is commonly referred to as an upstream interface.

To do this, the IGMP proxy applies the same rules as described above in Section 3 and infers records from the host's network interface based on socket records, but with two separate records, one for the INCLUDE source and one for the EXCLUDE source. Therefore, the source list is inferred from the EXCLUDE source record, and the information about the INCLUDE source does not need to be considered because the INCLUDE source record contains the above information.

These rules that the improved IGMP proxy applies to each network interface and multicast group are as follows:

Rule 1: For each multicast group, each INCLUDE record contains the union of all INCLUDE sources of INCLUDE messages about said multicast group received at all proxy network interfaces.

Rule 2: For each multicast group, each EXCLUDE record contains the intersection of all EXCLUDE sources in the EXCLUDE message for said multicast group received at all proxy network interfaces.

A message system with two "group records", the same as described in point 4, is used to separately transmit information about the multicast group, including both INCLUDE and EXCLUDE sources, to the router.

The improved IGMP proxy can work concurrently with hosts using the IGMPv3 protocol and hosts using the modified IGMP protocol according to the invention.

<img file="JP2010531586A_D0006.tif" />