Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 8393 J. Drake
Category: Standards Track Juniper Networks
ISSN: 2070-1721 May 2018
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 8393 J. Drake
Category: Standards Track Juniper Networks
ISSN: 2070-1721 May 2018
Operating the Network Service Header (NSH) with Next Protocol "None"
使用下一个协议“无”操作网络服务报头（NSH）
Abstract
摘要
This document describes a network that supports Service Function Chaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None".
本文档描述了一个支持使用网络服务头（NSH）的服务功能链接（SFC）的网络，该网络没有有效负载数据，只携带元数据。这是通过定义新的NSH“下一个协议”类型值“无”来实现的。
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.
本文档说明了该机制可能实现或增强的一些功能，但并未提供详尽的用例列表，也无意对其描述的功能进行确定。预计其他文档将更详细地描述特定用例，并为每个用例定义协议机制。
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/rfc8393.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8393.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. The Network Service Header . . . . . . . . . . . . . . . . . 4
3.1. Next Protocol "None" . . . . . . . . . . . . . . . . . . 4
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5
6. Overview of Use Cases . . . . . . . . . . . . . . . . . . . . 6
6.1. Per-SFP Metadata . . . . . . . . . . . . . . . . . . . . 6
6.2. Per-Flow Metadata . . . . . . . . . . . . . . . . . . . . 7
6.3. Coordination between SFC-Aware SFIs . . . . . . . . . . . 7
6.4. Operations, Administration, and Maintenance (OAM) . . . . 8
6.5. Control-Plane and Management-Plane Uses . . . . . . . . . 8
6.6. Non-applicable Use Cases . . . . . . . . . . . . . . . . 9
7. Management and Congestion Control Considerations . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. The Network Service Header . . . . . . . . . . . . . . . . . 4
3.1. Next Protocol "None" . . . . . . . . . . . . . . . . . . 4
4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 4
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5
6. Overview of Use Cases . . . . . . . . . . . . . . . . . . . . 6
6.1. Per-SFP Metadata . . . . . . . . . . . . . . . . . . . . 6
6.2. Per-Flow Metadata . . . . . . . . . . . . . . . . . . . . 7
6.3. Coordination between SFC-Aware SFIs . . . . . . . . . . . 7
6.4. Operations, Administration, and Maintenance (OAM) . . . . 8
6.5. Control-Plane and Management-Plane Uses . . . . . . . . . 8
6.6. Non-applicable Use Cases . . . . . . . . . . . . . . . . 9
7. Management and Congestion Control Considerations . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
An architecture for Service Function Chaining (SFC) is presented in [RFC7665]. That architecture enables packets to be forwarded along Service Function Paths (SFPs) to pass through various Service Functions (SFs) that act on the packets. Each packet is encapsulated with a Network Service Header (NSH) [RFC8300] that identifies the SFP that the packet travels along (by means of a Service Path Identifier -- SPI) and the hop (i.e., the next SF to be executed) along the SFP that the packet has reached (by means of a Service Index -- SI). The SPI and SI are fields encoded in the NSH.
[RFC7665]中介绍了服务功能链（SFC）的体系结构。该体系结构使数据包能够沿着服务功能路径（SFP）转发，以通过作用于数据包的各种服务功能（SF）。每个分组用网络服务报头（NSH）[RFC8300]封装，该网络服务报头（NSH）[RFC8300]标识分组沿着的SFP（通过服务路径标识符--SPI）和分组已经到达的SFP（通过服务索引--SI）的跃点（即，要执行的下一个SF）。SPI和SI是NSH中编码的字段。
Packets are classified at the SFC network ingress boundaries by classifiers (Section 4.4 of [RFC7665]) and have an NSH applied to them. Such packets are forwarded between Service Function Forwarders (SFFs) using tunnels across the underlay network, and each SFF may hand the packet off to one or more Service Function Instances (SFIs) according to the definition of the SFP.
通过分类器（RFC7665第4.4节）在SFC网络入口边界对数据包进行分类，并对其应用NSH。这样的分组在使用穿越底层网络的隧道的服务功能转发器（SFF）之间转发，并且每个SFF可以根据SFP的定义将分组交给一个或多个服务功能实例（sfi）。
The SFC classifier or any SFC-aware SFI may wish to share information (possibly state information) about the SFP, the traffic flow, or a specific packet, and they may do this by adding metadata to packets as part of the NSH. Metadata may be used to enhance or enable the function performed by SFC-aware SFs, may enable coordination and data exchange between SFIs, or may be used to assist a network operator in the diagnosis and monitoring of an SFP. The nature of metadata to be supplied and consumed is implementation- and deployment-specific.
SFC分类器或任何感知SFC的SFI可能希望共享关于SFP、业务流或特定分组的信息（可能是状态信息），并且他们可以通过向分组添加元数据作为NSH的一部分来做到这一点。元数据可用于增强或启用SFC感知SFs执行的功能，可启用SFI之间的协调和数据交换，或可用于协助网络运营商诊断和监控SFP。要提供和使用的元数据的性质是特定于实现和部署的。
This document defines a mechanism for metadata to be carried on an SFP without the need for payload data. This mechanism enables diagnosis and monitoring of SFPs, and coordination between SFC-aware SFIs. The mechanism can be applied without the need for traffic to be flowing; if traffic is flowing, it can be applied without the need to insert what might be substantial amounts of metadata into data packets (an operation that may be costly in some hardware).
本文档定义了一种在SFP上携带元数据的机制，而不需要有效负载数据。该机制可实现SFP的诊断和监控，以及SFC感知SFI之间的协调。该机制可以在不需要流量的情况下应用；如果流量是流动的，则无需在数据包中插入大量元数据即可应用（在某些硬件中，这一操作可能成本高昂）。
This document describes how this function is achieved through the use of a new value for the NSH "Next Protocol" field to indicate "None". Like any NSH packets, such packets are contained within the SFC-enabled domain.
本文件描述了如何通过在NSH“下一个协议”字段中使用新值来表示“无”来实现此功能。与任何NSH数据包一样，此类数据包包含在支持SFC的域中。
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes (see Section 6).
本文档说明了该机制可能实现或增强的一些功能，但并未提供详尽的用例列表，也无意对其所描述的功能进行明确说明（见第6节）。
This document uses the terms defined in [RFC7665] and [RFC8300].
本文件使用[RFC7665]和[RFC8300]中定义的术语。
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]所述进行解释。
The NSH includes a field called "Next Protocol" that is used to indicate the nature of the payload data that follows the NSH. The field can be used by any component that processes the NSH (for example, to understand how to interpret and parse the payload) and by nodes at the end of the SFP that remove the NSH and forward the payload data.
NSH包括一个称为“下一个协议”的字段，该字段用于指示NSH之后的有效载荷数据的性质。该字段可由处理NSH的任何组件（例如，理解如何解释和解析有效载荷）以及SFP末端移除NSH并转发有效载荷数据的节点使用。
This document defines a new value (0x00) for the "Next Protocol" field to indicate that the next protocol is "None", which means that there is no user/payload data following the NSH.
本文档为“下一个协议”字段定义了一个新值（0x00），以指示下一个协议为“无”，这意味着NSH之后没有用户/有效负载数据。
When the next protocol is "None", the rest of the NSH still has meaning; in particular, the metadata carried in the NSH may still be present. It is not intended that a packet with next protocol set to "None" be sent with no metadata (see Section 4). Thus, an SFC-aware node SHOULD NOT create a packet with "Next Protocol" set to "None", Metadata Type set to 0x2, and with an NSH Length of 0x2.
当下一个协议为“无”时，NSH的其余部分仍有意义；特别地，NSH中携带的元数据可能仍然存在。下一个协议设置为“无”的数据包发送时不需要元数据（参见第4节）。因此，支持SFC的节点不应创建“下一个协议”设置为“无”、元数据类型设置为0x2且NSH长度为0x2的数据包。
A packet with no payload data may be inserted at the head end of an SFP (such as at a classifier) and may be easily forwarded by an SFF or SFI on the SFP using the processing rules defined in [RFC8300].
没有有效载荷数据的分组可以插入到SFP的前端（例如在分类器处），并且可以使用[RFC8300]中定义的处理规则由SFP上的SFF或SFI容易地转发。
A packet with no payload may also be generated by an SFC-aware SFI as a result of processing an incoming packet (i.e., triggered by a condition arising from processing a normal NSH packet with a payload). In such cases, the SPI/SI can be inherited from the original packet or can be set according to information supplied in one of three ways:
作为处理传入分组的结果（即，由处理具有有效载荷的正常NSH分组产生的条件触发），具有SFC意识的SFI也可以生成没有有效载荷的分组。在这种情况下，SPI/SI可以从原始分组继承，或者可以根据以下三种方式之一提供的信息进行设置：
o through the control plane,
o 通过控制平面，
o through the management plane, or
o 通过管理层，或
o through information carried in the metadata of the data packet.
o 通过数据包元数据中携带的信息。
This document does not further specify the triggers to generate an NSH packet with a "Next Protocol" set to "None".
本文件未进一步规定生成“下一协议”设置为“无”的NSH数据包的触发器。
An SFC-aware node wishing to send metadata without a data packet (i.e., a node that conforms to this specification):
希望在没有数据包的情况下发送元数据的SFC感知节点（即，符合本规范的节点）：
o MUST create a packet carrying an NSH and the desired metadata.
o 必须创建包含NSH和所需元数据的数据包。
o MUST set the "Next Protocol" field to 0x00.
o 必须将“下一个协议”字段设置为0x00。
o SHOULD ensure that there are no bytes following the end of the NSH (i.e., that there is no payload data).
o 应确保NSH结束后没有字节（即，没有有效负载数据）。
o MUST encapsulate and send the packet as normal for tunneling to the next hop on the SFP as would be done for any NSH packet (i.e., for a data packet following the SFP).
o 必须像对任何NSH数据包（即，SFP之后的数据包）所做的那样，封装并发送数据包，以便通过隧道传输到SFP上的下一跳。
A transit node (SFF, SFI, or classifier) that conforms to this specification and that receives a packet with "Next Protocol" indicating "None" MUST NOT attempt to parse or process beyond the end of the NSH, but it SHOULD process the NSH and the metadata as normal. Processing for nodes that do not support "Next Protocol" set to "None" is described in Section 5. Note, however, that an intermediate node that is instructed to strip all metadata from packets will create a packet with an NSH but no metadata and no payload. Such packets SHOULD NOT continue to be forwarded along the SFP.
符合本规范的传输节点（SFF、SFI或分类器）接收带有“下一个协议”指示“无”的数据包时，不得尝试在NSH结束后解析或处理，但应正常处理NSH和元数据。第5节描述了不支持将“下一个协议”设置为“无”的节点的处理。然而，请注意，被指示从数据包中剥离所有元数据的中间节点将创建具有NSH但没有元数据和有效负载的数据包。此类数据包不应继续沿SFP转发。
A node that is the egress of an SFP would normally strip the NSH and forward the payload according to the setting of the "Next Protocol" field. Such nodes MUST NOT forward packets with "Next Protocol" indicating "None" even if there are some bytes after the NSH.
作为SFP出口的节点通常会剥离NSH，并根据“下一协议”字段的设置转发有效负载。即使NSH后有一些字节，此类节点也不得转发指示“无”的“下一协议”数据包。
In deployments where use of next protocol "None" is not desired, administrators SHOULD instruct SFC-aware nodes to not create such packets and to discard packets with next protocol "None".
在不需要使用下一个协议“无”的部署中，管理员应指示支持SFC的节点不要创建此类数据包，并丢弃下一个协议为“无”的数据包。
SFC-aware nodes that do not understand the meaning of a value contained in the "Next Protocol" field of the NSH are unable to parse the payload. Such nodes silently drop packets with unknown "Next Protocol" values unless explicitly configured to forward them (Section 2.2 of [RFC8300]).
不理解NSH的“下一个协议”字段中包含的值的含义的SFC感知节点无法解析有效负载。除非明确配置为转发数据包，否则此类节点会静默地丢弃具有未知“下一个协议”值的数据包（RFC8300第2.2节）。
This means that legacy SFC-aware nodes that are unaware of the meaning of the "Next Protocol" value "None" will act as follows:
这意味着不知道“下一个协议”值“无”含义的传统SFC感知节点将按如下方式操作：
o SFFs can be configured to forward the packets.
o 可以将SFF配置为转发数据包。
o SFC proxies will drop the packets.
o SFC代理将丢弃数据包。
o SFIs will most likely drop the packets.
o SFI很可能会丢弃数据包。
o Classifiers (i.e., nodes performing reclassification) will most likely drop the packets.
o 分类器（即，执行重新分类的节点）最有可能丢弃数据包。
SFC-aware nodes at the end of an SFP possibly forward packets with no knowledge of the payload in a "pop and forward" form of processing where the NSH is removed, the packet is simply put on an interface, and the payload protocol is known a priori (or assumed). It is a general processing rule for all packet forwarding engines that they should not attempt to send packets with zero length. Packets with the NSH "Next Protocol" field set to "None" are expected to have zero payload length and so should not be forwarded once the NSH has been stripped. In any case, as noted in Section 4, SFC-aware nodes at the end of an SFP do not forward packets with "Next Protocol" set to "None".
SFP末端的SFC感知节点可能在不知道有效负载的情况下以“弹出转发”的处理形式转发数据包，其中NSH被移除，数据包被简单地放在接口上，并且有效负载协议是先验的（或假定的）。所有数据包转发引擎的一般处理规则是，它们不应尝试发送长度为零的数据包。NSH“Next Protocol”字段设置为“None”的数据包的有效负载长度预计为零，因此一旦NSH被剥离，就不应转发。在任何情况下，如第4节所述，SFP末端的SFC感知节点不会转发“下一协议”设置为“无”的数据包。
Per-SFP metadata is metadata that applies to an SFP and any data packets on that SFP. It does not need to be transmitted with every packet, but it can be installed at the points of consumption (such as at SFIs) and applied to all packets on the SFP as they pass through this point. It could be installed by inclusion in the NSH of a data packet sent on the SFP by out-of-band control- or management-plane mechanisms, or by separate metadata-only packets using "Next Protocol" set to "None" as described in this document.
Per SFP元数据是应用于SFP和该SFP上的任何数据包的元数据。它不需要与每个数据包一起传输，但它可以安装在消费点（如SFI），并在SFP上的所有数据包通过该点时应用于这些数据包。它可以通过在NSH中包含通过带外控制或管理平面机制在SFP上发送的数据包，或通过使用本文件中所述的“下一个协议”设置为“无”的单独的仅元数据数据包来安装。
Per-SFP metadata-only packets may be sent along the path of an SFP simply by setting the correct SPI in the NSH, and setting the SI to the correct value for the hop of the SFP at which the metadata is to be introduced. SFC-aware nodes (e.g., classifiers) will know the correct SI values to be used from information supplied by the control or management plane as is the case for NSH packets with payload data.
仅通过在NSH中设置正确的SPI并将SI设置为要引入元数据的SFP的跃点的正确值，就可以沿着SFP的路径发送每个SFP元数据分组。SFC感知节点（例如，分类器）将从控制或管理平面提供的信息中知道要使用的正确SI值，就像具有有效负载数据的NSH数据包的情况一样。
Per-flow metadata is metadata that applies to a subset of the packets on an SFP, such as packets matching a particular 5-tuple of source address, destination address, source port, destination port, and payload protocol. Also, this metadata does not need to be transmitted with every packet, but it can be installed at the SFIs on the SFP and applied to the packets that match the flow description.
每流元数据是应用于SFP上的数据包子集的元数据，例如与源地址、目标地址、源端口、目标端口和有效负载协议的特定5元组匹配的数据包。此外，此元数据不需要随每个数据包一起传输，但它可以安装在SFP上的SFI上，并应用于与流描述匹配的数据包。
If there is just one flow on an SFP, then there is no difference between per-flow metadata and per-SFP metadata as described in Section 6.1.
如果SFP上只有一个流，则按流元数据和按SFP元数据之间没有区别，如第6.1节所述。
In normal processing, the flow to which per-flow metadata applies can be deduced by looking at the payload data in the context of the value of the "Next Protocol" field. However, when "Next Protocol" indicates "None", this cannot be done. In this case, the identity of the flow is carried in the metadata itself.
在正常处理中，可以通过在“下一个协议”字段的值的上下文中查看有效负载数据来推断每个流元数据适用的流。但是，当“下一个协议”指示“无”时，无法执行此操作。在这种情况下，流的标识包含在元数据本身中。
A pair of SFC-aware SFIs (adjacent or not) on an SFP may desire to coordinate state and may do this by sending information encoded in metadata.
SFP上的一对SFC感知SFI（相邻或不相邻）可能希望协调状态，并且可以通过发送元数据中编码的信息来实现这一点。
To do this using the mechanisms defined in this document:
要使用本文档中定义的机制执行此操作，请执行以下操作：
o There must be an SFP that passes through the two SFIs in the direction of sender to receiver.
o 必须有一个SFP沿发送方到接收方的方向穿过两个SFI。
o The sender must know the correct SPI to use.
o 发送方必须知道要使用的正确SPI。
o The sender must know the correct SI to use for the point at which it resides on the SFP.
o 发送方必须知道要用于其驻留在SFP上的点的正确SI。
o Ideally, the receiver will know to remove the packet from the SFP and not forward it further as this might share metadata wider than desirable and would cause unnecessary packets in the network. Note, however, that continued forwarding of such packets would not be substantially harmful in its own right.
o 理想情况下，接收器将知道从SFP中移除分组，而不进一步转发它，因为这可能共享超出期望范围的元数据，并且将导致网络中不必要的分组。然而，请注意，继续转发此类数据包本身不会造成实质性危害。
Note that technically (according to the SFC architecture) the process of inserting a packet into an SFP is performed by a classifier. However, a classifier may be co-resident with an SFI so that an implementation of an SF may also be able to generate NSH packets as described in this document.
注意，在技术上（根据SFC架构），将分组插入SFP的过程由分类器执行。然而，分类器可以与SFI共同驻留，以便SF的实现也可以如本文中所述生成NSH分组。
Note also that a system with SFIs that need to coordinate between each other may be configured so that there is a specific, dedicated SFP between those service functions that is used solely for this purpose. Thus, such an SFI does not need to insert NSH packets onto SFPs used to carry payload data, but it can use (and know the SPI of) this special, dedicated SFP.
还请注意，需要相互协调的带有SFI的系统可以进行配置，以便在仅用于此目的的服务功能之间存在特定的专用SFP。因此，这样的SFI不需要将NSH分组插入到用于承载有效载荷数据的SFP上，但是它可以使用（并且知道）这种特殊的专用SFP的SPI。
Requirements for Operations, Administration, and Maintenance (OAM) in SFC networks are discussed in [SFC-OAM-FRAME]. The NSH definition in [RFC8300] includes an O bit that indicates that the packet contains OAM information.
[SFC-OAM-FRAME]中讨论了SFC网络中的操作、管理和维护（OAM）要求。[RFC8300]中的NSH定义包括一个O位，该位指示数据包包含OAM信息。
If OAM information is carried in packets that also include payload data, that information might be carried between the NSH and the payload. Therefore, the mechanism defined in this document can also be used to carry OAM information independent of payload data.
如果OAM信息在还包括有效载荷数据的分组中携带，则该信息可以在NSH和有效载荷之间携带。因此，本文档中定义的机制也可用于独立于有效负载数据携带OAM信息。
Sending OAM separate from (but interleaved with) packets that carry payload data may have several advantages including:
与承载有效负载数据的分组分开（但与之交织）发送OAM可能具有以下几个优点：
o Sending OAM when there is no other traffic flowing.
o 在没有其他流量流动时发送OAM。
o Sending OAM at predictable intervals.
o 以可预测的时间间隔发送OAM。
o Measuring path qualities distinct from behavior of SFIs.
o 测量不同于SFI行为的路径质量。
o Sending OAM without needing to rewrite payload data buffers.
o 发送OAM而无需重写有效负载数据缓冲区。
o Keeping OAM processing components separate from other processing components.
o 将OAM处理组件与其他处理组件分开。
Mechanisms for providing active OAM [RFC7799] in an SFC network have been proposed [OAM-SFC]. This use case is not intended to define another mechanism for active OAM, but it does illustrate a further option for discussion by the working group.
已经提出了在SFC网络中提供主动OAM[RFC7799]的机制[OAM-SFC]。本用例并不打算为主动OAM定义另一种机制，但它确实说明了供工作组讨论的另一种选择。
As described in Section 6.3, SFPs can be established specifically to carry metadata-only packets. And as described in Section 6.1, metadata-only packets can be sent down existing SFPs. This means that metadata-only packets can be used to carry control-plane and management-plane messages used to control and manage the SFC network.
如第6.3节所述，可以专门建立SFP来承载仅元数据数据包。如第6.1节所述，仅元数据的数据包可以沿现有SFP发送。这意味着仅元数据数据包可用于承载用于控制和管理SFC网络的控制平面和管理平面消息。
In effect, SFPs can be established to serve as a Data Control Network (DCN) or a Management Control Network (MCN). Further details of this process are out of scope for this document, but it should be understood that, just as for OAM, an essential feature of using a control channel is that the various speakers are assigned identifiers (i.e., addresses). In this case, those identifiers could be SPI/SI pairs or could be IP addresses as used in the normal control and management plane of the SFC network.
实际上，可以建立SFP作为数据控制网络（DCN）或管理控制网络（MCN）。该过程的进一步细节不在本文档的范围内，但是应当理解，正如对于OAM一样，使用控制信道的一个基本特征是为各个扬声器分配标识符（即，地址）。在这种情况下，这些标识符可以是SPI/SI对，或者可以是在SFC网络的正常控制和管理平面中使用的IP地址。
Per-packet metadata is metadata that applies specifically to a single payload packet. It informs an SFI how to handle the payload packet and does not apply to any other packet.
每个数据包元数据是专门应用于单个有效负载数据包的元数据。它通知SFI如何处理有效负载数据包，不适用于任何其他数据包。
The mechanisms described in this document are not applicable to per-packet metadata because, by definition, if the "Next Protocol" indicates "None", then there is no packet following the NSH for the metadata to be associated with.
本文档中描述的机制不适用于每个数据包元数据，因为根据定义，如果“下一个协议”指示“无”，则NSH之后没有与元数据相关联的数据包。
The mechanisms described in this document allow SFC-aware nodes in an SFC network to generate additional packets. These are not intended to be sent frequently for any flow, but there is still a risk that they might flood the network. For example, if an attempt is made to use this mechanism for "per-packet metadata" (see Section 6.6) then this might double the number of packets in the network. Similarly, if this mechanism is used for a form of aliveness detection OAM that requires very frequent test messages, then the number of additional messages may be very high. Such additional messages risk causing congestion in the network.
本文档中描述的机制允许SFC网络中感知SFC的节点生成额外的数据包。对于任何流，这些消息都不会频繁发送，但它们仍有可能淹没网络。例如，如果尝试将此机制用于“每个数据包元数据”（参见第6.6节），则这可能会使网络中的数据包数量增加一倍。类似地，如果该机制用于要求非常频繁的测试消息的有效性检测OAM的形式，则附加消息的数量可能非常高。此类附加消息有可能导致网络拥塞。
The underlay network (that is, the tunnels across the underlay between SFC nodes) will not distinguish between data-carrying packets and those packets with "Next Protocol" set to "None". All packets will be treated the same and will need to fall within the capabilities of the underlay network to process and forward packets.
参考底图网络（即SFC节点之间穿过参考底图的隧道）不会区分数据传输包和“下一协议”设置为“无”的包。所有数据包将被同等对待，并且需要在底层网络的能力范围内处理和转发数据包。
Nodes in the SFC overlay network will need to perform special processing on the additional packets according to their roles and according to the application for the metadata. For example, an SFF will likely only have to forward per-SFP metadata, while an SF will need to extract it and process it as it would if the metadata was carried in a packet with user data. On the other hand, metadata might also be used to cause actions at all nodes (see Sections 6.3, 6.4, and 6.5) and could increase the processing load.
SFC覆盖网络中的节点需要根据其角色和元数据应用程序对附加数据包执行特殊处理。例如，SFF可能只需要转发每个SFP元数据，而SF将需要提取并处理它，就像元数据在包含用户数据的数据包中携带一样。另一方面，元数据也可能用于在所有节点上引发操作（请参见第6.3、6.4和6.5节），并可能增加处理负载。
In view of these potential issues, all implementations SHOULD implement rate limits on the generation of per-SFP packets with "Next Protocol" set to "None". Furthermore, these rate limits SHOULD be configurable and applied per SFP and per application so that one application on one SFP does not encumber a different application on this or a different SFP. When an implementation finds that it is unable to generate or send a packet, it SHOULD increment a counter that is accessible by the operator and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
鉴于这些潜在问题，所有实现都应在“下一个协议”设置为“无”的情况下对每SFP数据包的生成实施速率限制。此外，这些费率限制应可配置并适用于每个SFP和每个应用程序，以便一个SFP上的一个应用程序不会妨碍此SFP或不同SFP上的不同应用程序。当实现发现无法生成或发送数据包时，应增加操作员可访问的计数器，并可能发出警报（尽管此类警报本身应具有速率限制）。
Additionally, an SFC node needs to protect itself against another node in the network not applying suitable rate limits. Therefore, implementations SHOULD apply incoming rate limits for SFC packets with "Next Protocol" set to "None". Such rate limits MAY be application aware, per SFC or interface, and SHOULD be configurable, but implementations MAY be more subtle if they are aware of internal processing loads and have access to queues/buffers. In any case, when an implementation drops a received packet because of these rate limits, it SHOULD increment a counter that is accessible by the operator and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
此外，SFC节点需要保护自身免受网络中未应用适当速率限制的另一节点的影响。因此，实现应该对“下一个协议”设置为“无”的SFC数据包应用传入速率限制。这样的速率限制可能是应用程序感知的，每个SFC或接口，并且应该是可配置的，但是如果实现知道内部处理负载并且可以访问队列/缓冲区，则可能会更微妙。在任何情况下，当实现由于这些速率限制而丢弃接收到的数据包时，它应该增加操作员可以访问的计数器，并可能发出警报（尽管此类警报本身应该是速率限制的）。
Suitable default rate limits will restrict an SFC node to not send more than one packet with "Next Protocol" set to "None" per ten data packets on any flow in a unit of time equal to the end-to-end delivery time on the flow.
适当的默认速率限制将限制SFC节点在等于流上的端到端传递时间的时间单位内，在任何流上每十个数据包中不发送多个“下一协议”设置为“无”的数据包。
Metadata-only packets as enabled by this document provide a covert channel. However, this is only different from the metadata feature in the normal NSH in that it can be sent without the presence of a data flow.
本文档启用的仅元数据数据包提供了一个隐蔽通道。但是，这与普通NSH中的元数据功能不同，因为它可以在不存在数据流的情况下发送。
Metadata may, of course, contain sensitive data and may also contain information used to control the behavior of SFIs in the network. As such, this data needs to be protected according to its value and according to the perceived vulnerabilities of the network. Protection of metadata may be achieved by using encrypted transport between SFC entities or by encrypting the metadata in its own right, and by authenticating the sender of the metadata. The need to protect the metadata is not modified by this document and forms part of the NSH definition found in [RFC8300].
当然，元数据可能包含敏感数据，也可能包含用于控制网络中SFI行为的信息。因此，这些数据需要根据其价值和感知到的网络漏洞进行保护。元数据的保护可以通过在SFC实体之间使用加密传输，或者通过对元数据本身进行加密，以及通过验证元数据的发送者来实现。保护元数据的需要不受本文件的修改，而是[RFC8300]中NSH定义的一部分。
The mechanism described in this document might be used to introduce packets into the SFC overlay network and might be used to illegitimately introduce false metadata to the nodes on an SFC.
本文档中描述的机制可用于将数据包引入SFC覆盖网络，并可用于将虚假元数据非法引入SFC上的节点。
Therefore, measures SHOULD be taken to ensure authorization of sources of such packets, and tunneling of such packets into the network SHOULD be prevented.
因此，应采取措施确保此类数据包来源的授权，并应防止此类数据包进入网络的隧道。
The amount of packets with "Next Protocol" set to "None" on an SFP SHOULD be rate limited at each point on the SFP to provide additional network security.
SFP上“Next Protocol”（下一协议）设置为“None”（无）的数据包数量应在SFP上的每个点进行速率限制，以提供额外的网络安全性。
Further discussion of NSH security is presented in [RFC8300].
[RFC8300]中介绍了NSH安全性的进一步讨论。
IANA maintains a registry called "Network Service Header (NSH) Parameters" with a sub-registry called "NSH Next Protocol". IANA has allocated a new value to the sub-registry as follows:
IANA维护一个名为“网络服务头（NSH）参数”的注册表和一个名为“NSH下一个协议”的子注册表。IANA已向子注册表分配了一个新值，如下所示：
Next Protocol | Description | Reference
---------------+---------------+-------------
0x00 | None | RFC 8393
Next Protocol | Description | Reference
---------------+---------------+-------------
0x00 | None | RFC 8393
[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>.
[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>.
[OAM-SFC] Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi-Layer Active OAM for Service Function Chains in Networks", Work in Progress, draft-wang-sfc-multi-layer-oam-10, September 2017.
[OAM-SFC]Mirsky，G.，Meng，W.，Khasnabish，B.，和C.Wang，“网络中服务功能链的多层主动OAM”，正在进行的工作，草稿-Wang-SFC-Multi-Layer-OAM-10，2017年9月。
[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>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]Morton，A.“主动和被动度量和方法（介于两者之间的混合类型）”，RFC 7799，DOI 10.17487/RFC7799，2016年5月<https://www.rfc-editor.org/info/rfc7799>.
[SFC-OAM-FRAME] Aldrin, S., Pignataro, C., Kumar, N., Akiya, N., Krishnan, R., and A. Ghanwani, "Service Function Chaining (SFC) Operation, Administration and Maintenance (OAM) Framework", Work in Progress, draft-ietf-sfc-oam-framework-04, March 2018.
[SFC-OAM-FRAME]Aldrin，S.，Pignataro，C.，Kumar，N.，Akiya，N.，Krishnan，R.，和A.Ghanwani，“服务功能链（SFC）运营、管理和维护（OAM）框架”，在建工程，草案-ietf-SFC-OAM-Framework-042018年3月。
Acknowledgements
致谢
Thanks to the attendees at the SFC interim meeting in Westford, Massachusetts in January 2017 for discussions that suggested the value of this document.
感谢2017年1月在马萨诸塞州韦斯特福德举行的证监会临时会议的与会者就本文件的价值进行了讨论。
Thanks to Eric Rosen, Med Boucadair, Greg Mirsky, Dave Dolson, Tal Mizrahi, and Mirja Kuehlewind for valuable review comments.
感谢Eric Rosen、Med Boucadair、Greg Mirsky、Dave Dolson、Tal Mizrahi和Mirja Kuehlewind提供的宝贵评论。
Contributors
贡献者
Lucy Yong Retired
杨露西退休了
Authors' Addresses
作者地址
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
Email: afarrel@juniper.net
Email: afarrel@juniper.net
John Drake Juniper Networks
约翰·德雷克·杜松网络公司
Email: jdrake@juniper.net
Email: jdrake@juniper.net