Network Working Group L. Berger, Editor
Request for Comments: 3471 Movaz Networks
Category: Standards Track January 2003
Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.
この文書では、マルチプロトコルラベルスイッチング（MPLS）一般MPLSをサポートするために必要なシグナルの拡張機能について説明します。一般MPLSは時分割（例えば、同期光ネットワークと同期デジタル・ハイアラーキ、SONET / SDH）、波長（光ラムダ）と空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するMPLSコントロールプレーンを拡張します。この文書では、拡張の機能説明を提示しています。プロトコル固有の形式とメカニズム、および技術の特定の詳細が別の文書で指定されています。
Table of Contents
目次
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. Label Related Formats ..................................... 6
3.1 Generalized Label Request ............................... 6
3.2 Generalized Label ....................................... 11
3.3 Waveband Switching ...................................... 12
3.4 Suggested Label ......................................... 13
3.5 Label Set ............................................... 14
4. Bidirectional LSPs ......................................... 16
4.1 Required Information .................................... 17
4.2 Contention Resolution ................................... 17
5. Notification on Label Error ................................ 20
6. Explicit Label Control ..................................... 20
6.1 Required Information .................................... 21
7. Protection Information ..................................... 21
7.1 Required Information .................................... 22
8. Administrative Status Information .......................... 23
8.1 Required Information .................................... 24
9. Control Channel Separation ................................. 25
9.1 Interface Identification ................................ 25
9.2 Fault Handling .......................................... 27
10. Acknowledgments ............................................ 27
11. Security Considerations .................................... 28
12. IANA Considerations ........................................ 28
13. Intellectual Property Considerations ....................... 29
14. References ................................................. 29
14.1 Normative References ................................... 29
14.2 Informative References ................................. 30
15. Contributors ............................................... 31
16. Editor's Address ........................................... 33
17. Full Copyright Statement ................................... 34
The Multiprotocol Label Switching (MPLS) architecture [RFC3031] has been defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).
マルチプロトコルラベルスイッチング（MPLS）アーキテクチャ[RFC3031]は、ラベルに基づいてデータの転送をサポートするために定義されています。このアーキテクチャでは、ラベルスイッチングルータ（LSRの）（a）の認識パケットまたはセルのいずれかの境界の可能な転送プレーンを有するものと、（b）はパケットヘッダのいずれかを処理することができる（パケット境界を認識することができるのLSRのためにしました）又はセル境界を認識することができるのLSRのためのセルヘッダー（）。
The original architecture has recently been extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports.
元のアーキテクチャは、最近、その転送面もパケットを認識し、またセル境界、したがって、パケットまたはセル・ヘッダのいずれかで運ばれた情報に基づいてデータを転送できないのLSRを含むように拡張されています。具体的には、このようなのLSRは、転送決定がタイムスロット、波長、または物理ポートに基づいてデバイスを含みます。
Given the above, LSRs, or more precisely interfaces on LSRs, can be subdivided into the following classes:
LSRの上、上記のLSR、またはより正確にはインタフェースを考えると、以下のクラスに細分化することができます。
1. Interfaces that recognize packet/cell boundaries and can forward data based on the content of the packet/cell header. Examples include interfaces on routers that forward data based on the content of the "shim" header, interfaces on (Asynchronous Transfer Mode) ATM-LSRs that forward data based on the ATM VPI/VCI. Such interfaces are referred to as Packet-Switch Capable (PSC).
パケット/セル境界を認識し、パケット/セル・ヘッダの内容に基づいてデータを転送することができる1.インターフェース。例としては、（非同期転送モード）の「シム」ヘッダ、インターフェイスATM VPI / VCIに基づいてデータを転送するATM-のLSRの内容に基づいてデータを転送するルータのインタフェースを含みます。そのようなインターフェースは、可能なパケット交換（PSC）と呼ばれます。
2. Interfaces that forward data based on the data's time slot in a repeating cycle. An example of such an interface is an interface on a SONET/SDH Cross-Connect. Such interfaces are referred to as Time-Division Multiplex Capable (TDM).
繰り返し周期内のデータのタイムスロットに基づいてデータを転送する2.インタフェース。そのようなインターフェイスの例は、SONET / SDHクロスコネクトのインターフェイスです。そのようなインタフェースは、可能な時分割多重（TDM）と呼ばれます。
3. Interfaces that forward data based on the wavelength on which the data is received. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of an individual wavelength. Such interfaces are referred to as Lambda Switch Capable (LSC).
データが受信された波長に基づいてデータを転送3.インタフェース。そのようなインターフェイスの例は、個々の波長レベルで動作可能な光クロスコネクトのインターフェイスです。そのようなインターフェイスは、可能なラムダスイッチ（LSC）と呼ばれます。
4. Interfaces that forward data based on a position of the data in the real world physical spaces. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of a single (or multiple) fibers. Such interfaces are referred to as Fiber-Switch Capable (FSC).
現実世界の物理的な空間でのデータの位置に基づいてデータを転送する4.インターフェース。そのようなインターフェイスの例は、単一（または複数）の繊維のレベルで動作可能な光クロスコネクトのインターフェイスです。そのようなインターフェイスは、ファイバスイッチ可能な（FSC）と呼ばれます。
Using the concept of nested Label Switched Paths (LSPs) allows the system to scale by building a forwarding hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface. See [MPLS-HIERARCHY] for more information on LSP hierarchies.
ネストされたラベルの概念を使用すると、パス（LSPの）システムが転送階層を構築することで拡張することができますを交換しました。この階層の最上位にPSCインターフェース続いTDMインタフェース続いLSCインターフェース続くFSCインタフェースは、、、です。この方法は、PSCインタフェース上で開始し、終了するLSPが起動し、TDMインタフェースで終了LSPに（一緒に、他のLSPとの）ネストすることができます。このLSP、順番に、起動し、起動し、FSCインタフェースで終わるLSPに順番に（他のLSPと一緒に）入れ子にすることができるLSCインターフェースで終了LSPに（一緒に、他のLSPとの）入れ子にすることができ。 LSP階層の詳細については、[MPLS-HIERARCHY]を参照してください。
The establishment of LSPs that span only the first class of interfaces is defined in [RFC3036, RFC3212, RFC3209]. This document presents a functional description of the extensions needed to generalize the MPLS control plane to support each of the four classes of interfaces. Only signaling protocol independent formats and definitions are provided in this document. Protocol specific formats are defined in [RFC3473] and [RFC3472]. Technology specific details are outside the scope of this document and will be specified in technology specific documents, such as [GMPLS-SONET].
インターフェイスの最初のクラスにまたがるLSPの確立は[RFC3036、RFC3212、RFC3209]で定義されています。この文書では、インタフェースの4つのクラスのそれぞれをサポートするためのMPLS制御プレーンを一般化するために必要な拡張機能の機能説明を提示しています。シグナリング・プロトコルに依存しないフォーマットや定義だけは、この文書で提供されています。プロトコル特定のフォーマットは、[RFC3473]及び[RFC3472]で定義されています。テクノロジー具体的な詳細は、このドキュメントの範囲外であり、技術では、このような[GMPLS-SONET]などの特定の文書を、指定されます。
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]に記載されているように解釈されます。
Generalized MPLS differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional types of switching has driven generalized MPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties, how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.
それはスイッチング複数のタイプ、すなわち、TDM、ラムダ、およびファイバ（ポート）は、スイッチングのためのサポートの追加をサポートしているという点で一般的なMPLSは、従来のMPLSは異なります。スイッチングの追加タイプのサポートは、従来のMPLSの特定の基底関数を拡張し、いくつかのケースでは、機能を追加するために一般化されたMPLSを駆動しています。これらの変更や追加は、ラベルが要求されたと伝え、エラーが伝播される方法のLSPの一方向性質、及び情報を入力および出力を同期させるために提供される方法の基本的なLSP特性を、影響を与えます。
In traditional MPLS Traffic Engineering, links traversed by an LSP can include an intermix of links with heterogeneous label encodings. For example, an LSP may span links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the real world physical space. Just like with traditional MPLS TE, where not all LSRs are capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in their forwarding plane, generalized MPLS includes support for LSRs that can't recognize (IP) packet boundaries in their forwarding plane. In traditional MPLS TE an LSP that carries IP has to start and end on a router. Generalized MPLS extends this by requiring an LSP to start and end on similar type of LSRs. Also, in generalized MPLS the type of a payload that can be carried by an LSP is extended to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These changes from traditional MPLS are reflected in how labels are requested and communicated in generalized MPLS, see Sections 3.1 and 3.2. A special case of Lambda switching, called Waveband switching is also described in Section 3.3.
伝統的なMPLSトラフィックエンジニアリングでは、LSPが通過するリンクは、異種のラベルエンコーディングとのリンクの混在を含めることができます。例えば、LSPは、ルータ、ルータとATM-LSRの間のリンク、およびATM-LSRの間のリンク間のリンクをまたがってもよいです。一般MPLSラベルがタイムスロット、または波長、または現実世界の物理的な空間における位置としてエンコードされたリンクを含むことによって、これを拡張します。ただ、必ずしもすべてのLSRが自分のフォワーディングプレーンに（IP）パケット境界（例えば、ATM-LSR）を認識することができる伝統的なMPLS TE、と同じように、一般的なMPLSはに（IP）パケットの境界を認識することができないのLSRのサポートが含まれています彼らのフォワーディングプレーン。伝統的なMPLS TEでIPを運ぶLSPが起動し、ルータに終了する必要があります。一般MPLSは、開始とのLSRの同様の種類に終了するLSPを要求することによって、これを延びています。また、一般にMPLS LSPによって実施することができるペイロードのタイプは、SONET / SDH、または1または10 Gbイーサネットのようなペイロードを可能にするように拡張されます。伝統的なMPLSからのこれらの変更は、セクション3.1と3.2を参照して、ラベルが一般化MPLSに要求されたと伝えているどのように反映されています。波長群スイッチングと呼ばれるラムダスイッチングの特別な場合は、また、第3.3節に記載されています。
Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3. There are also likely to be (much) fewer labels on non-PSC links than on PSC links. Note that the use of Forwarding Adjacencies (FA), see [MPLS-HIERARCHY], provides a mechanism that may improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units, as well as a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.
一般のMPLS LSPの伝統的および非PSCタイプとの間の別の基本的な違いは、LSPの帯域幅割り当ては、セクション3.1.3を参照して、唯一の別個の単位で行うことができることです。また、PSCのリンクよりも非PSCリンク上（多くの）少数のラベルである可能性が高いがあります。 、帯域幅帯域幅割り当てだけ個別の単位で行うことができる利用、ならびに転送状態を集約するためのメカニズムを改善することができるメカニズムを提供し、従って可能にフォワーディング隣接関係の使用（FA）は、[MPLS階層]を参照のことに注意してください必要なラベルの数を減少させることができます。
Generalized MPLS allows for a label to be suggested by an upstream node, see Section 3.4. This suggestion may be overridden by a downstream node but, in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the norm) the MAPPING/Resv message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. The suggested label is also valuable when recovering from nodal faults.
一般化されたMPLSラベルが上流ノードによって示唆されるようにするために、3.4節を参照できます。この提案は、いくつかの場合において、より高いLSPセットアップ時間を犠牲にして、下流のノードによってオーバーライドなくてもよいです。スイッチングファブリックの設定で（電気換算）長い遅延が存在し得る光学機器の特定の種類を介してLSPを確立する際に提案ラベルは価値があります。例えば、マイクロミラーが上昇又は移動させる必要があり、この物理的運動とその後の減衰時間がかかります。ラベルひいてはスイッチングファブリックが逆方向（ノルム）で構成されている場合MAPPING / Resvメッセージには、使用可能な転送パスを確立するためにホップ毎ミリ秒10件のだけ遅延される必要があるかもしれません。リンパ節の障害からの回復時に提案されたラベルにも貴重なものです。
Generalized MPLS extends on the notion of restricting the range of labels that may be selected by a downstream node, see Section 3.5. In generalized MPLS, an ingress or other upstream node may restrict the labels that may be used by an LSP along either a single hop or along the whole LSP path. This feature is driven from the optical domain where there are cases where wavelengths used by the path must be restricted either to a small subset of possible wavelengths, or to one specific wavelength. This requirement occurs because some equipment may only be able to generate a small set of the wavelengths that intermediate equipment may be able to switch, or because intermediate equipment may not be able to switch a wavelength at all, being only able to redirect it to a different fiber.
一般MPLSは、セクション3.5を参照して、下流のノードによって選択することができるラベルの範囲を制限する概念に延びています。一般MPLSにおいて、入力または他の上流ノードは、単一のホップに沿って、または全LSPパスに沿ってLSPによって使用することができるラベルを制限してもよいです。この機能は、パスが使用する波長が可能な波長の小さなサブセットへ、または1つの特定の波長のいずれかに制限されなければならない場合がある光学領域から駆動されます。一部の機器のみ中間機器がスイッチすることができる場合があり、波長の小さなセットを生成することができる可能性があるため、この要件が発生し、または中間装置は、全ての波長を切り替えることはできないかもしれないので、それをリダイレクトすることができるだけです異なる繊維。
While traditional traffic engineered MPLS (and even LDP) are unidirectional, generalized MPLS supports the establishment of bidirectional LSPs, see Section 4. The need for bidirectional LSPs comes from non-PSC applications. There are multiple reasons why such LSPs are needed, particularly possible resource contention when allocating reciprocal LSPs via separate signaling sessions, and simplifying failure restoration procedures in the non-PSC case. Bidirectional LSPs also have the benefit of lower setup latency and lower number of messages required during setup.
伝統的なトラフィックエンジニアリングMPLS（とさえLDP）は単方向ですが、一般的なMPLSは、双方向のLSPの確立をサポートし、第4節を参照してください双方向のLSPの必要性は、非PSCのアプリケーションから来ています。別のシグナリングセッションを介して相互LSPを割り当て、非PSC場合の障害復旧手順を簡素化するとき、そのようなLSPのは、特に可能なリソースの競合を必要とする理由複数の理由があります。双方向のLSPも低く設定待ち時間やセットアップ時に必要なメッセージ数が少ないという利点を持っています。
Generalized MPLS supports the communication of a specific label to use on a specific interface, see Section 6. [RFC3473] also supports an RSVP specific mechanism for rapid failure notification.
一般MPLSは、特定のインターフェイスで使用する特定のラベルの通信をサポートし、第6 [RFC3473]は、迅速な障害通知のためのRSVP特定のメカニズムをサポート参照します。
Generalized MPLS formalizes possible separation of control and data channels, see Section 9. Such support is particularly important to support technologies where control traffic cannot be sent in-band with the data traffic.
一般MPLSは、制御およびデータチャネルの可能な分離を形式、節参照9。このような支援は、制御トラフィックは、データトラフィックとインバンド送信できない技術をサポートすることが特に重要です。
Generalized MPLS also allows for the inclusion of technology specific parameters in signaling. The intent is for all technology specific parameters to be carried, when using RSVP, in the SENDER_TSPEC and other related objects, and when using CR-LDP, in the Traffic Parameters TLV. Technology specific formats will be defined on an as needed basis. For an example definition, see [GMPLS-SONET].
一般MPLSはまた、シグナリングにおける技術の特定のパラメータを含めることが可能になります。 SENDER_TSPECおよび他の関連するオブジェクトに、RSVPを使用する場合、およびCR-LDPを使用する場合、すべての技術の特定のパラメータがトラフィックパラメータTLVで、実施するために意図されます。テクノロジー固有の形式は、のように必要に応じて定義されます。例えば、定義については、[GMPLS-SONET]を参照。
To deal with the widening scope of MPLS into the optical and time domain, several new forms of "label" are required. These new forms of label are collectively referred to as a "generalized label". A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. This section defines a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
光学的および時間領域へのMPLSの拡大範囲に対処するには、「ラベル」のいくつかの新しい形態が必要とされています。ラベルのこれらの新しい形態を総称して「一般化ラベル」と呼ばれています。一般化ラベルは、受信ノードは、パスの入口セグメントが適切に接合されているように、接続関係なく、この十字型の接続、そのクロスをプログラムすることを可能にするのに十分な情報を含んでいます。このセクションでは、波長帯の切り替えのための一般的なラベル要求、一般ラベル、サポートを定義し、ラベルとラベルのセットを示唆しました。
Note that since the nodes sending and receiving the new form of label know what kinds of link they are using, the generalized label does not contain a type field, instead the nodes are expected to know from context what type of label to expect.
ノードは、ラベルの新しいフォームは、彼らが使用しているリンクの種類を知って送受信することから、一般的なラベルは、タイプフィールドが含まれていないことに注意してください、代わりにノードが期待するものをラベルの種類文脈から知っていることが予想されます。
The Generalized Label Request supports communication of characteristics required to support the LSP being requested. These characteristics include LSP encoding and LSP payload. Note that these characteristics may be used by transit nodes, e.g., to support penultimate hop popping.
一般ラベル要求は、要求されたLSPをサポートするために必要な特性の通信をサポートしています。これらの特性は、LSP符号化およびLSPペイロードを含みます。最後から二番目のホップのポッピングをサポートするために、例えば、これらの特性は、トランジットノードによって使用されてもよいことに留意されたいです。
The Generalized Label Request carries an LSP encoding parameter, called LSP Encoding Type. This parameter indicates the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the data associated with the LSP. The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses. A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats depending on the resource availability and capacity of the link. For example, consider an LSP signaled with "lambda" encoding. It is expected that such an LSP would be supported with no electrical conversion and no knowledge of the modulation and speed by the transit nodes. Other formats normally require framing knowledge, and field parameters are broken into the framing type and speed as shown below.
一般ラベル要求は、LSPのエンコードタイプと呼ばれるLSPのエンコーディングパラメータを、運びます。このパラメータは、LSPに関連するデータと共に使用される符号化の種類、例えば、SONET / SDH /ギガビットイーサネットなどを示します。 LSPエンコードタイプはLSPの性質ではなく、LSPが横断リンクの性質を表しています。リンクは、支持リンクは、リンクのリソース可用性と容量に応じて、これらの符号化フォーマットのうちの1つまたは複数の信号を搬送し、切り替えることができることを意味する符号化フォーマットのセットをサポートすることができます。たとえば、「ラムダ」エンコーディングで合図LSPを検討してください。このようなLSPがない電気変換及びトランジットノードによって変調速度の知識を用いてサポートされることが予想されます。他の形式は、通常、フレーミング知識を必要とし、以下に示すように、フィールドパラメータは、フレーミングタイプと速度に分割されます。
The Generalized Label Request also indicates the type of switching that is being requested on a link. This field normally is consistent across all links of an LSP.
一般ラベル要求は、リンク上で要求されているスイッチングの種類を示します。このフィールドには、通常、LSPのすべてのリンク全体で一貫しています。
The information carried in a Generalized Label Request is:
一般ラベル要求に運ばれた情報は以下のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type: 8 bits
LSP符号化タイプ：8ビット
Indicates the encoding of the LSP being requested. The following shows permitted values and their meaning:
LSPのエンコーディングが要求されていることを示します。次のショーは、値とその意味を許可しました：
Value Type
----- ----
1 Packet
2 Ethernet
3 ANSI/ETSI PDH
4 Reserved
5 SDH ITU-T G.707 / SONET ANSI T1.105
6 Reserved
7 Digital Wrapper
8 Lambda (photonic)
9 Fiber
10 Reserved
11 FiberChannel
The ANSI PDH and ETSI PDH types designate these respective
networking technologies. DS1 and DS3 are examples of ANSI PDH
LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type
refers to an LSP that encompasses a whole wavelengths. The
Fiber encoding type refers to an LSP that encompasses a whole
fiber port.
Switching Type: 8 bits
スイッチングタイプ：8ビット
Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field should map to one of the values advertised for the corresponding link in the routing Switching Capability Descriptor, see [GMPLS-RTG].
特定のリンク上で実行されなければならないスイッチングのタイプを示します。このフィールドは、機能を切り替える複数のタイプの広告をリンクするために必要とされています。このフィールドは、ルーティングスイッチング能力記述子に対応するリンクのためのアドバタイズのいずれかの値にマッピングする必要があり、参照[GMPLS-RTG]。
The following are currently defined values:
現在定義されている値は次のとおりです。
Value Type
----- ----
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 Layer-2 Switch Capable (L2SC)
100 Time-Division-Multiplex Capable (TDM)
150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)
Generalized PID (G-PID): 16 bits
一般化されたPID（G-PID）：16ビット
An identifier of the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop. Standard Ethertype values are used for packet and Ethernet LSPs; other values are:
LSP、すなわち、そのLSPのクライアント層の識別子によって運ばれるペイロードの識別子。これは、最後から二番目のホップによってLSPの端点における、いくつかの場合にノードによって使用されます。標準イーサタイプ値はパケットとイーサネットのLSPのために使用されます。他の値は次のとおりです。
Value Type Technology
----- ---- ----------
0 Unknown All
1 Reserved
2 Reserved
3 Reserved
4 Reserved
5 Asynchronous mapping of E4 SDH
6 Asynchronous mapping of DS3/T3 SDH
7 Asynchronous mapping of E3 SDH
8 Bit synchronous mapping of E3 SDH
9 Byte synchronous mapping of E3 SDH
10 Asynchronous mapping of DS2/T2 SDH
11 Bit synchronous mapping of DS2/T2 SDH
12 Reserved
13 Asynchronous mapping of E1 SDH
14 Byte synchronous mapping of E1 SDH
15 Byte synchronous mapping of 31 * DS0 SDH
16 Asynchronous mapping of DS1/T1 SDH
17 Bit synchronous mapping of DS1/T1 SDH
18 Byte synchronous mapping of DS1/T1 SDH
19 VC-11 in VC-12 SDH
20 Reserved
21 Reserved
22 DS1 SF Asynchronous SONET
23 DS1 ESF Asynchronous SONET
24 DS3 M23 Asynchronous SONET
25 DS3 C-Bit Parity Asynchronous SONET
26 VT/LOVC SDH
27 STS SPE/HOVC SDH
28 POS - No Scrambling, 16 bit CRC SDH
29 POS - No Scrambling, 32 bit CRC SDH
30 POS - Scrambling, 16 bit CRC SDH
31 POS - Scrambling, 32 bit CRC SDH
32 ATM mapping SDH
33 Ethernet SDH, Lambda, Fiber
34 SONET/SDH Lambda, Fiber
35 Reserved (SONET deprecated) Lambda, Fiber
36 Digital Wrapper Lambda, Fiber
37 Lambda Fiber
38 ANSI/ETSI PDH SDH 39 Reserved SDH 40 Link Access Protocol SDH SDH (LAPS - X.85 and X.86) 41 FDDI SDH, Lambda, Fiber 42 DQDB (ETSI ETS 300 216) SDH 43 FiberChannel-3 (Services) FiberChannel 44 HDLC SDH 45 Ethernet V2/DIX (only) SDH, Lambda, Fiber 46 Ethernet 802.3 (only) SDH, Lambda, Fiber
38 ANSI / ETSI PDH SDH 39留保SDH 40 SDH SDHリンクアクセスプロトコル（ラップ - X.85およびX.86）41 FDDI SDH、ラムダ、ファイバ42 DQDB（ETSI ETS 300 216）SDH 43個のファイバーチャネル-3（サービス）ファイバーチャネル44 HDLC SDH 45イーサネットV2 / DIX（のみ）SDH、ラムダ、ファイバ46イーサネット802.3（のみ）SDH、ラムダ、ファイバ
Bandwidth encodings are carried in 32 bit number in IEEE floating point format (the unit is bytes per second). For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP. Some typical values for the requested bandwidth are enumerated below. (These values are guidelines.) Additional values will be defined as needed. Bandwidth encoding values are carried in a per protocol specific manner, see [RFC3473] and [RFC3472].
帯域エンコーディング（単位は、秒あたりのバイト数である）IEEE浮動小数点形式の32ビット数で運ばれます。非パケットのLSPのために、LSPの帯域幅を識別するために、離散的な値を定義することが有用です。要求された帯域幅のためのいくつかの典型的な値は、以下に列挙されています。 （これらの値はガイドラインです。）必要に応じて追加の値が定義されます。帯域符号化値は[RFC3473]及び[RFC3472]を参照して、プロトコル当たりの特定の方法で実施されます。
Signal Type (Bit-rate) Value (Bytes/Sec)
(IEEE Floating point)
-------------- --------------- ---------------------
DS0 (0.064 Mbps) 0x45FA0000
DS1 (1.544 Mbps) 0x483C7A00
E1 (2.048 Mbps) 0x487A0000
DS2 (6.312 Mbps) 0x4940A080
E2 (8.448 Mbps) 0x4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 Mbps) 0x4A831A80
DS3 (44.736 Mbps) 0x4AAAA780
STS-1 (51.84 Mbps) 0x4AC5C100
Fast Ethernet (100.00 Mbps) 0x4B3EBC20
E4 (139.264 Mbps) 0x4B84D000
FC-0 133M 0x4B7DAD68
OC-3/STM-1 (155.52 Mbps) 0x4B9450C0
FC-0 266M 0x4BFDAD68
FC-0 531M 0x4C7D3356
OC-12/STM-4 (622.08 Mbps) 0x4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
FC-0 1062M 0x4CFD3356
OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0
OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0
The Generalized Label extends the traditional label by allowing the representation of not only labels which travel in-band with associated data packets, but also labels which identify time-slots, wavelengths, or space division multiplexed positions. For example, the Generalized Label may carry a label that represents (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also carry a label that represents a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI).
一般化ラベルはまただけでなく、関連するデータパケットと帯域内移動ラベルが、タイムスロット、波長、または空間分割多重位置を識別ラベルの表現を可能にすることによって、伝統的なラベルを拡張します。例えば、一般化ラベルは、バンドルにおける（A）単一のファイバを表すラベル、（b）は、ファイバ内の単一波長帯、（c）の波長帯（またはファイバ）内の単一波長、または（D）Aを搬送することができます波長（またはファイバ）内のタイムスロットのセット。また、一般的なMPLSラベル、フレームリレーのラベル、またはATMラベル（VCI / VPI）を表しているラベルを運ぶことができます。
A Generalized Label does not identify the "class" to which the label belongs. This is implicit in the multiplexing capabilities of the link on which the label is used.
一般ラベルは、ラベルが属する「クラス」を識別しません。これは、ラベルが使用されているリンクの多重化機能で暗黙的です。
A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS-HIERARCHY].
一般化ラベルのみ、すなわち、それは非階層的であり、ラベルの単一レベルを運びます。ラベルの複数のレベル（のLSP内のLSP）が必要とされる場合、各LSPは別々に確立されなければならない、[MPLS階層を参照してください。
Each Generalized Label object/TLV carries a variable length label parameter.
各汎用ラベルオブジェクト/ TLVは、可変長ラベルパラメータを運びます。
The information carried in a Generalized Label is:
一般ラベルに運ばれた情報は以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Variable Length
レーベル：可変長
Carries label information. The interpretation of this field depends on the type of the link over which the label is used.
ラベル情報を運びます。このフィールドの解釈は、ラベルが使用されている上、リンクの種類によって異なります。
Some configurations of fiber switching (FSC) and lambda switching (LSC) use multiple data channels/links controlled by a single control channel. In such cases the label indicates the data channel/link to be used for the LSP. Note that this case is not the same as when [MPLS-BUNDLE] is being used.
繊維スイッチング（FSC）及びラムダスイッチング（LSC）のいくつかの構成は、単一の制御チャネルによって制御される複数のデータ・チャネル/リンクを使用します。このような場合には、ラベルは、LSPのために使用されるデータチャネル/リンクを示しています。この場合は[MPLS-BUNDLE]が使用されているときと同じではないことに留意されたいです。
The information carried in a Port and Wavelength label is:
ポートと波長ラベルに運ばれた情報は以下のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: 32 bits
レーベル：32ビット
Indicates port/fiber or lambda to be used, from the perspective of the sender of the object/TLV. Values used in this field only have significance between two neighbors, and the receiver may need to convert the received value into a value that has local significance. Values may be configured or dynamically determined using a protocol such as [LMP].
オブジェクト/ TLVの送信者の観点から、使用するポート/繊維又はラムダを示しています。この分野で使用される値は2つのだけネイバー間の有意性を持っており、受信機は、ローカルな意味を持つ値に受信した値を変換する必要があるかもしれません。値は、設定または動的に、このような[LMP]などのプロトコルを使用して決定することができます。
Generic MPLS labels and Frame Relay labels are encoded right justified aligned in 32 bits (4 octets). ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
汎用MPLSラベルとフレームリレーラベルは右に32ビット（4つのオクテット）に並ん正当化符号化されます。 ATMラベルはビット16-31における右寄せのビット0-15及びVCIに正当化VPI権で符号化されます。
A special case of lambda switching is waveband switching. A waveband represents a set of contiguous wavelengths which can be switched together to a new waveband. For optimization reasons it may be desirable for an optical cross connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. The Waveband Label is defined to support this special case.
ラムダスイッチングの特殊なケースは、波長帯の切り替えです。波長帯は、新しい波長帯に一緒に切り替えることができる連続した波長の集合を表します。光クロスコネクトは、光学ユニットとして複数の波長をスイッチに接続するための最適化の理由から、望ましいかもしれません。これは、個々の波長の歪みを低減することができ、個々の波長の緊密な分離を可能にすることができます。波長群のラベルは、この特殊なケースをサポートするために定義されています。
Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way all other upper layer labels are treated.
波長帯は、自然ラベルスイッチング階層の別のレベルを導入し、このような波長帯は、他のすべての上層ラベルが処理されるのと同じ方法で処理されます。
As far as the MPLS protocols are concerned there is little difference between a waveband label and a wavelength label except that semantically the waveband can be subdivided into wavelengths whereas the wavelength can only be subdivided into time or statistically multiplexed labels.
限りMPLSプロトコルが懸念されるように波長のみ時間または統計的に多重化されたラベルに細分することができるのに対し、波長に分割することができ、その意味論的波長帯以外の波長帯のラベルと波長ラベルの間にはほとんど違いがあります。
Waveband switching uses the same format as the generalized label, see section 3.2.1.
波長群スイッチングは、セクション3.2.1を参照して、一般的なラベルと同じ形式を使用しています。
In the context of waveband switching, the generalized label has the following format:
波長帯の切り替えの文脈では、一般的なラベルの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Waveband Id: 32 bits
帯イド：32ビット
A waveband identifier. The value is selected by the sender and reused in all subsequent related messages.
波長帯識別子。値は、送信者によって選択され、それ以降のすべての関連メッセージに再利用されます。
Start Label: 32 bits
ラベルを起動します。32ビット
Indicates the channel identifier of the lowest value wavelength making up the waveband, from the object/TLV sender's perspective.
オブジェクト/ TLVの送信者の観点から、波長帯を構成する最小値の波長のチャネル識別子を示します。
End Label: 32 bits
エンドレーベル：32ビット
Indicates the channel identifier of the highest value wavelength making up the waveband, from the object/TLV sender's perspective.
オブジェクト/ TLVの送信者の観点から、波長帯を構成する最高値の波長のチャネル識別子を示します。
Channel identifiers are established either by configuration or by means of a protocol such as LMP [LMP]. They are normally used in the label parameter of the Generalized Label one PSC and LSC.
チャネル識別子は、コンフィギュレーションによって、またはそのようなLMP [LMP]などのプロトコルの手段のいずれかによって確立されます。彼らは通常、汎用ラベル1 PSCとLSCのラベルパラメータで使用されています。
The Suggested Label is used to provide a downstream node with the upstream node's label preference. This permits the upstream node to start configuring its hardware with the proposed label before the label is communicated by the downstream node. Such early configuration is valuable to systems that take non-trivial time to establish a label in hardware. Such early configuration can reduce setup latency, and may be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.
推奨されるラベルは、上流ノードのラベル優先下流ノードを提供するために使用されます。これは、ラベルが下流ノードによって通信される前に提案されたラベルとそのハードウェアの設定を開始するために、上流ノードを許容します。このような初期の構成は、ハードウェアにラベルを確立するために、非自明な時間がかかるシステムに貴重なものです。このような初期の設定は、セットアップの待ち時間を減らすことができ、および代替のLSPが急速にネットワーク障害の結果として確立する必要があるかもしれない回復のために重要であるかもしれません。
The use of Suggested Label is only an optimization. If a downstream node passes a different label upstream, an upstream LSR reconfigures itself so that it uses the label specified by the downstream node, thereby maintaining the downstream control of a label. Note, the transmission of a suggested label does not imply that the suggested label is available for use. In particular, an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream.
推奨ラベルの使用が唯一の最適化です。下流のノードが上流の異なる標識を通過した場合、それによってラベルの下流制御を維持し、下流ノードによって指定されたラベルを使用するように、上流のLSRは、それ自体を再構成します。注、提案されたラベルの送信が示唆されたラベルが使用可能であることを意味するものではありません。下流のノードが上流のラベルを通過するまで、特に、入口ノードが提案ラベルにデータトラフィックを送信してはなりません。
The information carried in a suggested label is identical to a generalized label. Note, values used in the label field of a suggested label are from the object/TLV sender's perspective.
提案されたラベルに運ばれた情報は一般的なラベルと同じです。提案されたラベルのラベルフィールドで使用される値は、オブジェクト/ TLVの送信者の視点からのもの、注意してください。
The Label Set is used to limit the label choices of a downstream node to a set of acceptable labels. This limitation applies on a per hop basis.
ラベルセットは、許容可能なラベルのセットに下流のノードのラベルの選択肢を制限するために使用されます。この制限は、ホップごとに適用されます。
We describe four cases where a Label Set is useful in the optical domain. The first case is where the end equipment is only capable of transmitting on a small specific set of wavelengths/bands. The second case is where there is a sequence of interfaces which cannot support wavelength conversion (CI-incapable) and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. The third case is where it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals. The last case is where two ends of a link support different sets of wavelengths.
私たちは、ラベルセットは、光領域で有用である4例を説明します。エンド機器が波長/帯域の小さな特定のセット上で送信することができるだけである最初のケースです。波長変換（CI-できない）をサポートし、同じ波長がホップのシーケンス、あるいは経路全体にわたってエンド・ツー・エンドを使用することが必要ではないができるインターフェイスの配列がある場合第二の場合です。光信号に歪みを低減するために行われている波長変換の量を制限することが望ましい場合に第三の場合です。リンクの両端は、波長の異なるセットをサポートするところ最後のケースです。
Label Set is used to restrict label ranges that may be used for a particular LSP between two peers. The receiver of a Label Set must restrict its choice of labels to one which is in the Label Set. Much like a label, a Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces.
ラベルのセットが2つのピア間で、特定のLSPのために使用することができるラベル範囲を制限するために使用されます。ラベルセットの受信機は、ラベルセットである1にラベルのその選択を制限する必要があります。多くのラベルのように、ラベルセットは、複数のホップ間で存在することができます。この場合、各ノードは、おそらく、着信ラベルを設定し、ノードのハードウェア機能に基づいた独自の発信ラベルセットを生成します。この場合には変換できない（CI-できない）インターフェイスを備えたノードのための標準であると予想されます。
The use of Label Set is optional, if not present, all labels from the valid label range may be used. Conceptually the absence of a Label Set implies a Label Set whose value is {U}, the set of all valid labels.
、有効なラベル範囲からすべてのラベルを使用することができる存在しない場合はラベルセットの使用は、オプションです。概念的にラベルセットが存在しない場合は、値{U}、すべての有効なラベルのセットであるラベルセットを意味しています。
A label set is composed of one or more Label_Set objects/TLVs. Each object/TLV contains one or more elements of the Label Set. Each element is referred to as a subchannel identifier and has the same format as a generalized label.
ラベルセットは、1つのまたは複数のLabel_Setオブジェクト/のTLVで構成されています。各オブジェクト/ TLVは、ラベルセットの1つの以上の要素が含まれています。各要素は、サブチャネル識別子と呼ばれ、一般化されたラベルと同じフォーマットを有しています。
The information carried in a Label_Set is:
Label_Setに運ばれる情報は以下のとおりです。
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 | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
アクション：8ビット
0 - Inclusive List
0 - インクルーシブ一覧
Indicates that the object/TLV contains one or more subchannel elements that are included in the Label Set.
オブジェクト/ TLVはラベルセットに含まれている1つまたは複数のサブチャネル要素が含まれていることを示します。
1 - Exclusive List
1 - 排他的なリスト
Indicates that the object/TLV contains one or more subchannel elements that are excluded from the Label Set.
オブジェクト/ TLVはラベルセットから除外されている1つまたは複数のサブチャネル要素が含まれていることを示します。
2 - Inclusive Range
2 - 包含範囲
Indicates that the object/TLV contains a range of labels. The object/TLV contains two subchannel elements. The first element indicates the start of the range. The second element indicates the end of the range. A value of zero indicates that there is no bound on the corresponding portion of the range.
オブジェクト/ TLVはラベルの範囲が含まれていることを示します。オブジェクトは、/ TLVは、二つのサブチャネル要素が含まれています。最初の要素は、範囲の開始を示します。第2の要素は、範囲の端を示します。ゼロの値は、範囲の対応する部分には結合したがないことを示しています。
3 - Exclusive Range
3 - 独占レンジ
Indicates that the object/TLV contains a range of labels that are excluded from the Label Set. The object/TLV contains two subchannel elements. The first element indicates the start of the range. The second element indicates the end of the range. A value of zero indicates that there is no bound on the corresponding portion of the range.
オブジェクト/ TLVはラベルセットから除外されたラベルの範囲が含まれていることを示します。オブジェクトは、/ TLVは、二つのサブチャネル要素が含まれています。最初の要素は、範囲の開始を示します。第2の要素は、範囲の端を示します。ゼロの値は、範囲の対応する部分には結合したがないことを示しています。
Reserved: 10 bits
予約：10ビット
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
このフィールドは予約されています。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Label Type: 14 bits
ラベルタイプ：14ビット
Indicates the type and format of the labels carried in the object/TLV. Values are signaling protocol specific.
オブジェクト/ TLVで運ばれたラベルの種類や形式を示します。値は、プロトコルの特定のシグナリングされています。
Subchannel:
サブチャネル：
The subchannel represents the label (wavelength, fiber ... ) which is eligible for allocation. This field has the same format as described for labels under section 3.2.
サブチャネルは、割り当ての対象となるラベル（波長、繊維...）を表します。このフィールドは、セクション3.2の下のラベルに記載されたものと同じ形式です。
Note that subchannel to local channel identifiers (e.g., wavelength) mappings are a local matter.
ローカルチャネル識別子にそのサブチャネルに留意されたい（例えば、波長）マッピングはローカル問題です。
This section defines direct support of bidirectional LSPs. Support is defined for LSPs that have the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction. In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP and the term "terminator" is used to refer to the node that is the target of the LSP. Note that for bidirectional LSPs, there is only one "initiator" and one "terminator".
このセクションでは、双方向のLSPの直接サポートを定義します。サポートが各方向に運命の共有、保護、修復、のLSR、およびリソース要件（例えば、遅延およびジッタ）を含む同じトラフィックエンジニアリング要件を持っているのLSPのために定義されています。このセクションの残りでは、用語「イニシエータ」は、LSPの確立を開始し、用語「ターミネーター」はLSPの対象であるノードを指すために使用されているノードを指すために使用されます。双方向のLSPのために、唯一の「イニシエータ」と一つの「ターミネーター」があることに注意してください。
Normally to establish a bidirectional LSP when using [RFC3209] or [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages:
通常は[RFC3209]または[RFC3212] 2つの単方向経路を使用した場合、双方向LSPを確立するために独立して確立されなければなりません。このアプローチは、次のような欠点があります。
* The latency to establish the bidirectional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it extends the worst-case latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes.
*双方向LSPを確立するための待ち時間は1回のラウンドトリップシグナリング時間プラスワンイニシエータターミネーターシグナル伝送遅延に等しいです。これが成功したLSPの確立のためのセットアップ・レイテンシを拡張するだけでなく、限り2回の開始剤 - ターミネーター通過遅延に失敗したLSPを発見するための最悪の場合の待ち時間を延長します。これらの遅延は、復旧のために確立されたLSPのために特に重要です。
* The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bidirectional LSP.
*制御オーバーヘッドはその倍の単方向LSPのです。別個の制御メッセージ（例えば、パスとのResv）は、双方向LSPの両方のセグメントについて生成しなければならないためです。
* Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bidirectional connection.
*リソースは別々のセグメントに確立されているので、ルート選択は複雑です。成功した双方向の接続を確立するの全体的な確率を減少させ、リソースの割り当て、中状態のため、追加の潜在的な競合もあります。
* It is more difficult to provide a clean interface for SONET/SDH equipment that may rely on bidirectional hop-by-hop paths for protection switching.
*保護スイッチングのための双方向のホップバイホップの経路に依存することがSONET / SDH機器のためのクリーンなインターフェイスを提供することはより困難です。
* Bidirectional optical LSPs (or lightpaths) are seen as a requirement for many optical networking service providers.
*双方向光のLSP（または光パス）は、多くの光ネットワーク・サービス・プロバイダのための要件として見られています。
With bidirectional LSPs both the downstream and upstream data paths, i.e., from initiator to terminator and terminator to initiator, they are established using a single set of signaling messages. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.
イニシエータからのターミネーターおよび開始するターミネーターに双方向のLSPの両方のダウンストリームとアップストリームデータパス、すなわち、と、それらはシグナリングメッセージの単一のセットを使用して確立されます。これは、本質的に1つのイニシエータターミネーターラウンドトリップ時間と処理時間に設定待ち時間を低減し、及び一方向LSPなどのメッセージの同じ数に制御オーバーヘッドを制限します。
For bidirectional LSPs, two labels must be allocated. Bidirectional LSP setup is indicated by the presence of an Upstream Label object/TLV in the appropriate signaling message. An Upstream Label has the same format as the generalized label, see Section 3.2.
双方向のLSPのために、2つのラベルを割り当てる必要があります。双方向LSPセットアップは、適切なシグナリングメッセージの上流ラベルオブジェクト/ TLVの存在によって示されます。上流のラベルは、3.2節を参照してください、一般的なラベルと同じ形式を持っています。
Contention for labels may occur between two bidirectional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (labels) at effectively the same time. If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources, then both nodes will pass different labels upstream and there is no contention. However, if there is a restriction on the labels that can be used for the bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), or if there are no more resources available, then the contention must be resolved by other means. To resolve contention, the node with the higher node ID will win the contention and it MUST issue a PathErr/NOTIFICATION message with a "Routing problem/Label allocation failure" indication. Upon receipt of such an error, the node SHOULD try to allocate a different Upstream label (and a different Suggested Label if used) to the bidirectional path. However, if no other resources are available, the node must proceed with standard error handling.
ラベルの競合は反対方向に走行する2つの双方向LSP設定要求の間発生することがあります。両側が効果的に同時に同じリソース（ラベル）を割り当てる場合、この競合が発生します。双方向のLSPのために使用することができる標識には制限がない場合、代替リソースがある場合、両方のノードが上流の異なる標識を通過し、いかなる競合は存在しません。しかし、（彼らは物理的に1つのI / Oカードに結合されなければならない場合、例えば）双方向のLSPのために使用することができるラベルに制限が存在する場合、または使用可能なより多くのリソースが存在しない場合、競合がなければなりません他の手段によって解決されます。競合を解決するには、高いノードIDを持つノードが競合に勝つだろうし、それは、「ルーティング問題/ラベル割り当ての失敗」の表示とのPathErr / NOTIFICATIONメッセージを発行しなければなりません。このようなエラーを受信すると、ノードは、（使用する場合と異なる推奨ラベル）双方向パスに異なる上流のラベルを割り当てることを試みるべきです。他のリソースが利用可能でない場合は、ノードは、標準エラー処理を進める必要があります。
To reduce the probability of contention, one may impose a policy that the node with the lower ID never suggests a label in the downstream direction and always accepts a Suggested Label from an upstream node with a higher ID. Furthermore, since the labels may be exchanged using LMP, an alternative local policy could further be imposed such that (with respect to the higher numbered node's label set) the higher numbered node could allocate labels from the high end of the label range while the lower numbered node allocates labels from the low end of the label range. This mechanism would augment any close packing algorithms that may be used for bandwidth (or wavelength) optimization. One special case that should be noted when using RSVP and supporting this approach is that the neighbor's node ID might not be known when sending an initial Path message. When this case occurs, a node should suggest a label chosen at random from the available label space.
競合の確率を低減するためには、より低いIDを有するノードが決して下流方向にラベルを示唆していない、常により高いIDを持つ上流ノードから推奨ラベルを受け付けるポリシーを課すことができます。ラベルはLMPを使用して交換することができるので、別のローカルポリシーは、さらに高い番号のノードが低いながら、ラベル範囲の高い端部からラベルを割り当てることができ、このような（より高い番号のノードのラベルセットに対して）ことが課される可能性が番ノードは、ラベル範囲のローエンドからラベルを割り当てます。この機構は、帯域幅（又は波長）最適化のために使用することができる任意近いパッキングアルゴリズムを増大させるであろう。 RSVPを使用して、このアプローチをサポートする際に注意すべき一つの特別なケースでは、最初のPathメッセージを送信する際に、近隣のノードのIDが知られていない可能性がありますということです。この場合は、発生した場合、ノードは、利用可能なラベルスペースからランダムに選ばれたラベルを提案すべきです。
An example of contention between two nodes (PXC 1 and PXC 2) is shown in Figure 1. In this example PXC 1 assigns an Upstream Label for the channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and sends a Suggested Label for the channel corresponding to local BCId=1 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label for the channel corresponding to its local BCId=6 (local BCId=1 on PXC 1) and sends a Suggested Label for the channel corresponding to its local BCId=7 (local BCId=2 on PXC 1). If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources available, then both PXC 1 and PXC 2 will pass different labels upstream and the contention is resolved naturally (see Fig. 2). However, if there is a restriction on the labels that can be used for bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), then the contention must be resolved using the node ID (see Fig. 3).
二つのノード（PXC 1及びPXC 2）間の競合の例は、この例では、PXC 1では、図1に示されていることに対応するチャネルの上流のラベルを割り当てるローカルBCID = 2（ローカルBCID = 7 PXC 2上）と送信しますローカルBCID = 1（ローカルBCID = 6 PXC 2上）に対応するチャンネルの推奨ラベル。同時に、PXC 2は、そのローカルBCID = 6（PXC 1にBCID = 1ローカル）に対応するチャネルの上流のラベルを割り当て、PXC 1にBCID = 2 BCID = 7（ローカルローカルに対応するチャネルのための提案されたラベルを送信します）。 （図2参照）が上流の異なる標識を通過する代替リソースが利用可能である場合、双方向のLSPのために使用することができ、ラベルは、PXC 1及びPXC 2の両方に制限がなく、競合が自然に解決される場合。双方向のLSPのために使用することができる標識に制限がある場合（それらが物理的に1つのI / Oカードに結合されなければならない場合など）しかしながら、その後の競合は、ノードIDを使用して解決されなければならない（図4参照。 3）。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + SL1,UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1, SL2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + + +
+ 3 +------------------------>+ 8 +
+ + + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 1. Label Contention
In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1).
この例では、PXC 1（PXC 2にBCID = 7）BCID = 2を使用して上流のラベルおよび使用推奨ラベルを割り当てBCID = 1（BCID = 6 PXC 2上）。同時に、PXC 2はBCID = 6（PXC 1にBCID = 1）を用いて上流のラベルとBCID = 7（PXC 1にBCID = 2）を使用して推奨ラベルを割り当てます。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + L2 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 2. Label Contention Resolution without resource restrictions
リソースの制約のない図2.ラベルのコンテンション解消
In this example, there is no restriction on the labels that can be used by the bidirectional connection and there is no contention.
この例では、双方向接続によって使用されない競合が存在しないことができるラベルに制限はありません。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + L2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + UL1 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 3. Label Contention Resolution with resource restrictions
リソースの制約の図3.ラベルのコンテンション解消
In this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on PXC 2, respectively) must be used by the same bidirectional connection. Since PXC 2 has a higher node ID, it wins the contention and PXC 1 must use a different set of labels.
この例では、同一の双方向接続によって使用されなければならないPXC 1上の1,2及び3,4（それぞれ、PXC 2上の6,7及び8,9ラベル）ラベル。 PXC 2は、より高いノードIDを有しているので、競合に勝つとPXC 1は、ラベルの異なるセットを使用しなければなりません。
There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication, see [RFC3209], [RFC3472] and [RFC3473]. When these cases occur, it can be useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages, see [RFC3472] and [RFC3473].
「許可されないラベル値」表示を含むエラーメッセージが表示され、伝統的なMPLSおよびGMPLSのケースがあり、[RFC3472]及び[RFC3473]を[RFC3209]を参照。これらのケースが発生したとき、それはラベルが許容可能であるかを示すためにエラーメッセージを生成するノードのために有用であり得ます。このケースをカバーするために、GMPLSは、「受け入れ可能なラベルセット」を介して、このような情報を伝えるための機能が導入されました。許容可能なラベルセットが適切なプロトコル固有のエラーメッセージで運ばれ、[RFC3472]と[RFC3473]を参照してください。
The format of an Acceptable Label Set is identical to a Label Set, see section 3.5.1.
許容ラベル設定の形式は、ラベルセットと同じである、セクション3.5.1を参照してください。
In traditional MPLS, the interfaces used by an LSP may be controlled via an explicit route, i.e., ERO or ER-Hop. This enables the inclusion of a particular node/interface, and the termination of an LSP on a particular outgoing interface of the egress LSR. Where the interface may be numbered or unnumbered, see [MPLS-UNNUM].
従来のMPLSにおいて、LSPによって使用されるインターフェースは、明示的経路、すなわち、EROまたはERホップを介して制御することができます。これは、特定のノード/インタフェースの包含、および出口LSRの特定の発信インターフェイス上のLSPの終了を可能にします。インタフェースは番号または番号なしすることができる場合、参照[MPLS-UNNUM]。
There are cases where the existing explicit route semantics do not provide enough information to control the LSP to the degree desired. This occurs in the case when the LSP initiator wishes to select a label used on a link. Specifically, the problem is that ERO and ER-Hop do not support explicit label sub-objects. An example case where such a mechanism is desirable is where there are two LSPs to be "spliced" together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP. This last case is more likely to be used in the non-PSC classes of links.
既存の明示的経路セマンティクスが所望の程度にLSPを制御するのに十分な情報を提供しない場合があります。 LSPのイニシエータは、リンク上で使用するラベルを選択したいとき、これは場合に発生します。具体的には、問題がEROとERホップが明示的なラベルサブオブジェクトをサポートしていないということです。最初のLSPの尾部は、第二LSPの先頭に「スプライシングされる」ことになる一緒に「スプライシングされた」される2つのLSP、すなわち、存在する場合、そのような機構が望ましい例の場合です。この最後のケースでは、リンクの非PSCのクラスで使用される可能性が高いです。
To cover this case, the Label ERO subobject / ER Hop is introduced.
このケースをカバーするために、ラベルEROサブオブジェクト/ ERホップが導入されます。
The Label Explicit and Record Routes contains:
ラベル明示とレコードルートが含まれています。
L: 1 bit
L：1ビット
This bit must be set to 0.
このビットは0に設定する必要があります。
U: 1 bit
U：1ビット
This bit indicates the direction of the label. It is 0 for the downstream label. It is set to 1 for the upstream label and is only used on bidirectional LSPs.
このビットは、ラベルの方向を示しています。これは、下流のラベルは0です。これは、上流のラベルを1に設定されているだけで、双方向のLSP上で使用されています。
Label: Variable
レーベル：変数
This field identifies the label to be used. The format of this field is identical to the one used by the Label field in Generalized Label, see Section 3.2.1.
このフィールドは、使用するラベルを識別します。このフィールドの形式は一般ラベルでラベルフィールドで使用されるものと同じである、3.2.1項を参照してください。
Placement and ordering of these parameters are signaling protocol specific.
これらのパラメータの配置および順序は、プロトコルの特定のシグナリングされています。
Protection Information is carried in a new object/TLV. It is used to indicate link related protection attributes of a requested LSP. The use of Protection Information for a particular LSP is optional. Protection Information currently indicates the link protection type desired for the LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that the protection capabilities of a link may be advertised in routing, see [GMPLS-RTG]. Path computation algorithms may take this information into account when computing paths for setting up LSPs.
保護情報は、新しいオブジェクト/ TLVで運ばれます。要求されたLSPのリンク関連の保護属性を示すために使用されます。特定のLSPの保護情報の使用はオプションです。保護情報は、現在、LSPのために必要なリンク保護タイプを示します。すなわち、1 + 1、又は1、特に保護タイプの場合：N、要求され、次いで、接続要求は、所望の保護型が表彰することができる場合にのみ処理されます。リンクの保護機能は、ルーティングでアドバタイズされてもよいことに留意されたい、[GMPLS-RTG]参照。 LSPを設定するための経路を計算するときに経路計算アルゴリズムは、この情報を考慮することができます。
Protection Information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are not used until the primary LSP fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP MUST be preempted.
LSPは、プライマリまたはセカンダリLSPであれば保護情報も示します。二次LSPは、一次LSPにバックアップです。主LSPに障害が発生するまで、二次LSPのリソースが使用されていません。一次LSPは、二次LSPにフェイルオーバーするまで二次LSPに割り当てられたリソースは、他のLSPによって使用されてもよいです。その時点で、二次LSPのリソースを使用している任意のLSPをプリエンプトされなければなりません。
The following information is carried in Protection Information:
次の情報が保護情報で運ばれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S): 1 bit
二次（S）：1ビット
When set, indicates that the requested LSP is a secondary LSP.
設定すると、要求されたLSPが二次LSPであることを示しています。
Reserved: 25 bits
予約：25ビット
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes.
このフィールドは予約されています。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。これらのビットは、トランジットノードによって修飾されていない通過されるべきです。
Link Flags: 6 bits
リンクフラグ：6ビット
Indicates desired link protection type. As previously mentioned, protection capabilities of a link may be advertised in routing. A value of 0 implies that any, including no, link protection may be used. More than one bit may be set to indicate when multiple protection types are acceptable. When multiple bits are set and multiple protection types are available, the choice of protection type is a local (policy) decision.
目的のリンク保護タイプを示します。前述したように、リンクの保護機能は、ルーティングで広告することができます。 0の値は、リンクの保護を使用することができるなど、いずれかのことを意味します。複数のビットは、複数の保護タイプが許容可能であることを示すために設定されてもよいです。複数のビットが設定されていて、複数の保護タイプが用意されていている場合は、保護タイプの選択は、ローカル（ポリシー）の決定です。
The following flags are defined:
次のフラグが定義されています。
0x20 Enhanced
0x20の強化
Indicates that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING.
+ 1専用よりも信頼性が高い保護方式は、例えば、4ファイバBLSR / MS-SPRING、使用されるべきであることを示しています。
0x10 Dedicated 1+1
0x10の専用1 + 1
Indicates that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP.
専用リンク層保護スキーム、すなわち、1 + 1保護は、LSPをサポートするために使用されるべきであることを示します。
0x08 Dedicated 1:1
0x08の1専用：1
Indicates that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP.
1保護、LSPをサポートするために使用されるべきである：専用リンクレイヤプロテクションスキーム、即ち、1はことを示しています。
0x04 Shared
0x04を共有
Indicates that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP.
例えば1などの共有リンクレイヤプロテクションスキーム、ことを示している：N保護、LSPをサポートするために使用されるべきです。
0x02 Unprotected
0x02で保護されていません
Indicates that the LSP should not use any link layer protection.
LSPは、任意のリンク層の保護を使用してはならないことを示します。
0x01 Extra Traffic
0x01の余分なトラフィック
Indicates that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail.
LSPは、他の（プライマリ）トラフィックを保護しているリンクを使用する必要があることを示します。 （一次）を運ぶリンクトラフィックが保護されているが失敗したとき、そのようなLSPはプリエンプトしてもよいです。
Administrative Status Information is carried in a new object/TLV. Administrative Status Information is currently used in two ways. In the first, the information indicates administrative state with respect to a particular LSP. In this usage, Administrative Status Information indicates the state of the LSP. State indications include "up" or "down", if it is in a "testing" mode, and if deletion is in progress. The actions taken by a node based on a state local decision. An example action that may be taken is to inhibit alarm reporting when an LSP is in "down" or "testing" states, or to report alarms associated with the connection at a priority equal to or less than "Non service affecting".
管理ステータス情報は、新しいオブジェクト/ TLVで運ばれます。管理ステータス情報は、現在、2つの方法で使用されます。最初に、情報は、特定のLSPに対する管理状態を示しています。この使用法では、管理ステータス情報は、LSPの状態を示します。削除が進行中であるならば、それは「テスト」モードになっている、とあれば状態表示は、「アップ」または「ダウン」が含まれます。状態ローカル決定に基づいて、ノードが実行したアクション。 LSPが「ダウン」または「テスト」状態にある、またはそれに等しいまたは「非サービスに影響」未満優先の接続に関連付けられたアラームを報告するときに取り得る例のアクションは、アラームレポートを阻害することです。
In the second usage of Administrative Status Information, the information indicates a request to set an LSP's administrative state. This information is always relayed to the ingress node which acts on the request.
管理ステータス情報の第2の使用では、情報はLSPの管理状態を設定するための要求を示します。この情報は常に要求に作用する入口ノードに中継されます。
The different usages are distinguished in a protocol specific fashion. See [RFC3473] and [RFC3472] for details. The use of Administrative Status Information for a particular LSP is optional.
さまざまな用途には、プロトコルの特定の様式で区別されています。詳細については、[RFC3473]と[RFC3472]を参照してください。特定のLSPのための管理ステータス情報の使用はオプションです。
The following information is carried in Administrative Status Information:
以下の情報は、管理ステータス情報で運ばれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit
反映（R）：1ビット
When set, indicates that the edge node SHOULD reflect the object/TLV back in the appropriate message. This bit MUST NOT be set in state change request, i.e., Notify, messages.
設定した場合、エッジノードは、バック適切なメッセージ内のオブジェクト/ TLVを反映すべきであることを示しています。このビットは、即ち、通知、状態変更要求のメッセージを設定してはいけません。
Reserved: 28 bits
予約：28ビット
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt. These bits SHOULD be pass through unmodified by transit nodes.
このフィールドは予約されています。これは、送信時にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。これらのビットは、トランジットノードによって修飾されていない通過されるべきです。
Testing (T): 1 bit
試験（T）：1ビット
When set, indicates that the local actions related to the "testing" mode should be taken.
設定した場合、「テスト」モードに関連するローカルアクションが取られるべきであることを示しています。
Administratively down (A): 1 bit
管理上のダウン（A）：1ビット
When set, indicates that the local actions related to the "administratively down" state should be taken.
設定した場合、「管理上のダウン」状態に関連するローカルアクションが取られるべきであることを示しています。
Deletion in progress (D): 1 bit
進行中の削除（D）：1ビット
When set, indicates that that the local actions related to LSP teardown should be taken. Edge nodes may use this flag to control connection teardown.
設定した場合、LSPティアダウンに関連するローカルアクションが取られるべきであることをことを示しています。エッジノードは、接続ティアダウンを制御するために、このフラグを使用してもよいです。
The concept of a control channel being different than a data channel being signaled was introduced to MPLS in connection with link bundling, see [MPLS-BUNDLE]. In GMPLS, the separation of control and data channel may be due to any number of factors. (Including bundling and other cases such as data channels that cannot carry in-band control information.) This section will cover the two critical related issues: the identification of data channels in signaling and handling of control channel failures that don't impact data channels.
制御チャネルの概念は、データチャネルとは異なるされ、リンクバンドルに関連してMPLS [MPLS-BUNDLE]を参照するために導入された合図されます。 GMPLSにおいて、制御及びデータチャネルの分離は、任意の数の要因に起因し得ます。 （バンドルそのようなインバンド制御情報を運ぶことができないデータ・チャネルのような他の場合を含む。）このセクションでは、2つの重要な関連する問題について説明します：データチャネルに影響を与えない制御チャネル障害のシグナリングにおけるデータチャネルの識別および取り扱いを。
In traditional MPLS there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel. (It is implicit in the control channel over which the signaling messages are sent.)
従来のMPLSにデータチャネルに対する制御チャネルの暗黙的な一対一の関連があります。そのような関連付けが存在する場合、追加の又は特別な情報は、特定のデータチャネルと、特定のLSPセットアップトランザクションを関連付けるために必要とされません。 （これは、シグナリングメッセージが送信される上に制御チャネルで暗黙です。）
In cases where there is not an explicit one-to-one association of control channels to data channels it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (see [MPLS-UNNUM]) and component interfaces (established via configuration or a protocol such as [LMP]). In all cases the choice of the data interface is indicated by the upstream node using addresses and identifiers used by the upstream node.
データチャネルに対する制御チャネルの明示的な一対一の関連がない場合では、制御される特定のデータチャネルを識別するために、シグナリングに追加的な情報を伝える必要があります。 GMPLSは、インタフェース識別情報を提供することによって、明示的なデータチャネル識別をサポートします。 GMPLSは、（[LMP]として構成またはプロトコルを介して確立された）IPv4またはIPv6アドレス、インターフェースインデックス（[MPLS-UNNUM]を参照）、コンポーネント・インタフェースを含むインタフェース識別方式の数の使用を可能にします。全ての場合において、データインターフェースの選択は、上流のノードによって使用されるアドレスと識別子を用いて、上流ノードにより示されています。
The following information is carried in Interface_ID:
以下の情報はInterface_IDに実施されます：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where each TLV has the following format:
各TLVは、次の形式を有する場合：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits
長さ：16ビット
Indicates the total length of the TLV, i.e., 4 + the length of the value field in octets. A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-octet aligned.
オクテットの値フィールドの長さ+ TLVの長さの合計を示し、すなわち、4。 TLVは4オクテット整列されるように、その長さが4の倍数でない値フィールドはゼロ埋めなければなりません。
Type: 16 bits
種類：16ビット
Indicates type of interface being identified. Defined values are:
インタフェースの種類が特定されていることを示します。定義された値は次のとおりです。
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 See below IF_INDEX (Interface Index)
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 See below COMPONENT_IF_UPSTREAM (Component interface)
For types 3, 4 and 5 the Value field has the format:
タイプ3、4および5の値フィールドは、フォーマットを有します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
IPアドレス：32ビット
The IP address field may carry either an IP address of a link or an IP address associated with the router, where associated address is the value carried in a router address TLV of routing.
IPアドレスフィールドは、リンクのIPアドレスまたは関連するアドレスがルーティングのルータアドレスTLVで搬送される値であるルータに関連付けられたIPアドレスのいずれかを運ぶことができます。
Interface ID: 32 bits
インターフェイスID：32ビット
For type 3 usage, the Interface ID carries an interface identifier.
タイプ3の使用のために、インタフェースIDは、インタフェース識別子を運びます。
For types 4 and 5, the Interface ID indicates a bundled component link. The special value 0xFFFFFFFF can be used to indicate the same label is to be valid across all component links.
タイプ4および5のために、インタフェースIDは、バンドルコンポーネントリンクを示しています。 0xFFFFFFFFには、同じラベルを示すために使用することができる特別な値は、すべてのコンポーネントリンク全体で有効になることです。
There are two new faults that must be handled when the control channel is independent of the data channel. In the first, there is a link or other type of failure that limits the ability of neighboring nodes to pass control messages. In this situation, neighboring nodes are unable to exchange control messages for a period of time. Once communication is restored the underlying signaling protocol must indicate that the nodes have maintained their state through the failure. The signaling protocol must also ensure that any state changes that were instantiated during the failure are synchronized between the nodes.
制御チャネルは、データチャネルとは独立したときに処理されなければならない2つの新しい断層があります。最初に、制御メッセージを渡すために隣接ノードの能力を制限するリンクや失敗の他のタイプがあります。この状況では、隣接ノードは、時間の期間のための制御メッセージを交換することができません。通信が復元されると、基礎となるシグナリングプロトコルは、ノードが障害を通ってその状態を維持していることを示さなければなりません。シグナリングプロトコルは、障害時にインスタンス化された任意の状態変化は、ノード間で同期されていることを確認しなければなりません。
In the second, a node's control plane fails and then restarts and losses most of its state information. In this case, both upstream and downstream nodes must synchronize their state information with the restarted node. In order for any resynchronization to occur the node undergoing the restart will need to preserve some information, such as its mappings of incoming to outgoing labels.
第二には、ノードの制御プレーンは失敗し、その状態情報のほとんどを再起動し、損失。この場合、上流および下流の両方のノードが再起動ノードとそれらの状態情報を同期化しなければなりません。再起動を受けたノードを発生する任意の再同期ためには、このような、発信ラベルに着信のそのマッピングなど、いくつかの情報を保存する必要があります。
Both cases are addressed in protocol specific fashions, see [RFC3473] and [RFC3472].
どちらの場合は、[RFC3473]及び[RFC3472]を参照して、プロトコル特定様式で対処されます。
Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures.
制御チャネル障害の独立したデータチャネルの障害を検出するためのメカニズムが存在する場合、これらの場合にのみ適用されます。
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
この文書は、多くの作家の作品であり、この分野における以前の文書数の組成物で構成されています。
Valuable comments and input were received from a number of people, including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this document are based on text proposed by Fong Liaw.
貴重なコメント入力はイゴールBryskin、エードリアンファレル、ベン・マック・クレーン、ディミトリPapadimitriou、フォンLiawとユルゲンハイレス含めた人の数、から受け取りました。このドキュメントのいくつかのセクションでは、フォンLiawによって提案されたテキストに基づいています。
This document introduce no new security considerations to either [RFC3212] or [RFC3209]. The security considerations mentioned in [RFC3212] or [RFC3209] apply to the respective protocol specific forms of GMPLS, see [RFC3473] and [RFC3472].
この文書では、[RFC3212]か[RFC3209]のいずれかに全く新しいセキュリティの考慮事項を導入しません。 [RFC3212]または[RFC3209]に記載されたセキュリティ問題[RFC3473]及び[RFC3472]を参照して、GMPLSの各プロトコルの特定の形態にも適用されます。
The IANA will administer assignment of new values for namespaces defined in this document. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANAは、この文書で定義された名前空間に新しい値の割り当てを管理します。このセクションでは、[BCP26]「RFCでIANA問題部に書くためのガイドライン」BCP 26の用語を使用しています。
This document defines the following namespaces:
このドキュメントでは、次の名前空間を定義します。
o LSP Encoding Type: 8 bits o Switching Type: 8 bits o Generalized PID (G-PID): 16 bits o Action: 8 bits o Interface_ID Type: 16 bits
O LSP符号化タイプ：スイッチングタイプO 8ビット：一般PID（G-PID）O 8ビット：アクションO 16ビット：Interface_IDタイプO 8ビット：16ビット
All future assignments should be allocated through IETF Consensus action or documented in a Specification.
すべての将来の割り当ては、IETF Consensus動作によって割り当てられたか、仕様書に記載しなければなりません。
LSP Encoding Type - valid value range is 1-255. This document defines values 1-11.
LSPエンコーディングタイプ - 有効な値の範囲は1〜255です。この文書では、値1-11を定義します。
Switching Type - valid value range is 1-255. This document defines values 1-4, 100, 150 and 200.
スイッチングタイプ - 有効な値の範囲は1〜255です。この文書では、値1-4、100、150および200を画定します。
Generalized PID (G-PID) - valid value range is 0-1500. This document defines values 0-46.
一般化されたPID（G-PID） - 有効な値の範囲は0から1500です。この文書では、値が0から46までを定義します。
Action - valid value range is 0-255. This document defines values 0-3.
アクション - 有効な値の範囲は0〜255です。この文書では、値0-3を定義します。
Interface_ID Type - valid value range is 1-65535. This document defines values 1-5.
Interface_IDタイプ - 有効な値の範囲は1〜65535です。この文書では、値1-5を定義します。
This section is taken from Section 10.4 of [RFC2026].
このセクションは、[RFC2026]のセクション10.4から取られます。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[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月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[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：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209、2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T. and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、E.、Heinanen、J.、Kilty、T.およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、2002年1月。
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]アッシュウッド・スミス、P。およびL.バーガー、エディターズ、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング - 制約ベースルーティングラベル配布プロトコル（CR-LDP）の拡張"、RFC 3472、2003年1月。
[RFC3473] Berger, L., Editor "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月。
[GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support of Generalized MPLS", Work in Progress.
[GMPLS-RTG] Kompella、K.、ら。、 "一般化MPLSのサポートにルーティング拡張"、ProgressのWork。
[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH Specifics", Work in Progress.
[GMPLS-SONET]アッシュウッド・スミス、P.ら、 "GMPLS - SONET / SDH細目"、ProgressのWork。
[LMP] Lang, et al., "Link Management Protocol", Work in Progress.
[LMP]ラングら、「リンク管理プロトコル」が進行中で働いて。
[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[MPLS-BUNDLE] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSトラフィックエンジニアリングでのリンクバンドル" が進行中で働いています。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS階層] Kompella、K.、およびY. Rekhter、 "MPLS TE LSPと階層"、ProgressのWork。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3、" BCP 9、RFC 2026、1996年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol label switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
ピーター・アッシュウッド・スミスノーテルネットワークス株式会社の私書箱K1Y 4H7カナダONボックス3511駅のC、オタワ、
Phone: +1 613 763 4534 EMail: petera@nortelnetworks.com
電話：+1 613 763 4534 Eメール：petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
アヤンバネルジーCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
Phone: +1 408 972-3645 EMail: abanerjee@calient.net
電話：+1 408 972-3645 Eメール：abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルー・バーガーMovazネットワークス株式会社7926ジョーンズ支店ドライブスイート615マクリーンVA、22102
Phone: +1 703 847-1801 EMail: lberger@movaz.com
電話：+1 703 847-1801 Eメール：lberger@movaz.com
Greg Bernstein
グレッグ・バーンスタイン
EMail: gregb@grotto-networking.com
メールアドレス：gregb@grotto-networking.com
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョン・ドレイクCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
Phone: +1 408 972 3720 EMail: jdrake@calient.net
電話：+1 408 972 3720 Eメール：jdrake@calient.net
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
YanheファンAxiowaveネットワークス株式会社200ニッカーソン道路マールボロ、MA 01752
Phone: + 1 774 348 4627 EMail: yfan@axiowave.com
電話：+ 1 774 348 4627 Eメール：yfan@axiowave.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194 N.マチルダアベニュー。サニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
ジョナサンP.ラングEメール：jplang@ieee.org
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium EMail: eric_mannie@hotmail.com
エリック・マニー独立コンサルタント2マッドソング1050ブリュッセルベルギーの電子メールのアベニュー：eric_mannie@hotmail.com
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
バラRajagopalan Tellium、Inc.の2クレセント置き私書箱ボックス901 Oceanport、NJ 07757から0901
Phone: +1 732 923 4237 Fax: +1 732 923 9804 EMail: braja@tellium.com
電話：+1 732 923 4237ファックス：+1 732 923 9804 Eメール：braja@tellium.com
Yakov Rekhter Juniper Networks, Inc.
ヤコフ・レックタージュニパーネットワークス株式会社
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Debanjan Saha EMail: debanjan@acm.org
DebanjanサハEメール：debanjan@acm.org
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174 Phone: +1 650-386-6723 EMail: v.sharma@ieee.org
ヴィシャル・シャルマMetanoia、Inc.の1600ヴィラ・ストリート、ユニット352マウンテンビュー、カリフォルニア州94041から1174電話：+1 650-386-6723電子メール：v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
ジョージツバメシスコシステムズ社250アポロドライブチェルムズフォード、MA 01824
Phone: +1 978 244 8143 EMail: swallow@cisco.com
電話：+1 978 244 8143 Eメール：swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z.ボー唐Eメール：botang01@yahoo.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルー・バーガーMovazネットワークス株式会社7926ジョーンズ支店ドライブスイート615マクリーンVA、22102
Phone: +1 703 847-1801 EMail: lberger@movaz.com
電話：+1 703 847-1801 Eメール：lberger@movaz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。