WO2013145150A1 - 通信装置、通信方法、及び通信プログラム - Google Patents

通信装置、通信方法、及び通信プログラム Download PDF

Info

Publication number
WO2013145150A1
WO2013145150A1 PCT/JP2012/058127 JP2012058127W WO2013145150A1 WO 2013145150 A1 WO2013145150 A1 WO 2013145150A1 JP 2012058127 W JP2012058127 W JP 2012058127W WO 2013145150 A1 WO2013145150 A1 WO 2013145150A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
frame
node
list
information
Prior art date
Application number
PCT/JP2012/058127
Other languages
English (en)
French (fr)
Inventor
澤田　順一
竜 小林
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2012/058127 priority Critical patent/WO2013145150A1/ja
Priority to JP2014507118A priority patent/JP5907252B2/ja
Publication of WO2013145150A1 publication Critical patent/WO2013145150A1/ja
Priority to US14/497,702 priority patent/US9614718B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H04L12/437—Ring fault isolation or reconfiguration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4637—Interconnected ring systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing

Definitions

  • the present invention relates to a communication apparatus, a communication method, and a communication program in a cascade topology network.
  • RPR Silicon Packet Ring
  • NTN Next Generation Network
  • RPR is standardized as IEEE 802.17.
  • RPR is a technique for efficiently using a high-speed line of 10 Gbit / s in units of frames.
  • IEEE 802.17 a ring topology and a cascade topology are defined as the connection form of each node.
  • FIG. 1 is a diagram illustrating an example of a ring topology.
  • the ring topology is a form in which each node is connected in a ring shape.
  • the RPR ring topology can be restored within 50 ms when a failure occurs, which is a measure of the solubility of the communication service provided by the communication carrier.
  • the IEEE 802.17 specification when a ring topology is constructed, there is a restriction that all transmission paths on the ring are set to RPR.
  • FIG. 2 is a diagram showing an example of a cascade topology.
  • the cascade topology is a form in which nodes are connected in series.
  • the cascade topology there is a high possibility that the network is divided due to a single transmission line failure and communication is impossible.
  • FIG. 3A is a diagram illustrating an example of an RPR network having a cascade topology.
  • the ring devices # 1 to # 5 construct an RPR network having a cascade topology.
  • Each of the ring devices # 1 to # 5 transmits an RPR control frame at a predetermined interval, learns the topology with control frames from other ring devices, and creates its own node information.
  • the own node information is information indicating the arrangement order of the nodes in the RPR network.
  • the local node information is created for each interface connected to the RPR network.
  • the own node information includes the node ID of the ring device located in the corresponding interface direction and the number of hops from the own device.
  • FIG. 3A shows the own node information that the ring device # 1 and the ring device # 5 have.
  • the own node information of ring device # 1 located at one end of the cascade topology in FIG. 3A is, for example, ring device # 1 (own device) at 0 hop, ring device # 2,. . . Ring device # 5 is located at a distance of 4 hops.
  • the ring device # 1 and the ring device # 5 transmit the RPR frame
  • the ring device # 1 and the ring device # 5 search the destination node with the own node information, and when the destination node exists in the own node information, the interface corresponding to the own node information Transmits an RPR frame.
  • the ring device # 1 and the ring device # 5 are nodes located at the end of the cascade topology, and have an interface connected to one RPR network, and thus each own node information is held. However, since the ring devices # 2 to # 4 each include an interface connected to two RPR networks, a total of two own node information for each interface is provided.
  • the ring apparatuses # 2 to # 4 search the destination node with the own node information corresponding to each interface, and the RPR frame is received from the interface corresponding to the own node information where the destination node exists. Send. If no destination node exists in any of the own node information, the frame is discarded.
  • FIG. 3B is a diagram illustrating an example when a failure occurs in the RPR network having the cascade topology illustrated in FIG. 3A.
  • a failure has occurred in the transmission path between the ring device # 2 and the ring device # 3.
  • the ring device # 2 and the ring device # 3 connected to the transmission path in which the failure has occurred respectively detect the failure occurrence and transmit a failure notification to the other ring devices.
  • FIG. 3B shows the own node information of ring device # 1 and ring device # 5.
  • ring device # 1 receives a failure notification from ring device # 2. After that, since the information of the ring devices # 3, # 4, and # 5 that are positioned ahead of the transmission path where the failure has occurred is not received, the ring device # 3, # 4, and # 5 of the ring devices # 3, # 4, and # 5 are obtained from the node information of the ring device # 1 Information is deleted. Accordingly, the ring device # 1 cannot transmit a frame to the ring devices # 3, # 4, and # 5 because the information of the ring devices # 3, # 4, and # 5 does not exist in the own node information.
  • ring device # 5 receives the failure notification transmitted from ring device # 3. Since the information of the ring devices # 1 and # 2 positioned at the tip of the transmission path in which the failure has occurred as viewed from the ring device # 5 is not received, the information of the ring devices # 1 and # 2 from the own node information of the ring device # 5 Is deleted. Accordingly, the ring device # 5 cannot transmit a frame to the ring devices # 1 and # 2 because the information of the ring devices # 1 and # 2 does not exist in its own node information.
  • ring device # 2 loses its own node information corresponding to the interface connected to the transmission path in which the failure occurred, and therefore cannot transmit a frame to ring devices # 3- # 5. Since ring device # 3 loses its own node information corresponding to the interface connected to the transmission path in which the failure has occurred, it cannot transmit a frame to ring devices # 1 and # 2. Since the ring device # 4 does not receive the information of the ring devices # 1 and # 2, the information of the ring devices # 1 and # 2 is deleted from its own node information, and the frame can be transmitted to the ring devices # 1 and # 2. Disappear.
  • An object of one embodiment of the present invention is to provide a communication device, a communication method, and a communication program for providing a first network having a cascade topology with a detour by a second network different from the first network. .
  • One aspect of the present invention is a communication apparatus that connects to a terminal of a first network in a cascade topology and connects to a second network having a frame format different from that of the first network,
  • a first list including information of a communication device in the first network that is a destination of transmission of a frame via the first network is located at the other end of the first network, and the second list
  • a transmitting unit that connects to the other network and transmits to the opposite communication device in the second network
  • a receiving unit that receives, from the opposing communication device, a second list including information on the communication device in the first network that is a destination of transmission of the frame via the first network of the opposing communication device;
  • a determination unit that determines whether a destination of a frame is included in the first list or the second list;
  • a frame transmission unit configured to transmit the frame to the second network when a destination of the frame received from the first network is included in the second list; It is a communication
  • Another aspect of the present invention is a communication method executed by the communication apparatus described above.
  • the other aspect of this invention can include the communication program which makes a computer function as a communication apparatus, and the computer-readable recording medium which recorded the said communication program.
  • the computer-readable recording medium refers to a recording medium in which information such as data and programs is accumulated by electrical, magnetic, optical, mechanical, or chemical action and can be read from the computer or the like.
  • the disclosed communication device, communication method, and communication program it is possible to provide a detour route by a second network different from the first network to the first network having the cascade topology.
  • FIG. 3A It is a figure which shows an example of a ring type topology. It is a figure which shows an example of a cascade type
  • FIG. 6 is a diagram showing an example of transition by frame conversion in the communication system according to the first embodiment. It is a figure which shows an example of the hardware constitutions of a ring apparatus. It is a figure which shows an example of the functional block of a ring apparatus. It is an example of the flowchart of the process which concerns on management of own node information.
  • FIG. 10 is an example of a flowchart of frame transfer processing when a frame is received in the LAN IF when a failure of the cascade NW occurs.
  • the bypass NW is shared by two RPR networks, RPR1 and RPR2. It is a figure which shows the example of the transition by the conversion of the flame
  • FIG. 4 is a diagram showing a detour design plan 1 in a cascade topology.
  • nodes located at both ends of the RPR network of the cascade topology are connected by Ethernet, and thereby a detour is constructed.
  • a node located at the end of the RPR network of the cascade topology and located at the boundary between the RPR network and the Ethernet is hereinafter referred to as a boundary node.
  • a cascade type RPR network is also referred to as a cascade NW.
  • design plan 1 has the following problems. For example, when a failure occurs in a transmission path in the RPR network, when the LAN side networks of the boundary nodes are connected, STP (Spanning Tree Protocol) is executed in the LAN. Since execution of this STP takes several seconds, the switching time when a failure occurs in the design plan 1 exceeds the switching time (within 50 ms), which is a measure of availability. Also, for example, when a frame passes through a detour (Ethernet), it cannot be passed in the RPR format, so that the RPR header is removed from the frame and becomes an original Ethernet frame. Therefore, QoS information for the RPR network is lost.
  • the original Ethernet frame refers to an Ethernet frame transmitted from a terminal in an NW (Ethernet) under the ring device. Therefore, when the frame reaches the RPR network again via the detour, proper priority control may not be performed in the RPR network.
  • FIG. 5A is a diagram showing a detour design plan 2 in a cascade topology.
  • the boundary nodes of the RPR network of the cascade topology are connected by Ethernet, and thereby a detour is constructed.
  • the boundary node in order to transmit the frame to the detour (Ethernet), the boundary node encapsulates the RPR frame with the Ethernet frame. By encapsulating with Ethernet, the header of the RPR frame is maintained, and loss of QoS information for the RPR network is prevented.
  • the detour Ethernet
  • FIG. 5B is a diagram showing a format of an Ethernet frame when an RPR frame is encapsulated.
  • the size is increased by an RPR header (26 bytes) and an Ethernet header (18 bytes in total) for encapsulating the RPR frame, compared to a normal Ethernet frame. Therefore, the frame transfer capability in the detour is reduced.
  • the frame size increases, and the frame transfer capability decreases by about 80%. That is, in the case of the design plan 2, the use band of the detour is increased due to an increase in the frame size by encapsulating the RPR frame with the Ethernet.
  • a communication method that maintains a switching time (50 ms), which is a measure of availability, and prevents a reduction in frame transfer capability of a bypass network.
  • FIG. 6A is a diagram for explaining an overview of a communication system having a detour in the first embodiment.
  • the communication system according to the first embodiment includes an RPR network (cascade NW in the figure) having a cascade topology and an Ethernet (detour NW in the figure) as a bypass.
  • Ring devices # 1 to # 5 are connected to the RPR network to construct a cascade topology.
  • Ring device # 1 and ring device # 5 (boundary node) are also connected to Ethernet using a LAN interface.
  • the ring devices # 1 and # 5 which are boundary nodes have opposite node information in addition to their own node information.
  • FIG. 6A shows the own node information and the opposite node information of the ring device # 1 and the ring device # 1.
  • the opposite node information is a copy of the own node information held by the opposite node in the detour NW, in other words, the boundary node at the other end of the cascade NW. Therefore, in the example shown in FIG. 6A, the own node information of the ring device # 1 and the opposite node information of the ring device # 5 are the same. In the example shown in FIG. 6A, the own node information of the ring device # 5 and the opposite node information of the ring device # 1 are the same.
  • each boundary node periodically transmits a copy of its own node information via the detour network and receives the copy of its own node information from the opposite node, thereby acquiring the opposite node information.
  • a copy of the own node information is transmitted by the control frame at a period of 3-10 ms.
  • This opposing node information is information indicating the arrangement order of the nodes in the detour NW direction for each boundary node.
  • the local node information is information indicating the arrangement of nodes in the cascade NW direction for each boundary node.
  • FIG. 6B is a diagram for explaining the outline of the communication system when a failure occurs in the cascade NW.
  • FIG. 6B shows the own node information and the opposite node information of the ring device # 1 and the ring device # 1.
  • the RPR function causes the ring device # 2 and the ring device # 3 to enter the cascade NW.
  • Failure notification is performed.
  • the information of the ring devices # 3, # 4, and # 5 that are located before the location of the failure when viewed from the ring device # 1 is deleted from the own node information of the ring device # 1 that is the boundary node.
  • the information of the ring devices # 1 and # 2 located before the location of the failure as viewed from the ring device # 5 is deleted from the own node information of the ring device # 5 which is another boundary node. Since each boundary node transmits a copy of its own node information, the opposite node information of each boundary node is also updated. That is, the opposite node information of the ring device # 1 is the same as the own node information of the ring device # 5, and is information in which the ring devices # 3, # 4, and # 5 exist. The opposite node information of the ring device # 5 is the same as the own node information of the ring device # 1, and is information in which the ring devices # 1 and # 2 exist. As a result, a node that does not exist in its own node information exists in the opposite node information in the boundary node, and the boundary node can recognize information of all nodes in the communication system even when a failure occurs.
  • the ring device # 3 when a frame is transmitted from the ring device # 1 that is a boundary node to the ring device # 3, the ring device # 3 It does not exist in the node information but exists in the opposite node information. Since the ring device # 1 recognizes that the node existing in the opposite node information exists in the bypass NW direction, the ring device # 1 transmits a frame addressed to the ring device # 3 to the bypass NW. On the other hand, in FIG. 6B, when the ring device # 1 transmits a frame to the ring device # 2, the ring device # 2 exists in its own node information of the ring device # 1. Since the ring device # 1 recognizes that the node existing in the own node information exists in the cascade NW direction, the ring device # 1 transmits a frame addressed to the ring device # 2 to the cascade NW.
  • the self-node information is information on a destination node that transmits a frame via the cascade NW.
  • the opposite node information is information on a destination node that transmits a frame via the detour NW when a failure occurs in the cascade NW. Therefore, the boundary node has the opposite node information that is a copy of the own node information of the opposite node in the detour NW, thereby forming a pseudo ring topology, and when the failure of the cascade NW occurs, the demarcation node quickly Can be switched.
  • FIG. 7A is a diagram for explaining an outline of frame conversion in the communication system according to the first embodiment.
  • the communication system shown in FIG. 7A is a communication system similar to FIG. 6A.
  • the boundary node stores the destination node information included in the header of the RPR frame in the VLAN tag, and inserts the VLAN tag at a predetermined position in the Ethernet frame. .
  • this Ethernet frame is received from the detour NW, the boundary node extracts destination node information from the VLAN tag of the received Ethernet frame, removes the VLAN tag, and adds an RPR header.
  • FIG. 7B is a diagram illustrating an example of transition due to frame conversion in the communication system according to the first embodiment. 7B, in the communication system shown in FIG. 7A, the frame transmitted from the NW (Ethernet) terminal under the ring device # 2 is the ring device # 2, ring device # 1, bypass network, ring device # 5. , Ring device # 4, an example in the case of following a route of NW (Ethernet) terminal under ring device # 4 is shown.
  • the frame FR1 transmitted from the NW (Ethernet) terminal under the ring device # 2 is a normal Ethernet frame.
  • This frame FR1 is given an RPR header by the ring device # 2, and is encapsulated in the RPR frame FR2.
  • the RPR frame FR2 in FIG. 7B a part of the RPR header is extracted and shown.
  • the destination of the Ethernet frame FR1 (original frame) is the NW terminal under the ring device # 4, so the destination node ID in the RPR header is the ring device # 4. .
  • each ring device recognizes the node ID of each ring device and the NW existing under each ring device by the RPR function, the destination NW of the Ethernet frame received from its own subordinate NW Thus, the destination node of the RPR can be acquired.
  • the RPR frame FR2 is transmitted to the ring device # 1 by the ring device # 2.
  • a frame FR3 in FIG. 7B shows the format of the VLAN tag in the first embodiment.
  • an IEEE 802.1Q VLAN tag has a TYPE field of 16 bits, a CFI field of 1 bit, a priority field of 3 bits, and a VLAN ID field of 12 bits.
  • 8 bits of the field storing the VLAN ID are used as the field storing the node ID (Node ID of the frame FR3 in the figure).
  • the remaining 4 bits of the field normally used as the VLAN ID field are reserved fields for future use (RSV field of frame FR3 in the figure).
  • RSV field of frame FR3 in the figure.
  • a value (0x8100) indicating that the frame is normally tagged according to IEEE802.1Q is stored.
  • a predetermined value indicating that the frame is a converted RPR frame. Stores the value.
  • the destination node ID and source node ID fields 6 bytes are prepared for the destination node ID and source node ID fields (DA and SA of frame FR2 in the figure).
  • the present invention is not limited to this, and when the destination node ID uses lower 8 bits or more, for example, the size of the node ID field in the VLAN tag may be changed (maximum 12 bits).
  • Ring device # 1 extracts the destination node ID (6 bytes) from the destination node ID field (DA of frame FR2 in the figure) of the header of the RPR frame FR2 received from the cascade NW. Next, the ring device # 1 deletes the RPR header of the frame FR2, and inserts the VLAN tag at a position defined in IEEE 802.1Q of the Ethernet frame. The node ID field of the VLAN tag stores the lower 8 bits of the destination node ID extracted from the RRP frame FR2. As a result, the RPR frame FR2 is converted into an Ethernet frame FR3. Ring device # 1 transmits this frame FR3 to the bypass NW. Note that the destination MAC address of the Ethernet header of the frame FR3 is the MAC address of the ring device # 5 that is the opposite node. Information such as the MAC address and IP address of the opposite node is set in the boundary node in advance.
  • the frame FR3 arrives at the ring device # 5 which is the other boundary node from the ring device # 1 via the detour NW.
  • ring device # 5 the reverse process of ring device # 1 is performed, and frame FR3 is converted to RPR frame FR4.
  • the ring device # 5 extracts the lower 8 bits of the destination node ID from the node ID field of the VLAN tag of the frame FR3, and adds the padding 40 bits to this to acquire the destination node ID.
  • Ring device # 5 deletes the VLAN tag from the Ethernet header of frame FR3, adds an RPR header, and stores the acquired destination node ID in the destination node ID field of the RPR header.
  • the Ethernet frame FR3 is converted into an RPR frame FR4. Since the destination node of the frame FR4 is the ring device # 4, the ring device # 5 transmits the frame FR4 to the cascade NW.
  • the RPR header is deleted by the ring device # 4 to become the Ethernet frame FR5 which is the original frame. Then, it is transmitted to the NW under the ring device # 4 where the destination terminal exists.
  • the source node information of the RPR frame is rewritten by the frame conversion between the RPR frame and the Ethernet frame executed in the ring device # 1 and the ring device # 5 which are the boundary nodes.
  • the transmission source node ID (SA, 6 bytes in the figure) of the frame FR2 in FIG. 7B is the ring device # 2
  • the transmission source node ID of the frame FR4 is the ring device # 5.
  • node information of the RPR network is attached to the Ethernet frame using an IEEE 802.1Q VLAN tag.
  • the increase in size compared to the normal Ethernet can be suppressed to 4 bytes. Therefore, it is possible to suppress a decrease in transfer capability of the bypass NW.
  • an RPR control frame broadcast by each ring device also flows through the bypass NW.
  • the ring device # 2 that is not the boundary node in FIG. 7A can acquire the information (control frame) of the ring devices # 3- # 5 from the ring device # 1 side via the bypass NW.
  • the ring device # 3- # 5 is present in the own node information corresponding to the interface on the ring device # 1 side, and the ring device # 2 moves in the direction in which the ring device # 1 is located. Recognize that exists.
  • ring device # 2 transmits a frame to ring device # 3- # 5
  • ring device # 2 transmits the frame in the direction in which ring device # 1 exists.
  • the ring device that is not a boundary node can communicate with the ring device existing ahead of the transmission path where the failure has occurred via the bypass NW.
  • FIG. 8 is a diagram illustrating an example of a hardware configuration of the ring device 1.
  • the ring device 1 shown in FIG. 8 is a ring device that becomes a boundary node.
  • the ring device 1 is a communication device such as a router or a switch, for example.
  • the ring device 1 is an example of a “communication device”.
  • the ring device 1 includes a control card 100, an IF card 110a, an IF card 110b, and a SW card 120.
  • the IF card 110a includes an interface 111 with the RPR network, and performs processing of a physical layer and a data link layer of data transmitted to or received from the RPR network.
  • the IF card 110b includes a LAN IF 112 that is an interface with an Ethernet work and a bypass IF 113, and performs processing of a physical layer and a data link layer of data transmitted to or received from the Ethernet work.
  • the LAN IF 112 is an interface connected to the Ethernet work under the ring device 1.
  • the bypass IF 113 is an interface connected to the bypass NW (Ethernet work).
  • the SW card 120 relays data between IF cards.
  • the control card 100 controls the IF card 110a, the IF card 110b, and the SW card 120. Further, the control card 100 operates as a control plane and executes software processing.
  • the control card 100 includes a processor 101, a volatile memory 102, and a nonvolatile memory 103.
  • the processor 101 is, for example, a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or an NPU (Network Processing Unit).
  • the processor 101 loads a program stored in the non-volatile memory 103 to the volatile memory 102 and executes it, and executes various processes. Further, the number of processors 101 is not limited to one, and a plurality of processors 101 may be provided.
  • the volatile memory 102 provides the processor 101 with a storage area and a work area for loading a program stored in the nonvolatile memory 103, and is used as a buffer.
  • the volatile memory 102 is a semiconductor memory such as SRAM (Static Random Access Memory) or DRAM (Dynamic Random Access Memory).
  • the nonvolatile memory 103 stores various programs and data used by the processor 101 when executing each program.
  • the auxiliary storage device 105 includes, for example, a nonvolatile memory such as PROM (Programmable / Read / Only / Memory).
  • PROM Programmable / Read / Only / Memory
  • the hardware configuration of the ring device 1 is not limited to the above, and components can be omitted, replaced, or added as appropriate according to the embodiment.
  • FIG. 9 is a diagram illustrating an example of functional blocks of the ring device 1.
  • the ring device 1 includes an RPR processing unit 11, a bypass NW processing unit 12, a LAN processing unit 13, a destination node determination unit 14, and a node list management unit when the processor 101 executes a communication program stored in the nonvolatile memory 103. 15 operates. Further, the node list database 16 (node list DB in the figure) is created in the storage area of the volatile memory 102 through the execution of the communication program of the processor 101.
  • each functional block may be realized by hardware by an electronic circuit such as FPGA (Field-Programmable Gate Array), ASIC (Application Specific Integrated Circuit), LSI (Large Scale Integration), or the like.
  • FPGA Field-Programmable Gate Array
  • ASIC Application Specific Integrated Circuit
  • LSI Large Scale Integration
  • the RPR processing unit 11 executes processing related to the RPR frame transmitted / received by the RPR IF 111 via the cascade NW (RPR). First, when an RPR frame is received by the RPR IF 111, the RPR processing unit 11 analyzes the RPR frame and extracts a destination node ID. Further, the RPR processing unit 11 deletes the RPR header from the received frame. Next, the RPR processing unit 11 inquires of the destination node determination unit 14 whether the extracted destination node ID exists in the node list DB 16. In the case of transmission of an RPR frame, the RPR processing unit 11 acquires a destination node ID from the destination node determination unit 14, adds an RPR header to the frame, and transmits the RPR frame from the RPR IF 111.
  • the RPR processing unit 11 is an example of a “second frame transmission unit”.
  • the detour NW processing unit 12 operates when a failure of the cascade NW (RPR) occurs, and executes processing related to an Ethernet frame transmitted and received by the detour IF 113 via the detour NW (Ethernet).
  • a VLAN tag is attached to the Ethernet frame transmitted / received by the detour IF 113 (see FIG. 7B, frame FR3). Therefore, when the Ethernet frame is received by the detour IF 113, the detour NW processing unit 12 analyzes the VLAN tag and extracts the node ID. Further, the detour NW processing unit 12 deletes the VLAN tag from the received frame.
  • the detour NW processing unit 12 inquires of the destination node determination unit 14 whether or not the extracted node ID exists in the node list DB 16.
  • the detour NW processing unit 12 acquires the destination node ID from the destination node determination unit 14, and stores the node ID in the VLAN tag.
  • the detour NW processing unit 12 inserts this VLAN tag at a predetermined position in the header to generate an Ethernet frame, and transmits the Ethernet frame from the detour IF 113.
  • the detour NW processing unit 12 is an example of a “frame transmission unit”.
  • the LAN processing unit 13 executes processing related to the Ethernet frame transmitted / received by the LAN IF 112 via the NW (Ethernet) under the ring device 1.
  • NW Network
  • the LAN processing unit 13 analyzes the received Ethernet frame and acquires a destination node having a destination NW of the Ethernet frame.
  • the association between the node ID of each ring device and the subordinate NW is acquired by, for example, the RPR function and stored in the volatile memory 102.
  • the LAN processing unit 13 inquires of the destination node determination unit 14 whether the acquired destination node exists in the node list DB 16.
  • the LAN processing unit 13 transmits the frame from the LAN IF 112.
  • the destination node determination unit 14 When the destination node determination unit 14 receives an inquiry from the RPR processing unit 11, the detour NW processing unit 12, and the LAN processing unit 13 about whether or not the destination node exists in the node list DB 16, the destination node determination unit 14 searches the node list DB 16.
  • the destination node determination unit 14 searches the destination node information 161 for a destination node.
  • the destination node determination unit 14 searches the destination node information 161 and the counter node information 162 for a destination node.
  • the destination node determination unit 14 determines transmission of a frame from the RPR IF 111 when the destination node exists in the own node information 161. Therefore, in this case, the destination node determination unit 14 instructs the RPR processing unit 11 to transmit a frame and notifies the destination node.
  • the destination node determination unit 14 determines transmission of a frame from the detour IF 113 when a destination node exists in the opposing node information 162 when a failure occurs in the cascade NW. In this case, the destination node determination unit 14 instructs the bypass NW processing unit 12 to transmit a frame and notifies the destination node.
  • the destination node determination unit 14 determines transmission of a frame from the LAN IF 112 when the destination node is its own device. In this case, the destination node determination unit 14 instructs the LAN processing unit 13 to transmit a frame.
  • the destination node determination unit 14 determines that the corresponding frame is discarded and discards the frame.
  • the destination node determination unit 14 is an example of a “determination unit”.
  • the node list management unit 15 manages the own node information 161 and the opposite node information 162 stored in the node list DB 16.
  • the node list management unit 15 updates the local node information 161 when information not included in the local node information is notified by the RPR control frame or according to the reception status of the RPR control frame. For example, when a control frame is received from a newly added ring device, the node list management unit 15 adds information about the ring device to its own node information. For example, for a ring device for which a control frame has not been received for a predetermined period or longer, the node list management unit 15 deletes it from its own node information.
  • the node list management unit 15 deletes it from its own node information.
  • the node list management unit 15 updates the opposite node information with a copy of the own node information of the opposite node received from the opposite node at a predetermined cycle.
  • the RPR control frame transmitted from each ring device also flows through the bypass NW, but the node list management unit 15 receives the RPR received through the bypass NW (by the bypass IF 113). No processing is performed for the control frame. For this reason, the node list management unit 15 does not update the node information in the RPR control frame received from the detour NW (by the detour IF 113).
  • the node list management unit 15 transmits a copy of the own node information 161 to the opposite node at a predetermined cycle.
  • This copy of the node information 161 is transmitted from the detour IF 113 regardless of whether or not the cascade network has a failure, and is transmitted via the detour NW.
  • the copy of the own node information 161 is handled as opposite node information in the opposite node.
  • the IP address and MAC address of the opposite node are set in the ring device 1 in advance.
  • the predetermined cycle is, for example, 3-10 ms.
  • the node list management unit 15 is an example of a “reception unit”.
  • the node list management unit 15 is an example of a “transmission unit”.
  • the node list DB 16 is a database that stores information on nodes existing in the RPR network recognized by the ring device 1.
  • the node list DB 16 stores its own node information 161 and opposing node information 162.
  • the node list DB 16 is an example of a “storage unit”.
  • the own node information 161 stores information on a destination node that transmits a frame from the RPR IF 111. Specifically, for example, as illustrated in FIG. 6A, the local node information 161 is a correspondence between the number of hops from the ring device 1 and the node ID.
  • the own node information 161 is associated with RPR IF 111, for example.
  • the own node information 161 is an example of a “first list”.
  • the opposite node information 162 is a copy of the own node information of the opposite node.
  • the opposite node information 162 is used when a failure occurs in the cascade NW (RPR network), and stores information on a destination node that transmits a frame from the detour IF 113.
  • the opposite node information 162 is associated with the detour IF 113, for example.
  • the opposing node information 162 is an example of a “second list”.
  • FIG. 10 is an example of a flowchart of processing relating to management of the own node information. The flowchart shown in FIG. 10 is repeatedly executed while the ring device 1 is activated.
  • the processor 101 determines whether or not the own node information 161 has been updated. Whether or not the own node information is updated is determined from, for example, the contents of the control frame and the reception status of the control frame. However, the control frame is received from the RPR network (with RPR IF 111). If the own node information 161 is updated (OP1: Yes), the process proceeds to OP2. If the own node information 161 is not updated (OP1: No), the process proceeds to OP3.
  • the processor 101 determines whether or not it is the transmission timing of the copy of the own node information 161. If it is the transmission timing of the copy of the own node information (OP3: Yes), the process proceeds to OP4. When it is not the transmission timing of the copy of the own node information (OP3: No), the processing shown in FIG. 10 is terminated and repeatedly executed.
  • the transmission timing of the copy of the own node information 161 is, for example, an interval of 3 ms-10 ms.
  • the processor 101 transmits the copy of the own node information 161 stored in the node list DB 16 from the detour IF 113 to the opposite node. Thereafter, the processing shown in FIG. 10 ends and is repeatedly executed.
  • the processing of OP1 to OP4 corresponds to a part of the processing of the node list management unit 15.
  • the transmission of the copy of the own node information 161 of OP4 from the detour IF 113 corresponds to a part of the process of the detour NW processing unit 12.
  • FIGS. 11, 12, and 13 are examples of flowcharts of frame transfer processing when a failure occurs in the cascade NW (RPR network).
  • FIG. 11 is an example of a flowchart of frame transfer processing when a frame is received by the RPR IF 111 when a cascade NW failure occurs.
  • the flowchart shown in FIG. 11 is started when a frame is received by the RPR IF 111 when a failure of the cascade NW occurs.
  • the processor 101 analyzes the RPR frame and extracts the destination node ID from the RPR header. In addition, the processor 101 deletes the RPR header from the received frame. Next, the process proceeds to OP12.
  • the processor 101 determines whether or not the extracted destination node ID exists in the own node information 161. If the destination node ID exists in the own node information 161 (OP12: Yes), the process proceeds to OP13. If the destination node ID does not exist in the own node information 161 (OP12: No), the process proceeds to OP16.
  • the processor 101 determines whether or not the destination node ID indicates the node ID of the own node. For example, the own node is registered with the hop number 0 in the own node information 161.
  • the processor 101 determines that the frame is transmitted from the LAN IF 112, and the process proceeds to OP14.
  • the destination node ID is not the node ID of the own node (OP13: No)
  • it is indicated that the destination node ID is the node ID of another ring device existing in the own node information 161.
  • the process proceeds to OP15, and the frame is discarded.
  • the processor 101 transmits a frame from the LAN IF 112. Thereafter, the process shown in FIG. 11 ends.
  • the processor 101 determines whether or not the destination node ID extracted in OP11 exists in the opposing node information 162. When the destination node ID is present in the opposite node information 162 (OP16: Yes), the processor 101 determines that the frame is transmitted from the detour IF 113 because the destination ID is present in the opposite node information 162, and processing is performed. Advances to OP17. If the destination node ID does not exist in the opposite node information 162 (OP16: No), the destination node ID does not exist in either the own node information 161 or the opposite node information 162, so the process proceeds to OP15 and the processor 101 Discards the frame.
  • the processor 101 stores the lower 8 bits of the destination node ID in the VLAN tag, and inserts this VLAN tag into the Ethernet header of the received frame.
  • the process proceeds to OP18, and the processor 101 transmits a frame from the detour IF 113. Thereafter, the process shown in FIG. 11 ends.
  • the process of OP11 corresponds to a part of the process of the RPR processing unit 11.
  • the processing of OP12, OP13, OP15, and OP16 corresponds to part of the processing of the destination node determination unit 14.
  • the process of OP14 corresponds to a part of the process of the LAN processing unit 13.
  • the processing of OP17 and OP18 corresponds to part of the processing of the detour NW processing unit 12.
  • FIG. 12 is an example of a flowchart of frame transfer processing when a frame is received by the detour IF 113 when a failure of the cascade NW occurs.
  • the flowchart shown in FIG. 12 is started when a frame is received in the detour IF 113 when a failure of the cascade NW occurs.
  • the frame received by the detour IF 113 is an Ethernet frame having a VLAN tag.
  • the processor 101 analyzes the Ethernet frame and extracts the node ID 8 bits from the VLAN tag. Further, the processor 101 deletes the VLAN tag from the Ethernet frame. Next, the process proceeds to OP22.
  • the processor 101 determines whether or not the extracted node ID exists in the own node information 161. If the extracted node ID exists in the own node information 161 (OP22: Yes), the process proceeds to OP23. If the destination node ID does not exist in the own node information 161 (OP22: No), the process proceeds to OP27.
  • the processor 101 determines whether or not the extracted node ID indicates the node ID of the own node.
  • the processor 101 determines that the frame is transmitted from the LAN IF 112, and the process proceeds to OP24.
  • the processor 101 determines that the frame is transmitted from the RPR IF 111, and the process proceeds to OP25.
  • the processor 101 transmits a frame from the LAN IF 112. Thereafter, the process shown in FIG. 12 ends.
  • the processor 101 pads the node ID extracted in OP21, stores it in the destination node ID field of the RPR header, adds the RPR header, and generates an RPR frame (see FIG. 7B, frame FR4).
  • the process proceeds to OP26, and the processor 101 transmits the RPR frame from the RPR IF 111 to the RPR network. Thereafter, the process shown in FIG. 12 ends.
  • the processor 101 discards the frame. If the destination node of the frame received by the detour IF 113 does not exist in the own node information 116, the same frame is transmitted to the detour NW again even if it exists in the opposite node information 162. The frame is discarded. Thereafter, the process shown in FIG. 12 ends.
  • the process of OP21 corresponds to a part of the process of the detour NW processing unit 12.
  • the processing of OP22, OP23, and OP27 corresponds to part of the processing of the destination node determination unit 14.
  • the process of OP24 corresponds to a part of the process of the LAN processing unit 13.
  • the processing of OP25 and OP26 corresponds to part of the processing of the RPR processing unit 11.
  • FIG. 13 is an example of a flowchart of frame transfer processing when a frame is received by the LAN IF 112 when a failure of the cascade NW occurs.
  • the flowchart shown in FIG. 13 is started when a frame is received in the LAN IF 112 when a failure of the cascade NW occurs.
  • the processor 101 obtains a destination node ID having the destination NW of the received Ethernet frame as a subordinate, and determines whether or not the destination node ID exists in the own node information 161. If the destination node ID exists in the own node information 161 (OP31: Yes), the process proceeds to OP32. If the destination node ID does not exist in the own node information 161 (OP31: No), the process proceeds to OP36.
  • the processor 101 determines whether or not the destination node ID indicates the node ID of the own node. When the destination node ID is the node ID of the own node (OP32: Yes), the same frame is transmitted again from the LAN IF 112, so the process proceeds to OP35 and the processor 101 discards the frame. If the destination node ID is not the node ID of the own node (OP32: No), the processor 101 determines that the frame is to be transmitted from the RPR IF 111, and the process proceeds to OP33.
  • the processor 101 stores the destination node ID in the destination node ID field of the RPR header, and adds the RPR header to generate an RPR frame (see FIG. 7B, frames FR1 and FR2).
  • the process proceeds to OP34, and the processor 101 transmits the RPR frame from the RPR IF 111 to the RPR network. Thereafter, the process shown in FIG. 13 ends.
  • the processor 101 determines whether or not the destination node ID exists in the opposing node information 162. When the destination node ID exists in the opposite node information 162 (OP36: Yes), the processor 101 determines that the frame is transmitted from the detour IF 113 because the destination node ID exists in the opposite node information 162. The process proceeds to OP37. If the destination node ID does not exist in the opposite node information 162 (OP36: No), the destination node ID does not exist in either the own node information 161 or the opposite node information 162, so the process proceeds to OP35, and the processor 101 Discards the frame.
  • the processor 101 stores the lower 8 bits of the destination node ID in the VLAN tag, and inserts the VLAN tag at a predetermined position in the Ethernet header. Next, the process proceeds to OP38, and the processor 101 transmits a frame from the detour IF 113. Thereafter, the process shown in FIG. 13 ends.
  • the process of acquiring the destination node ID of OP31 corresponds to a part of the process of the LAN processing unit 13.
  • the processing of OP31, OP32, OP35, and OP36 corresponds to part of the processing of the destination node determination unit 14.
  • the processing of OP33 and OP34 corresponds to part of the processing of the RPR processing unit 11.
  • OP37 and OP38 correspond to a part of the process of the detour NW processing unit 12.
  • FIG. 11 to FIG. 13 describe the processing when a failure occurs, but when the cascade NW recovers from the failure, the processing returns to the normal processing. That is, the opposite node information is not used for the search for the destination node.
  • Detection of failure recovery can be detected, for example, by receiving a control frame from the cascade NW and updating its own node information.
  • the restoration of the cascade NW may be determined when the nodes existing in the own node information and the opposite node information match.
  • the ring device serving as the boundary node of the cascade NW holds its own node information (opposite node information) of the opposite node.
  • Opposite node information indicates information of a destination node via a detour NW (Ethernet).
  • the network is switched to the detour NW, so that it is possible to maintain a switching time (within 50 ms) that is a measure of availability.
  • a switching time within 50 ms
  • a pseudo ring is formed using a network different from the RPR. can do.
  • the destination information of the RPR is stored in the VLAN tag, and this VLAN tag is inserted into the Ethernet frame.
  • the frame can be transmitted to the detour NW while maintaining the destination information of the RPR.
  • FIG. 14 is a diagram illustrating an application example of the first embodiment.
  • the example shown in FIG. 14 is an example in which the bypass NW is shared by two RPR networks of RPR1 and RPR2.
  • ring devices # 1 and # 5 which are the boundary nodes of RPR1
  • ring devices # 11 and # 15 which are the boundary nodes of RPR2
  • a layer 2 switch In the detour NW, ring devices # 1 and # 5, which are the boundary nodes of RPR1, and ring devices # 11 and # 15, which are the boundary nodes of RPR2, are connected to each other via a layer 2 switch.
  • the number of frames flowing through the detour NW is small (for example, the opposite node information), so it is not necessary to prepare the total bandwidth of the two RPR networks RPR1 and RPR2 for the detour NW.
  • a band should be prepared. By sharing the detour NW among a plurality of cascade NWs, the band can be used effectively.
  • the boundary node when transferring a frame to the detour NW (Ethernet), the boundary node stores the QoS information of the cascade NW in the header of the Ethernet frame in addition to the destination information of the cascade NW (RPR). . Thereby, it is possible to prevent the QoS information of the cascade NW from being lost due to passing through the bypass NW.
  • the description common to the first embodiment is omitted. Also in the second embodiment, the configuration of the communication system is assumed to be FIG. 6A and FIG. 7A as in the first embodiment.
  • FIG. 15 is a diagram illustrating an example of transition due to frame conversion in the communication system according to the second embodiment.
  • the frame transmitted from the NW (Ethernet) terminal under the ring device # 2 is the ring device # 2, ring device # 1, detour.
  • An example is shown in the case of following a route of an NW (Ethernet) terminal under the network, ring device # 5, ring device # 4, and ring device # 4.
  • the RPR frame FR2 is converted into an Ethernet frame FR3 for transfer to the detour NW.
  • a VLAN tag is inserted into an Ethernet frame, as in the first embodiment.
  • the QoS information included in the header of the RPR frame is stored in the VLAN tag in addition to the lower 8 bits of the destination node ID.
  • a 2-byte (16 bits) field used as a VLAN ID field in a normal VLAN tag is used as a node ID (8 bits), a service class (2 bits), and a reservation (2 bits).
  • the node ID field stores the lower 8 bits of the value stored in the destination node ID field (6 bytes) of the RPR frame FR2.
  • SC service class field
  • C control field
  • CRL control field
  • the RPR frame 1 byte is prepared in the control field, but since 2 bits are actually used in many cases, 2 bits are prepared in the service class field of the VLAN tag in the second embodiment.
  • the present invention is not limited to this, and when five service classes are used, the service class field of the VLAN tag may be set to 3 bits and the reserved field may be set to 1 bit.
  • the frame FR3 is transmitted from the ring device # 1 and arrives at the ring device # 5 via the detour NW.
  • Ring device # 5 converts Ethernet frame FR3 to RPR frame FR4 for transmission to the RPR network.
  • the field values of the node ID and the service class are extracted from the VLAN tag of the Ethernet frame FR3, and the VLAN tag is deleted from the frame FR3.
  • an RPR header is added to the frame, and the extracted node ID and service class values are stored in the destination node ID and control fields of the RPR header, respectively, and the frame FR4 is acquired.
  • the insufficient bits of the node ID and service class are padded.
  • the Ethernet frame FR3 is converted into an RPR frame FR4.
  • FIG. 16 is a diagram for explaining the outline of the communication system according to the second embodiment.
  • RPR stipulates that all bands on the ring are the same. However, there may be cases where only a bandwidth equal to or lower than the bandwidth of the cascade NW (RPR) can be prepared as the bypass NW.
  • RPR the bandwidth of the cascade NW
  • the bypass NW band is smaller than the cascade NW band, if the cascade NW QoS information is applied as it is, data loss may occur in the bypass NW.
  • each ring device in the RPR network holds a plurality of QoS tables for storing QoS information, and uses different QoS tables depending on whether it is normal or when a failure occurs.
  • each of the ring devices # 1 to # 5 has a QoS table 1 for normal use and a QoS table 2 for failure use.
  • bandwidth control information according to the bandwidth of the cascade NW 1000 Mbps is set.
  • band control information for the detour NW band 600 Mbps is set.
  • each ring device uses the normal QoS table 1 and performs bandwidth control for 1000 Mps.
  • the bandwidth control setting may exceed the bandwidth 600 Mbps of the cascade NW.
  • the failure notification is performed in the cascade NW by the ring device # 2 and the ring device # 3.
  • ring device # 1 and ring device # 5 which are boundary nodes, receive the failure notification, they transmit a control frame instructing switching of the QoS table to the ring device of the cascade NW.
  • the ring devices # 2- # 4 switch from the QoS table 1 to the QoS table 2 for failure.
  • Ring device # 1 and ring device # 5 which are boundary nodes, switch from QoS table 1 to QoS table 2 for failure by transmitting a control frame instructing switching of the QoS table.
  • the QoS table 2 for failure is used, and bandwidth control according to the bandwidth of the detour NW is executed. Therefore, the minimum necessary data communication can be ensured even when a failure occurs.
  • a control frame instructing switching of the QoS table is transmitted to the cascade NW at the timing when the ring device # 1 and the ring device # 5 which are boundary nodes detect the failure recovery.
  • each of the ring devices # 2 to # 4 switches the QoS table to be used from the QoS table 2 for failure to the QoS table 1 for normal operation.
  • switching the QoS table to be used is not limited to a QoS table switching instruction using a control frame from a boundary node.
  • the QoS table used autonomously by each ring device # 1-5 may be switched by detecting the occurrence of a failure, receiving a notification of the occurrence of a failure, detecting a failure recovery, and the like.
  • FIG. 17 is an example of a functional block of the ring device 1b which is a boundary node in the second embodiment.
  • the hardware configuration of the ring device 1b is the same as that of the ring device 1 of the first embodiment.
  • the processor 101 executes a communication program stored in the nonvolatile memory 103, the RPR processing unit 11, the detour NW processing unit 12, the LAN processing unit 13, the destination node determination unit 14, and the node list management unit In addition to 15, it further operates as a QoS processing unit 17.
  • a node list DB 16 through installation or execution of the communication program of the processor 101, a node list DB 16, a normal-time QoS table 18a, and a failure-time QoS table 18b are created in the storage area of the volatile memory 102.
  • the normal-time QoS table 18a and the failure-time QoS table 18b may be set by user input.
  • the present invention is not limited to this, and each functional block may be realized by hardware by an electronic circuit such as FPGA or ASIC.
  • the QoS processing unit 17 manages the QoS information given to the frame received from the NW subordinate to the ring device 1b and transferred to the cascade NW or the detour NW.
  • the QoS processing unit 17 stores a QoS table to be used, and in response to an inquiry from the LAN processing unit 13 when a frame is transmitted from the NW under the ring device 1b to the cascade NW or the detour NW, Read QoS information from the stored QoS table.
  • the read QoS information is notified to the RPR processing unit 11 or the detour NW processing unit 12 according to the transfer destination of the corresponding frame.
  • the QoS processing unit 17 transmits a QoS frame switching instruction control frame (from the RPR IF 111) to the cascade NW when a failure notification is received and when a failure recovery is detected.
  • the QoS processing unit 17 rewrites the used QoS table stored in the QoS processing unit 17 to the normal-time QoS table 18a or the failure-time QoS table 18b, and switches the QoS table.
  • the detection of failure recovery is detected, for example, by updating the own node information or when the ring devices included in the own node information and the opposite node information are the same by updating the own node information.
  • the RPR processing unit 11 executes the following processing in addition to the processing of the first embodiment.
  • the RPR processing unit 11 analyzes the RPR frame and extracts a value from the destination node ID and control fields.
  • the RPR processing unit 11 acquires a destination node ID and a service class, and stores values in the destination node ID and control fields of the RPR header.
  • the destination node ID is acquired from the destination node determination unit 14.
  • the service class is acquired by notification from the QoS processing unit 17 or the detour NW processing unit 12 according to the reception interface.
  • the RPR processing unit 11 adds an RPR header to the frame and transmits the RPR frame from the RPR IF 111.
  • the detour NW processing unit 12 executes the following processing in addition to the processing of the first embodiment.
  • the detour NW processing unit 12 analyzes the VLAN tag and extracts a value from the node ID and service class fields.
  • the detour NW processing unit 12 acquires the destination node ID and the service class and stores them in the VLAN tag.
  • the destination node ID is acquired from the destination node determination unit 14.
  • the service class is acquired by notification from the QoS processing unit 17 or the RPR processing unit 11.
  • the detour NW processing unit 12 generates an Ethernet frame by including this VLAN tag in the header, and transmits the Ethernet frame from the detour IF 113.
  • the LAN processing unit 13 inquires the QoS processing unit 17 about QoS information when the LAN IF 112 receives an Ethernet frame.
  • the destination node determination unit 14, the node list management unit 15, and the node list DB 16 are the same as those in the first embodiment.
  • bandwidth control information according to the bandwidth of the cascade NW is set.
  • bandwidth control information corresponding to the bandwidth of the bypass NW is set.
  • FIG. 18 is a diagram illustrating an example of functional blocks of the ring device 2 that is not a boundary node.
  • the hardware configuration of the ring device 2 is the same as that of the ring device 1b, which is a boundary node, as shown in FIG.
  • the processor 101 executes a communication program stored in the nonvolatile memory 103, the RPR processing unit 21, the LAN processing unit 23, the destination node determination unit 24, the node list management unit 25, and the QoS processing unit 27. Works as.
  • a node list DB 26 By installing or executing the communication program, a node list DB 26, a normal-time QoS table 28a, and a failure-time QoS table 28b are created in the storage area of the volatile memory 102.
  • the normal-time QoS table 28a and the failure-time QoS table 28b may be set by user input.
  • the node list DB 26 stores its own node information 261. Since the ring device 2 that is not a boundary node is not connected to the detour NW and does not recognize the detour NW, the ring device 2 does not have counter node information. Band control information according to the bandwidth of the cascade NW is set in the normal-time QoS table 28a. In the failure QoS table 28b, bandwidth control information corresponding to the bandwidth of the bypass NW is set.
  • the ring device 2 other than the boundary node is connected to the RPR network and the subordinate Ethernet work, and executes substantially the same processing as the ring device 1b that is the boundary node except that the processing related to the detour NW is not executed.
  • the RPR processing unit 21 processes frames transmitted and received in the RPR IF 111. Therefore, the processing of the RPR processing unit 21 and the LAN processing unit 23 is the same processing as the RPR processing unit 11 and the LAN processing unit 13 of the ring device 1b of the boundary node.
  • the destination node determination unit 24 and the node list management unit 25 determine the destination node of the ring device 1b of the boundary node except that the processing related to the opposite node is not performed because the ring device 2 other than the boundary node does not hold the opposite node information.
  • the processing is the same as that of the unit 14 and the node list management unit 15.
  • the QoS processing unit 27 manages the QoS information given to the frame received from the NW subordinate to the ring device 2 and transferred to the cascade NW.
  • the QoS processing unit 27 stores a QoS table to be used, and is used in response to an inquiry from the LAN processing unit 23 when a frame is transmitted from the NW subordinate to the ring device 2 to the cascade NW.
  • QoS information is read from the QoS table in which is stored. The read QoS information is notified to the RPR processing unit 21.
  • the QoS processing unit 27 When the QoS processing unit 27 receives a control frame for switching the QoS table from the ring device 1b, which is a boundary node, the QoS processing unit 27 rewrites the QoS table to be used into the normal-time QoS table 28a or the failure-time QoS table 28b. To switch the QoS table.
  • boundary node 19
  • 20, and 21 are examples of flowcharts of the frame transfer process of the ring device 1 b at the boundary node when a failure occurs in the cascade NW.
  • FIG. 19 is an example of a flowchart of frame transfer processing of the ring device 1b of the boundary node when a frame is received by the RPR IF 111 when a failure of the cascade NW occurs.
  • the flowchart shown in FIG. 19 is started when a frame is received by the RPR IF 111 when a failure of the cascade NW occurs.
  • the processor 101 analyzes the RPR frame received in the RPR IF 111, and extracts values stored in the destination node ID field and the control field of the RPR header. In addition, the processor 101 deletes the header of the RPR frame.
  • the frame at this time is a normal Ethernet frame (see FIG. 7B).
  • the processor 101 inserts the VLAN tag into a predetermined position of the Ethernet header of the frame from which the RPR header is removed in OP41.
  • the node ID field of the VLAN tag stores the lower 8 bits of the destination node ID extracted in OP41. Also, 2 bits used in the control field value of the RPR header extracted in OP41 are stored in the service class field of the VLAN tag.
  • FIG. 20 is an example of a flowchart of a frame transfer process of the ring device 1b which is a boundary node when a frame is received by the detour IF 113 when a failure of the cascade NW occurs.
  • the flowchart shown in FIG. 20 is started when a frame is received in the detour IF 113 when a failure of the cascade NW occurs.
  • the frame received by the detour IF 113 is an Ethernet frame having a VLAN tag.
  • the processor 101 analyzes the Ethernet frame received by the detour IF 113 from the detour NW, and extracts the value of 8 bits in the node ID field of the VLAN tag. Further, the processor 101 extracts 2 bits of the value of the service class field of the VLAN tag. The processor 101 deletes the VLAN tag from the Ethernet frame.
  • the processor 101 since it is determined that the Ethernet frame received by the detour IF 113 is transmitted to the RPR network, the processor 101 generates an RPR frame by adding an RPR header to the Ethernet frame (FIG. 7B, frame FR3, FR4).
  • the processor 101 stores, in the destination node ID field of the RPR frame, a value obtained by padding the value 8 bits of the node ID field of the VLAN tag extracted in OP21 to 6 bytes. Further, the processor 101 stores a value of 1 byte by padding the value of the service class field of the VLAN tag extracted in OP21 with 2 bits in the control field of the RPR frame.
  • FIG. 21 is an example of a flowchart of frame transfer processing of the ring device 1b, which is a boundary node when a frame is received by the LAN IF 112.
  • the flowchart shown in FIG. 21 is started when a frame is received by the LAN IF 112.
  • the processor 101 acquires QoS information from the QoS table being used.
  • the normal-time QoS table 18a is used.
  • the failure QoS table 18b is used.
  • the processor 101 since it is determined that the Ethernet frame received by the LAN IF 112 is transferred to the cascade NW (RPR), the processor 101 adds an RPR header to the Ethernet frame to generate an RPR frame (see FIG. 7B, frames FR1 and FR2).
  • the processor 101 stores the destination node ID acquired from the association between the subordinate NW and the node ID in the destination node ID field of the RPR frame. Further, the processor 101 stores the service class specified by the QoS information acquired in OP60 in the control field of the RPR frame. This frame is transmitted from the RPR IF 111 to the cascade NW (RPR).
  • the processor 101 inserts a VLAN tag at a predetermined position of the Ethernet frame.
  • the processor 101 stores the lower 8 bits of the destination node ID acquired from the association between the subordinate NW and the node ID in the node ID field of the VLAN tag. Further, the processor 101 stores the service class specified by the QoS information acquired in OP60 in the service class field of the VLAN tag. This frame is transmitted from the detour IF 113 to the detour NW (Ethernet).
  • the ring device 1b which is a boundary node, stores the QoS information in the VLAN Ntag (RPR) by storing the QoS information in the VLAN tag when the frame is transferred to the detour NW (Ethernet). Embed in a frame. Thereby, it is possible to prevent the QoS information of the cascade NW from being lost even when the detour NW is routed.
  • RPR VLAN Ntag
  • NW Ethernet
  • the ring devices in the cascade NW use different QoS tables depending on whether the cascade NW is normal or faulty. As a result, when a failure occurs in the cascade NW, bandwidth control according to the detour NW having a narrower bandwidth than the cascade NW is executed, and data loss can be prevented.
  • FIG. 22 shows an example in which the bypass NW is shared by two RPR networks, RPR1 and RPR2.
  • ring devices # 1 and # 5 which are the boundary nodes of RPR1
  • ring devices # 11 and # 15 which are the boundary nodes of RPR2
  • each ring device includes a QoS table 3 for double failure in addition to the QoS table 1 for normal time and the QoS table 2 for failure, and these are provided. Use properly.
  • the bandwidth of the cascade NW of RPR1 and RPR2 is 1000 Mbps
  • the bandwidth of the bypass NW is 600 Mbps.
  • the normal QoS table 1 stores the bandwidth control settings corresponding to the bandwidth of 1000 Mpbs of the cascade NW.
  • the QoS table 2 for failure is stored with bandwidth control settings corresponding to the bypass NW bandwidth 600 Mpbs.
  • the QoS table 3 for double failure stores bandwidth control settings according to the bandwidth that can be used at the time of double failure, such as 300 Mpbs, which is half of the bandwidth of the bypass NW.
  • RPR1 will be described, RPR2 can be similarly configured.
  • the ring devices # 1 and # 5 which are boundary nodes, detect a double failure, they notify the occurrence of the double failure to the ring devices # 2- # 4 in the cascade NW using a control frame.
  • ring device # 2- # 4 in cascade NW receives the notification of the occurrence of a double failure, it switches the QoS table to be used to QoS table 3 for double failure.
  • the ring devices # 1 and # 5 transmit a control frame for notifying a double failure, the ring devices # 1 and # 5 switch the QoS table to be used to the QoS table 3 for double failure.
  • Each ring device has a QoS table for double failure, and when a double failure occurs, a double failure occurs when a detour NW is shared by multiple cascade NWs by using the QoS table for double failure.
  • a double failure occurs when a detour NW is shared by multiple cascade NWs by using the QoS table for double failure.

Abstract

　カスケード型のトポロジの第１のネットワークの終端に接続し、第２のネットワークにも接続する通信装置である。この通信装置は、第１のネットワーク経由のフレームの送信の宛先である第１のネットワーク内の通信装置の情報を含む第１のリストを、第１のネットワークのもう一方の終端に位置する第２のネットワークにおいて対向する通信装置に送信し、該対向する通信装置から、該対向する通信装置の第１のネットワーク経由のフレームの送信の宛先である第１のネットワーク内の通信装置の情報を含む第２のリストを受信する。通信装置は、フレームの宛先が、第１のリスト又は第２のリストのいずれに含まれるか判定し、第１のネットワークから受信したフレームの宛先が第２のリストに含まれる場合に、フレームを第２のネットワークに送信する。

Description

通信装置、通信方法、及び通信プログラム
　本発明は、カスケード型のトポロジのネットワークにおける通信装置，通信方法，及び通信プログラムに関する。
　次世代ＩＰネットワーク（ＮＧＮ：Next Generation Network）のバックボーンの構築技術として注目されている技術に、ＲＰＲ（Resilient Packet Ring）がある。ＲＰＲは、ＩＥＥＥ８０２．１７として標準化されている。ＲＰＲは、１０Ｇビット／秒の高速回線をフレーム単位で効率的に利用するための技術である。ＩＥＥＥ８０２．１７では、各ノードの接続形態として、リング型トポロジとカスケード型トポロジとが規定されている。
　図１は、リング型トポロジの一例を示す図である。リング型トポロジは、各ノードが環状に接続する形態である。リング型トポロジでは、障害が発生しても、障害が発生している方向とは逆方向を利用して通信が可能であり、信頼性が高い。そのため、ＲＰＲのリング型トポロジは、通信事業者が提供する通信サービスの可溶性の目安である、障害発生時に５０ｍｓ以内に復旧することを実現可能である。しかしながら、ＩＥＥＥ８０２．１７の仕様により、リング型トポロジを構築する場合にはリング上の全伝送路をＲＰＲにする、という制約がある。
　図２は、カスケード型トポロジの一例を示す図である。カスケード型トポロジは、ノードが直列に接続された形態である。カスケード型トポロジは、一カ所の伝送路障害でネットワークが分断し、通信不可となる可能性が高い。
特開平１０－２９０２５２号公報
　図３Ａは、カスケード型トポロジのＲＰＲネットワークの例を示す図である。図３では、リング装置＃１－＃５がカスケード型トポロジのＲＰＲネットワークを構築している。各リング装置＃１－＃５は、所定間隔でＲＰＲの制御フレームを送信し、他のリング装置からの制御フレームによりトポロジを学習して、自ノード情報を作成する。自ノード情報は、ＲＰＲネットワークにおけるノードの並び順を示す情報である。また、自ノード情報は、ＲＰＲネットワークに接続するインタフェース毎に作成される。例えば、自ノード情報は、該当インタフェース方向に位置するリング装置のノードＩＤと自装置からのホップ数とを含む。
　図３Ａでは、リング装置＃１とリング装置＃５とが有する自ノード情報が示される。図３Ａにおけるカスケード型トポロジの一端に位置するリング装置＃１の自ノード情報は、例えば、０ホップにリング装置＃１（自装置）、１ホップの距離にリング装置＃２、．．．、４ホップの距離にリング装置＃５となる。リング装置＃１及びリング装置＃５は、ＲＰＲフレームを送信する際には、宛先ノードを自ノード情報で検索し、宛先ノードが自ノード情報に存在する場合に、該自ノード情報に対応するインタフェースからＲＰＲフレームを送信する。宛先ノードが自ノード情報に存在しない場合には、該当フレームは廃棄される。なお、リング装置＃１とリング装置＃５とは、カスケード型トポロジの端に位置するノードであり、１つのＲＰＲネットワークに接続するインタフェースを備えるため、保有する自ノード情報はそれぞれ１つである。ただし、リング装置＃２－＃４はそれぞれ２つのＲＰＲネットワークに接続するインタフェースを備えるため、それぞれのインタフェースに対する自ノード情報を、計２つ備える。リング装置＃２－＃４は、ＲＰＲフレームを送信する場合には、各インタフェースに対応する自ノード情報で宛先ノードを検索し、宛先ノードが存在する自ノード情報に対応するインタフェーエスからＲＰＲフレームを送信する。いずれの自ノード情報にも宛先ノードが存在しない場合には、フレームは廃棄される。
　図３Ｂは、図３Ａに示されるカスケード型トポロジのＲＰＲネットワークにおいて障害が発生した場合の例を示す図である。図３Ｂでは、リング装置＃２とリング装置＃３との間の伝送路で障害が発生している。この場合には、障害発生の伝送路に接続するリング装置＃２とリング装置＃３とが、それぞれ、障害発生を検知し、他のリング装置に障害通知を送信する。図３Ｂには、リング装置＃１とリング装置＃５の自ノード情報が示される。
　例えば、リング装置＃１は、リング装置＃２から障害通知を受信する。その後、障害発生の伝送路の先に位置するリング装置＃３、＃４、＃５の情報を受信しなくなるので、リング装置＃１の自ノード情報からリング装置＃３、＃４、＃５の情報は削除される。したがって、リング装置＃１は、リング装置＃３、＃４、＃５の情報が自ノード情報に存在しないために、リング装置＃３、＃４、#５に対してフレームを送信できなくなる。
　同様に、リング装置＃５は、リング装置＃３から送信された障害通知を受信する。リング装置＃５から見て障害発生の伝送路の先に位置するリング装置＃１、＃２の情報を受信しなくなるので、リング装置＃５の自ノード情報からリング装置＃１、＃２の情報は削除される。したがって、リング装置＃５は、リング装置＃１、＃２の情報が自ノード情報に存在しないために、リング装置＃１、＃２にフレームを送信できなくなる。
　また、リング装置＃２は障害発生の伝送路に接続するインタフェースに対応する自ノード情報が失われるため、リング装置＃３－＃５にフレームを送信できなくなる。リング装置＃３は、障害発生の伝送路に接続するインタフェースに対応する自ノード情報が失われるため、リング装置＃１、＃２にフレームを送信できなくなる。リング装置＃４は、リング装置＃１、＃２の情報を受信しなくなるので、自ノード情報からリング装置＃１、＃２の情報が削除され、リング装置＃１、＃２にフレームを送信できなくなる。
　このようにして、トポロジ型ネットワークでは、障害発生により、ネットワークが分断される。
　上記問題を鑑み、カスケード型トポロジでは、障害発生の対策として迂回路を設けることが考えられる。
　本発明の一態様は、カスケード型トポロジの第１のネットワークに第１のネットワークとは異なる第２のネットワークによる迂回路を提供する通信装置，通信方法，及び通信プログラムを提供することを目的とする。
　本発明の態様の一つは、カスケード型のトポロジの第１のネットワークの終端に接続し、前記第１のネットワークとはフレームの形式が異なる第２のネットワークにも接続する通信装置であって、
　前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第１のリストを、前記第１のネットワークのもう一方の終端に位置し、前記第２のネットワークにも接続し、前記第２のネットワークにおいて対向する通信装置に、送信する送信部と、
　前記対向する通信装置から、前記対向する通信装置の前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第２のリストを受信する受信部と、
　前記第１のリストと、前記第２のリストとを格納する格納部と、
　フレームの宛先が、前記第１のリスト又は前記第２のリストのいずれに含まれるか判定する判定部と、
　前記第１のネットワークから受信したフレームの宛先が前記第２のリストに含まれる場合に、前記フレームを前記第２のネットワークに送信するフレーム送信部と、
を備える通信装置である。
　本発明の他の態様の一つは、上述した通信装置が実行する通信方法である。また、本発明の他の態様は、コンピュータを通信装置として機能させる通信プログラム、及び当該通信プログラムを記録したコンピュータ読み取り可能な記録媒体を含むことができる。コンピュータ等が読み取り可能な記録媒体には、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。
　開示の通信装置，通信方法，及び通信プログラムによれば、カスケード型トポロジの第１のネットワークに第１のネットワークとは異なる第２のネットワークによる迂回路を提供することができる。
リング型トポロジの一例を示す図である。 カスケード型トポロジの一例を示す図である。 カスケード型トポロジのＲＰＲネットワークの例を示す図である。 図３Ａに示されるカスケード型トポロジのＲＰＲネットワークにおいて障害が発生した場合の例を示す図である。 カスケード型トポロジにおける迂回路の設計案１を示す図である。 カスケード型トポロジにおける迂回路の設計案２を示す図である。 ＲＰＲフレームをカプセル化した場合のイーサネットフレームのフォーマットを示す図である。 第１実施形態における迂回路を有する通信システムの概要を説明するための図である。 カスケードＮＷの障害発生時の通信システムの概要を説明するための図である。 第１実施形態に係る通信システムにおけるフレーム変換の概要を説明するための図である。 第1実施形態に係る通信システムにおけるフレームの変換による変遷の例を示す図である。 リング装置のハードウェア構成の一例を示す図である。 リング装置の機能ブロックの一例を示す図である。 自ノード情報の管理に係る処理のフローチャートの一例である。 カスケードＮＷの障害発生時に、ＲＰＲ　ＩＦにおいてフレームが受信された場合のフレーム転送処理のフローチャートの一例である。 カスケードＮＷの障害発生時に、迂回ＩＦにおいてフレームが受信された場合のフレーム転送処理のフローチャートの一例である。 カスケードＮＷの障害発生時に、ＬＡＮ　ＩＦにおいてフレームが受信された場合のフレーム転送処理のフローチャートの一例である。 迂回ＮＷがＲＰＲ１とＲＰＲ２との２つのＲＰＲネットワークで共有される例である。 第２実施形態に係る通信システムにおけるフレームの変換による変遷の例を示す図である。 第２実施形態の通信システムの概要を説明するための図である。 第２実施形態における境界ノードであるリング装置の機能ブロックの一例である。 境界ノードではないリング装置の機能ブロックの一例を示す図である。 カスケードＮＷの障害発生時に、ＲＰＲ　ＩＦにおいてフレームが受信された場合の境界ノードのリング装置のフレーム転送処理のフローチャートの一例である。 カスケードＮＷの障害発生時に、迂回ＩＦにおいてフレームが受信された場合の境界ノードであるリング装置のフレーム転送処理のフローチャートの一例である。 ＬＡＮ　ＩＦにおいてフレームが受信された場合の境界ノードであるリング装置のフレーム転送処理のフローチャートの一例である。 迂回ＮＷがＲＰＲ１とＲＰＲ２との２つのＲＰＲネットワークで共有される例である。
　以下、図面に基づいて、本発明の実施の形態を説明する。以下の実施形態の構成は例示であり、本発明は実施形態の構成に限定されない。
　＜イーサネット網を利用したカスケード型トポロジの迂回路＞
　図４は、カスケード型トポロジにおける迂回路の設計案１を示す図である。図４に示される例では、カスケード型トポロジのＲＰＲネットワークの両端に位置するノード同士はイーサネットで接続され、これによって、迂回路が構築される。カスケード型トポロジのＲＰＲネットワークの端に位置し、ＲＰＲネットワークとイーサネットの境界に位置するノードを、以降、境界ノードと称する。また、カスケード型のＲＰＲネットワークをカスケードＮＷとも称する。
　しかしながら、設計案１では、以下のような問題がある。例えば、ＲＰＲネットワーク内の伝送路に障害が発生した場合に、境界ノードのＬＡＮ側ネットワーク同士を接続すると、ＬＡＮにおいてＳＴＰ（Spanning Tree Protocol）が実行される。このＳＴＰの実行には数秒要するため、設計案１における障害発生時の切替時間が、可用性の目安である切り替え時間（５０ｍｓ以内）を超えてしまう。また、例えば、フレームが迂回路（イーサネット）を通過する際に、ＲＰＲのフォーマットのままでは通過できないので、フレームからＲＰＲヘッダが取り外され、オリジナルのイーサネットフレームにされてしまう。そのため、ＲＰＲネットワーク用のＱｏＳ情報は欠落してしまう。オリジナルのイーサネットフレームとは、リング装置の配下のＮＷ（イーサネット）内の端末から送信されるイーサネットフレームを指す。したがって、フレームが、迂回路を経由して再度ＲＰＲネットワークに到達した場合に、ＲＰＲネットワーク内で適正な優先制御が行われないおそれがある。
　図５Ａは、カスケード型トポロジにおける迂回路の設計案２を示す図である。図５Ａに示される例では、図４と同様に、カスケード型トポロジのＲＰＲネットワークの境界ノード同士が、イーサネットで接続され、これによって、迂回路が構築される。図５に示される設計案２では、迂回路（イーサネット）にフレームを送信するために、境界ノードがＲＰＲフレームをイーサネットフレームでカプセル化する。イーサネットでカプセル化することによって、ＲＰＲフレームのヘッダが維持され、ＲＰＲネットワーク用のＱｏＳ情報の欠落が防がれる。しかしながら、以下の問題がある。
　図５Ｂは、ＲＰＲフレームをカプセル化した場合のイーサネットフレームのフォーマットを示す図である。ＲＰＲフレームをカプセル化したイーサネットフレームの場合、通常のイーサネットフレームに比べて、ＲＰＲヘッダ（２６バイト），ＲＰＲフレームをカプセル化するためのイーサネットヘッダ（合計１８バイト）の分だけサイズが大きくなる。そのため、迂回路におけるフレーム転送能力が低下する。例えば、最小サイズ（６４バイト）のイーサネットフレームを伝送する際に、ＲＰＲフレームをイーサネットフレームでカプセル化すると、フレームサイズが増加するために、フレームの転送能力が８割程度低下する。すなわち、設計案２の場合には、ＲＰＲフレームをイーサネットでカプセリングすることによるフレームサイズの増加により迂回路の使用帯域が増加してしまう。
　＜第１実施形態＞
　第１実施形態では、可用性の目安である切替時間（５０ｍｓ）を維持し、迂回ネットワークのフレームの転送能力の低下を防ぐ通信方法を提供する。
　図６Ａは、第１実施形態における迂回路を有する通信システムの概要を説明するための図である。第１実施形態における通信システムは、カスケード型トポロジのＲＰＲネットワーク（図中、カスケードＮＷ）と、迂回路としてのイーサネット（図中、迂回ＮＷ）とを含む。リング装置＃１－＃５は、ＲＰＲネットワークに接続し、カスケード型トポロジを構築している。リング装置＃１とリング装置＃５と（境界ノード）は、ＬＡＮインタフェースを用いてイーサネットにも接続している。
　第１実施形態では、境界ノードであるリング装置＃１、＃５は、自ノード情報に加えて、対向ノード情報を有する。図６Ａでは、リング装置＃１とリング装置＃１との、自ノード情報と対向ノード情報とが示される。対向ノード情報は、迂回ＮＷにおいて対向するノード、言い換えると、カスケードＮＷのもう一端の境界ノードが保持する自ノード情報のコピーである。したがって、図６Ａに示される例において、リング装置＃１の自ノード情報とリング装置＃５の対向ノード情報とは同一である。また、図６Ａに示される例において、リング装置＃５の自ノード情報とリング装置＃１の対向ノード情報とは同一である。
　例えば、各境界ノードは、迂回ネットワーク経由で自ノード情報のコピーを定期的に送信し、対向ノードからの自ノード情報のコピーを受信することによって、対向ノード情報を取得する。例えば、３－１０ｍｓの周期で、制御フレームによって、自ノード情報のコピーは送信される。この対向ノード情報は、各境界ノードにとって、迂回ＮＷ方向のノードの並び順を示す情報となる。一方、自ノード情報は、各境界ノードにとって、カスケードＮＷ方向のノードの並びを示す情報である。対向ノード情報を保持することによって、境界ノードにおいても、カスケードＮＷとは逆の方向の並びを認識することができ、疑似的なリング型トポロジを形成することができる。
　図６Ｂは、カスケードＮＷの障害発生時の通信システムの概要を説明するための図である。図６Ｂでは、リング装置＃１とリング装置＃１との、自ノード情報と対向ノード情報とが示される。例えば、カスケードＮＷ内のリング装置＃２とリング装置＃３との間の伝送路に障害が発生した場合には、ＲＰＲの機能により、リング装置＃２とリング装置＃３とによってカスケードＮＷ内に障害通知が行われる。これによって、境界ノードであるリング装置＃１の自ノード情報から、リング装置＃１から見て障害発生箇所よりも先に位置するリング装置＃３、＃４、＃５の情報が削除される。また、もう１つの境界ノードであるリング装置＃５の自ノード情報からは、リング装置＃５から見て障害発生箇所よりも先に位置するリング装置＃１、＃２の情報が削除される。各境界ノードは自ノード情報のコピーを送信するので、各境界ノードの対向ノード情報も更新される。すなわち、リング装置＃１の対向ノード情報は、リング装置＃５の自ノード情報と同一であり、リング装置＃３、＃４、＃５が存在する情報となる。リング装置＃５の対向ノード情報は、リング装置＃１の自ノード情報と同一であり、リング装置＃１、＃２が存在する情報となる。これによって、境界ノードにおいて、自ノード情報に存在しないノードが対向ノード情報に存在することになり、障害発生時においても、境界ノードは通信システム内の全ノードの情報を認識可能になる。
　例えば、カスケードＮＷに障害が発生している図６Ｂにおいて、境界ノードであるリング装置＃１からリング装置＃３にフレームが送信される場合には、リング装置＃３は、リング装置＃１の自ノード情報には存在しないが、対向ノード情報には存在する。リング装置＃１は、対向ノード情報に存在するノードは迂回ＮＷ方向に存在すると認識するため、リング装置＃３宛てのフレームを迂回ＮＷに送信する。一方、図６Ｂにおいて、リング装置＃１がリング装置＃２にフレームを送信する場合には、リング装置＃２は、リング装置＃１の自ノード情報に存在する。リング装置＃１は、自ノード情報に存在するノードはカスケードＮＷ方向に存在すると認識するため、リング装置＃２宛てのフレームをカスケードＮＷに送信する。
　以上より、境界ノードであるリング装置にとって、自ノード情報は、カスケードＮＷ経由でフレームを送信する宛先ノードの情報である。また、境界ノードにとって、対向ノード情報は、カスケードＮＷ内の障害発生時において迂回ＮＷ経由でフレームを送信する宛先ノードの情報である。したがって、境界ノードが、迂回ＮＷにおいて対向するノードの自ノード情報のコピーである対向ノード情報を有することによって、疑似的なリング型トポロジを形成し、カスケードＮＷの障害発生時には、高速に迂回ＮＷに切り替えることができる。
　図７Ａは、第１実施形態に係る通信システムにおけるフレーム変換の概要を説明するための図である。図７Ａに示される通信システムは、図６Ａと同様の通信システムである。カスケードＮＷの障害発生時、迂回ＮＷを使用する場合には、境界ノードは、ＲＰＲフレームのヘッダに含まれる宛先ノード情報をＶＬＡＮタグに格納し、このＶＬＡＮタグをイーサネットフレームの所定の位置に挿入する。また、迂回ＮＷからこのイーサネットフレームを受信した場合、境界ノードは、受信したイーサネットフレームのＶＬＡＮタグから宛先ノード情報を抽出し、ＶＬＡＮタグを取り外して、ＲＰＲヘッダを付与する。
　図７Ｂは、第１実施形態に係る通信システムにおけるフレームの変換による変遷の例を示す図である。図７Ｂでは、図７Ａに示される通信システムにおいて、リング装置＃２の配下のＮＷ（イーサネット）の端末から送信されたフレームが、リング装置＃２，リング装置＃１，迂回ネットワーク，リング装置＃５，リング装置＃４，リング装置＃４の配下のＮＷ（イーサネット）の端末という経路をたどる場合の例が示される。
　リング装置＃２の配下のＮＷ（イーサネット）の端末から送信されるフレームＦＲ１は、通常のイーサネットフレームである。このフレームＦＲ１は、リング装置＃２によって、ＲＰＲヘッダが付与され、ＲＰＲフレームＦＲ２にカプセル化される。図７ＢのＲＰＲフレームＦＲ２では、ＲＰＲヘッダの一部が抜粋して示されている。なお、図７Ｂに示される例では、イーサネットフレームＦＲ１（オリジナルフレーム）の宛先は、リング装置＃４の配下のＮＷの端末であるので、ＲＰＲヘッダ内の宛先ノードＩＤは、リング装置＃４となる。なお、各リング装置は、ＲＰＲの機能により、各リング装置のノードＩＤと、各リング装置の配下に存在するＮＷとを認識しているため、自身の配下のＮＷから受信したイーサネットフレームの宛先ＮＷから、ＲＰＲの宛先ノードを取得することができる。ＲＰＲフレームＦＲ２は、リング装置＃２によってリング装置＃１へ送信される。
　フレームＦＲ２は、境界ノードであるリング装置＃１に到着すると、リング装置＃１によって、ＶＬＡＮタグを含むイーサネットフレームＦＲ３に変換される。図７ＢのフレームＦＲ３では、第１実施形態におけるＶＬＡＮタグのフォーマットが示される。通常、ＩＥＥＥ８０２．１ＱのＶＬＡＮタグは、ＴＹＰＥフィールド１６ビット，ＣＦＩフィールド１ビット，優先度フィールド３ビット，ＶＬＡＮ　ＩＤフィールド１２ビットのフィールドを有する。第１実施形態では、通常はＶＬＡＮ　ＩＤが格納されるフィールドのうち８ビットがノードＩＤを格納するフィールド（図中、フレームＦＲ３のＮｏｄｅ　ＩＤ）として用いられる。また、通常はＶＬＡＮ　ＩＤフィールドとして用いられるフィールドの残りの４ビットは、将来の利用の為の予約フィールド（図中、フレームＦＲ３のＲＳＶフィールド）とされる。なお、ＴＹＰＥフィールドには、通常はＩＥＥＥ８０２．１Ｑによるタグ付きフレームであることを示す値（０ｘ８１００）が格納されるが、第１実施形態では、ＲＰＲフレームを変換したフレームであることを示す所定の値が格納される。
　なお、ＲＰＲフレームのフォーマット規定では、宛先ノードＩＤ及び送信元ノードＩＤのフィールド（図中、フレームＦＲ２のＤＡ，ＳＡ）は６バイト用意されている。しかしながら、ＲＰＲでは最大ノード数が２５５台と規定されているため、実質的にノードＩＤとして用いられているのは８ビット（＝２５６）であり、ＲＰＲフレームにおいても宛先ノードＩＤ及び送信元ノードＩＤで用いられるのは下位８ビットであることが多い。そのため、第１実施形態では、ＲＰＲヘッダ内の宛先ノードＩＤフィールド（６バイト）に格納されている値のうち下位８ビットを宛先ノードＩＤとしてＶＬＡＮタグに格納する。ただし、これに限られず、宛先ノードＩＤが下位８ビット以上用いられている場合には、例えば、ＶＬＡＮタグ内のノードＩＤフィールドのサイズを変更して用いればよい（最大１２ビット）。
　リング装置＃１は、カスケードＮＷから受信したＲＰＲフレームＦＲ２のヘッダの宛先ノードＩＤフィールド（図中、フレームＦＲ２のＤＡ）から宛先ノードＩＤ（６バイト）を抽出する。次に、リング装置＃１は、フレームＦＲ２のＲＰＲヘッダを削除し、ＶＬＡＮタグをイーサネットフレームのＩＥＥＥ８０２．１Ｑにおいて規定される位置に挿入する。ＶＬＡＮタグのノードＩＤフィールドには、ＲＲＰフレームＦＲ２から抽出された宛先ノードＩＤの下位８ビットが格納される。これによってＲＰＲフレームＦＲ２がイーサネットフレームＦＲ３に変換される。リング装置＃１は、このフレームＦＲ３を迂回ＮＷに送信する。なお、フレームＦＲ３のイーサネットヘッダの宛先ＭＡＣアドレスは、対向ノードであるリング装置＃５のＭＡＣアドレスである。対向ノードのＭＡＣアドレスやＩＰアドレス等の情報は事前に境界ノードに設定される。
　フレームＦＲ３は、リング装置＃１から迂回ＮＷを経由してもう一方の境界ノードであるリング装置＃５に到着する。リング装置＃５では、リング装置＃１と逆の処理が行われ、フレームＦＲ３は、ＲＰＲフレームＦＲ４に変換される。具体的には、リング装置＃５は、フレームＦＲ３のＶＬＡＮタグのノードＩＤフィールドから宛先ノードＩＤの下位８ビットを抽出し、これにパディング４０ビットを追加して宛先ノードＩＤを取得する。リング装置＃５は、フレームＦＲ３のイーサネットヘッダからＶＬＡＮタグを削除し、ＲＰＲヘッダを付与して、取得した宛先ノードＩＤをＲＰＲヘッダの宛先ノードＩＤフィールドに格納する。これによって、イーサネットフレームＦＲ３は、ＲＰＲフレームＦＲ４に変換される。フレームＦＲ４の宛先ノードは、リング装置＃４であるので、リング装置＃５は、フレームＦＲ４をカスケードＮＷに送信する。
　フレームＦＲ４は、リング装置＃４に到着すると、リング装置＃４によってＲＰＲヘッダが削除され、オリジナルフレームであるイーサネットフレームＦＲ５になる。その後、宛先端末が存在するリング装置＃４の配下のＮＷに送信される。
　なお、境界ノードであるリング装置＃１及びリング装置＃５において実行されるＲＰＲフレームとイーサネットフレームとのフレーム変換によって、ＲＰＲフレームの送信元ノード情報は書き換えられてしまう。例えば、図７ＢのフレームＦＲ２の送信元ノードＩＤ（図中、ＳＡ、６バイト）はリング装置＃２であり、フレームＦＲ４の送信元ノードＩＤはリング装置＃５である。このように、第１実施形態では、迂回ＮＷを用いてフレームが転送された場合に、転送途中でＲＰＲフレームの送信元ノードが変更される。ただし、これによって、端末間の通信に影響は及ぼされないため、特に問題にはならない。
　図７Ａ及び図７Ｂで示されるように、第１実施形態では、ＩＥＥＥ８０２．１ＱのＶＬＡＮタグを用いて、ＲＰＲネットワークのノード情報をイーサネットフレームに付与する。これによって、迂回ＮＷとしてイーサネットワークを使用する場合にも、通常のイーサネットと比較して増加するサイズが４バイトに抑えられるので、迂回ＮＷの転送能力の低下を抑えることができる。
　なお、第１実施形態では、図７Ａ及び図７Ｂで説明されるように、カスケードＮＷ内の障害発生時には、各リング装置によってブロードキャストで送信されるＲＰＲの制御フレームも迂回ＮＷを流れる。これによって、例えば、図７Ａの境界ノードではないリング装置＃２は、迂回ＮＷを経由してリング装置＃１側からリング装置＃３－＃５の情報（制御フレーム）を取得できる。リング装置＃１側のインタフェースに対応する自ノード情報にリング装置＃３－＃５が存在するようになり、リング装置＃２は、リング装置＃１が位置する方向にリング装置＃３－＃５が存在することを認識する。したがって、リング装置＃２は、リング装置＃３－＃５にフレームを送信する際には、リング装置＃１が存在する方向にフレームを送信する。以上より、カスケードＮＷ内に障害が発生した場合でも、境界ノードではないリング装置は、障害発生の伝送路の先に存在するリング装置と迂回ＮＷを経由して通信を行うことができる。
　＜境界ノードの構成＞
　図８は、リング装置１のハードウェア構成の一例を示す図である。図８に示されるリング装置１は、境界ノードとなるリング装置である。リング装置１は、例えば、ルータ，スイッチ等の通信装置である。リング装置１は、「通信装置」の一例である。リング装置１は、制御カード１００，ＩＦカード１１０ａ，ＩＦカード１１０ｂ，ＳＷカード１２０を備える。
　ＩＦカード１１０ａは、ＲＰＲネットワークとのインタフェース１１１を備え、ＲＰＲネットワークへ送信またはＲＰＲネットワークから受信されるデータの物理層及びデータリンク層の処理を行う。ＩＦカード１１０ｂは、イーサネットワークとのインタフェースであるＬＡＮ　ＩＦ　１１２と迂回ＩＦ　１１３を備え、イーサネットワークへ送信又はイーサネットワークから受信されるデータの物理層及びデータリンク層の処理を行う。ＬＡＮ　ＩＦ　１１２は、リング装置１の配下のイーサネットワークと接続するインタフェースである。迂回ＩＦ　１１３は、迂回ＮＷ（イーサネットワーク）と接続するインタフェースである。ＳＷカード１２０は、ＩＦカード間のデータの中継を行う。
　制御カード１００は、ＩＦカード１１０ａ，ＩＦカード１１０ｂ，ＳＷカード１２０を制御する。また、制御カード１００は、コントロールプレーンとして動作し、ソフトウェア処理を実行する。制御カード１００は、プロセッサ１０１，揮発性メモリ１０２，不揮発性メモリ１０３を備える。
　プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＮＰＵ（Network Processing Unit）である。プロセッサ１０１は、不揮発性メモリ１０３に格納されるプログラムを揮発性メモリ１０２にロードして実行し、様々な処理を実行する。また、プロセッサ１０１は、１つに限られず、複数備えられてもよい。
　揮発性メモリ１０２は、プロセッサ１０１に、不揮発性メモリ１０３に格納されているプログラムをロードする記憶領域および作業領域を提供したり、バッファとして用いられたりする。例えば、揮発性メモリ１０２は、ＳＲＡＭ(Static Random Access Memory)やＤＲＡＭ(Dynamic Random Access Memory)等のような半導体メモリである。
　不揮発性メモリ１０３は、様々なプログラムや、各プログラムの実行に際してプロセッサ１０１が使用するデータを格納する。補助記憶装置１０５は、例えば、ＰＲＯＭ(Programmable Read Only Memory)等の不揮発性のメモリと、が含まれる。なお、リング装置１のハードウェア構成は、上記に限られず、実施の形態に応じて適宜構成要素の省略や置換、追加が可能である。
　図９は、リング装置１の機能ブロックの一例を示す図である。リング装置１は、プロセッサ１０１が不揮発性メモリ１０３に格納された通信プログラムを実行することによって、ＲＰＲ処理部１１，迂回ＮＷ処理部１２，ＬＡＮ処理部１３，宛先ノード判定部１４，ノードリスト管理部１５として動作する。また、プロセッサ１０１の通信プログラムの実行を通じて、揮発性メモリ１０２の記憶領域にノードリストデータベース１６（図中、ノードリストＤＢ）が作成される。ただし、これに限られず、各機能ブロックは、ＦＰＧＡ（Field-Programmable Gate Array），ＡＳＩＣ（Application Specific Integrated Circuit），ＬＳＩ（Large Scale Integration）等の電子回路によってハードウェアで実現されてもよい。
　ＲＰＲ処理部１１は、カスケードＮＷ（ＲＰＲ）経由でＲＰＲ　ＩＦ　１１１で送受信されるＲＰＲフレームに係る処理を実行する。まず、ＲＰＲ処理部１１は、ＲＰＲ　ＩＦ　１１１においてＲＰＲフレームが受信された場合、ＲＰＲフレームを解析して、宛先ノードＩＤを抽出する。また、ＲＰＲ処理部１１は、受信フレームからＲＰＲヘッダを削除する。次に、ＲＰＲ処理部１１は、抽出した宛先ノードＩＤのノードリストＤＢ　１６での存在の有無を宛先ノード判定部１４に問い合わせる。また、ＲＰＲフレームの送信の場合には、ＲＰＲ処理部１１は、宛先ノード判定部１４から宛先ノードＩＤを取得し、フレームにＲＰＲヘッダを付与してＲＰＲ　ＩＦ　１１１からＲＰＲフレームを送信する。ＲＰＲ処理部１１は、「第２のフレーム送信部」の一例である。
　迂回ＮＷ処理部１２は、カスケードＮＷ（ＲＰＲ）の障害発生時に動作し、迂回ＮＷ（イーサネット）経由で迂回ＩＦ　１１３で送受信されるイーサネットフレームに係る処理を実行する。迂回ＩＦ　１１３で送受信されるイーサネットフレームにはＶＬＡＮタグが付与されている（図７Ｂ、フレームＦＲ３参照）。したがって、迂回ＩＦ　１１３でイーサネットフレームが受信された場合には、迂回ＮＷ処理部１２は、ＶＬＡＮタグを解析し、ノードＩＤを抽出する。また、迂回ＮＷ処理部１２は、受信フレームからＶＬＡＮタグを削除する。迂回ＮＷ処理部１２は、抽出したノードＩＤのノードリストＤＢ　１６での存在の有無を宛先ノード判定部１４に問い合わせる。また、迂回ＩＦ　１１３からイーサネットフレームが送信される場合には、迂回ＮＷ処理部１２は、宛先ノード判定部１４から宛先ノードＩＤを取得し、ＶＬＡＮタグにノードＩＤを格納する。迂回ＮＷ処理部１２は、このＶＬＡＮタグをヘッダの所定の位置に挿入してイーサネットフレームを生成し、迂回ＩＦ　１１３からイーサネットフレームを送信する。迂回ＮＷ処理部１２は、「フレーム送信部」の一例である。
　ＬＡＮ処理部１３は、リング装置１の配下のＮＷ（イーサネット）経由でＬＡＮ　ＩＦ　１１２で送受信されるイーサネットフレームに係る処理を実行する。ＬＡＮ　ＩＦ　１１２でイーサネットフレームが受信された場合には、ＬＡＮ処理部１３は、受信されたイーサネットフレームを解析し、イーサネットフレームの宛先ＮＷを配下に有する宛先ノードを取得する。なお、各リング装置のノードＩＤとその配下のＮＷとの対応付けは、例えば、ＲＰＲの機能により取得され、揮発性メモリ１０２に格納されている。ＬＡＮ処理部１３は、取得した宛先ノードのノードリストＤＢ　１６での存在の有無を宛先ノード判定部１４に問い合わせる。また、リング装置１の配下のネットワークにフレームが送信される場合には、ＬＡＮ処理部１３は、ＬＡＮ　ＩＦ　１１２からフレーム送信する。
　宛先ノード判定部１４は、ＲＰＲ処理部１１，迂回ＮＷ処理部１２，ＬＡＮ処理部１３からの宛先ノードのノードリストＤＢ　１６での存在の有無の問い合わせを受けると、ノードリストＤＢ１６を検索する。カスケードＮＷ（ＲＲＰネットワーク）が正常な場合には、宛先ノード判定部１４は、自ノード情報１６１について宛先ノードを検索する。カスケードＮＷ（ＲＰＲネットワーク）の障害発生時には、宛先ノード判定部１４は、自ノード情報１６１と対向ノード情報１６２とについて宛先ノードを検索する。
　宛先ノード判定部１４は、自ノード情報１６１に宛先ノードが存在する場合には、ＲＰＲ　ＩＦ　１１１からのフレームの送信を判定する。したがって、この場合には、宛先ノード判定部１４は、ＲＰＲ処理部１１にフレームの送信を指示し、宛先ノードを通知する。
　宛先ノード判定部１４は、カスケードＮＷに障害発生時、対向ノード情報１６２に宛先ノードが存在する場合には、迂回ＩＦ　１１３からのフレームの送信を判定する。この場合には、宛先ノード判定部１４は、迂回ＮＷ処理部１２にフレームの送信を指示し、宛先ノードを通知する。
　宛先ノード判定部１４は、宛先ノードが自装置である場合には、ＬＡＮ　ＩＦ　１１２からのフレームの送信を判定する。この場合には、宛先ノード判定部１４は、ＬＡＮ処理部１３にフレームの送信を指示する。
　宛先ノード判定部１４は、宛先ノードがノードリストＤＢ　１６に存在しない場合には、該当フレームの廃棄を判定し、フレームを廃棄する。宛先ノード判定部１４は、「判定部」の一例である。
　ノードリスト管理部１５は、ノードリストＤＢ　１６に格納される自ノード情報１６１と対向ノード情報１６２とを管理する。ノードリスト管理部１５は、ＲＰＲの制御フレームによって自ノード情報にはない情報が通知された場合やＲＰＲの制御フレームの受信状況に応じて、自ノード情報１６１を更新する。例えば、新たに追加されたリング装置からの制御フレームが受信された場合には、ノードリスト管理部１５は、該リング装置の情報を自ノード情報に追加する。また、例えば、所定期間以上、制御フレームが受信されないリング装置については、ノードリスト管理部１５は、自ノード情報から削除する。また、例えば、障害発生通知を受信した後の所定期間（上記所定期間より短い期間）内に制御フレームが受信されないリング装置については、ノードリスト管理部１５は、自ノード情報から削除する。ノードリスト管理部１５は、所定周期で対向ノードから受信される対向ノードの自ノード情報のコピーで、対向ノード情報を更新する。なお、第１実施形態では、障害発生時、各リング装置から送信されるＲＰＲの制御フレームも迂回ＮＷを流れるが、ノードリスト管理部１５は、迂回ＮＷを通じて（迂回ＩＦ　１１３で）受信されたＲＰＲの制御フレームについては処理を行わない。そのため、迂回ＮＷから（迂回ＩＦ　１１３で）受信したＲＰＲの制御フレームでは、ノードリスト管理部１５は自ノード情報を更新しない。
　また、ノードリスト管理部１５は、所定周期で自ノード情報１６１のコピーを対向ノードに送信する。この自ノード情報１６１のコピーは、カスケードネットワークの障害の有無にかかわらず、迂回ＩＦ　１１３から送信され、迂回ＮＷを経由して送信される。この自ノード情報１６１のコピーは、対向ノードにおいて、対向ノード情報として取り扱われる。尚、対向ノードのＩＰアドレスやＭＡＣアドレス等は、事前にリング装置１に設定される。また、所定周期は、例えば、３－１０ｍｓである。ノードリスト管理部１５は、「受信部」の一例である。また、ノードリスト管理部１５は、「送信部」の一例である。
　ノードリストＤＢ　１６は、リング装置１が認識しているＲＰＲネットワークに存在するノードの情報を格納するデータベースである。ノードリストＤＢ　１６は、自ノード情報１６１と対向ノード情報１６２とを格納する。ノードリストＤＢ　１６は、「格納部」の一例である。
　自ノード情報１６１は、ＲＰＲ　ＩＦ　１１１からフレームを送信する宛先ノードの情報が格納されている。具体的には、例えば、図６Ａで示されるように、自ノード情報１６１は、リング装置１からのホップ数とノードＩＤとの対応付けである。自ノード情報１６１は、例えば、ＲＰＲ　ＩＦ　１１１と対応付けられている。自ノード情報１６１は、「第１のリスト」の一例である。
　対向ノード情報１６２は、対向ノードの自ノード情報のコピーである。対向ノード情報１６２は、カスケードＮＷ（ＲＰＲネットワーク）に障害発生時に用いられ、迂回ＩＦ　１１３からフレームを送信する宛先ノードの情報が格納されている。対向ノード情報１６２は、例えば、迂回ＩＦ　１１３と対応付けられている。対向ノード情報１６２は、「第２のリスト」の一例である。
　＜自ノード情報の管理の動作例＞
　図１０は、自ノード情報の管理に係る処理のフローチャートの一例である。図１０に示されるフローチャートは、リング装置１の起動中、繰り返し実行される。
　ＯＰ１では、プロセッサ１０１は、自ノード情報１６１の更新の有無を判定する。自ノード情報の更新の有無は、例えば、制御フレームの内容、制御フレームの受信状況から判定される。ただし、制御フレームはＲＰＲネットワークから（ＲＰＲ　ＩＦ　１１１で）受信されたものである。自ノード情報１６１に更新がある場合には（ＯＰ１：Ｙｅｓ）、処理がＯＰ２に進む。自ノード情報１６１に更新がない場合には（ＯＰ１：Ｎｏ）、処理がＯＰ３に進む。
　ＯＰ２では、プロセッサ１０１は、自ノード情報１６１を更新する。次に処理がＯＰ３に進む。
　ＯＰ３では、プロセッサ１０１は、自ノード情報１６１のコピーの送信タイミングであるか否かを判定する。自ノード情報のコピーの送信タイミングである場合には（ＯＰ３：Ｙｅｓ）、処理がＯＰ４に進む。自ノード情報のコピーの送信タイミングではない場合には（ＯＰ３：Ｎｏ）、図１０に示される処理が終了し、繰り返し実行される。自ノード情報１６１のコピーの送信タイミングは、例えば、３ｍｓ－１０ｍｓ間隔である。
　ＯＰ４では、プロセッサ１０１は、自ノード情報１６１のコピーの送信タイミングであるので、ノードリストＤＢ　１６に格納されている自ノード情報１６１のコピーを迂回ＩＦ　１１３から対向ノードに宛てて送信する。その後、図１０に示される処理が終了し、繰り返し実行される。
　ＯＰ１－ＯＰ４の処理は、ノードリスト管理部１５の処理の一部に相当する。また、ＯＰ４の自ノード情報１６１のコピーの迂回ＩＦ　１１３からの送信は、迂回ＮＷ処理部１２の処理の一部に相当する。
　＜カスケードＮＷの障害発生時のフレーム転送処理＞
　図１１，図１２，図１３は、それぞれ、カスケードＮＷ（ＲＰＲネットワーク）の障害発生時のフレーム転送処理のフローチャートの一例である。
　図１１は、カスケードＮＷの障害発生時に、ＲＰＲ　ＩＦ　１１１においてフレームが受信された場合のフレーム転送処理のフローチャートの一例である。図１１に示されるフローチャートは、カスケードＮＷの障害発生時にＲＰＲ　ＩＦ　１１１においてフレームが受信された場合に開始される。
　ＯＰ１１では、プロセッサ１０１は、ＲＰＲフレームを解析し、ＲＰＲヘッダから宛先ノードＩＤを抽出する。また、プロセッサ１０１は、受信したフレームからＲＰＲヘッダを削除する。次に処理がＯＰ１２に進む。
　ＯＰ１２では、プロセッサ１０１は、抽出した宛先ノードＩＤの自ノード情報１６１内の存在の有無を判定する。宛先ノードＩＤが自ノード情報１６１に存在する場合には（ＯＰ１２：Ｙｅｓ）、処理がＯＰ１３に進む。宛先ノードＩＤが自ノード情報１６１に存在しない場合には（ＯＰ１２：Ｎｏ）、処理がＯＰ１６に進む。
　ＯＰ１３では、プロセッサ１０１は、宛先ノードＩＤは自ノードのノードＩＤを示すか否かを判定する。例えば、自ノードは、自ノード情報１６１においてホップ数０で登録されている。宛先ノードＩＤが自ノードのノードＩＤである場合には（ＯＰ１３：Ｙｅｓ）、プロセッサ１０１はＬＡＮ　ＩＦ　１１２からフレームを送信することを判定し、処理がＯＰ１４に進む。宛先ノードＩＤが自ノードのノードＩＤではない場合には（ＯＰ１３：Ｎｏ）、宛先ノードＩＤは自ノード情報１６１に存在する他のリング装置のノードＩＤであることが示される。しかしながら、この場合には、ＲＰＲ　ＩＦ　１１１において受信したフレームを再度ＲＰＲ　ＩＦ　１１１に送信することになるため、処理がＯＰ１５に進み、フレームは廃棄される。
　ＯＰ１４では、プロセッサ１０１は、ＬＡＮ　ＩＦ　１１２からフレームを送信する。その後、図１１に示される処理が終了する。
　ＯＰ１６では、プロセッサ１０１は、ＯＰ１１で抽出した宛先ノードＩＤの対向ノード情報１６２内の存在の有無を判定する。宛先ノードＩＤが対向ノード情報１６２に存在する場合には（ＯＰ１６：Ｙｅｓ）、プロセッサ１０１は、対向ノード情報１６２に宛先ＩＤが存在したので、迂回ＩＦ　１１３からフレームを送信することを判定し、処理がＯＰ１７に進む。宛先ノードＩＤが対向ノード情報１６２に存在しない場合には（ＯＰ１６：Ｎｏ）、自ノード情報１６１と対向ノード情報１６２とのいずれにも宛先ノードＩＤが存在しないので、処理がＯＰ１５に進み、プロセッサ１０１はフレームを廃棄する。
　ＯＰ１７では、プロセッサ１０１は、宛先ノードＩＤの下位８ビットをＶＬＡＮタグに格納し、このＶＬＡＮタグを受信フレームのイーサネットヘッダに挿入する。次に、処理がＯＰ１８に進み、プロセッサ１０１は、迂回ＩＦ　１１３からフレームを送信する。その後、図１１に示される処理が終了する。
　ＯＰ１１の処理は、ＲＰＲ処理部１１の処理の一部に相当する。ＯＰ１２，ＯＰ１３，ＯＰ１５，ＯＰ１６の処理は、宛先ノード判定部１４の処理の一部に相当する。ＯＰ１４の処理は、ＬＡＮ処理部１３の処理の一部に相当する。ＯＰ１７，ＯＰ１８の処理は、迂回ＮＷ処理部１２の処理の一部に相当する。
　図１２は、カスケードＮＷの障害発生時に、迂回ＩＦ　１１３においてフレームが受信された場合のフレーム転送処理のフローチャートの一例である。図１２に示されるフローチャートは、カスケードＮＷの障害発生時に迂回ＩＦ　１１３において、フレームが受信された場合に開始される。なお、迂回ＩＦ　１１３において受信されるフレームは、ＶＬＡＮタグを有するイーサネットフレームである。
　ＯＰ２１では、プロセッサ１０１は、イーサネットフレームを解析し、ＶＬＡＮタグからノードＩＤ８ビットを抽出する。また、プロセッサ１０１は、イーサネットフレームからＶＬＡＮタグを削除する。次に処理がＯＰ２２に進む。
　ＯＰ２２では、プロセッサ１０１は、抽出したノードＩＤの自ノード情報１６１内の存在の有無を判定する。抽出したノードＩＤが自ノード情報１６１に存在する場合には（ＯＰ２２：Ｙｅｓ）、処理がＯＰ２３に進む。宛先ノードＩＤが自ノード情報１６１に存在しない場合には（ＯＰ２２：Ｎｏ）、処理がＯＰ２７に進む。
　ＯＰ２３では、プロセッサ１０１は、抽出したノードＩＤは自ノードのノードＩＤを示すか否かを判定する。抽出したノードＩＤが自ノードのノードＩＤである場合には（ＯＰ２３：Ｙｅｓ）、プロセッサ１０１はＬＡＮ　ＩＦ　１１２からフレームを送信することを判定し、処理がＯＰ２４に進む。抽出したノードＩＤが自ノードのノードＩＤではない場合には（ＯＰ２３：Ｎｏ）、プロセッサ１０１はＲＰＲ　ＩＦ　１１１からフレームを送信することを判定し、処理がＯＰ２５に進む。
　ＯＰ２４では、プロセッサ１０１は、ＬＡＮ　ＩＦ　１１２からフレームを送信する。その後、図１２に示される処理が終了する。
　ＯＰ２５では、プロセッサ１０１は、ＯＰ２１で抽出したノードＩＤにパディングしてＲＰＲヘッダの宛先ノードＩＤのフィールドに格納し、ＲＰＲヘッダを付与してＲＰＲフレームを生成する（図７Ｂ、フレームＦＲ４参照）。次に処理がＯＰ２６に進み、プロセッサ１０１はＲＰＲフレームをＲＰＲ　ＩＦ　１１１からＲＰＲネットワークに送信する。その後、図１２に示される処理が終了する。
　ＯＰ２７では、プロセッサ１０１はフレームを廃棄する。迂回ＩＦ　１１３において受信したフレームの宛先ノードが自ノード情報１１６に存在していない場合には、対向ノード情報１６２には存在していたとしても、再度同一フレームを迂回ＮＷに送信することになるため、フレームは廃棄される。その後、図１２に示される処理が終了する。
　ＯＰ２１の処理は、迂回ＮＷ処理部１２の処理の一部に相当する。ＯＰ２２，ＯＰ２３，ＯＰ２７の処理は、宛先ノード判定部１４の処理の一部に相当する。ＯＰ２４の処理は、ＬＡＮ処理部１３の処理の一部に相当する。ＯＰ２５，ＯＰ２６の処理は、ＲＰＲ処理部１１の処理の一部に相当する。
　図１３は、カスケードＮＷの障害発生時に、ＬＡＮ　ＩＦ　１１２においてフレームが受信された場合のフレーム転送処理のフローチャートの一例である。図１３に示されるフローチャートは、カスケードＮＷの障害発生時にＬＡＮ　ＩＦ　１１２においてフレームが受信された場合に開始される。
　ＯＰ３１では、プロセッサ１０１は、受信したイーサネットフレームの宛先ＮＷを配下に有する宛先ノードＩＤを取得し、宛先ノードＩＤの自ノード情報１６１内の存在の有無を判定する。宛先ノードＩＤが自ノード情報１６１に存在する場合には（ＯＰ３１：Ｙｅｓ）、処理がＯＰ３２に進む。宛先ノードＩＤが自ノード情報１６１に存在しない場合には（ＯＰ３１：Ｎｏ）、処理がＯＰ３６に進む。
　ＯＰ３２では、プロセッサ１０１は、宛先ノードＩＤは自ノードのノードＩＤを示すか否かを判定する。宛先ノードＩＤが自ノードのノードＩＤである場合には（ＯＰ３２：Ｙｅｓ）、ＬＡＮ　ＩＦ　１１２から再度同一フレームを送信することになるため、処理がＯＰ３５に進み、プロセッサ１０１はフレームを廃棄する。宛先ノードＩＤが自ノードのノードＩＤではない場合には（ＯＰ３２：Ｎｏ）、プロセッサ１０１はＲＰＲ　ＩＦ　１１１からフレームを送信することを判定し、処理がＯＰ３３に進む。
　ＯＰ３３では、プロセッサ１０１は、宛先ノードＩＤをＲＰＲヘッダの宛先ノードＩＤフィールドに格納し、ＲＰＲヘッダを付与してＲＰＲフレームを生成する（図７Ｂ、フレームＦＲ１、ＦＲ２参照）。次に処理がＯＰ３４に進み、プロセッサ１０１はＲＰＲフレームをＲＰＲ　ＩＦ　１１１からＲＰＲネットワークに送信する。その後、図１３に示される処理が終了する。
　ＯＰ３６では、プロセッサ１０１は、宛先ノードＩＤの対向ノード情報１６２内の存在の有無を判定する。宛先ノードＩＤが対向ノード情報１６２に存在する場合には（ＯＰ３６：Ｙｅｓ）、プロセッサ１０１は、対向ノード情報１６２に宛先ノードＩＤが存在したので、迂回ＩＦ　１１３からフレームを送信することを判定し、処理がＯＰ３７に進む。宛先ノードＩＤが対向ノード情報１６２に存在しない場合には（ＯＰ３６：Ｎｏ）、自ノード情報１６１と対向ノード情報１６２とのいずれにも宛先ノードＩＤが存在しないので、処理がＯＰ３５に進み、プロセッサ１０１はフレームを廃棄する。
　ＯＰ３７では、プロセッサ１０１は、宛先ノードＩＤの下位８ビットをＶＬＡＮタグに格納し、このＶＬＡＮタグをイーサネットヘッダの所定の位置に挿入する。次に、処理がＯＰ３８に進み、プロセッサ１０１は、迂回ＩＦ　１１３からフレームを送信する。その後、図１３に示される処理が終了する。
　ＯＰ３１の宛先ノードＩＤを取得する処理は、ＬＡＮ処理部１３の処理の一部に相当する。ＯＰ３１，ＯＰ３２，ＯＰ３５，ＯＰ３６の処理は、宛先ノード判定部１４の処理の一部に相当する。ＯＰ３３、ＯＰ３４の処理は、ＲＰＲ処理部１１の処理の一部に相当する。ＯＰ３７，ＯＰ３８は、迂回ＮＷ処理部１２の処理の一部に相当する。
　なお、図１０－図１３では、図９に示される機能ブロックが、プロセッサ１０１による通信プログラムに実行によって実現される場合を想定して説明した。ただし、これに限られず、図９に示される機能ブロックが、ハードウェアで実現される場合には、各処理は、それぞれ対応するハードウェアによって実現される。
　図１１－図１３では、障害発生時の処理について説明したが、カスケードＮＷが障害から復旧した場合には、通常の処理に戻る。すなわち、宛先ノードの検索に対向ノード情報は用いられない。障害復旧の検知は、例えば、カスケードＮＷから制御フレームを受信し自ノード情報が更新されることによって検知可能である。例えば、自ノード情報と対向ノード情報とに存在するノードが一致した場合に、カスケードＮＷの復旧を判定してもよい。
　＜第１実施形態の作用効果＞
　第１実施形態では、カスケードＮＷの境界ノードとなるリング装置が、対向ノードの自ノード情報（対向ノード情報）を保持する。対向ノード情報は、迂回ＮＷ（イーサネット）経由の宛先ノードの情報を示す。これによって、カスケードＮＷに障害が発生した場合でも、境界ノードはカスケードＮＷ内の各ノードの情報を認識することができる。また、カスケードＮＷに障害が発生した場合に、対向ノード情報に存在する宛先ノードへは迂回ＮＷを利用してフレームを送信することができ、通信の切断を防ぐことができる。また、カスケードＮＷ内の障害発生時には、対向ノード情報を使用すれば迂回ＮＷに切り替わるので、可用性の目安である切替時間（５０ｍｓ以内）を維持することができる。また、リング型トポロジのＲＰＲネットワークでは、リング上の伝送路はすべてＲＰＲであるという制約があるが、第１実施形態によれば、ＲＰＲとは種類の異なるネットワークを用いて疑似的なリングを形成することができる。
　また、第１実施形態では、境界ノードにおいて、ＲＰＲネットワークから迂回ＮＷへフレームを転送する際には、ＲＰＲの宛先情報をＶＬＡＮタグに格納し、このＶＬＡＮタグをイーサネットフレームに挿入する。これによって、ＲＰＲの宛先情報を維持しつつ、フレームを迂回ＮＷに送信することができる。また、通常のイーサネットフレームからはＶＬＡＮタグ４バイトが増えるだけなので、迂回ＮＷの帯域消費を抑えることができる。
　＜第１実施形態の適用例＞
　図１４は、第１実施形態の適用例を示す図である。図１４に示される例は、迂回ＮＷがＲＰＲ１とＲＰＲ２との２つのＲＰＲネットワークで共有される例である。迂回ＮＷにおいて、ＲＰＲ１の境界ノードであるリング装置＃１，＃５とＲＰＲ２の境界ノードであるリング装置＃１１、#１５とがそれぞれレイヤ２スイッチを介して接続される。
　ＲＰＲネットワークが正常時には、迂回ＮＷに流れるフレームは少ない（例えば、対向ノード情報）ため、迂回ＮＷにＲＰＲ１とＲＰＲ２との２つのＲＰＲネットワークの合計帯域を用意しなくてもよく、１つのＲＰＲ分の帯域を用意すればよい。複数のカスケードＮＷで迂回ＮＷを共有することで、帯域を有効に使用することができる。
　＜第２実施形態＞
　第２実施形態では、境界のノードは、迂回ＮＷ（イーサネット）にフレームを転送する際に、カスケードＮＷ（ＲＰＲ）の宛先情報に加えて、イーサネットフレームのヘッダにカスケードＮＷのＱｏＳ情報も格納される。これによって、迂回ＮＷを経由することによるカスケードＮＷのＱｏＳ情報の欠落を防止することができる。第２実施形態では、第１実施形態と共通する説明は省略される。なお、第２実施形態においても、通信システムの構成は、第１実施形態と同様に図６Ａ，図７Ａを想定する。
　図１５は、第２実施形態に係る通信システムにおけるフレームの変換による変遷の例を示す図である。図１５では、図７Ｂと同様に、図７Ａに示される通信システムにおいて、リング装置＃２の配下のＮＷ（イーサネット）の端末から送信されたフレームが、リング装置＃２，リング装置＃１，迂回ネットワーク，リング装置＃５，リング装置＃４，リング装置＃４の配下のＮＷ（イーサネット）の端末という経路をたどる場合の例が示される。
　リング装置＃２の配下のネットワークからリング装置＃２，リング装置＃２からリング装置＃１までのフレームＦＲ１１からフレームＦＲ１２への変遷については、第１実施形態（図７Ｂ）で説明した通りである。
　境界ノードであるリング装置＃１では、迂回ＮＷに転送するために、ＲＰＲフレームＦＲ２をイーサネットフレームＦＲ３へと変換する。第２実施形態では、第１実施形態と同様に、イーサネットフレームにＶＬＡＮタグを挿入する。ただし、第２実施形態では、ＶＬＡＮタグに、宛先ノードＩＤの下位８ビットに加えて、ＲＰＲフレームのヘッダに含まれるＱｏＳ情報が格納される。
　図１５のフレームＦＲ３では、第２実施形態におけるＶＬＡＮタグのフォーマットが示される。第２実施形態では、通常のＶＬＡＮタグでＶＬＡＮ　ＩＤフィールドとして使用される２バイト（１６ビット）のフィールドが、ノードＩＤ（８ビット）、サービスクラス（２ビット）、予約（２ビット）として使用される。ノードＩＤフィールドには、第１実施形態と同様に、ＲＰＲフレームＦＲ２の宛先ノードＩＤフィールド（６バイト）に格納される値のうち下位８ビットが格納される。サービスクラスフィールド（図中、フレームＦＲ３のＳＣ）には、ＲＰＲフレームＦＲ２のコントロールフィールド（図中、フレームＦＲ２のＣＴＲＬ）に格納される値のうち使用されている２ビットが格納される。なお、サービスクラスは、運用上では、３つである場合が多く、ＲＰＲの規定でも最大５クラスである。したがって、ＲＰＲフレームでは、コントロールフィールドに１バイト用意されているが、実際に使用されているのは２ビットであることが多いため、第２実施形態ではＶＬＡＮタグのサービスクラスフィールドに２ビット用意する。ただし、これに限られず、サービスクラスが５つ使用されている場合には、ＶＬＡＮタグのサービスクラスフィールドを３ビット、予約フィールドを１ビットに設定して用いてもよい。
　フレームＦＲ３は、リング装置＃１から送信され、迂回ＮＷを経由してリング装置＃５に到着する。リング装置＃５では、ＲＰＲネットワークに送信するために、イーサネットフレームＦＲ３をＲＰＲフレームＦＲ４に変換する。この場合には、まず、イーサネットフレームＦＲ３のＶＬＡＮタグからノードＩＤとサービスクラスとのフィールドの値が抽出され、フレームＦＲ３からＶＬＡＮタグが削除される。次に、フレームにＲＰＲヘッダが付与され、抽出されたノードＩＤとサービスクラスとの値が、それぞれ、ＲＰＲヘッダの宛先ノードＩＤとコントロールとのフィールドに格納されて、フレームＦＲ４が取得される。このとき、ノードＩＤ及びサービスクラスのそれぞれ不足分のビットはパディングされる。これによってリング装置＃１において、イーサネットフレームＦＲ３はＲＰＲフレームＦＲ４に変換される。
　図１６は、第２実施形態の通信システムの概要を説明するための図である。ＲＰＲでは、リング上の帯域は、全て同一であることが規定されている。しかしながら、迂回ＮＷとしてカスケードＮＷ（ＲＰＲ）の帯域以下の帯域しか用意できない場合がある。迂回ＮＷの帯域がカスケードＮＷの帯域より小さい場合には、カスケードＮＷのＱｏＳ情報をそのまま適用すると、迂回ＮＷにおいてデータの欠落が発生することがある。
　第２実施形態の通信システムでは、ＲＰＲネットワーク内の各リング装置は、ＱｏＳ情報を格納するＱｏＳテーブルを複数保持し、正常時と障害発生時とでＱｏＳテーブルを使い分ける。
　例えば、図１６に示される通信システムにおいて、カスケードＮＷの帯域は１０００Ｍｂｐｓ，迂回ＮＷの帯域は６００Ｍｂｐｓであるとする。各リング装置＃１－＃５は、通常時用のＱｏＳテーブル１と、障害時用のＱｏＳテーブル２とを有する。正常時用のＱｏＳテーブル１には、カスケードＮＷの帯域１０００Ｍｂｐｓに応じた帯域制御の情報が設定されている。障害時用のＱｏＳテーブル２には、迂回ＮＷの帯域６００Ｍｂｐｓ用の帯域制御の情報が設定されている。
　正常時には、各リング装置は通常時用のＱｏＳテーブル１を使用し、１０００Ｍｐｓ用の帯域制御が実行される。正常時には、カスケードＮＷから迂回ＮＷにはフレームはほぼ流れないため、帯域制御の設定がカスケードＮＷの帯域６００Ｍｂｐｓを上回っていてもよい。
　例えば、リング装置＃２とリング装置＃３との間の伝送路で障害が発生した場合には、リング装置＃２とリング装置＃３とによってカスケードＮＷ内に障害通知が行われる。境界ノードであるリング装置＃１及びリング装置＃５は、障害通知を受信すると、カスケードＮＷのリング装置に、ＱｏＳテーブルの切り替えを指示する制御フレームを送信する。ＱｏＳテーブルの切り替えを指示する制御フレームを受信すると、リング装置＃２－＃４は、ＱｏＳテーブル１から障害時用のＱｏＳテーブル２に切り替える。境界ノードであるリング装置＃１及びリング装置＃５は、ＱｏＳテーブルの切り替えを指示する制御フレームの送信により、ＱｏＳテーブル１から障害時用のＱｏＳテーブル２に切り替える。
　これによって、障害発生時には、障害時用のＱｏＳテーブル２が用いられ、迂回ＮＷの帯域に応じた帯域制御が実行される。したがって、障害発生時においても最低限必要なデータ通信を確保することができる。
　また、障害から復旧した際には、境界ノードであるリング装置＃１及びリング装置＃５が障害復旧を検知したタイミングで、ＱｏＳテーブルの切り替えを指示する制御フレームをカスケードＮＷに送信する。各リング装置＃２－＃４は、この制御フレームを受信すると、使用するＱｏＳテーブルを障害時用のＱｏＳテーブル２から正常時用のＱｏＳテーブル１に切り替える。境界ノードであるリング装置＃１及びリング装置＃５は、ＱｏＳテーブルの切り替えを指示する制御フレームの送信によって、使用するＱｏＳテーブルを正常時用のＱｏＳテーブル１に切り替える。
　なお、使用するＱｏＳテーブルを切り替えは、境界ノードからの制御フレームを利用したＱｏＳテーブルの切り替え指示に限られない。例えば、障害発生の検出，障害発生の通知の受信，障害復旧の検出等により、各リング装置＃１－５が自律的に使用するＱｏＳテーブルを切り替えてもよい。
　＜境界ノードの構成＞
　図１７は、第２実施形態における境界ノードであるリング装置１ｂの機能ブロックの一例である。リング装置１ｂのハードウェア構成は、第１実施形態のリング装置１と同様である。リング装置１ｂは、プロセッサ１０１が不揮発性メモリ１０３に格納される通信プログラムを実行することによって、ＲＰＲ処理部１１，迂回ＮＷ処理部１２，ＬＡＮ処理部１３，宛先ノード判定部１４，ノードリスト管理部１５に加え、更にＱｏＳ処理部１７として動作する。また、プロセッサ１０１の通信プログラムのインストール又は実行を通じて、揮発性メモリ１０２の記憶領域にノードリストＤＢ　１６と、正常時用ＱｏＳテーブル１８ａ，障害時用ＱｏＳテーブル１８ｂが作成される。正常時用ＱｏＳテーブル１８ａ，障害時用ＱｏＳテーブル１８ｂは、ユーザ入力によって設定されてもよい。ただし、これに限られず、各機能ブロックは、ＦＰＧＡ，ＡＳＩＣ等の電子回路によってハードウェアで実現されてもよい。
　ＱｏＳ処理部１７は、リング装置１ｂの配下のＮＷから受信し、カスケードＮＷ又は迂回ＮＷへ転送するフレームに対して付与されるＱｏＳ情報を管理する。ＱｏＳ処理部１７は、使用されるＱｏＳテーブルを記憶しており、リング装置１ｂの配下のＮＷからカスケードＮＷ又は迂回ＮＷへフレームが送信される際に、ＬＡＮ処理部１３からの問い合わせに応じて、記憶されているＱｏＳテーブルからＱｏＳ情報を読み出す。読み出されたＱｏＳ情報は、該当フレームの転送先に応じて、ＲＰＲ処理部１１又は迂回ＮＷ処理部１２に通知される。また、ＱｏＳ処理部１７は、障害発生の通知を受信した場合、及び、障害復旧を検出した場合に、カスケードＮＷに（ＲＰＲ　ＩＦ　１１１から）ＱｏＳテーブルの切り替え指示の制御フレームを送信する。また、ＱｏＳ処理部１７は、自身に記憶される使用されるＱｏＳテーブルを正常時用ＱｏＳテーブル１８ａ又は障害時用ＱｏＳテーブル１８ｂに書き換えて、ＱｏＳテーブルを切り替える。なお、障害復旧の検知は、例えば、自ノード情報の更新や、自ノード情報の更新により自ノード情報と対向ノード情報とが有するリング装置が同一になることにより検知される。
　ＲＰＲ処理部１１は、第１実施形態の処理に加えて、以下の処理を実行する。ＲＰＲ処理部１１は、ＲＰＲ　ＩＦ　１１１においてＲＰＲフレームが受信された場合、ＲＰＲフレームを解析して、宛先ノードＩＤとコントロールとのフィールドから値を抽出する。また、ＲＰＲフレームの送信の場合には、ＲＰＲ処理部１１は、宛先ノードＩＤとサービスクラスとを取得し、ＲＰＲヘッダの宛先ノードＩＤとコントロールとのフィールドにそれぞれ値を格納する。宛先ノードＩＤは宛先ノード判定部１４から取得される。サービスクラスは、受信インタフェースに応じてＱｏＳ処理部１７又は迂回ＮＷ処理部１２からの通知によって取得される。ＲＰＲ処理部１１は、フレームにＲＰＲヘッダを付与してＲＰＲ　ＩＦ　１１１からＲＰＲフレームを送信する。
　迂回ＮＷ処理部１２は、第１実施形態の処理に加えて、以下の処理を実行する。迂回ＩＦ　１１３でイーサネットフレームが受信された場合には、迂回ＮＷ処理部１２は、ＶＬＡＮタグを解析し、ノードＩＤとサービスクラスとのフィールドから値を抽出する。また、迂回ＩＦ　１１３からイーサネットフレームが送信される場合には、迂回ＮＷ処理部１２は、宛先ノードＩＤとサービスクラスとを取得し、ＶＬＡＮタグに格納する。宛先ノードＩＤは、宛先ノード判定部１４から取得される。サービスクラスは、ＱｏＳ処理部１７又はＲＰＲ処理部１１からの通知により取得される。迂回ＮＷ処理部１２は、このＶＬＡＮタグをヘッダに含めてイーサネットフレームを生成し、迂回ＩＦ　１１３からイーサネットフレームを送信する。
　ＬＡＮ処理部１３は、第１実施形態の処理に加えて、ＬＡＮ　ＩＦ　１１２でイーサネットフレームが受信された場合には、ＱｏＳ処理部１７にＱｏＳ情報を問い合わせる。
　宛先ノード判定部１４，ノードリスト管理部１５，ノードリストＤＢ　１６については、第１実施形態と同様である。
　正常時用ＱｏＳテーブル１８ａには、カスケードＮＷの帯域に応じた帯域制御の情報が設定されている。障害時用ＱｏＳテーブル１８ｂには、迂回ＮＷの帯域に応じた帯域制御の情報が設定されている。
　＜境界ノード以外のリング装置の構成＞
　図１８は、境界ノードではないリング装置２の機能ブロックの一例を示す図である。リング装置２のハードウェア構成は、境界ノードであるリング装置１ｂと同様であり、図８に示される通りである。リング装置２は、プロセッサ１０１が不揮発性メモリ１０３に格納される通信プログラムを実行することによって、ＲＰＲ処理部２１，ＬＡＮ処理部２３，宛先ノード判定部２４，ノードリスト管理部２５，ＱｏＳ処理部２７として動作する。また、該通信プログラムをインストール又は実行することによって、揮発性メモリ１０２の記憶領域にノードリストＤＢ　２６，正常時用ＱｏＳテーブル２８ａ，障害時用ＱｏＳテーブル２８ｂが作成される。正常時用ＱｏＳテーブル２８ａ，障害時用ＱｏＳテーブル２８ｂは、ユーザ入力によって設定されてもよい。
　ノードリストＤＢ　２６には、自ノード情報２６１が格納される。境界ノードでないリング装置２は、迂回ＮＷには接続されず、迂回ＮＷについては認識しないため、対向ノード情報は有しない。正常時用ＱｏＳテーブル２８ａには、カスケードＮＷの帯域に応じた帯域制御の情報が設定されている。障害時用ＱｏＳテーブル２８ｂには、迂回ＮＷの帯域に応じた帯域制御の情報が設定されている。
　境界ノード以外のリング装置２は、ＲＰＲネットワークと配下のイーサネットワークとに接続しており、迂回ＮＷに係る処理を実行しないこと以外は、境界ノードであるリング装置１ｂとほぼ同様の処理を実行する。ＲＰＲ処理部２１は、ＲＰＲ　ＩＦ　１１１において送受信されるフレームの処理を行う。したがって、ＲＰＲ処理部２１，ＬＡＮ処理部２３の処理は、境界ノードのリング装置１ｂのＲＰＲ処理部１１，ＬＡＮ処理部１３と同様の処理である。宛先ノード判定部２４，ノードリスト管理部２５は、境界ノード以外のリング装置２は対向ノード情報を保持しないので、対向ノードに係る処理を実行しない以外は、境界ノードのリング装置１ｂの宛先ノード判定部１４，ノードリスト管理部１５の処理と同様である。
　ＱｏＳ処理部２７は、リング装置２の配下のＮＷから受信し、カスケードＮＷへ転送するフレームに対して付与されるＱｏＳ情報を管理する。ＱｏＳ処理部２７は、使用されるＱｏＳテーブルを記憶しており、リング装置２の配下のＮＷからカスケードＮＷへフレームが送信される際に、ＬＡＮ処理部２３からの問い合わせに応じて、使用することが記憶されているＱｏＳテーブルからＱｏＳ情報を読み出す。読み出されたＱｏＳ情報は、ＲＰＲ処理部２１に通知される。また、ＱｏＳ処理部２７は、境界ノードであるリング装置１ｂからのＱｏＳテーブルの切り替え指示の制御フレームを受信すると、使用されるＱｏＳテーブルを正常時用ＱｏＳテーブル２８ａ又は障害時用ＱｏＳテーブル２８ｂに書き換えて、ＱｏＳテーブルを切り替える。
　＜境界ノードの動作例＞
　図１９，図２０，図２１は、それぞれ、カスケードＮＷの障害発生時における境界ノードのリング装置１ｂのフレーム転送処理のフローチャートの一例である。
　図１９は、カスケードＮＷの障害発生時に、ＲＰＲ　ＩＦ　１１１においてフレームが受信された場合の境界ノードのリング装置１ｂのフレーム転送処理のフローチャートの一例である。図１９に示されるフローチャートは、カスケードＮＷの障害発生時にＲＰＲ　ＩＦ　１１１においてフレームが受信された場合に開始される。
　図１９に示されるフローチャートにおいて、ＯＰ４２－ＯＰ４６，ＯＰ４８の処理は、図１１に示されるフローチャートのＯＰ１２－ＯＰ１６，ＯＰ１８の処理と同様である。以下、図１１に示されるフローチャートの処理と異なるＯＰ４１，ＯＰ４７の処理について説明する。
　ＯＰ４１では、プロセッサ１０１は、ＲＰＲ　ＩＦ　１１１において受信したＲＰＲフレームを解析し、ＲＰＲヘッダの宛先ノードＩＤフィールドとコントロールフィールドに格納される値を抽出する。また、プロセッサ１０１はＲＰＲフレームのヘッダを削除する。このときのフレームは、通常のイーサネットフレームである（図７Ｂ参照）。
　ＯＰ４７では、ＲＰＲ　ＩＦ　１１１において受信したフレームを迂回ＮＷに送信することを判定したので、プロセッサ１０１は、ＶＬＡＮタグをＯＰ４１においてＲＰＲヘッダが外されたフレームのイーサネットヘッダの所定の位置に挿入する。このＶＬＡＮタグのノードＩＤフィールドには、ＯＰ４１において抽出された宛先ノードＩＤの下位８ビットが格納される。また、ＶＬＡＮタグのサービスクラスフィールドには、ＯＰ４１において抽出されたＲＰＲヘッダのコントロールフィールドの値のうち使用されている２ビットが格納される。
　図２０は、カスケードＮＷの障害発生時に、迂回ＩＦ　１１３においてフレームが受信された場合の境界ノードであるリング装置１ｂのフレーム転送処理のフローチャートの一例である。図２０に示されるフローチャートは、カスケードＮＷの障害発生時に迂回ＩＦ　１１３において、フレームが受信された場合に開始される。なお、迂回ＩＦ　１１３において受信されるフレームは、ＶＬＡＮタグを有するイーサネットフレームである。
　図２０に示されるフローチャートにおいて、ＯＰ５２－ＯＰ５４，ＯＰ５６－ＯＰ５７の処理は、図１２に示されるフローチャートのＯＰ２２－ＯＰ２４，ＯＰ２６－ＯＰ２７の処理と同様である。以下、図１２に示されるフローチャートの処理と異なるＯＰ５１，ＯＰ５５の処理について説明する。
　ＯＰ５１では、プロセッサ１０１は、迂回ＮＷから迂回ＩＦ　１１３において受信したイーサネットフレームを解析し、ＶＬＡＮタグのノードＩＤフィールドの値８ビットを抽出する。また、プロセッサ１０１は、ＶＬＡＮタグのサービスクラスフィールドの値２ビットを抽出する。プロセッサ１０１は、イーサネットフレームからＶＬＡＮタグを削除する。
　ＯＰ５５では、迂回ＩＦ　１１３において受信したイーサネットフレームをＲＰＲネットワークに送信することが判定されたので、プロセッサ１０１は、該イーサネットフレームにＲＰＲヘッダを付与してＲＰＲフレームを生成する（図７Ｂ、フレームＦＲ３、ＦＲ４参照）。プロセッサ１０１は、ＲＰＲフレームの宛先ノードＩＤフィールドに、ＯＰ２１で抽出されたＶＬＡＮタグのノードＩＤフィールドの値８ビットにパディングして６バイトにした値を格納する。また、プロセッサ１０１は、ＲＰＲフレームのコントロールフィールドに、ＯＰ２１で抽出されたＶＬＡＮタグのサービスクラスフィールドの値２ビットにパディングして１バイトにした値を格納する。
　図２１は、ＬＡＮ　ＩＦ　１１２においてフレームが受信された場合の境界ノードであるリング装置１ｂのフレーム転送処理のフローチャートの一例である。図２１に示されるフローチャートは、ＬＡＮ　ＩＦ　１１２においてフレームが受信された場合に開始される。
　図２１に示されるフローチャートにおいて、ＯＰ６１－ＯＰ６２，ＯＰ６４－ＯＰ６６，ＯＰ６８の処理は、図１３に示されるフローチャートのＯＰ３１－ＯＰ３２，ＯＰ３４－ＯＰ３６，ＯＰ３８の処理と同様である。以下、図１２に示されるフローチャートの処理と異なるＯＰ６０，ＯＰ６３，ＯＰ６７の処理について説明する。
　ＯＰ６０では、プロセッサ１０１は、使用されているＱｏＳテーブルからＱｏＳ情報を取得する。なお、カスケードＮＷの正常時には、正常時用ＱｏＳテーブル１８ａが使用される。カスケードＮＷの障害時には、障害時用ＱｏＳテーブル１８ｂが使用される。
　ＯＰ６３では、ＬＡＮ　ＩＦ　１１２において受信されたイーサネットフレームがカスケードＮＷ（ＲＰＲ）に転送されることが判定されたので、プロセッサ１０１は、該イーサネットフレームにＲＰＲヘッダを付与してＲＰＲフレームを生成する（図７Ｂ、フレームＦＲ１、ＦＲ２参照）。プロセッサ１０１は、ＲＰＲフレームの宛先ノードＩＤフィールドに、配下のＮＷとノードＩＤとの対応付けから取得した宛先ノードＩＤを格納する。また、プロセッサ１０１は、ＲＰＲフレームのコントロールフィールドに、ＯＰ６０で取得したＱｏＳ情報で指定されるサービスクラスを格納する。このフレームはＲＰＲ　ＩＦ　１１１からカスケードＮＷ（ＲＰＲ）に送信される。
　ＯＰ６７では、ＬＡＮ　ＩＦ　１１２において受信されたイーサネットフレームが迂回ＮＷ（イーサネット）に転送されることが判定されたので、プロセッサ１０１は、該イーサネットフレームの所定の位置にＶＬＡＮタグを挿入する。プロセッサ１０１は、このＶＬＡＮタグのノードＩＤフィールドに、配下のＮＷとノードＩＤとの対応付けから取得した宛先ノードＩＤの下位８ビットを格納する。また、プロセッサ１０１は、ＶＬＡＮタグのサービスクラスフィールドに、ＯＰ６０において取得されたＱｏＳ情報で指定されるサービスクラスを格納する。このフレームは迂回ＩＦ　１１３から迂回ＮＷ（イーサネット）に送信される。
　＜第２実施形態の作用効果＞
　第２実施形態では、境界ノードであるリング装置１ｂは、迂回ＮＷ（イーサネット）にフレームを転送する場合に、ＶＬＡＮタグにＱｏＳ情報を格納することで、カスケードＮＷ（ＲＰＲ）内のＱｏＳ情報をイーサネットフレームに埋め込む。これによって、迂回ＮＷを経由した場合でもカスケードＮＷのＱｏＳ情報の欠落を防ぐことができる。
　また、第２実施形態では、カスケードＮＷ内のリング装置は、カスケードＮＷの正常時と障害時とでＱｏＳテーブルを使い分ける。これによって、カスケードＮＷの障害時には、カスケードＮＷよりも帯域の狭い迂回ＮＷに応じた帯域制御が実行され、データの欠落を防止することができる。
　＜第２実施形態の変形例＞
　図２２は、迂回ＮＷがＲＰＲ１とＲＰＲ２との２つのＲＰＲネットワークで共有される例を示す。迂回ＮＷにおいて、ＲＰＲ１の境界ノードであるリング装置＃１，＃５とＲＰＲ２の境界ノードであるリング装置＃１１、#１５とがそれぞれレイヤ２スイッチを介して接続される。
　ＲＰＲ１とＲＰＲ２との両方で障害が発生することを二重障害と称する。二重障害の場合には、ＲＰＲ１とＲＰＲ２との両方のネットワークが迂回ＮＷを利用するため、迂回ＮＷの帯域が圧迫される。そのため、第２実施形態の変形例では、各リング装置は、正常時用のＱｏＳテーブル１と障害時用のＱｏＳテーブル２とに加えて、二重障害時用のＱｏＳテーブル３を備え、これらを使い分ける。
　例えば、ＲＰＲ１及びＲＰＲ２のカスケードＮＷの帯域が１０００Ｍｂｐｓ，迂回ＮＷの帯域が６００Ｍｂｐｓであるとする。この場合、例えば、正常時用のＱｏＳテーブル１には、カスケードＮＷの帯域１０００Ｍｐｂｓに応じた帯域制御の設定が格納される。例えば、障害時用のＱｏＳテーブル２には、迂回ＮＷの帯域６００Ｍｐｂｓに応じた帯域制御の設定が格納される。また、例えば、二重障害時用のＱｏＳテーブル３には、迂回ＮＷの帯域の半分の３００Ｍｐｂｓのように二重障害時に利用可能な帯域に応じた帯域制御の設定が格納される。
　以下、ＲＰＲ１について説明するが、ＲＰＲ２についても同様に構成することができる。境界ノードであるリング装置＃１及びリング装置＃２は、例えば、迂回ＮＷ経由でのフレームの遅延，欠落等を検知することによって、二重障害の発生を検出する。例えば、自ノードのコピーを対向ノードに送信する制御フレームは、所定間隔で迂回ＮＷ経由でやり取りされるので、境界ノードはこの制御フレームの受信間隔等を監視して二重障害を検出する。
　境界ノードであるリング装置＃１、＃５は、二重障害を検出すると、制御フレームを利用して、二重障害の発生をカスケードＮＷ内のリング装置＃２－＃４に通知する。カスケードＮＷ内のリング装置＃２－＃４は、二重障害発生の通知を受信すると、使用するＱｏＳテーブルを二重障害時用のＱｏＳテーブル３に切り替える。境界ノードであるリング装置＃１、＃５は、二重障害を通知する制御フレームを送信すると、使用するＱｏＳテーブルを二重障害時用のＱｏＳテーブル３に切り替える。
　各リング装置が二重障害時用のＱｏＳテーブルを備え、二重障害発生時には、二重障害時用のＱｏＳテーブルを使用することによって、複数のカスケードＮＷで迂回ＮＷを共有する場合の二重障害にも柔軟に適応する帯域制御を行うことができる。
１，１ｂ，２　　　リング装置
１１　　　ＲＰＲ処理部
１２　　　迂回ＮＷ処理部
１３　　　ＬＡＮ処理部
１４　　　宛先ノード判定部
１５　　　ノードリスト管理部
１６　　　ノードリストデータベース
１７　　　ＱｏＳ処理部
１６１　　自ノード情報
１６２　　対向ノード情報1

