[go: up one dir, main page]

WO2015088268A1 - Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법 - Google Patents

Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법 Download PDF

Info

Publication number
WO2015088268A1
WO2015088268A1 PCT/KR2014/012220 KR2014012220W WO2015088268A1 WO 2015088268 A1 WO2015088268 A1 WO 2015088268A1 KR 2014012220 W KR2014012220 W KR 2014012220W WO 2015088268 A1 WO2015088268 A1 WO 2015088268A1
Authority
WO
WIPO (PCT)
Prior art keywords
network device
failure
controller
router
information
Prior art date
Application number
PCT/KR2014/012220
Other languages
English (en)
French (fr)
Inventor
곽은주
이광국
이영욱
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020140177257A external-priority patent/KR101618989B1/ko
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to US15/103,524 priority Critical patent/US20160315871A1/en
Publication of WO2015088268A1 publication Critical patent/WO2015088268A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • the present invention relates to software defined networking techniques, and more particularly, to a method for handling a failure occurring in a network device.
  • the Internet Engineering Task Force can centrally collect router information using an external controller or apply a routing system control policy so that the SDN concept can be applied without modifying the functions of the existing router as much as possible. It defines standard interfaces for routers and external controllers.
  • the IETF is an Interface to Routing System (I2RS) that supports centralized control using external controllers for routing systems, including legacy legacy IP routing systems that do not have separate forwarding and control planes. Propose technology.
  • I2RS Interface to Routing System
  • the IETF currently defines a framework and an interface for communicating between a controller and an existing or new router device by standardizing a routing system interface technology for a routing system.
  • An object of the present invention for solving the above problems is to provide a method of handling when a network device such as a router in the SDN environment has a failure.
  • a fault handling method for a network device the fault handling method performed in a network device connected to at least one controller, the method comprising: predicting a fault on the network device; If a failure to the network device is predicted, informing the at least one controller that the network device will be down.
  • the network device may be notified to the at least one controller including the time information when the network device is down.
  • the time information when the network device is down may use a time stamp generated by the network device.
  • the notifying that the network device is to be down includes: searching for a controller associated with the network device from a storage storing a list of at least one controller; And sending a message informing the discovered controller that the network device is going down.
  • a message broker may relay a message exchange between at least one controller and a network device.
  • a fault handling method for a network device the fault handling method performed in a network device connected to at least one controller, the method comprising: restarting the network device after failing over; And transmitting information about the restart to the at least one controller to inform the fact of the failure.
  • the transmitting of the information about the restart to the at least one controller may inform the at least one controller by using the information about the restart that an unexpected failure has occurred in the network device.
  • the information on the restart count of the network device may be included in the restart information to inform the at least one controller of the failure of the network device.
  • the transmitting of the information about the restart to the at least one controller may include: searching for a controller associated with a network device from a storage configured to store a list of at least one controller; And transmitting the information about the restart to the discovered controller.
  • a message broker may relay a message exchange between at least one controller and a network device.
  • a fault handling method for a network device includes: Receiving the distinguished information according to; And treating the failure according to the information distinguished according to the failure type.
  • the information distinguished according to the failure type includes notification information that the network device will be down if a failure for the network device is predicted, and if the failure for the network device is not predicted, It may include notification information for notifying restart.
  • the network device may receive notification information including time information when the network device is to be down.
  • the time information when the network device is down may use a time stamp generated by the network device.
  • the number of restarts of the network device may be received.
  • the message to be sent to the failed network device may be recorded in a log and the transmission may be suspended.
  • a message broker may relay a message exchange between at least one controller and a network device.
  • a method for dealing with a failure of a network device defines a handling mechanism for graceful failure and crash for each failure type of a router, so that all relevant controllers have a failure of the router. You can quickly grasp the information.
  • the controller logs all the messages that the controller wants to send to the router, and then pauses the transmission.
  • the network load can be reduced by reducing the retransmission of messages.
  • FIG. 1 is a block diagram illustrating the structure of a routing system according to an embodiment of the present invention.
  • FIG. 2 is a flowchart illustrating a failure processing method for a network device according to an embodiment of the present invention.
  • FIG. 3 is a conceptual diagram illustrating the publication and subscription of an event using a message broker according to an embodiment of the present invention.
  • FIG. 4 is a flowchart illustrating the publication and subscription of an event using a message broker according to an embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating a method of handling a predicted failure for a network device using a message broker according to an embodiment of the present invention.
  • FIG. 6 is a flowchart illustrating a method for a message broker to handle a predicted failure of a network device according to an embodiment of the present invention.
  • FIG. 7 is a flowchart illustrating a method of handling a predicted failure for a network device in the absence of a message broker according to an embodiment of the present invention.
  • FIG. 8 is a flowchart illustrating a method of handling an unexpected failure for a network device using a message broker according to an embodiment of the present invention.
  • FIG. 9 is a flow chart illustrating a method for a message broker to handle an unexpected failure for a network device according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a method of handling an unexpected failure for a network device in the absence of a message broker according to an embodiment of the present invention.
  • first, second, A, and B 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.
  • the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.
  • a 'controller' or a 'client' referred to in the present invention refers to a function element for controlling a related component (for example, a switch or a router) to control the flow of traffic. Meaning, it is not limited to the physical implementation form, implementation location and the like.
  • a controller may mean a controller function entity defined by ONF, IETF, ETSI, and / or ITU-T.
  • the term 'network device' or 'agent' referred to in the present invention refers to a functional element that substantially forwards, switches, or routes traffic (or packets), and includes ONF, IETF, ETSI, and / or ITU-. It may mean a switch, a router, a switch element, a router element, a forwarding element, and the like defined in T.
  • embodiments of the present invention described below are IEEE, ITU- which performs standardization on standard documents and / or delivery networks written in ONF, IETF, ETSI, ITU-T, which are performing standardization of SDN technology. T, may be supported by standard documents written in IETFs. That is, the contents of the embodiments of the present invention that are not specifically described in order to clearly reveal the technical spirit of the present invention may be supported by the standard documents prepared by the standardization organizations. In addition, all terms used in the present invention can be described by the above standard documents.
  • FIG. 1 is a block diagram illustrating the structure of a routing system according to an embodiment of the present invention.
  • a plurality of routers 200 to be controlled by the controller 100 may be configured, and a plurality of controllers 100 may also be configured to increase load distribution and stability.
  • the M controller 100 represented by the M controller in the first controller located outside to control the N routers 200 represented by the N-th router in the first router The case where it is shown is shown.
  • Each controller 100 may operate in conjunction with the network application 300.
  • each controller 100 may operate in conjunction with one or more applications 300.
  • each controller 100 may provide information required for the application 300 or perform a request of the application 300.
  • FIG. 1 illustrates normalization between an agent module 211 existing on a control plane in a router 200 and a client module 101 existing on a controller 100.
  • I2RS interface to routing system
  • the client module 101 may receive the routing policy or the control command from the application 300 and convert the received policy or the control command into a message in a form that the agent module 211 can parse. .
  • the Agent module 211 parses the transmitted policy or control information to connect the topology database 212, the policy database 215, and the Routing Information Base (RIB) module connected to the router 200. 214, a routing / signaling protocol module 213, an OAM event module 216, and the like, may interact with each other.
  • RDB Routing Information Base
  • the forwarding information base module 217 may exist on a data plane of the router 200. Accordingly, the information from the agent module 211 may be delivered to the forwarding information base module 217 of the data plane via the routing information base module 214.
  • a monitoring function for transmitting various event information or statistical information of the routers 200 preset from the operator to the client module 101 through the agent module 211 may be performed.
  • Agent module 211 which is a module in the router 200 that communicates with the controller 100 controlling the router 200 through a standard interface, is very important in terms of stability and reliability of the routing system.
  • router failure or agent failure
  • I2RS Interface To the Routing System
  • a message transmitted through an interface between the controller 100 and the routers 200 may include the number of the controllers 100 and the routers ( As the number of 200 increases, the number of relations to be managed by each controller 100 and the router 200 increases.
  • N routers 200 and M controllers 100 form a relationship
  • the number of relations to be managed directly becomes N ⁇ M.
  • the router 200 when a new router 200 or a controller 100 is added, the router 200 newly added to all the controllers 100 and the router 200 affected by the router 200 or the controller 100. There are also scalability issues, such as the need to perform additional tasks.
  • the present invention proposes a method for handling a router failure (or agent failure), and issues / issues an I2RS interface message such as a router failure (or agent failure).
  • a router failure or agent failure
  • an I2RS interface message such as a router failure (or agent failure).
  • FIG. 2 is a flowchart illustrating a failure processing method for a network device according to an embodiment of the present invention.
  • the router 200 may classify a failure according to whether the failure may be predicted (S210). For example, the router 200 may classify a case in which a predictable shutdown or failure occurs as a graceful failure, and classify a case in which the router 200 suddenly fails as a crash. .
  • the router 200 When the router 200 detects the occurrence of a graceful failure, the router 200 inquires or searches for information on all the controllers 100 connected thereto (S211), and the controllers 100 ) May be notified that the router will be down (S213). At this time, the controllers 100 may log a message to be sent to the router 200 to be down and log the transmission.
  • An unexpected crash may occur in the router 200 (S230).
  • the controllers 100 may not know the failure of the corresponding router 200. Accordingly, the controller 100 may transmit a message for checking the health, such as a heartbeat, to the controller 100 so that the router 200 may quickly recognize the router 200 in which the crash occurred. (S220). However, the transmission of the heartbeat message by the router 200 may be performed optionally.
  • the controller 100 may not receive a heartbeat from the router 200 or may not detect a crash occurring in the router 200 at a predetermined period (S231). In this case, the controller 100 may request a connection for transmitting a message to the router 200 (S240), and since the router 200 is in a crashed state, the controller 100 may fail to connect. An error response (Reply) such as Fail) can be received (S241).
  • Reply error response
  • Fail Fail
  • the controller 100 may detect a crash occurring in the router 200 through an error response such as not receiving a heartbeat message or a connection failure (S243).
  • the controller 100 may record a message to be sent to the router 200 which has become a crash state in a log and suspend transmission (S250). In addition, the controller 100 may inquire of the list of other controllers 100 related to the corresponding router to notify the router failure.
  • the router 200 may solve the crash and restart (S260).
  • the router 200 may notify all related controllers 100 that the reboot is performed (S261).
  • the session ID, a boot count, a boot time, and the like may be included and notified.
  • the boot count may mean the number of times the router 200 has been booted.
  • the controller 100 may recognize that the router has been rebooted due to the failure of the 200.
  • the controller may retransmit or delete the unsent message due to the failure of the router 100 according to the policy after the router 200 restarts (Agent Reboot) (S263).
  • Agent Reboot For example, depending on the message type, information on QoS, statistics, and events may be retransmitted, and change information on topology and RIB may be deleted.
  • all messages older than 1 hour may be deleted, and messages not transmitted within 1 hour may be retransmitted to process unsent messages for each policy.
  • FIG. 3 is a conceptual diagram illustrating the publication and subscription of an event using a message broker according to an embodiment of the present invention.
  • the publish is performed. And the method of subscription can be used.
  • the message broker 400 may be utilized to reduce the mutual dependency between the controller 100 and the router 200 and to reduce the complexity and burden of managing the relationship between the plurality of controllers 100 and the router 200. have.
  • the message broker 400 may relay message exchanges between the plurality of controllers 100 and the plurality of routers 200.
  • the message broker 400 may relay a message between a plurality of controllers 100 and a plurality of routers 200 with reference to a publish / subscribe relation DB 500, and relay the message.
  • Log information on the message exchange by the message log (Message Log) can be stored in the DB (600).
  • FIG. 4 is a flowchart illustrating the publication and subscription of an event using a message broker according to an embodiment of the present invention.
  • a method for issuing and subscribing to an event using a message broker includes a subscription / publication registration step (S410), authentication / authorization (Authenticate / Authorize).
  • a step S420, an event publication step S430, and an event subscription step S440 may be configured.
  • FIG. 4 is an embodiment of each step message and parameter in the publish / subscribe message transmission step in which the message broker (MB) 400 is present.
  • a subscription / publication registration step S410 may be performed using a message for a subscription registration request and a publication registration request.
  • the controller 100 may transmit a message for subscription registration request to the message broker, and the router 200 may transmit a message for publication registration request to the message broker.
  • the message broker 400 may receive the message for the subscription registration request and the publication registration request, so that the controller 100 may request the subscription and the router 200 may request the subscription.
  • the message used in the subscription / publication registration step S410 may include information included in Table 1 below.
  • the publisher and subscriber can be distinguished using the information in Table 1.
  • the information on the request status it is possible to perform registration, pause, suspension cancellation, cancellation of registration, and the like.
  • authentication and authorization may be performed between the message broker 400, the controller 100, and the router 200. That is, the message broker 400, the controller 100, and the router 200 may authenticate each other, and request and grant authority according to each role.
  • the message used in the authentication / authorization step (S420) may include information included in Table 2 below.
  • the message broker 400 may receive an event issued from the controller 100 and the router 200.
  • the message broker 400 may provide an event issued by the controller 100 and the router 200 to the controller 100 and the router 200.
  • the message used in the event publication step S430 and the event subscription step S440 may include information included in Table 3 below.
  • FIG. 5 is a flowchart illustrating a method of handling a predicted failure of a network device using a message broker according to an embodiment of the present invention
  • FIG. 6 is a message broker according to an embodiment of the present invention.
  • FIG. 5 illustrates a procedure for handling a graceful failure in a structure in which a message broker 400 is present.
  • a method of handling a predicted failure of a network device using a message broker 400 may include a subscription / publication registration step S510 and authentication. Authenticate / Authorize step (S520), router failure publication (Router Failure Publication) step (S430) and router failure subscription (Router Failure Subscription) step (S540).
  • each step according to FIG. 5 may be understood to correspond to each step according to FIG. 4.
  • the controller 100 may register a router failure subscription to the message broker 400, and the router 200 may request a router failure issuance registration request to the message broker 400 (S510). ).
  • the message broker 400 and the controller 100 and the router 200 registered for subscription and publication may authenticate each other, and request and grant authority according to each role (S520).
  • the router 200 may issue a router failure event to the message broker 400 according to occurrence of a router failure (S530).
  • the message broker 400 may transmit a router failure event to the controller 100 requesting a subscription, and change the state of the router 100 to a failure state (S540).
  • FIG. 6 describes the steps S530 and S540 of FIG. 5 in more detail.
  • the router 200 may publish a router failure event, and the message broker 400 may notify the controller 100 of the failure of the router. In addition, the message broker 400 may change the state of the corresponding router 200 in which the failure occurs to fail.
  • the message broker 400 may receive a publication for a router failure and record it in a message log (S610).
  • the message broker 400 may inquire the publish / subscribe relationship information to inquire the controller 100 which is the subscriber connected to the corresponding router 200 (S620).
  • the message broker 400 may be placed in a queue according to a transmission priority for a message to notify the controller 100 of the router failure (S630 and S640). At this time, by processing a queue by priority, it is possible to transmit an urgent and important message among several messages without delay or loss.
  • the message broker 400 may change the state of the corresponding router 200 in which the router failure occurs to a failure state (S650).
  • the message broker 400 may centrally manage whether the connection relationship between the controller 100 and the router 200 is connected or disconnected (by a router failure).
  • the message broker 400 Since the message broker 400 finally takes the role of subscription and publication, the burden of transmitting a message between the controller 100 and the router 200 may be reduced.
  • the message broker 400 stores the message as a log to enable asynchronous transmission of the message.
  • the message broker 400 may store a message in a log in case of a router failure, and collectively transmit an unsent message after the failure is recovered.
  • the message broker 400 may guarantee the transmission of the message for each priority in the entire network. Therefore, it is possible to improve the stability and reliability of the network by delivering the event (Event) occurred in the network quickly.
  • FIG. 7 is a flowchart illustrating a method of handling a predicted failure for a network device in the absence of a message broker according to an embodiment of the present invention.
  • information exchange between the controller 100 and the router 200 may be performed directly without the message broker 400 relaying message transfer between the controller 100 and the router 200. You can deal with failures.
  • controller 100 and the router 200 may directly authenticate each other and manage connection information between each other.
  • the method for handling a predicted failure for a network device in the absence of a message broker 400 may include a subscription / publication registration step (S710), authentication / Authorization (Authenticate / Authorize) step (S720), router failure publication (Router Failure Publication) step (S730) and router failure subscription (Router Failure Subscription) step (S740).
  • S710 subscription / publication registration step
  • S720 authentication / Authorization (Authenticate / Authorize) step
  • S730 router failure publication
  • router failure subscription Routerouter Failure Subscription
  • each step according to FIG. 7 may be understood to correspond to each step according to FIG. 4.
  • the controller 100 may make a router failure subscription registration request to the router 200 (S710).
  • the controller 100 and the router 200 may authenticate each other, and may request and grant a right according to each role (S720).
  • the router 200 may issue a router failure event to the controller 100 according to occurrence of a router failure (S730).
  • the controller 100 may change the state of the corresponding router 200 into a failure state (S740).
  • the network device may predict a failure of the network device, and when a failure of the network device is predicted, the network device may transmit a message indicating that the network device is to be down.
  • the controller 100 may be informed that the network device is to be down, including time information when the network device is to be down.
  • the time information when the network device is down may use a time stamp generated by the network device.
  • the network device may search for the controller 100 associated with the network device from a storage that stores a list of the controller 100, and may transmit a message indicating that the network device is to be down to the discovered controller 100. have.
  • FIG. 8 is a flowchart illustrating a method of handling an unexpected failure for a network device using a message broker according to an embodiment of the present invention
  • FIG. 9 is a message broker according to an embodiment of the present invention. Is a flowchart for explaining a method for dealing with an unforeseen obstacle.
  • a method of handling a predicted failure for a network device using the message broker 400 may include a subscription / publication registration step (S810), authentication. Authenticate / Authorize step (S820), router failure publication step (S830) and router failure subscription step (Router Failure Subscription) step (S840).
  • S810 subscription / publication registration step
  • S820 authentication.
  • S830 router failure publication step
  • S840 router failure subscription step
  • each step according to FIG. 8 may be understood to correspond to each step according to FIG. 4.
  • the controller 100 may request a router restart subscription registration request to the message broker 400, and the router 200 may request a router restart issue registration request to the message broker 400 ( S810).
  • the message broker 400 and the controller 100 and the router 200 that register the subscription and the publication may authenticate each other and may request and grant authority according to their respective roles (S820).
  • the router 200 may issue a router reboot event to the message broker 400 according to the router reboot (S830).
  • the message broker 400 may transmit a router restart event to the controller 100 requesting a subscription, and change the state of the corresponding router 200 to a failure state (S840).
  • FIG. 9 describes steps S830 and S840 of FIG. 8 in more detail.
  • the router 200 may publish a router restart event, and the message broker 400 may notify the control 100 of the router restart.
  • the message broker 400 may change the state of the corresponding router 200 in which the failure occurs to fail.
  • the message broker 400 may receive a publication for restarting the router and record it in a message log (S910).
  • the message broker 400 may query a controller that is a subscriber connected to the corresponding router by inquiring publish / subscribe relationship information (S920).
  • the message broker 400 may be placed in a queue according to a transmission priority for a message to notify the controller 100 of the router failure (S930 and S940). At this time, by processing a queue by priority, it is possible to transmit urgent and important messages without delay or loss even among multiple messages.
  • the message broker 400 transmits a message including information such as a session ID, a boot count, a boot time, and the like to the controller 100 to provide information about a router failure or restart. Even if the controller 100 does not receive, the controller 100 may inform the controller 100 of the time and the number of times that the controller 100 is restarted due to a router failure.
  • the message broker 400 may change the restarted router state into a fail state (S950).
  • FIG. 10 is a flowchart illustrating a method of handling an unexpected failure for a network device in the absence of a message broker according to an embodiment of the present invention.
  • the information exchange between the controller 100 and the router 200 is directly performed without the message broker 400 relaying message transfer between the controller 100 and the router 200. Through this, it is possible to handle restart due to router failure.
  • controller 100 and the router 200 may directly authenticate each other and manage connection information between each other.
  • the method for handling an unexpected failure for a network device in the absence of a message broker 400 may include a subscription / publication registration step (S1010), authentication. / Authenticate / Authorize step (S1020), router failure publication (Router Failure Publication) step (S1030) and router failure subscription (Router Failure Subscription) step (S1040).
  • S1010 subscription / publication registration step
  • S1020 authentication.
  • S1030 Authenticate / Authorize step
  • router failure publication Router Failure Publication
  • router failure subscription Router Failure Subscription
  • the controller 100 may request a router restart subscription registration request to the router 200 (S1010).
  • the controller 100 and the router 200 may authenticate each other, and may request and grant a right according to each role (S1020).
  • the router 200 may issue a router restart event to the controller 100 according to the router reboot (S1030).
  • the controller 100 may change the state of the router 200 to a failure state (S1040).
  • the network device can be restarted by recovering from a failure. If the restart is based on a failure of the network device, information about the restart of the network device may be transmitted to the controller 100. For example, the network device may inform the controller 100 by using the information about the restart of the network device that the failure of the network device is unexpected. In addition, the network device may notify the controller of the failure of the network device based on the number of restarts of the network device according to the information about the restart of the network device.
  • the network device may search for a controller 100 related to the network device from a storage that stores a list of the controller 100, and may transmit information about restarting the network device to the discovered controller 100.
  • the controller 100 may receive failure information on the network device from the network device, and determine the type of failure for the network device by using the failure information on the network device to handle the failure for the network device.
  • the failure information for the network device includes notification information that the network device will be down if a failure for the network device is predicted, and restart of the network device if the failure for the network device is not predicted. ) May include notification information.
  • the controller 100 may identify the failure of the network device by using the notification information that the network device including time information when the network device is down will be down.
  • the time information when the network device is down may use a time stamp generated by the network device.
  • the controller 100 may determine the failure of the network device by calculating the restart count of the network device using the failure information of the network device.
  • the controller 100 may record a message to be sent to the failed network device in a log and suspend transmission.
  • the processing mechanism for the graceful failure (Graceful Failure) and crash (Crash) for each type of failure of the router all the associated controllers can quickly determine the failure information of the router.
  • the controller logs all the messages that the controller wants to send to the router, and then pauses the transmission.
  • the network load can be reduced by reducing the retransmission of messages.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

네트워크 장치에 발생하는 장애를 처리하기 위한 방법이 개시된다. 네트워크 장치에 대한 장애 처리 방법은, 적어도 하나의 컨트롤러와 연결된 네트워크 장치에서 수행되는 장애 처리 방법에 있어서, 네트워크 장치에 대한 장애를 예측하는 단계와; 네트워크 장치에 대한 장애가 예측된 경우, 적어도 하나의 컨트롤러에 네트워크 장치가 다운(down)될 것임을 통보하는 단계를 포함한다. 따라서, 라우터의 장애 유형 별로 처리 메커니즘을 정의함으로써, 관련된 모든 컨트롤러가 라우터의 장애 정보를 신속히 파악할 수 있다.

Description

ＳＤＮ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법
본 발명은 소프트웨어 정의 네트워킹 기술에 관한 것으로, 더욱 상세하게는 네트워크 장치에 발생하는 장애를 처리하기 위한 방법에 관한 것이다.
통신 네트워크의 유연한 제어와 비용절감을 위해 통신 시스템의 전달 평면(forwarding plane)과 제어 평면(control plane)을 독립적으로 분리하여, 소프트웨어 프로그래밍을 하듯 네트워크를 중앙에서 소프트웨어적으로 정의하고 제어할 수 있는 소프트웨어 정의 네트워킹(SDN, Software Defined Networking) 기술이 등장하였다.
이러한 흐름에 따라 IETF(Internet Engineering Task Force)에서는 기존 라우터의 기능을 최대한 수정없이 SDN 개념을 적용할 수 있도록 외부의 컨트롤러를 이용하여 중앙집중식으로 라우터 정보를 수집하거나, 라우팅 시스템 제어 정책을 적용할 수 있도록 하는 라우터와 외부 컨트롤러의 표준 인터페이스를 정의하고 있다.
상세하게는, IETF는 포워딩 평면과 제어 평면이 분리되지 않은 기존 레거시(leagcy) IP 라우팅 시스템을 포함한 라우팅 시스템에 대해서도 외부 컨트롤러를 이용하여 중앙 집중 제어를 지원하는 라우팅 시스템 인터페이스(I2RS: Interface to Routing System) 기술을 제안하고 있다.
즉, 현재 IETF는 라우팅 시스템을 위한 라우팅 시스템 인터페이스 기술에 대한 표준화를 진행함으로써, 컨트롤러와 기존 또는 신규 라우터 장비 간 커뮤니케이션을 수행할 수 있는 프레임워크 및 인터페이스 등을 정의하고 있다.
그러나, SDN 환경에서 라우터와 같은 네트워크 장치에 장애가 발생하였을 경우의 처리 방법에 대한 논의는 미흡한 실정이다.
상기와 같은 문제점을 해결하기 위한 본 발명의 목적은, SDN 환경에서 라우터와 같은 네트워크 장치에 장애가 발생하였을 경우의 처리 방법을 제공하는데 있다.
상기 목적을 달성하기 위한 본 발명의 일 측면에 따른 네트워크 장치에 대한 장애 처리 방법은, 적어도 하나의 컨트롤러와 연결된 네트워크 장치에서 수행되는 장애 처리 방법에 있어서, 네트워크 장치에 대한 장애를 예측하는 단계와; 네트워크 장치에 대한 장애가 예측된 경우, 적어도 하나의 컨트롤러에 네트워크 장치가 다운(down)될 것임을 통보하는 단계를 포함한다.
여기에서, 상기 네트워크 장치에 대한 장애가 예측된 경우, 네트워크 장치가 다운될 시간 정보를 포함하여 적어도 하나의 컨트롤러에 네트워크 장치가 다운될 것임을 통보할 수 있다.
여기에서, 상기 네트워크 장치가 다운될 시간 정보는, 네트워크 장치가 생성한 타임 스탬프(time stamp)를 이용할 수 있다.
여기에서, 상기 네트워크 장치가 다운(down)될 것임을 통보하는 단계는, 적어도 하나의 컨트롤러에 대한 리스트를 저장하는 저장부로부터 네트워크 장치와 관련된 컨트롤러를 탐색하는 단계와; 탐색된 컨트롤러에 네트워크 장치가 다운될 것을 알리는 메시지를 전송하는 단계를 포함할 수 있다.
여기에서, 메시지 브로커(message broker)가 적어도 하나의 컨트롤러와 네트워크 장치 상호 간의 메시지 교환을 중계할 수 있다.
상기 목적을 달성하기 위한 본 발명의 다른 측면에 따른 네트워크 장치에 대한 장애 처리 방법은, 적어도 하나의 컨트롤러와 연결된 네트워크 장치에서 수행되는 장애 처리 방법에 있어서, 네트워크 장치가 장애 극복 후 재시작되는 단계와; 장애 발생 사실을 알리기 위해 재시작에 대한 정보를 적어도 하나의 컨트롤러에 전송하는 단계를 포함한다.
여기에서, 상기 재시작에 대한 정보를 상기 적어도 하나의 컨트롤러에 전송하는 단계는, 예측되지 않은 장애가 네트워크 장치에 발생하였음을 재시작에 대한 정보를 이용하여 적어도 하나의 컨트롤러에 알릴 수 있다.
여기에서, 상기 재시작에 대한 정보에 네트워크 장치의 재시작 횟수에 대한 정보를 포함시켜 적어도 하나의 컨트롤러에 네트워크 장치에 대한 장애를 알릴 수 있다.
여기에서, 상기 재시작에 대한 정보를 상기 적어도 하나의 컨트롤러에 전송하는 단계는, 적어도 하나의 컨트롤러에 대한 리스트를 저장하는 저장부로부터 네트워크 장치와 관련된 컨트롤러를 탐색하는 단계와; 탐색된 컨트롤러에 재시작에 대한 정보를 전송하는 단계를 포함할 수 있다.
여기에서, 메시지 브로커(message broker)가 적어도 하나의 컨트롤러와 네트워크 장치 상호 간의 메시지 교환을 중계할 수 있다.
상기 목적을 달성하기 위한 본 발명의 또 다른 측면에 따른 네트워크 장치에 대한 장애 처리 방법은, 적어도 하나의 네트워크 장치에 연결된 컨트롤러에서 수행되는 장애 처리 방법에 있어서, 네트워크 장치로부터 네트워크 장치에 발생한 장애 유형에 따라 구별된 정보를 수신하는 단계와; 장애 유형에 따라 구별된 정보에 따라 장애를 처리하는 단계를 포함한다.
여기에서, 상기 장애 유형에 따라 구별된 정보는, 네트워크 장치에 대한 장애가 예측된 경우, 네트워크 장치가 다운(down)될 것이라는 알림 정보를 포함하고, 네트워크 장치에 대한 장애가 예측되지 않은 경우, 네트워크 장치의 재시작(restart)를 알리는 알림 정보를 포함할 수 있다.
여기에서, 상기 네트워크 장치에 발생한 장애 유형에 따라 구별된 정보를 수신하는 단계는, 네트워크 장치에 대한 장애가 예측된 경우, 네트워크 장치가 다운될 시간 정보를 포함하는 알림 정보를 수신할 수 있다.
여기에서, 상기 네트워크 장치가 다운될 시간 정보는, 네트워크 장치가 생성한 타임 스탬프(time stamp)를 이용할 수 있다.
여기에서, 상기 네트워크 장치에 발생한 장애 유형에 따라 구별된 정보를 수신하는 단계는, 네트워크 장치에 대한 장애가 예측되지 않은 경우, 네트워크 장치의 재시작 횟수를 수신할 수 있다.
여기에서, 상기 네트워크 장치에 대한 장애를 처리하는 단계는, 장애가 발생한 네트워크 장치에 보낼 메시지를 로그에 기록하고 전송을 보류할 수 있다.
여기에서, 메시지 브로커(message broker)가 적어도 하나의 컨트롤러와 네트워크 장치 상호 간의 메시지 교환을 중계할 수 있다.
상기와 같은 본 발명에 따른 네트워크 장치에 대한 장애를 처리하는 방법은, 라우터의 장애 유형 별로 그레이스풀 장애(Graceful Failure)와 크래쉬(Crash)에 대한 처리 메커니즘을 정의함으로써, 관련된 모든 컨트롤러가 라우터의 장애 정보를 신속히 파악할 수 있다.
또한, 그레이스풀 장애(Graceful Failure)나 크래쉬(Crash)에 대한 정보를 이용하여 라우터에 장애가 발생한 이후, 컨트롤러가 해당 라우터로 전송하고자 하는 모든 메시지를 로그에 기록한 후 전송을 보류(pause) 함으로써, 불필요한 메시지 재전송 시도를 줄여 망의 부하를 줄일 수 있다.
도 1은 본 발명의 실시예에 따른 라우팅 시스템의 구조를 설명하기 위한 블록도이다.
도 2는 본 발명의 실시예에 따른 네트워크 장치에 대한 장애 처리 방법을 설명하기 위한 순서도이다.
도 3은 본 발명의 실시예에 따른 메시지 브로커를 이용한 이벤트의 발행 및 구독을 설명하기 위한 개념도이다.
도 4는 본 발명의 실시예에 따른 메시지 브로커를 이용한 이벤트의 발행 및 구독을 설명하기 위한 순서도이다.
도 5는 본 발명의 실시예에 따른 메시지 브로커를 이용하여 네트워크 장치에 대한 예측된 장애를 처리하는 방법을 설명하기 위한 순서도이다.
도 6은 본 발명의 실시예에 따른 메시지 브로커가 네트워크 장치에 대한 예측된 장애를 처리하는 방법을 설명하기 위한 흐름도이다.
도 7은 본 발명의 실시예에 따른 메시지 브로커가 없는 상태에서 네트워크 장치에 대한 예측된 장애를 처리하는 방법을 설명하기 위한 순서도이다.
도 8은 본 발명의 실시예에 따른 메시지 브로커를 이용하여 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법을 설명하기 위한 순서도이다.
도 9는 본 발명의 실시예에 따른 메시지 브로커가 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법을 설명하기 위한 순서도이다.
도 10은 본 발명의 실시예에 따른 메시지 브로커가 없는 상태에서 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법을 설명하기 위한 순서도이다.
본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.
제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이하, 본 발명에서 언급되는 '컨트롤러(controller)' 또는 '클라이언트(Client)'는 트래픽의 흐름을 제어하기 위해 관련 구성 요소(예를 들면, 스위치, 라우터 등)를 제어하는 기능 요소(entity)를 의미하는 것으로, 물리적인 구현 형태나 구현 위치 등에 한정되지 않는다. 예를 들어, 컨트롤러는 ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 컨트롤러 기능 요소(entity)를 의미할 수 있다.
또한, 본 발명에서 언급되는 '네트워크 장치' 또는 '에이전트(Agent)'는 트래픽(또는 패킷)을 실질적으로 포워딩하거나 스위칭 또는 라우팅하는 기능 요소를 의미하는 것으로, ONF, IETF, ETSI 및/또는 ITU-T 등에서 정의하고 있는 스위치, 라우터, 스위치 요소, 라우터 요소, 포워딩 요소 등을 의미할 수 있다.
또한, 이하에서 기술되는 본 발명의 실시예들은 SDN 기술의 표준화를 수행하고 있는 ONF, IETF, ETSI, ITU-T들에서 작성된 표준 문서들 및/또는 전달 네트워크에 관한 표준화를 수행하는 IEEE, ITU-T, IETF들에서 작성된 표준 문서들에 의해 뒷받침될 수 있다. 즉, 본 발명의 실시예들 중 본 발명의 기술적 사상을 명확히 드러내기 위해 구체적으로 설명하지 않은 내용들은 상기의 표준화 단체들에서 작성한 표준 문서들에 의해 뒷받침될 수 있다. 또한, 본 발명에서 사용되는 모든 용어들은 상기 표준 문서에 의해 설명될 수 있다.
이하, 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.
도 1은 본 발명의 실시예에 따른 라우팅 시스템의 구조를 설명하기 위한 블록도이다.
도 1을 참조하면, 컨트롤러(100)의 제어 대상인 라우터(200)는 복수 개로 구성될 수 있고, 이를 제어하는 컨트롤러(100)도 부하 분산, 안정성을 높이기 위해 복수 개로 구성될 수 있다.
도 1은 라우터(200)와 물리적으로 분리되어 외부에 위치한 제1 컨트롤러에서 제M 컨트롤러로 표시되는 M개의 컨트롤러(100)가 제1 라우터에서 제N 라우터로 표시되는 N개의 라우터(200)를 제어하는 경우를 도시한다.
각각의 컨트롤러(100)는 네트워크 애플리케이션(300)과 연동하여 동작할 수 있다. 또한, 각각의 컨트롤러(100)는 하나 또는 다수의 어플리케이션(300)과 연동하여 동작할 수 있다. 예를 들어, 각각의 컨트롤러(100)는 어플리케이션(300)에 필요한 정보를 제공하거나, 어플리케이션(300)의 요청을 수행할 수 있다.
상세하게는, 도 1은 라우터(200) 내의 제어 평면(Control Plane) 상에 존재하는 에이전트(agent) 모듈(211)과 컨트롤러(100) 상에 존재하는 클라이언트(client) 모듈(101) 상호 간에 표준화된 라우팅 시스템 인터페이스(I2RS: Interface to Routing System)를 통해 상호 통신이 되는 구조를 나타낸다.
Client 모듈(101)은 어플리케이션(300)으로부터 라우팅 정책이나 제어 명령을 전달받아 Agent 모듈(211)이 파싱(parsing) 가능한 형태로 수신된 정책이나 제어 명령을 메시지로 변환 및 전달 기능을 수행할 수 있다.
Agent 모듈(211)은 전달된 정책이나 제어 정보를 파싱하여 라우터(200) 내 연결되어 있는 토폴로지 데이터베이스(Topology DB)(212), 정책 데이터베이스(Policy DB)(215), RIB(Routing Information Base) 모듈(214) 및 라우팅/시그널링 프로토콜(Routing/Signaling protocol) 모듈(213) 및 OAM 이벤트 모듈(216) 등과 상호 동작을 수행할 수 있다.
또한, Forwarding information base 모듈(217)은 라우터(200)의 데이터 평면(Data Plane) 상에 존재할 수 있다. 따라서, Agent 모듈(211)로부터의 정보는 Routing information base 모듈(214)을 거쳐 데이터 평면의 Forwarding information base 모듈(217)로 전달될 수 있다.
더 나아가, 운영자로부터 미리 설정된 라우터(200)들의 다양한 이벤트 정보나 통계 정보를 Agent 모듈(211)을 통해 Client 모듈(101)로 전달하는 모니터링 기능을 수행할 수 있다.
라우터(200)를 제어하는 컨트롤러(100)와 표준 인터페이스를 통하여 통신을 담당하는 라우터(200) 내의 모듈인 Agent 모듈(211)은 라우팅 시스템의 안정성과 신뢰성 측면에서 매우 중요하다.
그러나, 현재는 Agent 모듈(211)의 장애에 대한 처리 구조와 메커니즘이 정의되어 있지 않은 상황이다. 즉, I2RS(Interface To the Routing System) 표준화 그룹에서는 라우터 장애(Router Failure)(또는 에이전트 장애(Agent Failure))에 대해 논의가 되고 있지만, 구체적인 메커니즘이 정립되지 않은 상황이다. 따라서 라우터 장애(Router Failure)(또는 에이전트 장애(Agent Failure))에 대한 적절한 처리 방안에 대한 정의가 필요하다.
한편, I2RS 환경에서 메시지 전송 방식 측면에서 프로토콜(Protocol)에 대한 요구사항 정의가 필요하다. 도 1와 같이 다수의 컨트롤러(100)가 다수의 라우터(200)와 연결되어 동작하는 환경에서 컨트롤러(100)와 라우터(200) 간에 인터페이스를 통해 전달되는 메시지는 컨트롤러(100)의 수와 라우터(200)의 수가 많아질수록 각각의 컨트롤러(100)와 라우터(200)가 관리해야 할 관계(relation)의 수가 증가하게 된다.
예를 들어, N개의 라우터(200)와 M개의 컨트롤러(100)가 모두 관계를 맺을 때 직접 관리해야 하는 관계(relation)의 수는 N × M 이 된다.
또한, 새로운 라우터(200)나 컨트롤러(100)가 추가 될 때, 해당 라우터(200)나 컨트롤러(100)에 의해 영향을 받는 모든 컨트롤러(100)와 라우터(200)에 새로 추가되는 라우터(200)의 추가 작업을 수행해야 하는 등 확장성 문제도 있다.
따라서, 본 발명에서는 라우터 장애(Router Failure)(또는 에이전트 장애(Agent Failure))에 대한 처리 방법을 제시하며, 라우터 장애(Router Failure)(또는 에이전트 장애(Agent Failure)) 등 I2RS 인터페이스 메시지의 발행/구독(Publish/Subscribe) 방식 구조를 개선하는 방법을 제공한다.
도 2는 본 발명의 실시예에 따른 네트워크 장치에 대한 장애 처리 방법을 설명하기 위한 순서도이다.
도 2를 참조하면, 라우터(200)는 장애 발생에 대한 예측 가능 여부에 따라 장애를 분류할 수 있다(S210). 예를 들어, 라우터(200)는 예측이 가능한 셧다운(shutdown)이나 장애가 발생한 경우를 그레이스풀 장애(graceful failure)로 분류하고, 라우터(200)에 갑자기 장애가 발생한 경우를 크래쉬(Crash)로 구분할 수 있다.
라우터(200)는 그레이스풀 장애(graceful failure)의 발생을 감지할 경우, 라우터(200)는 자신과 연결된 모든 컨트롤러들(100)에 대한 정보를 조회 또는 탐색하여(S211), 해당 컨트롤러들(100)에게 라우터가 다운(down)될 것 임을 통보할 수 있다(S213). 이 때, 컨트롤러들(100)은 다운될 라우터(200)에게 보낼 메시지를 로그에 기록하고 전송을 보류할 수 있다.
라우터(200)에 예상되지 않은 크래쉬(crash)가 발생할 수 있으며(S230), 이러한 경우, 컨트롤러들(100)은 해당 라우터(200)의 장애를 알 수 없다. 따라서, 컨트롤러(100)는 크래쉬가 발생한 라우터(200)를 빠른 시간에 알 수 있도록 라우터(200)가 컨트롤러(100)로 하트비트(Heartbeat)와 같은 상태(Health)를 체크하는 메시지를 전송할 수 있다(S220). 다만, 라우터(200)에 의한 하트비트(Heartbeat) 메시지의 전송은 선택적(optional)으로 수행될 수 있다.
컨트롤러(100)는 라우터(200)로부터의 하트비트를 수신하지 못하거나 일정한 주기에 라우터(200)에 발생한 크래쉬를 감지하지 못할 수 있다(S231). 이러한 경우, 컨트롤러(100)는 라우터(200)로 메시지 전송하기 위한 연결(Connection)을 요청할 수 있고(S240), 라우터(200)가 크래쉬(Crash)된 상태이므로 컨트롤러(100)는 연결 실패(Connection Fail)와 같은 에러 응답(Reply)을 받을 수 있다(S241).
따라서, 컨트롤러(100)는 하트비트(Heartbeat) 메시지의 미수신 또는 연결 실패(Connection Fail)와 같은 에러 응답(Reply)을 통하여 라우터(200)에 발생한 크래쉬(Crash)를 감지할 수 있다(S243)
컨트롤러(100)는 크래쉬(Crash) 상태가 된 라우터(200)에게 보낼 메시지를 로그에 기록하고 전송을 보류할 수 있다(S250). 또한, 컨트롤러(100)는 해당 라우터와 관련된 다른 컨트롤러(100)의 목록을 조회하여 라우터 장애(Router Failure)를 통보할 수 있음은 물론이다.
한편, 하트비트(Heartbeat) 메시지의 미수신 또는 연결 실패(Connection Fail)와 같은 에러 응답(Reply)을 통해서도 라우터(200)에 발생한 크래쉬(Crash)를 감지하지 못할 수 있으며, 이러한 경우의 처리를 설명하면 다음과 같다.
라우터(200)가 크래쉬(Crash)를 해결하고 재시작(Reboot)될 수 있다(S260). 라우터(200)가 재시작되면, 라우터(200)는 모든 관련된 컨트롤러들(100)에게 재시작(Reboot)됨을 통보할 수 있다(S261). 이 때, 이전 세션과의 분리를 위하여 세션 ID(Session ID), 부트 카운트(Boot count) 부트 타임(Boot Time) 등에 대한 정보를 포함시켜 통보할 수 있다. 여기서, 부트 카운트는 라우터(200)가 전부 몇 번째 시작(boot) 되었는지 횟수를 의미할 수 있다.
따라서, 컨트롤러(100)는 라우터(200)로부터 장애에 대한 통보를 받지 못하였더라도, 라우터가(200) 장애로 인해 재시작(Reboot)되었음을 알 수 있게 된다.
컨트롤러는 라우터(100)의 장애로 인해 미전송된 메시지를 라우터(200)가 재시작(Agent Reboot) 이후에 정책에 따라 재전송하거나 삭제할 수 있다(S263). 예를 들어, 메시지 유형에 따라 QoS, 통계, 이벤트(Event)에 대한 정보는 모두 재전송할 수 있고, 토폴로지(topology) 및 RIB에 대한 변경 정보는 모두 삭제할 수 있다. 또한, 1시간 이전의 메시지는 모두 삭제하고, 1시간 이내의 메시지는 재전송하는 방식으로 정책 별로 미전송된 메시지를 처리할 수 있다.
도 3은 본 발명의 실시예에 따른 메시지 브로커를 이용한 이벤트의 발행 및 구독을 설명하기 위한 개념도이다.
도 3을 참조하면, 컨트롤러(100)와 라우터(200) 간에 주고 받는 메시지의 종류가 많고 다양한 경우, 컨트롤러(100)와 라우터(200) 간의 연관성을 줄이고 세션 관리의 부담을 줄이기 위해 발행(Publish) 및 구독(Subscribe)의 방식을 사용할 수 있다.
또한, 컨트롤러(100)와 라우터(200) 간의 상호 종속성을 줄이고, 다수의 컨트롤러(100)와 라우터(200) 간의 관계 관리의 복잡성과 부담을 줄이기 위해 메시지 브로커(Message Broker)(400)를 활용할 수 있다.
메시지 브로커(400)는 다수의 컨트롤러(100)와 다수의 라우터(200) 상호 간의 메시지 교환을 중계할 수 있다. 예를 들어, 메시지 브로커(400)는 발생/구독 관계(Publish/Subscribe Relation) DB(500)를 참조하여 다수의 컨트롤러(100)와 다수의 라우터(200) 상호 간의 메시지를 중계할 수 있고, 중계에 의한 메시지 교환에 대한 로그 정보를 메시지 로그(Message Log) DB(600)에 저장할 수 있다.
도 4는 본 발명의 실시예에 따른 메시지 브로커를 이용한 이벤트의 발행 및 구독을 설명하기 위한 순서도이다.
도 4를 참조하면, 본 발명의 실시예에 따른 메시지 브로커를 이용한 이벤트의 발행 및 구독을 위한 방법은, 구독/발행 등록(Subscription/Publication Registration) 단계(S410), 인증/권한(Authenticate/Authorize) 단계(S420), 이벤트 발행(Event Publication) 단계(S430) 및 이벤트 구독(Event Subscription) 단계(S440)로 구성될 수 있다.
도 4를 참조하여 각 단계에서 사용하는 메시지를 설명하면 다음과 같다.
도 4는 메시지 브로커(MB)(400)가 있는 발행/구독(Publish/Subscribe) 메시지 전송 단계에서 각 단계별 메시지와 파라미터에 대한 실시 예이다.
먼저, 구독/발행 등록(Subscription/Publication Registration) 단계(S410)는 구독(Subscription) 등록 요청 및 발행(Publication) 등록 요청을 위한 메시지를 이용하여 수행될 수 있다.
컨트롤러(100)는 메시지 브로커에 구독(Subscription) 등록 요청을 위한 메시지를 전송하고, 라우터(200)는 메시지 브로커에 발행(Publication) 등록 요청을 위한 메시지를 전송할 수 있다.
따라서, 메시지 브로커(400)는 구독(Subscription) 등록 요청 및 발행(Publication) 등록 요청을 위한 메시지를 수신하여 구독을 요청한 컨트롤러(100)와 발행을 요청을 라우터(200)를 알 수 있다.
또한, 구독/발행 등록(Subscription/Publication Registration) 단계(S410)에서 사용되는 메시지에는 하기의 표 1에 포함된 정보가 포함될 수 있다.
즉, 표 1의 정보를 이용하여 Publisher와 Subscriber를 구분할 수 있다. 또한, 요청 상태에 대한 정보를 이용하여 등록, 일시 정지, 일시 정지 해지, 등록 해지 등을 수행할 수 있다.
표 1
파라미터 설명 비고
Msg id 메시지 id
Requester id 등록을 요청하는 컨트롤러 id 또는 라우터 id 등록 요청하는 컨트롤러, 라우터의 식별 정보
Order type 요청 상태 등록, 일시 정지, 일시 정지 해지, 등록 해지
Role 등록하고자 하는 역할 구분 Publisher 또는 Subscriber
Event type 발행/구독하고자 하는 이벤트의 유형 Policy, Routing Information, Fault, Statistics 등
Time stamp 요청 시각 등록 요청 메시지의 요청 시각
인증/권한(Authenticate/Authorize) 단계(S420)에서 메시지 브로커(400)와 컨트롤러(100) 및 라우터(200) 상호 간에 인증 및 권한 부여를 수행할 수 있다. 즉, 메시지 브로커(400)와 컨트롤러(100) 및 라우터(200) 상호 간에 서로를 인증하고, 각각의 역할에 따른 권한의 요청 및 부여를 할 수 있다.
또한, 인증/권한(Authenticate/Authorize) 단계(S420)에서 사용되는 메시지에는 하기의 표 2에 포함된 정보가 포함될 수 있다.
표 2
파라미터 설명 비고
Msg id 메시지 id
Requester id 인증/권한을 요청하는 메시지 브로커 id, 컨트롤러 id 또는 라우터 id 인증을 하기 위해 인증을 요청하는 메시지 브로커, 컨트롤러, 라우터의 식별 정보
Order type 요청 상태 등록, 일시 정지, 일시 정지 해지, 등록 해지
Role 역할 구분 Publisher 또는 Subscriber 또는 메시지 브로커
Event type 발행/구독하고자 하는 이벤트의 유형 Policy, Routing Information, Fault, Statistics 등
Time stamp 요청 시각 요청 메시지의 요청 시각
이벤트 발행(Event Publication) 단계(S430)에서 메시지 브로커(400)는 컨트롤러(100) 및 라우터(200)로부터 발행된 이벤트를 수신할 수 있다.
이벤트 구독(Event Subscription) 단계(S440)에서 메시지 브로커(400)는 컨트롤러(100) 및 라우터(200)에 의해 발행된 이벤트를 컨트롤러(100) 및 라우터(200)로 제공할 수 있다.
또한, 이벤트 발행(Event Publication) 단계(S430) 및 이벤트 구독(Event Subscription) 단계(S440)에서 사용되는 메시지에는 하기의 표 3에 포함된 정보가 포함될 수 있다.
표 3
파라미터 설명 비고
Msg id 메시지 id 구독 메시지 id
Publisher id 발행한 컨트롤러 id 또는 라우터 id
Subscriber id 구독받는 컨트롤러 id 또는 라우터 id
Priority 메시지 우선 순위 우선 순위가 높을수록 지연이나 손실없이 보내야 함
Event type 이벤트의 유형 Policy, Routing Information, Fault, Statistics 등
Event message 이벤트 메시지 Router Shutdown, Agent Crash, Agent Reboot 등에 대한 상세한 메시지
Event time 이벤트가 발생한 시각 Router boot time, Router shutdown time 등
Time stamp 메시지 요청 시각 구독 메시지의 요청 시각
도 5는 본 발명의 실시예에 따른 메시지 브로커를 이용하여 네트워크 장치에 대한 예측된 장애를 처리하는 방법을 설명하기 위한 순서도이고, 도 6은 본 발명의 실시예에 따른 메시지 브로커가 네트워크 장치에 대한 예측된 장애를 처리하는 방법을 설명하기 위한 흐름도이다.
도 5는 메시지 브로커(400)가 있는 구조에서 그레이스풀 장애(Graceful Failure)를 처리 절차를 나타낸다.
도 5를 참조하면, 본 발명의 실시예에 따른 메시지 브로커(400)를 이용하여 네트워크 장치에 대한 예측된 장애를 처리하는 방법은, 구독/발행 등록(Subscription/Publication Registration) 단계(S510), 인증/권한(Authenticate/Authorize) 단계(S520), 라우터 장애 발행(Router Failure Publication) 단계(S430) 및 라우터 장애 구독(Router Failure Subscription) 단계(S540)로 구성될 수 있다. 여기서, 도 5에 따른 각각의 단계는 도 4에 따른 각각의 단계에 대응하는 것으로 이해될 수 있다.
상세하게는, 컨트롤러(100)는 라우터 장애(Router Failure) 구독 등록을 메시지 브로커(400)에 할 수 있고, 라우터(200)는 라우터 장애 발행 등록 요청을 메시지 브로커(400)에 할 수 있다(S510).
메시지 브로커(400)와 구독 및 발행을 등록한 컨트롤러(100) 및 라우터(200)는 상호 간에 서로를 인증하고, 각각의 역할에 따른 권한의 요청 및 부여할 수 있다(S520).
라우터(200)는 라우터 장애(Router Failure)의 발생에 따라 라우터 장애(Router Failure) 이벤트를 메시지 브로커(400)로 발행할 수 있다(S530).
따라서, 메시지 브로커(400)는 라우터 장애(Router Failure) 이벤트를 구독 요청한 컨트롤러(100)에 전달할 수 있고, 해당 라우터(100)의 상태를 장애 상태로 변경할 수 있다(S540).
도 6은 도 5의 S530 및 S540 단계를 더욱 상세히 설명한다.
도 6을 참조하면, 라우터(200)는 라우터 장애 이벤트를 발행(publish)하고, 메시지 브로커(400)는 컨트롤러(100)에 라우터의 장애를 알릴 수 있다. 또한, 메시지 브로커(400)는 장애가 발생한 해당 라우터(200)의 상태를 장애(Fail)로 변경할 수 있다.
메시지 브로커(400)는 라우터 장애에 대한 발행(Publication)을 수신하여 이를 메시지 로그에 기록할 수 있다(S610).
메시지 브로커(400)는 발행/구독(publish/subscribe) 관계 정보를 조회하여 해당 라우터(200)와 연결된 구독자인 컨트롤러(100)를 조회할 수 있다(S620).
또한, 메시지 브로커(400)는 메시지에 대한 전송 우선권(Priority)에 따라 대기 행렬(Queue)에 넣어, 해당 컨트롤러(100)에게 라우터 장애를 통보할 수 있다(S630, S640). 이 때, 우선권(priority) 별로 대기 행렬(Queue)에 넣어 처리함으로써, 여러 개의 메시지 중 들에서도 긴급하고 중요한 메시지를 지연이나 손실이 없이 전송할 수 있다.
마지막으로, 메시지 브로커(400)는 라우터 장애가 발생한 해당 라우터(200)의 상태를 장애(Failure) 상태로 변경할 수 있다(S650).
상술한 도 5 및 도 6에 도시된 같이 메시지 브로커(400)를 이용하여 컨트롤러(100)와 라우터(200) 간의 메시지를 처리할 경우 다음과 같은 장점이 있다.
메시지 브로커(400)가 컨트롤러(100)와 라우터(200) 간의 연결 관계가 연결된 상태인지, 끊어진 상태인지(Router Failure등에 의해)를 중앙에서 집중 관리할 수 있다.
메시지 브로커(400)가 최종적으로 발행(Subscription)과 구독(Publication)에 대한 역할을 대신하기 때문에 컨트롤러(100)와 라우터(200) 사이에 메시지를 전송해야 하는 부담을 줄일 수 있다.
컨트롤러(100) 또는 라우터(200)에 장애가 발생하여 메시지 전송이 불가능한 상황에서도, 메시지 브로커(400)가 메시지를 로그로 저장함으로써 메시지의 비동기화(asynchronous) 전송을 가능하게 한다. 예를 들어, 메시지 브로커(400)는 라우터 장애 시에 메시지를 로그에 저장하고, 장애가 복구된 이후 미전송된 메시지를 일괄하여 전송할 수 있다.
메시지 브로커(400)가 메시지의 우선권(Priority)을 전체적으로 관리하여 메시지 전송에 혼잡(congestion)이 발생할 때, 망 전체적으로 우선 순위 별 메시지의 전송을 보장할 수 있다. 따라서, 망에 발생한 이벤트(Event)를 신속하게 전달함으로써 망의 안정성 및 신뢰성을 개선할 수 있다.
도 7은 본 발명의 실시예에 따른 메시지 브로커가 없는 상태에서 네트워크 장치에 대한 예측된 장애를 처리하는 방법을 설명하기 위한 순서도이다.
도 7을 참조하면, 도 5에 따른 실시예와 달리 컨트롤러(100)와 라우터(200) 간에 메시지 전달을 중계하는 메시지 브로커(400)가 없이 직접 컨트롤러(100)와 라우터(200) 간의 정보 교환을 통하여 장애를 처리할 수 있다.
즉, 컨트롤러(100)와 라우터(200)는 상호 간에 직접 인증을 수행하고, 상호 간의 연결 정보를 각각 관리할 수 있다.
상세하게는, 본 발명의 실시예에 따른 메시지 브로커(400)가 없는 상태에서 네트워크 장치에 대한 예측된 장애를 처리하는 방법은, 구독/발행 등록(Subscription/Publication Registration) 단계(S710), 인증/권한(Authenticate/Authorize) 단계(S720), 라우터 장애 발행(Router Failure Publication) 단계(S730) 및 라우터 장애 구독(Router Failure Subscription) 단계(S740)로 구성될 수 있다. 여기서, 도 7에 따른 각각의 단계는 도 4에 따른 각각의 단계에 대응하는 것으로 이해될 수 있다.
컨트롤러(100)는 라우터 장애(Router Failure) 구독 등록 요청을 라우터(200)에 할 수 있다(S710).
컨트롤러(100)와 라우터(200)는 상호 간에 서로를 인증하고, 각각의 역할에 따른 권한의 요청 및 부여를 할 수 있다(S720).
라우터(200)는 라우터 장애(Router Failure)의 발생에 따라 라우터 장애(Router Failure) 이벤트를 컨트롤러(100)로 발행할 수 있다(S730).
컨트롤러(100)는 해당 라우터(200) 상태를 장애 상태로 변경할 수 있다(S740).
따라서, 도 5 내지 도 7을 참조하여 네트워크 장치가 수행하는 장애 처리 방법을 설명하면 다음과 같다.
네트워크 장치는 네트워크 장치에 대한 장애를 예측할 수 있고, 네트워크 장치에 대한 장애가 예측된 경우, 컨트롤러(100)에 네트워크 장치가 다운(down)될 것을 알리는 메시지를 전송할 수 있다.
즉, 네트워크 장치에 대한 장애가 예측된 경우, 네트워크 장치가 다운될 시간 정보를 포함하여 컨트롤러(100)에 네트워크 장치가 다운될 것을 알릴 수 있다. 여기서, 네트워크 장치가 다운될 시간 정보는 네트워크 장치가 생성한 타임 스탬프(time stamp)를 이용할 수 있다.
또한, 네트워크 장치는 컨트롤러(100)에 대한 리스트를 저장하는 저장부로부터 네트워크 장치와 관련된 컨트롤러(100)를 탐색할 수 있고, 탐색된 컨트롤러(100)에 네트워크 장치가 다운될 것을 알리는 메시지를 전송할 수 있다.
도 8은 본 발명의 실시예에 따른 메시지 브로커를 이용하여 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법을 설명하기 위한 순서도이고, 도 9는 본 발명의 실시예에 따른 메시지 브로커가 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법을 설명하기 위한 흐름도이다.
도 8을 참조하면, 본 발명의 실시예에 따른 메시지 브로커(400)를 이용하여 네트워크 장치에 대한 예측된 장애를 처리하는 방법은, 구독/발행 등록(Subscription/Publication Registration) 단계(S810), 인증/권한(Authenticate/Authorize) 단계(S820), 라우터 장애 발행(Router Failure Publication) 단계(S830) 및 라우터 장애 구독(Router Failure Subscription) 단계(S840)로 구성될 수 있다. 여기서, 도 8에 따른 각각의 단계는 도 4에 따른 각각의 단계에 대응하는 것으로 이해될 수 있다.
상세하게는, 컨트롤러(100)는 라우터 재시작(Router Reboot) 구독 등록 요청을 메시지 브로커(400)에 할 수 있고, 라우터(200)는 라우터 재시작 발행 등록 요청을 메시지 브로커(400)에 할 수 있다(S810).
메시지 브로커(400)와 구독 및 발행을 등록한 컨트롤러(100) 및 라우터(200)는 상호 간에 서로를 인증하고, 각각의 역할에 따른 권한의 요청 및 부여를 할 수 있다(S820).
라우터(200)는 라우터 재시작(Router Reboot)에 따라 라우터 재시작(Router Reboot) 이벤트를 메시지 브로커(400)로 발행할 수 있다(S830).
따라서, 메시지 브로커(400)는 라우터 재시작(Router Reboot) 이벤트를 구독 요청한 컨트롤러(100)에 전달할 수 있고, 해당 라우터(200)의 상태를 장애 상태로 변경할 수 있다(S840).
도 9은 도 8의 S830 및 S840 단계를 더욱 상세히 설명한다.
도 9을 참조하면, 라우터(200)는 라우터 재시작 이벤트를 발행(publish)하고, 메시지 브로커(400)는 컨트롤(100)에 라우터 재시작을 알릴 수 있다. 또한, 메시지 브로커(400)는 장애가 발생한 해당 라우터(200)의 상태를 장애(Fail)로 변경할 수 있다.
메시지 브로커(400)는 라우터 재시작에 대한 발행(Publication)을 수신하여 이를 메시지 로그에 기록할 수 있다(S910).
메시지 브로커(400)는 발행/구독(publish/subscribe) 관계 정보를 조회하여 해당 라우터와 연결된 구독자인 컨트롤러를 조회할 수 있다(S920).
또한, 메시지 브로커(400)는 메시지에 대한 전송 우선권(Priority)에 따라 대기 행렬(Queue)에 넣어, 해당 컨트롤러(100)에게 라우터 장애를 통보할 수 있다(S930, S940). 이 때, 우선권(priority) 별로 대기 행렬(Queue)에 넣어 처리함로써, 여러 개의 메시지 중 들에서도 긴급하고 중요한 메시지를 지연이나 손실이 없이 전송할 수 있다.
또한, 메시지 브로커(400)는 세션 ID(Session ID), 부트 카운트(Boot Count), 부트 타임(Boot Time) 등과 같은 정보를 포함한 메시지를 컨트롤러(100)로 전송하여 라우터 장애 또는 재시작에 대한 정보를 컨트롤러(100)가 수신하지 못하였더라도 라우터 장애에 의해 다시 시작(Boot)된 시간 및 횟수를 컨트롤러(100)에 알려줄 수 있다.
마지막으로, 메시지 브로커(400)는 재시작된 라우터의 상태를 장애(Failure) 상태로 변경할 수 있다(S950).
도 10은 본 발명의 실시예에 따른 메시지 브로커가 없는 상태에서 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법을 설명하기 위한 순서도이다.
도 10을 참조하면, 도 8에 따른 실시예와 달리 컨트롤러(100)와 라우터 (200)간에 메시지 전달을 중계하는 메시지 브로커(400)가 없이 직접 컨트롤러(100)와 라우터(200) 간의 정보 교환을 통하여 라우터의 장애에 따른 재시작을 처리할 수 있다.
즉, 컨트롤러(100)와 라우터(200) 상호 간 직접 인증을 수행하고, 상호 간의 연결 정보를 각각 관리할 수 있다.
상세하게는, 본 발명의 실시예에 따른 메시지 브로커(400)가 없는 상태에서 네트워크 장치에 대한 예측되지 않은 장애를 처리하는 방법은, 구독/발행 등록(Subscription/Publication Registration) 단계(S1010), 인증/권한(Authenticate/Authorize) 단계(S1020), 라우터 장애 발행(Router Failure Publication) 단계(S1030) 및 라우터 장애 구독(Router Failure Subscription) 단계(S1040)로 구성될 수 있다. 여기서, 도 10에 따른 각각의 단계는 도 4에 따른 각각의 단계에 대응하는 것으로 이해될 수 있다.
컨트롤러(100)는 라우터 재시작(Router Reboot) 구독 등록 요청을 라우터(200)에 할 수 있다(S1010).
컨트롤러(100)와 라우터(200)는 상호 간에 서로를 인증하고, 각각의 역할에 따른 권한의 요청 및 부여를 할 수 있다(S1020).
라우터(200)는 라우터 재시작(Router Reboot)에 따라 라우터 재시작(Router Reboot) 이벤트를 컨트롤러(100)로 발행할 수 있다(S1030).
컨트롤러(100)는 해당 라우터(200)의 상태를 장애 상태로 변경할 수 있다(S1040).
따라서, 도 8 내지 도 10을 참조하여 네트워크 장치가 수행하는 장애 처리 방법을 설명하면 다음과 같다.
네트워크 장치는 장애를 복구하여 재시작될 수 있다. 재시작이 네트워크 장치에 대한 장애에 기반한 경우, 컨트롤러(100)에 네트워크 장치의 재시작에 대한 정보를 전송할 수 있다. 예를 들어, 네트워크 장치는 네트워크 장치에 대한 장애가 예측되지 않고 발생되었음을 네트워크 장치의 재시작에 대한 정보를 이용하여 컨트롤러(100)에 알릴 수 있다. 또한, 네트워크 장치는 네트워크 장치의 재시작에 대한 정보에 따른 네트워크 장치의 재시작 횟수에 기반하여 컨트롤러에 네트워크 장치에 대한 장애를 알릴 수 있다.
또한, 네트워크 장치는 컨트롤러(100)에 대한 리스트를 저장하는 저장부로부터 네트워크 장치와 관련된 컨트롤러(100)를 탐색하고, 탐색된 컨트롤러(100)에 네트워크 장치의 재시작에 대한 정보를 전송할 수 있다.
한편, 도 5 내지 도 10을 참조하여 컨트롤러(100)가 수행하는 장애 처리 방법을 설명하면 다음과 같다.
컨트롤러(100)는 네트워크 장치에 대한 장애 정보를 네트워크 장치로부터 수신하고, 네트워크 장치에 대한 장애 정보를 이용하여 네트워크 장치에 대한 장애의 유형을 파악하여 네트워크 장치에 대한 장애를 처리할 수 있다.
여기서, 네트워크 장치에 대한 장애 정보는, 네트워크 장치에 대한 장애가 예측된 경우, 네트워크 장치가 다운(down)될 것이라는 알림 정보를 포함하고, 네트워크 장치에 대한 장애가 예측되지 않은 경우, 네트워크 장치의 재시작(restart)를 알리는 알림 정보를 포함할 수 있다.
먼저, 네트워크 장치에 대한 장애가 예측된 경우, 컨트롤러(100)는 네트워크 장치가 다운될 시간 정보를 포함하는 네트워크 장치가 다운될 것이라는 알림 정보를 이용하여 네트워크 장치에 대한 장애를 파악할 수 있다. 여기서, 네트워크 장치가 다운될 시간 정보는, 네트워크 장치가 생성한 타임 스탬프(time stamp)를 이용할 수 있다.
네트워크 장치에 대한 장애가 예측되지 않은 경우, 컨트롤러(100)는 네트워크 장치에 대한 장애 정보를 이용하여 네트워크 장치의 재시작 횟수에 산출하여 네트워크 장치에 대한 장애를 파악할 수 있다.
장애가 발생한 네트워크 장치를 파악한 후, 컨트롤러(100)는 장애가 발생한 네트워크 장치에 보낼 메시지를 로그에 기록하고 전송을 보류할 수 있다.
본 발명에 따르면, 라우터의 장애 유형 별로 그레이스풀 장애(Graceful Failure)와 크래쉬(Crash)에 대한 처리 메커니즘을 정의함으로써, 관련된 모든 컨트롤러가 라우터의 장애 정보를 신속히 파악할 수 있다.
또한, 서비스 품질(QoS)을 적용한 메시지 우선권(Priority)에 따라 지연이나 손실없이 우선적으로 러우터 장애와 같은 긴급한 메시지를 전송할 수 있다.
또한, 그레이스풀 장애(Graceful Failure)나 크래쉬(Crash)에 대한 정보를 이용하여 라우터에 장애가 발생한 이후, 컨트롤러가 해당 라우터로 전송하고자 하는 모든 메시지를 로그에 기록한 후 전송을 보류(pause) 함으로써, 불필요한 메시지 재전송 시도를 줄여 망의 부하를 줄일 수 있다.
또한, 라우터가 정상적으로 재시작(Reboot)된 후, 전송 보류된 메시지를 일괄 재전송하여 비동기적(Asynchronous)으로 컨트롤러와 라우터 간에 메시지 전송 동기화하거나, 보류 메시지를 취소하는 등 정책에 따른 처리를 할 수 있다.
상기에서는 본 발명의 바람직한 실시예를 참조하여 설명하였지만, 해당 기술 분야의 숙련된 당업자는 하기의 특허 청구의 범위에 기재된 본 발명의 사상 및 영역으로부터 벗어나지 않는 범위 내에서 본 발명을 다양하게 수정 및 변경시킬 수 있음을 이해할 수 있을 것이다.

Claims (17)

  1. 적어도 하나의 컨트롤러와 연결된 네트워크 장치에서 수행되는 장애 처리 방법에 있어서,
    상기 네트워크 장치에 대한 장애를 예측하는 단계; 및
    상기 네트워크 장치에 대한 장애가 예측된 경우, 상기 적어도 하나의 컨트롤러에 상기 네트워크 장치가 다운(down)될 것임을 통보하는 단계를 포함하는,
    네트워크 장치에 대한 장애 처리 방법.
  2. 청구항 1에 있어서,
    상기 네트워크 장치에 대한 장애가 예측된 경우, 상기 네트워크 장치가 다운될 시간 정보를 포함하여 상기 적어도 하나의 컨트롤러에 상기 네트워크 장치가 다운될 것임을 통보하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  3. 청구항 2에 있어서,
    상기 네트워크 장치가 다운될 시간 정보는,
    상기 네트워크 장치가 생성한 타임 스탬프(time stamp)를 이용하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  4. 청구항 1에 있어서,
    상기 네트워크 장치가 다운(down)될 것임을 통보하는 단계는,
    상기 적어도 하나의 컨트롤러에 대한 리스트를 저장하는 저장부로부터 상기 네트워크 장치와 관련된 컨트롤러를 탐색하는 단계; 및
    상기 탐색된 컨트롤러에 상기 네트워크 장치가 다운될 것을 알리는 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  5. 청구항 1에 있어서,
    메시지 브로커(message broker)가 상기 적어도 하나의 컨트롤러와 상기 네트워크 장치 상호 간의 메시지 교환을 중계하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  6. 적어도 하나의 컨트롤러와 연결된 네트워크 장치에서 수행되는 장애 처리 방법에 있어서,
    상기 네트워크 장치가 장애 극복 후 재시작되는 단계; 및
    장애 발생 사실을 알리기 위해 재시작에 대한 정보를 상기 적어도 하나의 컨트롤러에 전송하는 단계를 포함하는,
    네트워크 장치에 대한 장애 처리 방법.
  7. 청구항 6에 있어서,
    상기 재시작에 대한 정보를 상기 적어도 하나의 컨트롤러에 전송하는 단계는,
    예측되지 않은 장애가 상기 네트워크 장치에 발생하였음을 상기 재시작에 대한 정보를 이용하여 상기 적어도 하나의 컨트롤러에 알리는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  8. 청구항 6에 있어서,
    상기 재시작에 대한 정보에 상기 네트워크 장치의 재시작 횟수에 대한 정보를 포함시켜 상기 적어도 하나의 컨트롤러에 상기 네트워크 장치에 대한 장애를 알리는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  9. 청구항 6에 있어서,
    상기 재시작에 대한 정보를 상기 적어도 하나의 컨트롤러에 전송하는 단계는,
    상기 적어도 하나의 컨트롤러에 대한 리스트를 저장하는 저장부로부터 상기 네트워크 장치와 관련된 컨트롤러를 탐색하는 단계; 및
    상기 탐색된 컨트롤러에 상기 재시작에 대한 정보를 전송하는 단계를 포함하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  10. 청구항 6에 있어서,
    메시지 브로커(message broker)가 상기 적어도 하나의 컨트롤러와 상기 네트워크 장치 상호 간의 메시지 교환을 중계하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  11. 적어도 하나의 네트워크 장치에 연결된 컨트롤러에서 수행되는 장애 처리 방법에 있어서,
    상기 네트워크 장치로부터 네트워크 장치에 발생한 장애 유형에 따라 구별된 정보를 수신하는 단계; 및
    상기 장애 유형에 따라 구별된 정보에 따라 장애를 처리하는 단계를 포함하는,
    네트워크 장치에 대한 장애 처리 방법.
  12. 청구항 11에 있어서,
    상기 장애 유형에 따라 구별된 정보는,
    상기 네트워크 장치에 대한 장애가 예측된 경우, 상기 네트워크 장치가 다운(down)될 것이라는 알림 정보를 포함하고,
    상기 네트워크 장치에 대한 장애가 예측되지 않은 경우, 상기 네트워크 장치의 재시작(restart)를 알리는 알림 정보를 포함하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  13. 청구항 11에 있어서,
    상기 네트워크 장치에 발생한 장애 유형에 따라 구별된 정보를 수신하는 단계는,
    상기 네트워크 장치에 대한 장애가 예측된 경우, 상기 네트워크 장치가 다운될 시간 정보를 포함하는 알림 정보를 수신하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  14. 청구항 13에 있어서,
    상기 네트워크 장치가 다운될 시간 정보는,
    상기 네트워크 장치가 생성한 타임 스탬프(time stamp)를 이용하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  15. 청구항 11에 있어서,
    상기 네트워크 장치에 발생한 장애 유형에 따라 구별된 정보를 수신하는 단계는,
    상기 네트워크 장치에 대한 장애가 예측되지 않은 경우, 상기 네트워크 장치의 재시작 횟수를 수신하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  16. 청구항 11에 있어서,
    상기 네트워크 장치에 대한 장애를 처리하는 단계는,
    상기 장애가 발생한 네트워크 장치에 보낼 메시지를 로그에 기록하고 전송을 보류하는 것을 특징으로 하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
  17. 청구항 11에 있어서,
    메시지 브로커(message broker)가 상기 적어도 하나의 컨트롤러와 상기 네트워크 장치 상호 간의 메시지 교환을 중계하는 것을 특징으로 하는,
    네트워크 장치에 대한 장애 처리 방법.
PCT/KR2014/012220 2013-12-11 2014-12-11 Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법 WO2015088268A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/103,524 US20160315871A1 (en) 2013-12-11 2014-12-11 Method for processing failure of network device in software defined networking (sdn) environment

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20130154015 2013-12-11
KR10-2013-0154015 2013-12-11
KR10-2014-0177257 2014-12-10
KR1020140177257A KR101618989B1 (ko) 2013-12-11 2014-12-10 Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법

Publications (1)

Publication Number Publication Date
WO2015088268A1 true WO2015088268A1 (ko) 2015-06-18

Family

ID=53371490

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2014/012220 WO2015088268A1 (ko) 2013-12-11 2014-12-11 Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법

Country Status (1)

Country Link
WO (1) WO2015088268A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170142223A1 (en) * 2015-11-16 2017-05-18 Electronics And Telecommunications Research Institute Software-defined networking multi-orchestrator system
US9871725B2 (en) 2016-01-21 2018-01-16 International Business Machines Corporation Wireless data transfer as an alternative method to overcome errors or noise in a storage environment

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050135233A1 (en) * 2003-10-17 2005-06-23 Ip Infusion Inc., A Delaware Corporation Redundant routing capabilities for a network node cluster
KR20110043983A (ko) * 2009-10-22 2011-04-28 한국전자통신연구원 이중 링 네트워크의 동기화 방법
US20110238771A1 (en) * 2003-06-24 2011-09-29 Research In Motion Limited Distributed router application serialization
JP2013008320A (ja) * 2011-06-27 2013-01-10 Nippon Telegr & Teleph Corp <Ntt> ネットワークシステム、冗長化方法、障害検知装置及び障害検知プログラム
US20130223543A1 (en) * 2010-04-15 2013-08-29 Silver Spring Networks, Inc. Method and system for detecting failures of network nodes

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110238771A1 (en) * 2003-06-24 2011-09-29 Research In Motion Limited Distributed router application serialization
US20050135233A1 (en) * 2003-10-17 2005-06-23 Ip Infusion Inc., A Delaware Corporation Redundant routing capabilities for a network node cluster
KR20110043983A (ko) * 2009-10-22 2011-04-28 한국전자통신연구원 이중 링 네트워크의 동기화 방법
US20130223543A1 (en) * 2010-04-15 2013-08-29 Silver Spring Networks, Inc. Method and system for detecting failures of network nodes
JP2013008320A (ja) * 2011-06-27 2013-01-10 Nippon Telegr & Teleph Corp <Ntt> ネットワークシステム、冗長化方法、障害検知装置及び障害検知プログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170142223A1 (en) * 2015-11-16 2017-05-18 Electronics And Telecommunications Research Institute Software-defined networking multi-orchestrator system
US9871725B2 (en) 2016-01-21 2018-01-16 International Business Machines Corporation Wireless data transfer as an alternative method to overcome errors or noise in a storage environment
US10326691B2 (en) 2016-01-21 2019-06-18 International Business Machines Corporation Wireless data transfer as an alternative method to overcome errors or noise in a storage environment

Similar Documents

Publication Publication Date Title
KR101618989B1 (ko) Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법
WO2022005170A1 (ko) 에지 컴퓨팅 서비스를 제공하기 위한 에지 컴퓨팅 시스템 및 이동통신 네트워크 간의 연동 방법 및 그 장치
WO2011019144A2 (ko) 전자 패치 장치, 네트워크 시스템 및 네트워크 시스템에서의 동작 방법
WO2023033585A1 (ko) 분산 게이트웨이 환경에 최적화된 터널링 및 게이트웨이 접속 시스템 및 그에 관한 방법
WO2023018149A1 (en) Methods and systems for af control of network slice quota
WO2014112771A1 (ko) 클라이언트의 ｉｐ주소를 서버로 전송하는 중계 시스템 및 방법
WO2019200728A1 (zh) 虚拟网关主备切换方法、装置及计算机可读存储介质
WO2015062052A1 (zh) 一种m2m数据的查询、调用方法、查询、调用设备及系统
WO2020253125A1 (zh) 日志管理方法、装置、设备及存储介质
WO2013069981A1 (en) Communication system and operating method using home gateway
WO2015088268A1 (ko) Ｓｄｎ 환경에서 네트워크 장치에 대한 장애를 처리하는 방법
WO2013129804A1 (ko) 무선 네트워크 부하 저감 정책 분석 방법 및 시스템과 기록매체
WO2015080525A1 (ko) Sdn 환경에서 트래픽의 동적 제어를 위한 방법 및 장치
WO2014201613A1 (zh) 一种mep配置方法及网络设备
WO2015080512A1 (ko) 컨트롤러와 네트워크 장치 간 이벤트를 처리하는 방법
WO2020166927A1 (ko) 구독 및 통지를 수행하는 방법 및 장치
WO2012150778A2 (ko) 연결 상태 확인 이벤트에 기반하여 m2m 통신 개체간 연결을 관리하는 방법 및 장치
WO2021085723A1 (ko) 정보 중심 네트워크를 위한 기회적 라우팅 프로토콜을 통한 메시지 전송 방법, 이를 수행하기 위한 기록 매체 및 장치
WO2018236137A1 (ko) M2m 시스템에서 요청 메시지를 처리하는 방법 및 그 장치
WO2022005173A1 (ko) 기지국장치 및 기지국장치의 동작 방법
WO2011145896A2 (ko) 코디네이터 결정 방법 및 장치
WO2022039359A1 (ko) 엣지 통합 제어장치 및 엣지 통합 제어장치의 동작 방법
WO2011031097A2 (ko) 복수의 세션 설정 방법 및 이를 이용하는 노드
WO2011016683A2 (en) Method for managing network and for providing service qos
WO2024090901A1 (ko) 가상 노드를 이용한 노드 관리 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14869231

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15103524

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 26/09/2016)

122 Ep: pct application non-entry in european phase

Ref document number: 14869231

Country of ref document: EP

Kind code of ref document: A1