CN1968156A - Ethernet device link failure detection method and its system - Google Patents
Ethernet device link failure detection method and its system Download PDFInfo
- Publication number
- CN1968156A CN1968156A CNA2006100623949A CN200610062394A CN1968156A CN 1968156 A CN1968156 A CN 1968156A CN A2006100623949 A CNA2006100623949 A CN A2006100623949A CN 200610062394 A CN200610062394 A CN 200610062394A CN 1968156 A CN1968156 A CN 1968156A
- Authority
- CN
- China
- Prior art keywords
- mep
- message
- target
- fault
- ccm
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
Abstract
The invention relates to a method for checking the chain accidence of Ethernet device, and relative system, wherein said method comprises that; a, maintain end MEP sends accidence message of target MEP to other MEP of maintain coalition MA; the message contains target MEP information; b, other MEP via said target MEP information judges if it is local port MEP accidence; if it is, receiving the accidence message and treat. The invention can solve the problem that over two MEP nodes have chain accidence in P2MP network or MA, to position the accident chain accurately.
Description
Technical field
The present invention relates to the ethernet technology field, specifically, relate to the technology of device link fault detect in the Ethernet.
Background technology
Ethernet technology has all obtained large-scale application because of it is simple and easy to can improve constantly with, cheap and bandwidth in enterprise network, metropolitan area network and wide area network scope.It is more weak that but ability can be safeguarded, can be runed to traditional ethernet, the scope of promoting along with Ethernet enlarges gradually, demand to Ethernet OAM (Operations, Administration and Maintenance Operations, Administration and Maintenance) function is also more and more stronger.
The function of Ethernet OAM mainly is divided into two parts: physical link Ethernet OAM function, the Ethernet OAM function of physical link level are used to realize the fault detect and the informing function of two Ethernet physical links between the equipment; Professional Ethernet OAM function, the connectivity of link management between the equipment that the Ethernet OAM of service level mainly realizes end-to-end (between the user, a plurality of network equipments can be passed through in the centre as the user).
Professional Ethernet OAM mainly contains following function:
Fault detection capability: the hardware fault (as link, node failure) or the software fault (as software error, internal memory collapse, configuration error etc.) that are used to detect two ends;
Fault recognition function: by loopback (LoopBack) message detected fault is confirmed, so that take follow-up quarantine measures;
Fault location and isolation features: after fault is identified, can position, then it be isolated from network,, and diagnosing malfunction be handled so that network can normally move to fault point (as link, node);
Signalling trouble and alarm inhibit feature: signalling trouble is used for fault message is informed to the upstream and downstream of node that the alarm inhibit feature is used for preventing that network from a large amount of notification messages occurring and causing periods of network disruption.
The above-mentioned functions of Ethernet OAM need be by the realizing of a series of OAM message alternately, and all message is based on all that maintenance field sends and receive.
Maintenance field (MD Maintenance Domain) is the involved network of Ethernet OAM function or certain part in the network, it is made up of a series of DSAP (Domain Service Access Point territory Service Access Point), it provides connectivity services to the inside in territory, in MD, be called Maintenance Association end node (MEP Maintenance Association End Point), also may there be ISAP (Intermediate Service Access Point intermediary service access point) in maintenance field inside, it is intermediate node from a DSAP to another DSAP, in MD, be called Maintenance Association intermediate node (MIPMaintenance Association Intermediate Point), wherein MEP and MIP are referred to as MP, MEP is the main promoter and the recipient of Ethernet OAM message, and MIP is used to transmit the Ethernet OAM message that MEP initiates.The connectionless alliance that MD specifies a Service Instance also just to set up between those MEP concerns that this relation is called Maintenance Association MA (Maintenance Association).
The schematic diagram of maintenance field as shown in Figure 1, wherein have 5 bridge devices and 6 DSAP, these six DSAP just can be defined as MEP respectively, and the zone of covering (grey color part among Fig. 1) is exactly maintenance field, there are a plurality of ISAP in the centre, and these a plurality of ISAP just can be defined as MIP respectively.
The Ethernet OAM mechanism that (802.1ag a kind of link layer protocol provides a kind of management of two layers of link) supported comprise continuity check (Connectivity Check, cc), link tracing (Link Trace, LT), loopback detection (LoopBack, LB).
LB is used in MA fault location position, sends LBM (Loopback Message) by MEP, is transparent to purpose MEP through MIP, and responds response message LBR by purpose MEP to source MEP.
LT is used to detect the MIP path of being passed through between two MP, sends LTM (Link TraceMessage) by MEP, arrives purpose MP through MIP, and MP and purpose MP will be toward source MEP return response message LTR on the way.
(Connectivity Check Message CCM) realizes fault detection capability by continuity check message.Each MEP of MA periodically broadcasts CCM message at its relevant Service Instance (as S-VLAN), the MEP that receives message upgrades the state of the opposite end MEP that is preserved, if do not receive the CCM message that opposite end MEP (each MEP preserves the information of all relevant MEP of MA) sends in a period of time, then think the other side's fault or link occurs fault, give keeper and service-user with Trouble Report, and initiate or initiate the affirmation and the location/isolation processes of fault automatically by the keeper.
MEP checks whether lose CCM message by a timer, and timer expiry is also confiscated CCM message, then thinks this information drop-out, if lost 3 CCM message continuously, then thinks and breaks down, and carries out subsequent treatment then.
Existing C CM message format as shown in Table 1, wherein:
The level value of MD Level:MD, the CC of high Level value
MMessage can penetrate the MD of low Level, on the contrary, and the CC of low Level
MMessage will be abandoned by the MD of high Level;
Version: version number;
The type of message of OpCode:OAM, is respectively Continue check message, Loopback message, Loopback reply message, Linktrace message, Linktrace reply message by totally 5 kinds;
Flag: first bit is the RDI flag bit, and last 3 bit are the lifetime flag bit;
The side-play amount of First TLV offset:TLV;
Transaction identifier/Sequence Number: transaction identifiers/sequence number
Maintenance association end point identifier:MEP identification code, its value is the value of the MEPID of transmitting terminal;
Maintenance domain name format: the form of maintenance field title, such as character string forms or digital form;
Maintenance domain name length: the length of maintenance field;
Maintenance domain name: the title of maintenance field;
Maintenance association name format: the form of Maintenance Association title, such as character string forms or digital form;
Maintenance domain name length: the length of maintenance field;
Maintenance domain name: the title of maintenance field;
Short MA Name Format: Maintenance Association form;
Short MA Name Length: Maintenance Association length;
Short MA Name: Maintenance Association title;
Remainder of MAID: for MAID (MA name+MD name) keeps;
Reserved for use by is Y.1731: be Y.1731 to keep;
Additional fields can be added, here, in future versions of the protocol:, can add other extra fields for the version reservation of back;
Optional CCM TLVs: all TLV of optional CCM;
End TLV:TLV terminal character.
0 | 1 | 2 | 3 | ||
1 | MD Level | Version | OpCode | Flags | |
5 | Transaction Identifier/Sequence Number | ||||
9 | Maintenance association End Point Identifier | Maintenance Domain Name Format | Maintenance Domain Name Length | ||
13 | Maintenance Domain Name … | ||||
27+dnl | Short MA Name Format | Short MA Name Length | 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+First TLV Offset | Optional CCM TLVs | ||||
Last | END TLV(0) |
Table one
As shown in Table 1, do not have the information of target MEP in the existing C CM message, only carry the MEPID (MEP identification code) of transmitting terminal.For P2P (point to point is point-to-point) networking, signalling trouble can successfully arrive the opposite end, but for P2MP (point to multiple point point-to-multipoint) networking or for the situation that a plurality of MEP are arranged in the MA, when far-end MEP receives band RDI (Remote DefectIndication, do not know whether receiving terminal is oneself during the far-end fault detect) CCM message, because CCM sends with the multicast form, any far-end MEP in MA can both receive the CCM message of the band RDI that sends over, do not carry the information of any target MEP in the message again, whether issue oneself so receiving terminal can't be judged the CCM of the band RDI that sends over.
Summary of the invention
The object of the present invention is to provide a kind of method and system thereof of ethernet device link failure detection, with the detection problem of the device link fault that solves the networking that surpasses 2 MEP nodes in P2MP networking or the MA.
For achieving the above object, the technical solution used in the present invention is as follows:
A kind of method of ethernet device link failure detection, 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.
Wherein also comprise before the step a:
A0, described MEP do not receive that in official hour the continuity that described target MEP sends detects CCM message.
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.
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.
Described information of carrying target MEP is to realize by the increase TLV in CCM message.
The type Type value of the TLV of described increase is the natural number outside 0 to 4.
The subtype subtype value representation single-channel fault of TLV by described increase and/or the conversion between the different faults detection protocol.
More specifically, 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.
Described information of carrying target MEP is that the MEPID by the target MEP of the increase fixed position in described CCM message realizes.
The present invention also provides a kind of system of ethernet device link failure detection, and described system comprises MA and MEP wherein, and described system also comprises:
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.
The information of described target MEP is the MEPID of target MEP.
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.
The information that TLV in the fault message that described failure message sending module sends carries target MEP.
The information that fixed identifier is carried target MEP in the fault message that described failure message sending module sends.
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.
The present invention overcomes the deficiencies in the prior art, (CCM) realizes fault detection capability by continuity check message, if MEP does not receive the CCM message that opposite end MEP sends in a period of time, then think link occurs fault, MEP sends the CCM message of band RDI to the opposite end, carry the information of target MEP among the described CCM, for the situation that a plurality of MEP networkings are arranged in P2MP networking or the MA, far-end MEP judges according to the information of the target MEP that wherein carries whether this CCM message sends to oneself after receiving CCM message, if then report relevant treatment such as fault warning, if not, then CCM message is abandoned, adopt technical scheme of the present invention, solved the detection problem of the device link fault of the networking that surpasses 2 MEP nodes in P2MP networking or the MA, can accurate in locating go out the problem that concrete which the bar link in a plurality of link failures occurs in the P2MP, and get through the cooperation between each detection method, solve the fault detect and the fault location of whole net end to end by the cooperation between the various detection methods.
Description of drawings
Fig. 1 is the maintenance field schematic diagram;
Fig. 2 is a maintenance field schematic diagram of the present invention;
Fig. 3 is the embodiment of the invention one flow chart.
Embodiment
Basic principle of the present invention is to realize fault detection capability by continuity check message (CCM), if MEP does not receive the CCM message that opposite end MEP sends in a period of time, then think link occurs fault, MEP sends the CCM message of band RDI to the opposite end, carry the information of target MEP among the described CCM, for the situation that a plurality of MEP networkings are arranged in P2MP networking or the MA, far-end MEP judges according to the information of the target MEP that wherein carries whether this CCM message sends to oneself after receiving CCM message, if then report relevant treatment such as fault warning, if not, then CCM message is abandoned.
Be elaborated below in conjunction with the drawings and specific embodiments.
Embodiment one
Employing is added the mode of TLV (type length value type, length and value) far-end MEP information is carried in CCM message
At first need to define a TLV (remote MEP TLV) who carries target MEPID, define as shown in Table 2:
Remote MFPID TLV Format
0 | 1 | 2 | 3 | |
1 | Type=5 | Length | MEPID | |
Subtype |
Table two
Wherein, (Type1 to 4 has defined different TLV respectively to the type Type=5 of TLV in agreement, therefore the TLV that defines a Type=5 is as the TLV that carries the MEPID of target MEP, MEPID is the MEPID that needs the far-end MEP of notice, this Remote MEPID TLV is carried in the CCM message, when far-end MEP receives the CCM of band RDI, detect TLV, when detecting the TLV of Type=5, take out MEPID, judge whether this MEPID is consistent with the MEPID of the port MEP, issue oneself if the CCM of this band RDI then is described, what at last distinguish that the opposite end sends according to subtype subtype again is the mistake of what type.
In order to distinguish dissimilar alarm mistakes, subtype is defined as follows:
The definition of Subtype=1 single-pass, the CCM message source can not receive the CC that the opposite end sends
MMessage;
After Subtype=2 is defined as and adopts 802.3ah (a kind of slow agreement of link detecting) detection failure, adopt 802.1ag to send to the fault of local terminal CE;
Subtype=3 adopts 802.1ag to send to far-end CE fault after being defined as and adopting BFD (with the agreement that solves the fault between adjacent two forwarding engines) detection failure;
Subtype supports the expansion of follow-up agreement.
As shown in Figure 2, defined a MA who is referred to as A in the dotted line scope, A has been carried out the OAM management.MEPA, MEPB, four MEP maintenance points of MEPC, MEPD in MA, have been defined respectively.Can send multicast CCM message respectively to the opposite end on four maintenance points during fault management, under normal circumstances MEPA can receive the normal CCM message that MEPB, MEPC, MEPD send over, and MEPB, MEPC, MEPD also can receive the normal CCM message that the opposite end sends over respectively simultaneously.
If this moment, MEPA can only receive the message that MEPB and MEPC send over, and can't receive the CCM message that MEPD sends over, illustrate that MEPA problem occurred to the link between the MEPD.But MEPD can normally receive the message that MEPA, MEPB, MEPC send over, so MEPD discover less than, need this moment MEPA in the CCM multicast message that sends, to carry the RDI flag bit and notify MEPD, and wherein need to carry the information of the MEPID of target MEP (MEPD), the message format of transmission as shown in Table 3:
0 | 1 | 2 | 3 | |||
1 | MD Level | Version | OpCode | Flags | First TLV Offset | |
5 | Transaction Identifier/Sequence Number | |||||
9 | 1 | Maintenance Domain Name Format | Maintenance Domain Name Length | |||
13 | Maintenance Domain Name… | |||||
27+ dnl | Short MA Name Format | Short MA Name Length | 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+ First TLV Offset | 5 | 4 | 4 | |||
1 | ||||||
Last | END TLV(0) |
Table three
When MEPD receives above-mentioned CCM message, search TLV wherein, find that type is 5, then extract the wherein value of MEPID (its value is 4), with the value of the MEPID that extracts and the MEPID value of self relatively, if equal then think that fault has appearred in the port MEP, inspection subtype=1, judgement is the alarm of single-pass, so report and alarm.But for MEPB and MEPC, received the TLV that detects behind this CCM message wherein, found that type is 5, then extracted the wherein value of MEPID (its value is 4), with the value of the MEPID that extracts and the value comparison of the MEPID of self, two kinds unequal, then directly abandons.
Concrete message flow specifically comprises the steps: as shown in Figure 3
1, MEPA send carry target MEP information the CCM multicast message to MEPB, MEPC and MEPD, wherein entrained target MEP information is the MEPID of MEPD (its value is 4), MEPB, MEPC and MEPD receive described CCM message;
2, after MEPB, MEPC and MEPD received described CCM message, traversal was resolved TLV type (Type) wherein, searches the wherein TLV of Type=5;
3, extract the value (its value is 4) of MEPID among the CCM, with the MEPID value of the value of the MEPID that extracts and the port relatively, think that fault has appearred in the port MEP if both are equal, commentaries on classics step 4, otherwise directly CCM is abandoned;
4, MEPD checks the TLV in the CCM multicast message, subtype=1 wherein, and judgement is the alarm of single-pass, so report and alarm.
The described system of present embodiment comprises ME and MEP wherein, and MEP comprises the failure message sending module, can send failure message by other MEP in MA, carries target MEP information in the described message;
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.
Wherein, the failure message sending module carries the MEPID (its value is 4) of target MEP by the TLV in the CCM message, the fault detection module of MEP receives failure message and with the MEPID comparison of the target MEPID in the described failure message and the port, judges whether it is the port MEP fault.The subtype value of TLV is 1, the expression single-channel fault.
Embodiment two:
If MEPA can not receive simultaneously the CCM message of MEPB and MEPD, illustrate between MEPA and the MEPB, the single-pass phenomenon has all appearred between MEPA and the MEPD, the message format of MEPA transmission this moment as shown in Table 4:
0 | 1 | 2 | 3 | |||
1 | MD Level | Version | OpCode | Flags | First TLV Offset | |
5 | Transaction Identifier/Sequence Number | |||||
9 | 1 | Maintenance Domain Name Format | Maintenance Domain Name Length | |||
13 | Maintenance Domain Name… | |||||
27+ dnl | Short MA Name Format | Short MA Name Length | 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+ First TLV Offset | 5 | 4 | 4 | |||
1 | ||||||
5 | 4 | 2 | ||||
1 | ||||||
Last | END TLV(0) |
Table four
When MEPD receives above-mentioned CCM message, this message is resolved, TLV is traveled through parsing, finding Type is 5 o'clock, MEPID=4 is carried in discovery, and subtype=1 sends a warning message in view of the above, and simultaneously MEPB receives the RemoteMEP TLV that has also found MEPID=2 behind this CCM message, check subtype=1, simultaneously MEPB also can report and alarm, but MEPC directly abandoned when receiving this CCM, can not alarm.
The described system of present embodiment comprises ME and MEP wherein, and MEP comprises the failure message sending module, can send failure message by other MEP in MA, carries target MEP information in the described message;
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.
Wherein, the failure message sending module carries the MEPID (its value is 4 and 2) of target MEP by the TLV in the CCM message, the fault detection module of MEP receives failure message and with the MEPID comparison of the target MEPID in the described failure message and the port, judges whether it is the port MEP fault.The subtype value of TLV is 1, the expression single-channel fault.
Embodiment three
Except in the CCM multicast message, adopting the TLV among embodiment one and the embodiment two to carry the target MEP, the also information that can in CCM message, adopt the fixed position to carry target MEP, MEPID by set form can make the recognition efficiency of microcode uprise, if adopt TLV to resolve, microcode need calculate the side-play amount of message, if adopt this field is fixed up in the CCM message, microcode can the constant offset amount obtain this flag bit, can improve microcode efficient, the CCM message format as shown in Table 5 at this moment, Additional fields can be added in table, here, in future versionsof the protocol position increases Remote MEPID, carries the information of target MEP by it.
0 | 1 | 2 | 3 | ||
1 | MD Level | Version | OpCode | Flags | First TLV Offset |
5 | Transaction Identifier/Sequence Number | ||||
9 | Local MEPID | Maintenance Domain Name Format | Maintenance Domain Name Length | ||
13 | Maintenance Domain Name … | ||||
27+dnl | Short MA Name Format | Short MA Name Length | 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+First TLV Offset | Optional CCM TLVs | ||||
Last | END TLV(0) |
Table five
The described system of present embodiment comprises ME and MEP wherein, and MEP comprises the failure message sending module, can send failure message by other MEP in MA, carries target MEP information in the described message;
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.
Wherein, the failure message sending module carries the MEPID of target MEP by the fixed identifier in the CCM message, the fault detection module of MEP receives failure message and with the MEPID comparison of the target MEPID in the described failure message and the port, judges whether it is the port MEP fault.The subtype value of TLV is 1, the expression single-channel fault.
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.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100623949A CN100550785C (en) | 2006-08-30 | 2006-08-30 | A kind of method of ethernet device link failure detection and system thereof |
PCT/CN2007/001551 WO2008028385A1 (en) | 2006-08-30 | 2007-05-14 | Method and apparatus of ethernet device link fault detection |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2006100623949A CN100550785C (en) | 2006-08-30 | 2006-08-30 | A kind of method of ethernet device link failure detection and system thereof |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1968156A true CN1968156A (en) | 2007-05-23 |
CN100550785C CN100550785C (en) | 2009-10-14 |
Family
ID=38076719
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2006100623949A Expired - Fee Related CN100550785C (en) | 2006-08-30 | 2006-08-30 | A kind of method of ethernet device link failure detection and system thereof |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN100550785C (en) |
WO (1) | WO2008028385A1 (en) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101820368A (en) * | 2010-04-08 | 2010-09-01 | 华为技术有限公司 | Ethernet link failure detection method and device |
CN101222370B (en) * | 2008-02-01 | 2010-09-22 | 华为技术有限公司 | Method and device for failure location using failure location packet |
CN101207529B (en) * | 2007-11-22 | 2010-12-01 | 杭州华三通信技术有限公司 | Method for link circuit fault detection and recovery based on PMD and corresponding apparatus |
CN101904134A (en) * | 2007-10-12 | 2010-12-01 | 北方电讯网络有限公司 | Mohan dinesh [ca]; unbehagen paul [us]; keesara srikanth [in] |
CN102164051A (en) * | 2011-05-18 | 2011-08-24 | 西安交通大学 | Service-oriented fault detection and positioning method |
CN102651702A (en) * | 2012-05-09 | 2012-08-29 | 华为技术有限公司 | Ethernet performance measurement method and equipment |
CN101771583B (en) * | 2009-12-30 | 2012-11-28 | 中兴通讯股份有限公司 | Method and device for detecting elimination or no elimination of network failure |
US8488475B2 (en) | 2007-11-26 | 2013-07-16 | Supcon Group Co., Ltd. | Fault processing method, system and exchanging device based on industry ethernet network |
CN103684887A (en) * | 2013-12-31 | 2014-03-26 | 杭州华三通信技术有限公司 | Method and equipment for generating connectivity fault detection network system hardware table entry |
US9571383B2 (en) | 2011-11-16 | 2017-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Rerouting technique |
CN108234234A (en) * | 2016-12-21 | 2018-06-29 | 瞻博网络公司 | Using modified Ethernet connectivity fault management signaling to avoid deadlock |
CN109547229A (en) * | 2017-09-21 | 2019-03-29 | 中兴通讯股份有限公司 | A kind of Ethernet fault handling method and device |
CN111698119A (en) * | 2020-05-07 | 2020-09-22 | 深圳市普威技术有限公司 | Communication module, control method thereof and communication equipment |
CN112714006A (en) * | 2019-10-24 | 2021-04-27 | 中兴通讯股份有限公司 | Link fault state notification method, device, equipment and medium |
CN115242736A (en) * | 2022-07-15 | 2022-10-25 | 杭州云合智网技术有限公司 | Transmission method of light load message |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110247797A (en) * | 2019-06-04 | 2019-09-17 | 深圳市中航比特通讯技术有限公司 | One kind accurate Remote Defect when multiple spot ETH is connected to indicates system |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6772376B1 (en) * | 2000-11-02 | 2004-08-03 | Dell Products L.P. | System and method for reporting detected errors in a computer system |
CN100499485C (en) * | 2004-04-08 | 2009-06-10 | 华为技术有限公司 | Maintaining method of Ethernet link state |
US7855968B2 (en) * | 2004-05-10 | 2010-12-21 | Alcatel Lucent | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network |
CN100403698C (en) * | 2006-08-08 | 2008-07-16 | 华为技术有限公司 | Method and apparatus for testing ethernet connection damage |
-
2006
- 2006-08-30 CN CNB2006100623949A patent/CN100550785C/en not_active Expired - Fee Related
-
2007
- 2007-05-14 WO PCT/CN2007/001551 patent/WO2008028385A1/en active Application Filing
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101904134A (en) * | 2007-10-12 | 2010-12-01 | 北方电讯网络有限公司 | Mohan dinesh [ca]; unbehagen paul [us]; keesara srikanth [in] |
US8918538B2 (en) | 2007-10-12 | 2014-12-23 | Rockstar Consortium Us Lp | Automatic MEP provisioning in a link state controlled ethernet network |
US9059918B2 (en) | 2007-10-12 | 2015-06-16 | Rpx Clearinghouse Llc | Continuity check management in a link state controlled ethernet network |
CN101207529B (en) * | 2007-11-22 | 2010-12-01 | 杭州华三通信技术有限公司 | Method for link circuit fault detection and recovery based on PMD and corresponding apparatus |
US8488475B2 (en) | 2007-11-26 | 2013-07-16 | Supcon Group Co., Ltd. | Fault processing method, system and exchanging device based on industry ethernet network |
CN101222370B (en) * | 2008-02-01 | 2010-09-22 | 华为技术有限公司 | Method and device for failure location using failure location packet |
CN101771583B (en) * | 2009-12-30 | 2012-11-28 | 中兴通讯股份有限公司 | Method and device for detecting elimination or no elimination of network failure |
CN101820368A (en) * | 2010-04-08 | 2010-09-01 | 华为技术有限公司 | Ethernet link failure detection method and device |
CN102164051A (en) * | 2011-05-18 | 2011-08-24 | 西安交通大学 | Service-oriented fault detection and positioning method |
CN102164051B (en) * | 2011-05-18 | 2013-11-06 | 西安交通大学 | Service-oriented fault detection and positioning method |
US9571383B2 (en) | 2011-11-16 | 2017-02-14 | Telefonaktiebolaget Lm Ericsson (Publ) | Rerouting technique |
CN104067575B (en) * | 2011-11-16 | 2017-04-19 | 瑞典爱立信有限公司 | Rerouting technique |
CN102651702A (en) * | 2012-05-09 | 2012-08-29 | 华为技术有限公司 | Ethernet performance measurement method and equipment |
CN103684887B (en) * | 2013-12-31 | 2017-01-04 | 杭州华三通信技术有限公司 | A kind of method and apparatus connecting the generation of error detection group network system hardware table item |
CN103684887A (en) * | 2013-12-31 | 2014-03-26 | 杭州华三通信技术有限公司 | Method and equipment for generating connectivity fault detection network system hardware table entry |
CN108234234A (en) * | 2016-12-21 | 2018-06-29 | 瞻博网络公司 | Using modified Ethernet connectivity fault management signaling to avoid deadlock |
CN109547229A (en) * | 2017-09-21 | 2019-03-29 | 中兴通讯股份有限公司 | A kind of Ethernet fault handling method and device |
CN112714006A (en) * | 2019-10-24 | 2021-04-27 | 中兴通讯股份有限公司 | Link fault state notification method, device, equipment and medium |
CN111698119A (en) * | 2020-05-07 | 2020-09-22 | 深圳市普威技术有限公司 | Communication module, control method thereof and communication equipment |
CN111698119B (en) * | 2020-05-07 | 2023-05-16 | 深圳市联洲国际技术有限公司 | Communication module, control method thereof and communication equipment |
CN115242736A (en) * | 2022-07-15 | 2022-10-25 | 杭州云合智网技术有限公司 | Transmission method of light load message |
CN115242736B (en) * | 2022-07-15 | 2024-04-12 | 云合智网(上海)技术有限公司 | Light load message transmission method |
Also Published As
Publication number | Publication date |
---|---|
CN100550785C (en) | 2009-10-14 |
WO2008028385A1 (en) | 2008-03-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1968156A (en) | Ethernet device link failure detection method and its system | |
CN1913496A (en) | Conversion control method and system of OAM message | |
CN100344132C (en) | Method for assuring automatic protecting system regular service of Ethernet | |
CN1086531C (en) | Multi-processor environments | |
CN1992638A (en) | Method and system for obtaining path maximum transmission unit in network | |
CN1838620A (en) | Method for detecting chain circuit fault between end-to-end notes in mixed network | |
CN1610312A (en) | Method for providing guaranteed distributed failure notification | |
CN101030901A (en) | Distributed Ethernet system and method for inspecting fault based thereon | |
EP1978670A3 (en) | Method and device for reliable broadcast | |
CN101601228B (en) | Fault localisation in multiple spanning tree based architectures | |
CN1905483A (en) | Method and apparatus for testing ethernet connection damage | |
CN1859371A (en) | Method for checking flow engineering link time slot state consistency | |
CN1467958A (en) | Apparatus and method of searching for dns server in outernet | |
CN102057731A (en) | Method of establishing a wireless multi-hop network | |
CN1925435A (en) | Method for obtaining chain circuit evaluating method | |
CN1921477A (en) | Method and system for complicated flow classification of arrange cutted piece message | |
CN1885799A (en) | Method for rapidly detecting Ethernet exchanger loop failure | |
CN101056194A (en) | A SNMP message transfer method and device | |
CN1905488A (en) | Method and system for access user by virtual router redundance protocol | |
CN101060485A (en) | Topology changed messages processing method and processing device | |
CN1855840A (en) | Method for network management device to obtain log data from network element | |
CN1571326A (en) | Apparatus and method for retransmitting data packets in mobile ad hoc network environment | |
JP2008059114A (en) | Automatic network monitoring system using snmp | |
CN1921432A (en) | Message transmitting method and device | |
CN1855851A (en) | Continuity inspection method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20091014 Termination date: 20170830 |