WO2004028099A1 - マルチキャストグループ接続装置 - Google Patents

マルチキャストグループ接続装置 Download PDF

Info

Publication number
WO2004028099A1
WO2004028099A1 PCT/JP2002/009564 JP0209564W WO2004028099A1 WO 2004028099 A1 WO2004028099 A1 WO 2004028099A1 JP 0209564 W JP0209564 W JP 0209564W WO 2004028099 A1 WO2004028099 A1 WO 2004028099A1
Authority
WO
WIPO (PCT)
Prior art keywords
bucket
network
multicast
multicast group
unit
Prior art date
Application number
PCT/JP2002/009564
Other languages
English (en)
French (fr)
Inventor
Tetsuya Itoh
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to PCT/JP2002/009564 priority Critical patent/WO2004028099A1/ja
Publication of WO2004028099A1 publication Critical patent/WO2004028099A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems

Definitions

  • the present invention relates to a technique for connecting a multicast group in a network having a multicast function.
  • IP unicast In normal IP (Internet Protocol) communication (IP unicast), data may be transmitted all at once to a plurality of, for example, 10 host terminals beyond a trunk line.
  • the source router or layer 3 switch
  • the source router needs to send an IP bucket individually to each host terminal, even if the contents of the data to be sent to all host terminals are the same.
  • Figure 24 shows an example of a case where data is transmitted to multiple host terminals simultaneously using normal IP tunics. As shown in Figure 24,
  • IP Unicast When IP Unicast is used, the same data flows through the trunk line 10 times.
  • FIG. 25 shows an example in which data transmission is simultaneously performed to a plurality of host terminals using the IP multicast.
  • the IP multicast bucket transmitted to the host terminal is copied as needed by the router at the end of the trunk line.
  • the IP multicast bucket copied by this router arrives at each host terminal downstream of the router.
  • data can be transmitted to a plurality of host terminals simultaneously. That is, when the same data is simultaneously transmitted to 10 host terminals as in the above example, only the IP multicast bucket storing the data for one unit flows through the trunk line.
  • the receiving mechanism of IP multicast mainly consists of processing between the router and the host, It can be divided into router and processing between routers.
  • the source host terminal that sends the IP multicast packet sends the IP multicast packet to the router, and the receiving host terminal on the receiving side sends the IP multicast packet to the router.
  • receiving the IP multicast bucket receives the IP multicast bucket.
  • FIG. 26 is a diagram for explaining the processing between the source host terminal and the router among the processing between the router and the host, and FIG. It is a figure which shows the process between host terminals.
  • the source host terminal is a diagram for explaining the processing between the source host terminal and the router among the processing between the router and the host
  • FIG. It is a figure which shows the process between host terminals.
  • the source host terminal the source host terminal that sends the IP multicast packet sends the IP multicast packet to the router, and the receiving host terminal on the receiving side sends the IP multicast packet to the router.
  • FIG. 26 is a diagram for explaining the processing between the
  • IP multicast address whose destination address is set to a multicast group address (sometimes referred to as “IP multicast address”).
  • Multicast bucket ”) is sent to the router.
  • IP address "22 4. 0. 0. 0J from” 239. 25 ⁇ . 255. 255 "is used as a multicast group address.
  • the IP multicast packet set to the "239.255.0.0" destination address which is one of the multicast group addresses, is transmitted from the source host terminal.
  • the IP multicast bucket is transmitted to all nodes in the subnet to which the source host terminal belongs. Therefore, this IP multicast bucket arrives at the nearest router.
  • the receiving host terminal in order for the receiving host terminal as shown in Fig. 27 to receive an IP multicast packet from a router, an IP multicast packet addressed to a specific multicast group address must be sent to the nearest router. You need to request the delivery of In the example shown in Fig. 27, in order to receive the IP multicast packet of "239.255.0.0.0" transmitted from the transmitting host, the receiving host terminal receives the IP multicast of the address. You must request the nearest router to deliver the bucket. At this time, the receiving host terminal uses a standard called IGMP (Internet Group Management Protocol) for requesting the router to transmit the IP multicast packet. 1 GMP is used when a receiving host terminal requests a router to receive an IP multicast packet and when it stops sending an IP multicast packet. IGMP has been standardized by an organization called Internet Engineering Task Force (IETF). This Therefore, it can be said that the processing between the router and the host is the same in all networks, even if there are slight differences in the versions.
  • IGMP Internet Group Management Protocol
  • FIG. 28 is a diagram illustrating an example of processing between routers in IP multicast.
  • each router exchanges the control information necessary to transfer the IP multicast bucket using the multicast routing protocol, and in accordance with the appearance or disappearance of the receiving host. Update its own multicast routing table.
  • the multicast routing table of router a in accordance with a request from the receiving host terminal (appearance of the receiving host), stores an IP multicast bucket addressed to "239.255.0.0". The information that the data is transferred to the right side is stored.
  • each router forwards the IP multicast packet received from the upstream router to the downstream router according to the multicast routing protocol.
  • the IP multicast packet addressed to “239.255.0.0.0” transmitted from the source host terminal enters router a.
  • Router a refers to the destination address value (IP multicast address) “239. 25.5.0.0” included in this IP multicast bucket, refers to the multicast routing table, and performs IP multicasting.
  • Routers b, c, and d perform the same operation as router a, and transmit the IP multicast bucket according to the multicast routing table created according to the multicast 1 routing protocol.
  • the IP multicast packet transmitted from the source host terminal arrives at the receiving host terminal via the routers a, b, c, and d.
  • the receiving host terminal requests the nearest router to stop receiving IP multicast packets using IGMP (leaving from the multicast group).
  • IGMP leaving from the multicast group.
  • the routers a, b, c, and d update the multicast routing table according to the multicast routing protocol, and the receiving host terminal receives an IP multicast packet from the source host terminal. Learn to do so.
  • each router updates the multicast routing table in accordance with the appearance or disappearance of the receiving host terminal.
  • a multicast routing protocol termination method disclosed in JP-A-2002-77239 has been proposed.
  • this multicast routing protocol termination method in a connectionless communication network, multicast communication is stably and economically realized by minimizing the convergence time of control messages and the bandwidth consumption of control messages. .
  • an inter-LAN relay device disclosed in Japanese Patent Application Laid-Open No. 2000-134208 has been proposed.
  • an information network that includes a plurality of LANs to which hosts such as terminals and multicast servers are connected, and a plurality of LAN-to-LAN relay devices that connect LANs, individual LAN-to-LAN relay devices
  • individual LAN-to-LAN relay devices In addition, it has a conversion processing unit that performs conversion operation between L2 level multicast protocol such as GNIRP and L3 level multicast protocol such as IGMP, and an L2 multicast table.
  • L2 level multicast protocol such as GNIRP
  • L3 level multicast protocol such as IGMP
  • a terminal even if a terminal does not have an L2 level multicast protocol processing function, it can be used in the IP subnet to which the terminal belongs as if it supports L2 level G MRP. It is intended to realize the selective distribution of a multicast bucket to the terminal concerned.
  • FIG. 29 is a diagram illustrating a problem when a different multicast routing protocol is used.
  • Network A uses multicast routing protocol A, and network B interconnects with multicast routing protocol A
  • multicast routing protocol B which has no uniqueness, is used.
  • the control information for generating the route of the IP multicast bucket cannot be exchanged between network A and network B. Therefore, the receiving host terminal joins the multicast group in order to receive the IP multicast packet transmitted from the transmitting host terminal on network A at the receiving host terminal on network B.
  • the transfer route of the IP multicast bucket between them is not established. Therefore, the receiving host terminal cannot receive the IP multicast bucket from the transmitting host terminal.
  • the above-mentioned problems are caused, for example, by connecting networks of different administrators (for example, networks of different companies), and transferring an IP multicast bucket from a transmission host on one network to another network. Occurs when trying to receive at the receiving host at. This is because the multicast routing protocol and multicast group address applied to each network are often different due to differences in the design philosophy of the administrator. Disclosure of the invention
  • an object of the present invention is to provide a multicast group connection technique that enables a multicast packet addressed to a certain multicast group to be delivered to another multicast group.
  • the present invention employs the following means in order to solve the above problems.
  • the present invention relates to a multicast group connection device, wherein detection means for detecting the appearance of a member participating in the first multicast group, and when the appearance of the member is detected by the detection means Means for participating in the second multicast group corresponding to the first multicast group; and a second multicast group transmitted by participating in the second multicast group.
  • the multicast group address is converted into an address suitable for the first multicast group. And deliver. Therefore, according to the present invention, it is possible to distribute a multicast bucket addressed to a certain multicast group to another multicast group.
  • the present invention provides a second detecting means for detecting the disappearance of the participating member, and a releasing means for leaving the second multicast group when the disappearance of the participating member is detected by the second detecting means. May be further included.
  • the multicast bucket due to the withdrawal of the participating members on the first multicast group side, the multicast bucket will not be received on the first multicast group side. Therefore, the second multicast group no longer sends the multicast bucket, and the delivery of the multicast bucket stops.
  • the detecting means in the multicast group connection device An exploration bucket transmitting unit for periodically transmitting an exploration bucket for exploring the existence of the participating member to the first multicast group; and a receiving bucket can be received only when the member exists. And a response bucket receiving unit for receiving a response bucket for each exploration bucket transmitted from the probe means, and the presence of the member may be detected by receiving the response bucket.
  • the second detecting means in the multicast group connection device monitors reception of a response bucket by the response bucket receiving unit, and when there is no response packet for a predetermined period, the participating member
  • the present invention is also directed to a multicast network connection device, which comprises a main unit connected to a first network and a second network; A probe unit connected to the main unit via at least one router or a layer 3 switch in the network, wherein the main unit has a multi-cast group address in the first network.
  • the above route is set on condition that a receiving host desiring to receive a bucket addressed to this multicast group address appears.
  • a probe bucket transmitting unit for periodically transmitting a probe bucket arriving at the probe unit via a layer 3 switch to the first network, and a response bucket of the probe bucket transmitted from the probe unit.
  • a detecting unit for detecting the appearance of the receiving host by receiving the data via the router or the layer 3 switch; and detecting the appearance of the receiving host by the detecting unit.
  • a requesting unit for requesting the second network to receive a packet addressed to the multicast group address in the second network corresponding to the multicast group address;
  • a receiving unit for receiving a packet addressed to the multicast group address in the second network transmitted from the network,
  • An address conversion unit for converting a destination address of a bucket received by the unit into a corresponding multicast group address in the first network; and a bucket for which the destination address is converted by the address conversion unit.
  • a transmitting unit for transmitting to the first network.
  • the probe unit includes means for generating and transmitting a response bucket corresponding to each of the search buckets each time the probe packet is received.
  • the main unit when distributing a multicast bucket between the first and second networks, the main unit sends the destination address of the multicast bucket to the second network. Change from the network address to the first network address. Therefore, according to the multicast network connection device of the present invention, it is possible to distribute a multicast bucket between the first and second networks.
  • the probe unit receives the exploration bucket only while the reception host is present, and the detection unit transmits the response bucket. Monitoring the reception of the packet, and detecting the disappearance of the receiving host when no response bucket has been received for a predetermined time.
  • the requesting unit when the detecting unit detects the disappearance of the receiving host, the second requesting unit.
  • the second network may be requested to stop receiving a packet addressed to the multicast group address in this network.
  • the present invention is also a device for detecting a receiving host of a multicast bucket, wherein the main unit is connected to a network, and the main unit is connected to the network via at least one router or a layer 3 switch. And a probe unit connected to the network unit, wherein the main unit is configured to receive a multicast group address in the network as a destination address and to receive a packet addressed to the multicast group address.
  • a search bucket transmitting unit for transmitting a search bucket arriving at the probe unit to the first network via the router or the layer 3 switch on condition that a search packet has appeared, and a search bucket transmitted from the probe unit. By receiving the response packet of the packet via the router or the layer 3 switch, the appearance of the receiving host can be determined.
  • a detection unit for detecting, and the probe unit includes means for generating and transmitting a response bucket corresponding to the search bucket when receiving the search bucket.
  • a receiving host that desires to receive a multicast bucket addressed to a multicast group address is detected by a main unit and a probe unit. Therefore, according to the apparatus for detecting a receiving host of a multicast bucket according to the present invention, it is possible to accurately detect the receiving host and appropriately perform the self-communication of the multicast packet.
  • the probe unit receives the exploration bucket only while the receiving host is present, and the detecting unit responds to the response packet. The reception of the bucket may be monitored, and if there is no response bucket for a predetermined time, the disappearance of the reception host may be detected.
  • FIG. 1 shows a configuration and an application example of the present invention.
  • FIG. 2 shows a process of transmitting a search bucket according to the present invention.
  • FIG. 3 shows an exploration bucket incoming notification process in the present invention.
  • FIG. 4 shows a process of receiving a bucket from a source host terminal according to the present invention.
  • FIG. 5 shows the address translation process in the present invention.
  • FIG. 6 shows a state where the receiving host terminal is receiving data in the present invention.
  • FIG. 7 shows the configuration of the embodiment.
  • FIG. 8 shows a functional block diagram of the present invention in the embodiment.
  • FIG. 9 shows the IP setting of the encoder in the embodiment.
  • FIG. 10 shows an address translation policy in the embodiment.
  • FIG. 11 shows a conversion table in the embodiment.
  • FIG. 12 shows a configuration of an exploration bucket in the embodiment.
  • FIG. 13 shows a state before the decoder requests reception of video data in the embodiment.
  • FIG. 14 shows a state immediately after the decoder requests reception of video data in the embodiment.
  • FIG. 15 shows a state in which the probe unit has received a search bucket in the embodiment.
  • FIG. 16 shows a configuration of a response bucket in the embodiment.
  • FIG. 17 shows a state where the main unit receives the response bucket in the embodiment.
  • FIG. 18 shows a conversion table immediately after receiving a response packet in the embodiment.
  • FIG. 19 shows a state in which the main body receives the video data bucket in the embodiment.
  • FIG. 20 shows a state where all processes for receiving video data to the decoder are completed in the embodiment.
  • FIG. 21 shows a state where the decoder stops receiving video data in the embodiment.
  • FIG. 22 shows a state in which the transfer of the central image data is completely stopped in the embodiment.
  • FIG. 23 shows a flowchart of the embodiment.
  • Fig. 24 shows an example of IP Unicast communication.
  • FIG. 25 shows an example of IP multicast communication.
  • Figure 26 shows the processing between the source host terminal and the router in IP multicast.
  • Fig. 27 shows the processing between the router and the receiving host terminal in IP multicast.
  • FIG. 28 shows a process between routers in IP multicast.
  • Figure 29 shows the problem when the multicast routing protocol is different.
  • FIG. 1 is a schematic diagram showing the configuration of the present invention.
  • the multicast network connection device of the present invention includes, for example, a main unit 100 and a probe unit 200.
  • the main unit 100 is installed between a network A managed by the administrator A and a network B managed by the administrator B.
  • the main body 100 is connected to both the network A and the network B.
  • the main body 100 is connected to a router in the network A via the network A sub-network.
  • the main body 100 is connected to a router in the network B via a subnetwork of the network B.
  • the probe unit 200 is installed on the network B, which is the receiving side of the IP multicast bucket.
  • the probe unit 200 is connected to a main body 100 and a subnet that is separated from one router in the network B.
  • FIG. 2 shows how the main body 100 of the multicast network connection device of the present invention transmits an exploration bucket in order to search for a receiving host terminal that receives an IP multicast bucket.
  • the main body 100 constantly transmits a search packet to the network B side in order to search for a receiving host terminal that desires to receive an IP multicast packet. For example, assuming that the multicast group address of network B on the receiving side is “Gb”, main unit 100 transmits a search bucket addressed to “Gb” to network B side. If there is no receiving host terminal that wants to receive the multicast group address "Gb" in network B, this probe packet is discarded by the nearest router (router R1).
  • FIG. 3 shows what happens when the receiving host terminal appears on network B.
  • a receiving host terminal that receives the multicast group address “Gb” appears in the network B while the main body unit 100 is transmitting the search bucket.
  • the exploration bucket follows the multicast routing protocol used in network B, and passes through router R 1 near the main unit 100, The data is transferred to the downstream sub-network.
  • the exploration bucket arrives at each of the downstream routers R 2 and R 3 and also arrives at the probe unit 200.
  • the probe unit 200 recognizing that the exploration bucket has arrived at itself notifies the main unit 100 of this fact.
  • the main unit 100 recognizes that the “Gb” receiving host terminal 300 has appeared in the network B, regardless of what multicast routing protocol is used in the network B. Can be recognized.
  • FIG. 4 shows how the receiving host terminal 300 makes a request for an IP multicast packet to the network A via the main body 100.
  • the main unit 100 which recognizes that the receiving host terminal of “G b” has appeared, sends an IP multicast to the multicast group address “Ga” to the network A side. Request that the bucket be sent to the main body 100. That is, the main body 100 participates as a receiving host in a predetermined multicast group on the network A side (a multicast group corresponding to the multicast group on the network B side in which participation of the receiving host has been detected). .
  • a protocol called IGMP is used for requesting the IP multicast bucket.
  • an IP multicast packet is transmitted to the source host terminal 400 having the IP address "Sa” and to the multicast group address "Ga".
  • the IP multicast packet transmitted from the source host terminal 400 has the source address information “Sa” and the destination address information “Ga”, and the multicast used in the network A.
  • Incoming call arrives at main unit 100 in accordance with the routing protocol.
  • FIG. 5 shows conversion of source address information and destination address information of an Ip multicast bucket by the main body 100 of the present invention.
  • the main unit 100 upon receiving the IP multicast packet addressed to the multicast group address "Ga", the main unit 100 changes the destination address of the IP multicast packet to "Gb". Also, after changing the source address to an address such as “Sb” corresponding to the network B side, the main body 100 relays the IP multicast bucket to the network B side.
  • FIG. 6 shows how IP multicast packets are delivered from the source host terminal 400 to the receiving host terminal.
  • the destination address information of the IP multicast packet relayed to the network B side has been changed to the multicast group address adopted in the network B by the main body 100. Therefore, the IP multicast bucket having the destination address “Gb” wants to receive the IP multicast bucket of the destination address information “Gb”, following the multicast routing protocol in the network B.
  • the call arrives at the receiving host terminal 300.
  • the IP multicast bucket transmitted on the network A can be received by the host in the network B.
  • the receiving host terminal 300 requests the router R3 to leave the multicast group according to the IGMP procedure. Then, the routers R3, R2, and R1 exchange control information according to the multicast routing protocol, update the multicast routing table, and do not transfer the IP multicast packet addressed to "Gb".
  • the probe unit 200 cannot receive the search bucket addressed to "Gb". Exploration for "Gb” Since the bucket does not arrive, the probe unit 200 does not notify the body unit 100 of the arrival of the exploration bucket. As a result, the main body unit 100 recognizes that there is no receiving host terminal 300 of the destination address information “Gb” in the network B.
  • the main body 100 is connected to the source host terminal 400 on the network A side.
  • FIG. 7 shows an overall configuration of a network system using a multicast network connection device according to the embodiment.
  • the multicast network connection device of the present invention connects a network A and a network B having different design concepts, and enables distribution of a multicast bucket from the network A to the network B.
  • Network A has the following configuration. That is, the routers R 4 and R 5 are connected to the router network.
  • the router R5 is connected to the encoder (source host terminal) 1 (400) and the encoder (source host terminal) 2 (500) via the subnetwork (192.168.1.10/24). It is connected to the.
  • the router R 4 is connected to the sub network (192.168.2.0/24).
  • Network B has the following configuration. That is, routers R 2 and R 3 are connected to the router network.
  • the router R3 is connected to a decoder (receiving host terminal) 300 via a subnetwork (192.16.3.0/24).
  • Router R2 is connected to router R1 via a subnetwork (172.16.2.0/24).
  • Router R1 is further connected to the subnetwork (172.16.1.0/24).
  • the multicast group connection device includes a main unit 100 and a probe unit 200.
  • the main unit 100 is connected to the sub-network of Network A (192.168.1.0/24) and the sub-network of Network B (172.16.1.0/24), respectively.
  • the probe unit 200 is connected to the sub-network (172.16.2.0/24) of the network B, and is connected to the main unit 100 via the router R1.
  • Network A is designed and operated based on the following policy (design concept).
  • Encoder 1 (400) and encoder 2 (500) in network A correspond to the sending host in the present invention.
  • Each encoder 400, 500 is set according to the table shown in Fig. 9.
  • the IP address (192.168.1.1) is set for the encoder 400, and the encoder 400 uses "239.255.0.”
  • the IP address (192.168.1.2) is set for the encoder 500, and the encoder 500 uses "239.255.0.2" as the multicast group address of the IP multicast bucket used for video distribution. Is used, and "15" is set as the TTL value for this IP multicast bucket.
  • Network B is designed and operated based on the following policy (design concept).
  • the decoder 300 in the network B corresponds to a receiving host in the present invention.
  • the decoder 300 connected to the network B receives the video data transmitted from the encoder 400, 500 connected to Nettowa click A, the address encoder 400, 500 is used, as described above Use is prohibited in Network B.
  • FIG. 10 is a table showing the contents of the address conversion set for main body unit 100.
  • the video data bucket transmitted from the encoder 400 has its source IP address converted from “192.168.1.1” to “172.16.1.1” and the destination address (multicast group). Address) is converted from “239.255.0.1” to "239.192.0.1", and the TTL value of the IP multicast bucket is reset to "15".
  • the source IP address is converted from “192.168.1.2” to “172.16.1.2” in the main unit 100, and the destination address (multicast group). Address) is converted from “239.255.0.2” to "239.192.0.2", and the TTL value of the IP multicast bucket is reset to "15".
  • FIG. 8 is a functional block diagram of the main body 100 and the probe 200 in the present embodiment.
  • the main unit 100 is composed of a conversion table management unit 1, an exploration bucket generation unit 2, an I / O unit 3 for the network B, a bucket classification unit 8, and an ARP (Address Resource Protocol). )
  • a processing unit 9 a response bucket processing unit 10, an IGMP processing unit 11, and an I / O unit 12 to the network A.
  • the conversion table management unit 1 includes conversion information for converting header information (a source address, a destination address, and a TTL) of an IP multicast packet transferred from the network A to the network B; It manages a conversion table 1a for managing the active information of the multicast group on the side.
  • FIG. 11 is a diagram illustrating an example of the conversion table 1a.
  • the conversion table 1a includes conversion target information indicating a combination of a source address and a destination address to be converted, conversion value information indicating a combination of a source address and a destination address after conversion, and a TTL value after conversion.
  • An entry is prepared for each multicast group on the transmitting side of an IP multicast packet.
  • the conversion target information is transmitted from the source set in the header of the IP multicast bucket to be transferred from network A (sending network) to network B (receiving network).
  • network A sending network
  • network B receiving network
  • the source IP address here is the IP address of the transmission host of the IP multicast bucket
  • the destination address is a multicast group address in the transmission side network (network A).
  • the conversion value information indicates a source IP address and a destination IP address set in the header of the IP multicast bucket by the address conversion.
  • the destination IP address here is a multicast group address in the receiving network (network B) of the IP multicast bucket.
  • the source IP address is a dummy source IP address (not the IP address of the main unit 100 (172.16.1.10 in this example)), and is an IP address that can be identified by a node in network B. Address is assigned. For example, as a recognizable IP address in the network B, a host address not used in the subnetwork in which the main body 100 is accommodated is assigned. In this embodiment, in order for the main body 100 to receive the response bucket from the router R1, the host address of the subnet 172.16.0 / 0/24 accommodating both is used as the source address of the converted value. ing.
  • the TTL value indicates the TTL value that is reset in the IP multicast bucket after address conversion.
  • the activity flag indicates the activity of the multicast group included in the conversion value information, that is, whether or not there is a receiving host participating in the multicast group in the receiving network of the IP multicast bucket. This flag is ON if there is at least one participating receiving host, and OFF if there is no participating receiving host.
  • the timer value indicates an allowable reception time of the response bucket of the exploration bucket.
  • the timer value becomes zero.
  • an initial value severe seconds to several tens of seconds
  • the timer value is used for 0NZ0FF control of the activation flag in the same entry.
  • the conversion table 1a shown in FIG. 11 holds contents according to the setting contents shown in FIG. That is, in the conversion table 1a, two entries 1 and 2 corresponding to the encoders 400 and 500 in the network A are prepared in accordance with the setting contents shown in FIG.
  • the conversion table management unit 1 sets and resets a timer value for each entry of the conversion table 1a, and performs ON / OFF control of an activation flag based on the timer value.
  • the conversion table management unit 1 sets and resets the timer value according to the response notification received from the response bucket processing unit 10.
  • the exploration bucket generation unit 2 refers to the conversion table 1a managed by the conversion table management unit 1, and according to the entry contents, the multicast of the receiving side. Generates an exploration packet (see Fig. 12) for each group and passes it to the I / O unit 3.
  • the I / O unit 3 has an interface function with the network B.
  • the I / O unit 3 has a search bucket received from the search packet generation unit 2, an ARP response bucket received from the ARP processing unit 9, and a transfer target received from the header conversion unit 13. Sends an Ip multicast bucket (target packet) to network B.
  • the I / O unit 3 receives various buckets such as a response bucket of an exploration bucket from the network B, and passes them to the bucket classifying unit 8.
  • the bucket classification unit 8 receives all buckets received by the I / O unit 3 and the I / O unit 12.
  • the bucket classifying unit 8 refers to the header and / or payload (information field) of the received bucket to determine the type of the packet.
  • the bucket from the I / O unit 3 is composed of a response bucket of an exploration bucket, an ARP request bucket, and other buckets.
  • the packet from the I / O unit 12 is an IP multicast packet. I Consists of GMP packets and other buckets.
  • the bucket classifying section 8 passes the bucket to the response bucket processing section 10 if the bucket discrimination result is a response bucket, and passes the bucket to the ARP processing section 9 if the bucket is an ARP request bucket, and sends the packet to the IGNIP packet. If it is, it is passed to the IGMP processing unit 11, and if it is an IP multicast bucket or another bucket, it is passed to the header conversion unit 13.
  • the bucket classification unit 8 may ignore or discard other buckets.
  • the ARP request unit 9 analyzes the ARP request packet from the packet classification unit 8 and refers to the conversion table 1 a to determine whether or not to respond to the ARP request bucket (whether or not the ARP request is addressed to itself). If it is determined that a response is required, an ARP response bucket including a MAG (Media Access Control) address (device address) of the main body 100 is generated and given to the I / O unit 3.
  • MAG Media Access Control
  • the ARP request unit 9 is configured to determine whether the IP address to be searched included in the ARP request packet is the same as the source IP address in the conversion value information of any entry in the conversion table 1a. It determines that the ARP request bucket is addressed to itself.
  • the response bucket processing unit 10 analyzes the response bucket from the bucket classification unit 8 and determines the multicast group of the network B in which the receiving host participates, which is included in the response bucket.
  • a response notification including information for specifying is given to the conversion table management unit 1.
  • the response notification includes the activation flag of the entry corresponding to the conversion table Used to control a timer.
  • the GMP processing unit 11 According to the value of the activation flag of each entry of the translation table 1a managed by the translation table management unit 1, if there is an entry for which the activation flag is on, the GMP processing unit 11 The main unit 100 generates an IGMP bucket for joining or leaving the specified multicast group of the network A as a receiving host, and gives it to the I / O unit 12. Also, the IGMP processing unit 11 receives an GNIP packet for inquiring of the multicast group in the network A whether or not the main unit 100 continues the participation state as a receiving host. At this time, if the activation flag in the entry of the corresponding conversion table 1a is on, the IGMP processing unit 11 generates an I GNIP bucket indicating that participation in the multicast group is continued. To the I / O section 12.
  • the I / O unit 12 has an interface function with the network A, and sends out an IGMP bucket from the IGMP processing unit 11 to the network A.
  • the I / O unit 12 receives an IGMP bucket, an IP multicast bucket, and the like from the network A, and passes all received buckets to the bucket classification unit 8.
  • the main unit 100 receives the IP multicast packet to be transferred from the network A to the network B, converts the header information thereof, and transmits the packet to the network B.
  • a function for detecting the joining / leaving of the receiving host to / from the multicast group in the network B corresponding to the given multicast group, and the function for detecting the joining / leaving of the receiving host to / from the multicast group in the network B It has a function to join and leave the corresponding multicast group of network A as a receiving host.
  • the probe unit 200 includes an I / O unit 4, a packet classification unit 5, a search packet processing unit 6, and a response bucket generation unit 7.
  • the I / O unit 4 is connected to the network B and manages an interface function, and passes all packets received from the network B to the packet classification unit 5.
  • the I / O unit 4 sends the response bucket received from the response bucket generation unit 7 to the network B.
  • the c- packet classification unit 5 receives all the packets received by the I / O unit 4.
  • the packet classification unit 5 refers to the header and header or the payload (information field) of the received bucket, and determines the type of the bucket. That is, the bucket classification unit 5 determines whether or not the bucket from the I / O unit 4 is an exploration bucket. If the packet discrimination result is a search bucket, the bucket classification unit 5 passes it to the search bucket processing unit 6. The bucket classification unit 5 may ignore or discard other buckets.
  • the exploration bucket processing unit 6 extracts information from the payload of the exploration bucket received from the bucket classification unit 5. Then, the search bucket processing unit 6 notifies the information extracted from the search bucket to the response packet generation unit 7.
  • the response bucket generation unit 7 uses the information from the exploration bucket processing unit 6 as a response bucket transmission instruction, and generates a response bucket based on this information. Then, the response bucket generating unit 7 transmits the generated response bucket to the I / O unit 4.
  • the above-described conversion table management unit 1, search packet generation unit 2, I / O unit 3, and response bucket processing unit 10 perform the IGMP processing corresponding to the detection means in the multicast group connection device of the present invention.
  • the unit 11 and the I / O unit 12 correspond to participation means in the multicast group connection device according to the present invention.
  • the above-mentioned I / O unit 12 corresponds to a receiving unit in the multicast group connection device according to the present invention.
  • the above-described header conversion unit 13 corresponds to a conversion unit in the multicast group connection device according to the present invention.
  • the above-mentioned I / O unit 3 corresponds to a transmission unit in the multicast group connection device according to the present invention.
  • the above-mentioned second detection means corresponds to the conversion table management unit 1 in the multicast group connection device according to the present invention.
  • the above-described exploration bucket generating unit 2 and I / O unit 3 correspond to an exploration bucket transmitting unit in the multicast group connection device according to the present invention.
  • the above-described probe unit 200 corresponds to a probe unit in the multicast group connection device according to the present invention.
  • the above-described I / O unit 3 corresponds to a response bucket receiving unit in the multicast group connection device according to the present invention.
  • the above-mentioned networks A and B correspond to the second network and the first network in the multicast network connection device of the present invention.
  • the above-mentioned exploration bucket generating unit 2 is connected to the multicast network connection of the present invention. This is equivalent to a layer 3 switch in the connection device.
  • the above-mentioned I / O unit 3 corresponds to a search bucket transmitting unit in the multicast network connection device of the present invention.
  • the above-mentioned IGMP processing unit 11 and I / O unit 12 correspond to a request unit in the multicast network connection device of the present invention.
  • the above-mentioned I / O unit 12 corresponds to a receiving unit in the multicast network connection device of the present invention.
  • the above-described header conversion unit 13 corresponds to an address conversion unit in the multicast network connection device of the present invention.
  • the above-mentioned I / O unit 3 corresponds to a transmitting unit in the multicast network connection device of the present invention.
  • the above-mentioned I / O unit 4, packet classifying unit 5, exploration packet processing unit &, and response packet generation unit 7 generate and send a response packet in the multicast network connection device of the present invention. Is equivalent to
  • the I / O unit 12 of the main unit 100 is connected to the network A, and the I / O unit 3 is connected to the network B.
  • the I / O unit 4 of the probe unit 200 is connected to a subnet (172.16.2.0/24) that is separated from the main unit 100 by one router.
  • FIG. 11 shows an address conversion table 1a of a video data bucket which is an IP multicast bucket transmitted from the encoder 400 and the encoder 500.
  • the notation "(source address, destination multicast group address)" may be used when expressing the IP multicast bucket.
  • entry 1 of conversion table 1a is an IP multicast bucket having a source address (192.168.1.1.1) and a destination address (239.255.0.1). This means that the source address is (172.16.1.1) and the destination address is converted to an IP multicast bucket (239.192.0.1). That is, the address information of the video data bucket transmitted from the encoder 400 is changed to address information that can be referred to on the network B.
  • the TTL value is set to 15 It also shows that Further, in the conversion table 1a, the activation flag and the timer are "OFF" and "0" respectively in the initial state.
  • the operation in the present embodiment starts when the search bucket generation unit 2 (FIG. 8) of the main body 100 of the multicast network connection device generates a search bucket.
  • Generation of the exploration packet is performed with reference to the conversion table 1 a (FIG. 11) stored in the conversion table management unit 1.
  • An exploration bucket is generated for each entry in the translation table 1a. That is, in this embodiment, the search bucket generating unit 2 generates two types of search buckets corresponding to the entry 1 (for the encoder 400) and the entry 2 (for the encoder 500), respectively.
  • FIG. 12 is a diagram showing an example of a search bucket, in which a search bucket corresponding to entry 1 is shown.
  • the search bucket generating unit 2 sets the source address information of the conversion value of the entry 1 in the conversion table 1a in the IP header as the source IP address of the search bucket.
  • the search bucket generating unit 2 sets the destination address information of the converted value in the entry 1 in the IP header as the destination address of the search bucket. That is, a multicast group address for exploring the participation of the receiving host is set as the destination address in the exploration bucket.
  • the search bucket generating unit 2 uses the TTL value ("15") of the entry 1 and sets the TTL value in the IP header of the search bucket.
  • UDP port 501 is used, and this port number is set in the UDP header. You.
  • exploration bucket generating unit 2 also generates an exploration bucket for entry 2 in the same manner as entry 1 described above.
  • the exploration bucket generating unit 2 periodically transmits the generated exploration bucket to the I / O unit 3.
  • the transmission interval of the exploration bucket at this time is appropriately adjusted for each network to be used, but is set to 100 ms in this embodiment. That is, a total of 20 buckets are transmitted to the I / O unit 3 for the search buckets of the entry 1 and the entry 2 at a rate of 10 buckets per second.
  • FIG. 13 shows the states of the network A and the network B before a receiving host desiring to deliver a video data bucket, which is an IP multicast bucket, appears.
  • the I / O section 3 of the main body section 100 transmits the search bucket received from the search packet generation section 2 to the subnet 172.16.1.0/24 of the network B.
  • the search packet transmitted by the main unit 100 arrives at the router R1. At this point, there is no receiving host terminal in network B that wishes to distribute the IP multicast bucket corresponding to entries 1 and 2. Therefore, the router R1 discards the received search packets for entries 1 and 2, respectively.
  • Fig. 14 shows the appearance when the decoder 300 appears as the receiving host terminal.
  • the decoder 300 of the network B is connected to the video data of the encoder 400. It is assumed that the reception of the bucket has started.
  • the decoder 300 joins the multicast group by using GNIP according to the standard procedure of the IP multicast (RFG1112, RFG2236).
  • the multicast group to which the decoder 300 participates is not “239.255.0.1”, which is the multicast group address used by the encoder 400 for video distribution. Participate in “239.192.0.1”, which is the multicast group address associated with the multicast group address by the main body 100.
  • the information that the decoder 300 has appeared as the receiving host terminal of the multicast group “239.192. 192. 0. 1 is transmitted to all the routers on the network B including the router R1. Do Then, the router R1 updates the multicast routing table so that the packet addressed to “239.192.0.1” from the subnet # 172.16.1.0 / 24 J is transferred to the subnet “172.16.2.0/24”.
  • the router R1 transfers the search packet for entry 1 which is a packet addressed to “239.192.0.1” to the subnet “172.16.2./24”. This means that the exploration bucket for entry 1 will be forwarded to the subnet "172.16.2.0/24". Note that the operation of the router R 1 does not change for the probe packet for the entry 2.
  • the search bucket for entry 1 transferred from the router R1 arrives at the I / O unit 4 (FIG. 8) of the probe unit 200.
  • IP multicast packets are handled as broadcasts at the layer 2 level, so that the exploration packets sent to the subnet “172.16.2.0/24” arrive not only at the router R2 but also at the probe unit 200. Because.
  • the I / O unit 4 transmits all the received packets to the packet classification unit 5. Therefore, the I / O unit 4 provides the search packet for the entry 1 to the packet classification unit 5.
  • the packet classification unit 5 classifies the packet received from the I / O unit 4.
  • the packet classification unit 5 can identify that the packet is a search packet by referring to the payload of the bucket and finding the identifier of the search bucket. As a result, if the bucket is an exploration bucket, it is transferred to the exploration bucket processing unit 6. If the bucket is not an exploration bucket, the bucket classifying unit 5 discards the bucket.
  • the response packet generator 7 generates a response bucket as shown in FIG. 16 based on the information obtained from the exploration bucket processor 6.
  • Fig. 16 shows an example of a response bucket in this embodiment, and the response to the search bucket of entry 1 is shown. A bucket is shown.
  • UDP port 501 is used in this embodiment, and is set in the UDP header.
  • the response bucket generating unit 7 includes, as payload of the response bucket, a bit pattern (identifier) indicating that the response bucket is a response bucket, and an entry number (in this case, a value copied from the exploration bucket).
  • the response bucket generator 7 transmits the response bucket to the I / O unit 4.
  • the I / O unit 4 transmits the response bucket to the router R1.
  • router R1 Upon receiving the response packet, router R1 sends an ARP request packet for IP address "172.16.1.1” on subnet "172.16.1.1". At this point, the router R1 has not obtained the MAC address (device address) corresponding to the IP address.
  • the I / O unit 3 classifies all the received packets into a packet classification unit 8.
  • the ARP request bucket is passed to the bucket classification unit 8.
  • the bucket classification unit 8 When the bucket classification unit 8 identifies that the bucket from the I / O unit 3 is an ARP request bucket, the bucket classification unit 8 transfers the ARP request packet to the ARP processing unit 9.
  • the ARP processing unit 9 determines whether it is necessary to return an ARP response to the received ARP request. This determination is made based on the conversion table 1a (FIG. 11) held by the conversion table management unit 1.
  • the ARP processing unit 9 searches the conversion table 1a for an entry in which the source address value of the conversion value field is the same as the IP address for which the ARP is requested, and if the corresponding entry exists, the ARP request Judge that it is necessary to return an ARP response to In this example, the source address value in the translation value field of entry 1 However, the ARP processing unit 9 determines that it is necessary to return an ARP response because the IP address matches the IP address requested for ARP.
  • the ARP processing unit 9 which has determined that the ARP response is to be returned generates an ARP response bucket (destination: router R 1) including the MAG address of the main unit 100 and sends this to the I / O. Send to Part 3.
  • the I / O unit 3 Upon receiving the ARP response packet, the I / O unit 3 transmits an ARP response packet to the subnet “172.16.1.0/24”.
  • the ARP response bucket is received by router R1.
  • the router R1 sets the obtained MAC address in the response packet, and sets the response packet according to the destination IP address “172.16.1.1” on the subnet “172.16.1.0/ 24 ".
  • main body 100 can receive the response bucket.
  • the above-described ARP request process is a process generally called proxy ARP.
  • the router R 1 uses the acquired MAG address of the main body 100 for the subsequent transfer of the response bucket corresponding to the entry 1.
  • FIG. 17 shows a state where the main body 100 has received the response bucket.
  • the packet classification unit 8 refers to the payload of the packet from the I / O unit 3, finds the identifier of the response packet, identifies that the packet is a response bucket, and maps the response bucket to the response bucket. Transfer to the block processor 10.
  • the conversion table management unit 1 checks whether the content of the response notification and the entry information of the conversion table 1a held by the conversion table management unit 1 are inconsistent. Specifically, the conversion value in the entry and the conversion value in the response notification are referred to by referring to the entry (here, entry 1) in the conversion table 1a corresponding to the entry number in the response notification. -Judge whether it matches. At this time, if the entry information is inconsistent (the conversion values do not match), the conversion table management unit 1 ignores the notification. If the response notification content and the content of the corresponding entry are not inconsistent (if the conversion values match), the conversion table management unit 1 sets the activation flag of the corresponding entry (entry 1) of the conversion table 1a. Set to "ON" and set the timer field value to a predetermined value.
  • FIG. 18 shows how the information in the conversion table 1a shown in FIG. 11 has been changed based on the response notification.
  • the value of the timer field in the entry indicates the lifetime of the active flag of the entry, and is decremented by 1 each time one second elapses. That is, in this example, the timer value becomes “0” after three seconds unless the conversion table management unit 1 receives a new response notification corresponding to the entry.
  • the conversion table management unit 1 sets the value of the activation flag to "OFF".
  • the conversion table management unit 1 notifies the IGMP processing unit 11 of the change.
  • the IGMP processing unit 11 When the direction of change of the activity flag is from OFF to ON, the IGMP processing unit 11 creates an IGMP Membership Report for the multicast group address included in the change notification.
  • an IGMP Membership R seal ort for 239.255.0.1 is created.
  • the IGMP Membership R mark ort is an IGMP message for requesting a router to join a host as a member of a given multicast group. The case where the activation flag changes from 0N to OFF will be described later.
  • the IGNIP processing unit 11 transmits the created IGMP Membership Report, that is, the Membership Report for “239.255.0.1” to the I / 0 unit 12.
  • the I / O unit 12 sends the IGMP Membership Report on the subnet “192.168.2.0/24” on the network A side.
  • This IGMP Membership Report arrives at router R4 as shown in Figure 19.
  • the router R4 sets the subnet “192.168.2.0” It recognizes that the main body 100 has appeared as a receiving host of "239. 255. 0. 1".
  • Router R 4 uses the multicast routing protocol (PI M-SM) adopted in network A, and sends the address to “2 39. 255. 0. 1” to other routers on network A. Request that the bucket be forwarded to itself.
  • PI M-SM multicast routing protocol
  • the I / O section 12 (FIG. 8) of the main body section 100 receives the video data packet “(192.168.1.1, 239.255.0.1)”. Since the I / O unit 12 transmits all the received packets to the packet classification unit 8, the I / O unit 12 transmits the video data bucket to the packet classification unit 8.
  • the packet classification unit 8 analyzes the type of the packet received from the I / O unit 12 and converts a packet that satisfies the condition that the packet does not correspond to an IMP packet, an ARP request packet, or a response packet into a header. Transfer to Part 13. The video data bucket satisfies the above conditions and is sent to the header conversion unit 13.
  • the header conversion unit 13 Upon receiving the video data bucket from the bucket classification unit 8, the header conversion unit 13 refers to the destination address of the conversion target field of the conversion table 1a and matches the destination address of the video data / packet. Search for entries. In this example, entry 1 is found. If there is no matching entry in the conversion table 1a, the header conversion unit 13 discards the bucket. On the other hand, when the corresponding entry is found, the header conversion unit 13 refers to the active flag of the entry. At this time, if the value of the activation flag is “ON”, the header conversion unit 13 changes the transmission source address and the destination address of the video data bucket to the value of the conversion value field.
  • the header converter 13 converts the source IP address and destination IP address “(192.168.1.1 and 239.255.0.1)” of the video data bucket to “(172. 16.1.1 and 239.192.0.1) are converted to ". If the activity flag is “OFF”, the header conversion unit 13 discards the IP multicast bucket. Then, the header conversion unit 13 converts the video data packet, for which the address conversion has been completed, into the I / O unit. Send to 3. Upon receiving the video data packet, the I / O unit 3 transmits the B image data packet on the subnet “172.16.1.0/24”.
  • Each router of the network B has a multicast routing table for transferring an IP multicast packet of “239.192.0.1” generated according to the multicast routing protocol (DVMRP) to the decoder 300. Therefore, as shown in FIG. 20, the video data bucket transmitted from the main unit 100 arrives at the decoder 300 via the router R1, the router R2, the router 'network, and the router R3. I do.
  • DVMRP multicast routing protocol
  • the decoder 300 that has received the B image data bucket takes out the video data from this bucket, performs a decoding process, and outputs a reproduced video.
  • the search bucket of entry 1 is transmitted to the network B at the above-mentioned cycle (1 O Oms) even after the response bucket reaches the main body 100.
  • the main unit 100 continues to transmit the exploration bucket regardless of the joining / leaving of the receiving host, and can receive the response bucket only when there is a participating receiving host. .
  • the router R4 is connected to the subnet “192.168”.
  • IG MP Membership Query for .2.0 / 24 is transmitted periodically.
  • the receiving host of the multicast bucket When receiving the IGMP Membership Query, the receiving host of the multicast bucket must respond to this with the IGMP Membership R mark ort. Failure to do so will cause the router to stop forwarding multicast packets (see RFC1112 and RFC2236).
  • the main unit 100 performs processing for the IGMP Menbership Query as follows. As shown in FIG. 8, an IGMP Membership Query arrives at the I / O section 12 of the main body section 100 as an IGMP bucket. The I / O unit 12 transmits the received IGMP bucket to the bucket classification unit 8.
  • the bucket classifying unit 8 identifies that the received bucket is an IGMP bucket
  • the bucket is transferred to the IGMP processing unit 11.
  • the IGNIP processing unit 11 Upon receiving the IGMP bucket, the IGNIP processing unit 11 refers to the conversion table 1a (FIG. 18) of the conversion table management unit 1 and lists all the entries whose active flag field value is "ON". In this example, only entry 1 is listed.
  • the IGMP processing unit 11 creates an IGMP Membership Report for the destination multicast group address of the conversion target field of the listed entry. In this example, the IGMP processing unit 11 creates an IGMP Membership Report for “239.255.0.1”. The IGMP processing unit 11 sends the created IGMP Membership Report to the I / O unit 12.
  • the I / O unit 12 sends an IGMP Membership Report on the subnet “192.168.2.0/24”. Then, the IGMP Membership Report from the main unit 100 arrives at the router R4 on the subnet “192.168.2.0/24”. As a result, the state of the main body 100 participating in the IP multicast bucket (multicast group) addressed to “239.255.0.1” is maintained. Therefore, the video data packet from the router R4 is continuously transferred to the network B via the main unit 100.
  • FIG. 21 shows how the transfer of the video data bucket and response bucket on Network B is stopped.
  • the decoder 300 leaves the multicast group "239.192.0.1” using the method (IGWIP) defined in [ ⁇ 01112 and [ ⁇ 02236].
  • the router R3 informs the network B using the multicast routing protocol (D VMRP) that the receiving host (decoder 300) of “239.192.0.1” has disappeared (“239.192.0.1 is unnecessary”). Notify other routers above (routers R1, R2, etc.).
  • each router on the network B updates the multicast routing table so as not to forward the IP multicast packet addressed to “239.192.0.1”.
  • the router R1 stops transferring the video data bucket and the search bucket.
  • the probe packet does not arrive at the probe unit 200. If the probe unit 200 does not receive the search packet, it will not transmit a response packet.
  • the timer field value of the entry 1 of the conversion table 1a managed by the conversion table management unit 1 in the main unit 100 becomes "0". This is because the timer field value is decremented by 1 every second and the initial timer value (3 seconds) is not reset unless the next exploration bucket comes.
  • the conversion table management unit 1 changes the activation flag field value of the corresponding entry (entry 1) of the conversion table 1 a from “ON” to “ON”. OFF ".
  • the conversion table management unit 1 notifies the IGMP processing unit 11 of the change in the activation flag.
  • the IGMP processing unit 11 receives the change notification, and when the direction of change of the activity flag included in the change notification is 0N ⁇ 0FF, declares that the mobile terminal has left the multicast group corresponding to the change notification.
  • Create IGNIP Leave Group Message as a message.
  • an IGMP Leave Group Message for 239.255.0.1 is created.
  • the I / O unit 12 Upon receiving the IGMP Leave Group Message, the I / O unit 12 transmits the IGMP Leave Group Message on the subnet “192.168.2.0/24”.
  • the IGMP Leave Group Message arrives at the router R4.
  • the router R4 recognizes that the receiving host (main unit 100) of the subnet “192.168.2.0/24” to “239.2550.1” has disappeared.
  • the router R4 notifies other routers on the network A using the multicast routing protocol (PIM-SM) that the reception host of “239.255.0.1” has disappeared.
  • Router R5 rewrites the multicast routing table so as not to forward the IP multicast packet addressed to “2 39.255 ⁇ 0.1”.
  • the router R5 stops transferring the video data bucket from the encoder 400. Note that the same processing as that of the entry 1 is performed for the entry 2, and the video data bucket from the encoder 500 is transmitted to the multicast group of the network B corresponding to the entry 2 of the decoder 300.
  • the video data transferred from the network A to the network B according to the participation / withdrawal from the network is received by the decoder 300, and the video data included in the video data bucket is decoded and reproduced.
  • the video of the encoders 400 and 500 connected to the network A can be reproduced and output by the decoder 300 connected to the network B.
  • the main body 100 sends a search bucket to the network B periodically.
  • the main unit 100 determines whether or not the decoder 300 has requested the delivery of the IP multicast bucket (step 101 in FIG. 23; hereinafter, abbreviated as S 101). If the decoder 300 has not requested the delivery of the IP multicast bucket, the exploration bucket is discarded, and the processing of step 101 is repeated.
  • the search packet transmitted from 00 is received (S102).
  • the probe unit 200 transmits a response bucket to the main unit 100 (S103).
  • the response bucket transmitted by the probe unit 200 arrives at the main unit 100 (S100).
  • main body 100 recognizes the presence of decoder 300 in network B.
  • the main body 100 transmits the IGMP Membership R mark ort to the network A where the encoder 400 is located (S105).
  • the main body section 100 receives the video data bucket from the encoder 400 (S106) o
  • the main unit 100 changes the source address information and the destination address information of the video data bucket into information corresponding to the network B, and transfers the information to the network B side (S107). .
  • the video data bucket transferred to the network B side flows from the upstream router to the downstream router, and arrives at the decoder 300 (S108).
  • the main unit 100 confirms whether the decoder 300 has stopped receiving the video data bucket (S109). If the decoder 300 continues to receive the video data bucket, the main body 100 repeats the processing of step 109.
  • the search bucket does not reach the probe unit 200 (S110). Therefore, the probe unit 200 stops transmitting the response bucket to the main unit 100.
  • the main body unit 100 recognizes that the decoder 300 on the network B side has disappeared in response to the fact that the response bucket is no longer received (S111).
  • the main unit 100 communicates to the network A side with an IGMP Leave Group Message that the decoder 300 has disappeared. Yes (S 1 1 2).
  • the encoder 400 Upon receiving the notification from the main body 100, the encoder 400 stops the distribution of the B image data bucket. '
  • IP multicast distribution can be performed between networks where the multicast group address and the multicast routing protocol do not match.
  • video collected by a public institution on the intranet can be multicasted to private networks as IP data.
  • the main unit 100 is connected to the network A and the network B, and the probe unit 200 is connected to the subnet separating the main unit 100 and one router.
  • the multicast routing protocol and the multicast group address of the network A and the network B are not limited to the conditions described in the above embodiment, and can be changed within a range that does not hinder the operation of the embodiment.
  • network A and network A Network B and the multicast routing protocol may be the same.
  • the example in which the video data is distributed by IP multicast is described, but the data to be distributed may be text data, image data, audio data, a combination thereof, or at least one of them and the video data. May be combined.
  • the distribution of the video data bucket from the encoder 1 (400) to the decoder 300 has been described, but the distribution from the encoder 2 (500) is of course performed in the same manner.
  • At least one of the routers described in the present embodiment may be a layer 3 switch.
  • multicast network connection device of the present invention is not limited to the present embodiment, and it is needless to say that various changes can be made without departing from the scope of the present invention.
  • the multicast network connection device of the present invention when transmitting and receiving the same IP multicast bucket at the same time between networks to which a large number of host terminals are connected, when the design philosophy is different. However, it is possible to easily and accurately perform the multicast distribution.

Description

明 細 書 マルチキャス卜グループ接続装置 技術分野
本発明は、マルチキャス卜機能を有するネッ卜ワークにおいてマルチキャストグ ループを接続する技術に関する。 背景技術
通常の I P ( I nternet Protoco l ) 通信（I Pュニキャスト）において、 中継回線 の先にある複数、例えば 1 0台のホスト端末に対して、一斉にデータを送信する場 合がある。 この場合、送信元のルータ（又はレイヤ 3スィッチ）は、全てのホス卜端 末に送信するデータの内容が同じでも、それぞれのホスト端末に対して個別に I P バケツトを送信する必要がある。 図 2 4に、 通常の I Pュニキャストを使用して、 複数のホス卜端末に一斉にデータ送信した場合の一例を示す。図 2 4に示すように、
I Pュニキャストを用いた場合は、 中継回線に同じデータが 1 0回流れる。
ところで、上記 I Pュニキャストに対して、 I Pマルチキャストと呼ばれる技術 がある。図 2 5は、 I Pマルチキャス卜を用いて、複数のホスト端末に対して一斉 にデータ送信を行った場合の一例を示す。図 2 5に示すように、 I Pマルチキャス 卜では、ホス卜端末に送信された I Pマルチキャス卜バケツ卜が、中継回線の先に あるルータで必要に応じてコピーされる。このルータによってコピーされた I Pマ ルチキャス卜バケツトは、 ルータの下流にあるそれぞれのホスト端末に着信する。 このように、 I Pマルチキャストを用いると、送信側のルータから受信側のルータ へホス卜 1台分のデータを送信することで、複数のホス卜端末に同時にデータを送 信することができる。即ち、上記例のように、 1 0台のホスト端末に同じデータを 一斉に送信する場合、中継回線には一台分のデータを格納した I Pマルチキャスト バケツトのみが流れる。
I Pマルチキャス卜の受信メカニズムは、主にルータとホス卜間における処理と、 ルータとルータ間における処理とに分けることができる。まず、ルータとホス卜間 における処理では、 I Pマルチキャス卜バケツ卜を送信する送信元ホスト端末がル —タに I Pマルチキャストバケツ卜を送信する過程と、受信側にある受信側ホスト 端末がルータから I Pマルチキャス卜バケツ卜を受信する過程とがある。図 2 6は、 ルータとホスト間における処理のうち、送信元ホス卜端末とルータ間の処理を説明 する図であり、図 2 7は、ルータとホスト端末間の処理のうち、ルータと受信側ホ ス卜端末間の処理を示す図である。図 2 6において、送信元ホスト端末がルータに
I Pマルチキャス卜バケツトを送信する際には、送信元ホスト端末は、宛先ァドレ スがマルチキャストグル一プアドレス（ Γ I Pマルチキャストァドレス」 と表記す ることもある）に設定された I Pパケット（「 I Pマルチキャス卜バケツ卜」と表記 することもある）をルータに送信する。 I Pアドレス「224. 0. 0. 0Jから 「239. 25δ. 255. 255」 はマルチキャストグループアドレスとして使用される。 図 2 6に示す例 では、 マルチキャストグループアドレスの一つである 「239. 255. 0. 0」 宛先アドレ スに設定された I Pマルチキャス卜バケツ卜が送信元ホスト端末から送信されて いる。 I Pマルチキャストバケツ卜は、送信元ホス卜端末が所属するサブネッ卜内 の全てのノードに送信される。従って、 この I Pマルチキャス卜バケツトは、最寄 りのルータに着信する。
一方、図 2 7に示すような受信側ホス卜端末がルータから I Pマルチキャストパ ケッ卜を受信するには、最寄りのルータに対して、特定のマルチキャストグル一プ ァドレス宛ての I Pマルチキャス卜バケツ卜の配信を要請する必要がある。図 2 7 に示す例では、受信側ホス卜端末は、送信側ホス卜から送信される「239. 255. 0. 0」 の I Pマルチキャス卜バケツトを受信するには、当該ァドレスの I Pマルチキャス 卜バケツ卜の配信を最寄りのルータに要請しなければならない。このとき、受信側 ホスト端末は、 ルータに対する I Pマルチキャストバケツ卜送信の要請に、 I GMP ( I nternet Group Management Protoco l ) という規格を用いる。 1 GMPは、受信側ホ スト端末が I Pマルチキャストパケットの受信をルータに要請する場合及び I P マルチキャストパケットの送信を中止させる場合に使用される。 なお、 I GMPは I ET F ( I nternet Engi neer i ng Task Force) という組織が、規格を標準化している。 こ のため、ルータとホスト間における処理は、細かなバージョンの違いはあるとして も、 全てのネットワークにおいて同一であるといえる。
—方、ルータ間における処理は、マルチキャス卜ルーティングプロトコルによリ 管理される。図 2 8は、 I Pマルチキャス卜における、ルータ間の処理の例を説明 する図である。図 2 8において、各ルータは、マルチキャストル一ティングプロ卜 コルを用いて、 I Pマルチキャス卜バケツ卜を転送するために必要な制御情報を交 換し、受信ホス卜の出現又は消滅にあわせて自身が保持しているマルチキャストル 一ティングテーブルを更新する。図 2 8に示す例では、受信側ホスト端末からの要 請（受信ホス卜の出現）に従って、 ルータ aのマルチキャストルーティングテーブル には、 「239. 255. 0. 0」 宛の I Pマルチキャス卜バケツ卜は右側に転送する、 とい う情報が格納される。また、ルータ b及びルータ cのマルチキャストル一ティング テーブルには、 「239. 255, 0. 0」 宛の I Pマルチキャストバケツ卜は右側に転送す る、 という情報が格納される。そして、ルータ dのマルチキャストルーティングテ 一ブルには、 「239. 255. 0. 0」 宛の I Pマルチキャストパケットは下に転送する、 という情報が格納される。
その後、各ルータは、マルチキャストルーティングプロ卜コルに従って上流のル —タから受信した I Pマルチキャス卜バケツ卜を下流のルータに転送する。図 2 8 を用いて説明すると、 送信元ホスト端末から送信された 「239. 255. 0. 0」 宛の I P マルチキャストバケツ卜は、 ルータ aに入る。 ルータ aは、 この I Pマルチキャス 卜バケツ卜に含まれた宛先ァドレスの値 ( I Pマルチキャス卜ァドレス） 「239. 2 55. 0. 0」を参照するとともに、マルチキャストルーティングテーブルを参照し、 I Pマルチキャストパケットをルーダ bに転送する。ルータ b , c , dもルータ aと 同様の動作を行い、マルチキャス 1ルーティングプロ卜コルに従って作成したマル チキャストルーティングテーブルに従って I Pマルチキャストバケツトを転送す る。 この結果、 送信元ホス卜端末から送出された I Pマルチキャス卜バケツトは、 ルータ a , b , c , dを経由して受信側ホスト端末に着信する。
その後、受信側ホス卜端末から最寄りのルータに対して I GMPを用いて I Pマルチ キャストバケツ卜の受信を停止するとの要請（マルチキャス卜グループからの離脱 要請） があった場合には、ルータ a , b , c， dはマルチキャストル一ティングプ 口トコルに従って、マルチキャストルーティングテーブルを更新し、受信側ホスト 端末に送信元ホスト端末からの I Pマルチキャストバケツ卜が着信し いように する。 このように、各ルータは、受信側ホス卜端末の出現又は消滅にあわせてマル チキャストルーティングテーブルを更新する。
このようなマルチキャスト機能に関する技術として、例えば特開 2002-77239号公 報に開示のマルチキャス卜ルーティングプロ卜コル終端方法が提案されている。こ のマルチキャス卜ルーティングプロトコル終端方法では、コネクションレス型通信 ネッ卜ワークにおいて、制御メッセージの収束時間及び制御メッセージの帯域消費 を小さく押さえることにより、安定して経済的にマルチキャスト通信を実現しょう とする。
また、マルチキャス卜の異種プロ卜コルを中継する機能に関する技術として、例え ば特開 2 0 0 0 - 1 3 4 2 0 8号公報に開示の LAN間中継装置が提案されている。 この提案によると、 端末やマルチキャス卜サーバ等のホス卜が接続される複数の L ANと、 LANを接続する複数の LAN間中継装置とを含む情報ネッ卜ワークにおいて、 個々の LAN間中継装置に、 GNIRP等の L2レベルのマルチキャストプロトコルと、 I GMP 等の L3レベルのマルチキャス卜プロ卜コルとの間で変換操作を行う変換処理部及 び L2マルチキャストテーブルを備える。この技術によれば、ある端末に L2レベルの マルチキャス卜プロ卜コルの処理機能が実装されていない場合でも、 L2レベルの G MRPをサポートしているかのように、 端末が属する I Pサブネッ卜内でのマルチキヤ ストバケツ卜の当該端末への選択的な配信を実現しょうとする。
ところで、実際のマルチキャストルーティングプロトコルにはいくつか種類があ る。 しかしながら、マルチキャストルーティングプロトコルの殆どは、接続の相互 接続性を保証していない。このため、異なるマルチキャストル一ティングプロトコ ルを用いるネッ卜ワーク間で情報の伝達が行うことができない、という問題がある。 図 2 9は、異なるマルチキャストル一ティングプロトコルを用いる場合の問齄点 を示す図である。ネッ卜ワーク Aは、マルチキャストルーティングプロ卜コル Aを 使用し、ネッ卜ワーク Bは、マルチキャス卜ルーティングプロトコル Aと相互接続 性のないマルチキャストルーティングプロトコル Bを使用しているものとする。こ の場合、ネッ卜ワーク Aとネッ卜ワーク Bとの間で I Pマルチキャストバケツ卜の ルートを生成するための制御情報をやりとりすることができない。このため、ネッ トワーク Aにある送信側ホスト端末から送信される I Pマルチキャストバケツ卜を ネッ卜ワーク Bにある受信側ホス卜端末で受信するために受信側ホス卜端末がマ ルチキャス卜グループに参加しても、両者間における I Pマルチキャス卜バケツ卜の 転送ルー卜は確立されない。従って、受信側ホス卜端末は、送信側ホス卜端末から の I Pマルチキャス卜バケツ卜を受信することができない。
このため、ェンドーェンドで I Pマルチキャス卜バケツ卜の配信を保証するには、 ネットワーク上の全てのルータで同じマルチキャストルーティングプロトコルを 採用するか、プロトコルが異なる個所に、プロトコルを相互変換する機能を持った 装置を接続する必要がある。
しかしながら、二つのネッ卜ワークが接続されている場合において、これらのネ ットワークで使用されるマルチキャストルーティングプロトコルが同一であった としても、使用されるマルチキャス卜グループアドレスがネッ卜ワーク間で異なる 場合には、 ネットワーク間で I Pマルチキャストバケツ卜を転送できない。
また、アルゴリズムの違いによりそもそもマルチキャストルーティングプロトコ ル間での相互変換が不可能である場合には、プロ卜コルを相互変換する機能を持つ た装置を適用することはできない。
以上のような問題は、 例えば、 管理者の異なるネットワーク (例えば異なる企業 のネッ卜ワーク）同士を接続し、 一方のネッ卜ワークにおける送信ホス卜からの I Pマルチキャス卜バケツトを他方のネッ卜ワークにおける受信ホス卜で受信しよ うとする場合に発生する。管理者の設計思想の相違により、夫々のネッ卜ワークに 適用されるマルチキャストルーティングプロ卜コルやマルチキャストグル一プア ドレスが相違することが多いからである。 発明の開示
本発明はこのような従来の技術の問題点に鑑みてなされたものである。 すなわち、本発明の課題は、あるマルチキャス卜グループ宛のマルチキャストパ ケットを他のマルチキャストグループ宛に配信することが可能となる、マルチキヤ ス卜グループ接続技術を提供することである。
本発明は上記課題を解決するために、 以下の手段を採用した。
すなわち、本発明は、マルチキャス卜グループ接続装置であり、第 1のマルチキ ヤス卜グループへの参加メンバーの出現を検出する検出手段と、前記検出手段によ つて参加メンバーの出現が検出されたときに、第 1のマルチキャス卜グループに対 応する第 2のマルチキャス卜グループに参加する参加手段と、前記第 2のマルチキ ヤストグループへの参加により送信されてくる、第 2のマルチキャス卜グループ宛 のマルチキャストバケツトを受信する受信手段と、前記受信手段によって受信され たマルチキャス卜バケツ卜の宛先ァドレスを前記第 1のマルチキャストグループ のァドレスに変換する変換手段と、前記変換手段によって宛先ァドレスが変換され たマルチキャストバケツ卜を前記第 1のマルチキャストグル一プに送出する送信 手段とを含むマルチキャス卜グループ接続装置である。
本発明は、ネットワーク内において、マルチキャストグル一プアドレスが異なる マルチキャストグループ間でマルチキャストバケツ卜を配信する際に、このマルチ キャストグル一プアドレスを、第 1のマルチキャス卜グループに適したァドレスに 変換して配信する。従って、本発明によれば、あるマルチキャストグループ宛のマ ルチキャストバケツトを他のマルチキャス卜グループ宛に配信することが可能と なる。
本発明は、前記参加メンバーの消滅を検出する第 2検出手段と、前記第 2検出手 段によって前記参加メンバーの消滅が検出された場合に、前記第 2のマルチキャス 卜グループから離脱する離脱手段とをさらに含んでもよい。
この場合には、第 1のマルチキャス卜グループ側の参加メンバーの離脱によって、 マルチキャストバケツ卜が第 1のマルチキャス卜グループ側で受信しなくなる。従 つて、第 2のマルチキャストグループ側はマルチキャス卜バケツ卜を送信しなくな リ、 マルチキャス卜バケツ卜の配信が停止する。
また、 本発明によるマルチキャス卜グループ接続装置における前記検出手段は、 前記参加メンバーの存在を探査するための探査バケツ卜を周期的に第 1のマルチ キャストグループ宛で送信する探査バケツ卜送信部と、前記メンバーが存在してい るときのみ探査バケツ卜を受信可能なプローブ手段から送信される探査バケツト 毎の応答バケツ卜を受信する応答バケツ卜受信部とを含み、前記応答バケツトの受 信により前記メンバーの存在を検出するようにしてもよい。
また、本発明によるマルチキャス卜グループ接続装置における前記第 2検出手段 は、前記応答バケツト受信部による応答バケツ卜の受信を監視し、所定期間応答パ ケッ卜の受信がない場合に、前記参加メンバーの消滅を検出するようにしてもよい また、本発明は、 マルチキャストネットワーク接続装置であり、第 1のネッ卜ヮ 一クと第 2のネッ卜ワークとに接続される本体部と、前記第 1のネッ卜ワークにお いて少なくとも 1台のルータ又はレイヤ 3スィッチを介して前記本体部と接続さ れるプローブ部とを備え、前記本体部は、第 1のネットワークにおけるマルチキヤ ストグル一プアドレスが宛先ァドレスとして設定され、このマルチキャス卜グルー プアドレス宛のバケツ卜の受信を望む受信ホス卜が出現したことを条件として前 記ルータ又はレイヤ 3スィッチを介して前記プローブ部に着信する探査バケツ卜 を周期的に第 1のネッ卜ワークへ送信する探査バケツ卜送信部と、前記プローブ部 から送信される探査バケツ卜の応答バケツトを前記ルータ又はレイヤ 3スィッチ を介して受信することにより受信ホス卜の出現を検出する検出部と、前記検出部に よって受信ホス卜の出現が検出された場合に、前記第 1のネッ卜ワークにおけるマ ルチキャストグル一プアドレスに対応する第 2のネッ卜ワークにおけるマルチキ ヤストグル一プアドレス宛のバケツ卜の受信を前記第 2のネッ卜ワークに要請す る要請部と、前記要請によって第 2のネッ卜ワークから送信されてくる前記第 2の ネットワークにおけるマルチキャストグル一プアドレス宛のバケツ卜を受信する 受信部と、前記受信部によって受信されたバケツ卜の宛先ァドレスを対応する第 1 のネッ卜ワークにおけるマルチキャストグル一プアドレスに変換するァドレス変 換部と、前記ァドレス変換部によって宛先ァドレスが変換されたバケツ卜を前記第 1のネッ卜ワークへ送信する送信部とを含み、前記プローブ部は、前記探査バケツ 卜を受信する毎に、 これに対応する応答バケツ卜を生成して送出する手段を含む。 本発明のマルチキャストネッ卜ワーク接続装置は、第 1と第 2のネッ卜ワーク間 において、マルチキャス卜バケツ卜の配信をする際に、本体部がこのマルチキャス トバケツ卜の宛先ァドレスを第 2のネッ卜ワーク宛から第 1のネットワーク宛に 変更する。従って、本発明のマルチキャストネッ卜ワーク接続装置によれば、第 1 と第 2のネットワーク間において、 マルチキャストバケツ卜の配信が可能となる。 また、本発明によるマルチキャス卜ネッ卜ワーク接続装置において、前記プロ一 ブ部は、前記受信ホス卜が存在している間のみ、探査バケツ卜を受信し、前記検出 部は、前記応答バケツ卜の受信を監視し、所定時間応答バケツ卜の受信がない場合 に前記受信ホス卜の消滅を検出し、前記要請部は、前記検出部によって受信ホスト の消滅が検出された場合に、前記第 2のネッ卜ワークにおけるマルチキャストグル 一プアドレス宛のバケツ卜の受信停止を前記第 2のネットワークに要請するよう にしてもよい。
また、本発明はマルチキャス卜バケツ卜の受信ホス卜の検出装置であり、ネッ卜 ワークに接続される本体部と、前記ネッ卜ワークにおいて少なくとも 1台のルータ 又はレイヤ 3スィッチを介して前記本体部と接続されるプローブ部とを備え、前記 本体部は、前記ネットワークにおけるマルチキャストグル一プアドレスが宛先ァド レスとして設定され、このマルチキャストグル一プアドレス宛のバケツ卜の受信を 望む受信ホス卜が出現したことを条件として前記ルータ又はレイヤ 3スィッチを 介して前記プローブ部に着信する探査バケツトを第 1のネッ卜ワークへ送信する 探査バケツ卜送信部と、前記プローブ部から送信される探査バケツ卜の応答バケツ トを前記ルータ又はレイヤ 3スィッチを介して受信することにより受信ホストの 出現を検出する検出部とを含み、前記プローブ部は、前記探査バケツトを受信した ときにこれに対応する応答バケツ卜を生成して送出する手段を含む。
本発明によるマルチキャス卜バケツ卜の受信ホス卜の検出装置は、本体部とプロ ーブ部によって、マルチキャストグル一プアドレス宛のマルチキャストバケツ卜の 受信を望む受信ホス卜を検出する。従って、本発明によるマルチキャス卜バケツト の受信ホス卜の検出装置によれば、受信ホス卜を正確に検出してマルチキャストパ ケッ卜の酉己信を適切に行うことができる。 また、 本発明によるマルチキャス卜バケツ卜の受信ホス卜の検出装置において、 前記プローブ部は、前記受信ホス卜が存在している間のみ、探査バケツ卜を受信し、 前記検出部は、前記応答バケツ卜の受信を監視し、所定時間応答バケツ卜の受信が ない場合に前記受信ホス卜の消滅を検出するようにしてもよい。 図面の簡単な説明
図 1は、 本発明の構成と適用例を示している。
図 2は、 本発明における探査バケツ卜の送信プロセスを示している。
図 3は、 本発明における探査バケツト着信通知プロセスを示している。
図 4は、本発明における送信元ホス卜端末からのバケツ卜受信プロセスを示して いる。
図 5は、 本発明におけるアドレス変換プロセスを示している。
図 6は、本 明において受信側ホス卜端末がデータを受信している状態を示して いる。
図 7は、 実施例の構成を示している。
図 8は、 実施例における本発明の機能ブロック図を示している。
図 9は、 実施例におけるエンコーダの I P設定を示している。
図 1 0は、 実施例におけるアドレス変換方針を示している。
図 1 1は、 実施例における変換テーブルを示している。
図 1 2は、 実施例における探査バケツ卜の構成を示している。
図 1 3は、実施例において、デコーダが映像データの受信を要求する前の状態を 示している。
図 1 4は、実施例において、デコーダが映像データの受信を要求した直後の状態 を示している。
図 1 5は、実施例において、プローブ部が探査バケツ卜を受信した状態を示して いる。
図 1 6は、 実施例における応答バケツ卜の構成を示している。
図 1 7は、実施例において、本体部が応答バケツトを受信した状態を示している。 図 1 8は、 実施例における応答パケット受信直後の変換テーブルを示している。 図 1 9は、実施例において、本体部が映像データバケツトを受信した状態を示し ている。
図 2 0は、実施例において、デコーダへの映像データ受信のための全プロセスが 完了した状態を示している。
図 2 1は、実施例において、デコーダが映像データの受信を停止した状態を示し ている。
図 2 2は、実施例において、 B央像データの転送が完全に停止した状態を示してい る。
図 2 3は、 実施例のフローチャートを示している。
図 2 4は、 I Pュニキャス卜通信の例を示している。
図 2 5は、 I Pマルチキャスト通信の例を示している。
図 2 6は、 I Pマルチキャス卜における送信元ホスト端末とルータ間の処理を示 している。
図 2 7は、 I Pマルチキャス卜におけるルータと受信側ホスト端末間の処理を示 している。
図 2 8は、 I Pマルチキャス卜におけるルータとルータ間の処理を示している。 図 2 9は、マルチキャス卜ルーティングプロ卜コルが異なる場合の問題点を示し ている。 発明を実施するための最良の形態
以下、 図面を参照して、本発明の好適な実施の形態を説明する。なお、以下の本 実施の形態では、管理者の異なるネッ卜ワーク A及びネットワーク Bにおいて、ネ ットワーク Aからネットワーク Bに I Pマルチキャス卜バケツトを送信する際に、 マルチキャストネットワーク接続装置によるネッ卜ワークルーティングプロトコ ルの解決手順を説明する。
〔原理〕
図 1から図 6に基づいて、本発明のマルチキャストネッ卜ワーク接続装置におけ る処理の概略を説明する。
図 1は、本発明の構成を示す概略図である。図 1に示すように、本発明のマルチ キャストネットワーク接続装置は、例えば、本体部 1 0 0と、 プローブ部 2 0 0と から構成される。
図 1に示すように、本体部 1 0 0は管理者 Aの管理するネッ卜ワーク Aと管理者 Bの管理するネットワーク Bとの間に設置される。この本体部 1 0 0は、ネットヮ ーク A及びネッ卜ワーク Bの双方に接続される。具体的には、本体部 1 0 0は、ネ ットワーク Aのサブネッ卜ワークを介してネッ卜ワーク A内のルータに接続され ている。また、本体部 1 0 0は、ネットワーク Bのサブネットワークを介してネッ 卜ワーク B内のルータに接続されている。プローブ部 2 0 0は、 I Pマルチキャス 卜バケツ卜の受信側であるネットワーク Bに設置される。このプローブ部 2 0 0は、 ネッ卜ワーク Bにおいて、本体部 1 0 0とルータ 1台を隔てたサブネッ卜に接続さ れている。
図 2は、本発明のマルチキャストネッ卜ワーク接続装置の本体部 1 0 0が、 I P マルチキャス卜バケツトを受信する受信側ホスト端末を探すために、探査バケツ卜 を送信する様子を示している。
図 2に示すように、本体部 1 0 0は、 I Pマルチキャストパケットの受信を希望 する受信側ホスト端末を探すために、ネッ卜ワーク B側に対して、定常的に探査パ ケットを送信する。例えば、受信側であるネットワーク Bのマルチキャス卜グルー プアドレスを "Gb" とすると、本体部 1 0 0は、ネッ卜ワーク B側に "Gb"宛の探 査バケツトを送信する。ネッ卜ワーク B内に、マルチキャストグル一プアドレス" G b" の受信を 望している受信側ホスト端末が存在しない場合、 この探査パケット は最寄りのルータ（ルータ R 1 )によって破棄される。
図 3は、 ネッ卜ワーク Bに受信側ホスト端末が現れたときの様子を示している。 図 3において、本体部 1 0 0が探査バケツトを送信している際に、ネットワーク B 内にマルチキャス卜グループアドレス "Gb"を受信する受信側ホス卜端末が現れた とする。 この場合、探査バケツ卜は、ネッ卜ワーク Bで使用するマルチキャストル —ティングプロ卜コルに従し、、本体部 1 0 0の最寄りにあるルータ R 1を経由して、 その下流のサブネッ卜ワークに転送される状態となる。これによつて、探査バケツ 卜は、下流側の各ルータ R 2、 R 3に着信するとともに、 プローブ部 2 0 0にも着 信する。探査バケツ卜が自身に着信したことを認識したプローブ部 2 0 0は、その 旨を本体部 1 0 0に通知する。これにより、本体部 1 0 0は、ネットワーク Bでど のようなマルチキャストルーティングプロトコルが使用されていても、ネッ卜ヮ一 ク B内に "Gb" の受信側ホスト端末 3 0 0が現れたことを認識できる。
図 4は、受信側ホスト端末 3 0 0が I Pマルチキャス卜バケツ卜の要求を、本体 部 1 0 0を介してネットワーク Aに行う様子を示している。図 4に示すように、 "G b" の受信側ホスト端末が現れたことを認識した本体部 1 0 0は、 ネッ卜ワーク A 側に、マルチキャストグル一プアドレス "Ga"宛の I Pマルチキャス卜バケツトを 本体部 1 0 0に送信するように要請する。すなわち、本体部 1 0 0は、受信ホスト として、 ネットワーク A側の所定のマルチキャストグループ (受信ホス卜の参加が 検出されたネットワーク B側のマルチキャス卜グループに対応するマルチキャス 卜グループ)に参加する。
このときの I Pマルチキャストバケツ卜の要請には、 I GMPと呼ばれるプロトコル を使用する。 このとき、ネットワーク A内では、 I Pァドレス "Sa"を持つ送信元 ホス卜端末 4 0 0力 マルチキャストグル一プアドレス "Ga"宛てに I Pマルチキ ヤス卜バケツ卜を送信していたとする。この場合、送信元ホスト端末 4 0 0から送 信される I Pマルチキャストバケツトは、送信元ァドレス情報 "Sa"及び宛先ァド レス情報 "Ga"を持ち、ネットワーク A内で使用されているマルチキャス卜ルーテ イングプロ卜コルに従って本体部 1 0 0に着信する。
図 5は、本発明の本体部 1 0 0による、 I pマルチキャス卜バケツ卜の送信元ァ ドレス情報、及び宛先アドレス情報の変換を示す。図 5に示すように、 このマルチ キャス卜グループアドレス "Ga"宛の I Pマルチキャス卜バケツトを受信した本体 部 1 0 0は、その I Pマルチキャストパケットの宛先アドレスを" Gb"に変更する。 また、送信元ァドレスを "Sb"等のネッ卜ワーク B側に対応したァドレスに変更し た後、本体部 1 0 0は、当該 I Pマルチキャストバケツ卜をネットワーク B側に中 継する。 図 6は、送信元ホスト端末 4 0 0から受信側ホス卜端末へ I Pマルチキャストパ ケッ卜の配信が行われる様子を示す。図 6に示すように、ネットワーク B側に中継 された I Pマルチキャス卜バケツ卜の宛先ァドレス情報は、本体部 1 0 0によって ネットワーク Bで採用されているマルチキャストグル一プアドレスに変更されて いる。従って、宛先ァドレス "Gb" を持つ I Pマルチキャストバケツ卜は、 ネット ワーク Bにおけるマルチキャス卜ルーティングプロ卜コルに倣って、宛先ァドレス 情報 "Gb"の I Pマルチキャス卜バケツ卜の受信を希望している受信側ホス卜端末 3 0 0に着信する。
以上の手順により、ネッ卜ワーク Aで送信された I Pマルチキャストバケツ卜が、 ネットワーク B内のホス卜で受信可能となる。
図 1〜図 6を用いた説明において、ネッ卜ワーク A及び Bでそれぞれ採用されて いるマルチキャストルーティングプロ卜コルの種別は問題にならない。さらに、パ ケッ卜のアドレスも本体部 1 0 0で変換されているので、マルチキャストグループ ァドレスの相違による問題も発生しない。従って、使用するマルチキャストグル一 プアドレスやマルチキャストルーティングプロ卜コルが一致しないネッ卜ワーク 間において、 マルチキャストバケツ卜を配信すること（ネッ卜ワーク Aからネット ワーク Bへのマルチキャス卜バケツ卜の配信）が可能となる。
なお、前述のネッ卜ワーク Bにおいて、受信側ホスト端末 3 0 0が I Pマルチキ ヤストバケツ卜 "Gb"の受信を中止する場合の手順について説明する。受信側ホス ト端末 3 0 0がネッ卜ワーク Bから離脱すると、ネッ卜ワーク Aから Bへの I Pマ ルチキャストバケツ卜の転送が停止される。
まず、受信側ホス卜端末 3 0 0が、 I GMPの手順に従ってマルチキャス卜グループ からの離脱をルータ R 3に要請する。すると、 ルータ R 3、 R 2、 R 1は、 マルチ キャストルーティングプロトコルに従って制御情報の交換を行い、マルチキャスト ルーティングテーブルを更新し、 "Gb"宛ての I Pマルチキャス卜バケツトを転送 しなくなる。
ルータ R 1が "Gb"宛ての I Pマルチキャス卜バケツ卜の転送を中止すると、 プ ローブ部 2 0 0は、 "Gb"宛の探査バケツ卜を受信できなくなる。 "Gb"宛の探査 バケツ卜が着信しないため、プローブ部 2 0 0は、当該探査バケツ卜の着信を本体 部 1 0 0に通知しなくなる。その結果、本体部 1 0 0は、ネットワーク Bに宛先ァ ドレス情報 "Gb" の受信側ホス卜端末 3 0 0がいないことを認識する。
すると、本体部 1 0 0は、ネッ卜ワーク A側の送信元ホス卜端末 4 0 0に対して
"Ga" 宛ての I Pマルチキャストバケツトがもう必要ないことを IGMPで通知する。 これによつて、本体部 1 0 0はネッ卜ワーク A側のマルチキャストグループから離 脱し、受信側ホス卜端末 3 0 0への I Pマルチキャストバケツ卜の送信が即座に停 止される。従って、無駄な I Pマルチキャストバケツ卜がネッ卜ワーク Bへ転送さ れるのを防止することができる。 . 〔実施例〕
次に、本発明のマルチキャストネッ卜ワーク接続装置による、マルチキャストル 一ティングプロトコルが異なるネッ卜ワーク接続処理の手順について説明する。 図 7は、実施例に係る、マルチキャス卜ネットワーク接続装置を用いたネットヮ ークシステムの全体構成を示す。図 7において、本発明のマルチキャストネットヮ —ク接続装置は、 設計思想の異なるネットワーク Aとネットワーク Bとを接続し、 ネットワーク Aからネットワーク Bへのマルチキャストバケツ卜の配信を可能に する。
ネッ卜ワーク Aは、次の構成を持つ。即ち、ルータ■ネッ卜ワークにルータ R 4 及び R 5が夫々接続されている。 ルータ R 5は、 サブネットワーク (192. 168. 1. 0/ 24)を介してエンコーダ（送信元ホス卜端末） 1 ( 4 0 0 )及びエンコーダ（送信元ホ スト端末） 2 ( 5 0 0 )に接続されている。 また、 ルータ R 4は、 サブネットワーク (192. 168. 2. 0/24)に接続されている。
ネッ卜ワーク Bは、次の構成を持つ。即ち、ルータ 'ネッ卜ワークにルータ R 2 及び R 3が夫々接続されている。 ルータ R 3は、 サブネットワーク (192. 16. 3. 0/2 4)を介してデコーダ（受信側ホス卜端末） 3 0 0に接続されている。ルータ R 2は、 サブネッ卜ワーク（172. 16. 2. 0/24)を介してルータ R 1に接続されている。 ルータ R 1は、 さらに、 サブネットワーク (172. 16. 1. 0/24)に接続されている。
マルチキャストグループ接続装置は、本体部 1 0 0と、プローブ部 2 0 0とから なる。 本体部 1 00は、 ネッ卜ワーク Aのサブネットワーク（192.168.1.0/24)と、 ネッ卜ワーク Bのサブネットワーク (172.16· 1.0/24)とに夫々接続されることで、 ネットワーク Aとネッ卜ワーク Bとを接続している。プローブ部 200は、ネッ卜 ワーク Bのサブネッ卜ワーク (172.16.2.0/24)に接続されており、 本体部 1 00と ルータ R 1を介して接続されている。
上述したネットワーク A及びネッ卜ワーク Bに夫々施された設定条件について 説明する。ネッ卜ワーク Aは、次の方針 (設計思想）に基づいて設計'運営されてい る。
(A)ュニキャストァドレスとして、プライべ一卜クラス0(192.168.0.0~192.168. 255.255)を使用する。
(B)マルチキャストグル一プアドレスとして、 Local Scope (239.255.0.0〜239.25 5.255.255)を使用する。
(C)マルチキャストルーティングプロ卜コルとして、 PIM - SM(RFG2362)を使用する。
(D)プライベートクラス G及び Local Scope以外のァドレスを、ユーザが使用するこ とを禁止する。
ネッ卜ワーク Aにおけるエンコーダ 1 (400),エンコーダ 2 (500)は、 本発 明における送信ホストに相当する。 各エンコーダ 400， 500には、 図 9に示す 表に従った設定が施されている。即ち、エンコーダ 400に対しては、 I Pァドレ ス（192.168.1.1)が設定されており、 エンコーダ 400は、 B央像配信に使用する I Pマルチキャストバケツ卜のマルチキャストグル一プアドレスとして" 239.255.0. 1" を使用し、 この I Pマルチキャストパケットに対する保存時間を表す TTL (Tim e To Live) の値として "1 5" が設定される。 一方、 エンコーダ 500に対して は、 I Pアドレス（192.168.1.2)が設定されており、 エンコーダ 500は、 映像配 信に使用する I Pマルチキャストバケツ卜のマルチキャストグル一プアドレスと して "239.255.0.2"を使用し、 この I Pマルチキャス卜バケツ卜に対する TTLの値 として "1 5" が設定される。
一方、ネットワーク Bは、次の方針 (設計思想）に基づいて設計 '運営されている。
(a)ュニキャストァドレスとして、 プライべ一トクラス Β(172.16.0.0~172.31.2 55.255)を使用する。
(b)マルチキャストグループアドレスとして、 Organization Local Scope (239.19 2.0.0〜239.195.255.255)を使用する。
(c)マルチキャストルーティングプロトコルとして、 DVMRP(RFC1075)を使用する。
(d)プライベートクラス B及び Organization Local Scope以外のアドレスを、ュ一 ザが使用することが禁止される。
ネッ卜ワーク Bにおけるデコーダ 300は、本発明における受信ホス卜に相当す る。
上記条件において、ネットワーク Bに接続されたデコーダ 300は、ネットヮー ク Aに接続されたエンコーダ 400, 500から送信される映像データを受信する c しかしながら、エンコーダ 400, 500が使用するアドレスは、上記のようにネ ットワーク Bにおいて使用が禁止されている。
このため、 ネットワーク Aからネットワーク Bに映像データ（を含む I Pマルチ キャストパケット； 「映像データパケット」 と表記することもある）を転送する際 に、本体部 1 00は、図 10に示されるような映像データバケツ卜のアドレス変換 を行う。図 1 0は、本体部 100に対して設定されるアドレス変換の内容を示す表 である。
即ち、エンコーダ 400から送信される映像データバケツトは、本体部 1 00に おいて、 その送信元 I Pアドレスが "192.168.1.1" から "172.16.1.1" に変換さ れ、 且つ宛先アドレス（マルチキャストグループアドレス）が "239.255.0.1" から "239.192.0.1 "に変換され、その I Pマルチキャス卜バケツ卜の TTLの値が" 1 5" に再設定される。
一方、エンコーダ 500から送信される映像データバケツトは、本体部 1 00に おいて、 その送信元 I Pアドレスが "192.168.1.2" から "172.16.1.2" に変換さ れ、 且つ宛先アドレス（マルチキャストグループアドレス）が "239.255.0.2" から "239.192.0.2"に変換され、その I Pマルチキャス卜バケツ卜の TTLの値が" 1 5" に再設定される。
〈システム構成〉 次に、本実施例に係るマルチキャストネットワーク接続装置の本体部 1 0 0及び プローブ部 2 0 0のシステム構成について説明する。図 8は、本実施例における本 体部 1 0 0及びプローブ部 2 0 0の機能プロック図である。
図 8において、本体部 1 0 0は、変換テーブル管理部 1と、探査バケツト生成部 2と、 ネットワーク Bへの I /O部 3と、 バケツト分類部 8と、 ARP (Address Reso l u t i on Protoco l )処理部 9と、応答バケツト処理部 1 0と、 I GMP処理部 1 1と、ネッ トワーク Aへの I/O部 1 2とを有する。
変換テーブル管理部 1は、ネッ卜ワーク Aからネッ卜ワーク Bへ転送される I P マルチキャストパケットのヘッダ情報 (送信元アドレス， 宛先アドレス， TTL)を変 換するための変換情報と、ネッ卜ワーク B側のマルチキャストグル一プの活性情報 とを管理するための変換テーブル 1 aを管理する。
図 1 1は、変換テーブル 1 aの例を示す図である。変換テーブル 1 aは、変換対 象の送信元ァドレス及び宛先ァドレスの組み合わせを示す変換対象情報と、変換後 の送信元ァドレス及び宛先ァドレスの組み合わせを示す変換値情報と、 変換後の T TLの値を示す丌 L情報と、 対応するマルチキャス卜グループの活性を示す活性フラ グと、 探査バケツ卜の応答バケツ卜の受信を許容するタイマ値とをフィールド (項 目）として持つ 1以上のェン卜リを保持する。 ェントリは I Pマルチキャストパケ ッ卜の送信側のマルチキャス卜グループ毎に用意される。
ここに、変換対象情報は、ネッ卜ワーク A (送信側ネッ卜ワーク）からネットヮ一 ク B (受信側ネットワーク）へ転送される対象の I Pマルチキャストバケツ卜のへ ッダに設定されている送信元 I Pアドレス及び宛先 I Pアドレスを示す。ここでの 送信元 I Pァドレスは、 I Pマルチキャス卜バケツ卜の送信ホス卜の I Pァドレス であり、宛先ァドレスは、送信側ネットワーク（ネットワーク A)におけるマルチキ ヤストグル一プアドレスである。
また、変換値情報は、ァドレス変換によって I Pマルチキャストバケツ卜のへッ ダに設定される送信元 I Pアドレス及び宛先 I Pアドレスを示す。ここでの宛先 I Pアドレスは、 I Pマルチキャストバケツ卜の受信側ネッ卜ワーク（ネッ卜ワーク B)におけるマルチキャストグループアドレスである。 一方、 変換値情報に含まれ る送信元 I Pァドレスは、 ダミーの送信元 I Pァドレスであり（本体部 1 0 0の I Pァドレス（この例では、 172. 16. 1. 10)でない）、ネットワーク Bにおけるノードに て判別可能な I Pァドレスが割り当てられる。例えば、ネットワーク Bにおいて認 識可能な I Pアドレスとして、本体部 1 0 0が収容されているサブネットワークに おいて未使用のホストァドレスが割り当てられる。本実施例では、ルータ R 1から 本体部 1 0 0が応答バケツトを受け取るために、 両者を収容するサブネット 172. 1 6. 1. 0/24のホストァドレスが変換値の送信元ァドレスとして使用されている。
TTL値は、ァドレス変換後の I Pマルチキャストバケツ卜に再設定される TTL値を 指す。
活性フラグは、変換値情報に含まれたマルチキャス卜グループの活性、すなわち I Pマルチキャス卜バケツ卜の受信側ネッ卜ワークにおいて当該マルチキャスト グループに参加している受信ホス卜があるか否かを示すフラグであリ、参加してい る受信ホス卜が 1つでもある場合には ONとなり、参加している受信ホス卜がない場 合には OFFとなる。
タイマ値は、探査バケツ卜の応答バケツ卜の受信許容時間を示す。活性フラグが オフのときには、 タイマ値は零になり、オンの時には、応答バケツ卜の受信毎に初 期値 (数秒〜数十秒)が設定され、 時間の経過に従って減少する。 タイマ値は、 同じ ェン卜リ中の活性フラグの 0NZ0FF制御のために使用される。
図 1 1に示す変換テーブル 1 aは、図 1 0に示される設定内容に従った内容を保 持している。即ち、変換テーブル 1 aは、 図 1 0に示した設定内容に従って、 ネッ 卜ワーク Aにおけるエンコーダ 4 0 0及び 5 0 0に夫々対応する二つのエントリ 1及び 2が用意されている。
変換テーブル管理部 1は、変換テーブル 1 aの各エントリに対して、タイマ値の セット及びリセット、及びこれに基づく活性フラグのオン オフ制御を行う。変換 テーブル管理部 1は、タイマ値のセッ卜及びリセッ卜を、応答バケツト処理部 1 0 から受け取る応答通知に従って行う。
図 8に戻って、探査バケツ卜生成部 2は、変換テーブル管理部 1で管理されてい る変換テーブル 1 aを参照し、そのエントリ内容に従って、受信側のマルチキャス 卜グループ毎の探査パケット（図 1 2参照）を生成し、 I/O部 3に渡す。
I/O部 3は、 ネットワーク Bとのインターフェイス機能を司り、 探査パケット生 成部 2から受け取る探査バケツ卜、 ARP処理部 9から受け取る ARP応答バケツト、及 びヘッダ変換部 1 3から受け取る転送対象の I pマルチキャストバケツト（対象パ ケット）をネットワーク Bへ送出する。一方、 I/O部 3は、ネットワーク Bから探査 バケツ卜の応答バケツト等の様々なバケツトを受信し、 バケツト分類部 8に渡す。 バケツ卜分類部 8は、 I/O部 3及び I/O部 1 2にて受信された全てのバケツトを受 け取る。バケツ卜分類部 8は、受け取ったバケツ卜のヘッダ及び 又はペイロード (情報フィールド）を参照し、 パケットの種別を判別する。 ここに、 I/O部 3からの バケツ卜は、 探査バケツ卜の応答バケツ卜， ARP要求バケツ卜， その他のバケツ卜 からなリ、 I/O部 1 2からのパケットは、 I Pマルチキャストパケット， I GMPパケ ッ卜， その他のバケツ卜からなる。バケツ卜分類部 8は、バケツ卜の判別結果が応 答バケツトであればそれを応答バケツ卜処理部 1 0に渡し、 ARP要求バケツトであ ればそれを ARP処理部 9に渡し、 IGNIPパケットであればそれを IGMP処理部 1 1に渡 し、 I Pマルチキャストバケツト又はその他のバケツ卜であればそれをヘッダ変換 部 1 3に渡す。なお、バケツト分類部 8は、その他のバケツ卜を無視又は廃棄する ようにしても良い。
ARP要求部 9は、 パケット分類部 8からの ARP要求パケットを解析し、 この ARP要 求バケツ卜に応答するか否か (ARP要求が自分宛か否か）を変換テーブル 1 aを参照 して判定し、 応答する必要がある場合には、 本体部 1 0 0の MAG (Med i a Access Co ntro l)アドレス（装置ァドレス）を含む ARP応答バケツトを生成し、 I /O部 3に与える。
ARP要求部 9は、 ARP要求バケツ卜に含まれている探索対象の I Pアドレスと、変換 テーブル 1 aにおける何れかのェン卜リの変換値情報中の送信元 I Pアドレスと が同じであれば、 その ARP要求バケツ卜が自分宛であると判定する。
応答バケツ卜処理部 1 0は、バケツ卜分類部 8からの応答バケツ卜を解析し、応 答バケツ卜に含まれている、受信ホス卜が参加しているネッ卜ワーク Bのマルチキ ヤストグループを特定するための情報を含む応答通知を変換テーブル管理部 1に 与える。応答通知は、変換テーブル管理部 1が対応するェントリの活性フラグ及び タイマを制御するために使用される。
I GMP処理部 1 1は、変換テーブル管理部 1からで管理されている変換テーブル 1 aの各エントリの活性フラグの値に従って、活性フラグがオンになっているェント リがあれば、そのエントリから特定されるネットワーク Aのマルチキャストグル一 プに対して本体部 1 0 0が受信ホストとして参加又は離脱するための I GMPバケツ トを生成し、 I/O部 1 2に与える。 また、 I GMP処理部 1 1は、 ネットワーク Aにお けるマルチキャストグループに対して本体部 1 0 0が受信ホストとして参加状態 を継続するか否かを問い合わせるための I GNIPパケットを受け取る。 このとき、 I GM P処理部 1 1は、 対応する変換テーブル 1 aのエントリ中の活性フラグがオンであ れぱ、当該マルチキャス卜グループへの参加を継続する旨の I GNIPバケツトを生成し、 I/O部 1 2へ与える。
I/O部 1 2は、 ネットワーク Aとのインターフェイス機能を司り、 I GMP処理部 1 1からの I GMPバケツトをネッ卜ワーク Aへ送出する。 一方、 I/O部 1 2は、 ネット ワーク Aから I GMPバケツトゃ I Pマルチキャストバケツト等を受信し、受信した全 てのバケツ卜をバケツ卜分類部 8に渡す。
このように、本体部 1 0 0は、ネットワーク Aからネッ卜ワーク Bへ転送すべき I Pマルチキャストバケツ卜を受信し、そのヘッダ情報を変換してネッ卜ワーク B に送出する機能と、ネットワーク Aにおける所定のマルチキャス卜グループに対応 するネッ卜ワーク Bにおけるマルチキャス卜グループに対する受信ホス卜の参加 離脱を検出するための機能と、ネッ卜ワーク Bにおけるマルチキャストグループ に対する受信ホス卜の参加 離脱に応じて、対応するネットワーク Aのマルチキヤ ス卜グループに受信ホストとして参加 離脱する機能とを備えてなる。
図 8において、 プローブ部 2 0 0は、 I/O部 4と、 パケット分類部 5と、 探查パ ケット処理部 6と、 応答バケツ卜生成部 7とを備えている。
I/O部 4は、 ネットワーク Bに接続されてインターフヱイス機能を司り、 ネット ワーク Bから受信する全てのパケットをパケット分類部 5に渡す。 一方、 I /O部 4 は、応答バケツ卜生成部 7から受け取る応答バケツ卜をネットワーク Bへ送出する c パケット分類部 5は、 I/O部 4にて受信された全てのパケットを受け取る。 パケ ット分類部 5は、 受け取ったバケツ卜のヘッダ及ぴノ又はペイロード (情報フィー ルド）を参照し、バケツ卜の種別を判別する。即ち、バケツ卜分類部 5は、 I/O部 4 からのバケツ卜が探査バケツ卜であるか否かを判断する。バケツ卜分類部 5は、パ ケッ卜の判別結果が探査バケツトであればそれを探査バケツト処理部 6に渡す。な お、バケツト分類部 5は、その他のバケツ卜を無視又は廃棄するようにしても良し、。 探査バケツ卜処理部 6は、バケツト分類部 5から受け取った探査バケツ卜のペイ ロードから情報を取り出す。そして、探査バケツ卜処理部 6は、探査バケツ卜から 取り出した情報を応答パケット生成部 7に通知する。
応答バケツト生成部 7は、探査バケツ卜処理部 6からの情報を応答バケツ卜送信 指示として、 この情報をもとに応答バケツ卜を生成する。そして、応答バケツト生 成部 7は、 生成した応答バケツ卜を I/O部 4に送信する。
なお、 上述の変換テーブル管理部 1 , 探査パケット生成部 2 , I/O部 3， 及び応 答バケツ卜処理部 1 0は、本発明のマルチキャストグループ接続装置における検出 手段に相当する上述の IGMP処理部 1 1 , I/O部 1 2は、 本発明によるマルチキャス トグループ接続装置における参加手段に相当する。 上述の I/O部 1 2は、 本発明に よるマルチキャストグループ接続装置における受信手段に相当する。上述のヘッダ 変換部 1 3は、本発明によるマルチキャス卜グループ接続装置における変換手段に 相当する。 上述の I/O部 3は、 本発明によるマルチキャストグループ接続装置にお ける送信手段に相当する。上述の第 2検出手段は、本発明によるマルチキャス卜グ ループ接続装置における変換テーブル管理部 1に相当する。上述の探査バケツト生 成部 2 , I/O部 3は、 本発明によるマルチキャストグループ接続装置における探査 バケツ卜送信部に相当する。上述のプローブ部 2 0 0は、本発明によるマルチキヤ ストグループ接続装置におけるプローブ手段に相当する。 上述の I/O部 3は、 本発 明によるマルチキャストグループ接続装置における応答バケツト受信部に相当す る。
また、上述のネッ卜ワーク A , 及びネットワーク Bは、本発明のマルチキャス卜 ネットワーク接続装置における第 2のネッ卜ワーク，及び第 1のネッ卜ワークに相 当する。上述の探査バケツト生成部 2は、本発明のマルチキャストネットワーク接 続装置におけるレイヤ 3スィッチに相当する。 上述の I/O部 3は、 本発明のマルチ キャストネッ卜ワーク接続装置における探査バケツト送信部に相当する。 上述の I GMP処理部 1 1 ,及び I/O部 1 2は、本発明のマルチキャストネットワーク接続装置 における要請部に相当する。 上述の I/O部 1 2は、 本発明のマルチキャストネット ワーク接続装置における受信部に相当する。上述のヘッダ変換部 1 3は、本発明の マルチキャストネッ卜ワーク接続装置におけるァドレス変換部に相当する。上述の I/O部 3は、 本発明のマルチキャストネッ卜ワーク接続装置における送信部に相当 する。 上述の I/O部 4， パケット分類部 5， 探査パケット処理部&， 及び応答パケ ット生成部 7は、本発明のマルチキャストネッ卜ワーク接続装置における応答パケ ッ卜を生成して送出する手段に相当する。
纖〉
図 8に示すように、 本実施例のマルチキャストネットワーク接続装置において、 本体部 1 0 0の I/O部 1 2をネットワーク Aに接続し、 I /O部 3をネッ卜ワーク Bに 接続する。 また、 プローブ部 2 0 0の I/O部 4は、 本体部 1 0 0からルータ 1台を 隔てたサブネット（172. 16. 2. 0/24)に接続される。
〈設定〉
まず、本体部 1 0 0の変換テーブル管理部 1が保持する変換テーブルに変換ポリ シーを設定する。図 1 1は、エンコーダ 4 0 0及びエンコーダ 5 0 0から送信され た I Pマルチキャストバケツトである映像データバケツトのァドレス変換テープ ル 1 aを示す。なお、以下の記載において、 I Pマルチキャストバケツトを表す際 に、 " （送信元アドレス， 宛先マルチキャストグループアドレス） " という表記 を用いることもある。
図 1 1において、変換テーブル 1 aのエントリ 1は、送信元ァドレス（192. 168. 1. 1 ) で、宛先ァドレスが（239. 255. 0. 1 ) の I Pマルチキャス卜バケツ卜が、送信 元アドレスが (172. 16. 1. 1 ) で、 宛先ァドレスが (239. 192. 0. 1 ) の I Pマルチキ ヤストバケツ卜に変換されることを意味する。即ち、エンコーダ 4 0 0から送信さ れる映像データバケツトのァドレス情報を、ネットワーク Bで参照可能なァドレス 情報に変更している。 また、 この変換テーブル 1 aでは、 TTLの値が 1 5にセッ卜 されることも示している。 さらに、変換テーブル 1 aにおいて、活性フラグ及びタ イマは、 初期状態ではそれぞれ "OFF" 、 " 0 " となる。
〈動作原理〉
次に、本実施例による、ネットワーク B側に設置されたデコーダ 3 0 0において、 I Pマルチキャス卜バケツ卜で送信された映像の再生が可能となるまでの処理の 手順を説明する。
本実施例における動作は、マルチキャストネッ卜ワーク接続装置の本体部 1 0 0 の探査バケツ卜生成部 2 (図 8 )が探査バケツ卜を生成することから始まる。探査パ ケッ卜の生成は、 変換テーブル管理部 1に記憶される変換テーブル 1 a (図 1 1 ) を参照して行われる。探査バケツ卜は、変換テーブル 1 aのエントリ毎に生成され る。 即ち、 本実施例では、 探査バケツト生成部 2は、 エントリ 1 (エンコーダ 4 0 0用）及びェントリ 2 (エンコーダ 5 0 0用）に夫々対応する 2種類の探査バケツ卜 を生成する。
図 1 2は、探査バケツ卜の例を示す図であり、エントリ 1に対応する探査バケツ 卜が示されている。探査バケツ卜生成部 2は、探査バケツ卜の送信元 I Pァドレス として、変換テーブル 1 aにおけるェン卜リ 1の変換値の送信元ァドレス情報を I Pヘッダにセッ卜する。
同様に、探査バケツト生成部 2は、探査バケツ卜の宛先ァドレスとして、ェン卜 リ 1における変換値の宛先ァドレス情報を I Pヘッダにセッ卜する。すなわち、探 査バケツ卜には、受信ホス卜の参加を探査するマルチキャストグル一プアドレスが 宛先アドレスとしてセットされる。
また、 探査バケツト生成部 2は、 エントリ 1の TTLの値（ " 1 5 " )を使用し、 探 査バケツ卜の I Pヘッダに TTL値をセッ卜する。
また、探査バケツ卜が使用する上位プロトコルは特に定められていないが、本実 施例では UDPのポ一ト 5 0 0 1番が使用され、このポ一卜番号力《UDPヘッダにセッ卜 される。
さらに、探査バケツトはそのペイロードとして、この I Pマルチキャス卜バケツ 卜が探査バケツトであることを示すビットパターン (識別子）、エントリ番号（= 1 )、 及び変換値情報 (送信元ァドレスと宛先ァドレス）をセッ卜する。
なお、探査バケツト生成部 2は、エントリ 2についても、上述したエントリ 1と 同様の手法で探査バケツ卜を生成する。
探査バケツ卜生成部 2は、生成した探査バケツトを定期的に I /O部 3へ送信する。 このときの探査バケツ卜の送信間隔は、使用するネッ卜ワーク毎に適宜調整される が、 この実施例では 100msとする。 即ち、 エントリ 1及びェン卜リ 2の探査バケツ トは、 1秒あたり 1 0バケツ卜ずつ合計 2 0バケツ卜が I /O部 3へ送信される。 図 1 3は、 I Pマルチキャス卜バケツ卜である映像データバケツ卜の配信を希望 する受信側ホス卜が現れる前のネットワーク A及びネッ卜ワーク Bの状態を示す。 図 1 3において、 本体部 1 0 0の I /O部 3は、 探査パケット生成部 2から受信し た探査バケツ卜を、 ネットワーク Bのサブネッ卜 172. 16. 1 . 0/24へ送信する。 本体 部 1 0 0が送信した探査パケットは、ルータ R 1に着信する。 し力、し、 この時点で は、ネッ卜ワーク B内にエントリ 1及び 2に対応する I Pマルチキャストバケツ卜 の配信を希望する受信側ホス卜端末は存在しない。従って、ルータ R 1は、夫々受 信したエントリ 1及び 2用の探査バケツ卜を破棄する。
図 1 4は、受信側ホスト端末としてデコーダ 3 0 0が出現したときの様子を示す c 図 1 4に示すように、ネッ卜ワーク Bのデコーダ 3 0 0が、エンコーダ 4 0 0の映 像データバケツ卜の受信を開始したものとする。 このとき、デコーダ 3 0 0は、 I Pマルチキャス卜の標準手順（RFG1112、 RFG2236)に従い、 I GNIPを使用してマルチキ ヤストグループに参加する。但し、デコーダ 3 0 0が参加するマルチキャストグル ープは、エンコーダ 4 0 0が映像配信に使用するマルチキャストグル一プアドレス である 「239. 255. 0. 1」 ではなく、 そのエンコーダ 4 0 0のマルチキャストグルー プアドレスが本体部 1 0 0によって関連づけられたマルチキャストグル一プアド レスである 「239. 192. 0. 1」 に参加する。
マルチキャス卜グループ 「239. 192. 0. 1」 の受信側ホスト端末として、 デコーダ 3 0 0が出現したという情報は、ネットワーク Bのマルチキャストルーティングプ ロトコル（この例では DVMRP)に従って、 DVMRPメッセージ（ 「239. 192. 0. 1を送信せ よ」 ）によりルータ R 1を含むネットワーク Bの全てのルータに伝達される。 する と、ルータ R1は、サブネッ卜 Γ172.16.1.0/24 Jからの「239.192.0.1」宛のパケ ットをサブネット 「172.16.2.0/24」 に転送するようにマルチキャストルーティン グテーブルを更新する。
従って、 ルータ R1は、 図 1 5に示すように、 「239.192.0.1」 宛てのパケット であるエントリ 1用の探査バケツ卜を、サブネット「172.16.2./24」側へ転送する ようになる。 これは、エントリ 1用の探査バケツ卜がサブネッ卜「172.16.2.0/24」 へ転送されることを意味する。 なお、 エントリ 2の用の探査パケットに対しては、 ルータ R 1の動作は変わらない。
ルータ R1から転送されたエントリ 1用の探査バケツ卜は、プローブ部 200の I/O部 4 (図 8)に着信する。 通常、 I Pマルチキャストパケットはレイヤ 2のレべ ルでは同報扱いとなるため、 サブネット 「172.16.2.0/24」 に送信された探査パケ ッ卜は、 ルータ R2だけでなくプローブ部 200にも着信するからである。
図 8に示すように、 I/O部 4は、 受信した全てのパケットをパケット分類部 5へ 送信する。 従って、 I/O部 4は、 エントリ 1用の探査パケットをパケット分類部 5 に与える。
パケット分類部 5は、 I/O部 4から受け取ったパケットを分類する。 パケット分 類部 5は、バケツ卜のペイロードを参照し、探査バケツ卜の識別子を見つけること で、 当該パケットが探査パケットであることを識別することができる。 その結果、 当該バケツ卜が探査バケツ卜であった場合には、それを探査バケツト処理部 6に転 送する。なお、 当該バケツ卜が探査バケツ卜でなければ、バケツト分類部 5は、 当 該バケツトを破棄する。
探査バケツト処理部 6は、探査バケツ卜のペイロード（図 1 2)から、エントリ番 号 (= 1 )、及び変換値 (= (172.16.1.1及び 239.192.0.1))の情報を取リ出す。そして、 探査バケツト処理部 6は、探査バケツ卜から取り出した情報を応答バケツト生成部 7に通知する。
応答バケツ卜生成部 7は、探査バケツト処理部 6から得た情報をもとに、応答パ ケッ卜生成部 7は、図 1 6に示すような応答バケツトを生成する。図 1 6は、本実 施例における応答バケツ卜の一例を示し、エントリ 1の探査バケツ卜に対する応答 バケツ卜が示されている。
応答バケツト生成部 7は、応答バケツ卜の送信元ァドレスとして、プローブ部 2 0 0の I Pアドレス（=172. 16. 2. 10)を使用し、 I Pヘッダにセットする。 一方、 応答バケツト生成部 7は、応答バケツ卜の宛先アドレスとして、探査バケツトの変 換値フィールドの送信元アドレス値 (=172. 16. 1. 1)を使用し、 I Pヘッダにセット する。 なお、 応答パケットが使用する上位プロトコルは特に定められていないが、 この実施例では UDPのポー卜 5 0 0 1番が使用され、 UDPヘッダにセッ卜される。さ らに、応答バケツ卜生成部 7は、応答バケツ卜のペイロードとして、応答バケツ卜 であることを示すビッ卜パターン (識別子)、探査バケツ卜から値をコピーしたェン トリ番号（ここでは、 = 1 )、 探査パケットから値をコピーした変換値の情報（ここ では、 =172· 16. 1. 1及び 239. 192. 0. 1)をセッ卜する。応答バケツ卜生成部 7は、応 答バケツ卜を生成し終わると、 応答バケツ卜を I/O部 4へ送信する。 応答バケツト を受信した I/O部 4は、 この応答バケツトをルータ R 1へ送信する。
応答バケツ卜を受信したルータ R 1は、サブネット 「172. 16. 1. 0」上に I Pァド レス 「172. 16. 1. 1」 に対する ARP要求パケットを送信する。 この時点では、 ルータ R 1は、 当該 I Pァドレスに対応する MACァドレス（装置ァドレス）を取得していな いからである。
図 1 5に示すように、ルータ R 1から本体部 1 0 0の I/O部 3に、 ARP要求バケツ 卜が着信すると、 I /O部 3は、 受信した全てのパケットをパケット分類部 8へ送る ようになっているので、 この ARP要求バケツトをバケツ卜分類部 8に渡す。
バケツ卜分類部 8は、 I/O部 3からのバケツ卜が ARP要求バケツトであることを識 別すると、 この ARP要求ノ ケットを ARP処理部 9へ転送する。
ARP処理部 9は、 受信した ARP要求に対して、 ARP応答を返す必要があるか否かを 判断する。 この判断は、 変換テーブル管理部 1が保持する変換テーブル 1 a (図 1 1 )に基づいて行われる。 ARP処理部 9は、変換値フィールドの送信元ァドレス値と ARP要求されている I Pアドレスとが同一となるエントリを変換テーブル 1 aから 探し、該当するェン卜リが存在する場合、当該 ARP要求に対し ARP応答を返す必要が あると判断する。この例では、エントリ 1の変換値フィールドの送信元ァドレス値 が、 ARP要求されている I Pアドレスと一致するため、 ARP処理部 9は ARP応答を返 す必要があると判断する。
図 8に示すように、 ARP応答を返すと判断した ARP処理部 9は、 本体部 1 0 0の M AGアドレスを含む ARP応答バケツト（宛先；ルータ R 1 )を生成し、これを I/O部 3へ 送信する。 ARP応答パケットを受信した I/O部 3は、 サブネット 「172. 16. 1. 0/24」 へ ARP応答バケツ卜を送信する。 ARP応答バケツ卜はルータ R 1にて受信される。こ れによって、 ルータ R 1は、 応答バケツ卜に取得した MACァドレスをセッ卜し、 応 答パケットをその宛先 I Pアドレス 「172. 16. 1. 1」 に従ってサブネット 「172. 16. 1. 0/24」 に送出する。 これによつて、本体部 1 0 0は、応答バケツ卜を受信するこ とができる。 このようにして、 プローブ部 2 0 0から送信された応答パケットは、 本体部 1 0 0に到達する。なお、上記した ARPの要求処理は、一般に proxy ARPと呼 ばれている処理である。また、ルータ R 1は、その後のェン卜リ 1に対応する応答 バケツ卜の転送に、 取得した本体部 1 0 0の MAGァドレスを用いる。
図 1 7に示すように、 本体部 1 0 0の I/O部 3にルータ R 1から送出された応答 バケツ卜が着信すると、 I/O部 3は、この応答バケツ卜をバケツ卜分類部 8へ送る。 図 1 7は、 本体部 1 0 0が応答バケツ卜を受信した状態を示している。
パケット分類部 8は、 I/O部 3からのパケットのペイロードを参照し、 応答パケ ッ卜の識別子を見つけることで、当該バケツ卜が応答バケツトであることを識別し、 応答バケツ卜を応答バケツ卜処理部 1 0へ転送する。
応答バケツ卜処理部 1 0は、応答バケツ卜のペイロード（図 1 6 )からエントリ番 号 (= 1 )、 及び変換値 (= (172. 16. 1. 1 , 239. 192. 0. 1) )を抽出し、 これらの情報を応 答通知として変換テーブル管理部 1へ通知する。
変換テーブル管理部 1は、応答通知の内容と、変換テーブル管理部 1の保持する 変換テーブル 1 aのエントリ情報が矛盾しているか否かを確認する。 具体的には、 応答通知中のエントリ番号に対応する変換テーブル 1 aのエントリ（ここではェン トリ 1 )を参照し、 そのェン卜リ中の変換値と応答通知中の変換値とがー致するか 否かを判定する。 このとき、 エントリ情報が矛盾していた場合 (変換値が一致しな い場合）は、 変換テーブル管理部 1は通知を無視する。 応答通知内容と対応するェントリの内容とが矛盾していなかった場合 (変換値が 一致する場合）には、 変換テーブル管理部 1は、 変換テーブル 1 aの該当エントリ (エントリ 1 )の活性フラグを "ON"にセッ卜し、タイマフィールド値を予め決めら れた値にセッ卜する。この値はネットワーク毎に適宜調整されるものであるが、こ の実施例では図 1 8に示すように "3 [秒]"にセットされる。図 1 8は、図 1 1に 示した変換テーブル 1 aの情報が、 応答通知に基づいて変更された様子を示す。 エントリ中のタイマフィールドの値は、当該ェントリの活性フラグの生存時間を 表しており、 1秒が経過する毎に 1ずつ変換テーブル管理部 1によって減算される。 即ち、 この例では、タイマ値は、当該エントリに対応する新たな応答通知を変換テ 一ブル管理部 1が受け取らない限り、 3秒後には "0" となる。 タイマ値が "0" となった場合、変換テーブル管理部 1は、活性フラグの値を "OFF"にセッ卜する。 変換テーブル管理部 1は、 活性フラグの値を変化させた場合には、 その変化を I GMP処理部 1 1へ通知する。 この変化通知は、 該当エントリ（エントリ 1 )における 活性フラグの変化の方向（=0FF→0N)と、 当該ェン卜リにおける変換対象フィール ドの宛先マルチキャストグル一プアドレス値（この例では、 「239.255.0.1」 （図 1 8))、すなわちネッ卜ワーク A側のマルチキャストグル一プアドレス値とを含んで いる。
活性フラグの変化の方向が OFFから ONであった場合、 IGMP処理部 1 1は、 変化通 知に含まれたマルチキャストグループアドレスに対する IGMP Membership Report を作成する。 この例では、 239.255.0.1に対する IGMP Membership R印 ortが作成さ れる。 IGMP Membership R印 ortは、ホス卜が所定のマルチキャス卜グループへのメ ンバーとして参加することをルータに要請するための IGMPメッセージである。なお、 活性フラグが 0Nから OFFに変化する場合については後述する。 IGNIP処理部 1 1は、 作成した IGMP Membership Report, 即ち 「239.255.0.1」 に対する Membership Re portを I /0部 1 2へ送信する。
I/O部 1 2は、 IGMP Membership Reportをネットワーク A側のサブネット 「192. 168.2.0/24」上に送信する。この IGMP Membership Reportは、図 1 9に示すように、 ルータ R4に着信する。 これにより、 ルータ R4は、 サブネット 「192.168.2.0」 に「239. 255. 0. 1」の受信ホストとして、本体部 1 0 0が出現したことを認識する。 ルータ R 4は、ネットワーク Aで採用されているマルチキャス卜ルーティングプ ロトコル (P I M-SM)を使用し、 ネットワーク A上における他のルータに対して、 「2 39. 255. 0. 1」宛てのバケツトを自身に転送するように要求する。 これにより、ェン コーダ 4 0 0から I Pマルチキャスト配信される映像データバケツトは、ルータ R 5 , ルータネットワーク， 及びルータ R 4を経由して本体部 1 0 0に着信する。 図 2 0に、ネッ卜ワーク Aからネットワーク Bへの映像データバケツ卜のアドレ スを変換し、当該映像データバケツトを転送する際の様子を示す。図 2 0において、 本体部 1 0 0の I/O部 1 2 (図 8 )は、 映像データパケット " (192. 168. 1. 1 , 239. 25 5. 0. 1) " を受信する。 I /O部 1 2は、 受信した全パケットをパケット分類部 8へ送 信するので、 映像データバケツ卜をバケツ卜分類部 8に送信する。
パケット分類部 8は、 I/O部 1 2から受信したパケットの種類を解析し、 I GMPパ ケッ卜、 ARP要求バケツト、 及び応答バケツ卜に該当しないという条件を満たすパ ケッ卜を、ヘッダ変換部 1 3へ転送する。映像データバケツトは、上記条件に合致 するのでヘッダ変換部 1 3へ送られる。
ヘッダ変換部 1 3は、バケツ卜分類部 8からの映像データバケツトを受け取ると、 変換テーブル 1 aの変換対象フィールドの宛先ァドレスを参照し、映像データ/ ケ ッ卜の宛先ァドレスと一致するェン卜リがあるか否かを検索する。 この例では、ェ ントリ 1が見つかる。もし一致するエントリが変換テーブル 1 aになかった場合に は、 ヘッダ変換部 1 3は、 当該バケツ卜を破棄する。 これに対し、 該当するェント リを見つけた場合には、ヘッダ変換部 1 3は、そのェントリの活性フラグを参照す る。このとき、当該活性フラグの値が" ON"であったならば、ヘッダ変換部 1 3は、 当該映像データバケツ卜の送信元ァドレス及び宛先ァドレスを、変換値フィールド の値に変更する。 この例では、ヘッダ変換部 1 3は、映像データバケツ卜の送信元 I Pアドレス及び宛先 I Pアドレス "（192. 168. 1. 1及び 239. 255. 0. 1) " を、 "（1 72. 16. 1. 1及び 239. 192. 0. 1) " に変換する。 なお、 当該活性フラグが "OFF" であ つた場合、ヘッダ変換部 1 3は、 当該 I Pマルチキャストバケツトを破棄する。そ して、 ヘッダ変換部 1 3は、 アドレス変換が終了した映像データパケットを I/O部 3へ送信する。 映像データパケットを受信した I/O部 3は、 B央像データパケットを サブネット 「172.16.1.0/24」 上に送信する。
ネッ卜ワーク Bの各ルータは、 マルチキャストルーティングプロ卜コル（DVMRP) に従って生成された、 「239.192.0.1」 の I Pマルチキャストバケツトをデコーダ 300へ転送するためのマルチキャストルーティングテーブルを有している。従つ て、 図 20に示すように、本体部 1 00から送出される映像データバケツトは、ル ータ R 1 , ルータ R2, ルータ 'ネットワーク， 及びルータ R3を経由してデコー ダ 300に着信する。
B央像データバケツトを受信したデコーダ 300は、このバケツ卜から映像データ を取り出して復号処理を行い、 再生映像を出力する。
なお、エントリ 1の探査バケツトは、本体部 1 00に応答バケツ卜が届くように なった後でも、 上記した周期（1 O Oms)でネットワーク Bへ送出される。 すなわ ち、本体部 1 00は、受信ホス卜の参加/離脱に拘わらず、探査バケツトを送信し 続け、参加している受信ホス卜があるときだけ、応答バケツトを受信できるように なっている。
ところで、ネットワーク Aからネッ卜ワーク Bへエンコーダ 400の映像データ バケツ卜が転送されている間（デコーダ 300でエンコーダ 400からの映像デ一 タを受信している間）、 ルータ R4は、 サブネット 「192.168.2.0/24」 に対して IG MP Membership Queryを定期的に送信している。
マルチキャス卜バケツ卜の受信側ホス卜は、 この IGMP Membership Queryを受信 すると、これに対して IGMP Membership R印 ortで応答しなければならない。この応 答を怠ると、 ルータによるマルチキャストバケツ卜の転送は中止される（RFC1112 及び RFC2236参照）。
このため、 本体部 1 00は、 次のように、 IGMP Menbership Queryに対する処理 を行う。図 8に示すように、本体部 1 00の I/O部 1 2には、 IGMPバケツ卜として I GMP Membership Queryが着信する。 I/O部 1 2は受信した IGMPバケツ卜をバケツ卜 分類部 8に送信する。
バケツト分類部 8は、受信したバケツ卜が IGMPバケツ卜であることを識別すると、 当該バケツトを IGMP処理部 1 1へ転送する。
IGMPバケツ卜を受信した IGNIP処理部 1 1は、変換テーブル管理部 1の変換テープ ル 1 a (図 1 8)を参照し、活性フラグフィールド値が "ON" となるェントリを全て リストアップする。 この例では、 エントリ 1のみがリストアップされる。
IGMP処理部 1 1は、リス卜アップしたエントリの変換対象フィールドの宛先マル チキャストグル一プアドレスに対する IGMP Membership Reportを作成する。この例 では、 IGMP処理部 1 1は、 「239.255.0.1」 に対する IGMP Membership Reportを作 成する。 IGMP処理部 1 1は、 作成した IGMP Membership Reportを I/O部 1 2に送信 する。
I/O部 1 2はサブネッ卜 「192.168.2.0/24」 上に IGMP Membership Reportを送信 する。 すると、 サブネット 「192.168.2.0/24」 上にあるルータ R4に、 本体部 100 からの IGMP Membership Reportが着信する。 これによつて、 「239.255.0.1」 宛て の I Pマルチキャストバケツト（マルチキャストグループ）に対する本体部 1 00 の参加状態が維持される。従って、ルータ R 4からの映像データパケットは引き続 き本体部 1 00を介してネッ卜ワーク Bに転送される。
次に、デコーダ 300が映像データの受信を中止してから映像データバケツ卜の 転送が停止されるまでの間における本実施例の処理の手順を説明する。 図 21に、 ネッ卜ワーク Bでの映像データバケツト及び応答バケツ卜の転送停止の様子を示 す。 図 21において、最初に、 デコーダ 300が、 [^01112及び[^02236に規定され た手法（IGWIP)を用いてマルチキャストグループ "239.192.0.1" から離脱する。 すると、 ルータ R 3は、 「239.192.0.1」 の受信ホス卜（デコーダ 300)が消滅 したこと（ 「239.192.0.1は不要」 ）を、 マルチキャストルーティングプロトコル (D VMRP)を使用してネッ卜ワーク B上の他のルータ（ルータ R 1， R 2等）に通知する。 すると、 ネットワーク B上の各ルータは、 「239.192.0.1」 宛の I Pマルチキャス トバケツ卜を転送しないようにマルチキャス卜ルーティングテーブルを更新する。 これによつて、ルータ R 1が映像データバケツ卜及び探査バケツ卜の転送を中止す る。すると、 プローブ部 200に、探査パケットが着信しなくなる。 プローブ部 2 00は、 探査パケットを受信しなくなると、 応答パケットを送信しなくなる。 これによつて、本体部 1 00における変換テーブル管理部 1で管理されている変 換テーブル 1 aのエントリ 1のタイマフィールド値は "0"になる。タイマフィー ルド値は 1秒につき 1減算され、次の探査バケツ卜が来ないとタイマ初期値（3秒） が再セッ卜されないからである。
変換テーブル 1 aのエントリ 1のタイマフィールド値が "0"に変化すると、変 換テーブル管理部 1は、変換テーブル 1 aの該当するエントリ（エントリ 1)の活性 フラグフィールド値を "ON" から "OFF" に変化させる。
続いて、変換テーブル管理部 1は、活性フラグの変化を IGMP処理部 1 1へ通知す る。 このときの変化の通知内容は、活性フラグの変化の方向 (-0N—0FF)と、変換対 象フィールドの宛先マルチキャストグル一プアドレス値 (=239.255.0.1)とを含ん でいる。
IGMP処理部 1 1は、変化通知を受け取り、 これに含まれた活性フラグの変化の方 向が 0N→0FFであった場合には、 変化通知に対応するマルチキャストグループから の離脱を宣言するためのメッセージとして、 IGNIP Leave Group Messageを作成する。 この例では、 239.255.0.1に対する IGMP Leave Group Messageが作成される。 IGMP 処理部 1 1は、作成した IGNIP Leave Group Message (=239.255.0, 1に対する Leave Group Message)を I/O部 1 2へ送信する。
IGMP Leave Group Messageを受信した I/O部 1 2は、 IGMP Leave Group Message をサブネット 「192.168.2.0/24」 上に送信する。
IGMP Leave Group Messageは、ルータ R 4に着信する。 これにより、ルータ R4 は、 サブネット 「192.168.2.0/24」から 「239.255· 0· 1」 の受信ホス卜（本体部 1 0 0)が消滅したことを認識する。
続いて、 ルータ R 4は、 図 22に示すように、 「239.255.0.1」 の受信ホストが 消滅したことを、マルチキャストルーティングプロトコル (PIM-SM)を使用してネッ トワーク A上の他のルータ（ルータ R 5等）に通知する。 すると、 ルータ R 5は 「2 39.255· 0.1」宛の I Pマルチキャス卜バケツトを転送しないようにマルチキャス卜 ルーティングテーブルを書き換える。 これによつて、ルータ R 5は、エンコーダ 4 00からのの映像データバケツ卜の転送を中止する。 なお、エントリ 2に対しても、エントリ 1と同様の処理が行われ、エンコーダ 5 0 0からの映像データバケツ卜が、デコーダ 3 0 0のェン卜リ 2に対応するネット ワーク Bのマルチキャストグル一プへの参加/離脱に応じて、ネッ卜ワーク Aから ネットワーク Bへ転送され、デコーダ 3 0 0で受信され、映像データバケツ卜に含 まれた映像データが復号 '再生される。
以上の動作により、ネッ卜ワーク Aに接続されたエンコーダ 4 0 0 , 5 0 0の映 像をネッ卜ワーク Bに接続されたデコーダ 3 0 0で再生■出力することができる。
〔作用〕
上述した実施例の作用を、 図 2 3のフローチャートを用いて説明する。
本体部 1 0 0は、 ネッ卜ワーク Bに探査バケツトを定期的に送信する。
本体部 1 0 0は、デコーダ 3 0 0が I Pマルチキャストバケツ卜の配信を要求し ているか否かを判断する（図 2 3におけるステップ 1 0 1、以下 S 1 0 1のように 省略する）。デコーダ 3 0 0が I Pマルチキャストバケツ卜の配信を要求していな いときは、 探査バケツ卜が破棄され、 ステップ 1 0 1の処理を繰り返す。
ネッ卜ワーク B内にデコーダ 3 0 0が現れると、プローブ部 2 0 0は、本体部 1
0 0から送信された探査パケットが着信される （S 1 0 2 ) 。
探査バケツ卜が着信すると、プローブ部 2 0 0は、本体部 1 0 0に応答バケツ卜 を送信する （S 1 0 3 ) 。
プローブ部 2 0 0が送信した応答バケツ卜は、本体部 1 0 0に着信する（S 1 0
4 ) 。 このとき、本体部 1 0 0は、 ネッ卜ワーク B内にあるデコーダ 3 0 0の存在 を認識する。
本体部 1 0 0は、エンコーダ 4 0 0があるネットワーク Aに、 I GMP Membersh i p R印 ortを送信する （S 1 0 5 ) 。
本体部 1 0 0は、 エンコーダ 4 0 0から、映像データバケツ卜を受信する （S 1 0 6 ) o
本体部 1 0 0は、この映像データバケツ卜の送信元アドレス情報と宛先アドレス 情報とを、ネッ卜ワーク Bに対応した情報に変更し、ネッ卜ワーク B側に転送する ( S 1 0 7 ) 。 ネットワーク B側に転送された映像データバケツトは、上流のルータから下流の ルータに流れて、 デコーダ 3 0 0で着信する （S 1 0 8 ) 。
本体部 1 0 0は、デコーダ 3 0 0が映像データバケツ卜の受信を止めたか否かを 確認する （S 1 0 9 ) 。デコーダ 3 0 0が映像データバケツ卜を受信し続けている 場合、 本体部 1 0 0は、 ステップ 1 0 9の処理を繰り返す。
デコーダ 3 0 0が映像データバケツ卜の受信を止めた場合、プローブ部 2 0 0に 探査バケツ卜が到達しなくなる （S 1 1 0 ) 。従って、 プローブ部 2 0 0は、 本体 部 1 0 0に応答バケツ卜を送信するのを止める。
本体部 1 0 0は、応答バケツ卜が受信しなくなつたことを受けて、ネットワーク B側のデコーダ 3 0 0が消滅したことを認識する （S 1 1 1 ) 。
本体部 1 0 0は、 ネットワーク A側に、 デコーダ 3 0 0が消滅したことを I GMP Leave Group Messageで通矢。する （S 1 1 2 ) 。
本体部 1 0 0からの通知を受けて、エンコーダ 4 0 0は、 B央像データバケツ卜の 配信を停止する。'
〔実施の形態の効果〕
本実施の形態によれば、マルチキャストグル一プアドレスやマルチキャストルー ティングプロトコルが一致しないネッ卜ワーク間において、 I Pマルチキャスト配 信を行うことができる。例えば、公共機関がイントラネッ卜で収集した映像を、 I Pデータのまま民間ネッ卜ワークにマルチキャスト配信することができる。
また、本実施例によれば、ネッ卜ワーク Aとネットワーク Bとに本体部 1 0 0を 接続し、且つ本体部 1 0 0とルータ 1台を隔てたサブネッ卜にプローブ部 2 0 0を 接続することにより、上記した作用効果を得ることができる。 このように、既存の ネットワーク A及び Bの構成を可能な限り変更することなくネットワーク間の I Pマルチキャス卜配信を可能とする。
〔変形例〕
ネットワーク A及びネッ卜ワーク Bのマルチキャストルーティングプロトコル、 マルチキャストグル一プアドレスは、上記した実施例に挙げた条件には限定されず、 実施例の動作を阻害しない範囲で変更可能である。例えば、ネットワーク Aとネッ トワーク Bとでマルチキャストルーティングプロトコルが同じであっても良い。ま た、実施例では映像データを I Pマルチキャス卜配信する例を挙げたが、配信され るデータは、テキストデータ， 画像データ， 音声データ， これらの組み合わせ， 或 いはこれらの少なくとも 1つと映像データの組み合わせであっても良い。 さらに、 前記実施例ではエンコーダ 1 ( 4 0 0 )からデコーダ 3 0 0への映像データバケツ 卜の配信について説明したが、勿論エンコーダ 2 ( 5 0 0 )からの配信も同様に行 われる。
また、本実施形態において説明したルータの少なくとも 1つはレイヤ 3スィッチ であっても良い。
また、本発明のマルチキャストネットワーク接続装置は、本実施の形態にのみ限 定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え 得ることは勿論である。 産業上の利用可能性
本発明のマルチキャス卜ネッ卜ワーク接続装置によれば、多数のホス卜端末が接 続するネットワーク間において、同一の I Pマルチキャス卜バケツトを一斉に送受 信する場合に、設計思想等が異なる場合であっても、容易且つ正確にマルチキャス ト配信を実施することができる。

