Information relay device and method with multicast protocol conversion function and information network system using the same

[00002] The present invention relates to an information relay device and method in which an operation for relay of information between a plurality of logical or physical information networks is performed and an information network system which uses such a device or method, and more particularly to an information relay device such as a bridge, router or LAN switch provided with a multicast protocol conversion function in which an operation for relay of multicast information between information networks is performed, an information relay method which is used in such a device and an information network system which uses such a device or method.

[00003] For example, in the field of information communication, a method called multicast communication (or transmission) is generally known as a method for performing the simultaneous delivery (or transmission) of the same data from one host to a plurality of hosts. In the multicast communication, one group is formed by a plurality of hosts and the same data is delivered to all hosts in this group by use of one multicast packet. Also, in TCP/IP (Transmission Control Protocol/Internet Protocol) as a standard protocol in the Internet, there is a technique called IP multicast in which the above multicast communication is used.

[00004] In the IP multicast, a specified IP address called IP multicast address is defined for each group and data is delivered to each host by use of an IP multicast packet with the IP multicast address taken as a receiver (or destination) IP address.

[00005] As one protocol for IP multicast, there is IGMP (Internet Group Management Protocol) described in RFC (Request For Comment) 1112, 2236 and draft (whose last edition on February 1999 is draft-ietf-idmr-igmp-v3-01.txt). The IGMP is a protocol for a request for multicast communication which is made from a host to an adjacent router. With the IGMP, the host is enabled to receive an IP multicast packet.

[00006] The IGMP is a protocol in the third layer (or network layer) of an OSI (Open Systems Interconnect) reference model.

[00007] On the other hand, GMRP (GARP (Generic Attribute Registration Protocol) Multicast Registration Protocol) described in IEEE (Institute of Electrical and Electronics Engineers) 802.1d draft (whose last edition on June 1998 is IEEE802.1d/D17) exists as one protocol for multicast communication in the second layer (or data link layer) of the OSI reference model.

[00008] The GMRP is a protocol for a request for multicast communication in the data link layer which is made from a host to an adjacent bridge or LAN (Local Area Network) switch. With the GMRP, the host is enabled to receive a multicast packet in the data link layer. Hereinafter, this multicast packet in the data link layer will be referred to gas MAC (Media Access Control) multicast packet. A difference between the IGMP and the GMRP lies in that the IGMP is a protocol specified for IP whereas the GMRP is a protocol independent of the network layer.

[00009] The former protocol IGMP mentioned above is standard-wise mounted on, for example, WINDOWS 95, or the like which has come into wide use as an OS for a personal computer or the like. Therefore, the IGMP has a merit that it can easily be utilized. However, since the multicast is performed with an IP address, as mentioned above, it is not possible to perform, for example, delivery or transmission with a construction in an IP subnet taken into consideration. Namely, a multicast packet from a multicast server is equally relayed to not only a host in an IP subnet making a declaration of joining to multicast but also all switches and hosts in the IP subnet to which the declaring host belongs. Accordingly, there is a technical problem that an unavailing traffic in the IP subnet increases due to the multicast.

[00010] A demand for control/reduction of a traffic caused from the multicast becomes greater when the wide use of so-called push type information delivery services using a multicast function in the Internet or the like is taken into consideration.

[00011] In the latter protocol GMRP, on the other hand, the multicast is performed with a MAC address. Therefore, a relay device can selectively relay a multicast packet to only a host making a declaration of joining to the multicast (or a port to which the declaring host is connected), thereby making it possible to avoid the generation of an unavailing traffic. However, a prerequisite is that the GMRP's are mounted on all relay devices or hosts connected to the network. Accordingly, there is a technical problem that easy/convenient wide use or utilization is difficult. Namely, since the number of hosts such as existing personal computers connected to information networks with the wide use of the Internet or the like is very large, it is practically difficult to expect the mounting of GMRP's on all these hosts.

[00012] An object of the present invention is to provide an information relay device and an information relay method which makes it possible to realize a multicast service without increasing the traffic of a network beyond the requisite amount thereof, and an information network system which uses such a device or method.

[00013] Another object of the present invention is to provide an information relay device and an information relay method which makes it possible to realize the simplification of mounting of multicast software in a host connected to a network and utilizing a multicast service, and an information network system which uses such a device or method.

[00014] A further object of the present invention is to provide an information relay device and an information relay method which compatibly enables the suppression of a traffic increase of a network caused from a multicast service and the easy/convenient realization and utilization of the multicast service, and an information network system which uses such a device or method.

[00015] A still further object of the present invention is to provide an information relay device and an information relay method which compatibly enables the simplification of mounting of multicast software in a host connected to a network and the utilization of a variety of multicast protocols, and an information network system which uses such a device or method.

[00016] To that end, in the present invention, an information relay device for performing an operation for relay of information between a plurality of logical or physical networks is provided with a multicast protocol conversion unit for making conversion between different multicast protocols which function in different level layers of a general purpose multicast message protocol, for example, different layer levels of an OSI reference model.

[00017] According to one aspect of the present invention, an information relay device connected between a plurality of logical or physical networks for performing an operation for relay of information between the networks includes a transmit/receive processing unit for receiving a general purpose multicast message from one of the plurality of networks and transmitting a multicast message to at least one of the plurality of networks, and a protocol conversion processing unit for converting, in the case where the general purpose multicast message received by the transmit/receive processing unit is a multicast protocol message of a certain layer, the multicast protocol message of the certain level layer into a multicast protocol message of another level layer.

[00018] With the information relay device of the present invention having such a construction, there is obtained an effect that a multicast service can be realized without increasing the traffic of a network beyond the requisite amount thereof.

[00019] Also, there is obtained an effect that the simplification of mounting of multicast software in a host connected to a network and utilizing a multicast service can be realized.

[00020] Also, there is obtained an effect that the suppression of an increase in traffic in a network caused from a multicast service and the easy/convenient realization and utilization of the multicast service are compatibly enabled.

[00021] Also, there is obtained an effect that the simplification of mounting of multicast software in a host connected to a network and the utilization of a variety of multicast protocols are compatibly enabled.

[00022] According to an example of the present invention, when a multicast protocol (IGMP, DVMRP, MOSPF, PIM-SM, PIM-DM, CBT, MLD or the like) message in the third layer (or network layer) of an OSI reference model is received, the protocol conversion processing unit converts this message into a multicast protocol (GMRP or the like) message in the second layer (or data link layer) and transmits the converted message.

[00023] According to another example of the present invention, when a multicast protocol (GMRP or the like) message in the second layer (or data link layer) is received, the protocol conversion processing unit converts this message into a multicast protocol (IGMP, DVMRP, MOSPF, PIM-SM, PIM-DM, CBT, MLD or the like) message in the third layer (or network layer) and transmits the converted message.

[00024] According to a further example of the present invention, there is provided with a function of performing the conversion from a multicast protocol in the second layer (or data link layer) into a multicast protocol in the third layer (or network layer) for all possible combinations of protocols.

[00025] According to a still further example of the present invention, a conversion table is provided, as required, so that the conversion from a multicast protocol in the second layer (or data link layer) into a multicast protocol in the third layer (or network layer) is made using a prefix portion of a multicast address registered in the conversion table beforehand.

[00026] According to a furthermore example of the present invention, a unit for monitoring a multicast packet flowing in a network and a conversion table are provided so that a prefix portion of a multicast address of the monitored multicast packet is registered into the conversion table and the conversion from a multicast protocol in the second layer (or data link layer) into a multicast protocol in the third layer (or network layer) is made using the prefix portion the multicast address registered in the conversion table.

[00057] Embodiments of an information relay device and method according to the present invention and an information network system using the same will now be described in reference to the accompanying drawings.

[00058] FIG. 1A is a block diagram showing an example of the construction of an information network system including an inter-LAN relay device which is an embodiment of an information relay device according to the present invention.

[00059] In the following description, a conversion between a multicast protocol in the second layer (or data link layer) of an OSI reference model and a multicast protocol in the third layer (or network layer) thereof will be described as an example of a conversion processing performed by the inter-LAN relay device. In the following, the second layer (or data link layer) and the third layer (or network layer) will be denoted by L2 and L3, respectively. Also, the multicast protocols in the second and third layers will be denoted by L2 and L3 multicast protocols, respectively.

[00060] The information network system in the present embodiment is constructed by a plurality of logical or physical networks, for example, local area networks (LAN's) 10 (four LAN's 10A, 10B, 10C and 10D in the example shown in FIG. 1), a plurality of inter-LAN relay devices 20 (three inter-LAN relay devices 20A, 20B and 20C in the example shown in FIG. 1) each connected between the LAN's for performing the operation of relay of information between the LAN'S, terminals 30 (four terminals 30A, 30B, 30C and 30D in the example shown in FIG. 1) such as personal computers or hosts connected to the respective LAN's 10, at least one multicast server 40 connected to any one of the LAN's 10A to 10D for performing multicast packet data communication, and so forth.

[00061] In the present embodiment, each inter-LAN relay device 20 includes, for example, a communication (or transmit/receive) processing unit 21, a conversion processing unit 22, an L2 multicast protocol processing unit 23, a multicast receive processing unit 24, a forwarding processing unit 25, and an L2 multicast information memory, for example, an L2 multicast table 26.

[00062] The communication processing unit 21 controls the communication of information with the corresponding LAN (10A, 10B, etc.) and the external device such as the personal computer 30 or the server 40 through a plurality of ports (20a, 20b, etc.) of the inter-LAN relay device 20.

[00063] The conversion processing unit 22 performs a processing for conversion for a received multicast message from an L3 multicast protocol into an L2 multicast protocol through a processing shown by, for example, a flow chart exemplified in FIG. 4 which will be described later on.

[00064] The L2 multicast protocol processing unit 23 performs a processing for an L2 multicast protocol such as GMRP, as will be described later on in reference to FIG. 11.

[00065] The multicast receive processing unit 24 performs an operation for distribution to a forwarding processing, an L2 multicast protocol processing, a conversion processing and so forth in accordance with the type of a multicast packet through a processing shown by, for example, a flow chart exemplified in FIG. 2 which will be described later on.

[00066] The forwarding processing unit 25 performs an operation of transmitting received relay data to a predetermined receiver (or destination for transmission) as it is.

[00067] The L2 multicast table 26 has a column 26a indicative of an L2 multicast address and a column 26b indicative of a receiver port (or the port of destination for transmission) which corresponds to the L2 multicast address of the column 26a and to which a terminal 30 making a declaration of utilization of a multicast service is connected, as exemplified in FIG. 5.

[00068] Each inter-LAN relay device 20 may be constructed by either hardware or software. In the case where the inter-LAN relay device 20 is constructed by hardware, the processing units 21 to 25 and the table (or memory) 26 may formed by, for example, discrete ASIC's (Application Specific Integrated Circuits) or a single ASIC. In the case where the inter-LAN relay device 20 is constructed by software, the device 20 may be formed by a CPU, a ROM, a RAM and an I/O (input/output) circuit, as shown in FIG. 1B, so that the processing units 22 to 25 are formed by software in the ROM (for example, a program module), the processing unit 21 is formed by software in the ROM (for example, a program module) and the I/O circuit and the table 26 is formed by a part of the ROM or RAM.

[00069] An example of the operation of each inter-LAM relay device 20 in the present embodiment will now be described. Though the following description will be made in conjunction with an example of the operation of the inter-LAM relay device 20A, the similar operation holds for the other inter-LAM relay devices 20.

[00070] First, the operation of the multicast receive processing unit 24 will be described referring to a flow chart shown in FIG. 2.

[00071] The monitoring is first made of whether or not a multicast message is received (step 1001). More particularly, an MAC header of a message received from the server 40 or the personal computer 30 through the LAN 10 and the port is examined to check whether or not the received message is an L2 or L3 multicast message. Namely, if a multicast address (such as an address 01-00-5E as shown in FIG. 5) is included in the MAC header, the judgement of the multicast message as being received is made.

[00072] In the case where the judgement of the multicast message as being not received is made, the processing is completed and a wait is taken for the next message to be received.

[00073] In the case where the judgement of the multicast message as being received is made, the judgement is made of whether or not an L3 multicast protocol message as a protocol control message is received (step 1002). More particularly, the MAC header and an IP header of the received message are examined to check whether or not the received message has an L3 multicast protocol message. Namely, in the case where the received message includes an L3 multicast protocol (for example, IGMP), an MAC header 110a and an IP header 100b of an IGMP message format 100 shown in FIG. 6 are examined to check whether or not the received message is an L3 multicast protocol message.

[00074] In the case where the judgement of the L3 multicast protocol message as being received is made, a processing for converting the L3 multicast protocol message into an L2 multicast protocol message is performed (step 1006), as will be described later on in reference to FIG. 4.

[00075] In the case where the judgement of the L3 multicast protocol message as being not received is made in step 1002, the judgement is made of whether or not an L2 multicast protocol message as a protocol control message is received (step 1003). More particularly, the MAC header of the received message is examined to check whether or not the received message has an L2 multicast protocol message. Namely, in the case where the received message includes an L2 multicast protocol (for example, GMRP), an MAC header 120a of a GMRP message format 120 shown in FIG. 8 is examined to check whether or not the received message is an L2 multicast protocol message.

[00076] In the case where the judgement of the L2 multicast protocol message as being received is made, a processing for L2 multicast protocol is performed (step 1005), as will be described later on in reference to FIG. 11.

[00077] In the case where the judgement of the L2 multicast protocol message as being not received is made in step 1003, the received multicast message is judged as being not the protocol control message but a usual multicast data packet and hence a processing for forwarding to a receiver (or destination for transmission) of that multicast data packet is performed (step 1004), as will be described later on in reference to FIG. 3.

[00078] The forwarding processing performed by the forwarding processing unit 25 will now be described. An example of the forwarding processing will be described using a flow chart shown in FIG. 3. First, an L2 multicast address is read from an MAC header of the received L2 multicast message (or usual L2 multicast data packet) having a format similar to that of the MAC header 120a of FIG. 8 to search an L2 multicast table 26 of FIG. 5 or the like (step 1101) to check whether or not the read L2 multicast address exists in the L2 multicast address columns 26a of the table 26 or the like, that is, whether or not the table search results in a hit (step 1102). In the case where the read L2 multicast address exists in the table 26 or the like, that is, in the case where there results in table hit, receiver ports corresponding to the read L2 multicast address are read from the receiver port column 26a so that the received multicast data packet is relayed (or transmitted) through the transmit/receive processing unit 21 to the read receiver ports (or transmit destination ports) excepting the receiving port (step 1103). Numerals 1, 3, 5 and so forth in the receiver port column 26b shown in FIG. 5 correspond to the receiver ports 20a, 20b and so forth shown in FIG. 1.

[00079] On the other hand, in the case where the read L2 multicast address does not exist in the table 26 or the like, that is, in the case where there results in table mishit, the received multicast data packet is relayed (or transmitted) to all the ports of the inter-LAN relay device 20 through the transmit/receive processing unit 21 or the multicast data packet is revoked (step 1104).

