JP2013046090A - Communication device and communication system - Google Patents

Abstract

There is provided a communication device capable of shortening a time required from a failure occurrence to a return in a ring network.
An ERP module that performs ERP (Ethernet Ring Protection) control including failure detection of a ring network, a topology information table in which topology information of the ring network is registered, and operation monitoring of the ERP module are performed. When a failure is detected by the ERP module 1 and the topology information collection module 2 that collects identification information and position information of each communication device forming the ring network and updates the topology information table 4 based on the collected information Whether the detected failure corresponds to a device failure or a link failure is determined based on the topology information table 4, and in the case of a device failure, the device in which the failure has occurred is specified, and the specified result is used as a higher-level protocol. A failure location identification module 6 to be notified.
[Selection] Figure 4

Description

  The present invention relates to a communication device that forms a ring network.

  ERP (Ethernet Ring Protection) is a layer 2 redundancy / loop prevention protocol using Ether OAM (see Non-Patent Documents 1 and 2). ERP realizes failure switching time (specifically, 50 milliseconds or less) equivalent to RPR (Resilient Packet Ring) and SDH (Synchronous Digital Hierarchy), and is a wide area network such as the power / transport field and metropolitan area network. It is expected to be used in other fields.

  In addition, connecting an ERP network to other subnets is generally widely performed, and in this case, a layer 3 routing protocol such as OSPF (Open Shortest Path First) or RIP (Routing Information Protocol) is used (non-patent). Reference 3 etc.). In many cases, layer 3 functions such as a virtual router and multicast routing are used together. Non-Patent Document 4 describes redundancy when multicast control is performed using Multicast Listener Discovery (MLD) and a multicast packet transmission terminal exists in a layer 3 network and a listener exists in a layer 2 network. A technique for performing a process for re-selecting an MLD querier from among existing MLD proxies is disclosed.

"G.8032 / Y.1344 Ethernet ring protection switching", ITU-T, Jun.2008 "Y.1731 OAM functions and mechanisms for Ethernet based networks", ITU-T, Feb.2008 "RFC2453 RIP Version 2", Internet Engineering Task Force, Nov.1998 "Examination of high-speed re-selection of MLD querier in case of failure in Ethernet ring", Norihiko Ochiai, Kazuki Hamada, Yuji Ogawa, Kazuyuki Kashima, Hideaki Yamanaka, Proceedings of 2011 IEICE General Conference B-6-94, Mar. 2011

  When the layer 3 protocol is operated on ERP, failure detection based on link down cannot be used, so it is necessary to perform failure detection based on a timer. Although the time required for failure detection by the timer differs depending on the protocol, for example, OSPF requires 40 seconds from failure occurrence to detection, and MLD-Proxy (Multicast Listener Discovery-Proxy) requires a maximum of 255 seconds. This is very long compared to the failure detection time within 50 milliseconds of ERP, and is required for layer 3 protocol failure switching even though layer 2 route switching by ERP is realized at high speed. There is a problem that it takes a long time to return to a state where a complete service can be used with End-to-End after a failure occurs because the time required for the failure (the time from the occurrence of the failure to the detection) is very long.

  The present invention has been made in view of the above, and in the state where the layer 3 protocol is operated on the ERP, from the occurrence of a failure to the state where a complete service can be used end-to-end. It is an object of the present invention to obtain a communication device and a communication system that can shorten the required time. Further, in a ring network in which communication devices to which the present invention is applied and communication devices to which the present invention is not applied are mixed, a communication device and a communication capable of reducing the time required for returning from a failure occurrence to a service usable state The purpose is to obtain a system.

  In order to solve the above-described problems and achieve the object, the present invention provides a communication device forming a ring network, an ERP processing means for performing ERP control including failure detection of the ring network, By collecting the topology information table in which the topology information is registered and the operation monitoring of the ERP processing means, the identification information and position information of each communication device forming the ring network are collected, and based on the collected information When a failure is detected by the topology information table updating means for updating the topology information table and the ERP processing means, the topology information table indicates whether the detected failure corresponds to a device failure or a link failure. In the case of a device failure, identify the device where the failure occurred, Characterized in that it and a failure location specification means for notifying the specific result to the upper layer protocol.

  According to the present invention, the layer 3 protocol can detect a network failure in a short time, and the time required from the occurrence of the failure to the path switching can be shortened. As a result, there is an effect that the service stop time at the end-to-end can be reduced.

