Network Working Group B. Davie
Request for Comments: 3035 J. Lawrence
Category: Standards Track K. McCloghrie
E. Rosen
G. Swallow
Cisco Systems, Inc.
Y. Rekhter
Juniper Networks
P. Doolan
Ennovate Networks, Inc.
January 2001
MPLS using LDP and ATM VC Switching
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
抽象
The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers).
マルチプロトコルラベルスイッチング（MPLS）アーキテクチャ[1]非同期転送モード（ATM）スイッチはラベルスイッチングルータとして使用することができる方法を説明します。 ATMは、（中間システム（IS-IS）などのオープンショーテストパスファースト（OSPF）、中間システムのような）ネットワーク層ルーティングアルゴリズムを実行するスイッチ、及びそのデータ転送はこれらのルーティングアルゴリズムの結果に基づいています。いいえATM固有のルーティングやアドレッシングは必要ありません。このように使用されるATMスイッチはATM-のLSR（ラベルスイッチングルータ）として知られています。
This document extends and clarifies the relevant portions of [1] and [2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms.
この文書は延びての関連する部分を明確に[1]および[2]より詳細に指定することにより、またはATM-のLSRからラベルを配布するときに使用する手順は、これらのラベルは、転送等価クラスを表す場合（のFECは、[1を参照]）ルートがネットワーク層ルーティングアルゴリズムによって、ホップバイホップに基づいて決定されます。
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3].
この文書はまた、またはATM-のLSRからラベル付きパケットを送信するときに使用されるMPLSカプセル化を指定し、その点での仲間ドキュメントである[3]。
Table of Contents
目次
1 Introduction ........................................... 2
2 Specification of Requirements .......................... 3
3 Definitions ............................................ 3
4 Special Characteristics of ATM Switches ................ 4
5 Label Switching Control Component for ATM .............. 5
6 Hybrid Switches (Ships in the Night) ................... 5
7 Use of VPI/VCIs ....................................... 5
7.1 Direct Connections ..................................... 6
7.2 Connections via an ATM VP .............................. 7
7.3 Connections via an ATM SVC ............................. 7
8 Label Distribution and Maintenance Procedures .......... 7
8.1 Edge LSR Behavior ...................................... 8
8.2 Conventional ATM Switches (non-VC-merge) ............... 9
8.3 VC-merge-capable ATM Switches .......................... 11
9 Encapsulation .......................................... 12
10 TTL Manipulation ....................................... 13
11 Optional Loop Detection: Distributing Path Vectors ..... 15
11.1 When to Send Path Vectors Downstream ................... 15
11.2 When to Send Path Vectors Upstream ..................... 16
12 Security Considerations ................................ 17
13 Intellectual Property Considerations ................... 17
14 References ............................................. 18
15 Acknowledgments ........................................ 18
16 Authors' Addresses ..................................... 18
17 Full Copyright Statement ............................... 20
The MPLS Architecture [1] discusses the way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs.
MPLSアーキテクチャは、[1] ATMスイッチはラベルスイッチングルータとして使用することができる方法を説明します。 ATMは（IS-ISなど、OSPFなど）、ネットワーク層ルーティングアルゴリズムを実行するスイッチ、及びそのデータ転送はこれらのルーティングアルゴリズムの結果に基づいています。いいえATM固有のルーティングやアドレッシングは必要ありません。このように使用されるATMスイッチは、ATM-LSRのとして知られています。
This document extends and clarifies the relevant portions of [1] and [2] by specifying in more detail the procedures which are to be used for distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. The label distribution technique described here is referred to in [1] as "downstream-on-demand". This label distribution technique MUST be used by ATM-LSRs that are not capable of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs that are capable of VC merge.
この文書では、これらのラベルは、転送等価クラス（のFECは、参照[表す場合、より詳細にATM-LSRのまたはからラベルを分配するために使用される手順を指定して、[1]と[2]の関連部分を拡張し、明確1]）ルートがネットワーク層ルーティングアルゴリズムによって、ホップバイホップに基づいて決定されます。ここで説明したラベル配布技術[1]「下流オンデマンド」として呼ばれます。このラベル配布技術（セクション3で定義）「VCマージ」することができないATM-のLSRによって使用され、VCマージが可能であるATM-LSRのためのオプションでなければなりません。
This document does NOT specify the label distribution techniques to be used in the following cases:
このドキュメントは、次のような場合に使用するラベル配布方法を指定しません。
- the routes are explicitly chosen before label distribution begins, instead of being chosen on a hop-by-hop basis as label distribution proceeds,
- ルートが明示的代わりにラベル配布が進むにつれてホップバイホップに基づいて選択されるので、ラベル配布が開始される前に選択され、
- the routes are intended to diverge in any way from the routes chosen by the conventional hop-by-hop routing at any time,
- ルートは、いつでも従来のホップバイホップルーティングによって選択された経路からのどのような方法で発散することを意図しています
- the labels represent FECs that consist of multicast packets,
- ラベルは、マルチキャストパケットから成るのFECを表します
- the LSRs use "VP merge".
- のLSRは、「VPマージ」を使用します。
Further statements made in this document about ATM-LSR label distribution do not necessarily apply in these cases.
ATM-LSRのラベル配布については、この文書で作られたさらなるステートメントは、必ずしもこのような場合には適用されません。
This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3]. The specified encapsulation is to be used for multicast or explicitly routed labeled packets as well.
この文書はまた、またはATM-のLSRからラベル付きパケットを送信するときに使用されるMPLSカプセル化を指定し、その点での仲間ドキュメントである[3]。指定されたカプセル化は、マルチキャストのために使用されるか、または明示的にもラベル付きパケットをルーティングされます。
This document uses terminology from [1].
この文書では、[1]から用語を使用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [1].
ラベルスイッチングルータ（LSR）は、[1]に記載の制御および転送コンポーネントラベルスイッチングを実現する装置です。
A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component. When a packet traversing such an interface is received, it is treated as a labeled packet. The packet's top label is inferred either from the contents of the VCI field or the combined contents of the VPI and VCI fields. Any two LDP peers which are connected via an LC-ATM interface will use LDP negotiations to determine which of these cases is applicable to that interface.
制御されたATM（LC-ATM）をラベルスイッチングインタフェースラベルスイッチング制御コンポーネントによって制御されるATMインタフェースです。そのようなインターフェースを横断パケットを受信した場合、それを標識パケットとして扱われます。パケットのトップラベルはVCIフィールドの内容またはVPIとVCIフィールドの組み合わせ内容のいずれかから推測されます。 LC-ATMインタフェースを介して接続されている任意の二つのLDPピアは、そのインターフェイスに適用可能であるこれらのケースのどちらかを決定するためにLDP交渉を使用します。
An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces, using labels carried in the VCI or VPI/VCI field, without reassembling the cells into frames before forwarding.
ATM-LSRに転送する前に、フレームに細胞を再組み立てすることなく、VCIまたはVPI / VCIフィールドで運ばれたラベルを使用して、これらのインタフェースの間の細胞を転送LC-ATMインターフェイスの数とLSRです。
A frame-based LSR is a LSR which forwards complete frames between its interfaces. Note that such a LSR may have zero, one or more LC-ATM interfaces.
フレームベースのLSRは、そのインターフェイス間の完全なフレームを転送LSRです。そのようなLSRは、ゼロ、1つまたはそれ以上のLC-ATMインターフェイスを有していてもよいことに留意されたいです。
Sometimes a single box may behave as an ATM-LSR with respect to certain pairs of interfaces, but may behave as a frame-based LSR with respect to other pairs. For example, an ATM switch with an ethernet interface may function as an ATM-LSR when forwarding cells between its LC-ATM interfaces, but may function as a frame-based LSR when forwarding frames from its ethernet to one of its LC-ATM interfaces. In such cases, one can consider the two functions (ATM-LSR and frame-based LSR) as being coresident in a single box.
時には単一のボックスは、インターフェースの特定のペアに対してATM-LSRとして動作することができるが、他のペアに対するフレームベースのLSRとして動作することができます。そのLC-ATMインターフェイス間の細胞を転送する場合、例えば、イーサネットインターフェイスとATMスイッチは、ATM-LSRとして機能することができるが、そのLC-ATMインターフェイスの一つに、イーサネットのフレームを転送する際にフレームベースのLSRとして機能することができます。このような場合には、一方が単一のボックスで共存あるように、2つの機能（ATM-LSRとフレームベースのLSR）を考慮することができます。
It is intended that an LC-ATM interface be used to connect two ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR. The use of an LC-ATM interface to connect two frame-based LSRs is not considered in this document.
LC-ATMインターフェイスは、2つのATM-のLSRを接続するために、またはフレームベースのLSRにATM-LSRを接続するために使用されることが意図されます。 2フレームベースのLSRを接続するためのLC-ATMインタフェースの使用は本書では考慮されていません。
An ATM-LSR domain is a set of ATM-LSRs which are mutually interconnected by LC-ATM interfaces.
ATM-LSRドメインは互いにLC-ATMインタフェースによって相互に接続されているATM-LSRのセットです。
The Edge Set of an ATM-LSR domain is the set of frame-based LSRs which are connected to members of the domain by LC-ATM interfaces. A frame-based LSR which is a member of an Edge Set of an ATM-LSR domain may be called an Edge LSR.
ATM-LSRドメインの辺集合はLC-ATMインタフェースによってドメインのメンバに接続されているフレームベースのLSRの集合です。 ATM-LSRドメインの辺集合のメンバーであるフレームベースのLSRは、エッジLSRと呼ばれることもあります。
VC-merge is the process by which a switch receives cells on several incoming VCIs and transmits them on a single outgoing VCI without causing the cells of different AAL5 PDUs to become interleaved.
VCマージは、スイッチが複数の着信のVCIのセルを受信し、インターリーブさになるように異なるAAL5 PDUの細胞を生じさせることなく、単一の発信VCIにそれらを送信するプロセスです。
While the MPLS architecture permits considerable flexibility in LSR implementation, an ATM-LSR is constrained by the capabilities of the (possibly pre-existing) hardware and the restrictions on such matters as cell format imposed by ATM standards. Because of these constraints, some special procedures are required for ATM-LSRs.
MPLSアーキテクチャはLSRの実装にかなりの柔軟性を可能にしながら、ATM-LSRは、（おそらく既存の）ハードウェアの機能とATM規格によって課されるセルフォーマットなどの事項の制限によって制約されます。そのためこれらの制約のため、いくつかの特別な手順がATM-LSRのために必要とされます。
Some of the key features of ATM switches that affect their behavior as LSRs are:
LSRとして彼らの行動に影響を与えるATMスイッチの主要な機能は次のとおりです。
- the label swapping function is performed on fields (the VCI and/or VPI) in the cell header; this dictates the size and placement of the label(s) in a packet.
- ラベルスワッピング機能はセルヘッダー内のフィールド（VCI及び/又はVPI）上で実行されます。これは、パケットにラベル（S）のサイズと配置を決定します。
- multipoint-to-point and multipoint-to-multipoint VCs are generally not supported. This means that most switches cannot support 'VC-merge' as defined above.
- マルチポイントツーポイントおよびマルチポイント・ツー・マルチポイントのVCは、一般的にサポートされていません。これは、上で定義したほとんどのスイッチは、「VC-マージ」をサポートできないことを意味します。
- there is generally no capability to perform a 'TTL-decrement' function as is performed on IP headers in routers.
- ルータにIPヘッダーで実行されるように「TTLデクリメント」機能を実行するいかなる能力は、一般的に存在しません。
This document describes ways of applying label switching to ATM switches which work within these constraints.
この文書では、これらの制約の範囲内で動作するATMスイッチにラベルスイッチングを適用する方法について説明します。
To support label switching an ATM switch MUST implement the control component of label switching. This consists primarily of label allocation, distribution, and maintenance procedures. Label binding information is communicated by several mechanisms, notably the Label Distribution Protocol (LDP) [2]. This document imposes certain requirements on the LDP.
ATMスイッチラベルスイッチングをサポートするには、ラベル・スイッチングの制御コンポーネントを実装しなければなりません。これは主に、ラベル割り当て、配布、および保守手順で構成されています。ラベルバインディング情報は、いくつかのメカニズム、特にラベル配布プロトコル（LDP）[2]によって伝達されます。この文書はLDPに一定の要件を課しています。
This document considers only the case where the label switching control component uses information learned directly from network layer routing protocols. It is presupposed that the switch participates as a peer in these protocols (e.g., OSPF, IS-IS).
この文書は、ラベルスイッチング制御コンポーネントは、ネットワーク層ルーティングプロトコルから直接学習した情報を使用する場合のみを考えます。スイッチはこれらのプロトコル（例えば、OSPFは、IS-IS）におけるピアとして参加することが前提とされています。
In some cases, LSRs make use of other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings. In these cases, an ATM-LSR would need to participate in these protocols. However, these are not explicitly considered in this document.
いくつかのケースでは、のLSRがラベルバインディングを配布する他のプロトコル（例えば、RSVP、PIM、BGP）を利用します。これらのケースでは、ATM-LSRは、これらのプロトコルに参加する必要があります。しかし、これらは明示的にこの文書では考慮されません。
Support of label switching on an ATM switch does NOT require the switch to support the ATM control component defined by the ITU and ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM cells.
ATMスイッチのラベルスイッチングをサポートは、ITUおよびATMフォーラム（例えば、UNI、PNNI）によって定義されたATM制御コンポーネントをサポートするためのスイッチを必要としません。 ATM-LSRは、オプションOAMセルに応答することができます。
The existence of the label switching control component on an ATM switch does not preclude the ability to support the ATM control component defined by the ITU and ATM Forum on the same switch and the same interfaces. The two control components, label switching and the ITU/ATM Forum defined, would operate independently.
ATMスイッチのラベルスイッチング制御成分の存在は、同じスイッチと同じインターフェイス上ITUおよびATMフォーラムによって定義されたATM制御コンポーネントをサポートする能力を排除するものではありません。 2つの制御部品、ラベルスイッチングと定義されたITU / ATMフォーラムは、独立して動作します。
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 VPI/VCI space which are available to each component.
このようなデバイスがどのように動作するかの定義は、この文書の範囲を超えています。しかし、情報の少ない量は、各コンポーネントに利用可能であるVPI / VCIスペースの部分のような2つの制御コンポーネント間の一貫性である必要があります。
Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1]
ラベルスイッチングを転送等価クラスとラベルを関連付ける、任意置換ラベルの値を決定するステップを含む、パケットを転送するラベル値を使用することによって達成されます。 [1]を参照してください。
for further details. In an ATM-LSR, the label is carried in the VPI/VCI field, or, when two ATM-LSRs are connected via an ATM "Virtual Path", in the VCI field.
詳細については。 2 ATM-LSRのは、VCIフィールドに、ATM「仮想パス」を介して接続されているとき、ATM-LSRでは、ラベルは、VPI / VCIフィールドで運ばれるか、または。
Labeled packets MUST be transmitted using the null encapsulation, as defined in Section 6.1 of RFC 2684 [5].
RFC 2684のセクション6.1で定義されるように標識されたパケットは、ヌルカプセル化を使用して送信されなければならない[5]。
In addition, if two LDP peers are connected via an LC-ATM interface, a non-MPLS connection, capable of carrying unlabelled IP packets, MUST be available. This non-MPLS connection is used to carry LDP packets between the two peers, and MAY also be used (but is not required to be used) for other unlabeled packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST be used on the non-MPLS connection.
2つのLDPピアは、LC-ATMインタフェース、非標識IPパケットを運ぶことができる非MPLS接続を介して接続されている場合に加えて、利用可能でなければなりません。この非MPLS接続は、2つのピア間のLDPパケットを運ぶために使用され、使用されてもよい（ただし、使用する必要がない）（例えば、OSPFパケット、等のような）他の標識されていないパケットのため。 RFC 2684のLLC / SNAPカプセル化[5]非MPLS接続に使用されなければなりません。
It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or non-labelled packets. In that case, the VCI values MUST NOT be in the 0-32 range. These may use either the null encapsulation, as defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP encapsulation, as defined in Section 5.1 of RFC 2684 [5].
なお、制御情報又は非標識パケットを運ぶために使用される追加のVPI / VCIを有するLC-ATMインターフェイスを設定することが可能であるべきです。その場合には、VCI値が0~32の範囲にあってはなりません。 RFC 2684のセクション6.1で定義されるように、これらは、[5] [5]、またはLLC / SNAPカプセル化、RFC 2684のセクション5.1で定義されるように、ヌルカプセル化のいずれかを使用することができます。
We say that two LSRs are "directly connected" over an LC-ATM interface if all cells transmitted out that interface by one LSR will reach the other, and there are no ATM switches between the two LSRs.
我々は、すべてのセルが他に到達する1つのLSRによってそのインターフェイスを送信場合、2つのLSRは、LC-ATMインタフェースを介して「直接接続」されていると言うと、2つのLSRの間にATMスイッチが存在しません。
When two LSRs are directly connected via an LC-ATM interface, they jointly control the allocation of VPIs/VCIs on the interface connecting them. They may agree to use the VPI/VCI field to encode a single label.
2つのLSRが直接LC-ATMインタフェースを介して接続されている場合、それらは共同で、それらを接続するインターフェイス上のVPI / VCIの割り当てを制御します。彼らは、単一のラベルをエンコードするためにVPI / VCIフィールドを使用することに同意することができます。
The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 32. Other values can be configured, as long as both parties are aware of the configured value.
非MPLS接続のデフォルトVPI / VCIの値がVPI 0、VCI 32の他の値であれば双方が設定された値を認識しているように、構成することができます。
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label.
そのVCI部分範囲で0-32包括的であるVPI / VCIの値がラベルのエンコーディングとして使用してはなりません。
With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces.
これらの予約済みの値を除いて、リンクの両方向で使用VPI / VCI値は、独立した空間として扱うことができます。
The allowable ranges of VCIs are communicated through LDP.
VCIの許容範囲は、LDPを介して通信されています。
Sometimes it can be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via an ATM Virtual Path. In this case, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field.
時にはそれらの間の接続はATM仮想パスを経由してATM「クラウド」を介して行われていても、LC-ATMインターフェイスを介して（一部のLSPで）隣接するように2つのLSRを治療するのに有用であることができます。この場合には、VPIフィールドはMPLSを使用できません、そしてラベルはVCIフィールド内に完全に符号化されなければなりません。
In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. Other values can be configured, as long as both parties are aware of the configured value. The VPI is set to whatever is required to make use of the Virtual Path.
この場合、LSRの間の非MPLS接続のデフォルトVCI値が32以外の値であれば双方が設定された値を認識しているように、構成することができるされています。 VPIは仮想パスを利用するために必要とされているものに設定されています。
A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label.
そのVCI部分範囲で0-32包括的であるVPI / VCIの値がラベルのエンコーディングとして使用してはなりません。
With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces.
これらの予約済みの値を除いて、リンクの両方向で使用VPI / VCI値は、独立した空間として扱うことができます。
The allowable ranges of VPI/VCIs are communicated through LDP. If more than one VPI is used for label switching, the allowable range of VCIs may be different for each VPI, and each range is communicated through LDP.
VPI / VCIの許容範囲は、LDPを介して通信されています。複数のVPIは、ラベルスイッチングのために使用される場合、VCIの許容範囲は、各VPI用異なっていてもよく、各範囲は、LDPを介して通信されます。
Sometimes it may be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via a set of ATM Switched Virtual Circuits.
場合によっては、それらの間の接続が仮想回線をスイッチATMのセットを介してATM「クラウド」を介して行われているにもかかわらず、LC-ATMインタフェースを介して（いくつかのLSPに）隣接するように2つのLSRを治療するのに有用であり得ます。
The current document does not specify the procedure for handling this case. Such procedures can be found in [4]. The procedures described in [4] allow a VCID to be assigned to each such VC, and specify how LDP can be used used to bind a VCID to a FEC. The top label of a received packet would then be inferred (via a one-to-one mapping) from the virtual circuit on which the packet arrived. There would not be a default VPI or VCI value for the non-MPLS connection.
現在のドキュメントには、このケースを処理するための手順を指定していません。そのような手順は、[4]に見出すことができます。記載された手順[4] VCIDは、そのような各VCに割り当てることを可能にする、およびLDPはFECにVCIDを結合するために使用に使用することができる方法を指定します。受信したパケットのトップラベルは、パケットが到着した仮想回線からの（1対1のマッピングを介して）推測されるであろう。非MPLS接続のデフォルトVPIまたはVCI値でありではないでしょう。
This document discusses the use of "downstream-on-demand" label distribution (see [1]) by ATM-LSRs. These label distribution procedures MUST be used by ATM-LSRs that do not support VC-merge, and MAY also be used by ATM-LSRs that do support VC-merge. The procedures differ somewhat in the two cases, however. We therefore describe the two scenarios in turn. We begin by describing the behavior of members of the Edge Set of an ATM-LSR domain; these "Edge LSRs" are not themselves ATM-LSRs, and their behavior is the same whether the domain contains VC-merge capable LSRs or not.
この文書では、ATM-LSRのことで（[1]参照）、「下流オンデマンド」のラベル配布の使用について説明します。これらのラベル配布手順は、VCマージをサポートしていないATM-LSRので使用されなければならない、ともVCマージをサポートしていないATM-LSRので使用されるかもしれません。手順は、しかし、2つのケースで多少異なります。そこで今度は2つのシナリオについて説明します。私たちは、ATM-LSRドメインの辺集合のメンバーの振る舞いを記述することから始めます。これらの「エッジLSRは、」ATM-LSRを自分自身ではなく、彼らの行動は、ドメインができるのLSRのVCは、マージか含まれているかどうかと同じです。
Consider a member of the Edge Set of an ATM-LSR domain. Assume that, as a result of its routing calculations, it selects an ATM-LSR as the next hop of a certain FEC, and that the next hop is reachable via a LC-ATM interface. The Edge LSR uses LDP to request a label binding for that FEC from the next hop. The hop count field in the request is set to 1 (but see the next paragraph). Once the Edge LSR receives the label binding information, it may use MPLS forwarding procedures to transmit packets in the specified FEC, using the specified label as an outgoing label. (Or using the VPI/VCI that corresponds to the specified VCID as the outgoing label, if the VCID technique of [4] is being used.)
ATM-LSRドメインの辺集合のメンバーを考えてみましょう。ルーティング計算の結果として、それは特定のFECのネクストホップとしてATM-LSRを選択し、次ホップがLC-ATMインタフェースを介して到達可能であること、と仮定する。エッジLSRは、次のホップからそのFECに対するラベルバインディングを要求するLDPを使用しています。リクエスト内のホップ数フィールドが1に設定され（ただし、次の段落を参照）されます。エッジLSRがラベルバインディング情報を受信すると、発信ラベルとして指定されたラベルを使用して、指定されたFECにパケットを送信するMPLS転送手順を使用してもよいです。 （[4]のVCIDの技術が使用されている場合。または、VPI / VCIを使用して、出力ラベルとして指定VCIDに対応します）
Note: if the Edge LSR's previous hop is using downstream-on-demand label distribution to request a label from the Edge LSR for a particular FEC, and if the Edge LSR is not merging the LSP from that previous hop with any other LSP, and if the request from the previous hop has a hop count of h, then the hop count in the request issued by the Edge LSR should not be set to 1, but rather to h+1.
注：エッジLSRの前のホップが特定のFECのためのエッジLSRからラベルを要求するダウンストリームオンデマンドラベル配布を使用している場合、エッジLSRは、任意の他のLSPとその前のホップからLSPをマージされていない場合、及び前のホップからの要求がhのホップ数を持っている場合は、エッジLSRによって発行された要求におけるホップ数が1のではなく、H + 1に設定するべきではありません。
The binding received by the edge LSR may contain a hop count, which represents the number of hops a packet will take to cross the ATM-LSR domain when using this label. If there is a hop count associated with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this amount before transmitting the packet. In any event, it MUST adjust a data packet's TTL by at least one before transmitting it. The procedures for doing so (in the case of IP packets) are specified in section 10. The procedures for encapsulating the packets are specified in section 9.
このラベルを使用する場合、パケットがATM-LSRドメインを横断するのにかかるホップ数を表すホップ数を含むことができるエッジLSRによって受信されたバインディング。バインディングに関連付けられたホップ数がある場合は、ATM-LSRは、パケットを送信する前にこの量によって、データパケットのTTLを調整する必要があります。いずれにしても、それを送信する前に少なくとも一つのことで、データパケットのTTLを調整する必要があります。 （IPパケットの場合には）そのようにするための手順は、パケットをカプセル化するための手順はセクション9で指定されたセクション10で指定されています。
When a member of the Edge Set of the ATM-LSR domain receives a label binding request from an ATM-LSR, it allocates a label, and returns (via LDP) a binding containing the allocated label back to the peer that originated the request. It sets the hop count in the binding to 1.
ATM-LSRドメインのエッジセットのメンバーは、ATM-LSRからラベルバインディング要求を受信すると、ラベルを割り当て、（LDPを介して）リターンバック要求を発したピアに割り当てられたラベルを含む結合します。これは、1への結合におけるホップ数を設定します。
When a routing calculation causes an Edge LSR to change the next hop for a particular FEC, and the former next hop was in the ATM-LSR domain, the Edge LSR SHOULD notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
ルーティング計算が特定のFECのための次のホップを変更するエッジLSRを引き起こし、前者次ホップがATM-LSRドメインであった場合、エッジLSRは、ラベルが関連付け結合することを（LDPを介して）元の次のホップを通知するべきですFECは、もはや必要ありません。
When an ATM-LSR receives (via LDP) a label binding request for a certain FEC from a peer connected to the ATM-LSR over a LC-ATM interface, the ATM-LSR takes the following actions:
ATM-LSRが（LDPを介して）LC-ATMインタフェースを介してATM-LSRに接続されたピアからの特定のFECのラベルバインディング要求を受信すると、ATM-LSRは、次のアクションを実行します。
- it allocates a label,
- それはラベルを割り当て、
- it requests (via LDP) a label binding from the next hop for that FEC;
- そのFECのための次のホップから結合標識（LDPを介して）要求します。
- it returns (via LDP) a binding containing the allocated incoming label back to the peer that originated the request.
- それは結合バック要求を発したピアに割り当てられた受信ラベルを含む（LDPを介して）返します。
For purposes of this procedure, we define a maximum hop count value MAXHOP. MAXHOP has a default value of 255, but may be configured to a different value.
この手順の目的のために、私たちは、最大ホップカウント値MAXHOPを定義します。 MAXHOPは、255のデフォルト値を持っていますが、異なる値に設定することができます。
The hop count field in the request that the ATM-LSR sends (to the next hop LSR) MUST be set to one more than the hop count field in the request that it received from the upstream LSR. If the resulting hop count exceeds MAXHOP, the request MUST NOT be sent to the next hop, and the ATM-LSR MUST notify the upstream neighbor that its binding request cannot be satisfied.
ATM-LSRが（次のホップLSRに）送信要求にホップ・カウント・フィールドは、それが上流のLSRから受信した要求にホップカウントフィールドよりも1に設定しなければなりません。得られたホップカウントがMAXHOPを超えた場合、要求を次のホップに送信されてはいけません、そしてATM-LSRは、そのバインディング要求を満たすことができないことを上流隣接に通知しなければなりません。
Otherwise, once the ATM-LSR receives the binding from the next hop, it begins using that label.
ATM-LSRは次のホップからのバインディング受信するとそうでない場合、それはそのラベルを使用して開始します。
The ATM-LSR MAY choose to wait for the request to be satisfied from downstream before returning the binding upstream. This is a form of "ordered control" (as defined in [1] and [2]), in particular "ingress-initiated ordered control". In this case, as long as the ATM-LSR receives from downstream a hop count which is greater than 0 and less than MAXHOP, it MUST increment the hop count it receives from downstream and MUST include the result in the binding it returns upstream. However, if the hop count exceeds MAXHOP, a label binding MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be informed that the requested label binding cannot be satisfied. If the hop count received from downstream is 0, the hop count passed upstream should also be 0; this indicates that the actual hop count is unknown.
ATM-LSRは上流の結合戻す前に、下流から満たすべき要求を待つことを選択するかもしれません。これは、特に、「入開始注文管理」（[1]、[2]で定義されるように）「コントロールを注文」の形態です。この場合には、限り、ATM-LSRは、0より大きくMAXHOP未満の下流ホップカウントから受信するように、それは下流から受信し、上流返す結合に結果を含まなければなりませんホップカウントをインクリメントしなければなりません。ホップカウントがMAXHOPを超えた場合は、結合ラベルは、上流渡されてはなりません。むしろ、上流のLDPピアは、バインディング要求ラベルを満たすことができないことを知らされなければなりません。下流側から受信したホップ数が0の場合、上流の通過ホップ数も0でなければなりません。これは、実際のホップ数が不明であることを示しています。
Alternatively, the ATM-LSR MAY return the binding upstream without waiting for a binding from downstream ("independent" control, as defined in [1] and [2]). In this case, it specifies a hop count of 0 in the binding, indicating that the true hop count is unknown. The correct value for hop count will be returned later, as described below.
代替的に、ATM-LSRは（で定義されるように、「独立」制御[1]と[2]）下流から結合を待たずに上流結合を返すことができます。この場合、それは真のホップ数が不明であることを示す、結合に0のホップ数を指定します。後述のようにホップ数の正しい値は、後に返されます。
Note that an ATM-LSR, or a member of the edge set of an ATM-LSR domain, may receive multiple binding requests for the same FEC from the same ATM-LSR. It MUST generate a new binding for each request (assuming adequate resources to do so), and retain any existing binding(s). For each request received, an ATM-LSR MUST also generate a new binding request toward the next hop for the FEC.
ATM-LSR、またはATM-LSRドメインの辺集合のメンバーは、同じATM-LSRから同じFECのための複数の結合要求を受信してもよいことに留意されたいです。それは（そうするために十分なリソースを仮定して）要求ごとに新しいバインディングを生成し、既存の（S）結合を保有しなければなりません。受信した各要求のために、ATM-LSRはまた、FECのための次のホップに向かって新しいバインディング要求を生成しなければなりません。
When a routing calculation causes an ATM-LSR to change the next hop for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
ルーティング計算がFECのための次のホップを変更するためにATM-LSRを引き起こす場合、ATM-LSRは、FECに関連付けられたラベルバインディングが不要になったこと（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. In the case where an ATM-LSR receives such notification and destroys the binding, it MUST notify the next hop for the FEC that the label binding is no longer needed. If a LSR does not destroy the binding, it may re-use the binding only if it receives a request for the same FEC with the same hop count as the request that originally caused the binding to be created.
LSRは、結合特定のラベルが不要になった通知を受信すると、LSRはバインディングに関連付けられたラベルの割当てを解除し、結合を破壊する可能性があります。 ATM-LSRは、そのような通知を受信し、結合を破壊する場合には、結合ラベルが不要になったことがFECのための次のホップに通知しなければなりません。 LSRが結合を破壊しない場合、それは最初に作成することへの結合を引き起こした要求と同じホップ数と同じFECのための要求を受信した場合にのみ、結合を再使用することができます。
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.
場合ルート変更、ラベルバインディングは、経路が以前の経路から分岐ポイントから再確立されています。その点の上流のLSRは、変化に気づかない（一つの例外を除いて、以下に記載されます）。
Whenever a LSR changes its next hop for a particular FEC, if the new next hop is reachable via an LC-ATM interface, then for each label that it has bound to that FEC, and distributed upstream, it MUST request a new label binding from the new next hop.
LSRは、新しい次のホップがLC-ATMインタフェースを介して到達可能である場合、特定のFECのために次のホップを変更し、それはそのFECに結合し、そして上流の分散した各ラベルのために、それから結合新しいラベルを要求しなければならないときはいつでも新しい次のホップ。
When an ATM-LSR receives a label binding for a particular FEC from a downstream neighbor, it may already have provided a corresponding label binding for this FEC 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, unless the hop count is 0, it MUST 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 ATM-LSR MUST notify the upstream neighbor of the change. Each ATM-LSR in turn MUST increment the hop count and pass it upstream until it reaches the ingress Edge LSR. If at any point the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. A hop count of 0 MUST be passed upstream unchanged.
ATM-LSRは、下流ネイバーから特定のFECのための結合標識を受信した場合、それは独立した制御を使用して、または下流から新しいバインディングからであるいずれかのために、それは既に、上流隣接このFECのバインディング対応するラベルを提供していることができますルーティング変更の結果です。ホップ数が0でない限り、この場合、それは新しいバインディングからのホップ数を抽出する必要がありますし、1で、それをインクリメント。新しいホップカウントは、以前（上流ネイバーが「不明」の値が与えられた場合も含む）上流の隣人に搬送されたものと異なる場合ATM-LSRは、変化の上流の近隣に通知しなければなりません。順番に各ATM-LSRはホップカウントをインクリメントし、それが入口エッジLSRに到達するまでの上流にそれを渡す必要があります。任意の時点で、ホップ数の値がMAXHOPに等しい場合は、ATM-LSRが上流の隣人からの結合を撤回すべきです。 0のホップ数は、上流そのまま渡さなければなりません。
Whenever an ATM-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 ATM-LSR SHOULD destroy the binding created in response to the received request, and notify the requester (via LDP).
ATM-LSRは、別のラベルバインディング要求（上流）LSR、およびLSRが満たされていない次のホップへの要求を受信した結果として、その次のホップLSRへのリクエストを結合ラベルを発信するたびに、ATM-LSRは、破壊すべきです受信した要求に応答して作成され、そして（LDPを介して）要求者に通知するバインディング。
If an ATM-LSR receives a binding request containing a hop count that exceeds MAXHOP, it MUST not establish a binding, and it MUST return an error to the requester.
ATM-LSRはMAXHOPを超えるホップ数を含む結合要求を受信した場合、それは、バインディングを確立してはならず、それが要求元にエラーを返さなければなりません。
When a LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection MUST be discarded. 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が、それは別のLSRとのLDPセッションが失われたと判断した場合、次のアクションが取られます。この接続を介して学習どれバインディング情報を捨てなければなりません。ピアからラベルバインディング要求を受信した結果として作成されたラベルバインディングのために、LSRはこれらのバインディング（これらは結合に関連した割当て解除ラベル）を破壊し得ます。
An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding requests from its neighbors. That is, if it receives a request for a binding to a particular FEC and the LSR making that request is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route.
それはその隣人からの結合要求を満たす場合、ATM-LSRは、「スプリットホライズン」を使用すべきです。それは、このATM-LSRによると、特定のFECと、その要求がある行うLSRへの結合のための要求を受信した場合には、であり、そのFECのための次のホップは、そのルートのためのバインディングを返すべきではありません。
It is expected that non-merging ATM-LSRs would generally use "conservative label retention mode" [1].
非合併ATM-LSRのは、一般的に「保守的なラベル保持モード」を使用することが期待されている[1]。
Relatively minor changes are needed to accommodate ATM-LSRs which support VC-merge. The primary difference is that a VC-merge-capable ATM-LSR needs only one outgoing label per FEC, even if multiple requests for label bindings to that FEC are received from upstream neighbors.
比較的軽微な変更は、VCマージをサポートするATM-LSRのに対応するために必要とされています。主な違いは、VCマージ可能なATM-LSRはそのFECにラベルバインディングのための複数の要求は、上流ネイバーから受信しても、FECごとに1つだけ出ラベルを必要としていることです。
When a VC-merge-capable ATM-LSR receives a binding request from an upstream LSR for a certain FEC, and it does not already have an outgoing label binding for that FEC (or an outstanding request for such a label binding), it MUST issue a bind request to its next hop just as it would do if it were not merge-capable. If, however, it already has an outgoing label binding for that FEC, it does not need to issue a downstream binding request. Instead, it may simply allocate an incoming label, and return that label in a binding to the upstream requester. When packets with that label as top label are received from the requester, the top label value will be replaced with the existing outgoing label value that corresponds to the same FEC.
VC-マージ可能なATM-LSRは、特定のFECのために上流のLSRからのバインディング要求を受信し、それが既にそのFECのための結合転出ラベル（又はそのようなラベルは、結合のための未処理の要求）を有していない場合、それは必須それはマージすることができなかった場合はそれを行うのと同じように、その次のホップにバインド要求を発行します。しかし、それはすでにそのFECのために結合発信ラベルを持っている場合、それは下流のバインディング要求を発行する必要はありません。その代わりに、それは単に、着信ラベルを割り当て、上流リクエスタへの結合にそのラベルを返すことができます。トップラベルとしてそのラベルを持つパケットをリクエスタから受信されたとき、トップラベルの値が同じFECに対応する既存の転出ラベル値に置き換えることであろう。
If the ATM-LSR does not have an outgoing label binding for the FEC, but does have an outstanding request for one, it need not issue another request.
ATM-LSRはFECのためのバインディング発信ラベルを持っていませんが、いずれかの未処理の要求を持っていない場合は、別の要求を発行する必要はありません。
When sending a label binding upstream, the hop count associated with the corresponding binding from downstream MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding. However, there are two exceptions: a hop count of 0 MUST be passed upstream unchanged, and if the hop count is already at MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead MUST send an error upstream.
上流の結合ラベルを送信するとき、対応する下流からバインディングに関連付けられているホップカウントが1だけ増分されなければならない、その結果は新しいバインディングに関連付けられているホップカウントとして上流送信されます。しかし、2つの例外があります0のホップ数は、上流そのまま渡さなければならない、とホップ数がMAXHOPにすでにある場合、ATM-LSRは上流の結合を渡してはならないが、その代わりに、上流のエラーを送らなければなりません。
Note that, just like conventional ATM-LSRs and members of the edge set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a new binding every time it receives a request from upstream, since there may be switches upstream which do not support VC-merge. However, it only needs to issue a corresponding binding request downstream if it does not already have a label binding for the appropriate route.
スイッチがあるかもしれないので、ちょうど従来のATM-のLSRとATM-LSRドメインのエッジセットのメンバーと同様に、VC-マージ可能なATM-LSRは、それが上流からの要求を受信するたびに結合新たを発行しなければならないことに注意してくださいその上流にVCマージをサポートしていません。しかし、それだけで、それはすでに適切な経路に対するラベルバインディングを持っていない場合、下流の対応する結合要求を発行する必要があります。
When a change in the routing table of a VC-merge-capable ATM-LSR causes it to select a new next hop for one of its FECs, it MAY optionally 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. (The choice between conservative and liberal label retention mode [1] is an implementation option.)
VC-マージ可能なATM-LSRのルーティングテーブルの変更がそののFECのための新たな次ホップを選択することを引き起こす場合は、必要に応じて前者のネクストホップからそのルートのバインドを解除してもよいです。それはすでに新しい次のホップのために対応するバインディングを持っていない場合は、1を要求しなければなりません。 （保存的およびリベラルラベル保持モード間の選択は、[1]の実装オプションです。）
If a new binding is obtained, which contains a hop count that differs from that which was received in the old binding, then the ATM-LSR must take the new hop count, increment it by one, and notify any upstream neighbors who have label bindings for this FEC of the new value. Just as with conventional ATM-LSRs, this enables the new hop count to propagate back towards the ingress of the ATM-LSR domain. If at any point the hop count exceeds MAXHOP, then the label bindings for this route must be withdrawn from all upstream neighbors to whom a binding was previously provided. This ensures that any loops caused by routing transients will be detected and broken.
新しいバインディングが古いバインディングで受信されたものとは異なるホップ数を含む、得られた場合には、ATM-LSRは、新しいホップカウントを取るいずれかでそれをインクリメントし、ラベルバインディングを持つ任意の上流の隣人に通知しなければなりません新しい価値のこのFECのために。ただ、従来のATM-LSRのと同じように、これはバックATM-LSRドメインの侵入に対する伝播するために、新たなホップ数を可能にします。任意の時点で、ホップ数がMAXHOPを超えた場合は、このルートのラベルバインディングは、バインディングが以前に提供された人に、すべての上流の隣人から撤退しなければなりません。これは、ルーティング過渡によって引き起こされる任意のループが検出され、破壊されることを保証します。
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the encapsulation in any way.
このセクションで説明する手順は、ATM-LSRドメインの唯一のエッジLSRに影響を与えます。 ATM-LSRの自体はどのような方法でカプセル化を変更しないでください。
Labeled packets MUST be transmitted using the null encapsulation of Section 6.1 of RFC 2684 [5].
標識されたパケットは、RFC 2684のセクション6.1のヌルカプセル化を使用して送信されなければならない[5]。
Except in certain circumstances specified below, when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a "shim header" [3].
標識されたパケットは、LC-ATMインターフェイス、VPI / VCI（又はVCID）上で送信される場合、以下に示す特定の状況ではラベルスタックのトップラベルとして解釈されることを除いて、パケットは、「シムヘッダを」含まなければなりません[3]。
If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label is encoded in the VPI/VCI field. The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim.
パケットは、n個のエントリを持つラベルスタックを持っている場合、それは、n個のエントリを持つシムを運ばなければなりません。トップラベルの実際の値は、VPI / VCIフィールドに符号化されています。 （単に「プレースホルダ」のエントリである）シムの一番上のエントリのラベル値は、送信時に0に設定しなければなりません、そして受信時に無視しなければなりません。パケットの送信TTL、およびそのCoSが、それぞれシムのトップスタックエントリのTTLおよびCoSフィールドで運ばれます。
Note that if a packet has a label stack with only one entry, this requires it to have a single-entry shim (4 bytes), even though the actual label value is encoded into the VPI/VCI field. This is done to ensure that the packet always has a shim. Otherwise, there would be no way to determine whether it had one or not, i.e., no way to determine whether there are additional label stack entries.
パケットが一つだけのエントリとラベルスタックを有する場合、これは実際のラベル値がVPI / VCIフィールドに符号化されていても、単一のエントリシム（4バイト）を有するように、それを必要とすることに留意されたいです。これは、パケットは常にシムを持っていることを確認するために行われます。それ以外の場合、すなわち、それは1かを持っていたかどうかを判断する方法、追加のラベルスタックのエントリがあるかどうかを判断する方法はありません。
The only ways to eliminate this extra overhead are:
この余分なオーバーヘッドを解消する唯一の方法があります。
- through apriori knowledge that packets have only a single label (e.g., perhaps the network only supports one level of label)
- パケットが単一のラベルを持つ先験的知識を介して（例えば、おそらくネットワークのみラベルの1つのレベルをサポートします）
- by using two VCs per FEC, one for those packets which have only a single label, and one for those packets which have more than one label
- 2つのFECあたりのVC、ただ一つのラベルを持っているそれらのパケットのための1つ、および複数のラベルを持っているそれらのパケットのための1つを使用して
The second technique would require that there be some way of signalling via LDP that the VC is carrying only packets with a single label, and is not carrying a shim. When supporting VC merge, one would also have to take care not to merge a VC on which the shim is not used into a VC on which it is used, or vice versa.
第2の技術は、VCは、単一のラベルを持つパケットだけを運んで、シムを持っていないことをLDPを介したシグナル伝達のいくつかの方法があることが必要であろう。 VCマージをサポートする場合は、1にもシムは、それはその逆の使用、またはされているVCに使用されていないVCをマージしないように注意してくださいする必要があります。
While either of these techniques is permitted, it is doubtful that they have any practical utility. Note that if the shim header is not present, the outgoing TTL is carried in the TTL field of the network layer header.
これらの技術のいずれかが許可されているが、彼らがすべての実用性を持っていることは疑問です。シムヘッダが存在しない場合、発信TTLは、ネットワーク層ヘッダのTTLフィールドで搬送されることに留意されたいです。
The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in any way.
このセクションで説明する手順は、ATM-LSRドメインの唯一のエッジLSRに影響を与えます。 ATM-LSRの自体はどのような方法でTTLを変更しないでください。
The details of the TTL adjustment procedure are as follows. If a packet was received by the Edge LSR as an unlabeled packet, the "incoming TTL" comes from the IP header. (Procedures for other network layer protocols are for further study.) If a packet was received by the Edge LSR as a labeled packet, using the encapsulation specified in [3], the "incoming TTL" comes from the entry at the top of the label stack.
次のようにTTL調整手順の詳細です。パケットが非標識パケットとしてエッジLSRによって受信された場合、「受信TTL」は、IPヘッダから来ます。 （他のネットワーク層プロトコルのための手順は、今後の検討課題である。）パケットに指定されたカプセル化を使用して、標識されたパケットとしてエッジLSRによって受信された場合、[3]、「着信TTL」との上部のエントリから来ていますラベルスタック。
If a hop count has been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) the difference between the incoming TTL and the hop count. If a hop count has not been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) one less than the incoming TTL.
ホップカウントは、パケットが転送されるときには、使用される結合ラベルに関連付けられている場合、「発信TTLは」（A）0より大きなまたは着信TTLとホップ数との間の（b）の差に設定されています。ホップカウントは、パケットが転送されるときには、使用される結合ラベルに関連付けられていない場合は、「発信TTLは」（A）0より大きなまたは着信TTLよりも（b）1種以下に設定されています。
If this causes the outgoing TTL to become zero, the packet MUST NOT be transmitted as a labeled packet using the specified label. The packet can be treated in one of two ways:
これがゼロになるため、発信TTLが発生した場合、パケットは指定されたラベルを使用してラベル付きパケットとして送信してはなりません。パケットは、次のいずれかの方法で処理することができます。
- it may be treated as having expired; this may cause an ICMP message to be transmitted;
- それは有効期限が切れたものとして処理することができます。これは、ICMPメッセージが送信される可能性があり、
- the packet may be forwarded, as an unlabeled packet, with a TTL that is 1 less than the incoming TTL; such forwarding would need to be done over a non-MPLS connection.
- パケットが着信TTLより1小さいTTLと、非標識パケットとして転送することができます。そのような転送は非MPLS接続を介して行われる必要があるだろう。
Of course, if the incoming TTL is 1, only the first of these two options is applicable.
入って来るTTLが1である場合はもちろん、これらの2つのオプションの唯一の最初のを適用することが可能です。
If the packet is forwarded as a labeled packet, the outgoing TTL is carried as specified in section 9.
パケットが標識パケットとして転送された場合、発信TTLは、セクション9で指定されるように行われます。
When an Edge LSR receives a labeled packet over an LC-ATM interface, it obtains the incoming TTL from the top label stack entry of the generic encapsulation, or, if that encapsulation is not present, from the IP header.
エッジLSRは、LC-ATMインタフェースを介して標識されたパケットを受信すると、そのカプセル化IPヘッダから、存在しない場合、それは、一般的なカプセル化の上部ラベルスタックエントリから受信TTLを取得し、または。
If the packet's next hop is an ATM-LSR, the outgoing TTL is formed using the procedures described in this section. Otherwise the outgoing TTL is formed using the procedures described in [3].
パケットの次のホップがATM-LSRである場合、発信TTLは、このセクションで説明する手順を使用して形成されています。そうでなければ発信TTL [3]に記載の手順を用いて形成されています。
The procedures in this section are intended to apply only to unicast packets.
このセクションの手順は、ユニキャストパケットのみに適用することを意図しています。
Every ATM-LSR MUST implement, as a configurable option, the following procedure for detecting forwarding loops. We refer to this as the LDPV (Loop Detection via Path Vectors) procedure. This procedure does not prevent the formation of forwarding loops, but does ensure that any such loops are detected. If this option is not enabled, loops are detected by the hop count mechanism previously described. If this option is enabled, loops will be detected more quickly, but at a higher cost in overhead.
すべてのATM-LSRは、設定可能なオプションとして、転送ループを検出するため、次の手順を実行しなければなりません。私たちは、手順（パスベクトルを経由してループ検出）LDPVとしてこれを参照してください。この手順は、転送ループの形成を防止しないが、このようなループが検出されていることを確認しません。このオプションが有効になっていない場合、ループは前述のホップカウントメカニズムによって検出されています。このオプションを有効にすると、ループはより迅速に検出されたが、オーバーヘッドで高コストになります。
Suppose an LSR R sends a request for a label binding, for a particular LSP, to its next hop. Then if R does not support VC-merging, and R is configured to use the LDPV procedure:
LSR Rは、その次ホップに、特定のLSPのために、結合ラベルを要求すると仮定する。そして、Rは、VC-マージをサポートしていない、そしてRはLDPVプロシージャを使用するように設定されている場合：
- If R is sending the request because it is an ingress node for that LSP, or because it has acquired a new next hop, then R MUST include a path vector object with the request, and the path vector object MUST contain only R's own address.
- それは、そのLSPのための入口ノードであるか、またはそれは新しい次のホップを取得したので、次にRは要求にパスベクトルオブジェクトを含まなければなりません、パスベクトルオブジェクトのみR自身のアドレスが含まれなければならないので、Rが要求を送信している場合。
- If R is sending the request as a result of having received a request from an upstream LSR, then:
- Rは、次いで、上流のLSRからの要求を受信した結果として、要求を送信している場合：
* if the received request has a path vector object, R MUST add its own address to the received path vector object, and MUST pass the resulting path vector object to its next hop along with the label binding request;
*受信した要求は、パスベクトルオブジェクトを有する場合、Rは、受信したパスベクトルオブジェクトに自身のアドレスを追加しなければならない、とラベルバインディング要求と共に、その次ホップに得られたパスベクトルオブジェクトを渡す必要があります。
* if the received request does not have a path vector object, R MUST include a path vector object with the request it sends, and the path vector object MUST contain only R's own address.
*受信した要求がパスベクトルオブジェクトを持っていない場合、Rは、それが送信要求にパスベクトルオブジェクトを含まなければならない、とパスベクトルオブジェクトはR自身のアドレスを含まなければなりません。
An LSR which supports VC-merge SHOULD NOT include a path vector object in the requests that it sends to its next hop.
VCマージをサポートLSRは、その次のホップに送信するリクエストのパスベクトルオブジェクトを含めるべきではありません。
If an LSR receives a label binding request whose path vector object contains the address of the node itself, the LSR concludes that the label binding requests have traveled in a loop. The LSR MUST act as it would in the case where the hop count exceeds MAXHOP (see section 8.2).
LSRは、そのパスベクトルオブジェクトは、ノード自身のアドレスを含むラベルバインディング要求を受信した場合、LSRは、ラベルバインディング要求がループ内で移動していると結論します。 LSRは（セクション8.2を参照）、それはホップカウントがMAXHOPを超えた場合と同じように行動しなければなりません。
This procedure detects the case where the request messages loop though a sequence of non-merging ATM-LSRs.
この手順は、非マージATM-LSRの一連かかわらず要求メッセージループ場合を検出します。
As specified in section 8, there are circumstances in which an LSR R must inform its upstream neighbors, via a label binding response message, of a change in hop count for a particular LSP. If the following conditions all hold:
セクション8で指定されるように、LSR Rは、特定のLSPのためのホップ数の変化の、ラベルバインディング応答メッセージを介して、その上流の近隣に知らせる必要がある状況があります。以下の条件全てが成立した場合：
- R is configured for the LDPV procedure,
- Rは、LDPV手順のために構成されています
- R supports VC-merge,
- Rは、VCマージをサポートしています
- R is not the egress for that LSP, and
- Rは、そのLSPのための出口ではない、そして
- R is not informing its neighbors of a decrease in the hop count,
- Rは、ホップ数の減少の隣国を通知されていません、
then R MUST include a path vector object in the response message.
次いで、Rは、応答メッセージ内のパスベクトルオブジェクトを含まなければなりません。
If the change in hop count is a result of R's having been informed by its next hop, S, of a change in hop count, and the message from S to R included a path vector object, then if the above conditions hold, R MUST add itself to this object and pass the result upstream. Otherwise, if the above conditions hold, R MUST create a new object with only its own address.
ホップ数の変化は、RのRは、上記の条件が成立し、次いで場合、しなければならないホップ数の変化から、その次のホップ、Sによって通知、及びSからRへのメッセージは、パスベクトルオブジェクトが含まれた結果である場合このオブジェクトにそれ自体を追加して、上流の結果を渡します。上記の条件が保持している場合それ以外の場合は、Rは、自身のアドレスを使用して新しいオブジェクトを作成する必要があります。
If R is configured for the LDPV procedure, and R supports VC merge, then it MAY include a path vector object in any label binding response message that it sends upstream. In particular, at any time that R receives a label binding response from its next hop, if that response contains a path vector, R MAY (if configured for the LDPV procedure) send a response to its upstream neighbors, containing the path vector object formed by adding its own address to the received path vector.
RはLDPV手順のために構成され、そしてRは、VCをマージサポートしている場合、それは、それが上流の送信任意のラベルバインディング応答メッセージにパスベクトルオブジェクトを含むかもしれません。 Rが次のホップからラベルバインディング応答を受信いつでも、特に、その応答は、パスベクトルを含む場合、R MAYは（LDPV手順のために構成されている場合）に形成され、パスベクトルオブジェクトを含む、その上流の近隣に応答を送信します受信したパスベクトルに自身のアドレスを追加します。
If R does not support VC merge, it SHOULD NOT send a path vector object upstream.
Rは、VCマージをサポートしていない場合、それは上流のパスベクトルオブジェクトを送るべきではありません。
If an LSR receives a message from its next hop, with a path vector object containing its own address, then LSR MUST act as it would if it received a message with a hop count equal to MAXHOP.
LSRは、自身のアドレスを含む経路ベクトルオブジェクトと、その次のホップからのメッセージを受信した場合、それはMAXHOPに等しいホップカウントを持つメッセージを受信した場合、LSRは、それが同じように行動しなければなりません。
LSRs which are configured for the LDPV procedure SHOULD NOT store a path vector once the corresponding path vector object has been transmitted.
対応する経路ベクトルオブジェクトが送信された後LDPV手順のために構成されているのLSRは、パスベクトルを格納すべきではありません。
Note that if the ATM-LSR domain consists entirely of non-merging ATM-LSRs, path vectors need not ever be sent upstream, since any loops will be detected by means of the path vectors traveling downstream.
ATM-LSRドメインは完全にATM-LSRの非マージの構成されている場合、任意のループが下流走行ベクトルパスによって検出されるので、パスベクトルはこれまで、アップストリーム送信される必要はないことに留意されたいです。
By not sending path vectors unless the hop count increases, one avoids sending them in many situations when there is no loop. The cost is that in some situations in which there is a loop, the time to detect the loop may be lengthened.
ホップ数が増加しない限り、パスベクトルを送信しないことで、1にはループが存在しない場合に多くの状況でそれらを送信しません。コストは、ループが存在するいくつかの状況では、ループを検出する時間を長くすることができることです。
The encapsulation and procedures specified in this document do not interfere in any way with the application of authentication and/or encryption to network layer packets (such as the application of IPSEC to IP datagrams).
この文書で指定されたカプセル化および手順は、（例えばIPデータグラムにIPSECのアプリケーションなど）ネットワーク層パケットに認証および/または暗号化のアプリケーションにどのような方法で妨害しません。
The procedures described in this document do not protect against the alteration (either accidental or malicious) of MPLS labels. Such alteration could cause misforwarding.
このドキュメントで説明する手順は、MPLSラベルの変更（偶発的または悪意のいずれか）を保護することはできません。このような改変は、misforwarding引き起こす可能性があります。
The procedures described in this document do not enable a receiving LSR to authenticate the transmitting LSR.
このドキュメントで説明する手順は、送信LSRを認証するために受信LSRを有効にしないでください。
A discussion of the security considerations applicable to the label distribution mechanism can be found in [2].
ラベル分配機構に適用可能なセキュリティ問題の議論は、[2]に見出すことができます。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETFは、この文書に含まれる仕様の一部またはすべてについて記載知的財産権について通知されています。詳細については、要求された権利のオンラインリストを参照してください。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[1] Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
[1]ローゼン、E.、Viswanathanの、A.とR. Callon "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[2]アンデL.、Doolan P.、フェルドマンN.、Fredette A.とR.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[3]ローゼン、E.、Rekhter、Y.、タッパン、D.、ファリナッチ、D.、Fedorkow、G.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[4] Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification over ATM Link for LDP", RFC 3038, January 2001.
[4]永見、K.、Demizu N.、江崎H.およびP. Doolan、 "LDPのためのATMリンク上VCID通知"、RFC 3038、2001年1月。
[5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[5]グロスマン、D.、Heinanen、J.、RFC 2684 "ATMアダプテーションレイヤ5以上のマルチプロトコルカプセル化"、1999年9月。
Significant contributions to this work have been made by Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We thank Alex Conta for his comments.
この作品への重要な貢献はアンソニーAlles氏、フレッド・ベイカー、ディノファリナッチ、ガイFedorkow、アーサー・林、モルガン・リトルダンタッパンによって行われています。私たちは、彼のコメントのためにアレックスコンタに感謝します。
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ブルース・デイビーシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: bsd@cisco.com
メールアドレス：bsd@cisco.com
Paul Doolan Ennovate Networks Inc. 60 Codman Hill Rd Boxborough, MA 01719
ポールDoolan Ennovateネットワークス60 CodmanヒルRdのボックスボロー、MA 01719
EMail: pdoolan@ennovatenetworks.com
メールアドレス：pdoolan@ennovatenetworks.com
Jeremy Lawrence Cisco Systems, Inc. 99 Walker St. North Sydney, NSW, Australia
ジェレミー・ローレンスシスコシステムズ社99ウォーカーセントノースシドニー、NSW、オーストラリア
EMail: jlawrenc@cisco.com
メールアドレス：jlawrenc@cisco.com
Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
キースMcCloghrieシスコシステムズ社170タスマン・ドライブサンノゼ、CA、95134
EMail: kzm@cisco.com
メールアドレス：kzm@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークスの1194 N.マチルダアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
エリック・ローゼンシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ジョージツバメシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.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機能のための基金は現在、インターネット協会によって提供されます。