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-ACH）、マルチプロトコルラベルスイッチング（MPLS）に関連付けられている制御/通信チャネルの実現を可能にするために、疑似回線（PW）付随制御チャネルの一般化として定義されているラベル（LSPを）パスのスイッチ、MPLSのPW、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メッセージが、カプセル化されたG-ACHに担持し、MPLS-TPノード上の管理や、シグナリング/ルーティング制御プレーンコンポーネントへの送達のために分離される方法について説明します。
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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
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）に使用されるパケットと同様の機能を識別するために疑似回線（PWの）で使用するためのパケットヘッダフォーマットです。
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は、パケットトランスポートネットワークを構築するための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-ACHは（サーバ層が管理通信チャネル（MCC）またはシグナリング通信チャネル（SCC）を提供していないときに使用される）は、2つの隣接するMPLS-TPノードを相互接続します。
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.
MCNを構築するMCCとSCNを構築するためのSCC：3 G-ACHは、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.
MCCとSCCは、異なるOSIレイヤ3（ネットワーク層）のPDUを運ぶことができるものでなければならない運ぶ5. G-ACH。これらは、IPv4、IPv6、およびOSI PDUを含まなければなりません。 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].
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.
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メッセージであるか否かを判定する。コードポイントの割り当てについては、セクション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へのチャネルタイプフィールドを設定し、MCC層3 PDUのタイプを示すために、PIDを埋め、そして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部、汎用関連するチャネル・ラベル（GAL）に関連付けられている場合は[RFC5586]で定義されるようにメッセージに追加されます。 （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は、パケットに付加され、[RFC5586]で定義されるようにLSPラベルは、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.
MPLSヘッダのトラフィッククラス（TC）フィールドの通常の処理を受け、全てのG-ACH MPLSパケットと共通に、G-ACHでDCNパケットのそのパケットの処理があることに注意してください。これは、異なる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.
通常のMPLSパケットの場合のように[RFC5586]によれば、受信機は、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.
高速（転送）パスにIP又はOSI転送をサポートするために、MPLS-TP装置のための要件がないことに留意されたいです。メッセージは、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]などの）リモート隣接関係を使用してシグナリングプロトコルを使用してのPWを設定することを望むかもしれません。 IPベースの制御プレーン・ネットワークの非存在下で、これらのPEは、第MPLS-TPネットワーク上のLSPトンネルを設定する必要があります。このトンネルは、それが設定された後PWを運ぶこととPE間の制御プレーン通信にG-ACHベース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「は、データチャネル関連CChによって」の作成を可能にする（付録Aに型6 [NM-REQ]）との「インバンドCChによって」（タイプ7付録A [ 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の一つまたは二つが、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]で定義されたIANA PW関連するチャネルタイプレジストリから割り当てられ、[RFC5586]で更新されます。
IANA has allocated two further Channel Types as follows: 0x0001 Management Communication Channel (MCC) 0x0002 Signaling Communication Channel (SCC)
次のようにIANAは、さらに2つのチャネルタイプを割り当てた：0x0001の管理通信チャネル（MCC）0×0002シグナリング通信チャネル（SCC）
[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月。
[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の割り当て"。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586]ボッチ、M.、エド。、Vigoureux、M.、エド。、およびS.ブライアント、エド。、 "MPLSジェネリック関連チャンネル"、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]ボッチ、M.、ブライアント、S.、フロスト、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]ラム、K.およびS.マンスフィールド、 "MPLS TPネットワーク管理の要件"、進歩、2009年10月に作業。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、編、 "ポイントツーポイントプロトコル（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.、BCP 88、RFC 3818、2004年6月 "ポイントツーポイントプロトコル（PPP）のためのIANAの考慮事項"。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]ニーヴン、ジェンキンス、B.、編。、Brungard、D.、編、ベッツ、M.編、Sprecher、N.、およびS.上野、 "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.
編集者は、この文書への貢献のためにピエトロ・グランディ、マーティンVigoureux、カムラム、ベン・ニーヴン・ジェンキンス、フランチェスコFondelli、ウォルターRothkegel、Shahram Davari、劉アグオマン、アレクサンドルVainshteinに感謝したい、と徹底的なレビューのためMEADチーム。
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
ディーターBellerアルカテル・ルーセントドイツのEメール：dieter.beller@alcatel-lucent.com
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk