[要約] RFC 6002は、Generalized MPLS（GMPLS）のデータチャネルスイッチング対応（DCSC）およびチャネルセットラベル拡張に関する仕様です。このRFCの目的は、GMPLSネットワークでのデータチャネルスイッチングとチャネルセットラベルの使用方法を定義することです。
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6002 LabN
Updates: 3471, 3473, 3945, 4202, 4203, 5307 D. Fedyk
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 October 2010
Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions
一般化されたMPLS（GMPLS）データチャネルスイッチング機能（DCSC）およびチャネルセットラベル拡張機能
Abstract
概要
This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path (LSP).
このドキュメントでは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）への2つの技術に依存しない拡張を説明しています。最初の拡張機能は、新しいスイッチングタイプデータチャネルスイッチングが可能にすることを定義します。データチャネルスイッチング有能なインターフェイスは、単一チャネルインターフェイスに表示されるデジタルチャネル全体の切り替えをサポートできます。2番目の拡張機能は、新しいタイプの一般化されたラベルと更新関連オブジェクトを定義します。新しいラベルは一般化されたChannel_setラベルと呼ばれ、複数のデータプレーンラベルをラベルスイッチドパス（LSP）の一部として制御できるようにします。
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/rfc6002.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6002で取得できます。
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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Data Channel Switching ..........................................3
2.1. Compatibility ..............................................4
3. Generalized Channel_Set Label Related Formats ...................4
3.1. Generalized Channel_Set LABEL_REQUEST Object ...............4
3.2. Generalized Channel_Set LABEL Object .......................4
3.3. Other Label-Related Objects ................................7
3.4. Compatibility ..............................................7
4. IANA Considerations .............................................8
4.1. Data Channel Switching Type ................................8
4.2. Generalized Channel_Set LABEL_REQUEST Object ...............8
4.3. Generalized Channel_Set LABEL Object .......................8
5. Security Considerations .........................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References ....................................10
Acknowledgments ...................................................10
This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching (GMPLS). Both of these extensions were initially defined in the context of Ethernet services, see [RFC6004] and [RFC6005], but are generic in nature and may be useful to any switching technology controlled via GMPLS.
このドキュメントでは、一般化されたマルチプロトコルラベルスイッチング（GMPLS）への2つの技術に依存しない拡張を説明しています。これらの拡張機能は両方とも、最初はイーサネットサービスのコンテキストで定義されていました。[RFC6004]と[RFC6005]を参照していますが、本質的には一般的であり、GMPLを介して制御されるスイッチングテクノロジーに役立つ場合があります。
The first extension defines a new switching type, which is called Data Channel Switching Capable (DCSC). DCSC interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a GMPLS Label Switched Path (LSP).
最初の拡張機能は、データチャネルスイッチング可能（DCSC）と呼ばれる新しいスイッチングタイプを定義します。DCSCインターフェイスは、単一チャネルインターフェイスに表示されるデジタルチャネル全体の切り替えをサポートできます。2番目の拡張機能は、新しいタイプの一般化されたラベルと更新関連オブジェクトを定義します。新しいラベルは一般化されたChannel_setラベルと呼ばれ、GMPLSラベルスイッチ付きパス（LSP）の一部として複数のデータプレーンラベルを制御できるようにします。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Current GMPLS switching types are defined in [RFC3945] and [RFC3471] and support switching at the packet (PSC), frame (L2SC), time-slot (TDM), frequency (LSC), and fiber (FSC) granularities. Parallel definitions for these switching types are also made in [RFC4202], [RFC4203], and [RFC5307].
現在のGMPLSスイッチングタイプは、[RFC3945]および[RFC3471]で定義され、パケット（PSC）、フレーム（L2SC）、タイムスロット（TDM）、周波数（LSC）、およびファイバー（FSC）の顆粒でのサポートスイッチングが定義されています。これらのスイッチングタイプの並列定義は、[RFC4202]、[RFC4203]、および[RFC5307]でも作成されています。
One type of switching that is not well represented in this current set is switching that occurs when all data received on an ingress port is switched through a network to an egress port. While there are similarities between this level of switching and the "opaque single wavelength" case, described in Section 3.5 of [RFC4202], such port-to-port switching is not limited to the optical switching technology implied by the LSC type. FSC is also similar, but it is restricted to fiber ports and also supports multiple data channels within a fiber port.
この現在のセットで十分に表されていないスイッチングの1つのタイプは、イングレスポートで受信したすべてのデータがネットワークを介して出口ポートに切り替えられたときに発生するスイッチングです。このレベルのスイッチングと[RFC4202]のセクション3.5で説明されている「不透明な単一波長」の場合には類似点がありますが、このようなポートからポートへの切り替えは、LSCタイプによって暗示される光学スイッチングテクノロジーに限定されません。FSCも似ていますが、ファイバーポートに制限されており、ファイバーポート内の複数のデータチャネルもサポートしています。
This document defines a new switching type called Data Channel Switching Capable (DCSC). Port switching seems a more intuitive name, but this naming collides with PSC so is not used. DCSC interfaces are able to support switching of the whole digital channel presented on single channel interfaces. Interfaces that inherently support multiple channels, e.g., Wavelength Division Multiplexing (WDM) and channelized TDM interfaces, are specifically excluded from this type. Any interface that can be represented as a single digital channel are included. Examples include concatenated TDM and line-encoded interfaces. Framed interfaces may also be included when they support switching on an interface granularity, for example Ethernet terminated at the physical (port) level and all traffic received on a port is switched to a physical port at the LSP egress.
このドキュメントでは、データチャネルスイッチング可能（DCSC）と呼ばれる新しいスイッチングタイプを定義します。ポートスイッチングはより直感的な名前のようですが、この命名はPSCと衝突するため、使用されません。DCSCインターフェイスは、単一チャネルインターフェイスに表示されるデジタルチャネル全体の切り替えをサポートできます。複数のチャネルを本質的にサポートするインターフェイス、たとえば、波長分割多重化（WDM）およびチャネル化されたTDMインターフェイスは、このタイプから特別に除外されます。単一のデジタルチャネルとして表現できるインターフェイスが含まれています。例には、連結されたTDMとラインエンコードインターフェイスが含まれます。たとえば、物理（ポート）レベルで終了したイーサネットと、ポートで受け取ったすべてのトラフィックがLSP Egressの物理ポートに切り替えられるなど、インターフェイスの粒度の切り替えをサポートする場合、フレーム付きインターフェイスを含めることもできます。
DCSC is represented in GMPLS, see [RFC3471] and [RFC4202], using the value 125. The DCSC value is carried in routing protocols in the Interface Switching Capability Descriptor defined in [RFC4202], and used in OSPF [RFC4203] and IS-IS [RFC5307]. These documents are not otherwise modified by this document.
DCSCはGMPLSで表されます。[RFC3471]および[RFC4202]を参照して、値125を使用して、DCSC値は[RFC4202]で定義されたインターフェイススイッチング機能記述子のルーティングプロトコルで運ばれ、OSPF [RFC4203]およびISで使用されます。[RFC5307]です。これらのドキュメントは、このドキュメントによって変更されていません。
The DCSC Switching Type may be used with the Generalized Label Request object, [RFC3473], or the Generalized Channel_Set LABEL_REQUEST object defined below. Port labels, as defined in [RFC3471], SHOULD be used for LSPs signaled using the DCSC Switching Type.
DCSCスイッチングタイプは、一般化されたラベルリクエストオブジェクト[RFC3473]、または以下に定義する一般化されたChannel_set label_requestオブジェクトで使用できます。[RFC3471]で定義されているように、ポートラベルは、DCSCスイッチングタイプを使用して信号を送信したLSPに使用する必要があります。
Transit and egress nodes that do not support the DCSC Switching Type when receiving a Path message with a Label Request containing the DCSC Switching Type will behave in the same way nodes generally handle the case of an unsupported Switching Type. Specifically, per [RFC3473], such nodes are required to generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication.
DCSCスイッチングタイプを含むパスメッセージを受信するときにDCSCスイッチングタイプをサポートしないトランジットノードと出口ノードは、ノードが一般にサポートされていないスイッチングタイプのケースを処理するのと同じように動作します。具体的には、[RFC3473]ごとに、このようなノードは、「ルーティングの問題/サポートされていないエンコード」表示を備えたPatherrメッセージを生成するために必要です。
Ingress nodes initiating a Path message containing a Label Request containing the DCSC Switching Type, receiving such a PathErr messages, then notify the requesting application user as appropriate.
INGRESSノードDCSCスイッチングタイプを含むラベル要求を含むパスメッセージを開始し、そのようなPatherRメッセージを受信し、必要に応じてリクエストアプリケーションユーザーに通知します。
This section defines a new type of generalized label and updates related objects. This section updates the label-related definitions of [RFC3473]. The ability to communicate more than one label as part of the same LSP was motivated by the support for the communication of one or more VLAN IDs. Simple concatenation of labels as is done in [RFC4606] was deemed impractical given the large number of VLAN IDs (up to 4096) that may need to be communicated. The formats defined in this section are not technology specific and may be useful for other switching technologies. The LABEL_SET object defined in [RFC3473] serves as the foundation for the defined formats.
このセクションでは、新しいタイプの一般化されたラベルと更新に関連するオブジェクトを定義します。このセクションでは、[RFC3473]のラベル関連定義を更新します。同じLSPの一部として複数のラベルを通信する能力は、1つ以上のVLAN IDの通信をサポートすることにより動機付けられました。[RFC4606]で行われているラベルの単純な連結は、通信する必要がある可能性のある多数のVLAN ID（最大4096）を考えると、非現実的であるとみなされました。このセクションで定義されている形式はテクノロジー固有ではなく、他のスイッチングテクノロジーに役立つ場合があります。[RFC3473]で定義されているLabel_setオブジェクトは、定義された形式の基礎として機能します。
The Generalized Channel_Set LABEL_REQUEST object is used to indicate that the Generalized Channel_Set LABEL object is to be used with the associated LSP. The format of the Generalized Channel_Set LABEL_REQUEST object is the same as the Generalized LABEL_REQUEST object and uses a C-Type of 5.
一般化されたChannel_set label_requestオブジェクトは、一般化されたChannel_setラベルオブジェクトが関連するLSPで使用されることを示すために使用されます。一般化されたChannel_set label_requestオブジェクトの形式は、一般化されたlabel_requestオブジェクトと同じであり、5のcタイプを使用します。
The Generalized Channel_Set LABEL Object communicates one or more labels, all of which can be used equivalently in the data path associated with a single LSP. The format of the Generalized Channel_Set LABEL Object is based on the LABEL_SET object defined in [RFC3473]. It differs from the LABEL_SET object in that the full set may be represented in a single object rather than the multiple objects required by the [RFC3473] LABEL_SET object. The object MUST be used on LSPs that use the Generalized Channel_Set LABEL_REQUEST object. The object MUST be processed per [RFC3473]. Make-before-break procedures, see [RFC3209], SHOULD be used when modifying the Channel_Set LABEL object.
一般化されたChannel_setラベルオブジェクトは、1つ以上のラベルを通信します。これらはすべて、単一のLSPに関連付けられたデータパスで同等に使用できます。一般化されたChannel_setラベルオブジェクトの形式は、[rfc3473]で定義されているlabel_setオブジェクトに基づいています。[rfc3473] label_setオブジェクトで必要な複数のオブジェクトではなく、フルセットが単一のオブジェクトで表される可能性があるという点で、label_setオブジェクトとは異なります。オブジェクトは、一般化されたChannel_set label_requestオブジェクトを使用するLSPで使用する必要があります。オブジェクトは[RFC3473]に従って処理する必要があります。channel_setラベルオブジェクトを変更する際には、[RFC3209]を参照してください。
The format of the Generalized Channel_Set LABEL object is:
一般化されたChannel_setラベルオブジェクトの形式は次のとおりです。
o Generalized Channel_Set LABEL object: Class = 16, C-Type = 4
o 一般化されたChannel_setラベルオブジェクト：class = 16、c-type = 4
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Subobject 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Channel_Set Subobject N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Channel_Set Subobject size is measured in bytes and MUST always be a multiple of 4, and at least 4, and has the following format:
Channel_set subobjectサイズはバイトで測定され、常に4の倍数で、少なくとも4つでなければならず、次の形式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Num Subchannels | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
: : :
: : :
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
アクション：8ビット
See [RFC3471] for definition of actions. Range actions SHOULD be used when possible to minimize the size of the Channel_Set LABEL Object.
アクションの定義については[RFC3471]を参照してください。範囲のアクションは、チャンネル_setラベルオブジェクトのサイズを最小限に抑えるために使用する必要があります。
Number of Subchannels: 10 bits
サブチャネルの数：10ビット
Indicates the number of subchannels carried in the subobject. When the number of subchannels required exceeds the limit of the field, i.e., 1024, multiple Channel_Set Subobjects MUST be used. Note that the size of the subobject may result in a Path message being larger than a single unfragmented IP packet. See Section 4.4 of [RFC6004] for an example of how this case may be handled.
サブオブジェクトに運ばれるサブチャネルの数を示します。必要なサブチャネルの数がフィールドの限界を超える場合、つまり1024、複数のChannel_setサブオブジェクトを使用する必要があります。サブオブジェクトのサイズは、パスメッセージが単一のフラージメントされていないIPパケットよりも大きくなる可能性があることに注意してください。このケースの処理方法の例については、[RFC6004]のセクション4.4を参照してください。
A value of zero (0) has special meaning and MAY be used in either the LABEL or UPSTREAM_LABEL object. A value of zero (0) is used in a LABEL or UPSTREAM_LABEL object to indicate that the subchannel(s) used in the corresponding (downstream or upstream) direction MUST match the subchannel(s) carried in the reverse directions label object. When value of zero (0) is used, no subchannels are included in the Channel_Set Subobject and only one Channel_Set Subobject may be present. The zero (0) value MUST NOT be used in both the LABEL and UPSTREAM_LABEL objects of the same LSP. Note that unacceptable label values continue to be handled according to [RFC3209] and [RFC3473], i.e., they result in PathErr or ResvErr messages with a "Routing problem/Unacceptable label value" indication. For example, in the case where a Resv message containing a zero (0) in both the LABEL and UPSTREAM_LABEL objects is received, the node would generate a ResvErr message.
ゼロ（0）の値には特別な意味があり、ラベルまたはUpstream_Labelオブジェクトのいずれかで使用できます。ゼロ（0）の値は、ラベルまたはアップストリーム_Labelオブジェクトで使用され、対応する（下流または上流）方向に使用されるサブチャネルが、逆方向ラベルオブジェクトで運ばれるサブチャネル（s）と一致する必要があることを示します。ゼロ（0）の値を使用すると、チャンネル_set subobjectにサブチャネルは含まれておらず、1つのChannel_setサブオブジェクトのみが存在する場合があります。ゼロ（0）値は、同じLSPのラベルとupstream_labelオブジェクトの両方で使用してはなりません。容認できないラベル値は、[RFC3209]および[RFC3473]に従って引き続き処理され続けていることに注意してください。つまり、「ルーティングの問題/容認できないラベル値」の表示を持つPatherrまたはRESVERRメッセージが得られることに注意してください。たとえば、ラベルオブジェクトとupstream_labelオブジェクトの両方にゼロ（0）を含むRESVメッセージが受信される場合、ノードはResverrメッセージを生成します。
Label Type: 14 bits
ラベルタイプ：14ビット
See [RFC3473] for a description of this field.
このフィールドの説明については、[RFC3473]を参照してください。
Subchannel: Variable
サブチャネル：変数
See [RFC3471] for a description of this field. Note that this field might not be 32-bit aligned.
このフィールドの説明については、[RFC3471]を参照してください。このフィールドは32ビットアライメントされていない可能性があることに注意してください。
Padding: Variable
パディング：変数
Padding is used to ensure that the length of a Channel_Set Subobject meets the multiple of 4 byte size requirement stated above. The field is only required when the Subchannel field is not 32-bit aligned and the number of included Subchannel fields result in the Subobject not being 32-bit aligned.
パディングは、Channel_setサブオブジェクトの長さが、上記の4バイトサイズの要件の倍数を満たすことを保証するために使用されます。フィールドは、サブチャネルフィールドが32ビットアライメントされていない場合にのみ必要であり、含まれているサブチャネルフィールドの数がサブオブジェクトが32ビットアライメントされていない場合にのみ必要です。
The Padding field MUST be included when the number of bits represented in all the Subchannel fields included in a Generalized Channel_Set Subobject result in the Subobject not being 32-bit aligned. When present, the Padding field MUST have a length that results in the Subobject being 32-bit aligned. When present, the Padding field MUST be set to a zero (0) value on transmission and MUST be ignored on receipt. These bits SHOULD be passed through unmodified by transit nodes.
一般化されたChannel_setサブオブジェクトに含まれるすべてのサブチャネルフィールドに表されるビットの数が、サブオブジェクトが32ビットに揃っていない場合、パディングフィールドを含める必要があります。存在する場合、パディングフィールドには、サブオブジェクトが32ビットアライメントされる長さが必要です。存在する場合、パディングフィールドは送信時にゼロ（0）値に設定する必要があり、受領時に無視する必要があります。これらのビットは、トランジットノードによって変更されていないことを通過する必要があります。
Note that the overall length of a Channel_Set Subobject is determined based on the value of the Num Subchannels field together with the size of each Subchannel field as well as any required padding. The size of the Subchannel field is uniquely identified by the Label Type field.
Channel_setサブオブジェクトの全長は、各サブチャネルフィールドのサイズと必要なパディングとともに、numサブチャネルフィールドの値に基づいて決定されることに注意してください。サブチャネルフィールドのサイズは、ラベルタイプフィールドによって一意に識別されます。
The previous section introduced a new LABEL object. As such the formats of the other label-related objects and subobjects are also impacted. Processing of these objects and subobjects is not modified and remains per their respective specifications. The other label related objects and subobjects are defined in [RFC3473] and include:
前のセクションでは、新しいラベルオブジェクトを導入しました。そのため、他のラベル関連オブジェクトとサブオブジェクトの形式も影響を受けます。これらのオブジェクトとサブオブジェクトの処理は変更されておらず、それぞれの仕様に従って残ります。他のラベル関連のオブジェクトとサブオブジェクトは[RFC3473]で定義されており、以下を含みます。
- SUGGESTED_LABEL object - LABEL_SET object - ACCEPTABLE_LABEL_SET object - UPSTREAM_LABEL object - RECOVERY_LABEL object - Label ERO subobject - Label RRO subobject
- sconsed_labelオブジェクト - label_set object -ecceptable_label_set object -upstream_labelオブジェクト-Recovery_Labelオブジェクト - ラベルERO SubObject -Label RRO SubObject
The label-related objects and subobjects each contain a Label field, all of which may carry any label type. As any label type may be carried, the introduction of a new label type means that the new label type may be carried in the Label field of each of the label-related objects and subobjects. No new definition needs to specified as their original specification is label-type agnostic.
ラベル関連のオブジェクトとサブオブジェクトにはそれぞれラベルフィールドが含まれており、そのすべてがラベルタイプを搭載する場合があります。任意のラベルタイプを運ぶことができるため、新しいラベルタイプの導入は、新しいラベルタイプを各ラベル関連オブジェクトとサブオブジェクトのラベルフィールドに携帯できることを意味します。元の仕様はラベルタイプの不可知論者であるため、新しい定義を指定する必要はありません。
Transit and egress nodes that do not support the Generalized Channel_Set Label related formats will first receive a Path message containing Generalized Channel_Set LABEL_REQUEST object. When such a node receives the Path message, per [RFC3209], it will send a PathErr with the error code "Unknown object C_Type".
一般化されたChannel_setラベル関連フォーマットをサポートしていないトランジットノードと出口ノードは、まず一般化されたChannel_set label_requestオブジェクトを含むパスメッセージを受信します。このようなノードが[RFC3209]ごとにパスメッセージを受信すると、エラーコード「不明なオブジェクトC_Type」を備えたPatherrが送信されます。
Ingress nodes initiating a Path message containing a Generalized Channel_Set LABEL_REQUEST object on receiving such a PathErr messages, then notify the requesting application user as appropriate.
IngressノードこのようなPatherRメッセージを受信する際に、一般化されたChannel_set label_requestオブジェクトを含むパスメッセージを開始し、必要に応じて要求アプリケーションユーザーに通知します。
IANA has assigned new values for namespaces defined in this document and summarized in this section. The registries are available from http://www.iana.org.
IANAは、このドキュメントで定義され、このセクションで要約されている名前空間に新しい値を割り当てています。レジストリはhttp://www.iana.orgから入手できます。
IANA has made the following assignment in the "Switching Types" section of the "GMPLS Signaling Parameters" registry.
IANAは、「GMPLSシグナリングパラメーター」レジストリの「スイッチングタイプ」セクションで次の割り当てを行いました。
Value Type Reference
----- ------------------------------------ ---------
125 Data Channel Switching Capable (DCSC) [RFC6002]
The assigned value is reflected in IANAGmplsSwitchingTypeTC of the IANA-GMPLS-TC-MIB available from http://www.iana.org.
割り当てられた値は、http：//www.iana.orgから入手可能なiana-gmpls-tc-mibのianagmplsswitchingtypetcに反映されます。
IANA has made the following assignment in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
IANAは、「クラス名、クラス番号、クラスタイプ」の「RSVPパラメーター」レジストリのセクションで次の割り当てを行いました。
A new class type for the existing LABEL_REQUEST Object class number (19) with the following definition:
次の定義を備えた既存のlabel_requestオブジェクトクラス番号（19）の新しいクラスタイプ：
Class Types or C-Types:
クラスタイプまたはCタイプ：
5 Generalized Channel_Set [RFC6002]
5一般化されたChannel_set [RFC6002]
IANA has made the following assignment in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry.
IANAは、「クラス名、クラス番号、クラスタイプ」の「RSVPパラメーター」レジストリのセクションで次の割り当てを行いました。
A new class type for the existing RSVP_LABEL Object class number (16) with the following definition:
次の定義を伴う既存のRSVP_Labelオブジェクトクラス番号（16）の新しいクラスタイプ：
Class Types or C-Types:
クラスタイプまたはCタイプ：
4 Generalized Channel_Set [RFC6002]
4一般化されたChannel_set [RFC6002]
This document introduces new message object formats for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane. As such, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations. Additionally, the existing framework for MPLS and GMPLS security is documented in [RFC5920].
このドキュメントでは、GMPLSシグナル伝達[RFC3473]で使用する新しいメッセージオブジェクト形式を導入します。新しいシグナリングメッセージは導入されたり、コントロールプレーンに隣接しているLSR間の関係を変更したりしません。そのため、このドキュメントでは、追加のセキュリティ上の考慮事項は導入されていません。関連するセキュリティに関する考慮事項については、[RFC3473]を参照してください。さらに、MPLSおよびGMPLSセキュリティの既存のフレームワークは[RFC5920]に文書化されています。
[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月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ」、RFC 3945、2004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張」、RFC 4203、2005年10月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K.、ed。、およびY. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、2008年10月。
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
[RFC4606] Mannie、E。およびD. Papadimitriou、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロールの拡張機能」、RFC 4606、2006年8月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching", RFC 6004, October 2010.
[RFC6004] Berger、L。およびD. Fedyk、「メトロイーサネットフォーラムおよびG.8011イーサネットサービススイッチングの一般化MPLS（GMPLS）サポート」、RFC 6004、2010年10月。
[RFC6005] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)", RFC 6005, October 2010.
[RFC6005] Berger、L。およびD. Fedyk、「メトロイーサネットフォーラムおよびG.8011ユーザーネットワークインターフェイス（UNI）の一般化MPLS（GMPLS）サポート」、RFC 6005、2010年10月。
Acknowledgments
謝辞
Dimitri Papadimitriou provided substantial textual contributions to this document and coauthored earlier versions of this document.
Dimitri Papadimitriouは、このドキュメントに実質的なテキスト貢献を提供し、このドキュメントの以前のバージョンを共著しました。
The authors would like to thank Evelyne Roch, Stephen Shew, and Adrian Farrel for their valuable comments.
著者は、貴重なコメントをしてくれたEvelyne Roch、Stephen Shew、Adrian Farrelに感謝したいと思います。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、L.L.C。電話：1-301-468-9228メール：lberger@labn.net
Don Fedyk Alcatel-Lucent Groton, MA, 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
Don Fedyk Alcatel-Lucent Groton、MA、01450電話：1-978-467-5645メール：donald.fedyk@alcatel-lucent.com