FIG. 1 is a diagram illustrating a configuration example of a block that executes a topology configuration recognition process in a communication device according to the present invention. FIG. 2 is a diagram illustrating an example of an ERP network. FIG. 3 is a diagram illustrating an example of the topology information table. FIG. 4 is a diagram illustrating a configuration example of the communication apparatus according to the first embodiment. FIG. 5 is a diagram illustrating a configuration example of the communication apparatus according to the second embodiment. FIG. 6 is a diagram illustrating a configuration example of the communication apparatus according to the third embodiment. FIG. 7 is a diagram illustrating a configuration example of a communication apparatus according to the fourth embodiment. FIG. 8 is a diagram illustrating a configuration example of a communication apparatus according to the fifth embodiment. FIG. 9 is a diagram illustrating an example of an MLD querier selection operation in the communication system according to the fifth embodiment. FIG. 10 is a diagram illustrating a configuration example of a communication apparatus according to the sixth embodiment.

  Embodiments of a communication apparatus and a communication system according to the present invention will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

Embodiment 1 FIG.
First, in the communication apparatus according to the present invention, a block for recognizing a ring network configuration (hereinafter, topology) will be described. Although details will be described later, in the communication apparatus according to the present invention, the location of the failure is specified using the topology information, and the time required for the failure recovery is shortened.

  FIG. 1 is a diagram illustrating a configuration example of a block that executes a topology configuration recognition process in a communication device according to the present invention. As illustrated, the communication apparatus according to the present invention includes an ERP module 1, a topology information collection module 2, a physical port 3, and a topology information table 4.

  The ERP module 1 operating as an ERP processing means has the functions defined in Non-Patent Document 1, and performs path control and management packet transmission / reception in an ERP network (a ring network to which ERP is applied). The physical port 3 is an interface with other communication devices, and transmits and receives various signals. The topology information table 4 is a table for storing the topology information generated by the topology information collection module 2. The topology information includes identification information (ID) of communication devices forming the ERP network and the order of arrangement of the communication devices. Information is registered. As the identification information, for example, node identification information (IP address) included in the Link Trace Request packet defined in Non-Patent Document 2 is used. Other identification information may be used.

  The topology information collection module 2 that operates as a topology information table update unit is a module that monitors the operation of the ERP module 1 and collects topology information, and includes a Link Trace Request transmission control unit 21, a Link Trace Response monitoring unit 22, and topology information. A calculation unit 23 is provided.

  When the device itself is set as an RPL (Ring Protection Link) owner (RPL Owner), the Link Trace Request transmission control unit 21 issues a link trace request (Link Trace Request) having a predetermined TTL value. An instruction is given to the ERP module at a predetermined timing to transmit. Note that the RPL owner indicates a node that is performing port blocking in order to prevent occurrence of a loop. The TTL value determined in advance (the initial value of TTL set when a link trace request is transmitted) is larger than the number of nodes (communication devices) forming the ERP network. It is assumed that all of the nodes to which the present invention is applied recognize the TTL initial value. For this reason, it is most appropriate to use 255 defined as the maximum value of TTL that can be set in the link trace request. However, a value different from TTL = 255 may be used as long as all the nodes can share the TTL initial value in advance and are larger than the number of nodes forming the ERP network. The link trace request transmission instruction is performed, for example, when it is detected that the link trace request is physically connected to another communication apparatus. After detecting a physical connection, it may be instructed to retransmit every time a predetermined time elapses.

  The Link Trace Response monitoring unit 22 monitors the link trace response received by the ERP module 1, and transmits information obtained as a result to the topology information calculation unit 23 as Response information. The link trace response to be monitored includes both the link trace response transmitted from the own device to the transmission source communication device of the link trace request and the link trace response transmitted from another communication device and relayed by the ERP module 1. To do. To the topology information calculation unit 23, at least three pieces of information including a reception port, a TTL value, and identification information (ID) of a transmission source device of the link trace response are transmitted.

  The topology information calculation unit 23 calculates topology information based on the information transmitted from the Link Trace Response monitoring unit 22. A specific topology calculation procedure will be described with reference to FIGS. FIG. 2 is a diagram illustrating an example of an ERP network formed by five nodes. In the ERP network illustrated in FIG. 2, a procedure in which each node calculates topology information is described below.

  Here, assuming that the node A is the RPL owner, the node A transmits the link trace request 101 using a predetermined TTL value (TTL = 255 in the illustrated example). In the node A, transmission of the link trace request 101 is executed by the ERP module 1 in accordance with an instruction from the Link Trace Request transmission control unit 21 in the topology information collection module 2.

  Each node (node B, C, D, E) that has received the link trace request 101 performs an operation according to the contents described in Non-Patent Document 1, and relays the received link trace request 101 (opposite to the receiving side). And the link trace response 102 is returned. Note that the TTL values assigned to the respective arrows shown in the drawings indicate the TTL values set in the link trace request 101 and the link trace response 102, respectively. In each node other than the RPL owner, the ERP module 1 receives and forwards the link trace request 101 and returns the link trace response 102. FIG. 2 shows only the link trace request 101 transmitted from the node A to the node B (right direction) and the link trace response 102 corresponding thereto. Node A also transmits a link trace request (to the direction of node E), and each node that receives this transmits a link trace request and returns a link trace response.

  Each node that has received the link trace request 101 forwards the link trace request 101 and replies with the link trace response 102, and monitors all the link trace responses 102 including the link trace response 102 transmitted from its own device. In each node, the link trace response 102 is monitored by the Link Trace Response monitoring unit 22 in the link topology information collection module 2. FIG. 3 shows an example of information obtained by the Link Trace Response monitoring unit 22 of each node as a result of monitoring. FIG. 3 shows an example of information acquired by the node C among the nodes shown in FIG. 2 (configuration example of the topology information table 4).

  In the node C, the topology information calculation unit 23 of the topology information collection module 2 first transmits in the right direction among the TTLs of the link trace response transmitted by itself in the right direction (node D) and the left direction (node B). 252 and those transmitted in the left direction are 253, so that the node A of the RPL owner recognizes that it is at a position of 2 Hops in the right direction and 3 hops in the left direction. When a link trace response in the left direction including TTL = 251 and an ID indicating the node B is received (received from the right side), the value of TTL is greater than TTL = 252 of the link trace response transmitted by itself. Therefore, it is recognized that the node B that is the transmission source of this signal is at the position of 1 Hop to the right. Similarly, by receiving the link trace response including the ID of the node D and the link trace response including the ID of the node E, from the reception method (transmission direction of the link trace response) and the set TTL value, Node D recognizes that it is 1 Hop on the left and Node E is 2 Hop on the left. By collecting all the collected information in this way, it is possible to grasp the arrangement of all nodes forming the ERP network.

  When the topology information calculation unit 23 grasps the position of each node, the topology information calculation unit 23 registers the collected information and the grasped position information in the topology information table 4 having the configuration illustrated in FIG. 3 and updates the topology information table 4. In FIG. 3, “Request” indicates a link trace request, and “Response” indicates a link trace response. Among the TTL values described in the column “Response from right”, those whose transmission source is other than node C (own device) are link traces transmitted from other nodes in the left direction (clockwise). The TTL value set in the response is shown. Among the TTL values described in the column “Response from the left”, those whose transmission source is other than the node C (own device) are link traces transmitted from the other nodes in the right direction (counterclockwise). The TTL value set in the response is shown. Among the TTL values described in the row of “Node C (own device)”, the one corresponding to “Response from the right” is the link trace response (transmitted counterclockwise) transmitted in the left direction (clockwise). TTL value set in “Response to request”, the one corresponding to “Response from the left” is set to the link trace response (response to the request sent in the clockwise direction) sent in the right direction (counterclockwise) TTL value.

  Here, the node C has been described as an example. However, among the nodes in the ERP network, all the nodes to which the present invention is applied acquire the arrangement order information of the nodes forming the ERP network by the same procedure. The node A that is the RPL owner analyzes the TTL value set in the link trace response from each node in response to the link trace request, and acquires the arrangement order information of the nodes forming the ERP network. Note that the above processing is not executed for a node to which the present invention is not applied (the arrangement order information of the nodes forming the ERP network is not acquired), but a link trace response is returned when a link trace request is received. The processing is a standard operation described in Non-Patent Document 1, and even if nodes not applying the present invention are mixed in the ERP network, the processing to which the nodes to which the present invention is applied acquires topology information is hindered. do not become. Further, the above processing does not adversely affect the operation of a node to which the present invention is not applied.

  As described above, the node to which the present invention is applied can easily obtain the topology information of the ERP network. The acquired topology information is used in the failure location specifying operation described later, and is provided when requested by the network administrator.

  Next, a characteristic operation of the communication apparatus according to the present embodiment, specifically, an operation when a failure in the ERP network is detected will be described.

  FIG. 4 is a diagram illustrating a configuration example of the communication apparatus according to the first embodiment. In order to simplify the description, only the components related to the characteristic operation are described.

  As shown in the figure, the communication apparatus according to the present embodiment mainly has an ERP module 1, a topology information collection module 2, a physical port 3, a topology information table 4, an OSPF module 5, a fault location specifying module 6, and a path table 7. It has. The ERP module 1, topology information collection module 2, physical port 3 and topology information table 4 are the same as the ERP module 1, topology information collection module 2, physical port 3 and topology information table 4 shown in FIG. Description is omitted. In the present embodiment, OSPF (Open Shortest Path First) is used as the layer 3 routing protocol.

  The failure location identification module 6 executes a failure location identification operation. Specifically, the device in which the failure has occurred is specified based on the failure information (failure detection result by ERP) provided from the ERP module 1 and the topology information stored in the topology information table 4. In addition, the OSPF module 5 is notified of information indicating the specific result (failure information). The failure information notified to the OSPF module 5 is, for example, the IP address of the communication device in which the failure has occurred.

  The OSPF module 5 is a module that performs layer 3 routing using OSPF. When failure information (information indicating the above-described identification result) is received from the failure location identification module 6, the OSPF module 5 performs failure switching based on the received failure information. (Update the route table 7). The OSPF module 5 may consider that the faulty device has disappeared and perform recalculation of the route, or all the links connected to the faulty device have been disconnected or the path cost has become a very large value. The route may be recalculated assuming that it has become. Note that this processing is performed only in the case of a device failure and not in the case of a link failure. Whether the failure is a link failure or a device failure is determined when the failure location specifying module 6 specifies a failure location based on the failure information and topology information notified from the ERP module 1. That is, if a device is included in the failure range, a device failure is assumed. If not, a link failure is assumed. When a failure occurs in the ERP network, the communication devices (communication devices that have detected the failure) located at both ends of the failure range block the port on the failure occurrence side, and a signal indicating failure detection on the failure occurrence side Since the (failure detection signal) is transmitted, the failure location specifying module 6 includes the device in the failure range by comparing the topology information with the transmission source device of the failure detection signal received from the clockwise and counterclockwise directions. Can be determined. For example, in the ERP network having the configuration shown in FIG. 2, when a failure occurs in the node D, the node C and the node E detect the failure and transmit a failure detection signal. Each node can determine that a failure has occurred in node D. When a failure occurs in the link between the node C and the node D, the node C and the node D transmit failure detection signals, so that each node receiving these signals can determine that a link failure has occurred. .

  As described above, the communication device according to the present embodiment collects identification information and position information (arrangement order information) of each communication device forming the ring network based on the ERP link trace response transmission / reception result. If a failure is detected by ERP, it is registered as topology information in the topology information table, and when a failure is detected, the failure type (apparatus failure and error) is determined based on the failure detection result and the topology information registered in the topology information table. Any of the link failures) is determined, and in the case of a device failure, the device in which the failure has occurred is identified, and the identification result is notified to the upper layer (layer 3). Thereby, the layer 3 protocol (OSPF protocol) can detect a network failure in a short time, and the required time from the occurrence of the failure to the path switching can be shortened. As a result, the service stop time at the end-to-end can be shortened.

  By the way, in an environment in which a device to which the present invention is applied and a device that has not been implemented are mixed in an ERP network, the above-described processing shown in the present embodiment is executed in the device to which the present invention is applied. OSPF path switching is performed at high speed, but a device that does not apply the present invention cannot acquire failure occurrence information from ERP (failure occurrence information from layer 2). Cannot be done. Here, if the device to which the present invention is applied is a representative router of a network to which the OSPF protocol is applied, when the representative router detects a failure based on information from the ERP, LSA, which is one of the processes defined in the OSPF protocol. Since (Link State Advertisement) exchange is promptly performed with other devices in the ERP network, the route information held by each device in the ERP network is synchronized with the information held by the representative router. In other words, by using a device to which the present invention is applied as a representative router in an ERP network, even when devices to which the present invention is not applied are mixed in the ERP network, the OSPF paths of all the devices in the ERP network Switching can be speeded up. Therefore, when the representative router is a device to which the present invention is applied, even if devices not applying the present invention are mixed in the ERP network, the OSPF path switching of all devices in the ERP network is completed in a short time. be able to.

