JP2007243288A - Communication system, node, communication method, and program for node - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a communication system, wherein a highly reliable link for interconnecting between networks or a highly reliable link interconnecting between the network and a terminal is attained. <P>SOLUTION: Only one of interlink connection nodes whose connection destinations (networks or terminals) are the same controls transmission of an Ethernet frame capsulated to one frame via an interlink. Concretely, when no fault takes place in the interlink connected to its own node and in the case that the frame is a unicast frame addressed to interlink connection whose connection destination is the same as that of its own node and a broadcast frame not attached with frame transmission completion identifier, the interlink connection node transmits its Ethernet frame to the connection destination via the interlink, and the interlink connection node attaches the frame transmission completion identifier to its Ethernet frame, and transfers the resulting Ethernet frame to an adjacent node in the case of the broadcast frame. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a communication system, a node, a communication method, and a node program, and more particularly, to a highly reliable communication system, and a node, a communication method, and a node program applied to such a communication system.

  In recent years, with the spread of the Internet, the Internet has been used not only for data distribution of characters and images but also for telephone calls and video distribution. For this reason, the traffic volume of the backbone communication system is rapidly increasing. In particular, since the amount of traffic that flows through links (hereinafter referred to as interlinks) connecting the networks that make up the backbone communication system is enormous, reliable interlink technology continues to maintain stable communication. It is extremely important to provide the information. Here, the interlink high reliability technology refers to a technology that suppresses the occurrence of congestion due to traffic concentration and avoids the interruption of communication due to an abnormality in the interlink. Note that the abnormality of the interlink includes not only an abnormality due to the disconnection of the interlink but also an abnormality due to a failure of nodes at both ends of the interlink (hereinafter referred to as an interlink connection node).

  Hereinafter, as an example of a network that realizes a highly reliable backbone communication system, a network to which RPR (Resilient Packet Ring) disclosed in Non-Patent Document 1 is applied (hereinafter referred to as an RPR network) is taken up. A technique for improving the reliability of interlinks connecting a plurality of RPR networks will be described. Non-Patent Document 1 is a standardized document issued by the Institute of Electrical and Electronics Engineers (IEEE) in 2004.

  FIG. 19 is an explanatory diagram illustrating an example of an RPR network. RPR is a network protocol for transferring frames (packets) on a network having a ring topology as shown in FIG.

  In the communication system shown in FIG. 19, an RPR network 80 is configured by eight nodes (hereinafter referred to as RPR nodes) that operate in accordance with RPR, and one terminal is accommodated under each RPR node. It is an example. Here, accommodating a terminal under the RPR node means connecting a terminal that does not belong to the ring network to which the RPR node belongs to the RPR node. Note that the terminal may belong to a ring network other than the ring network to which the RPR node belongs, or may belong to another communication network. In addition, a terminal accommodated under the RPR node may be simply referred to as a subordinate terminal.

  In the example shown in FIG. 19, each RPR node 800 to 870 has ports P1 to P3, respectively. Each RPR node 800 to 870 transmits and receives an RPR frame with an adjacent RPR node using ports P1 and P2. In addition, each RPR node 800 to 870 includes a subordinate terminal (one of terminals 1800 to 1870). Individual RPR nodes and subordinate terminals transmit and receive frames (Ethernet frames) using the port P3 of the RPR node and ports (not shown) of the subordinate terminals. Note that Ethernet is a registered trademark.

  As a main feature of RPR, a high-speed protection function is widely known. For example, in a RPR network, when a link between RPR nodes is disconnected, the RPR nodes on both sides of the link detect the disconnection and immediately notify all other RPR nodes. The other RPR node that has received the notification of the occurrence of the failure makes a transition to an operation state in which traffic is manipulated (communication direction, TTL, etc. are controlled) so as to bypass the link disconnection point. For this reason, it becomes possible to continue communication. Here, the protection function refers to a function for preventing communication from being interrupted due to a failure occurring at a certain location.

  RPR is a short period of time within 50 ms, equivalent to transmission technologies such as SDH (Synchronous Digital Hierarchy) or SONET (Synchronous Optical Network), on the premise of being used in a backbone communication system in which a large amount of traffic flows like an urban network. Therefore, it is possible to construct a highly reliable communication system.

  As a conventional technique for improving the reliability of an interlink connecting two RPR networks, there is LAG (Link Aggregation) disclosed in Non-Patent Document 2. Non-patent document 2 is also a standardized document issued by IEEE.

  LAG is a technology that virtualizes a plurality of physical ports into one logical port. In other words, this is a technique for virtualizing a plurality of links as if they were one logical link. When LAG is applied, traffic is distributed and transmitted to multiple physical links that belong to the logical link in the normal time when no failure occurs, so the communication bandwidth of the link is increased (up to the total communication bandwidth of the physical link). Up to). Further, in the event of an abnormality due to the disconnection of the physical link, since the frame is transferred using only another normal physical link in which no failure has occurred, the communication can be continued.

  FIG. 20 is an explanatory diagram showing an example in which LAG is applied to connection between RPR networks. The communication system shown in FIG. 20 is an example in which LAG is applied to an interlink connecting the RPR network 80 and the RPR network 90. In the example shown in FIG. 20, the RPR node 800 belonging to the RPR network 80 and the RPR node 900 belonging to the RPR network 90 have a port P4 in addition to the ports P1 to P3. LAG is set in the ports P3 and P4 of the RPR node 800. Similarly, LAG is set to the ports P3 and P4 of the RPR node 900. Then, port P3 of RPR node 800 and port P4 of RPR node 900 are connected by interlink 491, and port P4 of RPR node 800 and port P3 of RPR node 900 are connected by interlink 492. With such a configuration, in the example shown in FIG. 20, the reliability of connection between the RPR network 800 and the RPR network 900 is improved.

  Further, Patent Document 1 discloses a technique for improving the reliability of connection between two RPR networks. FIG. 21 is an explanatory diagram showing the configuration of the network described in Patent Document 1. As shown in FIG. In the network described in Patent Document 1, as shown in FIG. 21, the RPR node 800 and the RPR node 900 are arranged so as to belong to both the RPR network 80 and the RPR network 90. Then, one of the RPR node 800 and the RPR node 900 serves as a working node for frame transfer between RPR networks (between the RPR network 80 and the RPR network 90), and the other node serves as a backup node for frames between the RPR networks. It is set to the operating state where no transfer is performed. When the standby node detects a failure of the active node, the standby node shifts to an operation state in which frame transfer between the RPR networks is performed. Then, the contents of the forwarding database of all RPR nodes other than the RPR node 800 and the RPR node 900 are deleted. As a result, the traffic that has been transferred through the working node is transferred through the backup node. Therefore, communication can be continued even when a failure occurs in the working node.

  Patent Document 2 describes a communication network system in which two ring networks are connected. In the communication network system described in Patent Document 2, after interlinks connecting two ring networks are duplicated, one interlink is used as an active system and the other is used as a standby system. When a failure occurs in the active interlink, it is possible to continue communication by switching the interlink used for communication to the standby system.

Japanese Patent Laying-Open No. 2003-258822 (paragraphs 0015-0085, FIG. 1) JP 2000-004248 A (paragraphs 0073-0076) "IEEE Std 802.17 Part17: Resilient packet ring (RPR) access method and physical layer specifications", IEEE Inc, 2004, p.27-54 "IEEE Std 802.3ad Amendment to Carrier Sense Multiple Access with Collision Detection (CSMA / CD) Access Method and Physical Layer Specifications- Aggregation of Multiple Link Segments", IEEE Inc, 2000, p.95-107

  However, with the high reliability technology described above, the protection function can be realized for the interlinks connecting the networks constituting the backbone communication system, but each has the following problems. First, in a communication system to which LAG is applied, physical ports that can be virtualized to one logical port are limited to physical ports belonging to one node. For this reason, there is a problem that communication is interrupted only when one of the nodes (interlink connection nodes) that virtualizes the logical port fails. For example, in the communication system illustrated in FIG. 20, if either the RPR node 800 or the RPR node 900 fails, all communication between the RPR network 80 and the RPR network 90 is stopped.

  In addition, in the communication system described in Patent Document 1, although there are a plurality of network connection points, frame transfer is performed only at any one of the connection points, thereby suppressing the occurrence of congestion. I can't. The problem of the communication network system described in Patent Document 2 is the same in that only one of them is used by switching between active / spare.

  In a network topology in which ring networks are connected, if frame transfer is performed without control at multiple connection points, multiple receptions that receive the same frame twice, or frames that are broadcasted are permanently ringed. There is a problem that a phenomenon (called broadcast storm) that is not deleted from the network occurs. As a premise of high reliability technology, it is necessary to prevent such a phenomenon from occurring.

  Accordingly, the present invention provides a highly reliable communication system for an interlink connecting networks and a link connecting a network and a terminal, and a node, a communication method, and a program for the node applied to such a communication system. The purpose is to provide.

  The communication system according to the present invention is a communication system including a plurality of nodes to which terminals are connected, and some of the plurality of nodes are connected to a common terminal or a corresponding terminal via a link (interlink). Nodes belonging to a communication system different from the communication system are grouped as a group having a common connection destination (a common terminal or a communication system different from the communication system) by connecting nodes included in the communication system as terminals. Is an identifier indicating whether or not a frame received from a terminal connected to a node included in the communication system stored in the intra-system communication frame is transmitted to a common connection destination terminal or node. When an identifier adding means to be added to the internal communication frame and the intra-system communication frame are received Transmission determining means for determining whether to transmit a frame stored in the intra-system communication frame to a common connection destination terminal or node based on information indicated by the intra-system communication frame; It is characterized by having.

  Note that “connected to a common terminal” means that a plurality of nodes are connected to the same terminal. Further, being connected to a node included in a common communication system means that a plurality of nodes are connected to nodes included in another same communication system.

  Further, the nodes belonging to the group correspond to the determination result of the intra-system communication frame transmitting means for transmitting the intra-system communication frame to which the identifier is added by the identifier adding means to the nodes included in the communication system, and the transmission determination means. Terminal communication frame transmitting means for transmitting a frame stored in the intra-system communication frame to a common connection destination terminal or node.

  In addition, the node belonging to the group includes a failure monitoring unit that monitors a failure state of a link between a common connection destination terminal or node and the own node, and the transmission determination unit includes a node that belongs to the same group as the own node. Whether a frame stored in the intra-system communication frame is transmitted to a common connection destination terminal or node based on the identifier added by the identifier adding unit and the failure state of the link monitored by the failure monitoring unit It may be determined whether or not.

  In addition, the identifier adding means, when the own node transmits a frame stored in the intra-system communication frame indicating transfer by broadcast to a common connection destination terminal or node, indicates that transmission has been completed. An identifier may be added.

  In addition, the identifier adding means indicates that the own node did not transmit to the common connection destination terminal or node when it did not transmit the frame stored in the intra-system communication frame indicating transfer by broadcast. An untransmitted identifier that indicates may be added.

  The transmission determination unit may determine that transmission is not performed when the transmission source address of the intra-system communication frame is an address of a node belonging to the same group as the own node.

  In addition, the transmission determination means is a case where a transmitted identifier is not added to the intra-system communication frame or an untransmitted identifier is added to the intra-system communication frame when receiving the intra-system communication frame indicating transfer by broadcast. Then, when a frame can be transmitted / received to / from a common connection destination terminal or node, it may be determined to transmit the frame.

  In addition, the node belonging to the group includes a transfer route changing unit that changes the transfer route of the intra-system communication frame by changing the route information indicating the transfer route set in the intra-system communication frame. Also good.

  Each node not belonging to the group is assigned to any one of the nodes belonging to the group by associating with any one of the nodes belonging to the group. Transmission of the intra-system communication frame if the local node is the node that first received the intra-system communication frame among the nodes belonging to the group when receiving the intra-system communication frame indicating transfer by When the original node is assigned to the own node, and when a frame can be transmitted / received to / from a common connection destination terminal or node, and among the nodes belonging to the group, the own node If it is not the node that first received the intra-system communication frame, the intra-system communication frame When a communication identifier is added or when a transmission identifier is not added and a frame can be transmitted / received to / from a common connection destination terminal or node, it is determined to transmit and transferred. The route changing means is a case where the transmission determining means determines that the transmission is not performed, and there is no other node belonging to the group on the transfer path of the intra-system communication frame after the own node. In addition, the route information of the intra-system communication frame may be changed so as to be reachable to other nodes belonging to the group.

  The transfer route changing means may change the TTL stored in the intra-system communication frame as route information.

  In addition, when a node that does not belong to a group receives an intra-system communication frame, the node stores the frame stored in the intra-system communication frame based on information indicated by the intra-system communication frame. You may provide the 2nd transmission determination means which determines whether it transmits to the terminal connected.

  Further, the second transmission determination means, when receiving the intra-system communication frame indicating transfer by broadcast, the transfer path set by the transmission source node of the intra-system communication frame when generating the intra-system communication frame When the own node is not arranged above, it may be determined not to transmit.

  The transmission determination means transmits the frame when the destination address of the intra-system communication frame is an address of a node belonging to the same group as the own node and the frame can be transmitted / received to / from a common connection destination terminal or node. You may decide to do.

  In addition, a common terminal determines which of the nodes based on whether frame transmission / reception with each node connected to the terminal is possible and whether frame transmission / reception with other nodes included in the communication system in each node is possible. Alternatively, selective transmission means for transmitting a frame may be provided.

  Further, the identifier adding means uses the value of a predetermined field of the header of the intra-system communication frame, the preamble of the intra-system communication frame, or the interframe gap between the intra-system communication frames, An identifier may be expressed.

  The identifier adding means is a system in which the destination address of the intra-system communication frame is an address different from the broadcast address indicating transfer by broadcast, and the broadcast address is a destination address in a node belonging to the communication system. The identifier may be expressed by using an address at which a frame transfer process similar to the internal communication frame is performed.

  In addition, when a node belonging to a group cannot transmit and receive a frame on all links with other nodes included in the communication system connected to the own node, the node or node that is connected to the common node There may be provided a link control means for detecting that the frame cannot be transmitted / received to / from. The link control means, for example, closes a port that transmits / receives a frame to / from a terminal or node that is a common connection destination, or stops exchange of control frames for detecting a link failure. Let down be detected.

  The communication system and the common communication system different from the communication system may be an RPR network.

  Further, the node according to the present invention is a communication system including a plurality of nodes to which terminals are connected. Among the plurality of nodes, a node included in a communication system different from the common terminal or the communication system via a link is provided. By connecting as a terminal, nodes that are grouped together as a group having a common connection destination and stored in the intra-system communication frame and received from a terminal connected to a node included in the communication system An identifier adding means for adding an identifier indicating whether or not a common connection destination terminal or node is transmitted to the intra-system communication frame; and when the intra-system communication frame is received, the intra-system communication frame The frame stored in the intra-system communication frame based on the information indicated by Characterized by comprising a judging whether or not transmission determination means for transmitting to the terminal or node which is passing the connection destination.

  In addition, a transfer path changing unit that changes the transfer path of the intra-system communication frame by changing path information indicating the transfer path set in the intra-system communication frame may be provided.

  In addition, when a node that does not belong to a group and receives an intra-system communication frame, the frame stored in the intra-system communication frame is automatically determined based on information indicated by the intra-system communication frame. You may provide the 2nd transmission determination means which determines whether it transmits to the terminal connected to a node.

  The communication method according to the present invention is a communication system including a plurality of nodes to which a terminal is connected, wherein some of the plurality of nodes are each a common terminal or the communication system via a link. A communication method applied to a communication system that is grouped as a group having a common connection destination by connecting nodes included in a communication system different from the terminal as a terminal. An identifier indicating whether or not a frame received from a terminal connected to a node included in the communication system included in the communication frame is transmitted to a common connection destination terminal or node is stored in the intra-system communication frame. In addition, when an intra-system communication frame is received, the information indicated by the intra-system communication frame is added. Zui it, and judging whether or not to transmit the frame stored in said system within the communication frame to the common connection of the terminal or node.

  The node belonging to the group may change the transfer path of the intra-system communication frame by changing the route information indicating the transfer path set in the intra-system communication frame.

  In addition, when a node that does not belong to the group receives the intra-system communication frame, the frame stored in the intra-system communication frame is set to the local node based on the information indicated by the intra-system communication frame. You may determine whether it transmits to the terminal connected.

  The node program according to the present invention is included in a communication system including a plurality of nodes to which a terminal is connected, in a communication system different from the common terminal or the communication system through a link among the plurality of nodes. When a node is connected as a terminal, it is received from a terminal connected to the node included in the communication system, which is stored in the intra-system communication frame, in the computer provided in the node grouped as a group having a common connection destination. Processing for adding an identifier indicating whether or not the transmitted frame is transmitted to a common connection destination terminal or node to the intra-system communication frame, and when the intra-system communication frame is received, the intra-system communication Based on the information indicated in the frame, it is stored in the intra-system communication frame And characterized in that is a by which frames to execute the process of determining whether to transmit to a common destination terminal or node.

  Further, the computer may be caused to execute a process of changing the transfer path of the intra-system communication frame by changing path information indicating the transfer path set in the intra-system communication frame.

  In addition, when the intra-system communication frame is received by a computer included in a node that does not belong to the group, the frame stored in the intra-system communication frame is stored based on the information indicated by the intra-system communication frame. You may perform the process which determines whether it transmits to the terminal connected to an own node.

  According to the present invention, an interlink connection node having a common connection destination can be controlled to perform frame transfer with only one of a plurality of interlinks for one frame. It is possible to perform frame forwarding between interlink connection nodes while distributing traffic to multiple interlinks while preventing multiple frame reception and broadcast storm occurrence at normal times when no failure has occurred. it can. Therefore, the communication band of the link between networks can be expanded, and the occurrence of congestion can be suppressed.

  Further, according to the present invention, even when an interlink or an interlink connection node is abnormal, frame transfer can be performed via another normal interlink, so that communication can be continued. Therefore, a highly reliable communication system can be realized.

  In addition, according to the present invention, there is no need to notify each other of information such as a failure occurrence state of an interlink connected to the own node between interlink connection nodes in the same RPR network. No node-to-node protocol is required, and failure recovery time can be shortened.

Embodiment 1 FIG.
FIG. 1 is an explanatory diagram showing a first embodiment of a communication system according to the present invention. The communication system according to the first embodiment includes an RPR network 10 including RPR nodes 100 to 170 and an RPR network 20 including RPR nodes 200 to 270. As described above, the RPR network is a network to which RPR is applied.

  In the communication system illustrated in FIG. 1, the RPR networks 10 and 20 are connected to each other via interlinks 420 and 430. As already described, the interlink is a link that connects different networks included in the communication system. In this example, the RPR nodes 100, 110, 200, and 270 are interlink connection nodes.

  The RPR node is a node that operates in accordance with “IEEE Std 802.17”. Among the RPR nodes provided in the communication system of the present invention, RPR nodes (RPR nodes 100, 110, 200, 270) that are interlink connection nodes not only operate in conformity with “IEEE Std 802.17”, Other operations (operations for realizing the object of the present invention) are also performed.

  In the first embodiment, each RPR node has three ports P1, P2, and P3. The ports P1 and P2 are ports for transmitting and receiving RPR frames, and the RPR nodes 100 to 170 and 200 to 270 transmit and receive RPR frames with adjacent RPR nodes using the ports P1 and P2. The port P3 is a port for transmitting and receiving a frame (Ethernet frame) with a terminal accommodated under the port P3.

  The interlink 420 for connecting the RPR networks 10 and 20 is provided between the port P3 of the RPR node 100 and the port P3 of the RPR node 200. Similarly, the interlink 430 is provided between the port P3 of the RPR node 110 and the port P3 of the RPR node 270. The interlink connection nodes 100 and 110 belonging to the RPR network 10 and the interlink connection nodes 200 and 270 belonging to the RPR network 20 are connected one-to-one by the interlinks 420 and 430, respectively.

  For the interlink connection nodes 100 and 110 of the RPR network 10, the interlink connection nodes 200 and 270 of the RPR network 20 are terminals accommodated therein. Similarly, for the interlink connection nodes 200 and 270 of the RPR network 20, the interlink connection nodes 100 and 110 of the RPR network 10 are terminals accommodated therein.

  Although not shown in FIG. 1, the RPR network shown in FIG. 19 is provided at ports P3 of the RPR nodes 120 to 170 and 210 to 260 except for the RPR nodes 100, 110, 200, and 270 that are interlink connection nodes. Similarly, it is assumed that one subordinate terminal (for example, a user terminal) is accommodated.

  Furthermore, another node or another network may be connected to a terminal under each RPR node (RPR nodes 120 to 170, 210 to 260) that is not an interlink connection node. However, if a loop is formed as a result of connecting another terminal or the like to a terminal accommodated under each RPR node other than the interlink connection node, a broadcast storm is generated due to the loop, thereby causing communication. This causes problems such as instability. Therefore, a loop must not be formed by connecting other terminals or the like to terminals under the RPR nodes other than the interlink connection node.

  In this embodiment, a loop is formed by the interlink connection node. However, since the interlink connection node according to the present invention can prevent the occurrence of a broadcast storm, it has been described above. Not subject to configuration.

  In the communication system shown in FIG. 1, RPR frames are transferred (transmitted / received) between RPR nodes belonging to the same RPR network. Further, an Ethernet frame is transferred between the RPR node and a terminal under the RPR node (including between interlink connection nodes via an interlink). The RPR frame is a frame obtained by encapsulating an Ethernet frame as a payload (data body excluding the header portion). The header of the RPR frame includes a source and destination (destination) address and TTL (Time to Live). Is included. It should be noted that an RPR node address, an address indicating broadcast transmission, or an address indicating multicast transmission is stored as the source and destination addresses of the RPR frame.

  Next, the configuration of the RPR node will be described. FIG. 2 is a block diagram illustrating a configuration example of an RPR node that is not an interlink connection node provided in the communication system illustrated in FIG. FIG. 3 is a block diagram illustrating a configuration example of an RPR node that is an interlink connection node included in the communication system illustrated in FIG. 1.

  First, the configuration of the RPR node other than the interlink connection node will be described. Here, the RPR node 120 shown in FIG. 1 will be described as an example, but the configurations of the other RPR nodes 130 to 170 and 210 to 260 are the same as the configuration of the RPR node 120.

  As shown in FIG. 2, the RPR node 120 includes input ports 500-1 to 500-3, an RPR frame generator 510, an RPR switch processor 520, an Ethernet frame extractor 530, and output ports 540-1 to 540-3. , FDB 550, FDB management unit 560, TDB 570, MAC address management table 580, and port state monitoring unit 590.

  The input ports 500-1 to 500-3 of the RPR node 120 are ports (ports for receiving frames) corresponding to the receiving side in the ports P1 to P3 of the RPR node 120 shown in FIG. The input ports 500-1 and 500-2 are ports that receive RPR frames transmitted from adjacent RPR nodes. Input port 500-1 is a port that receives an RPR frame transmitted from an RPR node adjacent in the clockwise direction, and input port 500-2 is transmitted from an RPR node adjacent in the counterclockwise direction. It is a port that receives RPR frames. The input port 500-3 is a port that receives an Ethernet frame transmitted from a subordinate terminal (not shown).

  The output ports 540-1 to 540-3 of the RPR node 120 are ports (ports for transmitting frames) corresponding to the transmitting side in the ports P1 to P3 of the RPR node 120 shown in FIG. The output ports 540-1 and 540-2 are ports that transmit RPR frames to adjacent RPR nodes. The output port 540-1 is a port that transmits an RPR frame to an RPR node adjacent in the clockwise direction, and the output port 540-2 is a port that transmits an RPR frame to an RPR node adjacent in the counterclockwise direction. It is. The output port 540-3 is a port that transmits an Ethernet frame to a subordinate terminal (not shown).

  Specifically, the input port 500-1 of the RPR node 120 receives the RPR frame transmitted from the output port 540-2 of the RPR node 130 adjacent in the clockwise direction. The input port 500-2 of the RPR node 120 receives the RPR frame transmitted from the output port 540-1 of the RPR node 110 adjacent in the counterclockwise direction. Further, the input port 500-3 of the RPR node 120 receives the Ethernet frame transmitted from the output port of the subordinate terminal.

  The output port 540-1 of the RPR node 120 transmits the RPR frame to the input port 500-2 of the RPR node 130 adjacent in the clockwise direction. Further, the output port 540-2 of the RPR node 120 transmits the RPR frame to the input port 500-1 of the RPR node 110 adjacent in the counterclockwise direction. Also, the output port 540-3 of the RPR node 120 transmits an Ethernet frame to the input port of the subordinate terminal.

  The RPR frame generation unit 510 generates an RPR frame by encapsulating the Ethernet frame input from the input port 500-3.

  The RPR switch processing unit 520 performs processing related to RPR defined in “IEEE Std 802.17”. Examples of processing performed by the RPR switch processing unit 520 include transfer of an RPR frame received from an adjacent RPR node, management of topology information of the RPR network by TDP (Topology Discovery Protocol), and movement of communication bandwidth of traffic on the RPR network by Fairness Management, RPR network management by OAM (Operations, Administration, Maintenance). In the following description, the details of the processing of the RPR switch processing unit 520 are omitted except for the operation deeply related to the operation of the node according to the present invention.

  The Ethernet frame extraction unit 530 extracts the Ethernet frame stored in the payload of the RPR frame input from the RPR switch processing unit 520.

  The FDB 550 is a database for managing terminals accommodated under the RPR node belonging to the same RPR network as the own node. The FDB 550 stores the node identifier (MAC address) of the terminal and the node identifier (MAC address) of the RPR node that accommodates the terminal in association with each other. The correspondence relationship stored in the FDB 550 is registered by the FDB management unit 560 described later. The process of registering such a correspondence in the FDB 550 in the process of transmitting and receiving the RPR frame is called MAC address learning.

  FIG. 4 is an explanatory diagram showing an example of the correspondence relationship registered in the FDB 550 of the RPR node 120. In the example illustrated in FIG. 4, for example, the MAC address of the terminal under the RPR node 130 and the MAC address of the RPR node 130 are registered in association with each other. When the RPR node 120 receives an Ethernet frame having the MAC address of the terminal under the RPR node 130 as the destination MAC address from the terminal under its own node, the destination of the RPR frame encapsulating the Ethernet frame This means that the MAC address may be set to the MAC address of the RPR node 130. That is, it indicates to which RPR node the RPR frame should be transmitted with respect to the destination MAC address of the Ethernet frame.

  The FDB management unit 560 updates the contents registered in the FDB 550 according to various states of the own node (an RPR node including the FDB management unit 560) or according to a request from another component included in the own node. . For example, the FDB management unit 560 of the RPR node 120 performs MAC address learning by registering in the FDB 550 the correspondence between the MAC address of the terminal and the MAC address of the RPR node that accommodates the terminal when receiving the RPR frame. . Specifically, in response to a request from the Ethernet frame extraction unit 530, the FDB management unit 560 transmits the source MAC address of the RPR frame received by the own node and the source MAC of the Ethernet frame stored as a payload in the RPR frame. Addresses are registered in the FDB 550 in association with each other. In addition, in the correspondence relationship between a terminal and an RPR node that accommodates the terminal, one RPR node may be associated with a plurality of terminals.

  The TDB (Topology DataBase) 570 is a database for managing information related to the RPR network to which the own node (the RPR node including the TDB 570) belongs. The TDB 570 stores information indicating the topology state of the RPR network to which the node belongs and the failure occurrence status. For example, the TDB 570 stores information indicating the failure state of the link between RPR nodes in each RPR node belonging to the RPR network to which the own node belongs in order on the connection path. Information about the RPR network stored in the TDB 570 is managed (registered) by the RPR switch processing unit 520 according to TDP (Topology Discovery Protocol).

  FIG. 5 is an explanatory diagram illustrating an example of information registered in the TDB 570 of the RPR node 120. In the example shown in FIG. 5, information indicating the state of the ports P1 and P2 of each RPR node belonging to the same RPR network (RPR network 10) as the RPR node 120 (ports for transmitting and receiving RPR frames with adjacent RPR nodes) The RPR node 100 is registered in association with the node identifier (MAC address) of the RPR node in the order of connection in the clockwise direction. That is, information indicating which RPR node each RPR node belonging to the RPR network 10 is connected to and whether the connection ports P1 and P2 of each RPR node with the adjacent RPR node are valid or invalid is registered. Has been. Valid means that the port can be operated, and invalid means that the port cannot be operated.

  In the example shown in FIG. 5, for example, the RPR node 140 is connected to the RPR node 150 in the clockwise direction and is connected to the RPR node 130 in the counterclockwise direction. Further, for example, the port state of the port P1 (forwarding port in the clockwise direction) of the RPR node 140 is invalid, and the port state of the port P2 (forwarding port in the counterclockwise direction) is valid. ing. The fact that such information is registered in the TDB 570 means that “the RPR node 140 cannot transmit / receive an RPR frame at the port P1 and can transmit / receive an RPR frame at the port P2.” For example, FIG. 5 shows that the port state of the port P2 of the RPR node 150 is invalid. From this information, it can be seen that a failure has occurred in the link between the RPR node 140 and the RPR node 150 for some reason.

  The port status of other nodes is registered as follows. In order to manage the topology of the RPR network, each RPR node assigns a TP frame (Topology and Protection frame) storing the states of ports (ports P1, P2) that transmit / receive RPR frames to / from adjacent RPR nodes at a certain time interval. Broadcast transmission with. The RPR switch processing unit 520 refers to the TP frame transmitted from each RPR node and updates the state of the ports P1 and P2 of the transmission source RPR node registered in the TDB 570. Further, the port status monitoring unit 590 updates the status of the ports P1 and P2 of the own node. In other words, the port status monitoring unit 590 monitors the status of the ports P1 and P2 of the own node, and as a result of monitoring, the port P1 and P2 of the own node registered in the TDB 570 according to the status of the ports P1 and P2 are monitored. Update state.

  In the example shown in FIG. 5, only the information indicating whether the port state of the RPR node is valid or invalid is shown for the sake of simplicity. However, in the TDB defined by “IEEE Std 802.17”, the RPR Various information related to the RPR nodes constituting the network is managed. The TDB 570 shown in FIG. 1 is also registered for these pieces of information.

  The MAC address management table 580 is a table for managing MAC addresses assigned to the own node (an RPR node including the MAC address management table 580). FIG. 6 is an explanatory diagram showing an example of information registered in the MAC address management table 580 of the RPR node 120. As shown in FIG. 6, the MAC address management table 580 of the RPR node 120 includes the MAC address of the own node (RPR node 120). Registration of the MAC address in the MAC address management table 580 is performed in advance by the administrator of the communication system via the setting interface. The MAC address management table 580 is specifically stored in a storage device such as a memory provided in the RPR node.

  The MAC address registered in the MAC address management table 580 is referred to by other components of the RPR node. At least the RPR frame generation unit 510, the RPR switch processing unit 520, and the Ethernet frame extraction unit 530 refer to the MAC address registered in the MAC address management table 580.

  The port state monitoring unit 590 monitors at least the states of the input ports 500-1 and 500-2 and the output ports 540-1 and 540-2 of its own node (the RPR node including the port state monitoring unit 590), and automatically monitors according to the monitored state. Of the information registered in the TDB 570 of the node, information related to the port status of the own node is updated. For example, when the input port 500-1 is in a receivable state and the output port 540-1 is in a transmittable state, the port state monitoring unit 590 registers “valid” in the state of the port P1. Otherwise, register “invalid”. Further, for example, when the input port 500-2 is in a receivable state and the output port 540-2 is in a transmittable state, “valid” is registered in the state of the port P2, and in other cases Register “Invalid” in.

  Next, the configuration of the RPR node that is an interlink connection node will be described. Here, the interlink connection node 100 shown in FIG. 1 will be described as an example, but the configurations of the other interlink connection nodes 110, 200, and 270 are the same as the configuration of the interlink connection node 100. In the present embodiment, an RPR node that is an interlink connection node is a node that operates in accordance with “IEEE Std 802.17” and performs other operations (operations for realizing the object of the present invention). is there. As shown in FIG. 3, the interlink connection node has a port state table 600 and an interlink connection node management table 610 added as compared to an RPR node that is not an interlink connection node, and the port state monitoring unit 590 The difference is that the port states of the input port 500-3 and the output port 540-3 are also monitored. Further, the RPR switch processing unit 520 is different in that it not only performs processing related to RPR defined in “IEEE Std 802.17” but also performs other operations (operations for realizing the object of the present invention).

  The port status monitoring unit 590 monitors the status of the input ports 500-1, 2 and the output ports 540-1, 2 and updates the port status of its own node registered in the TDB 570, and also inputs the input port 500-3. The port status of the output port 540-3 is monitored, and the information regarding the port status registered in the port status table 600 of the own node is updated according to the status. For example, when the input port 500-3 is in a receivable state and the output port 540-3 is in a transmittable state, the port state monitoring unit 590 registers “valid” in the port state table 600. Otherwise, register “invalid”.

  The port status table 600 manages information indicating the status of the port P3 (the subordinate terminal, that is, the port that transmits / receives an Ethernet frame to / from another RPR network) of its own node (interlink connection node including the port status table 600). It is a table for. FIG. 7 is an explanatory diagram showing an example of the port status registered in the port status table 600 of the interlink connection node 100. As shown in FIG. 7, the port status table 600 of the interlink connection node 100 includes information indicating the status of the port P3 of the own node. Note that the port state table 600 is specifically stored in a storage device such as a memory provided in the interlink connection node.

  In the example illustrated in FIG. 7, for example, it is indicated that the port state of the port P3 of the own node is invalid. The fact that such a state is registered in the port state table 600 of the interlink connection node 100 means that the interlink connection node 100 cannot transmit and receive an Ethernet frame at the port P3. From this information, it can be seen that a failure has occurred in the link (interlink 420) connecting the RPR node 100 and another RPR network for some reason.

  The state of the port P3 registered in the port state table 600 is referred to by other components of the interlink connection node. At least the RPR switch processing unit 520 and the Ethernet frame extraction unit 530 refer to the state of the port P3 registered in the port state table 600.

  The interlink connection node management table 610 is connected via the interlink among the interlink connection nodes belonging to the same RPR network as the self node (interlink connection node including the interlink connection node management table 610). It is a table for managing the interlink connection node connected via the interlink with the same RPR network as the other RPR networks. Hereinafter, another network connected to an interlink connection node via an interlink is expressed as an interlink connection destination network.

  In other words, the interlink connection node management table 610 is a table for managing interlink connection nodes that belong to the same RPR network as the own node and are connected to the same interlink connection destination network as the own node. FIG. 8 is an explanatory diagram illustrating an example of information registered in the interlink connection node management table 610 of the interlink connection node 100. As shown in FIG. 8, the interlink connection node management table 610 of the interlink connection node 100 includes the same interlink connection destination network (RPR network) as the interlink connection node 100 among the interlink connection nodes belonging to the RPR network 10. 20) and node identifiers (MAC addresses) of the RPR node 100 and the RPR node 110. Registration of the MAC address of the interlink connection node in the interlink connection node management table 610 is performed in advance by the administrator of the communication system via the setting interface. The interlink connection node management table 610 is specifically stored in a storage device such as a memory provided in the interlink connection node.

  Note that the MAC address of the interlink connection node registered in the interlink connection node management table 610 is referred to by other components of the interlink connection node. At least, the RPR switch processing unit 520 refers to the MAC address registered in the interlink connection node management table 610.

  It is possible to determine whether or not the own node is an interlink connection node by registering the interlink connection node including the own node in the interlink connection node management table 610. For example, the interlink connection node has a switching unit that switches between operating as an interlink connection node or operating as a standard RPR node other than that according to the registered content of the interlink connection node management table 610. Interlink connection nodes and non-RPR nodes can be implemented using a common device. For example, by constructing a network using RPR nodes that can operate as interlink connection nodes, the arrangement of the interlink connection nodes can be changed only by changing the registered contents of the interlink connection node management table 610 according to the network topology. It can be changed freely. Note that if such an implementation is not performed, the own node may not be included.

  Next, the operation will be described. First, normal operation will be described. Specifically, an operation when transmitting and receiving an Ethernet frame via one of the interlinks 420 and 430 between terminals under the RPR node in a normal state will be described. Here, a terminal under the RPR node 140 (not shown in FIG. 1; hereinafter referred to as a terminal 1401) and a terminal under the RPR node 240 (not shown in FIG. 1; hereinafter referred to as a terminal 2401) transmit frames. A case where data are transmitted and received will be described as an example.

  In the following description, a case where MAC address learning is not performed in an RPR node that receives an Ethernet frame and a case where MAC address learning is already performed will be described. In the frame transfer from the terminal 1401 to the terminal 2401 described below, the MAC address learning related to the terminal 2401 is not performed in the RPR node (the RPR node 140 and the interlink connection node belonging to the RPR network 20) that receives the Ethernet frame. This is an example.

  Here, it is assumed that the FDB 550 of each RPR node and the interlink connection node management table 610 are in the following state at the time when frame transfer from the terminal 1401 to the terminal 2401 is performed.

  It is assumed that no information is registered in the FDB 550 of all RPR nodes belonging to the RPR network 10 and the RPR network 20. That is, it is assumed that no MAC address learning is performed in the RPR nodes 100 to 170 and 200 to 270.

  In the interlink connection node management table 610 of the interlink connection nodes belonging to the RPR network 10, the MAC addresses of the interlink connection nodes belonging to the RPR network 10 and having the RPR network 20 as the interlink connection destination network are registered. It shall be. That is, it is assumed that the MAC addresses of the RPR node 100 and the RPR node 110 are registered in the interlink connection node management table 610 of the RPR nodes 100 and 110 that are interlink connection nodes.

  Similarly, in the interlink connection node management table 610 of the interlink link connection node belonging to the RPR network 20, the MAC address of the interlink connection node belonging to the RPR network 20 and having the RPR network 10 as the interlink connection destination network is registered. It is assumed that That is, it is assumed that the MAC addresses of the RPR node 200 and the RPR node 270 are registered in the interlink connection node management table 610 of the RPR nodes 200 and 270 that are interlink connection nodes.

  First, the terminal 1401 transmits an Ethernet frame whose destination MAC address is the MAC address of the terminal 2401 to the RPR node 140. The input port 500-3 of the RPR node 140 receives the Ethernet frame. The Ethernet frame received by the input port 500-3 is sent to the RPR frame generation unit 510. That is, the RPR frame generation unit 510 of the RPR node 140 inputs the Ethernet frame from the terminal 1401 via the input port 500-3.

  The RPR frame generation unit 510 of the RPR node 140 searches the FDB 550 using the destination MAC address of the Ethernet frame as a search key, and acquires the MAC address of the RPR node accommodating the terminal indicated by the destination MAC address of the Ethernet frame. To do. That is, the MAC address of the RPR node associated with the destination MAC address of the Ethernet frame is retrieved from the FDB 550 and read. If the acquisition is successful, the RPR frame generation unit 510 encapsulates the Ethernet frame and generates an RPR frame with the MAC address of the read RPR node as the destination MAC address.

  Here, since no information is registered in the FDB 550, the RPR frame generation unit 510 fails to acquire the MAC address of the RPR node associated with the destination MAC address of the Ethernet frame.

  When acquisition of the MAC address of the RPR node fails, the RPR frame generation unit 510 stores the broadcast MAC address in the destination MAC address and stores the MAC address of the own node (RPR node 140) in the transmission source MAC address. In addition, an RPR frame in which an Ethernet frame is stored in the payload is generated. The RPR frame generation unit 510 may confirm the MAC address of the own node by referring to the MAC address management table 580. The RPR frame generation unit 510 sends the generated RPR frame to the RPR switch processing unit 520.

  When the destination MAC address of the RPR frame is a broadcast MAC address, that is, when the RPR frame is a broadcast frame, the RPR switch processing unit 520 of the RPR node 140 broadcasts the RPR frame.

  Specifically, the RPR switch processing unit 520 stores the number of RPR nodes belonging to the RPR network 10 (or the number obtained by subtracting 1 from the number of nodes to exclude the own node) in the TTL field of the RPR frame. The RPR frame is transmitted from either the output port 540-1 or the output port 540-2. The RPR switch processing unit 520 may confirm the number of RPR nodes belonging to the RPR network 10 by referring to the TDB 570.

  Here, the RPR switch processing unit 520 of the RPR node 140 stores the number (= 7) obtained by subtracting 1 from the number of nodes of the RPR node belonging to the RPR network 10 in the TTL field of the RPR frame, and then the output port 540. A case where an RPR frame is transmitted from -2 will be described as an example. When RPR node 140 transmits an RPR frame from output port 540-2, RPR node 130 receives the RPR frame.

  FIG. 9 is a flowchart illustrating an example of an operation when an RPR frame (in this example, the RPR node 130) that is not an interlink connection node receives a broadcast-transmitted RPR frame. Basically, an RPR node that is not an interlink connection node may operate in accordance with “IEEE Std 802.17”.

  The RPR node 130 receives the RPR frame transmitted from the output port 540-2 of the RPR node 140 at the input port 500-1 (step S101). The RPR frame received by the input port 500-1 of the RPR node 130 is sent to the RPR switch processing unit 520. That is, the RPR switch processing unit 520 of the RPR node 130 inputs the RPR frame from the RPR node 140 via the input port 500-1.

  When the transmission source MAC address of the received RPR frame is the MAC address of the own node (Yes in step S102), the RPR switch processing unit 520 of the RPR node 130 prevents the occurrence of a broadcast storm due to the loop configuration. The frame is discarded (step S103). In this example, since the source MAC address of the RPR frame is the MAC address of the RPR node 140, the RPR switch processing unit 520 of the RPR node 130 does not perform this discarding process. The RPR switch processing unit 520 may confirm the MAC address of the own node by referring to the MAC address management table 580.

  Next, when the source MAC address of the RPR frame is not the MAC address of the own node and the destination MAC address of the RPR frame is a broadcast MAC address, the RPR switch processing unit 520 receives the received RPR frame. Control for transferring the Ethernet frame encapsulated in the subordinate terminal (transfer control to the subordinate terminal) and control for transferring the received RPR frame to the adjacent RPR node (to the adjacent RPR node) Transfer control). Note that the operation related to the transfer to the subordinate terminal (steps S104 and S105) and the operation related to the transfer to the adjacent RPR node (steps S106 to S108) can be replaced or operated in parallel. is there. Here, the RPR switch processing unit 520 first performs transfer control to subordinate terminals.

  The RPR switch processing unit 520 sends the received RPR frame to the Ethernet frame extraction unit 530. At this time, the RPR switch processing unit 520 generates a copy of the RPR frame so that the received RPR frame can be transmitted to an adjacent RPR node, and then sends the RPR frame to the Ethernet frame extraction unit 530.

  The Ethernet frame extraction unit 530 of the RPR node 130 decapsulates the RPR frame sent from the RPR switch processing unit 520 and extracts the Ethernet frame stored in the payload. Then, the extracted Ethernet frame is transmitted from the output port 540-3 of the own node to the terminal under its own node (step S104). The Ethernet frame extraction unit 530 requests the FDB management unit 560 to perform MAC address learning based on the received RPR frame when extracting the Ethernet frame.

  The FDB management unit 560 of the RPR node 130 performs MAC address learning based on the received RPR frame in accordance with a request from the Ethernet frame extraction unit 530 (step S105). The FDB management unit 560 transmits the source MAC address of the Ethernet frame (here, the MAC address of the terminal 1401) stored in the payload of the received RPR frame and the source MAC address of the RPR frame (here, the RPR node 140). The MAC address learning related to the terminal 1401 is performed by registering the correspondence relationship with the MAC address) in the FDB 550.

  In this example, since no information is registered in the FDB 550, the FDB management unit 560 registers the correspondence relationship in the FDB 550 in response to a request from the Ethernet frame extraction unit 530. If the correspondence requested from the Ethernet frame extraction unit 530 is already registered in the FDB 550, the FDB management unit 560 may ignore the request from the Ethernet frame extraction unit 530. Note that it is possible for the Ethernet frame extraction unit 530 to check whether or not the registration has been made so that no request is issued to the FDB management unit 560. If the correspondence relationship different from the correspondence relationship requested from the Ethernet frame extraction unit 530 has already been registered in the FDB 550, the FDB management unit 560 overwrites and updates the information registered in the FDB 550.

  In addition, as a transfer control to the adjacent RPR node, the RPR switch processing unit 520 first subtracts 1 from the TTL value stored in the received RPR frame (step S106). If the TTL value after subtraction is greater than 0, the RPR switch processing unit 520 transmits the RPR frame to the next RPR node (Yes in step S107, S108). Specifically, the RPR switch processing unit 520 of the RPR node 130 stores the TTL after subtraction from the output port 540-2 of the own node to the RPR node 120 so as to transfer in the same direction as the transfer direction at the time of reception. Send a frame. If the TTL value is 0 as a result of the subtraction, the RPR switch processing unit 520 discards the RPR frame (No in step S107, S103).

  In this example, since the TTL value stored in the RPR frame received by the RPR node 130 is the TTL value (= 7) set by the RPR node 140, even if the RPR switch processing unit 520 subtracts 1 It will not be zero. Therefore, the RPR node 130 transfers the RPR frame storing the subtracted TTL to the adjacent RPR node 120.

  Thereafter, the RPR nodes 120, 170, 160, and 150 that belong to the RPR network 10 and are not interlink connection nodes operate in the same manner as the RPR node 130 described above, and transfer the RPR frame to the next RPR node. Therefore, the RPR frame broadcast from the RPR node 140 is transferred to the interlink connection node 110 via the RPR node 130 and the RPR node 120.

  Next, with reference to FIG. 10, an operation in which the interlink connection node belonging to the RPR network 10 transfers the broadcast-transmitted RPR frame will be described. FIG. 10 is a flowchart showing an example of the operation when the interlink connection node (in this example, the RPR node 110) receives the broadcast-transmitted RPR frame.

  As shown in FIG. 10, in an interlink connection node, an operation when a broadcast frame whose source MAC address is the MAC address of the own node is received (steps S101 to S103), and an operation related to transfer to an adjacent RPR node ( Steps S106 to S108) are the same as those of the above-described RPR node 130, but the operations (steps S201 to S204) related to the transfer to the subordinate terminal (that is, the interlink connection destination network) Steps S104 and S105) are different.

  That is, the interlink connection node in the present embodiment, even if the received RPR frame is a broadcast frame, depending on the conditions, the payload of the RPR frame is transmitted to the terminal under its node (that is, the interlink connection destination network). The Ethernet frame stored in may not be transmitted.

Here, the case where the interlink connection node 110 receives the RPR frame transferred from the RPR node 120 will be described as an example, but the operation of the interlink connection node 100 is the same as that of the interlink connection node 110.

  The RPR switch processing unit 520 of the interlink connection node 110 determines that the source MAC address of the received RPR frame is not the MAC address of the own node and the destination MAC address of the RPR frame is a broadcast MAC address. (No in step S102) First, it is determined whether or not to transmit an Ethernet frame to a subordinate terminal (interlink connection destination network). The RPR switch processing unit 520 determines whether or not to transmit the Ethernet frame stored in the payload of the RPR frame from the output port 540-3 based on conditions described later.

  The RPR switch processing unit 520 determines whether or not the source MAC address of the received RPR frame is the MAC address of an interlink connection node connected to the same interlink connection destination network as that of its own node (step S201). ). The RPR switch processing unit 520 may confirm the interlink connection node connected to the same interlink connection destination network as that of the own node by referring to the interlink connection node management table 610.

  Here, when the transmission source node of the received RPR frame is an interlink connection node connected to the same interlink connection destination network as that of its own node, this means that the RPR frame belongs to the interlink connection destination network. This indicates that the RPR frame is transferred via the interlink connection node indicated by the source MAC address. In such a case, the RPR switch processing unit 520 controls not to transfer to the interlink in order to prevent the occurrence of a broadcast storm caused by transferring the RPR frame to the interlink connection destination network again. Accordingly, when the source MAC address of the received RPR frame is the MAC address of the interlink connection node connected to the same interlink connection destination network as that of the own node, the RPR switch processing unit 520 It is determined that the Ethernet frame is not transmitted (Yes in step S201).

  Also, the RPR switch processing unit 520 determines whether or not a frame transmission completed identifier is added to the RPR frame (step S202).

  Here, the frame transmitted identifier is an identifier indicating that the Ethernet frame encapsulated in the RPR frame has already been transferred to the interlink connection destination network via another interlink. As a method for expressing a frame transmitted identifier, various methods can be used as shown in the following example. For example, it is defined that a frame transmission identifier is added when a field in an RPR frame header or an unused area of an interframe gap between RPR frames is used and the value of the bit is 1. In the case of 0, it may be defined that a frame transmission completed identifier is not added.

  Note that, when a frame transmitted identifier is expressed using an unused area or the like, the RPR frame to which the frame transmitted identifier is added must be received as a normal frame in an RPR node that is not an interlink connection node.

  In addition, if mutual connectivity with an RPR node that is not an interlink connection node is taken into account, a method of expressing using an RPR frame destination MAC address may be used. For example, if the destination MAC address of the RPR frame is a predetermined special multicast MAC address, it is defined that a frame transmission completed identifier is added, and if it is a broadcast MAC address, the frame transmission completed identifier is added. It is also possible to define that this is not done. If the special multicast MAC address is defined as the MAC address of the group to which all the RPR nodes belonging to the RPR network belong, the meaning is equivalent to the broadcast MAC address.

  In such a case, an RPR node that is not an interlink connection node transmits an RPR frame (multicast frame) whose destination MAC address is a special multicast MAC address, and an RPR frame (broadcast frame) whose destination MAC address is a broadcast MAC address. Since the frame is transferred in the same manner as in the above, it is possible to maintain the interconnectivity. Note that when a frame transmission completed identifier is expressed using a special multicast MAC address, the multicast MAC address cannot be used for the purpose of original multicast transmission, and must be treated as a reserved frame transmission identifier. .

  The frame transmission completed identifier is added by the interlink connection node that has transmitted the Ethernet frame to the subordinate terminal (interlink connection destination network).

  When a frame transmission completed identifier is added to the received RPR frame, the RPR switch processing unit 520 assumes that the RPR frame has already been transmitted to the interlink connection destination network by another interlink connection node, and again transmits the RPR frame. In order to prevent multiple reception within the transfer destination network due to transfer to the interlink connection destination network, control is performed not to transfer to the interlink. Therefore, the RPR switch processing unit 520 determines not to transmit the Ethernet frame to the subordinate terminal when the frame transmission completed identifier is added to the received RPR frame (Yes in step S202).

  Further, the RPR switch processing unit 520 determines whether or not the state of the port P3 of the own node is valid (step S203). The RPR switch processing unit 520 may confirm the state of the port P3 of the own node by referring to the port state table 600. When the state of the port P3 of the own node is invalid, the RPR switch processing unit 520 determines that transfer to the interlink connection destination network is impossible, and controls not to transfer to the interlink connection destination network. When the state of the port P3 of the own node is invalid, that is, when a failure has occurred in the interlink 430, the RPR switch processing unit 520 determines that the Ethernet frame is not transmitted to the subordinate terminal ( No in step S203).

  Further, the RPR switch processing unit 520 has a case other than the above, that is, a case where the transmission source MAC address of the received RPR frame is not the MAC address of the interlink connection node connected to the same interlink connection destination network as the own node. If the frame transmission identifier is not added to the RPR frame and the port status of the port P3 of the own node is valid, the subordinate terminal (interlink connection destination network) is connected to the Ethernet. It is determined that the frame is to be transmitted (Yes in step S201, Yes in S202, No in S230).

  Next, when it is determined that the RPR switch processing unit 520 transmits an Ethernet frame to a subordinate terminal, the RPR switch processing unit 520 transmits the Ethernet frame to the subordinate terminal (interlink connection destination network) in the same manner as the RPR node 130 described above. To do. That is, the RPR switch processing unit 520 sends the RPR frame to the Ethernet frame extraction unit 530. The Ethernet frame extraction unit 530 extracts an Ethernet frame from the RPR frame, and transmits the Ethernet frame from the output port 540-3 of its own node (step S104). At this time, the FDB management unit 560 performs MAC address learning by registering the correspondence between the MAC address of the terminal 1401 and the MAC address of the RPR node 140 in the FDB 550 based on the received RPR frame (step S105). ).

  On the other hand, when it is determined not to transmit the Ethernet frame to the subordinate terminal, the RPR switch processing unit 520 does not send the RPR frame to the Ethernet frame extracting unit 530 and does not transmit the Ethernet frame to the subordinate terminal. . Note that MAC address learning may be performed even when it is determined not to transmit an Ethernet frame to a subordinate terminal.

  Note that the RPR switch processing unit 520 transfers the RPR frame to an adjacent RPR node within an allowable range indicated by TTL regardless of whether or not to transmit an Ethernet frame to a subordinate terminal. The transfer of the RPR frame to the adjacent RPR node is executed by the same operation as that of the RPR node 130 described above. That is, the RPR switch processing unit 520 subtracts 1 from the TTL value stored in the received RPR frame (step S106). If the TTL value after the subtraction is greater than 0, the RPR frame is transferred to the next RPR node. (Yes in step S107, S108). If the TTL value is 0, the RPR frame is discarded (No in step S107, S103).

  However, in this embodiment, when the interlink connection node transfers the RPR frame to the adjacent RPR node, the interlink connection node performs the following operation according to the presence / absence of transfer to the subordinate terminal. When the RPR switch processing unit 520 determines to transmit an Ethernet frame to a subordinate terminal, the RPR switch processing unit 520 transmits a frame to the received RPR frame to indicate that the node has already been transferred to the interlink connection destination network. After the completed identifier is added (step S204), the RPR frame is transmitted to the next RPR node. For example, the RPR switch processing unit 520 rewrites the field in the header of the RPR frame or the 1-bit value of the unused area of the interframe gap included in the RPR frame, and transmits the RPR frame. . Further, for example, the RPR frame is transmitted after rewriting the destination address to a special multicast MAC address that has been determined in advance.

  If there is no interlink connection node connected to the same interlink connection destination network on the route from the self node to the TTL value of 0, the frame transmission identifier is not added. Also good. In the same case, it is also possible to delete the frame transmission completed identifier added by another interlink connection node.

  In this example, in the RPR frame received by the interlink connection node 110, the destination MAC address is the broadcast MAC address, the source MAC address is the MAC address of the RPR node 140, and the frame transmitted identifier Is not added, the interlink connection node 110 determines to transmit an Ethernet frame to a terminal under its control. Accordingly, the interlink connection node 110 transmits the Ethernet frame encapsulated in the received RPR frame to the RPR node 270 which is a subordinate terminal, and adds a frame transmission identifier to the next RPR node (RPR node 100). Transmit the RPR frame.

  In the interlink connection node, as already described, since it is necessary to add a frame transmission completed identifier to the RPR frame transferred to the adjacent RPR node depending on the presence / absence of transfer to the subordinate terminal, the RPR switch process The unit 520 must perform transfer control to an adjacent RPR node after determining whether or not to transmit an Ethernet frame to a subordinate terminal. After determining whether or not to transmit, it is possible to replace the operation related to the transfer to the subordinate terminal and the operation related to the transfer to the adjacent RPR node, but the transfer result to the subordinate terminal It is more preferable to receive and operate based on the result.

  Thereafter, the RPR node 100 that belongs to the RPR network 10 and is an interlink connection node operates in the same manner as the RPR node 110 described above, and transfers the RPR frame to the next RPR node. In the RPR node 100, since the RPR node 110 has added the frame transmission completed identifier, it is determined not to transmit the Ethernet frame to the subordinate terminal. Therefore, the RPR node 100 does not transmit the Ethernet frame encapsulated in the received RPR frame to the subordinate terminal RPR node 200, but subtracts 1 from the TTL value stored in the received RPR frame. Then, the RPR frame is transmitted to the next RPR node (RPR node 170).

  At this time, since the interlink connection node 100 does not have an interlink connection node connected to the same interlink connection destination network on the path from the self node to the TTL value of 0, the received RPR It is also possible to transmit the RPR frame to the RPR node 170 after deleting the frame transmission completed identifier added to the frame. Further, the RPR node 100 may perform MAC address learning even when it does not transmit an Ethernet frame to a subordinate terminal.

  Through the above operation, the RPR frame broadcast from the RPR node 140 is transferred to the interlink connection node 270 of the RPR network 20 by the interlink connection node 110 via the RPR node 130 and the RPR node 120. After being transferred in the order of the RPR node 100, RPR node 170, RPR node 160, and RPR node 150, since the TTL value of the RPR frame becomes 0, it is discarded by the RPR switch processing unit 520 of the RPR node 150. If the RPR node 140 sets the number of nodes including its own node (= 8) to TTL, after the RPR node 150 transfers to the RPR node 140, the source MAC address is the same as the MAC address of its own node. In order to match, it is discarded by the RPR switch processing unit 520 of the RPR node 140.

  If the RPR node 140 transmits an RPR frame from the output port 540-1, the RPR frame is transmitted by the interlink connection node 100 via the RPR node 150, RPR node 160 and RPR node 170. After being transferred to the interlink connection node 200 of the network 20 and in the order of the RPR node 110, the RPR node 120, and the RPR node 130, the TTL value of the RPR frame becomes 0. Discarded by the RPR switch processing unit 520.

  As described above, when the interlink connection node in the present embodiment receives a broadcast frame, the interlink connection node confirms the frame transmission completion identifier of the RPR frame and then sends it to the subordinate terminal (that is, the interlink connection destination network). Since an Ethernet frame is transmitted, while maintaining a communication order in which only one of the interlinks connected to the same interlink destination network is used to transfer to the interlink destination network, the occasional RPR Traffic can be distributed over a plurality of interlinks according to the frame transfer path and the interlink failure state.

  In the example shown in FIG. 1, any one of the RPR nodes 100 and 110 transmits an Ethernet frame (an Ethernet frame transmitted from a terminal 1401 under the RPR node 140) stored in the broadcast-transmitted RPR frame. Forward to the RPR network 20 via links 420, 430).

  Next, an operation from when an Ethernet frame is transferred from the RPR network 10 to the RPR network 20 until the Ethernet frame is transferred to a terminal under the RPR node 240 will be described. Here, as described above, the case where the Ethernet frame is transferred to the RPR node 270 via the interlink 430 by the interlink connection node 110 will be described as an example.

  When the Ethernet frame is transmitted by the interlink connection node 110, the RPR node 270 that is an interlink connection node belonging to the RPR network 20 receives the Ethernet frame. When the RPR node 270 receives the Ethernet frame transmitted from the RPR node 110 at the input port 500-3, the RPR node 270 transmits the Ethernet frame to the RPR frame generation unit 510. The operation when the RPR node 270 receives an Ethernet frame from a subordinate terminal is the same as that of an RPR node that is not an interlink connection node. That is, it is the same as the RPR node 140 described above.

  In this example, since the RPR node 270 fails to obtain the MAC address of the RPR node associated with the destination MAC address (here, the terminal 2401) of the Ethernet frame, the RPR node 270 stores the broadcast MAC address in the destination MAC address. In addition, an RPR frame in which the MAC address of the own node (RPR node 270) is stored in the source MAC address and an Ethernet frame is stored in the payload is generated. Then, the RPR frame is transmitted to the adjacent RPR node (RPR node 200).

  Hereinafter, an example in which the RPR node 270 transmits an RPR frame from the output port 540-1 after storing a number (= 7) obtained by subtracting 1 from the number of nodes of the RPR node belonging to the RPR network 20 in the TTL field. I will explain. The operations of other RPR nodes belonging to the RPR network 20 (an RPR node that is an interlink connection node and an RPR node other than the interlink connection node) are the same as those of an RPR node that belongs to the RPR network 10.

  The RPR node 200 that is an interlink connection node receives the RPR frame transmitted from the RPR node 270. The operation when the interlink connection node 200 receives the broadcast MAC address from the adjacent RPR node is the same as that of the interlink connection nodes 100 and 110 described above.

  Here, even if the destination MAC address of the received RPR frame is the broadcast MAC address, the interlink connection node 200 has the MAC address of the RPR node 270, that is, the same interlink connection as that of the own node. Since it is the MAC address of the interlink connection node connected to the destination network, it is determined not to transmit the Ethernet frame to the subordinate terminal.

  Therefore, the interlink connection node 200 does not transmit the Ethernet frame to the RPR node 100 which is a subordinate terminal, and subtracts the TTL value stored in the received RPR frame by 1, and then transmits the RPR frame. To the RPR node (RPR node 210).

  Thereafter, the RPR node 210, RPR node 220, RPR node 230, RPR node 240, RPR node 250, and RPR node 260 that belong to the RPR network 20 and are not interlink connection nodes operate in the same manner as the RPR node 130 described above. The RPR frame is transferred to the next RPR node within the allowable range indicated by TTL.

  Therefore, the RPR frame broadcasted from the RPR node 270 is transferred in the order of the RPR node 210, the RPR node 220, the RPR node 230, the RPR node 240, the RPR node 250, and the RPR node 260, and is under the RPR nodes 210 to 260. The Ethernet frame stored in the RPR frame is transmitted to the terminal.

  In other words, in this example, the Ethernet frame transmitted from the terminal 1401 is encapsulated into an RPR frame by the RPR node 140 and is once decapsulated by the interlink connection node 110 while being transferred to each RPR node belonging to the RPR network 10. And transferred to the interlink connection node 270 belonging to the RPR network 20. Then, it is encapsulated again by the interlink connection node 270, and decapsulated by the RPR node 240 and transferred to the terminal 2401 while being transferred to each RPR node of the RPR network 20.

  The RPR frame broadcast from the RPR node 270 is discarded by the RPR switch processing unit 520 of the RPR node 260 because the TTL value becomes 0 after being transferred to the RPR node 260. Also, in the FDB 550 of the RPR nodes 210 to 260, the correspondence relationship between the MAC address of the terminal 1401 and the MAC address of the RPR node 270 is registered as a result of MAC address learning. The interlink connection node 200 may perform MAC address learning.

  If the RPR node 270 transmits an RPR frame from the output port 540-2, the RPR frame is transmitted from the RPR node 260, the RPR node 250, the RPR node 240, the RPR node 230, the RPR node 220, and the RPR node 210. , RPR node 200 (interlink connection node 200) and then the TTL value of the RPR frame becomes 0, so that it is discarded by RPR switch processing unit 520 of RPR node 200. In such a case, since the source MAC address is the MAC address of the interlink connection node connected to the same interlink connection destination network as that of the own node, the interlink connection node 200 transmits the Ethernet to the subordinate terminal. Decide not to forward the frame.

  If the RPR node 200 receives an Ethernet frame transmitted from the RPR node 100 via the interlink 420, a broadcast frame having the source MAC address as the RPR node 200 is output to the output port 540-1, Alternatively, it is transmitted from either one of the output ports 540-2. In such a case, the correspondence between the MAC address of the terminal 1401 and the MAC address of the RPR node 200 is registered in the FDB 550 of each RPR node belonging to the RPR network 20.

  Next, on the assumption that the Ethernet frame is transferred from the terminal 1401 to the terminal 2401, an operation when the Ethernet frame is transferred (returned) from the terminal 2401 to the terminal 1401 will be described. In the frame transfer from the terminal 2401 to the terminal 1401 described below, MAC address learning related to the terminal 1401 is performed in the RPR node (the RPR node 240 and the interlink connection node belonging to the RPR network 10) that receives the Ethernet frame. This is an example.

  Here, it is assumed that the FDB 550 of each RPR node is in the following state when the frame transfer from the terminal 2401 to the terminal 1401 is performed.

  It is assumed that the correspondence between the MAC address of the terminal 1401 and the MAC address of the RPR node 140 is registered in the FDB 550 of all the RPR nodes belonging to the RPR network 10. Further, it is assumed that the correspondence between the MAC address of the terminal 1401 and the MAC address of the RPR node 270 is registered in the FDB 550 of all the RPR nodes belonging to the RPR network 20. Note that this state corresponds to the case where an interlink connection node that does not transfer an Ethernet frame to a subordinate terminal in the above description performs MAC address learning.

  First, the terminal 2401 transmits an Ethernet frame whose destination MAC address is the terminal 1401 to the RPR node 240. The input port 500-3 of the RPR node 240 receives the Ethernet frame. The Ethernet frame received by the input port 500-3 is sent to the RPR frame generation unit 510 of the RPR node 240.

  The RPR frame generation unit 510 of the RPR node 240 searches the FDB 550 of the RPR node 240 using the destination MAC address of the Ethernet frame as a search key, and the RPR node that accommodates the terminal indicated by the destination MAC address of the Ethernet frame. Get the MAC address. That is, the MAC address of the RPR node associated with the destination MAC address of the Ethernet frame (the MAC address of the terminal 1401) is retrieved from the FDB 550 and read.

  Here, the RPR frame generation unit 510 succeeds in acquiring the MAC address of the RPR node (RPR node 270). If acquisition of the MAC address is successful, the acquired MAC address is stored in the destination MAC address, the MAC address of the own node is stored in the source MAC address, and the payload receives from the terminal under the own node An RPR frame storing the Ethernet frame is generated. The RPR frame generation unit 510 sends the generated RPR frame to the RPR switch processing unit 520. If acquisition of the MAC address fails, the broadcast MAC address is set as the destination MAC address as in the case of the RPR node 140 described above.

  The RPR switch processing unit 520 of the RPR node 240 unicasts the RPR frame when the destination MAC address of the RPR frame is a node-specific MAC address, that is, when the RPR frame is a unicast frame. Specifically, the RPR switch processing unit 520 adds, in the TTL field of the RPR frame, a hop from the output port 540-1 or the output port 540-2 that actually outputs the RPR frame to the destination RPR node. After storing the number, an RPR frame is transmitted from either the output port 540-1 or the output port 540-2. The RPR switch processing unit 520 may confirm the hop count from the own node to the destination node by referring to the TDB 570 after determining the output port.

  Here, a case where the RPR switch processing unit 520 of the RPR node 240 transmits an RPR frame from the output port 540-2 will be described as an example. In this case, the TTL field stores the number of hops (= 5) from the RPR node 240 to the RPR node 270 in the counterclockwise route. When RPR node 240 transmits an RPR frame from output port 540-2, RPR node 230 receives the RPR frame.

  FIG. 11 is a flowchart illustrating an example of an operation performed when an RPR frame that is not an interlink connection node (an RPR node 230 in this example) receives a unicast-transmitted RPR frame. Basically, an RPR node that is not an interlink connection node may operate in accordance with “IEEE Std 802.17”.

  The RPR node 230 receives the RPR frame transmitted from the output port 540-2 of the RPR node 240 at the input port 500-1 (step S101). The RPR frame received by the input port 500-1 of the RPR node 230 is sent to the RPR switch processing unit 520.

  First, when the source MAC address of the RPR frame is the MAC address of the own node (Yes in step S102), the RPR switch processing unit 520 of the RPR node 230 first detects the RPR frame in order to prevent a broadcast storm from occurring due to the loop configuration. Is discarded (step S103). In this example, since the source MAC address of the RPR frame is the MAC address of the RPR node 240, the RPR switch processing unit 520 of the RPR node 230 does not perform this discarding process.

  Next, the RPR switch processing unit 520 determines that the source MAC address of the RPR frame is not the MAC address of the own node and the destination MAC address of the RPR frame is a node-specific (unicast) MAC address. Determines whether the destination MAC address of the RPR frame is the MAC address of its own node (step S301).

  If the destination MAC address of the received RPR frame is the MAC address of the own node, the RPR switch processing unit 520 performs transfer control to the subordinate terminal (Yes in step S301). Transfer control to subordinate terminals is the same as that of the RPR node 130 described above. That is, the RPR switch processing unit 520 sends the RPR frame to the Ethernet frame extraction unit 530 when the MAC address of the received RPR frame matches the MAC address of its own node. The Ethernet frame extraction unit 530 extracts the Ethernet frame from the RPR frame, and transmits the Ethernet frame from the output port 540-3 of its own node to the subordinate terminal (step S104). At this time, the FDB management unit 560 performs MAC address learning by registering the correspondence relationship between the MAC address of the terminal 2401 and the RPR node 240 in the FDB 550 (step S105).

  On the other hand, when the destination MAC address of the received RPR frame is not the MAC address of the own node, the RPR switch processing unit 520 performs transfer control to the adjacent RPR node (No in step S301). Note that transfer control to an adjacent RPR node is the same as that of the RPR node 130 described above. That is, if the destination MAC address of the received RPR frame does not match the MAC address of the own node, the RPR switch processing unit 520 subtracts 1 from the TTL value stored in the RPR frame (step S106). If the TTL value after subtraction is greater than 0, the RPR frame is transmitted to the next RPR node (Yes in step S107, S108). If the TTL value is 0 as a result of the subtraction, the RPR switch processing unit 520 discards the RPR frame (No in step S107, S103).

  In this example, since the destination MAC address of the unicast frame transmitted from the RPR node 240 is not the MAC address of the RPR node 230, the RPR node 230 subtracts TTL without transmitting the Ethernet frame to the subordinate terminal. After that, the RPR frame is transferred to the next RPR node (RPR node 220).

  Thereafter, the RPR nodes 220 and 210 that belong to the RPR network 20 and are not interlink connection nodes operate in the same manner as the RPR node 230 described above, and transfer the RPR frame to the next RPR node. Accordingly, the RPR frame unicast transmitted from the RPR node 240 is transferred to the RPR node 200 that is an interlink connection node via the RPR node 230, the RPR node 220, and the RPR node 210. In each RPR node, MAC address learning may be performed even when an Ethernet frame is not transferred to a subordinate terminal.

  Next, referring to FIG. 12, the RPR frame in which the interlink connection nodes belonging to the RPR network 20, that is, the RPR nodes 200 and 270, are unicast-transmitted (the RPR frame whose destination MAC address is a node-specific MAC address). The operation of transferring the will be described.

  FIG. 12 is a flowchart showing an example of the operation when the interlink connection node (the RPR node 200 in this example) receives the unicast-transmitted RPR frame. As shown in FIG. 12, an operation when a unicast frame whose source MAC address is the MAC address of its own node is received (steps S <b> 101 to 103) and an operation related to transfer to an adjacent RPR node (steps S <b> 106 to S <b> 108). Is the same as that of the RPR node 230 described above, but the operations (steps S201, S401 to S405, and S104 to S105) related to the transfer to the subordinate terminal (that is, the interlink connection destination network) are the operations of the RPR network 230 described above. (Steps S301, S104 to S105) are different.

  That is, the interlink connection node according to the present embodiment allows a terminal (that is, an interlink connection destination network) under its own node depending on conditions even if the received RPR frame is a unicast frame other than that addressed to the own node. Thus, an Ethernet frame stored in the payload of the RPR frame may be transmitted. Further, when the unicast frame addressed to the own node cannot be transmitted, the RPR frame may be transferred to the adjacent RPR node.

  Here, the case where the interlink connection node 200 receives the RPR frame transferred from the RPR node 210 will be described as an example. However, the operation of the interlink connection node 270 is the same as that of the interlink connection node 200.

  The interlink connection node 200 receives the RPR frame transmitted from the output port 540-2 of the RPR node 210 at the input port 500-1 (step S101). The RPR frame received by the input port 500-1 of the RPR node 200 is sent to the RPR switch processing unit 520.

  First, when the source MAC address of the RPR frame is the MAC address of the own node (Yes in step S102), the RPR switch processing unit 520 of the interlink connection node 200 prevents the occurrence of a broadcast storm due to the loop configuration. The RPR frame is discarded (step S103). In this example, since the source MAC address of the RPR frame is the MAC address of the RPR node 240, the RPR switch processing unit 520 of the RPR node 200 does not perform this discarding process.

  Next, the RPR switch processing unit 520 is a case where the source MAC address of the RPR frame is not the MAC address of the own node, and the destination MAC address of the RPR frame is a node-specific (unicast) MAC address. Determines whether the RPR frame is destined for the interlink connection destination network of the own node.

  First, the RPR switch processing unit 520 determines whether or not the source MAC address of the received RPR frame is the MAC address of an interlink connection node connected to the same interlink connection destination network as that of its own node ( Step S201).

  When the source MAC address of the RPR frame is the MAC address of the interlink connection node connected to the same interlink connection destination network as that of the own node (Yes in step S201), the RPR frame is the interlink connection destination. Assuming that the RPR frame is transmitted from the network, in order to prevent the occurrence of a broadcast storm due to the transfer of the RPR frame to the interlink connection destination network again, control is performed not to transfer to the subordinate terminal. Therefore, it is determined that the RPR frame is not addressed to the interlink connection destination network.

  Also, the RPR switch processing unit 520 determines whether or not the destination MAC address of the RPR frame is the MAC address of an interlink connection node (including the own node) connected to the same interlink connection destination network as the own node. Determination is made (step S401). For example, the RPR switch processing unit 520 determines whether or not the transmission source MAC address of the RPR frame matches the MAC address of the interlink connection node registered in the interlink connection node management table 610. When the interlink connection node management table 610 does not include the MAC address of the own node, it may be further determined whether or not it matches the MAC address of the own node registered in the MAC address management table 580. . When the destination MAC address of the RPR frame is not the MAC address of the interlink connection node connected to the same interlink connection destination network as that of the own node (No in step S401), the RPR switch processing unit 520 Is not addressed to the interlink connection destination network.

  Further, the RPR switch processing unit 520 has a case other than the above, that is, a case where the transmission source MAC address of the received RPR frame is not the MAC address of the interlink connection node connected to the same interlink connection destination network as the own node. If the destination MAC address is the MAC address of an interlink connection node connected to the same interlink connection destination network as that of the own node, the RPR frame is determined to be addressed to the interlink connection destination network. (Yes in step S201, No in S401).

  Next, when the RPR switch processing unit 520 determines that the received RPR frame is not addressed to the interlink connection destination network, the RPR switch processing unit 520 transmits the RPR frame to the adjacent RPR node as in the case of the RPR node 230 described above. That is, the RPR switch processing unit 520 subtracts 1 from the TTL value stored in the RPR frame (step S106), and if the TTL value after the subtraction is greater than 0, the RPR frame is transferred to the next RPR node. Transmit (Yes in step S107, S108). If the TTL value is 0 as a result of the subtraction, the RPR frame is discarded (No in step S107, S103).

  On the other hand, when it is determined that the received RPR frame is addressed to the interlink connection destination network, the RPR switch processing unit 520 determines whether or not the state of the port P3 of the own node is valid (step S402). When the received RPR frame is addressed to the interlink connection destination network and the state of the port P3 of the own node is valid (Yes in step S402), the RPR switch processing unit 520 is the same as the RPR node 230 described above. Then, the Ethernet frame is transmitted to the subordinate terminal (interlink connection destination network). That is, the RPR switch processing unit 520 sends the RPR frame to the Ethernet frame extraction unit 530. The Ethernet frame extraction unit 530 extracts an Ethernet frame from the RPR frame, and transmits the Ethernet frame from the output port 540-3 of the local node to a terminal (interlink connection destination network) under the local node (Step S104). . At this time, the FDB management unit 560 performs MAC address learning by registering the correspondence relationship between the MAC address of the terminal 2401 and the RPR node 240 in the FDB 550 based on the received RPR frame (step S105).

  In addition, even if the received RPR frame is addressed to the interlink connection destination network, the RPR switch processing unit 520 has a failure in the interlink 420 when the state of the port P3 of the own node is invalid. In this case (No in step S402), the RPR frame arrives at another interlink connection node connected to the same interlink connection destination network as that of its own node, because it cannot be transferred to the interlink connection destination network. It works as follows.

  When the destination MAC address of the received RPR frame is not the MAC address of the own node (No in step S403), the RPR switch processing unit 520 performs transfer control to a normal adjacent RPR node. That is, the RPR switch processing unit 520 subtracts 1 from the TTL value stored in the RPR frame (step S106), and if the TTL value after the subtraction is greater than 0, the RPR frame is transferred to the next RPR node. Transmit (Yes in step S107, S108). If the TTL value is 0 as a result of the subtraction, the RPR frame is discarded (No in step S107, S103).

  On the other hand, when the destination MAC address of the received RPR frame is the MAC address of the own node (Yes in step S403), the RPR switch processing unit 520 sets the TTL value set so as to reach the own node. Is set so as to reach another interlink connection node connected to the same interlink connection destination network as that of its own node, and the RPR frame is transferred to the next RPR node (steps S404 and S108). That is, if the RPR frame is addressed to the own node, the RPR switch processing unit 520 changes the TTL value to the number of hops to another interlink connection node, and transmits the RPR frame to the next RPR node.

  In this example, since the Ethernet frame transmitted by the terminal 2401 is transmitted as a unicast frame addressed to the RPR node 270 from the RPR node 240, the interlink connection node 200 has the same destination address as that of its own node. The MAC address of the interlink connection node connected to the network is determined to be addressed to the interlink connection destination network. Therefore, if the port P3 of the own node is valid, the interlink connection node 200 does not transfer the RPR frame to the adjacent RPR node (RPR node 270), but transmits the Ethernet frame to the RPR node 100 that is a subordinate terminal. Send.

  Even if the MAC address of the terminal 1401 and the MAC address of the RPR node 200 are associated with the FDB 550 of each RPR node belonging to the RPR network 20, it is transmitted as a unicast frame addressed to the RPR node 200 from the RPR node 240. The transfer operation is the same except for the difference.

  If the RPR node 240 transmits an RPR frame from the output port 540-1, the RPR frame is transferred to the RPR node 270 that is an interlink connection node via the RPR nodes 250 and 260. . Here, the RPR node 270 assumes that the received RPR frame is the MAC address of an interlink connection node (in this case, the local node) connected to the same interlink connection destination network as the local node, and It is determined that it is addressed. Accordingly, if the port P3 of the own node is valid, the interlink connection node 270 does not transfer the RPR frame to the adjacent RPR node (RPR node 200), but transmits the Ethernet frame to the RPR node 110 which is a subordinate terminal. Send.

  As described above, when an interlink connection node in the present embodiment receives a unicast frame, the interlink connection node is not limited to the case where the RPR frame is addressed to the own node, If it is addressed to another interlink connection node to be connected, an Ethernet frame is transmitted to the subordinate terminal (that is, the interlink connection destination network), and therefore, among the interlinks connected to the same interlink connection destination network. The traffic is distributed to multiple interlinks according to the transfer path of the RPR frame and the failure state of the interlink while maintaining the communication order of transferring to the interlink destination network using only one of be able to.

  In the example shown in FIG. 1, any one of the RPR nodes 200 and 270 interlinks an Ethernet frame (an Ethernet frame transmitted by a terminal 2401 under the control of the RPR node 240) stored in a unicast-transmitted RPR frame. The data is transferred to the RPR network 10 via the interlinks 420 and 430).

  Next, an operation from when an Ethernet frame is transferred from the RPR network 20 to the RPR network 10 until the Ethernet frame is transferred to a terminal under the RPR node 140 will be described. Here, a case where an Ethernet frame is transferred to the RPR node 100 via the interlink 420 by the RPR node 200 will be described as an example.

  The operation when each RPR node (including the interlink connection node) belonging to the RPR network 10 receives a unicast frame is the same as that of each RPR node belonging to the RPR network 20. In this example, when the RPR node 100 which is an interlink connection node receives the Ethernet frame transmitted from the RPR node 200, the MAC address of the RPR node associated with the destination MAC address of the Ethernet frame (here, the terminal 1401). (In this case, in order to successfully acquire the RPR node 140), the MAC address of the RPR node 140 is stored in the destination MAC address, and the MAC address of the own node (RPR node 100) is stored in the source MAC address. An RPR frame in which an Ethernet frame is stored in the payload is generated.

  Here, when the RPR node 100 transfers the RPR frame from the output port 540-2, the number of hops in the counterclockwise route from the RPR node 100 to the RPR node 140 is set in the TTL field of the RPR frame (= 4). And the RPR frame is transmitted to the next RPR node (RPR node 170).

  Thereafter, the unicast frame addressed to the RPR node 140 transmitted from the RPR node 100 is transferred in the order of the RPR node 170, the RPR node 160, the RPR node 150, and the RPR node 140, and is transmitted to the subordinate terminal 1401 by the RPR node 140. The Ethernet frame stored in the RPR frame is transmitted.

  If the RPR node 100 transfers the RPR frame from the output port 540-1, the TTL field of the RPR frame includes the number of hops in the clockwise route from the RPR node 100 to the RPR node 140 (= 4 ) Is stored and then transferred to the next RPR node (RPR node 110). Here, the interlink connection node 110 is an interlink connection node in which the transmission source node (RPR node 100) of the received RPR frame is connected to the same interlink connection destination network as its own node, or has been received Since the destination node (RPR node 140) of the RPR frame is not an interlink connection node connected to the same interlink connection destination network as that of the own node, it is determined that the RPR frame is not addressed to the interlink connection destination network. Therefore, the RPR frame is transferred to the next RPR node (RPR node 120) without transmitting the Ethernet frame to the subordinate terminal.

  In the above, the frame transfer operation at the normal time has been described by taking the communication between the terminal 1401 and the terminal 2401 as an example. In the present embodiment, an interlink through which an Ethernet frame transferred between different networks normally passes is an interlink connected to an interlink connection node that first receives an RPR frame in which the Ethernet frame is encapsulated. It is. For example, when an Ethernet frame is encapsulated and transferred to an adjacent RPR node, control is performed such as switching the transmission direction (either clockwise or counterclockwise) for each RPR frame. By distributing the interlink connection nodes to be received, traffic flowing between different networks can be distributed to a plurality of interlinks. Therefore, since it is possible to suppress the occurrence of congestion due to the concentration of traffic on one interlink, it is possible to construct a highly reliable communication system.

  Next, a failure recovery operation when a failure such as disconnection occurs in any interlink will be described. Here, a failure recovery operation for continuing communication between RPR networks only by the interlink 430 will be described by taking as an example a case where a failure has occurred in the interlink 420.

  When a failure occurs in the interlink 420, for example, the port state monitoring unit 590 of the RPR node 100 disables the port P3 (input port 500-3 or output port 540-3) of the own node (a state where the port cannot be operated). It detects that it became. Then, the port status monitoring unit 590 changes the port status registered in the port status table 600 to “invalid”. Similarly, the port status monitoring unit 590 of the RPR node 200 also detects that the port P3 of its own node has become invalid, and changes the port status registered in the port status table 600 to “invalid”.

  The broadcast frame and unicast frame transfer operation of the interlink connection node is performed only when the state of the port P3 of the own node is valid as described in the frame transfer operation in the normal state. That is, the Ethernet frame is transferred to the interlink connection destination network via the interlink.

  Here, the failure recovery operation will be described by taking as an example a case where a failure has occurred in the interlink connected to the first received interlink connection node.

  For example, when MAC address learning is not performed in each RPR node, the RPR node 140 transmits a broadcast frame storing an Ethernet frame addressed to the terminal 2401 transmitted from the subordinate terminal 1401 from the output port 540-1. Then, the broadcast frame transferred from the RPR node 140 is transferred to the interlink connection node 100 via the RPR nodes 150, 160, and 170.

  Here, when a failure has occurred in the interlink 420, as shown in FIG. 10, the interlink connection node 100 has received a broadcast frame whose source MAC address is not its own MAC address. However, since the state of the port P3 of the own node is invalid, it is determined not to transmit the Ethernet frame to the subordinate terminal. Therefore, the RPR frame is transferred to the next RPR node (RPR node 110) without transmitting the Ethernet frame to the subordinate terminal (interlink connection destination network) and without adding the frame transmission completed identifier to the RPR frame. To do.

  The interlink connection node 110 is not the MAC address of the interlink connection node that is connected to the same interlink connection destination network as the source node, and the frame transmission identifier is not added. If the port P3 of the node is valid, it is determined that the Ethernet frame is transmitted to the subordinate terminal. Therefore, the Ethernet frame is transmitted to the subordinate terminal (interlink connection destination network) and the RPR frame is transferred to the next RPR node (RPR node 120). In this case, since there is no interlink connection node connected to the same interlink connection destination network on the path from the interlink connection node 110 to the TTL value of 0, a frame transmitted identifier is added. You don't have to.

  For example, when MAC address learning is performed in each RPR node, the RPR node 140 uses an RPR frame storing an Ethernet frame addressed to the terminal 2401 transmitted from the subordinate terminal 1401 as a destination MAC address, for example. Is transmitted from the output port 540-1 as a unicast frame with the MAC address of the RPR node 100.

  Here, when a failure has occurred in the interlink 420, as shown in FIG. 12, the interlink connection node 100 has the same source MAC address (the MAC address of the RPR node 140) as that of its own node. It is not the MAC address of the interlink connection node connected to the link connection destination network, and the destination MAC address (here, the MAC address of the RPR node 100) is connected to the same interlink connection destination network as that of the own node. Even when the unicast frame that is the MAC address of the link connection node is received, the state of the port P3 of the own node is invalid, and thus the Ethernet frame is not transmitted to the subordinate terminal. Then, the interlink connection node 100 sets the value of TTL to the number of hops from the own node to another interlink connection node (in this case, up to the RPR node 110) so that the RPR frame reaches the other interlink connection node. And then the RPR frame is transferred to the next RPR node (RPR node 110).

  Then, it is determined by the RPR node 110 that is an interlink connection node that it is addressed to the interlink connection destination network of the local node, and then transmitted to the RPR node 270 via the interlink 430.

  Note that when the RPR node 140 transmits from the output port 540-2, a failure of the interlink 420 occurs regardless of whether the interlink connection node 110 is a broadcast frame or a unicast frame addressed to the RPR node 100. Regardless of the state, the data is transferred to the interlink connection destination network via the interlink 430 as in the normal state.

  Thereafter, the broadcast frame is transferred to the RPR node 100 after the frame transmission completed identifier is added. Since the RPR node 100 adds a frame identifier to the received RPR frame, even if the failure of the interlink 420 is recovered at this time, the RPR node 100 does not transmit the Ethernet frame to the subordinate terminal. Transfer to the next RPR node (RPR node 170).

  As described above, according to the present embodiment, even if a failure has occurred in the interlink 420, it is transferred by the interlink connection node 110 via the normal interlink 430. Communication between the network 10 and the RPR network 20 can be continued.

  Whether or not the interlink connection node transmits an Ethernet frame to the interlink based on the received RPR frame information and the state of the interlink connection port (port P3) in the node even when a failure occurs. For example, it is possible to control traffic without exchanging a special control frame between interlink connection nodes.

  When an interlink failure is recovered, the interlink connection nodes (in this case, the RPR node 100 and the RPR node 200) connected to the interlink detect the failure recovery, and the interlink of the own node is detected. By changing the state of the connection port (port P3) to valid, the normal frame transfer operation is restored. That is, it returns to a state in which a frame is transferred while distributing traffic to both the interlink 420 and the interlink 430. Here, whether or not to return to the normal frame transfer operation can also be determined based on the state of the interlink connection port in the own node, so that other interlink connection nodes and the failure information are mutually notified. It is possible to return at high speed without requiring any inter-node protocol.

  Next, a failure recovery operation when a failure occurs in any interlink connection node will be described. Here, a case where a failure occurs in the RPR node 100 that is an interlink connection node will be described as an example. When a failure occurs in the RPR node 100, an RPR node that is not an interlink connection node belonging to the RPR network 10 operates in accordance with “IEEE Std 802.17” to operate traffic.

  When such a failure occurs, other RPR nodes belonging to the RPR network 10 cannot communicate with the RPR node 100 by TDP (Topology Discovery Protocol) defined in “IEEE Std 802.17”. Recognize that Specifically, a node adjacent to the RPR node 100 detects an abnormality of a port that transmits / receives an RPR frame to / from the RPR node 100. Then, another RPR node is notified by broadcasting a TP frame indicating an abnormality of the port at a constant time interval. Each RPR node that has received the TP frame updates its own TDB 570. Then, each RPR node bypasses the RPR frame toward the RPR node 100 based on the TDB 570 of its own node.

  For example, a broadcast frame is transferred to all RPR nodes belonging to the RPR network 10 excluding the RPR node 100 while bypassing the RPR node 100 by controlling the communication direction, TTL, and the like using a protection function called Wrapping. be able to. Further, for example, a unicast frame addressed to the RPR node 110 can be transferred to the RPR node 110 while bypassing the RPR node 100 by using a protection function called Steering or Wrapping.

  For example, even if the frame is a unicast frame addressed to the RPR node 100, it can be received by the RPR node 110, which is another interlink connection node, in the process of bypassing the RPR node 100 using a protection function called Wrapping. . For example, in the case of a unicast frame addressed to the RPR node 100 transmitted in the clockwise direction from the RPR node before the failure occurs, the transfer direction is changed in the reverse direction (counterclockwise) by the RPR node 170 and transferred. The As a result, the data is transferred to the RPR node 110 via the RPR node 160, the RPR node 150, the RPR node 140, the RPR node 130, and the RPR node 120. Since the TTL of the RPR frame is not subtracted after the transfer direction is changed, the TTL of the RPR frame received by the RPR node 110 remains the number of hops (1 hop) from the RPR node 170 to the RPR node 100. is there. In addition, if a failure has occurred, the RPR frame addressed to the RPR node 100 is transmitted as a broadcast frame, and therefore, it is transferred to all the RPR nodes belonging to the RPR network 10 excluding the RPR node 100 while bypassing the RPR node 100. Can do.

  When transferred to the RPR node 110 that is an interlink connection node, the RPR node 110 transmits the Ethernet frame stored in the RPR frame to the RPR node 270 via the interlink 420. The operation of the interlink connection node 110 transmitting the Ethernet frame to the subordinate terminal is the same as that in the case where a failure occurs in the interlink 420 described above.

  As described above, even if a failure occurs in the RPR node 100 that is an interlink connection node, other RPR nodes are protected by Wrapping or Steering as defined in “IEEE Std 802.17”. By using the function, it is transferred to the RPR node 110 which is another interlink connection node. Then, since the data is transferred by the interlink connection node 110 via the normal interlink 430, communication from the RPR network 10 to the RPR network 20 is continued.

  For communication from the RPR network 20 to the RPR network 10, the port state monitoring unit 590 of the interlink connection node 200 connected to the interlink connection node 100 via the interlink detects a failure of the interlink 420. As described above, similarly to the above-described failure recovery operation at the time of an interlink failure, control can be performed via another interlink (interlink 430) and the operation can be continued.

  Next, a failure recovery operation when a failure occurs in any of the interlink connection nodes and the link between the adjacent RPR nodes will be described. Here, a case where a failure has occurred in the link between the RPR node 100 and the RPR node 170 and the link between the RPR node 100 and the RPR node 110 will be described as an example.

  When such a failure occurs, other RPR nodes belonging to the RPR network 10 cannot communicate with the RPR node 100 by TDP (Topology Discovery Protocol) defined in “IEEE Std 802.17”. Recognize that Here, communication from the RPR network 10 to the RPR network 20 can be continued by an operation similar to the failure recovery operation when a failure occurs in the interlink connection node 100 described above.

  However, for communication from the RPR network 20 to the RPR network 10, since no failure has occurred in the interlink 420, it is not recognized that the interlink 420 has become virtually unusable in the interlink connection node 200. For this reason, there is a possibility that communication may be interrupted when the interlink connection node 200 continues to transfer traffic by distributing traffic to the interlink 420 and the interlink 430 as in the normal state.

  In order to avoid this problem, in the interlink connection node according to the present embodiment, both of the two links between the own node (RPR node 100) and the adjacent RPR nodes (RPR node 110 and RPR node 170) fail. When this occurs, the interlink side port (port P3) is intentionally brought down (stopped) in order to cause the interlink connection destination node (RPR node 200) to detect an interlink failure. For example, the port status monitoring unit 590 closes the port P3, and the RPR switch processing unit 520 performs control such as stopping the exchange of control frames for detecting a link failure.

  As a result, the interlink connection node 200 detects an abnormality in the interlink 420 and controls the RPR network 20 to the RPR network by controlling to go through other interlinks similarly to the above-described failure recovery operation at the time of the interlink failure. Communication to 10 can be continued.

  Note that when one of the two links between the RPR node adjacent to the own node and the RPR node recovers, the RPR node 100 causes the interlink connection destination node to detect the recovery of the interlink failure. Bring up (restart) the link side port. For example, control such as opening a port or restarting exchange of control frames for detecting a link failure is performed.

  As described above, even when a failure occurs in both the interlink connection node and the link between the adjacent RPR nodes, the RPR network 10 is intentionally stopped by intentionally stopping the interlink side port of the interlink connection node. And the RPR network 20 can be maintained.

  Note that in either one or both of the RPR network 10 and the RPR network 20, when a failure occurs in a link between RPR nodes, or when a failure occurs in an RPR node other than the interlink connection node, The RPR node uses Steering or Wrapping defined in “IEEE Std 802.17” to continue communication between normal RPR nodes. That is, it is possible to continue communication between the RPR network 10 and the RPR network 20 as long as all the routes to the destination are not blocked.

  As described above, according to the present embodiment, in frame transfer between different networks, only one of the interlinks connected to the same interlink connection destination network is used for one RPR frame. The traffic can be distributed to a plurality of interlinks according to the transfer path of the RPR frame and the failure state of the interlink while maintaining the communication order of transferring to the interlink connection destination network. While preventing the occurrence of multiple receptions and broadcast storms, it is possible to expand the communication band of links between networks and suppress the occurrence of congestion.

  In this embodiment, since only one interlink connection node transfers the Ethernet frame stored in the RPR frame via the interlink, an extra frame is transferred to an interlink where traffic is likely to concentrate. The occurrence of congestion can be suppressed more effectively.

  Even when a failure occurs in an interlink or an interlink connection node, a frame can be transferred via another normal interlink, so that communication can be continued.

  Furthermore, since the above effect does not require an inter-link connection node protocol that specifically exchanges information between inter-link connection nodes, it does not generate extra traffic, and in the event of a failure, compared to the prior art. The failure recovery process can be started very quickly.

Embodiment 2. FIG.
Below, the 2nd Embodiment of this invention is described with reference to drawings. The configuration of the communication system according to the present embodiment is the same as that of the first embodiment shown in FIG. The configurations of the RPR node and the interlink connection node according to this embodiment are the same as those of the first embodiment shown in FIGS.

  The communication system according to the present embodiment is different from the first embodiment in the broadcast frame transfer method in the RPR network. In the first embodiment, an example in which a broadcast frame is transferred by a broadcast transfer method called “unidirectional broadcast” in “IEEE Std 802.17” has been described. In the broadcast transfer method called Unidirectional Broadcast, the number of RPR nodes constituting the RPR network or the number obtained by subtracting 1 from the number of nodes is set in the TTL field of the RPR frame, and the clockwise direction and the counterclockwise direction are set. It is a method of transmitting in any one direction.

  On the other hand, “IEEE Std 802.17” also discloses a broadcast transfer method called Bidirectional Broadcast. In the broadcast transfer method called Bidirectional Broadcast, the RPR frame is duplicated, and the value of ½ of the value obtained by subtracting 1 from the number of RPR nodes constituting the RPR network is set in the TTL field of each RPR frame. , One is transmitted in the clockwise direction and the other is transmitted in the counterclockwise direction.

  For example, when the number of nodes is even, the maximum natural number that does not exceed 1/2 of the value obtained by subtracting 1 from the number of nodes in the TTL field of one RPR frame, and 1 from the number of nodes is subtracted from the other. A minimum natural number exceeding 1/2 of the value is set.

  Each broadcast frame transmitted in both directions is sequentially transferred to the next RPR node until the respective TTL value becomes 0, and is discarded when the TTL becomes 0. A link between RPR nodes where each broadcast frame transmitted in both directions is discarded is referred to as “Clave Point”.

  For example, in the communication system shown in FIG. 1, the broadcast frame transmitted from the RPR node 140 is 4 in the TTL of the RPR frame to be transferred in the clockwise direction and RPR frame to be transferred in the counterclockwise direction in the transfer by Bidirectional Broadcast. The TTL is set to 3 and transferred. The Clear Point at this time is a link between the RPR node 100 where the RPR frame transferred in the clockwise direction is discarded and the RPR node 110 where the RPR frame transferred in the counterclockwise direction is discarded (RPR node 100-RPR). Link between nodes 110).

  When such a broadcast method is performed, the following problems occur in the interlink connection node in the first embodiment. Even if an interlink connection node (for example, RPR node 100) transfers an Ethernet frame to a subordinate terminal via an interlink and adds a frame transmission identifier to the RPR frame, another interlink connection node (for example, RPR node 110) may transfer the RPR frame transferred in the reverse direction without transferring the RPR frame. In such a case, the interlink connection node cannot recognize that it has already been transferred by another interlink connection node, and transfers the Ethernet frame again.

  That is, the Ethernet frame is transmitted twice from the two paths of the interlink 430 and the interlink 420 without recognizing the frame transmission completed identifier. As a result, the terminal that is the destination of the Ethernet frame receives an Ethernet frame that should be received only once, a plurality of times.

  Note that, in the first embodiment, such a problem does not occur because a transfer method using the Unidirectional Broadcast that transmits a broadcast frame only in one of the clockwise direction and the counterclockwise direction is used. .

  Hereinafter, a method for solving the above-described problem in a communication system that performs broadcast transfer using Bidirectional Broadcast will be described. FIG. 13 is a flowchart illustrating an example of an operation performed when an RPR node that is an interlink connection node receives an RPR frame that has been broadcast by Bidirectional Broadcast.

  As shown in FIG. 13, when the interlink connection node receives the broadcast frame, the operation (steps S101 to S103) when the transmission source MAC address is the MAC address of its own node (steps S101 to S103) is the first operation shown in FIG. This is the same as the embodiment.

  In the present embodiment, the above-mentioned problem in the communication system that performs broadcast transfer by Bidirectional Broadcast is solved by classifying each RPR node other than the interlink connection node into a group subordinate to each interlink connection node. A method for classifying each RPR node into a group subordinate to the interlink connection node will be described later.

  As shown in FIG. 13, in the interlink connection node according to the present embodiment, the interlink side port (port P3) is valid, and the own node first transmits the frame in the transfer path from the transmission source node. Ethernet that is received in the frame and stored in the frame of the subordinate terminal (that is, the interlink connection destination network) when the transmission source node belongs to the group assigned to the own node. Send a frame.

  The RPR switch processing unit 520 of the interlink connection node, when the source MAC address of the received RPR frame is not the MAC address of the own node and the destination MAC address of the RPR frame is a broadcast MAC address ( In step S102, No), it is determined whether or not to transmit an Ethernet frame to a subordinate terminal (that is, an interlink connection destination network). The RPR switch processing unit 520 determines whether or not to transmit an Ethernet frame to a subordinate terminal based on conditions different from those in the first embodiment when the received broadcast frame is transferred using a transfer method based on Bidirectional Broadcast. To decide. The broadcast transfer method can be recognized by referring to a field indicating the broadcast transmission method included in the header information of the received RPR frame. If they are unified in the system, they may be fixedly operated as a predetermined transfer method.

  First, when the source MAC address of the received RPR frame is the MAC address of the interlink connection node connected to the same interlink connection destination network as that of the own node, the RPR switch processing unit 520 Is determined to be an RPR frame transmitted from the interlink connection destination network, and it is determined not to transmit an Ethernet frame to a subordinate terminal (Yes in step S201).

  Next, the RPR switch processing unit 520 determines whether or not the own node is the first interlink connection node that has received the RPR frame (step S501). The RPR switch processing unit 520 confirms the transfer path of the RPR frame (recognizes the transfer direction and start point) based on, for example, the RPR frame reception port and the transmission source MAC address. Then, referring to the TDB 570, it is determined by checking whether or not the MAC address registered in the interlink connection node management table 610 is arranged on the transfer path.

  If the own node is the first interlink connection node that has received the RPR frame (Yes in step S501), the RPR switch processing unit 520 determines whether the transmission source node belongs to the group assigned to the own node. It is determined whether or not (step S502). When the transmission source node belongs to the group assigned to the own node (Yes in step S502), the RPR switch processing unit 520 determines whether the state of the port P3 of the own node is valid (step S503). ).

  Here, if the state of the port P3 of the own node is valid, it is determined that the Ethernet frame is transmitted to the subordinate terminal (Yes in step S503). That is, the RPR switch processing unit 520 is a case where the transmission source MAC address of the received RPR frame is not the MAC address of the interlink connection node connected to the same interlink connection destination network as the self node, and the self node Is the first interlink connection node that received the RPR frame, and the source MAC address of the RPR frame is the MAC address of the RPR node belonging to the group assigned to the own node. In addition, when the port state of the port P3 of the own node is valid, it is determined that the Ethernet frame is transmitted to the subordinate terminal (that is, the interlink connection destination network).

  Also, even if the RPR switch processing unit 520 is not the first interlink connection node that has received the RPR frame (No in step S501), the RPR switch processing unit 520 does not add the frame transmission completed identifier to the RPR frame. In such a case (No in step S504), after confirming the state of the port P3 of the own node, it is determined that the Ethernet frame is transmitted to the subordinate terminal. When the interlink connection node that first receives the broadcast frame does not transfer the Ethernet frame to the subordinate terminal, an Ethernet frame is added to the subordinate terminal by adding a frame untransmitted identifier to the broadcast frame. It is possible to easily determine whether or not to transmit. In such a case, the determination may be made by confirming whether or not the frame untransmitted identifier is added. Here, the addition of the frame non-transmission identifier is synonymous with the fact that the self-node is not the interlink connection node received first and the frame transmission identifier is not added.

  The method for expressing the frame untransmitted identifier can be realized by using a field of the header of the RPR frame, a multicast MAC address different from the frame transmitted identifier, or the like, similarly to the frame transmitted identifier.

  Further, in cases other than the above, the RPR switch processing unit 520 determines not to transmit an Ethernet frame to a subordinate terminal (interlink connection destination network). That is, when the own node is not the interlink connection node that first received the broadcast frame and the frame transmitted identifier is not added, or the own node is the interlink connection node that first received the broadcast frame. When the transmission source node does not belong to the group of the own node or when the port P3 of the own node is invalid, it is determined not to transmit the Ethernet frame.

  When the RPR switch processing unit 520 determines to transmit the Ethernet frame to the subordinate terminal, the RPR switch processing unit 520 transmits the Ethernet frame to the subordinate terminal as in the first embodiment.

  On the other hand, when it is determined not to transmit the Ethernet frame to the subordinate terminal, the RPR switch processing unit 520 does not send the RPR frame to the Ethernet frame extracting unit 530 and does not transmit the Ethernet frame to the subordinate terminal. . Note that MAC address learning may be performed even when it is determined not to transmit an Ethernet frame to a subordinate terminal.

  Note that the RPR switch processing unit 520 transfers the RPR frame to the adjacent RPR node regardless of whether or not to transmit the Ethernet frame to the subordinate terminal. The transfer of the RPR frame to the adjacent RPR node is the same as in the first embodiment.

  When the RPR switch processing unit 520 determines to transmit the Ethernet frame to the subordinate terminal, the Ethernet frame encapsulated in the RPR frame by the own node has already been transferred to another RPR network via the interlink. In order to indicate that the RPR frame has been transmitted, the frame transmission identifier is added to the RPR frame (step S204), and the RPR frame is transmitted to the next RPR node. If there is no interlink connection node connected to the same interlink connection destination network on the route from the self node to the TTL value, do not add the frame transmitted identifier. Also good.

  Further, in the present embodiment, when the RPR switch processing unit 520 determines that the Ethernet frame is not transmitted to the subordinate terminal because the port state of the interlink side port is invalid although other conditions are satisfied. (No in step S503), it is confirmed whether another interlink connection node is arranged on the subsequent broadcast frame route (route until the TTL value becomes 0) (step S506). If it is not arranged, the TTL value is updated so as to reach the interlink connection node ahead (step S507). That is, the RPR switch processing unit 520 changes the TTL value to the minimum value of the number of hops from its own node to the next interlink connection node in the broadcast frame transfer direction, and then transmits the RPR frame.

  However, if the minimum number of hops from the local node to the next interlink connection node exceeds the hop count from the local node to the transmission source node, that is, the transmission source node on the route to the next interlink connection node Is discarded by the source RPR node, there is no need to change the TTL value.

  The operation when the broadcast frame is not the first interlink connection node that has received the broadcast frame is the same as the operation of the interlink connection node when the broadcast frame is received in the first embodiment.

  That is, if the self-link node is an inter-link connection node that has received a broadcast frame for the second and subsequent times, whether or not the source RPR node of the broadcast frame is assigned to the self-node. There is no need to check.

  As described above, when an RPR node other than an interlink connection node is assigned to each interlink connection node so as not to overlap, the interlink connection node is an interlink connection node that first receives a broadcast frame. In this case, only the broadcast frame transmitted from the RPR node belonging to the group assigned to the own node, and the Ethernet frame encapsulated therein are transmitted to the interlink connection destination network.

  Hereinafter, a method for classifying each RPR node other than the interlink connection node into a group subordinate to each interlink connection node will be described. Here, a method of assigning each group to each interlink connection node after dividing each RPR node other than the interlink connection node into groups will be described as an example.

  First, groups are defined according to the number of interlinks that are distributed and transferred. The number of groups is arbitrary, but when the broadcast frame is distributed and transferred to all interlinks, groups corresponding to the number of interlink connection nodes are defined.

  Next, all RPR nodes other than the interlink connection nodes belonging to the same RPR network are classified so as to belong to any one of the defined groups. That is, the same RPR node is classified so as not to belong to a plurality of groups. Finally, each group is assigned to each interlink connection node. A method for assigning groups to interlink connection nodes is arbitrary.

  The following is an example of a group configuration method for causing an Ethernet frame stored in a broadcast frame to be transferred to another RPR network by an interlink connection node having the minimum number of hops from the source RPR node of the broadcast frame. . When this group configuration method is used, RPR nodes close to the interlink connection node are equally classified in the broadcast frame transfer path as a group subordinate to each interlink connection node.

  First, an RPR node (including interlink connection nodes at both ends) arranged on a path from a certain interlink connection node to the next interlink connection node is assumed to be one node. Next, the Clear Point of the virtual RPR node is obtained. In this case, the Clean Point when one node from the interlink connection node to the next interlink connection node in the clockwise direction is assumed to be one node, and the Clear Point of the RPR node that is virtually assumed by the counterclockwise route. 2 points are obtained.

  For example, in the RPR network 10 shown in FIG. 1, if each RPR node on the route from the interlink connection node 100 to the interlink connection node 110 is assumed to be one node, the virtual node based on the clockwise route is the RPR node. The virtual nodes including 100 and 110 and based on the route in the counterclockwise direction include the RPR nodes 100 and 170 to 110. A virtual node “Clave Point” based on a clockwise route is a link between the RPR node 140 and the RPR node 150. Further, the “Clave Point” of the virtual node based on the route in the counterclockwise direction is a link between the RPR node 100 and the RPR node 110.

  Next, the RPR nodes arranged on the route from each interlink connection node that is the starting point and end point of the virtual node to the obtained two Clear Point are assigned to the group of the interlink connection nodes.

  In this example, the group of interlink connection nodes 100 includes an RPR node (in this case, no corresponding node) arranged from the RPR node 100 to the link between the RPR node 100 and the RPR node 110, and the RPR node 100 to the RPR node. RPR nodes (herein, RPR nodes 170 to 150) arranged up to the link between 140 and RPR node 150 are allocated. Similarly, the group of interlink connection nodes 110 includes RPR nodes (in this case, no corresponding node) arranged from the RPR node 110 to the link between the RPR node 100 and the RPR node 110, and the RPR node 110 to the RPR node 140. -RPR nodes (in this case, RPR nodes 120 to 140) arranged up to the link between RPR nodes 150 are allocated.

  Although the above description assumes a normal Clear Point, the actual Clear Point dynamically changes depending on the RPR node failure and the failure state of the link between RPR nodes. When a failure occurs in an RPR node failure or a link between RPR nodes, the location where the failure has occurred becomes a Clean Point.

  Therefore, when the above-described group construction method is used, when each interlink connection node receives a broadcast frame, it dynamically obtains an RPR node belonging to the group of its own node based on the current Clean Point. it can.

  For example, in the RPR network 10 shown in FIG. 1, when a failure occurs in the RPR node 130, the virtual node Clear Point based on the clockwise route from the RPR node 100 to the RPR node 110 is represented by the RPR node 140-RPR node. It becomes a link between 130. Note that the Clear Point on the counterclockwise route is regarded as a failure inside the virtual node and is not changed from the normal time. Therefore, RPR nodes 140 to 170 are assigned to the group of interlink connection nodes 100. Further, RPR nodes 120 to 130 are allocated to the group of interlink connection nodes 110.

  Further, for example, when a failure occurs in the link between the RPR node 150 and the RPR node 160, the Clear Point of the virtual node based on the clockwise route from the RPR node 100 to the RPR node 110 is the RPR node 150-RPR node 160. It becomes an interlink. Accordingly, RPR nodes 160 and 170 are assigned to the group of interlink connection nodes 100, and RPR nodes 120 to 150 are assigned to the group of interlink connection nodes 110.

  Further, for example, when a failure occurs in the link between the RPR node 100 and the RPR node 110, the Clear Point is not changed from the normal time, and the RPR nodes 150 to 170 are assigned to the group of the interlink connection node 100, RPR nodes 120 to 140 are allocated to the group of interlink connection nodes 110.

  As described above, according to the present embodiment, even when a broadcast frame is transferred by a broadcast transfer method called Bidirectional Broadcast, a plurality of interlink connection nodes transmit the same Ethernet frame to the same other frame. The same effect as in the first embodiment can be obtained without transmitting to the RPR network.

