Data generating device

BACKGROUND OF THE INVENTION

0001The invention relates to a device for efficiently distributing data for multicasting in a multicast environment.

0002The multicast has hitherto been utilized as a technology of scheming to make efficient a transmission of streaming data, etc. including multimedia data such as voices, sounds, videos, images, these combination and so on. In the multicast, it is basically impossible to provide an on-demand data distribution. The multicast has, however, a large number of merits in a distribution of the dynamic images and a distribution of the voices in realtime (Example: live relay broadcasting).

0003In the multicast, a quantity of traffic of a certain route is kept constant at all times irrespective of the number of clients (the number of users desiring to receive data). Hence, there is a less of influence exerted on other communications. Accordingly, in the multicast, unlike unicast, there is no necessity of providing equipment such as a dedicated-to-distribution network and cache server, and the like. According to the multicast, the multimedia data can be distributed based on an extremely low-cost network structure.

0004Technologies for actualizing the multicast are Internet Group Management Protocol (IGMP) and a multicast routing protocol. The IGMP is a protocol for a multicast-supported router and a multicast-supported layer-3 switch (which will hereinafter be called “multicast routers”) to grasp multicast receiving states of the clients (an end system) each connected under the multicast router. The multicast routing protocol is a protocol that functions between the multicast routers in order to build up a data distribution route from the server down to each client. Note that, in the specification, “layer 2” and “layer 3” respectively mean communication functions defined on OSI (Open System Interconnection) layer model.

0005In conventional IGMP version 1 (IGMPv1) and IGMP version 2 (IGMPv2), a multicast group is managed by only multicast addresses corresponding to destination addresses of the multicast data. Note that there is a system capable of restricting a transmission host in IP multicast communications supported by the IGMPv2 messages (see “Patent document 1”).

0006In IGMP version 3 (IGMPv3: See non-patent document 2), however, a multicast session is identified and managed by an address (source address) of a server (source) as a data transmission source and by the multicast address. Namely, the multicast session where the source address, though the multicast address is the same, is different is recognized as a different multicast session. Accordingly, in the IGMPv3, a dual use of the multicast address becomes possible. This form of multicast is called SSM (Source Specific Multicast) and will be, it is predicted, applied to realtime broadcasting from now onwards.

0007Further, normally in a local area network (LAN) environment and in a broadband environment for accessing the Internet, a layer-2 switch (a LAN switch) is installed between the router or the layer-3 switch and the client. Then, this layer-2 switch accommodates the end system (clients) and is connected to the router or the layer-3 switch.

0008The layer-2 switch used in a network utilizing the multicast generally implements an IGMP Snooping function. In the IGMP Snooping, the multicast data are forwarded to only a port to which a client (a receiver) desiring to receive the multicast data is connected. In the IGMP Snooping, the layer-2 switch snoops to see (refers to) the IGMP messages sent from the client and the multicast router. Then, the layer-2 switch grasps a port where the multicast router was connected, each port where each client was connected, and each multicast address which each client expects reception of multicast data, and then forwards the multicast data based on the result of the grasp.

0009Thus, the IGMP Snooping enables the multicast data to be forwarded to only the port required. Therefore, it is avoided that the multicast data arrive at all the clients including the clients who do not desire to receive. At this time, the layer-2 switch supporting the IGMP Snooping judges whether layer-2 information, i.e., a media access control (MAC) address comes under the multicast address or not. Then, in case the MAC address is the multicast address, the layer-2 switch forwards the multicast data to only the port required.

0010Thus, the layer-2 switch actualizes the IGMP function by the IGMP snooping. Namely, the IGMP and the Internet Protocol (IP) multicast are functions of the layer 3, however, the layer-2 switch controls the forwarding process based on the layer-2 information. Accordingly, the layer-2 switch, even if supporting the IGMP Snooping, has no necessity of executing processes related to the layer 3 and did not therefore undergo a great adverse influence upon its performance.

0011Above-mentioned the Patent Document 1 and the non-Patent Documents 1 and 2 are as follows.

0000[Patent document 1] Japanese Patent laying-open Application Publication No. 2002-64558; <br /> [Non-patent document 1] “Multicast Listener Discovery Version 2 (MLDv2) for IPv6”, [online], Internet <URL:http://www.ietf.org/internet-drafts/draft-vida-mld-v2-06.txt>; and <br /> [Non-patent document 2] “Internet Group Management Protocol, Version 3”, [online], Internet <URL: http://www.ietf.org/rfc/rfc3376.txt? number=337>

0012In the IGMPv3 and Multicast Listener Discovery version 2 (MLDv2: see the non-patent document 1) which will be, it is predicted, spread from now onwards, however, the processing at a layer-2 level becomes impossible unlike conventional IGMPs (version 1, version 2) and MLD (version 1). Herein, the MLD is a technology on the IPv6 corresponding to the IGMP on the IPv4. In the IGMPv3 and the MLDv2, source information and a plurality of multicast addresses, etc. are stored in a payload field next to an IP header in an IP packet. These pieces of information are indispensable for actualizing functions of the IGMPv3 and the MLDv2. It is therefore impossible that the IGMP Snooping of the layer-2 switch realizes functions of the IGMPv3 and the MLDv2. Namely, for actualizing the functions of the IGMPv3 and the MLDv2 by utilizing the IGMP Snooping, the layer-2 switch is required to refer to layer-3 information in an IGMP packet or MLDv2 packet. The actualization of the functions of the IGMPv3 and the MLDv2 by utilizing the IGMP Snooping, the layer-2 switch is further required to determine a port as a forward destination after referring to the layer-3 information even in an actual forwarding process.

0013The layer-2 switch for switching a frame on the basis of the layer-2 (MAC) information implements the process of referring to the layer-3 information, which causes a remarkable decline of performance of the layer-2 switch, causes the device itself to be extremely complicated and causes its cost to rise. Further, it is the same as a state where the clients are connected by a shared media (a hub (HUB), etc.) that a network is configured by the layer-2 switches incapable of actualizing the IGMP Snooping. Namely, the multicast data are forwarded to even the client having no necessity of receiving the multicast data, and an adverse influence is exerted on other unicast communications and multicast communications. Hence, it follows that there is lost a merit given from the layer-2 switch accommodating the clients.

SUMMARY OF THE INVENTION

0014One of objects of the invention is that providing a system and device, in a network which is used a multicast group management protocol (e.g. IGMPv3 and/or MLDv2) using information for a certain layer (e.g. layer-3 information), for distributing multicast data to only ports connected clients, each which desires reception of the multicast data, via a switch based on a layer (e.g. layer-2) lower than the certain layer.

0015To solve the problems, the invention takes the following constructions. A first aspect of the invention is a data generating device installed on an upstream side of a switching device for performing switching based on data of a first layer. The data generating device comprises a reading unit reading forward management information relating to a forwarding process of forward data from data of a second layer higher than the first layer, a storage unit storing the forward management information read by the reading unit, a data generating unit identifying one or more clients, each of which becomes (corresponds to) a forward destination of the forward data on the basis of the forward management information stored on the storage unit, and generating the same number of pieces of transmission data including equivalent contents to the forward data as the number of identified clients, and a forwarding unit forwarding the transmission data generated by the data generating unit to the switching device in order to transmit the transmission data to the respective clients.

0016In the first aspect of the invention, the reading unit reads the forward management information about the forwarding process of the forward data, from data of a layer higher than other layer of data that is referred by the switching device installed on a downstream side of the data generating device when performs switching. For instance, if the switching device installed downstream of the data generating device is a layer-2 switch, the reading unit reads the forward management information from the data of the layer 3 or higher such as a message of the IGMPv3, a message of the MLDv2, and the like.

0017The storage unit stores the information based on the forward management information read by the reading unit. The storage unit may store intactly the forward management information read by the reading unit and may also store information created based on the forward management information by other means (e.g., managing unit).

0018The data generating unit determines, based on the forward management information, one or more devices (clients), each of which becomes (corresponds to) a forward destination of the forward data. The data generating unit generates the same number of pieces of unicast data as the number of identified clients. For example, the data generating unit copies and changes the forward data so that one piece of data is transmitted to the single client corresponding to the forward destination. The data generating unit copies the forward data in order to generate the same number of pieces of data as the number of clients corresponding to the forward destinations. Then, the data generating unit changes a destination address of the copied data into an address of the client corresponding to the forward destination.

0019Therefore, according to the first aspect of the invention, based on the forward management information, the transmission data having equivalent contents to the forward data are transmitted to each of the clients corresponding to the forward destination of the forward data (namely, the forward data are substantially transmitted to each client with a one-to-one transmission). Hence, the switching device installed downstream of the data generating device has no necessity of executing the process based on the forward management information with respect to the forward data. Namely, the switching device has no necessity of reading (referring to) the information (the forward management information) of the higher-order layer. Accordingly, it is possible to reduce a delay in processing due to the switching device's reading the information of the higher-order layer and a cost for thus designing the switching device.

0020A second aspect of the invention is a data generating device comprising a reading unit reading information on a forwarding process of multicast data from data of a layer higher than a layer 2 defined in OSI layer model (OSI reference model), a storage unit storing forward management information based on the information read by the reading unit, and a data generating unit identifying one or more clients, each of which corresponds to a forward destination, and generating the same number of pieces of unicast data as the number of identified clients from the multicast data. The data generating unit, for example, copies, based on the forward management information stored on the storage unit, the multicast data by the same number of pieces of data as the number of clients corresponding to the forward destinations, and changing each piece of copied data into unicast data.

0021The data generating unit may be constructed to generate the unicast data by rewriting a MAC address of each piece of copied data into a MAC address of each client corresponding to the forward destination.

0022Moreover, the second aspect of the invention may take such a construction that there is further included a sending unit sending the data toward a downstream side of the data generating device, and the sending unit sends the unicast data generated by the data generating unit and the multicast data.

0023Further, the second aspect of the invention may take such a construction that there is further included a managing unit updating the forward management information stored on the storage unit on the basis of the information read by the reading unit.

0024Still further, the second aspect of the invention may take such a construction that in case the information read by the reading unit is information indicating a participation in a multicast group, the managing unit has contents of the piece of information reflected in the forward management information stored on the storage unit.

0025Yet further, the second aspect of the invention may take such a construction that in case the information read by the reading unit is information that indicates leaving from the multicast group, the managing unit deletes information about the client as a sender of the piece of information from the forward management information.

0026Moreover, the second aspect of the invention may take such a construction that there is further included a time measuring unit for measuring a fixed period of time, and, in case the time measuring unit judges that a response to a response request is not received for the fixed period of time or longer from the client, the managing unit deletes information about this client from the forward management information.

0027Still moreover, the second aspect of the invention may take such a construction that the storage unit stores an address of the client to which the multicast data should be forwarded and a destination address of this piece of multicast data as the forward management information in a way that relates them to each other, and there is further included a client management information storage unit for storing a client identifier indicating the client to which the multicast data should be forwarded, a destination identifier indicating a transmission destination of this piece of multicast data, a time when this client and the transmission destination of this piece of multicast data have been stored in an interrelated manner in the forward management information, and a time when this client and the information about the transmission destination of this piece of multicast data have been deleted from the forward management information, in a way that relates them to each other on the basis of the forward management information.

0028Yet moreover, the second aspect of the invention may take such a construction that the storage unit stores an address of the client to which the multicast data should be forwarded, a destination address of the multicast data and a source address of the multicast address as the forward management information in a way that relates them to each other, and there is further included a client management information storage unit for storing a client identifier indicating the client to which the multicast data should be forwarded, a destination identifier indicating a transmission destination of this piece of multicast data, a source identifier indicating a transmission source of this piece of multicast data, a time when this client and the transmission destination of this piece of multicast data have been stored in an interrelated manner in the forward management information, and a time when this client and the information about the transmission destination of this piece of multicast data have been deleted from the forward management information, in a way that relates them to each other on the basis of the forward management information.

0029Furthermore, in case the information read by the reading unit is information indicating a change in a multicast receiving state, the managing unit may be constructed to update the forward management information stored on the storage unit by use of contents of this piece of information.

BRIEF DESCRIPTION OF THE DRAWINGS

0030Other aspects and/or advantages of the present invention will become apparent during the following discussion in conjunction with the accompanying drawings, in which:

0031<figref idref="DRAWINGS">FIG. 1</figref> is a view showing an example of a structure of a network using IP multicast;

0032<figref idref="DRAWINGS">FIG. 2</figref> is a table showing an alignment of multicast address;

0033<figref idref="DRAWINGS">FIGS. 3A and 3B</figref> are views showing an outline of IGMPv1;

0034<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> are views showing an outline of IGMPv2;

0035<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> are views showing an outline of IGMPv3;

0036<figref idref="DRAWINGS">FIG. 6</figref> is a view showing a state where a client designating an INCLUDE mode is connected;

0037<figref idref="DRAWINGS">FIG. 7</figref> is a view showing a state where a client designating an EXCLUDE mode is connected;

0038<figref idref="DRAWINGS">FIG. 8</figref> is a view showing an outline of a multi routing protocol;

0039<figref idref="DRAWINGS">FIG. 9</figref> is a view showing an outline of RFC1112;

0040<figref idref="DRAWINGS">FIG. 10</figref> is a view illustrating a forwarding system involving the use of a forwarding device of the invention;

0041<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram of the forwarding device;

0042<figref idref="DRAWINGS">FIG. 12</figref> is a view showing a view showing a network structure of a multicast system;

0043<figref idref="DRAWINGS">FIG. 13</figref> is a block diagram of a multicast router;

0044<figref idref="DRAWINGS">FIG. 14</figref> is a block diagram of a multicast packet processing unit;

0045<figref idref="DRAWINGS">FIG. 15</figref> is a diagram showing an example of a receipt client information management table;

0046<figref idref="DRAWINGS">FIG. 16</figref> is a diagram showing a format of a packet containing an IGMP message;

0047<figref idref="DRAWINGS">FIG. 17</figref> is a diagram showing a format of the packet containing an MLDv2 message;

0048<figref idref="DRAWINGS">FIG. 18</figref> is a diagram showing a header format of an IPv4 packet;

0049<figref idref="DRAWINGS">FIG. 19</figref> is a diagram showing a header format of an IPv6 packet;

0050<figref idref="DRAWINGS">FIG. 20</figref> is a diagram showing a format of a Report message on the IGMPv3;

0051<figref idref="DRAWINGS">FIG. 21</figref> is a diagram showing a format of a Report message on the IGMPv3;

0052<figref idref="DRAWINGS">FIG. 22</figref> is a diagram showing an example of entries retained in a receipt client information management table;

0053<figref idref="DRAWINGS">FIG. 23</figref> is a diagram showing an example of the entries retained in the receipt client information management table;

0054<figref idref="DRAWINGS">FIG. 24</figref> is a flowchart showing an example of an operation of a data frame generating unit;

0055<figref idref="DRAWINGS">FIG. 25</figref> is a view for explaining showing a function of an original multicast data transmitting process;

0056<figref idref="DRAWINGS">FIG. 26</figref> is a view showing an example of a structure of a network where a dedicated device is used;

0057<figref idref="DRAWINGS">FIG. 27</figref> is a view showing an outline of a contents distribution system;

0058<figref idref="DRAWINGS">FIG. 28</figref> is a diagram showing an example of a user management table; and

0059<figref idref="DRAWINGS">FIG. 29</figref> is a diagram showing an example of a service performed based on information in the user management table.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

IP Multicast

<Outline>

0060A structure of IP multicast as a premise of the invention will be described. Note that a case where a data link layer is Ethernet will be explained in the following discussion. <figref idref="DRAWINGS">FIG. 1</figref> is a view showing an example of a network using the IP multicast. In the IP multicast, a multicast address is used as an address. The IP multicast functions between a server (source) E<b>1</b> and clients (receivers) E<b>2</b>, each which is an end system, and a multicast router M<b>1</b>.

0061In the IP multicast, multicast data are transmitted to multicast addresses. The multicast data are received by the clients E<b>2</b> belonging to a multicast group via a multicast-supported network N<b>1</b>, the multicast router M<b>1</b> and layer-2 switches L<b>1</b>. The IP multicast in an IPv4 environment is actualized by a multicast group management protocol such as IGMP and a multicast routing protocol.

0062IGMP messages (a multicast group control message) are exchanged between the clients E<b>2</b> and the multicast router M<b>1</b> adjacent thereto (with the layer-2 switches L<b>1</b> interposed therebetween). By the IGMP, the multicast router M<b>1</b> grasps the multicast group of each client E<b>2</b> located under the multicast router M<b>1</b>.

0063A message of the multicast routing protocol is exchanged between the multicast routers M<b>1</b> (with the layer-2 switch L<b>1</b> interposed therebetween). By the multicast routing protocol, a multicast data distribution tree from a server E<b>1</b> down to the plurality of individual clients E<b>2</b> (receipt clients) is created between the multicast routers M<b>1</b>.

0064Next, a basic operation of a data transmission by the IP multicast will be explained. To begin with, the client E<b>2</b> desiring to receive the multicast data notifies the multicast router M<b>1</b> in a local network, of the IGMP message including information indicating that the client E<b>2</b> desires to receive the multicast data. When the multicast router M<b>1</b> receives the IGMP message, a state of the client E<b>2</b> is that the client E<b>2</b> is participating in the multicast group for receiving the desired multicast data. Namely, the client E<b>2</b> becomes a member of the multicast group.

0065The server E<b>1</b> transmits the multicast data (e.g., stream data) to each multicast address identified by class-D addresses. At this time, the server E<b>1</b>, irrespective of the number of clients belonging to the multicast group, transmits one piece of multicast data.

0066The multicast router M<b>1</b> in the multicast-supported network N<b>1</b> receives the multicast data transmitted from the server E<b>1</b>. The multicast router M<b>1</b>, according to each route to each clients E<b>2</b> participating in the multicast group of the multicast data, copies the received multicast data corresponding to need and transfers the multicast data (original or copy) to each route. Namely, the multicast router M<b>1</b> distributes the multicast data along the multicast data distribution tree created by the multicast routing protocol and extending from the transmission host (the server E<b>1</b>) down to each of the clients E<b>2</b>. Accordingly, one piece of multicast data transmitted by the server E is distributed finally to the plurality of clients E<b>2</b> of the multicast group member within the network.

0067Next, the multicast address, the IGMP and the multicast routing protocol will respectively be described.

<Multicast Address>

0068The multicast address in the IPv4 will be explained. The multicast address is defined as a class-D address and takes a value within a range of “224.0.0.0” through “239.255.255.255” in a decimal notation. Therefore, the class-D addresses are identified by first four bits “1110”.

