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

Abstract

A network failure recovery method is disclosed. When the controller connected to the plurality of network devices receives a failure notification message notifying the occurrence of a failure of the first path from the network equipment, the controller determines the failure recovery level of the first route based on a preset failure recovery policy, and determines the determined failure. A failure recovery request message instructing the network device to recover from the first path is transmitted based on the recovery level. Accordingly, even in an environment using limited resources, the quality of failure recovery can be improved, and failure recovery can be processed quickly.

Description

How to recover from failures in communication networks {METHODS FOR RECOVERING FAILURE IN COMMUNICATION NETWORKS}

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

When a failure occurs in a currently serviced path in a communication network, it is very important to quickly recognize it and recover from the failure. In particular, survivability becomes more important when a service based on a Service Level Agreement (SLA) including failure time, delay, and traffic loss is provided through a communication network.

As a method to improve the survivability of communication networks, research, operation, management and maintenance of the network's control plane and management plane (OAM) for network failure detection and failure recovery, etc. : Operation, Administration, and Maintenance) research is being actively conducted, and related standardization has been conducted.

However, in the conventional failure recovery method, the recovery policy of the path is determined at the time of creation of a specific path, and the determined policy is fixedly applied, so that the recovery quality is good when a failure occurs, but the resource use efficiency is bad. In addition, in the case of applying a method of finding a new path within the range of available resources at the time of failure in the conventional failure recovery method, failure recovery takes a lot of time, or if there is no available resource, failure recovery is performed. There is a disadvantage that the quality of service cannot be guaranteed because it is not possible.

On the other hand, in recent years, the forwarding plane and control plane of the communication system are separated for flexible operation of the communication network, avoiding hardware dependency, and cost reduction, so that the network can be controlled centrally by software, just like software programming. Software defined networking (SDN: Software Defined Networking, hereinafter abbreviated as'SDN') technology is being studied.

ONF (Open Networking Foundation) has defined SDN technology that can more easily program networks based on OpenFlow. In the openflow-based SDN structure, the packet forwarding plane and the control plane of the network are separated, and a standardized protocol for communication between these two functions is provided. Therefore, if the openflow technology is used, it is possible to determine the packet path in the switch irrespective of the equipment manufacturer by using software running in an external centralized control device, and to manage traffic more precisely than before. The SDN structure includes an openflow switch and a controller, and the openflow switch and controller are interconnected by an openflow protocol.

In addition, recently, research to expand and apply SDN technology to an optical transport network is underway through the OTWG (Optical Transport Working Group).

However, despite the advent of the SDN technology as described above, until now, a procedure or method for recovering a network failure by applying the SDN technology has not been specifically presented.

An object of the present invention for overcoming the above-described disadvantages is to provide a failure recovery method capable of efficiently performing failure detection and restoration of a communication network and improving the efficiency of using resources of a network.

Objects to be achieved in the present invention are not limited to the above objects, and other objects not mentioned will be clearly understood by those of ordinary skill in the technical field to which the present invention belongs from the following description.

A failure recovery method according to an aspect of the present invention for achieving the object of the present invention is a failure recovery method performed in a controller connected to a plurality of network devices, the step of receiving a request for setting a failure recovery of a first path; The step of setting a failure recovery policy of the first path and a recovery path generation request message instructing network equipment configuring a recovery path to generate a recovery path of the first path based on the set failure recovery policy of the first path And transmitting.

Here, in the network failure recovery method, receiving a request for generating the first path, querying resource information for generating the first route, and calculating the first route based on the retrieved resource information. And transmitting a path generation request message instructing the generation of the first path to network devices configuring the calculated first path.

Here, in the step of setting the failure recovery policy of the first path, at least one of identification information of the first path, a quality level of failure recovery, a recovery mechanism, and pre-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, the type of the recovery path, the bandwidth of the recovery path, and information on network devices constituting the recovery path. have.

Here, the network failure recovery method includes the steps of receiving a recovery path generation notification message indicating completion of the recovery path generation from at least one network equipment that has transmitted the path generation request message, and storing information on the recovery path. And storing the states of the first path and the recovery path.

Here, in the storing of the information on the recovery path, at least one of identification information of the first path, the type of the recovery path corresponding to the first path, the bandwidth of the recovery path, and network equipment information constituting the recovery path One piece of information can be stored.

Here, in the step of storing the state of the first path and the recovery path, information on whether to activate each of the first path and the recovery path may be stored.

In addition, a failure recovery method according to another aspect of the present invention for achieving the object of the present invention is a failure recovery method performed in a controller connected to a plurality of network equipment, and a failure of notifying the occurrence of a failure of the first path from the network equipment. Receiving an occurrence notification message, determining a failure recovery level of the first path based on a preset failure recovery policy, and instructing the network equipment to recover from a failure of the first path based on the determined failure recovery level And transmitting 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 where a failure occurs.

Here, the determining of the failure recovery level of the first path includes inquiring a failure recovery priority of the first path and a state of a protection path from the database, and the failure recovery priority and the protection path. It may include the step of determining a failure recovery level of the first path based on the state.

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

Here, the network failure recovery method includes the steps of 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 the first path and It may further include changing state information of each of the recovery paths.

Here, the network failure recovery method includes calculating a restoration path for failure recovery and storing it in a database when a protection path shared by a plurality of paths is in an active state, and the second path from the network device Receiving a failure occurrence notification message for notifying the occurrence of a failure, determining a failure restoration level of the second path based on a preset restoration priority, and the second network equipment to the network device based on the determined failure restoration grade. It may further include the step of transmitting a failure recovery request message instructing the failure recovery of the path. In addition, the determining of the failure recovery level of the second path may include inquiring a failure recovery priority of the second path and a state of a protection path from a database, and the first path and the second path When the protection path is shared, the protection path is being used for failure recovery, and the recovery priority of the second path is lower than that of the first path, the failure recovery level of the second path is set to Restoration. It may include determining and obtaining a restoration path of the second path previously stored in the database. In addition, the failure recovery request message indicating failure recovery of the second path may include restoration path information of the second path.

Here, the step of determining the recovery level of the second path includes inquiring a failure recovery priority of the second path and a state of a protection path from a database, and the first path and the second path When the protection path is shared, the protection path is being used for failure recovery of the first path, and the recovery priority of the first path is lower than that of the second path, the recovery level of the second path is protected. With (Protection), it may include determining a restoration level of the first path as restoration, and obtaining a restoration path from the database.

Here, the network failure recovery method includes transmitting a failure recovery request message including protection path information of the second path to the network device, and the recovery path information of the first path to the network device. Transmitting a failure recovery request message, receiving a failure recovery notification message of the first path and a failure recovery notification message of the second path from the network device, and recovery status information of the first path and the second path It may further include the step of updating.

A failure recovery method according to another aspect of the present invention for achieving the object of the present invention is a failure recovery method performed in a controller connected to a plurality of network equipment, and a failure indicating that the failure of the first path has been resolved from the network equipment. Receiving a resolution message, obtaining a failure recovery policy of the first path, and when the failure recovery policy of the first path is set to a recovery mode, a failure recovery request message instructing the network equipment to recover from a failure is sent. And transmitting.

Here, the method of recovering from a failure of the network includes receiving a failure recovery completion message indicating that the failure recovery is completed from the network device, and changing state information of the first path and the recovery path of the first path. It may further include.

Here, in the step of changing the state information, the state of the first path is changed from standby to active, and if the recovery path of the first path corresponds to a restoration path, the database When the restoration path is deleted and the restoration path of the first path corresponds to a protection path, the state of the protection path may be changed from active to standby.

The failure recovery method in a communication network according to the present invention provides a network failure recovery method such as protection or restoration by dynamically controlling and managing the creation and recovery of a label switched path (LSP) by a centralized controller. It can be optimized according to the situation of, and through this, better failure recovery quality can be obtained even when limited resources are used as in the prior art.

In addition, in the present invention, the controller calculates the restoration path in advance only for the required LSP based on the resource information available at the time when restoration is required, thereby reducing the processing load for the path calculation for restoration, and When necessary, restoration can be performed more quickly than conventional restoration methods.

1 is a conceptual diagram illustrating a failure recovery method in units of LSPs.
2 is a conceptual diagram illustrating a failure recovery method using a centralized controller according to an embodiment of the present invention.
3 is a flowchart illustrating a method of setting a failure recovery policy according to an embodiment of the present invention.
4 is a flowchart illustrating a method for recovering from a failure according to an embodiment of the present invention.
5 is a flow chart showing a failure recovery method according to another embodiment of the present invention.
6 is a flow chart showing a method for recovering from a failure according to another embodiment of the present invention.

In the present invention, various modifications may be made and various embodiments may be provided, and specific embodiments will be illustrated in the drawings and described in detail.

However, this is not intended to limit the present invention to a specific embodiment, it is to be understood to include all changes, equivalents, and substitutes included in the spirit and scope of the present invention.

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

When a component is referred to as being "connected" or "connected" to another component, it is understood that it may be directly connected or connected to the other component, but other components may exist in the middle. Should be. On the other hand, when a component is referred to as being "directly connected" or "directly connected" to another component, it should be understood that there is no other component in the middle.

The terms used in the present application are only used to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In the present application, terms such as "comprise" or "have" are intended to designate the presence of features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, but one or more other features. It is to be understood that the presence or addition of elements or numbers, steps, actions, components, parts, or combinations thereof, does not preclude in advance.

Unless otherwise defined, 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 the present invention belongs. Terms as defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning in the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in the present application. Does not.

Hereinafter, the'controller' referred to in the present invention means a functional element (entity) that controls related components (eg, switches, routers, nodes, etc.) in order to control the flow of traffic. It is not limited to the form of implementation or location of implementation. For example, the controller may mean a controller entity defined by ONF, IETF, ETSI and/or ITU-T.

In addition,'equipment' or'node' referred to in the present invention refers to a functional element that substantially forwards, switches or routes traffic (or packets), and is defined in ONF, IETF, ETSI and/or ITU-T, etc. It may mean a switch, a router, a switch element, a router element, a forwarding element, and the like.

In addition, embodiments of the present invention described below are standard documents written in ONF, IETF, ETSI, and ITU-Ts performing standardization of SDN technology and/or IEEE, ITU- performing standardization on delivery networks. It can be supported by standard documents written by T, IETFs. That is, among the embodiments of the present invention, contents not specifically described in order to clearly reveal the technical idea of the present invention may be supported by standard documents prepared by the above standardization organizations. 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 more detail with reference to the accompanying drawings. In describing the present invention, in order to facilitate an overall understanding, the same reference numerals are used for the same elements in the drawings, and duplicate descriptions for the same elements are omitted.

Failure recovery, a key element of network survivability, includes protection and restoration methods.

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

In the restoration method, when a network failure occurs, resources to be used are determined in advance, but the restoration path is not allocated in advance. The failure recovery time of the restoration method usually takes hundreds of msec to several seconds, so the failure restoration time is much longer than that of the protection method. In addition, the restoration method has a characteristic that failure recovery is not guaranteed because even if a network failure occurs, if there are no available resources, the failure cannot be restored.

The protection method can perform failure recovery quickly and reliably by allocating resources to be used for failure recovery in advance, but resource utilization is inferior to the restoration method. On the other hand, since the restoration method does not allocate resources for failure restoration in advance, if a failure occurs, the restoration time is lengthened or restoration itself cannot be performed, but the utilization of resources is higher than that of the protection method.

The protection and restoration methods work together with OAM messages, control planes, and management planes to form a framework for network survivability.

In order to transmit packets end-to-end in a packet delivery network, a virtual logical tunnel is established. This tunnel is called Label Switched Path (LSP). In addition, in order to accommodate a large number of customers in the set LSP, a virtual line (PW: Pseudo Wire) is created to transmit a client signal through an AC (Attachment Circuit). Therefore, a plurality of PWs may be included in one LSP.

The LSP and PW are structures including several PWs in the LSP.

On the other hand, the quality level of failure recovery can be classified into dedicated protection, shared protection, and restoration.

Dedicated protection is a method in which resources are not used for other purposes, but are used exclusively for protection switching.

Shared protection is a method in which resources for recovering various services are shared. The sharing ratio of shared protection is divided into 1:n and m:n, and as a method of shared protection, an end-to-end shared protection method that shares the same end points, and a plurality of There is a shared mesh protection scheme in which the protection paths of are shared resources. In the shared mesh protection scheme, the endpoints do not necessarily have to be the same.

In addition, various protection methods such as LSP, PW, link, and segment are used according to the restoration target to be restored. For example, LSP protection is used for failure recovery in LSP units, and PW protection is used for failure recovery in PW units.

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

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

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), and through this, the failure is recovered. do. Here, the protection LSP may be allocated in advance in case a failure occurs, and the switching from the operation LSP to the protection LSP may be performed by the edge nodes PE1 101 and PE2 102.

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

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

In a general failure recovery method, a failure recovery policy corresponding to the LSP created at the time of LSP creation is determined, and the determined failure recovery policy is fixedly applied. For example, the first LSP applies a protection method, L1 is preset as a protection path, and the second LSP (L2, requires low recovery quality) applies a restoration method, and the recovery policy is determined. In this case, when a failure occurs in the first LSP, the failure recovery quality is good (within 50msec) because the failure is restored using the preset L1, but the resource use efficiency is not good because the resource is always occupied as much as the bandwidth of L1. On the other hand, when a failure occurs in the second LSP, the restoration method is applied to recover the failure, so the resource is not occupied in advance compared to the protection method, but a new path to restore the failure must be found and created at the time of restoration. Therefore, there is a problem in that the failure recovery time is delayed, and in the worst case (for example, when there is no available resource), there is a disadvantage in that failure recovery cannot be performed because a recovery path cannot be found.

