Architecture system and implementation method of hierarchical software defined network controllerTechnical Field
The invention relates to a controller technology of a Software Defined Network (SDN) in an Optical Transport Network (OTN), in particular to an architecture system of a level Software Defined Network controller under a multi-domain OTN scene and an implementation method thereof.
Background
With the advent of the cloud network era, the industry has put higher demands on the development of the internet. How to meet the continuous increase of the number of users, the types of services, the bandwidth requirements and the like and how to meet the real-time dynamic fetching of service flow by the users is a main problem to be solved urgently by the next generation optical network transmission technology serving as a core bearing technology; it is not difficult to find out how to realize the on-demand service and the plug-and-play by taking users as the guide, which are key factors for solving the problems and are also the operation and maintenance characteristics which the next generation optical network must have, namely the cloud characteristic of the optical network.
Under the above background, the technical route of the next-generation software for flexibly controlling the optical network is becoming a focus of the industry in the technical field of optical network control. Currently, SDN technology is widely recognized as an ideal approach along the route to support this technology. SDN is a word created by Kate Greene, proposed in about 2009, with the following main features:
● on the basis of technical development, the advantages of centralized and distributed control technologies are fused, and the direction of the intelligent control is changed from the intelligence of the concerned network equipment to the centralized intelligent control provided for the upper-layer users in the form of cloud.
● in the form of a device, separation of the control plane from the transport plane is achieved.
The main advantages of the application of SDN to the OTN technology field are as follows:
● has the greatest advantage that it can adopt independent controller technology to deal with traffic flow control under different switching granularity technical conditions such as ODUk, ODUFlex, OCH, etc.
● can meet the needs of users for network editing to achieve flexibility in the way network devices are used, operated and sold, and enable users to obtain desired service functions at a faster rate without waiting for the device vendor to incorporate those functions into proprietary production equipment.
● SDN enables virtualized management of optical network resources, the range of network devices for which virtualized management can cover all OTN products.
● can exert the advantage of centralized computation to realize uniform and optimized scheduling of resources.
● can obtain the resource information of the whole network in time, which is convenient for developing the resource management and maintenance function.
As shown in fig. 1, the figure is based on the SDN network architecture generally agreed in the industry at present, and shows the future SDN network architecture facing OTN technology.
The framework mainly comprises: the OTN Application Layer (OTN Application Layer), the OTN network virtual Layer (OTN virtualization Layer), the OTN Controller Layer (OTN Controller Layer) and the OTN equipment Layer (OTN device Layer) are four layers in total. Wherein,
OTN application layer: the user can define the OTN network model by compiling a simple control program according to the self requirement; the user can initiate an operation (including establishing, deleting, modifying, inquiring and the like) request for OTN service connection on the network model defined by the user.
OTN virtual layer: all abstract network models defined by a user are sorted and analyzed, and finally mapped into an OTN whole network view.
OTN controller layer: and establishing a mapping relation between the whole network view and the physical equipment network, realizing intelligent control on service connection in the whole network view according to a service request issued by a user, and issuing finally formed service connection configuration to DXC and OXC table items on corresponding equipment nodes through an OpenFlow or PCEP (personal communications protocol) extension protocol.
OTN equipment layer: and each equipment node executes the service scheduling function of the node according to the DXC and OXC table entry records of the equipment node.
Under multi-domain OTN network scenario conditions, it is a common practice to deploy one or more OTN SDN controllers within each OTN domain, respectively. The networking architecture is similar to that shown in fig. 2. The SDN network architecture thus configured is mainly characterized as follows:
● generation and maintenance of network topology
The SDN controller in each domain is only responsible for establishing and maintaining the mapping relation between the network view of the domain and the physical equipment network; the SDN controllers in different domains do not notify each other about the contents of the network view, the physical device network, the mapping relation between the network view and the physical device network and the like in the domain.
● routing function
The SDN controller of the local domain only participates in the computation of the local domain service path or the computation of the path of the part in the local domain crossing the multi-domain service path. And for cross-domain service connection, determining a domain sequence in an assignment mode.
● service configuration function
The SDN controller of the local domain only participates in the assignment of the local domain service connection or the cross-domain service connection in the local domain according to the calculation result of the service path; the configured content includes, but is not limited to, the label, bandwidth, etc. resources associated with the service connection.
For the control of cross-domain end-to-end service connections, the problem of configuration of the cross-domain service connections in the inter-domain part needs to be solved by RSVP-TE signaling protocol.
The network architecture can meet the demand-based use and unified scheduling of the whole network resources in a simple network topology, such as the condition that the number of OTN network domains is small and the number of nodes in the network domains is not large. However, in a complex multi-domain networking scenario, especially in order to meet the requirements of a future cloud optical network for uniform scheduling of mass resources, the problem that cannot be solved by the single-domain SDN controller network architecture is encountered.
● generation and maintenance of network topology
The mapping relationship between the multi-domain network view and the global physical device network cannot be formed, and further, network topology information cannot be provided for the user-defined optimal scheduling of the end-to-end service connection in the global network range.
● routing function
The calculation function of the inter-domain path can not be provided for the end-to-end cross-domain service connection according to the topology view of the global network, so that the inter-domain route of the end-to-end cross-domain service connection can only be obtained through manual assignment; the real full network resource optimization algorithm cannot be realized.
● service configuration function
Resource reservation and allocation of cross-domain service connection in an inter-domain part need to be realized by running an RSVP-TE protocol between SDN controllers, so that processing efficiency and response speed of cross-domain service connection control are affected.
Under the batch processing operation condition of cross-domain service connection, resource reservation and allocation are carried out between domains by adopting RSVP-TE protocol, and asynchronous (sending of PATH message of next service connection, no need of waiting for RESV successful response of last service connection) sending process of signaling between multiple service connections is caused, so that success rate of multi-service connection operation is reduced.
Due to factors such as inter-domain link resource conflict of the passed intermediate domain, the inter-domain signaling process of the connection of multiple homologous and non-homologous homoclinic services fails.
Disclosure of Invention
The technical problem to be solved by the present invention is to provide a hierarchical software defined network controller architecture system and an implementation method thereof, so as to solve the network architecture defect caused by the fact that SDN controllers of different domains cannot notify each other under the condition of multi-domain OTN in the prior art.
In order to solve the technical problem, the present invention provides an architecture system of a hierarchical software defined network controller, which is applied to a multi-domain Optical Transport Network (OTN), wherein a Software Defined Network (SDN) Optical Transport Network (OTN) controller in the system includes a parent SDN OTN controller and one or more child SDNOTN controllers connected to the parent SDN OTN controller;
the parent SDN OTN controller is used for establishing an inter-domain mapping relation between a full-network view and a physical device network according to full-network topology information and sending a mapping processing request of the full-network view and the physical device network in each domain to each child SDNOTN controller;
the child SDN OTN controller is used for establishing a mapping relation between a full-network view and a physical device network in the domain according to the mapping processing request in the domain received from the parent SDN OTN controller.
Further, the system can also have the following characteristics:
the parent SDN OTN controller is further configured to execute configuration of cross-domain end-to-end service connections between domains, initiate a configuration processing request of cross-domain or single-domain end-to-end service connections inside each domain to each child SDN OTN controller, and notify each child SDNOTN controller of a processing result of inter-domain configuration of cross-domain service connections, where the configuration at least includes one of the following operation processes: creating, deleting, inquiring and modifying attributes;
the sub-SDN OTN controller is further configured to execute configuration of an end-to-end service connection across domains or a single domain within the local domain after receiving the configuration processing request.
Further, the system can also have the following characteristics:
the parent SDN OTN controller is further used for executing path calculation of cross-domain end-to-end service connection among domains, starting a path calculation request of cross-domain or single-domain end-to-end service connection inside each domain to each child SDN OTN controller, and notifying each child SDN OTN controller of a processing result of inter-domain path calculation of cross-domain service connection;
the sub-SDN OTN controller is used for executing path calculation of cross-domain or single-domain end-to-end service connection in each domain.
Further, the system can also have the following characteristics:
the child SDN OTN controller is further configured to receive link information between nodes and/or ports from an OTN device node, generate and maintain local domain internal topology information, and report inter-domain link information to the parent SDN OTN controller;
the parent SDN OTN controller is further configured to receive inter-domain link information from the child SDN OTN controller, and generate and maintain inter-domain topology information.
Further, the system can also have the following characteristics:
the parent SDN OTN controller is further configured to receive inter-domain and/or intra-domain node and link fault information from the child SDN OTN controllers, complete protection recovery between inter-domain and end-to-end connections across domains, and send a protection recovery request for cross-domain connection to each child SDN OTN controller of a cross-domain service or send a protection recovery request for single-domain connection to a child SDN OTN controller;
the child SDN OTN controller is further configured to receive fault information of nodes, ports, and links of a device from an OTN device node, report inter-domain and/or intra-domain node and link fault information to the parent SDN OTN controller, complete a protection recovery mechanism of a portion in a domain according to a protection recovery request for cross-domain connection issued by the parent SDNOTN controller, and complete protection recovery of single-domain service connection according to a protection recovery request for single-domain connection issued by the parent SDN OTN controller.
Further, the system can also have the following characteristics:
the sub-SDN OTN controller is further used for establishing and maintaining a connection session with an OTN device node, achieving automatic discovery with the OTN device node, and encrypting or decrypting messages with the OTN device node.
In order to solve the above technical problem, the present invention further provides a method for implementing a hierarchical software defined network controller architecture, which is applied to a multi-domain Optical Transport Network (OTN), wherein a parent Software Defined Network (SDN) Optical Transport Network (OTN) controller establishes an inter-domain mapping relationship between a full network view and a physical device network according to full network topology information, and sends a mapping processing request of the full network view and the physical device network in each domain to each sub-SDN OTN controller; the child SDN OTN controller establishes a mapping relation between a full-network view and a physical device network in the domain according to the mapping processing request in the domain received from the parent SDN OTN controller.
Further, the method can also have the following characteristics:
the method comprises the following steps that a parent SDN OTN controller executes configuration of cross-domain end-to-end service connection among domains, initiates a configuration processing request of cross-domain or single-domain end-to-end service connection inside each domain to each child SDN OTN controller, and each child SDN OTN controller notifies a processing result of inter-domain configuration of cross-domain service connection, wherein the configuration at least comprises one of the following operation processing: creating, deleting, inquiring and modifying attributes;
and after receiving the configuration processing request, the sub SDN OTN controller executes the configuration of cross-domain or single-domain end-to-end service connection in the local domain.
Further, the method can also have the following characteristics:
the parent SDN OTN controller executes path calculation of cross-domain end-to-end service connection among domains, starts a path calculation request of cross-domain or single-domain end-to-end service connection inside each domain to each child SDN OTN controller, and notifies each child SDNOTN controller of a processing result of inter-domain path calculation of cross-domain service connection;
the sub-SDN OTN controller performs path computation of cross-domain or single-domain end-to-end service connection in each domain.
Further, the method can also have the following characteristics:
the child SDN OTN controller receives link information between nodes and/or ports from OTN equipment nodes, generates and maintains local domain internal topology information, reports inter-domain link information to the parent SDN OTN controller, and the parent SDN OTN controller receives the inter-domain link information from the child SDN OTN controller and generates and maintains the inter-domain topology information.
Further, the method can also have the following characteristics:
the child SDN OTN controller receives fault information of nodes, ports and links of equipment from OTN equipment nodes and reports fault information of nodes and links between domains and/or in domains to the parent SDN OTN controller;
the parent SDN OTN controller receives inter-domain and/or intra-domain node and link fault information from the child SDN OTN controller, completes the protection recovery of cross-domain end-to-end connection between domains, and sends a protection recovery request of cross-domain connection to each child SDN OTN controller of cross-domain service or sends a protection recovery request of single-domain connection to the child SDN OTN controller;
and the child SDN OTN controller completes the protection recovery mechanism of the in-domain part according to the protection recovery request of cross-domain connection issued by the parent SDN OTN controller, and completes the protection recovery of single-domain service connection according to the protection recovery request of single-domain connection issued by the parent SDN OTN controller.
Further, the method can also have the following characteristics:
and the sub-SDNOTN controller establishes and maintains a connection session with the OTN equipment, and realizes automatic discovery with the OTN equipment node and encryption or decryption of messages with the OTN equipment node.
Further, the method can also have the following characteristics:
the cross-domain service establishing method comprises the following steps:
after receiving a cross-domain service establishment request from a network virtual layer, the parent SDN OTN controller completes inter-domain path calculation of cross-domain service connection according to an inter-domain mapping relation between a whole network view and a physical device network, completes a configuration process of inter-domain parts of the cross-domain service connection according to a calculation result of the inter-domain paths of the cross-domain service, initiates a configuration request of the cross-domain service connection in each domain to child SDN OTN controllers of each domain, completes path calculation of the cross-domain service connection in the domain according to the request, configures a connection part of the whole cross-domain service connection in the domain according to a path calculation result in the domain, and sends the connection relation to the device layer.
Further, the method can also have the following characteristics:
the single domain service establishing method comprises the following steps:
the method comprises the steps that after a parent SDN OTN controller receives a single-domain service establishment request from a network virtual layer, an intra-domain service connection configuration request is sent to a child SDN OTN controller of a domain where the single-domain service is located, the child SDN OTN controller completes path calculation of service connection in the domain, a connection part of the whole cross-domain service connection in the domain is configured according to a path calculation result in the domain, and the connection relation is issued to an equipment layer.
The invention sets the hierarchical structure of the parent SDN OTN controller and the child SDN OTN controller, can realize the mapping relation between the multi-domain full-network view and the global physical equipment network in the true sense, realize the full-network resource optimization algorithm in the true sense, and thoroughly solve the problem of inter-domain link resource conflict in the process of cross-domain service connection signaling.
In the aspect of generation and maintenance of network topology, the mapping relation between the multi-domain full-network view and the global physical equipment network can be really realized through the architecture mechanism, and further network topology information is provided for the optimized scheduling of end-to-end service connection defined by a user in the global network range.
In the aspect of routing function, a calculation function of an inter-domain path is provided for end-to-end cross-domain service connection according to a global network topology view, so that inter-domain routing of end-to-end cross-domain service connection defined by a user can be obtained through a parent SDN OTN controller in the framework; the method can realize the real full-network resource optimization algorithm in the multi-domain OTN scene.
In the aspect of service configuration function, resource reservation and allocation of cross-domain service connection between domains can be realized without running RSVP-TE protocol between child SDN OTN controllers, and can be completed by a parent SDNOTN controller through assignment; under the batch processing operation condition of cross-domain service connection, the father SDN OTN controller can complete the resource reservation and distribution of service connection among domains, and can avoid the asynchronous (sending of the PATH message of the next service connection, without waiting for the RESV successful response of the last service connection) sending process of signaling among a plurality of service connection domains, thereby greatly improving the success rate of multi-service connection operation; the problem of inter-domain link resource conflict in the cross-domain service connection signaling process is thoroughly solved through a father SDN OTN controller.
Drawings
Figure 1 is a schematic diagram of an OTN-oriented SDN network architecture in the prior art;
fig. 2 is a schematic diagram of a networking reference architecture of an SDN (Open Flow protocol) controller in a multi-domain scenario in the prior art;
figure 3 is a block diagram of a hierarchical SDN controller architecture system in a multi-domain OTN network scenario in the present invention;
FIG. 4 is a flow chart of cross-domain service connection establishment in the present invention;
fig. 5 is a flow chart of the single domain service connection establishment in the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily combined with each other without conflict.
The basic idea of the invention is mainly embodied in that a hierarchical architecture mode is adopted, a multi-domain OTN network is divided into domains and domains according to a parent SDN OTN controller which is responsible for the maintenance and management of network resources between SDN OTN domains and the unified scheduling and control of service connection between the domains, and a child SDN OTN controller is issued to be informed, so that the maintenance and management of the network resources in each domain of the SDN OTN and the unified scheduling and control of the service connection between the domains are completed.
As shown in fig. 1, in the architecture system of the middle-level SDN in the multi-domain OTN, two layers of OTN controllers are provided in an SDN OTN controller layer, including a parent SDN OTN controller and one or more child SDNOTN controllers connected to the parent SDN OTN controller.
And the parent SDN OTN controller is used for establishing an inter-domain mapping relation between the full-network view and the physical device network according to the full-network topology information and sending a mapping processing request of the full-network view and the physical device network in each domain to each child SDN OTN controller.
And the child SDN OTN controller is used for establishing a mapping relation between the whole network view and the physical device network in the domain according to the mapping processing request in the domain received from the parent SDN OTN controller.
By the framework mechanism, the mapping relation between the multi-domain whole network view and the global physical equipment network can be really realized, and further network topology information is provided for the optimized scheduling of the end-to-end service connection defined by the user in the global network range.
In the service connection configuration processing function:
a parent SDN OTN controller, configured to execute configuration between domains of cross-domain end-to-end service connections, initiate a configuration processing request for cross-domain or single-domain end-to-end service connections inside each domain to each child SDNOTN controller, and notify each child SDN OTN controller of a processing result of inter-domain configuration of cross-domain service connections, where the configuration at least includes one of the following operation processes: creating, deleting, querying, modifying attributes.
And the sub SDN OTN controller is used for executing the configuration of cross-domain or single-domain end-to-end service connection in the local domain after receiving the configuration processing request.
On the path calculation function of the service connection:
the parent SDN OTN controller is also used for executing path calculation of cross-domain end-to-end service connection among domains, starting a path calculation request of cross-domain or single-domain end-to-end service connection inside each domain to each child SDN OTN controller, and notifying each child SDNOTN controller of a processing result of inter-domain path calculation of cross-domain service connection;
and the sub SDN OTN controller is used for executing path calculation of cross-domain or single-domain end-to-end service connection in each domain.
In the function of topology generation and maintenance:
the system comprises a parent SDN OTN controller, a child SDN OTN controller and a plurality of SDN OTN controllers, wherein the parent SDN OTN controller is used for receiving inter-domain link information from the child SDN OTN controller and generating and maintaining inter-domain topology information;
and the child SDN OTN controller is further used for receiving link information between nodes and/or ports from the OTN equipment nodes, generating and maintaining local domain internal topology information, and reporting inter-domain link information to the parent SDN OTN controller.
In the reliability processing function:
the sub SDN OTN controller is used for receiving fault information of nodes, ports and links of the equipment from the OTN equipment nodes and reporting fault information of nodes and links between domains and/or in domains to the father SDN OTN controller;
the system comprises a parent SDN OTN controller, a child SDN OTN controller and a plurality of sub-SDN OTN controllers, wherein the parent SDN OTN controller is used for receiving inter-domain and/or intra-domain node and link fault information from the child SDN OTN controller, completing the protection recovery of cross-domain end-to-end connection between domains, and sending a protection recovery request of cross-domain connection to each child SDN OTN controller of cross-domain service or sending a protection recovery request of single-domain connection to the child SDN OTN controller;
the sub-SDN OTN controller is used for completing a protection recovery mechanism of the intra-domain part according to a protection recovery request of cross-domain connection issued by the parent SDN OTN controller and completing protection recovery of single-domain service connection according to a protection recovery request of single-domain connection issued by the parent SDN OTN controller.
Interaction between the child SDN OTN controller and the OTN device nodes:
the sub-SDN OTN controller is used for establishing and maintaining a connection session (through an OpenFlow protocol or a PCEP extension protocol) with the OTN equipment node, realizing automatic discovery with the OTN equipment node, and encrypting or decrypting messages with the OTN equipment node.
The function of the OTN device:
establishing and maintaining a connection session between the sub SDN OTN controller and the OTN equipment node through an OpenFlow protocol or a PCEP (personal computer operating environment) extension protocol, and realizing automatic discovery between the sub SDN OTN controller and the OTN equipment node, encryption/decryption of messages between the sub SDN OTN controller and the OTN equipment node and other processing;
reporting link information (including intra-domain and inter-domain links) among nodes, ports and equipment nodes automatically discovered by means of related protocols (such as LMP (local mean-path protocol) and the like) of the equipment to an SDN OTN (software defined network) controller through an OpenFlow protocol or a PCEP (personal computer environment protocol) extension protocol;
reporting fault information of nodes, ports, links (including intra-domain and inter-domain links) and the like of equipment to an SDN OTN controller through an OpenFlow protocol or a PCEP (personal computer environment extension protocol), so that a controller layer can trigger a protection recovery mechanism for service connection;
the OTN equipment node itself should possess the function of generating and maintaining OXC, DXC mapping table: configuring, modifying and inquiring related OXC and DXC mapping table items according to the request from the sub-SDNOTN controller, and completing the hardware driving of the OXC and DXC by the equipment node according to the table items.
The following mainly introduces the interactive message content of the system:
1. receiving message contents from an OTN network virtual layer by a father SDN OTN controller:
full network topology view information;
request for processing (setup, deletion, modification, query, etc.) of multi-domain or single-domain OTN traffic.
2. The message content sent to the OTN network virtual layer by the parent SDN OTN controller:
the processing (setup, deletion, modification, query, etc.) of multi-domain or single-domain OTN traffic is answered.
3. Message content sent by the parent SDN OTN controller to the child SDN OTN controller:
the single domain service comprises processing requests for creating, deleting, inquiring, modifying attributes and the like in the local domain of the SDN OTN controller;
the multi-domain service comprises processing requests for creating, deleting, inquiring, modifying attributes and the like in the domain where the sub SDN OTN controller is located;
and the network view of the whole network and the mapping of the physical equipment network in each domain process the request.
4. The parent SDN OTN controller receives the message content from the child SDN OTN controller:
the single domain service comprises processing responses of creating, deleting, inquiring, modifying attributes and the like in the local domain of the SDN OTN controller;
the multi-domain service comprises processing responses such as creation, deletion, inquiry, attribute modification and the like in the domain where the sub SDN OTN controller is located;
the mapping processing response of the whole network view and the physical equipment network in each domain;
reporting inter-domain link information to a parent SDN OTN controller;
and reporting inter-domain and intra-domain node and link fault information to the parent SDN OTN controller.
5. Message content sent to the OTN device layer by the child SDN OTN controller:
connection session request/response; protocol information is automatically discovered.
6. The sub-SDN OTN controller receives message content from an OTN device layer:
connection session request/response;
automatically discovering protocol information;
the method comprises the steps that the nodes and ports of equipment and link information (including intra-domain and inter-domain links) between equipment nodes automatically discovered by means of relevant protocols (such as LMP protocols and the like) report a SDN OTN controller through an OpenFlow protocol or a PCEP (personal computer environment protocol) extension protocol;
fault information of nodes, ports, links (including intra-domain and inter-domain links) and the like of the equipment is reported to the SDN OTN controller through an OpenFlow protocol or a PCEP (personal computer environment) extension protocol.
The management method of the level software defined network in the multi-domain optical transport network corresponds to the system, and comprises the following steps: the method comprises the steps that a father SDN OTN controller establishes an inter-domain mapping relation between a whole network view and a physical device network according to whole network topology information, and sends mapping processing requests of the whole network view and the physical device network in each domain to each son SDN OTN controller; and the child SDN OTN controller establishes a mapping relation between the whole network view and the physical device network in the domain according to the mapping processing request in the domain received from the parent SDN OTN controller.
The specific execution content corresponds to the execution content of the parent SDN OTN controller and the child SDN OTN controller in the system, and details are not described here.
The establishment process of cross-domain service connection under the level SDN OTN controller architecture comprises the following steps: after receiving a cross-domain service establishment request from a network virtual layer, a parent SDN OTN controller completes inter-domain path calculation of cross-domain service connection according to an inter-domain mapping relation between a whole network view and a physical device network, completes a configuration process of inter-domain parts of the cross-domain service connection according to a calculation result of the inter-domain paths of the cross-domain service, initiates a configuration request of the cross-domain service connection in each domain to child SDN OTN controllers of each domain, completes path calculation of the cross-domain service connection in the domain according to the request, configures a connection part of the whole cross-domain service connection in the domain according to a path calculation result in the domain, and sends the connection relation to the device layer.
As shown in fig. 4, the process of establishing a cross-domain service connection under a hierarchical SDN OTN controller architecture includes steps 401 to 410:
step 401: the application layer sends a service establishment request to the network virtual layer;
step 402: the network virtual layer forwards the service establishment request to a father SDN OTN controller according to the full-network topology view;
step 403: the method comprises the steps that a father SDN OTN controller completes inter-domain path calculation of cross-domain service connection according to an inter-domain mapping relation between a whole network view and a physical equipment network;
step 404: judging whether the inter-domain path calculation of the cross-domain service is successful; if the inter-domain path calculation is not successful, go to step 405, if the inter-domain path calculation is successful, go to step 406;
step 405: checking the inter-domain mapping relation between the whole network view and the physical equipment network, correcting, and returning to the step 403;
step 406: the father SDN OTN controller completes the configuration process of the inter-domain part of the cross-domain service connection according to the inter-domain path calculation result of the cross-domain service;
step 407: judging whether the inter-domain configuration process is successful or not; if the inter-domain configuration procedure is not successful, go directly back to step 405; if the inter-domain configuration process is successful, go to step 408;
step 408: a parent SDN OTN controller initiates a configuration request of cross-domain service connection in each domain to a child SDN OTN controller of each domain;
step 409: the child SDN OTN controller completes path calculation of cross-domain service connection in the domain according to the request of the parent SDN OTN controller;
step 410: and the sub SDN OTN controller configures a connection part of the whole cross-domain service connection in the domain according to a path calculation result in the domain, and issues the connection relation to a device layer through an Openflow protocol or a PCEP (personal computer operating environment) extension protocol.
The establishment process of the single domain service connection under the level SDN OTN controller architecture comprises the following steps: after receiving a single-domain service establishment request from a network virtual layer, a parent SDNOTN controller sends an intra-domain service connection configuration request to a child SDN OTN controller of a domain where the single-domain service is located, the child SDN OTN controller completes path calculation of service connection in the domain, configures a connection part of the whole cross-domain service connection in the domain according to a path calculation result in the domain, and issues the connection relation to an equipment layer.
As shown in fig. 5, the establishment procedure of the single domain service connection under the hierarchical SDN OTN controller architecture includes steps 501 to 505:
step 501: the application layer sends a service establishment request to the network virtual layer;
step 502: the network virtual layer forwards the service establishment request to a father SDN OTN controller according to the full-network topology view;
step 503: a parent SDN OTN controller initiates an intra-domain service connection configuration request to a child SDN OTN controller of a domain where the service connection is located;
step 504: the sub SDN OTN controller completes the path calculation of service connection in the local domain;
step 505: the sub-SDN OTN controller configures the service connection according to the path calculation result in the local domain, and issues the connection relation to a device layer (through an Openflow protocol or a PCEP (personal computer operating environment) extension protocol).
The present invention is capable of other embodiments, and various changes and modifications may be made by one skilled in the art without departing from the spirit and scope of the invention.
It will be understood by those skilled in the art that all or part of the steps of the above methods may be implemented by instructing the relevant hardware through a program, and the program may be stored in a computer readable storage medium, such as a read-only memory, a magnetic or optical disk, and the like. Alternatively, all or part of the steps of the above embodiments may be implemented using one or more integrated circuits. Accordingly, each module/unit in the above embodiments may be implemented in the form of hardware, and may also be implemented in the form of a software functional module. The present invention is not limited to any specific form of combination of hardware and software.