Network relaying method and device

The present invention relates to a network relay method and an apparatus, and more particularly to a network relay method and an apparatus when data is distributed from a server to a client by multicast.

In recent years, with the rapid spread of personal computers, the corporate network (intranet) has been expanding, and the functions and performance of computers and networks themselves have been improved. In addition, the spread of the web page (WWW), videos, even in a rapidly advancing spread of multimedia data such as voice is being seen. Furthermore, in recent years, broadband networks have become widespread in Internet access including corporate users and general users, and the use of so-called multimedia audio and video, distribution using these, and business forms by broadcasting services have increased. It is coming. Nowadays, the method of distributing data to each user by unicast is often used, and especially in the case of video distribution that is accessed by a large number of users, a large number of data distribution sources are used for the purpose of load distribution. A mechanism is adopted in which a user receives data from a nearby cache server by installing a server or a cache server for each region. This is the same for both on-demand broadcasting and real-time broadcasting, and in order for a large number of users to provide satisfactory quality, many facilities are required and a large amount of investment is required. On the other hand, data transmission using "multicast" technology has begun to be performed in order to efficiently transmit a large amount of data, and it is expected that multimedia data transmission using multicast will become more widespread in the future. Multicast basically cannot perform on-demand distribution, but has many merits in real-time video distribution and audio distribution such as live broadcasting. That is, in multicast distribution, as shown in Fig. 1, the server S1 simply sends one stream to the multicast-enabled network MNW regardless of the number of users (clients) that receive data, and the multicast routers 1_1,1_2 (hereinafter , The data may be collectively referred to by the code "1") or the LAN switches SW1, SW2 (hereinafter, may be collectively referred to by the code "SW") to a large number of clients R1, R2 ... Can be received. Therefore, it is not necessary to provide a cache in each place, and unlike unicast, the bandwidth in each network can be saved. In other words, regardless of the number of users, the traffic volume of a certain route can be kept constant, the influence on other communications is small, and as in the case of unicast, a network, cache server, etc. dedicated to distribution, etc. It is possible to distribute multimedia data at a very low cost without the need for equipment. However, although there is a limitation that the entire network from the server to the client must support multicast, nowadays, all of the relay devices and data distribution servers installed in the network, or the personal computers used by the client Multicast support is almost complete, and it is thought that the rate of use of multicast will gradually increase, especially in real-time broadcast format video distribution and voice distribution. Here, an outline of the multicast data distribution environment and mechanism will be described. Specifically, IP multicast address (group address) and data link layer multicast address, IGMP (Internet Group Management Protocol), which is a protocol between a client (host) and a multicast router, and multicast that builds a multicast distribution tree in a network. Each of the routing protocols will be described. The case where the data link layer is Ethernet will be described. IP multicast distribution uses a multicast address as the address, functions between client R1 and R2 and multicast router 1 as shown in FIGS. 28 (a) and 28 (b), and router 1 is a subordinate client R1 and R2. It is realized by operating IGMP, which provides a function to grasp the multicast group of, and a multicast routing protocol, which builds a multicast data distribution tree from the server to each of a plurality of receiving clients between routers. Here, with IGMP, the router 1 grasps whether or not a receiving client exists in the local network to which the router 1 belongs by exchanging an IGMP message in the packet format shown in FIG. 29 between the clients R1 and R2. It is a protocol to manage. In other words, it is a router-client protocol for telling router 1 that clients R1 and R2 will join a certain multicast group, and both router and client have IGMP (protocol ID in the IP header shown in Fig. 30). It is necessary to implement each function specified in (Applicable in case of "2"). IGMPv1 is Appendix 1 of RFC1112, IGMPv2 is specified in RFC2236, and IGMPv3 is being standardized by the IETF. As shown in FIG. 1, the multicast routing protocol is a network composed of a plurality of multicast routers 1 and layer 3 switch SWs so that the router 1 can deliver a multicast data stream to receiving clients R1 and R2. It is a protocol between routers for route control (or configuration of a route tree) that determines to which interface of router 1 the multicast data is copied and transmitted. The types include DVMRP (used by MBone, specified by RFC1075), PIM (specified by RFC2117, and a new version is under consideration by IETF), MOSPF (operable only on OSPF, specified by RFC1584, 1585), etc. .. The above RFC1112 is a class D IP address, that is, a mapping function between a multicast IP address and a multicast physical address, and a filtering function that receives only packets of a specific multicast physical address and raises them to the upper layer. The correspondence between this multicast IP address and the multicast physical address is that the lower 23 bits of the multicast IP address are the multicast physical address "01.00.5E.00.00.00".₁₆It is specified (RFC1700) to put it in the lower 23 bits of ". For example, the multicast IP address" 239.133.130.34 "becomes the multicast physical address" 01: 00: 5E: 05: 82: 22 ". (IPv4) is defined as a class D address and ranges from "224.0.0.0" to "239.255.255.255" in decimal notation. Figure 31 shows a class D IP address. The class D address is , Identified by the first 4 bits "1110". As shown, some multicast addresses are reserved for specific purposes. Local site allocations, ie "239.0.0.0" to "239.255." Up to 255.255 is an IP multicast address that can be generally used in, for example, a corporate network or an ISP. The procedure for distributing multicast data as described above will be briefly described below with reference to FIG. 28.

[1] Joining the multicast group (1) The multicast router 1 asks the clients R1 and R2 connected to the local network to join the multicast group, so that the IGMP header in the packet of the format (IGMPv2) shown in Fig. 29 "HMQ (Host Membership Query)" message (Fig. 28 (a) 1 ) with the type value of "Ox11" is sent to "224.0.0.1" (All-Systems-Group) on a regular basis. Send. (2) The client wishing to join the multicast group responds to the above "member query" and notifies the multicast address of the group wishing to join by setting the type value in the IGMP header in the packet of the same format. Send the "Ox12" "HMR (Host Membership Report)" message ( 2 in the figure) to the participating multicast address. Upon receiving this, the multicast router 1 grasps the multicast group (identified by the above-mentioned class D address) in which the client participates, and starts transmitting the multicast data (stream) to the local network.

