Network Working Group J.-P. Vasseur, Ed.
Request for Comments: 4561 Z. Ali
Category: Standards Track S. Sivabalan
Cisco Systems, Inc.
June 2006
Definition of a Record Route Object (RRO) Node-Id Sub-Object
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method.
MPLS TEの文脈高速リルートでは、合流点は、（MP）アドレスは、下流の高速reroutableトラフィックエンジニアリングラベルスイッチパス（TE LSP）交差するバックアップトンネルを選択するために、現地修理のポイント（PLR）で必要とされますラベルスイッチングルータ（LSR）。しかし、既存のプロトコルメカニズムは、ドメインが内部ゲートウェイプロトコル（IGP）領域または自律システム（AS）として定義されているマルチドメインルーティングネットワークにおけるMPのアドレスを見つけることは十分ではありません。したがって、現在のMPLS高速リルート機構はエリア境界ルータ（ABR）または自律システム境界ルータ（ASBR）の障害からドメイン間TE LSPを保護するために使用することができません。この文書では、このようにしてこの問題を解決するためにノードIDサブオブジェクトを定義する（定義された新しいフラグで）既存のレコードルートオブジェクト（RRO）、IPv4とIPv6のサブオブジェクトの使用を指定します。この文書に記載されたMPLS高速リルートメカニズムは「施設のバックアップ」MPLS TE高速リルートの方法を指します。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................4
2.1. Conventions Used in This Document ..........................5
3. Signaling Node-Ids in RROs ......................................5
4. Finding Merge Point .............................................6
5. Security Considerations .........................................7
6. Acknowledgements ................................................7
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................8
MPLS Fast Reroute (FRR) [FAST-REROUTE] is a fast recovery local protection technique used to protect Traffic Engineering LSPs from link/node/Shared Risk Link Group (SRLG) failure. One or more backup tunnels are pre-established to protect against the failure of a link/node/SRLG. In case of failure, every protected TE LSP traversing the failed resource is rerouted onto the appropriate backup tunnel.
MPLS高速リルート（FRR）[FAST-REROUTE]は、リンク/ノード/共有リスクリンクグループ（SRLG）障害からのトラフィックエンジニアリングLSPを保護するために使用する高速回復ローカル保護技術です。 1つまたは複数のバックアップトンネルは、リンク/ノード/ SRLGの障害から保護するために、事前に確立されています。障害が発生した場合に、障害が発生したリソースを横断するすべての保護されたTE LSPは、適切なバックアップトンネルに再ルーティングされます。
There are several requirements on the backup tunnel path that must be satisfied. First, the backup tunnel must not traverse the element that it protects. In addition, a primary tunnel and its associated backup tunnel should intersect at least at two points (nodes): Point of Local Repair (PLR) and Merge Point (MP). The former is the head-end LSR of the backup tunnel, and the latter is the tail-end LSR of the backup tunnel. The PLR is where FRR is triggered when link/node/SRLG failure happens.
満たさなければならないバックアップトンネルパス上のいくつかの要件があります。まず、バックアップトンネルは、それが保護する要素を横断してはいけません。また、プライマリトンネルとその関連するバックアップトンネルは少なくとも2点（ノード）で交差する必要がありますローカル修復点（PLR）とポイント（MP）をマージします。前者は、バックアップトンネルのヘッドエンドLSRであり、後者は、バックアップトンネルのテールエンドLSRです。 PLRは、リンク/ノード/ SRLG障害が発生したときFRRがトリガーされる場合です。
There are different methods for computing paths for backup tunnels at a given PLR. Specifically, a user can statically configure one or more backup tunnels at the PLR with an explicitly configured path, or the PLR can be configured to automatically compute a backup path or to send a path computation request to a PCE (see [PCE-ARCH]).
所与PLRでバックアップトンネルのパスを計算するための異なる方法があります。具体的には、ユーザが静的に明示的に設定パスとPLRで1つまたは複数のバックアップトンネルを設定することができ、またはPLRは自動的にバックアップ経路を計算するために、またはPCEに経路計算リクエストを送信するように構成することができる（参照[PCE-ARCH] ）。
Consider the following scenario (Figure 1).
以下のシナリオ（図1）を考えます。
Assumptions:
仮定：
- A multi-area network made of three areas: 0, 1, and 2.
0、1、及び2： - マルチエリア・ネットワークは、三つの領域からなります。
- A fast reroutable TE LSP T1 (TE LSP signaled with the "Local Protection Desired" bit set in the SESSION-ATTRIBUTE object or the FAST-REROUTE object) from R0 to R3.
- 高速reroutable TE LSP T1 R3へR0から（TE LSPは、セッション属性オブジェクトまたは高速リルートオブジェクトに設定されたビットの「所望の局所保護」と合図しました）。
- A backup tunnel B1 from R1 to R2, not traversing ABR1, and following the R1-ABR3-R2 path.
- R1からR2にバックアップトンネルB1、ABR1を横断し、R1-ABR3-R2経路に従いません。
- The PLR R1 reroutes any protected TE LSP traversing ABR1 onto the backup tunnel B1 in case of ABR1's failure.
- PLR R1はABR1の故障の場合のバックアップトンネルB1にABR1を横切る任意の保護TE LSPを再ルーティング。
<--- area 1 --><---area 0---><---area 2--->
R0-----R1-ABR1--R2------ABR2--------R3
\ /
\ /
ABR3
Figure 1: Use of Fast Reroute to protect a TE LSP against an ABR failure with MPLS Traffic Engineering Fast Reroute
図1：高速リルートを使用すると、MPLSトラフィックエンジニアリング高速リルートとABRの故障に対してTE LSPを保護します
When T1 is first signaled, the PLR R1 needs to dynamically select an appropriate backup tunnel intersecting T1 on a downstream LSR. However, existing protocol mechanisms are not sufficient to unambiguously find the MP address in a network with inter-domain TE LSP. This document addresses these limitations.
T1が最初に通知された場合に、PLR R1を動的下流LSRに適切なバックアップトンネル交差T1を選択する必要があります。しかし、既存のプロトコルメカニズムは明確ドメイン間TE LSPを有するネットワークにおけるMPのアドレスを見つけることは十分ではありません。この文書では、これらの制限に対処しています。
R1 needs to select an existing backup tunnel with the following properties:
R1は、次のプロパティを持つ既存のバックアップトンネルを選択する必要があります。
1. The backup tunnel intersects with the primary tunnel at the MP. For the sake of illustration, in Figure 1, R1 needs to determine that T1 and B1 intersect at the node R2.
1.バックアップトンネルはMPでプライマリトンネルと交差します。説明の便宜上、図1において、R1は、T1及びB1は、ノードR2で交差することを決定する必要があります。
2. The backup tunnel satisfies the primary LSP's request with respect to the bandwidth protection request (i.e., bandwidth guaranteed for the primary tunnel during failure), and the type of protection (link or node failure), as specified in [FAST-REROUTE].
2.バックアップトンネルを満たす帯域幅保護要求に対する一次LSPの要求（すなわち、故障時のプライマリトンネルに保証帯域）、及び保護（リンクまたはノードの障害）のタイプ、で指定されるように[FAST-REROUTE] 。
One technique for the PLR to ensure that condition (1) is met consists of examining the Record Route Object (RRO) of the primary tunnel to see whether any of the addresses specified in the RRO correspond to the MP. That said, as per [RSVP-TE], the addresses specified in the RRO IPv4 or IPv6 sub-objects sent in Resv messages can be node-ids and/or interface addresses. Hence, in Figure 1, router R2 may specify interface addresses in the RROs for T1 and B1. Note that these interface addresses are different in this example.
PLRは、その条件（1）が満たされていることを確認するための一つの技術は、RROに指定されたアドレスのいずれかがMPに対応するかどうか確認するために、プライマリトンネルのレコードルートオブジェクト（RRO）を調べることから成ります。つまり、前記[RSVP-TE]に従って、RESVメッセージで送信されたRRO IPv4またはIPv6のサブオブジェクトで指定されたアドレスは、ノードIDおよび/またはインターフェイスアドレスであってもよいです。従って、図1において、ルータR2は、T1およびB1ためRROsにインターフェイスアドレスを指定してもよいです。これらのインターフェイスアドレスは、この例では異なっていることに注意してください。
The problem of finding the MP using the interface addresses or node-ids can be easily solved in the case of a single IGP area. Specifically, in the case of a single IGP area, the PLR has the knowledge of all the interfaces attached to the tail-end of the backup tunnel. This information is available in PLR's IGP topology database. Thus, the PLR can unambiguously determine whether a backup tunnel intersecting a protected TE LSP on a downstream node exists and can also find the MP address regardless of how the addresses carried in the RRO IPv4 or IPv6 sub-objects are specified (i.e., whether using the interface addresses or the node-ids). However, such routing information is not available in the case of inter-domain environments. Hence, unambiguously making sure that condition (1) above is met in the case of inter-domain TE LSPs is not possible with existing mechanisms.
インタフェースアドレスまたはノードIDを使用してMPを見つける問題は、容易に単IGP領域の場合に解決することができます。具体的には、単一のIGP領域の場合には、PLRは、バックアップトンネルのテール端部に取り付けられたすべてのインタフェースの知識を有しています。この情報は、PLRのIGPトポロジデータベースで利用可能です。したがって、PLRは明白下流ノードで保護TE LSPに交差するバックアップトンネルが存在するかどうかを判定することができるともかかわらず、RRO IPv4またはIPv6のサブオブジェクトで運ばれたアドレスを使用しているかどうか、すなわち、（指定されている方法のMPのアドレスを見つけることができインタフェースアドレスまたはノードIDS）。しかしながら、そのようなルーティング情報は、インタードメイン環境の場合に使用できません。したがって、明確に条件（1）上記ドメイン間TE LSPの場合に満たされることを確認すると、既存のメカニズムでは不可能です。
In this document, we define extensions to and describe the use of Resource Reservation Protocol (RSVP) [RSVP, RSVP-TE] to solve the above-mentioned problem. Note that the requirement for the support of the fast recovery technique specified in [FAST-REROUTE] to inter-domain TE LSPs has been specified in [INTER-AREA-TE-REQS] and [INTER-AS-TE-REQS].
この文書では、我々は、への拡張を定義し、上記課題を解決するためにリソース予約プロトコル（RSVP）[RSVP、RSVP-TE]の使用を記載しています。ドメイン間TEのLSPに[FAST-REROUTE]で指定された高速リカバリ技術をサポートするための要件は[INTER-AREA-TE-REQS]と[INTER-AS-TE-REQS]で指定されていることに注意してください。
Area Border Routers (ABRs): Border routers used to connect two Interior Gateway Protocol (IGP) areas (areas in OSPF or levels in IS-IS).
エリア境界ルータ（ABRに）：2 IGP領域（IS-ISでOSPFまたはレベルの領域）を接続するために使用されるボーダールーター。
Autonomous System Border Router (ASBRs): Border routers used to connect to another AS of a different or the same Service Provider via one or more links inter-connecting between ASes.
自律システム境界ルータ（ASBRは）：1つまたは複数のリンクのAS間の相互接続を経由して別の、または同じサービスプロバイダーのAS別に接続するために使用されるボーダールーター。
Backup Tunnel: The LSP that is used to back up one of the many LSPs in many-to-one backup.
バックアップトンネル：多対1のバックアップでは、多くのLSPの1をバックアップするために使用されるLSP。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
インターAS TE LSP：TE LSP AS境界を越えます。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
インターエリアTE LSP：TE LSP IGPエリアを横切ります。
LSR: Label Switching Router.
LSR：ラベルスイッチングルータ。
LSP: Label Switched Path.
LSP：ラベルスイッチパス。
Local Repair: Techniques used to repair TE LSPs quickly when a link, an SRLG, or a node along the TE LSP fails.
現地修理：TE LSPに沿ったリンク、SRLG、またはノードに障害が発生したときにすぐにTE LSPを修復するために使用される技術。
PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：パス計算要素。ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用することが可能なエンティティ（コンポーネント、アプリケーション、またはネットワークノード）。
MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure.
MP：ポイントをマージします。 1つまたは複数のバックアップトンネルが下流潜在的な障害の保護されたLSPの経路を再結合LSR。
Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop.
LSP保護：LSPは、それがそのホップに由来する一つまたは複数の関連付けられたバックアップトンネルを有する場合、所与のホップで保護されていると言われます。
PLR: Point of Local Repair. The head-end of a backup tunnel.
PLR：ローカル修理のポイント。バックアップトンネルのヘッドエンド。
Reroutable LSP: Any LSP for which the "Local Protection Desired" bit is set in the Flag field of the SESSION_ATTRIBUTE object of its Path messages.
Reroutable LSP：「ローカル保護所望の」ビットはそのPathメッセージのSESSION_ATTRIBUTEオブジェクトのフラグフィールドに設定されている任意のLSP。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：トラフィックエンジニアリングラベルスイッチパス。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
As mentioned above, the limitation that we need to address is the generality of the contents of the RRO IPv4 and IPv6 sub-objects, as defined in [RSVP-TE]. [RSVP-TE] defines the IPv4 and IPv6 RRO sub-objects. Moreover, two additional flags are defined in [FAST-REROUTE]: the "Local Protection Available" and "Local Protection in Use" bits.
上述したように、我々は対処する必要がある制限は、[RSVP-TE]で定義されるように、RRO IPv4とIPv6のサブオブジェクトの内容の一般性です。 [RSVP-TE]は、IPv4とIPv6のRROサブオブジェクトを定義します。さらに、2つの追加のフラグは[FAST-REROUTE]で定義される「利用可能なローカル保護」と「使用中ローカル保護」ビット。
In this document, we define the following new flag:
この文書では、以下の新しいフラグを定義します。
Node-id: 0x20
ノードID：0x20の
When set, this indicates that the address specified in the RRO's IPv4 or IPv6 sub-object is a node-id address, which refers to the "Router Address" as defined in [OSPF-TE], or "Traffic Engineering Router ID" as defined in [ISIS-TE]. A node MUST use the same address consistently. Once an address is used in the RRO's IPv4 or IPv6 sub-object, it SHOULD always be used for the lifetime of the TE LSP.
設定されている場合、これは、RROのIPv4またはIPv6のサブオブジェクトで指定されたアドレスとして[OSPF-TE]、または「トラフィックエンジニアリングルータID」で定義されるように「ルータアドレス」を指すノードIDアドレスであることを示しています[ISIS-TE]で定義されます。ノードは、一貫して同じアドレスを使用しなければなりません。アドレスがRROのIPv4またはIPv6のサブオブジェクトで使用されると、それは常にTE LSPの寿命のために使用されるべきです。
An IPv4 or IPv6 RRO sub-object with the node-id flag set is also called a node-id sub-object. The problem of finding an MP address in a network with inter-domain TE LSP is solved by inserting a node-id sub-object (an RRO "IPv4" and "IPv6" sub-object with the 0x20 flag set) in the RRO object carried in the RSVP Resv message.
ノードIDフラグが設定されたIPv4またはIPv6 RROサブオブジェクトは、ノードIDサブオブジェクトと呼ばれています。ドメイン間TE LSPを使用してネットワーク内のMPのアドレスを見つける問題は、RROオブジェクトにノードIDサブオブジェクト（RRO「のIPv4」と0x20のフラグが設定された「IPv6の」サブオブジェクト）を挿入することによって解決されますRSVP Resvメッセージで運ば。
An implementation may decide to either:
実装は、どちらかに決めることができます。
1) Add the node-id sub-object in the RRO carried in an RSVP Resv message and, when required, also add another IPv4/IPv6 sub-object to record interface address.
1）RSVP Resvメッセージで運ばRROにノードIDサブオブジェクトを追加し、必要な場合、また、記録インターフェイス・アドレスに別のIPv4 / IPv6のサブオブジェクトを追加します。
Example: an inter-domain fast reroutable TE LSP would have the following two sub-objects in the RRO carried in Resv message: a node-id sub-object and a label sub-object. If recording the interface address is required, then an additional IPv4/IPv6 sub-object is added.
例：ノードIDサブオブジェクトとラベルサブオブジェクト：ドメイン間高速reroutable TE LSPは、Resvメッセージで運ばRROの次の二つのサブオブジェクトを有することになります。インターフェイスアドレスを記録する必要がある場合、追加のIPv4 / IPv6のサブオブジェクトが追加されます。
or
または
2) Add an IPv4/IPv6 sub-object recording the interface address and, when required, add a node-id sub-object in the RRO.
2）インターフェイスアドレスを記録したIPv4 / IPv6のサブオブジェクトを追加し、必要な場合、RROにノードIDサブオブジェクトを追加します。
Example: an inter-domain fast reroutable TE LSP would have the following three sub-objects in the RRO carried in Resv message: an IPv4/IPv6 sub-object recording interface address, a label sub-object, and a node-id sub-object.
例：のIPv4 / IPv6のサブオブジェクト記録インタフェースアドレス、ラベルサブオブジェクト、およびノードIDのサブ：ドメイン間高速reroutable TE LSPは、Resvメッセージで運ばRROに以下の三つのサブオブジェクトを有することになりますオブジェクト。
Note also that the node-id sub-object may have other applications than Fast Reroute backup tunnel selection. Moreover, it is RECOMMENDED that an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also set the node-id flag.
ノードIDサブオブジェクトが高速リルートバックアップトンネルの選択以外の用途を有し得ることにも留意されたいです。また、のIPv4 / IPv6のRROサブオブジェクトでLSR記録ノードIDアドレスはまた、ノードIDフラグを設定することをお勧めします。
Two cases should be considered:
二つのケースを考慮する必要があります。
- Case 1: If the backup tunnel destination is the MP's node-id, then a PLR can find the MP and suitable backup tunnel by simply comparing the backup tunnel's destination address with the node-id included in the RRO of the primary tunnel.
- ケース1：バックアップトンネルの宛先がMPのノードIDである場合、PLRは、単にノードIDとバックアップトンネルの宛先アドレスを比較することにより、MP及び適切なバックアップトンネルを見つけることができるプライマリトンネルのRROに含まれます。
- Case 2: If the backup tunnel terminates at an address different from the MP's node-id, then a node-id sub-object MUST also be included in the RRO of the backup tunnel. A PLR can find the MP and suitable backup tunnel by simply comparing the node-ids present in the RROs of both the primary and backup tunnels.
- ケース2：バックアップトンネルは、MPのノードIDとは異なるアドレスで終了する場合、ノードIDサブオブジェクトは、バックアップトンネルのRROに含まれなければなりません。 PLRは単にプライマリとバックアップトンネルのRROsに存在するノードIDを比較することによって、MPと適切なバックアップトンネルを見つけることができます。
It must be noted that although the technique described in this document for selecting an appropriate backup tunnel using the node-id sub-object applies to the case of Inter-area and Inter-AS, in the case of Inter-AS, the assumption is made that the MP's node-id (of the downstream domain) does not overlap with any LSR's node-id present in the PLR's AS.
ノードIDサブオブジェクトを使用して、適切なバックアップトンネルを選択するために、この文書に記載された技術は、インター領域及びインターASの場合に適用されるが、インターASの場合、仮定があることに留意しなければなりません（下流のドメインの）MPのノードIDは、PLRのAS内の任意のLSRのノードIDが存在すると重なっていないと判断。
When both IPv4 node-id and IPv6 node-id sub-objects are present, a PLR may use any or both of them in finding the MP address.
IPv4ノード-IDとIPv6の両方のノードIDサブオブジェクトが存在する場合、PLRは、MPアドレスを見つけるためにそれらのいずれかまたは両方を使用することができます。
This document does not introduce new security issues. The security considerations pertaining to [RSVP] and [RSVP-TE] remain relevant.
この文書は、新しいセキュリティ問題を紹介しません。 [RSVP]と[RSVP-TE]に関連するセキュリティ上の考慮事項は、関連残ります。
We would like to acknowledge input and helpful comments from Carol Iturralde, Anca Zamfir, Reshad Rahman, Rob Goguen, and Philip Matthews. A special thanks to Adrian Farrel for his thorough review of this document.
我々はキャロルIturralde、ANCA Zamfir、Reshadラーマン、ロブGoguen、およびフィリップマシューズからの入力や有益なコメントを承認したいと思います。このドキュメントの彼の徹底的な見直しのためのエードリアンファレルに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RSVP-TE] 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.
[RSVP-TE] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：ExtensionsがLSPトンネルのためのRSVPする"、RFC 3209 、2001年12月。
[FAST-REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[FAST-REROUTE]パン、P.、ツバメ、G.、およびA.アトラス、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、RFC 4090、2005年5月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、RFC 3630、2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]スミット、H.、およびT.李、 "トラフィックエンジニアリングのための中間システム（ISIS）拡張機能（TE）への中間システム"、RFC 3784、2004年6月。
[INTER-AREA-TE-REQS] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[INTER-AREA-TE-REQS]ル・ルー、J.-L.、Vasseur、J.-P.、およびJ.ボイル、 "エリア間MPLSトラフィックエンジニアリングのための要件"、RFC 4105、2005年6月。
[INTER-AS-TE-REQS] Zhang, R. and J.-P. Vasseur, "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[INTER-AS-TE-REQS]張、R.及びJ.-P. Vasseur、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
[PCE-ARCH] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE) Based Architecture", Work in Progress, April 2006.
[PCE-ARCH]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、進歩、2006年4月に作業。
Authors' Addresses
著者のアドレス
J.-P. Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA
J.-P. Vasseur（編集）、シスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA - 01719 USA
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Zafar Ali Cisco Systems, Inc. 100 South Main St. #200 Ann Arbor, MI 48104 USA
Zafarアリシスコシステムズ社100南メインストリート＃200アナーバー、MI 48104 USA
EMail: zali@cisco.com
メールアドレス：zali@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
シヴァシババランシスコシステムズ株式会社2000年イノベーションドライブカナタ、オンタリオ、K2K 3E8カナダ
EMail: msiva@cisco.com
メールアドレス：msiva@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。