[要約] RFC 3035は、LDPとATM VCスイッチングを使用したMPLSの仕様を定義しています。このRFCの目的は、ATMネットワークでのMPLSの実装と相互運用性を向上させることです。
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
LDPおよびATM VCスイッチングを使用したMPLS
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
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は、ネットワークレイヤールーティングアルゴリズムを実行する（最初に開いた最短パス（OSPF）、中間システムから中間システム（IS-IS）など）を切り替え、データ転送はこれらのルーティングアルゴリズムの結果に基づいています。ATM固有のルーティングやアドレス指定は必要ありません。この方法で使用されるATMスイッチは、ATM-LSRS（ラベルスイッチングルーター）として知られています。
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は、ネットワークレイヤールーティングアルゴリズム（OSPF、IS-ISなどなど）を実行し、そのデータ転送はこれらのルーティングアルゴリズムの結果に基づいています。ATM固有のルーティングやアドレス指定は必要ありません。この方法で使用されるATMスイッチは、ATM-LSRSとして知られています。
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.
このドキュメントは、[1]と[2]の関連する部分を拡張および明確にします。ATM-LSRとの間でのラベルの配布に使用する手順をより詳細に指定します。1]）ネットワークレイヤールーティングアルゴリズムによって、ルートがホップバイホップベースで決定される。ここで説明するラベル分布手法は、[1]で「下流のデマンド」と呼ばれています。このラベル分布手法は、「VCマージ」ができないATM-LSR（セクション3で定義）で使用する必要があり、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 Merge」を使用します。
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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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インターフェイスを介して接続されている2つの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として動作する場合があります。たとえば、イーサネットインターフェイスを備えたATMスイッチは、LC-ATMインターフェイス間でセルを転送するときにATM-LSRとして機能する場合がありますが、イーサネットからLC-ATMインターフェイスの1つにフレームを転送するときにフレームベースの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を接続するか、ATM-LSRをフレームベースの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-Mergeは、スイッチがいくつかの入っている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）で実行されます。これにより、パケット内のラベルのサイズと配置が決定されます。
- 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-Decrement」関数を実行する機能はありません。
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コントロールコンポーネントをサポートする機能を排除しません。ラベルスイッチングと定義されたITU/ATMフォーラムの2つの制御コンポーネントは、独立して動作します。
Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the 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] 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.
ラベルスイッチングは、ラベルを転送等価クラスに関連付け、ラベル値を使用して、交換用ラベルの値を決定するなど、転送パケットを使用することで実現されます。詳細については、[1]を参照してください。ATM-LSRでは、ラベルはVPI/VCIフィールドに運ばれます。つまり、VCIフィールドのATM「仮想パス」を介して2つのATM-LSRが接続されている場合。
Labeled packets MUST be transmitted using the null encapsulation, as defined in Section 6.1 of RFC 2684 [5].
RFC 2684 [5]のセクション6.1で定義されているように、nullカプセル化を使用して、ラベル付きパケットを送信する必要があります。
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 [5]のLLC/SNAPカプセル化は、非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 [5]のセクション6.1で定義されているように、NULLカプセル化を使用するか、RFC 2684 [5]のセクション5.1で定義されているLLC/SNAPカプセル化のいずれかを使用する場合があります。
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インターフェイスに「直接接続」され、他のLSRに到達し、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.
これらの予約値を除き、リンクの2つの方向で使用される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.
2つのLSRをLC-ATMインターフェイス全体で隣接する（一部のLSP）として扱うことが役立つ場合があります。この場合、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.
これらの予約値を除き、リンクの2つの方向で使用される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を使用すると、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.
2つのLSRをLC-ATMインターフェイス全体で隣接する（一部のLSP）として扱うことが有用な場合があります。
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を使用してVCIDをFECに結合する方法を指定します。受信したパケットのトップラベルは、パケットが到着した仮想回路から（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-LSRSによる「ダウンストリームオンデマンド」ラベル分布（[1]を参照）の使用について説明します。これらのラベル分布手順は、VCマルジュをサポートしていないATM-LSRによって使用する必要があり、VC-MergeをサポートするATM-LSRによっても使用される場合があります。ただし、2つのケースでは手順が多少異なります。したがって、2つのシナリオを順番に説明します。ATM-LSRドメインのエッジセットのメンバーの動作を説明することから始めます。これらの「エッジLSR」はそれ自体がATM-LSRではなく、その動作は、ドメインにVCマージ対応LSRSが含まれているかどうかと同じです。
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インターフェイスを介して到達可能であると仮定します。Edge LSRは、LDPを使用して、次のホップからそのFECのラベルバインディングを要求します。リクエストのホップカウントフィールドは1に設定されています（ただし、次の段落を参照）。Edge LSRがラベルバインディング情報を受信すると、指定されたラベルを発信ラベルとして使用して、指定されたFECでパケットを送信するためにMPLS転送手順を使用できます。（または、[4]のVCID手法が使用されている場合、指定されたVCIDに対応するVPI/VCIを発信ラベルとして使用します。）
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.
注：Edge LSRの以前のホップがDown-on-Demandラベル分布を使用して特定のFECに対してEdge LSRからラベルを要求している場合、およびEdge LSRが以前のホップからLSPを他のLSPとマージしていない場合、および前のホップからのリクエストにHのホップカウントがある場合、Edge 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.
Edge LSRが受け取ったバインディングには、このラベルを使用するときにATM-LSRドメインを横断するためにパケットが取るホップ数を表すホップカウントが含まれている場合があります。バインディングに関連付けられたホップカウントがある場合、ATM-LSRは、パケットを送信する前に、この量だけデータパケットのTTLを調整する必要があります。いずれにせよ、送信する前にデータパケットのTTLを少なくとも1つだけ調整する必要があります。そのための手順（IPパケットの場合）は、セクション10で指定されています。パケットをカプセル化する手順は、セクション9で指定されています。
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.
ルーティング計算により、Edge LSRが特定のFECの次のホップを変更し、前の次のホップがATM-LSRドメインにある場合、Edge 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のラベルバインディングリクエストを（LDP経由で）受信すると、ATM-LSRは次のアクションを実行します。
- it allocates a label,
- ラベルを割り当てます。
- it requests (via LDP) a label binding from the next hop for that FEC;
- （LDP経由で）そのFECの次のホップからバインディングを要求します。
- 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が下流から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に対して複数の結合要求を受信する場合があることに注意してください。要求ごとに新しいバインディングを生成し（適切なリソースを想定する）、既存のバインディングを保持する必要があります。受信したリクエストごとに、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.
ルーティングの計算により、ATM-LSRがFECの次のホップを変更すると、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は（1つの例外を除く、以下に記載されている）変更を忘れています。
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が特定のFECの次のホップを変更するたびに、新しい次のホップがLC-ATMインターフェイスを介して到達可能である場合、各ラベルについて、その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へのリクエストが満たされていません。受信したリクエストに応じて作成されたバインディング、および要求者に（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は、隣人からの拘束力のあるリクエストを満たす場合、「スプリットホリゾン」を使用する必要があります。つまり、特定のFECへのバインディングのリクエストを受信し、LSRがその要求を作成した場合、このATM-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に複数のリクエストが上流の近隣から受信した場合でも、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-Merge-Capable 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は新しいホップカウントを取得し、1つずつ増やし、ラベルバインディングを持っている上流の隣人に通知する必要があります新しい値のこのFECについて。従来のATM-LSRSと同様に、これにより、新しいホップカウントが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ドメインのEdge LSRSのみに影響します。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.
パケットに1つのエントリのみのラベルスタックがある場合、実際のラベル値が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)
- Packetが単一のラベルしか持っていないというAprioriの知識を通じて（たとえば、おそらくネットワークは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
- FECごとに2つのVCを使用することにより、1つのラベルしか持たないパケット用に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マージをサポートする場合、シムが使用されている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ドメインのEdge LSRSのみに影響します。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ヘッダーから供給されます。（他のネットワークレイヤープロトコルの手順はさらなる研究用です。）[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または（b）の違いとホップカウントの差の大きい方に設定されます。ホップカウントがパケットの転送時に使用されるラベルバインディングに関連付けられていない場合、「発信TTL」は、（a）0または（b）が着信TTLよりも大きい方に設定されます。
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がゼロになる場合、指定されたラベルを使用してパケットをラベル付きパケットとして送信する必要はありません。パケットは、2つの方法のいずれかで扱うことができます。
- 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.
Edge LSRがLC-ATMインターフェイス上でラベル付きパケットを受信すると、ジェネリックカプセル化のトップレーベルスタックエントリから受信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が形成されます。それ以外の場合、[3]で説明されている手順を使用して、発信TTLが形成されます。
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（Path Vectors経由のループ検出）手順と呼びます。この手順は、転送ループの形成を妨げるものではありませんが、そのようなループが検出されることを保証します。このオプションが有効になっていない場合、ループは前述のホップカウントメカニズムによって検出されます。このオプションが有効になっている場合、ループはより迅速に検出されますが、オーバーヘッドのコストが高くなります。
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.
- RがそのLSPのイングレスノードであるか、新しい次のホップを取得したためにRがリクエストを送信している場合、Rはリクエストにパスベクトルオブジェクトを含める必要があり、パスベクトルオブジェクトにはRのアドレスのみを含める必要があります。
- If R is sending the request as a result of having received a request from an upstream LSR, then:
- 上流のLSRからリクエストを受け取った結果、Rがリクエストを送信している場合、次のとおりです。
* 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-Mergeをサポートする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は、ホップカウントがMaxhopを超える場合のように行動する必要があります（セクション8.2を参照）。
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が次のホップS、ホップカウントの変更によって通知された結果であり、SからRへのメッセージにパスベクトルオブジェクトが含まれている場合、上記の条件が保持される場合、Rは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（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が次のホップから、独自のアドレスを含むパスベクトルオブジェクトを使用してメッセージを受信した場合、LSRは、Maxhopに等しいホップカウントのメッセージを受信した場合に行動する必要があります。
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.
ホップカウントが増加しない限り、パスベクトルを送信しないことにより、ループがない場合に多くの状況で送信することを避けます。コストは、ループがある状況では、ループを検出する時間が長くなる可能性があることです。
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).
このドキュメントで指定されたカプセル化と手順は、ネットワークレイヤーパケット（IPSECへのIPデータグラムへのアプリケーションなど）への認証および/または暗号化の適用をいかなる方法でも妨害しません。
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ラベルの変更（偶発的または悪意のある）から保護しません。このような変化は、誤った方向転換を引き起こす可能性があります。
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] Rosen、E.、Viswanathan、A。、およびR. Callon "Multi-Protocol Label Switching Architecture"、RFC 3031、2001年1月。
[2] Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.
[2] Andersson L.、Doolan P.、Feldman N.、Fredette A.、R。Thomas、「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] Rosen、E.、Rekhter、Y.、Tappan、D.、Farinacci、D.、Fedorkow、G.、Li、T。およびA. Conta、「Mpls Label Stack Encoding」、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] Nagami、K.、Demizu N.、Esaki 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] Grossman、D.、Heinanen、J。、「ATM適応層5に対するマルチプロトコルカプセル化」、RFC 2684、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.
この作品への多大な貢献は、アンソニー・アレンス、フレッド・ベイカー、ディノ・ファリナッチ、ガイ・フェドルコウ、アーサー・リン、モーガン・リトルウッド、ダン・タッパンによって行われました。彼のコメントをしてくれたAlex Contaに感謝します。
Bruce Davie Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
ブルース・デイビー・シスコ・システムズ、250アポロ・ドライブ・チェルムスフォード、マサチューセッツ州、01824
EMail: bsd@cisco.com
Paul Doolan Ennovate Networks Inc. 60 Codman Hill Rd Boxborough, MA 01719
Paul Doolan Envate Networks Inc. 60 Codman Hill Rd Boxborough、MA 01719
EMail: pdoolan@ennovatenetworks.com
Jeremy Lawrence
Cisco Systems, Inc.
99 Walker St.
North Sydney, NSW, Australia
EMail: jlawrenc@cisco.com
Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134
Keith McCloghrie Cisco Systems、Inc。170 Tasman Drive San Jose、CA、95134
EMail: kzm@cisco.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale、CA 94089
EMail: yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric Rosen Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA、01824
EMail: erosen@cisco.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
George Swallow Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA、01824
EMail: swallow@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。