JP3692830B2 - Multicast communication system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a technology for increasing the scale and reliability of a multicast communication system for distributing data using a network.
[0002]
[Prior art]
Currently, IGMP (Internet Group Management Protocol: RFC2236) has been established as an IP level standard by the Internet Engineering Task Force (IETF) as a technology related to multicast communication capable of distributing data to a plurality of specific destinations. The usage of multicast addresses is disclosed in RFC2356. IGMP is a protocol for determining whether or not a multicast group member exists in the local network to which the multicast router belongs so that the multicast data can be efficiently transferred. At the draft level of IETF, DVMRP (Distance Vector Multicast Routing Protocol) and MOSPF (Multicast Open Shortest First) are available as routing protocols for MBONE, a global multicast virtual experiment network. Both create a tree for multicast data transfer. The above technique is for efficiently performing multicast data transfer.
[0003]
With regard to the large scale of multicast, in the current situation where the number of users has increased explosively with the recent infrastructure development of the Internet, it is very important that the multicast service has the scalability to cope with the large scale. Yes. Under such circumstances, a wireless line having a very high affinity is attracting attention as a multicast transmission medium. Terrestrial digital communication networks, mobile communication networks, and satellite communication networks are gradually being prepared. In particular, satellite links with wide area and high speed are attracting attention as a powerful base for dealing with large-scale multicast communications. Utilizing this feature, it has been put into practical use as a broadcast-type service such as in-house broadcasting, educational TV broadcasting, and image download system for branch offices distributed from the head office. In addition, data distribution services using the gap between broadcast waves are spreading to homes.
[0004]
As techniques for improving the reliability of multicast data, there are a technique for adding an error correction code to data and a technique for performing retransmission control. Since retransmission control can obtain the highest reliability, retransmission control based on delivery confirmation is adopted for file distribution, program download, version upgrade, and corporate data distribution. There are basic GO-Back-N method and Selective Repeat method in retransmission control technology. Reference 1 (Fujibe, Kobayashi, Nakayama, “Problems and Proposals for Highly Reliable Multicast Communication Systems in Multimedia Satellite Communication” (Science Technical Report SAT96-127, 1997-01) includes methods that combine or modify them. Further, as shown below, there are various methods for improving the system throughput of a multicast system to which retransmission control is added, which are separated according to the timing of transmission control, delivery confirmation control, and retransmission control. .
[0005]
(1) Delivery confirmation and retransmission control after transmission control is completed, for example, Reference 2 (Joshishita, Takahashi, and other three authors “Applicability of Reliable Multicast Communication Protocol (RMTP) to Various Networks” (Science and Technology) RMTP) disclosed in SSE95-196, 1996-03).
[0006]
(2) A method for performing retransmission control after performing transmission control and delivery confirmation in parallel, for example, Reference 3 (StarBurst MFTP; White Paper “An Efficient, Scalable Method for Distributing Information Using IP Multicast "), and reference 4 (Mentat, USA XTP4.0;" XTP protocol as seen from TCP / IP "by Eguchi, magazine Bit Vol. 28 No. 4, 1996-04).
[0007]
(3) A method of performing transmission control, delivery confirmation and retransmission control in parallel (see Document 2)
There is. Both are based on IP or UDP. In addition, in order to reduce the load on the transmission host for acknowledgment and retransmission control, Reference 5 (BN Levine et al., “A comparison of known Classes of Reliable Multicast Protocols” ICNP1996-Oct, Columbus Ohio) Discloses a method in which retransmission control timing is dispersed in time and only a delivery confirmation that is not normally received is notified.
[0008]
[Problems to be solved by the invention]
For example, the above-mentioned delivery confirmation and retransmission control can be used when data is reliably multicasted without error to a large number of users, such as a service that distributes software such as game software to tens of thousands of contract users who use the Internet. It is important to adopt This is an indispensable means especially when using a wireless line whose quality is not high. In such a case, if the number of users becomes enormous, the load on the transmission host related to delivery confirmation or retransmission control cannot be reduced regardless of contrivances such as time dispersion, and much time is required for distribution. Also, due to problems such as part of the network line or traffic congestion, part of the multicast tree created by DVMRP or MOSPF is interrupted, making data delivery impossible or lengthening the transmission time, which adversely affects the entire system. May cause effects.
[0009]
An object of the present invention is to provide a large-scale multicast communication system capable of solving the above-described problems and reliably transmitting data to a large number of users.
In particular,
(1) Distributing the load on the sending host for delivery confirmation and retransmission control;
(2) avoid traffic congestion and data transmission stagnation;
(3) To suppress the consumption of network resources such as routers,
It is to provide a multicast communication method using the same, a multicast communication system using the same, an individual communication device necessary for constructing the system, and a program for realizing these communication devices on a computer.
[0010]
[Means for Solving the Problems]
In order to achieve the above object, the present invention is characterized in that a host that transmits multicast data dynamically controls the configuration of a host group (also referred to as a multicast group) according to network conditions.
In another aspect, the present invention is characterized in that a route from a transmission host to a host constituting a multicast group, that is, a multicast tree is dynamically reconfigured.
In general, a network is composed of network nodes with routing functions. Specifically, it may be a router, a gateway, or a normal PC as long as it has a path control function.
[0011]
As a control method, a host group is configured to include normally received hosts (for example, one or more newly created or the configuration of an existing host group is changed).
Further, the present invention is characterized in that the normally received host is caused to perform a part of communication processing for a newly created or changed host group to which the host belongs.
As another aspect, the present invention is characterized in that a multicast tree is reconstructed with a normally received host as a new transmission host.
Furthermore, in the multicast communication system of the present invention, the designated host comprises means for sending the received data delivery confirmation to the sending host, and means for requesting retransmission of data that could not be received normally. To do.
[0012]
According to the multicast communication system of the present invention, the load on the transmission host can be distributed, and a large-scale multicast system can be realized. In addition, according to some trouble situations, it becomes possible to avoid traffic congestion and data transmission stagnation by reconfiguring the host group and transferring the processing to the designated host. That is, it is possible to improve the efficiency of the retransmission control process that is responsible for high reliability, and it is possible to prevent a reduction in system efficiency.
Further, the present invention is characterized in that a wireless line, particularly a satellite line, is used for a route between a plurality of hosts. By configuring the reconfigured host group by direct connection via a wireless (satellite) line without going through a network node such as a router, the influence of communication processing such as delivery confirmation or retransmission control is not exerted on other networks. It becomes possible not to be influenced by other networks, and it becomes possible to improve the efficiency of communication processing and prevent the system efficiency from being lowered.
[0013]
Further, the present invention is characterized in that, in a system that requests retransmission of data that could not be normally transmitted, the host group newly created or changed by the designated host is retransmitted by multicast.
The communication processing apparatus used in the present invention includes means for notifying definition information of a reconfigured host group between nodes constituting the network, and performs communication processing closed to the reconfigured host group. And
Further, the communication processing apparatus used in the present invention is characterized by comprising means for selecting a normal receiving host that minimizes the network cost with the hosts constituting the new or changed host group.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments using the present invention will be described below with reference to the drawings.
FIG. 1 is a system configuration diagram for explaining the outline of the present invention. The system includes a plurality of networks 120 to 127, a plurality of routers 130 to 134 that connect these networks, and hosts 100 and 150 to 163 that connect to a network including the networks 120 to 127 and the routers 130 to 134. In the figure, a transmission host having multicast data distributed by the host 100 is shown, and the hosts 150 to 163 form a multicast group that receives the multicast data. A group 170 and a group 171 indicate host groups newly generated in the present invention. Here, the host 100 divides the multicast data 101 into a plurality of frames, and uses the multicast group address of this multicast group as the destination address, and distributes it to the hosts 150 to 163 belonging to the multicast group with high reliability using delivery confirmation and retransmission control. An example of the case will be described.
[0015]
In this case, the host 100 receives a delivery confirmation notification from the hosts 150 to 163 with respect to the transmitted frame, and manages the status of non-reception and normal reception for each of the hosts 150 to 163 in units of frames. Here, it is assumed that the hosts 152, 153, 154, 160, 162, and 163 are hosts that have received a notification that there is an unreceived frame and a retransmission is requested (hereinafter referred to as an unreceived host). Is assumed to be a host that normally receives the frame (hereinafter referred to as a normal host). Based on the delivery confirmation notification result, the host 100 newly defines a host group from the hosts 152, 153, 154, 160, 162, and 163 that have made non-reception notifications including normal reception hosts.
[0016]
In this figure, hosts 159 and 151 are designated as normal hosts, and two new host groups 170 and 171 including each are defined in such a policy that the total network cost up to unreceived hosts is reduced. The host group 170 is composed of designated hosts (hereinafter referred to as designated hosts) 159 and unreceived hosts 160, 162, and 163, and the host group 171 is composed of designated hosts 151 and unreceived hosts 152, 153, and 154.
[0017]
The host 100 assigns a new multicast address to each defined new host group, and transmits it as control data together with group definition information in parallel with the multicast data frame transmission before the start of retransmission, and notifies the hosts 150 to 163. To do.
[0018]
The hosts 151, 152, 153, 154, 159, 160, 162, and 163 related to the definition information receive the notified definition information. It is recognized that the host 151 is a designated host of the host group 171 and the host 159 is a designated host of the host group 170.
[0019]
The designated hosts 151 and 159 serve as masters for retransmission control of the host group 171 and the host group 170, respectively, and retransmit the necessary frames 180 and 181 with the multicast addresses assigned to the host groups 171 and 170, respectively. When the retransmission control is completed, the host 100 is notified of this.
[0020]
In this way, depending on the reception status and traffic status, the host group necessary for retransmission is temporarily defined together with the designated host, and retransmission control is performed locally to perform retransmission control, thereby enabling large-scale highly reliable multicast Service can be handled. Also, by performing locally closed communication processing, compared to the case of retransmitting from the host 100, it is possible to suppress the consumption of network resources such as a network or a router far from the unreceived host, that is, the adverse effect due to an increase in traffic of retransmitted frames Can be suppressed.
[0021]
Next, referring to FIG. 2, a description will be given of an embodiment in the case of using a satellite line which is a transmission medium having wide area and broadcast capability and very effective for large-scale multicast communication. In FIG. 2, 200 is a communication satellite, 210 and 220 to 234 are earth station devices that convert data to satellite channels and transmit / receive data, 211, 240 to 247, and 290 to 295 are connected to the earth station devices 220 to 234, respectively. Indicates the host that performs the process. Here, a case where the host 211 having multicast data distributes the multicast data to the hosts 240 to 247 and 290 to 295 constituting the multicast group 250 via the earth station device 210 and the communication satellite 200 via the satellite line 212 will be described. To do.
[0022]
In the same manner as described above, the data is divided into frames, and the multicast group 250 group address is assigned and broadcast. The host constituting the multicast group 250 returns a delivery confirmation to the host 211 by unicast. Based on this delivery confirmation, the reception statuses of the hosts 240 to 247 and 290 to 295 are grasped, and new host groups 270 and 280 are defined. Here, the unreceived hosts are the hosts 290 to 295, and the other hosts are normal hosts. The designated hosts are normal hosts 246 and 247. The host group can be defined based on the following criteria in view of the reception status.
[0023]
(1) Hosts having the same frame non-reception rate (definition will be described later) are set to the same group.
(2) Hosts with the same frame unreceived pattern (definition will be described later) are set to the same group.
(3) Hosts in the same region are grouped together
The selection of the designated host may be based on being physically close to the generated host group as much as possible.
[0024]
The designated host 246 is responsible for the host group 270, and the designated host 247 is responsible for the retransmission control of the host group 280. The designated host 246 transmits the retransmission frame 271 and the designated host 247 transmits the retransmission frame 281 to the unreceived hosts of the respective host groups 270 and 280 via the communication satellite 200.
In the following, an embodiment of a method for performing retransmission control after performing transmission control and delivery confirmation in parallel and transmitting data in a row as shown in the above-described conventional technology will be described.
[0025]
FIG. 3 shows a sequence in this embodiment. FIG. 3A shows a sequence for performing transmission control and delivery confirmation in parallel, and FIG. 3B shows an example of a sequence for retransmission control. FIG. 3A shows that the hosts 240, 290, and 295 are receiving data by multicast. Reference numerals 301 to 309 define multicast data frames, and six frames define one block. The host received for each block confirms delivery only for non-reception. Each receiving host activates a timer at the end of each block and sends a delivery confirmation after a random time has elapsed.
[0026]
Note that performing in parallel means sending the reception status (acknowledgment confirmation) for the data frames received so far while receiving multicast data, for example, in units of frames. The timing for sending the reception status can be arbitrarily selected according to the delivery confirmation method employed. For example, a method of confirming delivery for every window size or confirming delivery for every certain amount of received data is possible. Also, transmission control is transmission of multicast data including retransmission. The delivery confirmation means that the transmission side recognizes whether the multicast data is normally received or received in error by notifying the transmission side of the reception status for the multicast data.
[0027]
In the NACK (X, Y) frame for notifying that there is an unreceived frame, X is the host identifier, and Y is the unreceived frame number to notify the unreceived frame. In the figure, the host 290 notifies that the frame of frame number 2 has not been received, and the host 295 notifies that frame numbers 6 and 7 have not been received. In FIG. 3 (2), the sequence of (1) is completed, and the host 211 newly creates host groups 270 and 280 from the reception status, of which multicast frames are sent from the designated host 247 to the host 295 in the host group 280. 6 shows a state in which retransmissions 6 and 7 are performed.
[0028]
FIG. 4 shows a configuration example of a main apparatus that executes the sequence of FIG. In this figure, a communication processing device 400 for executing the present invention is connected to each of earth station devices 210, 235, and 227 that perform transmission and reception with a communication satellite. Furthermore, hosts 211, 295, and 247 are connected to the communication processing devices, respectively. Of course, the communication processing apparatus can be realized in the host, but is separated for the sake of clarity of the description of the invention. In this example, the host 247 is a designated host.
[0029]
FIG. 5 is a block diagram showing a configuration of the communication processing apparatus 400 that executes the multicast procedure of FIG. The CPU 500 calls various communication processing programs such as multicast communication control from the ROM 510 and executes them. The RAM 520 is a control information storage unit that temporarily stores information referred to in the implementation of the present invention, such as a reception status management table. The I / F circuit 530 is connected to the earth station device and temporarily stores input / output data in the input / output buffer 560. The I / F circuit 540 is connected to the host and temporarily stores input / output data in the input / output buffer 570.
[0030]
The I / F circuit 550 connects to another network and temporarily stores input / output data in the input / output buffer 580. The CPU 500 monitors the input / output buffer. Thereby, data from the connected host or network is communicated via the input / output buffer. Here, a case where communication is performed with a host or a network by TCP / IP (Transmission Control Protocol / Internet Protocol) which is a general Internet protocol will be described. The earth station apparatus implements the following protocol for multicast on the IP base.
[0031]
FIG. 6 shows an IP packet 600 standardized by IETF and used on the Internet or the like. The IP packet 600 is generally composed of a 20-byte IP header part and an IP data part 620. Multicast data is carried by the IP data unit 620. The communication processing device 400 stores the data exchanged in the format of FIG. 6 in the host or network in the input / output buffer, takes out the IP data 620, divides it into frame sizes, newly adds control information and converts it into an IP packet again. / F circuit 530.
[0032]
FIG. 7 shows the format of an IP packet 700 reassembled for transmission to the satellite line via the I / F circuit 530. The IP packet 700 includes a standard 20-byte IP header portion 710 and an IP data portion 720. The IP data portion 720 stores a frame segment 770 created by the communication processing device 400. The IP data part 720 includes a frame header part 730 and a frame data part 750. The frame data portion 750 stores user data or control information.
[0033]
The frame header portion 730 includes a data type for identifying user data / control data and a frame type 731 indicating a control frame, a source port number 732, a destination port number 733, a frame sequence number 734, and a block identifier for starting and ending the block. 735, an IP multicast address 736 for identifying the multicast application, and a checksum 737 for confirming that the frame has arrived normally. The control frame is a frame for transmitting control information related to the present invention, such as a frame for defining a host group sent from the side that sends multicast data and a delivery confirmation notification on the side that receives, as will be described later. The data frame is a frame for transmitting multicast data.
[0034]
First, the data transmission processing procedure of the communication processing apparatus 400 connected to the host 211 that is the transmission source of multicast data will be described with reference to the flowchart of FIG. 8 using FIGS. In step 801, the IP packet 600 in the input / output buffer 570 is checked, and in step 802, it is determined by the destination IP address of the IP header whether it is IP multicast data. In the specifications of the Internet standard, class D IP addresses are defined for multicast, and the first 4 bits are “1110” (224 in decimal notation).
[0035]
In FIG. 2, a multicast address is assigned for the multicast group 250. This multicast address is one of 224.0.1.0 to 238.255.255.255, which is assigned to the public in class D by default. Or if it is closed by one organization, 239.0.0-239.255.255.255 assigned locally can be used. If the IP address is a normal unicast IP address in step 802, the IP packet in the input / output buffer 570 is extracted in step 809 and transmitted to the input / output buffer 560 as it is in step 808.
[0036]
If it is determined in step 802 that it is multicast data, the IP packet 600 is taken out and decapsulated in step 803. In step 804, the decapsulated IP data 620 is divided into frames. A frame is not necessarily created from one IP data, and one frame may be composed of a plurality of IP data. In step 805, a frame header is created. Although the frame header is shown in FIG. 7, the frame type 731 is a user data type, the source port number 732, destination port number 733, and sequence number 734 inherited from the host 211 are assigned divided frame numbers. Block number 735 is attached to the first and last frames.
[0037]
The IP multicast address 736 is assigned with the IP multicast address to identify the current multicast application. In step 806, the frame data in step 804 is assembled from the frame header in step 805. In step 807, the frame in step 806 is encapsulated in the IP header 610 after decapsulation in step 803. In step 808, the input / output buffer is encapsulated. To 560. The above is the operation of the data transmission process. Here, it is assumed that the communication control apparatus 400 manages the IP multicast and IP address of the host.
[0038]
Next, a reception processing procedure of the communication processing apparatus 400 connected to the host 211 to be transmitted will be described, but a control frame used before that will be described. FIG. 9 shows control information 900 of an unacknowledged delivery confirmation frame (referred to as a NACK frame) returned from the communication processing devices 400 of the hosts 240 to 247 and 290 to 295 constituting the multicast group 250 that receives the multicast data via the satellite line. It is. The NACK frame is a control frame with an identifier indicating that the frame type of the frame header 730 described with reference to FIG. 7 is a NACK notification of control data, and the frame data portion 750 has an unreceived frame sequence number shown in FIG. It is a pair of head and tail.
[0039]
FIG. 10 shows the control information 1000 of the frame data portion 750 of the host group notification frame, which is a control frame sent from the transmission side communication processing apparatus 400 to the reception side communication processing apparatus 400. The control information 1000 includes, for each host group, the IP multicast address 1001 of the host group, the IP address 1002 of the designated host, the IP addresses 1003 and 1004 of the constituting hosts, and the sequence number of the unreceived frame in the configuration of the host group 1010. It consists of a head 1005 and a tail 1006. The IP multicast address newly assigned here is a local one assigned privately. Therefore, allocation is performed from among 239.192.0.0 to 239.251.255.255 allocated locally.
[0040]
The control information 1000 is based on the defined host group configuration, and the transmission host stores the host group configuration definition information. Also in the designated host, configuration definition information related to the new assigned host group, for example, the host IP address is stored as similar information. Further, the designated host IP address is stored in each constituent host.
[0041]
FIG. 11 shows a reception status management table 1100 managed by the RAM 520 by the communication processing device 400 on the multicast transmission side. The reception status management table 1100 includes a reception host ID 1101 and an unreceived frame number 1102, and an unreceived frame number is managed for each communication processing device. The reception processing procedure of the communication processing apparatus 400 on the transmission side will be described with reference to FIG.
[0042]
Here, the definition in this invention is illustrated about the above-mentioned frame unreception rate and a frame unreception pattern.
[0043]
The frame non-reception rate of each receiving host is, for example, when the total number of data frames is dt.
Frame unreceived rate = Host unreceived frames / dt
Defined by The number of unreceived frames is counted for each receiving host based on the table of FIG. In the case of the host 290, the number of AFNs from AF-1 is accumulated. When the frame non-reception rate falls within a preset error range, it is defined that “the frame non-reception rate is equal”.
[0044]
The frame non-reception pattern is defined as follows, in which the rate of matching frame numbers compared to other hosts is calculated among the non-reception frames of each reception host summarized in FIG. The following formula shows the coincidence rate when the host 290 is compared with the host 291. A case where the coincidence rate falls within a preset range is regarded as “the frame non-reception pattern is the same”.
[0045]
Match rate (host 290 → host 291) =
Number of frames with the same number as host 291 / Number of frames not received by host 290
When the IP packet storing the NACK frame is received in step 1201 of FIG. 12, the transmission IP address 711 of the IP header 610 and the unreceived frame number shown in FIG. 9 are read, and the reception state management table 1100 is updated in step 1202. In the sequence of FIG. 3, a NACK frame with an unreceived frame start number = unreceived frame end number = 2 from the host 290 and an NACK frame with an unreceived frame start number = 6 and an unreceived frame end number = 7 are received from the host 295. Indicates that it is being received.
[0046]
In step 1203, it is determined whether or not it is time to issue a new host group definition notification. There are various cases of determination methods. For example, (1) periodically notifies several blocks before the completion of transmission of multicast data, and (2) several times at the timing after completion of multicast data transmission. There are notifications. In the case of a host group in which the number of unreceived frames is larger than a specified number, there is a possibility that the line quality may be deteriorated due to weather or the like, so that retransmission is instructed after a certain time. If it is not time to send the host group definition notification to the designated host, the process returns to step 1201.
[0047]
In step 1204, the group configuration host and the designated host are determined from the reception status management table 1100 according to the host group definition criteria described above.
[0048]
In FIG. 2, the new host group 270 is defined as a designated host 246 and unreceived hosts 290 to 292, and the host group 280 is defined as a designated host 247 and unreceived hosts 293 to 295. In step 1205, based on this definition, control information 1000 of the frame data portion 750 of the host group notification frame is created and encapsulated with an IP header with the IP multicast address of the multicast group 250 as the destination IP address. In step 1206, the IP-encapsulated control frame is transmitted to the input / output buffer 560.
[0049]
FIG. 13 shows an IP multicast correspondence table for each application managed by the RAM 520 of the communication processing apparatus 400. This manages the host group for each application. Here, there are IP multicast correspondence tables 1300, 1310, and 1320 for each application using three multicasts.
[0050]
FIG. 14 shows a private IP multicast management table 1400. For example, if this table is used by a company, one master server that manages this table is set up and managed in the company. Necessary hosts are registered in the private IP multicast management table 1400 to obtain private IP multicast. The private IP multicast that can be used uses 239.192.0.0-239.251.255.255, which is locally allocated by IETF. The private IP multicast management table 1400 describes the host IP address of the acquisition source. If unused, it is 0.0.0.0.
[0051]
FIG. 15 illustrates a processing procedure of the communication processing device 400 connected to the host 246 and the host 247 that are designated hosts among the hosts that constitute the multicast group 250. Only the procedure specific to the designated host is described here.
[0052]
When the IP packet storing the host group notification frame is received from the input / output buffer 560 in step 1500, it is determined in step 1501 whether the IP address of the own host is described as the designated host. End if not marked. If it is recognized in step 1502 that the host is a designated host, it is determined whether it is a retransmission timing. The retransmission timing is also determined by the multicast system. In the sequence of FIG. 3, the retransmission timing is given from the transmission host. If the retransmission timing is not reached, the process returns to step 1500.
[0053]
In step 1503, the private IP multicast address of the host group that is newly responsible for the retransmission frame designated by the host group notification frame in step 1503 is the destination IP address 712 of the IP header 610, and the host IP address is the source IP address 711. And retransmit it in IP. In the case of the designated host 247 of the host group 280 in FIG. 3, the frames 6 and 7 are retransmitted.
[0054]
In step 1504, it is determined whether or not a NACK frame has been received from an unreceived host of the host group to which it belongs. If not received, in step 1505, a retransmission completion frame 1600 is created toward the multicast data transmission host, and the own host IP address is set as the source IP address of the IP header 610, and the IP address of the transmission host 211 is set as the destination IP address. To IP and transmit to the input / output buffer 560. Here, the retransmission completion frame 1600 is as shown in FIG. The frame type 731 is stored in the retransmission completed frame type, the private IP multicast address 1610 belonging as the control information of the frame data portion 750 is stored, and the beginning 1620 and the end 1621 of the sequence number of the retransmission frame completed thereafter are stored.
[0055]
FIG. 17 shows a processing procedure of the communication processing apparatus 400 of the unreceived host. Here, the procedure after the transmission of the NACK frame is described. When the host group notification frame is received in step 1701, the control information 1000 of the host group notification frame is checked in step 1702, the IP address of the own host is searched for the reception host IP address 1002, and the private IP of the designated affiliation belongs. The multicast address 1001 and the IP address of the designated host are stored in the RAM 520.
[0056]
It is determined whether the retransmission frame received in step 1703 is an unreceived multicast frame of the own host. If the retransmission frame is normally received in step 1704, the process ends. If not normally received, the head 910 and the tail 920 of the unreceived frame sequence number are set in the control information 900 of the NACK frame in step 1705 to set the IP. Packetize. The destination IP address of the IP header is set with the designated host IP address of the retransmission source and transmitted to the input / output buffer 560.
[0057]
As another embodiment, a method of performing multicast by a method of performing delivery confirmation and retransmission control after the end of transmission control is also conceivable. In this method, since the delivery confirmation notification is performed after the multicast data is transmitted, it is realized by changing the timing of the delivery confirmation notification of the communication processing device 400 of the host that receives the multicast data. It is.
[0058]
As a third embodiment, a method of performing transmission control, delivery confirmation, and retransmission control in parallel as shown in FIG. 18 will be described. In this case, since the NACK frame is retransmitted without completing a single transmission of multicast data, the processing procedure of the communication processing device 400 is different as follows.
[0059]
First, the host group notification frame of the communication processing device 400 of the host 211 that transmits multicast data is transmitted more frequently. Further, the host group may be different for each host group notification frame timing. Therefore, the host group is dynamically changed in the host group notification frame. That is, when the status of the NACK received during the current host group notification frame notification changes greatly from the previous notification of the host group notification frame, the host group configuration change occurs, and step 1203 shown in FIG. Is different from the above. Accordingly, the host group to which the receiving host that is the designated host belongs is frequently changed in the process described with reference to FIG. In the receiving host, the host group to which the receiving host belongs and the designated host are frequently changed by the processing shown in FIG. There is no change in the basic processing procedure of the communication processing apparatus 400 related to the present invention on the receiving host side.
[0060]
Next, a description will be given of an embodiment of a multicast system in which a designated host is determined in advance and delivery confirmation and retransmission control are performed by the designated host. FIG. 19 shows the system configuration. In this figure, a transmission host 1900 transmits multicast data to hosts 1910, 1920, 1930, 1940, 1950, 1960, 1970, 1990 constituting a multicast group 1902 via an earth station device 1901907 for satellite communication. Host groups 1903, 1904, and 1905 are defined in advance. The host group 1903 includes hosts 1920, 1940, and 1950, and the host 1940 is the designated host. The host group 1904 includes hosts 1910, 1930, and 1960, and the host 1910 is a designated host. The host group 1905 includes hosts 1970, 1980, and 1990, and the host 1990 is the designated host.
[0061]
Each designated host aggregates delivery confirmation notifications from other hosts in the host group to which it belongs and notifies the transmission host 1900 of the reception status of each host group. For example, the designated host 1940 receives and aggregates the delivery confirmation notifications of the hosts 1920 and 1950 of the host group 1903 and sends them to the host 1900 as a reception aggregation frame.
[0062]
FIG. 20 shows a format of the control information 2000 of the received total frame. The control information includes a host group ID 2010, a receiving host IP address 2020, and a head 2030 and a tail 2040 of an unreceived frame sequence number of the receiving host. The transmission host 1900 completes transmission of the multicast data and creates a reception status management table 1100 from the reception total frame transmitted from each designated host. Thereafter, the system shifts to a retransmission control operation.
[0063]
Next, an example in which the host 1920 and the host 1930 are assumed as non-reception hosts and the configuration of the current host group is changed based on the reception status management table 1100 and retransmission control is performed by the designated host will be described.
In FIG. 19, the transmission host selects the host 1910 as the designated host, defines the host group 1906 with the unreceived hosts 1920 and 1930, and notifies the host group notification frame 1000. When the host 1910 selected as the designated host completes the retransmission control using the private IP multicast address for the new host group 1906, the host 1910 transmits the retransmission completion frame of the control information shown in FIG.
[0064]
By dynamically changing the host group at the time of retransmission control as in this embodiment, a normal reception host can receive multicast data without being affected by an unreceived host. By newly configuring a host group with only necessary hosts, retransmission processing can be made more efficient.
[0065]
Next, an implementation configuration when the present invention is applied to a land line will be described.
As described with reference to FIG. 1, in order to distribute multicast data on the ground unlike satellite links, it must pass through a plurality of networks on the multicast tree. Specifically, the network node that is a constituent element of the tree corresponds to a router, a gateway, or a computer having a path control function, and a router is usually used as a network node. In a network composed of these routers, when performing multicast, the Internet uses IGMP, DVMRP, and MOSPF as described in the prior art.
[0066]
In order to realize the dynamic multicast of the present invention based on these techniques, control information in a format in which an IGMP message is extended as shown in FIG. 21 is exchanged between multicast-compatible routers.
FIG. 21 shows an example in which the subtype 2130 is provided in the unused area of the IGMP message and the identifier of the host group notification message is entered. After the checksum 2140, a public IP multicast address 2150, a private IP multicast address 2160 that is dynamically defined temporarily in the IP multicast address 2150, a designated host IP address 2170, and a host configured with the private IP multicast address 2160 It consists of IP addresses 2180 and 2190.
[0067]
FIG. 22 shows the configuration of the router 2200. The CPU 2210 executes the routing processing software in the ROM 2220, and sends out the received IP packet to the interface circuits 2240, 2250, and 2260 other than the interface that received the IP packet while referring to the routing table in the RAM 2230.
[0068]
The processing procedure of the router according to the present invention will be described with reference to FIG. When the host group notification message 2100 is received in step 2301, the designated host IP address 2170 and host IP addresses 2180 and 2190 constituting the private IP multicast group are checked in step 2302. In step 2303, it is determined whether or not all the hosts constituting the private IP multicast group are connected to the network of one subordinate interface with reference to the routing table of the own router. If all are connected, in step 2304, the received host group notification message 2100 is sent to the interface to the connected network. Otherwise, in step 2305, the private IP multicast address and the configuration host are registered in the routing table of the own router, and in step 2306, the received host group notification message 2100 is transmitted to the interface to the designated router and configuration host.
With the operation in FIG. 23, communication processing using the private IP multicast address is performed only in the private IP multicast group in charge of the designated host.
[0069]
Next, an embodiment in which multicast data can be easily received by dynamically changing the host group even when the receiving host moves will be described. When the host is moved in this way, a wireless line covering a wide area such as a satellite line is very advantageous, but the ground line in FIG. Here, the operation when the receiving host of the multicast system using the satellite line moves under the control of another earth station apparatus will be described with reference to FIG.
[0070]
In this figure, the sending host 2402 sends multicast data to the receiving hosts 2412, 2413, 2422, 2423, 2424, 2432, and 2433 constituting the multicast group 2470 via the communication processing device 2400, the earth station device 2401, and the satellite line 2480. An example of transmission is shown. The receiving hosts 2412 and 2413 are connected to the communication processing device 400, the receiving hosts 2422, 2423 and 2424 are connected to the communication processing device 400, and the receiving hosts 2432 and 2433 are connected to the communication processing device 400 by a LAN (Local Area Network) 2419, respectively. Yes. When the receiving host 2423 under the earth station device 2420 moves to the LAN 2441 under the earth station device 2440, the communication processing device 2400 dynamically changes the multicast group configuration as follows.
[0071]
That is, when the moving host 2423 moves under the control of the communication processing device 2440, a movement notification frame, which is one of the control frames described in FIG. 7, is transmitted from the LAN 2449 to the transmission host 2402 via the communication processing device 400 and the satellite line 2490. Is notified to the communication processing apparatus 400. The frame data portion 750 of the movement notification frame stores a unique host ID (which can be a MAC [Media Access Control] address) and a newly assigned host IP address as control information. If the host IP address is public, it can be used as a unique host ID. The communication processing device 400 of the receiving host 2423 that has received the movement notification frame newly adds the IP address of the receiving host 2423 to the network configuration table of the routing table.
[0072]
When the communication processing device 400 on the transmission host 2402 side receives the movement notification frame, the communication processing device 400 changes the multicast group 2460 so far to maintain the data distribution to the hosts constituting the multicast group 2470 so far. A multicast group 2460 is defined to include a satellite line 2490 connection to 2441. This new definition is made by updating the receiving host IP address in the IP multicast correspondence table shown in FIG. In this way, when a wireless line such as a satellite line is used, a new multicast group can be defined without increasing the network cost to the destination even if the receiving host moves, so that it is possible to easily cope with a moving body.
[0073]
Although the above embodiment has been described on the assumption of a satellite communication network, it can also be applied to terrestrial digital communication networks and mobile communication networks, which are other multicast transmission media.
[0074]
As described above, according to the present invention, the load on the transmission host can be distributed and a large-scale multicast system can be realized. In addition, according to some trouble situations, it becomes possible to avoid traffic congestion and data transmission stagnation by reconfiguring the host group and leaving it to the designated host belonging to the host group.
[0075]
In addition, the reconfigured host group can be configured by direct connection via a wireless (satellite) line without going through a network node such as a router. In addition, it is possible not to affect other networks by communication processing such as delivery confirmation or retransmission control, and it is possible not to be affected by other networks, and it is possible to improve the efficiency of communication processing and prevent the system efficiency from decreasing. become.
[0076]
【The invention's effect】
As described above, according to the present invention,
(1) A large-scale multicast system can be realized by distributing the load on the sending host.
(2) Traffic congestion and data transmission stagnation can be avoided.
(3) The consumption of network resources such as routers can be suppressed.
(4) It is possible to prevent the communication processing efficiency from being improved and the system efficiency from being lowered.
There is an effect
[Brief description of the drawings]
FIG. 1 is a system configuration diagram illustrating an outline of the present invention.
FIG. 2 is a diagram illustrating an outline of an embodiment in which the present invention is applied to a network using a satellite line.
FIG. 3 is a sequence diagram showing a specific embodiment using the satellite line of the present invention.
4 is a diagram showing a system configuration example for executing the sequence of FIG. 3; FIG.
FIG. 5 is a configuration diagram of a communication processing apparatus that executes the present invention;
FIG. 6 is a format diagram of an IP packet standardized by IETF.
FIG. 7 is a format diagram of a frame used in the embodiment of the present invention.
FIG. 8 is a flowchart illustrating a transmission processing procedure of a communication processing apparatus of a host that transmits multicast data according to the embodiment.
FIG. 9 is a control information format diagram of a NACK frame notifying an unreceived frame.
FIG. 10 is a control information format diagram of a host group notification frame for notifying a new host group.
FIG. 11 is a reception state management table managed by a communication processing apparatus connected to a transmission host.
FIG. 12 is a flowchart illustrating a host group definition and notification processing procedure of a communication processing apparatus connected to a transmission host.
FIG. 13 is an IP multicast correspondence table managed by a transmission host.
FIG. 14 is a private IP multicast address management table.
FIG. 15 is a diagram illustrating a processing procedure according to the present invention of a communication processing apparatus connected to a designated host.
16 is a control information format diagram of a retransmission completion frame used in the embodiment of FIG. 3;
FIG. 17 is a diagram illustrating a processing procedure related to retransmission control of a communication processing apparatus connected to an unreceived host.
FIG. 18 is a sequence diagram showing a specific embodiment using a satellite line.
FIG. 19 is a diagram illustrating an example of changing a host group according to the present invention.
FIG. 20 is a control information format diagram of a received total frame used in the embodiment of FIG. 19;
FIG. 21 is a host group message format diagram exchanged between routers to implement the present invention.
FIG. 22 is a configuration diagram of a router.
FIG. 23 is a diagram illustrating a processing procedure of a router according to the present invention.
FIG. 24 is a diagram illustrating an embodiment when the present invention is applied to a mobile host.
[Explanation of symbols]
100: Sending host,
151,159 ... Nominated host,
130, 131, 132, 133, 134 ... router,
152, 153, 154, 160, 162, 163 ... unreceived hosts,
200 ... communication satellite,
170, 171, 270, 280 ... Private IP multicast group,
210, 227, 235 ... Earth station device,
400: Communication processing device.

Claims (6)

In a multicast communication system consisting of a plurality of hosts connected to a network, performing communication processing by multicast from one host serving as a transmission host to a plurality of other hosts, and transmitting data,
The receiving host that has received the transmitted data among the other hosts includes means for transmitting a delivery confirmation to the transmitting host,
The sending host is
Means for receiving a delivery confirmation for the transmitted data from the other hosts;
Means for selecting, based on the received delivery confirmation, a designated host for performing the communication process for the unreceived host that could not confirm delivery of the data among the other hosts from the receiving host; ,
The selected designated host includes means for performing the communication process with respect to the unreceived host.
A multicast communication system. In the multicast communication system according to claim 1,
The sending host comprises means for configuring a host group comprising the receiving host and the unreceived host based on the received delivery confirmation;
Means for selecting a designated host from the receiving hosts in the configured host group,
The selected designated host includes means for performing the communication process with respect to the other unreceived hosts included in the host group to which the designated host belongs.
A multicast communication system. In the multicast communication system according to claim 1 or 2,
The communication process is a retransmission process to the unreceived host,
The selected designated host includes means for resending the data received by the designated host to the unreceived host.
A multicast communication system. In a multicast communication system comprising a plurality of hosts connected to a network and transmitting data by multicast from one host serving as a transmission host to a plurality of other hosts,
The plurality of other hosts are configured in advance with at least one host group including a designated host and other hosts,
The designated host includes means for counting delivery confirmations of data transmitted from the transmission host to other hosts in the host group and transmitting to the transmission host;
The sending host forms a new host group consisting of a receiving host that has received the sent data and an unreceived host that has not been able to confirm the delivery of the data, based on the delivery confirmation sent from the designated host. ,
Means for selecting a new designated host from the receiving hosts in the new host group,
The new designated host includes means for retransmitting the received data to other hosts included in the new host group to which the new designated host belongs.
A multicast communication system. In the multicast communication system according to any one of claims 1 to 4 ,
The plurality of hosts are:
Means for sending the received data delivery confirmation to the sending host;
And a means for requesting retransmission of data that could not be normally received. In the multicast communication system according to any one of claims 1 to 5 ,
A multicast communication system using a wireless line for the network.

Images