Claims

請求の範囲
1 . 第 1のマルチキャス卜グループへの参加メンバーの出現を検出する検出手段 前記検出手段によって参加メンバーの出現が検出されたときに、第 1のマルチキ ヤス卜グループに対応する第 2のマルチキャストグループに参加する参加手段と、 前記第 2のマルチキャストグループへの参加により送信されてくる、第 2のマル チキャス卜グループ宛のマルチキャス卜バケツトを受信する受信手段と、
前記受信手段によって受信されたマルチキャス卜バケツ卜の宛先ァドレスを前 記第 1のマルチキャストグループのァドレスに変換する変換手段と、
前記変換手段によって宛先ァドレスが変換されたマルチキャス卜バケツトを前 記第 1のマルチキャス卜グループに送出する送信手段と
を含むマルチキャストグループ接続装置。
2. 前記参加メンバーの消滅を検出する第 2検出手段と、
前記第 2検出手段によって前記参加メンバーの消滅が検出された場合に、前記第 2のマルチキャストグル一プから離脱する離脱手段とをさらに含む
請求の範囲 1記載のマルチキャストグル一プ接続装置。
3 . 前記検出手段は、前記参加メンバーの存在を探査するための探査バケツ卜を 周期的に第 1のマルチキャス卜グループ宛で送信する探査バケツト送信部と、前記 参加メンバーが存在しているときのみ探査バケツ卜を受信可能なプローブ手段か ら送信される探査バケツ卜毎の応答バケツ卜を受信する応答バケツ卜受信部とを 含み、 前記応答バケツ卜の受信により前記メンバーの存在を検出する
請求の範囲 1又は 2記載のマルチキャストグループ接続装置。
4 . 前記第 2検出手段は、前記応答バケツ卜受信部による応答バケツ卜の受信を 監視し、所定期間応答バケツ卜の受信がない場合に、前記参加メンバーの消滅を検 出する
請求の範囲 3記載のマルチキャス卜グループ接続装置。
5 . 第 1のネットワークと第 2のネッ卜ワークとに接続される本体部と、 前記第 1のネッ卜ワークにおいて少なくとも 1台のルータ又はレイヤ 3スイツ チを介して前記本体部と接続されるプロ一ブ部とを備え、
前記本体部は、
第 1のネッ卜ワークにおけるマルチキャストグル一プアドレスが宛先ァドレ スとして設定され、このマルチキャス卜グループアドレス宛のバケツ卜の受信を望 む受信ホス卜が出現したことを条件として前記ルータ又はレイヤ 3スィッチを介 して前記プローブ部に着信する探査バケツトを周期的に第 1のネッ卜ワークへ送 信する探査バケツト送信部と、
前記プローブ部から送信される探査バケツ卜の応答バケツ卜を前記ルータ又 はレイヤ 3スィッチを介して受信することにより受信ホス卜の出現を検出する検 出部と、
前記検出部によって受信ホス卜の出現が検出された場合に、前記第 1のネット ワークにおけるマルチキャス卜グループアドレスに対応する第 2のネッ卜ワーク におけるマルチキャストグル一プアドレス宛のバケツ卜の受信を前記第 2のネッ トワークに要請する要請部と、
前記要請によって第 2のネッ卜ワークから送信されてくる前記第 2のネッ卜 ワークにおけるマルチキャストグル一プアドレス宛のバケツ卜を受信する受信部 と、
前記受信部によって受信されたバケツ卜の宛先ァドレスを対応する第 1のネ ッ卜ワークにおけるマルチキャストグル一プアドレスに変換するァドレス変換部 と、
前記ァドレス変換部によって宛先ァドレスが変換されたバケツトを前記第 1 のネッ卜ワークへ送信する送信部とを含み、
前記プローブ部は、前記探査バケツ卜を受信する毎に、 これに対応する応答パケ ッ卜を生成して送出する手段を含む
マルチキャストネットワーク接続装置。
6 . 前記プローブ部は、前記受信ホス卜が存在している間のみ、探査バケツ卜を 受信し、
前記検出部は、前記応答バケツ卜の受信を監視し、所定時間応答バケツ卜の受信 がない場合に前記受信ホストの消滅を検出し、
前記要請部は、前記検出部によって受信ホス卜の消滅が検出された場合に、前記 第 2のネットワークにおけるマルチキャストグル一プアドレス宛のバケツトの受 信停止を前記第 2のネットワークに要請する
請求の範囲 5記載のマルチキャストネットワーク接続装置。
7 . ネットワークに接続される本体部と、
前記ネットワークにおいて少なくとも 1台のルータ又はレイヤ 3スィッチを介 して前記本体部と接続されるプローブ部とを備え、
前記本体部は、前記ネッ卜ワークにおけるマルチキャストグル一プアドレスが宛 先ァドレスとして設定され、このマルチキャストグル一プアドレス宛のバケツ卜の 受信を望む受信ホス卜が出現したことを条件として前記ルータ又はレイヤ 3スィ ツチを介して前記プローブ部に着信する探査バケツ卜を第 1のネッ卜ワークへ送 信する探査バケツ卜送信部と、前記プローブ部から送信される探査バケツ卜の応答 バケツトを前記ルータ又はレイヤ 3スィッチを介して受信することにより受信ホ ス卜の出現を検出する検出部とを含み、
前記プローブ部は、前記探査バケツトを受信したときにこれに対応する応答パケ ットを生成して送出する手段を含む
マルチキャス卜バケツ卜の受信ホス卜の検出装置。
8 . 前記プローブ部は、前記受信ホス卜が存在している間のみ、探査バケツ卜を 受信し、 前記検出部は、前記応答バケツ卜の受信を監視し、所定時間応答バケツ卜の受信 がない場合に前記受信ホス卜の消滅を検出する
請求の範囲 7記載のマルチキャス卜バケツ卜の受信ホス卜の検出装置。
9 . 第 1のマルチキャストグループへの参加メンバ一の出現を検出するステップ 前記参加メンバ一の出現が検出されたときに、第 1のマルチキャス卜グループに 対応する第 2のマルチキャストグループに参加するステップと、
前記第 2のマルチキャストグループへの参加により送信されてくる、第 2のマル チキャストグループ宛のマルチキャス卜バケツトを受信するステップと、
受信されたマルチキャストバケツ卜の宛先ァドレスを前記第 1のマルチキャス トグループのァドレスに変換するステップと、
宛先ァドレスが変換されたマルチキャス卜バケツ卜を前記第 1のマルチキャス 卜グループに送出するステップと
をマルチキャストグル一プ接続装置が実行するマルチキャストグル一プ接続方法。
1 0 . 前記参加メンバ一の消滅を検出するステップと、
前記参加メンバーの消滅が検出された場合に、前記第 2のマルチキャス卜グルー プから離脱するステップとを、マルチキャストグル一プ接続装置が実行する請求の 範囲 9記載のマルチキャストグループ接続方法。
1 1 . 前記第 1のマルチキャストグループへの参加メンバ一の出現を検出する ステップは、
前記参加メンバーの存在を探査するための探査バケツ卜を周期的に第 1のマル チキャス卜グループ宛で送信するステップと、前記参加メン/く一が存在していると きのみ探査バケツトを受信可能なプローブ手段から送信される探査バケツ卜毎の 応答バケツトを受信するステップとを実行し、前記応答バケツ卜の受信により前記 メンバーの存在を検出する 請求の範囲 9又は 1 0記載のマルチキャストグループ接続方法。
1 2 . 前記参加メンバーの消滅を検出するステップは、
応答バケツ卜の受信を監視し、所定期間応答バケツ卜の受信がない場合に、前記 参加メンバーの消滅を検出する
請求の範囲 1 1記載のマルチキャストグループ接続方法。
1 3 . 第 1のネッ卜ワークと第 2のネットワークとに接続される本体部と、 前記第 1のネッ卜ワークにおいて少なくとも 1台のルータ又はレイヤ 3スイツ チを介して前記本体部と接続されるプローブ部とを備えるマルチキャストネット ワーク接続装置が実行する方法であって、
前記本体部は、
第 1のネッ卜ワークにおけるマルチキャス卜グループアドレスが宛先ァドレ スとして設定され、このマルチキャストグル一プアドレス宛のバケツ卜の受信を望 む受信ホス卜が出現したことを条件として前記ルータ又はレイヤ 3スィッチを介 して前記プローブ部に着信する探査バケツトを周期的に第 1のネッ卜ワークへ送 信するステップと、
前記プローブ部から送信される探査バケツ卜の応答バケツトを前記ルータ又 はレイヤ 3スィッチを介して受信することにより受信ホス卜の出現を検出するス テツプと、
受信ホス卜の出現が検出された場合に、前記第 1のネッ卜ワークにおけるマル チキャス卜グループアドレスに対応する第 2のネッ卜ワークにおけるマルチキヤ ストグル一プアドレス宛のバケツ卜の受信を前記第 2のネッ卜ワークに要請する ステップと、
第 2のネットワークから送信されてくる前記第 2のネッ卜ワークにおけるマ ルチキャストグル一プアドレス宛のバケツトを受信するステップと、
受信されたバケツ卜の宛先アドレスを対応する第 1のネッ卜ワークにおける マルチキャス卜グループアドレスに変換するステップと、 宛先ァドレスが変換されたバケツトを前記第 1のネッ卜ワークへ送信するス テツプとを実行し、
前記プローブ部は、前記探査バケツ卜を受信する毎に、これに対応する応答パケ ットを生成して送出するステップを実行する
マルチキャストネットワーク接続方法。
1 4 . 前記プローブ部は、前記受信ホス卜が存在している間のみ、探査バケツト を受信し、
前記受信ホス卜を検出するステップでは、前記応答バケツ卜の受信を監視し、所 定時間応答バケツ卜の受信がない場合に前記受信ホス卜の消滅を検出し、
前記第 2のネットワークにおけるマルチキャス卜グループアドレス宛のバケツ 卜の受信を前記第 2のネットワークに要請するステップでは、受信ホス卜の消滅が 検出された場合に、前記第 2のネットワークにおけるマルチキャストグル一プアド レス宛のバケツ卜の受信停止を前記第 2のネッ卜ワークに要請する
請求の範囲 1 3記載のマルチキャス卜ネッ卜ワーク接続方法。
1 5 . ネッ卜ワークに接続される本体部と、
前記ネッ卜ワークにおいて少なくとも 1台のルータ又はレイヤ 3スィッチを介 して前記本体部と接続されるプローブ部とを備えるマルチキャストバケツトの受 信ホス卜の検出装置が実行する方法であって、
前記本体部は、前記ネットワークにおけるマルチキャス卜グループアドレスが宛 先ァドレスとして設定され、このマルチキャス卜グループアドレス宛のバケツ卜の 受信を望む受信ホス卜が出現したことを条件として前記ルータ又はレイヤ 3スィ ツチを介して前記プローブ部に着信する探査バケツ卜を第 1のネットワークへ送 信するステップと、前記プローブ部から送信される探査バケツ卜の応答バケツトを 前記ルータ又はレイヤ 3スィッチを介して受信することにより受信ホス卜の出現 を検出するステップとを実行し、
前記プローブ部は、前記探査バケツ卜を受信したときにこれに対応する応答パケ ットを生成して送出するステップを実行する
マルチキャストバケツ卜の受信ホス卜の検出方法。
1 6 . 前記プローブ部は、前記受信ホス卜が存在している間のみ、探査バケツト を受信し、
前記検出部は、前記応答バケツ卜の受信を監視し、所定時間応答バケツ卜の受信 がない場合に前記受信ホス卜の消滅を検出する
請求の範囲 1 5記載のマルチキャス卜バケツ卜の受信ホス卜の検出方法。
PCT/JP2002/009564 2002-09-18 2002-09-18 マルチキャストグループ接続装置 WO2004028099A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2002/009564 WO2004028099A1 (ja) 2002-09-18 2002-09-18 マルチキャストグループ接続装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2002/009564 WO2004028099A1 (ja) 2002-09-18 2002-09-18 マルチキャストグループ接続装置

Publications (1)

Publication Number Publication Date
WO2004028099A1 true WO2004028099A1 (ja) 2004-04-01

Family

ID=32012218

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2002/009564 WO2004028099A1 (ja) 2002-09-18 2002-09-18 マルチキャストグループ接続装置

Country Status (1)

Country Link
WO (1) WO2004028099A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1143680A2 (en) * 2000-04-03 2001-10-10 Hitachi, Ltd. Method of multicast data packet transmission
EP1161028A2 (en) * 2000-05-30 2001-12-05 Hitachi, Ltd. A multicast routing method and an apparatus
US20020021697A1 (en) * 2000-07-21 2002-02-21 Kazuaki Tsuchiya Multicast routing method and apparatus for routing multicast packet

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1143680A2 (en) * 2000-04-03 2001-10-10 Hitachi, Ltd. Method of multicast data packet transmission
EP1161028A2 (en) * 2000-05-30 2001-12-05 Hitachi, Ltd. A multicast routing method and an apparatus
US20020021697A1 (en) * 2000-07-21 2002-02-21 Kazuaki Tsuchiya Multicast routing method and apparatus for routing multicast packet

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Internet-Draft draft-ietf-idmr-igmp-v3-11.ps "Internet Group Management Protocol, Version 3" (May 2002) *
Internet-Draft draft-ietf-pim-sm-v2-new-05.ps "Protocol Independent Multicast-Sparse Mode (PIM-SM) : Protocol Specification (Revised)" (1 March 2002) *
Request for Comments: 1075, "Distance Vector Multicast Routing Protocol", (Nov. 1988) *
Request for Comments: 2362, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", (June 1998) *

