KR20150002474A - Methods for recovering failure in communication networks - Google Patents

Abstract

Disclosed is a method for recovering failure in a communications network. If a controller connected to a plurality of network devices receives a failure generation notice message for reporting failure generation of a first path from a network device, the controller determines a failure recovery level of a first path based on a preset failure recovery policy, and transmits a failure recovery request message for indicating failure recovery of the first path to the network device based on the determined failure recovery level. Therefore, quality of the failure recovery is improved even in an environment with limited resources and the failure recovery can be carried out promptly.

Description

[0001] METHODS FOR RECOVERING FAILURE IN COMMUNICATION NETWORKS [0002]

The present invention relates to a method for handling faults occurring in a communication network.

It is very important to recognize the failure of the path currently in service in the communication network and to recover the failure. Especially, when service level agreement (SLA) based services including failure time, delay, traffic loss, etc. are provided through a communication network, survivability becomes more important.

A method for improving the survivability of a communication network, including studying, operating, managing and maintaining the control plane and management plane aspects of the network for network fault detection and fault recovery : Operation, Administration, and Maintenance) have been actively studied, and related standardization has been carried out.

However, in the conventional failure recovery method, the recovery policy of the path is determined at the time of generation of the specific path, and the determined policy is fixedly applied, so that the recovery quality is good when the failure occurs, but the resource utilization efficiency is bad. Also, in the conventional fault recovery method, when applying a method of finding a new path within a range of available resources at the time of occurrence of a fault, it takes a long time to recover from the failure, or if there is no available resource, The quality of service can not be guaranteed.

In recent years, a forwarding plane and a control plane of a communication system are separated from each other in order to flexibly operate a communication network, to eliminate hardware dependency, and to reduce costs, Software Defined Networking (SDN) technology is being studied.

The Open Networking Foundation (ONF) defines SDN technology that makes it easier to program networks based on OpenFlow. The open-flow-based SDN architecture separates the packet forwarding plane and the control plane of the network and provides a standardized protocol for communication between these two functions. Thus, with open-flow technology, software driven by an external centralized control device can be used to determine the packet path in the switch, regardless of the equipment manufacturer, and to manage traffic more precisely than before. The SDN architecture includes an OpenFlow Switch and a Controller, and the Open Flow Switch and the Controller are interconnected by an open flow protocol.

Recently, studies are being conducted to expand the SDN technology for optical transport networks through OTWG (Optical Transport Working Group).

However, in spite of the above-mentioned SDN technology, there is no specific procedure or method for restoring the network failure by applying the SDN technology.

SUMMARY OF THE INVENTION An object of the present invention is to provide a fault recovery method capable of efficiently performing fault detection and recovery of a communication network and improving resource utilization efficiency of a network.

Other objects and advantages of the present invention will be apparent from the following description taken in conjunction with the accompanying drawings, in which: FIG.

According to an aspect of the present invention, there is provided a fault recovery method performed in a controller connected to a plurality of network devices, the method comprising: requesting a failure recovery setting of a first path; Setting a failure recovery policy of the first path and a recovery path creation request message instructing the network devices constituting the recovery path to generate the recovery path of the first path based on the failure recovery policy of the first path set .

Here, the failure recovery method of the network may include receiving the generation request of the first path, inquiring the resource information for generating the first path, and calculating the first path based on the inquired resource information And transmitting a route creation request message for instructing the network devices constituting the calculated first route to generate the first route.

In the setting of the failure recovery policy of the first path, at least one of the identification information of the first path, the quality class of the failure recovery, the recovery mechanism, and the prior path calculation information may be stored in the database.

Here, the recovery path creation request message may include at least one of identification information of the first path corresponding to the recovery path, type of the recovery path, bandwidth of the recovery path, and information of the network devices constituting the recovery path have.

Here, the failure recovery method of the network may include receiving a recovery path generation notification message indicating completion of generation of a recovery path from at least one network equipment that has transmitted the path generation request message, And storing the state of the first path and the recovery path.

Herein, in the step of storing the recovery path information, at least one of the identification information of the first path, the type of the recovery path corresponding to the first path, the bandwidth of the recovery path, and the network device information constituting the recovery path One information can be stored.

Herein, the step of storing the statuses of the first path and the recovery path may store the activation information of each of the first path and the recovery path.

According to another aspect of the present invention, there is provided a fault recovery method performed in a controller connected to a plurality of network devices, the fault recovery method comprising: The method comprising: receiving an occurrence notification message; determining a failure recovery class of the first path based on a preset failback policy; and instructing the network equipment to failback the first path based on the determined failback class And a failure recovery request message.

Here, the failure occurrence notification message may include at least one of identification information and failure type information of the first path in which the failure occurs.

The step of determining the failure recovery class of the first path includes the steps of inquiring the failure recovery priority of the first path and the state of a protection path from the database, And determining a failure recovery class of the first path based on the state.

Here, the failure recovery request message may include at least one of identification information of a fault path to be recovered and recovery path information.

Here, the failure recovery method of the network may include receiving a failure recovery notification message indicating that the failure recovery of the first path is completed from at least one network device that has transmitted the failure recovery request message, And changing status information of each of the recovery paths.

