Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7054 Juniper Networks
Category: Informational H. Endo
ISSN: 2070-1721 Hitachi, Ltd.
R. Winter
NEC
Y. Koike
NTT
M. Paul
Deutsche Telekom
November 2013
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 7054 Juniper Networks
Category: Informational H. Endo
ISSN: 2070-1721 Hitachi, Ltd.
R. Winter
NEC
Y. Koike
NTT
M. Paul
Deutsche Telekom
November 2013
Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs)
解决每个接口维护实体组中间点（MIPs）的要求和设计注意事项
Abstract
摘要
The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.
MPLS传输配置文件（MPLS-TP）中的操作、管理和维护框架（OAM）描述了维护实体组中间点（MIPs）如何位于传入和传出接口的网络节点内。
This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP.
本文档详细说明了内部MIP寻址的重要注意事项。更准确地说，它描述了任何机制的重要限制，这些机制指定了形成OAM消息的方式，以便它们可以针对传入或传出接口上的MIPs，并通过转发引擎正确转发。此外，该文档还包括节点实现的注意事项，其中传入和传出MIP之间没有区别。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7054.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7054.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Summary of the Problem Statement ................................3
4. Requirements and Design Considerations for Internal-MIP
Addressing ......................................................6
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Summary of the Problem Statement ................................3
4. Requirements and Design Considerations for Internal-MIP
Addressing ......................................................6
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................11
The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM Framework, [RFC6371]) distinguishes two configurations for the Maintenance Entity Group Intermediate Points (MIPs) on a node. It defines per-node MIPs and per-interface MIPs, where a per-node MIP is a single MIP per node in an unspecified location within the node and per-interface MIPs are two (or more) MIPs per node on each side of the forwarding engine.
MPLS传输配置文件（MPLS-TP）中的操作、管理和维护（OAM）框架（MPLS-TP OAM框架[RFC6371]）区分了节点上维护实体组中间点（MIP）的两种配置。它定义了每个节点MIP和每个接口MIP，其中每个节点MIP是节点内未指定位置的每个节点的单个MIP，每个接口MIP是转发引擎每侧每个节点的两个（或更多）MIP。
In-band OAM messages are sent using the Generic Associated Channel (G-ACh) [RFC5586]. OAM messages for the transit points of pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using the expiration of the MPLS shim header Time-to-Live (TTL) field. OAM messages for the end points of PWs and LSPs are simply delivered as normal.
带内OAM消息使用通用关联信道（G-ACh）[RFC5586]发送。用于伪线（PWs）或标签交换路径（LSP）传输点的OAM消息使用MPLS垫片报头生存时间（TTL）字段的过期时间来传递。PWs和LSP端点的OAM消息只是正常传递。
OAM messages delivered to end points or transit points are distinguished from other (data) packets so that they can be processed as OAM. In LSPs, the mechanism used is the presence of the Generic Associated Channel Label (GAL) in the Label Stack Entry (LSE) under the top LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW Associated Channel Header (PWACH) [RFC4385] or the presence of a GAL [RFC6423].
发送到端点或传输点的OAM消息与其他（数据）包不同，因此它们可以作为OAM进行处理。在LSP中，使用的机制是在顶部LSE[RFC5586]下的标签堆栈条目（LSE）中存在通用关联通道标签（GAL）。在PWs中，使用的机制是PW相关信道报头（PWACH）[RFC4385]或GAL[RFC6423]的存在。
If multiple MIPs are present on a single node, these mechanisms alone provide no way to address one particular MIP out of the set of MIPs. A mechanism that addresses this shortcoming has to obey a few important design considerations, which are discussed in this document.
如果单个节点上存在多个MIP，则仅这些机制无法解决MIP集中的一个特定MIP。解决这一缺点的机制必须遵循一些重要的设计注意事项，本文档将对此进行讨论。
In this document, we use the term in-MIP (incoming MIP) to refer to the MIP that processes OAM messages before they pass through the forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM messages after they have passed the forwarding engine of the node. The two together are referred to as internal MIPs. The term "forwarding engine" is used as defined in [RFC6371].
在本文档中，我们使用MIP（传入MIP）中的术语来指在OAM消息通过节点的转发引擎之前处理这些消息的MIP。out MIP（传出MIP）在OAM消息通过节点的转发引擎后处理这些消息。这两者一起被称为内部MIPs。术语“转发引擎”的使用如[RFC6371]中所定义。
Note that the acronym "OAM" is used in conformance with [RFC6291].
注意，首字母缩略词“OAM”的使用符合[RFC6291]。
Figure 1 shows an abstract functional representation of an MPLS-TP node. It is decomposed as an incoming interface (labeled "In"), a forwarding engine (FW), and an outgoing interface (labeled "Out"). As per the discussion in [RFC6371], MIPs may be placed in each of the functional interface components.
图1显示了MPLS-TP节点的抽象功能表示。它被分解为传入接口（标记为“In”）、转发引擎（FW）和传出接口（标记为“Out”）。根据[RFC6371]中的讨论，MIP可放置在每个功能接口组件中。
------------------------
|----- -----|
| MIP | | MIP |
| | ---- | |
----->-| In |->-| FW |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
------------------------
|----- -----|
| MIP | | MIP |
| | ---- | |
----->-| In |->-| FW |->-| Out |->----
| i/f | ---- | i/f |
|----- -----|
------------------------
Figure 1: Abstract Functional Representation of an MPLS-TP Node
图1:MPLS-TP节点的抽象功能表示
Several distinct OAM functions are required within this architectural model for both PWs and LSPs, such as:
对于PWs和LSP，此体系结构模型中需要几个不同的OAM功能，例如：
o Connectivity Verification (CV) between a Maintenance Entity Group End Point (MEP) and a MIP
o 维护实体组端点（MEP）和MIP之间的连接验证（CV）
o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs
o MPLS-TP LSP和/或包含MIPs的MPLS-TP PW上的跟踪路由
o data-plane loopback configuration at a MIP
o MIP上的数据平面环回配置
o diagnostic tests
o 诊断测试
The MIPs in these OAM functions may also be the MIPs at the incoming or outgoing interfaces.
这些OAM功能中的MIP也可以是传入或传出接口处的MIP。
Per-interface MIPs have the advantage that they enable a more accurate localization and identification of faults and diagnostic tests. In particular, the identification of whether a problem is located between nodes or on a particular node and where on that node is greatly enhanced. For obvious reasons, it is important to narrow down the cause of a fault quickly to initiate a timely and well-directed maintenance action to resume normal network operation.
每个接口MIPs的优点是，它们能够更准确地定位和识别故障和诊断测试。特别是，问题是位于节点之间还是在特定节点上以及在该节点上的位置的识别得到了极大的增强。出于显而易见的原因，快速缩小故障原因以启动及时且有针对性的维护行动以恢复正常网络运行非常重要。
The following two figures illustrate the fundamental difference between using per-node and per-interface MEPs and MIPs for OAM. Figure 2 depicts OAM using per-node MIPs and MEPs. For reasons of exposition, we pick a location for the MIPs on the nodes but the standard does not mandate the exact location for the per-node model. In the figure, a bidirectional LSP is depicted where in the forward (FWD) direction MEP1, MIP1, and MEP2 are located on the ingress interface. In the backward (BWD) direction MEP1', MIP1' and MEP2' are located on the egress interface, i.e., the same interfaces. S1 in the figure denotes the segment from PE1 In to P1 In and S2 denotes the segment from PE1 In to P2 In. Figure 3, on the other hand, shows the same basic network, but per-interface maintenance points are configured for OAM operations. Note that these figures are merely examples. It is important to note that per-interface MEPs or per-interface MIPs must logically be placed at a point before (for in-MIP) or after (for out-MIP) passing the forwarding engine as defined in [RFC6371]. All traffic associated with the MEP/MIP must pass through or be terminated at that point.
以下两个图说明了对OAM使用每个节点和每个接口MEP和MIP之间的根本区别。图2描述了使用每节点MIP和MEP的OAM。出于说明的原因，我们为节点上的MIPs选择了一个位置，但标准没有规定每个节点模型的确切位置。在图中，描绘了双向LSP，其中在前向（FWD）方向上，MEP1、MIP1和MEP2位于入口接口上。在向后（BWD）方向上，MEP1’、MIP1’和MEP2’位于出口接口上，即，相同的接口。图中S1表示从PE1 in到P1 in的段，S2表示从PE1 in到P2 in的段。另一方面，图3显示了相同的基本网络，但为OAM操作配置了每个接口的维护点。请注意，这些数字只是示例。需要注意的是，按照[RFC6371]中的定义，每个接口MEP或每个接口MIP必须逻辑地放置在通过转发引擎之前（对于in MIP）或之后（对于out MIP）。所有与MEP/MIP相关的流量必须在该点通过或终止。
Customer| Operator's Administrative | Customer
Domain | Domain | Domain
------> |<--------------------------------------->| <------
CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD PW/LSP | o-------------------------- > |
| V-------------*-------------V |
| MEP1 MIP1 MEP2 |
BWD PW/LSP | <---------------------------o |
| V-------------*-------------V |
| MEP1' MIP1' MEP2'|
(S1)<============>
(S2)<==========================>
Customer| Operator's Administrative | Customer
Domain | Domain | Domain
------> |<--------------------------------------->| <------
CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD PW/LSP | o-------------------------- > |
| V-------------*-------------V |
| MEP1 MIP1 MEP2 |
BWD PW/LSP | <---------------------------o |
| V-------------*-------------V |
| MEP1' MIP1' MEP2'|
(S1)<============>
(S2)<==========================>
Figure 2: Example of OAM Relying on Per-Node MIPs and MEPs
图2:OAM依赖于每节点MIPs和MEP的示例
To illustrate the difference between these two modes of operation, we use fault detection as an example. Consider the case where the client traffic between CE1 and CE2 experiences a fault. Also assume that an on-demand CV test between PE1 and PE2 was successful. The scenario in Figure 2 therefore leaves the forwarding engine (FW) of PE2, the out-going interface of PE2, the transmission line between PE2 and CE2, or CE2 itself as a potential location of the fault as on-demand CV can only be performed on segment S2. Note that in this scenario, the PWs or LSPs are to be understood as two examples (not one), i.e., the figures do not show the layer structure of PWs and LSPs.
为了说明这两种操作模式之间的差异，我们以故障检测为例。考虑CE1和CE2之间的客户端通信发生故障的情况。还假设PE1和PE2之间的按需CV测试成功。因此，图2中的场景将PE2的转发引擎（FW）、PE2的输出接口、PE2和CE2之间的传输线或CE2本身作为故障的潜在位置，因为按需CV只能在段S2上执行。注意，在该场景中，PWs或lsp应理解为两个示例（不是一个），即，图中未显示PWs和lsp的层结构。
The per-interface model in Figure 3 allows more fine-grained OAM operations to be performed. At first, CV on segment S'4 and in addition CV on segment S'5 can help to rule out, for example, the forwarding engine of PE2. This is of course only a single example, and other OAM functions and scenarios are trivially conceivable. The basic message is that with the per-interface OAM model, an operator can configure smaller segments on a transport path to which OAM operations apply. This enables a more fine-grained scoping of OAM operations, such as fault localization and performance monitoring, which gives operators better information to deal with adverse networking conditions.
图3中的每个接口模型允许执行更细粒度的OAM操作。首先，段S'4上的CV和段S'5上的CV有助于排除PE2的转发引擎。当然，这只是一个例子，其他OAM功能和场景都是可以想象的。基本信息是，使用每接口OAM模型，操作员可以在应用OAM操作的传输路径上配置较小的段。这可以对OAM操作进行更细粒度的范围界定，如故障定位和性能监视，从而为运营商提供更好的信息，以应对不利的网络条件。
Customer| Operator's Administrative |Customer
Domain | Domain |Domain
------->|<--------------------------------------->|<------
CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD PW/LSP | o-----------------------------------> |
| V-------*------*------*-----*-------V |
| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|
| |
BWD PW/LSP | <-----------------------------------o |
| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|
(S'1)<======>
(S'2)<=============>
(S'3)<====================>
(S'4)<==========================>
(S'5)<==================================>
Customer| Operator's Administrative |Customer
Domain | Domain |Domain
------->|<--------------------------------------->|<------
CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2
| <--------> <--------> <--------> |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
+---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+
| In FW Out In FW Out In FW Out |
| |
FWD PW/LSP | o-----------------------------------> |
| V-------*------*------*-----*-------V |
| MEP1 MIP1 MIP2 MIP3 MIP4 MEP2|
| |
BWD PW/LSP | <-----------------------------------o |
| MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'|
(S'1)<======>
(S'2)<=============>
(S'3)<====================>
(S'4)<==========================>
(S'5)<==================================>
Figure 3: Example of OAM Relying on Per-Interface MIPs and MEPs
图3:OAM依赖于每个接口MIPs和MEP的示例
OAM messages for transit points of PWs or LSPs are delivered using the expiration of the TTL field in the top LSE of the MPLS packet header. OAM messages for the end points of PWs and LSPs are simply delivered as normal. These messages are distinguished from other (data) packets so that they can be processed as OAM. In LSPs, the mechanism used is the presence of the GAL in the LSE under the top LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW Associated Channel Header [RFC4385] or the presence of a GAL [RFC6423]. In addition, two sets of identifiers exist that can be used to address MIPs, which are defined in [RFC6370] and [RFC6923]
PWs或LSP传输点的OAM消息使用MPLS数据包头顶部LSE中TTL字段的过期时间来传递。PWs和LSP端点的OAM消息只是正常传递。这些消息与其他（数据）包不同，因此它们可以作为OAM处理。在LSP中，使用的机制是在顶部LSE下方的LSE中存在GAL[RFC5586]。在PWs中，使用的机制是PW相关信道报头[RFC4385]或GAL[RFC6423]的存在。此外，存在两组可用于寻址MIPs的标识符，它们在[RFC6370]和[RFC6923]中定义
Any solution for sending OAM messages to the in- and out-MIPs must fit within these existing models of handling OAM.
任何向输入和输出MIP发送OAM消息的解决方案都必须适合这些处理OAM的现有模型。
Additionally, many MPLS-TP nodes are implemented in a way that all queuing and the forwarding function are performed at the incoming interface. The abstract functional representation of such a node is shown in Figure 4. As shown in the figure, the outgoing interfaces are minimal and for this reason it may not be possible to include
此外，许多MPLS-TP节点以一种方式实现，即所有排队和转发功能都在传入接口处执行。这种节点的抽象功能表示如图4所示。如图所示，输出接口是最小的，因此可能无法包括
MIP functions on those interfaces. This is the case for existing deployed implementations in particular.
这些接口上的MIP函数。现有部署的实现尤其如此。
Any solution that attempts to send OAM messages to the outgoing
interface of an MPLS-TP node must not cause any problems when such
implementations are present (such as leaking OAM packets with a TTL
of 0).
---------------------
|------------ |
| MIP | |
| ---- | |
----->-| In | FW | |-->-Out-|->---
| i/f ---- | i/f |
|------------ |
---------------------
Any solution that attempts to send OAM messages to the outgoing
interface of an MPLS-TP node must not cause any problems when such
implementations are present (such as leaking OAM packets with a TTL
of 0).
---------------------
|------------ |
| MIP | |
| ---- | |
----->-| In | FW | |-->-Out-|->---
| i/f ---- | i/f |
|------------ |
---------------------
Figure 4: Abstract Functional Representation of Some Existing MPLS-TP Nodes
图4：一些现有MPLS-TP节点的抽象功能表示
OAM must operate on MPLS-TP nodes that are branch points on point-to-
multipoint (P2MP) trees. This means that it must be possible to
target individual outgoing MIPs as well as all outgoing MIPs in the
abstract functional representation shown in Figure 5, and to handle
the P2MP node implementations as shown in Figure 6 without causing
problems.
--------------------------
| -----|
| | MIP |
| ->-| |->----
| | | Out |
| | | i/f |
| | -----|
|----- | -----|
| MIP | ---- | | MIP |
| | | |- | |
----->-| In |->-| FW |--->-| Out |->----
| i/f | | |- | i/f |
|----- ---- | -----|
| | -----|
| | | MIP |
| | | |
| ->-| Out |->----
| | i/f |
| -----|
--------------------------
OAM must operate on MPLS-TP nodes that are branch points on point-to-
multipoint (P2MP) trees. This means that it must be possible to
target individual outgoing MIPs as well as all outgoing MIPs in the
abstract functional representation shown in Figure 5, and to handle
the P2MP node implementations as shown in Figure 6 without causing
problems.
--------------------------
| -----|
| | MIP |
| ->-| |->----
| | | Out |
| | | i/f |
| | -----|
|----- | -----|
| MIP | ---- | | MIP |
| | | |- | |
----->-| In |->-| FW |--->-| Out |->----
| i/f | | |- | i/f |
|----- ---- | -----|
| | -----|
| | | MIP |
| | | |
| ->-| Out |->----
| | i/f |
| -----|
--------------------------
Figure 5: Abstract Functional Representation of an MPLS-TP Node Supporting P2MP
图5：支持P2MP的MPLS-TP节点的抽象功能表示
----------------------
| ->-Out-|->----
| | i/f |
|------------ | |
| | | |
| MIP ---- | | |
| | | |- |
----->-| In | FW | |--->-Out-|->----
| i/f | | |- i/f |
| ---- | | |
| | | |
|------------ | |
| | Out |
| ->-i/f-|->----
----------------------
----------------------
| ->-Out-|->----
| | i/f |
|------------ | |
| | | |
| MIP ---- | | |
| | | |- |
----->-| In | FW | |--->-Out-|->----
| i/f | | |- i/f |
| ---- | | |
| | | |
|------------ | |
| | Out |
| ->-i/f-|->----
----------------------
Figure 6: Abstract Functional Representation of Some Existing MPLS-TP Nodes Supporting P2MP
图6：支持P2MP的一些现有MPLS-TP节点的抽象功能表示
In summary, the solution for OAM message delivery must behave as follows:
总之，OAM消息传递解决方案的行为必须如下所示：
o Delivery of OAM messages to the correct MPLS-TP node.
o 将OAM消息传递到正确的MPLS-TP节点。
o Delivery of OAM instructions to the correct MIP within an MPLS-TP node.
o 将OAM指令传递到MPLS-TP节点内的正确MIP。
o Forwarding of OAM packets exactly as data packets.
o OAM数据包的转发与数据包完全相同。
o Packet inspection at the incoming and outgoing interfaces must be minimized.
o 必须尽量减少传入和传出接口处的数据包检查。
The first and second bullet points are obvious. However, the third bullet point is also vital. To illustrate the importance, a rejected solution is depicted in Figure 7. In the figure, all data and non-local OAM is handled as normal. Local OAM is intercepted at the incoming interface and delivered to the MIP at the incoming interface. If the OAM is intended for the incoming MIP, it is handled there with no issue. If the OAM is intended for the outgoing MIP, it is forwarded to that MIP using some internal messaging system that is implementation specific.
第一点和第二点是显而易见的。然而，第三点也是至关重要的。为了说明重要性，图7中描述了一个被拒绝的解决方案。在图中，所有数据和非本地OAM都按正常方式处理。本地OAM在传入接口处被截获，并在传入接口处交付给MIP。如果OAM用于传入的MIP，则在那里处理它时不会出现问题。如果OAM用于传出MIP，则使用特定于实现的内部消息传递系统将其转发给该MIP。
------------------------
|----- -----|
local OAM ----->-| MIP |----->------| MIP |
| | ---- | |
data =====>=| In |=>=| FW |=>=| Out |=>==== data
non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
|----- ---- -----|
------------------------
------------------------
|----- -----|
local OAM ----->-| MIP |----->------| MIP |
| | ---- | |
data =====>=| In |=>=| FW |=>=| Out |=>==== data
non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM
|----- ---- -----|
------------------------
Figure 7: OAM Control Message Delivery Bypassing the Forwarding Engine
图7：绕过转发引擎的OAM控制消息传递
This solution is fully functional for the incoming MIP. It also supports control of data loopback for the outgoing MIP and can adequately perform some OAM features such as interface identity reporting at the outgoing MIP.
此解决方案对传入的MIP功能齐全。它还支持控制传出MIP的数据环回，并可以在传出MIP上充分执行一些OAM功能，例如接口身份报告。
However, because the OAM message is not forwarded through the forwarding engine, this solution cannot correctly perform OAM loopback, connectivity verification, LSP tracing, or performance measurement.
但是，由于OAM消息未通过转发引擎转发，因此此解决方案无法正确执行OAM环回、连接验证、LSP跟踪或性能测量。
The last bullet point is also an important requirement for any solution to the internal-MIP addressing problem. Since OAM packets that target an out-MIP need to be sent through the forwarding engine and treated exactly as regular data packets, the determination of whether to forward the packet or process it at the incoming MIP needs to be fast; therefore, the processing overhead must be kept to a minimum. In addition, there are a few OAM procedures that operate at line rate such as OAM loopback. This adds to the requirement of minimal processing overhead for both the in-MIP and out-MIP.
最后一点也是解决内部MIP寻址问题的任何解决方案的重要要求。由于以out MIP为目标的OAM分组需要通过转发引擎发送，并且被完全视为常规数据分组，因此需要快速确定是转发分组还是在传入MIP处处理分组；因此，必须将处理开销保持在最低限度。此外，还有一些OAM过程以线路速率运行，例如OAM环回。这增加了对in MIP和out MIP的最小处理开销的要求。
Most of the above superficially appears to be an implementation matter local to an individual node; however, the format of the message needs to be standardized so that:
上述大部分内容表面上似乎是单个节点的本地实现问题；但是，信息的格式需要标准化，以便：
o A MEP can correctly target the outgoing MIP of a specific MPLS-TP node.
o MEP可以正确地针对特定MPLS-TP节点的传出MIP。
o A node can correctly filter out any OAM messages that were intended for its upstream neighbor's outgoing MIP, but which were not handled there because the upstream neighbor is an implementation as shown in Figures 4 and 6.
o 一个节点可以正确地过滤出任何用于其上游邻居的传出MIP的OAM消息，但由于上游邻居是如图4和图6所示的实现，因此没有在那里处理这些消息。
Note that the last bullet point describes a safety net in case OAM messages leak beyond their intended scope, but implementations should take care that messages do not leak so that the safety net does not need to be used.
请注意，最后一个要点描述了在OAM消息泄漏超出其预期范围的情况下的安全网，但实现应注意消息不会泄漏，以便不需要使用安全网。
OAM security is discussed in [RFC6371] and security aspects specific to MPLS-TP in general are outlined in [RFC6941].
[RFC6371]中讨论了OAM安全性，[RFC6941]中概述了MPLS-TP的安全方面。
OAM can provide useful information for detecting and tracing security attacks.
OAM可以为检测和跟踪安全攻击提供有用的信息。
OAM can also be used to illicitly gather information or for denial-of-service attacks and other types of attack. Implementations therefore are required to offer security mechanisms for OAM. Deployments are therefore strongly advised to follow the security advice provided in RFCs 6371 and 6941.
OAM还可用于非法收集信息，或用于拒绝服务攻击和其他类型的攻击。因此，需要实现为OAM提供安全机制。因此，强烈建议部署人员遵循RFCs 6371和6941中提供的安全建议。
Mixing of per-node and per-interface OAM on a single node is not advised as OAM message leakage could be the result.
不建议在单个节点上混合使用每个节点和每个接口的OAM，因为可能会导致OAM消息泄漏。
The authors gratefully acknowledge the substantial contributions of Zhenlong Cui. We would also like to thank Eric Gray, Sami Boutros, and Shahram Davari for interesting input to this document through discussions.
作者衷心感谢崔振龙的巨大贡献。我们还要感谢Eric Gray、Sami Boutros和Shahram Davari通过讨论为本文件提供了有趣的信息。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385]Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 43852006年2月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370]Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371]Busi，I.，Ed.和D.Allan，Ed.“基于MPLS的传输网络的操作、管理和维护框架”，RFC 63712011年9月。
[RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011.
[RFC6423]Li，H.，Martini，L.，He，J.，和F.Huang，“在MPLS传输配置文件（MPLS-TP）中使用伪线的通用相关信道标签”，RFC 64232011年11月。
[RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, "MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions", RFC 6923, May 2013.
[RFC6923]Winter，R.，Gray，E.，van Helvoort，H.，和M.Betts，“遵循ITU-T公约的MPLS传输配置文件（MPLS-TP）标识符”，RFC 69232013年5月。
[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, June 2011.
[RFC6291]Andersson，L.，van Helvoort，H.，Bonica，R.，Romascanu，D.，和S.Mansfield，“IETF中“OAM”首字母缩写词的使用指南”，BCP 161，RFC 62912011年6月。
[RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.
[RFC6941]Fang，L.，Ed.，Niven Jenkins，B.，Ed.，Mansfield，S.，Ed.，和R.Graveman，Ed.，“MPLS传输配置文件（MPLS-TP）安全框架”，RFC 69412013年4月。
Authors' Addresses
作者地址
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Hideki Endo Hitachi, Ltd.
远藤英机日立有限公司。
EMail: hideki.endo.es@hitachi.com
EMail: hideki.endo.es@hitachi.com
Rolf Winter NEC
罗尔夫冬季NEC
EMail: rolf.winter@neclab.eu
EMail: rolf.winter@neclab.eu
Yoshinori Koike NTT
小池吉诺里NTT
EMail: koike.yoshinori@lab.ntt.co.jp
EMail: koike.yoshinori@lab.ntt.co.jp
Manuel Paul Deutsche Telekom
曼努埃尔·保罗德国电信公司
EMail: Manuel.Paul@telekom.de
EMail: Manuel.Paul@telekom.de