[00080] Next, an example of the conversion processing performed by the conversion processing unit 22 will be described using a flow chart shown in FIG. 4. First or step 1301, an L3 multicast address in the received multicast message (for example, an IP multicast address 10e in an IGMP message format 100 shown in FIG. 6 or an IPv4 multicast address 10e in an IPv4 message format shown in FIG. 10A) is converted into an L2 multicast address (for example, an L2 multicast address 120d in an GMRP message format 120 shown in FIG. 8 or an L2 multicast address 120d in the GMRP message format 120 shown in FIG. 10B). For example, 9 upper bits (4 fixed bits and 5 indeterminate bits) of the IPv4 multicast address 100e shown in FIG. 10A is converted into 25 upper bits (a total of 25 bits including 24 fixed bits of data “01-00-5E” indicative of the multicast message plus 1 bit of “0”) of the L2 multicast address 120d shown in FIG. 10B.

[00081] Next, whether or not the received message is a multicast transmit request is judged from a type value of a message format, for example, a type 100d of an IGMP message format 100 shown in FIG. 6 (step 1302). As shown in FIG. 7, in the case where the type value of the IGMP message 100c is 0x12, 0x16 or 0x22, the type of the message is “VersionX Membership Report” or a transmit request and the updating of the L2 multicast table 26 (see FIG. 5) for entry addition is indicated. On the other hand, in the case where the type value of the IGMP message 100c is 0x17, the type of the message is “VersionX Leave Group” or a transmit refusal request (or is not a transmit request) and the updating of the L2 multicast table 26 (see FIG. 5) for entry deletion is indicated. Also, as shown in FIG. 9, the type of the GMPR message corresponding to the type “VersionX Membership Report” of the GMPR message 100c is “JoinEmpty” or “JoinIn” and the type of the GMPR message corresponding to the type “VersionX Leave Group” of the GMPR message 100c is “LeaveAll” or “LeaveIn”.

[00082] Accordingly, in the case where the received message is the multicast transmit request (for example, in the case where the type value of the IGMP message 100c is any one of 0x12, 0x16 and 0x22), the type value of the IGMP message 100c is rewritten into “JoinEmpty” or “JoinIn”. Thus, the transmit request message 100 of L3 multicast protocol (for example, the type 100d and the IP multicast address 100e of the IGMP message 100c) is rewritten to generate a transmit request message of L2 multicast protocol and to transmit the generated message (step 1304).

[00083] Further, the updating of the L2 multicast table 26 (FIG. 5) for entry addition of the thus generated transmit request message of L2 multicast protocol is performed (step 1305). Namely, the L2 multicast address 120d (FIGS. 8 and 10B) of the generated L2 multicast protocol message is added into the L2 multicast table 26. At this time, the L2 multicast address is written into an entry for the same receiver port (26b) as a receiver port indicated by the L2 multicast address.

[00084] On the other hand, in the case where the received message is not the multicast transmit request, the judgement is made of whether or not the received message is a multicast transmit refusal request (step 1303). For example, in the case where the type value of the IGMP message 100c is 0x17, the message type is “VersionX Leave Group” or the received message is not a multicast transmit request but a multicast transmit refusal request. In the case of the multicast transmit refusal request, the type value of the IGMP message 100c is rewritten into “LeaveAll”, “LeaveEmpty” or “LeaveIn”. Thus, the transmit refusal request message 100 of L3 multicast protocol (for example, the type 100d and the IP multicast address 100e of the IGMP message 100c) is rewritten to generate a transmit refusal request message of L2 multicast protocol and to transmit the generated message (step 1306).

[00085] Further, the updating of the L2 multicast table 26 (FIG. 5) for entry deletion of the thus generated transmit refusal request message of L2 multicast protocol is performed (step 1307). Namely, an entry of the L2 multicast table 26 corresponding to the L2 multicast address 120d (FIGS. 8 and 10B) of the generated L2 multicast protocol message is deleted.

[00086] In the following, specific examples of conversion between L2 and L3 multicast protocols will be described.

[00087] In the case where the L3 multicast protocol is IGMP and the L2 multicast protocol is GMRP, the flow of information takes the course of terminal (transmission of IGMP message)→inter-LAN relay device A (conversion into GMRP message and transmission thereof)→inter-LAN relay device B, as shown by arrow 210 in FIG. 21.

[00088] As exemplified in FIG. 6, an IGMP message format 100 is composed of an MAC header 100a, an IP header 100b and an IGMP message 100c including type 100d, IP multicast address 100e and other 100f. The type (or meaning) of a message indicated by a value set in the type 100d has a relationship as shown by a table 110 in FIG. 7.

[00089] On the other hand, a GMRP message format 120 is composed of an MAC header 120a and a GMRP message 120b including type 120c, L2 multicast address 120d and other 120e, as shown in FIG. 8. The type (or meaning) of a message indicated by the type 120c has a relationship as shown by a table 130 in FIG. 9.

[00090] Accordingly, the following is made in the conversion from the IGMP message into the GMRP message the case of a join message, example, “Membership Report” (0x12/0x16) of the type 100d of IGMP is replaced “JoinIn” (0x2) of the type 120c of GMRP. In the case of a leave message, “Leave Group” (0x17) of the type 100d of IGMP is replaced by “LeaveIn” (0x4) of the type 120c of GMRP.

[00091] Further, the following address conversion is made, as shown in FIGS. 10A and 10B. Namely, in the case 9′ of IPv4, 23 lower bits of the IPv4 multicast address of 32 bits in total (FIG. 10A) are remained as they are while 9 upper bits thereof are replaced by 25 upper bits (including 24 bits on the leading side plus 1 bit of “0”) of the L2 multicast address of 48 bits in total (FIG. 10B).

[00092] FIG. 11 shows a specific example of the flow of the L2 multicast protocol processing in step 1005 of FIG. 2 in the case where the L2 multicast protocol is GMRP.

[00093] Namely, in the case where the received L2 multicast protocol message is “JoinIn” or “JoinEmpty” of GMRP (step 1201), the updating of the L2 multicast table 26 for entry addition is performed (step 1203).

[00094] Also, in the case where the received L2 multicast protocol message is “LeaveIn”, “LeaveEmpty” or “LeaveAll” of GMRP (step 1202), the updating of the L2 multicast table 26 for entry deletion is performed (step 1204).

[00095] FIG. 12 shows a specific example of the flow of the conversion processing in step 1006 of FIG. 2 in the case where the L2 multicast protocol is GMRP.

[00096] Namely, the conversion in the received message from the IP multicast address into the L2 multicast address is made in a method exemplified in FIGS. 10A and 10B (step 1401). In the case of a “Membership Report” message of IGMP (step 1402), a “JoinIn” message of GMRP is generated and transmitted (step 1404). Further, the updating of the L2 multicast table 26 for entry addition is performed (step 1405).

[00097] In the case of a “Leave Group” message of IGMP (step 1403), a “LeaveIn” message of GMRP is generated and transmitted (step 1406). Further, the updating of the L2 multicast table 26 for entry deletion is performed (step 1407).

[00098] In the case where the L3 multicast protocol is MLD and the L2 multicast protocol is GMRP, the flow of information takes the course of terminal (transmission of MLD message)→inter-LAN relay device A (conversion into GMRP message and transmission thereof)→inter-LAN relay device B.

[00099] As exemplified in FIG. 26, this MLD message format 200 is composed of an MAC header 200a, an IPv6 header 200b and an IGMP message 200c including type 200d, IPv6 multicast address 200e and other 200f.

[00100] A value of 131 set in the type 200d represents a “Multicast Listener Report” message indicating a request for joining to a multicast service. A set value of 132 represents a “Multicast Listener Done” message indicating a request for leaving from the multicast service.

[00101] Accordingly, in the case where the conversion from the L3 multicast protocol into the L2 multicast protocol corresponding to FIG. 12 is made, the address conversion as exemplified in FIGS. 16A and 16B is performed by copying a portion of 32 lower bits of the IPV6 multicast address (FIG. 16A) into 32 lower bits of the L2 multicast address (FIG. 16B). Further, the “Multicast Listener Report” message is converted into “JoinIn” or “JoinEmpty” of GMRP of L2. The “Multicast Listener Done” message is converted into “LeaveIn”, “LeaveEmpty” or “LeaveAll” of GMRP.

[00102] The correspondence relationship in conversion between the L2 multicast protocol and the L3 multicast (join/leave protocol) message as mentioned above is shown on the upper stage side of a table 150 of FIG. 20 in conjunction with the case where L2 is GMRP and L3 is IGMP and MLD.

[00103] In the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is DVMRP, the flow of information takes the course of inter-LAN relay device A (transmission of DVMRP message) 4 inter-LAN relay device B (conversion into GMRP message and transmission thereof)→inter-LAN relay device C, as shown by arrow 220 in FIG. 21.

[00104] For DVMRP in this case, a DVMRP message format 160 is composed of an MAC header 160a, an IP header 160b and a DVMRP message 160c including code 160d, IP multicast address 160e and other 160f, as shown in FIG. 22. The meaning of a value set in the code 160d is such that code=7 indicates a Prune message and code=8 indicates a Graft message.

[00105] “Graft” and “Prune” of DVMRP are respectively converted into “Join” system and “Leave” system messages of GMRP, as shown on the lower stage side of the table 150 in FIG. 20.

[00106] In the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is PIM-DM, the flow of information takes the course of inter-LAN relay device A (transmission of PIM-DM message) 4 inter-LAN relay device B (conversion into GMRP message and transmission thereof) →inter-LAN relay device C.

[00107] For PIM-SM/DM in this case, a PIM-SM/DM message format 170 is composed of an MAC header 170a, an IP header 170b and a PIM-SM/DM message 170c including type 170d, IP multicast address 170e and other 170f, as shown in FIG. 23. The meaning of a value set in the type 170d is such that type=3 indicates a Join/Prune message and type=6 indicates a Graft message.

[00108] “Graft” and “Join”/“Prune” of PIM-DM are respectively converted into “Join” system and “Leave” system messages of GMRP, as shown on the lower stage side of the table 150 in FIG. 20.

[00109] In the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is PIM-SM, the flow of information takes the course of inter-LAN relay device A (transmission of PIM-SM message)→inter-LAN relay device B (conversion into GMRP message and transmission thereof) →inter-LAN relay device C.