0069<figref idref="DRAWINGS">FIG. 2</figref> is a table showing how the multicast addresses are assigned. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, some multicast addresses are reserved for specified applications. On the other hand, the each of addresses having a value within “239.0.0.0” through “239.255.255.255” is used as generally used multicast address (local site multicast addresses. The local site multicast addresses is used by enterprise networks, ISPs (Internet Service Providers), and so on.

0070Moreover, a concept or protocol termed SSM has recently come into an examination by IETF. The SSM is a multicast session identified by a pair of a multicast address (a multicast group address) and a source address of the multicast data, or is a mechanism thereof. A range of the multicast addresses for the SSM is, among the IPv4 class-D addresses, “232.0.0.0” through “232.255.255.255”.

0071Note that, in the SSM, the source address of the multicast data to be received is designated by the IGMP. Hence, the multicast router and the end system need to implement the IGMPv3.

<IGMP>

0072Next, the IGMP will be explained. The client (the host) and the multicast router transfer and receive the IGMP messages to and from each other. By the IGMP message, the multicast router grasps and manages the client in the local network to which the multicast router itself is connected. In other words, the IGMP is a protocol for informing the multicast router that each client participates in an multicast group. In this case, the multicast router and the client are respectively required to implement functions defined by the IGMP. The IGMP includes a version 1 (v1) through a version 3 (v3). The IGMPv1 is defined in an appendix <b>1</b> to Request For Comments (RFC) 1112. The IGMPv2 is defined in RFC2236. The IGMPv3 is defined in RFC3376.

0073The IGMPv1, the IGMPv2 and the IGMPv3 are the same in the point of each conducting the multicast group management but the IGMP has different functions per version. The following are explanations of the IGMPs in the respective versions.

<<IGMPv1>>

0074<figref idref="DRAWINGS">FIGS. 3A and 3B</figref> are views showing an outline of the IGMPv1. With respect to IGMPv1, a process in a case where the client E<b>2</b> participates in the multicast group (see <figref idref="DRAWINGS">FIG. 3A</figref>) and a process in a case where the client E<b>2</b> leaves the multicast group (see <figref idref="DRAWINGS">FIG. 3B</figref>), will be explained by use of <figref idref="DRAWINGS">FIGS. 3A and 3B</figref>.

0075To start with, the process in the case where the client E<b>2</b> participates in the multicast group will be described by use of <figref idref="DRAWINGS">FIG. 3A</figref>. In the IGMPv1, the multicast router (IGMP Querier router) M<b>1</b> periodically sends a Query message to a subnet <1>. The client E<b>2</b> desiring to participate in the multicast group stores a Report message (Report) with a piece of information of the multicast group as a response to the Query message, and transmits the Report message. In other words, the client E<b>2</b> responds to the Query message and sends the Report message that designates the multicast group <2>. The multicast router M<b>1</b>, in the case of receiving this Report message, sets an interface having received the Report message (i.e. the client E<b>2</b> of a source of the Report) to forward the multicast data transmitted to a multicast address corresponding to the multicast group.

0076Next, the process in the case where the client E<b>2</b> leaves the multicast group will be explained by use of <figref idref="DRAWINGS">FIG. 3B</figref>. The client E<b>2</b> participating in the multicast group stops receiving the multicast data when stops functions related to the multicast by an end of process of an application using the multicast data, etc. <3>. With this process, the client E<b>2</b> leaves the multicast group. In this case, the client E<b>2</b> does not respond to the Query message.

0077The multicast router M<b>1</b>, in the case of receiving no Report message for a fixed period of time from the client E<b>2</b>, recognizes from a timeout that this client E<b>2</b> has left the multicast group <4>. Then, after this recognition, the multicast router M<b>1</b> stops the process of forwarding the multicast data to the client E<b>2</b>.

0078Thus, the multicast router M<b>1</b> grasps, from the timeout with respect to the receipt of the Report message responding to the Query message, whether or not the client E<b>2</b> keeps participating in the multicast group. Therefore, even when the client E<b>2</b> leaves the multicast group, the multicast router M<b>1</b> executes forwarding the multicast data to the client E<b>2</b> till the timeout occurs. Namely, till the occurrence of the timeout, the multicast data continue to flow to the subnet to which the client E<b>2</b> is connected.

<<IGMPv2>>

0079<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> are views showing an outline of the IGMPv2. In regard to IGMPv2, a process in a case where the client E<b>2</b> participates in the multicast group (see <figref idref="DRAWINGS">FIG. 4A</figref>) and a process in a case where the client E<b>2</b> leaves the multicast group (see <figref idref="DRAWINGS">FIG. 4B</figref>), will be explained by use of <figref idref="DRAWINGS">FIGS. 4A and 4B</figref>.

0080At first, the process in the case where the client E<b>2</b> participates in the multicast group will be described by use of <figref idref="DRAWINGS">FIG. 4A</figref>. In the IGMPv2, in the same way as the IGMPv1, the multicast router M<b>1</b> periodically sends the Query message to the subnet <1>. The client E<b>2</b> desiring to participate in the multicast group stores the Report message with a piece of information of the multicast group as a response to the Query message, and thus sends it <2>. The multicast router M<b>1</b>, in the case of receiving this Report message, sets an interface having received the Report message (i.e. the client E<b>2</b>) to forward the multicast data corresponding to the multicast group.

0081In the IGMPv2, the client E<b>2</b>, at a point of time when desiring to participate in the multicast group, is capable of transmitting an Unsolicited Report message regardless of receiving the Query message. The multicast router M<b>1</b>, in the case of receiving the Unsolicited Report, immediately recognizes that a group member appears as a subordinate. Then, it starts forwarding the multicast data to the client E<b>2</b> as the group member.

0082Next, a process in the case where the client E<b>2</b> leaves the multicast group will be described by use of <figref idref="DRAWINGS">FIG. 4B</figref>. The client E<b>2</b> participating in the multicast group stores a piece of information of the multicast group in a Leave message (Leave) and transmits it to the multicast router M<b>1</b>, thereby leaving the multicast group <3>.

0083The multicast router M<b>1</b>, upon receiving the Leave message, confirms an existence of the client E<b>2</b> (other group member) other than the sender of the Leave message with respect to the subordinates to the interface having received the Leave message. At this time, the multicast router M<b>1</b> transmits a Group Specific Query message pertaining to this multicast group via the interface having received the Leave message <4>.

0084In case there exists other group member, the other group member sends the Report message in response to the Group Specific Query in order to inform of a purport of still wanting to receive <5>. The multicast router M<b>1</b>, when receives the Report message, recognizes the existence of other group member and continues to forward the multicast data to the corresponding interface.

0085On the other hand, the multicast router M<b>1</b>, in the case of receiving no Report message as a response to the Group Specific Query, namely, in the case of no existence of other group member, judges that no other group member exists under the interface, and stops forwarding the multicast data to the interface.

0086Next, differences between the IGMPv1 and the IGMPv2 will be explained. First, the IGMPv2 defines the Leave message for explicitly informing that the client E<b>2</b> leaves the multicast group to which it has been belonging.

0087Second, the IGMPv2 defines the Group Specific Query for the multicast router M<b>1</b> having received the Leave message to confirm as to whether other group member exists locally (in the local interface) or not.

0088Third, the IGMPv2 defines the Unsolicited Report for enabling the client E<b>2</b>, at the point of time when determining by the client E<b>2</b> itself to participate in the multicast group, to promptly participate in the multicast group irrespective of receiving the Query message from the multicast router M<b>1</b>.

0089Fourth, the IGMPv2 defines that in a case where a multicast router (IGMPv1 router) M<b>1</b> or a client (IGMPv1 client) E<b>2</b> that behaves according to the IGMPv1 exists in an subnet, a multicast router that behaves according to the IGMPv2 (IGMPv2 router) M<b>1</b> and a client that behaves according to the IGMPv2 (IGMPv2 client) E<b>2</b>, must behave according to the IGMPv1.

<<IGMPv3>>

0090<figref idref="DRAWINGS">FIGS. 5A and 5B</figref> are views showing an outline of the IGMPv3. As for IGMPv3, a process in the case where the client E<b>2</b> participates in the multicast group (see <figref idref="DRAWINGS">FIG. 5A</figref>) and a process in the case where the client E<b>2</b> leaves the multicast group (see <figref idref="DRAWINGS">FIG. 5B</figref>), will be explained by use of <figref idref="DRAWINGS">FIGS. 5A and 5B</figref>.

0091To begin with, the process in the case where the client E<b>2</b> participates in the multicast group will be described by use of <figref idref="DRAWINGS">FIG. 5A</figref>. In the IGMPv3, in the same way as the IGMPv1 and the IGMPv2, the multicast router M<b>1</b> periodically sends the Query message to the subnet <1>. The client E<b>2</b> desiring to participate in the multicast group stores the Report message with a piece of information of the multicast group as a response to the Query message, and thus sends it. At this time, the client E<b>2</b>, if it wants to designate a source (the server E<b>1</b> (at least one of E<b>1</b><i>a</i>, E<b>1</b><i>b</i>, E<b>1</b><i>n</i>)) for the multicast group, can transmit information of the server E<b>1</b> becoming the source in a way that has it contained in the Report message <2>. The client E<b>2</b> is capable of designating a plurality of servers E<b>1</b> (0 or more: for example, the server E<b>1</b><i>a </i>and E<b>1</b><i>b</i>) becoming the sources of the multicast group.

0092Such a source designating method (a filter mode) has two types of modes, an INCLUDE mode and an EXCLUDE mode. In the INCLUDE mode, the client E<b>2</b> receives the multicast data from the server E<b>1</b> designated by the Report message. On the other hand, in the EXCLUDE mode, the client E<b>2</b> receives the multicast data from a server E<b>1</b> excluding the server E<b>1</b> designated by the Report message.

0093The multicast router M<b>1</b>, upon receiving the Report message, forwards only the multicast data transmitted from the server E<b>1</b> designated by the Report message among pieces of multicast data corresponding to the Report message via the interface having received the Report message. Therefore, the clients E<b>2</b> subordinate to the multicast router M<b>1</b> can receive only the multicast data transmitted from one or more arbitrary servers E<b>1</b>.

0094The multicast router M<b>1</b>, when receives the Report message including that a new server E<b>1</b> to a client E<b>2</b> being is set as a source of a multicast group, makes a judgement (merging of information) about a forwarding destination of the multicast data from the server E<b>1</b>. In this case, the multicast router M<b>1</b> retains a result of the judgement, thereby forwarding the multicast data transmitted from the server E<b>1</b> to the client E<b>2</b> (i.e., transmitting from the interface).

0095In the IGMPv3, in case there exist only the clients E<b>2</b> subordinate to an interface which have designated the INCLUDE mode for a certain multicast address, by an execution of merging the information, the filter mode being “INCLUDE”, a source list including all the designated servers E<b>1</b> is retained. Herein, the source list is a list of the addresses of the servers E<b>1</b>, for judging the source with respect to the multicast address.

0096<figref idref="DRAWINGS">FIG. 6</figref> is a view showing a state where only the clients E<b>2</b> that have designated the INCLUDE mode exist subordinately to the interface. For instance, states of clients E<b>2</b><i>a</i>, E<b>2</b><i>b</i>, E<b>2</b><i>n </i>subordinate to an interface (i) of the multicast router M<b>1</b> are assumed to be respectively [(m), INCLUDE, “(a), (b) and (c)”], [(m), INCLUDE, “(b), (c) and (d)”], and [(m), INCLUDE, “(e) and (f)”] for a multicast address (m). Herein, the setting shall be [the multicast address, the filter mode, the source list]. In this case, a state that should be retained by the multicast router M<b>1</b> becomes [(i), (m), INCLUDE, “(a), (b), (c), (d), (e) and (f)”]. Namely, if all the client E<b>2</b> subordinate to the interface (i) are in the INCLUDE mode, the setting of the filter mode with respect to this interface (i) becomes the INCLUDE mode, and the source list turns out to be the merging of the sources (namely, (a), (b), (c), (d), (e), and (f)) contained in the respective records.

0097Further, under a certain interface, if at least one client E<b>2</b> having designated the EXCLUDE mode for the multicast address exists, the filter mode retained by the multicast router M<b>1</b> becomes the EXCLUDE mode. Then, the multicast router M<b>1</b> retains, as a source list, common elements of all the sources designated by the EXCLUDE mode excluding all the sources designated by the INCLUDE mode.

0098<figref idref="DRAWINGS">FIG. 7</figref> is a view showing a state where the clients E<b>2</b> that have designated the EXCLUDE mode exist subordinately to the interface (i). For instance, states of the clients E<b>2</b><i>a</i>, E<b>2</b><i>b</i>, E<b>2</b><i>n </i>subordinate to the interface (i) of the multicast router M<b>1</b> are assumed to be respectively [(m), EXCLUDE, “(a), (b), (c), and (d)”], [(m), EXCLUDE, “(b), (c), (d), and (e)”]], [(m), INCLUDE, “(d), (e), and (f)”]] for the multicast address (m). In this case, a state that should be retained by the multicast router M<b>1</b> becomes [(i), (m), EXCLUDE, “(b) and (c)”]]. Namely, the clients E<b>2</b> (E<b>2</b><i>a </i>and E<b>2</b><i>b </i>in this instance) of the EXCLUDE mode exist subordinately to the interface (i), and hence the filter mode of the interface (i) becomes the EXCLUDE mode. Then, the source list of the interface (i) becomes “(b) and (c)”.

0099The multicast router M<b>1</b> mages the states of the respective systems subordinate thereto, and retains the state thereof for each multicast address about each interface.

0100Further, the client E<b>2</b> retains respectively the filter mode and the corresponding source list thereto for each socket (if a plurality of sockets exist) and for each multicast address per interface.

0101Next, a process in the case where the client E<b>2</b> leaves the multicast group will be explained by use of <figref idref="DRAWINGS">FIG. 5B</figref>. The client E<b>2</b> participating the multicast group sends to the multicast group a Report message in which a source list is empty in the INCLUDE MODE. Alternatively, the client E<b>2</b> transmits a Report message including a change in the source information to the multicast group <3>. With the transmission of this Report message, the client E<b>2</b> leaves this multicast group.

