Internet Engineering Task Force (IETF) J. Halpern, Ed.
Request for Comments: 7665 Ericsson
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 Cisco
October 2015
Internet Engineering Task Force (IETF) J. Halpern, Ed.
Request for Comments: 7665 Ericsson
Category: Informational C. Pignataro, Ed.
ISSN: 2070-1721 Cisco
October 2015
Service Function Chaining (SFC) Architecture
服务功能链（SFC）体系结构
Abstract
摘要
This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.
本文档描述了网络中服务功能链（SFC）的规范、创建和持续维护的体系结构。它包括通过部署SFC构建复合服务时使用的体系结构概念、原则和组件，重点是IETF中要标准化的内容。本文档不建议解决方案、协议或现有协议的扩展。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7665.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7665.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Specification of Requirements . . . . . . . . . . . . . . 5
1.4. Definition of Terms . . . . . . . . . . . . . . . . . . . 6
2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
2.1. Service Function Chains . . . . . . . . . . . . . . . . . 8
2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 9
2.3. Service Function Paths . . . . . . . . . . . . . . . . . 10
2.3.1. Service Function Chains, Service Function Paths, and
Rendered Service Path . . . . . . . . . . . . . . . . 11
3. Architecture Principles . . . . . . . . . . . . . . . . . . . 12
4. Core SFC Architecture Components . . . . . . . . . . . . . . 13
4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 14
4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 15
4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 15
4.3.1. Transport-Derived SFF . . . . . . . . . . . . . . . . 17
4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 17
4.5. Network Overlay and Network Components . . . . . . . . . 18
4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Classification . . . . . . . . . . . . . . . . . . . . . 19
4.8. Reclassification and Branching . . . . . . . . . . . . . 19
4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 20
5. Additional Architectural Concepts . . . . . . . . . . . . . . 21
5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 21
5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 21
5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 22
5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 23
5.5. Load-Balancing Considerations . . . . . . . . . . . . . . 23
5.6. MTU and Fragmentation Considerations . . . . . . . . . . 24
5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Specification of Requirements . . . . . . . . . . . . . . 5
1.4. Definition of Terms . . . . . . . . . . . . . . . . . . . 6
2. Architectural Concepts . . . . . . . . . . . . . . . . . . . 8
2.1. Service Function Chains . . . . . . . . . . . . . . . . . 8
2.2. Service Function Chain Symmetry . . . . . . . . . . . . . 9
2.3. Service Function Paths . . . . . . . . . . . . . . . . . 10
2.3.1. Service Function Chains, Service Function Paths, and
Rendered Service Path . . . . . . . . . . . . . . . . 11
3. Architecture Principles . . . . . . . . . . . . . . . . . . . 12
4. Core SFC Architecture Components . . . . . . . . . . . . . . 13
4.1. SFC Encapsulation . . . . . . . . . . . . . . . . . . . . 14
4.2. Service Function (SF) . . . . . . . . . . . . . . . . . . 15
4.3. Service Function Forwarder (SFF) . . . . . . . . . . . . 15
4.3.1. Transport-Derived SFF . . . . . . . . . . . . . . . . 17
4.4. SFC-Enabled Domain . . . . . . . . . . . . . . . . . . . 17
4.5. Network Overlay and Network Components . . . . . . . . . 18
4.6. SFC Proxy . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Classification . . . . . . . . . . . . . . . . . . . . . 19
4.8. Reclassification and Branching . . . . . . . . . . . . . 19
4.9. Shared Metadata . . . . . . . . . . . . . . . . . . . . . 20
5. Additional Architectural Concepts . . . . . . . . . . . . . . 21
5.1. The Role of Policy . . . . . . . . . . . . . . . . . . . 21
5.2. SFC Control Plane . . . . . . . . . . . . . . . . . . . . 21
5.3. Resource Control . . . . . . . . . . . . . . . . . . . . 22
5.4. Infinite Loop Detection and Avoidance . . . . . . . . . . 23
5.5. Load-Balancing Considerations . . . . . . . . . . . . . . 23
5.6. MTU and Fragmentation Considerations . . . . . . . . . . 24
5.7. SFC OAM . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.8. Resilience and Redundancy . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Normative References . . . . . . . . . . . . . . . . . . 29
7.2. Informative References . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
The delivery of end-to-end services often requires various service functions. These include traditional network service functions such as firewalls and traditional IP Network Address Translators (NATs), as well as application-specific functions. The definition and instantiation of an ordered set of service functions and subsequent "steering" of traffic through them is termed Service Function Chaining (SFC).
端到端服务的交付通常需要各种服务功能。这些功能包括传统的网络服务功能，如防火墙和传统的IP网络地址转换器（NAT），以及特定于应用程序的功能。服务功能有序集合的定义和实例化以及随后通过它们的流量“引导”被称为服务功能链（SFC）。
This document describes an architecture used for the creation and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components, with a focus on those to be standardized in the IETF. SFCs enable composite services that are constructed from one or more service functions.
本文档描述了用于在网络中创建和持续维护服务功能链（SFC）的体系结构。它包括体系结构概念、原则和组件，重点是IETF中要标准化的内容。SFC支持由一个或多个服务函数构造的复合服务。
An overview of the issues associated with the deployment of end-to-end service function chains, abstract sets of service functions and their ordering constraints that create a composite service, and the subsequent "steering" of traffic flows through said service functions, is described in [RFC7498].
[RFC7498]中描述了与部署端到端服务功能链、创建复合服务的抽象服务功能集及其顺序约束，以及通过所述服务功能的后续交通流“转向”相关的问题概述。
The current service function deployment models are relatively static, coupled to network topology and physical resources, greatly reducing or eliminating the ability of an operator to introduce new services or dynamically create service function chains. This architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity.
当前的服务功能部署模型相对静态，与网络拓扑和物理资源相耦合，大大降低或消除了运营商引入新服务或动态创建服务功能链的能力。该体系结构提供了一个解决现有服务部署问题的模型，包括拓扑独立性和配置复杂性。
This document defines the architecture for Service Function Chaining (SFC) as standardized in the IETF. The SFC architecture is predicated on topological independence from the underlying forwarding topology.
本文件定义了IETF中标准化的服务功能链（SFC）体系结构。SFC体系结构基于与底层转发拓扑的拓扑独立性。
In this architecture, packets are classified on ingress for handling by the required set of Service Functions (SFs) in the SFC-enabled domain and are then forwarded through that set of functions for processing by each function in turn. Packets may be reclassified as a result of this processing.
在该体系结构中，数据包在入口上分类，以便由启用SFC的域中所需的服务功能集（SF）进行处理，然后通过该功能集转发，以便依次由每个功能进行处理。作为该处理的结果，分组可能被重新分类。
The architecture described in this document is independent of the planned usage of the network and deployment context and thus, for example, is applicable to both fixed and mobile networks as well as being useful in many data center applications.
本文档中描述的体系结构独立于网络和部署上下文的计划使用，因此，例如，适用于固定和移动网络，并且在许多数据中心应用中都很有用。
The architecture described herein is assumed to be applicable to a single network administrative domain. While it is possible for the architectural principles and components to be applied to inter-domain SFCs, these are left for future study.
本文描述的体系结构假定适用于单个网络管理域。虽然架构原则和组件可以应用于域间SFC，但这些仍有待于将来的研究。
The following assumptions are made:
作出以下假设：
o There is no standard definition or characterization applicable to all SFs, and thus the architecture considers each SF as an opaque processing element.
o 没有适用于所有SF的标准定义或特征，因此架构将每个SF视为不透明的处理元素。
o There is no global or standard list of SFs enabled in a given administrative domain. The set of SFs enabled in a given domain is a function of the currently active services that may vary with time and according to the networking environment.
o 给定管理域中没有启用的SFs的全局或标准列表。给定域中启用的SFs集是当前活动服务的功能，可能随时间和网络环境而变化。
o There is no global or standard SF chaining logic. The ordered set of SFs that needs to be applied to deliver a given service is specific to each administrative entity.
o 没有全局或标准的SF链接逻辑。为提供给定服务而需要应用的SFs的有序集合特定于每个管理实体。
o The chaining of SFs and the criteria to invoke them are specific to each administrative entity that operates an SF-enabled domain.
o SFs的链接和调用它们的条件特定于运行支持SF的域的每个管理实体。
o Several SF chaining policies can be simultaneously applied within an administrative domain to meet various business requirements.
o 可以在管理域内同时应用多个SF链接策略，以满足各种业务需求。
o The underlay is assumed to provide the necessary connectivity to interconnect the Service Function Forwarders (SFFs; see Section 1.4), but the architecture places no constraints on how that connectivity is realized other than it have the required bandwidth, latency, and jitter to support the SFC.
o 假定参考底图提供必要的连接，以互连服务功能转发器（SFF；参见第1.4节），但架构对如何实现该连接没有任何限制，除非它具有支持SFC所需的带宽、延迟和抖动。
o No assumption is made on how Forwarding Information Bases (FIBs) and Routing Information Bases (RIBs) of involved nodes are populated.
o 未对相关节点的转发信息库（FIB）和路由信息库（RIB）的填充方式进行假设。
o How to bind traffic to a given SF chain is policy-based.
o 如何将流量绑定到给定的SF链是基于策略的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a "composite service". The term "service" is used to denote a "network service" in the context of this document.
网络服务：由运营商提供的，使用一个或多个服务功能提供的服务。这也可以称为“复合服务”。术语“服务”在本文件上下文中用于表示“网络服务”。
Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a "firewall". Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted.
注意：除了本文档之外，“服务”一词还有各种不同的定义。例如，对某些人来说，服务是由运营商网络中的几个元素组成的产品，而对另一些人来说，服务，或者更具体地说是网络服务，是一个离散元素，例如“防火墙”。传统上，此类服务（在后一种意义上）承载一组服务功能，并具有承载服务的网络定位器。
Classification: Locally instantiated matching of traffic flows against policy for subsequent application of the required set of network service functions. The policy may be customer/network/ service specific.
分类：本地实例化的流量与策略的匹配，用于后续应用所需的一组网络服务功能。该策略可能是特定于客户/网络/服务的。
Classifier: An element that performs Classification.
分类器：执行分类的元素。
Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term "service chain" is often used as shorthand for service function chain.
服务功能链（SFC）：服务功能链定义了一组有序的抽象服务功能和排序约束，这些功能和约束必须应用于作为分类结果选择的数据包和/或帧和/或流。抽象服务功能的一个例子是“防火墙”。隐含顺序可能不是线性级数，因为体系结构允许SFC复制到多个分支，并且还允许在需要应用服务功能的顺序中具有灵活性的情况。术语“服务链”通常用作服务功能链的简写。
Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a service function can be realized as a virtual element or be embedded in a physical network element. One or more Service Functions can be embedded in the same network element. Multiple occurrences of the service function can exist in the same administrative domain.
服务功能（SF）：负责对接收到的数据包进行特定处理的功能。服务功能可以在协议栈的各个层（例如，在网络层或其他OSI层）上起作用。作为逻辑组件，服务功能可以作为虚拟元素实现，也可以嵌入到物理网元中。一个或多个服务功能可以嵌入到同一网元中。同一管理域中可能存在多次服务功能。
One or more service functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract service functions includes: firewalls, WAN and application acceleration,
增值服务的交付可涉及一个或多个服务功能。抽象服务功能的非详尽列表包括：防火墙、WAN和应用程序加速，
Deep Packet Inspection (DPI), Lawful Intercept (LI), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, and TCP optimizer.
深度数据包检查（DPI）、合法拦截（LI）、服务器负载平衡、NAT44[RFC3022]、NAT64[RFC6146]、NPTv6[RFC6296]、主机ID注入、HTTP头扩展功能和TCP优化器。
An SF may be SFC encapsulation aware (that is, it receives and acts on information in the SFC encapsulation) or unaware (in which case, data forwarded to the SF does not contain the SFC encapsulation). This is often referred to as "SFC aware" and "SFC unaware", respectively.
SF可以是SFC封装感知（即，它接收SFC封装中的信息并对其进行操作）或不感知（在这种情况下，转发给SF的数据不包含SFC封装）。这通常分别称为“证监会知晓”和“证监会不知晓”。
Service Function Forwarder (SFF): A service function forwarder is responsible for forwarding traffic to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, an SFF is responsible for delivering traffic to a classifier when needed and supported, transporting traffic to another SFF (in the same or different type of overlay), and terminating the Service Function Path (SFP).
服务功能转发器（SFF）：服务功能转发器负责根据SFC封装中携带的信息将流量转发到一个或多个连接的服务功能，并处理从SF返回的流量。此外，SFF负责在需要和支持时将流量传送到分类器，将流量传送到另一个SFF（在相同或不同类型的覆盖中），并终止服务功能路径（SFP）。
Metadata: Provides the ability to exchange context information between classifiers and SFs, and among SFs.
元数据：提供在分类器和SF之间以及SF之间交换上下文信息的能力。
Service Function Path (SFP): The service function path is a constrained specification of where packets assigned to a certain service function path must go. While it may be so constrained as to identify the exact locations, it can also be less specific. The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network.
服务功能路径（SFP）：服务功能路径是指定给特定服务功能路径的数据包必须到达的位置的约束规范。虽然它可能会受到限制，以确定确切的位置，但也可能不太具体。SFP提供了服务链（作为要交付的抽象服务功能序列）的完全抽象概念与数据包实际穿越网络时将访问哪个SFF/SFs的完全指定概念之间的间接层次。通过允许控制组件指定该间接级别，操作员可以控制委托给网络的SFF/SF选择权限的程度。
SFC Encapsulation: The SFC encapsulation provides, at a minimum, SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries metadata including data-plane context information.
SFC封装：SFC封装至少提供SFP标识，并由SFC感知功能（如SFF和SFC感知SFs）使用。SFC封装不用于网络数据包转发。除了SFP标识之外，SFC封装还携带元数据，包括数据平面上下文信息。
Rendered Service Path (RSP): Within an SFP, packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit.
呈现服务路径（RSP）：在SFP中，数据包本身当然从网络中的特定位置发送到网络中的特定位置，访问特定序列的SFF和SFs。数据包对网络中特定SFF和SFs的实际访问序列称为呈现服务路径（RSP）。此定义包含在此处，供后续文档使用，例如解决方案可能需要讨论数据包访问位置的实际顺序时。
SFC-Enabled Domain: A network or region of a network that implements SFC. An SFC-enabled domain is limited to a single network administrative domain.
启用SFC的域：实现SFC的网络或网络区域。启用SFC的域仅限于单个网络管理域。
SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function. SFC proxies are logical elements.
SFC代理：代表SFC服务函数移除和插入SFC封装。SFC代理是逻辑元素。
The following sections describe the foundational concepts of service function chaining and the SFC architecture.
以下各节描述了服务功能链和SFC体系结构的基本概念。
Service function chaining enables the creation of composite (network) services that consist of an ordered set of SFs that must be applied to packets and/or frames and/or flows selected as a result of classification. Each SF is referenced using an identifier that is unique within an SF-enabled domain.
服务功能链接允许创建复合（网络）服务，这些服务由一组有序的SF组成，这些SF必须应用于作为分类结果选择的数据包和/或帧和/或流。使用启用SF的域中唯一的标识符引用每个SF。
Service function chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities.
服务功能链是一个概念，它提供的不仅仅是对选定流量应用一组有序SF；相反，它描述了一种以支持这些SF的动态排序和拓扑独立性以及参与实体之间元数据交换的方式部署SF的方法。
In most networks, services are constructed as abstract sequences of SFs that represent SFCs. At a high level, an SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed. Graphs, as illustrated in Figure 1, define an SFC, where each graph node represents the required existence of at least one abstract SF. Such graph nodes (SFs) can be part of zero, one, or many SFCs. A given graph node (SF) can appear one time or multiple times in a given SFC.
在大多数网络中，服务被构造为表示SFC的SFs的抽象序列。从高层来看，SFC是服务的抽象视图，它指定了所需SF的集合以及它们必须执行的顺序。如图1所示，图定义了一个SFC，其中每个图节点表示至少一个抽象SF的必要存在性。这样的图节点（SF）可以是零、一或多个SFC的一部分。给定的图节点（SF）可以在给定的SFC中出现一次或多次。
SFCs can start from the origination point of the service function graph (i.e., node 1 in Figure 1), or from any subsequent node in the graph. As shown, SFs may therefore become branching nodes in the graph, with those SFs selecting edges that move traffic to one or
SFC可以从服务功能图的起始点（即图1中的节点1）或图中任何后续节点开始。如图所示，SF因此可能成为图中的分支节点，这些SF选择将流量移动到一个或多个节点的边
more branches. The top and middle graphs depict such a case, where a second classification event occurs after node 2, and a new graph is selected (i.e., node 3 instead of node 6). The bottom graph highlights the concept of a cycle, in which a given SF (e.g., node 7 in the depiction) can be visited more than once within a given service chain. An SFC can have more than one terminus.
更多的分支机构。顶部和中间的图描述了这样的情况，其中在节点2之后发生第二分类事件，并且选择了新的图（即，节点3而不是节点6）。下图突出了循环的概念，其中给定的SF（例如，描述中的节点7）可以在给定的服务链中访问多次。证监会可以有多个终点。
,-+-. ,---. ,---. ,---.
/ \ / \ / \ / \
( 1 )+--->( 2 )+---->( 6 )+---->( 8 )
\ / \ / \ / \ /
`---' `---' `---' `---'
,-+-. ,---. ,---. ,---.
/ \ / \ / \ / \
( 1 )+--->( 2 )+---->( 6 )+---->( 8 )
\ / \ / \ / \ /
`---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
,-+-. ,---. ,---. ,---. ,---.
/ \ / \ / \ / \ / \
( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 )
\ / \ / \ / \ / \ /
`---' `---' `---' `---' `---'
Figure 1: Service Function Chain Graphs
图1：服务功能链图
The concepts of classification, reclassification, and branching are covered in subsequent sections of this architecture (see Sections 4.7 and 4.8).
分类、重新分类和分支的概念将在本体系结构的后续章节中介绍（见第4.7节和第4.8节）。
SFCs may be unidirectional or bidirectional. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in which the SF instances are the same in opposite directions. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs; that is to say some SFs require symmetric traffic, whereas other SFs do not process reverse traffic or are independent of the corresponding forward traffic.
SFC可以是单向的或双向的。单向SFC要求在一个方向（sf1->sf2->sf3）上通过有序SFs转发流量，而双向SFC要求对称路径（sf1->sf2->sf3和sf3->sf2->sf1），其中SF实例在相反方向上相同。混合SFC具有单向和双向SFC的属性；也就是说，一些SF需要对称流量，而其他SF不处理反向流量或独立于相应的正向流量。
SFCs may contain cycles; that is traffic may need to traverse one or more SFs within an SFC more than once. Solutions will need to ensure suitable disambiguation for such situations.
SFC可能包含周期；也就是说，流量可能需要在一个SFC内多次穿越一个或多个SF。解决方案将需要确保对此类情况进行适当的消歧。
The architectural allowance that is made for SFPs that delegate choice to the network for which SFs and/or SFFs a packet will visit creates potential issues here. A solution that allows such delegation needs to also describe how the solution ensures that those service chains requiring service function chain symmetry can achieve that.
对于将选择权委托给数据包将访问的SFs和/或SFF的网络的SFP，其体系结构允许在这里产生潜在问题。允许这种委托的解决方案还需要描述该解决方案如何确保那些需要服务功能链对称性的服务链能够实现这一点。
Further, there are state trade-offs in symmetry. Symmetry may be realized in several ways depending on the SFF and classifier functionality. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed, whereas in others shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP. At a high level, there are various common cases. In a non-exhaustive way, there can be for example:
此外，对称性中存在着国家权衡。根据SFF和分类器功能，对称性可以通过多种方式实现。在某些情况下，可以部署“镜像”分类（即从源到目标和从目标到源）策略，而在其他情况下，可以使用分类器之间的共享状态来确保正确识别对称流，然后沿着所需的SFP进行引导。在高层，有各种常见情况。以非穷尽的方式，例如可以有：
o A single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier.
o 单个分类器（或少量分类器），在这种情况下，传入流和传出流都可以在同一个分类器上识别，因此通过分类器内部的内部机制可以实现同步。
o Stateful classifiers where several classifiers may be clustered and share state.
o 有状态分类器，其中多个分类器可以集群并共享状态。
o Fully distributed classifiers, where synchronization needs to be provided through unspecified means.
o 完全分布式分类器，需要通过未指定的方式提供同步。
o A classifier that learns state from the egress packets/flows that is then used to provide state for the return packets/flow.
o 从出口分组/流学习状态的分类器，然后用于为返回分组/流提供状态。
o Symmetry may also be provided by stateful forwarding logic in the SFF in some implementations.
o 在某些实现中，SFF中的有状态转发逻辑也可以提供对称性。
This is a non-comprehensive list of common cases.
这是一个不全面的常见案例列表。
A Service Function Path (SFP) is a mechanism used by service chaining to express the result of applying more granular policy and operational constraints to the abstract requirements of a service chain (SFC). This architecture does not mandate the degree of specificity of the SFP. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, selecting exactly which SFF and which SF are to be visited by packets using that SFP, while other SFPs may be quite vague, deferring to the SFF the decisions about the exact sequence of steps to be used to realize the SFC. The specificity may be anywhere in between these extremes.
服务功能路径（SFP）是服务链使用的一种机制，用于表示将更细粒度的策略和操作约束应用于服务链（SFC）抽象需求的结果。该体系结构不要求SFP的特定程度。架构上，在相同的支持SFC的域中，可以完全指定一些SFP，精确地选择使用该SFP的分组访问哪个SFF和哪个SF，而其他SFP可能非常模糊，遵从SFF关于实现SFC所使用的步骤的确切顺序的决定。特异性可能介于这两个极端之间。
As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC, where one SFP specifies that any order of SFF and SF may be used as long as it is within Data Center 1, and where the second SFP allows the same latitude, but only within Data Center 2.
作为此类中间特异性的示例，可能存在两个与给定SFC相关联的SFP，其中一个SFP指定只要在数据中心1内，就可以使用SFF和SF的任何顺序，并且第二个SFP允许相同的纬度，但仅在数据中心2内。
Thus, the policies and logic of SFP selection or creation (depending upon the solution) produce what may be thought of as a constrained version of the original SFC. Since multiple policies may apply to different traffic that uses the same SFC, it also follows that there may be multiple SFPs associated with a single SFC.
因此，SFP选择或创建的政策和逻辑（取决于解决方案）产生了原始SFC的约束版本。由于多个策略可能适用于使用同一SFC的不同流量，因此也可能有多个SFP与单个SFC关联。
The architecture allows for the same SF to be reachable through multiple SFFs. In these cases, some SFPs may constrain which SFF is used to reach which SF, while some SFPs may leave that decision to the SFF itself.
该体系结构允许通过多个SFF访问相同的SF。在这些情况下，一些SFP可能会限制使用哪个SFF来达到哪个SF，而一些SFP可能会将该决定留给SFF本身。
Further, the architecture allows for two or more SFs to be attached to the same SFF, and possibly connected via internal means allowing more effective communication. In these cases, some solutions or deployments may choose to use some form of internal inter-process or inter-VM messaging (communication behind the virtual switching element) that is optimized for such an environment. This must be coordinated with the SFF so that it can properly perform its job. Implementation details of such mechanisms are considered out of scope for this document, and can include a spectrum of methods: for example, situations including all next-hops explicitly, others where a list of possible next-hops is provided and the selection is local, or cases with just an identifier, where all resolution is local.
此外，该架构允许将两个或多个sf连接到同一SFF，并且可能通过允许更有效通信的内部装置连接。在这些情况下，一些解决方案或部署可能会选择使用某种形式的内部进程间或VM间消息传递（虚拟交换元素后面的通信），这是针对此类环境优化的。这必须与SFF协调，以便其能够正确执行其工作。此类机制的实现细节被认为超出了本文档的范围，可以包括一系列方法：例如，明确包括所有下一跳的情况，提供可能的下一跳列表且选择是本地的其他情况，或者只有一个标识符的情况，其中所有解析都是本地的。
This architecture also allows the same SF to be part of multiple SFPs.
该体系结构还允许同一SF成为多个SFP的一部分。
2.3.1. Service Function Chains, Service Function Paths, and Rendered Service Path
2.3.1. 服务功能链、服务功能路径和呈现服务路径
As an example of this progressive refinement, consider a Service Function Chain (SFC) that states that packets using this chain should be delivered to a firewall and a caching engine.
作为这种渐进式改进的一个例子，考虑一个服务功能链（SFC），它指出使用这个链的包应该被传递到防火墙和缓存引擎。
A Service Function Path (SFP) could refine this, considering that this architecture does not mandate the degree of specificity an SFP has to have. It might specify that the firewall and caching engine are both to be in a specific data center (e.g., in DC1), or it might specify exactly which instance of each firewall and caching engine is to be used.
服务功能路径（ServiceFunctionPath，SFP）可以改进这一点，因为该体系结构并不要求SFP必须具有的特定程度。它可以指定防火墙和缓存引擎都位于特定的数据中心（例如，在DC1中），也可以指定每个防火墙和缓存引擎的具体实例。
The Rendered Service Path (RSP) is the actual sequence of SFFs and SFs that the packets will actually visit. So if the SFP picked the DC, the RSP would be more specific.
呈现服务路径（RSP）是数据包实际访问的SFF和SFs的实际序列。因此，如果SFP选择DC，RSP将更加具体。
Service function chaining is predicated on several key architectural principles:
服务功能链接基于几个关键的体系结构原则：
1. Topological independence: No changes to the underlay network forwarding topology -- implicit, or explicit -- are needed to deploy and invoke SFs or SFCs.
1. 拓扑独立性：部署和调用SFs或SFC不需要对底层网络转发拓扑进行任何更改（隐式或显式）。
2. Plane separation: Dynamic realization of SFPs is separated from packet handling operations (e.g., packet forwarding).
2. 平面分离：SFPs的动态实现与数据包处理操作（例如，数据包转发）分离。
3. Classification: Traffic that satisfies classification rules is forwarded according to a specific SFP. For example, classification can be as simple as an explicit forwarding entry that forwards all traffic from one address into the SFP. Multiple classification points are possible within an SFC (i.e., forming a service graph), thus enabling changes/updates to the SFC by SFs.
3. 分类：满足分类规则的流量根据特定SFP转发。例如，分类可以像显式转发条目一样简单，该条目将所有流量从一个地址转发到SFP。一个SFC内可能有多个分类点（即形成服务图），因此SFs可以对SFC进行更改/更新。
Classification can occur at varying degrees of granularity; for example, classification can use a 5-tuple, a transport port or set of ports, part of the packet payload, it can be the result of high-level inspections, or it can come from external systems.
分类可以在不同的粒度上进行；例如，分类可以使用一个5元组、一个传输端口或一组端口、数据包有效负载的一部分，也可以是高级检查的结果，也可以来自外部系统。
4. Shared Metadata: Metadata/context data can be shared amongst SFs and classifiers, between SFs, and between external systems and SFs (e.g., orchestration).
4. 共享元数据：元数据/上下文数据可以在SF和分类器之间、SF之间以及外部系统和SF之间共享（例如，编排）。
One use of metadata is to provide and share the result of classification (that occurs within the SFC-enabled domain, or external to it) along an SFP. For example, an external repository might provide user/subscriber information to a service chain classifier. This classifier could in turn impose that information in the SFC encapsulation for delivery to the requisite SFs. The SFs could in turn utilize the user/subscriber information for local policy decisions. Metadata can also share SF output along the SFP.
元数据的一种用途是沿着SFP提供和共享分类结果（发生在支持SFC的域内或其外部）。例如，外部存储库可以向服务链分类器提供用户/订户信息。该分类器可以反过来将该信息施加在SFC封装中，以交付给必要的SFs。SFs可以反过来利用用户/订户信息进行本地策略决策。元数据还可以沿SFP共享SF输出。
5. Service definition independence: The SFC architecture does not depend on the details of SFs themselves.
5. 服务定义独立性：SFC架构不依赖于SFs本身的细节。
6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs.
6. 服务职能链独立性：创建、修改或删除SFC对其他SFC没有影响。SFP也是如此。
7. Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) to populate and resolve local policy and (if needed) local classification criteria.
7. 异构控制/策略点：该体系结构允许SFs使用独立的机制（不在本文档范围内）来填充和解析本地策略和（如果需要）本地分类标准。
The SFC Architecture is built out of architectural building blocks that are logical components; these logical components are classifiers, Service Function Forwarders (SFFs), the Service Functions (SFs) themselves, and SFC proxies. While this architecture describes functionally distinct logical components and promotes transport independence, they could be realized and combined in various ways in deployed products, and could be combined with an overlay.
SFC体系结构由作为逻辑组件的体系结构构建块构建而成；这些逻辑组件是分类器、服务功能转发器（SFF）、服务功能（SFs）本身和SFC代理。虽然此体系结构描述了功能不同的逻辑组件并促进了传输独立性，但它们可以在部署的产品中以各种方式实现和组合，并且可以与覆盖层组合。
They are interconnected using the SFC encapsulation. This results in a high-level logical architecture of an SFC-enabled domain that comprises:
它们使用SFC封装进行互连。这将导致启用SFC的域的高级逻辑体系结构，包括：
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. +--------------+ +------------------~~~
. | Service | SFC | Service +---+ +---+
. |Classification| Encapsulation | Function |sf1|...|sfn|
+---->| Function |+---------------->| Path +---+ +---+
. +--------------+ +------------------~~~
. SFC-enabled Domain
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. +--------------+ +------------------~~~
. | Service | SFC | Service +---+ +---+
. |Classification| Encapsulation | Function |sf1|...|sfn|
+---->| Function |+---------------->| Path +---+ +---+
. +--------------+ +------------------~~~
. SFC-enabled Domain
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 2: Service Function Chain Architecture
图2：服务功能链架构
The following subsections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of how some of these architectural components interact is provided in Figure 3:
以下小节提供了构成SFC体系结构基础的每个逻辑组件的详细信息。图3提供了一些架构组件如何交互的详细概述：
+----------------+ +----------------+
| SFC-aware | | SFC-unaware |
|Service Function| |Service Function|
+-------+--------+ +-------+--------+
| |
SFC Encapsulation No SFC Encapsulation
| SFC |
+---------+ +----------------+ Encapsulation +---------+
|SFC-Aware|-----------------+ \ +------------|SFC Proxy|
| SF | ... ----------+ \ \ / +---------+
+---------+ \ \ \ /
+-------+--------+
| SF Forwarder |
| (SFF) |
+-------+--------+
|
SFC Encapsulation
|
... SFC-enabled Domain ...
|
Network Overlay Transport
|
_,....._
,-' `-.
/ `.
| Network |
`. /
`.__ __,-'
`''''
+----------------+ +----------------+
| SFC-aware | | SFC-unaware |
|Service Function| |Service Function|
+-------+--------+ +-------+--------+
| |
SFC Encapsulation No SFC Encapsulation
| SFC |
+---------+ +----------------+ Encapsulation +---------+
|SFC-Aware|-----------------+ \ +------------|SFC Proxy|
| SF | ... ----------+ \ \ / +---------+
+---------+ \ \ \ /
+-------+--------+
| SF Forwarder |
| (SFF) |
+-------+--------+
|
SFC Encapsulation
|
... SFC-enabled Domain ...
|
Network Overlay Transport
|
_,....._
,-' `-.
/ `.
| Network |
`. /
`.__ __,-'
`''''
Figure 3: SFC Architecture Components After Initial Classification
图3：初始分类后的SFC体系结构组件
Please note that the depiction in Figure 3 shows packets after initial classification, and therefore includes the SFC encapsulation. Although not included in Figure 3, the classifier is an SFC architectural component.
请注意，图3中的描述显示了初始分类后的数据包，因此包括SFC封装。尽管未包含在图3中，但分类器是一个SFC体系结构组件。
The SFC encapsulation enables service function path selection. It also enables the sharing of metadata/context information when such metadata exchange is required.
SFC封装支持服务功能路径选择。它还支持在需要元数据交换时共享元数据/上下文信息。
The SFC encapsulation carries explicit information used to identify the SFP. However, the SFC encapsulation is not a transport encapsulation itself: it is not used to forward packets within the network fabric. If packets need to flow between separate physical platforms, the SFC encapsulation relies on an outer network
SFC封装包含用于识别SFP的明确信息。但是，SFC封装本身不是传输封装：它不用于在网络结构内转发数据包。如果数据包需要在不同的物理平台之间流动，SFC封装依赖于外部网络
transport. Transit forwarders -- such as router and switches -- forward SFC encapsulated packets based on the outer (non-SFC) encapsulation.
运输传输转发器——如路由器和交换机——基于外部（非SFC）封装转发SFC封装的数据包。
One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. As such, any network transport protocol may be used to carry the SFC encapsulated traffic.
SFC的关键架构原则之一是SFC封装保持传输独立。因此，可以使用任何网络传输协议来承载SFC封装的通信量。
The concept of an SF evolves; rather than being viewed as a bump in the wire, an SF becomes a resource within a specified administrative domain that is available for consumption as part of a composite service. SFs send/receive data to/from one or more SFFs. SFC-aware SFs receive this traffic with the SFC encapsulation.
SF的概念不断演变；SF不再被视为线路中的一个凸起，而是成为指定管理域中的一个资源，可作为复合服务的一部分使用。SFs向/从一个或多个SFF发送/接收数据。支持SFC的SFs通过SFC封装接收此流量。
While the SFC architecture defines the concept and specifies some characteristics of a new encapsulation -- the SFC encapsulation -- and several logical components for the construction of SFCs, existing SF implementations may not have the capabilities to act upon or fully integrate with the new SFC encapsulation. In order to provide a mechanism for such SFs to participate in the architecture, an SFC proxy function is defined (see Section 4.6). The SFC proxy acts as a gateway between the SFC encapsulation and SFC-unaware SFs. The integration of SFC-unaware service functions is discussed in more detail in the SFC proxy section.
虽然SFC体系结构定义了概念并指定了新封装（SFC封装）的一些特征以及用于构建SFC的几个逻辑组件，但现有SF实现可能不具备作用于新SFC封装或与新SFC封装完全集成的能力。为了为此类SF提供参与架构的机制，定义了SFC代理功能（见第4.6节）。SFC代理充当SFC封装和SFC非感知SFs之间的网关。SFC代理部分将更详细地讨论SFC服务功能的集成。
This architecture allows an SF to be part of multiple SFPs and SFCs.
该体系结构允许SF成为多个SFP和SFC的一部分。
The SFF is responsible for forwarding packets and/or frames received from the network to one or more SFs associated with a given SFF using information conveyed in the SFC encapsulation. Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. Some SFs, such as firewalls, could also consume a packet.
SFF负责使用SFC封装中传送的信息将从网络接收的分组和/或帧转发到与给定SFF相关联的一个或多个sf。来自SFs的流量最终返回到相同的SFF，SFF负责将流量注入网络。某些SF（如防火墙）也可能使用数据包。
The collection of SFFs and associated SFs creates a service-plane overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this service plane, the SFF component connects different SFs that form a service function path.
SFF和相关SF的集合创建了一个服务平面覆盖，其中包含感知SFC的SF以及不感知SFC的SF。在此服务平面内，SFF组件连接形成服务功能路径的不同SF。
SFFs maintain the requisite SFP forwarding information. SFP forwarding information is associated with a service path identifier that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated
SFF维护必要的SFP转发信息。SFP转发信息与用于唯一标识SFP的服务路径标识符相关联。服务转发状态使SFF能够识别给定SFP的哪些SF应被应用，以及在流量流经相关SFP时应用的顺序
SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed by the constraints of the SFP.
SFP。虽然SFF似乎只有一种可用的方式来交付给定的SF，但SFP的约束也可能允许多种选择。
If there are multiple choices, the SFF needs to preserve the property that all packets of a given flow are handled the same way, since the SF may well be stateful. Additionally, the SFF may preserve the handling of packets based on other properties on top of a flow, such as a subscriber, session, or application instance identification.
如果有多个选择，SFF需要保留一个属性，即给定流的所有数据包都以相同的方式处理，因为SF很可能是有状态的。此外，SFF可以基于流顶部的其他属性（例如订户、会话或应用实例标识）保留对分组的处理。
The SFF also has the information that allows it to forward packets to the next SFF after applying local service functions. Again, while there may be only a single choice available, the architecture allows for multiple choices for the next SFF. As with SFs, the solution needs to operate such that the behavior with regard to specific flows (see the Rendered Service Path) is stable. The selection of available SFs and next SFFs may be interwoven when an SFF supports multiple distinct service functions and the same service function is available at multiple SFFs. Solutions need to be clear about what is allowed in these cases.
SFF还具有允许其在应用本地服务功能后将数据包转发到下一个SFF的信息。同样，虽然可能只有一个选项可用，但该体系结构允许为下一个SFF提供多个选项。与SFs一样，解决方案的运行需要确保特定流的行为（请参见呈现的服务路径）是稳定的。当一个SFF支持多个不同的服务功能并且同一服务功能在多个SFF中可用时，可用SF和下一个SFF的选择可能是交织的。解决方案需要明确在这些情况下允许什么。
Even when the SFF supports and utilizes multiple choices, the decision as to whether to use flow-specific mechanisms or coarser-grained means to ensure that the behavior of specific flows is stable is a matter for specific solutions and specific implementations.
即使SFF支持并利用多种选择，是否使用特定于流的机制或粗粒度的方法来确保特定流的行为是稳定的，这取决于具体的解决方案和具体的实现。
The SFF component has the following primary responsibilities:
SFF组件的主要职责如下：
1. SFP forwarding: Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. After SF processing, the traffic is returned to the SFF, and, if needed, is forwarded to another SF associated with that SFF. If there is another non-local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata.
1. SFP转发：流量从网络到达SFF。SFF通过SFC封装中包含的信息确定应将流量转发到的适当SF。SF处理后，流量返回到SFF，如果需要，转发到与该SFF相关联的另一个SF。如果SFP中存在另一个非本地（即，不同的SFF）跳，则SFF进一步将业务封装在适当的网络传输协议中，并将其传送到网络以沿路径传送到下一个SFF。与此转发责任相关，SFF应该能够与元数据交互。
2. Terminating SFPs: An SFC is completely executed when traffic has traversed all required SFs in a chain. When traffic arrives at the SFF after the last SF has finished processing it, the final SFF knows from the service forwarding state that the SFC is complete. The SFF removes the SFC encapsulation and delivers the packet back to the network for forwarding.
2. 终止SFP：当流量已通过链中所有必需的SF时，SFC将完全执行。当流量在最后一个SF完成处理后到达SFF时，最终SFF从服务转发状态知道SFC已完成。SFF移除SFC封装并将数据包发送回网络进行转发。
3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. This state information may be used for a range of SFP-related tasks such as ensuring consistent treatment of all packets in a given flow, ensuring symmetry, or for state-aware SFC Proxy functionality (see Section 4.8).
3. 保持流状态：在某些情况下，SFF可能是有状态的。它创建流并存储以流为中心的信息。该状态信息可用于一系列与SFP相关的任务，如确保对给定流中的所有数据包进行一致处理，确保对称性，或用于状态感知SFC代理功能（见第4.8节）。
SFP forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information, if it can be arranged, to provide explicit service path information.
如上所述，SFP转发直接取决于SFC封装中包含的服务路径信息的使用。但是，现有的实现可能无法对SFC封装起作用。如果可以安排，这些平台可以选择使用现有的传输信息，以提供明确的服务路径信息。
This results in the same architectural behavior and meaning for SFP forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation.
这导致SFP转发和服务功能路径具有相同的体系结构行为和意义。控制组件负责确保在这种情况下执行的传输路径与服务链封装中的信息标识的路径完全一致。
Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information. Using the term "node" to refer generically to an entity that is performing a set of functions, in this context, an SFC boundary node denotes a node that connects one SFC-enabled domain to a node either located in another SFC-enabled domain or in a domain that is SFC-unaware.
可能需要在启用SFC的域的边界强制实施特定功能，例如，以避免泄露SFC信息。使用术语“节点”泛指正在执行一组功能的实体，在此上下文中，SFC边界节点表示将一个启用SFC的域连接到位于另一个启用SFC的域或位于未启用SFC的域中的节点的节点。
An SFC boundary node can act as egress or ingress. An SFC Egress Node denotes an SFC boundary node that handles traffic leaving the SFC-enabled domain the Egress Node belongs to. Such a node is required to remove any information specific to the SFC Domain, typically the SFC encapsulation. Further, from a privacy perspective, an SFC Egress Node is required to ensure that any sensitive information added as part of SFC gets removed. In this context, information may be sensitive due to network concerns or end-customer concerns. An SFC Ingress Node denotes an SFC boundary node that handles traffic entering the SFC-enabled domain. In most solutions and deployments this will need to include a classifier, and will be responsible for adding the SFC encapsulation to the packet.
SFC边界节点可以充当出口或入口。SFC出口节点表示处理离开出口节点所属的启用SFC的域的流量的SFC边界节点。需要这样一个节点来删除特定于SFC域的任何信息，通常是SFC封装。此外，从隐私角度来看，需要一个SFC出口节点来确保删除作为SFC一部分添加的任何敏感信息。在这种情况下，由于网络问题或最终客户问题，信息可能是敏感的。SFC入口节点表示处理进入启用SFC的域的流量的SFC边界节点。在大多数解决方案和部署中，这需要包括一个分类器，并负责将SFC封装添加到数据包中。
An SFC Proxy and corresponding SFC-unaware service function (see Figure 3) are inside the SFC-enabled domain.
SFC代理和相应的SFC Unknowledge服务功能（见图3）位于启用SFC的域内。
Underneath the SFF there are components responsible for performing the transport (overlay) forwarding. They do not consult the SFC encapsulation or inner payload for performing this forwarding. They only consult the outer-transport encapsulation for the transport (overlay) forwarding.
在SFF下面，有一些组件负责执行传输（覆盖）转发。他们不咨询SFC封装或内部有效负载来执行此转发。对于传输（覆盖）转发，它们只参考外部传输封装。
In order for the SFC architecture to support SFC-unaware SFs (e.g., legacy service functions) a logical SFC proxy function may be used. This function sits between an SFF and one or more SFs to which the SFF is directing traffic (see Figure 3).
为了使SFC体系结构支持SFC非意识SFs（例如，遗留服务功能），可以使用逻辑SFC代理功能。此函数位于SFF和SFF将流量定向到的一个或多个SFs之间（见图3）。
The proxy accepts packets from the SFF on behalf of the SF. It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC-unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path.
代理代表SF接受来自SFF的数据包。它移除SFC封装，然后使用本地连接电路将数据包传递给SFC不知道的SFs。它还接收来自SF的数据包，重新应用SFC封装，并将它们返回给SFF，以便沿着服务功能路径进行处理。
Thus, from the point of view of the SFF, the SFC proxy appears to be part of an SFC-aware SF.
因此，从SFF的角度来看，SFC代理似乎是具有SFC意识的SF的一部分。
Communication details between the SFF and the SFC Proxy are the same as those between the SFF and an SFC-aware SF. The details of that are not part of this architecture. The details of the communication methods over the local attachment circuit between the SFC proxy and the SFC-unaware SF are dependent upon the specific behaviors and capabilities of that SFC-unaware SF, and thus are also out of scope for this architecture.
SFF和SFC代理之间的通信细节与SFF和了解SFC的SF之间的通信细节相同。其细节不属于此体系结构的一部分。SFC代理和SFC Unknowledge SF之间通过本地连接电路的通信方法的细节取决于该SFC Unknowledge SF的特定行为和能力，因此也不在该架构的范围内。
Specifically, for traffic received from the SFF intended for the SF the proxy is representing, the SFC proxy:
具体而言，对于从SFF接收到的用于代理所代表SF的流量，SFC代理：
o Removes the SFC encapsulation from SFC encapsulated packets.
o 从SFC封装的数据包中删除SFC封装。
o Identifies the required SF to be applied based on available information including that carried in the SFC encapsulation.
o 根据可用信息（包括SFC封装中携带的信息）确定需要应用的SF。
o Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This is derived from the identification of the SF carried in the SFC encapsulation, and may include local techniques. Examples of a local attachment circuit include, but are not limited to, VLAN, IP-in-IP, Layer 2
o 选择适当的出站本地连接回路，通过该回路可访问此SFP的下一个SF。这源于SFC封装中携带SF的识别，可能包括局部技术。本地连接电路的示例包括但不限于VLAN、IP中的IP、第2层
Tunneling Protocol version 3 (L2TPv3), Generic Routing Encapsulation (GRE), and Virtual eXtensible Local Area Network (VXLAN).
隧道协议版本3（L2TPv3）、通用路由封装（GRE）和虚拟可扩展局域网（VXLAN）。
o Forwards the original payload via the selected local attachment circuit to the appropriate SF.
o 通过选定的本地连接电路将原始有效负载转发至相应的SF。
When traffic is returned from the SF:
当SF返回流量时：
o Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, or via packet classification, or other local policy. In some cases, packet ordering or modification by the SF may necessitate additional classification in order to reapply the correct SFC encapsulation.
o 应用所需的SFC封装。封装细节的确定可由接收分组和/或帧的本地连接电路、或经由分组分类或其他本地策略来推断。在某些情况下，SF的数据包排序或修改可能需要额外的分类，以便重新应用正确的SFC封装。
o Delivers the packet with the SFC encapsulation to the SFF, as would happen with packets returned from an SFC-aware SF.
o 将带有SFC封装的数据包传递到SFF，就像从支持SFC的SF返回的数据包一样。
Traffic from the network that satisfies classification criteria is directed into an SFP and forwarded to the requisite service function(s). Classification is handled by a service classification function; initial classification occurs at the ingress to the SFC domain. The granularity of the initial classification is determined by the capabilities of the classifier and the requirements of the SFC policy. For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X and directed into SFP A, or quite granular: all packets matching this 5-tuple are subject to SFC policy Y and directed into SFP B.
来自满足分类标准的网络的流量被引导到SFP并转发到必要的服务功能。分类由服务分类功能处理；初始分类发生在SFC域的入口。初始分类的粒度由分类器的能力和SFC政策的要求决定。例如，分类可能相对粗糙：来自此端口的所有数据包都遵循SFC策略X并定向到SFP A，或者非常精细：与此5元组匹配的所有数据包都遵循SFC策略Y并定向到SFP B。
As a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data, and a suitable SFP is selected or created. Classification results in attaching the traffic to a specific SFP.
作为分类决策的结果，对数据施加适当的SFC封装，并选择或创建适当的SFP。分类导致将流量附加到特定SFP。
The SFC architecture supports reclassification (or non-initial classification) as well. As packets traverse an SFP, reclassification may occur -- typically performed by a classification function co-resident with a service function. Reclassification may result in the selection of a new SFP, an update of the associated metadata, or both. This is referred to as "branching".
SFC架构也支持重新分类（或非初始分类）。当数据包穿过SFP时，可能会发生重新分类——通常由与服务函数共同驻留的分类函数执行。重新分类可能导致选择新的SFP、更新相关元数据或两者兼而有之。这被称为“分支”。
For example, an initial classification results in the selection of SFP A: DPI_1 --> SLB_8. However, when the DPI service function is executed, attack traffic is detected at the application layer. DPI_1 reclassifies the traffic as attack and alters the service path to SFP B, to include a firewall for policy enforcement: dropping the traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would be returned to the original SFF. In this simple example, the DPI service function reclassifies the traffic based on local application layer classification capabilities (that were not available during the initial classification step).
例如，初始分类会导致选择SFP A:DPI_1-->SLB_8。然而，当执行DPI服务功能时，在应用层检测到攻击流量。DPI_1将流量重新分类为攻击，并更改到SFP B的服务路径，以包括用于策略实施的防火墙：丢弃流量：DPI_1-->FW_4。在FWU 4之后，幸存的流量将返回到原始SFF。在此简单示例中，DPI服务功能基于本地应用层分类功能（在初始分类步骤中不可用）重新分类流量。
When traffic arrives after being steered through an SFC-unaware SF, the SFC Proxy must perform reclassification of traffic to determine the SFP. The SFC Proxy is concerned with re-attaching information for SFC-unaware SFs, and a stateful SFC Proxy simplifies such classification to a flow lookup.
当流量通过SFC控制后到达SF时，SFC代理必须对流量进行重新分类，以确定SFP。SFC代理关注于为SFC不知道的SFs重新附加信息，而有状态的SFC代理将此类分类简化为流查找。
Sharing metadata allows the network to provide network-derived information to the SFs, SF-to-SF information exchange, and the sharing of service-derived information to the network. Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. The shared metadata serves several possible roles within the SFC architecture:
共享元数据允许网络向SFs提供网络衍生信息、SF到SF的信息交换以及向网络共享服务衍生信息。某些SFC可能不需要元数据交换。SFC基础设施支持沿SFP交换此共享数据。共享元数据在SFC体系结构中有几个可能的角色：
o Allows elements that typically operate independently (e.g., as "ships in the night") to exchange information.
o 允许通常独立运行的元素（如“夜间船舶”）交换信息。
o Encodes information about the network and/or data for subsequent use within the SFP.
o 对有关网络和/或数据的信息进行编码，以便在SFP中后续使用。
o Creates an identifier used for policy binding by SFs.
o 创建SFs用于策略绑定的标识符。
Context information can be derived in several ways:
上下文信息可以通过几种方式导出：
o External sources
o 外部来源
o Network node classification
o 网络节点分类
o Service function classification
o 服务功能分类
There are a number of issues that solutions need to address, and that the architecture informs but does not determine. This section lays out some of those concepts.
解决方案需要解决许多问题，体系结构可以提供信息，但不能确定这些问题。本节列出了其中的一些概念。
Much of the behavior of service chains is driven by operator and per-customer policy. This architecture is structured to isolate the policy interactions from the data plane and control logic.
服务链的许多行为都是由运营商和客户政策驱动的。该体系结构的结构将策略交互与数据平面和控制逻辑隔离开来。
Specifically, it is assumed that the service chaining control plane creates the service paths. The service chaining data plane is used to deliver the classified packets along the service chains to the intended service functions.
具体地说，假设服务链接控制平面创建服务路径。服务链数据平面用于沿着服务链将分类分组传送到预期的服务功能。
Policy, in contrast, interacts with the system in other places. Policies and policy engines may monitor service functions to decide if additional (or fewer) instances of services are needed. When applicable, those decisions may in turn result in interactions that direct the control logic to change the SFP placement or packet classification rules.
相反，政策与其他地方的制度相互作用。策略和策略引擎可以监视服务功能，以确定是否需要额外（或更少）的服务实例。在适用的情况下，这些决定可能反过来导致交互，从而指示控制逻辑改变SFP放置或分组分类规则。
Similarly, operator service policy, often managed by Operations or Business Support Systems (OSS or BSS), will frequently determine what service functions are available. Operator service policies also determine which sequences of functions are valid and are to be used or made available.
类似地，通常由运营或业务支持系统（OSS或BSS）管理的运营商服务策略将经常确定可用的服务功能。运营商服务政策还确定哪些功能序列是有效的，哪些功能序列将被使用或提供。
The offering of service chains to customers, and the selection of which service chain a customer wishes to use, are driven by a combination of operator and customer policies using appropriate portals in conjunction with the OSS and BSS tools. These selections then drive the service chaining control logic, which in turn establishes the appropriate packet classification rules.
向客户提供服务链，以及选择客户希望使用的服务链，是由运营商和客户政策的组合驱动的，使用适当的门户以及OSS和BSS工具。然后，这些选择驱动服务链控制逻辑，从而建立适当的数据包分类规则。
The SFC control plane is part of the overall SFC architecture, and this section describes its high-level functions. However, the detailed definition of the SFC control plane is outside the scope of this document.
SFC控制平面是整个SFC体系结构的一部分，本节介绍其高级功能。然而，SFC控制平面的详细定义不在本文件范围内。
The SFC control plane is responsible for constructing SFPs, translating SFCs to forwarding paths, and propagating path information to participating nodes to achieve requisite forwarding behavior to construct the service overlay. For instance, an SFC
SFC控制平面负责构建SFP，将SFC转换为转发路径，并将路径信息传播到参与节点，以实现构建服务覆盖所需的转发行为。例如，证监会
construction may be static; selecting exactly which SFFs and which SFs from those SFFs are to be used, or it may be dynamic, allowing the network to perform some or all of the choices of SFF or SF to use to deliver the selected service chain within the constraints represented by the service path.
施工可能是静态的；选择要使用的SFF以及这些SFF中的哪些SF，或者可以是动态的，允许网络执行SFF或SF的部分或全部选择，以在服务路径表示的约束内交付所选服务链。
In the SFC architecture, SFs are resources; the control plane manages and communicates their capabilities, availability, and location in fashions suitable for the transport and SFC operations in use. The control plane is also responsible for the creation of the context (see below). The control plane may be distributed (using new or existing control-plane protocols), or be centralized, or a combination of the two.
在SFC架构中，SF是资源；控制平面以适合使用中的运输和SFC操作的方式管理和传达其能力、可用性和位置。控制平面还负责创建上下文（请参见下文）。控制平面可以是分布式的（使用新的或现有的控制平面协议），或者是集中式的，或者两者的组合。
The SFC control plane provides the following functionality:
SFC控制平面提供以下功能：
1. An SFC-enabled domain wide view of all available service function resources as well as the network locators through which they are reachable.
1. 支持SFC的域范围视图，可查看所有可用的服务功能资源以及可通过其访问的网络定位器。
2. Uses SFC policy to construct service function chains, and associated SFPs.
2. 使用SFC策略构建服务功能链和相关SFP。
3. Selection of specific SFs for a requested SFC, either statically (using specific SFs) or dynamically (using service explicit SFs at the time of delivering traffic to them).
3. 为请求的SFC选择特定SF，静态（使用特定SF）或动态（在向其交付流量时使用服务显式SF）。
4. Provides requisite SFC data-plane information to the SFC architecture components, most notably the SFF.
4. 向SFC体系结构组件（尤其是SFF）提供必要的SFC数据平面信息。
5. Provides the metadata and usage information classifiers need so that they in turn can provide this metadata for appropriate packets in the data plane.
5. 提供分类器所需的元数据和使用信息，以便它们反过来可以为数据平面中的适当数据包提供此元数据。
6. When needed, provide information including policy information to other SFC elements to be able to properly interpret metadata.
6. 必要时，向其他SFC元素提供包括策略信息在内的信息，以便能够正确解释元数据。
The SFC system may be responsible for managing all resources necessary for the SFC components to function. This includes network constraints used to plan and choose network path(s) between service function forwarders, network communication paths between service function forwarders and their attached service functions, characteristics of the nodes themselves such as memory, number of virtual interfaces, routes, and instantiation, configuration, and deletion of SFs.
SFC系统可能负责管理SFC组件运行所需的所有资源。这包括用于规划和选择服务功能转发器之间的网络路径的网络约束、服务功能转发器及其附加服务功能之间的网络通信路径、节点本身的特性，如内存、虚拟接口数量、路由以及实例化、配置、，和删除SFs。
The SFC system will also be required to reflect policy decisions about resource control, as expressed by other components in the system.
证券及期货事务监察委员会制度亦须反映有关资源管制的政策决定，一如该制度内其他组成部分所述。
While all of these aspects are part of the overall system, they are beyond the scope of this architecture.
虽然所有这些方面都是整个系统的一部分，但它们超出了此体系结构的范围。
This SFC architecture is predicated on topological independence from the underlying forwarding topology. Consequently, a service topology is created by service function paths or by the local decisions of the service function forwarders based on the constraints expressed in the SFP. Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once. The Service Chaining solution needs to permit these limited and policy-compliant loops. At the same time, the solutions must ensure that indefinite and unbounded loops cannot be formed, as such would consume unbounded resources without delivering any value.
此SFC体系结构基于与底层转发拓扑的拓扑独立性。因此，服务拓扑由服务功能路径或服务功能转发器基于SFP中表示的约束的本地决策创建。由于覆盖限制，分组转发路径可能需要多次访问同一SFF，并且在一些不太常见的情况下，甚至可能需要多次访问同一SF。服务链解决方案需要允许这些有限且符合策略的循环。同时，解决方案必须确保不能形成无限循环和无界循环，因为这样会消耗无界资源而不会产生任何价值。
In other words, this architecture requires the solution to prevent infinite service function loops, even when service functions may be invoked multiple times in the same SFP.
换句话说，这种体系结构需要解决方案来防止无限的服务函数循环，即使在同一个SFP中可能多次调用服务函数时也是如此。
Supporting function elasticity and high-availability should not overly complicate SFC or lead to unnecessary scalability problems.
支持功能弹性和高可用性不应使SFC过于复杂或导致不必要的可伸缩性问题。
In the simplest case, where there is only a single function in the SFP (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC.
在最简单的情况下，如果SFP中只有一个函数（下一个跃点是流的目标地址或到该目标的适当下一个跃点），可以认为可能不需要SFC。
In the cases where the classifier is separate from the single function or a function at the terminal address may need a sub-prefix (e.g., finer-grained address information) or per-subscriber metadata, a single SFP exists (i.e., the metadata changes but the SFP does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4.
在分类器与单个功能分离的情况下，或者终端地址处的功能可能需要子前缀（例如，更细粒度的地址信息）或每个订户元数据，则存在单个SFP（即，元数据改变，但SFP不改变），而不管流的潜在终端地址的数量。这就是简单负载平衡器的情况。参见图4。
+---+ +---++--->web server
source+-->|sff|+-->|sf1|+--->web server
+---+ +---++--->web server
+---+ +---++--->web server
source+-->|sff|+-->|sf1|+--->web server
+---+ +---++--->web server
Figure 4: Simple Load Balancing
图4：简单的负载平衡
By extrapolation, in the case where intermediary functions within a chain had similar "elastic" behaviors, we do not need separate chains to account for this behavior -- as long as the traffic coalesces to a common next-hop after the point of elasticity.
通过外推，在链中的中介函数具有类似的“弹性”行为的情况下，我们不需要单独的链来解释这种行为——只要流量在弹性点之后合并到一个公共的下一跳。
In Figure 5, we have a chain of five service functions between the traffic source and its destination.
在图5中，我们在流量源和目的地之间有一个由五个服务功能组成的链。
+---+ +---+ +---+ +---+ +---+ +---+
|sf2| |sf2| |sf3| |sf3| |sf4| |sf4|
+---+ +---+ +---+ +---+ +---+ +---+
| | | | | |
+-----+-----+ +-----+-----+
| |
+ +
+---+ +---+ +---+ +---+ +---+
source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
+---+ +---+ +---+ +---+ +---+
+ + +
| | |
+---+ +---+ +---+
|sf1| |sf3| |sf5|
+---+ +---+ +---+
+---+ +---+ +---+ +---+ +---+ +---+
|sf2| |sf2| |sf3| |sf3| |sf4| |sf4|
+---+ +---+ +---+ +---+ +---+ +---+
| | | | | |
+-----+-----+ +-----+-----+
| |
+ +
+---+ +---+ +---+ +---+ +---+
source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
+---+ +---+ +---+ +---+ +---+
+ + +
| | |
+---+ +---+ +---+
|sf1| |sf3| |sf5|
+---+ +---+ +---+
Figure 5: Load Balancing
图5：负载平衡
This would be represented as one service function path: sf1 -> sf2 -> sf3 -> sf4 -> sf5. The SFF is a logical element, which may be made up of one or multiple components. In this architecture, the SFF may handle load distribution based on policy.
这将表示为一个服务功能路径：sf1->sf2->sf3->sf4->sf5。SFF是一个逻辑元素，可以由一个或多个组件组成。在此架构中，SFF可以基于策略处理负载分配。
It can also be seen in the above that the same service function may be reachable through multiple SFFs, as discussed earlier. The selection of which SFF to use to reach sf3 may be made by the control logic in defining the SFP, or may be left to the SFFs themselves, depending upon policy, solution, and deployment constraints. In the latter case, it needs to be assured that exactly one SFF takes responsibility to steer traffic through sf3.
从上面还可以看出，如前面所讨论的，可以通过多个SFF访问相同的服务功能。根据策略、解决方案和部署约束，可由控制逻辑在定义SFP时选择使用哪个SFF来达到sf3，也可由SFF自己选择。在后一种情况下，需要确保只有一个SFF负责引导通过sf3的交通。
This architecture prescribes that additional information be added to packets to identify service function paths and often to represent metadata. It also envisions adding transport information to carry packets along service function paths, at least between service function forwarders. This added information increases the size of the packet to be carried by service chaining. Such additions could
该体系结构规定向数据包添加附加信息，以标识服务功能路径，并且通常表示元数据。它还设想添加传输信息以沿着服务功能路径传送数据包，至少在服务功能转发器之间。此添加的信息增加了服务链要承载的数据包的大小。这样的增加可能会
potentially increase the packet size beyond the MTU supported on some or all of the media used in the service chaining domain.
可能会将数据包大小增加到服务链域中使用的部分或所有媒体上支持的MTU之外。
Such packet size increases can thus cause operational MTU problems. Requiring fragmentation and reassembly in an SFF would be a major processing increase and might be impossible with some transports. Expecting service functions to deal with packets fragmented by the SFC function might be onerous even when such fragmentation was possible. Thus, at the very least, solutions need to pay attention to the size cost of their approach. There may be alternative or additional means available, although any solution needs to consider the trade-offs.
因此，这种数据包大小的增加可能导致操作MTU问题。需要在SFF中进行碎片化和重新组装将是一个主要的处理增加，并且对于某些传输来说可能是不可能的。期望服务函数处理由SFC函数分割的数据包可能会很繁重，即使这种分割是可能的。因此，解决方案至少需要注意其方法的规模成本。可能有替代或附加的手段可用，尽管任何解决方案都需要考虑权衡。
These considerations apply to any generic architecture that increases the header size. There are also more specific MTU considerations: Effects on Path MTU Discovery (PMTUD) as well as deployment considerations. Deployments within a single administrative control or even a single data center complex can afford more flexibility in dealing with larger packets, and deploying existing mitigations that decrease the likelihood of fragmentation or discard.
这些注意事项适用于任何增加头大小的通用体系结构。还有更具体的MTU注意事项：对路径MTU发现（PMTUD）的影响以及部署注意事项。在单个管理控制或甚至单个数据中心复合体内的部署可以提供更大的灵活性来处理较大的数据包，并部署现有的缓解措施，以降低碎片化或丢弃的可能性。
Operations, Administration, and Maintenance (OAM) tools are an integral part of the architecture. These serve various purposes, including fault detection and isolation, and performance management. For example, there are many advantages of SFP liveness detection, including status reporting, support for resiliency operations and policies, and an enhanced ability to balance load.
操作、管理和维护（OAM）工具是体系结构的一个组成部分。这些服务有多种用途，包括故障检测和隔离以及性能管理。例如，SFP活动性检测有许多优点，包括状态报告、支持弹性操作和策略以及增强的负载平衡能力。
Service function paths create a services topology, and OAM performs various functions within this service layer. Furthermore, SFC OAM follows the same architectural principles of SFC in general. For example, topological independence (including the ability to run OAM over various overlay technologies) and classification-based policy.
服务功能路径创建服务拓扑，OAM在此服务层中执行各种功能。此外，SFC OAM一般遵循SFC相同的体系结构原则。例如，拓扑独立性（包括在各种覆盖技术上运行OAM的能力）和基于分类的策略。
We can subdivide the SFC OAM architecture in two parts:
我们可以将SFC OAM体系结构细分为两部分：
o In-band: OAM packets follow the same path and share fate with user packets, within the service topology. For this, they also follow the architectural principle of consistent policy identifiers, and use the same path IDs as the service chain data packets. Load balancing and SFC encapsulation with packet forwarding are particularly important here.
o 带内：OAM数据包在服务拓扑中遵循相同的路径并与用户数据包共享命运。为此，它们还遵循一致策略标识符的体系结构原则，并使用与服务链数据包相同的路径ID。负载平衡和SFC封装与数据包转发在这里尤为重要。
o Out-of-band: Reporting beyond the actual data plane. An additional layer beyond the data-plane OAM allows for additional alerting and measurements.
o 带外：超出实际数据平面的报告。数据平面OAM之外的附加层允许附加警报和测量。
This architecture prescribes end-to-end SFP OAM functions, which implies SFF understanding of whether an in-band packet is an OAM or user packet. However, service function validation is outside of the scope of this architecture, and application-level OAM is not what this architecture prescribes.
该体系结构规定了端到端SFP OAM功能，这意味着SFF了解带内数据包是OAM还是用户数据包。但是，服务功能验证不在该体系结构的范围内，并且应用程序级OAM不是该体系结构规定的。
Some of the detailed functions performed by SFC OAM include fault detection and isolation in a service function path or a service function, verification that connectivity using SFPs is both effective and directing packets to the intended service functions, service path tracing, diagnostic and fault isolation, alarm reporting, performance measurement, locking and testing of service functions, validation with the control plane (see Section 5.2), and also allow for vendor-specific as well as experimental functions. SFC should leverage and, if needed, extend relevant existing OAM mechanisms.
SFC OAM执行的一些详细功能包括服务功能路径或服务功能中的故障检测和隔离、验证使用SFP的连接是否有效并将数据包定向到预期服务功能、服务路径跟踪、诊断和故障隔离、报警报告、，服务功能的性能测量、锁定和测试、控制平面验证（见第5.2节），以及供应商特定功能和实验功能。证监会应利用并在必要时扩展相关的现有OAM机制。
As a practical operational requirement, any service chaining solution needs to be able to respond effectively, and usually very quickly, to failure conditions. These may be failures of connectivity in the network between SFFs, failures of SFFs, or failures of SFs. Per-SF state (as, for example, stateful-firewall state) is the responsibility of the SF, and not addressed by this architecture.
作为一个实际的操作需求，任何服务链解决方案都需要能够有效地（通常是非常快速地）响应故障条件。这些可能是SFF之间的网络连接故障、SFF故障或SFs故障。每个SF状态（例如，有状态防火墙状态）是SF的责任，而不是由该体系结构解决。
Multiple techniques are available to address this issue. Solutions can describe both what they require and what they allow to address failure. Solutions can make use of flexible specificity of service function paths, if the SFF can be given enough information in a timely fashion to do this. Solutions can also make use of MAC- or IP-level redundancy mechanisms such as Virtual Router Redundancy Protocol (VRRP). Also, particularly for SF failures, load balancers co-located with the SFF or as part of the service function delivery mechanism can provide such robustness.
有多种技术可用于解决此问题。解决方案既可以描述它们需要什么，也可以描述它们允许什么来解决故障。如果能够及时向SFF提供足够的信息，则解决方案可以利用服务功能路径的灵活特性。解决方案还可以使用MAC或IP级别的冗余机制，如虚拟路由器冗余协议（VRRP）。此外，特别是对于SF故障，与SFF共存或作为服务功能交付机制的一部分的负载平衡器可以提供这种健壮性。
Similarly, operational requirements imply resilience in the face of load changes. While mechanisms for managing (e.g., monitoring, instantiating, loading images, providing configuration to SFC control, deleting, etc.) virtual machines are out of scope for this architecture, solutions can and are aided by describing how they can make use of scaling mechanisms.
类似地，运营需求意味着在负载变化时的弹性。虽然用于管理虚拟机的机制（例如，监视、实例化、加载映像、为SFC控制提供配置、删除等）超出了此体系结构的范围，但解决方案可以并且可以通过描述如何使用缩放机制来辅助解决方案。
The architecture described here is different from the current model, and moving to the new model could lead to different security arrangements and modeling. In the SFC architecture, a relatively static topologically-dependent deployment model is replaced with the chaining of sets of service functions. This can change the flow of data through the network, and the security and privacy considerations of the protocol and deployment will need to be reevaluated in light of the new model.
这里描述的体系结构与当前模型不同，迁移到新模型可能导致不同的安全安排和建模。在SFC体系结构中，一个相对静态的拓扑依赖部署模型被一系列服务功能的链接所取代。这可能会改变通过网络的数据流，需要根据新模型重新评估协议和部署的安全和隐私考虑。
Security considerations apply to the realization of this architecture, in particular to the documents that will define protocols. Such realization ought to provide means to protect against security and privacy attacks in the areas hereby described.
安全注意事项适用于此体系结构的实现，特别是将定义协议的文档。这种实现应提供在本文所述区域防止安全和隐私攻击的方法。
Building from the categorization of [RFC7498], we can largely divide the security considerations into four areas:
根据[RFC7498]的分类，我们可以将安全考虑分为四个方面：
Service Overlay: Underneath the service function forwarders, the components that are responsible for performing the transport forwarding consult the outer-transport encapsulation for underlay forwarding. Used transport mechanisms should satisfy the security requirements of the specific SFC deployment. These requirements typically include varying degrees of traffic separation, protection against different attacks (e.g., spoofing, man-in-the-middle, brute-force, or insertion attacks), and can also include authenticity and integrity checking, and/or confidentiality provisions, for both the network overlay transport and traffic it encapsulates.
服务覆盖：在服务功能转发器下方，负责执行传输转发的组件将参考外部传输封装以进行参考底图转发。使用的传输机制应满足特定SFC部署的安全要求。这些要求通常包括不同程度的流量分离、针对不同攻击的保护（例如，欺骗、中间人攻击、暴力攻击或插入攻击），还可以包括真实性和完整性检查，和/或针对其封装的网络覆盖传输和流量的保密规定。
Boundaries: Specific requirements may need to be enforced at the boundaries of an SFC-enabled domain. These include, for example, to avoid leaking SFC information, and to protect its borders against various forms of attacks. If untrusted parties can inject packets that will be treated as being properly classified for service chaining, there are a large range of attacks that can be mounted against the resulting system. Depending upon deployment details, these likely include spoofing packets from users and creating DDoS and reflection attacks of various kinds. Thus, when transport mechanisms are selected for use with SFC, they MUST ensure that outside parties cannot inject SFC packets that will be accepted for processing into the domain. This border security MUST include any tunnels to other domains. If those tunnels are to be used for SFC without reclassification, then the tunnel MUST include additional techniques to ensure the integrity and validity of such packets.
边界：可能需要在启用SFC的域边界强制执行特定要求。例如，这些措施包括避免泄露证监会信息，保护其边界免受各种形式的攻击。如果不受信任的方可以注入数据包，这些数据包将被视为服务链的正确分类，那么会有大量攻击针对生成的系统。根据部署细节，这些可能包括来自用户的欺骗数据包以及创建各种DDoS和反射攻击。因此，当选择传输机制与SFC一起使用时，它们必须确保外部各方不能将被接受处理的SFC数据包注入域中。这种边界安全必须包括通往其他域的任何隧道。如果这些隧道用于SFC而不重新分类，则隧道必须包括其他技术，以确保此类数据包的完整性和有效性。
Classification: Classification is used at the ingress edge of an SFC-enabled domain. Policy for this classification is done using a plurality of methods. Whatever method is used needs to consider a range of security issues. These include appropriate authentication and authorization of classification policy, potential confidentiality issues of that policy, protection against corruption, and proper application of policy with needed segregation of application. This includes proper controls on the policies that drive the application of the SFC encapsulation and associated metadata to packets. Similar issues need to be addressed if classification is performed within a service chaining domain, i.e., reclassification.
分类：分类用于启用SFC的域的入口边缘。此分类的策略使用多种方法完成。无论使用何种方法，都需要考虑一系列安全问题。其中包括分类政策的适当认证和授权、该政策的潜在保密问题、反腐败保护，以及政策的适当应用和必要的应用分离。这包括对驱动将SFC封装和相关元数据应用于数据包的策略的适当控制。如果在服务链接域内执行分类，即重新分类，则需要解决类似的问题。
SFC Encapsulation: The SFC encapsulation provides at a minimum SFP identification, and carries metadata. An operator may consider the SFC Metadata as sensitive. From a privacy perspective, a user may be concerned about the operator revealing data about (and not belonging to) the customer. Therefore, solutions should consider whether there is a risk of sensitive information slipping out of the operator's control. Issues of information exposure should also consider flow analysis. Further, when a specific metadata element is defined, it should be carefully considered whether origin authentication is needed for it.
SFC封装：SFC封装至少提供SFP标识，并携带元数据。操作员可以认为SFC元数据是敏感的。从隐私的角度来看，用户可能会担心运营商泄露有关（不属于）客户的数据。因此，解决方案应该考虑是否存在敏感信息从操作人员的控制中滑出的风险。信息暴露问题也应考虑流量分析。此外，在定义特定元数据元素时，应仔细考虑是否需要对其进行源身份验证。
A classifier may have privileged access to information about a packet or inside a packet (see Section 3, item 4, and Section 4.9) that is then communicated in the metadata. The threat of leaking this private data needs to be mitigated [RFC6973]. As one example, if private data is represented by an identifier, then a new identifier can be allocated, such that the mapping from the private data to the new identifier is not broadly shared.
分类器可以有特权访问有关数据包或数据包内部的信息（参见第3节第4项和第4.9节），然后在元数据中进行通信。需要减轻泄漏此私有数据的威胁[RFC6973]。作为一个示例，如果私有数据由标识符表示，则可以分配新标识符，使得从私有数据到新标识符的映射不被广泛共享。
Some metadata added to and carried in SFC packets is sensitive for various reasons, including potentially revealing personally identifying information. Realizations of the architecture MUST protect such information to ensure that it is handled with suitable care and precautions against inappropriate dissemination. This can have implications to the data plane, the control plane, or both. Data-plane protocol definitions for SFC can include suitable provisions to protect such information for use when handling sensitive information, with packet or SFP granularity. Equally, the control mechanisms used with SFC can have provisions to determine that such mechanisms are available, and to ensure that they are used when needed. Inability to do so needs to result in error indications to appropriate management systems. In particular, when the control systems know that sensitive information may potentially be added to
添加到SFC数据包中并在其中携带的某些元数据出于各种原因是敏感的，包括可能泄露个人身份信息。体系结构的实现必须保护这些信息，以确保以适当的谨慎和预防措施处理这些信息，防止不适当的传播。这可能对数据平面、控制平面或两者都有影响。SFC的数据平面协议定义可包括适当的规定，以保护此类信息，以便在处理具有数据包或SFP粒度的敏感信息时使用。同样，与证监会一起使用的控制机制可以有规定来确定这些机制是否可用，并确保在需要时使用这些机制。如果无法做到这一点，则需要向适当的管理系统发出错误指示。特别是，当控制系统知道可能会将敏感信息添加到
packets at certain points on certain service chains, the control mechanism MUST verify that appropriate protective treatment of NSH information is available from the point where the information is added to the point where it will be removed. If such mechanisms are unavailable, error notifications SHOULD be generated.
在某些服务链上的某些点上的数据包，控制机制必须验证NSH信息的适当保护处理从添加信息的点到删除信息的点是可用的。如果此类机制不可用，则应生成错误通知。
Additionally, SFC OAM functions need to not negatively affect the security considerations of an SFC-enabled domain.
此外，SFC OAM功能不需要对启用SFC的域的安全考虑产生负面影响。
Finally, all entities (software or hardware) interacting with the service chaining mechanisms need to provide means of security against malformed, poorly configured (deliberate or not) protocol constructs and loops. These considerations are largely the same as those in any network, particularly an overlay network.
最后，与服务链机制交互的所有实体（软件或硬件）都需要提供针对格式错误、配置不良（有意或无意）的协议构造和循环的安全措施。这些注意事项与任何网络，特别是覆盖网络中的注意事项基本相同。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[Boucadair2014] Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., Guichard, J., and C. Pignataro, "Service Function Chaining: Framework & Architecture", Work in Progress, draft-boucadair-sfc-framework-02, February 2014.
[Boucadair2014]Boucadair，M.，Jacquenet，C.，Parker，R.，Lopez，D.，Guichard，J.，和C.Pignataro，“服务功能链：框架和架构”，在建工程，草稿-Boucadair-sfc-Framework-022014年2月。
[Quinn2014] Quinn, P. and J. Halpern, "Service Function Chaining (SFC) Architecture", Work in Progress, draft-quinn-sfc-arch-05, May 2014.
[Quinn2014]Quinn，P.和J.Halpern，“服务功能链（SFC）架构”，正在进行的工作，草稿-Quinn-SFC-arch-05，2014年5月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，DOI 10.17487/RFC3022，2001年1月<http://www.rfc-editor.org/info/rfc3022>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 6296DOI 10.17487/RFC62962011年6月<http://www.rfc-editor.org/info/rfc6296>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <http://www.rfc-editor.org/info/rfc7498>.
[RFC7498]Quinn，P.，Ed.和T.Nadeau，Ed.，“服务功能链接的问题陈述”，RFC 7498，DOI 10.17487/RFC7498，2015年4月<http://www.rfc-editor.org/info/rfc7498>.
Acknowledgments
致谢
The editors would like to thank Sam Aldrin, Alia Atlas, Nicolas Bouthors, Stewart Bryant, Linda Dunbar, Alla Goldner, Ken Gray, Barry Greene, Anil Gunturu, David Harrington, Shunsuke Homma, Dave Hood, Chris Inacio, Nagendra Kumar, Hongyu Li, Andrew Malis, Guy Meador III, Kengo Naito, Thomas Narten, Ron Parker, Reinaldo Penno, Naiming Shen, Xiaohu Xu, and Lucy Yong for a thorough review and useful comments.
编辑们要感谢山姆·奥尔德林、艾莉亚·阿特拉斯、尼古拉斯·鲍托斯、斯图尔特·布莱恩特、琳达·邓巴、阿拉·戈德纳、肯·格雷、巴里·格林、阿尼尔·冈图鲁、大卫·哈灵顿、顺介·霍玛、戴夫·胡德、克里斯·伊纳西奥、纳甘德拉·库马尔、李洪玉、安德鲁·马里斯、盖·米多三世、肯戈·奈托、托马斯·纳腾、罗恩·帕克、雷纳尔多·佩诺、沈乃明、，徐晓虎和杨露西进行了深入的回顾和有益的评论。
The initial draft of this document was the result of merging two previous documents, and this section lists the acknowledgments from those documents.
本文件的初稿是合并前两份文件的结果，本节列出了对这些文件的确认。
From "Service Function Chaining (SFC) Architecture" [Quinn2014]
来自“服务功能链（SFC）架构”[Quinn2014]
The authors would like to thank David Ward, Abhijit Patra, Nagaraj Bagepalli, Darrel Lewis, Ron Parker, Lucy Yong, and Christian Jacquenet for their review and comments.
作者要感谢David Ward、Abhijit Patra、Nagaraj Bagepalli、Darrel Lewis、Ron Parker、Lucy Yong和Christian Jacquenet的评论和评论。
From "Service Function Chaining (SF) - Framework and Architecture" [Boucadair2014]:
来自“服务功能链（SF）-框架和体系结构”[Boucadair2014]：
Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, R. White, and B. Chatras for their review and comments.
非常感谢D.Abgrall、D.Minodier、Y.Le Goff、D.Cheng、R.White和B.Chatras的评论和评论。
Contributors
贡献者
As noted above, this document is the result of merging two previous documents. This section lists those who provided important ideas and text that fed into this architecture.
如上所述，本文件是合并前两份文件的结果。本节列出了为该体系结构提供重要思想和文本的人。
The authors of "Service Function Chaining (SFC) - Framework and Architecture" [Boucadair2014] were:
“服务功能链（SFC）-框架和架构”[Boucadair2014]的作者是：
Mohamed Boucadair Christian Jacquenet Ron Parker Diego R. Lopez Jim Guichard Carlos Pignataro
穆罕默德·布卡达尔·克里斯蒂安·雅克内特·罗恩·帕克·迭戈·洛佩兹·吉姆·吉查德·卡洛斯·皮格纳塔罗
The contributors were:
贡献者是：
Parviz Yegani Paul Quinn Linda Dunbar
帕维兹·耶加尼·保罗·奎因·琳达·邓巴
The authors of "Service Function Chaining (SFC) Architecture" [Quinn2014] were:
“服务功能链（SFC）体系结构”[Quinn2014]的作者是：
Paul Quinn (editor) Joel Halpern (editor)
Paul Quinn（编辑）Joel Halpern（编辑）
The contributors were:
贡献者是：
Puneet Agarwal Andre Beliveau Kevin Glavin Ken Gray Jim Guichard Surendra Kumar Darrel Lewis Nic Leymann Rajeev Manur Thomas Nadeau Carlos Pignataro Michael Smith Navindra Yadav
阿加瓦尔·安德烈·贝利沃·凯文·格拉文·肯·格雷·吉姆·吉查德·苏伦德拉·库马尔·达雷尔·刘易斯·尼克·莱曼·拉吉耶夫·曼努尔·托马斯·纳多·卡洛斯·皮格纳塔罗·迈克尔·史密斯·纳文德拉·亚达夫
Authors' Addresses
作者地址
Joel Halpern (editor) Ericsson
乔尔·哈尔佩恩（编辑）爱立信
Email: jmh@joelhalpern.com
Email: jmh@joelhalpern.com
Carlos Pignataro (editor) Cisco Systems, Inc.
卡洛斯·皮格纳塔罗（编辑）思科系统公司。
Email: cpignata@cisco.com
Email: cpignata@cisco.com