WO2018103460A1 - Sdn架构下多业务的并行恢复方法、装置及系统 - Google Patents

Sdn架构下多业务的并行恢复方法、装置及系统 Download PDF

Info

Publication number
WO2018103460A1
WO2018103460A1 PCT/CN2017/107019 CN2017107019W WO2018103460A1 WO 2018103460 A1 WO2018103460 A1 WO 2018103460A1 CN 2017107019 W CN2017107019 W CN 2017107019W WO 2018103460 A1 WO2018103460 A1 WO 2018103460A1
Authority
WO
WIPO (PCT)
Prior art keywords
otn
configuration
information
node
board
Prior art date
Application number
PCT/CN2017/107019
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
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to EP17877993.0A priority Critical patent/EP3554007A4/en
Publication of WO2018103460A1 publication Critical patent/WO2018103460A1/zh

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
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • 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
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/03—Arrangements for fault recovery
    • 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
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H04L41/0661—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities by reconfiguring faulty entities
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/22—Alternate routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/38—Flow based routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer

Definitions

  • the present invention relates to the field of the Internet, and in particular to a method, device and system for parallel recovery of multiple services in an SDN architecture.
  • Recovery refers to replacing a faulty connection by using idle resources in the network, rerouting and establishing a new connection. It is characterized by not having to occupy too many extra resources, as long as there are enough remaining resources in the network. Resist multiple failures. However, since the recovery action is a dynamic process of sensing faults in real time and dealing with faults, the service is damaged for a long time, which makes the fault handling less efficient. Based on these characteristics of recovery, major network operators and equipment manufacturers at home and abroad are very concerned about the recovery performance of services.
  • the embodiment of the invention provides a parallel recovery method, device and system for multiple services in an SDN architecture, so as to at least solve the technical problem that the processing efficiency of the routing fault in the SDN network is low in the related art.
  • a method for parallel recovery of multiple services in an SDN architecture includes: receiving one or more fault alarm information reported by an OTN network device that belongs to an OTN node; The fault alarm information is generated for the OTN node.
  • the configuration message is used to reconfigure all faulty services on the OTN node; send a configuration message to the corresponding OTN node.
  • the method further includes: sending the preset information to the OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; and the receiving OTN node sends the configuration information for indicating Feedback information of the results.
  • generating a corresponding configuration message for the OTN node based on the received fault alarm information includes: determining a recovery path of the fault service according to the fault alarm information; determining SNC cross information corresponding to the recovery path; generating, including all operations for operating the OTN node Configuration message for SNC cross information.
  • determining the recovery path of the fault service according to the fault alarm information includes: acquiring fault location information of the fault service from the fault alarm information; and generating a recovery path of the fault service according to the fault location information.
  • determining the SNC cross information corresponding to the recovery path includes: acquiring path information of the recovery path; and converting path information of the recovery path into SNC cross information.
  • the configuration message includes a flow_mod message, where the flow_mod message is used to carry at least one SNC cross information.
  • the parallel recovery method described above is applied to an SDN controller.
  • a method for parallel recovery of multiple services in an SDN architecture comprising: sending one or more fault alarm information reported by an OTN network device to an SDN controller; receiving SDN control The configuration message sent by the device, where the configuration message is used to reconfigure the faulty service; and the OTN board for performing the faulty service is reconfigured according to the configuration message.
  • reconfiguring the OTN board for performing the fault service according to the indication of the configuration message includes: generating one or more configuration commands for configuring the OTN board based on the configuration message; and configured to configure the same OTN board
  • the configuration command is carried in the configuration request and sent to the corresponding OTN board.
  • the method further includes: when receiving the preset information sent by the SDN controller, collecting the received information according to the indication of the preset information.
  • the configuration result of the configured OTN board is carried in the feedback information and is fed back to the SDN controller.
  • the feedback information includes the identification information of the OTN board that fails to be configured.
  • the configuration result of collecting the configured OTN board according to the indication of the preset information includes: receiving information sent by the OTN board to indicate that the configuration fails; and receiving, by the OTN board, information indicating that the configuration is successful; If the configuration result of the OTN board is not received within the preset time, the configuration timeout is used as the configuration result of the OTN board.
  • generating one or more configuration commands for configuring the OTN board based on the configuration message includes: acquiring one or more SNC cross information in the configuration message; converting one or more SNC cross information into one or more Configuration commands.
  • the configuration command for configuring the same OTN board is carried in the configuration request, and the sending to the corresponding OTN board includes: generating a TLV data packet corresponding to the configuration command by using a TLV format; The TLV data packet of the OTN board is carried in the configuration request and sent to the corresponding OTN board.
  • the configuration message includes a flow_mod message, where the flow_mod message is used to carry at least one SNC cross information.
  • the parallel recovery method described above is applied to an OTN node.
  • a multi-service parallel recovery apparatus in an SDN architecture includes: a first receiving unit, configured to receive one or more pieces reported by an OTN network device belonging to an OTN node.
  • the fault alarm information is generated, and is configured to generate, according to the received fault alarm information, a corresponding configuration message for the OTN node, where the configuration message is used to reconfigure all faulty services on the OTN node; and the first sending unit is configured to send the configuration.
  • the message is sent to the corresponding OTN node.
  • the first sending unit is further configured to send the preset information to the OTN node, where the preset information is used to indicate the OTN node feedback configuration.
  • the device further includes: a second receiving unit configured to receive feedback information sent by the OTN node to indicate a configuration result.
  • the generating unit includes: a first determining module, configured to determine a recovery path of the fault service according to the fault alarm information; and a second determining module configured to determine SNC cross information corresponding to the recovery path; the first generating module is configured to A configuration message is generated that includes all SNC cross-over information for operating the OTN node.
  • the first determining module includes: a first acquiring submodule configured to obtain fault location information of the fault service from the fault alarm information; and generating a submodule configured to generate a fault path of the fault service according to the fault location information.
  • the second determining module includes: a second acquiring submodule configured to obtain path information of the recovery path; and a transformation submodule configured to convert path information of the restoration path into SNC cross information.
  • the second sending unit is configured to send one or more fault alarm information reported by the OTN network device to the SDN controller
  • the third receiving unit is configured to receive the configuration message delivered by the SDN controller, where The configuration message is used to reconfigure the faulty service; the configuration unit is configured to reconfigure the OTN board for performing the faulty service according to the indication of the configuration message.
  • the configuration unit includes: a second generation module, configured to generate one or more configuration commands for configuring the OTN board based on the configuration message; and the sending module is configured to configure a configuration command for configuring the same OTN board It is carried in the configuration request and sent to the corresponding OTN board.
  • a parallel service for multi-service SDN architecture comprising: a collecting unit, configured to reconfigure an OTN board for performing faulty service according to an indication of a configuration message
  • the configuration result of the configured OTN board is collected according to the indication of the preset information;
  • the feedback unit is configured to carry the collected configuration result in the feedback information.
  • the feedback information is sent to the SDN controller, where the feedback information includes the identifier information of the OTN board that fails to be configured.
  • the collecting unit includes: a first receiving module, configured to receive information sent by the OTN board for indicating that the configuration fails; and a second receiving module configured to receive the OTN board for sending The information indicating that the configuration is successful; the processing module is set to the configuration result of the OTN board if the configuration result of the OTN board is not received within the preset time.
  • the second generation module includes: a third acquisition submodule configured to acquire one or more SNC cross information in the configuration message; and a conversion submodule configured to convert one or more SNC cross information into one or more Configuration commands.
  • a multi-service parallel recovery system in an SDN architecture including an SDN controller and an OTN node, where the SDN controller is configured to receive an OTN network device that is attributed to the OTN node.
  • the SDN controller is configured to receive an OTN network device that is attributed to the OTN node.
  • One or more fault alarm information and generate a corresponding configuration message for the OTN node based on the received fault alarm information, where the configuration message is used to reconfigure all faulty services on the OTN node; the OTN node is set to receive the SDN controller to send Configuration message.
  • the SDN controller is further configured to send the preset information to the OTN node after sending the configuration message to the corresponding OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; Feedback information indicating the configuration result.
  • an SDN device comprising: an SDN controller; a first memory configured to store SDN controller executable instructions; and configured to perform information transceiving communication according to control of the SDN controller a first transmission device, wherein the SDN controller is configured to: receive one or more fault alarm information reported by the OTN network device attributed to the OTN node; generate a corresponding configuration message for the OTN node based on the received fault alarm information The configuration message is used to reconfigure all faulty services on the OTN node; sending a configuration message to the corresponding OTN node.
  • the SDN controller is further configured to: after sending the configuration message to the corresponding OTN node, send the preset information to the OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; and the OTN node is received.
  • the feedback information sent to indicate the configuration result is further configured to: after sending the configuration message to the corresponding OTN node, send the preset information to the OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; and the OTN node is received.
  • the feedback information sent to indicate the configuration result is further configured to: after sending the configuration message to the corresponding OTN node, send the preset information to the OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; and the OTN node is received.
  • an OTN device comprising: an OTN controller; a second memory configured to store an OTN controller executable instruction; and configured to perform information transceiving communication according to control of the OTN controller a second transmission device; wherein the OTN controller is set To perform the following operations: sending one or more fault alarm information reported by the OTN network device to the SDN controller; receiving a configuration message delivered by the SDN controller, where the configuration message is used to reconfigure the faulty service; Configure an OTN board for performing faulty services.
  • the OTN controller is further configured to: generate one or more configuration commands for configuring the OTN board based on the configuration message; and carry configuration commands for configuring the same OTN board in the configuration request, Send to the corresponding OTN board.
  • a storage medium which may be configured to store program code for performing the following steps: receiving one or more fault alarm information reported by an OTN network device attributed to an OTN node Generating a corresponding configuration message for the OTN node based on the received fault alarm information, wherein the configuration message is used to reconfigure all faulty services on the OTN node; sending a configuration message to the corresponding OTN node, and the OTN node passes the configuration message correspondingly Configure the same OTN board with the same OTN board configuration command.
  • one or more fault alarm information reported by the OTN network device that is attributed to the OTN node is received; and the corresponding configuration message is generated for the OTN node based on the received fault alarm information, where the configuration message is used for reconfiguration.
  • the technical problem of low efficiency achieves the technical effect of improving the processing efficiency of routing faults in the SDN network.
  • FIG. 1 is a schematic diagram of an alternative computer terminal in accordance with an embodiment of the present invention.
  • FIG. 2 is a flow chart of an optional service recovery in accordance with an embodiment of the present invention.
  • FIG. 3 is a flow chart of an optional service recovery in accordance with an embodiment of the present invention.
  • FIG. 4 is a flowchart of a parallel recovery method for multiple services in an SDN architecture according to an embodiment of the present invention
  • FIG. 5 is a flowchart of another method for parallel recovery of multiple services in an SDN architecture according to an embodiment of the present invention.
  • FIG. 6 is a flowchart of a parallel recovery method for multiple services in an optional SDN architecture according to an embodiment of the present invention
  • FIG. 7 is a schematic diagram of an alternative OXM data structure in accordance with an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of an optional flow_mod message according to an embodiment of the present invention.
  • FIG. 9 is a schematic diagram of an optional packet_in message according to an embodiment of the present invention.
  • FIG. 10 is a schematic diagram of an alternative network topology in accordance with an embodiment of the present invention.
  • FIG. 11 is a flowchart of a parallel recovery method for multiple services in an optional SDN architecture according to an embodiment of the present invention
  • FIG. 12 is a flowchart of a parallel recovery method for multiple services in an optional SDN architecture according to an embodiment of the present invention
  • FIG. 13 is a flowchart of a parallel recovery method for multiple services in an optional SDN architecture according to an embodiment of the present invention
  • 15 is a schematic diagram of a parallel recovery device for multiple services in an SDN architecture according to an embodiment of the present invention.
  • FIG. 16 is a schematic diagram of another multi-service parallel recovery apparatus in an SDN architecture according to an embodiment of the present invention.
  • SDN Software Defined Network, software defined network.
  • PTN Packet Transport Network, packet transport network.
  • OTN Optical Transport Network, optical transport network.
  • SNC Sub Network Connect, subnet connection.
  • OIF Optical Internetworking Forum, Light Internet Forum.
  • ONF Open Networking Foundation, Open Network Foundation.
  • OTWG Optical Transport Working Group, Optical Transport Working Group.
  • OFP OpenFlow Protocol, OpenFlow protocol.
  • OXM OpenFlow Extensible Match, OpenFlow matches extended objects.
  • ODU Oracle Database Unloader, a set of fiber distribution units.
  • the method embodiment provided in Embodiment 1 of the present application can be executed in a mobile terminal, a computer terminal or the like.
  • the computer terminal may include one or more (only one shown) processor 101 (the processor 101 may include, but is not limited to, a microprocessor MCU or programmable A processing device such as a logic device FPGA, a memory 103 provided to store data, and a transmission device 105 provided as a communication function.
  • processor 101 may include, but is not limited to, a microprocessor MCU or programmable A processing device such as a logic device FPGA, a memory 103 provided to store data, and a transmission device 105 provided as a communication function.
  • FIG. 1 is merely illustrative and does not limit the structure of the above electronic device.
  • the above terminals may be SDN devices and OTN devices.
  • the memory 103 can be configured as a software program and a module for storing application software, such as program instructions/modules corresponding to the control method of the device in the embodiment of the present invention, and the processor 101 executes by executing a software program and a module stored in the memory 103.
  • application software such as program instructions/modules corresponding to the control method of the device in the embodiment of the present invention
  • the processor 101 executes by executing a software program and a module stored in the memory 103.
  • the memory can include high speed random access memory and can also include non-volatile memory such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memory.
  • the memory can further include memory remotely located relative to the processor, which can be connected to the computer terminal over a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
  • the above processor may be an SDN controller of an SDN device and an OTN controller of an OTN device.
  • the above memory may be a first memory of the SDN device and a second memory of the OTN device.
  • the transmission device is arranged to receive or transmit data via a network.
  • the above-described network specific examples may include a wireless network provided by a communication provider of a computer terminal.
  • the transmission device includes a Network Interface Controller (NIC) that can be connected to other network devices through the base station to communicate with the Internet.
  • the transmission device may be a Radio Frequency (RF) module configured to communicate with the Internet wirelessly.
  • NIC Network Interface Controller
  • RF Radio Frequency
  • the above transmission device may be a first transmission device of the SDN device and a second transmission device of the OTN device.
  • OpenFlow is a new type of network protocol, which is the standard protocol between controllers and switches
  • OpenFlow is a south-way protocol between controllers and network devices that is widely recognized by the industry under the SDN architecture.
  • the OTWG organization of ONF It has also been an OTN extension to OFP.
  • a flow_mod message can be configured to configure a one-way SNC crossover of a single OTN service, and the interaction between the controller, the OTN network device proxy, and the board (board 1 to board n) is as shown in FIG. :
  • Step S201 reporting a network fault
  • Step S202 the path calculation of the service 1
  • Step S203 carrying the cross information of the SNC intersection 1 of the service 1 by using the FLOW_MOD message
  • Step S204 sending a cross configuration command of SNC1 to the board 1;
  • Step S205 the card 1 processes the cross configuration command
  • Step S206 sending a cross configuration command of SNC1 to the board n;
  • Step S207 the card n processes the cross configuration command
  • Step S208 sending a mapping configuration command of SNC1 to the board n;
  • Step S209 the card n processes the mapping configuration command
  • Step S210 carrying the cross information of the SNC cross 2 of the service 1 through the FLOW_MOD message
  • Step S211 sending a cross configuration command of SNC2 to the board 1;
  • Step S212 the card 1 processes the cross configuration command
  • Step S213, sending a cross configuration command of SNC2 to the board n;
  • Step S214 the card n processes the cross configuration command
  • Step S215 sending a mapping configuration command of SNC2 to the board n;
  • Step S216 the card n processes the mapping configuration command
  • Step S217 sending a BARRIER_REQUEST message of service 1 to request to return a processing result
  • Step S219 sending a BARRIER_REQUEST of the service n;
  • Step S220 sending a SNC1 cross response of the service 1;
  • Step S222 sending a SNC1 cross response of the service 1;
  • Step S224 sending a SNC2 cross response of the service 1;
  • Step S225 sending a SNC2 mapping response of the service 1;
  • Step S227 transmitting a SNC1 cross response of the service n;
  • Step S229 sending a SNC1 cross response of the service n;
  • Step S230 transmitting an SNC1 mapping response of the service n;
  • Step S231 sending a SNC2 cross response of the service n;
  • Step S232 transmitting a SNC2 mapping response of the service n;
  • Step S233 the BARRIER_REPLY message of the service n is sent.
  • the OTN network multi-service recovery is not performed by using the bundle mechanism.
  • the OTN network device based on the time slot and the wavelength switching is complicated in configuration.
  • a single crossover and mapping configuration is frequently performed, which is inefficient and time consuming.
  • each cross-over and mapping configuration can be combined and delivered to the board for configuration at one time, which can improve the processing efficiency of the board and reduce the time and cost.
  • the bundle mechanism can be used to package multiple SNCs of multiple services.
  • the schematic diagram of the recovery process is shown in Figure 3:
  • Step S301 the network fault is reported
  • Step S302 the path calculation of the service 1
  • Step S303 the path calculation of the service n
  • Step S304 sending a bundle_open message to start a bundle mechanism
  • Step S305 sending an open_reply message in response to the bundle mechanism being enabled
  • Step S306 the bundle_add_1 message is carried by the flow_mod message, and the information about the cross-configuration of the board 1 is packaged into the bundle_add_1 for sending;
  • Step S307 the bundle_add_n message is carried by the flow_mod message, and the information about the cross-configuration of the board n is packaged into the bundle_add_n for transmission;
  • Step S308 sending a bundle_close message to close the bundle mechanism
  • Step S309 sending a close_reply message, and sending a response message that the shutdown is successful;
  • Step S310 sending a bundle_commit message, the message is used to trigger the configuration function of the board, and the configuration result is required to be returned;
  • Step S311 sending a plurality of cross commands of configuring service 1 to service n;
  • Step S312 the card 1 processes the cross configuration command
  • Step S316 the card n processes a plurality of cross commands
  • Step S317 sending a cross response
  • Step S319 sending a cross response
  • Step S320 commit_reply, returns the configuration result to the controller.
  • a method embodiment of a parallel recovery method for multiple services in an SDN architecture is provided.
  • the steps shown in the flowchart of the accompanying drawings may be executable in a group of computers, for example.
  • the instructions are executed in a computer system, and although the logical order is shown in the flowcharts, in some cases the steps shown or described may be performed in a different order than the ones described herein.
  • FIG. 4 is a flowchart of a method for parallel recovery of multiple services in an SDN architecture according to an embodiment of the present invention. As shown in FIG. 4, the method includes the following steps:
  • Step S401 Receive one or more fault alarm information reported by the OTN network device that belongs to the OTN node.
  • Step S402 Generate a corresponding configuration message for the OTN node based on the received fault alarm information, where the configuration message is used to reconfigure all faulty services on the OTN node.
  • Step S403 sending a configuration message to the corresponding OTN node.
  • the same OTN board can be configured by the OTN node by using a configuration command corresponding to the same OTN board in the configuration message.
  • the one or more fault alarm information reported by the OTN network device that is attributed to the OTN node is received; and the corresponding configuration message is generated for the OTN node based on the received fault alarm information, where the configuration message is used to reconfigure the OTN node. All the faulty services are sent; the configuration message is sent to the corresponding OTN node, and all the configuration related information of a certain node is sent through a message packet, thereby solving the related technology, and the processing efficiency of the routing fault in the SDN network is better.
  • the low technical problem achieves the technical effect of improving the processing efficiency of routing faults in the SDN network.
  • the foregoing configuration message includes a flow_mod message
  • the execution body of the foregoing method may be a controller in the OTN network, but is not limited thereto.
  • step S402 generating a corresponding configuration message for the OTN node based on the received fault alarm information includes: determining a recovery path of the fault service according to the fault alarm information; determining SNC cross information corresponding to the recovery path; generating all the operations for operating the OTN Configuration message for the node's SNC crossover information.
  • determining the recovery path of the fault service according to the fault alarm information refers to acquiring fault location information of the fault service from the fault alarm information; and generating a fault recovery path of the fault service according to the fault location information.
  • Determining the SNC cross information corresponding to the recovery path refers to acquiring the path information of the recovery path; converting the path information of the recovery path into the SNC cross information.
  • the result of the configuration may be obtained by: sending preset information to the OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; and the receiving OTN node sends the Feedback information used to represent the configuration results.
  • an embodiment of a method for parallel recovery of multiple services in an SDN architecture includes the following steps:
  • Step S501 Send one or more fault alarm information reported by the OTN network device to the SDN controller.
  • Step S502 Receive a configuration message sent by the SDN controller, where the configuration message is used to reconfigure the faulty service.
  • step S503 the OTN board for performing faulty service is reconfigured according to the indication of the configuration message.
  • one or more fault alarm information reported by the OTN network device is sent to the SDN controller; the configuration message sent by the SDN controller is received, and the configuration message is used to reconfigure the fault service; and the configuration message is reconfigured according to the indication of the configuration message.
  • a node obtains all the configuration related information by receiving a message packet, thereby solving the technical problem that the processing efficiency of the routing fault in the SDN network is low in the related technology, and the implementation is realized. The technical effect of improving the processing efficiency of routing faults in an SDN network.
  • each flow_mod message carries multiple pieces of SNC cross information.
  • the execution body of the foregoing method may be an OTN node in an OTN network, and the OTN node refers to an OTN network device node (its OTN node) It is equivalent to the proxy node of the OTN network device, but is not limited to this.
  • reconfiguring the OTN board for performing the fault service according to the indication of the configuration message includes: generating one or more configuration commands for configuring the OTN board based on the configuration message; and configuring the same OTN
  • the configuration commands of the board are carried in the configuration request and sent to the corresponding OTN board.
  • generating one or more configuration commands for configuring the OTN board based on the configuration message may be implemented by: acquiring one or more SNC cross information in the configuration message; converting one or more SNC cross information into One or more configuration commands.
  • the configuration command for configuring the same OTN board is carried in the configuration request, and is sent to the corresponding OTN board.
  • the TLV data packet corresponding to the configuration command is generated in the TLV format; the TLV data packet used to configure the same OTN board is carried in the configuration request and sent to the corresponding OTN board.
  • the OTN board for performing the faulty service is reconfigured according to the indication of the configuration message
  • the preset information sent by the SDN controller is received
  • the configured OTN board is collected according to the indication of the preset information.
  • the configuration result is carried in the feedback information and is fed back to the SDN controller, where the feedback information includes the identification information of the OTN board that fails to be configured.
  • the configuration result of collecting the configured OTN board according to the indication of the preset information includes: receiving information sent by the OTN board to indicate that the configuration fails; and receiving, by the OTN board, information indicating that the configuration is successful; If the configuration result of the OTN board is not received within the preset time, the configuration timeout is used as the configuration result of the OTN board.
  • a method for multi-service parallel recovery based on the OpenFlow protocol extension which can cross-connect multiple SNCs of multiple services of the same OTN network device node into one flow_mod message.
  • the OTN network device node then delivers multiple configuration commands of the same board in a configuration request according to the SNC cross-operation board. This not only simplifies the signaling message interaction between the controller and the network device, but also improves the configuration processing efficiency of the OTN board, thereby improving the performance of the multi-service parallel recovery of the OTN network under the SDN architecture and shortening the service damage time. If the OTN network device fails to perform the SNC crossover, the packet_in message can be used to report which SNC cross-execution failed.
  • Step S601 A fiber break occurs in the OTN network, and the controller detects the specific location of the network fault by using the transmission plane fault alarm information (that is, the fault alarm information) reported by the OTN network device. According to the fault location, the recovery path calculation is performed on the service that is damaged due to the fault.
  • the transmission plane fault alarm information that is, the fault alarm information
  • Step S602 after all the damaged service recovery paths are calculated, analyze the recovery path of all services, and convert the routing information into SNC cross information, specifically analyze and calculate a successful recovery path, and convert each recovery path information into multiple SNCs. Cross information.
  • Step S603 according to the OTN network device node operated by the SNC crossover, the operation is the same
  • a plurality of SNCs of the device-side node are sent to the corresponding device-side node (that is, the OTN node) through a flow_mod message, and then a barrier_request message is sent to the corresponding device-side node to confirm the execution result, and each operation is performed.
  • the device side node starts a signaling timeout timer for confirming whether the barrier_reply response message times out.
  • the signaling timeout period is configurable.
  • the default value is the minimum multipart_reply timeout period specified by the OFP standard, that is, 1 second.
  • Step S604 The OTN network device side node receives and parses the flow_mod message sent by the SDN controller, and converts the multiple SNC cross information into multiple configuration commands for operating the OTN board.
  • Step S605 classifying the configuration commands according to the respective boards operated by the configuration command. Multiple similar configuration commands that need to operate the same board are placed in a configuration request, and then sent to the corresponding board, and the cross-timeout timer is started for each operating board.
  • the cross-timeout period can be configured. According to the OTN network device dynamic performance indicator, the default value of the cross-timeout is set to 500 milliseconds.
  • each device side node After receiving the barrier_request message sent by the controller, each device side node waits for each board to return the execution result, and then responds to the controller barrier_reply message. For details, see the following steps:
  • Step S606 collecting the board configuration response, and determining whether the board performs the timeout, that is, collecting the execution result of each board configuration command, and determining whether the cross timeout timer expires. If yes, the configuration failure processing is performed, and step S608 is performed. If no, step S607 is performed.
  • step S607 it is determined whether the respective configuration commands of all the boards that need to perform the operation have returned the execution result. If yes, step S608 is performed, and if no, step S606 is repeatedly performed.
  • Step S608 collating the SNC cross-execution result of the configuration command of each board, and if the execution is successful, responding to the barrier_reply success message to the controller, and if the board command fails to execute, responding to the controller with a barrier_reply failure message and passing the packet_in
  • the message reports the SNC ID information (identification information of the SNC board) that failed to be executed.
  • Step S609 the controller collects the SNC cross execution result of each device side node, and determines Whether the signaling timeout timer expires. If it times out, the device side node is processed by cross failure.
  • step S610 it is determined whether all device side nodes have returned the SNC cross execution result, and if so, step S611 is performed. If no, step S610 is repeated.
  • step S611 the controller determines whether each service is successfully restored according to the cross-configuration result of each device-side node (ie, the response message). If each node responds to the barrier_reply success message, each service is restored successfully. If the device-side node responds to the barrier_reply failure message, the SNC ID information reported by the packet_in message is used to determine the recovery result of each service, and the process ends.
  • the extension of the latest version of the OpenFlow protocol is performed, and the multiple SNC cross-configuration information is encapsulated in a flow_mod message and sent to the device-side node, which improves the interaction and processing efficiency of the southbound signaling.
  • the specific extensions are as follows:
  • OFXXMT_EXP_OTN_SNCID is added in ofp_experimenters_field to indicate the extension type of OXM (the mapping between data entity objects and XML nodes is called OXM). And define the OXM data structure of OFP_OXM_EXP_OTN_SNCID as shown in Figure 7.
  • the above-mentioned field "ofp_experimenters_field” is a field for indicating the content of a specific extension type specified in "onf2015.569_04" in the OpenFlow protocol optical layer protocol extension. This application is extended on the basis of the "onf2015.569_04" protocol standard, and is added.
  • the content of OTN_SNCID is a field for indicating the content of a specific extension type specified in "onf2015.569_04" in the OpenFlow protocol optical layer protocol extension. This application is extended on the basis of the "onf2015.569_04" protocol standard, and is added.
  • the content of OTN_SNCID The content of OTN_SNCID.
  • the field "OFPXMT_EXP_OTN_SNCID" is a new content defined by the extended Openflow protocol in order to enable a flow_mod message to carry multiple SNC information, and is used to indicate the ID value of the SNC intersection. Only the content corresponding to this field can be used to accurately identify and distinguish the SNC cross information. When the multiple SNCs are carried in a flow_mod message, the purpose of accurately positioning and operating each SNC crossover can be achieved.
  • the SNC is defined in the ITU-T G.8080 standard, and the Chinese name is a subnet connection.
  • the definition content is: the subnet connection indicates the dynamic relationship between the two subnet points on the boundary of the same subnet. In fact, it is to specify the inbound and inbound labels of a stream, as well as the outbound and outgoing labels. With these inbound and outbound information, you can configure a data stream.
  • Existing flow_mod A message can only carry one SNC cross-information and cannot carry more than one, because the ingress and egress ports and tags are stored separately.
  • the application extends the protocol and newly defines the content of the SNC ID, so that a connection can be established between the separately stored ingress and egress ports and the tags, thereby ensuring that the broken in and out ports and tags can be formed in an orderly and accurate manner.
  • SNC cross information
  • the ofp_oxm_class of oxm_header is filled in as OFXXMC_EXPERIMENTER
  • ofp-oxm_field is filled in as the OFPXMT_EXP_OTN_SNCID added to the extension of this application.
  • the experimenter fills in the OFP_OTWG_EXPERIMENTER_ID to indicate the extended OXM structure.
  • the value of sncid is the unique number of the node on the device side. Use sncid to number different SNC crosses.
  • the signal type, ingress port, and ingress label in the SNC crossover need to be placed in the match field of the flow_mod message, and the egress port and outbound label in the SNC crossover need to be placed in the instructions field of the flow_mod message. Therefore, you need to parse the match field and the instructions field of the flow_mod message separately to get a complete SNC crossover information.
  • the flow_mod message is filled in by using the OTN_SNCID in the match field to number the signal type, the ingress port, and the inbound label information of multiple SNCs, and fill them into multiple OXMs in sequence.
  • the instructions field also distinguishes the outgoing port and the outgoing label information of multiple SNC intersections by OTN_SNCID, and fills in multiple actions in order.
  • the value of sncid in the match field is consistent with the value of sncid in the instructions field.
  • the extended flow_mod message example is shown in Figure 8. The message meaning in Figure 8 is described in the description related to Figure 7. The relevant definition of the flow_mod message).
  • a plurality of similar configuration commands that are set on the same OTN board are placed in a configuration request and sent to the OTN board, which improves the processing efficiency of the board.
  • Configuration commands for OTN boards include: crossover, mapping, wavelength assignment, wavelength tuning, etc. Apply for the TLV format to put multiple configuration commands in the same request in one request and send them to the corresponding board.
  • the cross-configuration command is used as an example.
  • the configuration request carries the total length of multiple TLVs.
  • Each TLV carries a specific cross-command, including: operation type, source board, source tributary information, destination board, and destination branch. Information and other information.
  • the application when the OTN network device fails to execute the configuration command, the application adds a new process, and reports the failed SNC ID information by using the extended packet_in (a type of message defined in the OpenFlow protocol) message.
  • the controller locates the service that crosses the failed execution, and makes the multi-service parallel recovery process more complete.
  • the specific extension of the packet_in message is as follows:
  • OFPR_OTN_CONFIG_SNC_FAIL is added to the ofp_packet_in_reason, indicating that the reason for reporting is "SNC configuration failed.”
  • OFPR_OTN_CONFIG_SNC_FAIL is added to the ofp_packet_in_reason, indicating that the reason for reporting is "SNC configuration failed.”
  • the match field of the packet_in message fill in the extended OXM structure OFP_OXM_EXP_OTN_SNCID of the present application, wherein the ofp_oxm_class of the oxm_header is filled in as OFXXMC_EXPERIMENTER, and the ofp-oxm_field is filled in as the OFXXMT_EXP_OTN_SNCID added for the extension of the application, and the experimenter fills in the OFP_OTWG_EXPERIMENTER_ID to indicate the extended OXM structure.
  • the sncid fills in the sncid value
  • the initial network topology is shown in Figure 10.
  • the network is a pure ODU layer network.
  • the paths are all from point A (link 1) to point B.
  • step S1101 the controller senses that the link 1 is interrupted (ie, the transmission plane is faulty) through the alarm information reported by the device. According to the fault location, it is determined that 80 ODU0 services need to be restored at the same time. Perform path calculation on 80 services and get recovery paths for 80 services. It is point A (link 5) to point D (link 4) to point B.
  • step S1102 the recovery path of the 80 services is analyzed, and the routing information is converted into the SNC cross information, and the SNC is classified according to the operated device side node, specifically, the routing information of each service is converted into multiple SNC cross information, and then The multiple SNC intersection information of operation point A, point D, and point B are separately analyzed and integrated, and finally three sets of intersection data are generated: SNC cross data packet of node A, SNC cross data packet of node D, and SNC cross data of node B package.
  • Step S1103 According to the OFP extension method provided by the present application, three sets of SNC cross-data packets are respectively encapsulated into three flow_mod messages, and multiple SNCs of the same device-side node are operated to pass the extended OpenFlow message. It is sent to each device-side node, that is, it is sent to the three device-side nodes of A, D, and B respectively, and the barrier_request is sent to confirm the execution result, and the signaling timeout timer is started, that is, A, D, and B respectively. The device-side node sends a barrier_request message to confirm the execution result of the crossover and starts the signaling timeout timer. The timeout period is 1 second.
  • Step S1104 The device side parses the flow_mod, and converts the multiple SNC cross information into multiple board configuration commands. Specifically, the three device side nodes respectively receive the flow_mod message, and respectively parse the match field and the destruction field according to the extended OTN_SNCID. Incoming and outgoing port and label information, and form each SNC cross information.
  • Step S1105 Analyze each SNC cross information, convert each SNC cross information into one or more board configuration commands, and classify the configuration commands according to the operated board, and operate multiple similar configurations of the same board.
  • the command is placed in a configuration request, sent to the corresponding board, and the cross-timeout timer is started.
  • the timeout period is 500 milliseconds.
  • step S1106 the execution result of each configuration command of the board (ie, configuration response information) is collected, and all the operating boards respond to the execution success within 500 milliseconds.
  • the three device side nodes respond to the controller with a barrier_reply success message.
  • Step S1107 The SDN controller receives the barrier_reply success message of the three OTN network device node responses of A, D, and B respectively within 1 second, and responds to the controller with a barrier_reply success message.
  • step S1108 each device side node returns successfully, and 80 services are successfully restored in parallel, that is, 80 ODU0 services are successfully restored, and the process ends.
  • step S1201 the controller senses that the link 1 is interrupted (ie, the transmission plane is faulty) through the alarm information reported by the device. According to the fault location, it is determined that 80 ODU0 services need to be restored at the same time. The path calculation is performed on 80 services, and the recovery paths of 80 services are all from point A (link 5) to point D (link 4) to point B.
  • step S1202 the recovery path of the 80 services is analyzed, and the routing information is converted into the SNC cross information, and the SNC is classified according to the operated device side node, specifically, the routing information of each service is converted into multiple SNC cross information, and then The multiple SNC intersection information of operation point A, point D, and point B are separately analyzed and integrated, and finally three sets of intersection data are generated: SNC cross data packet of node A, SNC cross data packet of node D, and SNC cross data of node B package.
  • Step S1203 According to the OFP extension method provided by the present application, three sets of SNC cross-data packets are respectively encapsulated into three flow_mod messages, and multiple SNC cross-information information of the same device-side node is operated, and the extended OpenFlow message is used. It is sent to each device-side node, that is, it is sent to the three device-side nodes of A, D, and B respectively, and the barrier_request is sent to confirm the execution result, and the signaling timeout timer is started, that is, A, D, and B respectively. The device-side node sends a barrier_request message to confirm the execution result of the crossover and starts the signaling timeout timer. The timeout period is 1 second.
  • Step S1204 The device side parses the flow_mod, and converts the multiple SNC cross information into multiple board configuration commands. Specifically, the three device side nodes respectively receive the flow_mod message, and respectively parse the match field and the destruction field according to the extended OTN_SNCID. Incoming and outgoing port and label information, and form each SNC cross information.
  • Step S1205 analyzing each SNC cross information, converting each SNC cross information Configure a command for one or more boards, and categorize the configuration commands according to the operation of the board.
  • the configuration commands of the same board are placed in a configuration request and sent to the corresponding board.
  • the cross-timeout timer is started and the timeout period is 500 milliseconds.
  • step S1206 the execution result of each configuration command of the board (ie, the configuration response information) is collected, and all the operating boards respond to the execution result within 500 milliseconds, but the partial board cross-execution of the node D fails. Therefore, after the three device side nodes receive the barrier_request message, the node A and the node B respond to the controller with a barrier_reply success message, and the node D responds to the controller with a barrier_reply failure message, and according to the configuration command that fails to execute, the failed SNC is executed. The ID is reported to the controller through the packet_in message.
  • step S1207 part of the card response fails, responds to the barrier_reply failure message to the controller, and reports the failed SNC ID information through the packet_in, and the SDN controller receives the barrier_reply success message of the response of the node A and the node B within 1 second respectively.
  • the node_reply failure message of the node D response, and the SNC ID in the packet_in message reported by the node D is analyzed, and it is determined which of the 80 ODU0 services are successfully restored, which recovery fails, and the process ends.
  • step S1208 the node that fails to perform the cross-connection fails, and according to the SNC ID information reported by the packet_in, it is determined which of the 80 services are successfully restored and which are failed.
  • step S1301 the controller senses that the link 1 is interrupted (ie, the transmission plane is faulty) through the alarm information reported by the device. According to the fault location, it is determined that 80 ODU0 services need to be restored at the same time. The path calculation is performed on 80 services, and the recovery paths of 80 services are all from point A (link 5) to point D (link 4) to point B.
  • step S1302 the recovery path of the 80 services is analyzed, and the routing information is converted into the SNC cross information, and the SNC is classified according to the operated device side node, specifically, the routing of each service.
  • the information is transformed into multiple SNC intersection information, and then multiple SNC intersection information of operation point A, point D, and point B are separately analyzed and integrated, and finally three sets of intersection data are generated: node A's SNC cross data packet, node D's SNC cross-packet and SNC cross-packet for Node B.
  • Step S1303 According to the OFP extension method provided by the present application, three sets of SNC cross-data packets are respectively encapsulated into three flow_mod messages, and multiple SNC cross-informations of the same device-side node are operated, and the extended OpenFlow message is used. It is sent to each device-side node, that is, it is sent to the three device-side nodes of A, D, and B respectively, and the barrier_request is sent to confirm the execution result, and the signaling timeout timer is started, that is, A, D, and B respectively. The device-side node sends a barrier_request message to confirm the execution result of the crossover and starts the signaling timeout timer. The timeout period is 1 second.
  • step S1304 the response of each node is collected, and both node A and node B return success, but the node D responds with a timeout. Because the signaling between the controller and the node D fails, the flow_mod message sent by the controller cannot be received.
  • the barrier_request message, Node A and Node B receive the flow_mod message and the barrier_request message, and perform the crossover success, and respond to the controller barrier_reply success message.
  • step S1305 the node D signaling timeout, the cross setting fails, and it is determined that 80 services are all failed to recover.
  • the SDN controller only receives the barrier_reply success message of the node A and the node B within 1 second, but does not receive the response of the node D.
  • the barrier_reply message indicates that all SNC cross-connections of node D fail to execute, and 80 ODU0 services fail to recover in parallel, and the process ends.
  • step S1401 the controller senses that the link 1 is interrupted (ie, the transmission plane is faulty) through the alarm information reported by the device. According to the fault location, it is determined that 80 ODU0 services need to be restored at the same time. The path calculation is performed on 80 services, and the recovery paths of 80 services are all from point A (link 5) to point D (link 4) to point B.
  • step S1402 the recovery path of the 80 services is analyzed, and the routing information is converted into the SNC cross information, and the SNC is classified according to the operated device side node, specifically, the routing information of each service is converted into multiple SNC cross information, and then The multiple SNC intersection information of operation point A, point D, and point B are separately analyzed and integrated, and finally three sets of intersection data are generated: SNC cross data packet of node A, SNC cross data packet of node D, and SNC cross data of node B package.
  • Step S1403 According to the OFP extension method provided by the present application, three sets of SNC cross-data packets are respectively encapsulated into three flow_mod messages, and multiple SNC cross-information information of the same device-side node is operated, and the extended OpenFlow message is used. It is sent to each device-side node, that is, it is sent to the three device-side nodes of A, D, and B respectively, and the barrier_request is sent to confirm the execution result, and the signaling timeout timer is started, that is, A, D, and B respectively. The device-side node sends a barrier_request message to confirm the execution result of the crossover and starts the signaling timeout timer. The timeout period is 1 second.
  • Step S1404 The device side parses the flow_mod, and converts the multiple SNC cross information into multiple board configuration commands. Specifically, the three device side nodes respectively receive the flow_mod message, and respectively parse the match field and the destruction field according to the extended OTN_SNCID. Incoming and outgoing port and label information, and form each SNC cross information.
  • Step S1405 analyzing each SNC cross information, converting each SNC cross information into one or more board configuration commands, and classifying the configuration commands according to the operated board, and operating multiple similar configurations of the same board.
  • the command is placed in a configuration request, sent to the corresponding board, and the cross-timeout timer is started.
  • the timeout period is 500 milliseconds.
  • step S1406 the execution result of each configuration command of the board is collected, and some boards of the node D do not respond to the execution result within 500 milliseconds, and the boards of other operations respond to the successful execution result.
  • step S1407 part of the board responds with a timeout, and the configuration fails to be processed. If the board configuration command response times out, the configuration is considered to be unsuccessful.
  • step S1408 the controller responds to the barrier_reply failure message, and reports the failed SNC ID information through the packet_in, and the three device side nodes receive the barrier_request.
  • the node A and the node B respond to the controller with the barrier_reply success message
  • the node D responds to the controller with the barrier_reply failure message, and reports the failed SNC ID to the controller through the packet_in message according to the configuration command.
  • step S1409 the node that fails the cross-execution fails, and according to the SNC ID information reported by the packet_in, it is determined which of the 80 services are successfully restored, and which recovers, and the SDN controller receives the barrier_reply of the response of the node A and the node B within 1 second.
  • the success message, and the barrier_reply failure message of the node D response, and the SNC ID in the packet_in message reported by the node D determines which of the 80 ODU0 services are successfully restored, and which recovery fails, and the process ends.
  • the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation.
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.
  • a parallel recovery device for multiple services in an SDN architecture is also provided.
  • the apparatus is configured to implement the above-described embodiments and preferred embodiments, and the description thereof has been omitted.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 15 is a schematic diagram of a multi-service parallel recovery apparatus in an SDN architecture according to an embodiment of the present invention.
  • the apparatus may include: a first receiving unit 151, a generating unit 152, and a first transmitting unit 153.
  • the first receiving unit 151 is configured to receive one or more fault alarm information reported by the OTN network device that belongs to the OTN node;
  • the generating unit 152 is configured to generate a corresponding configuration message for the OTN node based on the received fault alarm information, where the configuration message is used to reconfigure all faulty services on the OTN node;
  • the first transmitting unit 153 is configured to send a configuration message to the corresponding OTN node.
  • the first receiving unit receives one or more pieces of fault alarm information reported by the OTN network device that is attributed to the OTN node, and the generating unit generates a corresponding configuration message for the OTN node based on the received fault alarm information, where the configuration message is configured.
  • the first sending unit sends a configuration message to the corresponding OTN node, and sends all configuration related information of a certain node through a message packet, thereby solving the related art.
  • the technical problem of low routing efficiency in the SDN network has the technical effect of improving the processing efficiency of the routing fault in the SDN network.
  • the generating unit includes: a first determining module, configured to determine a recovery path of the fault service according to the fault alarm information; and a second determining module configured to determine SNC cross information corresponding to the recovery path; the first generating module is configured to A configuration message is generated that includes all SNC cross-over information for operating the OTN node.
  • the first determining module includes: a first acquiring submodule configured to obtain fault location information of the fault service from the fault alarm information; and generating a submodule configured to generate the fault location information.
  • the second determining module includes: a second acquiring submodule configured to acquire path information of the restoration path; and a transformation submodule configured to convert path information of the restoration path into SNC cross information.
  • the result of the configuration may be obtained by: after transmitting the configuration message to the corresponding OTN node, the first sending unit is further configured to send the preset information to the OTN node, where the preset information is used to indicate the OTN.
  • the node feeds back the configuration result; the device further includes: a second receiving unit, configured to receive feedback information sent by the OTN node to indicate the configuration result.
  • FIG. 16 is another parallel operation device for multi-service in an SDN architecture according to an embodiment of the present invention.
  • the apparatus may include: a second transmitting unit 161, a third receiving unit 162, and a configuration unit 163.
  • the second sending unit 161 is configured to send one or more fault alarm information reported by the OTN network device to the SDN controller;
  • the third receiving unit 162 is configured to receive a configuration message delivered by the SDN controller, where the configuration message is used to reconfigure the faulty service.
  • the configuration unit 163 is configured to reconfigure the OTN board for performing faulty service according to the indication of the configuration message.
  • the second sending unit sends one or more fault alarm information reported by the OTN network device to the SDN controller; the third receiving unit receives the configuration message delivered by the SDN controller, where the configuration message is used to reconfigure the fault.
  • the configuration unit reconfigures the OTN board for performing faulty service according to the indication of the configuration message, and a node obtains all configuration related information by receiving a message packet, thereby solving the related art, the route in the SDN network.
  • the technical problem of low processing efficiency of the fault achieves the technical effect of improving the processing efficiency of the routing fault in the SDN network.
  • the foregoing configuration message includes a flow_mod message
  • the foregoing OTN node refers to an OTN network device node (which is equivalent to a proxy node of the OTN network device), but is not limited thereto.
  • the configuration unit includes: a second generation module configured to generate one or more configuration commands for configuring an OTN board based on the configuration message; and a sending module configured to carry configuration commands for configuring the same OTN board In the configuration request, it is sent to the corresponding OTN board.
  • the second generation module includes: a third acquisition submodule configured to acquire one or more SNC cross information in the configuration message; and a conversion submodule configured to convert one or more SNC cross information into one or more Configuration commands.
  • the foregoing apparatus may further include: a collecting unit, configured to be in accordance with the configuration message After the OTN board for performing the faulty service is reconfigured, the configuration result of the configured OTN board is collected according to the preset information when receiving the preset information sent by the SDN controller; the feedback unit is set to The collected configuration result is carried in the feedback information and is fed back to the SDN controller, where the feedback information includes the identifier information of the OTN board that fails to be configured.
  • a collecting unit configured to be in accordance with the configuration message After the OTN board for performing the faulty service is reconfigured, the configuration result of the configured OTN board is collected according to the preset information when receiving the preset information sent by the SDN controller; the feedback unit is set to The collected configuration result is carried in the feedback information and is fed back to the SDN controller, where the feedback information includes the identifier information of the OTN board that fails to be configured.
  • the collecting unit includes: a first receiving module, configured to receive information sent by the OTN board for indicating a configuration failure; and a second receiving module configured to receive information sent by the OTN board to indicate that the configuration is successful;
  • the processing module is set to the configuration result of the OTN board if the configuration result of the OTN board is not received within the preset time.
  • a multi-service parallel recovery mode based on the OpenFlow protocol extension is provided, and multiple SNCs that operate multiple services of the same OTN network device node are placed in a flow_mod message for delivery, and OTN is delivered.
  • the network device node then delivers multiple configuration commands of the same board in a configuration request according to the SNC cross-operation board. This not only simplifies the signaling message interaction between the controller and the network device, but also improves the configuration processing efficiency of the OTN board, thereby improving the performance of the multi-service parallel recovery of the OTN network under the SDN architecture and shortening the service damage time. If the OTN network device fails to perform the SNC crossover, the packet_in message can be used to report which SNC cross-execution failed.
  • Step S601 A fiber break occurs in the OTN network, and the controller detects the specific location of the network fault by using the transmission plane fault alarm information reported by the OTN network device. According to the fault location, the recovery path calculation is performed on the service that is damaged due to the fault.
  • Step S602 after all the damaged service recovery paths are calculated, analyze the recovery path of all services, and convert the routing information into SNC cross information, specifically analyze and calculate a successful recovery path, and convert each recovery path information into multiple SNCs. Cross information.
  • Step S603 according to the OTN network device node operated by the SNC, the multiple SNCs of the same device-side node are sent to the corresponding device-side node (ie, the OTN node) through a flow_mod message, and then the corresponding The device side node sends the
  • the barrier_request message is used to confirm the execution result, and a signaling timeout timer is started for the device side node of each operation to confirm whether the barrier_reply response message times out.
  • the signaling timeout period is configurable. The default value is the minimum multipart_reply timeout period specified by the OFP standard, that is, 1 second.
  • Step S604 The OTN network device side node receives and parses the flow_mod message sent by the SDN controller, and converts the multiple SNC cross information into multiple configuration commands for operating the OTN board.
  • Step S605 classifying the configuration commands according to the respective boards operated by the configuration command. Multiple similar configuration commands that need to operate the same board are placed in a configuration request, and then sent to the corresponding board, and the cross-timeout timer is started for each operating board.
  • the cross-timeout period can be configured. According to the OTN network device dynamic performance indicator, the default value of the cross-timeout is set to 500 milliseconds.
  • each device side node After receiving the barrier_request message sent by the controller, each device side node waits for each board to return the execution result, and then responds to the controller barrier_reply message. For details, see the following steps:
  • Step S606 collecting the board configuration response, and determining whether the board performs the timeout, that is, collecting the execution result of each board configuration command, and determining whether the cross timeout timer expires. If yes, the configuration failure processing is performed, and step S608 is performed. If no, step S607 is performed.
  • step S607 it is determined whether the execution command results of all the configuration commands of all the boards that need to perform the operation are returned. If yes, step S608 is performed, and if not, step S606 is repeatedly executed.
  • Step S608 collating the SNC cross-execution result of the configuration command of each board, and if the execution is successful, responding to the barrier_reply success message to the controller, and if the board command fails to execute, responding to the controller with a barrier_reply failure message and passing the packet_in
  • the message reports the SNC ID information (identification information of the SNC board) that failed to be executed.
  • step S609 the controller collects the SNC cross-execution result of each device-side node, and determines whether the signaling timeout timer expires. If the timeout occurs, the device-side node performs cross-failure processing.
  • Step S610 determining whether all device side nodes return the SNC cross execution result, such as If yes, step S611 is performed. If no, step S610 is repeated.
  • step S611 the controller determines whether each service is successfully restored according to the cross-configuration result of each device-side node (ie, the response message). If each node responds to the barrier_reply success message, each service is restored successfully. If the device-side node responds to the barrier_reply failure message, the SNC ID information reported by the packet_in message is used to determine the recovery result of each service, and the process ends.
  • OFXXMT_EXP_OTN_SNCID is added in ofp_experimenters_field to indicate the extension type of OXM (the mapping between data entity objects and XML nodes is called OXM). And define the OXM data structure of OFP_OXM_EXP_OTN_SNCID as shown in Figure 7.
  • the ofp_oxm_class of oxm_header is filled in as OFXXMC_EXPERIMENTER
  • ofp-oxm_field is filled in as the OFPXMT_EXP_OTN_SNCID added to the extension of this application.
  • the experimenter fills in the OFP_OTWG_EXPERIMENTER_ID to indicate the extended OXM structure.
  • the value of sncid is the unique number of the node on the device side. Use sncid to number different SNC crosses.
  • the signal type, ingress port, and ingress label in the SNC crossover need to be placed in the match field of the flow_mod message, and the egress port and outbound label in the SNC crossover need to be placed in the instructions field of the flow_mod message. Therefore, you need to parse the match field and the instructions field of the flow_mod message separately to get a complete SNC crossover information.
  • the flow_mod message is filled in by using the OTN_SNCID in the match field to number the signal type, the ingress port, and the inbound label information of multiple SNCs, and fill them in order.
  • the instruction field also distinguishes the outbound port and outbound tag information in multiple SNC intersections by OTN_SNCID, and fills in multiple actions in order.
  • the value of sncid in the match field is consistent with the value of sncid in the instructions field.
  • the extended flow_mod message example is shown in Figure 8. The message meaning in Figure 8 is described in the description related to Figure 7. The relevant definition of the flow_mod message).
  • a plurality of similar configuration commands that are set on the same OTN board are placed in a configuration request and sent to the OTN board, which improves the processing efficiency of the board.
  • the OTN board configuration commands include: crossover, mapping, wavelength assignment, and wavelength tuning.
  • the TLV format is used to place multiple configuration commands in a single request and sent to the corresponding board.
  • the cross-configuration command is used as an example.
  • the configuration request carries the total length of multiple TLVs.
  • Each TLV carries a specific cross-command, including: operation type, source board, source tributary information, destination board, and destination branch. Information and other information.
  • the application when the OTN network device fails to execute the configuration command, the application adds a new process, and reports the failed SNC ID information by using the extended packet_in (a type of message defined in the OpenFlow protocol) message.
  • the controller locates the service that crosses the failed execution, and makes the multi-service parallel recovery process more complete.
  • the specific extension of the packet_in message is as follows:
  • OFPR_OTN_CONFIG_SNC_FAIL is added to the ofp_packet_in_reason, indicating that the reason for reporting is "SNC configuration failed.”
  • OFPR_OTN_CONFIG_SNC_FAIL is added to the ofp_packet_in_reason, indicating that the reason for reporting is "SNC configuration failed.”
  • the match field of the packet_in message fill in the extended OXM structure OFP_OXM_EXP_OTN_SNCID of the present application, wherein the ofp_oxm_class of the oxm_header is filled in as OFXXMC_EXPERIMENTER, and the ofp-oxm_field is filled in as the OFXXMT_EXP_OTN_SNCID added for the extension of the application, and the experimenter fills in the OFP_OTWG_EXPERIMENTER_ID to indicate the extended OXM structure.
  • the sncid fills in the sncid value
  • each of the above modules may be implemented by software or hardware.
  • the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the above modules are in any combination.
  • the forms are located in different processors.
  • a multi-service parallel recovery system in an SDN architecture including an SDN controller and an OTN node, where the SDN controller is configured to receive an OTN network device that is attributed to the OTN node.
  • the SDN controller is configured to receive an OTN network device that is attributed to the OTN node.
  • One or more fault alarm information and generate a corresponding configuration message for the OTN node based on the received fault alarm information, where the configuration message is used to reconfigure all faulty services on the OTN node; the OTN node is set to receive the SDN controller to send Configuration message.
  • the SDN controller is further configured to send the preset information to the OTN node after sending the configuration message to the corresponding OTN node, where the preset information is used to indicate that the OTN node feeds back the configuration result; Feedback information indicating the configuration result.
  • Embodiments of the present invention also provide a storage medium.
  • the foregoing storage medium may be configured to store program code for performing the following steps:
  • the storage medium is further arranged to store program code for performing the following steps:
  • S22 Receive a configuration message sent by the SDN controller, where the configuration message is used to reconfigure the faulty service.
  • the foregoing storage medium may include, but not limited to, a USB flash drive, a Read-Only Memory (ROM), a Random Access Memory (RAM), a mobile hard disk, and a magnetic memory.
  • ROM Read-Only Memory
  • RAM Random Access Memory
  • a mobile hard disk e.g., a hard disk
  • magnetic memory e.g., a hard disk
  • the processor performs: receiving, according to the stored program code in the storage medium, one or more fault alarm information reported by the OTN network device that belongs to the OTN node; and based on the received fault alarm information, The OTN node generates a corresponding configuration message, where the configuration message is used to reconfigure all faulty services on the OTN node; and the configuration message is sent to the corresponding OTN node.
  • the processor is configured to: send one or more fault alarm information reported by the OTN network device to the SDN controller according to the stored program code in the storage medium; and receive the configuration message delivered by the SDN controller.
  • the configuration message is used to reconfigure the faulty service; the OTN board for performing the faulty service is reconfigured according to the configuration message.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the parallel recovery method, device, and system for multiple services in the SDN architecture provided by the embodiments of the present invention have the following beneficial effects: the technology for processing routing faults in the SDN network is low in the related art. The problem achieves the technical effect of improving the processing efficiency of routing faults in the SDN network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明实施例提供了一种SDN架构下多业务的并行恢复方法、装置及系统。其中，该方法包括：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。本发明实施例解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题。

Description

SDN架构下多业务的并行恢复方法、装置及系统 技术领域
本发明涉及互联网领域，具体而言，涉及一种SDN架构下多业务的并行恢复方法、装置及系统。
背景技术
随着SDN网络技术的迅猛发展，致力于制定OTN网络相关标准和架构的OIF、ONF等国际标准组织，也都将研究重点转移到了SDN上，因此，传统OTN网络向SDN架构演进已经成为大势所趋。随着网络扁平化的发展，OTN网络与PTN网络将逐步融合，越来越多的小粒度业务会接入到OTN网络中进行传输。但由于OTN网络传输带宽很高，因此，一根光缆中断将会导致几十条甚至上百条业务需要进行路由的重新恢复。
“恢复”是指通过使用网络中的空闲资源，重新选路并建立新的连接来替代出现故障的连接，其特点是无需占用过多额外的资源，只要网络中有足够的剩余资源，就能够抵抗多次故障。但由于恢复动作是一个实时感知故障并处理故障的动态过程，因此，业务受损的时间会比较长，从而使得故障处理的效率较低。基于恢复的这些特点，目前国内外各大网络运营商和设备制造商都非常关注业务的恢复性能。
针对相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种SDN架构下多业务的并行恢复方法、装置及系统，以至少解决相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题。
根据本发明实施例的一个方面，提供了一种SDN架构下多业务的并行恢复方法，该方法包括：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的 配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。
可选地，在发送配置消息至对应的OTN节点之后，方法还包括：发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
可选地，基于接收到的故障告警信息为OTN节点生成对应的配置消息包括：根据故障告警信息确定故障业务的恢复路径；确定对应于恢复路径的SNC交叉信息；生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
可选地，根据故障告警信息确定故障业务的恢复路径包括：从故障告警信息中获取故障业务的故障位置信息；根据故障位置信息生成故障业务的恢复路径。
可选地，确定对应于恢复路径的SNC交叉信息包括：获取恢复路径的路径信息；将恢复路径的路径信息转化为SNC交叉信息。
可选地，配置消息包括flow_mod消息，其中，flow_mod消息用于携带至少一个SNC交叉信息。
可选地，上述的并行恢复方法应用于SDN控制器。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复方法，该方法包括：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，按照配置消息的指示重新配置用于执行故障业务的OTN板卡包括：基于配置消息生成一个或多个用于配置OTN板卡的配置命令；将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
可选地，在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，该方法还包括：在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
可选地，按照预设信息的指示收集被配置的OTN板卡的配置结果包括：接收OTN板卡发送的用于表示配置失败的信息；接收OTN板卡发送的用于表示配置成功的信息；若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
可选地，基于配置消息生成一个或多个用于配置OTN板卡的配置命令包括：获取配置消息中的一个或多个SNC交叉信息；将一个或多个SNC交叉信息转换为一个或多个配置命令。
可选地，将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡包括：采用TLV格式生成对应于配置命令的TLV数据包；将用于配置同一个OTN板卡的TLV数据包携带于配置请求中，发送至对应的OTN板卡。
可选地，配置消息包括flow_mod消息，其中，flow_mod消息用于携带至少一个SNC交叉信息。
可选地，上述的并行恢复方法应用于OTN节点。
根据本发明实施例的另一个方面，提供了一种SDN架构下多业务的并行恢复装置，该装置包括：第一接收单元，设置为接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；生成单元，设置为基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；第一发送单元，设置为发送配置消息至对应的OTN节点。
可选地，第一发送单元在发送配置消息至对应的OTN节点之后，还设置为发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配 置结果；装置还包括：第二接收单元，设置为接收OTN节点发送的用于表示配置结果的反馈信息。
可选地，生成单元包括：第一确定模块，设置为根据故障告警信息确定故障业务的恢复路径；第二确定模块，设置为确定对应于恢复路径的SNC交叉信息；第一生成模块，设置为生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
可选地，第一确定模块包括：第一获取子模块，设置为从故障告警信息中获取故障业务的故障位置信息；生成子模块，设置为根据故障位置信息生成故障业务的恢复路径。
可选地，第二确定模块包括：第二获取子模块，设置为获取恢复路径的路径信息；转化子模块，设置为将恢复路径的路径信息转化为SNC交叉信息。
可选地，包括：第二发送单元，设置为发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；第三接收单元，设置为接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；配置单元，设置为按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，配置单元包括：第二生成模块，设置为基于配置消息生成一个或多个用于配置OTN板卡的配置命令；发送模块，设置为将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复装置，该装置包括：收集单元，设置为在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；反馈单元，设置为将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
可选地，收集单元包括：第一接收模块，设置为接收OTN板卡发送的用于表示配置失败的信息；第二接收模块，设置为接收OTN板卡发送的用 于表示配置成功的信息；处理模块，设置为若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
可选地，第二生成模块包括：第三获取子模块，设置为获取配置消息中的一个或多个SNC交叉信息；转换子模块，设置为将一个或多个SNC交叉信息转换为一个或多个配置命令。
根据本发明的另一个实施例，还提供了一种SDN架构下多业务的并行恢复系统，包括SDN控制器和OTN节点，其中，SDN控制器设置为接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息，并基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；OTN节点设置为接收SDN控制器发送的配置消息。
可选地，SDN控制器还设置为：在发送配置消息至对应的OTN节点之后，发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明的另一个实施例，还提供了一种SDN设备，包括：SDN控制器；设置为存储SDN控制器可执行指令的第一存储器；设置为根据SDN控制器的控制进行信息收发通信的第一传输装置；其中，SDN控制器设置为执行以下操作：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。
可选地，SDN控制器还设置为执行以下操作：在发送配置消息至对应的OTN节点之后，发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明的另一个实施例，还提供了一种OTN设备，包括：OTN控制器；设置为存储OTN控制器可执行指令的第二存储器；设置为根据OTN控制器的控制进行信息收发通信的第二传输装置；其中，OTN控制器设置 为执行以下操作：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，OTN控制器还设置为执行以下操作：基于配置消息生成一个或多个用于配置OTN板卡的配置命令；将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
根据本发明的另一个实施例，提供了一种存储介质，存储介质可以被设置为存储用于执行以下步骤的程序代码：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点，由OTN节点通过配置消息中对应于同一个OTN板卡的配置命令对同一个OTN板卡进行配置。
在本发明实施例中，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点，将某一节点的所有的配置相关信息通过一个消息包来发送，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的可选的计算机终端的示意图；
图2是根据本发明实施例的可选的业务恢复的流程图；
图3是根据本发明实施例的可选的业务恢复的流程图；
图4是根据本发明实施例的一种SDN架构下多业务的并行恢复方法的流程图；
图5是根据本发明实施例的另一种SDN架构下多业务的并行恢复方法的流程图；
图6是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图7是根据本发明实施例的可选的OXM数据结构的示意图；
图8是根据本发明实施例的可选的flow_mod消息的示意图；
图9是根据本发明实施例的可选的packet_in消息的示意图；
图10是根据本发明实施例的可选的网络拓扑结构的示意图；
图11是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图12是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图13是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图14是根据本发明实施例的可选的SDN架构下多业务的并行恢复方法的流程图；
图15是根据本发明实施例的一种SDN架构下多业务的并行恢复装置的示意图；
图16是根据本发明实施例的另一种SDN架构下多业务的并行恢复装置的示意图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是， 在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
首先，在对本发明实施例进行描述的过程中出现的部分名词或术语适用于如下解释：
SDN：Software Defined Network，软件定义网络。
PTN：Packet Transport Network，分组传送网。
OTN：Optical Transport Network，光传送网。
SNC：Sub Network Connect，子网连接。
OIF：Optical Internetworking Forum，光互联网论坛。
ONF：Open Networking Foundation，开放网络基金会。
OTWG：Optical Transport Working Group，光传送工作组。
OFP：OpenFlow Protocol，OpenFlow协议。
OXM：OpenFlow Extensible Match，OpenFlow匹配扩展对象。
ODU：Oracle Database Unloader，集光纤配线单元。
实施例1
本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，如图1所示，计算机终端可以包括一个或多个(图中仅示出一个)处理器101(处理器101可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、设置为存储数据的存储器103、以及设置为通信功能的传输装置105。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。
上述的终端可以为SDN设备和OTN设备。
存储器103可设置为存储应用软件的软件程序以及模块，如本发明实施例中的设备的控制方法对应的程序指令/模块，处理器101通过运行存储在存储器103内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的处理器可以为SDN设备的SDN控制器和OTN设备的OTN控制器。
上述的存储器可以为SDN设备的第一存储器和OTN设备的第二存储器。
传输装置设置为经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端的通信供应商提供的无线网络。在一个实例中，传输装置包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置可以为射频(Radio Frequency，简称为RF)模块，其设置为通过无线方式与互联网进行通讯。
上述的传输装置可以为SDN设备的第一传输装置和OTN设备的第二传输装置。
OpenFlow协议(OpenFlow是一种新型的网络协议，它是控制器和交换机之间的标准协议)是目前SDN架构下业界普遍认可的控制器与网络设备之间的南向协议，ONF旗下的OTWG组织也一直在对OFP进行了OTN扩展。但根据目前最新的扩展版本，一条flow_mod消息可配置单条OTN业务的单向SNC交叉,控制器、OTN网络设备代理、板卡(板卡1至板卡n)之间的交互如图2所示：
步骤S201，网络故障上报；
步骤S202，业务1的路径计算；
步骤S203，通过FLOW_MOD消息承载业务1的SNC交叉1的交叉信息；
步骤S204，发送SNC1的交叉配置命令至板卡1；
步骤S205，板卡1处理交叉配置命令；
步骤S206，发送SNC1的交叉配置命令至板卡n；
步骤S207，板卡n处理交叉配置命令；
步骤S208，发送SNC1的映射配置命令至板卡n；
步骤S209，板卡n处理映射配置命令；
步骤S210，通过FLOW_MOD消息承载业务1的SNC交叉2的交叉信息；
步骤S211，发送SNC2的交叉配置命令至板卡1；
步骤S212，板卡1处理交叉配置命令；
步骤S213，发送SNC2的交叉配置命令至板卡n；
步骤S214，板卡n处理交叉配置命令；
步骤S215，发送SNC2的映射配置命令至板卡n；
步骤S216，板卡n处理映射配置命令；
步骤S217，发送业务1的BARRIER_REQUEST消息，以要求返回处理结果；
步骤S218，业务n的路径计算，计算之后的处理过程与上述相同，在此不再赘述；
步骤S219，发送业务n的BARRIER_REQUEST；
步骤S220，发送业务1的SNC1交叉响应；
步骤S221，发送业务1的SNC2交叉响应；
步骤S222，发送业务1的SNC1交叉响应；
步骤S223，发送业务1的SNC1映射响应；
步骤S224，发送业务1的SNC2交叉响应；
步骤S225，发送业务1的SNC2映射响应；
步骤S226，发送业务1的BARRIER_REPLY消息；
步骤S227，发送业务n的SNC1交叉响应；
步骤S228，发送业务n的SNC2交叉响应；
步骤S229，发送业务n的SNC1交叉响应；
步骤S230，发送业务n的SNC1映射响应；
步骤S231，发送业务n的SNC2交叉响应；
步骤S232，发送业务n的SNC2映射响应；
步骤S233，发送业务n的BARRIER_REPLY消息。
在上述方式中，不使用bundle机制进行OTN网络多业务恢复，与分组交换设备不同，基于时隙和波长交换的OTN网络设备在配置时较为复杂。对同一块OTN板卡而言，频繁地进行单次的交叉和映射配置，这种处理方式效率较低，且非常耗时。为了提高配置的效率，可将每一次的交叉和映射配置都合并在一起，一次性下发给板卡进行配置，能够提高板卡的处理效率，耗时减少明显。当OTN网络设备使用基于OFP v1.4.0及以后版本的扩展协议时，可以使用bundle机制来对多条业务的多个SNC交叉进行打包处理，恢复过程的示意图如图3所示：
步骤S301，网络故障上报；
步骤S302，业务1的路径计算；
步骤S303，业务n的路径计算；
步骤S304，发送bundle_open消息，启动bundle机制；
步骤S305，发送open_reply消息，以回应bundle机制开启；
步骤S306，通过flow_mod消息承载bundle_add_1消息，将板卡1的相关交叉配置的信息打包至bundle_add_1进行发送；
步骤S307，通过flow_mod消息承载bundle_add_n消息，将板卡n的相关交叉配置的信息打包至bundle_add_n进行发送；
步骤S308，发送bundle_close消息，以关闭bundle机制；
步骤S309，发送close_reply消息，发送关闭成功的回应消息；
步骤S310，发送bundle_commit消息，该消息用于触发板卡的配置功能，并要求返回配置结果；
步骤S311，发送配置业务1到业务n的多个交叉命令；
步骤S312，板卡1处理交叉配置命令；
步骤S313，配置业务1到业务n的多个映射命令；
步骤S314，板卡n处理交叉配置命令；
步骤S315，配置业务1到业务3的多个交叉命令；
步骤S316，板卡n处理多个交叉命令；
步骤S317，发送交叉响应；
步骤S318，发送映射响应；
步骤S319，发送交叉响应；
步骤S320，commit_reply，返回配置结果至控制器。
在SDN架构下的OTN网络中实现多个业务同时进行恢复，以提高多业务并行恢复性能，缩短业务受损时间，是一个非常严峻的问题，使用上述的bundle机制，可以一定程度上提高处理效率，但信令交互效率低下，同样影响恢复性能。
根据本发明实施例的一个方面，提供了一种SDN架构下多业务的并行恢复方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
图4是根据本发明实施例的一种SDN架构下多业务的并行恢复方法的流程图，如图4所示，该方法包括如下步骤：
步骤S401，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息。
步骤S402，基于接收到的故障告警信息为OTN节点生成对应的配置消息，配置消息用于重新配置OTN节点上的所有故障业务。
步骤S403，发送配置消息至对应的OTN节点。
可选地，可由OTN节点通过配置消息中对应于同一个OTN板卡的配置命令对同一个OTN板卡进行配置。
通过上述实施例，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点，将某一节点的所有的配置相关信息通过一个消息包来发送，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息，上述方法的执行主体可以为OTN网络中的控制器，但不局限于此。
在步骤S402中，基于接收到的故障告警信息为OTN节点生成对应的配置消息包括：根据故障告警信息确定故障业务的恢复路径；确定对应于恢复路径的SNC交叉信息；生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
可选地，根据故障告警信息确定故障业务的恢复路径是指从故障告警信息中获取故障业务的故障位置信息；根据故障位置信息生成故障业务的恢复路径。确定对应于恢复路径的SNC交叉信息是指获取恢复路径的路径信息；将恢复路径的路径信息转化为SNC交叉信息。
可选地，在发送配置消息至对应的OTN节点之后，可以通过如下方式获取配置的结果：发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复方法的方法实施例，如图5所示，该方法包括如下步骤：
步骤S501，发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
步骤S502，接收SDN控制器下发的配置消息，配置消息用于重新配置故障业务；
步骤S503，按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
通过上述实施例，发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡，某一节点通过接收一个消息包来获取所有的配置相关信息，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息，每条flow_mod消息中携带有多条SNC交叉信息，上述方法的执行主体可以为OTN网络中的OTN节点，OTN节点是指OTN网络设备节点(其相当于OTN网络设备的代理节点)，但不局限于此。
在上述的步骤S503中，按照配置消息的指示重新配置用于执行故障业务的OTN板卡包括：基于配置消息生成一个或多个用于配置OTN板卡的配置命令；将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。通过使用一个配置请求来携带多个业务的配置命令，以达到提高配置效率的目的。
可选地，基于配置消息生成一个或多个用于配置OTN板卡的配置命令可通过如下方式实现：获取配置消息中的一个或多个SNC交叉信息；将一个或多个SNC交叉信息转换为一个或多个配置命令。将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡包括：采 用TLV格式生成对应于配置命令的TLV数据包；将用于配置同一个OTN板卡的TLV数据包携带于配置请求中，发送至对应的OTN板卡。
可选地，在按照配置消息的指示重新配置用于执行故障业务的OTN板卡之后，在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
可选地，按照预设信息的指示收集被配置的OTN板卡的配置结果包括：接收OTN板卡发送的用于表示配置失败的信息；接收OTN板卡发送的用于表示配置成功的信息；若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
在上述实施例中，提供了一种基于OpenFlow协议扩展的多业务并行恢复的方法，该方法能够将操作同一个OTN网络设备节点的多条业务的多个SNC交叉放到一个flow_mod消息中进行下发，OTN网络设备节点再根据SNC交叉操作的板卡，将操作同一块板卡的多个同类配置命令放在一个配置请求中进行下发。这样不仅简化了控制器与网络设备之间的信令消息交互，还提高OTN板卡的配置处理效率，从而提高了SDN架构下OTN网络多业务并行恢复的性能，缩短了业务受损时间。如果OTN网络设备执行SNC交叉失败，可使用packet_in消息上报具体哪个SNC交叉执行失败。
下面结合图6详述本申请的实施例，如图6所示：
步骤S601，OTN网络中发生断纤，控制器通过OTN网络设备上报的传送平面故障告警信息(即故障告警信息)，感知到网络故障的具体位置。并根据故障位置，对由于该故障导致受损的业务进行恢复路径计算。
步骤S602，所有受损业务恢复路径计算结束后，分析所有业务的恢复路径，并将路由信息转为SNC交叉信息，具体是分析计算成功的恢复路径，并将各个恢复路径信息转化为多个SNC交叉信息。
步骤S603，根据SNC交叉所操作的OTN网络设备节点，将操作同一个 设备侧节点的多个SNC交叉信息通过一个flow_mod消息下发给对应的设备侧节点(即OTN节点)，然后再给对应的设备侧节点下发barrier_request消息用于确认执行结果，并给每个操作的设备侧节点启动信令超时定时器，用于确认barrier_reply响应消息是否超时。信令超时的时间可配置，其默认值为OFP标准规定的最小multipart_reply超时时间，即1秒钟。
步骤S604，OTN网络设备侧节点收到并解析SDN控制器下发的flow_mod消息，并将多个SNC交叉信息转换为多个操作OTN板卡的配置命令。
步骤S605，根据配置命令所操作的各个板卡，对配置命令进行分类。将需要操作同一块板卡的多个同类配置命令，都放在一个配置请求中，再下发给对应板卡，并给每个操作的板卡启动交叉超时定时器。交叉超时时间可配置，本申请根据OTN网络设备动态性能指标，设置交叉超时默认值为500毫秒。
各个设备侧节点收到控制器下发的barrier_request消息后，等待各个板卡返回执行结果后，再响应控制器barrier_reply消息，具体见如下步骤：
步骤S606，收集板卡配置响应，并判断板卡是否执行超时，也即收集各个板卡配置命令的执行结果，并判断交叉超时定时器是否超时，如果是，则按配置失败处理，执行步骤S608，如果否，则执行步骤S607。
步骤S607，判断需要执行操作的所有板卡的各个配置命令是否都返回了的执行结果。如果是，则执行步骤S608，如果否，则重复执行步骤S606。
步骤S608，整理各个板卡的配置命令的SNC交叉执行结果，如果均执行成功，则向控制器响应barrier_reply成功消息，如果有板卡命令执行失败，则向控制器响应barrier_reply失败消息，并通过packet_in消息上报执行失败的SNC ID信息(SNC板卡的标识信息)。
步骤S609，控制器收集各个设备侧节点的SNC交叉执行结果，并判断 信令超时定时器是否超时，如果超时，则对该设备侧节点按交叉失败处理。
步骤S610，判断是否所有设备侧节点都返回了SNC交叉执行结果，如果是，则执行步骤S611。如果否，则重复执行步骤S610。
步骤S611，控制器根据各个设备侧节点的交叉配置结果(即响应的消息)，判断各个业务是否恢复成功。如果各个节点都响应barrier_reply成功消息，则各个业务均恢复成功。如果存在设备侧节点响应barrier_reply失败消息，则根据packet_in消息上报的SNC ID信息，判断各个业务的恢复结果，流程结束。
在上述实施例中，基于最新版本的OpenFlow协议做了扩展，将多个SNC交叉配置信息封装在一个flow_mod消息中下发给设备侧节点，提高了南向信令的交互和处理效率。具体扩展内容如下：
在ofp_experimenters_field中增加OFPXMT_EXP_OTN_SNCID的定义，用于标示OXM(数据实体对象与XML节点之间的映射称为OXM)的扩展类型。并定义OFP_OXM_EXP_OTN_SNCID的OXM数据结构如图7所示。
上述的字段“ofp_experimenters_field”是Openflow协议光层协议扩展中“onf2015.569_04”中规定的用于表示具体扩展类型内容的字段，本申请在“onf2015.569_04”协议标准的基础上做了扩展，增加了OTN_SNCID的内容。
字段“OFPXMT_EXP_OTN_SNCID”是本申请为了使一个flow_mod消息中能够携带多个SNC信息，而扩展的Openflow协议所定义的新内容，用于表示SNC交叉的ID值。只有使用这个字段所对应的内容，才能准确的标识和区分各个SNC交叉信息。达到在一个flow_mod消息中携带多个SNC交叉时，能够准确的定位和操作每一个SNC交叉的目的。
需要说明的是，SNC在ITU-TG.8080标准中被定义，中文名称为子网连接，定义内容为：子网连接表示了在同一个子网的边界上，两个子网点之间的动态关系。其实就是指定一个流的入端口和入标签，以及出端口和出标签。有了这些入出信息，就能够配置一个数据流。现有的flow_mod 消息，只能携带一个SNC交叉信息，无法携带多个，因为入出端口和标签是分开存储的。本申请扩展了协议，新定义了SNC ID的内容，这样就能够对分别存储的入出端口和标签之间建立联系，从而确保将打散的入出端口和标签，能够有序和准确的组成一个个SNC交叉信息。
在图7中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID。experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示扩展的OXM结构。sncid的取值为设备侧节点的唯一编号，使用sncid对不同的SNC交叉进行编号。根据OpenFlow协议的标准规定，SNC交叉中的信号类型、入端口和入标签需要放在flow_mod消息的match域中，而SNC交叉中的出端口和出标签需要放在flow_mod消息的instructions域中。因此需要分别解析flow_mod消息的match域和instructions域后，才能得到一个完整的SNC交叉信息。
由于要将多个SNC交叉封装在一个flow_mod消息中，因此要使用sncid对不同的SNC交叉进行编号，这样就可以根据sncid的值将分配在match域和instructions域中多个入SNC信息和多个出SNC信息进行一一对应，从而在解析该flow_mod消息能够完整的组合出各个SNC交叉信息。
flow_mod消息填写方法为：match域中通过OTN_SNCID将多个SNC交叉中的信号类型、入端口和入标签信息分别进行编号，并按顺序分别填到多个OXM中。instructions域中也通过OTN_SNCID将多个SNC交叉中的出端口和出标签信息进行区分，并按顺序填写到多个action中。对于同一个SNC而言，match域中sncid的值与instructions域中sncid的值要保持一致，扩展后的flow_mod消息示例如图8所示(图8中的消息含义见与图7相关的描述和flow_mod消息的相关定义)。
在上述实施例中，将对同一块OTN板卡设置的多个同类配置命令，放在一个配置请求中，下发给OTN板卡，提高了板卡的处理效率。
OTN板卡的配置命令包括：交叉、映射、波长指派、波长调谐等，本 申请采用TLV格式将多个同类的配置命令放在一个请求中，下发给对应板卡。以交叉配置命令为例，配置请求中携带多个TLV的总长度，每个TLV携带一条具体的交叉命令，内容包括：操作类型，源单板，源支路信息，目的单板，目的支路信息等信息。
在上述实施例中，当OTN网络设备执行配置命令失败时，本申请增加了新的流程，通过扩展后的packet_in(为OpenFlow协议中定义的一类消息)消息上报执行失败的SNC ID信息，用于控制器定位交叉执行失败的业务，使多业务并行恢复过程更加完备。packet_in消息具体扩展内容如下：
在ofp_packet_in_reason中增加OFPR_OTN_CONFIG_SNC_FAIL的定义，表示上报原因为“SNC配置失败”。在packet_in消息的match域中，填写本申请扩展的OXM结构OFP_OXM_EXP_OTN_SNCID，其中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID，experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示是扩展的OXM结构。sncid中填写SNC交叉执行失败的sncid值，扩展后的packet_in消息示例如图9所示。
下面结合具体的实施方式详述本申请的实施例。
初始网络拓扑图如图10所示，该网络为纯ODU层网络，其中有四个OTN网络设备节点，分别为A、B、C、D点。网络中共有5条ODU层链路，链路编号分别为1到5，每条链路的带宽均为100G(ODU4)，在A点和B点之间存在80条无保护的ODU0业务，业务路径都为A点(链路1)到B点。
实施方式1
假设链路1发生故障，80条业务并行恢复成功，如图11所示：
步骤S1101，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都 为A点(链路5)到D点(链路4)到B点。
步骤S1102，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1103，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1104，设备侧解析flow_mod，将多个SNC交叉信息转换为多个板卡配置命令，具体是三个设备侧节点分别收到flow_mod消息，并根据扩展的OTN_SNCID分别解析match域和instructions域中的入、出端口和标签信息，并组成各个SNC交叉信息。
步骤S1105，分析各个SNC交叉信息，将每一个SNC交叉信息都转换为一个或多个板卡配置命令，并根据操作的板卡将配置命令进行分类，将操作同一块板卡的多个同类配置命令，都放在一个配置请求中，下发给对应板卡，并启动交叉超时定时器，超时时间为500毫秒。
步骤S1106，收集板卡各个配置命令的执行结果(即配置响应信息)，所有操作的板卡均在500毫秒内响应了执行成功。三个设备侧节点收到barrier_request消息后，向控制器响应barrier_reply成功消息。
步骤S1107，SDN控制器在1秒内，分别收到A、D、B三个OTN网络设备节点响应的barrier_reply成功消息，向控制器响应barrier_reply成功消息。
步骤S1108，各个设备侧节点均返回成功，80条业务并行恢复成功，即80条ODU0业务均恢复成功，流程结束。
实施方式2
假设链路1发生故障，由于设备侧节点交叉执行失败，80条业务部分恢复成功，部分恢复失败，本实施例流程图如图12所示。
步骤S1201，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1202，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1203，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1204，设备侧解析flow_mod，将多个SNC交叉信息转换为多个板卡配置命令，具体是三个设备侧节点分别收到flow_mod消息，并根据扩展的OTN_SNCID分别解析match域和instructions域中的入、出端口和标签信息，并组成各个SNC交叉信息。
步骤S1205，分析各个SNC交叉信息，将每一个SNC交叉信息都转换 为一个或多个板卡配置命令，并根据操作的板卡将配置命令进行分类，将操作同一块板卡的多个同类配置命令，都放在一个配置请求中，下发给对应板卡，并启动交叉超时定时器，超时时间为500毫秒。
步骤S1206，收集板卡各个配置命令的执行结果(即配置响应信息)，所有操作的板卡均在500毫秒内响应了执行结果，但节点D的部分板卡交叉执行失败。因此三个设备侧节点收到barrier_request消息后，节点A、节点B向控制器响应barrier_reply成功消息，而节点D则向控制器响应barrier_reply失败消息，并根据执行失败的配置命令，将执行失败的SNC ID通过packet_in消息上报给控制器。
步骤S1207，部分板卡响应执行失败，向控制器响应barrier_reply失败消息，并通过packet_in上报失败的SNC ID信息，SDN控制器在1秒之内，分别收到了节点A和节点B响应的barrier_reply成功消息，以及节点D响应的barrier_reply失败消息，并解析节点D上报的packet_in消息中的SNC ID，判断80条ODU0业务哪些恢复成功，哪些恢复失败，流程结束。
步骤S1208，存在交叉执行失败的节点，根据packet_in上报失败的SNC ID信息，判断80条业务哪些恢复成功，哪些恢复失败。
实施方式3
假设链路1发生故障，由于控制器与设备侧之间的南向信令中断，导致信令超时，80条业务并行恢复失败，流程如图13所示。
步骤S1301，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1302，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由 信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1303，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1304，收集各个节点的响应，节点A和节点B均返回成功，但节点D响应超时，由于控制器与节点D之间的信令发生故障，因此无法收到控制器下发的flow_mod消息和barrier_request消息，节点A和节点B收到flow_mod消息和barrier_request消息，且执行交叉成功，并响应控制器barrier_reply成功消息。
步骤S1305，节点D信令超时，交叉设置失败，判断80条业务均恢复失败，SDN控制器在1秒内，只收到了节点A和节点B的barrier_reply成功消息，但没有收到节点D响应的barrier_reply消息，则认为节点D所有SNC交叉均执行失败，80条ODU0业务并行恢复失败，流程结束。
实施方式4
假设链路1发生故障，由于设备侧节点交叉执行超时，80条业务部分恢复成功，部分恢复失败，流程如图14所示：
步骤S1401，控制器通过设备侧上报的告警信息，感知到链路1发生中断(即传送面故障)。根据故障位置，判断有80条ODU0业务需要同时进行恢复处理。对80条业务进行路径计算，得到80条业务的恢复路径都为A点(链路5)到D点(链路4)到B点。
步骤S1402，分析80条业务的恢复路径，并将路由信息转为SNC交叉信息，根据操作的设备侧节点对SNC进行分类，具体是将各个业务的路由信息转化为多个SNC交叉信息，然后将操作A点、D点、B点的多个SNC交叉信息分别进行分析和综合，最后生成三组交叉数据：节点A的SNC交叉数据包，节点D的SNC交叉数据包和节点B的SNC交叉数据包。
步骤S1403，根据本申请所提供的OFP扩展方法，将三组SNC交叉数据包，分别封装到三个flow_mod消息中，将操作同一个设备侧节点的多个SNC交叉信息，通过扩展后的OpenFlow消息分别发给各个设备侧节点，即分别下发给A、D、B三个设备侧节点，并下发barrier_request用于确认执行结果最后启动信令超时定时器，即分别给A、D、B三个设备侧节点下发barrier_request消息，用于确认交叉的执行结果，并启动信令超时定时器，超时时间为1秒。
步骤S1404，设备侧解析flow_mod，将多个SNC交叉信息转换为多个板卡配置命令，具体是三个设备侧节点分别收到flow_mod消息，并根据扩展的OTN_SNCID分别解析match域和instructions域中的入、出端口和标签信息，并组成各个SNC交叉信息。
步骤S1405，分析各个SNC交叉信息，将每一个SNC交叉信息都转换为一个或多个板卡配置命令，并根据操作的板卡将配置命令进行分类，将操作同一块板卡的多个同类配置命令，都放在一个配置请求中，下发给对应板卡，并启动交叉超时定时器，超时时间为500毫秒。
步骤S1406，收集板卡各个配置命令的执行结果，节点D的部分板卡在500毫秒内没有响应执行结果，而其他操作的板卡均响应了成功的执行结果。
步骤S1407，部分板卡响应超时，按配置执行失败处理，板卡配置命令响应超时，则认为配置失败。
步骤S1408，向控制器响应barrier_reply失败消息，并通过packet_in上报失败的SNC ID信息，三个设备侧节点收到barrier_request 消息后，节点A和节点B向控制器响应barrier_reply成功消息，而节点D则向控制器响应barrier_reply失败消息，并根据执行超时的配置命令，将执行失败的SNC ID通过packet_in消息上报给控制器。
步骤S1409，存在交叉执行失败的节点，根据packet_in上报失败的SNC ID信息，判断80条业务哪些恢复成功，哪些恢复失败，SDN控制器在1秒内，分别收到了节点A和节点B响应的barrier_reply成功消息，以及节点D响应的barrier_reply失败消息，并解析节点D上报的packet_in消息中的SNC ID，判断80条ODU0业务哪些恢复成功，哪些恢复失败，流程结束。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
本发明实施例中还提供了一种SDN架构下多业务的并行恢复装置。该装置设置为实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图15是根据本发明实施例的一种SDN架构下多业务的并行恢复装置的示意图。如图15所示，该装置可以包括：第一接收单元151、生成单元152以及第一发送单元153。
第一接收单元151设置为接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；
生成单元152设置为基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；
第一发送单元153设置为发送配置消息至对应的OTN节点。
通过上述实施例，第一接收单元接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；生成单元基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；第一发送单元发送配置消息至对应的OTN节点，将某一节点的所有的配置相关信息通过一个消息包来发送，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息。
可选地，生成单元包括：第一确定模块，设置为根据故障告警信息确定故障业务的恢复路径；第二确定模块，设置为确定对应于恢复路径的SNC交叉信息；第一生成模块，设置为生成包括所有用于操作OTN节点的SNC交叉信息的配置消息。
可选地，上述的第一确定模块包括：第一获取子模块，设置为从故障告警信息中获取故障业务的故障位置信息；生成子模块，设置为根据故障位置信息生。
上述的第二确定模块包括：第二获取子模块，设置为获取恢复路径的路径信息；转化子模块，设置为将恢复路径的路径信息转化为SNC交叉信息。
在上述实施例中，可以通过如下方式获取配置的结果：第一发送单元在发送配置消息至对应的OTN节点之后，还设置为发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；装置还包括：第二接收单元，设置为接收OTN节点发送的用于表示配置结果的反馈信息。
根据本发明实施例的另一个方面，还提供了一种SDN架构下多业务的并行恢复装置的实施例，图16是根据本发明实施例的另一种SDN架构下多业务的并行恢复装置的示意图。如图16所示，该装置可以包括：第二发送单元161、第三接收单元162以及配置单元163。
第二发送单元161，设置为发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
第三接收单元162，设置为接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；
配置单元163，设置为按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
通过上述实施例，第二发送单元发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；第三接收单元接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；配置单元按照配置消息的指示重新配置用于执行故障业务的OTN板卡，某一节点通过接收一个消息包来获取所有的配置相关信息，从而解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。
需要说明的是，上述的配置消息包括flow_mod消息，上述OTN节点是指OTN网络设备节点(其相当于OTN网络设备的代理节点)，但不局限于此。
上述的配置单元包括：第二生成模块，设置为基于配置消息生成一个或多个用于配置OTN板卡的配置命令；发送模块，设置为将用于配置同一个OTN板卡的配置命令携带于配置请求中，发送至对应的OTN板卡。
可选地，第二生成模块包括：第三获取子模块，设置为获取配置消息中的一个或多个SNC交叉信息；转换子模块，设置为将一个或多个SNC交叉信息转换为一个或多个配置命令。
可选地，上述装置还可包括：收集单元，设置为在按照配置消息的指 示重新配置用于执行故障业务的OTN板卡之后，在接收到SDN控制器下发的预设信息时，按照预设信息的指示收集被配置的OTN板卡的配置结果；反馈单元，设置为将收集到的配置结果携带于反馈信息中，反馈至SDN控制器，其中，反馈信息中包括配置失败的OTN板卡的标识信息。
可选地，收集单元包括：第一接收模块，设置为接收OTN板卡发送的用于表示配置失败的信息；第二接收模块，设置为接收OTN板卡发送的用于表示配置成功的信息；处理模块，设置为若在预设时间内未接收到OTN板卡的配置结果，则将配置超时作为OTN板卡的配置结果。
在上述实施例中，提供了一种基于OpenFlow协议扩展的多业务并行恢复方式，能够将操作同一个OTN网络设备节点的多条业务的多个SNC交叉放到一个flow_mod消息中进行下发，OTN网络设备节点再根据SNC交叉操作的板卡，将操作同一块板卡的多个同类配置命令放在一个配置请求中进行下发。这样不仅简化了控制器与网络设备之间的信令消息交互，还提高OTN板卡的配置处理效率，从而提高了SDN架构下OTN网络多业务并行恢复的性能，缩短了业务受损时间。如果OTN网络设备执行SNC交叉失败，可使用packet_in消息上报具体哪个SNC交叉执行失败。
下面结合图6详述本申请的实施例，上述的装置可按照如图6所示的步骤工作：
步骤S601，OTN网络中发生断纤，控制器通过OTN网络设备上报的传送平面故障告警信息，感知到网络故障的具体位置。并根据故障位置，对由于该故障导致受损的业务进行恢复路径计算。
步骤S602，所有受损业务恢复路径计算结束后，分析所有业务的恢复路径，并将路由信息转为SNC交叉信息，具体是分析计算成功的恢复路径，并将各个恢复路径信息转化为多个SNC交叉信息。
步骤S603，根据SNC交叉所操作的OTN网络设备节点，将操作同一个设备侧节点的多个SNC交叉信息通过一个flow_mod消息下发给对应的设备侧节点(即OTN节点)，然后再给对应的设备侧节点下发 barrier_request消息用于确认执行结果，并给每个操作的设备侧节点启动信令超时定时器，用于确认barrier_reply响应消息是否超时。信令超时的时间可配置，其默认值为OFP标准规定的最小multipart_reply超时时间，即1秒钟。
步骤S604，OTN网络设备侧节点收到并解析SDN控制器下发的flow_mod消息，并将多个SNC交叉信息转换为多个操作OTN板卡的配置命令。
步骤S605，根据配置命令所操作的各个板卡，对配置命令进行分类。将需要操作同一块板卡的多个同类配置命令，都放在一个配置请求中，再下发给对应板卡，并给每个操作的板卡启动交叉超时定时器。交叉超时时间可配置，本申请根据OTN网络设备动态性能指标，设置交叉超时默认值为500毫秒。
各个设备侧节点收到控制器下发的barrier_request消息后，等待各个板卡返回执行结果后，再响应控制器barrier_reply消息，具体见如下步骤：
步骤S606，收集板卡配置响应，并判断板卡是否执行超时，也即收集各个板卡配置命令的执行结果，并判断交叉超时定时器是否超时，如果是，则按配置失败处理，执行步骤S608，如果否，则执行步骤S607。
步骤S607，判断需要执行操作的所有板卡的各个配置命令是否都返回了的执行结果，如果是，则执行步骤S608，如果否，则重复执行步骤S606。
步骤S608，整理各个板卡的配置命令的SNC交叉执行结果，如果均执行成功，则向控制器响应barrier_reply成功消息，如果有板卡命令执行失败，则向控制器响应barrier_reply失败消息，并通过packet_in消息上报执行失败的SNC ID信息(SNC板卡的标识信息)。
步骤S609，控制器收集各个设备侧节点的SNC交叉执行结果，并判断信令超时定时器是否超时，如果超时，则对该设备侧节点按交叉失败处理。
步骤S610，判断是否所有设备侧节点都返回了SNC交叉执行结果，如 果是，则执行步骤S611。如果否，则重复执行步骤S610。
步骤S611，控制器根据各个设备侧节点的交叉配置结果(即响应的消息)，判断各个业务是否恢复成功。如果各个节点都响应barrier_reply成功消息，则各个业务均恢复成功。如果存在设备侧节点响应barrier_reply失败消息，则根据packet_in消息上报的SNC ID信息，判断各个业务的恢复结果，流程结束。
在上述实施例中，基于最新版本的OpenFlow协议，将多个SNC交叉配置信息封装在一个flow_mod消息中下发给设备侧节点，提高了南向信令的交互和处理效率。具体扩展内容如下：
在ofp_experimenters_field中增加OFPXMT_EXP_OTN_SNCID的定义，用于标示OXM(数据实体对象与XML节点之间的映射称为OXM)的扩展类型。并定义OFP_OXM_EXP_OTN_SNCID的OXM数据结构如图7所示。
在图7中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID。experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示扩展的OXM结构。sncid的取值为设备侧节点的唯一编号，使用sncid对不同的SNC交叉进行编号。根据OpenFlow协议的标准规定，SNC交叉中的信号类型、入端口和入标签需要放在flow_mod消息的match域中，而SNC交叉中的出端口和出标签需要放在flow_mod消息的instructions域中。因此需要分别解析flow_mod消息的match域和instructions域后，才能得到一个完整的SNC交叉信息。
由于要将多个SNC交叉封装在一个flow_mod消息中，因此要使用sncid对不同的SNC交叉进行编号，这样就可以根据sncid的值将分配在match域和instructions域中多个入SNC信息和多个出SNC信息进行一一对应，从而在解析该flow_mod消息能够完整的组合出各个SNC交叉信息。
flow_mod消息填写方法为：match域中通过OTN_SNCID将多个SNC交叉中的信号类型、入端口和入标签信息分别进行编号，并按顺序分别填到 多个OXM中；instructions域中也通过OTN_SNCID将多个SNC交叉中的出端口和出标签信息进行区分，并按顺序填写到多个action中。对于同一个SNC而言，match域中sncid的值与instructions域中sncid的值要保持一致，扩展后的flow_mod消息示例如图8所示(图8中的消息含义见与图7相关的描述和flow_mod消息的相关定义)。
在上述实施例中，将对同一块OTN板卡设置的多个同类配置命令，放在一个配置请求中，下发给OTN板卡，提高了板卡的处理效率。
OTN板卡的配置命令包括：交叉、映射、波长指派、波长调谐等，本申请采用TLV格式将多个同类的配置命令放在一个请求中，下发给对应板卡。以交叉配置命令为例，配置请求中携带多个TLV的总长度，每个TLV携带一条具体的交叉命令，内容包括：操作类型，源单板，源支路信息，目的单板，目的支路信息等信息。
在上述实施例中，当OTN网络设备执行配置命令失败时，本申请增加了新的流程，通过扩展后的packet_in(OpenFlow协议中定义的一类消息)消息上报执行失败的SNC ID信息，用于控制器定位交叉执行失败的业务，使多业务并行恢复过程更加完备。packet_in消息具体扩展内容如下：
在ofp_packet_in_reason中增加OFPR_OTN_CONFIG_SNC_FAIL的定义，表示上报原因为“SNC配置失败”。在packet_in消息的match域中，填写本申请扩展的OXM结构OFP_OXM_EXP_OTN_SNCID，其中，oxm_header的ofp_oxm_class填写为OFPXMC_EXPERIMENTER，而ofp-oxm_field填写为本申请扩展增加的OFPXMT_EXP_OTN_SNCID，experimenter填写为OFP_OTWG_EXPERIMENTER_ID表示是扩展的OXM结构。sncid中填写SNC交叉执行失败的sncid值，扩展后的packet_in消息示例如图9所示。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。
实施例3
根据本发明的另一个实施例，还提供了一种SDN架构下多业务的并行恢复系统，包括SDN控制器和OTN节点，其中，SDN控制器设置为接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息，并基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；OTN节点设置为接收SDN控制器发送的配置消息。
可选地，SDN控制器还设置为：在发送配置消息至对应的OTN节点之后，发送预设信息至OTN节点，其中，预设信息用于指示OTN节点反馈配置结果；接收OTN节点发送的用于表示配置结果的反馈信息。
该实施例的具体实施方式已在前述实施例中说明，在此不再赘述。
实施例4
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：
S11，接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；
S12，基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；
S13，发送配置消息至对应的OTN节点。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
S21，发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
S22，接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；
S23，按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为OTN节点生成对应的配置消息，其中，配置消息用于重新配置OTN节点上的所有故障业务；发送配置消息至对应的OTN节点。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收SDN控制器下发的配置消息，其中，配置消息用于重新配置故障业务；按照配置消息的指示重新配置用于执行故障业务的OTN板卡。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
工业实用性
如上所述，本发明实施例提供的一种SDN架构下多业务的并行恢复方法、装置及系统具有以下有益效果：解决了相关技术中，对SDN网络中的路由故障的处理效率较低的技术问题，实现了提高SDN网络中的路由故障的处理效率的技术效果。

Claims (32)

  1. 一种SDN架构下多业务的并行恢复方法，包括：
    接收归属于光传送网OTN节点的OTN网络设备上报的一条或多条故障告警信息；
    基于接收到的故障告警信息为所述OTN节点生成对应的配置消息，其中，所述配置消息用于重新配置所述OTN节点上的所有故障业务；
    发送所述配置消息至对应的所述OTN节点。
  2. 根据权利要求1所述的方法，其中，在发送所述配置消息至对应的所述OTN节点之后，所述方法还包括：
    发送预设信息至所述OTN节点，其中，所述预设信息用于指示所述OTN节点反馈配置结果；
    接收所述OTN节点发送的用于表示配置结果的反馈信息。
  3. 根据权利要求1所述的方法，其中，基于接收到的故障告警信息为所述OTN节点生成对应的配置消息包括：
    根据所述故障告警信息确定所述故障业务的恢复路径；
    确定对应于所述恢复路径的子网连接SNC交叉信息；
    生成包括所有用于操作所述OTN节点的所述SNC交叉信息的所述配置消息。
  4. 根据权利要求3所述的方法，其中，根据所述故障告警信息确定所述故障业务的恢复路径包括：
    从所述故障告警信息中获取所述故障业务的故障位置信息；
    根据所述故障位置信息生成所述故障业务的恢复路径。
  5. 根据权利要求3所述的方法，其中，确定对应于所述恢复路径的SNC交叉信息包括：
    获取所述恢复路径的路径信息；
    将所述恢复路径的路径信息转化为所述SNC交叉信息。
  6. 根据权利要求1所述的方法，其中，所述配置消息包括flow_mod消息，其中，所述flow_mod消息用于携带至少一个SNC交叉信息。
  7. 根据权利要求1至6中任意一项所述的方法，其中，所述的并行恢复方法应用于SDN控制器。
  8. 一种SDN架构下多业务的并行恢复方法，包括：
    发送光传送网OTN网络设备上报的一条或多条故障告警信息至软件定义网络SDN控制器；
    接收所述SDN控制器下发的配置消息，其中，所述配置消息用于重新配置故障业务；
    按照所述配置消息的指示重新配置用于执行所述故障业务的OTN板卡。
  9. 根据权利要求8所述的方法，其中，按照所述配置消息的指示重新配置用于执行所述故障业务的OTN板卡包括：
    基于所述配置消息生成一个或多个用于配置所述OTN板卡的配置命令；
    将用于配置同一个所述OTN板卡的配置命令携带于配置请求中，发送至对应的所述OTN板卡。
  10. 根据权利要求8所述的方法，其中，在按照所述配置消息的指示重新配置用于执行所述故障业务的OTN板卡之后，所述方法还包括：
    在接收到所述SDN控制器下发的预设信息时，按照所述预设信息 的指示收集被配置的所述OTN板卡的配置结果；
    将收集到的所述配置结果携带于反馈信息中，反馈至所述SDN控制器，其中，所述反馈信息中包括配置失败的OTN板卡的标识信息。
  11. 根据权利要求10所述的方法，其中，按照所述预设信息的指示收集被配置的所述OTN板卡的配置结果包括：
    接收所述OTN板卡发送的用于表示配置失败的信息；
    接收所述OTN板卡发送的用于表示配置成功的信息；
    若在预设时间内未接收到所述OTN板卡的配置结果，则将配置超时作为所述OTN板卡的配置结果。
  12. 根据权利要求9所述的方法，其中，基于所述配置消息生成一个或多个用于配置所述OTN板卡的配置命令包括：
    获取所述配置消息中的一个或多个子网连接SNC交叉信息；
    将所述一个或多个SNC交叉信息转换为一个或多个配置命令。
  13. 根据权利要求9所述的方法，其中，将用于配置同一个所述OTN板卡的配置命令携带于配置请求中，发送至对应的所述OTN板卡包括：
    采用TLV格式生成对应于所述配置命令的TLV数据包；
    将用于配置同一个所述OTN板卡的TLV数据包携带于所述配置请求中，发送至对应的所述OTN板卡。
  14. 根据权利要求8所述的方法，其中，所述配置消息包括flow_mod消息，其中，所述flow_mod消息用于携带至少一个SNC交叉信息。
  15. 根据权利要求8至14中任意一项所述的方法，其中，所述的并行恢复方法应用于OTN节点。
  16. 一种SDN架构下多业务的并行恢复装置，包括：
    第一接收单元，设置为接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；
    生成单元，设置为基于接收到的故障告警信息为所述OTN节点生成对应的配置消息，其中，所述配置消息用于重新配置所述OTN节点上的所有故障业务；
    第一发送单元，设置为发送所述配置消息至对应的所述OTN节点。
  17. 根据权利要求16所述的装置，其中，
    所述第一发送单元在发送所述配置消息至对应的所述OTN节点之后，还设置为发送预设信息至所述OTN节点，其中，所述预设信息用于指示所述OTN节点反馈配置结果；
    所述装置还包括：第二接收单元，设置为接收所述OTN节点发送的用于表示配置结果的反馈信息。
  18. 根据权利要求16或17所述的装置，其中，所述生成单元包括：
    第一确定模块，设置为根据所述故障告警信息确定所述故障业务的恢复路径；
    第二确定模块，设置为确定对应于所述恢复路径的SNC交叉信息；
    第一生成模块，设置为生成包括所有用于操作所述OTN节点的所述SNC交叉信息的所述配置消息。
  19. 根据权利要求18所述的装置，其中，所述第一确定模块包括：
    第一获取子模块，设置为从所述故障告警信息中获取所述故障业务的故障位置信息；
    生成子模块，设置为根据所述故障位置信息生成所述故障业务的恢复路径。
  20. 根据权利要求18所述的装置，其中，所述第二确定模块包括：
    第二获取子模块，设置为获取所述恢复路径的路径信息；
    转化子模块，设置为将所述恢复路径的路径信息转化为所述SNC交叉信息。
  21. 一种SDN架构下多业务的并行恢复装置，其中，包括：
    第二发送单元，设置为发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；
    第三接收单元，设置为接收所述SDN控制器下发的配置消息，其中，所述配置消息用于重新配置故障业务；
    配置单元，设置为按照所述配置消息的指示重新配置用于执行所述故障业务的OTN板卡。
  22. 根据权利要求21所述的装置，其中，所述配置单元包括：
    第二生成模块，设置为基于所述配置消息生成一个或多个用于配置所述OTN板卡的配置命令；
    发送模块，设置为将用于配置同一个所述OTN板卡的配置命令携带于配置请求中，发送至对应的所述OTN板卡。
  23. 根据权利要求21或22所述的装置，其中，所述装置还包括：
    收集单元，设置为在按照所述配置消息的指示重新配置用于执行所述故障业务的OTN板卡之后，在接收到所述SDN控制器下发的预设信息时，按照所述预设信息的指示收集被配置的所述OTN板卡的配置结果；
    反馈单元，设置为将收集到的所述配置结果携带于反馈信息中，反馈至所述SDN控制器，其中，所述反馈信息中包括配置失败的OTN板卡的标识信息。
  24. 根据权利要求23所述的装置，其中，所述收集单元包括：
    第一接收模块，设置为接收所述OTN板卡发送的用于表示配置失败的信息；
    第二接收模块，设置为接收所述OTN板卡发送的用于表示配置成功的信息；
    处理模块，设置为若在预设时间内未接收到所述OTN板卡的配置结果，则将配置超时作为所述OTN板卡的配置结果。
  25. 根据权利要求22所述的装置，其中，所述第二生成模块包括：
    第三获取子模块，设置为获取所述配置消息中的一个或多个SNC交叉信息；
    转换子模块，设置为将所述一个或多个SNC交叉信息转换为一个或多个配置命令。
  26. 一种SDN架构下多业务的并行恢复系统，包括SDN控制器和OTN节点，其中，
    所述SDN控制器设置为接收归属于所述OTN节点的OTN网络设备上报的一条或多条故障告警信息，并基于接收到的故障告警信息为所述OTN节点生成对应的配置消息，其中，所述配置消息用于重新配置所述OTN节点上的所有故障业务；
    所述OTN节点设置为接收所述SDN控制器发送的所述配置消息。
  27. 根据权利要求26所述的系统，其中，所述SDN控制器还设置为：
    在发送所述配置消息至对应的所述OTN节点之后，发送预设信息至所述OTN节点，其中，所述预设信息用于指示所述OTN节点反馈配置结果；
    接收所述OTN节点发送的用于表示配置结果的反馈信息。
  28. 一种SDN设备，包括：
    SDN控制器；
    设置为存储所述SDN控制器可执行指令的第一存储器；
    设置为根据所述SDN控制器的控制进行信息收发通信的第一传输装置；
    其中，所述SDN控制器设置为执行以下操作：接收归属于OTN节点的OTN网络设备上报的一条或多条故障告警信息；基于接收到的故障告警信息为所述OTN节点生成对应的配置消息，其中，所述配置消息用于重新配置所述OTN节点上的所有故障业务；发送所述配置消息至对应的所述OTN节点。
  29. 根据权利要求28所述的SDN设备，其中，所述SDN控制器还设置为执行以下操作：在发送所述配置消息至对应的所述OTN节点之后，发送预设信息至所述OTN节点，其中，所述预设信息用于指示所述OTN节点反馈配置结果；接收所述OTN节点发送的用于表示配置结果的反馈信息。
  30. 一种OTN设备，包括：
    OTN控制器；
    设置为存储所述OTN控制器可执行指令的第二存储器；
    设置为根据所述OTN控制器的控制进行信息收发通信的第二传输装置；
    其中，所述OTN控制器设置为执行以下操作：发送OTN网络设备上报的一条或多条故障告警信息至SDN控制器；接收所述SDN控制器下发的配置消息，其中，所述配置消息用于重新配置故障业务；按照所述配置消息的指示重新配置用于执行所述故障业务的OTN板卡。
  31. 根据权利要求30所述的OTN设备，其中，所述OTN控制器还设置为执行以下操作：基于所述配置消息生成一个或多个用于配置所述OTN板卡的配置命令；将用于配置同一个所述OTN板卡的配置命令携带于配置请求中，发送至对应的所述OTN板卡。
  32. 一种存储介质，所述存储介质包括存储的程序，其中，所述程序运行时执行权利要求1至15中任一项所述的方法。
PCT/CN2017/107019 2016-12-08 2017-10-20 Sdn架构下多业务的并行恢复方法、装置及系统 WO2018103460A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP17877993.0A EP3554007A4 (en) 2016-12-08 2017-10-20 PARALLEL RECOVERY METHOD, DEVICE AND SYSTEM FOR SEVERAL SERVICES IN AN SDN ARCHITECTURE

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201611123754.1A CN108183810B (zh) 2016-12-08 2016-12-08 Sdn架构下多业务的并行恢复方法、装置及系统
CN201611123754.1 2016-12-08

Publications (1)

Publication Number Publication Date
WO2018103460A1 true WO2018103460A1 (zh) 2018-06-14

Family

ID=62490675

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/107019 WO2018103460A1 (zh) 2016-12-08 2017-10-20 Sdn架构下多业务的并行恢复方法、装置及系统

Country Status (3)

Country Link
EP (1) EP3554007A4 (zh)
CN (1) CN108183810B (zh)
WO (1) WO2018103460A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020119625A1 (zh) * 2018-12-12 2020-06-18 中兴通讯股份有限公司 光纤割接方法、装置、sdn控制器、系统及存储介质

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110166299B (zh) * 2019-05-24 2022-05-10 新华三技术有限公司 Sdn控制器配置恢复方法及装置
CN112311573B (zh) * 2019-07-30 2024-02-06 中兴通讯股份有限公司 一种控制面和转发面配置一致的实现方法、装置和设备
CN110445529B (zh) * 2019-08-05 2021-09-24 天宸星通(深圳)科技有限公司 一种卫星物联网网关站及信息传输方法
CN116032720A (zh) * 2021-10-27 2023-04-28 中兴通讯股份有限公司 信息恢复方法、装置、电子设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102281103A (zh) * 2011-08-04 2011-12-14 北京邮电大学 基于模糊集合解算的光网络多故障恢复方法
CN102487329A (zh) * 2010-12-02 2012-06-06 中兴通讯股份有限公司 业务恢复方法及装置
US20150295752A1 (en) * 2014-04-14 2015-10-15 Fujitsu Limited Openflow switch and failure recovery method in openflow network

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5958056B2 (ja) * 2012-05-02 2016-07-27 富士通株式会社 障害救済方法及びノード装置
US9729949B2 (en) * 2014-04-23 2017-08-08 Alcatel Lucent Dynamic local decision control in software defined networking-based environment
US9237090B2 (en) * 2014-05-16 2016-01-12 Ciena Corporation Network routing systems and methods for validation of paths subsequent to validation failure
CN105656654A (zh) * 2014-11-14 2016-06-08 中兴通讯股份有限公司 路径获取方法和多域控制器、跨域业务保护方法和系统
CN105991332A (zh) * 2015-01-27 2016-10-05 中兴通讯股份有限公司 告警处理方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102487329A (zh) * 2010-12-02 2012-06-06 中兴通讯股份有限公司 业务恢复方法及装置
CN102281103A (zh) * 2011-08-04 2011-12-14 北京邮电大学 基于模糊集合解算的光网络多故障恢复方法
US20150295752A1 (en) * 2014-04-14 2015-10-15 Fujitsu Limited Openflow switch and failure recovery method in openflow network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3554007A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020119625A1 (zh) * 2018-12-12 2020-06-18 中兴通讯股份有限公司 光纤割接方法、装置、sdn控制器、系统及存储介质

Also Published As

Publication number Publication date
CN108183810B (zh) 2019-06-04
EP3554007A4 (en) 2020-04-29
EP3554007A1 (en) 2019-10-16
CN108183810A (zh) 2018-06-19

Similar Documents

Publication Publication Date Title
WO2018103460A1 (zh) Sdn架构下多业务的并行恢复方法、装置及系统
US6757297B1 (en) Method and apparatus for dynamic configuration and checking of network connections via out-of-band monitoring
EP2608459A2 (en) Router, virtual cluster router system and establishion method thereof
CN109314667B (zh) Sdn接口设备
JP2014042258A (ja) Ｍｐｌｓネットワークにおいて完全な論理接続を提供するための方法および装置
US9621685B2 (en) Architecture for an access network system management protocol control under heterogeneous network management environment
CN107104832B (zh) 跨洋复用段环网上自动发现跨节点业务拓扑的方法和设备
CN112020844A (zh) 用于互连多域网络分片控制和管理的系统、功能和接口
KR102257945B1 (ko) 서비스 데이터 전송 방법 및 장치
EP2862315B1 (en) Self-configuring transport network
CN105515816B (zh) 检测层次信息的处理方法及装置
CN103023702A (zh) 批量mib的处理方法
CN111142878A (zh) Sdn运维方法、装置、设备以及可读存储介质
CN104283802A (zh) 邻居发现方法和设备
WO2021098824A1 (zh) 网络切片创建方法、基础网络控制器、系统和存储介质
EP2672657A1 (en) Device and method for verifying communication redundancy in an automation network
US20180287884A1 (en) Cross-layer link discovery
RU2730390C1 (ru) Способ и устройство для автоматического определения топологии межузловой связи в совместно используемом резервном кольце трансокеанской мультиплексной секции
CN103108347A (zh) 有线网络和无线网络的关联告警方法及装置
CN107493182A (zh) 网元配置方法及装置
CN105530132A (zh) Cdocsis平台下catv光收模块的管理系统及方法
EP4071968A1 (en) Energy transmission method, energy router and operation control apparatus therefor, and storage medium
Thottan et al. The network OS: Carrier-grade SDN control of multi-domain, multi-layer networks
CN112865999B (zh) 信息处理方法及相关设备
Nsafoa‐Yeboah et al. Flexible open network operating system architecture for implementing higher scalability using disaggregated software‐defined optical networking

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: 17877993

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017877993

Country of ref document: EP

Effective date: 20190708