WO2016074522A1 - 路径获取方法和多域控制器、跨域业务保护方法和系统 - Google Patents

路径获取方法和多域控制器、跨域业务保护方法和系统 Download PDF

Info

Publication number
WO2016074522A1
WO2016074522A1 PCT/CN2015/088656 CN2015088656W WO2016074522A1 WO 2016074522 A1 WO2016074522 A1 WO 2016074522A1 CN 2015088656 W CN2015088656 W CN 2015088656W WO 2016074522 A1 WO2016074522 A1 WO 2016074522A1
Authority
WO
WIPO (PCT)
Prior art keywords
domain
path
protection path
controller
cross
Prior art date
Application number
PCT/CN2015/088656
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 中兴通讯股份有限公司
Publication of WO2016074522A1 publication Critical patent/WO2016074522A1/zh

Links

Images

Classifications

    • 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/76—Routing in software-defined topologies, e.g. routing between virtual machines
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical 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/12—Shortest path evaluation
    • 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/24—Multipath
    • H04L45/247—Multipath using M:N active or standby paths
    • 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

Definitions

  • the present invention relates to the field of network communication technologies, and in particular, to a path acquisition method, a multi-domain controller, and a cross-domain service protection method and system.
  • SDN Software Defined Network
  • OTN optical transport network
  • ODU optical channel data unit
  • SDN software-defined networking
  • OTN multi-domain networks it is common practice to deploy one or more SDN controllers in each OTN domain.
  • the network architecture is similar to that shown in Figure 1.
  • the controller in each domain is responsible for establishing and maintaining the mapping between the network view and the physical device network in the domain, and participating in the path calculation of the domain.
  • the controller in the domain is called a single.
  • the domain controller is connected to the plurality of single-domain controllers in the north direction, and is a multi-domain controller.
  • the multi-domain controller communicates with the single-domain controller through the openflow protocol, and can establish a network view of the entire network and a domain of the physical device network.
  • Inter-domain mapping, and inter-domain path calculation for inter-domain service connections inter-domain configuration process for inter-domain service connections based on cross-domain inter-domain path results, and cross-domain connection to each domain's single-domain controller in each domain Internal configuration request, each single-domain controller completes the path calculation of the cross-domain service in the local domain, and configures the entire cross-domain service in the domain according to the path calculation result in the local domain. Connecting portion, and the connection relationship issued to the device layer.
  • the main technical problem to be solved by the present invention is to provide a path acquisition method, a multi-domain controller, and an inter-domain service protection method and system, which can solve the problem in the current multi-domain OTN SDN system when the cross-domain service path fails. Timely The problem of protecting the business with a protection path.
  • the present invention provides a path acquisition method, which is applied to a multi-domain OTN software definition network, and includes the following steps:
  • the multi-domain controller acquires inter-domain link information, where the inter-domain link information includes: an identifier of the domain and an identifier of a border node in the domain;
  • the multi-domain controller After receiving the cross-domain service establishment request, the multi-domain controller calculates an initial working path of the cross-domain service according to the inter-domain link information;
  • the multi-domain controller calculates an initial protection path of the cross-domain service according to the inter-domain link information and the initial working path;
  • the multi-domain controller initiates an intra-domain protection path calculation request to the single-domain controller of the corresponding domain according to the initial protection path;
  • the multi-domain controller receives the intra-domain protection path calculation result returned by the single-domain controller, and obtains the protection path of the cross-domain service according to the intra-domain protection path calculation result and the initial protection path.
  • the inter-domain link information includes: an identifier of the domain and an identifier of the border node in the domain.
  • the step of acquiring the inter-domain link information by the multi-domain controller includes:
  • the multi-domain controller acquires the inter-domain link information by using OFPT_MULTIPART_REPLY sent by a single domain controller.
  • the step of calculating an initial working path of the cross-domain service according to the inter-domain link information includes:
  • the step of the multi-domain controller calculating the initial protection path of the cross-domain service according to the inter-domain link information and the initial working path includes:
  • the multi-domain controller uses the intermediate domain that the initial working path passes as a escaping condition, and calculates an initial protection path of the cross-domain service according to the evasive condition and the inter-domain link information;
  • the multi-domain controller uses the intermediate node on the initial working path as a evasive condition, and calculates an initial protection path of the cross-domain service according to the evasive condition and the inter-domain link information.
  • the present invention also provides a cross-domain service protection method, which is applied to a multi-domain OTN software definition network, and includes the following steps:
  • the protection path of the cross-domain service is obtained by using the path acquisition method according to any one of the preceding aspects, where the protection domain path includes a relative intra-domain protection path, and the relative intra-domain protection path includes an intra-domain protection path of the local domain and a boundary node within the domain. of Inter-domain protection path,
  • the saved intra-domain protection path is sent to a corresponding node in the domain for the node to establish a protection connection.
  • the step of the multi-domain controller sending the relative intra-domain protection path to the single domain controller of the corresponding domain includes:
  • the multi-domain controller sends the relative intra-domain protection path to a single-domain controller of the corresponding domain by using a flow-mod message.
  • the step of the multi-domain controller sending the relative intra-domain protection path to the single-domain controller of the corresponding domain by using a flow-mod message includes:
  • the multi-domain controller adds the relative intra-domain protection path to an extension field in a flow-mod message, and identifies the message as a relative intra-domain working path in a flow-mod message, and sends the flow-mod message to A single domain controller corresponding to the domain.
  • the present invention further provides a multi-domain controller, which is applied to a software-defined network of a multi-domain OTN, and includes: an information acquisition module, a calculation module, a request module, and a processing module;
  • the information acquiring module is configured to acquire inter-domain link information
  • the calculating module is configured to: after receiving the cross-domain service establishment request, calculate an initial working path of the cross-domain service according to the inter-domain link information, according to the inter-domain link information and the initial working path Calculating an initial protection path of the cross-domain service;
  • the requesting module is configured to initiate an intra-domain protection path calculation request to the single-domain controller of the corresponding domain according to the initial protection path;
  • the processing module is configured to receive an intra-domain protection path calculation result returned by the single domain controller, and obtain a protection path of the cross-domain service according to the intra-domain protection path calculation result and the initial protection path.
  • the present invention also provides an inter-domain service protection system, which is applied to a multi-domain OTN software definition network, including: multi-domain controller and single-domain control of multiple OTN domains as described above Device
  • the multi-domain controller is configured to obtain a working path of the cross-domain service, where the protection path includes a relative intra-domain protection path, where the intra-domain protection path includes an intra-domain protection path of the local domain and inter-domain protection of the inner boundary node of the local domain. a path, and a single domain controller that sends the protection path in the relative domain to the corresponding domain;
  • the protection path in the domain is configured to save the received intra-domain protection path; and when the working path of the cross-domain service fails, the saved intra-domain protection path is sent to the corresponding domain.
  • the node is for the node to establish a protected connection.
  • the present invention provides a path acquisition method, a multi-domain controller, and a cross-domain service protection method and system, which can protect a service by using a protection path when a cross-domain service path fails in a multi-domain OTN SDN system.
  • the present invention provides a path obtaining method, which is applied to a software-defined network of a multi-domain OTN, including: a multi-domain controller acquiring inter-domain link information; and the multi-domain controller receiving cross-domain services After the request is established, the initial working path of the cross-domain service is calculated according to the inter-domain link information, and the multi-domain controller calculates the cross-domain service according to the inter-domain link information and the initial working path.
  • the method can calculate the protection path corresponding to the working path of the cross-domain service through the multi-domain controller; so that the node device can use the protection path to forward the service in time when the working path of the cross-domain service fails, and ensure the normal transmission of the service; In the current multi-domain OTN SDN system, when the cross-domain service path fails, the protection path cannot be used to protect the service in time, and the network reliability is improved.
  • FIG. 1 is a schematic diagram of an architecture of a multi-domain OTN software definition network
  • FIG. 2 is a schematic flowchart of a path acquiring method according to Embodiment 1 of the present invention.
  • FIG. 3 is a schematic flowchart of a cross-domain service protection method according to Embodiment 2 of the present invention.
  • FIG. 4 is a schematic diagram of a topology of a multi-domain OTN according to Embodiment 2 of the present invention.
  • FIG. 5 is a schematic flowchart of another cross-domain service protection method according to Embodiment 2 of the present invention.
  • FIG. 6 is a schematic diagram of an extension of an ofp_port structure according to Embodiment 2 of the present invention.
  • FIG. 7 is a schematic diagram of a domain abstract diagram for calculating a protection path according to Embodiment 2 of the present invention.
  • FIG. 8 is a schematic diagram of a process for a multi-domain controller to initiate an intra-domain path calculation request to a single domain controller according to Embodiment 2 of the present invention
  • FIG. 9 is a schematic diagram of a working path and a protection path of a cross-domain service according to Embodiment 2 of the present invention.
  • FIG. 10 is a schematic structural diagram of a multi-domain controller according to Embodiment 3 of the present invention.
  • FIG. 11 is a schematic flowchart of a cross-domain service protection system according to Embodiment 4 of the present invention.
  • Embodiment 1 is a diagrammatic representation of Embodiment 1:
  • this embodiment provides a path acquisition method, which is applied to In the multi-domain OTN SDN, the following steps are included:
  • Step 201 The multi-domain controller acquires inter-domain link information.
  • the inter-domain link information in this step includes: an identifier of the domain and an identifier of the border node in the domain.
  • the process of implementing the step 201 includes:
  • the multi-domain controller sends an OFPT_MULTIPART_REQUET request to the single-domain controller to report the inter-domain link information
  • the single-domain controller sends the OFPT_MULTIPART_REPLY report inter-domain link information to the multi-domain controller.
  • the inter-domain link information in this embodiment may include: a domain ID, an intra-domain border node ID, and a port ID.
  • the inter-domain link information is reported to the multi-domain controller by the ofp_port in the OFPT_MULTIPART_REPLY.
  • the ofp_port extension field in OFPT_MULTIPART_REPLY carries the domain ID and the border node ID.
  • Step 202 After receiving the cross-domain service establishment request, the multi-domain controller calculates an initial working path of the cross-domain service according to the inter-domain link information.
  • the initial working path of this embodiment includes a boundary node of a domain, and a source node and a destination node of the cross-domain service.
  • the multi-domain controller may generate inter-domain topology information or inter-node topology information according to the reported inter-domain link information, and then calculate according to the topology information, the preset path algorithm, and the source node and the destination node of the service.
  • the required working path For example, according to the source node and the destination node, a required path is determined in the topology map, and the path is the working path.
  • the initial working path in this embodiment may be the shortest initial working path; in this case, the preset path algorithm may be a shortest path algorithm, such as the Dijkstra algorithm.
  • Step 203 The multi-domain controller calculates an initial protection path of the cross-domain service according to the inter-domain link information and the initial working path.
  • the initial protection path of the cross-domain service is calculated according to the inter-domain link information and the initial working path. Specifically, the initial protection path is calculated according to the generated topology information and the initial working path.
  • This step can use two strategies to calculate the initial protection path:
  • the multi-domain controller uses the intermediate domain through which the initial working path passes as the avoidance condition, and calculates the initial protection path of the cross-domain service according to the avoidance condition and the inter-domain link information.
  • the intermediate domain through which the initial working path passes is used as a avoidance condition, and then the corresponding initial protection path is calculated according to the topology information after avoiding the intermediate domain.
  • the multi-domain controller uses the intermediate node on the initial working path as the avoidance condition, and calculates the initial protection path of the cross-domain service according to the avoidance condition and the inter-domain link information.
  • the intermediate node that passes the initial working path is used as a avoidance condition, and then the corresponding initial protection path is calculated according to the topology information after the node is avoided.
  • the initial protection path includes a boundary node of the domain, a source node of the service, and a destination node of the service.
  • Step 204 The multi-domain controller initiates an intra-domain protection path calculation request to the single domain controller of the corresponding domain according to the initial protection path.
  • the working path and the protection path of the cross-domain service basically consists of the inter-domain path and the intra-domain path.
  • the inter-domain path and the approximate intra-domain path are determined, for example, only the source node and the source of the service are known.
  • this step includes:
  • These single-domain controllers calculate the protection path between the source node and the boundary node in the same domain, or calculate the protection path between two boundary nodes in the same domain, or calculate the protection path between the destination node and the boundary node in the same domain; These single domain controllers return the results of the calculations to the multi-domain controller.
  • the above process may also be adopted: initiating an intra-domain working path calculation request according to the initial working path to the single domain controller of the corresponding domain; and the multi-domain controller receiving the intra-domain working path returned by the single domain controller The calculation result and the calculation result of the protection path in the domain; then the working path of the cross-domain service is obtained according to the calculation result of the working path in the domain and the initial working path (the final working path is obtained by splicing).
  • Step 205 The multi-domain controller receives the calculation result of the intra-domain protection path returned by the single-domain controller, and obtains the protection path of the cross-domain service according to the calculation result of the protection path in the domain and the initial protection path.
  • the process of obtaining the protection path of the cross-domain service according to the calculation result of the intra-domain protection path and the initial protection path in this step may include: splicing the calculation result of the protection path in the domain into the initial protection path to obtain a final protection path.
  • the path obtaining method provided in this embodiment can calculate the protection path of the cross-domain service through the multi-domain controller.
  • the node device can use the protection path to forward the service in time to ensure the service. Normal transmission; solves the problem that the current multi-domain OTN SDN system fails to use the protection path to protect the service when the cross-domain service path fails, and improves the network reliability.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • this embodiment provides a cross-domain service protection method, which is applied to a multi-domain OTN software definition network, and includes the following steps:
  • Step 301 The path obtaining method of the first embodiment is used to obtain a protection path of the cross-domain service, where the protection path includes a protection path in the opposite domain, and the protection path in the opposite domain includes the intra-domain protection path of the local domain and the inter-domain protection path of the boundary node in the local domain.
  • Step 302 The multi-domain controller sends the relative intra-domain protection path to the single-domain controller of the corresponding domain.
  • the intra-domain protection path in this step may include routing information of the working path in the opposite domain and routing information of the protection path in the opposite domain.
  • the in-domain protection path is sent to the single-domain controller of the corresponding domain by using the service establishment request message, where the service establishment request message is a flow_mod message, that is, the relative intra-domain protection path is sent to the flow-mod message.
  • the service establishment request message is a flow_mod message
  • this step may add a relative intra-domain protection path to the extension field in the flow-mod message, and identify the message as a relative intra-domain protection path in the flow-mod message, and send the flow-mod message to the corresponding domain.
  • a domain controller that implements a single domain controller that sends a relative intradomain protection path to the corresponding domain.
  • the working path in the relative domain may be sent to the single domain controller of the corresponding domain by using the manner of sending the protection path in the relative domain.
  • the single domain controller corresponding to the domain in this embodiment includes a single domain controller of the domain through which the protection path passes.
  • Step 303 The single domain controller that receives the protection path in the opposite domain saves the protection path in the relative domain.
  • This step is to save the protection path in the relative domain.
  • the saved protection path can be sent to the corresponding node to establish a protection connection, so that the service can be switched to the protection connection to ensure normal transmission.
  • Step 304 When the working path of the cross-domain service fails, the saved relative intra-domain protection path is sent to the corresponding node in the domain for the node to establish a protection connection.
  • the embodiment provides a cross-domain service protection method, which uses a multi-domain controller to calculate a protection path of a service, and sends the protection path to a single-domain controller and protects it.
  • the protection path establishes a protection connection, so that the service is switched to the protection path to ensure normal forwarding of the service, and the problem that the related software-defined network technology is used in the multi-domain OTN environment cannot be set in advance to protect the working path, and When the number of domains is large, this method has greatly improved efficiency.
  • the protection method of this embodiment is described in detail below by taking the network domain shown in FIG. 1 as an example.
  • FIG. 1 there is a multi-domain controller, and four single-domain controllers, a single domain controller, and a single domain.
  • Controller 2, single domain controller 3 and single domain controller 4 the control domains of the four single domain controllers are area A, area B, area C, and area D, respectively.
  • the single domain controller is responsible for the path calculation in the local domain.
  • the single domain controller is responsible for the path calculation in the area A, and the single domain controller reports the boundary node in the domain to the multi-domain controller, and the single domain controller will Report the boundary node ID and domain ID in the domain to multiple domains.
  • the controller; its global network topology is shown in Figure 4.
  • the specific implementation steps are as follows, as shown in Figure 5:
  • Step 501 The multi-domain controller sends an OFPT_MULTIPART_REQUET request to the single domain controller to report the inter-domain link information.
  • Step 502 The single domain controller issues OFPT_MULTIPART_REPLY to report the inter-domain link information to the multi-domain controller.
  • Multi-domain controllers generate and maintain inter-domain topology information.
  • the ofp_port structure in the north OFPT_MULTIPART_REPLY extends the node_id (node ID) and the ra_id (domain ID).
  • the node_id can be used to calculate the working path
  • the multi-domain controller adopts the node separation policy to calculate the protection path
  • the ra_id can be used for calculation.
  • the multi-domain controller adopts a domain separation policy to calculate the protection path;
  • Step 503 The multi-domain controller receives the cross-domain S to D service establishment request of the application layer, and calculates the working path of S to D as A-B-C.
  • the multi-domain controller can calculate the working path by using the Dijkstra algorithm, and the multi-domain controller calculates the working path according to the inter-domain topology as S-BN1-BN3-BN5-BN7-D, wherein the routing information includes the domain ID, and when the domain is abstracted as a node,
  • the abstract domain path is ABC, as shown in Figure 7;
  • Step 504 The multi-domain controller uses the domain separation policy to calculate the protection path as A-D-C.
  • the domain A and the domain C are the first-to-tail domain, and the domain ID is B as the avoidance condition of the domain separation.
  • the protection path is S-BN2-BN8-BN9-BN10-D according to the topology after the avoidance.
  • the abstract domain path is an ADC. As shown in Figure 7, if a node or link separation strategy is adopted, the node or link of the working path is taken as a avoidance condition;
  • Step 505 The multi-domain controller initiates an intra-domain path calculation request to the single-domain controllers 1, 2, and 3 according to the working path, and initiates an intra-domain path calculation request to the single-domain controllers 1, 4, and 3 according to the protection path.
  • step 505 can include:
  • Step 5051 The multi-domain controller initiates an S-to-BN1 intra-domain path calculation request to the single-domain controller 1 according to the working path.
  • Step 5052 The multi-domain controller initiates a BN3 to BN5 intra-domain path calculation request to the single domain controller 2 according to the working path.
  • Step 5053 The multi-domain controller initiates a BN7-to-D-domain path calculation request to the single-domain controller 3 according to the working path.
  • Step 5054 The multi-domain controller initiates an S-to-BN2 intra-domain path calculation request to the single-domain controller 1 according to the protection path.
  • Step 5055 The multi-domain controller initiates a BN8 to BN9 intra-domain path calculation request to the single domain controller 4 according to the protection path.
  • Step 5056 The multi-domain controller initiates a BN10 to D domain path calculation request to the single domain controller 3 according to the protection path.
  • Step 506 Each single domain controller returns a path response in each domain to the multi-domain controller
  • Step 507 The end-to-end working path of the multi-domain controller is S-BN1-BN3-BN5-BN7-D (as shown in the thick line of the mark 1 in FIG. 9), and the end-to-end protection path is S-BN2- BN8-BN9-BN10-D (marked 2 thick line portion shown in Figure 9).
  • Step 508 The multi-domain controller establishes an inter-domain working path (BN1-BN3, BN5-BN7), and the multi-domain controller sends a service connection establishment request to the corresponding domain through the flow_mod message according to the end-to-end working and protection path.
  • the domain controller, the service connection establishment request includes: a work path establishment request and a protection path establishment request.
  • the working connection establishment request may include routing information of the working path in the opposite domain
  • the protection connection establishing request may include routing information of the protection path in the relative domain
  • Step 509 The single domain controller receives the service connection establishment request, forwards the working connection establishment request to the corresponding OTN device in the domain, and saves the protection connection establishment request.
  • the single domain controllers 1, 2, 3, 4 receive the service connection establishment request, and the single domain controllers 1, 2, 3 first respectively save the received protection connection establishment request; then the single domain controllers 1, 2 And 3 respectively send a working connection establishment request to the corresponding node device in the respective domain, that is, the OTN device, and the node devices can establish a corresponding working connection according to the received working connection establishment request. At this point, the working connection of the business in each domain is established.
  • This embodiment uses the simplest example to introduce the protection method.
  • the single domain controller 1 sends a working connection establishment request to the node S and the node BN1.
  • the single domain controller 2 transmits a working connection establishment request to the nodes BN3 and BN5, and the single domain controller 3 transmits a working connection establishment request to the nodes BN7 and D.
  • Step 510 The OTN device establishes a working connection according to the working connection establishment request (where the working paths in the domain are established as S-BN1, BN3-BN5, and BN7-D).
  • Step 511 When the working path of the service fails, the single domain controller forwards the saved protection establishment request to the corresponding OTN device in the local domain, and the OTN device establishes a protection connection according to the protection path establishment request.
  • Embodiment 3 is a diagrammatic representation of Embodiment 3
  • the embodiment provides a multi-domain controller, which is applied to a software-defined network of a multi-domain OTN, and includes: an information acquisition module, a calculation module, a request module, and a processing module;
  • the information acquiring module is configured to acquire inter-domain link information.
  • the calculating module is configured to: after receiving the cross-domain service establishment request, calculate an initial working path of the cross-domain service according to the inter-domain link information, and calculate an initial protection path of the cross-domain service according to the inter-domain link information and the initial working path;
  • the requesting module is configured to initiate an intra-domain protection path calculation request to the single domain controller of the corresponding domain according to the initial protection path;
  • the processing module is configured to receive the calculation result of the intra-domain protection path returned by the single domain controller, and obtain the protection path of the cross-domain service according to the calculation result of the intra-domain protection path and the initial protection path.
  • the inter-domain link information includes: an identifier of the domain and an identifier of the border node in the domain.
  • the information acquiring module is configured to acquire inter-domain link information by using OFPT_MULTIPART_REPLY sent by a single domain controller.
  • the calculating module is configured to calculate a shortest initial working path of the cross-domain service according to the inter-domain link information.
  • the above calculation module is set to:
  • the intermediate domain that the initial working path passes is used as a avoidance condition, and the initial protection path of the cross-domain service is calculated according to the avoidance condition and the inter-domain link information;
  • the intermediate node on the initial working path is used as a avoidance condition, and the initial protection path of the cross-domain service is calculated according to the avoidance condition and the inter-domain link information.
  • the multi-domain controller provided in this embodiment can calculate the protection path corresponding to the working path of the cross-domain service.
  • the node device can use the protection path to forward the service in time to ensure normal transmission of the service.
  • the protection path cannot be used to protect the service in time, and the network reliability is improved.
  • Embodiment 4 is a diagrammatic representation of Embodiment 4:
  • this embodiment provides an inter-domain service protection system, which is applied to a multi-domain OTN software definition network, and includes: a multi-domain controller of Embodiment 3 and a single domain controller of multiple OTN domains ( In the figure, n is greater than or equal to 2);
  • the multi-domain controller is configured to obtain a working path of the cross-domain service, where the protection path includes a relative intra-domain protection path, where the intra-domain protection path includes an intra-domain protection path of the domain and an inter-domain protection path of the boundary node within the domain, and The intra-domain protection path is sent to the single domain controller of the corresponding domain;
  • the single domain controller that receives the protection path in the opposite domain is used to save the received relative intra-domain protection path; and when the working path of the cross-domain service fails, the saved relative intra-domain protection path is sent to the corresponding node in the domain for the The node establishes a protected connection.
  • the multi-domain controller sends the intra-domain protection path to the single-domain controller of the corresponding domain by using a flow-mod message.
  • the multi-domain controller is configured to add the relative intra-domain protection path to the extension field in the flow-mod message, and identify the message as an intra-domain working path in the flow-mod message, and send the flow-mod message to the corresponding domain.
  • Single domain controller is configured to add the relative intra-domain protection path to the extension field in the flow-mod message, and identify the message as an intra-domain working path in the flow-mod message, and send the flow-mod message to the corresponding domain.
  • a path acquisition method, a multi-domain controller, and an inter-domain service protection method and system provided by the embodiments of the present invention have the following beneficial effects: when a cross-domain service path fails in a multi-domain OTN SDN system When the protection path is not used in time to protect the business.

Abstract

本发明公开了一种路径获取方法和多域控制器、跨域业务保护方法和系统。本发明的路径获取方法包括：多域控制器获取域间链路信息；多域控制器在接收到跨域业务建立请求后，根据域间链路信息计算出跨域业务的初始工作路径；多域控制器根据上述域间链路信息和初始工作路径计算跨域业务的初始保护路径；多域控制器根据初始保护路径向对应域的单域控制器发起域内保护路径计算请求；多域控制器接收单域控制器返回的域内保护路径计算结果，并根据域内保护路径计算结果和初始保护路径得到跨域业务的保护路径。本发明的方法解决了在多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护的问题。

Description

路径获取方法和多域控制器、跨域业务保护方法和系统 技术领域
本发明涉及网络通信技术领域，尤其涉及一种路径获取方法和多域控制器、跨域业务保护方法和系统。
背景技术
随着网络技术的飞速发展，业界对互联网的发展提出了更高的要求，如何满足用户数量、业务种类、带宽增长等的不断增长，是下一代光网络传输技术亟需解决的问题，而近年来软件定义网络(Software Defined Network，简称为SDN)成为业界研究的热点和重点。SDN通过控制和转发的分离，控制功能集中到控制器(Controllor)上。控制器与某个域中所有的网络设备会话，获悉网络拓扑结构，并从一个无所不知的中心点上对网络进行编程。将SDN运用到光传输网络(Optical Transport Network，简称为OTN)技术领域，可以应对光通道数据单元(Optical Channel Data Unit，简称为ODU)中ODUK、灵活速率光通道数据单元ODUFLEX、光纤信道层(Optical CHannel layer，简称为OCH)等不同交换粒度下的业务流量控制，并可以发挥集中式的计算优势，实现对资源的统一优化调度。
在上述背景下，软件定义网络(SDN)技术越来越成为业界在光网络控制技术领域的关注热点，在OTN多域网络中，通常做法是在每个OTN域内部署一个或多个SDN控制器，其组网架构类似图1所示，每个域内的控制器负责建立并维护本域内的网络视图与物理设备网络的映射关系，并参与本域的路径计算，所述域内控制器称为单域控制器；与所述的多个单域控制器北向相连的是一个多域控制器，多域控制器通过openflow协议与单域控制器通信，可以建立全网网络视图与物理设备网络的域间映射关系，并完成跨域业务连接的域间路径计算，根据跨域域间路径结果完成跨域业务连接的域间配置过程，再向各域的单域控制器发起跨域连接在各域内部的配置请求，各单域控制器完成所述跨域业务在本域的路径计算，根据本域内部的路径计算结果配置整个跨域业务在本域内部的连接部分，并将该连接关系下发至设备层。
目前，为了业务数据包的正常传输，通常需要通过预先分配资源的方法，预先为该业务路径设置保护路径，从而在业务路径发生故障时，快速使用该工作路径对应的保护路径，保证业务的正常传输。但是，在所述SDN OTN多域环境中时，能针对这种情况，目前尚没有解决方案。所以在多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护，从而导致网络的可靠性差。
发明内容
本发明要解决的主要技术问题是，提供一种路径获取方法和多域控制器、跨域业务保护方法和系统，能够解决目前多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使 用保护路径对业务进行保护的问题。
为解决上述技术问题，本发明提供一种路径获取方法，应用于多域OTN软件定义网络中，包括如下步骤：
多域控制器获取域间链路信息，所述域间链路信息包括：域的标识和域内边界节点的标识；
所述多域控制器在接收到跨域业务建立请求后，根据所述域间链路信息计算出所述跨域业务的初始工作路径；
所述多域控制器根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径；
所述多域控制器根据所述初始保护路径向对应域的单域控制器发起域内保护路径计算请求；
所述多域控制器接收所述单域控制器返回的域内保护路径计算结果，并根据所述域内保护路径计算结果和所述初始保护路径得到所述跨域业务的保护路径。
可选地，所述域间链路信息包括：域的标识和域内边界节点的标识。
可选地，所述多域控制器获取域间链路信息的步骤包括：
所述多域控制器通过单域控制器发送的OFPT_MULTIPART_REPLY获取所述域间链路信息。
可选地，所述根据所述域间链路信息计算出所述跨域业务的初始工作路径的步骤包括：
根据所述域间链路信息计算出所述跨域业务的最短的初始工作路径。
可选地，所述多域控制器根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径的步骤包括：
所述多域控制器将所述初始工作路径经过的中间域作为避让条件，根据所述避让条件和所述域间链路信息计算所述跨域业务的初始保护路径；
或者
所述多域控制器将所述初始工作路径上的中间节点作为避让条件，根据所述避让条件和所述域间链路信息计算所述跨域业务的初始保护路径。
同样为了解决上述技术问题，本发明还提供了一种跨域业务保护方法，应用于多域OTN软件定义网络中，包括如下步骤：
利用上述任一项所述的路径获取方法得到所述跨域业务的保护路径，所述保护域路径包括相对域内保护路径，所述相对域内保护路径包括本域的域内保护路径及本域内边界节点的 域间保护路径，
所述多域控制器将所述相对域内保护路径发送给对应域的单域控制器；
接收到相对域内保护路径的单域控制器保存所述相对域内保护路径；
当所述跨域业务的工作路径发生故障时，将保存的所述相对域内保护路径发送给本域内对应的节点以供节点建立保护连接。
可选地，所述多域控制器将所述相对域内保护路径发送给对应域的单域控制器的步骤包括：
所述多域控制器通过flow-mod消息将所述相对域内保护路径发送给对应域的单域控制器。
可选地，所述多域控制器通过flow-mod消息将所述相对域内保护路径发送给对应域的单域控制器的步骤包括：
所述多域控制器将所述相对域内保护路径添加到flow-mod消息中的扩展字段中，且在flow-mod消息中标识该消息为相对域内工作路径，将所述flow-mod消息发送给对应域的单域控制器。
同样为了解决上述的技术问题，本发明还提供了一种多域控制器，应用于多域OTN的软件定义网络中，包括：信息获取模块、计算模块、请求模块和处理模块；
所述信息获取模块设置为获取域间链路信息；
所述计算模块设置为在接收到跨域业务建立请求后，根据所述域间链路信息计算出所述跨域业务的初始工作路径，根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径；
所述请求模块设置为根据所述初始保护路径向对应域的单域控制器发起域内保护路径计算请求；
所述处理模块设置为接收所述单域控制器返回的域内保护路径计算结果，并根据所述域内保护路径计算结果和所述初始保护路径得到所述跨域业务的保护路径。
同样为了解决上述的技术问题，本发明还提供了一种跨域业务保护系统，应用于多域OTN软件定义网络中，包括：如上所述的多域控制器和多个OTN域的单域控制器；
所述多域控制器设置为得到所述跨域业务的工作路径，所述保护路径包括相对域内保护路径，所述相对域内保护路径包括本域的域内保护路径及本域内边界节点的域间保护路径，和将相对域内保护路径发送给对应域的单域控制器；
接收到相对域内保护路径的单域控制器设置为保存接收到的相对域内保护路径；以及当所述跨域业务的工作路径发生故障时，将保存的所述相对域内保护路径发送给本域内对应的 节点以供该节点建立保护连接。
本发明的有益效果是：
本发明提供了一种路径获取方法和多域控制器、跨域业务保护方法和系统，可以使得在多域OTN SDN系统中，当跨域业务路径发生故障时，可以采用保护路径对业务进行保护；具体地，本发明提供了一种路径获取方法，应用于多域OTN的软件定义网络中，包括：多域控制器获取域间链路信息；所述多域控制器在接收到跨域业务建立请求后，根据所述域间链路信息计算出所述跨域业务的初始工作路径；所述多域控制器根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径；所述多域控制器根据所述初始保护路径向对应域的单域控制器发起域内保护路径计算请求；所述多域控制器接收所述单域控制器返回的域内保护路径计算结果，并根据所述域内保护路径计算结果和所述初始保护路径得到所述跨域业务的保护路径；本发明的路径获取方法可以通过多域控制器来计算出跨域业务的工作路径对应的保护路径；使得在跨域业务的工作路径发生故障时节点设备可以及时采用保护路径进行业务转发，保证了业务正常传输；解决了目前多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护的问题，以及提高了网络可靠性。
附图说明
图1为一种多域OTN软件定义网络的架构图示意；
图2为本发明实施例一提供的一种路径获取方法的流程示意图；
图3为本发明实施例二提供的一种跨域业务保护方法的流程示意图；
图4为本发明实施例二提供的一种多域OTN的拓扑图示意；
图5为本发明实施例二提供的另一种跨域业务保护方法的流程示意图；
图6为本发明实施例二提供的一种ofp_port结构体扩展示意图；
图7为本发明实施例二提供的一种计算保护路径的域抽象图示意图；
图8为本发明实施例二提供的一种多域控制器向单域控制器发起域内路径计算请求的过程示意图；
图9为本发明实施例二提供的一种跨域业务的工作路径和保护路径的示意图；
图10为本发明实施例三提供的一种多域控制器的结构示意图；
图11为本发明实施例四提供的一种跨域业务保护系统的流程示意图。
具体实施方式
下面通过具体实施方式结合附图对本发明作进一步详细说明。
实施例一：
考虑到目前多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护的问题；如图2所示，本实施例提供了一种路径获取方法，应用于多域OTN SDN中，包括如下步骤：
步骤201：多域控制器获取域间链路信息。
可选地，本步骤中域间链路信息包括：域的标识和域内边界节点的标识。
可选地，实现本步骤201的过程包括：
多域控制器向单域控制器发送OFPT_MULTIPART_REQUET请求上报域间链路信息；
单域控制器向多域控制器发送OFPT_MULTIPART_REPLY上报域间链路信息。
本实施例中域间链路信息可以包括：域ID、域内边界节点ID和端口ID。
优选地，本实施例中通过OFPT_MULTIPART_REPLY中的ofp_port将域间链路信息上报给多域控制器。例如在OFPT_MULTIPART_REPLY中的ofp_port扩展字段来携带域ID和边界节点ID。
步骤202：多域控制器在接收到跨域业务建立请求后，根据域间链路信息计算出跨域业务的初始工作路径。
本实施例初始工作路径包括域的边界节点、以及跨域业务的源节点和目的节点。
可选地，本步骤中多域控制器可以根据上报的域间链路信息生成域间拓扑信息或者节点间拓扑信息，然后根据拓扑信息、预设路径算法、以及业务的源节点和目的节点计算出所需的工作路径。例如按照源节点和目的节点在拓扑图中确定一条所需的路径，此路径即为工作路径。
优选地，本实施例中初始工作路径可为最短的初始工作路径；此时预设路径算法可以最短路径算法，例如Dijkstra算法。
步骤203：多域控制器根据域间链路信息和初始工作路径计算跨域业务的初始保护路径。
本步骤可以根据上述域间链路信息和初始工作路径计算出跨域业务的初始保护路径，具体地，根据生成的拓扑信息和初始工作路径计算出初始保护路径。
本步骤可以采用两种策略来计算初始保护路径：
一种策略为：多域控制器将初始工作路径经过的中间域作为避让条件，根据避让条件和域间链路信息计算跨域业务的初始保护路径。
可选地，将出初始工作路径经过的中间域作为避让条件，然后根据避开中间域后的拓扑信息计算出对应的初始保护路径。
另一种策略为：多域控制器将初始工作路径上的中间节点作为避让条件，根据该避让条件和域间链路信息计算跨域业务的初始保护路径。
可选地，将初始工作路径经过的中间节点作为避让条件，然后根据避开节点后的拓扑信息计算出对应的初始保护路径。
本实施例中初始保护路径包括域的边界节点、业务的源节点和业务的目的节点。
步骤204：多域控制器根据初始保护路径向对应域的单域控制器发起域内保护路径计算请求。
对于跨域业务的工作路径和保护路径来说，其基本上由域间路径和域内路径构成，本步骤之前仅仅确定了域间路径和大致的域内路径，例如仅仅知道业务的源节点和与源节点所在同一个域的边界节点之间的大致保护路径。所以，为了能够得到完整的保护路径，还需要获取具体的域内保护路径；本步骤204即是实现这个目的所需过程中的一个过程。
可选地，本步骤包括：
首先确定初始工作路径经过的域，然后获取同时包括源节点和边界节点的域、同时包括两个边界节点域、同时包括目的节点和边界节点的域；
接着向这些域对应的单域控制器发起域内保护路径计算请求；
这些单域控制器计算同一域中源节点和边界节点之间的保护路径，或者计算同一域内两个边界节点之间的保护路径，或者计算同一域内目的节点和边界节点之间的保护路径；最后这些单域控制器将计算结果返回给多域控制器。
同样，当需要获取跨域业务工作路径也可采用上述的过程：根据初始工作路径向对应域的单域控制器发起域内工作路径计算请求；多域控制器接收单域控制器返回的域内工作路径计算结果和域内保护路径计算结果；然后根据域内工作路径计算结果和初始工作路径得到跨域业务的工作路径(采用拼接的方式获取最终的工作路径)。
步骤205：多域控制器接收单域控制器返回的域内保护路径计算结果，并根据该域内保护路径计算结果和初始保护路径得到跨域业务的保护路径。
本步骤中根据域内保护路径计算结果和初始保护路径得到跨域业务的保护路径的过程可以包括：将域内保护路径计算结果拼接到初始保护路径中从而得到最终的保护路径。
本实施例提供的路径获取方法，可以通过多域控制器来计算出跨域业务的保护路径；使得在跨域业务的工作路径发生故障时节点设备可以及时采用保护路径进行业务转发，保证了业务正常传输；解决了目前多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护的问题，以及提高了网络可靠性。
实施例二：
如图3所示，本实施例提供了一种跨域业务保护方法，应用于多域OTN软件定义网络中，包括如下步骤：
步骤301：利用实施例一的路径获取方法得到跨域业务的保护路径，该保护路径包括相对域内保护路径，相对域内保护路径包括本域的域内保护路径及本域内边界节点的域间保护路径。
步骤302：多域控制器将相对域内保护路径发送给对应域的单域控制器。
本步骤中域内保护路径可以包括相对域内工作路径的路由信息和相对域内保护路径的路由信息。
可选地，本实施例可以通过业务建立请求消息将相对域内保护路径发送给对应域的单域控制器，其中业务建立请求消息为flow_mod消息，即通过flow-mod消息将相对域内保护路径发送给对应域的单域控制器。
优选地，本步骤可以将相对域内保护路径添加到flow-mod消息中的扩展字段中，且在flow-mod消息中标识该消息为相对域内保护路径，将flow-mod消息发送给对应域的单域控制器，从而实现将相对域内保护路径发送给对应域的单域控制器。
同样，如果在建立工作路径的过程中，也可以采用上述发送相对域内保护路径的方式将相对域内工作路径发送给对应域的单域控制器。
本实施例中对应域的单域控制器包括保护路径经过的域的单域控制器。
步骤303：接收到相对域内保护路径的单域控制器保存相对域内保护路径。
本步骤保存相对域内保护路径的目的是：当工作路径发生故障时，可以将保存的相对域内保护路径发送给对应的节点建立保护连接，使得业务可以切换至保护连接上，保证业务正常传输。
步骤304：当跨域业务的工作路径发生故障时，将保存的相对域内保护路径发送给本域内对应的节点以供该节点建立保护连接，。
本实施例提供了一种跨域业务保护方法，通过多域控制器来计算出业务的保护路径，并将保护路径发到单域控制器并保护，当工作路径发生故障时，能够及时根据保存的保护路径建立保护连接，使业务切换至保护路径上保证业务正常转发，解决了在相关的软件定义网络技术运用在多域OTN环境中，无法预先设置保护路径对工作路径进行保护的问题，并且当域的数量多时，这种方法在效率有了很大的提高。
下面以图1所示的网络域为例来详细介绍本实施例的保护方法，在图1中，有一个多域控制器，还有四个单域控制器，单域控制器一、单域控制器二、单域控制器三和单域控制器四，这四个单域控制器的控制域分别为区域A、区域B、区域C、区域D。其中单域控制器负责本域内的路径计算，例如单域控制器一负责区域A内的路径计算，且单域控制器会上报本域内的边界节点到多域控制器，且单域控制器会上报本域内的边界节点标识和域标识到多域 控制器；其全局网络拓扑如图4所示，具体实施步骤如下，如图5所示：
步骤501：多域控制器发出OFPT_MULTIPART_REQUET请求单域控制器上报域间链路信息。
步骤502：单域控制器发出OFPT_MULTIPART_REPLY向多域控制器上报域间链路信息。
多域控制器生成并维护域间拓扑信息。其中如图6所示，北向OFPT_MULTIPART_REPLY中ofp_port结构体扩展node_id(节点ID)和ra_id(域ID)，node_id可用于计算工作路径后，多域控制器采取节点分离策略计算保护路径，ra_id可用于计算工作路径后，多域控制器采取域分离策略计算保护路径；
步骤503：多域控制器收到应用层的跨域S到D业务建立请求，计算S到D的工作路径为A-B-C。
多域控制器可采用Dijkstra算法计算工作路径，多域控制器根据域间拓扑计算工作路径为S-BN1-BN3-BN5-BN7-D，其中路由信息包含域ID，将域抽象为节点时，抽象域路径为A-B-C，如图7所示；
步骤504：多域控制器采用域分离策略计算保护路径为A-D-C。
其中域A和域C为首尾域不能作为避开条件，将域ID为B作为域分离的避开条件，根据避开后的拓扑计算保护路径为S-BN2-BN8-BN9-BN10-D，将域抽象为节点时，抽象域路径为A-D-C，如图7所示，若采用节点或链路分离策略，则将工作路径的节点或链路作为避开条件；
步骤505：多域控制器根据工作路径分别向单域控制器1、2、3发起域内路径计算请求；根据保护路径分别向单域控制器1、4、3发起域内路径计算请求。
如图8所示，步骤505可以包括：
步骤5051：多域控制器根据工作路径向单域控制器1发起S到BN1域内路径计算请求；
步骤5052：多域控制器根据工作路径向单域控制器2发起BN3到BN5域内路径计算请求；
步骤5053：多域控制器根据工作路径向单域控制器3发起BN7到D域内路径计算请求；
步骤5054：多域控制器根据保护路径向单域控制器1发起S到BN2域内路径计算请求；
步骤5055：多域控制器根据保护路径向单域控制器4发起BN8到BN9域内路径计算请求；
步骤5056：多域控制器根据保护路径向单域控制器3发起BN10到D域内路径计算请求；
步骤506：各单域控制器返回各域内路径应答到多域控制器；
步骤507：多域控制器拼接端到端工作路径为S-BN1-BN3-BN5-BN7-D(如图9所示的标记1粗线部分)，和端到端保护路径为S-BN2-BN8-BN9-BN10-D(如图9所示的标记2粗线部分)。
步骤508：多域控制器建立域间工作路径(BN1-BN3、BN5-BN7)，并且多域控制器根据端到端的工作和保护路径，通过flow_mod消息下发业务连接建立请求到对应域的单域控制器，业务连接建立请求包括：工作路径建立请求和保护路径建立请求。
可选地，利用flow_mod消息中的pad位或新扩展位表示工作路径或保护路径，设置pad＝0为工作路径，pad＝1为保护路径。
本步骤工作连接建立请求可以包括相对域内工作路径的路由信息，保护连接建立请求可以包括相对域内保护路径的路由信息。
步骤509：单域控制器收到业务连接建立请求，向域内对应的OTN设备转发工作连接建立请求，并保存保护连接建立请求。
可选地，单域控制器1、2、3、4接收到业务连接建立请求，单域控制器1、2、3首先各自保存接收到的保护连接建立请求；然后单域控制器1、2、3分别向各自域内对应的节点设备即OTN设备发送工作连接建立请求，这些节点设备则可以根据接收到的工作连接建立请求建立相应的工作连接。此时即建立完业务在各域内的工作连接。
本实施例采用最简单的例子来介绍保护方法，其中域A中节点S与节点BN1之间没有中间节点，所以本实施例中单域控制器1将工作连接建立请求发送给节点S和节点BN1，单域控制器2将工作连接建立请求发送给节点BN3和BN5，单域控制器3将工作连接建立请求发送给节点BN7和D。但是在实际应用中节点S与节点BN1之间是存在中间节点的，因此，在建立域内工作连接时，还需要将工作连接建立请求发给这些节点来建立业务在节点S与节点BN1之间的工作连接。同理在建立保护连接时也是一样，就不在赘述了。
步骤510：OTN设备根据工作连接建立请求建立工作连接(这里建立域内工作路径为S-BN1、BN3-BN5、BN7-D)。
步骤511：当业务的工作路径发生故障时，单域控制器将保存的保护建立请求转发给本域内对应的OTN设备，由OTN设备根据保护路径建立请求建立保护连接。
此时，即将业务传输切换到保护路径以达到业务不中断的目的。
实施例三：
如图10所示，本实施例提供了一种多域控制器，应用于多域OTN的软件定义网络中，包括：信息获取模块、计算模块、请求模块和处理模块；
上述信息获取模块设置为获取域间链路信息；
上述计算模块设置为在接收到跨域业务建立请求后，根据域间链路信息计算出跨域业务的初始工作路径，根据域间链路信息和初始工作路径计算跨域业务的初始保护路径；
上述请求模块设置为根据初始保护路径向对应域的单域控制器发起域内保护路径计算请求；
上述处理模块设置为接收单域控制器返回的域内保护路径计算结果，并根据域内保护路径计算结果和初始保护路径得到跨域业务的保护路径。
优选地，上述域间链路信息包括：域的标识和域内边界节点的标识。
优选地，上述信息获取模块设置为通过单域控制器发送的OFPT_MULTIPART_REPLY获取域间链路信息
优选地，上述计算模块设置为根据域间链路信息计算出跨域业务的最短的初始工作路径。
优选地，上述计算模块设置为：
将初始工作路径经过的中间域作为避让条件，根据避让条件和域间链路信息计算跨域业务的初始保护路径；
或者
将初始工作路径上的中间节点作为避让条件，根据避让条件和域间链路信息计算跨域业务的初始保护路径。
本实施例提供的多域控制器可以计算出跨域业务的工作路径对应的保护路径；使得在跨域业务的工作路径发生故障时节点设备可以及时采用保护路径进行业务转发，保证了业务正常传输；解决了目前多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护的问题，以及提高了网络可靠性。
实施例四：
如图11所示，本实施例提供了一种跨域业务保护系统，应用于多域OTN软件定义网络中；包括：实施例三的多域控制器和多个OTN域的单域控制器(图中n大于等于2)；
上述多域控制器设置为得到跨域业务的工作路径，上述保护路径包括相对域内保护路径，该相对域内保护路径包括本域的域内保护路径及本域内边界节点的域间保护路径，和将相对域内保护路径发送给对应域的单域控制器；
接收到相对域内保护路径的单域控制器用于保存接收到的相对域内保护路径；以及当跨域业务的工作路径发生故障时，将保存的相对域内保护路径发送给本域内对应的节点以供该节点建立保护连接。
优选地，多域控制器通过flow-mod消息将域内保护路径发送给对应域的单域控制器。
优选地，多域控制器用于将相对域内保护路径添加到flow-mod消息中的扩展字段中，且在flow-mod消息中标识该消息为域内工作路径，将flow-mod消息发送给对应域的单域控制器。
以上内容是结合具体的实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。
工业实用性
如上所述，本发明实施例提供的一种路径获取方法和多域控制器、跨域业务保护方法和系统具有以下有益效果：解决了在多域OTN SDN系统中，当跨域业务路径发生故障时，无法及时使用保护路径对业务进行保护的问题。

Claims (10)

  1. 一种路径获取方法，应用于多域光传输网络OTN软件定义网络中，包括如下步骤：
    多域控制器获取域间链路信息；
    所述多域控制器在接收到跨域业务建立请求后，根据所述域间链路信息计算出所述跨域业务的初始工作路径；
    所述多域控制器根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径；
    所述多域控制器根据所述初始保护路径向对应域的单域控制器发起域内保护路径计算请求；
    所述多域控制器接收所述单域控制器返回的域内保护路径计算结果，并根据所述域内保护路径计算结果和所述初始保护路径得到所述跨域业务的保护路径。
  2. 如权利要求1所述的方法，其中，所述域间链路信息包括：域的标识和域内边界节点的标识。
  3. 如权利要求2所述的方法，其中，所述多域控制器获取域间链路信息的步骤包括：
    所述多域控制器通过单域控制器发送的OFPT_MULTIPART_REPLY获取所述域间链路信息。
  4. 如权利要求1-3任一项所述的方法，其中，所述根据所述域间链路信息计算出所述跨域业务的初始工作路径的步骤包括：
    根据所述域间链路信息计算出所述跨域业务的最短的初始工作路径。
  5. 如权利要求1-3任一项所述的方法，其中，所述多域控制器根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径的步骤包括：
    所述多域控制器将所述初始工作路径经过的中间域作为避让条件，根据所述避让条件和所述域间链路信息计算所述跨域业务的初始保护路径；
    或者
    所述多域控制器将所述初始工作路径上的中间节点作为避让条件，根据所述避让条件和所述域间链路信息计算所述跨域业务的初始保护路径。
  6. 一种跨域业务保护方法，应用于多域光传输网络OTN软件定义网络中，包括如下步骤：
    利用如权利要求1-5任一项所述的路径获取方法得到所述跨域业务的保护路径，所述保护路径包括相对域内保护路径，所述相对域内保护路径包括本域的域内保护路径及本域内边界节点的域间保护路径；
    所述多域控制器将所述相对域内保护路径发送给对应域的单域控制器；
    接收到相对域内保护路径的单域控制器保存所述相对域内保护路径；
    当所述跨域业务的工作路径发生故障时，将保存的所述相对域内保护路径发送给本域内对应的节点以供节点建立保护连接。
  7. 如权利要求6所述的跨域业务保护方法，其中，所述多域控制器将所述相对域内保护路径发送给对应域的单域控制器的步骤包括：
    所述多域控制器通过flow-mod消息将所述相对域内保护路径发送给对应域的单域控制器。
  8. 如权利要求7所述的跨域业务保护方法，其中，所述多域控制器通过flow-mod消息将所述相对域内保护路径发送给对应域的单域控制器的步骤包括：
    所述多域控制器将所述相对域内保护路径添加到flow-mod消息中的扩展字段中，且在flow-mod消息中标识该消息为相对域内工作路径，将所述flow-mod消息发送给对应域的单域控制器。
  9. 一种多域控制器，应用于多域光传输网络OTN的软件定义网络中，包括：信息获取模块、计算模块、请求模块和处理模块；
    所述信息获取模块设置为获取域间链路信息；
    所述计算模块设置为在接收到跨域业务建立请求后，根据所述域间链路信息计算出所述跨域业务的初始工作路径，根据所述域间链路信息和所述初始工作路径计算所述跨域业务的初始保护路径；
    所述请求模块设置为根据所述初始保护路径向对应域的单域控制器发起域内保护路径计算请求；
    所述处理模块设置为接收所述单域控制器返回的域内保护路径计算结果，并根据所述域内保护路径计算结果和所述初始保护路径得到所述跨域业务的保护路径。
  10. 一种跨域业务保护系统，应用于多域光传输网络OTN软件定义网络中，包括：如权利要求9所述的多域控制器和多个OTN域的单域控制器；
    所述多域控制器设置为得到所述跨域业务的工作路径，所述保护路径包括相对域内保护路径，所述相对域内保护路径包括本域的域内保护路径及本域内边界节点的域间保护路径，和将相对域内保护路径发送给对应域的单域控制器；
    接收到相对域内保护路径的单域控制器设置为保存接收到的相对域内保护路径；以及当所述跨域业务的工作路径发生故障时，将保存的所述相对域内保护路径发送给本域内对应的节点以供该节点建立保护连接。
PCT/CN2015/088656 2014-11-14 2015-08-31 路径获取方法和多域控制器、跨域业务保护方法和系统 WO2016074522A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410649931.4 2014-11-14
CN201410649931.4A CN105656654A (zh) 2014-11-14 2014-11-14 路径获取方法和多域控制器、跨域业务保护方法和系统

Publications (1)

Publication Number Publication Date
WO2016074522A1 true WO2016074522A1 (zh) 2016-05-19

Family

ID=55953713

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/088656 WO2016074522A1 (zh) 2014-11-14 2015-08-31 路径获取方法和多域控制器、跨域业务保护方法和系统

Country Status (2)

Country Link
CN (1) CN105656654A (zh)
WO (1) WO2016074522A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109565468A (zh) * 2016-06-06 2019-04-02 瑞典爱立信有限公司 确定通信网络中的路径
US11916786B2 (en) 2021-08-13 2024-02-27 Cisco Technology, Inc. Distributed routing controllers for multi-region SDWAN

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108183810B (zh) * 2016-12-08 2019-06-04 中兴通讯股份有限公司 Sdn架构下多业务的并行恢复方法、装置及系统
CN109639499A (zh) * 2017-12-29 2019-04-16 中国联合网络通信有限公司广东省分公司 一种基于sdn的多厂家otn业务配置端到端互通系统及方法
CN109996130A (zh) * 2018-01-02 2019-07-09 中国移动通信有限公司研究院 基于sdn的光传送网保护恢复方法、设备及存储介质
CN110572323B (zh) * 2018-05-16 2022-03-22 中兴通讯股份有限公司 软件定义网络的路由获取方法、装置及存储介质
CN111836003B (zh) * 2019-04-16 2022-12-23 浙江宇视科技有限公司 一种基于sdn的媒体流链路智能选择方法及装置
CN113507475B (zh) * 2021-07-14 2022-12-23 杭州数梦工场科技有限公司 跨域访问方法和装置
CN113747277B (zh) * 2021-08-31 2023-05-12 中国联合网络通信集团有限公司 路径确定方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101715149A (zh) * 2009-07-21 2010-05-26 北京邮电大学 一种多层多域分布式光网络并行跨域故障恢复方法和装置
CN102201993A (zh) * 2011-05-25 2011-09-28 电子科技大学 一种跨域工作路径及其保护路径的计算方法
CN103532615A (zh) * 2012-07-06 2014-01-22 中兴通讯股份有限公司 一种路径计算方法、实现该方法的节点和路径计算单元
CN103634134A (zh) * 2012-08-24 2014-03-12 中兴通讯股份有限公司 跨域保护互通方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101715149A (zh) * 2009-07-21 2010-05-26 北京邮电大学 一种多层多域分布式光网络并行跨域故障恢复方法和装置
CN102201993A (zh) * 2011-05-25 2011-09-28 电子科技大学 一种跨域工作路径及其保护路径的计算方法
CN103532615A (zh) * 2012-07-06 2014-01-22 中兴通讯股份有限公司 一种路径计算方法、实现该方法的节点和路径计算单元
CN103634134A (zh) * 2012-08-24 2014-03-12 中兴通讯股份有限公司 跨域保护互通方法及系统

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109565468A (zh) * 2016-06-06 2019-04-02 瑞典爱立信有限公司 确定通信网络中的路径
CN109565468B (zh) * 2016-06-06 2022-07-01 瑞典爱立信有限公司 确定通信网络中的路径
US11962486B2 (en) 2016-06-06 2024-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Determining a path in a communication network
US11916786B2 (en) 2021-08-13 2024-02-27 Cisco Technology, Inc. Distributed routing controllers for multi-region SDWAN

Also Published As

Publication number Publication date
CN105656654A (zh) 2016-06-08

Similar Documents

Publication Publication Date Title
WO2016074522A1 (zh) 路径获取方法和多域控制器、跨域业务保护方法和系统
RU2651149C2 (ru) Sdn-контроллер, система центра обработки данных и способ маршрутизируемого соединения
US9509522B2 (en) Forwarding multicast data packets
EP3038303B1 (en) Establishment method and device of a cross-domain path
US10826722B2 (en) Controller based service policy mapping to establish different tunnels for different applications
RU2645296C2 (ru) Маршрутизация услуг "точка - много точек" в многодоменной сети
KR102503516B1 (ko) 클록 동기화 토폴로지를 갱신하는 방법, 클록 동기화 경로를 결정하는 방법, 및 기기
EP3427448B1 (en) Pcep extension for pcecc support of distributed computing, multiple services, and inter-domain routing
CN104301812B (zh) 一种光网络系统和网络功能虚拟化方法
CN105282028A (zh) 一种报文传输方法、节点及路径管理服务器
CN105827529B (zh) 一种路径建立方法及控制器
EP3131239B1 (en) Method and apparatus for path establishment
RU2011119536A (ru) Способ применения экземпляра службы к сети mpls (варианты) и сеть mpls
JP2013510459A (ja) 分離的なパス計算アルゴリズム
KR20120055674A (ko) 멀티레이어 네트워크 중 포워딩 인접의 속성 상속 방법 및 상응한 멀티레이어 네트워크
WO2016165139A1 (zh) 一种虚拟网络的故障恢复方法和装置
WO2015035616A1 (zh) 跨网通信方法及装置
US10666562B2 (en) Network path computation method, apparatus, and system
US20130336117A1 (en) Distributed processing scheme to support ieee 1588 ptp over multiple ports spanning a lag
US20160156523A1 (en) Method and System for Network Topology
CN104618235B (zh) 一种跨层建立不共路路径的方法及装置
CN106330701B (zh) 环形组网的快速重路由方法及装置
US11438420B2 (en) Method and device for establishing multi-domain multi-layer connectivity service
US11290372B2 (en) Method and device for establishing multi-domain dual-home path
JPWO2017164068A1 (ja) トランスポートネットワーク制御装置、通信システム、転送ノードの制御方法及びプログラム

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15859521

Country of ref document: EP

Kind code of ref document: A1