Patent Application
20200153679
The present disclosure relates generally to the field of software-defined networking (SDN), and in particular to enhancing communications between management plane and control plane operations within a SDN-based communication platform.
Modern communication systems require the management and control of network elements. To this end, the SDN provides an interactive platform to facilitate the monitoring and configuration of network elements. The SDN platform provides for three basic configuration levels: control plane, data plane, and management plane. The control plane and management plane serve the data plane, which bears the network traffic. The management plane, which carries administrative traffic, is configured as a subset of the control plane. The control plane is the part of the network that carries signaling traffic and is responsible for routing. Functions of the control plane include system configuration and management.
Various protocols and models specify the operations between the control, management, and data planes. For example, Yet Another Next Generation (YANG) modeling language and RESTCONF (which is an Internet Engineering Task Force (IETF) draft that described how to map a YANG specification to a RESTful interface) protocol provide standards that describe how to map a YANG-based commands to a RESTful interface.
However, in some instances, these standards may not adequately correlate information between the management and control planes to effectively communicate operational status issues for network hardware element upgrades or configuration changes.
An object of the present disclosure is to provide methods and architectures of providing improved status reporting communications between management plane and control plane operations in a SDN communication system.
In accordance with this objective, an aspect of the present disclosure provides a method comprising receiving, at a server, a user configuration request to establish a connection with the server and to implement a configuration change of a network element, assigning an operational ID to the user configuration request; validating the user configuration request in accordance with a configuration datastore; assigning a control plane job ID to the user configuration request; correlating the assigned operational ID with the assigned control plane job ID; requesting the control plane to verify the implementation of the user configuration request based on the corresponding control plane operation; and upon receiving verification from the control plane that: the user configuration request has been implemented, writing into an operational status datastore a record of the implemented user configuration request, the user configuration request has not been implemented, returning an error status message and storing the error status message in the operational status datastore.
Generally stated, the present disclosure provides an architecture for providing improved reporting status communications between a management plane and control plane operations in a SDN communication system, comprising server configured to receive a user configuration request to establish a connection with the server and to implement a configuration change of a network element, the server further configured to validate the user configuration request; a network protocol datastore including an intended configuration datastore and an operational status datastore, configured to store user configuration and operational status; a control plane configured to verify the user configuration request; and a correlation module configured to provide a network interface to correlate the control plane operations with the management plane operations; wherein upon the control plane has implemented the user configuration request, the control plane writes into the operational status datastore a record of the implemented user configuration request, and upon the control plane has not implemented the user configuration request, the control plane returns an error status message to the correlation module, and the correlation module stores the error status message into the operational status datastore.
Implementations of the present disclosure each have at least one of the above-mentioned object and/or aspects, but do not necessarily have all of them. It should be understood that some aspects of the present disclosure that have resulted from attempting to attain the above-mentioned object may not satisfy this object and/or may satisfy other objects not specifically recited herein.
Additional and/or alternative features, aspects and advantages of implementations of the present disclosure will become apparent from the following description, the accompanying drawings and the appended claims.
Embodiments of the present disclosure will be described by way of example only, with reference to the accompanying drawings.
Like numerals represent like features on the various drawings. It should also be noted that, unless otherwise explicitly specified herein, the drawings are not to scale.
A detailed description of the present disclosure will be discussed with respect to the accompanying figures. The embodiments of the concepts disclosed herein are intended to be illustrative, as the scope of the present disclosure should not be limited to such.
As illustrated by
Control plane 140 is configured to control the functions and processes that determine which path to use, such as, for example, routing protocols, spanning tree, signaling, path computation, Label Distribution Protocol (LDP), etc.
Management plane 105 may comprise the functions necessary to control and monitor devices. Datastore 120 is a conceptual entity that stores and facilitates access to information. Datastore 120 may be implemented, for example, by employing files, databases, flash memory locations, or combinations thereof. Control plane 140 is configured to exchange data with data plane 150. Data plane 150 may refer to all the functions and processes that forward packets/frames from one interface to another. As shown in
Although control plane 140 can read to and write from YANG datastore 120, the operations of control plane 140 are independent from the RESTCONF operations. Therefore, the returned value from YANG datastore 120 only reflects the status of the datastore operations rather than that of control plane 140. For example, if errors occur on the control plane operations, user 100 does not receive any error message from the control plane. The problem is that a reported successful RESTCONF operation does not confirm a successful subsequent control plane operation. As a result, when the subsequent control plane operation fails to successfully apply the user configuration information to a network hardware device, there is no adequate mechanism to inform the user of the failure.
Based on the deficiencies noted above, in order to enable users to query the status of the control plane operations and effectively receive useful feedback regarding the status of network elements in response to those operations, a correlation module that associates control plane operations with error reporting communications regarding with YANG-based operations is described herein. The proposed correlation module may be embodied as a software-based construct that is configured to correlate YANG operations in accordance with the management plane with and control plane counterparts.
In particular, the correlation module is configured with a YANG interface to comply with Network Configuration Protocol (NETCONF) and RESTCONF protocol communications. In this manner, status information based on the correlational relationship between the management plane and their control plane counterparts may be reported to the user via YANG module.
As discussed in detail below, the correlation module is configured to maintain an associative mapping between the YANG operations and control plane operations. The correlation module also provides the YANG interface, which, combined with the mapping, enables the user to access control plane status. As a result, not only is the user capable of viewing the status of the control plane operations, users are capable of retrying or cancelling the failed operations, based on the status information received, as well as providing users with an error reporting mechanism and the facility to provide users with manual intervention capabilities to correct any failed control plane operations.
With this said,
As illustrated in
Management plane 205 logically comprises a RESTCONF server 210 and a YANG datastore 220. Server 210 receives user 200 request message and interprets the request message in accordance with the YANG module. Server 210 then acquires the configuration parameter defined in YANG module. After referring to YANG datastore 220, which includes intended configuration datastore 221 and operational status datastore 222, server 210 confirms whether the user message is valid or not by comparing configuration parameters contained within the request message with that in intended configuration datastore 221.
Specifically, server 210 performs syntax checks of user request message. It validates whether input payload in the user configuration contained within the user request message contains valid JSON (or XML) syntax, such as, for example, if the input JSON string's brackets are balanced. This is the most basic validation performed by the RESTCONF server. Moreover, the server may do schematic check. It validates input JSON data against the schema of the YANG model. For example, it checks if the structure of the JSON data is consistent with the YANG model.
This check may also be performed by RESTCONF server which “knows” the YANG model schema. Intended configuration datastore 221 is a datastore that records the user configuration input by the user. Operational status datastore 222 stores the operational status of the control plane. Server 210 may store the configuration parameter to intended configuration datastore 221.
The most left column of
The second column to the left of
The last column of
Control plane 240 invokes control plane operations to map each of the operations with the corresponding RESTCONF Jobs. From the ID to the status and the error message, control plane 240 correlates the RESTCONF operations and the control plane operations accordingly. Correlation module 230 may then write the mapping table into the YANG datastore's control plane operation data tree which will be explained below as shown in
Correspondingly, correlation module 230 creates a control-plane job ID which associates it with the user configuration request having a RESTCONF operation ID. Correlation module 230 then invokes the control-plane operations, and associates those operations with control-plane job IDs. By doing so, correlation module 230 correlates the control-plane operations with the RESTCONF operations.
Control plane 240 may be configured to further verify the user configuration saved in intended configuration datastore 221 by the RESTCONF server. The configuration parameter may include relevant information, such as, for example, bandwidth of the tunnel, the source or destination Termination Point (TP), etc.
If control plane 240 succeeds in verifying the user configuration and implements the user configuration request, control plane 240 will write the applied user configuration into operational status datastore 222. If control plane 240 fails to implement the user configuration parameter, control plane 240 returns an error message to correlation module 230 to indicate the current operational status of control plane 240.
Correlation module 230 writes the error message in operational status datastore 222 under the control-plane-operation sub-tree whose schema is defined by the YANG model in
In accordance with embodiments of the present disclosure, because correlation module 230 is configured to have RESTCONF interface (such as, for example, a YANG-based defined model), the correction relationship between the RESTCONF operations and the control plane operations may be displayed and communicated to user 200 via the RESTCONF interface. In view of this facility, control plane 240 may actively return error message to correlation module 230 and correlation module 230 may write and report the error into operational status datastore 222. As a result, user 200 may directly query operational status datastore 222 to determine whether the requested jobs are successfully performed or, if not, the reasons why requested jobs failed.
In turn, YANG datastore 220 responds to RESTCONF server 210 with the current status of control plane 240. As a result, server 210 returns a corresponding message to user 200. Therefore, user 200 may perform corresponding operations, such as, for example, manually operate his/her message to request a “retry”, “abort”, “stop”, “resume”, etc. operation.
For example, in some instances the bandwidth may be available later, so that user 200 may request a “retry” operation to make the request again. In other cases, if user 200 does not want to continue to further operations, he/she may select “abort” to cancel the operation.
By way of an illustrative example regarding the operations between the RESTCONF protocol and the control plane, if user 200 wants to create two “tunnels” within the network, i.e., Job 1 and Job 2, user 200 sends a request to the network indicating the configuration for the two jobs. As described above, RESTCONF server 210 checks the syntax and schematics of network configuration parameters of the request against the YANG model schema. Server 210 may store the configuration parameter into intended configuration datastore 221 and if the syntax and schematics of the request are determined to be acceptable, then control plane 240 may be invoked to configure the network configuration of the two requested two tunnels to the network hardware.
However, in the event that the complete user request may not be successfully implemented, such as, for example, the bandwidth of the network is not enough to perform the two jobs, source or destination TPs are already in use, etc., and that only Job 1 can be created, but the Job 2 fails. In such a case, control plane 240 may write the applied user configuration parameter of Job 1 to operational status datastore 222. As such, control plane 240 will return an error message to correlation module 230 to indicate the failure of Job 2 and correlation module 230 will write the error message into the YANG operational status datastore 222.
In so doing, if the current status stored in operational status datastore 222 indicates that the Job 2 has not been implemented due to the shortage of the bandwidth, user 200 may directly recall the current status of the control plane by querying the status data from operational status datastore 222. For example, the user may use RESTCONF “get” or “retrieve” message operations to query operational status datastore 222 to determine whether the requested jobs are successfully performed.
For the input information, for example, there are four elements as follow:
“restconf-target”,
“restconf-operation-type”,
“restconf-operation-payload” and
“restconf-operation-time”.
The “restconf-target” indicates where the user configuration should be stored in intended configuration datastore. The “restconf-operation-type” means the type of the RESTCONF operation, for example, “PUT”, “ADD”, etc. The “restconf-operation-payload” is in a format of a string attribute indicating the job to be done. For example, it shows the configurations of two “tunnels” that should be created as requested by the user. The RESTCONF payloads are recorded for debugging. A job ID “[job-id]” is assigned uniquely within one RESTCONF operation.
If the operation is YANG-PATCH, the id is the same as “edit-id” generated by YANG-PATCH. If it is another RFC 8040 operation, the job-status sub-tree may be empty, since the global-status is used. Finally, a “corrective operation” may be performed. Based on the error report, user 200 may further operate the job, for example, retry, abort, stop, resume, etc.
Therefore, owing to this embodiment, user 200 is capable of acquiring actual, updated operational status and error reports regarding network element configurations from control plane 240. Such updated status and reports provides user 200 with the information necessary to pursue further network maintenance actions.
The configuration changes included in the request of user 200 may be syntactically and schematically valid relative to a RESTCONF operation. However, in the application's runtime context, it may be invalid. That is, as shown in
The following described below attempts to address the problem mentioned above. In another embodiment of the present disclosure, a mechanism (i.e., software-based “sandbox” module) that provides a testing environment within the YANG model and generates the sandbox testing RESTCONF API (Application Program Interfaces) for simulated RESTCONF operations in the control plane is provided. The communication established between the user and the control plane is performed by means of RPC mechanism instead of using the RESTCONF operation. The RPC operation is an operation that may be invoked by a user on a server.
The sandbox module functions substantially the same as the correlation module in the previous embodiment. However, the user configuration will not be recorded or written into the datastore. Further, the sandbox module adds a flag to the existing control plane API to indicate that the operation is for validation purposes only. The user configuration will not be applied to the network hardware.
In this embodiment, it is noted that the user configuration is not stored in the intended configuration datastore. The control plane only validates the user configuration with the corresponding configuration requirement in the control plane in a simulation scenario. Actually, the user configuration is not applied to the network hardware in this embodiment so that the network hardware is not affected. Other than that, this embodiment does not require much change in the control plane, because it already has validation logic.
On the user side, RESTCONF RPCs are defined by the sandbox YANG model. The RPC input parameters contains the RESTCONF operations which are to be sandbox-validated, such as:
In turn, the sandbox testing module processes and executes the RPC, such as:
In the embodiment of the present disclosure, the RPC mechanism is used to establish the communication between the user and the control plane. As shown in
The flag is a Boolean. It represents the application of the sandbox testing module. When its value is true, control plane 530 only performs the sematic validation and returns the result. Control plane 530, however, does not apply the user configuration to the network hardware. When the value is false, control plane 530 performs the normal operation. The default value is false.
In some cases, control plane 530 may check the validation of the configuration with data plane 540 by querying the API operations of data plane 540. If it is valid, control plane 530 sends back a successful message to sandbox testing module 520. In the end, server 510 sends the sandbox result back to user 500.
The function of sandbox testing module 520 just asks control plane 530 to verify the use configuration to see whether the user request can be fulfilled in the perspective of network hardware without applying the user configuration to the network hardware. For example, control plane 530 may check if the resource is available in the hardware in order to perform the user request. In this case, no hardware configuration is altered.
Optionally, according to the user request, in order to make sure the current configuration in the control plane is suitable for the operation of the request, sandbox testing module 520 may occasionally and optionally query YANG datastore 550 as shown by dashed line in
The above embodiment is intended to be illustrative only. In this embodiment, it is noted that YANG datastore 550 is optional. In certain embodiments, the above operations may be performed without YANG datastore.
“restconf-target”;
“restconf-operation-type”; and
“restconf-operation-payload”.
The RESTCONF target means a destination to save the user's configuration. Here, the target is assigned as a Universal Resource Indicator (URI). For the type of operation, it may include POST, PUT, DELETE, PATCH, YANG-PATCH and etc. The RESTCONF payload includes the configuration of the job indicated in the user request. In this embodiment, the payload is used for validation of the user configuration.
For example, null means DELETE. The control plane validates the user's configuration with the hardware resources and settings. If the validation fails, the control plane may provide an error message, which may be captured in the line “ietf-restconf: errors”.
The present disclosure has been described in the foregoing specification by means of non-restrictive illustrative embodiments provided as examples. These illustrative embodiments may be modified at will. The scope of the claims should not be limited by the embodiments set forth in the examples, but should be given the broadest interpretation consistent with the description as a whole.
