WO2016082592A1 - Configuration method and apparatus - Google Patents

Abstract

The present invention provides a configuration method and apparatus. The method comprises: establishing a connection between an SDN application and an SDN controller; and after the connection is established, performing Operations, Administration and Maintenance (OAM) configuration by using an interface between the SDN application and the SDN controller. By means of the present invention, a problem in the related art that an OAM function is not implemented for a northbound user interface is resolved, thereby improving user experience.

Description

Configuration method and device Technical field

The present invention relates to the field of communications, and in particular, to a configuration method and apparatus.

Background technique

As the current network exposes more and more ills and people's demand for network performance, researchers have to add a lot of complex functions to the router's architecture, which makes routers and other switching devices more and more bloated. And the space for performance improvement is getting smaller and smaller. However, in contrast to the predicament in the network field, the computer field has achieved rapid development. The underlying data path (switch, router) is "dumb, simple, minimal" and defines a common API for the flow table that is open to the outside world, while using the controller to control the entire network. Future researchers can freely call the underlying APIs on the controller to program, thus enabling network innovation.

Based on the above concept, a Software Defined Network (SDN) has emerged, which was originally a new network innovation architecture proposed by the Stanford University Clean Slate research group. It is widely used in packet networks and optical transmission networks. Wait. The SDN network in the related art includes: one SDN network usually includes three architecture levels: a physical network, an SDN application, and an SDN controller. The physical network is at the bottom, containing all the physical devices in the network that make up the entire IT infrastructure; SDN applications are the most visible part of the SDN network, providing services to users such as switches or network virtualization, firewalls and data stream equalizers, etc. The SDN controller is like a middleware of the whole architecture. The controller must integrate all the physical and virtual devices in the network, receive the request from the SDN application, process it accordingly, and then deliver it to the physical device to establish a service path and complete the corresponding request. Features.

Currently, the physical network and the controller communicate through the OpenFlow protocol. The OpenFlow protocol is used to describe the standards used by controllers and physical devices for interaction, as well as the corresponding interface standards. The interface between the physical network and the controller is called the Southbound Interface (SBI). The interface between the controller and the application is called the Northbound Interface (NBI). In the existing SDN standard, there are two northbound interface modes, OpenFlow protocol communication mode and RESTful interface mode.

In the network technology related to transport connection, fault monitoring and reporting, performance monitoring, and triggering of recovery mechanisms are all important, including space switching, DWDM, TDM and Ethernet PBB-TE and MPLS technologies. In these technologies, the OAM function can be used to monitor the survivability of network connections and monitor the performance of the connection, which is an indispensable function in the SDN network.

The inventor discovered that the function of OAM needs to be activated actively or passively and consistent with the connection function to prevent The generation of false alarms and the consistency of operations. In some technologies, an OAM entity needs to be configured. Therefore, network users must be able to select certain functions of OAM according to the type of connection, OAM configuration parameters, and OAM functions can be activated at any time; automatic dynamic monitoring of connections is required, especially when the number of connections is large, dynamic OAM Configuration is especially important. In order to achieve the above objectives, the OAM entity and its related functions need to be dynamically configured.

However, in the SDN network, the OAM function has not been implemented in the northbound user interface.

In view of the fact that the northbound user interface in the related art has not yet implemented the OAM function, an effective solution has not been proposed yet.

Summary of the invention

The main purpose of the embodiments of the present invention is to provide a configuration method and apparatus to solve at least the problem that the northbound user interface has not implemented the OAM function in the related art.

According to an aspect of an embodiment of the present invention, there is provided a configuration method comprising: establishing a connection between an SDN application and an SDN controller; and after the connection is established, an interface between the SDN application and the SDN controller Perform operations management and maintain OAM configuration.

Optionally, performing the OAM configuration includes at least one of the following: establishing an OAM entity and a configuration parameter, adjusting an OAM parameter, querying an OAM parameter, deleting an OAM entity, querying an OAM alarm, and querying an OAM performance.

Optionally, performing operation management and maintaining the OAM configuration includes: performing OAM configuration through a RESTful interface of the HTTP protocol stack.