0102The multicast router M<b>1</b>, when receives the Report message, confirms an existence of the client E<b>2</b> (other group member) other than the sender of the Report message with respect to the subordinates to the interface having received the Report message. Namely, the multicast router M<b>1</b> transmits a Group Specific Query message pertaining to the multicast group via the interface having received the Report message. Alternatively, the multicast router M<b>1</b>, when receives the Report message including changing the source information, sends a Group And Source Specific Query message for confirming that the source information is to be changed <4>.

0103If other group member exists, this other group member sends a Report message in response to the Group Specific Query in order to inform of a purport of still wanting to receive. Alternatively, the other group member transmits the Report message for maintaining the source information to be changed <5>. The multicast router M<b>1</b>, upon receiving the Report message, recognizes the existence of other group member and continues to forward the multicast data to the interface.

0104On the other hand, the multicast router M<b>1</b>, in the case of receiving no Report message as a response to the Group Specific Query, i.e., in the case of no existence of other group member, judges that there does not exist no other group member subordinately to the interface, and stops forwarding the multicast data to the interface.

0105Next, an operation for changing a state of the client E<b>2</b> in the IGMPv3 will be explained. The IGMPv1 and IGMPv2 define only operations of the client E<b>2</b> relating to participates and leaves to/from the multicast group. In the IGMPv3, however, the client E<b>2</b> is able to notify the multicast router M<b>1</b> of changes of state relating to the multicast (changes of the source information and/or the filter mode). The multicast router M<b>1</b>, upon receiving the notification, performs operations reflected the change of the state.

0106The client E<b>2</b> participating in the multicast group, when desires changing the source and/or the filter mode relating to the multicast group, transmits the Report message having information of the multicast group and information indicating changing in the filter mode and/or in the source.

0107The multicast router M<b>1</b>, upon receiving the Report message, confirm as to whether or not the state change contained in the Report message may reflect to the information (for example, a result of the judgement by merging the information) stored by the multicast router M<b>1</b>. At this time, the multicast router M<b>1</b> performs confirming about the state change by sending to the client E<b>2</b> the Group and Source Specific Query message related to the multicast group and the source list pertaining to the multicast group. The client E<b>2</b> receives the Group and Source Specific Query message. Then, the client E<b>2</b>, if wishes to maintain the source information that is to be changed about the multicast group, transmits to the multicast router M<b>1</b> the Report message including a request for maintain the information of the changing target.

0108The multicast router M<b>1</b>, after receiving the Report message, grasps the information of one or more server E<b>1</b> as sources relating to the change, maintains or updates the corresponding source list, and forwards the multicast data from the proper server E<b>1</b>.

0109The multicast router M<b>1</b>, in the case of receiving no Report message to the Group and Source Specific Query message about the multicast group, continues to forward the multicast data in accordance with the present information.

0110In the IGMPv3, the client E<b>2</b>, at a point of time when its own state is changed (such as stopping the receipt of the multicast data and changing the filter mode, and so on), can transmit an Unsolicited Report message irrespective of receiving the Query message.

0111The conventional IGMPs (the IGMPv1 and IGMPv2) provide the multicast group management function based on only the multicast addresses. On the other hand, the IGMPv3 provides the multicast group management function using a set of one multicast address and zero or more of the servers E<b>1</b> becoming the source of the multicast data. Namely, the client E<b>2</b> can designate zero or more of the servers E<b>1</b> with respect to a certain multicast group and can request for receiving the multicast data. In other words, if a restriction (the number of the servers E<b>1</b> is 0) is not given to the server E<b>1</b> with respect to the multicast address, the management becomes equal to the management of only the same multicast addresses as by the conventional IGMPs. Further, if (one or more) servers E<b>1</b> are designated, though the multicast address is the same, the multicast data transmitted from other than the designated servers E<b>1</b> are not processed (neither received nor forwarded). Moreover, in the same Report message, the plurality of multicast addresses and the source related thereto can be designated.

0112Further, if only one source is designated, a certain multicast session is expressed such as (S, G) by use of a source S and a multicast group G. Therefore, even when the same multicast address G is used about a plurality of multicast sessions, if each source S is different each other, it is able to manage each of the multicast sessions as a different multicast session. This mode is called SSM.

0113Note that a target of all versions of IGMP is IPv4. A protocol corresponding to the IGMP on which targets the IPv6 is the MLD. The MLD is being standardized by the magma WG (working group) of the IETF. A protocol corresponding to the IGMPv2 is MLD for IPv6 (RFC2710). A protocol corresponding to IGMPv3 is MLDv2 for IPv6 (draft-vida-mld-v2-xx.txt).

0114The IGMP (IGMPv1) is defined in APPENDIX I to RFC1112 and becomes the Internet Standard. Further, the IGMPv2 is defined in RFC2236 and is added a function related to “low leave latency” as compared with the IGMPv1 by addition of the Leave message. Moreover, the IGMPv3 has a added function of “source filtering” for managing the group membership information by designating the source together with the multicast address, and is so designed as to be mutually operable for the IGMPv1 and IGMPv2. The source filtering is a function enabling a certain system to receive the multicast data from only a specified source or a specified source group with respect to a certain multicast address.

0115A message of the IGMPv3 is encapsulated into IPv4 datagram, and an IP protocol number is “2”. Each of the IGMP messages is sent with “IP TTL (Time-To-Live)=1”. These definitions are the same as the IGMPv1 and IGMPv2.

0116Further, as in the case of the IGMPv1, the Query message and the Report message are used (the contents are, however, as a matter of course, different) as messages of the IGMPv3. Further, in the IGMPv3, a function equivalent to the Leave message in the IGMPv2 is actualized by sending the Report message of the IGMPv3 having a state that “the list of sources of the multicast data that a client desires to receive the multicast data is set empty”. Moreover, in the IGMPv3, an action equivalent to Join (a transmission of the Report message) in the IGMPv1 and IGMPv2 is actualized by sending the Report message of the IGMPv3 having a state that “the list of sources of the multicast data that a client does not desire to receive the multicast data is set empty”.

0117Next, differences between the IGMPv2 and the IGMPv3 will be described. First, in the IGMPv3, the source filtering is added.

0118Second, in the IGMPv3, the Leave message (the message for notifying of leaving the multicast group) is deleted from the specifications. Therefore, in the IGMPv3, the leaving from the multicast group is carried out by sending the Report message indicating that there is no source that requires forwarding with respect to the multicast group.

0119Third, the IGMPv3 enables the notification of the change of the state. Namely, in the IGMPv3, each client, when changing the source and/or the filtering mode about a certain multicast group is occurred, is able to notify the multicast router of the changing by the Report message.

0120Fourth, the IGMPv3 defines the Group and Source Specific Query. According to the definition, when the client notifies the multicast router of changing the source and/or the filtering mode by the Report message, the multicast router confirms subordinates to the interface as to whether the change in the formation of the source for the multicast group may reflect in or not.

0121Fifth, the IGMPv3 defines that the multicast router supporting the IGMPv3 (IGMPv3 router), in case there exists a multicast router or a client operating based on the IGMPv2 other than the IGMPv3 router itself, must operate based on the IGMPv2. Similarly, the IGMPv3 is defined that the IGMPv3 router, in case there exists a multicast router or a client operating based on the IGMPv1, must operate based on the IGMPv1.

0122Sixth, in the IGMPv3, it was abolished the Report message restraining function by the client. Namely, when a network is handled by the IGMPv3, unlike the IGMPv1, IGMPv2, the Report message is sent to an address “224.0.0.22” indicating all the IGMPv3 routers. This abolition is effectuated in consideration of the UGMP Snooping in a bridge/L<b>2</b> switch.

0123Seventh, in the IGMPv3, the IGMPv3 router must be capable of receiving any types of addresses (unicast or multicast) assigned to the interface at which the Report message has arrived, and confirming as to whether it is the Report message or not.

<Multicast Routing Protocol>

0124<figref idref="DRAWINGS">FIG. 8</figref> is a view showing an outline of a multicast routing protocol. The multicast routing protocol will be explained by use of <figref idref="DRAWINGS">FIG. 8</figref>.

0125The multicast routing protocol is, in a network configured by a plurality of multicast-supported routers and/or layer-3 switches (a plurality of multicast routers M<b>1</b>), a protocol for controlling routes (or for creating a route tree). The multicast routing protocol determines one or more interfaces of the multicast routers M<b>1</b> for transmitting the multicast data, in order to distribute the multicast data along routes to each client E<b>2</b>. The multicast routing protocol is used between the multicast routers M<b>1</b>.

0126The multicast routing protocols are DVMRP (Distance Vector Multicast Routing Protocol: used in MBone and defined in RFC1075), PIM (Protocol Independent Multicast: defined in RFC2362, and an examination of a new version by IETF is underway), MOSPF (Multicast OSPF operable only on OSPF (Open Shortest Path First) and defined in RFC1584, RFC1585) and so forth. Among them, the PIM is a de facto standard.

<RFC1112>

0127<figref idref="DRAWINGS">FIG. 9</figref> is a diagram showing an outline of RFC1112. RFC1112 will be described by use of <figref idref="DRAWINGS">FIG. 9</figref>. RFC1112 defines mapping between an IP address of the class-D and a physical address, a filtering function of receiving only a packet having physical addresses corresponding to a specified class-D IP address and raising the packet up to a higher-order layer, and so forth. For carrying out the function of RFC1112, both of the router and the client are required to implement RFC1112.

0128The mapping (correspondence) between the IP address and the physical address of the class-D is defined such that low-order 23 bits of the class-D IP address are padded to low-order 23 bits of a multicast physical address “01:00:5 E:00:00:00” (a hexadecimal number) (refer to RFC1700). For example, the IP address “239.133.130.34” becomes the physical address “01:00:5 E:05:82:22”.

<Multicast on IPv6>

0129Next, the multicast in an IPv6 environment will be explained. A protocol equivalent to the IGMPv3 in the IPv6 is the MLDv2 that is in the process of being examined by the IETF. The following points are main differences between the IGMP and the MLDv2. First, the MLDv2 does not specify the IGMP in an IPv4 header and uses an ICMPv6 message type (Multicast Listener Query: Type=decimal <b>130</b>, MLD Version 2 Multicast Listener Report: Type=decimal <b>131</b>, MLD version 2 Multicast Listener Done: Type=decimal <b>132</b>).

0130Second, in the MLDv2, the multicast MAC address is generated by mapping low-order 32 bits of the 128-bit IPv6 address to the 48-bit MAC address “33:33:xx:xx:xx:xx”.

0131Accordingly, the multicast differences between the IPv4 and the IPv6 are recognizable and distinguishable as well, and there is not much difference in operation between the IGMPv3 and the MLDv2. Moreover, there exists a multicast routing protocol such as the PIM capable of supporting the IPv6.

[Principle]

<System Structure>

0132Next, a principle of a forwarding device relating to the invention will be described by use of the drawings. <figref idref="DRAWINGS">FIG. 10</figref> is a view showing a forwarding system <b>1</b> in which the forwarding device corresponding to the invention is utilized. The forwarding system <b>1</b> is configured by use of a forwarding device <b>2</b>, a server <b>3</b>, layer-2 switches <b>4</b> (<b>4</b><i>a</i>, <b>4</b><i>b</i>), clients <b>5</b> (<b>5</b><i>a</i>, <b>5</b><i>b</i>) and a multicast-supported network <b>6</b>.

0133To begin with, constructions other than the forwarding device <b>2</b> will be explained. The server <b>3</b> is constructed by use of an information processing device such as a personal computer, a workstation, etc., transmits the multicast data to the clients <b>5</b>.

0134The layer-2 switch <b>4</b> accommodates one or more clients <b>5</b>. Herein, the layer-2 switch <b>4</b><i>a </i>accommodates the client <b>5</b><i>a </i>that does not receive the multicast data, and the layer-2 switch <b>4</b><i>b </i>accommodates the client <b>5</b><i>b </i>receiving the multicast data.

0135Each client <b>5</b> is constructed by using an information processing device such as a personal computer, a workstation, and so on. Herein, the client <b>5</b><i>a </i>is set not to receive the multicast data from the server <b>3</b>, while the client <b>5</b><i>b </i>is set to receive the multicast data from the server <b>3</b>. Therefore, the client <b>5</b><i>b </i>transmits a multicast control packet to the forwarding device <b>2</b>. Namely, the multicast control packet is transferred and received between the forwarding device <b>2</b>, the layer-2 switch <b>4</b><i>b </i>and the client <b>5</b><i>b</i>. The multicast control packet is datagram for notifying the forwarding device <b>2</b> of a desire for or a stop of receiving the multicast data. An IGMPv3 message is given by way of an example of such a multicast control packet.

0136The multicast-supported network <b>6</b> is a network configured by use of the multicast-supported routers and layer-3 switches.

0137<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram showing the principle of the forwarding device <b>2</b>. Next, the forwarding device <b>2</b> will be explained by using <figref idref="DRAWINGS">FIG. 11</figref>. The forwarding device <b>2</b> receives the multicast control packet from the client <b>5</b><i>b</i>, stores content thereof and judges which client <b>5</b> to which the multicast packet should be forwarded. Then, the forwarding device <b>2</b>, upon receiving the multicast packet from the server <b>3</b>, forwards a content of the received multicast packet to each client <b>5</b><i>b </i>in a way that unicasts it thereto. The forwarding device <b>2</b> is constructed by using transmitting/receiving interfaces <b>7</b> (<b>7</b><i>a</i>, <b>7</b><i>b</i>), a multicast packet processing unit <b>8</b> and a forward processing unit <b>13</b> in order to execute such a process.

0138Each of the transmitting/receiving interfaces <b>7</b> transmits and receives the data to and from other devices via the network. The transmitting/receiving interface <b>7</b><i>a </i>transmits and receives the data to and from the layer-2 switch <b>4</b> and the client <b>5</b> via the network. Herein, the transmitting/receiving interface <b>7</b><i>a </i>transmits and receives the data to and from the client <b>5</b> via the layer-2 switch <b>4</b>. Normally, the forwarding device <b>2</b> includes a plurality of transmitting/receiving interfaces <b>7</b><i>a</i>. The transmitting/receiving interface <b>7</b><i>b </i>transmits and receives the data to and from the server <b>3</b> via the network (the multicast-supported network <b>6</b>).

0139The multicast packet processing unit <b>8</b> is provided for each of transmitting/receiving interface <b>7</b><i>a </i>and transmitting/receiving interface <b>7</b><i>b</i>. Alternatively, one single multicast packet processing unit <b>8</b> is provided for all the transmitting/receiving interfaces <b>7</b><i>a</i>, <b>7</b><i>b</i>. In <figref idref="DRAWINGS">FIG. 11</figref>, for a convenience, one multicast packet processing unit <b>8</b> is shown. The multicast packet processing unit <b>8</b> manages the transmitting/receiving interface <b>7</b><i>a </i>corresponding thereto. The multicast packet processing unit <b>8</b> judges, from among the clients <b>5</b> subordinate to the transmitting/receiving interfaces <b>7</b> managed by itself, which client <b>5</b> the multicast packet received by the transmitting/receiving interface <b>7</b><i>b </i>should be forwarded to. The multicast packet processing unit <b>8</b>, for executing such a process, includes a receipt client information management table storage unit <b>9</b>, a multicast control message judging unit <b>10</b>, a multicast packet judging unit <b>11</b> and a data frame generating unit <b>12</b>.

0140The receipt client information management table storage unit <b>9</b> is stored with a receipt client information management table <b>9</b>A. The receipt client information management table <b>9</b>A is stored with information about the respective clients <b>5</b> subordinate to the forwarding device <b>2</b>.

0141The multicast control message judging unit <b>10</b> judges whether the packet received by the transmitting/receiving interface <b>7</b><i>a </i>from the client <b>5</b> is the multicast control packet or not. The multicast control message judging unit <b>10</b>, in case the received packet is the multicast control packet, reflects a content of the packet in the receipt client information management table <b>9</b>A. At this time, the multicast control message judging unit <b>10</b> transfers the packet to the forward processing unit <b>13</b>. Whine on the other hand, in case the received packet is not the multicast control packet, the multicast control message judging unit <b>10</b> transfers the packet to the forward processing unit <b>13</b>.

0142The multicast packet judging unit <b>11</b> judges whether the packet received from the forward processing unit <b>13</b> is a multicast packet or not. The multicast packet judging unit <b>11</b>, in case the packet is the multicast packet, transfers the packet to the data frame generating unit <b>12</b>. While on the other hand, in case the packet is not the multicast packet, the multicast packet judging unit <b>11</b> forwards the packet via the transmitting/receiving interface <b>7</b><i>a. </i>

0143The data frame generating unit <b>12</b> generates, based on the multicast packet received from the multicast packet judging unit <b>11</b>, a unicast packet (a multicast frame that should be transmitted to the client <b>5</b> (<b>5</b><i>b</i>)) that should be transmitted to the client <b>5</b> (<b>5</b><i>b</i>) subordinate to the transmitting/receiving interface <b>7</b><i>a. </i>

0144The forward processing unit <b>13</b> executes a routing process included in a normal router and a multicast routing process. Therefore, the forward processing unit <b>13</b> has a routing table storage unit <b>14</b> stored with a routing table <b>14</b>A, and a multicast processing unit <b>15</b> for executing the multicast routing process.

Example of Operation

0145Next, an example of an operation of the forwarding device <b>2</b> will be described. Wen the transmitting/receiving interface <b>7</b><i>a </i>receives the multicast control packet, the multicast control message judging unit <b>10</b> judges (checks) whether the received packet is the multicast control message or not. The multicast control message judging unit <b>10</b>, in case the received packet is the multicast control message, has a content of the packet reflected in the receipt client information management table <b>9</b>A. Further, the multicast control message judging unit <b>10</b> transfers the packet to the forward processing unit <b>13</b>. Then, the forward processing unit <b>13</b> has a content of the multicast control packet received as forward control information of the normal multicast data, reflected in the routing table <b>14</b>A and in the multicast processing unit <b>15</b>.

0146While on the other hand, the multicast control message judging unit <b>10</b>, in case the received packet is not the multicast control packet, transfers the packet to the forward processing unit <b>13</b>. Then, the forward processing unit <b>13</b> executes a forwarding process of the packet.

0147When the transmitting/receiving interface <b>7</b><i>b </i>receives the multicast packet, the forward processing unit <b>13</b> judges which transmitting/receiving interface <b>7</b><i>a </i>the received multicast data should be forwarded from. Then, the forward processing unit <b>13</b> transfers the received multicast packet to the multicast packet processing unit <b>8</b> that manages the thus-judged transmitting/receiving interface <b>7</b><i>a. </i>

0148The multicast packet transferred to the multicast packet processing unit <b>8</b> from the forward processing unit <b>13</b>, is processed by the multicast packet judging unit <b>11</b>. The multicast packet judging unit <b>11</b> refers to the receipt client information management table <b>9</b>A and thus confirms an existence or non-existence of the client <b>5</b><i>b </i>to which the received multicast packet should be forwarded. In case such a client <b>5</b><i>b </i>exists, the multicast packet judging unit <b>11</b> transfers the received multicast packet to the data frame generating unit <b>12</b>.

0149The data frame generating unit <b>12</b> converts the received multicast packet into an unicast packet addressed to the client <b>5</b><i>b</i>, and forwards the unicast packet to the client <b>5</b><i>b </i>via the transmitting/receiving interface <b>7</b><i>a</i>. At this time, the data frame generating unit <b>12</b> generates a plurality of unicast packets as the necessity arises. For instance, in case there exist a plurality of clients <b>5</b><i>b </i>that the received multicast packet should be forwarded to, one or more unicast packets are to be generated.

0150While on the other hand, in case these clients <b>5</b><i>b </i>do not exist, the multicast packet judging unit <b>11</b> forwards the received multicast packets to other devices via the transmitting/receiving interface <b>7</b><i>a</i>. Such other devices are, for example, other forwarding device <b>2</b> connected to the forwarding device <b>2</b>, the multicast-supported router, and so on.

Outline of Embodiments

0151Next, the forwarding device, i.e., a multicast router <b>16</b> in an embodiment of the invention will be described by use of the drawings. Note that the description of the embodiment is an exemplification, and the architecture of the invention is not limited to the following discussion. Further, in the following discussion, an explanation is made by exemplifying a network to which the IPv4 and the IGMPv3 are applied. In a case where the IPv6 is applied, the invention can be embodied in the same procedure by taking into consideration a difference between the multicasting on the IPv4 and the multicasting on the IPv6 such as applying the MDLv2 as a substitute for the IGMPv3.

0152<figref idref="DRAWINGS">FIG. 12</figref> is a view showing a network configuration of a multicast system <b>17</b> using the multicast router <b>16</b>. The multicast system <b>17</b> is configured by using the server <b>3</b>, the multicast-supported network <b>6</b>, the multicast router <b>16</b>, the layer-2 switch <b>4</b> and a plurality of clients <b>5</b>.

0153At first, constructions other than the multicast router <b>16</b> will be explained. The basic constructions of the server <b>3</b>, the multicast-supported network <b>6</b>, the layer-2 switch <b>4</b> and the client <b>5</b> are as shown in the description of the principle.

0154<figref idref="DRAWINGS">FIG. 13</figref> is a block diagram showing a construction of the multicast router <b>16</b>. The construction of the multicast router <b>16</b> will be described by use of <figref idref="DRAWINGS">FIG. 13</figref>. The multicast router <b>16</b> includes, hardwarewise, a CPU (central processing unit), a main memory (e.g., RAM), and secondary storage device (e.g., flash memory), and so on. The multicast router <b>16</b>, as a variety of programs (OS (operating system), applications, etc.) stored on the secondary storage device are loaded into the main memory and executed by the CPU, functions as a device including a multicast packet processing unit <b>18</b> (<b>18</b><i>a</i>, <b>18</b><i>b</i>, <b>18</b><i>c</i>), a forwarding control unit <b>19</b>, a transmitting/receiving interface <b>21</b> (<b>21</b><i>a</i>, <b>21</b><i>b</i>, <b>21</b><i>c</i>) and so on.

0155<figref idref="DRAWINGS">FIG. 14</figref> is a block diagram showing a construction of the multicast packet processing unit <b>18</b>. The multicast packet processing unit <b>18</b> will be described by sue of <figref idref="DRAWINGS">FIG. 14</figref>. The multicast packet processing unit <b>18</b> is constructed by using a timer <b>23</b>, a receipt client information management table storage unit <b>24</b>, a multicast control message judging unit <b>25</b>, a multicast packet judging unit <b>26</b>, and a data frame generating unit <b>27</b>.

0156The timer <b>23</b> is constructed by use of a timer device, a CPU, a RAM, and so on. The timer <b>23</b> starts measuring a time upon a transmission of a Query message via the transmitting/receiving interface <b>21</b> corresponding to the multicast packet processing unit <b>18</b> provided with the timer itself. The timer <b>23</b> measures a time with respect to each of entries in a receipt client information management table <b>24</b>A. Then, the timer <b>23</b> judges whether or not a Report message to the Query message is received within a fixed period of time via the transmitting/receiving interface <b>21</b>. Namely, the timer <b>23</b> judges whether or not the Report message is received within the fixed period of time in regard to each of the entries in the receipt client information management table <b>24</b>A. The timer <b>23</b>, upon a receipt of the Report message with respect to a certain entry in the receipt client information management table <b>24</b>A, resets the time measurement (a value of the time measurement is reset to 0) with respect to the entry.

0157For instance, three times as much time as a transmission interval of the Query message is set in the timer <b>23</b>. In this case, the timer <b>23</b>, in case the Report message is not received during that the Query message is sent three times, falls into a timeout. In a case where the transmission interval of the Query message is 125 seconds, the timer <b>23</b> is set so as to count 375 seconds.

0158The timer <b>23</b>, in the case of falling into the timeout, judges that the client <b>5</b> corresponding to the entry did not receive the multicast data by the time due to some cause. Therefore, the timer <b>23</b> deletes, from the receipt client information management table <b>24</b>A, information about the client <b>5</b> corresponding to the entry with the timeout occurred. Namely, the timer <b>23</b> deletes, from the receipt client information management table <b>24</b>A, the entry related to the client <b>5</b> corresponding to the entry with the timeout occurred. Hence, in case the timer <b>23</b> falls into the timeout, the forwarding of the multicast data to the client <b>5</b> corresponding to the entry is stopped.

0159The processes of the timer <b>23</b> are similarly executed even in the case of the MLDv2 in the IPv6 environment.

0160The receipt client information management table storage unit <b>24</b> is constructed by use of a hard disk and a nonvolatile storage device such as a flash memory, and so on. The receipt client information management table storage unit <b>24</b> is stored with the receipt client information management table <b>24</b>A.

0161<figref idref="DRAWINGS">FIG. 15</figref> is a diagram showing an example of the receipt client information management table <b>24</b>A. The receipt client information management table <b>24</b>A will be explained by use of <figref idref="DRAWINGS">FIG. 15</figref>.

0162The receipt client information management table <b>24</b>A manages information necessary for judging which multicast data the individual client <b>5</b> wants to receive. The receipt client information management table <b>24</b>A is created and updated based on information included in the Report message sent from each client <b>5</b> and received via the transmitting/receiving interface <b>21</b> corresponding to the table <b>24</b>A itself. The receipt client information management table <b>24</b>A is also stored with a MAC address because of being a piece of local interface information.

0163The receipt client information management table <b>24</b>A has entries each containing field items such as Entry Number, Client Address, Client MAC Address, Multicast Address, Source Address and Filter Mode.

0164The Entry Number is a uniquely number assigned to each entry. In the receipt client information management table <b>24</b>A shown in <figref idref="DRAWINGS">FIG. 15</figref>, one Entry Number is assigned per Client Address. Namely, in the receipt client information management table <b>24</b>A shown in <figref idref="DRAWINGS">FIG. 15</figref>, a plurality (one or more) of Multicast Addresses, Source Addresses and Filter Mode are assigned to one Client Address.

0165The Client Address represents an IP address of the client <b>5</b> located subordinately to the transmitting/receiving interface <b>21</b> corresponding to the multicast packet processing unit <b>18</b> provided with the receipt client information management table storage unit <b>24</b>.

0166The Client MAC Address represents a MAC address mapping to the Client Address in the same entry. The Client MAC Address indicates a MAC address of the client <b>5</b> having the Client Address in the same entry.

0167The Multicast Address represents a multicast address of the multicast data that the client <b>5</b> having the Client Address in the same entry desires to receive. There might be a case in which one entry retains a plurality of multicast addresses (example: the entry number <b>1</b> in <figref idref="DRAWINGS">FIG. 15</figref>).

0168The Source Address represents an address (IP address) of the server <b>3</b> becoming a transmission source of the multicast data with respect to the Multicast Address mapping thereto. The multicast router <b>16</b> supports the IGMPv3. Hence, there might be a case where a plurality of source addresses is retained for one multicast address (example: the entry number <b>1</b> in <figref idref="DRAWINGS">FIG. 15</figref>).

0169The Filter Mode represents a filter mode pertaining to the multicast address mapping thereto. The filter Mode has a value of any one of “INCLUDE” and “EXCLUSDE”.

0170Herein, the receipt client information management table <b>24</b>A will be explained by giving an example of a multicast address “238.0.0.123”. The receipt client information management table <b>24</b>A shown in <figref idref="DRAWINGS">FIG. 15</figref> has the following information.

0171The client <b>5</b> having an address of “210.23.171.aa” and the client <b>5</b> having an address of “210.23.171.ff” desire to receive the multicast data having a source address of “61.143.221.2”. The client <b>5</b> having the address of “210.23.171.aa”, the client <b>5</b> having an address of “210.23.171.dd” and the client <b>5</b> having the address of “210.23.171.ff” desire to receive the multicast data having a source address of “61.143.221.3”. The client <b>5</b> having the address of “210.23.171.aa” and the client <b>5</b> having the address of “210.23.171.dd desire to receive the multicast data having a source address of “61.143.221.4”. The client <b>5</b> having the address of “210.23.171.ff” desires to receive the multicast data having a source address of “61.143.221.5”. Then, the client <b>5</b> having the address of “210.23.171.dd” desires to receive the multicast data having a source address other than those described above. Moreover, the client <b>5</b> in the entry assigned the entry number <b>1</b> receives the multicast data addressed to a multicast address of “238.0.0.123” only in the case of being transmitted from the servers <b>3</b> having source address of one of “61.143.221.2”, “61.143.221.3”, and “61.143.221.4”.

0172The multicast control message judging unit <b>25</b> is constructed by use of a CPU, a RAM, and so on. The multicast control message judging unit <b>25</b> judges whether the packet received via the transmitting/receiving interface <b>21</b> corresponding to the multicast packet processing unit <b>18</b> provided with the multicast control message judging unit <b>25</b> itself, is a multicast control packet or not. Namely, the multicast control message judging unit <b>25</b> judges whether or not the packet received via the corresponding transmitting/receiving interface <b>21</b> is a packet including a multicast control message (an IGMP Report, a Leave message, a Report message that are voluntarily transmitted by the client). The multicast control message judging unit <b>25</b>, in case the received packet is the multicast control packet, recognizes that the client <b>5</b> desiring to receive the multicast data exists subordinately to the transmitting/receiving interface <b>21</b> corresponding thereto. The multicast control message judging unit <b>25</b>, in case the received packet is the multicast control packet, reflects contents of the packet in the receipt client information management table <b>24</b>A (contents of the receipt client information management table <b>24</b>A are updated or changed in accordance with the contents of the packet). At this time, the multicast control message judging unit <b>25</b> transfers the packet also to the forwarding control unit <b>19</b>. While on the other hand, in case the received packet is not the multicast control packet, the multicast control message judging unit <b>25</b> transfers the packet to the forwarding control unit <b>19</b>.

0173The multicast control message judging unit <b>25</b> judges that the packet including, for instance, the Report message (IGMP Report) is the multicast control packet, and executes the process. Herein, the Report message will be explained.

0174The Report message is a control message based on an IGMP message or an MLDv2 message. <figref idref="DRAWINGS">FIGS. 16 and 17</figref> are diagrams showing formats of the packet including the IGMP message and of the packet containing the MLDv2 message. An assumption in <figref idref="DRAWINGS">FIGS. 16 and 17</figref> are that the data link layer is Ethernet. The IP packet retains the IGMP message as datagram of the IP packet. The IP packet also retains the MLDv2 message similarly as datagram of the IP packet.

0175With respect to the Report message, an IP address is “224.0.0.22”, a MAC address is “01:00:5 E:00:00:16”, a protocol number in the IP header is “2” representing the IGMP, and a type value of the IGMP message is “0x22”. <figref idref="DRAWINGS">FIGS. 18 and 19</figref> are diagrams showing header formats of an IPv4 packet and of an IPv6 packet. In a case where a value of Protocol ID in <figref idref="DRAWINGS">FIG. 18</figref> is “2”, the packet is judged to be a packet including the IGMP message. Therefore, based on these pieces of information, the multicast control message judging unit <b>25</b> judges whether or not the received packet includes the IGMP message and further whether or not it includes the Report message.

0176<figref idref="DRAWINGS">FIGS. 20 and 21</figref> are diagrams showing formats of the Report messages on the IGMPv3 and on the MLDv2. The Report message includes a multicast address (group address: Multicast Address) of the multicast data that the client <b>5</b> as a sender of the Report message desires to receive, a list (source list) of addresses (Source Address) of the servers <b>3</b> as transmission sources of the multicast data desired to be received, and a filter mode.

0177For example, a Report message implying that the multicast data having a multicast address of “238.0.1.12” are received from a source address of “162.22.36.5” and from a source address of “162.22.36.6”, has the multicast address of “238.0.1.12”, the source address of one of “162.22.36.5” and “162.22.36.6”, and the filter mode of “INCLUDE”.

0178Further, for instance, a Report message implying that the multicast data having a multicast address of “238.0.1.12” are received from other than the source of “162.22.36.5” and the source of “162.22.36.6”, has the multicast address of “238.0.1.12”, the source addressor one of “162.22.36.5” and “162.22.36.6”, and the filter mode of “EXCLUDE”. The client <b>5</b> is capable of designating a plurality of multicast addresses in the single Report message, and further designating the list of source addresses for the respective multicast addresses and the corresponding filter mode.

0179The explanation of the Report message comes to an end, and there is a return to the description of the multicast control message judging unit <b>25</b>. Next, an entry adding process executed by the multicast control message judging unit <b>25</b> will be described. The multicast control message judging unit <b>25</b>, in the case of receiving the Report message from a new client <b>5</b> that is not recorded as an entry in the receipt client information management table <b>24</b>A, generates a new entry based on information contained in the Report message. At this time, the multicast control message judging unit <b>25</b> identifies the new client <b>5</b> by comparing a source address of the packet including the Report message with a client address in the receipt client information management table <b>24</b>A.

