WO2012171380A1 - Far-end failure processing method and device for ethernet - Google Patents

Abstract

Disclosed are a far-end failure processing method and device for the Ethernet. The method includes: a second edge device accessing one end of a link receiving a first message sent by a first edge device accessing another end of the link, wherein the first message is sent by the first edge device when detecting that a first associated port associated therewith has failed and the first message carries the failure information about the first associated port; and the second edge device closing a second associated port associated with the second edge device according to the failure information about the first associated port and the physical state of the second associated port. By means of the present invention the edge device in the network can regularly detect a link failure and promptly notifies the peer edge device after detecting a failure, so that the peer edge device closes a port associated therewith according to the failure information and opens that port to retransmit data after the failed link is recovered.

Description

The present invention relates to the field of communications, and in particular to a method and apparatus for processing an Ethernet remote fault. BACKGROUND OF THE INVENTION Ethernet technology has been widely used in local area networks, metropolitan area networks, and wide area networks due to its advantages of simplicity, ease of use, and low cost. However, since Ethernet was originally designed for LAN, there is no mechanism for management and maintenance. With the gradual expansion of Ethernet applications, the operation, management, and maintenance (OAM) mechanism on Ethernet becomes inevitable. The development trend, the ETH-OAM (Ethernet OAM) protocol came into being, it can effectively improve the management and maintenance of Ethernet, and ensure the stable operation of the network. The Ethernet OAM mechanism mainly includes a link layer OAM mechanism and a service layer OAM mechanism (CFM, connectivity fault management). The ETH-OAM is an OAM mechanism for the direct link. It is mainly configured to manage and maintain the local link. It can provide functions such as remote discovery, remote loopback, remote fault indication, and link monitoring. Connection Fault Management (CFM) is mainly for carrier networks and uses a multi-domain network model. CFM enables end-to-end fault management. The network administrator divides the network into several nestable maintenance domains based on management and maintenance purposes. The network is defined by defining a series of maintenance points (MPs) on the maintenance domain. Management and maintenance. Through CFM, network administrators can effectively check, isolate, and report connectivity faults on virtual bridge LANs. The main functions of CFM are: connectivity check, loopback detection, link tracking, and alarms. A single CFM maintenance domain is shown in Figure 1. The maintenance domain in the figure defines a series of maintenance points on the edge device and internal devices. The W point indicates the maintenance end point (Maintenance End Point, 简称 for short). Indicates the Maintenance Intermediate Point (MIP). The service-based Ethernet OAM implements the management and maintenance functions through MEP and MIP. Currently, the Ethernet OAM mechanism can diagnose faults in the management domain and use corresponding mechanisms (such as Spanning-Tree Protocol (ST:P), EAPS, etc.) to take corresponding switching measures. To ensure the reliability of the network, but the fault detection and linkage mechanism for the uplink and downlink access links is lacking. For example, in some special application scenarios in the carrier network, when the uplink fails, the downlink becomes unavailable. However, since the uplink and downlink do not belong to the same network administrator, the uplink cannot be used. The failure of the link is notified to the downlink, causing the downlink to fail to respond to the failure in a timely manner. As shown in Figure 2, the network between E and F (including E and F) is the carrier network, A is the server, and B is the user who uses the service of A. If the link between A and E fails, AEFB This link can't communicate normally, and B can't continue to use A. Service, but since B cannot sense the link failure between A and E, even user B uses high availability (High

The availability, referred to as HA) mechanism, cannot be switched to the standby link, resulting in a large amount of data loss. The network administrator cannot find the fault in time and take corresponding measures. SUMMARY OF THE INVENTION The present invention provides a method and apparatus for processing an Ethernet remote fault to at least solve the above problems. According to an aspect of the present invention, a method for processing an Ethernet remote fault is provided, including: receiving, by a second edge device at one end of the access link, a first message sent by a first edge device at another end of the access link, The first message is sent by the first edge device when it detects that the associated first associated port is faulty, and the first message carries the fault information of the first associated port. The second edge device is configured according to the first associated port. The fault information and the physical state of the second associated port associated with the second edge device close the second associated port. Preferably, before the second edge device receives the message sent by the first edge device, the method further includes: the first edge device detecting that the first associated port associated with it fails, and sending the first message to the second edge device. Preferably, after the second edge device closes the second associated port, the method further comprises: the second edge device updating the physical state of the second associated port to a closed state. Preferably, after the second edge device receives the first message sent by the first edge device, the method includes: the second edge device generates fault alarm information. Preferably, after the second edge device closes the second associated port, the method further includes: the second edge device receiving the second message sent by the first edge device, where the second message is that the first edge device detects the first And the second message carries the fault recovery information of the first associated port; the second edge device opens according to the fault recovery information of the first associated port and the current physical state of the second associated port. The second associated port. Preferably, after the second edge device opens the second associated port, the method further comprises: the second edge device updating the physical state of the second associated port to an open state. Preferably, after the second edge device receives the second message sent by the first edge device, the method further includes: the second edge device generating fault recovery alarm information. According to another aspect of the present invention, a device for processing an Ethernet remote fault is provided, including: a receiving module, configured to receive a first message sent by a first edge device at another end of the access link, where The message is sent by the first edge device when detecting that the associated first associated port is faulty, and is carried in the first message. The fault information of the first associated port is configured to: close the second associated port according to the fault information of the first associated port and the physical state of the second associated port associated with the second edge device. Preferably, the receiving module is further configured to receive the second message sent by the first edge device, where the second message is sent by the first edge device when detecting the failure recovery of the first associated port, and the second message is carried in the second message. There is fault recovery information of the first associated port; the execution module is further configured to open the second associated port according to the fault recovery information of the first associated port and the physical state of the second associated port associated with the second edge device. Preferably, the foregoing apparatus further includes: an updating module, configured to update a physical state of the second associated port according to an operation performed by the execution module on the second associated port. Preferably, the foregoing apparatus further includes: an alarm module, configured to generate corresponding alarm information according to information carried in the message received by the receiving module. The invention solves the problem that the uplink or downlink fails in the prior art after the uplink or downlink fails in the prior art, and the uplink and downlink do not belong to the same network administrator. The problem of communication interruption, and thus the ability to detect faults in time and adopt corresponding isolation or recovery mechanism to avoid a large amount of data loss. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, In the drawings: FIG. 1 is a schematic diagram of a single CFM maintenance domain according to the related art; FIG. 2 is a schematic diagram of an application example when a link fails according to the related art; FIG. 3 is an Ethernet remote according to an embodiment of the present invention. Figure 4 is a schematic illustration of a one-to-many designation in accordance with a preferred embodiment of the present invention; Figure 5 is a schematic illustration of a ring network designation in accordance with a preferred embodiment of the present invention; Figure 6 is a preferred embodiment in accordance with the present invention. Schematic diagram of the format of the Interface Status TLV field of the connectivity check message (CCM frame); Figure 2 is a diagram showing the value of the Interface Status TLV field of a connectivity check message (CCM frame) in accordance with a preferred embodiment of the present invention; Figure 8 is a process flow diagram of a port state change message in accordance with a preferred embodiment of the present invention; Is a process flow diagram of a connectivity check message (CCM frame) in accordance with a preferred embodiment of the present invention; FIG. 10 is a port state transition diagram in accordance with a preferred embodiment of the present invention; FIG. 11 is an Ethernet remote fault in accordance with an embodiment of the present invention. FIG. 12 is a schematic structural diagram of an apparatus for processing an Ethernet remote fault according to a preferred embodiment of the present invention; and FIG. 13 is a schematic structural view of a preferred apparatus according to a preferred embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. FIG. 3 is a flowchart of a method for processing an Ethernet remote fault according to an embodiment of the present invention. As shown in FIG. 3, the method mainly includes the following steps (step S302-step S304): Step S302, accessing one end of the link The second edge device receives the first message sent by the first edge device at the other end of the access link, where the first message is sent by the first edge device when detecting that the associated first associated port is faulty, and A message carries the fault information of the first associated port. In the embodiment of the present invention, before the second edge device receives the message sent by the first edge device, the first edge device and the second edge device may be pre-arranged (where the first edge device is remote from the second edge device) Similarly, the second edge device is configured with a fault detection and isolation function relative to the first edge device. For example, in FIG. 2, the fault detection function can be configured on the edge device E, and the configured fault detection function is configured. Associate with port 1 (port l), configure isolation on edge device F, and associate fault isolation with port 2 (port 2). When edge device E detects the associated port (that is, portl) associated with it. In the event of a failure, a message is sent to the edge device F (the message carries the fault information of port1). Preferably, in a preferred embodiment of the present invention, after the second edge device receives the fault information sent by the first edge device, the second edge device may further generate fault alarm information. For example, in FIG. 2, the physical states of the associated ports port1 and port3 can be separately monitored on the edge device E (ie, the first edge device) and the F (ie, the second edge device) at both ends. For convenience, the network can be The end where the access link fails is called the designated end (that is, the edge device E of Figure 2), and the end (the opposite end) that needs to be fault-isolated is called the designated end (the edge device F of Figure 2). The specified method is not limited. It can be specified for one-way or two-way. Of course, if the condition allows, it can also be specified in multiple directions. In the embodiment of the present invention, the specified manner includes but is not limited to the following forms:

(1) One-way designation is shown in Figure 2. If only portl is required to be closed, port3 should be closed. Otherwise, portl does not need to be closed after port3 down. This case is a one-way designation. The designated end is fixed and unchanged. Therefore, fault detection can only be performed on the specified end. Fault isolation and recovery can only be performed on the designated end.

(2) Two-way designation In Figure 2, if portl is required to be closed, port3 should be closed, and portl should be closed after port3 down. This case is a two-way designation. For bidirectional designation, both ends can be used as designated ends. And the designated end, as long as one end detects a fault, it needs to be isolated at the other end.

(3) One-to-many designation As shown in Fig. 4, in the embodiment shown in Fig. 4, if port1 is required to be closed, port2, port3, and port4 are simultaneously closed, which is a one-to-many designation.

(4) The linkage designation is as shown in FIG. 4. In the embodiment shown in FIG. 4, if port2 is required to be down, portl is to be closed, and then port1 and port4 are simultaneously closed due to portl down. Linkage designation.

(5) Designation on the ring network FIG. 5 is a schematic diagram of a ring network application according to a preferred embodiment of the preferred embodiment of the present invention. In the ring network example shown in FIG. 5, after port1 is down, port 2, port 3, One or more of port4 are closed. Here, it should be noted that the above five embodiments can be used in combination. For the two-way designation (that is, both ends need to react to the fault of the peer end), the specified end and the designated end are relative, and the specified role and the designated role are determined after the fault occurs. When the physical state of an associated port changes, the peer (the first edge device) can be regarded as the designated end, and the peer end of the peer can be regarded as the designated end (the second edge device). After the state of the associated port 1 (port 1 ) is changed, the message carrying the fault information is sent to the peer end (the designated end) (for example, in the embodiment of the present invention, the message is a protocol frame), so as to reach the port. The failure notification of 1 is given to the designated end. Moreover, after receiving the message carrying the fault information sent by the designated end, the designated end may also generate fault alarm information. Step S304, the second edge device closes the second associated port according to the fault information of the first associated port and the physical state of the second associated port associated with the second edge device. In the implementation of the present invention, after the second edge device (the designated end) receives the message carrying the fault information from the first edge device (the designated end), according to the first associated port (for example, the port port1 associated with the designated end) The fault information and the physical state of the second associated port (eg, port port 2 associated with the designated end) close the second associated port (eg, port 2) for fault isolation purposes. Moreover, after the second edge device closes the second associated port, the second edge device may also update the physical state of the second associated port to a closed state. For example, in FIG. 2, the port may be updated (also referred to as migration). 2 (port 2) The physical state is off. Preferably, in a preferred embodiment of the present invention, after the second edge device closes the second associated port, if the first edge device detects failure recovery of its associated first associated port, the first edge device And sending, by the second edge device, a second message that carries the fault recovery information of the first associated port, the second edge device receives the second message sent by the first edge device, and then the second edge device recovers the information according to the failure of the first associated port. And opening a second associated port with the current physical state of the second associated port. After the second edge device receives the second message (carrying the fault recovery information) sent by the first edge device, the second edge device may further generate the fault recovery alarm information. Preferably, the second edge device may also be the second The physical status of the associated port is updated to the open state. For example, in Figure 2, the physical state of port 2 (port 2) can be updated (also referred to as migration). A preferred implementation of the implementation of the present invention will be specifically described below by taking an application example in the case where the link in FIG. 2 fails. The following three steps are mainly included: Step 1, on the edge devices E and F in FIG. Configure the basic CFM function and configure an UP type MEP to associate them with the edge ports port1 and port3 to be detected. In this case, check the relationship between E and F. The connectivity periodically sends a connectivity check message (CCM frame to the peer end, where the CCM frame includes

Interface Status TLV field, Interface Status The format of the TLV field is shown in Figure 6. When the fault detection and isolation function is configured for the remote end, the Interface Status TLV field in the CCM frame carries the status of the associated port. Step 2, for two-way The physical status of the associated port is monitored at the two ends. When the physical status of the port is changed, the end is the designated end. After the MEP of the local end monitors the change of the port status, set the Interface Status TLV field of the CCM frame to Corresponding values (where the value of the Interface Status TLV field is as shown in Figure 7) are advertised to the designated end; for unidirectional designation, only the state of the associated port needs to be monitored at the designated end, in a preferred implementation of the present invention. In the mode, the Interface Status TIN field uses the values of isUp, isDown, and isDormant, which represent the three port states: the physical state of the port is up, the physical state of the port is down, and the port is artificial because it needs to isolate the remote fault. Close, where the local MEP processes the port status change message. The process is shown in Figure 8, which includes the following steps:

5801. Receive a message from the interface management module.

5802: Determine the type of the message. If it is the shutdown command, go to S803. If it is physical up, go to S804. If it is physical down, go to S805.

5803. Determine whether the local port status is isDormant. If yes, go to S806. Otherwise, end the process.

5804. Determine whether the status of the local port is isUp. If yes, go to S807. Otherwise, the process ends.

5805. Determine whether the local port status is isDown. If yes, go to S808. Otherwise, end the process.

5806. The local port status is migrated to isDown, and the process ends.

5807, The local port status is migrated to isUp, and the process ends.

5808. The local port status is migrated to isDown, and the process ends. Step 3: After receiving the CCM frame, the edge device of the designated end may first check the Interface Status TLV field information carried by the edge device, and close or open the associated port according to the value of the Interface Status TLV field and the physical state of the associated port of the local end. The action of the fault isolation or fault recovery, and the corresponding alarms are generated, and the state of the associated port of the local end can be migrated (updated). The processing flow of the CCM frame is as shown in FIG. 9, and the process includes the following steps: S901. Receive, by the designated end, a CCM message.

5902. Determine whether the received CCM message carries the Interface Status TIN field. If yes, go to S903. Otherwise, go to S904.

5903. Determine the state of the Interface Status TIN field in the CCM message. If it is isUp, go to S904. If it is isDown, go to S905. If it is isDormant, the process ends.

5904. Determine whether the local port status is isDormant. If yes, go to S906. Otherwise, end the process.

5905. Determine whether the status of the local port is isUp. If yes, go to S907. Otherwise, the process ends.

5906, migrates the local port state to isUp, and physically raises the port up. S907, the local port state is migrated to isDormant, and the port is physically down. As shown in FIG. 10, FIG. 10 is a port state transition diagram according to a preferred embodiment of the present invention. The event causing port state transition and its meaning are as follows: el: Receives a CCM frame carrying port status is isDown. E2: Received a CCM frame carrying the port status as isUp, or the CFM function fails for some reason, or the CCM continuity is lost. E3: Configure the shutdown command for the associated port. E4: Physical down of the associated port (including the shutdown command). E5: Associated port physical up (including the result of the no shutdown command). The response when the port state is migrated is as follows: rl : Set the associated port state to isDormant to physically drop the associated port. R2: Set the associated port status to isUp to physically raise the associated port. R3 : Set the port status to isDown. R4: Set the associated port status to isUp. Among them, events other than el-e5 do not respond. The method for processing the remote fault of the Ethernet provided by the foregoing embodiment can detect the remote fault and isolate the fault at the local end. After the remote fault is eliminated, the local end can perform the recovery operation on the fault. You can notify the administrator to take appropriate action in time. In particular, if there is a backup link on the local end, you can quickly perform the switchover process to minimize data loss caused by remote faults. FIG. 11 is a schematic structural diagram of a device for processing an Ethernet remote fault according to an embodiment of the present invention. The device is located at a first edge device. As shown in FIG. 11, the device includes: a receiving module 10 and an executing module 20. The receiving module 10 is configured to receive a first message sent by the first edge device at the other end of the access link, where the first message is sent by the first edge device when detecting that the associated first associated port is faulty. And the first message carries the fault information of the first associated port; the executing module 20 is connected to the receiving module 10, and is configured to be configured according to the fault information of the first associated port and the second associated port associated with the second edge device. Physical state, close the second associated port. The receiving module 10 is further configured to receive the second message sent by the first edge device, where the second message is sent by the first edge device when detecting the failure recovery of the first associated port, and the second message is carried in the second message. There is fault recovery information of the first associated port; the executing module 20 may be further configured to open the second associated port according to the fault recovery information of the first associated port and the physical state of the second associated port associated with the second edge device. FIG. 12 is a schematic structural diagram of a device for processing an Ethernet remote fault according to a preferred embodiment of the present invention. The device is configured to implement the method for processing an Ethernet remote fault provided by the foregoing embodiment. As shown in FIG. 12, the device is further configured. The method may include: an alarm module 30 and an update module 40. The alarm module 30 is configured to generate corresponding alarm information according to the information carried in the message received by the receiving module. The updating module 40 is configured to update the second associated port according to the operation performed by the execution module on the second associated port. Physical state. FIG. 13 is a schematic structural diagram of a preferred apparatus according to a preferred embodiment of the present invention. As shown in FIG. 13, the preferred apparatus includes: a CFM unit 131, a driving unit 132, a transceiver unit 133, an interface management unit 134, an alarm unit 135, and Operation and maintenance unit 136. The CFM unit 131 is configured to operate the protocol and maintain a port state state machine, and can notify the local end fault, and can also detect the remote fault, and notify the driving unit 132 to perform fault isolation and fault recovery operations; The unit 132 is configured to close or open the port to implement fault isolation and fault recovery; the transceiver packet unit 133 is configured to send and receive a fault notification message; the interface management unit 134 is configured to periodically poll the associated port state, and The change information of the status of the associated port is notified to the CFM unit 131; the alarm unit 135 is configured to generate an alarm when detecting the remote fault or the remote fault recovery, and notify the network administrator; the operation and maintenance unit 136 is configured to receive the configuration command of the user. And issued to the relevant unit. The remote end fault processing device provided by the foregoing embodiment can detect the remote fault and isolate the fault at the local end. After the remote fault is eliminated, the local end can perform the recovery operation on the fault. You can notify the administrator to take appropriate action in time. In particular, if there is a backup link on the local end, you can quickly perform the switchover process to minimize data loss caused by remote faults. From the above description, it can be seen that the present invention achieves the following technical effects: The method and device for processing an Ethernet remote fault are used to solve the uplink or downlink failure in the prior art due to uplink The problem that the road and the downlink do not belong to the same network manager and the communication is interrupted, avoids the effect of a large amount of data loss. The edge device in the network can detect the link fault periodically, and notify the edge device of the peer end after detecting the fault, so that the edge device of the peer end closes the port associated with it according to the fault information, and opens the link after the link fault is recovered. The port thus retransmits the data. Obviously, those skilled in the art should understand that the above modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device, such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein. The steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps are fabricated as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Claims

1. A method for processing an Ethernet remote fault, including:  The second edge device at one end of the access link receives the first message sent by the first edge device at the other end of the access link, where the first message is that the first edge device detects the association When the first associated port is faulty, the first message carries the fault information of the first associated port;  The second edge device closes the second associated port according to the fault information of the first associated port and the physical state of the second associated port associated with the second edge device. The method according to claim 1, wherein, before the second edge device receives the message sent by the first edge device, the method further includes:  The first edge device detects that the first associated port associated with it fails, and sends the first message to the second edge device. The method according to claim 1, wherein after the second edge device closes the second associated port, the method further comprises: the second edge device locating the physical of the second associated port The status is updated to the off state. The method according to claim 1, wherein after the second edge device receives the first message sent by the first edge device, the method includes: the second edge device generating fault alarm information. The method according to any one of claims 1 to 4, wherein after the second edge device closes the second associated port, the method further includes:  The second edge device receives the second message sent by the first edge device, where the second message is sent by the first edge device when detecting the failure recovery of the first associated port, and The second message carries fault recovery information of the first associated port;  The second edge device opens the second associated port according to the fault recovery information of the first associated port and the current physical state of the second associated port. The method according to claim 5, wherein, after the second edge device opens the second associated port, the method further comprises: the second edge device locating the physical of the second associated port The status is updated to open. The method according to claim 5, wherein, after the second edge device receives the second message sent by the first edge device, the method further includes: generating, by the second edge device, a fault recovery Alarm information. A device for processing an Ethernet remote fault, the second edge device at one end of the access link, comprising: a receiving module, configured to receive the first edge sent by the first edge device at the other end of the access link a message, where the first message is sent by the first edge device when it detects that the associated first associated port is faulty, and the first message carries the fault information of the first associated port. And an execution module, configured to close the second associated port according to the fault information of the first associated port and the physical state of the second associated port associated with the second edge device. The device according to claim 8, wherein the receiving module is further configured to receive a second message sent by the first edge device, where the second message is that the first edge device detects The fault is recovered when the first associated port is recovered, and the second message carries the fault recovery information of the first associated port.  The execution module is further configured to open the second associated port according to the failure recovery information of the first associated port and the physical state of the second associated port associated with the second edge device. The device according to claim 8 or 9, wherein the device further comprises: an update module, configured to update the second associated port according to an operation performed by the execution module on the second associated port Physical state. The device according to claim 8 or 9, wherein the device further comprises:  The alarm module is configured to generate corresponding alarm information according to the information carried in the message received by the receiving module.