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
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つの技術に依存しない拡張機能について説明します。最初の拡張はできるスイッチング新しいスイッチング方式データチャネルを定義します。対応インタフェースの切り替えデータチャネルは、単一チャネルインターフェイス上で提示全体のデジタルチャンネルの切り替えをサポートすることができます。第二延長は一般ラベルや更新に関連するオブジェクトの新しいタイプを定義します。新しいラベルは、一般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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（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ライセンスのテキストを含める必要があり、この文書から抽出されました。
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]を参照してください、イーサネットサービスのコンテキストで定義されていますが、自然の中で一般的なものとGMPLSを介して制御任意のスイッチング技術に有用である可能性がされました。
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インターフェースは、単一のチャネルインタフェース上に提示さ全体デジタルチャンネルの切り替えをサポートすることができます。第二延長は一般ラベルや更新に関連するオブジェクトの新しいタイプを定義します。新しいラベルは、一般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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）粒度で定義されています。これらのスイッチングタイプの平行定義はまた、[RFC4203]及び[RFC5307]、[RFC4202]に構成されています。
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.
それはよく表さこの現在セットされていないスイッチングの一つのタイプは、スイッチングされた入力ポートで受信されたすべてのデータが出力ポートにネットワークを介して切り替えられたときに発生します。スイッチングのこのレベルと[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の出口の物理ポートに切り替えられたポート上で受信するために、彼らは、インターフェイスの粒度をオンサポート場合入れるインターフェースが含まれていてもよいです。
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目的で使用することができます。 LSPがDCSC交換型を使用してシグナリングするためのポートのラベルは、[RFC3471]で定義されるように使用すべきです。
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交換型を含むラベル要求にPathメッセージを受信したとき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.
必要に応じて要求元のアプリケーションのユーザに通知し、その後、そのようなのPathErrメッセージを受信し、タイプスイッチングDCSCを含むラベル要求を含むPathメッセージを開始する入口ノード。
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の一部として、複数のラベルを通信する能力は、一つ以上のVLAN IDの通信のためのサポートによって動機づけました。 [RFC4606]に行われるようにラベルの単純な連結は、通信する必要があるかもしれない（4096まで）VLAN IDの多数所与非実用的と考えられました。このセクションで定義されたフォーマットは、特定の技術ではなく、他のスイッチング技術のために有用である可能性があります。 [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ラベルオブジェクトは、単一のLSPに関連付けられたデータパスに同等に使用することができる全てが1以上の標識を通信します。一般Channel_Setラベルオブジェクトのフォーマットは、[RFC3473]で定義されたLABEL_SETオブジェクトに基づいています。これは、完全なセットは、単一のオブジェクトではなく、[RFC3473] LABEL_SETオブジェクトによって必要とされる複数のオブジェクトで表すことができるという点でLABEL_SETオブジェクトとは異なります。オブジェクトは、一般Channel_Set LABEL_REQUESTオブジェクトを使用するLSP上で使用しなければなりません。オブジェクトは、[RFC3473]あたりに処理されなければなりません。メイク前にブレーク手続き、Channel_SetのLABELオブジェクトを変更するときに使用する、[RFC3209]を参照してください。
The format of the Generalized Channel_Set LABEL object is:
一般Channel_SetのLABELオブジェクトの形式は次のとおりです。
o Generalized Channel_Set LABEL object: Class = 16, C-Type = 4
O一般Channel_Setラベルオブジェクト：クラス= 16、C-タイプ= 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サブオブジェクトのサイズはバイト単位で測定され、常に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]を参照してください。 Channel_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パケットよりも大きいPathメッセージをもたらすことができることに留意されたいです。この場合は、処理することができる方法の例については、[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）の値は、対応する（上流、下流又は）方向で使用されるサブチャネル（単数または複数）は、逆方向ラベルオブジェクトで運ばサブチャネル（複数可）と一致しなければならないことを示すためにラベルまたはUPSTREAM_LABELオブジェクトで使用されています。ゼロ（0）の値を使用した場合、何のサブチャネルはChannel_Setサブオブジェクトに含まれず、一方のみChannel_Setサブオブジェクトが存在してもよいです。ゼロ（0）の値は、ラベルと同じLSPのUPSTREAM_LABELオブジェクトの両方に使用してはいけません。その容認できないラベル値、すなわち、それらは「ルーティング問題/許可されないラベル値」表示とのPathErr又はResvErrメッセージをもたらす、[RFC3209]及び[RFC3473]に従って処理され続けるに留意されたいです。例えば、場合には、ラベルとUPSTREAM_LABELオブジェクトの両方が受信されるゼロを含むResvメッセージ（0）、ノードは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.
すべてのサブチャネルフィールドに示されるビット数は32ビット整列されていないサブオブジェクトに一般Channel_Setサブオブジェクト結果に含まれるパディングフィールドを含まなければなりません。存在する場合、パディングフィールドは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サブオブジェクトの全体の長さが共に各サブチャネルフィールドのサイズ、並びに任意の必要なパディングと民サブチャネルフィールドの値に基づいて決定されることに留意されたいです。サブチャネルフィールドのサイズは一意にラベルタイプフィールドによって識別されます。
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
- SUGGESTED_LABELオブジェクト - LABEL_SETオブジェクト - ACCEPTABLE_LABEL_SETオブジェクト - UPSTREAM_LABELオブジェクト - RECOVERY_LABELオブジェクト - ラベルEROサブオブジェクト - ラベルRROのサブオブジェクト
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オブジェクトを含むPathメッセージを受信します。そのようなノードは、[RFC3209]あたり、Pathメッセージを受信すると、エラーコード「未知のオブジェクト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.
入口ノードは、必要に応じて要求元のアプリケーションのユーザに通知し、その後、そのようなのPathErrメッセージを受信すると一般Channel_Set LABEL_REQUESTオブジェクトを含むPathメッセージを開始します。
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 Objectクラスの数（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].
このドキュメントは[RFC3473]をGMPLSシグナリングで使用するための新たなメッセージオブジェクトフォーマットを導入します。これは、任意の新しいシグナリングメッセージを紹介し、また制御プレーンに隣接する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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド。は、 "一般化マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、エド。、 "一般化マルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、 "ルーティング拡張一般マルチプロトコルラベルスイッチング（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.、エド。、およびY. Rekhter、エド。、RFC 4203、2005年10月 "OSPF拡張一般化マルチプロトコルラベルスイッチング（GMPLS）のサポートで"。
[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.、エド。、およびY. Rekhter、エド。、 "IS-ISの拡張一般化マルチプロトコルラベルスイッチング（GMPLS）の支援で"、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]マニー、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]牙、L.、エド。、 "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]バーガー、L.とD. Fedyk、 "一般化MPLS（GMPLS）、メトロ・イーサネット・フォーラムとG.8011イーサネットサービス交換のサポート"、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]バーガー、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.
ディミトリPapadimitriouは、この文書にかなりのテキスト貢献を提供し、このドキュメントの以前のバージョンを共著。
The authors would like to thank Evelyne Roch, Stephen Shew, and Adrian Farrel for their valuable comments.
作者は彼らの貴重なコメントをエヴリーヌRochの、スティーブン供え、およびエードリアンファレルに感謝したいと思います。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、L.L.C.電話：+ 1-301-468-9228 Eメール：lberger@labn.net
Don Fedyk Alcatel-Lucent Groton, MA, 01450 Phone: +1-978-467-5645 EMail: donald.fedyk@alcatel-lucent.com
ドン・ルブランアルカテル・ルーセント、グロトン、MA 01450電話：+ 1-978-467-5645 Eメール：donald.fedyk@alcatel-lucent.com