Optionally, establishing the OAM entity and configuring the parameter includes: the SDN application formulating an OAM configuration parameter and/or a rule; and the SDN application passes the data corresponding to the configuration parameter and/or the rule through a RESTful interface of the HTTP protocol stack Sent to the SDN controller; the SDN controller operates in accordance with received configuration parameters and/or rules.

Optionally, deleting the OAM entity includes: sending, by the SDN application, a message for deleting the OAM entity to the SDN controller by using a RESTful interface of an HTTP protocol stack; the SDN controller according to the received deletion The OAM entity's message is deleted.

Optionally, querying the OAM parameter and/or the OAM performance includes: sending, by the SDN application, a message querying the OAM parameter and/or the OAM performance to the SDN control by using a RESTful interface of an HTTP protocol stack The SDN controller performs a query operation according to the received message querying the OAM parameter and/or the OAM performance.

Optionally, performing OAM configuration through the RESTful interface of the HTTP protocol stack includes: performing OAM configuration through a RESTful interface of the HTTP protocol stack in a JSON data format.

According to another aspect of the present invention, a configuration apparatus is provided, which is located in an SDN application, and includes: a first connection unit configured to establish a connection with an SDN controller; and a first operation management maintenance OAM unit, configured to be connected After the establishment, OAM configuration is performed through an interface with the SDN controller.

Optionally, the first OAM unit includes: a policy module, configured to send a first message, where the first message is used to indicate performing at least one of the following OAM configurations: establishing an OAM entity and configuration parameters, and adjusting OAM The parameter, the query OAM parameter, and the OAM entity are deleted; and/or the monitoring module is configured to send the second message, where the second message is used to indicate at least one of the following OAM configurations: querying the OAM alarm, querying the OAM performance .

According to another aspect of the present invention, a configuration apparatus is provided, which is located in an SDN controller, and includes: a second connection unit configured to establish a connection with an SDN application; and a second operation management maintenance OAM unit, configured to be connected After the establishment, OAM configuration is performed through an interface with the SDN application.

Through the embodiment of the present invention, a connection is established between the SDN application and the SDN controller; after the connection is established, the manner of operation management and maintenance of the OAM configuration is implemented by the interface between the SDN application and the SDN controller, and the solution is solved. In the related art, the northbound user interface has not implemented the OAM function, thereby improving the user experience.

DRAWINGS

The drawings described herein are intended to provide a further understanding of the invention, and are intended to be a part of the invention. In the drawing:

1 is a flow chart of a configuration method according to an embodiment of the present invention;

2 is a block diagram showing the structure of a configuration apparatus according to an embodiment of the present invention;

3 is a block diagram 1 of an optional structure of a configuration apparatus according to an embodiment of the present invention;

4 is a block diagram 2 of an optional structure of a configuration apparatus according to an embodiment of the present invention;

FIG. 5 is a structural block diagram of a configuration apparatus according to an embodiment of the present invention; FIG.

6 is a block diagram 3 of an optional structure of a configuration apparatus according to an embodiment of the present invention;

7 is a block diagram showing the structure of an SDN network architecture according to an alternative embodiment of the present invention;

8 is a block diagram showing the structure of an SDN application structure according to an alternative embodiment of the present invention;

9 is a block diagram showing the structure of an SDN controller according to an alternative embodiment of the present invention;

10 is a schematic diagram of OAM configuration parameters according to an alternative embodiment of the present invention;

11 is a flow diagram of an OAM configuration in accordance with an alternate embodiment of the present invention;

12 is a flow chart of fault and performance monitoring in accordance with an alternative embodiment of the present invention;

FIG. 13 is a block diagram showing an optional structure of an SDN network of an OAM configuration according to an alternative embodiment of the present invention.

detailed description

The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

A method for configuring a configuration is provided in this embodiment. FIG. 1 is a flowchart of a configuration method according to an embodiment of the present invention. As shown in FIG. 1 , the process includes the following steps:

Step S102: establishing a connection between the SDN application and the SDN controller;

Step S104: After the connection is established, the operation management and maintenance OAM configuration is performed through an interface between the SDN application and the SDN controller.

In this embodiment, after the connection between the SDN application and the SDN controller is established, the OAM configuration is performed through the interface between the SDN application and the SDN controller, and the OAM is not implemented in the northbound user interface in the related art. Functional issues that improve the user experience.

The OAM configuration can include multiple operations, such as setting up OAM entities and configuration parameters, adjusting OAM parameters, querying OAM parameters, deleting OAM entities, querying OAM alarms, and querying OAM performance. One or more of these operations can pass through the northbound interface. get on.

The OAM configuration can be implemented in various manners. In an optional implementation manner of the embodiment, the OAM configuration is performed in the following manner: OAM configuration is performed through a RESTful interface of the HTTP protocol stack.

The following is a description of RESTful: Representational State Transfer (REST) is a software architecture style proposed by Dr. Roy Fielding in his doctoral thesis in 2000. It is a way of designing and developing web applications that can reduce the complexity of development and increase the scalability of the system. Characterizing state transitions is a set of architectural constraints and principles, and applications or designs that satisfy these constraints and principles are RESTful. REST is usually based on the use of HTTP, URI, XML (a subset of the standard universal markup language), and HTML (an application under the standard universal markup language). Line of agreements and standards. The RESTful method is supported by the majority of operators and users due to the standardization of standards and simple implementation. At present, the ONF NBI working group and the OIF organization only define the functions of the northbound interface in the SDN network to implement service request and topology query and the interface mode, but have not realized that RESTful can be introduced into the OAM configuration of the northbound interface. The optional implementation uses a RESTful interface for configuration to make the configuration more flexible.

For the above-mentioned OAM configuration in the embodiment, the OAM configuration is performed through the RESTful interface of the HTTP protocol stack. In another optional implementation manner of this embodiment, the data may be encapsulated into a JSON data format and then encapsulated into RESTful data format, OAM configuration through the RESTful interface of the HTTP protocol stack.

Several OAM configurations are described below in conjunction with a few examples.

Example 1

In this optional implementation manner, when the involved OAM is configured to establish an OAM entity and configuration parameters, the following manner can be implemented:

Step S11: The SDN application formulates OAM configuration parameters and/or rules.

Step S12: The SDN application sends the data corresponding to the configuration parameter and/or the rule to the SDN controller through the RESTful interface of the HTTP protocol stack.

Step S13: The SDN controller operates according to the received configuration parameters and/or rules.

Case 2

In this optional implementation, when the OAM is configured to delete an OAM entity, the OAM configuration can be implemented as follows:

Step S21: The SDN application sends a message for deleting the OAM entity to the SDN controller through the RESTful interface of the HTTP protocol stack.

Step S22: The SDN controller performs a deletion operation according to the received message of deleting the OAM entity.

Example three

In this optional implementation, when the involved OAM is configured to query OAM parameters and/or OAM performance, the OAM configuration can be implemented as follows:

Step S31: The SDN application sends a message for querying OAM parameters and/or OAM performance to the SDN controller through the RESTful interface of the HTTP protocol stack.

Step S32: The SDN controller performs the message according to the received query OAM parameter and/or OAM performance. Query operation.

In the embodiment, a configuration device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and has not been described again. As used below, the term "module" "unit" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

2 is a structural block diagram of a configuration apparatus according to an embodiment of the present invention. The apparatus is located in an SDN application, as shown in FIG. 2, the apparatus includes: a first connection unit 22, configured to establish a connection with an SDN controller; The management maintenance OAM unit 24 is coupled to the first connection unit 22 and is configured to perform OAM configuration through an interface with the SDN controller after the connection is established.

FIG. 3 is a block diagram of an optional structure of a configuration apparatus according to an embodiment of the present invention. As shown in FIG. 3, the first OAM unit 24 includes a policy module 32 configured to send a first message, where the first message is used. Instructing to perform at least one of the following OAM configurations: establishing an OAM entity and configuration parameters, adjusting an OAM parameter, querying an OAM parameter, deleting an OAM entity, and/or, the monitoring module 34, configured to send a second message, where the second message is used At least one of the following OAM configurations is instructed: querying OAM alarms, querying OAM performance.

FIG. 4 is a block diagram of an optional structure of a configuration apparatus according to an embodiment of the present invention. As shown in FIG. 4, the first OAM unit 24 includes: a first adaptation module 42 coupled to the policy module 32, and configured to receive The RESTful data format data is decapsulated, and/or the data sent to the SDN controller is encapsulated into a RESTful data format; the first protocol stack module 44 is coupled to the first adaptation module 42 and configured to pass the HTTP protocol stack. The RESTful interface receives data from the SDN controller and/or sends data encapsulated in a RESTful data format to the SDN controller.

In an optional implementation manner of the embodiment, the first adaptation module 42 is further configured to encapsulate the data required for the OAM configuration into a JSON data format and then encapsulate the data into a RESTful data format.

5 is a structural block diagram of a configuration apparatus according to an embodiment of the present invention. The apparatus is located in an SDN controller. As shown in FIG. 5, the apparatus includes: a second connection unit 52 configured to establish a connection with an SDN application; The management maintenance OAM unit 54 is coupled to the second connection unit 52 and is configured to perform OAM configuration through an interface with the SDN application after the connection is established.

6 is a block diagram 3 of an optional structure of a configuration apparatus according to an embodiment of the present invention. As shown in FIG. 6, the second OAM unit 54 includes a second protocol stack module 62 configured to receive from a RESTful interface of the HTTP protocol stack. The data of the SDN application, and/or the data encapsulated in the RESTful data format is sent to the SDN application; the second adaptation module 64 is coupled to the second protocol stack module 62 and configured to perform the received data in the RESTful data format. Decapsulating, and/or encapsulating data sent to the SDN application into a RESTful data format; the OAM module 66 is coupled to the second adaptation module 64 and configured to perform at least one of the following OAM configurations; Set OAM entities and configuration parameters, adjust OAM parameters, query OAM parameters, delete OAM entities, query OAM alarms, and query OAM performance.

In an optional implementation manner of this embodiment, the second adaptation module 64 may be further configured to decapsulate the received RESTful data into data in a JSON data format, and then perform decapsulation, and/or send The data package of the SDN application is encapsulated into a JSON data format and then encapsulated into a RESTful data format.

In order to better illustrate the present invention, an alternative embodiment of the present invention will be described below using RESTful as an example. In the following optional embodiments, a device and a method for implementing OAM configuration, performance, alarm, and the like in the RESTful northbound interface under the SDN network architecture are provided. The following optional embodiment further defines a set of RESTful under the SDN network architecture. The northbound interface implements message specifications for a series of functions such as OAM entity creation, parameter modification, deletion, performance, and alarm query.

This alternative embodiment provides a solution for extending the OAM configuration and the alarm and performance monitoring functions in the SDN network northbound interface RESTful. By adding the processing flow of OAM configuration in RESTful, adding corresponding extensions, under the premise of complying with the existing standards, the OAM configuration method and device are proposed, and related functions such as fault monitoring and performance statistics are implemented, so that the SDN network has OAM function. The ability to monitor network quality includes OAM establishment and configuration methods and devices for related functions, query and report of fault alarms, performance query and implementation of reporting functions. Description will be made below with reference to the drawings.

FIG. 7 is a structural block diagram of an SDN network architecture diagram according to an alternative embodiment of the present invention. As shown in FIG. 7, the SDN network includes a three-layer basic framework: a physical network, an SDN application, and an SDN controller.

The physical network consists of an OpenFlow switch network, interconnected with the controller through the southbound interface, and follows the OpenFlow standard primitive; the SDN application and the controller are interconnected through the northbound interface, following the RESTful specification, based on using HTTP, URI, and XML. HTML is an existing wide range of popular protocols and standards. A device for implementing OAM configuration in an SDN network, wherein the function of the northbound interface mainly relates to an SDN application and an SDN controller.

FIG. 8 is a structural block diagram of an SDN application structure diagram according to an alternative embodiment of the present invention. As shown in FIG. 8, the module component of the SDN application includes: a protocol stack module, an adaptation module, a policy module, and a monitoring module.

The protocol stack is a protocol platform for implementing related RESTful functions, and sends and receives an HTTP protocol message from the controller; the adaptation module is a functional module that encapsulates the protocol stack data; the policy module is a module that formulates rules for the OAM configuration and related functions; The monitoring module is a management module for reporting and monitoring faults and performance. The OAM monitoring rule is passed to the policy module. When the OAM monitoring rule is delivered, the information of the flow identifier is also required to be transmitted, so that the policy module can associate the monitoring packet with the specific OAM processing rule.

FIG. 9 is a structural block diagram of an SDN controller according to an alternative embodiment of the present invention. As shown in FIG. 9, the module of the SDN controller includes: a protocol stack module, an adaptation module, and an OAM module.

The protocol stack is a protocol platform for implementing related RESTful functions, and sends and receives an HTTP protocol message from the controller; the adaptation module is a functional module that encapsulates the protocol stack data; and the OAM module receives and processes OAM related configurations and queries. Management module. The OAM module can receive the rules passed from the adaptation module and apply the rules delivered by the controller to the switch. At the same time, the OAM module is associated with a specific OAM rule according to the identifier in the packet. When the related data is queried, after the parsed message is filtered, the conditional report is reported to the SDN application.

OAM needs to be configurable and managed, and users should be able to enable/disable OAM-related capabilities. The OAM function needs to be activated actively or passively and consistent with the connection function. The OAM entity needs to be configured. Therefore, the SDN application user must be able to select certain functions of the OAM according to the type of connection, configure the parameters in OAM, and activate the OAM function at any time.

The configuration of the OAM entity needs to be completed after the connection is established. The OAM-related functions are optional and require other configurations, such as fault management (Fault Management for FM) and performance management (Performance Management for PM). )Wait. Therefore, OAM also needs to support the ability to select a range of OAM functions and configure their parameters.

The main aspects of configuring OAM include the establishment of OAM entities and the configuration of functions, coordination of OAM parameters at both ends, and deletion of OAM entities. These aspects are described separately below.

OAM entity creation and function configuration

Maintenance Points (MPs) are divided into two types: Maintenance End Points (MEPs) and Maintenance Intermediate Points (MIPs). MEPs are at both ends of the connection. OAM messages for FM and PM can be initiated and aborted; the MIP is in the intermediate node of the connection and can receive OAM messages but cannot initiate.

The maintenance entity (Maintenance Entity, ME for short) cooperates between the MEP and the MIP to monitor the connection. Once the connection is established, the forwarding relationship between the endpoint and the intermediate node has been established so that the OAM entity can monitor the connection. In addition to the related parameters defined by MP and ME, active OAM functions such as Continuity Check (CC), FM, and PM require parameter configuration.

In the RSVP-TE protocol, FIG. 10 is a schematic diagram of OAM configuration parameters according to the optional embodiment. The format of the OAM configuration is as shown in FIG. 10, and the OAM type indicates the OAM entity type supported by the creation node. When OAM is created, capability negotiation is required between nodes. Indicates whether the node is a MEP or a MIP and indicates whether the OAM alarm is enabled.

In the SDN network, first, the policy module of the SDN application formulates OAM-related rules according to the configuration or its own policy, such as performance monitoring rules, and passes the policy rules to the adaptation module; the adaptation module encapsulates the rules according to the policy module. The data is sent to the protocol stack, and the message contains a letter related to the policy rule. In addition, the connection information and the OAM configuration information of the policy rule are used. After receiving the message through the RESTful interface, the protocol stack sends the message to the adaptation module. The adaptation module parses the data and sends it to the OAM module for OAM configuration.

FIG. 11 is a flowchart of an OAM configuration according to an alternative embodiment of the present invention. As shown in FIG. 11, the steps of the configuration include:

Step S1102: The SDN application formulates the rules of the OAM configuration and related functions through the policy module, and delivers the corresponding configuration parameters to the adaptation module.

Step S1104: The adaptation module encapsulates the relevant data into a RESTful data format and sends the data to the HTTP protocol stack.

Step S1106: After receiving the message, the HTTP protocol stack sends the message to the controller through the RESTful interface.

Step S1108: the HTTP protocol stack of the controller receives the message sent to the adaptation module through the RESTful interface;

Step S1110: The adaptation module parses the relevant data and sends the data to the OAM module.

Step S1112: The OAM performs an OAM configuration operation according to the OAM configuration information delivered by the application.

OAM parameter adjustment

The OAM function that has been created and configured may require parameter adjustment during the lifetime of the connection. In this case, the OAM parameters need to be updated. The OAM parameter is related to the content and duration of the OAM message. It is also related to the way OAM detects, acquires, and generates alarms. Therefore, the source and end of the OAM need to update the data synchronously. First, the OAM alarm function is disabled, and then the OAM parameters are adjusted. After the OAM parameters are updated, the OAM alarm function is enabled. When the OAM parameters are modified on the RESTful interface, the policy module of the SDN application is required to perform the OAM configuration policy selection, and the OAM entity parameters are modified. The RESTful protocol is delivered to the adaptation module and adapted to the RESTful format through the HTTP protocol stack. Send to the SDN controller. The process of the OAM parameter adjustment is the same as the OAM creation process in FIG. 6.

OAM entity deletion

In some cases, some or all of the OAM entities and features need to be removed without affecting the established connections. First, the OAM alarm function is disabled, and the source and tail end need to delete data synchronously. Then the deletion of the OAM entity is automatically triggered. When the OAM entity and the configuration are deleted on the RESTful interface, the QoS policy is used to send the message to the SDN controller. The RESTful protocol is delivered to the SDN controller through the HTTP protocol stack. The process of deleting the OAM entity is the same as the OAM creation process in FIG. 6.

Fault and performance monitoring

In some cases, the user needs to monitor the network connection and network quality to grasp the operational efficiency of the entire network and to perform unified resource scheduling and planning on the network. Therefore, in the SDN network, the SDN application needs to send configuration messages on the northbound interface and monitor network faults and performance parameters in real time.

In the SDN network, the configuration of the OAM fault and performance monitoring functions can be performed first, as described above. When the user needs to monitor the connection failure and network quality, the fault and performance parameters can be queried in real time through the RESTful interface.

FIG. 12 is a flowchart of fault and performance monitoring according to an alternative embodiment of the present invention. As shown in FIG. 12, the steps of the query include:

Step S1202: The SDN application sends a query message to the adaptation module by sending a fault or a performance query command through the monitoring module.

Step S1204: The adaptation module encapsulates the relevant data into a RESTful data format, sends the data to the HTTP protocol stack, and sends the data to the controller through the RESTful interface.

Step S1206: The HTTP protocol stack of the controller receives the message through the RESTful interface, and sends the message to the adaptation module to parse the relevant data, and sends the data to the OAM module.

Step S1208: The OAM module reports the relevant query result to the adaptation module according to the query message.

Step S1210: The adaptation module encapsulates the relevant data into a RESTful data format, sends the data to the HTTP protocol stack, and sends the data to the SDN application through the RESTful interface.

Step S1212: The HTTP protocol stack of the SDN application receives the message through the RESTful interface and sends the message to the adaptation module to parse the relevant data, and sends the message to the monitoring module.

RESTful message specification

Under the Restful architecture, the client and server communicate using the HTTP protocol, which has the following characteristics:

1) Each URI represents a resource.

2) A kind of presentation layer for passing such resources between the client and the server, which may be in a format such as txt/html/xml/json.

3) The client operates on the server-side resources through four HTTP verbs (GET/POST/PUT/DELETE) to implement "presentation level state conversion".

JSON (JavaScript Object Notation) is a lightweight data exchange format. It is based on a subset of JavaScript. JSON has become the ideal data exchange language. Easy for people to read and write, but also easy to machine Parsing and generating. This article uses the JSON format as an example to develop a RESTful message specification.

The OAM API related to OAM configuration based on JSON is interoperable with the controllers of each domain to implement end-to-end OAM management, performance, and fault monitoring.

Tables 1a to 1e are diagrams of the OAM JSON message structure; among them, the OAM entity and configuration parameters are created and adjusted. As shown in Table 1a, the HTTP mode is POST. The parameters in the request message include: the id is the connection ID corresponding to the OAM, the MEP is the created OAM end node address, the MIP is the intermediate node address, and the Function is the created OAM-related function, such as FM, PM, etc. If the request is successful, return 200: OK response, the first 4 parameters in the response message are the same as the request, AdminStatus is up or down, indicating whether the OAM is enabled; if the request fails, according to the reason of the failure, return 400: Bad Request, etc. Message code, no response content.

Query the OAM parameters. As shown in Table 1b, the HTTP mode is GET, the id is the connection ID corresponding to the OAM, and the response message is the same as the created response.

The OAM entity is deleted. As shown in Table 1c, the HTTP mode is DELETE, the id is the connection ID corresponding to OAM, and there is no response content.

Query the OAM alarm. As shown in Table 1d, the HTTP mode is GET, and the id is the connection ID corresponding to the OAM. When the request is successful, the response message is returned. The Function is the function to be queried, such as FM; the alarmNum is the alarm number; the alarmStatus is the alarm status. ;alarmReason is the cause of the alarm; AdminStatus is up or down, indicating whether the OAM is enabled.

Query OAM performance. As shown in Table 1e, the HTTP mode is GET, the id is the connection ID corresponding to OAM, the Function is the function to be queried, such as PM, the bandwidth is the connection bandwidth, the BER is the service error rate, and the disconnect is the controller. The number of times of the link; AdminStatus is up or down, indicating whether the OAM is enabled. It should be understood that the relevant data may be modified, renamed, added, etc., all of which are within the scope of the alternative embodiments of the present invention. As shown in Tables 1a to 1e:

Table 1a

Table 1b

Table 1c

Table 1d

Table 1e

FIG. 13 is a block diagram of an optional structure of an SDN network according to an optional embodiment of the present invention. As shown in FIG. 13, the SDN network includes an SDN application APP and an SDN controller, and the IP address of the SDN controller is 193.90.160.5. And an administrative domain, the nodes in the domain are switch-1/2/3, and their IP addresses are 193.90.10.5, 193.90.20.5, and 193.90.30.5, respectively.

The APP establishes a connection between node switch-1 and node switch-3. The connection ID is 1. After the intermediate node switch-2, the service bandwidth is ODU2 protection type is 1+1 channel protection, and the recovery type is no recovery. The APP is interconnected with the controller through a RESTful interface, the HTTP protocol version is 1.1, and the REST object is in Json format. Several alternative embodiments are described below in conjunction with FIG.

Alternative embodiment 1:

An APP creates an OAM entity through a RESTful interface and configures OAM parameters. The function is performance monitoring. The message flow is as follows:

1. The APP formulates the OAM configuration parameters and rules of the performance monitoring through the policy module, and delivers the corresponding configuration parameters to the adaptation module.

2. The adaptation module encapsulates the relevant data into a JSON data format, sends it to the HTTP protocol stack, and sends it to the Controller through the RESTful interface;

3. The HTTP protocol stack of the Controller receives the message through the RESTful interface and sends it to the adaptation module, parses the relevant data, and sends it to the OAM module.

The OAM performs OAM configuration operations based on the delivered OAM configuration information.

The RESTful message format is as follows:

Alternative embodiment 2:

The APP deletes the OAM entity through the RESTful interface. The message flow is as follows:

1. The APP sends a corresponding OAM deletion message to the adaptation module through the policy module.

2. The adaptation module encapsulates the relevant data into a JSON data format, sends it to the HTTP protocol stack, and sends it to the Controller through the RESTful interface;

3. The HTTP protocol stack of the Controller receives the message through the RESTful interface and sends it to the adaptation module, parses the relevant data, and sends it to the OAM module.

4. The OAM performs an OAM deletion operation according to the delivered OAM deletion message.

The RESTful message format is as follows:

DELETE/rest/json/OAM_API/SERV-1

{

}

HTTP/1.x 200OK

{

}

Alternative embodiment three:

The APP queries the OAM configuration parameters through the RESTful interface. The message flow is as follows:

1. The APP sends a corresponding OAM query message to the adaptation module through the policy module.

2. The adaptation module encapsulates the relevant data into a JSON data format, sends it to the HTTP protocol stack, and sends it to the Controller through the RESTful interface;

3. The HTTP protocol stack of the Controller receives the message through the RESTful interface and sends it to the adaptation module, parses the relevant data, and sends it to the OAM module.

4. The OAM reports the OAM related configuration parameters to the adaptation module according to the delivered OAM query message.

5. The adaptation module is encapsulated into JSON data and sent to the HTTP protocol stack, and sent to the APP;

6. The HTTP protocol stack of the APP receives the RESTful message and sends it to the adaptation module, parses the JSON data, and sends it to the policy module.

The RESTful message format is as follows:

Alternative embodiment four:

The APP queries performance-related parameters through the RESTful interface. The message flow is as follows:

1. The APP sends a corresponding OAM query message to the adaptation module through the policy module.

2. The adaptation module encapsulates the relevant data into a JSON data format, sends it to the HTTP protocol stack, and sends it to the Controller through the RESTful interface;

3. The HTTP protocol stack of the Controller receives the message through the RESTful interface and sends it to the adaptation module, parses the relevant data, and sends it to the OAM module.

4. The OAM reports the OAM related configuration parameters to the adaptation module according to the delivered OAM query message.

5. The adaptation module is encapsulated into JSON data and sent to the HTTP protocol stack, and sent to the APP;

6. The HTTP protocol stack of the APP receives the RESTful message and sends it to the adaptation module, parses the JSON data, and sends it to the policy module.

The results of the RESTful query failure alarm are as follows:

The results of RESTful query performance statistics are as follows:

Through the above optional embodiments, related functions and parameters are defined, and there is no related message and parameter expansion in the RESTful interface, and the manner in which the user monitors network faults and performance is not defined. Therefore, the OAM configuration, network quality monitoring, and fault and alarm reporting functions are implemented in the RESTful interface mode to ensure the normal and stable operation of the network and the rapid recovery after the fault, providing users with high-quality services.

The above is only an alternative embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Industrial applicability

With the present invention, a connection is established between the SDN application and the SDN controller; after the connection is established, the OAM configuration is operated and maintained through the interface between the SDN application and the SDN controller, and the related technology is solved. The North-to-North user interface has not implemented the OAM function, which improves the user experience.

Claims (10)

A configuration method, including: Establish a connection between the SDN application and the SDN controller; After the connection is established, the operation management and maintenance OAM configuration is performed through an interface between the SDN application and the SDN controller. The method of claim 1 wherein performing the OAM configuration comprises at least one of: Establish OAM entities and configuration parameters, adjust OAM parameters, query OAM parameters, delete OAM entities, query OAM alarms, and query OAM performance. The method according to claim 1 or 2, wherein performing the operation management and maintenance OAM configuration comprises: OAM configuration through the RESTful interface of the HTTP protocol stack. The method of claim 3, wherein establishing the OAM entity and configuring the parameters comprises: The SDN application formulates OAM configuration parameters and/or rules; The SDN application sends the data corresponding to the configuration parameter and/or the rule to the SDN controller through the RESTful interface of the HTTP protocol stack; The SDN controller operates in accordance with received configuration parameters and/or rules. The method of claim 3, wherein deleting the OAM entity comprises: Sending, by the SDN application, a message for deleting the OAM entity to the SDN controller by using a RESTful interface of the HTTP protocol stack; The SDN controller performs a delete operation according to the received message of deleting the OAM entity. The method of claim 3 wherein querying the OAM parameters and/or the OAM performance comprises: The SDN application sends a message for querying the OAM parameter and/or the OAM performance to the SDN controller through a RESTful interface of the HTTP protocol stack; The SDN controller performs a query operation according to the received message querying the OAM parameter and/or the OAM performance. The method according to any one of claims 3 to 6, wherein the OAM configuration through the RESTful interface of the HTTP protocol stack comprises: The OAM configuration is performed through the RESTful interface of the HTTP protocol stack in the JSON data format. A configuration device, located in an SDN application, comprising: a first connection unit, configured to establish a connection with the SDN controller; The first operation management maintains the OAM unit, and is configured to perform OAM configuration through an interface with the SDN controller after the connection is established. The apparatus of claim 8 wherein said first OAM unit comprises: a policy module, configured to send a first message, where the first message is used to indicate that at least one of the following OAM configurations is performed: establishing an OAM entity and configuration parameters, adjusting an OAM parameter, querying an OAM parameter, deleting an OAM entity, and/or or, The monitoring module is configured to send a second message, where the second message is used to indicate at least one of the following OAM configurations: querying an OAM alarm, querying OAM performance. A configuration device, located in the SDN controller, comprising: a second connection unit, configured to establish a connection with the SDN application; The second operation management maintains the OAM unit, and is configured to perform OAM configuration through an interface with the SDN application after the connection is established.

Images