Claims (12)

  1. 　カスケード型のトポロジの第１のネットワークの終端に接続し、前記第１のネットワークとはフレームの形式が異なる第２のネットワークにも接続する通信装置であって、
    　前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第１のリストを、前記第１のネットワークのもう一方の終端に位置し、前記第２のネットワークにも接続し、前記第２のネットワークにおいて対向する通信装置に、送信する送信部と、
    　前記対向する通信装置から、前記対向する通信装置の前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第２のリストを受信する受信部と、
    　前記第１のリストと、前記第２のリストとを格納する格納部と、
    　フレームの宛先が、前記第１のリスト又は前記第２のリストのいずれに含まれるか判定する判定部と、
    　前記第１のネットワークから受信したフレームの宛先が前記第２のリストに含まれる場合に、前記フレームを前記第２のネットワークに送信するフレーム送信部と、
    を備える通信装置。
  2. 　前記判定部は、前記第１のネットワーク内において障害が発生した場合に、フレームの宛先について、前記第１のリストと、前記第２のリストとを検索する、
    請求項１に記載の通信装置。
  3. 　前記フレーム送信部は、前記第１のネットワークから受信したフレームを前記第１のネットワークで用いられる形式から前記第２のネットワークで用いられる形式に変換し、該変換において、前記第２のネットワークで用いられる形式のヘッダ内の宛先情報を格納するフィールドとは異なる位置に、前記フレームの宛先ノードの情報を埋め込む、
    請求項１又は２に記載の通信装置。
  4. 　前記第２のネットワークから受信したフレームの宛先が前記第１のリストに含まれる場合に、前記フレームを前記第２のネットワークで用いられる形式から前記第１のネットワークで用いられる形式に変換し、該変換において、前記第２のネットワークで用いられる形式のヘッダ内の宛先情報を格納するフィールドとは異なる位置に埋め込まれた前記フレームの宛先ノードの情報を、前記第１のネットワークで用いられる形式のヘッダ内の宛先情報に格納し、前記フレームを前記第１のネットワークに送信する第２のフレーム送信部、
    をさらに備える請求項３に記載の通信装置。
  5. 　前記フレーム送信部は、前記変換において、前記第２のネットワークで用いられる形式のヘッダ内のＱｏＳ情報を格納するフィールドとは異なる位置に、前記第１のネットワークで用いられる形式のヘッダ内のＱｏＳ情報を埋め込む、
    請求項３又は４に記載の通信装置。
  6. 　前記第１のネットワークの正常時用のＱｏＳ設定情報と、前記第１のネットワークの障害発生時用のＱｏＳ設定情報とを格納する前記第１のネットワーク内の通信装置に対して、前記第１のネットワークの障害発生時に、前記障害発生時用のＱｏＳ設定情報への切り替えを通知する通知部をさらに備える、
    請求項１から５のいずれか一項に記載の通信装置。
  7. 　前記第２のネットワークには、カスケード型のトポロジの第３のネットワークが接続しており、
    　前記第１のネットワーク内の通信装置は、前記第１のネットワーク及び前記第３のネットワークの両方における障害発生時用のＱｏＳ設定情報をさらに格納し、
    　前記通知部は、前記第１のネットワーク及び前記第３のネットワークの両方における障害発生時に、前記第１のネットワーク内の通信装置に、前記第１のネットワーク及び前記第３のネットワークの両方における障害発生時用のＱｏＳ設定情報への切り替えを通知する、
    請求項６に記載の通信装置。
  8. 　前記第１のネットワークの正常時用のＱｏＳ設定情報と、前記第１のネットワークの障害発生時用のＱｏＳ設定情報とを格納する第２の格納部と、
    　前記第１のネットワークの障害発生時に、使用するＱｏＳ設定情報を前記第１のネットワークの障害発生時用のＱｏＳ設定情報に切り替えるＱｏＳ管理部と、
    をさらに備える請求項５から７のいずれか一項に記載の通信装置。
  9. 　前記第２の格納部は、前記第２のネットワークに接続するカスケード型のトポロジの第３のネットワークと前記第１のネットワークとにおける障害発生時用のＱｏＳ設定情報をさらに格納し、
    　前記ＱｏＳ管理部は、前記第１のネットワーク及び前記第３のネットワークの両方における障害発生時に、使用するＱｏＳ設定情報を、前記第１のネットワーク及び前記第３のネットワークの両方における障害発生時用のＱｏＳ設定情報へ切り替える、
    請求項８に記載の通信装置。
  10. 　前記第１のネットワークはＲＰＲネットワークであり、
    　前記第２のネットワークはＥｔｈｅｒｎｅｔネットワークであり、
    　前記フレーム送信部は、前記変換において、ＥｔｈｅｒｎｅｔヘッダにＶＬＡＮタグを挿入し、該ＶＬＡＮタグ内に、該フレームのＲＰＲヘッダ内の宛先ノード情報を格納する、
    請求項３から９のいずれか一項に記載の通信装置。
  11. 　カスケード型のトポロジの第１のネットワークの終端に接続し、前記第１のネットワークとはフレームの形式が異なる第２のネットワークにも接続する通信装置が、
    　前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第１のリストを、前記第１のネットワークのもう一方の終端に位置し、前記第２のネットワークにも接続し、前記第２のネットワークにおいて対向する通信装置に、送信し、
    　前記対向する通信装置から、前記対向する通信装置の前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第２のリストを受信し、
    　前記第１のリストと、前記第２のリストとを格納し、
    　フレームの宛先が、前記第１のリスト又は前記第２のリストのいずれに含まれるか判定し、
    　前記第１のネットワークから受信したフレームの宛先が前記第２のリストに含まれる場合に、前記フレームを前記第２のネットワークに送信する、
    通信方法。
  12. 　カスケード型のトポロジの第１のネットワークの終端に接続し、前記第１のネットワークとはフレームの形式が異なる第２のネットワークにも接続する通信装置を、
    　前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第１のリストを、前記第１のネットワークのもう一方の終端に位置し、前記第２のネットワークにも接続し、前記第２のネットワークにおいて対向する通信装置に、送信する送信部と、
    　前記対向する通信装置から、前記対向する通信装置の前記第１のネットワーク経由のフレームの送信の宛先である前記第１のネットワーク内の通信装置の情報を含む第２のリストを受信する受信部と、
    　前記第１のリストと、前記第２のリストとを格納する格納部と、
    　フレームの宛先が、前記第１のリスト又は前記第２のリストのいずれに含まれるか判定する判定部と、
    　前記第１のネットワークから受信したフレームの宛先が前記第２のリストに含まれる場合に、前記フレームを前記第２のネットワークに送信するフレーム送信部と、
    として機能させる通信プログラム。
