[要約] RFC 5586は、MPLSネットワークでの汎用関連チャネル（G-ACh）の仕様を定義しています。G-AChは、MPLSパケットに関連情報を追加するための拡張機能であり、ネットワーク管理や制御プレーンのアプリケーションに使用されます。
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
MPLSジェネリック関連チャネル
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントは、MPLS擬似動物に加えて、MPLSラベルスイッチ付きパス（LSP）およびMPLSセクションに関連付けられているコントロールチャネルの実現を可能にするため、擬似ワイヤ（PW）関連チャネルヘッダー（ACH）の適用性を一般的に一般化します。ラベルスタック内のこの関連チャネルヘッダーの存在を識別するために、このドキュメントは、ラベルベースの例外メカニズムとして使用される一般的な関連チャネルラベル（GAL）に予約されたMPLSラベル値の1つを割り当てます。
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.
障害検出、診断、メンテナンス、および擬似ワイヤ（PW）およびラベルスイッチ付きパス（LSP）のその他の機能に使用できる運用、管理、およびメンテナンス（OAM）メカニズムが必要です。これらの機能は、LSPまたはPWの経路に沿って、任意の2つのラベルエッジルーター（LERS）/ラベルスイッチングルーター（LSRS）またはプロバイダーエッジルーター（T-PE）/スイッチングプロバイダーエッジルーター（S-PE）で使用できます。それぞれ[MPLS-TP]。これらの機能の一部は、仮想回路接続検証（VCCV）[RFC5085]、MPLS LSPS（BFD-MPLS）[BFD-MPLS]の双方向転送検出などの既存のツールを使用してサポートできます。VCCV [BFD-VCCV]。ただし、特にMPLSネットワークがパケット輸送サービスと輸送ネットワーク操作に使用される場合、この一連のメンテナンス機能を強化するための要件が示されています[OAM-Req]。これらの機能の例には、パフォーマンス監視、自動保護スイッチング、管理およびシグナリング通信チャネルのサポートが含まれます。これらのツールは、MPLS PWS、MPLS LSP、およびMPLSセクションで本質的に同じ方法（運用の観点から）に適用できる必要があります。また、パケットスイッチネットワーク（PSN）ルーティングやユーザートラフィックに依存しないように、PWまたはLSPでバンド内で操作する必要があり、動的コントロールプレーンの機能に依存してはなりません。
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]は、関連するチャネルヘッダー（ACH）を使用して、PWのエンドポイント間にPW関連のコントロールチャネルを提供し、OAMおよびその他のコントロールメッセージを交換できます。このドキュメントは、ACHの適用性を一般的に一般化して、同じ関連する制御チャネルメカニズムをセクション、LSP、およびPWSに使用できるようにします。したがって、一般化された関連する制御チャネルは、一般的な関連チャネル（G-ach）として知られています。RFC 4385 [RFC4385]で指定されているACHは、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.
ACHのLSPおよびセクションへの適用性を一般化するには、パケットにACHが含まれていて非サービスペイロードが含まれていることを識別する方法も必要です。したがって、このドキュメントは、LSPまたはセクションで受信するパケットが関連する制御チャネルに属することをLSR（またはLER）に通知するのに役立つラベルベースの例外メカニズムも定義します。その目的に使用されるラベルは、MPLS予約ラベルの1つであり、GAL（G-achラベル）と呼ばれます。GALメカニズムは、LSPSおよび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]は、MPLS LSRがIPヘッダーにカプセル化されているときにMPLS OAMパケットを識別および処理できるようにするアラートメカニズムを定義します。これらのアラートメカニズムは、たとえば、期限切れ（TTL）の有効期限に基づいています。IPv4とIPv6の場合、それぞれ127.0.0.0/104。これらのメカニズムは、IPヘッダーにカプセル化されたときにMPLS OAMパケットを識別するためのデフォルトのメカニズムです。ただし、特にIPベースのDemultiplexingを使用できない場合、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は一般的にMPLと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およびセクションに適用できる一般的な制御チャネルメカニズムを作成します。また、トランスポートコンテキストでのPWSのACHの使用を正規化し、ラベルスタックの下部の後にACHの存在をLERS/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.
このドキュメントでは、関連する制御チャネル機能が、LERS/LSRまたはPES間でどのように信号または交渉されるかを定義することも、さまざまな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-CACHパケット：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つのレイヤーネットワークの1つとして定義していることに注意してください。他のレイヤーネットワークは、物理メディアレイヤーネットワークです。
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 Type 2は、MPLSルーターアラートラベルを使用してVCCVパケットを示し、「バンド外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.
以前はPWSに限定されていたACHの使用は、LSPおよびセクションにも適用されるように一般化されています。PWSの場合、ACHを使用して関連する制御チャネルを実現する場合、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.
上記の図では、最初のニブルは0001bに設定されており、PW、LSP、またはセクションに関連するコントロールチャネルを示しています。RFC 4385 [RFC4385]で指定されているように、バージョンフィールドは0に設定されています。AChの8〜15個は予約されており、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]には、PES間の制御チャネルと接続の検証（つまり、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.
チャネルタイプフィールドは、関連するコントロールチャネルまたはIPv6の場合に関連するコントロールチャネルに掲載されたメッセージのタイプを示します。IPDemultiplexingが関連するコントロールチャネルで送信されたメッセージに使用される場合、またはIP Demultiplexingが使用されていない場合はOAMまたはその他のメンテナンス機能を示します。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 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.
現在VCCVに使用されているチャネルタイプフィールドの値は、たとえばRFC 4446 [RFC4446]およびRFC 4385 [RFC4385]で他の場所で指定されています。追加のチャネルタイプ値と関連するメンテナンス機能は、他のドキュメントで定義されます。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の1つの使用は、関連するチャネルメッセージのソースおよび/または目的の宛先を識別することです。ただし、このコンストラクトの使用は、アドレス指定情報を提供することに限定されません。また、輸送ネットワークアプリケーションに適用可能性が制限されていません。
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ヘッダーが存在する必要がありますが、このヘッダーに従うことがないことを示すために長さのフィールドがゼロに設定されている必要があります。。
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.
長さフィールドは、ACH TLVヘッダーに続くサブTLVを含む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 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.
ACH TLVは、16ビットタイプフィールドで構成され、その後、値フィールドのオクテットの数を指定する16ビットの長さフィールドが続き、長さフィールドに従います。この32ビットの単語の後に、値情報のゼロ以上のオクテットが続きます。値情報の形式とセマンティクスは、TLV型レジストリに記録されているTLVタイプによって定義されます。詳細については、セクション10を参照してください。ACH TLVの値フィールドにはサブ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]で定義されている予約されたラベル値の1つは、この目的のために割り当てられています。イアナは値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]は、MPLS LSRがIPヘッダーにカプセル化されているときにMPLS OAMパケットを識別および処理できるようにするアラートメカニズムを定義します。これらのアラートメカニズムは、たとえば、期限切れ（TTL）の有効期限に基づいています。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の連結セグメント、およびセクションでパケットを使用して使用する必要があり、PWSで使用してはなりません。常にラベルスタックの下部にある必要があります（つまり、sビットが1に設定されています）。ただし、他のMPLS環境では、このドキュメントは、ラベルスタック内のGALがどこに表示されるか、またはPWSでの使用を制限しません。ギャルがラベルスタックの下部にある場合（つまり、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）のトラフィッククラス（TC）フィールド（以前はEXPフィールドとして知られていました）は、[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の時間（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）は、AからDからDに確立され、BとCで切り替えられた2つのレール（AとD）と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.
この例では、LSRS BとCを介して、LERS AとDの間に伸びるLSPにG-CHACHが存在します。AとDのみが新しいG-CHACHパケットを開始できます。A、B、C、およびDは、G-CHACHパケットを処理および応答する場合があります。
The following figure (Figure 6) depicts the format of an MPLS-TP G-ACh packet when used for an LSP.
次の図（図6）は、LSPに使用した場合の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が別のLSPでトンネリングされる可能性があることに注意してください（たとえば、BとCの間にMPLSトンネルが存在する場合）、そのため他のLSEがラベルスタックに存在する可能性があることに注意してください。
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）がG-achメッセージを生成し、ACH TLVヘッダーと適切なACH TLVを準備します。次に、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.
o GALLSEのTTLフィールドは、少なくとも1に設定する必要があります。TTLの正確な値はアプリケーション固有です。定義および処理ルールについては、セクション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のビットは、ラベルスタックの位置に従って設定する必要があります（セクション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ラベルとGALLSESフィールドの両方をチェックした後、ターゲットの宛先は、パケット全体を適切な処理エンティティに渡す必要があります。
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セクションに関しては、AとZの間にG-achが存在します。AとZのみが、このG-achにパケットを挿入、抽出、または処理できます。
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は、特定のLSPに関連することなく、制御チャネルの例外メカニズムを提供する可能性があり、2つのLSRを相互接続する特定のリンク全体でメンテナンス関連の通信を提供します。この場合、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）がG-achメッセージを生成し、ACH TLVヘッダーと適切なACH TLVを前提とする可能性があります。次に、LSRはAChを追加します。最後に、それはギャルを押します。
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フィールドは、少なくとも1に設定する必要があります。TTLの正確な値はアプリケーション固有です。定義および処理ルールについては、セクション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のビットは、ラベルスタックの位置に従って設定する必要があります。（セクション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とGalをテールエンドLSR（z）に向けて変更してはなりません。G-achパケットを受信すると、テールエンドLSR（z）は、GALLSEフィールドをチェックした後、パケット全体を適切な処理エンティティに渡す必要があります。
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]は、RFC 3032 [RFC3032]で定義されている予約されたラベル値の1つの割り当て、MPLS OAMパケットの識別のためにユーザープレーンMPLS OAM関数が使用する「OAMアラートラベル」に割り当てられています。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 RFC 3429 [RFC3429]で説明および参照されるメカニズムとは異なり、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 このドキュメントの範囲外の手段を通じて、送信LSR、LER、またはPEに示されていることは、受信したパケットのACHによって示されるチャネルタイプで関連するチャネルパケットを処理することを示していません。
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
George Swallow Cisco Systems Email：swallow@cisco.com
David Ward Cisco Systems Email: dward@cisco.com
David Ward Cisco Systems Email：dward@cisco.com
Rahul Aggarwal Juniper Networks Email: rahul@juniper.net
Rahul Aggarwal Juniper Networksメール：rahul@juniper.net
The editors gratefully acknowledge the contributions of Sami Boutros, Italo Busi, Marc Lasserre, Lieven Levrau, and Siva Sivabalan.
編集者は、Sami Boutros、Italo Busi、Marc Lasserre、Lieven Levrau、Siva Sivabalanの貢献に感謝しています。
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.
著者はまた、Malcolm Betts、ITU-T Study Group 15、およびチームのすべてのメンバー（共同作業チーム、IETFのMPLS Interoperability Design Team、ITU-TのMPLS-TP AD HOCチーム）に感謝したいと思います。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をGALに割り当てました。レジストリ。
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レビュー」と呼ばれる）に基づいて割り当てられています。この割り当てプロセスは、PWE3ワーキンググループで到達したコンセンサスに基づいて選択されました。これは、IETFによって擬似されたチャネルメカニズムがレビューされるべきであり、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
32760-32767：実験
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:
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介して使用するコントロールワード」、RFC 4385、2006年2月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）：Pseudowiresの制御チャネル」、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] Andersson、L。およびR. Asati、「マルチプロトコルラベルスイッチング（MPLS）ラベルスタックエントリ：「Exp」フィールドは、「トラフィッククラス」フィールドに改名されました。RFC5462、2009年2月。
[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
[BFD-MPLS] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLS LSPSの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] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）の双方向転送検出（BFD）」、2009年5月の作業。
[G805] International Telecommunication Union, "Generic Functional Architecture of Transport Networks", ITU-T G.805, March 2000.
[G805] International Telecommunication Union、「輸送ネットワークの一般的な機能アーキテクチャ」、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] Bocci、M.、Bryant、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.、ed。、Ward、D.、ed。、およびM. Betts、ed。、「MPLS Transport Networksの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] OHTA、H。、「マルチプロトコルラベルスイッチングアーキテクチャ（MPLS）操作およびメンテナンス（OAM）機能のための「OAMアラートラベル」の割り当て」、2002年11月、RFC 3429。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[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] Niven-Jenkins、B.、ed。、Brungard、D.、Ed。、Betts、M.、ed。、Sprecher、N.、およびS. Ueno、「MPLS-TP要件」、作業進捗、2009年5月。
Authors' Addresses
著者のアドレス
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ UK
Matthew Bocci（編集者）Alcatel-Lucent Voyager Place、Shoppenhangers Road Maidenhead、Berks SL6 2PJ UK
EMail: matthew.bocci@alcatel-lucent.com
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay, 91620 France
Martin Vigoureux（編集者）Alcatel-Lucent Route De Villejust Nozay、91620 France
EMail: martin.vigoureux@alcatel-lucent.com
Stewart Bryant (editor) Cisco Systems
スチュワートブライアント（編集者）シスコシステム
EMail: stbryant@cisco.com