Internet Engineering Task Force (IETF) S. Boutros, Ed.
Request for Comments: 6435 S. Sivabalan, Ed.
Updates: 6371 Cisco Systems, Inc.
Category: Standards Track R. Aggarwal, Ed.
ISSN: 2070-1721 Arktan, Inc.
M. Vigoureux, Ed.
Alcatel-Lucent
X. Dai, Ed.
ZTE Corporation
November 2011
MPLS Transport Profile Lock Instruct and Loopback Functions
Abstract
抽象
Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.
トランスポート・ネットワーク内の2つの便利な操作、管理、および保守（OAM）機能が「ロック」と「ループバック」です。ロック機能は、クライアントのトラフィックを伝送しませんが、OAMメッセージを運ぶために続けることができ、テストトラフィックを運ぶことができるように、搬送経路をロックする作業を可能にします。ループバック機能は、すべての受信されたデータを返すようにループバックモードに搬送経路上の特定のノードを設定するオペレータを可能にします。
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
この文書では、MPLSネットワークのためのロック機能を指定し、ループバック機能は、MPLSネットワークでどのように動作するかを説明します。
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371.
この文書は、セクション7.1.1およびRFC 6371の7.1.2に更新します。
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 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc6435.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6435で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". This document discusses these functions in the context of MPLS networks.
トランスポート・ネットワーク内の2つの便利な操作、管理、および保守（OAM）機能が「ロック」と「ループバック」です。この文書では、MPLSネットワークのコンテキストでこれらの機能について説明します。
- The lock function enables an operator to lock a transport path such that it does not carry client traffic. As per RFC 5860 [1], lock is an administrative state in which it is expected that no client traffic may be carried. However, test traffic and OAM messages can still be mapped onto the locked transport path. The lock function may be applied to the Label Switched Paths (LSPs), Pseudowires (PWs) (including multi-segment Pseudowires) (MS-PWs), and bidirectional MPLS Sections as defined in RFC 5960 [9]).
- ロック機能は、クライアントトラフィックを伝送しないように、搬送経路をロックする作業を可能にします。 RFC 5860に従って、[1]、ロックは、何のクライアントトラフィックが搬送されなくてもよいことが予想された管理状態です。しかし、テストトラフィックとOAMメッセージはまだロックされた搬送経路上にマッピングすることができます。ラベルに適用することができるロック機能は、パス（LSPを）スイッチ、（MS-のPW）、およびRFC 5960で定義されるように、双方向MPLSセクション（マルチセグメントスードワイヤ含む）スードワイヤ（のPW）[9]）。
- The loopback function allows an operator to set a specific node on a transport path into loopback mode such that it returns all received data. Loopback can be applied at a Maintenance Entity Group End Point (MEP) or a Maintenance Entity Group Intermediate Point (MIP) on a co-routed bidirectional LSP, on a PW, or on a bidirectional MPLS Section. It can also be applied at a MEP on an associated bidirectional LSP.
- ループバック機能は、すべての受信されたデータを返すようにループバックモードに搬送経路上の特定のノードを設定するためのオペレータを可能にします。ループバックは、共同でルーティング双方向LSP上、PWの上に、または双方向MPLS部にメンテナンスエンティティグループエンドポイント（MEP）またはメンテナンスエンティティグループの中間点（MIP）で適用することができます。それはまた、関連する双方向LSP上のMEPに適用することができます。
Loopback is used to test the integrity of the transport path to and from the node that is performing loopback. It requires that the transport path be locked and that a MEP on the transport path send test data that it also validates on receipt.
ループバックは、ループバックを実行しているノードとから搬送路の完全性を試験するために使用されます。これは、搬送経路がロックされていること、それはまた、領収書に検証する搬送経路上のMEPは、テストデータを送信することが必要です。
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
この文書では、MPLSネットワークのためのロック機能を指定し、ループバック機能は、MPLSネットワークでどのように動作するかを説明します。
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371 [6].
この文書では、[6]のセクション7.1.1およびRFC 6371の7.1.2を更新します。
The framework in RFC 6371 makes the assumption that the Lock Instruct message is used to independently enable locking and requires a response message.
RFC 6371におけるフレームワークは、ロックに指示メッセージが、独立してロック可能と応答メッセージを要求するために使用されるという仮定を行います。
The mechanism defined in this document requires that when a lock instruction is sent by management to both ends of the locked transport path, the Lock Instruct message does not require a response.
この文書で定義された機構は、ロック命令がロック搬送路の両端に管理することによって送信されたとき、ロックに指示メッセージが応答を必要としないことを要求します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
ACH: Associated Channel Header
ACH：関連するチャネルヘッダー
LI: Lock Instruct
LI：ロック指示し
MEG: Maintenance Entity Group
MEG：メンテナンスエンティティグループ
MEP: Maintenance Entity Group End Point
MEP：メンテナンスエンティティグループエンドポイント
MIP: Maintenance Entity Group Intermediate Point
MIP：メンテナンスエンティティグループの中間点
MPLS-TP: MPLS Transport Profile
MPLS-TP：MPLSトランスポートプロファイル
NMS: Network Management System
NMS：ネットワーク管理システム
TLV: Type Length Value
TLV：タイプ長さ値
Transport path: MPLS-TP LSP or PW
トランスポートパス：MPLS-TPのLSPまたはPW
TTL: Time To Live
TTL：生存時間
Lock is used to request that a MEP take a transport path out of service for administrative reasons. For example, Lock can be used to allow some form of maintenance to be done for a transport path. Lock is also a prerequisite of the loopback function described in Section 4. The NMS or a management process initiates a Lock by sending a Lock command to a MEP. The MEP takes the transport path out of service, that is, it stops injecting or forwarding traffic onto the transport path.
ロックは、MEPは、管理上の理由でサービスのうち、搬送経路を取ることを要求するために使用されます。例えば、ロックはメンテナンスのいくつかのフォームが搬送経路に対して行うことができるようにするために使用することができます。ロックはまた、第4節NMSまたは管理プロセスで説明したループバック機能の前提条件であるMEPにロックコマンドを送信することで、ロックを開始します。 MEPはつまり、それが搬送経路上にトラフィックを注入するか、転送を停止し、サービスのうち、搬送経路をとります。
To properly lock a transport path (for example, to ensure that a loopback test can be performed), both directions of the transport path must be taken out of service; therefore, a Lock command is sent to the MEPs at both ends of the path. This ensures that no traffic is sent in either direction. Thus, the lock function can be realized entirely using the management plane.
適切に搬送路（例えば、ループバックテストを行うことができることを確実にするために）、搬送経路の両方向サービスから取り出さなければならないをロックします。従って、ロックコマンドは、経路の両端でのMEPに送信されます。これは、トラフィックがどちらの方向に送信されないことを保証します。これにより、ロック機能は、完全に管理プレーンを使用して実現することができます。
However, dispatch of messages in the management plane to the two MEPs may present coordination challenges. It is desirable that the lock be achieved in a coordinated way within a tight window, and this may be difficult with a busy management plane. In order to provide additional coordination, an LI OAM message can also be sent. A MEP locks a transport path when it receives a command from a management process or when it receives an LI message as described in Section 6.
しかし、2つのMEPに管理プレーン内のメッセージのディスパッチを協調の課題を提示してもよいです。ロックがきついウィンドウ内で協調して達成することが望ましい、これは忙しい管理面では難しいかもしれません。追加の調整を提供するために、LI OAMメッセージも送信することができます。それは管理プロセスからのコマンドを受信した場合、またはセクション6で説明したように、LIメッセージを受信した場合MEPは、搬送路をロックします。
This document defines an LI message for MPLS OAM. The LI message is based on a new ACH Type as well as an existing TLV. This is a common mechanism applicable to lock LSPs, PWs, and bidirectional MPLS Sections.
この文書では、MPLS OAMのためのLIメッセージを定義します。 LIメッセージは新しいACHタイプだけでなく、既存のTLVに基づいています。これはLSPを、PWを、双方向MPLSセクションをロックする適用共通のメカニズムです。
This section provides a description of the loopback function within an MPLS network. This function is achieved through management commands, so there is no protocol specification necessary. However, the loopback function is dependent on the lock function, so it is appropriate to describe it in this document.
このセクションでは、MPLSネットワーク内のループバック機能の説明を提供します。この機能は、管理コマンドを介して達成されるので、必要ないプロトコル仕様は存在しません。しかし、ループバック機能は、ロック機能に依存しているので、この文書でそれを記述することが適切です。
The loopback function is used to test the integrity of a transport path from a MEP up any other node in the same MEG. This is achieved by setting the target node into loopback mode, and transmitting a pattern of test data from the MEP. The target node loops all received data back toward the originator, and the MEP extracts the test data and compares it with what it sent.
ループバック機能は、同じMEG内の他のノードまでのMEPから搬送路の完全性を試験するために使用されます。これは、ループバック・モードにターゲットノードを設定し、MEPからのテストデータのパターンを送信することによって達成されます。ターゲットノードは、すべてのバック発信元に向けてデータを受信ループ、MEPは、試験データを抽出し、それを送信ものと比較します。
Loopback is a function that enables a receiving MEP or MIP to return traffic to the sending MEP when in the loopback state. This state corresponds to the situation where, at a given node, a forwarding plane loop is configured, and the incoming direction of a transport path is cross-connected to the outgoing reverse direction. Therefore, except in the case of early TTL expiry, traffic sent by the source will be received by that source.
ループバックは、ループバック状態のとき、送信MEPにトラフィックを戻すために受けたMEPまたはMIPを可能にする機能です。この状態は、所与のノードにおいて、転送プレーンループが構成され、状況に対応しており、搬送路の到来方向は、クロス接続された発信逆方向です。したがって、初期TTLの期限切れの場合を除き、ソースによって送信されたトラフィックは、そのソースによって受信されます。
Data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [1]. This function loops back all traffic (including user data and OAM). The traffic can be originated from one internal point at the ingress of a transport path within an interface or inserted from an input port of an interface using external test equipment. The traffic is looped back unmodified (other than normal per-hop processing such as TTL decrement) in the direction of the point of origin by an interface at either an intermediate node or a terminating node.
データプレーンのループバックは、RFC 5860のセクション2.2.5に、必要に応じて、アウトオブサービス機能である[1]。この機能は、バック（ユーザデータ及びOAMを含む）すべてのトラフィックをループします。トラフィックは、インタフェース内の搬送路の入口でつの内部点由来または外部のテスト機器を使用してインターフェイスの入力ポートから挿入することができます。トラフィックは、中間ノードまたは終端ノードのいずれかでのインタフェースによって原点の方向に修飾されていない（例えば、TTLの減少のような他の通常よりホップごとの処理）をループバックされます。
It should be noted that the data-plane loopback function itself is applied to data-plane loopback points residing on different interfaces from MIPs/MEPs. All traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path.
データプレーンのループバック機能自体がMIPを/のMEPとは異なるインターフェイス上に存在するデータプレーンループバックポイントに適用されることに留意すべきです。ループバックインターフェースは、搬送経路の逆方向に送られるに（ペイロードとOAMの両方を含む）すべてのトラフィックが受信されました。
For data-plane loopback at an intermediate point in a transport path, the loopback needs to be configured to occur at either the ingress or egress interface. This is done using management.
搬送経路の途中でデータプレーンループバックのために、ループバックは、入力または出力インターフェイスのいずれかで発生するように構成する必要があります。これは、管理を使用して行われます。
The management plane can be used to configure the loopback function. The management plane must ensure that the two MEPs are locked before it requests setting MEP or MIP in the loopback state.
管理プレーンは、ループバック機能を設定するために使用することができます。管理プレーンは、それがループバック状態にMEPまたはMIPを設定要求する前に2つのMEPがロックされていることを確認する必要があります。
The nature of test data and the use of loopback traffic to measure packet loss, delay, and delay variation are outside the scope of this document.
テストデータの性質やパケットロス、遅延、および遅延変動を測定するためのループバックトラフィックの使用は、この文書の範囲外です。
Obviously, for the loopback function to operate, there are several prerequisites:
明らかに、動作させるためのループバック機能のために、いくつかの前提条件があります。
- There must be a return path, so the transport path under test must be bidirectional.
- テスト対象の搬送経路が双方向でなければならないので、リターンパスが存在する必要があります。
- The node in loopback mode must be on both the forward and return paths. This is possible for all MEPs and MIPs on a co-routed bidirectional LSP, on a PW, or on a bidirectional MPLS Section, but it is only possible for MEPs on associated bidirectional LSPs.
- ループバック・モードでのノードは、順方向の両方であることとパスを返す必要があります。これは、PWの共同ルーティング双方向LSP上のすべてのMEPとMIPは、のために、または双方向MPLSセクションで可能ですが、それは、関連する双方向のLSP上のMEPのためにのみ可能です。
- The transport path cannot deliver client data when one of its nodes is in loopback mode, so it is important that the transport path be locked before loopback is enabled.
- そのノードのいずれかが、ループバック・モードのときに搬送経路は、クライアントのデータを配信することができないので、ループバックが有効になっている前に、搬送経路をロックすることが重要です。
- Management-plane coordination between the node in loopback mode and the MEP sending test data is required. The MEP must not send test data until loopback has been properly configured because this would result in the test data continuing toward the destination.
- ループバック・モードでのノードとMEP送信テストデータとの管理プレーン調整が必要です。これは先に向かって継続的なテストデータにつながるので、ループバックが適切に設定されるまで、MEPは、テストデータを送信してはなりません。
- The TTL of the test packets must be set sufficiently large to account for both directions of the transport path under test; otherwise, the packets will not be returned to the originating MEP.
- テストパケットのTTLは、試験下の搬送経路の両方向を考慮して十分に大きく設定されなければなりません。そうでない場合、パケットは元のMEPに返却されることはありません。
- OAM messages intended for delivery to nodes along the transport path under test can be delivered by correct TTL expiry. However, OAM messages cannot be delivered to points beyond the loopback node until the loopback condition is lifted.
- 試験下搬送経路に沿ったノードへの送達のために意図OAMメッセージが正しいTTLの期限切れにより送達することができます。ループバック状態が解除されるまでは、OAMメッセージは、ループバックノード以降のポイントに配信することができません。
The Lock Instruct message is carried in the Generic ACH described in [4]. It is identified by a new PW ACH Type of 0x0026.
ロックに指示メッセージは、[4]に記載の一般的なACHで運ばれます。それは、0x0026の新しいPW ACHタイプによって識別されます。
The format of an LI message is shown below.
LIメッセージのフォーマットを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Reserved | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP Source ID TLV |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: MPLS Lock Instruct Message Format
図1：MPLSロックに指示メッセージフォーマット
Version: The Version number is currently 1. (Note: the version number is to be incremented whenever a change is made that affects the ability of an implementation to correctly parse or process the message. These changes include any syntactic or semantic changes made to any of the fixed fields, or to any Type-Length-Value (TLV) or sub- TLV assignment or format that is defined at a certain version number. The version number may not need to be changed if an optional TLV or sub-TLV is added.)
バージョン：バージョン番号は現在1です（注意：バージョン番号は変更が正しくメッセージを解析または処理するための実装の能力に影響を与える行われるたびにインクリメントされるこれらの変更は、いずれかに行われた構文や意味の変更が含まれます。固定フィールドの、または任意のタイプレングス値（TLV）または特定のバージョン番号で定義されたサブTLVの割り当てまたはフォーマットにオプションのTLVまたはサブTLVがある場合、バージョン番号を変更する必要がないかもしれません追加しました。）
Reserved: The Reserved field MUST be set to zero on transmission and SHOULD be ignored on receipt.
予約：予約フィールドは、送信時にゼロに設定しなければならなくて、領収書の上で無視されるべきです。
Refresh Timer: The Refresh Timer is the maximum time between successive LI messages specified in seconds. The default value is 1. The value 0 is not permitted. When a lock is applied, a refresh timer is chosen. This value MUST NOT be changed for the duration of that lock. A node receiving an LI message with a changed refresh timer MAY ignore the new value and continue to apply the old value.
リフレッシュタイマ：リフレッシュタイマは秒単位で指定された連続LIメッセージ間の最大時間です。値0が許可されていない1.デフォルト値です。ロックが適用されると、リフレッシュタイマが選択されています。この値は、そのロックの期間中に変更しないでください。変更されたリフレッシュタイマとLIメッセージを受信したノードは、新しい値を無視し、古い値を適用し続けることができます。
MEP Source ID TLV: This is one of the three MEP Source ID TLVs defined in [3] and identifies the MEP that originated the LI message.
MEPソースID TLV：これは、[3]に定義された三元MEP IDのTLVの一つであり、LIメッセージを発信したMEPを識別する。
When a MEP receives a Lock command from an NMS or through some other management process, it MUST take the transport path out of service. That is, it MUST stop injecting or forwarding traffic onto the LSP, PW, or bidirectional Section that has been locked.
MEPは、NMSからまたは他の管理プロセスを通じてロックコマンドを受信すると、それはサービスのうち、搬送経路を取る必要があります。つまり、それはLSP、PW、またはロックされた双方向のセクションにトラフィックを注入するか、転送を停止しなければなりません。
If rapid coordination of lock state is to be achieved (as described in Section 3) then as soon as the transport path has been locked, the MEP MUST send an LI message targeting the MEP at the other end of the locked transport path. In this case, the source MEP MUST set the Refresh Timer value in the LI message and MUST retransmit the LI message at the frequency indicated by the value set.
ロック状態の迅速な調整が、その後、すぐに搬送パスがロックされているように（セクション3に記載されているように）を達成する場合、MEPは、ロックされた搬送路の他端にMEPを標的LIメッセージを送らなければなりません。この場合には、ソースMEPは、LIメッセージにリフレッシュタイマ値を設定する必要があり、その値のセットによって示される周波数でLIメッセージを再送しなければなりません。
When locking a transport path, the NMS or management process is required to send a Lock command to both ends of the transport path. Thus, a MEP may receive either the management command or an LI message first. A MEP MUST take the transport path out of service immediately in either case, but sends LI messages itself after it has received a management Lock command. Thus, a MEP is locked if either Lock was requested by management (and, as a result, the MEP is sending LI messages) or it is receiving LI messages from the remote MEP.
搬送路をロックする場合、NMSまたは管理プロセスは、搬送路の両端にロックコマンドを送信する必要があります。したがって、MEPは、管理コマンドまたは最初のLIメッセージのいずれかを受信することができます。 MEPは、いずれの場合には、直ちにサービスのうち、搬送経路を取るが、それは経営ロックコマンドを受信した後にLIメッセージ自体を送信しなければなりません。したがって、いずれかのロックが（結果として、MEPは、LIメッセージを送信している、など）管理によって要求された場合、MEPは、ロックされているか、遠隔MEPからのLIメッセージを受信しています。
Note that a MEP that receives an LI message MUST identify the correct transport path and validate the message. The label stack on the received message is used to identify the transport path to be locked:
LIメッセージを受信したMEPは、正しい搬送経路を識別し、メッセージを検証しなければならないことに留意されたいです。受信したメッセージにラベルスタックがロックされる搬送経路を識別するために使用されます。
- If no matching label binding exists, then there is no corresponding transport path and the received LI message is in error.
- 一致するラベルバインディングが存在しない場合、該当する搬送路と、受信したLIメッセージが存在しないとエラーになります。
- If the transport path can be identified, but there is no return path (for example, the transport path was unidirectional) then (obviously) the receiving MEP cannot apply a lock to the return path.
- 場合は、搬送経路を同定することができるが、ノーリターンパス（例えば、搬送経路が一方向であった）を（明らかに）受信MEPは、リターンパスにロックをかけることができないがありません。
- If the transport path is suitable for locking but the Source MEP-ID identifies an unexpected MEP for the MEG to which the receiving MEP belongs, the received LI message is in error.
- 搬送経路がロックするのに適しているが、ソースMEP-IDを受信MEPが属するMEGのための予想外のMEPを識別する、受信したLIメッセージがエラーである場合。
When an errored LI message is received, the receiving MEP MUST NOT apply a lock. A MEP receiving errored LI messages SHOULD perform local diagnostic actions (such as counting the messages) and MAY log the messages.
エラーの発生したLIメッセージを受信すると、受信したMEPは、ロックを適用してはいけません。エラーの発生したLIメッセージを受信したMEPは、（そのようなメッセージを数えるような）ローカル診断アクションを実行する必要があり、メッセージをログインすることができます。
A MEP keeps a transport path locked as long as it is either receiving the periodic LI messages or has an in-force Lock command from management (see Section 6.2 for an explanation of unlocking a MEP). Note that in some scenarios (such as the use of loopback as described in Section 4), LI messages will not continue to be delivered on a locked transport path. This is why a transport path is considered locked while there is an in-force Lock command from a management process regardless of whether LI messages are being received.
MEPは、それが定期的LIメッセージを受信するか、（MEPをロック解除の説明については、セクション6.2を参照）管理からで力ロックコマンドを有しているのいずれかとしてロックされた搬送路を維持します。 （例えば、セクション4で説明したように、ループバックの使用のような）いくつかのシナリオでは、LIメッセージがロック搬送路に配信され続けないことに注意してください。かかわらず、LIメッセージが受信されているかどうかの管理プロセスからで力Lockコマンドがある間搬送経路が、ロックされたと見なされるのはこのためです。
Unlock is used to request that a MEP bring the previously locked transport path back in service.
ロック解除MEPはバックサービスで、以前にロックされた搬送経路を持参することを要求するために使用されます。
When a MEP receives an Unlock command from a management process, it MUST cease sending LI messages. However, as described in Section 6.1, if the MEP is still receiving LI messages, the transport path MUST remain out of service. Thus, to unlock a transport path, the management process has to send an Unlock command to the MEPs at both ends.
MEPは、管理プロセスからロック解除コマンドを受信すると、それはLIメッセージの送信を中止しなければなりません。 6.1節で説明したようにMEPはまだLIメッセージを受信している場合には、搬送路には、サービスの外に残っている必要があります。したがって、搬送経路のロックを解除するために、管理プロセスは、両端のMEPにロック解除コマンドを送信しなければなりません。
When a MEP has been unlocked and has not received an LI message for a multiple of 3.5 times the Refresh Timer on the LI message (or has never received an LI message), the MEP unlocks the transport path and puts it back into service.
MEPがロック解除されたとLIメッセージの3.5倍リフレッシュタイマの倍数のためのLIメッセージを受信していない（またはLIメッセージを受信したことがない）場合は、MEPは、搬送路のロックを解除し、サービスに戻ってそれを置きます。
MPLS-TP is a subset of MPLS and builds upon many of the aspects of the security model of MPLS. MPLS networks make the assumption that it is very hard to inject traffic into a network, and it is equally hard to cause traffic to be directed outside the network. For more information on the generic aspects of MPLS security, see [7].
MPLS-TPは、MPLSのサブセットであり、MPLSのセキュリティモデルの特徴の多くの上に構築されています。 MPLSネットワークは、ネットワークにトラフィックを注入することは非常に困難であるという仮定を作り、トラフィックがネットワークの外に向けることが原因とすることも同様に困難です。 MPLSセキュリティの一般的な側面についての詳細は、[7]を参照してください。
This document describes a protocol carried in the G-ACh [4], so it is dependent on the security of the G-ACh, itself. The G-ACh is a generalization of the Pseudowire Associated Channel defined in [8]. Thus, this document relies heavily on the security mechanisms provided for the Associated Channel as described in [4] and [8].
この文書では、[4] G-ACHで運ばれるプロトコルについて説明し、それはG-ACH、自身のセキュリティに依存しています。 G-ACH [8]で定義された疑似関連するチャネルの一般化です。したがって、この文書は、に記載されているように、関連するチャネルのために提供するセキュリティ・メカニズムに大きく依存している[4]、[8]。
A specific concern for the G-ACh is that is can be used to provide a covert channel. This problem is wider than the scope of this document and does not need to be addressed here, but it should be noted that the channel provides end-to-end connectivity and SHOULD NOT be policed by transit nodes. Thus, there is no simple way to prevent traffic from being carried in the G-ACh between consenting nodes.
G-ACHに特異的な関心事であるが、隠れチャネルを提供するために使用することができることです。この問題は、このドキュメントの範囲よりも広く、かつ、ここで対処する必要はありませんが、チャネルは、エンドツーエンドの接続性を提供し、トランジットノードによって取り締まられるべきではないことに留意すべきです。したがって、同意ノード間G-ACHで搬送されるのトラフィックを防止する簡単な方法は存在しません。
A good discussion of the data-plane security of an associated channel may be found in [5]. That document also describes some mitigation techniques.
関連するチャネルのデータプレーンのセキュリティの良好な議論は[5]に見出すことができます。その文書はまた、いくつかの緩和技術について説明します。
It should be noted that the G-ACh is essentially connection-oriented, so injection or modification of control messages specified in this document requires the subversion of a transit node. Such subversion is generally considered hard in MPLS networks, and impossible to protect against at the protocol level. Management-level techniques are more appropriate.
G-ACHは、本質的にコネクション指向であるため、この文書で指定された制御メッセージの注射または修飾がトランジットノードの転覆を必要とすることに留意すべきです。そのようなSubversionは、一般的にMPLSネットワークでハード考え、プロトコルレベルでから保護することは不可能です。管理レベルの技術は、より適切です。
LI OAM requires a unique Associated Channel Type that has been assigned by IANA in the "Pseudowire Associated Channel Types" registry.
LI OAMは、「擬似回線関連するチャネルタイプ」レジストリにIANAによって割り当てられたユニークな関連するチャネルタイプが必要です。
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0026 LI No [RFC6435]
The authors would like to thank Loa Andersson, Yoshinori Koike, Alessandro D'Alessandro Gerardo, Shahram Davari, Greg Mirsky, Yaacov Weingarten, Liu Guoman, Matthew Bocci, Adrian Farrel, and Jia He for their valuable comments.
作者は彼らの貴重なコメントのためのLoaアンデション、義則小池、アレッサンドロ・ダレッサンドロヘラルド、Shahram Davari、グレッグMirsky、Yaacovヴェンガルテン、劉アグオマン、マシューボッチ、エードリアンファレル、および嘉氏に感謝したいと思います。
[1] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[1] Vigoureux、M.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "運用、管理、およびMPLS交通ネットワークのメンテナンス（OAM）のための要件"、RFC 5860、2010年5月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[3]アラン、D.、エド。、ツバメ、G.、エド。、およびJ.ドレイク、エド。、 "プロアクティブ接続検証、導通チェック、およびMPLSトランスポートプロファイルのためのリモート障害表示"、RFC 6428、11月2011。
[4] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[4]ボッチ、M.、エド。、Vigoureux、M.、エド。、およびS.ブライアント、エド。、 "MPLSジェネリック関連チャンネル"、RFC 5586、2009年6月。
[5] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[5]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。
[6] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[6]ビジネスサービス、I.、エド。、およびD.アラン編、 "運用、MPLSベースのトランスポートネットワークの管理、およびメンテナンス枠組み"、RFC 6371、2011年9月。
[7] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[7]牙、L.、エド。、RFC 5920、2010年7月 "MPLSとGMPLSネットワークのセキュリティフレームワーク"。
[8] 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.
[8]ブライアント、S.、ツバメ、G.、マティーニ、L.、およびD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジツーエッジ（PWE3）コントロールワード"、RFC 4385、2006年2月。
[9] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[9]フロスト、D.、エド。、ブライアント、S.、エド。、およびM.ボッチ、エド。、 "MPLS交通データプレーンのアーキテクチャプロフィール"、RFC 5960、2010年8月。
Contributing Authors
共著
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
ジョージツバメシスコシステムズ、株式会社Eメール：swallow@cisco.com
David Ward Juniper Networks. EMail: dward@juniper.net
デビッド・ウォードジュニパーネットワークス。メールアドレス：dward@juniper.net
Stewart Bryant Cisco Systems, Inc. EMail: stbryant@cisco.com
スチュワートブライアントシスコシステムズ、株式会社Eメール：stbryant@cisco.com
Carlos Pignataro Cisco Systems, Inc. EMail: cpignata@cisco.com
カルロスPignataroシスコシステムズ、株式会社Eメール：cpignata@cisco.com
Eric Osborne Cisco Systems, Inc. EMail: eosborne@cisco.com
エリック・オズボーンシスコシステムズ、株式会社Eメール：eosborne@cisco.com
Nabil Bitar Verizon. EMail: nabil.bitar@verizon.com
ナビル・ビタールベライゾン。メール：nabil.bitar@verizon.com
Italo Busi Alcatel-Lucent. EMail: italo.busi@alcatel-lucent.com
イタロBUSIアルカテル・ルーセント。メールアドレス：italo.busi@alcatel-lucent.com
Lieven Levrau Alcatel-Lucent. EMail: lieven.levrau@alcatel-lucent.com
リーフェンLevrauアルカテル・ルーセント。メールアドレス：lieven.levrau@alcatel-lucent.com
Laurent Ciavaglia Alcatel-Lucent. EMail: laurent.ciavaglia@alcatel-lucent.com
ローラン・スチュワートルーセント。メールアドレス：laurent.ciavaglia@alcatel-lucent.com
Bo Wu ZTE Corporation. EMail: wu.bo@zte.com.cn
UにZT E法人電子メールを弓:.ない特殊な薄い@ .COMために。
Jian Yang ZTE Corporation. EMail: yang_jian@zte.com.cn
Jイアン・ヤンZT E法人電子メール:.ヤン_特別.COMの@を参照するには。
Editors' Addresses
エディタのアドレス
Sami Boutros Cisco Systems, Inc. EMail: sboutros@cisco.com
サミBoutrosシスコシステムズ、株式会社Eメール：sboutros@cisco.com
Siva Sivabalan Cisco Systems, Inc. EMail: msiva@cisco.com
シヴァシババランシスコシステムズ株式会社Eメール：ಮಸಿವ@ಸಿಸ್ಕೋ.ಕಂ
Rahul Aggarwal Arktan, Inc EMail: raggarwa_1@yahoo.com
ラウール・アガーウォールArktan、株式会社Eメール：raggarwa_1@yahoo.com
Martin Vigoureux Alcatel-Lucent. EMail: martin.vigoureux@alcatel-lucent.com
マーティン・ヘイルアルカテル・ルーセント。メールアドレス：martin.vigoureux@alcatel-lucent.com
Xuehui Dai ZTE Corporation. EMail: dai.xuehui@zte.com.cn
X UEは、D、Z TE法人電子メールを愛する：...特別の@ .COMで学びます