JP2005094608A - Ip multicast transfer device and ip multicast communication information management device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a transfer device and a communication information management device used in an IP multicast transfer system. <P>SOLUTION: By a system comprising a multicast communication information management device 1 (VLM), a multicast transfer device 2 (VLR) and a communication device 3, a multicast communication on the Internet is realized. The VLR 2 composes a VLR management area for managing its subordinate communication device 3, and performs a transmission to the communication device 3 by using a unique IP multicast address within the VLR management area. On the other hand, the VLM 1 composes a VLM management area for managing the VLR 2 participating a group communication (VMC session) managed by the VLM 1, and notifies to the VLR 2 participating the same VMC session, necessary information for communication with another VLR 2, thereby enabling a data transfer of the VMC session with the VLR. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to provision of an IP multicast transfer device and an IP multicast communication information management device used in an IP multicast transfer system.

  Multicast communication is a technique for simultaneously transmitting data to a group of some communication devices among communication devices connected to a network. This multicast communication is an efficient communication method because data transmission is performed only to a necessary communication device. Therefore, it is desired that such multicast communication can be performed freely.

Incidentally, there is IP multicast as a means for realizing multicast communication on the Internet. In this IP multicast, communication is performed using an IP multicast address. The IP multicast address is a special address prepared for multicast in advance among IP addresses. In IP multicast, this IP multicast address is used as an identifier of a group consisting of a plurality of communication devices that desire to receive data, and multicast communication is realized by transmitting data with this identifier as a destination.
In other words, when communication is performed using IP multicast, an IP multicast address must be determined in advance. When the IP multicast address is determined, it must not overlap with other IP multicast addresses in the network through which the IP multicast communication propagates.

Conventionally, the IP multicast address used in the IP multicast communication is arbitrarily selected by the sender or determined by inquiring an administrator who manages the IP multicast address.
However, in this IP multicast address management method, when a sender arbitrarily selects an IP multicast address, the IP multicast address may be duplicated, and uniqueness within the network cannot be ensured. There was a case where communication using IP multicast could not be performed.
In addition, when an IP multicast address is determined by an administrator, there is a problem that it takes too much time to determine the IP multicast address.

  For such inconvenience, several mechanisms have been devised that automatically determine IP multicast addresses without duplication. The invention of the multicast session management apparatus disclosed in Japanese Patent Laid-Open No. 2000-244488 is one of them. This multicast session management apparatus receives data from a sender of multicast communication by unicast, and transmits the data by IP multicast on behalf of the sender. The multicast session management apparatus centrally manages the available multicast addresses, thereby preventing the redundant use of multicast addresses.

However, since the multicast session management apparatus transmits to downstream apparatuses using IP multicast, if there is a network relay that does not support IP multicast on the transmission path, communication is disconnected there.
Also, when the number of participants in group communication increases, a plurality of multicast session management devices may be provided to receive data from senders in a distributed manner.
However, when a plurality of multicast session management devices are provided, if the IP multicast address used by each device is duplicated, the same content data is transmitted from the plurality of devices to the same participant. Then, there is no point in providing a plurality of devices for reducing the load. Therefore, when a plurality of multicast session management devices are provided, the devices notify each other of IP multicast address management information so that duplicate IP multicast addresses are not used.
JP 2000-244488 A

As described above, although several methods for managing IP multicast addresses have been devised, all of them are assumed to be used in a small-scale network.
For example, the above-described conventional multicast session management device can also manage the IP multicast address in a unified manner when there are few participants, but when a plurality of devices are provided, each device uses an IP used by another device. It must not overlap with the multicast address. That is, even if an attempt is made to install the multicast session management apparatus on a large-scale network, it is not freed from the difficult problem of IP multicast address management.
Thus, it is very difficult to use these methods in a large-scale network. This is because information about which IP multicast address is used in which IP multicast communication must be shared in advance between all organizations to which IP multicast communication is transferred.

  In order to share such information, an organization that centrally manages IP multicast addresses is organized, and IP multicast addresses are centrally managed here. However, in the case of centralized management, it is necessary to manage an enormous amount of information called IP addresses, so it takes about a few days to apply after using an IP multicast address. is the current situation.

By the way, although there is an increasing demand for the ability to perform multicast communication freely, multicast communication that is particularly highly demanded can be referred to as “foamy multicast communication”. In other words, it is multicast communication used in a group in which individuals gather together, share information freely, and dissolve in a relatively short period of time.
It is too inconvenient for such a foamy multicast communication to take several days before the application is accepted. For example, when trying to use group communication to urgently solicit opinions on a specific theme, it may even be that the significance of multicast communication has already disappeared when the application is accepted.

  The basis of this invention is the recognition that the IP multicast address is responsible for the above problem in that it must ensure uniqueness within the network through which IP multicast communication can propagate. Therefore, the first problem to be solved was considered to facilitate the management of IP multicast addresses in the entire network.

Further, IP multicast communication has the following problems. That is, it is a problem that not all network repeaters (hereinafter referred to as “routers”) constituting the current Internet support IP multicast. For example, since a relay device such as a switching hub checks and transmits a MAC address, it cannot cope with IP multicast. When such a router that does not support IP multicast exists on the communication path, the multicast packet is ignored and multicast communication is disconnected.
The conventional multicast session management apparatus described above also has this problem. If this device is to be put into practical use in a large-scale network, all routers on the communication path must be replaced with ones that support IP multicast.

