[要約] RFC 5718は、MPLS Transport Profile（MPLS-TP）のためのインバンドデータ通信ネットワークに関する要約です。このRFCの目的は、MPLS-TPネットワークでのデータ通信のための効果的な方法を提供することです。
Internet Engineering Task Force (IETF) D. Beller
Request for Comments: 5718 Alcatel-Lucent
Category: Standards Track A. Farrel
ISSN: 2070-1721 Old Dog Consulting
January 2010
An In-Band Data Communication Network For the MPLS Transport Profile
MPLS輸送プロファイルのバンドデータ通信ネットワーク
Abstract
概要
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
ジェネリック関連チャネル（G-CHACH）は、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチ付きパス（LSP）に関連付けられているコントロール/通信チャネルの実現を可能にするために、擬似ワイヤ（PW）関連制御チャネルの一般化として定義されています。、MPLS PWS、MPLS LSPセグメント、および隣接するMPLS対応デバイス間のMPLSセクション。
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based on MPLS packet switching technology.
MPLSトランスポートプロファイル（MPLS-TP）は、MPLSツールキットの要素を識別するMPLSアーキテクチャのプロファイルであり、MPLSパケットスイッチングテクノロジーに基づいてキャリアグレードのパケットトランスポートネットワークを構築することができます。
This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node.
このドキュメントでは、G-achを使用して、管理通信ネットワーク（MCN）とシグナリング通信ネットワーク（SCN）の一部を形成するインフラストラクチャを提供する方法について説明します。まとめて、MCNとSCNはデータ通信ネットワーク（DCN）と呼ばれる場合があります。このドキュメントでは、MCNおよびSCNメッセージがMPLS-TPノードの管理またはシグナリング/ルーティングコントロールプレーンコンポーネントへの配信のために、G-achにカプセル化され、g-achに携帯され、脱線している方法について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5718.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5718で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
The associated channel header (ACH) is specified in [RFC4385]. It is a packet header format for use on pseudowires (PWs) in order to identify packets used for Operations, Administration, and Maintenance (OAM) and similar functions.
関連するチャネルヘッダー（ACh）は[RFC4385]で指定されています。これは、操作、管理、メンテナンス（OAM）および同様の機能に使用されるパケットを特定するために、Pseudowires（PWS）で使用するパケットヘッダー形式です。
The use of the ACH is generalized in [RFC5586] and can be applied on any Multiprotocol Label Switching (MPLS) Label Switching Path (LSP). This is referred to as the Generic Associated Channel (G-ACh) and is intended to create a control/management communication channel associated with the LSP that can be used to carry packets used for OAM and similar functions (e.g., control/management plane messages).
ACHの使用は[RFC5586]で一般化されており、マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングパス（LSP）に適用できます。これは、汎用関連チャネル（G-ach）と呼ばれ、OAMおよび同様の機能に使用されるパケットを運ぶために使用できるLSPに関連付けられたコントロール/管理通信チャネルを作成することを目的としています（例：コントロール/管理プレーンメッセージメッセージ）。
The purpose of a packet carried on the G-ACh is indicated by the value carried by the Channel Type field of the ACH and a registry of values is maintained by IANA ([RFC4446] and [RFC4385]). The ACH is referred to in this document as the G-ACh header.
G-achに携帯されるパケットの目的は、AChのチャネルタイプフィールドによって伝達される値によって示され、値のレジストリはIANA（[RFC4446]および[RFC4385]）によって維持されます。ACHは、このドキュメントでG-achヘッダーと呼ばれます。
The MPLS transport profile (MPLS-TP) is described in [MPLS-TP] and in [RFC5654]. MPLS-TP is the application of MPLS to construct a packet transport network. It constitutes a profile of MPLS that enables operational models typical in transport networks, which includes additional OAM, survivability, and other maintenance functions not previously supported by MPLS.
MPLS輸送プロファイル（MPLS-TP）は、[MPLS-TP]および[RFC5654]で説明されています。MPLS-TPは、Packet Transport Networkを構築するためのMPLSの適用です。輸送ネットワークで典型的な運用モデルを可能にするMPLSのプロファイルを構成します。これには、追加のOAM、生存性、および以前にMPLSでサポートされていなかったその他のメンテナンス機能が含まれます。
Label Switching Routers (LSRs) in MPLS networks may be operated using management protocols or control plane protocols. Messaging in these protocols is normally achieved using IP packets exchanged over IP-capable interfaces. However, some nodes in MPLS-TP networks may be constructed without support for direct IP encapsulation on their line-side interfaces and without access to an out-of-fiber data communication network. In order that such nodes can communicate using management plane or control plane protocols, channels must be provided, and the only available mechanism is to use an MPLS label.
MPLSネットワークのラベルスイッチングルーター（LSR）は、管理プロトコルまたはコントロールプレーンプロトコルを使用して操作できます。これらのプロトコルのメッセージングは、通常、IP対応インターフェイスを介して交換されたIPパケットを使用して達成されます。ただし、MPLS-TPネットワークの一部のノードは、ラインサイドインターフェイスでの直接IPカプセル化をサポートせずに、およびファイバー外データ通信ネットワークにアクセスすることなく構築できます。このようなノードが管理プレーンまたはコントロールプレーンのプロトコルを使用して通信できるように、チャネルを提供する必要があり、唯一の利用可能なメカニズムはMPLSラベルを使用することです。
The G-ACh provides a suitable mechanism for this purpose, and this document defines processes and procedures to allow the G-ACh to be used to build a Management Communication Network (MCN) and a Signaling Communication Network (SCN), together known as the Data Communication Network (DCN) [G.7712].
G-achはこの目的に適したメカニズムを提供し、このドキュメントは、G-achを使用して管理通信ネットワーク（MCN）とシグナリング通信ネットワーク（SCN）を構築するために使用できるようにするプロセスと手順を定義します。データ通信ネットワーク（DCN）[G.7712]。
It should be noted that the use of the G-ACh to provide connectivity for the DCN is intended for use only where the MPLS-TP network is not capable of encapsulating or delivering native DCN messages.
DCNの接続を提供するためのG-achの使用は、MPLS-TPネットワークがネイティブDCNメッセージをカプセル化または配信できない場合にのみ使用することを目的としていることに注意する必要があります。
The requirements presented in this section are based on those communicated to the IETF by the ITU-T.
このセクションで提示されている要件は、ITU-TによってIETFに伝えられた要件に基づいています。
1. A packet-encapsulation mechanism must be provided to support the transport of MCN and SCN packets over the G-ACh.
1. G-ach上のMCNおよびSCNパケットの輸送をサポートするために、パケットカプセル化メカニズムを提供する必要があります。
2. The G-ACh carrying the MCN and SCN packets shall support the following application scenarios:
2. MCNおよびSCNパケットを運ぶG-achは、次のアプリケーションシナリオをサポートするものとします。
a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when the server layer does not provide a Management Communication Channel (MCC) or a Signalling Communication Channel (SCC)).
a. G-CHACHは、2つの隣接するMPLS-TPノード（サーバーレイヤーが管理通信チャネル（MCC）またはシグナリング通信チャネル（SCC）を提供しない場合に使用されます）を相互に接続します。
b. The G-ACh is carried by an MPLS-TP tunnel that traverses another operator's domain (the carrier's carrier scenario).
b. G-achは、別のオペレーターのドメイン（キャリアのキャリアシナリオ）を横断するMPLS-TPトンネルによって運ばれます。
3. The G-ACh shall provide two independent channels: an MCC to build the MCN and an SCC to build the SCN. The G-ACh packet header shall indicate whether the packet is an MCC or an SCC packet in order to forward it to the management or control plane application for processing. This facilitates easy demultiplexing of control and management traffic from the DCN, and enables separate or overlapping address spaces and duplicate protocol instances in the management and control planes.
3. G-achは、MCNを構築するMCCとSCCを構築するMCCの2つの独立したチャネルを提供するものとします。G-achパケットヘッダーは、パケットがMCCであるか、SCCパケットであるかを示して、処理のために管理プレーンアプリケーションまたは制御プレーンのアプリケーションに転送する必要があります。これにより、DCNからの制御および管理トラフィックの容易な反転を容易にし、管理および制御プレーンの個別または重複するアドレススペースと複製プロトコルインスタンスを可能にします。
4. The channel-separation mechanism shall not preclude the use of separate rate limiters and traffic-shaping functions for each channel (MCC and SCC), ensuring that the flows do not exceed their assigned traffic profiles. The rate limiters and traffic shapers are outside the scope of the MCC and SCC definitions.
4. チャネル分離メカニズムは、各チャネル（MCCおよびSCC）の個別のレートリミッターとトラフィック形成機能の使用を排除してはなりません。これにより、フローが割り当てられたトラフィックプロファイルを超えないようにします。レートリミッターとトラフィックシェイパーは、MCCおよびSCCの定義の範囲外です。
5. The G-ACh that carries the MCC and SCC shall be capable of carrying different OSI layer 3 (network layer) PDUs. These shall include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC packet shall indicate which layer 3 PDU is contained in the payload field of the packet such that the packet can be delivered to the related layer 3 process within the management and control plane application, respectively, for further processing.
5. MCCおよびSCCを運ぶG-CHACHは、異なるOSIレイヤー3（ネットワークレイヤー）PDUを運ぶことができます。これらには、IPv4、IPv6、およびOSI PDUSが含まれます。MCC/SCCパケットのG-achヘッダーは、パケットのペイロードフィールドに含まれるレイヤー3 PDUが、パケットを管理および制御プレーンアプリケーション内の関連レイヤー3プロセスにそれぞれ配信できるようにする必要があります。さらなる処理。
6. The G-ACh is not required to provide specific security mechanisms. However, the management or control plane protocols that operate over the MCC or SCC are required to provide adequate security mechanisms in order to not be susceptible to security attacks.
6. G-achは、特定のセキュリティメカニズムを提供するために必要ありません。ただし、MCCまたはSCCを介して動作する管理または制御プレーンのプロトコルは、セキュリティ攻撃の影響を受けないために適切なセキュリティメカニズムを提供する必要があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC-2119 [RFC2119]に記載されているように解釈される。
Figure 1 depicts the format of an MCC/SCC packet that is sent on the G-ACh. The Channel Type field indicates the function of the ACH message and so, to send an MCC/SCC packet on the G-ACh, the MCC/SCC message is prepended with an ACH with the Channel Type set to indicate that the message is an MCC or SCC message. The ACH MUST NOT include the ACH TLV Header [RFC5586], meaning that no ACH TLVs can be included in the message. A two-byte Protocol Identifier (PID) field indicates the protocol type of the payload DCN message.
図1は、G-achに送信されるMCC/SCCパケットの形式を示しています。チャネルタイプフィールドはACHメッセージの関数を示しているため、G-achにMCC/SCCパケットを送信するために、MCC/SCCメッセージは、メッセージがMCCであることを示すチャネルタイプが設定されたACHで準備されています。またはSCCメッセージ。ACHには、ACH TLVヘッダー[RFC5586]を含めてはなりません。つまり、ACH TLVをメッセージに含めることはできません。2バイトプロトコル識別子（PID）フィールドは、ペイロードDCNメッセージのプロトコルタイプを示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MCC/SCC Message |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: G-ACh MCC/SCC Packet
図1：G-ach MCC/SCCパケット
o The Channel Type field determines whether the message is an MCC or an SCC message. See Section 5 for the codepoint assignments.
o チャネルタイプフィールドは、メッセージがMCCかSCCメッセージであるかどうかを決定します。CodePointの割り当てについては、セクション5を参照してください。
o The presence of the PID field is deduced from the Channel Type value indicating MCC or SCC. The field contains an identifier of the payload protocol using the PPP protocol identifiers ([RFC1661], [RFC3818]).
o PIDフィールドの存在は、MCCまたはSCCを示すチャネルタイプの値から推定されます。このフィールドには、PPPプロトコル識別子（[RFC1661]、[RFC3818]）を使用したペイロードプロトコルの識別子が含まれています。
When the G-ACh sender receives an MCC message that is to be sent over the MCC, the sender creates the G-ACh header, sets the Channel Type field to MCC, fills in the PID to indicate the MCC layer 3 PDU type, and prepends the MCC message with the G-ACh header. The same procedure is applied when a control plane message is to be sent over the SCC. In this case, the sender sets the Channel Type field to SCC.
G-ach送信者がMCCを介して送信されるMCCメッセージを受信すると、送信者がG-achヘッダーを作成し、チャネルタイプフィールドをMCCに設定し、PIDを記入してMCCレイヤー3 PDUタイプを示し、G-achヘッダーを使用してMCCメッセージをプレイズします。コントロールプレーンのメッセージをSCCに送信する場合、同じ手順が適用されます。この場合、送信者はチャネルタイプフィールドをSCCに設定します。
If the G-ACh is associated with an MPLS section, the Generic Associated Channel Label (GAL) is added to the message as defined in [RFC5586]. The Time to Live (TTL) field MUST be set to 1, and the S-bit of the GAL MUST be set to 1.
G-achがMPLSセクションに関連付けられている場合、[RFC5586]で定義されているように、ジェネリック関連チャネルラベル（GAL）がメッセージに追加されます。ライブ（TTL）フィールドを1に設定する必要があり、GALのSビットを1に設定する必要があります。
If the G-ACh is associated with an LSP, the GAL is added to the packet and the LSP label is pushed on top of the GAL as defined in [RFC5586]. The TTL field of the GAL MUST be set to 1, and the S-bit of the GAL MUST be set to 1.
G-achがLSPに関連付けられている場合、GALはパケットに追加され、LSPラベルは[RFC5586]で定義されているようにGALの上に押し込まれます。GALのTTLフィールドは1に設定する必要があり、GALのSビットは1に設定する必要があります。
Note that packet processing for DCN packets in the G-ACh is, in common with all G-ACh MPLS packets, subject to the normal processing of the Traffic Class (TC) field of the MPLS header. This could be used to enable prioritization of different DCN packets.
G-achのDCNパケットのパケット処理は、すべてのG-ach MPLSパケットと一般的に、MPLSヘッダーのトラフィッククラス（TC）フィールドの通常の処理に対応することに注意してください。これを使用して、異なるDCNパケットの優先順位付けを可能にすることができます。
The DCN channel MUST NOT be used to transport user traffic and SHALL only be used to carry management or control plane messages. Procedures that ensure this (such as deep packet inspection) are outside the scope of this specification.
DCNチャネルは、ユーザートラフィックの輸送に使用してはなりません。管理または制御プレーンのメッセージを運ぶためにのみ使用するものとします。これを保証する手順（深いパケット検査など）は、この仕様の範囲外です。
When a receiver has received a packet on the G-ACh with the ACH Channel Type set to MCC or SCC, it SHALL look at the PID field. If the PID value is known by the receiver, it delivers the MCC/SCC message to the appropriate processing entity. If the PID value is unknown, the receiver SHALL silently discard the received packet, MAY increment a counter that records discarded or errored messages, and MAY log an event.
MCCまたはSCCに設定されたACHチャネルタイプを使用して、受信者がG-achのパケットを受け取った場合、PIDフィールドを調べます。PID値が受信機によってわかっている場合、MCC/SCCメッセージを適切な処理エンティティに配信します。PID値が不明な場合、受信者は受信したパケットを静かに破棄し、廃棄されたメッセージまたはエラー化されたメッセージを記録するカウンターを増分し、イベントを記録する場合があります。
It must be noted that according to [RFC5586], a receiver MUST NOT forward a GAL packet based on the GAL label as is normally the case for MPLS packets. If the GAL appears at the bottom of the label stack, it MUST be processed as described in the previous paragraph.
[RFC5586]によれば、通常はMPLSパケットの場合であるように、GALラベルに基づいてGALパケットを転送してはならないことに注意する必要があります。GALがラベルスタックの下部に表示される場合、前の段落で説明されているように処理する必要があります。
Note that there is no requirement for MPLS-TP devices to support IP or OSI forwarding in the fast (forwarding) path. Thus, if a message is received on the MCC or SCC and is not targeted to an address of the receiving MPLS-TP node, the packet might not be forwarded in the fast path. A node MAY apply layer 3 forwarding procedures in the slow or fast path and MAY discard or reject the message using the layer 3 protocol if it is unable to forward it. Thus, protocols making use of the DCN should make no assumptions about the forwarding capabilities unless they are determined a priori or through the use of a routing protocol. Furthermore, it is important that user data (i.e., data traffic) is not routed through the DCN, as this would potentially cause the traffic to be lost or delayed and might significantly congest the DCN.
MPLS-TPデバイスが高速（転送）パスでIPまたはOSI転送をサポートする必要はないことに注意してください。したがって、MCCまたはSCCでメッセージが受信され、受信MPLS-TPノードのアドレスをターゲットにされていない場合、パケットは高速パスに転送されない場合があります。ノードは、遅いパスまたは高速パスでレイヤー3転送手順を適用し、転送できない場合はレイヤー3プロトコルを使用してメッセージを破棄または拒否する場合があります。したがって、DCNを使用するプロトコルは、以前またはルーティングプロトコルの使用を通じて決定されない限り、転送能力について仮定しないはずです。さらに、ユーザーデータ（つまり、データトラフィック）がDCNを介してルーティングされないことが重要です。これにより、トラフィックが失われるか遅延が発生し、DCNが大幅に混雑する可能性があります。
Provider Edge nodes (PEs) may wish to set up PWs using a signaling protocol that uses remote adjacencies (such as LDP [RFC5036]). In the absence of an IP-based control plane network, these PEs MUST first set up an LSP tunnel across the MPLS-TP network. This tunnel can be used both to carry the PW once it has been set up and to provide a G-ACh-based DCN for control plane communications between the PEs.
プロバイダーエッジノード（PES）は、リモート隣接（LDP [RFC5036]など）を使用するシグナリングプロトコルを使用してPWSをセットアップすることをお勧めします。IPベースのコントロールプレーンネットワークがない場合、これらのPEは最初にMPLS-TPネットワーク全体にLSPトンネルを設定する必要があります。このトンネルは、PWがセットアップされたら、PWを携帯するために、PE間のコントロールプレーン通信用のG-CHACHベースのDCNを提供するために使用できます。
The DCN is intended to provide connectivity between management stations and network nodes, and between pairs of network nodes, for the purpose of exchanging management plane and control plane messages.
DCNは、管理局とネットワークノード間、およびネットワークノードのペア間で、管理プレーンのメッセージを交換する目的で、ネットワークノードのペア間で接続することを目的としています。
Appendix A of [NM-REQ] describes how Control Channels (CCh) that are the links in an MPLS-TP DCN can be out-of-fiber and out-of-band, in-fiber and out-of-band, or in-band with respect to the user data carried by the MPLS-TP network. That appendix also explains how the DCN can be constructed from a mix of different types of links and how routing and forwarding can be used within the DCN to facilitate multi-hop delivery of management and control plane messages.
[NM-REQ]の付録Aでは、MPLS-TP DCNのリンクであるコントロールチャネル（CCH）が、繊維外および帯域外、繊維および帯域外の、または帯域外であるか、またはどのように帯状になりますか、またはMPLS-TPネットワークによって運ばれるユーザーデータに関してバンド。その付録では、DCNをさまざまな種類のリンクの組み合わせから構築する方法と、DCN内でルーティングと転送を使用して、管理プレーンメッセージのマルチホップ配信を容易にする方法についても説明しています。
The G-ACh used as described in this document allows the creation of a "data channel associated CCh" (type 6 in Appendix A of [NM-REQ]) and an "in-band CCh" (type 7 in Appendix A of [NM-REQ]). In the former case, the G-ACh is associated with an MPLS-TP section. In the latter case, the G-ACh is associated with an MPLS-TP LSP or PW and may span one or more hops in the MPLS-TP network.
このドキュメントで説明されているように使用されているG-achは、「[NM-REQ]の付録Aのタイプ6）と「インバンドCCH」（[付録Aのタイプ7）の[[nm-req]のタイプ6）の作成を可能にします。nm-req]）。前者の場合、G-achはMPLS-TPセクションに関連付けられています。後者の場合、G-achはMPLS-TP LSPまたはPWに関連付けられており、MPLS-TPネットワークで1つ以上のホップにまたがる場合があります。
There is no need to create a CCh for every LSP between a pair of MPLS-TP nodes. Indeed, where the nodes are physically adjacent, the G-ACh associated with the MPLS-TP section would normally be used. Where nodes are virtually adjacent (that is, connected by LSP tunnels), one or two of the LSPs might be selected to provide the CCh and a back-up CCh.
MPLS-TPノードのペア間のすべてのLSPに対してCCHを作成する必要はありません。実際、ノードが物理的に隣接している場合、MPLS-TPセクションに関連付けられたG-achが通常使用されます。ノードが実質的に隣接している場合（つまり、LSPトンネルで接続されている）、LSPの1つまたは2つを選択してCCHとバックアップCCHを提供することができます。
The G-ACh provides a virtual link between MPLS-TP nodes and might be used to induce many forms of security attack. The MPLS data plane does not include any security mechanisms of its own; therefore, it is important that protocols using the DCN apply their own security. Protocols that operate over the MCN or SCN are REQUIRED to include adequate security mechanisms, and implementations MUST allow operators to configure the use of those mechanisms.
G-achは、MPLS-TPノード間の仮想リンクを提供し、多くの形態のセキュリティ攻撃を誘導するために使用される場合があります。MPLSデータプレーンには、独自のセキュリティメカニズムは含まれていません。したがって、DCNを使用したプロトコルを独自のセキュリティを適用することが重要です。MCNまたはSCNを介して動作するプロトコルは、適切なセキュリティメカニズムを含める必要があり、実装はオペレーターがそれらのメカニズムの使用を構成できるようにする必要があります。
Channel Types for the Generic Associated Channel are allocated from the IANA PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586].
ジェネリック関連チャネルのチャネルタイプは、[RFC4446]で定義され、[RFC5586]によって更新されたIANA PW関連チャネルタイプレジストリから割り当てられます。
IANA has allocated two further Channel Types as follows: 0x0001 Management Communication Channel (MCC) 0x0002 Signaling Communication Channel (SCC)
IANAは次のようにさらに2つのチャネルタイプを割り当てました：0x0001管理通信チャネル（MCC）0x0002シグナリング通信チャネル（SCC）
[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月。
[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月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Ed。、Vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[G.7712] ITU-T Recommendation G.7712, "Architecture and specification of data communication network", June 2008.
[G.7712] ITU-Tの推奨G.7712、「データ通信ネットワークのアーキテクチャと仕様」、2008年6月。
[MPLS-TP] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework for MPLS in Transport Networks", Work in Progress, October 2009.
[MPLS-TP] Bocci、M.、Bryant、S.、Frost、D。、およびL. Levrau、「輸送ネットワークにおけるMPLSのフレームワーク」、2009年10月、進行中の作業。
[NM-REQ] Lam, K. and S. Mansfield, "MPLS TP Network Management Requirements", Work in Progress, October 2009.
[NM-Req] Lam、K。およびS. Mansfield、「MPLS TPネットワーク管理要件」、2009年10月の作業。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point Protocol (PPP)", BCP 88, RFC 3818, June 2004.
[RFC3818] Schryver、V。、「ポイントツーポイントプロトコル（PPP）に対するIANAの考慮事項」、BCP 88、RFC 3818、2004年6月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
The editors wish to thank Pietro Grandi, Martin Vigoureux, Kam Lam, Ben Niven-Jenkins, Francesco Fondelli, Walter Rothkegel, Shahram Davari, Liu Guoman, and Alexander Vainshtein for their contribution to this document, and the MEAD team for thorough review.
編集者は、ピエトロ・グランディ、マーティン・ヴィゴルー、カム・ラム、ベン・ニヴェン・ジェンキンス、フランチェスコ・フンデッリ、ウォルター・ロスケゲル、シャラム・ダバリ、リュー・グアーマン、アレクサンダー・ヴァインシュテインに、この文書とミードチームへの徹底的なレビューに感謝します。
Study Group 15 of the ITU-T provided the basis for the requirements text in Section 1.1.
ITU-Tの研究グループ15は、セクション1.1の要件テキストの基礎を提供しました。
Authors' Addresses
著者のアドレス
Dieter Beller Alcatel-Lucent Germany EMail: dieter.beller@alcatel-lucent.com
Dieter Beller Alcatel-Lucent Germanyメール：Dieter.beller@alcatel-lucent.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk