CN1968156A - Ethernet device link failure detection method and its system - Google Patents

Abstract

The present invention discloses a method and system for Ethernet equipment link fault detection, the method includes the following steps: a. The maintenance alliance end point MEP sends the fault message of the target MEP to other MEPs in the maintenance alliance MA, and the The target MEP information is carried in the message; b. The other MEP judges whether it is the MEP fault of the port through the target MEP information carried in the fault message, and if so, receives the fault message and performs related processing. Adopting the technical scheme of the present invention solves the problem of detecting equipment link failures in a P2MP network or a network with more than 2 MEP nodes in an MA, and can accurately locate which link among multiple link failures in a P2MP The problems that arise in the road, and the cooperation between various detection methods are opened up, and the end-to-end fault detection and fault location of the entire network are solved through the cooperation between various detection methods.

Description

Method and system for link fault detection of Ethernet equipment

technical field

The invention relates to the technical field of Ethernet, in particular, to the technology of equipment link fault detection in Ethernet.

Background technique

Due to its ease of use, low price, and continuous increase in bandwidth, Ethernet technology has been widely used in enterprise networks, metropolitan area networks, and wide area networks. However, the maintainability and operability of traditional Ethernet is relatively weak. As the scope of Ethernet promotion gradually expands, the demand for Ethernet OAM (Operations, Administration and Maintenance) functions is also becoming stronger.

The functions of Ethernet OAM are mainly divided into two parts: the physical link Ethernet OAM function, the physical link level Ethernet OAM function is used to realize the fault detection and notification function of the Ethernet physical link between two devices; Ethernet OAM function, business-level Ethernet OAM mainly implements end-to-end (such as between users and users, with multiple network devices in the middle) link connectivity management between devices.

Service Ethernet OAM mainly has the following functions:

Fault detection function: used to detect hardware faults (such as link and node faults) or software faults (such as software errors, memory crashes, configuration errors, etc.) at both ends;

Fault confirmation function: confirm the detected fault through the loopback (LoopBack) message, so as to take subsequent isolation measures;

Fault location and isolation function: After the fault is confirmed, the fault point (such as link, node) can be located, and then isolated from the network, so that the network can operate normally, and the fault can be diagnosed;

Fault notification and alarm suppression function: fault notification is used to inform the upstream and downstream of the node of the fault information, and the alarm suppression function is used to prevent a large number of notification messages in the network from causing network collapse.

The above functions of the Ethernet OAM need to be realized through the interaction of a series of OAM messages, and all messages are sent and received based on the maintenance domain.

The maintenance domain (MD Maintenance Domain) is a network or a part of the network involved in the Ethernet OAM function. It consists of a series of DSAPs (Domain Service Access Points), which provide Connectivity service, called MEP Maintenance Association End Point in MD, there may also be ISAP (Intermediate Service Access Point) inside the maintenance domain, which is the middle point from one DSAP to another DSAP Nodes are called MIP Maintenance Association Intermediate Points in MD, where MEP and MIP are collectively referred to as MPs, MEPs are the main initiator and receiver of Ethernet OAM messages, and MIPs are mainly used to forward Ethernet messages initiated by MEPs. Net OAM message. Specifying a service instance by MD also establishes a connectionless federation relationship between those MEPs. This relationship is called Maintenance Association (MA).

The schematic diagram of the maintenance domain is shown in Figure 1. There are 5 bridge devices and 6 DSAPs. These six DSAPs can be defined as MEPs respectively. The covered area (the gray part in Figure 1) is the maintenance domain. There are multiple ISAPs, these multiple ISAPs can be defined as MIPs respectively.

The Ethernet OAM mechanism supported by 802.1ag (a link layer protocol that provides a layer 2 link management) includes continuity check (Connectivity Check, cc), link tracking (Link Trace, LT), loopback detection (LoopBack, LB).

The LB is used to locate the fault location in the MA. The LBM (Loopback Message) is sent by the MEP, transparently transmitted to the destination MEP through the MIP, and the destination MEP responds with a response message LBR to the source MEP.

The LT is used to detect the MIP path passed between two MPs. The MEP sends an LTM (Link TraceMessage) to the destination MP through the MIP. Both the MP and the destination MP along the way will send a response message LTR to the source MEP.

The fault detection function is realized through the continuity check message (Connectivity Check Message, CCM). Each MEP of the MA periodically broadcasts a CCM message in its related service instance (such as S-VLAN). The MEP that receives the message updates the saved status of the peer MEP. If the peer MEP is not received within a period of time ( Each MEP saves the information of all MEPs related to the MA) sends a CCM message, considers that the other party is faulty or the link is faulty, reports the fault to the administrator and service user, and initiates the confirmation and confirmation of the fault automatically or initiated by the administrator. Locate/isolate process.

The MEP uses a timer to check whether the CCM message is lost. If the timer expires and the CCM message is not received, the message is considered lost. If three CCM messages are lost in a row, it is considered a fault and the follow-up processing is performed.

The existing CCM message format is shown in Table 1, where:

MD Level: MD level value, CCM packets with high Level value can penetrate MD with low Level value, on the contrary, CCM packets with low Level value will be discarded by MD with high Level value;

Version: version number;

OpCode: OAM message type, a total of 5 types, namely Continue check message, Loopback message, Loopback reply message, Linktrace message, Linktrace reply message;

Flag: The first bit is the RDI flag, and the last 3 bits are the lifetime flag;

First TLV offset: the offset of TLV;

Transaction identifier/Sequence Number: transaction identifier/sequence number

Maintenance association end point identifier: MEP identification code, whose value is the value of the MEPID of the sending end;

Maintenance domain name format: the format of the maintenance domain name, such as string or number;

Maintenance domain name length: the length of the maintenance domain;

Maintenance domain name: the name of the maintenance domain;

Maintenance association name format: maintain the format of the association name, such as string or number;

Maintenance domain name length: the length of the maintenance domain;

Maintenance domain name: the name of the maintenance domain;

Short MA Name Format: maintain alliance format;

Short MA Name Length: maintain the alliance length;

Short MA Name: maintenance alliance name;

remainder of MAID: reserved for MAID (MA name+MD name);

Reserved for use by Y.1731: Reserved for Y.1731;

Additional fields can be added, here, in future versions of the protocol: Reserved for later versions, other additional fields can be added;

Optional CCM TLVs: All TLVs of optional CCM;

End TLV: TLV terminator. 0 1 2 3 1 MDLevel Version OpCode Flags First TLV Offset 5 Transaction Identifier/Sequence Number 9 Maintenance association End PointIdentifier MaintenanceDomain NameFormat MaintenanceDomain NameLength 13 Maintenance Domain Name… 27+dnl Short MA Name Format Short MANameLength Short MA Name 57 (…remainder of MAID) 61 Reserved for use by Y.1731 65 69 73 77 (Additional fields can be added, here, in future version of the protocol) 5+FirstTLVOffset Optional CCM TLVs Last END TLV(0)

Table I

As shown in Table 1, the existing CCM message does not contain the information of the target MEP, but only carries the MEPID (MEP identification code) of the sending end. For P2P (point to point) networking, the fault notification can reach the peer end successfully, but for P2MP (point to multiple point point-to-multipoint) networking or for multiple MEPs in one MA, when the remote MEP When receiving a CCM message with RDI (Remote Defect Indication, remote fault detection), I don’t know whether the receiving end is myself, because the CCM is sent in multicast form, and any remote MEP in the MA can receive and send it The CCM message with RDI in the message does not carry any target MEP information, so the receiving end cannot determine whether the CCM with RDI is sent to itself.

Contents of the invention

The object of the present invention is to provide a method and system for detecting an Ethernet device link failure to solve the problem of detecting a device link failure in a P2MP network or a network with more than 2 MEP nodes in an MA.

To achieve the above object, the technical scheme adopted in the present invention is as follows:

A method for Ethernet equipment link fault detection, said method comprising the steps of:

a. The maintenance alliance endpoint MEP sends a fault message of the target MEP to other MEPs in the maintenance alliance MA, and the message carries target MEP information;

b. The other MEP receives the fault message, judges whether it is the MEP fault of the local port according to the target MEP information carried in the fault message, and if so, receives the fault message and performs related processing.

Wherein before step a also includes:

a0. The MEP does not receive the continuity detection CCM message sent by the target MEP within a specified time.

Wherein step a specifically includes:

a1. The MEP sends a remote fault detection RDI CCM message to other MEPs in the MA, and the CCM message carries the MEP identification code MEPID of the target MEP;

Wherein step b specifically includes:

b1. The other MEP extracts the target MEPID carried in the CCM message and compares it with the MEPID of the port, and if they are consistent, receives the CCM message and performs related processing.

Wherein step b also includes:

The other MEP receives the fault message, judges whether it is the MEP of the port that is faulty according to the target MEP information carried in the fault message, and discards the fault message if not.

The carrying of the information of the target MEP is realized by adding a TLV in the CCM message.

The Type value of the added TLV is a natural number other than 0-4.

The subtype value of the added TLV indicates a single-pass fault and/or conversion between different fault detection protocols.

More specifically, step b specifically includes:

b1. When the subtype value indicates a single-pass failure, the other MEP extracts the target MEPID carried in the CCM message and compares it with the MEPID of the port, and if they are consistent, receives the CCM message and Report alarm information.

The carrying of the information of the target MEP is realized by adding the MEPID of the target MEP at a fixed location in the CCM message.

The present invention also provides a system for detecting link failures of Ethernet equipment, the system includes the MA and the MEP therein, and the system also includes:

The MEP includes a fault message sending module capable of sending fault messages to other MEPs in the MA, and the message carries target MEP information;

The MEP includes a fault detection module capable of receiving fault messages sent by other MEPs and judging whether it is a fault of the MEP on the port according to the target MEP information in the fault message.

The information of the target MEP is the MEPID of the target MEP.

The fault detection module of the MEP can receive fault messages sent by other MEPs and compare the target MEPID in the fault messages with the MEPID of the port to determine whether the fault is caused by the MEP of the port.

The TLV in the fault information sent by the fault message sending module carries the information of the target MEP.

The fixed identifier in the fault information sent by the fault message sending module carries the information of the target MEP.

The TLV subtype subtype value in the fault information sent by the fault message sending module indicates a single-pass fault and/or conversion between different fault detection protocols.

The present invention overcomes the deficiencies in the prior art, and realizes the fault detection function through the continuity check message (CCM). The CCM message of the RDI is sent to the opposite end. The CCM carries the information of the target MEP. For a P2MP network or a network with multiple MEPs in the MA, the remote MEP receives the CCM message according to the information of the target MEP carried in it. information to determine whether the CCM message is sent to itself, and if so, perform related processing such as reporting a fault alarm, if not, discard the CCM message, and adopt the technical solution of the present invention to solve the problem of more than 2 CCM messages in P2MP networking or MA. The detection of equipment link failures in the networking of MEP nodes can accurately locate the specific link among the multiple link failures in P2MP, and open up the cooperation between various detection methods, through various The collaboration between detection methods solves the end-to-end fault detection and fault location of the entire network.

Description of drawings

Figure 1 is a schematic diagram of a maintenance domain;

Fig. 2 is a schematic diagram of the maintenance domain of the present invention;

Fig. 3 is a flowchart of Embodiment 1 of the present invention.

Detailed ways

The basic principle of the present invention is to implement the fault detection function through the continuity check message (CCM). If the MEP does not receive the CCM message sent by the peer MEP within a period of time, it considers that the link has failed, and the MEP sends a CCM with RDI message to the opposite end, the CCM carries the information of the target MEP. For a P2MP network or a network with multiple MEPs in the MA, the remote MEP judges the Whether the CCM message is sent to itself, if yes, perform related processing such as reporting a fault alarm, and if not, discard the CCM message.

A detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

Embodiment one

The remote MEP information is carried in by adding TLV (type length value type, length and value) to the CCM message

First, you need to define a TLV (remote MEP TLV) carrying the target MEPID. The definition is shown in Table 2:

Remote MFPID TLV Format 0 1 2 3 1 Type=5 Length MEPID Subtype

Table II

Among them, the type of TLV Type=5 (Type1 to 4 have defined different TLVs in the protocol, so define a TLV of Type=5 as the TLV carrying the MEPID of the target MEP, and the MEPID is the MEPID of the remote MEP to be notified , carry the Remote MEPID TLV in the CCM message. When the remote MEP receives the CCM with RDI, it will detect the TLV. Consistent, if it is, it means that the CCM with RDI is sent to itself, and finally according to the subtype subtype to distinguish what type of error is sent by the peer.

In order to distinguish different types of warning errors, subtype is defined as follows:

Subtype=1 single-pass definition, the sending end of the CCM message cannot receive the CCM message sent by the opposite end;

Subtype=2 is defined as a fault sent to the local CE by using 802.1ag after detecting a fault using 802.3ah (a slow protocol for link detection);

Subtype=3 is defined as adopting BFD (a protocol used to solve the fault between two adjacent forwarding engines) to detect the fault, and then adopting 802.1ag to send the fault to the remote CE;

Subtype supports extensions to subsequent protocols.

As shown in Figure 2, an MA called A is defined within the range of the dotted line, and OAM management is performed on A. Four MEP maintenance points, MEPA, MEPB, MEPC, and MEPD, are defined in the MA. During fault management, the four maintenance points will respectively send multicast CCM packets to the opposite end. Under normal circumstances, MEPA can receive normal CCM packets sent by MEPB, MEPC, and MEPD. At the same time, MEPB, MEPC, and MEPD can also receive Respectively receive the normal CCM message sent by the opposite end.

If MEPA can only receive the packets sent by MEPB and MEPC at this time, but cannot receive the CCM packets sent by MEPD, it means that the link between MEPA and MEPD is faulty. However, MEPD can normally receive the messages sent by MEPA, MEPB, and MEPC, so MEPD is not aware of it. At this time, MEPA needs to carry the RDI flag bit in the sent CCM multicast message to notify MEPD, and it needs to carry the target MEP (MEPD) The MEPID information, the sent message format is shown in Table 3:

0 1 2 3 1 MDLevel Version OpCode Flags First TLV Offset 5 Transaction Identifier/Sequence Number 9 1 MaintenanceDomain NameFormat Maintenance DomainName Length 13 Maintenance Domain Name… 27+dnl Short MAName Format Short MANameLength Short MA Name 57 (… remainder of MAID) 61 Reserved for use by Y.1731 65 69 73 77 (Additional fields can be added, here, in future version of the protocol) 5+FirstTLVOffset 5 4 4 1 Last END TLV(0)

Table 3

When MEPD receives above-mentioned CCM message, search wherein TLV, find that type is 5, then extract the value of wherein MEPID (its value is 4), the value of the MEPID of extracting is compared with the MEPID value of oneself, if equal then It is considered that the MEP of this port is faulty, and the subtype=1 is checked, and it is judged to be a one-way alarm, so an alarm is reported. But for MEPB and MEPC, after receiving this CCM message, detect the TLV therein, find that the type is 5, then extract the value of MEPID (its value is 4) wherein, combine the value of the MEPID of extracting with the value of the MEPID of oneself If the two are not equal, they are discarded directly.

The specific message flow is shown in Figure 3, specifically including the following steps:

1. MEPA sends the CCM multicast message carrying target MEP information to MEPB, MEPC and MEPD, wherein the target MEP information carried is the MEPID of MEPD (its value is 4), and MEPB, MEPC and MEPD receive the CCM message arts;

2. After receiving the CCM message, MEPB, MEPC and MEPD traverse and analyze the TLV types (Type) therein, and search for the TLV of Type=5;

3. Extract the MEPID value in the CCM (its value is 4), and compare the extracted MEPID value with the MEPID value of this port. If the two are equal, it is considered that the MEP of this port has failed, and go to step 4. Otherwise, directly CCM drop;

4. The MEPD checks the TLV in the CCM multicast message, and if subtype=1, it judges that it is a one-way alarm, and then reports an alarm.

The system described in this embodiment includes an ME and an MEP therein, and the MEP includes a fault message sending module capable of sending a fault message to other MEPs in the MA, and the message carries target MEP information;

The MEP includes a fault detection module, capable of receiving fault messages sent by other MEPs and judging whether the fault is caused by the MEP on the port according to the target MEP information in the fault message.

Wherein, the fault message sending module carries the MEPID (its value is 4) of the target MEP through the TLV in the CCM message, and the fault detection module of the MEP receives the fault message and compares the target MEPID in the fault message with the MEPID of this port, Determine whether the MEP on the port is faulty. The subtype value of the TLV is 1, indicating a single-pass failure.

Embodiment two:

If MEPA cannot receive the CCM message from MEPB and MEPD at the same time, it means that there is a one-way phenomenon between MEPA and MEPB, and between MEPA and MEPD. At this time, the format of the message sent by MEPA is shown in Table 4:

0 1 2 3 1 MDLevel Version OpCode Flags First TLV Offset 5 Transaction Identifier/Sequence Number 9 1 MaintenanceDomain NameFormat Maintenance DomainName Length 13 Maintenance Domain Name… 27+dnl Short MAName Format Short MANameLength Short MA Name 57 (…remainder of MAID) 61 Reserved for use by Y.1731 65 69 73 77 (Additional fields can be added, here, in future version of the protocol) 5+FirstTLVOffset 5 4 4 1 5 4 2 1 Last END TLV(0)

Table 4

When MEPD receives the above CCM message, it analyzes the message, traverses and analyzes the TLV, finds that Type is 5, finds that it carries MEPID=4, and subtype=1, and sends an alarm message accordingly, and at the same time After receiving this CCM message, MEPB also finds the RemoteMEP TLV with MEPID=2, checks subtype=1, and MEPB will report an alarm at the same time, but MEPC discards this CCM directly without alarming.

The system described in this embodiment includes an ME and an MEP therein, and the MEP includes a fault message sending module capable of sending a fault message to other MEPs in the MA, and the message carries target MEP information;

The MEP includes a fault detection module, capable of receiving fault messages sent by other MEPs and judging whether the fault is caused by the MEP on the port according to the target MEP information in the fault message.

Wherein, the fault message sending module carries the MEPID (its value is 4 and 2) of the target MEP by the TLV in the CCM message, and the fault detection module of the MEP receives the fault message and compares the target MEPID in the fault message with the MEPID of the port Compare them to determine whether the MEP on the port is faulty. The subtype value of the TLV is 1, indicating a single-pass failure.

Embodiment three

In addition to using the TLV in Embodiment 1 and Embodiment 2 to carry the target MEP in the CCM multicast message, it is also possible to use a fixed position to carry the information of the target MEP in the CCM message, and the MEPID of the fixed format can make the microcode The identification efficiency becomes higher. If TLV analysis is used, the microcode needs to calculate the offset of the message. If this field is fixed in the CCM message, the microcode can obtain the flag bit with a fixed offset, which can improve Microcode efficiency. At this time, the format of the CCM message is shown in Table 5. Additional fields in the table can be added. Here, Remote MEPID is added in the position of future versions of the protocol, and the information of the target MEP is carried through it. 0 1 2 3 1 MDLevel Version OpCode Flags First TLV Offset 5 Transaction Identifier/Sequence Number 9 Local MEPID MaintenanceDomain NameFormat MaintenanceDomain NameLength 13 Maintenance Domain Name… 27+dnl Short MA Name Format ShortMANameLength Short MA Name 57 (… remainder of MAID) 61 Reserved for use by Y.1731 65 69 73 Remote MEPID 77 (Additional fields can be added, here, in future version of the protocol) 5+FirstTLVOffset Optional CCM TLVs Last END TLV(0)

Table 5

The system described in this embodiment includes an ME and an MEP therein, and the MEP includes a fault message sending module capable of sending a fault message to other MEPs in the MA, and the message carries target MEP information;

The MEP includes a fault detection module, capable of receiving fault messages sent by other MEPs and judging whether the fault is caused by the MEP on the port according to the target MEP information in the fault message.

Wherein, the fault message sending module carries the MEPID of the target MEP through the fixed identifier in the CCM message, and the fault detection module of the MEP receives the fault message and compares the target MEPID in the fault message with the MEPID of the port to determine whether it is the The port MEP is faulty. The subtype value of the TLV is 1, indicating a single-pass failure.

Claims (15)

1, a kind of method of ethernet device link failure detection is characterized in that, described method comprises the steps:

A, Maintenance Association end points MEP other MEP in Maintenance Association MA send the failure message of target MEP, carry target MEP information in the described message;

B, described other MEP receive described failure message, judge whether it is the port MEP fault by the target MEP information of carrying in the described failure message, if then receive the described failure message line correlation of going forward side by side and handle.

2, method according to claim 1 is characterized in that, wherein also comprises before the step a:

A0, described MEP do not receive that in official hour the continuity that described target MEP sends detects CCM message.

3, method according to claim 1 is characterized in that, wherein step a specifically comprises:

A1, described MEP other MEP in described MA send the CCM message of far-end fault detect RDI, carry the MEP identification code MEPID of target MEP in the described CCM message;

Wherein step b specifically comprises:

The MEPID that b1, described other MEP extract the target MEPID that carries in the described CCM message and the port relatively, if both unanimities then receive the described CCM message line correlation of going forward side by side and handle.

4, method according to claim 1 is characterized in that, wherein step b also comprises:

Described other MEP receive described failure message, judge whether it is the port MEP fault by the target MEP information of carrying in the described failure message, if not, then described failure message is abandoned.

5, method according to claim 1 is characterized in that, described information of carrying target MEP is to realize by the increase TLV in CCM message.

6, method according to claim 5 is characterized in that, the type Type value of the TLV of described increase is the natural number outside 0 to 4.

7, method according to claim 5 is characterized in that, the subtype subtype value representation single-channel fault of the TLV by described increase and/or the conversion between the different faults detection protocol.

8, method according to claim 7 is characterized in that, wherein step b specifically comprises:

B1, when described subtype value representation single-channel fault, the MEPID that described other MEP extract the target MEPID that carries in the described CCM message and the port relatively, if both unanimities then receive described CCM message and report and alarm information, otherwise abandon described CCM message.

9, method according to claim 1 is characterized in that, described information of carrying target MEP is to realize by the increase fixed identifier in described CCM message.

10, a kind of system of ethernet device link failure detection, described system comprise MA and MEP wherein, it is characterized in that,

Described MEP comprises the failure message sending module, can send failure message by other MEP in described MA, carries target MEP information in the described message;

Described MEP comprises fault detection module, can receive the failure message of other MEP transmissions and judge whether it is the port MEP fault according to the target MEP information in the described failure message.

11, system according to claim 10 is characterized in that, the information of described target MEP is the MEPID of target MEP.

12, system according to claim 10, it is characterized in that, the fault detection module of described MEP can receive failure message that other MEP send and with the MEPID comparison of the target MEPID in the described failure message and the port, judge whether it is the port MEP fault.

13, system according to claim 10 is characterized in that, the information that the TLV in the fault message that described failure message sending module sends carries target MEP.

14, system according to claim 13 is characterized in that, TLV subtype subtype value representation single-channel fault in the fault message that described failure message sending module sends and/or the conversion between the different faults detection protocol.

15, system according to claim 10 is characterized in that, the information that fixed identifier is carried target MEP in the fault message that described failure message sending module sends.

Images