Multicast system, multicast method, and program

Abstract

A communication system 1 includes relay devices 20 and 30 that participate in an IP multicast network. The relay device 20 receives a multicast packet from a terminal 10 and sends out the multicast packet to the IP multicast network. The relay device 30 receives the multicast packet and distributes the multicast packet to a terminal 40. The relay device 30 holds membership information that associates a process with a multicast group in which the process participates, and connection information that associates a process with a connection established between the process and the relay device 30. The relay device 30 receives a multicast packet, refers to membership information to extract processes associated with a multicast group of the multicast packet, refers to connection information for each of the extracted processes to extract a connection associated with that process, and, using each of the extracted connections, converts and forwards the multicast packet so that the multicast packet can be transmitted via that connection.

Description

Multicast system, multicast method, and program

[0001] The present disclosure relates to a multicast system, a multicast method, and a program.

[0002] Remote Direct Memory Access (RDMA), which transfers data directly to memory without going through the CPU, is known as a communication method that achieves high speed and low latency.

[0003] Xin Zhe Khooi, Cha Hwan Song, and Mun Choon Chan, "Towards a Framework for One-sided RDMA Multicast," ANCS '21, December 13-16, 2021Wenxue Li, Junyi Zhang, Gaoxiong Zeng, Yufei Liu, Zilong Wang, Chaoliang Zeng, Pengpeng Zhou, Qiaoling Wang, and Kai Chen, "Gleam: An RDMA-accelerated Multicast Protocol for Datacenter Networks," 2023

[0004] Multicasting is also desired for RDMA. However, the current InfiniBand standard only supports multicasting in the UD (Unreliable Datagram) service type, and does not support it in other service types, namely, RC (Reliable Connection), RD (Reliable Datagram), and UC (Unreliable Connection). This is because, in connection-oriented multicast, if all receivers establish end-to-end connections with the sender in one-to-many communication, the number of connections increases too much, making it unscalable. Also, unlike IP multicast, RDMA packet headers (e.g., InfiniBand (IB) headers) may contain values ​​that cannot be aligned across multiple receivers, such as the destination memory address and packet sequence number, which makes it impossible to multicast the same packet to the end.

[0005] Non-Patent Document 1 proposes a technology to rewrite the IB header for each terminal. However, Non-Patent Document 1 only supports multicast at the IB level, and technical considerations for the use of IP multicast have not progressed. Furthermore, it does not address the issue of scalability that arises when the number of connections increases.

[0006] Non-Patent Document 2 advances technical studies up to IP-level multicast. It also proposes a method for aggregating information about connections established end-to-end and reconstructing a simple multicast distribution tree. However, it is unable to handle multiple connections belonging to the same multicast group on a single port. Non-Patent Document 2, however, allows the use of multiple connections by establishing multiple connections via different ports on the same Network Interface Card (NIC) or via different ports on different NICs. However, since Non-Patent Document 2 simply duplicates packets and forwards them to each of the multiple connections, it is unable to implement link aggregation functionality, which bundles the duplicated connections and treats them as a single high-speed line.

[0007] The present disclosure has been made in view of the above, and aims to realize a multicast system that can be flexibly configured.

[0008] A multicast system according to one aspect of the present disclosure is a multicast system including a first communication device and a second communication device participating in a multicast network, wherein the first communication device converts a unicast packet received from a first member connected to the first communication device into a multicast packet and sends it to a relay network, and the second communication device holds membership information associating a second member connected to the second communication device with a multicast group in which the second member participates, and connection information associating the second member with a connection established between the second member and the second communication device, receives the multicast packet from the relay network, refers to the membership information to extract at least one or more second members associated with the multicast group of the multicast packet, and for each of the extracted second members, refers to the connection information to extract at least one or more connections associated with the second member, and uses each of the extracted connections to convert the multicast packet into a unicast packet and forward it via the connection.

[0009] According to the present disclosure, a multicast system that can be flexibly configured can be realized.

[0010] FIG. 1 is a diagram illustrating an example of the overall configuration of a communication system. FIG. 2 is a diagram illustrating an example of RDMA. FIG. 3 is a diagram illustrating an example of the configuration of a transmitting-side relay device. FIG. 4 is a diagram illustrating an example of an address correspondence table. FIG. 5 is a diagram illustrating an example of the configuration of a receiving-side relay device. FIG. 6 is a diagram illustrating an example of membership information. FIG. 7A is a diagram illustrating an example of connection information. FIG. 7B is a diagram illustrating an example of connection information. FIG. 8 is a diagram illustrating an example of data transfer type information. FIG. 9 is a diagram illustrating an example of an operating status of a communication system. FIG. 10 is a diagram illustrating an example of information related to the connection of a transmitting-side terminal. FIG. 11 is a diagram illustrating an example of information related to the connection of a transmitting-side relay device. FIG. 12A is a diagram illustrating an example of information related to the connection of a receiving-side relay device. FIG. 12B is a diagram illustrating an example of information related to the connection of a receiving-side terminal. FIG. 13A is a diagram illustrating an example of information related to the connection of a receiving-side terminal. FIG. 13B is a diagram illustrating an example of information related to the connection of a receiving-side terminal. FIG. 14 is a sequence diagram illustrating an example of a process in which a receiving-side terminal and a relay device establish a connection. FIG. 15A is a diagram illustrating an example of a join request. FIG. 15B is a diagram illustrating an example of a join request. FIG. 16 is a diagram showing an example of membership information. FIG. 17A is a diagram showing an example of a connection establishment request. FIG. 17B is a diagram showing an example of a connection establishment request. FIG. 18A is a diagram showing an example of connection information. FIG. 18B is a diagram showing an example of connection information. FIG. 19A is a diagram showing an example of a connection establishment response. FIG. 19B is a diagram showing an example of a connection establishment response. FIG. 20A is a diagram showing an example of a SEND operation. FIG. 20B is a diagram showing an example of a SEND operation. FIG. 21 is a diagram showing an example of data transfer type information. FIG. 22 is a sequence diagram showing an example of a process for maintaining a multicast group. FIG. 23 is a sequence diagram showing an example of a process for leaving a multicast group. FIG. 24 is a sequence diagram showing an example of a process for establishing a connection between a transmitting terminal and a relay device. FIG. 25 is a diagram showing an example of an address correspondence table. FIG. 26 is a sequence diagram showing an example of a multicast packet forwarding process.Fig. 27 is a sequence diagram showing an example of a multicast packet forwarding process. Fig. 28 is a flowchart showing an example of a packet forwarding process for each process ID. Fig. 29 is a flowchart showing an example of a header generation process and a packet forwarding process. Fig. 30 is a flowchart showing an example of a header generation process and a packet forwarding process. Fig. 31 is a flowchart showing an example of a header generation process and a packet forwarding process. Fig. 32 is a diagram showing an example of the hardware configuration of a terminal and a relay device.

[0011] [Communication System] An example of a communication system 1 according to the present embodiment will be described with reference to Fig. 1. The communication system 1 includes transmitting terminals 10A and 10B, a transmitting relay device 20, receiving relay devices 30A and 30B, and receiving terminals 40A, 40B, 40C, and 40D. Hereinafter, when there is no need to distinguish between the terminals 10A and 10B, the relay devices 30A and 30B, and the terminals 40A, 40B, 40C, and 40D, they will be referred to as the terminal 10, the relay device 30, and the terminal 40.

[0012] Packets sent from terminal 10 are relayed by relay devices 20 and 30 and delivered to each terminal 40. FIG. 1 shows how packets containing data to be sent to members of multicast group A and packets containing data to be sent to members of multicast group B are distributed. Terminal 10A unicasts packets containing data to be sent to members of multicast group A, and terminal 10B unicasts packets containing data to be sent to members of multicast group B. The correspondence method between unicast packets transferred between terminals and relay devices and their destination multicast groups will be described later. Relay device 20 converts each unicast packet received from terminal 10 into multicast packets addressed to multicast groups A and B, and then transmits them to the IP multicast network (wide area network). Relay device 30 receives multicast packets addressed to multicast groups A and B from the IP multicast network, converts them into unicast packets, and then transmits them to terminal 40. In the example of FIG. 1, terminal 40A receives unicast packets addressed to members of multicast group A and unicast packets addressed to members of multicast group B. The terminals 40B and 40C receive unicast packets addressed to members of multicast group B. The terminal 40D receives unicast packets addressed to members of multicast group A.

[0013] Multiple relay devices 20 and 30 exist on the IP multicast network. A multicast distribution tree is constructed between the IP multicast network and the relay devices 20 and 30. The IP multicast routing protocol used in the IP multicast network is Protocol Independent Multicast (PIM), but is not limited to this. Messages in a format similar to Internet Group Management Protocol (IGMP) are used to join and leave a multicast group. However, a process ID value that does not exist in IGMP is added. Although only one relay device 20 is shown on the sending side in FIG. 1, multiple relay devices 20 may also be provided on the sending side.

[0014] Unicast connections are used between the terminal 10 and the relay device 20, and between the terminal 40 and the relay device 30, and data transfer is performed by RDMA. More specifically, the RoCEv2 protocol is used to transfer RDMA packets over IP.

[0015] The terminal 10 transmits a unicast packet to the relay device 20 by RDMA.

[0016] The relay device 20 maintains an address correspondence table that associates RDMA destination information with multicast group destination information. The relay device 20 refers to the address correspondence table, converts unicast packets received from the terminal 10 into multicast packets addressed to the corresponding multicast group, and transmits the packets to the IP multicast network.

[0017] In the IP multicast network, packets are replicated, and each of the relay devices 30 receives packets from the multicast group.

[0018] The relay device 30 holds membership information that manages multicast groups for each process running on the terminal 40 and connection information that manages RDMA connections between processes. The relay device 30 references the membership information to extract processes to which multicast packets received from the IP multicast network should be distributed, references the connection information for each extracted process to extract connections established with the process, and converts the received multicast packets into unicast packets using each extracted connection, and then transfers them to the process by RDMA.

[0019] A process is an instance of a program running on the terminal 40. A process may also be called an application. Multiple processes may run on the terminal 40, and each process may join a different multicast group. The terminal 40 or a process may also be called a member that joins a multicast group.

[0020] Furthermore, the relay device 30 holds data transfer type information that specifies a data transfer type for each process, and when one process establishes multiple connections, it flexibly utilizes those connections. Specifically, the data transfer type information is set for each process as to whether multiple connections are to be integrated and used as link aggregation, or whether they are to be used to ensure redundancy.

[0021] [RDMA] Data transfer using the RDMA SEND operation will be explained with reference to Figure 2. In RDMA, a terminal that sends or receives data has a Send Queue (SQ) and a Receive Queue (RQ), and data is transferred while managing the occurrence and termination of data transfer requests in these queues. RDMA communication is managed in units of communication requests called Work Requests (WR). WRs are stacked in SQ / RQ in units called Work Queue Elements (WQE). An SQ / RQ pair within a terminal involved in one communication is called a Queue Pair (QP).

[0022] RDMA is broadly divided into four service types: Reliable Connection (RC), Reliable Datagram (RD), Unreliable Connection (UC), and Unreliable Datagram (UD) based on the classification of Reliable / Unreliable and Connection / Datagram. Communication System 1 targets RC-type and UC-type communications. RC guarantees the order and reachability of messages by using ACK / NAK to confirm communication success / abnormalities and a retransmission mechanism. RC and UC are connection-type communications, and perform one-to-one communication between a local terminal and a remote terminal.

[0023] RDMA is broadly divided into four operation types: SEND, RDMA WRITE (with Immediate), RDMA READ, and ATOMIC Operations. All operation types can be used in RC. Only SEND and RDMA WRITE (with Immediate) can be used in UC.

[0024] The following description will be given taking the RC SEND operation as an example, but the communication system 1 may use any operation type.

[0025] Before data transfer, a connection is established between the local terminal and the remote terminal. When the connection is established, the local terminal sets the values ​​of the Queue Pair Number (QPN) and Starting Packet Sequence Number (PSN) of the SQ in the Communication Management (CM) header of the InfiniBand Connect Request (REQ) and notifies the remote terminal. The remote terminal sets the values ​​of the QPN and Starting PSN of the RQ in the CM header of the Connect Reply (REP) and notifies the local terminal. The QPN is an identifier used to identify the communication partner. The PSN is a sequence number uniquely assigned to each packet. The sender increments the PSN by one when sending a packet.

[0026] When a connection is established, a WQE is loaded into the SQ / RQ. In a SEND operation, the local terminal loads a WQE specifying the address of the memory area where the data is stored into the SQ. The remote terminal loads a WQE specifying the address of the memory area where the data will be stored into the RQ.

[0027] When the communication is ready, the local terminal sends data. The remote terminal sends an ACK to the local terminal each time it receives a packet. When all packets of data are successfully received, a Completion Queue Entry (CQE) is placed in the Completion Queue (CQ). When the local terminal receives the ACK for the last packet, it places the CQE in the CQ. Once the successful completion of the CQE is confirmed, the WQE in the SQ / RQ is deleted and the next WR can be accepted.

[0028] In a WRITE operation, the IB header contains the memory area to which the packet is written, so the same packet cannot be duplicated and transferred to different processes. Therefore, in communication system 1, information about the memory area to which the packet is written is obtained in advance from each process and managed as connection information, and multicast packets are converted into unicast packets with headers rewritten for each connection, after which the data is duplicated and sent to each process.

[0029] [Relay Device] An example of the configuration of the relay device 20 on the transmitting side will be described with reference to Fig. 3. The relay device 20 shown in the figure includes an RDMA communication unit 21, a destination conversion unit 22, an IP communication unit 23, a registration unit 24, and a storage unit 25. The relay device 20 is connected to the transmitting terminal 10 via an Ethernet switch 50.

[0030] The RDMA communication unit 21 establishes a connection with the transmitting terminal 10, and communicates with the terminal 10 using RDMA to receive data from the terminal 10. In the example of Fig. 3, a connection is established between a queue of terminal 10A with a QPN of 0xa and a queue of the RDMA communication unit 21 with a QPN of 0xc, and data is transmitted from the terminal 10A to the RDMA communication unit 21 using this connection. A connection is established between a queue of terminal 10B with a QPN of 0xb and a queue of the RDMA communication unit 21 with a QPN of 0xd, and data is transmitted from the terminal 10B to the RDMA communication unit 21 using this connection. A connection is established between a queue of terminal 10C with a QPN of 0xe and a queue of the RDMA communication unit 21 with a QPN of 0xf, and data is transmitted from the terminal 10C to the RDMA communication unit 21 using this connection. Terminal 10A transmits unicast packets addressed to members of multicast group A, terminal 10B transmits unicast packets addressed to members of multicast group B, and terminal 10C transmits unicast packets addressed to members of multicast group C.

[0031] The destination conversion unit 22 refers to the address correspondence table held in the storage unit 25 and assigns destination information of the corresponding multicast group to the data received from the terminal 10. In other words, it can be said that the destination conversion unit 22 converts unicast destination information into multicast destination information.

[0032] FIG. 4 shows an example of an address correspondence table. The address correspondence table shown in FIG. 4(a) has fields for content identifier, source IP address, multicast group address, and MAC address for the group address. It is stored, for example, in an external database and shared in advance within the communication system 1. The address correspondence table shown in FIG. 4(b) is maintained by the relay device 20 in addition to the address correspondence table shown in FIG. 4(a). It has fields for process ID, source MAC address, and QPN of the relay device 20, and the values ​​of each field are obtained through data exchange with the terminal 10. The process ID is an identifier for identifying a process running on the terminal 10. For example, a process ID is created by combining a process ID provided by the OS with the MAC address of the NIC of the terminal 10, ensuring uniqueness between terminals. For simplicity, short numbers such as 100, 200, and 300 are used in FIG. 4(b). Managing the correspondence between each process and a multicast group allows different processes within the same terminal 10 to participate in different multicast groups. The source MAC address is the MAC address of the terminal 10. The QPN of the relay device 20 is the QPN of the queue in the RDMA communication unit 21 , and is the RDMA destination of the unicast packet transmitted by the terminal 10 .

[0033] The IP communication unit 23 sends the multicast packets converted from the unicast packets by the destination conversion unit 22 to the IP multicast network.

[0034] The registration unit 24 acquires the process ID, source MAC address, and QPN of the relay device 20 and registers them in the address correspondence table when a multicast group join request is exchanged between the terminal 10 and the RDMA communication unit 21 or when a connection is established. Specifically, the registration unit 24 acquires the process ID and source MAC address when a process running on the terminal 10 sends a multicast group join request to a multicast group. Furthermore, the registration unit 24 acquires the QPN of the relay device 20 when a connection is established between the process running on the terminal 10 and the RDMA communication unit 21.

[0035] The storage unit 25 holds an address correspondence table.

[0036] An example of the configuration of a receiving-side relay device 30 will be described with reference to Fig. 5. The relay device 30 shown in Fig. 5 includes an IP communication unit 31, a destination conversion / duplication unit 32, an RDMA communication unit 33, a registration unit 34, and a storage unit 35. The relay device 30 is connected to a receiving-side terminal 40 via an Ethernet switch 50.

[0037] The IP communication unit 31 receives multicast packets from the IP multicast network.

[0038] The destination conversion / duplication unit 32 references the membership information, connection information, and data transfer type information stored in the storage unit 35 to obtain information on the number of connections and data transfer type for forwarding received multicast packets, and performs header generation processing such as packet duplication and multicast-to-unicast conversion. The membership information stores, for each process running on each terminal 40, information on the multicast group in which that process participates. The connection information stores information on connections established between the relay device 30 and terminal 40, in association with information on processes using those connections.

[0039] In the example of FIG. 5, process 101 for joining multicast group A and process 102 for joining multicast group B are running on terminal 40A, process 103 for joining multicast group B is running on terminal 40B, and process 104 for joining multicast group C is running on terminal 40C. Process 101 has established two connections with relay device 30 via an interface with an IP address of 10.0.1.1 and an interface with an IP address of 10.0.1.2. The QPNs of the queues on the relay device 30 side are 0x10 and 0x20, and the QPNs of the queues on terminal 40A side are 0x70 and 0x80. Process 102 has established one connection with relay device 30 via an interface with an IP address of 10.0.1.3. The QPN of the queue on the relay device 30 side is 0x30, and the QPN of the queue on terminal 40A side is 0x90. Process 103 has established one connection with relay device 30 via an interface to which an IP address of 10.0.2.1 is set. The QPN of the queue on the relay device 30 side is 0x40, and the QPN of the queue on the terminal 40A side is 0xA0. Process 104 has established two connections with relay device 30 via an interface to which an IP address of 10.0.2.2 is set and an interface to which an IP address of 10.0.2.3 is set. The QPNs of the queues on the relay device 30 side are 0x50 and 0x60, and the QPNs of the queues on the terminal 40C side are 0xB0 and 0xC0.

[0040] 6, 7A, and 7B show examples of membership information and connection information. The membership information in FIG. 6 includes, for each process running on the terminal 40, a process ID, a multicast group address and source address, and interface information used by the process (LAST REPORTER in the figure). The connection information in FIGS. 7A and 7B includes, for each connection established between the relay device 30 and the terminal 40, interface information (such as an IP address) used by the process running on the terminal 40, as well as some information about the Base Transport Header (BTH) related to RDMA transfer and other information about the RDMA Extended Transport Header (RETH) related to RDMA transfer. The former includes the QPN (DEST QPN) of the destination terminal 40 and the packet sequence number (PSN) for packet loss detection. The latter includes the destination memory area (VA) on the terminal 40 side, the authentication key (R_KEY) for accessing the memory area, and transfer size information (TRANSFER_LENGTH).

[0041] The destination translation / duplication unit 32 references the membership information to obtain the process ID of the process participating in the multicast group from the information of the received multicast packet, obtains the connection information and data transfer type information associated with the obtained process ID, and performs header generation processing such as packet duplication and multicast-to-unicast conversion. Specifically, when a multicast packet addressed to multicast group A with a group address of 239.0.10.1 is received, the destination translation / duplication unit 32 references the membership information in FIG. 6 to obtain process ID=101. The destination translation / duplication unit 32 obtains two entries with process ID=101 from the connection information in FIGS. 7A and 7B. When a multicast packet addressed to multicast group B with a group address of 239.0.20.2 is received, the destination translation / duplication unit 32 references the membership information in FIG. 6 to obtain process IDs=102 and 103. The destination translation / duplication unit 32 obtains two entries with process IDs=102 and 103 from the connection information in FIGS. 7A and 7B. When a multicast packet addressed to multicast group C with a group address of 239.0.30.3 is received, the destination translation / duplication unit 32 obtains the process ID=104 by referring to the membership information in Fig. 6. The destination translation / duplication unit 32 obtains two entries for process ID=104 from the connection information in Figs. 7A and 7B.

[0042] When multiple connections are established with one process, the destination conversion / duplication unit 32 references the data transfer type information to obtain the data transfer type desired by the process, duplicates the packet payload in a manner appropriate to the data transfer type, converts the packet's destination IP address to the address (unicast address) of the last reporter in each entry of the membership information, adds an RDMA header with the destination QPN in each entry of the connection information as the destination, and passes the packet to the RDMA communication unit 33. FIG. 8 shows an example of data transfer type information. In the data transfer type information in FIG. 8, a multicast group address and a data transfer type are associated with a process ID. The data transfer type is, for example, redundancy, link aggregation, or no specification. When the data transfer type is redundancy, the destination conversion / duplication unit 32 duplicates the packet payload by the number of connections the process has, generates a header, and then passes the packet to the RDMA communication unit 33. If the data transfer type is link aggregation, the destination conversion / duplicating unit 32 does not duplicate the payload of the packet, but generates a header while distributing the packet to each connection of the process, and passes the generated header to the RDMA communication unit 33 .

[0043] The RDMA communication unit 33 transmits the packet received from the destination conversion / copying unit 32 to the terminal 40 by RDMA.

[0044] When a process running on the terminal 40 joins a multicast group and establishes a connection, the registration unit 34 acquires the process ID, multicast group address, and information about the connection, and registers them in the membership information and connection information. Specifically, when the process sends a request to join a multicast group, the registration unit 34 acquires the process ID, multicast group address, multicast source address, IP address of the terminal 40, and the identifier of the interface that received the join request, and registers them in the membership information. When a connection is established between the process and the RDMA communication unit 33, the registration unit 34 acquires the process ID, the MAC addresses, IP addresses, and UDP port number of the terminal 40 and the relay device 30, as well as RDMA transfer information, and registers them in the connection information. The registration unit 34 also receives a data transfer type from the process and registers it in the data transfer type information.

[0045] The storage unit 35 holds membership information, connection information, and data transfer type information.

[0046] [Communication System of the Embodiment] Next, the processing flow of a communication system of another embodiment will be described with reference to messages exchanged between terminals and relay devices. The operating status of the communication system of the embodiment will be described with reference to FIG. 9 . Each of terminals 10A, 10B, and 10C transmits a unicast packet containing data to be sent to members of multicast groups 1, 2, and 3, respectively. Relay device 20 converts the unicast packets received from terminals 10A, 10B, and 10C into multicast packets and transmits them to the IP multicast network. Relay device 30 receives multicast packets from the IP multicast network, converts them into unicast packets, and forwards them to terminals 40A and 40B. The source addresses, multicast group addresses, and MAC addresses for the multicast groups 1, 2, and 3 are shared in advance among terminals 10A, 10B, and 10C, relay device 20, relay device 30, and terminals 40A and 40B.

[0047] Data transfer is performed by unicast RDMA between the terminal 10 and the relay device 20, and between the terminal 40 and the relay device 30. The figure shows the QPs and connection status of the transmitting terminal 10, the relay device 20, the receiving terminal 40, and the relay device 30. The terminal 10 and the relay device 20 are connected via an Ethernet switch 50. The terminal 40 and the relay device 30 are connected via an Ethernet switch 50.

[0048] In terminal 10A, a process 3001 is running to join multicast group 1. In terminal 10B, a process 4001 is running to join multicast group 2. In terminal 10C, a process 5001 is running to join multicast group 3. Each of processes 3001, 4001, and 5001 has established one connection with relay device 20.

[0049] On terminal 40A, process 1001 is running to join multicast group 1, and process 1002 is running to join multicast group 2. Process 1001 has established three connections with relay device 30 via three interfaces: an interface with an IP address of 10.0.1.1, an interface with an IP address of 10.0.1.2, and an IP address of 10.0.1.3. Process 1002 has established one connection with relay device 30 via an interface with the same IP address of 10.0.1.3 as process 1001. On terminal 40B, process 2003 is running to join multicast group 3. Process 2003 has established three connections with relay device 30 via three interfaces: an interface with an IP address of 10.0.1.4, an interface with an IP address of 10.0.2.1, and an IP address of 10.0.3.1. The relay device 30 is connected to the terminal 40 via three interfaces (the identifiers of the respective interfaces are IF:1, IF:2, and IF:3): one interface with an IP address of 10.0.1.10, one interface with an IP address of 10.0.2.10, and one interface with an IP address of 10.0.3.10.

[0050] 10 shows information about connections A, B, and C for terminals 10A, 10B, and 10C, respectively. The information about the connections includes a MAC address, an IP address, a QPN, and a PSN. The MAC address and IP address are the MAC address and IP address used by terminal 10 for connections A, B, and C. The QPN is the QPN of the queue of terminal 10. The PSN is the PSN initially assigned when transmitting an RDMA packet.

[0051] FIG. 11 shows information about connections A, B, and C of the relay device 20. The information about the connections includes the MAC address, IP address, QPN, PSN, and also the VA, R_KEY, and TRANSFER_LENGTH. The MAC address and IP address are the MAC address and IP address used by the relay device 20 for connections A, B, and C. The QPN is the QPN of the queue of the relay device 20. The PSN is the PSN initially assigned when transmitting an RDMA packet. The VA, R_KEY, and TRANSFER_LENGTH are information contained in the RETH header of the RDMA packet. The VA indicates the virtual address of the RDMA operation, the R_KEY indicates the remote key that authenticates access for the RDMA operation, and the TRANSFER_LENGTH indicates the length of the transfer data.

[0052] 12A and 12B show information about connections 1 to 7 of the relay device 30. The information about the connections includes an IF, a MAC address, an IP address, a QPN, and a PSN. The IF is an identifier of the interface used by the relay device 30 for connections 1 to 7. The MAC address and IP address are the MAC address and IP address of each interface. The QPN is the QPN of the queue of the relay device 30. The PSN is the PSN that is initially assigned when an RDMA packet is sent.

[0053] 13A and 13B show information about connections 1 to 7 for each terminal 40. The information about the connections includes the MAC address, IP address, QPN, PSN, as well as VA, R_KEY, and TRANSFER_LENGTH. The MAC address and IP address are the MAC address and IP address used by terminal 40 for connections 1 to 7. The QPN is the QPN of the queue of terminal 40. The PSN is the PSN initially assigned when transmitting an RDMA packet. The VA, R_KEY, and TRANSFER_LENGTH are information contained in the RETH header of the RDMA packet. The VA indicates the virtual address of the RDMA operation, the R_KEY indicates the remote key that authenticates access for the RDMA operation, and the TRANSFER_LENGTH indicates the length of the transfer data.

[0054] [Connection Establishment on the Receiving Side] An example of a process for establishing a connection by a process running on the receiving terminal 40 will be described with reference to the sequence diagram of Fig. 14. When a connection is established between the process and the relay device 30, membership information and connection information are generated.

[0055] In step S101, processes 1001, 1002, and 2003 (hereinafter referred to as processes) running on terminal 40 send a multicast group join request, including a process ID, to relay device 30. This join request is a modified version of the existing IGMP Membership Report (join) format, with a new process ID added. However, because unicast packets are exchanged between relay device 30 and terminal 40, there is no need to control the reception of multicast packets, and there is no need to run the existing IGMP itself.

[0056] 15A and 15B show examples of a join request sent by terminal 40. The join request shown in the figures includes a process ID, the MAC addresses and IP addresses of terminal 40 and relay device 30, and information about the multicast group.

[0057] In terminal 40A, processes 1001 and 1002 send the join requests shown in Fig. 15A. Process 1001 receives packets for multicast group 1 using three interfaces, so it sends a join request for each of the three interfaces. Process 1002 sends a join request to join multicast group 2. In this embodiment, these join requests are sent as unicast packets addressed to the address of the network interface on the relay device side, but the multicast address used in the IGMP Membership Report may also be used.

[0058] In terminal 40B, process 2003 transmits the join request shown in Fig. 15B. Since process 2003 receives packets for multicast group 3 using three interfaces, it transmits a join request for each of the three interfaces. In this embodiment, these join requests are transmitted as unicast packets addressed to the address of the network interface on the relay device side, but the multicast address used in the IGMP Membership Report may also be used.

[0059] When the relay device 30 receives the join request, in step S102, if necessary, it sends a PIM Graft message to the multicast group to an upstream router in the IP multicast network, requesting that the router join the multicast tree. For example, if there are no members belonging to the multicast group indicated by the received join request among the terminals 40 connected to the relay device 30, the relay device 30 sends a PIM Graft message.

[0060] In step S103, the relay device 30 acquires the process ID, multicast address, multicast source address, and IP address of the terminal 40 (SRC of the IP address in Figures 15A and 15B) from the received join request, and registers them in the membership information.

[0061] 16 shows an example of membership information held by the relay device 30. The membership information in the figure includes information about the process ID, interface identifier (IF), and multicast group. The process ID and information about the multicast group, including the multicast group address (GROUP ADDRESS), can be obtained from the join request. The interface identifier can be identified from the interface that received the join request. Process 1001 receives multicast packets via three interfaces, so there are three entries that include 1001 as the process ID. Process 2003 receives multicast packets via three interfaces, so there are three entries that include 2003 as the process ID. There is one entry that includes 1002 as the process ID.

[0062] In step S104, the process transmits an RDMA connection establishment request including the process ID to the relay device 30.

[0063] 17A and 17B show an example of a connection establishment request sent by the terminal 40. The connection establishment request can use an IB REQ. The connection establishment request shown in the figures includes a process ID, the MAC addresses, IP addresses, and UDP port numbers of the terminal 40 and the relay device 30, as well as an IB CM header. The CM header includes the Local QPN and PSN of the process queue.

[0064] Process 1001 establishes three connections and therefore transmits three connection establishment requests. Process 1002 transmits one connection establishment request. Process 2003 establishes three connections and therefore transmits three connection establishment requests.

[0065] In step S105, the relay device 30 acquires the process ID, the MAC addresses, IP addresses, and UDP port number of the terminal 40 and the relay device 30, as well as the local QPN and PSN from the received connection establishment request, and registers them in the connection information.

[0066] 18A and 18B show an example of connection information registered based on a connection establishment request received from the terminal 40. The connection information has entries for the number of connections established between the relay device 30 and the terminal 40. Each entry of the connection information includes destination information for transferring data to each process. Information about the IB header includes some information about BTH and information about RETH. BTH is a header added to all InfiniBand Architecture transport services. RETH is an additional header added to perform RDMA operations. Information other than RETH information can be obtained from the connection establishment request received in step S104. RETH information is sent by a SEND operation, which will be described later.

[0067] In step S106, the relay device 30 transmits a connection establishment response to the process in order to establish a connection.

[0068] 19A and 19B show examples of a connection establishment response sent from the relay device 30 to the terminal 40. The connection establishment request can use the REP of the IB. The connection establishment request shown in the figures includes a process ID, the MAC addresses, IP addresses, and UDP port numbers of the relay device 30 and the terminal 40, as well as a CM header of the IB. The CM header includes the Local QPN and PSN of the relay device 30.

[0069] In step S107, the process transmits a Ready to Use (RTU) message indicating that the connection has been established and communication is now possible. After this, RDMA communication is possible between the process and the relay device 30.

[0070] In step S108, the process notifies the process-specific information by a SEND operation. The process-specific information includes, for example, VA, which indicates the virtual address of the RDMA operation, R_KEY, which indicates the remote key for authenticating the access of the RDMA operation, and TRANSFER_LENGTH, which indicates the length of the transfer data. This information is used when the relay device 30 performs a WRITE operation on the process.

[0071] 20A and 20B show an example of a SEND operation that the process of the terminal 40 sends to the relay device 30. The SEND operation shown in the figures includes information on VA, R_KEY, and TRANSFER_LENGTH in the payload portion.

[0072] In step S109, the relay device 30 acquires VA, R_KEY, and TRANSFER_LENGTH from the payload of the SEND operation and registers them in the connection information. Specifically, the relay device 30 registers VA, R_KEY, and TRANSFER_LENGTH in the RETH items of IB in the connection information in FIGS. 18A and 18B.

[0073] In step S110, the process notifies the data transfer type by a SEND operation. The data transfer type is notified by a process that has established multiple connections.

[0074] In step S111, the relay device 30 acquires the data transfer type from the payload of the SEND operation and registers it in the data transfer type information.

[0075] An example of data transfer type information is shown in Fig. 21. In the data transfer type information shown in the figure, a process ID is associated with a multicast group address and a data transfer type.

[0076] [Maintaining a Multicast Group] An example of a process for maintaining a multicast group will be described with reference to the sequence diagram of FIG.

[0077] In step S201, the relay device 30 transmits a multicast group participation maintenance confirmation to the terminal 40 to confirm the necessity of maintaining participation in the multicast group. The relay device 30 transmits this multicast group participation maintenance confirmation from all of its own network interfaces to the IP address of the network interface of the opposing terminal 40. This multicast group participation maintenance confirmation uses a message in the same format as an IGMP General Query.

[0078] In step S202, the process on terminal 40 that has received the multicast group participation maintenance confirmation replies with a multicast group participation maintenance request to maintain participation in the multicast group within the maximum response time. This multicast group participation maintenance request is sent from each network interface that receives unicast packets addressed to the multicast group to the IP address of the network interface of the opposite relay device 30. The multicast group participation maintenance request uses a message in the same format as the IGMP Membership Report (maintenance). Like the multicast group participation request, the multicast group participation maintenance request includes the process ID, the MAC addresses and IP addresses of terminal 40 and relay device 30, and information about the multicast group.

[0079] In step S203, the relay device 30 updates the information related to the multicast group in the membership information. Specifically, it updates the GROUP TIMER UPTIME, GROUP TIMER EXPIRES, and GROUP SOURCE LIST EXPIRES items in the membership information in Fig. 16. GROUP TIMER UPTIME is the time elapsed since the entry was registered, and GROUP TIMER EXPIRES is the time remaining until the entry is deleted. GROUP SOURCE LIST EXPIRES is the time remaining until the entry is deleted.

[0080] [Leaving a Multicast Group] An example of a process for leaving a multicast group will be described with reference to the sequence diagram of FIG.

[0081] In step S301, the process transmits a multicast group leave request from the multicast group. This multicast group leave request is transmitted from each network interface that has received unicast packets addressed to the multicast group to the IP address of the network interface of the opposite relay device 30. The multicast group leave request uses a message in the same format as the IGMP Membership Report (leave). However, a process ID is added to the IGMP Report. Like the join request, the leave request includes the process ID, the MAC addresses and IP addresses of the terminal 40 and the relay device 30, and information about the multicast group.

[0082] When the relay device 30 receives the leave request, in step S302, if necessary, it sends a PIM Prune message to an upstream router in the IP multicast network and leaves the multicast tree. For example, if the number of members belonging to the multicast group indicated in the received leave request becomes 0, the relay device 30 sends a PIM Prune message.

[0083] In step S303, the relay device 30 deletes the entry corresponding to the process ID of the process that sent the withdrawal request from the membership information.

[0084] In step S304, the relay device 30 deletes the entry corresponding to the process ID of the process that sent the leave request from the connection information.

[0085] [Connection Establishment on the Transmission Side] An example of a process for establishing a connection by a process running on the transmission side terminal 10 will be described with reference to the sequence diagram of Fig. 24. When a connection is established between the terminal 10 and the relay device 20, an address correspondence table is generated.

[0086] In step S401, processes 3001, 4001, and 5001 (hereinafter referred to as processes) running on terminal 10 send a multicast group join request, including a process ID, to relay device 20. The join request can use a message in the same format as an IGMP Membership Report (join). However, the process ID is added to the IGMP Report. As explained in the section on establishing a connection on the receiving side, the join request includes the process ID, the MAC addresses and IP addresses of terminal 10 and relay device 20, and information about the multicast group.

[0087] In step S402, the relay device 20 acquires the process ID, the address of the multicast group, and the MAC address of the terminal 10 from the received join request.

[0088] In step S403, the process transmits an RDMA connection establishment request including a process ID to the relay device 20. The connection establishment request can use an IB REQ. As described in the connection establishment on the receiving side, the connection establishment request includes the process ID, the MAC addresses, IP addresses, and UDP port numbers of the terminal 10 and the relay device 20, as well as the IB CM header. The CM header includes the Local QPN and PSN of the process.

[0089] In step S404, the relay device 20 acquires the process ID from the received connection establishment request, and acquires the QPN of the queue on the relay device 20 side.

[0090] In step S405, the relay device 20 registers the process ID, the MAC address of the terminal 10, and the QPN of the relay device 20 acquired in steps S402 and S404 in an address correspondence table. An example of the address correspondence table is shown in Fig. 25. In the address correspondence table of Fig. 25, the process ID, the MAC address of the terminal 10, and the QPN of the relay device 20 are assigned to information related to multicast distribution that has been shared in advance within the communication system 1.

[0091] In step S406, the relay device 20 sends a connection establishment response to the process to establish a connection. The connection establishment request can use the REP of the IB.

[0092] In step S407, the process transmits the RTU. After this, RDMA communication is enabled between the process and the relay device 20.

[0093] [Multicast Packet Forwarding Process] An example of multicast packet forwarding process will be described with reference to the sequence diagrams of FIGS. 26 and 27.

[0094] In step S501 of FIG. 26, a process operating in the transmitting terminal 10 transmits data to the transmitting relay device 20 by RDMA.

[0095] In step S502, the relay device 20 refers to the address correspondence table and acquires the multicast group address and MAC address using the destination QPN of the data received in step S501 as a key. If there is no entry corresponding to the destination QPN, the received data is discarded and processing is terminated.

[0096] In step S503, the relay device 20 generates a multicast packet by adding a multicast group address and a MAC address to the received data.

[0097] In step S504, the relay device 20 transfers the multicast packet to the IP multicast network.

[0098] The multicast packet is replicated in the IP multicast network, and in step S505, the receiving relay device 30 receives the multicast packet.

[0099] 27 shows the flow of processing executed by the relay device 30 each time it receives a packet of a certain content. After receiving a packet in step S510, the relay device 30 searches the membership information for entries whose source address and multicast group address match those of the received multicast packet, and acquires all corresponding process IDs in step S511. If no corresponding entry is found, the relay device 30 discards the multicast packet and stops processing.

[0100] In step S512, the relay device 30 performs a transfer process for each of the acquired process IDs. The transfer process for each process ID will be described later. The transfer process in step S512 involves duplicating the packet payload, generating a header, and placing a data transfer request in the SQ of each connection.

