CN109417556A - 用于安全服务协作的系统和方法 - Google Patents

Abstract

提供了用于通过启用安全服务功能之间的协作来缓解安全攻击的系统和方法。服务功能链(SFC)节点接收分组并确定是否将服务功能应用于所述分组。响应于确定所述服务功能已经处理了所述分组，可以将所述分组重新分类并切换到不同的SFC路径。

Description

用于安全服务协作的系统和方法

相关申请的交叉引用

本申请要求2016年5月13日提交的题为“用于安全服务协作的系统和方法”的美国临时专利申请号62/336,137的优先权，该申请的内容通过引用并入本文。

技术领域

本公开一般涉及用于实现计算机和通信网络中的服务功能(例如安全服务功能)的协作的系统和方法。

背景技术

在计算机网络中，拒绝服务(DoS)攻击是攻击者使机器、网络或服务对其预期用户不可用的尝试。攻击者可以使用大量业务轰炸目标网络或服务器，从而使目标的可用带宽、CPU容量或其他系统资源过载。此类攻击可能会使服务泛滥或使服务崩溃到无法再服务合法请求的程度。分布式拒绝服务(DDoS)是攻击源自多个源(通常是数千个唯一IP地址)。

这些大容量攻击通常依赖于相同的基本原理。首先，欺骗允许攻击者在请求网络服务时伪造源地址。这导致对该请求的响应被发送到伪造的源地址(这也称为“反射”)。这也使受害者网络难以识别攻击者并防御攻击。其次，攻击者利用放大，其原理在于一些网络协议对相对较小的请求返回大的应答。攻击者对放大特别感兴趣，因为对攻击业务的少量投资能够导致大量攻击。

通常在网络中的用户设备和服务器上实现某种形式的防火墙以帮助防止这种攻击。如本文所使用的，术语“防火墙”具有在计算机领域中通常理解的含义，并且广泛地指以硬件和/或软件实现并且被配置为基于分析通过防火墙的网络业务来检测可疑或未授权活动的网络安全机制。简单防火墙可以以无状态方式运行，并且评估个体业务分组，而不考虑它们各自的分组流或连接。更复杂的防火墙被称为“有状态”防火墙，这种类型的防火墙能够基于检测到新连接并针对个体连接累积分组信息来分析网络业务。防火墙还可以在应用级别运行，其中可以利用应用行为和协议的知识来检测可疑或未授权活动。

云计算通常指一种按需网络，其提供对可配置计算资源(例如网络、服务器、存储、应用、服务等)的共享池的接入。资源池的概念是云计算的一个重要弹性特征，它使资源能够混合和匹配以满足最终用户需求。云计算解决方案为用户和企业均提供了在各个位置的数据中心内存储和处理其数据的功能。还提出了“云朵(cloudlet)”的概念，因为它涉及移动用户的角度。云朵通常指可供附近的移动设备使用的本地化云资源集。

诸如上述那些安全攻击的安全攻击可以在不同的域中需要不同的响应。

因此，期望提供一种消除或缓解上述问题的系统和方法。

发明内容

本公开的一个目的是消除或缓解现有技术的至少一个缺点。

在本公开的第一方面，提供了一种由服务功能链(SFC)节点执行的方法。所述方法包括接收包括第一SFC路径标识符(ID)和第一SFC索引的分组。确定是否将第一服务功能应用于所述分组。根据将所述第一服务功能应用于所述分组，在所述分组中设置已处理指示符。响应于确定所述分组已由所述第一服务功能处理，选择与所述第一SFC路径ID和所述第一SFC索引关联的第二SFC路径ID和第二SFC索引。通过用所述第二SFC路径ID和所述第二SFC索引替换所述第一SFC路径ID和所述第一SFC索引来修改所述分组，以及根据所述第二SFC路径ID和所述第二SFC索引来转发修改后的分组。

在本公开的第二方面，提供了一种服务功能链(SFC)节点，其包括包含处理器和存储器的电路。所述存储器包含能够由所述处理器执行的指令，由此所述SFC节点可操作以接收包括第一SFC路径标识符(ID)和第一SFC索引的分组。所述SFC节点确定是否将第一服务功能应用于所述分组，以及根据将所述第一服务功能应用于所述分组，在所述分组中设置已处理指示符。响应于确定所述分组已由所述第一服务功能处理，所述SFC节点选择与所述第一SFC路径ID和所述第一SFC索引关联的第二SFC路径ID和第二SFC索引。通过用所述第二SFC路径ID和所述第二SFC索引替换所述第一SFC路径ID和所述第一SFC索引来修改所述分组。所述SFC节点根据所述第二SFC路径ID和所述第二SFC索引来转发修改后的分组。

在本公开的另一方面，提供了一种存储可执行指令的计算机可读存储介质，所述可执行指令在由处理器执行时使得所述处理器：接收包括第一SFC路径标识符(ID)和第一SFC索引的分组；确定是否将第一服务功能应用于所述分组；根据将所述第一服务功能应用于所述分组，在所述分组中设置已处理指示符；响应于确定所述分组已由所述第一服务功能处理，选择与所述第一SFC路径ID和所述第一SFC索引关联的第二SFC路径ID和第二SFC索引；通过用所述第二SFC路径ID和所述第二SFC索引替换所述第一SFC路径ID和所述第一SFC索引来修改所述分组；以及根据所述第二SFC路径ID和所述第二SFC索引来转发修改后的分组。

在一些实施例中，根据确定所述第一服务功能是否已被应用于所述分组，确定是否将所述第一服务功能应用于所述分组。确定所述第一服务功能是否已被应用于所述分组能够根据所述分组中的所述已处理指示符来确定。

在一些实施例中，根据协作协议，确定是否将所述第一服务功能应用于所述分组。所述协作协议能够定义所述SFC节点已分配用于应用所述第一服务功能的资源量和所述SFC节点将所述第一服务功能所应用到的业务的带宽中的至少一者。

在一些实施例中，根据接收所述分组的隧道，确定是否将所述第一服务功能应用于所述分组。

在一些实施例中，所述已处理指示符能够作为元数据被存储在所述分组中或者作为字段被存储在例如网络服务报头的分组报头中。

在一些实施例中，响应于确定所述分组尚未被所述第一服务功能处理，根据第一SFC路径ID和第一SFC索引转发所述分组。

在一些实施例中，所述第二SFC路径ID和所述第二SFC索引被选择以旁路所述第一SFC路径中所述第一服务功能的后续实例。

在一些实施例中，根据所述第二SFC路径ID和所述第二SFC索引，选择用于将所述分组转发到第二域的隧道。

本文描述的各个方面和实施例可以备选地、可选地和/或彼此地相互组合。

通过结合附图阅读本公开的具体实施例的以下描述，本公开的其他方面和特征对于本领域普通技术人员将变得显而易见。

附图说明

现在将参考附图仅通过示例的方式描述本公开的实施例，其中：

图1示出了多域安全性概述；

图2示出了域间协作架构；

图3示出了域内协作架构；

图4示出了在SFC中插入新SSF实例的实施例；

图5示出了使SFC数据平面形成分支的实施例；

图6是示出用于在单个域中添加新SSF提供者的方法的流程图；

图7示出了备选SFC路径的实施例；

图8示出了多域协作的实施例；

图9是示出用于实现域间协作的方法的流程图；

图10是示出由SFC节点执行的方法的流程图；

图11是示出示例SFC节点的框图；以及

图12是示出具有模块的示例SFC节点的框图。

具体实施方式

以下可以参考根据附图编号的特定元件。下面的讨论应该被认为是示例性的，而不是限制本公开的范围。本公开的范围在权利要求中限定，并且不应该被认为受到下面描述的实现细节的限制，本领域技术人员将理解，实现细节可以通过用等效功能元件替换元件来修改。

本公开的实施例涉及用于处理分组业务以允许在多个节点和/或域之间提供服务功能的协作的机制。

有序服务功能集的定义和实例化以及随后通过它们的业务“引导”被称为服务功能链(SFC)。已经在因特网工程任务组(IETF)请求评论(RFC)7665[https://tools.ietf.org/html/rfc7665]中定义了SFC架构，其在本文中将出于说明性目的而引用。在该架构中，分组可以在入口上被分类，以便由启用SFC的域中的所需服务功能(SF)集处理，然后通过该功能集转发，以便按指定的顺序由每个SF进行处理。

服务功能(SF)是负责所接收分组的特定处理的功能。SF可以在协议栈的各个层(例如在网络层或其他开放系统互连(OSI)层)处起作用。作为逻辑组件，服务功能可以被实现为虚拟元件或被嵌入物理网络元件中。一个或多个SF可以嵌入在同一网络元件中。

分类器(CF)是通过将业务分组和/或流与策略进行匹配来执行分类以便随后应用所需的网络服务功能集的元件。

服务功能转发器(SFF)负责根据SFC封装中携带的信息将业务转发到一个或多个连接的服务功能以及处理从SF返回的业务。此外，SFF负责在需要和支持时将业务传送到分类器、将业务传输到另一SFF(在相同或不同类型的域中)、以及终止SFC路径。

SFC可以使用特定的SFC封装，例如IETF草案“网络服务报头”[https://tools.ietf.org/html/draft-quinn-sfc-nsh-07]中所述的网络服务报头(NSH)，以便携带SFC相关信息。NSH携带的信息的一些示例包括SFC路径ID、分组在SFC链中的位置(也称为服务索引或SFC索引)、以及可能用于沿路径的特定SF实例的一些元数据。通过可以根据SFC路径ID和NSH中指示的位置(SFC索引)来确定下一个SF或转发器的SFF将分组迭代地转发到预期的SF。当SSF接收到分组时，除了相应地处理分组(例如在防火墙的情况下应用过滤规则)之外，它还可以通过使用用于链中的后续转发器或SF的特定元数据来向NSH添加一些上下文信息。在遍历整个链之后但在离开域之前，最终转发元件负责处理NSH分组，这可以包括移除任何上下文SFC信息。

安全服务功能(SSF)是一种通常采用跨不同管理域实例化的路径上服务的形式以便能够检测和缓解安全威胁的服务功能(SF)。例如，假设在虚拟数据中心(VDC)内的云中实例化了服务。业务由因特网服务提供者(ISP)传送到云，然后由云提供者传送到VDC，最后传送到终端服务器。在其路径上，每个域都可以实例化并供应可能旨在解决类似威胁的SSF。由于这些SSF均独立行动，它们可能不共享相同级别的信息/检测，并且可能需要在每个域内过度供应(over-provision)。

使这些SSF协作能够提供一些潜在的益处。第一个方面是检测，因为VDC是可以更好地用于以非侵入方式检测特定于应用或服务的攻击以及DDoS攻击的域。然后，VDC可以通知其他SSF关于正在进行的攻击，使得受其影响的所有SSF都可以实时从最准确的安全信息受益。同样，这种协作可以带来更好的缓解，因为VDC可能更加能够定义缓解策略并在本地或通过将此任务外包给攻击路径上的其他SSF来实现该策略。在SSF之间交换准确信息的自然结果是改善了资源使用，因为每个域能够将精力集中在特定任务上。

例如，不是让ISP及其客户端都试图检测和缓解DDoS攻击，而是后者可以专注于检测而前者可以集中于缓解。客户端更适合仔细评估入站业务，因为分组可能被加密，并且攻击可能与正在执行的应用本质上相关。相比之下，ISP更接近攻击源，因此它可以在恶意业务变得过大并且影响ISP和客户端两者的基础设施之前对恶意业务进行过滤。此外，该方法还可以允许在每个域上实例化的不同SSF之间共享检测/缓解负载，而不是在两个域中产生SSF重复。即使协作的范围是单个域，也能够实现资源使用优化机会。过载的虚拟机(VM)可以将一些任务卸载到具有空闲资源的另一VM。然后，可以在创建新实例之前最大限度地使用已供应的VM，从而最小化对VM的按需(而非保留)分配的需求。域之间和域内的这种协作资源共享能够提高安全即服务(SECaaS)系统的可伸缩性。

软件定义网络(SDN)允许管理员通过解耦系统，借助高级功能的抽象来管理网络服务，该系统做出关于从将业务向其目的地(例如数据平面)转发的底层系统将业务发送到何处(例如控制平面)的决策。SDN可用于促进域之间可能的交互，因为SDN范例提供借助标准化应用编程接口(API)创建和部署所需(协作)缓解软件。传统的协作方法侧重于处理来自不同管理域(例如通常是ISP和客户网络)的协作者，从而允许将安全功能外包到上游域以及处理DDoS。

本领域技术人员将理解，服务功能链和SDN的概念可以与网络功能虚拟化(NFV)共存，NFV是使用虚拟化技术将整个类别的网络节点功能虚拟化成构建块的网络架构概念，所述构建块连接或链接在一起以创建通信服务。

本公开的实施例涉及一种包括以下方面的协作框架。首先，它能够实现不同管理域(例如云和云朵)内或之间的SSF之间的协作。如果认为有必要，它使能按需供应新SSF实例，从而在云中提供更好的安全性和资源使用。其次，这些实例可以与以下项相关联：(1)不同的SSF类型，在这种情况下，协作可以包括请求特定功能；或者(2)相同的SSF类型，其中协作可以包括外包一小部分负载，即，每个新协作者可以在有限时间量内将有限资源量专用于该任务。因此，协作被视为关于用于给定SSF的专用资源的约定，从而允许在(可能不是完全可信的)自治系统之间建立临时合作。协作可以处于“尽力而为”模式，即每当执行外包任务所需的资源量达到约定的阈值时，不执行该任务，并且标记任何未处理的分组以便稍后处理它们。此模式可用于鼓励协作，因为它增加了系统的灵活性，并能够防止资源耗尽或资源劫持等不良情况。

图1示出了根据本公开实施例的多域安全性的概述。图1示出了由具有四个SSF的链保护的web(网络)服务器114的示例场景。SSF4 112是在VDC 108上用web服务器114托管的web应用防火墙(WAF)。SSF3 110是位于VDC 108的入口点的网关防火墙。SSF2 106是放置在云104的入口点处的防火墙。SSF1 102的几个实例(云朵100防火墙)托管在ISP的域中，并因此靠近web服务器114的客户端。虽然实际上可以存在多个云朵100以在恶意业务到达云之前过滤恶意业务，但是为了简化说明，对于该示例，SSF1 102将被称为单个SSF。在这种情况下协作的目的包括：(1)尽可能靠近源来缓解DDoS攻击，使得它们的总体影响(例如在合法分组的延迟和丢弃率方面)保持最小；(2)通过避免传送稍后将丢弃的分组来降低基础设施成本，使得能够相应地确定每个SSF的尺寸；以及(3)通过使不同域能够共享这些活动的资源(例如由WAF提供的信息可能触发云朵上的缓解任务)，使检测和缓解任务动态和快速进行。

对于图1的场景，将假设所有SSF防火墙102、106、100、112的尺寸为100σ，其中σ表示计算资源(或带宽)的通用度量。假设在某个时间点，SSF用于处理其自身安全任务的资源使用为50σ。然后，由于DDoS攻击，SSF1 102和SSF4 112处的资源使用都上升到80σ。出于相同原因，如果SSF2 106和SSF3 110继续处理相同的任务，则它们的资源使用将分别变为r55σ和105σ，因为如当前配置的，SSF3 110将最终过滤大多数DDoS业务。在这种情况下，SSF3110中的队列将持续增长，从而增大等待时间，直到其缓冲区已满并且分组开始被丢弃。处理该问题的一种方法是创建SSF3 110的第二实例并将两个SSF3 110实例均附加到负载平衡器。使用多域协作解决方案，另一种方法是考虑SSF3 110是否可以简单地将某些任务(例如取25σ)卸载到SSF2 106。SSF2 106和SSF3 110都将以80σ的资源使用结束，从而保持QoS而没有任何额外实例供应。

在稍后的时间点，在DDoS攻击受到控制之后，攻击模式可能改变并且开始包括仅由安装在SSF4 112处的规则过滤的分组。这将对应过滤任务τ的资源使用从0σ提高到30σ。因此，SSF4的112总资源使用变为110σ。不幸的是，SSF4 112无法将整个任务卸载到任何其他防火墙，因为这只会改变问题的位置。然而，它可以与一些防火墙实例协作，以用于以“尽力而为”的方式共享对应的负载。例如，如果τ在任何位置执行时都将采用相同的资源量，则SSF4 112可以要求SSF3 110和SSF2 106均在该任务上投资10σ，因此SSF4 112、SSF3 110和SSF2 106上的负载将是90σ。然而，在SSF2 106处仅用10σ运行τ可能不如在SSF4 112中那样有效，因为SSF2 106处的业务量更高。在SSF4 112中，τ仅在未被SSF3 110或SSF2 106的任务过滤的分组上运行，而SSF2 106看到τ必须被应用到的分组的完整负载。因此，可能需要某种协商机制来决定合理的工作负载划分，以确保没有单个防火墙实例过载。

可能存在卸载和尽力而为共享负载都不可行的情况，因此应该实例化新的SSF以避免升级现有机器(例如垂直缩放)。即使在这种情况下，多域协作方法也能够提供比仅使用负载平衡更大的灵活性，因为添加到链中的新实例不一定需要是某些现有SSF的精确副本。因此，可能可以进行一些优化。例如，新的SSF实例可以放置在链的开头，并成为能够过滤许多分组(最好是几乎没有处理)的被卸载任务的目标，从而减少网络的总体负载。另外或备选地，用于新SSF实例的资源分配可以根据新SSF实例将执行的任务(例如使新SSF实例更加面向处理或存储器)来优化。

“协作”安全解决方案概念的传统方法倾向依赖于具有网络全局视图的中央控制器。该控制器负责协调安全模块之间的任何协作，在不同网络节点上部署所需的SSF，以避免拥塞或将流重新路由到具有足够资源和所需功能的路径。另外，考虑到在控制器自己的域内引发的警报，来自不同域的控制器(例如基于SDN的控制器)也可以合作以定义针对DDoS攻击的策略。例如，可以为检测到的可疑流定义单独的数据路径(例如使用VLAN标签)，从而在该路径中包括可疑流分析所需的所有SSF。本公开的实施例可以包括类似的考虑因素，但是还考虑路径中的SSF上的负载，并且如果需要则供应新的实例。此外，传统解决方案中的元素之间的任何协作通常都是“全有或全无”的，因为匹配给定安全策略的所有业务必须由已同意执行给定任务的节点来处理。这在某些情况下可能足够，但是图1的示例说明，与“尽力而为”方法相比，这在资源使用方面可能不一定是最佳的。

在没有集中控制器的解决方案中，当检测到拥塞时，节点可以自主向其上游邻居(即，更接近分组源的节点)发送SSF请求并且假设它们能够满足该请求(例如应用例如速率限制策略)。还可以考虑混合方法，其中路径中的节点是自治的，但是可以由中央控制器动态地重组以更好地过滤业务。这些方法可以依赖于中央协调器或让SSF直接协作。

节点之间的资源协商是协作系统的另一方面，因为通常需要确保在实际外包服务之前能够可靠地外包服务，即使是临时的。一些方法允许节点基于其资源可用性拒绝服务部署请求。在其他情况下，启动外包的节点可以在发送确定性的路由部署请求之前向其中央控制器发送资源分配请求。如已经讨论的，一些实施例还可以包括在有限的时间段内以尽力而为的方式外包服务的可能性。

根据一些实施例，可以定义可以协作的SSF的类别，以及将要由每个类别提供的对应服务。尽管术语“SSF”用于指定通用安全元素，但SSF可以在以下示例类中进行分组。

路径上SSF：可以在路径上的各个位置例如防火墙中执行的服务、电子邮件附件分析、DDoS缓解。例如，防火墙通常位于各种域的边界处以及域内。然而，在某些情况下，这种SSF可能必须在特定的端点执行(例如当端到端加密就位时)。

端点SSF：在网络的端点处执行的服务，其可以包括例如标记化或身份管理。如果SSF的任务(在被外包时)必须由目标SSF实例完整处理，则SSF可被归类为端点SSF。

位置相关的SSF：必须在特定位置执行的服务。示例包括必须放置在隧道末端的加密器，以及保护域边缘的边缘防火墙。类似地，如果还需要通过端点进行解密，则基于加密内容(例如HTTP或任何应用层内容)的SSF可以是位置相关的。注意，该类别没有考虑物理约束(例如网络中特定硬件的位置)施加于位置的情况。

根据一些实施例，还可以定义协作中涉及的属性集。请求和接受协作的SSF将分别称为“发起者”和“提供者”。发起者可以向潜在提供者发送协作协议(CA)请求。这样的请求可以包含不同的CA提议，并且每个提议可以包含与可接受的值相关联的不同属性的列表。提供者可以使用CA响应(其中选择了单个提议)回复，并返回具有所选值的每个属性。在一些实施例中，这些属性中的一些属性可以是强制性的，而其他属性则可以是可选的。协商的属性的一些示例可以包括：

ID：以标识CA。

缔约方：以标识发起者和提供者，例如通过IP地址、完全限定域名(FQDN)或证书等。

模式：以定义各方之间的协作类型，包括完全卸载或尽力而为等。

目标SSF：以在协作范围内指定一种SSF。

期满时间：以指示CA的寿命。

取决于用例，可能需要附加属性。例如，如果同意协作的SSF实例需要进一步配置(例如由两个不同防火墙处理的规则)，则可以包括协作信道参数。这些属性还可以包括要使用的协议，并最终提供用于相互认证的票据。

在尽力协作的场景中(其中不期望提供者处理所有分组)，CA可以包括指示资源和数据路径的两个附加属性。资源属性可以指定提供者专用于协作的资源量，这使SSF能够协商并限制其贡献的资源量。然后，可以通过“标准路径”引导由提供者处理的分组，而未处理的分组则应该经过“备用路径”。然后，可以使用数据路径属性来指定在发起者和提供者之间如何引导业务，从而定义那些不同的路径。实际上，标准路径和备用路径可以采用多种形式(逻辑的和/或物理的)。例如，当协作涉及两个独立管理域(例如云和云朵)时，这些路径可以由配置有不同密钥的不同VXLAN或GRE隧道表示，或者由具有不同安全参数索引(SPI)的两个不同IPsec隧道表示以用于互连域。在这种情况下，发起者和提供者可以进一步就隧道的类型及其相关联的ID和/或密钥达成一致。相比之下，当协作保持在单个管理域中时，不需要此类隧道。在这种情况下，标准路径和备用路径可以由两个不同的SFC路径表示，每个路径都有自己的特定SFC路径ID，或者备选地，这种情况可以利用SFC的封装机制，如下所述。

这些属性的描述应仅被视为是非限制性示例。CA中的参数可以以各种方式表示，例如各种计算资源(例如CPU、存储器、I/O和/或带宽)的组合。如有必要，可以详细说明更具体的属性。

接下来将描述用于在来自云和云朵的SSF实例之间提供协作的架构概述。假设来自每个域的安全协调器可以参与协作以在SSF发起者和SSF提供者之间建立CA。协调器可以提供对SFC背后的逻辑的全面理解，以及SFC的全局视图，以帮助定义提供者应插入链中的位置并评估为此任务实例化新SSF的潜在需求。在域之间设置协作可能还需要一些管理权限。

图2示出了包括两个独立域(云朵100和云104)的域间协作架构。假设每个域中的SSF由服务功能链(SFC)架构管理，所述架构包括例如SDN控制器以用于引导分组业务通过一组SSF实例。提供多个转发元件118a-e以用于路由SFC业务。在该示例中，SSF发起者120位于云104中，并向云协调器122发送与给定SSF类型协作的请求。当SSF发起者120识别出例如其自己的资源接近耗尽时，可以触发协作请求。云协调器122评估SSF提供者实例是否可以在其自己的域中实例化，或者提供者是否应该在另一域(例如更下游)中实例化。

对于图2的示例，云协调器122请求云朵的协调器124与云朵100中的SSF实例建立协作，使得该实例可以充当“提供者”。如已经讨论的，这样的请求可以导致云104和云朵100之间的CA的协商。这可以导致：(1)来自云朵的SSF实例126被选为提供者；(2)云和云朵通过标准路径和备用路径互连；(3)云进行内部配置，以确保只有来自备用路径的业务才经过SSF发起者。

在云和云朵中的域间备用路径及其对应的域内备用路径在图2中用虚线表示。实际上，云和云朵之间的互连通常可以用不同的VXLAN、GRE或IPsec隧道来实现。其中一个隧道被配置用于“标准路径”，其传送已经由SSF提供者102处理的分组。另一隧道被配置“备用路径”，其携带未处理的业务。云域104中的分类器元件可以区分两种类型的业务(已处理与未处理)，而不需要来自云朵的SFC的任何内部信息。换句话说，每个SFC负责在域间标准路径和对应的域内标准路径之间执行适当的绑定。这同样适用于备用路径。

在图2中，例如云朵100中的最终(例如出口)转发元件118b负责将业务从云朵的标准路径引导到域间标准路径。类似地，云104中的分类器元件和/或第一(例如入口)转发元件118c负责将业务从域间标准和备用路径引导到云104内的适当SFC路径。应当理解，图2的示例没有明确地将分类和转发功能示为单独的个体元件。

出于解释的目的，图2未示出SFC中的所有SSF实例或其他非安全服务功能，仅示出SSF发起者120和SSF提供者126。注意，备用路径的定义只涉及这两个SSF实例，因为它们是参与协作的仅有的元件。如果业务被引导到云中的多个不同SF，则备用和标准路径业务也将经过所有这些SF(只有SSF发起者120除外)。

在配置期间，取决于各种因素，云朵协调器124可以决定重用现有SSF实例或者为SSF提供者126创建新实例。如果需要创建新的SSF实例，则拥有动态更新网络配置和分配资源的权限可能是不够的。这种类型的操作还可能需要了解要应用于业务的有序服务链，因为每类SSF可能有不同的要求。例如，如果链包含加密SSF和防火墙SSF，则可能需要在加密发生之前放置防火墙。

图3示出了单个管理域内的域内协作架构。类似于图2，引导分组业务通过域内的一组SSF实例136a-c。在接收到分组业务时，分类器元件CF 130可以在该示例中经由转发元件SFF 132a-c为业务选择适当的SFC路径。

图3中所示的SFC控制平面使协调器138能够动态地更新SFC架构。举例来说，协调器可以使用接口C1经由分类器130将业务引导到不同路径。接口C2可以用于修改业务被引导到的下一跳，或者在最终转发器SFF 134上用于管理如何移除NSH信息并将分组转发到另一域。接口C3可用于更新SSF实例136a-c。

为了在协商CA之后使协作能够发生，协调器138可以继续以下动作：(1)将(可能新实例化的)提供者插入到现有的SFC路径中；(2)设置内部信令以区分备用路径和标准路径(例如使用NSH上下文元数据)；以及(3)更新最终转发元件134，使得出站分组被适当地重定向到域间备用路径或域间标准路径。

图4示出了用于将新SSF提供者150插入SFC路径的三个示例实施例，该SFC路径包括分类器CF 140、转发器(SFF1 142、SFF2 144、SFF3 146、SFF4 148)和SSF发起者152。在图4a中，创建包括SSF提供者150和先前SFC路径的所有SFF和SF实例(包括SSF发起者152)的新SFC路径(称为该示例的“提供者路径”)。在这种情况下，分类器140使用此新路径而不是原始路径，因此可以简单地删除原始路径。

在图4b所示的被称为“分支”的方法中，仅重新配置负责将业务引导到SSF提供者150的转发元件SFF1 142，因此它简单地将该新的SSF 150视为已经存在的路径的一部分。更具体地，SFF1 142可以嵌入两个类分类器元件(CE)，它们(类似于双网络地址转换(NAT)设备)能够更新所有入站分组的SFC路径ID和索引，以便将业务从原始路径引导到SSF提供者150，然后当这些分组从SSF提供者150返回时再次回到初始路径。

图4c示出了组合图4a和4b的替代方案的“混合方法”。在这种情况下，创建包括除了发起者SSF 152之外的原始路径的所有SSF的提供者路径，并且链的所有业务被导向该新路径。然后，每当SSF提供者150未处理业务时，SFF1 142中嵌入的为SSF提供者负责的分类器元件(CE)就可以将业务从提供者路径引导到原始路径，从而使原始路径成为“备用路径”。

图4a的方法是最直接的实现，因为它仅需要为协作机制提供足够的权限来创建新的SFC路径。在该实施例中，发起者SSF 512仍将接收所有业务并且可以确定业务是否已被处理。图4b的方法需要所采用的特定SFC实现的支持。但是，它可能会导致较低的配置开销，因为只有一个转发元件(SFF1 142)受影响。与替代方案相比，预期图4c的方法减少了经过发起者SSF 152的业务量。

在所有三个示例情况中，提供者SSF 150可以指示业务是否已被处理，从而允许适当的分组遍历“备用路径”。在一些实施例中，这可以通过在分组的NSH报头中设置特定元数据来实现。在图4a和4b中，该信息用于发起者SSF 152，其可以通过处理或简单地转发分组而相应地执行动作。在图4c的混合方法中，该信息旨在用于转发器(SFF1 142)中嵌入的分类器元件，该分类器元件负责将来自SSF提供者150的业务引导到适当的SFC路径。注意，利用图4a和4b的方法，备用路径和标准路径被复用到相同的SFC路径中。相反，在图4c中，隔离了备用路径和标准路径。

云协调器可以根据同意CA的结果来实现以下动作：(1)更新其分类器以考虑域间备用路径和域间标准路径；以及(2)内部地处理备用和标准业务。

在这种情况下更新分类器可以包括将分类器配置为处理用于已处理业务和未处理业务的两个不同隧道。要区分两个隧道，可以配置具有不同SFC ID的两个不同路径。虽然云朵需要将所有入站业务引导到提供者SSF(因此提供者SSF可以决定是否对其进行处理)，但云域不必将所有业务引导到发起者SSF。创建两个不同的SFC路径可以避免将SFC元数据中的备用路径信息传送到发起者SSF(然后发起者SSF必须读取和分析对应的元数据，从而导致不必要的开销)的需要。

建立备用路径的概念(例如通过建立第二SFC路径)是本文描述的一些实施例的特征。当SSF具有用于其出站业务的备用路径时，则该SSF未处理的任何业务都将转发到该备用路径。此参数可以帮助鼓励SSF进行协作，因为它们可以就有限量的资源达成一致，以在有限的时间内为任务做出贡献。任何需要额外资源的任务都将被简单地转发到备用路径。如前所述，SSF可以将其协作模式定义为尽力而为。实际上，这意味着可能无法处理一部分入站业务。

为了支持尽力而为模式，提供者SSF应能够指示是否已经处理了入站分组。该指示的动机是防止SSF多次处理相同的分组。利用这种机制，提供者SSF能够控制其自己的在协作中使用的资源。

应当注意，建立备用路径不包括在所有实施例中，而是当存在未处理的业务和/或未处理的业务应该具有与已处理的业务不同的处理时可以采用备用路径。当存在未处理的业务时，这意味着SSF正在以尽力而为(或类似)模式工作。在备选示例中，当提供者SSF处理所有业务时，不需要设置备用路径，因为所有业务将被处理。在提供者SSF放置在发起者SSF之前(在服务链中)的情况下，可以配置备用路径，以使得由提供者SSF处理的分组可以旁路发起者SSF。

当在两个SSF之间设置备用路径时，SSF的顺序可以是重要的。更具体地，当提供者SSF被放置在发起者SSF之前时，该备用路径使提供者SSF能够向发起者SSF指示分组尚未被处理。在另一种情况下，当发起者SSF位于提供者SSF之前时，可以设置备用路径，使得发起者SSF向提供者SSF指示分组已处理/未处理。因此，备用路径的定义可以取决于SSF的顺序。发起者SSF或安全协调器可以确定并指示哪个SSF应该放在另一SSF之前。

备用路径概念可以以各种方式实现。在一些实施例中，可以将特定元数据添加到分组的NSH报头中。在这种情况下，已处理的和未处理的业务可能会遵循完全相同的SFC路径。已处理的和未处理的业务之间的唯一区别将是此元数据的值。这可以视为将备用路径和标准路径复用成一个SFC路径。备选地，可以为备用路径创建特定的SFC路径(具有其自己的特定SFC路径ID/索引)。在这种情况下，所创建的SFC路径将仅携带未处理的分组。

本领域技术人员将理解，例如通过包括多个比特，可以容易地扩展该元数据或报头信息以指示与多个服务/功能相关的分组的已处理/未处理状态。

图5示出了如何通过分支来更新SFC数据平面以实现两个SSF之间的协作的另一示例。将使用来自图4的相同示例SFC，包括分类器CF 140和转发器SSF 1-4 142/144/146/148。假设SSF提供者150和SSF发起者152都驻留在单个域中，并且单个SFC控制平面可以执行配置。

图5a示出了在添加SSF提供者150之前的初始SFC数据路径。图5b示出了使初始路径产生分支以将SSF提供者150添加到SFC数据路径的实施例。分支可以包括创建从初始路径分支到SSF提供者150的特定环路。注意，在图5b的示例中，仅添加了一个新的SSF提供者，尽管这可以扩展为包括在新的分支链中链接在一起的几个SSF。

在图5b的一个实施例中，所有业务被引导通过SSF提供者150和SSF发起者152。这意味着所有分组将由这两个实例分析/处理。构建这样的单个路径需要将SSF提供者150添加到现有的SFC路径中。这可以通过组合不同的独立SFC或通过重新定义在新路径创建中定义的新SFC来完成。因为所有业务都被引导到两个实例并不意味着无法定义协作或备用路径。相反，可以通过由SSF 150/152分析的元数据来指示备用路径。

为了将SSF提供者150添加到路径中，SFC控制平面可以创建仅去往SSF提供者150的新SFC路径。在路径分支出的点处，分类器元件(CE)的两个新实例154/156可以添加到链中。这两个新的CE元件154/156确定业务在初始路径和新路径之间的来回切换。可以通过在标识SFC路径的SFC ID与指示每个相应路径中的位置的SFC索引之间切换来实现这些路径之间的切换。在一些实施例中，CE或SFF元件可以存储初始SFC路径与新SFC路径标识符之间的映射或关联。

在一个实施例中，入口CE 154可以将SFC INITIAL_PATH ID切换成SFC NEW_PATHID。此外，SFC NEW_PATH位置(索引)也可以被重新初始化。通常，SFC索引的初始值是255，并且当分组遍历SFC时索引值递减。但是，控制平面可以根据需要配置SFC索引值。出口CE 156相反地执行，其中SFC NEW_PATH ID被切换回SFC INITIAL_PATH并且SFC索引被切换回初始SFC索引值。本质上，分支拦截当前SFC路径ID，将其从INITIAL_PATH重新分类为NEW_PATH，以便将业务引导到SSF提供者150，然后再次将业务从NEW_PATH重新分类到INITIAL_PATH，以通过剩余的初始SFC路径引导回业务。注意，SSF提供者150的插入应当考虑其中分配不同的SF以处理业务的服务链顺序。

图6是示出用于在类似于关于图5所描述的单个域协作内添加新SSF实例的方法的流程图。在所有业务在单个路径上被引导的情况下，所有业务通过同一组SF。路径本身可以是单个SFC路径，也可以由多个SFC路径组成，如分支的情况那样。然而，在该实施例中，一旦新添加的SSF提供者处理了分组，输出分组将不会旁路链中的任何后续服务。

该方法开始于确定相对于初始SFC路径在何处插入SSF提供者的新实例(框200)。这可以包括验证SSF提供者的创建/添加是否符合初始SFC路径中的预定义服务功能顺序。还可以创建和配置用于新SSF提供者的入口和出口分类器元件(框210)。创建并配置与SSF提供者相关联的新SFC路径(框220)。这可以包括定义与SSF提供者相关联的新SFC路径ID和SFC索引。然后，入口分类器元件将入站业务从初始SFC路径切换或重新分类到新SFC路径，以将业务转发到SSF提供者(框230)。这可以包括用新的SFC路径ID/索引替换分组中的初始SFC路径ID/索引。

然后，SSF提供者可以可选地(例如根据协作协议)在业务上应用其服务功能，并将任何已服务的分组标记为“已处理”(框240)。然后，出口分类器元件例如通过用初始SFC路径ID/索引替换分组中的新SFC路径ID/索引，将业务从新SFC路径切换或重新分类回初始SFC路径(框250)。相应地，业务沿着初始SFC路径转发并朝向SSF发起者。在分组未被标记为“已处理”的情况下，SSF发起者可以应用其服务功能(框260)。如果分组被标记为“已处理”，则SSF发起者可以简单地传递分组并将其转发到SFC路径中的下一个目的地。

在图6的实施例中，只有SSF提供者未处理的分组将由SSF发起者处理，反之亦然。由于所有业务必须通过所有功能，因此不同的路径不能由SFC转发元件(SFF)处理，而是由SSF实例本身处理。SSF提供者可以向SSF发起者指示分组是否已被处理，并且由于该信息仅由SSF发起者考虑，因此SFC转发元件不受影响。在一些实施例中，SSF提供者可以通过在报头中设置一些元数据来向SSF发起者指定已经处理了分组。注意，在该示例中，这样的元数据将指定分组是否已被SSF提供者处理，但是这可以被概括和扩展，例如如果要求SSF提供者提供更大的信息集。

利用NSH报头，如果NSH MD是类型1，则可以在强制上下文报头中携带元数据，或者如果NSH MD是类型2，则可以在任何可选的元数据字段中携带元数据。这种元数据的使用不会影响SFC数据平面配置但可能造成一些操作成本，因为必须由SSF为分组提取和/或插入元数据。这可以通过将流引导到不同的独立路径来避免，这显然会影响SFC数据平面配置。

图7示出了使用备用路径以便实现属于单个域的两个SSF之间的协作的示例。图7a示出了业务被同时引导到两个不同SFC路径中并且每个SFC路径具有恰好一个SSF实例的示例情况。在该实施例中，SSF提供者150和SSF发起者152永远不会在相同的SFC路径上。在这种情况下，SFC数据平面被配置为使得业务仅由一个SSF实例处理，并且当由一个SSF处理时，它不影响另一SSF。分类器140可以将入站业务引导到要由SSF提供者150或SSF发起者152处理的SFC路径之一。

图7b示出了所有入站业务被引导到SSF提供者150的示例情况。如所讨论的，SSF提供者150可能能够或可能不能够处理所有分组业务。因此，它可能将分组标记为已处理或未处理。添加与SFF1 142和SSF提供者150相关联的分类器元件CE 158，以将业务引导到SFC路径之间。分类器元件CE 158可以将已经由SSF提供者处理的业务重新分类到备用SFC路径，从而旁路SSF发起者152。在该实施例中，未被SSF提供者150处理的业务将保留在初始SFC路径上并被转发到SSF发起者152实例。

图7c示出了另一变型，其中所有入站业务仍然被定向到SSF提供者150，然而，分类器元件CE 160被添加在与SFF3 146和SSF发起者152相关联的不同位置。SSF提供者150可以将分组标记为已处理或未处理。在该实施例中，所有业务沿着初始SFC路径被引导到SFF3146。分类器元件CE 160确定分组是否已被处理。已处理的分组被重新分类到备用SFC路径，而未处理的分组保留在初始SFC路径上并且被转发到SSF发起者152实例。

本领域技术人员将理解，在图7的示例实施例中，备用SFC路径遍历与初始SFC路径相同的转发元件(例如SFF1-4 142/144/146/148)。举例来说，在图7b中，经分类器元件CF158分类后，已处理的和未处理的业务都被引导至SFF2 144、SFF3 146和SFF4 148。在其他实施例中，备用SFC路径可引导已处理的分组通过整个路线，例如直接引导到SFF4 148，只要考虑SFC中的顺序和其他功能即可。

在先前的示例中，SFC数据平面被配置为通过单个SFC控制平面来简化SSF之间的协作。其他实施例将考虑SSF提供者和SSF发起者在两个不同域中的情况。每个域都可以拥有自己的SFC控制平面。因此，协作可能需要两个SFC控制平面就某些参数达成一致以实现协作。

以下的示例性实施例将考虑第一域(例如云)请求第二域(例如云朵)来实例化SSF提供者的新实例的情况。可能不允许云域例如通过引导业务经过一个或多个路径来定义云朵域如何组织自身。在该场景中，假设云朵实施NSH以指示是否已处理业务。假设在云朵域中的SSF提供者插入可以遵循单个域内的协作，如先前详细描述的那样。SFC数据平面更新可以由SFC控制平面完成。类似地，还假设云域实现NSH，并且SFC数据平面的所有修改可以由云域的SFC控制平面完成。

SFC控制平面可能无法处理云与云朵之间的协议。相反，每个域都可以与负责处理云和云朵之间的协作协议的安全协调器相关联。SFC控制平面可能仅代表安全协调器的一个接口。例如，它还可以负责管理域内的资源、实例化VM、为SSF提供者确定最合适的位置、决定启动协作等等。云和云朵可能需要确定并约定它们如何互相连接。出于协作的目的，这可以包括云朵将如何向云指示业务的特性，包括业务是否已由SSF提供者处理。

图8示出了多域协作的示例。图8a示出了当使用单个路径将来自云朵300的业务引导到云310时的示例实施例。作为用于互连的单个路径，可以在两个域之间交换元数据。图8a示出了SFC路径的三个不同部分，一个在云朵300中，一个在云310中，以及它们之间的互连。在某些架构中，这可以被视为单个逻辑SFC路径，但在其他架构中，这些SFC路径将保持独立。在某些情况下，可能已经配置了云朵-云互连。在其他情况下，可以使用NSH设置互连以进行协作。可以在云朵300和云310 SFC控制平面之间配置一些属性，例如SFC ID和与备用路径关联的任何元数据。

一旦在云朵300和云310之间就这些属性达成一致，每个域之间涉及的接口包括以下内容。

在云朵300域中，C4接口可用于配置SFC代理306以使用为云朵-云互连定义的SFC路径来适当地转换内部SFC路径。这还可以包括元数据的转换。云朵可能需要将内部元数据格式和值转换成云朵300和云310之间约定的格式。

在云310域中，C1接口可以用于从互连到云310的SFC内部路径的转换。这还可以包括与备用路径相关联的元数据。云310可以将在云310和云朵300之间约定的元数据类型和格式转换成其内部格式和值。

路径可以携带的信息取决于路径本身。例如，如果互连采用NSH，则备用路径信息可以使用NSH元数据。如果互连不使用NSH，而是使用MPLS、GRE等，则可以不将这种信息从云朵300发送到云310。而是可以按隧道分配这种信息。

在图8a的示例中，云朵300中的SFC业务从SFF 302引导到SSF提供者304再到云朵SFC代理306。代理306可以转换云朵300 SFC路径参数，所述参数包括用于云朵-云互连的元数据。在云310域处，代理312可以将所接收的信息转换成云310 SFC路径参数，所述参数包括元数据。然后，业务被引导到SFF 314、SSF发起者316和SFF 318。在一些实施例中，SFF发起者316可以经由分组的元数据确定分组是否已被处理/未被处理，类似于关于图5b描述的单路径实施例。

图8b示出了当云朵-云互连对于已经由云朵300处理的业务和尚未由云朵300处理的业务使用不同路径时的示例实施例。在一些实施例中，不同的路径不一定都是SFC路径。这些路径可以使用其他封装技术，例如GRE、MPLS、IPsec。这些隧道技术中的每一种都有自己的特定标识符，并且这些标识符将被绑定到特定SFC路径。

可能需要在云朵300和云310之间约定一些属性，包括路径的类型(例如备用路径或输出路径)、封装类型(例如NSH、GRE、MPLS、VxLAN)、以及标签ID。一旦在云朵300和云310之间约定了这些属性，则每个域之间涉及的接口包括以下内容。

在云朵300域中，C4接口可以配置SFC代理320以使用为云朵-云互连定义的SFC路径来适当地转换内部SFC路径。这还可以包括元数据的转换。

在云310域中，C1接口可用于从互连到SFC内部路径的转换。这还可以包括与备用路径相关联的元数据。

为了在两个域之间携带关于已处理和未处理的分组的信息，可以向SFC代理元件添加附加功能。从SFC云朵到SFC云创建了两个隧道。每个隧道由SSF提供者304分别专用于已处理或未处理的业务。云朵代理320被配置为读取关于云朵中的备用路径的可选信息、解释该信息、然后将业务导向适当的隧道中。在云310处，代理(CF 322)可以包括类似于本文所述的分类器功能。CF 322可以被配置为确定在哪个隧道上接收分组，并且相应地确定该分组是否已被处理。然后，CF 322可以选择适当的云310SFC路径并相应地设置SFC参数。

注意，在本文描述的一些实施例中，诸如SSF、CF、CE和SFF的各种SFC功能已被图示为单独的实体。应当理解，一个或多个功能模块可以包括在单个物理、虚拟或逻辑节点中。例如，SFC节点可以包括分类器功能、服务功能和转发功能。

图9是示出根据一些实施例的用于使用备用路径实现域间协作的方法的流程图。假设云朵300和云320是两个独立但协作的域。该方法开始于协商云-云朵互连(框330)并在该互连的云端点和云朵端点处均创建/配置代理功能元件(框340和350)。然后，云朵代理开始从云朵中的SFC路径接收业务(框360)。可以从包括SFF功能和SSF功能中的一个或多个的SFC节点接收业务。在一些实施例中，可以从云朵300中的SSF提供者接收业务。

云朵代理元件检查业务中的第一分组以确定该分组是否已被特定服务功能(例如SSF提供者)处理(框370)。在一些实施例中，这可以包括检查由分组携带的NSH报头和/或元数据，其指示服务功能是否已经应用于该分组。云朵代理可以根据正在处理(或未处理)的分组来选择隧道，并在该隧道上转发分组(框380)。

如果分组已被处理，则云朵代理元件将在适当的隧道(例如隧道A)上转发该分组。该分组将由云代理元件经由隧道A接收并相应地处理(框390)。云代理可以插入用于云310域的SFC路径ID和/或索引，并将元数据设置为与隧道A关联的“已处理”。然后，云代理可以将分组导向正确的云SFC路径并根据SFC路径ID/索引转发该分组。

另一方面，如果分组尚未被处理，则云朵代理节点将在第二隧道(例如隧道B)上转发分组，并且分组将由云代理接收(框390)。然后，云代理可以插入用于云310域的SFC路径ID/索引，将元数据设置为“未处理”，并将分组导向与隧道B相关联的适当云SFC路径，并根据SFC路径ID/索引转发分组。

为了进一步说明，图9的示例可被描述为用于在第一域处理分组业务的第一方法和用于在第二域处理分组业务的第二方法。

用于在第一域中处理分组业务的方法可以由如本文所述的云朵域中的代理元件来实现。代理接收第一分组，该分组包括服务已应用指示符。服务已应用指示符可以是由分组携带的NSH报头或其他元数据。根据服务已应用指示符，确定分组是否已被特定服务功能处置或处理。在一些实施例中，一旦确定了分组是否已被处理，就可以从分组中移除服务已应用指示符(诸如NSH报头)。至少部分地基于分组是否已被处理的确定来选择隧道。然后可以封装分组并通过所选隧道向第二域发送所述分组。

用于在第二域中处理分组业务的方法可以由如本文所述的云域中的代理元件来实现。该方法开始于通过隧道从第一域接收分组。代理元件可以将隧道标识符映射到特定类或业务类型。可以根据接收分组的隧道确定分组是否由服务功能(例如在第一域中)处置/处理。至少部分地基于该确定，代理可以向分组添加服务已应用指示符(例如NSH报头)，服务已应用指示符指示该分组是否已被服务功能处理(或未处理)。可以根据分组参数选择第二域中的服务路径，并且将分组发送到所选择的服务路径。

图10是示出根据本文描述的实施例的由SFC节点执行的方法的流程图。SFC节点可以包括服务功能、分类和/或转发功能中的至少一个。

步骤400：接收分组，该分组包括第一SFC路径ID和第一SFC索引。

步骤410：确定是否将第一服务功能应用于该分组。在一些实施例中，可以根据确定第一服务功能是否已经应用于分组来进行应用第一服务功能的确定。可选地，可以根据分组中包括的已处理指示符来进行该确定。可以在元数据或报头字段中携带已处理指示符。在一些实施例中，SFC节点可以确定第一服务功能是否已经由SFC路径中的服务功能的先前实例应用于分组。

在一些实施例中，可以根据协作协议来确定是否将第一服务功能应用于分组。协作协议可以定义SFC节点将专用/分配/使用以用于应用第一服务功能的资源量(例如阈值)。资源量可以指SFC节点使用的计算资源(例如CPU、存储器)和/或要由SFC节点处理的业务的带宽。

在一些实施例中，可以根据接收分组的隧道来确定是否将第一服务功能应用于分组。

步骤420(可选)：根据应用第一服务功能在分组中设置已处理指示符。在SFC节点将第一服务功能应用于分组的实施例中，SFC节点可以在分组中设置指示已经应用了服务的标志/字段/指示符。已处理指示符可以存储在元数据中或特定的报头字段中，例如存储在NSH中。

步骤430：响应于确定分组已被第一服务功能处理，选择与第一SFC路径ID和第一SFC索引相关联的第二SFC路径ID和第二SFC索引。可以检查已处理指示符以确定该分组已经应用了服务功能。在一些实施例中，第二SFC路径ID对应于与第一SFC路径相关联的备用SFC路径。在一些实施例中，选择第二SFC路径ID和第二SFC索引，以使得分组将旁路第一SFC路径中第一服务功能的后续实例。

在备选实施例中，响应于确定分组尚未被第一服务功能处理(例如根据已处理指示符)，SFC节点可以根据第一SFC路径ID和第一SFC索引转发分组。

步骤440：通过用第二SFC路径ID和第二SFC索引替换第一SFC路径ID和第一SFC索引来修改分组。

步骤450：根据第二SFC路径ID和第二SFC索引转发修改后的分组。在一些实施例中，SFC节点可以根据第二SFC路径ID和第二SFC索引选择用于将分组转发到第二域的隧道，第二域与SFC节点的域不同和/或远离SFC节点的域。

应当理解，上述一个或多个步骤可以同时和/或以不同的顺序执行。而且，以虚线示出的步骤是可选的，并且在一些实施例中可以省略。

图11是示出根据本公开的实施例的示例SFC节点500的框图。SFC节点500可以是本文已经描述的任何元件或节点或其组合。SFC节点500包括包含处理器502、存储器或指令储存库504和通信接口506的电路。通信接口506可以包括至少一个输入端口和至少一个输出端口。存储器504包含能够由处理器502执行的指令，由此网络设备500可操作以执行如本文所述的各种实施例。在一些实施例中，SFC节点500可以包括由底层物理硬件托管的虚拟化组件。SFC节点500可以被配置为实现图1-10中所示的任何方法和过程。

在一些实施例中，SFC节点500可以包括用于(例如经由发射机(Tx)、接收机(Rx)和天线)发送和接收无线信号的收发机510。处理器502执行指令以提供上述由SFC节点500提供的一些或全部功能，存储器504存储由处理器502执行的指令。在一些实施例中，处理器502和存储器504形成处理电路。通信接口506可以包括将信号传送到其他网络组件的网络接口。

处理器502可以包括任何合适的硬件组合以执行指令并且操纵数据以执行SFC节点500的一些或所有所描述的功能，例如上面描述的那些功能。在一些实施例中，处理器502可以包括例如一个或多个计算机、一个或多个中央处理单元(CPU)、一个或多个微处理器、一个或多个专用集成电路(ASIC)、一个或多个现场可编程门阵列(FPGA)和/或其他逻辑。

存储器504通常可操作以存储指令，例如计算机程序、软件、应用和/或能够由处理器执行的其他指令，所述应用包括逻辑、规则、算法、代码、表等中的一个或多个。存储器504的示例包括计算机存储器(例如随机存取存储器(RAM)或只读存储器(ROM))、大容量存储介质(例如硬盘)、可移除存储介质(例如光盘(CD)或者数字视频盘(DVD))、和/或存储信息的任何其他易失性或非易失性、非暂时性计算机可读和/或计算机可执行存储设备。

在一些实施例中，通信接口506通信地耦合到处理器502，并且可以指可操作以接收SFC节点500的输入、从SFC节点500发送输出、执行对输入或输出或两者的适当处理、与其他设备通信，或上述的任何组合的任何合适的设备。通信接口506可以包括适当的硬件(例如端口、调制解调器、网络接口卡等)和软件(包括协议转换和数据处理能力)以通过网络进行通信。

SFC节点500的其他实施例可以包括除了图11中所示的可以负责提供节点功能的某些方面(包括上述任何功能和/或任何附加功能(包括任何支持上述解决方案所必要的功能))的那些组件之外的附加组件。各种不同类型的节点可以包括具有相同物理硬件但是被配置(例如通过编程)以支持不同功能的组件，或者可以表示部分或完全不同的物理组件。

在一些实施例中，节点可以包括被配置为实现本文描述的节点的功能的一系列模块。图12是包括服务功能模块522、分类模块524和转发模块526的示例SFC节点520的框图。

应当理解，各种模块可以实现为硬件和软件的组合，例如图11中所示的SFC节点500的处理器502、存储器504和/或通信接口506。一些实施例还可以包括附加模块以支持附加的和/或可选的功能。

节点520可以被配置为实现图1-10中所示的方法和过程。服务功能模块522被配置为接收分组，确定是否将第一服务功能应用于分组，以及根据应用第一服务功能在分组中设置已处理指示符。分类模块524被配置为通过响应于确定分组已被第一服务功能处理而修改分组的SFC路径ID和SFC索引来对分组进行分类。转发模块526被配置为根据分组的修改后的SFC路径ID和SFC索引来转发分组。

本发明的实施例可以表示为存储在机器可读介质(也称为计算机可读介质、处理器可读介质或具有在其中体现的计算机可读程序代码的计算机可用介质)中的软件产品。非暂时性机器可读介质可以是任何合适的有形介质，包括性、光或电存储介质，其中包括磁盘、光盘只读存储器(CD-ROM)、数字通用光盘只读存储器(DVD-ROM)存储设备(易失性或非易失性)或类似的存储机制。机器可读介质可以包含各种指令集、代码序列、配置信息或其他数据，其在被执行时使处理器执行根据本发明实施例的方法中的步骤。本领域普通技术人员将理解，实现所描述的发明所必需的其他指令和操作也可以存储在机器可读介质上。从机器可读介质运行的软件可以与电路接口以执行所描述的任务。

如本文所使用的，诸如“第一”、“第二”、“顶部”和“底部”等的关系术语可以仅用于将一个实体或元件与另一实体或元件区分开，而不必要求或暗示此类实体或元件之间存在任何物理或逻辑关系或顺序。本文使用的术语仅用于描述特定实施例的目的，并不旨在限制本文描述的概念。如本文所使用的，单数形式“一”、“一个”和“该”也旨在包括复数形式，除非上下文另有明确说明。将进一步理解，术语“包括”和/或“包含”在本文中使用时，指定存在所声明的特征、整数、步骤、操作、元件和/或组件，但是不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组合。

本发明的上述实施例仅旨在作为示例。在不脱离本发明的范围的情况下，本领域技术人员可以对特定实施例进行改变、修改和变化，本发明的范围仅由所附权利要求限定。

Claims (23)

1.一种在服务功能链SFC节点处的方法，包括：

接收包括第一SFC路径标识符ID和第一SFC索引的分组；

确定是否将第一服务功能应用于所述分组；

根据将所述第一服务功能应用于所述分组，在所述分组中设置已处理指示符；

响应于确定所述分组已由所述第一服务功能处理，选择与所述第一SFC路径ID和所述第一SFC索引关联的第二SFC路径ID和第二SFC索引；

通过用所述第二SFC路径ID和所述第二SFC索引替换所述第一SFC路径ID和所述第一SFC索引来修改所述分组；以及

根据所述第二SFC路径ID和所述第二SFC索引来转发修改后的分组。

2.根据权利要求1所述的方法，还包括：根据确定所述第一服务功能是否已被应用于所述分组，确定是否将所述第一服务功能应用于所述分组。

3.根据权利要求2所述的方法，还包括：根据所述分组中的所述已处理指示符，确定所述第一服务功能是否已被应用于所述分组。

4.根据权利要求1所述的方法，还包括：根据协作协议，确定是否将所述第一服务功能应用于所述分组。

5.根据权利要求4所述的方法，其中，所述协作协议定义所述SFC节点已分配用于应用所述第一服务功能的资源量和所述SFC节点将所述第一服务功能所应用到的业务的带宽中的至少一者。

6.根据权利要求1所述的方法，还包括：根据接收所述分组的隧道，确定是否将所述第一服务功能应用于所述分组。

7.根据权利要求1所述的方法，其中，所述已处理指示符作为元数据被存储在所述分组中。

8.根据权利要求1所述的方法，其中，所述已处理指示符是网络服务报头中的字段。

9.根据权利要求1所述的方法，还包括：响应于确定所述分组尚未被所述第一服务功能处理，根据第一SFC路径ID和第一SFC索引转发所述分组。

10.根据权利要求1所述的方法，其中，所述第二SFC路径ID和所述第二SFC索引被选择以旁路所述第一SFC路径中所述第一服务功能的后续实例。

11.根据权利要求1所述的方法，还包括：根据所述第二SFC路径ID和所述第二SFC索引，选择用于将所述分组转发到第二域的隧道。

12.一种服务功能链SFC节点，包括电路，所述电路包括处理器和存储器，所述存储器包含能够由所述处理器执行的指令，由此所述SFC节点可操作以：

接收包括第一SFC路径标识符ID和第一SFC索引的分组；

确定是否将第一服务功能应用于所述分组；

根据将所述第一服务功能应用于所述分组，在所述分组中设置已处理指示符；

响应于确定所述分组已由所述第一服务功能处理，选择与所述第一SFC路径ID和所述第一SFC索引关联的第二SFC路径ID和第二SFC索引；

通过用所述第二SFC路径ID和所述第二SFC索引替换所述第一SFC路径ID和所述第一SFC索引来修改所述分组；以及

根据所述第二SFC路径ID和所述第二SFC索引来转发修改后的分组。

13.根据权利要求12所述的SFC节点，还可操作以：根据确定所述第一服务功能是否已被应用于所述分组，确定是否将所述第一服务功能应用于所述分组。

14.根据权利要求13所述的SFC节点，还可操作以：根据所述分组中的所述已处理指示符，确定所述第一服务功能是否已被应用于所述分组。

15.根据权利要求12所述的SFC节点，还可操作以：根据协作协议，确定是否将所述第一服务功能应用于所述分组。

16.根据权利要求15所述的SFC节点，其中，所述协作协议定义所述SFC节点已分配用于应用所述第一服务功能的资源量和所述SFC节点将所述第一服务功能所应用到的业务的带宽中的至少一者。

17.根据权利要求12所述的SFC节点，还可操作以：根据接收所述分组的隧道，确定是否将所述第一服务功能应用于所述分组。

18.根据权利要求12所述的SFC节点，其中，所述已处理指示符作为元数据被存储在所述分组中。

19.根据权利要求12所述的SFC节点，其中，所述已处理指示符是网络服务报头中的字段。

20.根据权利要求12所述的SFC节点，还可操作以：响应于确定所述分组尚未被所述第一服务功能处理，根据第一SFC路径ID和第一SFC索引转发所述分组。

21.根据权利要求12所述的SFC节点，其中，所述第二SFC路径ID和所述第二SFC索引被选择以旁路所述第一SFC路径中所述第一服务功能的后续实例。

22.根据权利要求12所述的SFC节点，还可操作以：根据所述第二SFC路径ID和所述第二SFC索引，选择用于将所述分组转发到第二域的隧道。

23.一种存储可执行指令的计算机可读存储介质，所述可执行指令在由处理器执行时使所述处理器：

接收包括第一SFC路径标识符ID和第一SFC索引的分组；

确定是否将第一服务功能应用于所述分组；

根据将所述第一服务功能应用于所述分组，在所述分组中设置已处理指示符；

响应于确定所述分组已由所述第一服务功能处理，选择与所述第一SFC路径ID和所述第一SFC索引关联的第二SFC路径ID和第二SFC索引；

通过用所述第二SFC路径ID和所述第二SFC索引替换所述第一SFC路径ID和所述第一SFC索引来修改所述分组；以及

根据所述第二SFC路径ID和所述第二SFC索引来转发修改后的分组。