WO2019134572A1

WO2019134572A1 - Sdn-based optical transport network protection recovery method and device, and storage medium

Info

Publication number: WO2019134572A1
Application number: PCT/CN2018/124045
Authority: WO
Inventors: 赵阳; 李晗; 王磊
Original assignee: 中国移动通信有限公司研究院; 中国移动通信集团有限公司
Priority date: 2018-01-02
Filing date: 2018-12-26
Publication date: 2019-07-11
Also published as: CN109996130A

Abstract

Disclosed are an SDN-based optical transport network protection recovery method and device and a storage medium. The method comprises: acquiring information of a recovery constraint object in an open networking foundation (ONF) model, wherein the recovery constraint object comprises at least: a protection recovery scope field; performing a route calculation according to the information of the recovery constraint object; and configuring a protection path or a recovery path according to the result of the route calculation.

Description

SDN-based optical transport network protection recovery method, device and storage medium

Cross-reference to related applications

The present application is filed on the basis of the Chinese Patent Application No. 201810003049.0, the entire disclosure of which is hereby incorporated by reference.

Technical field

The present invention relates to the field of optical fiber communication technologies, but is not limited to the field of optical fiber communication technologies, and in particular, to an optical transmission network protection recovery method, device, and storage medium based on a Software Defined Network (SDN).

Background technique

Optical transport networks based on SDN centralized control architecture have been widely used. The Open Networking Foundation (ONF) defines an information interaction model for optical transport networks that can be used to describe all network resources.

In particular, it involves cross-domain transmission of multiple domains, and how to perform protection recovery of faults. Different vendors offer different implementations in the prior art. In this case, the following problems exist:

First: the interoperability of different implementations is poor. When there are multiple vendors' devices in a domain, it is difficult to achieve compatibility.

Second: There may be a waste of resources for redundant operations. Due to poor interoperability, fault handling methods between different vendors are isolated from each other, resulting in a lot of unnecessary operations and waste of resources.

Third: It is impossible to find the most suitable release method for the current fault from the perspective of the entire network, resulting in failure to optimize resources and optimize faults.

Summary of the invention

In view of this, the embodiments of the present application are expected to provide an SDN-based optical transport network protection recovery method, device, and storage medium.

The technical solution of the present application is implemented as follows:

The first aspect of the embodiments of the present application provides an SDN-based optical transport network protection and recovery method, which is applied to a controller, and includes:

Obtaining information of a recovery constraint object in an Open Network Foundation ONF model, where the recovery constraint object includes at least: a protection recovery scope field;

Performing a route calculation according to the information of the recovery constraint object;

According to the result of the route calculation, a protection path or a recovery path is configured.

A second aspect of the embodiments of the present application provides a controller, including:

An obtaining unit, configured to obtain information of a recovery constraint object in an Open Network Foundation ONF model, where the recovery constraint object includes at least: a protection recovery scope field;

a route calculation unit, configured to perform route calculation according to the information of the recovery constraint object;

And a configuration unit, configured to configure a protection path or a recovery path according to the result of the route calculation.

A third aspect of the embodiments of the present application provides a controller, including: a network interface, a memory, a processor, and a computer program stored on the memory and executed by the processor;

The processor is connected to the network interface and the memory, respectively, for implementing the SDN-based optical transport network protection recovery method provided by the foregoing one or more technical solutions by executing the computer program.

A fourth aspect of the embodiments of the present application provides a computer storage medium, where the computer storage medium stores a computer program; after the computer program is executed, the SDN-based optical transport network protection and recovery provided by the foregoing one or more technical solutions can be implemented. method.

The embodiment of the present invention provides an SDN-based optical transport network protection and recovery method, device, and storage medium. The controller can obtain at least a recovery constraint object including a protection recovery range field from the ONF recovery constraint object, and perform route calculation, so triggering The information calculated by the route is carried in the ONF message transmitted between the controllers, and the ONF message is a message transmission supported by devices of different vendors, thereby solving the problem of poor interoperability in the prior art. The problem of poor interoperability is solved and it is determined that the calculation is based on the ONF message. For example, according to the protection recovery range field in the ONF, it is determined by whom the route calculation is performed, which can avoid unnecessary calculation caused by all controllers performing route calculation at the same time, and The calculated result is different from the conflict resolution problem. In addition, in the embodiment of the present application, the controller that is most suitable for the current protection path or the recovery path calculation may be selected according to the protection recovery range field, thereby optimizing the route calculation of the protection path or the restoration path, thereby realizing Resource configuration optimization and effect optimization for protection of working paths.

DRAWINGS

1 is a schematic flowchart of a first SDN-based optical transport network protection and recovery method according to an embodiment of the present application;

2 is a system architecture diagram provided by an embodiment of the present application;

FIG. 3 is a schematic structural diagram of a controller according to an embodiment of the present disclosure;

4 is a schematic flowchart of a second SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 5 is a schematic flowchart of a third SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 6 is a schematic flowchart diagram of a fourth SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 7 is a schematic flowchart of a fifth SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 8 is a schematic flowchart of a sixth SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 9 is a schematic flowchart of a seventh SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 10 is a schematic flowchart of an eighth SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure;

FIG. 11 is a schematic flowchart diagram of a DC SDN-based optical transport network protection and recovery method according to an embodiment of the present disclosure.

Detailed ways

The technical solutions of the present application are further elaborated below in conjunction with the drawings and specific embodiments.

As shown in FIG. 1 , the embodiment provides an SDN-based optical transport network protection recovery method, which is applied to a controller, and includes:

Step S110: Acquire information of a recovery constraint object in an Open Network Foundation ONF model, where the recovery constraint object includes at least: a protection recovery scope field;

Step S120: Perform route calculation according to the information of the recovery constraint object.

Step S130: Configure a protection path or a recovery path according to the result of the route calculation.

In the embodiment, the controller may be an SC or a DC. Usually, the one DC controls one domain; the SC is connected to multiple DCs and controls multiple domains at the same time. FIG. 2 is a schematic structural diagram of an SDN network provided by an embodiment of the present application. The A domain DC controls the A domain, and the B domain DC controls the B domain. The DC connects to the SC through the northbound borrowing. The SC can control the A domain and the B domain at the same time, and can uniformly schedule network resources in the A domain and the B domain. In this embodiment, the A domain and the B domain may be metropolitan area networks of different cities, or one may be a miniaturized domain within a group based on an enterprise or a government, and the other is a metropolitan area network.

When the controller is an SC, the SC may receive information of the recovery constraint object from a management device connected thereto or from a human-machine interaction interface, or query information of the recovery constraint object from an ONF model database. The information of the recovery constraint object includes one or more fields, and the field defines various parameters for eliminating the service failure by switching the protection path or the recovery path when the working path of the service data is faulty.

In this embodiment, the information of the recovery constraint object includes at least a protection recovery scope field, and the field is one field or multiple fields. If a field can be used to indicate the range, specifically the scope of protection or the range of responses can be determined by combining the type field. In other embodiments, the protection recovery range field may be two fields, one is a protection scope field for indicating a range in which the protection path is located, and the other is a recovery scope field for indicating a range of the restoration path. In this embodiment, the range may be single domain or cross domain. For example, if the end-to-end protection is used, the protection scope is cross-domain, and all the domains that the working path corresponding to the protection path passes through. If the single-domain is used, only the protection of the domain through which the working path passes is required. Multiple domains coordinate for protection. For example, the working path is in the A domain, the B domain, and the C domain. If the single domain protection is used, the protection path is configured in the A domain, the B domain, and the C domain. For example, when the fault point of the current working path is located in the A domain, when the service data is switched, the traffic data on the working path in the A domain is switched to the protection path of the A domain, and the B domain is transmitted. The C domain still uses the original working path for transmission, and there is no need to switch between the working path and the protection path.

In this embodiment, the protection path is a pre-configured reserved path. For example, after calculating the route of the protection path, according to the result of the route calculation, the transmission resource of the protection path is reserved, for example, the transmission bandwidth, etc. Once the fault is detected, you can switch directly to the protection path.

In some embodiments, the recovery path may be that the route is calculated first, but the network resource is not allocated in advance to configure the path. When the fault occurs, the network resource is allocated based on the pre-calculated route to implement the configuration of the recovery path. After the configuration of the recovery path is completed, the service data transmitted on the failed working path is switched to the recovery for transmission.

In other embodiments, the route of the restoration path is not necessarily calculated in advance, but the route calculation is performed when the fault is detected, and the network resource allocation is implemented based on the route calculation to implement the restoration path configuration, and after the restoration path configuration is completed, the route is performed. Switching transmission of business data.

The calculated route may include: a domain through which the two ends of the service transmission pass, a forwarding node in the domain, a port of the transit node, and the like.

In this embodiment, after the SC and the DC in the step S130 acquire the protection recovery range field, it may be determined whether the route calculation is required. For example, if the global end-to-end protection is performed, the SC itself needs to perform route calculation. If the SC is only based on the single-domain protection, the SC only needs to send the ONF message carrying the protection recovery range field to the corresponding DC. The route calculation in the domain can be performed by the DC. Therefore, first, the protection recovery range word can be used to indicate an execution subject that performs routing calculation, and the execution subject can be an SC or a DC. In this case, even if the devices of different manufacturers receive the ONF message, they know whether they need to participate in the calculation of the route, so that the calculation can be avoided and the calculation can be performed preferentially. The devices of different vendors support the interaction and identification of ONF messages in the ONF model. Therefore, the problem of poor interoperability is solved. The ONF message is directly equivalent to indicating whether the corresponding controller performs route calculation. If it needs to be executed, it is equivalent to the implementation. Coordination between devices from different vendors avoids double counting and can select the best execution subject for route calculation to optimize the protection recovery. In this embodiment, the information of the recovery constraint object is carried by the ONF message between the controllers for transmission, so the compatibility with the prior art is strong, and the interaction between the SC and the DC can be easily performed; Unnecessary calculation and waste of resources, the optimal configuration of protection recovery in the entire network is realized, and the optimization of protection and recovery of fault cancellation is realized.

In some embodiments, the protection recovery range field is used to determine the scope of protection recovery and/or the execution subject of the route calculation.

In some embodiments, when the controller is an SC, the step S120 may include: when the protection recovery range field indicates end-to-end protection recovery, the inter-domain controller SC performs a route calculation;

The step S130 may include: performing resource configuration of the pre-configured protection path or the recovery path according to the route calculation performed by the SC, and sending the configuration information of the resource configuration to the domain controller DC of each domain. .

Since the end-to-end protection recovery is possible, since the end-to-end protection path or recovery path may be cross-domain, the route calculated by the SC is superior to the route calculated by a single DC. For example, the SC may consider different The load of the domain, select the domain through which the protection path or recovery path passes, select the port to be transmitted between the domain and the domain according to the load between the different domain ports, avoid the domain with high load or disconnect, and thus obtain the protection path or recovery. The path can reduce the congestion of the service data transmission process, and avoid further increasing the busyness of the busy domain or forwarding device or port, thereby reducing the delay of the service data, thereby optimizing the configuration of the protection path or the recovery path. .

After the SC completes the route calculation of the protection path or the recovery path, the configuration information of the resource configuration of the protection path or the recovery path is sent to the DC of the domain that the protection path or the recovery path needs to pass, and is determined by the DC according to the The configuration information is used for resource configuration, thereby completing the configuration of the protection path or the recovery path.

When the controller is DC, and the protection recovery range is a domain-by-domain protection in a single domain in step S120, the route calculation is performed as DC, and the resource configuration of the protection path or the restoration path is also performed. DC. Because the domain-by-domain protection is complete, the domain and the domain can be completely independent. In this case, unnecessary information interaction between the SC and the DC can be reduced, and the delay caused by the information interaction is reduced. The DC performs route calculation of the local domain, and performs configuration of the protection path or the recovery path based on the result of the route calculation. For example, the step S120 may include: when the protection recovery range field is the domain-by-domain protection recovery, the DC calculates the route calculation of the local domain; the step S130 may include: according to the result of the route calculation performed by the DC, Configure the protection path or recovery path in this domain.

If the controller is a DC, the step S110 may include: receiving an ONF message carrying information of the recovery constraint object from the SC.

The protection constraint object further includes: a protection recovery type field; wherein the protection recovery type field is used to determine a route calculation mode of the protection path or the restoration path.

The protection recovery type field substantially indicates the type of protection recovery, for example, may include: 1+1 protection, dynamic reroute recovery, or preset route recovery. The 1+1 protection is pre-configured with a protection path, and the protection path and the working path are 1:1 configured, that is, one protection path is configured with one protection path. Usually, in this case, the execution subject of the route calculation is SC. If the protection recovery type field is to indicate dynamic reroute recovery, the DC of each domain that the work path passes may be performed by performing the route calculation. When the protection recovery type field indicates that the recovery type is the preset configuration, the route is pre-calculated by the SC, and the configuration information for performing the restoration path configuration is sent to the DC.

In some embodiments, the protection recovery type field is also used to indicate when protection and recovery are taking place. For example, the step S120 may include one or more of the following alternatives.

Optional one:

The step S120 may include:

When the protection recovery type field indicates that the recovery type is dynamic reroute recovery, the path of the protection path or the recovery path of the working path is calculated after detecting the working path failure. If you want to save network resources and avoid waste of resources by pre-configuring routing resources, you can use dynamic rerouting for route calculation of recovery path of service data with large transmission delay. Therefore, in order to reduce unnecessary calculation, you can appear in the working path. The route calculation of the recovery path is performed only when the fault occurs. Generally, if the probability of occurrence of the fault is small, the calculation amount and the computational resources consumed by the route calculation can be greatly reduced.

In addition, in the present embodiment, in order to reduce the dynamic re-routing in the process, the route calculation by the SC requires further delay caused by the information exchange with the DC for routing calculation, in this implementation. In the example, DC is preferred for route calculation, and in the case of failure due to dynamic rerouting,

Option 2: The step S120 may include:

When the protection recovery type field indicates that the recovery type is preset reroute recovery, the route of the protection path or the recovery path of the working path is calculated before the calculation of the working path failure.

In this embodiment, the protection recovery type field indicates that the recovery type is a preset re-routing, that is, the route of the restoration path is pre-configured, that is, the calculation is performed before the failure of the working path occurs, so the pre-computation recovery is required in the implementation force. The route of the path. Normally, when the route of the working path is calculated, the route of the recovery path can be calculated synchronously. Alternatively, after completing the route calculation of the working path, when the service data is transmitted by using the working path, the route calculation of the recovery path is started.

Option 3:

The step S130 may include:

When the protection recovery type field indicates that the protection type is the permanent 1+1 protection mode, the route of the protection path is calculated in advance.

In this embodiment, the protection type is a permanent 1+1 protection mode, which indicates that a protection path always exists in a working path. Therefore, before the working path starts to transmit service data, it is necessary to pre-calculate the route of the protection path and complete the protection path. Configuration. If the data transmission on the working path is switched to the currently available protection path for transmission, the protection path of the path of the current transmission service data needs to be calculated immediately to ensure a highly reliable path.

In some embodiments, the current working path is to use the recovery path for service guarantee or the protection path for service guarantee, and may be determined according to the quality of service (QoS) of the service data and the transmission delay requirement. Generally, the reliability of the protection path is the highest and the delay of the service switching is small, and the reliability of the recovery path is slightly lower and the delay is larger. If the recovery path is used, it is divided into dynamic re-routing and pre-re-routing. The reliability of dynamic routing is lower than that of domain-to-reroute, and the delay of dynamic re-routing is greater than the delay of preset re-routing. Therefore, when determining the protection recovery type field in the information of the recovery constraint object, comprehensive configuration may be performed according to parameters such as QoS of service data and/or allowed transmission delay.

As shown in FIG. 3, this embodiment provides a controller, including:

The obtaining unit 110 is configured to acquire information of a recovery constraint object in an Open Network Foundation ONF model, where the recovery constraint object includes at least: a protection recovery scope field;

The route calculation unit 120 is configured to perform route calculation according to the information of the recovery constraint object;

The configuration unit 130 is configured to configure a protection path or a recovery path according to the result of the route calculation.

In this embodiment, the controller may be the foregoing SC or DC, and the obtaining unit 110 may include information that the network interface may receive the recovery constraint object from other devices, or may include a human-computer interaction interface receiving management input. The information of the recovery constraint object.

The route calculation unit 120 may correspond to a processor and may be configured to perform route calculation according to a network topology condition.

The configuration unit 130 can also be corresponding to the processor, and can be used to continue the configuration of the protection path or the recovery path through the configuration of the network resource, for example, the port configuration and/or the port configuration, so that the service data is paired through the protection path. The working path is protected, and the recovery of the service data is resumed when the working path fails, thereby realizing the protection and recovery of the service data transmission.

The controller may be an inter-domain controller; the route calculation unit 120 is configured to perform route calculation when the protection recovery range field indicates end-to-end protection recovery; the configuration unit 130 is configured to use, according to the SC The route calculation is performed, and the resource configuration of the pre-configured protection path or the recovery path is performed, and the configuration information of the resource configuration is sent to the domain controller DC of each domain.

In some embodiments, the controller may be a DC, and the route calculation unit 120 is configured to calculate a route calculation of the local domain when the protection recovery range field is a domain-by-domain protection recovery; the configuration unit 130. Specifically, configured to configure a protection path or a recovery path in the local area according to a result of the route calculation performed by the DC. At this time, the acquiring unit 110 is specifically configured to receive, from the SC, an ONF message carrying information of the recovery constraint object.

In some embodiments, the protection constraint object further includes: a protection recovery type field; wherein the protection recovery type field is used to perform an execution entity of the route calculation.

In some embodiments, when the protection recovery type field indicates that the recovery type is dynamic reroute recovery, the controller is a DC, and the route of the restoration path is calculated by the route calculation unit 120 of the DC.

In some embodiments, when the protection recovery type field indicates that the recovery type is preset reroute recovery, the controller is an SC, and the route of the restoration path is calculated by the route calculation unit 120 of the SC;

In some embodiments, when the protection recovery type field indicates that the protection type is a permanent 1+1 protection mode, the controller is an SC, and the route of the protection path is calculated by the route calculation unit 120 of the SC.

In some embodiments, the protection recovery type field is further configured to determine a route calculation mode of the protection path or the restoration path;