0180<figref idref="DRAWINGS">FIG. 22</figref> is a diagram showing an example of the entry retained in the receipt client information management table <b>24</b>A. For instance, in a state where the receipt client information management table <b>24</b>A shown in <figref idref="DRAWINGS">FIG. 15</figref> is retained, in the case of receiving the Report message from the client <b>5</b> whose IP address is “210.23.171.gg”, a new entry shown in <figref idref="DRAWINGS">FIG. 22</figref> is registered in the receipt client information management table <b>24</b>A. At this time, it is premised that the Report message includes “xx:xx:xx:xx:45:67” as the MAC address of the client <b>5</b>, “61.143.221.38” as the source address, “238.0.2.222” as the multicast address, and “INCLUDE” as the filter mode.

0181Next, an entry updating process executed by the multicast control message judging unit <b>25</b> will be explained. The multicast control message judging unit <b>25</b>, in case contents of the Report message are different from contents of the entry in the receipt client information management table <b>24</b>A, executes the entry updating process.

0182For instance, it is assumed that the Report message designating “EXCLUDE” as the filter mode, “61.143.221.2” as the source address and “238.0.0.123” as the multicast address be received from the client <b>5</b> whose address is “210.23.171.aa”. In this case, the contents of the Report message are different from the contents of the receipt client information management table <b>24</b>A. Accordingly, the multicast control message judging unit <b>25</b> updates the contents of the receipt client information management table <b>24</b>A.

0183<figref idref="DRAWINGS">FIG. 23</figref> is a diagram showing an example of the entry retained in the receipt client information management table <b>24</b>A. In the case of receiving the Report message, the multicast control message judging unit <b>25</b> updates the contents of the entry number <b>1</b> into contents shown in <figref idref="DRAWINGS">FIG. 23</figref>. As a result of the updating, the multicast router <b>16</b> forwards the multicast data having the multicast address of “238.0.0.123” and sent from other than the server <b>3</b> of which the source address is “61.143.221.2”, to the client <b>5</b> having the address of “210.23.171.aa”.

0184Moreover, in the case of receiving a Report message that has the filter mode of “INCLUDE” and does not include the source address (empty), the multicast control message judging unit <b>25</b> deletes, from the entry, information including the multicast address included in the Report message. Namely, in the case of receiving such the Report message, the multicast control message judging unit <b>25</b> updates the entry so as not to forward the multicast data having the multicast address included in the Report message to the client <b>5</b> as the sender of the Report message.

0185For instance, it is assumed that a Report message including the multicast address of “238.225.13.33”, the source address of being empty and the filter mode of “INCLUDE” be received from the client whose address is “210.23.171.bb”. In this case, the multicast control message judging unit <b>25</b> judges that the forwarding of the multicast data having the multicast address of “238.225.13.33” to the client <b>5</b> be stopped (canceled). Namely, the multicast control message judging unit <b>25</b> deletes the information with the multicast address being “238.225.13.33” from the entry in which the client address is “210.23.171.bb”. In the receipt client information management table <b>24</b>A shown in <figref idref="DRAWINGS">FIG. 15</figref>, as a result, the entry given the entry number <b>2</b> is deleted. This process is executed similarly on the MLDv2 in the IPv6 environment.

0186Next, an operation of the multicast control message judging unit <b>25</b> in the IPv6 environment will be described. In an MLDv2-supported network in the IPv6 environment, the multicast control message judging unit <b>25</b> judges that a packet in which the MAC address is the multicast MAC address and is “33:33:00:00:00:22”, a value in a next header field within the IP header is “58” and a type value within the header is “136 (a binary number)”, is a packet including the Report message on the MLDv2. Therefore, in a case where the layer-2 switch <b>4</b> does not support the MLDv2 Snooping and even in an environment where the MLDv2 is applied in a sub-network subordinate to the multicast router <b>16</b>, the multicast data can be forwarded to only the client <b>5</b> requiring the multicast data.

0187The multicast packet judging unit <b>26</b> is constructed by using a CPU, a RAM, and so on. The multicast packet judging unit <b>26</b> judges whether the packet received from the forwarding control unit <b>19</b> is the multicast packet or not. The multicast packet judging unit <b>26</b>, in case the packet is the multicast packet, transfers the packet to the data frame generating unit <b>27</b>.

0188While on the other hand, the multicast packet judging unit <b>26</b>, in case the packet is not the multicast packet, sends the packet via the transmitting/receiving interface <b>21</b>. An example of the type of packet is, in the normal unicast data and the multicast data such as a message on the multicast routing protocol, and so on.

0189The data frame generating unit <b>27</b> is constructed by use of a CPU, a RAM, and so on. The data frame generating unit <b>27</b> receives, from the multicast packet judging unit <b>26</b>, the packet judged to be the multicast packet by the multicast packet judging unit <b>26</b>. The data frame generating unit <b>27</b> refers to the multicast address and the source address (the address of the server <b>3</b> as the transmission source) in the multicast packet received. The data frame generating unit <b>27</b> reads, from the receipt client information management table <b>24</b>A, an entry including the multicast address and the source address as reference results. The data frame generating unit <b>27</b> changes and copies the received multicast packet, thereby generating a unicast packet addressed to the client address (the client MAC address) in the readout entry. At this time, the data frame generating unit <b>27</b> changes the destination MAC address in the received multicast packet into the client MAC address included in the readout entry from the multicast MAC address. Then, the data frame generating unit <b>27</b> sends the generated unicast packet via the transmitting/receiving interface <b>21</b>.

0190<figref idref="DRAWINGS">FIG. 24</figref> is a flowchart showing an example of an operation of the data frame generating unit <b>27</b>. The operation of the data frame generating unit <b>27</b> will be described by use of <figref idref="DRAWINGS">FIG. 24</figref>.

0191For example, in a case where the multicast router <b>16</b> receives the multicast data (the multicast address is “238.0.0.123”) from the server <b>3</b> having the address of “61.143.221.2”, the data frame generating unit <b>27</b> receives the piece of multicast data from the multicast packet judging unit <b>26</b> (S<b>01</b>).

0192The data frame generating unit <b>27</b> judges whether an entry related to the received multicast data exists in the receipt client information management table <b>24</b>A or not. Namely, the data frame generating unit <b>27</b> searches the receipt client information management table <b>24</b>A for the multicast address and the source address (an entry including the source address in the case of the filter mode being “INCLUDE”, but an entry that does not include the source address in the case of the filter mode being “EXCLUDE”) of the piece of multicast data (S<b>02</b>).

0193In case the receipt client information management table <b>24</b>A has none of the entries related to the received multicast data (S<b>03</b>-NO), the data frame generating unit <b>27</b> sends the piece of multicast data in an intact state (i.e., the original multicast data) via the transmitting/receiving interface <b>21</b>, and finishes the processing (S<b>04</b>).

0194While on the other hand, in case the receipt client information management table <b>24</b>A has the entry related to the received multicast data (S<b>03</b>-YES), the data frame generating unit <b>27</b> unicasts the piece of multicast data to each client <b>5</b> making a request for receiving the piece of multicast data (S<b>05</b>).

0195In the example given above, the multicast address “238.0.0.123” of the received multicast data exists in the entry numbers <b>1</b> and <b>4</b> of the receipt client information management table <b>24</b>A. Then, taking the filter mode and the source address into consideration, as a result, the data frame generating unit <b>27</b> judges that the received multicast data should be forwarded to the client <b>5</b> relevant to the entry number <b>1</b>. Therefore, the received multicast data are unicast to the client <b>5</b> relevant to the entry number <b>1</b>.

0196Concretely, the data frame generating unit <b>27</b> confirms the relevant entry and reads the client MAC address included in the entry. Namely, in FIG.

019715, the data frame generating unit <b>27</b> reads “xx:xx:xx:xx:12:34”. Next, the data frame generating unit <b>27</b> generates unicast data by setting the readout client MAC address to the destination MAC address of the received multicast data. At this time, the data frame generating unit <b>27</b>, when reads a plurality of client MAC addresses, generates the same number of pieces of unicast data as the number of readout client MAC addresses by copying the received multicast data. In the example described above, one client MAC address is read out. Hence, the data frame generating unit <b>27</b> copies one piece of multicast data and executes changing the MAC addressing order to generate the unicast data. The data frame generating unit <b>27</b> transmits the generated unicast data via the transmitting/receiving interface <b>21</b>. Then, the data frame generating unit <b>27</b> transmits the piece of multicast data in an intact state (i.e., the original multicast data) via the transmitting/receiving interface <b>21</b>, and finishes the process (S<b>06</b>).

0198As described above, the data frame generating unit <b>27</b>, irrespective of whether the process of forwarding the unicast data is executed or not, transmits the original multicast data. <figref idref="DRAWINGS">FIG. 25</figref> shows a view for explaining an operation of the process of transmitting the original multicast data. In <figref idref="DRAWINGS">FIG. 25</figref>, a multicast router <b>16</b><i>b </i>is connected to a multicast router <b>16</b><i>a </i>located upstream through the layer-2 switch <b>4</b>. The multicast router <b>16</b><i>b </i>needs the original multicast data in order to correctly distribute the multicast data to the client <b>5</b><i>b </i>connected subordinately. Therefore, the data frame generating unit <b>27</b> of the multicast router <b>16</b><i>a</i>, irrespective of whether the process of forwarding the unicast data is executed or not, transmits the original multicast data. Normally, the layer-2 switch <b>4</b> forwards the multicast packet inputted from a certain port, via a port (e.g., a port which the multicast router <b>16</b><i>b </i>is connected to) accommodated the multicast router or a port in a direction that the multicast router exists. Hence, the original multicast data are transmitted to other multicast router (the multicast router <b>16</b><i>b</i>).

0199The transmitting/receiving interface <b>21</b> transmits and receives the data to/from other device via the network. The transmitting/receiving interface <b>21</b><i>a </i>transmits and receives the data to/from the server <b>3</b> via the network (the multicast-supported network <b>6</b>). Each of the transmitting/receiving interfaces <b>21</b> band <b>21</b><i>c </i>transmits and receives the data to/from one of the client <b>5</b> and other multicast router <b>16</b> through the sub-network and the layer-2 switch <b>4</b>.

0200The forwarding control unit <b>19</b> executes a routing process included in a normal router and a multicast routing process. Therefore, the forward processing unit <b>19</b> has a routing table storage unit <b>20</b> stored with a routing table <b>20</b>A, and a multicast processing unit <b>22</b> for executing the multicast routing process.

[Operation/Effect]

0201According to the multicast router <b>16</b> of the invention, the receipt client information management table <b>24</b>A retains the receipt setting of the multicast data for each client <b>5</b> on the basis of the IGMPv3 message. Then, the data frame generating unit <b>27</b>, based on the contents of the receipt client information management table <b>24</b>A, unicasts the received multicast data as the unicast data to the client <b>5</b> set to receive the multicast data.

