[要約] RFC 3031は、Multiprotocol Label Switching（MPLS）アーキテクチャに関する標準化ドキュメントであり、MPLSの目的は、高速かつ効率的なパケット転送を実現するために、パケットにラベルを付けて経路制御を行うことです。
Network Working Group E. Rosen
Request for Comments: 3031 Cisco Systems, Inc.
Category: Standards Track A. Viswanathan
Force10 Networks, Inc.
R. Callon
Juniper Networks, Inc.
January 2001
Multiprotocol Label Switching Architecture
マルチプロトコルラベルスイッチングアーキテクチャ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。全著作権所有。
Abstract
概要
This document specifies the architecture for Multiprotocol Label Switching (MPLS).
このドキュメントは、マルチプロトコルラベルスイッチング（MPLS）のアーキテクチャを指定します。
Table of Contents
目次
1 Specification ...................................... 3
2 Introduction to MPLS ............................... 3
2.1 Overview ........................................... 4
2.2 Terminology ........................................ 6
2.3 Acronyms and Abbreviations ......................... 9
2.4 Acknowledgments .................................... 9
3 MPLS Basics ........................................ 9
3.1 Labels ............................................. 9
3.2 Upstream and Downstream LSRs ....................... 10
3.3 Labeled Packet ..................................... 11
3.4 Label Assignment and Distribution .................. 11
3.5 Attributes of a Label Binding ...................... 11
3.6 Label Distribution Protocols ....................... 11
3.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12
3.8 Label Retention Mode ............................... 12
3.9 The Label Stack .................................... 13
3.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 13
3.11 Incoming Label Map (ILM) ........................... 14
3.12 FEC-to-NHLFE Map (FTN) ............................. 14
3.13 Label Swapping ..................................... 15
3.14 Scope and Uniqueness of Labels ..................... 15
3.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 16
3.16 Penultimate Hop Popping ............................ 18
3.17 LSP Next Hop ....................................... 20
3.18 Invalid Incoming Labels ............................ 20
3.19 LSP Control: Ordered versus Independent ............ 20
3.20 Aggregation ........................................ 21
3.21 Route Selection .................................... 23
3.22 Lack of Outgoing Label ............................. 24
3.23 Time-to-Live (TTL) ................................. 24
3.24 Loop Control ....................................... 25
3.25 Label Encodings .................................... 26
3.25.1 MPLS-specific Hardware and/or Software ............. 26
3.25.2 ATM Switches as LSRs ............................... 26
3.25.3 Interoperability among Encoding Techniques ......... 28
3.26 Label Merging ...................................... 28
3.26.1 Non-merging LSRs ................................... 29
3.26.2 Labels for Merging and Non-Merging LSRs ............ 30
3.26.3 Merge over ATM ..................................... 31
3.26.3.1 Methods of Eliminating Cell Interleave ............. 31
3.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 31
3.27 Tunnels and Hierarchy .............................. 32
3.27.1 Hop-by-Hop Routed Tunnel ........................... 32
3.27.2 Explicitly Routed Tunnel ........................... 33
3.27.3 LSP Tunnels ........................................ 33
3.27.4 Hierarchy: LSP Tunnels within LSPs ................. 33
3.27.5 Label Distribution Peering and Hierarchy ........... 34
3.28 Label Distribution Protocol Transport .............. 35
3.29 Why More than one Label Distribution Protocol? ..... 36
3.29.1 BGP and LDP ........................................ 36
3.29.2 Labels for RSVP Flowspecs .......................... 36
3.29.3 Labels for Explicitly Routed LSPs .................. 36
3.30 Multicast .......................................... 37
4 Some Applications of MPLS .......................... 37
4.1 MPLS and Hop by Hop Routed Traffic ................. 37
4.1.1 Labels for Address Prefixes ........................ 37
4.1.2 Distributing Labels for Address Prefixes ........... 37
4.1.2.1 Label Distribution Peers for an Address Prefix ..... 37
4.1.2.2 Distributing Labels ................................ 38
4.1.3 Using the Hop by Hop path as the LSP ............... 39
4.1.4 LSP Egress and LSP Proxy Egress .................... 39
4.1.5 The Implicit NULL Label ............................ 40
4.1.6 Option: Egress-Targeted Label Assignment ........... 40
4.2 MPLS and Explicitly Routed LSPs .................... 42
4.2.1 Explicitly Routed LSP Tunnels ...................... 42
4.3 Label Stacks and Implicit Peering .................. 43
4.4 MPLS and Multi-Path Routing ........................ 44
4.5 LSP Trees as Multipoint-to-Point Entities .......... 44
4.6 LSP Tunneling between BGP Border Routers ........... 45
4.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 47
4.8 MPLS and Multicast ................................. 47
5 Label Distribution Procedures (Hop-by-Hop) ......... 47
5.1 The Procedures for Advertising and Using labels .... 48
5.1.1 Downstream LSR: Distribution Procedure ............. 48
5.1.1.1 PushUnconditional .................................. 49
5.1.1.2 PushConditional .................................... 49
5.1.1.3 PulledUnconditional ................................ 49
5.1.1.4 PulledConditional .................................. 50
5.1.2 Upstream LSR: Request Procedure .................... 51
5.1.2.1 RequestNever ....................................... 51
5.1.2.2 RequestWhenNeeded .................................. 51
5.1.2.3 RequestOnRequest ................................... 51
5.1.3 Upstream LSR: NotAvailable Procedure ............... 52
5.1.3.1 RequestRetry ....................................... 52
5.1.3.2 RequestNoRetry ..................................... 52
5.1.4 Upstream LSR: Release Procedure .................... 52
5.1.4.1 ReleaseOnChange .................................... 52
5.1.4.2 NoReleaseOnChange .................................. 53
5.1.5 Upstream LSR: labelUse Procedure ................... 53
5.1.5.1 UseImmediate ....................................... 53
5.1.5.2 UseIfLoopNotDetected ............................... 53
5.1.6 Downstream LSR: Withdraw Procedure ................. 53
5.2 MPLS Schemes: Supported Combinations of Procedures . 54
5.2.1 Schemes for LSRs that Support Label Merging ........ 55
5.2.2 Schemes for LSRs that do not Support Label Merging . 56
5.2.3 Interoperability Considerations .................... 57
6 Security Considerations ............................ 58
7 Intellectual Property .............................. 58
8 Authors' Addresses ................................. 59
9 References ......................................... 59
10 Full Copyright Statement ........................... 61
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で説明されていると解釈されます。
This document specifies the architecture for Multiprotocol Label Switching (MPLS).
このドキュメントは、マルチプロトコルラベルスイッチング（MPLS）のアーキテクチャを指定します。
Note that the use of MPLS for multicast is left for further study.
マルチキャストへのMPLSの使用は、さらなる研究のために残されていることに注意してください。
As a packet of a connectionless network layer protocol travels from one router to the next, each router makes an independent forwarding decision for that packet. That is, each router analyzes the packet's header, and each router runs a network layer routing algorithm. Each router independently chooses a next hop for the packet, based on its analysis of the packet's header and the results of running the routing algorithm.
コネクションレスネットワークレイヤープロトコルのパケットがあるルーターから次のルーターに移動すると、各ルーターはそのパケットの独立した転送決定を行います。つまり、各ルーターはパケットのヘッダーを分析し、各ルーターはネットワークレイヤールーティングアルゴリズムを実行します。各ルーターは、パケットのヘッダーの分析とルーティングアルゴリズムの実行結果に基づいて、パケットの次のホップを独立して選択します。
Packet headers contain considerably more information than is needed simply to choose the next hop. Choosing the next hop can therefore be thought of as the composition of two functions. The first function partitions the entire set of possible packets into a set of "Forwarding Equivalence Classes (FECs)". The second maps each FEC to a next hop. Insofar as the forwarding decision is concerned, different packets which get mapped into the same FEC are indistinguishable. All packets which belong to a particular FEC and which travel from a particular node will follow the same path (or if certain kinds of multi-path routing are in use, they will all follow one of a set of paths associated with the FEC).
パケットヘッダーには、単に次のホップを選択するために必要な情報よりもかなり多くの情報が含まれています。したがって、次のホップを選択することは、2つの関数の構成と考えることができます。最初の関数は、可能なパケットのセット全体を「転送等価クラス（FEC）」のセットに分割します。2番目のマップは、各FECを次のホップにマッピングします。転送決定が関係する限り、同じFECにマッピングされる異なるパケットは区別できません。特定のFECに属し、特定のノードから移動するすべてのパケットは同じパスをたどります（または、特定の種類のマルチパスルーティングが使用されている場合、それらはすべてFECに関連付けられたパスのセットの1つに従います）。
In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn reexamines the packet and assigns it to a FEC.
従来のIP転送では、特定のルーターは通常、xが各パケットの宛先アドレスの「最も長い一致」であるというルーターのルーティングテーブルにいくつかのアドレスプレフィックスxがある場合、2つのパケットが同じFECにあると考慮します。パケットがネットワークを横断すると、各ホップがパケットを再検討し、FECに割り当てます。
In MPLS, the assignment of a particular packet to a particular FEC is done just once, as the packet enters the network. The FEC to which the packet is assigned is encoded as a short fixed length value known as a "label". When a packet is forwarded to its next hop, the label is sent along with it; that is, the packets are "labeled" before they are forwarded.
MPLSでは、パケットがネットワークに入ると、特定のFECへの特定のパケットの割り当てが一度だけ行われます。パケットが割り当てられるFECは、「ラベル」として知られる短い固定長値としてエンコードされます。パケットが次のホップに転送されると、ラベルはそれとともに送信されます。つまり、パケットは転送される前に「ラベル付け」されます。
At subsequent hops, there is no further analysis of the packet's network layer header. Rather, the label is used as an index into a table which specifies the next hop, and a new label. The old label is replaced with the new label, and the packet is forwarded to its next hop.
その後のホップでは、パケットのネットワークレイヤーヘッダーのそれ以上の分析はありません。むしろ、ラベルは、次のホップと新しいラベルを指定するテーブルへのインデックスとして使用されます。古いラベルは新しいラベルに置き換えられ、パケットは次のホップに転送されます。
In the MPLS forwarding paradigm, once a packet is assigned to a FEC, no further header analysis is done by subsequent routers; all forwarding is driven by the labels. This has a number of advantages over conventional network layer forwarding.
MPLS転送パラダイムでは、パケットがFECに割り当てられたら、後続のルーターによってさらにヘッダー分析は行われません。すべての転送はラベルによって駆動されます。これには、従来のネットワークレイヤー転送よりも多くの利点があります。
- MPLS forwarding can be done by switches which are capable of doing label lookup and replacement, but are either not capable of analyzing the network layer headers, or are not capable of analyzing the network layer headers at adequate speed.
- MPLS転送は、ラベルのルックアップと交換を行うことができるが、ネットワークレイヤーヘッダーを分析できないか、適切な速度でネットワークレイヤーヘッダーを分析することができないスイッチで実行できます。
- Since a packet is assigned to a FEC when it enters the network, the ingress router may use, in determining the assignment, any information it has about the packet, even if that information cannot be gleaned from the network layer header. For example, packets arriving on different ports may be assigned to different FECs. Conventional forwarding, on the other hand, can only consider information which travels with the packet in the packet header.
- ネットワークに入るとパケットがFECに割り当てられるため、イングレスルーターは、ネットワークレイヤーヘッダーから情報を収集できなくても、割り当てを決定する際にパケットに関する情報を決定する際に使用する場合があります。たとえば、異なるポートに到着するパケットは、異なるFECに割り当てられる場合があります。一方、従来の転送は、パケットヘッダーのパケットを使用して移動する情報のみを考慮することができます。
- A packet that enters the network at a particular router can be labeled differently than the same packet entering the network at a different router, and as a result forwarding decisions that depend on the ingress router can be easily made. This cannot be done with conventional forwarding, since the identity of a packet's ingress router does not travel with the packet.
- 特定のルーターでネットワークに入るパケットは、別のルーターでネットワークに入るのと同じパケットとは異なるラベルを付けることができ、その結果、イングレスルーターに依存する転送決定を簡単に作成できます。これは、パケットのイングレスルーターの身元がパケットと一緒に移動しないため、従来の転送ではできません。
- The considerations that determine how a packet is assigned to a FEC can become ever more and more complicated, without any impact at all on the routers that merely forward labeled packets.
- パケットがFECに割り当てられている方法を決定する考慮事項は、単にラベル付きパケットを転送するルーターにまったく影響を与えることなく、ますます複雑になる可能性があります。
- Sometimes it is desirable to force a packet to follow a particular route which is explicitly chosen at or before the time the packet enters the network, rather than being chosen by the normal dynamic routing algorithm as the packet travels through the network. This may be done as a matter of policy, or to support traffic engineering. In conventional forwarding, this requires the packet to carry an encoding of its route along with it ("source routing"). In MPLS, a label can be used to represent the route, so that the identity of the explicit route need not be carried with the packet.
- パケットがネットワークを介して移動するときに通常の動的ルーティングアルゴリズムによって選択されるのではなく、パケットがネットワークに入る前に明示的に選択される特定のルートを強制することが望ましい場合があります。これは、ポリシーの問題として、または交通工学をサポートするために行うことができます。従来の転送では、これにはパケットがルートとともにエンコードを搭載する必要があります（「ソースルーティング」）。MPLSでは、ラベルを使用してルートを表すことができるため、明示的なルートのIDをパケットで運ぶ必要はありません。
Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.
一部のルーターは、パケットの次のホップを選択するだけでなく、パケットの「優先順位」または「サービスのクラス」を決定するためだけでなく、パケットのネットワークレイヤーヘッダーを分析します。その後、さまざまな破棄のしきい値を適用したり、分野のスケジューリを異なるパケットに適用したりできます。MPLSを使用すると、優先順位またはサービスのクラスをラベルから完全または部分的に推測することができます（必要ありません）。この場合、ラベルはFECと優先順位またはサービスの組み合わせを表していると言うことができます。
MPLS stands for "Multiprotocol" Label Switching, multiprotocol because its techniques are applicable to ANY network layer protocol. In this document, however, we focus on the use of IP as the network layer protocol.
MPLSは、「マルチプロトコル」ラベルスイッチング、マルチプロトコルの略です。なぜなら、その手法は任意のネットワークレイヤープロトコルに適用できるためです。ただし、このドキュメントでは、ネットワークレイヤープロトコルとしてのIPの使用に焦点を当てています。
A router which supports MPLS is known as a "Label Switching Router", or LSR.
MPLSをサポートするルーターは、「ラベルスイッチングルーター」またはLSRとして知られています。
This section gives a general conceptual overview of the terms used in this document. Some of these terms are more precisely defined in later sections of the document.
このセクションでは、このドキュメントで使用されている用語の一般的な概念的概要を説明します。これらの用語の一部は、ドキュメントの後のセクションでより正確に定義されています。
DLCI a label used in Frame Relay networks to identify frame relay circuits
dlciフレームリレーネットワークで使用されるラベルフレームリレー回路を識別するために
forwarding equivalence class a group of IP packets which are forwarded in the same manner (e.g., over the same path, with the same forwarding treatment)
同じ方法で転送されるIPパケットのクラスAグループのクラスAグループ（たとえば、同じパスで、同じ転送処理で）
frame merge label merging, when it is applied to operation over frame based media, so that the potential problem of cell interleave is not an issue.
フレームベースのメディアを介した動作に適用される場合、フレームマージラベルのマージで、セルインターリーブの潜在的な問題は問題ではありません。
label a short fixed length physically contiguous identifier which is used to identify a FEC, usually of local significance.
通常、局所的な重要性のFECを識別するために使用される短い固定長い物理的に隣接する識別子にラベルを付けます。
label merging the replacement of multiple incoming labels for a particular FEC with a single outgoing label
特定のFECの複数の着信ラベルの交換を単一の発信ラベルとマージするラベル
label swap the basic forwarding operation consisting of looking up an incoming label to determine the outgoing label, encapsulation, port, and other data handling information.
ラベルスワップ入りラベルを検索して、発信ラベル、カプセル化、ポート、およびその他のデータ処理情報を決定することで構成される基本的な転送操作を交換します。
label swapping a forwarding paradigm allowing streamlined forwarding of data by using labels to identify classes of data packets which are treated indistinguishably when forwarding.
ラベルの転送パラダイムを交換して、ラベルを使用して、転送時に見分けがつかないと扱われるデータパケットのクラスを識別することにより、データの合理化された転送を可能にします。
label switched hop the hop between two MPLS nodes, on which forwarding is done using labels.
ラベルスイッチホップ2つのMPLSノード間のホップをホップし、その上でラベルを使用して転送が行われます。
label switched path The path through one or more LSRs at one level of the hierarchy followed by a packets in a particular FEC.
ラベルがパスを切り替えたパスは、1つ以上のLSRを階層の1つのレベルで通過し、その後特定のFECにパケットが続きます。
label switching router an MPLS node which is capable of forwarding native L3 packets
ラベルスイッチングルーターネイティブL3パケットを転送できるMPLSノード
layer 2 the protocol layer under layer 3 (which therefore offers the services used by layer 3). Forwarding, when done by the swapping of short fixed length labels, occurs at layer 2 regardless of whether the label being examined is an ATM VPI/VCI, a frame relay DLCI, or an MPLS label.
レイヤー2レイヤー3の下のプロトコルレイヤー（したがって、レイヤー3で使用されるサービスを提供します）。転送は、短い固定長ラベルのスワッピングによって行われた場合、検査対象のラベルがATM VPI/VCI、フレームリレーDLCI、またはMPLSラベルであるかどうかに関係なく、レイヤー2で発生します。
layer 3 the protocol layer at which IP and its associated routing protocols operate link layer synonymous with layer 2
レイヤー3 IPとそれに関連するルーティングプロトコルがリンクレイヤーを動作させるプロトコルレイヤーレイヤー2と同義語
loop detection a method of dealing with loops in which loops are allowed to be set up, and data may be transmitted over the loop, but the loop is later detected
ループ検出ループをセットアップし、データをループ上に送信できるループを扱う方法。
loop prevention a method of dealing with loops in which data is never transmitted over a loop
ループ予防データがループ上に送信されないループを扱う方法
label stack an ordered set of labels
ラベルスタック注文されたラベルセット
merge point a node at which label merging is done
マージポイントラベルマージが完了するノード
MPLS domain a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain
MPLSドメインMPLSルーティングと転送を操作し、1つのルーティングまたは管理ドメインにある隣接するノードのセット
MPLS edge node an MPLS node that connects an MPLS domain with a node which is outside of the domain, either because it does not run MPLS, and/or because it is in a different domain. Note that if an LSR has a neighboring host which is not running MPLS, that that LSR is an MPLS edge node.
MPLS EDGEノードMPLSドメインをドメインの外側にあるノードに接続するMPLSノードは、MPLSを実行しないため、および/または異なるドメインにあるためです。LSRがMPLSを実行していない隣接ホストを持っている場合、そのLSRはMPLSエッジノードであることに注意してください。
MPLS egress node an MPLS edge node in its role in handling traffic as it leaves an MPLS domain
MPLS出力ノードMPLSドメインを離れるときのトラフィックの処理におけるその役割におけるMPLSエッジノード
MPLS ingress node an MPLS edge node in its role in handling traffic as it enters an MPLS domain
MPLSイングレスノードMPLSドメインに入るときのトラフィックの処理におけるその役割におけるMPLSエッジノード
MPLS label a label which is carried in a packet header, and which represents the packet's FEC
MPLSラベルパケットヘッダーで運ばれ、パケットのFECを表すラベル
MPLS node a node which is running MPLS. An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels. An MPLS node may optionally be also capable of forwarding native L3 packets.
MPLSノードMPLSを実行しているノード。MPLSノードは、MPLS制御プロトコルを認識し、1つ以上のL3ルーティングプロトコルを操作し、ラベルに基づいてパケットを転送できます。MPLSノードは、オプションでネイティブL3パケットを転送することもできます。
MultiProtocol Label Switching an IETF working group and the effort associated with the working group
IETFワーキンググループの切り替えとワーキンググループに関連する努力
network layer synonymous with layer 3
ネットワークレイヤーレイヤー3と同義
stack synonymous with label stack
ラベルスタックと同義語のスタック
switched path synonymous with label switched path
ラベルスイッチ付きパスと同義のスイッチ付きパス
virtual circuit a circuit used by a connection-oriented layer 2 technology such as ATM or Frame Relay, requiring the maintenance of state information in layer 2 switches.
仮想回路ATMやフレームリレーなどの接続指向のレイヤー2テクノロジーで使用される回路。レイヤー2スイッチの状態情報のメンテナンスが必要です。
VC merge label merging where the MPLS label is carried in the ATM VCI field (or combined VPI/VCI field), so as to allow multiple VCs to merge into one single VC
MPLSラベルがATM VCIフィールド（または組み合わせたVPI/VCIフィールド）で運ばれる場所でのVCマージラベルの合併。複数のVCが1つの単一のVCにマージできるように
VP merge label merging where the MPLS label is carried din the ATM VPI field, so as to allow multiple VPs to be merged into one single VP. In this case two cells would have the same VCI value only if they originated from the same node. This allows cells from different sources to be distinguished via the VCI.
MPLSラベルがATM VPIフィールドに運ばれる場所でのVPマージラベルの合併。複数のVPを1つのVPにマージできるようにします。この場合、2つのセルは、同じノードから発信された場合にのみ、同じVCI値を持ちます。これにより、さまざまなソースのセルをVCIを介して区別できます。
VPI/VCI a label used in ATM networks to identify circuits
VPI/VCI ATMネットワークで使用されるラベル回路を識別する
ATM Asynchronous Transfer Mode BGP Border Gateway Protocol DLCI Data Link Circuit Identifier FEC Forwarding Equivalence Class FTN FEC to NHLFE Map IGP Interior Gateway Protocol ILM Incoming Label Map IP Internet Protocol LDP Label Distribution Protocol L2 Layer 2 L3 Layer 3 LSP Label Switched Path LSR Label Switching Router MPLS MultiProtocol Label Switching NHLFE Next Hop Label Forwarding Entry SVC Switched Virtual Circuit SVP Switched Virtual Path TTL Time-To-Live VC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifier
ATM非同期転送モードBGPボーダーゲートウェイプロトコルDLCIデータリンク回路識別子識別子FEC転送等価クラスFTN FECからNHLFEマップIGPインテリアゲートウェイプロトコルILM着信ラベルマップIPインターネットプロトコルLDPラベル分布プロトコルL2レイヤー3 LSPラベルLSRラベルスイッチングスイッチングスイッチングスイッチングスイッチングルーターMPLSマルチプロトコルラベルスイッチングNHLFE次のホップラベル転送エントリSVCスイッチ付き仮想パススイッチ付き仮想パスTTLタイムトゥライブVC仮想回路VCI仮想回路識別子VPI仮想パス識別子識別子
The ideas and text in this document have been collected from a number of sources and comments received. We would like to thank Rick Boivie, Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and George Swallow for their inputs and ideas.
このドキュメントのアイデアとテキストは、受け取った多くの情報源とコメントから収集されています。リック・ボイヴィー、ポール・ドゥーラン、ナンシー・フェルドマン、ヤコフ・レクター、ヴィジェイ・スリニバサン、ジョージ・スワローの意見とアイデアに感謝します。
In this section, we introduce some of the basic concepts of MPLS and describe the general approach to be used.
このセクションでは、MPLSの基本概念のいくつかを紹介し、使用する一般的なアプローチについて説明します。
A label is a short, fixed length, locally significant identifier which is used to identify a FEC. The label which is put on a particular packet represents the Forwarding Equivalence Class to which that packet is assigned.
ラベルは、FECを識別するために使用される短い固定長の局所的に重要な識別子です。特定のパケットに置かれたラベルは、そのパケットが割り当てられる転送等価クラスを表します。
Most commonly, a packet is assigned to a FEC based (completely or partially) on its network layer destination address. However, the label is never an encoding of that address.
最も一般的には、パケットは、ネットワークレイヤーの宛先アドレスで（完全または部分的に）FECに割り当てられます。ただし、ラベルはそのアドレスのエンコードではありません。
If Ru and Rd are LSRs, they may agree that when Ru transmits a packet to Rd, Ru will label with packet with label value L if and only if the packet is a member of a particular FEC F. That is, they can agree to a "binding" between label L and FEC F for packets moving from Ru to Rd. As a result of such an agreement, L becomes Ru's "outgoing label" representing FEC F, and L becomes Rd's "incoming label" representing FEC F.
ruとrdがLSRである場合、RUがパケットをRDに送信すると、パケットが特定のFEC Fのメンバーである場合にのみ、Ruがラベル値Lでパケットをラベル付けすることに同意するかもしれません。RUからRDに移動するパケットのラベルLとFEC Fの間の「バインディング」。このような合意の結果、LはFEC Fを表すRUの「発信ラベル」になり、LはFEC Fを表すRDの「着信ラベル」になります。
Note that L does not necessarily represent FEC F for any packets other than those which are being sent from Ru to Rd. L is an arbitrary value whose binding to F is local to Ru and Rd.
Lは、RUからRDに送信されているパケット以外のパケットに対して必ずしもFEC Fを表すわけではないことに注意してください。Lは、FへのバインディングがRUおよびRDに局所的な任意の値です。
When we speak above of packets "being sent" from Ru to Rd, we do not imply either that the packet originated at Ru or that its destination is Rd. Rather, we mean to include packets which are "transit packets" at one or both of the LSRs.
RUからRDに「送信される」パケットについて上記で話すとき、パケットがRUで発生したこと、またはその目的地がRDであることを意味するものではありません。むしろ、LSRの一方または両方に「トランジットパケット」であるパケットを含めることを意味します。
Sometimes it may be difficult or even impossible for Rd to tell, of an arriving packet carrying label L, that the label L was placed in the packet by Ru, rather than by some other LSR. (This will typically be the case when Ru and Rd are not direct neighbors.) In such cases, Rd must make sure that the binding from label to FEC is one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1, while also agreeing with some other LSR Ru2 to bind L to a different FEC F2, UNLESS Rd can always tell, when it receives a packet with incoming label L, whether the label was put on the packet by Ru1 or whether it was put on by Ru2.
ラベルLが他のLSRではなく、ラベルLがRUによってパケットに配置されていることを、RDがラベルLを運ぶ到着パケットを伝えることが難しい場合もあれば、不可能な場合もあります。（これは通常、RUとRDが直接隣人ではない場合に当てはまります。）そのような場合、RDはラベルからFECへのバインディングが1対1であることを確認する必要があります。つまり、rdはrdにlをfec f1に結合するためにRu1に同意してはなりませんが、他のLSR ru2にも同意して、RDがいつでもわかりますが、着信ラベルLのパケットを受け取ったときに、LDを常に伝えることができない限り、LSをバインドしてください。ラベルは、RU1によってパケットに置かれたのか、それともRU2によって置かれたかどうか。
It is the responsibility of each LSR to ensure that it can uniquely interpret its incoming labels.
各LSRの責任は、着信ラベルを独自に解釈できるようにすることです。
Suppose Ru and Rd have agreed to bind label L to FEC F, for packets sent from Ru to Rd. Then with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR".
RUとRDがRUからRDに送られたパケットについて、ラベルLをFEC Fにバインドすることに同意したとします。次に、この結合に関して、Ruは「上流のLSR」であり、RDは「下流LSR」です。
To say that one node is upstream and one is downstream with respect to a given binding means only that a particular label represents a particular FEC in packets travelling from the upstream node to the downstream node. This is NOT meant to imply that packets in that FEC would actually be routed from the upstream node to the downstream node.
1つのノードが上流で、1つは特定のバインディングに関して下流であると言うことは、特定のラベルが上流ノードから下流ノードまで移動するパケットの特定のFECを表すことのみを意味します。これは、そのFECのパケットが実際に上流ノードから下流ノードまでルーティングされることを意味するものではありません。
A "labeled packet" is a packet into which a label has been encoded. In some cases, the label resides in an encapsulation header which exists specifically for this purpose. In other cases, the label may reside in an existing data link or network layer header, as long as there is a field which is available for that purpose. The particular encoding technique to be used must be agreed to by both the entity which encodes the label and the entity which decodes the label.
「ラベル付きパケット」は、ラベルがエンコードされたパケットです。場合によっては、ラベルはこの目的のために特別に存在するカプセル化ヘッダーに存在します。それ以外の場合、ラベルは、その目的のために利用可能なフィールドがある限り、既存のデータリンクまたはネットワークレイヤーヘッダーに存在する場合があります。使用する特定のエンコード手法は、ラベルをエンコードするエンティティとラベルを解読するエンティティの両方によって合意する必要があります。
In the MPLS architecture, the decision to bind a particular label L to a particular FEC F is made by the LSR which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding. Thus labels are "downstream-assigned", and label bindings are distributed in the "downstream to upstream" direction.
MPLSアーキテクチャでは、特定のラベルLを特定のFEC Fに結合する決定は、その結合に関して下流のLSRによって行われます。その後、下流のLSRは、上流のLSRにバインディングの通知を行います。したがって、ラベルは「ダウンストリーム割り当て」であり、ラベルバインディングは「下流から上流」方向に分布しています。
If an LSR has been designed so that it can only look up labels that fall into a certain numeric range, then it merely needs to ensure that it only binds labels that are in that range.
LSRが特定の数値範囲に分類されるラベルのみを検索できるように設計されている場合、その範囲にあるラベルのみにバインドすることを確認する必要があります。
A particular binding of label L to FEC F, distributed by Rd to Ru, may have associated "attributes". If Ru, acting as a downstream LSR, also distributes a binding of a label to FEC F, then under certain conditions, it may be required to also distribute the corresponding attribute that it received from Rd.
RDによってRUに分布したFEC FへのラベルLの特定の結合は、「属性」に関連付けられている可能性があります。下流のLSRとして機能するRuが、FEC Fへのラベルの結合も分配する場合、特定の条件下では、RDから受け取った対応する属性も分配する必要がある場合があります。
A label distribution protocol is a set of procedures by which one LSR informs another of the label/FEC bindings it has made. Two LSRs which use a label distribution protocol to exchange label/FEC binding information are known as "label distribution peers" with respect to the binding information they exchange. If two LSRs are label distribution peers, we will speak of there being a "label distribution adjacency" between them.
ラベル分布プロトコルは、あるLSRが作成したラベル/FECバインディングの別のLSRに通知する一連の手順です。ラベル分布プロトコルを使用してラベル/FECのバインディング情報を交換する2つのLSRは、交換するバインディング情報に関して「ラベル分布ピア」として知られています。2つのLSRがラベルディストリビューションピアである場合、それらの間に「ラベル分布隣接」があることを話します。
(N.B.: two LSRs may be label distribution peers with respect to some set of bindings, but not with respect to some other set of bindings.)
（N.B。：2つのLSRは、バインディングのいくつかのセットに関してラベル分布ピアである可能性がありますが、他のバインディングに関してはそうではありません。）
The label distribution protocol also encompasses any negotiations in which two label distribution peers need to engage in order to learn of each other's MPLS capabilities.
ラベルディストリビューションプロトコルには、お互いのMPLS機能を学ぶために2つのラベル配布ピアが従事する必要がある交渉も含まれます。
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them (see, e.g., [MPLS-BGP], [MPLS-RSVP-TUNNELS]). New protocols have also been defined for the explicit purpose of distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP].
アーキテクチャは、単一のラベル分布プロトコルのみがあるとは想定していません。実際、多くの異なるラベル分布プロトコルが標準化されています。既存のプロトコルは拡張されているため、ラベル分布をピギーバックすることができます（例えば、[MPLS-BGP]、[MPLS-RSVP-Tunnels]を参照）。新しいプロトコルは、ラベルの分布の明示的な目的のために定義されています（たとえば、[MPLS-LDP]、[MPLS-CR-LDP]を参照してください。
In this document, we try to use the acronym "LDP" to refer specifically to the protocol defined in [MPLS-LDP]; when speaking of label distribution protocols in general, we try to avoid the acronym.
このドキュメントでは、[MPLS-LDP]で定義されているプロトコルを特に参照するために頭字語「LDP」を使用しようとします。一般的なラベル分布プロトコルについて話すとき、頭字語を避けようとします。
The MPLS architecture allows an LSR to explicitly request, from its next hop for a particular FEC, a label binding for that FEC. This is known as "downstream-on-demand" label distribution.
MPLSアーキテクチャにより、LSRは次のHopから特定のFEC、そのFECのラベルバインディングを明示的に要求できます。これは、「ダウンストリームオンデマンド」ラベル分布として知られています。
The MPLS architecture also allows an LSR to distribute bindings to LSRs that have not explicitly requested them. This is known as "unsolicited downstream" label distribution.
MPLSアーキテクチャにより、LSRは明示的にリクエストしていないLSRにバインディングを配布することもできます。これは、「未承諾のダウンストリーム」ラベル分布として知られています。
It is expected that some MPLS implementations will provide only downstream-on-demand label distribution, and some will provide only unsolicited downstream label distribution, and some will provide both. Which is provided may depend on the characteristics of the interfaces which are supported by a particular implementation. However, both of these label distribution techniques may be used in the same network at the same time. On any given label distribution adjacency, the upstream LSR and the downstream LSR must agree on which technique is to be used.
一部のMPLS実装は、下流オンデマンドラベル分布のみを提供し、一部のMPLSは未承諾のダウンストリームラベル分布のみを提供し、一部は両方を提供することが予想されます。提供される場合は、特定の実装によってサポートされているインターフェイスの特性に依存する場合があります。ただし、これらのラベル分布技術は両方とも同時に同じネットワークで使用できます。特定のラベル分布の隣接性では、上流のLSRと下流のLSRは、どの手法を使用するかに同意する必要があります。
An LSR Ru may receive (or have received) a label binding for a particular FEC from an LSR Rd, even though Rd is not Ru's next hop (or is no longer Ru's next hop) for that FEC.
LSR RUは、RDがそのFECに対してRUの次のホップ（またはRUの次のホップではない）ではない場合でも、LSR RDから特定のFECのラベルバインディングを受け取る（または受け取った）ことができます。
Ru then has the choice of whether to keep track of such bindings, or whether to discard such bindings. If Ru keeps track of such bindings, then it may immediately begin using the binding again if Rd eventually becomes its next hop for the FEC in question. If Ru discards such bindings, then if Rd later becomes the next hop, the binding will have to be reacquired.
Ruは、そのようなバインディングを追跡するかどうか、またはそのようなバインディングを廃棄するかどうかを選択します。Ruがこのようなバインディングを追跡している場合、RDが最終的に問題のFECの次のホップになると、すぐにバインディングを再度使用し始める可能性があります。RUがそのようなバインディングを破棄する場合、RDが後に次のホップになった場合、バインディングを再取得する必要があります。
If an LSR supports "Liberal Label Retention Mode", it maintains the bindings between a label and a FEC which are received from LSRs which are not its next hop for that FEC. If an LSR supports "Conservative Label Retention Mode", it discards such bindings.
LSRが「リベラルラベル保持モード」をサポートする場合、そのFECの次のホップではないLSRから受信されるラベルとFECの間のバインディングを維持します。LSRが「保守的なラベル保持モード」をサポートする場合、そのようなバインディングを破棄します。
Liberal label retention mode allows for quicker adaptation to routing changes, but conservative label retention mode though requires an LSR to maintain many fewer labels.
リベラルラベル保持モードでは、ルーティングの変更をより迅速に適応させることができますが、保守的なラベル保持モードでは、LSRがより少ないラベルを維持する必要があります。
So far, we have spoken as if a labeled packet carries only a single label. As we shall see, it is useful to have a more general model in which a labeled packet carries a number of labels, organized as a last-in, first-out stack. We refer to this as a "label stack".
これまでのところ、ラベル付きパケットには単一のラベルのみが搭載されているかのように話しました。ご覧のとおり、ラベル付きパケットには、最終的な最初のスタックとして整理された多くのラベルが搭載されている、より一般的なモデルがあると便利です。これを「ラベルスタック」と呼びます。
Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present.
私たちが見るように、MPLSは階層をサポートしていますが、ラベル付きパケットの処理は階層のレベルとは完全に独立しています。処理は常にトップレーベルに基づいており、過去に他のいくつかのラベルが「それ以上」であった可能性があるか、または現在いくつかの他のラベルが現在下にある可能性がある可能性がないことに関係なく。
An unlabeled packet can be thought of as a packet whose label stack is empty (i.e., whose label stack has depth 0).
ラベルのないパケットは、ラベルスタックが空のパケットと考えることができます（つまり、ラベルスタックに深さ0）。
If a packet's label stack is of depth m, we refer to the label at the bottom of the stack as the level 1 label, to the label above it (if such exists) as the level 2 label, and to the label at the top of the stack as the level m label.
パケットのラベルスタックが深さmの場合、スタックの下部にあるラベルをレベル1ラベルと呼び、その上のラベル（そのような場合）はレベル2ラベルとして、上部のラベルを参照します。レベルmラベルとしてのスタックの。
The utility of the label stack will become clear when we introduce the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).
LSPトンネルとMPLS階層の概念を導入すると、ラベルスタックのユーティリティが明らかになります（セクション3.27）。
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding a labeled packet. It contains the following information:
「次のホップラベル転送エントリ」（NHLFE）は、ラベル付きパケットを転送するときに使用されます。次の情報が含まれています。
1. the packet's next hop
1. パケットの次のホップ
2. the operation to perform on the packet's label stack; this is one of the following operations:
2. パケットのラベルスタックで実行する操作。これは、次の操作の1つです。
a) replace the label at the top of the label stack with a specified new label
a) ラベルスタックの上部にあるラベルを指定された新しいラベルに置き換えます
b) pop the label stack
b) ラベルスタックをポップします
c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack.
c) ラベルスタックの上部にあるラベルを指定された新しいラベルに置き換え、1つ以上の指定された新しいラベルをラベルスタックに押します。
It may also contain:
また、以下を含めることもできます。
d) the data link encapsulation to use when transmitting the packet
d) パケットを送信するときに使用するデータリンクカプセル化
e) the way to encode the label stack when transmitting the packet
e) パケットを送信するときにラベルスタックをエンコードする方法
f) any other information needed in order to properly dispose of the packet.
f) パケットを適切に処分するために必要なその他の情報。
Note that at a given LSR, the packet's "next hop" might be that LSR itself. In this case, the LSR would need to pop the top level label, and then "forward" the resulting packet to itself. It would then make another forwarding decision, based on what remains after the label stacked is popped. This may still be a labeled packet, or it may be the native IP packet.
特定のLSRでは、パケットの「次のホップ」がLSR自体になる可能性があることに注意してください。この場合、LSRはトップレベルのラベルをポップし、結果のパケット自体を「転送」する必要があります。その後、ラベルが積み上げられた後に残っているものに基づいて、別の転送決定を下します。これはまだラベル付きパケットであるか、ネイティブIPパケットである可能性があります。
This implies that in some cases the LSR may need to operate on the IP header in order to forward the packet.
これは、場合によっては、LSRがパケットを転送するためにIPヘッダーで操作する必要があることを意味します。
If the packet's "next hop" is the current LSR, then the label stack operation MUST be to "pop the stack".
パケットの「次のホップ」が現在のLSRである場合、ラベルスタック操作は「スタックをポップ」する必要があります。
The "Incoming Label Map" (ILM) maps each incoming label to a set of NHLFEs. It is used when forwarding packets that arrive as labeled packets.
「着信ラベルマップ」（ILM）は、各着信ラベルをNHLFEのセットにマッピングします。ラベル付きパケットとして到着するパケットを転送するときに使用されます。
If the ILM maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
ILMが特定のラベルを複数の要素を含むNHLFEのセットにマッピングする場合、パケットが転送される前に、セットの正確な1つの要素を選択する必要があります。セットから要素を選択する手順は、このドキュメントの範囲を超えています。ILMを複数のNHLFEを含むセットにILMマップにマップすると、たとえば、複数の等しいコストパスでロードバランスを実行することが望まれる場合、有用になる場合があります。
The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded.
「FEC-to-NHLFE」（FTN）は、各FECをNHLFEのセットにマッピングします。これは、ラベルなしで到着するが、転送される前にラベル付けされるパケットを転送するときに使用されます。
If the FTN maps a particular label to a set of NHLFEs that contains more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the FTN map a label to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths.
FTNが特定のラベルを複数の要素を含むNHLFEのセットにマッピングする場合、パケットが転送される前に、セットの正確な1つの要素を選択する必要があります。セットから要素を選択する手順は、このドキュメントの範囲を超えています。FTNマップを複数のNHLFEを含むセットにラベルをマップすることは、たとえば複数の等しいコストパスで負荷分散を行うことが望まれる場合に役立つ場合があります。
Label swapping is the use of the following procedures to forward a packet.
ラベルスワッピングは、パケットを転送するための次の手順を使用しています。
In order to forward a labeled packet, a LSR examines the label at the top of the label stack. It uses the ILM to map this label to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. It then encodes the new label stack into the packet, and forwards the result.
ラベル付きパケットを転送するために、LSRはラベルスタックの上部にラベルを調べます。ILMを使用して、このラベルをNHLFEにマッピングします。NHLFEの情報を使用して、パケットを転送する場所を決定し、パケットのラベルスタックで操作を実行します。次に、新しいラベルスタックをパケットにエンコードし、結果を転送します。
In order to forward an unlabeled packet, a LSR analyzes the network layer header, to determine the packet's FEC. It then uses the FTN to map this to an NHLFE. Using the information in the NHLFE, it determines where to forward the packet, and performs an operation on the packet's label stack. (Popping the label stack would, of course, be illegal in this case.) It then encodes the new label stack into the packet, and forwards the result.
ラベルのないパケットを転送するために、LSRはネットワークレイヤーヘッダーを分析し、パケットのFECを決定します。次に、FTNを使用してこれをNHLFEにマッピングします。NHLFEの情報を使用して、パケットを転送する場所を決定し、パケットのラベルスタックで操作を実行します。（もちろん、ラベルスタックをポップすると、この場合は違法になります。）次に、新しいラベルスタックをパケットにエンコードし、結果を転送します。
IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE.
ラベルスワッピングが使用されている場合、次のホップは常にNHLFEから取得されることに注意することが重要です。これは、MPLSが使用されていない場合に次のホップとは異なる場合があります。
A given LSR Rd may bind label L1 to FEC F, and distribute that binding to label distribution peer Ru1. Rd may also bind label L2 to FEC F, and distribute that binding to label distribution peer Ru2. Whether or not L1 == L2 is not determined by the architecture; this is a local matter.
与えられたLSR RDは、ラベルL1をFEC Fにバインドし、そのバインディングをラベル分布PEER RU1に分布させることができます。RDは、ラベルL2をFEC Fにバインドし、そのバインディングをラベル分布PEER RU2に分配することもできます。L1 == L2がアーキテクチャによって決定されないかどうか。これは地元の問題です。
A given LSR Rd may bind label L to FEC F1, and distribute that binding to label distribution peer Ru1. Rd may also bind label L to FEC F2, and distribute that binding to label distribution peer Ru2. IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we may say that Rd is using a different "label space" for the labels it distributes to Ru1 than for the labels it distributes to Ru2.
与えられたLSR RDは、ラベルLをFEC F1にバインドし、そのバインディングをラベル分布PEER RU1に分布させることができます。RDは、ラベルLをFEC F2にバインドし、そのバインディングをラベル分布PEER RU2に分配することもできます。RDがRU1によってラベルがそこに置かれたか、RU2によって置かれたかにかかわらず、TOPラベルがLのパケットを受信したときに、RDがわかります（および唯一の場合）、アーキテクチャはF1 == F2を必要としません。そのような場合、RDは、RU2に分布するラベルよりもRU1に分布するラベルに異なる「ラベルスペース」を使用していると言うことができます。
In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following conditions hold:
一般に、RDは、次の条件が保持されている場合、特定のラベル値Lをラベルスタックの上部に置くのはRU1またはRU2であるかどうかのみを知ることができます。
- Ru1 and Ru2 are the only label distribution peers to which Rd distributed a binding of label value L, and
- RU1とRU2は、RDがラベル値Lのバインディングを配布した唯一のラベル配布ピアであり、
- Ru1 and Ru2 are each directly connected to Rd via a point-to-point interface.
- RU1とRU2はそれぞれ、ポイントツーポイントインターフェイスを介してRDに直接接続されています。
When these conditions hold, an LSR may use labels that have "per interface" scope, i.e., which are only unique per interface. We may say that the LSR is using a "per-interface label space". When these conditions do not hold, the labels must be unique over the LSR which has assigned them, and we may say that the LSR is using a "per-platform label space."
これらの条件が当てはまる場合、LSRは「インターフェイスごと」スコープ、つまりインターフェイスごとにのみ一意のラベルを使用する場合があります。LSRは「インターフェイスごとのラベルスペース」を使用していると言えるかもしれません。これらの条件が保持されない場合、ラベルはそれらを割り当てたLSRに対して一意でなければならず、LSRは「プラットフォームごとのラベルスペース」を使用していると言えるかもしれません。
If a particular LSR Rd is attached to a particular LSR Ru over two point-to-point interfaces, then Rd may distribute to Ru a binding of label L to FEC F1, as well as a binding of label L to FEC F2, F1 != F2, if and only if each binding is valid only for packets which Ru sends to Rd over a particular one of the interfaces. In all other cases, Rd MUST NOT distribute to Ru bindings of the same label value to two different FECs.
特定のLSR RDが2つのポイントツーポイントインターフェイスで特定のLSR RUに接続されている場合、RDはFEC F1へのラベルLの結合とFEC F2、F1へのラベルLの結合にRUに分配できます！= F2、各バインディングが特定のインターフェイスの1つでRDに送信するパケットに対してのみ有効である場合にのみ。他のすべての場合、RDは同じラベル値のRUバインディングに2つの異なるFECに分配してはなりません。
This prohibition holds even if the bindings are regarded as being at different "levels of hierarchy". In MPLS, there is no notion of having a different label space for different levels of the hierarchy; when interpreting a label, the level of the label is irrelevant.
この禁止は、バインディングが異なる「階層のレベル」にあると見なされていても、保持されます。MPLSでは、階層の異なるレベルのために異なるラベルスペースを持つという概念はありません。ラベルを解釈するとき、ラベルのレベルは無関係です。
The question arises as to whether it is possible for an LSR to use multiple per-platform label spaces, or to use multiple per-interface label spaces for the same interface. This is not prohibited by the architecture. However, in such cases the LSR must have some means, not specified by the architecture, of determining, for a particular incoming label, which label space that label belongs to. For example, [MPLS-SHIM] specifies that a different label space is used for unicast packets than for multicast packets, and uses a data link layer codepoint to distinguish the two label spaces.
LSRが複数のプラットフォームごとのラベルスペースを使用できるか、同じインターフェイスに複数のインターフェイスごとのラベルスペースを使用できるかについての疑問が生じます。これはアーキテクチャによって禁止されていません。ただし、そのような場合、LSRには、ラベルが属するラベルスペースがある特定の着信ラベルに対して、建築によって指定されていないいくつかの手段が決定されなければなりません。たとえば、[MPLS-Shim]は、マルチキャストパケットとは異なるラベルスペースがユニキャストパケットに使用されていることを指定し、データリンクレイヤーコードポイントを使用して2つのラベルスペースを区別します。
A "Label Switched Path (LSP) of level m" for a particular packet P is a sequence of routers,
特定のパケットPの「レベルMのラベルスイッチパス（LSP）」は、ルーターのシーケンスであり、
<R1, ..., Rn>
<r1、...、rn>
with the following properties:
次のプロパティがあります。
1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's label stack, resulting in a label stack of depth m;
1. 「LSP Ingress」であるR1は、ラベルをPのラベルスタックに押し込むLSRであり、深さmのラベルスタックが得られます。
2. For all i, 1<i<n, P has a label stack of depth m when received by LSR Ri;
2. すべてのIについて、1 <i <n、pには、LSR RIが受信した場合、深さmのラベルスタックがあります。
3. At no time during P's transit from R1 to R[n-1] does its label stack ever have a depth of less than m;
3. PのR1からR [n-1]への通過中は、ラベルスタックがm未満の深さを持つことはありません。
4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS, i.e., by using the label at the top of the label stack (the level m label) as an index into an ILM;
4. すべてのIについて、1 <i <n：riはMPLSによってPにpにpに送信されます。つまり、ILMへのインデックスとしてラベルスタック（レベルMラベル）の上部にあるラベルを使用します。
5. For all i, 1<i<n: if a system S receives and forwards P after P is transmitted by Ri but before P is received by R[i+1] (e.g., Ri and R[i+1] might be connected via a switched data link subnetwork, and S might be one of the data link switches), then S's forwarding decision is not based on the level m label, or on the network layer header. This may be because:
5. すべてのIの場合、1 <i <n：システムがpを受信して転送した場合、pがRiによって送信された後、pがR [i 1]によって受信される前に（例えば、riおよびr [i 1]がAを介して接続される可能性があります。Switched Dataリンクサブネットワーク、およびSはデータリンクスイッチの1つである可能性があります）、Sの転送決定は、レベルMラベルまたはネットワークレイヤーヘッダーに基づいていません。これは、
a) the decision is not based on the label stack or the network layer header at all;
a) この決定は、ラベルスタックまたはネットワークレイヤーヘッダーに基づいていません。
b) the decision is based on a label stack on which additional labels have been pushed (i.e., on a level m+k label, where k>0).
b) この決定は、追加のラベルがプッシュされたラベルスタックに基づいています（つまり、レベルm kラベル、ここでk> 0）。
In other words, we can speak of the level m LSP for Packet P as the sequence of routers:
言い換えれば、パケットPのレベルM LSPについて、ルーターのシーケンスとして話すことができます。
1. which begins with an LSR (an "LSP Ingress") that pushes on a level m label,
1. これは、レベルmラベルをプッシュするLSR（「LSPイングレス」）から始まります。
2. all of whose intermediate LSRs make their forwarding decision by label Switching on a level m label,
2. 中間LSRがレベルMラベルをラベルに切り替えることにより、転送決定を下すすべてのもの、
3. which ends (at an "LSP Egress") when a forwarding decision is made by label Switching on a level m-k label, where k>0, or when a forwarding decision is made by "ordinary", non-MPLS forwarding procedures.
3. （「LSP Egress」で）レベルM-Kラベルのラベルスイッチをラベルに切り替えることで転送決定が下された場合、またはk> 0で、または「通常」の転送による転送決定が行われる場合、非MPLS転送手順が終了します。
A consequence (or perhaps a presupposition) of this is that whenever an LSR pushes a label onto an already labeled packet, it needs to make sure that the new label corresponds to a FEC whose LSP Egress is the LSR that assigned the label which is now second in the stack.
これの結果（またはおそらく前提）は、LSRがラベルを既にラベルの付いたパケットに押し込むときはいつでも、新しいラベルがLSP Egressが現在のラベルを割り当てたLSRであるFECに対応することを確認する必要があることです。スタックで2番目。
We will call a sequence of LSRs the "LSP for a particular FEC F" if it is an LSP of level m for a particular packet P when P's level m label is a label corresponding to FEC F.
PのレベルMラベルがFEC Fに対応するラベルである場合、特定のパケットPのレベルMのLSPである場合、LSRSのシーケンスを「特定のFEC FのLSP」と呼びます。
Consider the set of nodes which may be LSP ingress nodes for FEC F. Then there is an LSP for FEC F which begins with each of those nodes. If a number of those LSPs have the same LSP egress, then one can consider the set of such LSPs to be a tree, whose root is the LSP egress. (Since data travels along this tree towards the root, this may be called a multipoint-to-point tree.) We can thus speak of the "LSP tree" for a particular FEC F.
FEC FのLSPイングレスノードである可能性のあるノードのセットを考慮してください。次に、それらの各ノードから始まるFEC FのLSPがあります。これらのLSPの多くが同じLSP出力を持っている場合、そのようなLSPのセットがルートがLSP出力であるツリーであると考えることができます。（データはこのツリーに沿ってルートに向かって移動するため、これはマルチポイントツーポイントツリーと呼ばれる場合があります。）したがって、特定のFEC Fの「LSPツリー」について話すことができます。
Note that according to the definitions of section 3.15, if <R1, ..., Rn> is a level m LSP for packet P, P may be transmitted from R[n-1] to Rn with a label stack of depth m-1. That is, the label stack may be popped at the penultimate LSR of the LSP, rather than at the LSP Egress.
セクション3.15の定義によれば、<r1、...、rn>がパケットpのレベルm lspである場合、pはr [n-1]からrnにrnに送信される場合があります。1。つまり、ラベルスタックは、LSPの出口ではなく、LSPの最後から2番目のLSRにポップされる場合があります。
From an architectural perspective, this is perfectly appropriate. The purpose of the level m label is to get the packet to Rn. Once R[n-1] has decided to send the packet to Rn, the label no longer has any function, and need no longer be carried.
建築の観点から見ると、これは完全に適切です。レベルMラベルの目的は、パケットをRNに導入することです。R [n-1]がパケットをRNに送信することを決定すると、ラベルには機能がなく、運ばれる必要がなくなります。
There is also a practical advantage to doing penultimate hop popping. If one does not do this, then when the LSP egress receives a packet, it first looks up the top label, and determines as a result of that lookup that it is indeed the LSP egress. Then it must pop the stack, and examine what remains of the packet. If there is another label on the stack, the egress will look this up and forward the packet based on this lookup. (In this case, the egress for the packet's level m LSP is also an intermediate node for its level m-1 LSP.) If there is no other label on the stack, then the packet is forwarded according to its network layer destination address. Note that this would require the egress to do TWO lookups, either two label lookups or a label lookup followed by an address lookup.
また、最後から2番目のホップポップを行うことには実際的な利点があります。これを行わない場合、LSP Egressがパケットを受信すると、最初にトップレーベルを調べ、その検索の結果として実際にLSP Egressであると判断します。その後、スタックをポップし、パケットの残りを調べる必要があります。スタックに別のラベルがある場合、出口はこのルックアップに基づいてこれを調べてパケットを転送します。（この場合、パケットのレベルM LSPの出力は、レベルM-1 LSPの中間ノードでもあります。）スタックに他のラベルがない場合、パケットはネットワークレイヤーの宛先アドレスに従って転送されます。これには、2つのレーベルルックアップまたはレーベルルックアップのいずれかの2つのルックアップを行う必要があることに注意してください。
If, on the other hand, penultimate hop popping is used, then when the penultimate hop looks up the label, it determines:
一方、最後から2番目のホップポップが使用されている場合、最後から2番目のホップがラベルを調べると、次のように決定します。
- that it is the penultimate hop, and
- それが最後から2番目のホップであること、そして
- who the next hop is.
- 次のホップは誰ですか。
The penultimate node then pops the stack, and forwards the packet based on the information gained by looking up the label that was previously at the top of the stack. When the LSP egress receives the
次に、最後から2番目のノードがスタックをポップし、以前にスタックの上部にあったラベルを調べることで得られた情報に基づいてパケットを転送します。LSP出力が受信したとき
packet, the label which is now at the top of the stack will be the label which it needs to look up in order to make its own forwarding decision. Or, if the packet was only carrying a single label, the LSP egress will simply see the network layer packet, which is just what it needs to see in order to make its forwarding decision.
現在スタックの上部にあるラベルであるパケットは、独自の転送決定を行うために検索する必要があるラベルになります。または、パケットが単一のラベルのみを搭載していた場合、LSP Egressは単にネットワークレイヤーパケットを表示します。これは、転送決定を行うために必要なものです。
This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node.
この手法により、出口は単一のルックアップを行うことができ、最後から2番目のノードによる1回のルックアップのみが必要です。
The creation of the forwarding "fastpath" in a label switching product may be greatly aided if it is known that only a single lookup is ever required:
ラベルスイッチング製品の転送「FastPath」の作成は、単一のルックアップのみが必要であることがわかっている場合、大いに役立つ場合があります。
- the code may be simplified if it can assume that only a single lookup is ever needed
- コードは、単一のルックアップのみが必要であると仮定できる場合、単純化される場合があります
- the code can be based on a "time budget" that assumes that only a single lookup is ever needed.
- コードは、単一のルックアップのみが必要であると仮定する「時間予算」に基づいている場合があります。
In fact, when penultimate hop popping is done, the LSP Egress need not even be an LSR.
実際、最後から2番目のホップポップが完了した場合、LSP EgressはLSRでさえ必要ありません。
However, some hardware switching engines may not be able to pop the label stack, so this cannot be universally required. There may also be some situations in which penultimate hop popping is not desirable. Therefore the penultimate node pops the label stack only if this is specifically requested by the egress node, OR if the next node in the LSP does not support MPLS. (If the next node in the LSP does support MPLS, but does not make such a request, the penultimate node has no way of knowing that it in fact is the penultimate node.)
ただし、一部のハードウェアスイッチングエンジンがラベルスタックをポップできない場合があるため、これを普遍的に必要とすることはできません。また、最後から2番目のホップポップが望ましくない状況もあります。したがって、最後から2番目のノードは、これが出口ノードによって特異的に要求される場合、またはLSPの次のノードがMPLSをサポートしていない場合にのみ、ラベルスタックをポップします。（LSPの次のノードがMPLSをサポートしているが、そのような要求を行わない場合、最後から2番目のノードには、実際には最後から2番目のノードであることを知る方法がありません。）
An LSR which is capable of popping the label stack at all MUST do penultimate hop popping when so requested by its downstream label distribution peer.
ラベルスタックをまったくポップできるLSRは、ダウンストリームラベルディストリビューションピアから要求されたときに最後から2番目のホップをポップする必要があります。
Initial label distribution protocol negotiations MUST allow each LSR to determine whether its neighboring LSRS are capable of popping the label stack. A LSR MUST NOT request a label distribution peer to pop the label stack unless it is capable of doing so.
初期ラベル分布プロトコル交渉により、各LSRが隣接するLSRがラベルスタックをポップできるかどうかを判断できるようにする必要があります。LSRは、ラベル分布ピアを要求して、ラベルスタックをポップしてはいけません。
It may be asked whether the egress node can always interpret the top label of a received packet properly if penultimate hop popping is used. As long as the uniqueness and scoping rules of section 3.14 are obeyed, it is always possible to interpret the top label of a received packet unambiguously.
Penultimate Hop Poppingが使用されている場合、出力ノードが受信パケットのトップラベルを常に適切に解釈できるかどうかを尋ねられる場合があります。セクション3.14の独自性とスコーピングルールが従っている限り、受信したパケットのトップラベルを明確に解釈することは常に可能です。
The LSP Next Hop for a particular labeled packet in a particular LSR is the LSR which is the next hop, as selected by the NHLFE entry used for forwarding that packet.
特定のLSRの特定のラベル付きパケットの次のLSPホップは、そのパケットの転送に使用されるNHLFEエントリで選択されている次のホップであるLSRです。
The LSP Next Hop for a particular FEC is the next hop as selected by the NHLFE entry indexed by a label which corresponds to that FEC.
特定のFECの次のLSPホップは、そのFECに対応するラベルによってインデックスが付けられたNHLFEエントリによって選択された次のホップです。
Note that the LSP Next Hop may differ from the next hop which would be chosen by the network layer routing algorithm. We will use the term "L3 next hop" when we refer to the latter.
LSP Next Hopは、ネットワークレイヤールーティングアルゴリズムによって選択される次のホップとは異なる場合があることに注意してください。後者を参照すると、「L3 Next Hop」という用語を使用します。
What should an LSR do if it receives a labeled packet with a particular incoming label, but has no binding for that label? It is tempting to think that the labels can just be removed, and the packet forwarded as an unlabeled IP packet. However, in some cases, doing so could cause a loop. If the upstream LSR thinks the label is bound to an explicit route, and the downstream LSR doesn't think the label is bound to anything, and if the hop by hop routing of the unlabeled IP packet brings the packet back to the upstream LSR, then a loop is formed.
LSRは、特定の着信ラベルを備えたラベル付きパケットを受け取った場合、そのラベルにバインディングされていない場合はどうすればよいですか？ラベルを削除できるだけで、パケットがラベル付けされていないIPパケットとして転送されると考えるのは魅力的です。ただし、場合によっては、そうすることでループを引き起こす可能性があります。上流のLSRがラベルが明示的なルートにバインドされていると考え、下流のLSRはラベルが何にも拘束されていないと考え、ホップバイホップのホップルーティングがパケットをアップストリームLSRに戻した場合、次に、ループが形成されます。
It is also possible that the label was intended to represent a route which cannot be inferred from the IP header.
また、ラベルがIPヘッダーから推測できないルートを表すことを目的としている可能性もあります。
Therefore, when a labeled packet is received with an invalid incoming label, it MUST be discarded, UNLESS it is determined by some means (not within the scope of the current document) that forwarding it unlabeled cannot cause any harm.
したがって、ラベル付きのパケットが無効な受信ラベルで受信される場合、何らかの手段（現在の文書の範囲内ではなく）で決定されない限り、それを廃棄する必要があります。
Some FECs correspond to address prefixes which are distributed via a dynamic routing algorithm. The setup of the LSPs for these FECs can be done in one of two ways: Independent LSP Control or Ordered LSP Control.
一部のFECは、動的ルーティングアルゴリズムを介して分布するアドレスプレフィックスに対応しています。これらのFECのLSPのセットアップは、独立したLSP制御または順序付きLSPコントロールの2つの方法のいずれかで実行できます。
In Independent LSP Control, each LSR, upon noting that it recognizes a particular FEC, makes an independent decision to bind a label to that FEC and to distribute that binding to its label distribution peers. This corresponds to the way that conventional IP datagram routing works; each node makes an independent decision as to how to treat each packet, and relies on the routing algorithm to converge rapidly so as to ensure that each datagram is correctly delivered.
独立したLSPコントロールでは、各LSRは、特定のFECを認識していることに気づくと、そのFECにラベルをバインドし、そのバインディングをラベル分布ピアに分配するという独立した決定を下します。これは、従来のIPデータグラムルーティングが機能する方法に対応しています。各ノードは、各パケットを処理する方法について独立した決定を下し、各データグラムが正しく配信されるように、迅速に収束するルーティングアルゴリズムに依存しています。
In Ordered LSP Control, an LSR only binds a label to a particular FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next hop for that FEC.
順序付けられたLSPコントロールでは、LSRは、そのFECの出力LSRである場合、またはそのFECの次のホップからそのFECのラベルバインディングをすでに受け取っている場合、特定のFECにラベルを特定のFECにバインドします。
If one wants to ensure that traffic in a particular FEC follows a path with some specified set of properties (e.g., that the traffic does not traverse any node twice, that a specified amount of resources are available to the traffic, that the traffic follows an explicitly specified path, etc.) ordered control must be used. With independent control, some LSRs may begin label switching a traffic in the FEC before the LSP is completely set up, and thus some traffic in the FEC may follow a path which does not have the specified set of properties. Ordered control also needs to be used if the recognition of the FEC is a consequence of the setting up of the corresponding LSP.
特定のFECのトラフィックが、指定されたプロパティセットを使用してパスに従うことを保証したい場合（たとえば、トラフィックがノードを2回通過しないこと、指定された量のリソースがトラフィックに利用可能であること、トラフィックが従うことを確認します。明示的に指定されたパスなど）順序制御を使用する必要があります。独立したコントロールを使用すると、一部のLSRは、LSPが完全にセットアップされる前にFECのトラフィックをラベルスイッチするラベルを開始する可能性があるため、FECの一部のトラフィックは、指定されたプロパティセットがないパスに従う場合があります。FECの認識が対応するLSPのセットアップの結果である場合、注文制御も使用する必要があります。
Ordered LSP setup may be initiated either by the ingress or the egress.
注文されたLSPセットアップは、入り口または出口によって開始される場合があります。
Ordered control and independent control are fully interoperable. However, unless all LSRs in an LSP are using ordered control, the overall effect on network behavior is largely that of independent control, since one cannot be sure that an LSP is not used until it is fully set up.
順序付けられた制御と独立した制御は完全に相互運用可能です。ただし、LSP内のすべてのLSRが順序付けられたコントロールを使用していない限り、ネットワークの動作に対する全体的な効果は、LSPが完全にセットアップされるまで使用されないことを確信できないため、ネットワークの動作に対する全体的な効果です。
This architecture allows the choice between independent control and ordered control to be a local matter. Since the two methods interwork, a given LSR need support only one or the other. Generally speaking, the choice of independent versus ordered control does not appear to have any effect on the label distribution mechanisms which need to be defined.
このアーキテクチャにより、独立した制御と秩序制御の選択をローカルの問題にすることができます。2つの方法はインターワークであるため、特定のLSRにはどちらか一方のみをサポートする必要があります。一般的に言えば、独立対秩序化された制御の選択は、定義する必要があるラベル分布メカニズムに影響を与えないようです。
One way of partitioning traffic into FECs is to create a separate FEC for each address prefix which appears in the routing table. However, within a particular MPLS domain, this may result in a set of FECs such that all traffic in all those FECs follows the same route. For example, a set of distinct address prefixes might all have the same egress node, and label swapping might be used only to get the the traffic to the egress node. In this case, within the MPLS domain, the union of those FECs is itself a FEC. This creates a choice: should a distinct label be bound to each component FEC, or should a single label be bound to the union, and that label applied to all traffic in the union?
トラフィックをFECに分割する1つの方法は、ルーティングテーブルに表示される各アドレスプレフィックスに個別のFECを作成することです。ただし、特定のMPLSドメイン内では、これらすべてのFECのすべてのトラフィックが同じルートに従うように、これによりFECのセットが生じる可能性があります。たとえば、個別のアドレスプレフィックスのセットはすべて同じ出力ノードを持っている可能性があり、ラベルスワッピングは、Egressノードへのトラフィックを取得するためにのみ使用される場合があります。この場合、MPLSドメイン内では、それらのFECの結合自体がFECです。これにより、選択が作成されます。明確なラベルを各コンポーネントFECにバインドする必要がありますか、それとも単一のラベルを組合にバインドする必要があり、そのラベルは組合内のすべてのトラフィックに適用される必要がありますか？
The procedure of binding a single label to a union of FECs which is itself a FEC (within some domain), and of applying that label to all
単一のラベルをFECの結合に結合する手順自体がFEC（一部のドメイン内）であり、そのラベルをすべてに適用する
traffic in the union, is known as "aggregation". The MPLS architecture allows aggregation. Aggregation may reduce the number of labels which are needed to handle a particular set of packets, and may also reduce the amount of label distribution control traffic needed.
組合のトラフィックは、「集約」として知られています。MPLSアーキテクチャにより、集約が可能になります。集約は、特定のパケットセットを処理するために必要なラベルの数を減らすことができ、必要なラベル配信制御トラフィックの量を減らすこともあります。
Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (c) being the "finest granularity".
単一のFECに「集約可能」のFECのセットを考えると、（a）それらを単一のFECに集計することができ、（b）それらをFECのセットに集約すること、または（c）それらをまったく集約しないことができます。したがって、凝集の「粒度」について話すことができます。（a）「最も粗い粒度」であり、（c）「最高の粒度」であることがあります。
When order control is used, each LSR should adopt, for a given set of FECs, the granularity used by its next hop for those FECs.
注文制御を使用する場合、各LSRは、特定のFECのセットについて、次のFECの次のホップで使用される粒度を採用する必要があります。
When independent control is used, it is possible that there will be two adjacent LSRs, Ru and Rd, which aggregate some set of FECs differently.
独立したコントロールを使用すると、2つの隣接するLSR、RUとRDが存在する可能性があり、FECのセットを異なる方法で集約します。
If Ru has finer granularity than Rd, this does not cause a problem. Ru distributes more labels for that set of FECs than Rd does. This means that when Ru needs to forward labeled packets in those FECs to Rd, it may need to map n labels into m labels, where n > m. As an option, Ru may withdraw the set of n labels that it has distributed, and then distribute a set of m labels, corresponding to Rd's level of granularity. This is not necessary to ensure correct operation, but it does result in a reduction of the number of labels distributed by Ru, and Ru is not gaining any particular advantage by distributing the larger number of labels. The decision whether to do this or not is a local matter.
RUがRDよりも細かい粒度がある場合、これは問題を引き起こしません。RUは、RDよりもそのセットのFECのラベルをより多く配布しています。これは、RUがこれらのFECのラベル付きパケットをRDに転送する必要がある場合、NラベルをMラベルにマッピングする必要がある場合があることを意味します。オプションとして、Ruは、分布したNラベルのセットを撤回し、RDの粒度のレベルに対応するMラベルのセットを配布する場合があります。これは正しい操作を確保するために必要ではありませんが、RUによって分散されたラベルの数が減少し、RUはより多くのラベルを分配することで特定の利点を獲得していません。これを行うかどうかの決定は、地元の問題です。
If Ru has coarser granularity than Rd (i.e., Rd has distributed n labels for the set of FECs, while Ru has distributed m, where n > m), it has two choices:
RUがRDよりも粗い粒度がある場合（つまり、RDがFECのセットのnラベルを分布しているのに対し、Ruはm、n> mを分布しています）、2つの選択肢があります。
- It may adopt Rd's finer level of granularity. This would require it to withdraw the m labels it has distributed, and distribute n labels. This is the preferred option.
- RDのより細かいレベルの粒度を採用する可能性があります。これには、配布したMラベルを引き出し、Nラベルを配布する必要があります。これが好ましいオプションです。
- It may simply map its m labels into a subset of Rd's n labels, if it can determine that this will produce the same routing. For example, suppose that Ru applies a single label to all traffic that needs to pass through a certain egress LSR, whereas Rd binds a number of different labels to such traffic, depending on the individual destination addresses of the packets. If Ru knows the address of the egress router, and if Rd has bound a label to the FEC which is identified by that address, then Ru can simply apply that label.
- これが同じルーティングを生成すると判断できる場合、MラベルをRDのNラベルのサブセットにマッピングするだけです。たとえば、RUが特定の出力LSRを通過する必要があるすべてのトラフィックに単一のラベルを適用しているのに対し、RDはパケットの個々の宛先アドレスに応じて、そのようなトラフィックにさまざまなラベルを拘束するのに対し、仮定します。Ruが出力ルーターのアドレスを知っている場合、RDがそのアドレスで識別されるFECにラベルをバインドしている場合、Ruは単にそのラベルを適用できます。
In any event, every LSR needs to know (by configuration) what granularity to use for labels that it assigns. Where ordered control is used, this requires each node to know the granularity only for FECs which leave the MPLS network at that node. For independent control, best results may be obtained by ensuring that all LSRs are consistently configured to know the granularity for each FEC. However, in many cases this may be done by using a single level of granularity which applies to all FECs (such as "one label per IP prefix in the forwarding table", or "one label per egress node").
いずれにせよ、すべてのLSRは、それが割り当てるラベルに使用する粒度を（構成ごとに）知る必要があります。順序付けられたコントロールが使用される場合、これには各ノードがそのノードでMPLSネットワークを残すFECのみの粒度を把握する必要があります。独立した制御のために、すべてのLSRが各FECの粒度を知るように一貫して構成されていることを確認することにより、最良の結果を得ることができます。ただし、多くの場合、これはすべてのFEC（「転送テーブルのIPプレフィックスごとに1つのラベル」や「出口ノードごとに1つのラベル」など）に適用される単一レベルの粒度を使用して行うことができます。
Route selection refers to the method used for selecting the LSP for a particular FEC. The proposed MPLS protocol architecture supports two options for Route Selection: (1) hop by hop routing, and (2) explicit routing.
ルート選択とは、特定のFECのLSPを選択するために使用される方法を指します。提案されているMPLSプロトコルアーキテクチャは、ルート選択の2つのオプションをサポートしています。（1）ホップルーティングによるホップ、および（2）明示的なルーティング。
Hop by hop routing allows each node to independently choose the next hop for each FEC. This is the usual mode today in existing IP networks. A "hop by hop routed LSP" is an LSP whose route is selected using hop by hop routing.
ホップバイホップルーティングを使用すると、各ノードを個別に選択して、各FECの次のホップを選択できます。これは、既存のIPネットワークでの今日の通常のモードです。「ホップバイホップルーティングLSP」は、ホップルーティングによるホップを使用してルートが選択されるLSPです。
In an explicitly routed LSP, each LSR does not independently choose the next hop; rather, a single LSR, generally the LSP ingress or the LSP egress, specifies several (or all) of the LSRs in the LSP. If a single LSR specifies the entire LSP, the LSP is "strictly" explicitly routed. If a single LSR specifies only some of the LSP, the LSP is "loosely" explicitly routed.
明示的にルーティングされたLSPでは、各LSRは次のホップを独立して選択しません。むしろ、単一のLSR、一般的にLSPイングレスまたはLSP出口で、LSPのLSRのいくつか（またはすべて）を指定します。単一のLSRがLSP全体を指定する場合、LSPは「厳密に」明示的にルーティングされます。単一のLSRがLSPの一部のみを指定している場合、LSPは明示的にルーティングされています。
The sequence of LSRs followed by an explicitly routed LSP may be chosen by configuration, or may be selected dynamically by a single node (for example, the egress node may make use of the topological information learned from a link state database in order to compute the entire path for the tree ending at that egress node).
明示的にルーティングされたLSPが続くLSRのシーケンスは、構成によって選択されるか、単一のノードによって動的に選択される場合があります（たとえば、出口ノードは、リンク状態データベースから学習したトポロジ情報を使用して、その出口ノードで終わるツリーのパス全体）。
Explicit routing may be useful for a number of purposes, such as policy routing or traffic engineering. In MPLS, the explicit route needs to be specified at the time that labels are assigned, but the explicit route does not have to be specified with each IP packet. This makes MPLS explicit routing much more efficient than the alternative of IP source routing.
明示的なルーティングは、ポリシールーティングやトラフィックエンジニアリングなど、多くの目的に役立つ場合があります。MPLSでは、ラベルが割り当てられる時点で明示的なルートを指定する必要がありますが、明示的なルートを各IPパケットで指定する必要はありません。これにより、MPLSはIPソースルーティングの代替品よりもはるかに効率的に明示的になります。
The procedures for making use of explicit routes, either strict or loose, are beyond the scope of this document.
明示的なルートを使用する手順は、厳格または緩みのいずれかで、このドキュメントの範囲を超えています。
When a labeled packet is traveling along an LSP, it may occasionally happen that it reaches an LSR at which the ILM does not map the packet's incoming label into an NHLFE, even though the incoming label is itself valid. This can happen due to transient conditions, or due to an error at the LSR which should be the packet's next hop.
ラベル付きパケットがLSPに沿って走行している場合、ILMがパケットの着信ラベルをNHLFEにマッピングしないLSRに到達することがありますが、着信ラベル自体が有効です。これは、一時的な条件のために発生する可能性があります。また、Packetの次のホップであるLSRでのエラーが発生します。
It is tempting in such cases to strip off the label stack and attempt to forward the packet further via conventional forwarding, based on its network layer header. However, in general this is not a safe procedure:
このような場合、ラベルスタックを取り除き、ネットワークレイヤーヘッダーに基づいて、従来の転送を介してパケットをさらに転送しようとします。ただし、一般に、これは安全な手順ではありません。
- If the packet has been following an explicitly routed LSP, this could result in a loop.
- パケットが明示的にルーティングされたLSPをフォローしている場合、これによりループが発生する可能性があります。
- The packet's network header may not contain enough information to enable this particular LSR to forward it correctly.
- パケットのネットワークヘッダーには、この特定のLSRが正しく転送できるようにするのに十分な情報を含めることはできません。
Unless it can be determined (through some means outside the scope of this document) that neither of these situations obtains, the only safe procedure is to discard the packet.
これらの状況のどちらも取得していないという（このドキュメントの範囲外の何らかの手段を通じて）決定できない限り、唯一の安全な手順はパケットを破棄することです。
In conventional IP forwarding, each packet carries a "Time To Live" (TTL) value in its header. Whenever a packet passes through a router, its TTL gets decremented by 1; if the TTL reaches 0 before the packet has reached its destination, the packet gets discarded.
従来のIP転送では、各パケットにはヘッダーに「生きる時間」（TTL）値があります。パケットがルーターを通過するたびに、そのTTLは1によって減少します。パケットが宛先に到達する前にTTLが0に達すると、パケットが破棄されます。
This provides some level of protection against forwarding loops that may exist due to misconfigurations, or due to failure or slow convergence of the routing algorithm. TTL is sometimes used for other functions as well, such as multicast scoping, and supporting the "traceroute" command. This implies that there are two TTL-related issues that MPLS needs to deal with: (i) TTL as a way to suppress loops; (ii) TTL as a way to accomplish other functions, such as limiting the scope of a packet.
これにより、誤った採取のため、またはルーティングアルゴリズムの故障またはゆっくりした収束のために存在する可能性のある転送ループに対するある程度の保護が提供されます。TTLは、マルチキャストスコーピングや「Traceroute」コマンドのサポートなど、他の機能にも使用される場合があります。これは、MPLが対処する必要がある2つのTTL関連の問題が次のとおりであることを意味します。（i）ループを抑制する方法としてTTL。（ii）パケットの範囲の制限など、他の機能を達成する方法としてのTTL。
When a packet travels along an LSP, it SHOULD emerge with the same TTL value that it would have had if it had traversed the same sequence of routers without having been label switched. If the packet travels along a hierarchy of LSPs, the total number of LSR-hops traversed SHOULD be reflected in its TTL value when it emerges from the hierarchy of LSPs.
パケットがLSPに沿って移動すると、ラベルを切り替えずに同じシーケンスのルーターのシーケンスを横断していた場合と同じTTL値で出現するはずです。パケットがLSPの階層に沿って移動する場合、LSPの階層から出現する場合、トラバースされたLSR-HOPSの総数はTTL値に反映される必要があります。
The way that TTL is handled may vary depending upon whether the MPLS label values are carried in an MPLS-specific "shim" header [MPLS-SHIM], or if the MPLS labels are carried in an L2 header, such as an ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY].
TTLの処理方法は、MPLSラベル値がMPLS固有の「シム」ヘッダー[MPLS-Shim]で運ばれるかどうかによって異なる場合があります。MPLS-ATM]またはフレームリレーヘッダー[MPLS-FRMRLY]。
If the label values are encoded in a "shim" that sits between the data link and network layer headers, then this shim MUST have a TTL field that SHOULD be initially loaded from the network layer header TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be copied into the network layer header TTL field when the packet emerges from its LSP.
ラベル値がデータリンクとネットワークレイヤーヘッダーの間にある「シム」にエンコードされている場合、このシムには、ネットワークレイヤーヘッダーTTLフィールドから最初にロードする必要があるTTLフィールドが必要である必要があります。ホップ、パケットがLSPから出現したら、ネットワークレイヤーヘッダーTTLフィールドにコピーする必要があります。
If the label values are encoded in a data link layer header (e.g., the VPI/VCI field in ATM's AAL5 header), and the labeled packets are forwarded by an L2 switch (e.g., an ATM switch), and the data link layer (like ATM) does not itself have a TTL field, then it will not be possible to decrement a packet's TTL at each LSR-hop. An LSP segment which consists of a sequence of LSRs that cannot decrement a packet's TTL will be called a "non-TTL LSP segment".
ラベル値がデータリンクレイヤーヘッダー（ATMのAAL5ヘッダーのVPI/VCIフィールドなど）でエンコードされ、ラベル付きパケットがL2スイッチ（ATMスイッチなど）とデータリンクレイヤー（ATMのように）自体がTTLフィールドを持っていないため、各LSR-HOPでパケットのTTLを減らすことはできません。パケットのTTLを減らすことができないLSRのシーケンスで構成されるLSPセグメントは、「非TTL LSPセグメント」と呼ばれます。
When a packet emerges from a non-TTL LSP segment, it SHOULD however be given a TTL that reflects the number of LSR-hops it traversed. In the unicast case, this can be achieved by propagating a meaningful LSP length to ingress nodes, enabling the ingress to decrement the TTL value before forwarding packets into a non-TTL LSP segment.
ただし、非TTL LSPセグメントからパケットが出現する場合、移動したLSR-HOPSの数を反映するTTLを与える必要があります。ユニキャストの場合、これは意味のあるLSPの長さを伝播してノードを侵入することで実現できます。つまり、イングレスがTTL値を低下させる前に、パケットを非TTL LSPセグメントに転送できます。
Sometimes it can be determined, upon ingress to a non-TTL LSP segment, that a particular packet's TTL will expire before the packet reaches the egress of that non-TTL LSP segment. In this case, the LSR at the ingress to the non-TTL LSP segment must not label switch the packet. This means that special procedures must be developed to support traceroute functionality, for example, traceroute packets may be forwarded using conventional hop by hop forwarding.
非TTL LSPセグメントに侵入すると、パケットがその非TTL LSPセグメントの出口に到達する前に、特定のパケットのTTLが期限切れになることを決定することができます。この場合、非TTL LSPセグメントへのイングレスのLSRは、パケットのスイッチにラベルを付けてはなりません。これは、Traceroute機能をサポートするために特別な手順を開発する必要があることを意味します。たとえば、Tracerouteパケットは、ホップ転送による従来のホップを使用して転送される場合があります。
On a non-TTL LSP segment, by definition, TTL cannot be used to protect against forwarding loops. The importance of loop control may depend on the particular hardware being used to provide the LSR functions along the non-TTL LSP segment.
TTL以外のLSPセグメントでは、定義上、TTLを使用して転送ループから保護することはできません。ループ制御の重要性は、非TTL LSPセグメントに沿ってLSR関数を提供するために使用される特定のハードウェアに依存する可能性があります。
Suppose, for instance, that ATM switching hardware is being used to provide MPLS switching functions, with the label being carried in the VPI/VCI field. Since ATM switching hardware cannot decrement TTL, there is no protection against loops. If the ATM hardware is capable of providing fair access to the buffer pool for incoming cells carrying different VPI/VCI values, this looping may not have any deleterious effect on other traffic. If the ATM hardware cannot
たとえば、ATMスイッチングハードウェアがMPLSスイッチング関数を提供するために使用されていると仮定し、ラベルがVPI/VCIフィールドで運ばれます。ATMスイッチングハードウェアはTTLを減らすことはできないため、ループに対する保護はありません。ATMハードウェアが、さまざまなVPI/VCI値を持つ着信セル用のバッファープールへの公正なアクセスを提供できる場合、このループは他のトラフィックに有害な影響を与えない場合があります。ATMハードウェアができない場合
provide fair buffer access of this sort, however, then even transient loops may cause severe degradation of the LSR's total performance.
ただし、この種の公正なバッファーアクセスを提供しますが、一時的なループでさえLSRの合計パフォーマンスの深刻な分解を引き起こす可能性があります。
Even if fair buffer access can be provided, it is still worthwhile to have some means of detecting loops that last "longer than possible". In addition, even where TTL and/or per-VC fair queuing provides a means for surviving loops, it still may be desirable where practical to avoid setting up LSPs which loop. All LSRs that may attach to non-TTL LSP segments will therefore be required to support a common technique for loop detection; however, use of the loop detection technique is optional. The loop detection technique is specified in [MPLS-ATM] and [MPLS-LDP].
公正なバッファーアクセスが提供されたとしても、「可能性よりも長く」持続するループを検出する手段を持つことは依然として価値があります。さらに、TTLおよび/またはVCごとの公正キューイングがループを生き残るための手段を提供している場合でも、ループがどのLSPを設定しないようにすることが実用的な場合でも望ましい場合があります。したがって、非TTL LSPセグメントに付着する可能性のあるすべてのLSRは、ループ検出の一般的な手法をサポートするために必要です。ただし、ループ検出手法の使用はオプションです。ループ検出手法は、[MPLS-ATM]および[MPLS-LDP]で指定されています。
In order to transmit a label stack along with the packet whose label stack it is, it is necessary to define a concrete encoding of the label stack. The architecture supports several different encoding techniques; the choice of encoding technique depends on the particular kind of device being used to forward labeled packets.
ラベルスタックがラベルスタックであるパケットとともに、ラベルスタックを送信するには、ラベルスタックのコンクリートエンコードを定義する必要があります。アーキテクチャは、いくつかの異なるエンコード技術をサポートしています。エンコーディング技術の選択は、ラベル付きパケットを転送するために使用される特定の種類のデバイスに依存します。
If one is using MPLS-specific hardware and/or software to forward labeled packets, the most obvious way to encode the label stack is to define a new protocol to be used as a "shim" between the data link layer and network layer headers. This shim would really be just an encapsulation of the network layer packet; it would be "protocol-independent" such that it could be used to encapsulate any network layer. Hence we will refer to it as the "generic MPLS encapsulation".
MPLS固有のハードウェアおよび/またはソフトウェアを使用してラベル付きパケットを転送している場合、ラベルスタックをエンコードする最も明白な方法は、データリンクレイヤーとネットワークレイヤーヘッダーの間の「シム」として使用される新しいプロトコルを定義することです。このシムは、本当にネットワークレイヤーパケットのカプセル化にすぎません。任意のネットワークレイヤーのカプセルをカプセル化するために使用できるように、「プロトコルに依存しません」。したがって、それを「ジェネリックMPLSカプセル化」と呼びます。
The generic MPLS encapsulation would in turn be encapsulated in a data link layer protocol.
汎用MPLSカプセル化は、データリンクレイヤープロトコルでカプセル化されます。
The MPLS generic encapsulation is specified in [MPLS-SHIM].
MPLSジェネリックカプセル化は[MPLS-Shim]で指定されています。
It will be noted that MPLS forwarding procedures are similar to those of legacy "label swapping" switches such as ATM switches. ATM switches use the input port and the incoming VPI/VCI value as the index into a "cross-connect" table, from which they obtain an output port and an outgoing VPI/VCI value. Therefore if one or more labels can be encoded directly into the fields which are accessed by these legacy switches, then the legacy switches can, with suitable software upgrades, be used as LSRs. We will refer to such devices as "ATM-LSRs".
MPLS転送手順は、ATMスイッチなどのレガシー「ラベルスワッピング」スイッチのものと類似していることに注意してください。ATMスイッチは、入力ポートと着信VPI/VCI値をインデックスとして「クロスコネクト」テーブルに使用し、そこから出力ポートと発信VPI/VCI値を取得します。したがって、これらのレガシースイッチからアクセスされるフィールドに1つ以上のラベルを直接エンコードできる場合、レガシースイッチは、適切なソフトウェアアップグレードを使用してLSRとして使用できます。そのようなデバイスを「ATM-LSR」と呼びます。
There are three obvious ways to encode labels in the ATM cell header (presuming the use of AAL5):
ATMセルヘッダーにラベルをエンコードする3つの明白な方法があります（AAL5の使用を推定）：
1. SVC Encoding
1. SVCエンコーディング
Use the VPI/VCI field to encode the label which is at the top of the label stack. This technique can be used in any network. With this encoding technique, each LSP is realized as an ATM SVC, and the label distribution protocol becomes the ATM "signaling" protocol. With this encoding technique, the ATM-LSRs cannot perform "push" or "pop" operations on the label stack.
VPI/VCIフィールドを使用して、ラベルスタックの上部にあるラベルをエンコードします。この手法は、任意のネットワークで使用できます。このエンコード手法により、各LSPはATM SVCとして実現され、ラベル分布プロトコルはATM「シグナリング」プロトコルになります。このエンコード手法では、ATM-LSRはラベルスタックで「プッシュ」または「POP」操作を実行できません。
2. SVP Encoding
2. SVPエンコーディング
Use the VPI field to encode the label which is at the top of the label stack, and the VCI field to encode the second label on the stack, if one is present. This technique some advantages over the previous one, in that it permits the use of ATM "VP-switching". That is, the LSPs are realized as ATM SVPs, with the label distribution protocol serving as the ATM signaling protocol.
VPIフィールドを使用して、ラベルスタックの上部にあるラベルをエンコードし、VCIフィールドが存在する場合はスタックの2番目のラベルをエンコードします。この手法は、ATMの「VPスイッチング」の使用を許可するという点で、以前のものよりもいくつかの利点があります。つまり、LSPはATM SVPとして実現され、ラベル分布プロトコルはATMシグナル伝達プロトコルとして機能します。
However, this technique cannot always be used. If the network includes an ATM Virtual Path through a non-MPLS ATM network, then the VPI field is not necessarily available for use by MPLS.
ただし、この手法を常に使用するとは限りません。ネットワークに非MPLS ATMネットワークを介したATM仮想パスが含まれている場合、VPIフィールドは必ずしもMPLSで使用できるわけではありません。
When this encoding technique is used, the ATM-LSR at the egress of the VP effectively does a "pop" operation.
このエンコーディング手法を使用すると、VPの出口でのATM-LSRが「ポップ」操作を効果的に行います。
3. SVP Multipoint Encoding
3. SVPマルチポイントエンコーディング
Use the VPI field to encode the label which is at the top of the label stack, use part of the VCI field to encode the second label on the stack, if one is present, and use the remainder of the VCI field to identify the LSP ingress. If this technique is used, conventional ATM VP-switching capabilities can be used to provide multipoint-to-point VPs. Cells from different packets will then carry different VCI values. As we shall see in section 3.26, this enables us to do label merging, without running into any cell interleaving problems, on ATM switches which can provide multipoint-to-point VPs, but which do not have the VC merge capability.
VPIフィールドを使用して、ラベルスタックの上部にあるラベルをエンコードし、VCIフィールドの一部を使用してスタックの2番目のラベルをエンコードし、存在する場合は、VCIフィールドの残りの部分を使用してLSPを識別します。侵入。この手法を使用すると、従来のATM VPスイッチング機能を使用して、マルチポイントツーポイントVPSを提供できます。異なるパケットのセルは、異なるVCI値を運びます。セクション3.26でわかるように、これにより、マルチポイントからポイントへのVPSを提供できるがVCマージ機能がないATMスイッチで、セルのインターリーブの問題に遭遇することなく、ラベルマージを行うことができます。
This technique depends on the existence of a capability for assigning 16-bit VCI values to each ATM switch such that no single VCI value is assigned to two different switches. (If an
この手法は、2つの異なるスイッチに単一のVCI値が割り当てられないように、各ATMスイッチに16ビットVCI値を割り当てる機能の存在に依存します。（もし
adequate number of such values could be assigned to each switch, it would be possible to also treat the VCI value as the second label in the stack.)
そのような値の適切な数を各スイッチに割り当てることができます。また、VCI値をスタック内の2番目のラベルとして扱うこともできます。）
If there are more labels on the stack than can be encoded in the ATM header, the ATM encodings must be combined with the generic encapsulation.
ATMヘッダーでエンコードできるよりも多くのラベルがスタックにある場合、ATMエンコーディングは汎用カプセル化と組み合わせる必要があります。
If <R1, R2, R3> is a segment of a LSP, it is possible that R1 will use one encoding of the label stack when transmitting packet P to R2, but R2 will use a different encoding when transmitting a packet P to R3. In general, the MPLS architecture supports LSPs with different label stack encodings used on different hops. Therefore, when we discuss the procedures for processing a labeled packet, we speak in abstract terms of operating on the packet's label stack. When a labeled packet is received, the LSR must decode it to determine the current value of the label stack, then must operate on the label stack to determine the new value of the stack, and then encode the new value appropriately before transmitting the labeled packet to its next hop.
<R1、R2、R3>がLSPのセグメントである場合、R1はパケットPをR2に送信するときにラベルスタックの1つのエンコードを使用する可能性がありますが、R2はパケットPをR3に送信するときに異なるエンコードを使用します。一般に、MPLSアーキテクチャは、異なるホップで使用されるさまざまなラベルスタックエンコーディングでLSPをサポートしています。したがって、ラベル付きパケットを処理する手順について議論するとき、パケットのラベルスタックで操作するという抽象的な観点から話します。ラベル付きパケットを受信した場合、LSRはラベルスタックの現在の値を決定するためにそれをデコードする必要があります。次に、ラベルスタックで動作してスタックの新しい値を決定する必要があります。次のホップに。
Unfortunately, ATM switches have no capability for translating from one encoding technique to another. The MPLS architecture therefore requires that whenever it is possible for two ATM switches to be successive LSRs along a level m LSP for some packet, that those two ATM switches use the same encoding technique.
残念ながら、ATMスイッチには、あるエンコーディングテクニックから別のエンコード技術に翻訳する能力がありません。したがって、MPLSアーキテクチャでは、2つのATMスイッチがパケットのレベルM LSPに沿って連続するLSRになることができる場合はいつでも、これら2つのATMスイッチが同じエンコード技術を使用することを必要とします。
Naturally there will be MPLS networks which contain a combination of ATM switches operating as LSRs, and other LSRs which operate using an MPLS shim header. In such networks there may be some LSRs which have ATM interfaces as well as "MPLS Shim" interfaces. This is one example of an LSR with different label stack encodings on different hops. Such an LSR may swap off an ATM encoded label stack on an incoming interface and replace it with an MPLS shim header encoded label stack on the outgoing interface.
当然、LSRSとして動作するATMスイッチの組み合わせと、MPLSシムヘッダーを使用して動作する他のLSRの組み合わせを含むMPLSネットワークがあります。このようなネットワークには、ATMインターフェイスと「MPLSシム」インターフェイスを備えたLSRがある場合があります。これは、異なるホップに異なるラベルスタックエンコーディングを持つLSRの1つの例です。このようなLSRは、着信インターフェイスにATMエンコードされたラベルスタックを交換し、発信インターフェイスのMPLSシムヘッダーエンコードラベルスタックに置き換えることができます。
Suppose that an LSR has bound multiple incoming labels to a particular FEC. When forwarding packets in that FEC, one would like to have a single outgoing label which is applied to all such packets. The fact that two different packets in the FEC arrived with different incoming labels is irrelevant; one would like to forward them with the same outgoing label. The capability to do so is known as "label merging".
LSRが複数の着信ラベルを特定のFECにバインドしていると仮定します。そのFECにパケットを転送する場合、そのようなすべてのパケットに適用される単一の発信ラベルが必要です。FEC内の2つの異なるパケットが異なる着信ラベルで到着したという事実は無関係です。同じ発信ラベルで転送したいと思います。そうする能力は、「ラベルマージ」として知られています。
Let us say that an LSR is capable of label merging if it can receive two packets from different incoming interfaces, and/or with different labels, and send both packets out the same outgoing interface with the same label. Once the packets are transmitted, the information that they arrived from different interfaces and/or with different incoming labels is lost.
LSRは、異なる着信インターフェイスから2つのパケットを受け取ることができる場合、および/または異なるラベルを使用してラベルマージが可能であるとし、同じラベルで同じ発信インターフェイスを両方のパケットを送信します。パケットが送信されると、異なるインターフェイスや異なる着信ラベルから到着した情報が失われます。
Let us say that an LSR is not capable of label merging if, for any two packets which arrive from different interfaces, or with different labels, the packets must either be transmitted out different interfaces, or must have different labels. ATM-LSRs using the SVC or SVP Encodings cannot perform label merging. This is discussed in more detail in the next section.
異なるインターフェイスから到着する2つのパケット、または異なるラベルを使用して、パケットを異なるインターフェイスから送信するか、異なるラベルを持たなければならない場合、LSRはマージすることができないとしましょう。SVCまたはSVPエンコーディングを使用したATM-LSRは、ラベルマージを実行できません。これについては、次のセクションで詳しく説明します。
If a particular LSR cannot perform label merging, then if two packets in the same FEC arrive with different incoming labels, they must be forwarded with different outgoing labels. With label merging, the number of outgoing labels per FEC need only be 1; without label merging, the number of outgoing labels per FEC could be as large as the number of nodes in the network.
特定のLSRがラベルマージを実行できない場合、同じFECの2つのパケットが異なる着信ラベルで到着する場合、異なる発信ラベルで転送する必要があります。ラベルのマージでは、FECあたりの発信ラベルの数は1である必要があります。ラベルのマージがなければ、FECあたりの発信ラベルの数は、ネットワーク内のノードの数と同じくらい大きくなる可能性があります。
With label merging, the number of incoming labels per FEC that a particular LSR needs is never be larger than the number of label distribution adjacencies. Without label merging, the number of incoming labels per FEC that a particular LSR needs is as large as the number of upstream nodes which forward traffic in the FEC to the LSR in question. In fact, it is difficult for an LSR to even determine how many such incoming labels it must support for a particular FEC.
ラベルのマージを使用すると、特定のLSRが必要とするFECあたりの着信ラベルの数は、ラベル分布の隣接の数よりも大きくなることはありません。ラベルのマージがなければ、特定のLSRが必要とするFECあたりの着信ラベルの数は、FECのトラフィックを問題のLSRに転送する上流ノードの数と同じくらい大きい。実際、LSRが特定のFECに対してサポートしなければならないこのような着信ラベルの数を判断することさえ困難です。
The MPLS architecture accommodates both merging and non-merging LSRs, but allows for the fact that there may be LSRs which do not support label merging. This leads to the issue of ensuring correct interoperation between merging LSRs and non-merging LSRs. The issue is somewhat different in the case of datagram media versus the case of ATM. The different media types will therefore be discussed separately.
MPLSアーキテクチャは、マージと非マージングLSRの両方に対応していますが、ラベルのマージをサポートしていないLSRが存在する可能性があるという事実が可能になります。これは、LSRのマージと非マスターLSRの間の正しい相互操作を確保する問題につながります。この問題は、Datagramメディアの場合とATMの場合と多少異なります。したがって、さまざまなメディアタイプについて個別に説明します。
The MPLS forwarding procedures is very similar to the forwarding procedures used by such technologies as ATM and Frame Relay. That is, a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a "cross-connect table", on the basis of that lookup an output port is chosen, and the label value is rewritten. In fact, it is possible to use such technologies for MPLS forwarding; a label distribution protocol can be used as the "signalling protocol" for setting up the cross-connect tables.
MPLS転送手順は、ATMやフレームリレーなどのテクノロジーが使用する転送手順と非常に似ています。つまり、データの単位が到着し、ラベル（VPI/VCIまたはDLCI）が「クロスコネクトテーブル」で検索されます。そのルックアップに基づいて、出力ポートが選択され、ラベル値が書き直されます。実際、MPLS転送にそのような技術を使用することが可能です。ラベル分布プロトコルは、クロスコネクトテーブルを設定するための「シグナル伝達プロトコル」として使用できます。
Unfortunately, these technologies do not necessarily support the label merging capability. In ATM, if one attempts to perform label merging, the result may be the interleaving of cells from various packets. If cells from different packets get interleaved, it is impossible to reassemble the packets. Some Frame Relay switches use cell switching on their backplanes. These switches may also be incapable of supporting label merging, for the same reason -- cells of different packets may get interleaved, and there is then no way to reassemble the packets.
残念ながら、これらのテクノロジーは、必ずしもラベルのマージ機能をサポートするわけではありません。ATMでは、ラベルマージを実行しようとする場合、結果はさまざまなパケットからの細胞のインターリーブになる可能性があります。異なるパケットのセルがインターリーブされる場合、パケットを再組み立てることは不可能です。一部のフレームリレースイッチは、バックプレーンのセルスイッチングを使用します。これらのスイッチは、同じ理由でラベルの合併をサポートできない場合もあります。異なるパケットのセルがインターリーブされる場合があり、パケットを再組み立てる方法はありません。
We propose to support two solutions to this problem. First, MPLS will contain procedures which allow the use of non-merging LSRs. Second, MPLS will support procedures which allow certain ATM switches to function as merging LSRs.
この問題の2つのソリューションをサポートすることを提案します。まず、MPLSには、非マースLSRの使用を可能にする手順が含まれます。第二に、MPLSは、特定のATMスイッチがLSRのマージとして機能できるようにする手順をサポートします。
Since MPLS supports both merging and non-merging LSRs, MPLS also contains procedures to ensure correct interoperation between them.
MPLSはマージと非マージングLSRの両方をサポートしているため、MPLSにはそれらの間の正しい相互操作を確保する手順も含まれています。
An upstream LSR which supports label merging needs to be sent only one label per FEC. An upstream neighbor which does not support label merging needs to be sent multiple labels per FEC. However, there is no way of knowing a priori how many labels it needs. This will depend on how many LSRs are upstream of it with respect to the FEC in question.
ラベルマージをサポートする上流のLSRは、FECごとに1つのラベルのみを送信する必要があります。ラベルのマージをサポートしていない上流の隣人は、FECあたり複数のラベルを送信する必要があります。ただし、必要なラベルの数を先験的に知る方法はありません。これは、問題のFECに関して、LSRの上流であるLSRの数に依存します。
In the MPLS architecture, if a particular upstream neighbor does not support label merging, it is not sent any labels for a particular FEC unless it explicitly asks for a label for that FEC. The upstream neighbor may make multiple such requests, and is given a new label each time. When a downstream neighbor receives such a request from upstream, and the downstream neighbor does not itself support label merging, then it must in turn ask its downstream neighbor for another label for the FEC in question.
MPLSアーキテクチャでは、特定の上流の隣人がラベルのマージをサポートしていない場合、そのFECのラベルを明示的に要求しない限り、特定のFECのラベルは送信されません。上流の隣人は複数のそのようなリクエストを行うことができ、毎回新しいラベルが与えられます。下流の隣人が上流からそのような要求を受け取り、下流の隣人自体がラベルのマージをサポートしていない場合、次に、下流の隣人に問題のFECの別のラベルを求めなければなりません。
It is possible that there may be some nodes which support label merging, but can only merge a limited number of incoming labels into a single outgoing label. Suppose for example that due to some hardware limitation a node is capable of merging four incoming labels into a single outgoing label. Suppose however, that this particular node has six incoming labels arriving at it for a particular FEC. In this case, this node may merge these into two outgoing labels.
ラベルのマージをサポートするノードがいくつかある可能性がありますが、限られた数の受信ラベルを単一の発信ラベルにマージすることしかできません。たとえば、ハードウェアの制限により、ノードが4つの着信ラベルを単一の発信ラベルに統合できるとします。ただし、この特定のノードには、特定のFECのために6つの着信ラベルが到着していると仮定します。この場合、このノードはこれらを2つの発信ラベルに統合する場合があります。
Whether label merging is applicable to explicitly routed LSPs is for further study.
ラベルマージが明示的にルーティングされたLSPに適用できるかどうかは、さらなる研究のためです。
There are several methods that can be used to eliminate the cell interleaving problem in ATM, thereby allowing ATM switches to support stream merge:
ATMの細胞インターリーニング問題を排除するために使用できるいくつかの方法があり、それによりATMスイッチがストリームマージをサポートできるようにします。
1. VP merge, using the SVP Multipoint Encoding
1. VPマージ、SVPマルチポイントエンコーディングを使用
When VP merge is used, multiple virtual paths are merged into a virtual path, but packets from different sources are distinguished by using different VCIs within the VP.
VPマージを使用すると、複数の仮想パスが仮想パスにマージされますが、VP内の異なるVCIを使用することにより、異なるソースからのパケットが区別されます。
2. VC merge
2. VCマージ
When VC merge is used, switches are required to buffer cells from one packet until the entire packet is received (this may be determined by looking for the AAL5 end of frame indicator).
VCマージを使用すると、パケット全体が受信されるまで1つのパケットからセルをバッファリングするにはスイッチが必要です（これは、フレームインジケーターのAAL5エンドを探すことで決定できます）。
VP merge has the advantage that it is compatible with a higher percentage of existing ATM switch implementations. This makes it more likely that VP merge can be used in existing networks. Unlike VC merge, VP merge does not incur any delays at the merge points and also does not impose any buffer requirements. However, it has the disadvantage that it requires coordination of the VCI space within each VP. There are a number of ways that this can be accomplished. Selection of one or more methods is for further study.
VP Mergeには、既存のATMスイッチの実装の割合が高いことと互換性があるという利点があります。これにより、VPマージを既存のネットワークで使用できる可能性が高くなります。VCマージとは異なり、VP Mergeはマージポイントで遅延を負担せず、バッファー要件も課しません。ただし、各VP内のVCI空間の調整が必要であるという不利な点があります。これを達成できる方法はいくつかあります。1つ以上の方法を選択することは、さらなる研究のためです。
This tradeoff between compatibility with existing equipment versus protocol complexity and scalability implies that it is desirable for the MPLS protocol to support both VP merge and VC merge. In order to do so each ATM switch participating in MPLS needs to know whether its immediate ATM neighbors perform VP merge, VC merge, or no merge.
既存の機器とプロトコルの複雑さとスケーラビリティとの互換性との間のこのトレードオフは、MPLSプロトコルがVPマージとVCマージの両方をサポートすることが望ましいことを意味します。そのためには、MPLSに参加している各ATMスイッチが、その直接のATM近隣がVPマージ、VCマージ、またはマージを実行しないかどうかを知る必要があります。
The interoperation of the various forms of merging over ATM is most easily described by first describing the interoperation of VC merge with non-merge.
ATMを介したさまざまな形のマージの相互操作は、最初に非マージとのVCマージの相互操作を記述することによって最も簡単に説明されます。
In the case where VC merge and non-merge nodes are interconnected the forwarding of cells is based in all cases on a VC (i.e., the concatenation of the VPI and VCI). For each node, if an upstream neighbor is doing VC merge then that upstream neighbor requires only a single VPI/VCI for a particular stream (this is analogous to the requirement for a single label in the case of operation over frame media). If the upstream neighbor is not doing merge, then the
VCマージと非マージノードが相互接続されている場合、細胞の転送はすべての場合にVC（つまり、VPIとVCIの連結）に基づいています。各ノードについて、上流の隣人がVCマージを行っている場合、その上流の隣接は特定のストリームに対して単一のVPI/VCIのみを必要とします（これは、フレームメディア上の動作の場合の単一のラベルの要件に類似しています）。上流の隣人がマージしていない場合、
neighbor will require a single VPI/VCI per stream for itself, plus enough VPI/VCIs to pass to its upstream neighbors. The number required will be determined by allowing the upstream nodes to request additional VPI/VCIs from their downstream neighbors (this is again analogous to the method used with frame merge).
隣人は、それ自体に対してストリームごとに単一のVPI/VCIと、上流の隣人に渡すのに十分なVPI/VCIを必要とします。必要な数は、上流のノードが下流の隣人に追加のVPI/VCIを要求できるようにすることで決定されます（これは、フレームマージで使用されるメソッドに類似しています）。
A similar method is possible to support nodes which perform VP merge. In this case the VP merge node, rather than requesting a single VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead may request a single VP (identified by a VPI) but several VCIs within the VP. Furthermore, suppose that a non-merge node is downstream from two different VP merge nodes. This node may need to request one VPI/VCI (for traffic originating from itself) plus two VPs (one for each upstream node), each associated with a specified set of VCIs (as requested from the upstream node).
VPマージを実行するノードをサポートする同様の方法が可能です。この場合、VPは、下流の近隣から単一のVPI/VCIまたは多数のVPI/VCIを要求するのではなく、NODEをマージし、代わりにVP（VPIで識別）がVP内のいくつかのVCIを要求する場合があります。さらに、非マージノードが2つの異なるVPマージノードから下流にあると仮定します。このノードは、1つのVPI/VCI（それ自体からのトラフィック用）と2つのVPS（各アップストリームノードに1つ）を要求する必要があります。
In order to support all of VP merge, VC merge, and non-merge, it is therefore necessary to allow upstream nodes to request a combination of zero or more VC identifiers (consisting of a VPI/VCI), plus zero or more VPs (identified by VPIs) each containing a specified number of VCs (identified by a set of VCIs which are significant within a VP). VP merge nodes would therefore request one VP, with a contained VCI for traffic that it originates (if appropriate) plus a VCI for each VC requested from above (regardless of whether or not the VC is part of a containing VP). VC merge node would request only a single VPI/VCI (since they can merge all upstream traffic into a single VC). Non-merge nodes would pass on any requests that they get from above, plus request a VPI/VCI for traffic that they originate (if appropriate).
したがって、VPマージ、VCマージ、および非マージのすべてをサポートするためには、上流ノードがゼロ以上のVC識別子（VPI/VCIで構成される）とゼロ以上のVPの組み合わせを要求できるようにする必要があります。VPIで識別）それぞれが指定された数のVCを含む（VP内で重要なVCIのセットによって識別）。したがって、VPマージノードは、1つのVPを要求し、上から要求された各VCのVCIが発生するトラフィックに含まれるVCIを含みます（VCが含まれるVPの一部であるかどうかに関係なく）。VCマージノードは、1つのVPI/VCIのみを要求します（上流のすべてのトラフィックを単一のVCにマージできるため）。非マージノードは、上から得られるリクエストを渡し、さらに、それらが発生するトラフィックのVPI/VCIを要求します（必要に応じて）。
Sometimes a router Ru takes explicit action to cause a particular packet to be delivered to another router Rd, even though Ru and Rd are not consecutive routers on the Hop-by-hop path for that packet, and Rd is not the packet's ultimate destination. For example, this may be done by encapsulating the packet inside a network layer packet whose destination address is the address of Rd itself. This creates a "tunnel" from Ru to Rd. We refer to any packet so handled as a "Tunneled Packet".
Ruter RUは、RuとRDがそのパケットのホップバイホップパス上の連続したルーターではなく、RDはパケットの最終的な目的地ではない場合でも、特定のパケットを別のRouter RDに配信するために明示的なアクションをとることがあります。たとえば、これは、宛先アドレスがRD自体のアドレスであるネットワークレイヤーパケット内のパケットをカプセル化することで実行できます。これにより、RUからRDへの「トンネル」が作成されます。「トンネルパケット」として処理されたパケットを参照してください。
If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.
トンネルパケットがRUからRDへのホップバイホップパスに従う場合、「送信エンドポイント」がRUであり、「受信エンドポイント」がRDである「ホップバイホップルーティングトンネル」にあると言います。
If a Tunneled Packet travels from Ru to Rd over a path other than the Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. For example, we might send a packet through an Explicitly Routed Tunnel by encapsulating it in a packet which is source routed.
トンネルされたパケットがホップバイホップパス以外のパスを越えてRUからRDに移動する場合、「送信エンドポイント」がRUであり、「受信エンドポイント」がRDである「明示的にルーティングされたトンネル」にあると言います。たとえば、ソースルーティングのパケットにカプセル化することにより、明示的にルーティングされたトンネルを介してパケットを送信する場合があります。
It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. The tunnel would be a LSP <R1, ..., Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the receive endpoint of the tunnel. This is called a "LSP Tunnel".
トンネルをLSPとして実装し、ネットワークレイヤーのカプセル化ではなくラベルスイッチングを使用して、パケットをトンネルを通過させることができます。トンネルはLSP <r1、...、RN>であり、R1はトンネルの送信エンドポイント、RNはトンネルの受信エンドポイントです。これは「LSPトンネル」と呼ばれます。
The set of packets which are to be sent though the LSP tunnel constitutes a FEC, and each LSR in the tunnel must assign a label to that FEC (i.e., must assign a label to the tunnel). The criteria for assigning a particular packet to an LSP tunnel is a local matter at the tunnel's transmit endpoint. To put a packet into an LSP tunnel, the transmit endpoint pushes a label for the tunnel onto the label stack and sends the labeled packet to the next hop in the tunnel.
LSPトンネルがFECを構成するが送信されるパケットのセットは、トンネル内の各LSRがそのFECにラベルを割り当てる必要があります（つまり、ラベルをトンネルに割り当てる必要があります）。特定のパケットをLSPトンネルに割り当てるための基準は、トンネルの送信エンドポイントの局所的な問題です。パケットをLSPトンネルに入れるために、送信エンドポイントはトンネルのラベルをラベルスタックに押し込み、ラベル付きパケットをトンネルの次のホップに送信します。
If it is not necessary for the tunnel's receive endpoint to be able to determine which packets it receives through the tunnel, as discussed earlier, the label stack may be popped at the penultimate LSR in the tunnel.
前述のように、トンネルの受信エンドポイントがトンネルを通って受信するパケットを決定できるようにする必要がない場合、ラベルスタックはトンネルの最後から2番目のLSRにポップされる可能性があります。
A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as an hop-by-hop routed LSP between the transmit endpoint and the receive endpoint.
「ホップバイホップルーティングされたLSPトンネル」は、送信エンドポイントと受信エンドポイントの間のホップバイホップルーティングLSPとして実装されるトンネルです。
An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an Explicitly Routed LSP.
「明示的にルーティングされたLSPトンネル」は、明示的にルーティングされたLSPでもあるLSPトンネルです。
Consider a LSP <R1, R2, R3, R4>. Let us suppose that R1 receives unlabeled packet P, and pushes on its label stack the label to cause it to follow this path, and that this is in fact the Hop-by-hop path. However, let us further suppose that R2 and R3 are not directly connected, but are "neighbors" by virtue of being the endpoints of an LSP tunnel. So the actual sequence of LSRs traversed by P is <R1, R2, R21, R22, R23, R3, R4>.
LSP <R1、R2、R3、R4>を考えてみましょう。R1がラベルのないパケットPを受信し、ラベルスタックをプッシュしてラベルを押して、このパスに従うようにし、これが実際にホップバイホップパスであると仮定します。ただし、R2とR3が直接接続されていないが、LSPトンネルのエンドポイントであるために「隣人」であるとさらに仮定します。したがって、Pによって横断されるLSRの実際の配列は、<R1、R2、R21、R22、R23、R3、R4>です。
When P travels from R1 to R2, it will have a label stack of depth 1. R2, switching on the label, determines that P must enter the tunnel. R2 first replaces the Incoming label with a label that is meaningful to R3. Then it pushes on a new label. This level 2 label has a value which is meaningful to R21. Switching is done on the level 2 label by R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, pops the label stack before forwarding the packet to R3. When R3 sees packet P, P has only a level 1 label, having now exited the tunnel. Since R3 is the penultimate hop in P's level 1 LSP, it pops the label stack, and R4 receives P unlabeled.
PがR1からR2に移動すると、ラベルを切り替えるR2のラベルスタックがあり、Pがトンネルに入る必要があると判断します。R2は、最初に着信ラベルをR3にとって意味のあるラベルに置き換えます。その後、新しいラベルを押します。このレベル2ラベルには、R21にとって意味のある値があります。スイッチングは、R21、R22、R23によるレベル2ラベルで行われます。R2-R3トンネルの最後から2番目のホップであるR23は、パケットをR3に転送する前にラベルスタックをポップします。R3がパケットPを見ると、Pにはレベル1のラベルのみがあり、トンネルを終了しました。R3はPのレベル1 LSPの最後から2番目のホップであるため、ラベルスタックがポップされ、R4はPを無効にします。
The label stack mechanism allows LSP tunneling to nest to any depth.
ラベルスタックメカニズムにより、LSPトンネリングは任意の深さまでネストできます。
Suppose that packet P travels along a Level 1 LSP <R1, R2, R3, R4>, and when going from R2 to R3 travels along a Level 2 LSP <R2, R21, R22, R3>. From the perspective of the Level 2 LSP, R2's label distribution peer is R21. From the perspective of the Level 1 LSP, R2's label distribution peers are R1 and R3. One can have label distribution peers at each layer of hierarchy. We will see in sections 4.6 and 4.7 some ways to make use of this hierarchy. Note that in this example, R2 and R21 must be IGP neighbors, but R2 and R3 need not be.
パケットPがレベル1 LSP <R1、R2、R3、R4>に沿って移動し、R2からR3に進むとレベル2 LSP <R2、R21、R22、R3>に沿って移動するとします。レベル2 LSPの観点から見ると、R2のラベル分布ピアはR21です。レベル1 LSPの観点から見ると、R2のラベル分布ピアはR1とR3です。階層の各層でラベル分布ピアを持つことができます。セクション4.6および4.7では、この階層を利用する方法をいくつか見ていきます。この例では、R2とR21はIGP近隣でなければなりませんが、R2とR3は必要ではないことに注意してください。
When two LSRs are IGP neighbors, we will refer to them as "local label distribution peers". When two LSRs may be label distribution peers, but are not IGP neighbors, we will refer to them as "remote label distribution peers". In the above example, R2 and R21 are local label distribution peers, but R2 and R3 are remote label distribution peers.
2つのLSRがIGP近隣の場合、それらを「ローカルラベルディストリビューションピア」と呼びます。2つのLSRがラベル分布ピアであるが、IGPの隣接者ではない場合、それらを「リモートラベル配信ピア」と呼びます。上記の例では、R2とR21はローカルラベルディストリビューションピアですが、R2とR3はリモートラベル配布ピアです。
The MPLS architecture supports two ways to distribute labels at different layers of the hierarchy: Explicit Peering and Implicit Peering.
MPLSアーキテクチャは、階層の異なるレイヤーでラベルを配布する2つの方法をサポートしています：明示的なピアリングと暗黙のピアリング。
One performs label distribution with one's local label distribution peer by sending label distribution protocol messages which are addressed to the peer. One can perform label distribution with one's remote label distribution peers in one of two ways:
ピアに宛てられたラベル配布プロトコルメッセージを送信することにより、ローカルラベルディストリビューションピアでラベル配布を実行します。2つの方法のいずれかで、リモートラベルディストリビューションピアを使用してラベル配布を実行できます。
1. Explicit Peering
1. 明示的なピアリング
In explicit peering, one distributes labels to a peer by sending label distribution protocol messages which are addressed to the peer, exactly as one would do for local label distribution peers. This technique is most useful when the number of remote label distribution peers is small, or the
明示的なピアリングでは、ローカルラベルディストリビューションピアに対して行うように、ピアに宛てられたラベル配布プロトコルメッセージを送信することにより、ラベルをピアに配布します。この手法は、リモートラベルディストリビューションピアの数が小さい場合、または
number of higher level label bindings is large, or the remote label distribution peers are in distinct routing areas or domains. Of course, one needs to know which labels to distribute to which peers; this is addressed in section 4.1.2.
高レベルのラベルバインディングの数は大きいか、リモートラベルの配布ピアが異なるルーティングエリアまたはドメインにあります。もちろん、どのラベルを配布するかを知る必要があります。これは、セクション4.1.2で説明されています。
Examples of the use of explicit peering is found in sections 4.2.1 and 4.6.
明示的なピアリングの使用の例は、セクション4.2.1および4.6にあります。
2. Implicit Peering
2. 暗黙のピアリング
In Implicit Peering, one does not send label distribution protocol messages which are addressed to one's peer. Rather, to distribute higher level labels to ones remote label distribution peers, one encodes a higher level label as an attribute of a lower level label, and then distributes the lower level label, along with this attribute, to one's local label distribution peers. The local label distribution peers then propagate the information to their local label distribution peers. This process continues till the information reaches the remote peer.
暗黙のピアリングでは、ピアに宛てられたラベル配布プロトコルメッセージを送信しません。むしろ、より高いレベルのラベルをリモートラベル分布ピアに配布するために、より高いレベルのラベルを低レベルのラベルの属性としてエンコードし、この属性とともにローカルラベル配布ピアに低レベルのラベルを配布します。その後、ローカルラベルの配布ピアは、情報をローカルラベルディストリビューションピアに伝播します。このプロセスは、情報がリモートピアに到達するまで続きます。
This technique is most useful when the number of remote label distribution peers is large. Implicit peering does not require an n-square peering mesh to distribute labels to the remote label distribution peers because the information is piggybacked through the local label distribution peering. However, implicit peering requires the intermediate nodes to store information that they might not be directly interested in.
この手法は、リモートラベル配布ピアの数が多い場合に最も便利です。暗黙のピアリングでは、情報がローカルラベルディストリビューションピアリングを通じてピギーバックされているため、リモートラベルの配布ピアにラベルを配布するために、N二乗ピアリングメッシュを必要としません。ただし、暗黙のピアリングには、直接関心がない可能性のある情報を保存するために中間ノードが必要です。
An example of the use of implicit peering is found in section 4.3.
暗黙のピアリングの使用の例は、セクション4.3にあります。
A label distribution protocol is used between nodes in an MPLS network to establish and maintain the label bindings. In order for MPLS to operate correctly, label distribution information needs to be transmitted reliably, and the label distribution protocol messages pertaining to a particular FEC need to be transmitted in sequence. Flow control is also desirable, as is the capability to carry multiple label messages in a single datagram.
ラベル分布プロトコルは、MPLSネットワークのノード間で使用され、ラベルバインディングを確立および維持します。MPLが正しく動作するためには、ラベル分布情報を確実に送信する必要があり、特定のFECに関するラベル分布プロトコルメッセージを順番に送信する必要があります。単一のデータグラムに複数のラベルメッセージを伝達する機能と同様に、フロー制御も望ましいです。
One way to meet these goals is to use TCP as the underlying transport, as is done in [MPLS-LDP] and [MPLS-BGP].
これらの目標を達成する1つの方法は、[MPLS-LDP]および[MPLS-BGP]で行われるように、TCPを基礎となる輸送として使用することです。
This architecture does not establish hard and fast rules for choosing which label distribution protocol to use in which circumstances. However, it is possible to point out some of the considerations.
このアーキテクチャは、どのような状況で使用するラベル分布プロトコルを選択するためのハードで高速なルールを確立しません。ただし、考慮事項の一部を指摘することができます。
In many scenarios, it is desirable to bind labels to FECs which can be identified with routes to address prefixes (see section 4.1). If there is a standard, widely deployed routing algorithm which distributes those routes, it can be argued that label distribution is best achieved by piggybacking the label distribution on the distribution of the routes themselves.
多くのシナリオでは、プレフィックスに対処するためのルートで識別できるFECにラベルをバインドすることが望ましい（セクション4.1を参照）。これらのルートを配布する標準の広く展開されたルーティングアルゴリズムがある場合、ラベル分布は、ルート自体の分布に関するラベル分布をピギーバックすることで最もよく達成されると主張できます。
For example, BGP distributes such routes, and if a BGP speaker needs to also distribute labels to its BGP peers, using BGP to do the label distribution (see [MPLS-BGP]) has a number of advantages. In particular, it permits BGP route reflectors to distribute labels, thus providing a significant scalability advantage over using LDP to distribute labels between BGP peers.
たとえば、BGPはそのようなルートを分配し、BGPスピーカーがBGPのピアにラベルを配布する必要がある場合、BGPを使用してラベル分布（[MPLS-BGPを参照]を参照）には多くの利点があります。特に、BGPルートリフレクターがラベルを配布できるようにするため、LDPを使用してBGPピア間でラベルを配布する上で大きなスケーラビリティの利点を提供します。
When RSVP is used to set up resource reservations for particular flows, it can be desirable to label the packets in those flows, so that the RSVP filterspec does not need to be applied at each hop. It can be argued that having RSVP distribute the labels as part of its path/reservation setup process is the most efficient method of distributing labels for this purpose.
RSVPが特定のフローのリソース予約をセットアップするために使用される場合、RSVPフィルタースペックを各ホップで適用する必要がないように、それらのフローにパケットにラベルを付けることが望ましい場合があります。RSVPがパス/予約セットアッププロセスの一部としてラベルを配布することは、この目的のためにラベルを配布する最も効率的な方法であると主張することができます。
In some applications of MPLS, particularly those related to traffic engineering, it is desirable to set up an explicitly routed path, from ingress to egress. It is also desirable to apply resource reservations along that path.
MPLの一部、特にトラフィックエンジニアリングに関連するアプリケーションでは、イングレスから出口まで、明示的にルーティングされたパスを設定することが望ましいです。また、そのパスに沿ってリソースの予約を適用することも望ましいです。
One can imagine two approaches to this:
これに対する2つのアプローチを想像できます。
- Start with an existing protocol that is used for setting up resource reservations, and extend it to support explicit routing and label distribution.
- リソースの予約を設定するために使用される既存のプロトコルから始めて、明示的なルーティングとラベル分布をサポートするために拡張します。
- Start with an existing protocol that is used for label distribution, and extend it to support explicit routing and resource reservations.
- ラベル分布に使用される既存のプロトコルから始めて、明示的なルーティングとリソースの予約をサポートするために拡張します。
The first approach has given rise to the protocol specified in [MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS-CR-LDP].
最初のアプローチでは、[MPLS-RSVP-Tunnels]で指定されたプロトコルが生まれ、[MPLS-CR-LDP]で指定されたアプローチの2番目のアプローチが生まれました。
This section is for further study
このセクションは、さらなる研究のためです
A number of uses of MPLS require that packets with a certain label be forwarded along the same hop-by-hop routed path that would be used for forwarding a packet with a specified address in its network layer destination address field.
MPLの多くの使用では、特定のラベルを持つパケットが、ネットワークレイヤー宛先アドレスフィールドに指定されたアドレスを含むパケットを転送するために使用される同じホップバイホップルーティングパスに沿って転送される必要があります。
In general, router R determines the next hop for packet P by finding the address prefix X in its routing table which is the longest match for P's destination address. That is, the packets in a given FEC are just those packets which match a given address prefix in R's routing table. In this case, a FEC can be identified with an address prefix.
一般に、Router Rは、Pの宛先アドレスで最も長い一致であるルーティングテーブルにアドレスプレフィックスxを見つけることにより、パケットPの次のホップを決定します。つまり、特定のFECのパケットは、Rのルーティングテーブルの特定のアドレスプレフィックスに一致するパケットにすぎません。この場合、FECはアドレスプレフィックスで識別できます。
Note that a packet P may be assigned to FEC F, and FEC F may be identified with address prefix X, even if P's destination address does not match X.
Pの宛先アドレスがxと一致しない場合でも、パケットPがFEC Fに割り当てられ、FEC FはアドレスプレフィックスXで識別される場合があることに注意してください。
LSRs R1 and R2 are considered to be label distribution peers for address prefix X if and only if one of the following conditions holds:
LSRS R1とR2は、次の条件のいずれかが保持されている場合にのみ、アドレスプレフィックスxのラベル配布ピアであると見なされます。
1. R1's route to X is a route which it learned about via a particular instance of a particular IGP, and R2 is a neighbor of R1 in that instance of that IGP
1. R1のXへのルートは、特定のIGPの特定のインスタンスを介して学んだルートであり、R2はそのIGPのその場合にR1の隣です
2. R1's route to X is a route which it learned about by some instance of routing algorithm A1, and that route is redistributed into an instance of routing algorithm A2, and R2 is a neighbor of R1 in that instance of A2
2. R1のXへのルートは、ルーティングアルゴリズムA1のいくつかのインスタンスで学んだルートであり、そのルートはルーティングアルゴリズムA2のインスタンスに再配布され、R2はA2のそのインスタンスでR1の隣です。
3. R1 is the receive endpoint of an LSP Tunnel that is within another LSP, and R2 is a transmit endpoint of that tunnel, and R1 and R2 are participants in a common instance of an IGP, and are in the same IGP area (if the IGP in question has areas), and R1's route to X was learned via that IGP instance, or is redistributed by R1 into that IGP instance
3. R1は別のLSP内にあるLSPトンネルの受信エンドポイントであり、R2はそのトンネルの送信エンドポイントであり、R1とR2はIGPの一般的なインスタンスの参加者であり、同じIGP領域にあります（IGPの場合問題には領域があります）、そしてXへのR1のルートはそのIGPインスタンスを介して学習されたか、R1によってそのIGPインスタンスに再配布されました
4. R1's route to X is a route which it learned about via BGP, and R2 is a BGP peer of R1
4. R1のXへのルートは、BGPを介して学んだルートであり、R2はR1のBGPピアです
In general, these rules ensure that if the route to a particular address prefix is distributed via an IGP, the label distribution peers for that address prefix are the IGP neighbors. If the route to a particular address prefix is distributed via BGP, the label distribution peers for that address prefix are the BGP peers. In other cases of LSP tunneling, the tunnel endpoints are label distribution peers.
一般に、これらのルールは、特定のアドレスプレフィックスへのルートがIGPを介して配布される場合、そのアドレスプレフィックスのラベル分布ピアがIGPネイバーであることを保証します。特定のアドレスプレフィックスへのルートがBGPを介して配布される場合、そのアドレスプレフィックスのラベル配布ピアはBGPピアです。LSPトンネルの他の場合、トンネルのエンドポイントはラベル配布ピアです。
In order to use MPLS for the forwarding of packets according to the hop-by-hop route corresponding to any address prefix, each LSR MUST:
任意のアドレスプレフィックスに対応するホップバイホップルートに従ってパケットの転送にMPLを使用するには、各LSRが次のことが必要です。
1. bind one or more labels to each address prefix that appears in its routing table;
1. ルーティングテーブルに表示される各アドレスのプレフィックスに1つ以上のラベルをバインドします。
2. for each such address prefix X, use a label distribution protocol to distribute the binding of a label to X to each of its label distribution peers for X.
2. このようなアドレスのプレフィックスXごとに、ラベル分布プロトコルを使用して、Xのラベル分布ピアのそれぞれにラベルのバインディングを分配します。
There is also one circumstance in which an LSR must distribute a label binding for an address prefix, even if it is not the LSR which bound that label to that address prefix:
また、LSRがアドレスプレフィックスのラベルバインディングを配布しなければならない状況も1つあります。
3. If R1 uses BGP to distribute a route to X, naming some other LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has assigned label L to X, then R1 must distribute the binding between L and X to any BGP peer to which it distributes that route.
3. R1がBGPを使用してルートをXに分散し、他のLSR R2をBGPに次のHopに命名し、R1がラベルLをXに割り当てたことを知っている場合、R1はLとX間のバインディングを任意のBGPに分配する必要があります。そのルートを配布するピア。
These rules ensure that labels corresponding to address prefixes which correspond to BGP routes are distributed to IGP neighbors if and only if the BGP routes are distributed into the IGP. Otherwise, the labels bound to BGP routes are distributed only to the other BGP speakers.
これらの規則により、BGPルートに対応するアドレスのプレフィックスに対応するラベルが、BGPルートがIGPに分散されている場合にのみ、IGPネイバーに配布されることが保証されます。それ以外の場合、BGPルートにバインドされたラベルは、他のBGPスピーカーにのみ分布しています。
These rules are intended only to indicate which label bindings must be distributed by a given LSR to which other LSRs.
これらのルールは、どのラベルバインディングを他のLSRに配布する必要があるかを示すことのみを目的としています。
If the hop-by-hop path that packet P needs to follow is <R1, ..., Rn>, then <R1, ..., Rn> can be an LSP as long as:
パケットPが従う必要があるホップバイホップパスが<r1、...、rn>、<r1、...、rn>は次の場合、lspになります。
1. there is a single address prefix X, such that, for all i, 1<=i<n, X is the longest match in Ri's routing table for P's destination address;
1. 1つのアドレスプレフィックスxがあります。これにより、すべてのIで、1 <= i <n、xは、Pの宛先アドレスのRIのルーティングテーブルで最も長い一致です。
2. for all i, 1<i<n, Ri has assigned a label to X and distributed that label to R[i-1].
2. すべてのIについて、1 <i <n、riはxにラベルを割り当て、そのラベルをr [i-1]に分散しました。
Note that a packet's LSP can extend only until it encounters a router whose forwarding tables have a longer best match address prefix for the packet's destination address. At that point, the LSP must end and the best match algorithm must be performed again.
パケットのLSPは、転送テーブルがパケットの宛先アドレスにより長い一致アドレスプレフィックスを持っているルーターに遭遇するまでのみ拡張できることに注意してください。その時点で、LSPが終了する必要があり、最適な一致アルゴリズムを再度実行する必要があります。
Suppose, for example, that packet P, with destination address 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 advertises address prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is advertising an "aggregated route" to R1. In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC.
たとえば、宛先アドレス10.2.153.178を備えたパケットPがR1からR2に移動する必要があるとします。また、R2がアドレスのプレフィックス10.2/16からR1を宣伝するが、R3は10.2.153/23、10.2.154/23、10.2/16からR2を宣伝すると仮定します。つまり、R2はR1への「集計ルート」を宣伝しています。この状況では、パケットPをR2に達するまでラベルを切り替えることができますが、R2はルート集約を実行したため、PのFECを見つけるには最高の一致アルゴリズムを実行する必要があります。
An LSR R is considered to be an "LSP Egress" LSR for address prefix X if and only if one of the following conditions holds:
LSR rは、次の条件のいずれかが保持されている場合にのみ、アドレスプレフィックスxの「LSP Egress」LSRと見なされます。
1. R has an address Y, such that X is the address prefix in R's routing table which is the longest match for Y, or
1. rにはアドレスyがあり、xがrのルーティングテーブルのアドレスプレフィックスであり、yの最長の一致、または
2. R contains in its routing tables one or more address prefixes Y such that X is a proper initial substring of Y, but R's "LSP previous hops" for X do not contain any such address prefixes Y; that is, R is a "deaggregation point" for address prefix X.
2. rはルーティングテーブルに1つ以上のアドレスのプレフィックスyを含むようにxがyの適切な初期サブストリングであるが、xのrの「LSP以前のホップ」にはそのようなアドレスのプレフィックスyは含まれていない。つまり、rはアドレスプレフィックスXの「deaggregationポイント」です。
An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address prefix X if and only if:
LSR R1は、アドレスプレフィックスXの「LSPプロキシエグレス」LSRと見なされます。
1. R1's next hop for X is R2, and R1 and R2 are not label distribution peers with respect to X (perhaps because R2 does not support MPLS), or
1. R1の次のホップXはR2であり、R1とR2はXに関してラベル分布ピアではありません（おそらくR2はMPLSをサポートしていないため）、または
2. R1 has been configured to act as an LSP Proxy Egress for X
2. R1は、xのLSPプロキシ出口として機能するように構成されています
The definition of LSP allows for the LSP Egress to be a node which does not support MPLS; in this case the penultimate node in the LSP is the Proxy Egress.
LSPの定義により、LSP EgressはMPLSをサポートしないノードになります。この場合、LSPの最後から2番目のノードはプロキシエグレスです。
The Implicit NULL label is a label with special semantics which an LSR can bind to an address prefix. If LSR Ru, by consulting its ILM, sees that labeled packet P must be forwarded next to Rd, but that Rd has distributed a binding of Implicit NULL to the corresponding address prefix, then instead of replacing the value of the label on top of the label stack, Ru pops the label stack, and then forwards the resulting packet to Rd.
暗黙のヌルラベルは、LSRがアドレスプレフィックスにバインドできる特別なセマンティクスを備えたラベルです。LSR RuがILMを相談してRDの隣に標識されたパケットPを転送する必要があることを確認した場合、RDは暗黙のヌルのバインディングを対応するアドレスプレフィックスに分配している場合、その後、ラベルの値を置き換える代わりに、ラベルスタック、Ruはラベルスタックをポップし、結果のパケットをRDに転送します。
LSR Rd distributes a binding between Implicit NULL and an address prefix X to LSR Ru if and only if:
LSR RDは、暗黙のnullとアドレスのプレフィックスxからLSR ruへのバインディングを分配します。
1. the rules of Section 4.1.2 indicate that Rd distributes to Ru a label binding for X, and
1. セクション4.1.2のルールは、RDがXのラベルバインディングをRUに分配することを示しています。
2. Rd knows that Ru can support the Implicit NULL label (i.e., that it can pop the label stack), and
2. RDは、RUが暗黙のヌルラベルをサポートできることを知っています（つまり、ラベルスタックをポップできること）、および
3. Rd is an LSP Egress (not proxy egress) for X.
3. rdはxのLSP出力（プロキシエグレスではありません）です。
This causes the penultimate LSR on a LSP to pop the label stack. This is quite appropriate; if the LSP Egress is an MPLS Egress for X, then if the penultimate LSR does not pop the label stack, the LSP Egress will need to look up the label, pop the label stack, and then look up the next label (or look up the L3 address, if no more labels are present). By having the penultimate LSR pop the label stack, the LSP Egress is saved the work of having to look up two labels in order to make its forwarding decision.
これにより、LSPの最後から2番目のLSRがラベルスタックをポップします。これは非常に適切です。LSP EgressがXのMPLS Egressである場合、最後から2番目のLSRがラベルスタックをポップしない場合、LSP Egressはラベルを検索し、ラベルスタックをポップしてから次のラベルを調べる必要があります（または検索します（または検索します（または検索）L3アドレスは、これ以上ラベルが存在しない場合）。最後から2番目のLSR POPにラベルスタックにPOPにすることにより、LSP Egressは、転送の決定を下すために2つのラベルを調べなければならないという作業を節約されます。
However, if the penultimate LSR is an ATM switch, it may not have the capability to pop the label stack. Hence a binding of Implicit NULL may be distributed only to LSRs which can support that function.
ただし、最後から2番目のLSRがATMスイッチである場合、ラベルスタックをポップする機能がない場合があります。したがって、暗黙のヌルの結合は、その機能をサポートできるLSRにのみ分布することができます。
If the penultimate LSR in an LSP for address prefix X is an LSP Proxy Egress, it acts just as if the LSP Egress had distributed a binding of Implicit NULL for X.
アドレスプレフィックスXのLSPの最後から2番目のLSRがLSPプロキシエグレスである場合、まるでLSPの出口がxの暗黙のヌルの結合を分布しているかのように機能します。
There are situations in which an LSP Ingress, Ri, knows that packets of several different FECs must all follow the same LSP, terminating at, say, LSP Egress Re. In this case, proper routing can be achieved
LSP IngressのRIは、いくつかの異なるFECのパケットがすべて同じLSPを追跡し、たとえばLSP Egress REで終了する必要があることを知っている状況があります。この場合、適切なルーティングを達成できます
by using a single label for all such FECs; it is not necessary to have a distinct label for each FEC. If (and only if) the following conditions hold:
そのようなすべてのFECに単一のラベルを使用する。FECごとに明確なラベルを持つ必要はありません。次の条件が保持されている場合（および場合にのみ）。
1. the address of LSR Re is itself in the routing table as a "host route", and
1. LSR REのアドレスは、それ自体が「ホストルート」としてルーティングテーブルにあり、
2. there is some way for Ri to determine that Re is the LSP egress for all packets in a particular set of FECs
2. RIが特定のFECのセット内のすべてのパケットのLSP出力であると判断するには、何らかの方法があります。
Then Ri may bind a single label to all FECS in the set. This is known as "Egress-Targeted Label Assignment."
その後、RIはセット内のすべてのFECに単一のラベルをバインドできます。これは「出口標的ラベルの割り当て」として知られています。
How can LSR Ri determine that an LSR Re is the LSP Egress for all packets in a particular FEC? There are a number of possible ways:
LSR RIは、LSR REが特定のFEC内のすべてのパケットのLSP出力であるとどのように判断できますか？可能な方法はいくつかあります：
- If the network is running a link state routing algorithm, and all nodes in the area support MPLS, then the routing algorithm provides Ri with enough information to determine the routers through which packets in that FEC must leave the routing domain or area.
- ネットワークがリンク状態ルーティングアルゴリズムを実行し、エリア内のすべてのノードがMPLSをサポートしている場合、ルーティングアルゴリズムはRIに、そのFECのパケットがルーティングドメインまたはエリアを離れる必要があるルーターを決定するのに十分な情報をRIに提供します。
- If the network is running BGP, Ri may be able to determine that the packets in a particular FEC must leave the network via some particular router which is the "BGP Next Hop" for that FEC.
- ネットワークがBGPを実行している場合、RIは、特定のFECのパケットが、そのFECの「BGP Next Hop」である特定のルーターを介してネットワークを離れる必要があると判断できる場合があります。
- It is possible to use the label distribution protocol to pass information about which address prefixes are "attached" to which egress LSRs. This method has the advantage of not depending on the presence of link state routing.
- ラベル分布プロトコルを使用して、どのアドレスプレフィックスが「添付されている」かについて情報を渡すことができます。この方法には、リンク状態ルーティングの存在に依存しないという利点があります。
If egress-targeted label assignment is used, the number of labels that need to be supported throughout the network may be greatly reduced. This may be significant if one is using legacy switching hardware to do MPLS, and the switching hardware can support only a limited number of labels.
出力ターゲットラベルの割り当てが使用されている場合、ネットワーク全体でサポートする必要があるラベルの数が大幅に削減される場合があります。これは、MPLSを実行するためにレガシースイッチングハードウェアを使用している場合に重要な場合があり、スイッチングハードウェアは限られた数のラベルのみをサポートできます。
One possible approach would be to configure the network to use egress-targeted label assignment by default, but to configure particular LSRs to NOT use egress-targeted label assignment for one or more of the address prefixes for which it is an LSP egress. We impose the following rule:
考えられるアプローチの1つは、デフォルトで出口ターゲットのラベル割り当てを使用するようにネットワークを構成することですが、LSP Egressである1つ以上のアドレスプレフィックスに対してEugressターゲットラベル割り当てを使用しないように特定のLSRを構成することです。次のルールを課します。
- If a particular LSR is NOT an LSP Egress for some set of address prefixes, then it should assign labels to the address prefixes in the same way as is done by its LSP next hop for those address prefixes. That is, suppose Rd is Ru's LSP next
- 特定のLSRがアドレスプレフィックスのセットのLSP出力でない場合、LSPの次のアドレスプレフィックスの次のホップによって行われるのと同じ方法で、アドレスプレフィックスにラベルを割り当てる必要があります。つまり、rdが次のrspであると仮定します
hop for address prefixes X1 and X2. If Rd assigns the same label to X1 and X2, Ru should as well. If Rd assigns different labels to X1 and X2, then Ru should as well.
アドレスのプレフィックスX1およびX2をホップします。RDが同じラベルをX1とX2に割り当てる場合、RUも同様に必要です。RDが異なるラベルをX1とX2に割り当てる場合、RUも同様に必要です。
For example, suppose one wants to make egress-targeted label assignment the default, but to assign distinct labels to those address prefixes for which there are multiple possible LSP egresses (i.e., for those address prefixes which are multi-homed.) One can configure all LSRs to use egress-targeted label assignment, and then configure a handful of LSRs to assign distinct labels to those address prefixes which are multi-homed. For a particular multi-homed address prefix X, one would only need to configure this in LSRs which are either LSP Egresses or LSP Proxy Egresses for X.
たとえば、出力ターゲットのラベル割り当てをデフォルトにしたいのに、複数の可能なLSP出力があるアドレスプレフィックスに個別のラベルを割り当てることを望んでいるとします（つまり、マルチホームのアドレスプレフィックスに対して）。すべてのLSRは、出口ターゲットのラベル割り当てを使用し、複数のLSRを構成して、マルチホームのアドレスプレフィックスに異なるラベルを割り当てるように構成します。特定のマルチホームアドレスの接頭辞Xの場合、LSP EgressesまたはLSP Proxy EgressesのいずれかであるLSRでこれを構成する必要があります。
It is important to note that if Ru and Rd are adjacent LSRs in an LSP for X1 and X2, forwarding will still be done correctly if Ru assigns distinct labels to X1 and X2 while Rd assigns just one label to the both of them. This just means that R1 will map different incoming labels to the same outgoing label, an ordinary occurrence.
RUとRDがX1およびX2のLSPで隣接するLSRである場合、RUが異なるラベルをX1とX2に割り当てる場合、RUが両方に1つのラベルを割り当てる場合、転送はまだ正しく行われることに注意することが重要です。これは、R1が異なる着信ラベルを同じ発信ラベル、通常の発生にマッピングすることを意味します。
Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns to them both the label corresponding to the address of their LSP Egress or Proxy Egress, forwarding will still be done correctly. Ru will just map the incoming label to the label which Rd has assigned to the address of that LSP Egress.
同様に、RDが異なるラベルをX1とX2に割り当てるが、RUがLSP EgressまたはProxy Egressのアドレスに対応するラベルの両方をそれらに割り当てる場合、転送はまだ正しく行われます。Ruは、RDがそのLSP Egressのアドレスに割り当てたラベルに着信ラベルをマップするだけです。
There are a number of reasons why it may be desirable to use explicit routing instead of hop by hop routing. For example, this allows routes to be based on administrative policies, and allows the routes that LSPs take to be carefully designed to allow traffic engineering [MPLS-TRFENG].
ホップルーティングによるホップではなく、明示的なルーティングを使用することが望ましい理由はいくつかあります。たとえば、これにより、ルートは管理ポリシーに基づいており、LSPが取るルートを慎重に設計して交通工学[MPLS-Trfeng]を許可します。
In some situations, the network administrators may desire to forward certain classes of traffic along certain pre-specified paths, where these paths differ from the Hop-by-hop path that the traffic would ordinarily follow. This can be done in support of policy routing, or in support of traffic engineering. The explicit route may be a configured one, or it may be determined dynamically by some means, e.g., by constraint-based routing.
状況によっては、ネットワーク管理者は、特定のクラスのトラフィックを特定の事前に指定されたパスに沿って転送したい場合があります。これらのパスは、トラフィックが通常従うホップバイホップパスとは異なります。これは、ポリシールーティングをサポートするか、交通工学をサポートすることで実行できます。明示的なルートは、構成されたルートである場合があります。または、たとえば、制約ベースのルーティングにより、何らかの方法で動的に決定される場合があります。
MPLS allows this to be easily done by means of Explicitly Routed LSP Tunnels. All that is needed is:
MPLSを使用すると、これを明示的にルーティングされたLSPトンネルによって簡単に実行できます。必要なのは次のとおりです。
1. A means of selecting the packets that are to be sent into the Explicitly Routed LSP Tunnel;
1. 明示的にルーティングされたLSPトンネルに送られるパケットを選択する手段。
2. A means of setting up the Explicitly Routed LSP Tunnel;
2. 明示的にルーティングされたLSPトンネルを設定する手段。
3. A means of ensuring that packets sent into the Tunnel will not loop from the receive endpoint back to the transmit endpoint.
3. トンネルに送信されたパケットが受信エンドポイントから送信エンドポイントに戻らないようにする手段。
If the transmit endpoint of the tunnel wishes to put a labeled packet into the tunnel, it must first replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint. Then it must push on the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. To allow this, the tunnel endpoints should be explicit label distribution peers. The label bindings they need to exchange are of no interest to the LSRs along the tunnel.
トンネルの送信エンドポイントがラベル付きパケットをトンネルに入れたい場合、最初にスタックの上部のラベル値を、トンネルの受信エンドポイントによって分布したラベル値に置き換える必要があります。次に、トンネルに沿った次のホップによって分配されたトンネル自体に対応するラベルをプッシュする必要があります。これを許可するには、トンネルエンドポイントは明示的なラベル配布ピアである必要があります。交換する必要があるラベルのバインディングは、トンネルに沿ったLSRには興味がありません。
Suppose a particular LSR Re is an LSP proxy egress for 10 address prefixes, and it reaches each address prefix through a distinct interface.
特定のLSR REが10のアドレスプレフィックスのLSPプロキシエグレスであり、個別のインターフェイスを介して各アドレスプレフィックスに到達すると仮定します。
One could assign a single label to all 10 address prefixes. Then Re is an LSP egress for all 10 address prefixes. This ensures that packets for all 10 address prefixes get delivered to Re. However, Re would then have to look up the network layer address of each such packet in order to choose the proper interface to send the packet on.
10のアドレスプレフィックスすべてに単一のラベルを割り当てることができます。次に、REは10個すべてのアドレスプレフィックスのLSP出力です。これにより、10のアドレスプレフィックスすべてのパケットがREに配信されることが保証されます。ただし、REは、パケットを送信するための適切なインターフェイスを選択するために、各パケットのネットワークレイヤーアドレスを調べる必要があります。
Alternatively, one could assign a distinct label to each interface. Then Re is an LSP proxy egress for the 10 address prefixes. This eliminates the need for Re to look up the network layer addresses in order to forward the packets. However, it can result in the use of a large number of labels.
または、各インターフェイスに異なるラベルを割り当てることもできます。次に、REは10のアドレスプレフィックスのLSPプロキシエセスです。これにより、パケットを転送するためにネットワークレイヤーアドレスをREが検索する必要性がなくなります。ただし、多数のラベルを使用する可能性があります。
An alternative would be to bind all 10 address prefixes to the same level 1 label (which is also bound to the address of the LSR itself), and then to bind each address prefix to a distinct level 2 label. The level 2 label would be treated as an attribute of the level 1 label binding, which we call the "Stack Attribute". We impose the following rules:
別の方法では、10のアドレスのプレフィックスすべてを同じレベル1ラベル（LSR自体のアドレスにもバインドされている）にバインドし、各アドレスのプレフィックスを個別のレベル2ラベルにバインドすることです。レベル2ラベルは、「スタック属性」と呼ばれるレベル1ラベルバインディングの属性として扱われます。次のルールを課します。
- When LSR Ru initially labels a hitherto unlabeled packet, if the longest match for the packet's destination address is X, and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru a binding of label L1 to X, along with a stack attribute of L2, then
- LSR RUが当初、これまでのラベルのないパケットにラベルを付けた場合、パケットの宛先アドレスの最長の一致がXで、RuのLSP次のホップがXである場合、RDはRUにL1のラベルL1のバインディングに分配され、スタックとともにスタックが分配されました。L2の属性
1. Ru must push L2 and then L1 onto the packet's label stack, and then forward the packet to Rd;
1. RUはL2を押してから、L1をパケットのラベルスタックに押してから、パケットをRDに転送する必要があります。
2. When Ru distributes label bindings for X to its label distribution peers, it must include L2 as the stack attribute.
2. ruがxのラベルバインディングをラベル配布ピアに配布する場合、L2をスタック属性として含める必要があります。
3. Whenever the stack attribute changes (possibly as a result of a change in Ru's LSP next hop for X), Ru must distribute the new stack attribute.
3. スタック属性が変更されたときはいつでも（おそらくRuのLSPの次のHop for xの変更の結果として）、RUは新しいスタック属性を配布する必要があります。
Note that although the label value bound to X may be different at each hop along the LSP, the stack attribute value is passed unchanged, and is set by the LSP proxy egress.
LSPに沿った各ホップでxにバインドされたラベル値は異なる場合がありますが、スタック属性値は変更されず、LSPプロキシエグレスによって設定されていることに注意してください。
Thus the LSP proxy egress for X becomes an "implicit peer" with each other LSR in the routing area or domain. In this case, explicit peering would be too unwieldy, because the number of peers would become too large.
したがって、XのLSPプロキシエセスは、ルーティング領域またはドメインで互いのLSRとの「暗黙のピア」になります。この場合、ピアの数が大きくなるため、明示的なピアリングは扱いにくいでしょう。
If an LSR supports multiple routes for a particular stream, then it may assign multiple labels to the stream, one for each route. Thus the reception of a second label binding from a particular neighbor for a particular address prefix should be taken as meaning that either label can be used to represent that address prefix.
LSRが特定のストリームの複数のルートをサポートする場合、各ルートに1つは複数のラベルをストリームに割り当てることができます。したがって、特定のアドレスのプレフィックスの特定の隣の隣人からの2番目のラベルバインディングの受信は、いずれかのラベルを使用してそのアドレスプレフィックスを表すことができることを意味するものとみなす必要があります。
If multiple label bindings for a particular address prefix are specified, they may have distinct attributes.
特定のアドレスプレフィックスの複数のラベルバインディングが指定されている場合、それらは異なる属性を持っている場合があります。
Consider the case of packets P1 and P2, each of which has a destination address whose longest match, throughout a particular routing domain, is address prefix X. Suppose that the Hop-by-hop path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4, R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes this binding to R2. R2 binds label L2 to X, and distributes this binding to both R1 and R4. When R2 receives packet P1, its incoming label will be L2. R2 will overwrite L2 with L3, and send P1 to R3. When R2 receives packet P2, its incoming label will also be L2. R2 again overwrites L2 with L3, and send P2 on to R3.
パケットP1とP2のケースを考えてみましょう。それぞれには、特定のルーティングドメイン全体で最も長い一致がアドレスのプレフィックスXである宛先アドレスがあります。P1のホップバイホップパスは<R1、R2、R3>であると仮定します。、およびP2のホップバイホップパスは<R4、R2、R3>です。R3がラベルL3をXに結合し、このバインディングをR2に分配するとしましょう。R2はラベルL2をXに結合し、この結合をR1とR4の両方に分配します。R2がパケットP1を受信すると、その着信ラベルはL2になります。R2はL2をL3で上書きし、P1をR3に送信します。R2がパケットP2を受信すると、その着信ラベルもL2になります。R2は再びL2をL3で上書きし、R3にP2を送信します。
Note then that when P1 and P2 are traveling from R2 to R3, they carry the same label, and as far as MPLS is concerned, they cannot be distinguished. Thus instead of talking about two distinct LSPs, <R1,
次に、P1とP2がR2からR3に移動している場合、それらは同じラベルを持ち、MPLSに関する限り、それらは区別できないことに注意してください。したがって、2つの異なるLSPについて話す代わりに、<r1、
R2, R3> and <R4, R2, R3>, we might talk of a single "Multipoint-to-Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>.
R2、R3>および<R4、R2、R3>、単一の「マルチポイントツーポイントLSPツリー」について話すことができます。
This creates a difficulty when we attempt to use conventional ATM switches as LSRs. Since conventional ATM switches do not support multipoint-to-point connections, there must be procedures to ensure that each LSP is realized as a point-to-point VC. However, if ATM switches which do support multipoint-to-point VCs are in use, then the LSPs can be most efficiently realized as multipoint-to-point VCs. Alternatively, if the SVP Multipoint Encoding (section 3.25.2) can be used, the LSPs can be realized as multipoint-to-point SVPs.
これにより、従来のATMスイッチをLSRSとして使用しようとすると、困難が生じます。従来のATMスイッチはマルチポイントからポイントへの接続をサポートしていないため、各LSPがポイントツーポイントVCとして実現されることを確認する手順が必要です。ただし、マルチポイントツーポイントVCSをサポートするATMスイッチが使用されている場合、LSPはマルチポイントツーポイントVCとして最も効率的に実現できます。または、SVPマルチポイントエンコード（セクション3.25.2）を使用できる場合、LSPはマルチポイントツーポイントSVPとして実現できます。
Consider the case of an Autonomous System, A, which carries transit traffic between other Autonomous Systems. Autonomous System A will have a number of BGP Border Routers, and a mesh of BGP connections among them, over which BGP routes are distributed. In many such cases, it is desirable to avoid distributing the BGP routes to routers which are not BGP Border Routers. If this can be avoided, the "route distribution load" on those routers is significantly reduced. However, there must be some means of ensuring that the transit traffic will be delivered from Border Router to Border Router by the interior routers.
他の自律システム間のトランジットトラフィックを運ぶ自律システムAの場合を考慮してください。自律システムAには、多くのBGPボーダールーターと、それらの間のBGP接続のメッシュがあり、その上にBGPルートが分布しています。そのような多くの場合、BGPボーダールーターではないルーターにBGPルートを配布することを避けることが望ましいです。これを回避できれば、これらのルーターの「ルート分布負荷」が大幅に減少します。ただし、輸送トラフィックが内部ルーターによってボーダールーターからボーダールーターに配信されるようにするための何らかの手段が必要です。
This can easily be done by means of LSP Tunnels. Suppose that BGP routes are distributed only to BGP Border Routers, and not to the interior routers that lie along the Hop-by-hop path from Border Router to Border Router. LSP Tunnels can then be used as follows:
これは、LSPトンネルによって簡単に実行できます。BGPルートは、BGPボーダールーターにのみ分布しており、ボーダールーターからボーダールーターまでのホップバイホップパスに沿って横たわっている内部ルーターには分布していないとします。LSPトンネルは次のように使用できます。
1. Each BGP Border Router distributes, to every other BGP Border Router in the same Autonomous System, a label for each address prefix that it distributes to that router via BGP.
1. 各BGPボーダールーターは、同じ自律システム内の他のすべてのBGPボーダールーターに分配されます。各アドレスプレフィックスのラベルは、BGPを介してそのルーターに分布しています。
2. The IGP for the Autonomous System maintains a host route for each BGP Border Router. Each interior router distributes its labels for these host routes to each of its IGP neighbors.
2. 自律システムのIGPは、各BGPボーダールーターのホストルートを維持します。各インテリアルーターは、これらのホストルートのラベルを各IGPネイバーに配布しています。
3. Suppose that:
3. 仮定：
a) BGP Border Router B1 receives an unlabeled packet P,
a) BGPボーダールーターB1は、ラベルのないパケットPを受け取ります。
b) address prefix X in B1's routing table is the longest match for the destination address of P,
b) B1のルーティングテーブルのアドレスプレフィックスXは、Pの宛先アドレスで最も長い一致です。
c) the route to X is a BGP route,
c) XへのルートはBGPルートです。
d) the BGP Next Hop for X is B2,
d) Xの次のホップはB2です。
e) B2 has bound label L1 to X, and has distributed this binding to B1,
e) B2はラベルL1をXにバインドしており、このバインディングをB1に分布させています。
f) the IGP next hop for the address of B2 is I1,
f) B2のアドレスのIGP次のホップはI1です。
g) the address of B2 is in B1's and I1's IGP routing tables as a host route, and
g) B2のアドレスは、ホストルートとしてB1およびI1のIGPルーティングテーブルにあり、
h) I1 has bound label L2 to the address of B2, and distributed this binding to B1.
h) I1はラベルL2をB2のアドレスにバインドし、この結合をB1に分布させました。
Then before sending packet P to I1, B1 must create a label stack for P, then push on label L1, and then push on label L2.
その後、パケットPをi1に送信する前に、B1はPのラベルスタックを作成し、ラベルL1を押してからラベルL2を押してください。
4. Suppose that BGP Border Router B1 receives a labeled Packet P, where the label on the top of the label stack corresponds to an address prefix, X, to which the route is a BGP route, and that conditions 3b, 3c, 3d, and 3e all hold. Then before sending packet P to I1, B1 must replace the label at the top of the label stack with L1, and then push on label L2.
4. BGP Border Router B1がラベル付きパケットPを受信し、ラベルスタックの上部にあるラベルがアドレスプレフィックスXに対応していると仮定します。すべてが保持されます。その後、パケットPをi1に送信する前に、B1はラベルスタックの上部にあるラベルをL1に置き換え、ラベルL2をプッシュする必要があります。
With these procedures, a given packet P follows a level 1 LSP all of whose members are BGP Border Routers, and between each pair of BGP Border Routers in the level 1 LSP, it follows a level 2 LSP.
これらの手順を使用すると、特定のパケットPはレベル1 LSPに続き、そのメンバーはすべてBGPボーダールーターであり、レベル1 LSPのBGPボーダールーターの各ペア間で、レベル2 LSPに従います。
These procedures effectively create a Hop-by-Hop Routed LSP Tunnel between the BGP Border Routers.
これらの手順は、BGPボーダールーターの間にホップバイホップルーティングLSPトンネルを効果的に作成します。
Since the BGP border routers are exchanging label bindings for address prefixes that are not even known to the IGP routing, the BGP routers should become explicit label distribution peers with each other.
BGPボーダールーターは、IGPルーティングにさえ知られていないアドレスプレフィックスのラベルバインディングを交換しているため、BGPルーターは明示的なラベル配布ピアになるはずです。
It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels between two BGP Border Routers, even if they are not in the same Autonomous System. Suppose, for example, that B1 and B2 are in AS 1. Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally, suppose that B2 and B3 are on some network which is common to both Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP tunnel can be set up directly between B1 and B3 as follows:
同じ自律システムにない場合でも、2つのBGPボーダールーターの間にホップバイホップルーティングされたLSPトンネルを作成することができる場合があります。たとえば、B1とB2が1にあると仮定します。B3がB2のEBGP隣接であり、AS2にあると仮定します。最後に、B2とB3が両方の自律システム（「非武装ゾーン」）に共通するいくつかのネットワーク上にあると仮定します。この場合、次のようにLSPトンネルをB1とB3の間に直接セットアップできます。
- B3 distributes routes to B2 (using EBGP), optionally assigning labels to address prefixes;
- B3はルートをB2（EBGPを使用して）に分配し、オプションでラベルを割り当てて接頭辞を処理します。
- B2 redistributes those routes to B1 (using IBGP), indicating that the BGP next hop for each such route is B3. If B3 has assigned labels to address prefixes, B2 passes these labels along, unchanged, to B1.
- B2は、これらのルートをB1（IBGPを使用して）に再配置し、そのようなルートごとのBGPがB3であることを示しています。B3がプレフィックスに対処するためにラベルを割り当てた場合、B2はこれらのラベルを変更してB1に渡します。
- The IGP of AS1 has a host route for B3.
- AS1のIGPには、B3のホストルートがあります。
The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels between BGP Next Hops. Any situation in which one might otherwise have used an encapsulation tunnel is one in which it is appropriate to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the packet with a new header whose destination address is the address of the tunnel's receive endpoint, the label corresponding to the address prefix which is the longest match for the address of the tunnel's receive endpoint is pushed on the packet's label stack. The packet which is sent into the tunnel may or may not already be labeled.
ホップバイホップルーティングされたLSPトンネルの使用は、BGPの次のホップ間のトンネルに限定されません。そうでなければ、カプセル化トンネルを使用した可能性のある状況は、ホップバイホップルーティングLSPトンネルを使用することが適切な状況です。宛先アドレスがトンネルの受信エンドポイントのアドレスである新しいヘッダーでパケットをカプセル化する代わりに、トンネルの受信エンドポイントのアドレスの最長一致であるアドレスプレフィックスに対応するラベルは、パケットのラベルスタックにプッシュされます。トンネルに送信されるパケットには、ラベルが付けられている場合とされていない場合があります。
If the transmit endpoint of the tunnel wishes to put a labeled packet into the tunnel, it must first replace the label value at the top of the stack with a label value that was distributed to it by the tunnel's receive endpoint. Then it must push on the label which corresponds to the tunnel itself, as distributed to it by the next hop along the tunnel. To allow this, the tunnel endpoints should be explicit label distribution peers. The label bindings they need to exchange are of no interest to the LSRs along the tunnel.
トンネルの送信エンドポイントがラベル付きパケットをトンネルに入れたい場合、最初にスタックの上部のラベル値を、トンネルの受信エンドポイントによって分布したラベル値に置き換える必要があります。次に、トンネルに沿った次のホップによって分配されたトンネル自体に対応するラベルをプッシュする必要があります。これを許可するには、トンネルエンドポイントは明示的なラベル配布ピアである必要があります。交換する必要があるラベルのバインディングは、トンネルに沿ったLSRには興味がありません。
Multicast routing proceeds by constructing multicast trees. The tree along which a particular multicast packet must get forwarded depends in general on the packet's source address and its destination address. Whenever a particular LSR is a node in a particular multicast tree, it binds a label to that tree. It then distributes that binding to its parent on the multicast tree. (If the node in question is on a LAN, and has siblings on that LAN, it must also distribute the binding to its siblings. This allows the parent to use a single label value when multicasting to all children on the LAN.)
マルチキャストルーティングは、マルチキャストツリーを構築することで収益を上げます。特定のマルチキャストパケットが転送されなければならないツリーは、一般的にパケットのソースアドレスとその宛先アドレスに依存します。特定のLSRが特定のマルチキャストツリーのノードであるときはいつでも、そのツリーにラベルをバインドします。次に、マルチキャストツリーの親にその結合を分配します。（問題のノードがLAN上にあり、そのLANに兄弟がある場合、兄弟にバインディングを分配する必要があります。これにより、親はLANのすべての子供にマルチリキャストするときに単一のラベル値を使用できます。）
When a multicast labeled packet arrives, the NHLFE corresponding to the label indicates the set of output interfaces for that packet, as well as the outgoing label. If the same label encoding technique is used on all the outgoing interfaces, the very same packet can be sent to all the children.
マルチキャストラベル付きパケットが到着すると、ラベルに対応するNHLFEは、そのパケットの出力インターフェイスのセットと発信ラベルを示します。同じラベルエンコーディング手法がすべての発信インターフェイスで使用されている場合、まったく同じパケットをすべての子供に送信できます。
In this section, we consider only label bindings that are used for traffic to be label switched along its hop-by-hop routed path. In these cases, the label in question will correspond to an address prefix in the routing table.
このセクションでは、トラフィックがホップバイホップルーティングパスに沿ってラベルを切り替えるために使用されるラベルバインディングのみを検討します。これらの場合、問題のラベルは、ルーティングテーブルのアドレスプレフィックスに対応します。
There are a number of different procedures that may be used to distribute label bindings. Some are executed by the downstream LSR, and some by the upstream LSR.
ラベルバインディングの分布に使用できるさまざまな手順があります。下流のLSRによって実行されるものもあり、一部は上流のLSRによって実行されます。
The downstream LSR must perform:
ダウンストリームLSRは実行する必要があります。
- The Distribution Procedure, and
- 分布手順、および
- the Withdrawal Procedure.
- 撤退手順。
The upstream LSR must perform:
上流のLSRは実行する必要があります。
- The Request Procedure, and
- リクエスト手順、および
- the NotAvailable Procedure, and
- Notabable Procedure、および
- the Release Procedure, and
- リリース手順、および
- the labelUse Procedure.
- ラベルース手順。
The MPLS architecture supports several variants of each procedure.
MPLSアーキテクチャは、各手順のいくつかのバリエーションをサポートしています。
However, the MPLS architecture does not support all possible combinations of all possible variants. The set of supported combinations will be described in section 5.2, where the interoperability between different combinations will also be discussed.
ただし、MPLSアーキテクチャは、考えられるすべてのバリアントのすべての可能な組み合わせをサポートするものではありません。サポートされている組み合わせのセットについては、セクション5.2で説明します。ここでは、異なる組み合わせ間の相互運用性についても説明します。
The Distribution Procedure is used by a downstream LSR to determine when it should distribute a label binding for a particular address prefix to its label distribution peers. The architecture supports four different distribution procedures.
分布手順は、下流のLSRによって使用され、特定のアドレスのプレフィックスのラベルバインディングをラベル配布ピアに配布する時期を決定します。アーキテクチャは、4つの異なる配布手順をサポートしています。
Irrespective of the particular procedure that is used, if a label binding for a particular address prefix has been distributed by a downstream LSR Rd to an upstream LSR Ru, and if at any time the attributes (as defined above) of that binding change, then Rd must inform Ru of the new attributes.
使用されている特定の手順に関係なく、特定のアドレスプレフィックスのラベルバインディングが下流のLSR RDによって上流のLSR RUに分散されている場合、およびその結合変化の属性（上記の）の属性（上記）の場合、RDは、RUに新しい属性を通知する必要があります。
If an LSR is maintaining multiple routes to a particular address prefix, it is a local matter as to whether that LSR binds multiple labels to the address prefix (one per route), and hence distributes multiple bindings.
LSRが特定のアドレスプレフィックスに複数のルートを維持している場合、LSRが複数のラベルをアドレスプレフィックス（ルートごとに1つ）にバインドするため、複数のバインディングを分散するかどうかについてのローカル問題です。
Let Rd be an LSR. Suppose that:
rdをLSRとします。仮定：
1. X is an address prefix in Rd's routing table
1. XはRDのルーティングテーブルのアドレスプレフィックスです
2. Ru is a label distribution peer of Rd with respect to X
2. ruはxに対してRDのラベル配布ピアです
Whenever these conditions hold, Rd must bind a label to X and distribute that binding to Ru. It is the responsibility of Rd to keep track of the bindings which it has distributed to Ru, and to make sure that Ru always has these bindings.
これらの条件が保持されるたびに、RDはラベルをXにバインドし、そのバインディングをRUに分配する必要があります。RDに分配されたバインディングを追跡し、Ruが常にこれらのバインディングを持っていることを確認することは、RDの責任です。
This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Independent LSP Control Mode.
この手順は、独立したLSP制御モードで未承諾のダウンストリームラベル割り当てを実行しているLSRによって使用されます。
Let Rd be an LSR. Suppose that:
rdをLSRとします。仮定：
1. X is an address prefix in Rd's routing table
1. XはRDのルーティングテーブルのアドレスプレフィックスです
2. Ru is a label distribution peer of Rd with respect to X
2. ruはxに対してRDのラベル配布ピアです
3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd.
3. RDはXのLSP出力またはLSPプロキシエグレスのいずれか、またはrdのL3の次のホップはXです。RNはRUとは異なり、RNはラベルをXにバインドし、その結合をRDに分布させました。
Then as soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru.
その後、これらの条件がすべて保持されるとすぐに、RDはラベルをXにバインドし、そのバインディングをRUに分配する必要があります。
Whereas PushUnconditional causes the distribution of label bindings for all address prefixes in the routing table, PushConditional causes the distribution of label bindings only for those address prefixes for which one has received label bindings from one's LSP next hop, or for which one does not have an MPLS-capable L3 next hop.
Pushuncontionalは、ルーティングテーブルのすべてのアドレスプレフィックスのラベルバインディングの分布を引き起こしますが、プッシュコンディショナルは、次のホップからラベルバインディングを受け取った、または自分が持っていないアドレスバインディングを受信したアドレスのプレフィックスのみのラベルバインディングの分布を引き起こします。MPLS対応L3次のホップ。
This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Ordered LSP Control Mode.
この手順は、順序付けられたLSP制御モードで未承諾のダウンストリームラベル割り当てを実行しているLSRによって使用されます。
Let Rd be an LSR. Suppose that:
rdをLSRとします。仮定：
1. X is an address prefix in Rd's routing table
1. XはRDのルーティングテーブルのアドレスプレフィックスです
2. Ru is a label distribution peer of Rd with respect to X
2. ruはxに対してRDのラベル配布ピアです
3. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru
3. Ruは、RDがラベルをXにバインドし、バインディングをRUに分配することを明示的に要求しました
Then Rd should bind a label to X and distribute that binding to Ru. Note that if X is not in Rd's routing table, or if Rd is not a label distribution peer of Ru with respect to X, then Rd must inform Ru that it cannot provide a binding at this time.
次に、RDはラベルをXにバインドし、そのバインディングをRUに分配する必要があります。XがRDのルーティングテーブルにない場合、またはRDがXに関してRUのラベル分布ピアでない場合、RDはRUに現時点でバインディングを提供できないことを通知する必要があることに注意してください。
If Rd has already distributed a binding for address prefix X to Ru, and it receives a new request from Ru for a binding for address prefix X, it will bind a second label, and distribute the new binding to Ru. The first label binding remains in effect.
RDが既にアドレスのプレフィックスXのバインディングをRUに配布しており、アドレスプレフィックスXのバインディングの新しい要求をRUから受信している場合、2番目のラベルにバインドされ、新しいバインディングをRUに分配します。最初のラベル結合は引き続き有効です。
This procedure would be used by LSRs performing downstream-on-demand label distribution using the Independent LSP Control Mode.
この手順は、独立したLSP制御モードを使用して、下流オンデマンドラベル分布を実行するLSRによって使用されます。
Let Rd be an LSR. Suppose that:
rdをLSRとします。仮定：
1. X is an address prefix in Rd's routing table
1. XはRDのルーティングテーブルのアドレスプレフィックスです
2. Ru is a label distribution peer of Rd with respect to X
2. ruはxに対してRDのラベル配布ピアです
3. Ru has explicitly requested that Rd bind a label to X and distribute the binding to Ru
3. Ruは、RDがラベルをXにバインドし、バインディングをRUに分配することを明示的に要求しました
4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and Rn has bound a label to X and distributed that binding to Rd
4. RDはXのLSP出力またはLSPプロキシエグレスのいずれか、またはRDのL3の次のホップはXです。RNはRUとは異なり、RNはラベルをXにバインドし、RDへのバインディングを分布させました
Then as soon as these conditions all hold, Rd should bind a label to X and distribute that binding to Ru. Note that if X is not in Rd's routing table and a binding for X is not obtainable via Rd's next hop for X, or if Rd is not a label distribution peer of Ru with respect to X, then Rd must inform Ru that it cannot provide a binding at this time.
その後、これらの条件がすべて保持されるとすぐに、RDはラベルをXにバインドし、そのバインディングをRUに分配する必要があります。XがRDのルーティングテーブルにない場合、XのバインディングがRDの次のホップを介して取得できない場合、またはRDがXに関してRUのラベル分布ピアではない場合、RDはRUに提供できないことを通知する必要があります。この時点でのバインディング。
However, if the only condition that fails to hold is that Rn has not yet provided a label to Rd, then Rd must defer any response to Ru until such time as it has receiving a binding from Rn.
ただし、保持できない唯一の条件がRNがまだRDにラベルを提供していないということである場合、RDはRNからバインディングを受けるまでRUへの応答を延期する必要があります。
If Rd has distributed a label binding for address prefix X to Ru, and at some later time, any attribute of the label binding changes, then Rd must redistribute the label binding to Ru, with the new attribute. It must do this even though Ru does not issue a new Request.
RDがアドレスプレフィックスXのラベルバインディングをRUに配布し、後でラベルバインディングの属性を変更した場合、RDは新しい属性を使用してRUにラベルバインディングを再配布する必要があります。RUが新しいリクエストを発行していない場合でも、これを行う必要があります。
This procedure would be used by LSRs that are performing downstream-on-demand label allocation in the Ordered LSP Control Mode.
この手順は、順序付けられたLSP制御モードで下流の需要ラベル割り当てを実行しているLSRによって使用されます。
In section 5.2, we will discuss how to choose the particular procedure to be used at any given time, and how to ensure interoperability among LSRs that choose different procedures.
セクション5.2では、いつでも使用する特定の手順を選択する方法と、異なる手順を選択するLSR間の相互運用性を確保する方法について説明します。
The Request Procedure is used by the upstream LSR for an address prefix to determine when to explicitly request that the downstream LSR bind a label to that prefix and distribute the binding. There are three possible procedures that can be used.
リクエスト手順は、上流のLSRによってアドレスプレフィックスに使用され、下流のLSRがラベルをそのプレフィックスに結合してバインディングを配布することを明示的に要求するタイミングを決定する時期を決定する時期を決定します。使用できる3つの手順があります。
Never make a request. This is useful if the downstream LSR uses the PushConditional procedure or the PushUnconditional procedure, but is not useful if the downstream LSR uses the PulledUnconditional procedure or the the PulledConditional procedures.
リクエストをしないでください。これは、下流のLSRがプッシュコンディショナル手順またはプッシュコンディショナル手順を使用している場合に役立ちますが、下流のLSRがプルドンコンディショナル手順またはプル条件手順を使用する場合は役に立ちません。
This procedure would be used by an LSR when unsolicited downstream label distribution and Liberal Label Retention Mode are being used.
この手順は、未承諾のダウンストリームラベル分布とリベラルラベル保持モードが使用されている場合、LSRによって使用されます。
Make a request whenever the L3 next hop to the address prefix changes, or when a new address prefix is learned, and one doesn't already have a label binding from that next hop for the given address prefix.
L3がアドレスのプレフィックスを変更するとき、または新しいアドレスプレフィックスが学習されたときに、次のアドレスのプレフィックスの次のホップからバインディングされていない場合、L3が次のアドレスプレフィックスに登場するときはいつでもリクエストを行います。
This procedure would be used by an LSR whenever Conservative Label Retention Mode is being used.
この手順は、保守的なラベル保持モードが使用されている場合はいつでもLSRによって使用されます。
Issue a request whenever a request is received, in addition to issuing a request when needed (as described in section 5.1.2.2). If Ru is not capable of being an LSP ingress, it may issue a request only when it receives a request from upstream.
必要に応じてリクエストを発行することに加えて、リクエストが受信されるたびにリクエストを発行します（セクション5.1.2.2で説明します）。ruがLSPイングレスであることができない場合、上流からリクエストを受信した場合にのみリクエストを発行する場合があります。
If Rd receives such a request from Ru, for an address prefix for which Rd has already distributed Ru a label, Rd shall assign a new (distinct) label, bind it to X, and distribute that binding. (Whether Rd can distribute this binding to Ru immediately or not depends on the Distribution Procedure being used.)
RDがRUからそのようなリクエストを受け取った場合、RDがすでにRU Aラベルを配布しているアドレスプレフィックスについては、RDは新しい（異なる）ラベルを割り当て、Xにバインドし、その結合を配布するものとします。（RDがこのバインディングをすぐにRUに分配できるかどうかは、使用されている分布手順に依存します。）
This procedure would be used by an LSR which is doing downstream-on-demand label distribution, but is not doing label merging, e.g., an ATM-LSR which is not capable of VC merge.
この手順は、下流のデマンドラベル分布を実行しているLSRによって使用されますが、VCマージができないATM-LSRなどのラベルマージを行っていません。
If Ru and Rd are respectively upstream and downstream label distribution peers for address prefix X, and Rd is Ru's L3 next hop for X, and Ru requests a binding for X from Rd, but Rd replies that it cannot provide a binding at this time, because it has no next hop for X, then the NotAvailable procedure determines how Ru responds. There are two possible procedures governing Ru's behavior:
RUとRDがそれぞれ上流および下流のラベル配布ピアであるアドレスプレフィックスXの場合、RDがRUの次のホップである場合、RUはRDからXのバインディングを要求しますが、RDは現時点ではバインディングを提供できないと答えます。Xの次のホップがないため、Notabable ProcedureはRUの応答方法を決定します。Ruの行動を管理する2つの手順があります。
Ru should issue the request again at a later time. That is, the requester is responsible for trying again later to obtain the needed binding. This procedure would be used when downstream-on-demand label distribution is used.
RUは後で再度リクエストを発行する必要があります。つまり、要求者は、後で必要なバインディングを取得するために後で再試行する責任があります。この手順は、下流のデマンドラベル分布を使用する場合に使用されます。
Ru should never reissue the request, instead assuming that Rd will provide the binding automatically when it is available. This is useful if Rd uses the PushUnconditional procedure or the PushConditional procedure, i.e., if unsolicited downstream label distribution is used.
RUは、RDが利用可能なときにバインディングを自動的に提供すると仮定する代わりに、リクエストを再発行しないでください。これは、RDがプッシュコンディショナル手順またはプッシュコンディショナル手順を使用する場合、つまり、未承諾のダウンストリームラベル分布を使用する場合に役立ちます。
Note that if Rd replies that it cannot provide a binding to Ru, because of some error condition, rather than because Rd has no next hop, the behavior of Ru will be governed by the error recovery conditions of the label distribution protocol, rather than by the NotAvailable procedure.
RDが次のホップがないためではなく、ある程度のエラー条件のためにRUにバインディングできないと答えた場合、RUの動作は、ラベル分布プロトコルのエラー回復条件によって支配されることに注意してください。記述可能な手順。
Suppose that Rd is an LSR which has bound a label to address prefix X, and has distributed that binding to LSR Ru. If Rd does not happen to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's L3 next hop for address prefix X, then Ru will not be using the label. The Release Procedure determines how Ru acts in this case. There are two possible procedures governing Ru's behavior:
RDは、プレフィックスXに対処するためにラベルをバインドし、その結合をLSR RUに分布させたLSRであると仮定します。RDがRUのL3 Next HopのアドレスプレフィックスXの次のホップではない場合、またはアドレスプレフィックスXのRUのL3 Next Hopでなくなった場合、RUはラベルを使用しません。リリース手順は、この場合にRUがどのように作用するかを決定します。Ruの行動を管理する2つの手順があります。
Ru should release the binding, and inform Rd that it has done so. This procedure would be used to implement Conservative Label Retention Mode.
RUはバインディングを解放し、RDにそうしていることを通知する必要があります。この手順は、保守的なラベル保持モードを実装するために使用されます。
Ru should maintain the binding, so that it can use it again immediately if Rd later becomes Ru's L3 next hop for X. This procedure would be used to implement Liberal Label Retention Mode.
RUはバインディングを維持する必要があります。これにより、RDが後でRUのL3 Next Hop for Xの場合にすぐに再度使用できます。この手順は、リベラルラベル保持モードを実装するために使用されます。
Suppose Ru is an LSR which has received label binding L for address prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and in fact Rd is Ru's L3 next hop for X.
RUがLSR RDのアドレスプレフィックスXに対してラベルバインディングLを受け取ったLSRであり、RuはXに対してRDの上流であり、実際にRDはXの次のHopです。
Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop for X, Ru does not make any use of the binding at that time. Ru may however start using the binding at some later time, if Rd becomes Ru's L3 next hop for X.
RDがXの次のホップである場合、RUはバインディングを使用します。バインディングがRUのl3である場合、RDがXの次のホップではない場合、RUはそのバインディングを使用しません。時間。しかし、RDがXの次のホップにRDになった場合、RUは後半にバインディングを使用し始める可能性があります。
The labelUse Procedure determines just how Ru makes use of Rd's binding.
ラベルース手順は、RUがRDの結合をどのように使用するかを決定します。
There are two procedures which Ru may use:
RUが使用できる2つの手順があります。
Ru may put the binding into use immediately. At any time when Ru has a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will also be Ru's LSP next hop for X. This procedure is used when loop detection is not in use.
RUは、バインディングをすぐに使用することができます。RuがRDからXのバインディングを持ち、RDがRUのL3 Next Hop for Xのバインディングを持っているときはいつでも、RDはRUのLSP Next Hop for Xです。この手順は、ループ検出が使用されていない場合に使用されます。
This procedure is the same as UseImmediate, unless Ru has detected a loop in the LSP. If a loop has been detected, Ru will discontinue the use of label L for forwarding packets to Rd.
この手順は、ruがLSPでループを検出しない限り、useimmediateと同じです。ループが検出された場合、RuはパケットをRDに転送するためのラベルLの使用を中止します。
This procedure is used when loop detection is in use.
この手順は、ループ検出が使用されているときに使用されます。
This will continue until the next hop for X changes, or until the loop is no longer detected.
これは、Xの次のホップが変更されるまで、またはループが検出されなくなるまで続きます。
In this case, there is only a single procedure.
この場合、単一の手順しかありません。
When LSR Rd decides to break the binding between label L and address prefix X, then this unbinding must be distributed to all LSRs to which the binding was distributed.
LSR RDがラベルLとアドレスプレフィックスXの間のバインディングを破ることを決定した場合、このバインディングは、バインディングが分布しているすべてのLSRに分布する必要があります。
It is required that the unbinding of L from X be distributed by Rd to a LSR Ru before Rd distributes to Ru any new binding of L to any other address prefix Y, where X != Y. If Ru were to learn of the new binding of L to Y before it learned of the unbinding of L from X, and if packets matching both X and Y were forwarded by Ru to Rd, then for a period of time, Ru would label both packets matching X and packets matching Y with label L.
Xからのlのバインディングをrdによってlsr ruに分布する前に、rdがrの新しいバインディングを他のアドレスプレフィックスyにRUに分配する必要があります。ここで、x！= y。LからYのxからのlのバインディングを知った前、xとyの両方を一致させるパケットがRuにruに転送された場合、しばらくの間、ruはxとyとラベルを一致させるパケットの両方のパケットにラベルを付けます。L.
The distribution and withdrawal of label bindings is done via a label distribution protocol. All label distribution protocols require that a label distribution adjacency be established between two label distribution peers (except implicit peers). If LSR R1 has a label distribution adjacency to LSR R2, and has received label bindings from LSR R2 via that adjacency, then if adjacency is brought down by either peer (whether as a result of failure or as a matter of normal operation), all bindings received over that adjacency must be considered to have been withdrawn.
ラベルバインディングの分布と撤回は、ラベル分布プロトコルを介して行われます。すべてのラベル分布プロトコルでは、2つのラベル配布ピア（暗黙のピアを除く）の間にラベル分布隣接を確立する必要があります。LSR R1がLSR R2へのラベル分布隣接性を持ち、その隣接を介してLSR R2からラベルバインディングを受け取った場合、隣接がピアによって削減される場合（失敗の結果または通常の操作の問題として）、すべてその隣接を介して受け取ったバインディングは、撤回されたと見なされなければなりません。
As long as the relevant label distribution adjacency remains in place, label bindings that are withdrawn must always be withdrawn explicitly. If a second label is bound to an address prefix, the result is not to implicitly withdraw the first label, but to bind both labels; this is needed to support multi-path routing. If a second address prefix is bound to a label, the result is not to implicitly withdraw the binding of that label to the first address prefix, but to use that label for both address prefixes.
関連するラベル分布の隣接性が残っている限り、撤回されるラベルバインディングは常に明示的に撤回する必要があります。2番目のラベルがアドレスプレフィックスにバインドされている場合、結果は最初のラベルを暗黙的に撤回するのではなく、両方のラベルをバインドすることです。これは、マルチパスルーティングをサポートするために必要です。2番目のアドレスプレフィックスがラベルにバインドされている場合、結果は、そのラベルのバインディングを最初のアドレスプレフィックスに暗黙的に撤回するのではなく、両方のアドレスプレフィックスにそのラベルを使用することになります。
Consider two LSRs, Ru and Rd, which are label distribution peers with respect to some set of address prefixes, where Ru is the upstream peer and Rd is the downstream peer.
2つのLSR、RUとRDを考えてみましょう。RUとRDは、いくつかのアドレスプレフィックスに関するラベル配布ピアであり、RUは上流のピアであり、RDは下流のピアです。
The MPLS scheme which governs the interaction of Ru and Rd can be described as a quintuple of procedures: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. (Since there is only one Withdraw Procedure, it need not be mentioned.) A "*" appearing in one of the positions is a wild-card, meaning that any procedure in that category may be present; an "N/A" appearing in a particular position indicates that no procedure in that category is needed.
RUとRDの相互作用を規定するMPLSスキームは、手順のQuintupleとして説明できます。（撤回手順は1つしかないため、言及する必要はありません。）ポジションの1つに表示される「*」はワイルドカードです。つまり、そのカテゴリの手順が存在する可能性があります。特定の位置に表示される「n/a」は、そのカテゴリの手順が不要であることを示しています。
Only the MPLS schemes which are specified below are supported by the MPLS Architecture. Other schemes may be added in the future, if a need for them is shown.
以下に指定されているMPLSスキームのみが、MPLSアーキテクチャによってサポートされています。それらの必要性が示されている場合、他のスキームが将来追加される可能性があります。
If Ru and Rd are label distribution peers, and both support label merging, one of the following schemes must be used:
RUとRDがラベル配信ピアであり、どちらもラベルマージをサポートする場合、次のスキームのいずれかを使用する必要があります。
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseImmediate>
1. <pushunconditional、requestnever、n/a、noreleaseonchange、useimmediate>
This is unsolicited downstream label distribution with independent control, liberal label retention mode, and no loop detection.
これは、独立した制御、リベラルラベル保持モード、およびループ検出なしの未承諾のダウンストリームラベル分布です。
2. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange, UseIfLoopNotDetected>
2. <PushunConditional、requestnever、n/a、noreleaseonchange、useifloopnotdeteded>
This is unsolicited downstream label distribution with independent control, liberal label retention, and loop detection.
これは、独立した制御、リベラルなラベル保持、およびループ検出を備えた未承諾のダウンストリームラベル分布です。
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>
3. <pushconditional、requestwheneeded、requestnoretry、releaseonchange、 *>
This is unsolicited downstream label distribution with ordered control (from the egress) and conservative label retention mode. Loop detection is optional.
これは、順序付けられた制御（出口から）および保守的なラベル保持モードを備えた未承諾のダウンストリームラベル分布です。ループ検出はオプションです。
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
This is unsolicited downstream label distribution with ordered control (from the egress) and liberal label retention mode. Loop detection is optional.
これは、順序付けられた制御（出口から）およびリベラルラベル保持モードを備えた未承諾のダウンストリームラベル分布です。ループ検出はオプションです。
5. <PulledConditional, RequestWhenNeeded, RequestRetry, ReleaseOnChange, *>
5. <pulledconditional、requestwheneeded、requestretry、releaseonchange、 *>
This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection.
これは、順序付けられた制御（イングレスによって開始）、保守的なラベル保持モード、およびオプションのループ検出を備えた下流の需要ラベル分布です。
6. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseImmediate>
6. <pulledunConditional、requestwheneeded、n/a、leaversonchange、useimmediate>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection.
これは、ループ検出なしで、独立した制御および保守的なラベル保持モードを備えた下流のデマンドラベル分布です。
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange, UseIfLoopNotDetected>
7. <pulledunConditional、requestwheneeded、n/a、leaversonchange、useifloopnotdeted>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection.
これは、独立した制御および保守的なラベル保持モードを備えた下流の需要ラベル分布であり、ループ検出を備えています。
Suppose that R1, R2, R3, and R4 are ATM switches which do not support label merging, but are being used as LSRs. Suppose further that the L3 hop-by-hop path for address prefix X is <R1, R2, R3, R4>, and that packets destined for X can enter the network at any of these LSRs. Since there is no multipoint-to-point capability, the LSPs must be realized as point-to-point VCs, which means that there needs to be three such VCs for address prefix X: <R1, R2, R3, R4>, <R2, R3, R4>, and <R3, R4>.
R1、R2、R3、およびR4は、ラベルのマージをサポートしていないが、LSRとして使用されているATMスイッチであると仮定します。さらに、アドレスプレフィックスxのL3ホップバイホップパスは<R1、R2、R3、R4>であると仮定し、X向けのパケットがこれらのLSRのいずれかでネットワークに入ることができます。マルチポイントからポイントへの機能がないため、LSPはポイントツーポイントVCSとして実現する必要があります。つまり、アドレスプレフィックスXには3つのそのようなVCが必要であることを意味します。R2、R3、R4>、および<R3、R4>。
Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is implemented using conventional ATM switching hardware (i.e., no cell interleave suppression), or is otherwise incapable of performing label merging, the MPLS scheme in use between R1 and R2 must be one of the following:
したがって、R1とR2がMPLSピアであり、従来のATMスイッチングハードウェアを使用して実装されているLSRである場合（つまり、細胞インターリーブ抑制なし）、またはラベル合併を実行できない場合、R1とR2の間で使用されているMPLSスキームを実行できません。次のいずれかでなければなりません。
1. <PulledConditional, RequestOnRequest, RequestRetry, ReleaseOnChange, *>
1. <pulledConditional、requestOnRequest、requestretry、lelease onchange、 *>
This is downstream-on-demand label distribution with ordered control (initiated by the ingress), conservative label retention mode, and optional loop detection.
これは、順序付けられた制御（イングレスによって開始）、保守的なラベル保持モード、およびオプションのループ検出を備えた下流の需要ラベル分布です。
The use of the RequestOnRequest procedure will cause R4 to distribute three labels for X to R3; R3 will distribute 2 labels for X to R2, and R2 will distribute one label for X to R1.
RequestOnRequest手順を使用すると、R4はXの3つのラベルをR3に配布します。R3はXの2つのラベルをR2に配布し、R2はXの1つのラベルをR1に分配します。
2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseImmediate>
2. <pulledunconditional、requestonrequest、n/a、releaseonchange、useimmediate>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, without loop detection.
これは、ループ検出なしで、独立した制御および保守的なラベル保持モードを備えた下流のデマンドラベル分布です。
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange, UseIfLoopNotDetected>
3. <PulledunConditional、RequestOnRequest、n/a、releaseonchange、useifloopnotdeted>
This is downstream-on-demand label distribution with independent control and conservative label retention mode, with loop detection.
これは、独立した制御および保守的なラベル保持モードを備えた下流の需要ラベル分布であり、ループ検出を備えています。
It is easy to see that certain quintuples do NOT yield viable MPLS schemes. For example:
特定のQuintuppleが実行可能なMPLSスキームを生成しないことを簡単に確認できます。例えば：
- <PulledUnconditional, RequestNever, *, *, *>
<PulledConditional, RequestNever, *, *, *>
In these MPLS schemes, the downstream LSR Rd distributes label bindings to upstream LSR Ru only upon request from Ru, but Ru never makes any such requests. Obviously, these schemes are not viable, since they will not result in the proper distribution of label bindings.
これらのMPLSスキームでは、下流のLSR RDはRUからのリクエストに応じてラベルバインディングを上流のLSR RUに分配しますが、RUはそのような要求を行うことはありません。明らかに、これらのスキームは、ラベルバインディングの適切な分布をもたらさないため、実行可能ではありません。
- <*, RequestNever, *, *, ReleaseOnChange>
In these MPLS schemes, Rd releases bindings when it isn't using them, but it never asks for them again, even if it later has a need for them. These schemes thus do not ensure that label bindings get properly distributed.
これらのMPLSスキームでは、RDはそれらを使用していないときにバインディングをリリースしますが、後でそれらを必要としていても、二度とそれらを求めることはありません。したがって、これらのスキームは、ラベルバインディングが適切に分散されることを保証しません。
In this section, we specify rules to prevent a pair of label distribution peers from adopting procedures which lead to infeasible MPLS Schemes. These rules require either the exchange of information between label distribution peers during the initialization of the label distribution adjacency, or a priori knowledge of the information (obtained through a means outside the scope of this document).
このセクションでは、実行不可能なMPLSスキームにつながる手順を採用することをラベル配布ピアのペアが採用するのを防ぐためのルールを指定します。これらの規則では、ラベル配布隣接の初期化中のラベル配布ピア間の情報交換、または情報の先験的な知識（このドキュメントの範囲外の手段を通じて得られた）のいずれかが必要です。
1. Each must state whether it supports label merging.
1. それぞれがラベルのマージをサポートするかどうかを述べる必要があります。
2. If Rd does not support label merging, Rd must choose either the PulledUnconditional procedure or the PulledConditional procedure. If Rd chooses PulledConditional, Ru is forced to use the RequestRetry procedure.
2. RDがラベルのマージをサポートしていない場合、RDはPulleDunConditional手順またはPulledConditional手順のいずれかを選択する必要があります。RDがPulledConditionalを選択した場合、RuはRequestRetry手順を使用せざるを得ません。
That is, if the downstream LSR does not support label merging, its preferences take priority when the MPLS scheme is chosen.
つまり、下流のLSRがラベルマージをサポートしていない場合、MPLSスキームが選択された場合、その好みが優先されます。
3. If Ru does not support label merging, but Rd does, Ru must choose either the RequestRetry or RequestNoRetry procedure. This forces Rd to use the PulledConditional or PulledUnConditional procedure respectively.
3. RUがラベルのマージをサポートしていないが、RDはRequestRetryまたはRequestNoretryの手順を選択する必要があります。これにより、RDはそれぞれプルコンディショナルまたはプルダンコンディショナル手順を使用することを強制します。
That is, if only one of the LSRs doesn't support label merging, its preferences take priority when the MPLS scheme is chosen.
つまり、LSRの1つだけがラベルのマージをサポートしていない場合、MPLSスキームが選択された場合、その好みが優先されます。
4. If both Ru and Rd both support label merging, then the choice between liberal and conservative label retention mode belongs to Ru. That is, Ru gets to choose either to use RequestWhenNeeded/ReleaseOnChange (conservative) , or to use RequestNever/NoReleaseOnChange (liberal). However, the choice of "push" vs. "pull" and "conditional" vs. "unconditional" belongs to Rd. If Ru chooses liberal label retention mode, Rd can choose either PushUnconditional or PushConditional. If Ru chooses conservative label retention mode, Rd can choose PushConditional, PulledConditional, or PulledUnconditional.
4. RUとRDの両方がラベルの合併をサポートする場合、リベラルと保守的なラベル保持モードの選択はRUに属します。つまり、ruは、requestWhENeeded/releaseonChange（保守派）を使用するか、RequestNever/noreLeaseonChange（リベラル）を使用するかを選択することができます。ただし、「プッシュ」対「プル」と「条件付き」対「無条件」の選択はRDに属します。Ruがリベラルなラベル保持モードを選択した場合、RDはPushunconditionalまたはPushoncitionalのいずれかを選択できます。Ruが保守的なラベル保持モードを選択した場合、RDはプッシュコンディショナル、プルドコンディショナル、またはプルダンコンディショナルを選択できます。
These choices together determine the MPLS scheme in use.
これらの選択は一緒になって、使用中のMPLSスキームを決定します。
Some routers may implement security procedures which depend on the network layer header being in a fixed place relative to the data link layer header. The MPLS generic encapsulation inserts a shim between the data link layer header and the network layer header. This may cause any such security procedures to fail.
一部のルーターは、データリンクレイヤーヘッダーに比べて固定場所にあるネットワークレイヤーヘッダーに依存するセキュリティ手順を実装する場合があります。MPLSジェネリックカプセル化は、データリンクレイヤーヘッダーとネットワークレイヤーヘッダーの間にシムを挿入します。これにより、そのようなセキュリティ手順が失敗する可能性があります。
An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack (the "label writer"), and the LSR that interprets that label (the "label reader"). If labeled packets are accepted from untrusted sources, or if a particular incoming label is accepted from an LSR to which that label has not been distributed, then packets may be routed in an illegitimate manner.
MPLSラベルは、ラベルをラベルスタック（「ラベルライター」）に配置するLSRと、そのラベルを解釈するLSR（「ラベルリーダー」）との間の合意により、その意味を持ちます。ラベル付きパケットが信頼できないソースから受け入れられている場合、またはそのラベルが分布していないLSRから特定の着信ラベルが受け入れられている場合、パケットは非合法的にルーティングされる場合があります。
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は、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、請求権のオンラインリストを参照してください。
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Eric C. Rosen Cisco Systems、Inc。250 Apollo Drive Chelmsford、MA、01824
EMail: erosen@cisco.com
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd. Milpitas, CA 95035-7438
Arun Viswanathan Force10 Networks、Inc。1440 McCarthy Blvd.Milpitas、CA 95035-7438
EMail: arun@force10networks.com
Ross Callon Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
Ross Callon Juniper Networks、Inc。1194 North Mathilda Avenue Sunnyvale、CA 94089 USA
EMail: rcallon@juniper.net
[MPLS-ATM] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[MPLS-ATM] Davie、B.、Lawrence、J.、McCloghrie、K.、Rekhter、Y.、Rosen、E.、Swallow、G。、およびP. Doolan、「LDPおよびATM VCスイッチングを使用したMPLS」、RFC3035、2001年1月。
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.
[MPLS-BGP]「BGP-4のラベル情報の運搬」、Rekhter、Rosen、Work in Progress。
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.
[MPLS-CR-LDP]「LDPを使用した制約ベースのLSPセットアップ」、Jamoussi、編集者、作業中の作業。
[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-FRMRLY] CONTA、A.、DOOLAN、P。およびA. MALIS、「フレームリレーネットワーク仕様のラベルスイッチングの使用」、RFC 3034、2001年1月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[MPLS-LDP] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。and B. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche, Berger, Gan, Li, Swallow, Srinvasan, Work in Progress.
[MPLS-RSVP-Tunnels]「LSPトンネルのRSVPへの拡張」、Awduche、Berger、Gan、Li、Swallow、Srinvasan、進行中の作業。
[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G., Farinacci, D. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-Shim] Rosen、E.、Rekhter、Y.、Tappan、D.、Fedorkow、G.、Farinacci、D。、A。Conta、「MPLS Label Stack Encoding」、RFC 3032、2001年1月。
[MPLS-TRFENG] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[MPLS-Trfeng] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M.、J。McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
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エディター機能の資金は現在、インターネット協会によって提供されています。