Embodiment 2. FIG.
FIG. 5 is a diagram illustrating a configuration example of the communication apparatus according to the second embodiment. The communication apparatus according to the present embodiment has a configuration in which an OSPF failure detection notification module 8 is added to the communication apparatus (see FIG. 4) described in the first embodiment. Since the components other than the OSPF failure detection notification module 8 are the same as those provided in the communication apparatus according to the first embodiment, description of components other than the OSPF failure detection notification module 8 will be omitted.

  The OSPF failure detection notification module 8 generates a predetermined OSPF protocol packet based on the failure information output from the OSPF module 5 in order to cause a communication device to which the present invention is not applied to perform failure switching, and applies the present invention. It transmits toward other communication apparatuses including the communication apparatus which is not. The failure information output from the OSPF module 5 is the IP address or MAC address of the device in which the failure has occurred. The destination of the OSPF protocol packet may be limited to only a communication device to which the present invention is not applied, or may be all communication devices including a communication device to which the invention is applied. The IP address of the communication device can be obtained from the topology information table 4.

  In the present embodiment, when a failure occurs in a device in the ERP network, any one of the devices to which the present invention is applied among the devices other than the device in which the failure has occurred is failed. By transmitting a packet indicating that the path from the generated device is invalid, the device to which the present invention is not applied is caused to perform fault switching. In the packet to be transmitted, for example, the path cost of the link connected to the failure occurrence device is set to 65535. Path cost 65535 indicates unreachability in the OSPF protocol. In addition, a method of setting a sufficiently large path cost compared to a link in which no failure has occurred may be used so that there is no path passing through the path, or any other method is used. Does not disturb. However, since it is possible to reliably notify the occurrence of a failure by using the method of setting the path cost to 65535, it is desirable to adopt the method of setting the path cost to 65535. By transmitting the OSPF protocol packet with the path cost of the link connected to the faulty device as 65535, the communication device that has received this packet performs OSPF path switching and returns to a normal state.

  When there are a plurality of communication devices to which the present invention is applied in a device in which no failure has occurred, a packet indicating that the path from the device in which the failure has occurred is invalid is transmitted to another communication device. As a method for selecting one communication device, there is a method for exchanging information on devices between communication devices to which the present invention is applied and selecting a device in charge of transmission in advance. As another method, a method of performing fixed setting by an administrator or the like may be used, or any other method may be used.

  Note that the OSPF module 5 may have the function of the OSPF failure detection notification module 8. When the own device is an OSPF representative router, the OSPF failure detection / notification module 8 does not perform the above-described operation (operation of transmitting an OSPF packet for the purpose of switching a failure to a communication device to which the present invention is not applied). Also good.

  As described above, the communication apparatus according to the present embodiment adds the OSPF failure detection notification module 8 to the communication apparatus according to the first embodiment, and when a failure occurrence is detected, another communication apparatus (applies the present invention). The communication is not notified to the layer 3 protocol of the failure detected in the layer 2), and an OSPF protocol packet with a sufficiently large path cost is transmitted to notify the failure occurrence in a pseudo manner, and the failure is switched. We decided to carry out. Accordingly, it is possible to realize a communication system capable of performing OSPF path switching at high speed even when the representative router of the network to which the OSPF protocol is applied is not a communication device to which the present invention is applied. Of course, the communication device of this embodiment may be used as a representative router.

