WO2016091013A1 - 业务处理方法及装置 - Google Patents

业务处理方法及装置 Download PDF

Info

Publication number
WO2016091013A1
WO2016091013A1 PCT/CN2015/092326 CN2015092326W WO2016091013A1 WO 2016091013 A1 WO2016091013 A1 WO 2016091013A1 CN 2015092326 W CN2015092326 W CN 2015092326W WO 2016091013 A1 WO2016091013 A1 WO 2016091013A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
restful interface
cross
node
connection
Prior art date
Application number
PCT/CN2015/092326
Other languages
English (en)
French (fr)
Inventor
鲁春怀
王家昱
张帅
刘芳
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2016091013A1 publication Critical patent/WO2016091013A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W92/00Interfaces specially adapted for wireless communication networks
    • H04W92/04Interfaces between hierarchically different network devices

Definitions

  • the present invention relates to the field of communications, and in particular to a service processing method and apparatus.
  • SDN Software Defined Network
  • SDON Software Defined Optical Networking
  • OTN Optical Transport Network
  • the core technology of the software-defined network is to separate the control plane of the network device from the data plane through the OpenFlow protocol.
  • OpenFlow protocol there is a problem in the OpenFlow protocol in the optical network: Since the OpenFlow protocol was originally designed for the data network, the latest version of OpenFlow Although the protocol has been extended to the optical network, it still cannot fully support the optical network.
  • the present invention provides a service processing method and apparatus to at least solve the problem that the OpenFlow protocol in the related art cannot fully support an optical network.
  • a service processing method includes: creating a first RESTful interface between a multi-domain controller in a software-defined optical network SDON and one or more single-domain controllers, and A second RESTful interface between the one or more single domain controllers and the nodes in the corresponding domain; processing the SDON service according to the created first RESTful interface and/or the second RESTful interface.
  • the creating the first RESTful interface between the multi-domain controller in the SDON and the one or more single-domain controllers includes: the SDON service on the first RESTful interface
  • a functional attribute of a business object is provided, and the functional attribute of the business object includes a functional attribute of the connection object and a functional attribute of the endpoint object.
  • the functional attributes of the connection object include: a connection identifier ID of the connection object, and a connection class of the connection object.
  • the connection path of the connection object wherein the connection type includes one of the following: a working connection, a protection connection, a work recovery connection, and a protection recovery connection;
  • the function attributes of the endpoint object include: a node identifier ID of the endpoint object, and an endpoint The port number of the object.
  • the creating the second RESTful interface between the one or more single domain controllers in the SDON and the nodes in the corresponding domain comprises: providing a service object for the SDON service on the second RESTful interface
  • the cross-operation function attribute, the cross-operation function attribute of the business object includes a cross-operation function attribute of the connection object, and the cross-operation function attribute of the connection object includes a cross-operation function attribute of the endpoint object.
  • the cross-operation function attribute of the endpoint object includes: ingress port information, outbound port information, inbound label information, and outbound label information.
  • processing the SDON service according to the created first RESTful interface and/or the second RESTful interface includes one of: a domain that the multi-domain controller passes to the service path through the first RESTful interface Corresponding one or more single domain controllers send a service establishment request; the one or more single domain controllers send, by using the second RESTful interface, a node that passes the service path in the corresponding domain for the SDON service.
  • the node feeds back a successful response message to the node by the second RESTful interface to the single-domain controller to which the node belongs; And sending, by the second RESTful interface, a deletion message for deleting the cross information of the node with successful cross configuration to the node with successful cross configuration through the second RESTful interface.
  • the single domain controller receives the response message of the node's cross configuration failure in the domain, through the first REST
  • the ful interface sends a response message for feeding back the failure of the local area service establishment to the multi-domain controller; the node to which the single-domain controller belongs sends a response message for feeding back the cross-over information to the single-domain controller through the second RESTful interface.
  • the single domain controller feeds back the response message of the local service establishment success to the multi-domain controller through the first RESTful interface; Sending, by the first RESTful interface, the deletion message to the one or more single domain controllers for deleting the SDON service; the one or more single domain controllers to the first RESTful interface
  • the multi-domain controller feeds back the response message of the SDON service.
  • a service processing apparatus comprising: a creating module, configured to create a first between a multi-domain controller in the software-defined optical network SDON and one or more single-domain controllers a RESTful interface, and a second RESTful interface between the one or more single domain controllers and nodes within the corresponding domain; a processing module configured to create the first RESTful interface and/or the second RESTful interface pair The SDON business is processed.
  • the creating module is further configured to provide a function attribute of the service object for the SDON service on the first RESTful interface, where the function attribute of the service object includes a function attribute of the connection object and a function of the endpoint object. Attributes.
  • the function attribute of the connection object includes: a connection identifier ID of the connection object, a connection type of the connection object, and a connection path of the connection object, wherein the connection type includes one of the following: a working connection, a protection connection, and a work Restore the connection, protect the recovery connection;
  • the functional attributes of the endpoint object include: the node identification ID of the endpoint object, and the port number of the endpoint object.
  • the creating module is further configured to provide a cross-operation function attribute of the service object for the SDON service on the second RESTful interface, where the cross-operation function attribute of the service object includes a cross-operation function of the connection object An attribute, the connection object cross-operation function attribute includes a cross-operation function attribute of the endpoint object.
  • the cross-operation function attributes of the endpoint object include: ingress port information, outbound port information, inbound label information, and outbound label information.
  • the processing module is further configured to: the multi-domain controller send a service establishment request to the one or more single domain controllers by using the first RESTful interface; the one or more orders The domain controller sends, by using the second RESTful interface, a cross-configuration request for cross-configuration of the SDON service on the node to the corresponding intra-domain node; if the node cross-configuration is successful, the node passes the The RESTful interface feeds back a successful response message of the node to the single domain controller to which the node belongs; and if the single domain controller receives the response message of the failed node cross configuration in the domain, the second RESTful interface is used to The node with successful cross-configuration sends a delete message for deleting the cross-connection information of the node with successful cross-configuration; and the single-domain controller receives the response message of the failed node cross-configuration in the domain, and passes the first RESTful interface.
  • the node to which the single domain controller belongs is The RESTful interface sends a response message for feedback deletion of the cross information to the single domain controller; in a case where the nodes in the domain to which the single domain controller belongs are all successfully configured, the single domain controller passes the first RESTful Sending, by the interface, the response message that the local service establishment is successful to the multi-domain controller; and sending, by the multi-domain controller, the deletion message for deleting the SDON service to the one or more single domain controllers by using the first RESTful interface And the one or more single domain controllers feed back, by the first RESTful interface, a response message that deletes the SDON service to the multi-domain controller.
  • the embodiment of the present invention creates a first RESTful interface between the multi-domain controller and one or more single-domain controllers in the software-defined optical network SDON, and one or more single-domain controllers and corresponding domains in the optical network SDON.
  • FIG. 1 is a flowchart of a service processing method according to an embodiment of the present invention.
  • FIG. 2 is a structural block diagram of a service processing apparatus according to an embodiment of the present invention.
  • FIG. 3 is a schematic diagram of a system architecture of a software-defined optical network according to an embodiment of the present invention.
  • FIG. 4 is a REST object diagram of a multi-domain controller performing service configuration on a single domain controller according to an embodiment of the present invention
  • FIG. 5 is a REST object class diagram of a cross-configuration of a device node by a single domain controller according to an embodiment of the present invention
  • FIG. 6 is a flowchart of service establishment using a RESTful interface according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of performing service deletion using a RESTful interface according to an embodiment of the present invention.
  • Figure 8 is a network topology diagram in accordance with a preferred embodiment of the present invention.
  • FIG. 1 is a flowchart of a service processing method according to an embodiment of the present invention. As shown in FIG. 1, the process includes:
  • Step S102 creating a first RESTful interface between the multi-domain controller in the software-defined optical network SDON and one or more single-domain controllers, and a second RESTful between the one or more single-domain controllers and the nodes in the corresponding domain interface;
  • Step S104 processing the SDON service according to the created first RESTful interface and/or the second RESTful interface.
  • a first RESTful interface between the multi-domain controller and one or more single-domain controllers is created in the software-defined optical network SDON, and between the one or more single-domain controllers and the nodes in the corresponding domain
  • the RESTful interface is configured to process the service according to the first RESTful interface and/or the second RESTful interface, and solves the problem that the OpenFlow protocol in the related technology cannot fully support the optical network; the control plane and the data plane of the network device are implemented.
  • the implementation is simple and easy to expand.
  • the business object of the first RESTful interface between the multi-domain controller and the single-domain controller needs to be configured and Some basic attributes, such as support for service establishment, query, and delete operations, also require interface support for service protection and recovery. In order to support the protection and recovery of services, it is also necessary to add protection type related attributes that define connection objects and services.
  • the SDON service can be added on the first RESTful interface to provide the functional attributes of the service object for the SDON service.
  • the function attribute of the business object of the SDON service may include: a service identifier ID of the business object and a service name of the business object, which are used to distinguish the business object; a service level of the business object, which is used to identify the level of the service; The service bandwidth is used to identify the network bandwidth required by the service. The service status of the service object is used to identify the current status of the service. The protection type of the service object and the recovery type of the service object are used to identify the protection and recovery of the service object.
  • the function attribute of the connection object of the SDON service may include: a connection identifier ID of the connection object, a connection object for identifying the SDON service, and a connection type of the connection object, which is used to identify the connection type of the connection object, wherein the connection type may include One of the following: working connection, protection connection, work recovery connection, protection recovery connection; connection path of the connection object, used to identify the connection path of the connection object.
  • the function attributes of the endpoint object of the SDON service may include: a node identifier ID of the endpoint object, which is used to distinguish the endpoint object; and a port number of the endpoint object, used to identify the port number of the endpoint object.
  • the functional attributes defining the connection object and the endpoint object are added, which can support not only the multi-domain controller and the single domain controller.
  • Basic operations such as establishing, querying, and deleting services, and enabling protection and recovery of services.
  • the interaction between the single domain controller and the nodes in the corresponding domain is mainly a cross configuration operation.
  • the cross-operation function attribute of the business object of the SDON service may be provided for the SDON service on the second RESTful interface, the service
  • the cross-operation function attribute of the object includes the cross-operation function attribute of the connection object
  • the cross-operation function attribute of the connection object includes the cross-operation function attribute of the endpoint.
  • the cross-operation function attribute of the service object of the SDON service may include: a service identifier ID of the SDON service, a cross-operation function attribute of the working connection of the SDON service on the predetermined node, and a cross-operation function of the protection connection of the SDON service on the predetermined node.
  • the attribute, the cross-operation function attribute of the connection object of the SDON service may include: a connection identifier ID of the connection object of the SDON service, a forward cross-operation function attribute of the connection of the SDON service on the predetermined node, and a connection of the SDON service on the predetermined node
  • the reverse cross-operation function attribute; S; the cross-operation function attribute of the endpoint object of the SDON service may include: in-port information, out-port information, Enter tag information and tag information.
  • the embodiment of the present invention configures a cross-operation function attribute of a service object of the SDON service on the second RESTful interface, and defines a cross-operation function attribute of the connection object under the cross-operation function attribute of the business object of the SDON service, in the connection object
  • the cross-operation function attribute of the endpoint object is defined under the cross-operation function attribute, which is used to support the single-domain controller to add, delete, and modify the node cross-configuration information in the domain.
  • the message interaction involving the first RESTful interface and the second RESTful interface includes multiple types, for example, may include at least the following One: the multi-domain controller sends a service establishment request to one or more single-domain controllers corresponding to the domains through which the service path passes through the first RESTful interface; one or more single-domain controllers reach the corresponding domain through the second RESTful interface
  • the node sends a cross-configuration request for cross-configuration of the SDON service on the node; in the case that the node cross-configuration is successful, the node feeds back the successful response message of the node to the single-domain controller to which the node belongs through the second RESTful interface; If the single-domain controller receives the response message that the node in the domain fails to be configured in the cross-connection, the second RESTful interface sends a delete message for deleting the cross-configuration information of the node with successful cross
  • the single-domain controller feeds back the response message of the local service establishment success to the multi-domain controller through the first RESTful interface;
  • the RESTful interface sends a delete message for deleting the SDON service to one or more single domain controllers; the one or more single domain controllers feed back the response message of the SDON service to the multi-domain controller through the first RESTful interface.
  • the multiple domain controller and the one or more single domain controllers and the multiple single domain controllers and the corresponding intradomain nodes are respectively configured according to the created first RESTful interface and/or the second RESTful interface.
  • the SDON service is processed to solve the problem that the OpenFlow protocol in the related technology cannot fully support the optical network, and has the advantages of simple implementation, small occupied bandwidth, and reduced optical network development cost.
  • a service processing device is also provided, which is used to implement the foregoing embodiments and preferred embodiments, and has not been described again.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 2 is a structural block diagram of a service processing apparatus according to an embodiment of the present invention. As shown in FIG. 2, the apparatus includes: a creating module 22 and a processing module 24. The apparatus will be described below.
  • Create module 22 set to create a multi-domain controller in the software defined optical network SDON with one or more single domains a first RESTful interface between the controllers, and a second RESTful interface between the one or more single domain controllers and nodes within the corresponding domain; the processing module 24, coupled to the creation module 22, configured to be based on the first RESTful interface created And/or the second RESTful interface processes the SDON service.
  • the creation module 22 is further configured to provide a functional attribute of the business object for the SDON service on the first RESTful interface, the functional attributes of the business object including the functional attribute of the connection object and the functional attribute of the endpoint object.
  • the function attributes of the business object include: a business identifier ID of the business object, a business name of the business object, a business level of the business object, a service bandwidth of the business object, a business status of the business object, a protection type of the business object, and a business object.
  • Recovery type the functional attributes of the connection object of the SDON service include: the connection identification ID of the connection object, the connection type of the connection object, and the connection path of the connection object, wherein the connection type includes one of the following: a working connection, a protection connection, and a work recovery connection.
  • the protection recovery connection; the functional attributes of the endpoint object of the SDON service include: the node identification ID of the endpoint object, and the port number of the endpoint object.
  • the creating module 22 is further configured to provide a cross-operation function attribute of the service object for the SDON service on the second RESTful interface, where the cross-operation function attribute of the service object includes a cross-operation function attribute of the connection object, and the connection object
  • the cross-operation function attribute includes the intersection information of the endpoint object.
  • the cross-operation function attribute of the service object of the SDON service includes: a service identifier ID of the SDON service, a cross-operation function attribute of the working connection of the SDON service on the predetermined node, and a cross-operation function attribute of the protection connection of the SDON service on the predetermined node.
  • the cross-operation function attribute of the connection object of the SDON service includes: the connection identification ID of the connection object of the SDON service, the cross-operation function attribute of the forward cross of the connection of the SDON service on the predetermined node, and the connection of the SDON service on the predetermined node.
  • the cross-operation function attribute of the reverse crossover; the cross-operation function attributes of the endpoint object of the SDON service include: inbound port information, outbound port information, inbound label information, and outbound label information.
  • the processing module 24 is further configured to: the multi-domain controller sends a service establishment request to the one or more single domain controllers through the first RESTful interface; the one or more single domain controllers pass the second RESTful interface Sending a cross-configuration request for cross-configuration of the SDON service on the node to the node in the corresponding domain; in the case that the cross-configuration of the node is successful, the node feeds back the successful response of the node to the single-domain controller to which the node belongs through the second RESTful interface.
  • a message that is used to delete the cross-information of the node with successful cross-configuration is sent to the node with successful cross-configuration through the second RESTful interface, in the case that the single-domain controller receives the response message of the failed cross-configuration of the node in the domain; If the single domain controller receives the response message that the node is configured to fail to be configured in the domain, the first RESTful interface sends a response message to the multi-domain controller for feeding back the failure of the local service establishment; the node to which the single domain controller belongs Sending a cross-information for feedback deletion to a single domain controller through a second RESTful interface A message; in the case of a single domain controller node belongs to the art are successful cross configuration, the first single domain controller for all domain present RESTful interface feedback to deposit multi-domain controller node The fork configures a successful response message; the multi-domain controller sends a delete message for deleting the SDON service to the one or more single-domain controllers through the first RESTful interface; one or more
  • the service processing method and the service processing device in the embodiment of the present invention are simple to implement and convenient to expand in a case where the control plane of the network device is separated from the data plane.
  • the core technology of the software-defined network is to separate the control plane of the network device from the data plane through the OpenFlow protocol.
  • the OpenFlow protocol in the optical network has the following problems. First, the OpenFlow protocol is originally for the data network. Designed, the support for optical networks is still not comprehensive. If each device manufacturer adopts its own private extension, it is not conducive to the interconnection between devices. Second, Openflow's protocol has many contents and complex implementation, but most of the content is on optical networks. It is useless.
  • the northbound interface between the SDN controller and the application generally adopts a RESTful interface. If the southbound interface between the device and the device adopts the OpenFlow protocol. The controller needs to implement two sets of protocol stacks, which is complicated to implement and is not conducive to the unification between the north and south interfaces.
  • Representational State Transfer refers to a set of architectural constraints and principles: defining IDs for all resources; linking all resources together; using standard methods; multiple representations of resources; An application or design that satisfies these constraints and principles is RESTful.
  • the RESTful architecture is clear, standards-compliant, easy to understand, and easy to extend.
  • the HTTP protocol is a concrete example of a RESTful architecture. Each resource on the server corresponds to a specific URI. A certain presentation layer of such resources is transmitted between the client and the server, and may be in a format such as txt/html/xml/json.
  • the client operates on the server-side resources through four HTTP verbs (GET/POST/PUT/DELETE) to implement "presentation level state conversion".
  • the above embodiments and preferred embodiments not only solve the problem that the OpenFlow protocol has many contents and complex implementations, but also directly apply to the software-defined optical network SDON to increase the development and maintenance cost, and increase the complexity of the system; and between the SDON controller and the device.
  • the northbound interface between the southbound interface and the SDON controller and the application is unified, which solves the problem of complicated working procedures of the SDON controller.
  • the implementation is simple and easy to expand.
  • FIG. 3 is a schematic diagram of a system architecture of a software-defined optical network according to an embodiment of the present invention.
  • a RESTful architecture can be used between a multi-domain controller and a single-domain controller, a single-domain controller, and a device node, where the Control Virtual Network Interface (CVNI) is controlled.
  • CVNI Control Virtual Network Interface
  • Both the Control Data Plane Interface (CDPI) and the Control Data Plane Interface (CDPI) can be implemented using a RESTful interface.
  • the multi-domain controller is the client and the single-domain controller is the server.
  • Single domain controller is a guest between a single domain controller and a device node The client node is the server.
  • FIG. 4 is a REST object diagram of the multi-domain controller performing service configuration on the single domain controller according to the embodiment of the present invention, as shown in FIG. , business objects and their corresponding attribute relationships include:
  • attributes include service ID, name, A endpoint, Z endpoint, hierarchy, bandwidth, status, protection type, recovery type, working connection, protection connection, work recovery connection, protection recovery connection, etc.
  • the Z endpoint is an EndPoint object, and the working connection, the protection connection, the work recovery connection, and the protection recovery connection are Connection objects.
  • connection The connection object under the business.
  • a business has multiple connection objects.
  • the properties of the connection object include: the connection ID, the connection type, and the path.
  • the path records the specific path information of the connection.
  • EndPoint The endpoint object, which mainly includes node and port information.
  • FIG. 5 is a REST object class diagram of a single domain controller performing cross-configuration on a device node according to an embodiment of the present invention, as shown in the figure.
  • the objects involved and their attributes include:
  • Call_SNC Cross-information of a service on a certain node. If it is a protected service, it has cross-connection information corresponding to the working connection and the protection connection.
  • Connection_SNC A cross-connection that is connected to a node. It can be a working connection or a protection connection of a service. It is a child of Call_SNC. Because the business is bidirectional, each connection has two intersections in the forward and reverse directions at each node it passes through.
  • SNC A cross-tab, which is a sub-object of Connection_SNC, including inbound port, inbound tag, egress port, and outgoing tag information.
  • the Call_SNC object supports the Create and Delete operations, and the single domain controller performs cross-setting and deleting operations on the device nodes. If the service supports dynamic recovery, the Call_SNC object also needs to support the Update operation.
  • FIG. 6 is a flowchart of establishing a service using a RESTful interface according to an embodiment of the present invention. Show that the process includes:
  • Step S602 the multi-domain controller calculates a domain sequence and each of the service path through the service request parameter. Source and sink nodes within the domain.
  • Step S604 The multi-domain controller sends a service establishment request to each single-domain controller that passes the service path through the RESTful interface, where the multi-domain controller sends the service establishment request to the single-domain controller, which may include the source, the sink node, and the level of the service. , bandwidth and other information.
  • Step S606 each single domain controller calculates an intra-domain path.
  • Step S608 Each single-domain controller sends a cross-configuration request to the node that the service passes in the local domain through the RESTful interface.
  • the single-domain controller sends the cross-configuration request by using the RESTful interface, including the node ID, the service ID, the connection ID, and the signal type. , in port, inbound label, outgoing port, outgoing label, and other information.
  • each node performs a cross-configuration operation and returns a cross-configuration response to the single-domain controller.
  • the response returned by the device node to the single domain controller needs to indicate whether the cross configuration succeeds or fails.
  • Step S612 it is determined whether all nodes cross configuration is successful; if the determination result is yes, proceed to step S616; otherwise, proceed to step S614;
  • step S614 the single-domain controller deletes the successfully configured cross-connection information, that is, the service establishment failure in the domain, where the single-domain controller deletes the successfully configured cross-connection information, and the single-domain controller sends the cross-delete through the RESTful interface to each node that successfully performs the cross-configuration. request.
  • each single-domain controller returns a service establishment response to the multi-domain controller, that is, all the nodes are successfully configured, and the services in the domain are successfully established.
  • the response returned by the single domain controller to the multi-domain controller needs to indicate that the service establishment succeeds or fails.
  • the successful response needs to contain the ID of the service in the domain and the specific connection path information.
  • the service ID is generated by a single domain controller as an identifier for subsequent service query, modification, and deletion.
  • Step S618 determining whether all single domain controller services are successfully established; that is, each single domain controller returns a service establishment response to the multi-domain controller. If the result of the determination is yes, proceed to step S622, otherwise proceed to step S620;
  • step S620 the service establishment fails, and the multi-domain controller deletes the intra-domain service that is successfully established.
  • Step S622 all the single domain controllers return a successful response, and the service is successfully established.
  • FIG. 7 is a flowchart of a service deletion using a RESTful interface according to an embodiment of the present invention. As shown in FIG. 7, the steps of deleting a successful intra-domain service by a multi-domain controller include:
  • Step S702 The multi-domain controller sends a service deletion request to the single-domain controller that is successfully established in the intra-domain service through the RESTful interface.
  • the deletion request sent by the multi-domain controller to the single-domain controller needs to include the service ID.
  • Step S704 Each single-domain controller sends a cross-delete request to the node that passes the service in the local area through the RESTful interface.
  • the single-domain controller sends a cross-delete request to the device node by using the RESTful interface, where the request may include the service ID and the connection ID. , in port, in label.
  • each device node performs cross-delete and returns a cross-delete response to the single-domain controller. If all nodes are successfully deleted, the single domain controller returns a successful response to the multi-domain controller, otherwise it returns a failure response.
  • Step S708 each single domain controller returns a service deletion response to the multi-domain controller. If all single-domain controllers return a successful response, the service is deleted successfully, otherwise the service deletion fails.
  • FIG. 8 is a network topology diagram according to a preferred embodiment of the present invention, as shown in FIG.
  • the multi-domain controller manages two domains, domain 1 and domain 2, single domain controller 1 manages domain 1, its IP address is 193.80.160.5, and single domain controller 2 manages domain 2 with an IP address of 193.90. 160.5.
  • the IP addresses of nodes A, B, C, and D in domain 1 are 193.80.10.5, 193.80.20.5, 193.80.30.5, and 193.80.40.5, respectively.
  • the IP addresses of nodes A1, B1, and C1 in domain 2 are 193.90.10.5, 193.90.20.5, and 193.90.30.5, respectively.
  • the multi-domain controller needs to establish a service between node A and node C.
  • the service bandwidth is ODU2
  • the protection type is 1+1 channel protection
  • the recovery type is no recovery.
  • the multi-domain controller sends an HTTP message to the single-domain controller 1 through the RESTful interface.
  • the REST object is in the json format, and the message format is as follows:
  • the two parts separated by "/" in aEnd and zEnd are the node ID and port ID, respectively.
  • the single-domain controller 1 calculates the working path of the service as A->B->C, the protection path is A->D->C, and the single-domain controller 1 needs to give four nodes A, B, C, and D respectively.
  • Send cross configuration information, each command contains a cross information.
  • the cross-configuration information REST interface sent by the single-domain controller 1 to the node is defined as follows, taking the forward cross on Node B as an example:
  • the single-domain controller 1 After the node B cross-configuration succeeds, the single-domain controller 1 returns a successful response, and the message content is empty.
  • the single domain controller 1 After all the nodes A, B, C, and D are successfully configured, the single domain controller 1 returns a service establishment success response to the multi-domain controller.
  • the message format is as follows.
  • a method for deleting an intra-domain service using a RESTful interface is provided.
  • the network topology is as shown in FIG. 8.
  • the multi-domain controller deletes the service between the node A and the node C established in the first embodiment, and the multi-domain controller sends a service deletion request to the single-domain controller 1.
  • the message format is as follows:
  • the single-domain controller 1 sends a cross-delete request to the nodes A, B, C, and D respectively.
  • the message format is as follows:
  • Nodes A, B, C, and D return a successful response to cross-delete to single-domain controller 1, and the message content is empty.
  • the single-domain controller 1 After the nodes A, B, C, and D both return the cross-delete success response, the single-domain controller 1 returns a successful response to the service deletion to the multi-domain controller, and the message content is empty.
  • a method for establishing cross-domain service using a RESTful interface is provided, and the network topology is as shown in FIG. 8.
  • the multi-domain controller needs to establish a service between node A and node A1.
  • the service bandwidth is ODU2
  • the protection type is unprotected
  • the recovery type is dynamic recovery.
  • the multi-domain controller calculates that the service between node A and A1 needs to pass through domain 1 and domain 2.
  • the source and sink nodes in domain 1 are A and C
  • the source and sink nodes in domain 2 are C1 and A1.
  • the message format sent by the multi-domain controller to the single domain controller 1 is as follows:
  • the message format sent by the multi-domain controller to the single domain controller 2 is as follows:
  • the single domain controller 1 calculates that the path of the service in the domain 1 is A->B->C, and the single domain controller 2 calculates that the path in the domain 2 is C1->A1.
  • the single domain controller 1 sends the cross configuration information to the nodes A, B, and C respectively.
  • the information format is as follows:
  • the positive crossover is as follows:
  • the single domain controller 2 sends the cross configuration information to the nodes A1 and C1 respectively.
  • the message format is as follows, taking the forward cross on the node C1 as an example.
  • the nodes A, B, and C return the response of the cross-configuration success to the single-domain controller 1.
  • the nodes A1 and C1 return the response of the cross-configuration success to the single-domain controller 2.
  • the message format is as follows, and the message content is empty.
  • the single domain controller 1 returns a response to the successful establishment of the service to the multi-domain controller, and the message format is as follows.
  • the single domain controller 2 returns a response to the successful establishment of the service to the multi-domain controller, and the message format is as follows.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明公开了一种业务处理方法及装置,其中,该方法包括:创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及一个或多个单域控制器与对应域内节点之间的第二RESTful接口;依据创建的第一RESTful接口和/或第二RESTful接口对SDON业务进行处理。解决了相关技术中的OpenFlow协议无法全面支持软件定义光网络的问题。

