WO2017101815A1 - 一种消息处理方法、装置和系统 - Google Patents

一种消息处理方法、装置和系统 Download PDF

Info

Publication number
WO2017101815A1
WO2017101815A1 PCT/CN2016/110123 CN2016110123W WO2017101815A1 WO 2017101815 A1 WO2017101815 A1 WO 2017101815A1 CN 2016110123 W CN2016110123 W CN 2016110123W WO 2017101815 A1 WO2017101815 A1 WO 2017101815A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
content
information
application
service
Prior art date
Application number
PCT/CN2016/110123
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 华为技术有限公司
Priority to EP16874872.1A priority Critical patent/EP3379771B1/en
Publication of WO2017101815A1 publication Critical patent/WO2017101815A1/zh
Priority to US16/010,041 priority patent/US10592316B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Definitions

  • the present invention relates to the field of data communications, and in particular, to a message processing method, apparatus, and system.
  • SDN Software Defined Network
  • SDN Software Defined Network
  • forwarding and control of network devices are separated to form mutually independent forwarding planes (English: Forwarding Plane) and control planes (English: Control Plane).
  • Application Plane Network users and network applications are in the application plane (English: Application Plane).
  • Application Plane For the specific architecture of the SDN, refer to Figure 1.
  • the application plane interacts with the control plane, and the control plane interacts with the forwarding plane.
  • the application plane can send a service request to the control plane, and the control plane determines the control requirement for implementing the service requirement on the SDN according to the content carried in the received service requirement.
  • the service requirements described herein can be understood as an abstract description of the network requirements, such as connectivity, bandwidth, service deployment life cycle, etc., so that the application plane no longer needs to describe to the control plane how these requirements can be implemented on the network.
  • an embodiment of the present invention provides a message processing method, apparatus, and system, which implements a service requirement to control demand conversion between an application plane and a control plane.
  • an embodiment of the present invention provides a message processing method, which is applied to an SDN, where the method includes:
  • the application sends a first message to the controller, where the first message includes a message header and a message content, where The message header of the first message is used to identify that the message type of the first message is a request message, and the message content of the first message includes service content for describing a service requirement, and the service content includes target information and operation information.
  • the target information is used to identify a target object, and the operation information is used to identify an operation for implementing the service requirement on the target object;
  • the application receives a second message sent by the controller, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response message.
  • the message content of the second message includes scenario information for implementing at least one solution of the service content, the scenario information includes a scenario description of the at least one scenario, or a scenario identifier corresponding to the at least one scenario;
  • the application identifies the second message as a response message according to a message header of the second message
  • the service content further includes constraint information and/or context information, where the constraint information of the service content includes a constraint for identifying the service content, and the context information of the service content includes The environmental information of the business content, where the environmental information includes a combination of any one or more of an application environment parameter, a network environment parameter, and an application scenario source.
  • the message content of the second message further includes a constraint dimension item and/or a context requirement item, where the constraint dimension item is used to request the application to reply to a constraint for the service content, the context requirement item Used to request the application to reply to environmental information for the business content;
  • the method further includes:
  • the application sends a third message to the controller, where the third message includes a message header and a message content, and a message header of the third message is used to identify that the message type of the third message is a request message,
  • the message content of the third message includes the first supplementary content, wherein if the message content of the second message includes a constraint dimension item, the first supplementary content includes a constraint dimension of the second message The constraint condition required in the item; if the message content of the second message includes a context requirement item, the first supplementary content includes environment information required in a context requirement item of the second message.
  • the third message and the first message each carry an object identifier for identifying the target object
  • the message content of the third message includes the service content and the first supplementary content.
  • the method further includes:
  • the application receives a fourth message sent by the controller, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is a response message.
  • the message content of the fourth message includes a constraint dimension item and/or a context requirement item;
  • the application identifies the fourth message as a response message according to a message header of the fourth message
  • the application sends a fifth message to the controller, where the fifth message includes a message header and a message content, and a message header of the fifth message is used to identify that the message type of the fifth message is a request message,
  • the message content of the fifth message includes the second supplementary content, wherein if the message content of the fourth message includes a constraint dimension item, the second supplementary content includes a requirement in a constraint dimension item of the fourth message a constraint condition; if the message content of the fourth message includes a context requirement item, the second supplemental content includes environment information required in a context requirement item of the fourth message.
  • the target information is placed in a target field of the message content of the request message, and the operation information is placed in an operation field of the message content of the request message;
  • the constraint information is placed in a constraint field of a message content of the request message;
  • the context information is placed in a context field of a message content of the request message;
  • the constraint dimension of the second message is placed in the constraint field of the message content of the request message, and the environment information required in the context requirement item of the second message is placed in the context field of the message content of the request message;
  • the constraint required in the constraint dimension item of the fourth message is placed in a constraint field of the message content of the request message, and the context requirement item of the fourth message
  • the environment information required in the context is placed in the context field of the message content of the request message.
  • the method further includes:
  • the application sends a sixth message to the controller, where the sixth message includes a message header and a message content, and a message header of the sixth message is used to identify that the message type of the sixth message is a selection message,
  • the message content of the sixth message includes a target solution selected by the application from the scenario information of the at least one scenario or a scenario identifier of the target scenario;
  • the application receives a seventh message sent by the controller for the sixth message, where the seventh message includes a message header and a message content, and a message header of the seventh message is used to identify the message of the seventh message.
  • the type is a confirmation message
  • the message content of the seventh message includes an implementation result of the target solution, and the implementation result is used to identify whether the target solution is implemented.
  • an embodiment of the present invention provides a message processing apparatus, which is applied to an SDN, where the apparatus includes:
  • a sending unit configured to send a first message to the controller, where the first message includes a message header and a message content, where a message header of the first message is used to identify that the message type of the first message is a request message,
  • the message content of the first message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify the target object.
  • a receiving unit configured to receive a second message sent by the controller, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response message
  • the message content of the second message includes scenario information for implementing at least one solution of the service content, the scenario information includes a scenario description of the at least one scenario, or includes a scenario identifier corresponding to the at least one scenario ;
  • An identifying unit configured to identify the second message as a response message according to a message header of the second message
  • an obtaining unit configured to acquire scheme information of the at least one solution according to the message content of the second message.
  • the service content further includes constraint information and/or context information, where the constraint information of the service content includes a constraint for identifying the service content, and the context information of the service content includes The environmental information of the business content, where the environmental information includes a combination of any one or more of an application environment parameter, a network environment parameter, and an application scenario source.
  • the message content of the second message further includes a constraint dimension item and/or a context requirement item, where the constraint dimension item is used to request the application to reply to a constraint for the service content, the context requirement item Used to request the application to reply to environmental information for the business content;
  • the obtaining unit is further configured to acquire, according to the message content of the second message, a constraint dimension item and/or a context requirement item included in the second message, and acquire scenario information of at least one solution included in the second message. .
  • the device further includes:
  • a determining unit configured to determine, according to the constraint dimension item and/or the context requirement item included in the second message, the first supplemental content
  • the sending unit is further configured to send a third message to the controller, where the third message includes a message header and a message content, and a message header of the third message is used to identify that the message type of the third message is a request a message, the message content of the third message includes the first supplementary content, wherein if the message content of the second message includes a constraint dimension item, the first supplemental content includes a constraint dimension item of the second message The constraint condition required in the message; if the message content of the second message includes a context requirement item, the first supplemental content includes environment information required in a context requirement item of the second message.
  • the third message and the first message each carry an object identifier for identifying the target object
  • the message content of the third message includes the service content and the first supplementary content.
  • the receiving unit is further configured to receive a fourth message sent by the controller, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is Responding to the message, the message content of the fourth message includes a constraint dimension item and/or a context requirement item;
  • the identifying unit is further configured to identify the fourth message as a response message according to a message header of the fourth message;
  • the obtaining unit is further configured to acquire, according to the message content of the fourth message, a constraint dimension item and/or a context requirement item included in the fourth message;
  • the determining unit is further configured to determine the second supplementary content according to the constraint dimension item and/or the context requirement item included in the fourth message;
  • the sending unit is further configured to send a fifth message to the controller, where the fifth message includes a message header and a message content, and a message header of the fifth message is used to identify that the message type of the fifth message is a request a message, the message content of the fifth message includes the second supplementary content, wherein if the message content of the fourth message includes a constraint dimension item, the second supplementary content includes a constraint dimension item of the fourth message The constraint condition required in the message; if the message content of the fourth message includes a context requirement item, the second supplementary content includes environment information required in a context requirement item of the fourth message.
  • the target information is placed in a target field of the message content of the request message, and the operation information is placed in an operation field of the message content of the request message;
  • the constraint information is placed in a constraint field of a message content of the request message;
  • the context information is placed in a context field of a message content of the request message;
  • the constraint required in the constraint dimension item of the second message is placed in a constraint field of the message content of the request message, and the context requirement item of the second message
  • the environment information required in the context is placed in the context field of the message content of the request message;
  • the constraint required in the constraint dimension item of the fourth message is placed in a constraint field of the message content of the request message, and the context requirement item of the fourth message
  • the environment information required in the context is placed in the context field of the message content of the request message.
  • the sending unit is further configured to send a sixth message to the controller, where the sixth message includes And a message header, the message header of the sixth message is used to identify that the message type of the sixth message is a selection message, and the message content of the sixth message includes scenario information of the application from the at least one scenario. a target scheme selected in the scheme or a scheme identifier of the target scheme;
  • the receiving unit is further configured to receive a seventh message sent by the controller for the sixth message, where the seventh message includes a message header and a message content, where a message header of the seventh message is used to identify the
  • the message type of the seven message is an acknowledgment message
  • the message content of the seventh message includes an implementation result of the target solution, and the implementation result is used to identify whether the target solution is implemented.
  • an embodiment of the present invention provides a message processing method, which is applied to an SDN, where the method includes:
  • the controller obtains a first message sent by the application, where the first message includes a message header and a message content, and the message header of the first message is used to identify that the message type of the first message is a request message, the first message
  • the message content includes service content for explaining a business requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify that the target object is implemented on the target object. Operation of business requirements;
  • the controller identifies the first message as a request message according to a message header of the first message
  • the controller acquires the service content according to the message content of the first message
  • the controller sends a second message to the application, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response message.
  • the message content of the second message includes scenario information of the at least one scenario, the scenario information includes a scenario description of the at least one scenario, or a scenario identifier corresponding to the at least one scenario.
  • the service content further includes constraint information and/or context information, where the constraint information of the service content includes a constraint for identifying the service content, and the context information of the service content includes The environmental information of the business content, where the environmental information includes a combination of any one or more of an application environment parameter, a network environment parameter, and an application scenario source.
  • the controller determines, according to the service content, that the application is requested to reply to the constraint of the service content and/or Requesting the application to reply to environmental information for the business content;
  • the message content of the second message further includes a constraint dimension item and/or a context requirement item, the A bundle dimension item is used to request the application to reply to a constraint for the business content, the context requirement item for requesting the application to reply to environmental information for the business content.
  • the method further includes:
  • the controller acquires a third message, where the third message includes a message header and a message content, and a message header of the third message is used to identify that the message type of the third message is a request message, and the third message is
  • the message content includes supplementary content
  • the constraint content includes constraint information and/or context information
  • the constraint information of the supplementary content includes a constraint condition for the service content
  • the context information of the supplementary content includes the service for the service
  • Environmental information of the content
  • the controller identifies the third message as a request message according to a message header of the third message
  • the controller acquires a message content of the third message.
  • the third message and the first message each carry an object identifier for identifying the target object, where the method further includes :
  • the controller When the controller acquires the third message, the controller extracts the saved service content according to the object identifier carried by the third message;
  • Determining, by the controller, at least one solution for implementing the service content according to the service content including:
  • the controller determines, according to the service content, at least one solution for implementing the service content, including:
  • the controller determines at least one solution for implementing the service content according to the service content and the supplementary content.
  • the controller determines, according to the service content, that the application is requested to reply to the constraint and/or the request for the service content.
  • the application replies to environmental information for the business content;
  • the controller sends a fourth message to the application, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is a response message,
  • the message content of the fourth message includes the constraint dimension item and/or a context requirement item, the constraint dimension item is used to request the application to reply to a constraint for the service content, the context requirement item is used to request the The application replies to environmental information for the business content.
  • the method further includes:
  • the controller acquires a third message, where the third message includes a message header and a message content, and a message header of the third message is used to identify that the message type of the third message is a request message, and the third message is
  • the message content includes supplementary content
  • the constraint content includes constraint information and/or context information
  • the constraint information of the supplementary content includes a constraint condition for the service content, where the context message of the supplementary content includes the service Environmental information of the content;
  • the controller identifies the third message as a request message according to a message header of the third message
  • the controller acquires a message content of the third message.
  • the third message and the first message each carry an object identifier for identifying the target object, where the method further includes :
  • the controller When the controller acquires the third message, the controller extracts the saved service content according to the object identifier carried by the third message;
  • the controller determines, according to the service content, that the application is requested to reply to the constraint and/or the request for the service content.
  • the application replies to environmental information for the business content, including:
  • the controller determines, according to the supplementary content and the service content, that the application reply is requested for the Constraints of the business content and/or requesting the application to reply to environmental information for the business content;
  • the controller determines that the application is requested to reply to the constraint of the service content and/or requests the application to reply to the environment information for the service content, including:
  • the controller determines, according to the supplementary content and the service content, that the application reply is requested for the Constraints of the business content and/or requesting the application to reply to environmental information for the business content.
  • the method further includes:
  • the controller acquires a sixth message sent by the application, where the sixth message includes a message header and a message content, and a message header of the sixth message is used to identify that the message type of the sixth message is a selection message.
  • the message content of the sixth message includes a target solution selected by the application from the solution information of the at least one solution or a solution identifier of the target solution;
  • the controller identifies the sixth message as a selection message according to a message header of the sixth message
  • the controller sends a seventh message for the sixth message to the application, where the seventh message includes a message header and a message content, and a message header of the seventh message is used to identify the message of the seventh message.
  • the type is a confirmation message
  • the message content of the seventh message includes an implementation result of the target solution, and the implementation result is used to identify whether the target solution is implemented.
  • an embodiment of the present invention provides a message processing apparatus, which is applied to an SDN, where the apparatus includes:
  • a receiving unit configured to acquire a first message sent by the application, where the first message includes a message header and a message content, where a message header of the first message is used to identify that the message type of the first message is a request message,
  • the message content of the first message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify the target object.
  • An identifying unit configured to identify, according to a message header of the first message, the first message as a request message
  • An obtaining unit configured to acquire the service content according to the message content of the first message
  • a determining unit configured to determine, according to the service content, at least one solution for implementing the service content
  • a sending unit configured to send a second message to the application, where the second message includes a message header And a message content, the message header of the second message is used to identify that the message type of the second message is a response message, and the message content of the second message includes scenario information of the at least one scenario, where the scenario information includes A scheme description of the at least one scheme, or a scheme identifier corresponding to the at least one scheme.
  • the service content further includes constraint information and/or context information, where the constraint information of the service content includes a constraint for identifying the service content, and the context information of the service content includes The environmental information of the business content, where the environmental information includes a combination of any one or more of an application environment parameter, a network environment parameter, and an application scenario source.
  • the determining unit is further configured to determine, according to the service content, that the application is requested to reply to the constraint for the service content. And/or requesting the application to reply to environmental information for the business content;
  • the message content of the second message further includes a constraint dimension item and/or a context requirement item, the constraint dimension item is used to request the application to reply to a constraint for the service content, where the context requirement item is used to request the location
  • the application replies to environmental information for the business content.
  • the receiving unit is further configured to acquire a third message, where the third message includes a message header and a message content, where a message header of the third message is used to identify that the message type of the third message is a request message, where the The message content of the three messages includes supplementary content, the supplementary content includes constraint information and/or context information, and the constraint information of the supplementary content includes a constraint condition for the service content, and the context information of the supplementary content includes Environmental information of the business content;
  • the identifying unit is further configured to identify the third message as a request message according to a message header of the third message;
  • the obtaining unit is further configured to acquire a message content of the third message.
  • the third message and the first message each carry an object identifier for identifying the target object, where the method further includes :
  • the receiving unit is further configured to: when acquiring the first message, save the service content and record the object identifier;
  • the object identifier extracts the saved business content
  • the determining unit is further configured to determine, according to the service content and the supplementary content, at least one solution for implementing the service content;
  • the determining unit is further configured to determine, according to the service content and the supplementary content, at least one solution for implementing the service content.
  • the determining unit is further configured to determine, according to the service content, that the application is requested to reply to the constraint condition of the service content and/or Or requesting the application to reply to environmental information for the business content;
  • the sending unit is further configured to send a fourth message to the application, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is a response message.
  • the message content of the fourth message includes the constraint dimension item and/or a context requirement item, where the constraint dimension item is used to request the application to reply to a constraint for the service content, where the context requirement item is used
  • the application is requested to reply to environmental information for the business content.
  • the receiving unit is further configured to acquire a third message, where the third message includes a message header and a message content, where a message header of the third message is used to identify that the message type of the third message is a request message, where the The message content of the three messages includes supplementary content, the supplementary content includes constraint information and/or context information, and the constraint information of the supplementary content includes a constraint for the service content, and the context message of the supplementary content includes Environmental information of the business content;
  • the identifying unit is further configured to identify the third message as a request message according to a message header of the third message;
  • the obtaining unit is further configured to acquire a message content of the third message.
  • the third message and the first message each carry an object identifier that is used to identify the target object.
  • the receiving unit is further configured to: when acquiring the first message, save the service content and record the object identifier;
  • the receiving unit when acquiring the third message, is further configured to extract, according to the object identifier carried in the third message, the saved service content;
  • the determining unit is further configured to determine, according to the supplementary content and the service content, that the application is requested to reply to the service content. Constraints and/or requesting the application to reply to environmental information for the business content;
  • the determining unit is further configured to use the supplementary content and The service content determines that the application is requested to reply to the constraint of the service content and/or requests the application to reply to environmental information for the service content.
  • the receiving unit is further configured to acquire a sixth message sent by the application, where the sixth message includes a message header and a message content, and a message header of the sixth message is used to identify that the message type of the sixth message is selected.
  • a message, the message content of the sixth message includes a target solution selected by the application from the solution information of the at least one solution or a solution identifier of the target solution;
  • the identifying unit is further configured to identify the sixth message as a selection message according to a message header of the sixth message;
  • the determining unit is further configured to determine, according to the message content of the sixth message, an implementation result of the target solution, where the implementation result is used to identify whether the target solution is implemented;
  • the sending unit is further configured to send, to the application, a seventh message for the sixth message, where the seventh message includes a message header and message content, and a message header of the seventh message is used to identify the seventh message.
  • the message type of the message is an acknowledgment message
  • the message content of the seventh message includes an implementation result of the target solution, and the implementation result is used to identify whether the target solution is implemented.
  • an embodiment of the present invention provides a message processing system, which is applied to an SDN, where the system includes an application and a controller:
  • the application is configured to send a first message to the controller, where the first message includes a message header and a message content, and a message header of the first message is used to identify that the message type of the first message is a request message.
  • the message content of the first message includes service content for describing a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify the An operation of implementing the service requirement on the target object; receiving a second message sent by the controller, the second message includes a message header and a message content, and a message header of the second message is used to identify the second message
  • the message type is a response message, and the second message is cancelled.
  • the content information includes solution information for implementing at least one solution of the service content, the solution information includes a scenario description of the at least one scenario, or a scenario identifier corresponding to the at least one scenario; according to the second message
  • the message header identifies the second message as a response message; and according to the message content of the second message, acquiring solution information of the at least one solution;
  • the controller is configured to acquire the first message sent by the application, identify the first message as a request message according to a message header of the first message, and acquire a location according to the message content of the first message. Determining, according to the service content, at least one solution for implementing the service content; and sending the second message to the application.
  • the type of the first message is defined by the message header of the first message, and the service content of the first message is carried by the message content of the first message, so that the application in the application plane can be used.
  • the first message sends a target object in the business requirement and an operation to implement the service requirement on the target object to a controller at a control level.
  • the type of the second message is defined by a message header of the second message, and the service content of the second message is carried by the message content of the second message, when the second message sent from the controller is received
  • the application may identify and obtain the solution information carried in the message content of the second message for implementing at least one solution of the service content, thereby implementing the service requirement between the application plane and the control plane. Control demand conversion.
  • 1 is a schematic diagram of an architecture of an SDN
  • FIG. 2 is a schematic diagram of a message format of a message according to an embodiment of the present invention.
  • FIG. 3 is a schematic diagram of message interaction signaling of an application plane and a control plane according to an embodiment of the present disclosure
  • FIG. 4 is a second schematic diagram of message interaction signaling of an application plane and a control plane according to an embodiment of the present disclosure
  • FIG. 5 is a third schematic diagram of message interaction signaling of an application plane and a control plane according to an embodiment of the present invention.
  • FIG. 6 is a fourth schematic diagram of message interaction signaling of an application plane and a control plane according to an embodiment of the present disclosure
  • FIG. 7 is a schematic diagram of an application scenario according to an embodiment of the present disclosure.
  • FIG. 8 is a structural diagram of a device of a message processing apparatus according to an embodiment of the present disclosure.
  • FIG. 9 is a structural diagram of a device of a message processing apparatus according to an embodiment of the present invention.
  • FIG. 10 is a schematic structural diagram of a system of a message processing system according to an embodiment of the present disclosure.
  • FIG. 11 is a hardware structural diagram of an application device according to an embodiment of the present disclosure.
  • FIG. 12 is a schematic structural diagram of a hardware of a controller according to an embodiment of the present invention.
  • the current focus has shifted to between the application plane and the control plane. It is hoped that the application plane can realize only the intent of the user, without paying attention to the specific implementation details of the user's intention in the SDN. .
  • the application plane needs to clearly express and reflect the user's intention through the abstract description of the business requirements.
  • the control plane needs to be able to understand the description in the service requirements provided by the application plane for embodying the user's intention, and provide a corresponding network implementation, that is, determine the control requirements specifically for implementing the service requirement in the SND. It can be seen that how to implement the business requirement to control demand conversion between the application plane and the control plane in the SDN is a technical problem to be solved urgently.
  • the control plane can provide a northbound interface (English: Northbound Interface, abbreviated: NBI) for interacting with the application plane.
  • NBI Northbound Interface
  • the NBI provided to the application plane may be based on an intent-based northbound interface (English: Intent-based NBI).
  • This intent-based northbound interface is a highly abstract, network-specific implementation-independent northbound interface that describes user intent.
  • the application plane only needs An abstract description of network requirements, such as connectivity, bandwidth, and business deployment lifecycle.
  • the application plane only needs to pay attention to the user's intention, and does not need to describe how the network implements the user's intention.
  • the control plane converts the mapping into a control requirement for network resources according to the specific syntax and semantic description used by the application plane to the user's requirements.
  • the intent negotiation process between the application plane and the control plane can realize the conversion of the service requirement to the control requirement.
  • the Intent-based NBI implementation standard is fundamentally defined, such that between the application plane and the control plane. It is possible to achieve business requirements to control demand conversion through standards.
  • an embodiment of the present invention provides a message processing method, apparatus, and system, which defines a type of the first message by using a message header of the first message, and carries a service for indicating a service requirement by using a message content of the first message.
  • the content is such that the application at the application plane can use the first message to send the target object in the business requirement and the operation to implement the service requirement on the target object to a controller at a control level.
  • the type of the second message is defined by a message header of the second message, and the service content of the second message is carried by the message content of the second message, when the second message sent from the controller is received
  • the application may identify and obtain at least one solution carried in the message content of the second message for implementing the service content, thereby implementing a service requirement to control demand conversion between the application plane and the control plane.
  • the application may be understood as an application plane in an SDN, and the application may be a series of applications, and the application may reside on any number of physical platforms or virtual platforms. Any number of software components to implement.
  • the physical platform may be a physical device such as a physical server, and the virtual platform may be a virtual device (English: Virtual Machine, abbreviated: VM), and the software component may be an application process, a thread, or the like.
  • the application may be a network application, for example, a Bandwidth on Demand (English: Bandwidth on Demand, BoD) application, an SFC application (a service function serial connection technology, and English Service Function Chaining).
  • the application can send network requirements and expected established network behaviors to the network controller through an abstract interface provided by the network controller, either directly or in a programmed manner.
  • the application typically drives the adaptation of the business logic and one or more different underlying network technologies to accomplish the description of the business requirements required by the business.
  • the controller can control, manage, and configure the network resources according to the service requirements described by the application, and meet the network service customization requirements.
  • the controller can be understood as a control plane in the SDN and is a software entity that can control the network resource set.
  • the controller can be implemented by any number of software components residing on any number of physical platforms.
  • the controller may be a network controller, such as OpenDaylight (a distributed network controller), ONOS (an open network operating system), Floodlight (an OpenFlow controller), and the like.
  • OpenDaylight a distributed network controller
  • ONOS an open network operating system
  • Floodlight an OpenFlow controller
  • the message type of the message may be identified by a message header portion of a message, which may include a request (English: request) message, a response (English: response) message, a selection (English: selection) message, and an acknowledgment (English: confirmation) message.
  • request English: request
  • response English: response
  • selection English: selection
  • acknowledgment English: confirmation
  • the type of the message can be identified by the message header of the message.
  • the content carried in the message content of a message is related to the message type of this message.
  • the message content of the message may carry service content for explaining the service requirement and/or supplementary content for supplementing the service requirement. It can be seen that the request message is sent by the application to the controller, and the content carried by the request message is used to indicate to the controller what the user intention is.
  • the message content of the message may carry scenario information of at least one solution for implementing the service content and/or content for requesting the application to be supplemented, and the requested content may be bound by a dimension item and / or context requirements are carried.
  • the constraint dimension item is used to request the application to reply to a constraint for the service content
  • the context requirement item is used to request the application to reply to environment information for the service content.
  • the solution information of at least one of the scenarios described herein may include a specific scenario description of the at least one scenario, the scenario description may include a specific implementation description for the at least one scenario,
  • the main functional characteristics of each module in the at least one solution, the dependencies between the modules, the processing logic sequence, the correspondence between the functions of the modules and the service requirements, and the like may be included.
  • the solution information of the at least one solution may also include the solution identifier corresponding to the at least one solution. It is noted that, in order to play a clear identification role, in general, a solution has a unique solution identifier.
  • the scheme identifier may be in the form of a string, or may directly use the scheme name as a scheme identifier, or may be another identifier form capable of uniquely identifying the at least one scheme.
  • the solution information is the solution identifier
  • a prior network negotiation is required between the application and the controller, so that the application can understand the specific content or the approximate process of the identified solution by using the solution identifier.
  • the response message is sent by the controller to the application, and the content carried by the response message is displayed to the application, and how the user intention is implemented by using SDN.
  • the controller does not actively send a response message to the application, and the controller mainly returns a corresponding response message to the application after receiving the request message sent by the application. .
  • a message is a selection message
  • the message content of the message includes an identifier of the target scheme or the target scheme selected by the application. It can be seen that the selection message is sent by the application to the controller, and the content carried by the selection message is used to inform the controller, the solution selected by the application.
  • a message is a confirmation message
  • the message content of the message includes an implementation result of the target solution, that is, an implementation result of the controller in the network for the target solution.
  • the confirmation message is sent by the controller to the application, and the content carried by the confirmation message is used to inform the application whether the target solution is implemented in the network.
  • the controller does not actively send an acknowledgment message to the application, and the controller mainly returns a corresponding acknowledgment message to the application after receiving the selection message sent by the application. .
  • the content that can be included in the message content will be described in detail next.
  • the content carried in the message content of different types of messages is different.
  • the message content is classified into categories, and the content of the message is described.
  • the message content of a request message may include a target field (English: object), an operation field (English: operation), and a constraint field (English: constraint). These three fields can be regarded as a three-tuple (English: 3-tuple pattern) in the message content.
  • the fields of the triplet are collectively referred to as the business requirement field.
  • the specific form of the triplet can be: ⁇ object, operation, Constraint ⁇ .
  • the content in the target field can be used to describe the target object that the business needs to operate, manage, or influence.
  • the target object described here is an abstract representation method, which is a network resource or a user resource.
  • the contents of the operation field may be used to describe the operations required to implement the business requirements on the target object.
  • the operations described herein may be processes, actions, and the like that need to be performed, and the processes and actions may be implemented under specific conditions.
  • the content in the constraint field can be used to describe the constraint on the service content, that is, the limited content, the limited parameter, and the like that need to be met when the service content is operated to implement the service requirement.
  • the message content of a request message may include one or more triples. However, in some cases, the three fields in the triplet do not appear at the same time. Sometimes the message content of the request message only needs to contain one or two combinations of fields.
  • the message content of the request message may further include a context field (English: context).
  • the content in the context field is used to describe specific environmental information, background information related to the business requirements.
  • the context field may include a combination of any one or more of application environment parameters, network environment parameters, and application scenario sources.
  • one or more context fields may be included in the message content of a request message.
  • the message content of a response message may include a constraint dimension item, a context requirement item, and a scheme information part that implements a business requirement scenario.
  • the content in the constraint dimension item is used to describe the constraints that may or must be constrained when the implementation of the business requirements (for the business requirements of the request message in the request message) is met, and which also need to be supplemented by the application.
  • the application that receives the response message can be used to reply to the corresponding constraint.
  • one or more constraint dimension items may be included in the message content of a response message.
  • the content in the context requirements item is used to describe the environmental information that may or must be supplemented by the application when it is implemented to meet the business requirements (for the business requirements requested in the request message).
  • the content in the context requirement item can be used to request the application receiving the response message to reply to the corresponding environment information.
  • the message content of a response message can include one or Multiple context requirements items.
  • the scheme information part of the implementation of the service requirement scheme includes a specific scheme description of the scheme, or may also include a scheme identifier corresponding to the scheme. Since the scheme of prior business needs may have one or more schemes, the scheme information part may also correspond to one or more scheme information.
  • the application receiving the response message can be presented with a way to implement the business requirement.
  • the message may be carried in an existing packet format, such as a transmission control protocol packet, or may be carried in a customized packet format.
  • the existing packet format may be, for example, a Transmission Control Protocol (English: Transmission Control Protocol, abbreviation: TCP) message, a User Datagram Protocol (English: User Datagram Protocol, abbreviation: UDP) message, and a flow control transmission protocol. : Stream Control Transmission Protocol, abbreviation: SCTP), etc.
  • the message can generally be carried through the message content portion of the message.
  • the format of the message in the message varies according to the type of message.
  • the format of the request message in the message can be as shown in Table 2:
  • the header portion of the request message is used to identify that the message type is a request message.
  • the message length of the request message which is used to identify the byte length of the message content of the request message.
  • the content of the number of bytes after the header of the request message is determined to belong to the message content corresponding to the message header of the request message.
  • the message length of the request message can also be used to identify the sum of the message header of the request message and the byte length of the message content.
  • the business requirement header, the business requirement group, the context field header, and the context field are all part of the message content of the request message.
  • the business requirement header may include a business requirement number field and a business requirement length field.
  • the number of service requirements field is used to identify how many triplets are in the service requirement group, and the service requirement length field is used to identify the total length of bytes occupied by the service requirement group.
  • the service requirement group may include a target field, an operation field, and a constraint field, and the length of the three fields may be a fixed byte length or a non-fixed byte length. In the case of non-fixed byte lengths, these three fields may also have corresponding headers (English: header) for identifying Should be the start position and byte length of the field.
  • the flag field in the target field (English: c_flag) can also be used to identify whether the service requirement group contains a constraint field. For example, if the flag bit field is 1, it indicates that the service requirement group includes a constraint field. When the flag bit field is 0, it indicates that the constraint field is not included in the service requirement group.
  • the context field header may include a context information number field and a context information length field, and the context information number field may be used to identify the number of context information included in the context field, and the context information length field may be used to identify the total byte of the context field. length.
  • Context information is included in the context field.
  • the format of the response message in the message can be as shown in Table 3:
  • the header portion of the response message is used to identify that the message type is a response message.
  • the message length of the response message which is used to identify the byte length of the message content of the response message.
  • the content of the number of bytes after the response message header is determined to belong to the message content corresponding to the message header of the response message.
  • the message length of the response message can also be used to identify the sum of the message headers of the response message and the byte length of the message content.
  • the context requirement item is used to identify whether the context requirement item is included in the response message. For example, when the flag bit of the context requirement item is 1, it can be considered to be equivalent to including the context requirement item in the response message, to request the application to send the corresponding context information. . When the flag of the context requirement item is 0, it can be considered as equivalent to not including the context requirement item in the response message, and the application does not need to send the context information.
  • the constraint dimension number field and the constraint dimension length field may be included in the constraint dimension header.
  • the constraint dimension number field is used to identify the number of constraint dimension items in the constraint dimension item field.
  • the Constraint Dimension Length field is used to identify the total length of bytes used by the Constraint Dimension Item field.
  • the constraint dimension items contained in the constraint dimension item field can be fixed byte length or non-fixed byte length.
  • the constraint dimension item may also have a corresponding header (English: header) for identifying the start position and the byte length of the corresponding constraint dimension item.
  • the scheme information header of the implementation of the service requirement scheme may include a scheme information number field and a scheme information length field.
  • the number of scheme information fields is used to identify the number of schemes in the scheme information field that implements the service requirement scheme, that is, the number of corresponding scheme information.
  • the scheme information length field is used to identify the total length of bytes occupied by the scheme information field that implements the service requirement scheme.
  • the scheme information in the scheme information field of the implementation of the service requirement scheme may be fixed byte length or non-fixed byte length.
  • the scheme information may also have a corresponding header (English: header) for identifying the start position and the byte length of the corresponding scheme information.
  • FIG. 3 is a schematic diagram of message interaction signaling of an application plane and a control plane according to an embodiment of the present disclosure, as shown in FIG. 3, including:
  • the application sends a first message to the controller, where the first message includes a message header and a message content, and the message header of the first message is used to identify that the message type of the first message is a request message, the first
  • the message content of the message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify that the target object is implemented on the target object.
  • the application may explicitly describe the network requirements in the user's intention and the expected network behavior expected by the request message.
  • a request message can describe one or more user intents.
  • the first message belongs to a request message, which can be understood as a first request message or a first request message sent by the application to the controller for a user intent.
  • a request message As the first request message describing a user's intention, it is necessary to fully describe the intention of the user.
  • the target information and the operation information may be core content, which is a mandatory part, and needs to describe a target object of a user's intention through target information and operation information. The operation of the business requirement is implemented on the target object.
  • the portion included in the message content of the first message may be part of the business content.
  • the message content of the first message may further include constraint information and/or context information to better describe the user intent.
  • the constraint information may identify a constraint condition on the service content
  • the context information may identify a ring of the service content.
  • Information may be included in the message content of the first message.
  • the target information may be placed in a target field of the message content of the first message, and the operation information may be placed in a message content of the first message.
  • the service content includes constraint information, the constraint information may be placed in a constraint field of the message content of the first message.
  • the service content includes context information, the context information may be placed in a context field of the message content of the first message.
  • the controller identifies the first message as a request message according to a message header of the first message.
  • the first message may be identified as a request message according to the message header function defined above.
  • Step 102 The controller acquires the service content according to the message content of the first message.
  • the format of the request message has been described above, and when the controller processes the first message, it can be determined by the message length of the request message how many bytes of content afterwards belong to the message content of the first message, This gets the business content.
  • the controller After the controller obtains the service content, according to the processing of the service content, at least three different results can be obtained.
  • the controller may determine all the solutions for implementing the service content.
  • the second result is that the content included in the service content is not sufficient, and the controller may determine a partial scheme for implementing the service content or a scheme for implementing a part of the service content, but for some of the service content. In some content or schemes, the controller cannot determine an achievable solution according to the currently obtained service content. To this end, the controller may determine that the application further needs to supplement the content, for example, determining And requesting the application to reply to the constraint of the service content, and determining to request the application to reply to the environment information for the service content.
  • the content included in the service content is insufficient, and the controller cannot determine the implemented solution according to the currently obtained service content.
  • the controller In order to arrive at a solution that enables user intent, the controller needs to determine what the application needs to supplement for this.
  • the first one of the above three results is mainly described.
  • the result and the second result when determining the solution for implementing the business content, how the controller interacts with the application. See the contents and descriptions in steps 103 and 104 for details.
  • the controller determines, according to the service content, at least one solution that implements the service content.
  • the controller may determine at least one solution for implementing the service content, and at least one solution described herein may be understood as implementing all the solutions of the service content.
  • at least one solution determined by the controller may be understood as a partial solution for implementing the service content, or a solution for implementing a part of the service content.
  • the controller can also determine content that the application needs to replenish.
  • the controller sends a second message to the application, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response message.
  • the message content of the second message includes scenario information of the at least one scenario, the scenario information includes a scenario description of the at least one scenario, or a scenario identifier corresponding to the at least one scenario.
  • the second message belongs to a response message including the scenario information, and the format of the second message may also be as shown in Table 3.
  • the second message will not include the context requirement item (for example, when the flag of the context requirement item is 0, which is equivalent to not including the context requirement item), the constraint dimension header, and the constraint dimension item.
  • the controller may add the determined content that needs to be replenished by the application to a corresponding location in the message content of the second message. For example, a constraint for requesting the application to reply to the business content is placed as a constraint dimension item in a constraint dimension item field in the message content of the second message.
  • the flag bit of the context requirement item in the message content of the second message is set to 1 or the like.
  • the at least one solution may be sent to the application by using the second message in different forms for different application scenarios and requirements.
  • the message content of the second message is the scenario information of the at least one solution.
  • the complete solution that is, the The specific solution of the at least one solution is used as the solution information of the at least one solution.
  • the solution identifier corresponding to the at least one solution may also be used as the solution information of the at least one solution.
  • the controller may save the at least one scheme, and/or the correspondence between the at least one scheme and the scheme identifier on the controller side for subsequent calling.
  • the application identifies the second message as a response message according to a message header of the second message.
  • the first message may be identified as a response message according to the message header function defined above.
  • the application acquires solution information of the at least one solution according to the message content of the second message.
  • the format of the response message has been described above, and when the application processes the second message, it can be determined by the message length of the response message how many bytes of content afterwards belong to the message content of the second message, thereby Obtaining scheme information of the at least one scheme in the message content of the second message.
  • the application may obtain the message content of the second message, in addition to acquiring the at least one solution,
  • the second message includes a constraint dimension item and/or a context requirement item.
  • the application may have at least two processing manners.
  • the user is satisfied with the solution information of the at least one solution provided by the controller, and at least one target solution can meet the needs of the user. That is, the user can select an identification of a target solution or a target solution from the scenario information of the at least one scenario.
  • the first processing method may correspond to the first result described above or the second result. That is, when only the scenario information of the at least one scenario is included in the message content of the second message, the application may implement the first processing mode, in the message content of the second message. The application may also implement the first processing mode when not only the scenario information of the at least one scheme but also the constraint dimension item and/or the context requirement item.
  • the user In the second processing mode, the user is dissatisfied with the solution information of the at least one solution provided by the controller, and cannot meet the requirements of the user.
  • the user prefers to follow the appointment in the second message
  • the bundle dimension item and/or the context requirement item complement the content.
  • the controller When only the scenario information of the at least one scheme is included in the message content of the second message, the controller has provided all the schemes capable of realizing the user's intention, and does not need to supplement the content to the controller. Therefore, the second processing method mainly corresponds to the second result described above. That is, when the message content of the second message includes not only the scenario information of the at least one solution, but also the constraint dimension item and/or the context requirement item, the application may implement the second process. the way.
  • FIG. 4 is a second diagram of message interaction signaling diagrams of the application plane and the control plane according to an embodiment of the present invention, as shown in FIG. 4:
  • the controller sends a second message to the application.
  • the application also has the step of identifying and reading the content of the message after receiving the second message, and details are not described herein again.
  • the application sends a sixth message to the controller, where the sixth message includes a message header and a message content, and a message header of the sixth message is used to identify that the message type of the sixth message is a selection message.
  • the message content of the sixth message includes a target solution selected by the application from the scenario information of the at least one scenario or a scenario identifier of the target scenario.
  • the controller needs to be notified of the result of the selection by the application.
  • the sixth message belongs to a selection message, and the result of the selection may be carried by the message content of the sixth message to inform the controller.
  • the selected target solution may be directly added to the sixth message as a result of the selection.
  • the scheme identifier of the target scheme may also be added as the result of the selection in the message content of the sixth message.
  • the solution information of the at least one solution obtained by the application through the step 200 specifically includes a solution identifier corresponding to the at least one solution. Then, the scheme identifier of the target scheme may be added as a result of the selection in the message content of the sixth message.
  • the controller identifies, according to a message header of the sixth message, the sixth message as a selection message.
  • the controller determines, according to the message content of the sixth message, an implementation result of the target solution, where the implementation result is used to identify whether the target solution is implemented.
  • the controller determines, by using the sixth message, a target solution selected by a user, implements according to the target solution, and uses the implementation result to identify the target Whether the case is achieved.
  • the controller determines, according to the message content of the sixth message, the target identifier of the target scheme, and determines the target scheme by using a correspondence between the pre-stored scheme and the scheme identifier.
  • the controller sends a seventh message for the sixth message to the application, where the seventh message includes a message header and message content, and a message header of the seventh message is used to identify the seventh message.
  • the message type is an acknowledgement message, and the message content of the seventh message includes an implementation result of the target scenario.
  • the controller determines the implementation result of the target solution
  • the implementation result needs to be notified to the application to clear to the user whether the target solution has been implemented.
  • the seventh message belongs to a confirmation message, and the controller may carry the implementation result of the target solution by using the message content of the seventh message to notify the application.
  • FIG. 5 is the third embodiment of the message interaction signaling diagram of the application plane and the control plane according to the embodiment of the present invention, as shown in FIG. 5:
  • the controller sends a second message to the application.
  • the application also has the step of identifying and reading the content of the message after receiving the second message, and details are not described herein again.
  • the application determines the first supplementary content according to the constraint dimension item and/or the context requirement item included in the second message.
  • the first supplemental content and the controller are related to the content provided by the application by the second message. If the second message includes a constraint dimension item, the first supplemental content includes a constraint condition required in a constraint dimension item of the second message. If the second message includes a context requirement item, the first supplemental content includes environmental information required in a context requirement item of the second message.
  • the application sends a third message to the controller, where the third message includes a message header and a message content, and a message header of the third message is used to identify that the message type of the third message is a request message.
  • the message content of the third message includes the first supplemental content.
  • the first supplemental content includes a constraint condition required in a constraint dimension item of the second message; if the message content of the second message includes a context The requirement item, the first supplemental content includes environmental information required in a context requirement item of the second message.
  • the third message belongs to a request message, which is a request message replied according to a request in a response message including the scheme information.
  • the third message includes a constraint field, and the constraint required in the constraint dimension item of the second message may be placed in the message of the third message.
  • the content is in the constraint field.
  • the third message includes a context field, and the environment information required in the context requirement item of the second message may be placed in the message content of the third message. In the context field.
  • the third message may further carry the service content originally included in the message content of the first message.
  • the controller may be configured to determine a solution for implementing the service content according to the service content and the first supplementary content.
  • the service content includes target information and operation information
  • the target information may be placed in a target field of message content of the third message
  • the operation information may be placed in a message content of the third message.
  • the service content includes constraint information
  • the constraint information may be placed in a constraint field of the message content of the third message.
  • the service content includes context information
  • the context information may be placed in a context field of a message content of the third message.
  • the controller since the third message is a request message sent to the controller after the first message, the controller has acquired the service content, such as target information, by using the first message. And operation information, etc.
  • the application may not carry the service included in the message content of the first message in the third message when the third message is sent by using the third message. content.
  • the application may carry the same identifier when sending the first message and the third message by using a pre-negotiation.
  • the application may carry the same in the first message and the third message.
  • the identifier for example, the identifier of the object used to identify the target object, it should be noted that the content of the object identifier and the target information of the service content used to identify the target object may be the same or different.
  • the object identifier may be carried by the target field of the third message, or may be carried in other locations of the third message, which is not limited by the present invention.
  • the controller may save the service content and record the object identifier when receiving the first message. In this way, the controller receives only the first supplement
  • the previously saved service object may be retrieved according to the object identifier carried by the third message, and then combined with the first supplementary message in the third message to determine that the Business content plan.
  • the controller identifies the third message as a request message according to a message header of the third message.
  • the controller acquires a message content of the third message.
  • the controller performs different processing according to different content carried in the message content of the third message.
  • the controller may retrieve the service content corresponding to the object identifier according to the object identifier. And then combining the first supplementary message in the third message to determine a solution for implementing the service content.
  • the controller may not save the service content, and correspondingly reduce the controller.
  • Store pressure The controller determines a scheme for implementing the service content according to the service content obtained from the message content of the third message and the first supplemental message.
  • the controller may determine, according to the first supplementary content and the service content, that the application is requested to reply to a constraint for the service content and/or request the application to reply to an environment for the service content. information. Then, the controller may send a response message to the application again to instruct the application to continue to provide corresponding supplementary content until the application provides supplementary content required by the controller, or the application selects Until the target program.
  • the response message sent by the controller to the application may be a second message carrying the solution, or may be a non-carrying solution, but only a response carrying the constraint dimension item and/or the context requirement item. Message.
  • the response message carrying the constraint dimension item and/or the context requirement item for the non-carrying scheme reference may be made to the embodiment corresponding to FIG. 6.
  • step 102 a third result described in step 102 in the embodiment corresponding to FIG. 3 will be described.
  • the third case is that the content included in the service content is insufficient, and the controller cannot determine the implemented solution according to the currently obtained service content. In order to arrive at a solution that enables user intent, the controller needs to determine what the application needs to supplement for this.
  • FIG. 6 is an application flat according to an embodiment of the present invention.
  • the message interaction signaling diagram of the plane and the control plane is as shown in Figure 6:
  • the application sends the first message to a controller.
  • the controller identifies the first message as a request message according to a message header of the first message.
  • Step 102 The controller acquires the service content according to the message content of the first message.
  • the controller determines, according to the service content, that the application is requested to reply to the constraint of the service content and/or The application is requested to reply to environmental information for the business content.
  • the step 104 is mainly for the operation when the processing result of the step 102 is the third result, that is, for the controller, according to the currently obtained service content, an implemented solution cannot be determined. The operation performed.
  • the controller sends a fourth message to the application, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is a response message.
  • the message content of the fourth message includes the constraint dimension item and/or a context requirement item, the constraint dimension item is used to request the application to reply to a constraint for the service content, the context requirement item is used for requesting The application replies to environmental information for the business content.
  • the fourth message belongs to a response message that does not include the scenario information.
  • the controller may add the determined content that needs to be replenished by the application to a corresponding location in the message content of the fourth message.
  • the application identifies the fourth message as a response message according to a message header of the fourth message.
  • the application acquires a constraint dimension item and/or a context requirement item included in the fourth message according to the message content of the fourth message.
  • the application determines the second supplementary content according to the constraint dimension item and/or the context requirement item included in the fourth message.
  • the application sends a fifth message to the controller, where the fifth message includes a message header and a message content, and a message header of the fifth message is used to identify that the message type of the fifth message is a request message.
  • the message content of the fifth message includes the second supplemental content.
  • the second supplementary content includes a constraint condition required in the constraint dimension item of the fourth message; if the message content of the fourth message includes a context a requirement item, the second supplemental content including an environmental letter required in a context requirement item of the fourth message interest.
  • the fifth message belongs to a request message, and the request message is a request message replied according to a request in a response message that does not include the scenario information.
  • the fifth message includes a constraint field, and the constraint required in the constraint dimension item of the fourth message may be placed in the message of the fifth message.
  • the content is in the constraint field.
  • the fifth message includes a context field, and the environment information required in the context requirement item of the fourth message may be placed in the message content of the fifth message.
  • the fifth message may further carry the service content originally included in the message content of the first message.
  • the controller may be configured to determine a solution for implementing the service content according to the service content and the second supplementary content.
  • the service content includes target information and operation information
  • the target information may be placed in a target field of a message content of the fifth message
  • the operation information may be placed in a message content of the fifth message.
  • the service content includes constraint information
  • the constraint information may be placed in a constraint field of the message content of the fifth message.
  • the context information may be placed in a context field of a message content of the fifth message.
  • the controller since the fifth message is a request message sent to the controller after the first message, the controller has acquired the service content, such as target information, by using the first message. And the contents of the operation information, etc.
  • the application may not carry the service included in the message content of the first message in the fifth message when the fifth message is sent by using the foregoing negotiation. content.
  • the specific implementation process for the fifth message is similar to the implementation process for the third message, and details are not described herein again.
  • the controller may determine, according to the second supplementary content and the service content, that the application is requested to reply to a constraint condition for the service content and/or request the application to reply to an environment for the service content. information. Then, the controller may send a response message to the application again to instruct the application to continue to provide corresponding supplementary content until the application provides supplementary content required by the controller, or the application selects Until the target program.
  • the response message sent by the controller to the application may be the second message carrying the solution, or It does not carry the scheme, but only carries the fourth message of the constraint dimension item and/or the context requirement item.
  • FIG. 7 is a schematic diagram of an application scenario according to an embodiment of the present invention. As shown in Figure 7:
  • Site1 and Site2 can be two sites of Enterprise A. There are multiple service flows between the two sites (English: flow), which are f1, f2, and f3.
  • the service flow between Site1 and Site2 is divided into two service flows with high priority and low priority according to importance.
  • the bandwidth utilization rate of 100M bandwidth dedicated link between Site1 and Site2 shall not exceed 80%. Wherein, when the bandwidth usage rate is higher than 80%, the service flow in the dedicated link needs to be adjusted to the common bandwidth link, and the traffic flow with high importance is not adjusted to the public bandwidth link, and the traffic flow with low importance is required. Adjust to the common bandwidth link.
  • the target object is specifically:
  • the content of the target information in the business content can be as follows:
  • Traffic migration occurs when the link bandwidth usage is greater than 80%.
  • the content of the operational information of the business content can be as follows:
  • op1 is an operation.
  • the constraint information is specifically:
  • the content of the constraint information of the business content can be as follows:
  • the context information is specifically:
  • F1 is used for file transfer protocol data transmission
  • f2 is used for backup data transmission
  • f3 is used for video transmission.
  • the content of the context information of the business content can be as follows:
  • the first message may carry the target information by using the target field in the message content, the operation field carries the operation information, the constraint field carries the constraint information, and the context field carries the context information.
  • the controller determines a solution for implementing the service content according to the service content.
  • the specific content of the process and plan for determining the plan can be as follows:
  • the three service flows are used for ftp data transmission, data backup and online video conference.
  • online video conferencing is more sensitive to bandwidth, and the gold QoS bandwidth guarantee is performed on the service flow f3, and the silver QoS bandwidth guarantee is performed on the data backup service flow f2.
  • the controller can send the determined solution to the application through the second message, thereby implementing the application flat Business requirements to control demand transformation between the surface and the control plane.
  • the user intention is specifically:
  • the hypertext transfer protocol (English: Hyper Text Transfer Protocol, abbreviation: HTTP) between the site 1 and the site 2 needs to be logged.
  • the log record needs to be processed according to a specific log format, and the uniformity in each HTTP packet is recorded.
  • Resource identifier (English: Uniform Resource Identifier, abbreviation: URI).
  • the target object is specifically:
  • the content of the target information of the business content can be as follows:
  • the content of the operational information of the business content can be as follows:
  • the context information is specifically:
  • the content of the context information of the business content can be as follows:
  • the controller acquiring the service content from the message content of the first message, where the service content includes the target information, the operation information, and the context information.
  • the first message may carry the target information by using the target field in the message content, the operation field carries the operation information, and the context field carries the context information.
  • the controller determines a solution for implementing the service content according to the service content.
  • a scheme for realizing the log record of the URI of an HTTP message requires two steps.
  • the specific content can be as follows:
  • the first step is to classify the service flow data packet and deep packet inspection (Deep Packet Inspection, DPI) to obtain the URI of the HTTP packet.
  • DPI Deep Packet Inspection
  • the second step is to perform log processing.
  • the scenario description for this scenario can be as follows:
  • the scheme identifier corresponding to this scheme can be: service-catalog-5.2.
  • processing steps and scheme identifiers of this scheme can be saved in the user manual (English manual) or saved in the service customization portal (English: portal).
  • the scheme information of the scheme added by the controller in the message content of the second message can be in two forms, and which form can be set in advance.
  • the first form is to add the scenario description of this scenario to the message content of the second message.
  • the second form is to add only the scheme identifier corresponding to this scheme to the message content of the second message.
  • the application may determine the specific scheme description of the scheme according to the scheme identifier uniquely.
  • the type of the first message is defined by the message header of the first message, and the service content of the first message is carried by the message content of the first message, so that the application in the application plane can use the first message
  • the target object in the business requirement and the operation to implement the business requirement on the target object are sent to the controller at the control level.
  • the type of the second message is defined by a message header of the second message, and the service content of the second message is carried by the message content of the second message, when the second message sent from the controller is received
  • the application may identify and obtain the solution information carried in the message content of the second message for implementing at least one solution of the service content, thereby implementing the service requirement between the application plane and the control plane. Control demand conversion.
  • FIG. 8 is a structural diagram of a device of a message processing apparatus according to an embodiment of the present invention.
  • the message processing apparatus 800 is applied to an SDN, and the message processing apparatus 800 includes:
  • the sending unit 801 is configured to send a first message to the controller, where the first message includes a message header and a message content, and the message header of the first message is used to identify that the message type of the first message is a request message, where
  • the message content of the first message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify the target object.
  • the receiving unit 802 is configured to receive a second message sent by the controller, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response.
  • a message the message content of the second message includes scenario information for implementing at least one scenario of the service content, the scenario information includes a scenario description of the at least one scenario, or a scenario corresponding to the at least one scenario Identification
  • the identifying unit 803 is configured to identify, according to the message header of the second message, the second message as a response message;
  • the obtaining unit 804 is configured to acquire scheme information of the at least one solution according to the message content of the second message.
  • the service content further includes constraint information and/or context information, where the constraint information of the service content includes a constraint for identifying the service content, and the context information of the service content includes The environmental information of the business content, where the environmental information includes a combination of any one or more of an application environment parameter, a network environment parameter, and an application scenario source.
  • the message content of the second message further includes a constraint dimension item and/or a context requirement item, where the constraint dimension item is used to request the application to reply to a constraint for the service content, the context requirement item Used to request the application to reply to environmental information for the business content;
  • the obtaining unit is further configured to acquire, according to the message content of the second message, a constraint dimension item and/or a context requirement item included in the second message, and acquire scenario information of at least one solution included in the second message. .
  • the device further includes:
  • a determining unit configured to determine, according to the constraint dimension item and/or the context requirement item included in the second message, the first supplemental content
  • the sending unit is further configured to send a third message to the controller, where the third message includes a message header and a message content, and a message header of the third message is used to identify that the message type of the third message is a request a message, the message content of the third message includes the first supplementary content, wherein if the message content of the second message includes a constraint dimension item, the first supplemental content includes a constraint dimension item of the second message The constraint condition required in the message; if the message content of the second message includes a context requirement item, the first supplemental content includes environment information required in a context requirement item of the second message.
  • the third message and the The first message carries an object identifier for identifying the target object
  • the message content of the third message includes the service content and the first supplementary content.
  • the receiving unit is further configured to receive a fourth message sent by the controller, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is Responding to the message, the message content of the fourth message includes a constraint dimension item and/or a context requirement item;
  • the identifying unit is further configured to identify the fourth message as a response message according to a message header of the fourth message;
  • the obtaining unit is further configured to acquire, according to the message content of the fourth message, a constraint dimension item and/or a context requirement item included in the fourth message;
  • the determining unit is further configured to determine the second supplementary content according to the constraint dimension item and/or the context requirement item included in the fourth message;
  • the sending unit is further configured to send a fifth message to the controller, where the fifth message includes a message header and a message content, and a message header of the fifth message is used to identify that the message type of the fifth message is a request a message, the message content of the fifth message includes the second supplementary content, wherein if the message content of the fourth message includes a constraint dimension item, the second supplementary content includes a constraint dimension item of the fourth message The constraint condition required in the message; if the message content of the fourth message includes a context requirement item, the second supplementary content includes environment information required in a context requirement item of the fourth message.
  • the target information is placed in a target field of the message content of the request message, and the operation information is placed in an operation field of the message content of the request message;
  • the constraint information is placed in a constraint field of a message content of the request message;
  • the context information is placed in a context field of a message content of the request message;
  • the constraint required in the constraint dimension item of the second message is placed in a constraint field of the message content of the request message, and the context requirement item of the second message.
  • the environment information required in the context of the message content of the request message In the field;
  • the constraint required in the constraint dimension item of the fourth message is placed in a constraint field of the message content of the request message, and the context requirement item of the fourth message
  • the environment information required in the context is placed in the context field of the message content of the request message.
  • the sending unit is further configured to send a sixth message to the controller, where the sixth message includes a message header and a message content, and a message header of the sixth message is used to identify that the message type of the sixth message is selected.
  • a message, the message content of the sixth message includes a target solution selected by the application from the solution information of the at least one solution or a solution identifier of the target solution;
  • the receiving unit is further configured to receive a seventh message sent by the controller for the sixth message, where the seventh message includes a message header and a message content, where a message header of the seventh message is used to identify the
  • the message type of the seven message is an acknowledgment message
  • the message content of the seventh message includes an implementation result of the target solution, and the implementation result is used to identify whether the target solution is implemented.
  • the type of the first message is defined by the message header of the first message, and the service content of the first message is carried by the message content of the first message, so that the application in the application plane can use the first message
  • the target object in the business requirement and the operation to implement the business requirement on the target object are sent to the controller at the control level.
  • the type of the second message is defined by a message header of the second message, and the service content of the second message is carried by the message content of the second message, when the second message sent from the controller is received
  • the application may identify and obtain the solution information carried in the message content of the second message for implementing at least one solution of the service content, thereby implementing the service requirement between the application plane and the control plane. Control demand conversion.
  • FIG. 9 is a structural diagram of a device of a message processing apparatus according to an embodiment of the present invention, which is applied to an SDN, and the message processing apparatus 900 includes:
  • the receiving unit 901 is configured to acquire a first message sent by the application, where the first message includes a message header and a message content, and the message header of the first message is used to identify that the message type of the first message is a request message, where
  • the message content of the first message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify the target object.
  • the identifying unit 902 is configured to identify the first message as a request according to a message header of the first message.
  • the obtaining unit 903 is configured to acquire the service content according to the message content of the first message.
  • a determining unit 904 configured to determine, according to the service content, at least one solution for implementing the service content
  • the sending unit 905 is configured to send a second message to the application, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response message.
  • the message content of the second message includes scenario information of the at least one scenario, the scenario information includes a scenario description of the at least one scenario, or a scenario identifier corresponding to the at least one scenario.
  • the service content further includes constraint information and/or context information, where the constraint information of the service content includes a constraint for identifying the service content, and the context information of the service content includes The environmental information of the business content, where the environmental information includes a combination of any one or more of an application environment parameter, a network environment parameter, and an application scenario source.
  • the determining unit is further configured to determine, according to the service content, that the application is requested to reply to the constraint for the service content. And/or requesting the application to reply to environmental information for the business content;
  • the message content of the second message further includes a constraint dimension item and/or a context requirement item, the constraint dimension item is used to request the application to reply to a constraint for the service content, where the context requirement item is used to request the location
  • the application replies to environmental information for the business content.
  • the receiving unit is further configured to acquire a third message, where the third message includes a message header and a message content, where a message header of the third message is used to identify that the message type of the third message is a request message, where the The message content of the three messages includes supplementary content, the supplementary content includes constraint information and/or context information, and the constraint information of the supplementary content includes a constraint condition for the service content, and the context information of the supplementary content includes Environmental information of the business content;
  • the identifying unit is further configured to identify the third message as a request message according to a message header of the third message;
  • the obtaining unit is further configured to acquire a message content of the third message.
  • the third Both the message and the first message carry an object identifier for identifying the target object, and the method further includes:
  • the receiving unit is further configured to: when acquiring the first message, save the service content and record the object identifier;
  • the receiving unit when acquiring the third message, is further configured to extract, according to the object identifier carried in the third message, the saved service content;
  • the determining unit is further configured to determine, according to the service content and the supplementary content, at least one solution for implementing the service content;
  • the determining unit is further configured to determine, according to the service content and the supplementary content, at least one solution for implementing the service content.
  • the determining unit is further configured to determine, according to the service content, that the application is requested to reply to the constraint condition of the service content and/or Or requesting the application to reply to environmental information for the business content;
  • the sending unit is further configured to send a fourth message to the application, where the fourth message includes a message header and a message content, and a message header of the fourth message is used to identify that the message type of the fourth message is a response message.
  • the message content of the fourth message includes the constraint dimension item and/or a context requirement item, where the constraint dimension item is used to request the application to reply to a constraint for the service content, where the context requirement item is used
  • the application is requested to reply to environmental information for the business content.
  • the receiving unit is further configured to acquire a third message, where the third message includes a message header and a message content, where a message header of the third message is used to identify that the message type of the third message is a request message, where the The message content of the three messages includes supplementary content, the supplementary content includes constraint information and/or context information, and the constraint information of the supplementary content includes a constraint for the service content, and the context message of the supplementary content includes Environmental information of the business content;
  • the identifying unit is further configured to identify the third message as a request message according to a message header of the third message;
  • the obtaining unit is further configured to acquire a message content of the third message.
  • the third Both the message and the first message carry an object identifier for identifying the target object
  • the receiving unit is further configured to: when acquiring the first message, save the service content and record the object identifier;
  • the receiving unit when acquiring the third message, is further configured to extract, according to the object identifier carried in the third message, the saved service content;
  • the determining unit is further configured to determine, according to the supplementary content and the service content, that the application is requested to reply to the service content. Constraints and/or requesting the application to reply to environmental information for the business content;
  • the determining unit is further configured to use the supplementary content and The service content determines that the application is requested to reply to the constraint of the service content and/or requests the application to reply to environmental information for the service content.
  • the receiving unit is further configured to acquire a sixth message sent by the application, where the sixth message includes a message header and a message content, and a message header of the sixth message is used to identify that the message type of the sixth message is selected.
  • a message, the message content of the sixth message includes a target solution selected by the application from the solution information of the at least one solution or a solution identifier of the target solution;
  • the identifying unit is further configured to identify the sixth message as a selection message according to a message header of the sixth message;
  • the determining unit is further configured to determine, according to the message content of the sixth message, an implementation result of the target solution, where the implementation result is used to identify whether the target solution is implemented;
  • the sending unit is further configured to send, to the application, a seventh message for the sixth message, where the seventh message includes a message header and message content, and a message header of the seventh message is used to identify the seventh message.
  • the message type of the message is an acknowledgment message
  • the message content of the seventh message includes an implementation result of the target solution, and the implementation result is used to identify whether the target solution is implemented.
  • the type of the first message is defined by the message header of the first message, and the service content of the first message is carried by the message content of the first message, so that the application in the application plane can use the first message
  • the target object in the business requirement and the operation to implement the business requirement on the target object are sent to the controller at the control level.
  • the message header defines a type of the second message, and the message content of the second message carries service content for indicating a service requirement, and when the second message sent by the controller is received, the application may identify Obtaining, by the message content of the second message, solution information for implementing at least one solution of the service content, thereby implementing a service requirement to control requirement conversion between the application plane and the control plane.
  • the message processing system 1000 includes an application and a controller:
  • the application 1001 is configured to send a first message to the controller, where the first message includes a message header and a message content, and a message header of the first message is used to identify that the message type of the first message is a request.
  • the message content of the first message includes service content for describing a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify An operation of implementing the service requirement on the target object; receiving a second message sent by the controller, where the second message includes a message header and a message content, and a message header of the second message is used to identify the second
  • the message type of the message is a response message
  • the message content of the second message includes scenario information for implementing at least one solution of the service content, the scenario information includes a scenario description of the at least one scenario, or includes the a scheme identifier corresponding to the at least one scheme; identifying, according to the message header of the second message, the second message as a response message; Information content
  • the controller 1002 is configured to acquire the first message sent by the application, identify the first message as a request message according to a message header of the first message, and acquire according to the message content of the first message. Determining, according to the service content, at least one solution for implementing the service content; and sending the second message to the application.
  • FIG. 11 is a schematic diagram of a hardware structure of an application device according to an embodiment of the present invention.
  • the application device 1100 is located in an SDN, where an application is deployed, and the application device performs the following operations by executing the deployed application.
  • the application device 1100 includes a memory 1101, a receiver 1102, and a transmitter 1103, and a processor 1104 connected to the memory 1101, the receiver 1102, and the transmitter 1103, respectively, for storing one
  • the program instruction is used by the processor 1104 to call the program instruction stored by the memory 1101 to perform the following operations:
  • the transmitter 1103 is triggered to send a first message to the controller, where the first message includes a message header and a message content, and the message header of the first message is used to identify that the message type of the first message is
  • the message content of the first message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify An operation of implementing the business requirement on the target object;
  • the receiver 1102 is triggered to receive a second message sent by the controller, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response.
  • the message content of the second message includes scenario information for implementing at least one scenario of the service content, the scenario information includes a scenario description of the at least one scenario, or a scenario corresponding to the at least one scenario Identification
  • the processor 1104 may be a central processing unit (CPU), and the memory 1101 may be an internal memory of a random access memory (RAM) type, the receiver 1102 and The transmitter 1103 may include a common physical interface, and the physical interface may be an Ethernet interface or an Asynchronous Transfer Mode (ATM) interface.
  • the processor 1104, the transmitter 1103, the receiver 1102, and the memory 1101 may be integrated into one or more independent circuits or hardware, such as an Application Specific Integrated Circuit (ASIC).
  • ASIC Application Specific Integrated Circuit
  • the controller 1200 is located in an SDN, and the first router 1200 includes a memory 1201, a receiver 1202, and a transmitter 1203, and respectively The memory 1201, the receiver 1202, and the processor 1203 are connected to the processor 1204.
  • the memory 1201 is configured to store a set of program instructions, and the processor 1204 is configured to invoke the program instructions stored by the memory 1201 to execute the following. operating:
  • the message content of the first message includes service content for explaining a service requirement, the service content includes target information and operation information, the target information is used to identify a target object, and the operation information is used to identify the target object.
  • the transmitter 1203 is configured to send a second message to the application, where the second message includes a message header and a message content, and a message header of the second message is used to identify that the message type of the second message is a response message.
  • the message content of the second message includes scenario information of the at least one scenario, the scenario information includes a scenario description of the at least one scenario, or a scenario identifier corresponding to the at least one scenario.
  • the processor 1204 may be a CPU
  • the memory 1201 may be a RAM type internal memory
  • the receiver 1202 and the transmitter 1203 may include a common physical interface, and the physical interface may be an Ethernet interface. Or ATM interface.
  • the processor 1204, the transmitter 1203, the receiver 1202, and the memory 1201 may be integrated into one or more separate circuits or hardware, such as an ASIC.
  • the above general-purpose processor may be a microprocessor or the processor may be any conventional processor, decoder or the like.
  • the steps of the method disclosed in the embodiments of the present invention may be directly implemented as a hardware processor, or may be performed by a combination of hardware and software modules in the processor.
  • the software module can be located in a conventional storage medium such as random access memory, flash memory, read only memory, programmable read only memory or electrically erasable programmable memory, registers, and the like.
  • the first message mentioned in the embodiment of the present invention and the "first" of the first supplementary content are only used for name identification, and do not represent the first in the order. The same rules apply to "second", "third”, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例公开了一种消息处理方法、装置和系统，应用于SDN中，应用向控制器发送第一消息，包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述应用接收所述控制器发送的第二消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。由此实现了应用平面和控制平面之间业务需求到控制需求转换。