Embodiment 3 FIG.
The third embodiment of the present invention will be described below with reference to the drawings. FIG. 14 is an explanatory diagram showing a configuration example of a communication system according to the present embodiment. The communication system shown in FIG. 14 is a communication system in which an RPR network 30 including RPR nodes 300 to 370 is connected to the RPR network 10 of the first embodiment shown in FIG. It is. Note that the RPR nodes 300 to 370 belonging to the RPR network 30 are RPR nodes belonging to other RPR networks (for example, the RPR nodes 100 to 170 and the RPR nodes 200 to 270 in the first embodiment shown in FIGS. 2 and 3). ). In the present embodiment, the RPR nodes 100, 110, 200, and 270 are interlink connection nodes between the RPR network 10 and the RPR network 20, and the RPR nodes 140, 150, 300, and 370 are the RPR network 10-. This is an interlink connection node between the RPR networks 30.

  In the present embodiment, the first implementation is that the method of expressing the frame transmitted identifier and the frame untransmitted identifier is distinguished between interlink connection nodes connected to different interlink connection destination networks in the same RPR network. The form is different. Other points are the same as those in the first embodiment.

  For example, if the interlink connection nodes 100 and 110 whose interlink connection destination network is the RPR network 20 and the interlink connection nodes 140 and 150 whose interlink connection destination network is the RPR network 30 use the same frame transmitted identifier. The following problems occur. If the interlink connection node 100 transmits the Ethernet frame stored in the broadcast frame to the RPR network 20 and adds the frame transmission completion identifier to the broadcast frame, the interlink connection nodes 140 and 150 transmit the frame. Recognizes the completed identifier and does not transmit an Ethernet frame to the RPR network 30. For this reason, an Ethernet frame cannot be transferred to a terminal under each RPR node belonging to the RPR network 30.

  Therefore, the same frame transmitted identifier is used in the interlink connection nodes 100 and 110 whose interlink connection destination network is the RPR network 20 and in the interlink connection nodes 140 and 150 whose interlink connection destination network is the RPR network 30. As a result, there arises a problem that communication cannot be performed between the terminals under the RPR nodes belonging to the RPR network 10 and the RPR network 20 and the terminals under the RPR nodes belonging to the RPR network 30.

  In order to solve such a problem, in the present embodiment, as already described, the frame transmitted identifier and the inter-link connection node connected to different inter-link connection destination networks in the same RPR network Differentiate the method of expressing the frame untransmitted identifier. In this example, different representation methods are used for the frame transmitted identifier used by the interlink connection nodes 140 and 150 and the frame transmitted identifier used by the interlink connection nodes 100 and 110. By using a different expression method, the frame transmission identifier added by the interlink connection node 100 or the interlink connection node 110 is not erroneously recognized by the interlink connection node 140 or the interlink connection node 150. The Ethernet frame stored in the broadcast frame is transmitted to each of the RPR network 20 and the RPR network 30.

  For example, when a method of changing the destination MAC address of a broadcast frame from a broadcast MAC address to a multicast MAC address is used as a method of expressing a frame transmission identifier, the value of the multicast MAC address used by the interlink connection nodes 100 and 110 The multicast MAC address values used by the interlink connection nodes 140 and 150 may be defined as different values.

  The special multicast MAC address defined as the frame transmission completed identifier is defined as the MAC address of the group to which all the RPR nodes belonging to the RPR network belong, as in the first embodiment.

  Each interlink connection node has a frame transmission identifier added when the destination MAC address is a multicast MAC address defined for an interlink connection node connected to the same interlink connection destination network as that of its own node. If not, it may be recognized as a normal broadcast frame or a normal multi-cast frame. By operating in this way, for example, the interlink connection nodes 140 and 150 use the broadcast MAC address for the RPR frame having the multicast MAC address added by the interlink connection node 100 or the interlink connection node 110 as the destination MAC address. As a destination MAC address. Similarly, for example, the interlink connection nodes 100 and 110 use the multicast MAC address added by the interlink connection node 140 or the interlink connection node 150 as the destination MAC address, and the broadcast MAC address as the destination MAC address. Can be processed as an RPR frame.

  As described above, according to the present embodiment, since the interlinks between a plurality of RPR networks can be duplicated, a more reliable communication system can be constructed.