A tunneling technique has been proposed as a technique for realizing IP multicast communication beyond a network that does not support IP multicast. However, existing tunneling techniques assume the requirement for uniqueness of IP multicast addresses. Therefore, the tunneling technique does not alleviate various difficulties associated with management of IP multicast addresses.
Therefore, the present invention provides a second problem to be solved that enables group communication that takes advantage of IP multicast communication even when a router that does not support IP multicast exists on the communication path. I thought.

  In the first invention, one or more subordinate communication devices are connected to a network, a communication device management area for managing these communication devices is formed, and a channel for group communication (hereinafter referred to as “VMC session”) is established. Connects to a channel management device to be managed via a network, and transmits / receives VMC session data to / from a device that manages other communication device management areas via a network that supports IP multicast or does not support IP multicast, Data of the VMC session is transmitted to a subordinate communication device according to a unique IP multicast address within the communication device management area.

  According to a second invention, there is provided a VMC information storage unit for storing information related to the VMC session in the first invention, and a request to participate in a specific VMC session and information specifying the VMC session from the subordinate communication device. When a certain VMC-ID is transmitted, an IP multicast address used to transmit the data of the VMC session to the communication device is selected, and the VMC-ID is associated with the IP multicast address to associate the VMC-ID with the VMC-ID. The channel management device that stores the information in the information storage unit and manages the VMC session is requested to participate in the VMC session, and the other IP participating in the VMC session from the channel management device that has received the request. Upon receiving information related to the multicast transfer device, this information is sent to the VMC-I When the VMC session data is transmitted from the subordinate communication device, the VMC information storage unit sends the VMC information based on the IP multicast address that is the destination of the data. -ID is extracted, and information on other IP multicast transfer devices participating in the VMC session specified by this VMC-ID is extracted, and the above-mentioned data is added to the other When the data of the VMC session is received from another IP multicast transfer device while being transferred to the IP multicast transfer device, the VMC-ID is extracted from this data, and the IP multicast address corresponding to this VMC-ID is read from the VMC information storage unit. Extract the IP multicast to the received data. And transmits to the subordinate communication apparatus adds bets address.

  The third invention connects to a network repeater on a network via a communication line, manages a channel of group communication (hereinafter referred to as “VMC session”) using IP multicast communication, and participates in the VMC session An IP multicast communication information management apparatus that manages a network repeater that connects a communication apparatus to a network, and includes a storage unit that stores information related to the network repeater in association with the VMC session, and participates in the VMC session from the network repeater Upon receiving the request, the information on the network repeater that has requested to participate in the VMC session is stored in the storage unit in association with the channel identifier that identifies the VMC session, and the information on the network repeater is stored. Participate in the above VMC session When a request for withdrawal from a VMC session is received from any of the network repeaters, the information about the network repeater is deleted from the storage unit, and the VMC session The updated contents of the storage unit are transmitted to all participating network repeaters.

According to the first invention, since uniqueness of the IP multicast address only needs to be maintained between the participant in the multicast communication and the IP multicast transfer device that manages the participant, it is possible for all the members who participate in the same VMC session. It is no longer necessary to assign the same IP multicast address. Therefore, since each IP multicast transfer device only needs to manage the IP multicast address within the communication device management area for managing the communication devices under its control, uniqueness can be easily secured, and the IP multicast address can be set. Decide quickly.
Further, since the application data of the VMC session can be transferred even when there is a router that does not support IP multicast between the IP multicast transfer devices, the IP multicast transfer device of the present invention can be used without replacing the router with one compatible with IP multicast. It can be used for actual operation.

  According to the second invention, based on the VMC-ID shared between the IP multicast transfer devices, each IP multicast transfer device can take out the IP multicast address used in its own communication device management area. it can. Therefore, it is not necessary to know what IP multicast address is used in another communication device management area.

  According to the third invention, the IP multicast communication information management device manages information on all IP multicast transfer devices participating in the VMC session, and notifies each IP multicast transfer device of information on other IP multicast transfer devices. doing. Since this information includes information necessary for communication between the IP multicast transfer apparatuses, the IP multicast transfer apparatus can transfer the application data of the VMC session to another IP multicast transfer apparatus based on this information. Good. Therefore, even when a network repeater that does not support IP multicast exists between the IP multicast transfer apparatuses, application data transmission / reception of the VMC session can be realized.

FIG. 1 is a diagram showing an embodiment of group communication using a VMC session, that is, IP multicast, realized by the present invention.
This group is composed of an IP multicast communication information management device (hereinafter referred to as “VLM”) 1, an IP multicast transfer device (hereinafter referred to as “VLR”) 2, and a communication device 3 under each VLR 2, and VLM 1 and VLR 2 are It is connected via the Internet N.
Hereinafter, for convenience of expression, the communication device 3 may be referred to as “terminal 3” or “participant terminal 3”.

  The entire system that implements the VMC session is composed of an area in which the VLM 1 manages the VLR 2 and a communication apparatus management area in which the VLR 2 manages the terminals 3 under it. Hereinafter, the former is called VLM management area A, and the latter is called VLR management area B.

  Such a system configuration is generated for each arbitrary VMC session. An arbitrary VMC session is identified from another VMC session by a VMC-ID which is an identifier.

FIG. 2 shows the contents of this VMC-ID. The VMC-ID is a combination of a VLM identifier and a channel identifier.
The VLM identifier is information for specifying VLM1. As this VLM identifier, for example, the URL or global IP address of VLM1 can be used.
The channel identifier is information for specifying a channel, that is, a specific VMC session. The broadcasting stations are distinguished by the frequency used, and 1 channel or 3 channels are equivalent to the channel in this case. That is, when a specific channel of the television receiver is selected, the same content is broadcast to only the viewer who has selected that channel. The IP multicast communication using the system of this embodiment is similar to this, and the application data of the same VMC session is sent all at once to only those who have selected a specific channel from the terminal 3.

