Device for managing multicast groups

ES 2 358 546 T3

DESCRIPTION

Field of the invention

[001] The invention is in the field of multicast or multicast technology in data networks. More specifically, the invention refers to a multicast traffic management procedure in a data network, where sources broadcast data addressed to at least one multicast group and a plurality of hosts receive from a router the data broadcast by one or more of said sources that broadcast in said multicast group, said hosts and said router communicating through a communications protocol, such as the IGMP protocol (Internet Group Management Protocol) or the MLD protocol (Multicast Listener Discovery), which allows host-router multicast communications through which said host can define, for said multicast group, a list of included sources to indicate that you want to receive the data broadcast by the sources in that list and a list of excluded sources to indicate that you want to receive traffic from all sources in that multicast group except the sources in that list.

[002] The invention also relates to devices that apply said method.

State of the art

[003] Multicast technology makes it possible to send data from a single source to many recipients through a data network, without it being necessary to establish a unicast communication, that is, an individual one-to-one communication between the source and each of the recipients. To do this, the source sends data, in the form of data packets, to a single address associated with a multicast group to which the computers interested in being recipients of said data broadcast can subscribe. This address, called a multicast address or also a multicast group address, is an IP (Internet Protocol) address chosen from a range that is reserved for multicast applications. The data packets that have been sent by the source to the multicast address are then replicated in the different routers of the network so that they reach the recipients who have joined the multicast group.

[004] Normally, the recipients of data broadcasts in a multicast group are computers connected to the data network through a proxy or a router. From now on, the usual term host will be used to refer to these target computers. A host can be, for example, a computer or a set top box connected to a television.

[005] When a host wants to receive the information emitted by one or more sources of a multicast group, it sends to the nearest router, or to an intermediate proxy, a subscription message to said group so that the router transmits the data that reaches it. through the data network and that have been emitted by the sources of the multicast group. Likewise, when a host wishes to stop receiving data broadcasts in the multicast group, it sends the router or proxy a logout message to stop receiving them.

[006] The messages exchanged between a host and the closest router to manage membership in a multicast group use the IGMP protocol (Internet Group Management Protocol) or the MLD protocol (Multicast Listener Discovery), depending on whether the router works with the version 4 (IPv4) or version 6 (IPv6) of the IP (Internet Protocol), respectively.

[007] When there is a proxy between the host and the router, the proxy also uses the IGMP / MLD protocols to exchange multicast group membership messages with the host, the nearest router or another intermediate proxy. In these cases, the proxy can receive from different hosts requests to subscribe or unsubscribe to a multicast group, and groups them together to reduce the traffic of IGMP / MLD messages that it sends to the router.

[008] On the other hand, the routers exchange messages among themselves in order to define the routing that allows the data to be efficiently routed from the sources to the hosts that have subscribed to a muilticast group. For this, routers use specific protocols, among which the most widespread is PIM-SM (Protocol Independent Muticast - Sparse Mode).

In summary, the routers receive from the hosts, in the form of IGMP / MLD messages, information that specifies which multicast groups they want to receive the traffic from, and they communicate with other routers, for example using the PIM-SM protocol, in order to establish a route that makes the traffic requested by them reach the hosts.

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

[011] The version of the IGMP protocol currently in use is IGMPv3, which is described in the RFC 3376 specifications published online by the IETF (B. Cain et al., Engineering Task Force, Network Working Group, Request for Comments 3376 , October 2002; currently available at the Internet address http://tools.ietf.org/html/rfc3376).

[012] Regarding the MDL protocol, the version currently used is MDLv2, which is described in the RFC 3810 specifications edited online by the IETF (R. Vida et al., Engineering Task Force, Network Working

Group, Request for Comments 3810, June 2004; currently available at the Internet address http://tools.ietf.org/html/rfc3810).

ES 2 358 546 T3

[013] The operation of an IGMP proxy using the IGMP / MLD protocols is described in the RFC 4605 specifications published online by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4605, August 2006; currently available at http://tools.ietf.org/html/rfc4605).

[014] The PIM-SM protocol used for communication between routers is described in RFC 4601 specifications published online by the IETF (B. Fenner et al., Engineering Task Force, Network Working Group, Request for Comments 4601, August 2006; currently available at http://tools.ietf.org/html/rfc4601).

[015] Initially, multicast technology was mainly implemented to apply it to the many-to-many communication model, known as ASM (“Any Source Multicast”), in which many users communicate with each other and any of them can broadcast data and also receive data from everyone else. A typical ASM application is conference calling over the Internet.

[016] Subsequently, musticast technology was implemented to apply it to the one-to-many communication model, known as SSM (“Source Specific Multicast”), in which a single source emits data for many recipients. Radio and television over the Internet are applications of SSM. For this reason, the SSM is currently of great interest.

[017] In the first versions of the IGMP protocol, a host could not choose the data sources to which it wanted to subscribe within a multicast group, but could only subscribe or unsubscribe from the group for all sources. The messages sent by a host to a router were very simple: Join (G) to receive traffic from multicast group G and Leave (G) to stop receiving it. Therefore, the first versions of the IGMP protocol did not allow SSM.

[018] To allow SSM, the IGMPv3 version of the IGMP protocol introduced the possibility that hosts could choose the sources within a multicast group. To do this, a host can send two types of IGMP messages:

- An INCLUDE message, which consists of indicating the IP addresses of the sources from which you do want to receive the data broadcast. The IP addresses of the chosen sources, following the terminology of the RFC 3376 specifications, are called INCLUDE sources.

- An EXCLUDE message, which consists of indicating the IP addresses of the sources from which you do not want to receive the data broadcast. In this case, it is interpreted that the host wants to receive the data emitted by all sources except the sources indicated as excluded in the message. The IP addresses of the excluded sources, also following the terminology of the RFC 3376 specifications, are called EXCLUDE sources.

[019] To save memory, data traffic or for other reasons, in the IGMPv3 version it was decided that each network interface and multicast group could only work in one of the following two modes, being able to switch from one to another: an INCLUDE mode in which the network interface defines an INCLUDE source list or an EXCLUDE mode in which the network interface defines an EXCLUDE source list.

[020] For each multicast group G1, a network interface can receive several different requests. Each request contains, for the same multicast group, an INCLUDE source list or an EXCLUDE source list. To solve this situation, and keep the restriction that each network interface can only work fine in INCLUDE mode or in EXCLUDE mode, the

[021] IGMPv3 protocol establishes that the network interface enforces the following rules:

Rule 1. If any of the data sources in a group G1 is EXCLUDE, then the network interface works in EXCLUDE mode for group G1 and the source list of the network interface is the intersection of the EXCLUDE source lists minus the sources of the INCLUDE lists.

Rule 2. If all sources are of type INCLUDE, then the network interface works in INCLUDE mode for group G1 and the list of sources of the network interface is the union of all INCLUDE sources.

[022] As will be understood later with the description of some embodiments of the invention, these rules considerably complicate communication.

[023] In ASM mutlicast, when a host wants to receive traffic from a specific multicast group G, the following technical problem must be solved: the host only knows the address of the multicast group G and does not know the IP addresses of the sources of that group G that are emitting data. There are different multicast communication protocols between routers that solve this problem in different ways. Currently, the PIM-SM protocol is mainly applied and the problem is solved by designating a router called "Rendezvous Point", hereinafter RP router, as responsible for knowing all the sources of the same multicast domain (set of routers that use the same router RP). To find out the IP addresses of the sources, each router establishes a first multicast communication with the RP router so that it sends the requested multicast traffic. When the router receives the first data of the multicast traffic, it discovers the IP addresses of the sources. Then, the last router, that is, the router that directly receives the IGMP messages from the hosts, tries to receive the data directly from the hosts.

ES 2 358 546 T3 sources using the SPT (Shortest Path Tree) that establishes the shortest path through the network, called the SPT path. When the router begins to receive data in duplicate, both through the RP router and directly through the SPT path, it cuts communication with the RP router and maintains only direct communication through the SPT path.

[024] In SSM the problem of finding out the IP addresses of the sources of a multicast group does not exist, since it is the user who chooses the sources from which they want to receive the multicast traffic. Therefore, the hosts are able to tell the router or proxy the source IP addresses. As a consequence, in SSM it is possible to eliminate numerous technical complexities that are peculiar to ASM. In particular, it is possible to eliminate the technical complexities that are associated with finding out the IP addresses of sources. For example, in SSM it is not necessary to use an RP router, since the routers can know the IP addresses of the sources, which are indicated by the hosts when they subscribe to the multicast group. Therefore, in SSM it is possible to apply more efficient algorithms than those currently used.

[025] The aforementioned rules for the IGMPv3 protocol prevent these advantages of the SSM system from being exploited. When a network interface works in EXCLUDE mode, it does not know the IP addresses of the sources and therefore it is forced to find out these IP addresses through the RP router, as has been previously explained for the ASM, with the disadvantage that routing procedures for the ASM are more complicated.

[026] Recently, the IETF has published a new proposal that modifies the specifications of the IGMPv3 and MLDv2 versions of the IGMP and MDL protocols to try to solve the aforementioned drawbacks, and that is described in the RFC 4604 specifications published online by the IETF (H. Holbrook et al., Engineering Task Force, Network Working Group, Request for Comments 4604, August 2006; currently available at http://tools.ietf.org/html/rfc4604). The proposed modification basically consists in reserving a range for SSM multicast addresses and in imposing that in an SSM multicast system the hosts cannot send EXCLUDE messages. This restriction unnecessarily penalizes the full development of the SSM, since it prevents a host from listening to other new sources within the same multicast group.

[027] Numerous patents or patent applications are known proposing various enhancements to multicast communications. Among them, the following are noteworthy: US6434622B1, US6785294B1, US6977891B1, US2003 / 0067917A1, US2005 / 0207354A1, US2006 / 0120368, US2006 / 0182109A1 and WO2006 / 001803A1. However, none of them solve the problems mentioned above.

Summary of the invention

[028] The main purpose of the invention is to provide an improved multicast communications management system in a data network, especially applicable to SSM communications.

[029] An objective of the invention is to increase the efficiency of the routing between the sending data sources and the hosts that have requested to receive said data broadcasts.

[030] Another objective of the invention is that it can be implemented in the form of an improved host-router multicast communications protocol based on existing protocols and in a manner compatible with previous versions of the latter.

[031] For this purpose, the invention relates to a router according to claim 1.

[032] Preferably, said router uses the information from the lists of included sources included in said messages received by the router to request from other routers the data traffic emitted by said included sources.

[033] Preferably, to request said data traffic issued by said included sources, said router uses the PIM-SIM protocol (Protocol Independent Muticast - Sparse Mode).

[034] In a preferred embodiment, upon receiving a message informing it that some host no longer wishes to receive traffic from a certain multicast group and a certain source included, said router checks if there is a record of sources excluded from said multicast group and if said record exists and does not contain an excluded source with the same IP address as said included source, said router continues to transmit said traffic, of said multicast group and said certain source included, without sending a Group-And-Source Specific Query message in the IGMP protocol to check if there is another host that still wants to receive said traffic.

[035] Likewise, in a preferred embodiment, upon receiving a message to update the information in the excluded sources registry, where said message requests a blocking of traffic from a certain source and multicast group, said router checks if there is a registry of Included sources of said multicast group and if said record exists and contains an included source with the same IP address as the source for which said message has requested a lock, said router continues transmitting said traffic, from said certain multicast group and said certain source, without sending a Group-And-Source Specific Query message in the IGMP protocol to check if there is another host that still wants to receive said traffic.

ES 2 358 546 T3

Brief description of the drawings

[036] Other advantages and characteristics of the invention can be seen from the following description in which, without any limitation, some preferred embodiments of the invention are reported making mention of the accompanying drawings. Figures show:

Fig. 1, a basic example of a multicast system in a data network;

Fig. 2, a more detailed example of a multicast system in a data network;

Fig. 3, the format of the “Membership Query” messages sent by the routers to the hosts in the IGMPv3 protocol, both in the IGMPv3 protocol and in the modified IGMP protocol according to the invention;

Fig. 4, the format of the "Membership Report" messages sent by the hosts to the routers, both in the IGMPv3 protocol and in the modified IGMP protocol according to the invention;

Fig. 5, the internal format of the “Group Record” data blocks contained in each “Membership Query” or “Membership Report” message, in the IGMPv3 protocol;

Fig.6, format of a "Membership Report" message that corresponds 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.

Detailed description of some embodiments of the invention

[037] Fig. 1 shows a basic example of a multicast system in a data network. In this example, three hosts 101, 102, 103 are connected to the data network through CPEs 104, 105 (CPE: Customer-Premises Equipment). A CPE is a network connection terminal located on the subscriber side of an access line, which communicates for example by means of a DSL modem (DSL: Digital Subscriber Line or digital subscriber line). Host 101 is connected to a CPE 104 on one subscriber line, while hosts 102 and 103 are both connected to another CPE 105 on another subscriber line. The CPEs 104, 105 are connected to a DSLAM 106 (DSLAM: Digital Subscriber Line Access Multiplexer) that directs the traffic of the different CPEs 104, 105, through a switch 107, towards a router 108 which, in turn, is connected to an IP network 109 (IP: Internet Protocol). At another point in the IP network 109, another router 110 is connected which concentrates the data packets emitted by sources 111, 112 of a multicast group.

[038] For simplicity, in Fig. 1 a single set formed by several hosts 101, 102, 103 connected to a router 107, and a single group of sources 111, 112 connected to a router 110 has been illustrated. Of course, actually a multicast system is made up of a large number of these sets and groups.

[039] Fig. 1 also shows the scope of each of the IGMP and PIM-SM protocols: the IGMP protocol is applied to communications between receiving hosts and routers, through CPEs and DSLAMs, while The PIM-SM protocol applies to communications between different routers over the IP network.

[040] In this example it has been assumed that the routers work with the IPv4 version of the IP protocol and therefore the system uses the IGMP protocol. However, the reasoning given is also applicable to a system using the MLD protocol (IPv6 version of the IP protocol).

[041] CPEs and DSLAMs are equipment that can perform an IGMP proxy function consisting of receiving several IGMP requests and grouping them to reduce the volume of IGMP messages that are sent to the router. This operation is described in the IETF RFC 4605 specifications mentioned at the beginning.

[042] The basic operation of the multicast system illustrated in Fig. 1 is as follows.

[043] The hosts 101, 102, 103 send to the CPEs 104, 105 IGMP messages in which they identify the multicast address of the group and the addresses of the sources from which they want to receive a data broadcast. The CPEs that receive several IGMP messages from different hosts, as is the case with the CPE 105 in the example of Fig. 1, group these IGMP messages to send a single IGMP message to the DSLAM. For its part, the DSLAM 106 receives IGMP messages from different CPEs, in this case the CPEs 104, 105, and groups them to send to the router 108, through the switch 107, an IGMP message in which they are only indicated, for each multicast group, the INCLUDE or EXCLUDE sources.

[044] The router 108 receives the IGMP message sent by the DSLAM 106 through the switch 107, and communicates with other routers on the IP network using the PIM-SM protocol to establish a route through the IP network that sends up to router 108 the data emitted by the sources that have been specified in the IGMP message received by router 108.

[045] As will be seen below in a more detailed example, in the prior art the router 108 does not always know the IP addresses of the sources that had been specified by the hosts, since this information has been lost when the Network interfaces have bundled the IGPM messages originally sent by hosts. The

ES 2 358 546 T3 router 108 therefore has to find out the IP addresses of the sources using complicated and inefficient procedures.

Operation example of a multicast system that applies the procedures of the prior art (IGMPv3 protocol)

[046] In Fig. 2 a multicast system and the different communications necessary for its operation are shown in more detail.

[047] In order to illustrate the principles and advantages of the invention, starting from the diagram of Fig. 2, the operation according to the prior state of the art, which applies the IGMPv3 protocol, is explained first. Reference will be made later to this same diagram of Fig. 2 to explain the operation according to the invention.

[048] Host 200 is a personal computer PC running two applications 201, 202 that can request multicast traffic. Computer 200 is equipped with a network card 203 that is connected to a CPE 208, which in turn is connected to a DSLAM 240.

[049] Hosts 220 and 225 are two PC personal computers that are each equipped with a network card 222, 223 connected to the same CPE 228, which in turn is connected to DSAM 240. In each computer 220, 225 is runs a single application, respectively 221, 226, which can request multicast traffic.

[050] Host 231 is a STB decoder (STB: Set-Top-Box), connected to a television 230, which allows receiving television channels over the Internet. Decoder 231 is each equipped with a network card 232 connected to a CPE 229 which in turn is connected to DSLAM 240.

[051] DSLAM 240 is connected to router 260 through switch 250. Router 260 is connected to an IP network made up of other routers, which in this example are routers 261, 262, 263, 264, 265, 266 , 267 and 268.

[052] Router 264 is an RP (Rendezvous Point) router, that is, a router used by the PIM-SM protocol to be able to establish the routing between the multicast group broadcast sources and the hosts that wish to receive broadcasts from these sources when they do not know the IP addresses of the latter.

[053] In the example of Fig. 2 there are five broadcast sources 295, 296, 297, 298, 299 that belong to the same multicast group G1. For ease of explanation, in the following these sources are referred to through their respective IP addresses, which are respectively S1, S2, S3, S4 and S5 as indicated in Fig. 2.

[054] Sources S1, S2 and S3 are connected to the IP network through router 266, while sources S4 and S5 are connected through router 262.

[055] Applications 201 and 202 running on host 200 want to receive data broadcasts in multicast group G1, but each application wants to receive broadcasts from different sources:

- application 201 wishes to receive the broadcasts from sources S1 and S2, and for this it will make a request of the INCLUDE type ({S1, S2}; G1);

- the application 202 wishes to receive the broadcasts from all sources except S4, and for this it will make a request of type EXCLUDE ({S4}; G1).

[056] The network card 203 is a network interface that must combine the status of the different sockets associated with applications 201 and 202 applying the rules of the IGMPv3 protocol. Since one of the sockets works in EXCLUDE mode, network interface 203 will only work in EXCLUDE mode and will send the following message to CPE 208: EXCLUDE ({S4}; G1).

[057] In principle, it seems that sending an EXCLUDE message ({S4}; G1) makes it unnecessary to send an INCLUDE message ({S1, S2}; G1), since the former implicitly includes all sources except S4 and therefore both include S1 and S2 sources. However, when operating in this way, valuable information that was contained in the IGMP message sent by application 201 has been lost: the IP addresses of the S1 and S2 sources.

[058] The EXCLUDE message ({S4}; G1) sent by the network card 203 is transmitted up to the DSLAM 240, without the information of the sources being modified by the CPE 208 since it only receives IGMP messages from one source .

[059] The application 221 running on the computer 220 makes a request of type INCLUDE ({S5}, G1), which indicates that it wishes to receive the broadcast from the source S5. The network card 222 does not have to combine several requests, since it only receives requests from the socket that the application 221 is associated with. Therefore, the network card 222 sends the CPE 228 an IGMP message that contains the same information as the application request 221, ie an INCLUDE message ({S5}, G1).

[060] The application 226 running on the computer 225 makes a request of type INCLUDE ({S3}, G1), which indicates that it wishes to receive the broadcast from source S3. The 223 network card does not have to combine multiple requests, as it only

ES 2 358 546 T3 receives requests from the socket to which the application 226 is associated. Therefore, the network card 223 sends the CPE 228 an IGMP message containing the same information as the request from the application 226, that is, a message INCLUDE ({S3}, G1).

[061] The CPE 228 acts as an IGMP proxy, applying the rules of the IGMPv3 protocol to combine the messages sent by the network interfaces 222 and 223, respectively. Since all messages received are of type INCLUDE, the network interface 228 will operate only in INCLUDE mode and will transmit to the DSLAM 240 the following message: INCLUDE ({S3, S5}; G1).

[062] The STB 231 sends the INCLUDE message ({S1}, G1), which indicates that it wishes to receive the broadcast from source S1. CPE 229 transmits this message intact to DSLAM 240, as it receives IGMP messages from a single source.

[063] The DSLAM 240 thus receives the following three IGMP messages:

EXCLUDE ({S4}; G1), from CPE 208

INCLUDE ({S3, S5}; G1), from CPE 228

INCLUDE ({S1}, G1), from CPE 229

[064] The DSLAM 240 is a proxy that must combine these different messages applying the rules of the IGMPv3 protocol. As one of the messages received, referring to multicast group G1, is of type EXCLUDE, the network interface 240 will work only in EXCLUDE mode for said multicast group G1 and will transmit to router 260, through switch 250, the following message: EXCLUDE ({S4}; G1), which indicates that the router 260 must transmit to the DSLAM 240 the broadcasts of all the sources of the group G1, except S4.

[065] The router 260 then communicates with the other routers on the IP network using the PIM-SM protocol to receive the data emitted by the sources requested in the IGMP message, which are all sources of the multicast group G1 except source S4 . The PIM-SM protocol is a complex protocol that allows two types of routing trees to be established: an RTP tree (Rendezvous Point Tree), which has its center in the RP router (which in this case is the 264 router) and an SPT tree (Shorter Path Tree) that sets the shortest path. The RP router is a router designated by the PIM-SM protocol as responsible for knowing the IP addresses of all sources in a multicast group. Initially, router 260 always receives traffic from the multicast group through the RPT tree, since only the RP router knows the IP addresses of the sources. When certain conditions that will be explained below are met, the router 260 switches to using the SPT tree and abandons the transmission through the RP tree.

[066] In the example of Fig. 2, when initially using the RPT tree, the router 260 receives the broadcasts from the sources S1, S2 and S3 through the path 281 indicated in dashed lines, and receives the broadcast from the source S5 through path 282 indicated in broken line. The router 260 is thus receiving the data through the longest paths, instead of the shortest paths according to the STP trees, which are paths 291 and 292 indicated in solid lines.

[067] The router 260 does not know the IP addresses of the included sources, since it has only received an EXCLUDE message ({S4}; G1) from the DSLAM 240. Therefore, router 260 cannot request traffic from included sources using STP trees directly. As already mentioned at the beginning, this is a serious drawback. Another drawback is that if the router works only in SSM multicast, it will not accept the EXCLUDE message. Also, if the router is a simplified router that is only capable of connecting directly to sources, you will not be able to do so if you do not know their IP addresses.

[068] The conditions established by the PIM-SM protocol to change from the RPT tree to an SPT tree for a specific channel (S, G), that is, the channel defined by source S within multicast group G, are detailed in the RFC 4601 specifications, specifically in section 4.2.1 called “Last Hop Switchover to the SPT” that defines a function called CheckSwitchToSpt (S, G):

void

CheckSwitchToSpt (S, G) {if ((pim_include (*, G) (-) pim_exclude (S, G) (+) pim_include (S, G)! = NULL)

AND SwitchToSptDesired (S, G)) {# Note: Restarting the KAT will result in # the SPT switch set KeepaliveTimer (S, G) to # Keepalive_Period ^}^}

ES 2 358 546 T3

[069] The CheckSwitchToSpt (S, G) function has a configurable part, defined by the SwitchToSptDesired (S, G) configurable function, and a non-configurable part. The change from the RPT tree to the SPT tree occurs when both parts of the conditions are met.

[070] Usually, the configurable function SwitchToSptDesired (S, G) is used to establish a threshold for the volume of traffic from source S, so that the change from the RPT tree to the SPT tree is not performed if this threshold has not been exceeded .

[071] The non-configurable part, which is part of the PIM-SM protocol programming code, is the following:

(pim_include (*, G) (-) pim_exclude (S, G) (+) pim_include (S, G)! = NULL)

[072] This non-configurable condition establishes that a router only changes from the RPT tree to the SPT tree for a certain channel (S, G) if there is any network interface of the router that has received an IGMP INCLUDE message (S, G) or if There is a network interface of the router that has received an IGMP message indicating that it wants to receive traffic from all sources in group G, and that network interface has not received an IGMP ExcLuDE (S, G) message. As this non-configurable condition refers only to IGMP messages, the only router that can initiate a switch to the SPT tree to establish a direct connection with the incoming channel router (S, G) is the router that receives the IGMP messages, that is, the router 260 in the example of Fig. 2. In routers that do not receive IGMP messages directly through one of their network interfaces, this condition will never occur, so these routers will never initiate a change to the SPT tree.

[073] In the example of Fig. 2, the only message that router 260 receives is EXCLUDE ({S4}, G1), with which said non-configurable condition is not met. Consequently, the router 260 will not be able to move from the RPT tree to the SPT tree and traffic will continue to go indefinitely on the longer paths 281, 282 through the RP router 264, instead of on the shorter paths 291, 292. The traffic is therefore distributed in an inefficient way, and also the RP router is unnecessarily overloaded.

[074] In summary, this example shows that applying the IGMPv3 protocol rules to combine INCLUDE and EXCLUDE messages negatively affects the efficiency of routing systems. The person skilled in the art will easily understand that this situation also occurs in other multicast systems with combinations different from those shown in Fig. 2.

Modified IGMP protocol according to the invention

[075] The invention solves these problems by applying a modified IGMP protocol so that the network interfaces can transmit the messages sent by the hosts without losing the information contained in said messages.

[076] The modified IGMP protocol according to the invention differs from the IGMPv3 protocol in that the network interfaces can operate in dual mode: they store and transmit separately the information contained in IGMP messages of the INCLUDE type and the information contained in IGMP messages of type EXCLUDE.

[077] The modified IGMP protocol according to the invention is described below. For ease of explanation, reference is made to the description of the IGMPv3 protocol according to the IETF RFC 3376 specifications mentioned at the beginning, and only the changes in the modified IGMP protocol with respect to said IGMPv3 protocol are discussed in detail. The parts that are not detailed comply with the IGMPv3 protocol and are therefore within the reach of a person skilled in the art.

[078] The description has been structured in the following sections:

1) Description of the Interface. Status information. How to group the sources.

2) How to delete a status record.

3) Rules for deriving the registers of the network interfaces.

4) Description of the IGMP messages.

5) Behavior when information in a record changes.

6) Behavior when a host receives a Membership Query message.

