Network Working Group M. Chen
Request for Comments: 5316 R. Zhang
Category: Standards Track Huawei Technologies Co., Ltd
X. Duan
China Mobile
December 2008
ISIS Extensions in Support of Inter-Autonomous System (AS)
MPLS and GMPLS Traffic Engineering
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) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
この文書では、マルチプロトコルラベルスイッチング（MPLS）と一般化MPLS複数の自律システム用（GMPLS）トラフィックエンジニアリング（TE）（のAS）をサポートするために、ISIS（ISIS）プロトコルの拡張機能について説明します。これは、相互AS TEの経路計算を実行するために使用することができAS間リンクに関するTE情報の氾濫のためにISIS-TE拡張を定義します。
No support for flooding information from within one AS to another AS is proposed or defined in this document.
別のASへのAS 1内から情報をあふれさせるためのサポートが提案していないか、またはこの文書で定義されています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Problem Statement ...............................................3
2.1. A Note on Non-Objectives ...................................4
2.2. Per-Domain Path Determination ..............................4
2.3. Backward Recursive Path Computation ........................6
3. Extensions to ISIS-TE ...........................................7
3.1. Inter-AS Reachability TLV ..................................7
3.2. TE Router ID ...............................................9
3.3. Sub-TLV Detail .............................................9
3.3.1. Remote AS Number Sub-TLV ............................9
3.3.2. IPv4 Remote ASBR ID Sub-TLV ........................10
3.3.3. IPv6 Remote ASBR ID Sub-TLV ........................11
3.3.4. IPv4 TE Router ID sub-TLV ..........................11
3.3.5. IPv6 TE Router ID sub-TLV ..........................12
4. Procedure for Inter-AS TE Links ................................12
4.1. Origin of Proxied TE Information ..........................14
5. Security Considerations ........................................14
6. IANA Considerations ............................................15
6.1. Inter-AS Reachability TLV .................................15
6.2. Sub-TLVs for the Inter-AS Reachability TLV ................15
6.3. Sub-TLVs for the IS-IS Router Capability TLV ..............17
7. Acknowledgments ................................................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................17
[ISIS-TE] defines extensions to the ISIS protocol [ISIS] to support intra-area Traffic Engineering (TE). The extensions provide a way of encoding the TE information for TE-enabled links within the network (TE links) and flooding this information within an area. The extended IS reachability TLV and traffic engineering router ID TLV, which are defined in [ISIS-TE], are used to carry such TE information. The extended IS reachability TLV has several nested sub-TLVs that describe the TE attributes for a TE link.
[ISIS-TE]はISISプロトコル[ISIS]エリア内のトラフィックエンジニアリング（TE）をサポートするために拡張機能を定義します。拡張子は、ネットワーク内のTE-有効なリンクのためのTE情報（TEリンク）をコードし、エリア内でこの情報をフラッディングする方法を提供します。 [ISIS-TE]で定義されているIS拡張到達可能性TLVとトラフィックエンジニアリングルータID TLVは、このようなTE情報を搬送するために使用されます。 IS延長到達可能性TLVは、TEはTEリンクの属性を記述し、いくつかのネストされたサブTLVを持っています。
[ISIS-TE-V3] and [GMPLS-TE] define similar extensions to ISIS [ISIS] in support of IPv6 and GMPLS traffic engineering, respectively.
[ISIS-TE-V3]と[GMPLS-TE]は、それぞれ、IPv6およびGMPLSトラフィックエンジニアリングをサポートするISIS [ISIS]と同様の拡張機能を定義します。
Requirements for establishing Multiprotocol Label Switching (MPLS) TE Label Switched Paths (LSPs) that cross multiple Autonomous Systems (ASes) are described in [INTER-AS-TE-REQ]. As described in [INTER-AS-TE-REQ], a method SHOULD provide the ability to compute a path spanning multiple ASes. So a path computation entity that may be the head-end Label Switching Router (LSR), an AS Border Router (ASBR), or a Path Computation Element (PCE [PCE]) needs to know the TE information not only of the links within an AS, but also of the links that connect to other ASes.
（MPLS）TEラベルをマルチプロトコルラベルスイッチングを確立するための要件は、複数の自律システム（のAS）は[INTER-AS-TE-REQ]に記載されているクロスパス（LSPを）スイッチ。 [INTER-AS-TE-REQ]で説明されるように、方法は、複数のASにまたがる経路を計算する能力を提供すべきです。だから、ヘッドエンドラベルスイッチングルータ（LSR）とすることができる経路計算エンティティは、AS境界ルータ（ASBR）、またはパス計算要素（PCE [PCE]は）内のリンクだけでなくTE情報を知る必要がありますASが、他のASに接続するリンクの。
In this document, a new TLV, which is referred to as the inter-AS reachability TLV, is defined to advertise inter-AS TE information, and three new sub-TLVs are defined for inclusion in the inter-AS reachability TLV to carry the information about the remote AS number and remote ASBR ID. The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents for inclusion in the extended IS reachability TLV for describing the TE properties of a TE link are applicable to be included in the inter-AS reachability TLV for describing the TE properties of an inter-AS TE link as well. Also, two more new sub-TLVs are defined for inclusion in the IS-IS router capability TLV to carry the TE Router ID when the TE Router ID needs to reach all routers within an entire ISIS routing domain. The extensions are equally applicable to IPv4 and IPv6 as identical extensions to [ISIS-TE] and [ISIS-TE-V3]. Detailed definitions and procedures are discussed in the following sections.
この文書では、AS間の到達可能性TLVと呼ばれる新しいTLVは、インターAS TEの情報をアドバタイズするように定義され、3新しいサブのTLVを運ぶためにAS間の到達可能性TLVに含めるために定義されています数およびリモートASBR ID ASリモートに関する情報。 [ISIS-TE]で定義されたサブTLVは、[ISIS-TE-V3]、および拡張に含めるために他の文書TEリンクのTEの特性を説明するためのTLVは、AS間に含まれることに適用可能である到達可能IS同様にインターAS TEリンクのTEの特性を説明するための到達可能性TLV。また、2つの新たなサブのTLVは、TEルータID全体ISISルーティングドメイン内のすべてのルータに到達する必要があるときTEルータIDを運ぶISISルータ能力TLVに含まれるように定義されています。拡張機能は[ISIS-TE]と[ISIS-TE-V3]と同一の拡張としてIPv4とIPv6にも同様に適用可能です。詳細な定義と手順は、次のセクションで説明されています。
This document does not propose or define any mechanisms to advertise any other extra-AS TE information within ISIS. See Section 2.1 for a full list of non-objectives for this work.
この文書では、提案やISIS内の他の余分な-AS TEの情報を宣伝するために、任意のメカニズムを定義していません。この作業のための非目標の完全なリストについては、2.1節を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC2119 [RFC2119]に記載されているように解釈されます。
As described in [INTER-AS-TE-REQ], in the case of establishing an inter-AS TE LSP that traverses multiple ASes, the Path message [RFC3209] may include the following elements in the Explicit Route Object (ERO) in order to describe the path of the LSP:
[INTER-AS-TE-REQ]で説明されるように、複数のASを横断する間AS TE LSPを確立する場合に、Pathメッセージ[RFC3209]は順に明示的経路オブジェクト（ERO）の次の要素を含んでもよいですLSPのパスを記述するために：
- a set of AS numbers as loose hops, and/or
- AS番号の集合としてゆるいホップ、および/または
- a set of LSRs including ASBRs as loose hops.
- ゆるいホップなどのASBRを含むのLSRのセット。
Two methods for determining inter-AS paths are currently being discussed. The per-domain method [PD-PATH] determines the path one domain at a time. The backward recursive method [BRPC] uses cooperation between PCEs to determine an optimum inter-domain path. The sections that follow examine how inter-AS TE link information could be useful in both cases.
AS間の経路を決定するための2つの方法は、現在議論されています。あたりドメイン法[PD-PATH]は一度にパスつのドメインを決定します。後方再帰法[BRPC]は、最適なドメイン間の経路を決定するためのPCE間の協力を使用します。次のセクションでは、AS間TEリンク情報は、どちらの場合に有用であり得るかを調べます。
It is important to note that this document does not make any change to the confidentiality and scaling assumptions surrounding the use of ASes in the Internet. In particular, this document is conformant to the requirements set out in [INTER-AS-TE-REQ].
このドキュメントは、インターネットでのASの使用を取り巻く機密性およびスケーリングの仮定に変更を行わないことに注意することが重要です。特に、このドキュメントは[INTER-AS-TE-REQ]に定める要件に準拠しています。
The following features are explicitly excluded:
次の機能は明示的に除外されています。
o There is no attempt to distribute TE information from within one AS to another AS.
O別のASにAS 1内から情報を配布する試みはありません。
o There is no mechanism proposed to distribute any form of TE reachability information for destinations outside the AS.
Oなどの外部宛先に到達可能性情報の任意の形態を分配するために提案されたメカニズムはありません。
o There is no proposed change to the PCE architecture or usage.
O PCEアーキテクチャや使用への変更案はありません。
o TE aggregation is not supported or recommended.
O TE集約はサポートまたは推奨されていません。
o There is no exchange of private information between ASes.
O AS間の個人情報の交換はありません。
o No ISIS adjacencies are formed on the inter-AS link.
OノーISIS隣接関係は、AS間リンクの上に形成されています。
In the per-domain method of determining an inter-AS path for an MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a Path message from an upstream AS with an ERO containing a next hop that is an AS number, it needs to find which LSRs (ASBRs) within the local AS are connected to the downstream AS. That way, it can compute a TE LSP segment across the local AS to one of those LSRs and forward the Path message to that LSR and hence into the next AS. See Figure 1 for an example.
LSRは、ASへのエントリ・ポイントは次のホップを含むEROと同様に上流側からPathメッセージを受信されたMPLS-TE LSPのためのAS間の経路を決定するごとドメイン方法、でAS番号は、AS下流に接続されているローカルAS内のどののLSR（のASBR）を見つける必要があります。そのように、それはそれらのLSRのようにローカル横切るTE LSPセグメントを計算し、そのLSRに、従って次ASにPathメッセージを転送することができます。例えば、図1を参照してください。
R1------R3----R5-----R7------R9-----R11
| | \ | / |
| | \ | ---- |
| | \ | / |
R2------R4----R6 --R8------R10----R12
: :
<-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 1: Inter-AS Reference Model
図1：インターAS参照モデル
The figure shows three ASes (AS1, AS2, and AS3) and twelve LSRs (R1 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are ASBRs in AS3.
図は、3つのAS（AS1、AS2およびAS3）及び12件のLSR（R12を介してR1）を示しています。 R3およびR4は、AS1内のASBRです。 R5、R6、R7、およびR8は、AS2でのASBRです。 R9及びR10は、AS3でのASBRです。
If an inter-AS TE LSP is planned to be established from R1 to R12, the AS sequence will be: AS1, AS2, AS3.
相互AS TE LSPがR1からR12に確立することが計画されている場合は、ASシーケンスは次のようになります。AS1、AS2、AS3。
Suppose that the Path message enters AS2 from R3. The next hop in the ERO shows AS3, and R5 must determine a path segment across AS2 to reach AS3. It has a choice of three exit points from AS2 (R6, R7, and R8), and it needs to know which of these provide TE connectivity to AS3, and whether the TE connectivity (for example, available bandwidth) is adequate for the requested LSP.
Pathメッセージは、R3からAS2に入ると仮定します。 EROの次のホップは、AS3を示し、R5は、AS3に到達するためにAS2を横切る経路セグメントを決定しなければなりません。これは、AS2（R6、R7、およびR8）から3出口点の選択肢を持っており、それがAS3にTEコネクティビティを提供し、これらのどれかを知る必要があり、かつTEコネクティビティ（例えば、利用可能な帯域幅）は、要求に適切であるかどうかLSP。
Alternatively, if the next hop in the ERO is the entry ASBR for AS3 (say R9), R5 needs to know which of its exit ASBRs has a TE link that connects to R9. Since there may be multiple ASBRs that are connected to R9 (both R7 and R8 in this example), R5 also needs to know the TE properties of the inter-AS TE links so that it can select the correct exit ASBR.
EROの次のホップがAS3（例えばR9）のエントリASBRである場合あるいは、R5はR9に接続TEリンクを有し、その出口のASBRのかを知る必要があります。 （この例では、両方のR7及びR8）R9に接続された複数のASBRが存在し得るので、正しい出口ASBRを選択できるように、R5はまた、インターAS TEリンクのTEの特性を知る必要があります。
Once the Path message reaches the exit ASBR, any choice of inter-AS TE link can be made by the ASBR if not already made by the entry ASBR that computed the segment.
Pathメッセージが出口ASBRに到達すると、既にセグメントを計算エントリーASBRによって作られていない場合は、インターAS TEリンクのいずれかの選択は、ASBRによって行うことができます。
More details can be found in Section 4 of [PD-PATH], which clearly points out why advertising of inter-AS links is desired.
詳細は、AS間リンクの広告を希望する理由を明確に指摘され、[PD-PATH]のセクション4で見つけることができます。
To enable R5 to make the correct choice of exit ASBR, the following information is needed:
終了ASBRの正しい選択をするためにR5を有効にするには、以下の情報が必要とされています。
o List of all inter-AS TE links for the local AS.
OローカルASのためのすべての間AS TEリンクの一覧。
o TE properties of each inter-AS TE link.
各AS間TEリンクのO TEプロパティ。
o AS number of the neighboring AS connected to by each inter-AS TE link.
各AS間のTEリンクによって隣接するように接続の数AS O。
o Identity (TE Router ID) of the neighboring ASBR connected to by each inter-AS TE link.
各AS間TEリンクによって接続された隣接ASBRのOアイデンティティ（TEルータID）。
In GMPLS networks, further information may also be required to select the correct TE links as defined in [GMPLS-TE].
GMPLSネットワークでは、更なる情報は、[GMPLS-TE]で定義されるように正しいTEリンクを選択するために必要とされ得ます。
The example above shows how this information is needed at the entry-point ASBRs for each AS (or the PCEs that provide computation services for the ASBRs). However, this information is also needed throughout the local AS if path computation functionality is fully distributed among LSRs in the local AS, for example to support LSPs that have start points (ingress nodes) within the AS.
上記の例では、この情報が各AS（またはのASBRの計算サービスを提供するのPCE）のためのエントリポイントのASBRで必要とされる様子を示しています。しかし、この情報は、経路計算の機能が完全にAS内の点（入力ノード）を起動有するLSPをサポートするために、例えば、ローカルAS内のLSR間で分散されているかのようにローカル全体に必要とされます。
Another scenario using PCE techniques has the same problem. [BRPC] defines a PCE-based TE LSP computation method (called Backward Recursive Path Computation) to compute optimal inter-domain constrained MPLS-TE or GMPLS LSPs. In this path computation method, a specific set of traversed domains (ASes) are assumed to be selected before computation starts. Each downstream PCE in domain(i) returns to its upstream neighbor PCE in domain(i-1) a multipoint-to-point tree of potential paths. Each tree consists of the set of paths from all boundary nodes located in domain(i) to the destination where each path satisfies the set of required constraints for the TE LSP (bandwidth, affinities, etc.).
PCEの技術を使用して、別のシナリオは、同じ問題を抱えています。 【BRPC】最適インタードメイン制約MPLS-TEやGMPLS LSPを計算する（後方再帰経路計算と呼ばれる）PCEベースのTE LSP計算方法を定義します。この経路計算方法では、横断ドメインの特定のセット（のAS）の計算が始まる前に選択されているものとします。ドメイン内の各下流PCE（i）は、ドメイン内のその上流隣接PCE（I-1）潜在的なパスのマルチポイント・ツー・ポイント・ツリーに戻ります。各ツリーは、各パスがTE LSPのために必要な制約条件（帯域幅、親和性、等）のセットを満たす目的地までの領域（I）に位置するすべての境界ノードからのパスのセットで構成されています。
So a PCE needs to select boundary nodes (that is, ASBRs) that provide connectivity from the upstream AS. In order for the tree of paths provided by one PCE to its neighbor to be correlated, the identities of the ASBRs for each path need to be referenced. Thus, the PCE must know the identities of the ASBRs in the remote AS that are reached by any inter-AS TE link, and, in order to provide only suitable paths in the tree, the PCE must know the TE properties of the inter-AS TE links. See the following figure as an example.
だから、PCEは、上流のASからの接続を提供する境界ノード（つまり、ASBRは）を選択する必要があります。相関させるために、その隣接1つのPCEによって提供される経路のツリーの順に、各パスのためのASBRの同一性は、参照する必要があります。したがって、PCEは、任意の相互AS TEリンクによって到達されたリモートAS内のASBRのアイデンティティを知っていなければならない、と、ツリー内でのみ、適切なパスを提供するために、PCEは、相互のTEの性質を知っている必要がありますAS TEリンク。例として、次の図を参照してください。
PCE1<------>PCE2<-------->PCE3
/ : :
/ : :
R1------R3----R5-----R7------R9-----R11
| | \ | / |
| | \ | ---- |
| | \ | / |
R2------R4----R6 --R8------R10----R12
: :
<-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 2: BRPC for Inter-AS Reference Model
図2：AS間のリファレンスモデルのBRPC
The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1, PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are ASBRs in AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS path computation and are responsible for path segment computation within their own domain(s).
図は、3つのAS（AS1、AS2およびAS3）三件のPCE（PCE1、PCE2、およびPCE3）、及び12件のLSR（R12を介してR1）を示しています。 R3およびR4は、AS1内のASBRです。 R5、R6、R7、およびR8は、AS2でのASBRです。 R9及びR10は、AS3でのASBRです。 PCE1、PCE2、およびPCE3は、インターASパス計算を実行するために協働し、独自のドメイン（単数または複数）内の経路セグメントの計算を担当しています。
If an inter-AS TE LSP is planned to be established from R1 to R12, the traversed domains are assumed to be selected: AS1->AS2->AS3, and the PCE chain is: PCE1->PCE2->PCE3. First, the path computation request originated from the PCC (R1) is relayed by PCE1 and PCE2 along the PCE chain to PCE3. Then, PCE3 begins to compute the path segments from the entry boundary nodes that provide connection from AS2 to the destination (R12). But, to provide suitable path segments, PCE3 must determine which entry boundary nodes provide connectivity to its upstream neighbor AS (identified by its AS number), and must know the TE properties of the inter-AS TE links. In the same way, PCE2 also needs to determine the entry boundary nodes according to its upstream neighbor AS and the inter-AS TE link capabilities.
AS1-> AS2-> AS3、およびPCE鎖である：インターAS TE LSPは、R1からR12まで確立される予定である場合、横断ドメインが選択されているものとするPCE1-> PCE2-> PCE3。まず、計算要求は、PCC（R1）に由来する経路がPCE3にPCE鎖に沿っPCE1およびPCE2によって中継されます。次いで、PCE3は、宛先（R12）にAS2から接続を提供する入口境界ノードからのパスセグメントを計算し始めます。しかし、適切な経路セグメントを提供するために、PCE3はAS（そのAS番号によって識別される）その上流隣接への接続を提供するエントリー境界ノードを決定しなければならない、と相互AS TEリンクのTEの特性を知っていなければなりません。同様に、PCE2はまた、AS上流の隣人と相互AS TEリンクの能力に応じてエントリー境界ノードを決定する必要があります。
Thus, to support Backward Recursive Path Computation, the same information listed in Section 2.2 is required. The AS number of the neighboring AS connected to by each inter-AS TE link is particularly important.
このように、後方再帰経路計算をサポートするために、セクション2.2に記載されている同一の情報が必要です。各AS間のTEリンクによって隣接するように接続のAS番号が特に重要です。
Note that this document does not define mechanisms for distribution of TE information from one AS to another, does not distribute any form of TE reachability information for destinations outside the AS, does not change the PCE architecture or usage, does not suggest or recommend any form of TE aggregation, and does not feed private information between ASes. See Section 2.1.
この文書は別のAS 1からTE情報の配信のためのメカニズムを定義していないことに注意してください、AS外の宛先のためのTE到達可能性情報の任意のフォームを配布していない、PCEアーキテクチャや使用法を変更しない、任意の形式を提案したりすることはお勧めしません。 TE凝集の、およびAS間のプライベートな情報を供給していません。 2.1節を参照してください。
In this document, for the advertisement of inter-AS TE links, a new TLV, which is referred to as the inter-AS reachability TLV, is defined. Three new sub-TLVs are also defined for inclusion in the inter-AS reachability TLV to carry the information about the neighboring AS number and the remote ASBR ID of an inter-AS link. The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents for inclusion in the extended IS reachability TLV are applicable to be included in the inter-AS reachability TLV for inter-AS TE links advertisement. Also, two other new sub-TLVs are defined for inclusion in the IS-IS router capability TLV to carry the TE Router ID when the TE Router ID is needed to reach all routers within an entire ISIS routing domain.
この文書では、相互AS TEリンクの広告のために、AS間の到達可能性TLVと呼ばれる新しいTLVは、定義されます。三個の新たなサブのTLVはまた、番号AS隣接およびAS間リンクのリモートASBR IDに関する情報を搬送するためにAS間の到達可能性TLVに含まれるように定義されています。拡張に含めるために[ISIS-TE]、[ISIS-TE-V3]、および他の文書で定義されたサブのTLVは、到達可能性TLVは、AS間TEが広告をリンクするためのインターAS到達可能性TLVに含まれることに適用可能であるIS 。また、他の二つの新たなサブのTLVは、TEルータIDを全体ISISルーティングドメイン内のすべてのルータに到達するために必要とされる場合TEルータIDを運ぶためにISISルータ能力TLVに含まれるように定義されています。
While some of the TE information of an inter-AS TE link may be available within the AS from other protocols, in order to avoid any dependency on where such protocols are processed, this mechanism carries all the information needed for the required TE operations.
インターAS TEリンクのTE情報の一部は、他のプロトコルからのAS内で使用可能であってもよいが、そのようなプロトコルが処理される場合にどのような依存性を回避するために、この機構は、必要なTE動作のために必要なすべての情報を運びます。
The inter-AS reachability TLV has type 141 (see Section 6.1) and contains a data structure consisting of:
AS間の到達可能性TLV 141型を持つ（6.1節参照）とからなるデータ構造を含みます。
o 4 octets of Router ID o 3 octets of default metric o 1 octet of control information, consisting of: - 1 bit of flooding-scope information (S bit) - 1 bit of up/down information (D bit) - 6 bits reserved o 1 octet of length of sub-TLVs o 0-246 octets of sub-TLVs, where each sub-TLV consists of a sequence of: - 1 octet of sub-type - 1 octet of length of the value field of the sub-TLV - 0-244 octets of value
なる制御情報の1つのオクテットOメトリックデフォルトの3つのオクテットOルータIDのO 4つのオクテット： - アップ/ダウン情報（Dビット）の1ビット - - フラッディングスコープ情報（Sビット）の1ビットの6ビットはリザーブO各サブTLVは、の配列からなるサブTLVは、0から246までのオクテットOサブのTLVの長さの1つのオクテット： - サブタイプの1つのオクテット - サブの値フィールドの長さの1つのオクテットTLV - 値の0から244個のオクテット
Compared to the extended reachability TLV, which is defined in [ISIS-TE], the inter-AS reachability TLV replaces the "7 octets of System ID and Pseudonode Number" field with a "4 octets of Router ID" field and introduces an extra "control information" field, which consists of a flooding-scope bit (S bit), an up/down bit (D bit), and 6 reserved bits.
[ISIS-TE]で定義されている拡張到達性TLV、AS間の到達可能性に比べTLVは「ルータIDの4つのオクテット」フィールドと「システムIDの7つのオクテットと擬似ノード番号」フィールドを置換し、余分を紹介しますフラッディングスコープビット（Sビット）、アップ/ダウンビット（Dビット）、及び6つの予約ビットから成るフィールド、「制御情報」。
The Router ID field of the inter-AS reachability TLV is 4 octets in length, which contains the Router ID of the router who generates the inter-AS reachability TLV. The Router ID MUST be unique within the ISIS area. If the router generates inter-AS reachability TLV with entire ISIS routing domain flooding scope, then the Router ID MUST also be unique within the entire ISIS routing domain. The Router ID could be used to indicate the source of the inter-AS reachability TLV.
AS間の到達可能性TLVのルータIDフィールドは、AS間の到達可能性TLVを生成ルータのルータIDを含んでいる長さが4つのオクテットです。ルータIDは、ISISエリア内で一意でなければなりません。ルータが全体ISISルーティングドメインの氾濫範囲とAS間の到達可能性TLVを生成した場合、ルータIDはまた、全体ISISルーティングドメイン内で一意でなければなりません。ルータIDは、AS間の到達可能性TLVのソースを示すために使用することができます。
The flooding procedures for inter-AS reachability TLV are identical to the flooding procedures for the GENINFO TLV, which are defined in Section 4 of [GENINFO]. These procedures have been previously discussed in [ISIS-CAP]. The flooding-scope bit (S bit) SHOULD be set to 0 if the flooding scope is to be limited to within the single IGP area to which the ASBR belongs. It MAY be set to 1 if the information is intended to reach all routers (including area border routers, ASBRs, and PCEs) in the entire ISIS routing domain. The choice between the use of 0 or 1 is an AS-wide policy choice, and configuration control SHOULD be provided in ASBR implementations that support the advertisement of inter-AS TE links.
AS間の到達可能性TLVのためのフラッディング手順は、[GENINFO]のセクション4で定義されているGENINFO TLVのためのフラッディング手順と同一です。これらの手順は、以前に[ISIS-CAP]で議論されてきました。氾濫範囲はASBRが属する単一のIGP領域内に限定されるべきである場合、フラッディングスコープビット（Sビット）が0に設定されるべきです。情報全体ISISルーティングドメイン内（境界ルータ、ASBRは、とのPCEを含む）すべてのルータに到達するために意図されている場合、それは1に設定されるかもしれません。 0または1の使用の間の選択は、AS全体のポリシーの選択であり、構成制御は、AS間TEリンクの広告をサポートするASBR実装で提供されるべきです。
The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents for describing the TE properties of a TE link are also applicable to the inter-AS reachability TLV for describing the TE properties of an inter-AS TE link. Apart from these sub-TLVs, three new sub-TLVs are defined for inclusion in the inter-AS reachability TLV defined in this document:
[ISIS-TE]、[ISIS-TE-V3]、およびTEリンクのTEの特性を説明するための他のドキュメントで定義されたサブのTLVは、インターのTEの特性を説明するためのAS間の到達可能性TLVにも適用可能です-AS TEリンク。別にこれらのサブのTLVから、3の新しいサブTLVのは、このドキュメントで定義されたAS間の到達可能性TLVでの包含のために定義されています。
Sub-TLV type Length Name
------------ ------ ---------------------------
24 4 remote AS number
25 4 IPv4 remote ASBR identifier
26 16 IPv6 remote ASBR identifier
The detailed definitions of the three new sub-TLVs are described in Section 3.3.
つの新しいサブのTLVの詳細な定義は、セクション3.3に記載されています。
The IPv4 TE Router ID TLV and IPv6 TE Router ID TLV, which are defined in [ISIS-TE] and [ISIS-TE-V3] respectively, only have area flooding-scope. When performing inter-AS TE, the TE Router ID MAY be needed to reach all routers within an entire ISIS routing domain and it MUST have the same flooding scope as the inter-AS reachability TLV does.
IPv4のTEそれぞれのルータID TLV及び[ISIS-TE]で定義されたIPv6 TEルータID TLV、及び[ISIS-TE-V3]は、領域のみフラッディングスコープを持っています。相互AS TEを行う際には、TEルータIDは、全体のIS-ISルーティングドメイン内のすべてのルータに到達するために必要な場合があり、それが相互AS到達可能性TLVがないのと同じ氾濫範囲を持っていなければなりません。
[ISIS-CAP] defines a generic advertisement mechanism for ISIS, which allows a router to advertise its capabilities within an ISIS area or an entire ISIS routing domain. [ISIS-CAP] also points out that the TE Router ID is a candidate to be carried in the IS-IS router capability TLV when performing inter-area TE.
[ISIS-CAP]は、ルータは、ISISエリア全体ISISルーティングドメイン内でその機能をアドバタイズすることを可能にするISISための一般的な広告の機構を定義します。 [ISIS-CAP]はまた、TEルータIDは、エリア間TEを行う場合ISISルータ能力TLVで搬送される候補であることを指摘しています。
This document uses such mechanism for TE Router ID advertisement when the TE Router ID is needed to reach all routers within an entire ISIS Routing domain. Two new sub-TLVs are defined for inclusion in the IS-IS router capability TLV to carry the IPv4 and IPv6 TE Router IDs, respectively:
TEルータIDが全体ISISルーティングドメイン内のすべてのルータに到達するために必要とされるときに、この文書では、TEルータIDの広告のために、このようなメカニズムを使用しています。二つの新しいサブTLVのは、それぞれ、IPv4とIPv6のTEルータIDを運ぶためにIS-ISルータ機能TLVに含めるために定義されています。
Sub-TLV type Length Name
------------ ------ -----------------
11 4 IPv4 TE Router ID
12 16 IPv6 TE Router ID
Detailed definitions of the two new sub-TLVs are described in Section 3.3.
二つの新しいサブのTLVの詳細な定義は、セクション3.3に記載されています。
A new sub-TLV, the remote AS number sub-TLV, is defined for inclusion in the inter-AS reachability TLV when advertising inter-AS links. The remote AS number sub-TLV specifies the AS number of the neighboring AS to which the advertised link connects.
AS間のリンクをアドバタイズするときに新しいサブTLV、数サブTLV ASリモートは、AS間の到達可能性TLVでの包含のために定義されています。数のサブTLV ASリモートはにアドバタイズリンクが接続AS隣接のAS番号を指定します。
The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and is 4 octets in length. The format is as follows:
番号サブTLV ASリモートはTLVタイプ24（セクション6.2を参照）であり、長さが4つのオクテットです。形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote AS number field has 4 octets. When only 2 octets are used for the AS number, as in current deployments, the left (high-order) 2 octets MUST be set to 0. The remote AS number sub-TLV MUST be included when a router advertises an inter-AS TE link.
リモートAS番号フィールドは4つのオクテットを持っています。唯一の2オクテットをAS番号を使用する場合、ルータがインターAS TEをアドバタイズするとき番号サブTLVが含まれなければならないので、現在の配備のように、左（上位）は、2つのオクテットは0リモートに設定しなければなりませんリンク。
A new sub-TLV, which is referred to as the IPv4 remote ASBR ID sub-TLV, is defined for inclusion in the inter-AS reachability TLV when advertising inter-AS links. The IPv4 remote ASBR ID sub-TLV specifies the IPv4 identifier of the remote ASBR to which the advertised inter-AS link connects. This could be any stable and routable IPv4 address of the remote ASBR. Use of the TE Router ID as specified in the Traffic Engineering router ID TLV [ISIS-TE] is RECOMMENDED.
AS間のリンクをアドバタイズするときIPv4のリモートASBRのIDサブTLVと呼ばれる新しいサブTLVは、AS間の到達可能性TLVに含まれるように定義されています。 IPv4のリモートASBRのIDサブTLVは、アドバタイズされたAS間のリンクが接続するリモートASBRのIPv4の識別子を指定します。これは、リモートASBRの任意の安定とルーティング可能なIPv4アドレスである可能性があります。トラフィックエンジニアリングルータID TLV [ISIS-TE]に指定されているTEルータIDの使用を推奨します。
The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) and is 4 octets in length. The format of the IPv4 remote ASBR ID sub-TLV is as follows:
IPv4のリモートASBRのIDサブTLVは、TLVタイプ25（セクション6.2を参照）であり、長さが4つのオクテットです。次のようにIPv4のリモートASBRのIDサブTLVのフォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv4 remote ASBR ID sub-TLV MUST be included if the neighboring ASBR has an IPv4 address. If the neighboring ASBR does not have an IPv4 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID sub-TLV MUST be included instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID sub-TLV MAY both be present in an extended IS reachability TLV.
隣接ASBRは、IPv4アドレスを持つ場合のIPv4リモートASBRのIDサブTLVは含まなければなりません。隣接ASBRは、IPv4アドレス（いないIPv4のTEルータID）を持っていない場合は、IPv6のリモートASBRのIDサブTLVは、代わりに含まなければなりません。 IPv4のリモートASBRのIDサブTLVとIPv6リモートASBRのIDサブTLVの両方がされた延長到達可能性TLVに存在してもよいです。
A new sub-TLV, which is referred to as the IPv6 remote ASBR ID sub-TLV, is defined for inclusion in the inter-AS reachability TLV when advertising inter-AS links. The IPv6 remote ASBR ID sub-TLV specifies the IPv6 identifier of the remote ASBR to which the advertised inter-AS link connects. This could be any stable and routable IPv6 address of the remote ASBR. Use of the TE Router ID as specified in the IPv6 Traffic Engineering router ID TLV [ISIS-TE-V3] is RECOMMENDED.
AS間のリンクをアドバタイズするときのIPv6リモートASBRのIDサブTLVと呼ばれる新しいサブTLVは、AS間の到達可能性TLVに含まれるように定義されています。 IPv6のリモートASBRのIDサブTLVは、アドバタイズされたAS間のリンクが接続するリモートASBRのIPv6の識別子を指定します。これは、リモートASBRの任意の安定とルーティング可能なIPv6アドレスである可能性があります。 IPv6のトラフィックエンジニアリングルータID TLV [ISIS-TE-V3]に指定されているTEルータIDの使用を推奨します。
The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) and is 16 octets in length. The format of the IPv6 remote ASBR ID sub-TLV is as follows:
IPv6のリモートASBRのIDサブTLVは、TLVタイプ26（セクション6.2を参照）であり、長さは16オクテットです。次のようにIPv6のリモートASBRのIDサブTLVのフォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 remote ASBR ID sub-TLV MUST be included if the neighboring ASBR has an IPv6 address. If the neighboring ASBR does not have an IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be included instead. An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID sub-TLV MAY both be present in an extended IS reachability TLV.
隣接ASBRがIPv6アドレスを持っている場合のIPv6リモートASBRのIDサブTLVは含まなければなりません。隣接ASBRは、IPv6アドレスを持っていない場合、IPv4のリモートASBRのIDサブTLVは、代わりに含まなければなりません。 IPv4のリモートASBRのIDサブTLVとIPv6リモートASBRのIDサブTLVの両方がされた延長到達可能性TLVに存在してもよいです。
The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) and is 4 octets in length. The format of the IPv4 TE Router ID sub-TLV is as follows:
IPv4のTEルータIDサブTLVは、TLVタイプ11（セクション6.3を参照）であり、長さが4つのオクテットです。次のようにIPv4のTEルータIDサブTLVのフォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the TE Router ID is needed to reach all routers within an entire ISIS routing domain, the IS-IS Router capability TLV MUST be included in its LSP. If an ASBR supports Traffic Engineering for IPv4 and if the ASBR has an IPv4 TE Router ID, the IPv4 TE Router ID sub-TLV MUST be included. If the ASBR does not have an IPv4 TE Router ID, the IPv6 TE Router sub-TLV MUST be included instead. An IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an IS-IS router capability TLV.
TEルータIDが全体のIS-ISルーティングドメイン内のすべてのルータに到達するために必要とされる場合は、ISISルータ機能TLVは、そのLSPに含まれなければなりません。 ASBRは、IPv4のトラフィックエンジニアリングをサポートしている場合ASBRがIPv4 TEルータIDを持っている場合、IPv4のTEルータIDサブTLVを含まなければなりません。 ASBRは、IPv4 TEルータIDを持っていない場合、IPv6のTEルータサブTLVは、代わりに含まなければなりません。 IPv4のTEルータIDサブTLVとIPv6 TEルータIDサブTLVの両方がIS-ISルータ能力TLVに存在してもよいです。
The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is 4 octets in length. The format of the IPv6 TE Router ID sub-TLV is as follows:
IPv6のTEルータIDサブTLVは、TLVタイプ12（セクション6.3を参照）であり、長さが4つのオクテットです。次のようにIPv6のTEルータIDサブTLVのフォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Router ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the TE Router ID is needed to reach all routers within an entire ISIS routing domain, the IS-IS router capability TLV MUST be included in its LSP. If an ASBR supports Traffic Engineering for IPv6 and if the ASBR has an IPv6 TE Router ID, the IPv6 TE Router ID sub-TLV MUST be included. If the ASBR does not have an IPv6 TE Router ID, the IPv4 TE Router sub-TLV MUST be included instead. An IPv4 TE Router ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an IS-IS router capability TLV.
TEルータIDが全体のIS-ISルーティングドメイン内のすべてのルータに到達するために必要とされる場合は、ISISルータ機能TLVは、そのLSPに含まれなければなりません。 ASBRは、IPv6のトラフィックエンジニアリングをサポートしている場合ASBRがIPv6 TEルータIDを持っている場合、IPv6のTEルータIDサブTLVを含まなければなりません。 ASBRは、IPv6 TEルータIDを持っていない場合、IPv4のTEルータサブTLVは、代わりに含まなければなりません。 IPv4のTEルータIDサブTLVとIPv6 TEルータIDサブTLVの両方がIS-ISルータ能力TLVに存在してもよいです。
When TE is enabled on an inter-AS link and the link is up, the ASBR SHOULD advertise this link using the normal procedures for ISIS-TE [ISIS-TE]. When either the link is down or TE is disabled on the link, the ASBR SHOULD withdraw the advertisement. When there are changes to the TE parameters for the link (for example, when the available bandwidth changes), the ASBR SHOULD re-advertise the link but MUST take precautions against excessive re-advertisements.
ときTEは、AS間リンク上で有効になっていると、リンクがアップして、ASBRは、ISIS-TE [ISIS-TE]のための通常の手順を使用して、このリンクを宣伝すべきです。リンクのいずれかがダウンしているか、TEは、リンク上で無効になっている場合は、ASBRは、広告を撤回すべきです。 （例えば、ときに利用可能な帯域幅の変更）リンクのTEパラメータへの変更がある場合は、ASBRは再宣伝リンクべきであるが、過度の再広告に対する予防措置を講じなければなりません。
Hellos MUST NOT be exchanged over the inter-AS link, and consequently, an ISIS adjacency MUST NOT be formed.
ハローズは、AS間リンク上で交換されてはならない、その結果、ISIS隣接が形成されてはなりません。
The information advertised comes from the ASBR's knowledge of the TE capabilities of the link, the ASBR's knowledge of the current status and usage of the link, and configuration at the ASBR of the remote AS number and remote ASBR TE Router ID.
宣伝情報は、リンクのTE能力のASBRの知識、リンクの現在の状態と使用状況のASBRの知識、および数およびリモートASBR TEルータID ASリモートのASBRの設定から来ています。
Legacy routers receiving an advertisement for an inter-AS TE link are able to ignore it because they do not know the new TLV and sub-TLVs that are defined in Section 3 of this document. They will continue to flood the LSP, but will not attempt to use the information received.
インターAS TEリンクの広告を受信レガシールータは、彼らがこのドキュメントのセクション3で定義されている新しいTLVとサブTLVを知らないので、それを無視することができます。彼らは、LSPをあふれさせる続けますが、受信した情報を使用しようとしません。
In the current operation of ISIS TE, the LSRs at each end of a TE link emit LSAs describing the link. The databases in the LSRs then have two entries (one locally generated, the other from the peer) that describe the different 'directions' of the link. This enables Constrained Shortest Path First (CSPF) to do a two-way check on the link when performing path computation and eliminate it from consideration unless both directions of the link satisfy the required constraints.
ISIS TEの現在の操作で、TEリンクの各端部のLSRはリンクを説明LSAを発します。 LSR内のデータベースは、リンクの異なる「方向」を記述する（ピアから他のローカルに生成一つ）の2つのエントリを有しています。これは、経路計算を実行するときに、リンク上で双方向のチェックを行い、リンクの両方向が必要な制約を満たしていない限り配慮からそれを排除するために制約付き最短パスファースト（CSPF）を有効にします。
In the case we are considering here (i.e., of a TE link to another AS), there is, by definition, no IGP peering and hence no bidirectional TE link information. In order for the CSPF route computation entity to include the link as a candidate path, we have to find a way to get LSAs describing its (bidirectional) TE properties into the TE database.
（すなわち、別のASへTEリンクの）我々はここで検討している場合には、定義により、まったくIGPピアリングひいてはない双方向TEリンク情報は存在しません。候補パスとしてリンクを含むようにCSPF経路計算エンティティのために、我々は、TEデータベースにその（双方向）TEの特性を記述するLSAを取得する方法を見つけなければなりません。
This is achieved by the ASBR advertising, internally to its AS, information about both directions of the TE link to the next AS. The ASBR will normally generate an LSA describing its own side of a link; here we have it 'proxy' for the ASBR at the edge of the other AS and generate an additional LSA that describes that device's 'view' of the link.
これは、内部的にそのAS、次のASへのTEリンクの両方の方向についての情報を、ASBR広告によって達成されます。 ASBRは、通常リンクの独自の側面を説明するLSAを生成します。ここでは、他のASのエッジにASBRのための「プロキシ」、それを持っていると、リンクのそのデバイスの「ビュー」を記述する追加のLSAを生成します。
Only some essential TE information for the link needs to be advertised; i.e., the Interface Address, the remote AS number, and the remote ASBR ID of an inter-AS TE link.
リンクだけのためのいくつかの重要なTE情報を公示する必要があります。即ち、インターフェイスアドレス、番号、およびインターAS TEリンクのリモートASBR IDとして遠隔。
Routers or PCEs that are capable of processing advertisements of inter-AS TE links SHOULD NOT use such links to compute paths that exit an AS to a remote ASBR and then immediately re-enter the AS through another TE link. Such paths would constitute extremely rare occurrences and SHOULD NOT be allowed except as the result of specific policy configurations at the router or PCE computing the path.
インターAS TEリンクがリモートASBRする終了した後、すぐに別のTEリンクを介してASを再入力経路を計算するためにそのようなリンクを使用しませんの広告を処理することができるルータ又はのPCE。そのような経路は非常にまれ発生を構成するであろうし、経路を計算するルータまたはPCEで特定のポリシー設定の結果として以外は許されるべきではありません。
Section 4 describes how an ASBR advertises TE link information as a proxy for its neighbor ASBR, but does not describe where this information comes from.
第4節では、ASBRは、その隣接ASBRのプロキシとしてTEリンク情報を広告するが、この情報はどこから来るのか説明していない方法を説明します。
Although the source of this information is outside the scope of this document, it is possible that it will be a configuration requirement at the ASBR, as are other local properties of the TE link. Further, where BGP is used to exchange IP routing information between the ASBRs, a certain amount of additional local configuration about the link and the remote ASBR is likely to be available.
この情報のソースはこの文書の範囲外であるが、TEリンクの他の局所的な性質であるとして、それは、ASBRで構成要件となることが可能です。さらに、BGPは、ASBR間IPルーティング情報を交換するために使用される場合、リンクおよびリモートASBR約追加のローカルコンフィギュレーションの特定の量は、利用可能である可能性が高いです。
We note further that it is possible, and may be operationally advantageous, to obtain some of the required configuration information from BGP. Whether and how to utilize these possibilities is an implementation matter.
我々はそれが可能であり、BGPから必要な設定情報の一部を取得するために、操作上有利であり得ることにさらに留意されたいです。そしてどのようにこれらの可能性を利用するかどうかは、実装上の問題です。
The protocol extensions defined in this document are relatively minor and can be secured within the AS in which they are used by the existing ISIS security mechanisms (e.g., using the cleartext passwords or Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm, which are defined in [ISIS] and [RFC5304], respectively).
この文書で定義されたプロトコルの拡張は比較的軽微であり、彼らは平文パスワードやハッシュメッセージ認証コードを使用して、既存のISISのセキュリティメカニズム（例えば、で使用されているAS内に固定することができます - メッセージダイジェスト5（HMAC-MD5）アルゴリズムそれぞれ[ISIS]と[RFC5304]）で定義されています。
There is no exchange of information between ASes, and no change to the ISIS security relationship between the ASes. In particular, since no ISIS adjacency is formed on the inter-AS links, there is no requirement for ISIS security between the ASes.
AS間の情報の交換なし、とAS間ISISのセキュリティ関係に変更はありません。何ISIS隣接のAS間リンクの上に形成されていないので、特に、AS間ISISセキュリティの必要はありません。
Some of the information included in these new advertisements (e.g., the remote AS number and the remote ASBR ID) is obtained manually from a neighboring administration as part of a commercial relationship. The source and content of this information should be carefully checked before it is entered as configuration information at the ASBR responsible for advertising the inter-AS TE links.
これらの新しい広告（例えば、数およびリモートASBR IDとリモート）に含まれる情報の一部は、商業関係の一部として近隣投与から手動で得られます。それは相互AS TEリンクを広告するための責任ASBRで設定情報として入力される前に、この情報のソースと内容を慎重にチェックする必要があります。
It is worth noting that in the scenario we are considering, a Border Gateway Protocol (BGP) peering may exist between the two ASBRs and that this could be used to detect inconsistencies in configuration (e.g., the administration that originally supplied the information may be lying, or some manual mis-configurations or mistakes may be made by the operators). For example, if a different remote AS number is received in a BGP OPEN [BGP] from that locally configured to ISIS-TE, as we describe here, then local policy SHOULD be applied to determine whether to alert the operator to a potential mis- configuration or to suppress the ISIS advertisement of the inter-AS TE link. Note further that if BGP is used to exchange TE information as described in Section 4.1, the inter-AS BGP session SHOULD be secured using mechanisms as described in [BGP] to provide authentication and integrity checks.
それを（我々が検討しているシナリオ、ボーダーゲートウェイプロトコル（BGP）で2つのASBR間に存在し、これは設定の不整合を検出するために使用することができることもピアリングことは注目に値する例えば、元々の情報を提供政権が横たわっていることがあり、またはいくつかの手動誤構成またはミス）がオペレータによってなされてもよいです。例えば、数AS異なる遠隔がで受信された場合、BGP OPEN [BGP]そのローカル我々はここで説明するように、ローカルポリシーは、潜在的な誤にオペレータに警告するかどうかを決定するために適用されるべきである、ISIS-TEに構成からインターAS TEリンクのISIS広告を抑制するための構成や。さらにBGPは、セクション4.1で説明したようにTEの情報を交換するために使用される場合、認証及び完全性チェックを提供するために、[BGP]に記載されているように、インターAS BGPセッションがメカニズムを使用して保護されるべきであることに注意してください。
For a discussion of general security considerations for IS-IS, see [RFC5304].
IS-ISのための一般的なセキュリティ上の考慮事項の議論に関しては、[RFC5304]を参照してください。
IANA has made the following allocations from registries under its control.
IANAは、その管理下にレジストリから以下の配分を行っています。
This document defines the following new ISIS TLV type, described in Section 3.1, which has been registered in the ISIS TLV codepoint registry:
このドキュメントは、ISIS TLVコードポイントレジストリに登録されている3.1節で説明した次の新しいISIS TLVタイプを、定義しています。
Type Description IIH LSP SNP
---- ---------------------- --- --- ---
141 inter-AS reachability n y n
information
This document defines the following new sub-TLV types (described in Sections 3.3.1, 3.3.2, and 3.3.3) of top-level TLV 141 (see Section 6.1 above), which have been registered in the ISIS sub-TLV registry for TLV 141. Note that these three new sub-TLVs SHOULD NOT appear in TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222).
この文書は、最上位のTLV 141の以下の新しいサブTLVのタイプ定義（セクション3.3.1、3.3.2に記載し、そして3.3.3）ISISサブTLVに登録されている、（上述のセクション6.1を参照されたいです） TLV 141のレジストリこれら三つの新しいサブのTLVは、TLV 22（またはTLV 222）に表示されないように注意してくださいとするTLV 22（またはTLV 222）で無視しなければなりません。
Type Description
---- ------------------------------
24 remote AS number
25 IPv4 remote ASBR Identifier
26 IPv6 remote ASBR Identifier
As described above in Section 3.1, the sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents for describing the TE properties of a TE link are applicable to describe an inter-AS TE link and MAY be included in the inter-AS reachability TLV when adverting inter-AS TE links.
セクション3.1で説明したように、[ISIS-TE]で定義されたサブTLVは、[ISIS-TE-V3]、およびTEリンクのTEの特性を説明するための他の文書は、インターAS TEリンクを記述するのに適用可能であり、相互AS TEリンクをadvertingときAS間の到達可能性TLVに含まれるかもしれません。
IANA has updated the registry that was specified as "Sub-TLVs for TLV 22" to be named "Sub-TLVs for TLVs 22, 141, and 222". Three new columns have been added to the registry to show in which TLVs the sub-TLVs may be present. All sub-TLVs currently defined may be present in all three TLVs, hence the registry (with the definition of the new sub-TLVs defined here) should read as follows.
IANAは、「TLVの22、141、および222のためのサブTLVを」と命名されるように、「TLV 22のためのサブのTLV」として指定されたレジストリを更新しました。三つの新しい列とは、サブのTLVが存在することができるのTLV表示するためにレジストリに追加されました。現在定義されているすべてのサブのTLVは、したがって、次のように読むべきである（ここで定義された新たなサブのTLVの定義を有する）のレジストリすべての3つのTLVに存在してもよいです。
TLV TLV TLV
Type Description 22 141 222 Reference
------- ------------------------------------ --- --- --- ---------
0 Unassigned y y y
1 Unassigned y y y
2 Unassigned y y y
3 Administrative group (color) y y y [RFC5305]
4 Link Local/Remote Identifiers y y y
[RFC4205][RFC5307]
5 Unassigned y y y
6 IPv4 interface address y y y [RFC5305]
7 Unassigned y y y
8 IPv4 neighbor address y y y [RFC5305]
9 Maximum link bandwidth y y y [RFC5305]
10 Maximum reservable link bandwidth y y y [RFC5305]
11 Unreserved bandwidth y y y [RFC5305]
12 Unassigned y y y
13 Unassigned y y y
14 Unassigned y y y
15 Unassigned y y y
16 Unassigned y y y
17 Unassigned y y y
18 TE Default metric y y y [RFC5305]
19 Link-attributes y y y [RFC5029]
20 Link Protection Type y y y
[RFC4205][RFC5307]
21 Interface Switching Capability Desc y y y
[RFC4205][RFC5307]
22 Bandwidth Constraints y y y [RFC4124]
23 Unconstrained TE LSP Count (sub-)TLV y y y [RFC5330]
24 remote AS number n y n [RFC5316]
25 IPv4 remote ASBR identifier n y n [RFC5316]
26 IPv6 remote ASBR identifier n y n [RFC5316]
27-249 Unassigned
250-254 Reserved for Cisco-specific exts
255 Reserved for future expansion
Further sub-TLVs may be defined in the future for inclusion in any of the TLVs 22, 141, or 222. The re-naming of the registry as above ensures that there is no accidental overlap of sub-TLV codepoints. The introduction of the columns within the registry clarify the use of the sub-TLVs.
さらに、サブのTLVは、上記のように、サブTLVのコードポイントのない偶発的オーバーラップが存在しないことを保証するのTLV 22、141、または222、レジストリの再命名のいずれかに含めるために、将来的に定義されてもよいです。レジストリ内の列の導入は、サブのTLVの使用を明確にします。
This document defines the following new sub-TLV types, described in Sections 3.3.4 and 3.3.5, of top-level TLV 242 (which is defined in [ISIS-CAP]) that have been registered in the ISIS sub-TLV registry for TLV 242:
この文書では、ISISサブTLVのレジストリに登録されている（[ISIS-CAP]で定義されている）トップレベルTLV 242のセクション3.3.4および3.3.5に記載の以下の新しいサブTLVのタイプを、定義しますTLV 242のために：
Type Description Length
---- ------------------------------ --------
11 IPv4 TE Router ID 4
12 IPv6 TE Router ID 16
The authors would like to thank Adrian Farrel, Jean-Louis Le Roux, Christian Hopps, Les Ginsberg, and Hannes Gredler for their review and comments on this document.
作者は彼らのレビューと、この文書にコメントをエードリアンファレル、ジャン=ルイ・ル・ルー、クリスチャンHoppsが、レ・ギンズバーグ、およびハンネスGredlerに感謝したいと思います。
[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月。
[RFC3209] 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.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]李、T.、およびR.アトキンソンは、 "IS-IS暗号認証"、RFC 5304、2008年10月。
[ISIS] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[ISIS] Callon、R.、RFC 1195、1990年12月、 "TCP / IPやデュアル環境でのルーティングのためのOSI ISISの使用"。
[ISIS-CAP] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007.
[ISIS-CAP] Vasseur、JP。、エド。、シェン、N.、エド。、およびR.アガルワル、エド。、 "中間システムへの中間システム（ISIS）広告ルータ情報のための拡張機能"、RFC 4971、 2007年7月。
[INTER-AS-TE-REQ] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005.
[INTER-AS-TE-REQ]張、R.、編、及びJ.-P. Vasseur、エド。、 "MPLSインター自律システム（AS）トラフィックエンジニアリング（TE）の要件"、RFC 4216、2005年11月。
[PD-PATH] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[PD-PATH] Vasseur、JP。、編、Ayyangar、A.編、及びR.張は、「A単位のドメイン経路計算方法は、インタードメイントラフィックエンジニアリング（TE）ラベルを確立するためのパス（LSPを）交換しました」、RFC 5152、2008年2月。
[BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., JL. Le Roux, "A Backward Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Inter-Domain Traffic Engineering Label Switched Paths", Work in Progress, April 2008.
【BRPC] Vasseur、JP。、編、張、R.、ビタール、N.、JL。ル・ルー、進歩、2008年4月に、仕事を「最短ドメイン間トラフィックエンジニアリングラベルを計算するために、後方再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[PCE]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[ISIS-TE] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
[ISIS-TE]李、T.とH.スミット、 "トラフィックエンジニアリングのためのISIS拡張機能"、RFC 5305、2008年10月。
[ISIS-TE-V3] Harrison, J., Berger, J., and Bartlett, M., "IPv6 Traffic Engineering in IS-IS", Work in Progress, June 2008.
[ISIS-TE-V3]ハリソン、J.、バーガー、J.、およびバートレット、M.、 "ISISでのIPv6トラフィックエンジニアリング"、進歩、2008年6月の作業。
[GMPLS-TE] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[GMPLS-TE] Kompella、K.、エド。、およびY. Rekhterは、エド。、 "IS-ISの拡張一般化マルチプロトコルラベルスイッチング（GMPLS）の支援で"、RFC 5307、2008年10月。
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[GENINFO] L. Ginsberg., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", Work in Progress, June 2008.
[GENINFO] L.ギンズバーグ。、Previdi、S.、およびM.シャンド、 "IS-ISで広告ジェネリック情報"、進歩、2008年6月に作業。
Authors' Addresses
著者のアドレス
Mach (Guoyi) Chen Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd. Hai-Dian District Beijing, 100085 P.R. China
マッハ（GU Oのa）の陳HU Aは技術CO。、L TDK UI KEビル、ラインRDで9番Xである。H愛-Dイアン地区、北京、100085中華人民共和国
EMail: mach@huawei.com
メールアドレス：mach@huawei.com
Renhai Zhang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd. Hai-Dian District Beijing, 100085 P.R. China
N張HU技術の共同の海。、L TDK UI KEビル、ラインRD。H愛-Dイアン地区、北京、100085中華人民共和国で9番のX再
EMail: zhangrenhai@huawei.com
メールアドレス：zhangrenhai@huawei.com
Xiaodong Duan China Mobile 53A, Xibianmennei Ave. Xunwu District Beijing, China
Aodong D U [XI]ええと、中国の携帯電話53A、ξサイドドアAVE。X UN無い地区、北京、中国
EMail: duanxiaodong@chinamobile.com
メールアドレス：duanxiaodong@chinamobile.com