[要約] RFC 3906は、トラフィックエンジニアリングトンネル上の内部ゲートウェイプロトコル（IGP）ルートの計算に関する情報を提供しています。このRFCの目的は、IGPルーティングとトラフィックエンジニアリングの統合を可能にするためのガイドラインを提供することです。
Network Working Group N. Shen
Request for Comments: 3906 Redback Networks
Category: Informational H. Smit
October 2004
Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels
インテリアゲートウェイプロトコル（IGP）が交通工学トンネルを介してルートを計算する
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering.
このドキュメントでは、従来のホップバイホップリンク状態ルーティングプロトコルが新しいトラフィックエンジニアリング機能と対話し、インテリアゲートウェイプロトコル（IGP）ショートカットを作成する方法について説明します。特に、このドキュメントでは、Dijkstraの最短パスファースト（SPF）アルゴリズムがどのように適応できるかについて説明し、リンク状態IGPSがIPルートを計算して、トラフィックエンジニアリングによって設定されたトンネル上にトラフィックを転送することです。
Link-state protocols like integrated Intermediate System to Intermediate System (IS-IS) [1] and OSPF [2] use Dijkstra's SPF algorithm to compute a shortest path tree to all nodes in the network. Routing tables are derived from this shortest path tree. The routing tables contain tuples of destination and first-hop information. If a router does normal hop-by-hop routing, the first-hop will be a physical interface attached to the router. New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. At the router that originates explicit routes, such routes can be viewed as logical interfaces which supply Label Switched Paths through the network. In the context of this document, we refer to these Label Switched Paths as Traffic Engineering tunnels (TE-tunnels). Such capabilities are specified in [3] and [4].
中間システム（IS-IS）[1]およびOSPF [2]への統合された中間システムなどのリンク状態プロトコルは、DijkstraのSPFアルゴリズムを使用して、ネットワーク内のすべてのノードに最短のパスツリーを計算します。ルーティングテーブルは、この最短のパスツリーから派生しています。ルーティングテーブルには、宛先情報と最初のホップ情報が含まれています。ルーターが通常のホップバイホップルーティングを実行する場合、最初のホップはルーターに接続された物理インターフェイスになります。新しいトラフィックエンジニアリングアルゴリズムは、ネットワーク内の1つ以上のノードへの明示的なルートを計算します。明示的なルートを発信するルーターでは、そのようなルートは、ネットワークを通るラベルが切り替えられたパスを供給する論理インターフェイスとして見ることができます。このドキュメントのコンテキストでは、これらのラベルスイッチされたパスをトラフィックエンジニアリングトンネル（TEタンネル）と呼びます。このような機能は、[3]および[4]で指定されています。
The existence of TE-tunnels in the network and how the traffic in the network is switched over those tunnels are orthogonal issues. A node may define static routes pointing to the TE-tunnels, it may match the recursive route next-hop with the TE-tunnel end-point address, or it may define local policy such as affinity based tunnel selection for switching certain traffic. This document describes a mechanism utilizing link-state IGPs to dynamically install IGP routes over those TE-tunnels.
ネットワーク内のTe-Tunnelの存在と、それらのトンネルの上にネットワーク内のトラフィックがどのように切り替わるかは直交の問題です。ノードは、TE-Tunnelsを指す静的ルートを定義し、再帰ルートの次のホップとTEトンネルエンドポイントアドレスと一致する場合があります。また、特定のトラフィックを切り替えるためのアフィニティベースのトンネル選択などのローカルポリシーを定義する場合があります。このドキュメントでは、リンク状態IGPSを利用して、これらのテタンネルにIGPルートを動的にインストールするメカニズムについて説明します。
The tunnels under consideration are tunnels created explicitly by the node performing the calculation, and with an end-point address known to this node. For use in algorithms such as the one described in this document, it does not matter whether the tunnel itself is strictly or loosely routed. A simple constraint can ensure that the mechanism be loop free. When a router chooses to inject a packet addressed to a destination D, the router may inject the packet into a tunnel where the end-point is closer (according to link-state IGP topology) to the destination D than is the injecting router. In other words, the tail-end of the tunnel has to be a downstream IGP node for the destination D. The algorithms that follow are one way that a router may obey this rule and dynamically make intelligent choices about when to use TE-tunnels for traffic. This algorithm may be used in conjunction with other mechanisms such as statically defined routes over TE-tunnels or traffic flow and QoS based TE-tunnel selection.
検討中のトンネルは、計算を実行するノードによって明示的に作成されたトンネルと、このノードに既知のエンドポイントアドレスがあることによって作成されます。このドキュメントで説明されているようなアルゴリズムで使用するために、トンネル自体が厳密か緩やかにルーティングされているかは関係ありません。単純な制約により、メカニズムがループフリーになるようにします。ルーターが宛先Dにアドレス指定されたパケットを注入することを選択すると、ルーターは、注入ルーターよりもエンドポイントが（リンク状態のIGPトポロジーに従って）宛先Dにエンドポイントが近づいているトンネルにパケットを注入できます。言い換えれば、トンネルのテールエンドは、宛先Dの下流のIGPノードでなければなりません。以下のアルゴリズムは、ルーターがこのルールに従い、Te-Tunnelを使用する時期について動的にインテリジェントな選択をする可能性がある1つの方法です。渋滞。このアルゴリズムは、Te-Tunnels上の静的に定義されたルートや交通フロー、QoSベースのTEトンネル選択など、他のメカニズムと組み合わせて使用できます。
This IGP shortcut mechanism assumes the TE-tunnels have already been setup. The TE-tunnels in the network may be used for QoS, bandwidth, redundancy, or fastreroute reasons. When an IGP shortcut mechanism is applied on those tunnels, or other mechanisms are used in conjunction with an IGP shortcut, the physical traffic switching through those tunnels may not match the initial traffic engineering setup goal. Also the traffic pattern in the network may change with time. Some forwarding plane measurement and feedback into the adjustment of TE-tunnel attributes need to be there to ensure that the network is being traffic engineered efficiently [6].
このIGPショートカットメカニズムは、TEタンネルがすでにセットアップされていることを前提としています。ネットワーク内のTe-Tunnelsは、QoS、帯域幅、冗長性、またはFastrerouteの理由に使用できます。これらのトンネルにIGPショートカットメカニズムが適用される場合、または他のメカニズムがIGPショートカットと併用される場合、これらのトンネルを通る物理的な交通スイッチは、初期の交通エンジニアリングセットアップの目標と一致しない場合があります。また、ネットワーク内のトラフィックパターンは時間とともに変化する場合があります。ネットワークが効率的にトラフィックエンジニアリングされていることを確認するために、TE-Tunnel属性の調整へのいくつかの転送面測定とフィードバックが必要です[6]。
During each step of the SPF computation, a router discovers the path to one node in the network. If that node is directly connected to the calculating router, the first-hop information is derived from the adjacency database. If a node is not directly connected to the calculating router, it inherits the first-hop information from the parent(s) of that node. Each node has one or more parents. Each node is the parent of zero or more down-stream nodes.
SPF計算の各ステップで、ルーターがネットワーク内の1つのノードへのパスを発見します。そのノードが計算ルーターに直接接続されている場合、最初のホップ情報は隣接データベースから派生します。ノードが計算ルーターに直接接続されていない場合、そのノードの親からの最初のホップ情報を継承します。各ノードには1人以上の親がいます。各ノードは、ゼロ以上のダウンストリームノードの親です。
For traffic engineering purposes, each router maintains a list of all TE-tunnels that originate at this router. For each of those TE-tunnels, the router at the tail-end is known.
トラフィックエンジニアリングの目的で、各ルーターは、このルーターで発生するすべてのテタンネルのリストを維持します。これらのテタンネルのそれぞれについて、テールエンドのルーターが知られています。
During SPF, when a router finds the path to a new node (in other words, this new node is moved from the TENTative list to the PATHS list), the router must determine the first-hop information. There are three possible ways to do this:
SPFの間に、ルーターが新しいノードへのパス（言い換えれば、この新しいノードが暫定リストからパスリストに移動される）の間、ルーターは最初のホップ情報を決定する必要があります。これを行うには3つの可能な方法があります。
- Examine the list of tail-end routers directly reachable via a TE-tunnel. If there is a TE-tunnel to this node, we use the TE-tunnel as the first-hop.
- TEトンネルを介して直接到達可能なテールエンドルーターのリストを調べます。このノードにTE-Tunnelがある場合、TE-Tunnelを最初のホップとして使用します。
- If there is no TE-tunnel, and the node is directly connected, we use the first-hop information from the adjacency database.
- Te-Tunnelがなく、ノードが直接接続されている場合、隣接データベースの最初のホップ情報を使用します。
- If the node is not directly connected, and is not directly reachable via a TE-tunnel, we copy the first-hop information from the parent node(s) to the new node.
- ノードが直接接続されておらず、TEトンネルを介して直接到達できない場合は、親ノードから新しいノードに最初のホップ情報をコピーします。
The result of this algorithm is that traffic to nodes that are the tail-end of TE-tunnels, will flow over those TE-tunnels. Traffic to nodes that are downstream of the tail-end nodes will also flow over those TE-tunnels. If there are multiple TE-tunnels to different intermediate nodes on the path to destination node X, traffic will flow over the TE-tunnel whose tail-end node is closest to node X. In certain applications, there is a need to carry both the native adjacency and the TE-tunnel next-hop information for the TE-tunnel tail-end and its downstream nodes. The head-end node may conditionally switch the data traffic onto TE-tunnels based on user defined criteria or events; the head-end node may also split flow of traffic towards either types of the next-hops; the head-end node may install the routes with two different types of next-hops into two separate RIBs. Multicast protocols running over physical links may have to perform RPF checks using the native adjacency next-hops rather than the TE-tunnel next-hops.
このアルゴリズムの結果、Te-Tunnelsのテールエンドであるノードへのトラフィックは、それらのTe-Tunnels上に流れます。テールエンドノードの下流にあるノードへのトラフィックも、これらのTe-Tunnelの上に流れます。宛先ノードXへのパス上に異なる中間ノードに複数のテトゥンネルがある場合、テールエンドノードがノードXに最も近いTE-Tunnelの上にトラフィックが流れます。特定のアプリケーションでは、両方を運ぶ必要があります。ネイティブの隣接とTEトンネルネクストホップ情報は、TEトンネルテールエンドとその下流ノードの情報です。ヘッドエンドノードは、ユーザー定義の基準またはイベントに基づいて、データトラフィックをテタンネルに条件付きで切り替えることができます。ヘッドエンドノードは、次のホップのいずれかのタイプに向かってトラフィックの流れを分割する場合があります。ヘッドエンドノードは、2つの異なるタイプのネクストホップを備えたルートを2つの別々のリブに取り付けることができます。物理的なリンクを介して実行されるマルチキャストプロトコルは、TEタンネルの次のホップではなく、ネイティブの隣接次のホップを使用してRPFチェックを実行する必要がある場合があります。
The Shortest Path First algorithm will find equal-cost parallel paths to destinations. The enhancement described in this document does not change this. Traffic can be forwarded over one or more native IP paths, over one or more TE-tunnels, or over a combination of native IP paths and TE-tunnels.
最短パスファーストアルゴリズムは、宛先への等しいコストの並列パスを見つけます。このドキュメントで説明されている強化はこれを変更しません。トラフィックは、1つまたは複数のネイティブIPパス、1つ以上のTe-Thinnels、またはネイティブIPパスとTEタンネルの組み合わせに転送できます。
A special situation occurs in the following topology:
次のトポロジーで特別な状況が発生します。
rtrA -- rtrB -- rtrC
| |
rtrD -- rtrE
Assume all links have the same cost. Assume a TE-tunnel is set up from rtrA to rtrD. When the SPF calculation puts rtrC on the TENTative list, it will realize that rtrC is not directly connected, and thus it will use the first-hop information from the parent, which is rtrB. When the SPF calculation on rtrA moves rtrD from the TENTative list to the PATHS list, it realizes that rtrD is the tail-end of a TE-tunnel. Thus rtrA will install a route to rtrD via the TE-tunnel, and not via rtrB.
すべてのリンクに同じコストがあると仮定します。TEトンネルがRTRAからRTRDにセットアップされていると仮定します。SPF計算がRTRCを暫定リストに載せると、RTRCが直接接続されていないことがわかります。したがって、親からの最初のホップ情報、つまりRTRBが使用されます。RTRAのSPF計算がRTRDを暫定リストからPATHSリストに移動すると、RTRDがTEトンネルのテールエンドであることがわかります。したがって、RTRAは、RTRBを介してではなく、TEトンネルを介してRTRDへのルートをインストールします。
When rtrA puts rtrE on the TENTative list, it realizes that rtrE is not directly connected, and that rtrE is not the tail-end of a TE-tunnel. Therefore, rtrA will copy the first-hop information from the parents (rtrC and rtrD) to the first-hop information of rtrE. Traffic to rtrE will now load-balance over the native IP path via rtrA->rtrB->rtrC, and the TE-tunnel rtrA->rtrD.
RTRAが暫定リストにRTREを配置すると、RTREが直接接続されておらず、RTREがTEトンネルのテールエンドではないことを認識します。したがって、RTRAは、親（RTRCおよびRTRD）から最初のホップ情報をRTREの最初のホップ情報にコピーします。RTREへのトラフィックは、RTRA-> RTRB-> RTRCとTE-Tunnel RTRA-> RTRDを介して、ネイティブIPパスを介してバランスを負荷します。
In the case where both parallel native IP paths and paths over TE-tunnels are available, implementations can allow the network administrator to force traffic to flow over only TE-tunnels (or only over native IP paths) or both to be used for load sharing.
並列ネイティブIPパスとTEタンネル上のパスの両方が利用可能な場合、実装により、ネットワーク管理者はトラフィックにテクスンのみ（またはネイティブIPパスのみ）またはその両方をロード共有に使用できるようにすることができます。。
When an IGP route is installed in the routing table with a TE-tunnel as the next hop, an interesting question is what should be the cost or metric of this route? The most obvious answer is to assign a metric that is the same as the IGP metric of the native IP path as if the TE-tunnels did not exist. For example, rtrA can reach rtrC over a path with a cost of 20. X is an IP prefix advertised by rtrC. We install the route to X in rtrA's routing table with a cost of 20. When a TE-tunnel from rtrA to rtrC comes up, by default the route is still installed with metric of 20, only the next-hop information for X is changed.
次のホップとしてTE-Tunnelを使用してルーティングテーブルにIGPルートを設置する場合、興味深い質問は、このルートのコストまたはメトリックがどうあるべきかということです。最も明白な答えは、Te-Tunnelsが存在しないかのように、ネイティブIPパスのIGPメトリックと同じメトリックを割り当てることです。たとえば、RTRAは20のコストでパスでRTRCに到達できます。XはRTRCによって宣伝されているIPプレフィックスです。RTRAのルーティングテーブルでXへのルートを20のコストでインストールします。RTRAからRTRCへのTEトンネルが表示されると、デフォルトではルートが20のメートルでインストールされています。。
While this scheme works well, in some networks it might be useful to change the cost of the path over a TE-tunnel, to make the route over the TE-tunnel less or more preferred than other routes.
このスキームはうまく機能しますが、一部のネットワークでは、TEトンネル上のパスのコストを変更して、他のルートよりもTEトンネル上のルートを好むか、それ以上にすることが役立つ場合があります。
For instance, when equal cost paths exist over a TE-tunnel and over a native IP path, by adjusting the cost of the path over the TE-tunnel, we can force traffic to prefer the path via the TE-tunnel, to prefer the native IP path, or to load-balance among them. Another example is when multiple TE-tunnels go to the same or different destinations. Adjusting TE-tunnel metrics can force the traffic to prefer some TE-tunnels over others regardless of underlining IGP cost to those destinations.
たとえば、TEトンネルとネイティブのIPパスに等しいコストパスが存在する場合、TE-Tunnelのパスのコストを調整することにより、TE-Tunnelを介してパスを好むようにトラフィックを強制することができます。ネイティブのIPパス、またはそれらの間の負荷バランスへ。別の例は、複数のテタンネルが同じまたは異なる宛先に行くときです。TE-Tunnelメトリックの調整により、IGPのコストをこれらの目的地に下げても、トラフィックに他の人よりもトラフィックを優先させることができます。
Setting a manual metric on a TE-tunnel does not impact the SPF algorithm itself. It only affects the comparison of the new route with existing routes in the routing table. Existing routes can be either IP routes to another router that advertises the same IP prefix, or it can be a path to the same router, but via a different outgoing interface or different TE-tunnel. All routes to IP prefixes advertised by the tail-end router will be affected by the TE-tunnel metric. Also, the metrics of paths to routers that are downstream of the tail-end router will be influenced by the manual TE-tunnel metric.
TEタンネルに手動メトリックを設定しても、SPFアルゴリズム自体に影響しません。それは、ルーティングテーブル内の既存のルートとの新しいルートの比較にのみ影響します。既存のルートは、同じIPプレフィックスを宣伝する別のルーターへのIPルートか、同じルーターへのパスになる可能性がありますが、異なる発信インターフェイスまたは異なるTEトンネルを介して行われます。テールエンドルーターによって宣伝されているIPプレフィックスへのすべてのルートは、TEトンネルメトリックの影響を受けます。また、テールエンドルーターの下流のルーターへのパスのメトリックは、マニュアルTEトンネルメトリックの影響を受けます。
This mechanism is loop free since the TE-tunnels are source-routed and the tunnel egress is a downstream node to reach the computed destinations. The end result of TE-tunnel metric adjustment is more control over traffic loadsharing. If there is only one way to reach a particular IP prefix through a single TE-tunnel, then no matter what metric is assigned, the traffic has only one path to go.
Te-Tunnelsはソースルーティングであり、トンネルエッセージが計算された宛先に到達するための下流ノードであるため、このメカニズムはループフリーです。TEトンネルメトリック調整の最終結果は、トラフィックの負荷をより制御することです。単一のTEタンネルを介して特定のIPプレフィックスに到達する方法が1つしかない場合、どのメトリックが割り当てられていても、トラフィックには1つのパスしかありません。
The routing table described in this section can be viewed as the private RIB for the IGP. The metric is an important attribute to the routes in the routing table. A path or paths with lower metric will be selected over other paths for the same route in the routing table.
このセクションで説明するルーティングテーブルは、IGPのプライベートリブとして表示できます。メトリックは、ルーティングテーブルのルートの重要な属性です。ルーティングテーブル内の同じルートの他のパスでメートルートが低いパスまたはパスが選択されます。
It is possible to represent the TE-tunnel metric in two different ways: an absolute (or fixed) metric or a relative metric, which is merely an adjustment of the dynamic IGP metric as calculated by the SPF computation. When using an absolute metric on a TE-tunnel, the cost of the IP routes in the routing table does not depend on the topology of the network. Note that this fixed metric is not only used to compute the cost of IP routes advertised by the router that is the tail-end of the TE-tunnel, but also for all the routes that are downstream of this tail-end router. For example, if we have TE-tunnels to two core routers in a remote POP, and one of them is assigned with an absolute metric of 1, then all the traffic going to that POP will traverse this low-metric TE-tunnel.
TE-Tunnelメトリックを2つの異なる方法で表すことができます：絶対（または固定）メトリックまたは相対メトリックは、SPF計算によって計算された動的IGPメトリックの単なる調整です。TEトンネルで絶対メトリックを使用する場合、ルーティングテーブルのIPルートのコストは、ネットワークのトポロジに依存しません。この固定されたメトリックは、TE-Tunnelのテールエンドであるルーターによって宣伝されたIPルートのコストを計算するために使用されるだけでなく、このテールエンドルーターの下流のすべてのルートに対しても使用されることに注意してください。たとえば、リモートポップに2つのコアルーターにTe-Tunnelsがあり、そのうちの1つが絶対メトリック1で割り当てられている場合、そのポップに行くすべてのトラフィックはこの低メトリックのTEターンネルを横断します。
By setting a relative metric, the cost of IP routes in the routing table is based on the IGP metric as calculated by the SPF computation. This relative metric can be a positive or a negative number. Not configuring a metric on a TE-tunnel is a special case of the relative metric scheme. No metric is the same as a relative metric of 0. The relative metric is bounded by minimum and maximum allowed metric values while the positive metric disables the TE-tunnel in the SPF calculation.
相対メトリックを設定することにより、ルーティングテーブルのIPルートのコストは、SPF計算で計算されたIGPメトリックに基づいています。この相対メトリックは、正または負の数になります。TE-Tunnelでメトリックを構成しないことは、相対メトリックスキームの特別なケースです。メトリックはありません。相対メトリックは0の相対メトリックと同じです。相対メトリックは最小値と最大許容メートル値によって制限されますが、正のメトリックはSPF計算のTEトンネルを無効にします。
Assume the following topology. X, Y, and Z are IP prefixes advertised by rtrC, rtrD, and rtrE respectively. T1 is a TE-tunnel from rtrA to rtrC. Each link in the network has an IGP metric of 10.
次のトポロジを仮定します。X、Y、およびZは、それぞれRTRC、RTRD、およびRTREによって宣伝されているIPプレフィックスです。T1は、RTRAからRTRCまでのTEトンネルです。ネットワーク内の各リンクのIGPメトリックは10です。
===== T1 =====>
rtrA -- rtrB -- rtrC -- rtrD -- rtrE
10 10 | 10 | 10 |
X Y Z
Without TE-tunnel T1, rtrA will install IP routes X, Y, and Z in the routing table with metrics 20, 30, and 40 respectively. When rtrA has brought up TE-tunnel T1 to rtrC, and if rtrA is configured with the relative metric of -5 on tunnel T1, then the routes X, Y, and Z will be installed in the routing table with metrics 15, 25, and 35. If an absolute metric of 5 is configured on tunnel T1, then rtrA will install routes X, Y, and Z all with metrics 5, 15, and 25 respectively.
Te-Tunnel T1を使用しないと、RTRAはそれぞれメトリック20、30、および40を備えたルーティングテーブルにIPルートX、Y、Zをインストールします。RTRAがTe -Tunnel T1をRTRCに持ち込み、RTRAがトンネルT1に-5の相対メトリックで構成されている場合、ルートX、Y、Zは、メトリック15、25のルーティングテーブルにインストールされます。35. 5の絶対メトリックがトンネルT1で構成されている場合、RTRAはそれぞれメトリック5、15、および25のルートX、Y、およびZをすべてインストールします。
This document does not change the security aspects of IS-IS or OSPF. Security considerations specific to each protocol still apply. For more information see [5] and [2].
このドキュメントは、IS-ISまたはOSPFのセキュリティの側面を変更しません。各プロトコルに固有のセキュリティ上の考慮事項は引き続き適用されます。詳細については、[5]および[2]を参照してください。
The authors would like to thank Joel Halpern and Christian Hopps for their comments on this document.
著者は、この文書に関するコメントについて、Joel HalpernとChristian Hoppsに感謝したいと思います。
[1] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990.
[1] ISO。情報技術 - 電気通信とシステム間の情報交換 - Connectionless -Modeネットワークサービスを提供するためのプロトコルと併用するための中間システムから中間システムルーティング交換プロトコル。ISO、1990。
[2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[2] Moy、J。、「OSPFバージョン2」、RFC 2328、1998年4月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[3] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[4] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[4] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、2001年12月。
[5] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[5] Li、T。およびR. Atkinson、「中間システムから中間システム（IS-IS）暗号化認証」、RFC 3567、2003年7月。
[6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[6] Awduche、D.、Chiu、A.、Elwalid、A.、Widjaja、I。、およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、RFC 3272、2002年5月。
Naiming Shen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134
Naiming Shen Redback Networks、Inc。300 Holger Way San Jose、CA 95134
EMail: naiming@redback.com
Henk Smit
ヘンクスミット
EMail: hhwsmit@xs4all.nl
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。