Here, the method for recovering a failure of the network includes the steps of: calculating a restoration path for failure recovery when a protection path shared by a plurality of paths is in an active state, and storing the restoration path in a database; Determining a failure recovery class of the second path based on a predetermined recovery priority and determining a failure recovery class of the second path based on the determined failback class, And transmitting a failure recovery request message indicating failure recovery of the path. The step of determining the failure recovery level of the second path may include the steps of inquiring the failure recovery priority of the second path and the state of a protection path from the database, Restoration of the second path is restored when the protection path shares the protection path and the protection path is in use for failure recovery and the restoration priority of the second path is lower than the first path And obtaining a restoration path of the second path stored in advance in the database. The failure recovery request message indicating failure recovery of the second path may include restoration path information of the second path.

The step of determining the recovery level of the second path includes the steps of inquiring the failure recovery priority of the second path and the state of the protection path from the database, If the protection path shares a protection path and the protection path is being used for failback of the first path and the restoration priority of the first path is lower than the second path, Determining a restoration level of the first path as Protection, and obtaining a restoration path from the database.

Here, the failure recovery method of the network may include: transmitting a failure recovery request message including the protection path information of the second path to the network equipment; and transmitting, to the network equipment, Receiving a failure recovery notification message of the first path and a failure recovery notification message of the second path from the network equipment; and transmitting the recovery status notification information of the first path and the second path And a step of updating the data.

According to another aspect of the present invention, there is provided a fault recovery method performed by a controller connected to a plurality of network devices, the fault recovery method comprising the steps of: A failure recovery request message for instructing failure recovery to the network equipment when the failure recovery policy of the first path is set to the recovery mode; .

Here, the network failure recovery method may include receiving a failure recovery completion message indicating that the failure recovery from the network equipment is completed, changing the status information of the first path and the recovery path of the first path, As shown in FIG.

Here, in the step of changing the state information, if the state of the first path is changed from a standby state to an active state and the recovery path of the first path corresponds to a restoration path, The restoration path is deleted, and if the recovery path of the first path corresponds to a protection path, the protection path can be switched from active to standby.

A method of recovering a failure in a communication network according to the present invention is a method in which a centralized controller dynamically controls and manages generation and recovery of an LSP (Label Switched Path) to manage a failure recovery method, such as protection or restoration, And thus it is possible to obtain a better failure recovery quality even when a limited resource is used as in the prior art.

In addition, in the present invention, the controller can reduce the processing load on the path calculation for restoration by calculating the restoration path in advance only for the necessary LSP based on the available resource information at the time of necessity of restoration, The restoration can be performed more quickly than the conventional restoration method when necessary.

FIG. 1 is a conceptual diagram illustrating a failure recovery method for each LSP.
2 is a conceptual diagram illustrating a fault recovery method using a centralized controller according to an embodiment of the present invention.
FIG. 3 is a flowchart illustrating a failure recovery policy setting method according to an embodiment of the present invention.
4 is a flowchart illustrating a failure recovery method according to an embodiment of the present invention.
5 is a flowchart illustrating a failure recovery method according to another embodiment of the present invention.
6 is a flowchart illustrating a failure recovery method according to another embodiment of the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail.

It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used in this application is used only to describe a specific embodiment and is not intended to limit the invention. The singular expressions include plural expressions unless the context clearly dictates otherwise. In the present application, the terms "comprises" or "having" and the like are used to specify that there is a feature, a number, a step, an operation, an element, a component or a combination thereof described in the specification, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with the meaning in the context of the relevant art and are to be interpreted in an ideal or overly formal sense unless explicitly defined in the present application Do not.

Hereinafter, a 'controller' referred to in the present invention means a functional entity for controlling a related component (eg, a switch, a router, a node, etc.) The present invention is not limited to the embodiment or implementation position. For example, the controller may refer to a controller functional entity defined in ONF, IETF, ETSI, and / or ITU-T.

The term 'equipment' or 'node' referred to in the present invention means a functional element for substantially forwarding, switching, or routing traffic (or packet). It is defined in ONF, IETF, ETSI and / or ITU-T A switch, a router, a switch element, a router element, a forwarding element, and the like.

It should be noted that the embodiments of the present invention described below can be applied to IEEE, ITU-T, and the like that perform standardization on standard documents and / or transmission networks created in ONF, IETF, ETSI, ITU- T, and IETFs. That is, those of the embodiments of the present invention that are not specifically described in order to clearly illustrate the technical idea of the present invention can be supported by the standard documents prepared by the above standardization bodies. In addition, all terms used in the present invention can be described by the standard document.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In order to facilitate the understanding of the present invention, the same reference numerals are used for the same constituent elements in the drawings and redundant explanations for the same constituent elements are omitted.

Recovery, a key element of network survivability, involves protection and restoration.

The protection method is a method in which a recovery path is allocated in advance in case of a network failure, and a failure path is switched to a recovery path when a network failure occurs. Recovery time of the recovery method is usually very short, within about 50 msec.

The restoration method is a method in which a resource to be used when a network failure occurs is determined in advance, but a recovery path is not allocated in advance. Recovery methods typically take hundreds of milliseconds to several seconds to provide a much longer disaster recovery time than protection. In addition, the restoration method is characterized in that failure recovery can not be guaranteed because the failure can not be recovered when there is no available resource even if the network fails.

The protection scheme can quickly and reliably perform failover by allocating resources in advance for resources to be used for failback in advance, but the resource utilization is lower than the restoration method. On the other hand, since the restoration method does not allocate resources for failure recovery in advance, there is a disadvantage in that it takes a long time to recover if a failure occurs, or the recovery itself can not be performed. However, the availability of resources is higher than the protection method.

The protection scheme and the restoration scheme operate together with the OAM message, the control plane, and the management plane to form a framework for the survivability of the network.

In order to transmit packets in an end-to-end manner in a packet delivery network, a virtual logical tunnel is established. This tunnel is called an LSP (Label Switched Path). In order to accommodate a large number of customers in the set LSP, a pseudo wire (PW) for transmitting a client signal through an AC (Attachment Circuit) is generated. Therefore, a plurality of PWs can be included in one LSP.

 LSP and PW are structures including several PWs in LSP.

On the other hand, the quality grade of failover can be divided into a dedicated protection, a shared protection, and a restoration.

Dedicated protection is a method in which resources are not used for other purposes and are dedicated to protection switching.

Shared protection is a way in which resources are shared for the recovery of multiple services. The sharing ratio of the shared protection is divided into 1: n and m: n. The shared protection scheme includes an end-to-end shared protection scheme sharing the same end points, There is a shared mesh protection scheme in which the protection paths of the nodes share resources. In the shared mesh protection scheme, the endpoints do not necessarily have to be the same.

Also, various protection schemes such as LSP, PW, Link, and Segment are used depending on the object to be restored. For example, LSP protection is used for LSP unit failover and PW protection is used for PW failover.

FIG. 1 is a conceptual diagram illustrating a failure recovery method in units of LSPs, illustrating failure recovery operations when a failure occurs in a working LSP.

1, when a failure occurs in an operating LSP configured between an edge node PE1 101 and a PE2 102 via a node P1 103, the edge nodes PE1 101 and PE2 102, Is notified through the OAM message transmitted / received through the operating LSP. Here, the OAM message may be, for example, a Link Down Indication (LDI) message, a Loss Of Signal (LOS) message, or the like.

Thereafter, the operating LSP is switched to the protection LSP (protection LSP) via the edge node PE1 101 - node P2 104 - node P3 105 - edge node PE2 102, do. Here, the protection LSP can be allocated in advance in case of failure, and the switching from the operating LSP to the protection LSP can be performed by the edge nodes PE1 101 and PE2 102.

Similar to the LSP unit failure recovery method shown in FIG. 1, if failure is detected through the OAM function in the PW unit failure recovery method, a PW protection function is performed according to a pre-set protection policy for each PW.

As described above, in the general failure recovery method, the failure is detected and confirmed mainly by the OAM message, the failure occurrence is tested, and the protection switching is performed. In addition, the path calculation and generation of the operating LSP and the protection LSP are performed by the control plane or the management plane. In this case, the control plane can be selectively used, and a path can be generated by a distributed control plane in which control functions are distributed in each node, such as Generalized Multi-Protocol Label Switching (GMPLS).

In the general failure recovery method, the failure recovery policy corresponding to the LSP generated at the time of creation of the LSP is determined, and the determined failure recovery policy is fixedly applied. For example, the first LSP applies a protection scheme, L1 is set in advance as a protection path, and the second LSP (L2, low recovery quality required) applies a restoration scheme. In case of failure of the first LSP, the failure is recovered by using the preset L1. Therefore, the failure recovery quality is good (within 50 msec), but resource utilization is not good because the resource is always occupied by the bandwidth of L1. On the other hand, when a failure occurs in the second LSP, since the failure is recovered by applying the restoration method, the resource is not occupied in advance compared to the protection method. However, a new path for restoring the failure at the recovery point must be found and generated Therefore, there is a problem that the failure recovery time is delayed, and in the worst case (for example, when there is no available resource), the recovery path can not be found and the failure recovery can not be performed.

In order to solve the inefficiency due to the application of the fixed failure recovery policy of the general failure recovery method in view of the failure recovery of the network, the present invention adopts a centralized controller to efficiently and intelligently control the network, Also, the present invention provides a fault recovery method that can improve the quality of fault recovery even in an environment where the resource utilization efficiency is improved.

In other words, according to the present invention, the centralized controller dynamically determines the recovery policy and the failure recovery method of all the LSPs according to the network status, thereby recovering the failure Even when using the same resources as before, it is possible to guarantee a higher failure recovery quality than existing failure recovery methods.

In addition, according to the present invention, even when a restoration method is applied to a fault recovery method, the centralized controller can calculate a restoration path in advance and restore the fault more quickly than the existing restoration method, .

Hereinafter, a fault recovery method according to embodiments of the present invention will be described in more detail with reference to the drawings.

FIG. 2 is a conceptual diagram for explaining a failure recovery method using a centralized controller according to an embodiment of the present invention, conceptually illustrating the configuration of a packet transfer network into which the controller 200 is introduced.

2, a fault recovery method according to an embodiment of the present invention can be performed in an environment where a plurality of network devices (or network nodes) 201 and 202 constituting a network are connected to the controller 200. [ 2, two network devices 201 and 202 are connected to the controller 200. However, the controller 200 may be connected to a plurality of network devices in addition to the network devices shown in FIG. 2 Should be understood. Hereinafter, it is assumed that the controller 200 knows the information of the network devices 201 and 202 connected to the controller 200 and the overall network configuration information.

The controller 200 may include a path setting unit 210 and a fault recovery unit 220. The path setting unit 210 and the fault recovery unit 220 may operate in conjunction with each other. Here, the path setting unit 210 and the failure recovery unit 220 are elements classified according to functions, and are not limited to physical configuration types. For example, the path setting unit 210 and the failure recovery unit 220 may be configured as separate hardware or software modules processed by one processor.

Upon receiving the LSP creation request, the controller 200 centrally calculates a path and transmits a path creation request message to the corresponding network equipment, which instructs the setting of the calculated path, to generate an operating LSP (working LSP) have. Here, the path calculation and transmission of the path creation request message may be performed by the path setting unit 210. [

In addition, the controller 200 can set a recovery policy against the failure of the LSP according to the recovery policy provided by the network operator or the default recovery policy when the LSP is created. For example, the controller 200 may control the network devices 201 and 202 so that a protection LSP (protection LSP) corresponding to the LSP1 is generated when the LSP1 is generated. Alternatively, the controller 200 may determine the recovery policy by intelligently determining the recovery policy at the time of performing the failure recovery after recognizing the failure occurrence of the LSP. For example, when the operation LSPn fails, the controller 200 can generate a restoration LSP to replace the failure occurrence path. The recovery policy of the LSP can be set by the failure recovery unit 220.

The interworking between the controller 200 and the plurality of network devices 201 and 202 can be performed through the CDPI (Control Data Plane Interface) standardized in the ONW OTWG.

Messages exchanged between the controller 200 and the plurality of network devices 201 and 202 may include the following messages.

- Path generation request message: a message transmitted from the controller 200 to the network equipment 201, 202, and used for instructing path generation.

- Route creation notification message: A message sent by the network equipment (201, 202) to the controller (200), used to indicate completion of route creation.

- failure occurrence notification message: a message transmitted from the network equipments 201 and 202 to the controller 200, and used to notify the controller 200 of the failure occurrence.

Failure Request Message: A message sent by controller 200 to network equipment 201, 202, used to indicate failover.

Failure Notification Message: A message sent by the network equipment (201, 202) to the controller (200), used to indicate the completion of a failover.

The CDPI messages illustrate some of the messages used in the present invention, and the messages used in the failure recovery method according to the present invention are not limited to the messages. That is, various CDPI messages may be used for the messages used in the failure recovery method according to the present invention, as in the embodiments described below, in addition to the messages.

On the other hand, the controller 200 manages path information for each LSP when creating, modifying or deleting LSPs. Here, the controller 200 can manage path information for each LSP by using a separate path database 230. [ For example, the controller 200 may refer to the route database 230 to perform a corresponding operation when creating, modifying, or deleting an LSP, and may store the execution result in the route database 230. Such an operation can be performed by the path setting unit 210.

The controller 200 can manage the recovery status information for each LSP when the failure occurs in the LSP and the failure recovery is performed. Here, the controller 200 can manage the LSP-specific status and recovery status information using a separate recovery database 240, and the recovery database 240 stores the LSP-specific recovery policy and recovery status information of the failed path . Such an operation can be performed by the failure recovery unit 220. [

FIG. 3 is a flowchart illustrating a failure recovery policy setting method according to an embodiment of the present invention.

3 illustrates an example of a process of generating a LSP1 and setting a policy for failure recovery of the LSP1 when a request for generating an LSP1 that connects network devices occurs in a packet-forwarding network environment in which a controller is connected to a plurality of network devices It is. It is assumed that the recovery class uses a protection scheme. In FIG. 3, PE1 and PEn denote the edge nodes on both sides of LSP1, and the transit nodes on the path of LSP1 are denoted as P1 and P2.

Referring to FIG. 3, the controller receives a request to create an LSP1 from an operator, an operating system, or an external system (S301). At this time, the generation request includes information such as edge node information (e.g., PE1 and PEn), bandwidth, quality of service (QoS) information, service level agreement (SLA) .

In addition, the controller may be provided with a recovery policy setting request of the LSP 1 from the operator, the operating system, or the external system (S302). In this case, the recovery policy setting request is not necessarily provided. If the recovery policy setting request is not provided separately, the controller may set the recovery policy of LSP1 according to the recovery policy set by default according to the characteristics such as SLA or QoS of LSP1 have. The request to set up the recovery policy can include information such as the quality grade of the failover, the recovery mechanism, and whether to calculate the pre-path for fast restoration. The quality class information of the failover may include class setting information such as dedicated protection, shared protection, restoration, and the like. Recovery mechanism information may include share ratio information such as 1: 1, 1: n, m: n, and so on.

When the controller is provided with the recovery policy setting request for the LSP1, the controller may store information such as the recovery-target LSP information (i.e., LSP1), the quality class of the failure recovery, the recovery mechanism, .

The controller inquires the resource information, calculates the path of the LSP1 based on the inquired resource, and transmits a path creation request message requesting generation of the LSP1 to each node on the path constituting the calculated LSP1 (S304) . Here, the path creation request message may include the identification information of the LSP to be generated (i.e., LSP1), the bandwidth, the node information on the LSP1 path (e.g., PE1, P1, P2, ..., PEn ), And the like.

In addition, the controller calculates a protection path for the LSP1, and transmits a recovery path creation request message for requesting generation of a protection LSP (protection LSP) of each node on the path constituting the calculated protection path (S305). Here, the recovery path generation request message may include a CDPI message, and may include a LSP identification information (i.e., LSP1) corresponding to the protection LSP, a type of recovery path (i.e., protection LSP) For example, PE1, P1 ', P2', ..., PEn). (Eg, PE1, PEn) are the same as LSP1, but the transit nodes (eg, P1 ', P2', ...) of the protected LSP are the same as the LSP1 (E.g., P1, P2,.

In step S303, the nodes (e.g., PE1, P1, P2, ..., PEn) that have received the path creation request message for the LSP1 generate LSP1 and then instruct the controller to generate the LSP1 The route creation notification message is transmitted (S306). Here, the path creation notification message may include a CDPI message and identification information of the generated LSP (i.e., LSP1).

In step S307, the nodes (for example, PE1, P1 ', P2', ..., PEn) that have received the recovery path creation request message for the protection LSP generate the protection LSP, And transmits a recovery path generation notification message indicating the success of the recovery path generation notification message (S307). Here, the recovery path generation notification message CDPI message may be used, LSP identification information (i.e., LSP1) corresponding to the generated protection LSP, and protection LSP information may be included.

Upon receiving the path creation notification message and the recovery path creation notification message from the nodes, the controller stores path information and recovery path information of the generated LSP in the path database (S308). At this time, the controller can store identification information of the generated LSP and the protection LSP, bandwidth, node information on each path, and the like in the path database.

In addition, the controller stores the generated LSP (i.e., LSP1) and the status information of the protected LSP in the recovery database (S309). For example, the controller can store the status information of LSP1 as active (LSP1, Active) and the status information of the protection LSP as standby (Protection LSP, Standby).

4 is a flowchart illustrating a failure recovery method according to an embodiment of the present invention.

FIG. 4 illustrates a failure recovery process in the case where LSP1 and LSP2 are set in a packet-forwarding network environment in which a controller is connected to a plurality of network devices, and a failure occurs in the order of LSP1 and LSP2 (redundant failure occurs). In FIG. 4, LSP1 and LSP2 are operated in a shared protection scheme sharing one protection LSP, and the recovery quality class (or restoration priority) of LSP1 is less than the recovery quality class of LSP2 High. In FIG. 4, PE1 and PEn denote both edge nodes of LSP1 and LSP2, and the transit nodes on the paths of LSP1 and LSP2 are denoted by P1 and P2, respectively.

Referring to FIG. 4, when a failure occurs in the LSP1, the PE1 and the PEn transmit a failure notification message to the controller (S401). Here, the failure occurrence notification message may be a CDPI message, and may include identification information of the failed path (i.e., LSP1) and failure type information.

Upon receiving the failure notification message for the LSP1, the controller inquires the recovery policy of the LSP1 and the status of the protection (protection LSP) from the recovery database to determine the recovery level of the LSP1 (S402). Here, the recovery class of LSP1 is shared protection as described above, and it is assumed that a protection LSP (protection LSP) is used.

Thereafter, the controller transmits a failure recovery request message to PE1 and PEn according to the determined recovery class (S403). Here, the failback request message may be a CDPI message, and may include recovery target LSP identification information (i.e., LSP1) and recovery path information (i.e., protection LSP).

Upon receiving the failure recovery request message from the controller, PE1 and PEn perform failback to LSP1. Here, PE1 and PEn can perform path switching to the protection LSP included in the failure recovery request message. Thereafter, the PE1 and the PEn transmit a failure recovery notification message to the controller indicating that the failover has successfully completed (S404). The failback notification message may be a CDPI message and may include information on the LSP to be recovered (i.e., LSP1) and recovery path (i.e., protected LSP).

Upon receiving the failure recovery notification message from the PE1 and the PEn, the controller changes the status information of the LSP1 and the protection LSP stored in the recovery database (S405). Here, the controller can change the status of the protection LSP from Standby to Active (i.e., Protection LSP, Active) by changing the state of the LSP1 from Up to Down (i.e., LSP1, Down).

If a failure occurs in the LSP2, the PE1 and the PEn transmit a failure notification message to the controller (S406). Here, the failure occurrence notification message may be a CDPI message, and may include identification information of a failure path (i.e., LSP2) and failure type information.

Upon receipt of the failure notification message for the LSP2, the controller inquires the recovery policy of the LSP2 and the status of the protection LSP (Protection LSP) from the recovery database, and determines the recovery level of the LSP2 according to the priority (S407). In Figure 4, because LSP1 and LSP2 share a protected LSP and the recovery quality class (or restoration priority) of LSP1 is assumed to be higher than LSP2 and the protected LSP has already been used to recover LSP1, It is decided to use restoration.

On the other hand, when the controller is selected to perform the pre-path calculation when it is necessary to apply the restoration to the restoration policy of the LSP2, when the restoration of the LSP2 is required (that is, after the LSP1 has failed and occupies the protection LSP, The restoration path for the LSP2 is calculated according to a predetermined period only and the restoration path is stored in the path database. For example, the controller may change the state information of the LSP1 and the protection LSP through execution of step S405, and then calculate the restoration path for the LSP2 in advance.

When the controller is selected to perform the pre-path calculation when applying the restoration to the restoration policy, upon receiving the failure notification message of the LSP2, the controller inquires restoration path information calculated in advance in the path database (S408). In this case, the restored path information to be inquired may include LSP information (i.e., LSP2) and restored LSP path information to which the restored path is to be applied.

Thereafter, the controller transmits a failure recovery request message to the PE1 and the PEn according to the retrieved restoration path information (S409). Here, the failback request message may be a CDPI message, and may include path information of the LSP to be recovered (i.e., LSP2) and the protection LSP.

Upon receiving the failure recovery request message from the controller, the PE1 and the PEn establish a recovery path for the LSP2 according to the protection LSP path information included in the received failure recovery request message, and issue a failure recovery notification indicating that the failure recovery has been successfully completed The message is transmitted to the controller (S410). The failback notification message may be a CDPI message, and may include recovery LSP identification information (i.e., LSP2) and protection LSP information.

Upon receiving the failure recovery notification message from the PE1 and the PEn, the controller changes the path information of the restoration path stored in the path database (S411).

Further, the controller changes the state information of the LSP 2 stored in the recovery database (S412). Here, the controller can change the state of the restored LSP from Standby to Active (i.e., Restoration LSP, Active) by changing the state of the LSP2 from Up to Down (i.e., LSP2, Down).

The failure recovery method as shown in FIG. 4 can also be applied to a case where 1: n, m: n shared protection is applied as a failure recovery policy to two or more LSPs.

5 is a flowchart illustrating a failure recovery method according to another embodiment of the present invention.

5, when LSP1 and LSP2 are operated in a shared protection scheme sharing one protection LSP (protection LSP) and the recovery quality class (or restoration priority) of LSP2 is higher than the recovery quality class of LSP1 When the failure occurs in the order of LSP1 and LSP2 in the set state, the process of dynamically performing optimal recovery is illustrated. In FIG. 5, PE1 and PEn denote both edge nodes of LSP1 and LSP2, and the transit nodes on the paths of LSP1 and LSP2 are denoted by P1 and P2, respectively.

Referring to FIG. 5, when a failure occurs in the LSP1, the PE1 and the PEn transmit a failure notification message to the controller (S501). Here, the failure occurrence notification message may be a CDPI message, and may include identification information of the failed path (i.e., LSP1) and failure type information.

Upon receiving the failure notification message for the LSP1, the controller inquires the recovery policy of the LSP1 and the status of the protection (protection LSP) from the recovery database to determine the recovery level of the LSP1 (S502). Here, the recovery class of LSP1 is shared protection as described above, and it is assumed that a protection LSP (protection LSP) is used.

Thereafter, the controller transmits a failure recovery request message to PE1 and PEn according to the determined recovery class (S503). Here, the failure recovery request message may be a CDPI message, and may include recovery target LSP identification information (i.e., LSP1) and protection LSP information.

Upon receiving the failure recovery request message from the controller, PE1 and PEn perform failback to LSP1. Here, PE1 and PEn can perform path switching to the protection LSP included in the failure recovery request message. Then, the PE1 and the PEn transmit a failure recovery notification message to the controller indicating that the failure recovery has been successfully completed (S504). The failback notification message may be a CDPI message, and may include recovery LSP identification information (i.e., LSP1) and protection LSP information.

Upon receiving the failure recovery notification message from the PE1 and the PEn, the controller changes the status information of the LSP1 and the protection LSP stored in the recovery database (S505). Here, the controller can change the status of the protection LSP from Standby to Active (i.e., Protection LSP, Active) by changing the state of the LSP1 from Up to Down (i.e., LSP1, Down).

Thereafter, when a failure occurs in the LSP2, the PE1 and the PEn transmit a failure notification message to the controller (S506). Here, the failure occurrence notification message may be a CDPI message, and may include identification information of a failure path (i.e., LSP2) and failure type information.

Upon receiving the failure notification message for the LSP2, the controller inquires the recovery policy of the LSP2 and the status of the protection LSP (Protection LSP) from the recovery database, and determines the recovery level of the LSP2 according to the priority (S507). 5, it is determined that LSP1 and LSP2 share the protection LSP and that the recovery quality class (or restoration priority) of LSP2 is higher than LSP1, so the controller determines to apply protection LSP (protection LSP) to the recovery class of LSP2 do.

Thereafter, the controller transmits a failure recovery request message to PE1 and PEn according to the determined recovery class of the LSP2 (i.e., protection LSP) (S508). Here, the failure recovery request message may be a CDPI message, and may include recovery target LSP identification information (i.e., LSP2) and protection LSP information.

5, it is assumed that the LSP1 and the LSP2 operate in a manner sharing the protection LSP. Therefore, in order to allocate the protection LSP allocated to the failed LSP1 to the LSP2, the protection LSP allocated to the LSP1 must be changed to the restoration LSP .

In order to cope with this situation, when the controller is selected to perform the preliminary path calculation when it is necessary to apply the restoration to the recovery policy setting of the LSP1, when the restoration of the LSP1 is required (that is, when the protection LSP Is occupied and there is a possibility of application of the restoration LSP to the LSP1), the restoration path for the LSP1 is calculated according to a predetermined period and stored in the path database. For example, the controller may change the state information of the LSP1 and the protection LSP through execution of step S505, and then calculate the restoration path of the LSP1 in advance in case the failure occurs in the LSP2 having a high priority.

Upon receiving the failure notification message of the LSP2 having a higher priority than the LSP1, the controller inquires restoration path information of the LSP1 calculated in the path database in operation S509. In this case, the restored path information to be inquired may include LSP information (i.e., LSP1) and restored LSP path information to which the restored path is to be applied.

Thereafter, the controller transmits a failure recovery request message to the PE1 and the PEn according to the retrieved restoration path information (S510). Here, the failure recovery request message may be a CDPI message, and may include recovery target LSP identification information (i.e., LSP1) and restored LSP path information.

On the other hand, the PE1 and the PEn which have received the failure recovery request message from the controller in step S508 set the restoration path for the LSP2 according to the protection LSP information included in the received failure recovery request message, and indicate that the failure recovery has been completed successfully And transmits a failure recovery notification message to the controller (S511). The failback notification message may be a CDPI message, and may include recovery LSP identification information (i.e., LSP2) and protection LSP information.

In step S510, the PE1 and the PEn that have received the failure recovery request message for the LSP1 from the controller set a restoration path for the LSP1 according to the restoration LSP path information included in the received failure recovery request message, A failure recovery notification message indicating completion is transmitted to the controller (S512). The failback notification message may be a CDPI message, and may include recovery object LSP identification information (i.e., LSP1) and restoration LSP information.

Upon receiving the failure recovery notification message from the PE1 and the PEn, the controller changes the path information for the restoration path stored in the path database (S513).

In addition, the controller changes the state information of the LSP2 stored in the recovery database (S514). Here, the controller can change the state of the protection LSP from Standby to Active (i.e., Protection LSP, Active) from the state of the LSP2 to the state of Up to down (i.e., LSP2, Down).

Since the state information of the LSP1 has been changed, the controller changes the state information of the LSP1 stored in the recovery database (S5145). Here, the controller changes the state of the LSP1 from Up to Down (i.e., LSP1, Down) From Standby to Active (that is, Restoration LSP, Active).

The failure recovery method as shown in FIG. 5 can also be applied to a case where 1: n, m: n shared protection is applied as a failure recovery policy to two or more LSPs.

In Fig. 5, steps S508 to S512 may be configured to execute in a different order according to the failback policy. For example, after step S507 is executed, it may be configured to be executed in the order of steps S509, S510, S512, S508, and S512.

6 is a flowchart illustrating a failure recovery method according to another embodiment of the present invention.

In FIG. 6, LSP1 and LSP2 are operated in a shared protection scheme in which one protection LSP (protection LSP) is shared, and as shown in FIG. 4, redundancy failure occurs in the order of LSP1 and LSP2, And the process of returning the LSPs to the original state when the failure of LSP1 and LSP2 is solved after completion. Hereinafter, it is assumed that a revertive mode is set to return to the initial state when the failure of the LSP is resolved by the failure recovery policy. In FIG. 6, PE1 and PEn denote both edge nodes of LSP1 and LSP2, and the transit nodes on the paths of LSP1 and LSP2 are denoted by P1 and P2, respectively.

Referring to FIG. 6, when the fault is eliminated in the LSP1, the edge nodes PE1 and PEn on both sides of the LSP1 transmit a fault clearance message indicating that the fault has been eliminated to the controller (S601). Here, the fail-over message may be composed of a CDPI message and may include identification information of the failed LSP (i.e., LSP1).

Upon receiving the failure resolution message, the controller inquires the failure recovery policy and status of the LSP 1 in the recovery database based on the identification information included in the failure resolution message (S602). Here, the controller can know that the failure has occurred with the status information of the LSP 1, and that the failure recovery policy is set to the retrieve mode.

The controller transmits a failure return request message to the PE1 and the PEn as the failure recovery policy of the LSP1 is set to the recovery mode (S603). Here, the failure recovery request message may be composed of a CDPI message, and may include identification information (i.e., LSP1) of the failure recovery target LSP and protection LSP (Protection LSP) information.

The PE1 and the PEn perform fault recovery for the LSP1 according to the fault return request message received from the controller, and transmit a fault return complete message to the controller indicating that the fault recovery has been successfully completed (S604). Here, the failure return complete message may be composed of a CDPI message, and may include identification information LSP1 of the completed failure recovery and protection LSP (Protection LSP) information.

Upon receiving the failure recovery completion message, the controller changes the status information of the LSP1 and the protection LSP in the recovery database (S605). For example, the controller can change the status information of the LSP1 to active (LSP1, Active) and the status information of the protection LSP to standby (Protection LSP, Standby).

Thereafter, when the failure is eliminated in the LSP 2, the PE 1 and the PEn transmit a failure solicitation message indicating that the failure of the LSP 2 has been solved to the controller (S 606). Here, the fail-over message may be composed of a CDPI message and may include identification information (i.e., LSP2) of the failed LSP.

Upon receiving the failure resolution message, the controller inquires the failure recovery policy and status of the LSP2 in the recovery database based on the identification information (i.e., LSP2) included in the failure resolution message (S607). Here, the controller can know from the status information of the LSP 2 that the failure occurrence fact and the failure recovery policy are set to the retrieve mode.

The controller transmits a failure return request message to the PE1 and the PEn as the failure recovery policy of the LSP2 is set to the recovery mode (S608). Here, the failure recovery request message may be composed of a CDPI message, and may include identification information (i.e., LSP2) of the failure recovery target LSP and restoration LSP information.

The PE1 and the PEn perform fault recovery for the LSP2 in response to the fault return request message received from the controller, and transmit a fault return complete message to the controller indicating that the fault recovery has been successfully completed (S609). Here, the failure return complete message may be composed of a CDPI message, and may include identification information LSP2 of restored LSP and restoration LSP information.

Upon receiving the failure return complete message, the controller deletes the information on the restoration path in the path database (S610).

In addition, the controller changes the status information about the LSP2 in the recovery database and deletes the information on the restoration LSP (S611). For example, the controller may change the state information of the LSP2 to be active (LSP2, Active), and the state information of the protected LSP may be deleted (Delete Restoration LSP).

The failure recovery method as shown in FIG. 6 can also be applied to a case where 1: n, m: n shared protection is applied as a failure recovery policy to two or more LSPs.

It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. It will be possible.

101: edge node PE1 102: edge node PE2
103: node P1 104: node P2
105: node P3 200: controller
201: Network equipment 202: Network equipment
210: path setting unit 220:
230: path database 240: recovery database

Claims (20)

A failure recovery method performed on a controller connected to a plurality of network devices,
Receiving a failure recovery setting of a first path;
Setting a failure recovery policy of the first path; And
And transmitting a recovery path generation request message for instructing creation of a recovery path of the first path to the network devices constituting the recovery path based on the failure recovery policy of the first path. In claim 1,
The method for restoring the network includes:
Receiving a generation request of the first path;
Inquiring resource information for generating the first path, and calculating the first path based on the inquired resource information; And
Further comprising the step of transmitting a path generation request message instructing generation of the first path to the network devices constituting the calculated first path. In claim 1,
Wherein the setting of the failure recovery policy of the first path comprises:
Wherein at least one of the identification information of the first path, the quality class of the failure recovery, the recovery mechanism, and the prior path calculation information is stored in the database. In claim 1,
The recovery path creation request message includes:
Wherein the information includes at least one of identification information of the first path corresponding to the recovery path, type of the recovery path, bandwidth of the recovery path, and information of the network devices constituting the recovery path. In claim 1,
The method for recovering a fault in the network includes:
Receiving a recovery path generation notification message indicating completion of generation of a recovery path from at least one network equipment that has transmitted the path creation request message;
Storing information of the recovery path; And
Further comprising the step of storing the state of the first path and the recovery path. In claim 5,
Wherein the step of storing information of the recovery path comprises:
And information on at least one of identification information of the first path, type of the recovery path corresponding to the first path, bandwidth of the recovery path, and network equipment information constituting the recovery path. How to recover from a failure. In claim 5,
Wherein the storing the state of the first path and the recovery path comprises:
And storing information on whether the first path and the recovery path are activated, respectively. A failure recovery method performed on a controller connected to a plurality of network devices,
Receiving a failure occurrence notification message notifying a failure of a first path from a network device;
Determining a failure recovery class of the first path based on a preset failover policy; And
And sending a failure recovery request message to the network equipment indicating failure recovery of the first path based on the determined failure recovery class. In claim 8,
Wherein the failure notification message includes at least one of identification information of the first path and failure type information of the failed path. In claim 8,
The method of claim 1, wherein determining the failure recovery class of the first path comprises:
Inquiring the status of the protection path and the failure recovery priority of the first path from the database; And
And determining a failback class of the first path based on the failback priority and the state of the protection path. In claim 8,
The failure recovery request message includes:
The identification information of the faulty path to be restored, and the recovery path information. In claim 11,
The method for restoring the network includes:
Receiving a failure recovery notification message indicating that failure recovery of the first path is completed from at least one network equipment that has transmitted the failure recovery request message; And
Further comprising changing status information of each of the first path and the recovery path. In claim 8,
The method for restoring the network includes:
When a protection path shared by a plurality of paths is in an active state, calculating and restoring a restoration path for failback to a database;
Receiving a failure occurrence notification message notifying the occurrence of a failure of a second path from the network equipment;
Determining a failure recovery class of the second path based on a preset recovery priority; And
And sending a failure recovery request message instructing the network equipment to fail back on the second path based on the determined failback class. In claim 13,
Wherein determining the failback class of the second path comprises:
Retrieving a status of a protection path and a failure recovery priority of the second path from a database;
When the first path and the second path share a protection path and the protection path is in use for failure recovery and the restoration priority of the second path is lower than the first path, Determining a failure recovery grade as restoration; And
And acquiring a restoration path of the second path previously stored in the database. In claim 14,
Wherein the failure recovery request message indicating failure recovery of the second path includes restoration path information of the second path. In claim 13,
Wherein the step of determining the degree of recovery of the second path comprises:
Inquiring a failure recovery priority of the second path and a state of a protection path from a database;
When the first path and the second path share a protection path and the protection path is in use for failure recovery of the first path and the recovery priority of the first path is lower than the second path, Determining a restoration degree of the first path as protection and a restoration degree of the first path as restoration; And
And obtaining a restoration path from the database. In claim 16,
The method for restoring the network includes:
Transmitting a failure recovery request message including protection path information of the second path to the network equipment;
Transmitting a failure recovery request message including restoration path information of the first path to the network equipment;
Receiving a failure recovery notification message of the first path and a failure recovery notification message of the second path from the network equipment; And
Further comprising updating the recovery status information of the first path and the second path. A failure recovery method performed on a controller connected to a plurality of network devices,
Receiving a failure solicitation message indicating that the failure of the first path has been eliminated from the network equipment;
Obtaining a failure recovery policy of the first path; And
And transmitting a failure recovery request message indicating failure recovery to the network equipment when the failure recovery policy of the first path is set to the recovery mode. In claim 18,
The method for recovering a fault in the network includes:
Receiving a failure recovery completion message indicating that the failure recovery is completed from the network equipment;
Further comprising changing status information of the recovery path of the first path and the first path. In claim 18,
Wherein the step of modifying the state information comprises:
Wherein if the recovery path of the first path corresponds to the restoration path, the restoration path is deleted from the database, and the path of the first path is changed to the active state of the first path, And switching the state of the protection path from active to standby if the recovery path corresponds to a protection path.

Images