Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 8595 Old Dog Consulting
Category: Standards Track S. Bryant
ISSN: 2070-1721 Futurewei
J. Drake
Juniper Networks
June 2019
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 8595 Old Dog Consulting
Category: Standards Track S. Bryant
ISSN: 2070-1721 Futurewei
J. Drake
Juniper Networks
June 2019
An MPLS-Based Forwarding Plane for Service Function Chaining
一种基于MPLS的业务功能链转发平面
Abstract
摘要
This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks.
本文档描述了如何通过MPLS标签堆栈中网络服务头（NSH）的逻辑表示在MPLS网络中实现服务功能链接（SFC）。也就是说，不使用NSH，但NSH的字段映射到MPLS标签堆栈中的字段。这种方法并不反对或取代NSH，但它承认可能需要在棕地网络中临时部署SFC功能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc8595.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8595.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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 ....................................................3
2. Requirements Language ...........................................4
3. Choice of Data-Plane SPI/SI Representation ......................4
4. Use Case Scenarios ..............................................5
4.1. Label Swapping for Logical NSH .............................5
4.2. Hierarchical Encapsulation .................................5
4.3. Fine Control of Service Function Instances .................6
4.4. Micro Chains and Label Stacking ............................6
4.5. SFC and Segment Routing ....................................6
5. Basic Unit of Representation ....................................6
6. MPLS Label Swapping .............................................7
7. MPLS Label Stacking ............................................10
8. Mixed-Mode Forwarding ..........................................12
9. A Note on Service Function Capabilities and SFC Proxies ........13
10. Control-Plane Considerations ..................................14
11. Use of the Entropy Label ......................................14
12. Metadata ......................................................15
12.1. Indicating Metadata in User Data Packets .................16
12.2. In-Band Programming of Metadata ..........................18
12.2.1. Loss of In-Band Metadata ..........................21
13. Worked Examples ...............................................22
14. Implementation Notes ..........................................26
15. Security Considerations .......................................26
16. IANA Considerations ...........................................28
17. References ....................................................29
17.1. Normative References .....................................29
17.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................32
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Choice of Data-Plane SPI/SI Representation ......................4
4. Use Case Scenarios ..............................................5
4.1. Label Swapping for Logical NSH .............................5
4.2. Hierarchical Encapsulation .................................5
4.3. Fine Control of Service Function Instances .................6
4.4. Micro Chains and Label Stacking ............................6
4.5. SFC and Segment Routing ....................................6
5. Basic Unit of Representation ....................................6
6. MPLS Label Swapping .............................................7
7. MPLS Label Stacking ............................................10
8. Mixed-Mode Forwarding ..........................................12
9. A Note on Service Function Capabilities and SFC Proxies ........13
10. Control-Plane Considerations ..................................14
11. Use of the Entropy Label ......................................14
12. Metadata ......................................................15
12.1. Indicating Metadata in User Data Packets .................16
12.2. In-Band Programming of Metadata ..........................18
12.2.1. Loss of In-Band Metadata ..........................21
13. Worked Examples ...............................................22
14. Implementation Notes ..........................................26
15. Security Considerations .......................................26
16. IANA Considerations ...........................................28
17. References ....................................................29
17.1. Normative References .....................................29
17.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................32
Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract Service Functions (SFs) before being delivered to the intended destination. An architecture for SFC is defined in [RFC7665].
服务功能链（SFC）是通过网络引导数据包的过程，以便在将数据包交付到预定目的地之前，可以由一组有序的抽象服务功能（SF）对其进行操作。[RFC7665]中定义了SFC的体系结构。
When applying a particular service function chain to the traffic selected by a service classifier, the traffic needs to be steered through an ordered set of SFs in the network. This ordered set of SFs is termed a Service Function Path (SFP), and the traffic is passed between Service Function Forwarders (SFFs) that are responsible for delivering the packets to the SFs and for forwarding them onward to the next SFF.
当将特定服务功能链应用于由服务分类器选择的流量时，需要通过网络中的一组有序SF引导流量。这组有序的SF称为服务功能路径（SFP），流量在服务功能转发器（SFF）之间传递，服务功能转发器（SFF）负责将数据包传送到SFs并将其转发到下一个SFF。
In order to steer the selected traffic between SFFs and to the correct SFs, the service classifier needs to attach information to each packet. This information indicates the SFP on which the packet is being forwarded and hence the SFs to which it must be delivered. The information also indicates the progress the packet has already made along the SFP.
为了在SFF和正确的SFs之间控制选定的流量，服务分类器需要将信息附加到每个数据包。此信息表示数据包转发到的SFP，以及必须将数据包发送到的SFs。该信息还指示数据包在SFP上已经取得的进展。
The Network Service Header (NSH) [RFC8300] has been defined to carry the necessary information for SFC in packets. The NSH can be inserted into packets and contains various information, including a Service Path Identifier (SPI), a Service Index (SI), and a Time To Live (TTL) counter.
网络服务报头（NSH）[RFC8300]已定义为在数据包中携带SFC所需的信息。NSH可以插入到分组中并包含各种信息，包括服务路径标识符（SPI）、服务索引（SI）和生存时间（TTL）计数器。
Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed forwarding technology that uses labels placed in a packet in a label stack to identify the forwarding actions to be taken at each hop through a network. Actions may include swapping or popping the labels as well as using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. In many cases, MPLS will be used as a tunneling technology to carry packets through networks between SFFs.
多协议标签交换（MPLS）[RFC3031]是一种广泛部署的转发技术，它使用标签堆栈中的数据包中的标签来识别在网络中的每个跃点处要采取的转发操作。操作可能包括交换或弹出标签以及使用标签来确定转发数据包的下一跳。标签还可用于建立转发分组的上下文。在许多情况下，MPLS将被用作隧道技术，在SFF之间通过网络传输数据包。
This document describes how SFC can be achieved in an MPLS network by means of a logical representation of the NSH in an MPLS label stack. This approach is applicable to all forms of MPLS forwarding (where labels are looked up at each hop and are swapped or popped [RFC3031]). It does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. The mechanisms described in this document are a compromise between the full function that can be achieved using the NSH and the benefits of reusing the existing
本文档描述了如何通过MPLS标签堆栈中NSH的逻辑表示在MPLS网络中实现SFC。此方法适用于所有形式的MPLS转发（其中标签在每个跃点查找并交换或弹出[RFC3031]）。它并不反对或取代NSH，但它承认可能需要在棕地网络中临时部署SFC功能。本文档中描述的机制是使用NSH可以实现的全部功能和重用现有系统的好处之间的折衷
MPLS forwarding paradigms (the approach defined here does not include the O bit defined in [RFC8300] and has some limitations to the use of metadata as described in Section 12).
MPLS转发范例（此处定义的方法不包括[RFC8300]中定义的O位，并且对元数据的使用有一些限制，如第12节所述）。
Section 4 provides a short overview of several use case scenarios that help to explain the relationship between the MPLS label operations (swapping, popping, stacking) and the MPLS encoding of the logical NSH described in this document.
第4节简要概述了几个用例场景，这些场景有助于解释MPLS标签操作（交换、弹出、堆叠）与本文档中描述的逻辑NSH的MPLS编码之间的关系。
It is assumed that the reader is fully familiar with the terms and concepts introduced in [RFC7665] and [RFC8300].
假设读者完全熟悉[RFC7665]和[RFC8300]中介绍的术语和概念。
Note that one of the features of the SFC architecture described in [RFC7665] is the "SFC proxy", which exists to include legacy SFs that are not able to process NSH-encapsulated packets. This issue is equally applicable to the use of MPLS-encapsulated packets that encode a logical representation of an NSH. It is discussed further in Section 9.
请注意，[RFC7665]中描述的SFC体系结构的特征之一是“SFC代理”，其存在包括不能处理NSH封装数据包的传统SF。该问题同样适用于使用MPLS封装的分组，该分组对NSH的逻辑表示进行编码。第9节将对此进行进一步讨论。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
While [RFC8300] defines the NSH that can be used in a number of environments, this document provides a mechanism to handle situations in which the NSH is not ubiquitously deployed. In this case, it is possible to use an alternative data-plane representation of the SPI/SI by carrying the identical semantics in MPLS labels.
虽然[RFC8300]定义了可以在许多环境中使用的NSH，但本文档提供了一种机制来处理NSH未普遍部署的情况。在这种情况下，通过在MPLS标签中携带相同的语义，可以使用SPI/SI的替代数据平面表示。
In order to correctly select the mechanism by which SFC information is encoded and carried between SFFs, it may be necessary to configure the capabilities and choices either within the whole Service Function Overlay Network or on a hop-by-hop basis. It is a requirement that both ends of a tunnel over the underlay network (i.e., a pair of SFFs adjacent in the SFP) know that the tunnel is used for SFC and know what form of NSH representation is used. A control-plane signaling approach to achieve these objectives is provided using BGP in [BGP-NSH-SFC].
为了正确选择SFC信息在SFF之间编码和传输的机制，可能需要在整个服务功能覆盖网络内或在逐跳基础上配置功能和选择。要求基线网络上隧道的两端（即SFP中相邻的一对SFF）知道隧道用于SFC，并知道使用何种形式的NSH表示。使用[BGP-NSH-SFC]中的BGP提供了实现这些目标的控制平面信令方法。
Note that the encoding of the SFC information is independent of the choice of tunneling technology used between SFFs. Thus, an MPLS representation of the logical NSH (as defined in this document) may be used even if the tunnel between a pair of SFFs is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself).
请注意，SFC信息的编码与SFF之间使用的隧道技术的选择无关。因此，即使一对sff之间的隧道不是MPLS隧道，也可以使用逻辑NSH（如本文中定义的）的MPLS表示。相反，MPLS隧道可用于承载逻辑NSH的其他编码（具体地说，NSH本身）。
There are five scenarios that can be considered for the use of an MPLS encoding in support of SFC. These are set out in the following subsections.
使用MPLS编码支持SFC可以考虑五种方案。这些内容在以下小节中列出。
The primary use case for SFC is described in [RFC7665] and delivered using the NSH, which, as described in [RFC8300], uses an encapsulation with a position indicator that is modified at each SFC hop along the chain to indicate the next hop.
SFC的主要用例在[RFC7665]中描述，并使用NSH交付，如[RFC8300]中所述，NSH使用带有位置指示器的封装，该位置指示器在链上的每个SFC跃点处修改，以指示下一个跃点。
The label-swapping use case scenario effectively replaces the NSH with an MPLS encapsulation as described in Section 6. The MPLS labels encode the same information as the NSH to form a logical NSH. The labels are modified (swapped per [RFC3031]) at each SFC hop along the chain to indicate the next hop. The processing and the forwarding state for a chain (i.e., the actions to take on a received label) are programmed into the network using a control plane or management plane.
标签交换用例场景有效地用MPLS封装替换NSH，如第6节所述。MPLS标签编码与NSH相同的信息以形成逻辑NSH。在链上的每个SFC跃点处修改标签（根据[RFC3031]交换），以指示下一个跃点。链的处理和转发状态（即对接收到的标签采取的操作）使用控制平面或管理平面编程到网络中。
[RFC8459] describes an architecture for hierarchical encapsulation using the NSH. It facilitates partitioning of SFC domains for administrative reasons and allows concatenation of service function chains under the control of a service classifier.
[RFC8459]描述了使用NSH进行分层封装的体系结构。它有助于出于管理原因划分SFC域，并允许在服务分类器的控制下连接服务功能链。
The same function can be achieved in an MPLS network using an MPLS encoding of the logical NSH, and label stacking as defined in [RFC3031] and described in Section 7. In this model, swapping is used per Section 4.1 to navigate one chain, and when the end of the chain is reached, the final label is popped, revealing the label for another chain. Thus, the primary mode is swapping, but stacking is used to enable the ingress classifier to control concatenation of service function chains.
使用逻辑NSH的MPLS编码和[RFC3031]中定义并在第7节中描述的标签堆叠，可以在MPLS网络中实现相同的功能。在此模型中，根据第4.1节使用交换来导航一条链，当到达链的末端时，弹出最终标签，显示另一条链的标签。因此，主要模式是交换，但堆叠用于使入口分类器能够控制服务功能链的串联。
It may be that a service function chain (as described in Section 4.1) allows some leeway in the choice of service function instances along the chain. However, it may be that a service classifier wishes to constrain the choice and this can be achieved using chain concatenation so that the first chain ends at the point of choice, the next label in the stack indicates the specific service function instance to be executed, and the next label in the stack starts a new chain. Thus, a mixture of label swapping and stacking is used.
可能是服务功能链（如第4.1节所述）在选择该链上的服务功能实例时有一定的回旋余地。然而，可能是服务分类器希望约束选择，并且这可以使用链连接来实现，以便第一条链在选择点结束，堆栈中的下一个标签指示要执行的特定服务功能实例，并且堆栈中的下一个标签启动新的链。因此，使用标签交换和堆叠的混合。
The scenario in Section 4.2 may be extended to its logical extreme by making each concatenated chain as short as it can be: one SF. Each label in the stack indicates the next SF to be executed, and the network is programmed through the control plane or management plane to know how to route to the next (i.e., first) hop in each chain just as it would be to support the scenarios in Sections 4.1 and 4.2.
第4.2节中的场景可以通过使每个连接链尽可能短来扩展到其逻辑极限：一个SF。堆栈中的每个标签表示要执行的下一个SF，并且通过控制平面或管理平面对网络进行编程，以了解如何路由到每个链中的下一个（即第一个）跳，就像支持第4.1节和第4.2节中的场景一样。
This scenario is functionally identical to the use of Segment Routing (SR) in an MPLS network (known as SR-MPLS) for SFC, as described in Section 4.5, and the discussion in that section applies to this section as well.
如第4.5节所述，该场景在功能上与SFC在MPLS网络（称为SR-MPLS）中使用段路由（SR）相同，该节中的讨论也适用于本节。
SR-MPLS uses a stack of MPLS labels to encode information about the path and network functions that a packet should traverse. SR-MPLS is achieved by applying control-plane and management-plane techniques to program the MPLS forwarding plane and by imposing labels on packets at the entrance to the SR-MPLS network. An implementation proposal for achieving SFC using SR-MPLS can be found in [SR-Srv-Prog] and is not discussed further in this document.
SR-MPLS使用一堆MPLS标签对数据包应该穿越的路径和网络功能的信息进行编码。SR-MPLS是通过应用控制平面和管理平面技术对MPLS转发平面进行编程，并通过在SR-MPLS网络入口处的数据包上施加标签来实现的。使用SR-MPLS实现SFC的实施方案可在[SR Srv Prog]中找到，本文件不再进一步讨论。
When an MPLS label stack is used to carry a logical NSH, a basic unit of representation is used. This unit comprises two MPLS labels, as shown below. The unit may be present one or more times in the label stack as explained in subsequent sections.
当MPLS标签堆栈用于承载逻辑NSH时，使用基本表示单元。该单元包括两个MPLS标签，如下所示。如后续章节所述，该单元可能在标签堆栈中出现一次或多次。
In order to convey the same information as is present in the NSH, two MPLS label stack entries are used. One carries a label to provide context within the SFC scope (the SFC Context Label), and the other carries a label to show which SF is to be actioned (the SF Label). This two-label unit is shown in Figure 1.
为了传递与NSH中存在的信息相同的信息，使用了两个MPLS标签栈条目。一个带有一个标签以提供SFC范围内的上下文（SFC上下文标签），另一个带有一个标签以显示要采取行动的SF（SF标签）。这两个标签单元如图1所示。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Context Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Context Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Basic Unit of MPLS Label Stack for SFC
图1:SFC的MPLS标签堆栈的基本单元
The fields of these two label stack entries are encoded as follows:
这两个标签堆栈项的字段编码如下：
Label: The Label fields contain the values of the SFC Context Label and the SF Label encoded as 20-bit integers. The precise semantics of these Label fields are dependent on whether the label stack entries are used for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7).
标签：标签字段包含SFC上下文标签和编码为20位整数的SF标签的值。这些标签字段的精确语义取决于标签堆栈条目是用于MPLS标签交换（参见第6节）还是用于MPLS标签堆叠（参见第7节）。
TC: The TC bits have no meaning in this case. They SHOULD be set to zero in both label stack entries when a packet is sent and MUST be ignored on receipt.
TC：在这种情况下，TC位没有意义。发送数据包时，两个标签堆栈条目中的值都应设置为零，并且在接收时必须忽略。
S: The "Bottom of Stack" bit has its usual meaning in MPLS. It MUST be clear in the SFC Context Label stack entry. In the SF Label stack entry, it MUST be clear in all cases except when the label is the bottom of the stack, when it MUST be set.
S：“栈底”位在MPLS中有其通常的含义。它必须在SFC上下文标签堆栈项中清除。在SF标签堆栈条目中，除标签位于堆栈底部时必须设置外，在所有情况下都必须清除。
TTL: The TTL field in the SFC Context Label stack entry SHOULD be set to 1. The TTL in the SF Label stack entry (called the SF TTL) is set according to its use for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7) and is used to mitigate packet loops.
TTL:SFC上下文标签堆栈项中的TTL字段应设置为1。SF标签堆栈条目中的TTL（称为SF TTL）根据其用于MPLS标签交换（见第6节）或MPLS标签堆叠（见第7节）进行设置，并用于缓解数据包循环。
The sections that follow show how this basic unit of MPLS label stack may be used for SFC in the MPLS label-swapping case and in the MPLS label-stacking case. For simplicity, these sections do not describe the use of metadata; that topic is covered separately in Section 12.
以下各节说明了在MPLS标签交换情况和MPLS标签堆叠情况下，如何将MPLS标签堆栈的这个基本单元用于SFC。为简单起见，这些部分不描述元数据的使用；该主题在第12节中单独讨论。
This section describes how the basic unit of MPLS label stack for SFC (introduced in Section 5) is used when MPLS label swapping is in use. The use case scenario for this approach is introduced in Section 4.1.
本节描述了在使用MPLS标签交换时，如何使用SFC的MPLS标签堆栈的基本单元（在第5节中介绍）。第4.1节介绍了这种方法的用例场景。
As can be seen in Figure 2, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used (i.e., MPLS, MPLS in UDP, MPLS in GRE, and MPLS in Virtual Extensible Local Area Networks
如图2所示，标签栈的顶部包括通过SFF之间的MPLS隧道交付数据包所需的标签。可以使用任何MPLS封装（即，MPLS、UDP中的MPLS、GRE中的MPLS以及虚拟可扩展局域网中的MPLS）
(VXLANs) or the Generic Protocol Extension for VXLAN (GPE)); thus, the tunnel technology does not need to be MPLS, but MPLS is shown here for simplicity.
（VXLAN）或VXLAN的通用协议扩展（GPE）；因此，隧道技术不需要是MPLS，但是为了简单起见，这里显示了MPLS。
An entropy label [RFC6790] may also be present, as described in Section 11.
熵标签[RFC6790]也可能存在，如第11节所述。
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+ - - -
| SPI Label |
+---------------+ Basic unit of MPLS label stack for SFC
| SI Label |
+---------------+ - - -
| |
~ Payload ~
| |
---------------
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+ - - -
| SPI Label |
+---------------+ Basic unit of MPLS label stack for SFC
| SI Label |
+---------------+ - - -
| |
~ Payload ~
| |
---------------
Figure 2: The MPLS SFC Label Stack
图2:MPLS SFC标签堆栈
Under these labels (or other encapsulation) comes a single instance of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries (provided in Section 5), the following meanings are applied:
在这些标签（或其他封装）下是SFC的MPLS标签堆栈基本单元的单个实例。除了解释这些标签堆栈条目的字段（在第5节中提供）外，还应用了以下含义：
SPI Label: The Label field of the SFC Context Label stack entry contains the value of the SPI encoded as a 20-bit integer. The semantics of the SPI are exactly as defined in [RFC8300]. Note that an SPI as defined by [RFC8300] can be encoded in 3 octets (i.e., 24 bits), but that the Label field allows for only 20 bits and reserves the values 0 through 15 as "special-purpose labels" [RFC7274]. Thus, a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16.
SPI标签：SFC上下文标签堆栈项的标签字段包含编码为20位整数的SPI值。SPI的语义与[RFC8300]中的定义完全相同。注意，[RFC8300]定义的SPI可编码为3个八位字节（即24位），但标签字段仅允许20位，并将值0到15保留为“专用标签”[RFC7274]。因此，使用逻辑NSH的MPLS表示的系统不得分配大于2^20-1或小于16的SPI值。
SI Label: The Label field of the SF Label stack entry contains the value of the SI exactly as defined in [RFC8300]. Since the SI requires only 8 bits, and to avoid overlap with the special-purpose label range of 0 through 15 [RFC7274], the SI is carried in the top (most significant) 8 bits of the Label field with the low-order 12 bits set to zero.
SI标签：SF标签堆栈项的标签字段包含SI的值，该值与[RFC8300]中的定义完全相同。由于SI只需要8位，并且为了避免与专用标签范围0到15[RFC7274]重叠，SI被携带在标签字段的顶部（最高有效）8位，低阶12位设置为零。
TC: The TC fields are as described in Section 5.
TC：TC字段如第5节所述。
S: The S bits are as described in Section 5.
S：S位如第5节所述。
TTL: The TTL field in the SPI Label stack entry SHOULD be set to 1 as stated in Section 5. The TTL in the SF Label stack entry is decremented once for each forwarding hop in the SFP, i.e., for each SFF transited, and so mirrors the TTL field in the NSH.
TTL:SPI标签堆栈条目中的TTL字段应设置为1，如第5节所述。SF标签堆栈项中的TTL对于SFP中的每个转发跃点（即，对于每个传输的SFF）减小一次，从而镜像NSH中的TTL字段。
The following processing rules apply to the Label fields:
以下处理规则适用于标签字段：
o When a classifier inserts a packet onto an SFP, it sets the SPI Label to indicate the identity of the SFP and sets the SI Label to indicate the first SF in the path.
o 当分类器将数据包插入SFP时，它设置SPI标签以指示SFP的标识，并设置SI标签以指示路径中的第一个SF。
o When a component of the SFC system processes a packet, it uses the SPI Label to identify the SFP and the SI Label to determine which SFF or instance of an SF (an SFI) to deliver the packet to. Under normal circumstances (with the exception of branching and reclassification -- see [BGP-NSH-SFC]), the SPI Label value is preserved on all packets. The SI Label value is modified by SFFs and through reclassification to indicate the next hop along the SFP.
o 当SFC系统的组件处理数据包时，它使用SPI标签来标识SFP，并使用SI标签来确定将数据包交付给哪个SFF或SF实例（SFI）。在正常情况下（分支和重新分类除外——请参见[BGP-NSH-SFC]），SPI标签值保留在所有数据包上。SI标签值由SFFs修改，并通过重新分类来指示SFP上的下一个跃点。
The following processing rules apply to the TTL field of the SF Label stack entry and are derived from Section 2.2 of [RFC8300]:
以下处理规则适用于SF标签堆栈项的TTL字段，并源自[RFC8300]的第2.2节：
o When a classifier places a packet onto an SFP, it MUST set the TTL to a value between 1 and 255. It SHOULD set this according to the expected length of the SFP (i.e., the number of SFs on the SFP), but it MAY set it to a larger value according to local configuration. The maximum TTL value supported in an NSH is 63, and so the practical limit here may also be 63.
o 当分类器将数据包放到SFP上时，它必须将TTL设置为1到255之间的值。它应该根据SFP的预期长度（即SFP上的SF数量）设置此值，但可以根据本地配置将其设置为更大的值。NSH中支持的最大TTL值为63，因此此处的实际限制也可能为63。
o When an SFF receives a packet from any component of the SFC system (classifier, SFI, or another SFF), it MUST discard any packets with TTL set to zero. It SHOULD log such occurrences but MUST apply rate limiting to any such logs.
o 当SFF从SFC系统的任何组件（分类器、SFI或其他SFF）接收到数据包时，它必须丢弃TTL设置为零的任何数据包。它应该记录此类事件，但必须对任何此类日志应用速率限制。
o An SFF MUST decrement the TTL by one each time it performs a lookup to forward a packet to the next SFF.
o SFF每次执行查找以将数据包转发到下一个SFF时，必须将TTL减量1。
o If an SFF decrements the TTL to zero, it MUST NOT send the packet and MUST discard the packet. It SHOULD log such occurrences but MUST apply rate limiting to any such logs.
o 如果SFF将TTL减至零，则它不得发送该数据包，并且必须丢弃该数据包。它应该记录此类事件，但必须对任何此类日志应用速率限制。
o SFIs MUST ignore the TTL but MUST mirror it back to the SFF unmodified along with the SI (which may have been changed by local reclassification).
o SFI必须忽略TTL，但必须将其镜像回未随SI修改的SFF（可能已通过本地重新分类进行更改）。
o If a classifier along the SFP makes any change to the intended path of the packet, including for looping, jumping, or branching (see [BGP-NSH-SFC]), it MUST NOT change the SI TTL of the packet. In particular, each component of the SFC system MUST NOT increase the SI TTL value; otherwise, loops may go undetected.
o 如果沿SFP的分类器对数据包的预期路径进行任何更改，包括循环、跳跃或分支（参见[BGP-NSH-SFC]），则其不得更改数据包的SI TTL。特别是，SFC系统的每个组件不得增加SI TTL值；否则，循环可能无法被检测到。
This section describes how the basic unit of MPLS label stack for SFC (introduced in Section 5) is used when MPLS label stacking is used to carry information about the SFP and SFs to be executed. The use case scenarios for this approach are introduced in Section 4.
本节描述了当MPLS标签堆叠用于携带有关要执行的SFP和SFs的信息时，如何使用SFC的MPLS标签堆栈的基本单元（在第5节中介绍）。第4节介绍了这种方法的用例场景。
As can be seen in Figure 3, the top of the label stack comprises the labels necessary to deliver the packet over the MPLS tunnel between SFFs. Any MPLS encapsulation may be used.
如图3所示，标签栈的顶部包括通过SFF之间的MPLS隧道交付数据包所需的标签。可以使用任何MPLS封装。
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
~ ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| |
~ Payload ~
| |
-------------------
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
~ ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| |
~ Payload ~
| |
-------------------
Figure 3: The MPLS SFC Label Stack for Label Stacking
图3：用于标签堆叠的MPLS SFC标签堆栈
An entropy label [RFC6790] may also be present, as described in Section 11.
熵标签[RFC6790]也可能存在，如第11节所述。
Under these labels comes one or more instances of the basic unit of MPLS label stack for SFC. In addition to the interpretation of the fields of these label stack entries (provided in Section 5), the following meanings are applied:
在这些标签下面是SFC的MPLS标签堆栈基本单元的一个或多个实例。除了解释这些标签堆栈条目的字段（在第5节中提供）外，还应用了以下含义：
SFC Context Label: The Label field of the SFC Context Label stack entry contains a label that delivers SFC context. This label contains the SPI, encoded as a 20-bit integer using the semantics exactly as defined in [RFC8300]. Note that in this case a system using MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. This label may also be used to convey other SFC context-specific semantics, such as indicating how to interpret the SF Label or how to forward the packet to the node that offers the SF if so configured and coordinated with the controller that programs the labels for the SFP.
SFC上下文标签：SFC上下文标签堆栈项的标签字段包含传递SFC上下文的标签。此标签包含SPI，使用[RFC8300]中定义的语义编码为20位整数。注意，在这种情况下，使用逻辑NSH的MPLS表示的系统不得分配大于2^20-1或小于16的SPI值。该标签还可用于传达其他SFC上下文特定语义，例如指示如何解释SF标签或如何将分组转发到提供SF的节点（如果与为SFP编程标签的控制器如此配置和协调）。
SF Label: The Label field of the SF Label stack entry contains a value that identifies the next SFI to be actioned for the packet. This label may be scoped globally or within the context of the preceding SFC Context Label and comes from the range 16 ... 2^20 - 1.
SF标签：SF标签堆栈项的标签字段包含一个值，该值标识要为数据包执行操作的下一个SFI。该标签的范围可以是全局范围，也可以是在前面的SFC上下文标签的上下文范围内，并且来自范围16。。。2^20 - 1.
TC: The TC fields are as described in Section 5.
TC：TC字段如第5节所述。
S: The S bits are as described in Section 5.
S：S位如第5节所述。
TTL: The TTL fields in the SFC Context Label stack entry and in the SF Label stack entry SHOULD be set to 1 as stated in Section 5 but MAY be set to larger values if the label indicated a forwarding operation towards the node that hosts the SF.
TTL：如第5节所述，SFC上下文标签堆栈项和SF标签堆栈项中的TTL字段应设置为1，但如果标签指示向承载SF的节点进行转发操作，则可以设置为更大的值。
The following processing rules apply to the Label fields:
以下处理规则适用于标签字段：
o When a classifier inserts a packet onto an SFP, it adds a stack comprising one or more instances of the basic unit of MPLS label stack for SFC. Taken together, this stack defines the SFs to be actioned and so defines the SFP that the packet will traverse.
o 当分类器将数据包插入SFP时，它会添加一个堆栈，该堆栈包含用于SFC的MPLS标签堆栈基本单元的一个或多个实例。综上所述，该堆栈定义了要操作的SFs，从而定义了数据包将遍历的SFP。
o When a component of the SFC system processes a packet, it uses the top basic unit of label stack for SFC to determine to which SFI to next deliver the packet. When an SFF receives a packet, it examines the top basic unit of MPLS label stack for SFC to determine where to send the packet next. If the next recipient is a local SFI, the SFF strips the basic unit of MPLS label stack for SFC before forwarding the packet.
o 当SFC系统的一个组件处理一个数据包时，它使用SFC标签堆栈的顶部基本单元来确定下一个将数据包交付给哪个SFI。当SFF接收到一个数据包时，它会检查MPLS标签堆栈的顶部基本单元，以便SFC确定下一个数据包的发送位置。如果下一个收件人是本地SFI，则SFF会在转发数据包之前剥离SFC的MPLS标签堆栈的基本单元。
The previous sections describe homogeneous networks where SFC forwarding is either all label swapping or all label popping (stacking). This simplification helps to clarify the explanation of the mechanisms.
前面的章节描述了同质网络，其中SFC转发是全部标签交换或全部标签弹出（堆叠）。这种简化有助于澄清对机制的解释。
However, as described in Section 4.2, some use cases may use label swapping and stacking at the same time. Furthermore, it is also possible that different parts of the network utilize swapping or popping such that an end-to-end service chain has to utilize a combination of both techniques. It is also worth noting that a classifier may be content to use an SFP as installed in the network by a control plane or management plane and so would use label swapping, but that there may be a point in the SFP where a choice of SFIs can be made (perhaps for load balancing) and where, in this instance, the classifier wishes to exert control over that choice by use of a specific entry on the label stack as described in Section 4.3.
然而，如第4.2节所述，一些用例可能同时使用标签交换和堆叠。此外，网络的不同部分也可能利用交换或弹出，使得端到端服务链必须利用这两种技术的组合。还值得注意的是，分类器可能满足于使用由控制平面或管理平面安装在网络中的SFP，因此将使用标签交换，但是在SFP中可能存在一个点，其中可以选择sfi（可能用于负载平衡），并且在该实例中，分类器希望通过使用第4.3节中描述的标签堆栈上的特定条目来控制该选择。
When an SFF receives a packet containing an MPLS label stack, it checks from the context of the incoming interface, and from the SFP indicated by the top label, whether it is processing an {SPI, SI} label pair for label swapping or a {context label, SFI index} label pair for label stacking. It then selects the appropriate SFI to which to send the packet. When it receives the packet back from the SFI, it has four cases to consider.
当SFF接收到包含MPLS标签堆栈的数据包时，它会从传入接口的上下文和顶部标签指示的SFP中检查是否正在处理用于标签交换的{SPI，SI}标签对或用于标签堆栈的{context label，SFI index}标签对。然后，它选择要向其发送数据包的适当SFI。当它从SFI接收数据包时，它需要考虑四种情况。
o If the current hop requires an {SPI, SI} and the next hop requires an {SPI, SI}, it sets the SPI Label according to the SFP to be traversed, selects an instance of the SF to be executed at the next hop, sets the SI Label to the SI value of the next hop, and tunnels the packet to the SFF for that SFI.
o 如果当前跳需要一个{SPI，SI}而下一跳需要一个{SPI，SI}，它将根据要遍历的SFP设置SPI标签，选择要在下一跳执行的SF实例，将SI标签设置为下一跳的SI值，并将数据包隧道到该SFI的SFF。
o If the current hop requires an {SPI, SI} and the next hop requires a {context label, SFI Label}, it pops the {SPI, SI} from the top of the MPLS label stack and tunnels the packet to the SFF indicated by the context label.
o 如果当前跳需要一个{SPI，SI}而下一跳需要一个{context label，SFI label}，它将从MPLS标签堆栈的顶部弹出{SPI，SI}，并将数据包隧道到上下文标签指示的SFF。
o If the current hop requires a {context label, SFI Label}, it pops the {context label, SFI Label} from the top of the MPLS label stack.
o 如果当前跃点需要{context label，SFI label}，它将从MPLS标签堆栈的顶部弹出{context label，SFI label}。
* If the new top of the MPLS label stack contains an {SPI, SI} label pair, it selects an SFI to use at the next hop and tunnels the packet to the SFF for that SFI.
* 如果MPLS标签堆栈的新顶部包含{SPI，SI}标签对，它将选择一个SFI以在下一跳使用，并将数据包隧道到该SFI的SFF。
* If the new top of the MPLS label stack contains a {context label, SFI Label}, it tunnels the packet to the SFF indicated by the context label.
* 如果MPLS标签堆栈的新顶部包含{context-label，SFI-label}，它将数据包隧道到由context-label指示的SFF。
The concept of an "SFC proxy" is introduced in [RFC7665]. An SFC proxy is logically located between an SFF and an SFI that is not "SFC aware". Such SFIs are not capable of handling the SFC encapsulation (whether that be NSH or MPLS) and need the encapsulation stripped from the packets they are to process. In many cases, legacy SFIs that were once deployed as "bumps in the wire" fit into this category until they have been upgraded to be SFC aware.
[RFC7665]中介绍了“证监会代理”的概念。SFC代理在逻辑上位于SFF和非“SFC感知”的SFI之间。此类SFI无法处理SFC封装（无论是NSH还是MPLS），需要从要处理的数据包中剥离封装。在许多情况下，曾经作为“线路中的凸点”部署的传统SFI都属于这一类别，直到它们升级为SFC感知。
The job of an SFC proxy is to remove and then reimpose SFC encapsulation so that the SFF is able to process as though it was communication with an SFC-aware SFI, and so that the SFI is unaware of the SFC encapsulation. In this regard, the job of an SFC proxy is no different when NSH encapsulation is used and when MPLS encapsulation is used as described in this document, although (of course) it is different encapsulation bytes that must be removed and reimposed.
SFC代理的工作是删除并重新导入SFC封装，以便SFF能够像处理与SFC感知SFI的通信一样进行处理，并且SFI不知道SFC封装。在这方面，当使用NSH封装和本文档中描述的使用MPLS封装时，SFC代理的工作没有什么不同，尽管（当然）必须删除和重新导入的是不同的封装字节。
It should be noted that the SFC proxy is a logical function. It could be implemented as a separate physical component on the path from the SFF to the SFI, but it could be co-resident with the SFF or it could be a component of the SFI. This is purely an implementation choice.
应该注意的是，SFC代理是一个逻辑函数。它可以在从SFF到SFI的路径上作为一个单独的物理组件实现，但它可以与SFF共存，也可以是SFI的一个组件。这纯粹是一种实现选择。
Note also that the delivery of metadata (see Section 12) requires specific processing if an SFC proxy is in use. This is also no different when NSH functionality or the MPLS encoding defined in this document is in use, and how it is handled will depend on how (or if) each non-SFC-aware SFI can receive metadata.
还请注意，如果正在使用SFC代理，元数据的交付（见第12节）需要特定的处理。当使用本文档中定义的NSH功能或MPLS编码时，这也没有什么不同，如何处理它将取决于每个非SFC感知SFI如何（或是否）接收元数据。
In order that a packet may be forwarded along an SFP, several functional elements must be executed.
为了可以沿着SFP转发数据包，必须执行几个功能元素。
o Discovery/advertisement of SFIs.
o SFI的发现/广告。
o Computation of the SFP.
o SFP的计算。
o Programming of classifiers.
o 分类器的编程。
o Advertisement of forwarding instructions.
o 转发指示的广告。
Various approaches may be taken. These include a fully centralized model where SFFs report to a central controller the SFIs that they support, the central controller computes the SFP and programs the classifiers, and (if the label-swapping approach is taken) the central controller installs forwarding state in the SFFs that lie on the SFP.
可以采取各种方法。其中包括一个完全集中的模型，其中SFF向中央控制器报告其支持的SFI，中央控制器计算SFP并编程分类器，并且（如果采用标签交换方法），中央控制器在SFP上的SFF中安装转发状态。
Alternatively, a dynamic control plane may be used, such as that described in [BGP-NSH-SFC]. In this case, the SFFs use the control plane to advertise the SFIs that they support, a central controller computes the SFP and programs the classifiers, and (if the label-swapping approach is taken) the central controller uses the control plane to advertise the SFPs so that SFFs that lie on the SFP can install the necessary forwarding state.
或者，可以使用动态控制平面，如[BGP-NSH-SFC]中所述。在这种情况下，SFF使用控制平面公布其支持的SFI，中央控制器计算SFP并编程分类器，并且（如果采用标签交换方法），中央控制器使用控制平面公布SFP，以便位于SFP上的SFF可以安装必要的转发状态。
Entropy is used in ECMP situations to ensure that packets from the same flow travel down the same path, thus avoiding jitter or reordering issues within a flow.
熵用于ECMP情况，以确保来自同一流的数据包沿着同一路径移动，从而避免流内的抖动或重新排序问题。
Entropy is often determined by hashing on specific fields in a packet header, such as the "five-tuple" in the IP and transport headers. However, when an MPLS label stack is present, the depth of the stack could be too large for some processors to correctly determine the entropy hash. This problem is addressed by the inclusion of an entropy label as described in [RFC6790].
熵通常通过对数据包报头中的特定字段进行散列来确定，例如IP和传输报头中的“五元组”。但是，当存在MPLS标签堆栈时，堆栈的深度可能太大，某些处理器无法正确确定熵散列。如[RFC6790]所述，通过加入熵标签来解决该问题。
When entropy is desired for packets as they are carried in MPLS tunnels over the underlay network, it is RECOMMENDED that an entropy label be included in the label stack immediately after the tunnel labels and before the SFC Labels, as shown in Figures 2 and 3.
当数据包在底层网络上的MPLS隧道中传输时需要熵时，建议在隧道标签之后和SFC标签之前立即在标签堆栈中包含熵标签，如图2和图3所示。
If an entropy label is present in an MPLS payload, it is RECOMMENDED that the initial classifier use that value in an entropy label inserted in the label stack when the packet is forwarded (on the first tunnel) to the first SFF. In this case, it is not necessary to remove the entropy label from the payload.
如果MPLS有效载荷中存在熵标签，则建议初始分类器在将分组转发（在第一隧道上）到第一SFF时，在标签堆栈中插入的熵标签中使用该值。在这种情况下，不需要从有效负载中移除熵标签。
Metadata is defined in [RFC7665] as providing "the ability to exchange context information between classifiers and SFs, and among SFs." [RFC8300] defines how this context information can be directly encoded in fields that form part of the NSH encapsulation.
[RFC7665]将元数据定义为“在分类器和SF之间以及SF之间交换上下文信息的能力”。[RFC8300]定义了如何在构成NSH封装一部分的字段中直接编码此上下文信息。
Sections 12.1 and 12.2 describe how metadata is associated with user data packets, and how metadata may be exchanged between SFC nodes in the network, when using an MPLS encoding of the logical representation of the NSH.
第12.1节和第12.2节描述了当使用NSH逻辑表示的MPLS编码时，元数据如何与用户数据包相关联，以及元数据如何在网络中的SFC节点之间交换。
It should be noted that the MPLS encoding is less functional than the direct use of the NSH. Both methods support metadata that is "per-SFP" or "per-flow" (see [RFC8393] for definitions of these terms), but "per-packet" metadata (where the metadata must be carried on each packet because it differs from one packet to the next even on the same flow or SFP) is only supported using the NSH and not using the mechanisms defined in this document.
应当注意，MPLS编码的功能不如直接使用NSH。这两种方法都支持“每SFP”或“每流”元数据（这些术语的定义请参见[RFC8393]），但支持“每包”元数据（其中元数据必须在每个包上携带，因为即使在同一个流或SFP上，每个包之间的元数据也不同）仅支持使用NSH，而不支持使用本文档中定义的机制。
Metadata is achieved in the MPLS realization of the logical NSH by the use of an SFC Metadata Label, which uses the extended special-purpose label construct [RFC7274]. Thus, three label stack entries are present, as shown in Figure 4:
元数据通过使用SFC元数据标签在逻辑NSH的MPLS实现中实现，SFC元数据标签使用扩展的专用标签构造[RFC7274]。因此，存在三个标签堆栈条目，如图4所示：
o The Extension Label (value 15).
o 扩展标签（值15）。
o An extended special-purpose label called the Metadata Label Indicator (MLI) (value 16).
o 一个扩展的专用标签，称为元数据标签指示器（MLI）（值16）。
o The Metadata Label (ML).
o 元数据标签（ML）。
----------------
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
----------------
----------------
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
----------------
Figure 4: The MPLS SFC Metadata Label
图4:MPLS SFC元数据标签
The Metadata Label value is an index into a table of metadata that is programmed into the network using in-band or out-of-band mechanisms. Out-of-band mechanisms potentially include management-plane and control-plane solutions (such as [BGP-NSH-SFC]) but are out of scope for this document. The in-band mechanism is described in Section 12.2.
元数据标签值是元数据表的索引，元数据表使用带内或带外机制编程到网络中。带外机制可能包括管理平面和控制平面解决方案（如[BGP-NSH-SFC]），但不在本文件范围内。带内机构如第12.2节所述。
The SFC Metadata Label (as a set of three labels as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet. For MPLS label swapping, the SFC Metadata Labels are placed immediately after the basic unit of MPLS label stack for SFC, as shown in Figure 5. For MPLS label stacking, the SFC Metadata Labels are placed at the bottom of the label stack, as shown in Figure 6.
SFC元数据标签（如图4所示的一组三个标签）可能在MPLS SFC数据包中出现零次、一次或多次。对于MPLS标签交换，SFC元数据标签立即放置在SFC的MPLS标签堆栈的基本单元之后，如图5所示。对于MPLS标签堆叠，SFC元数据标签放置在标签堆栈的底部，如图6所示。
----------------
~ Tunnel Labels ~
+----------------+
~ Optional ~
~ Entropy Label ~
+----------------+
| SPI Label |
+----------------+
| SI Label |
+----------------+
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
+----------------+
~ Other ~
| Metadata |
~ Label Triples ~
+----------------+
| |
~ Payload ~
| |
----------------
----------------
~ Tunnel Labels ~
+----------------+
~ Optional ~
~ Entropy Label ~
+----------------+
| SPI Label |
+----------------+
| SI Label |
+----------------+
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
+----------------+
~ Other ~
| Metadata |
~ Label Triples ~
+----------------+
| |
~ Payload ~
| |
----------------
Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata Label
图5：用于与元数据标签交换的MPLS SFC标签堆栈
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MLI |
+-------------------+
| Metadata Label |
+-------------------+
~ Other ~
| Metadata |
~ Label Triples ~
+-------------------+
| |
~ Payload ~
| |
-------------------
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MLI |
+-------------------+
| Metadata Label |
+-------------------+
~ Other ~
| Metadata |
~ Label Triples ~
+-------------------+
| |
~ Payload ~
| |
-------------------
Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata Label
图6:MPLS SFC标签堆栈用于标签与元数据标签的堆叠
A mechanism for sending metadata associated with an SFP without a payload packet is described in [RFC8393]. The same approach can be used in an MPLS network where the NSH is logically represented by an MPLS label stack.
[RFC8393]中描述了在没有有效负载分组的情况下发送与SFP相关联的元数据的机制。在MPLS网络中，NSH在逻辑上由MPLS标签堆栈表示，可以使用相同的方法。
The packet header is formed exactly as previously described in this document so that the packet will follow the SFP through the SFC network. However, instead of payload data, metadata is included after the bottom of the MPLS label stack. An extended special-purpose label is used to indicate that the metadata is present. Thus, three label stack entries are present:
数据包报头的形成与本文件前面描述的完全相同，因此数据包将通过SFC网络跟随SFP。但是，元数据不是有效负载数据，而是包含在MPLS标签堆栈的底部之后。扩展的专用标签用于指示元数据存在。因此，存在三个标签堆栈条目：
o The Extension Label (value 15).
o 扩展标签（值15）。
o An extended special-purpose label called the Metadata Present Indicator (MPI) (value 17).
o 一个扩展的专用标签，称为元数据显示指示器（MPI）（值17）。
o The Metadata Label (ML) that is associated with this metadata on this SFP and can be used to indicate the use of the metadata as described in Section 12.
o 与此SFP上的元数据关联的元数据标签（ML），可用于指示元数据的使用，如第12节所述。
The MPI, if present, is placed immediately after the last basic unit of MPLS label stack for SFC. The resultant label stacks are shown in Figure 7 for the MPLS label-swapping case and Figure 8 for the MPLS label-stacking case.
MPI（如果存在）立即放置在SFC的MPLS标签堆栈的最后一个基本单元之后。图7显示了MPLS标签交换情况下的标签堆栈，图8显示了MPLS标签堆叠情况下的标签堆栈。
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+
| SPI Label |
+---------------+
| SI Label |
+---------------+
| Extension = 15|
+---------------+
| MPI |
+---------------+
| Metadata Label|
+---------------+
| |
~ Metadata ~
| |
---------------
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+
| SPI Label |
+---------------+
| SI Label |
+---------------+
| Extension = 15|
+---------------+
| MPI |
+---------------+
| Metadata Label|
+---------------+
| |
~ Metadata ~
| |
---------------
Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying Metadata
图7：用于携带元数据的标签交换的MPLS SFC标签堆栈
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MPI |
+-------------------+
| Metadata Label |
+-------------------+
| |
~ Metadata ~
| |
-------------------
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MPI |
+-------------------+
| Metadata Label |
+-------------------+
| |
~ Metadata ~
| |
-------------------
Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying Metadata
图8：用于标签堆叠的MPLS SFC标签堆栈承载元数据
In both cases, the metadata is formatted as a TLV, as shown in Figure 9.
在这两种情况下，元数据都被格式化为TLV，如图9所示。
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Metadata Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Metadata ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Metadata Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Metadata ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Metadata TLV
图9：元数据TLV
The fields of this TLV are interpreted as follows:
该TLV的字段解释如下：
Length: The length of the metadata carried in the Metadata field in octets, not including any padding.
长度：元数据字段中携带的元数据的长度（以八位字节为单位），不包括任何填充。
Metadata Type: The type of the metadata present. Values for this field are taken from the "NSH MD Types" registry maintained by IANA and defined in [RFC8300] and encoded with the most significant bit first.
元数据类型：当前元数据的类型。此字段的值取自IANA维护的“NSH MD Types”注册表，并在[RFC8300]中定义，并首先用最高有效位编码。
Metadata: The actual metadata formatted as described in whatever document defines the metadata. This field is end-padded with zero to 3 octets of zeroes to take it up to a 4-octet boundary.
元数据：定义元数据的文档中描述的实际元数据格式。该字段末端填充0到3个八位字节的零，以将其带到4个八位字节的边界。
Note that in-band exchange of metadata is vulnerable to packet loss. This is both a risk arising from network faults and an attack vulnerability.
请注意，带内元数据交换容易发生数据包丢失。这既是由网络故障引起的风险，也是一种攻击漏洞。
If packets that arrive at an SFF use an MLI that does not have an entry in the metadata table, an alarm can be raised and the packet can be discarded or processed without the metadata according to local configuration. This provides some long-term mitigation but is not an ideal solution.
如果到达SFF的数据包使用的MLI在元数据表中没有条目，则会发出警报，并根据本地配置丢弃或处理数据包，而不使用元数据。这提供了一些长期缓解措施，但不是理想的解决方案。
Further mitigation of loss of metadata packets can be achieved by retransmitting them at a configurable interval. This is a relatively cheap, but only partial, solution because there may still be a window during which the metadata has not been received.
通过以可配置的间隔重新传输元数据包，可以进一步减轻元数据包的丢失。这是一个相对便宜但只是部分的解决方案，因为可能仍然存在一个未收到元数据的窗口。
The concern of lost metadata may be particularly important when the metadata applicable to a specific MPI is being changed. This could result in out-of-date metadata being applied to a packet. If this is a concern, it is RECOMMENDED that a new MPI be used to install a new entry in the metadata table, and the packets in the flow should be marked with the equivalent new MLI.
当更改适用于特定MPI的元数据时，元数据丢失的问题可能特别重要。这可能会导致对数据包应用过时的元数据。如果这是一个问题，建议使用一个新的MPI在元数据表中安装一个新条目，并且流中的数据包应该用等效的新MLI标记。
Finally, if an application that requires metadata is sensitive to this potential loss or attack, it SHOULD NOT use in-band metadata distribution but SHOULD rely on control-plane or management-plane mechanisms, because these approaches can use a more sophisticated protocol that includes confirmation of delivery and can perform verification or inspection of entries in the metadata table.
最后，如果需要元数据的应用程序对这种潜在的丢失或攻击敏感，则不应使用带内元数据分发，而应依赖于控制平面或管理平面机制，因为这些方法可以使用更复杂的协议，其中包括传递确认，并可以对元数据表中的条目执行验证或检查。
This section reverts to the simplified descriptions of networks that rely wholly on label swapping or label stacking. As described in Section 4, actual deployment scenarios may depend on the use of both mechanisms and utilize a mixed mode as described in Section 8.
本节返回到完全依赖标签交换或标签堆叠的网络的简化描述。如第4节所述，实际部署场景可能取决于两种机制的使用，并使用第8节所述的混合模式。
Consider the simplistic MPLS SFC overlay network shown in Figure 10. A packet is classified for an SFP that will see it pass through two SFs (SFa and SFb) that are accessed through two SFFs (SFFa and SFFb, respectively). The packet is ultimately delivered to the destination, D.
考虑图10所示的简单MPLS SFC覆盖网络。一个数据包被分类为一个SFP，它将通过两个SFF（分别是SFFa和SFFb）访问的两个SF（SFa和SFb）。数据包最终被传送到目的地D。
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFa | | SFb | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFa +-------+ SFFb +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFa | | SFb | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFa +-------+ SFFb +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
Figure 10: Service Function Chaining in an MPLS Network
图10:MPLS网络中的服务功能链
Let us assume that the SFP is computed and assigned an SPI value of 239. The forwarding details of the SFP are distributed (perhaps using the mechanisms of [BGP-NSH-SFC]) so that the SFFs are programmed with the necessary forwarding instructions.
假设计算SFP并为其分配SPI值239。分发SFP的转发细节（可能使用[BGP-NSH-SFC]的机制），以便使用必要的转发指令对SFF进行编程。
The packet progresses as follows:
数据包的进程如下所示：
1. The classifier assigns the packet to the SFP and imposes two label stack entries comprising a single basic unit of MPLS SFC representation:
1. 分类器将分组分配给SFP，并施加两个标签堆栈条目，包括MPLS SFC表示的单个基本单元：
* The higher label stack entry contains a label carrying the SPI value of 239.
* 较高的标签堆栈条目包含一个SPI值为239的标签。
* The lower label stack entry contains a label carrying the SI value of 255.
* 下部标签堆栈条目包含一个SI值为255的标签。
Further labels may be imposed to tunnel the packet from the classifier to SFFa.
可以施加进一步的标签以将分组从分类器隧道到SFFa。
2. When the packet arrives at SFFa, SFFa strips any labels associated with the tunnel that runs from the classifier to SFFa. SFFa examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFa. The packet is forwarded to SFa unmodified.
2. 当数据包到达SFFa时，SFFa会剥离与从分类器到SFFa的隧道相关联的任何标签。SFFa检查顶部标签并匹配SPI/SI，以确定数据包应转发给SFa。数据包未经修改就转发到SFa。
3. SFa performs its designated function and returns the packet to SFFa.
3. SFa执行其指定的功能并将数据包返回给SFFa。
4. SFFa modifies the SI in the lower label stack entry (to 254) and uses the SPI/SI to look up the forwarding instructions. It sends the packet with two label stack entries:
4. SFFa修改较低标签堆栈项中的SI（至254），并使用SPI/SI查找转发指令。它发送带有两个标签堆栈项的数据包：
* The higher label stack entry contains a label carrying the SPI value of 239.
* 较高的标签堆栈条目包含一个SPI值为239的标签。
* The lower label stack entry contains a label carrying the SI value of 254.
* 下部标签堆栈条目包含一个SI值为254的标签。
Further labels may be imposed to tunnel the packet from SFFa to SFFb.
可以施加进一步的标签以将分组从SFFa隧道传输到SFFb。
5. When the packet arrives at SFFb, SFFb strips any labels associated with the tunnel from SFFa. SFFb examines the top labels and matches the SPI/SI to identify that the packet should be forwarded to SFb. The packet is forwarded to SFb unmodified.
5. 当数据包到达SFFb时，SFFb从SFFa中剥离与隧道相关的任何标签。SFFb检查顶部标签并匹配SPI/SI，以确定数据包应转发给SFb。数据包未经修改就转发到SFb。
6. SFb performs its designated function and returns the packet to SFFb.
6. SFb执行其指定的功能并将数据包返回给SFFb。
7. SFFb modifies the SI in the lower label stack entry (to 253) and uses the SPI/SI to look up the forwarding instructions. It determines that it is the last SFF in the SFP, so it strips the two SFC Label stack entries and forwards the payload toward D using the payload protocol.
7. SFFb修改较低标签堆栈项中的SI（至253），并使用SPI/SI查找转发指令。它确定它是SFP中的最后一个SFF，因此它剥离两个SFC标签堆栈条目，并使用有效负载协议将有效负载转发给D。
Alternatively, consider the MPLS SFC overlay network shown in Figure 11. A packet is classified for an SFP that will see it pass through two SFs (SFx and SFy) that are accessed through two SFFs (SFFx and SFFy, respectively). The packet is ultimately delivered to the destination, D.
或者，考虑图11所示的MPLS SFC覆盖网络。一个数据包被分类为一个SFP，它将通过两个SFF（分别是SFFx和SFFy）访问的两个SF（SFx和SFy）。数据包最终被传送到目的地D。
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFx | | SFy | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFx +-------+ SFFy +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFx | | SFy | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFx +-------+ SFFy +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+
Figure 11: Service Function Chaining Using MPLS Label Stacking
图11：使用MPLS标签堆叠的服务功能链接
Let us assume that the SFP is computed and assigned an SPI value of 239. However, the forwarding state for the SFP is not distributed and installed in the network. Instead, it will be attached to the individual packets using the MPLS label stack.
假设计算SFP并为其分配SPI值239。但是，SFP的转发状态未在网络中分发和安装。相反，它将使用MPLS标签堆栈连接到各个数据包。
The packet progresses as follows:
数据包的进程如下所示：
1. The classifier assigns the packet to the SFP and imposes two basic units of MPLS SFC representation to describe the full SFP:
1. 分类器将数据包分配给SFP，并使用MPLS SFC表示的两个基本单元来描述完整的SFP：
* The top basic unit comprises two label stack entries as follows:
* 顶部基本单元包括两个标签堆栈项，如下所示：
+ The higher label stack entry contains a label carrying the SFC context.
+ 较高的标签堆栈条目包含一个带有SFC上下文的标签。
+ The lower label stack entry contains a label carrying the SF indicator for SFx.
+ 下部标签堆栈条目包含一个带有SFx SF指示器的标签。
* The lower basic unit comprises two label stack entries as follows:
* 下部基本单元包括两个标签堆栈项，如下所示：
+ The higher label stack entry contains a label carrying the SFC context.
+ 较高的标签堆栈条目包含一个带有SFC上下文的标签。
+ The lower label stack entry contains a label carrying the SF indicator for SFy.
+ 下部标签堆栈条目包含一个带有SFy SF指示器的标签。
Further labels may be imposed to tunnel the packet from the classifier to SFFx.
可以施加进一步的标签以将分组从分类器隧道到SFFx。
2. When the packet arrives at SFFx, SFFx strips any labels associated with the tunnel from the classifier. SFFx examines the top labels and matches the context/SF values to identify that the packet should be forwarded to SFx. The packet is forwarded to SFx unmodified.
2. 当数据包到达SFFx时，SFFx将从分类器中剥离与隧道相关的所有标签。SFFx检查顶部标签并匹配上下文/SF值，以确定数据包应转发给SFx。数据包未经修改就转发到SFx。
3. SFx performs its designated function and returns the packet to SFFx.
3. SFx执行其指定的功能并将数据包返回给SFFx。
4. SFFx strips the top basic unit of MPLS SFC representation, revealing the next basic unit. It then uses the revealed context/SF values to determine how to route the packet to the next SFF, SFFy. It sends the packet with just one basic unit of MPLS SFC representation comprising two label stack entries:
4. SFFx剥离MPLS SFC表示的顶部基本单元，显示下一个基本单元。然后，它使用显示的上下文/SF值来确定如何将数据包路由到下一个SFF，SFFy。它只发送包含两个标签堆栈项的MPLS SFC表示的一个基本单元的数据包：
* The higher label stack entry contains a label carrying the SFC context.
* 较高的标签堆栈条目包含一个带有SFC上下文的标签。
* The lower label stack entry contains a label carrying the SF indicator for SFy.
* 下部标签堆栈条目包含一个带有SFy SF指示器的标签。
Further labels may be imposed to tunnel the packet from SFFx to SFFy.
可施加进一步的标签以将分组从SFFx隧道至SFFy。
5. When the packet arrives at SFFy, SFFy strips any labels associated with the tunnel from SFFx. SFFy examines the top labels and matches the context/SF values to identify that the packet should be forwarded to SFy. The packet is forwarded to SFy unmodified.
5. 当数据包到达SFFy时，SFFy将从SFFx中剥离与隧道相关的所有标签。SFFy检查顶部标签并匹配上下文/SF值，以确定数据包应转发给SFy。数据包未经修改就转发给SFy。
6. SFy performs its designated function and returns the packet to SFFy.
6. SFy执行其指定的功能并将数据包返回给SFFy。
7. SFFy strips the top basic unit of MPLS SFC representation, revealing the payload packet. It forwards the payload toward D using the payload protocol.
7. SFFy剥离MPLS SFC表示的顶部基本单元，显示有效负载数据包。它使用有效负载协议将有效负载转发给D。
It is not the job of an IETF specification to describe the internals of an implementation, except where that directly impacts upon the bits on the wire that change the likelihood of interoperability or where the availability of configuration or security options directly affects the utility of an implementation.
IETF规范的任务不是描述实现的内部，除非它直接影响到线路上改变互操作性可能性的位，或者配置或安全选项的可用性直接影响实现的实用性。
However, in view of the objective of this document to acknowledge that there may be a need for an interim deployment of SFC functionality in brownfield MPLS networks, this section provides some observations about how an SFF might utilize MPLS features that are available in existing routers. This section is not intended to be definitive or technically complete; rather, it is indicative.
然而，鉴于本文件的目的是承认可能需要在棕地MPLS网络中临时部署SFC功能，本节提供了一些关于SFF如何利用现有路由器中可用的MPLS功能的观察结果。本节不具有决定性或技术完整性；相反，它是指示性的。
Consider the mechanism used to indicate to which Virtual Routing and Forwarding (VRF) system an incoming MPLS packet should be routed in a Layer 3 Virtual Private Network (L3VPN) [RFC4364]. In this case, the top MPLS label is an indicator of the VRF system that is to be used to route the payload.
考虑用于指示在一个第3层虚拟专用网络（L3VPN）[RCF4364]中路由哪个传入的MPLS分组的虚拟路由和转发（VRF）系统的机制。在这种情况下，顶部MPLS标签是用于路由有效负载的VRF系统的指示器。
A similar approach can be taken with the label-swapping SFC technique described in Section 6 such that the SFC Context Label identifies a routing table specific to the SFP. The SF Label can be looked up in the context of this routing table to determine to which SF to direct the packet and how to forward it to the next SFF.
第6节中描述的标签交换SFC技术也可以采用类似的方法，以便SFC上下文标签识别特定于SFP的路由表。可以在此路由表的上下文中查找SF标签，以确定将数据包定向到哪个SF以及如何将其转发到下一个SFF。
Advanced features (such as metadata) are not inspected by SFFs. The packets are passed to SFIs that are MPLS-SFC aware or to SFC proxies, and those components are responsible for handling all metadata issues.
高级功能（如元数据）不受SFFs检查。数据包被传递给支持MPLS-SFC的SFI或SFC代理，这些组件负责处理所有元数据问题。
Of course, an actual implementation might make considerable optimizations on this approach, but this section should provide hints about how MPLS-based SFC might be achieved with relatively small modifications to deployed MPLS devices.
当然，实际的实现可能会对这种方法进行相当大的优化，但本节应该提供一些提示，说明如何通过对部署的MPLS设备进行相对较小的修改来实现基于MPLS的SFC。
Discussion of the security properties of SFC networks can be found in [RFC7665]. Further security discussion for the NSH and its use is provided in [RFC8300]. Those documents provide analysis and present a set of requirements and recommendations for security, and the normative security requirements from those documents apply to this specification. However, it should be noted that those documents do not describe any mechanisms for securing NSH systems.
有关SFC网络安全属性的讨论，请参见[RFC7665]。[RFC8300]中提供了NSH及其使用的进一步安全性讨论。这些文件对安全性进行了分析并提出了一套要求和建议，这些文件中的规范性安全要求适用于本规范。然而，应该注意的是，这些文件没有描述任何保护NSH系统的机制。
It is fundamental to the SFC design that the classifier is a fully trusted element. That is, the classification decision process is not visible to the other elements, and its output is treated as accurate. As such, the classifier has responsibility for determining the processing that the packet will be subject to, including, for example, firewall functions. It is also fundamental to the MPLS design that packets are routed through the network using the path specified by the node imposing the labels and that the labels are swapped or popped correctly. Where an SF is not encapsulation aware, the encapsulation may be stripped by an SFC proxy such that a packet may exist as a native packet (perhaps IP) on the path between the SFC proxy and the SF; however, this is an intrinsic part of the SFC design, which needs to define how a packet is protected in that environment.
分类器是完全可信的元素，这是SFC设计的基础。也就是说，分类决策过程对其他元素不可见，其输出被视为准确的。因此，分类器负责确定分组将要经受的处理，包括例如防火墙功能。MPLS设计的另一个基本原则是，使用施加标签的节点指定的路径在网络中路由数据包，并正确交换或弹出标签。在SF不知道封装的情况下，封装可以由SFC代理剥离，使得包可以作为本机包（可能是IP）存在于SFC代理和SF之间的路径上；然而，这是SFC设计的固有部分，它需要定义如何在该环境中保护数据包。
SFC components are configured and enabled through a management system or a control plane. This document does not make any assumptions about what mechanisms are used. Deployments should, however, be aware that vulnerabilities in the management plane or control plane of an SFC system imply vulnerabilities in the whole SFC system. Thus, control-plane solutions (such as [BGP-NSH-SFC]) and management-plane mechanisms must include security measures that can be enabled by operators to protect their SFC systems.
SFC组件通过管理系统或控制平面进行配置和启用。本文件未对所使用的机制做出任何假设。然而，部署人员应注意，SFC系统的管理平面或控制平面中的漏洞意味着整个SFC系统中的漏洞。因此，控制平面解决方案（如[BGP-NSH-SFC]）和管理平面机制必须包括运营商能够保护其SFC系统的安全措施。
An analysis of the security of MPLS systems is provided in [RFC5920], which also notes that the MPLS forwarding plane has no built-in security mechanisms. Some proposals to add encryption to the MPLS forwarding plane have been suggested [MPLS-Opp-Sec], but no mechanisms have been agreed upon at the time of publication of this document. Additionally, MPLS does not provide any cryptographic integrity protection on the MPLS headers. That means that procedures described in this document rely on three basic principles:
[RFC5920]对MPLS系统的安全性进行了分析，其中还指出，MPLS转发平面没有内置的安全机制。已经提出了一些向MPLS转发平面添加加密的建议[MPLS Opp Sec]，但在本文件发布时尚未商定任何机制。此外，MPLS不在MPLS头上提供任何加密完整性保护。这意味着本文件中描述的程序依赖于三个基本原则：
o The MPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an outside party is not possible. MPLS networks are operated with closed boundaries so that MPLS-encapsulated packets are not admitted to the network, and MPLS headers are stripped before packets are forwarded from the network. This is particularly pertinent in the SFC context because [RFC7665] notes that "The architecture described herein is assumed to be applicable to a single network administrative domain." Furthermore, [RFC8300] states that packets originating outside the SFC-enabled domain MUST be dropped if they contain an NSH and packets exiting the SFC-enabled domain MUST be dropped if they contain an NSH. These constraints apply equally to the use of MPLS to encode a logical representation of the NSH.
o MPLS网络通常被认为是一个封闭的网络，因此外部方不可能插入、修改或检查数据包。MPLS网络以闭合边界运行，因此MPLS封装的数据包不被允许进入网络，并且在数据包从网络转发之前，MPLS报头被剥离。这在SFC上下文中特别相关，因为[RFC7665]注意到“此处描述的架构假定适用于单个网络管理域。”此外，[RFC8300]声明如果包含NSH，则必须丢弃源自启用SFC的域之外的数据包；如果包含NSH，则必须丢弃退出启用SFC的域的数据包。这些约束同样适用于使用MPLS对NSH的逻辑表示进行编码。
o The underlying transport mechanisms (such as Ethernet) between adjacent MPLS nodes may offer security mechanisms that can be used to defend packets "on the wire".
o 相邻MPLS节点之间的底层传输机制（如以太网）可以提供安全机制，用于保护“在线”上的数据包。
o The SFC-capable devices participating in an SFC system are responsible for verifying and protecting payload packets and their contents as well as providing other security capabilities that might be required in the particular system.
o 参与SFC系统的支持SFC的设备负责验证和保护有效负载数据包及其内容，并提供特定系统中可能需要的其他安全功能。
Additionally, where a tunnel is used to link two non-MPLS domains, the tunnel design needs to specify how the tunnel is secured.
此外，当隧道用于链接两个非MPLS域时，隧道设计需要指定如何保护隧道。
Thus, this design relies on the component underlying technologies to address the potential security vulnerabilities, and it documents the necessary protections (or risk of their absence) above. It does not include any native security mechanisms in-band with the MPLS encoding of the NSH functionality.
因此，该设计依赖于组件底层技术来解决潜在的安全漏洞，并记录了上述必要的保护（或缺少保护的风险）。在NSH功能的MPLS编码带中，它不包括任何本机安全机制。
Note that configuration elements of this system (such as the programming of the table of metadata; see Section 12) must also be adequately secured, although such mechanisms are not in scope for this protocol specification.
请注意，该系统的配置元素（如元数据表的编程；参见第12节）也必须得到充分保护，尽管此类机制不在本协议规范的范围内。
No known new security vulnerabilities over the SFC architecture [RFC7665] and the NSH specification [RFC8300] are introduced by this design, but if issues are discovered in the future, it is expected that they will be addressed through modifications to control/ management components of any solution or through changes to the underlying technology.
该设计未引入SFC架构[RFC7665]和NSH规范[RFC8300]上的已知新安全漏洞，但如果将来发现问题，预计将通过修改任何解决方案的控制/管理组件或更改基础技术来解决。
IANA has made allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry as follows:
IANA已从“专用多协议标签交换（MPLS）标签值”注册表的“扩展专用MPLS标签值”子区进行分配，如下所示：
Value | Description | Reference
-------+-----------------------------------+--------------
16 | Metadata Label Indicator (MLI) | RFC 8595
17 | Metadata Present Indicator (MPI) | RFC 8595
Value | Description | Reference
-------+-----------------------------------+--------------
16 | Metadata Label Indicator (MLI) | RFC 8595
17 | Metadata Present Indicator (MPI) | RFC 8595
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 6790，DOI 10.17487/RFC6790，2012年11月<https://www.rfc-editor.org/info/rfc6790>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>.
[RFC7274]Kompella，K.，Andersson，L.，和A.Farrel，“分配和停用特殊用途MPLS标签”，RFC 7274，DOI 10.17487/RFC7274，2014年6月<https://www.rfc-editor.org/info/rfc7274>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8393] Farrel, A. and J. Drake, "Operating the Network Service Header (NSH) with Next Protocol "None"", RFC 8393, DOI 10.17487/RFC8393, May 2018, <https://www.rfc-editor.org/info/rfc8393>.
[RFC8393]Farrel，A.和J.Drake，“使用下一个协议“无”操作网络服务报头（NSH）”，RFC 8393，DOI 10.17487/RFC8393，2018年5月<https://www.rfc-editor.org/info/rfc8393>.
[BGP-NSH-SFC] 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-11, May 2019.
[BGP-NSH-SFC]Farrel，A.，Drake，J.，Rosen，E.，Uttaro，J.，和L.Jalil，“NSH-SFC的BGP控制平面”，在建工程，草案-ietf-bess-NSH-BGP-Control-Plane-11，2019年5月。
[MPLS-Opp-Sec] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-03, March 2017.
[MPLS Opp Sec]Farrel，A.和S.Farrell，“MPLS网络中的机会主义安全”，正在进行的工作，草稿-ietf-MPLS-Opportatic-encrypt-032017年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 3031，DOI 10.17487/RFC3031，2001年1月<https://www.rfc-editor.org/info/rfc3031>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<https://www.rfc-editor.org/info/rfc4364>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402]Filsfils，C.，Ed.，Previdi，S.，Ed.，Ginsberg，L.，Decarene，B.，Litkowski，S.，和R.Shakir，“段路由架构”，RFC 8402，DOI 10.17487/RFC8402，2018年7月<https://www.rfc-editor.org/info/rfc8402>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, "Hierarchical Service Function Chaining (hSFC)", RFC 8459, DOI 10.17487/RFC8459, September 2018, <https://www.rfc-editor.org/info/rfc8459>.
[RFC8459]Dolson，D.，Homma，S.，Lopez，D.，和M.Boucadair，“分层服务功能链（hSFC）”，RFC 8459，DOI 10.17487/RFC8459，2018年9月<https://www.rfc-editor.org/info/rfc8459>.
[SR-Srv-Prog] Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, draft-xuclad-spring-sr-service-programming-02, April 2019.
[SR Srv Prog]Coad，F.，Ed.，Xu，X.，Ed.，Filsfils，C.，Bernier，D.，Li，C.，Decarene，B.，Ma，S.，Yadlapalli，C.，Henderickx，W.，和S.Salsano，“带段路由的服务编程”，进行中的工作，草稿-XUCALD-spring-SR-Service-Programming-022019年4月。
Acknowledgements
致谢
This document derives ideas and text from [BGP-NSH-SFC]. The authors are grateful to all those who contributed to the discussions that led to that work: Loa Andersson, Andrew G. Malis, Alexander (Sasha) Vainshtein, Joel Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments.
本文件源自[BGP-NSH-SFC]的观点和文本。作者感谢所有参与讨论的人：Loa Andersson、Andrew G.Malis、Alexander（Sasha）Vainstein、Joel Halpern、Tony Przygienda、Stuart Mackie、Keyur Patel和Jim Guichard。Loa Andersson提供了有用的审查意见。
Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, and Mach Chen for reviews of this text. Thanks to Russ Mundy for his Security Directorate review and to S Moonesamy for useful discussions. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for comprehensive reviews during IESG evaluation.
感谢Loa Andersson、Lizhong Jin、Matthew Bocci、Joel Halpern和Mach Chen对本文的评论。感谢Russ Mundy的安全理事会审查，感谢S Moonesay的有益讨论。还要感谢Benjamin Kaduk、Alissa Cooper、Eric Rescorla、Mirja Kuehlewind、Alvaro Retana和Martin Vigoureux在IESG评估期间进行的全面审查。
The authors would like to be able to thank the authors of [SR-Srv-Prog] and [RFC8402] whose original work on service chaining and the identification of services using Segment Identifiers (SIDs), and conversation with whom, helped clarify the application of SR-MPLS to SFC.
作者希望能够感谢[SR Srv Prog]和[RFC8402]的作者，他们在服务链接和使用段标识符（SID）识别服务方面的原始工作，以及与他们的对话，帮助澄清了SR-MPLS在SFC的应用。
Particular thanks to Loa Andersson for conversations and advice about working group process.
特别感谢Loa Andersson就工作组流程进行对话并提供建议。
Contributors
贡献者
The following individual contributed text to this document:
以下个人为本文件提供了文本：
Andrew G. Malis Email: agmalis@gmail.com
Andrew G.Malis电子邮件：agmalis@gmail.com
Authors' Addresses
作者地址
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
Email: adrian@olddog.co.uk
Email: adrian@olddog.co.uk
Stewart Bryant Futurewei
斯图尔特·布莱恩特的未来
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com
John Drake Juniper Networks
约翰·德雷克·杜松网络公司
Email: jdrake@juniper.net
Email: jdrake@juniper.net