The route calculation unit 120 is specifically configured to: when the protection recovery type field indicates that the recovery type is dynamic reroute recovery, calculate a route of the recovery path after detecting a working path failure; and/or, when The protection recovery type field indicates that when the recovery type is preset reroute recovery, the route of the restoration path is calculated before calculating the working path failure; and/or, when the protection recovery type field indicates that the protection type is permanent 1+1 protection mode At the time, the route of the protection path is calculated in advance.

In some embodiments, the protection recovery range field includes a protection scope field for indicating a range of the protection path, and a recovery range field for indicating a range of the restoration path.

As shown in FIG. 4, the embodiment of the present application further provides a controller, which may include: a network interface 210, a memory 220, a processor 230, and a computer program stored on the memory 220 and executed by the processor 230;

The processor 230 is connected to the network interface 210 and the memory 220, respectively, for implementing the SDN-based optical transport network protection recovery method by implementing the computer program to implement the foregoing one or more technical solutions.

The network interface 210 in this embodiment may correspond to various types of interfaces, such as cable interfaces or fiber optic cable interfaces.

The memory 220 can include devices that store various information.

The processor 230 may include: a central processing unit, a microprocessor, a digital signal processor, an application processor, a programmable array or an application specific integrated circuit, etc., and may be applied to the execution by computer executable instructions such as a computer program. In a power control method for a beam in a communication device.

The processor 230 can be coupled to the transceiver 310 and the memory via a communication bus (e.g., an integrated circuit bus).

The embodiment provides a computer storage medium, where the computer storage medium stores a computer program, and the computer program is executed to execute the SDN-based optical transport network protection and recovery method provided by the foregoing one or more technical solutions.

Several specific examples are provided below in connection with any of the above embodiments:

Example 1:

Currently, the ResilienceType object in the ResilienceConstraint object in the ONF model contains a ResilienceType type object. Specify the protection/recovery type and policy for a specific service by resilienceType. The current ResilienceType is defined as follows:

According to the above definition, since a service needs to configure the protection type, the recovery type, and the scope of protection and recovery (end-to-end or domain-by-domain), the current field definition is insufficient to meet the requirements of the multi-domain protection recovery strategy. This proposal extends the resilienceType and adds a protectionRange field and a restoreRange field to indicate the scope of execution protection and the scope of execution recovery, that is, the scope of the protection path and the scope of the recovery path. Is an end-to-end cross-domain or single-domain scope. After the extension, the ResilienceType is as follows, and the protection recovery type of the service is identified by three fields: resilienceType, protectionRange, and restoreRange.

Based on the above extensions, different combinations of protection and recovery types can be developed.

The value of the SC-related field is as follows (end-to-end protection service needs to occupy 3 Service End Point (SEP) ports in the domain):

The values related to the DC side are as follows:

On the DC and SC control system, when a fault is detected or a fault notification is received, it is necessary to determine whether the protection recovery action is performed at the local end. For example, "end-to-end dynamic rerouting" is calculated by the SC for global rerouting, while DC does not calculate rerouting; "domain-by-domain rerouting" is calculated by the failed DC to calculate rerouting, while the SC does not need to be calculated.

Therefore, based on the extension of the ONF standard model, it is also necessary to add corresponding fields in the DC and SC control system database. This proposal does not specify the specific database design of the control system. There are three fields (resilienceType, protectionRange, restoreRange) for each service in the DC and SC system tables.

For services, the protection/recovery types usually have permanent 1+1, dynamic reroute recovery, and 1+1 reroute recovery. This proposal mainly defines the interaction mechanism between DC and SC for the above three protection types.

The scheme of protection type for permanent 1+1 protection can be as follows:

In the permanent 1+1 protection mode, the service identifiers of the DC and SC are E2E. Considering that the route calculated by the SC is globally optimal and the resources on the protection path are pre-occupied, this example uses the cross-domain end-to-end protection scheme in which the protection path is calculated by the SC in the permanent 1+1 protection mode. This solution not only ensures the global optimization of the path, but also does not affect the service switching time.

In the permanent 1+1 protection mode, the device uses a dual-issue selection mechanism, that is, the device sends data signals on both the working and protection paths, and the receiver selects the signal with better quality. In this mode, after the device detects an alarm, the receiver directly switches to the protection port, and the sender does not need to switch. In summary, the permanent 1+1 protection mode is performed by the device after the fault occurs, and the alarm of the fault is reported to the DC, and then reported to the SC by the DC. Since it is a hardware direct handover, there is no need to wait for a signaling response, so the service interruption time can be guaranteed to be less than 50 ms.

The DC and the SC receive the fault alarm and do not need to send any signaling for service switching. However, for the permanent 1+1 mode, the SC needs to recalculate a protection path after the working path fails.

The relevant parameters of the SC end are configured as follows:

resilienceType=1P1&NR

protectionRange=E2E

restoreRange=NA

The parameters of the DC side are configured as follows:

resilienceType=1P1&NR

protectionRange=E2E

restoreRange=NA

The scheme for recovery type reroute recovery can be as follows:

Reroute recovery includes dynamic rerouting and pre-reroute. In the dynamic rerouting mode, the controller calculates the rerouting in real time after detecting the fault; in the preset rerouting mode, the controller calculates the rerouting while the service is being sent, and saves it in the system database, and does not occupy the actual device resources. After the fault occurs, the service is directly switched to the pre-calculated re-routing.

Dynamic rerouting

In the dynamic rerouting mode, it is considered that the signaling interaction between the DC and the SC often takes a long time (seconds or even minutes), so this example adopts a domain-by-domain recovery scheme of re-routing by DC calculation. When the device detects a fault, the device does not switch because the dual-issue selection is not configured. The alarm is directly submitted to the DC. After receiving the alarm, the DC of the fault domain calculates the intra-domain rerouting scheme according to the restoreType field, and the other domains do not take any action. Since per-domain rerouting is configured, the SC does not calculate rerouting after receiving an alert.

The corresponding parameters of the SC end are configured as follows:

ResilienceType=NP&NR

ProtectionRange=NA

RestoreRange=PD

The configuration parameters of the DC side are as follows:

ResilienceType=NP&DR

ProtectionRange=NA

RestoreRange=E2E

b. Pre-reroute

In the pre-reroute mode, since the re-routing is calculated in advance, this example uses the SC to calculate the re-routing, and then delivers and stores the scheme in the DC database. In the parameter configuration, perform configuration according to DC execution recovery, and the corresponding parameters are configured as follows:

The parameters of the SC side are as follows:

ResilienceType=NP&NR

ProtectionRange=NA

RestoreRange=PD

The parameters on the DC side are as follows:

ResilienceType=NP&PR

ProtectionRange=NA

RestoreRange=E2E

The interaction between the pre-rerouted SC and the DC and the device is as shown in the figure (assuming a fault occurs in the A domain). Since the re-routing calculated by the SC is the globally optimal end-to-end route, not only the fault occurs when the fault occurs. The domain needs to be rerouted, and domains that have not failed may also need to be rerouted.

Example 2:

As shown in FIG. 5, this example provides a 1+1 protection method based on an example, including:

The SC performs route calculation of the protection path;

The SC sends the configuration information of the network resource for the reserved protection path to the controllers DC A and DC B of the A domain and the B domain respectively.

DC A detects the fault and switches the service to the protection path, that is, the transmission of the service data is switched from the working path to the protection path;

DC A sends a fault report to the SC;

The SC re-calculates the route of the current working path;

The SC reserves the network resources of the protection path again, and sends the information of the network resources that reserve the protection path to DC A and DC B respectively.

Example 3:

As shown in Figure 7, this example provides a recovery method for dynamic rerouting, including:

The SC performs resource configuration, and sends configuration information of the resource configuration to the DC A.

DC A detects the fault and then calculates the route of the recovery path.

After DC A recovers the path based on the dynamically calculated route, the service is switched to the recovery path.

DC A can report the fault of the working path to the SC, or it can not report the fault of the working path.

Example 4:

As shown in FIG. 6 and FIG. 7, this example provides a 1+1 protection recovery method, including:

First, the SC performs route calculation of the protection path;

The SC sends a notification of the network resource that reserves the protection path to the DC A and the DC B;

DC A detects the fault and directly switches the service to the configured protection path.

DC A reports the fault to the SC;

The SC indicates that the service has been switched to dynamic rerouting;

DC A detects the route of the fault calculation recovery path;

DC A switches the service to the recovery path.

If a working path is configured with both the protection path and the recovery path, the service fault can be eliminated based on the protection path or the recovery path according to the protection path and the recovery path.

Example 5:

As shown in Figure 8, this example provides a recovery method for dynamic rerouting, including:

SC setting field, resilienceType=NP&DR, protectionRange=NA, restoreRange=PD; where NP means no protection; DR means dynamic rerouting; NA means vacancy; PD means domain-by-domain protection.

The SC configures the resources and sets the fields to be sent to the A-domain DCs and B-domain DCs: protectionRange=NA, restoreRange=E2E; where E2E is end-to-end, and in the case of domain-by-domain protection, the end-to-end is in a single domain. End-to-end, rather than cross-domain service source and sink end-to-end.

The A-domain DC configures the resources of the A-domain device according to the configuration information sent by the SC. The B-domain DC configures the resources of the B-domain device according to the configuration information sent by the SC.

