Internet Engineering Task Force (IETF) A. Malis, Ed.
Request for Comments: 6827 Verizon Communications
Obsoletes: 5787 A. Lindem, Ed.
Updates: 5786 Ericsson
Category: Standards Track D. Papadimitriou, Ed.
ISSN: 2070-1721 Alcatel-Lucent
January 2013
Internet Engineering Task Force (IETF) A. Malis, Ed.
Request for Comments: 6827 Verizon Communications
Obsoletes: 5787 A. Lindem, Ed.
Updates: 5786 Ericsson
Category: Standards Track D. Papadimitriou, Ed.
ISSN: 2070-1721 Alcatel-Lucent
January 2013
Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
OSPFv2协议的自动交换光网络（ASON）路由
Abstract
摘要
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
ITU-T定义了运行自动交换光网络（ASON）的体系结构和要求。
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Networks (OTNs), and lambda switching optical networks.
通用多协议标签交换（GMPLS）协议套件旨在为一系列网络技术提供控制平面。这些包括光网络，如时分复用（TDM）网络，包括同步光网络/同步数字体系（SONET/SDH）、光传输网络（OTN）和lambda交换光网络。
The requirements for GMPLS routing to satisfy the requirements of ASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
其他文件中提供了满足ASON路由要求的GMPLS路由要求以及对现有GMPLS路由协议的评估。本文档定义了OSPFv2链路状态路由协议的扩展，以满足ASON中的路由要求。
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786.
请注意，这项工作的范围是RFC 4258和RFC 4652中表达的要求和评估，以及编写这些文件时最新的ITU-T建议。如果修订了ITU-T建议，或者在RFC 4258的修订版中引入了新的要求，则可能需要对本工作进行未来的扩展或修订。本文件淘汰RFC 5787并更新RFC 5786。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6827.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6827.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. Routing Areas, OSPF Areas, and Protocol Instances ...............5
3. Terminology and Identification ..................................6
4. Reachability ....................................................7
5. Link Attribute ..................................................8
5.1. Local Adaptation ...........................................8
5.2. Bandwidth Accounting .......................................9
6. Routing Information Scope .......................................9
6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) .9
6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) ...11
7. Routing Information Dissemination ..............................11
7.1. Import/Export Rules .......................................12
7.2. Loop Prevention ...........................................12
7.2.1. Inter-RA Export Upward/Downward Sub-TLVs ...........13
7.2.2. Inter-RA Export Upward/Downward Sub-TLV Processing .13
8. OSPFv2 Scalability .............................................14
9. Security Considerations ........................................15
10. IANA Considerations ...........................................15
10.1. Sub-TLVs of the Link TLV .................................15
10.2. Sub-TLVs of the Node Attribute TLV .......................16
10.3. Sub-TLVs of the Router Address TLV .......................16
11. Management Considerations .....................................17
11.1. Routing Area (RA) Isolation ..............................17
11.2. Routing Area (RA) Topology/Configuration Changes .........17
12. Comparison to Requirements in RFC 4258 ........................17
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................25
14. Acknowledgements ..............................................26
14.1. RFC 5787 Acknowledgements ................................26
Appendix A. ASON Terminology ......................................27
Appendix B. ASON Routing Terminology ..............................28
Appendix C. Changes from RFC 5787 .................................29
1. Introduction ....................................................4
1.1. Conventions Used in This Document ..........................5
2. Routing Areas, OSPF Areas, and Protocol Instances ...............5
3. Terminology and Identification ..................................6
4. Reachability ....................................................7
5. Link Attribute ..................................................8
5.1. Local Adaptation ...........................................8
5.2. Bandwidth Accounting .......................................9
6. Routing Information Scope .......................................9
6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) .9
6.2. Reachability Advertisement (Local TE Router ID Sub-TLV) ...11
7. Routing Information Dissemination ..............................11
7.1. Import/Export Rules .......................................12
7.2. Loop Prevention ...........................................12
7.2.1. Inter-RA Export Upward/Downward Sub-TLVs ...........13
7.2.2. Inter-RA Export Upward/Downward Sub-TLV Processing .13
8. OSPFv2 Scalability .............................................14
9. Security Considerations ........................................15
10. IANA Considerations ...........................................15
10.1. Sub-TLVs of the Link TLV .................................15
10.2. Sub-TLVs of the Node Attribute TLV .......................16
10.3. Sub-TLVs of the Router Address TLV .......................16
11. Management Considerations .....................................17
11.1. Routing Area (RA) Isolation ..............................17
11.2. Routing Area (RA) Topology/Configuration Changes .........17
12. Comparison to Requirements in RFC 4258 ........................17
13. References ....................................................25
13.1. Normative References .....................................25
13.2. Informative References ...................................25
14. Acknowledgements ..............................................26
14.1. RFC 5787 Acknowledgements ................................26
Appendix A. ASON Terminology ......................................27
Appendix B. ASON Routing Terminology ..............................28
Appendix C. Changes from RFC 5787 .................................29
The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including SONET/SDH, Optical Transport Networks (OTNs), and lambda switching optical networks.
通用多协议标签交换（GMPLS）[RFC3945]协议套件旨在为一系列网络技术提供控制平面。其中包括光网络，如时分复用（TDM）网络，包括SONET/SDH、光传输网络（OTN）和lambda交换光网络。
The ITU-T defines the architecture of the Automatically Switched Optical Network (ASON) in [G.8080].
ITU-T在[G.8080]中定义了自动交换光网络（ASON）的体系结构。
[RFC4258] describes the routing requirements for the GMPLS suite of routing protocols to support the capabilities and functionality of ASON control planes identified in [G.7715] and in [G.7715.1].
[RFC4258]描述了GMPLS路由协议套件的路由要求，以支持[G.7715]和[G.7715.1]中确定的ASON控制平面的能力和功能。
[RFC4652] evaluates the IETF Link State routing protocols against the requirements identified in [RFC4258]. Section 7.1 of [RFC4652] summarizes the capabilities to be provided by OSPFv2 [RFC2328] in support of ASON routing. This document describes the OSPFv2 specifics for ASON routing.
[RFC4652]根据[RFC4258]中确定的要求评估IETF链路状态路由协议。[RFC4652]第7.1节总结了OSPFv2[RFC2328]为支持ASON路由而提供的功能。本文档描述了ASON路由的OSPFv2细节。
Multi-layer transport networks are constructed from multiple networks of different technologies operating in a client-server relationship. The ASON routing model includes the definition of routing levels that provide scaling and confidentiality benefits. In multi-level routing, domains called routing areas (RAs) are arranged in a hierarchical relationship. Note that as described in [RFC4652], there is no implied relationship between multi-layer transport networks and multi-level routing. The multi-level routing mechanisms described in this document work for both single-layer and multi-layer networks.
多层传输网络由在客户机-服务器关系中运行的不同技术的多个网络构成。ASON路由模型包括提供扩展和保密优势的路由级别定义。在多级路由中，称为路由区域（RAs）的域以层次关系排列。注意，如[RFC4652]所述，多层传输网络和多级路由之间没有隐含的关系。本文档中描述的多级路由机制适用于单层和多层网络。
Implementations may support a hierarchical routing topology (multi-level) for multiple transport network layers and/or a hierarchical routing topology for a single transport network layer.
实现可支持用于多个传输网络层的分层路由拓扑（多级）和/或用于单个传输网络层的分层路由拓扑。
This document describes the processing of the generic (technology-independent) link attributes that are defined in [RFC3630], [RFC4202], and [RFC4203] and that are extended in this document. As described in Section 5.2, technology-specific traffic engineering attributes and their processing may be defined in other documents that complement this document.
本文档描述了[RFC3630]、[RFC4202]和[RFC4203]中定义并在本文档中扩展的通用（独立于技术的）链路属性的处理。如第5.2节所述，特定于技术的交通工程属性及其处理可在补充本文件的其他文件中定义。
Note that this work is scoped to the requirements and evaluation expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of [RFC4258].
请注意，这项工作的范围是[RFC4258]和[RFC4652]中表达的要求和评估，以及编写这些文件时最新的ITU-T建议。如果修订了ITU-T建议，或者在[RFC4258]的修订版中引入了新的要求，则可能需要对本工作进行未来的扩展或修订。
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]中所述进行解释。
The reader is assumed to be familiar with the terminology and requirements developed in [RFC4258] and the evaluation outcomes described in [RFC4652].
假定读者熟悉[RFC4258]中制定的术语和要求以及[RFC4652]中描述的评估结果。
General ASON terminology is provided in Appendix A. ASON routing terminology is described in Appendix B.
一般ASON术语见附录A。ASON路由术语见附录B。
An ASON routing area (RA) represents a partition of the transport plane, and its identifier is used within the control plane as the representation of this partition.
ASON路由区域（RA）表示传输平面的分区，其标识符在控制平面内用作该分区的表示。
RAs are hierarchically contained: a higher-level (parent) RA contains lower-level (child) RAs that in turn MAY also contain RAs. Thus, RAs contain RAs that recursively define successive hierarchical RA levels. Routing information may be exchanged between levels of the RA hierarchy, i.e., Level N+1 and N, where Level N represents the RAs contained by Level N+1. The links connecting RAs may be viewed as external links (inter-RA links), and the links representing connectivity within an RA may be viewed as internal links (intra-RA links). The external links to an RA at one level of the hierarchy may be internal links in the parent RA. Intra-RA links of a child RA MAY be hidden from the parent RA's view [RFC4258].
RAs是分层包含的：较高级别（父级）的RA包含较低级别（子级）的RA，而较低级别（子级）的RA也可能包含RAs。因此，RA包含递归定义连续层次RA级别的RA。路由信息可以在RA层次的级别之间交换，即，级别N+1和N，其中级别N表示由级别N+1包含的RAs。连接RAs的链路可被视为外部链路（RA间链路），并且表示RA内的连接性的链路可被视为内部链路（RA内链路）。层次结构的一个级别上到RA的外部链接可能是父RA中的内部链接。子RA的RA内部链接可以从父RA的视图中隐藏[RFC4258]。
An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON RA levels does not map to the hierarchy of OSPF areas. Instead, successive hierarchical levels of RAs MUST be represented by separate instances of the protocol. Thus, inter-level routing information exchange (as described in Section 7) involves the export and import of routing information between protocol instances.
ASON RA可以映射到OSPF区域，但ASON RA级别的层次结构不映射到OSPF区域的层次结构。相反，RAs的连续分层级别必须由协议的单独实例表示。因此，层间路由信息交换（如第7节所述）涉及协议实例之间路由信息的导出和导入。
An ASON RA may therefore be identified by the combination of its OSPF Instance ID and its OSPF Area ID. With proper and careful network-wide configuration, this can be achieved using just the OSPF Area ID, and this process is RECOMMENDED in this document. These concepts are discussed in Section 7.
因此，可以通过其OSPF实例ID和OSPF区域ID的组合来识别ASON RA。通过适当和仔细的网络范围配置，可以仅使用OSPF区域ID来实现这一点，本文档中建议使用此过程。这些概念将在第7节中讨论。
A key ASON requirement is the support of multiple transport planes or layers. Each transport node has associated topology (links and reachability), which is used for ASON routing.
ASON的一个关键要求是支持多个传输平面或层。每个传输节点都有相关的拓扑（链路和可达性），用于ASON路由。
This section describes the mapping of key ASON entities to OSPF entities. Appendix A contains a complete glossary of ASON routing terminology.
本节描述关键ASON实体到OSPF实体的映射。附录A包含ASON路由术语的完整词汇表。
There are three categories of identifiers used for ASON routing (G.7715.1): transport-plane names, control-plane identifiers for components, and Signaling Communications Network (SCN) addresses. This section discusses the mapping between ASON routing identifiers and corresponding identifiers defined for GMPLS routing and how these support the physical (or logical) separation of transport-plane entities and control-plane components. GMPLS supports this separation of identifiers and planes.
ASON路由（G.7715.1）使用三类标识符：传输平面名称、组件控制平面标识符和信令通信网络（SCN）地址。本节讨论ASON路由标识符和为GMPLS路由定义的相应标识符之间的映射，以及它们如何支持传输平面实体和控制平面组件的物理（或逻辑）分离。GMPLS支持标识符和平面的分离。
In the context of OSPF Traffic Engineering (TE), an ASON transport node corresponds to a unique OSPF TE node. An OSPF TE node is uniquely identified by the TE Router Address TLV [RFC3630]. In this document, the TE Router Address is referred to as the TE Router ID. In GMPLS, TE router addresses are advertised as reachable in both the control and transport planes, see Section 4 below. Furthermore, the TE Router ID should not be confused with the OSPF Router ID that uniquely identifies an OSPF router within an OSPF routing domain [RFC2328] and is in a name space for control-plane components.
在OSPF流量工程（TE）的上下文中，ASON传输节点对应于唯一的OSPF TE节点。OSPF TE节点由TE路由器地址TLV[RFC3630]唯一标识。在本文件中，TE路由器地址被称为TE路由器ID。在GMPLS中，TE路由器地址在控制平面和传输平面上都是可到达的，见下文第4节。此外，TE路由器ID不应与OSPF路由器ID混淆，OSPF路由器ID唯一地标识OSPF路由域[RFC2328]内的OSPF路由器，并且位于控制平面组件的名称空间中。
The Router Address top-level TLV definition, processing, and usage are largely unchanged from [RFC3630]. This TLV specifies a stable OSPF TE node IP address, i.e., the IP address is always reachable when there is IP connectivity to the associated OSPF TE node.
路由器地址顶级TLV定义、处理和使用与[RFC3630]基本相同。该TLV指定了一个稳定的OSPF TE节点IP地址，即，当与相关OSPF TE节点存在IP连接时，该IP地址始终是可访问的。
ASON defines a Routing Controller (RC) as an entity that handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the Routing Database (RDB). ASON defines a Protocol Controller (PC) as an entity that handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI) and internal exchanges with the RC [RFC4258]. In this document, an OSPF router advertising ASON TE topology information will perform both the
ASON将路由控制器（RC）定义为一个实体，该实体通过在路由数据库（RDB）上操作来处理路由所需的（抽象）信息以及与对等RCs交换路由信息。ASON将协议控制器（PC）定义为根据信息交换的参考点（例如e-NNI、I-NNI）和与RC的内部交换来处理协议特定消息交换的实体[RFC4258]。在本文档中，公布ASON TE拓扑信息的OSPF路由器将执行
functions of the RC and PC. The OSPF routing domain comprises the control plane, and each OSPF router is uniquely identified by its OSPF Router ID [RFC2328].
RC和PC的功能。OSPF路由域包括控制平面，每个OSPF路由器由其OSPF路由器ID[RFC2328]唯一标识。
In ASON, reachability information describes the set of endpoints that are reachable by the associated node in the transport plane. Reachability information represents transport-plane resources, e.g., an optical cross-connect interface, and uses transport-plane identifiers.
在ASON中，可达性信息描述传输平面中关联节点可访问的端点集。可达性信息表示传输平面资源，例如，光交叉连接接口，并使用传输平面标识符。
In order to advertise blocks of reachable address prefixes, a summarization mechanism is introduced that is based on the techniques described in [RFC5786]. For ASON reachability advertisement, blocks of reachable address prefixes are advertised together with the associated transport-plane node. The transport-plane node is identified in OSPF TE Link State Advertisements (LSAs) by its TE Router ID, as discussed in Section 6.
为了公布可到达地址前缀块，引入了一种基于[RFC5786]中描述的技术的摘要机制。对于ASON可达性通告，可到达地址前缀块与相关联的传输平面节点一起通告。传输平面节点在OSPF TE链路状态通告（LSA）中通过其TE路由器ID标识，如第6节所述。
In order to support ASON reachability advertisement, the Node Attribute TLV defined in [RFC5786] is used to advertise the combination of a TE Router ID and its set of associated reachable address prefixes. The Node Attribute TLV can contain the following sub-TLVs:
为了支持ASON可达性播发，在[RFC5786]中定义的节点属性TLV用于播发TE路由器ID及其一组相关联的可达地址前缀的组合。节点属性TLV可以包含以下子TLV：
- Local TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786]
- 本地TE路由器ID子TLV：长度：4；在第6.2节-节点IPv4本地地址子TLV中定义：长度：变量；[RFC5786]-节点IPv6本地地址子TLV:长度：变量；[RFC5786]
A router may support multiple transport nodes as discussed in Section 6 and, as a result, may be required to advertise reachability separately for each transport node. As a consequence, it MUST be possible for the router to originate more than one TE LSA containing the Node Attribute TLV when used for ASON reachability advertisement.
如第6节所述，路由器可以支持多个传输节点，因此，可能需要为每个传输节点分别通告可达性。因此，当用于ASON可达性广告时，路由器必须能够发起多个包含节点属性TLV的TE LSA。
Hence, the Node Attribute TLV [RFC5786] advertisement rules are relaxed. A Node Attribute TLV MAY appear in more than one TE LSA originated by the RC when the RC is advertising reachability information for a different transport node identified by the Local TE Router sub-TLV (refer to Section 6.2).
因此，放宽了节点属性TLV[RFC5786]播发规则。当RC为本地TE路由器子TLV标识的不同传输节点发布可达性信息时，节点属性TLV可能出现在由RC发起的多个TE LSA中（参考第6.2节）。
As specified in [RFC3630], TE-advertised router addresses are also advertised as reachable in the control plane and are therefore also valid identifiers in the ASON SCN name space.
如[RFC3630]中所述，TE播发的路由器地址也在控制平面中播发为可到达，因此也是ASON SCN名称空间中的有效标识符。
With the exception of local adaptation (described below), the mapping of link attributes and characteristics to OSPF TE Link TLV sub-TLVs is unchanged [RFC4652]. OSPF TE Link TLV sub-TLVs are described in [RFC3630] and [RFC4203]. Advertisement of this information SHOULD be supported on a per-layer basis, i.e., one TE LSA per unique switching capability and bandwidth granularity combination.
除本地适配（如下所述）外，链路属性和特性到OSPF TE链路TLV子TLV的映射保持不变[RFC4652]。[RFC3630]和[RFC4203]中描述了OSPF TE链路TLV子TLV。应在每层的基础上支持此信息的公布，即，每个唯一交换能力和带宽粒度组合一个TE LSA。
Local adaptation is defined as a TE link attribute (i.e., sub-TLV) that describes the cross/inter-layer relationships.
局部适配定义为描述跨层/层间关系的TE链路属性（即子TLV）。
The Interface Switching Capability Descriptor (ISCD) TE Attribute [RFC4202] identifies the ability of the TE link to support cross-connection to another link within the same layer. When advertising link adaptation, it also identifies the ability to use a locally terminated connection that belongs to one layer as a data link for another layer (adaptation capability). However, the information associated with the ability to terminate connections within that layer (referred to as the termination capability) is advertised with the adaptation capability.
接口交换能力描述符（ISCD）TE属性[RFC4202]标识TE链路支持交叉连接到同一层内另一链路的能力。当广告链路适配时，它还识别使用属于一层的本地端接连接作为另一层的数据链路的能力（适配能力）。然而，与在该层内终止连接的能力（称为终止能力）相关联的信息通过自适应能力来公布。
For instance, a link between two optical cross-connects will contain at least one ISCD attribute describing the Lambda Switching Capable (LSC) switching capability. Conversely, a link between an optical cross-connect and an IP/MPLS Label Switching Router (LSR) will contain at least two ISCD attributes, one for the description of the LSC termination capability and one for the Packet Switching Capable (PSC) adaptation capability.
例如，两个光交叉连接之间的链路将包含至少一个描述Lambda交换能力（LSC）交换能力的ISCD属性。相反，光交叉连接和IP/MPLS标签交换路由器（LSR）之间的链路将包含至少两个ISCD属性，一个用于描述LSC终止能力，另一个用于分组交换能力（PSC）自适应能力。
In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a sub-TLV (type 15) of the top-level Link TLV (type 2) [RFC4203]. The adaptation and termination capabilities are advertised using two separate ISCD sub-TLVs within the same top-level Link TLV.
在OSPFv2中，接口交换能力描述符（ISCD）是顶级链路TLV（类型2）[RFC4203]的子TLV（类型15）。在同一顶级链路TLV内，使用两个单独的ISCD子TLV公布适配和终止能力。
An interface MAY have more than one ISCD sub-TLV, per [RFC4202] and [RFC4203]. Hence, the corresponding advertisements should not result in any compatibility issues.
根据[RFC4202]和[RFC4203]，一个接口可能有多个ISCD子TLV。因此，相应的广告不应导致任何兼容性问题。
GMPLS routing defines an ISCD that provides, among other things, the quantities of the maximum/minimum available bandwidth per priority for Label Switched Paths (LSPs). One or more ISCD sub-TLVs can be associated with an interface, per [RFC4202] and [RFC4203]. This information, combined with the Unreserved Bandwidth Link TLV sub-TLV [RFC3630], provides the basis for bandwidth accounting.
GMPLS路由定义了一个ISCD，它为标签交换路径（LSP）提供每个优先级的最大/最小可用带宽数量。根据[RFC4202]和[RFC4203]，一个或多个ISCD子TLV可与接口相关联。该信息与无保留带宽链路TLV sub TLV[RFC3630]相结合，为带宽计费提供了基础。
In the ASON context, additional information may be included when the representation and information in the other advertised fields are not sufficient for a specific technology, e.g., SDH. The definition of technology-specific information elements is beyond the scope of this document. Some technologies will not require additional information beyond what is already defined in [RFC3630], [RFC4202], and [RFC4203].
在ASON上下文中，当其他广告字段中的表示和信息不足以用于特定技术（例如SDH）时，可以包括附加信息。技术特定信息元素的定义超出了本文件的范围。除[RFC3630]、[RFC4202]和[RFC4203]中已经定义的信息外，某些技术不需要其他信息。
For ASON routing, the control-plane component routing adjacency topology (i.e., the associated Protocol Controller (PC) connectivity) and the transport topology are not assumed to be congruent [RFC4258]. Hence, a single OSPF router (i.e., the PC) MUST be able to advertise on behalf of multiple transport-layer nodes. The OSPF routers are identified by OSPF Router ID, and the transport nodes are identified by TE Router ID.
对于ASON路由，控制平面组件路由邻接拓扑（即，相关协议控制器（PC）连接）和传输拓扑不被认为是一致的[RFC4258]。因此，单个OSPF路由器（即PC）必须能够代表多个传输层节点进行广告。OSPF路由器由OSPF路由器ID标识，传输节点由TE路由器ID标识。
The Router Address TLV [RFC3630] is used to advertise the TE Router ID associated with the advertising Routing Controller (RC). TE Router IDs for additional transport nodes are advertised through specification of the Local TE Router Identifier in the Local and Remote TE Router TE sub-TLV and the Local TE Router Identifier sub-TLV described in the sections below. These Local TE Router Identifiers are typically used as the local endpoints for TE LSPs terminating on the associated transport node.
路由器地址TLV[RFC3630]用于公布与公布路由控制器（RC）相关联的TE路由器ID。附加传输节点的TE路由器ID通过在本地和远程TE路由器TE子TLV中指定本地TE路由器标识符以及在以下各节中描述的本地TE路由器标识符子TLV来公布。这些本地TE路由器标识符通常用作在相关传输节点上终止的TE LSP的本地端点。
The use of multiple OSPF Routers to advertise TE information for the same transport node is not considered a required use case and is not discussed further in this document.
使用多个OSPF路由器为同一传输节点播发TE信息不被视为必要的用例，本文档中不再进一步讨论。
When an OSPF Router advertises on behalf of multiple transport nodes, the link endpoints cannot be automatically assigned to a single transport node associated with the advertising router. In this case, the local and remote transport nodes MUST be identified by TE Router ID to unambiguously specify the transport topology.
当OSPF路由器代表多个传输节点播发时，链路端点不能自动分配给与播发路由器关联的单个传输节点。在这种情况下，本地和远程传输节点必须由TE路由器ID标识，以明确指定传输拓扑。
For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Link TLV is introduced that defines the Local and Remote TE Router ID.
为此，引入了OSPFv2 TE LSA顶级链路TLV的新子TLV，该TLV定义了本地和远程TE路由器ID。
The Type field of the Local and Remote TE Router ID sub-TLV is assigned the value 10 (see Section 10). The Length field takes the value 8. The Value field of this sub-TLV contains 4 octets of the Local TE Router Identifier followed by 4 octets of the Remote TE Router Identifier. The value of the Local and Remote TE Router Identifier MUST NOT be set to 0.
本地和远程TE路由器ID子TLV的类型字段被分配值10（参见第10节）。长度字段的值为8。此子TLV的值字段包含本地TE路由器标识符的4个八位字节，后跟远程TE路由器标识符的4个八位字节。本地和远程TE路由器标识符的值不得设置为0。
The format of the Local and Remote TE Router ID sub-TLV is:
本地和远程TE路由器ID子TLV的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (10) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (10) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV if the OSPF router is advertising on behalf of one or more transport nodes having TE Router IDs different from the TE Router ID advertised in the Router Address TLV. For consistency, this sub-TLV MUST be included when OSPF is used for the advertisement of ASON information as described herein. If it is not included in a Link TLV, or if a value of 0 is specified for the Local or Remote TE Router Identifier, the Link TLV will not be used for transport-plane path computation. Additionally, the condition SHOULD be logged for possible action by the network operator.
如果OSPF路由器代表一个或多个具有不同于路由器地址TLV中公布的TE路由器ID的传输节点公布，则该子TLV必须作为顶级链路TLV的子TLV包括。为了一致性，当OSPF用于如本文所述的ASON信息的广告时，必须包括该子TLV。如果链路TLV中未包含该值，或者如果为本地或远程TE路由器标识符指定了值0，则链路TLV将不用于传输平面路径计算。此外，应记录该情况，以便网络运营商采取可能的行动。
Note: The Link ID sub-TLV identifies the other end of the link (i.e., Router ID of the neighbor for point-to-point links) [RFC3630]. When the Local and Remote TE Router ID sub-TLV is present, it MUST be used to identify local and remote transport node endpoints for the link and the Link-ID sub-TLV MUST be ignored. In fact, when the Local and Remote TE Router ID sub-TLV is specified, the Link-ID sub-TLV MAY be omitted. The Local and Remote TE Router ID sub-TLV, if specified, MUST only be specified once. If specified more than once, instances other than the first will be ignored and the condition SHOULD be logged for possible action by the network operator.
注：链路ID子TLV标识链路的另一端（即点到点链路的邻居路由器ID）[RFC3630]。当存在本地和远程TE路由器ID子TLV时，必须使用它来标识链路的本地和远程传输节点端点，并且必须忽略链路ID子TLV。事实上，当指定本地和远程TE路由器ID sub-TLV时，可以省略链路ID sub-TLV。如果指定了本地和远程TE路由器ID子TLV，则只能指定一次。如果多次指定，将忽略第一个以外的实例，并应记录该条件，以便网络运营商采取可能的措施。
When an OSPF router is advertising on behalf of multiple transport nodes, the routing protocol MUST be able to associate the advertised reachability information with the correct transport node.
当OSPF路由器代表多个传输节点进行广告时，路由协议必须能够将广告的可达性信息与正确的传输节点相关联。
For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Node Attribute TLV is introduced. This TLV associates the local prefixes (see above) to a given transport node identified by the TE Router ID.
为此，引入了OSPFv2 TE LSA顶级节点属性TLV的新子TLV。该TLV将本地前缀（见上文）与TE路由器ID标识的给定传输节点相关联。
The Type field of the Local TE Router ID sub-TLV is assigned the value 5 (see Section 10). The Length field takes the value 4. The Value field of this sub-TLV contains the Local TE Router Identifier encoded over 4 octets.
本地TE路由器ID子TLV的类型字段被分配值5（参见第10节）。“长度”字段的值为4。此子TLV的值字段包含通过4个八位字节编码的本地TE路由器标识符。
The format of the Local TE Router ID sub-TLV is:
本地TE路由器ID子TLV的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (5) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 (5) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV MUST be included as a sub-TLV of the top-level Node Attribute TLV if the OSPF router is advertising on behalf of one or more transport nodes having TE Router IDs different from the TE Router ID advertised in the Router Address TLV. For consistency, this sub-TLV MUST be included when OSPF is used for the advertisement of ASON information as described herein. If it is not included in a Node Attribute TLV, or if a value of 0 is specified for the Local TE Router Identifier, the Note Attribute TLV will not be used for determining ASON SCN reachability. Additionally, the condition SHOULD be logged for possible action by the network operator.
如果OSPF路由器代表一个或多个具有不同于路由器地址TLV中公布的TE路由器ID的传输节点公布，则该子TLV必须作为顶级节点属性TLV的子TLV包括。为了一致性，当OSPF用于如本文所述的ASON信息的广告时，必须包括该子TLV。如果节点属性TLV中未包含注释属性，或者如果为本地TE路由器标识符指定了值0，则注释属性TLV将不用于确定ASON SCN可达性。此外，应记录该情况，以便网络运营商采取可能的行动。
An ASON routing area (RA) represents a partition of the transport plane, and its identifier is used within the control plane as the representation of this partition. An RA may contain smaller RAs inter-connected by links. ASON RA levels do not map directly to OSPF areas. Rather, hierarchical levels of RAs are represented by separate OSPF protocol instances. However, it is useful to align the RA IDs and area ID in order to facilitate isolation of RAs as described in Section 11.1.
ASON路由区域（RA）表示传输平面的分区，其标识符在控制平面内用作该分区的表示。RA可以包含通过链路相互连接的较小RA。ASON RA级别不直接映射到OSPF区域。相反，RAs的分层级别由单独的OSPF协议实例表示。然而，如第11.1节所述，对齐RA ID和区域ID有助于隔离RA。
Routing Controllers (RCs) supporting multiple RAs disseminate information downward and upward in this ASON hierarchy. The vertical routing information dissemination mechanisms described in this section do not introduce or imply hierarchical OSPF areas. RCs supporting RAs at multiple levels are structured as separate OSPF instances with routing information exchange between levels described by import and export rules between these instances. The functionality described herein does not pertain to OSPF areas or OSPF Area Border Router (ABR) functionality.
支持多个RA的路由控制器（RCs）在此ASON层次结构中向下和向上传播信息。本节中描述的垂直路由信息传播机制不引入或暗示分层OSPF区域。在多个级别上支持RAs的RCs被构造为单独的OSPF实例，这些实例之间通过导入和导出规则描述的级别之间的路由信息交换。本文描述的功能不涉及OSPF区域或OSPF区域边界路由器（ABR）功能。
RCs supporting RAs disseminate information upward and downward in the hierarchy by importing/exporting routing information as TE LSAs. TE LSAs are area-scoped Opaque LSAs with Opaque type 1 [RFC3630]. The information that MAY be exchanged between adjacent levels includes the Router Address, Link, and Node Attribute top-level TLVs.
支持RAs的RCs通过将路由信息作为TE LSA导入/导出，在层次结构中向上和向下传播信息。TE LSA是不透明类型为1的区域范围不透明LSA[RFC3630]。可在相邻级别之间交换的信息包括路由器地址、链路和节点属性顶级TLV。
The imported/exported routing information content MAY be transformed, e.g., filtered or aggregated, as long as the resulting routing information is consistent. In particular, when more than one RC is bound to adjacent levels and both are allowed to import/export routing information, it is expected that these transformations are performed in a consistent manner. Definition of these policy-based mechanisms are outside the scope of this document.
导入/导出的路由信息内容可以被转换，例如，过滤或聚合，只要得到的路由信息是一致的。特别是，当一个以上的RC绑定到相邻级别，并且两个RC都被允许导入/导出路由信息时，这些转换应以一致的方式执行。这些基于策略的机制的定义不在本文件的范围内。
In practice, and in order to avoid scalability and processing overhead, routing information imported/exported downward/upward in the hierarchy is expected to include reachability information (see Section 4) and, upon strict policy control, link topology information.
实际上，为了避免可伸缩性和处理开销，在层次结构中向下/向上导入/导出的路由信息应包括可达性信息（参见第4节），并且在严格的策略控制下，还应包括链路拓扑信息。
When more than one RC is bound to an adjacent level of the ASON hierarchy and is configured to export routing information upward or downward, a specific mechanism is required to avoid looping of routing information. Looping is the re-advertisement of routing information into an RA that had previously advertised that routing information upward or downward into an upper or lower level RA in the ASON hierarchy. For example, without loop-prevention mechanisms, this could happen when the RC advertising routing information downward in the hierarchy is not the same one that advertises routing information upward in the hierarchy.
当多个RC绑定到ASON层次结构的相邻级别并配置为向上或向下导出路由信息时，需要一种特定的机制来避免路由信息的循环。循环是将路由信息重新播发到RA中，该RA先前向上或向下播发该路由信息到ASON层次结构中的上层或下层RA中。例如，如果没有环路预防机制，当层次结构中向下的RC广告路由信息与层次结构中向上的广告路由信息不同时，可能会发生这种情况。
The Inter-RA Export sub-TLVs can be used to prevent the re-advertisement of OSPF TE routing information into an RA that previously advertised that information. The type value 13 (see Section 10) will indicate that the associated routing information has been exported downward. The type value 12 (see Section 10) will indicate that the associated routing information has been exported upward. While it is not required for routing information exported downward, both sub-TLVs will include the Routing Area (RA) ID from which the routing information was exported. This RA is not necessarily the RA originating the routing information but the RA from which the information was immediately exported.
RA间导出子tlv可用于防止将OSPF TE路由信息重新播发到先前播发该信息的RA中。类型值13（参见第10节）将指示相关路由信息已向下导出。类型值12（参见第10节）将指示相关路由信息已向上导出。虽然向下导出的路由信息不需要该ID，但两个子TLV都将包含导出路由信息的路由区域（RA）ID。该RA不一定是发送路由信息的RA，而是从中立即导出信息的RA。
These additional sub-TLVs MAY be included in TE LSAs that include any of the following top-level TLVs:
这些附加子TLV可包括在TE LSA中，其中包括以下任何顶级TLV：
- Router Address top-level TLV - Link top-level TLV - Node Attribute top-level TLV
- 路由器地址顶级TLV-链路顶级TLV-节点属性顶级TLV
The Type field of the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs are respectively assigned the values 12 and 13 (see Section 10). The Length field in these sub-TLVs takes the value 4. The Value field in these sub-TLVs contains the associated RA ID. The RA ID value must be a unique identifier for the RA within the ASON routing domain.
RA间向上导出和RA间向下导出子TLV的类型字段分别指定了值12和13（见第10节）。这些子TLV中的长度字段的值为4。这些子TLV中的值字段包含关联的RA ID。RA ID值必须是ASON路由域中RA的唯一标识符。
The format of the Inter-RA Export Upward and Inter-RA Export Downward sub-TLVs is graphically depicted below:
RA间向上导出和RA间向下导出子TLV的格式如下图所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upward/Downward Type | Length (4) |
| (12/13) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upward/Downward Type | Length (4) |
| (12/13) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE LSAs MAY be imported or exported downward or upward in the ASON routing hierarchy. The direction and advertising RA ID are advertised in an Inter-RA Export Upward/Downward sub-TLV. They MUST be retained and advertised in the receiving RA with the associated routing information.
TE LSA可以在ASON路由层次结构中向下或向上导入或导出。方向和广告RA ID在RA间向上/向下导出子TLV中进行广告。必须在接收RA中保留和公布它们以及相关的路由信息。
When exporting routing information upward in the ASON routing hierarchy, any information received from a level above, i.e., tagged with an Inter-RA Export Downward sub-TLV, MUST NOT be exported upward. Since an RA at Level N is contained by a single RA at Level N+1, this is the only checking that is necessary and the associated RA ID is used solely for informational purposes.
在ASON路由层次结构中向上导出路由信息时，从以上级别接收的任何信息（即，标记有RA间向下导出子TLV）不得向上导出。由于级别N的RA包含在级别N+1的单个RA中，因此这是唯一必要的检查，关联的RA ID仅用于信息目的。
When exporting routing information downward in the ASON routing hierarchy, any information received from a level below, i.e., tagged with an Inter-RA Export Upward sub-TLV, MUST NOT be exported downward if the target RA ID matches the RA ID associated with the routing information. This additional checking is required for routing information exported downward since a single RA at Level N+1 may contain multiple RAs at Level N in the ASON routing hierarchy. In other words, routing information MUST NOT be exported downward into the RA from which it was received.
在ASON路由层次结构中向下导出路由信息时，如果目标RA ID与路由信息相关联的RA ID匹配，则从以下级别接收的任何信息（即标记有RA间向上导出子TLV）不得向下导出。对于向下导出的路由信息，需要进行额外的检查，因为在ASON路由层次结构中，级别N+1的单个RA可能包含级别N的多个RA。换句话说，不得将路由信息向下导出到接收路由信息的RA中。
The extensions described herein are only applicable to ASON routing domains, and it is not expected that the attendant reachability (see Section 4) and link information will ever be combined with global Internet or Layer 3 Virtual Private Network (VPN) routing. If there were ever a requirement for a given RC to participate in both domains, separate OSPFv2 instances would be utilized. However, in a multi-level ASON hierarchy, the potential volume of information could be quite large and the recommendations in this section MUST be followed by RCs implementing this specification.
本文描述的扩展仅适用于ASON路由域，并且不期望伴随可达性（参见第4节）和链路信息与全球互联网或第3层虚拟专用网（VPN）路由相结合。如果某个给定的RC需要参与这两个域，则将使用单独的OSPFv2实例。然而，在多级ASON层次结构中，潜在的信息量可能相当大，RCs实施本规范时必须遵循本节中的建议。
- Routing information exchange upward/downward in the hierarchy between adjacent RAs MUST, by default, be limited to reachability information. In addition, several transformations such as prefix aggregation are RECOMMENDED to reduce the amount of information imported/exported by a given RC when such transformations will not impact consistency.
- 默认情况下，相邻RAs之间层次结构中向上/向下的路由信息交换必须限于可达性信息。此外，建议进行一些转换（如前缀聚合），以减少给定RC导入/导出的信息量，前提是此类转换不会影响一致性。
- Routing information exchange upward/downward in the ASON hierarchy involving TE attributes MUST be under strict policy control. Pacing and min/max thresholds for triggered updates are strongly RECOMMENDED.
- 涉及TE属性的ASON层次结构中向上/向下的路由信息交换必须受到严格的策略控制。强烈建议为触发的更新设置速度和最小/最大阈值。
- The number of routing levels MUST be maintained under strict policy control.
- 路由级别的数量必须在严格的策略控制下保持。
This document specifies the contents and processing of OSPFv2 TE LSAs [RFC3630] and [RFC4202]. The TE LSA extensions defined in this document are not used for Shortest Path First (SPF) computation and have no direct effect on IP routing. Additionally, ASON routing domains are delimited by the usual administrative domain boundaries.
本文件规定了OSPFv2 TE LSA[RFC3630]和[RFC4202]的内容和处理。本文档中定义的TE LSA扩展不用于最短路径优先（SPF）计算，对IP路由没有直接影响。此外，ASON路由域由通常的管理域边界分隔。
Any mechanisms used for securing the exchange of normal OSPF LSAs can be applied equally to all TE LSAs used in the ASON context. Authentication of OSPFv2 LSA exchanges (such as OSPF cryptographic authentication [RFC2328] [RFC5709]) can be used to provide significant protection against active attacks. [RFC5709] defines a mechanism for authenticating OSPFv2 packets by making use of the Hashed Message Authentication Code (HMAC) algorithm in conjunction with the SHA family of cryptographic hash functions.
用于确保正常OSPF LSA交换安全的任何机制都可以平等地应用于ASON上下文中使用的所有TE LSA。OSPFv2 LSA交换的身份验证（例如OSPF加密身份验证[RFC2328][RFC5709]）可用于针对主动攻击提供重要保护。[RFC5709]定义了一种通过结合使用散列消息认证码（HMAC）算法和SHA系列加密散列函数对OSPFv2数据包进行认证的机制。
RCs implementing export/import of ASON routing information between RAs MUST also include policy control of both the maximum amount of information advertised between RAs and the maximum rate at which it is advertised. This is to isolate the consequences of an RC being compromised to the RAs to which that subverted RC is attached.
在RAs之间实现ASON路由信息导出/导入的RCs还必须包括对RAs之间通告的最大信息量和通告的最大速率的策略控制。这是为了隔离RC被破坏到该被破坏RC所连接的RAs的后果。
The "Analysis of OSPF Security According to KARP Design Guide" [OSPF-SEC] provides a comprehensive analysis of OSPFv2 and OSPFv3 security relative to the requirements specified in [RFC6518].
“根据KARP设计指南分析OSPF安全性”[OSPF-SEC]提供了与[RFC6518]中规定要求相关的OSPFv2和OSPFv3安全性的综合分析。
This document defines new sub-TLVs for inclusion in OSPF TE LSAs. IANA has assigned values per the assignment policies for the registries of code points for these sub-TLVs [RFC3630].
本文件定义了OSPF TE LSA中包含的新子TLV。IANA已根据分配策略为这些子TLV的代码点注册表分配了值[RFC3630]。
The following subsections summarize the required sub-TLVs.
以下小节总结了所需的子TLV。
This document defines the following sub-TLVs of the Link TLV advertised in the OSPF TE LSA:
本文件定义了OSPF TE LSA中公布的链路TLV的以下子TLV：
- Local and Remote TE Router ID sub-TLV (10) - Inter-RA Export Upward sub-TLV (12) - Inter-RA Export Downward sub-TLV (13)
- 本地和远程TE路由器ID子TLV（10）-RA间向上导出子TLV（12）-RA间向下导出子TLV（13）
Codepoints for these sub-TLVs have been allocated in the Standards Action range of the "Types for sub-TLVs of TE Link TLV (Value 2)" registry [RFC3630].
这些子TLV的代码点已在“TE Link TLV子TLV类型（值2）”注册表[RFC3630]的标准行动范围内分配。
Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV.
请注意，在链路TLV、节点属性TLV和路由器地址TLV中出现时，必须使用RA间向上导出子TLV和RA间向下导出子TLV的相同值。
This document defines the following sub-TLVs of the Node Attribute TLV advertised in the OSPF TE LSA:
本文档定义了OSPF TE LSA中公布的节点属性TLV的以下子TLV：
- Local TE Router ID sub-TLV (5) - Inter-RA Export Upward sub-TLV (12) - Inter-RA Export Downward sub-TLV (13)
- 本地TE路由器ID子TLV（5）-RA间向上导出子TLV（12）-RA间向下导出子TLV（13）
Codepoints for these sub-TLVs have been assigned in Standards Action range of the "Types for sub-TLVs of TE Node Attribute TLV (Value 5)" [RFC5786].
这些子TLV的代码点已在“TE节点属性TLV的子TLV类型（值5）”[RFC5786]的标准行动范围内分配。
Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV.
请注意，在链路TLV、节点属性TLV和路由器地址TLV中出现时，必须使用RA间向上导出子TLV和RA间向下导出子TLV的相同值。
The Router Address TLV is advertised in the OSPF TE LSA [RFC3630]. Since the TLV had no sub-TLVs defined, a "Types for sub-TLVs of Router Address TLV (Value 1)" registry has been defined.
路由器地址TLV在OSPF TE LSA[RFC3630]中公布。由于TLV没有定义子TLV，因此定义了“路由器地址TLV（值1）的子TLV类型”注册表。
The registry guidelines for the assignment of types for sub-TLVs of the Router Address TLV are as follows:
为路由器地址TLV的子TLV分配类型的注册表指南如下：
o Types in the range 0-32767 are to be assigned via Standards Action.
o 范围为0-32767的类型将通过标准操作进行分配。
o Type 0 in the aforementioned Standards Action range (0-32767) is reserved.
o 保留上述标准操作范围（0-32767）中的类型0。
o Types in the range 32768-32777 are for experimental use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
o 32768-32777范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
o Types in the range 32778-65535 are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned.
o 此时不分配32778-65535范围内的类型。在此范围内进行任何分配之前，必须有一个标准跟踪RFC，指定涵盖所分配范围的IANA注意事项。
This document defines the following sub-TLVs for inclusion in the Router Address TLV:
本文件定义了路由器地址TLV中包含的以下子TLV：
- Inter-RA Export Upward sub-TLV (12) - Inter-RA Export Downward sub-TLV (13)
- RA间向上导出子TLV（12）-RA间向下导出子TLV（13）
Codepoints for these sub-TLVs have been allocated in the Standards Action range of the "Types for sub-TLVs of Router Address TLV (Value 1)" registry.
这些子TLV的代码点已在“路由器地址TLV的子TLV类型（值1）”注册表的标准操作范围内分配。
Note that the same values for the Inter-RA Export Upward sub-TLV and the Inter-RA Export Downward sub-TLV MUST be used when they appear in the Link TLV, Node Attribute TLV, and Router Address TLV.
请注意，在链路TLV、节点属性TLV和路由器地址TLV中出现时，必须使用RA间向上导出子TLV和RA间向下导出子TLV的相同值。
If the RA ID is mapped to the OSPF Area ID as recommended in Section 2, OSPF [RFC2328] implicitly provides isolation. On any intra-RA link, packets will only be accepted if the area ID in the OSPF packet header matches the area ID for the OSPF interface on which the packet was received. Hence, RCs will only establish adjacencies and exchange reachability information (see Section 4.0) with RCs in the same RA. Other mechanisms for RA isolation are beyond the scope of this document.
如果RA ID映射到第2节中建议的OSPF区域ID，则OSPF[RFC2328]隐式提供隔离。在任何RA内链路上，仅当OSPF数据包报头中的区域ID与接收数据包的OSPF接口的区域ID匹配时，才会接受数据包。因此，RCs将仅与同一RA中的RCs建立邻接并交换可达性信息（见第4.0节）。RA隔离的其他机制超出了本文件的范围。
The GMPLS Routing for ASON requirements [RFC4258] dictate that the routing protocol MUST support reconfiguration and SHOULD support architectural evolution. OSPF [RFC2328] includes support for the dynamic introduction or removal of ASON reachability information through the flooding and purging of OSPF Opaque LSAs [RFC5250]. Also, when an RA is partitioned or an RC fails, stale LSAs SHOULD NOT be used unless the advertising RC is reachable. The configuration of OSPF RAs and the policies governing the redistribution of ASON reachability information between RAs are implementation issues outside of the OSPF routing protocol and beyond the scope of this document.
ASON要求的GMPLS路由[RFC4258]规定，路由协议必须支持重新配置，并应支持架构演进。OSPF[RFC2328]包括通过OSPF不透明LSA的泛洪和清除来动态引入或移除ASON可达性信息的支持[RFC5250]。此外，当RA被分区或RC失败时，除非可以访问广告RC，否则不应使用过时的LSA。OSPF RAs的配置和管理RAs之间ASON可达性信息再分配的策略是OSPF路由协议之外的实现问题，超出了本文档的范围。
The following table shows how this document complies with the requirements in [RFC4258]. The first column contains a requirements number (1-30) and the relevant section in RFC 4258. The second column describes the requirement, the third column discusses the
下表显示了本文件如何符合[RFC4258]中的要求。第一列包含需求编号（1-30）和RFC 4258中的相关章节。第二列描述需求，第三列讨论
compliance to that requirement, and the fourth column lists the relevant section in this document and/or another RFC that already satisfies the requirement.
符合该要求，第四列列出了本文件中的相关章节和/或已满足该要求的其他RFC。
+----------+---------------------------+---------------+-------------+
| RFC 4258 | RFC 4258 Requirement | Compliance | Reference |
| Section | | | |
| (Req. | | | |
| Number) | | | |
+----------+---------------------------+---------------+-------------+
| 3 (1) | The failure of an RC, or | Implied by | Not an |
| | the failure of | separation of |attribute of |
| |communications between RCs,| transport and | routing |
| |and the subsequent recovery|control plane. | protocol. |
| |from the failure condition | | |
| | MUST NOT disrupt calls in | | |
| | progress. | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (2) | Multiple Hierarchical | Yes | Sections 2 |
| | Levels of ASON Routing | | and 3. |
| | Areas (RAs). | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (3) | Prior to establishing | Yes, when RA |Section 11.1.|
| | communications, RCs MUST | maps to OSPF | |
| |verify that they are bound | Area ID. | |
| | to the same parent RA. | Otherwise, | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and |
| | within its containing RA. | | Section 3. |
+----------+---------------------------+---------------+-------------+
| 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, |
| | network SHALL be uniquely | uniqueness is | 3, and 11.1.|
| | identifiable. RA IDs MAY |the operator's | |
| | be associated with a |responsibility.| |
| |transport-plane name space,| | |
| | whereas RC IDs are | | |
| | associated with a | | |
| | control-plane name space. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (6) | Hierarchical Routing | Yes | Section 7. |
| | Information Dissemination.| | |
+----------+---------------------------+---------------+-------------+
| 3.2 (7) | Routing Information | Yes | Section 7.1.|
| |exchanged between levels N | | |
| | and N+1 via separate | | |
| | instances and | | |
| | import/export. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| RFC 4258 | RFC 4258 Requirement | Compliance | Reference |
| Section | | | |
| (Req. | | | |
| Number) | | | |
+----------+---------------------------+---------------+-------------+
| 3 (1) | The failure of an RC, or | Implied by | Not an |
| | the failure of | separation of |attribute of |
| |communications between RCs,| transport and | routing |
| |and the subsequent recovery|control plane. | protocol. |
| |from the failure condition | | |
| | MUST NOT disrupt calls in | | |
| | progress. | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (2) | Multiple Hierarchical | Yes | Sections 2 |
| | Levels of ASON Routing | | and 3. |
| | Areas (RAs). | | |
+----------+---------------------------+---------------+-------------+
| 3.1 (3) | Prior to establishing | Yes, when RA |Section 11.1.|
| | communications, RCs MUST | maps to OSPF | |
| |verify that they are bound | Area ID. | |
| | to the same parent RA. | Otherwise, | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and |
| | within its containing RA. | | Section 3. |
+----------+---------------------------+---------------+-------------+
| 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, |
| | network SHALL be uniquely | uniqueness is | 3, and 11.1.|
| | identifiable. RA IDs MAY |the operator's | |
| | be associated with a |responsibility.| |
| |transport-plane name space,| | |
| | whereas RC IDs are | | |
| | associated with a | | |
| | control-plane name space. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (6) | Hierarchical Routing | Yes | Section 7. |
| | Information Dissemination.| | |
+----------+---------------------------+---------------+-------------+
| 3.2 (7) | Routing Information | Yes | Section 7.1.|
| |exchanged between levels N | | |
| | and N+1 via separate | | |
| | instances and | | |
| | import/export. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (8) | Routing Information | No - Not | |
| |exchanged between levels N | described. | |
| | and N+1 via external link | | |
| | (inter-RA links). | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (9) | Routing information | Yes | Sections 4, |
| | exchange MUST include | |6, 6.1, 6.2, |
| | reachability information | | and 8. |
| | and MAY include, upon | | |
| | policy decision, node and | | |
| | link topology. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (10) | There SHOULD NOT be any |Yes - separate | Sections 2 |
| | dependencies on the | instances. | and 3. |
| |different routing protocols| | |
| | used within an RA or in | | |
| | different RAs. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (11) |The routing protocol SHALL | Yes | Section 7.2.|
| | differentiate the routing | | |
| |information originated at a| | |
| |given-level RA from derived| | |
| | routing information | | |
| | (received from external | | |
| | RAs), even when this | | |
| |information is forwarded by| | |
| | another RC at the same | | |
| | level. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (12) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N+1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N+1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (13) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N-1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N-1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (8) | Routing Information | No - Not | |
| |exchanged between levels N | described. | |
| | and N+1 via external link | | |
| | (inter-RA links). | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (9) | Routing information | Yes | Sections 4, |
| | exchange MUST include | |6, 6.1, 6.2, |
| | reachability information | | and 8. |
| | and MAY include, upon | | |
| | policy decision, node and | | |
| | link topology. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (10) | There SHOULD NOT be any |Yes - separate | Sections 2 |
| | dependencies on the | instances. | and 3. |
| |different routing protocols| | |
| | used within an RA or in | | |
| | different RAs. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (11) |The routing protocol SHALL | Yes | Section 7.2.|
| | differentiate the routing | | |
| |information originated at a| | |
| |given-level RA from derived| | |
| | routing information | | |
| | (received from external | | |
| | RAs), even when this | | |
| |information is forwarded by| | |
| | another RC at the same | | |
| | level. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (12) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N+1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N+1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (13) | The routing protocol MUST | Yes | Section 7.2.|
| | provide a mechanism to | | |
| | prevent information | | |
| |propagated from a Level N-1| | |
| | RA's RC into the Level N | | |
| | RA's RC from being | | |
| | re-introduced into the | | |
| | Level N-1 RA's RC. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (14) | Instance of a Level N | Yes | Sections 2, |
| | routing function and an | | 3, and 7. |
| | instance of a Level N+1 | | |
| | routing function in the | | |
| | same system. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (15) | The Level N routing | Not described | N/A |
| | function is on a separate | but possible. | |
| | system than the Level | | |
| | N+1 routing function. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (16) |The RC MUST support static | The automation| Sections 2 |
| | (i.e., operator assisted) | requirement is|and 3. Refer |
| | and MAY support automated | ambiguous. | to RFC 2328 |
| | configuration of the | OSPF supports | for OSPF |
| |information describing its | auto-discovery| auto- |
| |relationship to its parent | of neighbors | discovery. |
| | and its child within the | and topology. | |
| | hierarchical structure | Default and | |
| | (including RA ID and RC | automatically | |
| | ID). | configured | |
| | | polices are | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and |
| | (i.e., operator assisted) |area maps to RA|Section 11.1.|
| | and MAY support automated | discovery is | |
| | configuration of the | automatic. | |
| |information describing its | | |
| | associated adjacencies to | | |
| | other RCs within an RA. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328. |
| |support all the types of RC| | |
| | adjacencies described in | | |
| |Section 9 of [G.7715]. The | | |
| | latter includes congruent | | |
| |topology (with distributed | | |
| | RC) and hubbed topology | | |
| |(e.g., note that the latter| | |
| | does not automatically | | |
| | imply a designated RC). | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.2 (14) | Instance of a Level N | Yes | Sections 2, |
| | routing function and an | | 3, and 7. |
| | instance of a Level N+1 | | |
| | routing function in the | | |
| | same system. | | |
+----------+---------------------------+---------------+-------------+
| 3.2 (15) | The Level N routing | Not described | N/A |
| | function is on a separate | but possible. | |
| | system than the Level | | |
| | N+1 routing function. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (16) |The RC MUST support static | The automation| Sections 2 |
| | (i.e., operator assisted) | requirement is|and 3. Refer |
| | and MAY support automated | ambiguous. | to RFC 2328 |
| | configuration of the | OSPF supports | for OSPF |
| |information describing its | auto-discovery| auto- |
| |relationship to its parent | of neighbors | discovery. |
| | and its child within the | and topology. | |
| | hierarchical structure | Default and | |
| | (including RA ID and RC | automatically | |
| | ID). | configured | |
| | | polices are | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+
| 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and |
| | (i.e., operator assisted) |area maps to RA|Section 11.1.|
| | and MAY support automated | discovery is | |
| | configuration of the | automatic. | |
| |information describing its | | |
| | associated adjacencies to | | |
| | other RCs within an RA. | | |
+----------+---------------------------+---------------+-------------+
| 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328. |
| |support all the types of RC| | |
| | adjacencies described in | | |
| |Section 9 of [G.7715]. The | | |
| | latter includes congruent | | |
| |topology (with distributed | | |
| | RC) and hubbed topology | | |
| |(e.g., note that the latter| | |
| | does not automatically | | |
| | imply a designated RC). | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.4 (19) |The routing protocol SHOULD| Yes |RFC 2328, RFC|
| | be capable of supporting | | 5250, and |
| |architectural evolution in | |Section 11.2.|
| | terms of the number of | | |
| |hierarchical levels of RAs,| | |
| |as well as the aggregation | | |
| | and segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
|3.5.2 (20)|Advertisements MAY contain | | |
| |the following common set of| | |
| | information regardless of | | |
| | whether they are link or | | |
| | node related: | | |
| | - RA ID of the RA to | Yes | Section |
| | which the | | 7.2.1. |
| | advertisement is | | |
| | bounded | | |
| | - RC ID of the entity | Yes | RFC 2328. |
| | generating the | | |
| | advertisement | | |
| | - Information to | Yes |RFC 2328, RFC|
| | uniquely identify | | 5250. |
| | advertisements | | |
| | - Information to | No - Must | |
| | determine whether an |compare to old.| |
| | advertisement has | | |
| | been updated | | |
| | - Information to | Yes | Section |
| | indicate when an | | 7.2.1. |
| | advertisement has been| | |
| | derived from a | | |
| | different level RA. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 3.4 (19) |The routing protocol SHOULD| Yes |RFC 2328, RFC|
| | be capable of supporting | | 5250, and |
| |architectural evolution in | |Section 11.2.|
| | terms of the number of | | |
| |hierarchical levels of RAs,| | |
| |as well as the aggregation | | |
| | and segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
|3.5.2 (20)|Advertisements MAY contain | | |
| |the following common set of| | |
| | information regardless of | | |
| | whether they are link or | | |
| | node related: | | |
| | - RA ID of the RA to | Yes | Section |
| | which the | | 7.2.1. |
| | advertisement is | | |
| | bounded | | |
| | - RC ID of the entity | Yes | RFC 2328. |
| | generating the | | |
| | advertisement | | |
| | - Information to | Yes |RFC 2328, RFC|
| | uniquely identify | | 5250. |
| | advertisements | | |
| | - Information to | No - Must | |
| | determine whether an |compare to old.| |
| | advertisement has | | |
| | been updated | | |
| | - Information to | Yes | Section |
| | indicate when an | | 7.2.1. |
| | advertisement has been| | |
| | derived from a | | |
| | different level RA. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
|3.5.3 (21)|The Node Attributes' Node |Yes - Prefixes | RFC 5786, |
| |ID and Reachability must be| only for | Sections 4 |
| | advertised. It MAY be | reachability. | and 6. |
| | advertised as a set of | | |
| |associated external (e.g., | | |
| | User Network Interface | | |
| | (UNI)) address/address | | |
| | prefixes or a set of | | |
| | associated Subnetwork | | |
| | Point Pool (SNPP) link | | |
| | IDs/SNPP ID prefixes, the | | |
| |selection of which MUST be | | |
| | consistent within the | | |
| | applicable scope. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (22)| The Link Attributes' Local| Yes | Section 6.1.|
| | SNPP link ID, Remote SNPP | | |
| |link ID, and layer specific| | |
| | characteristics must be | | |
| | advertised. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (23)| Link Signaling Attributes | Yes | Section 5, |
| |other than Local Adaptation| | RFC 4652 - |
| |(Signal Type, Link Weight, | | Section |
| | Resource Class, Local | | 5.3.1. |
| | Connection Types, Link | | |
| | Capacity, Link | | |
| | Availability, Diversity | | |
| | Support). | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (24)| Link Signaling Local | Yes | Section 5.1.|
| | Adaptation. | | |
+----------+---------------------------+---------------+-------------+
| 5 (25) | The routing adjacency | Yes | Sections 2, |
| | topology (i.e., the | | 3, and 6. |
| |associated PC connectivity | | |
| |topology) and the transport| | |
| |network topology SHALL NOT | | |
| |be assumed to be congruent.| | |
+----------+---------------------------+---------------+-------------+
| 5 (26) |The routing topology SHALL | Yes |RFC 2328, RFC|
| | support multiple links | | 3630. |
| | between nodes and RAs. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
|3.5.3 (21)|The Node Attributes' Node |Yes - Prefixes | RFC 5786, |
| |ID and Reachability must be| only for | Sections 4 |
| | advertised. It MAY be | reachability. | and 6. |
| | advertised as a set of | | |
| |associated external (e.g., | | |
| | User Network Interface | | |
| | (UNI)) address/address | | |
| | prefixes or a set of | | |
| | associated Subnetwork | | |
| | Point Pool (SNPP) link | | |
| | IDs/SNPP ID prefixes, the | | |
| |selection of which MUST be | | |
| | consistent within the | | |
| | applicable scope. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (22)| The Link Attributes' Local| Yes | Section 6.1.|
| | SNPP link ID, Remote SNPP | | |
| |link ID, and layer specific| | |
| | characteristics must be | | |
| | advertised. | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (23)| Link Signaling Attributes | Yes | Section 5, |
| |other than Local Adaptation| | RFC 4652 - |
| |(Signal Type, Link Weight, | | Section |
| | Resource Class, Local | | 5.3.1. |
| | Connection Types, Link | | |
| | Capacity, Link | | |
| | Availability, Diversity | | |
| | Support). | | |
+----------+---------------------------+---------------+-------------+
|3.5.4 (24)| Link Signaling Local | Yes | Section 5.1.|
| | Adaptation. | | |
+----------+---------------------------+---------------+-------------+
| 5 (25) | The routing adjacency | Yes | Sections 2, |
| | topology (i.e., the | | 3, and 6. |
| |associated PC connectivity | | |
| |topology) and the transport| | |
| |network topology SHALL NOT | | |
| |be assumed to be congruent.| | |
+----------+---------------------------+---------------+-------------+
| 5 (26) |The routing topology SHALL | Yes |RFC 2328, RFC|
| | support multiple links | | 3630. |
| | between nodes and RAs. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 5 (27) |The routing protocol SHALL | Yes |RFC 2328, RFC|
| | converge such that the | | 5250. |
| | distributed Routing | | |
| | Databases (RDBs) become | | |
| |synchronized after a period| | |
| | of time. | | |
+----------+---------------------------+---------------+-------------+
| 5 (28) |Self-consistent information|Yes - However, | Section 7.1.|
| | at the receiving level | this is not a | |
| | resulting from any | routing | |
| | transformation (filter, | protocol | |
| | summarize, etc.) and | function. | |
| | forwarding of information | | |
| | from one RC to RC(s) at | | |
| | different levels when | | |
| |multiple RCs are bound to a| | |
| | single RA. | | |
+----------+---------------------------+---------------+-------------+
| 5 (29) | In order to support |Partial - OSPF |RFC 2328 and |
| | operator-assisted changes | supports the | RFC 5250. |
| | in the containment | purging of | |
| | relationships of RAs, the | stale | |
| | routing protocol SHALL |advertisements | |
| |support evolution in terms |and origination| |
| | of the number of | of new. The | |
| |hierarchical levels of RAs.|non-disruptive | |
| | For example, support of | behavior is | |
| | non-disruptive operations |implementation | |
| |such as adding and removing| specific. | |
| | RAs at the top/bottom of | | |
| | the hierarchy, adding or | | |
| | removing a hierarchical | | |
| |level of RAs in or from the| | |
| |middle of the hierarchy, as| | |
| | well as aggregation and | | |
| | segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
| 5 (30) | A collection of links and |Yes - Within an| Sections 4 |
| |nodes such as a subnetwork | RA it must be | and 6. |
| | or RA MUST be able to | consistent. | |
| | represent itself to the | | |
| | wider network as a single | | |
| | logical entity with only | | |
| |its external links visible | | |
| | to the topology database. | | |
+----------+---------------------------+---------------+-------------+
+----------+---------------------------+---------------+-------------+
| 5 (27) |The routing protocol SHALL | Yes |RFC 2328, RFC|
| | converge such that the | | 5250. |
| | distributed Routing | | |
| | Databases (RDBs) become | | |
| |synchronized after a period| | |
| | of time. | | |
+----------+---------------------------+---------------+-------------+
| 5 (28) |Self-consistent information|Yes - However, | Section 7.1.|
| | at the receiving level | this is not a | |
| | resulting from any | routing | |
| | transformation (filter, | protocol | |
| | summarize, etc.) and | function. | |
| | forwarding of information | | |
| | from one RC to RC(s) at | | |
| | different levels when | | |
| |multiple RCs are bound to a| | |
| | single RA. | | |
+----------+---------------------------+---------------+-------------+
| 5 (29) | In order to support |Partial - OSPF |RFC 2328 and |
| | operator-assisted changes | supports the | RFC 5250. |
| | in the containment | purging of | |
| | relationships of RAs, the | stale | |
| | routing protocol SHALL |advertisements | |
| |support evolution in terms |and origination| |
| | of the number of | of new. The | |
| |hierarchical levels of RAs.|non-disruptive | |
| | For example, support of | behavior is | |
| | non-disruptive operations |implementation | |
| |such as adding and removing| specific. | |
| | RAs at the top/bottom of | | |
| | the hierarchy, adding or | | |
| | removing a hierarchical | | |
| |level of RAs in or from the| | |
| |middle of the hierarchy, as| | |
| | well as aggregation and | | |
| | segmentation of RAs. | | |
+----------+---------------------------+---------------+-------------+
| 5 (30) | A collection of links and |Yes - Within an| Sections 4 |
| |nodes such as a subnetwork | RA it must be | and 6. |
| | or RA MUST be able to | consistent. | |
| | represent itself to the | | |
| | wider network as a single | | |
| | logical entity with only | | |
| |its external links visible | | |
| | to the topology database. | | |
+----------+---------------------------+---------------+-------------+
[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月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[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月。
[RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions", RFC 5786, March 2010.
[RFC5786]Aggarwal，R.和K.Kompella，“在OSPF流量工程（TE）扩展中宣传路由器的本地地址”，RFC 5786，2010年3月。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005.
[RFC4258]Brungard，D.，Ed.“自动交换光网络（ASON）的通用多协议标签交换（GMPLS）路由要求”，RFC 4258，2005年11月。
[RFC4652] Papadimitriou, D., Ed., Ong, L., Sadler, J., Shew, S., and D. Ward, "Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements", RFC 4652, October 2006.
[RFC4652]Papadimitriou，D.，Ed.，Ong，L.，Sadler，J.，Shew，S.，和D.Ward，“根据自动交换光网络（ASON）路由要求评估现有路由协议”，RFC 4652，2006年10月。
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, October 2009.
[RFC5709]Bhatia，M.，Manral，V.，Fanto，M.，White，R.，Barnes，M.，Li，T.，和R.Atkinson，“OSPFv2 HMAC-SHA加密认证”，RFC 5709，2009年10月。
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines", RFC 6518, February 2012.
[RFC6518]Lebovitz，G.和M.Bhatia，“路由协议的键控和认证（KARP）设计指南”，RFC 6518，2012年2月。
[OSPF-SEC] Hartman, S. and Zhang, D., "Analysis of OSPF Security According to KARP Design Guide", Work in Progress, November 2012.
[OSPF-SEC]Hartman，S.和Zhang，D.，“根据KARP设计指南分析OSPF安全性”，正在进行的工作，2012年11月。
[G.7715] ITU-T Rec. G.7715/Y.1706, "Architecture and Requirements in the Automatically Switched Optical Network", June 2002.
[G.7715]ITU-T Rec.G.7715/Y.1706，“自动交换光网络的体系结构和要求”，2002年6月。
[G.7715.1] ITU-T Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link State Protocols", February 2004.
[G.7715.1]ITU-T Rec.G.7715.1/Y.1706.1，“ASON路由体系结构和链路状态协议要求”，2004年2月。
[G.805] ITU-T Rec. G.805, "Generic Functional Architecture of Transport Networks)", March 2000.
[G.805]ITU-T Rec.G.805，“传输网络的通用功能架构”，2000年3月。
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the automatically switched optical network", February 2012.
[G.8080]ITU-T Rec.G.8080/Y.1304，“自动交换光网络的体系结构”，2012年2月。
The editors would like to thank Lyndon Ong, Remi Theillaud, Stephen Shew, Jonathan Sadler, Deborah Brungard, Lou Berger, and Adrian Farrel for their useful comments and suggestions.
编辑们要感谢林登·翁、雷米·泰劳德、斯蒂芬·休、乔纳森·萨德勒、黛博拉·布伦加德、卢·伯格和阿德里安·法雷尔，感谢他们提出的有用的意见和建议。
The author would like to thank Dean Cheng, Acee Lindem, Pandian Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell for their useful comments and suggestions.
作者要感谢Cheng院长、Acee Lindem、Pandian Vijay、Alan Davey、Adrian Farrel、Deborah Brungard和Ben Campbell提出的有用意见和建议。
Lisa Dusseault and Jari Arkko provided useful comments during IESG review.
Lisa Dusseault和Jari Arkko在IESG审查期间提供了有用的意见。
Question 14 of Study Group 15 of the ITU-T provided useful and constructive input.
ITU-T第15研究组的问题14提供了有益和建设性的投入。
This document makes use of the following terms:
本文件使用了以下术语：
Administrative domain: (See Recommendation [G.805].) For the purposes of [G.7715.1], an administrative domain represents the extent of resources that belong to a single player such as a network operator, a service provider, or an end-user. Administrative domains of different players do not overlap amongst themselves.
管理域：（见建议[G.805]）在[G.7715.1]中，管理域表示属于单个参与者（如网络运营商、服务提供商或最终用户）的资源范围。不同参与者的管理域之间不会重叠。
Control plane: performs the call control and connection control functions. Through signaling, the control plane sets up and releases connections and may restore a connection in case of a failure.
控制平面：执行呼叫控制和连接控制功能。通过信令，控制平面建立和释放连接，并在发生故障时恢复连接。
(Control) Domain: represents a collection of (control) entities that are grouped for a particular purpose. The control plane is subdivided into domains matching administrative domains. Within an administrative domain, further subdivisions of the control plane are recursively applied. A routing control domain is an abstract entity that hides the details of the RC distribution.
（控制）域：表示为特定目的分组的（控制）实体的集合。控制平面细分为与管理域匹配的域。在管理域内，递归地应用控制平面的进一步细分。路由控制域是隐藏RC分发详细信息的抽象实体。
External NNI (E-NNI): interfaces located between protocol controllers between control domains.
外部NNI（E-NNI）：位于控制域之间的协议控制器之间的接口。
Internal NNI (I-NNI): interfaces located between protocol controllers within control domains.
内部NNI（I-NNI）：位于控制域内协议控制器之间的接口。
Link: (See Recommendation G.805.) A "topological component" that describes a fixed relationship between a "subnetwork" or "access group" and another "subnetwork" or "access group". Links are not limited to being provided by a single server trail.
链接：（见建议G.805。）描述“子网”或“接入组”与另一“子网”或“接入组”之间固定关系的“拓扑组件”。链接不限于由单个服务器提供。
Management plane: performs management functions for the transport plane, the control plane, and the system as a whole. It also provides coordination between all the planes. The following management functional areas are performed in the management plane: performance, fault, configuration, accounting, and security management.
管理平面：对运输平面、控制平面和整个系统执行管理功能。它还提供所有平面之间的协调。在管理平面中执行以下管理功能区域：性能、故障、配置、记帐和安全管理。
Management domain: (See Recommendation G.805.) A management domain defines a collection of managed objects that are grouped to meet organizational requirements according to geography, technology, policy, or other structure, and for a number of functional areas such as Fault, Configuration, Accounting, Performance, and Security (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint, contained,
管理域：（见建议G.805。）管理域定义了管理对象的集合，这些对象根据地理位置、技术、策略或其他结构进行分组，以满足组织需求，并用于故障、配置、记帐、性能和安全（FCAP）等多个功能领域，为了以一致的方式提供控制。管理域可以是不相交的、包含的、，
or overlapping. As such, the resources within an administrative domain can be distributed into several possible overlapping management domains. The same resource can therefore belong to several management domains simultaneously, but a management domain shall not cross the border of an administrative domain.
或重叠。因此，管理域中的资源可以分布到几个可能重叠的管理域中。因此，同一资源可以同时属于多个管理域，但管理域不得跨越管理域的边界。
Subnetwork Point (SNP): The SNP is a control-plane abstraction that represents an actual or potential transport-plane resource. SNPs (in different subnetwork partitions) may represent the same transport resource. A one-to-one correspondence should not be assumed.
子网点（SNP）：SNP是表示实际或潜在传输平面资源的控制平面抽象。SNP（在不同的子网分区中）可以表示相同的传输资源。不应假设一对一的对应关系。
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together for the purposes of routing.
子网点池（SNPP）：为路由目的而分组在一起的一组SNP。
Termination Connection Point (TCP): A TCP represents the output of a Trail Termination function or the input to a Trail Termination Sink function.
终端连接点（TCP）：TCP表示跟踪终端功能的输出或跟踪终端接收器功能的输入。
Transport plane: provides bidirectional or unidirectional transfer of user information, from one location to another. It can also provide transfer of some control and network management information. The transport plane is layered; it is equivalent to the Transport Network defined in Recommendation G.805.
传输平面：提供用户信息从一个位置到另一个位置的双向或单向传输。它还可以提供一些控制和网络管理信息的传输。运输机是分层的,；它相当于建议G.805中定义的传输网络。
User Network Interface (UNI): interfaces are located between protocol controllers between a user and a control domain. Note: There is no routing function associated with a UNI reference point.
用户网络接口（UNI）：接口位于用户和控制域之间的协议控制器之间。注：没有与UNI参考点关联的路由功能。
This document makes use of the following terms:
本文件使用了以下术语：
Routing Area (RA): an RA represents a partition of the transport plane, and its identifier is used within the control plane as the representation of this partition. Per [G.8080], an RA is defined by a set of subnetworks, the links that interconnect them, and the interfaces representing the ends of the links exiting that RA. An RA may contain smaller RAs inter-connected by links. The limit of subdivision results in an RA that contains two subnetworks interconnected by a single link.
路由区域（RA）：RA表示传输平面的分区，其标识符在控制平面内用作此分区的表示。根据[G.8080]，RA由一组子网络、互连它们的链路以及代表退出RA的链路端部的接口定义。RA可以包含通过链路相互连接的较小RA。细分的限制导致RA包含由单个链路互连的两个子网络。
Routing Database (RDB): a repository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and may additionally contain information that is configured. The RDB may contain routing information for more than one routing area (RA).
路由数据库（RDB）：本地拓扑、网络拓扑、可达性和其他路由信息的存储库，作为路由信息交换的一部分进行更新，还可能包含已配置的信息。RDB可能包含多个路由区域（RA）的路由信息。
Routing Components: ASON routing architecture functions. These functions can be classified as protocol independent (Link Resource Manager (LRM), Routing Controller (RC)) or protocol specific (Protocol Controller (PC)).
路由组件：ASON路由架构功能。这些功能可分为协议独立（链路资源管理器（LRM）、路由控制器（RC））或协议特定（协议控制器（PC））。
Routing Controller (RC): handles (abstract) information needed for routing and the routing information exchange with peering RCs by operating on the RDB. The RC has access to a view of the RDB. The RC is protocol independent.
路由控制器（RC）：通过在RDB上操作，处理路由所需的（抽象）信息以及与对等RCs的路由信息交换。RC可以访问RDB的视图。RC是独立于协议的。
Note: Since the RDB may contain routing information pertaining to multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information.
注意：由于RDB可能包含与多个RAs（以及可能与多层网络）相关的路由信息，因此访问RDB的RCs可能共享路由信息。
Link Resource Manager (LRM): supplies all the relevant component and TE link information to the RC. It informs the RC about any state changes of the link resources it controls.
链路资源管理器（LRM）：向RC提供所有相关组件和TE链路信息。它将通知RC其控制的链路资源的任何状态更改。
Protocol Controller (PC): handles protocol-specific message exchanges according to the reference point over which the information is exchanged (e.g., E-NNI, I-NNI) and internal exchanges with the RC. The PC function is protocol dependent.
协议控制器（PC）：根据交换信息的参考点（如e-NNI、I-NNI）和与RC的内部交换，处理特定于协议的消息交换。PC功能取决于协议。
This document contains the following changes from RFC 5787:
本文件包含RFC 5787的以下更改：
1. This document will be on the Standards Track, rather than Experimental, and reflects experience gained from RFC 5787 implementation and interoperability testing. This also required changes to the IANA Considerations.
1. 本文档将走上标准化的轨道，而不是实验性的，并反映了从RFC 5787实施和互操作性测试中获得的经验。这也需要对IANA注意事项进行更改。
2. There is a new Section 3 on Terminology and Identification to describe the mapping of key ASON entities to OSPF entities.
2. 有一个关于术语和标识的新的第3节描述了关键ASON实体到OSPF实体的映射。
3. Sections were reorganized to explain terminology before defining prefix extensions.
3. 在定义前缀扩展之前，对各节进行了重新组织以解释术语。
4. There is a new Section 11, Management Considerations, which describes how existing OSPF mechanisms address ASON requirements on Routing Area changes.
4. 新的第11节“管理注意事项”描述了现有OSPF机制如何满足ASON对路由区域更改的要求。
5. There is a new Section 12, which compares the document to the requirements in RFC 4258.
5. 新的第12节将本文件与RFC 4258中的要求进行了比较。
6. The prefix format was changed to reference RFC 5786 rather than defining a separate format and The Node Attribute TLV in RFC 5786 has been updated as a result.
6. 前缀格式已更改为引用RFC 5786，而不是定义单独的格式，因此RFC 5786中的节点属性TLV已更新。
7. Routing Information Advertisements were simplified from RFC 5787.
7. 路由信息广告从RFC 5787简化。
8. Review comments from ITU-T SG15 and the IESG were incorporated.
8. 纳入了ITU-T SG15和IESG的审查意见。
Authors' Addresses
作者地址
Andrew G. Malis Verizon Communications 60 Sylvan Rd. Waltham, MA 02451 USA
Andrew G.Malis Verizon Communications美国马萨诸塞州沃尔瑟姆西尔文路60号，邮编02451
EMail: andrew.g.malis@verizon.com
EMail: andrew.g.malis@verizon.com
Acee Lindem Ericsson 102 Carric Bend Court Cary, NC 27519
Acee Lindem Ericsson 102北卡罗来纳州卡里克本德法院，邮编27519
EMail: acee.lindem@ericsson.com
EMail: acee.lindem@ericsson.com
Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan, 50 2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan，比利时安特卫普2018年5月50日
EMail: dimitri.papadimitriou@alcatel-lucent.com
EMail: dimitri.papadimitriou@alcatel-lucent.com