Network Working Group M. Bocci, Ed.
Request for Comments: 5586 M. Vigoureux, Ed.
Updates: 3032, 4385, 5085 Alcatel-Lucent
Category: Standards Track S. Bryant, Ed.
Cisco Systems
June 2009
MPLS Generic Associated Channel
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document generalizes the applicability of the pseudowire (PW) Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) and MPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism.
この文書は、疑似回線（PW）関連するチャネルヘッダ（ACH）の適用を一般化、MPLSラベルに関連する制御チャネルの実現を有効にすると、MPLSの疑似回線に加えて、パス（LSPの）およびMPLSセクションを交換しました。ラベルスタックにおけるこの関連するチャネルヘッダの存在を識別するために、この文書はまた、ラベルベースの例外機構として使用される一般的な関連するチャネル・ラベル（GAL）に予約MPLSラベル値のいずれかを割り当てます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Requirements Language and Terminology . . . . . . . . . . 5
2. Generic Associated Channel Header . . . . . . . . . . . . . . 5
2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Allocation of Channel Types . . . . . . . . . . . . . . . 6
3. ACH TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. ACH TLV Payload Structure . . . . . . . . . . . . . . . . 7
3.2. ACH TLV Header . . . . . . . . . . . . . . . . . . . . . . 8
3.3. ACH TLV Object . . . . . . . . . . . . . . . . . . . . . . 8
4. Generalized Exception Mechanism . . . . . . . . . . . . . . . 9
4.1. Relationship with Existing MPLS OAM Alert Mechanisms . . . 9
4.2. GAL Applicability and Usage . . . . . . . . . . . . . . . 10
4.2.1. GAL Processing . . . . . . . . . . . . . . . . . . . . 10
4.3. Relationship with RFC 3429 . . . . . . . . . . . . . . . . 13
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
7. Major Contributing Authors . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
There is a need for Operations, Administration, and Maintenance (OAM) mechanisms that can be used for fault detection, diagnostics, maintenance, and other functions on a pseudowire (PW) and a Label Switched Path (LSP). These functions can be used between any two Label Edge Routers (LERs)/Label Switching Router (LSRs) or Terminating Provider Edge routers (T-PEs)/Switching Provider Edge routers (S-PEs) along the path of an LSP or PW, respectively [MPLS-TP]. Some of these functions can be supported using existing tools such as Virtual Circuit Connectivity Verification (VCCV) [RFC5085], Bidirectional Forwarding Detection for MPLS LSPs (BFD-MPLS) [BFD-MPLS], LSP-Ping [RFC4379], or BFD-VCCV [BFD-VCCV]. However, a requirement has been indicated to augment this set of maintenance functions, in particular when MPLS networks are used for packet transport services and transport network operations [OAM-REQ]. Examples of these functions include performance monitoring, automatic protection switching, and support for management and signaling communication channels. These tools MUST be applicable to, and function in essentially the same manner (from an operational point of view) on MPLS PWs, MPLS LSPs, and MPLS Sections. They MUST also operate in-band on the PW or LSP such that they do not depend on Packet Switched Network (PSN) routing or on user traffic, and MUST NOT depend on dynamic control plane functions.
事業の必要性、管理、およびメンテナンスの疑似回線上の障害検出、診断、メンテナンス、およびその他の機能に使用することができます（OAM）メカニズム（PW）とラベルスイッチパス（LSP）があります。これらの機能は、LSPまたはPWの経路に沿っプロバイダーエッジルータ（S-PES）をスイッチング/（のLER）/ラベルルータ（LSRの）を切り替えたり、プロバイダーエッジルータの終了（T-PES）任意の二つのラベルエッジルータとの間で使用することができ、それぞれ[MPLS-TP]。これらの機能のいくつかは、仮想回線接続性検証（VCCV）[RFC5085]、MPLS LSPのための双方向フォワーディング検出（BFD-MPLS）[BFD-MPLS]、LSP-Pingの[RFC4379]、またはBFD-などの既存のツールを使用してサポートすることができますVCCV [BFD-VCCV]。しかし、要件は、MPLSネットワークはパケット転送サービスとトランスポートネットワーク運用[OAM-REQ]のために使用される場合、特に、保守機能のセットを増やすことが示されています。これらの機能の例には、性能監視、自動保護スイッチング、および管理のサポートおよびシグナリング通信チャネルを含みます。これらのツールは、MPLSのPW、MPLSのLSP、及びMPLSセクションに（動作の観点から）本質的に同じ方法での適用、および関数でなければなりません。彼らはまた、インバンドPWに又はそれらがパケットに依存しないように、LSP動作しなければならないネットワーク（PSN）ルーティングまたはユーザトラフィックを交換し、動的制御プレーン機能に依存してはなりません。
VCCV [RFC5085] can use an Associated Channel Header (ACH) to provide a PW associated control channel between a PW's endpoints, over which OAM and other control messages can be exchanged. This document generalizes the applicability of the ACH to enable the same associated control channel mechanism to be used for Sections, LSPs, and PWs. The associated control channel thus generalized is known as the Generic Associated Channel (G-ACh). The ACH, specified in RFC 4385 [RFC4385], may be used with additional code points to support additional MPLS maintenance functions on the G-ACh.
VCCV [RFC5085]はOAMと他の制御メッセージを交換することができ、その上PWのエンドポイント間のPW付随制御チャネルを提供するために、関連するチャネルヘッダ（ACH）を使用することができます。この文書では、セクション、のLSP、およびPWのために使用される同一の付随制御チャネル機構を有効にするACHの適用を一般化します。従って一般付随制御チャネルは、汎用関連するチャネル（G-ACH）として知られています。 RFC 4385で指定されたACH、[RFC4385]は、G-ACHに追加MPLSメンテナンス機能をサポートするための追加のコード・ポイントで使用することができます。
Generalizing the applicability of the ACH to LSPs and Sections also requires a method to identify that a packet contains an ACH followed by a non-service payload. Therefore, this document also defines a label-based exception mechanism that serves to inform an LSR (or LER) that a packet it receives on an LSP or Section belongs to an associated control channel. The label used for that purpose is one of the MPLS reserved labels and is referred to as the GAL (G-ACh Label). The GAL mechanism is defined to work together with the ACH for LSPs and MPLS Sections.
LSPとセクションにACHの適用を一般化すると、パケットは、非サービス・ペイロードが続くACHが含まれていることを識別するための方法を必要とします。したがって、この文書はまた、LSPまたはセクションに受信パケット関連制御チャネルに属していることをLSR（またはLER）を通知するために役立つラベルベースの例外メカニズムを定義します。その目的のために使用されるラベルは、MPLS予約ラベルの1つであり、GAL（G-ACHラベル）と呼ばれます。 GAL機構のLSPとMPLSセクションのACHと一緒に動作するように定義されます。
RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when these are encapsulated in an IP header. These alert mechanisms are based, for example, on Time To Live (TTL) expiration and/or on the use of an IP destination address in the range of 127.0.0.0/8 or 0:0: 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. These mechanisms are the default mechanisms for identifying MPLS OAM packets when encapsulated in an IP header. However, it may not always be possible to use these mechanisms in some MPLS applications, e.g., MPLS Transport Profile (MPLS-TP) [MPLS-TP], particularly when IP-based demultiplexing cannot be used. This document defines a mechanism that is RECOMMENDED for identifying and encapsulating MPLS OAM and other maintenance messages when IP based mechanisms such as those used in [RFC4379] and [BFD-MPLS] are not available. Yet, this mechanism MAY be used in addition to IP-based mechanisms.
RFC 4379 [RFC4379]とBFD-MPLS [BFD-MPLSは、これらがIPヘッダでカプセル化されたとき、MPLS OAMパケットを識別し、処理するためのMPLS LSRを有効に警告メカニズムを定義します。 0：0：0：0 FFFFこれらのアラートメカニズムは、例えば、生存時間（TTL）の有効期限上及び/又は127.0.0.0/8または0の範囲内のIP宛先アドレスを使用することに、基づいています。それぞれ、IPv4およびIPv6用127.0.0.0/104。これらのメカニズムは、IPヘッダ内にカプセル化するとき、MPLS OAMパケットを識別するためのデフォルトのメカニズムです。しかし、必ずしもIPベースの分離を使用することができない場合は特に、例えば、MPLSトランスポートプロファイル（MPLS-TP）[MPLS-TP]、いくつかのMPLSアプリケーションでこれらのメカニズムを使用することは可能ではないかもしれません。この文書は、[RFC4379]で使用したものと[BFD-MPLS]などのIPベースのメカニズムを使用できない場合のMPLS OAM及び他の保守メッセージを識別し、カプセル化するための推奨されるメカニズムを定義します。しかし、このメカニズムは、IPベースのメカニズムに加えて使用することもできます。
Note that, in this document, maintenance functions and packets should be understood in the broad sense. That is, a set of maintenance and management mechanisms that include OAM, Automatic Protection Switching (APS), Signaling Communication Channel (SCC), and Management Communication Channel (MCC) messages.
なお、本書では、保守機能パケットは、広い意味で理解されるべきです。これは、OAM、自動保護スイッチング（APS）、シグナリング通信チャネル（SCC）、および管理通信チャネル（MCC）メッセージを含む維持管理メカニズムのセットです。
Also note that the GAL and ACH are applicable to MPLS and PWs in general. This document specifies general mechanism and uses MPLS-TP as an example application. The application of the GAL and ACH to other specific MPLS uses is outside the scope of this document.
また、GALとACHは、一般的には、MPLSおよびPWに適用可能であることに注意してください。この文書では、一般的なメカニズムを指定し、応用例として、MPLS-TPを使用しています。 MPLSが使用する他の特定のGAL及びACHのアプリケーションは、この文書の範囲外です。
This document defines a mechanism that provides a solution to the extended maintenance needs of emerging applications for MPLS. It creates a generic control channel mechanism that may be applied to MPLS LSPs and Sections, while maintaining compatibility with the PW associated channel. It also normalizes the use of the ACH for PWs in a transport context, and defines a label-based exception mechanism to alert LERs/LSRs of the presence of an ACH after the bottom of the label stack.
この文書では、MPLSのための新しいアプリケーションの拡張メンテナンスニーズに対する解決策を提供するメカニズムを定義します。これは、PW関連するチャネルとの互換性を維持しながら、MPLSのLSPのとセクションに適用することができる一般的な制御チャネルメカニズムを作成します。また、搬送コンテキスト内のPW用ACHの使用を正規化し、ラベルスタックの底後ACHの存在のLER / LSRのを警告するラベルベースの例外メカニズムを定義します。
This document defines the encapsulation header for Section, LSP, and PW associated control channel messages.
このドキュメントは、セクション、LSP及びPW関連する制御チャネル・メッセージのカプセル化ヘッダを定義します。
This document does not define how associated control channel capabilities are signaled or negotiated between LERs/LSRs or between PEs, nor does it define the operation of various OAM functions.
この文書は、関連する制御チャネル機能を合図またはネゴシエートのLER / LSRの間またはPE間で、またそれは、様々なOAM機能の動作を定義しない方法を定義していません。
This document does not deprecate existing MPLS and PW OAM mechanisms.
この文書では、既存のMPLSとPW OAMメカニズムを廃止しません。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document uses the following additional terminology:
このドキュメントは、以下の追加の用語を使用します。
ACH: Associated Channel Header
ACH：関連するチャネルヘッダー
G-ACh: Generic Associated Channel
G-ACH：ジェネリック関連したチャンネル
GAL: G-ACh Label
GAL：G-AChのラベル
G-ACh packet: Any packet containing a message belonging to a protocol that is carried on a PW, LSP, or MPLS Section associated control channel. Examples include maintenance protocols such as OAM functions, signaling communications, or management communications.
G-ACHパケット：PW、LSP、またはMPLSセクション関連する制御チャネル上で搬送されるプロトコルに属するメッセージを含む任意のパケット。例としては、保守ようなOAM機能などのプロトコル、シグナリング通信、又は管理通信を含みます。
The terms "Section" and "Concatenated Segment" are defined in [TP-REQ] as follows (note that the terms "Section" and "Section Layer Network" are synonymous):
次のように用語「セクション」および「連結セグメント」（用語「セクション」および「セクションレイヤのネットワーク」は同義であることに注意）TP-REQ]で定義されています。
Section Layer Network: A section layer is a server layer (which may be MPLS-TP or a different technology) that provides for the transfer of the section layer client information between adjacent nodes in the transport path layer or transport service layer. Note that G.805 [G805] defines the section layer as one of the two layer networks in a transmission media layer network. The other layer network is the physical media layer network.
セクションレイヤネットワーク：セクション層は搬送路層やトランスポートサービス層内の隣接するノード間のセクション層クライアント情報の転送を提供する（MPLS-TP又は異なる技術であってもよい）サーバ層です。 G.805 [G805]は伝送媒体レイヤネットワーク内の2つの層のネットワークの一つとして、セクション層を定義することに留意されたいです。他のレイヤネットワークは、物理メディアレイヤネットワークです。
Concatenated Segment: A serial-compound link connection as defined in [G805]. A concatenated segment is a contiguous part of an LSP or multi-segment PW that comprises a set of segments and their interconnecting nodes in sequence.
連結セグメント：[G805]で定義されるようにシリアル化合物リンク接続。連結セグメントは、セグメントおよび配列におけるそれらの相互接続ノードのセットを含むLSPまたはマルチセグメントPWの連続した部分です。
VCCV [RFC5085] defines three Control Channel (CC) Types that may be used to exchange OAM messages through a PW. CC Type 1 uses an ACH and is referred to as "In-band VCCV"; CC Type 2 uses the MPLS Router Alert Label to indicate VCCV packets and is referred to as "Out-of-Band VCCV"; CC Type 3 uses the TTL to force the packet to be processed by the targeted router control plane and is referred to as "MPLS PW Label with TTL == 1".
VCCV [RFC5085]はPWを介しOAMメッセージを交換するために使用することができる3つの制御チャネル（CC）タイプを定義します。 CCタイプ1は、ACHを使用し、「インバンドVCCV」と呼ばれます。 CCのタイプ2は、VCCVパケットを示すために、MPLSルータアラートラベルを使用し、「アウトオブバンドVCCV」と呼ばれます。 CCタイプ3は、ターゲットルータ制御プレーンによって処理されるパケットを強制的にTTLを使用し、「TTL == 1とMPLS PWラベル」と呼ばれます。
The use of the ACH, previously limited to PWs, is here generalized to also apply to LSPs and to Sections. Note that for PWs, the PWE3 control word [RFC4385] MUST be present in the encapsulation of user packets when the ACH is used to realize the associated control channel.
以前のPWに限定ACHの使用は、ここにものLSPにし、セクションに適用する一般化されています。 ACHは、関連する制御チャネルを実現するために使用される場合のPWのために、PWE3制御ワード[RFC4385]は、ユーザパケットのカプセル化に存在しなければならないことに留意されたいです。
The ACH used by CC Type 1 is depicted in figure below:
CCのタイプ1が使用するACHは、以下の図に描かれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Associated Channel Header
図1：関連するチャネルヘッダー
In the above figure, the first nibble is set to 0001b to indicate a control channel associated with a PW, LSP, or Section. The Version field is set to 0, as specified in RFC 4385 [RFC4385]. Bits 8 to 15 of the ACH are reserved and MUST be set to 0 and ignored on reception. Bits 16 to 31 are used to encode the possible Channel Types. This 16-bit field is in network byte order.
上記の図では、最初のニブルはPW、LSP、またはセクションに関連する制御チャネルを示すために、0001Bに設定されています。 RFC 4385 [RFC4385]で指定されるようにバージョンフィールドは、0に設定されています。 ACHの15ビット8が予約され、0に設定され、受信時には無視されなければなりません。ビット16〜31は、可能なチャネルタイプを符号化するために使用されます。この16ビットのフィールドは、ネットワークバイト順です。
Note that VCCV [RFC5085] also includes mechanisms for negotiating the Control Channel and Connectivity Verification (i.e., OAM function) Types between PEs. It is anticipated that similar mechanisms will be applied to LSPs. Such application will require further specification. However, such specification is beyond the scope of this document.
VCCV [RFC5085]はまた、PE間制御チャネルと接続検証（すなわち、OAM機能）タイプを交渉するための機構を含むことに留意されたいです。同様のメカニズムがのLSPに適用されることが予想されます。このようなアプリケーションでは、さらに仕様が必要になります。しかし、そのような仕様は、このドキュメントの範囲を超えています。
The G-ACh MUST NOT be used to transport user traffic.
G-ACHは、ユーザトラフィックを転送するために使用してはいけません。
The Channel Type field indicates the type of message carried on the associated control channel, e.g., IPv4 or IPv6 if IP demultiplexing is used for messages sent on the associated control channel, or OAM or other maintenance function if IP demultiplexing is not used. For associated control channel packets where IP is not used as the multiplexer, the Channel Type indicates the specific protocol carried in the associated control channel.
チャネル型の電界IP分離を使用しない場合、IP分離は付随制御チャネル上で送信されたメッセージ、またはOAM又は他のメンテナンス機能のために使用される場合、関連する制御チャネル上で伝えられるメッセージの種類、例えば、IPv4またはIPv6を示します。 IPはマルチプレクサとして使用されていない付随制御チャネルパケットのために、チャネルタイプは、関連する制御チャネルで搬送される特定のプロトコルを示します。
Values for the Channel Type field currently used for VCCV are specified elsewhere, e.g., in RFC 4446 [RFC4446] and RFC 4385 [RFC4385]. Additional Channel Type values and the associated
現在VCCVに使用されるチャネル型フィールドの値は、RFC 4446 [RFC4446]及びRFC 4385 [RFC4385]に、例えば、他の場所で規定されています。追加のチャネルタイプの値と関連します
maintenance functionality will be defined in other documents. Each document, specifying a protocol solution relying on the ACH, MUST also specify the applicable Channel Type field value.
メンテナンス機能は、他のドキュメントで定義されます。 ACHに依存するプロトコル・ソリューションを指定する各文書は、また、該当するチャンネル型のフィールド値を指定する必要があります。
Note that these values are allocated from the PW Associated Channel Type registry [RFC4446], but this document modifies the existing policy to accommodate a level of experimentation. See Section 10 for further details.
これらの値はPW関連するチャネルタイプレジストリ[RFC4446]から割り当てられますが、この文書は、実験のレベルに対応するために既存のポリシーを変更することに注意してください。詳細については、セクション10を参照してください。
In some applications of the generalized associated control channel, it is necessary to include one or more ACH TLVs to provide additional context information to the G-ACh packet. One use of these ACH TLVs might be to identify the source and/or intended destination of the associated channel message. However, the use of this construct is not limited to providing addressing information nor is the applicability restricted to transport network applications.
一般付随制御チャネルのいくつかの用途では、G-ACHパケットに追加のコンテキスト情報を提供するために、1つ以上のACH TLVを含める必要があります。これらACHのTLVの使用は、関連するチャネルメッセージのソース及び/又は意図された宛先を識別するかもしれません。しかし、この構築物の使用は、アドレス情報を提供することに限定されないでもネットワークアプリケーションを転送するために制限された適用性があります。
If the G-ACh message MAY be preceded by one or more ACH TLVs, then this MUST be explicitly specified in the definition of an ACH Channel Type. If the ACH Channel Type definition does state that one or more ACH TLVs MAY precede the G-ACh message, an ACH TLV Header MUST follow the ACH. If no ACH TLVs are required in a specific associated channel packet, but the Channel Type nevertheless defines that ACH TLVs MAY be used, an ACH TLV Header MUST be present but with a length field set to zero to indicate that no ACH TLV follow this header.
G-AChのメッセージが1つまたは複数のACHのTLVが先行する可能性がある場合、これは明示的にACHチャネルタイプの定義で指定する必要があります。 ACHチャネルタイプの定義は、1つまたは複数のACHのTLVはG-AChのメッセージに先行してもよいという状態を行う場合は、ACH TLVヘッダーはACHに従わなければなりません。何ACHのTLVは、特定の関連するチャネルパケットに必要とされないが、チャネルタイプは、それにもかかわらず、ACHのTLVを使用することができることを規定している場合、ACH TLVヘッダが存在しなければならないが、ゼロに設定され、長さフィールドに何ACH TLVは、このヘッダに従っていないことを示すために。
If an ACH Channel Type specification does not explicitly specify that ACH TLVs MAY be used, then the ACH TLV Header MUST NOT be used.
ACHチャネル型の仕様は明示的にACHのTLVを使用することができることが指定されていない場合は、ACH TLVヘッダーを使用してはいけません。
This section defines and describes the structure of an ACH payload when an ACH TLV Header is present.
ACH TLVヘッダが存在する場合、このセクションでは、ACHペイロードの構造を定義し、記述する。
The following figure (Figure 2) shows the structure of a G-ACh packet payload.
次の図（図2）は、G-ACHパケットペイロードの構造を示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ zero or more ACH TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: G-ACh Packet Payload
図2：G-ACHパケットペイロード
The ACH TLV Header defines the length of the set of ACH TLVs that follow.
ACH TLVヘッダは、以下のACHのTLVの集合の長さを規定します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ACH TLV Header
図3：ACH TLVヘッダー
The Length field specifies the length in octets of the complete set of TLVs including sub-TLVs that follow the ACH TLV Header. A length of zero indicates that no ACH TLV follow this header. Note that no padding is required for the set of ACH TLVs.
Lengthフィールドは、ACH TLVヘッダーに続くサブTLVを含むのTLVの完全なセットのオクテットの長さを指定します。ゼロの長さにはACH TLVは、このヘッダに従っていないことを示しています。パディングは、ACHのTLVのセットのために必要とされないことに注意してください。
The Reserved field is for future use and MUST be set to zero on transmission and ignored on reception.
予約フィールドは、将来の使用のためのものであり、送信時にゼロに設定され、受信時には無視されなければなりません。
ACH TLVs MAY follow an ACH TLV Header. The structure of ACH TLVs is defined and described in this section.
ACHのTLVは、ACH TLVヘッダーに従うことができます。 ACHのTLVの構造が定義され、このセクションで説明されています。
An ACH TLV consists of a 16-bit Type field, followed by a 16-bit Length field that specifies the number of octets of the Value field, which follows the Length field. This 32-bit word is followed by zero or more octets of Value information. The format and semantics of the Value information are defined by the TLV Type as recorded in the TLV
ACH TLVは、長さフィールドの後に続く値フィールドのオクテット数を指定する16ビットの長さフィールドに続く16ビットのタイプフィールドからなります。この32ビット・ワードは、値情報のゼロ以上のオクテットが続きます。 TLVに記録されている価値情報のフォーマット及びセマンティクスはTLVタイプによって定義されます
Type registry. See Section 10 for further details. Note that the Value field of ACH TLVs MAY contain sub-TLVs. Note that no padding is required for individual TLVs or sub-TLVs.
タイプレジストリ。詳細については、セクション10を参照してください。 ACHのTLVのValueフィールドはサブTLVを含むことができることに注意してください。パディングは、個々のTLVまたはサブTLVのために必要とされないことに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Value ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ACH TLV Format
図4：ACH TLVフォーマット
Generalizing the associated control channel mechanism to LSPs and Sections also requires a method to identify that a packet contains an ACH followed by a non-service payload. This document specifies that a label is used for that purpose and calls this special label the G-ACh Label (GAL). One of the reserved label values defined in RFC 3032 [RFC3032] is assigned for this purpose. IANA assigned the value 13 to the GAL.
LSPとセクションに関連する制御チャネルメカニズムを一般化すると、パケットは、非サービス・ペイロードが続くACHが含まれていることを識別するための方法を必要とします。このドキュメントでは、ラベルは、その目的のために使用され、G-AChのラベル（GAL）この特別なラベルを呼び出していることを指定します。 RFC 3032 [RFC3032]で定義された予約ラベル値の一つは、この目的のために割り当てられています。 IANAは、GALに値13を割り当て。
The GAL provides an alert based exception mechanism to:
GALはにアラートベースの例外メカニズムを提供します。
o differentiate specific packets (i.e., G-ACh packets) from others, such as user-plane ones.
O、ユーザプレーンのものと他のものから特定のパケット（すなわち、G-ACHパケット）、差別。
o indicate that the ACH appears immediately after the bottom of the label stack.
O ACHは、ラベルスタックの最下部の直後に表示されていることを示しています。
The GAL MUST only be used where both these purposes apply.
両方のこれらの目的は、適用場所GALのみを使用しなければなりません。
RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms that enable an MPLS LSR to identify and process MPLS OAM packets when these are encapsulated in an IP header. These alert mechanisms are based, for example, on Time To Live (TTL) expiration and/or on the use of an IP destination address in the range of 127.0.0.0/8 or 0:0: 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively.
RFC 4379 [RFC4379]とBFD-MPLS [BFD-MPLSは、これらがIPヘッダでカプセル化されたとき、MPLS OAMパケットを識別し、処理するためのMPLS LSRを有効に警告メカニズムを定義します。 0：0：0：0 FFFFこれらのアラートメカニズムは、例えば、生存時間（TTL）の有効期限上及び/又は127.0.0.0/8または0の範囲内のIP宛先アドレスを使用することに、基づいています。それぞれ、IPv4およびIPv6用127.0.0.0/104。
These mechanisms are the default mechanisms for identifying MPLS OAM packets when encapsulated in an IP header although the mechanism defined in this document MAY also be used.
これらのメカニズムは、この文書で定義されたメカニズムを使用してもよいがIPヘッダでカプセル化されたときに、MPLS OAMパケットを識別するためのデフォルトのメカニズムです。
In MPLS-TP, the GAL MUST be used with packets on a G-ACh on LSPs, Concatenated Segments of LSPs, and with Sections, and MUST NOT be used with PWs. It MUST always be at the bottom of the label stack (i.e., S bit set to 1). However, in other MPLS environments, this document places no restrictions on where the GAL may appear within the label stack or its use with PWs. Where the GAL is at the bottom of the label stack (i.e., S bit set to 1), then it MUST always be followed by an ACH.
MPLS-TPにおいて、GALは、LSPの上のG-ACH上のパケット、LSPの連結セグメントと、及びセクションと一緒に使用する必要があり、およびPWで使用してはいけません。それは常に（すなわち、Sが1に設定ビット）のラベルスタックの底でなければなりません。しかし、他のMPLS環境では、このドキュメントの場所GALがラベルスタックやPWを持つその使用中に表示される場合がありますどこに制限はありません。 GALは、ラベルスタックの一番下にある場合（即ち、Sビットが1に設定）、それは常にACHが続かなければなりません。
The GAL MUST NOT appear in the label stack when transporting normal user-plane packets. Furthermore, when present, the GAL MUST NOT appear more than once in the label stack.
通常のユーザプレーンパケットを転送するときにGALがラベルスタックに現れてはいけません。さらに、存在する場合、GALは一度ラベルスタックでより多く見えてはいけません。
A receiving LSR, LER, or PE MUST NOT forward a G-ACh packet to another node based on the GAL label.
受信LSR、LER、またはPEは、GALラベルに基づいて他のノードにG-ACHパケットを転送してはいけません。
The Traffic Class (TC) field (formerly known as the EXP field) of the Label Stack Entry (LSE) containing the GAL follows the definition and processing rules specified and referenced in [RFC5462].
GALを含むラベルスタックエントリ（LSE）のトラフィッククラス（以前のEXPフィールドとして知られている）（TC）フィールドは、[RFC5462]で指定され、参照定義および処理規則に従います。
The Time-To-Live (TTL) field of the LSE that contains the GAL follows the definition and processing rules specified in [RFC3443].
GALが含まLSEのTime-To-Live（TTL）フィールドは、[RFC3443]で指定された定義および処理規則に従います。
The following figure (Figure 5) depicts two LERs (A and D) and two LSRs (B and C) for a given LSP that is established from A to D and switched in B and C.
次の図（図5）は、2つのLER（A及びD）とからDに確立され、B及びCに切り替えられる所定のLSPのための2つのLSR（B及びC）を示します
+---+ +---+ +---+ +---+
| A |-------------| B |-------------| C |-------------| D |
+---+ +---+ +---+ +---+
Figure 5: Maintenance over an LSP
図5：LSP上のメンテナンス
In this example, a G-ACh exists on the LSP that extends between LERs A and D, via LSRs B and C. Only A and D may initiate new G-ACh packets. A, B, C, and D may process and respond to G-ACh packets.
この例では、G-ACHは、新しいG-ACHパケットを開始することができるのLSR BおよびCのみ、AとDを介して、のLER AとDとの間に延在するLSP上に存在します。 、B、C、およびDは、プロセスおよびG-ACHパケットに応答することができます。
The following figure (Figure 6) depicts the format of an MPLS-TP G-ACh packet when used for an LSP.
LSPのために使用される場合、次の図（図6）は、MPLS-TP G-ACHパケットのフォーマットを示す図です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: G-ACh Packet Format for an LSP
図6：LSPのためのG-ACHパケットフォーマット
Note that it is possible that the LSP may be tunneled in another LSP (e.g., if an MPLS Tunnel exists between B and C), and as such other LSEs may be present in the label stack.
LSP（例えば、MPLSトンネルは、BとCとの間に存在する場合）、他のLSPにトンネリングすることができる、そのような他の小売り供給者はラベルスタック中に存在することができるようにすることが可能であることに留意されたいです。
To send a G-ACh message on the LSP associated control channel, the LER (A) generates a G-ACh message, to which it MAY prepend an ACH TLV Header and appropriate ACH TLVs. It then adds an ACH, onto which it pushes a GAL LSE. Finally, the LSP Label LSE is pushed onto the resulting packet.
LSP関連する制御チャネル上でG-ACHメッセージを送信するには、LER（A）は、ACH TLVヘッダ及び適切なACHのTLVを付加MAY先の、G-ACHメッセージを生成します。それはそれはGAL LSEをプッシュし、その上にACHを、追加します。最後に、LSPラベルLSEは、結果として得られるパケットにプッシュされます。
o The TTL field of the GAL LSE MUST be set to at least 1. The exact value of the TTL is application specific. See Section 4.2.1 for definition and processing rules.
GALのTTLフィールドoをLSEは、TTLの正確な値はアプリケーション固有であり、少なくとも1に設定しなければなりません。定義と処理のルールについては、セクション4.2.1を参照してください。
o The S bit of the GAL MUST be set according to its position in the label stack (see Section 4.2).
O GALのSビットがラベルスタック内の位置に応じて設定しなければなりません（セクション4.2を参照）。
o The setting of the TC field of the GAL is application specific. See Section 4.2.1 for definition and processing rules.
O GALのTCフィールドの設定は、アプリケーション固有です。定義と処理のルールについては、セクション4.2.1を参照してください。
LSRs MUST NOT modify the G-ACh message, the ACH or the GAL towards the targeted destination.
LSRはG-AChのメッセージ、ACHまたは対象先へのGALを変更してはいけません。
Note: This is because once a G-ACh packet has been sent on an LSP, no node has visibility of it unless the LSP label TTL expires or the GAL is exposed when the LSP label is popped. If this is at the targeted destination, for example, indicated by an address in an ACH TLV, then processing can proceed as specified below. If this is not the targeted destination, but the node has agreed to process packets on that ACH channel, then the processing applied to the packet is out of scope of this document.
注：G-ACHパケットがLSP上で送信された後、LSPラベルTTLが期限切れになるか、LSPラベルがポップされたときにGALが露出されていない限り、どのノードがそれの視認性を有していないためです。これはターゲット宛先である場合、以下に指定されるように、例えば、ACH TLVのアドレスによって示される、処理は進行することができます。これはターゲット宛先ではなく、ノードはそのACHチャネル上でパケットを処理することに同意した場合、パケットに適用される処理は、この文書の範囲外です。
Upon reception of the labeled packet, the targeted destination, after having checked both the LSP Label and GAL LSEs fields, SHOULD pass the whole packet to the appropriate processing entity.
標識されたパケットを受信すると、ターゲット宛先は、LSPラベルとGAL小売り供給者フィールドの両方を確認した後、適切な処理エンティティにパケット全体を通過させなければなりません。
The following figure (Figure 7) depicts an example of an MPLS Section.
次の図（図7）MPLS部の一例を示す図です。
+---+ +---+
| A |-------------| Z |
+---+ +---+
Figure 7: Maintenance over an MPLS Section
図7：MPLSセクションオーバーメンテナンス
With regard to the MPLS Section, a G-ACh exists between A and Z. Only A and Z can insert, extract, or process packets on this G-ACh.
MPLSセクションに関しては、G-ACHは、このG-ACH上で、抽出物、またはプロセス・パケットを挿入することができAおよびZ.のみAとZの間に存在します。
The following figure (Figure 8) depicts the format of a G-ACh packet when used for an MPLS Section. The GAL MAY provide the exception mechanism for a control channel in its own right without being associated with a specific LSP, thus providing maintenance-related communications across a specific link interconnecting two LSRs. In this case, the GAL is the only label in the stack.
次の図（図8）は、MPLSセクションに使用されるG-ACHパケットのフォーマットを示す図です。 GALは、したがって、2つのLSRを相互接続する特定のリンクを介してメンテナンス関連の通信を提供する、特定のLSPに関連付けされることなく、それ自体で制御チャネルの例外機構を提供することができます。この場合、GALは、スタック内のラベルだけです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GAL | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACH TLV Header (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ Zero or more ACH TLVs ~
~ (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ G-ACh message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: G-ACh Packet Format for an MPLS Section
図8：MPLSセクションのG-ACHパケットフォーマット
To send a G-ACh message on a control channel associated to the Section, the head-end LSR (A) of the Section generates a G-ACh message, to which it MAY prepend an ACH TLV Header and appropriate ACH TLVs. Next, the LSR adds an ACH. Finally, it pushes a GAL LSE.
節に関連する制御チャネル上でG-ACHメッセージを送信するために、セクションのヘッドエンドLSR（A）は、ACH TLVヘッダ及び適切なACHのTLVを付加し得るにG-ACHメッセージを生成します。次に、LSRは、ACHを追加します。最後に、GAL LSEをプッシュ。
o The TTL field of the GAL MUST be set to at least 1. The exact value of the TTL is application specific. See Section 4.2.1 for definition and processing rules.
oをGALのTTLフィールドは、TTLの正確な値はアプリケーション固有であり、少なくとも1に設定しなければなりません。定義と処理のルールについては、セクション4.2.1を参照してください。
o The S bit of the GAL MUST be set according to its position in the label stack. (see Section 4.2).
O GALのSビットはラベルスタック中のその位置に応じて設定しなければなりません。 （4.2節を参照してください）。
o The setting of the TC field of the GAL is application specific. See Section 4.2.1 for definition and processing rules.
O GALのTCフィールドの設定は、アプリケーション固有です。定義と処理のルールについては、セクション4.2.1を参照してください。
Intermediate nodes of the MPLS Section MUST NOT modify the G-ACh message, the ACH and the GAL towards the tail-end LSR (Z). Upon reception of the G-ACh packet, the tail-end LSR (Z), after having checked the GAL LSE fields, SHOULD pass the whole packet to the appropriate processing entity.
MPLSセクションの中間ノードは、G-ACHメッセージ、ACH及びテールエンドLSR（Z）に向かってGALを変更してはいけません。 G-ACHパケットを受信すると、末尾のLSR（Z）は、GAL LSEフィールドを確認した後、適切な処理エンティティにパケット全体を通過させなければなりません。
RFC 3429 [RFC3429] describes the assignment of one of the reserved label values, defined in RFC 3032 [RFC3032], to the "OAM Alert Label" that is used by user-plane MPLS OAM functions for the identification of MPLS OAM packets. The value of 14 is used for that purpose.
RFC 3429 [RFC3429]はMPLS OAMパケットの識別のためのユーザプレーンMPLS OAM機能によって使用される、「OAMの警告ラベル」に、RFC 3032で定義された予約ラベル値、[RFC3032]のいずれかの割り当てを記述する。 14の値は、その目的のために使用されます。
Both this document and RFC 3429 [RFC3429] therefore describe the assignment of reserved label values for similar purposes. The rationale for the assignment of a new reserved label can be summarized as follows:
本文書及びRFC 3429 [RFC3429]の両方は、従って、同様の目的のために予約されたラベル値の割り当てを記述する。次のように新しい予約ラベルの割り当てのための根拠を要約することができます。
o Unlike the mechanisms described and referenced in RFC 3429 [RFC3429], G-ACh messages will not reside immediately after the GAL but instead behind the ACH, which itself resides after the bottom of the label stack.
O [RFC3429] RFC 3429に記載され、参照機構とは異なり、G-ACHメッセージが直ちにGAL後ではなく、それ自体がラベルスタックの底後に存在するACH、背後に存在しないであろう。
o The set of maintenance functions potentially operated in the context of the G-ACh is wider than the set of OAM functions referenced in RFC 3429 [RFC3429].
O潜在G-ACHのコンテキストで動作保守機能のセットは、RFC 3429 [RFC3429]で参照されるOAM機能のセットよりも広いです。
o It has been reported that there are existing implementations and running deployments using the "OAM Alert Label" as described in RFC 3429 [RFC3429]. It is therefore not possible to modify the "OAM Alert Label" allocation, purpose, or usage. Nevertheless, it is RECOMMENDED that no further OAM extensions based on "OAM Alert Label" (Label 14) usage be specified or developed.
O RFC 3429 [RFC3429]で説明したように「OAMの警告ラベル」を使用して既存の実装と実行中の展開があることが報告されています。 「OAMの警告ラベル」割り当て、目的、または使用を変更することはできません。それにもかかわらず、「OAMの警告ラベル」（ラベル14）使用状況に基づいて、更なるOAM機能拡張が指定されていないか、開発を行うことを推奨します。
Procedures for handling a packet received with an invalid incoming label are specified in RFC 3031 [RFC3031].
無効着信ラベルで受信したパケットを処理するための手順は、RFC 3031 [RFC3031]で指定されています。
An LER, LSR, or PE MUST discard received associated channel packets on which all of the MPLS or PW labels have been popped if any one of the following conditions is true:
LERは、LSR、またはPEは、MPLS又はPWラベルの全ては、以下の条件のいずれかが真である場合にポップされた上で、関連するチャネル・パケットを受信捨てなければなりません。
o It is not capable of processing packets on the Channel Type indicated by the ACH of the received packet.
Oは、受信したパケットのACHで示されるチャンネルタイプの処理パケットすることができません。
o It has not, through means outside the scope of this document, indicated to the sending LSR, LER, or PE that it will process associated channel packets on the Channel Type indicated by the ACH of the received packet.
Oそれは、この文書の範囲外の手段を介して、それが受信したパケットのACHで示されるチャネルタイプに関連するチャネルのパケットを処理すること送信LSR、LER、またはPEに示されていません。
o The packet is received on an Experimental Channel Type that is locally disabled.
Oパケットがローカルで無効になっている実験的チャネルタイプで受信されます。
o If the ACH was indicated by the presence of a GAL, and the first nibble of the ACH of the received packet is not 0001b.
O ACHは、GALの存在によって示される、受信したパケットのACHの最初のニブルは0001Bないした場合。
o The ACH version is not recognized.
O ACHバージョンが認識されません。
In addition, the LER, LSR, or PE MAY increment an error counter and MAY also issue a system and/or Simple Network Management Protocol (SNMP) notification.
また、LER、LSR、またはPEはエラーカウンタをインクリメントすることができ、またシステムおよび/または簡易ネットワーク管理プロトコル（SNMP）通知を発行することができます。
The congestion considerations detailed in RFC 5085 [RFC5085] apply.
RFC 5085で詳述渋滞考慮事項[RFC5085]適用されます。
The editors would like to thank George Swallow, David Ward, and Rahul Aggarwal who made a major contribution to the development of this document.
編集者は、この文書の発展に多大な貢献をしたジョージ・ツバメ、デビッド・ウォード、そしてラウール・アガーウォールに感謝したいと思います。
George Swallow Cisco Systems Email: swallow@cisco.com
ジョージツバメシスコシステムズ電子メール：swallow@cisco.com
David Ward Cisco Systems Email: dward@cisco.com
デビッド・ウォードシスコシステムズ電子メール：dward@cisco.com
Rahul Aggarwal Juniper Networks Email: rahul@juniper.net
ラウール・アガーウォールジュニパーネットワークスのEメール：rahul@juniper.net
The editors gratefully acknowledge the contributions of Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau, and Siva Sivabalan.
編集者は感謝サミBoutros、イタロBUSI、マルク・Lasserre、リーフェンLevrau、およびシヴァシババランの貢献を認めます。
The authors would also like to thank Malcolm Betts, ITU-T Study Group 15, and all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the MPLS-TP Ad Hoc Team in ITU-T) involved in the definition and specification of the MPLS Transport Profile.
著者らはまた、マルコムベッツ、ITU-T研究グループ15、およびチームのすべてのメンバー（共同作業チーム、IETFでのMPLSの相互運用性設計チームとITU-TにおけるMPLS-TPアドホックチーム）関与を感謝したいと思いますMPLSトランスポートプロファイルの定義や仕様インチ
The security considerations for the associated control channel are described in RFC 4385 [RFC4385]. Further security considerations MUST be described in the relevant associated channel type specification.
付随制御チャネルのためのセキュリティ問題は、RFC 4385 [RFC4385]に記載されています。さらなるセキュリティの考慮事項は、関連する関連チャネル型明細書に記載されなければなりません。
RFC 5085 [RFC5085] provides data plane related security considerations. These also apply to a G-ACh, whether the alert mechanism uses a GAL or only an ACH.
RFC 5085 [RFC5085]は、データプレーンに関連するセキュリティ問題を提供します。これらはまた、警報機構がGALのみACHを使用するかどうか、G-ACHに適用されます。
IANA allocated label value 13 to the GAL from the pool of reserved labels in the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry.
IANAは、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）ラベルの値」レジストリ内の予約ラベルのプールからGALにラベル値13を割り当てられます。
Channel Types for the Associated Channel Header are allocated from the IANA "PW Associated Channel Type" registry [RFC4446]. The PW Associated Channel Type registry is currently allocated based on the IETF consensus process (termed "IETF Review" in [RFC5226]). This allocation process was chosen based on the consensus reached in the PWE3 working group that pseudowire associated channel mechanisms should be reviewed by the IETF and only those that are consistent with the PWE3 architecture and requirements should be allocated a code point.
関連するチャンネルヘッダーのためのチャネル・タイプは、IANA「PW関連するチャネルタイプ」レジストリ[RFC4446]から割り当てられます。 PW関連するチャネルタイプレジストリは、現在IETFコンセンサス・プロセスに基づいて割り当てられている（[RFC5226]で「IETFレビュー」と呼ばれます）。この割り当てプロセスは疑似回線関連するチャネル機構はIETFによって検討されるべきであるとのみPWE3アーキテクチャおよび要件と一致するものがコードポイントを割り当てなければならないPWE3ワーキンググループで到達コンセンサスに基づいて選択しました。
However, a requirement has emerged (see [OAM-REQ]) to allow for optimizations or extensions to OAM and other control protocols running in an associated channel to be experimented without resorting to the IETF standards process, by supporting experimental code points. This would prevent code points used for such functions from being used from the range allocated through the IETF standards and thus protects an installed base of equipment from potential inadvertent overloading of code points. In order to support this requirement, IANA has changed the code point allocation scheme for the PW Associated Channel Type be changed as follows:
しかし、要件は、実験的なコードポイントをサポートすることによって、IETF標準化プロセスに頼らずに実験するOAMと関連するチャネルで動作している他の制御プロトコルに最適化又は拡張を可能にするために、（[OAM-REQ]を参照）浮上しています。これは、IETF標準を通して割り当てられた範囲から使用されているから、そのような機能のために使用されるコードポイントを防止し、したがってコードポイントの潜在的な不注意による過負荷から機器のインストールベースを保護するであろう。この要件をサポートするために、IANAは、次のようにPW関連するチャネルタイプのコードポイント割り当て方式を変更する変更されました。
0 - 32751 : IETF Review
0から32751：IETFレビュー
32760 - 32767 : Experimental
実験：32767から32760
Code points in the experimental range MUST be used according to the guidelines of RFC 3692 [RFC3692]. Functions using experimental G-ACh code points MUST be disabled by default. The Channel Type value used for a given experimental OAM function MUST be configurable, and care MUST be taken to ensure that different OAM functions that are not inter-operable are configured to use different Channel Type values.
実験範囲内のコードポイントは、RFC 3692 [RFC3692]のガイドラインに従って使用しなければなりません。実験的なG-AChのコード・ポイントを使用した機能はデフォルトでは無効にする必要があります。与えられた実験的OAM機能のために使用されるチャネル型の値は設定していなければなりません、そして注意が相互動作可能でない異なるOAM機能は異なるチャネル型の値を使用するように構成されていることを保証するために注意しなければなりません。
The PW Associated Channel Type registry has been updated to include a column indicating whether the ACH is followed by a ACH TLV header (Yes/No). There are two ACH Channel Type code-points currently assigned and in both cases no ACH TLV header is used. Thus, the new format of the PW Channel Type registry is:
PW関連するチャネルタイプレジストリは、ACHはACH TLVヘッダ（はい/いいえ）が続いているか否かを示す列を含むように更新されました。そこに現在割り当てられた2つのACHチャネル型コードポイントであり、両方の場合において全くACH TLVヘッダが使用されません。したがって、PWチャネルタイプレジストリの新しい形式は次のとおりです。
Registry:
Value Description TLV Follows Reference
----- ---------------------------- ----------- ---------
0x21 ACH carries an IPv4 packet No [RFC4385]
0x57 ACH carries an IPv6 packet No [RFC4385]
Figure 9: PW Channel Type Registry
図9：PWチャネルタイプレジストリ
IANA created a new registry called the Associated Channel Header TLV Registry. The allocation policy for this registry is IETF review. This registry MUST record the following information. There are no initial entries.
IANAは、関連するチャンネルヘッダーTLVレジストリと呼ばれる新しいレジストリを作成しました。このレジストリの割り当てポリシーは、IETFレビューです。このレジストリには、以下の情報を記録しなければなりません。何の初期のエントリがありません。
Name Type Length Description Reference (octets)
名前タイプ長さ説明リファレンス（オクテット）
Figure 10: ACH TLV Registry
図10：ACH TLVレジストリ
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwalさん、P.とB. Akyol、 "（MPLS）ネットワークのマルチプロトコルラベルスイッチングにおける生存時間（TTL）処理"、RFC 3443、2003年1月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten氏、T.、 "役に立つと考えられ割り当て実験とテスト番号"、BCP 82、RFC 3692、2004年1月。
[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月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T.とC. Pignataro、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"、RFC 5085、2007年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]アンデション、L.およびR. Asatiは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ： "EXPトラフィッククラス "フィールド"、RFC 5462、2009年2月" フィールドに改名します"。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
[BFD-MPLS]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "MPLSのLSPについてBFD"、進歩、2008年6月に働いています。
[BFD-VCCV] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, May 2009.
[BFD-VCCV]ナドー、T.とC. Pignataro、 "双方向フォワーディング検出（BFD）スードワイヤ仮想回線接続性検証（VCCV）について"、進歩、2009年5月での作業。
[G805] International Telecommunication Union, "Generic Functional Architecture of Transport Networks", ITU-T G.805, March 2000.
[G805]国際電気通信連合、 "トランスポート・ネットワークの一般的な機能アーキテクチャ"、ITU-T G.805、2000年3月。
[MPLS-TP] Bocci, M., Bryant, S., and L. Levrau, "A Framework for MPLS in Transport Networks", Work in Progress, November 2008.
[MPLS-TP]ボッチ、M.、ブライアント、S.、およびL. Levrau、 "トランスポートネットワークにおけるMPLSのための枠組み"、進歩、2008年11月の作業。
[OAM-REQ] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for OAM in MPLS Transport Networks", Work in Progress, March 2009.
[OAM-REQ] Vigoureux、M.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "MPLS交通ネットワークにおけるOAMの要件"、進歩、2009年3月での作業。
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, November 2002.
[RFC3429]太田、H.、RFC 3429、2002年11月 "のアーキテクチャをマルチプロトコル・ラベル・スイッチング（MPLS）動作及び保守（OAM）機能のための 'OAMの警告ラベル' の割り当て"。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[TP-REQ] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "MPLS-TP Requirements", Work in Progress, May 2009.
[TP-REQ]ニーヴン、ジェンキンス、B.、編。、Brungard、D.、編、ベッツ、M.編、Sprecher、N.、およびS.上野、 "MPLS-TP要件"、仕事に進捗状況、2009年5月。
Authors' Addresses
著者のアドレス
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ UK
マシューボッチ（編集者）アルカテル・ルーセントボイジャープレイス、Shoppenhangers道路メイデンヘッド、バークスSL6 2PJ英国
EMail: matthew.bocci@alcatel-lucent.com
メールアドレス：matthew.bocci@alcatel-lucent.com
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay, 91620 France
マーティン・ヘイル（編集者）アルカテル・ルーセントルートヴィルジュNozay、フランス91620
EMail: martin.vigoureux@alcatel-lucent.com
メールアドレス：martin.vigoureux@alcatel-lucent.com
Stewart Bryant (editor) Cisco Systems
スチュワートブライアント（エディタ）シスコシステムズ
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com