Description

业务处理方法及装置 技术领域
本发明涉及通信领域,具体而言,涉及一种业务处理方法及装置。
背景技术
软件定义网络(Software Defined Network,简称为SDN),通过将网络设备的控制面与数据面分离开来,从而实现了网络流量的灵活控制,为核心网络及应用的创新提供了良好的平台,解决了现有网络设备越来越臃肿且性能提升空间越来越小的问题。
软件定义光网络(Software Defined Optical Networking,简称为SDON)是将SDN体系架构用于光传输网络(Optical Transport Network,简称为OTN)网络中,以提高OTN网络的端到端组网能力和业务创新能力。
软件定义网络的核心技术是通过OpenFlow协议将网络设备控制面与数据面分离开来,然而,光网络中采用OpenFlow协议存在一个问题:由于OpenFlow协议最初是为数据网络而设计的,最新版本的OpenFlow协议虽然针对光网络进行了一定的扩展,但依然无法全面支持光网络。
发明内容
本发明提供了一种业务处理方法及装置,以至少解决相关技术中的OpenFlow协议无法全面支持光网络的问题。
根据本发明实施例的一个方面,提供了一种业务处理方法,包括:创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及所述一个或多个单域控制器与对应域内节点之间的第二RESTful接口;依据创建的所述第一RESTful接口和/或所述第二RESTful接口对SDON业务进行处理。
可选地,创建所述SDON中所述多域控制器与所述一个或多个单域控制器之间的所述第一RESTful接口包括:在所述第一RESTful接口上为所述SDON业务提供业务对象的功能属性,所述业务对象的功能属性包括连接对象的功能属性和端点对象的功能属性。
可选地,连接对象的功能属性包括:连接对象的连接标识ID、连接对象的连接类 型、连接对象的连接路径,其中,所述连接类型包括以下之一:工作连接、保护连接、工作恢复连接、保护恢复连接;所述端点对象的功能属性包括:端点对象的节点标识ID、端点对象的端口号。
可选地,创建所述SDON中所述一个或多个单域控制器与对应域内节点之间的所述第二RESTful接口包括:在所述第二RESTful接口上为所述SDON业务提供业务对象的交叉操作功能属性,所述业务对象的交叉操作功能属性包括连接对象的交叉操作功能属性,所述连接对象的交叉操作功能属性包括端点对象的交叉操作功能属性。
可选地,所述端点对象的交叉操作功能属性,包括:入端口信息、出端口信息、入标签信息、出标签信息。
可选地,依据创建的所述第一RESTful接口和/或所述第二RESTful接口对SDON业务进行处理包括以下之一:多域控制器通过所述第一RESTful接口向业务路径经过的各域对应的所述一个或多个单域控制器发送业务建立请求;所述一个或多个单域控制器通过所述第二RESTful接口向对应域内业务路径经过的节点发送用于所述SDON业务在所述节点上进行交叉配置的交叉配置请求;在节点交叉配置成功的情况下,所述节点通过所述第二RESTful接口向所述节点所属的单域控制器反馈节点交叉配置成功的响应消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第二RESTful接口向交叉配置成功的节点发送用于删除所述交叉配置成功的节点的交叉信息的删除消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第一RESTful接口向多域控制器发送用于反馈本域业务建立失败的响应消息;单域控制器所属节点通过所述第二RESTful接口向所述单域控制器发送用于反馈删除交叉信息的应答消息;在单域控制器所属域内的节点均交叉配置成功的情况下,所述单域控制器通过所述第一RESTful接口向所述多域控制器反馈本域业务建立成功的响应消息;多域控制器通过所述第一RESTful接口向所述一个或多个单域控制器发送用于删除SDON业务的删除消息;所述一个或多个单域控制器通过所述第一RESTful接口向所述多域控制器反馈删除所述SDON业务的应答消息。
根据本发明实施例的另一个方面,还提供一种业务处理装置,包括:创建模块,设置为创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及所述一个或多个单域控制器与对应域内节点之间的第二RESTful接口;处理模块,设置为依据创建的所述第一RESTful接口和/或所述第二RESTful接口对SDON业务进行处理。
可选地,所述创建模块,还设置为在所述第一RESTful接口上为所述SDON业务提供业务对象的功能属性,所述业务对象的功能属性包括连接对象的功能属性和端点对象的功能属性。
可选地,所述连接对象的功能属性包括:连接对象的连接标识ID、连接对象的连接类型、连接对象的连接路径,其中,所述连接类型包括以下之一:工作连接、保护连接、工作恢复连接、保护恢复连接;所述端点对象的功能属性包括:端点对象的节点标识ID、端点对象的端口号。
可选地,所述创建模块,还设置为在所述第二RESTful接口上为所述SDON业务提供业务对象的交叉操作功能属性,所述业务对象的交叉操作功能属性包括连接对象的交叉操作功能属性,所述连接对象交叉操作功能属性包括端点对象的交叉操作功能属性。
可选地,所述端点对象的交叉操作功能属性包括:入端口信息、出端口信息、入标签信息、出标签信息。
可选地,所述处理模块,还设置为以下之一:多域控制器通过所述第一RESTful接口向所述一个或多个单域控制器发送业务建立请求;所述一个或多个单域控制器通过所述第二RESTful接口向对应域内节点发送用于所述SDON业务在所述节点上进行交叉配置的交叉配置请求;在节点交叉配置成功的情况下,所述节点通过所述第二RESTful接口向所述节点所属的单域控制器反馈节点交叉配置成功的响应消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第二RESTful接口向交叉配置成功的节点发送用于删除所述交叉配置成功的节点的交叉信息的删除消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第一RESTful接口向多域控制器发送用于反馈本域业务建立失败的响应消息;单域控制器所属节点通过所述第二RESTful接口向所述单域控制器发送用于反馈删除交叉信息的应答消息;在单域控制器所属域内的节点均交叉配置成功的情况下,所述单域控制器通过所述第一RESTful接口向所述多域控制器反馈本域业务建立成功的响应消息;在多域控制器通过所述第一RESTful接口向所述一个或多个单域控制器发送用于删除SDON业务的删除消息;所述一个或多个单域控制器通过所述第一RESTful接口向所述多域控制器反馈删除所述SDON业务的应答消息。
本发明实施例通过在光网络SDON中创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及一个或多个单域控制器与对应域内节点之间的第二RESTful接口;并依据创建的第一RESTful接口和/或第二RESTful接口对SDON业务进行处理,解决了相关技术中的OpenFlow协议无法全面支持软件定义光网络的问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发 明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例的业务处理方法的流程图;
图2是根据本发明实施例的业务处理装置的结构框图;
图3是根据本发明实施例的软件定义光网络的系统架构示意图;
图4是根据本发明实施例的多域控制器对单域控制器进行业务配置的REST对象图;
图5是根据本发明实施例的单域控制器对设备节点进行交叉配置的REST对象类图;
图6是根据本发明实施例的使用RESTful接口进行业务建立的流程图;
图7是根据本发明实施例的使用RESTful接口进行业务删除的流程图;
图8是根据本发明优选实施方式的网络拓扑图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
图1是根据本发明实施例的业务处理方法的流程图,如图1所示,该流程包括:
步骤S102,创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及一个或多个单域控制器与对应域内节点之间的第二RESTful接口;
步骤S104,依据创建的第一RESTful接口和/或第二RESTful接口对SDON业务进行处理。
通过上述步骤,在软件定义光网络SDON中创建多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及一个或多个单域控制器与对应域内节点之间的第二RESTful接口;并依据创建的第一RESTful接口和/或第二RESTful接口对业务进行处理,解决了相关技术中的OpenFlow协议无法全面支持光网络的问题;在实现了网络设备控制面与数据面分离的情况下,实现简单,便于扩展的效果。
在创建SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口时,需要对多域控制器和单域控制器之间的第一RESTful接口的业务配置业务对象和 一些基本属性,例如,支持业务的建立、查询、删除操作,也需要对业务的保护和恢复提供接口支持。为了支持业务的保护和恢复,还需要增加定义连接对象和业务的保护类型恢复相关属性。
即在创建SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口时,可以在第一RESTful接口上为SDON业务提供业务对象的功能属性的基础上增加定义SDON业务的连接对象的功能属性和SDON业务的端点对象的功能属性。
其中,SDON业务的业务对象的功能属性可以包括:业务对象的业务标识ID和业务对象的业务名称,用于对于业务对象进行区别;业务对象的业务层次,用于标识业务的层次;业务对象的业务带宽,用于标识业务所需占用的网络带宽;业务对象的业务状态,用于标识业务当前的状态;业务对象的保护类型和业务对象的恢复类型,用于标识业务对象的保护和恢复。
SDON业务的连接对象的功能属性可以包括:连接对象的连接标识ID,用于标识SDON业务的连接对象;连接对象的连接类型,用于对连接对象的连接类型进行标识,其中,连接类型可以包括以下之一:工作连接、保护连接、工作恢复连接、保护恢复连接;连接对象的连接路径,用于对连接对象的连接路径进行标识。
SDON业务的端点对象的功能属性可以包括:端点对象的节点标识ID,用于对端点对象进行区别;端点对象的端口号,用于对端点对象的端口号进行标识。
本发明实施例通过在第一RESTful接口上,除了配置业务业务对象和一些基本功能属性,还增加定义了连接对象和端点对象的功能属性,不仅能够支持多域控制器和单域控制器之间之间业务的建立、查询、删除等基本操作,同时能够实现对业务的保护和恢复。
单域控制器与对应域内节点之间的交互主要是交叉配置操作。例如在创建SDON中一个或多个单域控制器与对应域内节点之间的第二RESTful接口时,可以在该第二RESTful接口上为SDON业务提供SDON业务的业务对象的交叉操作功能属性,业务对象的交叉操作功能属性包括连接对象的交叉操作功能属性,连接对象的交叉操作功能属性包括端点的交叉操作功能属性。
其中,SDON业务的业务对象的交叉操作功能属性可以包括:SDON业务的业务标识ID、SDON业务在预定节点上的工作连接的交叉操作功能属性、SDON业务在预定节点上的保护连接的交叉操作功能属性、;SDON业务的连接对象的交叉操作功能属性可以包括:SDON业务的连接对象的连接标识ID,SDON业务的连接在预定节点上的正向交叉操作功能属性、SDON业务的连接在预定节点上的反向交叉操作功能属性;S;SDON业务的端点对象的交叉操作功能属性可以包括:入端口信息、出端口信息、 入标签信息、出标签信息。
本发明实施例通过在该第二RESTful接口上,配置SDON业务的业务对象的交叉操作功能属性,并在SDON业务的业务对象的交叉操作功能属性下定义连接对象的交叉操作功能属性,在连接对象的交叉操作功能属性下定义端点对象的交叉操作功能属性,用于支持单域控制器对域内节点交叉配置信息的增加、删除和修改操作。
优选地,在依据创建的第一RESTful接口和/或第二RESTful接口对SDON业务进行处理时,涉及到上述第一RESTful接口和第二RESTful接口的消息交互包括多种,例如,可以包括以下至少之一:多域控制器通过第一RESTful接口向业务路径经过的各域对应的一个或多个单域控制器发送业务建立请求;一个或多个单域控制器通过第二RESTful接口向对应域内节点发送用于SDON业务在节点上进行交叉配置的交叉配置请求;在节点交叉配置成功的情况下,节点通过第二RESTful接口向节点所属的单域控制器反馈节点交叉配置成功的响应消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过第二RESTful接口向交叉配置成功的节点发送用于删除交叉配置成功的节点的交叉信息的删除消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第一RESTful接口向多域控制器发送用于反馈本域业务建立失败的响应消息;单域控制器所属节点通过第二RESTful接口向单域控制器发送用于反馈删除交叉信息的应答消息;在单域控制器所属域内的节点均交叉配置成功的情况下,单域控制器通过第一RESTful接口向多域控制器反馈本域业务建立成功的响应消息;在多域控制器通过第一RESTful接口向一个或多个单域控制器发送用于删除SDON业务的删除消息;一个或多个单域控制器通过第一RESTful接口向多域控制器反馈删除SDON业务的应答消息。
在本发明实施例中,通过依据创建的第一RESTful接口和/或第二RESTful接口分别对多域控制器与一个或多个单域控制器之间以及多个单域控制器与对应域内节点之间SDON业务进行处理,解决了相关技术中的OpenFlow协议无法全面支持光网络的问题,具有实现简单、占用带宽小,降低光网络开发成本的优点。
在本实施例中还提供了一种业务处理装置,该装置用于实现上述实施例及优选实施方式,已经进行过说明的不再赘述。如以下所使用的,术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现,但是硬件,或者软件和硬件的组合的实现也是可能并被构想的。
图2是根据本发明实施例的业务处理装置的结构框图,如图2所示,该装置包括:创建模块22和处理模块24,下面对该装置进行说明。
创建模块22,设置为创建软件定义光网络SDON中多域控制器与一个或多个单域 控制器之间的第一RESTful接口,以及一个或多个单域控制器与对应域内节点之间的第二RESTful接口;处理模块24,与创建模块22连接,设置为依据创建的第一RESTful接口和/或第二RESTful接口对SDON业务进行处理。
优选地,该创建模块22还设置为在第一RESTful接口上为SDON业务提供业务对象的功能属性,所述业务对象的功能属性包括连接对象的功能属性和端点对象的功能属性。
其中,该业务对象的功能属性包括:业务对象的业务标识ID、业务对象的业务名称、业务对象的业务层次、业务对象的业务带宽、业务对象的业务状态、业务对象的保护类型、业务对象的恢复类型;SDON业务的连接对象的功能属性包括:连接对象的连接标识ID、连接对象的连接类型、连接对象的连接路径,其中,连接类型包括以下之一:工作连接、保护连接、工作恢复连接、保护恢复连接;SDON业务的端点对象的功能属性包括:端点对象的节点标识ID、端点对象的端口号。
另外,该创建模块22,还设置为在第二RESTful接口上为SDON业务提供业务对象的交叉操作功能属性,所述业务对象的交叉操作功能属性包括连接对象的交叉操作功能属性,所述连接对象的交叉操作功能属性包括端点对象的交叉信息。
其中,SDON业务的业务对象的交叉操作功能属性包括:SDON业务的业务标识ID,SDON业务在预定节点上的工作连接的交叉操作功能属性、SDON业务在预定节点上的保护连接的交叉操作功能属性;SDON业务的连接对象的交叉操作功能属性包括:SDON业务的连接对象的连接标识ID、SDON业务的连接在预定节点上的正向交叉的交叉操作功能属性、SDON业务的连接在预定节点上的反向交叉的交叉操作功能属性;SDON业务的端点对象的交叉操作功能属性包括:入端口信息、出端口信息、入标签信息、出标签信息。
优选地,该处理模块24还设置为以下之一:多域控制器通过第一RESTful接口向一个或多个单域控制器发送业务建立请求;一个或多个单域控制器通过第二RESTful接口向对应域内节点发送用于SDON业务在节点上进行交叉配置的交叉配置请求;在节点交叉配置成功的情况下,节点通过第二RESTful接口向节点所属的单域控制器反馈节点交叉配置成功的响应消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过第二RESTful接口向交叉配置成功的节点发送用于删除交叉配置成功的节点的交叉信息的删除消息;在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第一RESTful接口向多域控制器发送用于反馈本域业务建立失败的响应消息;单域控制器所属节点通过第二RESTful接口向单域控制器发送用于反馈删除交叉信息的应答消息;在单域控制器所属域内的节点均交叉配置成功的情况下,单域控制器通过第一RESTful接口向多域控制器反馈本域所有节点交 叉配置成功的响应消息;多域控制器通过第一RESTful接口向一个或多个单域控制器发送用于删除SDON业务的删除消息;一个或多个单域控制器通过第一RESTful接口向多域控制器反馈删除SDON业务的应答消息。
在具体实施中,本发明实施例的业务处理方法和业务处理装置在能实现网络设备控制面与数据面分离的情况下,实现简单,便于扩展。在相关技术中,软件定义网络的核心技术是通过OpenFlow协议将网络设备控制面与数据面分离开来,然而,光网络中采用OpenFlow协议存在以下问题,第一,OpenFlow协议最初是为数据网络而设计的,对光网络的支持依然不全面,如果各个设备厂商采用自己的私有扩展则不利于设备之间的互联互通;第二,Openflow的协议内容繁多,实现复杂,但大部分内容对光网络是无用的,直接应用在光网络中增加开发维护成本,加重系统复杂性;第三,SDN控制器和应用之间的北向接口普遍采用RESTful接口,如果和设备之间的南向接口采用OpenFlow协议则控制器需要实现两套协议栈,实现复杂,也不利于南北向接口之间的统一。
其中,表现层状态转移(Representational State Transfer,简称为REST)指的是一组架构约束条件和原则:为所有资源定义ID;将所有资源链接在一起;使用标准方法;资源多重表述;无状态通信,满足这些约束条件和原则的应用程序或设计就是RESTful。RESTful架构结构清晰,符合标准,易于理解,扩展方便。HTTP协议是RESTful架构的一个具体实例,服务器上的每种资源对应一个特定的URI,客户端和服务器之间传递这种资源的某种表现层,可以是txt/html/xml/json等格式,客户端通过四个HTTP动词(GET/POST/PUT/DELETE),对服务器端资源进行操作,实现“表现层状态转化”。
通过上述实施例及优选实施例,不仅解决了OpenFlow协议内容繁多,实现复杂,直接应用在软件定义光网络SDON增加开发维护成本,加重系统复杂性的问题;并且使SDON控制器和设备之间的南向接口与SDON控制器和应用之间的北向接口实现统一,解决了SDON控制器工作程序复杂的问题。在实现网络设备控制面与数据面分离的情况下,实现简单,便于扩展。
下面对上述实施例及优选实施例结合操作过程进行简单说明。
软件定义光网络SDON通过采用层次化的控制器结构实现跨厂商、多域组网场景下的端到端连接控制和管理,图3是根据本发明实施例的软件定义光网络的系统架构示意图,如图3所示,在SDON架构中,多域控制器和单域控制器、单域控制器和设备节点之间都可以采用RESTful架构,其中控制虚拟网络接口(Control Virtual Network Interface,简称为CVNI)和控制数据平面接口(Control Data Plane Interface,简称为CDPI)都可以采用RESTful接口实现。在多域控制器和单域控制器之间,多域控制器是客户端,单域控制器是服务器端。在单域控制器和设备节点之间,单域控制器是客 户端,设备节点是服务器端。
多域控制器和单域控制器之间的RESTful接口不仅对业务配置了业务对象Call和一些基本属性,支持业务的建立、查询、删除操作,还对业务的保护和恢复提供接口支持。为了支持业务的保护和恢复,增加了Connection对象和相关的保护恢复属性,图4是根据本发明实施例的多域控制器对单域控制器进行业务配置的REST对象图,如图4所示,业务对象及其对应的属性关系包括:
Call:业务业务对象,属性包括业务ID、名称、A端点、Z端点、层次、带宽、状态、保护类型、恢复类型、工作连接、保护连接、工作恢复连接、保护恢复连接等,其中,A端点、Z端点为EndPoint对象,工作连接、保护连接、工作恢复连接、保护恢复连接为Connection对象。
Connection:业务下的连接对象,一条业务有多条连接对象。连接对象的属性包括:连接ID、连接类型和Path,Path中记录连接的具体路径信息。
EndPoint:端点对象,主要包括节点和端口信息。
单域控制器和设备节点之间的交互主要是交叉配置操作,需要定义如下REST对象,图5是根据本发明实施例的单域控制器对设备节点进行交叉配置的REST对象类图,如图5所示,涉及的对象及其属性包括:
Call_SNC:一条业务在某个节点上的交叉信息,如果是带保护的业务,则分别有工作连接和保护连接对应的交叉信息。
Connection_SNC:一条连接在某个节点上的交叉信息,可以是某条业务的工作连接或保护连接,是Call_SNC的子对象。因为业务是双向的,所以每条连接在其经过的每个节点会有正反方向的两个交叉。
SNC:一条交叉信息,是Connection_SNC的子对象,包括入端口、入标签、出端口、出标签信息。
Call_SNC对象支持Create、Delete操作,分别对应单域控制器对设备节点进行交叉设置和删除操作。如果业务支持动态恢复,则Call_SNC对象还需要支持Update操作。
下面结合上述业务对象及其属性的说明,对本发明优选实施例的基于RESTful接口进行业务配置的流程说明,图6是根据本发明实施例的使用RESTful接口进行业务建立的流程图,如图6所示,该流程包括:
步骤S602,多域控制器根据业务请求参数计算出业务路径经过的域序列以及每个 域内的源宿节点。
步骤S604,多域控制器给业务路径经过的各个单域控制器通过RESTful接口发送业务建立请求;其中,多域控制器给单域控制器发送业务建立请求可以包括业务的源、宿节点、层次、带宽等信息。
步骤S606,各个单域控制器计算域内路径。
步骤S608,各个单域控制器给业务在本域内经过的节点通过RESTful接口发送交叉配置请求;其中,单域控制器采用RESTful接口发送交叉配置请求需要包含节点ID、业务ID、连接ID、信号类型、入端口、入标签、出端口、出标签等信息。
步骤S610,各个节点进行交叉配置操作,并给单域控制器返回交叉配置应答。其中,设备节点返回给单域控制器的应答需要标明交叉配置成功或者失败。
步骤S612,判断是否所有节点交叉配置成功;在判断结果为是的情况下,进入步骤S616;否则进入步骤S614;
步骤S614,单域控制器删除配置成功的交叉信息,即域内业务建立失败,其中,单域控制器删除配置成功的交叉信息包括单域控制器向交叉配置成功的各个节点通过RESTful接口发送交叉删除请求。
步骤S616,各个单域控制器给多域控制器返回业务建立应答,即所有节点都交叉配置成功,则域内业务建立成功。其中,单域控制器返回给多域控制器的应答中需要标明业务建立成功或者失败。成功应答需要包含业务在该域内的ID和具体的连接路径信息。业务ID由单域控制器生成,作为后续业务查询、修改和删除的标识。
步骤S618,判断是否所有单域控制器业务建立成功;即各个单域控制器给多域控制器返回业务建立应答。在判断结果为是的情况下,进入步骤S622,否则进入步骤S620;
步骤S620,业务建立失败,多域控制器删除建立成功的域内业务。
步骤S622,所有单域控制器都返回成功应答,则业务建立成功;
图7是根据本发明实施例的使用RESTful接口进行业务删除的流程图,如图7所示,多域控制器删除建立成功的域内业务的步骤包括:
步骤S702,多域控制器给域内业务建立成功的各个单域控制器通过RESTful接口发送业务删除请求;其中,多域控制器发送给单域控制器的删除请求中需要包含业务ID。
步骤S704,各个单域控制器给业务在本域内经过的节点通过RESTful接口发送交叉删除请求;其中,单域控制器采用RESTful接口对设备节点发送交叉删除请求,请求中可以包含业务ID、连接ID、入端口、入标签。
步骤S706,各个设备节点进行交叉删除,并给单域控制器返回交叉删除应答。如果所有节点都交叉删除成功,则单域控制器给多域控制器返回成功应答,否则返回失败应答。
步骤S708,各个单域控制器给多域控制器返回业务删除应答。如果所有单域控制器都返回成功应答,则业务删除成功,否则业务删除失败。
下面对本发明优选实施方式进行说明。
优选实施方式一
在本优选实施方式中,提供了一种使用RESTful接口进行域内业务建立的方法,图8是根据本发明优选实施方式的网络拓扑图,如图8所示。多域控制器管理了两个域,分别为域1和域2,单域控制器1管理域1,其IP地址为193.80.160.5,单域控制器2管理域2,其IP地址为193.90.160.5。域1中节点A、B、C、D的IP地址分别是193.80.10.5、193.80.20.5、193.80.30.5、193.80.40.5。域2中节点A1、B1、C1的IP地址分别是193.90.10.5、193.90.20.5、193.90.30.5。
多域控制器需要建立一条节点A到节点C之间的业务,业务带宽为ODU2,保护类型为1+1通道保护、恢复类型为无恢复。多域控制器通过RESTful接口发送HTTP消息给单域控制器1,REST对象采用json格式,消息格式如下:
Figure PCTCN2015092326-appb-000001
aEnd和zEnd中用“/”分割的两部分分别为节点ID和端口ID。
单域控制器1计算出业务的域内工作路径为A->B->C,保护路径为A->D->C,单域控制器1需要分别给A、B、C、D四个节点发送交叉配置信息,每条命令包含一条交叉信息。单域控制器1发送给节点的交叉配置信息REST接口定义如下,以节点B上的正向交叉为例:
Figure PCTCN2015092326-appb-000002
节点B交叉配置成功后,返回给单域控制器1成功应答,消息内容为空。
HTTP/1.1200OK
节点A、B、C、D全部交叉配置成功后,单域控制器1向多域控制器返回业务建立成功应答,消息格式如下。
Figure PCTCN2015092326-appb-000003
Figure PCTCN2015092326-appb-000004
Figure PCTCN2015092326-appb-000005
优选实施方式二
本优选实施方式中,提供了一种使用RESTful接口进行域内业务删除的方法,网络拓扑如图8所示。
多域控制器删除实施例一中建立的节点A到节点C之间的业务,多域控制器向单域控制器1发送业务删除请求,消息格式如下:
DELETE/rest/json/SERVICE_REQ_API/1-1HTTP/1.1
单域控制器1分别给节点A、B、C、D发送交叉删除请求,以节点B为例,消息格式如下:
Figure PCTCN2015092326-appb-000006
节点A、B、C、D给单域控制器1返回交叉删除的成功应答,消息内容为空。
HTTP/1.1200OK
节点A、B、C、D都返回交叉删除成功应答后,单域控制器1给多域控制器返回业务删除的成功应答,消息内容为空。
HTTP/1.1200OK
优选实施方式三
在本优选实施方式中,提供了一种使用RESTful接口进行跨域业务建立的方法,网络拓扑如图8所示。
多域控制器要建立一条节点A和节点A1之间的业务,业务带宽为ODU2,保护类型为无保护,恢复类型为动态恢复。
多域控制器计算出节点A和A1之间的业务需要经过域1和域2,在域1内的源宿节点为A、C,在域2内的源宿节点为C1、A1。
多域控制器发送给单域控制器1的消息格式如下:
Figure PCTCN2015092326-appb-000007
多域控制器发送给单域控制器2的消息格式如下:
Figure PCTCN2015092326-appb-000008
单域控制器1计算出业务在域1内的路径为A->B->C,单域控制器2计算出在域2内的路径为C1->A1。
单域控制器1分别给节点A、B、C发送交叉配置信息,信息格式如下,以节点C 上的正向交叉为例:
Figure PCTCN2015092326-appb-000009
同时单域控制器2分别给节点A1、C1发送交叉配置信息,消息格式如下,以节点C1上的正向交叉为例
Figure PCTCN2015092326-appb-000010
节点A、B、C给单域控制器1返回交叉配置成功的应答,节点A1、C1给单域控制器2返回交叉配置成功的应答,消息格式如下,消息内容为空。
HTTP/1.1200OK
单域控制器1给多域控制器返回业务建立成功的应答,消息格式如下。
Figure PCTCN2015092326-appb-000011
单域控制器2给多域控制器返回业务建立成功的应答,消息格式如下。
Figure PCTCN2015092326-appb-000012
显然,本领域的技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在存储装置中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已,并不用于限制本发明,对于本领域的技 术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

