RFC3031 日本語訳
3031 Multiprotocol Label Switching Architecture. E. Rosen, A.Viswanathan, R. Callon. January 2001. (Format: TXT=147175 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループE.ローゼン要求をネットワークでつないでください: 3031年のシスコシステムズInc.カテゴリ: 標準化過程A.Viswanathan Force10はInc.2001年1月にInc.R.Callon杜松ネットワークをネットワークでつなぎます。
Multiprotocol Label Switching Architecture
Multiprotocolラベル切り換え構造
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document specifies the architecture for Multiprotocol Label Switching (MPLS).
このドキュメントはMultiprotocol Label Switching(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
1つの仕様… MPLSへの3 2紹介… 3 2.1概観… 4 2.2用語… 6 2.3の頭文字語と略語… 9 2.4の承認… 9 3のMPLS基礎… 9 3.1 ラベルします。 9 3.2 上流の、そして、川下のLSRs… 10 3.3はパケットをラベルしました… 11 3.4 課題と分配をラベルしてください… 11 ラベル結合の3.5の属性… 11 3.6 プロトコルと分配をラベルしてください… 11 3.7 川下要求次第に対して川下で求められていません… 12 3.8 モードと保有をラベルしてください… 12 3.9 ラベルスタック… 13 3.10 次のホップラベル推進エントリー(NHLFE)… 13 3.11 入って来るラベル地図(ILM)… 14
Rosen, et al. Standards Track [Page 1] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[1ページ]。
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
3.12 FECからNHLFEは(FTN)を写像します… 14 3.13 スワッピングをラベルしてください… 15 3.14 ラベルの範囲とユニークさ… 15 3.15ラベルが経路を切り換えた、(LSP)、LSPイングレス、LSP出口. 16 3.16の終わりから二番目のホップの飛び出し… 次の18 3.17LSPは跳びます… 20 3.18 無効の入って来るラベル… 20 3.19 LSPは制御します: 無党派に対して注文します… 20 3.20集合… 21 3.21 選択を発送してください… 23 3.22 出発しているラベルの不足… 24 3.23 生きる時間(TTL)… 24 3.24 コントロールを輪にしてください… 25 3.25 Encodingsをラベルしてください… 26 3.25.1 MPLS特有のハードウェア、そして/または、ソフトウェア… 26 3.25.2 気圧はLSRsとして切り替わります… 26 3.25.3 テクニックをコード化する中の相互運用性… 28 3.26 合併をラベルしてください… 28 3.26.1 非合併しているLSRs… 29 3.26.2 合併するためのラベルと非合併しているLSRs… 30 3.26.3 気圧で、合併してください… 31 3.26.3.1 セルインタリーブを排除する方法… 31 3.26.3.2 Interoperation: VCマージ、VPマージ、および非マージ。 31 3.27のTunnelsと階層構造… 32 3.27.1 ホップごとに、トンネルを発送しました… 32 3.27.2 明らかに発送されたトンネル… 33 3.27.3 LSPはトンネルを堀ります… 33 3.27.4 階層構造: LSPはLSPsの中でトンネルを堀ります… 33 3.27.5 じっと見るのと階層構造と分配をラベルしてください… 34 3.28 プロトコル輸送と分配をラベルしてください… 35 3.29 1つのLabel DistributionプロトコルよりなぜMore? ..... 36 3.29.1 BGPと自由民主党… 36 3.29.2 RSVP Flowspecsのためのラベル… 36 3.29.3 明らかに発送されたLSPsのためのラベル… 36 3.30マルチキャスト… 37 4 MPLSのいくつかのアプリケーション… 37 4.1MPLSとホップごとに、交通を発送しました… 37 4.1 .1 アドレス接頭語のために、ラベルします。 37 4.1 .2 分配はアドレスのために接頭語をラベルします… 37 4.1 .2 .1 アドレス接頭語のために分配同輩にレッテルを貼ってください… 37 4.1 .2 .2 ラベルを分配します… 38 4.1 .3 LSPとしてHop経路のそばでHopを使用します… 39 4.1 .4 LSP出口とLSPプロキシ出口… 39 4.1 .5 内在しているヌルラベル… 40 4.1 .6オプション: 出口で狙っているラベル課題… 40 4.2MPLSと明らかに発送されたLSPs… 42 4.2 .1 明らかに発送されたLSPはトンネルを堀ります… 42 4.3 スタックと暗黙のじっと見ることをラベルしてください… 43
Rosen, et al. Standards Track [Page 2] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[2ページ]。
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
4.4MPLSとマルチ経路ルート設定… 44 4.5 多点から点実体としてのLSP木… 44 4.6 BGP境界ルータの間のLSPトンネリング… 45 4.7 ホップごとに発送されたLSPの他の用途はトンネルを堀ります… 47 4.8のMPLSとマルチキャスト… 47 5 手順と分配をラベルしてください(ホップで、跳んでください)… 47 5.1 AdvertisingのためのProceduresとUsingラベル… 48 5.1 .1 川下のLSR: 分配手順… 48 5.1 .1 .1PushUnconditional… 49 5.1 .1 .2PushConditional… 49 5.1 .1 .3PulledUnconditional… 49 5.1 .1 .4PulledConditional… 50 5.1 .2 上流のLSR: 手順を要求してください… 51 5.1 .2 .1RequestNever… 51 5.1 .2 .2RequestWhenNeeded… 51 5.1 .2 .3RequestOnRequest… 51 5.1 .3 上流のLSR: NotAvailable手順… 52 5.1 .3 .1RequestRetry… 52 5.1 .3 .2RequestNoRetry… 52 5.1 .4 上流のLSR: 手順をリリースしてください… 52 5.1 .4 .1ReleaseOnChange… 52 5.1 .4 .2NoReleaseOnChange… 53 5.1 .5 上流のLSR: labelUse手順… 53 5.1 .5 .1UseImmediate… 53 5.1 .5 .2UseIfLoopNotDetected… 53 5.1 .6 川下のLSR: 手順を引き下がらせてください… 53 5.2MPLSが計画します: LSRsのためにProcedures. 54 5.2.1SchemesのCombinationsを支持する、そのSupport Label Merging… 55 5.2 .2 どんなSupport Label Merging. 56 5.2.3Interoperability ConsiderationsもしないLSRsを計画します… 57 6 セキュリティ問題… 58 7知的所有権… 58 8人の作者のアドレス… 59 9つの参照箇所… 59 10の完全な著作権宣言文… 61
1. Specification
1. 仕様
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
2. Introduction to MPLS
2. MPLSへの紹介
This document specifies the architecture for Multiprotocol Label Switching (MPLS).
このドキュメントはMultiprotocol Label Switching(MPLS)に構造を指定します。
Note that the use of MPLS for multicast is left for further study.
MPLSのマルチキャストの使用をさらなる研究に発たれることに注意してください。
Rosen, et al. Standards Track [Page 3] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[3ページ]。
2.1. Overview
2.1. 概観
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つの機能の構成として次のホップを選ぶのを考えることができます。 最初の機能は1セットの「推進同値類(FECs)」に全体のセットの可能なパケットを仕切ります。 秒は各FECを次のホップに写像します。 推進決定に関する限り、同じFECに写像される異なったパケットは区別がつきません。 特定のFECのものて、特定のノードから旅するすべてのパケットが同じ経路に続くでしょう(マルチ経路ルーティングのある種類が使用中であるなら、それらは皆、FECに関連している経路の1セットの1つに続くでしょう)。
In conventional IP forwarding, a particular router will typically consider two packets to be in the same FEC if there is some address prefix X in that router's routing tables such that X is the "longest match" for each packet's destination address. As the packet traverses the network, each hop in turn reexamines the packet and assigns it to a FEC.
従来のIP推進では、何らかのアドレス接頭語Xがそのルータの経路指定テーブルにあると特定のルータが、2つのパケットが同じFECにあると通常考えるので、Xは各パケットの送付先アドレスのための「最も長いマッチ」です。 パケットがネットワークを横断するとき、各ホップは、順番にパケットを再検討して、それを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に割り当てると、その後のルータはさらなるヘッダー分析を全くしません。 すべての推進がラベルによって追い立てられます。 これには、従来のネットワーク層推進より多くの利点があります。
Rosen, et al. Standards Track [Page 4] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[4ページ]。
- 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に割り当てられるので、イングレスルータは課題を決定する際にそれがパケットに関して持っているどんな情報も使用するかもしれません、ネットワーク層ヘッダーからその情報を収集できないでも。 例えば、異なったポートの上で到着するパケットは異なったFECsに割り当てられるかもしれません。 他方では、従来の推進はパケットのヘッダーをパケットとともに旅する情報を考えることができるだけです。
- 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が許容する、(必要でない、)、ラベルから完全か部分的に推論されるべきサービスの先行かクラス。 この場合、ラベルがサービスのFECの組み合わせと先行かクラスを表すと言うかもしれません。
Rosen, et al. Standards Track [Page 5] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[5ページ]。
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は"Multiprotocol"Label Switching、「マルチ-プロトコル」を表します。 しかしながら、本書では、私たちはネットワーク層プロトコルとしてIPの使用に焦点を合わせます。
A router which supports MPLS is known as a "Label Switching Router", or LSR.
MPLSを支持するルータは「ラベル切り換えルータ」、またはLSRとして知られています。
2.2. Terminology
2.2. 用語
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はフレームリレーサーキットを特定するのにFrame Relayネットワークに使用されるラベルです。
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.
ラベルを使用するのによるデータの流線型の推進が進めるとき見分けのつかないほど扱われるデータ・パケットのクラスを特定できる推進パラダイムとスワッピングをラベルしてください。
Rosen, et al. Standards Track [Page 6] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[6ページ]。
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.
1LSRsを通してパケットが特定のFECであとに続いた階層構造の1つのレベルで切り換えられた経路を経路とラベルしてください。
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.
プロトコルが層3(したがって、層3によって利用されたサービスを提供します)の下で層にする2を層にしてください。 脆い固定長ラベルのスワッピングですると推進が調べられるラベルがATM VPI/VCIであるかどうかにかかわらず層2に起こって、フレームリレーがDLCIであるかMPLSはラベルです。
layer 3 the protocol layer at which IP and its
associated routing protocols operate
link layer synonymous with layer 2
プロトコルがどのIPで層にする3を層にしてください。そうすれば、関連ルーティング・プロトコルは層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
1つの順序集合のラベルとスタックをラベルしてください。
merge point a node at which label merging is done
マージはラベル合併が行われるノードを指します。
MPLS domain a contiguous set of nodes which operate
MPLS routing and forwarding and which
are also in one Routing or
Administrative Domain
MPLSドメインはMPLSルーティングと推進を操作して、1ルート設定かAdministrative Domainにもあるノードの隣接のセットです。
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がLSRがそれですが、隣接しているそうするホストがMPLSを走らせないのをさせるならMPLSがノードを斜めに進ませることに注意してください。
Rosen, et al. Standards Track [Page 7] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[7ページ]。
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ノードaノード。 MPLSノードは、MPLS制御プロトコルを意識して、1つ以上のL3ルーティング・プロトコルを運転して、ラベルに基づく推進パケットができるでしょう。 また、MPLSノードは任意にネイティブのL3パケットを進めることができるかもしれません。
MultiProtocol Label Switching an IETF working group and the
effort associated with the working
group
MultiProtocol Label SwitchingはIETFワーキンググループとワーキンググループに関連している努力です。
network layer synonymous with layer 3
層3と同義のネットワーク層
stack synonymous with label stack
ラベルスタックと同義のスタック
switched path synonymous with label switched path
ラベルと同義の切り換えられた経路は経路を切り換えました。
virtual circuit a circuit used by a connection-oriented
layer 2 technology such as ATM or Frame
Relay, requiring the maintenance of
state information in layer 2 switches.
サーキットがATMかFrame Relayなどの接続指向の層の2技術で使用した仮想のサーキット、層2における、州の情報の維持を必要とするのは切り替わります。
VC merge label merging where the MPLS label is
carried in the ATM VCI field (or
combined VPI/VCI field), so as to allow
multiple VCs to merge into one single VC
VCはMPLSラベルがATM VCI分野(または、結合したVPI/VCI分野)で運ばれるところでラベル合併を合併します、複数のVCsが1独身のVCに溶け込むのを許容するために
VP merge label merging where the MPLS label is
carried din the ATM VPI field, so as to
allow multiple VPs to be merged into one
single VP. In this case two cells would
have the same VCI value only if they
originated from the same node. This
allows cells from different sources to
be distinguished via the VCI.
VPはMPLSラベルがATM VPIがさばく運ばれた騒音であるところでラベル合併を合併します、複数のVPsが1独身のVPに合併されるのを許容するために。 この場合、2つのセルには、同じノードから発する場合にだけ、同じVCI値があるでしょうに。 これは、さまざまな原因からのセルがVCIを通して区別されるのを許容します。
Rosen, et al. Standards Track [Page 8] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[8ページ]。
VPI/VCI a label used in ATM networks to identify
circuits
VPI/VCIはサーキットを特定するのにATMネットワークに使用されるラベルです。
2.3. Acronyms and Abbreviations
2.3. 頭文字語と略語
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の自由民主党ラベル分配プロトコルL2地図IGPゲートウェイプロトコルILMラベル地図IPインターネットプロトコル層2のL3層3のLSPラベルに同値類FTN FECを送る気圧非同期通信モードBGPボーダ・ゲイトウェイ・プロトコルDLCIデータ・リンクサーキット識別子FEC; 切り換えられた経路LSRラベル切り換えルータMPLS MultiProtocolは切り換えられた仮想の仮想の仮想の経路の仮想の経路VPI仮想の経路TTL生きる時間VCサーキットVCIサーキット識別子VP識別子をエントリーSVC交換仮想回路SVPに転送する次のホップラベルと切り換えNHLFEをラベルします。
2.4. Acknowledgments
2.4. 承認
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、ナンシー・フェルドマン、ヤコフRekhter、ビジェイSrinivasan、およびジョージSwallowに感謝申し上げます。
3. MPLS Basics
3. MPLS基礎
In this section, we introduce some of the basic concepts of MPLS and describe the general approach to be used.
このセクションで、私たちは、MPLSに関する基本概念のいくつかを紹介して、使用されるために一般的方法について説明します。
3.1. Labels
3.1. ラベル
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を特定するのに使用される局所的に重要な識別子です。 特定のパケットに置かれるラベルはそのパケットが割り当てられるForwarding Equivalence Classを表します。
Rosen, et al. Standards Track [Page 9] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[9ページ]。
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がLSRsであるなら、RuがパケットをRdに伝えるとき、Ruがラベル値Lがあるパケットでラベルを望んでいるのに同意するかもしれない、Thatがパケットが特定のFEC F.のメンバーである場合にだけあって、彼らは、パケットのために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がRuから通りに送られるもの以外のどんなパケットのためにも必ずFEC Fを表すというわけではないことに注意してください。 LはFとの結合がRuと通りに地方である任意の値です。
When we speak above of packets "being sent" from Ru to Rd, we do not imply either that the packet originated at Ru or that its destination is Rd. Rather, we mean to include packets which are "transit packets" at one or both of the LSRs.
私たちである、パケットの言葉の上を「送る」、RuからRdまで、私たちは、パケットがRuで由来したか、目的地が通りであると暗示しません。 むしろ、私たちは、LSRsの1か両方の「トランジットパケット」であるパケットを含んでいるのを意図します。
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を運ぶ到着パケットについてラベルLがある他のLSRでというよりむしろRuによってパケットに置かれたと言うのは、時々、難しいか、または不可能でさえあるかもしれません。 (RuとRdがダイレクト隣接物でないときに、これは通常そうになるでしょう。) そのような場合、Rdは、ラベルからFECまでの結合が1〜1であることを確実にしなければなりません。 また、異なったFEC F2にLを縛るのをある他のLSR Ru2に同意している間、すなわち、Rdは、FEC F1にLを縛るのをRu1に同意してはいけません、とUNLESS Rdはいつも言うことができます、入って来るラベルLでパケットを受けるとき、ラベルがRu1によってパケットに置かれたか、またはそれがRu2によって置かれたことにかかわらず。
It is the responsibility of each LSR to ensure that it can uniquely interpret its incoming labels.
唯一入って来るラベルを解釈できるのを保証するのは、それぞれのLSRの責任です。
3.2. Upstream and Downstream LSRs
3.2. 上流の、そして、川下のLSRs
Suppose Ru and Rd have agreed to bind label L to FEC F, for packets sent from Ru to Rd. Then with respect to this binding, Ru is the "upstream LSR", and Rd is the "downstream LSR".
RuとRdが、Ruから通りに送られたパケットで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つのノードが上流であり、1つが与えられた結合に関して川下であると言うのが特定のラベルが上流のノードから川下のノードまで旅行しながらパケットに特定のFECを表すだけであることを意味します。 これは、そのFECのパケットが実際に上流のノードから川下のノードまで発送されるのを含意することになっていません。
Rosen, et al. Standards Track [Page 10] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[10ページ]。
3.3. Labeled Packet
3.3. パケットとラベルされます。
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.
「ラベルされたパケット」はラベルがコード化されたパケットです。 いくつかの場合、ラベルは明確にこのために存在するカプセル化ヘッダーに住んでいます。 他の場合では、ラベルは既存のデータリンクかネットワーク層ヘッダーに住むかもしれません、そのために利用可能な分野がある限り。 ラベルをコード化する実体とラベルを解読する実体の両方が使用されるべき特定のコード化のテクニックに同意しなければなりません。
3.4. Label Assignment and Distribution
3.4. ラベル課題と分配
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を縛るという決定はその結合に関するDOWNSTREAMである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が、ある一定の数値範囲に落ちるラベルは見上げることができるだけであるように設計されるなら、それが、単にその範囲にあるラベルを縛るだけであるのを保証する必要があります。
3.5. Attributes of a Label Binding
3.5. ラベル結合の属性
A particular binding of label L to FEC F, distributed by Rd to Ru, may have associated "attributes". If Ru, acting as a downstream LSR, also distributes a binding of a label to FEC F, then under certain conditions, it may be required to also distribute the corresponding attribute that it received from Rd.
RdによってRuに分配されたFEC FへのラベルLの特定の結合は「属性」を関連づけたかもしれません。 また、川下のLSRとして機能して、Ruがラベルの結合をFEC Fに広げるなら、一定の条件の下で、通りから受信したのが、また、対応する属性を分配するのに必要であるかもしれません。
3.6. Label Distribution Protocols
3.6. ラベル分配プロトコル
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結合について別のものに知らせる1セットの手順です。 ラベル/FECの拘束力がある情報を交換するのにラベル分配プロトコルを使用する2LSRsが「ラベル分配同輩」として彼らが交換する拘束力がある情報に関して知られています。 2LSRsがラベル分配同輩であるなら、私たちはそこで彼らの間の「ラベル分配隣接番組」であるのについて話すつもりです。
(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.: 2LSRsが何らかのセットの結合に関するラベル分配同輩ですが、ある他のセットの結合に関する同輩であるかもしれないというわけではありません。)
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能力を知るために従事する必要があるどんな交渉も成就します。
Rosen, et al. Standards Track [Page 11] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[11ページ]。
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-自由民主党]、[MPLS-CR-自由民主党]を見てください。
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-自由民主党]で定義されたプロトコルを示すのに頭文字語「自由民主党」を使用しようとします。 一般に、ラベル分配プロトコルについて話すとき、私たちは頭文字語を避けようとします。
3.7. Unsolicited Downstream vs. Downstream-on-Demand
3.7. 川下では、川下要求次第に対して求められていません。
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は明らかに彼らを要求していないLSRsに結合を広げることができます。 これは「求められていない川下」ラベル分配として知られています。
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は、使用されるためにテクニックがどれであるかに同意しなければなりません。
3.8. Label Retention Mode
3.8. ラベル保有モード
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はLSR Rdから特定のFECで固まるラベルを受けるかもしれません(または、受信しました)、RdはそのFECのためのRuの次のホップ(もうRuのものは次のホップである)ではありませんが。
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がそのような結合の動向をおさえるなら、それは、すぐに、問題のFECのためにRdが結局次のホップになるなら再び結合を使用し始めるかもしれません。 Ruがそのような結合を捨てると、Rdが後で次のホップになるなら、結合は再取得されなければならないでしょう。
Rosen, et al. Standards Track [Page 12] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[12ページ]。
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のためにその次のホップでないLSRsから受け取られるラベルと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が多くの、より少ないラベルを維持するのを必要とします。
3.9. The Label Stack
3.9. ラベルスタック
So far, we have spoken as if a labeled packet carries only a single label. As we shall see, it is useful to have a more general model in which a labeled packet carries a number of labels, organized as a last-in, first-out stack. We refer to this as a "label stack".
今までのところ、まるでラベルされたパケットが単一のラベルだけを運ぶかのように私たちは話しました。 私たちが見るように、ラベルされたパケットが多くのラベルを運ぶより一般的なモデルがあるのは、役に立ちます、中で持続するとして(外で最初のスタック)、組織化されています。 私たちは「ラベルスタック」にこれについて言及します。
Although, as we shall see, MPLS supports a hierarchy, the processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that some number of other labels may have been "above it" in the past, or that some number of other labels may be below it at present.
私たちが見るようにMPLSは階層構造をサポートしますが、ラベルされたパケットの処理は階層構造のレベルから完全に独立しています。 処理はいつもトップラベルに基づいています、他の何らかの数のラベルが過去に「それ」にあったかもしれないか、またはそれの下に他の何らかの数のラベルが現在のところあるかもしれない可能性への尊敬なしで。
An unlabeled packet can be thought of as a packet whose label stack is empty (i.e., whose label stack has depth 0).
ラベルスタックが空であるパケットとしてラベルされていないパケットを考えることができます(すなわち、ラベルスタックには深さ0がある)。
If a packet's label stack is of depth m, we refer to the label at the bottom of the stack as the level 1 label, to the label above it (if such exists) as the level 2 label, and to the label at the top of the stack as the level m label.
パケットのラベルスタックが深さmのものであるなら、私たちはスタックの下部にレベル1が平らな2ラベルとしてそれ(そのようなものが存在しているなら)を上のラベルとラベルして、mがラベルするレベルとしてのスタックの先端のラベルとラベルを呼びます。
The utility of the label stack will become clear when we introduce the notion of LSP Tunnel and the MPLS Hierarchy (section 3.27).
私たちがLSP TunnelとMPLS Hierarchy(セクション3.27)の概念を紹介するとき、ラベルスタックに関するユーティリティは明確になるでしょう。
3.10. The Next Hop Label Forwarding Entry (NHLFE)
3.10. 次のホップラベル推進エントリー(NHLFE)
The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding a labeled packet. It contains the following information:
ラベルされたパケットを進めるとき、「次のホップラベル推進エントリー」(NHLFE)は使用されています。 それは以下の情報を含んでいます:
1. the packet's next hop
1. パケットの次のホップ
2. the operation to perform on the packet's label stack; this is one
of the following operations:
2. パケットのラベルスタックに実行する操作。 これは以下の操作の1つです:
a) replace the label at the top of the label stack with a
specified new label
a) ラベルスタックの先端でラベルを指定された新しいラベルに取り替えてください。
b) pop the label stack
b) ラベルスタックを飛び出させてください。
Rosen, et al. Standards Track [Page 13] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[13ページ]。
c) replace the label at the top of the label stack with a
specified new label, and then push one or more specified new
labels onto the label stack.
c) ラベルスタックの先端でラベルを指定された新しいラベルに取り替えてください、そして、次に、1個以上の指定された新しいラベルをラベルスタックに押してください。
It may also contain:
また、それは以下を含むかもしれません。
d) the data link encapsulation to use when transmitting the packet
d) パケットを伝えるとき使用するデータ・リンクカプセル化
e) the way to encode the label stack when transmitting the packet
e) パケットを伝えるときラベルスタックをコード化する方法
f) any other information needed in order to properly dispose of
the packet.
いかなる他の情報も適切にパケットを処分するために必要としたf)。
Note that at a given LSR, the packet's "next hop" might be that LSR itself. In this case, the LSR would need to pop the top level label, and then "forward" the resulting packet to itself. It would then make another forwarding decision, based on what remains after the label stacked is popped. This may still be a labeled packet, or it may be the native IP packet.
パケットの「次のホップ」が与えられたLSRでは、そのLSR自身であるかもしれないことに注意してください。 この場合、LSRはトップ平らなラベルを飛び出させて、次に、結果として起こるパケットをそれ自体に「進める」必要があるでしょう。 そして、それは積み重ねられたラベルが飛び出した後に残っているものに基づいて別の推進決定をするでしょう。 これはまだラベルされたパケットであるかもしれませんかそれがネイティブのIPパケットであるかもしれません。
This implies that in some cases the LSR may need to operate on the IP header in order to forward the packet.
これはLSRがパケットを進めるためにIPヘッダーの上に操作する必要があるかもしれないいくつかの場合でそれを含意します。
If the packet's "next hop" is the current LSR, then the label stack operation MUST be to "pop the stack".
「パケットの「次のホップ」が現在のLSRであるなら、ラベルスタック操作はスタックを飛び出す」ことでなければなりません。
3.11. Incoming Label Map (ILM)
3.11. 入って来るラベル地図(ILM)
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の1セットに写像します。 パケットとラベルされるように到着するパケットを進めるとき、それは使用されています。
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が1つ以上の要素を含むNHLFEsの1セットに特定のラベルを写像するなら、パケットを進める前にちょうどセットの1つの要素を選ばなければなりません。 セットから要素を選ぶための手順はこのドキュメントの範囲を超えています。 例えば、複数の等しい費用経路にわたってロードバランシングをするのが必要であるなら、ILMに1NHLFEを含むセットにラベルを写像させるのは、役に立つかもしれません。
3.12. FEC-to-NHLFE Map (FTN)
3.12. FECからNHLFEへの地図(FTN)
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の1セットに各FECを写像します。 ラベルされていない状態で到着しますが、進める前にラベルすることになっているパケットを進めるとき、それは使用されています。
Rosen, et al. Standards Track [Page 14] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[14ページ]。
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が1つ以上の要素を含むNHLFEsの1セットに特定のラベルを写像するなら、パケットを進める前にちょうどセットの1つの要素を選ばなければなりません。 セットから要素を選ぶための手順はこのドキュメントの範囲を超えています。 例えば、複数の等しい費用経路にわたってロードバランシングをするのが必要であるなら、FTNに1NHLFEを含むセットにラベルを写像させるのは、役に立つかもしれません。
3.13. Label Swapping
3.13. ラベルスワッピング
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.
ラベルスワッピングが使用中であるときに、次のホップがNHLFEからいつも取られることに注意するのは重要です。 MPLSが使用中でなかったなら、いくつかの場合、これは次のホップが何であるだろうかと異なっているかもしれません。
3.14. Scope and Uniqueness of Labels
3.14. ラベルの範囲とユニークさ
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と分配をラベルするためにその結合を広げるかもしれません。 ひもがも、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は、ラベルLをFEC F1に縛って、同輩Ru1と分配をラベルするためにその結合を広げるかもしれません。 ひもがも、FEC F2とLをラベルして、同輩Ru2と分配をラベルするためにその結合を第広げますように。 (唯一、)、第CAN(RU1かRU2によってそこへ置かれたか否かに関係なく、トップラベルがLであるパケットを受けて、次に、構造はそのF1=F2を必要としない)は、言います。 そのような場合、私たちは、RdがそれがRu1に分配するラベルにそれがRu2に分配するラベルと異なった「ラベルスペース」を使用していると言うかもしれません。
Rosen, et al. Standards Track [Page 15] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[15ページ]。
In general, Rd can only tell whether it was Ru1 or Ru2 that put the particular label value L at the top of the label stack if the following conditions hold:
一般に、Rdは、以下の条件が成立するならラベルスタックの先端に特定のラベル値Lを置くのが、Ru1かそれともRu2であったかを言うことができるだけです:
- Ru1 and Ru2 are the only label distribution peers to which Rd
distributed a binding of label value L, and
- そしてRu1とRu2がRdがラベル価値Lの結合を広げた唯一のラベル分配同輩である。
- Ru1 and Ru2 are each directly connected to Rd via a point-to-
point interface.
- Ru1とRu2はポイントからポイントへのインタフェースを通してそれぞれ直接Rdに接続されます。
When these conditions hold, an LSR may use labels that have "per interface" scope, i.e., which are only unique per interface. We may say that the LSR is using a "per-interface label space". When these conditions do not hold, the labels must be unique over the LSR which has assigned them, and we may say that the LSR is using a "per- platform label space."
これらの状態が成立すると、LSRはすなわち「インタフェース」単位で範囲を持っているラベルを使用するかもしれません(インタフェース単位でユニークであるだけです)。 私たちは、LSRが「1インタフェースあたりのラベルスペース」を使用していると言うかもしれません。 これらの状態が成立しないとき、ラベルがそれらを割り当てたLSRに関してユニークであるに違いなく、私たちが、LSRがaを使用していると言うかもしれない、「-、プラットホームのラベルスペース、」
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がポイントツーポイントが連結する特定のLSR Ruより多くのtwoに取り付けられるなら、RdはFEC F1へのラベルLの結合をRuに広げるかもしれません、FEC F2へのラベルLの結合と同様に、F1!=F2、Ruがa特定のものの上でRdに送るインタフェースのパケットだけに、それぞれの結合が有効である場合にだけ。 他のすべての場合では、Rdは2異なったFECsへの同じラベル価値の結合を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が複数の1プラットホームあたりのラベル空間を使用するか、または同じインタフェースに複数の1インタフェースあたりのラベル空間を使用するのが可能であるかどうかに関して質問は起こります。 これは構造によって禁止されません。 しかしながら、そのような場合LSRには、いくつかの手段が特定の入って来るラベルのためにそのラベルがどのラベルスペースに属すかを決定する構造によって指定されるのではなく、なければなりません。 例えば、[MPLS-SHIM]は、マルチキャストパケットと異なったラベルスペースがユニキャストパケットに使用されると指定して、2つのラベル空間を区別するのにデータ・リンク層codepointを使用します。
3.15. Label Switched Path (LSP), LSP Ingress, LSP Egress
3.15. ラベルが経路を切り換えた、(LSP)、LSPイングレス、LSP出口
A "Label Switched Path (LSP) of level m" for a particular packet P is a sequence of routers,
特定のパケットPのための「平らなmのラベルSwitched Path(LSP)」はルータの系列です。
<R1, ..., Rn>
<R1…, Rn>。
with the following properties:
以下の特性で:
Rosen, et al. Standards Track [Page 16] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[16ページ]。
1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's
label stack, resulting in a label stack of depth m;
1. 「LSPイングレス」というR1はPのラベルスタックにラベルを押すLSRです、深さmのラベルスタックをもたらして。
2. For all i, 1<i<n, P has a label stack of depth m when received
by LSR Ri;
2. すべてのi、1<i<nに関しては、Pには、LSR Riによって受け取られると、深さmのラベルスタックがあります。
3. At no time during P's transit from R1 to R[n-1] does its label
stack ever have a depth of less than m;
3. いかなる時も、ラベルスタックには、PのR1からR[n-1]までのトランジットの間、m以下の深さがありません。
4. For all i, 1<i<n: Ri transmits P to R[i+1] by means of MPLS,
i.e., by using the label at the top of the label stack (the
level m label) as an index into an ILM;
4. すべてのi、1<iの<nのために: RiはMPLSによってPからR[i+1]を伝えます、すなわち、インデックスとしてラベルスタック(mがラベルするレベル)の先端で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:
5. すべてのi、1<iの<nのために: RiがPを伝えた後にもかかわらず、R[i+1]でPを受け取る前以外に、システムSがPを受けて、進めるなら(例えば、RiとR[i+1]は切り換えられたデータ・リンクサブネットワークを通して接続されるかもしれません、そして、Sはデータタンブラ・スイッチの1つであるかもしれません)、Sの推進決定はmがレッテルを貼るレベル、または、ネットワーク層ヘッダーに基づいていません。 これがそうである、:
a) the decision is not based on the label stack or the network
layer header at all;
a) 決定はラベルスタックか全くネットワーク層ヘッダーに基づいていません。
b) the decision is based on a label stack on which additional
labels have been pushed (i.e., on a level m+k label, where
k>0).
すなわち、aに、m+kラベルを平らにしてください、どこ。b) 決定が追加ラベルが押されたラベルスタックに基づいている、(k>0)。
In other words, we can speak of the level m LSP for Packet P as the sequence of routers:
言い換えれば、私たちはPacket Pのためにルータの系列として平らなm LSPについて話すことができます:
1. which begins with an LSR (an "LSP Ingress") that pushes on a
level m label,
1. どれがLSRと共にそれが押す平らなmがラベルする(「LSPイングレス」)を始めるか。
2. all of whose intermediate LSRs make their forwarding decision
by label Switching on a level m label,
2. 中間的LSRsがだれのもので彼らの推進決定をするかに関するすべてが平らなmのSwitchingをラベルとラベルします。
3. which ends (at an "LSP Egress") when a forwarding decision is
made by label Switching on a level m-k label, where k>0, or
when a forwarding decision is made by "ordinary", non-MPLS
forwarding procedures.
3.0かいつ「普通」の、そして、非MPLSの推進手順で推進決定をするかという推進決定が平らなm kラベルの上のラベルSwitching、どこk>によってされるどの終わり(「LSP出口」の)。
A consequence (or perhaps a presupposition) of this is that whenever an LSR pushes a label onto an already labeled packet, it needs to make sure that the new label corresponds to a FEC whose LSP Egress is the LSR that assigned the label which is now second in the stack.
この結果(または、恐らく前提)はLSRが既にラベルされたパケットにラベルを押すときはいつも、新しいラベルがLSP Egressがスタックで現在2番目であるラベルを割り当てたLSRであるFECに対応するのを確実にするのが必要であるということです。
Rosen, et al. Standards Track [Page 17] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[17ページ]。
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.
私たちは、mがラベルするPのレベルがFEC Fに対応するラベルであるときに、それが特定のパケットPのための平らなmのLSPであるならLSRsの系列を「特定のFEC FのためのLSP」と呼ぶつもりです。
Consider the set of nodes which may be LSP ingress nodes for FEC F. Then there is an LSP for FEC F which begins with each of those nodes. If a number of those LSPs have the same LSP egress, then one can consider the set of such LSPs to be a tree, whose root is the LSP egress. (Since data travels along this tree towards the root, this may be called a multipoint-to-point tree.) We can thus speak of the "LSP tree" for a particular FEC F.
そこのFEC F.ThenのためのLSPイングレスノードであるかもしれないノードのセットがそれぞれのそれらのノードで始まるFEC FのためのLSPであると考えてください。 それらの多くのLSPsに同じLSP出口があるなら、人は、そのようなLSPsのセットが根がLSP出口である木であると考えることができます。 (データがこの木に沿って根に向かって移動するので、これは多点からポイントへの木と呼ばれるかもしれません。) その結果、私たちは特定のFEC Fのために「LSP木」について話すことができます。
3.16. Penultimate Hop Popping
3.16. 終わりから二番目のホップの飛び出し
Note that according to the definitions of section 3.15, if <R1, ..., Rn> is a level m LSP for packet P, P may be transmitted from R[n-1] to Rn with a label stack of depth m-1. That is, the label stack may be popped at the penultimate LSR of the LSP, rather than at the LSP Egress.
セクション3.15の定義に従って、<R1であるならそれに注意してください…, Rn>がパケットPのためのレベルm LSPである、Pは深さm-1のラベルスタックでR[n-1]からRnまで伝えられるかもしれません。 すなわち、ラベルスタックはLSP Egressでというよりむしろ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.
建築見解から、これは完全に適切です。 ラベルがRnへのパケットを得ることになっている平らなmの目的。 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-1LSPのための中間的ノードです。) スタックの上に他のラベルが全くなければ、ネットワーク層送付先アドレスに応じて、パケットを進めます。 これがTWOにルックアップをするために出口を必要とすることに注意してください、と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
終わりから二番目のノードは、次に、スタックを飛び出させて、以前に、スタックの先端にあったラベルを見上げることによって獲得された情報に基づくパケットを進めます。 LSP出口は受信されます。
Rosen, et al. Standards Track [Page 18] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[18ページ]。
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出口は単にネットワーク層パケットを見るでしょう。(それは、ちょうど推進決定をするように見るそれが必要があるものです)。
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:
ただ一つのルックアップだけが今までに必要であることが知られているなら、ラベル切り換え製品における、推進"fastpath"の創造は大いに支援されるかもしれません:
- the code may be simplified if it can assume that only a single
lookup is ever needed
- ただ一つのルックアップだけが今までに必要であると仮定できるなら、コードは簡素化されるかもしれません。
- the code can be based on a "time budget" that assumes that only
a single lookup is ever needed.
- コードはただ一つのルックアップだけが今までに必要であると仮定する「時間予算」に基づくことができます。
In fact, when penultimate hop popping is done, the LSP Egress need not even be an LSR.
事実上、終わりから二番目のホップであるときに、飛び出しをして、LSP EgressはLSRである必要さえありません。
However, some hardware switching engines may not be able to pop the label stack, so this cannot be universally required. There may also be some situations in which penultimate hop popping is not desirable. Therefore the penultimate node pops the label stack only if this is specifically requested by the egress node, OR if the next node in the LSP does not support MPLS. (If the next node in the LSP does support MPLS, but does not make such a request, the penultimate node has no way of knowing that it in fact is the penultimate node.)
しかしながら、いくつかのハードウェア切り換えエンジンがラベルスタックを飛び出させることができないかもしれないので、一般にこれを必要とすることができません。 また、終わりから二番目のホップの飛び出しが望ましくないいくつかの状況があるかもしれません。 したがって、これが出口ノードによって明確に要求される場合にだけ、終わりから二番目のノードはラベルスタックを飛び出させて、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 MUST NOTは、ラベルスタックを飛び出させるようラベル分配同輩に要求します。
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の規則を見るのが従われる限り、明白に容認されたパケットのトップラベルを解釈するのはいつも可能です。
Rosen, et al. Standards Track [Page 19] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[19ページ]。
3.17. LSP Next Hop
3.17. 次のLSPは跳びます。
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 Next Hopは次のホップであるLSRです、そのパケットを進めるのに使用されるNHLFEエントリーで選択されるように。
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 Next HopはそのFECに対応するラベルによって索引をつけられたNHLFEエントリーで選択されるように次のホップです。
Note that the LSP Next Hop may differ from the next hop which would be chosen by the network layer routing algorithm. We will use the term "L3 next hop" when we refer to the latter.
LSP Next Hopがネットワーク層ルーティング・アルゴリズムによって選ばれている次のホップと異なるかもしれないことに注意してください。 後者について言及するとき、私たちは「次のL3は跳ぶ」用語を使用するつもりです。
3.18. Invalid Incoming Labels
3.18. 無効の入って来るラベル
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.
したがって、無効の入って来るラベルでラベルされたパケットを受け取るときそれを捨てなければならなくて、それがいくつか決定しているUNLESSがそれを進めながらそれを意味する、(現在のドキュメントのいずれの範囲の中でもそうしません)ラベルされていなさ、少しの害も引き起こさない場合があります。
3.19. LSP Control: Ordered versus Independent
3.19. LSPは制御します: 無党派に対して注文します。
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.
いくつかのFECsが、ダイナミックルーティングアルゴリズムで分配される接頭語を記述するために対応しています。 2つの方法の1つでこれらのFECsのためのLSPsのセットアップができます: 独立しているLSPコントロールか命令された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 Controlでは、特定のFECを認識することに注意するとき、各LSRはそのFECにラベルを縛って、それを分配するという独立決議をラベル分配同輩にとって拘束力があるようにします。 これは従来のIPデータグラムルーティングが利く方法に対応しています。 各ノードは、どう各パケットを扱うかに関して独立決議をして、各データグラムが正しく届けられるのを確実にするために急速に一点に集まるようにルーティング・アルゴリズムを当てにします。
Rosen, et al. Standards Track [Page 20] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[20ページ]。
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.
Ordered LSP Controlでは、それがそのFECのための出口LSRである、またはそのFECのために既に次のホップからそのFECで固まるラベルを受けた場合にだけ、LSRは特定のFECにラベルを縛ります。
If one wants to ensure that traffic in a particular FEC follows a path with some specified set of properties (e.g., that the traffic does not traverse any node twice, that a specified amount of resources are available to the traffic, that the traffic follows an explicitly specified path, etc.) ordered control must be used. With independent control, some LSRs may begin label switching a traffic in the FEC before the LSP is completely set up, and thus some traffic in the FEC may follow a path which does not have the specified set of properties. Ordered control also needs to be used if the recognition of the FEC is a consequence of the setting up of the corresponding LSP.
人が、特定のFECの交通が何らかの指定されたセットの特性と共に小道をたどるのを保証したいなら(例えば、交通が二度どんなノードも横断しないで、指定された量のリソースが交通に利用可能であり、それが交通であることは明らかに指定された経路などに続いて起こります)、命令されたコントロールを使用しなければなりません。 独立制御で、LSPが完全にセットアップされる前にいくつかのLSRsが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のすべてのLSRsが命令されたコントロールを使用していない場合、ネットワークの振舞いへの総合的な効果は主に独立制御のものです、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は1かもう片方だけを支持しなければなりません。 概して、独立者対命令されたコントロールの選択は定義される必要があるラベル分配メカニズムにどんな影響も与えるように見えません。
3.20. Aggregation
3.20. 集合
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?
交通をFECsに仕切る1つの方法は経路指定テーブルに現れるそれぞれのアドレス接頭語のために別々のFECを作成することです。 しかしながら、特定のMPLSドメインの中では、これがFECsの1セットをもたらすかもしれないので、それらのすべてのFECsのすべての交通が同じルートに続いて起こります。 例えば、1セットの異なったアドレス接頭語にはすべて、同じ出口ノードがあるかもしれません、そして、ラベルスワッピングは使用されるかもしれませんが、出口ノードから交通を抜きます。 この場合、それらのFECsの組合はそれ自体でMPLSドメインの中では、FECです。 これは選択を作成します: 異なったラベルが各コンポーネントFECに縛られるべきですか、または単一のラベルは組合、および組合のすべての交通に適用されたそのラベルに縛られるべきですか?
The procedure of binding a single label to a union of FECs which is itself a FEC (within some domain), and of applying that label to all
それ自体でFEC(何らかのドメインの中の)であるFECsの組合に単一のラベルを縛って、そのラベルをすべてに適用する手順
Rosen, et al. Standards Track [Page 21] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[21ページ]。
traffic in the union, is known as "aggregation". The MPLS architecture allows aggregation. Aggregation may reduce the number of labels which are needed to handle a particular set of packets, and may also reduce the amount of label distribution control traffic needed.
組合を売買して、「集合」として知られています。 MPLS構造は集合を許容します。 集合は、特定のセットのパケットを扱うのが必要であるラベルの数を減少させて、また、交通が必要としたラベル配給統制の量を減少させるかもしれません。
Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (c) being the "finest granularity".
独身のFECに「「集合-可能」な」FECsの1セットを考えて、(a) 集合彼らにとって、FEC、(b)が彼らをFECsの1セット、または(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はFECsの与えられたセットのためにそれらのFECsに次のホップによって使用される粒状を採用するはずです。
When independent control is used, it is possible that there will be two adjacent LSRs, Ru and Rd, which aggregate some set of FECs differently.
独立制御が使用されているとき、2隣接しているLSRs、Ru、およびRdがあるのは、可能です。(RdはFECsの何らかのセットに異なって集めます)。
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はFECsのそのセットのためにRdが分配するよりさらに多くのラベルを分配します。 これは、Ruが、それらのFECsでラベルされたパケットをRdに送る必要があると、mラベル、どこにnラベルをn>m写像するかが必要であるかもしれないことを意味します。 オプションとして、Ruはそれが分配したnラベルのセットを撤退して、次に、1セットのmラベルを分配するかもしれません、Rdの粒状のレベルに対応しています。 Ruによって分配されたラベルの数の減少をもたらします、そして、これは正しい操作を確実にするのに必要ではありませんが、Ruは多くのラベルを分配することによって、少しの特定の利点も獲得していません。 これをするかどうかという決定は地域にかかわる事柄です。
If Ru has coarser granularity than Rd (i.e., Rd has distributed n labels for the set of FECs, while Ru has distributed m, where n > m), it has two choices:
RuにRdより粗い粒状があるなら(すなわち、RdはFECsのセットのためにnラベルを分配しました、Ruがm、どこをn>m分配したか、しかし、)、それには、2つの選択があります:
- It may adopt Rd's finer level of granularity. This would
require it to withdraw the m labels it has distributed, and
distribute n labels. This is the preferred option.
- それはRdの、よりすばらしいレベルの粒状を採用するかもしれません。 これは、それが分配したmラベルを引っ込めるためにそれを必要として、nラベルを分配するでしょう。 これは都合のよいオプションです。
- It may simply map its m labels into a subset of Rd's n labels,
if it can determine that this will produce the same routing.
For example, suppose that Ru applies a single label to all
traffic that needs to pass through a certain egress LSR,
whereas Rd binds a number of different labels to such traffic,
depending on the individual destination addresses of the
packets. If Ru knows the address of the egress router, and if
Rd has bound a label to the FEC which is identified by that
address, then Ru can simply apply that label.
- それは単にRdのnラベルの部分集合にmラベルを写像するかもしれません、これが同じルーティングを作成することを決定できるなら。 例えば、そのRuが単一のラベルを適用するなら、必要があるすべての交通にLSRはある出口を通って向かっていますが、Rdは多くの異なったラベルをそのような交通に縛ります、パケットの個々の送付先アドレスによって。 Ruが出口ルータのアドレスを知って、Rdがそのアドレスによって特定されるFECにラベルを縛ったなら、Ruは単にそのラベルを適用できます。
Rosen, et al. Standards Track [Page 22] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[22ページ]。
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ネットワークを出るFECsで粒状を知るために各ノードを必要とします。 独立制御において、すべてのLSRsが各FECで粒状を知るために一貫して構成されるのを確実にすることによって、最も良い結果を得るかもしれません。 しかしながら、多くの場合、すべてのFECs(「推進テーブルのIP接頭語あたり1個のラベル」、または「出口ノードあたり1個のラベル」などの)に適用されるただ一つのレベルの粒状を使用することによって、これをするかもしれません。
3.21. Route Selection
3.21. ルート選択
Route selection refers to the method used for selecting the LSP for a particular FEC. The proposed MPLS protocol architecture supports two options for Route Selection: (1) hop by hop routing, and (2) explicit routing.
ルート選択は特定のFECのためにLSPを選択するのに使用される方法を示します。 提案されたMPLSプロトコル構造はRoute Selectionのために2つのオプションをサポートします: (1) ホップルーティング、および(2)の明白なルーティングで、跳んでください。
Hop by hop routing allows each node to independently choose the next hop for each FEC. This is the usual mode today in existing IP networks. A "hop by hop routed LSP" is an LSP whose route is selected using hop by hop routing.
ホップルーティングによるホップで、各ノードは独自に各FECのための次のホップを選ぶことができます。 これは既存のIPネットワークで今日の普通のモードです。 「ホップの発送されたLSPによるホップ」はルートがホップルーティングでホップを使用することで選択されるLSPです。
In an explicitly routed LSP, each LSR does not independently choose the next hop; rather, a single LSR, generally the LSP ingress or the LSP egress, specifies several (or all) of the LSRs in the LSP. If a single LSR specifies the entire LSP, the LSP is "strictly" explicitly routed. If a single LSR specifies only some of the LSP, the LSP is "loosely" explicitly routed.
明らかに発送されたLSPでは、各LSRは独自に次のホップを選びません。 むしろ、独身のLSR(一般にLSPイングレスかLSP出口)はLSPでLSRsの数個(すべて)を指定します。 独身の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によって続かれたLSRsの系列は、構成によって選ばれているか、またはただ一つのノードによってダイナミックに選択されるかもしれません(例えば、出口ノードはその出口ノードにおける木の結末のために全体の経路を計算するためにリンク州のデータベースから学習された位相的な情報を利用するかもしれません)。
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.
明白なルートを利用するための厳しいか、またはゆるい手順は、このドキュメントの範囲を超えています。
Rosen, et al. Standards Track [Page 23] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[23ページ]。
3.22. Lack of Outgoing Label
3.22. 出発しているラベルの不足
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.
或るものは外にこのドキュメント)その範囲を意味します。決定できない、(通じて、これらの状況のどちらも入手しない、唯一の安全な方法はパケットを捨てることです。
3.23. Time-to-Live (TTL)
3.23. 生きる時間(TTL)
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.
これはmisconfigurationsのため、または失敗のため存在するかもしれない推進輪に対する何らかのレベルの保護かルーティング・アルゴリズムの遅い集合を提供します。 TTLは他の機能に良い、そして、マルチキャストの見るのなどように「トレースルート」コマンドをサポートするとして時々使用されます。 これは、MPLSが対処する必要がある関連する2TTL冊があるのを含意します: (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に沿って移動します、それ。いつ、切り換えられたラベルであったのなしでルータの同じ系列を横断したなら、SHOULDはそれが持っていたのと同じTTL値で現れるか。 それであるときに、LSPsの階層構造、LSRホップの横断されたSHOULDの総数に沿ったパケット旅行がTTLで反射しているなら、値はLSPsの階層構造から出て来ます。
Rosen, et al. Standards Track [Page 24] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[24ページ]。
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].
MPLSラベル値がMPLS特有の「詰め物」ヘッダー[MPLS- SHIM]で運ばれるかどうか、またはMPLSラベルがL2ヘッダーで運ばれるかどうかによって、TTLが扱われる方法は異なるかもしれません、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.
ラベル値がデータ・リンクとネットワーク層ヘッダーの間に座る「詰め物」でコード化されるなら、SHOULD、ネットワーク層ヘッダーTTL分野からロードされて、初めはSHOULDがそうであるTTL分野は各LSR-ホップ、およびSHOULDでこの詰め物で減少しなければなりません。パケットが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".
ラベル値がデータ・リンク層でコード化されるなら、それ自体ではなく、L2スイッチ(例えば、ATMスイッチ)で(例えば、ATMのAAL5ヘッダーのVPI/VCI分野)、およびラベルされたパケットを進めて、データ・リンク層(ATMのような)がするヘッダーがTTL分野を持って、次に、各LSR-ホップでパケットのTTLを減少させるのは可能でないでしょう。 パケットのTTLを減少させることができないLSRsの系列から成る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.
aであるときに、パケットは非TTL LSPセグメントから出て来て、それはSHOULDです。しかしながら、それが横断したLSR-ホップの数を反映するTTLをお願いします。 ユニキャスト場合では、重要なLSPの長さをイングレスノードに伝播することによって、これを達成できます、非TTL LSPセグメントにパケットを送る前にイングレスがTTL値を減少させるのを可能にして。
Sometimes it can be determined, upon ingress to a non-TTL LSP segment, that a particular packet's TTL will expire before the packet reaches the egress of that non-TTL LSP segment. In this case, the LSR at the ingress to the non-TTL LSP segment must not label switch the packet. This means that special procedures must be developed to support traceroute functionality, for example, traceroute packets may be forwarded using conventional hop by hop forwarding.
時々、非TTL LSPセグメントへのイングレスでパケットがその非TTL LSPセグメントの出口に達する前に特定のパケットのTTLが期限が切れることを決定できます。 この場合、非TTL LSPセグメントへのイングレスにおけるLSRはパケットとスイッチをラベルしてはいけません。 これは、トレースルートの機能性を支持するために特別な手順を開発しなければならないことを意味します、例えば、ホップ推進で従来のホップを使用することでトレースルートパケットを進めるかもしれません。
3.24. Loop Control
3.24. ループ制御
On a non-TTL LSP segment, by definition, TTL cannot be used to protect against forwarding loops. The importance of loop control may depend on the particular hardware being used to provide the LSR functions along the non-TTL LSP segment.
非TTL LSPセグメントでは、定義上、推進輪から守るのにTTLを使用できません。 ループ制御の重要性は、非TTL LSPセグメントに沿ってLSR機能を提供するのに使用されることで特定のハードウェアによるかもしれません。
Suppose, for instance, that ATM switching hardware is being used to provide MPLS switching functions, with the label being carried in the VPI/VCI field. Since ATM switching hardware cannot decrement TTL, there is no protection against loops. If the ATM hardware is capable of providing fair access to the buffer pool for incoming cells carrying different VPI/VCI values, this looping may not have any deleterious effect on other traffic. If the ATM hardware cannot
例えば、ATM切り換えハードウェアがスイッチング関数をMPLSに供給するのに使用されていると仮定してください、ラベルがVPI/VCI分野で運ばれている状態で。 ATM切り換えハードウェアがTTLを減少させることができないので、ノー・プロテクションは輪に反対しています。 ATMハードウェアが異なったVPI/VCI値を運びながらバッファプールへの公正なアクセスを入って来るセルに提供できるなら、このループはどんな有害な影響も他の交通に与えないかもしれません。 ATMハードウェアがそうすることができないなら
Rosen, et al. Standards Track [Page 25] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[25ページ]。
provide fair buffer access of this sort, however, then even transient loops may cause severe degradation of the LSR's total performance.
しかしながら、当時の同等の一時的な輪がLSRの総性能の厳しい退行を引き起こすかもしれないこの種類の公正なバッファアクセスを提供してください。
Even if fair buffer access can be provided, it is still worthwhile to have some means of detecting loops that last "longer than possible". In addition, even where TTL and/or per-VC fair queuing provides a means for surviving loops, it still may be desirable where practical to avoid setting up LSPs which loop. All LSRs that may attach to non-TTL LSP segments will therefore be required to support a common technique for loop detection; however, use of the loop detection technique is optional. The loop detection technique is specified in [MPLS-ATM] and [MPLS-LDP].
公正なバッファアクセスを提供できても、「可能であるより長い間に」続く輪を検出するいくつかの手段を持つまだ価値があります。 それはどの輪をLSPsに設定するかを避けるために実用的であるところでさらに、どこさえTTL、そして/または、1VCあたりの公正な列を作りが生き残っている輪に手段を供給するかがまだ望ましいかもしれません。 したがって、非TTL LSPセグメントに付くかもしれないすべてのLSRsが輪の検出のための一般的なテクニックをサポートするのに必要でしょう。 しかしながら、輪の検出のテクニックの使用は任意です。 輪の検出のテクニックは[MPLS-ATM]と[MPLS-自由民主党]で指定されます。
3.25. Label Encodings
3.25. ラベルEncodings
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.
コンクリートを定義するために、ラベルのコード化が積み重ねられるのがラベルがそれを積み重ねるパケットに伴うラベルスタックが伝わるそうであることが必要です。 構造はいくつかの異なったコード化のテクニックをサポートします。 テクニックをコード化することのこの選択はラベルされたパケットを進めるのに使用される特定の種類の装置次第です。
3.25.1. MPLS-specific Hardware and/or Software
3.25.1. MPLS特有のハードウェア、そして/または、ソフトウェア
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".
1つが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]で指定されます。
3.25.2. ATM Switches as LSRs
3.25.2. LSRsとしての気圧スイッチ
It will be noted that MPLS forwarding procedures are similar to those of legacy "label swapping" switches such as ATM switches. ATM switches use the input port and the incoming VPI/VCI value as the index into a "cross-connect" table, from which they obtain an output port and an outgoing VPI/VCI value. Therefore if one or more labels can be encoded directly into the fields which are accessed by these legacy switches, then the legacy switches can, with suitable software upgrades, be used as LSRs. We will refer to such devices as "ATM- LSRs".
MPLS推進手順がATMスイッチなどの遺産「ラベルスワッピング」スイッチのものと同様であることに注意されるでしょう。 ATMスイッチはインデックスとして「十字接続」テーブルに入力ポートと入って来るVPI/VCI値を使用します。(それらはそれから出力ポートと外向的なVPI/VCI値を入手します)。 したがって、直接これらの遺産スイッチによってアクセスされる分野に1個以上のラベルをコード化できるなら、適当なソフトウェアの更新で、LSRsとして遺産スイッチを使用できます。 私たちは「気圧LSRs」のような装置について言及するつもりです。
Rosen, et al. Standards Track [Page 26] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[26ページ]。
There are three obvious ways to encode labels in the ATM cell header (presuming the use of AAL5):
ATMセルヘッダーでラベルをコード化する3つの当たり前の方法があります(AAL5の使用を推定して):
1. SVC Encoding
1. SVCコード化
Use the VPI/VCI field to encode the label which is at the top
of the label stack. This technique can be used in any network.
With this encoding technique, each LSP is realized as an ATM
SVC, and the label distribution protocol becomes the ATM
"signaling" protocol. With this encoding technique, the ATM-
LSRs cannot perform "push" or "pop" operations on the label
stack.
VPI/VCI分野を使用して、ラベルスタックの先端にあるラベルをコード化してください。 どんなネットワークにもこのテクニックを使用できます。 これがテクニックをコード化していて、各LSPはATM SVCとして実感されます、そして、ラベル分配プロトコルはATM「シグナリング」プロトコルになります。 これがテクニックをコード化していて、ATM- LSRsは「プッシュ」を実行できませんし、ラベルスタックで操作を「飛び出させることができません」。
2. SVP Encoding
2. SVPコード化
Use the VPI field to encode the label which is at the top of
the label stack, and the VCI field to encode the second label
on the stack, if one is present. This technique some
advantages over the previous one, in that it permits the use of
ATM "VP-switching". That is, the LSPs are realized as ATM
SVPs, with the label distribution protocol serving as the ATM
signaling protocol.
VPI分野を使用して、スタックの上の2番目のラベルをコード化するためにラベルスタックの先端、およびVCI分野にあるラベルをコード化してください、1つが存在しているなら。 或るものが前のものの上でATMの「VP-切り換え」の使用を可能にするという点に役立つこのテクニック。 ATMシグナリングが議定書を作るのでラベル分配プロトコルが役立っていて、すなわち、LSPsはATM SVPsとして実感されます。
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 Virtual Pathを含んでいるなら、VPI分野は必ずMPLSによる使用に利用可能であるというわけではありません。
When this encoding technique is used, the ATM-LSR at the egress
of the VP effectively does a "pop" operation.
このコード化のテクニックが使用されているとき、事実上、VPの出口のATM-LSRは「ポップス」操作をします。
3. SVP Multipoint Encoding
3. SVP多点コード化
Use the VPI field to encode the label which is at the top of
the label stack, use part of the VCI field to encode the second
label on the stack, if one is present, and use the remainder of
the VCI field to identify the LSP ingress. If this technique
is used, conventional ATM VP-switching capabilities can be used
to provide multipoint-to-point VPs. Cells from different
packets will then carry different VCI values. As we shall see
in section 3.26, this enables us to do label merging, without
running into any cell interleaving problems, on ATM switches
which can provide multipoint-to-point VPs, but which do not
have the VC merge capability.
VPI分野を使用して、ラベルスタックの先端にあるラベルをコード化してください、1つが存在しているなら、VCI分野の一部を使用して、スタックの上の2番目のラベルをコード化してください、VCI分野の残りを使用して、LSPイングレスを特定してください。 このテクニックが使用されているなら、多点からポイントへのVPsを提供するのに従来のATM VP-スイッチング能力を使用できます。 そして、異なったパケットからのセルは異なったVCI値を運ぶでしょう。 私たちがセクション3.26で見るように、これは、私たちがラベル合併をするのを可能にします、どんなセルインターリービング問題も出くわさないで、多点からポイントへのVPsを提供できますが、VCが能力を合併しないATMスイッチの上に。
This technique depends on the existence of a capability for
assigning 16-bit VCI values to each ATM switch such that no
single VCI value is assigned to two different switches. (If an
このテクニックは、どんなただ一つのVCI値も2個の異なったスイッチに割り当てられないように16ビットのVCI値をそれぞれのATMスイッチに割り当てるために能力の存在に依存します。 (
Rosen, et al. Standards Track [Page 27] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[27ページ]。
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.)
そのような適切な数の値を各スイッチに割り当てることができて、また、スタックにおける2番目のラベルとして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 encodingsを結合しなければなりません。
3.25.3. Interoperability among Encoding Techniques
3.25.3. テクニックをコード化する中の相互運用性
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であるなら、パケットPをR2に伝えるとき、R1がラベルスタックのあるコード化を使用しますが、パケットPをR3に伝えるときR2がa異なったコード化を使用するのは、R2、R3>がLSPのセグメントであることが可能です。 一般に、異なったラベルスタックencodingsが異なったホップの上で使用されている状態で、MPLS構造はLSPsを支持します。 したがって、ラベルされたパケットを処理するための手順について議論するとき、私たちはパケットのラベルスタックを作動させる抽象名辞で話します。 ラベルされたパケットが受け取られていると、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スイッチには、テクニックをコード化する1つ〜別のものまで翻訳するための能力が全くありません。 したがって、MPLS構造は、ATMが切り替わる2に、平らなmに沿った連続したLSRsが、あるパケットのためのLSPであったなら可能であり、それがATMスイッチが同じように使用するそれらの2であるときはいつも、テクニックをコード化しながら、それを必要とします。
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詰め物のヘッダーを使用することで作動するLSRs、および他のLSRsとして作動するATMスイッチの組み合わせを含むMPLSネットワークがあるでしょう。 そのようなネットワークには、「MPLS詰め物」インタフェースと同様にATMインタフェースを持っているいくつかのLSRsがあるかもしれません。 これは異なったホップの上に異なったラベルスタックencodingsがあるLSRに関する1つの例です。 LSRがATMで交換するかもしれないそのようなものは、入って来るインタフェースでラベルスタックをコード化して、それをコード化されたラベルが外向的なインタフェースで積み重ねるMPLS詰め物のヘッダーに取り替えます。
3.26. Label Merging
3.26. ラベル合併
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つは同じ出発しているラベルでそれらを進めたがっています。 そうする能力は「ラベル合併」として知られています。
Rosen, et al. Standards Track [Page 28] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[28ページ]。
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.
異なったインタフェース、または異なったラベルと共に到着するどんな2つのパケットに関しても、パケットに、異なったインタフェースから伝えなければならないか、または異なったラベルがなければならないなら、LSRがラベル合併できないと言いましょう。 SVCかSVP Encodingsを使用するATM-LSRsはラベル合併を実行できません。 さらに詳細に次のセクションでこれについて議論します。
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.
同じFECの2つのパケットが異なった入って来るラベルと共に到着して、特定のLSRがラベル合併を実行できないなら、異なった出発しているラベルでそれらを進めなければなりません。 ラベル合併で、1FECあたりの出発しているラベルの数は1であるだけでよいです。 ラベル合併がなければ、1FECあたりの出発しているラベルの数はネットワークにおける、ノードの数と同じくらい大きいかもしれません。
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.
ラベル合併で、1特定のLSRが必要とするFECあたりの入って来るラベルの数はラベル分配隣接番組の数より決して大きくないことです。 ラベル合併がなければ、1特定のLSRが必要とするFECあたりの入って来るラベルの数はFECの交通を問題のLSRに送る上流のノードの数と同じくらい大きいです。 事実上、LSRがそれが特定のFECのために支えなければならないそのような入って来る何ラベルを決定するのさえ、難しいです。
The MPLS architecture accommodates both merging and non-merging LSRs, but allows for the fact that there may be LSRs which do not support label merging. This leads to the issue of ensuring correct interoperation between merging LSRs and non-merging LSRs. The issue is somewhat different in the case of datagram media versus the case of ATM. The different media types will therefore be discussed separately.
MPLS構造は、合併と非合併しているLSRsの両方を収容しますが、ラベル合併を支持しないLSRsがあるかもしれないという事実を考慮します。 これはLSRsと非合併しているLSRsを合併するとき正しいinteroperationを確実にする問題に通じます。 問題はデータグラムメディア対ATMに関するケースの場合においていくらか異なっています。 したがって、別々に異なったメディアタイプについて議論するでしょう。
3.26.1. Non-merging LSRs
3.26.1. 非合併しているLSRs
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とFrame Relayのような技術で用いられた推進手順と非常に同様です。 すなわち、データのユニットは到着します、そして、ラベル(VPI/VCIかDLCI)は「十字接続テーブル」で調べられます、そして、そのルックアップに基づいて出力ポートは選ばれています、そして、ラベル値は書き直されます。 事実上、MPLS推進にそのような技術を使用するのは可能です。 十字接続テーブルをセットアップするのに「合図プロトコル」としてラベル分配プロトコルを使用できます。
Rosen, et al. Standards Track [Page 29] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[29ページ]。
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では、1つが、ラベル合併を実行するのを試みるなら、結果は様々なパケットからのセルのインターリービングであるかもしれません。 異なったパケットからのセルがはさみ込まれるなら、パケットを組み立て直すのは不可能です。 いくつかのFrame Relayスイッチがそれらのバックプレーンのセルの切り換えを使用します。 また、これらのスイッチはラベル合併を支持できないかもしれません、同じ理由から--異なったパケットのセルははさみ込まれるかもしれません、そして、その時、パケットを組み立て直す方法が全くありません。
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は非合併しているLSRsの使用を許す手順を含むでしょう。 2番目に、MPLSはあるATMスイッチがLSRsを合併するとして機能する手順を支持するでしょう。
Since MPLS supports both merging and non-merging LSRs, MPLS also contains procedures to ensure correct interoperation between them.
MPLSが合併と非合併しているLSRsの両方を支持するので、また、MPLSはそれらの間で正しいinteroperationを確実にする手順を含んでいます。
3.26.2. Labels for Merging and Non-Merging LSRs
3.26.2. 合併するためのラベルと非合併しているLSRs
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は、1FECあたり1個のラベルだけが送られる必要があります。 上流のサポートラベル合併ではなく、そうする隣人が、複数の1FECあたりのラベルが送られる必要があります。 しかしながら、それがいくつのラベルを必要とするかを先験的に知る方法が全くありません。 これはいくつのLSRsがそれのFECに関する問題の上流であるかによるでしょう。
In the MPLS architecture, if a particular upstream neighbor does not support label merging, it is not sent any labels for a particular FEC unless it explicitly asks for a label for that FEC. The upstream neighbor may make multiple such requests, and is given a new label each time. When a downstream neighbor receives such a request from upstream, and the downstream neighbor does not itself support label merging, then it must in turn ask its downstream neighbor for another label for the FEC in question.
MPLS構造では、そのFECのために明らかにラベルを求めないで、また特定の上流の隣人がラベル合併を支持しないなら、どんなラベルも特定のFECのためにそれに送られません。 上流の隣人にそのようなものが要求する倍数を作るかもしれなくて、各回新しいラベルを与えます。 川下の隣人が上流からそのような要求を受け取って、川下の隣人がサポートラベル合併をそれ自体にするというわけではないなら、それは問題のFECのために順番に川下の隣人に別のラベルを求めなければなりません。
It is possible that there may be some nodes which support label merging, but can only merge a limited number of incoming labels into a single outgoing label. Suppose for example that due to some hardware limitation a node is capable of merging four incoming labels into a single outgoing label. Suppose however, that this particular node has six incoming labels arriving at it for a particular FEC. In this case, this node may merge these into two outgoing labels.
限られた数の入って来るラベルを単一の出発しているラベルに合併できるだけであって、ラベル合併を支えるいくつかのノードがあるのは、可能です。 例えば、何らかのハードウェア制限のため、ノードが4個の入って来るラベルを単一の出発しているラベルに合併できると仮定してください。 しかしながら、思ってください、そして、この特定のノードには6入来があるのが特定のFECのためにそれへの到着をラベルします。 この場合、このノードは2個の出発しているラベルにこれらを合併するかもしれません。
Whether label merging is applicable to explicitly routed LSPs is for further study.
さらなる研究にはラベル合併が明らかに発送されたLSPsに適切であるかどうかがあります。
Rosen, et al. Standards Track [Page 30] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[30ページ]。
3.26.3. Merge over ATM
3.26.3. 気圧で、合併してください。
3.26.3.1. Methods of Eliminating Cell Interleave
3.26.3.1. セルインタリーブを排除する方法
There are several methods that can be used to eliminate the cell interleaving problem in ATM, thereby allowing ATM switches to support stream merge:
セルインターリービング問題を解決するのに使用できるいくつかの方法がATMにあります、その結果、ATMスイッチが流れのマージを支持するのを許容します:
1. VP merge, using the SVP Multipoint Encoding
1. SVP Multipoint Encodingを使用して、VPは合併します。
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の中で異なったVCIsを使用することによって、区別されます。
2. VC merge
2. VCは合併します。
When VC merge is used, switches are required to buffer cells
from one packet until the entire packet is received (this may
be determined by looking for the AAL5 end of frame indicator).
VCマージが使用されているとき、スイッチが、全体のパケットが受け取られているまで(これはフレームインディケータのAAL5端を探すことによって、決定するかもしれません)1つのパケットからセルをバッファリングするのに必要です。
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スペースをコーディネートに要求します。 これを達成できる多くの方法があります。 さらなる研究には1つ以上の方法の品揃えがあります。
This tradeoff between compatibility with existing equipment versus protocol complexity and scalability implies that it is desirable for the MPLS protocol to support both VP merge and VC merge. In order to do so each ATM switch participating in MPLS needs to know whether its immediate ATM neighbors perform VP merge, VC merge, or no merge.
既存の設備との互換性対プロトコルの複雑さとスケーラビリティの間のこの見返りは、MPLSプロトコルに、VPが合併して、VCが合併するのが、サポートの両方に望ましいのを含意します。 そう即座のATM隣人がVPマージを実行するか否かに関係なく、VCが合併するか、いいえを知るMPLSの必要性に参加するそれぞれのATMスイッチをするには、合併してください。
3.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge
3.26.3.2. Interoperation: VCマージ、VPマージ、および非マージ
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の上の様々なフォームの合併のinteroperationは、最初に非マージでVCマージのinteroperationについて説明することによって、最も容易に説明されます。
In the case where VC merge and non-merge nodes are interconnected the forwarding of cells is based in all cases on a VC (i.e., the concatenation of the VPI and VCI). For each node, if an upstream neighbor is doing VC merge then that upstream neighbor requires only a single VPI/VCI for a particular stream (this is analogous to the requirement for a single label in the case of operation over frame media). If the upstream neighbor is not doing merge, then the
VCが合併して、非マージノードがインタコネクトされる場合では、セルの推進はすべての場合でVC(すなわち、VPIとVCIの連結)に基づいています。 各ノードに関しては、上流の隣人がVCをしているなら、上流の隣人が特定の流れのために独身のVPI/VCIだけを必要とするのについて(これはフレームメディアの上の操作の場合における単一のラベルのための要件に類似しています)その時、合併してください。 上流の隣人であるなら、そしてするのはマージではありません。
Rosen, et al. Standards Track [Page 31] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[31ページ]。
neighbor will require a single VPI/VCI per stream for itself, plus enough VPI/VCIs to pass to its upstream neighbors. The number required will be determined by allowing the upstream nodes to request additional VPI/VCIs from their downstream neighbors (this is again analogous to the method used with frame merge).
隣人は、それ自体のための流れ単位で独身のVPI/VCIを必要として、通ることができるくらいのVPI/VCIsを上流の隣人への必要になるでしょう。 上流のノードが彼らの川下の隣人から追加VPI/VCIsを要求するのを許容することによって、注文数は決定するでしょう(これは再び、フレームマージと共に使用される方法に類似しています)。
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/VCIsを要求するよりむしろVPの中の独身のVP(VPIによって特定される)にもかかわらず、数個のVCIsを要求するかもしれません。 その上、非マージノードが2つの異なったVPマージノードから川下であると仮定してください。 このノードは、1VPI/VCI(それ自体から発する交通への)と2VPs(それぞれの上流のノードあたり1つ)を要求する必要があるかもしれません、それぞれVCIsの指定されたセットに関連している、(要求された通り、上流のノード)
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マージ、および非マージのすべてを支持するために、したがって、VCs(VCIsの1セットで、どれがVPの中で重要であるかを特定する)の指定された数を含んで、要求へのノードにゼロの組み合わせを許すか、または上流へより多くのVC識別子(VPI/VCIから成る)、プラスゼロまたは、より多くのVPsに(VPIsによって特定されます)それぞれを許容するのが必要です。 したがって、VPマージノードは上から要求された各VC(VCが含んでいるVPの一部であるかどうかにかかわらず)のためにそれが溯源する(適切であるなら)交通への含まれたVCIとVCIと共に1VPを要求するでしょう。 VCマージノードは独身のVPI/VCIだけを要求するでしょう(彼らがすべての上流の交通を独身のVCに合併できるので)。 非マージノードは溯源する交通にVPI/VCIを上から届けて、要求するという(適切であるなら)どんな要求も伝えるでしょう。
3.27. Tunnels and Hierarchy
3.27. トンネルと階層構造
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は特定のパケットが別のルータRdに渡されることを引き起こすために明白な行動を取ります、RuとRdはそのパケットのためのホップによるHop経路の連続したルータではありません、そして、Rdはパケットの最終仕向地ではありませんが。 例えば、送付先アドレスがRd自身のアドレスであるネットワーク層パケットにパケットをカプセルに入れることによって、これをするかもしれません。 これはRuから通りまで「トンネル」を作成します。 私たちはどんな「トンネルを堀られたパケット」と同じくらい扱われたパケットについても言及します。
3.27.1. Hop-by-Hop Routed Tunnel
3.27.1. ホップごとの発送されたトンネル
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.
Tunneled PacketがRuからRdまでのホップによるHop経路に続くなら、私たちが、それが「ホップごとに発送されたトンネル」にあると言う、だれのもの、「終点を伝えてください」がRuと「終点を受けてください」がだれのものであるということである、通り
Rosen, et al. Standards Track [Page 32] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[32ページ]。
3.27.2. Explicitly Routed Tunnel
3.27.2. 明らかに発送されたトンネル
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.
Tunneled PacketがホップによるHop経路以外の経路の上をRuからRdまで旅行するなら、私たちが、それが「明らかに発送されたトンネル」にあると言う、だれのもの、「終点を伝えてください」がRuと「終点を受けてください」がだれのものであるということである、通り 例えば、私たちは、Explicitly Routed Tunnelを通して発送されたソースであるパケットでそれを要約することによって、パケットを送るかもしれません。
3.27.3. LSP Tunnels
3.27.3. LSP Tunnels
It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. The tunnel would be a LSP <R1, ..., Rn>, where R1 is the transmit endpoint of the tunnel, and Rn is the receive endpoint of the tunnel. This is called a "LSP Tunnel".
パケットがトンネルを通って旅行することを引き起こすネットワーク層カプセル化よりむしろLSPとしてトンネルを実行して、ラベルの切り換えを使用するのは可能です。 トンネルはLSP<R1でしょう…, Rn>、トンネルの終点を伝えてください。そうすれば、Rnが伝える、トンネルの終点を受けてください。(そこでは、R1がそうです)。 これは「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トンネルにパケットを入れるために伝える、aがラベルされたパケットをラベルスタックへのトンネルとラベルして、送る終点プッシュをトンネルの次のホップに伝えてください。
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を発送したので実行されるTunnelである、終点を伝えてください、終点を受けてください。
An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an Explicitly Routed LSP.
「明らかに発送されたLSPトンネル」はまたExplicitly Routed LSPであるLSP Tunnelです。
3.27.4. Hierarchy: LSP Tunnels within LSPs
3.27.4. 階層構造: LSPsの中のLSP Tunnels
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を受けて、ラベルスタックにラベルを押して、事実上、これがホップによるHop経路であると思いましょう。 しかしながら、さらに、R2とR3がLSPトンネルの終点であることによる直接接続されませんが、「隣人」であると思いましょう。 それで、Pによって横断されたLSRsの実際の系列は<R1、R2、R21、R22、R23、R3、R4>です。
Rosen, et al. Standards Track [Page 33] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[33ページ]。
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は最初に、IncomingラベルをR3に重要なラベルに取り替えます。 そして、それは新しいラベルを押します。 この平らな2ラベルには、R21に重要な値があります。 切り換えが平らな2ラベルでR21、R22、R23によって行われます。 パケットをR3に送る前に、R23(R2-R3トンネルの終わりから二番目のホップである)はラベルスタックを飛び出させます。 R3がパケットPを見るとき、今トンネルを出たので、Pには、平らな1個のラベルしかありません。 R3がPのレベル1LSPの終わりから二番目のホップであるので、ラベルスタックを飛び出させます、そして、R4はラベルされていない状態でPを受けます。
The label stack mechanism allows LSP tunneling to nest to any depth.
ラベルスタックメカニズムは巣にどんな深さまでもトンネルを堀るLSPを許容します。
3.27.5. Label Distribution Peering and Hierarchy
3.27.5. ラベル分配のじっと見るのと階層構造
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がLevel1LSP<R1に沿って移動すると仮定してください、R2、R3、R4>、行くとき、R2からR3まで、LSP<R2はLevel2に沿って旅行しています、R21、R22、R3>。 Level2LSPの見解から、R2のラベル分配同輩はR21です。 Level1LSPの見解から、R2のラベル分配同輩は、R1とR3です。 1つはそれぞれの層の階層構造でラベル分配同輩を持つことができます。 私たちはこの階層構造を利用するセクション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.
2LSRsがIGP隣接物であるときに、「地方のラベル分配はじっと見る」とき、私たちが彼らを参照するつもりです。 2LSRsがラベル分配同輩であるかもしれませんが、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:
1つは、人の地元のラベル分配同輩と共に同輩に記述されるラベル分配プロトコルメッセージを送ることによって、ラベル分配を実行します。 1つは人のリモートラベル分配同輩と共にラベル分配を2つの方法の1つで実行できます:
1. Explicit Peering
1. 明白なじっと見ること
In explicit peering, one distributes labels to a peer by
sending label distribution protocol messages which are
addressed to the peer, exactly as one would do for local label
distribution peers. This technique is most useful when the
number of remote label distribution peers is small, or the
明白なじっと見ることでは、1つは同輩に同輩に記述されるラベル分配プロトコルメッセージを送ることによって、ラベルを分配します、ちょうど1つが地元のラベル分配同輩のために大丈夫であるように。 またはリモートラベル分配同輩の数が少ないときに、このテクニックが最も役に立つ。
Rosen, et al. Standards Track [Page 34] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[34ページ]。
number of higher level label bindings is large, or the remote
label distribution peers are in distinct routing areas or
domains. Of course, one needs to know which labels to
distribute to which peers; this is addressed in section 4.1.2.
より高い平らなラベル結合の数が大きいか、またはリモートラベル分配同輩は異なったルーティング領域かドメインにいます。 もちろん、人はどの同輩にどのラベルを分配したらよいかを知る必要があります。 これはセクション4.1.2で記述されます。
Examples of the use of explicit peering is found in sections
4.2.1 and 4.6.
明白なじっと見ることの使用に関する例はセクション4.2.1と4.6で見つけられます。
2. Implicit Peering
2. 暗黙のじっと見ること
In Implicit Peering, one does not send label distribution
protocol messages which are addressed to one's peer. Rather,
to distribute higher level labels to ones remote label
distribution peers, one encodes a higher level label as an
attribute of a lower level label, and then distributes the
lower level label, along with this attribute, to one's local
label distribution peers. The local label distribution peers
then propagate the information to their local label
distribution peers. This process continues till the
information reaches the remote peer.
Implicit Peeringでは、1つは人の同輩に記述されるラベル分配プロトコルメッセージを送りません。 むしろ、より高いレベルを分配するのがリモートラベル分配同輩にもののレッテルを貼って、1つは、下のレベルラベルの属性として、より高い平らなラベルをコード化して、次に、下のレベルラベルを分配します、この属性と共に、人の地元のラベル分配同輩に。 そして、地元のラベル分配同輩は地元のラベル分配同輩に情報を伝播します。 情報がリモート同輩に届くまで、この過程は持続します。
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で見つけられます。
3.28. Label Distribution Protocol Transport
3.28. ラベル分配プロトコル輸送
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].
これらの目標を達成する1つの方法はそのままな基本的な輸送として[MPLS-自由民主党]と[MPLS-BGP]でしていた状態でTCPを使用することです。
Rosen, et al. Standards Track [Page 35] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[35ページ]。
3.29. Why More than one Label Distribution Protocol?
3.29. 1つのLabel DistributionプロトコルよりなぜMore?
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.
この構造はどの事情でどのラベル分配プロトコルを使用したらよいかを選ぶための鉄則を確立しません。 しかしながら、問題のいくつかを指摘するのは可能です。
3.29.1. BGP and LDP
3.29.1. BGPと自由民主党
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.
多くのシナリオでは、接頭語を記述するためにルートと同一視できるFECsにラベルを縛るのは望ましいです(セクション4.1を見てください)。 それらのルートを分配する標準の、そして、広く配備されたルーティング・アルゴリズムがあれば、ルート自体の分配のときにラベル分配を背負うことによってラベル分配を達成するのが最も良いと主張できます。
For example, BGP distributes such routes, and if a BGP speaker needs to also distribute labels to its BGP peers, using BGP to do the label distribution (see [MPLS-BGP]) has a number of advantages. In particular, it permits BGP route reflectors to distribute labels, thus providing a significant scalability advantage over using LDP to distribute labels between BGP peers.
例えば、BGPはそのようなルートを分配します、そして、BGPスピーカーが、また、BGP同輩にラベルを分配する必要があるなら、ラベル分配([MPLS-BGP]を見る)をするのにBGPを使用するのにおいて、多くの利点があります。 特に、BGPルート反射鏡がラベルを分配することを許可します、その結果、BGP同輩の間にラベルを分配するのに自由民主党を使用するより重要なスケーラビリティ利点を提供します。
3.29.2. Labels for RSVP Flowspecs
3.29.2. RSVP Flowspecsのためのラベル
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に経路/予約セットアップの過程の一部としてラベルを分配させるのが、このためにラベルを分配する最も効率的な方法であると主張できます。
3.29.3. Labels for Explicitly Routed LSPs
3.29.3. 明らかに発送されたLSPsのためのラベル
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.
- ラベル分配に使用される既存のプロトコルから始まってください、そして、それを広げて、明白なルーティングと資源予約を支持してください。
Rosen, et al. Standards Track [Page 36] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[36ページ]。
The first approach has given rise to the protocol specified in [MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS- CR-LDP].
最初のアプローチは[MPLS-RSVP-Tunnels]で指定されたプロトコルをもたらしました、とアプローチへの2番目は[MPLS- CR-自由民主党]で指定しました。
3.30. Multicast
3.30. マルチキャスト
This section is for further study
さらなる研究にはこのセクションがあります。
4. Some Applications of MPLS
4. MPLSのいくつかのアプリケーション
4.1. MPLS and Hop by Hop Routed Traffic
4.1. ホップの発送された交通によるMPLSとホップ
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の多くの用途が、あるラベルがあるパケットが指定されたアドレスがネットワーク層目的地アドレス・フィールドにある状態でパケットを進めるのに使用されるのと同じホップごとに発送された経路に沿って進められるのを必要とします。
4.1.1. Labels for Address Prefixes
4.1.1. アドレス接頭語のためのラベル
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.
一般に、Pの送付先アドレスのための最も長いマッチである経路指定テーブルでアドレスが接頭語Xであることがわかることによって、ルータRはパケット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がFEC Fに割り当てられるかもしれなくて、FEC Fがアドレス接頭語Xと同一視されるかもしれないことに注意してください、Pの送付先アドレスがXに合わないでも。
4.1.2. Distributing Labels for Address Prefixes
4.1.2. アドレス接頭語のためにラベルを分配します。
4.1.2.1. Label Distribution Peers for an Address Prefix
4.1.2.1. アドレス接頭語のためのラベル分配同輩
LSRs R1 and R2 are considered to be label distribution peers for address prefix X if and only if one of the following conditions holds:
LSRs R1とR2がアドレス接頭語Xのためのラベル分配同輩であると考えられる、以下の条件の1つは単に以下を保持します。
1. R1's route to X is a route which it learned about via a
particular instance of a particular IGP, and R2 is a neighbor
of R1 in that instance of that IGP
1. Xへの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
2. XへのR1のルートはそれがルーティング・アルゴリズムA1の何らかの例で学んだルートです、そして、ルーティング・アルゴリズムA2の例にそのルートを再配付します、そして、R2はA2のその例におけるR1の隣接物です。
Rosen, et al. Standards Track [Page 37] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[37ページ]。
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 Tunnelの終点を受けてください、aがそのトンネルの終点を伝えて、R1とR2はIGPの一般的な例の関係者であり、同じIGP領域にあって(問題のIGPに領域があるなら)、XへのR1のルートがそのIGP例で学習されたということである、またはR2はR1によってそのIGP例に再配付されます。
4. R1's route to X is a route which it learned about via BGP, and
R2 is a BGP peer of R1
4. Xへの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トンネリングの他の場合では、トンネル終点はラベル分配同輩です。
4.1.2.2. Distributing Labels
4.1.2.2. ラベルを分配します。
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:
ホップごとにパケットの推進にMPLSを使用するには、どんなアドレス接頭語との対応も発送してください、各LSR MUST:
1. bind one or more labels to each address prefix that appears in
its routing table;
1. 経路指定テーブルに現れるそれぞれのアドレス接頭語あたり1個以上のラベルを縛ってください。
2. for each such address prefix X, use a label distribution
protocol to distribute the binding of a label to X to each of
its label distribution peers for X.
2. そのような各アドレスのために、Xを前に置いてください、そして、ラベル分配プロトコルを使用して、Xのためにラベル分配同輩各人へのXにラベルの結合を広げてください。
There is also one circumstance in which an LSR must distribute a label binding for an address prefix, even if it is not the LSR which bound that label to that address prefix:
また、LSRがアドレス接頭語で固まるラベルを分配しなければならない1つの状況があります、そのアドレス接頭語にそのラベルを縛ったのが、LSRでなくても:
3. If R1 uses BGP to distribute a route to X, naming some other
LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has
assigned label L to X, then R1 must distribute the binding
between L and X to any BGP peer to which it distributes that
route.
3. R1がBGPを使用するなら、XへのBGP Next HopとR1が、R2がラベルLをXに割り当てたのを知っているかどうかとしてある他のLSR R2を命名して、Xにルートを分配するために、R1はそれがそのルートを分配するどんなBGP同輩へのLとXの間にも結合を広げなければなりません。
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がどのラベル結合をどの他のLSRsに広げなければならないかを単に示すことを意図します。
Rosen, et al. Standards Track [Page 38] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[38ページ]。
4.1.3. Using the Hop by Hop path as the LSP
4.1.3. LSPとしてHop経路のそばでHopを使用します。
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;
i1<=<n、1. ただ一つのアドレス接頭語Xがあります、そのようなものによって、Xはすべてのiに関するPの送付先アドレスのためのRiの経路指定テーブルで最も長いマッチです。
2. for all i, 1<i<n, Ri has assigned a label to X and distributed
that label to R[i-1].
2. すべてのi、1<i<nに関して、RiはラベルをXに割り当てて、R[i-1]にそのラベルを分配しました。
Note that a packet's LSP can extend only until it encounters a router whose forwarding tables have a longer best match address prefix for the packet's destination address. At that point, the LSP must end and the best match algorithm must be performed again.
パケットの送付先アドレスのために、推進テーブルが持っている中で、より長いマッチアドレス接頭語最も良いルータに遭遇するまでしかパケットのLSPが広がることができないことに注意してください。 その時、LSPは終わらなければなりません、そして、再び最も良いマッチアルゴリズムを実行しなければなりません。
Suppose, for example, that packet P, with destination address 10.2.153.178 needs to go from R1 to R2 to R3. Suppose also that R2 advertises address prefix 10.2/16 to R1, but R3 advertises 10.2.153/23, 10.2.154/23, and 10.2/16 to R2. That is, R2 is advertising an "aggregated route" to R1. In this situation, packet P can be label Switched until it reaches R2, but since R2 has performed route aggregation, it must execute the best match algorithm to find P's FEC.
例えば、目的地アドレス10.2.153.178があるそのパケットPが、R1からR2までR3に行く必要であると仮定してください。 また、R2がアドレス接頭語10.2/16のR1に広告を出しますが、R3が10.2 23、.153/10.2.154/23、および10.2/16のR2に広告を出すと仮定してください。 すなわち、R2は「集められたルート」のR1に広告を出しています。 この状況で、R2に達するまで、パケットPはラベルSwitchedであるかもしれませんが、R2がルート集合を実行したので、それはPのFECを見つけるために最も良いマッチアルゴリズムを実行しなければなりません。
4.1.4. LSP Egress and LSP Proxy Egress
4.1.4. LSP出口とLSPプロキシ出口
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つは単に以下を保持します。
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がアドレス接頭語Xのための「LSPプロキシ出口」LSRであると考えられる、唯一、:
1. R1's next hop for X is R2, and R1 and R2 are not label
distribution peers with respect to X (perhaps because R2 does
not support MPLS), or
1. またはXのためのR1の次のホップがR2であり、R1とR2がXに関するラベル分配同輩(恐らくR2がMPLSを支持しないので)でない。
2. R1 has been configured to act as an LSP Proxy Egress for X
2. R1は、XのためのLSP Proxy Egressとして機能するように構成されました。
Rosen, et al. Standards Track [Page 39] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[39ページ]。
The definition of LSP allows for the LSP Egress to be a node which does not support MPLS; in this case the penultimate node in the LSP is the Proxy Egress.
LSPの定義は、LSP EgressがMPLSを支えないノードであることを許容します。 この場合、LSPの終わりから二番目のノードはProxy Egressです。
4.1.5. The Implicit NULL Label
4.1.5. 内在しているヌルラベル
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.
Implicit NULLラベルはLSRがアドレス接頭語に縛ることができる特別な意味論があるラベルです。 LSR Ruが、Rdの横でパケットPとラベルされたそれを進めなければならないのをILMに相談することによって見ますが、そのRdが対応するアドレス接頭語にImplicit NULLの結合を広げたなら、ラベルスタックの上でラベルの値を取り替えることの代わりに、Ruはラベルスタックを飛び出させて、結果として起こるパケットを通りに送ります。
LSR Rd distributes a binding between Implicit NULL and an address prefix X to LSR Ru if and only if:
LSR RdがImplicit 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の規則が、RdがXで固まるラベルをRuに分配するのを示す。
2. Rd knows that Ru can support the Implicit NULL label (i.e.,
that it can pop the label stack), and
2. そしてRuがImplicit NULLラベルを支えることができるのを第知っている、(すなわち、ラベルを飛び出させることができるのは積み重ねられます)。
3. Rd is an LSP Egress (not proxy egress) for X.
3. XのためのLSP Egress(プロキシ出口でない)は第そうです。
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 EgressがXのためのMPLS Egressであり、終わりから二番目のLSRがラベルスタックを飛び出させないと、LSP Egressはラベルを見上げて、ラベルスタックを飛び出させて、次に、次のラベルを見上げる必要があるでしょう(それ以上のラベルが存在していないなら、L3アドレスを調べてください)。 終わりから二番目のLSRにラベルスタックを飛び出させることによって、推進決定をするように2個のラベルを見上げなければならない仕事はLSP Egressに救われます。
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スイッチであるなら、それには、ラベルスタックを飛び出させる能力がないかもしれません。 したがって、Implicit NULLの結合はその機能をサポートできるLSRsだけに広げられるかもしれません。
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 Proxy Egressであるなら、まるでまさしくLSP EgressがXのためにImplicit NULLの結合を広げたかのようにそれは行動します。
4.1.6. Option: Egress-Targeted Label Assignment
4.1.6. オプション: 出口で狙っているラベル課題
There are situations in which an LSP Ingress, Ri, knows that packets of several different FECs must all follow the same LSP, terminating at, say, LSP Egress Re. In this case, proper routing can be achieved
LSP Ingress(Ri)が、数個の異なったFECsのパケットがすべて、同じLSPに続かなければならないのを知っている状況があります、たとえば、LSP Egress Reで終わって。 この場合、適切なルーティングを達成できます。
Rosen, et al. Standards Track [Page 40] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[40ページ]。
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:
シングルを使用することによって、すべてのそのようなもののためにFECsをラベルしてください。 各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. FECsの特定のセットにRiがReがすべてのパケットのための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 Riは、LSR Reが特定のFECのすべてのパケットのためのLSP Egressであることをどのように決定できますか? 多くの可能な道があります:
- 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を走らせているなら、Riは、特定のFECのパケットが何らかの特定のルータを通した「次のBGPは跳ぶ」そのネットワークをFECに出なければならないことを決定できるかもしれません。
- 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.
- 情報がアドレス接頭語がどれであるかに関してどの出口に「付いたか」というLSRsを渡すのにラベル分配プロトコルを使用するのは可能です。 この方法には、リンク州のルーティングの存在によらない利点があります。
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つの可能なアプローチがデフォルトで出口で狙っているラベル課題を使用するためにネットワークを構成するだろうことですが、特定のLSRsをどんな使用にも出口で狙った状態で構成しないように、それがLSP出口である接頭語とアドレスの1つ以上の課題をラベルしてください。 私たちは以下の規則を課します:
- If a particular LSR is NOT an LSP Egress for some set of
address prefixes, then it should assign labels to the address
prefixes in the same way as is done by its LSP next hop for
those address prefixes. That is, suppose Rd is Ru's LSP next
- 特定のLSRが何らかのセットのアドレス接頭語のためのLSP Egressでないなら、次にLSPによって行われるのと同じようにアドレス接頭語へのラベルを割り当てるべきであるその時はそれらのアドレス接頭語のために跳びます。 すなわち、Rdであるなら、RuのLSPは次ですか?
Rosen, et al. Standards Track [Page 41] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[41ページ]。
hop for address prefixes X1 and X2. If Rd assigns the same
label to X1 and X2, Ru should as well. If Rd assigns different
labels to X1 and X2, then Ru should as well.
アドレス接頭語のX1とX2には、跳んでください。 Rdが同じラベルをX1とX2に割り当てるなら、また、Ruは割り当てるべきです。 Rdが異なったラベルをX1とX2に割り当てるなら、また、Ruはそうするべきです。
For example, suppose one wants to make egress-targeted label assignment the default, but to assign distinct labels to those address prefixes for which there are multiple possible LSP egresses (i.e., for those address prefixes which are multi-homed.) One can configure all LSRs to use egress-targeted label assignment, and then configure a handful of LSRs to assign distinct labels to those address prefixes which are multi-homed. For a particular multi-homed address prefix X, one would only need to configure this in LSRs which are either LSP Egresses or LSP Proxy Egresses for X.
例えば、人が出口で狙っているラベル課題をデフォルトにしたがっていると仮定しますが、異なったラベルをそれらに割り当てるために、複数の可能なLSP出口がある接頭語を記述してください、(すなわち、そうするそれらのアドレス接頭語、マルチ、家へ帰り、)。 1つが出口で狙っているラベル課題を使用するためにすべてのLSRsを構成して、次に、そうするそれらのアドレス接頭語に異なったラベルを割り当てるために一握りのLSRsを構成できる、マルチ、家へ帰り 事項、マルチ、家へ帰り、アドレス接頭語X、人はXのためのLSP EgressesかLSP Proxy EgressesのどちらかであるLSRsでこれを構成する必要があるだけでしょう。
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の隣接しているLSRsであるなら、Rdがちょうど1個のラベルをそれらの両方に割り当てますが、Ruが異なったラベルをX1とX2に割り当てると正しく推進することに注意するのは重要です。 これは、R1が同じ出発しているラベル、普通の発生に異なった入って来るラベルを写像することをただ意味します。
Similarly, if Rd assigns distinct labels to X1 and X2, but Ru assigns to them both the label corresponding to the address of their LSP Egress or Proxy Egress, forwarding will still be done correctly. Ru will just map the incoming label to the label which Rd has assigned to the address of that LSP Egress.
同様に、Rdが異なったラベルをX1とX2に割り当てますが、RuがそれらのLSP EgressかProxy Egressのアドレスに対応するラベルをそれらの両方に割り当てると、それでも、正しく推進するでしょう。 RuはただRdがそのLSP Egressのアドレスに割り当てたラベルに入って来るラベルを写像するでしょう。
4.2. MPLS and Explicitly Routed LSPs
4.2. MPLSと明らかに発送されたLSPs
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].
ホップルーティングによるホップの代わりに明白なルーティングを使用するのが望ましいかもしれない多くの理由があります。 例えば、これは、交通工学[MPLS-TRFENG]を許容するためにルートが施政方針に基づくのを許容して、LSPsが取るルートが入念に設計されているのを許容します。
4.2.1. Explicitly Routed LSP Tunnels
4.2.1. 明らかに発送されたLSP Tunnels
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.
いくつかの状況で、ネットワーク管理者は、ある一定のあらかじめ指定された経路に沿って通常、交通が続くことを前進のあるクラスの交通に望むかもしれません。そこでは、これらの経路がホップによるHop経路と異なっています。 方針ルーティングを支持して交通工学を支持してこれができます。 明白なルートは構成されたものであるかもしれませんかそれがどうでもダイナミックに断固とするかもしれません、例えば、規制ベースのルーティングで。
MPLS allows this to be easily done by means of Explicitly Routed LSP Tunnels. All that is needed is:
MPLSはExplicitly Routed LSP Tunnelsによってこれを容易にさせます。 必要であるのは以下の通りだけです。
Rosen, et al. Standards Track [Page 42] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[42ページ]。
1. A means of selecting the packets that are to be sent into the
Explicitly Routed LSP Tunnel;
1. Explicitly Routed LSP Tunnelに送られることになっているパケットを選択する手段。
2. A means of setting up the Explicitly Routed LSP Tunnel;
2. Explicitly Routed LSP Tunnelをセットアップする手段。
3. A means of ensuring that packets sent into the Tunnel will not
loop from the receive endpoint back to the transmit endpoint.
3. Tunnelに送られたそのパケットを確実にする手段が輪にしないために望んでいる、終点の後部を受ける、終点を伝えてください。
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.
ラベルされたパケットをトンネルに入れるというトンネル願望の終点を伝えてください、そして、それは最初に、スタックの先端でラベル値をそれに分配されて、トンネルのものが終点を受けるということであったラベル値に取り替えなければなりません。 次に、トンネル自体に対応するラベルを押さなければなりません、トンネルに沿った次のホップによってそれに分配されるように。 これを許容するために、トンネル終点は明白なラベル分配同輩であるべきです。 彼らが交換する必要があるラベル結合はトンネルに沿ってLSRsに全くおもしろくはありません。
4.3. Label Stacks and Implicit Peering
4.3. ラベルスタックと暗黙のじっと見ること
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.
1つはすべての10のアドレス接頭語に単一のラベルを割り当てるかもしれません。 そして、Reはすべての10のアドレス接頭語のためのLSP出口です。 これは、すべての10のアドレス接頭語のためのパケットがReに渡されるのを確実にします。 しかしながら、そして、Reは、パケットを送る適切なインタフェースを選ぶためにそのようなそれぞれのパケットのネットワーク層アドレスを調べなければならないでしょう。
Alternatively, one could assign a distinct label to each interface. Then Re is an LSP proxy egress for the 10 address prefixes. This eliminates the need for Re to look up the network layer addresses in order to forward the packets. However, it can result in the use of a large number of labels.
あるいはまた、1つは異なったラベルを各インタフェースに割り当てるかもしれません。 そして、Reは10のアドレス接頭語のためのLSPプロキシ出口です。 これはReがパケットを進めるためにネットワーク層アドレスを調べる必要性を排除します。 しかしながら、それは多くのラベルの使用をもたらすことができます。
An alternative would be to bind all 10 address prefixes to the same level 1 label (which is also bound to the address of the LSR itself), and then to bind each address prefix to a distinct level 2 label. The level 2 label would be treated as an attribute of the level 1 label binding, which we call the "Stack Attribute". We impose the following rules:
代替手段は、同じレベル1への接頭語が分類するすべての10アドレス(また、LSR自身のアドレスに縛られる)を縛って、そして、異なった平らな2ラベルにそれぞれのアドレス接頭語を縛るだろうことです。 レベル2はレベル1の属性として扱われただろうというラベル結合をラベルします。(私たちはそれに「スタック属性」と呼びます)。 私たちは以下の規則を課します:
- When LSR Ru initially labels a hitherto unlabeled packet, if
the longest match for the packet's destination address is X,
and Ru's LSP next hop for X is Rd, and Rd has distributed to Ru
a binding of label L1 to X, along with a stack attribute of L2,
then
- LSR Ruが初めはこれまでラベルされていないパケットをラベルするとき、パケットの送付先アドレスのための最も長いマッチがX、およびRuのLSPであるなら、Xのための次のホップはRdです、そして、RdはXへのラベルL1の結合をRuに広げました、L2のスタック属性と共に、そして
Rosen, et al. Standards Track [Page 43] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[43ページ]。
1. Ru must push L2 and then L1 onto the packet's label stack,
and then forward the packet to Rd;
1. Ruは、パケットのラベルスタックにL2を押して、次に、L1を押して、次に、パケットをRdに送らなければなりません。
2. When Ru distributes label bindings for X to its label
distribution peers, it must include L2 as the stack
attribute.
2. RuがXのためのラベル結合をラベル分配同輩に広げるとき、それはスタック属性としてL2を含まなければなりません。
3. Whenever the stack attribute changes (possibly as a result
of a change in Ru's LSP next hop for X), Ru must distribute
the new stack attribute.
3. スタック属性が変化する(ことによるとRuのLSPにおける変化の結果、Xのために次に跳んでください)ときはいつも、Ruは新しいスタック属性を分配しなければなりません。
Note that although the label value bound to X may be different at each hop along the LSP, the stack attribute value is passed unchanged, and is set by the LSP proxy egress.
スタック属性値が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になります。 同輩の数は大きくなり過ぎるでしょう、したがって、この場合、明白なじっと見るのが扱いにく過ぎるでしょう。
4.4. MPLS and Multi-Path Routing
4.4. MPLSとマルチ経路ルート設定
If an LSR supports multiple routes for a particular stream, then it may assign multiple labels to the stream, one for each route. Thus the reception of a second label binding from a particular neighbor for a particular address prefix should be taken as meaning that either label can be used to represent that address prefix.
LSRが特定の流れのための複数のルートを支えるなら、それは流れ(各ルートあたり1つ)に複数のラベルを割り当てるかもしれません。 したがって、そのアドレス接頭語を表すのにどちらのラベルも使用できることを意味すると特定の隣人から特定のアドレス接頭語で固まる2番目のラベルのレセプションはみなされるべきです。
If multiple label bindings for a particular address prefix are specified, they may have distinct attributes.
特定のアドレス接頭語のための複数のラベル結合が指定されるなら、それらには、異なった属性があるかもしれません。
4.5. LSP Trees as Multipoint-to-Point Entities
4.5. 多点から点実体としてのLSP木
Consider the case of packets P1 and P2, each of which has a destination address whose longest match, throughout a particular routing domain, is address prefix X. Suppose that the Hop-by-hop path for P1 is <R1, R2, R3>, and the Hop-by-hop path for P2 is <R4, R2, R3>. Let's suppose that R3 binds label L3 to X, and distributes this binding to R2. R2 binds label L2 to X, and distributes this binding to both R1 and R4. When R2 receives packet P1, its incoming label will be L2. R2 will overwrite L2 with L3, and send P1 to R3. When R2 receives packet P2, its incoming label will also be L2. R2 again overwrites L2 with L3, and send P2 on to R3.
パケットのケースがP1とP2であると考えてください。それはそれぞれ、P1のためのホップによるHop経路が接頭語X.Supposeですが、最も長いマッチが特定の経路ドメイン中でアドレスである送付先アドレスを持っています。<R1、R2、R3>、およびP2のためのホップによるHop経路は<R4です、R2、R3>。 R3がラベルL3をXに縛って、この結合をR2に広げると思いましょう。 R2はラベルL2をXに縛って、R1とR4の両方にこの結合を広げます。 R2がパケットP1を受けるとき、入って来るラベルはL2になるでしょう。 R2はL3と共にL2を上書きして、P1をR3に送るでしょう。 また、R2がパケットP2を受けるとき、入って来るラベルはL2になるでしょう。 R2は再びL3と共にL2を上書きします、そして、P2をR3に送ってください。
Note then that when P1 and P2 are traveling from R2 to R3, they carry the same label, and as far as MPLS is concerned, they cannot be distinguished. Thus instead of talking about two distinct LSPs, <R1,
その時、P1とP2がR2からR3まで旅行しているとき、彼らが同じラベルを運んで、MPLSに関する限り、区別できないことに注意してください。 その結果、およそ2異なったLSPs、<R1について話すことの代わりに
Rosen, et al. Standards Track [Page 44] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[44ページ]。
R2, R3> and <R4, R2, R3>, we might talk of a single "Multipoint-to-
Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>.
R2、R3>、および<R4、R2、R3>、私たちは単一の「多点からポイントへのLSP木」について話すかもしれません、私たちがそうするかもしれないもの。<としてR1、R4を指示してください、R2、R3>。
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.
私たちが、LSRsとして従来のATMスイッチを使用するのを試みるとき、これは困難を作成します。 従来のATMスイッチが多点からポイントとの接続を支持しないので、各LSPが二地点間VCとして実感されるのを保証する手順があるに違いありません。 しかしながら、多点からポイントへのVCsを支持するATMスイッチが使用中であるなら、多点からポイントへのVCsとして最も効率的にLSPsを実感できます。 あるいはまた、SVP Multipoint Encoding(セクション3.25.2)を使用できるなら、多点からポイントへのSVPsとしてLSPsを実感できます。
4.6. LSP Tunneling between BGP Border Routers
4.6. BGP境界ルータの間でトンネルを堀るLSP
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.
Autonomous System、他のAutonomous Systemsの間のトランジット交通を運ぶAに関するケースを考えてください。自治のSystem Aには多くのBGP Border Routers、および彼らの中のBGP接続のメッシュがあるでしょう。(BGPルートはそれに分配されています)。 そのような多くの場合では、BGP Border RoutersでないルータにBGPルートを分配するのを避けるのは望ましいです。 これを避けることができるなら、それらのルータの「ルート分配負荷」はかなり減少します。 しかしながら、トランジット交通が内部のルータによってBorder RouterからBorder Routerまで提供されるのを確実にするいくつかの手段があるに違いありません。
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 Tunnelsによって容易にこれができます。 BGPルートがBorder RouterからBorder RouterまでのホップによるHop経路に沿ってある内部のルータではなく、BGP Border Routersだけに分配されると仮定してください。 次に、以下の通りLSP Tunnelsを使用できます:
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 Border RouterはそれがBGPを通してそのルータに分配するそれぞれのアドレス接頭語のために同じAutonomous Systemの他のあらゆるBGP Border Routerにラベルを分配します。
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. Autonomous SystemのためのIGPは各BGP Border Routerのためにホストルートを維持します。 それぞれの内部のルータはIGP隣人各人へのこれらのホストルートにラベルを分配します。
3. Suppose that:
3. 以下のことと仮定してください。
a) BGP Border Router B1 receives an unlabeled packet P,
a) BGP Border Router B1はラベルされていないパケットPを受けます。
b) address prefix X in B1's routing table is the longest match
for the destination address of P,
B1の経路指定テーブルのb)アドレス接頭語XはPの送付先アドレスのための最も長いマッチです。
c) the route to X is a BGP route,
c) XへのルートはBGPルートです。
d) the BGP Next Hop for X is B2,
d) XのためのBGP Next HopはB2です。
Rosen, et al. Standards Track [Page 45] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[45ページ]。
e) B2 has bound label L1 to X, and has distributed this binding
to B1,
e) B2はラベルL1をXに縛って、この結合をB1に広げました。
f) the IGP next hop for the address of B2 is I1,
次のIGPがB2のアドレスのために飛び越すf)は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.
そして、パケットPをI1に送る前に、B1はPのためにラベルスタックを作成して、次に、ラベルL1を押して、次に、ラベルL2を押さなければなりません。
4. Suppose that BGP Border Router B1 receives a labeled Packet P,
where the label on the top of the label stack corresponds to an
address prefix, X, to which the route is a BGP route, and that
conditions 3b, 3c, 3d, and 3e all hold. Then before sending
packet P to I1, B1 must replace the label at the top of the
label stack with L1, and then push on label L2.
4. BGP Border Router B1がラベルスタックの先端のラベルがアドレス接頭語、ルートがBGPルートであるXに対応するラベルされたPacket Pを受けて、状態の3b、3c、3d、および3eがすべて持ちこたえると仮定してください。 そして、パケットPをI1に送る前に、B1はラベルスタックの先端でラベルをL1に取り替えて、次に、ラベルL2を押さなければなりません。
With these procedures, a given packet P follows a level 1 LSP all of whose members are BGP Border Routers, and between each pair of BGP Border Routers in the level 1 LSP, it follows a level 2 LSP.
これらの手順で、与えられたパケットPはメンバーが皆、BGP Border Routersである平らな1LSPに続きます、そして、平らな1LSPの各組のBGP Border Routersの間では、それは平らな2LSPに続きます。
These procedures effectively create a Hop-by-Hop Routed LSP Tunnel between the BGP Border Routers.
事実上、これらの手順はBGP Border Routersの間でホップによるHop Routed LSP Tunnelを作成します。
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:
2BGP Border Routersの間でホップによるHop Routed LSP Tunnelsを創造するのは時々可能です、彼らが同じAutonomous Systemにいないでも。 例えば、B1とB2がAS1にあると仮定してください。 B3がB2のEBGP隣人であり、AS2にあると仮定してください。 最終的に、B2とB3が両方のAutonomous Systems(「非武装地帯」)に共通の何らかのネットワークにあると仮定してください。 この場合、B1と以下のB3の直接間でLSPトンネルをセットアップできます:
- B3 distributes routes to B2 (using EBGP), optionally assigning
labels to address prefixes;
- 接頭語を記述するために任意にラベルを割り当てて、B3はB2(EBGPを使用する)にルートを分配します。
- B2 redistributes those routes to B1 (using IBGP), indicating
that the BGP next hop for each such route is B3. If B3 has
assigned labels to address prefixes, B2 passes these labels
along, unchanged, to B1.
- BGPが次に跳ぶのを示して、B2は、そのような各ルートがB3であるので、B1(IBGPを使用する)にそれらのルートを再配付します。 B3が接頭語を記述するためにラベルを割り当てたなら、B2はB1に変わりがない状態でこれらのラベルを回します。
Rosen, et al. Standards Track [Page 46] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[46ページ]。
- The IGP of AS1 has a host route for B3.
- AS1のIGPには、B3のためのホストルートがあります。
4.7. Other Uses of Hop-by-Hop Routed LSP Tunnels
4.7. ホップごとに発送されたLSP Tunnelsの他の用途
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.
ホップによるHop Routed LSP Tunnelsの使用はBGP Nextホップスの間のトンネルに制限されません。 そうでなければ1つがカプセル化トンネルを使用したかもしれないどんな状況もホップによるHop Routed LSP Tunnelを使用するのが適切であるものです。 送付先アドレスがトンネルのもののアドレスである新しいヘッダーと共にパケットをカプセルに入れることの代わりに、終点(トンネルのもののアドレスが終点を受けるので最も長いマッチがパケットのラベルスタックに押されるということであるアドレス接頭語に対応するラベル)を受けてください。 トンネルに送られるパケットは既にラベルされるかもしれません。
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.
ラベルされたパケットをトンネルに入れるというトンネル願望の終点を伝えてください、そして、それは最初に、スタックの先端でラベル値をそれに分配されて、トンネルのものが終点を受けるということであったラベル値に取り替えなければなりません。 次に、トンネル自体に対応するラベルを押さなければなりません、トンネルに沿った次のホップによってそれに分配されるように。 これを許容するために、トンネル終点は明白なラベル分配同輩であるべきです。 彼らが交換する必要があるラベル結合はトンネルに沿ってLSRsに全くおもしろくはありません。
4.8. MPLS and Multicast
4.8. MPLSとマルチキャスト
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はそのパケットのために出力インタフェースのセットを示します、出発しているラベルと同様に。 すべての外向的なインタフェースでテクニックをコード化する同じラベルを使用するなら、全く同じパケットをすべての子供に送ることができます。
5. Label Distribution Procedures (Hop-by-Hop)
5. ラベル分配手順(ホップごとの)
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.
このセクションでは、私たちは、交通に使用されるラベル結合だけがホップごとに発送された経路に沿って切り換えられたラベルであると考えます。 これらの場合では、問題のラベルは経路指定テーブルのアドレス接頭語に対応するでしょう。
Rosen, et al. Standards Track [Page 47] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[47ページ]。
5.1. The Procedures for Advertising and Using labels
5.1. AdvertisingのためのProceduresとUsingラベル
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
- そしてNotAvailable手順。
- 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で説明されるでしょう。また、異なった組み合わせの間の相互運用性はそこで論じられるでしょう。
5.1.1. Downstream LSR: Distribution Procedure
5.1.1. 川下のLSR: 分配手順
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.
Distribution Procedureは、それがいつ特定のアドレス接頭語でラベル分配同輩に固まるラベルを分配するべきであるかを決定するのに川下のLSRによって使用されます。 構造は4つの異なった分配手順を支持します。
Irrespective of the particular procedure that is used, if a label binding for a particular address prefix has been distributed by a downstream LSR Rd to an upstream LSR Ru, and if at any time the attributes (as defined above) of that binding change, then Rd must inform Ru of the new attributes.
使用された特定の手順において関係ありません、特定のアドレス接頭語で固まるラベルが川下のLSR Rdによって上流のLSR Ruに分配されて、その結合の属性(上で定義されるように)がいつでも変化するなら、Rdは新しい属性についてRuに知らせなければなりません。
If an LSR is maintaining multiple routes to a particular address prefix, it is a local matter as to whether that LSR binds multiple labels to the address prefix (one per route), and hence distributes multiple bindings.
LSRが特定のアドレス接頭語に複数のルートを維持しているなら、それはそのLSRがアドレス接頭語(1ルートあたり1つ)に複数のラベルを縛って、したがって、複数の結合を広げるかどうかに関する地域にかかわる事柄です。
Rosen, et al. Standards Track [Page 48] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[48ページ]。
5.1.1.1. PushUnconditional
5.1.1.1. PushUnconditional
Let Rd be an LSR. Suppose that:
RdがLSRであることをさせてください。 以下のことと仮定してください。
1. X is an address prefix in Rd's routing table
1. XはRdの経路指定テーブルのアドレス接頭語です。
2. Ru is a label distribution peer of Rd with respect to X
2. RuはXに関するRdのラベル分配同輩です。
Whenever these conditions hold, Rd must bind a label to X and distribute that binding to Ru. It is the responsibility of Rd to keep track of the bindings which it has distributed to Ru, and to make sure that Ru always has these bindings.
これらの状態が成立するときはいつも、RdはXにラベルを縛って、その結合をRuに広げなければなりません。 それがRuに広げた結合の動向をおさえて、Ruにはこれらの結合がいつもあるのを確実にするのは、Rdの責任です。
This procedure would be used by LSRs which are performing unsolicited downstream label assignment in the Independent LSP Control Mode.
この手順は無党派LSP Control Modeにおける求められていない川下のラベル課題を実行しているLSRsによって用いられるでしょう。
5.1.1.2. PushConditional
5.1.1.2. PushConditional
Let Rd be an LSR. Suppose that:
RdがLSRであることをさせてください。 以下のことと仮定してください。
1. X is an address prefix in Rd's routing table
1. XはRdの経路指定テーブルのアドレス接頭語です。
2. Ru is a label distribution peer of Rd with respect to X
2. RuはXに関するRdのラベル分配同輩です。
3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
Rn has bound a label to X and distributed that binding to Rd.
3. X、またはRdの次のL3のためのLSP EgressかLSP Proxy EgressがXのために飛び越すどちらかがRnであり、RnがXにラベルを縛って、その結合を通りに広げたという第ことです。(そこでは、RnがRuと異なっています)。
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.
この手順はOrdered LSP Control Modeの求められていない川下のラベル課題を実行しているLSRsによって用いられるでしょう。
5.1.1.3. PulledUnconditional
5.1.1.3. PulledUnconditional
Let Rd be an LSR. Suppose that:
RdがLSRであることをさせてください。 以下のことと仮定してください。
1. X is an address prefix in Rd's routing table
1. XはRdの経路指定テーブルのアドレス接頭語です。
2. Ru is a label distribution peer of Rd with respect to X
2. RuはXに関するRdのラベル分配同輩です。
Rosen, et al. Standards Track [Page 49] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[49ページ]。
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に広げるはずです。 Rdが、XがRdの経路指定テーブルにないか、またはRdがXに関するRuのラベル分配同輩でないならこのとき結合を提供できないことをRuに知らせなければならないことに注意してください。
If Rd has already distributed a binding for address prefix X to Ru, and it receives a new request from Ru for a binding for address prefix X, it will bind a second label, and distribute the new binding to Ru. The first label binding remains in effect.
Rdが既にアドレス接頭語Xのための結合をRuに広げて、アドレス接頭語Xのための結合のためにRuから新しい要求を受け取ると、それは、2番目のラベルを縛って、新しい結合をRuに広げるでしょう。 最初のラベル結合は有効なままで残っています。
This procedure would be used by LSRs performing downstream-on-demand label distribution using the Independent LSP Control Mode.
この手順は無党派LSP Control Modeを使用することで川下要求次第のラベル分配を実行するLSRsによって用いられるでしょう。
5.1.1.4. PulledConditional
5.1.1.4. PulledConditional
Let Rd be an LSR. Suppose that:
RdがLSRであることをさせてください。 以下のことと仮定してください。
1. X is an address prefix in Rd's routing table
1. XはRdの経路指定テーブルのアドレス接頭語です。
2. Ru is a label distribution peer of Rd with respect to X
2. RuはXに関するRdのラベル分配同輩です。
3. Ru has explicitly requested that Rd bind a label to X and
distribute the binding to Ru
3. Ruは、RdがXにラベルを縛って、結合をRuに広げるよう明らかに要求しました。
4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or
Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and
Rn has bound a label to X and distributed that binding to Rd
4. XがRnであり、RnがXにラベルを縛って、Rdにそんなに拘束力があった状態で分配されて、次のLSP EgressかXのためのLSP Proxy EgressかRdのL3のどちらかが跳ぶという第ことです。そこでは、RnがRuと異なっています。
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に広げるはずです。 Rdが、XがRdの経路指定テーブルになくて、またXのための結合がXのためのRdの次のホップを通して入手可能でないか、またはRdがXに関するRuのラベル分配同輩でないならこのとき結合を提供できないことをRuに知らせなければならないことに注意してください。
However, if the only condition that fails to hold is that Rn has not yet provided a label to Rd, then Rd must defer any response to Ru until such time as it has receiving a binding from Rn.
しかしながら、成立しない唯一の状態がRnがまだラベルをRdに供給していないということであるなら、Rdは、Rnから結合を受けながら、持っているような時間までRuへのどんな応答も延期しなければなりません。
If Rd has distributed a label binding for address prefix X to Ru, and at some later time, any attribute of the label binding changes, then Rd must redistribute the label binding to Ru, with the new attribute. It must do this even though Ru does not issue a new Request.
RdがRu、および何らかの後の時間にアドレス接頭語Xで固まるラベルを分配したなら、ラベル結合のどんな属性も変化します、次に、RdはRuに固まるラベルを再配付しなければなりません、新しい属性で。 Ruは新しいRequestを発行しませんが、それはこれをしなければなりません。
Rosen, et al. Standards Track [Page 50] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[50ページ]。
This procedure would be used by LSRs that are performing downstream- on-demand label allocation in the Ordered LSP Control Mode.
この手順はOrdered LSP Control Modeで川下で要求次第のラベル配分を実行しているLSRsによって用いられるでしょう。
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で、私たちは、その時々で使用されるためにどのように特定の手順を選ぶか、そして、異なった手順を選ぶLSRsの中でどのように相互運用性を確実にするかを議論するつもりです。
5.1.2. Upstream LSR: Request Procedure
5.1.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がその接頭語にラベルを縛って、結合を広げるよういつ明らかに要求するかを決定するのにRequest Procedureは上流のLSRによって使用されます。 用いることができる3つの可能な手順があります。
5.1.2.1. RequestNever
5.1.2.1. RequestNever
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.
求められていない川下のラベル分配と自由党員Label Retention Modeが使用されているとき、この手順はLSRによって用いられるでしょう。
5.1.2.2. RequestWhenNeeded
5.1.2.2. RequestWhenNeeded
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.
新しいアドレス接頭語が学習されて、ラベル結合が与えられたアドレス接頭語のために1つでそんなに次にから既に跳ばないとき、アドレスへの次のホップが前に置くL3が変化するときはいつも、要求をしてください。
This procedure would be used by an LSR whenever Conservative Label Retention Mode is being used.
保守党員Label Retention Modeが使用されているときはいつも、この手順はLSRによって用いられるでしょう。
5.1.2.3. RequestOnRequest
5.1.2.3. RequestOnRequest
Issue a request whenever a request is received, in addition to issuing a request when needed (as described in section 5.1.2.2). If Ru is not capable of being an LSP ingress, it may issue a request only when it receives a request from upstream.
必要であると(セクション5.1.2で.2について説明するので)要求を出すことに加えて要求を受け取るときはいつも、要求を出してください。 上流から要求を受け取るときだけ、RuはLSPイングレスであることができないなら、それが要求を出すかもしれません。
If Rd receives such a request from Ru, for an address prefix for which Rd has already distributed Ru a label, Rd shall assign a new (distinct) label, bind it to X, and distribute that binding. (Whether Rd can distribute this binding to Ru immediately or not depends on the Distribution Procedure being used.)
RdがRuからそのような要求を受け取るなら、ラベルでありRdが既にRuを分配したアドレス接頭語のために、Rdは新しい(異なった)ラベルを割り当てるものとします、そして、Xにそれを縛ってください、そして、その結合を広げてください。 (Rdがすぐにこの結合をRuに広げることができるかどうかが使用されるDistribution Procedureによります。)
Rosen, et al. Standards Track [Page 51] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[51ページ]。
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.
この手順は川下進行中の要求しているラベル分配をしていますが、ラベル合併(例えば、VCマージができないATM-LSR)はしていないLSRによって用いられるでしょう。
5.1.3. Upstream LSR: NotAvailable Procedure
5.1.3. 上流のLSR: NotAvailable手順
If Ru and Rd are respectively upstream and downstream label distribution peers for address prefix X, and Rd is Ru's L3 next hop for X, and Ru requests a binding for X from Rd, but Rd replies that it cannot provide a binding at this time, because it has no next hop for X, then the NotAvailable procedure determines how Ru responds. There are two possible procedures governing Ru's behavior:
RuとRdがそれぞれ上流であり、アドレス接頭語Xのための川下のラベル分配同輩、およびRdがそのように上流であるなら、Ruの次のL3はXのために跳びます、そして、RuはRdからのXのための結合、次のノーがあるのでそれがこのとき結合を提供できないRd回答だけがXのために跳んで、次に、NotAvailable手順が、Ruがどのように応じるかを決定するよう要求します。 Ruの振舞いを治める2つの可能な手順があります:
5.1.3.1. RequestRetry
5.1.3.1. RequestRetry
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は再び後で要求を出すはずです。 すなわち、リクエスタは再試行するのに必要な結合を得るのが、より遅い原因となります。 川下要求次第のラベル分配が使用されているとき、この手順は用いられるでしょう。
5.1.3.2. RequestNoRetry
5.1.3.2. RequestNoRetry
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.
代わりにそれが利用可能であるときに、Rdが自動的に結合を提供すると仮定する場合、Ruは要求を決して再発行するはずがありません。 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が、何らかのエラー条件のために結合をRuに供給できないと返答すると、むしろ、Ruの動きが次のノーがRdがそうしたので跳ぶよりNotAvailable手順でというよりむしろラベル分配プロトコルのエラー回復状態によって治められることに注意してください。
5.1.4. Upstream LSR: Release Procedure
5.1.4. 上流のLSR: リリース手順
Suppose that Rd is an LSR which has bound a label to address prefix X, and has distributed that binding to LSR Ru. If Rd does not happen to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's L3 next hop for address prefix X, then Ru will not be using the label. The Release Procedure determines how Ru acts in this case. There are two possible procedures governing Ru's behavior:
Rdが接頭語Xを記述するためにラベルを縛って、その結合をLSR Ruに広げたLSRであると仮定してください。 Rdが、Ruの次のL3がアドレス接頭語Xのために跳ぶというたまたまことでない、またはRuの次のL3がアドレス接頭語Xのために跳ぶということであることをやめたなら、Ruはラベルを使用しないでしょう。 Release Procedureは、Ruがこの場合どのように行動するかを決定します。 Ruの振舞いを治める2つの可能な手順があります:
5.1.4.1. ReleaseOnChange
5.1.4.1. ReleaseOnChange
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に知らせるはずです。 この手順は、保守党員Label Retention Modeを実行するのに用いられるでしょう。
Rosen, et al. Standards Track [Page 52] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[52ページ]。
5.1.4.2. NoReleaseOnChange
5.1.4.2. NoReleaseOnChange
Ru should maintain the binding, so that it can use it again immediately if Rd later becomes Ru's L3 next hop for X. This procedure would be used to implement Liberal Label Retention Mode.
Ruは結合を維持するはずであり、Rdが後でRuのL3になるならすぐに再びそれを使用できて、X.This手順のための次のホップは、自由党員Label Retention Modeを実行するのに使用されるでしょう。
5.1.5. Upstream LSR: labelUse Procedure
5.1.5. 上流のLSR: labelUse手順
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はRdでXに関して上流です、そして、事実上、RdによるRuの次のL3がXのために跳ぶということです。
Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop for X, Ru does not make any use of the binding at that time. Ru may however start using the binding at some later time, if Rd becomes Ru's L3 next hop for X.
RdによるRuの次のL3はX.Ifのために跳びます、結合がRuによって受けられるときRdによるRuの次のL3がXのために跳んで、Ruがその時結合の少しの使用もしないということでないということであるなら、Ruは結合を利用するでしょう。 しかしながら、Ruは、何らかの後の時間に結合を使用し始めるかもしれなくて、Rdが次にRuのL3になるなら、Xのために跳んでください。
The labelUse Procedure determines just how Ru makes use of Rd's binding.
labelUse Procedureは、RuがいったいどのようにRdのものの使用を拘束力があるようにするかを決定します。
There are two procedures which Ru may use:
Ruが用いるかもしれない2つの手順があります:
5.1.5.1. UseImmediate
5.1.5.1. UseImmediate
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のための結合があって、またRuのものがLSPであったならRdがX、Rdのための次のホップがそうするRuのL3である何時でも、X.This手順のための次のホップは使用されています。
5.1.5.2. UseIfLoopNotDetected
5.1.5.2. UseIfLoopNotDetected
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はラベル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のための次のホップが変化するまで、これは続くでしょう。
5.1.6. Downstream LSR: Withdraw Procedure
5.1.6. 川下のLSR: 手順を引き下がらせてください。
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の間の結合を壊すと決めると、結合が広げられたすべてのLSRsにこの解くことを分配しなければなりません。
Rosen, et al. Standards Track [Page 53] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[53ページ]。
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からのLを解くことを知る前にY.X!=If RuがLからYの新しい結合を知ることになっていて、XとYの両方に合っているパケットがRuによってRdに送られるならしばらくRuがラベルLでXに合っているパケットとパケットの両方を合っているYとラベルするいかなる他のアドレス接頭語YへのLのどんな新しい結合もRuに広げる前にXからのLを解くことがRdによってLSR Ruに分配されるのが必要です。
The distribution and withdrawal of label bindings is done via a label distribution protocol. All label distribution protocols require that a label distribution adjacency be established between two label distribution peers (except implicit peers). If LSR R1 has a label distribution adjacency to LSR R2, and has received label bindings from LSR R2 via that adjacency, then if adjacency is brought down by either peer (whether as a result of failure or as a matter of normal operation), all bindings received over that adjacency must be considered to have been withdrawn.
ラベル分配プロトコルでラベル結合の分配と取り消しをします。 すべてのラベル分配プロトコルが、ラベル分配隣接番組が2人のラベル分配同輩(内在している同輩を除いた)の間で確立されるのを必要とします。 LSR R1がラベル分配隣接番組をLSR R2に持って、LSR R2からその隣接番組でラベル結合を受けたなら、隣接番組がどちらの同輩によっても降ろされるなら(失敗の結果、通常の操作の問題にかかわらず)、引き下がったとその隣接番組の上に受けられたすべての結合を考えなければなりません。
As long as the relevant label distribution adjacency remains in place, label bindings that are withdrawn must always be withdrawn explicitly. If a second label is bound to an address prefix, the result is not to implicitly withdraw the first label, but to bind both labels; this is needed to support multi-path routing. If a second address prefix is bound to a label, the result is not to implicitly withdraw the binding of that label to the first address prefix, but to use that label for both address prefixes.
関連ラベル分配隣接番組が適所に残っている限り、よそよそしいラベル結合はいつも明らかに引き下がらなければなりません。 2番目のラベルがアドレス接頭語に縛られるなら、結果はそれとなく最初のラベルを引っ込めるのではなく、両方のラベルを縛ることです。 これが、マルチ経路ルーティングを支持するのに必要です。 2番目のアドレス接頭語がラベルに縛られるなら、結果はそのラベルの結合を最初のアドレス接頭語にそれとなく引き下がらせるのではなく、両方のアドレス接頭語にそのラベルを使用することです。
5.2. MPLS Schemes: Supported Combinations of Procedures
5.2. MPLSは計画します: 手順の支持された組み合わせ
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.
2LSRs、Ru、およびRdを考えてください。(Rdは何らかのセットのアドレス接頭語に関するラベル分配同輩です)。そこでは、Ruが上流の同輩であり、Rdは川下の同輩です。
The MPLS scheme which governs the interaction of Ru and Rd can be described as a quintuple of procedures: <Distribution Procedure, Request Procedure, NotAvailable Procedure, Release Procedure, labelUse Procedure>. (Since there is only one Withdraw Procedure, it need not be mentioned.) A "*" appearing in one of the positions is a wild-card, meaning that any procedure in that category may be present; an "N/A" appearing in a particular position indicates that no procedure in that category is needed.
RuとRdの相互作用を治めるMPLS計画は手順の5倍として記述できます: <分配手順、要求手順、NotAvailable手順は手順、labelUse手順>をリリースします。 (1Withdraw Procedureしかないので、それは言及される必要はありません。) 位置の1つに現れる「*」はワイルドカードです、そのカテゴリにおけるどんな手順も存在しているかもしれないことを意味して。 特定の位置の「なし」という排臨は、そのカテゴリにおける手順は全く必要でないことを示します。
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 Architectureによって支持されます。 それらの必要性が示されるなら、他の計画は将来、加えられるかもしれません。
Rosen, et al. Standards Track [Page 54] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[54ページ]。
5.2.1. Schemes for LSRs that Support Label Merging
5.2.1. LSRsの計画、そのSupport Label Merging
If Ru and Rd are label distribution peers, and both support label merging, one of the following schemes must be used:
RuとRdがラベル分配同輩であり、両方がラベル合併を支持するなら、以下の計画の1つを使用しなければなりません:
1. <PushUnconditional, RequestNever, N/A, NoReleaseOnChange,
UseImmediate>
1. <PushUnconditional、RequestNever、なし、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、なし、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.
これは命令されたコントロール(出口からの)と保守的なラベル保有モードがある求められていない川下のラベル分配です。 輪の検出は任意です。
4. <PushConditional, RequestNever, N/A, NoReleaseOnChange, *>
4. <PushConditional、RequestNever、なし、NoReleaseOnChange、*>。
This is unsolicited downstream label distribution with ordered
control (from the egress) and liberal label retention mode.
Loop detection is optional.
これは命令されたコントロール(出口からの)と寛容なラベル保有モードがある求められていない川下のラベル分配です。 輪の検出は任意です。
5. <PulledConditional, RequestWhenNeeded, RequestRetry,
ReleaseOnChange, *>
5. <PulledConditional、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、なし、ReleaseOnChange、UseImmediate>。
This is downstream-on-demand label distribution with
independent control and conservative label retention mode,
without loop detection.
これは、独立制御による川下要求次第のラベル分配と輪の検出がなければ保守的なラベル保有モードです。
Rosen, et al. Standards Track [Page 55] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[55ページ]。
7. <PulledUnconditional, RequestWhenNeeded, N/A, ReleaseOnChange,
UseIfLoopNotDetected>
7. <PulledUnconditional、RequestWhenNeeded、なし、ReleaseOnChange、UseIfLoopNotDetected>。
This is downstream-on-demand label distribution with
independent control and conservative label retention mode, with
loop detection.
独立制御と保守的なラベル保有モード、輪の検出でこれは川下要求次第のラベル分配です。
5.2.2. Schemes for LSRs that do not Support Label Merging
5.2.2. どんなSupport Label MergingもしないLSRsの計画
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がラベル合併を支持するのではなく、LSRsとして使用されていることを支持するATMスイッチであると仮定してください。 ホップごとのアドレス接頭語XのためのL3経路が<R1、R2、R3、R4>であり、Xのために運命づけられたパケットがこれらのLSRsのどれかにネットワークを入れることができるとさらに仮定してください。 多点からポイントへの能力が全くないので、ポイントツーポイントVCsとしてLSPsを実感しなければなりません:(VCsはアドレス接頭語Xのためのそのような3VCsがあるのが必要であることを意味します)。 <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つであるに違いありません:
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はXのために3個のラベルをR3に分配するでしょう。 R3はXのために2個のラベルをR2に分配するでしょう、そして、R2はXのために1個のラベルをR1に分配するでしょう。
2. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
UseImmediate>
2. <PulledUnconditional、RequestOnRequest、なし、ReleaseOnChange、UseImmediate>。
This is downstream-on-demand label distribution with
independent control and conservative label retention mode,
without loop detection.
これは、独立制御による川下要求次第のラベル分配と輪の検出がなければ保守的なラベル保有モードです。
Rosen, et al. Standards Track [Page 56] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[56ページ]。
3. <PulledUnconditional, RequestOnRequest, N/A, ReleaseOnChange,
UseIfLoopNotDetected>
3. <PulledUnconditional、RequestOnRequest、なし、ReleaseOnChange、UseIfLoopNotDetected>。
This is downstream-on-demand label distribution with
independent control and conservative label retention mode, with
loop detection.
独立制御と保守的なラベル保有モード、輪の検出でこれは川下要求次第のラベル分配です。
5.2.3. Interoperability Considerations
5.2.3. 相互運用性問題
It is easy to see that certain quintuples do NOT yield viable MPLS schemes. For example:
ある5倍が実行可能なMPLS計画をもたらさないのがわかるのは簡単です。 例えば:
- <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計画では、それらを使用していないとき、Rdは結合をリリースしますが、二度とそれらを求めません、それにそれらの必要が後であっても。 その結果、これらの計画は、ラベル結合が適切に分配されるのを確実にしません。
In this section, we specify rules to prevent a pair of label distribution peers from adopting procedures which lead to infeasible MPLS Schemes. These rules require either the exchange of information between label distribution peers during the initialization of the label distribution adjacency, or a priori knowledge of the information (obtained through a means outside the scope of this document).
このセクションでは、私たちは、1組のラベル分配同輩が実行不可能なMPLS Schemesに通じる手順を取り入れるのを防ぐために規則を指定します。 これらの規則は初期化の間のラベル分配同輩の間のラベル分配隣接番組の情報交換か情報(このドキュメントの範囲の外の手段で、得る)に関する知識のどちらかを先験的の必要とします。
1. Each must state whether it supports label merging.
1. それぞれが、それがラベル合併を支持するかどうかと述べなければなりません。
2. If Rd does not support label merging, Rd must choose either the
PulledUnconditional procedure or the PulledConditional
procedure. If Rd chooses PulledConditional, Ru is forced to
use the RequestRetry procedure.
2. Rdがラベル合併を支持しないなら、RdはPulledUnconditional手順かPulledConditional手順のどちらかを選ばなければなりません。 RdがPulledConditionalを選ぶなら、Ruはやむを得ずRequestRetry手順を用います。
That is, if the downstream LSR does not support label merging,
its preferences take priority when the MPLS scheme is chosen.
すなわち、MPLS計画が選ばれていて、川下のLSRがラベル合併を支持しないなら、好みは優先します。
Rosen, et al. Standards Track [Page 57] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[57ページ]。
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.
すなわち、MPLS計画が選ばれていて、LSRsの唯一のひとりがラベル合併を支持しないなら、好みは優先します。
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(寛容な)を使用するのを選び始めます。 しかしながら、「無条件」に対して「牽引力」で「条件付き」に対する「プッシュ」の選択は通りに属します。 Ruが寛容なラベル保有モードを選ぶなら、RdはPushUnconditionalかPushConditionalのどちらかを選ぶことができます。 Ruが保守的なラベル保有モードを選ぶなら、RdはPushConditional、PulledConditional、またはPulledUnconditionalを選ぶことができます。
These choices together determine the MPLS scheme in use.
一緒にこれらの選択はMPLS計画を使用中に決定します。
6. Security Considerations
6. セキュリティ問題
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から特定の入って来るラベルを受け入れるなら、違法な方法でパケットを発送するかもしれません。
7. Intellectual Property
7. 知的所有権
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は本書では含まれた仕様いくつかかすべてに関して要求された知的所有権について通知されました。 詳しい情報に関しては、要求された権利のオンラインリストに相談してください。
Rosen, et al. Standards Track [Page 58] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[58ページ]。
8. Authors' Addresses
8. 作者のアドレス
Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824
Driveチェルムズフォード、エリックC.ローゼンシスコシステムズInc.250アポロMA 01824
EMail: erosen@cisco.com
メール: erosen@cisco.com
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd. Milpitas, CA 95035-7438
アルンViswanathan Force10はInc.1440マッカーシーBlvd.をネットワークでつなぎます。 ミルピタス、カリフォルニア95035-7438
EMail: arun@force10networks.com
メール: arun@force10networks.com
Ross Callon Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
ロスCallon JuniperはInc.1194の北のマチルダ・Avenueカリフォルニア94089サニーベル(米国)をネットワークでつなぎます。
EMail: rcallon@juniper.net
メール: rcallon@juniper.net
9. References
9. 参照
[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-気圧] デイビー、B.、ローレンス、J.、McCloghrie、K.、Rekhter、Y.、G.とP.Doolan、ローゼン、E.は飲み込まれます、「MPLSは自由民主党と気圧VCの切り換えを使用し」て、RFC3035、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.
[MPLS-CR-自由民主党] 「規制ベースのLSPセットアップは自由民主党を使用し」て、Jamoussi(エディタ)は進行中で働いています。
[MPLS-FRMRLY] Conta, A., Doolan, P. and A. Malis, "Use of Label
Switching on Frame Relay Networks Specification",
RFC 3034, January 2001.
[MPLS-FRMRLY] コンタ、A.、Doolan、P.、およびA.Malis、「フレームリレーにおけるラベルの切り換えの使用は仕様をネットワークでつなぎます」、RFC3034、2001年1月。
[MPLS-LDP] Andersson, L., Doolan, P., Feldman, N., Fredette,
A. and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[MPLS-自由民主党] アンデションとL.とDoolanとP.とフェルドマンとN.とFredetteとA.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
Rosen, et al. Standards Track [Page 59] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[59ページ]。
[MPLS-RSVP-TUNNELS] "Extensions to RSVP for LSP Tunnels", Awduche,
Berger, Gan, Li, Swallow, Srinvasan, Work in
Progress.
「LSP TunnelsのためのRSVPへの拡大」(Awduche、バーガー、ガン、李)が飲み込む[MPLS-RSVP-トンネル](Srinvasan)は進行中で働いています。
[MPLS-SHIM] Rosen, E., Rekhter, Y., Tappan, D., Fedorkow, G.,
Farinacci, D. and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[MPLS-詰め物] ローゼン、E.、Rekhter、Y.、タッパン、D.、Fedorkow、G.、ファリナッチ、D.、およびA.コンタ、「MPLSはスタックコード化をラベルします」、RFC3032、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の上の交通工学のための要件」RFC2702(1999年9月)。
Rosen, et al. Standards Track [Page 60] RFC 3031 MPLS Architecture January 2001
ローゼン、他 規格はMPLS構造2001年1月にRFC3031を追跡します[60ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Rosen, et al. Standards Track [Page 61]
ローゼン、他 標準化過程[61ページ]
一覧
スポンサーリンク