[00110] A message format in this case has already been described in conjunction with FIG. 23. “Join”“Prune” of PIM-SM is converted into “Join” system and “Leave” system messages of GMRP, as shown on the lower stage side of the table 150 in FIG. 20.

[00111] In the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is CBT, the flow of information takes the course of inter-LAN relay device A (transmission of CBT message) →inter-LAN relay device B (conversion into GMRP message and transmission thereof)→inter-LAN relay device C.

[00112] For CBT in this case, a CBT message format 180 is composed of an MAC header 180a, an IP header 180b and a CBT message 180c including type 180d, IP multicast address 180e and other 180f, as shown in FIG. 24. The meaning of a value set in the type 180d is such that type=1 indicates a JOIN_REQUEST message and type=3 indicates a QUIT_NOTIFICATION message.

[00113] “JOIN_REQUEST” and “QUIT_NOTIFICATION” of CBT re respectively converted into “Join” system and “Leave” system messages of GMRP, as shown on the lower stage side of the table 150 in FIG. 20.

[00114] In the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is MOSPF, the flow of information takes the course of inter-LAN relay device A (transmission of MOSPF message)→inter-LAN relay device B (conversion into GMRP message and transmission thereof) inter-LAN relay device C.

[00115] For MOSPF in this case, an MOSPF message format 190 is composed of an MAC header 190a, an IP header 190b and an MOSPF message 190c including type 190d, IP multicast address 190e and other 190f, as shown in FIG. 25. The meaning of a value set in the type 190d is such that type=6 indicates a Group-membership-LSA message.

[00116] “Group-membership-LSA” of MOSPFT is converted into a “Join” system message of GMRP, as shown on the lower stage side of the table 150 in FIG. 20.

[00117] A general receive processing flow in the case of a processing for conversion from the L2 multicast protocol into the L3 multicast protocol is shown in FIG. 13 (which corresponds to FIG. 2). This processing is performed by a receive processing unit 24 shown in FIG. 17 which will be described later on.

[00118] First, the presence/absence of reception of an L2 multicast message is monitored (step 1501). In the case where the L2 multicast message is received, the judgement is made of whether or not the received message is an L2 multicast protocol message (step 1502). In the case where the received message is an L2 multicast protocol message, an L2 multicast protocol processing as exemplified by the flow chart of FIG. 11 having already been mentioned is performed (step 1504) and a processing for conversion into an L3 multicast protocol is performed (step 1505).

[00119] In the case where the judgement of the received message as being not an L2 multicast protocol message is made in step 1502, there is performed a forwarding processing similar to that in step 1004 of FIG. 2 in which the message is forwarded to the destination for relay as it is (step 1503).

[00120] In the conversion processing in step 1505, there is performed a processing exemplified by a flow chart in FIG. 14.

[00121] First, the multicast address conversion from L2 to L3 is made in a method exemplified in FIGS. 10A and 10B or FIGS. 16A and 16B (step 1601). Next, in the case where a received L2 message is a multicast transmit request (step 1602), a transmit request message of L3 multicast protocol having an equivalent meaning is generated and transmitted to the destination for relay (step 1604). In the case where the received L2 message is not a multicast transmit request, the examination is made of whether or not the message is a multicast transmit refusal request (step 1603). In the case where the message is a multicast transmit refusal request, a transmit refusal message of L3 multicast protocol having an equivalent meaning is generated and transmitted to the destination for relay (step 1605).

[00122] A more specific example of the conversion processing will be described by use of a flow chart in FIG. 15 in conjunction with the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is IGMP.

[00123] The flow of information in this case takes the course of terminal (transmission of GMRP message)→inter-LAN relay device A (conversion into IGMP message and transmission thereof) →inter-LAN relay device B, as shown by arrow 230 in FIG. 21.

[00124] First, the multicast address conversion from L2 to L3 is made in a manner similar to that in FIGS. 10A and 10B (step 1701). Next, in the case where a received L2 multicast protocol message is “JoinIn” or “JoinEmpty” of GMRP (step 1702), a “Membership Report” message of IGMP for L3 equivalent thereto is generated and transmitted to the destination for relay (step 1704).

[00125] In the case where the received L2 multicast protocol message is “LeaveIn” or “LeaveEmpty” of GMRP (step 1703), a “Leave Group” message of IGMP for L3 equivalent thereto is generated and transmitted to the destination for relay (step 1705).

[00126] Also, in the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is MLD. The flow of information in this case takes the course of terminal (transmission of GMRP message)→inter-LAN relay device A (conversion into MLD message and transmission thereof)→inter-LAN relay device B. In this case, in the above-mentioned conversion processing in step 1704, “Multicast Listener Report” of MLD is generated and transmitted. Also, in the processing in step 1705, “Multicast Listener Done” is generated and transmitted.

[00127] In the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is DVMRP, the flow of information takes the course of terminal (transmission of GMRP message)→inter-LAN relay device A (conversion into DVMRP message and transmission thereof) →inter-LAN relay device B, as shown by arrow 240 in FIG. 21. “Join” system and “Leave” system messages of GMRP are converted into “Graft” and “Prune” of DVMRP, respectively.

