Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 8372 Huawei
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco
M. Chen
Z. Li
Huawei
G. Mirsky
ZTE Corp.
May 2018
Internet Engineering Task Force (IETF) S. Bryant
Request for Comments: 8372 Huawei
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco
M. Chen
Z. Li
Huawei
G. Mirsky
ZTE Corp.
May 2018
MPLS Flow Identification Considerations
MPLS流识别注意事项
Abstract
摘要
This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.
本文档讨论在开发MPLS流识别解决方案时要考虑的方面。需要此解决方案的关键应用程序是在使用MPLS封装用户数据包时对MPLS流进行带内性能监控。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8372.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8372.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3
3. Delay Measurement Considerations . . . . . . . . . . . . . . 4
4. Units of Identification . . . . . . . . . . . . . . . . . . . 4
5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
8. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Informative References . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Loss Measurement Considerations . . . . . . . . . . . . . . . 3
3. Delay Measurement Considerations . . . . . . . . . . . . . . 4
4. Units of Identification . . . . . . . . . . . . . . . . . . . 4
5. Types of LSP . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Network Scope . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7
8. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Informative References . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
This document discusses the aspects that need to be considered when developing a solution for MPLS flow identification. The key application that needs this is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets.
本文档讨论了在开发MPLS流标识解决方案时需要考虑的方面。需要这样做的关键应用程序是在使用MPLS封装用户数据包时对MPLS流进行带内性能监控。
There is a need to identify flows in MPLS networks for various applications such as determining packet loss and packet delay measurement. A method of loss and delay measurement in MPLS networks was defined in [RFC6374]. When used to measure packet loss, [RFC6374] depends on the use of injected Operations, Administration, and Maintenance (OAM) packets to designate the beginning and the end of the packet group over which packet loss is being measured. If the misordering of packets from one group relative to the following group
对于各种应用，例如确定分组丢失和分组延迟测量，需要识别MPLS网络中的流。[RFC6374]中定义了MPLS网络中的损耗和延迟测量方法。当用于测量数据包丢失时，[RFC6374]依赖于使用注入的操作、管理和维护（OAM）数据包来指定测量数据包丢失的数据包组的开始和结束。如果一个组的数据包相对于下一个组的顺序错误
or the misordering of any of the packets being counted relative to the Loss Measurement packet [RFC6374] occurs, then an error will occur in the packet loss measurement.
或者，正被计数的任何分组相对于丢失测量分组[RFC6374]发生错误排序，则在分组丢失测量中将发生错误。
In addition, [RFC6374] did not support different granularities of flow or address a number of multipoint cases in which two or more ingress Label Switching Routers (LSRs) could send packets to one or more destinations.
此外，[RFC6374]不支持不同的流粒度或解决多点情况，其中两个或多个入口标签交换路由器（LSR）可以将数据包发送到一个或多个目的地。
Due to the very low loss rate in normal operation, improvements in link and transmission technologies have made it more difficult to assess packet loss using active performance measurement methods with synthetic traffic. That, together with more demanding service-level requirements, means that network operators now need to be able to measure the loss of the actual user data traffic using passive performance measurement methods. Any technique deployed needs to be transparent to the end user, and it needs to be assumed that they will not take any active part in the measurement process. Indeed, it is important that any flow identification technique be invisible to them and that no remnant of the measurement process leaks into their network.
由于正常运行中的丢失率非常低，链路和传输技术的改进使得使用具有合成流量的主动性能测量方法评估数据包丢失变得更加困难。再加上更高的服务级别要求，意味着网络运营商现在需要能够使用被动性能测量方法测量实际用户数据流量的损失。部署的任何技术都需要对最终用户透明，并且需要假设他们不会积极参与测量过程。事实上，重要的是，任何流量识别技术对他们来说都是不可见的，并且测量过程中没有任何残余泄漏到他们的网络中。
Additionally, when there are multiple traffic sources, such as in multipoint-to-point and multipoint-to-multipoint network environments, there needs to be a method whereby the sink can distinguish between packets from the various sources; that is to say, a multipoint measurement model needs to be developed.
此外，当存在多个业务源时，例如在多点对点和多点对多点网络环境中，需要有一种方法，使得接收器能够区分来自各种源的分组；也就是说，需要开发一个多点测量模型。
Modern networks, if not oversubscribed, generally drop relatively few packets; thus, packet loss measurement is highly sensitive to the common demarcation of the exact set of packets to be measured for loss. Without some form of coloring or batch marking such as that proposed in [RFC8321], it may not be possible to achieve the required accuracy in the loss measurement of customer data traffic. Thus, when accurate measurement of packet loss is required, it may be economically advantageous, or even be a technical requirement, to include some form of marking in the packets to assign each packet to a particular counter for loss measurement purposes.
现代网络，如果不是过度订阅，通常丢弃相对较少的数据包；因此，分组丢失测量对要测量丢失的分组的精确集合的共同界限高度敏感。如果没有[RFC8321]中提出的某种形式的着色或批标记，则可能无法达到客户数据流量损失测量所需的精度。因此，当需要准确测量分组丢失时，在分组中包括某种形式的标记以将每个分组分配给特定计数器以用于丢失测量目的，这在经济上是有利的，甚至是技术上的要求。
When this level of accuracy is required and the traffic between a source-destination pair is subject to Equal-Cost Multipath (ECMP), a demarcation mechanism is needed to group the packets into batches. Once a batch is correlated at both ingress and egress, the packet accounting mechanism is then able to operate on the batch of packets that can be accounted for at both the packet ingress and the packet
当需要这一级别的准确度并且源-目的地对之间的通信量受到等成本多路径（ECMP）的影响时，需要一种划分机制来将数据包分组。一旦在入口和出口处对一批进行关联，则分组计费机制随后能够对可在分组入口和分组处进行计费的该批分组进行操作
egress. Errors in the accounting are particularly acute in Label Switched Paths (LSPs) subjected to ECMP because the network transit time will be different for the various ECMP paths since:
出口在ECMP下的标签交换路径（LSP）中，记帐错误尤其严重，因为不同ECMP路径的网络传输时间不同，因为：
1. the packets may traverse different sets of LSRs;
1. 分组可以穿过不同的lsr集合；
2. the packets may depart from different interfaces on different line cards on LSRs; and
2. 数据包可能来自LSR上不同线路卡上的不同接口；和
3. the packets may arrive at different interfaces on different line cards on LSRs.
3. 数据包可能到达LSR上不同线路卡上的不同接口。
A consideration with this solution on modifying the identity label (the MPLS label ordinarily used to identify the LSP, Virtual Private Network, Pseudowire, etc.) to indicate the batch is the impact that this has on the path chosen by the ECMP mechanism. When the member of the ECMP path set is chosen by deep packet inspection, a change of batch represented by a change of identity label will have no impact on the ECMP path. If the path member is chosen by reference to an entropy label [RFC6790], then changing the batch identifier will not result in a change to the chosen ECMP path. ECMP is so pervasive in multipoint-to-(multi)point networks that some method of avoiding accounting errors introduced by ECMP needs to be supported.
此解决方案考虑修改标识标签（通常用于标识LSP、虚拟专用网络、伪线等的MPLS标签）以指示批次，这对ECMP机制选择的路径有影响。当通过深度数据包检查选择ECMP路径集的成员时，由标识标签更改表示的批次更改将不会对ECMP路径产生影响。如果通过引用熵标签[RFC6790]选择路径成员，则更改批标识符不会导致所选ECMP路径的更改。ECMP在多点对多点网络中非常普遍，因此需要支持一些避免ECMP引入的记帐错误的方法。
Most of the existing delay measurement methods are active methods that depend on the extra injected test packet to evaluate the delay of a path. With the active measurement method, the rate, numbers, and interval between the injected packets may affect the accuracy of the results. Due to ECMP (or link aggregation techniques), injected test packets may traverse different links from the ones used by the data traffic. Thus, measuring the delay of the real traffic is required.
现有的大多数时延测量方法都是主动的，依赖于额外注入的测试包来评估路径的时延。使用主动测量方法时，注入数据包之间的速率、数量和间隔可能会影响结果的准确性。由于ECMP（或链路聚合技术），注入的测试数据包可能会穿过与数据流量使用的不同的链路。因此，需要测量实际流量的延迟。
For combined loss and delay measurements, both the loss and the delay considerations apply.
对于综合损耗和延迟测量，损耗和延迟考虑均适用。
The most basic unit of identification is the identity of the node that processed the packet on its entry to the MPLS network. However, the required unit of identification may vary depending on the use case for accounting, performance measurement, or other types of packet observations. In particular, note that there may be a need to impose identity at several different layers of the MPLS label stack.
最基本的标识单元是在数据包进入MPLS网络时处理该数据包的节点的标识。然而，所需的标识单元可能会根据记帐、性能测量或其他类型的数据包观察的用例而有所不同。特别地，请注意，可能需要在MPLS标签栈的几个不同层上施加标识。
This document considers the identification of the following traffic components:
本文件考虑了以下交通组件的识别：
o Per source LSR: everything from one source is aggregated
o 每个源LSR：来自一个源的所有内容都是聚合的
o Per group of LSPs chosen by an ingress LSR: an ingress LSP aggregates a group of LSPs (e.g., all the LSPs of a tunnel)
o 入口LSR选择的每组LSP：入口LSP聚合一组LSP（例如，隧道的所有LSP）
o Per LSP: the basic form
o 每LSP：基本形式
o Per flow [RFC6790] within an LSP: a fine-grained method
o LSP中的每流[RFC6790]：细粒度方法
Note that a fine-grained identity resolution is needed when there is a need to perform these operations on a flow not readily identified by some other element in the label stack. Such a fine-grained resolution may be possible by deep packet inspection. However, this may not always be possible, or it may be desired to minimize processing costs by doing this only on entry to the network. Adding a suitable identifier to the packet for reference by other network elements minimizes the processing needed by other network elements. An example of such a fine-grained case might be traffic belonging to a certain service or from a specific source, particularly if matters related to service level agreement or application performance were being investigated.
请注意，当需要对标签堆栈中其他元素不容易识别的流执行这些操作时，需要细粒度标识解析。这种细粒度的解析可以通过深度包检查实现。然而，这并不总是可能的，或者可能希望通过仅在进入网络时这样做来最小化处理成本。将适当的标识符添加到分组以供其他网元参考，可最小化其他网元所需的处理。这种细粒度情况的一个示例可能是属于某个服务或来自特定源的流量，特别是在调查与服务级别协议或应用程序性能相关的问题时。
We can thus characterize the identification requirement in the following broad terms:
因此，我们可以用以下广义术语描述识别要求：
o There needs to be some way for an egress LSR to identify the ingress LSR with an appropriate degree of scope. This concept is discussed further in Section 6.
o 出口LSR需要某种方式来识别具有适当范围的入口LSR。第6节将进一步讨论这一概念。
o There needs to be a way to identify a specific LSP at the egress node. This allows for the case of instrumenting multiple LSPs operating between the same pair of nodes. In such cases, the identity of the ingress LSR is insufficient.
o 需要有一种方法来识别出口节点处的特定LSP。这允许检测在同一对节点之间运行的多个LSP。在这种情况下，入口LSR的标识不足。
o In order to conserve resources such as labels, counters, and/or compute cycles, it may be desirable to identify an LSP group so that an operation can be performed on the group as an aggregate.
o 为了节省诸如标签、计数器和/或计算周期之类的资源，可能需要识别LSP组，以便可以在该组上作为聚合执行操作。
o There needs to be a way to identify a flow within an LSP. This is necessary when investigating a specific flow that has been aggregated into an LSP.
o 需要有一种方法来识别LSP中的流。这在调查已聚合到LSP中的特定流时是必要的。
The unit of identification and the method of determining which packets constitute a flow will be specific to the application or use case and are out of scope of this document.
标识单元和确定哪些数据包构成流的方法将特定于应用程序或用例，不在本文档的范围内。
We need to consider a number of types of LSP. The two simplest types to monitor are point-to-point LSPs and point-to-multipoint LSPs. The ingress LSR for a point-to-point LSP, such as those created using the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC5420] signaling protocol or those that conform to the MPLS Transport Profile (MPLS-TP) [RFC5654], may be identified by inspection of the top label in the stack because, at any provider-edge (PE) or provider (P) router on the path, the top label is unique to the ingress-egress pair at every hop at a given layer in the LSP hierarchy. Provided that Penultimate Hop Popping (PHP) is disabled, the identity of the ingress LSR of a point-to-point LSP is available at the egress LSR; thus, determining the identity of the ingress LSR must be regarded as a solved problem. Note, however, that the identity of a flow cannot to be determined without further information being carried in the packet or gleaned from some aspect of the packet payload.
我们需要考虑多种类型的LSP。两种最简单的监控类型是点对点LSP和点对多点LSP。点到点LSP的入口LSR，例如使用资源预留协议-流量工程（RSVP-TE）[RFC5420]信令协议创建的入口LSR或符合MPLS传输配置文件（MPLS-TP）[RFC5654]的入口LSR，可以通过检查堆栈中的顶部标签来识别，因为在任何提供者边缘（PE）或提供者（P）在路径上的路由器上，在LSP层次结构中给定层的每个跃点处，顶部标签对于入口-出口对是唯一的。如果倒数第二跳弹出（PHP）被禁用，则点到点LSP的入口LSR的标识在出口LSR处可用；因此，确定入口LSR的身份必须被视为一个已解决的问题。然而，注意，如果没有在分组中携带进一步的信息或从分组有效载荷的某些方面收集进一步的信息，则不能确定流的标识。
In the case of a point-to-multipoint LSP, and in the absence of PHP, the identity of the ingress LSR may also be inferred from the top label. However, it may not possible to adequately identify the flow from the top label alone; thus, further information may need to be carried in the packet or gleaned from some aspect of the packet payload. In designing any solution, it is desirable that a common flow identification solution be used for both point-to-point and point-to-multipoint LSP types. Similarly, it is desirable that a common method of LSP group identification be used. In the above cases, a context label [RFC5331] needs to be used to provide the required identity information. This is a widely supported MPLS feature.
在点对多点LSP的情况下，并且在没有PHP的情况下，也可以从顶部标签推断入口LSR的标识。但是，仅从顶部标签可能无法充分识别流量；因此，可能需要在分组中携带进一步的信息或从分组有效载荷的某些方面收集进一步的信息。在设计任何解决方案时，最好对点对点和点对多点LSP类型使用公共流识别解决方案。类似地，希望使用LSP组识别的通用方法。在上述情况下，需要使用上下文标签[RFC5331]来提供所需的身份信息。这是广泛支持的MPLS功能。
A more interesting case is the case of a multipoint-to-point LSP. In this case, the same label is normally used by multiple ingress or upstream LSRs; hence, source identification is not possible by inspection of the top label by the egress LSRs. It is therefore necessary for a packet to be able to explicitly convey any of the identity types described in Section 4.
一个更有趣的例子是多点对点LSP。在这种情况下，同一标签通常由多个入口或上游LSR使用；因此，无法通过出口LSR检查顶部标签来识别源。因此，分组必须能够显式地传送第4节中描述的任何标识类型。
Similarly, in the case of a multipoint-to-multipoint LSP, the same label is normally used by multiple ingress or upstream LSRs; hence, source identification is not possible by inspection of the top label by egress LSRs. The various identity types described in Section 4 are again needed. Note, however, that the scope of the identity may be constrained to be unique within the set of multipoint-to-multipoint LSPs terminating on any common node.
类似地，在多点到多点LSP的情况下，多个入口或上游lsr通常使用相同的标签；因此，无法通过出口LSR检查顶部标签来识别源。同样需要第4节中描述的各种标识类型。然而，请注意，标识的范围可以被限制为在终止于任何公共节点的多点到多点lsp集合中唯一。
The scope of identification can be constrained to the set of flows that are uniquely identifiable at an ingress LSR or some aggregation thereof. There is no need for an ingress LSR to seek assistance from outside the MPLS protocol domain.
标识的范围可以限制为在入口LSR或其某些聚集处唯一可标识的流集合。入口LSR不需要从MPLS协议域之外寻求帮助。
In any solution that constrains itself to carrying the required identity in the MPLS label stack rather than in some different associated data structure, constraints on the choice of label and label stack size imply that the scope of identity resides within that MPLS domain. For similar reasons, the identity scope of a component of an LSP is constrained to the scope of that LSP.
在任何约束自身在MPLS标签堆栈中而不是在某些不同的关联数据结构中承载所需标识的解决方案中，对标签和标签堆栈大小的选择的约束意味着标识的范围位于该MPLS域中。出于类似的原因，LSP组件的标识范围被限制为该LSP的范围。
In any network, it is unlikely that all LSRs will have the same capability to support the methods of identification discussed in this document. It is therefore an important constraint on any flow identity solution that it is backwards compatible with deployed MPLS equipment to the extent that deploying the new feature will not disable anything that currently works on the legacy equipment.
在任何网络中，不可能所有LSR都具有相同的能力来支持本文件中讨论的识别方法。因此，任何流标识解决方案的一个重要限制是，它与已部署的MPLS设备向后兼容，以至于部署新功能不会禁用当前在遗留设备上工作的任何内容。
This is particularly the case when the deployment is incremental or the feature is not required for all LSRs or all LSPs. Thus, the flow identification design must support the coexistence of LSRs that can identify the traffic components described in Section 4 and those that cannot. In addition, the identification of the traffic components described in Section 4 must be an optional feature that is disabled by default. As a design simplification, a solution may require that all egress LSRs of a point-to-multipoint or a multipoint-to-multipoint LSP support the identification type in use so that a single packet can be correctly processed by all egress devices. The corollary of this last point is that either all egress LSRs are enabled to support the required identity type or none of them are.
当部署是增量的，或者并非所有LSR或所有LSP都需要该功能时，情况尤其如此。因此，流量识别设计必须支持能够识别第4节中描述的流量组件的LSR与不能识别的LSR共存。此外，第4节中描述的交通组件标识必须是默认禁用的可选功能。作为设计简化，解决方案可能要求点对多点或多点对多点LSP的所有出口lsr支持使用中的标识类型，以便单个分组可以由所有出口设备正确处理。最后一点的推论是，要么所有出口LSR都支持所需的标识类型，要么它们都不支持。
There is a huge installed base of MPLS equipment; typically, this type of equipment remains in service for an extended period of time, and in many cases, hardware constraints mean that it is not possible to upgrade its data-plane functionality. Changes to the MPLS data plane are therefore expensive to implement, add complexity to the network, and may significantly impact the deployability of a solution that requires such changes. For these reasons, MPLS users have set a very high bar to changes to the MPLS data plane, and only a very small number have been adopted. Hence, it is important that the method of identification must minimize changes to the MPLS data
MPLS设备安装量巨大；通常，此类设备在较长时间内仍在使用，在许多情况下，硬件限制意味着无法升级其数据平面功能。因此，对MPLS数据平面的更改实施起来非常昂贵，增加了网络的复杂性，并且可能会显著影响需要此类更改的解决方案的可部署性。由于这些原因，MPLS用户对MPLS数据平面的更改设置了非常高的限制，并且只采用了非常小的数量。因此，重要的是，识别方法必须尽量减少对MPLS数据的更改
plane. Ideally, method(s) of identification that require no changes to the MPLS data plane should be given preferential consideration. If a method of identification that makes a change to the data plane is chosen, it will need to have a significant advantage over any method that makes no change, and the advantage of the approach will need to be carefully evaluated and documented. If a change to the MPLS data plane proves necessary, it should be (a) as small a change as possible and (b) a general-purpose method, so as to maximize its use for future applications. It is imperative that, as far as can be foreseen, any necessary change made to the MPLS data plane does not impose any foreseeable future limitation on the MPLS data plane.
飞机理想情况下，应优先考虑不需要更改MPLS数据平面的识别方法。如果选择了对数据平面进行更改的识别方法，则该方法需要比任何不进行更改的方法具有显著优势，并且该方法的优势需要仔细评估和记录。如果MPLS数据平面的更改被证明是必要的，那么它应该是（a）一个尽可能小的更改和（b）一个通用方法，以便最大限度地将其用于未来的应用。在可以预见的范围内，对MPLS数据平面所做的任何必要更改都不能对MPLS数据平面施加任何可预见的未来限制。
Stack size is an issue with many MPLS implementations both as a result of hardware limitations and due to the impact on networks and applications in which a large number of small payloads need to be transported. In particular, one MPLS payload may be carried inside another. For example, one LSP may be carried over another LSP, or a Pseudowire (PW) or similar multiplexing construct may be carried over an LSP, and identification may be required at both layers. Of particular concern is the implementation of low-cost edge LSRs that, for cost reasons, have a significant limit on the number of Label Stack Entries (LSEs) that they can impose or dispose. Therefore, any method of identity must not consume an excessive number of unique labels and must not result in an excessive increase in the size of the label stack.
堆栈大小是许多MPLS实现的一个问题，这既是硬件限制的结果，也是由于对需要传输大量小有效负载的网络和应用程序的影响。特别地，一个MPLS有效载荷可以被携带在另一个MPLS有效载荷内部。例如，一个LSP可以承载在另一个LSP上，或者伪线（PW）或类似复用构造可以承载在LSP上，并且可能需要在两个层上进行标识。特别值得关注的是低成本边缘LSR的实现，出于成本原因，这些边缘LSR对它们可以施加或处置的标签堆栈条目（LSE）的数量有很大的限制。因此，任何标识方法都不得使用过多的唯一标签，也不得导致标签堆栈的大小过度增加。
The design of the MPLS data plane provides two types of special-purpose labels: the original 16 reserved labels and the much larger set of special-purpose labels defined in [RFC7274]. The original reserved labels need one LSE, and the newer special-purpose labels [RFC7274] need two LSEs. Given the tiny number of original reserved labels, it is core to the MPLS design philosophy that this scarce resource is only used when it is absolutely necessary. Using a special-purpose label to encode flow identity requires two label stack entries, one for the reserved label and one for the flow identity. Use of extended special-purpose labels [RFC7274] requires a total of three label stack entries to encode the flow identity. The larger set of [RFC7274] labels requires two label stack entries for the special-purpose label itself; hence, a total of three label stack entries is needed to encode the flow identity.
MPLS数据平面的设计提供了两种类型的专用标签：原始的16个保留标签和[RFC7274]中定义的更大的专用标签集。原始保留标签需要一个LSE，而较新的专用标签[RFC7274]需要两个LSE。鉴于原始保留标签的数量很少，MPLS设计理念的核心是只有在绝对必要时才使用这种稀缺资源。使用专用标签编码流标识需要两个标签堆栈条目，一个用于保留标签，一个用于流标识。使用扩展专用标签[RFC7274]需要总共三个标签堆栈条目来编码流标识。较大的[RFC7274]标签集需要两个标签堆栈条目，用于专用标签本身；因此，总共需要三个标签堆栈条目来编码流标识。
The use of special-purpose labels [RFC7274] as part of a method to encode the identity information therefore has a number of undesirable implications for the data plane. Thus, while a solution may use special-purpose labels, methods that do not require special-purpose labels need to be carefully considered.
因此，使用专用标签[RFC7274]作为身份信息编码方法的一部分对数据平面有许多不希望的影响。因此，虽然解决方案可能使用专用标签，但需要仔细考虑不需要专用标签的方法。
Any flow identity design should both seek to minimize the complexity of the control plane and minimize the amount of label coordination needed amongst LSRs.
任何流标识设计都应寻求最小化控制平面的复杂性，并最小化LSR之间需要的标签协调量。
The inclusion of originating and/or flow information in a packet provides more identity information and hence potentially degrades the privacy of the communication.
在分组中包含原始和/或流信息提供了更多的身份信息，因此潜在地降低了通信的隐私性。
Recent IETF concerns on pervasive monitoring [RFC7258] have resulted in a preference for a solution that does not degrade the privacy of user traffic below that of an MPLS network not implementing the flow identification feature. The choice of using MPLS technology for this OAM solution has a privacy advantage, as the choice of the label identifying a flow is limited to the scope of the MPLS domain and does not have any dependency on the identification of the user data. This minimizes the observability of the flow characteristics.
最近IETF对普适性监控[RFC7258]的关注导致人们倾向于采用一种解决方案，该解决方案不会将用户流量的隐私降低到低于未实现流量识别功能的MPLS网络的隐私。为该OAM解决方案选择使用MPLS技术具有隐私优势，因为标识流的标签的选择限于MPLS域的范围，并且不依赖于用户数据的标识。这使得流量特性的可观测性降至最低。
Any flow identification solution must not degrade the security of the MPLS network below that of an equivalent network not deploying the specified identity solution. In order to preserve present assumptions about MPLS privacy properties, propagation of identification information outside the MPLS network imposing it must be disabled by default. Any solution should provide for the restriction of the identity information to those components of the network that need to know it. It is thus desirable to limit the knowledge of the identify of an endpoint to only those LSRs that need to participate in traffic flow. The choice of using MPLS technology for this OAM solution, with MPLS encapsulation of user traffic, provides for a key advantage over other data-plane solutions, as it provides for a controlled access and trusted domain within a service provider's network.
任何流标识解决方案不得降低MPLS网络的安全性，使其低于未部署指定标识解决方案的等效网络的安全性。为了保留关于MPLS隐私属性的现有假设，默认情况下必须禁用在MPLS网络外部传播标识信息。任何解决方案都应将身份信息限制在需要了解身份信息的网络组件上。因此，希望将端点识别的知识限制为仅需要参与交通流的那些lsr。此OAM解决方案选择使用MPLS技术，并对用户流量进行MPLS封装，这提供了比其他数据平面解决方案更重要的优势，因为它在服务提供商的网络中提供了受控访问和可信域。
For a more comprehensive discussion of MPLS security and attack mitigation techniques, please see "Security Framework for MPLS and GMPLS Networks" [RFC5920].
有关MPLS安全和攻击缓解技术的更全面的讨论，请参阅“MPLS和GMPLS网络的安全框架”[RFC5920]。
This document has no IANA considerations.
本文件没有IANA考虑事项。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <https://www.rfc-editor.org/info/rfc5331>.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 5331，DOI 10.17487/RFC5331，2008年8月<https://www.rfc-editor.org/info/rfc5331>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <https://www.rfc-editor.org/info/rfc5420>.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，DOI 10.17487/RFC5420，2009年2月<https://www.rfc-editor.org/info/rfc5420>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC5654]Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 5654，DOI 10.17487/RFC5654，2009年9月<https://www.rfc-editor.org/info/rfc5654>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 6374，DOI 10.17487/RFC6374，2011年9月<https://www.rfc-editor.org/info/rfc6374>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790]Kompella，K.，Drake，J.，Amante，S.，Henderickx，W.，和L.Yong，“MPLS转发中熵标签的使用”，RFC 6790，DOI 10.17487/RFC6790，2012年11月<https://www.rfc-editor.org/info/rfc6790>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<https://www.rfc-editor.org/info/rfc7258>.
[RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating and Retiring Special-Purpose MPLS Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014, <https://www.rfc-editor.org/info/rfc7274>.
[RFC7274]Kompella，K.，Andersson，L.，和A.Farrel，“分配和停用特殊用途MPLS标签”，RFC 7274，DOI 10.17487/RFC7274，2014年6月<https://www.rfc-editor.org/info/rfc7274>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8321]Fioccola，G.，Ed.，Capello，A.，Cociglio，M.，Castaldelli，L.，Chen，M.，Zheng，L.，Mirsky，G.，和T.Mizrahi，“被动和混合动力性能监测的替代标记方法”，RFC 8321，DOI 10.17487/RFC8321，2018年1月<https://www.rfc-editor.org/info/rfc8321>.
Acknowledgments
致谢
The authors thank Nobo Akiya, Nagendra Kumar Nainar, George Swallow, and Deborah Brungard for their comments.
作者感谢Nobo Akiya、Nagendra Kumar Nainar、George Swallow和Deborah Brungard的评论。
Authors' Addresses
作者地址
Stewart Bryant Huawei
斯图尔特·布莱恩特·华为
Email: stewart.bryant@gmail.com
Email: stewart.bryant@gmail.com
Carlos Pignataro Cisco Systems, Inc.
卡洛斯·皮格纳塔罗思科系统公司。
Email: cpignata@cisco.com
Email: cpignata@cisco.com
Mach(Guoyi) Chen Huawei
马赫（国一）陈华为
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com
Zhenbin Li Huawei
李振斌华为
Email: lizhenbin@huawei.com
Email: lizhenbin@huawei.com
Gregory Mirsky ZTE Corp.
格雷戈里·米尔斯基中兴通讯公司。
Email: gregimirsky@gmail.com
Email: gregimirsky@gmail.com