FIG. 2 illustrates a case where the VLM identifier is “vlm.jaist.ac.jp” and the channel identifier is “chat1”. In this example, the VMC-ID is “vlm.jaist.ac.jp/cat1”, which is information for identifying the VMC session from other VMC sessions.
The channel identifier is managed inside the VLM 1 that controls and manages the VMC session. Therefore, if a VMC-ID that is a combination of a VLM identifier and a channel identifier is specified, a specific VMC session can be identified from a vast area of the Internet. That is, the VLM 1 that manages the VMC session can be seen from the portion representing the VLM identifier of the VMC-ID. The VLM 1 extracts a channel identifier from the VMC-ID, and recognizes which VMC session the request for participation is based on the channel identifier.

  The VMC session identified by the VMC-ID is composed of VLM1, a participant terminal group that participates in the VMC session, and a VLR group that manages the participant terminal 3. In the VLM management area A, the VLM 1 manages information on all VLRs 2 participating in the VMC session specified by the VMC-ID. However, the participant terminal 3 is not managed in this area. This is because the management of the participant terminal 3 is performed inside the VLR management area B which is an area independent of the VLM management area A.

  In the VLR management area B, each VLR 2 managed by the VLM 1 manages information of all terminals 3 that have requested the VLR 2 to participate in the VMC session. As described above, an arbitrary VMC session identified by one VMC-ID is realized by a system having a two-stage configuration of the VLM management area A and the VLR management area B.

  In the VLR management area B, application data that is the content of the VMC session is shared between the VLR 2 and the participant terminals 3 under the VLR 2 by inter-VLR-terminal communication. And this VLR-terminal communication is performed using the technique of IP multicast communication. For this reason, it is not necessary to duplicate data as many as the number of participant terminals 3 and to transmit the data to each terminal 3, so that efficient communication can be realized.

On the other hand, this application data is shared with other VLRs 2 participating in the VMC session by inter-VLR communication. Such inter-VLR communication is possible within VLM management area A, as VLM1 notifies each VLR2 of other VLR2 information that participates in the same VMC session, and each VLR2 stores this information. Because it is.
Note that the communication method of VLR-terminal communication is multicast communication, but the method of communication between VLRs is not necessarily multicast communication. In this embodiment, it is assumed that unicast communication is used. This is because the VLR 2 itself is a router that supports IP multicast, but not all routers that exist on the communication path between the VLR 2 are compatible with IP multicast.

Next, how the VLM1 and VLR2 are configured will be described with reference to FIG.
The VLM 1 includes a VLM channel information storage unit 4, a VLM channel participation / withdrawal request reception unit 5, a VLM channel information management unit 6, and a VLM channel information transmission unit 7.

  As shown in FIG. 4, the VLM channel information storage unit 4 includes all channel identifiers managed by the VLM 1 and information on all VLRs 2 participating in the VMC session specified by the channel identifier. It is remembered. Note that the VLM channel information storage unit 4 stores no information regarding the terminal 3. This is because the VLM channel information storage unit 4 is provided for the VLM management area A where the VLM1 manages the participating VLR2.

The VLM channel participation / withdrawal request receiving unit 5 receives this signal when a signal requesting participation or withdrawal from the VMC session managed by the VLM1 is transmitted from the VLR2.
The VLM channel information management unit 6 updates the content corresponding to the VMC session in the VLM channel information storage unit 4 based on the participation request signal received by the VLM channel participation / withdrawal request reception unit 5.
The VLM information transmission unit 7 notifies the VLR 2 of the updated information in the VLM channel information storage unit 4.

  The VLR 2 includes a VMC information storage unit 8, a VMC session participation / withdrawal request reception unit 9, a VMC information management unit 10, and an IP multicast address management unit 11.

  As shown in FIG. 5, the VMC information storage unit 8 includes a VMC-ID, an IP multicast address used in VLR-terminal communication for the VMC session specified by the VMC-ID, and the VMC session. The identifier of the terminal 3 participating in the information and the information regarding the other VLR 2 participating in the VMC session are stored.

Here, the IP multicast address is used by the VLR 2 for communication using the IP multicast to the terminal 3 under its control. The identifier of the terminal 3 is, for example, the IP address of the terminal 3. However, this IP address may be private or global. This is because it is sufficient that the VLR 2 can be distinguished from other terminals 3 within the VLR management area B.
The information regarding the other VLR 2 includes a VLR identifier, a communication method between the VLRs, and information necessary for communication between the VLRs. The VLR identifier is information for identifying a specific VLR 2 and, for example, the global IP address of the VLR 2 is used.
FIG. 5 shows a case where there is one channel, but the VMC information storage unit 8 stores information for the number of channels in which the subordinate terminal 3 participates, that is, for the number of VMC sessions. ing.

The VMC session participation / withdrawal request receiving unit 9 receives a VMC session participation / withdrawal request signal from the terminal 3.
The VMC information management unit 10 moves to the VMC session specified by the channel identifier included in the VMC-ID with respect to the VLM1 specified by the VLM identifier included in the VMC-ID included in the participation or withdrawal request signal. Request to join or leave. In addition, the VMC information management unit 10 receives the updated channel information transmitted from the VLM channel information transmission unit 7 of the VLM 1 and stores it in the VMC information storage unit 8.

  The IP multicast address management unit 11 automatically assigns a unique IP multicast address that is unique within the VLR management area B so that the VLR 2 can use IP multicast communication for the terminals 3 participating in the VMC session. decide. Then, this IP multicast address is notified to the terminal 3. This IP multicast address is determined between the VLR 2 and the terminal 3 under its control, and is used only within the VLR management area B, which is a closed area, and communication that flows on the Internet It is not used for. Therefore, it does not matter at all whether the other VLR 2 overlaps with the IP multicast address used with the terminal 3 under its control. Therefore, it is not necessary for the VLRs 2 to notify each other of information regarding the IP multicast address that they are using.

  The VLR 2 also includes an IP multicast transmission / reception unit 12, a transfer rule determination unit 13, and an inter-VLR transfer unit 14.

