RFC5392 日本語訳
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Chen
Request for Comments: 5392 R. Zhang
Category: Standards Track Huawei Technologies Co., Ltd.
X. Duan
China Mobile
January 2009
コメントを求めるワーキンググループM.チェン要求をネットワークでつないでください: 5392年のR.チャンカテゴリ: 2009年1月のモバイルの標準化過程のHuawei技術株式会社X.Duan中国
OSPF Extensions in Support of Inter-Autonomous System (AS)
MPLS and GMPLS Traffic Engineering
相互自律システム(AS) MPLSとGMPLS交通工学を支持したOSPF拡張子
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2009IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.
このドキュメントは、複数のAutonomous Systems(ASes)のために、Multiprotocol Label Switching(MPLS)とGeneralized MPLS(GMPLS)交通Engineering(TE)を支持するためにOSPFバージョン2と3プロトコルに拡大について説明します。 OSPF-TE v2とv3拡張子は相互AS TE経路計算を実行するのに使用できる相互ASリンクのTE情報の氾濫によって定義されます。
No support for flooding information from within one AS to another AS is proposed or defined in this document.
1ASから別のASまでの氾濫情報のサポートは、全く本書では提案もされませんし、定義もされません。
Chen, et al. Standards Track [Page 1] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[1ページ]相互、Te2009年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 OSPF ..............................................7
3.1. LSA Definitions ............................................8
3.1.1. Inter-AS-TE-v2 LSA ..................................8
3.1.2. Inter-AS-TE-v3 LSA ..................................8
3.2. LSA Payload ................................................9
3.2.1. Link TLV ............................................9
3.3. Sub-TLV Details ...........................................10
3.3.1. Remote AS Number Sub-TLV ...........................10
3.3.2. IPv4 Remote ASBR ID Sub-TLV ........................11
3.3.3. IPv6 Remote ASBR ID Sub-TLV ........................11
4. Procedure for Inter-AS TE Links ................................12
4.1. Origin of Proxied TE Information ..........................13
5. Security Considerations ........................................14
6. IANA Considerations ............................................14
6.1. Inter-AS TE OSPF LSA ......................................14
6.1.1. Inter-AS-TE-v2 LSA .................................14
6.1.2. Inter-AS-TE-v3 LSA .................................14
6.2. OSPF LSA Sub-TLVs Type ....................................15
7. Acknowledgments ................................................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
1. 序論…2 1.1. このドキュメントで中古のコンベンション…3 2. 問題声明…3 2.1. 非目的に関する注…4 2.2. 1ドメインあたりの経路決断…4 2.3. 後方の再帰的な経路計算…6 3. OSPFへの拡大…7 3.1. LSA定義…8 3.1.1. 相互、Te v2 LSA、…8 3.1.2. 相互、Te v3 LSA、…8 3.2. LSA有効搭載量…9 3.2.1. TLVをリンクしてください…9 3.3. サブTLVの詳細…10 3.3.1. 数のサブTLVとしてリモート…10 3.3.2. IPv4のリモートASBR IDサブTLV…11 3.3.3. IPv6のリモートASBR IDサブTLV…11 4. 手順、相互、Teはリンクされます…12 4.1. Proxied Te情報の起源…13 5. セキュリティ問題…14 6. IANA問題…14 6.1. 相互、Te OSPF LSA…14 6.1.1. 相互、Te v2 LSA、…14 6.1.2. 相互、Te v3 LSA、…14 6.2. OSPF LSAサブTLVsはタイプします…15 7. 承認…15 8. 参照…15 8.1. 標準の参照…15 8.2. 有益な参照…16
1. Introduction
1. 序論
[OSPF-TE] defines extensions to the OSPF protocol [OSPF] 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. Type 10 Opaque Link State Advertisements (LSAs) [RFC5250] are used to carry such TE information. Two top-level Type Length Values (TLVs) are defined in [OSPF-TE]: Router Address TLV and Link TLV. The Link TLV has several nested sub-TLVs that describe the TE attributes for a TE link.
[OSPF-TE]は、イントラ領域Traffic Engineering(TE)を支持するためにOSPFプロトコル[OSPF]と拡大を定義します。 拡大は領域の中でネットワーク(TEリンク)と氾濫の中のTEによって可能にされたリンクのためのTE情報をコード化する方法にこの情報を提供します。 10タイプOpaque Link州Advertisements(LSAs)[RFC5250]が、そのようなTE情報を運ぶのに使用されます。 2トップレベルType Length Values(TLVs)が[OSPF-TE]で定義されます: ルータアドレスTLVとリンクTLV。 Link TLVには、TE属性についてTEリンクに説明する数個の入れ子にされたサブTLVsがあります。
Chen, et al. Standards Track [Page 2] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[2ページ]相互、Te2009年1月
[OSPF-V3-TE] defines similar extensions to OSPFv3 [OSPFV3]. It defines a new LSA, which is referred to as the Intra-Area-TE LSA, to advertise TE information. [OSPF-V3-TE] uses "Traffic Engineering Extensions to OSPF" [OSPF-TE] as a base for TLV definitions and defines some new TLVs and sub-TLVs to extend TE capabilities to IPv6 networks.
[OSPF-V3-TE]はOSPFv3[OSPFV3]と同様の拡大を定義します。 それは新しいLSAを定義します。(LSAは、TE情報の広告を出すためにIntra領域TE LSAと呼ばれます)。 [OSPF-V3-TE]は、TLV定義に、ベースとして「OSPFへの交通工学拡大」[OSPF-TE]を使用して、IPv6ネットワークへのTE能力を広げるためにいくつかの新しいTLVsとサブTLVsを定義します。
Requirements for establishing Multiprotocol Label Switching Traffic Engineering (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] needs to know the TE information not only of the links within an AS, but also of the links that connect to other ASes.
複数のAutonomous Systems(ASes)に交差するMultiprotocol Label Switching Traffic Engineering(MPLS-TE)ラベルSwitched Paths(LSPs)を設立するための要件は[INTER-AS-TE-REQ]で説明されます。 [INTER-AS-TE-REQ]で説明されるように、SHOULDが複数のASesにかかる経路を計算する能力を提供する方法です。 それで、ギヤエンドLabel Switching Router(LSR)、AS Border Router(ASBR)、またはPath Computation Elementであるかもしれない[PCE]経路計算実体は、ASの中のリンクだけではなく、他のASesに接続するリンクのTE情報を知る必要があります。
In this document, two new separate LSAs are defined to advertise inter-AS TE information for OSPFv2 and OSPFv3, respectively, and three new sub-TLVs are added to the existing Link TLV to extend TE capabilities for inter-AS Traffic Engineering. The detailed definitions and procedures are discussed in the following sections.
本書では、2新しい別々のLSAsがそれぞれOSPFv2とOSPFv3のための相互AS TE情報の広告を出すために定義されます、そして、3新しいサブTLVsが、相互AS Traffic EngineeringのためにTE能力を広げるために既存のLink TLVに加えられます。 以下のセクションで詳細な定義と手順について議論します。
This document does not propose or define any mechanisms to advertise any other extra-AS TE information within OSPF. See Section 2.1 for a full list of non-objectives for this work.
このドキュメントは、OSPFの中にいかなる他の余分なAS TE情報も広告を出すためにどんなメカニズムも提案もしませんし、定義もしません。 非目的の完全リストに関してこの仕事に関してセクション2.1を見てください。
1.1. Conventions Used in This Document
1.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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Problem Statement
2. 問題声明
As described in [INTER-AS-TE-REQ], in the case of establishing an inter-AS TE LSP traversing 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]、複数のASesを横断しながら相互AS TE LSPを設立する場合で説明されるように、Pathメッセージ[RFC3209]はLSPの経路について説明するためにExplicit Route Object(ERO)の以下の要素を含むかもしれません:
- a set of AS numbers as loose hops; and/or
- 1セットのゆるいAS同じくらい番号は跳びます。 そして/または
- a set of LSRs including ASBRs as loose hops.
- ゆるいホップとしてASBRsを含むLSRsの1セット。
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.
相互AS経路を決定するための2つの方法は現在、議論することです。 1ドメインあたりの方法[PD-PATH]は一度に1つのドメインに経路を決定します。 後方の因果循環法[BRPC]は、最適な相互ドメイン経路を決定するのにPCEsの間の協力を使用します。
Chen, et al. Standards Track [Page 3] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[3ページ]相互、Te2009年1月
The sections that follow examine how inter-AS TE link information could be useful in both cases.
従うセクションは相互AS TEリンク情報がどちらの場合もどう役に立つかもしれないかを調べます。
2.1. A Note on Non-Objectives
2.1. 非目的に関する注
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].
このドキュメントが秘密性と仮定をスケーリングすることへのインターネットでのASesの使用が囲まれるどんな変更も行わないことに注意するのは重要です。 このドキュメントは[INTER-AS-TE-REQ]を始められた要件への特に、conformantです。
The following features are explicitly excluded:
以下の特徴は明らかに遮断されます:
o There is no attempt to distribute TE information from within one
AS to another AS.
o 1ASから別のASまでTE情報を分配する試みが全くありません。
o There is no mechanism proposed to distribute any form of TE
reachability information for destinations outside the AS.
o ASの外の目的地のためのどんなフォームのTE可到達性情報も分配するために提案されて、メカニズムが全くありません。
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 ASesの間には、個人情報の交換が全くありません。
o No OSPF adjacencies are formed on the inter-AS link.
o OSPF隣接番組は全く相互ASリンクに形成されません。
Note also that the extensions proposed in this document are used only to advertise information about inter-AS TE links. As such these extensions address an entirely different problem from L1VPN Auto- Discovery [L1VPN-OSPF-AD], which defines how TE information about links between Customer Edge (CE) equipment and Provider Edge (PE) equipment can be advertised in OSPF-TE alongside the auto-discovery information for the CE-PE links. There is no overlap between this document and [L1VPN-OSPF-AD].
また、本書では提案された拡張子が使用されることに注意してください相互AS TEリンクの情報の広告を出す。 そういうものとして、これらの拡大はその完全にCE-PEリンクのための自動発見情報と並んでOSPF-TEにどうCustomer Edge(CE)設備とProvider Edge(PE)設備とのリンクのTE情報の広告を出すことができるかを定義するL1VPN Auto発見[L1VPN-OSPF-西暦]と異なった問題を訴えます。 このドキュメントと[L1VPN-OSPF-西暦]の間には、オーバラップが全くありません。
2.2. Per-Domain Path Determination
2.2. 1ドメインあたりの経路決断
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 so that it can compute a TE LSP segment across the local AS to one of those LSRs and forward the Path message to it and hence into the next AS. See Figure 1 for an example:
ASへのエントリー・ポイントであるLSRがAS番号である次のホップを含むEROと共に上流からのPathメッセージを受け取るときMPLS-TE LSPのために相互AS経路を決定する1ドメインあたりの方法で、それは、地方のASの中のどのLSRs(ASBRs)が地方のASの向こう側にTE LSPセグメントをそれらのLSRsの1つまで計算して、それと、そして、したがって、次のASの中にPathメッセージを転送できるように川下のASに接続されるかわかる必要があります。 例に関して図1を見てください:
Chen, et al. Standards Track [Page 4] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[4ページ]相互、Te2009年1月
R1------R3----R5-----R7------R9-----R11
| | \ | / |
| | \ | ---- |
| | \ | / |
R2------R4----R6 --R8------R10----R12
: :
<-- AS1 -->:<---- AS2 --->:<--- AS3 --->
R1------R3----R5-----R7------R9-----R11| | \ | / | | | \ | ---- | | | \ | / | R2------R4----R6 --R8------R10----R12: : <-- AS1-->: <。---- AS2--->: <。--- AS3--->。
Figure 1: Inter-AS Reference Model
図1: 相互、規範モデル
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.
図は3ASes(AS1、AS2、およびAS3)と12LSRs(R1からR12)を示しています。 R3とR4はAS1のASBRsです。 R5、R6、R7、およびR8はAS2のASBRsです。 R9とR10はAS3のASBRsです。
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はAS2の向こう側の経路セグメントがAS3に達することを決定しなければなりません。 それには、AS2(R6、R7、およびR8)からの3つのエキジットポイントの選択があります、そして、これらのどれがTEの接続性をAS3に供給するか、そして、要求されたLSPに、TEの接続性(例えば、利用可能な帯域幅)が適切であるかどうかを知るのが必要です。
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のためのエントリーASBR(R9を言う)であるなら、R5は、出口ASBRsのどれがR9に接続するTEリンクを持っているかを知る必要があります。 R9(この例のR7とR8の両方)に接続される複数のASBRsがあるかもしれないので、また、R5は、正しい出口ASBRを選択できるように相互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.
経路メッセージがいったん出口ASBRに達すると、相互AS TEリンクのどんな選択もASBRが作るか、またはセグメントを計算したエントリーASBRは既にすることができます。
More details can be found in Section 4 of [PD-PATH], which clearly points out why the advertising of inter-AS links is desired.
[PD-PATH]のセクション4でその他の詳細を見つけることができます。(明確に、]は、相互ASリンクの広告がなぜ望まれているかを指摘します)。
To enable R5 to make the correct choice of exit ASBR, the following information is needed:
R5が出口ASBRの正しい選択をするのを可能にするために、以下の情報が必要です:
o List of all inter-AS TE links for the local AS.
o すべての相互AS TEのリストは地方のASのためにリンクされます。
o TE properties of each inter-AS TE link.
o それぞれの相互AS TEのTEの特性はリンクされます。
o AS number of the neighboring AS to which each inter-AS TE link
is connected.
o それぞれの相互AS TEがリンクする隣接しているASのAS番号は関連しています。
Chen, et al. Standards Track [Page 5] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[5ページ]相互、Te2009年1月
o Identity (TE Router ID) of the neighboring ASBR to which each
inter-AS TE link is connected.
o それぞれの相互AS TEがリンクする隣接しているASBRのアイデンティティ(TE Router 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), but this information is also needed throughout the local AS if path computation function is fully distributed among LSRs in the local AS, for example, to support LSPs that have start points (ingress nodes) within the AS.
ASの中で(イングレスノード)を指します上記の例が、この情報がエントリー・ポイントASBRsで各AS(または、計算サービスをASBRsに供給するPCEs)に必要ですが、また、例えば、経路計算機能が始めを持っているLSPsを支持するために地方のASのLSRsの中で完全に分配されるならこの情報が地方のAS中でどう必要であるかを示している。
2.3. Backward Recursive Path Computation
2.3. 後方の再帰的な経路計算
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 LSPsを計算するPCEベースのTE LSP計算方法(Backward Recursive Path Computationと呼ばれる)を定義します。 この経路計算方法で、計算が始まる前に特定のセットの横断されたドメイン(ASes)が選択されると思われます。 ドメイン(i)のそれぞれの川下のPCEは潜在的経路のドメイン(i-1)示す多点木の上流の隣人PCEに戻ります。 各木はドメイン(i)に位置するすべてのBoundary Nodesから各経路がTE LSP(帯域幅、親近感など)の必要な規制のセットを満たす目的地までの経路のセットから成ります。
So a PCE needs to select Boundary Nodes (that is, ASBRs) that provide connectivity from the upstream AS. In order that the tree of paths provided by one PCE to its neighbor can be correlated, the identities of the ASBRs for each path need to be referenced, so the PCE must know the identities of the ASBRs in the remote AS reached by any inter-AS TE link, and, in order that it provides 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から接続性を提供するBoundary Nodes(すなわち、ASBRs)を選択する必要があります。 1PCEによって隣人に提供された経路の木が関連できるように、各経路へのASBRsのアイデンティティは、参照をつけられる必要があります、そして、したがって、PCEはどんな相互AS TEリンクでも達したリモートASのASBRsのアイデンティティを知らなければなりません、そして、適当な経路だけを木に提供するために、PCEは相互AS TEリンクのTEの特性を知らなければなりません。 以下が例として現れるのを見てください:
PCE1<------>PCE2<-------->PCE3
/ : :
/ : :
R1------R3----R5-----R7------R9-----R11
| | \ | / |
| | \ | ---- |
| | \ | / |
R2------R4----R6 --R8------R10----R12
: :
<-- AS1 -->:<---- AS2 --->:<--- AS3 --->
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: BRPC、相互、規範モデル
Chen, et al. Standards Track [Page 6] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[6ページ]相互、Te2009年1月
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).
図は3ASes(AS1、AS2、およびAS3)、3PCEs(PCE1、PCE2、およびPCE3)、および12LSRs(R1からR12)を示しています。 R3とR4はAS1のASBRsです。 R5、R6、R7、およびR8はAS2のASBRsです。 R9とR10はAS3のASBRsです。 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 Path Computation Client (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.
相互AS TE LSPがR1からR12まで証明されるために計画されているなら、横断されたドメインが選択されると思われます: AS1->、AS2、->AS3、およびPCEチェーンは以下の通りです。 PCE1、-、>PCE2->、PCE3。 まず最初に、Path Computation Client(R1)から溯源された経路計算要求はPCEチェーンに沿ってPCE1とPCE2によってPCE3にリレーされて、次に、PCE3はAS2から接続を備えるエントリー境界ノードから目的地(R12)まで経路セグメントを計算し始めます。 しかし、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 to which each inter-AS TE link is connected is particularly important.
したがって、Backward Recursive Path Computationを支持するために、セクション2.2にリストアップされた同じ情報が必要です。 それぞれの相互AS TEリンクが接続されている隣接しているASのAS番号は特に重要です。
3. Extensions to OSPF
3. OSPFへの拡大
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.
このドキュメントがTE情報の1ASから別のASまでの分配のためにメカニズムを定義しないで、またASの外の目的地のためのどんなフォームのTE可到達性情報も分配しないで、またPCE構造か用法を変えないで、またどんなフォームのTE集合も示しもしませんし、推薦もしないで、ASesの間の個人情報を与えないことに注意してください。 セクション2.1を見てください。
The extensions defined in this document allow an inter-AS TE link advertisement to be easily identified as such by the use of two new types of LSA, which are referred to as Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA. Three new sub-TLVs are added to the Link TLV to carry the information about the neighboring AS and the remote ASBR.
本書では定義された拡大は、相互AS TEリンク広告がLSAの2つの新しいタイプの使用で容易にそういうものとして特定されるのを許容します。LSAはInter-AS-TE-v2 LSAとInter-AS-TE-v3 LSAと呼ばれます。 3新しいサブTLVsが、隣接しているASとリモートASBRの情報を運ぶためにLink 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操作に必要であるすべての情報を乗せます。
Chen, et al. Standards Track [Page 7] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[7ページ]相互、Te2009年1月
3.1. LSA Definitions
3.1. LSA定義
3.1.1. Inter-AS-TE-v2 LSA
3.1.1. 相互、Te v2 LSA
For the advertisement of OSPFv2 inter-AS TE links, a new Opaque LSA, the Inter-AS-TE-v2 LSA, is defined in this document. The Inter-AS-TE-v2 LSA has the same format as "Traffic Engineering LSA", which is defined in [OSPF-TE].
OSPFv2相互AS TEリンクの広告において、新しいOpaque LSA(Inter-AS-TE-v2 LSA)は本書では定義されます。 Inter-AS-TE-v2 LSAには、[OSPF-TE]で定義される「交通工学LSA」と同じ形式があります。
The inter-AS TE link advertisement SHOULD be carried in a Type 10 Opaque LSA [RFC5250] if the flooding scope is to be limited to within the single IGP area to which the ASBR belongs, or MAY be carried in a Type 11 Opaque LSA [RFC5250] if the information is intended to reach all routers (including area border routers, ASBRs, and PCEs) in the AS. The choice between the use of a Type 10 (area-scoped) or Type 11 (AS-scoped) Opaque LSA is an AS-wide policy choice, and configuration control of it SHOULD be provided in ASBR implementations that support the advertisement of inter-AS TE links.
相互AS TEリンク広告SHOULDは氾濫範囲がASBRが属するただ一つのIGP領域に制限されるつもりであるならType10Opaque LSA[RFC5250]で運ばれるか、または情報がすべてのルータに達することを意図するなら(境界ルータ、ASBRs、およびPCEsを含んでいて)、ASでType11Opaque LSA[RFC5250]で運ばれるかもしれません。 Type10(領域で見られた)かType11(ASによって見られた)の不透明なLSAの使用の選択はAS全体の政治的選択であり、それの構成管理はSHOULDです。相互AS TEリンクの広告を支持するASBR実現に提供します。
The Link State ID of an Opaque LSA as defined in [RFC5250] is divided into two parts. One of them is the Opaque type (8-bit), the other is the Opaque ID (24-bit). The value for the Opaque type of Inter-AS-TE-v2 LSA is 6 and has been assigned by IANA (see Section 6.1). The Opaque ID of the Inter-AS-TE-v2 LSA is an arbitrary value used to uniquely identify Traffic Engineering LSAs. The Link State ID has no topological significance.
[RFC5250]の定義されるとしてのOpaque LSAのLink州IDは2つの部品に分割されます。 それらの1つがOpaqueタイプ(8ビット)である、もう片方がOpaque ID(24ビット)です。 Inter-AS-TE-v2 LSAのOpaqueタイプのための値は、6歳であり、IANAによって割り当てられました(セクション6.1を見てください)。 Inter-AS-TE-v2 LSAのOpaque IDは唯一Traffic Engineering LSAsを特定するのに使用される任意の値です。 Link州IDには、どんな位相的な意味もありません。
The TLVs within the body of an Inter-AS-TE-v2 LSA have the same format as used in OSPF-TE. The payload of the TLVs consists of one or more nested Type/Length/Value triplets. New sub-TLVs specifically for inter-AS TE Link advertisement are described in Section 3.2.
Inter-AS-TE-v2 LSAのボディーの中のTLVsには、OSPF-TEで同じくらい中古の同じ形式があります。 TLVsのペイロードは1人以上の入れ子にされたType/長さ/値の三つ子から成ります。 特に相互AS TE Link広告のための新しいサブTLVsはセクション3.2で説明されます。
3.1.2. Inter-AS-TE-v3 LSA
3.1.2. 相互、Te v3 LSA
In this document, a new LS type is defined for OSPFv3 inter-AS TE link advertisement. The new LS type function code is 13 (see Section 6.1).
本書では、新しいLSタイプはOSPFv3相互AS TEリンク広告のために定義されます。 新しいLSタイプ機能コードは13(セクション6.1を見る)です。
The format of an Inter-AS-TE-v3 LSA follows the standard definition of an OSPFv3 LSA as defined in [OSPFV3].
Inter-AS-TE-v3 LSAの形式は[OSPFV3]で定義されるようにOSPFv3 LSAの標準定義に続きます。
The high-order three bits of the LS type field of the OSPFv3 LSA header encode generic properties of the LSA and are termed the U-bit, S2-bit, and S1-bit [OSPFV3]. The remainder of the LS type carries the LSA function code.
OSPFv3 LSAヘッダーのLSタイプ分野の高位3ビットは、LSAの一般的な特性をコード化して、U-ビット、S2-ビット、およびS1-ビット[OSPFV3]と呼ばれます。 LSタイプの残りはLSA機能コードを運びます。
Chen, et al. Standards Track [Page 8] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[8ページ]相互、Te2009年1月
For the Inter-AS-TE-v3-LSA, the bits are set as follows:
Inter-AS-TE-v3-LSAにおいて、ビットは以下の通り設定されます:
The U-bit is always set to 1 to indicate that an OSPFv3 router MUST flood the LSA at its defined flooding scope even if it does not recognize the LS type.
いつも1にU-ビットが、LSがタイプすると認めないでもOSPFv3ルータが定義された氾濫範囲にLSAをあふれさせなければならないのを示すように設定されます。
The S2 and S1 bits indicate the flooding scope of an LSA. For the Inter-AS-TE-v3-LSA, the S2 and S1 bits SHOULD be set to 01 to indicate that the flooding scope is to be limited to within the single IGP area to which the ASBR belongs, but MAY be set to 10 if the information should reach all routers (including area border routers, ASBRs, and PCEs) in the AS. The choice between the use of 01 or 10 is a network-wide policy choice, and configuration control SHOULD be provided in ASBR implementations that support the advertisement of inter-AS TE links.
S2とS1ビットはLSAの氾濫範囲を示します。 Inter-AS-TE-v3-LSA、S2、およびS1ビットにおいて、SHOULDは01に氾濫範囲がASBRが属するただ一つのIGP領域に制限されることになっているのを示すように設定されますが、情報がすべてのルータに達するなら(境界ルータ、ASBRs、およびPCEsを含んでいて)、ASで10に用意ができるかもしれません。 01か10の使用の選択はネットワーク全体の政治的選択です、そして、ASBR実現におけるそのサポートであるなら、構成管理SHOULDはそのような政治的選択です。相互AS TEリンクの広告。
The Link State ID of the Inter-AS-TE-v3 LSA is an arbitrary value used to uniquely identify Traffic Engineering LSAs. The LSA ID has no topological significance.
Inter-AS-TE-v3 LSAのLink州IDは唯一Traffic Engineering LSAsを特定するのに使用される任意の値です。 LSA IDには、どんな位相的な意味もありません。
The TLVs within the body of an Inter-AS-TE-v3 LSA have the same format and semantics as those defined in [OSPF-V3-TE]. New sub-TLVs specifically for inter-AS TE Link advertisement are described in Section 3.2.
Inter-AS-TE-v3 LSAのボディーの中のTLVsには、[OSPF-V3-TE]で定義されたものとして同じ形式と意味論があります。 特に相互AS TE Link広告のための新しいサブTLVsはセクション3.2で説明されます。
3.2. LSA Payload
3.2. LSA有効搭載量
Both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA contain one top level TLV:
Inter-AS-TE-v2 LSAとInter-AS-TE-v3 LSAの両方が1最高平らなTLVを含んでいます:
2 - Link TLV
2--リンクTLV
For the Inter-AS-TE-v2 LSA, this TLV is defined in [OSPF-TE], and for the Inter-AS-TE-v3 LSA, this TLV is defined in [OSPF-V3-TE]. The sub-TLVs carried in this TLV are described in the following sections.
Inter-AS-TE-v2 LSAに関しては、このTLVは[OSPF-TE]で定義されます、そして、Inter-AS-TE-v3 LSAに関して、このTLVは[OSPF-V3-TE]で定義されます。 これで運ばれたサブTLVs TLVは以下のセクションで説明されます。
3.2.1. Link TLV
3.2.1. リンクTLV
The Link TLV describes a single link and consists a set of sub-TLVs. The sub-TLVs for inclusion in the Link TLV of the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA are defined, respectively, in [OSPF-TE] and [OSPF-V3-TE], and the list of sub-TLVs may be extended by other documents. However, this document defines the following exceptions.
Link TLVは単一のリンクについて説明して、a設定していた状態でサブTLVsから成ります。 Inter-AS-TE-v2 LSAとInter-AS-TE-v3 LSAのLink TLVでの包含のためのサブTLVsは[OSPF-TE]と[OSPF-V3-TE]でそれぞれ定義されます、そして、サブTLVsのリストは他のドキュメントによって広げられるかもしれません。 しかしながら、このドキュメントは以下の例外を定義します。
Chen, et al. Standards Track [Page 9] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[9ページ]相互、Te2009年1月
The Link ID sub-TLV [OSPF-TE] MUST NOT be used in the Link TLV of an Inter-AS-TE-v2 LSA, and the Neighbor ID sub-TLV [OSPF-V3-TE] MUST NOT be used in the Link TLV of an Inter-AS-TE-v3 LSA. Given that OSPF is an IGP and should only be utilized between routers in the same routing domain, the OSPF specific Link ID and Neighbor ID sub-TLVs are not applicable to inter-AS links.
Inter-AS-TE-v2 LSAのLink TLVでLink IDサブTLV[OSPF-TE]を使用してはいけません、そして、Neighbor IDサブTLV[OSPF-V3-TE]はInter-AS-TE-v3 LSAのLink TLVで使用されてはいけません。 それを考えて、OSPFはIGPであり、同じ経路ドメインのルータの間で利用されるだけであるべきであり、OSPFの特定のLink IDとNeighbor IDサブTLVsは相互ASリンクに適切ではありません。
Instead, the remote ASBR is identified by the inclusion of the following new sub-TLVs defined in this document and described in the subsequent sections.
代わりに、リモートASBRは本書では定義されて、その後のセクションで説明された以下の新しいサブTLVsの包含で特定されます。
21 - Remote AS Number sub-TLV
21--、数のサブTLVとしてリモート
22 - IPv4 Remote ASBR ID sub-TLV
22--IPv4のリモートASBR IDサブTLV
23 - IPv6 Remote ASBR ID sub-TLV
23--IPv6のリモートASBR IDサブTLV
The Remote-AS-Number sub-TLV MUST be included in the Link TLV of both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA. At least one of the IPv4-Remote-ASBR-ID sub-TLV and the IPv6-Remote-ASBR-ID sub-TLV SHOULD be included in the Link TLV of the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA. Note that it is possible to include the IPv6-Remote-ASBR-ID sub-TLV in the Link TLV of the Inter-AS-TE-v2 LSA, and to include the IPv4-Remote-ASBR-ID sub-TLV in the Link TLV of the Inter-AS-TE-v3 LSA because the sub-TLVs refer to ASBRs that are in a different addressing scope (that is, a different AS) from that where the OSPF LSA is used.
含まれているコネがInter-AS-TE-v2 LSAとInter-AS-TE-v3 LSAの両方のLink TLVであったならサブTLV MUSTにRemote-AS付番してください。 少なくとも1、IPv4の遠く離れたASBR IDサブTLVとIPv6の遠く離れたASBR IDサブTLV SHOULDでは、Inter-AS-TE-v2 LSAとInter-AS-TE-v3 LSAのLink TLVで含められてください。 サブTLVsがそれから異なったアドレシング範囲(すなわち、異なったAS)にあるASBRsをOSPF LSAが使用されているところと呼ぶので、Inter-AS-TE-v2 LSAのLink TLVのサブTLVのIPv6遠く離れたASBR IDを含んでいて、Inter-AS-TE-v3 LSAのLink TLVのサブTLVのIPv4遠く離れたASBR IDを含んでいるのが可能であることに注意してください。
3.3. Sub-TLV Details
3.3. サブTLVの詳細
3.3.1. Remote AS Number Sub-TLV
3.3.1. 数のサブTLVとして、リモートです。
A new sub-TLV, the Remote AS Number sub-TLV is defined for inclusion in the Link 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. The Remote AS Number sub-TLV is REQUIRED in a Link TLV that advertises an inter-AS TE link.
相互ASリンクの広告を出すとき、新しいサブTLVであり、Remote AS NumberサブTLVはLink TLVでの包含のために定義されます。 Remote AS NumberサブTLVは広告を出しているリンクが接続する隣接しているASのAS番号を指定します。 Remote AS NumberサブTLVは相互AS TEリンクの広告を出すLink TLVのREQUIREDです。
The Remote AS Number sub-TLV is TLV type 21 (see Section 6.2), and is four octets in length. The format is as follows:
Remote AS NumberサブTLVはTLVタイプ21であり(セクション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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 数として、リモートです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chen, et al. Standards Track [Page 10] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[10ページ]相互、Te2009年1月
The Remote AS Number field has 4 octets. When only two octets are used for the AS number, as in current deployments, the left (high- order) two octets MUST be set to zero.
Remote AS Number分野には、4つの八重奏があります。 2つの八重奏だけがAS番号に現在の展開のように使用されるとき、左の(高いオーダー)2つの八重奏をゼロに設定しなければなりません。
3.3.2. IPv4 Remote ASBR ID Sub-TLV
3.3.2. IPv4のリモートASBR IDサブTLV
A new sub-TLV, which is referred to as the IPv4 Remote ASBR ID sub- TLV, can be included in the Link 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 Address TE Router ID as specified in the Router Address TLV [OSPF-TE] is RECOMMENDED.
相互ASリンクの広告を出すとき、Link TLVに新しいサブTLV(IPv4 Remote ASBR IDサブTLVと呼ばれる)を含むことができます。 IPv4 Remote ASBR IDサブTLVは広告を出している相互ASリンクが接続するリモートASBRに関するIPv4識別子を指定します。 これは、リモートASBRのどんなうまやとroutable IPv4アドレスであるかもしれません。 Router Address TLV[OSPF-TE]の指定されるとしてのTE Router Address TE Router IDの使用はRECOMMENDEDです。
The IPv4 Remote ASBR ID sub-TLV is TLV type 22 (see Section 6.2), and is four octets in length. Its format is as follows:
IPv4 Remote ASBR IDサブTLVはTLVタイプ22であり(セクション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 ASBR ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたASBR ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In OSPFv2 advertisements, 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 a Link TLV in OSPFv2 or OSPFv3.
OSPFv2広告、IPv4 Remote ASBR IDサブTLV MUST、隣接しているASBRにIPv4アドレスがあるなら、含められてください。 IPv4アドレス(IPv4 TE Router IDでないさえ)、IPv6 Remote ASBR IDサブTLV MUSTが隣接しているASBRが代わりに含ませていないなら。 IPv4 Remote ASBR IDサブTLVとIPv6 Remote ASBR ID、サブTLV MAYであることは、ともにOSPFv2でのLink TLVでのプレゼントかOSPFv3です。
3.3.3. IPv6 Remote ASBR ID Sub-TLV
3.3.3. IPv6のリモートASBR IDサブTLV
A new sub-TLV, which is referred to as the IPv6 Remote ASBR ID sub- TLV, can be included in the Link TLV when advertising inter-AS links. The IPv6 Remote ASBR ID sub-TLV specifies the identifier of the remote ASBR to which the advertised inter-AS link connects. This could be any stable, routable, and global IPv6 address of the remote ASBR. Use of the TE Router IPv6 Address IPv6 TE Router ID as specified in the IPv6 Router Address, which is specified in the IPv6 Router Address TLV [OSPF-V3-TE], is RECOMMENDED.
相互ASリンクの広告を出すとき、Link TLVに新しいサブTLV(IPv6 Remote ASBR IDサブTLVと呼ばれる)を含むことができます。 IPv6 Remote ASBR IDサブTLVは広告を出している相互ASリンクが接続するリモートASBRに関する識別子を指定します。 これはリモートASBRのどんな安定して、発送可能であって、グローバルなIPv6アドレスであるかもしれません。 IPv6 Router Address TLV[OSPF-V3-TE]で指定されるIPv6 Router Addressの指定されるとしてのTE Router IPv6 Address IPv6 TE Router IDの使用はRECOMMENDEDです。
The IPv6 Remote ASBR ID sub-TLV is TLV type 24 (see Section 6.2), and is sixteen octets in length. Its format is as follows:
IPv6 Remote ASBR IDサブTLVはTLVタイプ24であり(セクション6.2を見ます)、長さが16の八重奏です。 形式は以下の通りです:
Chen, et al. Standards Track [Page 11] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[11ページ]相互、Te2009年1月
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたASBR ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたASBR ID(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたASBR ID(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 遠く離れたASBR ID(続けられています)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In OSPFv3 advertisements, 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 a Link TLV in OSPFv2 or OSPFv3.
OSPFv3広告、IPv6 Remote ASBR IDサブTLV MUST、隣接しているASBRにIPv6アドレスがあるなら、含められてください。 隣接しているASBRがIPv6アドレス、IPv4 Remote ASBR IDをサブTLV MUSTであるのに持っていないなら、代わりに含められてください。 IPv4 Remote ASBR IDサブTLVとIPv6 Remote ASBR ID、サブTLV MAYであることは、ともにOSPFv2でのLink TLVでのプレゼントかOSPFv3です。
4. Procedure for Inter-AS TE Links
4. 手順、相互、Teはリンクされます。
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 OSPF-TE [OSPF-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 the ASBR MUST take precautions against excessive re- advertisements as described in [OSPF-TE].
TEが相互ASリンクで有効にされて、リンクが上がっているとき、ASBR SHOULDは、OSPF-TE[OSPF-TE]に正常な手順を用いることでこのリンクの広告を出します。 リンクが下がっているか、またはTEがリンクの上に無効にされるとき、ASBR SHOULDは広告を引き下がらせます。 リンクのためのTEパラメタへの変化があるとき(利用可能な帯域幅が例えば変化すると)、ASBR SHOULDはリンクの再広告を出しますが、ASBR MUSTは[OSPF-TE]で説明されるように過度の再広告に対して予防策を講します。
Hellos MUST NOT be exchanged over the inter-AS link, and consequently, an OSPF adjacency MUST NOT be formed.
相互ASリンクの上とハローズを交換してはいけません、そして、その結果、OSPF隣接番組を形成してはいけません。
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の知識、リンクの現在の状態と使用法、およびリモートAS番号の、そして、遠く離れたASBR TE Router IDのASBRでの構成に関するASBRの知識から来ます。
Legacy routers receiving an advertisement for an inter-AS TE link are able to ignore it because the Link Type carries an unknown value. They will continue to flood the LSA, but will not attempt to use the information received as if the link were an intra-AS TE link.
Link Typeが未知の値を運ぶので、相互AS TEリンクに広告を受け取る遺産ルータはそれを無視できます。 彼らは、LSAをあふれさせ続けますが、まるでリンクがイントラ-AS TEリンクであるかのように受け取られた情報を使用するのを試みないでしょう。
In the current operation of TE OSPF, 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)
TE OSPFの現在の操作では、TEリンクの各端のLSRsはリンクについて説明するLSAsを放ちます。 そして、LSRsのデータベースには、2つのエントリーがあります。(同輩からの局所的に発生するもの、もう片方)
Chen, et al. Standards Track [Page 12] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[12ページ]相互、Te2009年1月
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.
それはリンクの異なった'指示'について説明します。 リンクの両方の指示が必要な規制を満たさないなら、これは、Constrained Shortest Path First(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経路計算実体が候補道としてリンクを含むように、私たちはLSAsに(双方向)のTEの特性についてTEデータベースに説明させる方法を見つけなければなりません。
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 Link Type, the Remote AS number, and the Remote 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.
リンクのための何らかのだけ不可欠のTE情報が、広告を出す必要があります。 すなわち、Link Type、Remote AS番号、およびRemote ASBR ID。 相互AS TEの処理広告ができるルータかPCEsがそのようなものがASを出る経路をリモートASBRに計算して、次に、すぐに別のTEリンクを通してASに再入するためにリンクするSHOULD NOT使用をリンクします。 そのような経路は非常にまれな事故とSHOULD NOTを構成するでしょう。特定保険証券構成の結果を除いて、経路を計算するルータかPCEに許容されてください。
4.1. Origin of Proxied TE Information
4.1. Proxied Te情報の起源
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がどうTEリンク情報の広告を出すかを隣人ASBRのプロキシと説明しますが、この情報がどこから来るかを説明しません。
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.
このドキュメントの範囲の外にこの情報の源がありますが、それがASBRでなる構成要件は可能です、TEリンクの他の、そして、ローカルの特性のように。 さらに、BGPがASBRsと、リンクに関する、ある量の追加地方の構成とリモートASBRの間でIPルーティング情報を交換するのにどこで使用されるかは、利用可能である傾向があります。
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から必要な設定情報のいくつかを得るために可能であり、操作上有利であるかもしれないことにさらに注意します。 問題であってこれらの可能性を利用するのは、どのように実現問題であるか。
Chen, et al. Standards Track [Page 13] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[13ページ]相互、Te2009年1月
5. Security Considerations
5. セキュリティ問題
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 OSPF security mechanisms.
本書では定義されたプロトコル拡大は、比較的小さい方であり、彼らが既存のOSPFセキュリティー対策によって使用されるASの中で保証できます。
There is no exchange of information between ASes, and no change to the OSPF security relationship between the ASes. In particular, since no OSPF adjacency is formed on the inter-AS links, there is no requirement for OSPF security between the ASes.
ASesの間には、ASesにもかかわらず、OSPF安全保障関係へのどんな変化の間にはも、情報交換が全くありません。 OSPF隣接番組が全く相互ASリンクに形成されないので、ASesの間には、特に、OSPFセキュリティのための要件が全くありません。
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 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.
商業関係の一部として隣接している管理からこれらの新しい広告(例えば、リモートAS番号とリモート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 this could be used to detect inconsistencies in configuration (e.g., the administration that originally supplied the information may be lying, or some manual misconfigurations or mistakes are made by the operators). For example, if a different remote AS number is received in a BGP OPEN [BGP] from that locally configured into OSPF-TE, as we describe here, then local policy SHOULD be applied to determine whether to alert the operator to a potential misconfiguration or to suppress the OSPF 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)のじっと見ることが2ASBRsの間に私たちが考えているシナリオに存在するかもしれないことに注意する価値があって、構成における矛盾を検出するのにこれは使用できました(例えば元々情報を提供した管理があるかもしれませんか、またはいくつかの手動のmisconfigurationsか誤りがオペレータによってされます)。 例えば、異なったリモートAS番号が局所的にOSPF-TEに次に、私たちがここで説明するように地方で構成されたそれからBGP OPENで容認された[BGP]方針SHOULDであるなら適用されて、潜在的misconfigurationのオペレータを警告するか、または相互AS TEリンクのOSPF広告を抑圧するか決定してください。 BGPが提供するために[BGP]で説明される安全にされた使用メカニズムが認証であったならセクション4.1、相互AS BGPセッションSHOULDのときに説明される交換TE情報に使用されて、保全がチェックするなら、さらにそれに注意してください。
6. IANA Considerations
6. IANA問題
IANA has made the following allocations from registries under its control.
IANAは登録からコントロールの下で以下の配分をしました。
6.1. Inter-AS TE OSPF LSA
6.1. 相互、Te OSPF LSA
6.1.1. Inter-AS-TE-v2 LSA
6.1.1. 相互、Te v2 LSA
IANA has assigned a new Opaque LSA type (6) to Inter-AS-TE-v2 LSA.
IANAは新しいOpaque LSAタイプ(6)をInter-AS-TE-v2 LSAに選任しました。
6.1.2. Inter-AS-TE-v3 LSA
6.1.2. 相互、Te v3 LSA
IANA has assigned a new OSPFv3 LSA type function code (13) to Inter- AS-TE-v3 LSA.
IANAは新しいOSPFv3 LSAタイプ機能コード(13)をInter- AS-TE-v3 LSAに割り当てました。
Chen, et al. Standards Track [Page 14] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[14ページ]相互、Te2009年1月
6.2. OSPF LSA Sub-TLVs Type
6.2. OSPF LSAサブTLVsはタイプします。
IANA maintains the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry with sub-registry "Types for sub-TLVs in a TE Link TLV". IANA has assigned three new sub-TLVs as follows (see Section 3.3 for details):
IANAは、サブ登録がある「開いている最短パス最初(OSPF)の交通工学TLVs」登録が「TeリンクTLVのサブTLVsのために、タイプされる」と主張します。 IANAは以下の3新しいサブTLVsを割り当てました(詳細に関してセクション3.3を見てください):
Value Meaning
値の意味
21 Remote AS Number sub-TLV
21、数のサブTLVとしてリモート
22 IPv4 Remote ASBR ID sub-TLV
22 IPv4のリモートASBR IDサブTLV
24 IPv6 Remote ASBR ID sub-TLV
24 IPv6のリモートASBR IDサブTLV
7. Acknowledgments
7. 承認
The authors would like to thank Adrian Farrel, Acee Lindem, JP Vasseur, Dean Cheng, and Jean-Louis Le Roux for their review and comments to this document.
作者はこのドキュメントへの彼らのレビューとコメントについてエードリアン・ファレル、Acee Lindem、JP Vasseur、ディーン・チェン、およびジャン・ルイル・ルーに感謝したがっています。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[GMPLS-TE] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4203, October 2005.
[GMPLS-Te]Kompella、K.(エド)、およびY.Rekhter(エド)、「一般化されたマルチプロトコルを支持したOSPF拡張子は切り換え(GMPLS)をラベルします」、RFC4203、2005年10月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[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.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[OSPF-V3-TE] Ishiguro, K., Manral, V., Davey, A., and A. Lindem,
Ed., "Traffic Engineering Extensions to OSPF
Version 3", RFC 5329, September 2008.
[OSPF-V3-Te] イシグロとK.とManralとV.とデーブ、A.とA.Lindem、エド、「工学拡大をOSPFにバージョン3インチ取引してください、RFC5329、2008年9月。」
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem,
"OSPF for IPv6", RFC 5340, July 2008.
[OSPFV3] ColtunとR.とファーガソンとD.とMoy、J.とA.Lindem、「IPv6"、RFC5340、2008年7月のためのOSPF。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Chen, et al. Standards Track [Page 15] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[15ページ]相互、Te2009年1月
[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.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun,
"The OSPF Opaque LSA Option", RFC 5250, July 2008.
2008年7月の[RFC5250]バーガーとL.とBryskinとI.とジニン、A.とR.Coltun、「OSPFの不明瞭なLSAオプション」RFC5250。
8.2. Informative References
8.2. 有益な参照
[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)について議定書の中で述べます」、RFC4271、2006年1月。
[BRPC] Vasseur, JP., Ed., Zhang, R., Bitar, N., and 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.、Bitar、N.、およびJL。 ル・ルー、「計算する中で相互ドメイン交通工学ラベル最も脆い後方の再帰的なPCEベースの計算(BRPC)手順は経路を切り換えました」、処理中の作業、2008年4月。
[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.
[相互、Te REQ、]、エドチャン、R.、J.-P。 Vasseur、エド「MPLS相互自律システム(AS)交通は(Te)要件を設計すること」でのRFC4216、2005年11月。
[L1VPN-OSPF-AD] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN
Auto-Discovery", RFC 5252, July 2008.
[L1VPN-OSPF-西暦] BryskinとI.とL.バーガー、「OSPFベースの層1のVPN自動発見」、RFC5252、2008年7月。
[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)ベースの構造」、RFC4655、2006年8月。
[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-経路]Vasseur(JP)、エド、Ayyangar、A.、エドR.チャン、「相互ドメイン交通工学(Te)ラベルを設立するための1ドメインあたり1つの経路計算方法が経路(LSPs)を切り換えました」、RFC5152、2月2008
Chen, et al. Standards Track [Page 16] RFC 5392 OSPF Extensions for Inter-AS TE January 2009
チェン、他 規格がRFC5392OSPF拡張子を追跡する、[16ページ]相互、Te2009年1月
Authors' Addresses
作者のアドレス
Mach(Guoyi) Chen Huawei Technologies Co., Ltd. KuiKe Building, No.9 Xinxi Rd. Hai-Dian District Beijing, 100085 P.R. China
マッハ(Guoyi)チェンHuawei技術株式会社KuiKeビル、No.9Xinxi通り Hai-ダイアンDistrict100085P.R.北京(中国)
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
RenhaiチャンHuawei技術株式会社KuiKeビル、No.9Xinxi通り Hai-ダイアンDistrict100085P.R.北京(中国)
EMail: zhangrenhai@huawei.com
メール: zhangrenhai@huawei.com
Xiaodong Duan China Mobile 53A,Xibianmennei Ave,Xunwu District Beijing, China
シャオドンDuan中国のモバイル53A、Xibianmennei Ave、Xunwu District中国北京
EMail: duanxiaodong@chinamobile.com
メール: duanxiaodong@chinamobile.com
Chen, et al. Standards Track [Page 17]
チェン、他 標準化過程[17ページ]
一覧
スポンサーリンク