The present invention uses a limited resource by efficiently and intelligently controlling the network by introducing a centralized controller in order to solve the inefficiency caused by the application of a fixed failure recovery policy of a general failure recovery method from the viewpoint of network failure recovery. It provides a failure recovery method that can improve the quality of failure recovery even in an environment that can improve the efficiency of resource use.

In other words, in the present invention, instead of applying the previously set recovery policy for each recovery unit, the centralized controller dynamically determines the recovery policy and the failure recovery method of all LSPs according to the network situation to recover the failure. Even when the same resources are used as before, it is possible to guarantee higher quality of failure recovery than the existing failure recovery method.

In addition, in the present invention, even when the restoration method is applied as the failure recovery method, the centralized controller calculates the restoration path in advance so that the failure can be recovered more quickly than the existing restoration method, and the restoration quality is improved. I can.

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

2 is a conceptual diagram for explaining a failure recovery method using a centralized controller according to an embodiment of the present invention, and conceptually illustrates the configuration of a packet delivery network in which the controller 200 is introduced.

Referring to FIG. 2, the failure recovery method according to an embodiment of the present invention may be performed in an environment in which a plurality of network devices (or network nodes) 201 and 202 constituting a network are connected to the controller 200. In FIG. 2, for convenience of explanation, two network devices 201 and 202 are illustrated as being connected to the controller 200, but the controller 200 is connected to a plurality of network devices other than the network devices shown in FIG. 2. It must 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 failure recovery unit 220, and the path setting unit 210 and the failure recovery unit 220 may interwork 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 a physical configuration. For example, the path setting unit 210 and the failure recovery unit 220 may be configured as separate hardware, or may be configured as a software module processed by one processor.

Upon receiving the LSP generation request, the controller 200 can generate a working LSP (working LSP) by centrally calculating a path and transmitting a path generation request message instructing the configuration of the calculated path to the corresponding network device. have. Here, the path calculation and transmission of the path generation request message may be performed by the path setting unit 210.

In addition, the controller 200 may set a recovery policy against a failure of the LSP according to a recovery policy provided by a network operator or a basically defined recovery policy when the LSP is created. For example, the controller 200 may control the network equipment 201 and 202 to generate a protection LSP (protection LSP) corresponding to the LSP1 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 that the LSP has failed. For example, when a failure occurs in the operating LSPn, the controller 200 may generate a restoration LSP (restoration LSP) to replace the failure path. The recovery policy of the LSP may be set by the failure recovery unit 220.

Meanwhile, the interworking between the controller 200 and the plurality of network devices 201 and 202 may be performed through a control data plane interface (CDPI) standardized by ONF's OTWG.

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

-Route creation request message: A message transmitted by the controller 200 to the network equipment 201 and 202, and is used to instruct route creation.

-Route creation notification message: A message transmitted by the network equipment 201 and 202 to the controller 200, and is used to indicate the completion of route creation.

-Failure occurrence notification message: A message transmitted by the network equipment 201 and 202 to the controller 200, and is used to notify the controller 200 of the occurrence of a failure.

-Failure recovery request message: A message transmitted by the controller 200 to the network equipment 201 and 202, and is used to instruct failure recovery.

-Failure recovery notification message: A message transmitted from the network equipment 201, 202 to the controller 200, and is used to indicate completion of the failure recovery.

The CDPI messages are described as examples of 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, as for the messages used in the failure recovery method according to the present invention, in addition to the above messages, various CDPI messages may be used as in the embodiments described below.

Meanwhile, the controller 200 manages path information for each LSP when the LSP is created, modified or deleted. Here, the controller 200 may manage path information for each LSP using a separate path database 230. For example, when the LSP is created, modified, or deleted, the controller 200 may refer to the path database 230 to perform a corresponding task, and store the execution result in the path database 230. This operation may be performed by the path setting unit 210.

In addition, when a failure occurs in the LSP and performs failure recovery, the controller 200 may manage recovery status information for each LSP. Here, the controller 200 may use a separate recovery database 240 to manage status and recovery status information for each LSP, and the recovery database 240 contains recovery policy for each LSP and recovery status information of a path where a failure occurs. Can be included. Such an operation may be performed by the failure recovery unit 220.

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

In FIG. 3, when a request for generation of LSP1 connecting network devices occurs in a packet delivery network environment in which a controller is connected to a plurality of network devices, the process of creating LSP1 and setting a policy for failure recovery of LSP1 is illustrated. I did it. At this time, it is assumed that the recovery level is to use the protection method. In FIG. 3, PE1 and PEn mean both edge nodes of LSP1, and transit nodes on the path of LSP1 are indicated by P1, P2, and the like.

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

In addition, the controller may receive a request for setting a recovery policy of LSP1 from an operator, an operating system, or an external system (S302). Here, the request for setting the recovery policy is not necessarily provided, and if a request for setting the recovery policy is not provided separately, the controller may set the recovery policy for LSP1 according to the default recovery policy according to characteristics such as SLA or QoS of LSP1. have. The request for setting a recovery policy may include information such as a quality level of failure recovery, a recovery mechanism, and whether or not a pre-path is calculated for fast restoration. The quality level information of failure recovery may include level setting information such as dedicated protection, shared protection, and restoration. The recovery mechanism information may include sharing ratio information such as 1:1, 1:n, m:n, and the like.

When receiving a request for setting a recovery policy for LSP1, the controller may store information such as recovery target LSP information (i.e., LSP1), a quality level of failure recovery, a recovery mechanism, and whether to calculate a pre-path in the recovery database (S303). .

The controller inquires resource information, calculates the path of LSP1 based on the inquired resource, and then transmits a path creation request message requesting the creation of LSP1 to each node on the path constituting the calculated LSP1 (S304). . Here, the above-described CDPI message may be used as the path creation request message, and identification information of the LSP to be generated (i.e., LSP1), bandwidth, and node information on the LSP1 path (eg, PE1, P1, P2, ..., PEn ), etc.

In addition, the controller calculates the protection path for LSP1, and transmits a recovery path creation request message to each node on the path constituting the calculated protection path to request the creation of a protection LSP (protection LSP) of the LSP1 (S305). Here, the recovery path creation request message may be a CDPI message, LSP identification information corresponding to the protection LSP (i.e., LSP1), the type of the recovery path (i.e., protection LSP), bandwidth, node information on the protection LSP path ( For example, it may include information such as PE1, P1', P2', ..., PEn). Since the protection LSP is a replacement path when LSP1 fails, the end nodes of the protection LSP (i.e., PE1, PEn) are the same as LSP1, but the transit node of the protection LSP (e.g., P1', P2', …) is LSP1. It may be different from the via node (for example, P1, P2, ...) of.

Meanwhile, nodes (e.g., PE1, P1, P2, ..., PEn) that have received the path creation request message for LSP1 in step S303 generate LSP1, and then indicate to the controller that the generation of LSP1 has been successful. The route creation notification message is transmitted (S306). Here, the path generation notification message may use a CDPI message, and may include identification information (ie, LSP1) of the generated LSP.

In addition, nodes (e.g., PE1, P1', P2', ..., PEn) that have received the recovery path creation request message for the protection LSP in step S307 generate the protection LSP and then generate the protection LSP to the controller. A recovery path creation notification message indicating that this was successful is transmitted (S307). Here, the recovery path creation notification message CDPI message may be used, and LSP identification information (ie, LSP1) corresponding to the generated protection LSP and protection LSP information may be included.

When the controller receives 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 LSP created in the path database (S308). At this time, the controller may store the generated LSP and protection LSP identification information, bandwidth, node information on each path, and the like in the path database.

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

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

In FIG. 4, in a packet delivery network environment in which a controller is connected to a plurality of network devices, LSP1 and LSP2 are set, and a failure recovery process is illustrated in the case of a failure (duplicate failure occurrence) in the order of LSP1 and LSP2. In FIG. 4, LSP1 and LSP2 are operated in a shared protection method that shares one protection LSP (protection LSP), and the recovery quality level (or recovery priority) of LSP1 is higher than that of LSP2. It is assumed to be high. In addition, in FIG. 4, PE1 and PEn mean both edge nodes of LSP1 and LSP2, and transit nodes on the paths of LSP1 and LSP2 are indicated by P1, P2, and the like.

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

Upon receiving the failure occurrence notification message for LSP1, the controller inquires the recovery policy and protection LSP status of LSP1 from the recovery database to determine the recovery level of LSP1 (S402). Here, it is assumed that the recovery level of LSP1 is shared protection as described above, and 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 level (S403). Here, the failure recovery request message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP1) and recovery path information (ie, protection LSP).

When PE1 and PEn receive a failure recovery request message from the controller, they perform failure recovery for LSP1. Here, PE1 and PEn may perform path switching to the protection LSP included in the failure recovery request message. Thereafter, PE1 and PEn transmit a failure recovery notification message indicating that the failure recovery has been successfully completed to the controller (S404). The failure recovery notification message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP1) and recovery path (ie, protection LSP) information.

When the controller receives the failure recovery notification message from PE1 and PEn, the controller changes the state information of the LSP1 and the protection LSP stored in the recovery database (S405). Here, the controller may change the state of LSP1 from Up to Down (ie, LSP1, Down), and change the state information of the protection LSP from Standby to Active (ie, Protection LSP, Active).

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

When the controller receives a failure notification message for LSP2, the controller checks the recovery policy of LSP2 and the status of the protection LSP (Protection LSP) from the recovery database, and then determines the recovery level of LSP2 according to the priority (S407). In FIG. 4, it is assumed that LSP1 and LSP2 share the protection LSP, and the recovery quality level (or recovery priority) of LSP1 is higher than that of LSP2, and the protection LSP has already been used for recovery of LSP1, so the controller has the recovery level of LSP2. You decide to use restoration.

On the other hand, if the controller is selected to perform pre-path calculation when it is necessary to apply the restoration with the restoration policy of LSP2, the time when the restoration of LSP2 is required (i.e., after LSP1 occupies the protection LSP due to a failure Only when there is a possibility that restoration application occurs), a restoration path for LSP2 is calculated according to a predetermined period and stored in the path database. For example, the controller may pre-calculate a restoration path for LSP2 after changing the state information of LSP1 and the protection LSP through the execution of step S405.

When the controller selects to perform the pre-path calculation when applying the restoration as the restoration policy, upon receiving the failure occurrence notification message of LSP2, the controller inquires the pre-calculated restoration path information from the route database (S408). At this time, the retrieved restoration path information may include LSP information to which the restoration path is to be applied (ie, LSP2) and restoration LSP path information.

Thereafter, the controller transmits a failure recovery request message to PE1 and PEn according to the inquired recovery path information (S409). Here, the failure recovery request message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP2) and path information of the protection LSP.

When PE1 and PEn receive a failover request message from the controller, they set the recovery path for LSP2 according to the protected LSP path information included in the received failover request message, and a failover notification indicating that the failover has been successfully completed. The message is transmitted to the controller (S410). The failure recovery notification message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP2) and protection LSP information.

When the controller receives the failure recovery notification message from PE1 and PEn, the controller changes path information for the recovery path stored in the path database (S411).

In addition, the controller changes the state information of LSP2 stored in the recovery database (S412). Here, the controller may change the state of LSP2 from Up to Down (ie, LSP2, Down), and change the state information of the restored LSP from Standby to Active (ie, Restoration LSP, Active).

The failure recovery method as shown in FIG. 4 can also be applied when 1:n, m:n sharing protection is applied as a failure recovery policy for two or more LSPs.

5 is a flow chart showing a failure recovery method according to another embodiment of the present invention.

In FIG. 5, LSP1 and LSP2 are operated in a shared protection scheme that shares one protection LSP (protection LSP), and the recovery quality level (or recovery priority) of LSP2 is higher than that of LSP1. In the set state, when a failure occurs in the order of LSP1 and LSP2, the process of dynamically performing optimal recovery is illustrated. In FIG. 5, PE1 and PEn mean both edge nodes of LSP1 and LSP2, and transit nodes on the paths of LSP1 and LSP2 are indicated by P1, P2, and the like.

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

Upon receiving the failure occurrence notification message for LSP1, the controller inquires the recovery policy of LSP1 and the status of the protection LSP from the recovery database to determine the recovery level of LSP1 (S502). Here, it is assumed that the recovery level of LSP1 is shared protection as described above, and 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 level (S503). Here, the failure recovery request message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP1) and protection LSP information.

When PE1 and PEn receive a failure recovery request message from the controller, they perform failure recovery for LSP1. Here, PE1 and PEn may perform path switching to the protection LSP included in the failure recovery request message. Thereafter, PE1 and PEn transmit a failure recovery notification message indicating that the failure recovery has been successfully completed to the controller (S504). The failure recovery notification message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP1) and protection LSP information.

When the controller receives the failure recovery notification message from PE1 and PEn, the controller changes the state information of the LSP1 and the protection LSP stored in the recovery database (S505). Here, the controller may change the state of LSP1 from Up to Down (ie, LSP1, Down), and change the state information of the protection LSP from Standby to Active (ie, Protection LSP, Active).

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

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

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

Meanwhile, in FIG. 5, it is assumed that LSP1 and LSP2 operate in a manner of sharing the protection LSP, so first, in order to allocate the protection LSP assigned to the failed LSP1 to LSP2, the assigned protection LSP of LSP1 must be changed to a restored LSP. .

To prepare for such a situation, when the controller is selected to perform pre-path calculation when it is necessary to apply the restoration with the restoration policy setting of LSP1, when the restoration of LSP1 is required (i.e., the protected LSP shared among LSPs). When LSP1 is occupied and there is a possibility that application of the restoration LSP to LSP1 may occur), a restoration path for 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 the execution of step S505, and then calculate the restoration path of the LSP1 in advance in case a failure occurs in the high priority LSP2.

When the controller receives the failure occurrence notification message of LSP2 having a higher priority than LSP1, the controller inquires about the restoration path information of LSP1 calculated in advance in the path database (S509). In this case, the retrieved restoration path information may include LSP information to which the restoration path is to be applied (ie, LSP1) and restoration LSP path information.

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

On the other hand, PE1 and PEn receiving the failure recovery request message from the controller in step S508 set the restoration path for LSP2 according to the protection LSP information included in the received failure recovery request message, indicating that the failure recovery has been successfully completed. A failure recovery notification message is transmitted to the controller (S511). The failure recovery notification message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP2) and protection LSP information.

In addition, PE1 and PEn, which received the failure recovery request message for LSP1 from the controller in step S510, set the restoration path for LSP1 according to the restoration LSP path information included in the received failure recovery request message, and the failure recovery is successful. A failure recovery notification message indicating completion is transmitted to the controller (S512). The failure recovery notification message may be a CDPI message, and may include recovery target LSP identification information (ie, LSP1) and restoration LSP information.

When the controller receives the failure recovery notification message from PE1 and PEn, the controller changes path information on the recovery path stored in the path database (S513).

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

Also, since the state information of LSP1 has changed, the controller changes the state information of LSP1 stored in the recovery database (S5145. Here, the controller changes the state of LSP1 from Up to Down (i.e., LSP1, Down), and the state information of the restored LSP) Can be changed from Standby to Active (ie, Restoration LSP, Active).

The failure recovery method as shown in FIG. 5 can also be applied when 1:n, m:n sharing protection is applied as a failure recovery policy for two or more LSPs.

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

6 is a flow chart showing a method for recovering from a failure according to another embodiment of the present invention.

In FIG. 6, LSP1 and LSP2 are operated in a shared protection method that shares one protection LSP (protection LSP), and as shown in FIG. 4, a redundant failure occurs in the order of LSP1 and LSP2, so that failure recovery is possible. After completion, when the failure of LSP1 and LSP2 is resolved, the process of returning the LSPs to their original state is illustrated. Hereinafter, it is assumed that a revertive mode that returns to an initial state when a failure of the LSP is resolved by the failure recovery policy is set. In FIG. 6, PE1 and PEn refer to both edge nodes of LSP1 and LSP2, and transit nodes on the paths of LSP1 and LSP2 are indicated by P1, P2, and the like.

Referring to FIG. 6, when a failure is first resolved in LSP1, PE1 and PEn, both edge nodes of LSP1, transmit a failure cancellation message indicating that the failure has been resolved to the controller (S601). Here, the failure cancellation message may be composed of a CDPI message, and may include identification information (ie, LSP1) of the LSP from which the failure has been resolved.

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

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

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

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

Thereafter, when the failure is resolved in LSP2, PE1 and PEn transmit a failure cancellation message indicating that the failure of LSP2 has been resolved to the controller (S606). Here, the failure cancellation message may be composed of a CDPI message, and may include identification information (ie, LSP2) of the LSP from which the failure has been resolved.

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 (ie, LSP2) included in the failure resolution message (S607). Here, the controller can know that a failure has occurred and that the failure recovery policy has been set to a retrieve mode from the status information of the LSP2.

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

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

Upon receiving the failure recovery completion message, the controller deletes information on the recovery path from the path database (S610).

In addition, the controller changes the status information on the LSP2 in the recovery database and deletes the information on the restored LSP (S611). For example, the controller can change the status information of LSP2 to active (LSP2, Active) and delete the status information of the protection LSP (Delete Restoration LSP).

The failure recovery method as shown in FIG. 6 can also be applied when 1:n, m:n sharing protection is applied as a failure recovery policy for two or more LSPs.

Although described with reference to the above embodiments, those skilled in the art will understand that various modifications and changes can be made to the present invention without departing from the spirit and scope of the present invention described in the following claims. I will be able to.

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: failure recovery unit
230: path database 240: recovery database

Claims (20)

A failure recovery method performed by a centralized controller connected to a plurality of network devices,
Receiving a request for setting failure recovery of a first path;
Setting a failure recovery policy of the first path; And
And transmitting a recovery path creation request message instructing to create a recovery path of the first path to network devices configuring a recovery path based on a set failure recovery policy of the first path,
The step of setting the failure recovery policy of the first path,
And storing at least one of the identification information of the first path, a quality level of failure recovery, a recovery mechanism, and pre-path calculation information in a database. In claim 1,
The network failure recovery method,
Receiving a request for generating the first path;
Querying resource information for generating the first route, and calculating the first route based on the retrieved resource information; And
And transmitting a path generation request message instructing the generation of the first path to network devices configuring the calculated first path. delete In claim 1,
The recovery path creation request message,
And at least one of information on the identification information of the first path corresponding to the recovery path, the type of the recovery path, the bandwidth of the recovery path, and information on network devices constituting the recovery path. In claim 1,
The network failure recovery method,
Receiving a recovery path creation notification message indicating completion of the recovery path generation from at least one network equipment that has transmitted the path creation request message;
Storing information on the recovery path; And
And storing the state of the first path and the recovery path. In claim 5,
Storing the information of the recovery path,
And storing 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 information on network equipment constituting the recovery path. Failure recovery method. In claim 5,
Storing the state of the first path and the recovery path,
And storing information on whether to activate each of the first path and the recovery path. A failure recovery method performed by a centralized controller connected to a plurality of network devices,
Receiving a failure occurrence notification message for notifying occurrence of a failure of the first path from the network device;
Determining a failure recovery level of the first path based on a preset failure recovery policy;
Transmitting a failure restoration request message instructing failure restoration of the first path to the network device based on the determined failure restoration level;
When a protection path shared by a plurality of paths is in an active state, calculating a restoration path for failure recovery and storing it in a database;
Receiving a failure occurrence notification message for notifying occurrence of a failure of a second path from the network device;
Determining a failure recovery level of the second path based on a preset recovery priority; And
And transmitting a failure restoration request message instructing failure restoration of the second path to the network device based on the determined failure restoration class. In claim 8,
Wherein the failure occurrence notification message includes at least one of identification information and failure type information of the first path in which a failure has occurred. In claim 8,
The step of determining the failure recovery level of the first path,
Querying a failure recovery priority of the first path and a state of a protection path from a database; And
And determining a failure recovery level of the first path based on the failure recovery priority and a state of a protection path. In claim 8,
The failure recovery request message,
A network failure recovery method comprising at least one of identification information of a failure path to be restored and information on a recovery path. In claim 11,
The network failure recovery method,
Receiving a failure restoration notification message indicating that failure restoration of the first path is completed from at least one network device that has transmitted the failure restoration request message; And
And changing state information of each of the first path and the recovery path. delete In claim 8,
The step of determining the failure recovery level of the second path,
Inquiring a state 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, the protection path is being used for failure recovery, and the recovery priority of the second path is lower than the first path, the second path is Determining a failure recovery level as restoration; And
And acquiring a restoration path of the second path previously stored in the database. In claim 14,
The failure recovery request message indicating failure recovery of the second path includes information on the recovery path of the second path. In claim 8,
Determining the recovery level of the second path,
Querying 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, the protection path is being used for failure recovery of the first path, and the recovery priority of the first path is lower than that of the second path, Determining a recovery level of the second path as protection and a recovery level of the first path as restoration; And
And obtaining a restoration path from the database. In claim 16,
The network failure recovery method,
Transmitting a failure recovery request message including protection path information of the second path to the network device;
Transmitting a failure recovery request message including information on the restoration path of the first path to the network device;
Receiving a failure recovery notification message of the first path and a failure recovery notification message of the second path from the network device; And
And updating the recovery status information of the first path and the second path. A failure recovery method performed by a centralized controller connected to a plurality of network devices,
Receiving a failure resolution message indicating that the failure of the first path has been resolved from the network equipment;
Obtaining a failure recovery policy of the first path;
If the failure recovery policy of the first path is set to a recovery mode, transmitting a failure recovery request message indicating failure recovery to the network device;
Receiving a failure recovery completion message indicating that failure recovery has been completed from the network equipment; And
And changing state information of the first path and the recovery path of the first path,
The step of changing the state information,
If the state of the first path is changed from standby to active, and if the recovery path of the first path corresponds to a restoration path, the restoration path is deleted from the database, and When the recovery path corresponds to a protection path, the state of the protection path is changed from active to standby. delete delete

Images