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.
著作権（C）インターネット協会（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）の部分を明確にしています。 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など、など、である）、およびそれらの転送がこれらのルーティングアルゴリズムの結果に基づいています。いかなる特定のフレームリレーのルーティングは必要ありません。
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）をベースのトラフィックをラベルスイッチングを実行するように構成することができます。 DLCIは、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で定義されているキーワードは、MAY、OPTIONAL、必須、推奨、、、、解釈されるすべきでないないものとものとしてはなりませんしなければなりません。
This document is a companion document to [STACK] and [ATM].
この文書では、コンパニオン[STACK]の文書と、[ATM]です。
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つのそのようなインターフェイスの間でフレームを転送する一つまたはそれ以上の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ドメインは、互いにLC-FRインタフェースによって相互接続されるFR-のLSRの集合です。
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ドメインの辺集合はLC-FRインタフェースによってドメインに接続されているのLSRのセットです。
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、ジェネリック）（IP、など）のタイプでありますヘッダ。
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.
そのパケットは何のMPLSカプセル化を持っていない場合は、入力カプセル化は、MPLSカプセル化のタイプ、そのパケットがLSRのインターフェイスで受信されたパケット、またはネットワーク層の（フレームリレー、ATM、ジェネリック）（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.
そのパケットは何のMPLSカプセル化を持っていない場合、出力カプセル化は、MPLSカプセル化のタイプ、そのパケットがLSRのインターフェイス上で送信されたパケット、またはネットワーク層の（フレームリレー、ATM、ジェネリック）（IP、など）のカプセル化です。
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インタフェース、またはネットワーク層（IP）TTLで受信されるスタックの上部のMPLS 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インタフェース、またはネットワーク層（IP）TTLで送信されるスタックの上部のMPLSの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.
アーキテクチャラベルスイッチングは、LSRの実装にかなりの柔軟性を可能にしながら、FR-LSRは、（おそらく既存の）ハードウェアの機能とフレームリレー[MIFR】オーバーマルチインターコネクトによって課されたフレームフォーマットのような事項の制限によって制約されていますそのためこれらの制約のなど、またはフレームリレー規格[FRF]は、....、いくつかの特別な手順はFR-LSRのために必要とされます。
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）上で実行されます。これは、パケットにラベル（S）のサイズと配置を決定します。 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デクリメント」機能を実行するいかなる能力は、一般的に存在しません。
- 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への複数の入力の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:
[STACK]で定義されるようにデフォルトでは、すべての標識されたパケットは、フレームリレーヌルカプセル化メカニズムを使用して、一般的なラベルカプセル化を用いて送信されるべきです。
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」は2つのまたは4オクテットであり得るQ.922アドレスの長さです。
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.
一般的なカプセル化はなく、むしろあるラベル用深度のラベルスタックの最上位スタックエントリはEXP、S、及びTTLフィールドの有意な値を運ぶ「N」[STACK]、[STACK]は、「N」ラベルを含みます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において、上部（電流）MPLSラベルは、フレームのフレームリレーデータリンク層ヘッダのDLCI分野で運ばれます。トップラベルは暗黙的にネットワークプロトコルの種類についての情報を運びます。
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はDLCIは、スイッチ間のIPルーティングプロトコルを実行するために使用される構成と同様の構成の仕方によって値が割り当てられます。
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.
この構成値を除いて、リンクの両方向でMPLSのために使用されるDLCI値は、すなわち、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.
DLCIの許容範囲は、のDLCIの大きさ、および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からのパケットPを送信する場合LSR2に、ラベルスタックの同一の符号化を使用し、その後、LSR3にすることが可能です。このような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である場合、LSR2にパケットPを送信する際LSR1はラベルスタックの符号化を使用するが、LSR3にパケットPを送信する場合LSR2は異なる符号化を使用することが可能です。一般的には、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.
当然フレームリレーの組み合わせは、一般的な（MPLSシムヘッダ）、またはATMカプセル化のような他のMPLSカプセル化を使用して動作のLSR、および他のLSRとして動作スイッチ含むMPLSネットワークが存在することになります。そのようなネットワークでは、いくつかのフレームリレーインタフェースを持つのLSR、並びにMPLSジェネリック（「MPLSシム」）インタフェースが存在してもよいです。これは、同じLSPの異なるホップ上の異なるラベルスタックエンコーディングとLSRの一例です。そのようなLSRは、入力インターフェイス上でフレームリレー符号化されたラベルをオフに交換し、発信インターフェイス上の汎用MPLS（MPLSシム）ヘッダにエンコードされたラベルで置き換えてもよいです。
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ホップの総数は、その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ホップの数を反映すべきです。ユニキャストの場合、これは[ARCH非TTL LSPセグメントにパケットを転送する前にTTL値をデクリメントする進入を可能にする、FR-LSRの入口ノードに意味のあるLSP長又はLSPフレームリレーセグメント長を伝播することによって達成することができます。
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 LSPセグメント」の出口に到達する前に、特定のパケットのTTLが期限切れになることをMPLS TTLをデクリメントすると判断した場合は、FR-LSRはパケットを切り替えるラベルではなく、従っていなければなりません。パケットの送信元にエラーメッセージを返すための試みで、[STACK]で仕様：
- 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セグメント長は、非TTL LSPセグメントからパケットを転送する前にTTL値をデクリメントする出力をイネーブル、FR-LSR出口ノードに伝播されます。
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:
"入力カプセル化"（IE）の "D"、 "カプセル化を転送する"（FE）、および "出力カプセル化"（OE）。続いて「出力TTL」を生成する「入力TTL」に適用される計算は、として記述することができます。
output TTL = input TTL - D(ie, fe, oe)
出力TTL = TTL入力 - D（すなわち、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.
それは分散場合LDP [LDPは、このような「ホップカウント」値を提供した場合は、「LSPセグメントのホップ数」は、パケットが転送されるときに使用されるラベルが添付された「ホップカウント」の値でありますLSPのためのラベルは、「ホップ数のオブジェクトを」持っていたことが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:
「I」は、IP（ネットワーク層）汎用MPLSのため、「G」、およびフレームリレーMPLSは、「F」の略語「I」入力する場合とLSRインタフェースを参照略語で「転送カプセル化」を参照それはフレームリレーである場合、または、出力カプセル化は「」とき、それはATMであり、さらに記号「IIF」を考慮して、入力または出力MPLSカプセル化が汎用MPLSとき、「G」、IPなしMPLSカプセル化である「F」、入力、転送および出力カプセル化とのLSRとして「GGF」、「FFF」、等...上記言及したが、以下は、前のセクションで説明同種および異種の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
"IIF" は、フレームリレーLSPの "入口LSR" であると計算：mpls_ttl = IP_TTL - ホップ数= N-5 "FIIは、" フレームリレーLSPからの "出口LSR" であり、計算：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
「IIGは、」LSPで「イングレスLSR」です。それは計算：mpls_ttl = N-1「GGFは、」フレームリレーセグメントで汎用MPLSセグメントから「出口LSR」、及び「入口LSR」であると計算：mpls_ttl = N-6「FGA」フレーム・リレー・セグメントからの「出口LSR」、そしてATMセグメント内の「入口LSR」と計算：mpls_ttl = N-9「GGFは、」フレームリレーセグメントで汎用MPLSセグメントから「出口LSR」、及び「入口LSR」であると計算：mpls_ttl = N-13「FGG」がありますフレーム・リレー・セグメントからの "出口LSR" と入口LSR」汎用MPLSセグメントおよび計算：mpls_ttl = N-14 "GIIは、LSPから出口LSR "" であり" と計算：IP_TTL = N-15
And further examples:
そしてさらなる例：
Frame Relay Unicast -- TTL calculated at 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
フレームリレーマルチキャスト - 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ラベルスタック[STACK]を含むであろうことを除いて、通常のネットワーク層転送操作によって転送されます。フレームリレーヌルカプセル化は暗黙的にのみ、そのネットワーク・プロトコルに関連付けられている必要があり、ラベル、ネットワーク層プロトコルに関する情報を伝送します。トップラベルスタックエントリ内の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.
セグメントはLSPを形成...などリレー、PPP、イーサネット、ATMを、フレーム - - （b）は、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".
「非TTLセグメント」のホップ数に関して出口FR-LSRに意味のある情報を渡す必要がマルチキャストパケットの場合、MPLS TTLは、LSPを構築する1】LDPだけデクリメントされるべきです。
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カプセル化されたパケットを運ぶフレームリレーフレームは、次のLSRにフレームリレーVCに転送されます。
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.
出力インタフェースは、一般的なもの、またはLSP（異種）の次のATMセグメントのホップ数である場合、出力インタフェースは、ATM（非TTLである場合、ユニキャストパケットの場合、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].
フレームリレースイッチラベルスイッチングをサポートするには、ラベル割り当ておよび保守手順で主に構成されてラベル・スイッチングの制御コンポーネントを実装しなければなりません。ラベルバインディング情報は、ラベル配布プロトコル（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.
フレームリレー回路は、伝統的なフレームリレー機構からのNOの関与と、LDP、またはRSVP、等を介して確立される場合には、そのような入力/出力の最大フレームサイズ、要求された着信/発信/合意された契約情報を確立し、その回路を想定していますスループット、発信/受信許容されるスループット、着信/発信バーストサイズは、着信/発信の送信に使用されるフレームレート、および輻輳制御はRSVPを介してFR-のLSRに渡すことができる、または静的に設定することができます。また、輻輳の結果としてフラグ付け、その輻輳制御及びフレームヘッダは、従来のフレームリレー回路のと同様の方法でFR-のLSRによって行われるであろうと想定されます。入力ポリシングがでDEビットを設定するようにデフォルトとしてベストエフォート型ルータをエミュレートする目的で、デフォルトのVCのLDPの非存在下でのパラメータ、RSVP、またはそのようなパラメータを設定する他のメカニズムへの参加は、ゼロ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（フレーミング、ビットスタッフィング、ヘッダ、FCS）への適合を必要とします。 PVCおよび/またはSVCのためのQ.933シグナリングが必要とされていません。両方がMPLSと同じインターフェイス上で実行されている場合、次のセクションで説明したようにPVC及び/又はSVCシグナリングは、非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.
フレームリレースイッチのラベルスイッチング制御成分の存在は、ITUによって定義されたフレームリレー制御コンポーネントをサポートし、同一のスイッチと同じインタフェース（NIC）にリレーフォーラムをフレームに能力を排除するものではありません。 2つの制御部品、ラベルスイッチングおよびITU /フレームリレーフォーラムで定義されたものは、独立して動作します。
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によって使用されなければならない、そしてそれはまた、FR-のLSRによって使用されるかもしれマージVCが（このことに注意してサポートしていないことメカニズムは、ホップバイホップにルーティングされたトラフィック）適用されます。
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-フレームリレーインタフェースを介して到達可能であること、と仮定する。ネクストホップFR-LSRは "LDPピア" [ARCH] [LDP]であると仮定する。エッジLSRは次のホップ、川下のLSRからラベルバインディングのためのLDP「要求」メッセージを送信します。エッジLSRは、下流LSRからの応答にLDP「マッピング」メッセージ内のラベルバインディング情報を受信すると、ラベルはそのFECの発信ラベルとしてラベル情報ベース（LIB）に格納されています。 「マッピング」メッセージは、このラベルを使用した場合、パケットが出力FR-LSRにFR-LSRドメインを横断するのにかかるホップの数を表し、「ホップ数」オブジェクトを含んでいてもよいです。この情報は、TTLの計算のために記憶されてもよいです。これが行われると、LSRはそのFECにパケットを送信するMPLS転送を使用してもよいです。
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ドメインのエッジセットのメンバーは、FECのためのFR-LSRからLDP「要求」メッセージを受信すると、それが出口-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ドメインであった場合、エッジ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);
- それは、そのルート（FEC）のために、LSR次ホップに下流LDP「要求」メッセージを送信することによって、「要求」を伝播します。
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は、順序付けられた」（「要求」に応答して上流の「マッピング」を返す前に「マッピング」メッセージを下流側から応答されるその「要求」を待機します制御」アプローチ[ARCH]）。この場合、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.
経路計算は、経路（FEC）のための次のホップを変更するFR-LSRを引き起こす場合、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は、変化に気づかない（一つの例外を除いて、以下に記載されます）。新しいネクストホップがFR-LSRまたはLC-FRインタフェースを介して到達可能な設定エッジのメンバである場合、LSRは、次いで、経路LSRに関連付けられ、そのLIB内の各エントリについて、特定のルートのために次のホップを変更するたびに新しい次のホップからのバインディング（LDP経由）を要求すべきです。
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は、下流隣人から結合標識を受信すると、下流の結果であるから、それは「独立した制御」またはので、新しいバインディングを使用しているいずれかのために、それは既に、上流隣接この経路のバインディング対応するラベルを提供していることができますルーティング変更の。この場合、それは新しいバインディングからのホップ数を抽出しなければならないし、いずれかによって、それをインクリメント。新しいホップカウントは、以前（上流ネイバーが「不明」の値が与えられた場合も含む）上流の隣人に搬送されたものと異なる場合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にラベルバインディング要求を発信するたびに、FR-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.
上記の議論は、エッジLSRは、FR-LSRドメイン内の次のホップを有するそのルーティングテーブル内の各プレフィックスのためつのラベルを要求することを想定しています。実際には、かなりの代わりに、いくつかのルートのための1つのラベルをエッジLSR要求を有することにより、必要なラベルの数を削減することができます。転送等価クラスの概念を使用してルート（アドレスプレフィックス）とラベルの間の多対一のマッピングを使用することは、（[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のために結合発信ラベルを持っていませんが、いずれかの未処理の要求を持っていない場合は、別の要求を発行する必要はありません。これは、ラベルの保全場合には、FR-LSRは、すべての上流の要求に対して新しいバインディングで応答しなければならないが、それは下流の一つの結合要求を送信する必要があるかもしれないことを意味します。
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.
「不明」と異なる場合は、1によりインクリメントし、持っている上流の隣人に通知：新しいバインディングは、古いバインディングとは異なるホップ数を含んでいる、得られた場合、FR-LSRは新しいホップカウントを処理しなければなりません新しい価値のこのFECのためのラベルバインディング。新しいホップカウントが「最大」値を超えた場合にループが検出されることを保証するために、このFECのためのラベルの値は、以前に送信されたバインディングの人に、すべての上流の隣人から撤退しなければなりません。
The Label Distribution Protocol [LDP] messages exchanged between two Frame Relay "LDP-peer" LSRs may contain Frame Relay specific information such as:
ラベル配布プロトコル[LDP]メッセージは、「LDPピア」のLSRは、フレームリレー固有の情報などを含んでいてもよい2つのフレームリレーとの間で交換しました。
"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
レンDLCIビット
0 10 2 23
０ １０ ２ ２３
Len values 1 and 3 are reserved for future use.
レンは、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によってサポートされているデータ・リンク接続識別子（DLCI）のブロックの下限のバイナリ値です。最小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によってサポートされているデータ・リンク接続識別子（DLCI）のブロックの上限のバイナリ値です。最大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
0 1つのマージをサポートサポートされていませんマージ
A FR-LSR that supports VC merging MUST ensure that fragmented frames from distinct incoming DLCIs are not interleaved on the outgoing DLCI.
FR-LSR VCが合併サポートの異なる、着信の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
レンDLCIビット
0 10 2 23
０ １０ ２ ２３
Len values 1 and 3 are reserved for future use.
レンは、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）のかなりの数は、フレームリレーデータリンクヘッダの一部（セクション4を参照）と、データリンク接続識別子（DLCI）フィールドに符号化されるべきです。
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.
事故又は偽造潜在的に以下のラベルスタック内のフレームまたは1つ以上のフィールドのフレームリレーデータリンク層ヘッダの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.
大規模な見直しと（アルファベット順）ダン・ハリントン、ミラノMerhar、マーティン・ミューラー、エリック・ローゼンからの建設的なコメントをありがとう。また、彼の見直しのために、そしてエリックグレーにヌルカプセル化を使用するための提案のためのジョージくんのおかげ。
Also thanks to Nancy Feldman and Bob Thomas for their collaboration in including the LDP messages specific to Frame Relay LSRs.
また、リレーのLSRをフレームに特定のLDPメッセージなどでのコラボレーションのためのナンシー・フェルドマンとボブトーマスのおかげ。
[MIFR] Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998.
[MIFR]ブラッドリー、T.、ブラウン、C.とA. Malis、 "フレームリレー上のマルチインターコネクト"、RFC 2427、1998年9月。
[ARCH] Rosen, E., Callon, R. and A. Vishwanathan, "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
[ARCH]ローゼン、E.、Callon、R.と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]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.とR.トーマス、 "ラベル配布プロトコル"、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.
[STACK]ローゼン、E.、Rehter、Y.、タッパン、D.、ファリナッチ、D.、Fedorkow、G.、李、T.、およびA.コンタ、 "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]デイビー、B.、ローレンス、J.、McCloghrie、M.、ローゼン、E.、ツバメ、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]国際電気通信連合、「フレームモードベアラサービスのための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
アレックス・コンタTranSwitch社株式会社3エンタープライズ・ドライブシェルトン、CT 06484
Phone: 1-203-929-8810 EMail: aconta@txc.com
電話：1-203-929-8810 Eメール：aconta@txc.com
Paul Doolan Ennovate Networks 60 Codman Hill Rd Boxborough MA 01719
ポールDoolan Ennovateネットワーク60 CodmanヒルRdのボックスボローMA 01719
Phone: 1-978-263-2002 EMail: pdoolan@ennovatenetworks.com
電話：1-978-263-2002 Eメール：pdoolan@ennovatenetworks.com
Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 USA
アンドリューG. Malisビバーチェネットワークス株式会社2730オーチャードパークウェイサンノゼ、CA 95134 USA
Phone: 1-408-383-7223 Fax: 1-408-904-4748 EMail: Andy.Malis@vivacenetworks.com
電話：1-408-383-7223ファックス：1-408-904-4748 Eメール：Andy.Malis@vivacenetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。