CN100446470C - Method for realizing operation and maintenance of wind-band ethernet network - Google Patents
Method for realizing operation and maintenance of wind-band ethernet network Download PDFInfo
- Publication number
- CN100446470C CN100446470C CNB2006100332163A CN200610033216A CN100446470C CN 100446470 C CN100446470 C CN 100446470C CN B2006100332163 A CNB2006100332163 A CN B2006100332163A CN 200610033216 A CN200610033216 A CN 200610033216A CN 100446470 C CN100446470 C CN 100446470C
- Authority
- CN
- China
- Prior art keywords
- end mep
- message
- far
- mep
- receiving
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Abstract
The present invention relates to a method for realizing operation and maintenance of wind-band Ethernet network, which solves the problem that network fault can not be recognized when the fault happens before the first CC message comes in the prior art. In the present invention, when receiving the first CC message sent by source end MEP, remote end MEP can feed back a response message. After sending the first CC message to the remote end MEP, the source end MEP can judge whether the response message fed back from the remote end MEP is received in prearranged time: if true, current network is judged faultless and subsequent CC message is sent at fixed time to realize the continuity test. If the feedback of the remote end MEP is not received, the source end MEP reports alarm, and sequentially, sends announce message to the remote end MEP in prearranged time interval. If the announce response message fed back from the remote end MEP is received, the current network is judged faultless, and the subsequent CC message is sent at the fixed time to realize the continuity test. The method of the prevent invention can ensure that the network fault can be recognized after the continuity test is started.
Description
Technical field
The present invention relates to the broadband ethernet technology, more particularly, relate to a kind of broadband ethernet operation and maintenance implementation method.
Background technology
At ETHER (Ethernet) OAM (Operation and Maintenance, operation and maintenance), carrying out standardization effort now, up-to-date standard is " IEEE P802.1ag/D3.0 Apirl12.2005 ", " IEEE P802.1ag/D4.1August 18,2005 ", " IEEE P802.1ag/D5.0November 16.2005 " and " IEEE P802.1ag/D5.2 December 6,2005 ".ETHEROAM mainly comprises CC (Continuity Check, continuity detects), LB (Loopback, loopback) and LT technology such as (Link trace, link tracings).
In ETHER OAM CC mechanism, mainly be by source end MEP (Maintenance AssociationEnd Point, the maintenance association end points) timed sending does not have the CC message of response, far-end MEP (also claiming can be place end MEP) regularly detects the CC message that whether receives from the source end, judges whether whole network path exists fault.When source end MEP stops the continuity measuring ability, can in last CC message, add sign and notify far-end MEP.
In " IEEE P802.1ag/D3.0Apirl 12.2005 ", employing be the implementation of " far-end MEP starts continuity to source end MEP and detects from receiving first CC start of heading ".But there is very big defective in this scheme, as shown in Figure 1, if before starting the continuity detection network failure has taken place, because what send is to send the CC message that does not have response, source end MEP can't know whether the CC message of its transmission arrives far-end MEP, and far-end MEP does not in fact receive the CC message yet, does not detect so can not start continuity; Consequently source end MEP and far-end MEP can't identify the network failure that has existed.Rectangular patterns among Fig. 1 is MEP, and pattern of oval shapes is MIP (Maintenance AssociationIntermediate Point, a maintenance association intermediate point); The left side is source end MEP, and the right side is far-end MEP.
At " IEEE P802.1ag/D4.1 August 18,2005 " in, aforementioned schemes is revised, wherein safeguard a state machine at source end MEP, be the MEP Continuity Check InitiatorState Machine (the MEP continuity detects promoter's state machine), it is mainly used in the transmission of execution cycle CC message and the transmission of 3 terminal CC messages; Safeguard two state machines at far-end MEP, i.e. theRemote MEP State Machine (far-end MEP state machine) and MEP Terminal CCM ReceiverState Machine (MEP stops CC message accepting state machine).During work, far-end MEP preceding state machine regularly detects the arrival of first CC message and the arrival of follow-up CC message, if do not receive CC message, then report and alarm in official hour; The state machine in back then is used for suppressing the preceding state report on board after receiving terminal CC message alert, because the preceding state machine will not receive the CC message certainly when normally stopping the continuity detection, but be not answer report and alarm at this moment, so need to suppress its report and alarm function; After receiving normal CC message, a back state machine will stop the inhibition to the preceding state machine, make it can recover the report and alarm function.
As if the standard of latest edition has solved when fault arrives prior to first CC message can't discern the problem of existing network failure, but anatomize, and the scheme of this newest standards does not still settle the matter once and for all.For example, after source end MEP has sent terminal CC message constantly at T, temporarily stopped the continuity measuring ability, far-end MEP will suppress the generation of alarm according to the terminal CC message of receiving; If source end MEP recovers the continuity measuring ability constantly again at T+N, sent the CC message again, but fault occurred and cause far-end MEP not receive the CC message this moment, because its report and alarm function is suppressed, so it can be because of not receiving CC message report and alarm, that is to say that can't identify network failure this moment.
Summary of the invention
At the above-mentioned defective of prior art, the present invention will solve the problem that can't discern existing network failure in the existing continuity detection technique when fault arrives prior to first CC message, to guarantee can correctly identifying network failure after starting continuity detects.
The technical solution adopted for the present invention to solve the technical problems is: a kind of broadband ethernet operation and maintenance implementation method is provided, and wherein, far-end MEP should return a response message when the first CC message of receiving that source end MEP sends; For realizing that continuity detects, and handles according to the following steps:
(S1) end MEP in source sends first CC message to far-end MEP, starts continuity and detects;
(S2) end MEP in source judges whether to receive in the given time the response message of far-end MEP passback; If then enter step (S3), otherwise jump to step (S4)
(S3) judge the current network fault-free, and the follow-up CC message of timed sending, get back to described step (S2) then;
(S4) report and alarm, then,
(S41) end MEP in source sends notification packet to far-end MEP on schedule at interval, and waits for that receiving far-end MEP is receiving the announce response message that returns behind this notification packet;
(S42) if do not receive described announce response message then get back to described step (S41), if receive described announce response message then jump to described step (S3).
In the step (S41) of the method for the invention: described source end MEP can send notification packet to all far-end MEP by broadcast mode, and waits for that receiving that far-end MEP corresponding with purpose MEPID is receiving the unicast response message that returns behind this notification packet.
In the step (S41) of the method for the invention: described source end MEP can search corresponding MAC Address according to purpose MEPID, and send notification packet with mode of unicast to far-end MEP, and wait for that receiving this far-end MEP is receiving the unicast response message that returns behind this notification packet according to the MAC Address that finds.
By technique scheme, can solve the problem that when fault arrives prior to first CC message, can't discern existing network failure, thereby can correctly identify network failure after guaranteeing to start the continuity detection.
Description of drawings
The invention will be further described below in conjunction with drawings and Examples, in the accompanying drawing:
Fig. 1 is a schematic diagram of having sent out network failure between source end MEP and the far-end MEP;
Fig. 2 is the flow chart in a preferred embodiment of the invention;
Fig. 3 is the schematic diagram of the CC far-end transmit status machine in a preferred embodiment of the invention.
Embodiment
By aforementioned analysis as can be known, be because " the CC message that does not have response " just caused discerning the generation of existing this problem of network failure in essence.Initial period in that the continuity measuring ability activates, preferably can allow source end MEP know whether far-end MEP has correctly received first CC message.
As shown in Figure 2, in a preferred embodiment of the present invention, at first should determine following rule, (1) far-end MEP should return a response message when the first CC message of receiving that source end MEP sends; (2) end MEP in source can send notification packet to far-end MEP, and far-end MEP should return an announce response message when receiving the notification packet that source end MEP sends.For realizing that continuity detects, and can handle according to the following steps:
Earlier send first CC message to far-end MEP, start the continuity measuring ability by source end MEP; Far-end MEP should reply corresponding response message after receiving this first CC message;
Then, end MEP in source judges whether to receive in the given time that far-end MEP is receiving the response message that returns behind the described first CC message;
If source end MEP receives the response message of far-end MEP passback in the given time, then judge the current network fault-free, and the follow-up CC message of timed sending detects to realize continuity;
If source end MEP fails to receive in the given time the response message that far-end MEP returns, then report and alarm; Start cycle timer simultaneously, Controlling Source end MEP sends notification packet to far-end MEP on schedule at interval, and waits for that receiving far-end MEP is receiving the announce response message that returns behind this notification packet; If do not receive response message, then send notification packet repeatedly at described notification packet; If receive at the response message of described notification packet then judge the current network fault-free, and the follow-up CC message of timed sending detects to realize continuity.
In the embodiment shown in Figure 2, source end MEP searches corresponding MAC Address according to purpose MEPID, and send notification packet with mode of unicast to far-end MEP, and wait for that receiving this far-end MEP is receiving the unicast response message that returns behind this notification packet according to the MAC Address that finds.
During concrete enforcement, source end MEP can also send notification packet to all far-end MEP by broadcast mode, and waits for that receiving that far-end MEP corresponding with purpose MEPID is receiving the unicast response message that returns behind this notification packet.
As shown in Figure 3, in a preferred embodiment of the present invention, source end MEP safeguards a CC far-end transmit status machine in the initial period that the continuity measuring ability activates to each the far-end MEP that is disposed, and its complete realization comprises following described three parts.
State description:
(1) state CCRS_IDLE: init state;
(2) state CCRS_WAITING_SETUP: wait for the state that far-end MEP responds;
(3) state CCRS_FAILED_SETUP: far-end MEP responds the state of failure;
(4) state CCRS_OK: source end MEP has received the state from the back message using of far-end MEP, and expression this moment can be carried out follow-up continuity and detect.
Event Description:
(1) incident CCRSenabled: expression starts the continuity measuring ability, and the generation of this incident can defined incident be to obtain among MEPactive and the CCIenabled from standard; When MEPactive and CCIenabled were true, CCRSenabled was that true promptly takes place; Among Fig. 3 "! CCRSenabled " then expression cancelled the continuity measuring ability;
(2) incident CCRSrevd: response message has been received in expression, and this incident does not exist in existing standard, is to increase newly in the present embodiment, and when receiving the receiveing the response of far-end MEP (unicast packet), CCRSrevd is that true promptly takes place; Among Fig. 3 "! CCRSrevd " then expression do not receive response message.
The state machine explanation:
(1) state CCRS_IDLE receives incident CCRSenabled: state becomes CCRS_WAITING_SETUP, start waiting timer simultaneously, the rMEPtime value that time span (being the CCRSinterval value) suggestion equals to define in the standard of overflowing of this timer adds 1 second;
(2) state CCRS_WAITING_SETUP receives incident CCRSrevd: state becomes CCRS_OK;
(3) state CCRS_WAITING_SETUP receives incident! CCRSenabled: the continuity measuring ability has been cancelled in expression, and state becomes CCRS_IDLE.
(4) state CCRS_WAITING_SETUP receives that timer overflows incident: state becomes CCRS_FAILED_SETUP, on the one hand, needs to carry out CCRSFaultAlarm () report and alarm; On the other hand, need to start cycle timer, regularly send the notification packet of purpose MEPID, promptly carry out CCRSPeriodSend () operation to far-end MEP;
(5) state CCRS_FAILED_SETUP receives incident! CCRSenabled: state becomes CCRS_IDLE, and report and alarm recovers (promptly reverting to the normal condition that alarm does not take place), stops simultaneously sending the unicast inquiry message to far-end MEP;
(6) state CCRS_FAILED_SETUP receives incident CCRSrevd: state becomes CCRS_OK, and report and alarm recovers, and stops simultaneously sending the unicast inquiry message to far-end MEP;
(7) state CCRS_OK receives incident! CCRSenabled: state becomes CCRS_IDLE.
(8) CCRSwhile=CCRSinterval: see Fig. 3, when " CCRS_WAITING_SETUP " state, the CCRSwhile initialization equals CCRSinterval (this value can be passed through configuration settings).
(9) CCRSwhile=0: when " CCRS_WAITING_SETUP " state, CCRSwhile can constantly subtract one by timer then, equal zero or receive CCRSrevd incident (far-end echo is received in expression) until CCRSwhile, " CCRS_FAILED_SETUP " or " CCRS_IDLE " gets the hang of respectively.
(10) CCRSFaultAlarmRestore (): when entering " CCRS_WAITING_SETUP " state, carry out " CCRSFaultAlarmRestore () " and " CCRSPeriodSend () ", promptly " send alarm " and " sending CC " to the opposite end.
(11) CCRSStopPeriodSend (): when " CCRS_WAITING_SETUP " state, receive " CCRSrevd " incident, carry out " CCRSStopPeriodSend () ", promptly " stop to send CC ".
When state CCRS_WAITING_SETUP receives that timer overflows incident, need to carry out " notification packet that regularly sends purpose MEPID " operation to far-end MEP.For finishing this operation, following two kinds of possibilities are arranged:
The first adopts broadcasting announcement mode, and promptly target MAC (Media Access Control) address is a broadcast address.This scheme need not be known the MAC Address of purpose MEPID correspondence; Adopt the shortcoming of broadcast mode to be, the reception of most of MEP is useless, and the reception of having only a MEP is effective.
It two is to adopt clean culture announcement mode, when adopting this mode, at first need to inquire about MEP database, to check whether purpose MEPID exists corresponding MAC Address, if there is no, then when timer overflows incident, continue inquiry next time, when inquiring corresponding MAC Address, just send the clean culture notification packet according to this MAC Address.
During concrete enforcement, suggestion adopts second kind of scheme to realize the announcement of purpose MEPID.Regularly announcing purpose MEPID, mainly is the problem that solves alarm clearing.A kind of situation is, certain bar link has broken between far-end MEP and the local terminal MEP, the basic CC message of just not receiving local terminal of far-end MEP, behind the link failure recovery, alarm just recovers (directly corresponding states CCRS_FAILED_SETUP receives incident CCRSrevd) naturally; Another kind of situation is, far-end MEP has sent the clean culture back message using after receiving first CC message of local terminal MEP, but owing to various hit reasons soft, hardware make local terminal MEP not receive back message using, thereby the alarm that produces local terminal, and this moment local terminal MEP because the CC message of far-end MEP sends the MAC Address of having learnt purpose MEPID, send purpose MEPID notification packet by local terminal, after far-end MEP responded this message, alarm was recovered.
For realizing above-mentioned functions, need in existing standard, increase a kind of OpCode type, i.e. ContinuityCheck Remote Notification Message (continuity detects the far-end notification packet), and contain the TLV that purpose is announced MEPID in the message.MIP does not deal with this OpCode type.
In order to realize above-mentioned state machine,, also need under existing standard, increase by two functions below the realization for the receiving terminal MEP (being far-end MEP) that continuity detects.
(1), needs to respond the unicast response message for the CC message that receives for the first time;
(2), need to respond the unicast response message for the CC notification packet of receiving.
Equally, need increase a kind of OpCode type in existing standard, i.e. Continuity CheckRemote Notification Reply Message (continuity detect far-end announce response message) also contains the TLV of search purposes MEPID in the message.MIP does not deal with this OpCode type yet.
Claims (3)
1, a kind of broadband ethernet operation and maintenance implementation method is characterized in that, wherein, far-end MEP should return a response message when the first CC message of receiving that source end MEP sends; For realizing that continuity detects, and handles according to the following steps:
(S1) end MEP in source sends first CC message to far-end MEP, starts continuity and detects;
(S2) end MEP in source judges whether to receive in the given time that far-end MEP is receiving the response message that returns behind the described first CC message; If then enter step (S3), otherwise jump to step (S4);
(S3) judge the current network fault-free, and jump to step (S5);
(S4) report and alarm, then,
(S41) end MEP in source sends notification packet to far-end MEP on schedule at interval, and waits for that receiving far-end MEP is receiving the announce response message that returns behind this notification packet;
(S42) if do not receive described announce response message then get back to described step (S41), if receive described announce response message then jump to step (S5);
(S5) the follow-up CC message of timed sending detects to realize continuity.
2, method according to claim 1 is characterized in that, in described step (S41):
Described source end MEP sends notification packet with broadcast mode to all far-end MEP, and waits for that receiving that far-end MEP corresponding with purpose MEPID is receiving the unicast response message that returns behind this notification packet.
3, method according to claim 1 is characterized in that, in described step (S41):
Described source end MEP searches corresponding MAC Address according to purpose MEPID, and sends notification packet with mode of unicast to far-end MEP according to the MAC Address that finds, and waits for that receiving this far-end MEP is receiving the unicast response message that returns behind this notification packet.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100332163A CN100446470C (en) | 2006-01-19 | 2006-01-19 | Method for realizing operation and maintenance of wind-band ethernet network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100332163A CN100446470C (en) | 2006-01-19 | 2006-01-19 | Method for realizing operation and maintenance of wind-band ethernet network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1852166A CN1852166A (en) | 2006-10-25 |
| CN100446470C true CN100446470C (en) | 2008-12-24 |
Family
ID=37133636
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2006100332163A Expired - Fee Related CN100446470C (en) | 2006-01-19 | 2006-01-19 | Method for realizing operation and maintenance of wind-band ethernet network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100446470C (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101174975B (en) * | 2006-11-03 | 2010-05-12 | 华为技术有限公司 | Periodic line fault location method and system in Ethernet |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1578234A (en) * | 2003-07-29 | 2005-02-09 | 华为技术有限公司 | Detecting method for Link routine state |
| CN1681254A (en) * | 2004-04-08 | 2005-10-12 | 华为技术有限公司 | Maintaining method of Ethernet link state |
| US20050249119A1 (en) * | 2004-05-10 | 2005-11-10 | Alcatel | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network |
| CN1697401A (en) * | 2004-05-10 | 2005-11-16 | 阿尔卡特公司 | Remote access link fault indication mechanism |
-
2006
- 2006-01-19 CN CNB2006100332163A patent/CN100446470C/en not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1578234A (en) * | 2003-07-29 | 2005-02-09 | 华为技术有限公司 | Detecting method for Link routine state |
| CN1681254A (en) * | 2004-04-08 | 2005-10-12 | 华为技术有限公司 | Maintaining method of Ethernet link state |
| US20050249119A1 (en) * | 2004-05-10 | 2005-11-10 | Alcatel | Alarm indication and suppression (AIS) mechanism in an ethernet OAM network |
| CN1697401A (en) * | 2004-05-10 | 2005-11-16 | 阿尔卡特公司 | Remote access link fault indication mechanism |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1852166A (en) | 2006-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN100499485C (en) | Maintaining method of Ethernet link state | |
| EP2698948A1 (en) | Method and device for determining failure elimination based on oam protocol | |
| CN101262401B (en) | A method for realizing network recovery in loop network | |
| CN1953400A (en) | A method to control the continuity detection of Ethernet link | |
| WO2008031347A1 (en) | Method and apparatus for realizing protection switching in the ring ethernet | |
| CN101729426B (en) | Method and system for quickly switching between master device and standby device of virtual router redundancy protocol (VRRP) | |
| CN109525434B (en) | Redundancy backup method based on onboard equipment board card | |
| CN105429814B (en) | Method and equipment for protecting BFD (bidirectional forwarding detection) by using multiple board cards | |
| CN101174975A (en) | Periodic line fault location method and system in Ethernet | |
| CN101989933A (en) | Method and system for failure detection | |
| CN101729307A (en) | Failure detecting method, communication equipment and network system | |
| CN113783961B (en) | Remote terminal management method, device, computer equipment and storage medium | |
| CN105223949A (en) | Electrical equipment and communication fault diagnosis method and device thereof | |
| CN110611590A (en) | Method and system for internet of things gateway communication backup | |
| CN101119304A (en) | Neighbourhood establishing method and router | |
| CN100446470C (en) | Method for realizing operation and maintenance of wind-band ethernet network | |
| US8451828B2 (en) | Registering an internet protocol phone in a dual-link architecture | |
| CN101409648A (en) | Method for locating node fault and link fault of Overlay network | |
| CN101771583B (en) | Method and device for detecting elimination or no elimination of network failure | |
| JP4757719B2 (en) | Network system, IP telephone terminal, and network device switching method used therefor | |
| CN111835551B (en) | Method and apparatus for operating network elements and monitoring entities in a communication infrastructure | |
| US20120230207A1 (en) | Early detection of loss of continuity in a maintenance association | |
| CN104348676A (en) | Link detection method and device based on operation administration and maintenance | |
| CN106549956A (en) | The LAN communication method that a kind of UDP and TCP be combined with each other | |
| CN105871716B (en) | VRRP-based link monitoring method and system |
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: 20081224 Termination date: 20180119 |