Similar Documents

Publication Publication Date Title
US8185657B2 (en) Data generating device
US7860094B2 (en) Multicast routing method and apparatus for routing multicast packet
US7835276B2 (en) Admission control mechanism for multicast receivers
JP4297875B2 (ja) ネットワーク中継方法及び装置
AU720817B2 (en) Multicast switching
EP1938530B1 (en) Application-level multicasting architecture
US20050249233A1 (en) Method for making effective use of bandwidth in multicast communication on ring network
US20030193958A1 (en) Methods for providing rendezvous point router redundancy in sparse mode multicast networks
JP2000134208A (ja) 情報中継装置
WO2010111956A1 (zh) 一种组播转发路径收敛的方法和系统
CN101527727A (zh) 通信设备和操作管理方法
WO2009024054A1 (fr) Procédé, dispositif et système pour réaliser l'agent de protocole de gestion pour des membres dans un groupe de multidiffusion
JP4141304B2 (ja) マルチキャスト通信ネットワークにおける通信方法、受信端末、ｌ２スイッチおよびｌ３スイッチ
JP3824906B2 (ja) ネットワーク間接続方法、その装置およびその装置を用いたネットワーク間接続システム
JP2007228293A (ja) ノード装置および通信システム
CN101827037A (zh) 组播数据流的发送方法、装置和二层交换设备
WO2004028099A1 (ja) マルチキャストグループ接続装置
Cisco Configuring Networking Protocols
JP2004064649A (ja) ネットワーク中継装置及び該装置の通信離脱方法
JP2004254288A (ja) マルチキャストデータ通信システム及び方法、クライアント側ゲートウェイ、サーバ側ゲートウェイ、コンピュータプログラム、ならびに、コンピュータプログラムを記録した記録媒体
CN101286925B (zh) 检测是否会出现重复的组播数据包的方法及装置
JPH11127151A (ja) マルチキャスト方法
Hardwick et al. IP multicast explained
Shah et al. Performance under a failure of wide-area datagram networks with unicast and multicast traffic routing
Cao et al. A novel scalable explicit multicast protocol

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP