Internet Engineering Task Force (IETF) D. Dolson
Request for Comments: 8459 Sandvine
Category: Experimental S. Homma
ISSN: 2070-1721 NTT
D. Lopez
Telefonica I+D
M. Boucadair
Orange
September 2018
Internet Engineering Task Force (IETF) D. Dolson
Request for Comments: 8459 Sandvine
Category: Experimental S. Homma
ISSN: 2070-1721 NTT
D. Lopez
Telefonica I+D
M. Boucadair
Orange
September 2018
Hierarchical Service Function Chaining (hSFC)
分层服务功能链（hSFC）
Abstract
摘要
Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.
分层服务功能链（hSFC）是一种网络体系结构，允许组织将大规模网络分解为多个管理域。
The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.
hSFC的目标是使大型网络更易于设计、更易于控制，并支持大型网络运营商内的独立功能组。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8459.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8459.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Experiment Goals . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 6
3.1. Upper Level . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 8
4. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 10
4.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 10
4.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 11
4.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 12
4.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 13
4.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 13
4.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 14
4.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 16
4.3. Decrementing Service Index . . . . . . . . . . . . . . . 16
4.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 16
5. Subdomain Classifier . . . . . . . . . . . . . . . . . . . . 17
6. Control Plane Elements . . . . . . . . . . . . . . . . . . . 18
7. Extension for Adapting to NSH-Unaware Service Functions . . . 18
7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Requirements for an IBN . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Hierarchical Service Function Chaining . 24
A.1. Reducing the Number of Service Function Paths . . . . . . 24
A.2. Managing a Distributed DC Network . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Experiment Goals . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Hierarchical Service Function Chaining (hSFC) . . . . . . . . 6
3.1. Upper Level . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Lower Levels . . . . . . . . . . . . . . . . . . . . . . 8
4. Internal Boundary Node (IBN) . . . . . . . . . . . . . . . . 10
4.1. IBN Path Configuration . . . . . . . . . . . . . . . . . 10
4.1.1. Flow-Stateful IBN . . . . . . . . . . . . . . . . . . 11
4.1.2. Encoding Upper-Level Paths in Metadata . . . . . . . 12
4.1.3. Using Unique Paths per Upper-Level Path . . . . . . . 13
4.1.4. Nesting Upper-Level NSH within Lower-Level NSH . . . 13
4.1.5. Stateful/Metadata Hybrid . . . . . . . . . . . . . . 14
4.2. Gluing Levels Together . . . . . . . . . . . . . . . . . 16
4.3. Decrementing Service Index . . . . . . . . . . . . . . . 16
4.4. Managing TTL . . . . . . . . . . . . . . . . . . . . . . 16
5. Subdomain Classifier . . . . . . . . . . . . . . . . . . . . 17
6. Control Plane Elements . . . . . . . . . . . . . . . . . . . 18
7. Extension for Adapting to NSH-Unaware Service Functions . . . 18
7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Requirements for an IBN . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 21
9.2. Infinite Forwarding Loops . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Examples of Hierarchical Service Function Chaining . 24
A.1. Reducing the Number of Service Function Paths . . . . . . 24
A.2. Managing a Distributed DC Network . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Service Function Chaining (SFC) is a technique for prescribing differentiated traffic-forwarding policies within an SFC-enabled domain. The SFC architecture is described in detail in [RFC7665] and is not repeated here.
服务功能链（SFC）是一种在支持SFC的域中规定差异化流量转发策略的技术。[RFC7665]中详细描述了SFC体系结构，此处不再重复。
This document focuses on the difficult problem of implementing SFC across a large, geographically dispersed network, potentially comprised of millions of hosts and thousands of network-forwarding elements and which may involve multiple operational teams (with varying functional responsibilities). We recognize that some stateful Service Functions (SFs) require bidirectional traffic for transport-layer sessions (e.g., NATs, firewalls). We assume that some Service Function Paths (SFPs) need to be selected on the basis of transport-layer coordinate (typically, the 5-tuple of source IP address, source port number, destination IP address, destination port number, and transport protocol) stickiness to specific stateful SF instances.
本文件重点讨论在地理位置分散的大型网络上实施SFC的难题，该网络可能由数百万台主机和数千个网络转发元件组成，可能涉及多个运营团队（具有不同的职能职责）。我们认识到，一些有状态服务功能（SF）需要传输层会话的双向流量（例如NAT、防火墙）。我们假设需要根据传输层坐标（通常是源IP地址、源端口号、目标IP地址、目标端口号和传输协议的5元组）对特定有状态SF实例的粘性来选择一些服务功能路径（SFP）。
Difficult problems are often made easier by decomposing them in a hierarchical (nested) manner. So, instead of considering a single SFC control plane that can manage (create, withdraw, supervise, etc.) complete SFPs from one end of the network to the other, we decompose the network into smaller domains operated by as many SFC control plane components (under the same administrative entity). Coordination between such components is further discussed in this document.
通过以分层（嵌套）的方式对难题进行分解，难题通常会变得更容易。因此，我们将网络分解为更小的域，由尽可能多的SFC控制平面组件（在同一管理实体下）操作，而不是考虑一个能够管理（创建、撤销、监督等）从网络一端到另一端的完整SFP的单一SFC控制平面。本文件将进一步讨论这些组件之间的协调。
Each subdomain may support a subset of the network applications or a subset of the users. Decomposing a network should be done with care to ease monitoring and troubleshooting of the network and services as a whole. The criteria for decomposing a domain into multiple SFC-enabled subdomains are beyond the scope of this document. These criteria are deployment specific.
每个子域可以支持网络应用程序的子集或用户的子集。分解网络时应小心，以便于对整个网络和服务进行监视和故障排除。将域分解为多个启用SFC的子域的标准超出了本文档的范围。这些标准是特定于部署的。
An example of simplifying a network by using multiple SFC-enabled domains is further discussed in [USE-CASES].
[用例]中进一步讨论了通过使用多个支持SFC的域简化网络的示例。
We assume the SFC-aware nodes use the Network Service Header (NSH) [RFC8300] or a similar labeling mechanism. Examples are described in Appendix A.
我们假设支持SFC的节点使用网络服务报头（NSH）[RFC8300]或类似的标记机制。附录A中描述了示例。
The SFC-enabled domains discussed in this document are assumed to be under the control of a single organization (an operator, typically), such that there is a strong trust relationship between the domains. The intention of creating multiple domains is to improve the ability
本文档中讨论的支持SFC的域被假定为在单个组织（通常是运营商）的控制下，因此域之间存在强大的信任关系。创建多个域的目的是提高能力
to operate a network. It is outside of the scope of this document to consider domains operated by different organizations or dwell on interoperator considerations.
操作网络。考虑不同组织操作的域或考虑互操作者的考虑，在本文档的范围之外。
We introduce the concept of an Internal Boundary Node (IBN) that acts as a gateway between the levels of the hierarchy. We also discuss options for realizing this function.
我们引入了内部边界节点（IBN）的概念，它充当层次结构级别之间的网关。我们还讨论了实现此功能的选项。
This document defines an architecture that aims to solve complications that may be encountered when deploying SFC in large networks. A single network is therefore decomposed into multiple subdomains, each treated as an SFC-enabled domain. Levels of hierarchy are defined, together with SFC operations that are specific to each level. In order to ensure consistent SFC operations when multiple subdomains are involved, this document identifies and analyzes various options for IBNs to glue the layers together (Section 4.1).
本文档定义了一种体系结构，旨在解决在大型网络中部署SFC时可能遇到的复杂问题。因此，单个网络被分解为多个子域，每个子域都被视为支持SFC的域。定义了层次结构的级别，以及特定于每个级别的SFC操作。为了确保涉及多个子域时SFC操作的一致性，本文件确定并分析了IBN将各层粘合在一起的各种选项（第4.1节）。
Because it does not make any assumptions about (1) how subdomains are defined, (2) whether one or multiple IBNs are enabled per subdomain, (3) whether the same IBN is solicited at both the ingress and egress of a subdomain for the same flow, (4) the nature of the internal paths to reach SFs within a subdomain, or (5) the lack of deployment feedback, this document does not call for a recommended option to glue the SFC layers together.
因为它没有对以下方面做出任何假设：（1）如何定义子域，（2）是否为每个子域启用一个或多个IBN，（3）是否在子域的入口和出口为相同的流请求相同的IBN，（4）到达子域内SFs的内部路径的性质，或（5）由于缺乏部署反馈，本文档不要求推荐将SFC层粘合在一起的选项。
Further experiments are required to test and evaluate the different options. A recommendation for hSFC might be documented in a future specification when the results of implementation and deployment of the aforementioned options are available.
需要进一步的实验来测试和评估不同的选项。当上述选项的实施和部署结果可用时，hSFC的建议可能会记录在未来的规范中。
It is not expected that all the options discussed in this document will be implemented and deployed. The lack of an implementation might be seen as a signal to recommend against a given option.
预计不会实施和部署本文件中讨论的所有选项。缺少实现可能被视为反对给定选项的信号。
This document makes use of the terms defined in Section 1.4 of [RFC7665] and Section 1.3 of [RFC8300].
本文件使用了[RFC7665]第1.4节和[RFC8300]第1.3节中定义的术语。
The following terms are defined:
定义了以下术语：
o Upper-level domain: the entire network domain to be managed.
o 上层域：要管理的整个网络域。
o Lower-level domain: a portion of the network (called a subdomain).
o 低级域：网络的一部分（称为子域）。
o Internal Boundary Node (IBN): is responsible for bridging packets between upper and lower levels of SFC-enabled domains.
o 内部边界节点（IBN）：负责在支持SFC的域的上层和下层之间桥接数据包。
A hierarchy has multiple levels: the topmost level encompasses the entire network domain to be managed, and lower levels encompass portions of the network. These levels are discussed in the following subsections.
层次结构有多个级别：最顶层包含要管理的整个网络域，较低的级别包含网络的部分。这些级别将在以下小节中讨论。
Considering the example depicted in Figure 1, a top-level network domain includes SFC data plane components distributed over a wide area, including:
考虑到图1所示的示例，顶级网络域包括分布在广域上的SFC数据平面组件，包括：
o Classifiers (CFs)
o 分类器（CFs）
o Service Function Forwarders (SFFs)
o 服务功能转发器（SFF）
o Subdomains
o 子域
+------------+
|Subdomain#1 |
| in DC1 |
+----+-------+
|
.---- SFF1 ------. +----+
+----+ / / | \--|CF#4|
--->|CF#1|--/---->' | \ +----+
+----+ / SC#1 | \
| | |
| V .------>|--->
| / / |
\ | / /
+----+ \ | / / +----+
|CF#2|---\ | / /---|CF#3|
+----+ '---- SFF2 ------' +----+
|
+----+-------+
|Subdomain#2 |
| in DC2 |
+------------+
+------------+
|Subdomain#1 |
| in DC1 |
+----+-------+
|
.---- SFF1 ------. +----+
+----+ / / | \--|CF#4|
--->|CF#1|--/---->' | \ +----+
+----+ / SC#1 | \
| | |
| V .------>|--->
| / / |
\ | / /
+----+ \ | / / +----+
|CF#2|---\ | / /---|CF#3|
+----+ '---- SFF2 ------' +----+
|
+----+-------+
|Subdomain#2 |
| in DC2 |
+------------+
Legend: SC#1: Service Chain 1 DC: Data Center
图例：SC#1:服务链1 DC:数据中心
Figure 1: Network-Wide View of Upper Level of Hierarchy
图1：上层层次结构的网络范围视图
One path is shown from edge classifier (CF#1) to SFF1 to Subdomain#1 (residing in Data Center 1) to SFF1 to SFF2 (residing in Data Center 2) to Subdomain#2 to SFF2 to network egress.
显示了从边缘分类器（CF#1）到SFF1到子域#1（位于数据中心1）到SFF1到SFF2（位于数据中心2）到子域#2到SFF2到网络出口的一条路径。
For the sake of clarity, components of the underlay network are not shown; an underlay network is assumed to provide connectivity between SFC data plane components.
为清楚起见，未显示参考底图网络的组件；假定参考底图网络提供SFC数据平面组件之间的连接。
Top-level SFPs carry packets from classifiers through a set of SFFs and subdomains, with the operations within subdomains being opaque to the upper levels.
顶级SFP通过一组SFF和子域携带来自分类器的数据包，子域内的操作对上层不透明。
We expect the system to include a top-level control plane having responsibility for configuring forwarding policies and traffic-classification rules.
我们希望系统包括一个顶级控制平面，负责配置转发策略和流量分类规则。
The top-level Service Chaining control plane manages end-to-end service chains and associated service function paths from network edge points to subdomains. It also configures top-level classifiers
顶级服务链控制平面管理从网络边缘点到子域的端到端服务链和相关服务功能路径。它还配置顶级分类器
at a coarse level (e.g., based on source or destination host) to forward traffic along paths that will transit across appropriate subdomains.
在粗略级别（例如，基于源主机或目标主机）沿将通过适当子域的路径转发流量。
Figure 1 shows one possible service chain passing from the edge through two subdomains to network egress. The top-level control plane does not configure traffic-classification rules or forwarding policies within the subdomains.
图1显示了一个可能的服务链，它从边缘经过两个子域到达网络出口。顶级控制平面不在子域内配置流量分类规则或转发策略。
At this network-wide level, the number of SFPs required is a linear function of the number of ways in which a packet is required to traverse different subdomains and egress the network. Note that the various paths that may be followed within a subdomain are not represented by distinct network-wide SFPs; specific policies at the ingress nodes of each subdomain bind flows to subdomain paths.
在这个网络范围的级别上，所需SFP的数量是数据包穿越不同子域和离开网络所需方式数量的线性函数。注意，子域内可能遵循的各种路径不由不同的网络范围SFP表示；每个子域的入口节点处的特定策略将流绑定到子域路径。
Packets are classified at the edge of the network to select the paths by which subdomains are to be traversed. At the ingress of each subdomain, packets are reclassified to paths directing them to the required SFs of the subdomain. At the egress of each subdomain, packets are returned to the top-level paths. Contrast this with an approach requiring the top-level classifier to select paths to specify all of the SFs in each subdomain.
在网络边缘对数据包进行分类，以选择要遍历子域的路径。在每个子域的入口处，分组被重新分类为将它们定向到子域的所需SFs的路径。在每个子域的出口处，数据包被返回到顶层路径。与此相反，这种方法要求顶级分类器选择路径来指定每个子域中的所有SF。
It should be assumed that some SFs require bidirectional symmetry of paths (see more in Section 5). Therefore, the classifiers at the top level must be configured with policies ensuring outgoing packets take the reverse path of incoming packets through subdomains.
应假定某些SF需要路径的双向对称性（详见第5节）。因此，顶层的分类器必须配置策略，确保传出数据包通过子域与传入数据包的路径相反。
Each of the subdomains in Figure 1 is an SFC-enabled domain.
图1中的每个子域都是支持SFC的域。
Figure 2 shows a subdomain interfaced with an upper-level domain by means of an Internal Boundary Node (IBN). An IBN acts as an SFC-aware SF in the upper-level domain and as a classifier in the lower-level domain. As such, data packets entering the subdomain are already SFC encapsulated. Also, it is the purpose of the IBN to apply classification rules and direct the packets to the selected local SFPs terminating at an egress IBN. Finally, the egress IBN restores packets to the original SFC shim and hands them off to SFFs.
图2显示了通过内部边界节点（IBN）与上层域接口的子域。IBN在上层域中充当SFC感知SF，在下层域中充当分类器。因此，进入子域的数据包已经被SFC封装。此外，IBN的目的是应用分类规则并将分组定向到在出口IBN处终止的所选本地sfp。最后，出口IBN将数据包恢复到原始SFC垫片，并将其交给SFFs。
Each subdomain intersects a subset of the total paths that are possible in the upper-level domain. An IBN is concerned with upper-level paths, but only those traversing its subdomain.
每个子域与上层域中可能的总路径的子集相交。IBN涉及上层路径，但只涉及那些穿过其子域的路径。
Each subdomain is likely to have a control plane that can operate independently of the top-level control plane, managing classification, forwarding paths, etc., within the level of the subdomain, with the details being opaque to the upper-level control elements. Section 4 provides more details about the behavior of an IBN.
每个子域可能都有一个控制平面，该控制平面可以独立于顶层控制平面运行，在子域的级别内管理分类、转发路径等，细节对上层控制元素是不透明的。第4节提供了有关IBN行为的更多详细信息。
The subdomain control plane configures the classification rules in the IBN, where SFC encapsulation of the top-level domain is converted to/from SFC encapsulation of the lower-level domain. The subdomain control plane also configures the forwarding rules in the SFFs of the subdomain.
子域控制平面配置IBN中的分类规则，其中顶级域的SFC封装转换为低级域的SFC封装，或从低级域的SFC封装转换为高级域的SFC封装。子域控制平面还配置子域的SFF中的转发规则。
+----+ +-----+ +----------------------+ +-----+
| | | SFF | | IBN 1 (in DC 1) | | SFF |
| |SC#1| | | +----------------+ | | |
->| |===============>| SFF |================>
| | +-----+ | +----------------+ | +-----+
| CF | | | ^ |
| | | v | |
| | |+--------------------+| Upper domain
| | ||CF, fwd/rev mapping ||
| | * * * * *|| and "glue" || * * * * *
| | * |+--------------------+| *
+----+ * | | | | | | Sub *
* +-o-o--------------o-o-+ domain*
* SC#2 | |SC#1 ^ ^ #1 *
* +-----+ | | | *
* | V | | *
* | +---+ +------+ | | *
* | |SFF|->|SF#1.1|--+ | *
* | +---+ +------+ | *
* V | *
* +---+ +------+ +---+ +------+ *
* |SFF|->|SF#2.1|->|SFF|->|SF#2.2| *
* +---+ +------+ +---+ +------+ *
* * * * * * * * * * * * * * * * * * * * * *
Legend:
*** Subdomain boundary
=== upper-level chain
--- lower-level chain
+----+ +-----+ +----------------------+ +-----+
| | | SFF | | IBN 1 (in DC 1) | | SFF |
| |SC#1| | | +----------------+ | | |
->| |===============>| SFF |================>
| | +-----+ | +----------------+ | +-----+
| CF | | | ^ |
| | | v | |
| | |+--------------------+| Upper domain
| | ||CF, fwd/rev mapping ||
| | * * * * *|| and "glue" || * * * * *
| | * |+--------------------+| *
+----+ * | | | | | | Sub *
* +-o-o--------------o-o-+ domain*
* SC#2 | |SC#1 ^ ^ #1 *
* +-----+ | | | *
* | V | | *
* | +---+ +------+ | | *
* | |SFF|->|SF#1.1|--+ | *
* | +---+ +------+ | *
* V | *
* +---+ +------+ +---+ +------+ *
* |SFF|->|SF#2.1|->|SFF|->|SF#2.2| *
* +---+ +------+ +---+ +------+ *
* * * * * * * * * * * * * * * * * * * * * *
Legend:
*** Subdomain boundary
=== upper-level chain
--- lower-level chain
Figure 2: Example of a Subdomain within an Upper-Level Domain
图2：上层域中的子域示例
If desired, the pattern can be applied recursively. For example, SF#1.1 in Figure 2 could be a subdomain of the subdomain.
如果需要，可以递归地应用该模式。例如，图2中的SF#1.1可以是子域的子域。
As mentioned in the previous section, a network element termed an "Internal Boundary Node" (or IBN) is responsible for bridging packets between upper and lower layers of SFC-enabled domains. It behaves as an SF to the upper level (Section 3.1) and looks like a classifier and end of chain to the lower level (Section 3.2).
如前一节所述，称为“内部边界节点”（或IBN）的网元负责在支持SFC的域的上层和下层之间桥接数据包。它表现为上层的SF（第3.1节）和下层的分类器和链末端（第3.2节）。
To achieve the benefits of hierarchy, the IBN should be applying fine-grained traffic-classification rules at a lower level than the traffic passed to it. This means that the number of SFPs within the lower level is greater than the number of SFPs arriving to the IBN.
为了实现层次结构的好处，IBN应该在比传递给它的流量更低的级别上应用细粒度流量分类规则。这意味着较低级别内的SFP数量大于到达IBN的SFP数量。
The IBN is also the termination of lower-level SFPs. This is because the packets exiting lower-level SFPs must be returned to the upper-level SFPs and forwarded to the next hop in the upper-level domain.
IBN也是较低级别SFP的终止。这是因为退出较低级别SFP的数据包必须返回到较高级别SFP，并转发到较高级别域中的下一跳。
When different metadata schemes are used at different levels, the IBN has further responsibilities: when packets enter the subdomain, the IBN translates upper-level metadata into lower-level metadata; and when packets leave the subdomain at the termination of lower-level SFPs, the IBN translates lower-level metadata into upper-level metadata.
当在不同级别使用不同的元数据方案时，IBN有进一步的责任：当数据包进入子域时，IBN将上层元数据转换为下层元数据；当数据包在较低级别的SFP终止时离开子域时，IBN将较低级别的元数据转换为较高级别的元数据。
Appropriately configuring IBNs is key to ensuring the consistency of the overall SFC operation within a given domain that enables hSFC. Classification rules (or lack thereof) in the IBN classifier can, of course, impact upper levels.
适当配置IBN是确保在支持hSFC的给定域内整体SFC操作一致性的关键。当然，IBN分类器中的分类规则（或缺乏分类规则）会影响上层。
The lower-level domain may be provisioned with valid upper-level paths or allow any upper-level paths.
较低级别域可以配置有效的较高级别路径，也可以允许任何较高级别路径。
When packets enter the subdomain, the Service Path Identifier (SPI) and Service Index (SI) are re-marked according to the path selected by the (subdomain) classifier.
当数据包进入子域时，根据（子域）分类器选择的路径重新标记服务路径标识符（SPI）和服务索引（SI）。
At the termination of an SFP in the subdomain, packets can be restored to an original upper-level SFP by implementing one of these methods:
在子域中的SFP终止时，可以通过实现以下方法之一将数据包恢复到原始的上层SFP：
1. Saving the SPI and SI in transport-layer flow state (Section 4.1.1).
1. 在传输层流状态下保存SPI和SI（第4.1.1节）。
2. Pushing the SPI and SI into a metadata header (Section 4.1.2).
2. 将SPI和SI推入元数据头（第4.1.2节）。
3. Using unique lower-level paths per upper-level path coordinates (Section 4.1.3).
3. 根据上层路径坐标使用唯一的下层路径（第4.1.3节）。
4. Nesting NSH headers, encapsulating the upper-level NSH headers within the lower-level NSH headers (Section 4.1.4).
4. 嵌套NSH标头，将上层NSH标头封装在下层NSH标头内（第4.1.4节）。
5. Saving the upper level with a flow identifier (ID) and placing an hSFC Flow ID into a metadata header (Section 4.1.5).
5. 使用流标识符（ID）保存上层，并将hSFC流ID放入元数据头（第4.1.5节）。
An IBN can be flow aware, returning packets to the correct upper-level SFP on the basis, for example, of the transport-layer coordinates (typically, a 5-tuple) of packets exiting the lower-level SFPs.
IBN可以是流感知的，例如，基于离开较低级别SFP的包的传输层坐标（通常为5元组），将包返回到正确的较高级别SFP。
When packets are received by the IBN on an upper-level path, the classifier parses encapsulated packets for IP and transport-layer (TCP, UDP, etc.) coordinates. State is created, indexed by some or all transport coordinates (typically, {source-IP, destination-IP, source-port, destination-port, and transport protocol}). The state contains, at minimum, the critical fields of the encapsulating SFC header (SPI, SI, MD Type, flags); additional information carried in the packet (metadata, TTL) may also be extracted and saved as state. Note that some fields of a packet may be altered by an SF of the subdomain (e.g., source IP address).
当IBN在上层路径上接收到数据包时，分类器解析IP和传输层（TCP、UDP等）坐标的封装数据包。状态由一些或所有传输坐标（通常为{源IP、目标IP、源端口、目标端口和传输协议}）创建和索引。状态至少包含封装SFC头的关键字段（SPI、SI、MD类型、标志）；包中携带的附加信息（元数据，TTL）也可以提取并保存为状态。注意，数据包的某些字段可能会被子域的SF（例如，源IP地址）改变。
Note that this state is only accessed by the classifier and terminator functions of the subdomain. Neither the SFFs nor SFs have knowledge of this state; in fact they may be agnostic about being in a subdomain.
请注意，此状态仅由子域的分类器和终止符函数访问。SFF和SFs均不知道该状态；事实上，他们可能不知道自己是否在子域中。
One approach is to ensure that packets are terminated at the end of the chain at the same IBN that classified the packet at the start of the chain. If the packet is returned to a different egress IBN, state must be synchronized between the IBNs.
一种方法是确保数据包在链的末端终止于链的起始处对数据包进行分类的同一IBN。如果数据包返回到不同的出口IBN，则必须在IBN之间同步状态。
When a packet returns to the IBN at the end of a chain (which is the SFP-terminating node of the lower-level chain), the SFC header is removed, the packet is parsed for flow-identifying information, and state is retrieved from within the IBN using the flow-identifying information as index.
当数据包返回到链末端的IBN（即较低级别链的SFP终止节点）时，SFC报头被移除，数据包被解析为流标识信息，并且使用流标识信息作为索引从IBN内检索状态。
State cannot be created by packets arriving from the lower-level chain; when state cannot be found for such packets, they must be dropped.
从低级链到达的数据包不能创建状态；当无法找到此类数据包的状态时，必须丢弃它们。
This stateful approach is limited to use with SFs that retain the transport coordinates of the packet. This approach cannot be used with SFs that modify those coordinates (e.g., NATs) or otherwise create packets for new coordinates other than those received (e.g., as an HTTP cache might do to retrieve content on behalf of the original flow). In both cases, the fundamental problem is the inability to forward packets when state cannot be found for the packet transport-layer coordinates.
这种有状态方法仅限于与保留数据包传输坐标的SFs一起使用。这种方法不能用于修改这些坐标（例如NAT）或为接收到的坐标以外的新坐标创建数据包的SFs（例如HTTP缓存可能会代表原始流检索内容）。在这两种情况下，基本问题是当无法找到数据包传输层坐标的状态时，无法转发数据包。
In the stateful approach, there are issues caused by having state, such as how long the state should be maintained as well as whether the state needs to be replicated to other devices to create a highly available network.
在有状态方法中，存在由状态引起的问题，例如状态应保持多长时间，以及是否需要将状态复制到其他设备以创建高可用网络。
It is valid to consider the state to be disposable after failure, since it can be recreated by each new packet arriving from the upper-level domain. For example, if an IBN loses all flow state, the state is recreated by an endpoint retransmitting a TCP packet.
有效地考虑状态是一次性的失败后，因为它可以由来自上层域的每个新分组重新创建。例如，如果IBN丢失所有流状态，则该状态将由端点重新传输TCP数据包来重新创建。
If an SFC domain handles multiple network regions (e.g., multiple private networks), the coordinates may be augmented with additional parameters, perhaps using some metadata to identify the network region.
如果SFC域处理多个网络区域（例如，多个专用网络），则可以使用附加参数来增加坐标，可能使用一些元数据来标识网络区域。
In this stateful approach, it is not necessary for the subdomain's control plane to modify paths when upper-level paths are changed. The complexity of the upper-level domain does not cause complexity in the lower-level domain.
在这种有状态方法中，当上层路径发生更改时，子域的控制平面不必修改路径。上层域的复杂性不会导致下层域的复杂性。
Since it doesn't depend on NSH in the lower-level domain, this flow-stateful approach can be applied to translation methods of converting NSH to other forwarding techniques (refer to Section 7).
由于它不依赖于较低级别域中的NSH，因此这种流状态方法可应用于将NSH转换为其他转发技术的转换方法（参见第7节）。
An IBN can push the upper-level SPI and SI (or encoding thereof) into a metadata field of the lower-level encapsulation (e.g., placing upper-level path information into a metadata field of the NSH). When packets exit the lower-level path, the upper-level SPI and SI can be restored from the metadata retrieved from the packet.
IBN可以将上层SPI和SI（或其编码）推入下层封装的元数据字段（例如，将上层路径信息放入NSH的元数据字段）。当数据包退出下层路径时，上层SPI和SI可以从从数据包检索的元数据中恢复。
This approach requires the SFs in the path to be capable of forwarding the metadata and appropriately attaching metadata to any packets injected for a flow.
这种方法要求路径中的SFs能够转发元数据，并将元数据适当地附加到为流注入的任何数据包。
Using a new metadata header may inflate packet size when variable-length metadata (NSH MD Type 0x2) is used.
当使用可变长度元数据（NSH MD类型0x2）时，使用新的元数据头可能会增大数据包大小。
It is conceivable that the MD Type 0x1 Fixed-Length Context Header field of the NSH is not all relevant to the lower-level domain. In this case, 32 bits of the Fixed-Length Context Header field could be repurposed within the lower-level domain and restored when leaving.
可以想象，NSH的MD Type 0x1固定长度上下文头字段并不都与较低级别的域相关。在这种情况下，固定长度上下文标头字段的32位可以在较低级别域中重新调整用途，并在离开时恢复。
If flags or TTL (see Section 4.4) from the original header also need to be saved, more metadata space will be consumed.
如果原始标题中的标志或TTL（参见第4.4节）也需要保存，则会消耗更多的元数据空间。
In this metadata approach, it is not necessary for the subdomain's control element to modify paths when upper-level paths are changed. The complexity of the upper-level domain does not increase complexity in the lower-level domain.
在这种元数据方法中，当上层路径发生更改时，子域的控制元素不必修改路径。上层域的复杂性不会增加下层域的复杂性。
This approach assumes that paths within the subdomain are constrained so that an SPI (of the subdomain) unambiguously indicates the egress SPI and SI (of the upper domain). This allows the original path information to be restored at subdomain egress from a look-up table using the subdomain SPI.
该方法假设子域内的路径受到约束，以便（子域的）SPI明确指示（上域的）出口SPI和SI。这允许在子域出口处使用子域SPI从查找表恢复原始路径信息。
Whenever the upper-level domain provisions a path via the lower-level domain, the lower-level domain control plane must provision corresponding paths to traverse the lower-level domain.
每当上层域提供通过下层域的路径时，下层域控制平面必须提供相应的路径以穿过下层域。
A downside of this approach is that the number of paths in the lower-level domain is multiplied by the number of paths in the upper-level domain that traverse the lower-level domain. That is, a subpath must be created for each combination of upper SPI/SI and lower chain. The number of paths required for lower-level domains will increase exponentially as hierarchy becomes deep.
这种方法的缺点是，较低级别域中的路径数乘以较高级别域中穿过较低级别域的路径数。也就是说，必须为上SPI/SI和下链的每个组合创建子路径。随着层次结构的加深，较低级别域所需的路径数将呈指数级增加。
A further downside of this approach is that it requires upper and lower levels to utilize the same metadata configuration.
这种方法的另一个缺点是，它需要上层和下层使用相同的元数据配置。
Furthermore, this approach does not allow any information to be stashed away in state or embedded in metadata. For example, the TTL modifications by the lower level cannot be hidden from the upper level.
此外，这种方法不允许将任何信息隐藏在状态中或嵌入元数据中。例如，较低级别的TTL修改不能从较高级别隐藏。
When packets arrive at an IBN in the top-level domain, the classifier in the IBN determines the path for the lower-level domain and pushes the new NSH header in front of the original NSH header.
当数据包到达顶级域中的IBN时，IBN中的分类器确定下层域的路径，并将新NSH报头推到原始NSH报头的前面。
As shown in Figure 3, the Lower-NSH header used to forward packets in the lower-level domain precedes the Upper-NSH header from the top-level domain.
如图3所示，用于转发下层域中的数据包的下层NSH报头位于顶层域的上层NSH报头之前。
+---------------------------------+
| Outer-Transport Encapsulation |
+---------------------------------+
| Lower-NSH Header |
+---------------------------------+
| Upper-NSH Header |
+---------------------------------+
| Original Packet |
+---------------------------------+
+---------------------------------+
| Outer-Transport Encapsulation |
+---------------------------------+
| Lower-NSH Header |
+---------------------------------+
| Upper-NSH Header |
+---------------------------------+
| Original Packet |
+---------------------------------+
Figure 3: Encapsulation of NSH within NSH
图3:NSH在NSH中的封装
The traffic with this stack of two NSH headers is to be forwarded according to the Lower-NSH header in the lower-level SFC domain. The Upper-NSH header is preserved in the packets but not used for forwarding. At the last SFF of the chain of the lower-level domain (which resides in the IBN), the Lower-NSH header is removed from the packet, and then the packet is forwarded by the IBN to an SFF of the upper-level domain. The packet will be forwarded in the top-level domain according to the Upper-NSH header.
具有这两个NSH报头堆栈的流量将根据较低级别SFC域中的较低NSH报头进行转发。上部NSH报头保留在数据包中，但不用于转发。在较低级别域链（位于IBN中）的最后一个SFF处，较低NSH报头从数据包中移除，然后数据包由IBN转发到较高级别域的SFF。数据包将根据上NSH报头在顶级域中转发。
With such encapsulation, Upper-NSH information is carried along the extent of the lower-level chain without modification.
通过这种封装，上层NSH信息沿着下层链的范围传送，而无需修改。
A benefit of this approach is that it does not require state in the IBN or configuration to encode fields in metadata. All header fields, including flags and TTL, are easily restored when the chains of the subdomain terminate.
这种方法的一个好处是，它不需要IBN中的状态或配置来编码元数据中的字段。当子域链终止时，所有头字段（包括标志和TTL）都可以轻松恢复。
However, the downside is that it does require SFC-aware SFs in the lower-level domain to be able to parse multiple NSH layers. If an SFC-aware SF injects packets, it must also be able to deal with adding appropriate multiple layers of headers to injected packets.
然而，缺点是，它确实需要较低级别域中支持SFC的SFs能够解析多个NSH层。如果SFC感知SF注入数据包，它还必须能够处理向注入的数据包添加适当的多层头的问题。
By increasing packet overhead, nesting may lead to fragmentation or decreased MTU in some networks.
通过增加数据包开销，嵌套可能导致某些网络中的碎片或MTU减少。
The basic idea of this approach is for the IBN to save upper domain encapsulation information such that it can be retrieved by a unique identifier, termed an "hSFC Flow ID".
这种方法的基本思想是IBN保存上层域封装信息，以便可以通过称为“hSFC流ID”的唯一标识符检索该信息。
The hSFC Flow ID is placed, for example, in the NSH Fixed-Length Context Header field of the packet in the lower-level domain, as shown in Figure 4. Likewise, hSFC Flow ID may be encoded as a Variable-Length Context Header field when MD Type 0x2 is used.
例如，hSFC流ID被放置在下层域中数据包的NSH固定长度上下文报头字段中，如图4所示。同样，当使用MD类型0x2时，hSFC流ID可以编码为可变长度上下文标头字段。
When packets exit the lower-level domain, the IBN uses the hSFC Flow ID to retrieve the appropriate NSH encapsulation for returning the packet to the upper domain. The hSFC Flow ID Context Header is then stripped by the IBN.
当数据包退出较低级别域时，IBN使用hSFC流ID检索适当的NSH封装以将数据包返回到较高级别域。然后，IBN剥离hSFC流ID上下文头。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hSFC Flow ID |
| Zero Padding or other fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hSFC Flow ID |
| Zero Padding or other fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Storing hSFC Flow ID in Lower-Level NSH Fixed-Length Context Header Field ([RFC8300], Section 2.4)
图4：在较低级别NSH固定长度上下文标题字段中存储hSFC流ID（[RFC8300]，第2.4节）
Advantages of this approach include:
这种方法的优点包括：
o It does not require state to be based on a 5-tuple, so it works with SFs that change the IP addresses or port numbers of a packet, such as NATs.
o 它不要求状态基于5元组，因此它可以与更改数据包的IP地址或端口号（如NAT）的SFs一起使用。
o It does not require all domains to have the same metadata scheme.
o 它不要求所有域都具有相同的元数据方案。
o It can be used to restore any upper-domain information, including metadata, flags, and TTL, not just the service path.
o 它可以用于恢复任何上层域信息，包括元数据、标志和TTL，而不仅仅是服务路径。
o The lower-level domain only requires a single item of metadata regardless of the number of items of metadata used in the upper domain.
o 较低级别的域只需要单个元数据项，而不考虑在较高级别的域中使用的元数据项的数量。
o The SFC-related functionality required by this approach in an SFC-aware SF is able to preserve and apply metadata, which is a requirement that was already present in [RFC8300].
o 这种方法在支持SFC的SF中所需的SFC相关功能能够保存和应用元数据，这是[RFC8300]中已经提出的要求。
Disadvantages include those of other stateful approaches, including state timeout and synchronization, mentioned in Section 4.1.1.
缺点包括第4.1.1节中提到的其他有状态方法的缺点，包括状态超时和同步。
There may be a large number of unique NSH encapsulations to be stored, given that the hSFC Flow ID must represent all of the bits in the upper-level encapsulation. This might consume a lot of memory or
考虑到hSFC流ID必须表示上层封装中的所有位，可能要存储大量独特的NSH封装。这可能会消耗大量内存或内存
create out-of-memory situations in which hSFC Flow IDs cannot be created or old hSFC Flow IDs are discarded while still in use.
创建无法创建hSFC流ID或旧hSFC流ID仍在使用时被丢弃的内存不足情况。
The SPI or metadata included in a packet received by the IBN may be used as input to reclassification and path selection within a lower-level domain.
IBN接收到的分组中包括的SPI或元数据可以用作低级别域内的重新分类和路径选择的输入。
In some cases, the meanings of the various path IDs and metadata must be coordinated between domains for the sake of proper end-to-end SFC operation.
在某些情况下，为了正确的端到端SFC操作，必须在域之间协调各种路径ID和元数据的含义。
One approach is to use well-known identifier values in metadata, maintained in a global registry.
一种方法是在元数据中使用在全局注册表中维护的已知标识符值。
Another approach is to use well-known labels for chain identifiers or metadata, as an indirection to the actual identifiers. The actual identifiers can be assigned by control-plane systems. For example, a subdomain classifier could have a policy, "if pathID = classA then chain packet to path 1234"; the upper-level controller would be expected to configure the concrete upper-level "pathID" for "classA".
另一种方法是使用链标识符或元数据的已知标签作为实际标识符的间接指向。实际标识符可由控制平面系统分配。例如，子域分类器可以有一个策略，“如果pathID=classA，则将数据包链到路径1234”；上层控制器需要为“classA”配置具体的上层“pathID”。
Because the IBN acts as an SFC-aware SF to the upper-level domain, it must decrement the Service Index in the NSH headers of the upper-level path. This operation should be undertaken when the packet is first received by the IBN, before applying any of the strategies of Section 4.1, immediately prior to classification.
由于IBN充当上层域的SFC感知SF，因此它必须减少上层路径的NSH头中的服务索引。在应用第4.1节中的任何策略之前，当IBN第一次收到数据包时，应在分类前立即执行此操作。
The NSH base header contains a TTL field [RFC8300]. There is a choice:
NSH基本报头包含一个TTL字段[RFC8300]。有一个选择：
a subdomain may appear as a pure service function, which should not decrement the TTL from the perspective of the upper-level domain, or
子域可以显示为纯服务函数，从上层域的角度来看，它不应该减少TTL，或者
all of the TTL changes within the subdomain may be visible to the upper-level domain.
子域内的所有TTL更改可能对上层域可见。
Some readers may recognize this as a choice between "pipe" and "uniform" models, respectively [RFC3443].
一些读者可能会认为这是分别在“管道”和“统一”模型之间进行选择[RFC3443]。
The network operator should be given control of this behavior, choosing whether to expose the lower-level topology to the upper layer. An implementation may support per-packet policy, allowing some users to perform a layer-transcending trace route, for example.
应该让网络运营商控制这种行为，选择是否向上层公开下层拓扑。一种实现可以支持每包策略，例如，允许一些用户执行超越跟踪路由的层。
The choice affects whether the methods of restoring the paths in Section 4.1 restore a saved version of the TTL or propagate it with the packet. The method of Section 4.1.3 does not permit topology hiding. The other methods of Sections 4.1.1, 4.1.2, 4.1.4, and 4.1.5 have unique methods for restoring saved versions of the TTL.
该选择会影响第4.1节中恢复路径的方法是恢复TTL的保存版本，还是将其与数据包一起传播。第4.1.3节的方法不允许拓扑隐藏。第4.1.1节、第4.1.2节、第4.1.4节和第4.1.5节中的其他方法具有恢复TTL保存版本的独特方法。
Within the subdomain (referring to Figure 2), as the classifier receives incoming packets, the upper-level encapsulation is treated according to one of the methods described in Section 4.1 to either statefully store, encode, or nest header information. The classifier then selects the path and metadata for the packet within the subdomain.
在子域内（参考图2），当分类器接收到传入的数据包时，根据第4.1节中描述的方法之一处理上层封装，以有状态地存储、编码或嵌套报头信息。然后，分类器为子域内的数据包选择路径和元数据。
One of the goals of the hierarchical approach is to make it easy to have transport-flow-aware service chaining with bidirectional paths. For example, it is desired that for each TCP flow, the client-to-server packets traverse the same SF instances as the server-to-client packets, but in the opposite sequence. We call this "bidirectional symmetry". If bidirectional symmetry is required, it is the responsibility of the control plane to be aware of symmetric paths and configure the classifier to chain the traffic in a symmetric manner.
分层方法的目标之一是使具有双向路径的传输流感知服务链变得容易。例如，希望对于每个TCP流，客户端到服务器的数据包与服务器到客户端的数据包遍历相同的SF实例，但顺序相反。我们称之为“双向对称”。如果需要双向对称，则控制平面负责了解对称路径，并配置分类器以对称方式链接流量。
Another goal of the hierarchical approach is to simplify the mechanisms of scaling SFs in and out. All of the complexities of load-balancing among multiple SFs can be handled within a subdomain, under control of the classifier, allowing the upper-level domain to be oblivious to the existence of multiple SF instances.
分层方法的另一个目标是简化SFs的伸缩机制。在分类器的控制下，多个SF之间负载平衡的所有复杂性都可以在子域内处理，从而允许上层域忽略多个SF实例的存在。
Considering the requirements of bidirectional symmetry and load-balancing, it is useful to have all packets entering a subdomain be received by the same classifier or a coordinated cluster of classifiers. There are both stateful and stateless approaches to ensuring bidirectional symmetry.
考虑到双向对称和负载平衡的要求，让进入子域的所有数据包由同一分类器或协调的分类器集群接收是有用的。有状态和无状态两种方法可以确保双向对称。
Although SFC control protocols have not yet been standardized (as of 2018), from the point of view of hierarchical service function chaining, we have these expectations:
尽管SFC控制协议尚未标准化（截至2018年），但从分层服务功能链的角度来看，我们有以下期望：
o Each control-plane instance manages a single level of the hierarchy of a single domain.
o 每个控制平面实例管理单个域层次结构的单个级别。
o Each control plane is agnostic about other levels of the hierarchy. This aspect allows humans to reason about the system within a single domain and control-plane algorithms to use only domain-local inputs. Top-level control does not need visibility to subdomain policies, nor does subdomain control need visibility to upper-level policies. (Top-level control considers a subdomain as though it were an SF.)
o 每个控制平面对于层次结构的其他级别是不可知的。这方面允许人类在单个域内对系统进行推理，控制平面算法仅使用域本地输入。顶级控制不需要子域策略的可见性，子域控制也不需要上层策略的可见性。（顶级控件将子域视为SF。）
o Subdomain control planes are agnostic about the control planes of other subdomains. This allows both humans and machines to manipulate subdomain policy without considering policies of other domains.
o 子域控制平面对其他子域的控制平面不可知。这允许人和机器操作子域策略，而不考虑其他域的策略。
Recall that the IBN acts as an SFC-aware SF in the upper-level domain (receiving SF instructions from the upper-level control plane) and as a classifier in the lower-level domain (receiving classification rules from the subdomain control plane). In this view, it is the IBN that glues the layers together.
回想一下，IBN在上层域中充当SFC感知SF（从上层控制平面接收SF指令），在下层域中充当分类器（从子域控制平面接收分类规则）。在这个视图中，是IBN将层粘合在一起。
These expectations are not intended to prohibit network-wide control. A control hierarchy can be envisaged to distribute information and instructions to multiple domains and subdomains. Control hierarchy is outside the scope of this document.
这些期望并不是为了禁止网络范围的控制。可以设想控制层次结构将信息和指令分发到多个域和子域。控制层次结构不在本文档的范围内。
The hierarchical approach can be used for dividing networks into NSH-aware and NSH-unaware domains by converting NSH encapsulation to other forwarding techniques (e.g., 5-tuple-based forwarding with OpenFlow), as shown in Figure 5.
通过将NSH封装转换为其他转发技术（例如，使用OpenFlow的基于5元组的转发），分层方法可用于将网络划分为NSH感知域和NSH不感知域，如图5所示。
* * * * * * * * * * * * * * * * * *
* NSH-aware domain *
* +-------+ +-------+ *
* | SF#1 | | SF#5 | *
* +-o---o-+ +-o---o-+ *
* ^ | ^ | *
* +-|---|-+ +-|---|-+ *
* | |SFF| | | |SFF| | *
* +-|---|-+ +-|---|-+ *
* . | | . *
* +--+ / | | \ *
-->|CF|--' | | '------->
* +--+ v | *
* +---o-----------o---+ *
.*.*.*.*.| / | IBN | \ |*.*.*.
. +-o--o---------o--o-+ .
. | | ^ ^ .
. | +-+ +-+ | .
. +---+ v | +---+ .
. | +-o-----o-+ | .
. | | SF#2 | | .
. | +---------+ | .
. +--+ +--+ .
. | +---------+ | .
. v | v | .
. +-o---o-+ +-o---o-+ .
. | SF#3 | | SF#4 | .
. +-------+ +-------+ .
. NSH-unaware domain .
. . . . . . . . . . . . . . . . . .
* * * * * * * * * * * * * * * * * *
* NSH-aware domain *
* +-------+ +-------+ *
* | SF#1 | | SF#5 | *
* +-o---o-+ +-o---o-+ *
* ^ | ^ | *
* +-|---|-+ +-|---|-+ *
* | |SFF| | | |SFF| | *
* +-|---|-+ +-|---|-+ *
* . | | . *
* +--+ / | | \ *
-->|CF|--' | | '------->
* +--+ v | *
* +---o-----------o---+ *
.*.*.*.*.| / | IBN | \ |*.*.*.
. +-o--o---------o--o-+ .
. | | ^ ^ .
. | +-+ +-+ | .
. +---+ v | +---+ .
. | +-o-----o-+ | .
. | | SF#2 | | .
. | +---------+ | .
. +--+ +--+ .
. | +---------+ | .
. v | v | .
. +-o---o-+ +-o---o-+ .
. | SF#3 | | SF#4 | .
. +-------+ +-------+ .
. NSH-unaware domain .
. . . . . . . . . . . . . . . . . .
SF#1 and SF#5 are NSH aware; SF#2, SF#3, and SF#4 are NSH unaware. In the NSH-unaware domain, packets are conveyed in a format supported by SFs that are deployed there.
SF 1和SF 5意识到NSH；SF#2、SF#3和SF#4是NSH不知道的。在NSH域中，数据包以部署在该域中的SFs支持的格式传输。
Figure 5: Dividing NSH-Aware and NSH-Unaware Domains
图5：划分NSH感知域和NSH不感知域
This approach is expected to facilitate service chaining in networks in which NSH-aware and NSH-unaware SFs coexist. Some examples of such situations are:
这种方法有望促进NSH感知和NSH不感知SFs共存的网络中的服务链。这类情况的一些例子如下：
o In a period of transition from legacy SFs to NSH-aware SFs
o 在从传统SFs向NSH感知SFs过渡的时期
o Supporting multitenancy
o 支持多租户
In this usage, an IBN classifier is required to have an NSH conversion table for applying packets to appropriate lower-level paths and returning packets to the correct upper-level paths. For example, the following methods would be used for saving/restoring upper-level path information:
在这种用法中，IBN分类器需要具有NSH转换表，用于将数据包应用到适当的较低级别路径并将数据包返回到正确的较高级别路径。例如，以下方法将用于保存/恢复上层路径信息：
o Saving SPI and SI in transport-layer flow state (refer to Section 4.1.1)
o 在传输层流状态下保存SPI和SI（参考第4.1.1节）
o Using unique lower-level paths per upper-level NSH coordinates (refer to Section 4.1.3)
o 根据上层NSH坐标使用唯一的下层路径（参考第4.1.3节）
Using the unique paths approach would be especially good for translating NSH to a different forwarding technique in the lower level. A single path in the upper level may be branched to multiple paths in the lower level such that any lower-level path is only used by one upper-level path. This allows unambiguous restoration to the upper-level path.
使用独特路径方法对于在较低级别将NSH转换为不同的转发技术尤其有利。上层中的单个路径可以分支到下层中的多个路径，使得任何下层路径仅由一个上层路径使用。这允许明确地恢复到上层路径。
In addition, an IBN might be required to convert metadata contained in the NSH to the format appropriate to the packet in the lower-level path. For example, some legacy SFs identify subscribers based on information about the network topology, such as the VLAN ID (VID), and the IBN would be required to create a VLAN to packets from metadata if the subscriber identifier is conveyed as metadata in upper-level domains.
此外，可能需要IBN将NSH中包含的元数据转换为适合较低级别路径中的数据包的格式。例如，一些传统sf基于关于网络拓扑的信息（例如VLAN ID（VID））来识别订户，并且如果订户标识符在上层域中作为元数据传送，则IBN将需要创建从元数据到数据包的VLAN。
Other fundamental functions required for an IBN (e.g., maintaining metadata of upper level or decrementing Service Index) are the same as in normal usage.
IBN所需的其他基本功能（例如，维护上层元数据或递减服务索引）与正常使用时相同。
It is useful to permit metadata to be transferred between levels of a hierarchy. Metadata from an upper level may be useful within a subdomain, and a subdomain may augment metadata for consumption in an upper domain. However, allowing uncontrolled metadata between domains may lead to forwarding failures.
允许元数据在层次结构的级别之间传输是很有用的。来自上层的元数据在子域内可能有用，子域可能会增加元数据以供上层域使用。但是，允许域之间不受控制的元数据可能会导致转发失败。
In order to prevent SFs of lower-level SFC-enabled domains from supplying (illegitimate) metadata, IBNs may be instructed to only permit specific metadata types to exit the subdomain. Such control over the metadata in the upper level is the responsibility of the upper-level control plane.
为了防止启用SFC的较低级别域的SFs提供（非法）元数据，可能会指示IBN仅允许特定元数据类型退出子域。对上层元数据的这种控制是上层控制平面的责任。
To limit unintentional metadata reaching SFs of lower-level SFC-enabled subdomains, IBNs may be instructed to only permit specific metadata types into the subdomain. Such control of metadata in the lower-level domain is the responsibility of the lower-level control plane.
为了限制无意元数据到达启用SFC的较低级别子域的SFs，可能会指示IBN仅允许特定元数据类型进入子域。底层域中元数据的这种控制是底层控制平面的责任。
This document has no IANA actions.
本文档没有IANA操作。
hSFC makes use of service chaining architecture; hence, it inherits the security considerations described in the architecture document [RFC7665].
hSFC采用服务链架构；因此，它继承了体系结构文档[RFC7665]中描述的安全注意事项。
Furthermore, hSFC inherits the security considerations of the data-plane protocols (e.g., NSH) and control-plane protocols used to realize the solution.
此外，hSFC继承了用于实现解决方案的数据平面协议（如NSH）和控制平面协议的安全考虑。
This document describes systems that may be managed by distinct teams that all belong to the same administrative entity. Subdomains must have consistent configurations in order to properly forward traffic. Any protocol designed to distribute the configurations must be secure from tampering. The means of preventing attacks from within a network must be enforced. For example, continuously monitoring the network may allow detecting such misbehaviors. hSFC adheres to the same security considerations as [RFC8300]. Those considerations must be taken into account.
本文档描述了可能由属于同一管理实体的不同团队管理的系统。子域必须具有一致的配置才能正确转发流量。设计用于分发配置的任何协议都必须是安全的，不受篡改。必须实施防止网络内攻击的手段。例如，持续监控网络可允许检测此类不当行为。hSFC遵守与[RFC8300]相同的安全注意事项。必须考虑到这些因素。
The options in Sections 4.1.2 and 4.1.5 assume the use of a dedicated context header to store information to bind a flow to its upper-level SFP. Such a context header is stripped by the IBN of a subdomain before exiting a subdomain. Additional guards to prevent leaking unwanted context information when entering/exiting a subdomain are discussed in Section 7.2.
第4.1.2节和第4.1.5节中的选项假设使用专用上下文标头存储信息，以将流绑定到其上层SFP。在退出子域之前，子域的IBN将剥离这样的上下文头。第7.2节讨论了在进入/退出子域时防止泄漏不需要的上下文信息的附加保护。
All of the systems and protocols must be secure from modification by untrusted agents.
所有系统和协议都必须是安全的，不受不可信代理的修改。
Security considerations related to the control plane are discussed in the corresponding control specification documents (e.g., [BGP-CONTROL], [PCEP-EXTENSIONS], or [RADIUS]).
与控制平面相关的安全注意事项在相应的控制规范文件（例如，[BGP-control]、[PCEP-EXTENSIONS]或[RADIUS]）中讨论。
Distributing policies among multiple domains may lead to forwarding loops. NSH supports the ability to detect loops (as described in Sections 4.3 and 4.4 of [RFC8300]), but the means of ensuring the consistency of the policies should be enabled at all levels of a domain. Within the context of hSFC, it is the responsibility of the Control Elements at all levels to prevent such (unwanted) loops.
在多个域之间分发策略可能会导致转发循环。NSH支持检测循环的能力（如[RFC8300]第4.3节和第4.4节所述），但应在域的所有级别启用确保策略一致性的方法。在hSFC环境中，各级控制元件有责任防止此类（不需要的）回路。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665]Halpern，J.，Ed.和C.Pignataro，Ed.，“服务功能链（SFC）架构”，RFC 7665，DOI 10.17487/RFC7665，2015年10月<https://www.rfc-editor.org/info/rfc7665>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8300]Quinn，P.，Ed.，Elzur，U.，Ed.，和C.Pignataro，Ed.，“网络服务头（NSH）”，RFC 8300，DOI 10.17487/RFC8300，2018年1月<https://www.rfc-editor.org/info/rfc8300>.
[BGP-CONTROL] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for NSH SFC", Work in Progress, draft-ietf-bess-nsh-bgp-control-plane-04, July 2018.
[BGP-CONTROL]Farrel，A.，Drake，J.，Rosen，E.，Uttaro，J.，和L.Jalil，“NSH SFC的BGP控制平面”，在建工程，草案-ietf-bess-NSH-BGP-CONTROL-Plane-042018年7月。
[PCEP-EXTENSIONS] Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. Tantsura, "PCEP Extensions for Service Function Chaining (SFC)", Work in Progress, draft-wu-pce-traffic-steering-sfc-12, June 2017.
[PCEP-扩展]Wu，Q.，Dhody，D.，Boucadair，M.，Jacquenet，C.，和J.Tantsura，“服务功能链（SFC）的PCEP扩展”，正在进行的工作，草稿-Wu-pce-traffic-steering-SFC-12，2017年6月。
[RADIUS] Maglione, R., Trueba, G., and C. Pignataro, "RADIUS Attributes for NSH", Work in Progress, draft-maglione-sfc-nsh-radius-01, October 2016.
[RADIUS]Maglione，R.，Trueba，G.，和C.Pignataro，“NSH的半径属性”，在建工程，草稿-Maglione-sfc-NSH-RADIUS-01，2016年10月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，DOI 10.17487/RFC3443，2003年1月<https://www.rfc-editor.org/info/rfc3443>.
[USE-CASES] Kumar, S., Tufail, M., Majee, S., Captari, C., and S. Homma, "Service Function Chaining Use Cases In Data Centers", Work in Progress, draft-ietf-sfc-dc-use-cases-06, February 2017.
[用例]Kumar，S.，Tufail，M.，Majee，S.，Captari，C.，和S.Homma，“数据中心中的服务功能链接用例”，正在进行的工作，草稿-ietf-sfc-dc-USE-CASES-062017年2月。
The advantage of hSFC compared with normal or flat service function chaining is that it can reduce the management complexity significantly. This section discusses examples that show those advantages.
与普通或平面服务功能链相比，hSFC的优势在于可以显著降低管理复杂性。本节讨论显示这些优点的示例。
In this case, hSFC is used to simplify service function chaining management by reducing the number of SFPs.
在这种情况下，hSFC通过减少SFP的数量来简化服务功能链管理。
As shown in Figure 6, there are two domains, each with different concerns: a Security Domain that selects SFs based on network conditions and an Optimization Domain that selects SFs based on traffic protocol.
如图6所示，有两个域，每个域都有不同的关注点：基于网络条件选择SFs的安全域和基于流量协议选择SFs的优化域。
In this example, there are five security functions deployed in the Security Domain. The Security Domain operator wants to enforce the five different security policies, and the Optimization Domain operator wants to apply different optimizations (either cache or video optimization) to each of these two types of traffic. If we use flat SFC (normal branching), 10 SFPs are needed in each domain. In contrast, if we use hSFC, only five SFPs in Security Domain and two SFPs in Optimization Domain will be required, as shown in Figure 7.
在本例中，安全域中部署了五个安全功能。安全域运营商希望实施五种不同的安全策略，而优化域运营商希望对这两种类型的流量中的每一种应用不同的优化（缓存或视频优化）。如果我们使用扁平SFC（正常分支），每个域需要10个SFP。相反，如果我们使用hSFC，则只需要安全域中的五个SFP和优化域中的两个SFP，如图7所示。
In the flat model, the number of SFPs is the product of the number of SFs in all of the domains. In the hSFC model, the number of SFPs is the sum of the number of SFs. For example, adding a "bypass" path in the Optimization Domain would cause the flat model to require 15 paths (five more) but cause the hSFC model to require one more path in the Optimization Domain.
在平面模型中，SFP的数量是所有域中SF数量的乘积。在hSFC模型中，SFP的数量是SF数量的总和。例如，在优化域中添加“旁路”路径会导致平面模型需要15条路径（五条以上），但会导致hSFC模型在优化域中需要一条以上的路径。
. . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
. +-1---[ ]----------------->[Cache ]------->
. | [ WAF ] . . .
. +-2-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-3---[Anti ]----------------->[Cache ]------->
. | [Virus] . . .
. +-4-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-5-->[ ]----------------->[Cache ]------->
[DPI]--->[CF]---| [ IPS ] . . .
. +-6-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-7-->[ ]----------------->[Cache ]------->
. | [ IDS ] . . .
. +-8-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-9-->[Traffic]--------------->[Cache ]------->
. | [Monitor] . . .
. +-10->[ ]--------------->[Video Opt.]---->
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
. +-1---[ ]----------------->[Cache ]------->
. | [ WAF ] . . .
. +-2-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-3---[Anti ]----------------->[Cache ]------->
. | [Virus] . . .
. +-4-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-5-->[ ]----------------->[Cache ]------->
[DPI]--->[CF]---| [ IPS ] . . .
. +-6-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-7-->[ ]----------------->[Cache ]------->
. | [ IDS ] . . .
. +-8-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-9-->[Traffic]--------------->[Cache ]------->
. | [Monitor] . . .
. +-10->[ ]--------------->[Video Opt.]---->
. . . . . . . . . . . . . . . . . . . . . . . . .
Legend: IDS: Intrusion Detection System IPS: Intrusion Prevention System WAF: Web Application Firewall DPI: Deep Packet Inspection
图例：IDS:入侵检测系统IPS:入侵预防系统WAF:Web应用程序防火墙DPI:深度数据包检查
The classifier must select paths that determine the combination of
Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt,
3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5:IPS+Cache, 6:IPS+VideoOpt,
7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache,
10:TrafficMonitor+VideoOpt
The classifier must select paths that determine the combination of
Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt,
3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5:IPS+Cache, 6:IPS+VideoOpt,
7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache,
10:TrafficMonitor+VideoOpt
Figure 6: Flat SFC (Normal Branching)
图6：扁平SFC（正常分支）
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
[CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]---->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Traffic ]----+ .
. [ Monitor ] .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
[CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]---->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Traffic ]----+ .
. [ Monitor ] .
. . . . . . . . . . . . . . .
Figure 7: Simplified Path Management with hSFC
图7：使用hSFC的简化路径管理
Hierarchical service function chaining can be used to simplify inter-DC SFC management. In the example of Figure 8, there is a central data center (Central DC) and multiple local data centers (Local DC#1, #2, #3) that are deployed in a geographically distributed manner. All of the data centers are under a single administrative domain.
分层服务功能链可用于简化DC间SFC管理。在图8的示例中，有一个中央数据中心（central DC）和多个本地数据中心（local DC#1、#2、#3），它们以地理分布的方式部署。所有数据中心都在一个管理域下。
The central DC may have some service functions that the local DC needs, such that the local DC needs to chain traffic via the central DC. This could be because:
中央DC可能具有一些本地DC需要的服务功能，使得本地DC需要通过中央DC链接流量。这可能是因为：
o Some SFs are deployed as dedicated hardware appliances, and there is a desire to lower the cost (both CAPEX and OPEX) of deploying such SFs in all data centers.
o 一些SF被部署为专用硬件设备，人们希望降低在所有数据中心部署此类SF的成本（资本支出和运营支出）。
o Some SFs are being trialed or introduced, or they otherwise handle a relatively small amount of traffic. It may be cheaper to manage these SFs in a single central data center and steer packets to the central data center than to manage these SFs in all data centers.
o 一些SF正在试验或引入，或者以其他方式处理相对较少的流量。在单个中央数据中心管理这些SF并将数据包引导到中央数据中心可能比在所有数据中心管理这些SF更便宜。
+-----------+
|Central DC |
+-----------+
^ ^ ^
| | |
.---|--|---|----.
/ / | | \
/ / | \ \
+-----+ / / | \ \ +-----+
|Local| | / | \ | |Local|
|DC#1 |--|--. | .----|----|DC#3 |
+-----+ | | | +-----+
\ | /
\ | /
\ | /
'----------------'
|
+-----+
|Local|
|DC#2 |
+-----+
+-----------+
|Central DC |
+-----------+
^ ^ ^
| | |
.---|--|---|----.
/ / | | \
/ / | \ \
+-----+ / / | \ \ +-----+
|Local| | / | \ | |Local|
|DC#1 |--|--. | .----|----|DC#3 |
+-----+ | | | +-----+
\ | /
\ | /
\ | /
'----------------'
|
+-----+
|Local|
|DC#2 |
+-----+
Figure 8: Simplify Inter-DC SFC Management
图8：简化DC间SFC管理
For large DC operators, one local DC may have tens of thousands of servers and hundreds of thousands of virtual machines. SFC can be used to manage user traffic. For example, SFC can be used to classify user traffic based on service type, DDoS state, etc.
对于大型DC运营商，一个本地DC可能有数万台服务器和数十万台虚拟机。SFC可用于管理用户流量。例如，SFC可用于根据服务类型、DDoS状态等对用户流量进行分类。
In such a large-scale DC, using flat SFC is very complex, requiring a super controller to configure all DCs. For example, any changes to SFs or SFPs in the central DC (e.g., deploying a new SF) would require updates to all of the SFPs in the local DCs accordingly. Furthermore, requirements for symmetric paths add additional complexity when flat SFC is used in this scenario.
在如此大规模的DC中，使用扁平SFC非常复杂，需要一个超级控制器来配置所有DC。例如，中央DC中SFs或SFP的任何更改（例如，部署新SF）都需要相应地更新本地DC中的所有SFP。此外，在该场景中使用扁平SFC时，对称路径的要求增加了额外的复杂性。
Conversely, if using hierarchical SFC, each DC can be managed independently to significantly reduce management complexity. SFPs between DCs can represent abstract notions without regard to details within DCs. Independent controllers can be used for the top level (getting packets to pass the correct DCs) and local levels (getting packets to specific SF instances).
相反，如果使用分级SFC，则可以独立管理每个DC，以显著降低管理复杂性。DC之间的SFP可以表示抽象概念，而不考虑DC内的细节。独立控制器可用于顶层（将数据包传送到正确的DCs）和本地层（将数据包传送到特定的SF实例）。
Acknowledgements
致谢
The concept of Hierarchical Service Path Domains was introduced in "Analysis on Forwarding Methods for Service Chaining" (August 2016) as a means of improving scalability of service chaining in large networks.
在“服务链转发方法分析”（2016年8月）中引入了分层服务路径域的概念，作为提高大型网络中服务链可扩展性的一种手段。
The concept of nesting NSH headers within lower-level NSH was contributed by Ting Ao. The concept originally appeared in "Hierarchical SFC for DC Interconnection" (April 2016) as a means of creating hierarchical SFC in a data center.
在较低级别NSH中嵌套NSH标头的概念由Ting Ao提出。该概念最初出现在“用于直流互连的分级SFC”（2016年4月）中，作为在数据中心创建分级SFC的一种方法。
We thank Dapeng Liu for contributing the DC examples in the Appendix.
我们感谢刘大鹏在附录中提供DC示例。
The Stateful/Metadata Hybrid section was contributed by Victor Wu.
有状态/元数据混合部分由Victor Wu提供。
The authors would also like to thank the following individuals for providing valuable feedback:
作者还要感谢以下个人提供了宝贵的反馈：
Ron Parker Christian Jacquenet Jie Cao Kyle Larose
罗恩·帕克·克里斯蒂安·雅克内特·杰·曹·凯尔·拉罗斯
Thanks to Ines Robles, Sean Turner, Vijay Gurbani, Ben Campbell, and Benjamin Kaduk for their review.
感谢Ines Robles、Sean Turner、Vijay Gurbani、Ben Campbell和Benjamin Kaduk的评论。
Authors' Addresses
作者地址
David Dolson Sandvine Waterloo, ON Canada
大卫·道森·桑德文·滑铁卢，加拿大
Email: ddolson@acm.org
Email: ddolson@acm.org
Shunsuke Homma NTT 3-9-11, Midori-cho Musashino-shi, Tokyo 180-8585 Japan
日本东京武藏市中岛町武藏市新田町顺介3-9-11 180-8585
Email: homma.shunsuke@lab.ntt.co.jp
Email: homma.shunsuke@lab.ntt.co.jp
Diego R. Lopez Telefonica I+D Don Ramon de la Cruz, 82 Madrid 28006 Spain
Diego R.Lopez Telefonica I+D Don Ramon de la Cruz，82马德里28006西班牙
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Mohamed Boucadair Orange Rennes 35000 France
穆罕默德·布卡代尔·奥兰治·雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com