[2] Multicast data distribution (1) On the other hand, the multicast data transmission server (for example, server S1 in Fig. 1) transmits "one" data (stream) to the multicast group identified by the class D address. .. (2) The multicast router 1 in the network transmits the data stream destined for the group while copying it as necessary along the route to each receiving client participating in the multicast group. In other words, the multicast data is distributed along the route tree of the multicast data distribution from the transmitting server to each receiving client, which is configured by the multicast routing protocol. Ultimately, the "one" data stream sent by the server will be delivered to "multiple" clients in the network.

[3] Withdrawal from the multicast group (1) When the client wishing to withdraw from the participating multicast group decides to withdraw, as shown in Fig. 28 (b), Leave Send a message ( 3 in the figure) to 224.0.0.2 (All-Routers-Group). (2) The multicast router 1 that received the "request to leave" message specifies the group address to confirm that there are no other clients participating in the multicast group, and "GS-Q ( Group Specific Query) message ( 4 in the figure) is sent. In this case, if there is a client that is still in the group other than the client that sent the "leave request" message, that client sends a "member join request" message to notify multicast router 1 of its existence. Tell. In this way, while there are many merits in distributing data and contents using multicast, the server does not send data to each client as in the case of unicast, and multicast itself is UDP ( User Data Protocol) Packets are used, making individual user management difficult. Difficulty in management means, for example, that it is possible to grasp the number of receiving clients at a certain point in time, from when to when data was received for each client, and to acquire and manage information on the clients themselves. It means that it cannot be done. Therefore, it is not possible to collect information to consider which content is popular and how many clients have received it, or to charge according to the time when data was received as a service form. It was. Therefore, an object of the present invention is to realize a network relay method and device that manages individual client information that joins / leaves multicast when data is delivered from a server to a client by multicast.

In order to achieve the above object, the network relay method according to the present invention includes the first step of determining the join / leave information transmitted by the client to the multicast group, and the multicast join / leave information of the client. It is characterized by having a second step of processing into notification information and a third step of transferring the multicast participation / departure notification information to a server. The above-mentioned multicast join / leave notification information can include the identification information of the client, the multicast address, and the join / leave start time. Further, in the first step described above, the join / leave information of the client mounted on the multicast control packet from the client is determined, and in the second step described above, the join / leave information of the client is used as the multicast join / leave information. It can be processed into a departure notification packet, and the third step can forward the packet to the server. Further, in the second step described above, when the multicast join / leave notification packet is forwarded to the server, if the join / leave information for the same multicast group is received from another client within a certain period of time, all the clients. It is possible to generate an aggregated join / leave notification packet that aggregates the join / leave information into one packet, and forward the aggregated join / leave notification packet to the server in the third step. Further, when it is determined in the first step above that the multicast join / leave notification packet has been received from the downstream network device, in the third step above, the multicast join / leave notification packet is further transferred to the server. be able to. Further, when it is determined in the first step described above that the aggregated join / leave notification packet has been received from the downstream network device, in the third step described above, the aggregated join / leave notification packet is further transferred to the server. Can be done. Further, when it is determined in the first step above that the aggregate join / leave notification packet has been received from the downstream network relay method, in the second step above, join / leave information for the same multicast group from its own client. In the case of aggregating all of them, an aggregated join / withdrawal notification packet that aggregates all the join / withdrawal information into one packet can be generated, and this can be immediately transferred to the server in the third step. Further, in the third step, the join / leave information of the client can be retained until there is a transfer request from the server. Further, it is also possible to use the source address included in the packet as the above-mentioned client identification information. Further, in the third step described above, when the client does not respond to the periodic inquiry, the withdrawal notification information of the client can be sent to the server. As a device that realizes the above-mentioned network relay method according to the present invention, a discriminating unit that discriminates participation / departure information transmitted by a client to a multicast group and multicast participation / departure notification information of the client's participation / departure information. It is characterized by including an information processing unit for processing the multicast and a transfer processing unit for transferring the multicast participation / departure notification information to the server. The above-mentioned multicast join / leave notification information can include the identification information of the client, the multicast address, and the join / leave start time. Further, the above-mentioned discriminating unit discriminates the participation / leaving information of the client mounted on the multicast control packet from the client, and the above-mentioned information processing unit notifies the joining / leaving information of the client to the multicast joining / leaving notification. It can be processed into packets, and the forwarding processing unit can forward the multicast join / leave notification packet to the server. Further, when the above information processing unit forwards the multicast join / leave notification to the server, if the join / leave information for the same multicast group is received from another client within a certain period of time, the information processing unit of all the clients. An aggregated join / leave notification packet that aggregates the join / leave information into one packet can be generated, and the forwarding processing unit can forward the aggregated join / leave notification packet to the server. Further, when the discriminating unit determines that the multicast join / leave notification has been received from the downstream network device, the forwarding processing unit may further forward the multicast join / leave notification packet to the server. it can. Further, when the discriminating unit determines that the aggregated join / withdrawal notification packet has been received from the downstream network device, the forwarding processing unit further forwards the aggregated join / withdrawal notification packet to the server. Can be done. Further, when the above-mentioned discriminating unit determines that the aggregated join / leave notification packet has been received from the downstream network relay device, the above-mentioned information processing unit receives join / leave information for the same multicast group from its own client. When aggregated, an aggregated join / leave notification packet that aggregates all the join / leave information into one packet can be generated, and the transfer processing unit can immediately transfer this packet to the server. In addition, the transfer processing unit can hold the join / leave information of the client until there is a transfer request from the server. The source address included in the packet can be used as the above-mentioned client identification information. Further, the transfer processing unit can send the withdrawal notification information of the client to the server when the client does not respond to the periodic inquiry. Further, a server is configured by a discriminating unit that discriminates the multicast participation / departure notification information transmitted from the network relay device and a holding unit that extracts and holds the client information in the multicast participation / departure notification. Can be done. Then, this server can have a means for performing hourly billing for multicast data distribution (content reception) based on the information of the client. The network relay method and apparatus according to the present invention described above will be described below with reference to the drawings. FIG. 1 shows an example of a network configuration for explaining the concept of the present invention. In the figure, S1 is a multicast data transmission server, 1_1 and 1_2 are multicast (corresponding) routers that implement the network relay method and device of the present invention, SW1 and SW2 are LAN switches or layer 2 switches that accommodate clients, and MNW is multicast. A network composed of routers, R1 is a client that normally receives data, R2 is a client that receives multicast data, PKT1 is a multicast control packet that functions between receiving clients R1 and R2 and multicast router 1_2, and PKT2 is a receiving client. It is a user information packet that is transferred to the server toward S1 including join or leave (hereinafter referred to as join / leave) information. Packets PKT1 and PKT2 may also be collectively referred to as PKT. Further, FIG. 2 shows a principle configuration diagram of the network relay device 1 of the present invention, which is a router that normally implements the multicast function. This network relay device 1 includes transmission / reception interfaces 2, 7 and 8, a discrimination unit 3 of the multicast control packet PKT1, a generation unit 4 of the client management information packet PKT2 for notifying the server S1 of user information, and a routing table. It is composed of a transfer processing unit 5 that performs routing processing (including multicast routing processing) implemented in a normal network relay device including 6. In operation, when the reception client R2 is connected to the transmission / reception interface 2 via the LAN switch SW2, the reception client R2 indicates that it wants to receive multicast data (multicast group participation desire), or it has received so far. However, the multicast control packet PKT1 for notifying the multicast router 1 that the reception is to be stopped (multicast group departure request) is transmitted, and the multicast router 1 receives this. The multicast router 1 inspects what the received packet is by the packet discriminating unit 3. If it is the multicast control packet PKT1, it is sent to the forwarding processing unit 5 for normal multicast data forwarding control, and the information is reflected in the routing table 6. At the same time, in order to enable the server S1 to manage the user information, the packet generation unit 4 generates a multicast join / leave notification packet that stores the user information, sends it to the forwarding processing unit 5, and sends the direction in which the server S1 exists. Transfer from interface 7 or 8 of. When this arrives at the server 51, it is possible to realize data reception user management that was not possible with conventional multicast data transfer.