Claims (12)

  1. 一种业务处理方法,包括:
    创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及所述一个或多个单域控制器与对应域内节点之间的第二RESTful接口;
    依据创建的所述第一RESTful接口和/或所述第二RESTful接口对SDON业务进行处理。
  2. 根据权利要求1所述的方法,其中,创建所述SDON中所述多域控制器与所述一个或多个单域控制器之间的所述第一RESTful接口包括:
    在所述第一RESTful接口上为所述SDON业务提供业务对象的功能属性,所述业务对象的功能属性包括连接对象的功能属性和端点对象的功能属性。
  3. 根据权利要求2所述的方法,其中,
    所述连接对象的功能属性包括:连接对象的连接标识ID、连接对象的连接类型、连接对象的连接路径,其中,所述连接类型包括以下之一:工作连接、保护连接、工作恢复连接、保护恢复连接;
    所述端点对象的功能属性包括:端点对象的节点标识ID、端点对象的端口号。
  4. 根据权利要求1所述的方法,其中,创建所述SDON中所述一个或多个单域控制器与对应域内节点之间的所述第二RESTful接口包括:
    在所述第二RESTful接口上为所述SDON业务提供业务对象的交叉操作功能属性,所述业务对象的交叉操作功能属性包括连接对象的交叉操作功能属性,所述连接对象的交叉操作功能属性包括端点对象的交叉操作功能属性。
  5. 根据权利要求4所述的方法,其中,
    所述端点对象的交叉操作功能属性,包括:入端口信息、出端口信息、入标签信息、出标签信息。
  6. 根据权利要求1所述的方法,其中,依据创建的所述第一RESTful接口和/或所述第二RESTful接口对SDON业务进行处理包括以下之一:
    多域控制器通过所述第一RESTful接口向业务路径经过的各域对应的所述一个或多个单域控制器发送业务建立请求;
    所述一个或多个单域控制器通过所述第二RESTful接口向对应域内业务路径经过的节点发送用于所述SDON业务在所述节点上进行交叉配置的交叉配置请 求;
    在节点交叉配置成功的情况下,所述节点通过所述第二RESTful接口向所述节点所属的单域控制器反馈节点交叉配置成功的响应消息;
    在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第二RESTful接口向交叉配置成功的节点发送用于删除所述交叉配置成功的节点的交叉信息的删除消息;
    在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第一RESTful接口向多域控制器发送用于反馈本域业务建立失败的响应消息;
    单域控制器所属节点通过所述第二RESTful接口向所述单域控制器发送用于反馈删除交叉信息的应答消息;
    在单域控制器所属域内的节点均交叉配置成功的情况下,所述单域控制器通过所述第一RESTful接口向所述多域控制器反馈本域业务建立成功的响应消息;
    多域控制器通过所述第一RESTful接口向所述一个或多个单域控制器发送用于删除SDON业务的删除消息;
    所述一个或多个单域控制器通过所述第一RESTful接口向所述多域控制器反馈删除所述SDON业务的应答消息。
  7. 一种业务处理装置,包括:
    创建模块,设置为创建软件定义光网络SDON中多域控制器与一个或多个单域控制器之间的第一RESTful接口,以及所述一个或多个单域控制器与对应域内节点之间的第二RESTful接口;
    处理模块,设置为依据创建的所述第一RESTful接口和/或所述第二RESTful接口对SDON业务进行处理。
  8. 根据权利要求7所述的装置,其中,所述创建模块,还设置为在所述第一RESTful接口上为所述SDON业务提供业务对象的功能属性,所述业务对象的功能属性包括连接对象的功能属性和端点对象的功能属性。
  9. 根据权利要求8所述的装置,其中,
    所述连接对象的功能属性包括:连接对象的连接标识ID、连接对象的连接类型、连接对象的连接路径,其中,所述连接类型包括以下之一:工作连接、保护 连接、工作恢复连接、保护恢复连接;
    所述端点对象的功能属性包括:端点对象的节点标识ID、端点对象的端口号。
  10. 根据权利要求7所述的装置,其中,所述创建模块,还设置为在所述第二RESTful接口上为所述SDON业务提供业务对象的交叉操作功能属性,所述业务对象的交叉操作功能属性包括连接对象的交叉操作功能属性,所述连接对象交叉操作功能属性包括端点对象的交叉操作功能属性。
  11. 根据权利要求10所述的装置,其中,
    所述端点对象的交叉操作功能属性包括:入端口信息、出端口信息、入标签信息、出标签信息。
  12. 根据权利要求10所述的装置,其中,所述处理模块,还设置为以下之一:
    多域控制器通过所述第一RESTful接口向所述一个或多个单域控制器发送业务建立请求;
    所述一个或多个单域控制器通过所述第二RESTful接口向对应域内业务路径经过的节点发送用于所述SDON业务在所述节点上进行交叉配置的交叉配置请求;
    在节点交叉配置成功的情况下,所述节点通过所述第二RESTful接口向所述节点所属的单域控制器反馈节点交叉配置成功的响应消息;
    在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第二RESTful接口向交叉配置成功的节点发送用于删除所述交叉配置成功的节点的交叉信息的删除消息;
    在单域控制器接收到域内所属节点交叉配置失败的响应消息的情况下,通过所述第一RESTful接口向多域控制器发送用于反馈本域业务建立失败的响应消息;
    单域控制器所属节点通过所述第二RESTful接口向所述单域控制器发送用于反馈删除交叉信息的应答消息;
    在单域控制器所属域内的节点均交叉配置成功的情况下,所述单域控制器通过所述第一RESTful接口向所述多域控制器反馈本域业务建立成功的响应消息;
    在多域控制器通过所述第一RESTful接口向所述一个或多个单域控制器发送用于删除SDON业务的删除消息;
    所述一个或多个单域控制器通过所述第一RESTful接口向所述多域控制器反馈删除所述SDON业务的应答消息。