The B domain device detects the fault and reports it to the B domain DC.

The B domain device is based on the field sent by the SC: resilienceType=NP&NR, protectionRange=NA, and restoreRange=E2E. Since it is not a local domain failure, it is not processed. The processing here is fault recovery processing.

The A domain device detects the fault and reports it to the A domain DC.

Based on the fields sent by the SC: resilienceType=NP&DR, protectionRange=NA, and restoreRange=E2E, the A domain device calculates the intra-domain rerouting, configures the resources of the recovery path calculated by the route, and switches the service to the recovery path.

The A domain DC reports a fault.

After receiving the fault, the SC reads the fields: resilienceType=NP&DR, protectionRange=NA, and restoreRange=PD. No action is taken according to the field. No action is taken here to do no protection or recovery.

Example 6:

As shown in FIG. 9, this example provides a 1+1 protection method, including:

SC setting field, resilienceType=IPI&DR, protectionRange=E2E, restoreRange=NA; where IPI indicates 1+1 protection; NR indicates no recovery; NA indicates vacancy; here E2E is cross-domain end-to-end protection.

The SC allocates resources and sets the fields to be sent to the A-domain DC and B-domain DCs: resilienceType=IPI&DR, protectionRange=E2E, and restoreRange=NA.

The B domain device detects the fault and reports the B domain DC and switches the service to the protection path.

The B domain device reads the field sent by the SC: resilienceType=IPI&DR, protectionRange=E2E, and restoreRange=NA. The device does not send any operation to the device. The device here is the device in the B domain and reports the fault to the SC.

The A domain device detects the fault and reports it to the A domain DC and switches the service to the protection path.

The A domain device reads the field sent by the SC: resilienceType=IPI&DR, protectionRange=E2E, and restoreRange=NA. The device does not send any operations to the device. The device here is the device in the A domain and reports the fault to the SC.

After receiving the fault, the SC reads the fields: resilienceType=NP&DR, protectionRange=NA, restoreRange=PD, and recalculates the protection path.

Example 7:

As shown in Figure 10, this example provides a preset route recovery method, including:

SC setting field, resilienceType=NP&PR, protectionRange=NA, restoreRange=PD; where NP means no protection; PR means preset route; NA means vacancy; PD here is single-domain recovery.

The SC configures the resources and sets the fields to be sent to the A-domain DC and B-domain DCs: resilienceType=NP&PR, protectionRange=NA, and restoreRange=E2E. This E2E represents end-to-end recovery within a single domain, rather than cross-domain recovery of the entire path.

The A-domain DC and the B-domain DC save the re-routing of the recovery path to the database according to the field sent by the SC, and configure the resources of the devices in the respective domain, but the resource configuration here is not the resource configuration of the recovery path.

The B domain device detects the fault and reports it to the B domain DC.

The B domain device reads the fields sent by the SC: resilienceType=NP&PR, protectionRange=NA, restoreRange=E2E, reads the rerouting from the database, and performs resource configuration of the recovery path based on the read rerouting.

After receiving the configuration resource allocation command of the B domain DC, the B domain device configures the recovery path and switches the service to the recovery path.

The A domain device detects the fault and reports it to the A domain DC.

The A domain device reads the fields sent by the SC: resilienceType=NP&PR, protectionRange=NA, restoreRange=E2E, reads the rerouting from the database, and performs resource configuration of the recovery path based on the read rerouting.

After receiving the configuration resource allocation command of the A domain DC, the A domain device configures the recovery path and switches the service to the recovery path.

After the SC receives the fault, it reads the fields: resilienceType=NP&PR, protectionRange=NA, restoreRange=PD, and does nothing. Any action here refers to the recovery action.

Example 8:

As shown in FIG. 11, the example provides a DC protection recovery method, including:

Received a fault alarm for the device in the domain;

Determine whether the service configuration is “no protection” and “end-to-end recovery”; if yes, determine whether to dynamically reroute, if not, go to other processing flow.

If the dynamic rerouting is performed, it is determined whether the domain is faulty. If the intra-domain rerouting is calculated, the process is terminated.

If it is not dynamic routing, determine whether to pre-reroute.

If it is a preset reroute, read the preset reroute.

If it is not preset rerouting, the prompt status is wrong.

After determining the preset route, it is determined whether the domain is faulty; if the domain is faulty, the configuration is sent to the device to configure the recovery path; if not, whether the domain needs to be modified, for example, the threshold re-routing port is determined. If the configuration of the recovery path is delivered by the device, the process is terminated.

