[要約] RFC 4561は、Record Route Object (RRO) Node-Id Sub-Objectの定義と目的を示しています。このサブオブジェクトは、パケットの経路情報を記録するために使用されます。
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
レコードルートオブジェクト（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).
Copyright（c）The Internet Society（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 Fast Rerouteのコンテキストでは、地元の修理ポイント（PLR）でマージポイント（MP）アドレスが必要です。ラベルスイッチングルーター（LSR）。ただし、既存のプロトコルメカニズムは、ドメインがインテリアゲートウェイプロトコル（IGP）領域または自律システム（AS）として定義されるマルチドメインルーティングネットワークでMPアドレスを見つけるのに十分ではありません。したがって、現在のMPLS高速リルートメカニズムは、ドメイン間のTE LSPをエリアボーダールーター（ABR）または自律システムボーダールーター（ASBR）の障害から保護するために使用することはできません。このドキュメントは、既存のレコードルートオブジェクト（RRO）IPv4とIPv6サブオブジェクト（新しいフラグを定義した）の使用を指定して、この問題を解決するためにノードIDサブオブジェクトを定義します。このドキュメントに記載されているMPLS高速リルートメカニズムは、「施設のバックアップ」MPLS TE Fast Rerouteメソッドを指します。
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 Fast Reroute（FRR）[Fast-Reroute]は、LINK/ノード/共有リスクリンクグループ（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は、link/node/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の3つの領域で構成されるマルチエリアネットワーク。
- 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.
- R0からR3までの高速再利用可能なTE LSP T1（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の障害が発生した場合に、ABR1をバックアップトンネルB1に移動する保護された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を保護するための高速再ルートの使用Fast Reroute
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つの手法（1）が満たされることを確認するための1つの手法は、RROで指定されたアドレスがMPに対応するかどうかを確認するために、一次トンネルのレコードルートオブジェクト（RRO）を調べることで構成されています。とはいえ、[RSVP-TE]に従って、RRO IPv4またはRESVメッセージで送信される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サブオブジェクトでのアドレスがどのように指定されているかに関係なく（つまり、使用するかどうか、インターフェイスアドレスまたはノードID）。ただし、ドメイン間環境の場合、そのようなルーティング情報は利用できません。したがって、既存のメカニズムでは、ドメイン間のTE LSPの場合に上記（1）が満たされていることを明確に確認することはできません。
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]の使用の拡張機能を定義し、説明します。[Fast-Reroute]で指定された高速回復手法のサポートの要件は、領域間TE LSPに指定されていることが、[エリア間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）エリア（OSPFのエリアまたはIS-ISのレベル）を接続するために使用される境界ルーター。
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.
自律システムボーダールーター（ASBRS）：ASE間の1つ以上のリンクを介して、別のリンクまたは同じサービスプロバイダーのように別のまたは同じサービスプロバイダーに接続するために使用されるボーダールーター。
Backup Tunnel: The LSP that is used to back up one of the many LSPs in many-to-one backup.
バックアップトンネル：多くのLSPの1つをバックアップしてバックアップするために使用されるLSP。
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-as te lsp：境界を横切るte lsp。
Inter-area TE LSP: A TE LSP that crosses an IGP area.
Inter-Areae LSP：IGP領域を横切るTE LSP。
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は、そのホップで1つまたは複数の関連するバックアップトンネルがある場合、特定のホップで保護されていると言われています。
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.
再ルート可能なLSP：「ローカル保護が希望する」ビットが、パスメッセージのセッション_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サブオブジェクトを定義します。さらに、[Fast-Reroute]で2つの追加フラグが定義されています。「ローカル保護が利用可能」と「使用中のローカル保護」ビットです。
In this document, we define the following new flag:
このドキュメントでは、次の新しいフラグを定義します。
Node-id: 0x20
node-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サブオブジェクトで指定されたアドレスがノード-IDアドレスであり、[OSPF-TE]で定義されている「ルーターアドレス」、または「トラフィックエンジニアリングルーター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.
Node-IDフラグセットを備えたIPv4またはIPv6 RROサブオブジェクトは、ノードIDサブオブジェクトとも呼ばれます。ドメイン間TE LSPを使用してネットワークでMPアドレスを見つける問題は、rroオブジェクトに0x20フラグセットを備えたrro "ipv4"および "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.
例：ドメイン間の高速再利用可能なTE LSPには、RSVメッセージに掲載されたRROに次の2つのサブオブジェクトがあります：ノードIDサブオブジェクトとラベルサブオブジェクト。インターフェイスアドレスを記録する必要がある場合、追加の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.
例：ドメイン間の高速再利用可能なTE LSPは、RROにrROに掲載された次の3つのサブオブジェクトをRESVメッセージに掲載します：IPv4/IPv6サブオブジェクト記録インターフェイスアドレス、ラベルサブオブジェクト、およびノードIDサブサブサブ - 物体。
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.
また、Node-IDサブオブジェクトには、高速再ルートバックアップトンネル選択以外のアプリケーションがある場合があることに注意してください。さらに、IPv4/IPv6 RROサブオブジェクトにノードIDアドレスを記録するLSRも、ノード-IDフラグを設定することをお勧めします。
Two cases should be considered:
2つのケースを考慮する必要があります。
- 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のNode-IDである場合、PLRは、バックアップトンネルの宛先アドレスをプライマリトンネルのRROに含まれるノードIDと比較するだけでMPと適切なバックアップトンネルを見つけることができます。
- 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.
Node-IDサブオブジェクトを使用して適切なバックアップトンネルを選択するためのこのドキュメントで説明されている手法は、インターエリアおよび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 node-idとipv6 node-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.
Carol Iturralde、Anca Zamfir、Reshad Rahman、Rob Goguen、およびPhilip Matthewsからの入力と有益なコメントを認めたいと思います。この文書を徹底的にレビューしてくれたAdrian Farrelに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：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] Pan、P.、Swallow、G。、およびA. Atlas、「LSP TunnelsのRSVP-TEへのFast Reroute Extensions」、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] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to 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] Smit、H。およびT. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（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.
[A-A-Area-Te-Reqs] Le Roux、J.-L.、Vasseur、J.-P。、およびJ. Boyle、「A-A-Area MPLS Traffic Engineeringの要件」、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] Zhang、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] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「Path Computation Element（PCE）ベースのアーキテクチャ」は、2006年4月に進行中の作業。
Authors' Addresses
著者のアドレス
J.-P. Vasseur (Editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough , MA - 01719 USA
J.-P.Vasseur（編集者）Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA -01719 USA
EMail: jpv@cisco.com
Zafar Ali Cisco Systems, Inc. 100 South Main St. #200 Ann Arbor, MI 48104 USA
Zafar Ali Cisco Systems、Inc。100 South Main St.＃200 Ann Arbor、MI 48104 USA
EMail: zali@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada
Siva Sivabalan Cisco Systems、Inc。2000イノベーションドライブカナタ、オンタリオ州、K2K 3E8カナダ
EMail: msiva@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。