[要約] 要約： RFC 3471は、Generalized Multi-Protocol Label Switching（GMPLS）シグナリングの機能的な説明を提供しています。GMPLSは、異なるプロトコルを使用してラベルスイッチングを行うための一般化されたアーキテクチャです。目的： このRFCの目的は、GMPLSシグナリングの機能を詳細に説明し、ネットワークの制御と管理を向上させるためのガイドラインを提供することです。
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
一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明
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.
Copyright（c）The Internet Society（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は、MPLSコントロールプレーンを拡張して、時間帯（例えば、同期光ネットワークと同期デジタル階層、SONET/SDH）、波長（光lambdas）および空間スイッチング（たとえば、出力ポートまたは発信ポートまたはファイバーへの繊維）を包含します。このドキュメントは、拡張機能の機能的な説明を示しています。プロトコル固有の形式とメカニズム、およびテクノロジー固有の詳細は、個別のドキュメントで指定されています。
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）パケットヘッダーを処理できる（b）パケット境界を認識できるLSRの場合、（b）転送面があると想定されています。）またはセルヘッダー（細胞境界を認識できる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、またはより正確にLSRSのインターフェイスを次のクラスに細分化できます。
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）の概念を使用すると、転送階層を構築することでシステムを拡張できます。この階層の上部には、FSCインターフェイスがあり、LSCインターフェイスが続き、続いてTDMインターフェイスが続き、続いてPSCインターフェイスが続きます。このようにして、PSCインターフェイスで開始および終了するLSPは、（他のLSPとともに）TDMインターフェイスで開始および終了するLSPにネストできます。このLSPは、（他のLSPと一緒に）LSCインターフェイスで開始および終了する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]で定義されています。このドキュメントでは、MPLS制御プレーンを一般化して4つのクラスのインターフェイスのそれぞれをサポートするために必要な拡張機能の機能的な説明を示します。このドキュメントでは、シグナリングプロトコルの独立した形式と定義のみが提供されています。プロトコル固有の形式は、[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
一般化されたMPLSは、複数の種類のスイッチング、つまりTDM、Lambda、およびFiber（ポート）スイッチングのサポートの追加をサポートするという点で、従来の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では、IPを運ぶLSPがルーターで開始および終了する必要があります。一般化されたMPLSは、LSPが同様のタイプのLSRを起動および終了することを要求することにより、これを拡張します。また、一般化されたMPLSは、LSPによって運ばれるペイロードのタイプを拡張して、SONET/SDHまたは1または10GBイーサネットなどのペイロードを許可するように拡張されます。従来のMPLからのこれらの変更は、一般化されたMPLでラベルがどのように要求され、伝達されるかに反映されています。セクション3.1および3.2を参照してください。波路スイッチングと呼ばれるラムダスイッチングの特殊なケースについては、セクション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タイプのもう1つの基本的な違いは、LSPの帯域幅割り当てが離散ユニットでのみ実行できることです。セクション3.1.3を参照してください。また、PSCリンクよりも（PSC以外のリンクでは（はるかに）少ないラベルがある可能性があります。[MPLS階層]を参照する隣接（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を確立するときに価値があります。たとえば、マイクロミラーを上げたり動かしたりする必要がある場合があり、この物理的な動きとその後の減衰には時間がかかります。ラベルとスイッチングファブリックが逆方向に構成されている場合（標準）、使用可能な転送パスを確立するために、マッピング/RESVメッセージを1ホップあたり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では、侵入またはその他のアップストリームノードは、1つのホップまたは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.
従来のトラフィックエンジニアリングMPL（およびLDP）は単方向ですが、一般化されたMPLSは双方向LSPの確立をサポートしますが、セクション4を参照してください。双方向LSPの必要性は非PSCアプリケーションから得られます。このようなLSPが必要である理由は複数あり、特に個別のシグナル伝達セッションを介して相互LSPを割り当てる際のリソース競合の可能性があり、非PSCケースでの障害回復手順を簡素化する場合があります。双方向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].
一般化されたMPLは、シグナル伝達にテクノロジー固有のパラメーターを含めることもできます。意図は、すべてのテクノロジー固有のパラメーターが、rsvpを使用する場合、sender_tspecおよびその他の関連オブジェクトで、および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.
MPLの拡大範囲を光学および時間ドメインに扱うには、「ラベル」のいくつかの新しい形式が必要です。これらの新しい形式のラベルは、集合的に「一般化されたラベル」と呼ばれます。一般化されたラベルには、このクロスコネクトのタイプに関係なく、受信ノードがクロス接続をプログラムできるようにするのに十分な情報が含まれています。これにより、パスの侵入セグメントが適切に結合されます。このセクションでは、一般化されたラベルリクエスト、一般化されたラベル、波路スイッチングのサポート、提案されたラベルセット、ラベルセットを定義します。
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ペイロードが含まれます。これらの特性は、3番目のホップポップをサポートするために、トランジットノードで使用できることに注意してください。
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/GIGEなどを示します。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.
ANSI PDHおよびETSI PDHタイプは、これらのそれぞれのネットワーク技術を指定します。DS1とDS3は、ANSI PDH LSPの例です。E1 LSPはETSI PDHになります。Lambdaエンコーディングタイプは、波長全体を含むLSPを指します。ファイバーエンコーディングタイプは、ファイバーポート全体を含むLSPを指します。
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].
特定のリンクで実行する必要があるスイッチングのタイプを示します。このフィールドは、複数のタイプのスイッチング機能を宣伝するリンクに必要です。このフィールドは、ルーティングスイッチング機能記述子の対応するリンクに対して宣伝されている値の1つにマッピングする必要があります。[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のエンドポイントでのノード、および場合によっては最後から2番目のホップによって使用されます。標準のEtherType値は、パケットおよびイーサネット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
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ビット数で運ばれます（ユニットは1秒あたりバイトです）。非パケット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を個別に確立する必要があります。
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）およびLambdaスイッチング（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ラベルは、ビット0-15で正当化されたVPI右およびビット16-31で正当化されたVCIでエンコードされます。
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.
Lambdaスイッチングの特別なケースは、波路スイッチングです。波形は、新しい波帯に切り替えることができる一連の隣接する波長を表します。最適化の理由から、光学クロス接続がユニットとして複数の波長を光学的に切り替えることが望ましい場合があります。これにより、個々の波長の歪みが軽減され、個々の波長がより緊密に分離できる場合があります。波形ラベルは、この特別なケースをサポートするために定義されています。
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.
WaveBand Switchingは、一般化されたラベルと同じ形式を使用します。セクション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
ウェーブバンドID：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.
ラベルセットは、ダウンストリームノードのラベルの選択肢を許容可能なラベルのセットに制限するために使用されます。この制限は、1ホップごとに適用されます。
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つのケースについて説明します。最初のケースは、最終機器が波長/帯域の小さな特定のセットでのみ送信できる場合です。2番目のケースは、波長変換（ci-incapable）をサポートできないインターフェイスのシーケンスがあり、同じ波長を一連のホップ、またはパス全体でエンドツーエンドで使用する必要がある場合です。3番目のケースは、光学信号の歪みを減らすために実行される波長変換の量を制限することが望ましい場合です。最後のケースは、リンクの2つの端が異なる波長セットをサポートする場所です。
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に使用できるラベル範囲を制限するために使用されます。ラベルセットの受信機は、ラベルセットにあるラベルに選択したラベルを制限する必要があります。ラベルと同じように、複数のホップにラベルセットが存在する場合があります。この場合、各ノードは、おそらく着信ラベルセットとノードのハードウェア機能に基づいて、独自の発信ラベルセットを生成します。このケースは、変換不能な（ci-incapable）インターフェイスを備えたノードの標準であると予想されます。
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つのサブチャネル要素が含まれています。最初の要素は、範囲の開始を示します。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つのサブチャネル要素が含まれています。最初の要素は、範囲の開始を示します。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の場合、「イニシエーター」と「ターミネーター」が1つしかないことに注意してください。
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]を使用するときに双方向LSPを確立するには、2つの単方向パスを独立して確立する必要があります。このアプローチには、次の欠点があります。
* 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つの往復信号時間と1つのイニシエーターターミネーターシグナリングトランジット遅延に等しくなります。これにより、LSPの確立を成功させるためのセットアップレイテンシを拡張するだけでなく、失敗したLSPを発見するための最悪のケースのレイテンシを、イニシエーターターミネータートランジット遅延の2倍に拡張します。これらの遅延は、修復目的で確立された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の2倍です。これは、双方向LSPの両方のセグメントに対して個別の制御メッセージ（パスとRESVなど）を生成する必要があるためです。
* 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（またはLightPath）は、多くの光学ネットワーキングサービスプロバイダーの要件と見なされています。
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に使用できるラベルに制限がなく、代替リソースがある場合、両方のノードは上流で異なるラベルを通過し、競合はありません。ただし、双方向LSPに使用できるラベルに制限がある場合（たとえば、単一のI/Oカードで物理的に結合する必要がある場合）、または利用可能なリソースがもうない場合、競合は他の手段によって解決されます。競合を解決するには、より高いノード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を使用してこのアプローチをサポートする際に注意すべき特別なケースの1つは、初期パスメッセージを送信するときに近隣のノード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).
2つのノード間の競合の例（PXC 1とPXC 2）を図1に示します。この例では、PXC 1は、ローカルBCID = 2（PXC 2のローカルBCID = 7）に対応するチャネルに上流ラベルを割り当て、aを送信します。ローカルBCID = 1（PXC 2のローカルBCID = 6）に対応するチャネルの提案ラベル。同時に、PXC 2は、ローカルBCID = 6（PXC 1のローカルBCID = 1）に対応するチャネルに上流ラベルを割り当て、ローカルBCID = 7（PXC 1でローカルBCID = 2で対応するチャネルの推奨ラベルを送信します。）。双方向LSPに使用できるラベルに制限がない場合、および使用可能な代替リソースがある場合、PXC 1とPXC 2の両方が異なるラベルを上流で通過し、競合は自然に解決されます（図2を参照）。ただし、双方向LSPに使用できるラベルに制限がある場合（たとえば、単一のI/Oカードで物理的に結合する必要がある場合）、ノードIDを使用して競合を解決する必要があります（図を参照してください。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はBCID = 2（PXC 2でBCID = 7）を使用して上流ラベルを割り当て、BCID = 1（PXC 2でBCID = 6）を使用して推奨ラベルを割り当てます。同時に、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には、「容認できないラベル値」の表示を含むエラーメッセージが得られるケースがあります。[RFC3209]、[RFC3472]および[RFC3473]を参照してください。これらのケースが発生する場合、エラーメッセージを生成するノードがどのラベルが許容できるかを示すのに役立ちます。このケースをカバーするために、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].
従来のMPLでは、LSPが使用するインターフェイスは、明示的なルート、つまりEROまたはER-HOPを介して制御できます。これにより、特定のノード/インターフェイスを含めることができ、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-HOPが明示的なラベルサブオブジェクトをサポートしていないことです。このようなメカニズムが望ましい場合の例は、2つのLSPが一緒に「スプライス」される場合、つまり、最初のLSPの尾が2番目のLSPの頭に「スプライス」される場合です。この最後のケースは、非PSCクラスのリンクで使用される可能性が高くなります。
To cover this case, the Label ERO subobject / ER Hop is introduced.
このケースをカバーするために、ラベルERO Subobject / ER HOPが導入されています。
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]を参照してください。PATH計算アルゴリズムは、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にリソースを使用している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
セカンダリ：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の値は、noを含む任意のリンク保護を使用することを意味します。複数の保護タイプが許容される場合を示すように複数のビットを設定することができます。複数のビットが設定され、複数の保護タイプが利用可能な場合、保護タイプの選択はローカル（ポリシー）の決定です。
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 1よりも信頼性の高い保護スキームを使用する必要があることを示します。たとえば、4ファイバーBLSR/MSスプリング。
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：1保護スキームを使用してLSPをサポートする必要があることを示します。
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では、制御チャネルとデータチャネルの分離は、任意の数の要因が原因である可能性があります。（バンドリングや、バンド内の制御情報を運ぶことができないデータチャネルなどのその他のケースを含む。）このセクションでは、データチャネルに影響を与えない制御チャネル障害のシグナリングと処理におけるデータチャネルの識別をカバーします。。
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では、コントロールチャネルとデータチャネルとの暗黙の1対1の関連性があります。そのような関連性が存在する場合、特定の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.
制御チャネルとデータチャネルとの明示的な1対1の関連性がない場合は、制御されている特定のデータチャネルを特定するために、信号の追加情報を伝える必要があります。GMPLSは、インターフェイス識別情報を提供することにより、明示的なデータチャネル識別をサポートします。GMPLSを使用すると、IPv4またはIPv6アドレス、インターフェイスインデックス（[MPLS-UNNUM]を参照）、コンポーネントインターフェイス（[LMP]などのプロトコルを介して確立された）など、多くのインターフェイス識別スキームを使用できます。すべての場合において、データインターフェイスの選択は、上流ノードで使用されるアドレスと識別子を使用したアップストリームノードによって示されます。
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:
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オクテットに並べられるように、ゼロパッドをゼロにする必要があります。
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アドレスまたはルーターに関連付けられたIPアドレスのいずれかを搭載してください。関連するアドレスは、ルーティングのルーターアドレスTLVに配信される値です。
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はバンドルされたコンポーネントリンクを示します。特別な値0xffffffffffを使用して、同じラベルがすべてのコンポーネントリンクで有効であることを示すことができます。
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.
2番目では、ノードのコントロールプレーンが故障し、州の情報のほとんどを再起動および損失します。この場合、上流ノードと下流ノードの両方が、状態情報を再起動したノードと同期する必要があります。再同期が発生するためには、再起動するノードは、発信ラベルから発信ラベルのマッピングなど、いくつかの情報を保持する必要があります。
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.
Igor Bryskin、Adrian Farrel、Ben Mack-Crane、Dimitri Papadimitriou、Fong Liaw、Juergen Heilesなど、多くの人々から貴重なコメントと意見が受けられました。このドキュメントの一部のセクションは、Fong 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]で言及されているセキュリティ上の考慮事項は、GMPLのそれぞれのプロトコル固有の形式に適用されます。[RFC3473]および[RFC3472]を参照してください。
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は、このドキュメントで定義されている名前空間の新しい値の割り当てを管理します。このセクションでは、RFCSでIANAの考慮事項セクションを作成するためのBCP 26 "ガイドラインの用語を使用しています[BCP26]。
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エンコーディングタイプ：8ビットOスイッチングタイプ：8ビットo一般化PID（G-PID）：16ビットOアクション：8ビットOインターフェイス_IDタイプ：16ビット
All future assignments should be allocated through IETF Consensus action or documented in a Specification.
すべての将来の割り当ては、IETFコンセンサスアクションを通じて割り当てられるか、仕様に文書化される必要があります。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、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] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：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.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、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] Ashwood-Smith、P。and L. Berger、編集者、「一般化されたマルチプロトコルラベルスイッチング（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] Berger、L.、Editor「Generalized Multi-Protocol Label Switching（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.、et al。、「一般化されたMPLSをサポートするルーティング拡張機能」、進行中の作業。
[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH Specifics", Work in Progress.
[Gmpls-Sonet] Ashwood-Smith、P.、et al。、「Gmpls-Sonet / SDH詳細」、進行中の作業。
[LMP] Lang, et al., "Link Management Protocol", Work in Progress.
[LMP] Lang、et al。、「Link Management Protocol」は、進行中の作業。
[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。Berger、「MPLS Traffic Engineeringにおけるリンクバンドリング」、進行中の作業。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with MPLS TE", Work in Progress.
[MPLS-Hierarchy] Kompella、K。およびY. Rekhter、「MPLS TEとのLSP階層」、進行中の作業。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
Peter Ashwood-Smith Nortel Networks Corp. P.O.ボックス3511ステーションC、オタワ、K1Y 4H7カナダ
Phone: +1 613 763 4534
EMail: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose、CA 95138
Phone: +1 408 972-3645
EMail: abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Greg Bernstein
グレッグ・バーンスタイン
EMail: gregb@grotto-networking.com
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
John Drake Calient Networks 5853 Rue Ferrari San Jose、CA 95138
Phone: +1 408 972 3720 EMail: jdrake@calient.net Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
電話：1 408 972 3720メール：jdrake@calient.net yanheファンAxiowave Networks、Inc。200 Nickerson Road Marlborough、MA 01752
Phone: + 1 774 348 4627
EMail: yfan@axiowave.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 N. Mathilda Ave. Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
Jonathan P. Langメール：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
Bala Rajagopalan Tellium、Inc。2 Crescent Place P.O.Box 901 Oceanport、NJ 07757-0901
Phone: +1 732 923 4237
Fax: +1 732 923 9804
EMail: braja@tellium.com
Yakov Rekhter Juniper Networks, Inc.
Yakov Rekhter Juniper Networks、Inc。
EMail: yakov@juniper.net
Debanjan Saha
EMail: 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
Vishal Sharma Metanoia、Inc。1600 Villa Street、Unit 352 Mountain View、CA 94041-1174電話：1 650-386-6723メール：v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
George Swallow Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA 01824
Phone: +1 978 244 8143
EMail: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z. Bo Tang Email：botang01@yahoo.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
Lou Berger Movaz Networks、Inc。7926 Jones Branch Drive Suite 615 McLean VA、22102
Phone: +1 703 847-1801
EMail: lberger@movaz.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。