[00128] Similarly, in the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is PIM-SM, the flow of information takes the course of terminal (transmission of GMRP message)→inter-LAN relay device A (conversion into PIM-SM message and transmission thereof) →inter-LAN relay device B. “Join” system and “Leave” system messages of GMRP are converted into “Join”/“Prune” of PIN-SM.

[00129] Similarly, in the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is PIM-DM, the flow of information takes the course of terminal (transmission of GMRP message) 4 inter-LAN relay device A (conversion into PIM-DM message and transmission thereof) →inter-LAN relay device B. “Join” system and “Leave” system messages of GMRP are converted into “Graft” and “Join”/“Prune” of PIM-DM, respectively.

[00130] Similarly, in the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is CBT, the flow of information takes the course of terminal (transmission of GMRP message)→inter-LAN relay device A (conversion into CBT message and transmission thereof)→inter-LAN relay device B. “Join” system and “Leave” system messages of GMRP are converted into “JOIN REQUEST” and “QUIT NOTIFICATION” of CBT, respectively.

[00131] Similarly, in the case where the L2 multicast protocol is GMRP and the L3 multicast protocol is MOSPF, the flow of information takes the course of terminal (transmission of GMRP message) 4 inter-LAN relay device A (conversion into MOSPF message and transmission thereof) →inter-LAN relay device B. A “Join” system message of GMRP is converted into “Group-membership-LSA” of MOSPF.

[00132] Next, the reference to FIGS. 17, 18, 19 and so forth will be made to show an example in which multicast packets flowing on the information network system are monitored to collect and register prefix portions of multicast addresses so that the registered prefix address portion is utilized in a processing for conversion from an L2 multicast protocol into an L3 multicast protocol.

[00133] As exemplified in FIG. 17, each of the inter-LAN relay devices 20 (20A, 20B, 20C, - - - ) shown in FIG. 1 is additionally provided with a monitor processing unit 27 for monitoring an L3 multicast packet to be relayed, thereby extracting a prefix portion of its multicast address (for example, 9 leading bits of IPv4 in FIG. 10A or 96 leading bits of IPv6 in FIG. 16A), and a multicast address memory such as a conversion table 140 (28) for storing the extracted prefix address. The monitor processing unit 27 may be formed by an ASIC or program, and the table 140 may be formed by an ASIC or a part of ROM or RAM.

[00134] As exemplified by a flow chart shown in FIG. 19, the monitor processing unit 27 monitors whether or not an IP multicast packet of L3 is received (step 1801). When it is received, the monitor processing unit 27 reads a prefix address portion of an IP multicast address and stores it into the conversion table 140 (see FIG. 18) for each type (step 1802).

[00135] In generating an IP multicast address 100e at the time of conversion from a GMRP message of L2 into an IGMP message of L3 (as shown in FIG. 6), for example, as in step 1601 of the flow chart of FIG. 14 (corresponding to that of FIG. 4) or step 1701 of the flow chart of FIG. 15 (corresponding to that of FIG. 12), the corresponding data registered in the conversion table 140 is used for generating 9 upper bits other than 23 lower bits (in the case of FIG. 10A) of the IP multicast address taken over from the GMRP message or 96 upper bits other than 32 lower bits (in the case of FIG. 16A) thereof.

[00136] Next, the reference to FIGS. 27 and 28 will be made to describe an actual operation in which after a processing for a request for joining to multicast service transmitted from a specified terminal 30 is performed in the above-mentioned processing for conversion between L2 and L3 multicast protocols, a multicast packet transmitted from a multicast server 40 is selectively relayed to the terminal 30.

[00137] An L3 multicast memory such as an L3 multicast table 250 exemplified in FIG. 27 is stored with an IP multicast address 250a as a destination address and a corresponding receiver IP subnet 250b having the list of one or plural subnet masks for specifying one or plural subnets to which a multicast packet with that multicast address is to be relayed.

[00138] Though not shown in FIG. 1 or 17, the L3 multicast table 250 is mounted on the inter-LAN relay device 20 (20C) which functions as a router for performing an L3 relaying operation for the widely used L3 multicast protocol such as IGMP. The table 250 may be formed by an ASIC, ROM or RAM.

[00139] First, when an IP multicast packet is received (step 1901), the L3 multicast table 250 is searched using the received multicast address (step 1902). In the case where there results in a hit, 23 lower bits of a value registered in the L2 multicast address column 26a of the L2 multicast table 26 (see FIG. 5) are searched by use of 23 lower bits of the IP multicast address (step 1903). In the case where there results in a hit, the IP multicast packet is selectively relayed to a terminal 30 connected to a receiver port stored in the receiver port column 26b of the table 26 (step 1904).

[00140] In the case where the search in step 1902 or 1903 results in a mishit, the IP multicast packet is revoked (step 1905).

[00141] In connection to the above-mentioned conversion between the multicast protocols of L2 and L3 levels in the present invention, FIGS. 29A and 29B and FIGS. 30A and 30B show a processing for conversion and transmission of a multicast service join message (or pre-procedure) and the behavior of traffic reduction in an actual multicast packet transmission control processing performed after this pre-procedure.

[00142] FIGS. 29A and 29B correspond to the case where each of all inter-LAN relay devices 20 (switches) is provided with a function of multicast protocol conversion between L2 and L3 in the present invention.

[00143] The pre-procedure in this case is performed as shown in FIG. 29A. Namely, in an inter-LAN relay device 20 (20A) connected to a terminal 30 and functioning as an L2 level switch, IGMP of L3 level transmitted from the terminal 30 is converted into GMRP of L2 level. The GMRP of L2 level is transmitted from the inter-LAN relay device 20 (20A) to the other inter-LAN relay devices 20 (20B, 20C, - - - ). The original IGMP of L3 level is also transmitted to the other inter-LAN relay devices 20 (20B, 20C, - - - ) after passed through the inter-LAN relay device 20 (20A) as it is.

[00144] After the execution of the above pre-procedure, an IP multicast packet arriving the inter-LAN relay device 20 (20C) on the backbone side from a multicast server 40 is selectively transmitted to only the terminal 30 in the IP subnet, as shown in FIG. 29B, as if the terminal 30 supported the multicast protocol of L2 level even in the case where the terminal 30 is not provided with a function of processing GMRP of L2 level.

[00145] FIGS. 30A and 30B correspond to the case where only an inter-LAN relay device 20 (20C) on the backbone side is provided with a function of multicast protocol conversion between L2 and L3 in the present invention.

[00146] In this case, as shown in FIG. 30A, IGMP of L3 level transmitted from a terminal 30 is passed through an inter-LAN relay device 20 (20A) connected to the terminal 30 and functioning as an L2 level switch and is thereafter transmitted to the inter-LAN relay device 20 (20C) on the backbone side. In the inter-LAN relay device 20 (20C), the IGMP of L3 level transmitted from the terminal 30 is converted into GMRP of L2 level. The GMRP of L2 level is transmitted to all the inter-LAN relay devices 20 (20A, 20B, 20C, - - - ).

[00147] After the execution of the above pre-procedure, an IP multicast packet arriving the inter-LAN relay device 20 (20C) on the backbone side from a multicast server 40 is selectively transmitted to only the terminal 30 in the IP subnet, as shown in FIG. 30B, as if the terminal 30 supported the multicast protocol of L2 level even in the case where the terminal 30 is not provided with a function of processing GMRP of L2 level.

[00148] Thus, according to the information relay device in the present embodiment, with a construction in which a multicast protocol of L3 level such as IGM which has come into wide use in association with a general purpose OS for a personal computer or the like is converted into a multicast protocol of L2 level such as GMRP which has not yet come into so wide use but is capable of a service for selective delivery of a multicast protocol, it is possible to realize a multicast service with a reduced traffic resulting from the selective delivery of a multicast packet in a subnet by the multicast protocol of L2 level. Namely, it becomes possible to realize a multicast service without increasing the traffic in a subnet beyond the requisite amount thereof.

[00149] Also, with a construction in which a multicast protocol of L2 level such as GMRP or the like the degree of utilization of which is low as yet is mounted on only inter-LAN relay devices 20 such as bridges or routers the number of which is relatively small, even if such a multicast protocol of L2 is not mounted on a large number of terminals 30 such as hosts connected to information networks, it is possible to realize the selective delivery of a multicast packet in a subnet by the multicast protocol of L2 level. Namely, it is possible to realize the simplification of mounting of multicast software in a host connected to a network and utilizing a multicast service.

[00150] In other words, there are compatibly enabled the suppression of an increase in traffic in a network which is caused from a multicast service and the easy/convenient realization and utilization of the multicast service which results from the simplification of mounting of multicast software on a terminal such as a host connected to the network.

[00151] Further, with a construction in which software for performing the conversion between multicast protocols of L2 and L3 levels is merely mounted on inter-LAN relay devices 20 the number of which is small as compared with that of terminals, the utilization of a variety of multicast protocols in a network becomes possible. Namely, there are compatibly enabled the simplification of mounting of multicast software in a host connected to a network and the utilization of a variety of multicast protocols.

[00152] In the foregoing, the present invention has been disclosed on the basis of the embodiments thereof. However, it is needless to say that the present invention is not limited to the disclosed embodiments and various changes or modifications are possible in a rage which does not depart from the gist of the present invention.

[00153] For example, the multicast protocols of L2 and L3 levels made the object of conversion processing in the present invention are not limited to those exemplified in the foregoing embodiments. There can also be applied to other protocols so long as the conversion is made so that essential information in a protocol message concerning a multicast service is logically reserved in conversion between L2 and L3 levels.

[00154] In the case where each inter-LAN relay device 20 in the foregoing embodiments is formed by software, as shown in FIG. 1B, processing programs and data shown in FIGS. 2 to 12 and so forth may be installed later on instead of being installed in the ROM (and RAM) of the inter-LAN relay device beforehand. Namely, such processing programs and data may be recorded in a recording medium such as a CD-ROM. The programs and data recorded in the recording medium can be written into the ROM (and RAM) of the inter-LAN relay device 20 by setting the recording medium on a recording medium reading unit 151 connected to the inter-LAN relay device 20 and connecting the recording medium reading unit 151 to the I/O circuit of the inter-LAN relay device 20. Alternatively, such processing programs and data may be loaded down onto the ROM (and RAM) of the inter-LAN relay device 20 through the network so that they are written thereinto.