WO2018218472A1 - 一种软件可定义的网络业务配置方法 - Google Patents

一种软件可定义的网络业务配置方法 Download PDF

Info

Publication number
WO2018218472A1
WO2018218472A1 PCT/CN2017/086510 CN2017086510W WO2018218472A1 WO 2018218472 A1 WO2018218472 A1 WO 2018218472A1 CN 2017086510 W CN2017086510 W CN 2017086510W WO 2018218472 A1 WO2018218472 A1 WO 2018218472A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
msg
field
physical switch
control
Prior art date
Application number
PCT/CN2017/086510
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 US16/070,293 priority Critical patent/US11310128B2/en
Priority to PCT/CN2017/086510 priority patent/WO2018218472A1/zh
Publication of WO2018218472A1 publication Critical patent/WO2018218472A1/zh

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/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • 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/08—Configuration management of networks or network elements
    • H04L41/0894—Policy-based network configuration management
    • 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/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • 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
    • 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/5045—Making service definitions prior to deployment
    • 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
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/55—Prevention, detection or correction of errors
    • H04L49/555—Error detection

Definitions

  • the present invention belongs to the field of network communication technologies, and in particular, to a software definable network service configuration method.
  • Computer networks typically consist of a large number of routers, switches, and network middleware with varying capabilities.
  • the administrator formulates various policies according to the services (such as video, language, web, etc.) carried by the current network. Due to the lack of available tools, the administrator needs to manually convert these advanced policies into network devices. Identifying low-level configuration commands, this work is challenging and error-prone.
  • SDN Software Defined Network
  • the current Internet is “rigid”.
  • the root cause of this “stiffness” of the Internet lies in the excessive coupling between the network control plane and the data plane.
  • Each network device is independent in decision-making, and lacks global planning. In this network environment, deploying a new service is undoubtedly not an easy task, because the administrator needs to go deep into each device in the underlying network. Configuration.
  • a large number of network function boxes (such as firewalls, intrusion detection systems, and address translators) can be placed on top of the basic interconnections at the bottom of the network. For managers, the management cost is too high, it is the last choice.
  • the fundamental goal of separation of forwarding and control is to achieve simple programming of the network data path.
  • Centralized control across the entire network is achieved by separating the control of the network device from the physical forwarding.
  • the so-called centralized control does not mean that there is only one physical controller in the network, but a logical centralized control. Obviously, this kind of control is beneficial for deploying new network protocols and services.
  • the global network view facilitates network management and integration of various network function systems.
  • the object of the present invention is to overcome the deficiencies of the prior art and propose a software definable network service configuration method.
  • Step (1) The network is composed of an application layer, a control layer, and a data layer, where the entity of the control layer is a control component, and the entity of the data layer is a physical switch;
  • Step (2) the user describes the required service through the application layer, constructs a service request, and transfers the control to the control device through the web service interface;
  • Step (3) The control device sends a control message (Msg-1) to all physical switches in the data layer in a broadcast manner, and queries the capabilities of each physical switch;
  • the control message includes a message type (MsgType), a service ID (SrvID), a service specification (SrvDesc), a receiving node set (RecvSets), a sending node set (TransSets), a service support (SrvSupport), and a service configuration result (ConfResult). ), the service configuration cost (ConfCost) 8 main fields; wherein the MsgType value is 0 for the query, 1 for the response, 2 for the service installation, and 3 for the service offload;
  • the MsgType in Msg-1 is set to 0, the initial value of RecvSets is set to null, and the initial values of the SrvSupport, ConfResult, and ConfCost fields are set to -1;
  • Step (4) After receiving the Msg-1, the physical switch first checks whether it supports the SrvID. If the service is not supported, set the value of the SrvSupport field to 1. If it can be supported, the physical switch checks whether it meets the service specification according to the SrvDesc field in Msg-1. If it cannot be satisfied, set the value of the SrvSupport field to 2. If it can be satisfied, set the value of SrvSupport field to 0;
  • Step (5) The physical switch writes the field value set in step (4) to the control message (Msg-2), MsgType is set to 1, other field values are the same as Msg-1, and Msg-2 is sent back to the unicast mode.
  • Msg-2 the control message
  • MsgType is set to 1
  • other field values are the same as Msg-1
  • Msg-2 is sent back to the unicast mode.
  • Step (6) After receiving the Msg-2, the control device selects a physical switch capable of supporting the service corresponding to the SrvID according to the queried physical switch capability, and constructs a virtual network (vNet) for the service corresponding to the SrvID;
  • vNet virtual network
  • Step (7) The control component executes a customized path planning algorithm in the virtual network vNet to obtain an optimal service deployment path (Path), and constructs a service installation node set (SrvInstallSets), and each element in the SrvInstallSets corresponds to a physical switch on the Path;
  • Step (8) The control device sends a control message (Msg-3) to each physical switch on the path in a multicast manner, and starts the installation process of the service corresponding to the SrvID;
  • the MsgType in the Msg-3 is set to 2, the RecvSets field is set to SrvInstallSets, the SrvSupport field is set to 1, the ConfResult field is set to -1, and the ConfCost field is set to -1;
  • Step (9) After each physical switch receives the control message Msg-3, the following steps are performed:
  • the physical switch determines whether it belongs to the RecvSets field in Msg-3. If it does not belong, set the value of the ConfResult field to 2, and go to step 9-3; if it belongs, go directly to step 9-2;
  • the physical switch performs the service installation process. If the installation is successful, set the value of the ConfCost field to the current resource cost, and set the value of the ConfResult field to 0. If the installation fails, set the value of the ConfResult field to 1.
  • Step (10) The control traverses the return of each physical switch in the node set SrvInstallSets Control message Msg-4, if all the control messages Msg-4 have a ConfResult field of 0, it indicates that the service configuration is successful, and the virtual network vNet information is updated according to the ConfCost field; if all the control messages Msg-4 have the ConfResult field If the value is not all 0, the service configuration is unsuccessful. Perform the following steps:
  • Msg-5 10-1 control structure construction control message (Msg-5), MsgType is set to 3, other fields are the same as Msg-3, and Msg-5 is multicast to each physical switch on the path;
  • the control device finds the physical switch corresponding to the control message Msg-4 whose ConfResult field is 1, and identifies it as unavailable in the vNet, and proceeds to step (7).
  • the beneficial effects of the present invention are as follows:
  • the service deployment in the traditional network is very complicated, and the operator needs to plan the service path in advance, and then manually configure the policy for each node on the service path.
  • a software-definable network service configuration method disclosed by the present invention is different from a traditional network.
  • the control layer has a global network resource view, and it is easier to plan a service path for a service request.
  • the control layer passes the southbound interface. Centralized management of physical switch nodes in the data layer makes it easier to automate the implementation of policy configurations in physical switch nodes.
  • a software definable network service configuration method includes the following steps:
  • Step (1) The network is composed of an application layer, a control layer, and a data layer, where the entity of the control layer is a control component, and the entity of the data layer is a physical switch;
  • Step (2) the user describes the required service through the application layer, constructs a service request, and transfers the control to the control device through the web service interface;
  • Step (3) The control device sends a control message (Msg-1) to all physical switches in the data layer in a broadcast manner, and queries the capabilities of each physical switch;
  • the control message includes a message type (MsgType), a service ID (SrvID), a service specification (SrvDesc), a receiving node set (RecvSets), a sending node set (TransSets), a service support (SrvSupport), and a service configuration result (ConfResult). ), the service configuration cost (ConfCost) 8 main fields; wherein the MsgType value is 0 for the query, 1 for the response, 2 for the service installation, and 3 for the service offload;
  • the MsgType in Msg-1 is set to 0, the initial value of RecvSets is set to null, and the initial values of the SrvSupport, ConfResult, and ConfCost fields are set to -1;
  • Step (4) After receiving the Msg-1, the physical switch first checks whether it supports the service corresponding to the SrvID. If it cannot support, set the value of the SrvSupport field to 1. If it can be supported, the physical switch according to the SrvDesc in the Msg-1. The field checks whether it meets the service specification requirements. If it is not satisfied, set the value of the SrvSupport field to 2. If it is satisfied, set the value of the SrvSupport field to 0.
  • Step (5) The physical switch writes the field value set in step (4) to the control message (Msg-2), MsgType is set to 1, other field values are the same as Msg-1, and Msg-2 is sent back to the unicast mode.
  • Msg-2 the control message
  • MsgType is set to 1
  • other field values are the same as Msg-1
  • Msg-2 is sent back to the unicast mode.
  • Step (6) After receiving the Msg-2, the control device selects a physical switch capable of supporting the service corresponding to the SrvID according to the queried physical switch capability, and constructs a virtual network (vNet) for the service corresponding to the SrvID;
  • vNet virtual network
  • Step (7) The control component executes a customized path planning algorithm in the virtual network vNet to obtain an optimal service deployment path (Path), and constructs a service installation node set (SrvInstallSets), and each element in the SrvInstallSets corresponds to a physical switch on the Path;
  • Step (8) The control device sends a control message (Msg-3) to each physical switch on the path in a multicast manner, and starts the installation process of the service corresponding to the SrvID;
  • the MsgType in the Msg-3 is set to 2, the RecvSets field is set to SrvInstallSets, the SrvSupport field is set to 1, the ConfResult field is set to -1, and the ConfCost field is set to -1;
  • Step (9) After each physical switch receives the control message Msg-3, the following steps are performed:
  • the physical switch determines whether it belongs to the RecvSets field in Msg-3, if it is not Then set the value of the ConfResult field to 2, go to step 9-3; if it belongs, go directly to step 9-2;
  • the physical switch performs the service installation process. If the installation is successful, set the value of the ConfCost field to the current resource cost, and set the value of the ConfResult field to 0. If the installation fails, set the value of the ConfResult field to 1.
  • Step (10) The control device traverses the control message Msg-4 returned by each physical switch in the node set SrvInstallSets. If the ConfResult field of all control messages Msg-4 is 0, the service configuration is successful, and according to ConfCost The field updates the virtual network vNet information; if the ConfResult fields of all the control messages Msg-4 are not all 0, it indicates that the service configuration is unsuccessful, and the following steps are performed:
  • Msg-5 10-1 control structure construction control message (Msg-5), MsgType is set to 3, other fields are the same as Msg-3, and Msg-5 is multicast to each physical switch on the path;
  • the control device finds the physical switch corresponding to the control message Msg-4 whose ConfResult field is 1, and identifies it as unavailable in the vNet, and proceeds to step (7).
  • the topology and node capabilities in the network change dynamically.
  • the control actively queries the capabilities and links of the physical nodes in the infrastructure layer.
  • the physical node to the control unit feeds back its own capability information and connection status to the control unit.
  • the control unit plans the service path according to the feedback information of the infrastructure layer, generates the configuration commands required for each physical node, and then issues configuration commands for each physical node.
  • the physical node executes the configuration command and feeds back the operating status to the control.
  • the period control builds and maintains a virtual network for each type of network service that contains the service path required for the service request.
  • the service configuration method of the present invention can be implemented as follows, as shown in FIG. 1:
  • the user can describe the service to be deployed through a graphical human-computer interaction interface, describe the result to be quantized into specific service request parameters, and construct an HTTP message according to the access control layer web service interface, the service interface form. It can be a RESTful API like a web service.
  • the control device starts the capability query process of the physical switch of the data layer, and needs to construct a control message for querying the capability of each physical switch. Since the support capability of each physical switch for the new service is unknown, the broadcast method will be adopted. This control message is sent to each physical switch.
  • the control message includes a message type (MsgType), a service ID (SrvID), a service specification (SrvDesc), a reception node set (RecvSets), a transmission node set (TransSets), a service support (SrvSupport), a service configuration result (ConfResult),
  • the service configuration cost (ConfCost) has eight main fields. These fields are sufficient to describe a service and its installation process.
  • the initial value of RecvSets in the query message is set to null, and the initial values of the SrvSupport, ConfResult, and ConfCost fields are set to -1.
  • the MsgType value is 0 for the query, 1 for the response, 2 for the service installation, and 3 for the service offload.
  • Each physical switch will receive a query message from the control device, first determine whether it supports the service requested in the query message. If not, set SrvSupport to 1, indicating that the physical machine does not support the service; Then, it is judged whether the service specification requirement described by SrvDesc can be satisfied. If the setting SrvSupport field is 0, if the SrvSupport field is not satisfied, the physical switch can support the service but has insufficient capability. Each physical switch reconstructs a response message based on the result of its own inspection, and unicasts the control.
  • the control device updates the network resource view according to the queried physical node capability and the link information, selects a physical switch capable of supporting the requested service, constructs and maintains the virtual network, and executes a customized service path discovery algorithm in the virtual network (may be The shortest path first algorithm, which may also be a distance vector algorithm, etc., obtains an optimal service deployment path Path. Then, for each node on the proposed service deployment path, a service installation node set SrvInstallSets is constructed, and each element in the set corresponds to a physical switch on the path.
  • a service path discovery algorithm may be The shortest path first algorithm, which may also be a distance vector algorithm, etc.
  • the control component and each physical switch on the service path form a one-to-many correspondence.
  • the control sends a message to each physical switch that is suitable for the multicast mode.
  • the multicast source is the control component, and the group member is each physical switch on the service path.
  • the control device sends a control message to all physical switches in the data layer in multicast mode to instruct the physical switch to perform service installation.
  • the RecvSets field in the control message is set to the service installation node set, the SrvSupport field is set to 1, the ConfResult field is set to -1, and the ConfCost field is set to -1, because it is already possible to determine the physical switch that receives the control message. It is supported by the service, but the business configuration result and the service configuration cost are not known.
  • each physical switch that receives the multicast service installation message first confirms whether it belongs to the recipient of the installation message by judging the RecvSets field in the message. Generally speaking, this step will not have any problem, otherwise The physical switch does not receive multicast messages, but it does not rule out accidents. Therefore, if the physical switch finds that it is not the recipient of the installation message, it needs to notify the control device by unicast.
  • the service installation process is performed. The installation process is specifically configured to allocate computing resources and link resources for the service operation. After the installation is successful, the resource cost is written into the ConfCost in the control message. In the field, set the ConfResult field in the control message to 0. If the installation is unsuccessful, set the ConfResult field to 1, indicating that the installation failed. After that, a control message is constructed based on the installation result, and the control is notified in a unicast manner.
  • the control device checks the service installation node set SrvInstallSets to return an installation confirmation message. If the ConfResult in all the installation confirmation messages is 0, the service deployment path Path is completely successful; otherwise, the service deployment path Path is unsuccessful.
  • the time control device also needs to withdraw the original installation process, and the control component constructs a control message for performing the service unloading process and multicasting to each physical switch on the path to perform the service unloading process.
  • the control device identifies the unsuccessful physical switch as unavailable in the virtual network, re-provisions the service deployment path, and performs the installation process.
  • the network resource view is the underlying physical network in the data layer.
  • a subset which records the topology and resource distribution in the physical network in real time, where the resource distribution includes link bandwidth usage and node capacity usage.

Landscapes

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

Abstract

传统网络中的业务部署十分复杂，操作者需要事先规划服务路径，再针对服务路径上的每个节点手动配置策略。与传统网络不同的一种软件可定义的网络业务配置方法，一方面，控制层拥有全局的网络资源视图更容易针对服务请求规划服务路径，另一方面，控制层通过南向接口对数据层中的物理交换机节点进行集中管理，更易于物理交换机节点中策略配置的自动化实现。

Description

一种软件可定义的网络业务配置方法 技术领域
本发明属于网络通信技术领域，尤其涉及一种软件可定义的网络业务配置方法。
背景技术
计算机网络通常由大量的路由器、交换机和功能各异的网络中间件组成。为了有效管理网络，管理员根据当前网络所承载的业务(如：视频、语言、Web等)来制定各种策略，由于缺少可用工具，管理员需要将这些高级策略手动地转化为可被网络设备识别的低级配置命令，这项工作富有挑战性且极易出错。
对网络从业和研究人员而言，另一个几乎不能被克服的困难就是互联网的“僵化”问题。互联网的庞大部署规模，使得其成为社会中的关键基础设施，部署规模的不断扩张，随之而来的是互联网自身的演进和变革越来越困难，几十年前为解决基础互联问题而设计的互联网面对当前日新月异的各种显得越来越力不从心。
上述背景下，以IETF ForCES(Forwarding and Control Seperation，ForCES)为代表的可编程网络作为一种促进网络演化的手段被提出。而软件定义网络(Software Defined Network，SDN)是可编程网络的新形式，提供了一种新型的网络架构。SDN通过分离网络中的转发平面和控制平面，旨在简化网络管理、支持网络创新和演进，有望从根本上解决互联网的“僵化”问题。
如上所述，当前的互联网是“僵化的”，造成这种互联网“僵化”现象的根本原因在于网络控制平面和数据平面的过度耦合，每个网络设备对流经的数据都是独立决策，缺少全局规划。在这种网络环境下，部署一个新业务毫无疑问不是一件容易的事，因为管理者需要深入基础网络中的每个设备进行 配置。当然作为解决互联网“僵化”问题的一种备选方案，可以在网络底部的基础互联部分之上，大量放置各种网络功能盒(如：防火墙、入侵检测系统和地址转换器等)，但这样对于管理者来说管理成本实在太高，是当下不得已的选择。
转发与控制分离的根本目标就是实现网络数据路径的简单可编程。通过将网络设备的控制和物理转发之间分离，实现全网范围内的集中化控制，所谓集中化控制并不意味着网络中只有一个物理的控制器，而是一种逻辑上的集中控制。显然，这种控制方式对于部署新的网络协议和业务是有好处的，全局的网络视图有利于网络管理和各种网络功能系统的整合。
发明内容
本发明的目的是克服现有技术的不足，提出一种软件可定义的网络业务配置方法。
本发明解决其技术问题所采用的技术方案包含如下步骤：
步骤(1)网络由应用层、控制层和数据层组成，控制层的实体为控制件，数据层的实体为物理交换机；
步骤(2)用户通过应用层描述所需的业务，构造业务请求并通过web服务接口转给控制件；
步骤(3)控制件以广播方式向数据层中所有的物理交换机发送控制消息(Msg-1)，查询每个物理交换机的能力；
所述控制消息包含了消息类型(MsgType)、业务ID(SrvID)、业务规格说明(SrvDesc)、接收节点集(RecvSets)、发送节点集(TransSets)、业务支持(SrvSupport)、业务配置结果(ConfResult)、业务配置代价(ConfCost)8个主要字段；其中MsgType值为0表示查询、1表示应答、2表示业务安装、3表示业务卸载；
在查询每个物理交换机的能力时，Msg-1中MsgType设置为0，RecvSets初始值设置为空，SrvSupport、ConfResult和ConfCost字段初始值设置为-1；
步骤(4)物理交换机接收到Msg-1后，首先检查自己是否支持SrvID所对 应业务，如果不能够支持，设置SrvSupport字段的值为1；如果能够支持，物理交换机再根据Msg-1中的SrvDesc字段检查自己是否满足业务规格要求，如不能满足则设置SrvSupport字段的值为2，如能满足则设置SrvSupport字段的值为0；
步骤(5)物理交换机将步骤(4)设置后的字段值写入控制消息(Msg-2)，MsgType设置为1，其他字段值与Msg-1相同，Msg-2以单播方式发回给控制件；
步骤(6)控制件接收到Msg-2后，根据查询到的物理交换机能力情况，选取能够支持SrvID所对应业务的物理交换机，并针对SrvID所对应业务构造虚拟网(vNet)；
步骤(7)控制件在虚拟网vNet中执行自定义的路径规划算法得到最优业务部署路径(Path)，构建业务安装节点集(SrvInstallSets)，SrvInstallSets中的每一个元素对应Path上一个物理交换机；
步骤(8)控制件以组播方式向Path上每一个物理交换机发送控制消息(Msg-3)，开启SrvID所对应业务的安装过程；
所述Msg-3中的MsgType设置为2、RecvSets字段设置为SrvInstallSets、SrvSupport字段设置为1、ConfResult字段设置为-1、ConfCost字段设置为-1；
步骤(9)每一个物理交换机接收到控制消息Msg-3后，执行如下步骤：
9-1物理交换机判断自己是否属于Msg-3中的RecvSets字段，如果不属于则设置ConfResult字段的值为2，进入步骤9-3；如果属于，直接进入步骤9-2；
9-2物理交换机执行业务安装过程，如果安装成功则，设置ConfCost字段的值为当前的资源开销，同时设置ConfResult字段的值为0；如果安装失败则设置ConfResult字段的值为1；
9-3物理交换机将修改后的字段值写入控制消息(Msg-4)，MsgType设置为1，其它字段和Msg-3相同，Msg-4以单播方式发回给控制件；
步骤(10)控制件遍历节点集SrvInstallSets中每一个物理交换机所返回的 控制消息Msg-4，如果所有的控制消息Msg-4的ConfResult字段都为0，则表示此次业务配置成功，同时根据ConfCost字段更新虚拟网vNet信息；如果所有的控制消息Msg-4的ConfResult字段不全为0，则表示此次业务配置不成功，执行如下步骤：
10-1控制件构造控制消息(Msg-5)，MsgType设置为3，其它字段和Msg-3相同，Msg-5以组播方式发送至Path上每一个物理交换机；
10-2收到Msg-5的物理交换机，卸载SrvID所对应的业务；
控制件找出ConfResult字段为1的控制消息Msg-4所对应的物理交换机，在vNet中将其标识为不可用，进入步骤(7)。
本发明有益效果如下：传统网络中的业务部署十分复杂，操作者需要事先规划服务路径，再针对服务路径上的每个节点手动配置策略。本发明所公布的一种软件可定义的网络业务配置方法与传统网络不同，一方面，控制层拥有全局的网络资源视图更容易针对服务请求规划服务路径，另一方面，控制层通过南向接口对数据层中的物理交换机节点进行集中管理，更易于物理交换机节点中策略配置的自动化实现。
附图说明
图1业务部署流程。
具体实施方式
下面结合附图和具体实施例对本发明作进一步说明。
如图1所示，本发明提供的一种软件可定义的网络业务配置方法，包括以下步骤：
步骤(1)网络由应用层、控制层和数据层组成，控制层的实体为控制件，数据层的实体为物理交换机；
步骤(2)用户通过应用层描述所需的业务，构造业务请求并通过web服务接口转给控制件；
步骤(3)控制件以广播方式向数据层中所有的物理交换机发送控制消息(Msg-1)，查询每个物理交换机的能力；
所述控制消息包含了消息类型(MsgType)、业务ID(SrvID)、业务规格说明(SrvDesc)、接收节点集(RecvSets)、发送节点集(TransSets)、业务支持(SrvSupport)、业务配置结果(ConfResult)、业务配置代价(ConfCost)8个主要字段；其中MsgType值为0表示查询、1表示应答、2表示业务安装、3表示业务卸载；
在查询每个物理交换机的能力时，Msg-1中MsgType设置为0，RecvSets初始值设置为空，SrvSupport、ConfResult和ConfCost字段初始值设置为-1；
步骤(4)物理交换机接收到Msg-1后，首先检查自己是否支持SrvID所对应业务，如果不能够支持，设置SrvSupport字段的值为1；如果能够支持，物理交换机再根据Msg-1中的SrvDesc字段检查自己是否满足业务规格要求，如不能满足则设置SrvSupport字段的值为2，如能满足则设置SrvSupport字段的值为0；
步骤(5)物理交换机将步骤(4)设置后的字段值写入控制消息(Msg-2)，MsgType设置为1，其他字段值与Msg-1相同，Msg-2以单播方式发回给控制件；
步骤(6)控制件接收到Msg-2后，根据查询到的物理交换机能力情况，选取能够支持SrvID所对应业务的物理交换机，并针对SrvID所对应业务构造虚拟网(vNet)；
步骤(7)控制件在虚拟网vNet中执行自定义的路径规划算法得到最优业务部署路径(Path)，构建业务安装节点集(SrvInstallSets)，SrvInstallSets中的每一个元素对应Path上一个物理交换机；
步骤(8)控制件以组播方式向Path上每一个物理交换机发送控制消息(Msg-3)，开启SrvID所对应业务的安装过程；
所述Msg-3中的MsgType设置为2、RecvSets字段设置为SrvInstallSets、SrvSupport字段设置为1、ConfResult字段设置为-1、ConfCost字段设置为-1；
步骤(9)每一个物理交换机接收到控制消息Msg-3后，执行如下步骤：
9-1物理交换机判断自己是否属于Msg-3中的RecvSets字段，如果不属 于则设置ConfResult字段的值为2，进入步骤9-3；如果属于，直接进入步骤9-2；
9-2物理交换机执行业务安装过程，如果安装成功则，设置ConfCost字段的值为当前的资源开销，同时设置ConfResult字段的值为0；如果安装失败则设置ConfResult字段的值为1；
9-3物理交换机将修改后的字段值写入控制消息(Msg-4)，MsgType设置为1，其它字段和Msg-3相同，Msg-4以单播方式发回给控制件；
步骤(10)控制件遍历节点集SrvInstallSets中每一个物理交换机所返回的控制消息Msg-4，如果所有的控制消息Msg-4的ConfResult字段都为0，则表示此次业务配置成功，同时根据ConfCost字段更新虚拟网vNet信息；如果所有的控制消息Msg-4的ConfResult字段不全为0，则表示此次业务配置不成功，执行如下步骤：
10-1控制件构造控制消息(Msg-5)，MsgType设置为3，其它字段和Msg-3相同，Msg-5以组播方式发送至Path上每一个物理交换机；
10-2收到Msg-5的物理交换机，卸载SrvID所对应的业务；
控制件找出ConfResult字段为1的控制消息Msg-4所对应的物理交换机，在vNet中将其标识为不可用，进入步骤(7)。
实施例
为了便于本领域一般技术人员理解和实现本发明，现结合附图进一步说明本发明的技术方案，给出一种本发明的具体实施方式。
网络中的拓扑和节点能力动态变化，为获取实时、精确的全局网络资源视图，每当新的业务请求到来时，控制件主动向下查询基础设施层中物理节点的能力和链路，被查询到的物理节点向控制件反馈自己的能力信息和连接状态，控制件根据基础设施层的反馈信息规划服务路径、生成每个物理节点所需的配置命令，然后针对每个物理节点下发配置命令，最后物理节点执行配置命令并将运行状态反馈至控制件。期间控制件针对每一类型的网络业务构建并维护一个虚拟网，该虚拟网包含了服务请求所需的服务路径。
基于上述分析，本发明的业务配置方法可实现如下，如图1所示：
首先，用户可以通过图形化的人机交互界面，针对要部署的业务进行描述，描述结果被量化成具体的业务请求参数并据此构造HTTP消息，访问控制层的Web服务接口，该服务接口形态可以是类似Web Service的RESTful API。
控制件启动数据层的物理交换机的能力查询过程，过程中需要构造控制消息用于查询每个物理交换机的能力，由于针对新业务每个物理交换机的支持能力尚不可知，因此采用广播的方式将该控制消息发送至每一个物理交换机。控制消息包含了消息类型(MsgType)、业务ID(SrvID)、业务规格说明(SrvDesc)、接收节点集(RecvSets)、发送节点集(TransSets)、业务支持(SrvSupport)、业务配置结果(ConfResult)、业务配置代价(ConfCost)8个主要字段，这些字段足以描述一个业务及其安装过程，此时将查询消息中的RecvSets初始值设置为空，SrvSupport、ConfResult和ConfCost字段初始值设置为-1。其中MsgType值为0表示查询、1表示应答、2表示业务安装、3表示业务卸载。
每个物理交换机都将收到来自控制件的查询消息，首先判断自身是否支持查询消息中所请求的业务，如果不能够，将SrvSupport设置为1，表示该物理机不支持该业务；如果能够支持，再判断是否能够满足SrvDesc所描述的业务规格要求，如果满足设置SrvSupport字段为0，如果不满足设置SrvSupport字段为2，表示该物理交换机虽可以支持该业务但能力不足。每个物理交换机根据将自己检查的结果，重新构造一个应答消息，以单播方式的告知控制件。
控制件根据查询到的物理节点能力和链路信息，更新网络资源视图、选取能够支持所请求业务的物理交换机，构建并维护虚拟网，在虚拟网中执行自定义的服务路径发现算法(可以是最短路径优先算法，也可以是距离矢量算法等)得到最优的服务部署路径Path。之后，针对拟定服务部署路径上的每个节点，构建业务安装节点集SrvInstallSets，该集合中的每一个元素对应路径上一个物理交换机。
控制件和服务路径上每一个物理交换机形成了一对多的对应关系，此时 控制件向每一个物理交换机发送消息适合采用组播模式，组播源是控制件，组成员是服务路径上每一个物理交换机。控制件以组播方式向数据层中所有的物理交换机发送控制消息，用于指示物理机交换机进行业务安装。此时，控制消息中RecvSets字段设置为业务安装节点集、SrvSupport字段设置为1、ConfResult字段设置为-1、ConfCost字段设置为-1，这是因为已经可以确定收到该控制消息的物理交换机必然是支持该业务的，但业务配置结果和业务配置代价尚且不知道。
接下来，每个收到组播的业务安装消息的物理交换机，首先通过判断消息中的RecvSets字段来再次确认自己是否属于该安装消息的接受者，一般说来这一步不会有什么问题，否则该物理交换机不会收到组播消息，但也不排除有意外，因此如果物理交换机发现自己不属于安装消息的接受者，就需要以单播的方式告知控制件。在物理交换机自己属于该安装消息的接受者的情况下，执行业务安装过程，安装过程具体表现为针对业务运行分配计算资源和链路资源，安装成功后将资源开销数写入控制消息中的ConfCost字段，同时设置控制消息中的ConfResult字段为0；如果安装不成功，那么直接将ConfResult字段设置为1，表示安装失败。之后，根据安装结果构造控制消息，以单播方式告知控制件。
控制件检查业务安装节点集SrvInstallSets中每一个物理交换机节点返回安装确认消息，如果所有安装确认消息中的ConfResult都为0，表示服务部署路径Path完全成功；否则，说明服务部署路径Path不成功，此时控制件还需要在此撤回原来的安装过程，控制件构造控制消息，用于执行业务卸载过程并以组播发送至Path上的每一个物理交换机，执行业务卸载过程。
在服务部署路径Path不成功的情况下，控制件将安装业务不成功的物理交换机在虚拟网中标识为不可用，重新进行服务部署路径规划并执行安装过程。
需要补充说明的是：在上述业务部署过程中，控制件的一项重要工作就是，基于网络资源视图构建虚拟网。网络资源视图是数据层中底层物理网的 子集，它实时记录了物理网中的拓扑和资源分布，其中资源分布包括链路带宽占用和节点能力使用情况。

Claims (1)

  1. 一种软件可定义的网络业务配置方法，其特征在于，包括如下步骤：
    步骤(1)网络由应用层、控制层和数据层组成，控制层的实体为控制件，数据层的实体为物理交换机；
    步骤(2)用户通过应用层描述所需的业务，构造业务请求并通过web服务接口转给控制件；
    步骤(3)控制件以广播方式向数据层中所有的物理交换机发送控制消息(Msg-1)，查询每个物理交换机的能力；
    所述控制消息包含消息类型(MsgType)、业务ID(SrvID)、业务规格说明(SrvDesc)、接收节点集(RecvSets)、发送节点集(TransSets)、业务支持(SrvSupport)、业务配置结果(ConfResult)、业务配置代价(ConfCost)8个主要字段；其中MsgType值为0表示查询、1表示应答、2表示业务安装、3表示业务卸载；
    在查询每个物理交换机的能力时，Msg-1中MsgType设置为0，RecvSets初始值设置为空，SrvSupport、ConfResult和ConfCost字段初始值设置为-1；
    步骤(4)物理交换机接收到Msg-1后，首先检查自己是否支持SrvID所对应业务，如果不能够支持，设置SrvSupport字段的值为1；如果能够支持，物理交换机再根据Msg-1中的SrvDesc字段检查自己是否满足业务规格要求，如不能满足则设置SrvSupport字段的值为2，如能满足则设置SrvSupport字段的值为0；
    步骤(5)物理交换机将步骤(4)设置后的字段值写入控制消息(Msg-2)，MsgType设置为1，其他字段值与Msg-1相同，Msg-2以单播方式发回给控制件；
    步骤(6)控制件接收到Msg-2后，根据查询到的物理交换机能力情况，选取能够支持SrvID所对应业务的物理交换机，并针对SrvID所对应业务构造虚 拟网(vNet)；
    步骤(7)控制件在虚拟网vNet中执行自定义的路径规划算法得到最优业务部署路径(Path)，构建业务安装节点集(SrvInstallSets)，SrvInstallSets中的每一个元素对应Path上一个物理交换机；
    步骤(8)控制件以组播方式向Path上每一个物理交换机发送控制消息(Msg-3)，开启SrvID所对应业务的安装过程；
    所述Msg-3中的MsgType设置为2、RecvSets字段设置为SrvInstallSets、SrvSupport字段设置为1、ConfResult字段设置为-1、ConfCost字段设置为-1；
    步骤(9)每一个物理交换机接收到控制消息Msg-3后，执行如下步骤：
    9-1物理交换机判断自己是否属于Msg-3中的RecvSets字段，如果不属于则设置ConfResult字段的值为2，进入步骤9-3；如果属于，直接进入步骤9-2；
    9-2物理交换机执行业务安装过程，如果安装成功则，设置ConfCost字段的值为当前的资源开销，同时设置ConfResult字段的值为0；如果安装失败则设置ConfResult字段的值为1；
    9-3物理交换机将修改后的字段值写入控制消息(Msg-4)，MsgType设置为1，其它字段和Msg-3相同，Msg-4以单播方式发回给控制件；
    步骤(10)控制件遍历节点集SrvInstallSets中每一个物理交换机所返回的控制消息Msg-4，如果所有的控制消息Msg-4的ConfResult字段都为0，则表示此次业务配置成功，同时根据ConfCost字段更新虚拟网vNet信息；如果所有的控制消息Msg-4的ConfResult字段不全为0，则表示此次业务配置不成功，执行如下步骤：
    10-1控制件构造控制消息(Msg-5)，MsgType设置为3，其它字段和Msg-3相同，Msg-5以组播方式发送至Path上每一个物理交换机；
    10-2收到Msg-5的物理交换机，卸载SrvID所对应的业务；
    控制件找出ConfResult字段为1的控制消息Msg-4所对应的物理交换机，在vNet中将其标识为不可用，进入步骤(7)。
PCT/CN2017/086510 2017-05-30 2017-05-30 一种软件可定义的网络业务配置方法 WO2018218472A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/070,293 US11310128B2 (en) 2017-05-30 2017-05-30 Software-definable network service configuration method
PCT/CN2017/086510 WO2018218472A1 (zh) 2017-05-30 2017-05-30 一种软件可定义的网络业务配置方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/086510 WO2018218472A1 (zh) 2017-05-30 2017-05-30 一种软件可定义的网络业务配置方法

Publications (1)

Publication Number Publication Date
WO2018218472A1 true WO2018218472A1 (zh) 2018-12-06

Family

ID=64454202

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/086510 WO2018218472A1 (zh) 2017-05-30 2017-05-30 一种软件可定义的网络业务配置方法

Country Status (2)

Country Link
US (1) US11310128B2 (zh)
WO (1) WO2018218472A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113676412A (zh) * 2020-05-15 2021-11-19 大唐移动通信设备有限公司 网络控制方法及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101883049A (zh) * 2010-06-29 2010-11-10 浙江工商大学 基于转发和控制分离网络件架构实现业务配置路由器的方法
CN102104542A (zh) * 2011-01-14 2011-06-22 中国人民解放军信息工程大学 转发和控制分离网络件架构下实现业务集群路由器的方法
US20140244847A1 (en) * 2011-08-24 2014-08-28 Alcatel-Lucent Method for managing network resources within a plurality of datacenters
CN104320278A (zh) * 2014-10-31 2015-01-28 杭州华三通信技术有限公司 基于软件定义网络sdn的广域网络实现方法及设备

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8495244B2 (en) * 2005-06-29 2013-07-23 Jumpstart Wireless Corporation System and method for dynamic automatic communication path selection, distributed device synchronization and task delegation
JP5571128B2 (ja) 2012-06-28 2014-08-13 株式会社東芝 計測支援装置、方法及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101883049A (zh) * 2010-06-29 2010-11-10 浙江工商大学 基于转发和控制分离网络件架构实现业务配置路由器的方法
CN102104542A (zh) * 2011-01-14 2011-06-22 中国人民解放军信息工程大学 转发和控制分离网络件架构下实现业务集群路由器的方法
US20140244847A1 (en) * 2011-08-24 2014-08-28 Alcatel-Lucent Method for managing network resources within a plurality of datacenters
CN104320278A (zh) * 2014-10-31 2015-01-28 杭州华三通信技术有限公司 基于软件定义网络sdn的广域网络实现方法及设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113676412A (zh) * 2020-05-15 2021-11-19 大唐移动通信设备有限公司 网络控制方法及设备

Also Published As

Publication number Publication date
US11310128B2 (en) 2022-04-19
US20210320852A1 (en) 2021-10-14

Similar Documents

Publication Publication Date Title
US11368862B2 (en) Point-to-multipoint or multipoint-to-multipoint mesh self-organized network over WIGIG standards with new MAC layer
CN108833166B (zh) 边缘云报文转发方法及系统、网络报文转发方法及系统
US9461877B1 (en) Aggregating network resource allocation information and network resource configuration information
CN110476453A (zh) 用于向客户提供网络切片的服务发放
US20150003296A1 (en) System and method for providing p2p based reconfigurable computing and structured data distribution
CN108777633B (zh) 支持数据调度的意图型工业sdn北向接口系统及交互方法
US9088477B2 (en) Distributed fabric management protocol
EP3132567B1 (en) Event processing in a network management system
Nguyen et al. Can sdn technology be transported to software-defined wsn/iot?
WO2021164330A1 (zh) 一种基于键值配置的控制请求发送方法、装置和系统
US11805011B2 (en) Bulk discovery of devices behind a network address translation device
CN113300957A (zh) 一种基于段路由的智能骨干网管理调度系统和方法
CN106850803B (zh) 一种基于sdn的加权轮询系统及算法
CN106878090B (zh) 支持多样性架构组件的软件定义网络控制器
CN114157715B (zh) 一种骨干网络控制器的网络信息管理方法及系统
WO2018218472A1 (zh) 一种软件可定义的网络业务配置方法
US10686752B2 (en) Methods for configuring and managing an IP network, corresponding devices and computer programs
WO2015070763A1 (zh) X2接口的自建立方法及装置
CN104320322A (zh) 一种报文控制方法和设备
CN107294773B (zh) 一种软件可定义的网络业务配置方法
WO2015003420A1 (zh) 一种云计算环境的资源部署方法
JP2015103854A (ja) ネットワーク管理制御装置、ネットワーク管理制御システム、及びネットワーク管理制御方法
CN116458204A (zh) 传输网络切片控制设备及用于基于时间敏感网络的传输网络的控制面实体
Nguyen et al. S-manage protocol for provisioning IoT applications on demand
KR20150033498A (ko) 써킷망과 패킷망이 혼재하는 복합망을 위한 단대단 경로 제공 방법 및 이를 위한 통합 소프트웨어 정의 네트워크 컨트롤러

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17911758

Country of ref document: EP

Kind code of ref document: A1