[要約] RFC 3034は、フレームリレーネットワークでのラベルスイッチングの使用に関する仕様を定めたものであり、その目的は、フレームリレーネットワークにおける効率的なパケット転送を実現することです。
Network Working Group A. Conta
Request for Comments: 3034 Transwitch Corporation
Category: Standards Track P. Doolan
Ennovate
A. Malis
Vivace Networks, Inc.
January 2001
Use of Label Switching on Frame Relay Networks Specification
フレームリレーネットワークの仕様のラベルスイッチングの使用
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 (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs).
このドキュメントでは、フレームリレーネットワークのマルチプロトコルラベルスイッチングのモデルと一般的なメカニズムを定義しています。さらに、[ARCH]および[LDP]に記載されているラベル分布プロトコル（LDP）で説明されているマルチプロトコルラベルスイッチングアーキテクチャの一部が、フレームリレーネットワークと比較して[LDP）の一部を拡張および明確にします。MPLSは、ラベルスイッチングルーター（LSR）としてフレームリレースイッチを使用することを可能にします。
Table of Contents
目次
1. Introduction................................................2
2. Terminology.................................................3
3. Special Characteristics of Frame Relay Switches.............4
4. Label Encapsulation.........................................5
5. Frame Relay Label Switching Processing......................6
5.1 Use of DLCIs..............................................6
5.2 Homogeneous LSPs..........................................7
5.3 Heterogeneous LSPs........................................7
5.4 Frame Relay Label Switching Loop Prevention and Control...7
5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............7
5.4.2 Performing MPLS TTL calculations.......................8
5.5 Label Processing by Ingress FR-LSRs......................12
5.6 Label Processing by Core FR-LSRs.........................12
5.7 Label Processing by Egress FR-LSRs.......................13
6. Label Switching Control Component for Frame Relay.........13
6.1 Hybrid Switches (Ships in the Night) ...................14
7. Label Allocation and Maintenance Procedures ..............15
7.1 Edge LSR Behavior........................................15
7.2 Efficient use of label space-Merging FR-LSRs.............18
7.3 LDP message fields specific to Frame Relay...............19
8. Security Considerations .................................21
9. Acknowledgments .........................................21
10. References ..............................................22
11. Authors' Addresses ......................................23
12. Full Copyright Statement ................................24
The Multiprotocol Label Switching Architecture is described in [ARCH]. It is possible to use Frame Relay switches as Label Switching Routers. Such Frame Relay switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based on the results of these routing algorithms. No specific Frame Relay routing is needed.
マルチプロトコルラベルスイッチングアーキテクチャは[Arch]で説明されています。フレームリレースイッチをラベルスイッチングルーターとして使用することができます。このようなフレームリレースイッチは、ネットワークレイヤールーティングアルゴリズム（OSPF、IS-ISなど）を実行し、その転送はこれらのルーティングアルゴリズムの結果に基づいています。特定のフレームリレールーティングは必要ありません。
When a Frame Relay switch is used for label switching, the top (current) label, on which forwarding decisions are based, is carried in the DLCI field of the Frame Relay data link layer header of a frame. Additional information carried along with the top (current) label, but not processed by Frame Relay switching, along with other labels, if the packet is multiply labeled, are carried in the generic MPLS encapsulation defined in [STACK].
ラベルスイッチングにフレームリレースイッチを使用すると、転送決定の基礎となる上部（現在）ラベルが、フレームのフレームリレーデータリンクレイヤーヘッダーのDLCIフィールドに運ばれます。追加情報は、上部（現在の）ラベルとともに携帯されていますが、フレームリレースイッチングで処理されず、他のラベルとともに、パケットが乗算されている場合、[stack]で定義された汎用MPLSカプセル化に運ばれます。
Frame Relay permanent virtual circuits (PVCs) could be configured to carry label switching based traffic. The DLCIs would be used as MPLS Labels and the Frame Relay switches would become Frame Relay Label Switching Routers, while the MPLS traffic would be encapsulated according to this specification, and would be forwarded based on network layer routing information.
フレームリレー永久仮想回路（PVC）は、ラベルスイッチングベースのトラフィックを運ぶように構成できます。DLCISはMPLSラベルとして使用され、フレームリレースイッチはフレームリレーラベルスイッチングルーターになり、MPLSトラフィックはこの仕様に従ってカプセル化され、ネットワークレイヤールーティング情報に基づいて転送されます。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119.
キーワードは、rfc 2119で定義されていると解釈されるべきではない、、オプション、必要、要求、推奨、推奨、推奨されないことをしてはなりません。
This document is a companion document to [STACK] and [ATM].
このドキュメントは、[スタック]と[ATM]のコンパニオンドキュメントです。
LSR
LSR
A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [ARCH].
ラベルスイッチングルーター（LSR）は、[Arch]で説明されているラベルスイッチング制御および転送コンポーネントを実装するデバイスです。
LC-FR
LC-FR
A label switching controlled Frame Relay (LC-FR) interface is a Frame Relay interface controlled by the label switching control component. Packets traversing such an interface carry labels in the DLCI field.
ラベルスイッチング制御フレームリレー（LC-FR）インターフェイスは、ラベルスイッチング制御コンポーネントによって制御されるフレームリレーインターフェイスです。このようなインターフェイスを横断するパケットは、DLCIフィールドにラベルを運びます。
FR-LSR
fr-lsr
A FR-LSR is an LSR with one or more LC-FR interfaces which forwards frames between two such interfaces using labels carried in the DLCI field.
FR-LSRは、DLCIフィールドに運ばれるラベルを使用して、2つのそのようなインターフェイス間でフレームを転送する1つ以上のLC-FRインターフェイスを備えたLSRです。
FR-LSR domain
FR-LSRドメイン
A FR-LSR domain is a set of FR-LSRs, which are mutually interconnected by LC-FR interfaces.
FR-LSRドメインはFR-LSRのセットであり、LC-FRインターフェイスによって相互に相互接続されています。
Edge Set
エッジセット
The Edge Set of an FR-LSR domain is the set of LSRs, which are connected to the domain by LC-FR interfaces.
FR-LSRドメインのエッジセットはLSRのセットであり、LC-FRインターフェイスによってドメインに接続されています。
Forwarding Encapsulation
転送カプセル化
The Forwarding Encapsulation is the type of MPLS encapsulation (Frame Relay, ATM, Generic) of a packet that determines the packet's MPLS forwarding, or the network layer encapsulation if that packet is forwarded based on the network layer (IP, etc...)header.
転送カプセル化は、パケットのMPLS転送を決定するパケットのMPLSカプセル化（フレームリレー、ATM、ジェネリック）、またはネットワークレイヤーのカプセル化を決定するパケットのタイプです。ヘッダ。
Input Encapsulation
入力カプセル化
The Input Encapsulation is the type of MPLS encapsulation (Frame Relay, ATM, Generic) of a packet when that packet is received on an LSR's interface, or the network layer (IP, etc...)encapsulation if that packet has no MPLS encapsulation.
入力カプセル化は、そのパケットがLSRのインターフェイスで受信された場合のパケットのパケットのMPLSカプセル化（フレームリレー、ATM、ジェネリック）のタイプ、またはそのパケットにMPLSカプセル化がない場合のネットワークレイヤー（IPなど）カプセル化です。。
Output Encapsulation
出力カプセル化
The Output Encapsulation is the type of MPLS encapsulation (Frame Relay, ATM, Generic) of a packet when that packet is transmitted on an LSR's interface, or the network layer (IP, etc...)encapsulation if that packet has no MPLS encapsulation.
出力カプセル化は、そのパケットがLSRのインターフェイスで送信される場合のパケットのMPLSカプセル化（フレームリレー、ATM、ジェネリック）のタイプです。。
Input TTL
入力TTL
The Input TTL is the MPLS TTL of the top of the stack when a labeled packet is received on an LSR interface, or the network layer (IP) TTL if the packet is not labeled.
入力TTLは、ラベル付きパケットがLSRインターフェイスで受信される場合のスタックの上部のMPLS TTL、またはパケットがラベル付けされていない場合はネットワークレイヤー（IP）TTLです。
Output TTL
出力TTL
The Output TTL is the MPLS TTL of the top of the stack when a labeled packet is transmitted on an LSR interface, or the network layer (IP) TTL if the packet is not labeled.
出力TTLは、ラベル付きパケットがLSRインターフェイスに送信される場合のスタックの上部のMPLS TTL、またはパケットがラベル付けされていない場合はネットワークレイヤー（IP）TTLです。
Additionally, this document uses terminology from [ARCH].
さらに、このドキュメントでは、[Arch]の用語を使用しています。
While the label switching architecture permits considerable
flexibility in LSR implementation, a FR-LSR is constrained by the
capabilities of the (possibly pre-existing) hardware and the
restrictions on such matters as frame format imposed by the
Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay
standards [FRF], etc.... Because of these constraints, some special
procedures are required for FR-LSRs.
Some of the key features of Frame Relay switches that affect their behavior as LSRs are:
LSRとしての動作に影響を与えるフレームリレースイッチの重要な機能のいくつかは次のとおりです。
- the label swapping function is performed on fields (DLCI) in the frame's Frame Relay data link header; this dictates the size and placement of the label(s) in a packet. The size of the DLCI field can be 10 (default) or 23 bits, and it can span two or four bytes in the header.
- ラベルスワッピング関数は、フレームのフレームリレーデータリンクヘッダーのフィールド（DLCI）で実行されます。これにより、パケット内のラベルのサイズと配置が決定されます。DLCIフィールドのサイズは10（デフォルト）または23ビットであり、ヘッダーの2つまたは4バイトにまたがることがあります。
- there is generally no capability to perform a 'TTL-decrement' function as is performed on IP headers in routers.
- 通常、ルーターのIPヘッダーで実行される「TTL-Decrement」関数を実行する機能はありません。
- congestion control is performed by each node based on parameters that are passed at circuit creation. Flags in the frame headers may be set as a consequence of congestion, or exceeding the contractual parameters of the circuit.
- 混雑制御は、回路作成時に渡されるパラメーターに基づいて各ノードによって実行されます。フレームヘッダー内のフラグは、輻輳の結果として、または回路の契約上のパラメーターを超えて設定される場合があります。
- although in a standard switch it may be possible to configure multiple input DLCIs to one output DLCI resulting in a multipoint-to-point circuit, multipoint-to-multipoint VCs are generally not fully supported.
- 標準スイッチでは、複数の入力DLCIを1つの出力DLCIに構成してマルチポイントツーポイント回路になりますが、マルチポイントからマルチポイントVCは一般に完全にはサポートされていません。
This document describes ways of applying label switching to Frame Relay switches, which work within these constraints.
このドキュメントでは、これらの制約内で機能するフレームリレースイッチにラベルスイッチングを適用する方法について説明します。
By default, all labeled packets should be transmitted with the generic label encapsulation as defined in [STACK], using the frame relay null encapsulation mechanism:
デフォルトでは、フレームリレーヌルカプセル化メカニズムを使用して、[スタック]で定義されている一般的なラベルカプセル化とともに、すべてのラベル付きパケットを送信する必要があります。
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | . |
/ . /
/ MPLS packet /
| . |
+-----------------------+-----------------------+
"n" is the length of the Q.922 Address which can be 2 or 4 octets.
「n」は、q.922アドレスの長さであり、2〜4オクテットです。
The Q.922 [ITU] representation of a DLCI (in canonical order - the first bit is stored in the least significant, i.e., the right-most bit of a byte in memory) [CANON] is the following:
DLCIのQ.922 [ITU]表現（標準的な順序で - 最初のビットは最も重要ではない、つまり、メモリ内のバイトの右ビット）[Canon]は次のとおりです。
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10ビットDLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----00
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23ビットDLCI
The use of the frame relay null encapsulation implies that labels implicitly encode the network protocol type.
フレームリレーヌルカプセル化の使用は、ラベルがネットワークプロトコルタイプを暗黙的にエンコードすることを意味します。
Rules regarding the construction of the label stack, and error messages returned to the frame source are also described in [STACK].
ラベルスタックの構築に関するルール、およびフレームソースに返されるエラーメッセージも[Stack]で説明されています。
The generic encapsulation contains "n" labels for a label stack of depth "n" [STACK], where the top stack entry carries significant values for the EXP, S , and TTL fields [STACK] but not for the label, which is rather carried in the DLCI field of the Frame Relay data link header encoded in Q.922 [ITU] address format.
一般的なカプセル化には、深さのラベルスタック "n" [スタック]のラベルスタックの「n」ラベルが含まれています。上部スタックエントリは、EXP、S、およびTTLフィールド[スタック]の重要な値を持ちますが、ラベルではありません。Q.922 [ITU]アドレス形式でエンコードされたフレームリレーデータリンクヘッダーのDLCIフィールドに携帯されています。
Label switching is accomplished by associating labels with routes and using the label value to forward packets, including determining the value of any replacement label. See [ARCH] for further details. In a FR-LSR, the top (current) MPLS label is carried in the DLCI field of the Frame Relay data link layer header of the frame. The top label carries implicitly information about the network protocol type.
ラベルスイッチングは、ラベルをルートに関連付け、ラベル値を使用して、交換用ラベルの値を決定するなど、フォワードパケットを使用することで実現されます。詳細については、[Arch]を参照してください。FR-LSRでは、フレームのフレームリレーデータリンクレイヤーヘッダーのDLCIフィールドにトップ（電流）MPLSラベルが運ばれます。トップラベルには、ネットワークプロトコルタイプに関する情報が暗黙的に情報を提供します。
For two connected FR-LSRs, a full-duplex connection must be available for LDP. The DLCI for the LDP VC is assigned a value by way of configuration, similar to configuring the DLCI used to run IP routing protocols between the switches.
2つの接続されたFR-LSRの場合、LDPでは全二重接続を利用できる必要があります。LDP VCのDLCIは、スイッチ間でIPルーティングプロトコルを実行するために使用されるDLCIの構成と同様に、構成によって値を割り当てられます。
With the exception of this configured value, the DLCI values used for MPLS in the two directions of the link may be treated as belonging to two independent spaces, i.e., VCs may be half-duplex, each direction with its own DLCI.
この構成された値を除き、リンクの2つの方向のMPLSに使用されるDLCI値は、2つの独立したスペースに属するものとして扱われます。つまり、VCは半分二重であり、各方向は独自のDLCIです。
The allowable ranges of DLCIs, the size of DLCIs, and the support for VC merging MUST be communicated through LDP messages. Note that the range of DLCIs used for labels depends on the size of the DLCI field.
DLCISの許容範囲、DLCISのサイズ、およびVCマージのサポートは、LDPメッセージを介して通信する必要があります。ラベルに使用されるDLCIの範囲は、DLCIフィールドのサイズに依存することに注意してください。
If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1, LSR2, and LSR3 will use the same encoding of the label stack when transmitting packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is homogeneous.
<LSR1、LSR2、LSR3>がLSPである場合、LSR1、LSR2、およびLSR3が、LSR1からLSR2、LSR2、およびLSR3にパケットPを送信するときに、ラベルスタックの同じエンコードを使用する可能性があります。このようなLSPは均質です。
If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1 will use one encoding of the label stack when transmitting packet P to LSR2, but LSR2 will use a different encoding when transmitting a packet P to LSR3. In general, the MPLS architecture supports LSPs with different label stack encodings on different hops. When a labeled packet is received, the LSR must decode it to determine the current value of the label stack, then must operate on the label stack to determine the new label value of the stack, and then encode the new value appropriately before transmitting the labeled packet to its next hop.
<LSR1、LSR2、LSR3>がLSPである場合、LSR1はパケットPをLSR2に送信するときにラベルスタックの1つのエンコードを使用する可能性がありますが、LSR2はパケットPをLSR3に送信するときに異なるエンコードを使用します。一般に、MPLSアーキテクチャは、異なるホップで異なるラベルスタックエンコーディングでLSPをサポートしています。ラベル付きパケットが受信されたら、LSRはラベルスタックの現在の値を決定するためにデコードする必要があります。次に、ラベルスタックで動作してスタックの新しいラベル値を決定する必要があり、次にラベルを送信する前に新しい値を適切にエンコードする必要があります。次のホップにパケット。
Naturally there will be MPLS networks which contain a combination of Frame Relay switches operating as LSRs, and other LSRs, which operate using other MPLS encapsulations, such as the Generic (MPLS shim header), or ATM encapsulation. In such networks there may be some LSRs, which have Frame Relay interfaces as well as MPLS Generic ("MPLS Shim") interfaces. This is one example of an LSR with different label stack encodings on different hops of the same LSP. Such an LSR may swap off a Frame Relay encoded label on an incoming interface and replace it with a label encoded into a Generic MPLS (MPLS shim) header on the outgoing interface.
当然、LSRSとして動作するフレームリレースイッチの組み合わせと、ジェネリック（MPLSシムヘッダー）やATMカプセル化などの他のMPLSカプセルを使用して動作するMPLSネットワークが含まれます。このようなネットワークには、フレームリレーインターフェイスとMPLSジェネリック（ "MPLS SHIM"）インターフェイスを備えたいくつかのLSRがある場合があります。これは、同じLSPの異なるホップに異なるラベルスタックエンコーディングを持つLSRの1つの例です。このようなLSRは、着信インターフェイスにフレームリレーエンコードラベルを交換し、発信インターフェイスのジェネリックMPLS（MPLS SHIM）ヘッダーにエンコードされたラベルに置き換えることができます。
FR-LSRs SHOULD operate on loop free FR-LSPs or LSP Frame Relay segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use loop prevention mechanisms as described in [ARCH], and [LDP].
FR-LSRは、ループフリーFR-LSPまたはLSPフレームリレーセグメントで動作する必要があります。したがって、FR-LSRはループ検出を使用し、[ARCH]および[LDP]に記載されているようにループ予防メカニズムを使用する場合があります。
The MPLS TTL encoded in the MPLS label stack is a mechanism used to:
MPLSラベルスタックでエンコードされたMPLS TTLは、以下に使用されるメカニズムです。
(a) suppress loops;
(a) ループを抑制します。
(b) limit the scope of a packet.
(b) パケットの範囲を制限します。
When a packet travels along an LSP, it should emerge with the same TTL value that it would have had if it had traversed the same sequence of routers without having been label switched. If the packet travels along a hierarchy of LSPs, the total number of LSR-hops traversed should be reflected in its TTL value when it emerges from the hierarchy of LSPs [ARCH].
パケットがLSPに沿って移動すると、ラベルを切り替えずに同じシーケンスのルーターのシーケンスを横断していた場合と同じTTL値で出現するはずです。パケットがLSPの階層に沿って移動する場合、LSP [Arch]の階層から出現する場合、トラバースされたLSR-HOPSの総数は、TTL値に反映される必要があります。
The initial value of the MPLS TTL is loaded into a newly pushed label stack entry from the previous TTL value, whether that is from the network layer header when no previous label stack existed, or from a pre-existent lower level label stack entry.
MPLS TTLの初期値は、以前のラベルスタックが存在しなかったときのネットワークレイヤーヘッダーからのものであろうと、前に存在する低レベルのラベルスタックエントリからであろうと、以前のTTL値から新しくプッシュされたラベルスタックエントリにロードされます。
A FR-LSR switching same level labeled packets does not decrement the MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment".
同じレベルのラベル付きパケットを切り替えるFR-LSRは、MPLS TTLを減少させません。このようなFR-LSRのシーケンスは、「非TTLセグメント」です。
When a packet emerges from a "non-TTL LSP segment", it should however reflect in the TTL the number of LSR-hops it traversed. In the unicast case, this can be achieved by propagating a meaningful LSP length or LSP Frame Relay segment length to the FR-LSR ingress nodes, enabling the ingress to decrement the TTL value before forwarding packets into a non-TTL LSP segment [ARCH].
ただし、「非TTL LSPセグメント」からパケットが出現すると、TTLには走行したLSR-HOPSの数を反映する必要があります。ユニキャストの場合、これは、意味のあるLSP長またはLSPフレームリレーセグメントの長さをFR-LSRイングレスノードに伝播することで実現できます。。
When an ingress FR-LSR determines upon decrementing the MPLS TTL that a particular packet's TTL will expire before the packet reaches the egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch the packet, but rather follow the specifications in [STACK] in an attempt to return an error message to the packet's source:
イングレスFR-LSRが、特定のパケットのTTLが「非TTL LSPセグメント」の出口に到達する前に特定のパケットのTTLが期限切れになることをMPLS TTLの減少時に決定する場合、FR-LSRにパケットにラベルを付けてはならず、[スタック]の仕様は、パケットのソースにエラーメッセージを返しようとしています。
- it treats the packet as an expired packet and return an ICMP message to its source.
- パケットを期限切れのパケットとして扱い、ICMPメッセージをそのソースに返します。
- it forwards the packet, as an unlabeled packet, with a TTL that reflects the IP (network layer) forwarding.
- IP（ネットワークレイヤー）転送を反映するTTLを使用して、パケットを無効なパケットとして転送します。
If the incoming TTL is 1, only the first option applies.
着信TTLが1の場合、最初のオプションのみが適用されます。
In the multicast case, a meaningful LSP length or LSP segment length is propagated to the FR-LSR egress node, enabling the egress to decrement the TTL value before forwarding packets out of the non-TTL LSP segment.
マルチキャストの場合、意味のあるLSPの長さまたはLSPセグメントの長さがFR-LSR Egressノードに伝播され、Egressが非TTL LSPセグメントからパケットを転送する前にTTL値を減らすことができます。
The calculation applied to the "input TTL" that yields the "output TTL" depends on (i)the "input encapsulation", (ii)the "forwarding encapsulation", and (iii)the "output encapsulation". The relationship among (i),(ii), and (iii), can be defined as a function
「出力TTL」を生成する「入力TTL」に適用される計算は、（i）「入力カプセル化」、（ii）「転送カプセル化」、および（iii）「出力カプセル化」に依存します。（i）、（ii）、および（iii）の関係は、関数として定義できます
"D" of "input encapsulation" (ie), "forwarding encapsulation" (fe), and "output encapsulation" (oe). Subsequently the calculation applied to the "input TTL" to yield the "output TTL" can be described as:
「入力カプセル化」（すなわち）、「転送カプセル化」（FE）、および「出力カプセル化」（OE）の「D」。その後、「入力TTL」に適用された計算は、「出力TTL」を生成することができます。
output TTL = input TTL - D(ie, fe, oe)
or in a brief notation:
または簡単な表記で：
output TTL = input TTL - d
出力TTL =入力TTL -d
where "d" has three possible values: "0","1", or "the number of hops of the LSP segment":
ここで、「D」には3つの可能な値があります：「0」、「1」、または「LSPセグメントのホップ数」：
For unicast transmission:
ユニキャスト伝送の場合：
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| 1 | any | Generic MPLS | Generic MPLS |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | any | or | Frame Relay |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
The "number of hops of the LSP segment" is the value of the "hop count" that is attached with the label used when the packet is forwarded, if LDP [LDP] has provided such a "hop count" value when it distributed the label for the LSP, that is the LDP message had a "hop count object". If LDP didn't provide a "hop count", or it provided an "unknown" value, the default value of the "number of hops of the segment" is 1.
「LSPセグメントのホップ数」は、LDP [LDP]がそのような「ホップカウント」値を提供した場合、パケットが転送されたときに使用されるラベルに添付された「ホップカウント」の値です。LSPのラベル、つまりLDPメッセージには「ホップカウントオブジェクト」がありました。LDPが「ホップカウント」を提供しなかった場合、または「未知の」値を提供した場合、「セグメントのホップ数」のデフォルト値は1です。
When sending a label binding upstream, the "hop count" associated with the corresponding binding from downstream, if different than the "unknown" value, MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding (the "unknown" value is transmitted unchanged). If the new "hop count" value exceeds the "maximum" value, the FR-LSR MUST NOT pass the binding upstream, but instead MUST send an error upstream [LDP][ARCH].
上流のラベルバインディングを送信する場合、「不明な」値とは異なる場合、下流からの対応するバインディングに関連付けられた「ホップ数」は1で増分する必要があり、結果は新しいバインディングに関連付けられたホップカウントとして上流に送信されなければなりません（「未知の」値は変化していません）。新しい「ホップカウント」値が「最大」値を超える場合、FR-LSRはバインディングアップストリームを渡す必要はありませんが、代わりに上流[LDP] [Arch]を上流にエラーを送信する必要があります。
For multicast transmission:
マルチキャストトランスミッションの場合：
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| | | Generic MPLS | |
| 1 | any | or | Frame Relay |
| | |IP(network layer)| |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | Frame Relay | or | any |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
Referring to the "forwarding encapsulation" with the abbreviation "I" for IP (network layer), "G" for Generic MPLS, and "F" for Frame Relay MPLS, referring to an LSR interface with the abbreviation "i" if the input or output encapsulation is IP and no MPLS encapsulation, "g" when the input or output MPLS encapsulation is Generic MPLS, "f" when it is Frame Relay, "a" when it is ATM, and furthermore considering the symbols "iIf", "gGf", "fFf", etc... as LSRs with input, forwarding and output encapsulations as referred above, the following describes examples of TTL calculations for the Homogeneous and Heterogeneous LSPs discussed in previous sections:
IP（ネットワークレイヤー）の略語「I」、ジェネリックMPLSの「G」、およびフレームリレーMPLSの「g」との「転送カプセル化」を参照し、入力の場合、略語「I」とのLSRインターフェイスを指します。または、出力カプセル化はIPであり、MPLSカプセル化はありません。「G」入力または出力MPLSカプセル化が一般的なMPLS、FARE RELAYの場合は「F」、ATMの場合は「A」、さらにはシンボル「IIF」を考慮してください。「GGF」、「FFF」など...上記のように入力、転送、出力カプセルを備えたLSRとして、以下は、以前のセクションで説明した均質および不均一なLSPのTTL計算の例を説明します。
Homogeneous LSP
---------------
IP_ttl = n IP_ttl=mpls_ttl-1 = n-6
--------->iIf fIi--------->
| mpls_ttl = n-5 ^
| |
number of hops 1| Frame Relay |5
| |
V 2 3 4 |
fFf--->fFf--->fFf--->fFf
"iIf" is "ingress LSR" in Frame Relay LSP and
calculates: mpls_ttl = IP_TTL - number of hops = n-5
"fIi" is "egress LSR" from Frame Relay LSP, and
calculates: IP_ttl = mpls_ttl-1 = n-6
Heterogeneous LSP
-----------------
ingress LSR egress LSR
IP_ttl = n IP_ttl = n - 15
links LAN PPP FR ATM PPP FR LAN
--->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi--->
hops 1 2 | 6 | | 9 | 10 | 13 ^ 14 15
|1 4| |1 3| |1 3|
V 2 3 | V 2 | V 2 |
fFf-->fFf-->fFf aAa-->aAa fFf-->fFf
mpls_ttl
n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14
"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6
"fGa" "egress LSR" from Frame Relay segment, and
"ingress LSR" in ATM segment and calculates: mpls_ttl=n-9
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13
"fGg" is "egress LSR" from Frame Relay segment, and
ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14
"gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15
And further examples:
そしてさらに例：
Frame Relay Unicast -- TTL calculated at ingress
フレームリレーユニキャスト-Ingressで計算されたTTL
(ingress LSR) 1 2 3 4
x--->---+--->---+--->>--+-->>---x (egress LSR)
o.ttl=i.ttl-4 | 2 3
^
hops 1|
|
x (ingress LSR)
o.ttl=i.ttl-3
Frame Relay Multicast -- TTL calculated at egress
フレームリレーマルチキャスト-Eugressで計算されたTTL
(egress LSR)x o.ttl=i.ttl-3
hops |
^3
(ingress LSR) | o.ttl=i.ttl-4
x--->---+--->---+--->---+--->---x (egress LSR)
1 2 3 4
When a packet first enters an MPLS domain, the packet is forwarded by normal network layer forwarding operations with the exception that the outgoing encapsulation will include an MPLS label stack [STACK] with at least one entry. The frame relay null encapsulation will carry information about the network layer protocol implicitly in the label, which MUST be associated only with that network protocol. The TTL field in the top label stack entry is filled with the network layer TTL (or hop limit) resulted after network layer forwarding [STACK]. The further FR-LSR processing is similar in both possible cases:
パケットが最初にMPLSドメインに入ると、パケットは、発信カプセル化に少なくとも1つのエントリを持つMPLSラベルスタック[スタック]が含まれることを除き、通常のネットワークレイヤー転送操作によって転送されます。フレームリレーヌルカプセル化は、ネットワークレイヤープロトコルに関する情報をラベルに暗黙的に伝達します。これは、そのネットワークプロトコルにのみ関連付けられている必要があります。トップラベルスタックエントリのTTLフィールドは、ネットワークレイヤー転送後に生じたネットワークレイヤーTTL（またはホップ制限）で満たされています[STACK]。可能な場合の両方の場合、さらにFR-LSR処理は類似しています。
(a) the LSP is homogeneous -- Frame Relay only -- and the FR-LSR is the ingress.
(a) LSPは均質です - フレームリレーのみ - FR-LSRは侵入です。
(b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM, etc... segments form the LSP -- and the FR-LSR is the ingress into a Frame Relay segment.
(b) LSPは不均一です - フレームリレー、PPP、イーサネット、ATMなど...セグメントはLSPを形成し、FR-LSRはフレームリレーセグメントへの侵入です。
For unicast packets, the MPLS TTL SHOULD be decremented with the number of hops of the Frame Relay LSP (homogeneous), or Frame Relay segment of the LSP (heterogeneous). An LDP constructing the LSP SHOULD pass meaningful information to the ingress FR-LSR regarding the number of hops of the "non-TTL segment".
ユニキャストパケットの場合、MPLS TTLは、フレームリレーLSP（均一）のホップ数、またはLSPのフレームリレーセグメント（異種）で減少する必要があります。LSPを構築するLDPは、「非TTLセグメント」のホップ数に関して、意味のある情報を侵入FR-LSRに渡す必要があります。
For multicast packets, the MPLS TTL SHOULD be decremented by 1. An LDP constructing the LSP SHOULD pass meaningful information to the egress FR-LSR regarding the number of hops of the "non-TTL segment".
マルチキャストパケットの場合、MPLS TTLは1で減少する必要があります。LSPを構築するLDPは、「非TTLセグメント」のホップ数に関して、Egress FR-LSRに意味のある情報を渡す必要があります。
Next, the MPLS encapsulated packet is passed down to the Frame Relay data link driver with the top label as output DLCI. The Frame Relay frame carrying the MPLS encapsulated packet is forwarded onto the Frame Relay VC to the next LSR.
次に、MPLSカプセル化されたパケットは、出力DLCIとしてトップラベルを持つフレームリレーデータリンクドライバーに渡されます。MPLSカプセル化されたパケットを運ぶフレームリレーフレームは、フレームリレーVCに次のLSRに転送されます。
In a FR-LSR, the current (top) MPLS label is carried in the DLCI field of the Frame Relay data link layer header of the frame. Just as in conventional Frame Relay, for a frame arriving at an interface, the DLCI carried by the Frame Relay data link header is looked up in the DLCI Information Base, replaced with the correspondent output DLCI, and transmitted on the outgoing interface (forwarded to the next hop node).
FR-LSRでは、電流（上）MPLSラベルがフレームリレーデータリンクレイヤーヘッダーのDLCIフィールドに運ばれます。従来のフレームリレーと同様に、インターフェイスに到着するフレームの場合、フレームリレーデータリンクヘッダーによって運ばれるDLCIがDLCI情報ベースで検索され、特派員出力DLCIに置き換えられ、発信インターフェイスに送信されます（転送されます（次のホップノード）。
The current label information is also carried in the top of the label stack. In the top-level entry, all fields except the label information, which is carried and switched in the Frame Relay frame data link-layer header, are of current significance.
現在のラベル情報は、ラベルスタックの上部にも掲載されています。トップレベルのエントリでは、フレームリレーフレームデータリンク層ヘッダーに携帯および切り替えられたラベル情報を除くすべてのフィールドが現在の重要性です。
When reaching the end of a Frame Relay LSP, the FR-LSR pops the label stack [ARCH]. If the label popped is the last label, it is necessary to determine the particular network layer protocol which is being carried. The label stack carries no explicit information to identify the network layer protocol. This must be inferred from the value of the label which is popped from the stack.
フレームリレーLSPの端に到達すると、FR-LSRがラベルスタック[Arch]をポップします。ラベルが最後のラベルである場合、運ばれている特定のネットワークレイヤープロトコルを決定する必要があります。ラベルスタックには、ネットワークレイヤープロトコルを識別するための明示的な情報が含まれていません。これは、スタックからポップされたラベルの値から推測する必要があります。
If the label popped is not the last label, the previous top level MPLS TTL is propagated to the new top label stack entry.
ポップされたラベルが最後のラベルではない場合、前のトップレベルMPLS TTLが新しいトップレーベルスタックエントリに伝播されます。
If the FR-LSR is the egress switch of a Frame Relay segment of a hybrid LSP, and the end of the Frame Relay segment is not the end of the LSP, the MPLS packet will be processed for forwarding onto the next segment of the LSP based on the information held in the Next Hop Label Forwarding Entry (NHLFE) [ARCH]. The output label is set to the value from the NHLFE, and the MPLS TTL is decremented by the appropriate value depending the type of the output interface and the type of transmit operation (see section 6.3). Further, the MPLS packet is forwarded according to the MPLS specifications for the particular link of the next segment of the LSP.
FR-LSRがハイブリッドLSPのフレームリレーセグメントの出口スイッチであり、フレームリレーセグメントの終了がLSPの終了ではない場合、MPLSパケットはLSPの次のセグメントに転送するために処理されます次のホップラベル転送エントリ（NHLFE）[Arch]に保持されている情報に基づいています。出力ラベルはNHLFEの値に設定され、MPLS TTLは、出力インターフェイスのタイプと送信操作のタイプに応じて、適切な値によって減少します（セクション6.3を参照）。さらに、MPLSパケットは、LSPの次のセグメントの特定のリンクのMPLS仕様に従って転送されます。
For unicast packets, the MPLS TTL SHOULD be decremented by one if the output interface is a generic one, or with the number of hops of the next ATM segment of the LSP (heterogeneous), if the output interface is an ATM (non-TTL) interface.
ユニキャストパケットの場合、出力インターフェイスが一般的なものである場合、または出力インターフェイスがATM（非TTL）の場合、LSPの次のATMセグメント（異種）のホップ数がある場合、MPLS TTLは1つによって減少する必要があります。） インターフェース。
For multicast packets, the MPLS TTL SHOULD be decremented by the number of hops of the FR segment being exited. An LDP constructing the LSP SHOULD pass meaningful information to the egress FR-LSR regarding the number of hops of the FR "non-TTL segment".
マルチキャストパケットの場合、MPLS TTLは、FRセグメントが終了するホップ数によって減少する必要があります。LSPを構築するLDPは、FR「非TTLセグメント」のホップ数に関して、意味のある情報を出力FR-LSRに渡す必要があります。
To support label switching a Frame Relay Switch MUST implement the control component of label switching, which consists primarily of label allocation and maintenance procedures. Label binding information MAY be communicated by several mechanisms, one of which is the Label Distribution Protocol (LDP) [LDP].
ラベルスイッチングをサポートするには、フレームリレースイッチのスイッチが、主にラベルの割り当てとメンテナンス手順で構成されるラベルスイッチングの制御コンポーネントを実装する必要があります。ラベル結合情報は、いくつかのメカニズムによって伝達される場合があります。その1つは、ラベル分布プロトコル（LDP）[LDP]です。
Since the label switching control component uses information learned directly from network layer routing protocols, this implies that the switch MUST participate as a peer in these protocols (e.g., OSPF, IS-IS).
ラベルスイッチング制御コンポーネントは、ネットワークレイヤールーティングプロトコルから直接学習した情報を使用するため、これは、スイッチがこれらのプロトコル（例：OSPF、IS-IS）にピアとして参加する必要があることを意味します。
In some cases, LSRs may use other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings. In these cases, a Frame Relay LSR should participate in these protocols.
場合によっては、LSRは他のプロトコル（RSVP、PIM、BGPなど）を使用してラベルバインディングを分布させる場合があります。これらの場合、フレームリレーLSRはこれらのプロトコルに参加する必要があります。
In the case where Frame Relay circuits are established via LDP, or RSVP, or others, with no involvement from traditional Frame Relay mechanisms, it is assumed that circuit establishing contractual information such as input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incoming/outgoing burst size, incoming/outgoing frame rate, used in transmitting, and congestion control MAY be passed to the FR-LSRs through RSVP, or can be statically configured. It is also assumed that congestion control and frame header flagging as a consequence of congestion, would be done by the FR-LSRs in a similar fashion as for traditional Frame Relay circuits. With the goal of emulating a best-effort router as default, the default VC parameters, in the absence of LDP, RSVP, or other mechanisms participation to setting such parameters, should be zero CIR, so that input policing will set the DE bit in incoming frames, but no frames are dropped.
従来のフレームリレーメカニズムからの関与がないLDP、またはRSVPなどを介してフレームリレー回路が確立されている場合、入力/出力最大フレームサイズ、受信/発信要求/合意などの契約情報を確立する回路が想定されています。スループット、受信/発信許容可能なスループット、着信/発信バーストサイズ、着信/発信フレームレート、送信に使用される、および輻輳制御は、RSVPを介してFR-LSRに渡すことができます。また、輻輳の結果としての混雑制御とフレームヘッダーフラグは、従来のフレームリレー回路と同様の方法でFR-LSRによって行われると想定されています。デフォルトとしてベストエフォルトルーターをエミュレートすることを目的として、LDP、RSVP、またはその他のメカニズムの参加がそのようなパラメーターを設定するための関与がない場合、デフォルトのVCパラメーターはゼロCIRである必要があります。着信フレームですが、フレームはドロップされていません。
Control and state information for the circuits based on MPLS MAY be communicated through LDP.
MPLSに基づく回路の制御および状態情報は、LDPを介して伝達される場合があります。
Support of label switching on a Frame Relay switch requires conformance only to [FRF] (framing, bit-stuffing, headers, FCS) except for section 2.3 (PVC control signaling procedures, aka LMI). Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or SVCs when both are running on the same interface as MPLS, as discussed in the next section.
フレームリレースイッチのラベルスイッチングのサポートには、セクション2.3（PVC制御シグナル伝達手順、別名LMI）を除き、[FRF]（FRAMING、ビットスタッフ、ヘッダー、FCS）にのみ適合する必要があります。Q.933 PVCおよび/またはSVCのシグナリングは必要ありません。PVCおよび/またはSVCシグナル伝達は、次のセクションで説明したように、両方がMPLSと同じインターフェイスで実行されている場合、非MPLS（標準フレームリレー）PVCおよび/またはSVCに使用できます。
The existence of the label switching control component on a Frame Relay switch does not preclude the ability to support the Frame Relay control component defined by the ITU and Frame Relay Forum on the same switch and the same interfaces (NICs). The two control components, label switching and those defined by ITU/Frame Relay Forum, would operate independently.
フレームリレースイッチにラベルスイッチング制御コンポーネントの存在は、同じスイッチと同じインターフェイス（NIC）でITUおよびフレームリレーフォーラムによって定義されたフレームリレー制御コンポーネントをサポートする機能を排除しません。ラベルスイッチングとITU/フレームリレーフォーラムで定義された2つの制御コンポーネントは、独立して動作します。
Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the DLCI space which are available to each component.
このようなデバイスがどのように動作するかの定義は、このドキュメントの範囲を超えています。ただし、各コンポーネントが使用できるDLCIスペースの一部など、2つの制御コンポーネント間で一貫性を保つ必要がある情報は少量のみです。
The mechanisms and message formats of a Label Distribution Protocol are documented in [ARCH] and [LDP]. The "downstream-on-demand" label allocation and maintenance mechanism discussed in this section MUST be used by FR-LSRs that do not support VC merging, and it MAY also be used by FR-LSRs that do support VC merging (note that this mechanism applies to hop-by-hop routed traffic):
ラベル分布プロトコルのメカニズムとメッセージ形式は、[Arch]および[LDP]で文書化されています。このセクションで説明する「ダウンストリームオンデマンド」ラベルの割り当ておよびメンテナンスメカニズムは、VC合併をサポートしないFR-LSRが使用する必要があり、VC合併をサポートするFR-LSRによっても使用できます（これに注意する必要があります。メカニズムは、ホップバイホップルーティングトラフィックに適用されます）：
Consider a member of the Edge Set of a FR-LSR domain. Assume that, as a result of its routing calculations, it selects a FR-LSR as the next hop of a certain route (FEC), and that the next hop is reachable via a LC-Frame Relay interface. Assume that the next-hop FR-LSR is an "LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP "request" message for a label binding from the next hop, downstream LSR. When the Edge LSR receives in response from the downstream LSR the label binding information in an LDP "mapping" message, the label is stored in the Label Information Base (LIB) as an outgoing label for that FEC. The "mapping" message may contain the "hop count" object, which represents the number of hops a packet will take to cross the FR-LSR domain to the Egress FR-LSR when using this label. This information may be stored for TTL calculation. Once this is done, the LSR may use MPLS forwarding to transmit packets in that FEC.
FR-LSRドメインのエッジセットのメンバーを検討してください。ルーティング計算の結果、特定のルートの次のホップ（FEC）としてFR-LSRを選択し、次のホップはLCフレームリレーインターフェイスを介して到達可能であると仮定します。Next-Hop FR-LSRは「LDP-PEER」[Arch] [LDP]であると仮定します。Edge LSRは、次のホップ、下流LSRからのラベルバインディングのLDP「要求」メッセージを送信します。Edge LSRがLDPの「マッピング」メッセージのラベルバインディング情報に応答してEdge LSRが受信すると、ラベルはそのFECの発信ラベルとしてラベル情報ベース（LIB）に保存されます。「マッピング」メッセージには、「ホップカウント」オブジェクトが含まれている場合があります。これは、このラベルを使用するときに、FR-LSRドメインをEgress FR-LSRに渡るためにパケットが取るホップの数を表します。この情報は、TTL計算のために保存される場合があります。これが完了すると、LSRはMPLS転送を使用してそのFECにパケットを送信できます。
When a member of the Edge Set of the FR-LSR domain receives an LDP "request" message from a FR-LSR for a FEC, it means it is the Egress-FR-LSR. It allocates a label, creates a new entry in its Label Information Base (LIB), places that label in the incoming label component of the entry, and returns (via LDP) a "mapping" message containing the allocated label back upstream to the LDP peer that originated the request. The "mapping" message contains the "hop count" object value set to 1.
FR-LSRドメインのEDGEセットのメンバーがFECのFR-LSRからLDPの「要求」メッセージを受信すると、それはEgress-FR-LSRであることを意味します。ラベルを割り当て、ラベル情報ベース（lib）に新しいエントリを作成し、エントリの着信ラベルコンポーネントにラベルを付ける場所を作成し、（LDPを介して）ldpに戻る割り当てラベルを含む「マッピング」メッセージを返します。リクエストを発信したピア。「マッピング」メッセージには、1に設定された「ホップカウント」オブジェクト値が含まれています。
When a routing calculation causes an Edge LSR to change the next hop for a route, and the former next hop was in the FR-LSR domain, the Edge LSR should notify the former next hop (via an LDP "release" message) that the label binding associated with the route is no longer needed.
ルーティングの計算により、エッジLSRがルートの次のホップを変更し、前の次のホップがFR-LSRドメインにある場合、Edge LSRは以前の次のホップ（LDP「リリース」メッセージを介して）に通知する必要があります。ルートに関連付けられたラベルバインディングは不要になりました。
When a Frame Relay-LSR receives an LDP "request" message for a certain route (FEC) from an LDP peer connected to the FR-LSR over a LC-FR interface, the FR-LSR takes the following actions:
フレームリレーLSRがLC-FRインターフェイスを介してFR-LSRに接続されたLDPピアから特定のルート（FEC）のLDP「要求」メッセージを受信すると、FR-LSRは次のアクションを実行します。
- it allocates a label, creates a new entry in its Label Information Base (LIB), and places that label in the incoming label component of the entry;
- ラベルを割り当て、ラベル情報ベース（lib）に新しいエントリを作成し、エントリの着信ラベルコンポーネントにラベルを付ける場所を作成します。
- it propagates the "request", by sending an LDP "request" message to the next hop LSR, downstream for that route (FEC);
- 次のホップLSRにLDP「リクエストメッセージ」を送信することにより、「リクエスト」を伝播します。そのルートの下流（FEC）。
In the "ordered control" mode [ARCH], the FR-LSR will wait for its "request" to be responded from downstream with a "mapping" message before returning the "mapping" upstream in response to a "request" ("ordered control" approach [ARCH]). In this case, the FR-LSR increments the hop count it received from downstream and uses this value in the "mapping" it returns upstream.
「順序付けられたコントロール」モード[ARCH]では、FR-LSRは、「マッピング」メッセージで「マッピング」メッセージで「リクエスト」が「マッピング」メッセージで「マッピング」メッセージを返して、「リクエスト」に応じて応答するのを待ちます（「注文」コントロール「アプローチ[アーチ]）。この場合、FR-LSRは、下流から受け取ったホップカウントを増加させ、この値を「マッピング」で上流に戻します。
Alternatively, the FR-LSR may return the binding upstream without waiting for a binding from downstream ("independent control" approach [ARCH]). In this case, it uses a reserved value for hop count in the "mapping", indicating that it is 'unknown'. The correct value for hop count will be returned later, as described below.
あるいは、FR-LSRは、下流からのバインディングを待たずに上流の上流を返すことができます（「独立制御」アプローチ[Arch]）。この場合、「マッピング」のホップカウントに予約価値を使用し、「不明」であることを示します。以下で説明するように、ホップカウントの正しい値は後で返されます。
Since both the "ordered" and "independent" control has advantages and disadvantages, this is left as an implementation, or configuration choice.
「秩序化」と「独立した」コントロールの両方には利点と短所があるため、これは実装または構成の選択肢として残されています。
Once the FR-LSR receives in response the label binding in an LDP "mapping" message from the next hop, it places the label into the outgoing label component of the LIB entry.
FR-LSRが次のホップからLDPの「マッピング」メッセージでラベルバインディングを受信すると、LIBエントリの発信ラベルコンポーネントにラベルを配置します。
Note that a FR-LSR, or a member of the edge set of a FR-LSR domain, may receive multiple binding requests for the same route (FEC) from the same FR-LSR. It must generate a new "mapping" for each "request" (assuming adequate resources to do so), and retain any existing mapping(s). For each "request" received, a FR-LSR should also generate a new binding "request" toward the next hop for the route (FEC).
FR-LSR、またはFR-LSRドメインのエッジセットのメンバーは、同じFR-LSRから同じルート（FEC）に対して複数のバインディングリクエストを受信できることに注意してください。「リクエスト」ごとに新しい「マッピング」を生成し（適切なリソースを想定する）、既存のマッピングを保持する必要があります。受信した各「リクエスト」について、FR-LSRは、ルートの次のホップ（FEC）に向けて新しいバインディング「リクエスト」も生成する必要があります。
When a routing calculation causes a FR-LSR to change the next hop for a route (FEC), the FR-LSR should notify the former next hop (via an LDP "release" message) that the label binding associated with the route is no longer needed.
ルーティング計算により、FR-LSRがルートの次のホップ（FEC）を変更すると、FR-LSRは、ルートに関連するラベルバインディングがNOであることを（LDP「リリース」メッセージを介して）以前の次のホップに通知する必要があります。長く必要です。
When a LSR receives a notification that a particular label binding is no longer needed, the LSR may deallocate the label associated with the binding, and destroy the binding. This mode is the "conservative label retention mode" [ARCH]. In the case where a FR-LSR receives such notification and destroys the binding, it should notify the next hop for the route that the label binding is no longer needed. If a LSR does not destroy the binding (the FR-LSR is configured in "liberal label retention mode" [ARCH]), it may re-use the binding only if it receives a request for the same route with the same hop count as the request that originally caused the binding to be created.
LSRが特定のラベルバインディングが不要になったという通知を受け取ると、LSRはバインディングに関連付けられたラベルを扱い、バインディングを破壊する場合があります。このモードは、「保守的なラベル保持モード」[Arch]です。FR-LSRがそのような通知を受け取り、バインディングを破壊する場合、ラベルバインディングが不要になったルートの次のホップに通知する必要があります。LSRがバインディングを破壊しない場合（FR-LSRは「リベラルラベル保持モード」[Arch]で構成されています）、同じルートのリクエストを受け取った場合にのみ、バインディングを再利用できます。元々結合を作成した要求。
When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change. Whenever a LSR changes its next hop for a particular route, if the new next hop is a FR-LSR or a member of the edge set reachable via a LC-FR interface, then for each entry in its LIB associated with the route the LSR should request (via LDP) a binding from the new next hop.
ルートが変更されると、ラベルバインディングは、ルートが前のルートから分岐するポイントから再確立されます。そのポイントの上流のLSRは（1つの例外を除く、以下に記載されている）変更を忘れています。LSRが特定のルートの次のホップを変更するたびに、新しい次のホップがLC-FRインターフェイスを介して到達可能なEdgeセットのメンバーである場合、LSRのルートに関連付けられた各エントリの各エントリについて（LDP経由で）新しいNext Hopからバインディングを要求する必要があります。
When a FR-LSR receives a label binding from a downstream neighbor, it may already have provided a corresponding label binding for this route to an upstream neighbor, either because it is using "independent control" or because the new binding from downstream is the result of a routing change. In this case, it should extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown') the FR-LSR must notify the upstream neighbor of the change. Each FR-LSR in turn increments the hop count and passes it upstream until it reaches the ingress Edge LSR.
FR-LSRが下流の隣人からラベルバインディングを受信すると、「独立コントロール」を使用しているか、下流からの新しいバインディングが結果であるため、上流の隣人へのこのルートの対応するラベル結合をすでに提供している可能性があります。ルーティングの変更の。この場合、新しいバインディングからホップカウントを抽出し、1つずつ増加させる必要があります。新しいホップカウントが、以前に上流の隣人に伝えられたものとは異なる場合（上流の隣人に「不明」値が与えられた場合を含む）FR-LSRは、上流の隣人に変更を通知する必要があります。各FR-LSRは、ホップカウントを増加させ、イングレスエッジLSRに到達するまで上流に渡します。
Whenever a FR-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the FR-LSR should destroy the binding created in response to the received request, and notify the requester (via an LDP "withdraw" message).
FR-LSRが別の（上流）LSRからラベルバインディングリクエストを受信した結果として次のホップLSRへのラベルバインディングリクエストを発信する場合はいつでも、次のホップLSRへのリクエストが満たされていません。受信したリクエストに応じて作成されたバインディング、および要求者に通知します（LDP「撤回」メッセージを介して）。
When an LSR determines that it has lost its LDP session with another LSR, the following actions are taken:
LSRが別のLSRとのLDPセッションを失ったと判断した場合、次のアクションが実行されます。
- MUST discard any binding information learned via this connection;
- この接続を介して学んだ拘束力のある情報を廃棄する必要があります。
- For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR may destroy these bindings (and deallocate labels associated with these binding).
- ピアからラベルバインディングリクエストを受信した結果として作成されたラベルバインディングの場合、LSRはこれらのバインディングを破壊する可能性があります（これらのバインディングに関連するレーベルを扱います）。
The above discussion assumes that an edge LSR will request one label for each prefix in its routing table that has a next hop in the FR-LSR domain. In fact, it is possible to significantly reduce the number of labels needed by having the edge LSR request instead one label for several routes. Use of many-to-one mappings between routes (address prefixes) and labels using the notion of Forwarding Equivalence Classes (as described in [ARCH]) provides a mechanism to conserve the number of labels.
上記の議論では、Edge LSRがFR-LSRドメインに次のホップがあるルーティングテーブルの各プレフィックスの1つのラベルを要求することを前提としています。実際、いくつかのルートで1つのラベルの代わりにEdge LSR要求を使用することにより、必要なラベルの数を大幅に削減することができます。等価クラスを転送する概念（[Arch]に記載されている）を使用して、ルート（アドレスプレフィックス）とラベル間の多面マッピングの使用（[Arch]に記載されている）は、ラベルの数を保存するメカニズムを提供します。
Note that conserving label space (VC merging) may be restricted in case the frame traffic requires Frame Relay fragmentation. The issue is that Frame Relay fragments must be transmitted in sequence, i.e., fragments of distinct frames must not be interleaved. If the fragmenting FR-LSR ensures the transmission in sequence of all fragments of a frame, without interleaving with fragments of other frames, then label conservation (VC merging) can be performed.
フレームトラフィックにフレームリレーの断片化が必要な場合に備えて、ラベルスペース（VCマージ）の保存が制限される場合があることに注意してください。問題は、フレームリレーフラグメントを順番に送信する必要があることです。つまり、異なるフレームのフラグメントをインターリーブしてはなりません。断片化するFR-LSRが、他のフレームのフラグメントとインターリーブすることなく、フレームのすべてのフラグメントのシーケンスで伝送を保証する場合、ラベル保存（VCマージ）を実行できます。
When label conservation is used, when a FR-LSR receives a binding request from an upstream LSR for a certain FEC, and it does already have an outgoing label binding for that FEC, it does not need to issue a downstream binding request. Instead, it may allocate an incoming label, and return that label in a binding to the upstream requester. Packets received from the requester, with that label as top label, will be forwarded after replacing the label with the existing outgoing label for that FEC. If the FR-LSR does not have an outgoing label binding for that FEC, but does have an outstanding request for one, it need not issue another request. This means that in a label conservation case, a FR-LSR must respond with a new binding for every upstream request, but it may need to send one binding request downstream.
ラベル保存が使用される場合、FR-LSRが特定のFECに対して上流のLSRから拘束力のあるリクエストを受信し、そのFECの発信ラベルバインディングがすでにある場合、下流の結合リクエストを発行する必要はありません。代わりに、着信ラベルを割り当て、そのラベルを上流のリクエスト担当者にバインディングして返す場合があります。リクエスターから受け取ったパケットは、そのラベルをトップラベルとして、そのFECの既存の発信ラベルにラベルを置き換えた後に転送されます。FR-LSRがそのFECの発信ラベルバインディングを持っていないが、1つの未解決のリクエストがある場合、別のリクエストを発行する必要はありません。これは、ラベル保存の場合には、FR-LSRが上流の要求ごとに新しいバインディングで応答する必要があることを意味しますが、1つのバインディングリクエストを下流に送信する必要がある場合があります。
In case of label conservation, if a change in the routing table causes FR-LSR to select a new next hop for one of its FECs, it MAY release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it must request one (note that the choice depends on the label retention mode [ARCH]).
ラベルの保存の場合、ルーティングテーブルの変更によりFR-LSRがFECの1つの新しい次のホップを選択すると、前の次のホップからそのルートのバインディングがリリースされる場合があります。新しい次のホップに対応するバインディングがまだない場合は、要求する必要があります（選択はラベル保持モード[ARCH]に依存することに注意してください）。
If a new binding is obtained, which contain a hop count that differs from that of the old binding, the FR-LSR must process the new hop count: increment by 1, if different than "unknown", and notify the upstream neighbors who have label bindings for this FEC of the new value. To ensure that loops will be detected, if the new hop count exceeds the "maximum" value, the label values for this FEC must be withdrawn from all upstream neighbors to whom a binding was previously sent.
古いバインディングのそれとは異なるホップカウントを含む新しいバインディングが得られる場合、FR-LSRは新しいホップカウントを処理する必要があります：「不明」とは異なる場合、1倍になり、上流の隣人に通知する必要があります。新しい値のこのFECのラベルバインディング。ループが検出されることを確認するために、新しいホップカウントが「最大」値を超える場合、このFECのラベル値は、以前にバインディングが送信されたすべての上流の隣人から引き出されなければなりません。
The Label Distribution Protocol [LDP] messages exchanged between two Frame Relay "LDP-peer" LSRs may contain Frame Relay specific information such as:
2つのフレームリレー「LDP-PEER」LSRの間で交換されたラベル分布プロトコル[LDP]メッセージには、次のようなフレームリレー特定の情報が含まれている場合があります。
"Frame Relay Label Range":
「フレームリレーラベル範囲」：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with the following fields:
次のフィールドで：
Reserved This fields are reserved. They must be set to zero on transmission and must be ignored on receipt.
予約されているこのフィールドは予約されています。それらは送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Len This field specifies the number of bits of the DLCI. The following values are supported:
このフィールドは、DLCIのビット数を指定します。次の値がサポートされています。
Len DLCI bits
len dlciビット
0 10 2 23
0 10 2 23
Len values 1 and 3 are reserved for future use.
LEN値1と3は、将来の使用のために予約されています。
Minimum DLCI This 23 bit field is the binary value of the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported by the originating FR-LSR. The Minimum DLCI should be right justified in this field and the preceding bits should be set to 0.
最小DLCIこの23ビットフィールドは、発信元のFR-LSRによってサポートされるデータリンク接続識別子（DLCIS）のブロックの下限のバイナリ値です。最小DLCIはこのフィールドで正当化される必要があり、前のビットは0に設定する必要があります。
Maximum DLCI This 23 bit field is the binary value of the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported by the originating FR-LSR. The Maximum DLCI should be right justified in this field and the preceding bits should be set to 0.
最大DLCIこの23ビットフィールドは、発信元のFR-LSRによってサポートされるデータリンク接続識別子（DLCIS）のブロックの上限のバイナリ値です。最大DLCIはこのフィールドで正当化する必要があり、前のビットは0に設定する必要があります。
"Frame Relay Merge":
「フレームリレーマージ」：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |M|
+-+-+-+-+-+-+-+-+
with the following fields:
次のフィールドで：
Merge One bit field that specifies the merge capabilities of the FR-LSR:
FR-LSRのマージ機能を指定する1つのビットフィールドをマージします。
Value Meaning
価値の意味
0 Merge NOT supported
1 Merge supported
A FR-LSR that supports VC merging MUST ensure that fragmented frames from distinct incoming DLCIs are not interleaved on the outgoing DLCI.
VCの合併をサポートするFR-LSRは、異なる入っているDLCIからの断片化されたフレームが発信DLCIにインターリーブされないことを保証する必要があります。
Reserved This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約されたこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
and "Frame Relay Label":
および「フレームリレーラベル」：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with the following fields:
次のフィールドで：
Reserved This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
予約されたこのフィールドは予約されています。送信時にゼロに設定する必要があり、受領時に無視する必要があります。
Len This field specifies the number of bits of the DLCI. The following values are supported:
このフィールドは、DLCIのビット数を指定します。次の値がサポートされています。
Len DLCI bits
len dlciビット
0 10 2 23
0 10 2 23
Len values 1 and 3 are reserved for future use.
LEN値1と3は、将来の使用のために予約されています。
DLCI The binary value of the Frame Relay Label. The significant number of bits (10 or 23) of the label value are to be encoded into the Data Link Connection Identifier (DLCI) field when part of the Frame Relay data link header (see Section 4.).
DLCIフレームリレーラベルのバイナリ値。レーベル値のかなりの数のビット（10または23）は、フレームリレーデータリンクヘッダーの一部の場合、データリンク接続識別子（DLCI）フィールドにエンコードされます（セクション4を参照）。
This section looks at the security aspects of:
このセクションでは、次のセキュリティの側面について説明します。
(a) frame traffic,
(a) フレームトラフィック、
(b) label distribution.
(b) ラベル分布。
MPLS encapsulation has no effect on authenticated or encrypted network layer packets, that is IP packets that are authenticated or encrypted will incur no change.
MPLSカプセル化は、認証または暗号化されたネットワークレイヤーパケットには影響しません。つまり、認証または暗号化されたIPパケットは変更されません。
The MPLS protocol has no mechanisms of its own to protect against misdirection of packets or the impersonation of an LSR by accident or malicious intent.
MPLSプロトコルには、偶然または悪意のある意図によるパケットの誤った方向性またはLSRのなりすましから保護するための独自のメカニズムはありません。
Altering by accident or forgery an existent label in the DLCI field of the Frame Relay data link layer header of a frame or one or more fields in a potentially following label stack affects the forwarding of that frame.
偶然または偽造により、フレームリレーデータリンクレイヤーヘッダーのDLCIフィールドに存在するラベルを変更します。
The label distribution mechanism can be secured by applying the appropriate level of security to the underlying protocol carrying label information - authentication or encryption - see [LDP].
ラベル分布メカニズムは、適切なレベルのセキュリティを基礎となるプロトコルを、ラベル情報 - 認証または暗号化 - [LDP]を参照してください。
The initial version of this document was derived from the Label Switching over ATM document [ATM].
このドキュメントの初期バージョンは、ATMドキュメント[ATM]を切り替えるラベルから派生しました。
Thanks for the extensive reviewing and constructive comments from (in alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller, Eric Rosen. Also thanks to George Swallow for the suggestion to use null encapsulation, and to Eric Gray for his reviewing.
（アルファベット順）ダン・ハリントン、ミラノ・マーハール、マーティン・ミューラー、エリック・ローゼンからの広範なレビューと建設的なコメントをありがとう。また、Nullカプセル化を使用することを提案してくれたGeorge Swallow、および彼のレビューのためにEric Grayに感謝します。
Also thanks to Nancy Feldman and Bob Thomas for their collaboration in including the LDP messages specific to Frame Relay LSRs.
また、フレームリレーLSRSに固有のLDPメッセージを含めて、ナンシーフェルドマンとボブトーマスのコラボレーションに感謝します。
[MIFR] Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998.
[MIFR] Bradley、T.、Brown、C。and A. Malis、「Multiprotocol Interconnect Over Frame Relay」、RFC 2427、1998年9月。
[ARCH] Rosen, E., Callon, R. and A. Vishwanathan, "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
[Arch] Rosen、E.、Callon、R。and A. Vishwanathan、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and R. Thomas、「Label Distribution Protocol」、RFC 3036、2001年1月。
[STACK] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[スタック] Rosen、E.、Rehter、Y.、Tappan、D.、Farinacci、D.、Fedorkow、G.、Li、T。およびA. Conta、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月。
[ATM] Davie, B., Lawrence, J., McCloghrie, M., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "Use of Label Switching with ATM", RFC 3035, January 2001.
[ATM] Davie、B.、Lawrence、J.、McCloghrie、M.、Rosen、E.、Swallow、G.、Rekhter、Y.、およびP. Doolan、「ATMとのラベルスイッチングの使用」、RFC 3035、2001年1月。
[ITU] International Telecommunications Union, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", ITU-T Recommendation Q.922, 1992.
[ITU] International Telecommunications Union、「ISDNデータリンクレイヤーフレームモードベアラーサービスの仕様」、ITU-T推奨Q.922、1992。
[FRF] Frame Relay Forum, User-to-Network Implementation Agreement (UNI), FRF 1.1, January 19, 1996.
[frf]フレームリレーフォーラム、ユーザーからネットワークの実装契約（UNI）、FRF 1.1、1996年1月19日。
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484
Alex Conta Transwitch Corporation 3エンタープライズドライブシェルトン、コネチカット06484
Phone: 1-203-929-8810 EMail: aconta@txc.com
電話：1-203-929-8810メール：aconta@txc.com
Paul Doolan Ennovate Networks 60 Codman Hill Rd Boxborough MA 01719
Paul Doolan Enovate Networks 60 Codman Hill Rd Boxborough MA 01719
Phone: 1-978-263-2002 EMail: pdoolan@ennovatenetworks.com
電話：1-978-263-2002メール：pdoolan@ennovatenetworks.com
Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 USA
Andrew G. Malis Vivace Networks、Inc。2730 Orchard Parkway San Jose、CA 95134 USA
Phone: 1-408-383-7223 Fax: 1-408-904-4748 EMail: Andy.Malis@vivacenetworks.com
電話：1-408-383-7223 FAX：1-408-904-4748メール：andy.malis@vivacenetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。