FIG. 1 is a diagram showing a network configuration example for explaining a network relay method and an apparatus according to the present invention. FIG. 2 is a block diagram of the principle configuration of the network relay device according to the present invention. FIG. 3 is a diagram showing a network configuration example for explaining an embodiment of the present invention. FIG. 4 is a simplified diagram of the network configuration example of FIG. FIG. 5 is a block diagram showing an embodiment of the network relay device according to the present invention. FIG. 6 is a format diagram of the multicast participation notification packet. FIG. 7 is a diagram showing a multicast participation notification sequence to the server and a receiving client management table managed by the server. FIG. 8 is a diagram showing an example of a network when aggregating client information. FIG. 9 is a format diagram of the multicast aggregate participation notification packet. FIG. 10 is a diagram showing a multicast aggregate participation notification sequence to the server and a receiving client management table. FIG. 11 is a diagram showing an example of an aggregated network of information of a multicast aggregate participation notification packet and a multicast participation request message from the downstream. FIG. 12 is a format diagram of a multicast aggregate participation notification packet to which information is added in the middle of the route to the server. FIG. 13 is a diagram showing an information addition sequence to the multicast aggregate participation notification packet and the receiving client management table. FIG. 14 is a block diagram showing an embodiment of a server (when both client management and a multicast data transmission server are used). FIG. 15 is a format diagram of a multicast (aggregate) participation notification packet identified by the protocol ID field. FIG. 16 is a format diagram showing the IP header in FIG. FIG. 17 is a format diagram of the multicast exit notification packet. FIG. 18 is a diagram showing a multicast exit notification sequence to the server and a receiving client management table. FIG. 19 is a format diagram of the multicast aggregation withdrawal notification packet. FIG. 20 is a reception client management table diagram at the time of multicast aggregation withdrawal managed by the server. FIG. 21 is a format diagram of a multicast aggregation withdrawal notification packet to which information is added in the middle of the route to the server. FIG. 22 is a reception client management table diagram managed by the server with respect to FIG. FIG. 23 is a general format diagram of an ICMPv6 message. FIG. 24 is a general format diagram of an MLD message. FIG. 25 is a diagram showing an outline of detection of client failure, notification to the server, and update of the management table. FIG. 26 is a conceptual diagram of an hourly billing service when multicast contents are used. FIG. 27 is a diagram showing an example of a multicast content distribution service and an hourly billing system using the present invention. FIG. 28 is a diagram for explaining a general multicast join / leave procedure of IGMP. FIG. 29 is a general format diagram of an IGMPv2 packet. FIG. 30 is a general format diagram of the IPv4 header. FIG. 31 is a diagram illustrating allocation of multicast addresses according to purpose of use.

Code description

1 (1_1 ~ 1_7) Multicast router (network relay device) 2,7,8,21 Transmission / reception interface 3 (3_1 ~ 3_3), 22 Packet discriminator 4 Packet generator 5 Forwarding processing unit 6 Routing table 9 Multicast processing unit 10 Timer 11 Client information holder 23 Client management table S1, S11 ~ S13 Server MNW Multicast compatible network PKT (PKT1, PKT2, PKT2_1, PKT2_2, PKT_21, PKT_22) Packet SW (SW1, SW2) LAN switch CMP1 ~ CMP3 Client management information packet R1 ~ R3, R11 ~ R14 Client DT Multicast data In the figure, the same code indicates the same or equivalent part.