When the application data of the VMC session is transmitted from the terminal 3, the IP multicast transmission / reception unit 12 has a function of receiving this and passing it to the transfer rule determination unit 13. The IP multicast transmission / reception unit 12 also has a function of adding the IP multicast address and transmitting the IP multicast address to the subordinate terminal 3 when the transfer rule determination unit 13 specifies the IP multicast address.
The transfer rule determination unit 13 has a function of extracting the VMC-ID from the VMC information storage unit 8 using the IP multicast address added to the application data transmitted from the subordinate terminal 3 as a key, and the application received from the other VLR 2 And a function of extracting an IP multicast address from the VMC information storage unit 8 using the VMC-ID added to the data as a key. That is, the transfer rule determination unit 13 functions to perform mutual conversion between the VMC-ID and the IP multicast address.
The inter-VLR transfer unit 14 has a function of transmitting / receiving application data of a VMC session to / from another VLR.

  Next, in this embodiment, how the VMC session is performed by the IP multicast method will be described in detail.

It is assumed that the VLM 1 constituting this VMC session is the VLM 101 having the URL “vlm.jaist.ac.jp” and the corresponding global IP address “10.0.0.101”.
The VLR 2 constituting the VMC session includes a VLR 201 having an IP address “192.168.1.201”, a VLR 202 having an IP address “192.168.2.202”, and an IP address “192.168 .. Assume that the VLR 203 has 3.203 ″. Furthermore, it is assumed that the terminals 301 and 304 are connected under the VLR 201, the terminal 302 is connected under the VLR 202, and the terminal 303 is connected under the VLR 203.

  The VLM 101 manages the VMC session of the channel whose channel identifier is “chat1”. At this time, in the VLM channel information storage unit 4 of the VLM 101, data representing a channel identifier is stored in the record REC1, as shown in FIG.

Assume that the terminal 301 designates “vlm.jaist.ac.jp/cat1” as the VMC-ID and transmits a request to participate in the VMC session to the VLR 201. The VMC session participation / withdrawal request receiving unit 9 of the VLR 201 passes this participation request signal to the IP multicast address management unit 11 and the VMC information management unit 10.
Here, a person who wants to participate in the VMC session such as the terminal 301 specifies the VMC-ID of the VMC session that he / she wants to participate by using some information sharing method such as a home page or a messaging service.

The IP multicast address management unit 11 selects an IP multicast address that is not currently used from among IP multicast addresses that the VLR 201 can use in its own VLR management area B, and uses this for the VMC session. And decide. Assuming that the determined IP multicast address is α, the terminal 301 is notified of this α, while the content of the VMC information storage unit 8 is updated.
FIG. 7A shows the contents of the VMC information storage unit 8 at the time when α is notified. Here, the record IREC1 stores the VMC-ID, the record IREC2 stores the determined IP multicast address, and the record IREC3 stores information identifying the terminal 3 participating in the VMC session.

  On the other hand, the VMC information management unit 10 of the VLR 201 determines that the VMC session requested to participate from the VMC-ID is a VLM whose VLM identifier is “vlm.jaist.ac.jp”, that is, a channel on which the VLM 101 controls and manages communication. Among the channels, it is recognized that the channel has “chat1” as the channel identifier. Then, the VLM channel participation / withdrawal request receiving unit 5 of the VLM 101 is given a participation request signal for the VMC session.

  The VLM channel information management unit 6 of the VLM 101 that has received this signal from the VLM channel participation / withdrawal request receiving unit 5 updates the VLM channel information storage unit 4. The contents of the updated VLM channel information storage unit 4 are shown in FIG. It can be seen that the IP address of the VLR 201 that is the VLR identifier of the VLR 201 is written in the record REC2. Here, although not illustrated, in addition to the VLR identifier, a communication method between VLRs and information necessary for communication are also written.

  The VLM channel information transmission unit 7 of the VLM 101 transmits the contents of the VLM channel information storage unit 4 updated as described above to the VLR 201. As described above, the VLM 101 notifies the updated contents of the VLM channel information storage unit 4 to all VLRs participating in the VMC session identified by the VMC-ID. In this example, since VLR 201 is the only participating VLR at this time, only VLR 201 is notified. The VLR 201 does not update the VMC information storage unit 8 because the transmitted content is not related to other VLRs.

  Next, it is assumed that the terminal 302 designates “vlm.jaist.ac.jp/chat1” as the VMC-ID and transmits a request to participate in the VMC session to the VLR 202. The VMC session participation / withdrawal request receiving unit 9 of the VLR 202 passes this participation request signal to the IP multicast address management unit 11 and the VMC information management unit 10. The IP multicast address management unit 11 determines an IP multicast address that the VLR 202 can use in its own VLR management area B that is not currently used. If the determined IP multicast address is β, this β is notified to the terminal 302, while the contents of the VMC information storage unit 8 are updated. The contents of the VMC information storage unit 8 at the time when β is notified are shown in FIG.

  Note that β can be freely determined as long as it does not overlap within the VLR management area B that is a closed area managed by the VLR 202. The IP multicast address α is previously determined in the area managed by the VLR 201, but it does not matter whether β matches α. This is because the IP multicast address can be freely determined in each VLR management area B which is a closed area. Therefore, it is not necessary for the VLR 201 and the VLR 202 to exchange information regarding the IP multicast address with each other.

  On the other hand, the VMC information management unit 10 of the VLR 202 controls communication by the VLM 1 whose VLM identifier is “vlm.jaist.ac.jp”, that is, the VLM 101, in the VMC session that the terminal 302 has requested to join from the VMC-ID. Among the channels to be managed, it is recognized as a channel having “chat1” as a channel identifier. Then, a participation request signal for the channel is transmitted to the VLM channel participation / withdrawal request receiving unit 5 of the VLM 101.

The VLM channel information management unit 6 of the VLM 101 that has received this signal from the VLM channel participation / withdrawal request receiving unit 5 updates the VLM channel information storage unit 4. The contents of the updated VLM channel information storage unit 4 are shown in FIG. It can be seen that the IP address of the VLR 202 that identifies the VLR 202 has been added to the record REC2.
The VLM channel information transmission unit 7 of the VLM 101 transmits the updated content to the VLR 201 that is the participating VLR 2 and the VMC information management unit 10 of the VLR 202 because the VLM channel information storage unit 4 has been updated as described above.