Embodiment 4 FIG.
The fourth embodiment of the present invention will be described below with reference to the drawings. FIG. 15 is an explanatory diagram showing a configuration example of a communication system according to the present embodiment. The communication system shown in FIG. 15 is a communication system in which an interlink 460 is added to the connection between the RPR network 10 and the RPR network 20 of the first embodiment shown in FIG.

  In the present embodiment, the RPR nodes 100, 110, 170, 200, 210, and 270 are interlink connection nodes. Note that the configuration of each node and the frame transfer operation in this embodiment are the same as those in the first embodiment.

  In the present embodiment, for example, even when a failure occurs in the interlink 420 and the interlink 430, communication can be continued through the interlink 460. Note that the number of interlinks is not limited to three. Since the communication system to which the present invention is applied can connect the RPR networks with three or more interlinks, it is possible to construct a more reliable communication system.

Embodiment 5 FIG.
Hereinafter, a fifth embodiment of the present invention will be described with reference to the drawings. FIG. 16 is an explanatory diagram showing a configuration example of a communication system according to the present embodiment. In the communication system shown in FIG. 16, the first point is that interlink connection nodes connected to the same interlink connection destination network are not arranged at adjacent positions but at positions separated by one hop or more. This is different from the embodiment. In the present embodiment, the RPR nodes 110, 170, 210, and 270 are interlink connection nodes. Other points are the same as in the first embodiment.

  In this embodiment, a method for solving a problem that occurs in RPR nodes other than interlink connection nodes when a broadcast frame is transferred by Bidirectional Broadcast in the configuration shown in FIG.

  Note that the operation of each RPR node (including the RPR node that is an interlink connection node) when all the RPR nodes transfer a broadcast frame by Unidirectional Broadcast is the same as in the first embodiment. In addition, the operation of the interlink connection node in the case of transferring a broadcast frame by Bidirectional Broadcast is the same as that of the second embodiment.

  In the following, in the communication system in which all RPR nodes belonging to the RPR network 10 and the RPR network 20 perform broadcast frame transfer by Bidirectional Broadcast, a description has been given in the second embodiment when a failure occurs in the interlink 430. The problem caused by the broadcast frame transfer method and its solution will be described.

  Here, a case where a broadcast frame is transferred from the RPR node 140 using Bidirectional Broadcast will be described as an example. Here, it is assumed that the RPR node 140 belongs to the group of interlink connection nodes 110 connected to the interlink 430 in which a failure has occurred.

  In this example, when an RPR frame is broadcast from the RPR node 140, the broadcast frame transmitted in the counterclockwise direction is transferred from the RPR node 120 to the interlink connection node 110. As shown in FIG. 13, the interlink connection node 110 is the first interlink connection node at which the node received the RPR frame as in the second embodiment, and the source MAC address of the RPR frame Even if the MAC address of the RPR node belonging to the group assigned to the own node, the port status of the port P3 of the own node is invalid, so that the Ethernet frame is sent to the subordinate terminal (that is, the interlink connection destination network). Do not send.

  At this time, if the TTL value of the received broadcast frame is a value that can reach another interlink connection node (here, RPR node 170) in the subsequent route, interlink connection node 110 does nothing particularly. First, the broadcast frame is transferred to the next RPR node (RPR node 100).

  On the other hand, if the TTL value is not a value that can reach another interlink connection node, the interlink connection node 110 sets the TTL value to the number of hops from its own node to the next interlink connection node (here, 2 hops) and then forward to the next RPR node.

  In the latter case, for example, when the ClearPoint of the broadcast frame transmission source node is the link between the RPR node 100 and the RPR node 110, the RPR node 100 transmits the broadcast frame transferred in the clockwise direction and the interlink connection node. Two broadcast frames of the broadcast frame forwarded in the counterclockwise direction with the TTL updated so that 110 is forwarded to another interlink connection node are received. For this reason, the RPR node 100 cannot recognize even the same broadcast frame, and transmits the Ethernet frame stored in each broadcast frame to the terminals under its own node. Therefore, there is a problem that terminals under the RPR node 100 receive the same Ethernet frame twice.

  Therefore, the RPR node 100 needs to perform transfer control to a subordinate terminal only for one of these two broadcast frames.

  In this embodiment, in an RPR node that is not an interlink connection node, transfer control to a subordinate terminal is not performed for a broadcast frame whose TTL has been updated by the interlink connection node and should not be received in a normal state. By controlling so as to solve the above problem.

  FIG. 17 is a flowchart illustrating an example of an operation performed when an RPR node (in this example, the RPR node 100) that is not an interlink connection node according to the present embodiment receives an RPR frame that has been broadcast by Bidirectional Broadcast.

  As shown in FIG. 17, the RPR node in the present embodiment is different from the first embodiment in that it may not transmit to a subordinate terminal when a broadcast frame is received. The operation when the source MAC address of the broadcast frame is the MAC address of its own node (steps S101 to 103) and the operation of transferring the RPR frame to the adjacent RPR node (steps S106 to 108) are as follows. This is the same as the embodiment. That is, the RPR node in the present embodiment not only operates in accordance with “IEEE Std 802.17”, but also performs other operations (operations for realizing the object of the present invention).

  The RPR switch processing unit 520 of the RPR node 100 is when the transmission source MAC address of the received RPR frame is not the MAC address of the own node and the destination MAC address of the RPR frame is the broadcast MAC address (step In step S102, it is determined whether to transmit an Ethernet frame to a subordinate terminal. The RPR switch processing unit 520 determines whether or not to transmit an Ethernet frame to a subordinate terminal according to the following condition when the received broadcast frame is transferred using a transfer method based on Bidirectional Broadcast.

  The RPR switch processing unit 520 of the RPR node 100 determines to transmit an Ethernet frame to a subordinate terminal when a frame transmission completed identifier is added. In addition, the RPR switch processing unit 520, when a frame transmission completed identifier is not added, or when a frame untransmitted identifier is added, on the transfer path set by the transmission source node when the frame is generated, If the own node is arranged, it is determined that the Ethernet frame is transmitted to the subordinate terminal.

  Note that the condition that the source node is located on the transfer path set when the frame is generated by the transmission source node described above is that the number of hops from the transmission source node to the local node (RPR node 100) is that of the broadcast frame. This matches the condition that it is less than or equal to the initial value of the TTL set by the transmission source node at the time of generation (that is, the number of hops from the transmission node to the Clear Point). In the RPR switch processing unit 520, the hop number from the transmission source node to the own node in the transfer path of the received RPR frame is the initial value of the TTL set by the transmission source node (the number of hops from the transmission source node to the Clear Point). In the following cases, it is determined that the Ethernet frame is transmitted to the subordinate terminal.

  When the RPR switch processing unit 520 determines not to transmit the Ethernet frame to the subordinate terminal, the RPR switch processing unit 520 does not transmit the RPR frame to the Ethernet frame extracting unit 530 and does not transmit the Ethernet frame to the subordinate terminal. Note that MAC address learning may be performed even when it is determined not to transmit an Ethernet frame to a subordinate terminal.

  On the other hand, when it is determined to transmit the Ethernet frame to the subordinate terminal, the Ethernet frame is transmitted to the subordinate terminal as in the second embodiment. That is, the RPR switch processing unit 520 sends the RPR frame to the Ethernet frame extraction unit 530. The Ethernet frame extraction unit 530 extracts the Ethernet frame from the RPR frame, and transmits the Ethernet frame from the output port 540-3 of the own node to the terminals under the own node (Step S104). At this time, the FDB management unit 560 performs MAC address learning by registering the correspondence relationship between the MAC address of the terminal and the RPR node in the FDB 550 based on the received RPR frame (step S105).

  Note that the RPR switch processing unit 520 transfers the RPR frame to the adjacent RPR node regardless of whether or not to transmit the Ethernet frame to the subordinate terminal. The transfer operation of the RPR frame to the adjacent RPR node is the same as that in the second embodiment. That is, the RPR switch processing unit 520 subtracts 1 from the TTL value stored in the received RPR frame (step S106). If the TTL value after the subtraction is greater than 0, the RPR frame is transferred to the next RPR node. (Yes in step S107, S108). If the TTL value is 0, the RPR frame is discarded (No in step S107, S103).

  As described above, according to the present embodiment, the RPR node 100 sandwiched between the interlink connection nodes recognizes the broadcast frame transferred beyond the ClearPoint set by the transmission source node, and Since the stored Ethernet frame is not transmitted to the subordinate terminal, even if the same RPR frame is received by the traffic operation of the interlink connection node, the situation where the subordinate terminal receives the Ethernet frame twice is avoided. Can do.

  Therefore, since the arrangement of the interlink connection nodes is not limited, it is possible to easily construct a highly reliable communication system.

Embodiment 6 FIG.
The sixth embodiment of the present invention will be described below with reference to the drawings. FIG. 18 is an explanatory diagram showing a configuration example of a communication system according to the present embodiment. The communication system shown in FIG. 18 includes an RPR network 10 that includes RPR nodes 100 to 170. The RPR nodes 120 to 170 each accommodate one terminal (terminals 720 to 770). Further, the RPR node 100 and the RPR node 110 accommodate one common terminal 700.

  In such a configuration, the RPR node 100 and the RPR node 110 are regarded as interlink connection nodes, and the RPR node 100-terminal 700 link and the RPR node 110-terminal 700 link are regarded as interlinks. A highly reliable communication system can be constructed not only for communication between networks but also for communication between RPR nodes and terminals.

  Note that the configuration of each RPR node in the present embodiment is the same as in the other embodiments. The frame transfer operation is the same as that of the other embodiments except that when the terminal 700 transmits an Ethernet frame, the frame is transmitted to one of the RPR node 100 and the RPR node 110. is there.

  The RPR node to which the terminal 700 transmits an Ethernet frame must satisfy the following conditions. First, it is an RPR node in which no failure has occurred. Next, no failure has occurred in the link connecting the terminal 700 and the RPR node. Next, communication with other RPR nodes belonging to the RPR network 10 is possible. It is preferable that there are as many other RPR nodes as possible to communicate.

  When both the RPR node 100 and the RPR node 110 satisfy the above conditions, the terminal 700 transmits and receives an Ethernet frame via either the RPR node 100 or the RPR node 110 as long as the arrival order of the Ethernet frames is maintained. Therefore, traffic can be distributed over a plurality of links between the RPR network 10 and the terminal 700.

  Note that the function of selecting an RPR node to which the terminal 700 transmits an Ethernet frame is to apply a LAG to the ports P1 and P2 of the terminal 700 and implement an Ethernet frame transmission destination selection algorithm that satisfies the above conditions. Can be realized.

  As described above, according to the present invention, it is possible to easily realize a so-called multi-homing configuration in which the link between the RPR network and the terminal is made redundant in addition to the redundancy of the interlink connecting the RPR networks. It is.

  In each of the above embodiments, the RPR node and the interlink connection node have been described as including the respective processing units such as the RPR frame generation unit 510 and the RPR switch processing unit 520. However, the RPR node and the interlink connection node However, the computer may be configured so that the computer operates in the same manner as each processing unit according to the program. Note that the program may be stored in advance in a storage device included in the node.

  The identifier adding unit, the transmission determining unit, and the transfer path changing unit described in the claims are realized by, for example, the RPR switch processing unit 520 of the interlink connection node. Further, the failure monitoring means is realized by, for example, the port state monitoring unit 590 of the interlink connection node. The link control means is realized by, for example, the RPR switch processing unit 520 and the port state monitoring unit 590 of the interlink connection node. The second transmission determination unit is realized by, for example, the RPR switch processing unit 520 of the RPR node that is not the interlink connection node. Further, the selection transmission means is realized by a CPU on which a transmission destination selection algorithm included in the terminal 700 is mounted, for example.

BRIEF DESCRIPTION OF THE DRAWINGS Explanatory drawing which shows 1st Embodiment of the communication system by this invention. The block diagram which shows the structural example of the RPR node which is not an interlink connection node. The block diagram which shows the structural example of the RPR node which is an interlink connection node. Explanatory drawing which shows the example of the corresponding relationship registered into FDB. Explanatory drawing which shows the example of the information registered into TDB. Explanatory drawing which shows the example of the information memorize | stored in a MAC address management table. Explanatory drawing which shows the example of the information memorize | stored in a port status table. Explanatory drawing which shows the example of the information memorize | stored in an interlink connection node management table. The flowchart which shows the example of the process progress of the broadcast frame transfer operation | movement in RPR node which is not an interlink connection node. The flowchart which shows the example of the process progress of the broadcast frame transfer operation | movement in RPR node which is an interlink connection node. The flowchart which shows the example of processing progress of the unicast frame transfer operation | movement in RPR node which is not an interlink connection node. The flowchart which shows the example of processing progress of the unicast frame transfer operation | movement in the RPR node which is an interlink connection node. 9 is a flowchart showing a processing progress of a broadcast frame transfer operation in an RPR node which is an interlink connection node in the second embodiment. Explanatory drawing which shows 3rd Embodiment of the communication system by this invention. Explanatory drawing which shows 4th Embodiment of the communication system by this invention. Explanatory drawing which shows 5th Embodiment of the communication system by this invention. The flowchart which shows the process progress of the transfer operation | movement of the broadcast frame in RPR node which is not an interlink connection node by 5th Embodiment. Explanatory drawing which shows 6th Embodiment of the communication system by this invention. An explanatory view showing an example of an RPR network. Explanatory drawing which shows the example which applied LAG to the connection of RPR networks. Explanatory drawing which shows the structure of the network described in patent document 1. FIG.

Explanation of symbols

10, 20, 30, 80, 90 RPR network 100-170, 200-270, 300-370, 800-870, 900-970 RPR node 400-460, 491, 492 Interlink 500-1-3 Input port 510 RPR Frame generation unit 520 RPR switch processing unit 530 Ethernet frame extraction unit 540-1 to 3 Output port 550 FDB
560 FDB management unit 570 TDB
580 MAC address management table 590 port state monitoring unit 600 port state table 610 interlink connection node management table 700 to 770 terminal

Claims (27)

A communication system including a plurality of nodes to which a terminal is connected,
Some nodes of the plurality of nodes each have a common connection destination by connecting, as a terminal, a common terminal or a node included in a communication system different from the communication system via a link. Are summarized as
Nodes belonging to the group are
An identifier indicating whether or not a frame received from a terminal connected to a node included in the communication system stored in the intra-system communication frame is transmitted to a common connection destination terminal or node is used as the intra-system communication. Identifier adding means for adding to the frame for use;
Whether a frame stored in the intra-system communication frame is transmitted to a common connection destination terminal or node based on the information indicated by the intra-system communication frame when an intra-system communication frame is received And a transmission determination means for determining whether or not. The nodes belonging to the group are
An intra-system communication frame transmitting means for transmitting an intra-system communication frame to which an identifier is added by the identifier adding means to a node included in the communication system;
The communication system according to claim 1, further comprising: a terminal communication frame transmission unit configured to transmit a frame stored in the intra-system communication frame to a common connection destination terminal or node according to a determination result of the transmission determination unit. . The nodes belonging to the group are
A failure monitoring means for monitoring a failure state of a link between a common connection destination terminal or node and the own node,
The transmission determination unit is stored in the intra-system communication frame based on the identifier added by the identifier addition unit of the node belonging to the same group as the own node and the failure state of the link monitored by the failure monitoring unit. The communication system according to claim 1, wherein it is determined whether to transmit a frame to a common connection destination terminal or node.   The identifier adding means transmits a transmitted identifier indicating that transmission has been performed when the node transmits a frame stored in an intra-system communication frame indicating transfer by broadcast to a common connection destination terminal or node. The communication system according to any one of claims 1 to 3, which is added.   The identifier adding means indicates that the own node has not transmitted the frame stored in the intra-system communication frame indicating the transfer by broadcast to the common connection destination terminal or node. The communication system according to any one of claims 1 to 4, wherein an untransmitted identifier is added.   The transmission determination unit determines that transmission is not performed when the transmission source address of the intra-system communication frame is an address of a node belonging to the same group as the own node. The communication system according to item.   The transmission determination means is a case where a transmitted identifier is not added to the intra-system communication frame or an untransmitted identifier is added to the intra-system communication frame when receiving the intra-system communication frame indicating transfer by broadcast. The communication system according to any one of claims 4 to 6, wherein when a frame can be transmitted / received to / from a common connection destination terminal or node, transmission is determined.   The node belonging to the group includes a transfer route changing unit that changes a transfer route of the intra-system communication frame by changing route information indicating a transfer route set in the intra-system communication frame. The communication system according to claim 1. Each node not belonging to a group is assigned to any one of the nodes belonging to the group by being associated with any one of the nodes belonging to the group,
If the transmission determination means receives the intra-system communication frame indicating transfer by broadcast and the node is the first node that has received the intra-system communication frame among the nodes belonging to the group, the transmission determination means When the transmission source node of the internal communication frame is assigned to the own node, and when the frame can be transmitted / received to / from a common connection destination terminal or node, and the own node belongs to the group If it is not the node that has received the intra-system communication frame first among the nodes to which it belongs, it is a case where an untransmitted identifier is added to the intra-system communication frame or a transmission identifier is not added, If it is possible to send and receive frames to and from the terminal or node to which
The transfer path changing unit is a case where the transmission determining unit determines not to transmit, and no other node belonging to the group is arranged on the transfer path of the intra-system communication frame after the own node The communication system according to claim 8, wherein the path information of the intra-system communication frame is changed to reach another node belonging to the group.   The communication system according to claim 8 or 9, wherein the transfer path changing unit changes the TTL stored in the intra-system communication frame as path information.   When a node that does not belong to the group receives the intra-system communication frame, the node stored in the intra-system communication frame is connected to its own node based on the information indicated by the intra-system communication frame. The communication system according to any one of claims 1 to 10, further comprising a second transmission determination unit that determines whether or not to transmit to a terminal.   When the second transmission determination unit receives the intra-system communication frame indicating the transfer by broadcast, the second transmission determination unit is on a transfer path set by the transmission source node of the intra-system communication frame when generating the intra-system communication frame. The communication system according to claim 11, wherein when the own node is not arranged, it is determined not to transmit.   The transmission determination means transmits the frame when the destination address of the intra-system communication frame is an address of a node belonging to the same group as the own node and the frame can be transmitted / received to / from a common connection destination terminal or node. The communication system according to any one of claims 1 to 12, which decides to do so.   The common terminal is one of the nodes based on whether or not frame transmission / reception with each node connected to the terminal and whether or not frame transmission / reception with another node included in the communication system in each node is possible. The communication system according to any one of claims 1 to 13, further comprising selective transmission means for transmitting frames to each other.   The identifier adding means uses the header of the intra-system communication frame, the preamble of the intra-system communication frame, or the value of a predetermined field of the interframe gap between the intra-system communication frames, to thereby identify the identifier. The communication system according to any one of claims 1 to 14, which is expressed.   The identifier adding means is an intra-system communication in which the destination address of the intra-system communication frame is different from the broadcast address indicating transfer by broadcast, and the broadcast address is a destination address in a node belonging to the communication system. The communication system according to any one of claims 1 to 14, wherein the identifier is expressed by using an address at which a frame transfer process similar to that for a frame is performed.   When a node belonging to a group cannot transmit / receive a frame on all links with other nodes included in the communication system connected to the own node, the node or node that is connected to the common node The communication system according to any one of claims 1 to 16, further comprising link control means for detecting that frames cannot be transmitted / received between them.   The communication system according to any one of claims 1 to 17, wherein the communication system and a common communication system different from the communication system are RPR networks. In a communication system including a plurality of nodes to which a terminal is connected, among the plurality of nodes, a common terminal or a node included in a communication system different from the communication system is connected as a terminal via a link. Nodes that are grouped together as a group having a common connection destination,
An identifier indicating whether or not a frame received from a terminal connected to a node included in the communication system stored in the intra-system communication frame is transmitted to a common connection destination terminal or node is used as the intra-system communication. Identifier adding means for adding to the frame for use;
Whether a frame stored in the intra-system communication frame is transmitted to a common connection destination terminal or node based on the information indicated by the intra-system communication frame when an intra-system communication frame is received A node having transmission determination means for determining whether or not.   20. The node according to claim 19, further comprising transfer path changing means for changing a transfer path of the intra-system communication frame by changing path information indicating a transfer path set in the intra-system communication frame. A node that does not belong to a group,
Whether or not to transmit the frame stored in the intra-system communication frame to the terminal connected to the own node based on the information indicated by the intra-system communication frame when the intra-system communication frame is received 21. The node according to claim 19 or 20, further comprising second transmission determination means for determining whether or not. A communication system including a plurality of nodes to which a terminal is connected, wherein some of the nodes are included in a common terminal or a communication system different from the communication system via a link. Is a communication method applied to a communication system that is grouped as a group having a common connection destination by being connected as a terminal,
Indicates whether a node belonging to the group has transmitted a frame received from a terminal connected to a node included in the communication system, stored in an intra-system communication frame, to a common destination terminal or node An identifier is added to the intra-system communication frame;
Whether a frame stored in the intra-system communication frame is transmitted to a common connection destination terminal or node based on the information indicated by the intra-system communication frame when an intra-system communication frame is received A communication method characterized by determining whether or not.   23. The communication method according to claim 22, wherein a node belonging to the group changes a transfer route of the intra-system communication frame by changing route information indicating a transfer route set in the intra-system communication frame.   When a node that does not belong to the group receives the intra-system communication frame, the frame stored in the intra-system communication frame is connected to its own node based on the information indicated by the intra-system communication frame. The communication method according to claim 22 or 23, wherein it is determined whether or not to transmit to a terminal. In a communication system including a plurality of nodes to which a terminal is connected, among the plurality of nodes, a common terminal or a node included in a communication system different from the communication system is connected as a terminal via a link. In a computer with nodes that are grouped together as a group with a common connection destination,
An identifier indicating whether or not a frame received from a terminal connected to a node included in the communication system stored in the intra-system communication frame is transmitted to a common connection destination terminal or node is used as the intra-system communication. When a process to be added to a communication frame and an intra-system communication frame are received, the frame stored in the intra-system communication frame is connected to a common connection destination based on information indicated by the intra-system communication frame. Node program for executing the process of determining whether to transmit to a terminal or node. On the computer,
26. The program for a node according to claim 25, for executing processing for changing a transfer path of the intra-system communication frame by changing path information indicating a transfer path set in the intra-system communication frame. To a computer with a node that does not belong to a group,
Whether or not to transmit the frame stored in the intra-system communication frame to the terminal connected to the own node based on the information indicated by the intra-system communication frame when the intra-system communication frame is received 27. The node program according to claim 25 or 26, for executing a process for determining whether or not.

Images