PCT/CN2015/092326 2014-12-12 2015-10-20 业务处理方法及装置 WO2016091013A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410768528.3A CN105744386A (zh) 2014-12-12 2014-12-12 业务处理方法及装置
CN201410768528.3 2014-12-12

Publications (1)

Publication Number Publication Date
WO2016091013A1 true WO2016091013A1 (zh) 2016-06-16

Family

ID=56106648

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/092326 WO2016091013A1 (zh) 2014-12-12 2015-10-20 业务处理方法及装置

Country Status (2)

Country Link
CN (1) CN105744386A (zh)
WO (1) WO2016091013A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412826A (zh) * 2017-08-18 2019-03-01 中兴通讯股份有限公司 Sdon架构模型优化方法、装置、系统及计算机可读存储介质
CN111600736A (zh) * 2019-02-21 2020-08-28 中国信息通信研究院 一种光传送网络中多域集中式恢复方法、装置和系统

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107493523B (zh) * 2017-09-13 2021-02-12 苏州大学 一种全光数据中心网络交换系统
CN109962937B (zh) * 2017-12-14 2021-08-17 中兴通讯股份有限公司 一种多域多层连接业务建立方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014166399A1 (en) * 2013-04-10 2014-10-16 Huawei Technologies Co., Ltd. System and method for a control plane reference model framework
WO2014166758A1 (en) * 2013-04-09 2014-10-16 Alcatel Lucent Control system, apparatus, methods, and computer readable storage medium storing instructions for a network node and/or a network controller

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9094148B2 (en) * 2013-05-10 2015-07-28 Nec Laboratories America, Inc. Adaptive optical amplifier for WDM systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014166758A1 (en) * 2013-04-09 2014-10-16 Alcatel Lucent Control system, apparatus, methods, and computer readable storage medium storing instructions for a network node and/or a network controller
WO2014166399A1 (en) * 2013-04-10 2014-10-16 Huawei Technologies Co., Ltd. System and method for a control plane reference model framework

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZHANG, PENG.: "SDN Solves Multi-vendor Networking Problem: China Telecom and Equipment Firms Combined Together Complete the First SDON Multi-domain Networking Test", COMMUNICATIONS WORLD, 25 September 2014 (2014-09-25), pages 13, ISSN: 1009-1584 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109412826A (zh) * 2017-08-18 2019-03-01 中兴通讯股份有限公司 Sdon架构模型优化方法、装置、系统及计算机可读存储介质
CN111600736A (zh) * 2019-02-21 2020-08-28 中国信息通信研究院 一种光传送网络中多域集中式恢复方法、装置和系统

Also Published As

Publication number Publication date
CN105744386A (zh) 2016-07-06

Similar Documents

Publication Publication Date Title
US11563669B2 (en) Method for implementing network virtualization and related apparatus and communications system
CN107147509B (zh) 虚拟专用网业务实现方法、装置及通信系统
EP2989749B1 (en) Network resource monitoring
RU2595540C9 (ru) Базовые контроллеры для преобразования универсальных потоков
US8959185B2 (en) Multitenant server for virtual networks within datacenter
TW201543243A (zh) 在服務導向架構中的監控能力
CN103825954A (zh) 一种OpenFlow控制方法及相应插件、平台和网络
WO2016091013A1 (zh) 业务处理方法及装置
EP3682597B1 (en) Modeling access networks as trees in software-defined network controllers
WO2016095493A1 (zh) 一种资源虚拟化处理的方法、装置及控制器
EP2913964A1 (en) Software-defined networking event distribution method, control device, and processor
CN115118585A (zh) 一种业务的部署方法、装置及系统
US10110423B2 (en) System and method for managing network connections
US11438420B2 (en) Method and device for establishing multi-domain multi-layer connectivity service
EP3370392B1 (en) Controller-to-controller interface for multi-layer network abstraction
CN104883263A (zh) 一种网络集中控制方法、系统以及多域控制器
CN116996585A (zh) 组播通信方法、装置、系统、计算机设备和存储介质
CN108259345A (zh) 端口生成方法和装置
JPWO2016068238A1 (ja) ネットワークの制御システム、制御装置、ネットワーク情報の管理方法及びプログラム
EP4145795B1 (en) Runtime extensible application programming interface server
US10601649B1 (en) Stack switching detection and provisioning
US11463324B2 (en) Systems and methods for supporting connectivity to multiple VRFs from a data link
CN106878051A (zh) 一种多机备份实现方法及装置
CN113938534A (zh) 协同方法及装置
US9860128B2 (en) Automated command and discovery process for network communications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15866623

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15866623

Country of ref document: EP

Kind code of ref document: A1