[0101] In steps S513 and S514, the packet is transferred to the receiving terminal 40 by RDMA based on the transfer request for the data loaded in the SQ in step S512.

[0102] [Transfer Processing for Each Process] Processing for each process of the packet transfer destination will be described with reference to the flowcharts of FIGS.

[0103] In step S601, the relay device 30 selects one process ID to be processed from the process IDs acquired in step S511 of FIG.

[0104] In step S602, the relay device 30 branches depending on the data transfer type of the process selected in step S511.

[0105] If the process ID of the process target does not specify a data transfer type, in step S603, the relay device 30 generates a header without specifying a data transfer type and executes a transfer process.

[0106] If the data transfer type of the process ID to be processed is link aggregation, in step S604, the relay device 30 executes header generation and transfer processing for link aggregation.

[0107] If the data transfer type of the process ID to be processed is redundancy, in step S605, the relay device 30 executes header generation and transfer processing for redundancy.

[0108] The processing of steps S603, S604, and S605 will be described in detail later.

[0109] After generating a header according to the data transfer type and performing the transfer process, in step S606, the relay device 30 determines whether or not an unprocessed process ID remains. If so, the process returns to step S601 to select the next process ID. If not, the packet transfer process ends and the process returns to step S510 in Fig. 27. That is, the next packet is received and the process proceeds to processing that packet.

[0110] FIG. 29 is a flowchart showing an example of header generation and packet transfer processing when the data transfer type is not specified.

[0111] In step S701, the relay device 30 refers to the connection information and acquires information about the connection C corresponding to the process ID. If the data transfer type is not specified, the number of connections corresponding to the process ID is only one.

[0112] In step S702, relay device 30 determines whether the packet to be transferred is the first packet of the content, although the method for determining whether the packet is the first packet of the content is not specified here.

[0113] In the case of the first packet of the content, in step S703, the relay device 30 refers to the connection information acquired in step S701 and sets the PSN(C) to be assigned to the packet to be forwarded to the connection C to the value acquired from the connection information.

[0114] If it is determined in step S702 that the packet is not the first packet of the content, the relay device 30 increments the PSN(C) in step S704.

[0115] In step S705, the relay device 30 determines whether the operation is an RDMA Write First operation or an RDMA Write Only operation.

[0116] If the operation is an RDMA Write First operation or an RDMA Write Only operation, in step S706, the relay device 30 acquires destination information including RETH from the connection information. RETH includes the write destination address and data length of the WRITE operation.

[0117] If the operation is neither an RDMA Write First operation nor an RDMA Write Only operation, in step S707, the relay device 30 acquires destination information excluding RETH from the connection information.

[0118] In step S708, the relay device 30 generates a packet header using the destination information acquired in step S706 or step S707.

[0119] In step S709, the relay device 30 executes the packet forwarding process for connection C. That is, the relay device 30 loads a packet transmission request into the SQ of the QP for connection C.

[0120] Since the process of transferring the packet to the process is completed by the process up to step S709, the relay device 30 returns to step S606 in FIG. 28 and moves to the process of the next process.

[0121] FIG. 30 is a flowchart showing an example of header generation and packet transfer processing when the data transfer type is link aggregation.

[0122] In step S801, the relay device 30 refers to the connection information and acquires a list CL of connections corresponding to the process ID. When the data transfer type is link aggregation, there are usually multiple connections corresponding to the process ID.

[0123] In step S802, the relay device 30 determines whether the packet to be transferred is the first packet of the content.

[0124] In the case of the first packet of the content, in step S803, the relay device 30 selects connection C with the smallest QPN from the list CL of connections acquired in step S801, and acquires information about connection C by referring to the connection information.

[0125] Then, in step S804, the PSN(C) to be assigned to the packet to be transferred to the connection C is set to the value obtained from the connection information.

[0126] If it is determined in step S802 that the packet is not the first packet of the content, then in step S805, the relay device 30 updates the connection C used to transfer the packet. Specifically, the relay device 30 determines whether or not there is a connection with a larger QPN than the connection C that transmitted the previous packet. If such a connection exists, the relay device 30 refers to the connection information, updates the connection C to be the destination of the packet to the C in the CL with the next smallest QPN after the connection C that transmitted the previous packet, and acquires the information on the connection C. If there is no connection with a larger QPN than the connection C, the relay device 30 refers to the connection information, updates the connection C to be the destination of the packet to the C in the CL with the smallest QPN, and acquires the information on the connection C.

[0127] In step S806, relay device 30 determines whether the packet currently being processed is the first packet of the content to be transferred to connection C. If it is the first packet, in step S804, the PSN(C) to be assigned to the packet to be transferred to connection C is set to the value obtained from the connection information.

[0128] If it is determined in step S806 that the packet is not the first packet, in step S807, relay device 30 sets the PSN to be assigned to the packet currently being processed to the incremented value of PSN(C). This allows the PSNs of packets sent using connection C to have consecutive values, and packet loss detection in packet transfer to and from terminal 40 can be performed normally.

[0129] In step S808, the relay device 30 determines whether the operation is an RDMA Write First operation or an RDMA Write Only operation.

[0130] If the operation is an RDMA Write First operation or an RDMA Write Only operation, in step S809, the relay device 30 acquires destination information including RETH from the connection information.

[0131] If the operation is neither an RDMA Write First operation nor an RDMA Write Only operation, in step S810, the relay device 30 acquires destination information excluding RETH from the connection information.

[0132] In step S811, the relay device 30 generates a packet header using the destination information acquired in step S809 or step S810.

[0133] In step S812, the relay device 30 executes the packet forwarding process for connection C. That is, the relay device 30 loads a packet transmission request into the SQ of the QP for connection C.

[0134] Since the process of transferring the packet to the process is completed by the process up to step S812, the relay device 30 returns to step S606 in FIG. 28 and moves to the process of the next process.

[0135] FIG. 31 is a flowchart showing an example of header generation and packet transfer processing when the data transfer type is redundancy.

[0136] In step S901, the relay device 30 refers to the connection information and acquires a list CL of connections corresponding to the process ID of the process to be processed. When the data transfer type is redundant, there are usually multiple connections corresponding to the process ID.

[0137] In step S902, the relay device 30 determines whether the packet to be transferred is the first packet of the content.

[0138] In the case of the first packet of the content, in step S903, the relay device 30 refers to the connection information and acquires information on all connections in the connection list CL acquired in step S901. Furthermore, in step S904, the PSN value PSN(C) to be added to the header of the packet to be transferred to each connection C is set to the value acquired from the connection information.

[0139] If it is determined in step S902 that the packet is not the first packet of the content, in step S905, the relay device 30 increments the value of PSN(C) corresponding to each connection and sets these values ​​as the PSN values ​​to be added to the header when forwarding the packet to each connection C.

[0140] In step S906, the relay device 30 determines whether the operation is an RDMA Write First operation or an RDMA Write Only operation.

[0141] If the operation is an RDMA Write First operation or an RDMA Write Only operation, in step S907, the relay device 30 acquires destination information including RETH from the connection information.

[0142] If the operation is neither an RDMA Write First operation nor an RDMA Write Only operation, in step S908, the relay device 30 acquires destination information excluding RETH from the connection information.

[0143] In step S909, the relay device 30 copies the packet payload for the number of connections included in the CL acquired in step S901. Then, using the destination information acquired in step S907 or step S908, the relay device 30 generates packet headers for the number of connections included in the connection list CL and assigns them to the copied payloads.

[0144] In step S910, the relay device 30 executes packet forwarding processing for all connections included in the connection list CL, that is, it places packet transmission requests in the SQs of the QPs for all connections C included in CL.

[0145] Since the transfer process of the packet to the process is completed by the process up to step S910, the relay device 30 returns to step S606 in FIG. 28 and moves to the process of the next process.

[0146] [Example Using IPv6] The present disclosure can also utilize IPv6. For example, when a process joins a multicast group, the process sends a message in a format similar to a Version 2 Multicast Listener Report (Join) to the relay device 30. However, this is a modification of the existing Version 2 Multicast Listener Report (Join) format by adding a new process ID. To maintain the multicast group, the relay device 30 periodically sends a message in a format similar to a Multicast Listener Query. A process that receives a message in a format similar to a Multicast Listener Query replies with a message in a format similar to a Version 2 Multicast Listener Report (Maintain) within the maximum response time. However, this is a modification of the existing Version 2 Multicast Listener Report (Maintain) format by adding a new process ID. When a process leaves a multicast group, the process sends a message in a format similar to a Version 2 Multicast Listener Report (Leave) to the relay device 30. However, this is a modification of the existing Version 2 Multicast Listener Report (Leave) format by adding a new process ID.

[0147] As described above, the communication system 1 of this embodiment includes relay devices 20 and 30 participating in the IP multicast network. Relay device 20 receives unicast packets from terminal 10, converts them into multicast packets, and sends them to the IP multicast network. Relay device 30 receives multicast packets, converts them into unicast packets, and distributes them to terminal 40. Relay device 30 stores membership information that associates processes with the multicast groups in which the processes participate, and connection information that associates processes with connections established between the processes and relay device 30. Relay device 30 receives multicast packets, references the membership information, extracts processes associated with the multicast group of the multicast packet, references the connection information for each extracted process, extracts connections associated with the process, and uses each extracted connection to convert the multicast packets received from the IP multicast network into unicast packets that can be transmitted via the connections and forwards them. This allows multicast communication to be performed using any combination of processes, multicast groups, and connections.

[0148] The relay device 30 of this embodiment holds data transfer type information that specifies the data transfer type when multiple connections are established between a process and the relay device 30, and transfers packets for each process using the transmission method specified by the data transfer type. This allows the connections established between the process and the relay device 30 to be used for link aggregation or redundancy.

[0149] The terminals 10 and 40 and relay devices 20 and 30 described above can be, for example, a general-purpose computer system including a central processing unit (CPU) 901, memory 902, storage 903, a communication device 904, an input device 905, and an output device 906, as shown in Fig. 32. In this computer system, the CPU 901 executes a predetermined program loaded onto the memory 902, thereby realizing the terminals 10 and 40 and relay devices 20 and 30. This program can be recorded on a non-transitory computer-readable recording medium such as a magnetic disk, optical disk, or semiconductor memory, or can be distributed via a network.

[0150] REFERENCE SIGNS LIST 1 Communication system 10, 10A, 10B, 10C, 40, 40A, 40B, 40C, 40D Terminal 20, 30, 30A, 30B Relay device 21 RDMA communication unit 22 Destination conversion unit 23 IP communication unit 24 Registration unit 25 Storage unit 31 IP communication unit 32 Destination conversion / replication unit 33 RDMA communication unit 34 Registration unit 35 Storage unit

Claims

1. A multicast system comprising a first communication device and a second communication device participating in a multicast network, wherein the first communication device converts a unicast packet received from a first member connected to the first communication device into a multicast packet and sends it to a relay network, the second communication device holds membership information associating a second member connected to the second communication device with a multicast group in which the second member participates, and connection information associating the second member with a connection established between the second member and the second communication device, receives the multicast packet from the relay network, refers to the membership information to extract at least one or more second members associated with the multicast group of the multicast packet, refers to the connection information for each extracted second member to extract at least one or more connections associated with the second member, and converts the multicast packet into a unicast packet using each of the extracted connections and forwards it via the connection.

2. A multicast system according to claim 1, wherein the second communication device holds, for each of the second members, data transfer type information specifying a method for transmitting the unicast packets when multiple connections are established between the second member and the second communication device, and for second members with multiple connections established with the second communication device, forwards the unicast packets using the transmission method specified in the data transfer type information.

3. A multicast system according to claim 1, wherein the first communication device and the first member are connected by an RDMA connection, and the second communication device and the second member are connected by an RDMA connection, the first communication device holds an address correspondence table that associates RDMA destination information with multicast groups, receives unicast packets via the RDMA connection, refers to the address correspondence table, converts the unicast packets into multicast packets, and sends them to the relay network, and the second communication device forwards the unicast packets using the RDMA connection.

4. A multicast system according to claim 3, wherein the connection information includes information specific to each of the second members, and the second communication device transmits RDMA packets using the information specific to each of the second members.

5. A multicast system as described in claim 1, wherein the second communication device receives a request to join a multicast group from a second member, adds an entry to the membership information that associates the second member with the multicast group in which the second member is participating based on the join request, receives a request to establish a connection from the second member, and adds an entry to the connection information that associates the second member with a connection established between the second member and the second communication device based on the establishment request.

6. A multicast method by a communication device that distributes a multicast packet to at least one or more members, comprising: receiving the multicast packet from a relay network; referring to membership information that associates members with multicast groups, extracting at least one or more members associated with the multicast group of the multicast packet; referring to connection information that associates the member with a connection established between the member and the communication device for each of the extracted members, extracting at least one or more connections associated with the member; and using each of the extracted connections, converting the multicast packet into a unicast packet and forwarding it via the connection.

7. A program for causing a computer to operate as each part of the first communication device or the second communication device provided in the multicast system according to any one of claims 1 to 5.

Images