CN1791096A - Method for distinguishing LP-S and SF-P request in multiplex section protection - Google Patents

Abstract

The invention relates to a method for distinguishing LP-S (Sector Protection Lock) and SF-P (Signal Failure Protection) requests in multiplex section protection. The core of the present invention is to transfer the LP-S and SF-P request identification information between network elements at both ends by means of non-K1 and K2 overhead bytes, so as to transfer the LP-S command information issued to a certain network element Pass it to the peer network element, so that the network elements at both ends can know the delivery of the LP-S command. Therefore, the implementation of the present invention ensures that during the multiplex section protection process, the network elements at both ends that issue the LP-S command can accurately identify the LP-S request, so as to effectively distinguish the corresponding LP-S and SF-P Requests are processed in different ways. At the same time, the present invention can also make it easier to identify the switching state of the network element.

Description

Method for Distinguishing LP-S and SF-P Requests in Multiplex Section Protection

technical field

The invention relates to the technical field of network communication protection, in particular to a method for distinguishing LP-S (section protection locking) and SF-P (signal failure protection) requests in multiplex section protection.

Background technique

Multiplex section protection is a main protection method in SDH/SONET equipment. Due to its short switching response time, support for a complete APS (Automatic Protection Switching) protocol, rich external switching commands, and high switching reliability, it is used in optical widely used in the network.

Multiplex section protection transmits the APS switching protocol through the K1 and K2 overhead bytes of the SDH/SONET multiplex section. The definition of these two overhead bytes is shown in Table 1:

Table 1: K1 K2 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 switch request destination node number source node number long and short diameter switch state

It can be seen from Table 1 that the lower four bits of K1 transmit switching requests. Since there are only four bits, only 16 different switching requests can be distinguished. According to the G.841 standard, the values of the corresponding switching requests are shown in Table 1. 2 shows:

Table 2: Bridge Request code (Bits D1-D4) Bits D1 D2 D3 D4 1 1 1 1 Signal Fail(Protection)SF-P/Lockout of Protection(Span)LP-S 1 1 1 0 Forced Switch(Span)FS-S 1 1 0 1 Forced Switch(Ring)FS-R 1 1 0 0 Signal Fail(Span)SF-S 1 0 1 1 Signal Fail(Ring)SF-R 1 0 1 0 Signal Degrade(Protection)SD-P 1 0 0 1 Signal Degrade(Span)SD-S 1 0 0 0 Signal Degrade(Ring)SD-R 0 1 1 1 Manual Switch(Span)MS-S 0 1 1 0 Manual Switch(Ring)MS-R 0 1 0 1 Wait-To-Restore WTR 0 1 0 0 Exerciser(Span)EXER-S 0 0 1 1 Exerciser (Ring) EXER-R 0 0 1 0 Reverse Request (Span) RR-S 0 0 0 1 Reverse Request (Ring) RR-R 0 0 0 0 No Request NR

It can be seen from Table 2 that SF-P and LP-S are represented by the same value in the signaling transmitted by k bytes. Therefore, when switching occurs, the peer network element of the segment where switching occurs cannot distinguish whether the switching request is an SF-P request or an LP-S request based on the value of the switching request field in the k1 byte in the received signaling. request, that is, when the switching request field in the received signaling is 0xf, the node cannot distinguish whether it is SF-P or LP-S.

However, in the G.841 standard, it is stipulated that the protocol processing procedures of SF-P requests and LP-S requests are different. For example, in the case of ring multiplex section However, LP-S does not allow any ring switching in the same segment. Therefore, if the SF-P and LP-S requests cannot be distinguished on the network element, the specific protocol processing will be affected.

In addition, on the ring and linear multiplex sections, if the SF-P and LP-S requests cannot be effectively distinguished, it will also cause the multiplex section status of the network element at one end of the section to be switched in the case of querying the multiplex section status It is SF-P, but the multiplex section status of the network element at the other end is LP-S, resulting in misunderstanding of the multiplex section status.

For this reason, a technical solution is required to realize that when a network element receives a switching request, it can distinguish whether the switching request is an SF-P request or an LP-S request.

One method adopted at present is: use the RDI (Remote Defect Indication) in the switching status field transmitted by the upper three bits of the k2 byte in the overhead byte to distinguish. When the received switching request field is 0xf, then judge whether the value of the switching status field is 0x6, if yes, then determine that the switching request is SF-P, if the value of the switching status field is not 0x6, then the switching request is LP-S .

However, this method can only effectively distinguish LP-S and SF-P requests in certain cases, but cannot effectively distinguish SF-P and LP-S requests in some cases.

As shown in Figure 1, if the LP-S command is sent to the east of network element A, and assuming that the protection fibers in the section between A and B are all good, then the k-byte switching request received by B The field is 0xf, and the switching status field is not 0x6, so B can determine that the received switching request is LP-S.

However, when the protective optical fiber is cut off in section AB, B cannot receive k bytes in the short path direction (only RDI is inserted in the short path direction), so NE B has no way of knowing that NE A issued LP- In the case of the S command; if the eastbound protection fiber of network element A is broken, and the LP-S command is sent to the eastbound of network element A at the same time, the signaling transmitted by k bytes can be received, and the k bytes The switching request field of the stanza is 0xf, and the switching status field is 0x6. Therefore, it is judged that the received switching request is SF-P, but in fact it should be the LP-S request that works. This leads to misjudgment of SF-P and LP-S requests.

Another technical solution currently adopted is: U.S. Patent US 2002/0039348 A1 provides a method to distinguish SF-P and LP by using two values 0x4 and 0x5 that are not defined in the G.841 regulation in the switching state field in k2 -S method.

It can be seen that in the above method, SF-P and LP-S requests can be distinguished for the situation in FIG. 1 . That is, it solves the problem that end A sends LP-S to the east (or detects SF-P, that is, A's east protection fiber receiving is broken), and B's west has a local SF-R request (that is, B's west work and protection In the case of all receiving fibers are broken), the problem of distinguishing SF-P and LP-S requests when performing multiplex section switching. This is because SF-P and SF-R can coexist in the AB section, and LP-S needs to preempt SF-R. Therefore, it is necessary to pair SF-P and LP-S by switching the two undefined values in the status field. To make a distinction, the above-mentioned patents effectively solve this problem.

However, if there are switching requests in other sections except AB, this scheme will fail, because the long-path k bytes sent by A will not be transmitted to B, and network element B will naturally not be able to follow the patent In the method provided by US 2002/0039348 A1, it is judged whether A's request is SF-P or LP-S from the corresponding value in the k bytes received from A. Therefore, this method still has great limitations.

Contents of the invention

In view of the problems in the prior art above, the purpose of the present invention is to provide a method for distinguishing LP-S and SF-P requests in multiplex section protection, which can effectively distinguish LP-S and SF-P requests in various situations Request, which provides convenience for switching protocol processing and switching status query.

The purpose of the present invention is achieved through the following technical solutions:

The invention provides a method for distinguishing LP-S and SF-P requests in multiplex section protection, including:

A. After the network element receives the section protection lock LP-S command, it sends an LP-S request notification message to the peer network element;

B. After receiving the notification message, the peer network element records the LP-S request information;

C. When the peer network element receives a switching request identified as an LP-S or SF-P request, it determines that the received switching request is an LP-S request according to recorded information.

Described step A comprises:

Send the LP-S request notification message to the peer network element through the data communication channel DCC or the dedicated control channel.

Described step B comprises:

The opposite end network element records the information of the LP-S command transmitted from the other end network element using a separately set request attribute flag.

Described step C comprises:

If the peer network element receives the switching request in the K-byte switching request field and the switching request is 0Xf, check whether the information of the LP-S request issued by the other network element is recorded, and if so, determine that the received switching request is LP-S S request, otherwise, determine that the switching request is an SF-P request.

Described step B also includes:

B1. The peer network element returns a response message of the LP-S request notification message to the other network element;

B2. The network element at the other end judges whether the response message has been received within the set time. If it is received, record the information that the LP-S command has been issued in the network element at the local end. Otherwise, the network element at the local end The terminal that sends the LP-S command returns the message that the command is sent without response.

Described step B2 also includes:

After the local network element sends the message of no response, it also sends a message to clear the LP-S request to the peer network element. After receiving the message, the peer network element sets the request attribute identifier recorded by it to None ask.

The method for distinguishing LP-S and SF-P requests in the multiplex section protection also includes:

D. When the network element receives the clear LP-S command, check whether the local network element records the information that the LP-S command has been sent, if so, execute step E, otherwise, execute step F;

E. Generate a message for clearing the LP-S request, and send it to the peer network element. After the peer network element receives the message, set its recorded request attribute identifier to no request;

F. Send downward the message of clearing the command error returned by the LP-S command terminal.

Described step E also comprises:

The peer network element returns a response message to the local network element;

The local network element judges whether the response message is received within the set time, and if so, modifies the recorded LP-S command issued information to no request, and performs protocol processing accordingly. Otherwise, send the clear LP-S command to the terminal and return the command to send no response information.

It can be seen from the above-mentioned technical solution provided by the present invention that the present invention transmits LP-S and SF-P request identification information between network elements at both ends by means of non-K1 and K2 overhead bytes, so that both ends of the network Yuan Jun can know the issuance of the LP-S command. Therefore, the implementation of the present invention ensures that during the multiplex section protection process, the network elements at both ends of the issued LP-S command can accurately identify the LP-S request, so as to effectively distinguish the corresponding LP-S and SF-P Requests are handled in different ways. At the same time, the present invention can also make it easier to identify the switching state of the network element.

Description of drawings

Figure 1 is a schematic diagram of the multiplex section protection ring network structure;

Figure 2 is a flow chart of the method of the present invention.

Detailed ways

The core of the present invention is to use a non-K1, K2 byte overhead method (such as through a data communication channel, etc.) to communicate between network elements, so as to transfer the LP-S command information sent to the network element to the peer network element , so that the peer network element can know the delivery of the LP-S command in this section without transmitting k bytes, which facilitates the processing of the protocol and the query of the protocol state of the network element.

The main process of the method of the present invention comprises:

First, when the network management issues an LP-S command to the local network element, the local network element sends an LP-S request notification message to the peer network element;

The peer network element records the information of the LP-S command issued by the other network element according to the received notification message, and returns a response message to the local network element, so that the local network element can confirm that the LP-S command has been issued hair;

In this way, when the peer network element receives the switching request sent by the local network element, or needs to query the switching status of the peer end, it can determine whether it is an LP-S request according to the information stored therein.

The specific implementation of the method of the present invention is shown in Figure 2, specifically comprising the following steps:

Step 21: During the multiplex section protection process, the network management issues an LP-S command to a certain network element A, as shown in Figure 1, assuming that network element A receives the issued LP-S command, it is called the local end Network element, network element B is the network element at the other end of the same segment, and is called the peer network element;

Step 22: After network element A receives the LP-S command issued by the network management system, it sends an LP-S request notification message to the peer network element, that is, network element B, to notify network element B of the occurrence of LP-S in this section. S request;

Step 23: After the peer network element B receives the LP-S request notification message, it uses the set request attribute flag (which can be called attribute 1) to record the LP-S command issued by the network element A locally. Information, the function of attribute 1 is to identify whether the peer network element has issued the LP-S command;

Step 24: When network element B modifies attribute 1 information, it also needs to send a response message of the LP-S request notification message to network element A;

Step 25: Network element A judges whether the response message is received within the set time, if so, execute step 26, otherwise, execute step 27;

If network element B has not received the LP-S request notification message from network element A, or network element A has not received the response message from network element B, then network element A will , the response message from network element B will not be received;

Step 26: After network element A receives the response message, record the LP-S command in the external switching command flag (which may be called attribute 2) of network element A. Record the LP-S command in the issued, and perform protocol processing, At the same time, execute step 29;

Step 27: Network element A returns the return information that the network management command cannot be executed, and at the same time sends a message to clear LP-S to network element B;

Step 28: After network element B receives the message for clearing LP-S, it clears the information recorded in attribute 1 and sets it as NR (no request), and at the same time, executes step 29;

Step 29: Network element B waits to receive the switching request sent by network element A;

Step 210: Network element B receives the k-byte switching request sent by network element A, and the switching request in the switching request field is 0xf;

Step 211: Determine whether the switching request is an LP-S request or an SF-P request according to attribute 1 saved by network element B;

Network element B judges whether attribute 1 records the LP-S command issued by network element A, if yes, then determines that the switching request is an LP-S request, otherwise, determines that the switching request is an SF-P request;

After the previous processing, in this step, according to the information recorded in attribute 1, it can be known whether the received switching request is an SF-P request or an LP-S request, so as to handle it accordingly;

In the present invention, when the switching state needs to be queried, if the switching request recorded locally is 0xf, it is also necessary to know whether the switching request is LP-S or SF-P according to the information recorded in the local attribute 1. In this way, The network management system can correctly display the switching status.

The method of the present invention also includes the processing procedure when the network manager issues a clear LP-S command to a certain network element. It is still assumed that the LP-S switching command is issued to NE A, and NE B is the NE at the other end of the same segment. The specific processing process includes:

(1) If the clear LP-S command is issued to NE B, because the value in the local attribute 2 of NE B is not 0xf, that is, the network management has not issued the LP-S switching command to NE B, at this time, the NE B returns the command error information to the network management system.

(2) If the clear LP-S command is issued to network element A, and the value of local attribute 2 of network element B is 0xf, then network element A sends a clear LP-S message to network element B to clear network element B The value of attribute 1 of the network element B; after receiving the message of clearing LP-S, the remote network element B restores the local attribute 1 to NR, and sends a response message to network element A at the same time.

If NE B does not receive the message for clearing LP-S from NE A, or if NE A does not receive the response message from NE B, then NE A will return the command to the network management system after a timeout of 3 seconds. Send the return information that cannot be executed, that is, send a non-response message to the network management command, and notify the network management that the command it issued cannot be executed. At the same time, an LP-S request notification message is sent to network element B to prevent the inconsistency between the two ends caused by the fact that attribute 1 in network element B has been cleared.

If network element A receives the response message for clearing the LP-S message, restore the information recorded in attribute 2 of network element A to NR, and perform protocol processing.

The LP-S request notification message described in the present invention and the message of clearing the LP-S command can be transmitted between network elements through DCC (data communication channel) or dedicated channels, and can also be adopted to ensure that the LP-S between network elements Channels for reliable delivery of information.

The above is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present invention can easily think of changes or Replacement should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the protection scope of the claims.

Claims (8)

1. A method for distinguishing LP-S and SF-P requests in multiplex section protection, characterized in that it comprises: A. After the network element receives the section protection lock LP-S command, it sends an LP-S request notification message to the peer network element; B. After receiving the notification message, the peer network element records the LP-S request information; C. When the peer network element receives a switching request identified as an LP-S or SF-P request, it determines that the received switching request is an LP-S request according to recorded information. 2. The method for distinguishing between LP-S and SF-P requests in multiplex section protection according to claim 1, wherein said step A comprises: Send the LP-S request notification message to the peer network element through the data communication channel DCC or the dedicated control channel. 3. The method for distinguishing between LP-S and SF-P requests in multiplex section protection according to claim 1, wherein said step B comprises: The opposite end network element records the information of the LP-S command transmitted from the other end network element using a separately set request attribute flag. 4. The method for distinguishing between LP-S and SF-P requests in multiplex section protection according to claim 1, 2 or 3, wherein said step C comprises: If the peer network element receives the switching request in the K-byte switching request field and the switching request is OXf, check whether the information of the LP-S request issued by the other network element is recorded, and if so, determine that the received switching request is LP-S S request, otherwise, determine that the switching request is an SF-P request. 5. The method for distinguishing between LP-S and SF-P requests in multiplex section protection according to claim 1, 2 or 3, characterized in that said step B further comprises: B1. The peer network element returns a response message of the LP-S request notification message to the other network element; B2. The network element at the other end judges whether the response message has been received within the set time. If it is received, record the information that the LP-S command has been issued in the network element at the local end. Otherwise, the network element at the local end The terminal that sends the LP-S command returns the message that the command is sent without response. 6. The method for distinguishing between LP-S and SF-P requests in multiplex section protection according to claim 5, characterized in that said step B2 further comprises: After the local network element sends the message of no response, it also sends a message to clear the LP-S request to the peer network element. After receiving the message, the peer network element sets the request attribute identifier recorded by it to None ask. 7. The method for distinguishing LP-S and SF-P requests in multiplex section protection according to claim 1, 2 or 3, characterized in that the method further comprises: D. When the network element receives the clear LP-S command, check whether the local network element records the information that the LP-S command has been sent, if so, execute step E, otherwise, execute step F; E. Generate a message for clearing the LP-S request, and send it to the peer network element. After the peer network element receives the message, set its recorded request attribute identifier to no request; F. Send downward the message of clearing the command error returned by the LP-S command terminal. 8. The method for distinguishing LP-S and SF-P requests in multiplex section protection according to claim 7, characterized in that said step E further comprises: The peer network element returns a response message to the local network element; The local network element judges whether the response message is received within the set time, and if so, modifies the recorded LP-S command issued information to no request, and performs protocol processing accordingly. Otherwise, send the clear LP-S command to the terminal and return the command to send no response information.

Images