Description

一种消息处理方法、装置和系统
本申请要求于2015年12月16日提交中国专利局、申请号为CN 201510947136.8、发明名称为“一种消息处理方法、装置和系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及数据通信领域，特别是涉及一种消息处理方法、装置和系统。
背景技术
软件定义网络(英文：Software Defined Network，缩写：SDN)是一种典型的网络结构。在SDN中，将网络设备的转发和控制进行分离，形成相互独立的转发平面(英文：Forwarding Plane)和控制平面(英文：Control Plane)。而网络用户、网络应用等处于应用平面(英文：Application Plane)。SDN的具体架构可以参见图1，应用平面与控制平面之间进行交互，控制平面与转发平面之间进行交互。
随着技术发展，希望可以在SDN中，根据SDN的各平面的特点，灵活的根据业务需求对网络资源、网络行为进行控制。例如应用平面可以向控制平面发送业务需求，而由控制平面根据接收的业务需求中携带的内容，确定出具体在SDN上实现该业务需求的控制需求。这里所述的业务需求可以理解为一种对网络需求的抽象描述，例如连通性、带宽、业务部署生命周期等，使得应用平面不再需要向控制平面描述如何能够在网络上实现这些需求。
可见，如何在SDN中的应用平面和控制平面之间实现业务需求到控制需求转换是目前亟待解决的技术问题。
发明内容
为了解决上述技术问题，本发明实施例提供了一种消息处理方法、装置和系统，实现了应用平面和控制平面之间业务需求到控制需求转换。
第一方面，本发明实施例提供了一种消息处理方法，应用于SDN中，所述方法包括：
应用向控制器发送第一消息，所述第一消息包括消息头和消息内容，所 述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
所述应用接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；
所述应用根据所述第二消息的消息头识别所述第二消息为响应消息；
所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
可选的，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
可选的，所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息；
所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息，包括：
所述应用根据所述第二消息的消息内容，获取所述第二消息包括的约束维度项和/或上下文需求项，以及获取所述第二消息包括的至少一个方案的方案信息。
可选的，所述方法还包括：
所述应用根据所述第二消息包括的约束维度项和/或上下文需求项确定第一补充内容；
所述应用向所述控制器发送第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括所述第一补充内容，其中，若所述第二消息的消息内容包括约束维度项，所述第一补充内容包括所述第二消息的约束维度 项中所要求的约束条件；若所述第二消息的消息内容包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
可选的，
若所述第三消息的消息内容中未包括所述业务内容，所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识；或者，
所述第三消息的消息内容中包括所述业务内容和所述第一补充内容。
可选的，在所述应用向控制器发送第一消息之后，所述应用接收所述控制器发送的第二消息之前，还包括：
所述应用接收所述控制器发送的第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括约束维度项和/或上下文需求项；
所述应用根据所述第四消息的消息头识别所述第四消息为响应消息；
所述应用根据所述第四消息的消息内容，获取所述第四消息包括的约束维度项和/或上下文需求项；
所述应用根据所述第四消息包括的约束维度项和/或上下文需求项确定第二补充内容；
所述应用向所述控制器发送第五消息，所述第五消息包括消息头和消息内容，所述第五消息的消息头用于标识所述第五消息的消息类型为请求消息，所述第五消息的消息内容包括所述第二补充内容，其中，若所述第四消息的消息内容包括约束维度项，所述第二补充内容包括所述第四消息的约束维度项中所要求的约束条件；若所述第四消息的消息内容包括上下文需求项，所述第二补充内容包括所述第四消息的上下文需求项中所要求的环境信息。
可选的，
若所述业务内容包括目标信息和操作信息，所述目标信息置于请求消息的消息内容的目标字段中，所述操作信息置于请求消息的消息内容的操作字段中；
若所述业务内容包括约束信息，所述约束信息置于请求消息的消息内容的约束字段中；
若所述业务内容包括上下文信息，所述上下文信息置于请求消息的消息内容的上下文字段中；
若请求消息的消息内容包括所述第一补充内容，所述第二消息的约束维 度项中所要求的约束条件置于请求消息的消息内容的约束字段中，所述第二消息的上下文需求项中所要求的环境信息置于请求消息的消息内容的上下文字段中；
若请求消息的消息内容包括所述第二补充内容，所述第四消息的约束维度项中所要求的约束条件置于请求消息的消息内容的约束字段中，所述第四消息的上下文需求项中所要求的环境信息置于请求消息的消息内容的上下文字段中。
可选的，在所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息之后，还包括：
所述应用向所述控制器发送第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
所述应用接收所述控制器针对所述第六消息发送的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
第二方面，本发明实施例提供了一种消息处理装置，应用于SDN中，所述装置包括：
发送单元，用于向控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
接收单元，用于接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；
识别单元，用于根据所述第二消息的消息头识别所述第二消息为响应消息；
获取单元，用于根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
可选的，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
可选的，所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息；
所述获取单元还用于根据所述第二消息的消息内容，获取所述第二消息包括的约束维度项和/或上下文需求项，以及获取所述第二消息包括的至少一个方案的方案信息。
可选的，所述装置还包括：
确定单元，用于根据所述第二消息包括的约束维度项和/或上下文需求项确定第一补充内容；
所述发送单元还用于向所述控制器发送第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括所述第一补充内容，其中，若所述第二消息的消息内容包括约束维度项，所述第一补充内容包括所述第二消息的约束维度项中所要求的约束条件；若所述第二消息的消息内容包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
可选的，
若所述第三消息的消息内容中未包括所述业务内容，所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识；或者，
所述第三消息的消息内容中包括所述业务内容和所述第一补充内容。
可选的，
所述接收单元还用于接收所述控制器发送的第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括约束维度项和/或上下文需求项；
所述识别单元还用于根据所述第四消息的消息头识别所述第四消息为响应消息；
所述获取单元还用于根据所述第四消息的消息内容，获取所述第四消息包括的约束维度项和/或上下文需求项；
所述确定单元还用于根据所述第四消息包括的约束维度项和/或上下文需求项确定第二补充内容；
所述发送单元还用于向所述控制器发送第五消息，所述第五消息包括消息头和消息内容，所述第五消息的消息头用于标识所述第五消息的消息类型为请求消息，所述第五消息的消息内容包括所述第二补充内容，其中，若所述第四消息的消息内容包括约束维度项，所述第二补充内容包括所述第四消息的约束维度项中所要求的约束条件；若所述第四消息的消息内容包括上下文需求项，所述第二补充内容包括所述第四消息的上下文需求项中所要求的环境信息。
可选的，
若所述业务内容包括目标信息和操作信息，所述目标信息置于请求消息的消息内容的目标字段中，所述操作信息置于请求消息的消息内容的操作字段中；
若所述业务内容包括约束信息，所述约束信息置于请求消息的消息内容的约束字段中；
若所述业务内容包括上下文信息，所述上下文信息置于请求消息的消息内容的上下文字段中；
若请求消息的消息内容包括所述第一补充内容，所述第二消息的约束维度项中所要求的约束条件置于请求消息的消息内容的约束字段中，所述第二消息的上下文需求项中所要求的环境信息置于请求消息的消息内容的上下文字段中；
若请求消息的消息内容包括所述第二补充内容，所述第四消息的约束维度项中所要求的约束条件置于请求消息的消息内容的约束字段中，所述第四消息的上下文需求项中所要求的环境信息置于请求消息的消息内容的上下文字段中。
可选的，
所述发送单元还用于向所述控制器发送第六消息，所述第六消息包括消 息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
所述接收单元还用于接收所述控制器针对所述第六消息发送的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
第三方面，本发明实施例提供了一种消息处理方法，应用于SDN中，所述方法包括：
控制器获取应用发送的第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
所述控制器根据所述第一消息的消息头识别所述第一消息为请求消息；
所述控制器根据所述第一消息的消息内容，获取所述业务内容；
所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案；
所述控制器向所述应用发送第二消息，所述述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
可选的，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
可选的，
若所述控制器根据所述业务内容不足以确定出实现所述业务内容的全部方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约 束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
可选的，在所述控制器获取应用发送的第一消息之后，所述控制器向所述应用发送第二消息之前，还包括：
所述控制器获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文信息中包括针对所述业务内容的环境信息；
所述控制器根据所述第三消息的消息头识别所述第三消息为请求消息；
所述控制器获取所述第三消息的消息内容。
可选的，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
所述控制器获取所述第一消息时，保存所述业务内容并记录所述对象标识；
所述控制器获取所述第三消息时，所述控制器根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案，包括：
所述控制器根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案；
或者，
若所述第三消息的消息内容还包括所述业务内容，所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案，包括：
所述控制器根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案。
可选的，
若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
所述控制器向所述应用发送第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括所述约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
可选的，在所述控制器获取应用发送的第一消息之后，所述控制器向所述应用发送第四消息之前，还包括：
所述控制器获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文消息中包括针对所述业务内容的环境信息；
所述控制器根据所述第三消息的消息头识别所述第三消息为请求消息；
所述控制器获取所述第三消息的消息内容。
可选的，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
所述控制器获取所述第一消息时，保存所述业务内容并记录所述对象标识；
所述控制器获取所述第三消息时，所述控制器根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息，包括：
若所述控制器根据所述补充内容和所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
或者，
若所述第三消息的消息内容还包括所述业务内容，若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务 内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息，包括：
若所述控制器根据所述补充内容和所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。
可选的，在所述控制器向所述应用发送第二消息之后，所述方法还包括：
所述控制器获取所述应用发送的第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
所述控制器根据所述第六消息的消息头识别所述第六消息为选择消息；
所述控制器根据所述第六消息的消息内容，确定所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现；
所述控制器向所述应用发送针对所述第六消息的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
第四方面，本发明实施例提供了一种消息处理装置，应用于SDN中，所述装置包括：
接收单元，用于获取应用发送的第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
识别单元，用于根据所述第一消息的消息头识别所述第一消息为请求消息；
获取单元，用于根据所述第一消息的消息内容，获取所述业务内容；
确定单元，用于根据所述业务内容，确定实现所述业务内容的至少一个方案；
发送单元，用于向所述应用发送第二消息，所述述第二消息包括消息头 和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
可选的，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
可选的，
若所述确定单元根据所述业务内容不足以确定出实现所述业务内容的全部方案，所述确定单元还用于根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
可选的，
所述接收单元还用于获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文信息中包括针对所述业务内容的环境信息；
所述识别单元还用于根据所述第三消息的消息头识别所述第三消息为请求消息；
所述获取单元还用于获取所述第三消息的消息内容。
可选的，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
所述接收单元还用于获取所述第一消息时，保存所述业务内容并记录所述对象标识；
所述接收单元获取所述第三消息时，还用于根据所述第三消息携带的所 述对象标识提取出保存的所述业务内容；
所述确定单元还用于根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案；
或者，
若所述第三消息的消息内容还包括所述业务内容，所述确定单元还用于根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案。
可选的，
若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
所述发送单元还用于向所述应用发送第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括所述约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
可选的，
所述接收单元还用于获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文消息中包括针对所述业务内容的环境信息；
所述识别单元还用于根据所述第三消息的消息头识别所述第三消息为请求消息；
所述获取单元还用于获取所述第三消息的消息内容。
可选的，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，
所述接收单元还用于获取所述第一消息时，保存所述业务内容并记录所述对象标识；
所述接收单元获取所述第三消息时，还用于根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
或者，
若所述第三消息的消息内容还包括所述业务内容，若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。
可选的，
所述接收单元还用于获取所述应用发送的第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
所述识别单元还用于根据所述第六消息的消息头识别所述第六消息为选择消息；
所述确定单元还用于根据所述第六消息的消息内容，确定所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现；
所述发送单元还用于向所述应用发送针对所述第六消息的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
第五方面，本发明实施例提供了一种消息处理系统，应用于SDN中，所述系统包括应用和控制器：
所述应用，用于向所述控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消 息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；根据所述第二消息的消息头识别所述第二消息为响应消息；根据所述第二消息的消息内容，获取所述至少一个方案的方案信息；
所述控制器，用于获取所述应用发送的所述第一消息；根据所述第一消息的消息头识别所述第一消息为请求消息；根据所述第一消息的消息内容，获取所述业务内容；根据所述业务内容，确定实现所述业务内容的至少一个方案；向所述应用发送所述第二消息。
由上述技术方案可以看出，通过第一消息的消息头定义所述第一消息的类型，通过第一消息的消息内容携带用于说明业务需求的业务内容，使得处于应用平面的应用可以使用所述第一消息将所述业务需求中的目标对象以及在所述目标对象上实现所述业务需求的操作发向处于控制层面的控制器。而且，通过第二消息的消息头定义所述第二消息的类型，通过第二消息的消息内容携带用于说明业务需求的业务内容，当接收到从所述控制器发送的所述第二消息时，所述应用可以识别并获取所述第二消息的消息内容中携带的，用于实现所述业务内容的至少一个方案的方案信息，由此实现了应用平面和控制平面之间业务需求到控制需求转换。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为一种SDN的架构示意图；
图2为本发明实施例提供的一种消息的报文格式示意图；
图3为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之一；
图4为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之二；
图5为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之三；
图6为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之四；
图7为本发明实施例提供的一种应用场景示意图；
图8为本发明实施例提供的一种消息处理装置的装置结构图；
图9为本发明实施例提供的一种消息处理装置的装置结构图；
图10为本发明实施例提供的一种消息处理系统的系统结构图；
图11为本发明实施例提供的一种应用设备的硬件结构图；
图12为本发明实施例提供的一种控制器的硬件结构图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
随着SDN技术的发展，希望最终可以根据SDN的各平面的特点，灵活的根据业务需求对网络资源、网络行为进行控制。在传统的SDN中，已经可以在技术上成熟的分离出从功能上相互独立的转发平面和控制平面，分别实现转发功能和控制功能。
根据对SDN需求的提升，目前的关注点开始转移到了应用平面和控制平面之间，希望应用平面能够实现只需要关注用户的意图(intent)，而不需要关注用户意图在SDN中具体的实现细节。为了实现上述目的，需要应用平面可以通过抽象描述的业务需求，清楚的表达、体现用户意图。相应的，控制平面需要能够理解应用平面提供的，用于体现用户意图的业务需求中的描述，并给出对应的网络实现，即确定出具体在SND中实现该业务需求的控制需求。可见，如何在SDN中的应用平面和控制平面之间实现业务需求到控制需求转换是目前亟待解决的技术问题。
为了达到上述目的，发明人发现，控制平面可以提供北向接口(英文：Northbound Interface，缩写：NBI)用于与应用平面进行交互。具体的，向应用平面提供的NBI可以基于意图的北向接口(英文：Intent-based NBI)。这种基于意图的北向接口是一种用于描述用户意图的、高度抽象的、网络具体实现细节无关的北向接口。根据Intent-based NBI所提供的功能，应用平面只需 要对网络需求进行抽象的描述，如连通性，带宽，业务部署生命周期等。应用平面只需关注用户意图，无需描述网络如何实现该用户意图。而控制平面会根据应用平面对用户需求所使用的特定语法、语义描述，编译映射转换成为对网络资源的控制需求。
可见，通过北向接口，应用平面和控制平面之间通过意图协商(intent negotiation)的过程，可以实现业务需求到控制需求转换。在本发明中，除了从流程上定义应用平面与控制平面之间可能需要的交互步骤和所使用的网络接口，还从根本上定义了Intent-based NBI实现标准，使得应用平面和控制平面之间能够通过标准，确实实现业务需求到控制需求转换。
为此，本发明实施例提供了一种消息处理方法、装置和系统，通过第一消息的消息头定义所述第一消息的类型，通过第一消息的消息内容携带用于说明业务需求的业务内容，使得处于应用平面的应用可以使用所述第一消息将所述业务需求中的目标对象以及在所述目标对象上实现所述业务需求的操作发向处于控制层面的控制器。而且，通过第二消息的消息头定义所述第二消息的类型，通过第二消息的消息内容携带用于说明业务需求的业务内容，当接收到从所述控制器发送的所述第二消息时，所述应用可以识别并获取所述第二消息的消息内容中携带的用于实现所述业务内容的至少一个方案，由此实现了应用平面和控制平面之间业务需求到控制需求转换。
在本发明实施例中，所述的应用可以理解为处于SDN中的应用平面，所述应用可以是一系列的应用程序，所述应用可以通过驻留在任意数量的物理平台或虚拟平台上的任意数量的软件组件来实现。所述物理平台可以是物理服务器等物理设备，所述虚拟平台可以是虚拟机(英文：Virtual Machine，缩写：VM)等虚拟设备，所述软件组件可以是应用进程、线程等。所述应用可以为一种网络应用，例如可以是带宽按需分配(英文：Bandwidth on Demand，缩写：BoD)应用、SFC应用(一种业务功能串接的技术，英文为Service Function Chaining)等。
所述应用可以通过直接或编程的方式，通过网络控制器提供的抽象接口，向网络控制器发送网络需求和期待的既定网络行为。所述应用通常将业务逻辑和一个或多个不同底层网络技术的适配驱动，以完成业务所需的业务需求的描述。而所述控制器可以根据所述应用所描述的业务需求，进行网络资源的控制、管理和配置，满足网络业务定制需求。
所述的控制器可以理解为处于SDN中的控制平面，是一个可以控制网络资源集的软件实体。所述控制器可以通过驻留在任意数量的物理平台上的任何数量的软件组件来实现。所述控制器可以是一种网络控制器，例如可以是OpenDaylight(一种分布式的网络控制器)、ONOS(一种开放式网络操作系统)、Floodlight(一种OpenFlow控制器)等。在本发明实施例中提到的消息，具体组成形式可以参见图2，图2为本发明实施例提供的一种消息的报文格式示意图。如图2所示，一个消息包括消息头和消息内容(英文：payload)两个部分。可以通过一个消息的消息头部分标识这个消息的消息类型，消息类型可以包括请求(英文：request)消息、响应(英文：response)消息、选择(英文：selection)消息和确认(英文：confirmation)消息。在实现的过程中，可以通过不同的类型值定义不同的消息类型，例如可以如表1所示。
消息类型 类型值(十六进制)
请求消息 0X01
响应消息 0X02
选择消息 0X03
确认消息 0X04
表1
由此，所述应用或者所述控制器在接收到一个消息时，可以通过该消息的消息头识别出该消息的类型。
一个消息的消息内容中携带的内容与这个消息的消息类型相关。例如：
若一个消息为请求消息，该消息的消息内容中可以携带用于说明业务需求的业务内容和/或用于补充说明所述业务需求的补充内容。可见，所述请求消息主要由所述应用向所述控制器发送，通过所述请求消息携带的内容，向所述控制器说明用户意图具体是什么。
若一个消息为响应消息，该消息的消息内容中可以携带实现所述业务内容的至少一个方案的方案信息和/或用于请求所述应用补充的内容，请求补充的内容可以通过约束维度项和/或上下文需求项携带。具体的，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
这里所述的至少一个方案的方案信息可以包括对所述至少一个方案的具体方案描述，所述方案描述可以包括针对所述至少一个方案的具体实现描述， 可以包括所述至少一个方案中各模块的主要功能特性，各模块之间的依赖关系以及处理逻辑顺序，各模块功能与业务需求的对应关系等。或者，所述的至少一个方案的方案信息也可以包括所述至少一个方案所对应的方案标识，需要注意的是，为了起到明确的标识作用，一般情况下，一个方案具有一个唯一方案标识。所述方案标识可以为字符串的形式，或者也可以直接使用方案名称作为方案标识，或者也可以是能够实现唯一标识所述至少一个方案的其他标识形式。当所述方案信息为方案标识时，所述应用和所述控制器之间需要进行事先的网络协商，以使得所述应用通过方案标识可以理解所标识方案的具体内容或大概流程。可见，所述响应消息主要由所述控制器向所述应用发送，通过所述响应消息携带的内容，向所述应用展示，通过SDN如何实现用户意图。一般来说，所述控制器不会主动向所述应用发送响应消息，所述控制器主要在接收到所述应用发送的请求消息后，才会针对性的向所述应用返回相应的响应消息。
若一个消息为选择消息，该消息的消息内容中包括所述应用选择的目标方案或者目标方案的标识。可见，所述选择消息主要由所述应用向所述控制器发送，通过所述选择消息携带的内容，用于告知所述控制器，所述应用选择的方案。
若一个消息为确认消息，该消息的消息内容中包括所述目标方案的实现结果，即所述控制器针对目标方案在网络中的实现结果。可见，所述确认消息主要由所述控制器向所述应用发送，通过所述确认消息携带的内容，用于告知所述应用，所述目标方案是否在网络中得以实现。一般来说，所述控制器不会主动向所述应用发送确认消息，所述控制器主要在接收到所述应用发送的选择消息后，才会针对性的向所述应用返回相应的确认消息。
描述完消息内容与这个消息的消息类型之间的相关性之后，接下来将详细说明所述消息内容中的可以包含的内容。不同类型消息的消息内容中所携带的内容有所不同，这里以消息类型为分类，对消息内容进行说明。
针对请求消息的消息内容：
一个请求消息的消息内容中可以包括目标字段(英文：object)、操作字段(英文：operation)和约束字段(英文：constraint)。这三个字段在消息内容中可以看作是一个三元组(英文：3-tuple pattern)，三元组所在字段统称为业务需求字段，三元组的具体形式可以为：{object,operation,constraint}。
目标字段中的内容可以用于描述业务需求要操作、管理或影响的目标对象。这里所述的目标对象是一种抽象的表述方法，可是一种网络资源，也可以是一种用户资源。
操作字段中的内容可以用于描述在所述目标对象上实现业务需求所需的操作，这里所述的操作可以为需要进行的处理、动作等，这些处理、动作可以在特定条件下实现。
约束字段中的内容可以用于描述对所述业务内容的约束条件，也就是在对所述业务内容进行实现所述业务需求的操作时，所需要满足的限定内容、限定参数等。
针对复杂的业务需求，一个请求消息的消息内容中可以包括一个或者多个三元组。不过有些情况下，三元组中的三个字段并不会同时都出现，有时请求消息的消息内容中只需要包含其中的一个或两个字段的组合。
需要注意的是，针对同一个业务需求，也有可能会有一个或者多个的业务运行环境，或者需要应用在不同的应用场景中。所以，为了可以清楚的描述一个业务需求的相关环境信息、背景信息，所述请求消息的消息内容中还可以包括上下文字段(英文：context)。上下文字段中的内容用于描述与所述业务需求相关的特定环境信息、背景信息。上下文字段中可以包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。针对复杂的业务需求，一个请求消息的消息内容中可以包括一个或多个上下文字段。
针对响应消息的消息内容：
一个响应消息的消息内容中可以包括约束维度项、上下文需求项和实现业务需求方案的方案信息部分。
约束维度项中的内容用于描述在满足业务需求(针对请求消息中请求实现的业务需求)实现时，可以或必须进行约束的、且还需要由应用补充的约束条件。通过约束维度项中的内容，可以用于请求接收到这个响应消息的应用回复相应的约束条件。针对复杂的业务需求，一个响应消息的消息内容中可以包括一个或多个约束维度项。
上下文需求项中的内容用于描述在满足业务需求(针对请求消息中请求实现的业务需求)实现时，可以或必须要由应用补充的环境信息。通过上下文需求项中的内容，可以用于请求接收到这个响应消息的应用回复相应的环境信息。针对复杂的业务需求，一个响应消息的消息内容中可以包括一个或 多个上下文需求项。
实现业务需求方案的方案信息部分中包括方案的具体方案描述，或者，也可以包括方案所对应的方案标识。由于事先业务需求的方案可以有一个或多个方案，方案信息部分也可以对应的有一个或多个方案信息。通过实现业务需求方案的方案信息部分，可以向接收到这个响应消息的应用展示实现业务需求的途径。
接下来说明承载所述消息的方式，在本发明实施例中，可以通过传输控制协议报文等现有报文格式携带所述消息，也可以通过自定义的报文格式携带所述消息。现有报文格式例如具体可以是传输控制协议(英文：Transmission Control Protocol，缩写：TCP)报文，用户数据报协议(英文：User Datagram Protocol，缩写：UDP)报文，流控制传输协议(英文：Stream Control Transmission Protocol，缩写：SCTP)报文等。
一般可以通过报文的报文内容部分来携带所述消息。所述消息在报文中的格式根据消息类型的不同而有所不同。
请求消息在报文中的格式可以如表2所示：
Figure PCTCN2016110123-appb-000001
表2
其中，请求消息的消息头部分用于标识消息类型为请求消息。
请求消息的消息长度，用来标识该请求消息的消息内容的字节长度。以确定出该请求消息头后多少字节内的内容属于该请求消息的消息头对应的消息内容。请求消息的消息长度，也可以用来标识该请求消息的消息头和消息内容的字节长度之和。
业务需求头、业务需求组、上下文字段头和上下文字段都属于请求消息的消息内容的可能组成部分。
业务需求头可以包括业务需求个数字段和业务需求长度字段。其中，业务需求个数字段用于标识业务需求组中有多少个三元组，业务需求长度字段用于标识业务需求组总共占用的字节长度。
业务需求组中可以包括目标字段、操作字段和约束字段，这三个字段的长度可以是固定字节长度的，也可以是非固定字节长度的。在非固定字节长度的情况下，这三个字段还可以有对应的头(英文：header)，用于标识所对 应字段的开始位置和字节长度。在业务需求组中，还可以通过目标字段中的标志位字段(英文：c_flag)来标识业务需求组中是否包含有约束字段，例如标志位字段为1时，表示该业务需求组中包含约束字段，标志位字段为0时表示该业务需求组中不包含约束字段。
上下文字段头中可以包括上下文信息个数字段和上下文信息长度字段，上下文信息个数字段可以用于标识上下文字段中包括上下文信息的个数，上下文信息长度字段可以用于标识上下文字段的总字节长度。
上下文字段中包括上下文信息。
响应消息在报文中的格式可以如表3所示：
Figure PCTCN2016110123-appb-000002
表3
其中，响应消息的消息头部分用于标识消息类型为响应消息。
响应消息的消息长度，用来标识该响应消息的消息内容的字节长度。以确定出该响应消息头后多少字节内的内容属于该响应消息的消息头对应的消息内容。响应消息的消息长度，也可以用来标识该响应消息的消息头和消息内容的字节长度之和。
上下文需求项用于标识在响应消息中是否包含上下文需求项，例如当上下文需求项的标志位为1时，可以认为相当于在该响应消息中包含上下文需求项，以请求应用发送相应的上下文信息。当上下文需求项的标志位为0时，可以认为相当于在该响应消息中不包含上下文需求项，不需要应用发送上下文信息。
约束维度头中可以包括约束维度个数字段和约束维度长度字段。其中，约束维度个数字段用于标识约束维度项字段中具有约束维度项的个数。约束维度长度字段用于标识约束维度项字段所占用的字节总长度。
约束维度项字段中包含的约束维度项可以是固定字节长度的，也可以是非固定字节长度的。在非固定字节长度的情况下，约束维度项还可以有对应的头(英文：header)，用于标识所对应约束维度项的开始位置和字节长度。
实现业务需求方案的方案信息头中可以包括方案信息个数字段和方案信息长度字段。其中，方案信息个数字段用于标识实现业务需求方案的方案信息字段中具有方案的个数，也就是相对应的方案信息的个数。方案信息长度字段用于标识实现业务需求方案的方案信息字段所占用的字节总长度。
实现业务需求方案的方案信息字段中的方案信息可以是固定字节长度的，也可以是非固定字节长度的。在非固定字节长度的情况下，方案信息还可以有对应的头(英文：header)，用于标识所对应方案信息的开始位置和字节长度。
接下来将描述SDN中的应用平面和控制平面之间的实际消息交互过程，以通过具体的应用场景对本发明中对消息的处理进行进一步的说明。
图3为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之一，如图3所示，包括：
100：应用向控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作，这些处理、动作可以在特定条件下实现。
举例说明，当用户具有一个需要在网络上实现某些功能的意图时，可以通过应用，以请求消息明确的描述出用户意图中的网络需求和期待的既定网络行为等。一个请求消息可以描述一个或多个用户意图。
所述第一消息属于一种请求消息，可以理解是针对一个用户意图，所述应用向所述控制器发送的第一次请求消息或者说首次请求消息。作为首次描述一个用户意图的请求消息，需要充分描述清楚用户的意图，所述目标信息和操作信息可以是核心内容，属于必选部分，需要通过目标信息和操作信息描述一个用户意图的目标对象和在所述目标对象上实现所述业务需求的操作。
所述第一消息的消息内容中所包括的部分均可以作为业务内容的一部分。针对较为复杂的用户意图，所述第一消息的消息内容中还可以包括约束信息和/或上下文信息，以更好的描述用户意图。其中，通过约束信息可以标识对所述业务内容的约束条件，通过上下文信息可以标识所述业务内容的环 境信息。相应的，除了可以包括所述目标信息和操作信息，所述业务内容中还可以包括所述第一消息的消息内容中的约束信息和/或上下文信息。
其中，若所述业务内容中包括目标信息和操作信息，所述目标信息可以置于所述第一消息的消息内容的目标字段中，所述操作信息可以置于所述第一消息的消息内容的操作字段中。若所述业务内容中包括约束信息，所述约束信息可以置于所述第一消息的消息内容的约束字段中。若所述业务内容中包括上下文信息，所述上下文信息可以置于所述第一消息的消息内容的上下文字段中。
101：所述控制器根据所述第一消息的消息头识别所述第一消息为请求消息。
当所述控制器收到所述应用通过步骤100发送的第一消息时，可以根据上述定义的消息头功能，识别出所述第一消息为一个请求消息。
102：所述控制器根据所述第一消息的消息内容，获取所述业务内容。
上文中已经描述了请求消息的格式，所述控制器在处理第一消息时，通过请求消息的消息长度可以确定出之后多少字节长度的内容是属于所述第一消息的消息内容的，由此获取所述业务内容。
所述控制器获取所述业务内容后，根据对所述业务内容的处理，可以得到至少三种不同的结果。
第一种结果，所述业务内容所包含的内容充分，所述控制器可以确定出实现所述业务内容的全部方案。
第二种结果，所述业务内容所包含的内容不是很充分，所述控制器可以确定出实现所述业务内容的部分方案或者实现一部分所述业务内容的方案，但针对所述业务内容的一些部分内容或方案，所述控制器依据目前得到的所述业务内容尚不能确定出可实现的方案，为此，所述控制器可以确定出所述应用还需要为此补充的内容，例如，确定出请求所述应用回复针对所述业务内容的约束条件，确定出请求所述应用回复针对所述业务内容的环境信息。
第三种结果，所述业务内容所包含的内容不充分，所述控制器无法依据目前得到的所述业务内容确定出实现的方案。为了得出能够实现用户意图的方案，所述控制器需要确定出所述应用还需要为此补充的内容。
在图3所对应实施例中，主要描述在出现上述三种结果中的所述第一种 结果和第二种结果时，即确定出实现所述业务内容的方案时，所述控制器如何与所述应用进行交互。具体参见步骤103和104中的内容和描述。
103：所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案。
在出现所述第一种结果时，所述控制器可以确定出实现所述业务内容的至少一个方案，这里所述的至少一个方案可以理解为实现所述业务内容的全部方案。在出现所述第二种结果时，所述控制器确定出的至少一个方案可以理解为实现所述业务内容的部分方案，或者实现一部分所述业务内容的方案。此外，为了得到针对所述业务内容可以再确定出的剩余方案，所述控制器还可以确定需要所述应用再进行补充的内容。
200：所述控制器向所述应用发送第二消息，所述述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
举例说明，所述第二消息属于一种包括了方案信息的响应消息，所述第二消息的格式也可以如表3所示。在出现所述第一种结果时，所述第二消息中将不包括上下文需求项(例如上下文需求项的标志位为0时，相当于不包括上下文需求项)、约束维度头和约束维度项字段这三个部分。
在出现所述第二种结果时，所述控制器可以将确定出的，需要所述应用再进行补充的内容添加到所述第二消息的消息内容中相应的位置。例如，将用于请求所述应用回复针对所述业务内容的约束条件作为约束维度项放到第二消息的消息内容中的约束维度项字段中。将第二消息的消息内容中的上下文需求项的标志位设置为1等。
需要注意的是，针对所述至少一个方案，虽然将完整的方案(例如方案的全部流程)发送给所述应用可以帮助使用所述应用的用户清楚理解方案，但是，传输完整方案可能会消耗较多的网络资源，在一些网络资源紧张的应用场景下，传输完整方案会造成较大的网络负担。故可以针对不同的应用场景和要求，通过不同的形式，通过所述第二消息向所述应用发送所述至少一个方案。在本发明实施例中，所述第二消息的消息内容中为所述至少一个方案的方案信息。在网络资源允许的情况下，可以将完整的方案，也就是所述 至少一个方案的具体方案描述作为所述至少一个方案的方案信息，在网络资源紧张的情况下，也可以将所述至少一个方案对应的方案标识作为所述至少一个方案的方案信息。在这两种可能的方案信息的实现中，所述控制器都可以将所述至少一个方案，和/或所述至少一个方案与方案标识的对应关系保存在控制器端，以便后续调用。
201：所述应用根据所述第二消息的消息头识别所述第二消息为响应消息。
当所述应用收到所述控制器通过步骤200发送的第二消息时，可以根据上述定义的消息头功能，识别出所述第而消息为一个响应消息。
202：所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
上文中已经描述了响应消息的格式，所述应用在处理第二消息时，通过响应消息的消息长度可以确定出之后多少字节长度的内容是属于所述第二消息的消息内容的，由此获取所述第二消息的消息内容中的所述至少一个方案的方案信息。
需要注意的是，若所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述应用根据所述第二消息的消息内容，除了获取所述至少一个方案，还可以获取所述第二消息包括的约束维度项和/或上下文需求项。
所述应用在获取到所述至少一个方案的方案信息后，可以有至少两种处理方式。
第一种处理方式，用户对所述控制器提供的所述至少一个方案的方案信息比较满意，其中有至少有一个目标方案可以满足用户的需求。也就是说，用户可以从所述至少一个方案的方案信息选择出一个目标方案或者一个目标方案的标识。
第一种处理方式既可以对应上述第一种结果，也可以对应上述第二种结果。也就是说，在所述第二消息的消息内容中仅包括所述至少一种方案的方案信息时，所述应用可以实施所述第一种处理方式，在所述第二消息的消息内容中不仅包括所述至少一种方案的方案信息，也包括约束维度项和/或上下文需求项时，所述应用也可以实施所述第一种处理方式。
第二种处理方式，用户对所述控制器提供的所述至少一个方案的方案信息均不满意，不能满足用户的需求。用户更倾向于根据所述第二消息中的约 束维度项和/或上下文需求项进行内容的补充。
在所述第二消息的消息内容中仅包括所述至少一种方案的方案信息时，所述控制器已经提供了能够实现用户意图的全部方案，不需要再向所述控制器补充内容。故第二种处理方式主要对应上述第二种结果。也就是说，在所述第二消息的消息内容中不仅包括所述至少一种方案的方案信息，也包括约束维度项和/或上下文需求项时，所述应用可以实施所述第二种处理方式。
针对第一种处理方式，在图3所对应实施例的基础上，图4为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之二，如图4所示：
200：所述控制器向所述应用发送第二消息。
所述应用在接收到所述第二消息后还有识别和读取消息内容的步骤，这里不再赘述。
300：所述应用向所述控制器发送第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识。
举例说明，当用户从所述至少一个方案中确定出目标方案，需要通过所述应用将选择的结果告知所述控制器。所述第六消息属于一种选择消息，可以通过所述第六消息的消息内容携带选择的结果，以告知所述控制器。
若所述应用通过步骤200获得的所述至少一个方案的方案信息具体包括所述至少一个方案的方案描述，则可以将选择的所述目标方案作为选择的结果，直接添加在所述第六消息的消息内容中，也可以将所述目标方案的方案标识作为选择的结果，添加在所述第六消息的消息内容中。
若所述应用通过步骤200获得的所述至少一个方案的方案信息具体包括所述至少一个方案对应的方案标识。那么可以将所述目标方案的方案标识作为选择的结果，添加在所述第六消息的消息内容中。
301：所述控制器根据所述第六消息的消息头识别所述第六消息为选择消息。
302：所述控制器根据所述第六消息的消息内容，确定所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
举例说明，所述控制器通过所述第六消息，确定了用户所选择的目标方案，根据所述目标方案进行实现，并通过所述实现结果用来标识所述目标方 案是否实现。
所述控制器根据所述第六消息的消息内容，若获取的是对所述目标方案的方案标识，可以通过预先保存的方案与方案标识之间的对应关系确定出所述目标方案。
400：所述控制器向所述应用发送针对所述第六消息的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果。
举例说明，当所述控制器确定出所述目标方案的实现结果，需要将所述实现结果告知所述应用，以向用户明确所述目标方案是否已经实现了。所述第七消息属于一种确认消息，所述控制器可以通过所述第七消息的消息内容携带所述目标方案的实现结果，以告知所述应用。
针对第二种处理方式，在图3所对应实施例的基础上，图5为本发明实施例提供的一种应用平面和控制平面的消息交互信令图之三，如图5所示：
200：所述控制器向所述应用发送第二消息。
所述应用在接收到所述第二消息后还有识别和读取消息内容的步骤，这里不再赘述。
203：所述应用根据所述第二消息包括的约束维度项和/或上下文需求项确定第一补充内容。
举例说明，所述第一补充内容和所述控制器通过所述第二消息请求所述应用提供的内容相关。若所述第二消息包括约束维度项，所述第一补充内容包括所述第二消息的约束维度项中所要求的约束条件。若所述第二消息包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
500：所述应用向所述控制器发送第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括所述第一补充内容。其中，若所述第二消息的消息内容包括约束维度项，所述第一补充内容包括所述第二消息的约束维度项中所要求的约束条件；若所述第二消息的消息内容包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
举例说明，所述第三消息属于一种请求消息，这种请求消息是根据包括了方案信息的响应消息中的请求所回复的请求消息。
其中，若所述第二消息的消息内容包括约束维度项，所述第三消息包括约束字段，所述第二消息的约束维度项中所要求的约束条件可以置于所述第三消息的消息内容的约束字段中。
若所述第二消息的消息内容包括上下文需求项，所述第三消息包括上下文字段，所述第二消息的上下文需求项中所要求的环境信息可以置于所述第三消息的消息内容的上下文字段中。
除了第一补充内容以外，所述第三消息中还可以携带原本在所述第一消息的消息内容中包括的所述业务内容。由此可以使得所述控制器根据所述业务内容和所述第一补充内容来确定实现所述业务内容的方案。其中，若所述业务内容包括目标信息和操作信息，所述目标信息可以置于所述第三消息的消息内容的目标字段中，所述操作信息可以置于所述第三消息的消息内容的操作字段中。若所述业务内容包括约束信息，所述约束信息可以置于所述第三消息的消息内容的约束字段中。若所述业务内容包括上下文信息，所述上下文信息可以置于所述第三消息的消息内容的上下文字段中。
需要注意的是，由于所述第三消息是在所述第一消息之后向所述控制器发送的请求消息，所述控制器已经通过所述第一消息获取了所述业务内容，例如目标信息和操作信息等。为了节约网络资源，可以通过预先的协商，所述应用在发送所述第三消息时，可以不再在所述第三消息中携带原本在所述第一消息的消息内容中包括的所述业务内容。
为了实现上述不在所述第三消息中携带所述业务内容的效果，通过预先的协商，所述应用在发送所述第一消息和第三消息时，可以携带相同的标识。可选的，在本发明实施例中，若所述应用不希望在所述第三消息中携带所述业务内容，所述应用可以在所述第一消息和所述第三消息中携带相同的标识，例如用于标识所述目标对象的对象标识，需要注意的是，这里的所述对象标识和所述业务内容的目标信息中用于标识目标对象的内容可以相同，也可以不同。所述对象标识可以通过所述第三消息的目标字段携带，也可以携带在所述第三消息的其他位置，本发明对此不限定。
通过预先的协商，所述控制器可以在接收到所述第一消息时，保存所述业务内容并记录所述对象标识。这样所述控制器在接收到仅携带所述第一补 充内容的第三消息时，可以根据所述第三消息携带的对象标识，调取之前保存的所述业务对象，然后再结合所述第三消息中的第一补充消息，来确定实现所述业务内容的方案。
501：所述控制器根据所述第三消息的消息头识别所述第三消息为请求消息。
502：所述控制器获取所述第三消息的消息内容。
所述控制器将根据所述第三消息的消息内容中携带内容的不同，进行不同的处理。
若所述第三消息仅携带所述第一补充消息，所述控制器可以根据所述对象标识，可以调取与所述对象标识对应的所述业务内容。然后再结合所述第三消息中的第一补充消息，来确定实现所述业务内容的方案。
若所述第三消息携带了所述业务内容和所述第一补充消息，所述控制器在接收所述第一消息时，可以不用保存所述业务内容，相应的减少了所述控制器的存储压力。所述控制器将根据从所述第三消息的消息内容中获取的所述业务内容和所述第一补充消息来确定实现所述业务内容的方案。
需要注意的是，有可能所述第一补充内容并不能符合所述控制器的需求，例如所述应用发送了错误的补充内容，或者发送的补充内容不充分，不足以让所述控制器确定出新的方案。为此，所述控制器可以根据所述第一补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。然后，所述控制器可以再一次向所述应用发送响应消息，以指示所述应用继续提供相应的补充内容，直到所述应用提供了所述控制器需要的补充内容，或者所述应用选择了目标方案为止。在这一阶段，所述控制器向所述应用发送的响应消息中，可以是携带了方案的第二消息，也可以是不携带方案，而仅携带约束维度项和/或上下文需求项的响应消息。针对不携带方案，而仅携带约束维度项和/或上下文需求项的响应消息的说明可以参见图6所对应的实施例。
接下来将针对图3所对应实施例中步骤102中描述的第三种结果进行说明。所述第三种情况也就是针对所述业务内容所包含的内容不充分，所述控制器无法依据目前得到的所述业务内容确定出实现的方案。为了得出能够实现用户意图的方案，所述控制器需要确定出所述应用还需要为此补充的内容。
在图3所对应实施例的基础上，图6为本发明实施例提供的一种应用平 面和控制平面的消息交互信令图之四，如图6所示：
100：所述应用向控制器发送所述第一消息。
101：所述控制器根据所述第一消息的消息头识别所述第一消息为请求消息。
102：所述控制器根据所述第一消息的消息内容，获取所述业务内容。
104：若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。
举例说明，步骤104主要是针对当步骤102的处理结果为上述第三种结果时的操作，也就是针对所述控制器依据目前得到的所述业务内容，一个实现的方案都无法确定出的情况所进行的操作。
600：所述控制器向所述应用发送第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括所述约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
举例说明，所述第四消息属于一种不包括方案信息的响应消息。所述控制器可以将确定出的，需要所述应用再进行补充的内容添加到所述第四消息的消息内容中相应的位置。
601：所述应用根据所述第四消息的消息头识别所述第四消息为响应消息。
602：所述应用根据所述第四消息的消息内容，获取所述第四消息包括的约束维度项和/或上下文需求项。
603：所述应用根据所述第四消息包括的约束维度项和/或上下文需求项确定第二补充内容。
700：所述应用向所述控制器发送第五消息，所述第五消息包括消息头和消息内容，所述第五消息的消息头用于标识所述第五消息的消息类型为请求消息，所述第五消息的消息内容包括所述第二补充内容。其中，若所述第四消息的消息内容包括约束维度项，所述第二补充内容包括所述第四消息的约束维度项中所要求的约束条件；若所述第四消息的消息内容包括上下文需求项，所述第二补充内容包括所述第四消息的上下文需求项中所要求的环境信 息。
举例说明，所述第五消息属于一种请求消息，这种请求消息是根据不包括方案信息的响应消息中的请求所回复的请求消息。
其中，若所述第四消息的消息内容包括约束维度项，所述第五消息包括约束字段，所述第四消息的约束维度项中所要求的约束条件可以置于所述第五消息的消息内容的约束字段中。
若所述第四消息的消息内容包括上下文需求项，所述第五消息包括上下文字段，所述第四消息的上下文需求项中所要求的环境信息可以置于所述第五消息的消息内容的上下文字段中。除了第二补充内容以外，所述第五消息中还可以携带原本在所述第一消息的消息内容中包括的所述业务内容。由此可以使得所述控制器根据所述业务内容和所述第二补充内容来确定实现所述业务内容的方案。其中，若所述业务内容包括目标信息和操作信息，所述目标信息可以置于所述第五消息的消息内容的目标字段中，所述操作信息可以置于所述第五消息的消息内容的操作字段中。若所述业务内容包括约束信息，所述约束信息可以置于所述第五消息的消息内容的约束字段中。若所述业务内容包括上下文信息，所述上下文信息可以置于所述第五消息的消息内容的上下文字段中。
需要注意的是，由于所述第五消息是在所述第一消息之后向所述控制器发送的请求消息，所述控制器已经通过所述第一消息获取了所述业务内容，例如目标信息和操作信息中的内容等。为了节约网络资源，可以通过预先的协商，所述应用在发送所述第五消息时，可以不再在所述第五消息中携带原本在所述第一消息的消息内容中包括的所述业务内容。针对所述第五消息的具体的实现流程和针对所述第三消息的实现流程类似，这里不再赘述。
在所述应用向所述控制器发送所述第五消息后，有可能所述第二补充内容并不能符合所述控制器的需求，不足以让所述控制器确定出可实现的方案。为此，所述控制器可以根据所述第二补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。然后，所述控制器可以再一次向所述应用发送响应消息，以指示所述应用继续提供相应的补充内容，直到所述应用提供了所述控制器需要的补充内容，或者所述应用选择了目标方案为止。在这一阶段，所述控制器向所述应用发送的响应消息中，可以是携带了方案的第二消息，也可以 是不携带方案，而仅携带约束维度项和/或上下文需求项的第四消息。
接下来，将通过具体的应用场景对本发明的方案进行描述。图7为本发明实施例提供的一种应用场景示意图。如图7所示：
Site1和Site2可以为企业A的两个站点，两个站点间有多条业务流(英文：flow)，分别为f1、f2和f3。
企业A的用户意图是，希望实现以下的业务需求场景：
1、Site1和Site2之间有100M带宽专用链路一条，同时可以使用公共带宽链路资源。
2、Site1和Site2之间的业务流，按照重要性进行优先级高和优先级低的两种业务流划分。
3、Site1和Site2之间的100M带宽专用链路带宽使用率不得高于80％。其中，在带宽使用率高于80％时，需要将在专用链路中业务流进行调整至公共带宽链路，重要性高的业务流不被调整至公共带宽链路，重要性低的业务流调整至公共带宽链路。
4、Site1和Site2之间的专用带宽链路中的业务流，根据业务流的上下文需求，会对带宽进行不同的金牌、银牌、铜牌等服务质量(英文：Quality of Service，缩写：QoS)优先级保证。
针对这一用户意图，可以确定出：
目标对象具体为：
设定C1为专用带宽链路，C2为公共带宽链路。f1、f2和f3的参数以及三个业务流的优先级(英文：Priority)，其中，H1为较低的优先级，H2为较高的优先级。
那么业务内容中的目标信息的内容可以如下所示：
Connection C1 Endnodes(Site1,Site2)Prosperities 100M
Connection C2 Endnodes(Site1,Site2)Prosperities 50M
Flow f1 Match src-ip:"160.1.1.0/24",dst-ip:"10.1.0.3/24”Priority:”H1”
Flow f2 Match src-ip:"160.2.1.0/24",dst-ip:"10.2.0.3/24”Priority:”H2”
Flow f3 Match src-ip:"160.3.1.0/24",dst-ip:"10.3.0.3/24”Priority:”H2”
在所述目标对象上实现所述业务需求的操作具体为：
在链接带宽使用率大于80％时进行业务流迁移。
那么业务内容的操作信息的内容可以如下所示：
Operation op1 Action move f1,f2,f3 Condition c1.utilization>80％
其中，op1为操作。
约束信息具体为：
在业务迁移时，迁移优先级为H2的业务流。
那么业务内容的约束信息的内容可以如下所示：
Constraint＝exclude(flow with Priority H2)
上下文信息具体为：
f1用于文件传输协议数据的传输，f2用于备份数据的传输，f3用于视频的传输。
那么业务内容的上下文信息的内容可以如下所示：
Context:”ftp-data”
Context:”data-backup”
Context:”video”
通过应用，将具有上述反映用户意图的业务内容的第一消息向控制器发送，控制器从第一消息的消息内容中获取该业务内容，该业务内容包括上述目标信息、操作信息、约束信息和上下文信息中的内容。其中，该第一消息可以通过消息内容中的目标字段携带目标信息，操作字段携带操作信息，约束字段携带约束信息，上下文字段携带上下文信息。
控制器根据该业务内容，确定出实现该业务内容的方案。确定出方案的过程和方案的具体内容可以如下：
创建链路连通资源，进行带宽保证。为带宽保证的连通性需求，根据实际承载该业务需求网络的实现技术，在两个站点间原有基础带宽链接上，分别创建两个流量工程(英文：Traffic Engineering，缩写：TE)隧道TE1和TE2，分别保证带宽100M和50M。
分析业务内容中三个业务流的上下文内容，三个业务流分别用于ftp数据传输，数据备份和在线视频会议。具有相同优先级的数据备份和在线视频会议两个业务中，在线视频会议对带宽更具敏感性，则对业务流f3进行金牌QoS带宽保证，对数据备份业务流f2进行银牌QoS带宽保证。
在对业务流进行转发的过程中，如果专用带宽链路的带宽使用率高与80％时，会调整业务流，并满足op1描述的约束条件。
控制器可以将确定出的方案通过第二消息发给应用，由此实现了应用平 面和控制平面之间业务需求到控制需求转换。
接下来，将再通过一个具体应用场景对本发明的方案进行描述。
该应用场景中，用户意图具体为：
站点1和站点2之间的超文本传输协议(英文：Hyper Text Transfer Protocol，缩写：HTTP)访问报文需要进行日志记录，日志记录需要按照特定日志格式处理，记录每次HTTP报文中的统一资源标识符(英文：Uniform Resource Identifier，缩写：URI)。
针对这一用户意图，可以确定出：
目标对象具体为：
站点1和站点2之间的HTTP业务流f1。
那么业务内容的目标信息的内容可以如下所示：
Flow f1 Match src-ip:"160.1.1.0/24",dst-ip:"10.1.0.3/24”,dst-port:”8080”
在所述目标对象上实现所述业务需求的操作具体为：
需要继续URI日志处理。
那么业务内容的操作信息的内容可以如下所示：
Operation op1 Action uri-logging f1
上下文信息具体为：
HTTP报文的URI日志记录。
那么业务内容的上下文信息的内容可以如下所示：
Context:”http-uri-logging”
通过应用，将具有上述反映用户意图的业务内容的第一消息向控制器发送，控制器从第一消息的消息内容中获取该业务内容，该业务内容包括上述目标信息、操作信息和上下文信息中的内容。其中，该第一消息可以通过消息内容中的目标字段携带目标信息，操作字段携带操作信息，上下文字段携带上下文信息。
控制器根据该业务内容，确定出实现该业务内容的方案。实现HTTP报文的URI的日志记录的方案，需要两个步骤，具体内容可以如下：
第一步，对业务流数据报文进行分类和深度包检测(英文：Deep Packet Inspection，缩写：DPI)解析，获取HTTP报文的URI。
第二步，进行log处理。
这需要两个不同的业务功能(英文：service function)的处理，且有先后顺序关系。
这个方案的方案描述可以如下所示：
Solution s1 1st DPI:“packet filtering and de-capsulation”,2nd LOG:“logging”
这个方案对应的方案标识可以为：service-catalog-5.2。
这个方案的处理步骤和方案标识可以预先保存在用户手册(英文：user manual)中，或者保存在业务定制入口(英文：portal)。
控制器在第二消息的消息内容中添加的这个方案的方案信息可以有两种形式，使用哪一种形式可以预先设置。第一种形式是将这个方案的方案描述添加到所述第二消息的消息内容中。第二种形式是仅仅将这个方案对应的方案标识添加到所述第二消息的消息内容中。在第二种形式中，应用在收到方案标识service-catalog-5.2后，可以根据这个方案标识唯一的确定出这个方案具体的方案描述。
可见，通过第一消息的消息头定义所述第一消息的类型，通过第一消息的消息内容携带用于说明业务需求的业务内容，使得处于应用平面的应用可以使用所述第一消息将所述业务需求中的目标对象以及在所述目标对象上实现所述业务需求的操作发向处于控制层面的控制器。而且，通过第二消息的消息头定义所述第二消息的类型，通过第二消息的消息内容携带用于说明业务需求的业务内容，当接收到从所述控制器发送的所述第二消息时，所述应用可以识别并获取所述第二消息的消息内容中携带的，用于实现所述业务内容的至少一个方案的方案信息，由此实现了应用平面和控制平面之间业务需求到控制需求转换。
图8为本发明实施例提供的一种消息处理装置的装置结构图，应用于SDN中，所述消息处理装置800包括：
发送单元801，用于向控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
接收单元802，用于接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；
识别单元803，用于根据所述第二消息的消息头识别所述第二消息为响应消息；
获取单元804，用于根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
可选的，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
可选的，所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息；
所述获取单元还用于根据所述第二消息的消息内容，获取所述第二消息包括的约束维度项和/或上下文需求项，以及获取所述第二消息包括的至少一个方案的方案信息。
可选的，所述装置还包括：
确定单元，用于根据所述第二消息包括的约束维度项和/或上下文需求项确定第一补充内容；
所述发送单元还用于向所述控制器发送第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括所述第一补充内容，其中，若所述第二消息的消息内容包括约束维度项，所述第一补充内容包括所述第二消息的约束维度项中所要求的约束条件；若所述第二消息的消息内容包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
可选的，
若所述第三消息的消息内容中未包括所述业务内容，所述第三消息和所 述第一消息均携带用于标识所述目标对象的对象标识；或者，
所述第三消息的消息内容中包括所述业务内容和所述第一补充内容。
可选的，
所述接收单元还用于接收所述控制器发送的第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括约束维度项和/或上下文需求项；
所述识别单元还用于根据所述第四消息的消息头识别所述第四消息为响应消息；
所述获取单元还用于根据所述第四消息的消息内容，获取所述第四消息包括的约束维度项和/或上下文需求项；
所述确定单元还用于根据所述第四消息包括的约束维度项和/或上下文需求项确定第二补充内容；
所述发送单元还用于向所述控制器发送第五消息，所述第五消息包括消息头和消息内容，所述第五消息的消息头用于标识所述第五消息的消息类型为请求消息，所述第五消息的消息内容包括所述第二补充内容，其中，若所述第四消息的消息内容包括约束维度项，所述第二补充内容包括所述第四消息的约束维度项中所要求的约束条件；若所述第四消息的消息内容包括上下文需求项，所述第二补充内容包括所述第四消息的上下文需求项中所要求的环境信息。
可选的，
若所述业务内容包括目标信息和操作信息，所述目标信息置于请求消息的消息内容的目标字段中，所述操作信息置于请求消息的消息内容的操作字段中；
若所述业务内容包括约束信息，所述约束信息置于请求消息的消息内容的约束字段中；
若所述业务内容包括上下文信息，所述上下文信息置于请求消息的消息内容的上下文字段中；
若请求消息的消息内容包括所述第一补充内容，所述第二消息的约束维度项中所要求的约束条件置于请求消息的消息内容的约束字段中，所述第二消息的上下文需求项中所要求的环境信息置于请求消息的消息内容的上下文 字段中；
若请求消息的消息内容包括所述第二补充内容，所述第四消息的约束维度项中所要求的约束条件置于请求消息的消息内容的约束字段中，所述第四消息的上下文需求项中所要求的环境信息置于请求消息的消息内容的上下文字段中。
可选的，
所述发送单元还用于向所述控制器发送第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
所述接收单元还用于接收所述控制器针对所述第六消息发送的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
可见，通过第一消息的消息头定义所述第一消息的类型，通过第一消息的消息内容携带用于说明业务需求的业务内容，使得处于应用平面的应用可以使用所述第一消息将所述业务需求中的目标对象以及在所述目标对象上实现所述业务需求的操作发向处于控制层面的控制器。而且，通过第二消息的消息头定义所述第二消息的类型，通过第二消息的消息内容携带用于说明业务需求的业务内容，当接收到从所述控制器发送的所述第二消息时，所述应用可以识别并获取所述第二消息的消息内容中携带的，用于实现所述业务内容的至少一个方案的方案信息，由此实现了应用平面和控制平面之间业务需求到控制需求转换。
图9为本发明实施例提供的一种消息处理装置的装置结构图，应用于SDN，所述消息处理装置900包括：
接收单元901，用于获取应用发送的第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
识别单元902，用于根据所述第一消息的消息头识别所述第一消息为请求 消息；
获取单元903，用于根据所述第一消息的消息内容，获取所述业务内容；
确定单元904，用于根据所述业务内容，确定实现所述业务内容的至少一个方案；
发送单元905，用于向所述应用发送第二消息，所述述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
可选的，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
可选的，
若所述确定单元根据所述业务内容不足以确定出实现所述业务内容的全部方案，所述确定单元还用于根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
可选的，
所述接收单元还用于获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文信息中包括针对所述业务内容的环境信息；
所述识别单元还用于根据所述第三消息的消息头识别所述第三消息为请求消息；
所述获取单元还用于获取所述第三消息的消息内容。
可选的，若所述第三消息的消息内容未包括所述业务内容，则所述第三 消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
所述接收单元还用于获取所述第一消息时，保存所述业务内容并记录所述对象标识；
所述接收单元获取所述第三消息时，还用于根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
所述确定单元还用于根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案；
或者，
若所述第三消息的消息内容还包括所述业务内容，所述确定单元还用于根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案。
可选的，
若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
所述发送单元还用于向所述应用发送第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括所述约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
可选的，
所述接收单元还用于获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文消息中包括针对所述业务内容的环境信息；
所述识别单元还用于根据所述第三消息的消息头识别所述第三消息为请求消息；
所述获取单元还用于获取所述第三消息的消息内容。
可选的，若所述第三消息的消息内容未包括所述业务内容，则所述第三 消息和所述第一消息均携带用于标识所述目标对象的对象标识，
所述接收单元还用于获取所述第一消息时，保存所述业务内容并记录所述对象标识；
所述接收单元获取所述第三消息时，还用于根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
或者，
若所述第三消息的消息内容还包括所述业务内容，若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。
可选的，
所述接收单元还用于获取所述应用发送的第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
所述识别单元还用于根据所述第六消息的消息头识别所述第六消息为选择消息；
所述确定单元还用于根据所述第六消息的消息内容，确定所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现；
所述发送单元还用于向所述应用发送针对所述第六消息的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
可见，通过第一消息的消息头定义所述第一消息的类型，通过第一消息的消息内容携带用于说明业务需求的业务内容，使得处于应用平面的应用可以使用所述第一消息将所述业务需求中的目标对象以及在所述目标对象上实现所述业务需求的操作发向处于控制层面的控制器。而且，通过第二消息的 消息头定义所述第二消息的类型，通过第二消息的消息内容携带用于说明业务需求的业务内容，当接收到从所述控制器发送的所述第二消息时，所述应用可以识别并获取所述第二消息的消息内容中携带的，用于实现所述业务内容的至少一个方案的方案信息，由此实现了应用平面和控制平面之间业务需求到控制需求转换。
图10为本发明实施例提供的一种消息处理系统的系统结构图，应用于SDN中，所述消息处理系统1000包括应用和控制器：
所述应用1001，用于向所述控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；根据所述第二消息的消息头识别所述第二消息为响应消息；根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
所述控制器1002，用于获取所述应用发送的所述第一消息；根据所述第一消息的消息头识别所述第一消息为请求消息；根据所述第一消息的消息内容，获取所述业务内容；根据所述业务内容，确定实现所述业务内容的至少一个方案；向所述应用发送所述第二消息。
图11为本发明实施例提供的一种应用设备的硬件结构图，所述应用设备1100位于SDN中，所述应用设备中部署了应用，所述应用设备通过执行所部署的应用执行如下操作，所述应用设备1100包括存储器1101、接收器1102和发送器1103，以及分别与所述存储器1101、所述接收器1102和所述发送器1103连接的处理器1104，所述存储器1101用于存储一组程序指令，所述处理器1104用于调用所述存储器1101存储的程序指令执行如下操作：
触发所述发送器1103向控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请 求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
触发所述接收器1102接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；
根据所述第二消息的消息头识别所述第二消息为响应消息；
根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
可选地，所述处理器1104可以为中央处理器(Central Processing Unit，CPU)，所述存储器1101可以为随机存取存储器(Random Access Memory，RAM)类型的内部存储器，所述接收器1102和所述发送器1103可以包含普通物理接口，所述物理接口可以为以太(Ethernet)接口或异步传输模式(Asynchronous Transfer Mode，ATM)接口。所述处理器1104、发送器1103、接收器1102和存储器1101可以集成为一个或多个独立的电路或硬件，如：专用集成电路(Application Specific Integrated Circuit，ASIC)。
图12为本发明实施例提供的一种控制器的硬件结构图，所述控制器1200位于SDN中，所述第一路由器1200包括存储器1201、接收器1202和发送器1203，以及分别与所述存储器1201、所述接收器1202和所述发送器1203连接的处理器1204，所述存储器1201用于存储一组程序指令，所述处理器1204用于调用所述存储器1201存储的程序指令执行如下操作：
触发所述接收器1202获取应用发送的第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
根据所述第一消息的消息头识别所述第一消息为请求消息；
根据所述第一消息的消息内容，获取所述业务内容；
根据所述业务内容，确定实现所述业务内容的至少一个方案；
触发所述发送器1203向所述应用发送第二消息，所述述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
可选地，所述处理器1204可以为CPU，所述存储器1201可以为RAM类型的内部存储器，所述接收器1202和所述发送器1203可以包含普通物理接口，所述物理接口可以为Ethernet接口或ATM接口。所述处理器1204、发送器1203、接收器1202和存储器1201可以集成为一个或多个独立的电路或硬件，如：ASIC。
其中，上述通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器，解码器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。
本发明实施例中提到的第一消息和第一补充内容的“第一”只是用来做名字标识，并不代表顺序上的第一。该规则同样适用于“第二”、“第三”等。
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质可以是下述介质中的至少一种：只读存储器(英文：read-only memory，缩写：ROM)、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实 施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims (33)

  1. 一种消息处理方法，其特征在于，应用于软件定义网络SDN中，所述方法包括：
    应用向控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
    所述应用接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；
    所述应用根据所述第二消息的消息头识别所述第二消息为响应消息；
    所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
  2. 根据权利要求1所述的方法，其特征在于，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
  3. 根据权利要求1或2所述的方法，其特征在于，所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息；
    所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息，包括：
    所述应用根据所述第二消息的消息内容，获取所述第二消息包括的约束维度项和/或上下文需求项，以及获取所述第二消息包括的至少一个方案的方案信息。
  4. 根据权利要求3所述的方法，其特征在于，所述方法还包括：
    所述应用根据所述第二消息包括的约束维度项和/或上下文需求项确定第一补充内容；
    所述应用向所述控制器发送第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括所述第一补充内容，其中，若所述第二消息的消息内容包括约束维度项，所述第一补充内容包括所述第二消息的约束维度项中所要求的约束条件；若所述第二消息的消息内容包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
  5. 根据权利要求4所述的方法，其特征在于，
    若所述第三消息的消息内容中未包括所述业务内容，所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识；或者，
    所述第三消息的消息内容中包括所述业务内容和所述第一补充内容。
  6. 根据权利要求1至5任一项所述的方法，其特征在于，在所述应用向控制器发送第一消息之后，所述应用接收所述控制器发送的第二消息之前，还包括：
    所述应用接收所述控制器发送的第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括约束维度项和/或上下文需求项；
    所述应用根据所述第四消息的消息头识别所述第四消息为响应消息；
    所述应用根据所述第四消息的消息内容，获取所述第四消息包括的约束维度项和/或上下文需求项；
    所述应用根据所述第四消息包括的约束维度项和/或上下文需求项确定第二补充内容；
    所述应用向所述控制器发送第五消息，所述第五消息包括消息头和消息内容，所述第五消息的消息头用于标识所述第五消息的消息类型为请求消息，所述第五消息的消息内容包括所述第二补充内容，其中，若所述第四消息的消息内容包括约束维度项，所述第二补充内容包括所述第四消息的约束维度项中所要求的约束条件；若所述第四消息的消息内容包括上下文需求项，所述第二补充内容包括所述第四消息的上下文需求项中所要求的环境信息。
  7. 根据权利要求1至5任一项所述的方法，其特征在于，在所述应用根据所述第二消息的消息内容，获取所述至少一个方案的方案信息之后，还包 括：
    所述应用向所述控制器发送第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
    所述应用接收所述控制器针对所述第六消息发送的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
  8. 一种消息处理装置，其特征在于，应用于软件定义网络SDN中，所述装置包括：
    发送单元，用于向控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
    接收单元，用于接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；
    识别单元，用于根据所述第二消息的消息头识别所述第二消息为响应消息；
    获取单元，用于根据所述第二消息的消息内容，获取所述至少一个方案的方案信息。
  9. 根据权利要求8所述的装置，其特征在于，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
  10. 根据权利要求8或9所述的方法，其特征在于，所述第二消息的消 息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息；
    所述获取单元还用于根据所述第二消息的消息内容，获取所述第二消息包括的约束维度项和/或上下文需求项，以及获取所述第二消息包括的至少一个方案的方案信息。
  11. 根据权利要求10所述的装置，其特征在于，所述装置还包括：
    确定单元，用于根据所述第二消息包括的约束维度项和/或上下文需求项确定第一补充内容；
    所述发送单元还用于向所述控制器发送第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括所述第一补充内容，其中，若所述第二消息的消息内容包括约束维度项，所述第一补充内容包括所述第二消息的约束维度项中所要求的约束条件；若所述第二消息的消息内容包括上下文需求项，所述第一补充内容包括所述第二消息的上下文需求项中所要求的环境信息。
  12. 根据权利要求11所述的装置，其特征在于，
    若所述第三消息的消息内容中未包括所述业务内容，所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识；或者，
    所述第三消息的消息内容中包括所述业务内容和所述第一补充内容。
  13. 根据权利要求8至12任一项所述的装置，其特征在于，
    所述接收单元还用于接收所述控制器发送的第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括约束维度项和/或上下文需求项；
    所述识别单元还用于根据所述第四消息的消息头识别所述第四消息为响应消息；
    所述获取单元还用于根据所述第四消息的消息内容，获取所述第四消息包括的约束维度项和/或上下文需求项；
    所述确定单元还用于根据所述第四消息包括的约束维度项和/或上下文需求项确定第二补充内容；
    所述发送单元还用于向所述控制器发送第五消息，所述第五消息包括消息头和消息内容，所述第五消息的消息头用于标识所述第五消息的消息类型为请求消息，所述第五消息的消息内容包括所述第二补充内容，其中，若所述第四消息的消息内容包括约束维度项，所述第二补充内容包括所述第四消息的约束维度项中所要求的约束条件；若所述第四消息的消息内容包括上下文需求项，所述第二补充内容包括所述第四消息的上下文需求项中所要求的环境信息。
  14. 根据权利要求8至13任一项所述的装置，其特征在于，
    所述发送单元还用于向所述控制器发送第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
    所述接收单元还用于接收所述控制器针对所述第六消息发送的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
  15. 一种消息处理方法，其特征在于，应用于软件定义网络SDN中，所述方法包括：
    控制器获取应用发送的第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
    所述控制器根据所述第一消息的消息头识别所述第一消息为请求消息；
    所述控制器根据所述第一消息的消息内容，获取所述业务内容；
    所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案；
    所述控制器向所述应用发送第二消息，所述述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
  16. 根据权利要求15所述的方法，其特征在于，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
  17. 根据权利要求15或16所述的方法，其特征在于，
    若所述控制器根据所述业务内容不足以确定出实现所述业务内容的全部方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
    所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
  18. 根据权利要求17所述的方法，其特征在于，在所述控制器获取应用发送的第一消息之后，所述控制器向所述应用发送第二消息之前，还包括：
    所述控制器获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文信息中包括针对所述业务内容的环境信息；
    所述控制器根据所述第三消息的消息头识别所述第三消息为请求消息；
    所述控制器获取所述第三消息的消息内容。
  19. 根据权利要求18所述的方法，其特征在于，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
    所述控制器获取所述第一消息时，保存所述业务内容并记录所述对象标识；
    所述控制器获取所述第三消息时，所述控制器根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
    所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案，包括：
    所述控制器根据所述业务内容和所述补充内容，确定实现所述业务内容 的至少一个方案；
    或者，
    若所述第三消息的消息内容还包括所述业务内容，所述控制器根据所述业务内容，确定实现所述业务内容的至少一个方案，包括：
    所述控制器根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案。
  20. 根据权利要求15或16所述的方法，其特征在于，
    若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
    所述控制器向所述应用发送第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括所述约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
  21. 根据权利要求20所述的方法，其特征在于，在所述控制器获取应用发送的第一消息之后，所述控制器向所述应用发送第四消息之前，还包括：
    所述控制器获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息，所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文消息中包括针对所述业务内容的环境信息；
    所述控制器根据所述第三消息的消息头识别所述第三消息为请求消息；
    所述控制器获取所述第三消息的消息内容。
  22. 根据权利要求21所述的方法，其特征在于，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
    所述控制器获取所述第一消息时，保存所述业务内容并记录所述对象标识；
    所述控制器获取所述第三消息时，所述控制器根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
    若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息，包括：
    若所述控制器根据所述补充内容和所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
    或者，
    若所述第三消息的消息内容还包括所述业务内容，若所述控制器根据所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息，包括：
    若所述控制器根据所述补充内容和所述业务内容无法确定出实现所述业务内容的方案，所述控制器根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。
  23. 根据权利要求15至22任一项所述的方法，其特征在于，在所述控制器向所述应用发送第二消息之后，所述方法还包括：
    所述控制器获取所述应用发送的第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
    所述控制器根据所述第六消息的消息头识别所述第六消息为选择消息；
    所述控制器根据所述第六消息的消息内容，确定所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现；
    所述控制器向所述应用发送针对所述第六消息的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
  24. 一种消息处理装置，其特征在于，应用于软件定义网络SDN中，所述装置包括：
    接收单元，用于获取应用发送的第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；
    识别单元，用于根据所述第一消息的消息头识别所述第一消息为请求消息；
    获取单元，用于根据所述第一消息的消息内容，获取所述业务内容；
    确定单元，用于根据所述业务内容，确定实现所述业务内容的至少一个方案；
    发送单元，用于向所述应用发送第二消息，所述述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括所述至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识。
  25. 根据权利要求24所述的装置，其特征在于，所述业务内容还包括约束信息和/或上下文信息，所述业务内容的约束信息包括用于标识对所述业务内容的约束条件，所述业务内容的上下文信息包括用于标识所述业务内容的环境信息，所述环境信息包括应用环境参数、网络环境参数和应用场景来源中的任意一项或多项的组合。
  26. 根据权利要求24或25所述的装置，其特征在于，
    若所述确定单元根据所述业务内容不足以确定出实现所述业务内容的全部方案，所述确定单元还用于根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
    所述第二消息的消息内容还包括约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
  27. 根据权利要求26所述的装置，其特征在于，
    所述接收单元还用于获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息， 所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文信息中包括针对所述业务内容的环境信息；
    所述识别单元还用于根据所述第三消息的消息头识别所述第三消息为请求消息；
    所述获取单元还用于获取所述第三消息的消息内容。
  28. 根据权利要求27所述的装置，其特征在于，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，所述方法还包括：
    所述接收单元还用于获取所述第一消息时，保存所述业务内容并记录所述对象标识；
    所述接收单元获取所述第三消息时，还用于根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
    所述确定单元还用于根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案；
    或者，
    若所述第三消息的消息内容还包括所述业务内容，所述确定单元还用于根据所述业务内容和所述补充内容，确定实现所述业务内容的至少一个方案。
  29. 根据权利要求24或25所述的装置，其特征在于，
    若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
    所述发送单元还用于向所述应用发送第四消息，所述第四消息包括消息头和消息内容，所述第四消息的消息头用于标识所述第四消息的消息类型为响应消息，所述第四消息的消息内容包括所述约束维度项和/或上下文需求项，所述约束维度项用于请求所述应用回复针对所述业务内容的约束条件，所述上下文需求项用于请求所述应用回复针对所述业务内容的环境信息。
  30. 根据权利要求29所述的装置，其特征在于，
    所述接收单元还用于获取第三消息，所述第三消息包括消息头和消息内容，所述第三消息的消息头用于标识所述第三消息的消息类型为请求消息， 所述第三消息的消息内容包括补充内容，所述补充内容包括约束信息和/或上下文信息，所述补充内容的约束信息中包括针对所述业务内容的约束条件，所述补充内容的上下文消息中包括针对所述业务内容的环境信息；
    所述识别单元还用于根据所述第三消息的消息头识别所述第三消息为请求消息；
    所述获取单元还用于获取所述第三消息的消息内容。
  31. 根据权利要求30所述的装置，其特征在于，若所述第三消息的消息内容未包括所述业务内容，则所述第三消息和所述第一消息均携带用于标识所述目标对象的对象标识，
    所述接收单元还用于获取所述第一消息时，保存所述业务内容并记录所述对象标识；
    所述接收单元获取所述第三消息时，还用于根据所述第三消息携带的所述对象标识提取出保存的所述业务内容；
    若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息；
    或者，
    若所述第三消息的消息内容还包括所述业务内容，若所述确定单元根据所述业务内容无法确定出实现所述业务内容的方案，所述确定单元还用于根据所述补充内容和所述业务内容确定出请求所述应用回复针对所述业务内容的约束条件和/或请求所述应用回复针对所述业务内容的环境信息。
  32. 根据权利要求24至31任一项所述的装置，其特征在于，
    所述接收单元还用于获取所述应用发送的第六消息，所述第六消息包括消息头和消息内容，所述第六消息的消息头用于标识所述第六消息的消息类型为选择消息，所述第六消息的消息内容包括所述应用从所述至少一个方案的方案信息中选择的一个目标方案或者所述目标方案的方案标识；
    所述识别单元还用于根据所述第六消息的消息头识别所述第六消息为选择消息；
    所述确定单元还用于根据所述第六消息的消息内容，确定所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现；
    所述发送单元还用于向所述应用发送针对所述第六消息的第七消息，所述第七消息包括消息头和消息内容，所述第七消息的消息头用于标识所述第七消息的消息类型为确认消息，所述第七消息的消息内容包括所述目标方案的实现结果，所述实现结果用来标识所述目标方案是否实现。
  33. 一种消息处理系统，其特征在于，应用于软件定义网络SDN中，所述系统包括应用和控制器：
    所述应用，用于向所述控制器发送第一消息，所述第一消息包括消息头和消息内容，所述第一消息的消息头用于标识所述第一消息的消息类型为请求消息，所述第一消息的消息内容包括用于说明业务需求的业务内容，所述业务内容包括目标信息和操作信息，所述目标信息用于标识目标对象，所述操作信息用于标识在所述目标对象上实现所述业务需求的操作；接收所述控制器发送的第二消息，所述第二消息包括消息头和消息内容，所述第二消息的消息头用于标识所述第二消息的消息类型为响应消息，所述第二消息的消息内容包括用于实现所述业务内容的至少一个方案的方案信息，所述方案信息包括所述至少一个方案的方案描述，或者包括所述至少一个方案对应的方案标识；根据所述第二消息的消息头识别所述第二消息为响应消息；根据所述第二消息的消息内容，获取所述至少一个方案的方案信息；
    所述控制器，用于获取所述应用发送的所述第一消息；根据所述第一消息的消息头识别所述第一消息为请求消息；根据所述第一消息的消息内容，获取所述业务内容；根据所述业务内容，确定实现所述业务内容的至少一个方案；向所述应用发送所述第二消息。
PCT/CN2016/110123 2015-12-16 2016-12-15 一种消息处理方法、装置和系统 WO2017101815A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP16874872.1A EP3379771B1 (en) 2015-12-16 2016-12-15 Message processing method, device and system
US16/010,041 US10592316B2 (en) 2015-12-16 2018-06-15 Message processing method, apparatus, and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510947136.8 2015-12-16
CN201510947136.8A CN106888152B (zh) 2015-12-16 2015-12-16 一种消息处理方法、装置和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/010,041 Continuation US10592316B2 (en) 2015-12-16 2018-06-15 Message processing method, apparatus, and system

Publications (1)

Publication Number Publication Date
WO2017101815A1 true WO2017101815A1 (zh) 2017-06-22

Family

ID=59055831

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/110123 WO2017101815A1 (zh) 2015-12-16 2016-12-15 一种消息处理方法、装置和系统

Country Status (4)

Country Link
US (1) US10592316B2 (zh)
EP (1) EP3379771B1 (zh)
CN (1) CN106888152B (zh)
WO (1) WO2017101815A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10469427B2 (en) * 2016-11-08 2019-11-05 Facebook, Inc. Methods and systems for transmitting a video as an asynchronous artifact
CN109586982B (zh) * 2019-01-04 2020-08-21 北京邮电大学 一种功能备份方法及装置
CN111490893B (zh) * 2019-01-29 2022-02-22 华为技术有限公司 一种网络转发模型的建立方法、装置及系统
KR20220130664A (ko) * 2020-01-17 2022-09-27 인텔 코포레이션 무선 인터페이스 엔진들 및 무선 가상 머신들을 포함하는 재구성가능한 무선 시스템들
US11455470B2 (en) * 2020-02-24 2022-09-27 Raul ABREU Distributed reactive streaming microservices architecture with self-management and autonomous routing
US20220239591A1 (en) * 2021-01-27 2022-07-28 Cisco Technology, Inc. Coordination of sdn underlay and overlay for deterministic traffic

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103841044A (zh) * 2014-02-27 2014-06-04 中国科学技术大学苏州研究院 基于软件定义网络下面向不同流的带宽控制方法
WO2014169289A1 (en) * 2013-04-12 2014-10-16 Extreme Networks Bandwidth on demand in sdn networks
CN104253820A (zh) * 2014-10-16 2014-12-31 北京邮电大学 软件定义网安全控制系统和控制方法
CN104518993A (zh) * 2014-12-29 2015-04-15 华为技术有限公司 云化网络通信路径的分配方法、装置及系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008048304A2 (en) * 2005-12-01 2008-04-24 Firestar Software, Inc. System and method for exchanging information among exchange applications
WO2007124015A2 (en) * 2006-04-20 2007-11-01 Tekelec Methods, systems, and computer program products for transferring a message service payload between messaging entities
CN101431460B (zh) * 2008-11-28 2011-07-13 中兴通讯股份有限公司 Web应用与外部设备网络互连的实现方法和系统
US9813494B2 (en) * 2012-05-11 2017-11-07 Interdigital Patent Holdings, Inc. Context-aware peer-to-peer communication
CN102739549B (zh) * 2012-07-13 2015-10-21 华为技术有限公司 接收报文的方法、发送报文的方法及装置
US9100285B1 (en) * 2012-12-18 2015-08-04 Juniper Networks, Inc. Dynamic control channel establishment for software-defined networks having centralized control
US9912521B2 (en) * 2013-03-13 2018-03-06 Dell Products L.P. Systems and methods for managing connections in an orchestrated network
US8954349B2 (en) * 2013-03-15 2015-02-10 Parcelpoke Limited Ordering system and ancillary service control through text messaging
CN104518902B (zh) * 2013-09-30 2017-11-24 新华三技术有限公司 一种应用软件定义网络优化二层网络流量的方法和设备
CN103618679A (zh) * 2013-11-25 2014-03-05 上海华为技术有限公司 服务质量控制方法、装置和系统
CN104468231A (zh) * 2014-12-23 2015-03-25 上海斐讯数据通信技术有限公司 Sdn交换机和控制器动态注册方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014169289A1 (en) * 2013-04-12 2014-10-16 Extreme Networks Bandwidth on demand in sdn networks
CN103841044A (zh) * 2014-02-27 2014-06-04 中国科学技术大学苏州研究院 基于软件定义网络下面向不同流的带宽控制方法
CN104253820A (zh) * 2014-10-16 2014-12-31 北京邮电大学 软件定义网安全控制系统和控制方法
CN104518993A (zh) * 2014-12-29 2015-04-15 华为技术有限公司 云化网络通信路径的分配方法、装置及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3379771A4 *

Also Published As

Publication number Publication date
EP3379771A4 (en) 2018-09-26
EP3379771A1 (en) 2018-09-26
CN106888152A (zh) 2017-06-23
US20180307549A1 (en) 2018-10-25
EP3379771B1 (en) 2019-10-30
CN106888152B (zh) 2019-11-12
US10592316B2 (en) 2020-03-17

Similar Documents

Publication Publication Date Title
WO2017101815A1 (zh) 一种消息处理方法、装置和系统
EP2989747B1 (en) App store portal providing point-and-click deployment of third-party virtualized network functions
JP5943331B2 (ja) サービスプロセス制御方法およびネットワークデバイス
CN105051687B (zh) 应用部署方法和设备
US8599716B2 (en) Method and system to configure quality of service in a network
KR20170105582A (ko) Nfv 및 sdn과 연동하기 위한 sdt를 위한 시스템들 및 방법들
CN114980250B (zh) 基于SRv6的算力路由系统及方法
US20160255048A1 (en) Communications over multiple protocol interfaces in a computing environment
US10165092B2 (en) Using a network service header to manage a network-as-a-system
WO2015196923A1 (zh) 一种发送信息的方法和网络装置
CN110036608A (zh) 用于Diameter消息的优先级路由的方法、系统和计算机可读介质
CN113556359A (zh) 一种通讯协议转换方法、设备、系统及网关设备
CN103384220B (zh) 一种流量工程标签交换路径的建立方法、设备和系统
CN112564994A (zh) 流量监测方法、装置、云服务器及存储介质
CN112491576A (zh) 网络配置的发送方法及装置、存储介质、电子装置
WO2021148843A1 (en) Deployment of a virtualized service on a cloud infrastructure based on interoperability requirements between service functions
EP3125634A1 (en) Message transmission method and node device based on network selection and temporal arrangement
CN115499386A (zh) 一种数据转发方法、vpp网元设备和可读存储介质
CN110063048A (zh) 用于对由一组用户实现的计算机应用进行优先化的系统
CN104702505A (zh) 一种报文传输方法和节点
CN115486041A (zh) 跨不同网络进行通信的数据报文格式
CN1836421A (zh) 对分组通信网络中的分组内容的描述
CN109150726A (zh) 一种报文处理方法和装置
WO2023246118A1 (zh) 报文的转发方法、装置、存储介质及电子装置
WO2024007640A1 (zh) 数据传输方法、数据处理方法、电子设备、存储介质

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016874872

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016874872

Country of ref document: EP

Effective date: 20180620