RFC3906 日本語訳

Network Working Group                                            N. Shen
Request for Comments: 3906                              Redback Networks
Category: Informational                                          H. Smit
                                                            October 2004

コメントを求めるワーキンググループN.シン要求をネットワークでつないでください: 3906年の20ドル紙幣はカテゴリをネットワークでつなぎます: 情報のH.スミット2004年10月

          Calculating Interior Gateway Protocol (IGP) Routes
                    Over Traffic Engineering Tunnels

交通工学Tunnelsの上の計算の内部のゲートウェイプロトコル(IGP)ルート

Status of this Memo

この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).

Copyright(C)インターネット協会(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.

このドキュメントはInteriorゲートウェイプロトコル(IGP)近道を作成する新しいTraffic Engineering能力にホップごとの従来のLinkState方式プロトコルがどう対話するかを説明します。 特に、このドキュメントはリンク州のIGPsがTraffic Engineeringによって設立されるトンネルの上に交通を送るためにIPルートを計算するようにどうダイクストラのShortest Path First(SPF)アルゴリズムを適合させることができるかを説明します。

1.  Introduction

1. 序論

   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].

Intermediate Systemへの統合Intermediate Systemのようなリンク州のプロトコル、(-、)、[1]とOSPF[2]は、ネットワークにおけるすべてのノードに最短パス木を計算するのにダイクストラのSPFアルゴリズムを使用します。 この最短パス木から経路指定テーブルを得ます。 経路指定テーブルは目的地と最初に、ホップ情報のtuplesを含んでいます。 ルータがホップごとの正常なルーティングをすると、最初のホップはルータに付けられた物理インターフェースになるでしょう。 新しい交通工学アルゴリズムはネットワークで明白なルートを1つ以上のノードまで計算します。 明白なルートを溯源するルータでは、ネットワークを通してLabel Switched Pathsを供給する論理的なインタフェースとしてそのようなルートを見なすことができます。 このドキュメントの文脈では、Traffic Engineeringが(TE-トンネル)にトンネルを堀るとき、私たちはこれらのLabel Switched Pathsを参照します。 そのような能力は[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

ネットワークとネットワークの交通がどのようにそれらのトンネルの上に切り換えられているのが、直交した問題であるということであるかのTE-トンネルの存在。 ノードはTE-トンネルを示すスタティックルートを定義するかもしれなくて、それは合うかもしれません。

Shen & Smit                  Informational                      [Page 1]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[1ページ]のRFC3906IGP近道

   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-トンネルエンドポイントアドレス、またはそれによる次のホップの再帰的なルートは切り換えのある一定の交通のための親近感に基づいているトンネル選択などのローカルの方針を定義するかもしれません。 このドキュメントはダイナミックにそれらのTE-トンネルの上にIGPルートを設置するのにリンク州のIGPsを利用するメカニズムについて説明します。

   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に記述されたパケットを注入するのを選ぶと、ルータはエンドポイントが目的地Dの注入ルータより近く(リンク州のIGPトポロジーに従って)にあるトンネルにパケットを注ぐかもしれません。 言い換えれば、トンネルの末端は目的地D.のための川下のIGPノードでなければなりません。従うアルゴリズムはルータが使用するためにこの規則に従って、いつ頃に関してダイナミックに利口な選択をするかもしれない1つのようが交通にTEトンネルを堀るということです。 このアルゴリズムはTE-トンネルか交通の流れの上の静的に定義されたルートなどの他のメカニズムに関連して使用されたかもしれません、そして、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-トンネルはQoS、帯域幅、冗長、またはfastreroute理由に使用されるかもしれません。 IGP近道のメカニズムがそれらのトンネルに適用されるか、または他のメカニズムがIGP近道に関連して使用されるとき、それらのトンネルを通って切り替わる物理的な交通は初期の交通工学セットアップ目標に合わないかもしれません。 また、ネットワークにおけるトラフィック・パターンは時間を交換するかもしれません。 ネットワークが交通であることを保証するためにそこにあるTE-トンネル属性の必要性の調整への何らかの推進飛行機測定とフィードバックが効率的に[6]を設計しました。

2.  Enhancement to the Shortest Path First Computation

2. 最短パス最初の計算への増進

   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.

交通工学目的のために、各ルータはこのルータで由来するすべてのTE-トンネルのリストを維持します。 それぞれのそれらのTEトンネルに関しては、末端のルータは知られています。

Shen & Smit                  Informational                      [Page 2]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[2ページ]のRFC3906IGP近道

   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:

ルータが新しいノードに経路を見つけるとき(言い換えれば、この新しいノードはTENTativeリストからPATHSリストに移されます)、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-トンネルがあれば、私たちは最初に、ホップとしてTE-トンネルを使用します。

      -  If there is no TE-tunnel, and the node is directly connected,
         we use the first-hop information from the adjacency database.

- TE-トンネルが全くなくて、ノードが直接接続されるなら、私たちは隣接番組データベースからの最初に、ホップ情報を使用します。

      -  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-トンネルの末端であるノードへのその交通であり、それらのTE-トンネルの上を流れるでしょう。 また、川下にある末端ノードのノードへの交通はそれらのTE-トンネルの上を流れるでしょう。 目的地ノードXへの経路の異なった中間的ノードへの複数のTE-トンネルがあると、交通は末端ノードがノードのX.のInのあるアプリケーションの最も近くにあるTE-トンネルの上を流れて、自然な隣接番組とTE-トンネルの末端のためのTE-トンネル次のホップ情報とその川下のノードの両方を運ぶ必要があります。 ギヤエンドのノードは条件付きにユーザの定義された評価基準か出来事に基づくTE-トンネルにデータ通信量を切り換えるかもしれません。 ギヤエンドのノードは次のホップのタイプに向かった交通のまた、分かれている流れがそうするかもしれません。 ギヤエンドのノードは2つの異なったタイプの次のホップで2別々のRIBsにルートをインストールするかもしれません。 物理的なリンクをひくマルチキャストプロトコルはTEトンネルを堀っている次のホップよりむしろ次のホップで自然な隣接番組を使用するRPFチェックを実行しなければならないかもしれません。

3.  Special Cases and Exceptions

3. 特別なケースと例外

   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.

Shortest Path Firstアルゴリズムは等しい費用の平行な経路を目的地に見つけるでしょう。 本書では説明された増進はこれを変えません。 交通は1つ以上のTE-トンネルの上、または、ネイティブのIP経路とTE-トンネルの組み合わせの上に1つ以上のネイティブのIP経路を送ることができます。

   A special situation occurs in the following topology:

特別な状況は以下のトポロジーに起こります:

      rtrA -- rtrB -- rtrC
               |       |
              rtrD -- rtrE

rtrA--rtrB--rtrC| | rtrD--rtrE

Shen & Smit                  Informational                      [Page 3]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[3ページ]のRFC3906IGP近道

   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計算がTENTativeリストにrtrCを載せるとき、rtrCが直接接続されないのは換金されるでしょう、そして、その結果、それが親からの最初に、ホップ情報を使用するでしょう。(その親は、rtrBです)。 rtrAにおけるSPF計算がTENTativeリストからPATHSリストへrtrDを移すとき、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がTENTativeリストにrtrEを載せるとき、rtrEが直接接続されないで、またrtrEがTEトンネルの末端でないことは換金されます。 したがって、rtrAは両親(rtrCとrtrD)からrtrEの最初に、ホップ情報まで最初に、ホップ情報をコピーするでしょう。 rtrEへの現在負荷でrtrAを通したネイティブのIP経路の上で>rtrB->のバランスをとっている意志のrtrC、およびTE-トンネルrtrA->rtrDを取引してください。

   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の上の経路トンネルの両方が利用可能である場合では、実現で、ネットワーク管理者は、負荷分割法に使用されるためにTE-トンネル(またはネイティブのIP経路だけの上で)か両方だけの上で強制的に交通を流れさせることができます。

4.  Metric Adjustment of IP Routes over TE-tunnels

4. IPのメートル法の調整はTeトンネルの上で発送します。

   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.

IGPルートが次のホップとしてTE-トンネルがある経路指定テーブルにインストールされるとき、面白い質問はこのルートで費用の、または、メートル法であるべきことですか? 最も明白な答えはメートル法でaを割り当てるために、まるでTE-トンネルが存在していないかのようにそれがネイティブのIP経路におけるメートル法のIGPと同じであるということです。 例えば、rtrAは経路の上で20の費用でrtrCに達することができます。 XはrtrCによって広告に掲載されたIP接頭語です。 私たちはrtrAの経路指定テーブルで20の費用でルートをXにインストールします。 rtrAからrtrCまでのTE-トンネルが来るとき、デフォルトで、20におけるメートル法でまだルートをインストールしていて、Xのための次のホップ情報だけを変えます。

   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-トンネルの上で経路の費用を調整することによって、交通をTE-トンネルを通って経路を好むか、ネイティブのIP経路を好むか、または私たちは負荷でそれらの中で強制的にバランスをとらせることができます。 別の例は複数のTE-トンネルが同じであるか異なった目的地まで続く時です。 測定基準が強制できるTE-トンネルを調整して、それらの目的地へのIGP費用にアンダーラインを引くことにかかわらずいくらかのTEを好む交通は他のものの上でトンネルを堀ります。

Shen & Smit                  Informational                      [Page 4]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[4ページ]のRFC3906IGP近道

   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-トンネルがソースによって発送されていて、トンネル出口が計算された目的地に達する川下のノードであるので、このメカニズムには、輪がありません。 TE-トンネルのメートル法の調整の結末は交通loadsharingの、より多くのコントロールです。 交通には、1つしかなければ、次にたとえ何があっても、単一のTE-トンネルを通ってメートル法で特定のIP接頭語に達する方法は割り当てられて、行くために、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のための個人的なRIBとしてこのセクションで説明された経路指定テーブルは見なすことができます。 メートル法は経路指定テーブルのルートへの重要な属性です。 経路か低いメートル法の意志が同じくらいのために他の経路に関して選択されている経路が経路指定テーブルを中に発送します。

4.1.  Absolute and Relative Metrics

4.1. 絶対の、そして、相対的な測定基準

   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.

2つの異なった方法でメートル法のTE-トンネルを表すのは可能です: メートル法かa絶対の、そして、(修理される)の親類メートル法であり、単にSPF計算による計算されるとしてのメートル法のダイナミックなIGPの調整はどれですか? TE-トンネルのメートル法の絶対的なものを使用するとき、経路指定テーブルのIPルートの費用はネットワークのトポロジーに依存しません。 メートル法で修理されたこれがTE-トンネルの末端ですが、川下にあるこの末端ルータのすべてのルートにも末端であるルータによって広告に掲載されたIPルートの費用を計算するのに使用されるだけではないことに注意してください。 例えば、私たちがリモートPOPにTEトンネルを2つのコアルータまで持って、それらの1つが1におけるメートル法の絶対的なもので割り当てられると、そのPOPに行くすべての交通がこの低いメートル法の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-トンネルのメートル法のaを構成しないのは、相対的なメートル法の計画の特別なケースです。 メートル法でないことは、0におけるメートル法の親類と同じくらいです。 親類メートル法であることは、制限されて、最小の、そして、最大の許容メートル法の数値がメートル法で正数をゆったり過ごすということです。SPF計算でTEトンネルを無能にします。

Shen & Smit                  Informational                      [Page 5]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[5ページ]のRFC3906IGP近道

4.2.  Examples of Metric Adjustment

4.2. メートル法の調整に関する例

   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接頭語です。 rtrAからrtrCまでT1はTE-トンネルです。 ネットワークにおける各リンクで、IGPは10でメートル法になります。

        ===== T1 =====>
      rtrA -- rtrB -- rtrC -- rtrD -- rtrE
           10      10  |   10  |   10  |
                       X       Y       Z

===== T1=====>rtrA--rtrB--rtrC--rtrD--rtrE10 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-トンネルT1がなければ、rtrAは測定基準20、30、および40でIPルートX、Y、およびZを経路指定テーブルにそれぞれインストールするでしょう。 rtrAがrtrCとrtrAが-5におけるトンネルT1のメートル法の親類に構成されるかどうかにTE-トンネルT1を持って来たなら、ルートX、Y、およびZは測定基準15、25、および35で経路指定テーブルにインストールされるでしょう。 5におけるメートル法の絶対的なものがトンネルT1で構成されると、rtrAはすべて測定基準5、15、および25でそれぞれルートX、Y、およびZをインストールするでしょう。

5.  Security Considerations

5. セキュリティ問題

   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].

このドキュメントがセキュリティ局面を変えない、-、または、OSPF。 各プロトコルに特定のセキュリティ問題はまだ適用されています。 詳しい情報に関しては、[5]と[2]を見てください。

6.  Acknowledgments

6. 承認

   The authors would like to thank Joel Halpern and Christian Hopps for
   their comments on this document.

作者はこのドキュメントの彼らのコメントについてジョエル・アルペルンとクリスチャンのホップスに感謝したがっています。

7.  Informative References

7. 有益な参照

   [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。 情報技術--システムの間のテレコミュニケーションと情報交換--プロトコルに関連したコネクションレスなモードネットワーク・サービスを提供する使用のための中間システムルート設定交換プロトコルへの中間システム。 ISO、1990。

   [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

[2]Moy、J.、「OSPF、バージョン2インチ、RFC2328、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.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(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.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。

Shen & Smit                  Informational                      [Page 6]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[6ページ]のRFC3906IGP近道

   [5] Li, T. and R. Atkinson, "Intermediate System to Intermediate
       System (IS-IS) Cryptographic Authentication", RFC 3567, July
       2003.

[5] 李、T.、およびR.アトキンソン、「中間システムへの中間システム、(-、)、暗号の認証、」、RFC3567、7月2003日

   [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.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、およびX.Xiao、「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。

8.  Authors' Addresses

8. 作者のアドレス

   Naiming Shen
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA 95134

シンRedbackをNaimingすると、Inc.300オルガーWayサンノゼ(カリフォルニア)95134はネットワークでつながれます。

   EMail: naiming@redback.com

メール: naiming@redback.com

   Henk Smit

ヘンク・スミット

   EMail: hhwsmit@xs4all.nl

メール: hhwsmit@xs4all.nl

Shen & Smit                  Informational                      [Page 7]

RFC 3906              IGP ShortCut Over MPLS LSPs           October 2004

MPLS LSPs2004年10月の間のシンとスミット情報[7ページ]のRFC3906IGP近道

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金は現在、インターネット協会によって提供されます。

Shen & Smit                  Informational                      [Page 8]

シンとスミットInformationalです。[8ページ]