In the several embodiments provided herein, it should be understood that the disclosed apparatus and methods may be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of the unit is only a logical function division. In actual implementation, there may be another division manner, such as: multiple units or components may be combined, or Can be integrated into another system, or some features can be ignored or not executed.

In addition, the coupling, or direct coupling, or communication connection of the components shown or discussed may be indirect coupling or communication connection through some interfaces, devices or units, and may be electrical, mechanical or other forms. of.

The units described above as separate components may or may not be physically separated, and the components displayed as the unit may or may not be physical units, that is, may be located in one place or distributed to multiple network units; Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing module, or each unit may be separately used as one unit, or two or more units may be integrated into one unit; The unit can be implemented in the form of hardware or in the form of hardware plus software functional units.

A person skilled in the art can understand that all or part of the steps of implementing the above method embodiments may be completed by using hardware related to the program instructions. The foregoing program may be stored in a computer readable storage medium, and the program is executed when executed. The foregoing storage device includes the following steps: the foregoing storage medium includes: a mobile storage device, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. A medium that can store program code.

The foregoing is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto, and any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present application. It should be covered by the scope of protection of this application. Therefore, the scope of protection of the present application should be determined by the scope of the claims.

Claims

An optical transport network protection and recovery method based on a software-defined network SDN, which is applied to a controller, and includes:

Obtaining information of a recovery constraint object in an Open Network Foundation ONF model, where the recovery constraint object includes at least: a protection recovery scope field;

Performing a route calculation according to the information of the recovery constraint object;

According to the result of the route calculation, a protection path or a recovery path is configured.
The method of claim 1 wherein

The protection recovery range field is used to determine the scope of the protection recovery and/or the execution subject of the route calculation.
The method of claim 2, wherein

When the controller is the inter-domain controller SC, the performing the route calculation according to the information of the recovery constraint object includes:

When the protection recovery range field indicates end-to-end protection recovery, the SC performs route calculation;

And configuring the protection path or the recovery path according to the result of the route calculation, including:

According to the route calculation performed by the SC, the resource configuration of the pre-configured protection path or the recovery path is performed, and the configuration information of the resource configuration is sent to the domain controller DC of each domain.
The method of claim 2, wherein

When the controller is a DC, the performing the route calculation according to the information of the recovery constraint object includes:

When the protection recovery range field is the domain-by-domain protection recovery, the DC calculates the route calculation of the local domain;

And configuring the protection path or the recovery path according to the result of the route calculation, including:

According to the result of the route calculation performed by the DC, the protection path or the recovery path in the local domain is configured.
The method of claim 4, wherein

The obtaining information of the recovery constraint object in the Open Network Foundation ONF model includes:

The ONF message carrying the information of the restoration constraint object is received from the SC.
The method of claim 1 wherein

The protection constraint object further includes: a protection recovery type field; wherein the protection recovery type field is used to execute an execution entity of the route calculation.
The method of claim 6 wherein

Performing route calculation according to the information of the recovery constraint object, including:

When the protection recovery type field indicates that the recovery type is dynamic reroute recovery, the route of the recovery path is calculated by the DC;

and / or,

When the protection recovery type field indicates that the recovery type is preset reroute recovery, the route of the restoration path is calculated by the SC;

and / or,

When the protection recovery type field indicates that the protection type is the permanent 1+1 protection mode, the route of the protection path is calculated by the SC.
The method according to claim 6 or 7, wherein

The protection recovery type field is further configured to determine a route calculation mode of the protection path or the restoration path;

Performing route calculation according to the information of the recovery constraint object, including:

When the protection recovery type field indicates that the recovery type is dynamic reroute recovery, the route of the recovery path is calculated after detecting the working path failure;

and / or,

When the protection recovery type field indicates that the recovery type is preset reroute recovery, calculating a route of the recovery path before calculating a working path failure;

and / or,

When the protection recovery type field indicates that the protection type is the permanent 1+1 protection mode, the route of the protection path is calculated in advance.
The method of claim 1 wherein

The protection recovery range field includes:

a protection range field, used to indicate a range of the protection path;

A recovery range field indicating the range of the recovery path.
A controller comprising:

An obtaining unit, configured to obtain information of a recovery constraint object in an Open Network Foundation ONF model, where the recovery constraint object includes at least: a protection recovery scope field;

a route calculation unit, configured to perform route calculation according to the information of the recovery constraint object;

The configuration unit is configured to configure a protection path or a recovery path according to the result of the route calculation.
A controller comprising: a network interface, a memory, a processor, and a computer program stored on the memory and executed by the processor;

The processor is coupled to the network interface and the memory, respectively, for implementing the method of any one of claims 1 to 9 by executing the computer program.
A computer storage medium storing a computer program; the computer program being executed to implement the method of any one of claims 1 to 9.