7) Description of the protocol for the routers.

8) Compatibility with an IGMPv3 host

9) Improved IGMP proxy

1) Description of the Interface. Status information. How to group the sources.

ES 2 358 546 T3

[079] In the RFC 3376 specifications of the IGMPv3 protocol it is explained that systems must support IGMP messages according to the following function, which allows a host to choose the multicast data sources:

IPMulticastListen (socket, interface, multicast-address, filter-mode, {source-list}) where:

socket is a parameter that allows distinguishing the different applications running on the system and calling the IPMulticastListen function. For example, they can be different applications that run on the same computer connected to the data network.

interface is a local identifier of the network card or network interface in which the multicast data sources to be received are indicated.

multicast-address is the address of the multicast group.

filter-mode is the mode of the network interface, which can be INCLUDE or EXCLUDE. In INCLUDE mode the network interface defines the source-list as INCLUDE; this means that the traffic emitted by all the sources in the list must be sent. In EXCLUDE mode the network interface defines the source-list as EXCLUDE; this means that the traffic of all sources that broadcast in the multicast group must be sent, except the sources in the list.

source-list is the list of INCLUDE or EXCLUDE sources.

[080] The RFC 3376 specifications make it clear that for a given socket, network interface, and multicast group combination, there can only be one filter mode, which can be INCLUDE or EXCLUDE.