The VMC information management unit 10 of the received VLR 201 updates the contents of the VMC information storage unit 8 as shown in FIG. It can be seen that the record IREC4 stores the identifier of the VLR 202, which is another VLR newly participating in this VMC session.
Although not shown, in addition to the VLR identifier, a communication method and information necessary for communication with the VLR 202 are also stored.
Further, the VMC information management unit 10 of the newly joined VLR 202 updates the contents of the VMC information storage unit 8 as shown in FIG. It can be seen that the IP address of the VLR 201 which is the other VLR 2 participating in this VMC session is stored in the record JREC4.

Next, it is assumed that the terminal 303 designates “vlm.jaist.ac.jp/chat1” as the VMC-ID, and transmits a request to participate in the VMC session to the VLR 203. The VMC session participation / withdrawal request receiving unit 9 of the VLR 203 passes this participation request signal to the IP multicast address management unit 11 and the VMC information management unit 10.
The IP multicast address management unit 11 determines an IP multicast address that the VLR 203 can use in its own VLR management area B that is not currently used. If the determined IP multicast address is γ, this γ is notified to the terminal 303 while the contents of the VMC information storage unit 8 are updated. The contents of the VMC information storage unit 8 at the time when γ is notified are shown in FIG.

  On the other hand, the VMC information management unit 10 of the VLR 203 controls communication by the VLM 1 whose VLM identifier is “vlm.jaist.ac.jp”, that is, the VLM 101, in the VMC session requested by the terminal 303 to participate from the VMC-ID. Among the channels to be managed, it is recognized as a channel having “chat1” as a channel identifier. Then, a participation request signal for the VMC session is transmitted to the VLM channel participation / withdrawal request receiving unit 5 of the VLM 101.

The VLM channel information management unit 6 of the VLM 101 that has received this signal from the VLM channel participation / withdrawal request receiving unit 5 updates the VLM channel information storage unit 4. The contents of the updated VLM channel information storage unit 4 are shown in FIG. It can be seen that the IP address of the VLR 203 that identifies the VLR 203 has been added to the record REC2.
The VLM channel information transmission unit 7 of the VLM 101 transmits the updated contents to the VLR information management units 10 of the VLR 201, the VLR 202, and the VLR 203 that are the participating VLRs 2 because the VLM channel information storage unit 4 has been updated as described above. .

The VMC information management unit 10 of the received VLR 201 updates the contents of the VMC information storage unit 8 as shown in FIG. It can be seen that the IP address of the VLR 203 newly participating in this VMC session is added to the record IREC4.
The received VMC information management unit 10 of the VLR 202 updates the contents of the VMC information storage unit 8 as shown in FIG. It can be seen that the IP address of the VLR 203 newly participating in this VMC session is added to the record JREC4.
Further, the VMC information management unit 10 of the newly joined VLR 203 updates the contents of the VMC information storage unit 8 as shown in FIG. 9 (2) based on the transmitted information. It can be seen that the IP addresses of VLR 201 and VLR 202 which are other VLR 2 participating in this VMC session are stored in the record KREC4.

  Next, it is assumed that the terminal 304 has designated “vlm.jaist.ac.jp/chat1” as the VMC-ID and has transmitted a request to participate in the VMC session to the VLR 201. The VMC session participation / withdrawal request receiving unit 9 of the VLR 201 passes this participation request signal to the IP multicast address management unit 11 and the VMC information management unit 10. The IP multicast address management unit 11 refers to the content of the VMC information storage unit 8 shown in FIG. 7 (3), and from the fact that there is already a request to join the channel “chat1” from the record IREC1, and from the content of the record IREC2. Recognize that the IP multicast address α has already been assigned. Then, this α is notified to the terminal 304.

On the other hand, the VMC information management unit 10 stores the terminal 304 as a new participating terminal in the VMC information storage unit 8 as shown in FIG. It can be seen that the terminal 304 has been added to the record IREC3.
Here, the VMC information management unit 10 of the VLR 201 does not notify the VLM 101 of information that the terminal 304 has newly joined the VMC session. This is because the VLR 201 has already requested the VLM 101 to join the channel “chat1”. In this way, the VLR 2 notifies the VLM 1 of a request for participation in the VMC session of the VLR 2 itself, not a request for participation in units of individual terminals. This point also shows the feature of this embodiment in which the VLM management area A and the VLR management area B are mutually independent and closed areas.

The processing contents of the VLR 2 when there is a participation request from the terminal 3 to the VLR 2 and the processing contents of the VLM 1 when there is a participation request from the VLR 2 to the VLM 1 have been described.
Next, with reference to FIGS. 10 and 11, how application data, which is the communication content of a VMC session, is transmitted and received between participating terminals will be described.
The arrows shown in FIG. 10 indicate the flow of application data, arrows (a), (c), and (e) represent VLR-terminal communication, and arrows (b) and (d) represent inter-VLR communication. Yes.
In FIG. 11 (1) to FIG. 11 (3), only the fields necessary for the description of this embodiment are shown.

  When data is transmitted from the terminal 301 to the VMC session (arrow (a) in FIG. 10), the IP multicast transmission / reception unit 12 of the VLR 201 receives the data. At this time, the content transmitted from the terminal 301 is roughly divided into application data, an IP multicast address (= α), and an identifier of the terminal 301 that is the sender of the VMC session, as shown in FIG. The The IP multicast transmission / reception unit 12 passes the IP multicast address α, the sender identifier, application data, and reception interface information to the transfer rule determination unit 13 of the VLR 201.

  The transfer rule determination unit 13 refers to the VMC information storage unit 8 shown in FIG. 7 (4) and extracts the VMC-ID “vlm.jaist.ac.jp/cat1” corresponding to the IP multicast address α. Then, another VLR 2 participating in the VMC session is extracted from the record IREC4 in FIG. As a result, the VLR 202 is identified as the VLR 2 to be transferred, and the other VLR 2 information, the VMC-ID, the sender identifier, and the application data are passed to the inter-VLR transfer unit 14.

  The inter-VLR transfer unit 14 of the VLR 201 transfers necessary information to the VLR 202 according to the communication method between the VMC-ID, the identifier of the VLR 201 itself, application data, and other VLRs. The information required according to the communication method includes the IP address of the VLR 202 that is the transfer destination. The communication content between the VLR 201 and the VLR 202 at this time is shown in FIG.

Next, the inter-VLR transfer unit 14 of the VLR 202 receives the transfer data described above from the inter-VLR transfer unit 14 of the VLR 201 (arrow (b) in FIG. 10), and the transfer rule determination unit 13 of the VLR 202 receives the VMC-ID and The identifier of the VLR 201 that is the transfer source and the application data are passed. The transfer rule determination unit 13 of the VLR 202 specifies a VMC session from the VMC-ID in the received data.
Further, the VMC information storage unit 8 shown in FIG. 8 (3) is referred to based on the VMC-ID, and the IP multicast address is recognized as “β”. The IP multicast address “β”, the identifier of the terminal 301 that is the sender of the VMC session, and the application data are passed to the IP multicast transmission / reception unit 12 of the VLR 202.

  As shown in FIG. 11 (3), the IP multicast transmission / reception unit 12 of the VLR 202 transmits application data using IP multicast communication using the VMC sender identifier as the sender and the IP multicast address “β” as the destination. (Arrow (c) in FIG. 10).

Next, transfer of the application data from the VLR 202 to the VLR 203 (arrow (d) in FIG. 10) will be described. The inter-VLR transfer unit 14 of the VLR 202 receives the transfer data received from the inter-VLR transfer unit 14 of the VLR 201 (arrow (b) in FIG. 10) to the transfer rule determination unit 13 of the VLR 202, and the VLR 201 that is the transfer source. Pass the identifier and application data. The transfer rule determination unit 13 of the VLR 202 extracts information on the VMC session and other VLRs participating in the VMC session from the VMC information storage unit based on the VMC-ID in the received data. From this other information regarding the VLR, it is determined that the VLR 203 is a VLR to which application data is to be transferred. Therefore, the transfer rule determination unit 13 uses the identifier of the VLR 203 of the transfer destination, information necessary for communication with the VLR 203, the VMC-ID, the identifier of the terminal 301 that is the sender of the VMC session, and the application data of the VLR 202. The data is transferred to the inter-VLR transfer unit 14, and the inter-VLR transfer unit 14 transfers them to the inter-VLR transfer unit 14 of the VLR 203.
The received application data is transmitted by the VLR 203 to the subordinate terminal 303 using IP multicast (arrow (e) in FIG. 10).

  In communication between VLRs such as data transfer from the VLR 201 to the VLR 202 described above, IP unicast is used. The reason why inter-VLR communication by IP unicast can be performed in this way is because the VLRs 2 participating in the same VMC session acquire other VLR information via the VLM 1.

By the way, in the conventional tunneling technology that encapsulates and transfers IP multicast communication data by IP unicast, the transfer source must know the IP multicast address of the transfer destination. Therefore, when the VLR 201 transfers application data to the VLR 202 by the tunneling technique, the VLR 201 needs to know that the IP multicast address on the VLR 202 side is β.
However, in this embodiment, it is not necessary to know what the IP multicast address used in the other VLR 2 is. This can also be seen from the example shown in FIG. 11B, when the application data is transferred from the VLR 201 to the VLR 202, which does not include the IP multicast address “β” used in the transfer destination VLR 202. However, the VMC-ID is included in the transfer data instead of the IP multicast address. This VMC-ID is converted into the IP multicast address “β” in the VLR 202 of the transfer destination. Therefore, the VLR 201 can transfer the application data of the VMC session to the VLR 202 without knowing that β is used as the IP multicast address in the VLR 202.

  If each VLR 2 can cope with IP multicast communication, it is considered that communication between VLRs may be performed by the IP multicast method. However, when data is transferred between VLRs, another router is usually interposed between these VLRs 2. If one of the routers existing between the VLRs does not support IP multicast communication, IP multicast communication between the VLRs cannot be performed. However, the tunneling technology lacks consideration of the management problem of the IP multicast address as already described.

However, in this embodiment, the problem that there is a router that does not support IP multicast can be solved.
Moreover, in the closed VLR management area B managed by one VLR 2, communication can be efficiently performed using IP multicast communication.

That is, in this embodiment, unlike the existing “group communication method using only IP multicast for transfer”, group communication is realized by combining a plurality of transfer methods of IP multicast and IP unicast. Since this embodiment can efficiently transfer the application data of the VMC session only to the participants, it appears as if the entire system constitutes a virtual link for multicast packets.
By adopting such a method, the problem of IP multicast address management was solved, and the problem of the existence of a network repeater on a network incompatible with IP multicast was also solved.

As described above, the combination of IP multicast communication and IP unicast communication enables the enjoyment of group communication in a network existing in a wide area because the VLM 2 manages the participating terminals 3 and the VLM 1 This is because the participation VLR 2 is divided into areas for management.
The VMC-ID functions to enable cooperation between these two types of areas.

When data is transferred between VLRs, a VMC-ID is added to the data as shown in FIG. The transfer rule determination unit 13 of each VLR 2 refers to its own VMC information storage unit 8 based on the VMC-ID added to the data, and what IP multicast address is subordinate to the VMC-ID. Whether it is assigned to the terminal 3 can be extracted. Therefore, the VLR 2 can efficiently transmit data to the subordinate terminals 3 using IP multicast.
On the other hand, the transfer rule determination unit 13 of each VLR 2 refers to its own VMC information storage unit 8 based on the VMC-ID added to the data, and what other identifiers are associated with the VMC-ID. It is possible to extract whether the VLR 2 possessed participates in the VMC session. Therefore, the VLR 2 can transfer data to other VLRs 2 participating in the same VMC session.
Therefore, application data can be shared among all the participants of the VMC session specified by the VMC-ID.

By the way, in this embodiment, buddy multicast communication in which friends gather in a short time, communicate within the buddy, and dissolve in a short time is taken into consideration. Therefore, participation and withdrawal are frequent.
Therefore, processing of VLM1 and VLR2 when a participant withdraws from this VMC session will be described below.

Assume that the terminal 303 requests the VMR session participation / withdrawal request receiving unit 9 of the VLR 203 to withdraw from the channel “chat1”. The IP multicast address management unit 11 of the VLR 203 deletes the terminal 303 from the record KREC3 from the VMC information storage unit 8, as shown in FIG.
Next, the VMC information management unit 10 of the VLR 203 refers to the VMC information storage unit 8, detects that there is no terminal 3 participating in the channel “chat1”, and detects the VMC-ID from the VMC information storage unit 8. The information regarding the VMC session identified by “vlm.jaist.ac.jp/cat1” is deleted. That is, the records KREC1 to KREC4 in FIG. 9 (3) are deleted.

  On the other hand, since the VLR 203 has no terminal 3 that is managing itself, that is participating in the channel “chat1”, the VLR 203 sends the channel “chat1” to the VLM channel participation / withdrawal request receiving unit 5 of the VLM 101. Request withdrawal from. Based on this withdrawal request, the VLM channel information management unit 6 of the VLM 101 updates the VLM channel information storage unit 4 as shown in FIG. It can be seen that the IP address “192.168.3.203” which is the identifier of the VLR 203 is deleted from the record REC2.

  Next, the VLM channel information transmission unit 7 transmits the updated contents of the updated VLM channel information storage unit 4 to the VLR 201 and VLR 202, and the VMC information management unit 10 of each VLR 2 stores the contents of the VMC information storage unit 8. Is updated as shown in FIGS. 7 (5) and 8 (4). It can be seen that the information regarding the VLR 203 is deleted from both the record IREC4 in FIG. 7 (5) and the record JREC4 in FIG. 8 (4).

In the above embodiment, the VLR 2 can transmit data to the participant terminal 3 managed by the VLR 2 using IP multicast communication, and data transfer between other VLRs uses IP unicast communication. Explained what to do.
This VLR2 function can be applied to a dial-up router as shown in FIG.
By applying VLR to the dial-up router, the network repeater upstream from the dial-up router does not need to support IP multicast.
In addition, since the range in which IP multicast is used is only between the participant terminal 3 for the VMC session and the dial-up router, the IP multicast address is within the area where each dial-up router manages the terminal 3 under its control. Free addresses that do not overlap are available.
That is, for each network under the dial-up router, the IP multicast address can be assigned and managed separately from other networks.

Further, as shown in FIG. 13, the VLR can be applied to an ISP router which is a router of an Internet service provider (hereinafter referred to as “ISP”).
In this case, the network repeater upstream of the ISP router does not need to support IP multicast.
In this application example, the IP multicast address can be freely assigned by the ISP within the area where the network under the ISP router is managed.
That is, it becomes possible to assign and manage different IP multicast addresses for each network under the ISP router.

Furthermore, as shown in FIG. 14, the VLR can be applied to a router closer to the backbone on the Internet.
In this case, the network corresponding to the IP multicast is further expanded.

These application examples of the VLR indicate that management of IP multicast addresses can be performed in a distributed manner.
It also shows that the range that can support IP multicast can be gradually expanded in the network.

  The outline of communication between VLRs is as described above, but no particular mention has been made of optimization of communication paths. Hereinafter, how to determine the optimum communication path based on the quality of the communication line will be described.

  Assume that VLR 201, VLR 202, and VLR 203 participate in the same VMC session as in the example shown in FIG. The numbers with circles in the figure represent network characteristic values. In this example, it is assumed that the network characteristic value indicates RTT (= Round Trip Time). There is a large difference in the RTT value of each VLR network, and communication between VLR 201 and VLR 202 requires 10 times the RTT compared to communication between VLR 201 and VLR 203 or between VLR 202 and VLR 203. .

In this case, it is expected that the application data transferred from the VLR 201 will be distributed to all VLRs faster if the application data is shared using the route W2 than the VLR 202 and the VLR 203 using the route W1. The Therefore, in the example of FIG. 15, W2 is selected as the optimum route.
The network characteristic value is not limited to the above RTT, but may be the number of routers constituting a network between VLRs, or may be a characteristic value of IP communication such as bandwidth, packet loss rate, and jitter.

  As shown in this example, what route is used to realize the communication between VLRs is a problem largely related to the characteristics of the VMC session. In this embodiment, there are two methods for calculating this route: a method in which the VLM performs intensively and a method in which each VLR performs in a distributed manner.

First, a method in which the VLM 1 performs route calculation intensively will be described. When this method is adopted, the block diagram of VLM1 and VLR2 is as shown in FIG. 16. Compared with FIG. Has been.
The inter-VLR communication path management unit 15 of the VLM1 is connected to the inter-VLR network information collection unit 16 of each VLR2 that is participating in any VMC session managed by the VLM1, and the other VLR2 that is participating in the same VMC session. To collect network information. The inter-VLR network information collection unit 16 of each instructed VLR 2 collects information about the network between itself and the other VLR 2. The inter-VLR network information collection unit 16 transmits the collected information to the inter-VLR communication path management unit 15 of the VLM1.
As described above, the network information between the VLRs is collected in the inter-VLR communication path management unit 15 of the VLM 1. The VLM 1 performs route calculation using this, and transmits it to all VLRs 2 participating in the session. As a result, communication between VLRs using an optimum route can be realized.

