[要約] RFC 7054は、Per-Interface Maintenance Entity Group Intermediate Points（MIPs）の要件と設計に関するガイドラインです。その目的は、ネットワークのメンテナンスエンティティグループの中間ポイントに関するアドレッシング要件と設計上の考慮事項を提供することです。
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)
インターフェイスごとのメンテナンスエンティティグループ中間ポイント（MIP）の要件と設計上の考慮事項への対処
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）のフレームワークは、メンテナンスエンティティグループ中間ポイント（MIP）が着信および発信インターフェイスのネットワークノード内にどのように配置されるかを説明します。
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メッセージを形成する方法を指定するメカニズムの重要な制限について説明します。これにより、OAMメッセージを着信または発信インターフェイスのMIPに向け、転送エンジンを介して正しく転送できます。さらに、このドキュメントには、着信MIPと発信MIPの間に区別がないノードの実装に関する考慮事項が含まれています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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）（MPLS-TP OAMフレームワーク、[RFC6371]）内の運用、管理、保守（OAM）のフレームワークは、ノードの保守エンティティグループ中間ポイント（MIP）の2つの構成を区別します。これは、ノードごとのMIPとインターフェイスごとのMIPを定義します。ノードごとのMIPは、ノード内の指定されていない場所にあるノードごとの単一のMIPであり、インターフェイスごとのMIPは、ノードの両側のノードごとに2つ（またはそれ以上）の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メッセージは、Generic Associated Channel（G-ACh）[RFC5586]を使用して送信されます。疑似配線（PW）またはラベルスイッチドパス（LSP）のトランジットポイントのOAMメッセージは、MPLSシムヘッダーのTime-to-Live（TTL）フィールドの有効期限を使用して配信されます。 PWと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）におけるGeneric Associated Channel Label（GAL）の存在です。 PWで使用されるメカニズムは、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.
1つのノードに複数のMIPが存在する場合、これらのメカニズムだけでは、一連のMIPから特定の1つの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].
このドキュメントでは、in-MIP（受信MIP）という用語を使用して、OAMメッセージがノードの転送エンジンを通過する前に処理するMIPを指します。送信MIP（送信MIP）は、ノードの転送エンジンを通過したOAMメッセージを処理します。 2つを合わせて内部MIPと呼びます。 「転送エンジン」という用語は、[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 |
|----- -----|
------------------------
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:
このアーキテクチャモデルには、PWと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および/またはMIPを含むMPLS-TP PW上のtraceroute
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.
インターフェイスごとのMIPには、障害の正確な特定と特定、および診断テストを可能にするという利点があります。特に、問題がノード間または特定のノードにあるかどうか、およびそのノードのどこにあるかの識別が大幅に強化されます。明らかな理由により、障害の原因をすばやく絞り込み、適切な指示に従って適切な保守作業を開始し、通常のネットワーク操作を再開することが重要です。
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.
次の2つの図は、OAMでノードごととインターフェイスごとのMEPとMIPを使用する場合の基本的な違いを示しています。図2は、ノードごとのMIPとMEPを使用したOAMを示しています。説明のため、ノード上のMIPの場所を選択しますが、標準ではノードごとのモデルの正確な場所を義務付けていません。図では、双方向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)<==========================>
Figure 2: Example of OAM Relying on Per-Node MIPs and MEPs
図2：ノードごとのMIPおよびMEPに依存するOAMの例
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.
これらの2つの動作モードの違いを説明するために、例として障害検出を使用します。 CE1とCE2の間のクライアントトラフィックに障害が発生した場合を考えます。また、PE1とPE2間のオンデマンドCVテストが成功したと仮定します。したがって、図2のシナリオでは、PE2の転送エンジン（FW）、PE2の発信インターフェイス、PE2とCE2の間の伝送ライン、またはCE2自体が、オンデマンドCVのみが可能なため、障害の潜在的な場所として残ります。セグメントS2で実行されます。このシナリオでは、PWまたはLSPは2つの例（1つではない）として理解されることに注意してください。つまり、図はPWおよび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の転送エンジンを除外するのに役立ちます。もちろん、これは1つの例にすぎず、他の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)<==================================>
Figure 3: Example of OAM Relying on Per-Interface MIPs and MEPs
図3：インターフェイスごとのMIPおよびMEPに依存するOAMの例
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]
PWまたはLSPのトランジットポイントのOAMメッセージは、MPLSパケットヘッダーの上部LSEのTTLフィールドの有効期限を使用して配信されます。 PWとLSPのエンドポイントのOAMメッセージは、通常どおり配信されるだけです。これらのメッセージは他の（データ）パケットと区別されるため、OAMとして処理できます。 LSPで使用されるメカニズムは、最上位LSE [RFC5586]の下のLSEにGALが存在することです。 PWで使用されるメカニズムは、PW関連チャネルヘッダーの存在[RFC4385]またはGALの存在[RFC6423]です。さらに、[RFC6370]と[RFC6923]で定義されているMIPのアドレス指定に使用できる2組の識別子が存在します。
Any solution for sending OAM messages to the in- and out-MIPs must fit within these existing models of handling OAM.
OAMメッセージをin-およびout-MIPに送信するためのソリューションはすべて、これらの既存の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 MIP functions on those interfaces. This is the case for existing deployed implementations in particular.
さらに、多くのMPLS-TPノードは、すべてのキューイングおよび転送機能が着信インターフェイスで実行されるように実装されています。そのようなノードの抽象的な機能表現を図4に示します。図に示すように、発信インターフェースは最小限であり、このため、これらのインターフェースに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 |
|------------ |
---------------------
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 |
| -----|
--------------------------
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-|->----
----------------------
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 MPLS-TPノード内の正しいMIPへのOAM命令の配信。
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.
最初と2番目の箇条書きは明らかです。ただし、3番目の箇条書きも重要です。重要性を説明するために、拒否されたソリューションを図7に示します。図では、すべてのデータと非ローカルOAMが通常どおりに処理されます。ローカルOAMは着信インターフェイスで代行受信され、着信インターフェイスでMIPに配信されます。 OAMが着信MIPを対象としている場合、OAMは問題なくそこで処理されます。 OAMが発信MIPを対象としている場合、実装固有の内部メッセージングシステムを使用して、そのMIPに転送されます。
------------------------
|----- -----|
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でのインターフェイスIDレポートなどの一部の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アドレッシング問題のソリューションの重要な要件でもあります。アウト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 図4および6に示すように、ノードは、上流ネイバーの発信MIPを目的としたOAMメッセージを正しくフィルタリングできますが、上流ネイバーは実装であるため、そこで処理されませんでした。
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].
OAMセキュリティは[RFC6371]で議論されており、MPLS-TPに一般的なセキュリティの側面は[RFC6941]で概説されています。
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のセキュリティメカニズムを提供する必要があります。したがって、デプロイメントでは、RFC 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]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、2006年2月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M。、編、Vigoureux、M、編、およびS. Bryant、編、「MPLS Generic Associated Channel」、RFC 5586、2009年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 Transport Profile（MPLS-TP）Identifiers」、RFC 6370、2011年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。、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年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 6423、2011年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、「MPLSトランスポートプロファイル（MPLS-TP）ITU-T規則に従う識別子」、RFC 6923、2013年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 6291 、2011年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。、and R. Graveman、Ed。、 "MPLS Transport Profile（MPLS-TP）Security Framework"、 RFC 6941、2013年4月。
Authors' Addresses
著者のアドレス
Adrian Farrel Juniper Networks
エイドリアンファレルジュニパーネットワークス
EMail: adrian@olddog.co.uk
Hideki Endo Hitachi, Ltd.
ひでき えんど ひたち、 Ｌｔｄ。
EMail: hideki.endo.es@hitachi.com
Rolf Winter NEC
ロルフウィンターNEC
EMail: rolf.winter@neclab.eu
Yoshinori Koike NTT
よしのり こいけ んっｔ
EMail: koike.yoshinori@lab.ntt.co.jp
Manuel Paul Deutsche Telekom
マヌエルポールドイツテレコム
EMail: Manuel.Paul@telekom.de