[081] The system keeps a status record for each active socket. This record contains the following information:

(interface, multicast-address, filter-mode, {source-list})

[082] For each socket, the registry filter-mode can only be INCLUDE or EXCLUDE.

[083] Also, the system keeps a record for each network interface. This record contains the following information:

(multicast-address, filter-mode, {source-list})

[084] For each network interface and multicast group, the filter-mode of the registry can only be INCLUDE or EXCLUDE. The registers for each network interface are derived from the registers for the sockets. When the registration of a network interface must result from the combination of different registers, the rules that were already exposed at the beginning apply, and which are transcribed below:

Rule 1. If any of the data sources of a group G1 is EXCLUDE, then the network interface will have an EXCLUDE “filter-mode” for group G1 and the list of sources of the network interface is the intersection of the lists EXCLUDE fonts minus the fonts in the INCLUDE lists.

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

[085] So far, the characteristics of the IGMPv3 protocol have been described according to the RFC 3376 specifications.

[086] The modified IGMP protocol according to the invention maintains the same structure of the IPMulticastListen function of the IGMPv3 protocol:

IPMulticastListen (socket, interface, multicast-address, filter-mode, {source-list}) but with the difference that for each socket and each network interface the system saves two registers: one for the EXCLUDE “filtermode” and another for the "filter-mode" InClUDE.

[087] The system thus keeps two registers for each socket:

INCLUDE record: (interface, multicast-address, INCLUDE, {source-list})

EXCLUDE record: (interface, multicast-address, EXCLUDE, {source-list}) and two records for each network interface and multicast group:

INCLUDE record: (multicast-address, INCLUDE, {source-list})

ES 2 358 546 T3

EXCLUDE record: (multicast-address, EXCLUDE, {source-list})

[088] As long as there are only INCLUDE fonts or there are only EXCLUDE fonts, the system only needs one record. But if there are different calls to the IPMulticastListen function for the same multicast group with information from INCLUDE sources and EXCLUDE sources, then the system stores the information in two registers, instead of mixing the information as in the prior art with the IGMPv3 protocol.

[089] Each call to the IPMulticastListen function replaces the contents of the record for a certain multicast group, and if the record does not exist it creates it (this happens, for example, when the function for that multicast group is called for the first time).

2) How to delete a record

[090] In the IGMPv3 protocol, to delete a record from a specific G1 group, an INCLUDE message is sent with an empty source list: INCLUDE ({}, G1). On the other hand, a record in EXCLUDE mode of a certain group G1 switches to INCLUDE mode automatically after a certain time without the need to send any message. To do this, in the IGMPv3 protocol, the records have a timer for each multicast group that is different from zero if the status of the record is EXCLUDE. When the timer reaches zero the register changes from EXCLUDE mode to INCLUDE mode.

[091] In the modified IGMP protocol according to the invention, to delete an INCLUDE record from a certain G1 group the same system is used as in the IGMPv3 protocol: an INCLUDE type message is sent with an empty source list: INCLUDE ({ }).

[092] To automatically delete an EXCLUDE record from a specific G1 group, in the modified IGMP protocol the EXCLUDE records also have a timer for each multicast group, as in the IGMPv3 protocol, but the operation is simpler since it is not necessary to perform a change from INCLUDE mode to EXCLUDE mode: simply, when the timer reaches zero the EXCLUDE register is cleared.

[093] Optionally, the modified IGMP system adds a new system to clear EXCLUDE status records more quickly that applies to:

- the hosts' records, which are updated with the IPMulticastListen function;

- the logs of the proxies and routers, which are updated by means of IGMP messages.

[094] To delete EXCLUDE records using the IPMulticastListen function, a new “filter-mode parameter called Filter_Delete_Exclude has been incorporated into the modified IGMP protocol. When the IPMulticastListen function receives a call with this parameter, it knows that it must delete the EXCLUDE record of the multicast group indicated in the “multicast-address”.

[095] To delete EXCLUDE records from proxies and routers through IGMP messages, in the modified IGMP protocol a new value has been defined for the “Group Record Type” field of the “Membership Report” messages with the following abbreviated description:

DELEX - Type MODE_IS_DELETE_EXCLUDE

This new value is added to the values ​​1 to 6 of the “Group Record Type” field that already exist in the IGMPv3 protocol with the following abbreviated descriptions (section 4.2.12 of the RFC 3376 specifications):

IS_IN (x) - Type MODE_IS_INCLUDE

IS_EX (x) - Type MODE_IS_EXCLUDE

TO_IN (x) - Type CHANGE_TO_INCLUDE_MODE

TO_EX (x) - Type CHANGE_TO_EXCLUDE_MODE

ALLOW (x) - Type ALLOW_NEW_SOURCES

BLOCK (x) - Type BLOCK_OLD_SOURCES where x is the list of IP addresses of the sources.

3) Rules for deriving the registers of the network interfaces

[096] As mentioned in section 1), for each network interface and multicast group, the modified IGMP protocol allows two records to be saved:

INCLUDE record: (multicast-address, INCLUDE, {source-list})

ES 2 358 546 T3

EXCLUDE record: (multicast-address, EXCLUDE, {source-list}) where multicast-address is the address of the multicast group and source-list is the list of sources.

[097] As in the IGMPv3 protocol, the registers of the network interfaces are derived from the registers of the sockets. However, when applying the modified IGMP protocol the process is much simpler since it is not necessary to mix the INCLUDE sources and the EXCLUDE sources of the same multicast group.

[098] For each network interface and multicast group, the modified IGMP protocol applies the following rules:

Rule 1. For each multicast group, each INCLUDE record of the network interface contains the union of all the sources of the INCLUDE records of the sockets that use that network interface.

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

4) Description of IGMP messages

[099] To simplify the explanation, this section describes the IGMP messages between the router and a host, assuming that there is no IGMP Proxy between the two. Later, in section 9, the behavior of an IGMP Proxy will be described.

[100] For communication between a host and a router, the modified IGMP protocol uses the same messages as the IGMPv3 protocol, which are described in section 4 of the RFC 3376 specifications, but with the modifications that are explained later.

[101] Fig. 3 shows the format of the messages sent by the routers to the hosts in the IGMPv3 protocol. These messages are called “Membership Query”. The format shown in Fig. 3 applies to both the IGMPv3 protocol and the modified IGMP protocol.

[102] Fig. 4 shows the format of the messages sent by the hosts to the routers in the IGMPv3 protocol. These messages are called “Membership Report”. The format shown in Fig. 4 applies to both the IGMPv3 protocol and the modified IGMP protocol.

[103] Fig. 5 shows the internal format of the data blocks called "Group Record" that are contained in each "Membership Report" message. The "Group Address" field contains the multicast group address. The “Source Address” fields contain the information about the sources. The "Number of Sources" field indicates the number of "Source Address" fields in each "Group Record". The format shown in Fig. 5 applies to the IGMPv3 protocol.

[104] In the modified IGMP protocol, when a message of the “Membership Report” type is sent, the same message format is used as in the IGMPv3 protocol, but when there are INCLUDE sources and also EXCLUDE sources for the same multicast group, they are sent two “Group Records”, as can be seen in Fig. 6 discussed below. As the sources are not mixed and there can be two records for each network interface and multicast group, the system can issue a message with two different “Group Records” for the same group or multicast address: one of the Group Records transmits the information of the INCLUDE sources and the other conveys the information from the EXCLUDE sources.

[105] In the IGMPv3 protocol, routers send a Membership Query message of the General Query type to interrogate the hosts about their status. In response to this message, hosts send a Membership Report status message of type “Current-State Record”. In the modified IGMP protocol this system is maintained, but the “Current-State Record” message sent by the host can contain two “Group Records” for the same multicast group: one in INCLUDE mode and the other in EXCLUDE mode. The INCLUDE or EXCLUDE mode is identified, as in the IGMPv3 protocol, by the content of the Record Type field, respectively:

Record Type = 1 = MODE_IS_INCLUDE

Record Type = 2 = MODE_IS_EXCLUDE

[106] The information of the two records is thus transmitted in the same "Current-State Record" message.

[107] In the IGMPv3 protocol, hosts send “Source-List-Change Record” messages to report changes to the INCLUDE and EXCLUDE sources. Unlike Current-State Record messages, “Source-List-Change Record” messages are not sent in response to a Membership Query message sent by the router, but rather sent by a host to indicate that a change has occurred. in your font registry.

[108] In the modified IGMP protocol, hosts also send “Source-List-Change Record” messages, as in the IGMPv3 protocol, but with the following difference: as there can be two different records for the same multicast group (an INCLUDE record and an EXCLUDE record) the message “Source-List-Change Record” must indicate which of

ES 2 358 546 T3 the two registers are concerned. For this, in the modified IGMP protocol four new “Group Record Type” are defined, with the following abbreviated expressions:

ALLOWIN (x) - Type ALLOW_NEW_SOURCES_INCLUDE

BLOCKIN (x) - Type BLOCK_OLD_SOURCES_INCLUDE

ALLOWEX (x) - Type ALLOW_NEW_SOURCES_EXCLUDE

BLOCKEX (x) - Type BLOCK_OLD_SOURCES_EXCLUDE where x is the list of IP addresses of the sources.

[109] The new Group Record Type 8 and 9, that is the expressions ALLOWIN (x) and BLOCKIN (x), are used to send messages that add or remove, respectively, elements of the font lists in the INCLUDE registers.

[110] The new Group Record Type 10 and 11, that is, the expressions ALLOWEX (x) and BLOCKEX (x), are used to send messages to allow or block, respectively, the traffic emitted by the source x.

[111] Fig. 6 shows an example of a "Membership Report" message that corresponds to the message sent by the DSLAM 240 to the router 260 in the scheme 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. DSLAM 240 acts as an IGMP Proxy located between router 260 and hosts 200, 220, 225, and 231. Therefore, in this case the preceding explanation about IGMP messages between a router and a host is applied by replacing said host with DSLAM 240. An IGMP Proxy behaves like a host in its communications with an IGMP Router and behaves like an IGMp router in its communications with a host.

[112] The record stored by each equipment in Fig. 2 when the modified IGMP protocol according to the invention is applied is indicated below.

[113] On PC 200, if applications 201 and 202 use socket1 and socket2 respectively, the state registers for socket1 and socket2, respectively, are as follows:

INCLUDE record: (Interface 203, Group G1, INCLUDE, {S1, S2})

EXCLUDE record: (Interface 203, Group G1, EXCLUDE, {S4})

[114] The record for the status of the network interface 203 of the PC 200, which coincides with the status of the network interface of the CPE 208, is as follows:

INCLUDE record: (Group G1, INCLUDE, {S1, S2})

EXCLUDE record: (Group G1, EXCLUDE, {S4})

[115] On PC 220, if application 221 uses socket1, the state register for socket1 is as follows:

INCLUDE record: (Group G1, INCLUDE, {S5})

[116] On PC 225, if application 226 uses socket1, the socket1 status register is as follows:

INCLUDE record: (Group G1, INCLUDE, {S3})

[117] The record of the status of the network interface of the CPE 228 that works as IGMP Proxy, after grouping the sources, is the following:

INCLUDE record: (Group G1, INCLUDE, {S3, S5})

[118] In the STB 231, the status register of the network interface 232, which matches the status of the network interface of the CPE 229, is as follows:

INCLUDE record: (Group G1, INCLUDE, {S1})

[119] Each of the CPEs 208, 228 and 229 sends its IGMP messages to the DSLAM 240, which groups them again but without mixing the INCLUDE and EXCLUDE sources.

[120] The record of the status of the network interface of the DSLAM 240 that works as IGMP Proxy, after grouping the sources, is the following:

INCLUDE record: (Group G1, INCLUDE, {S1, S2, S3, S5})

EXCLUDE record: (Group G1, EXCLUDE, {S4})

ES 2 358 546 T3

[121] In response to a "General Query" message sent by router 260, DSLAM 240 sends router 260 the message depicted in Fig. 6, which is discussed below.

[122] Type = = 0x22 indicates that it is a “Membership Report” and Number of Group Records = 2 indicates that two data blocks or “Group Record” are sent for the same multicast group G1. One of the “Group Records” contains the information of the INCLUDE sources and the other that of the EXCLUDE sources. The first “Group Record” has a “Record Type” equal to 1. This means that it is of the “MODE_IS_INCLUDE” type, that is, it contains the information of the INCLUDE sources. In this data block "Number of Sources" is equal to 4, which means that information from four INCLUDE sources will be sent. The multicast group G1 is indicated in the "Multicast Address" field. The four fields “Source Address [1]” to “Source Address [4]” contain the information of the four INCLUDE sources: S1, S2, S3 and S5. This is followed by a second “Group Record” with a “Record Type” equal to 2. This means that it is of the MODE_IS_EXCLUDE type, that is, it contains the information from the EXCLUDE sources. “Number of Sources” is equal to 1, which means that information from an EXCLUDE source will be sent. The multicast group G1 is indicated in the "Multicast Address" field. The "Source Address [1]" field contains the source information EXCLUDE: S4.

[123] Router 260 has received complete information from all sources. Now the requirements established by the PIM-SM protocol to change from the RPT tree to the SPT tree are fulfilled, as explained below.

[124] By default, the SwitchToSptDesired (S, G) condition of the PIM-SM protocol is configured, which is the configurable part of the change conditions from the RPT tree to the SPT tree for the channel (S, G), so that this condition is met when the first data packet arrives from source S through the SPT tree. The non-configurable condition of said change conditions is always fulfilled when the modified IGMP protocol is applied, since the router interested in receiving the traffic from source S will always have received an IGMP INCLUDE (S, G) message, or will have received a IGMP type message that tells you that you want to receive traffic from all sources in group G and you will not have received an IGmP EXCLUDE (S, G) message.

[125] Therefore, when the modified IGMP protocol is applied, all routers that have received traffic requests for a source can go to the SPT tree and receive the traffic from said source by the shortest path.

[126] Thus, in the example of Fig. 2 the traffic emitted by the sources S1, S2 and S3 will go by the shortest path 291, and the traffic emitted by the source S5 will go by the shortest path 292.

[127] Optionally, the router 260 can connect directly, from the beginning, with the SPT tree of each source S1, S2, S3 and S5, since it knows the IP addresses of these sources and therefore can directly use the SPT tree. To do this, simply make the SwitchToSptDesired (S, G) function always true.

[128] Additionally, optionally, each host can indicate to router 260, in the IGMP message itself, when to initiate the change from the RPT tree to the SPT tree based on each source. For this, according to the invention, a multicast address field is used that is outside the multicast address range and in which a multicast address is not entered, but a message. For example, the first two bytes of the multicast address are set to 0 and the second two bytes are used to send the message to the router, associating these second two bytes with the following meaning:

100 = connect directly via SPT tree

200 = use the default router configuration and evaluate the SwitchToSptDesired (S, G) function to decide to switch to the SPT tree

300 = always use RPT tree and do not switch to SPT tree

[129] The router detects that the address is outside the multicast address range and interprets those 4 bytes as a message that tells it how to change from the RPT tree to the SPT tree in the multicast address that follows in the same "Group Record".

5) Behavior when information in a record changes

[130] In the modified IGMP protocol, when the state record of a network interface changes for a certain multicast group, the system must simply transmit the changes by sending a “Source-ListChange Record” message as indicated in the previous section.

[131] In the IGMPv3 protocol this process is more complex because the system must take into account the filter-mode and its possible changes. This complexity does not exist in the modified IGMP protocol, since the information from the INCLUDE and EXCLUDE sources are stored and transmitted separately.

6) Behavior when a host receives a Membership Query message

[132] In both the IGMPv3 protocol and the modified IGMP protocol, the routers send messages called “Membership Query” to the hosts so that they inform them of the channels and multicast groups they wish to receive. In the modified IGMP protocol, the hosts send a reply message to the routers that is similar to the one

ES 2 358 546 T3 send in the IGMPv3 protocol, but with the difference that the information from the INCLUDE and EXCLUDE sources is sent separately.

[133] To prevent all hosts from responding at the same time, several timers are used that delay the responses of the hosts to distribute them for a period of time that is specified in the "Membership Query" message. This works the same in the modified IGMP protocol and in the IGMPv3 protocol.

[134] There are three types of “Membership Query” messages: General Query, Group-Specific Query and Group-andSource-Specific Query.

[135] General Query messages are sent by the router every so often (by default 125 seconds) so that all hosts report the groups and multicast channels they want to receive by sending “Membership Report” messages called “Current -State Record ”. The messages with which the host responds to a General Query request include blocks of data called Group Records, which can be of two types:

Record Type = 1 MODE_IS_INCLUDE

Record Type = 2 MODE_IS_EXCLUDE

[136] As seen previously, in a single message or “Membership Report”, like the one shown in Fig. 4, several blocks of data called “Group Record” are sent, like the one shown in Fig. 5. The first field in Fig. 5, that is, the “Group Record”, is the “Record Type” field that indicates the meaning of each data block (in the example in Fig. 5, the Record Type field is the field indicated as Type).

[137] In the IGMPv3 protocol, as each multicast group can only be in the INCLUDE state or in the EXCLUDE state, each host only sends, for each multicast group, one “Group Record”, with a Record Type of value 1 or value 2 according to be the status of the group INCLUDE or EXCLUDE, respectively.

[138] In the modified IGMP protocol, thanks to the fact that the information from the INCLUDE and EXCLUDE sources is stored and sent separately, it is possible that a host needs to send two “Group Records” for the same multicast group: a first “Group Record” with Record Type = 1 to report INCLUDE fonts and a second “Group Record” with Record Type = 2 to report EXCLUDE fonts. This can be seen in Fig. 6, where there are two “Group Records” for the same multicast group G1.

[139] For Group-Specific Query and Group-and-Source-Specific Query messages, there is the same difference that has just been explained: when hosts reply to these messages, they can send information separately from the INCLUDE and EXCLUDE sources using two “Group Records”.

7) Description of the protocol for the routers

[140] Operation under the modified IGMP protocol is very similar to that of the IGMPv3 and MLDv2 protocols. For this reason, to facilitate understanding, in what follows the same nomenclature has been adopted as in the RFC 3376 (IGMPv3 protocol) and RFC 3810 (MLDv2 protocol) specifications mentioned at the beginning.

[141] The main difference from the prior art IGMPv3 and MLDv2 protocols is that, in the modified IGMP protocol, the router has two status registers for each multicast group: an INCLUDE record and an EXCLUDE record.

[142] The modified IGMP protocol allows routers to make better use of routing algorithms, since routers receive detailed information from the INCLUDE and EXCLUDE sources from the hosts. Routers run the IGMP protocol on all networks to which they are directly connected. If a multicast router has more than one network interface 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 the router no longer works exclusively in an INCLUDE or EXCLUDE mode for each multicast group and network interface. Therefore, you no longer need all the mechanisms that allowed you to switch from INCLUDE mode to EXCLUDE mode and vice versa.

[143] For each network card or network interface, and multicast group, routers using the modified IGMP protocol store information separated from the INCLUDE and EXCLUDE multicast sources in two registers:

INCLUDE record: (multicast-address, INCLUDE, {list of sources and timers})

EXCLUDE record: (multicast-address, group-timer, EXCLUDE, {list of sources and timers}) where {list of sources and timers} is a list of elements (source-address, source-timer), where source-address is the IP address of a source and source-timer being a timer associated with that source,

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

ES 2 358 546 T3

[145] The two registers, INCLUDE and EXCLUDE, stored in the router therefore contain a timer source-timer associated with each source source-address.

[146] As previously explained in point 2 regarding the ways to delete a record, each EXCLUDE record associated with a multicast group also contains a timer group-timer that is used to eliminate the EXCLUDE status record when a certain time without the router receiving reports with traffic requests of type EXCLUDE.

[147] As previously explained, the routers periodically send the hosts some messages called “Membership Query”, like the one in Fig. 3, so that the hosts reply informing them of the groups and sources from which they wish to receive multicast traffic. . Hosts can also send messages to the router to request multicast traffic without waiting for the host to send a “Membership Query” message.

[148] The router uses timers to ensure that, after having sent a “Group Specific Query” message or a “Group and Source Specific Query” message, all hosts have had enough time to reply to that message. The value of the timers decreases over time and if the router receives a “Membership Report” message from a host, the router restarts the corresponding timers.

[149] In the INCLUDE register, the timers work as follows: for a certain network interface, a certain multicast group and a certain source including source-address, as long as the source-timer is greater than zero, the router will continue transmitting on said network interface channel multicast traffic (source, multicast group); when the “source-timer” reaches zero, the router will stop transmitting such traffic and will remove the source from the INCLUDE source list of that multicast group.

[150] In the EXCLUDE register, the timers work in a similar way, but with the difference that the EXCLUDE sources are classified in two lists: a first list called "Requested List" that contains the sources whose timer source-timer has a higher value. than zero and a second list called “Exclude List that contains the sources whose timer source-timer has value zero.

[151] For each Gi group, the router transmits all the traffic requested by the INCLUDE sources. If there is also an EXCLUDE record for group Gi, the router also transmits all remaining traffic for group Gi except EXCLUDE sources from the Exclude List.

[152] The reason for the existence of a “Requested List” is that in a network with several hosts sending messages to a Router, it may be the case that there is a conflict between the requests from the different hosts. This happens, for example, when one host requests traffic from a certain source and another host requests traffic excluding that source. For example, one host1 sends a first EXCLUDE message ({S1}, G1) and another host2 on the same ethernet network then sends a second EXCLUDE message ({S1, S2, S3}, G1) to the same router. If the router, upon receiving the second message, put the sources of the second message {S1, S2, S3} in the Exclude List, host1 would stop receiving the traffic from sources S2 and S3 that it wanted to receive since it wanted to receive everything the traffic minus that of the S1 source. To avoid this problem, the router only places in the Exclude List the intersection of the font set of the new message with the font set that was in the Exclude List prior to receiving the message. The rest of the EXCLUDE sources go to the Requested List and, optionally, the router sends a Group-And-Source Specific Query message to the hosts to ask if there are any hosts that are still interested in receiving traffic from the S2 and S3 sources from group G1.

[153] The principle of classifying EXCLUDE sources into two lists “Requested List” and “Exclude List according to the value of the timer source-timer is analogous to that applied in the IGMPv3 and MLDv2 protocols. The RFC 3810 (MLDv2 protocol) specifications cited at the beginning contain an explanation of this principle.

[154] Table 1 (at the end of the document) illustrates the operation of an improved router that applies the modified IGMP protocol according to the invention. In its initial state, the router has, for a given multicast group G, two status registers for said multicast group G because it has both INCLUDE sources and EXCLUDE sources. In Table 1, the first column Status 1 shows the initial status of the router's INCLUDE and EXCLUDE registers; the second column Message shows the content of a Membership Report message received by the router; the third column Status 2 shows the status of these router records after having received the Membership Report message; the fourth and last column Actions shows the actions that the router performs after receiving the Membership Report message. The table contains 6 rows, separated from each other by a dashed line. Each row in the table is an example of how the router works from an initial state and depending on the message it has received.

[155] Table 1 refers to each multicast group G independently. Each multicast group G will have its own INCLUDE and EXCLUDE status registers that will be affected by the messages received by the router referring to that group G.

[156] In Table 1 the following nomenclature has been used:

- (A + B) means the union of source sets A and B

ES 2 358 546 T3

- (A * B) means the intersection of the source sets A and B

- (AB) means the set of sources A minus the sources of A that are also in B.

- INCLUDE (A), indicates that the router has an INCLUDE record with a set of sources that we call A

- EXCLUDE (X, Y) indicates that the router has an EXCLUDE status register because there are EXCLUDE sources

- X is the "Requested List"

- Y is the "Exclude List"

- GMI is a parameter called “Group Membership Interval” that contains a time value. By default, it takes a value of 250 seconds.

- LMQT is a parameter named Last Member Query Time that contains a time value. It is the time a host has to reply to a Group-And-Source Specific Query message. After this time, if no host replies that it is interested in this data, the router stops transmitting it.

- T (S) is the timer source timer of source S

- GT is the Group Timer, that is, the timer of the EXCLUDE record for the entire multicast group

- SEND Q (G, S) means that the router sends a Group-And-Source specific Query message to the hosts to check if there are still any hosts interested in the S sources of multicast group G. When it performs this action, the router also decreases the timers of the S sources to the LMQT value. If the router receives in response a message showing interest in any of the S sources, then it initializes the value of the timers of those sources, for which there is an interested host, to an initial value equal to GMI.

[157] An additional advantage of the modified IGMP protocol is that it allows the router to query the two INCLUDE and EXCLUDE registers before sending a Source-And-Group Specific Query message and to remove some sources from the list of message sources, so which may even suppress the message if all sources are removed.

[158] To do this, when the router receives a message of type BLOCKIN (B) as in the example shown in row 4 of Table 1, before performing the SEND Q (G, A * B) action, it can check if it exists an EXCLUDE record for the same group G and remove from the Q (G, A * B) message all the sources that are not in the Exclude List because it means that someone has requested them through an EXCLUDE message.

[159] In the same way, when the router receives a message of type BLOCKEX (B) as in the example shown in row 6 of Table 1, the router can consult the list of sources of the INCLUDE record and use that information to suppress the fonts that appear in the INCLUDE record from the Q (G, BY) message.

[160] These two checks can eliminate a large number of Group-And-Source Specific Query messages, reducing network traffic and the number of messages that hosts and routers have to process.

8) Compatibility with an IGMPv3 host

[161] Routers using the modified IGMP protocol, hereinafter referred to as enhanced routers, can communicate with hosts using the IGMPv3 protocol. For example, an ethernet network may have connected hosts that work with the IGMPv3 protocol and hosts that work with the modified IGMP protocol according to the invention.

[162] For this, an improved router capable of handling the new messages of the modified IGMP protocol also listens to the messages used by the IGMPv3 and MLDv2 protocols that are not used in the modified IGMP protocol.

[163] When the enhanced router receives an ALLOW (B) message, the router behaves as if it had received an ALLOWIN (B) message for the sources of B that are in the INCLUDE register, and behaves as if it had received an ALLOWEX (B) message for B sources that have an EXCLUDE status record.

[164] If the sources of B of the ALLOW (B) message are in both the INCLUDE and EXCLUDE registers of the router, the operation of the router can be configured to behave as if it had received the two messages ALLOWIN (B) and ALLOWEX (B) or as if he had only received one of the two messages. In the router configuration you can choose between these two options.

[165] In the same way, the case in which the router receives a message of the BLOCK (B) type is managed: the operation of the router can be configured to behave as if it had received the two messages BLOCKIN (B) and / or BLOCKEX (B)

ES 2 358 546 T3

[166] When it receives a TO_IN (B) message, the router treats it as if it were an IS_IN (B) message since it does not need to change from INCLUDE to EXCLUDE mode and vice versa since the router can operate in dual mode.

[167] In the same way, when it receives a TO_EX (B) message, the router treats it as if it were an IS_EX (B) message.

9) Improved IGMP proxy

[168] The improved IGMP Proxy according to the invention differs from the IGMP Proxy defined in the cited RFC 4605 specifications in that it stores and transmits separately the information from the INCLUDE and EXCLUDE sources.

[169] For each network interface and multicast group the Enhanced IGMP Proxy can store two records:

INCLUDE record: (multicast-address, INCLUDE, {source list})

EXCLUDE record: (multicast-address, EXCLUDE, {source list})

[170] The function of an IGMP Proxy is to group the messages it receives from its network interfaces connected to the hosts to send a message grouped or summarized by the network interface that connects the IGMP Proxy with the IGMP router or with another IGMP Proxy . Said network interface in the direction of the IGMP router is often called the "upstream" interface.

[171] For this, the IGMP Proxy applies rules that are similar to those explained previously in section 3 to deduce the records of a host's network interface from the sockets records, but with the difference since there are two separate records, one for the INCLUDE sources and one for the EXCLUDE sources, to derive the list of sources from the EXCLUDE source record it is not necessary to take into account the information from the INCLUDE sources, since such information is collected in the INCLUDE source registry.

[172] These rules, which the Enhanced IGMP Proxy applies for 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 the INCLUDE messages referring to that multicast group received on all network interfaces of the Proxy.

Rule 2. For each multicast group, each EXCLUDE record contains the intersection of all the EXCLUDE sources of the EXCLUDE messages referring to that multicast group received on all the proxy network interfaces.

[173] To transmit separately to the router the information of the multicast groups that contain both INCLUDE sources and EXCLUDE sources, the same message system with two Group Records that has been explained in point 4 is used.

[174] The Enhanced IGMP Proxy can work simultaneously with hosts that use the IGMPv3 protocol and with hosts that use the modified IGMP protocol according to the invention.

ES 2 358 546 T3

Table 1

<td>STATE 1</td><td></td><td>MESSAGE</td><td></td><td>STATUS 2</td><td></td><td>ACTIONS</td>

<td>INCLUDE</td><td>(TO)</td><td>IS IN (B)</td><td></td><td>INCLUDE</td><td>(A + B)</td><td>T (B) = GMI</td>

<td>EXCLUDE</td><td>(X, Y)</td><td></td><td></td><td>EXCLUDE</td><td>(X, Y)</td><td></td>

<td>INCLUDE</td><td>(TO)</td><td>IS EX (B)</td><td></td><td>INCLUDE</td><td>(TO)</td><td></td>

<td>EXCLUDE</td><td>(X, Y)</td><td></td><td></td><td>EXCLUDE</td><td>(BY, Y * B)</td><td>T (BXY) = GMI DEL (XB) DEL (YB) GT = GMI</td>

<td>INCLUDE</td><td>(TO)</td><td>ALLOWIN</td><td>B)</td><td>INCLUDE</td><td>(A + B)</td><td>T (B) = GMI</td>

<td>EXCLUDE</td><td>(X, Y)</td><td></td><td></td><td>EXCLUDE</td><td>(X, Y)</td><td></td>

<td>INCLUDE</td><td>(TO)</td><td>BLOCKIN</td><td>B)</td><td>INCLUDE</td><td>(TO)</td><td>SEND Q (G, A * B)</td>

<td>EXCLUDE</td><td>(X, Y)</td><td></td><td></td><td>EXCLUDE</td><td>(X, Y)</td><td>T (A * B) = LMQT</td>

<td>INCLUDE</td><td>(TO)</td><td>ALLOWEX</td><td>B)</td><td>INCLUDE</td><td>(TO)</td><td>T (B) = GMI</td>

<td>EXCLUDE</td><td>(X, Y)</td><td></td><td></td><td>EXCLUDE</td><td>(X + B, YB)</td><td></td>

<td>INCLUDE</td><td>(TO)</td><td>BLOCKEX</td><td>B)</td><td>INCLUDE</td><td>(TO)</td><td>T (BXY) = GT</td>

<td>EXCLUDE</td><td>(X, Y)</td><td></td><td></td><td>EXCLUDE</td><td>(X + (BY), Y)</td><td>SEND Q (G, BY) T (BXY) = LMQT</td>