Next, a method in which each VLR 2 performs route calculation in a distributed manner will be described. When this method is adopted, the block diagram of VLM1 and VLR2 is as shown in FIG. Compared to FIG. 3, an inter-VLR network information collection unit 16 and an inter-VLR communication path management unit 17 are added to the VLM 2.
The inter-VLR network information collection unit 16 reads the information of the other VLR 2 participating in the same VMC session from the VMC information storage unit 8 of its own VLR 2, and collects the information about the network between itself and the other VLR 2. To do. The collected information is stored in the VMC information storage unit 8. The inter-VLR communication path management unit 17 of the VLR reads the inter-VLR network information with the other VLR 2 from its own VMC information storage unit 8, and determines the optimal path for the inter-VLR communication using the information. The determined route is stored in the VMC information storage unit 8.
In this way, each VLR 2 determines a route.

  Each of the above-described two route calculation methods has advantages and disadvantages. The method in which the VLM 1 calculates intensively is suitable for use in a VMC session in which the participation VLR 2 is frequently changed and the number of participants is relatively small. On the other hand, the method in which the VLR 2 calculates in a distributed manner is suitable for use in a VMC session in which the participating VLR 2 does not change so frequently and has a large number of participants.

  Note that the internal configurations of VLM1 and VLR2 in the above embodiment and the functions of each component are merely examples, and the present invention is not limited to these. Further, the configuration of the transmission data shown in FIGS. 11 (1) to 11 (3), the table structure of the VLM channel information storage unit shown in FIG. 4 and the VMC information storage unit shown in FIG. It is not something. These depend on how the software and hardware incorporated in VLM1 and VLR2 are designed and implemented.

It is a basic conceptual diagram which shows the whole structure of embodiment. It is explanatory drawing of VMC-ID. It is a block diagram which shows the internal structure of VLM and VLR. It is a figure which shows the table structure of a VLM channel information storage part. It is a figure which shows the table structure of a VMC information storage part. It is a figure which illustrates the content written in the VLM channel information storage part of VLM. It is a figure which illustrates the content written in the VLM channel information storage part of VLM. It is a figure which illustrates the content written in the VLM channel information storage part of VLM. It is a figure which illustrates the content written in the VLM channel information storage part of VLM. It is a figure which illustrates the content written in the VLM channel information storage part of VLM. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the content written in the VMC information storage part of VLR. It is a figure which illustrates the flow of application data in a VMC session. It is a figure which illustrates the structure of the data transferred in a VMC session. It is a figure which illustrates the structure of the data transferred in a VMC session. It is a figure which illustrates the structure of the data transferred in a VMC session. It is a conceptual diagram at the time of applying VLR to a dialup router. It is a conceptual diagram at the time of applying VLR to an ISP router. It is a conceptual diagram at the time of applying VLR to the router near a backbone. It is a figure explaining the view of route optimization. It is a block diagram which shows the internal structure of VLM and VLR when VLM performs route calculation intensively. It is a block diagram which shows the internal structure of VLM and VLR when VLR performs path | route calculation dispersively.

Explanation of symbols

1 IP multicast communication information management device (VLM)
2 IP multicast transfer device (VLR)
3 Communication device 4 (VLM) VLM channel information storage unit 5 (VLM) VLM channel join / leave request reception unit 6 (VLM) VLM channel information management unit 7 (VLM) VLM channel information transmission unit 8 (VLR) VMC information storage unit 9 (VLR) VMC session join / withdraw request receiving unit 10 (VLR) VMC information management unit 11 (VLR) IP multicast address management unit 12 (VLR) IP multicast transmission / reception unit 13 (VLR) transfer Rule decision unit 14 (VLR) inter-VLR transfer unit A VLM management area B VLR management area

Claims (3)

  A channel management device that connects one or more subordinate communication devices to a network, forms a communication device management area for managing these communication devices, and manages a channel for group communication (hereinafter referred to as “VMC session”); The VMC session data is transmitted / received to / from a device that manages other communication device management areas via a network that supports IP multicast or does not support IP multicast, and is connected to the subordinate communication device. An IP multicast transfer device that transmits VMC session data according to a unique IP multicast address within the communication device management area.   A VMC information storage unit that stores information on the VMC session, and when a request to participate in a specific VMC session and a VMC-ID that is information specifying the VMC session are transmitted from the subordinate communication device, Selects an IP multicast address used for transmitting VMC session data to the communication device, stores the VMC-ID and the IP multicast address in association with each other in the VMC information storage unit, and manages the VMC session Requesting the channel management device to participate in the VMC session, and receiving information on other IP multicast transfer devices participating in the VMC session from the channel management device receiving the request. Is associated with the VMC-ID and the VMC information storage unit On the other hand, when the VMC session data is transmitted from the subordinate communication device, the VMC-ID is extracted from the VMC information storage unit based on the IP multicast address that is the destination of the data, and the VMC -Extracts information related to other IP multicast transfer devices participating in the VMC session specified by the ID, and transfers the data to the other IP multicast transfer devices with the addition of the VMC-ID. When the VMC session data is received from the IP multicast transfer device, the VMC-ID is extracted from the data, the IP multicast address corresponding to the VMC-ID is extracted from the VMC information storage unit, and the received data A subordinate communication device with a multicast address added. Sending to the IP multicast forwarding apparatus according to claim 1, wherein.   Connects to a network repeater on the network via a communication line, manages the channel of group communication (hereinafter referred to as “VMC session”) using IP multicast communication, and connects communication devices participating in the VMC session to the network The IP multicast communication information management apparatus for managing the network repeater includes a storage unit that stores information related to the network repeater in association with the VMC session, and receives a request for participation in the VMC session from the network repeater. Information on the network repeater that has requested to participate in the VMC session is stored in the storage unit in association with a channel identifier that identifies the VMC session, and information on the network repeater is included in the VMC session. All that When a request for withdrawal from a VMC session is received from one of the network repeaters while transmitting to the network repeater, information regarding this network repeater is deleted from the storage unit and all networks participating in this VMC session are also received. An IP multicast communication information management apparatus, wherein the updated contents of the storage unit are transmitted to a repeater.

Images