Internet Engineering Task Force (IETF) P. Quinn, Ed.
Request for Comments: 8300 Cisco
Category: Standards Track U. Elzur, Ed.
ISSN: 2070-1721 Intel
C. Pignataro, Ed.
Cisco
January 2018
Internet Engineering Task Force (IETF) P. Quinn, Ed.
Request for Comments: 8300 Cisco
Category: Standards Track U. Elzur, Ed.
ISSN: 2070-1721 Intel
C. Pignataro, Ed.
Cisco
January 2018
Network Service Header (NSH)
网络服务报头（NSH）
Abstract
摘要
This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining (SFC) encapsulation required to support the SFC architecture (defined in RFC 7665).
本文档描述了施加在分组或帧上的网络服务报头（NSH），以实现服务功能路径（SFP）。NSH还提供了一种沿实例化服务路径进行元数据交换的机制。NSH是支持SFC体系结构（在RFC 7665中定义）所需的服务功能链（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/rfc8300.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8300.
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
1.1. Applicability ..............................................4
1.2. Requirements Language ......................................4
1.3. Definition of Terms ........................................4
1.4. Problem Space ..............................................6
1.5. NSH-Based Service Chaining .................................6
2. Network Service Header ..........................................7
2.1. Network Service Header Format ..............................7
2.2. NSH Base Header ............................................8
2.3. Service Path Header .......................................11
2.4. NSH MD Type 1 .............................................12
2.5. NSH MD Type 2 .............................................13
2.5.1. Optional Variable-Length Metadata ..................13
3. NSH Actions ....................................................15
4. NSH Transport Encapsulation ....................................16
5. Fragmentation Considerations ...................................17
6. Service Path Forwarding with NSH ...............................18
6.1. SFFs and Overlay Selection ................................18
6.2. Mapping the NSH to Network Topology .......................21
6.3. Service Plane Visibility ..................................21
6.4. Service Graphs ............................................22
7. Policy Enforcement with NSH ....................................22
7.1. NSH Metadata and Policy Enforcement .......................22
7.2. Updating/Augmenting Metadata ..............................24
7.3. Service Path Identifier and Metadata ......................25
8. Security Considerations ........................................26
8.1. NSH Security Considerations from Operators' Environments ..27
8.2. NSH Security Considerations from the SFC Architecture .....28
8.2.1. Integrity ..........................................29
8.2.2. Confidentiality ....................................31
9. IANA Considerations ............................................32
9.1. NSH Parameters ............................................32
9.1.1. NSH Base Header Bits ...............................32
9.1.2. NSH Version ........................................32
9.1.3. NSH MD Types .......................................33
9.1.4. NSH MD Class .......................................33
9.1.5. NSH IETF-Assigned Optional Variable-Length
Metadata Types .....................................34
9.1.6. NSH Next Protocol ..................................35
10. NSH-Related Codepoints ........................................35
10.1. NSH Ethertype ............................................35
11. References ....................................................36
Acknowledgments ...................................................38
Contributors ......................................................39
Authors' Addresses ................................................40
1. Introduction ....................................................3
1.1. Applicability ..............................................4
1.2. Requirements Language ......................................4
1.3. Definition of Terms ........................................4
1.4. Problem Space ..............................................6
1.5. NSH-Based Service Chaining .................................6
2. Network Service Header ..........................................7
2.1. Network Service Header Format ..............................7
2.2. NSH Base Header ............................................8
2.3. Service Path Header .......................................11
2.4. NSH MD Type 1 .............................................12
2.5. NSH MD Type 2 .............................................13
2.5.1. Optional Variable-Length Metadata ..................13
3. NSH Actions ....................................................15
4. NSH Transport Encapsulation ....................................16
5. Fragmentation Considerations ...................................17
6. Service Path Forwarding with NSH ...............................18
6.1. SFFs and Overlay Selection ................................18
6.2. Mapping the NSH to Network Topology .......................21
6.3. Service Plane Visibility ..................................21
6.4. Service Graphs ............................................22
7. Policy Enforcement with NSH ....................................22
7.1. NSH Metadata and Policy Enforcement .......................22
7.2. Updating/Augmenting Metadata ..............................24
7.3. Service Path Identifier and Metadata ......................25
8. Security Considerations ........................................26
8.1. NSH Security Considerations from Operators' Environments ..27
8.2. NSH Security Considerations from the SFC Architecture .....28
8.2.1. Integrity ..........................................29
8.2.2. Confidentiality ....................................31
9. IANA Considerations ............................................32
9.1. NSH Parameters ............................................32
9.1.1. NSH Base Header Bits ...............................32
9.1.2. NSH Version ........................................32
9.1.3. NSH MD Types .......................................33
9.1.4. NSH MD Class .......................................33
9.1.5. NSH IETF-Assigned Optional Variable-Length
Metadata Types .....................................34
9.1.6. NSH Next Protocol ..................................35
10. NSH-Related Codepoints ........................................35
10.1. NSH Ethertype ............................................35
11. References ....................................................36
Acknowledgments ...................................................38
Contributors ......................................................39
Authors' Addresses ................................................40
Service Functions are widely deployed and essential in many networks. These Service Functions provide a range of features such as security, WAN acceleration, and server load balancing. Service Functions may be instantiated at different points in the network infrastructure such as the WAN, data center, and so forth.
在许多网络中，服务功能被广泛部署且必不可少。这些服务功能提供了一系列功能，如安全性、WAN加速和服务器负载平衡。服务功能可以在网络基础设施（如WAN、数据中心等）的不同点实例化。
Prior to development of the SFC architecture [RFC7665] and the protocol specified in this document, current Service Function deployment models have been relatively static and bound to topology for insertion and policy selection. Furthermore, they do not adapt well to elastic service environments enabled by virtualization.
在开发SFC体系结构[RFC7665]和本文档中指定的协议之前，当前的服务功能部署模型是相对静态的，并且绑定到拓扑以进行插入和策略选择。此外，它们不能很好地适应虚拟化支持的弹性服务环境。
New data-center network and cloud architectures require more flexible Service Function deployment models. Additionally, the transition to virtual platforms demands an agile service insertion model that supports dynamic and elastic service delivery. Specifically, the following functions are necessary:
新的数据中心网络和云架构需要更灵活的服务功能部署模型。此外，向虚拟平台的过渡需要支持动态和弹性服务交付的敏捷服务插入模型。具体而言，以下功能是必需的：
1. The movement of Service Functions and application workloads in the network.
1. 网络中服务功能和应用程序工作负载的移动。
2. The ability to easily bind service policy to granular information, such as per-subscriber state.
2. 能够轻松地将服务策略绑定到细粒度信息，例如每个订户状态。
3. The capability to steer traffic to the requisite Service Function(s).
3. 将交通导向必要服务功能的能力。
This document, the Network Service Header (NSH) specification, defines a new data-plane protocol, which is an encapsulation for SFCs. The NSH is designed to encapsulate an original packet or frame and, in turn, be encapsulated by an outer transport encapsulation (which is used to deliver the NSH to NSH-aware network elements), as shown in Figure 1:
本文档，即网络服务头（NSH）规范，定义了一个新的数据平面协议，它是SFCs的封装。NSH被设计成封装原始分组或帧，并依次被外部传输封装（用于将NSH传送到感知NSH的网络元件）封装，如图1所示：
+------------------------------+
| Transport Encapsulation |
+------------------------------+
| Network Service Header (NSH) |
+------------------------------+
| Original Packet / Frame |
+------------------------------+
+------------------------------+
| Transport Encapsulation |
+------------------------------+
| Network Service Header (NSH) |
+------------------------------+
| Original Packet / Frame |
+------------------------------+
Figure 1: Network Service Header Encapsulation
图1：网络服务头封装
The NSH is composed of the following elements:
NSH由以下要素组成：
1. Service Function Path identification.
1. 服务功能路径识别。
2. Indication of location within a Service Function Path.
2. 服务功能路径内的位置指示。
3. Optional, per-packet metadata (fixed-length or variable).
3. 可选，每个数据包元数据（固定长度或变量）。
[RFC7665] provides an overview of a service chaining architecture that clearly defines the roles of the various elements and the scope of a SFC encapsulation. Figure 3 of [RFC7665] depicts the SFC architectural components after classification. The NSH is the SFC encapsulation referenced in [RFC7665].
[RFC7665]概述了服务链体系结构，该体系结构明确定义了各种元素的角色和SFC封装的范围。[RFC7665]的图3描述了分类后的SFC架构组件。NSH是[RFC7665]中引用的SFC封装。
The NSH is designed to be easy to implement across a range of devices, both physical and virtual, including hardware platforms.
NSH设计为易于在一系列设备上实现，包括物理和虚拟设备，包括硬件平台。
The intended scope of the NSH is for use within a single provider's operational domain. This deployment scope is deliberately constrained, as explained also in [RFC7665], and limited to a single network administrative domain. In this context, a "domain" is a set of network entities within a single administration. For example, a network administrative domain can include a single data center, or an overlay domain using virtual connections and tunnels. A corollary is that a network administrative domain has a well-defined perimeter.
NSH的预期范围适用于单个供应商的运营领域。如[RFC7665]中所述，此部署范围被刻意限制，并仅限于单个网络管理域。在此上下文中，“域”是单个管理中的一组网络实体。例如，网络管理域可以包括单个数据中心，也可以包括使用虚拟连接和隧道的覆盖域。由此推论，网络管理域具有定义良好的周界。
An NSH-aware control plane is outside the scope of this document.
NSH感知控制平面不在本文件范围内。
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]所述进行解释。
Byte: All references to "bytes" in this document refer to 8-bit bytes, or octets.
字节：本文件中对“字节”的所有引用均指8位字节或八位字节。
Classification: Defined in [RFC7665].
分类：在[RFC7665]中定义。
Classifier: Defined in [RFC7665].
分类器：在[RFC7665]中定义。
Metadata (MD): Defined in [RFC7665]. The metadata, or context information shared between Classifiers and SFs, and among SFs, is carried on the NSH's Context Headers. It allows summarizing a classification result in the packet itself, avoiding subsequent re-classifications. Examples of metadata include classification information used for policy enforcement and network context for forwarding after service delivery.
元数据（MD）：在[RFC7665]中定义。分类器和SF之间以及SF之间共享的元数据或上下文信息携带在NSH的上下文标头上。它允许在数据包本身中汇总分类结果，避免后续重新分类。元数据的示例包括用于策略实施的分类信息和用于在服务交付后转发的网络上下文。
Network Locator: Data-plane address, typically IPv4 or IPv6, used to send and receive network traffic.
网络定位器：数据平面地址，通常为IPv4或IPv6，用于发送和接收网络流量。
Network Node/Element: Device that forwards packets or frames based on an outer header (i.e., transport encapsulation) information.
网络节点/元件：根据外部报头（即传输封装）信息转发数据包或帧的设备。
Network Overlay: Logical network built on top of an existing network (the underlay). Packets are encapsulated or tunneled to create the overlay network topology.
网络覆盖：建立在现有网络（参考底图）之上的逻辑网络。数据包被封装或隧道化以创建覆盖网络拓扑。
NSH-aware: NSH-aware means SFC-encapsulation-aware, where the NSH provides the SFC encapsulation. This specification uses NSH-aware as a more specific term from the more generic term "SFC-aware" [RFC7665].
NSH感知：NSH感知是指SFC封装感知，其中NSH提供SFC封装。本规范使用NSH aware作为更通用的术语“SFC aware”[RFC7665]中更具体的术语。
Service Classifier: Logical entity providing classification function. Since they are logical, Classifiers may be co-resident with SFC elements such as SFs or SFFs. Service Classifiers perform classification and impose the NSH. The initial Classifier imposes the initial NSH and sends the NSH packet to the first SFF in the path. Non-initial (i.e., subsequent) classification can occur as needed and can alter, or create a new service path.
服务分类器：提供分类功能的逻辑实体。由于它们是逻辑的，分类器可能与SFs或SFF等SFC元素共存。服务分类器执行分类并实施NSH。初始分类器施加初始NSH，并将NSH分组发送到路径中的第一个SFF。可以根据需要进行非初始（即后续）分类，并且可以更改或创建新的服务路径。
Service Function (SF): Defined in [RFC7665].
服务功能（SF）：在[RFC7665]中定义。
Service Function Chain (SFC): Defined in [RFC7665].
服务功能链（SFC）：在[RFC7665]中定义。
Service Function Forwarder (SFF): Defined in [RFC7665].
服务功能转发器（SFF）：在[RFC7665]中定义。
Service Function Path (SFP): Defined in [RFC7665].
服务功能路径（SFP）：在[RFC7665]中定义。
Service Plane: The collection of SFFs and associated SFs creates a service-plane overlay in which all SFs and SFC Proxies reside [RFC7665].
服务平面：SFF和相关SF的集合创建一个服务平面覆盖，所有SFs和SFC代理都驻留在其中[RFC7665]。
SFC Proxy: Defined in [RFC7665].
SFC代理：在[RFC7665]中定义。
The NSH addresses several limitations associated with Service Function deployments. [RFC7498] provides a comprehensive review of those issues.
NSH解决了与服务功能部署相关的几个限制。[RFC7498]对这些问题进行了全面审查。
The NSH creates a dedicated service plane; more specifically, the NSH enables:
NSH创建一个专用服务平面；更具体地说，NSH实现了：
1. Topological Independence: Service forwarding occurs within the service plane, so the underlying network topology does not require modification. The NSH provides an identifier used to select the network overlay for network forwarding.
1. 拓扑独立性：服务转发发生在服务平面内，因此底层网络拓扑不需要修改。NSH提供用于选择网络转发的网络覆盖的标识符。
2. Service Chaining: The NSH enables service chaining per [RFC7665]. The NSH contains path identification information needed to realize a service path. Furthermore, the NSH provides the ability to monitor and troubleshoot a service chain, end-to-end via service-specific Operations, Administration, and Maintenance (OAM) messages. The NSH fields can be used by administrators (for example, via a traffic analyzer) to verify the path specifics (e.g., accounting, ensuring correct chaining, providing reports, etc.) of packets being forwarded along a service path.
2. 服务链接：NSH根据[RFC7665]启用服务链接。NSH包含实现服务路径所需的路径标识信息。此外，NSH还提供了通过特定于服务的操作、管理和维护（OAM）消息对服务链进行端到端监控和故障排除的能力。管理员（例如，通过流量分析器）可以使用NSH字段来验证沿服务路径转发的数据包的路径细节（例如，记帐、确保正确链接、提供报告等）。
3. The NSH provides a mechanism to carry shared metadata between participating entities and Service Functions. The semantics of the shared metadata are communicated via a control plane (which is outside the scope of this document) to participating nodes. Section 3.3 of [SFC-CONTROL-PLANE] provides an example of this. Examples of metadata include classification information used for policy enforcement and network context for forwarding post service delivery. Sharing the metadata allows Service Functions to share initial and intermediate classification results with downstream Service Functions saving re-classification, where enough information was enclosed.
3. NSH提供了一种在参与实体和服务功能之间传输共享元数据的机制。共享元数据的语义通过控制平面（不在本文档范围内）传递给参与节点。[SFC-CONTROL-PLANE]第3.3节提供了一个例子。元数据的示例包括用于策略实施的分类信息和用于转发服务后交付的网络上下文。共享元数据允许服务功能与下游服务功能共享初始和中间分类结果，从而节省重新分类的时间，并在其中包含足够的信息。
4. The NSH offers a common and standards-based header for service chaining to all network and service nodes.
4. NSH提供了一个通用的、基于标准的报头，用于将服务链接到所有网络和服务节点。
5. Transport Encapsulation Agnostic: The NSH is transport encapsulation independent: meaning it can be transported by a variety of encapsulation protocols. An appropriate (for a given deployment) encapsulation protocol can be used to carry NSH-encapsulated traffic. This transport encapsulation may form an
5. 传输封装不可知：NSH与传输封装无关：这意味着它可以通过多种封装协议传输。可以使用适当的（对于给定部署）封装协议来承载NSH封装的流量。这种传输封装可以形成一个
overlay network; and if an existing overlay topology provides the required service path connectivity, that existing overlay may be used.
覆盖网络；如果现有覆盖拓扑提供所需的服务路径连接，则可以使用该现有覆盖。
An NSH is imposed on the original packet/frame. This NSH contains service path information and, optionally, metadata that are added to a packet or frame and used to create a service plane. Subsequently, an outer transport encapsulation is imposed on the NSH, which is used for network forwarding.
对原始分组/帧施加NSH。此NSH包含服务路径信息以及（可选）添加到数据包或帧并用于创建服务平面的元数据。随后，在NSH上施加外部传输封装，其用于网络转发。
A Service Classifier adds the NSH. The NSH is removed by the last SFF in the service chain or by an SF that consumes the packet.
服务分类器添加NSH。NSH由服务链中的最后一个SFF或使用该数据包的SF删除。
The NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header, and optional Context Headers, as shown in Figure 2.
NSH由一个4字节的基本报头、一个4字节的服务路径报头和可选的上下文报头组成，如图2所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Context Header(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Context Header(s) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Network Service Header
图2：网络服务头
Base Header: Provides information about the service header and the payload protocol.
基本标头：提供有关服务标头和有效负载协议的信息。
Service Path Header: Provides path identification and location within a service path.
服务路径头：提供服务路径中的路径标识和位置。
Context Header: Carries metadata (i.e., context data) along a service path.
上下文标头：沿服务路径携带元数据（即上下文数据）。
Figure 3 depicts the NSH Base Header:
图3描述了NSH基本标题：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: NSH Base Header
图3:NSH基本收割台
The field descriptions are as follows:
字段描述如下所示：
Version: The Version field is used to ensure backward compatibility going forward with future NSH specification updates. It MUST be set to 0x0 by the sender, in this first revision of the NSH. If a packet presumed to carry an NSH header is received at an SFF, and the SFF does not understand the version of the protocol as indicated in the base header, the packet MUST be discarded, and the event SHOULD be logged. Given the widespread implementation of existing hardware that uses the first nibble after an MPLS label stack for Equal-Cost Multipath (ECMP) decision processing, this document reserves version 01b. This value MUST NOT be used in future versions of the protocol. Please see [RFC7325] for further discussion of MPLS-related forwarding requirements.
版本：版本字段用于确保未来NSH规范更新的向后兼容性。在NSH的第一个版本中，发送方必须将其设置为0x0。如果在SFF处接收到假定携带NSH报头的数据包，并且SFF不理解基本报头中指示的协议版本，则必须丢弃该数据包，并且应记录该事件。鉴于现有硬件的广泛实施，即使用MPLS标签堆栈后的第一个半字节进行等成本多路径（ECMP）决策处理，本文档保留版本01b。此值不得在协议的未来版本中使用。有关MPLS相关转发要求的进一步讨论，请参见[RFC7325]。
O bit: Setting this bit indicates an OAM packet (see [RFC6291]). The actual format and processing of SFC OAM packets is outside the scope of this specification (for example, see [SFC-OAM-FRAMEWORK] for one approach).
O位：设置此位表示OAM数据包（请参阅[RFC6291]）。SFC OAM数据包的实际格式和处理不在本规范的范围内（例如，一种方法见[SFC-OAM-FRAMEWORK]）。
The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM packets. The O bit MUST NOT be modified along the SFP.
必须为OAM数据包设置O位，不得为非OAM数据包设置O位。不得沿SFP修改O位。
SF/SFF/SFC Proxy/Classifier implementations that do not support SFC OAM procedures SHOULD discard packets with O bit set, but MAY support a configurable parameter to enable forwarding received SFC OAM packets unmodified to the next element in the chain. Forwarding OAM packets unmodified by SFC elements that do not support SFC OAM procedures may be acceptable for a subset of OAM functions, but it can result in unexpected outcomes for others; thus, it is recommended to analyze the impact of forwarding an OAM packet for all OAM functions prior to enabling this behavior. The configurable parameter MUST be disabled by default.
不支持SFC OAM过程的SF/SFF/SFC代理/分类器实现应丢弃设置了O位的数据包，但可支持一个可配置参数，以允许将接收到的未经修改的SFC OAM数据包转发到链中的下一个元素。转发未经不支持SFC OAM过程的SFC元素修改的OAM数据包对于OAM功能的子集可能是可接受的，但它可能会导致其他人的意外结果；因此，建议在启用此行为之前，分析转发所有OAM功能的OAM数据包的影响。默认情况下，必须禁用可配置参数。
TTL: Indicates the maximum SFF hops for an SFP. This field is used for service-plane loop detection. The initial TTL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly provided, the default initial TTL value of 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the TTL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a TTL value of 63. The packet MUST NOT be forwarded if TTL is, after decrement, 0.
TTL：表示SFP的最大SFF跃点。此字段用于服务平面回路检测。初始TTL值应可通过控制平面进行配置；配置的初始值可以特定于一个或多个SFP。如果没有明确提供初始值，则必须使用默认的初始TTL值63。在NSH转发查找之前，转发NSH数据包所涉及的每个SFF必须将TTL值减少1。从输入值0减去1将导致TTL值为63。如果TTL在减量后为0，则不得转发数据包。
This TTL field is the primary loop-prevention mechanism. This TTL mechanism represents a robust complement to the Service Index (see Section 2.3), as the TTL is decremented by each SFF. The handling of an incoming 0 TTL allows for better, although not perfect, interoperation with pre-standard implementations that do not support this TTL field.
该TTL字段是主要环路预防机制。该TTL机制代表了对服务索引的一个强大补充（见第2.3节），因为TTL由每个SFF递减。处理传入的0 TTL允许与不支持此TTL字段的预标准实现进行更好的互操作，尽管这并不完美。
Length: The total length, in 4-byte words, of the NSH including the Base Header, the Service Path Header, the Fixed-Length Context Header, or Variable-Length Context Header(s). The length MUST be 0x6 for MD Type 0x1, and it MUST be 0x2 or greater for MD Type 0x2. The length of the Network Service Header MUST be an integer multiple of 4 bytes; thus, variable-length metadata is always padded out to a multiple of 4 bytes.
长度：NSH的总长度（以4字节字表示），包括基本标头、服务路径标头、固定长度上下文标头或可变长度上下文标头。对于MD类型0x1，长度必须为0x6，对于MD类型0x2，长度必须为0x2或更大。网络服务头的长度必须是4字节的整数倍；因此，可变长度元数据始终填充为4字节的倍数。
Unassigned bits: All other flag fields, marked U, are unassigned and available for future use; see Section 9.1.1. Unassigned bits MUST be set to zero upon origination, and they MUST be ignored and preserved unmodified by other NSH supporting elements. At reception, all elements MUST NOT modify their actions based on these unknown bits.
未分配位：所有其他标记为U的标志字段均未分配，可供将来使用；见第9.1.1节。未分配的位在发起时必须设置为零，并且必须忽略这些位，并保持它们不被其他NSH支持元素修改。接收时，所有元件不得基于这些未知位修改其动作。
Metadata (MD) Type: Indicates the format of the NSH beyond the mandatory NSH Base Header and the Service Path Header. MD Type defines the format of the metadata being carried. Please see the IANA Considerations in Section 9.1.3.
元数据（MD）类型：表示NSH的格式超出了必需的NSH基本头和服务路径头。MD Type定义所携带元数据的格式。请参见第9.1.3节中的IANA注意事项。
This document specifies the following four MD Type values:
本文件规定了以下四个MD类型值：
0x0: This is a reserved value. Implementations SHOULD silently discard packets with MD Type 0x0.
0x0:这是一个保留值。实现应该以静默方式丢弃MD类型为0x0的数据包。
0x1: This indicates that the format of the header includes a Fixed-Length Context Header (see Figure 5 below).
0x1：这表示头的格式包括一个固定长度的上下文头（参见下面的图5）。
0x2: This does not mandate any headers beyond the Base Header and Service Path Header, but may contain optional Variable-Length Context Header(s). With MD Type 0x2, a length of 0x2 implies there are no Context Headers. The semantics of the Variable-Length Context Header(s) are not defined in this document. The format of the optional Variable-Length Context Headers is provided in Section 2.5.1.
0x2：这不强制要求基本头和服务路径头之外的任何头，但可能包含可选的可变长度上下文头。对于MD类型0x2，长度0x2表示没有上下文标头。本文档中未定义可变长度上下文标题的语义。第2.5.1节提供了可选可变长度上下文标题的格式。
0xF: This value is reserved for experimentation and testing, as per [RFC3692]. Implementations not explicitly configured to be part of an experiment SHOULD silently discard packets with MD Type 0xF.
0xF：根据[RFC3692]，该值保留用于实验和测试。未显式配置为实验一部分的实现应悄悄丢弃MD类型为0xF的数据包。
The format of the Base Header and the Service Path Header is invariant and not affected by MD Type.
基本头和服务路径头的格式是不变的，不受MD类型的影响。
The NSH MD Type 1 and MD Type 2 are described in detail in Sections 2.4 and 2.5, respectively. NSH implementations MUST support MD Types 0x1 and 0x2 (where the length is 0x2). NSH implementations SHOULD support MD Type 0x2 with length greater than 0x2. Devices that do not support MD Type 0x2 with a length greater than 0x2 MUST ignore any optional Context Headers and process the packet without them; the Base Header Length field can be used to determine the original payload offset if access to the original packet/frame is required. This specification does not disallow the MD Type value from changing along an SFP; however, the specification of the necessary mechanism to allow the MD Type to change along an SFP are outside the scope of this document and would need to be defined for that functionality to be available. Packets with MD Type values not supported by an implementation MUST be silently dropped.
第2.4节和第2.5节分别详细描述了NSH MD类型1和MD类型2。NSH实现必须支持MD类型0x1和0x2（其中长度为0x2）。NSH实现应支持长度大于0x2的MD类型0x2。不支持长度大于0x2的MD类型0x2的设备必须忽略任何可选的上下文标头，并在没有这些标头的情况下处理数据包；如果需要访问原始分组/帧，则可以使用基本报头长度字段来确定原始有效负载偏移。本规范不允许MD类型值沿SFP变化；但是，允许MD类型沿SFP更改的必要机制的规范不在本文档的范围内，并且需要为该功能的可用性进行定义。实现不支持具有MD类型值的数据包必须以静默方式丢弃。
Next Protocol: Indicates the protocol type of the encapsulated data. The NSH does not alter the inner payload, and the semantics on the inner protocol remain unchanged due to NSH SFC. Please see the IANA Considerations in Section 9.1.6.
下一个协议：指示封装数据的协议类型。NSH不会改变内部有效负载，并且由于NSH SFC，内部协议的语义保持不变。请参见第9.1.6节中的IANA注意事项。
This document defines the following Next Protocol values:
本文件定义了以下下一个协议值：
0x1: IPv4 0x2: IPv6 0x3: Ethernet 0x4: NSH 0x5: MPLS 0xFE: Experiment 1 0xFF: Experiment 2
0x1:IPv4 0x2:IPv6 0x3:Ethernet 0x4:NSH 0x5:MPLS 0xFE:实验1 0xFF:实验2
The functionality of hierarchical NSH using a Next Protocol value of 0x4 (NSH) is outside the scope of this specification. Packets with Next Protocol values not supported SHOULD be silently dropped by default, although an implementation MAY provide a configuration parameter to forward them. Additionally, an implementation not explicitly configured for a specific experiment [RFC3692] SHOULD silently drop packets with Next Protocol values 0xFE and 0xFF.
使用下一个协议值0x4（NSH）的分层NSH的功能超出了本规范的范围。默认情况下，不支持具有Next协议值的数据包应该被静默丢弃，尽管实现可能会提供一个配置参数来转发它们。此外，未明确为特定实验配置的实现[RFC3692]应以静默方式丢弃具有下一协议值0xFE和0xFF的数据包。
Figure 4 shows the format of the Service Path Header:
图4显示了服务路径头的格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Path Identifier (SPI): 24 bits Service Index (SI): 8 bits
服务路径标识符（SPI）：24位服务索引（SI）：8位
Figure 4: NSH Service Path Header
图4:NSH服务路径头
The meaning of these fields is as follows:
这些字段的含义如下：
Service Path Identifier (SPI): Uniquely identifies a Service Function Path (SFP). Participating nodes MUST use this identifier for SFP selection. The initial Classifier MUST set the appropriate SPI for a given classification result.
服务路径标识符（SPI）：唯一标识服务功能路径（SFP）。参与节点必须使用此标识符进行SFP选择。初始分类器必须为给定的分类结果设置适当的SPI。
Service Index (SI): Provides location within the SFP. The initial Classifier for a given SFP SHOULD set the SI to 255; however, the control plane MAY configure the initial value of the SI as appropriate (i.e., taking into account the length of the SFP). The Service Index MUST be decremented by a value of 1 by Service Functions or by SFC Proxy nodes after performing required services; the new decremented SI value MUST be used in the egress packet's NSH. The initial Classifier MUST send the packet to the first SFF in the identified SFP for forwarding along an SFP. If re-classification occurs, and that re-classification results in a new SPI, the (re-)Classifier is, in effect, the initial Classifier for the resultant SPI.
服务索引（SI）：提供SFP中的位置。给定SFP的初始分类器应将SI设置为255；然而，控制平面可酌情配置SI的初始值（即，考虑SFP的长度）。执行所需服务后，服务函数或SFC代理节点必须将服务索引的值减1；必须在出口数据包的NSH中使用新的递减SI值。初始分类器必须将数据包发送到识别的SFP中的第一个SFF，以便沿着SFP转发。如果发生重新分类，并且重新分类产生新的SPI，则（重新）分类器实际上是结果SPI的初始分类器。
The SI is used in conjunction with the Service Path Identifier for SFP selection and for determining the next SFF/SF in the path. The SI is also valuable when troubleshooting or reporting service paths. While the TTL provides the primary SFF-based loop prevention for this mechanism, SI decrement by SF serves as a limited loop-prevention
SI与服务路径标识符一起用于SFP选择和确定路径中的下一个SFF/SF。SI在排除故障或报告服务路径时也很有价值。虽然TTL为该机制提供了主要的基于SFF的环路预防，但SF的SI减量用作有限环路预防
mechanism. NSH packets, as described above, are discarded when an SFF decrements the TTL to 0. In addition, an SFF that is not the terminal SFF for an SFP will discard any NSH packet with an SI of 0, as there will be no valid next SF information.
机械装置如上所述，当SFF将TTL减至0时，NSH分组被丢弃。此外，不是SFP的终端SFF的SFF将丢弃SI为0的任何NSH数据包，因为将没有有效的下一个SF信息。
When the Base Header specifies MD Type 0x1, a Fixed-Length Context Header (16-bytes) MUST be present immediately following the Service Path Header, as per Figure 5. The value of a Fixed-Length Context Header that carries no metadata MUST be set to zero.
当基本头指定MD类型0x1时，服务路径头之后必须立即出现一个固定长度的上下文头（16字节），如图5所示。不携带元数据的固定长度上下文标头的值必须设置为零。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fixed-Length Context Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fixed-Length Context Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: NSH MD Type 0x1
图5:NSH MD类型0x1
This specification does not make any assumptions about the content of the 16-byte Context Header that must be present when the MD Type field is set to 1, and it does not describe the structure or meaning of the included metadata.
本规范未对MD Type字段设置为1时必须存在的16字节上下文标头的内容做出任何假设，也未描述所包含元数据的结构或含义。
An SFC-aware SF or SFC Proxy needs to receive the data structure and semantics first in order to process the data placed in the mandatory context field. The data structure and semantics include both the allocation schema and order as well as the meaning of the included data. How an SFC-aware SF or SFC Proxy gets the data structure and semantics is outside the scope of this specification.
支持SFC的SF或SFC代理需要首先接收数据结构和语义，以便处理放置在强制上下文字段中的数据。数据结构和语义包括分配模式和顺序以及所包含数据的含义。支持SFC的SF或SFC代理如何获取数据结构和语义超出了本规范的范围。
An SF or SFC Proxy that does not know the format or semantics of the Context Header for an NSH with MD Type 1 MUST discard any packet with such an NSH (i.e., MUST NOT ignore the metadata that it cannot process), and MUST log the event at least once per the SPI for which the event occurs (subject to thresholding).
不知道MD类型为1的NSH的上下文标头的格式或语义的SF或SFC代理必须丢弃具有此类NSH的任何数据包（即，不得忽略其无法处理的元数据），并且必须根据事件发生的SPI至少记录一次事件（根据阈值）。
[NSH-DC-ALLOCATION] and [NSH-BROADBAND-ALLOCATION] provide specific examples of how metadata can be allocated.
[NSH-DC-ALLOCATION]和[NSH-BROADBAND-ALLOCATION]提供了如何分配元数据的具体示例。
When the Base Header specifies MD Type 0x2, zero or more Variable-Length Context Headers MAY be added, immediately following the Service Path Header (see Figure 6). Therefore, Length = 0x2, indicates that only the Base Header and Service Path Header are present (and in that order). The optional Variable-Length Context Headers MUST be of an integer number of 4-bytes. The Base Header Length field MUST be used to determine the offset to locate the original packet or frame for SFC nodes that require access to that information.
当基本头指定MD类型0x2时，可以在服务路径头之后添加零个或多个可变长度上下文头（参见图6）。因此，Length=0x2表示只有基本报头和服务路径报头存在（并按该顺序）。可选的可变长度上下文标头必须是4字节的整数。基本头长度字段必须用于确定偏移量，以便为需要访问该信息的SFC节点定位原始数据包或帧。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Variable-Length Context Headers (opt.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: NSH MD Type 0x2
图6:NSH MD类型0x2
The format of the optional Variable-Length Context Headers, is as depicted in Figure 7.
可选可变长度上下文标题的格式如图7所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable-Length 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata Class | Type |U| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable-Length Metadata |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Variable-Length Context Headers
图7：可变长度上下文标题
Metadata Class (MD Class): Defines the scope of the Type field to provide a hierarchical namespace. Section 9.1.4 defines how the MD Class values can be allocated to standards bodies, vendors, and others.
元数据类（MD类）：定义类型字段的范围以提供分层命名空间。第9.1.4节定义了如何将MD类值分配给标准机构、供应商和其他方。
Type: Indicates the explicit type of metadata being carried. The definition of the Type is the responsibility of the MD Class owner.
类型：指示正在携带的元数据的显式类型。类型的定义由MD类所有者负责。
Unassigned bit: One unassigned bit is available for future use. This bit MUST NOT be set, and it MUST be ignored on receipt.
未分配位：一个未分配位可供将来使用。不得设置该位，并且在收到时必须忽略该位。
Length: Indicates the length of the variable-length metadata, in bytes. In case the metadata length is not an integer number of 4-byte words, the sender MUST add pad bytes immediately following the last metadata byte to extend the metadata to an integer number of 4-byte words. The receiver MUST round the Length field up to the nearest 4-byte-word boundary, to locate and process the next field in the packet. The receiver MUST access only those bytes in the metadata indicated by the Length field (i.e., actual number of bytes) and MUST ignore the remaining bytes up to the nearest 4-byte-word boundary. The length may be 0 or greater.
长度：表示可变长度元数据的长度，以字节为单位。如果元数据长度不是4字节字的整数，发送方必须在最后一个元数据字节后立即添加pad字节，以将元数据扩展到4字节字的整数。接收器必须将长度字段四舍五入到最近的4字节字边界，以定位和处理数据包中的下一个字段。接收方必须仅访问由长度字段指示的元数据中的那些字节（即实际字节数），并且必须忽略剩余字节，直到最近的4字节字边界。长度可以是0或更大。
A value of 0 denotes a Context Header without a Variable-Length Metadata field.
值0表示没有可变长度元数据字段的上下文标头。
This specification does not make any assumption about Context Headers that are mandatory to implement or those that are mandatory to process. These considerations are deployment specific. However, the control plane is entitled to instruct SFC-aware SFs with the data structure of the Context Header together with its scoping (see e.g., Section 3.3.3 of [SFC-CONTROL-PLANE]).
本规范没有对强制实现或强制处理的上下文头进行任何假设。这些注意事项是特定于部署的。但是，控制平面有权使用上下文标头的数据结构及其作用域（例如，参见[SFC-control-plane]第3.3.3节）指示支持SFC的SFs。
Upon receipt of a packet that belongs to a given SFP, if a mandatory-to-process Context Header is missing in that packet, the SFC-aware SF MUST NOT process the packet and MUST log an error at least once per the SPI for which the mandatory metadata is missing.
在收到属于给定SFP的数据包后，如果该数据包中缺少强制处理上下文报头，则支持SFC的SF不得处理该数据包，并且必须在缺少强制元数据的每个SPI中至少记录一次错误。
If multiple mandatory-to-process Context Headers are required for a given SFP, the control plane MAY instruct the SFC-aware SF with the order to consume these Context Headers. If no instructions are provided and the SFC-aware SF will make use of or modify the specific Context Header, then the SFC-aware SF MUST process these Context Headers in the order they appear in an NSH packet.
如果给定SFP需要多个强制处理上下文头，则控制平面可指示支持SFC的SF使用这些上下文头。如果未提供任何说明，且SFC感知SF将使用或修改特定上下文标头，则SFC感知SF必须按照这些上下文标头在NSH数据包中出现的顺序处理这些上下文标头。
If multiple instances of the same metadata are included in an NSH packet, but the definition of that Context Header does not allow for it, the SFC-aware SF MUST process the first instance and ignore subsequent instances. The SFC-aware SF MAY log or increase a counter for this event.
如果NSH数据包中包含同一元数据的多个实例，但该上下文标头的定义不允许，则支持SFC的SF必须处理第一个实例并忽略后续实例。SFC感知SF可能会记录或增加此事件的计数器。
NSH-aware nodes (which include Service Classifiers, SFFs, SFs, and SFC Proxies) may alter the contents of the NSH headers. These nodes have several possible NSH-related actions:
NSH感知节点（包括服务分类器、SFF、SFs和SFC代理）可以改变NSH报头的内容。这些节点有几个可能的NSH相关操作：
1. Insert or remove the NSH: These actions can occur respectively at the start and end of a service path. Packets are classified, and if determined to require servicing, an NSH will be imposed. A
1. 插入或删除NSH：这些操作可以分别发生在服务路径的开始和结束处。对数据包进行分类，如果确定需要服务，将实施NSH。A.
Service Classifier MUST insert an NSH at the start of an SFP. An imposed NSH MUST contain both a valid Base Header and Service Path Header. At the end of an SFP, an SFF MUST remove the NSH before forwarding or delivering the un-encapsulated packet. Therefore, it is the last node operating on the service header.
服务分类器必须在SFP的开头插入NSH。强制NSH必须同时包含有效的基本标头和服务路径标头。在SFP结束时，SFF必须在转发或交付未封装的数据包之前移除NSH。因此，它是在服务头上操作的最后一个节点。
Multiple logical Classifiers may exist within a given service path. Non-initial Classifiers may re-classify data, and that re-classification MAY result in the selection of a different SFP. When the logical Classifier performs re-classification that results in a change of service path, it MUST replace the existing NSH with a new NSH with the Base Header and Service Path Header reflecting the new service path information and MUST set the initial SI. The O bit, the TTL field, and unassigned flags MUST be copied transparently from the old NSH to a new NSH. Metadata MAY be preserved in the new NSH.
给定的服务路径中可能存在多个逻辑分类器。非初始分类器可对数据进行重新分类，且该重新分类可导致选择不同的SFP。当逻辑分类器执行导致服务路径改变的重新分类时，它必须使用反映新服务路径信息的基本报头和服务路径报头替换现有NSH，并且必须设置初始SI。O位、TTL字段和未分配标志必须透明地从旧NSH复制到新NSH。元数据可以保存在新的NSH中。
2. Select service path: The Service Path Header provides service path information and is used by SFFs to determine correct service path selection. SFFs MUST use the Service Path Header for selecting the next SF or SFF in the service path.
2. 选择服务路径：服务路径头提供服务路径信息，并由SFFs用于确定正确的服务路径选择。SFF必须使用服务路径头来选择服务路径中的下一个SF或SFF。
3. Update the NSH: SFs MUST decrement the service index by one. If an SFF receives a packet with an SPI and SI that do not correspond to a valid next hop in a valid SFP, that packet MUST be dropped by the SFF.
3. 更新NSH:SFs必须将服务索引减少1。如果SFF接收到SPI和SI与有效SFP中的有效下一跳不对应的数据包，则SFF必须丢弃该数据包。
Classifiers MAY update Context Headers if new/updated context is available.
如果新的/更新的上下文可用，分类器可能会更新上下文标题。
If an SFC proxy is in use (acting on behalf of an NSH-unaware Service Function for NSH actions), then the proxy MUST update the Service Index and MAY update contexts. When an SFC Proxy receives an NSH-encapsulated packet, it MUST remove the NSH before forwarding it to an NSH-unaware SF. When the SFC Proxy receives a packet back from an NSH-unaware SF, it MUST re-encapsulate it with the correct NSH, and it MUST decrement the Service Index by one.
如果正在使用SFC代理（代表NSH行动的NSH非意识服务职能部门），则该代理必须更新服务索引，并可能更新上下文。当SFC代理收到NSH封装的数据包时，它必须先删除NSH，然后再将其转发给NSH SF。当SFC代理接收到来自NSH不知道SF的数据包时，它必须用正确的NSH重新封装它，并且必须将服务索引减少1。
4. Service policy selection: Service Functions derive policy (i.e., service actions such as permit or deny) selection and enforcement from the NSH. Metadata shared in the NSH can provide a range of service-relevant information such as traffic classification.
4. 服务策略选择：服务功能从NSH派生策略（即，许可或拒绝等服务操作）选择和执行。NSH中共享的元数据可以提供一系列与服务相关的信息，如流量分类。
Figure 8 maps each of the four actions above to the components in the SFC architecture that can perform it.
图8将上述四个操作中的每一个映射到SFC体系结构中可以执行它的组件。
+-----------+-----------------------+-------+---------------+-------+
| | Insert, remove, or |Forward| Update |Service|
| | replace the NSH |the NSH| the NSH |policy |
| | |packets| |sel. |
|Component +-------+-------+-------+ +-------+-------+ |
| | | | | |Dec. |Update | |
| |Insert |Remove |Replace| |Service|Context| |
| | | | | |Index |Header | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | | + | | | + | |
|Classifier | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
|Service | | + | | + | | | |
|Function | | | | | | | |
|Forwarder | | | | | | | |
|(SFF) | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
|Service | | | | | + | + | + |
|Function | | | | | | | |
|(SF) | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | + | | | + | + | |
|SFC Proxy | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
+-----------+-----------------------+-------+---------------+-------+
| | Insert, remove, or |Forward| Update |Service|
| | replace the NSH |the NSH| the NSH |policy |
| | |packets| |sel. |
|Component +-------+-------+-------+ +-------+-------+ |
| | | | | |Dec. |Update | |
| |Insert |Remove |Replace| |Service|Context| |
| | | | | |Index |Header | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | | + | | | + | |
|Classifier | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
|Service | | + | | + | | | |
|Function | | | | | | | |
|Forwarder | | | | | | | |
|(SFF) | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
|Service | | | | | + | + | + |
|Function | | | | | | | |
|(SF) | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
| | + | + | | | + | + | |
|SFC Proxy | | | | | | | |
+-----------+-------+-------+-------+-------+-------+-------+-------+
Figure 8: NSH Action and Role Mapping
图8:NSH行动和角色映射
Once the NSH is added to a packet, an outer transport encapsulation is used to forward the original packet and the associated metadata to the start of a service chain. The encapsulation serves two purposes:
一旦NSH被添加到数据包中，外部传输封装用于将原始数据包和相关元数据转发到服务链的起点。封装有两个目的：
1. Creates a topologically independent services plane. Packets are forwarded to the required services without changing the underlying network topology.
1. 创建拓扑独立的服务平面。数据包被转发到所需的服务，而不改变底层网络拓扑。
2. Transit network nodes simply forward the encapsulated packets without modification.
2. 传输网络节点只需转发封装的数据包，无需修改。
The service header is independent of the transport encapsulation used. Existing transport encapsulations can be used. The presence of an NSH is indicated via a protocol type or another indicator in the outer transport encapsulation.
服务头独立于所使用的传输封装。可以使用现有的传输封装。NSH的存在通过协议类型或外部传输封装中的另一指示符来指示。
The NSH and the associated transport encapsulation header are "added" to the encapsulated packet/frame. This additional information increases the size of the packet.
NSH和相关联的传输封装报头被“添加”到封装的分组/帧。此附加信息增加了数据包的大小。
Within a managed administrative domain, an operator can ensure that the underlay MTU is sufficient to carry SFC traffic without requiring fragmentation. Given that the intended scope of the NSH is within a single provider's operational domain, that approach is sufficient.
在托管管理域内，运营商可以确保底层MTU足以承载SFC流量，而无需分段。鉴于NSH的预期范围在单个供应商的运营领域内，该方法就足够了。
However, although explicitly outside the scope of this specification, there might be cases where the underlay MTU is not large enough to carry the NSH traffic. Since the NSH does not provide fragmentation support at the service plane, the transport encapsulation protocol ought to provide the requisite fragmentation handling. For instance, Section 9 of [RTG-ENCAP] provides exemplary approaches and guidance for those scenarios.
然而，尽管明确超出了本规范的范围，但也可能存在以下情况：底层MTU不够大，无法承载NSH流量。由于NSH不在服务平面提供碎片支持，传输封装协议应该提供必要的碎片处理。例如，[RTG-ENCAP]第9节为这些场景提供了示例性方法和指导。
When the transport encapsulation protocol supports fragmentation, and fragmentation procedures needs to be used, such fragmentation is part of the transport encapsulation logic. If, as it is common, fragmentation is performed by the endpoints of the transport encapsulation, then fragmentation procedures are performed at the sending NSH entity as part of the transport encapsulation, and reassembly procedures are performed at the receiving NSH entity during transport de-encapsulation handling logic. In no case would such fragmentation result in duplication of the NSH header.
当传输封装协议支持分段，并且需要使用分段过程时，这种分段是传输封装逻辑的一部分。如果通常由传输封装的端点执行分段，则作为传输封装的一部分，在发送NSH实体处执行分段过程，并且在传输解除封装处理逻辑期间在接收NSH实体处执行重新组装过程。在任何情况下，这种分段都不会导致NSH报头的重复。
For example, when the NSH is encapsulated in IP, IP-level fragmentation coupled with Path MTU Discovery (PMTUD) (e.g., [RFC8201]) is used. Since PMTUD relies on ICMP messages, an operator should ensure ICMP packets are not blocked. When, on the other hand, the underlay does not support fragmentation procedures, an error message SHOULD be logged when dropping a packet too big. Lastly, NSH-specific fragmentation and reassembly methods may be defined as well, but these methods are outside the scope of this document and subject for future work.
例如，当NSH封装在IP中时，使用与路径MTU发现（PMTUD）（例如，[RFC8201]）耦合的IP级分段。由于PMTUD依赖ICMP消息，操作员应确保ICMP数据包未被阻止。另一方面，如果参考底图不支持分段过程，则在丢弃过大的数据包时应记录错误消息。最后，也可以定义NSH特定的碎片和重组方法，但这些方法不在本文件的范围内，有待进一步研究。
As described above, the NSH contains a Service Path Identifier (SPI) and a Service Index (SI). The SPI is, as per its name, an identifier. The SPI alone cannot be used to forward packets along a service path. Rather, the SPI provides a level of indirection between the service path / topology and the network transport encapsulation. Furthermore, there is no requirement for, or expectation of, an SPI being bound to a predetermined or static network path.
如上所述，NSH包含服务路径标识符（SPI）和服务索引（SI）。根据其名称，SPI是一个标识符。SPI不能单独用于沿服务路径转发数据包。相反，SPI在服务路径/拓扑和网络传输封装之间提供了一定程度的间接性。此外，不要求或期望SPI绑定到预定或静态网络路径。
The Service Index provides an indication of location within a service path. The combination of SPI and SI provides the identification of a logical SF and its order within the service plane. This combination is used to select the appropriate network locator(s) for overlay forwarding. The logical SF may be a single SF or a set of eligible SFs that are equivalent. In the latter case, the SFF provides load distribution amongst the collection of SFs as needed.
服务索引提供服务路径中位置的指示。SPI和SI的组合提供了服务平面内逻辑SF及其顺序的标识。此组合用于为覆盖转发选择适当的网络定位器。逻辑SF可以是单个SF或一组等效的合格SF。在后一种情况下，SFF根据需要在SF集合之间提供负载分配。
SI serves as a mechanism for detecting invalid SFPs. In particular, an SI value of zero indicates that forwarding is incorrect and the packet must be discarded.
SI用作检测无效SFP的机制。特别是，SI值为零表示转发不正确，必须丢弃数据包。
This indirection -- SPI to overlay -- creates a true service plane. That is, the SFF/SF topology is constructed without impacting the network topology, but, more importantly, service-plane-only participants (i.e., most SFs) need not be part of the network overlay topology and its associated infrastructure (e.g., control plane, routing tables, etc.). SFs need to be able to return a packet to an appropriate SFF (i.e., has the requisite NSH information) when service processing is complete. This can be via the overlay or underlay and, in some cases, can require additional configuration on the SF. As mentioned above, an existing overlay topology may be used, provided it offers the requisite connectivity.
这种间接方式（SPI到overlay）创建了一个真正的服务平面。也就是说，SFF/SF拓扑的构造不会影响网络拓扑，但更重要的是，仅服务平面参与者（即，大多数SF）不需要是网络覆盖拓扑及其相关基础设施（例如，控制平面、路由表等）的一部分。当服务处理完成时，SFs需要能够将数据包返回到适当的SFF（即，具有必要的NSH信息）。这可以通过叠加或参考底图实现，在某些情况下，可能需要在SF上进行额外配置。如上所述，可以使用现有的覆盖拓扑，只要它提供必要的连接。
The mapping of SPI to transport encapsulation occurs on an SFF (as discussed above, the first SFF in the path gets an NSH encapsulated packet from the Classifier). The SFF consults the SPI/ID values to determine the appropriate overlay transport encapsulation protocol (several may be used within a given network) and next hop for the requisite SF. Table 1 depicts an example of a single next-hop SPI/ SI-to-network overlay network locator mapping.
SPI到传输封装的映射发生在SFF上（如上所述，路径中的第一个SFF从分类器获取NSH封装的数据包）。SFF参考SPI/ID值以确定适当的覆盖传输封装协议（在给定网络中可以使用多个）和所需SF的下一跳。表1描述了单个下一跳SPI/SI到网络覆盖网络定位器映射的示例。
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | |
| 10 | 254 | 198.51.100.10 | GRE |
| | | | |
| 10 | 251 | 198.51.100.15 | GRE |
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
+------+------+---------------------+-------------------------+
| SPI | SI | Next Hop(s) | Transport Encapsulation |
+------+------+---------------------+-------------------------+
| 10 | 255 | 192.0.2.1 | VXLAN-gpe |
| | | | |
| 10 | 254 | 198.51.100.10 | GRE |
| | | | |
| 10 | 251 | 198.51.100.15 | GRE |
| | | | |
| 40 | 251 | 198.51.100.15 | GRE |
| | | | |
| 50 | 200 | 01:23:45:67:89:ab | Ethernet |
| | | | |
| 15 | 212 | Null (end of path) | None |
+------+------+---------------------+-------------------------+
Table 1: SFF NSH Mapping Example
表1:SFF NSH映射示例
Additionally, further indirection is possible: the resolution of the required SF network locator may be a localized resolution on an SFF, rather than an SFC control plane responsibility, as per Tables 2 and 3.
此外，还可以进一步间接：根据表2和表3，所需SF网络定位器的分辨率可以是SFF上的局部分辨率，而不是SFC控制平面责任。
Please note: VXLAN-gpe and GRE in the above table refer to [VXLAN-GPE] and [RFC2784] [RFC7676], respectively.
请注意：上表中的VXLAN gpe和GRE分别参考[VXLAN-gpe]和[RFC2784][RFC7676]。
+------+-----+----------------+
| SPI | SI | Next Hop(s) |
+------+-----+----------------+
| 10 | 3 | SF2 |
| | | |
| 245 | 12 | SF34 |
| | | |
| 40 | 9 | SF9 |
+------+-----+----------------+
+------+-----+----------------+
| SPI | SI | Next Hop(s) |
+------+-----+----------------+
| 10 | 3 | SF2 |
| | | |
| 245 | 12 | SF34 |
| | | |
| 40 | 9 | SF9 |
+------+-----+----------------+
Table 2: NSH-to-SF Mapping Example
表2:NSH到SF映射示例
+------+-------------------+-------------------------+
| SF | Next Hop(s) | Transport Encapsulation |
+------+-------------------+-------------------------+
| SF2 | 192.0.2.2 | VXLAN-gpe |
| | | |
| SF34 | 198.51.100.34 | UDP |
| | | |
| SF9 | 2001:db8::1 | GRE |
+------+-------------------+-------------------------+
+------+-------------------+-------------------------+
| SF | Next Hop(s) | Transport Encapsulation |
+------+-------------------+-------------------------+
| SF2 | 192.0.2.2 | VXLAN-gpe |
| | | |
| SF34 | 198.51.100.34 | UDP |
| | | |
| SF9 | 2001:db8::1 | GRE |
+------+-------------------+-------------------------+
Table 3: SF Locator Mapping Example
表3:SF定位器映射示例
Since the SPI is a representation of the service path, the lookup may return more than one possible next hop within a service path for a given SF, essentially a series of weighted (equally or otherwise) paths to be used (for load distribution, redundancy, or policy); see Table 4. The metric depicted in Table 4 is an example to help illustrate weighing SFs. In a real network, the metric will range from a simple preference (similar to routing next-hop) to a true dynamic composite metric based on the state of a Service Function (including load, session state, capacity, etc.).
由于SPI是服务路径的表示，因此查找可以在给定SF的服务路径内返回多个可能的下一跳，基本上是要使用的一系列加权（相等或其他）路径（用于负载分配、冗余或策略）；见表4。表4中所示的度量是一个有助于说明SFs称重的示例。在实际网络中，度量的范围从简单的首选项（类似于路由下一跳）到基于服务功能状态（包括负载、会话状态、容量等）的真正动态复合度量。
+------+-----+--------------+---------+
| SPI | SI | NH | Metric |
+------+-----+--------------+---------+
| 10 | 3 | 203.0.113.1 | 1 |
| | | | |
| | | 203.0.113.2 | 1 |
| | | | |
| 20 | 12 | 192.0.2.1 | 1 |
| | | | |
| | | 203.0.113.4 | 1 |
| | | | |
| 30 | 7 | 192.0.2.10 | 10 |
| | | | |
| | | 198.51.100.1 | 5 |
+------+-----+--------------+---------+
+------+-----+--------------+---------+
| SPI | SI | NH | Metric |
+------+-----+--------------+---------+
| 10 | 3 | 203.0.113.1 | 1 |
| | | | |
| | | 203.0.113.2 | 1 |
| | | | |
| 20 | 12 | 192.0.2.1 | 1 |
| | | | |
| | | 203.0.113.4 | 1 |
| | | | |
| 30 | 7 | 192.0.2.10 | 10 |
| | | | |
| | | 198.51.100.1 | 5 |
+------+-----+--------------+---------+
(encapsulation type omitted for formatting)
（格式化时省略封装类型）
Table 4: NSH Weighted Service Path
表4:NSH加权服务路径
The information contained in Tables 1-4 may be received from the control plane, but the exact mechanism is outside the scope of this document.
表1-4中包含的信息可从控制平面接收，但具体机制不在本文件范围内。
As described above, the mapping of the SPI to network topology may result in a single path, or it might result in a more complex topology. Furthermore, the SPI-to-overlay mapping occurs at each SFF independently. Any combination of topology selection is possible. Please note, there is no requirement to create a new overlay topology if a suitable one already exists. NSH packets can use any (new or existing) overlay, provided the requisite connectivity requirements are satisfied.
如上所述，SPI到网络拓扑的映射可能导致单一路径，也可能导致更复杂的拓扑。此外，SPI到覆盖映射独立地发生在每个SFF处。拓扑选择的任何组合都是可能的。请注意，如果已经存在合适的覆盖拓扑，则不需要创建新的覆盖拓扑。NSH数据包可以使用任何（新的或现有的）覆盖，只要满足必要的连接要求。
Examples of mapping for a topology:
拓扑的映射示例：
1. Next SF is located at SFFb with locator 2001:db8::1 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 2001:db8::1
1. 下一个SF位于SFFb，定位器2001:db8:：1 SFFa映射：SPI=10-->VXLAN gpe，dst ip:2001:db8:：1
2. Next SF is located at SFFc with multiple network locators for load-distribution purposes: SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:203.0.113.1, 203.0.113.2, 203.0.113.3, equal cost
2. 下一个SF位于SFFc，带有多个网络定位器，用于负载分配：SFFb映射：SPI=10-->VXLAN gpe，dst_ip:203.0.113.1、203.0.113.2、203.0.113.3，成本相等
3. Next SF is located at SFFd with two paths from SFFc, one for redundancy: SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:192.0.2.10 cost=10, 203.0.113.10, cost=20
3. 下一个SF位于SFFd，有两条来自SFFc的路径，一条用于冗余：SFFc映射：SPI=10-->VXLAN gpe，dst_ip:192.0.2.10成本=10203.0.113.10，成本=20
In the above example, each SFF makes an independent decision about the network overlay path and policy for that path. In other words, there is no a priori mandate about how to forward packets in the network (only the order of services that must be traversed).
在上面的示例中，每个SFF对网络覆盖路径和该路径的策略做出独立的决定。换句话说，关于如何在网络中转发数据包（只有必须遍历的服务顺序）没有先验的规定。
The network operator retains the ability to engineer the network paths as required. For example, the overlay path between SFFs may utilize traffic engineering, QoS marking, or ECMP, without requiring complex configuration and network protocol support to be extended to the service path explicitly. In other words, the network operates as expected, and evolves as required, as does the service plane.
网络运营商保留根据需要设计网络路径的能力。例如，sff之间的覆盖路径可以利用流量工程、QoS标记或ECMP，而不需要显式地将复杂的配置和网络协议支持扩展到服务路径。换言之，网络按预期运行，并按要求演进，服务平面也是如此。
The SPI and SI serve an important function for visibility into the service topology. An operator can determine what service path a packet is "on" and its location within that path simply by viewing NSH information (packet capture, IP Flow Information Export (IPFIX), etc.). The information can be used for service scheduling and placement decisions, troubleshooting, and compliance verification.
SPI和SI在查看服务拓扑方面起着重要作用。操作员只需查看NSH信息（数据包捕获、IP流信息导出（IPFIX）等），即可确定数据包“在”的服务路径及其在该路径中的位置。这些信息可用于服务计划和放置决策、故障排除和合规性验证。
While a given realized SFP is a specific sequence of Service Functions, the service, as seen by a user, can actually be a collection of SFPs, with the interconnection provided by Classifiers (in-service path, non-initial re-classification). These internal re-Classifiers examine the packet at relevant points in the network, and, if needed, SPI and SI are updated (whether this update is a re-write, or the imposition of a new NSH with new values is implementation specific) to reflect the "result" of the classification. These Classifiers may, of course, also modify the metadata associated with the packet. Section 2.1 of [RFC7665] describes Service Graphs in detail.
虽然给定的已实现SFP是服务功能的特定序列，但用户看到的服务实际上可以是SFP的集合，其互连由分类器提供（服务内路径、非初始重新分类）。这些内部重新分类器检查网络中相关点处的数据包，如果需要，更新SPI和SI（无论此更新是重新写入，还是使用新值强制实施新NSH是特定于实现的），以反映分类的“结果”。当然，这些分类器还可以修改与分组相关联的元数据。[RFC7665]第2.1节详细描述了服务图。
As described in Section 2, NSH provides the ability to carry metadata along a service path. This metadata may be derived from several sources. Common examples include:
如第2节所述，NSH提供了沿着服务路径携带元数据的能力。此元数据可能来自多个来源。常见的例子包括：
Network nodes/devices: Information provided by network nodes can indicate network-centric information (such as VPN Routing and Forwarding (VRF) or tenant) that may be used by Service Functions or conveyed to another network node post service path egress.
网络节点/设备：网络节点提供的信息可以表示以网络为中心的信息（如VPN路由和转发（VRF）或租户），这些信息可由服务功能使用或在服务路径出口后传输到另一个网络节点。
External (to the network) systems: External systems, such as orchestration systems, often contain information that is valuable for Service Function policy decisions. In most cases, this information cannot be deduced by network nodes. For example, a cloud orchestration platform placing workloads "knows" what application is being instantiated and can communicate this information to all NSH nodes via metadata carried in the Context Header(s).
外部（网络）系统：外部系统，如编排系统，通常包含对服务功能策略决策有价值的信息。在大多数情况下，网络节点无法推断这些信息。例如，放置工作负载的云编排平台“知道”正在实例化的应用程序，并可以通过上下文标头中携带的元数据将此信息传达给所有NSH节点。
Service Functions: A Classifier co-resident with Service Functions often performs very detailed and valuable classification.
服务功能：与服务功能共存的分类器通常执行非常详细和有价值的分类。
Regardless of the source, metadata reflects the "result" of classification. The granularity of classification may vary. For example, a network switch, acting as a Classifier, might only be able to classify based on a 2-tuple, or based on a 5-tuple, while a Service Function may be able to inspect application information. Regardless of granularity, the classification information can be represented in the NSH.
不管来源如何，元数据都反映了分类的“结果”。分类的粒度可能会有所不同。例如，充当分类器的网络交换机可能只能基于2元组或5元组进行分类，而服务功能可能能够检查应用程序信息。无论粒度如何，分类信息都可以在NSH中表示。
Once the data is added to the NSH, it is carried along the service path. NSH-aware SFs receive the metadata, and can use that metadata for local decisions and policy enforcement. Figures 9 and 10 highlight the relationship between metadata and policy.
将数据添加到NSH后，数据将沿着服务路径传输。NSH感知SF接收元数据，并可将该元数据用于本地决策和策略实施。图9和图10突出显示了元数据和策略之间的关系。
+-------+ +-------+ +-------+
| SFF )------->( SFF |------->| SFF |
+---+---+ +---+---+ +---+---+
^ | |
,-|-. ,-|-. ,-|-.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ ify / \ / \ /
`---' `---' `---'
5-tuple: Permit Inspect
Tenant A Tenant A AppY
AppY
+-------+ +-------+ +-------+
| SFF )------->( SFF |------->| SFF |
+---+---+ +---+---+ +---+---+
^ | |
,-|-. ,-|-. ,-|-.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ ify / \ / \ /
`---' `---' `---'
5-tuple: Permit Inspect
Tenant A Tenant A AppY
AppY
Figure 9: Metadata and Policy
图9：元数据和策略
+-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+
^ | |
,-+-. ,-+-. ,-+-.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ ify / \ / \ /
`-+-' `---' `---'
| Permit Deny AppZ
+---+---+ employees
| |
+-------+
External
system:
Employee
AppZ
+-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+
^ | |
,-+-. ,-+-. ,-+-.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ ify / \ / \ /
`-+-' `---' `---'
| Permit Deny AppZ
+---+---+ employees
| |
+-------+
External
system:
Employee
AppZ
Figure 10: External Metadata and Policy
图10：外部元数据和策略
In both of the examples above, the Service Functions perform policy decisions based on the result of the initial classification: the SFs did not need to perform re-classification; instead, they rely on an antecedent classification for local policy enforcement.
在上述两个示例中，服务功能根据初始分类的结果执行策略决策：SFs不需要执行重新分类；相反，它们依赖于本地政策执行的先行分类。
Depending on the information carried in the metadata, data privacy impact needs to be considered. For example, if the metadata conveys tenant information, that information may need to be authenticated
根据元数据中包含的信息，需要考虑数据隐私影响。例如，如果元数据传递租户信息，则可能需要对该信息进行身份验证
and/or encrypted between the originator and the intended recipients (which may include intended SFs only); one approach to an optional capability to do this is explored in [NSH-ENCRYPT]. The NSH itself does not provide privacy functions, rather it relies on the transport encapsulation/overlay. An operator can select the appropriate set of transport encapsulation protocols to ensure confidentiality (and other security) considerations are met. Metadata privacy and security considerations are a matter for the documents that define metadata format.
和/或在发起人和预期接收人之间加密（可能仅包括预期SF）；[NSH-ENCRYPT]中探讨了实现此功能的可选功能的一种方法。NSH本身不提供隐私功能，而是依赖于传输封装/覆盖。操作员可以选择一组适当的传输封装协议，以确保满足机密性（和其他安全性）考虑。元数据隐私和安全注意事项是定义元数据格式的文档的问题。
Post-initial metadata imposition (typically, performed during initial service path determination), the metadata may be augmented or updated:
在初始元数据施加之后（通常，在初始服务路径确定期间执行），元数据可以被扩充或更新：
1. Metadata Augmentation: Information may be added to the NSH's existing metadata, as depicted in Figure 11. For example, if the initial classification returns the tenant information, a secondary classification (perhaps co-resident with deep packet inspection (DPI) or server load balancing (SLB)) may augment the tenant classification with application information, and impose that new information in NSH metadata. The tenant classification is still valid and present, but additional information has been added to it.
1. 元数据扩充：可以将信息添加到NSH的现有元数据中，如图11所示。例如，如果初始分类返回承租人信息，则二级分类（可能与深度分组检查（DPI）或服务器负载平衡（SLB）共同驻留）可以使用应用程序信息扩充承租人分类，并将该新信息强加在NSH元数据中。租户分类仍然有效且存在，但已添加其他信息。
2. Metadata Update: Subsequent Classifiers may update the initial classification if it is determined to be incorrect or not descriptive enough. For example, the initial Classifier adds metadata that describes the traffic as "Internet", but a security Service Function determines that the traffic is really "attack". Figure 12 illustrates an example of updating metadata.
2. 元数据更新：如果确定初始分类不正确或描述不够，后续分类器可能会更新初始分类。例如，初始分类器添加将流量描述为“Internet”的元数据，但安全服务功能确定流量确实是“攻击”。图12展示了更新元数据的示例。
+-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+
^ | |
,---. ,---. ,---.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ / \ / \ /
`-+-' `---' `---'
| Inspect Deny
+---+---+ employees employee+
| | Class=AppZ appZ
+-------+
External
system:
Employee
+-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+
^ | |
,---. ,---. ,---.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ / \ / \ /
`-+-' `---' `---'
| Inspect Deny
+---+---+ employees employee+
| | Class=AppZ appZ
+-------+
External
system:
Employee
Figure 11: Metadata Augmentation
图11：元数据扩充
+-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+
^ | |
,---. ,---. ,---.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ / \ / \ /
`---' `---' `---'
5-tuple: Inspect Deny
Tenant A Tenant A attack
--> attack
+-----+ +-----+ +-----+
| SFF |---------> | SFF |----------> | SFF |
+--+--+ +--+--+ +--+--+
^ | |
,---. ,---. ,---.
/ \ / \ / \
( Class ) ( SF1 ) ( SF2 )
\ / \ / \ /
`---' `---' `---'
5-tuple: Inspect Deny
Tenant A Tenant A attack
--> attack
Figure 12: Metadata Update
图12：元数据更新
Metadata information may influence the service path selection since the Service Path Identifier values can represent the result of classification. A given SPI can be defined based on classification results (including metadata classification). The imposition of the SPI and SI results in the packet being placed on the newly specified SFP at the position indicated by the imposed SPI and SI.
元数据信息可能会影响服务路径选择，因为服务路径标识符值可以表示分类的结果。可以根据分类结果（包括元数据分类）定义给定的SPI。SPI和SI的施加导致分组被放置在新指定的SFP上由施加的SPI和SI指示的位置。
This relationship provides the ability to create a dynamic service plane based on complex classification, without requiring each node to be capable of such classification or requiring a coupling to the network topology. This yields Service Graph functionality as
这种关系提供了基于复杂分类创建动态服务平面的能力，而不需要每个节点都能够进行此类分类，也不需要与网络拓扑进行耦合。这将产生如下服务图功能：
described in Section 6.4. Figure 13 illustrates an example of this behavior.
如第6.4节所述。图13展示了这种行为的一个例子。
+-----+ +-----+ +-----+
| SFF |---------> | SFF |------+---> | SFF |
+--+--+ +--+--+ | +--+--+
| | | |
,---. ,---. | ,---.
/ \ / SF1 \ | / \
( SCL ) ( + ) | ( SF2 )
\ / \SCL2 / | \ /
`---' `---' +-----+ `---'
5-tuple: Inspect | SFF | Original
Tenant A Tenant A +--+--+ next SF
--> DoS |
V
,-+-.
/ \
( SF10 )
\ /
`---'
DoS
"Scrubber"
+-----+ +-----+ +-----+
| SFF |---------> | SFF |------+---> | SFF |
+--+--+ +--+--+ | +--+--+
| | | |
,---. ,---. | ,---.
/ \ / SF1 \ | / \
( SCL ) ( + ) | ( SF2 )
\ / \SCL2 / | \ /
`---' `---' +-----+ `---'
5-tuple: Inspect | SFF | Original
Tenant A Tenant A +--+--+ next SF
--> DoS |
V
,-+-.
/ \
( SF10 )
\ /
`---'
DoS
"Scrubber"
Legend: SCL = Service Classifier
图例：SCL=服务分类器
Figure 13: Path ID and Metadata
图13：路径ID和元数据
Specific algorithms for mapping metadata to an SPI are outside the scope of this document.
将元数据映射到SPI的特定算法不在本文档的范围内。
NSH security must be considered in the contexts of the SFC architecture and operators' environments. One important characteristic of NSH is that it is not an end-to-end protocol. As opposed to a protocol that "starts" on a host and "ends" on a server or another host, NSH is typically imposed by a network device on ingress to the SFC domain and removed at the egress of the SFC domain. As such, and as with any other network-centric protocols (e.g., IP Tunneling, Traffic Engineering, MPLS, or Provider-Provisioned Virtual Private Networks), there is an underlying trust in the network devices responsible for imposing, removing, and acting on NSH information.
NSH安全必须在SFC架构和运营商环境的背景下考虑。NSH的一个重要特征是它不是端到端协议。与在主机上“启动”而在服务器或另一主机上“结束”的协议相反，NSH通常由网络设备在进入SFC域时强制实施，并在SFC域的出口处移除。因此，与任何其他以网络为中心的协议（例如，IP隧道、流量工程、MPLS或提供商提供的虚拟专用网络）一样，在负责施加、删除和处理NSH信息的网络设备中存在基础信任。
The following sections detail an analysis and present a set of requirements and recommendations in those two areas.
以下各节详细介绍了这两个方面的分析，并提出了一组要求和建议。
Trusted Devices
可信设备
All Classifiers, SFFs and SFs (hereinafter referred to as "SFC devices") within an operator's environment are assumed to have been selected, vetted, and actively maintained; therefore, they are trusted by that operator. This assumption differs from the oft held view that devices are untrusted, often referred to as the "zero-trust model". Operators SHOULD regularly monitor (i.e., continuously audit) these devices to help ensure compliant behavior. This trust, therefore, extends into NSH operations: SFC devices are not, themselves, considered to be attack vectors. This assumption, and the resultant conclusion is reasonable since this is the very basis of an operator posture; the operator depends on this reality to function. If these devices are not trusted, and indeed are compromised, almost the entirety of the operator's standard-based IP and MPLS protocol suites are vulnerable; therefore, the operation of the entire network is compromised. Although there are well-documented monitoring-based methods for detecting compromise (such as included continuous monitoring and audit and log review), these may not be sufficient to contain damage by a completely compromised element.
假设运营商环境中的所有分类器、SFF和SFs（以下简称“SFC设备”）已被选择、审查和积极维护；因此，该操作员信任它们。这一假设不同于经常持有的设备不受信任的观点，通常被称为“零信任模型”。运营商应定期监控（即持续审计）这些设备，以帮助确保合规行为。因此，这种信任延伸到NSH操作：SFC设备本身并不被视为攻击载体。这一假设以及由此得出的结论是合理的，因为这是操作员姿势的基础；操作员依赖于这个现实来运行。如果这些设备不受信任，并且确实受到危害，则运营商几乎所有基于标准的IP和MPLS协议套件都易受攻击；因此，整个网络的运行受到影响。尽管有记录良好的基于监控的方法来检测危害（例如包括持续监控、审计和日志审查），但这些方法可能不足以遏制完全危害元素造成的损害。
Methods and best practices to secure devices are also widely documented and outside the scope of this document.
保护设备的方法和最佳实践也有广泛的文档记录，不在本文档的范围内。
Single Domain Boundary
单畴边界
As per [RFC7665], NSH is designed for use within a single administrative domain. This scoping provides two important characteristics:
根据[RFC7665]，NSH设计用于单个管理域。此范围界定提供了两个重要特征：
i) Clear NSH boundaries
i) 清除NSH边界
NSH egress devices MUST strip the NSH headers before they send the users' packets or frames out of the NSH domain.
NSH出口设备必须在将用户的数据包或帧发送出NSH域之前剥离NSH报头。
Means to prevent leaking privacy-related information outside an administrative domain are natively supported by the NSH given that the last SFF of a service path will systematically remove the NSH encapsulation before forwarding a packet exiting the service path.
考虑到服务路径的最后一个SFF将在转发离开服务路径的包之前系统地移除NSH封装，因此NSH本机支持防止在管理域之外泄漏隐私相关信息的方法。
The second step in such prevention is to filter the transport encapsulation protocol used by NSH at the domain edge. The transport encapsulation protocol MUST be filtered and MUST NOT leave the domain edge.
这种预防的第二步是过滤NSH在域边缘使用的传输封装协议。传输封装协议必须经过筛选，并且不得离开域边缘。
Depending upon the transport encapsulation protocol used for NSH, this can be done either by completely blocking the transport encapsulation (e.g., if MPLS is the chosen NSH transport encapsulation protocol, it is therefore never allowed to leave the domain) or by examining the carried protocol with the transport encapsulation (e.g., if VXLAN-gpe is used as the NSH transport encapsulation protocol, all domain edges need to filter based on the carried protocol in the VXLAN-gpe.)
根据NSH使用的传输封装协议，这可以通过完全阻止传输封装（例如，如果MPLS是所选的NSH传输封装协议，则永远不允许其离开域）或通过使用传输封装检查所携带的协议来实现（例如，如果VXLAN gpe用作NSH传输封装协议，则所有域边缘都需要根据VXLAN gpe中的承载协议进行过滤。）
The other consequence of this bounding is that ingress packets MUST also be filtered to prevent attackers from sending in NSH packets with service path identification and metadata of their own selection. The same filters as described above for both the NSH at SFC devices and for the transport encapsulation protocol as general edge protections MUST be applied on ingress.
这种边界的另一个后果是，还必须过滤入口数据包，以防止攻击者发送带有服务路径标识和自己选择的元数据的NSH数据包。对于SFC设备上的NSH和传输封装协议，如上所述的相同过滤器作为一般边缘保护必须应用于入口。
In summary, packets originating outside the SFC-enabled domain MUST be dropped if they contain an NSH. Similarly, packets exiting the SFC-enabled domain MUST be dropped if they contain an NSH.
总之，如果数据包包含NSH，则必须丢弃源自支持SFC的域之外的数据包。类似地，如果数据包包含NSH，则必须丢弃退出支持SFC的域的数据包。
ii) Mitigation of external threats
ii）缓解外部威胁
As per the trusted SFC device points raised above, given that NSH is scoped within an operator's domain, that operator can ensure that the environment and its transitive properties comply with that operator's required security posture. Continuous audits for assurance are recommended with this reliance on a fully trusted environment. The term "continuous audits" describes a method (automated or manual) of checking security-control compliance on a regular basis, at some set period of time.
根据上文提到的受信任SFC设备要点，鉴于NSH的范围在运营商的域内，运营商可以确保环境及其可传递属性符合该运营商所需的安全态势。建议在完全信任的环境中进行持续的保证审核。术语“持续审计”描述了一种在一定时间段内定期检查安全控制合规性的方法（自动或手动）。
The SFC architecture defines functional roles (e.g., SFF), as well as protocol elements (e.g., Metadata). This section considers each role and element in the context of threats posed in the areas of integrity and confidentiality. As with routing, the distributed computation model assumes a distributed trust model.
SFC体系结构定义了功能角色（如SFF）以及协议元素（如元数据）。本节在诚信和保密领域所构成威胁的背景下考虑每个角色和要素。与路由一样，分布式计算模型采用分布式信任模型。
An important consideration is that NSH contains mandatory-to-mute fields, and further, the SFC architecture describes cases where other fields in NSH change, all on a possible SFP hop-by-hop basis. This means that any cryptographic solution requires complex key distribution and life-cycle operations.
一个重要的考虑因素是，NSH包含强制静音字段，此外，SFC体系结构描述了NSH中其他字段发生更改的情况，所有这些都是在可能的SFP逐跳基础上进行的。这意味着任何加密解决方案都需要复杂的密钥分发和生命周期操作。
SFC devices
SFC设备
SFC devices MAY perform various forms of verification on received NSH packets such as only accepting NSH packets from expected devices, checking that NSH SPI and SI values received from expected devices conform to expected values and so on. Implementation of these additional checks are a local matter and, thus, out of scope of this document.
SFC设备可以对接收到的NSH分组执行各种形式的验证，例如仅接受来自预期设备的NSH分组，检查从预期设备接收到的NSH SPI和SI值是否符合预期值等等。这些附加检查的实施是一个局部问题，因此超出了本文件的范围。
NSH Base and Service Path Headers
NSH基本和服务路径头
Attackers who can modify packets within the operator's network may be able to modify the SFP, path position, and/or the metadata associated with a packet.
能够在运营商网络内修改数据包的攻击者可能能够修改SFP、路径位置和/或与数据包相关的元数据。
One specific concern is an attack in which a malicious modification of the SPI/SI results in an alteration of the path to avoid security devices. The options discussed in this section help thwart that attack, and so does the use of the optional "Proof of Transit" method [PROOF-OF-TRANSIT].
一个特别关注的问题是一种攻击，其中恶意修改SPI/SI会导致路径改变，从而避开安全设备。本节讨论的选项有助于阻止该攻击，使用可选的“运输证明”方法[运输证明]也有助于阻止该攻击。
As stated above, SFC devices are trusted; in the case where an SFC device is compromised, NSH integrity protection would be subject to forging (in many cases) as well.
如上所述，SFC设备是可信的；在SFC设备受损的情况下，NSH完整性保护也会受到伪造（在许多情况下）的影响。
NSH itself does not mandate protocol-specific integrity protection. However, if an operator deems protection is required, several options are viable:
NSH本身并不强制要求协议特定的完整性保护。但是，如果操作员认为需要保护，则有几种选择是可行的：
1. SFF/SF NSH verification
1. SFF/SF NSH验证
Although, strictly speaking, not integrity protection, some of the techniques mentioned above, such as checking expected NSH values are received from expected SFC device(s), can provide a form of verification without incurring the burden of a full-fledged integrity-protection deployment.
虽然严格来说不是完整性保护，但是上面提到的一些技术，例如检查预期的NSH值是从预期的SFC设备接收的，可以提供一种形式的验证，而不会产生全面的完整性保护部署的负担。
2. Transport Security
2. 运输安全
NSH is always encapsulated by an outer transport encapsulation as detailed in Section 4 of this specification, and as depicted in Figure 1. If an operator deems cryptographic integrity protection necessary due to their risk analysis, then an outer transport encapsulation that provides such protection [RFC6071], such as IPsec, MUST be used.
NSH始终由外部传输封装封装，如本规范第4节所述，如图1所示。如果运营商因其风险分析认为需要加密完整性保护，则必须使用提供此类保护的外部传输封装[RFC6071]，如IPsec。
Although the threat model and recommendations of Section 5 of BCP 72 [RFC3552] would normally require cryptographic data origin authentication for the header, this document does not mandate such mechanisms in order to reflect the operational and technical realities of deployment.
尽管BCP 72[RFC3552]第5节的威胁模型和建议通常要求对报头进行加密数据源身份验证，但本文件并未强制要求此类机制以反映部署的操作和技术现实。
Given that NSH is transport independent, as mentioned above, a secure transport, such as IPsec can be used for carry NSH. IPsec can be used either alone or in conjunction with other transport encapsulation protocols, in turn, encapsulating NSH.
鉴于NSH是独立于传输的，如上所述，安全传输（如IPsec）可用于传输NSH。IPsec可以单独使用，也可以与其他传输封装协议结合使用，从而封装NSH。
Operators MUST ensure the selected transport encapsulation protocol can be supported by the transport encapsulation/ underlay of all relevant network segments as well as SFFs, SFs, and SFC Proxies in the service path.
运营商必须确保所选的传输封装协议能够得到所有相关网段以及服务路径中SFF、SFs和SFC代理的传输封装/参考底图的支持。
If connectivity between SFC-enabled devices traverses the public Internet, then such connectivity MUST be secured at the transport encapsulation layer. IPsec is an example of such a transport.
如果支持SFC的设备之间的连接穿越公共互联网，则必须在传输封装层保护此类连接。IPsec就是这种传输的一个例子。
3. NSH Variable Header-Based Integrity
3. 基于NSH可变报头的完整性
Lastly, NSH MD Type 2 provides, via variable-length headers, the ability to append cryptographic integrity protection to the NSH packet. The implementation of such a scheme is outside the scope of this document.
最后，NSH MD Type 2通过可变长度报头提供向NSH数据包附加加密完整性保护的能力。该计划的实施不在本文件范围内。
NSH metadata
NSH元数据
As with the Base and Service Path Headers, if an operator deems cryptographic integrity protection needed, then an existing, standard transport protocol MUST be used since the integrity protection applies to entire encapsulated NSH packets. As mentioned above, a risk assessment that deems data-plane traffic subject to tampering will apply not only to NSH but to the transport information; therefore, the use of a secure transport is likely needed already to protect the entire stack.
与基本和服务路径头一样，如果操作员认为需要加密完整性保护，则必须使用现有的标准传输协议，因为完整性保护适用于整个封装的NSH数据包。如上所述，认为数据飞机流量受到篡改的风险评估不仅适用于NSH，也适用于运输信息；因此，可能已经需要使用安全传输来保护整个堆栈。
If an MD Type 2 variable header integrity scheme is in place, then the integrity of the metadata can be ensured via that mechanism as well.
如果有MD Type 2变量头完整性方案，那么也可以通过该机制确保元数据的完整性。
SFC devices
SFC设备
SFC devices can "see" (and need to use) NSH information.
SFC设备可以“查看”（并需要使用）NSH信息。
NSH Base and Service Path Headers
NSH基本和服务路径头
SPI and other base / service path information does not typically require confidentiality; however, if an operator does deem confidentiality to be required, then, as with integrity, an existing transport encapsulation that provides encryption MUST be utilized.
SPI和其他基本/服务路径信息通常不需要保密；但是，如果运营商确实认为需要保密，那么与完整性一样，必须使用提供加密的现有传输封装。
NSH metadata
NSH元数据
An attacker with access to the traffic in an operator's network can potentially observe the metadata NSH carries with packets, potentially discovering privacy-sensitive information.
访问运营商网络流量的攻击者可能会观察NSH随数据包携带的元数据，从而发现隐私敏感信息。
Much of the metadata carried by NSH is not sensitive. It often reflects information that can be derived from the underlying packet or frame. Direct protection of such information is not necessary, as the risks are simply those of carrying the underlying packet or frame.
NSH携带的大部分元数据不敏感。它通常反映可以从底层数据包或帧派生的信息。直接保护这些信息是没有必要的，因为风险仅仅是携带底层数据包或帧的风险。
Implementers and operators MUST be aware that metadata can have privacy implications, and those implications are sometimes hard to predict. Therefore, attached metadata should be limited to that necessary for correct operation of the SFP. Further, [RFC8165] defines metadata considerations that operators can take into account when using NSH.
实施者和运营商必须意识到元数据可能具有隐私影响，而这些影响有时很难预测。因此，附加的元数据应限于SFP正确运行所需的元数据。此外，[RFC8165]定义了操作员在使用NSH时可以考虑的元数据注意事项。
Protecting NSH metadata information between SFC components can be done using transport encapsulation protocols with suitable security capabilities, along the lines discussed above. If a security analysis deems these protections necessary, then security features in the transport encapsulation protocol (such as IPsec) MUST be used.
保护SFC组件之间的NSH元数据信息可以使用具有适当安全功能的传输封装协议来完成，如上所述。如果安全分析认为这些保护是必要的，则必须使用传输封装协议（如IPsec）中的安全功能。
One useful element of providing privacy protection for sensitive metadata is described under the "SFC Encapsulation" area of the Security Considerations of [RFC7665]. Operators can and should use indirect identification for metadata deemed to be sensitive (such as personally identifying information), significantly mitigating the risk of a privacy violation. In particular, subscriber-identifying information should be handled carefully, and, in general, SHOULD be obfuscated.
[RFC7665]安全注意事项的“SFC封装”区域中描述了为敏感元数据提供隐私保护的一个有用元素。运营商可以而且应该对被视为敏感的元数据（如个人识别信息）使用间接标识，从而显著降低侵犯隐私的风险。特别是，应仔细处理订户识别信息，并且通常应混淆。
For those situations where obfuscation is either inapplicable or judged to be insufficient, an operator can also encrypt the metadata. An approach to an optional capability to do this was explored in [NSH-ENCRYPT]. For other situations where greater assurance is desired, optional mechanisms such as [PROOF-OF-TRANSIT] can be used.
对于模糊处理不适用或被判断为不充分的情况，操作员还可以加密元数据。[NSH-ENCRYPT]中探讨了实现此功能的可选功能的方法。对于需要更大保证的其他情况，可以使用可选机制，如[运输证明]。
IANA has created a new "Network Service Header (NSH) Parameters" registry. The following subsections detail new registries within the "Network Service Header (NSH) Parameters" registry.
IANA创建了一个新的“网络服务头（NSH）参数”注册表。以下小节详细介绍了“网络服务头（NSH）参数”注册表中的新注册表。
There are five unassigned bits (U bits) in the NSH Base Header, and one assigned bit (O bit). New bits are assigned via Standards Action [RFC8126].
NSH基本报头中有五个未分配位（U位）和一个分配位（O位）。通过标准操作[RFC8126]分配新位。
Bit 2 - O (OAM) bit Bit 3 - Unassigned Bits 16-19 - Unassigned
位2-O（OAM）位3-未分配位16-19-未分配
IANA has set up the "NSH Version" registry. New values are assigned via Standards Action [RFC8126].
IANA已经建立了“NSH版本”注册表。通过标准行动[RFC8126]分配新值。
+-------------+---------------------------------+-----------+
| Version | Description | Reference |
+-------------+---------------------------------+-----------+
| Version 00b | Protocol as defined by RFC 8300 | RFC 8300 |
| Version 01b | Reserved | RFC 8300 |
| Version 10b | Unassigned | |
| Version 11b | Unassigned | |
+-------------+---------------------------------+-----------+
+-------------+---------------------------------+-----------+
| Version | Description | Reference |
+-------------+---------------------------------+-----------+
| Version 00b | Protocol as defined by RFC 8300 | RFC 8300 |
| Version 01b | Reserved | RFC 8300 |
| Version 10b | Unassigned | |
| Version 11b | Unassigned | |
+-------------+---------------------------------+-----------+
Table 5: NSH Version
表5:NSH版本
IANA has set up the "NSH MD Types" registry, which contains 4-bit values. MD Type values 0x0, 0x1, 0x2, and 0xF are specified in this document; see Table 6. Registry entries are assigned via the "IETF Review" policy defined in RFC 8126 [RFC8126].
IANA已经建立了“NSH MD类型”注册表，其中包含4位值。本文件中规定了MD类型值0x0、0x1、0x2和0xF；见表6。注册表项通过RFC 8126[RFC8126]中定义的“IETF审查”策略分配。
+-----------+-----------------+-----------+
| MD Type | Description | Reference |
+-----------+-----------------+-----------+
| 0x0 | Reserved | RFC 8300 |
| | | |
| 0x1 | NSH MD Type 1 | RFC 8300 |
| | | |
| 0x2 | NSH MD Type 2 | RFC 8300 |
| | | |
| 0x3 - 0xE | Unassigned | |
| | | |
| 0xF | Experimentation | RFC 8300 |
+-----------+-----------------+-----------+
+-----------+-----------------+-----------+
| MD Type | Description | Reference |
+-----------+-----------------+-----------+
| 0x0 | Reserved | RFC 8300 |
| | | |
| 0x1 | NSH MD Type 1 | RFC 8300 |
| | | |
| 0x2 | NSH MD Type 2 | RFC 8300 |
| | | |
| 0x3 - 0xE | Unassigned | |
| | | |
| 0xF | Experimentation | RFC 8300 |
+-----------+-----------------+-----------+
Table 6: MD Type Values
表6:MD类型值
IANA has set up the "NSH MD Class" registry, which contains 16-bit values. New allocations are to be made according to the following policies:
IANA已经建立了“NSH MD类”注册表，其中包含16位值。根据以下政策进行新的分配：
0x0000 to 0x01ff: IETF Review 0x0200 to 0xfff5: Expert Review
0x0000至0x01ff：IETF评审0x0200至0xfff5：专家评审
IANA has assigned the values as follows:
IANA已分配如下值：
+------------------+------------------------+------------+
| Value | Meaning | Reference |
+------------------+------------------------+------------+
| 0x0000 | IETF Base NSH MD Class | RFC 8300 |
| | | |
| 0xfff6 to 0xfffe | Experimental | RFC 8300 |
| | | |
| 0xffff | Reserved | RFC 8300 |
+------------------+------------------------+------------+
+------------------+------------------------+------------+
| Value | Meaning | Reference |
+------------------+------------------------+------------+
| 0x0000 | IETF Base NSH MD Class | RFC 8300 |
| | | |
| 0xfff6 to 0xfffe | Experimental | RFC 8300 |
| | | |
| 0xffff | Reserved | RFC 8300 |
+------------------+------------------------+------------+
Table 7: NSH MD Class
表7:NSH MD等级
A registry for Types for the MD Class of 0x0000 is defined in Section 9.1.5.
第9.1.5节定义了0x0000 MD类的类型注册表。
Designated Experts evaluating new allocation requests from the "Expert Review" range should principally consider whether a new MD class is needed compared to adding MD Types to an existing class. The Designated Experts should also encourage the existence of an associated and publicly visible registry of MD Types although this registry need not be maintained by IANA.
指定专家从“专家评审”范围评估新的分配请求应该主要考虑是否需要一个新的MD类，相比于将MD类型添加到现有的类中。指定专家还应鼓励存在一个相关的、公开可见的MD类型登记册，尽管IANA不需要维护该登记册。
When evaluating a request for an allocation, the Expert should verify that the allocation plan includes considerations to handle privacy and security issues associated with the anticipated individual MD Types allocated within this class. These plans should consider, when appropriate, alternatives such as indirection, encryption, and limited-deployment scenarios. Information that can't be directly derived from viewing the packet contents should be examined for privacy and security implications.
在评估分配请求时，专家应验证分配计划是否包括处理与此类内分配的预期单个MD类型相关的隐私和安全问题的考虑因素。在适当的时候，这些计划应该考虑诸如间接、加密和有限的部署方案等替代方案。不能直接从查看数据包内容中获得的信息应检查隐私和安全问题。
The Type values within the IETF Base NSH MD Class, i.e., when the MD Class is set to 0x0000 (see Section 9.1.4), are the Types owned by the IETF. Per this document, IANA has created a registry for the Type values for the IETF Base NSH MD Class called the "NSH IETF-Assigned Optional Variable-Length Metadata Types" registry, as specified in Section 2.5.1.
IETF基本NSH MD类中的类型值，即当MD类设置为0x0000（见第9.1.4节）时，为IETF拥有的类型。根据本文件，IANA为IETF基本NSH MD类的类型值创建了一个注册表，称为“NSH IETF分配的可选可变长度元数据类型”注册表，如第2.5.1节所述。
The type values are assigned via Standards Action [RFC8126].
通过标准操作[RFC8126]分配类型值。
No initial values are assigned at the creation of the registry.
创建注册表时不分配初始值。
IANA has set up the "NSH Next Protocol" registry, which contains 8-bit values. Next Protocol values 0, 1, 2, 3, 4, and 5 are defined in this document (see Table 8). New values are assigned via "Expert Review" as per [RFC8126].
IANA已经建立了“NSH下一个协议”注册表，其中包含8位值。下一个协议值0、1、2、3、4和5在本文件中定义（见表8）。根据[RFC8126]，通过“专家评审”分配新值。
+---------------+--------------+-----------+
| Next Protocol | Description | Reference |
+---------------+--------------+-----------+
| 0x00 | Unassigned | |
| | | |
| 0x01 | IPv4 | RFC 8300 |
| | | |
| 0x02 | IPv6 | RFC 8300 |
| | | |
| 0x03 | Ethernet | RFC 8300 |
| | | |
| 0x04 | NSH | RFC 8300 |
| | | |
| 0x05 | MPLS | RFC 8300 |
| | | |
| 0x06 - 0xFD | Unassigned | |
| | | |
| 0xFE | Experiment 1 | RFC 8300 |
| | | |
| 0xFF | Experiment 2 | RFC 8300 |
+---------------+--------------+-----------+
+---------------+--------------+-----------+
| Next Protocol | Description | Reference |
+---------------+--------------+-----------+
| 0x00 | Unassigned | |
| | | |
| 0x01 | IPv4 | RFC 8300 |
| | | |
| 0x02 | IPv6 | RFC 8300 |
| | | |
| 0x03 | Ethernet | RFC 8300 |
| | | |
| 0x04 | NSH | RFC 8300 |
| | | |
| 0x05 | MPLS | RFC 8300 |
| | | |
| 0x06 - 0xFD | Unassigned | |
| | | |
| 0xFE | Experiment 1 | RFC 8300 |
| | | |
| 0xFF | Experiment 2 | RFC 8300 |
+---------------+--------------+-----------+
Table 8: NSH Base Header Next Protocol Values
表8:NSH基本头Next协议值
Expert Review requests MUST include a single codepoint per request. Designated Experts evaluating new allocation requests from this registry should consider the potential scarcity of codepoints for an 8-bit value, and check both for duplications and availability of documentation. If the actual assignment of the Next Protocol field allocation reaches half of the range (that is, when there are 128 unassigned values), IANA needs to alert the IESG. At that point, a new more strict allocation policy SHOULD be considered.
专家评审请求必须包括每个请求的单个代码点。指定专家从这个注册表中评估新的分配请求应该考虑8位值的代码点的潜在稀缺性，并且检查文档的重复性和可用性。如果下一个协议字段分配的实际分配达到范围的一半（即，当有128个未分配值时），IANA需要通知IESG。在这一点上，应该考虑新的更严格的分配政策。
An IEEE Ethertype, 0x894F, has been allocated for NSH.
已为NSH分配IEEE以太网类型0x894F。
[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>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[NSH-BROADBAND-ALLOCATION] Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. Boucadair, "NSH Context Header Allocation -- Broadband", Work in Progress, draft-napper-sfc-nsh-broadband-allocation-04, November 2017.
[NSH-BROADBAND-ALLOCATION]Napper，J.，Kumar，S.，Muley，P.，Henderickx，W.，和M.Boucadair，“NSH上下文标题分配——宽带”，正在进行中，草稿-Napper-sfc-NSH-BROADBAND-ALLOCATION-042017年11月。
[NSH-DC-ALLOCATION] Guichard, J., Smith, M., Kumar, S., Majee, S., Agarwal, P., Glavin, K., Laribi, Y., and T. Mizrahi, "Network Service Header (NSH) MD Type 1: Context Header Allocation (Data Center)", Work in Progress, draft-guichard-sfc-nsh-dc-allocation-07, August 2017.
[NSH-DC-ALLOCATION]Guichard，J.，Smith，M.，Kumar，S.，Majee，S.，Agarwal，P.，Glavin，K.，Laribi，Y.，和T.Mizrahi，“网络服务头（NSH）MD类型1：上下文头分配（数据中心）”，正在进行中，草稿-Guichard-sfc-NSH-DC-ALLOCATION-07，2017年8月。
[NSH-ENCRYPT] Reddy, T., Patil, P., Fluhrer, S., and P. Quinn, "Authenticated and encrypted NSH service chains", Work in Progress, draft-reddy-sfc-nsh-encrypt-00, April 2015.
[NSH-ENCRYPT]Reddy，T.，Patil，P.，Fluhrer，S.，和P.Quinn，“经验证和加密的NSH服务链”，正在进行的工作，草稿-Reddy-sfc-NSH-ENCRYPT-00，2015年4月。
[PROOF-OF-TRANSIT] Brockners, F., Bhandari, S., Dara, S., Pignataro, C., Leddy, J., Youell, S., Mozes, D., and T. Mizrahi, "Proof of Transit", Work in Progress, draft-brockners-proof-of-transit-04, October 2017.
[过境证明]布罗克内尔斯，F.，班达里，S.，达拉，S.，皮格纳塔罗，C.，莱迪，J.，尤尔，S.，莫泽斯，D.，和T.米兹拉希，“过境证明”，正在进行中的工作，草案-Brockners-PROOF-TRANSIT-042017年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 2784，DOI 10.17487/RFC27842000年3月<https://www.rfc-editor.org/info/rfc2784>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<https://www.rfc-editor.org/info/rfc3552>.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/info/rfc3692>.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，DOI 10.17487/RFC3692，2004年1月<https://www.rfc-editor.org/info/rfc3692>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>.
[RFC6071]Frankel，S.和S.Krishnan，“IP安全（IPsec）和互联网密钥交换（IKE）文档路线图”，RFC 6071，DOI 10.17487/RFC6071，2011年2月<https://www.rfc-editor.org/info/rfc6071>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 6291，DOI 10.17487/RFC6291，2011年6月<https://www.rfc-editor.org/info/rfc6291>.
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[RFC7325]Villamizar，C.，Ed.，Kompella，K.，Amante，S.，Malis，A.，和C.Pignataro，“MPLS转发合规性和性能要求”，RFC 7325，DOI 10.17487/RFC73252014年8月<https://www.rfc-editor.org/info/rfc7325>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>.
[RFC7498]Quinn，P.，Ed.和T.Nadeau，Ed.，“服务功能链接的问题陈述”，RFC 7498，DOI 10.17487/RFC7498，2015年4月<https://www.rfc-editor.org/info/rfc7498>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 10.17487/RFC7676, October 2015, <https://www.rfc-editor.org/info/rfc7676>.
[RFC7676]Pignataro，C.，Bonica，R.，和S.Krishnan，“对通用路由封装（GRE）的IPv6支持”，RFC 7676，DOI 10.17487/RFC76762015年10月<https://www.rfc-editor.org/info/rfc7676>.
[RFC8165] Hardie, T., "Design Considerations for Metadata Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, <https://www.rfc-editor.org/info/rfc8165>.
[RFC8165]Hardie，T.，“元数据插入的设计考虑”，RFC 8165，DOI 10.17487/RFC8165，2017年5月<https://www.rfc-editor.org/info/rfc8165>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201]McCann，J.，Deering，S.，Mogul，J.，和R.Hinden，编辑，“IP版本6的路径MTU发现”，STD 87，RFC 8201，DOI 10.17487/RFC8201，2017年7月<https://www.rfc-editor.org/info/rfc8201>.
[RTG-ENCAP] Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger, L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation Considerations", Work in Progress, draft-ietf-rtgwg-dt-encap-02, October 2016.
[RTG-ENCAP]Nordmark，E.，Tian，A.，Gross，J.，Hudson，J.，Kreeger，L.，Garg，P.，Thaler，P.，和T.Herbert，“封装注意事项”，在建工程，草案-ietf-rtgwg-dt-ENCAP-02，2016年10月。
[SFC-CONTROL-PLANE] Boucadair, M., "Service Function Chaining (SFC) Control Plane Components & Requirements", Work in Progress, draft-ietf-sfc-control-plane-08, October 2016.
[SFC-CONTROL-PLANE]Boucadair，M.“服务功能链（SFC）控制平面组件和要求”，正在进行的工作，草稿-ietf-SFC-CONTROL-PLANE-082016年10月。
[SFC-OAM-FRAMEWORK] 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-03, September 2017.
[SFC-OAM-FRAMEWORK]Aldrin，S.，Pignataro，C.，Kumar，N.，Akiya，N.，Krishnan，R.，和A.Ghanwani，“服务功能链（SFC）运营、管理和维护（OAM）框架”，正在进行的工作，草案-ietf-SFC-OAM-FRAMEWORK-03，2017年9月。
[VXLAN-GPE] Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Extension for VXLAN", Work in Progress, draft-ietf-nvo3-vxlan-gpe-05, October 2017.
[VXLAN-GPE]Maino，F.，Kreeger，L.，和U.Elzur，“VXLAN的通用协议扩展”，正在进行的工作，草案-ietf-nvo3-VXLAN-GPE-052017年10月。
Acknowledgments
致谢
The authors would like to thank Sunil Vallamkonda, Nagaraj Bagepalli, Abhijit Patra, Peter Bosch, Darrel Lewis, Pritesh Kothari, Tal Mizrahi, and Ken Gray for their detailed reviews, comments, and contributions.
作者感谢Sunil Vallamkonda、Nagaraj Bagepalli、Abhijit Patra、Peter Bosch、Darrel Lewis、Pritesh Kothari、Tal Mizrahi和Ken Gray的详细评论、评论和贡献。
A special thank you goes to David Ward and Tom Edsall for their guidance and feedback.
特别感谢David Ward和Tom Edsall的指导和反馈。
Additionally, the authors would like to thank Larry Kreeger for his invaluable ideas and contributions, which are reflected throughout this document.
此外，作者还要感谢Larry Kreeger的宝贵想法和贡献，这些想法和贡献反映在本文件中。
Loa Andersson provided a thorough review and valuable comments; we thank him for that.
Loa Andersson提供了全面的审查和宝贵的意见；我们为此感谢他。
Reinaldo Penno deserves a particular thank you for his architecture and implementation work that helped guide the protocol concepts and design.
Reinaldo Penno的体系结构和实现工作帮助指导了协议概念和设计，值得特别感谢。
The editors also acknowledge comprehensive reviews and respective useful suggestions by Med Boucadair, Adrian Farrel, Juergen Schoenwaelder, Acee Lindem, and Kathleen Moriarty.
编辑们还感谢Med Boucadair、Adrian Farrel、Juergen Schoenwaeld、Acee Lindem和Kathleen Moriarty的全面评论和各自的有用建议。
Lastly, David Dolson has provided significant review, feedback, and suggestions throughout the evolution of this document. His contributions are very much appreciated.
最后，David Dolson在本文档的整个发展过程中提供了重要的回顾、反馈和建议。非常感谢他的贡献。
Contributors
贡献者
This WG document originated as draft-quinn-sfc-nsh; the following are its coauthors and contributors along with their respective affiliations at the time of WG adoption. The editors of this document would like to thank and recognize them and their contributions. These coauthors and contributors provided invaluable concepts and content for this document's creation.
本工作组文件源于quinn sfc nsh草案；以下是其合著者和贡献者以及他们在工作组采用时各自的从属关系。本文件的编辑要感谢并认可他们及其贡献。这些合著者和贡献者为本文档的创建提供了宝贵的概念和内容。
o Jim Guichard, Cisco Systems, Inc. o Surendra Kumar, Cisco Systems, Inc. o Michael Smith, Cisco Systems, Inc. o Wim Henderickx, Alcatel-Lucent o Tom Nadeau, Brocade o Puneet Agarwal o Rajeev Manur, Broadcom o Abhishek Chauhan, Citrix o Joel Halpern, Ericsson o Sumandra Majee, F5 o David Melman, Marvell o Pankaj Garg, Microsoft o Brad McConnell, Rackspace o Chris Wright, Red Hat, Inc. o Kevin Glavin, Riverbed o Hong (Cathy) Zhang, Huawei US R&D o Louis Fourie, Huawei US R&D o Ron Parker, Affirmed Networks o Myo Zarny, Goldman Sachs o Andrew Dolganow, Alcatel-Lucent o Rex Fernando, Cisco Systems, Inc. o Praveen Muley, Alcatel-Lucent o Navindra Yadav, Cisco Systems, Inc.
o Jim Guichard、Cisco Systems Inc.o Surendra Kumar、Cisco Systems Inc.o Michael Smith、Cisco Systems Inc.o Wim Henderickx、Alcatel Lucent o Tom Nadeau、Brocade o Puneet Agarwal o Rajeev Manur、Broadcom o Abhishek Chauhan、Citrix o Joel Halpern、Ericsson o Sumandra Majee、F5 o David Melman、Marvell o Pankaj Garg、Microsoft o Brad McConnell、，Rackspace o Chris Wright，Red Hat，Inc.o Kevin Glavin，Riverbed o Hong（Cathy）Zhang，华为美国研发部o Louis Fourie，华为美国研发部o Ron Parker，网络部o Myo Zarny，高盛公司o Andrew Dolganow，阿尔卡特朗讯公司o Rex Fernando，思科系统公司o Praveen Muley，阿尔卡特朗讯公司o Navindra Yadav，思科系统公司。
Authors' Addresses
作者地址
Paul Quinn (editor) Cisco Systems, Inc.
保罗·奎因（编辑）思科系统公司。
Email: paulq@cisco.com
Email: paulq@cisco.com
Uri Elzur (editor) Intel
乌里·埃尔祖尔（编辑）英特尔
Email: uri.elzur@intel.com
Email: uri.elzur@intel.com
Carlos Pignataro (editor) Cisco Systems, Inc.
卡洛斯·皮格纳塔罗（编辑）思科系统公司。
Email: cpignata@cisco.com
Email: cpignata@cisco.com