Embodiment 3 FIG.
FIG. 6 is a diagram illustrating a configuration example of the communication apparatus according to the third embodiment. The communication device according to the present embodiment is obtained by replacing the OSPF module 5 and the OSPF failure detection notification module 8 of the communication device (see FIG. 5) described in the second embodiment with a RIP module 9 and a RIP failure detection notification module 10, respectively. It is. Since the constituent elements other than the RIP module 9 and the RIP failure detection notification module 10 are the same as those provided in the communication apparatus according to the first embodiment, description thereof will be omitted.

  The RIP module 9 is a module that performs layer 3 routing by RIP (Routing Information Protocol). When failure information is received from the failure location identification module 6, the RIP module 9 performs failure switching based on the received failure information (route table 7). Update).

  The RIP failure detection / notification module 10 generates a predetermined RIP packet based on the failure information output from the RIP module 9 in order to cause a communication device not applying the present invention to perform failure switching, and applies the present invention. Transmitting to other communication devices including communication devices that are not connected. The failure information output from the RIP module 9 is the IP address or MAC address of the device in which the failure has occurred.

  In the present embodiment, when a failure occurs in a device in the ERP network, any one of the devices to which the present invention is applied among the devices other than the device in which the failure has occurred is failed. By transmitting a packet indicating that the path from the generated device is invalid, the device to which the present invention is not applied is caused to perform fault switching. In the packet to be transmitted, for example, the metric to the failure occurrence device is 16. Metric 16 indicates unreachability in RIP. In the RIP, in the case of the operation according to the non-patent document 3, not all the route information advertised from each device other than the own device is held, and therefore all advertised route information is acquired. A procedure is required. For example, in the present embodiment, route information is collected in advance by holding all the route information advertised by each device in each device in a steady state before the failure occurs. Since the number of devices forming the ERP network is specified to be 256 or less, it is generally easy to maintain all path information.

  In addition, since a communication device that performs the operation according to Non-Patent Document 3 retains information on a device that uses the device as the next hop, the route information of the metric 16 is transmitted only for the information. It is also possible. However, according to this method, since all routes are not deleted, the processing time required for recovery of some routes is long, so it is recommended to use a method that retains all information.

  When there are a plurality of communication devices to which the present invention is applied in a device in which no failure has occurred, a packet indicating that the path from the device in which the failure has occurred is invalid is transmitted to another communication device. As a method of selecting one communication device, there is a method of exchanging information on the own bridge between communication devices to which the present invention is applied and selecting a transmission responsible device in advance. As another method, a method of performing fixed setting by an administrator or the like may be used, or any other method may be used.

  As described above, the communication device according to the present embodiment replaces the OSPF module 5 and the OSPF failure detection notification module 8 of the communication device according to the second embodiment with the RIP module 9 and the RIP failure detection notification module 10, respectively. Even when layer 3 routing is performed, layer 3 path switching can be performed at high speed as in the communication system of the second embodiment.

Embodiment 4 FIG.
FIG. 7 is a diagram illustrating a configuration example of a communication apparatus according to the fourth embodiment. The communication apparatus according to the present embodiment replaces the OSPF module 5, the path table 7, and the OSPF failure detection notification module 8 of the communication apparatus (see FIG. 5) described in the second embodiment with the VRRP module 11 and the VRRP failure detection notification module 12. It is a replacement. Since the components other than the VRRP module 11 and the VRRP failure detection notification module 12 are the same as those provided in the communication apparatus according to the first embodiment, description thereof is omitted.

  In the present embodiment, the communication apparatus forming the ERP network operates as a router, and the communication apparatus (communication apparatus to which the present invention is applied) shown in FIG. 7 and the communication apparatus to which the present invention is not applied are mixed. It is assumed that each communication device (router) forming the ERP network operates as one virtual router together with one or more other communication devices in accordance with VRRP (Virtual Router Redundancy Protocol).

  When receiving the failure information from the failure location specifying module 6, the VRRP module 11 determines whether or not the own device operates as a master router. When operating as a master router, routing control is performed.

  The VRRP failure detection notification module 12 causes the other communication device to perform re-selection of the master router (determination as to whether or not to operate as a master router), so that a predetermined VRRP is determined based on the failure information output from the VRRP module 11. A packet is generated and transmitted to other communication devices including a communication device to which the present invention is not applied. The failure information output from the VRRP module 11 is the IP address or MAC address of the device in which the failure has occurred.

  In the present embodiment, when a failure occurs in a device in the ERP network, any one of the devices to which the present invention is applied among the devices other than the device in which the failure has occurred is failed. By transmitting a packet indicating that the path from the generated device is invalid, the device to which the present invention is not applied is selected again. Specifically, a VRRP advertisement with Priority = 0 is transmitted. By transmitting the VRRP advertisement with Priority = 0, the communication device that has received this performs the master router selection operation. In VRRP, even if information of Priority = 0 is received a plurality of times, the operation is not affected. Therefore, when there are a plurality of devices to which the present invention is applied in the ERP network, a VRRP of Priority = 0 from a plurality of devices. An advertisement may be transmitted.

  As described above, the communication device according to the present embodiment forms an ERP network and a virtual router. When a device failure is detected in the ERP network, it is determined whether or not to operate as a master router (re-establishment of the master router). Selection), and VRRP advertisement with Priority = 0 is transmitted to other communication devices to re-select the master router. As a result, when a failure occurs in the communication device operating as the master router, the master router can be quickly switched, and the service stop time at the end-to-end can be shortened.