0202Hence, the layer-2 switch <b>4</b> installed or placed between the multicast router <b>16</b> and the client <b>5</b>, is capable of forwarding the unicast data transmitted from the multicast router <b>16</b> on the basis of the layer-2 information. Namely, the layer-2-switch <b>4</b> becomes to have no necessity of executing the process based on the IGMPv3, which requires the layer-3 level processing. Accordingly, the layer-2 switch <b>4</b> does not need implementing the IGMPv3-supported Snooping that causes a decline of forwarding ability. Hence, it is possible to reduce a cost for implementing the IGMPv3-supported Snooping and to prevent the decline of the forwarding ability.

0203In other words, the layer-2 switch <b>4</b> existing downstream of the multicast router <b>16</b>, by the switching operation based on the layer 2, can forward the multicast data to only one or more clients <b>5</b>, desiring to receive the multicast data, within one or more clients <b>5</b> accommodated in the layer-2 switch <b>4</b>.

0204Further, the data frame generating unit <b>27</b>, regardless of whether or not the multicast data are forwarded as the unicast data, invariably forwards the original multicast data. Therefore, it is feasible to forward the original multicast data to other multicast routers <b>16</b> installed or placed subordinately to the multicast router <b>16</b>. Accordingly, other multicast routers <b>16</b> can correctly forward, based on the original multicast data, the unicast data to each of the plurality of clients <b>5</b> installed subordinately to each of the other multicast routers <b>16</b>.

0205Further, the timer <b>23</b> deletes, from the receipt client information management table <b>24</b>A, the entry related to the client <b>5</b> corresponding to the entry with the timeout occurred. Therefore, in case the client <b>5</b> is unable to receive the multicast data due to an occurrence of problems or troubles (e.g., a sudden stop of the power supply, a hang-up (freeze) of the OS, and so on), the forwarding of the multicast data to the client <b>5</b> is stopped. Accordingly, a network bandwidth can be prevented from being wasted. Namely, it is feasible to prevent an useless process of forwarding the multicast data from being executed.

Modified Embodiment

0206The two pieces of transmitting/receiving interfaces <b>21</b> (the transmitting/receiving interfaces <b>21</b> band <b>21</b><i>c</i>) are provided on the side of the client, however, there may be constructed so that three or more interfaces or only one interface are to be provided without being limited to two.

0207Further, the multicast packet processing unit <b>18</b> is provided per transmitting/receiving interface <b>21</b>, however, there may be also constructed to provide one single multicast packet processing unit <b>18</b> for managing all the transmitting/receiving interfaces.

0208Moreover, the data frame generating unit <b>27</b> may be constructed to read the client MAC address in whatever judging procedures.

0209Still further, the multicast control message judging unit <b>25</b> may be constructed to, in the case of receiving the Report message and the Query message corresponding to the IGMPv1 or the IGMPv2, convert the receipt client information management table <b>24</b>A so as to support the IGMPv1 or IGMPv2. Then, the data frame generating unit <b>27</b> generates the unicast data corresponding to the multicast data by referring to the converted receipt client information management table <b>24</b>A, and transmits the unicast data. Namely, in this case, the multicast packet processing unit <b>18</b> including the data frame generating unit <b>27</b> operates corresponding to the IGMPv1 or IGMPv2.

0210The multicast router is constructed by implementing configurations and functions of the forwarding device relating to the present invention to one of the general multicast router and the layer-3 switch for respectively executing the IP-level routing process. It may be, however, available to implement the configurations and functions of the forwarding device of the invention as a dedicated device.

0211<figref idref="DRAWINGS">FIG. 26</figref> shows an example of a network structure in the case of implementing configurations and functions of the forwarding device of the invention as a dedicated device <b>29</b>. This network is configured by use of a distribution center <b>28</b>, the dedicated device <b>29</b>, an EPON (Ethernet Passive Optical Network) <b>32</b>, a coupler <b>33</b> and a user's home <b>36</b>. A contents server <b>31</b> is installed within the distribution center <b>28</b>. Further, a media converter <b>34</b> and a client <b>35</b> are installed in the user's home <b>36</b>. Moreover, the dedicated device <b>29</b> is installed between a router <b>37</b> connected to a multicast-supported network <b>30</b> and the client <b>35</b>.

0212The dedicated device <b>29</b> refers to IGMP messages transmitted from the router <b>37</b> and the client <b>35</b> and generates the receipt client information management table <b>24</b>A (see <figref idref="DRAWINGS">FIG. 15</figref>). Furthermore, the dedicated device <b>29</b> receives the multicast data from the router <b>37</b>, generates the unicast data at the data frame generating unit <b>27</b> on the basis of the receipt client information management table <b>24</b>A, and transmits the unicast data to the client <b>35</b>.

0213The dedicated device <b>29</b> is thus installed. Thereby, there is no necessity to prepare a new multicast router <b>16</b> implemented the forwarding device of the invention, and it enable to use the existent equipment such as the router <b>37</b> and so on. For instance, even in a case where the router <b>37</b> does not support the IGMPv3, it is possible to make the router <b>37</b> support the IGMPv3 by upgrading the software, and so on. Therefore, with respect to the network only supporting the IGMPv1 and IGMPv2, it is possible to configure an IGMPv3-supported network by installing the dedicated device <b>29</b> and upgrading the software, thereby, it is able to reduce costs expended for constructing the network.

0214Further, in FTTH (Fiber To The Home), in terms of a property of the EPON<b>32</b>, the media converter <b>34</b> must implement the function of the IGMP Snooping. Normally, however, it is difficult to implement the forwarding device of the present invention, because the media converter <b>34</b> is small and does not include the CPU. In such a case, the dedicated device <b>29</b> is installed as illustrated in <figref idref="DRAWINGS">FIG. 26</figref>, whereby the IGMPv3-based multicast becomes possible without exerting any influence upon other systems.

Applied Examples

0215The forwarding device (such as the multicast router <b>16</b> implemented the forwarding device, the dedicated device <b>29</b>, and the like) of the invention is applied to a contents distribution system, thereby exhibiting new effects. <figref idref="DRAWINGS">FIG. 27</figref> shows an outline of a contents distribution system <b>38</b> to which the multicast router <b>16</b> is applied. The content distributions system <b>38</b> is configured by use of a server site <b>39</b> of a contents distribution network (CDN) carrier, a control center <b>44</b> of an ISP (Internet Service Provider), a network <b>45</b> of the ISP (multicast-supported network), the multicast router <b>16</b>, the clients <b>5</b> and the layer-2 switch <b>4</b>. The server site <b>39</b> is configured by using a user management/authentication server <b>40</b>, an accounting server <b>41</b>, a multicast contents distribution server <b>42</b> and a router <b>43</b>. Further, the ISP network <b>45</b> includes the multicast router <b>16</b>. Moreover, the layer-2 switch <b>4</b> is connected to the ISP network <b>45</b> via the multicast router <b>16</b>.

0216In the contents distribution system <b>38</b> illustrated in <figref idref="DRAWINGS">FIG. 27</figref>, a content distribution request/contract is made between the CDN carrier and the ISP (1). Thereafter, the multicast contents distribution server <b>42</b> of the CDN carrier performs multicast distributing contents (2). The multicast router <b>16</b> collects, retains and manages the receipt client information (3), and transmits the receipt client information to the site of the CDN carrier (4). The CDN carrier having received the receipt client information notifies the contract-established ISP of the received user information and accounting information (5). Then, the ISP claims the user for charges corresponding to receiving condition of the contents (6).

0217The user management/authentication server <b>40</b> is stored with a user management table <b>46</b>. The user management/authentication server <b>40</b> creates and updates the user management table <b>46</b> on the basis of the client information from the multicast router <b>16</b> installed in the ISP network <b>45</b>. The client information includes pieces of information retained in the receipt client information management table <b>24</b>A.

0218<figref idref="DRAWINGS">FIG. 28</figref> is a diagram showing an example of the user management table <b>46</b>. The user management table <b>46</b> has field items such as a user name, a user address (client address), an address of received contents (multicast address), a start time of reception, and an end time of reception.

0219The user name represents a name of the user of the client <b>5</b>. The user name is used for identifying the user and may therefore be replaced by a user's ID, and the like.

0220The user address is an address assigned to the client <b>5</b> and corresponds to the client address in the receipt client information management table <b>24</b>A. The user address may be mapping to the client MAC address in the receipt client information management table <b>24</b>A. Further, the mapping (correspondence) between the user name and the user address becomes possible by referring to log information of a DHCP (Dynamic Host Configuration Protocol) server of the ISP and by making the user management/authentication server <b>40</b> and the DHCP server cooperate.

0221The receipt content address (the address of the received contents) is a multicast address of the contents received by the client <b>5</b> and corresponds to the multicast address in the receipt client information management table <b>24</b>A. At this time, the client <b>5</b> receives the multicast data as contents distributed by the multicast contents distribution server <b>42</b>.

0222The start-of-receiving time (the start time of reception) represents a time when the client <b>5</b> starts receiving the multicast data with respect to the corresponding multicast address. The end-of-receiving time (the end time of reception) represents a time when the client <b>5</b> finishes receiving the multicast data with respect to the corresponding multicast address.

0223The CDN carrier can provide services on the basis of the information stored in the user management table <b>46</b>. <figref idref="DRAWINGS">FIG. 29</figref> is a diagram showing an example of the services performed based on the information in the user management table <b>46</b>.

0224In <figref idref="DRAWINGS">FIG. 29</figref>, the CDN carrier performs the services. The CDN carrier conducts a business for providing a contents distribution system oriented contract-users such as a contents creating company, the ISP, and the like. It is particularly herein assumed that the CDN carrier is to provide the contents distribution system based on the multicast system.

0225The CDN carrier sets a service for distributing the contents by normal multicasting, and a service including user management in addition to the multicast-based content distribution. At this time, in the service including the user management, the service based on information retained in the user management table <b>46</b> is provided. For example, the CDN carrier provides, based on the user management table <b>46</b>, the content creating company and the ISP with receipt contents, a receipt time thereof, etc. of each user.

0226In the conventional multicast, the server executes only the process of simply attaching the multicast address to the data of the contents and transmitting it. Further, the conventional multicast used UDP (User Datagram Protocol), and hence, unlike the case where TCP (Transmission Control Protocol) is utilized, it was basically impossible to grasp which client receives the multicast data and which multicast data is received. Accordingly, in the conventional multicast-based content distribution, it was impossible to grasp the user management and conditions of watching and listening to the contents.

0227The information provided by the CDN carrier, however, enables the contents creating company and the ISP to grasp the user management and the contents watching/listening conditions, and time-based charging per user, a calculation of an audience rating, and the like can be carried out.

0228Note that these services may also be provided not by the CDN carrier but by the ISP itself. Further, this service may also be conducted in such a form that the CDN carrier provides the network system itself and surrogates to distribute the content created by the content creating company.

0229According to the invention, in the network utilizing the multicast management protocol involving the use of the information of a layer of an unspecified or higher order (e.g., the layer 3), the switching device distributes the multicast data to only the port which the client desiring to receive the multicast data is connected to, without making any change in the switching device of a layer of a lower order (e.g., the layer 2) than the unspecified layer.