PCT/JP2012/058127 2012-03-28 2012-03-28 通信装置、通信方法、及び通信プログラム WO2013145150A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2012/058127 WO2013145150A1 (ja) 2012-03-28 2012-03-28 通信装置、通信方法、及び通信プログラム
JP2014507118A JP5907252B2 (ja) 2012-03-28 2012-03-28 通信装置、通信方法、及び通信プログラム
US14/497,702 US9614718B2 (en) 2012-03-28 2014-09-26 Communication system for fault tolerance in cascade topology and ring topology

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/058127 WO2013145150A1 (ja) 2012-03-28 2012-03-28 通信装置、通信方法、及び通信プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/497,702 Continuation US9614718B2 (en) 2012-03-28 2014-09-26 Communication system for fault tolerance in cascade topology and ring topology

Publications (1)

Publication Number Publication Date
WO2013145150A1 true WO2013145150A1 (ja) 2013-10-03

Family

ID=49258517

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/058127 WO2013145150A1 (ja) 2012-03-28 2012-03-28 通信装置、通信方法、及び通信プログラム

Country Status (3)

Country Link
US (1) US9614718B2 (ja)
JP (1) JP5907252B2 (ja)
WO (1) WO2013145150A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017002804B4 (de) * 2017-03-23 2018-10-04 WAGO Verwaltungsgesellschaft mit beschränkter Haftung Koppler für ein Automatisierungssystem
CN113422818B (zh) * 2021-06-18 2022-10-25 重庆紫光华山智安科技有限公司 一种数据级联传输方法、系统及节点设备
US11784916B2 (en) * 2021-07-23 2023-10-10 EMC IP Holding Company LLC Intelligent control plane communication

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006060489A (ja) * 2004-08-19 2006-03-02 Mitsubishi Electric Corp 二重リングネットワーク
JP2010103788A (ja) * 2008-10-24 2010-05-06 Fujitsu Telecom Networks Ltd パケット伝送制御システム及びパケット伝送制御方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3842379B2 (ja) * 1997-02-17 2006-11-08 富士通株式会社 伝送路データ迂回システム
JP2001285322A (ja) * 2000-03-28 2001-10-12 Fujitsu Ltd Ｌａｎ間通信装置及びこれを用いるｌａｎ間通信ネットワーク
JP4052956B2 (ja) * 2003-02-07 2008-02-27 富士通株式会社 Ｒｐｒネットワークシステム，ステーションノード，ブリッジノード及びｒｐｒカード
CN100364289C (zh) * 2004-04-30 2008-01-23 华为技术有限公司 在基于弹性分组环的网络中实现二层设备互连的方法
JP2007116284A (ja) * 2005-10-18 2007-05-10 Fujitsu Ltd 伝送装置
JP4760504B2 (ja) * 2006-04-12 2011-08-31 株式会社日立製作所 ネットワークシステムおよび通信装置
JP2008060489A (ja) * 2006-09-04 2008-03-13 Nippon Steel Chem Co Ltd 電子部品吸着保持具
JP5105096B2 (ja) * 2006-11-22 2012-12-19 日本電気株式会社 通信ネットワーク、情報処理装置およびアドレス割当方法
ATE536682T1 (de) * 2008-10-15 2011-12-15 Yamaha Corp Audionetzwerksystem

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006060489A (ja) * 2004-08-19 2006-03-02 Mitsubishi Electric Corp 二重リングネットワーク
JP2010103788A (ja) * 2008-10-24 2010-05-06 Fujitsu Telecom Networks Ltd パケット伝送制御システム及びパケット伝送制御方法

Also Published As

Publication number Publication date
US9614718B2 (en) 2017-04-04
US20150009799A1 (en) 2015-01-08
JP5907252B2 (ja) 2016-04-26
JPWO2013145150A1 (ja) 2015-08-03

Similar Documents

Publication Publication Date Title
US7898942B2 (en) Ring network system, failure recovery method, failure detection method, node and program for node
US7826400B2 (en) Packet ring network system and packet transport method
US9853894B2 (en) Apparatus and method for establishing tunnels between nodes in a communication network
JP4676403B2 (ja) 通信装置及び通信システム
JP4688765B2 (ja) ネットワークの冗長方法及び中位スイッチ装置
JP5345942B2 (ja) Ｐｂｔネットワークの中間ノードにおけるイーサネットｏａｍ
JP5158369B2 (ja) 通信システム、ノード、端末、通信方法、およびプログラム
US20040170184A1 (en) RPR network system
JPWO2004075485A1 (ja) ネットワークシステム、スパニングツリー構成方法及び構成プログラム、スパニングツリー構成ノード
JP2006270169A (ja) パケット中継装置
GB2471761A (en) Fault recovery path reconfiguration in ring networks
JP5891877B2 (ja) 中継装置および中継方法
CN110401599A (zh) 数据包的处理方法及装置、存储介质、电子装置
KR101477012B1 (ko) Ｓｄｎ 스위칭 방법, 장치, 시스템 및 컴퓨터 판독 가능한 기록 매체
WO2021088433A1 (zh) 一种报文的处理方法，装置和系统
US8218446B2 (en) Frame transfer route confirmation method, node, frame transfer route confirmation program and frame transfer route confirmation system
US20070217438A1 (en) Ring node device and method of connecting terminal to ring node device
US20150172173A1 (en) Communication system, communication apparatus and path switching method
JP5907252B2 (ja) 通信装置、通信方法、及び通信プログラム
JP2005175591A (ja) スイッチングハブ
JPWO2006075402A1 (ja) オープンループネットワークノード装置及びオープンループネットワーク制御方法
JP2009147653A (ja) 通信システムおよびリングノード装置
JP2017034365A (ja) ネットワークシステムおよびパケット転送方法
JP5045332B2 (ja) パケットリングネットワークシステム、およびフォワーディングデータベース管理方法
JP4447385B2 (ja) Ｒｐｒノード装置およびｒｐｒネットワークのフォワーディングパス制御方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12872709

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014507118

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12872709

Country of ref document: EP

Kind code of ref document: A1