Hereinafter, examples of the network relay method and the apparatus according to the present invention will be described. Regarding the multicast control message, the case of the above-mentioned IGMPv2 (specified in RFC 2236) message, which is the most widely used and widely implemented, will be described, but the present invention is also applied to the case where the multicast control message is IGMPv1 and IGMPv3. It is possible. In the case of IPv6, the function equivalent to IGMPv2 is called MLD (Multicast Listener Discovery) and is specified in RFC2710. In addition, the functions equivalent to IGMPv3 are being standardized by the IETF. In this embodiment, the case where the network layer is IPv4 will be described, but of course, it can also be applied to the case of IPv6. The difference between IPv6 and IPv4 multicast will be described later. Figure 3 shows the corporate IP network and ISP (Internet Service) targeted by the present invention. Indicates a general IP network such as a provider) or a carrier's IP network. As in Fig. 1, clients R1 to R3 such as personal computers and multicast-compatible routers 1_1 to 1_8 (hereinafter referred to as "1") that make up the network are shown. It is composed of the server S1 that distributes and manages multicast data by the multicast routing protocol MRP. In addition, as shown in Fig. 1, clients R1 to R3 are housed in a LAN switch / Layer 2 switch and connected to a multicast router 1, which is common in both enterprises and Internet access, but the figure is simplified. Not shown to do. The client management information packets CMP1 to CMP3 shown in the figure are composed of the packets PKT1 and PKT2 in FIG. 1, respectively.<u style="single">Example [1]</u> FIG. 4 is a simplified representation of the embodiment [1] of the present invention in the network configuration example of FIG. 3, in which the client R1 sends a multicast participation packet PKT1 to the multicast router 1 and responds to the multicast participation packet PKT1. The multicast router 1 shows that the multicast participation notification packet PKT2_1 is sent to the server S1 and that the server S1 is sending the multicast data DT. The IGMP packet format and the IGMP message field are as shown in FIG. 29, and the IPv4 header shown in FIG. 30 may be used. Further, FIG. 5 shows an embodiment configuration of a multicast router, a multicast-compatible layer 3 switch, and the like, which are the network relay devices of the present invention shown in principle in FIG. In the figure, the packet discriminating units 3_1 to 3_3 (hereinafter, may be collectively referred to by the reference numeral "3") are multicast participation request messages (IGMP Report) and departure request messages (IGMP) from the client. The Leave message) is detected and sent to the known multicast processing unit 9 that performs multicast control, and also sent to the timer 10 and the client information holding unit 11. The timer 10 is used together with the client information holding unit 11 and the packet generating unit 4 when generating the join / leave information notification message (packet) in which the client information is aggregated, as will be described later. Hereinafter, the operation of the network relay device 1 shown in FIG. 5 will be described with reference to FIGS. 3 and 4. First, the network relay device 1 grasps the information of the multicast data receiving clients R1 to R3 existing under each of its own interfaces 2, 7, and 8. Specifically, the packet discriminator 3 inspects the packets transmitted from the clients R1 to R3 that want to receive the multicast data, and if the packet contains an IGMP participation request (report) message, it is received under the receiving interface. Recognize that the client exists. The method of identifying the message requesting to participate in IGMP is that (1) the IP address is a multicast address, (2) the "protocol number" in the IP header is "2" indicating IGMP, and then (3) IGMP. Make sure the message type value is "Ox16". As shown in FIG. 29, the multicast addresses (group addresses) that the receiving clients R1 to R3 want to receive are stored in the IGMP participation request message. The network relay device 1 uses the packet generator 4 to manage the destination address (see FIG. 30) so that the server S1 can manage that the client that is the source of this message wants to receive the multicast data (multicast participation request). Is used as the address of the server S1 to generate the multicast participation notification packet PKT2_1, and the transfer processing unit 5 forwards the packet to the server S1 by normal routing processing. At this time, when the server S1 receives this, the type value of the IGMP message is changed and transmitted so that it can be identified as the multicast participation notification message. That is, as shown in Fig. 29, there are two standard IGMP message type values: version 1 (IGMPv1), version 2 (IGMPv2), and version 3 (IGMPv3) (IGMPv3 is a standardization body for Internet technology. IETF (Internet Engineering Task Force) is working on standardization), but in the present invention, the multicast participation notification message shall be identified by setting a type value other than the above. This type value will be described later. The IGMP participation request message indicating that the clients R1 to R3 want to receive the multicast data DT1 to DT3 is sent to the address that they want to receive (in IGMPv3 under consideration, it is sent to "224.0.0.22". ) Receives an IGMP participation request message in the network relay device 1 so that the server S1 can manage the information of the receiving clients of the multicast data DT1 to DT3, the destination address field is replaced with the server address, and the server S1 Send to. At this time, since the "maximum response time field" of the IGMP message shown in FIG. 29 is unnecessary for processing, a method such as setting it to "0" can be considered. It is also desirable to set the "checksum" to a value calculated again for the integrity of the data. By including the multicast address G1 that the client is requesting to receive in the group address, for example, when the same client wants to receive a plurality of different multicast addresses, it can be managed separately. FIG. 6 shows the format of the multicast participation notification packet PKT2_1 sent from the client relay device 1 to the server S1 as described above, and the received client information includes the address of the client R1 wishing to participate in the multicast and the start of participation. Time t1 is installed. Upon receiving this, the server S1 confirms the message type, and if it is a participation notification message, the server S1 sends the address of the client R1 stored in its source address field (see FIG. 30). By storing the multicast data in association with the address G1 and the reception time t1 of the participation notification packet, it is possible to manage which multicast data (here G1) started to be received (here t1) by the client R1. .. At this time, the network relay device 1 accommodating the receiving client R1 on its interface cannot know the addresses of the multicast address G1 and the server S1 until the multicast data is received. Therefore, in actual operation, if dummy multicast data with a small amount of traffic is sent before the actual multicast content is transmitted, the network relay device 1 recognizes the relationship between the multicast address G1 and its server S1. It is possible to grasp the relationship between G1 and S1 and send the information R1 and G1 to the server S1 when receiving the IGMP participation request message from the client R1. As a matter of course, since the multicast session is distinguished by the multicast address, if an IGMP participation request message for the multicast address G2 is received in addition to G1, the processing will be performed in parallel with G1. Figure 7 (a) illustrates the above operation sequence. When the client R1 sends an IGMP join request packet PKT1 (Figure 7 (1)), the multicast router 1 that receives this packet notifies the multicast join. When the packet PKT2_1 is generated (Fig. (2)) and the packet PKT2_1 is sent to the server S1 via the multicast-enabled network MNW (Fig. (3)), the server S1 is a table for client management. Is created (Fig. (4)). An example of the table at this time is shown in Fig. (B).<u style="single">Example [2]</u> Normally, a network relay device has a plurality of interfaces 2, 8 and 7 as shown in FIG. 5, and subnets are connected to each of them as shown in FIG. 8, and a large number of clients are connected to each subnet. If the target network is large, many participation notification messages PKT2 will be sent to the server S1 side, and it is sufficient if they are distributed in time, but if they are concentrated, the processing load will be imposed on the server S1. .. Therefore, it is desirable that the information of the receiving clients under the control of each network relay device 1 is aggregated, and the information of a plurality of clients is included in one packet and transmitted in a batch. For example, the network relay device 1 operates the timer 10 when a reception request control message for the multicast address G1, that is, an IGMP participation request message is received. The same (multicast) group address received by the time this timer 10 expires is the information of all the target IGMP join message, that is, the source address of each receiving client is the client of one packet as shown in the packet format of FIG. Include it in the information and send it to the server as an aggregate participation notification message PKT2_2. As for the method of determining the timer value, for example, if the administrator who transmits the multicast data on the server wants to manage the information every minute for the purpose of billing, the timer value may be set to 60 seconds. Also, at this time, in order to show that this is different from the normal IGMP participation request message and also different from the above participation notification message, it is not specified as standard in the type field of the IGMP participation request message, and the above participation notification message also Use no type value. FIG. 10A illustrates an outline of the operation sequence between the clients R1 to R1, the multicast router 1, and the server S1. When the IGMP participation request packet is transmitted from the client R1 (Fig. (1)), the timer 10 is started by the multicast router 1 that receives it (Fig. (2)), and then the same applies from the clients R3 and R2. When the packet of (Fig. (3), (4)) is received, an aggregate participation notification packet is generated (Fig. (6)) on condition that the timer 10 has expired (Fig. (5)). This packet is sent to the server S1 (Fig. (7)). Server S1 creates a client management table accordingly (Fig. (8)). Figure (b) shows an example of a table of information held by server S1 at this point. Note that "xx", "tx", etc. in the figure indicate the state of having the status related to other multicasts and clients.<u style="single">Example [3]</u> As shown in FIG. 11, when the aggregate participation notification message PKT2_21 is transmitted from a certain network relay device 1_2 toward the server S1, it is received by the network relay device 1_1 in the next stage in the server direction. This network relay device 1_1 inspects the packet PKT2_21, and if it is an aggregate participation notification message, further forwards it to the server S1 direction. At this time, the network relay device 1_1 may also have a receiving client on the local interface like the network relay device 1_2. Assuming that the network relay device 1_1 receives the participation request message regarding the multicast data G1 from the receiving clients R11 to R14 and the timer 10 is operating for information aggregation, the aggregation participation regarding the multicast data G1 from the network relay device 1_2 is performed. When the notification packet PKT2_21 is received, the timer 10 is canceled to avoid delaying the information of the network relay device 1_2 and delivering it to the server S1, and the local network relay device 1_1 previously held for the multicast data G1. The information of the receiving clients R11 to R14 of the above is added to the received aggregated participation notification packet PKT2_21 to generate the packet PKT2_22, which is immediately transmitted. FIG. 12 shows the format of the aggregated participation notification packet PKT2_22 transmitted from the network relay device 1_1. If the network relay device 1_1 does not receive the IGMP participation request message from the local receiving clients R11 to R14 before receiving the aggregated participation notification packet PKT2_21 from the network relay device 1_2, the interface in the server direction is used as it is. Transfer to. In addition, these operations are performed independently for each multicast address. FIG. 13 (a) illustrates the sequence at this time, and the network relay device 1_1 activates the timer when it receives the multicast participation packet from the client R11 (Fig. 13 (1)) (Fig. 13 (2)). ), And after receiving the multicast participation packet from the client R12 (Fig. (3)), when the aggregate participation notification packet is received from the network relay device 1_2 (Fig. (4)), the timer is forcibly terminated (Fig. 3). (5)), the participation information of clients R11 and R12 is added to the aggregated participation notification packet PKT2_21 from the network relay device 1_2 and immediately transmitted (Fig. (6)), and in response to this, a table is created on server S1 (same). Figure (7)). Figure (b) shows an example of the table managed by server S1 at this time.<u style="single">Server example</u> As shown in FIG. 14, the server side also has a packet discriminating unit 22 that inspects and identifies the packet as a user information packet, and if applicable, starts receiving the client information and status in the client management table 23, for example, in minutes. Record the time. Based on this information, the management application 24 can grasp the number of users and the information for hourly billing calculation. Further, when the number of users is large, it can be used as reference information for the design of the server site, for example, adding servers having the same contents. In the illustrated example, the case where the server serves as both receiver management and transmission of multicast data is shown. In addition, the communication process 25 and the application 26 drive the multicast transmission control unit 27 to send the multicast data DT from the content 28 to the multicast-compatible network from the transmission / reception interface 21.<u style="single">Packet variant</u> Furthermore, regarding the multicast participation notification packet and the aggregate participation notification packet, as shown in FIGS. 9 and 12, the IGMP participation request message received from the client is diverted for the transmission of necessary information, and has a unique format. It may be an IP packet. For example, as shown in FIG. 15, multicast data address information may be included in the payload portion for the data link layer header (for example, MAC header) and the IP header. At this time, it is sufficient if there is a method for identifying that it is a participation notification packet or an aggregate participation notification packet. For example, as shown in FIG. 16, a value currently not specified for the protocol ID of the IP header is used. , It can be identified by checking this. Well-Known protocol IDs are managed by IANA (Internet Assigned Numbers Authority) or ICANN (The Internet Corporation for Assigned Names and Numbers), so if you apply for a message, you can use it in actual operation. is there.<u style="single">Example [4]</u> When the receiving client stops receiving the multicast data, it sends a normal leave request message (packet), that is, "IGMP Leave". IGMPv2 uses the IGMP leave request message, and IGMPv3 uses the IGMP join request message (sent to "224.0.0.22" indicating the ALL-IGMPv3 router) with the multicast address desired to be received set to "empty". .. In order to manage the receiving client, the information such as "which client stopped receiving when" is also managed by the server. The withdrawal information is basically the same as the above participation information. The following description shows an example of IGMPv2. The exit request message sent by the client that has received the multicast data so far is sent to "224.0.0.2", which is the "All-Routers-Group address" (Note that the "Multicast address that you want to receive is" The "empty" IGMP participation request message "will be sent to" 224.0.0.22 ".). Upon receiving this, the network relay device 1 inspects whether or not it is an IGMP exit request message by the packet determination unit 3. The method of identifying the IGMP exit request message is as follows: (1) The IP address is "224.0.0.2", (2) "Protocol number" in the IP header is "2" indicating IGMP, and (3) Make sure that the type value of the IGMP message is "Ox17". Similarly, the multicast address that the receiving client wants to leave is stored in the IGMP leave request message. In the network relay device 1, the packet generator 4 sets the destination address to the address of the server S1 in order to inform the server S1 that the client that is the source of this message wants to stop receiving the multicast data that has been received so far. The leaving notification packet is generated, and the forwarding processing unit 5 forwards it to the server S1 by normal routing processing. At this time, the type value of the IGMP message is changed and sent so that the server S1 can identify that it is a withdrawal notification message when it receives it. An example of the format of such a departure notification packet is shown in FIG. Upon receiving this, the server S1 confirms the message type, and if it is a departure notification packet, the address of the client R1 stored in the source address field and the address G1 of the multicast data transmitted by the server S1. By associating and adding the reception time t2 of the exit notification packet, it is possible to manage when the client having the address R1 stopped receiving the multicast data (G1 in this case) (t2 in this case). Further, regarding the client R1, as described above, the server S1 holds the information that the data transmitted by the client R1 to the multicast address G1 is started from the time t1 (that is, "R1, G1, t1"). By associating this with the departure start time t2, the time "t2-t1" received by the client R1 can be calculated. That is, it indicates that the client R1 received the multicast data G1 during (t2-t1). As described above, the sequence is the same as that of the above-mentioned IGMP participation request message, and is shown in FIGS. 18 (a) as procedures (1) to (4) as in FIG. 7 (a). In addition, an example of a table managed by the server S1 is shown in FIG. 18 (b), and as shown in the figure, the departure time information and the received time information are added.<u style="single">Example [5]</u> As a matter of course, the network relay device 1 has a plurality of interfaces 2, 7 and 8 as shown in FIG. 5, and as shown in FIG. 8, subnets are connected to each, and a large number of clients are connected to each subnet. ing. If the target network is large, many withdrawal notification messages will be sent to the server side, and if they are sent in a concentrated manner, the processing load may be imposed on the server S1. Therefore, as in the case of multicast participation information, it is conceivable that each network relay device 1 aggregates the withdrawal information of the receiving clients under its control and collectively transmits the information of a plurality of clients in one packet. For example, the network relay device 1 operates the timer 10 when the exit message for the multicast address G1, that is, the IGMP exit request message is first received. Information on all IGMP exit wish messages received by the expiration of this timer 10, that is, the source address of each receiving client is included in the client information of one packet and multicast aggregated to the server as shown in the packet format of FIG. Send as a withdrawal notification message. As for the method of determining the timer value, for example, if the administrator who transmits the multicast data on the server wants to manage the information every minute for the purpose of billing, the timer value may be set to 60 seconds. After the timer expires, the timer 10 is started when the IGMP exit request message is received again. Also, at this time, in order to show that this is different from the normal IGMP withdrawal request message and further different from the above-mentioned withdrawal notification message, the type field of the IGMP withdrawal request message is not specified as standard, and the above-mentioned participation notification is not specified. An IGMP type value that is different from the message, the aggregate participation notification message, and the above withdrawal notification message may be used. Furthermore, since the "maximum response time field" of the IGMP message shown in FIG. 29 is unnecessary for processing, a method such as setting it to "0" can be considered. In addition, it is desirable to set a newly calculated value for the "checksum" for the sake of data integrity. By including the multicast address G1 that the client is requesting to stop receiving in the group address field, for example, if the same client is receiving multiple different multicast addresses and you want to stop receiving them, you can distinguish them from each other. Can be managed. FIG. 19 shows an example of the format of the aggregate withdrawal notification packet including the information when the three receiving clients R1 to R3 leave the multicast group G1 almost at the same time. FIG. 20 also shows the client management table 23 when the server S1 receives this aggregated exit notification packet.<u style="single">Example [6]</u> As shown in FIGS. 11 and 13 for the IGMP participation desired packet, when the aggregate departure notification message is also transmitted from the network relay device 1_2 toward the server S1, it is sent to the network relay device 1_1 in the next stage in the server direction. Received. The network relay device 1_1 inspects the packet, and if it is an aggregate withdrawal notification message, further forwards it to the server. At this time, the network relay device 1_1 may also have a receiving client on the local interface like the network relay device 1_2. Assuming that the network relay device 1_1 receives the IGMP exit request message regarding the multicast G1 from the receiving clients R11 to R14 and operates the timer 10 for information aggregation, the aggregation regarding the multicast data G1 from the network relay device 1_2 is performed. Suppose that a participation notification packet is received. At this time, the timer 10 is canceled in order to avoid delaying the information of the network relay device 1_2 and delivering it to the server S1, and the local receiving client R11 previously held by the network relay device 1_1 for the multicast data G1. The information of ~ R14 is immediately transmitted in addition to the received aggregate participation notification packet. If the network relay device 1_1 has not received the withdrawal request message from the local receiving clients R11 to R14 before receiving the aggregated participation notification packet from the same 1_2, it is forwarded to the interface in the server direction as it is. In addition, these operations are performed independently for each multicast address. This is because in FIG. 11, when the network relay device 1_1 receives the departure request message from the directly connected client such as the clients R11 to R14 and the timer 10 is started for information aggregation, the network relay device 1_2 is the server. The aggregate withdrawal notification packet is transmitted in the direction, the timer 10 is stopped when it is received by the network relay device 1_1, and the information of clients R11 to R14 is added to the aggregate withdrawal notification packet from the network relay device 1_2 immediately. The operation is to transfer to the server S1. In this case, FIG. 21 shows an example of the format of the aggregate withdrawal notification packet transmitted from the network relay device 1_1. Further, FIG. 22 shows the state of the client management table 23 of the server S1 when the aggregated withdrawal notification packet is received.<u style="single">Client identity</u> Although the reception client management in multicast data distribution has been described above, it is most convenient to identify each client by the IP address of the client. That is, it is possible to use the IP address which is the source (source) address of the IGMP participation desired packet or the IGMP withdrawal desired packet transmitted from the user side. For example, in the case of a dial-up user, an IP address is assigned to the personal computer in the user's home from the ISP (Internet Service Provider) contracted by the user, so use this, or use FTTH (Fiber to the Home) or ADSL ( For broadband access such as Asymmetric Digital Subscriber Line), an address is assigned to the outward interface of a small router (SOHO (Small Office Home Office) router) in the user's home, which can be used. Of course, ISP address assignment is performed together with information such as "which IP address was assigned to which user from when to when" for billing management. Therefore, by combining this information with the IP address information of the multicast receiving client and the receiving time (t2-t1), it is possible to calculate the hourly charge for the multicast content. At this time, suppose that there is a SOHO router in the user's house, there are multiple terminals inside, and both terminals are receiving the same multicast, and one terminal sends a withdrawal message, that is, an IGMP withdrawal request message. , The network relay device (multicast router) receives it, and in order to check whether there is still a client who wants to receive the multicast data under the interface, the GS-Q described in Fig. 28 (b) is explained. (Group Specific Query) message is sent. Another client in the user's home that received this via the SOHO router sends a new participation request message to indicate the desire to continue receiving, and the same address, that is, the address assigned to the SOHO router, is received. It will remain as client information and will not be unreceivable. In other words, it works without problems in the current form of Internet access and broadband access environments such as ADSL and FTTH, which are expected to increase in the future.<u style="single">Batch transmission of management information</u> The method and device for managing the receiving client by transferring the information of the client's participation and withdrawal to the server based on the IGMP join / withdrawal message sent by the client side have been described above. Apart from this, it is usually conceivable to store and store client information in a network relay device accommodating a plurality of clients, and collectively send the management information to the management server when the management information is needed. In this case, the processing load of client management on the server side can be reduced. In a general intranet or Internet access end-user accommodating network form, as shown in Fig. 1, each receiving client R1 and R2 are accommodated in LAN switch / layer 2 switches SW1 and SW2, and further upstream network. It is connected to a relay device (multicast). At this time, each network relay device holds the information of the receiving client under each interface and the information of which multicast address the data was received from when to when by the above-mentioned means. That is, when the IGMP participation request message is received, the IP address of the receiving client, the requested multicast address G1 and the participation time t1 are recorded. When the IGMP withdrawal request message is received from the same receiving client, the time t2 at which the IGMP withdrawal request message is received is added to the client address information. If this is done for each multicast on each interface, the information required for management can be obtained. The management information collected by each network relay device for each local subnet connected to itself is not immediately transmitted to the server, but is configured as a network, for example, when the multicast session ends. Collectively sends the information of the receiving client that it holds to the business operator or the management server such as the ISP that provides the service. Alternatively, when the multicast session ends, it may be transmitted by a method such as transmitting information about the multicast or by a command from the server side. As a result, if it is not necessary for the server side to grasp the information of the receiving client in real time, the operation and management of the server side can be easily performed by collectively transmitting the multicast data at a certain point after the transmission is completed. become. Of course, this information can be used for purposes such as hourly billing calculation for each user and survey of the number of receiving users (audience rating). The above-mentioned local user information retention function may be provided in the LAN switches SW1 and SW2 in the figure or in the multicast routers 1_1 and 1_2 with reference to FIG.<u style="single">Setting the IGMP type value</u> Although one embodiment of the present invention has been described above, the IGMP type values that identify the participation notification packet, the aggregation participation notification packet, the departure notification packet, and the aggregation departure notification packet are used in the standard shown in FIG. A value that has not been set may be used, for example: -Join notification packet: Ox31-Aggregate participation notification packet: Ox32-Departure notification packet: Ox33-Aggregate departure notification packet: Ox34. The present invention is also applicable to IPv6 multicast, but the main differences from IPv4 multicast are shown below. (1) The multicast MAC address is generated by mapping the lower 32 bits of the 128-bit IPv6 address to the 48-bit MAC address 33: 33: xx: xx: xx: xx. (2) For MLD equivalent to IPv4 IGMP, use the ICMPv6 message (specified in RFC2463) shown in Fig. 23, ICMPv6 type value "130" is an IGMP query (Query) message, and "131" wants to participate ( Report) Message, "132" is Done (same as requesting to leave IGMP) (see Figure 24). (3) The IPv6 multicast address is identified by FFOX: 0: 0: 0: 0: 0: 0: 0 (the first 8 bits are 11111111). It is also applicable to environment multicast.<u style="single">Example [7]</u> Although the receiving client can be managed by the above method, the withdrawal message, that is, the IGMP withdrawal request message cannot be sent when the reception cannot be received due to the client OS failure or the media playback application hangs. In this case, accurate client withdrawal management cannot be performed. An example for solving this problem will be described below. Normally, the multicast router periodically sends an IGMP query (Query) message to the All-Systems Group address 224.0.0.1 (default 125 seconds), and each receiving client receives this query message. And send an IGMP participation request message. In many cases, the above-mentioned IGMP participation request message is voluntarily transmitted when the client decides to receive the multicast data, and is not transmitted in response to the IGMP inquiry message periodically transmitted from the network relay device. In many cases, the client is regularly monitored for survival by the IGMP participation request message sent in response to the regularly sent IGMP inquiry message. This is the normal standard behavior. If a receiving client cannot receive due to an OS failure or a media playback application hangs, it will not respond to the IGMP inquiry message that is periodically sent from the network relay device, and will not send the IGMP participation request message. In the network relay device, the receiving client that no longer responds to the IGMP inquiry message is regarded as the reception stop, the withdrawal time is entered in its own client management table, the status is described as "reception stop / error", and the withdrawal for that client is performed. By generating a notification message and sending it to the server S1, client management that responds to such failures becomes possible. In this case, as described above, the information is often written in the IGMP participation request message that the client voluntarily sends when it decides to receive the multicast data, but the IGMP inquiry message that is sent periodically The operation is to wait for the receipt of the IGMP participation request message in response to and confirm the existence. If you want to manage the client accurately in 1-minute units, you can set the timer for the inquiry message that is sent regularly from the default of 125 seconds to 60 seconds. For example, in units of 10 minutes, the default value is sufficient. If the client starts receiving, the start time and the subsequent withdrawal time may be reflected in the management table. Further, when the management table is held in the network relay device, the information may be reflected in the management table of the network relay device and collectively transmitted to the server at a certain opportunity. Alternatively, as another means, there is also a method of confirming the existence of each receiving client by Ping. An overview of this is shown in Figure 25. That is, the figure (a) can be divided into three phases PS1 to PS3. In the phase PS1, since the group joins, the client R1 sends an IGMP join request packet (figure (1)), and the multicast router 1 generates a participation notification packet (Fig. (2)) and transmits the packet to the server S1 via the multicast-compatible network MNW (Fig. (3)). The server S1 creates the client management table 23 from this (Fig. (4)). Phase PS2 indicates the failure detection phase, and if multicast router 1 is sending query messages on a regular basis (Figure (5)), assuming that client R1 is in a failed state, client R1 will respond to that query. On the other hand, the IGMP participation request packet cannot be sent (Fig. (6)). As a result, the multicast router 1 detects that the client R1 is in a failed state and writes that fact in its client management table (Fig. (7)). Then, the multicast router 1 generates a departure notification packet for the client R1 (Fig. (8)) and sends it to the server S1 (Fig. (9)). On server S1, the management information about client R1 is updated (Fig. (10)). Phase PS3 indicates the reception resumption phase, and after the failure is recovered, client R1 sends an IGMP join request packet (Fig. (11)), and in response, multicast router 1 generates a join notification packet (). Figure (12)) and transmission to server S1 (Figure (13)). The client management table is updated on server S1 (Fig. (14)). As a result, the information about the client R1 in the client management table 23 on the server S1 including the information at the time t3 when the reception is restarted is shown in FIG.<u style="single">Hourly billing service</u> The management method of the receiving client on the server has been described above, but a new service can be provided by using this mechanism. As already mentioned, in data distribution such as voice and image by multicast, what kind of receiving client exists, how many receiving clients in total exist at a certain time, or how many receiving clients according to statistics receive multicast data. I couldn't get the information such as whether it was received. This is because there is no such concept in the multicast mechanism and UDP packets are used for data transmission, and such a background hinders the spread of multicast, which has many advantages at the same time. Therefore, the network relay device method and device provided by the present invention can provide a user management service for multicast data distribution and an hourly billing service for content usage for each receiving client, which was not possible in the past. Currently, there are two main types of paid content distribution services (by unicast): One is a form of purchasing the right to use the service at a fixed fee, and the other is a form of pay-as-you-go. In addition, these are all unicast, and the distribution form is on-demand or real-time relay. At this time, especially for real-time relay, it has already been mentioned that multicast is effective in that it can suppress capital investment, but if the service is provided because the user itself cannot be managed, the right to access the content will be purchased. There was no other way. Moreover, since multicast is not on-demand but real-time content distribution, it was necessary to access it at the time when it could be received. However, if the receiving client is managed according to the present invention, it is possible to charge according to the time when the content is accessed, and it becomes very easy for the business operator to provide the service. Also, for the user side, if the broadcast time of the content cannot be accessed, there is no charge, or if the program is delivered by accessing the content for a certain period of time during the content broadcast, that amount of time is used. It will be possible to provide services that are beneficial to the user side as well. Examples of this service provision form are shown in FIGS. 26 and 27. In the example of FIG. 26, the server site ST such as ISP / NSP is provided with the client management / authentication server S11, the billing server SR, and the multicast content distribution / client management server S13. By managing / authenticating the client with the server S11, the multicast join / leave information is collected via the client accommodation switch SW and the multicast-compatible routers 1_1 to 1_5. Then, as shown in FIG. 27, the Internet connection / content distribution company 30 provides the normal Internet connection service 32 to the client 20 2 and charges the client (user) the Internet connection fee 3 . , When the Internet connection / content distribution company 30 provides the content distribution service to the client 20 as a further value-added service, it is possible to provide the multicast content distribution service DS by pay-as-you-go using multicast. That is, it is possible to provide a content distribution service DS that charges based on the program reception time of the client 20, and the Internet connection / content distribution company 30 listens to the program to the client 20 based on the program listening time of the client 20. Charge and charge the fee. As described above, according to the present invention, as in the current unicast communication, it is possible to provide reliability in multicast communication by enabling reception user management in data distribution by multicast, which was impossible in the past, and supports multicast. It contributes to the spread of network devices, end systems, and multicast-compatible applications. Further, according to the present invention, by providing a user management function in a multicast environment, it is possible to grasp and manage the number of receiving clients and the total number of recipients at a certain point in time, and it is possible to perform a content distribution service by multicast and the Internet in real time. It contributes to the spread of broadcasting. Further, according to the present invention, by providing user management while performing multicast distribution, it is possible to provide an hourly billing service for multicast content distribution, which was not possible in the past, to popularize the content distribution business and further to receive content. It also contributes to the spread of broadband networks for the purpose of.