Network Working Group M. Chen
Request for Comments: 5392 R. Zhang
Category: Standards Track Huawei Technologies Co., Ltd.
X. Duan
China Mobile
January 2009
Network Working Group M. Chen
Request for Comments: 5392 R. Zhang
Category: Standards Track Huawei Technologies Co., Ltd.
X. Duan
China Mobile
January 2009
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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.
本文档描述了OSPF版本2和3协议的扩展，以支持多个自治系统（ASE）的多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程（TE）。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.
不支持本文件中提议或定义的从一个内部到另一个的洪水信息。
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. 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
[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]定义了OSPF协议[OSPF]的扩展，以支持区域内流量工程（TE）。扩展提供了一种对网络中启用TE的链路（TE链路）的TE信息进行编码的方法，并在一个区域内传播该信息。类型10不透明链路状态播发（LSA）[RFC5250]用于承载此类TE信息。[OSPF-TE]中定义了两个顶级类型长度值（TLV）：路由器地址TLV和链路TLV。链路TLV有几个嵌套的子TLV，用于描述TE链路的TE属性。
[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，称为区域内TE LSA，用于公布TE信息。[OSPF-V3-TE]使用“OSPF的流量工程扩展”[OSPF-TE]作为TLV定义的基础，并定义了一些新的TLV和子TLV，以将TE功能扩展到IPv6网络。
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.
建立跨多个自治系统（ASE）的多协议标签交换流量工程（MPLS-TE）标签交换路径（LSP）的要求在[INTER-AS-TE-REQ]中描述。如[INTER-As-TE-REQ]中所述，方法应提供计算跨越多个ASE的路径的能力。因此，可以是前端标签交换路由器（LSR）、AS边界路由器（ASBR）或路径计算元素[PCE]的路径计算实体不仅需要知道AS内的链路的TE信息，还需要知道连接到其他AS的链路的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.
在本文件中，定义了两个新的独立LSA，分别为OSPFv2和OSPFv3发布AS间TE信息，并在现有链路TLV中添加了三个新的子TLV，以扩展AS间流量工程的TE能力。详细定义和程序将在以下章节中讨论。
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内宣传任何其他额外信息的任何机制。有关本工作的非目标的完整列表，请参见第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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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]中所述，在建立穿越多个As的INTER-As-TE LSP的情况下，路径消息[RFC3209]可以在显式路由对象（ERO）中包括以下元素，以便描述LSP的路径：
- a set of AS numbers as loose hops; and/or
- 一组数字，如松散的啤酒花；和/或
- a set of LSRs including ASBRs as loose hops.
- 一组LSR，包括作为松散跃点的ASBR。
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间路径的方法。每域方法[PD-PATH]一次确定一个域的路径。反向递归方法[BRPC]使用PCE之间的协作来确定最佳域间路径。
The sections that follow examine how inter-AS TE link information could be useful in both cases.
接下来的部分将研究在这两种情况下，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].
需要注意的是，本文件并未对互联网中ASE使用的保密性和可扩展性假设进行任何更改。特别是，本文件符合[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 没有试图将TE信息从一个AS内部分发到另一个AS。
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 ASE之间不交换私人信息。
o No OSPF adjacencies are formed on the inter-AS link.
o 在AS间链路上不形成OSPF邻接。
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链接的信息。因此，这些扩展解决了与L1VPN自动发现[L1VPN-OSPF-AD]完全不同的问题，L1VPN-OSPF-AD定义了如何在OSPF-TE中公布有关客户边缘（CE）设备和提供商边缘（PE）设备之间链路的TE信息以及CE-PE链路的自动发现信息。本文件与[L1VPN-OSPF-AD]之间没有重叠。
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:
在为MPLS-TE LSP确定AS间路径的每域方法中，当作为AS入口点的LSR从上游AS接收到带有ERO的path消息，其中ERO包含作为AS编号的下一跳时，它需要找到哪个LSR（ASBR）在本地AS中，连接到下游AS，以便它可以计算本地AS中的一个LSR的TE LSP段，并将路径消息转发给它，从而转发到下一个AS。有关示例，请参见图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:Inter 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.
该图显示了三个ASE（AS1、AS2和AS3）和十二个LSR（R1到R12）。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.
如果计划从R1到R12建立AS间TE LSP，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）中选择，并且它需要知道其中哪一个提供到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的入口ASBR（比如R9），则R5需要知道其出口ASBR中的哪个具有连接到R9的TE链路。由于可能有多个ASBR连接到R9（本例中为R7和R8），因此R5还需要知道AS TE间链路的TE属性，以便选择正确的退出ASBR。
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 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的所有AS-TE链接列表。
o TE properties of each inter-AS TE link.
o 每个inter AS TE链路的TE属性。
o AS number of the neighboring AS to which each inter-AS TE link is connected.
o 每个AS-TE链路所连接的相邻AS的数量。
o Identity (TE Router ID) of the neighboring ASBR to which each inter-AS TE link is connected.
o 每个AS-TE链路连接到的相邻ASBR的标识（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), 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（或为ASBR提供计算服务的PCE）在入口点ASBR处如何需要此信息，但在整个本地也需要此信息，就好像路径计算功能完全分布在本地AS中的LSR之间一样，例如，为了支持具有起点的LSPAS内的（入口节点）。
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]定义了一种基于PCE的TE LSP计算方法（称为反向递归路径计算），用于计算最优域间约束MPLS-TE或GMPLS LSP。在这种路径计算方法中，假设在计算开始之前选择一组特定的遍历域（ASE）。域（i）中的每个下游PCE向其域（i-1）中的上游邻居PCE返回潜在路径的多点到点树。每个树由从位于域（i）中的所有边界节点到目的地的路径集组成，其中每个路径满足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需要选择边界节点（即ASBR），以从上游AS提供连接。为了能够关联一个PCE向其邻居提供的路径树，需要参考每个路径的ASBR的标识，因此PCE必须知道任何AS TE间链路到达的远程ASBR的标识，并且为了仅在树中提供合适的路径，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:Inter 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).
该图显示了三个ASE（AS1、AS2和AS3）、三个PCE（PCE1、PCE2和PCE3）和十二个LSR（R1到R12）。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 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.
如果计划从R1到R12建立AS-TE间LSP，则假定选择了经过的域：AS1->AS2->AS3，PCE链为：PCE1->PCE2->PCE3。首先，来自路径计算客户端（R1）的路径计算请求由PCE1和PCE2沿着PCE链中继到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.
因此，为了支持反向递归路径计算，需要第2.2节中列出的相同信息。每个AS-TE链路所连接的相邻AS的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到另一个AS的TE信息分发机制，未为AS之外的目的地分发任何形式的TE可达性信息，未更改PCE架构或使用，未建议或推荐任何形式的TE聚合，并且不会在ASE之间提供私人信息。见第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.
本文档中定义的扩展允许通过使用两种新类型的LSA（称为inter-AS-TE-v2 LSA和inter-AS-TE-v3 LSA）轻松识别inter-AS-TE链接广告。将三个新的子TLV添加到链路TLV，以承载关于相邻AS和远程ASBR的信息。
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操作所需的所有信息。
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间链路的广告，本文件定义了一种新的不透明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.
如果泛洪范围限制在ASBR所属的单个IGP区域内，则AS TE链路间广告应在类型10不透明LSA[RFC5250]中进行，或者如果信息旨在到达AS中的所有路由器（包括区域边界路由器、ASBR和PCE），则可在类型11不透明LSA[RFC5250]中进行。使用类型10（范围为区域）或类型11（范围为区域）不透明LSA之间的选择是一个同样广泛的策略选择，并且应在支持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]中定义的不透明LSA的链路状态ID分为两部分。其中一个是不透明类型（8位），另一个是不透明ID（24位）。AS-TE-v2内部LSA不透明类型的值为6，且已由IANA指定（见第6.1节）。Inter-AS-TE-v2 LSA的不透明ID是用于唯一标识流量工程LSA的任意值。链接状态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.
AS-TE-v2 LSA内部TLV的格式与OSPF-TE中使用的格式相同。TLV的有效载荷由一个或多个嵌套类型/长度/值三元组组成。第3.2节描述了专门用于AS TE链路间广告的新子TLV。
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).
在本文档中，为OSPFv3 AS-TE链接广告定义了一种新的LS类型。新的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-type字段的高阶三位编码LSA的一般属性，被称为U位、S2位和S1位[OSPFv3]。LS类型的其余部分携带LSA功能代码。
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.
U位始终设置为1，以指示OSPFv3路由器必须在其定义的泛洪范围内泛洪LSA，即使它不识别LS类型。
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的泛洪范围。对于内部AS-TE-v3-LSA，S2和S1位应设置为01，以指示泛洪范围将限于ASBR所属的单个IGP区域内，但如果信息应到达AS中的所有路由器（包括区域边界路由器、ASBR和PCE），则可设置为10。使用01或10之间的选择是网络范围的策略选择，在支持AS TE间链路广告的ASBR实现中应提供配置控制。
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的链路状态ID是用于唯一标识流量工程LSA的任意值。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.
AS-TE-v3 LSA内部的TLV与[OSPF-v3-TE]中定义的格式和语义相同。第3.2节描述了专门用于AS TE链路间广告的新子TLV。
Both the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA contain one top level TLV:
跨AS-TE-v2 LSA和跨AS-TE-v3 LSA都包含一个顶级TLV：
2 - Link TLV
双链路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.
对于AS-TE-v2间LSA，该TLV在[OSPF-TE]中定义，对于AS-TE-v3间LSA，该TLV在[OSPF-v3-TE]中定义。本TLV中携带的子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.
链路TLV描述单个链路并由一组子TLV组成。在[OSPF-TE]和[OSPF-v3-TE]中分别定义了要包含在Inter-AS-TE-v2 LSA和Inter-AS-TE-v3 LSA的链路TLV中的子TLV，子TLV的列表可以由其他文件扩展。但是，本文件定义了以下例外情况。
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.
链路ID子TLV[OSPF-TE]不得用于内部AS-TE-v2 LSA的链路TLV中，且相邻ID子TLV[OSPF-V3-TE]不得用于内部AS-TE-V3 LSA的链路TLV中。鉴于OSPF是IGP，且仅应在同一路由域中的路由器之间使用，OSPF特定链路ID和邻居ID子TLV不适用于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通过包含本文件中定义并在后续章节中描述的以下新子TLV来识别。
21 - Remote AS Number sub-TLV
21-远程AS编号子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.
远程AS编号子TLV必须包括在Inter-AS-TE-v2 LSA和Inter-AS-TE-v3 LSA的链路TLV中。Inter-AS-TE-v2 LSA和Inter-AS-TE-v3 LSA的链路TLV中应至少包括IPv4远程ASBR ID子TLV和IPv6远程ASBR ID子TLV中的一个。注意，可以将IPv6远程ASBR ID子TLV包括在Inter-AS-TE-v2 LSA的链路TLV中，并将IPv4远程ASBR ID子TLV包括在Inter-AS-TE-v3 LSA的链路TLV中，因为子TLV指的ASBR与使用OSPF LSA的寻址范围不同（即不同的AS）。
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.
定义了一个新的子TLV，即远程AS编号子TLV，以便在发布AS间链路时将其包含在链路TLV中。远程AS编号子TLV指定播发链接所连接的相邻AS的AS编号。在播发AS TE间链路的链路TLV中需要远程AS编号子TLV。
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:
远程AS编号子TLV为TLV类型21（见第6.2节），长度为四个八位字节。格式如下:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
远程AS编号字段有4个八位字节。当AS编号仅使用两个八位字节时，如在当前部署中，左（高阶）两个八位字节必须设置为零。
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间链路时，链路TLV中可以包括一个新的子TLV，称为IPv4远程ASBR ID子TLV。IPv4远程ASBR ID子TLV指定播发的AS间链路连接到的远程ASBR的IPv4标识符。这可以是远程ASBR的任何稳定且可路由的IPv4地址。建议使用路由器地址TLV[OSPF-TE]中指定的TE路由器地址TE路由器ID。
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远程ASBR ID子TLV为TLV类型22（见第6.2节），长度为四个八位字节。其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote 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播发中，如果相邻ASBR具有IPv4地址，则必须包括IPv4远程ASBR ID子TLV。如果相邻ASBR没有IPv4地址（甚至没有IPv4 TE路由器ID），则必须包含IPv6远程ASBR ID子TLV。IPv4远程ASBR ID子TLV和IPv6远程ASBR ID子TLV可能都存在于OSPFv2或OSPFv3中的链路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间链路时，链路TLV中可以包括一个新的子TLV，称为IPv6远程ASBR ID子TLV。IPv6远程ASBR ID子TLV指定播发的AS间链路连接到的远程ASBR的标识符。这可以是远程ASBR的任何稳定、可路由和全局IPv6地址。建议使用IPv6路由器地址[OSPF-V3-TE]中指定的IPv6路由器地址中指定的TE路由器IPv6地址IPv6 TE路由器ID。
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远程ASBR ID子TLV为TLV类型24（见第6.2节），长度为16个八位字节。其格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote ASBR ID (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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播发中，如果相邻ASBR具有IPv6地址，则必须包括IPv6远程ASBR ID子TLV。如果相邻ASBR没有IPv6地址，则必须包含IPv4远程ASBR ID子TLV。IPv4远程ASBR ID子TLV和IPv6远程ASBR ID子TLV可能都存在于OSPFv2或OSPFv3中的链路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 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].
当在AS间链路上启用TE且链路启动时，ASBR应使用OSPF-TE[OSPF-TE]的正常程序播发此链路。当链接关闭或链接上的TE被禁用时，ASBR应撤回广告。当链路的TE参数发生变化时（例如，当可用带宽发生变化时），ASBR应重新公布链路，但ASBR必须采取预防措施防止过度重新公布，如[OSPF-TE]中所述。
Hellos MUST NOT be exchanged over the inter-AS link, and consequently, an OSPF adjacency MUST NOT be formed.
HELLO不能在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.
公布的信息来自ASBR对链路TE能力的了解、ASBR对链路当前状态和使用情况的了解以及ASBR对远程AS号码和远程ASBR TE路由器ID的配置。
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.
传统路由器接收到内部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链路每一端的lsr发射描述链路的lsa。然后，LSR中的数据库有两个条目（一个是本地生成的，另一个是来自对等方的）
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.
描述链接的不同“方向”。这使得约束最短路径优先（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.
在我们这里考虑的情况下（即，TE链路到另一AS），根据定义，没有IGP对等，因此没有双向TE链路信息。为了让CSPF路由计算实体将链路作为候选路径，我们必须找到一种方法，将描述其（双向）TE属性的LSA获取到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.
这是通过ASBR在其AS内部发布关于TE链接到下一个AS的两个方向的信息来实现的。ASBR通常会生成一个LSA，描述链路的自己一侧；这里，我们在另一个AS的边缘为ASBR设置了“代理”，并生成一个额外的LSA，该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信息的链接需要广告；i、 例如，链路类型、远程AS编号和远程ASBR ID。能够处理AS-TE链路广告的路由器或PCE不应使用此类链路来计算从AS到远程ASBR的路径，然后通过另一个TE链路立即重新进入AS。此类路径将构成极为罕见的情况，并且不应被允许，除非由于路由器或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.
尽管此信息的来源不在本文档的范围内，但它可能是ASBR的配置要求，TE链接的其他本地属性也是如此。此外，在使用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 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.
ASE之间没有信息交换，ASE之间的OSPF安全关系也没有变化。特别是，由于在AS间链路上没有形成OSPF邻接，因此ASE之间不需要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.
值得注意的是，在我们正在考虑的场景中，两个ASBR之间可能存在边界网关协议（BGP）对等，这可用于检测配置中的不一致性（例如，最初提供信息的管理部门可能在撒谎，或者操作员出现了一些手动错误配置或错误）。例如，如果在BGP OPEN[BGP]中接收到不同的远程AS号码根据本地配置到OSPF-TE中的数据，如我们在此处所述，则应应用本地策略来确定是向运营商发出潜在错误配置警报，还是抑制as-TE链路的OSPF广告。此外，请注意，如果使用BGP来交换第4.1节所述的TE信息，则as-BGP-se应使用[BGP]中所述的机制保护会话，以提供身份验证和完整性检查。
IANA has made the following allocations from registries under its control.
IANA已从其控制下的登记处进行了以下分配。
IANA has assigned a new Opaque LSA type (6) to Inter-AS-TE-v2 LSA.
IANA已将一种新的不透明LSA类型（6）分配给Inter-AS-TE-v2 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。
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）流量工程TLV”注册表和子注册表“TE链路TLV中的子TLV类型”。IANA分配了三个新的子TLV，如下所示（详情见第3.3节）：
Value Meaning
价值意义
21 Remote AS Number sub-TLV
21远程AS编号子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
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.
作者感谢Adrian Farrel、Acee Lindem、JP Vasseur、Dean Cheng和Jean-Louis Le Roux对本文件的审查和评论。
[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.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，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]Ishiguro，K.，Manral，V.，Davey，A.，和A.Lindem，Ed.，“OSPF版本3的流量工程扩展”，RFC 53292008年9月。
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFV3]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5250]Berger，L.，Bryskin，I.，Zinin，A.，和R.Coltun，“OSPF不透明LSA选项”，RFC 5250，2008年7月。
[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.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 42712006年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.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“基于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.
[INTER-AS-TE-REQ]Zhang，R.，Ed.，和J.-P.Vasseur，Ed.，“MPLS自治系统间（AS）流量工程（TE）要求”，RFC 42162005年11月。
[L1VPN-OSPF-AD] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-Discovery", RFC 5252, July 2008.
[L1VPN-OSPF-AD]Bryskin，I.和L.Berger，“基于OSPF的第1层VPN自动发现”，RFC 5252，2008年7月。
[PCE] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[PCE]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年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-PATH]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
Authors' Addresses
作者地址
Mach(Guoyi) Chen Huawei Technologies Co., Ltd. KuiKe Building, No.9 Xinxi Rd. Hai-Dian District Beijing, 100085 P.R. China
中国北京市海淀区新西路9号魁克大厦Mach（国一）陈华为技术有限公司，邮编100085
EMail: mach@huawei.com
EMail: mach@huawei.com
Renhai Zhang Huawei Technologies Co., Ltd. KuiKe Building, No.9 Xinxi Rd. Hai-Dian District Beijing, 100085 P.R. China
中国北京市海淀区新西路9号奎克大厦华为技术有限公司人海张100085
EMail: zhangrenhai@huawei.com
EMail: zhangrenhai@huawei.com
Xiaodong Duan China Mobile 53A,Xibianmennei Ave,Xunwu District Beijing, China
中国移动北京寻乌区西边门内大街53A小东段
EMail: duanxiaodong@chinamobile.com
EMail: duanxiaodong@chinamobile.com