CN107819663B - 一种实现虚拟网络功能服务链的方法和装置 - Google Patents

一种实现虚拟网络功能服务链的方法和装置 Download PDF

Info

Publication number
CN107819663B
CN107819663B CN201711204137.9A CN201711204137A CN107819663B CN 107819663 B CN107819663 B CN 107819663B CN 201711204137 A CN201711204137 A CN 201711204137A CN 107819663 B CN107819663 B CN 107819663B
Authority
CN
China
Prior art keywords
port
service chain
port pair
vnf
vnf module
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN201711204137.9A
Other languages
English (en)
Other versions
CN107819663A (zh
Inventor
黄永远
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ruijie Networks Co Ltd
Original Assignee
Ruijie Networks Co Ltd
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 Ruijie Networks Co Ltd filed Critical Ruijie Networks Co Ltd
Priority to CN201711204137.9A priority Critical patent/CN107819663B/zh
Publication of CN107819663A publication Critical patent/CN107819663A/zh
Application granted granted Critical
Publication of CN107819663B publication Critical patent/CN107819663B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/38—Flow based routing
    • 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/58—Association of routers
    • H04L45/586—Association of routers of virtual routers
    • 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/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering

Abstract

本申请实施例提供了一种实现虚拟网络功能服务链的方法及装置，涉及网络技术领域，能够解决虚拟网络功能服务链不支持透明模式的VNF部署，或不支持透明模式和路由模式混合的VNF部署的问题。该方案包括：服务器确定抽象数据模型，抽象数据模型包括分类器和端口对组列表；服务器根据分类器和端口对组列表确定服务链；其中，端口对组列表包括至少一个端口对，端口对包VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式。本申请可以应用于NFV的编排技术中。

Description

一种实现虚拟网络功能服务链的方法和装置
技术领域
本申请涉及网络技术领域，尤其涉及一种实现虚拟网络功能服务链的方法和装置。
背景技术
网络功能虚拟化(Network Functions Virtualization，NFV)是由运营商主导的一种新型网络技术，目的是通过x86通用硬件架构以及虚拟化技术来承载相关的网络功能，从而降低购买专用网络设备的成本。通过将网络功能从专用设备解耦出来，使网络功能不再强依赖于专用硬件，可以有效地解决资源的合理共享、复用，加快新业务的推出和创新，同时对于实际的网络业务，能够做到按需灵活部署、弹性伸缩、故障检测及恢复。在NFV技术中，针对已部署的虚拟网络功能(Virtualized Network Function，VNF)，可以根据用户定义的业务流路径，对VNF实施编排。如图1所示，包括两条业务流路径，其中业务流A经过的路径为：连接点(Connection Point，CP)11->CP12->CP31->CP32，业务流B经过的路径为：CP21->CP22->CP31->CP32。不仅如此，在VNF编排中还需要关注业务的动态伸缩，如图2所示，当经过VNF2的业务流量超过了某个阈值时，需要动态地增加一个相同类型的VNF，即图中的VNF2-1。然后业务流量均衡地分布在VNF2和VNF2-1，反之，当业务流量下降到某个阈值时，将VNF2-1删除，流量只经过VNF2。
通常，VNF通过Openstack环境加载，VNF的虚拟网卡直接连接到Openstack环境中OpenVswitch上。OpenVswitch即软件实现的虚拟交换机，支持802.1Q虚拟局域网(VirtualLAN((Local Area Network)，VLAN)、服务质量(Quality of Service，QoS)以及OpenFlow等特性，可以为虚拟机与虚拟机、虚拟机与物理机、物理机与物理机之间提供互联。示例性的，如图3所示，服务链(Service Function Chain，SFC)的路径为src->p1->p2->VNF->p3->p4->dst。其中，src为源虚拟机，dst为目的虚拟机。p1、p2、p3、p4都是Openstackneutron端口(port)，都携带各自的VLAN标识(Identity，ID)。服务链将流量引入到下一跳虚拟机的输入端口时，需要修改报文的目的媒体接入控制(Media Access Control，MAC)地址为下一跳虚拟机的输入端口的MAC地址。
在实现上述技术方案的过程中，发明人发现现有技术中至少存在如下问题：服务链不支持透明模式的VNF部署，或不支持透明模式和路由模式混合的VNF部署。透明模式即不修改数据报文的MAC地址的VNF部署，路由模式即修改数据报文的MAC地址的VNF部署。另外，服务链不支持从物理网口引流，且不支持带VLAN ID的报文的传输等。
发明内容
本申请的实施例提供一种实现虚拟网络功能服务链的方法和装置，能够解决虚拟网络功能服务链不支持透明模式的VNF部署或透明模式和路由模式混合的VNF部署的问题。
为达到上述目的，本申请的实施例采用如下技术方案：
第一方面，提供一种实现虚拟网络功能服务链的方法，包括：
服务器确定抽象数据模型，抽象数据模型包括分类器(flow-classifier)和端口对组列表；
服务器根据分类器和端口对组列表确定服务链；
其中，端口对组列表包括至少一个端口对，端口对包括VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式，路由模式用于指示向VNF模块的输入端口发送数据报文时，将数据报文的目的MAC地址修改为VNF模块的输入端口的MAC地址，透明模式用于指示向VNF模块的输入端口发送数据报文时，不修改数据报文的目的MAC地址。
第二方面，提供一种服务器，包括：
确定单元，用于确定抽象数据模型，抽象数据模型包括分类器和端口对组列表；
确定单元，还用于根据分类器和端口对组列表确定服务链；
其中，端口对组列表包括至少一个端口对，端口对包括VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式，路由模式用于指示向VNF模块的输入端口发送数据报文时，将数据报文的目的MAC地址修改为VNF模块的输入端口的MAC地址，透明模式用于指示向VNF模块的输入端口发送数据报文时，不修改数据报文的目的MAC地址。
相比现有技术，从服务链的某个VNF向下一个VNF引流时，需要将报文的目的MAC地址修改为下一个VNF输入端口的MAC地址。由于在透明传输模式下，无需修改报文的任何内容，因此现有技术只能支持路由模式的VNF部署而不支持透明模式的VNF部署。本申请可以根据端口对的数据模型确定如何部署VNF。其中，数据模型中存储有VNF的部署模式，包括透明模式和路由模式。从而，本申请既可以支持透明模式的VNF部署，同时也支持透明和路由混合模式的VNF部署。
附图说明
图1为一种VNF的服务链示意图；
图2为一种VNF负载均衡服务链示意图
图3为一种VNF的服务链示意图；
图4为一种NFV的架构示意图；
图5为一种NFV的架构示意图；
图6为一种实现VNF服务链的方法的流程示意图；
图7为一种VNF的服务链示意图；
图8为一种VNF的端口对示意图；
图9为一种VNF的端口对组示意图；
图10为一种VNF的服务链示意图；
图11为一种VNF的服务链示意图；
图12为一种VNF的服务链示意图；
图13为一种VNF的服务链示意图；
图14为一种VNF的服务链示意图；
图15为一种服务器的结构示意图；
图16为一种服务器的结构示意图；
图17为一种服务器的结构示意图。
具体实施方式
在详细说明本申请的实现方式之前，首先对NFV的架构做如下说明：
服务器上运行的NFV的架构如图4所示，主要包含四个部分，即：VNF模块(即VNF)、网络功能虚拟化基础实施(Network Functions Virtualization Infrastructure，NFVI)、虚拟网络功能管理器(Virtualized Network Function Manager，VNFM)以及网络功能虚拟化编排器(Network Functions Virtualization Orchestrator，NFVO)。其中，VNF代表软件实现的网络功能。NFVI负责对物理资源的抽象，包含虚拟网络、虚拟计算、虚拟存储。VNFM负责VNF的生命周期管理和配置。NFVO负责VNF业务流的管理。NFV的架构还可以包括虚拟基础实施管理器(Virtualized Infrastructure Manager，VIM)(图4中未示出)。VIM负责控制和管理NFVI。
如图5所示，为一种运行环境为Openstack的开源NFV技术方案的实现框架。Openstack是一个开源的云计算管理平台。Openstack Tacker属于Openstack的一个子项目，可以为NFV提供NFVO、VNFM或SFC功能实现。NFVO和VNFM可以通过相应的应用程序接口(Application Programming Interface，API)来调用SFC提供的服务。OpenstackNetworking-Sfc属于Openstack的一个子项目，可以为VNF提供服务链的功能实现以及OpenVswitch代理(Agent)功能。OpenVswitch是软件实现的虚拟交换机，可以存在于物理机中，可以为虚拟机与虚拟机、虚拟机与物理机、物理机与物理机之间提供互联。
本申请实施例可以应用于NFV的编排技术中，例如可以应用于基于Openstack环境实现VNF服务链的方法中。该方法可以通过单个物理服务器或多个物理服务器实现。本申请实施例能够支撑VNF业务的灵活部署、动态引流、动态伸缩等。
下面结合附图对本申请实施例对VNF服务链的实现方法和装置进行详细描述。
本申请实施例提供一种实现VNF服务链的方法，如图6所示，包括：
601、服务器确定抽象数据模型。
可以理解的是，服务链编排用户可以在服务器上通过命令行方式创建抽象数据模型，抽象数据模型包括分类器和端口对组列表。
其中，分类器的作用是对报文进行分类，只有匹配分类器，数据报文才能被引导到相应的服务链，以便相应的服务链对数据报文进行处理。分类器可以包含的内容如下：
分类器的名。
分类器支持的以太网类型，例如支持互联网协议第四版(Internet Protocolversion 4，IPv4)和IPv6。
分类器支持的协议，例如支持传输控制协议(Transmission Control Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)、因特网控制报文协议(InternetControl Message Protocol，ICMP)。
分类器的描述信息。
分类器定义的协议源端口最小值，通常针对TCP和UDP。
分类器定义的协议源端口最大值，通常针对TCP和UDP。
分类器定义的协议目的端口最小值，通常针对TCP和UDP。
分类器定义的协议目的端口最大值，通常针对TCP和UDP。
分类器定义的源网际协议(Internet Protocol，IP)地址。
分类器定义的目的IP地址。
分类器定义的数据报文的源端口，即引流的起点。源端口可以为虚拟端口或物理端口。
分类器定义的数据报文的目的端口，即引流的终点。目的端口可以为虚拟端口或物理端口。
需要说明的是，物理端口可以用字符串信息指示。示例性的，字符串信息的格式可以为：“主机名：物理端口名称”。即物理端口的格式可以包括主机名和物理端口名称。虚拟端口可以用通用唯一识别码(Universally Unique Identifier，UUID)指示。
举例来说，如图7所示，当从物理机1的物理端口eth2进入的数据报文匹配分类器时，分类器可以将数据报文引导到对应的服务链的入口。当数据报文不匹配分类器时，分类器可以将数据报文丢弃或匹配其他流表项。
在一种可能的设计中，端口对(port-pair)组列表包含在虚拟端口对信息中，虚拟端口对信息包括虚拟端口对的基本信息或虚拟端口对的详细信息。
虚拟端口对的基本信息用于记录VNF的输入和输出端口的基本信息。虚拟端口对的基本信息抽象模型是对一个VNF基本信息的抽象，其包含有如下的信息：
端口对名称。举例来说，如图8所示，VNF拥有两个虚拟端口p1和p2。由于每条服务链都对应一条反向服务链，即服务链存在上行和下行两个方向。因此，对于一个VNF而言，通常对应有两个端口对，可以分别记为pp1和pp2，其中pp1＝(入口(ingress)＝p1,出口(egress)＝p2)，pp2＝(ingress＝p2,egress＝p1)。
端口对描述信息。
端口对的虚拟输入端口。
端口对的虚拟输出端口。
端口对的部署模式。这里的部署模式主要有两种，分别为透明模式和路由模式。路由模式用于指示向VNF模块的输入端口发送数据报文时，将数据报文的目的媒体接入控制MAC地址修改为VNF模块的输入端口的MAC地址，透明模式用于指示向VNF模块的输入端口发送数据报文时，不修改数据报文的目的MAC地址。端口对的部署模式可以解决现有技术中不支持透明模式的VNF部署在服务链中的问题。
端口对标识：即端口对标识(Identity，ID)值，其并非是UUID，而是普通的整数。增加端口对ID值的原因是为了实现源进源出的负载均衡。端口对ID值对于同一个VNF的上行和下行两个方向的端口对来说是相同的。如图8所示的两个端口对pp1和pp2，它们都有相同的端口对ID值。
端口对组：即一组端口对，至少包含一个端口对信息。端口对组包含的信息如下所示：
端口对组名称。
端口对组描述信息。
端口对组ID，可以是整数，而非UUID。
端口对组列表：即存储端口对的列表。服务器可以遍历服务器上全部的VNF，将相同类型或执行相同功能的VNF对应的端口对确定为一个端口对组列表，一个端口对组列表包括至少一个端口对。需要说明的是，服务链可以包括多个端口对组列表。对于每个端口对组列表，服务链包括该端口对组列表中的至少一个端口对。举例来说，如图9所示，VNF1和VNF2为一个负载均衡组，VNF1和VNF2是相同类型或执行相同功能的VNF。本申请实施例以无状态的负载均衡为例进行说明，但不限于此，本申请实施例提供的方法也可以应用于有状态的负载均衡中。仅考虑一个方向的情况下，VNF1的端口对为pp1＝(ingress＝p1，egress＝p2)，VNF2的端口对为pp2＝(ingress＝p3，egress＝p4)。因此端口对组包含的端口对列表为[pp1，pp2]。
虚拟端口对详细信息除了包括虚拟端口对基本信息所包括的端口信息外，还可以包括以下内容：
虚拟输入端口所在的主机名称，例如：“物理机1”。
虚拟输入端口的MAC地址。
虚拟输入端口所属的网络类型：可扩展虚拟局域网(Virtual eXtensible LAN，VXLAN)、VLAN等。
虚拟输入端口所属网络的段ID：该段ID是Openstack虚拟网络特有的概念。对于VLAN网络类型，该段ID对应的是VLANID值；对于VXLAN、通用路由封装(Generic RouteEncapsulation，GRE)网络类型，该段ID对应的是隧道ID值。
虚拟输入端口所在物理主机的本地IP(local-IP)值。local-IP也是Openstack虚拟网络特有的概念，只有网络类型为VXLAN、GRE等隧道类型时，local-IP才有意义，local-IP代表本机上的隧道口的IP地址。
是否为物理端口指示:该字段用来标识是普通的虚拟端口对还是物理端口对。对于物理端口对则该字段值为1，反之为0。
物理端口名称：例如图7中的“eth2”“eth3”等。该字段是本申请实施例为了支持从物理端口引流新增的。对于物理端口而言，虚拟端口对的基本信息或虚拟端口对的详细信息中只有三个字段有效，其他字段可视为冗余。这三个字段分别为：虚拟输入端口所在的主机名称、是否物理端口、物理端口名称。
602、服务器根据分类器和端口对组列表确定服务链。
在一种可能的设计中，服务链的定义可以为：服务链＝分类器+端口对组列表。其中，服务链包括的端口对组列表包括至少一个端口对，端口对包括VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式。
举例来说，如图10所示，数据报文分上行和下行两个方向，分别对应上行服务链和下行服务链。其中，上行服务链包括分类器1，记为：fc1。端口对有四个，可以分别记为：pp0＝(compute1:eth2)，pp1＝(ingress＝p1，egress＝p2)，pp2＝(ingress＝p3，egress＝p4)，pp3＝(ingress＝p5，egress＝p6)。其中pp0为物理端口对应的端口对。对于“compute1:eth3”，无需创建端口对，因为对于上行服务链，该端口是终点。端口对组有三个，分别记为：pg1＝[pp1]，pg2＝[pp2]，pg3＝[pp3]。从而，上行服务链可以记为pc1＝fc1+[pg1，pg2，pg3]。
下行服务链包括分类器2，可以记为fc2。包括端口对四个，可以分别记为：pp4＝(compute1:eth3),pp5＝(ingress＝p6,egress＝p5)，pp6＝(ingress＝p4,egress＝p3)，pp7＝(ingress＝p2，egress＝p1)。其中pp4为物理端口对应的端口对。对于“compute1:eth2”物理端口无需创建端口对，因为对于下行服务链，该端口是终点。端口对组有三个，分别记为：pg4＝[pp5]，pg5＝[pp6]，pg6＝[pp7]。从而，下行服务链可以记为pc2＝fc2+[pg4，pg5，pg6]。
需要说明的是，本申请以一条服务链包含一个分类器匹配为例进行说明，在实际应用中，一条服务链可以包含多个分类器匹配。
另外，服务器可以删除服务链对应所有VNF模块的输入端口和输出端口的VLANID。其中，服务链对应的VNF模块为至少一个。这是由于VNF模块的输入端口和输出端口通过具有相应的VLAN ID，当带VLAN ID的数据报文经过VNF模块的输入端口和输出端口时，VNF模块的输入端口和输出端口会将数据报文的VLAN ID修改为端口自身的VLAN ID，而数据报文的VLAN ID是用户所需的，而删除VNF模块的输入端口和输出端口的VLAN ID后，VNF模块的输入端口和输出端口就不会改变数据报文的VLAN报文VLAN ID，从而提高用户体验。
603、服务器根据服务链构造服务链流表。
服务链流表可被视作是对网络设备的数据转发功能的一种抽象。在传统网络设备中，交换机和路由器的数据转发需要依赖设备中保存的二层MAC地址转发表或者三层IP地址路由表，而服务链流表也是如此，不过在它的表项中整合了网络中各个层次的网络配置信息，从而在进行数据转发时可以使用更丰富的规则。
流表的每个流表项可以包括用于数据包匹配的包头域(Header Fields)以及用于展示匹配的数据包如何处理的动作(actions)。其中，包头域可以包括流表(table)序号、输入端口(in_port)、优先级(priority)以及匹配分类器等。
下面以服务链对应的端口对都为透明模式为例，对服务链流表进行说明。
举例来说，如图11所示，服务器部署了三个VNF，即VNF1、VNF2、VNF3。三个VNF对应的端口对都为透明模式，即不对报文内容做任何修改，直接透传。需要说明的是，由于虚拟端口p1、p2、p3、p4、p5、p6都属于服务链上的端口，这些虚拟端口都包括VLAN ID。为了不改变数据报文的VLAN ID，在创建服务链的时候可以删除这些虚拟端口的VLAN ID，以支持数据报文的VLAN ID透传。
服务链流表包括上行服务链流表和下行服务链流表，上行服务链流表的设计如下所示：
table＝0,in_port＝物理机1:eth2,priority＝30,匹配分类器1,actions＝output:p1
table＝0,in_port＝物理机1:eth2,priority＝0,不匹配分类器1,actions＝output:物理机1:eth3
table＝0,in_port＝p2,priority＝30,actions＝output:p3
table＝0,in_port＝p4,priority＝30,actions＝output:p5
table＝0,in_port＝p6,priority＝30,actions＝output:物理机1:eth3
可以理解的是，当交换机接收到数据报文时，可以根据序号为0且优先级最高(例如priority＝30)的table对该数据报文进行匹配。根据上行服务链流表，若数据报文的输入端口为物理机1:eth2且该数据报文携带的传输协议和IP地址与分类器1定义的传输协议和IP地址匹配，则交换机执行将该数据报文从p1输出的动作。
类似的，下行服务链流表的设计如下所示：
table＝0,in_port＝物理机1:eth3,priority＝30,匹配分类器2,actions＝output:p6
table＝0,in_port＝物理机1:eth3,priority＝0,不匹配分类器2,actions＝output:物理机1:eth2
table＝0,in_port＝p5,priority＝30,actions＝output:p4
table＝0,in_port＝p3,priority＝30,actions＝output:p2
table＝0,in_port＝p1,priority＝30,actions＝output:物理机1:eth2
由上行服务链流表和下行服务链流表的设计可知，透明模式下不需要修改报文的任何内容，直接透传。同时只需要在引流口匹配分类器即可，对于服务链的中间环节，无需再匹配分类器。
需要说明的是，服务链可以存在一条对应的反向服务链，即服务链存在上行和下行两个方向，上行和下行的源MAC和目的MAC对会存在不相同的情况，这样就会导致上行和下行计算出来的哈希值不同，进而有可能选择不同的VNF，导致流量无法源进源出。本申请实施例提出的解法方法是：可以进一步通过端口对ID值唯一标识特定的VNF。而且，使用OpenVswitch多路径(multipath)流表来代替组(group)流表实现负载均衡。这样，在下发上行和下行负载均衡流表的时候，可以根据端口对ID值，利用multipath流表引入相同的VNF。即上行服务链对应的VNF模块与下行服务链对应的VNF模块相同，上行服务链对应的VNF模块或下行服务链对应的VNF模块为至少一个。这样就可以做到源进源出的负载均衡了。
举例来说，如图12所示，VNF1和VNF1-1都为透明模式，属于一组，用于负载均衡。下面只描述负载均衡相关的流表，其他流表项和上述描述一致。
上行服务链负载均衡流表如下：
table＝0,in_port＝物理机1:eth2,priority＝30,匹配分类器1,reg0＝0,actions＝load:0x1->NXM_NX_REG0[],multipath(symmetric_l3l4,1024,modulo_n,2,0,NXM_NX_REG1[]),resubmit(5)
table＝5,priority＝0,reg0＝0x1,reg1＝0,actions＝output:p1
table＝5,priority＝0,reg0＝0x1,reg1＝1,actions＝output:p1-1
下行服务链负载均衡流表如下：
table＝0,in_port＝p3,priority＝30,reg0＝0,actions＝load:0x2->NXM_NX_REG0[],multipath(symmetric_l3l4,1024,modulo_n,2,0,NXM_NX_REG1[]),resubmit(5)
table＝5,priority＝0,reg0＝0x2,reg1＝0,actions＝output:p2
table＝5,priority＝0,reg0＝0x2,reg1＝1,actions＝output:p2-1
其中，NXM_NX_REG0[]的值在上行服务链时可以为1，在下行服务链时可以为2。对于不同的负载均衡路径，路径的索引值存储在寄存器NXM_NX_REG1[]中。例如，VNF1对应的索引可以为0，VNF1-1对应的索引可以为1。VNF对应的索引是根据各自端口对抽象数据模型中存储的端口对ID值映射而来的，较小的端口对ID映射为0，较大的端口对ID映射为1。这样一来，可以保证上行服务链和下行服务链对应的VNF是相同的，从而满足了源进源出的负载均衡。
下面以服务链对应的端口对都为路由模式为例，对服务链流表进行说明。
示例性的，如图13所示。部署了三个VNF，即：VNF1、VNF2、VNF3。三个VNF对应的端口对都是路由模式。
上行服务链流表设计如下：
table＝0,in_port＝物理机1:eth2,priority＝30,匹配分类器1,actions＝修改报文目的MAC为p1端口的MAC地址,output:p1
table＝0,in_port＝物理机1:eth2,priority＝30,ARP报文,目标IP＝p1端口的IP地址,actions＝output:p1
table＝0,in_port＝物理机1:eth2,priority＝0,不匹配分类器1,actions＝drop
table＝0,in_port＝p2,priority＝30,actions＝修改报文目的MAC为p3端口的MAC地址,output:p3
table＝0,in_port＝p4,priority＝30,actions＝修改报文目的MAC为p5端口的MAC地址,output:p5
table＝0,in_port＝p6,priority＝30,actions＝output:物理机1:eth3
类似的，下行服务链流表设计如下；
table＝0,in_port＝物理机1:eth3,priority＝30,匹配分类器2,actions＝修改报文目的MAC为p6端口的MAC地址,output:p6
table＝0,in_port＝物理机1:eth3,priority＝30,ARP报文,目标IP＝p6端口的IP地址,actions＝output:p6
table＝0,in_port＝物理机1:eth3,priority＝0,不匹配分类器2,actions＝drop
table＝0,in_port＝p5,priority＝30,actions＝修改报文目的MAC为p4端口的MAC地址,output:p4
table＝0,in_port＝p3,priority＝30,actions＝修改报文目的MAC为p2端口的MAC地址,output:p2
table＝0,in_port＝p1,priority＝30,actions＝output:物理机1:eth2
从上面的流表设计可知，由于VNF对应的端口对都是路由模式，因此在将数据报文发送到下一跳VNF之前，需要将报文的目的MAC地址修改为下一跳输入端口的MAC地址。同时只需要在引流口匹配分类器即可，对于服务链的中间环节，无需再匹配分类器。
需要说明的是，如图13所示，由于虚拟端口p1、p2、p3、p4、p5、p6都属于服务链上的端口，这些路由模式的虚拟端口都包括VLAN ID。为了不改变数据报文的VLAN ID，在创建服务链的时候可以删除这些虚拟端口的VLAN ID，以支持数据报文的VLAN ID透传。
另外，对于端口对为路由模式的负载均衡，和上述的端口对为透明模式的负载均衡的流表设计的区别在于，路由模式下需要对报文的目的MAC做修改。
下面以服务链对应的端口对中一部分为透明模式，其余部分为路由模式为例进行说明。
举例来说，如图14所示。部署了三个VNF，即：VNF1、VNF2、VNF3。其中VNF1对应的端口对和VNF3对应的端口对为透明模式，不需要对报文做任何修改，直接透传报文。VNF2对应的端口对为路由模式，需要对报文进行修改。
上行服务链流表设计如下：
table＝0,in_port＝物理机1:eth2,priority＝30,匹配分类器1,actions＝output:p1
table＝0,in_port＝物理机1:eth2,priority＝30,ARP报文,目标IP＝p3端口的IP地址,actions＝output:p3
table＝0,in_port＝物理机1:eth2,priority＝0,不匹配分类器1,actions＝drop
table＝0,in_port＝p2,priority＝30,actions＝修改报文目的MAC为p3端口的MAC地址,output:p3
table＝0,in_port＝p4,priority＝30,actions＝output:p5
table＝0,in_port＝p6,priority＝30,actions＝output:物理机1:eth3
类似的，下行服务链流表设计如下：
table＝0,in_port＝物理机1:eth3,priority＝30,匹配分类器2,actions＝output:p6
table＝0,in_port＝物理机1:eth3,priority＝30,ARP报文,目标IP＝p4端口的IP地址,actions＝output:p4
table＝0,in_port＝物理机1:eth3,priority＝0,不匹配分类器2,actions＝drop
table＝0,in_port＝p5,priority＝30,actions＝修改报文目的MAC为p4端口的MAC地址,output:p4
table＝0,in_port＝p3,priority＝30,actions＝output:p2
table＝0,in_port＝p1,priority＝30,actions＝output:物理机1:eth2
从上面的流表设计可知，从透明模式的VNF引流到路由模式的VNF时，需要将报文的目的MAC地址修改为路由模式VNF的输入端口的MAC地址。从路由模式的VNF引流到透明模式的VNF时，无需修改报文的目的MAC地址。同时只需要在引流口匹配分类器即可，对于服务链的中间环节，无需再匹配分类器。
对于上行服务链，最后一个路由模式的VNF的输出端口(如图14的p4端口)需要和外部网络交互ARP报文。也就是说，数据报文从VNF2的p4端口发送出去之前，需要向VNF2的下一跳网关请求MAC地址。其中，VNF的配置信息可以用于指示VNF2的下一跳网关。因此VNF2可以通过p4->p5->p6->物理机1:eth3来广播ARP报文。下一跳网关接收到广播的ARP报文后，可以向VNF2发送ARP回应报文，ARP回应报文包括下一跳网关的MAC地址。但是由于ARP回应报文无法匹配分类器2，为了使p4端口接收到ARP回应报文，可以增加相应的ARP回应报文的流表，其中，ARP回应报文的目标IP地址为P4端口的IP地址。由此，可以使下一跳网关回应的ARP报文能够正确投递到p4端口。类似的，对于下行服务链，可以增加ARP回应报文的流表，以便最后一个路由模式的VNF的输出端口(如图14的p3端口)可以接收到下一跳网关回复的ARP回应报文。
上述主要从服务器的角度对本申请实施例提供的方案进行了介绍。可以理解的是，服务器为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对服务器进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
相比现有技术，从服务链的某个VNF向下一个VNF引流时，需要将报文的目的MAC地址修改为下一个VNF输入端口的MAC地址。由于在透明传输模式下，无需修改报文的任何内容，因此现有技术只能支持路由模式的VNF部署而不支持透明模式的VNF部署。本申请实施例中，服务器可以根据分类器和端口对组列表确定服务链；其中，端口对组列表包括至少一个端口对，端口对包括虚拟网络功能VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式。从而，当从服务链的某个VNF向下一个VNF引流时，若确定端口对为透明模式，则无需修改报文的任何内容，例如MAC地址。若确定端口对为路由模式，则可以修改报文的MAC地址。由此，本申请既可以支持透明模式的VNF部署，同时也支持透明和路由混合模式的VNF部署。
在采用对应各个功能划分各个功能模块的情况下，图15示出了上述实施例中所涉及的服务器15的一种可能的结构示意图，服务器包括：确定单元1501和处理单元1502。在本申请实施例中，确定单元1501可以用于确定抽象数据模型，抽象数据模型包括分类器和端口对组列表；根据分类器和端口对组列表确定服务链。处理单元1502用于根据服务链构造服务链流表。在图6所示的方法实施例中，确定单元1501用于支持服务器执行图6中的过程601和602；处理单元1502用于支持服务器执行图6中的过程603。其中，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
在采用集成的单元的情况下，图16示出了上述实施例中所涉及的服务器的一种可能的结构示意图。在本申请中，服务器可以包括处理模块1601、通信模块1602和存储模块1603。其中，处理模块1601用于控制服务器的各部分硬件装置和应用程序软件等；通信模块1602用于可使用无线保真(Wireless Fidelity，WiFi)等通讯方式接受其它设备发送的指令，也可以将服务器的数据发送给其它设备；存储模块1603用于执行服务器的软件程序的存储、数据的存储和软件的运行等。其中，处理模块1601可以是处理器或控制器，例如可以是中央处理器(Central Processing Unit，CPU)，通用处理器，数字信号处理器(DigitalSignal Processor，DSP)，专用集成电路(Application-Specific Integrated Circuit，ASIC)，现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信模块1602可以是收发器、收发电路或通信接口等。存储模块1603可以是存储器。
当处理模块1601为处理器，通信模块1602为收发器，存储模块1603为存储器时，本申请实施例所涉及的服务器可以为图17所示的服务器。
参阅图17所示，该服务器17包括：处理器1701、收发器1702、存储器1703以及总线1704。其中，收发器1702、处理器1701以及存储器1703通过总线1704相互连接；总线1704可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图17中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
结合本申请公开内容所描述的方法或者算法的步骤可以硬件的方式来实现，也可以是由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于RAM、闪存、ROM、EPROM、EEPROM、寄存器、硬盘、移动硬盘、只读光盘或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外，该ASIC可以位于核心网接口设备中。当然，处理器和存储介质也可以作为分立组件存在于核心网接口设备中。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
本领域内的技术人员应明白，本申请实施例可提供为方法、系统、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请实施例是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请的保护范围之内。

Claims (9)

1.一种实现虚拟网络功能服务链的方法，其特征在于，包括：
服务器确定抽象数据模型，所述抽象数据模型包括分类器和端口对组列表；
所述服务器根据所述分类器和所述端口对组列表确定服务链；
其中，分类器的作用是对报文进行分类，将数据报文引导到相应的服务链，以便相应的服务链对数据报文进行处理，
所述服务器根据所述分类器确定所述数据报文的源端口和/或目的端口为虚拟端口或物理端口，所述物理端口包括主机名和物理端口名称，
其中，所述端口对组列表包括至少一个端口对，所述端口对包括虚拟网络功能VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式，所述路由模式用于指示向VNF模块的输入端口发送数据报文时，将所述数据报文的目的媒体接入控制MAC地址修改为所述VNF模块的输入端口的MAC地址，所述透明模式用于指示向VNF模块的输入端口发送数据报文时，不修改所述数据报文的目的MAC地址。
2.根据权利要求1所述的实现虚拟网络功能服务链的方法，其特征在于，所述抽象数据模型还包括端口对标识，所述服务链对应的端口对标识与所述服务链的反向服务链对应的端口对标识相同，所述服务链对应的端口对标识用于指示所述服务链对应的VNF模块，所述服务链的反向服务链对应的端口对标识用于指示所述服务链的反向服务链对应的VNF模块，所述服务链或所述反向服务链对应的VNF模块为至少一个。
3.根据权利要求1或2所述的实现虚拟网络功能服务链的方法，其特征在于，所述方法还包括：
所述服务器确定删除所述服务链对应的所述VNF模块的虚拟局域网标识VLAN ID，所述VNF模块的VLAN ID包括所述VNF模块的输入端口的VLAN ID和所述VNF模块的输出端口的VLAN ID，所述VNF模块为至少一个。
4.根据权利要求1或2所述的实现虚拟网络功能服务链的方法，其特征在于，所述方法还包括：
所述服务器根据所述服务链构造服务链流表；
当所述服务链对应的端口对中包括路由模式的端口对时，所述服务链流表包括地址解析协议ARP回应报文的流表，所述ARP回应报文的目标网际协议IP地址为最后一个路由模式的端口对的输出端口的IP地址。
5.一种服务器，其特征在于，包括：
确定单元，用于确定抽象数据模型，所述抽象数据模型包括分类器和端口对组列表；
所述确定单元，还用于根据所述分类器和所述端口对组列表确定服务链；
其中，分类器的作用是对报文进行分类，将数据报文引导到相应的服务链，以便相应的服务链对数据报文进行处理，
所述确定单元还用于：
根据所述分类器确定所述数据报文的源端口和/或目的端口为虚拟端口或物理端口，所述物理端口包括主机名和物理端口名称，
其中，所述端口对组列表包括至少一个端口对，所述端口对包括虚拟网络功能VNF模块的输入端口和输出端口，对于每个端口对，该端口对为路由模式或透明模式，所述路由模式用于指示向VNF模块的输入端口发送数据报文时，将所述数据报文的目的媒体接入控制MAC地址修改为所述VNF模块的输入端口的MAC地址，所述透明模式用于指示向VNF模块的输入端口发送数据报文时，不修改所述数据报文的目的MAC地址。
6.根据权利要求5所述的服务器，其特征在于，所述抽象数据模型还包括端口对标识，所述服务链对应的端口对标识与所述服务链的反向服务链对应的端口对标识相同，所述服务链对应的端口对标识用于指示所述服务链对应的VNF模块，所述服务链的反向服务链对应的端口对标识用于指示所述服务链的反向服务链对应的VNF模块，所述服务链或所述反向服务链对应的VNF模块为至少一个。
7.根据权利要求5或6所述的服务器，其特征在于，所述确定单元还用于：
确定删除所述服务链对应的所述VNF模块的虚拟局域网标识VLAN ID，所述VNF模块的VLAN ID包括所述VNF模块的输入端口的VLAN ID和所述VNF模块的输出端口的VLAN ID，所述VNF模块为至少一个。
8.根据权利要求5或6所述的服务器，其特征在于，还包括处理单元，用于：
根据所述服务链构造服务链流表；
当所述服务链对应的端口对中包括路由模式的端口对时，所述服务链流表包括地址解析协议ARP回应报文的流表，所述ARP回应报文的目标网际协议IP地址为最后一个路由模式的端口对的输出端口的IP地址。
9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-4任一项所述的实现虚拟网络功能服务链的方法。
CN201711204137.9A 2017-11-27 2017-11-27 一种实现虚拟网络功能服务链的方法和装置 Active CN107819663B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201711204137.9A CN107819663B (zh) 2017-11-27 2017-11-27 一种实现虚拟网络功能服务链的方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201711204137.9A CN107819663B (zh) 2017-11-27 2017-11-27 一种实现虚拟网络功能服务链的方法和装置

Publications (2)

Publication Number Publication Date
CN107819663A CN107819663A (zh) 2018-03-20
CN107819663B true CN107819663B (zh) 2020-06-16

Family

ID=61610276

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201711204137.9A Active CN107819663B (zh) 2017-11-27 2017-11-27 一种实现虚拟网络功能服务链的方法和装置

Country Status (1)

Country Link
CN (1) CN107819663B (zh)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108566380B (zh) * 2018-03-15 2020-08-28 国家计算机网络与信息安全管理中心四川分中心 一种代理上网行为识别与检测方法
CN108833335A (zh) * 2018-04-16 2018-11-16 中山大学 一种基于云计算管理平台Openstack的网络安全功能服务链系统
CN109040101A (zh) * 2018-08-27 2018-12-18 北京安数云信息技术有限公司 一种基于openflow协议实现多租户使用不同安全服务的方法
CN110086675B (zh) * 2019-05-05 2022-03-11 广东技术师范大学 服务链的构建方法、设备及计算机可读存储介质
CN110198234B (zh) * 2019-05-15 2021-11-09 中国科学技术大学苏州研究院 软件定义网络中虚拟交换机和虚拟网络功能联合部署方法
CN112087379B (zh) * 2019-06-12 2023-08-01 南京中兴新软件有限责任公司 业务链的编排方法及装置、存储介质和电子装置
CN113132200B (zh) * 2019-12-30 2024-01-19 中兴通讯股份有限公司 数据转发方法、转发器、系统、服务器和存储介质
CN112187608B (zh) * 2020-06-16 2022-04-08 浪潮云信息技术股份公司 一种基于OpenStack的透明模式服务链实现方法及其系统
CN111756632B (zh) * 2020-06-22 2021-10-22 中国电子科技集团公司第五十四研究所 一种基于mpls封装的安全服务链动态编排方法
CN111884863B (zh) * 2020-08-04 2023-11-07 浪潮云信息技术股份公司 一种用于云计算环境的vpc服务链实现方法及系统
CN112367258B (zh) * 2020-10-29 2022-09-06 浪潮云信息技术股份公司 基于Openstack架构实现服务链功能的方法
CN112511432B (zh) * 2020-11-12 2022-01-25 中国科学院计算技术研究所 一种Overlay网络虚拟化SFC路由配置、传输方法及系统
CN114363929B (zh) * 2021-12-28 2023-10-13 展讯半导体(成都)有限公司 通信模式配置方法与装置、网络设备
CN114338193B (zh) * 2021-12-31 2024-01-23 北京天融信网络安全技术有限公司 一种流量编排方法、装置及ovn流量编排系统
CN114726774B (zh) * 2022-04-08 2023-06-23 安超云软件有限公司 用于云平台的服务链实现的方法、装置及基于云平台的系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105122741A (zh) * 2014-03-14 2015-12-02 华为技术有限公司 业务流的业务链控制方法和装置
CN105917690A (zh) * 2013-12-19 2016-08-31 阿姆多克斯软件系统有限公司 基于网络功能虚拟化(nfv)在网络中模块间通信的系统、方法和计算机程序
CN105978806A (zh) * 2016-03-11 2016-09-28 北京星网锐捷网络技术有限公司 一种服务链引流方法和装置
CN106506315A (zh) * 2016-12-16 2017-03-15 无锡华云数据技术服务有限公司 一种报文转发的透明配置方法
WO2017138688A1 (ko) * 2016-02-11 2017-08-17 엘지전자 주식회사 차세대 이동통신 네트워크에서 서비스 기능 체인에 대한 정보를 획득하는 방법 및 단말

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105917690A (zh) * 2013-12-19 2016-08-31 阿姆多克斯软件系统有限公司 基于网络功能虚拟化(nfv)在网络中模块间通信的系统、方法和计算机程序
CN105122741A (zh) * 2014-03-14 2015-12-02 华为技术有限公司 业务流的业务链控制方法和装置
WO2017138688A1 (ko) * 2016-02-11 2017-08-17 엘지전자 주식회사 차세대 이동통신 네트워크에서 서비스 기능 체인에 대한 정보를 획득하는 방법 및 단말
CN105978806A (zh) * 2016-03-11 2016-09-28 北京星网锐捷网络技术有限公司 一种服务链引流方法和装置
CN106506315A (zh) * 2016-12-16 2017-03-15 无锡华云数据技术服务有限公司 一种报文转发的透明配置方法

Also Published As

Publication number Publication date
CN107819663A (zh) 2018-03-20

Similar Documents

Publication Publication Date Title
CN107819663B (zh) 一种实现虚拟网络功能服务链的方法和装置
JP7417825B2 (ja) スライスベースルーティング
EP3254417B1 (en) Method and system for supporting port ranging in a software-defined networking (sdn) system
EP3222012B1 (en) Method and system for virtualizing flow tables in a software-defined networking (sdn) system
EP3130109B1 (en) A method and system for network function placement
JP6445015B2 (ja) ミドルウェアおよびアプリケーションの実行のためにエンジニアド・システムにおいてデータサービスを提供するためのシステムおよび方法
US9729441B2 (en) Service function bundling for service function chains
US9736057B2 (en) Forwarding packet fragments using L4-L7 headers without reassembly in a software-defined networking (SDN) system
CN107896195B (zh) 服务链编排方法、装置及服务链拓扑结构系统
US11159421B2 (en) Routing table selection in a policy based routing system
US20160301603A1 (en) Integrated routing method based on software-defined network and system thereof
EP3507953B1 (en) Techniques for architecture-independent dynamic flow learning in a packet forwarder
CN109076018A (zh) 利用is-is暴露最大节点和/或链路分段标识符深度的技术
US11165692B2 (en) Packet forwarding using vendor extension in a software-defined networking (SDN) system
WO2016162828A1 (en) Method and system for burst based packet processing
US11563698B2 (en) Packet value based packet processing
CN113395212B (zh) 网络装置及其操作方法和非暂时性计算机可读介质
Ranjbar et al. Domain isolation in a multi-tenant software-defined network
RU2675212C1 (ru) Адаптивная балансировка нагрузки при обработке пакетов
WO2018220426A1 (en) Method and system for packet processing of a distributed virtual network function (vnf)
CN113726915A (zh) 网络系统及其中的报文传输方法和相关装置
CN111464443B (zh) 基于服务功能链的报文转发方法、装置、设备及存储介质
US11563648B2 (en) Virtual network function placement in a cloud environment based on historical placement decisions and corresponding performance indicators
CN117596205A (zh) 报文处理方法、装置、电子设备及可读介质
CN117097818A (zh) 一种报文处理的方法及相关设备

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant