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.
著作権（C）インターネット協会（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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
コネクションレスネットワーク層プロトコルのパケットは次の1つのルータから移動するように、各ルータは、そのパケットのための独立した転送決定を行います。すなわち、各ルータは、パケットのヘッダを解析し、各ルータは、ネットワーク層ルーティングアルゴリズムを実行する、です。各ルータは、独立して、そのパケットのヘッダの解析およびルーティングアルゴリズムを実行した結果に基づいて、パケットの次のホップを選択します。
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）」のセットに可能なパケットのセット全体を仕切ります。第二は、次のホップに各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.
Xは、各パケットの宛先アドレスの「最長一致」であるようにそのルータのルーティングテーブル内のいくつかのアドレスプレフィックスXが存在する場合、従来のIPフォワーディングでは、特定のルータは一般的に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では、ラベルは、明示的なルートのアイデンティティがパケットで運ばれる必要がないように、ルートを表すために使用することができます。
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は、precedenceまたはサービスのクラスは、完全に、または部分的にラベルから推測することができます（ただし、必須ではありません）。この場合、1は、ラベルは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パケットのグループを転送します
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.
ラベルは、特定のFECにパケットが続く階層の1つのレベルで一の以上のLSRを通る経路に経路を切り替えます。
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ルーティングおよび転送とを動作させるノードの連続する組
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エッジノードドメインの外にあるノードと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ノードは、一つ以上のL3ルーティングプロトコルを動作する、MPLS制御プロトコルを知っているであろう、そしてラベルに基づいてパケットを転送することができるであろう。 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.
仮想回線レイヤ2つのスイッチの状態情報の維持を必要とするようなATMやフレームリレーなどの接続指向のレイヤ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が単一の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.
複数のVPは、1つのVPにマージされることを可能にするようVPは、MPLSラベルがATM VPIフィールドDIN運ばれたラベルのマージをマージします。この場合、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
NHLFE地図IGP内部ゲートウェイプロトコルILM着信ラベル地図IPインターネットプロトコルLDPラベル配布プロトコルL2レイヤ2 L3レイヤ3 LSPラベルスイッチパスのLSRラベルスイッチングにATM非同期転送モードBGPボーダーゲートウェイプロトコルDLCIデータリンクサーキット識別子FEC転送等価クラスFTN FECルータのMPLSマルチプロトコルラベルスイッチングNHLFEネクストホップラベル転送エントリSVCは、仮想回線のSVPは、仮想パスTTLのTime-To-ライブVC仮想回線VCI仮想回線識別子VP仮想パス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.
この文書のアイデアやテキストを受信源とコメントの数から集めてきました。私たちは、それらの入力やアイデアのためにリックBoivie、ポールDoolan、ナンシー・フェルドマン、ヤコフ・レックター、ビジェイSrinivasan氏、ジョージくんに感謝したいと思います。
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にパケットを送信する場合、Ruがあればラベル値Lとパケットで標識し、パケットが特定のFEC Fのメンバーである場合にのみ、彼らが同意することができることに同意することができますRDにruから移動するパケットのラベル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は必ずしもRDにruから送信されているもの以外の任意のパケットに対して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.
我々は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.
RdがラベルLが、むしろ他のいくつかのLSRによってよりも、Ruをすることによって、パケット内に配置したことを、ラベルLを運んで到着したパケットの、伝えることのために時にはそれが困難または不可能かもしれません。 （Ru及びRdは直接隣人でないときこれは通常の場合となります。）このような場合には、RdがラベルからFECへの結合が1対1であることを確認する必要があります。また、異なるFEC F2にLをバインドするために、いくつかの他のLSR RU2に同意しながら、それが入って来るラベルLを持つパケットを受信したときにRdは常に、伝えることができない限り、つまり、Rdがいるかどうか、、、FEC F1にLをバインドするRU1に同意してはなりませんラベルは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がRDにルテニウムから送信されるパケットのために、FEC FにラベルLをバインドすることに合意したと仮定します。この結合に関して、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つは、特定のラベルが下流ノードへの上流ノードから移動するパケットの特定の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アーキテクチャでは、特定のFEC Fに特定のラベルLに結合するという決定は、その結合に対して下流である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.
RuにRdのにより分配FEC FのラベルLの特定の結合は、「属性」が関連付けられていてもよいです。 Ruは、下流LSRとして動作する、また、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バインディングの別を通知することにより、手順のセットです。ラベル/ 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.
ラベル配布プロトコルは、2つのラベル配布ピアが互いのMPLS機能を知るために従事する必要がある任意の交渉を包含する。
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-CR-LDP]、例えば、[MPLS-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が明示的に特定の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の実装は唯一のダウンストリームオンデマンドラベル配布を提供し、一部だけ迷惑下流ラベル配布を提供し、いくつかの両方を提供することが期待されます。これは特定の実装によってサポートされるインタフェースの特性に依存する可能性が提供されます。しかし、これらのラベル配布技術の両方が同時に同じネットワークで使用することができます。任意のラベル配布隣接で、上流および下流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がルテニウムのネクストホップません（または、もはやのRuの次のホップである）、そのFECのためにもかかわらず、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のであれば、我々は、トップレベル2ラベルとして、ラベルに（例えば、存在する場合）その上のラベルに、レベル1ラベルとしてスタックの底部にラベルを参照しますレベル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）が使用されます。これは、次の情報が含まれます。
2. the operation to perform on the packet's label stack; this is one of the following operations:
2.操作は、パケットのラベルスタックに実行します。これは、次の操作のいずれかです。
a) replace the label at the top of the label stack with a specified new label
a）に指定された新しいラベルでラベルスタックの最上部にラベルを置き換えます
b) pop the label stack 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.
b）のラベルスタック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）はNHLFEsのセットに入ってくる各ラベルをマッピングします。標識されたパケットとして到着したパケットを転送するときに使用されます。
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は、複数の要素が含まれていNHLFEsのセットに特定のラベルをマッピングした場合、パケットが転送される前に、一連の正確に一つの要素を選択する必要があります。セットから要素を選択するための手順は、このドキュメントの範囲を超えています。例えば、複数の等コストパス上に負荷分散を行うことが望まれる、場合ILMが複数のNHLFEを含むセットにラベルをマップ有することは有用であり得ます。
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ツーNHLFE」（FTN）はNHLFEsのセットに各FECをマッピングします。未標識の到着が、転送される前に標識されるべきパケットを転送するときに使用されます。
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は、複数の要素が含まれていNHLFEsのセットに特定のラベルをマッピングした場合、パケットが転送される前に、一連の正確に一つの要素を選択する必要があります。セットから要素を選択するための手順は、このドキュメントの範囲を超えています。例えば、複数の等コストパス上に負荷分散を行うことが望まれる、場合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はラベルスタックの最上部にラベルを調べます。それはNHLFEにこのラベルをマップするためにILMを使用しています。 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を決定するために、ネットワーク層ヘッダを解析します。その後、NHLFEにこれをマップするためにFTNを使用しています。 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.
ITは、LABELスワッピングが使用されているときに、次のホップは常に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がFEC FにラベルL1を結合し、ラベル配布ピアRU1に結合することを分配することができます。 RDはまた、FEC FにラベルL2を結合し、ラベル配布ピア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がFEC F1にラベルLを結合し、ラベル配布ピアRU1に結合することを分配することができます。 RDはまた、FEC F2にラベルLを結合し、ラベル配布ピアRU2に結合することを分配することができます。 ITは、ラベルがRU1 OR BY RU2によってそこに置かれたかどうか、そのトップラベル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が唯一それがRU1または以下の条件が保持している場合、ラベルスタックの最上位に特定のラベル値Lを入れ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 F2、F1へのラベルLの結合、並びに、FEC F1へのラベルLの結合Ruに分配することができます！ = F2、場合にのみ、各結合のみRuがインターフェースの特定の1つを超えるRDに送信するパケットのために有効である場合。他のすべての例では、R dは二つの異なるのFECに同じラベル値のRuのバインディングに配布してはなりません。
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. R1、「LSPイングレス」は、深さmのラベルスタックで、その結果、PのラベルスタックにラベルをプッシュLSRです。
2. For all i, 1<i<n, P has a label stack of depth m when received by LSR Ri;
iは、1 <iがn <全てについて2. 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. RへR1からのPの輸送中ない時間[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;
Riがへのインデックスとしてラベルスタック（レベルMのラベル）の上部にあるラベルを使用することによって、すなわち、MPLSを用いて[I + 1] RにPを送信する：I、1 <iがn <ALL 4. ILM;
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:
PはRiをによって送信された後であるが、PがR [I + 1]（例えば、RおよびR [I + 1]かもしれによって受信される前に、システムSはPを受信して転送する場合：I、1 <iがn <ALL 5. Sの転送決定がレベルmのラベルに、またはネットワーク層ヘッダに基づいていない次いで、交換データリンクサブネットワークを介して接続され、及びS）は、データリンクスイッチの1つかもしれません。これは、ことがあります
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は> 0 k個のラベルにプッシュされていたラベルスタックに基づいています。
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,
レベルMラベルにプッシュLSR（「LSPイングレス」）で始まる1、
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.
転送の決定は、レベルm-k個のラベル上にスイッチングラベルによって行われる場合（「LSP出口」で）終了3.ここで、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出口今あるラベルを割り当てたLSRであるFECに対応していることを確認する必要があるということですスタック内の第二。
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である場合、我々は、「特定のFEC FのためのLSP」のLSRのシーケンスを呼び出します
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.
パケットPのレベルmのLSPである<R1、...、Rn>の場合セクション3.15の定義に従って、Pが深さM-のラベルスタックとRnのにR [N-1]から送信されてもよいことに注意してください1。すなわち、ラベルスタックはなくLSP出口よりも、LSPの最後から二番目の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.
最後から二番目のホップのポッピングを行うには実用上の利点もあります。 1はこれを行わない場合はLSP出口がパケットを受信したとき、そして、それは最初の最上位ラベルを検索し、それが実際にLSP出口である、ルックアップの結果として決定されます。そして、それはスタックをポップし、パケットの残るものを調べる必要があります。スタック上の別のラベルがある場合は、出口はこれを検索し、この検索に基づいてパケットを転送します。 （この場合には、パケットのレベル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:
一方、最後から二番目のホップのポッピングが使用されている場合は、最後から二番目のホップがラベルを見上げたときに、それが決定されます。
- that it is the penultimate hop, and
- それは最後から二番目のホップである、とすることを
- 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 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出口がパケットを受信すると、スタックの一番上に今あるラベルは、それが自身の転送決定を行うためにルックアップする必要がラベルになります。パケットは、単一のラベルを運んでいた場合は、LSP出口は、単にそれがその転送決定を行うために見る必要があるだけで何であるネットワーク層パケットを、表示されます。
This technique allows the egress to do a single lookup, and also requires only a single lookup by the penultimate node.
この技術は、単一のルックアップを行うための出口を可能にし、また最後から二番目のノードによってのみ、単一のルックアップが必要です。
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:
唯一の単一のルックアップは、これまで必要とされることが知られている場合は、製品ラベルスイッチングにおけるフォワーディング「ファーストパス」の作成が大幅に支援することができます。
- 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.
最後から二番目のホップポッピングが行われたときに実際には、LSP出口でも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.)
しかし、一部のハードウェアスイッチングエンジンは、ラベルスタックをポップすることができないかもしれないので、これは普遍的に必要とすることはできません。また、最後から二番目のホップのポッピングが望ましくないようないくつかの状況があるかもしれません。したがって、最後から二番目のノードは、これは、特に出口ノードによって要求され、OR LSPの次のノードがMPLSをサポートしていない場合にのみラベルスタックをポップします。 （LSPの次のノードがサポートMPLSを行いますが、そのような要求をしない場合は、最後から二番目のノードは、それが実際には最後から二番目のノードであることを知る方法はありません。）
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はとてもその下流のラベル配布ピアによって要求されたときに飛び出る最後から二番目のホップを行う必要があります。
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がその隣接LSRSはラベルスタックをポップすることが可能であるかどうかを決定することを可能にしなければなりません。それはそうすることが可能でない限り、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.
最後から二番目のホップのポッピングが使用されている場合、出口ノードは、常に適切に受信したパケットのトップラベルを解釈できるかどうかを求められることがあります。限りセクション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ネクストホップは、ネットワーク層ルーティングアルゴリズムによって選択される次のホップ異なっていてもよいことに留意されたいです。我々は後者を参照するとき、私たちは、用語「L3ネクストホップ」を使用します。
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は、ラベルが何にバインドされているとは思いませんし、非標識IPパケットのホップルーティングによってホップが上流の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は、ダイナミックルーティングアルゴリズムを介して配信されるプレフィックスに対処するために対応しています。独立したLSP Controlまたは順序LSP制御：これらのFECのためのLSPのセットアップは、次のいずれかの方法で行うことができます。
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制御においては、そのFECのための出口LSRである場合LSRは、特定の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.
1は、特定のFECにそのトラフィックを確保したい場合は、トラフィックがリソースの指定された量は、トラフィックが続くことを、トラフィックに利用可能であることを、二回の任意のノードを横断していないこと、などの特性（一部の指定されたセットを持つ経路をたどります明示的に指定したパスなど）の制御を使用する必要があります命じました。独立制御では、LSPが完全に設定される前に、いくつかのLSRは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が注文したコントロールを使用していない限り、1は、それが完全に設定されるまでの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にトラフィックを分割する一つの方法は、ルーティングテーブルに表示される各アドレスプレフィックスのために別々のFECを作成することです。しかし、特定のMPLSドメイン内で、これはすべてのそれらのFECですべてのトラフィックが同じ経路をたどるようのFECのセットをもたらすことができます。例えば、個別のアドレスプレフィックスのセットはすべて同じ出口ノードを持っているかもしれない、とラベルスワッピングは出口ノードへのトラフィックを取得するために使用される可能性があります。この場合、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 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.
（いくつかのドメイン内の）FEC自体でのFECの組合に、ユニオン内のすべてのトラフィックにそのラベルを適用する単一のラベルを結合する手順は、「集合」として知られています。 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.
独立した制御が使用される場合、異なるのFECのいくつかのセットを集約隣接のLSR、Ru及びRdを、そこになることが可能です。
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がRDに、これらのFECで標識されたパケットを転送する必要があるとき、それはMラベル、N> Mにn個のラベルをマップする必要があることを意味します。オプションとして、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の（RuはM、N> Mを分散していながら、すなわち、Rdは、のFECのセットについて、n個のラベルを配布している）よりも粗い粒度を有する場合、それは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.
- それは、これが同じルーティングを生成することを決定することができる場合、それは単に、Rdのn個のラベルの一部に、そのm個のラベルをマッピングすることができます。例えば、Rdは、パケットの個々の宛先アドレスに応じて、そのようなトラフィックに異なるラベルの数を結合するのに対しRuは、特定の出口LSRを通過する必要があるすべてのトラフィックに単一のラベルを適用すると仮定する。 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のための粒度を知るように構成されていることを確実にすることによって得ることができます。しかし、多くの場合、これは、（「フォワーディングテーブルのIPプレフィックスごとにラベル」、又は「出口ノードごとにラベル」など）は、すべてのFECに適用される粒度の単一レベルを使用することによって行うことができます。
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を選択するために使用される方法を指します。ホップ・ルーティング（1）ホップ、及び（2）明示的ルーティング：提案されたMPLSプロトコルアーキテクチャは、経路選択のための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は独立して、次のホップを選択していません。むしろ、一般的にLSPの入口またはLSPの出口単一LSRは、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に達することが起こり得ます。これは、過渡状態に、または起因するパケットのネクストホップであるべき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は、時々そのようなマルチキャストスコープ、及び「トレースルート」コマンドをサポートするように、同様に他の機能のために使用されます。これは、MPLSが対処する必要がある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ホップの総数は、その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ラベルは、L2ヘッダで運ばれている場合、このようなATMヘッダとして[ 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フィールドを持たなければならない、各LSR-でデクリメントされてくださいホップ、及びパケットが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のように）それ自体は、各LSRホップでパケットのTTLを減少することはできません、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ホップの数を反映するTTLを与えられるべきです。ユニキャストの場合、これは、非TTL LSPセグメントにパケットを転送する前に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が期限切れとなることを、非TTL LSPセグメントへの進入時に、決定することができます。この場合、非TTL LSPセグメントへの入口でのLSRは、パケットスイッチラベルはなりません。これは、特別な手順は、例えば、トレースルートパケットがホップ転送することにより、従来のホップを使用して転送することができる、トレースルート機能をサポートするために開発されなければならないことを意味します。
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 provide fair buffer access of this sort, however, then even transient loops may cause severe degradation of the LSR's total performance.
ATMスイッチングハードウェアはラベルがVPI / VCIフィールドで搬送されると、MPLSスイッチング機能を提供するために使用されていること、例えば、仮定する。 ATMスイッチングハードウェアはTTLを減少することはできませんので、ループを防ぐ機能はありません。 ATMハードウェアが異なるVPI / VCI値を搬送着信セル用のバッファプールへの公平なアクセスを提供することが可能である場合、このループは、他のトラフィック上の任意の有害な効果を有していなくてもよいです。 ATMハードウェアがこの種の公正なバッファアクセスを提供できない場合は、しかし、その後も、過渡的なループが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値を使用します。一つ以上のラベルがこれらのレガシースイッチによってアクセスされるフィールドに直接符号化することができ、したがって場合、レガシースイッチは、適切なソフトウェアのアップグレードと、のLSRとして使用することができます。私たちは、「ATM-LSRの」などのデバイスを指します。
There are three obvious ways to encode labels in the ATM cell header (presuming the use of AAL5):
（AAL5の使用を想定）ATMセルのヘッダのラベルを符号化するための3つの明白な方法があります。
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のラベルスタックに「プッシュ」または「ポップ」操作を実行することはできません。
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.
一方が存在する場合、スタック上の第2のラベルを符号化するためにラベルスタックの最上位にあるラベル、およびVCIフィールドを符号化するためにVPIフィールドを使用します。この手法にはATM「VP-切り替え」の使用を許可することで、以前の1を超えるいくつかの利点、。すなわち、LSPはATMシグナリングプロトコルとしてラベル配布プロトコルを使用して、ATMのSVPとして実現されます。
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は、効果的に「ポップ」の操作を行います。
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フィールドを使用するものが存在する場合、スタック上の第2のラベルを符号化するためにVCIフィールドの一部を使用して、LSPを識別するために、VCIフィールドの残りの部分を使用し侵入。この技術を使用する場合、従来のATM VP-スイッチング機能は、マルチポイント・ツー・ポイントのVPを提供するために使用することができます。異なるパケットからの細胞は、その後、異なるVCI値を伝送します。私たちはセクション3.26に見るように、これは、マルチポイント・ツー・ポイントのVPを提供することができますが、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 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つの異なるスイッチに割り当てられていないように、各ATMスイッチに16ビットVCI値を割り当てるための能力の有無に依存します。 （そのような値の適切な数は、各スイッチに割り当てることができれば、また、スタック内の第二のラベルとしてVCI値を処理することが可能であろう。）
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がR2にパケットPを送信するラベルスタックの符号化を使用するが、R3にパケットPを送信するときR2は異なる符号化を使用することが可能です。一般的には、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スイッチは、これら2つのATMスイッチは、同じ符号化技術を使用することは、いくつかのパケットのレベルmのLSPに沿って連続のLSRであるためにことを必要とします。
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.
当然のMPLS ATMの組み合わせのLSRとして動作するスイッチを含むネットワーク、MPLSシムヘッダを使用して動作する他のLSRが存在するであろう。そのようなネットワークではATMインターフェイスならびに「MPLSシム」インターフェースを有するいくつかのLSRがあってもよいです。これは、異なるホップ上の異なるラベルスタックエンコーディングとLSRの一例です。そのような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つの異なるパケットが異なる着信ラベルで到着したという事実は無関係です。 1は、同じ発信ラベルでそれらを転送したいと思います。そうする能力は、「ラベルマージ」として知られています。
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.
私たちは、それがおよび/または異なる標識で、異なる着信インターフェイスから2つのパケットを受信し、同じラベルを持つ同じ発信インターフェイスから両方のパケットを送信できる場合LSRが合併ラベルすることが可能であることを言ってみましょう。パケットが送信されると、それらは、および/または異なる受信ラベルと異なるインタフェースから到着した情報が失われます。
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.
私たちは異なるインターフェイスから到着任意の二つのパケットのために、または異なる標識で、パケットがいずれかの異なるインターフェイスを送信しなければならない、または異なるラベルを持っている必要があり、場合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あたりの着信ラベルの数は、当該LSRにFECでトラフィックを転送する上流ノードの数と同じ大きさです。実際には、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間の正しい相互運用性を確保する問題につながります。問題は、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に依存します。
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.
それが明示的にそのFECのためのラベルを要求しない限り、MPLSアーキテクチャでは、特定の上流の隣人が合併ラベルをサポートしていない場合、それは特定の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つの着信ラベルを有することが仮定。この場合、このノードは、二つの発信ラベルにこれらを統合することができます。
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のセルインタリーブ問題を解消するために使用することができるいくつかの方法があります。
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を用いて区別されます。
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マージは、それが既存のATMスイッチの実装の高い割合との互換性があるという利点を有しています。これは、VPマージが既存のネットワークで使用することができる可能性が高くなります。 VCとは異なり、VPマージは、マージポイントで任意の遅延が発生せず、また、任意のバッファを要求しません、マージします。しかし、それは各VP内のVCIスペースの調整を必要とするという欠点があります。これを達成することができますいくつかの方法があります。一つ以上の方法の選択は、今後の検討課題です。
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 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).
VCマージと非マージノードがセルの転送がVC上のすべての場合に基づいて相互に接続されている場合（すなわち、VPI及びVCIの連結）。上流隣接次に、VCマージを行っている場合は、各ノードに対して、上流の隣人は、特定のストリームのための単一のVPI / VCI（これはフレーム媒体上の動作の場合には単一のラベルのための要件と類似している）必要があること。上流の隣人がマージやってされていない場合は、隣人は、その上流の隣人に渡すために自分自身のためのストリームごとに単一の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の数を要求する代わりに、（VPIによって識別される）は、単一のVPが、VP内の複数のVCIを要求することができます。また、非マージノードは、2つの異なるVPマージノードから下流にあると仮定する。このノードは、（上流のノードからの要求に応じて）各VCIの指定されたセットに関連付けられている、と2個のVP（各上流ノードに対して1つ）（それ自体から発信トラフィック用）を一度VPI / VCIを要求する必要があるかもしれません。
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の組み合わせを要求することを可能にすることが必要です各々がVP内に有意であるVCIの組によって識別さVCの指定された数を（）を含む）のVPIによって同定しました。 VPは、ノードをマージ従って、それが発信するトラフィックのために含まれるVCIと、1つのVPを要求する（適切な場合）に加えて、各VCのためのVCIは（かかわらず、VCが含有VPの一部であるか否かの）上から要求されました。 （彼らは、単一のVCにすべてのアップストリームトラフィックをマージすることができますので）VCマージノードは、単一のVPI / VCIを要求します。非マージノードは、彼らが上から取得するには、プラス（該当する場合）、彼らが発信するトラフィックのための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".
時には、ルータのRuは、RuとRdがそのパケットのホップバイホップパス上の連続したルータではなく、Rdは、パケットの最終目的地でなくても、他のルータ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.
トンネリングされたパケットが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.
トンネリングされたパケットは、ホップバイホップパス以外のパス上RDにruから移動する場合、我々はそれがその「送信エンドポイント」であり、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としてトンネルを実装し、パケットがトンネルを通って走行させるために、ネットワーク層のカプセル化ではなく、ラベルスイッチングを使用することが可能です。トンネルは、R1は、トンネルの送信エンドポイントであり、Rnはトンネルの受信エンドポイントであるLSP <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.
トンネルの受信エンドポイントが前述のように、それは、トンネルを介して受信するパケットを決定できるようにすることが必要でない場合は、ラベルスタックは、トンネル内の最後から二番目の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へ移動するとき、それはラベルに切り替え、深さ1 R2のラベルスタックを有し、Pがトンネルを入力しなければならないことを決定します。 R2最初はR3にとって意味のあるラベルと着信ラベルを置き換えます。そして、それは新しいラベルにプッシュします。このレベル2ラベルは、R21に意味のある値を有します。切り替えはR21、R22、R23でレベル2ラベルに行われます。 R2-R3トンネルにおける最後から二番目のホップであるR23は、R3にパケットを転送する前にラベルスタックをポップ。 R3がパケットPを見たとき、Pは、今だけを有するレベル1ラベルは、トンネルを出ました。 R3がPのレベル1 LSPに最後から二番目のホップであるので、ラベルスタックをポップし、そして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>に沿って移動、及びR3にR2から行くことレベル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つの方法のいずれかで自分のリモートラベル配布ピアとラベル配布を行うことができます。
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.
明示的ピアリングでは、1は1つがローカルラベル配布ピアのために行う場合とまったく同じように、ピア宛てのラベル配布プロトコルメッセージを送信することにより、ピアにラベルを配布します。リモートラベル配布ピアの数が少ない、またはより高いレベルのラベルバインディングの数が多い、またはリモートラベル配布ピアが異なるルーティングエリアまたはドメインにある場合、この手法は、最も有用です。もちろん、人はどのピアに配布するラベルを知っている必要があります。これは、セクション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で発見されました。
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ネットワーク内のノード間で使用されています。 MPLSが正しく動作するためには、ラベル分布情報を確実に伝達する必要があり、特定のFECの必要性に関連するラベル配布プロトコルメッセージを順番に送信します。単一のデータグラムに複数のラベルのメッセージを運ぶための能力があるとして、フロー制御は、また望ましいです。
One way to meet these goals is to use TCP as the underlying transport, as is done in [MPLS-LDP] and [MPLS-BGP].
[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.
多くのシナリオでは、（セクション4.1を参照）プレフィックスに対処する経路で識別することができるのFECにラベルを結合することが望ましいです。これらのルートを配布し、標準、広く展開されているルーティングアルゴリズムがあれば、ラベル配布が最適なルート自身の分布にラベル配布をピギーバックすることによって達成されると主張することができます。
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 FilterSpecには、各ホップで適用する必要がないように、これらのフロー内のパケットを標識することが望ましいです。 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.
MPLS、トラフィックエンジニアリングに関連する特にいくつかの用途では、入口から出口まで、明示的にルーティングされたパスを設定することが望ましいです。そのパスに沿ってリソース予約を適用することも望ましいです。
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].
第1のアプローチは、[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.
MPLSの使用回数は、特定のラベルのパケットがネットワーク層宛先アドレスフィールドで指定されたアドレスを有するパケットを転送するために使用される同じホップバイホップルーティングパスに沿って転送されることを必要とします。
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.
一般に、ルータ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:
以下の条件の場合のみ1が保持している場合のLSR 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
X 1. R1の経路は、特定の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
X 2. R1のルートは、ルーティングアルゴリズム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インスタンスを介して学習された、またはそのIGPインスタンスにR1によって再配布されます
4. R1's route to X is a route which it learned about via BGP, and R2 is a BGP peer of R1
X 4. R1のルートは、それが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:
任意のアドレスプレフィックス、各LSRのMUSTに対応するホップバイホップ経路に従ってパケットを転送するためのMPLSを使用するために：
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.
このような各アドレスプレフィックス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は、それがそのアドレスプレフィックスにそのラベルをバインド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はXにBGPネクストホップとしていくつかの他のLSR R2を命名、Xへのルートを配布するためにBGPを使用し、そしてR1は、R2がXにラベルLを割り当てたことを知っている場合には、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ルートがIGPに分配されている場合にのみ場合BGPルートに対応するプレフィックスをアドレスに対応するラベルが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に与えられた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つのアドレスプレフィックスXは、存在するよう、そのための全てのi、1 <= iは、XがPの宛先アドレスのためのRIのルーティングテーブル内の最長一致であり、n <。
2. for all i, 1<i<n, Ri has assigned a label to X and distributed that label to R[i-1].
すべてのため2. <iがn <I、1は、R 1はXにラベルを割り当てており、[I-1] Rにそのラベルを配布しました。
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.
R3にR1からR2に行く必要10.2.153.178宛先アドレスと、例えば、そのパケットPと仮定する。 R2はR1にアドレスプレフィックス10.2 / 16をアドバタイズしますが、R3は10.2.153 / 23アドバタイズ、10.2.154 / 23、およびR2に10.2 / 16ということもあるとします。つまり、R2はR1に「集約ルート」を宣伝しています。このような状況では、それはR2に到達するまで、パケットPは、ラベルを切り替えることができますが、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出口」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がYのために最長一致であるRのルーティングテーブル内のアドレスプレフィックスがある、またはそのようなことを有します
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用の「脱凝集点」であります
An LSR R1 is considered to be an "LSP Proxy Egress" LSR for address prefix X if and only if:
LSR R1は、と考えられている「LSP代理出口」アドレスプレフィックスXのための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
X 1. R1のネクストホップはR2であり、R1及びR2は、（R2がMPLSをサポートしていないため、おそらく）Xに対して配布ピアにラベルを付ける、またはされていません
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出口がMPLSをサポートしていないノードであるためにLSPの定義が可能。この場合、LSPに最後から二番目のノードがプロキシ出口です。
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.
暗黙のNULLラベルは、LSRがアドレスプレフィックスと結合することができる特別なセマンティクスを持つラベルです。 LSR Ruは、そのILMを調べることによって、ラベル付きパケットPは、次のRDに転送されなければならないということが、Rdは、対応するアドレスプレフィックスへの暗黙のNULLのバインディングを配布したこと、そして代わりのの上にラベルの値を置き換える見ている場合ラベルスタック、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とLSR Ruに対するアドレスプレフィックスXとの間の結合を分配する場合にのみ。
1. the rules of Section 4.1.2 indicate that Rd distributes to Ru a label binding for X, and
1. 4.1.2項の規定は、道がXに対するラベルバインディングを実行するために配布することを示し、
2. Rd knows that Ru can support the Implicit NULL label (i.e., that it can pop the label stack), and
2. RdがRuが（それがラベルスタックをポップすることができていること、すなわち）暗黙のNULLラベルをサポートできることを知っており、
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の最後から二番目のLSRが発生します。これは非常に適切です。 LSP出口がXのためのMPLS出力であれば最後から二番目のLSRはラベルスタックをポップしない場合、その後、LSP出口は、ラベルをルックアップする必要があるラベルスタックをポップして、次のラベルを検索（または検索しますL3アドレス、これ以上のラベルが存在しない場合）。最後から二番目のLSRはラベルスタックをポップ持つことにより、LSP出口は、その転送決定を行うために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.
最後から二番目のLSRは、ATMスイッチがある場合は、それはラベルスタックをポップする機能を持っていないかもしれません。したがって暗黙のNULLの結合は、その機能をサポートすることができるの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で最後から二番目のLSRがLSP代理出口であるならば、それはLSP出口がX用の暗黙のNULLのバインディングを配布していたかのように動作します
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 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:
LSPイングレス、Riは、いくつかの異なるのFECのパケットはすべてのLSP出口再、たとえば、で終わる、同じLSPに従わなければならないことを知っているという状況があります。この場合には、適切なルーティングは、すべてのそのようなの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はReがのFECの特定のセット内のすべてのパケットのLSPの出口であることを決定するためのいくつかの方法があります
Then Ri may bind a single label to all FECS in the set. This is known as "Egress-Targeted Label Assignment."
そして、Riが、セット内のすべてのFECSに単一のラベルを結合することができます。これはとして知られている「出力-ターゲットラベルの割り当て。」
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 LSR Riが再特定の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内のすべてのノードされている場合、ルーティングアルゴリズムは、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を実行している場合、R 1は、特定のFECにパケットがそのFECは、「BGPネクストホップ」であるいくつかの特定のルータを介してネットワークを離れなければならないことを決定することができます。
- 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.
- アドレスプレフィックスが出口れるのLSRに「添付」されているかについての情報を渡すためにラベル配布プロトコルを使用することが可能です。この方法は、リンク状態ルーティングの存在に依存しないという利点を有します。
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.
出口を標的とラベルの割り当てが使用されている場合は、ネットワーク全体でサポートする必要のあるラベルの数を大幅に削減することができます。 1は、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出口であるため、アドレスプレフィックスのうちの1つまたは複数の出口を標的とラベルの割り当てを使用しないように、特定の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 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.
- 特定のLSRがアドレスプレフィックスのいくつかのセットのためにLSP出口されていない場合、それは、それらのアドレス・プレフィックスのために、そのLSPネクストホップによって行われるのと同じ方法でアドレスプレフィックスにラベルを割り当てるべきです。それは、RdがアドレスプレフィックスX1とX2のためのRuのLSPネクストホップであると仮定し、あります。 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.
たとえば、1は出口を標的とラベルの割り当てをデフォルトにしたいと考えたとしますが、複数の可能なLSPのegresses存在であるため、これらのアドレスプレフィックスに明確なラベルを割り当てること（マルチホームされているそれらのアドレスプレフィックスのためのすなわち、。）一つは設定することができますすべてのLSRは出口をターゲットラベル割り当てを使用して、マルチホームであるこれらのアドレスプレフィックスに明確なラベルを割り当てるためのLSRの一握りを設定します。特定のマルチホームアドレスプレフィックスXの場合、1は、いずれか一方のみLSP EgressesまたはX用のLSP代理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に明確なラベルを割り当てた場合Rdは、それらの両方に一つだけのラベルを割り当てながら、転送が正常に行われることに注意することが重要です。これは単に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出口またはプロキシ出口は、転送が正常に行われるそれらのアドレスに対応するラベルに割り当てられている場合。 RuはちょうどRdがそのLSP出口のアドレスに割り当てられたラベルに入ラベルをマッピングします。
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トンネルに送信されるパケットを選択する手段。
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件のアドレスプレフィックスに単一のラベルを割り当てることができます。再は、すべての10のアドレスプレフィックスのLSP出口です。これは、すべての10件のアドレスプレフィックスのためのパケットを再配信することを保証します。しかし、再はその後にパケットを送信するために、適切なインタフェースを選択するために、このような各パケットのネットワーク層アドレスを検索する必要があります。
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.
あるいは、各インターフェイスに異なるラベルを割り当てることができます。その後、再10件のアドレスプレフィックスのLSP代理出口です。これは、パケットを転送するために、ネットワーク層アドレスを検索するために再する必要がなくなります。しかし、それは大量のラベルを使用することになります。
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:
代替的には、（また、LSR自体のアドレスにバインドされている）は、同じレベル1ラベルにすべての10件のアドレスプレフィックスを結合すること、そしてその後異なるレベル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
- と一緒に、パケットの宛先アドレスの最長一致がXであり、XのためのRuのLSPネクストホップがRdのであり、RdはXにラベルL1の結合Ruに分散している場合LSR Ruは当初、これまで未標識パケットにラベルを付ける場合そして、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.スタックは（おそらくX用のRuのLSPネクストホップの変化の結果として）属性の変更をするたびに、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.
Xに結合した標識の値がLSPに沿って各ホップで異なるかもしれないが、スタックの属性値が変化しない渡され、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つずつ複数のラベルを割り当てることができます。従って特定のアドレスプレフィックスの特定の隣人から結合第二の標識の受信がいずれかのラベルがそのアドレスプレフィックスを表すために使用することができることを意味すると解釈されるべきです。
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用のホップバイホップパスは<R1、R2、R3>であると仮定するアドレスプレフィックスX.である、特定のルーティングドメイン全体、最長一致宛先アドレスをそれぞれ有するパケットP1及びP2の場合を考えます、およびP2のためのホップバイホップパスは<R4、R2、R3>です。のは、R3がXにラベルL3を結合し、R2には、この結合を配信しているとしましょう。 R2はXにラベルL2に結合し、このR1及びR4の双方への結合を分配します。 R2は、パケットP1を受信した場合、その着信ラベルがL2であろう。 R2は、L3とL2を上書きし、及びR3にP1を送信します。 R2は、パケットP2を受信すると、その着信ラベルもL2になります。 R2は再びL3とL2を上書きし、及び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が懸念されるように、それらを区別することができないこと、次に注意。したがって代わりに二つの別個の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>は、我々は>我々は<{R1、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.
これは、我々がLSRのような従来のATMスイッチを使用しようとする困難を作成します。従来のATMスイッチはマルチポイントツーポイント接続をサポートしていないので、各LSPがポイントツーポイントVCとして実現されていることを確認するための手順が存在しなければなりません。マルチポイント・ツー・ポイントVCをサポートして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隣人のそれぞれにこれらのホストルートのためにそのラベルを配布しています。
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, e) B2 has bound label L1 to X, and has distributed this binding to B1,
D）XのためのBGPネクストホップがB2、E）B2がXにラベルL1に結合していて、この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は、B2のアドレスにラベルL2を結合し、及び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.
その後、I1にパケットPを送信する前に、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境界ルータB1はラベルスタックの上にラベルがルートがBGPルートされるアドレスプレフィックス、Xに対応する標識されたパケットPを受信すると仮定し、その条件3B、3C、3D、そして3Eすべてが成り立ちます。その後、I1にパケットPを送信する前に、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はB3は、B2のEBGPネイバーであり、AS2であると仮定するAS 1であることを、例えば、と仮定する。最後に、B2およびB3は両方の自律システム（「非武装地帯」）に共通するいくつかのネットワーク上にあると仮定します。この場合、以下のように、LSPトンネルはB1とB3の間で直接設定することができます。
- B3 distributes routes to B2 (using EBGP), optionally assigning labels to address prefixes;
- B3は、任意のプレフィックスに対処するためのラベルを割り当て、（EBGPを使用して）B2へのルートを分配します。
- 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
- 利用不可手順、および
- the Release Procedure, and
- リリース手順、および
- the labelUse Procedure.
- labelUse手順。
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 Ruに下流LSR rdで配布されている場合、使用される場合、およびれている特定の手順のRdが新しい属性のルテニウムを通知しなければなりません。
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とします。仮定：
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に結合することを配布する必要があります。それはRuに配布したバインディングを追跡するために、及び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とします。仮定：
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がLSP出口またはXのためのLSP代理出口、またはXのためのRdのL3ネクストホップRnはRuの区別されるRnは、のいずれかであり、RnがRDに結合がXにラベルを結合し、分散しています。
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.
PushUnconditionalは、ルーティングテーブル内のすべてのアドレスプレフィクスのラベルバインディングの分布を生じさせる一方、PushConditionalのは、唯一の一つのLSPネクストホップからラベルバインディングを受信したため、これらのアドレスプレフィックスのラベルバインディングの分布を引き起こす、または1つは持っていないため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とします。仮定：
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に対するルテニウムのラベル配布ピアでない場合、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はすでにのRuにアドレスプレフィックスXに対するバインディングに分散している、そしてそれはアドレスプレフィックスX用の結合のためのRuから新しい要求を受信した場合、それは第二の標識を結合し、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とします。仮定：
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代理出口のいずれかである、またはXのためのRdのL3ネクストホップがRnはRuの区別されるRnに、であり、RnはRDに結合がXにラベルを結合し、分散しています
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に対する結合は、XのRdのの次のホップを介して得られない、またはRdはXに対するルテニウムのラベル配布ピアではない場合、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にラベルを提供していないということであれば、それはRnの結合を受けたとしてしかし、その後、Rdが、そのような時間までの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のは、RuにアドレスプレフィックスXに対するラベルバインディングを配布しており、そしていくつかの後の時点で、ラベルバインディングの変更のいずれかの属性が、その後、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がPushConditionalのプロシージャまたはPushUnconditional手順を使用するが、下流LSRがPulledUnconditionalプロシージャまたはPulledConditional手順を使用している場合に有用ではない場合に有用です。
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次のアドレスプレフィックスの変更へのホップ、またはときに新しいアドレスプレフィックスが学習され、もう1つは、すでに与えられたアドレスプレフィックスのその次のホップからのラベルバインディングを持っていない時はいつでもリクエストしてください。
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はRdが既にのRuにラベルを配布したのアドレスプレフィックスのためのRuからそのような要求を受信した場合、R dは、新しい（異なる）ラベルを割り当て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.
この手順では、ATM-LSRは、VCマージすることはできないこれは、ダウンストリームオンデマンドラベル配布を行っている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がXのためのRuのL3ネクストホップである、とRuはRdのからX用のバインディングを要求したが、Rdが、それはこの時点でバインディングを提供できないことを返信した場合それはXのための次のホップを持っていないので、その後、利用不可の手順は、Ruがどのように応答するかを決定します。ルテニウムの行動を支配する二つの可能な方法があります。
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はPushUnconditionalプロシージャまたはPushConditionalの手順を使用している場合迷惑下流ラベル配布が使用される場合、これは、すなわち、有用です。
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は、それはRdが何のネクストホップを持っていないので、ルテニウムの行動ではなくによってより、ラベル配布プロトコルのエラー回復条件によって支配されるのではなく、理由はいくつかのエラー状態のため、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で、LSR Ruに結合することを配布したと仮定する。 RdがアドレスプレフィックスXに対するRuのL3ネクストホップであることを発生しません、またはアドレスプレフィックスXに対するRuのL3ネクストホップであることをやめた場合、Ruはラベルを使用できなくなります。リリース手順は、Ru、この場合に作用する方法を決定します。ルテニウムの行動を支配する二つの可能な方法があります。
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.
Rdが後でこの手順では、自民党ラベル保持モードを実装するために使用されるX用のRuのL3ネクストホップになった場合、それはすぐに再使用できるように、Ruは、結合を維持する必要があります。
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用のRuのL3ネクストホップであると仮定
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.
Ruはバインディングがルテニウムによって受信された時点で、RdがXのためのRuのL3ネクストホップではありません、場合RdはX用のRuのL3ネクストホップである場合、Ruはその時バインディングのいずれかを利用していない結合を利用します時間。 RdはXのRUのL3ネクストホップになった場合、RUは、しかし、いくつかの後の時点で結合を使用して開始することができます
The labelUse Procedure determines just how Ru makes use of Rd's binding.
labelUse手順は、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がXのためのRuのL3ネクストホップである任意の時点で、Rdが、ループ検出が使用されていない場合、この手順が使用されているX用のRuのLSPネクストホップであろう。
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.
RdがX！= Y.場合はRuが新しいバインディングを学習した他のアドレスプレフィックスYへのRu Lのいずれかの新しいバインディングを配布する前に、XからLのアンバインドをLSR RuにRdので配布されることが必要とされますそれはXからLの解離を知っ、XおよびYの両方が一致するパケットがRDにルテニウムによって転送された場合、一定期間、RuがラベルとYと一致するXとパケットを照合両方のパケットにラベルを付けることになる前に、YにLの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のアドレスプレフィックスが標識に結合されている場合は、結果が暗黙のうち最初のアドレスプレフィックスへのラベルの結合を撤回するが、両方のアドレスプレフィックスのためにそのラベルを使用することではありません。
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.
Ruが上流のピアであり、Rdは下流ピアのアドレスプレフィックスのいくつかのセットに対するラベル配布ピア二つのLSR、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.
<配信手順、要求手順、利用不可手順、リリース手順、labelUse手順>：Ru及びRdの間の相互作用を支配するMPLSスキームは、手順の五重のように記述することができます。 （一つだけ手順撤退があるので、それは言及する必要はない）A「*」の位置のうちの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、UseIfLoopNotDetected>
This is unsolicited downstream label distribution with independent control, liberal label retention, and loop detection.
これは独立した制御、リベラルラベル保持、およびループ検出と迷惑下流ラベル配布です。
3. <PushConditional, RequestWhenNeeded, RequestNoRetry, ReleaseOnChange, *>
3. <PushConditionalの、RequestWhenNeeded、RequestNoRetry、ReleaseOnChange、*>
This is unsolicited downstream label distribution with ordered control (from the egress) and conservative label retention mode. Loop detection is optional.
これは、（出口からの）順序制御、保守的なラベル保持モードで迷惑下流ラベル配布です。ループ検出はオプションです。
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、RequestWhenNeeded、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、RequestWhenNeeded、N / A、ReleaseOnChange、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、RequestWhenNeeded、N / A、ReleaseOnChange、UseIfLoopNotDetected>
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はアドレスプレフィックスXに対する3つのそのようなのVCが必要であることを意味する、ポイント・ツー・ポイントのVCとして実現されなければならない：<R1、R2、R3、R4>、< 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、ReleaseOnChange、*>
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がR3にXのための3つのラベルを配布するようになります。 R3はR2とX 2つのラベルを配布し、R2はR1にXための一つのラベルを配布します。
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、UseIfLoopNotDetected>
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:
特定のは、実行可能なMPLSスキームを得られないquintuplesことを確認することは容易です。例えば：
- <PulledUnconditional, RequestNever, *, *, *> <PulledConditional, RequestNever, *, *, *>
- <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>
- <*、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スキームでは、R dはバインディングを解放し、それが再び彼らのために要求することはありません。これらのスキームは、このようにそのラベルバインディングが適切に分散取得を保証しません。
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スキームにつながる手順を採用するから、ラベル配布ピアのペアを防ぐためのルールを指定します。これらのルールは、ラベル配布隣接関係の初期化中にラベル配布ピアとの間の情報の交換、又は（本文書の範囲外の手段によって得られた）情報の事前知識のいずれかを必要とします。
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がない場合、RuはRequestRetryまたはRequestNoRetry手順のいずれかを選択する必要があります。これは、RdはそれぞれPulledConditionalまたはPulledUnConditional手順を使用して強制的に。
That is, if only one of the LSRs doesn't support label merging, its preferences take priority when the MPLS scheme is chosen.
それはのLSRの一つだけがラベルマージをサポートしていない場合は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のいずれかを選択する（保守的）RequestWhenNeeded / ReleaseOnChangeを使用する、または（リベラル）RequestNever / NoReleaseOnChangeを使用するために取得、です。しかし、「プル」と「無条件」対「条件付き」対「プッシュ」の選択は、RDに属します。 Ruがリベラルラベル保持モードを選択した場合、RdがPushUnconditionalまたはPushConditionalのどちらかを選択することができます。 Ruが保守的なラベル保持モードを選択した場合、RdがPushConditionalの、PulledConditional、またはPulledUnconditionalを選択することができます。
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
エリックC.ローゼンシスコシステムズ社250アポロドライブチェルムズフォード、MA、01824
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd. Milpitas, CA 95035-7438
アルンViswanathanのフォーステンネットワークス株式会社1440マッカーシーブルバードミルピタス、CA 95035-7438
EMail: arun@force10networks.com
メールアドレス：arun@force10networks.com
Ross Callon Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
ロスCallonジュニパーネットワークス株式会社1194北マチルダアベニューサニーベール、CA 94089 USA
EMail: rcallon@juniper.net
メールアドレス：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]デイビー、B.、ローレンス、J.、McCloghrie、K.、Rekhter、Y.、ローゼン、E.、ツバメ、G.およびP. Doolan、 "LDPおよびATM VCスイッチングを使用してMPLS"、RFC 3035、2001年1月。
[MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, Work in Progress.
[MPLS-BGP] "BGP-4でラベル情報を運ぶ"、Rekhter、ローゼンは進行中で働いています。
[MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, Editor, Work in Progress.
、Jamoussi、エディタ、進行中で働い[MPLS-CR-LDP] "LDPを使用して、制約ベースLSPセットアップ"。
[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[MPLS-FRMRLY]コンタ、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]アンダーソン、L.、Doolan、P.、フェルドマン、N.、Fredette、A.及びB.トーマス、 "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]、Awduche、バーガー、ガン、李、ツバメ、Srinvasanが進行中で働い "LSPトンネルのためのRSVPへの拡張"。
[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]ローゼン、E.、Rekhter、Y.、タッパン、D.、Fedorkow、G.、ファリナッチ、D.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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.、マルコム、J.、Agogbua、J.、オデル、M.とJ.マクマナス、 "トラフィックエンジニアリングオーバーMPLSのための要件"、RFC 2702、1999年9月。
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。