Embodiment 5 FIG.
FIG. 8 is a diagram illustrating a configuration example of a communication apparatus according to the fifth embodiment. The communication apparatus according to the present embodiment is obtained by replacing the OSPF module 5, the path table 7, and the OSPF failure detection notification module 8 of the communication apparatus (see FIG. 5) described in the second embodiment with an MLD-Proxy module 13. . Since the components other than the MLD-Proxy module 13 are the same as those provided in the communication apparatus according to the first embodiment, description thereof is omitted.

  In this embodiment, each communication device forming the ERP network operates as an MLD (Multicast Listener Discovery) proxy shown in Non-Patent Document 4, and the communication device shown in FIG. 8 (communication to which the present invention is applied). Assume a case in which communication devices that do not apply the present invention are mixed.

  In the communication device according to the present embodiment, the MLD-Proxy module 13 reselects the MLD querier according to the description of Non-Patent Document 4 when the failure generating device specified by the failure location specifying module 6 is an MLD querier. carry out.

  Here, in a communication device to which the present invention is not applied, failure detection based on a timer is performed, so that a failure occurs in a device selected as an MLD querier as described in Non-Patent Document 4. It takes a very long time to detect the failure. Therefore, after the communication device to which the present invention is applied performs the reselection of the MLD querier, the MLD querier is reselected after a while, and one failure occurs as shown in FIG. However, there is a possibility that the switching of the MLD querier occurs a plurality of times. However, when the MLD querier is selected for the second and subsequent times, the end-to-end multicast transmission stoppage does not occur. The stop time can be set to several hundred milliseconds, which is similar to that in the case of non-mixing (when an ERP network is formed only by communication devices to which the present invention is applied).

  In the example of the control operation (MLD querier selection operation) shown in FIG. 9, the communication device (communication device having the configuration shown in FIG. 8) to which the present invention is applied in the querier reselection (1) immediately after the ERP failure is detected. The one with the highest priority starts operating as a querier, and multicast packet relaying is resumed. After that, when a communication device that does not apply the present invention detects a failure according to the failure detection process defined in the MLD-Proxy protocol, querier reselection (2) is performed, and the communication device does not apply the present invention. The highest priority device starts the querier operation, but multicast packet relay stop does not occur. In FIG. 9, since the highest priority device is included among communication devices to which the present invention is not applied, the querier reselection (2) is performed to switch the querier (for a device to which the present invention is not applied). Among the devices to which the present invention is applied, the highest priority device starts its operation as a new querier and the highest priority device stops the querier operation). When the communication device having the highest priority is included in the communication devices, the querier reselection (2) does not cause switching of the querier.

  As described above, the communication apparatus according to the present embodiment operates as an MLD proxy, and when an apparatus failure is detected in the ERP network, the MLD querier is reselected. As a result, when a failure occurs in the MLD querier, the MLD querier can be switched quickly, and the service stop time at the end-to-end can be shortened.

Embodiment 6 FIG.
FIG. 10 is a diagram illustrating a configuration example of a communication apparatus according to the sixth embodiment. The communication apparatus according to the present embodiment replaces the OSPF module 5 and the OSPF failure detection notification module 8 of the communication apparatus (see FIG. 5) described in the second embodiment with the PIM-SM module 14 and the PIM-SM failure detection notification module 15. It is a replacement. Since the components other than the PIM-SM module 14 and the PIM-SM failure detection notification module 15 are the same as those provided in the communication apparatus of the first embodiment, description thereof is omitted.

  In the present embodiment, it is assumed that a communication device forming an ERP network relays a multicast packet according to a PIM-SM (Protocol Independent Multicast-Sparse Mode) protocol.

  The PIM-SM module 14 is a module for routing multicast packets by PIM-SM. When failure information is received from the failure location identification module 6, failure switching is performed as necessary based on the received failure information. (Update the routing table 7). The PIM-SM failure detection / notification module 15 causes the communication device not applying the present invention to perform failure switching when the PIM-SM module 14 determines that failure switching is necessary. A predetermined PIM-SM protocol packet is generated based on the failure information output from 14, and transmitted to other communication devices including a communication device to which the present invention is not applied.

  In PIM-SM, a forwarder responsible for relaying multicast packets and a representative router (DR) responsible for transmission of a PIM control message are selected in the same subnet. In the ERP network of the present embodiment, when a device failure occurs and the device in which the failure has occurred is a forwarder or a representative router, failure switching is performed according to the following procedure. If the device in which the failure has occurred is different from both the forwarder and the designated router, the failure does not affect the transmission of the multicast packet, and therefore the following processing is not necessary. In some cases, the device in which the failure has occurred is a forwarder and a representative router. In this case, both of the following two procedures are performed.

(Operation when the failed communication device is Forwarder)
In this case, in one of the communication devices to which the present invention is applied and no failure has occurred, the PIM-SM failure detection notification module 15 sets the preference and metric values of the communication device in which the failure has occurred A PIM-Assert packet with low priority is generated, and transmission is performed using the IP address of the device in which the failure occurred. Note that the IP address of the device in which the failure has occurred is notified from the PIM-SM module 14 to the PIM-SM failure detection notification module 15 as failure information. The values of preference and metric used in the PIM-Assert packet are values with lower priority than any of those set for each device forming the ERP network. Normally, it is not possible to know the preference and metric used by other devices, so it is desirable to use the lowest priority value within the range of preference and metric defined by the PIM-Assert protocol. However, the value is not limited to this, and other values may be used as long as the priority is sufficiently low and the above condition is satisfied. Note that the number of devices that transmit the packet is not limited to one in the ERP network, and two or more devices or all devices to which the present invention is applied may perform transmission processing.

(Operation when the failed communication device is the designated router)
In this case, in one of the communication apparatuses to which the present invention is applied and in which no failure has occurred, the PIM-SM failure detection notification module 15 has lowered the DR priority of the communication device in which the failure has occurred. A packet is generated and transmitted using the address of the device where the failure occurred. The priority value used in the Hello packet is set to a lower priority value than the value set in any device forming the ERP network. Normally, it is not possible to know the DR priority value used by other devices, so it is desirable to use the lowest priority value within the DP priority value range. However, the value is not limited to this, and other values may be used as long as the values are sufficiently low priority and satisfy the above conditions. Note that the number of devices that transmit the packet is not limited to one in the ERP network, and two or more devices or all devices to which the present invention is applied may perform transmission processing.

  As described above, the communication device of this embodiment performs routing of multicast packets by PIM-SM. When a device failure is detected in the ERP network, failure switching is performed when the detected device is a forwarder or a representative router. In addition to the implementation, the PIM-SM protocol packet for causing the communication device to which the present invention is not applied to perform fault switching is generated and transmitted. As a result, when a failure occurs in the PIM-SM Forwarder or the representative router, failure switching can be performed quickly, and the service stop time at the end-to-end can be shortened.

  Of the above-described embodiments, those applying the L3 protocol that can be used simultaneously in parallel may be combined. That is, Embodiments 2 and 3 cannot be combined, but other combinations are possible. For example, the VRRP module 11 and the VRRP failure detection notification module 12 included in the communication device (see FIG. 7) according to the fourth embodiment may be added to the communication device according to the second embodiment (see FIG. 5). Good.

  As described above, the communication apparatus according to the present invention is useful as a communication apparatus that forms an ERP network.

DESCRIPTION OF SYMBOLS 1 ERP module 2 Topology information collection module 3 Physical port 4 Topology information table 5 OSPF module 6 Failure location specific module 7 Path table 8 OSPF failure detection notification module 9 RIP module 10 RIP failure detection notification module 11 VRRP module 12 VRRP failure detection notification module 13 MLD-Proxy module 14 PIM-SM module 15 PIM-SM failure detection notification module 21 Link Trace Request transmission control unit 22 Link Trace Response monitoring unit 23 Topology information calculation unit 101 Link trace request 102 Link trace response

Claims (16)

A communication device forming a ring network,
ERP processing means for performing ERP control including failure detection of the ring network;
A topology information table in which topology information of the ring network is registered;
Topology information table update that collects identification information and position information of each communication device forming the ring network by monitoring the operation of the ERP processing means, and updates the topology information table based on the collected information Means,
When a failure is detected by the ERP processing means, it is determined based on the topology information table whether the detected failure corresponds to a device failure or a link failure. In the case of a device failure, a failure has occurred. A fault location identifying means for identifying the device and notifying the higher level protocol of the identified result;
A communication apparatus comprising: Topology information table update means
The ERP processing means receives a link trace response transmitted as a response to a link trace request that is defined in advance by the system and is set as an initial value with a TTL value shared by each communication device forming the ring network. Information acquisition means for acquiring the TTL value set in the received link trace response and the identification information of the transmission source device, and the information of the port that received the link trace response,
Based on the TTL value and port information acquired by the information acquisition means, the location of the transmission source device of the link trace response is specified, and the topology result table is associated with the identification result and the acquired identification information. A device location specifying means to be registered in
The communication apparatus according to claim 1, further comprising: Topology information table update means
When the own device is an RPL owner, the ERP is set so that a link trace request is transmitted by setting a TTL value defined in advance by the system and shared by each communication device forming the ring network. Transmission instruction means for instructing the processing means,
The communication apparatus according to claim 2, further comprising: The upper protocol is OSPF,
4. The communication apparatus according to claim 1, wherein the communication apparatus operates as a representative router of a communication system that performs L3 routing by OSPF. The upper protocol is OSPF,
When the failure detected by the ERP processing means is a device failure, a value indicating that the path cost to the failure generating device specified by the failure location specifying means is unreachable or no failure has occurred OSPF protocol packet transmission means for transmitting an OSPF protocol packet having a sufficiently large value compared to the path cost of the route to another communication device;
The communication device according to claim 1, further comprising: The upper protocol is RIP,
When the failure detected by the ERP processing means is a device failure, a value indicating that the metric to the failure generating device specified by the failure location specifying means is unreachable or a route where no failure has occurred ERP packet transmitting means for transmitting an ERP packet having a sufficiently large value compared to the metric of
The communication device according to claim 1, further comprising: The upper protocol is VRRP and a virtual router is formed with other communication devices forming the ring network,
VRRP packet transmitting means for transmitting a VRRP advertisement packet having a priority set to “0” to another communication device in the ring network when the failure detected by the ERP processing means is a device failure;
The communication device according to claim 1, further comprising: The upper protocol operates as MLD and MLD proxy,
An MLD querier reselecting means for performing an MLD querier reselection operation when the fault detected by the ERP processing means is a device fault and the device specified by the fault location specifying means is an MLD querier;
The communication device according to claim 1, further comprising: The upper protocol is PIM-SM,
When the failure detected by the ERP processing means is a device failure and the device specified by the failure location specifying means is a PIM-SM Forwarder, the preference and metric of the specified device are set to the ring network. A PIM-Assert packet transmitting means for transmitting a PIM-Assert packet set to a lower value than any other communication device in using the IP address of the identified device;
The communication device according to claim 1, further comprising: The upper protocol is PIM-SM,
When the failure detected by the ERP processing means is a device failure and the device specified by the failure location specifying device is a PIM-SM representative router, the DR priority of the specified device is the lowest. Hello packet transmission means for transmitting a Hello packet set to priority using the IP address of the identified device,
The communication apparatus according to claim 1, further comprising: A communication system that performs L3 routing with OSPF.
4. A communication system according to claim 1, wherein the communication device according to claim 1, 2 or 3 is an OSPF representative router, and an upper-layer protocol in which the failure point specifying means of the communication device notifies the specifying result is OSPF. A communication system that performs L3 routing with OSPF.
A communication system comprising one or more communication devices according to claim 5. A communication system that performs L3 routing by RIP,
A communication system comprising one or more communication devices according to claim 6.   A communication system comprising a virtual router formed by a plurality of communication devices including at least one communication device according to claim 7. A communication system that performs M3 L3 multicast control,
A communication system comprising at least one communication device according to claim 8 as a communication device that operates as an MLD proxy. A communication system for performing L3 multicast routing by PIM-SM,
A communication system comprising one or more communication devices according to claim 9 or 10.

Images