Internet Engineering Task Force (IETF) P. Psenak
Request for Comments: 7684 Cisco Systems
Category: Standards Track H. Gredler
ISSN: 2070-1721 Independent
R. Shakir
Jive Communications, Inc.
W. Henderickx
Alcatel-Lucent
J. Tantsura
Ericsson
A. Lindem
Cisco Systems
November 2015
Internet Engineering Task Force (IETF) P. Psenak
Request for Comments: 7684 Cisco Systems
Category: Standards Track H. Gredler
ISSN: 2070-1721 Independent
R. Shakir
Jive Communications, Inc.
W. Henderickx
Alcatel-Lucent
J. Tantsura
Ericsson
A. Lindem
Cisco Systems
November 2015
OSPFv2 Prefix/Link Attribute Advertisement
OSPFv2前缀/链接属性播发
Abstract
摘要
OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.
OSPFv2需要功能扩展，超出了RFC2328中描述的固定格式链路状态播发（LSA）可以轻松完成的功能。本文档基于类型长度值（TLV）元组定义OSPFv2不透明LSA，该元组可用于将附加属性与前缀或链接关联。根据应用程序的不同，这些前缀和链接可能会以固定格式LSA发布，也可能不会。OSPFv2不透明LSA是可选的，完全向后兼容。
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/rfc7684.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7684.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
2. OSPFv2 Extended Prefix Opaque LSA ...............................3
2.1. OSPFv2 Extended Prefix TLV .................................5
3. OSPFv2 Extended Link Opaque LSA .................................8
3.1. OSPFv2 Extended Link TLV ...................................9
4. Backward Compatibility .........................................10
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
6.1. OSPFv2 Extended Prefix Opaque LSA TLVs Registry ...........11
6.2. OSPFv2 Extended Prefix TLV Sub-TLVs Registry ..............12
6.3. OSPFv2 Extended Prefix TLV Flags Registry .................12
6.4. OSPFv2 Extended Link Opaque LSA TLVs Registry .............12
6.5. OSPFv2 Extended Link TLV Sub-TLVs Registry ................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................15
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
2. OSPFv2 Extended Prefix Opaque LSA ...............................3
2.1. OSPFv2 Extended Prefix TLV .................................5
3. OSPFv2 Extended Link Opaque LSA .................................8
3.1. OSPFv2 Extended Link TLV ...................................9
4. Backward Compatibility .........................................10
5. Security Considerations ........................................10
6. IANA Considerations ............................................11
6.1. OSPFv2 Extended Prefix Opaque LSA TLVs Registry ...........11
6.2. OSPFv2 Extended Prefix TLV Sub-TLVs Registry ..............12
6.3. OSPFv2 Extended Prefix TLV Flags Registry .................12
6.4. OSPFv2 Extended Link Opaque LSA TLVs Registry .............12
6.5. OSPFv2 Extended Link TLV Sub-TLVs Registry ................13
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgements ..................................................14
Authors' Addresses ................................................15
OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328 [OSPFV2]. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible. This is in contrast to the approach taken in OSPFv3 [OSPFv3-EXTEND] where the existing LSAs will be replaced by TLV-based extended LSAs.
OSPFv2需要功能扩展，超出了RFC2328[OSPFv2]中描述的固定格式链路状态播发（LSA）可以轻松完成的功能。本文档基于类型长度值（TLV）元组定义OSPFv2不透明LSA，该元组可用于将附加属性与前缀或链接关联。根据应用程序的不同，这些前缀和链接可能会以固定格式LSA发布，也可能不会。OSPFv2不透明LSA是可选的，完全向后兼容。这与OSPFv3[OSPFv3 EXTEND]中采用的方法不同，在OSPFv3[OSPFv3 EXTEND]中，现有的LSA将被基于TLV的扩展LSA取代。
New requirements such as source/destination routing, route tagging, and segment routing necessitate this extension.
源/目的地路由、路由标记和段路由等新需求需要此扩展。
This specification defines the following OSPFv2 Opaque LSAs:
本规范定义了以下OSPFv2不透明LSA：
1. OSPFv2 Extended Prefix Opaque LSA - Allows advertisement of additional attributes for prefixes advertised in Router-LSAs, Network-LSAs, Summary-LSAs (IP network), NSSA-LSAs, and AS-external-LSAs [OSPFV2][RFC3101].
1. OSPFv2扩展前缀不透明LSA-允许在路由器LSA、网络LSA、摘要LSA（IP网络）、NSSA LSA和外部LSA中公布前缀的附加属性[OSPFv2][RFC3101]。
2. OSPFv2 Extended Link Opaque LSA - Allows advertisement of additional attributes for links advertised in Router-LSAs.
2. OSPFv2扩展链路不透明LSA-允许为路由器LSA中公布的链路公布附加属性。
Additionally, the following TLVs are defined:
此外，还定义了以下TLV：
1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes for a prefix in the OSPFv2 Extended Prefix Opaque LSA.
1. OSPFv2扩展前缀TLV-OSPFv2扩展前缀不透明LSA中前缀的顶级TLV广告属性。
2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes for a link in the OSPFv2 Extended Link Opaque LSA.
2. OSPFv2扩展链路TLV-OSPFv2扩展链路不透明LSA中链路的顶级TLV广告属性。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The OSPFv2 Extended Prefix Opaque LSA is used to advertise additional prefix attributes. Opaque LSAs are described in [OPAQUE].
OSPFv2扩展前缀不透明LSA用于公布其他前缀属性。不透明LSA在[不透明]中描述。
Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix Opaque LSA depends on the scope of the advertised prefixes and is
OSPFv2路由器可以播发多个OSPFv2扩展前缀不透明LSA。OSPFv2扩展前缀不透明LSA的泛洪范围取决于播发前缀的范围，并且是
under the control of the advertising router. In some cases (e.g., mapping server deployment [SEGMENT-ROUTING]), the LSA flooding scope may be greater than the scope of the corresponding prefixes.
在广告路由器的控制下。在某些情况下（例如，映射服务器部署[段路由]），LSA泛洪范围可能大于相应前缀的范围。
The format of the OSPFv2 Extended Prefix Opaque LSA is as follows:
OSPFv2扩展前缀不透明LSA的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv2 Extended Prefix Opaque LSA
OSPFv2扩展前缀不透明LSA
The Opaque Type used by the OSPFv2 Extended Prefix Opaque LSA is 7. The Opaque Type is used to differentiate the various types of OSPFv2 Opaque LSAs and is described in Section 3 of [OPAQUE]. The LS Type may be 10 or 11, indicating that the Opaque LSA flooding scope is area-local (10) or AS-wide (11) [OPAQUE]. The LSA Length field [OSPFV2] represents the total length (in octets) of the Opaque LSA, including the LSA header and all TLVs (including padding).
OSPFv2扩展前缀不透明LSA使用的不透明类型为7。不透明类型用于区分各种类型的OSPFv2不透明LSA，并在[不透明]的第3节中描述。LS类型可能为10或11，表示不透明LSA泛洪范围为局部区域（10）或宽度（11）[不透明]。LSA长度字段[OSPFV2]表示不透明LSA的总长度（以八位字节为单位），包括LSA头和所有TLV（包括填充）。
The Opaque ID field is an arbitrary value used to maintain multiple OSPFv2 Extended Prefix Opaque LSAs. For OSPFv2 Extended Prefix Opaque LSAs, the Opaque ID has no semantic significance other than to differentiate OSPFv2 Extended Prefix Opaque LSAs originated by the same OSPFv2 router. If multiple OSPFv2 Extended Prefix Opaque LSAs include the same prefix, the attributes from the Opaque LSA with the lowest Opaque ID SHOULD be used.
不透明ID字段是用于维护多个OSPFv2扩展前缀不透明LSA的任意值。对于OSPFv2扩展前缀不透明LSA，不透明ID除了用于区分由同一OSPFv2路由器发起的OSPFv2扩展前缀不透明LSA之外，没有任何语义意义。如果多个OSPFv2扩展前缀不透明LSA包含相同的前缀，则应使用不透明ID最低的不透明LSA的属性。
The format of the TLVs within the body of the OSPFv2 Extended Prefix Opaque LSA is the same as the format used by the Traffic Engineering Extensions to OSPFv2 [TE]. The variable TLV section consists of one or more nested TLV tuples. Nested TLVs are also referred to as sub-TLVs. The format of each TLV is:
OSPFv2扩展前缀不透明LSA主体内TLV的格式与OSPFv2[TE]流量工程扩展使用的格式相同。变量TLV部分由一个或多个嵌套TLV元组组成。嵌套TLV也称为子TLV。每个TLV的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
TLV格式
The Length field defines the length of the value portion in octets (thus, a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the Length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-byte value would have the Length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. The padding is composed of zeros.
长度字段以八位字节定义值部分的长度（因此，没有值部分的TLV的长度为0）。TLV填充为4-八位组对齐；长度字段中不包括填充（因此3个八位字节的值的长度为3，但TLV的总大小为8个八位字节）。嵌套TLV也是32位对齐的。例如，一个1字节的值将把Length字段设置为1，并在TLV的值部分的末尾添加3个八位字节的填充。填充由零组成。
The OSPFv2 Extended Prefix TLV is used to advertise additional attributes associated with the prefix. Multiple OSPFv2 Extended Prefix TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. However, since the Opaque LSA type defines the flooding scope, the LSA flooding scope MUST satisfy the application-specific requirements for all the prefixes included in a single OSPFv2 Extended Prefix Opaque LSA. The OSPFv2 Extended Prefix TLV has the following format:
OSPFv2扩展前缀TLV用于公布与前缀关联的其他属性。可以在每个OSPFv2扩展前缀不透明LSA中通告多个OSPFv2扩展前缀TLV。但是，由于不透明LSA类型定义了泛洪范围，因此LSA泛洪范围必须满足单个OSPFv2扩展前缀不透明LSA中包含的所有前缀的应用程序特定要求。OSPFv2扩展前缀TLV具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Prefix Length | AF | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Prefix Length | AF | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
OSPFv2 Extended Prefix TLV
OSPFv2扩展前缀TLV
Type The TLV type. The value is 1 for this TLV type.
键入TLV类型。此TLV类型的值为1。
Length Variable, dependent on sub-TLVs.
长度变量，取决于子TLV。
Route Type The type of the OSPFv2 route. If the route type is 0 (Unspecified), the information inside the OSPFv2 External Prefix TLV applies to the prefix regardless of prefix's route type. This is useful when prefix-specific attributes are advertised by an external entity that is not aware of the route type associated with the prefix. Supported types are:
路由类型OSPFv2路由的类型。如果路由类型为0（未指定），则OSPFv2外部前缀TLV中的信息将应用于前缀，而不管前缀的路由类型如何。当不知道与前缀关联的路由类型的外部实体播发前缀特定属性时，这非常有用。支持的类型包括：
0 - Unspecified
0-未指定
1 - Intra-Area
1-区域内
3 - Inter-Area
3-区域间
5 - Autonomous System (AS) External
5-自主系统（AS）外部
7 - Not-So-Stubby Area (NSSA) External
7-不太短的外部区域（NSSA）
These route types correspond directly to the OSPFv2 LSAs types as defined in the "OSPFv2 Link State (LS) Type" registry in <http://www.iana.org/assignments/ospfv2-parameters>. Specification of route types other than those defined will prevent correlation with existing OSPFv2 LSAs and is beyond the scope of this specification.
这些路由类型直接对应于中“OSPFv2链路状态（LS）类型”注册表中定义的OSPFv2 LSA类型<http://www.iana.org/assignments/ospfv2-parameters>. 除已定义的路由类型以外的路由类型规范将防止与现有OSPFv2 LSA相关，并且超出本规范的范围。
Prefix Length Length of prefix in bits.
前缀长度前缀的长度，以位为单位。
AF Address family for the prefix. Currently, the only supported value is 0 for IPv4 unicast. The inclusion of address family in this TLV allows for future extension.
前缀的AF地址族。目前，IPv4单播唯一支持的值是0。此TLV中包含的地址系列允许将来扩展。
Flags This one-octet field contains flags applicable to the prefix. Supported Flags include:
标志此八位字节字段包含适用于前缀的标志。支持的标志包括：
0x80 - A-Flag (Attach Flag): An Area Border Router (ABR) generating an OSPFv2 Extended Prefix TLV for an inter-area prefix that is locally connected or attached in another connected area SHOULD set this flag.
0x80-A标志（附加标志）：区域边界路由器（ABR）为本地连接或附加在另一连接区域的区域间前缀生成OSPFv2扩展前缀TLV时，应设置此标志。
0x40 - N-Flag (Node Flag): Set when the prefix identifies the advertising router, i.e., the prefix is a host prefix advertising a globally reachable address typically associated with a loopback address. The advertising router MAY choose to not set this flag even when the above conditions are met. If the flag is set and the prefix length is not a host prefix, then the flag MUST be ignored. The flag is preserved when the OSPFv2 Extended Prefix Opaque LSA is propagated between areas.
0x40-N标志（节点标志）：当前缀标识播发路由器时设置，即，前缀是播发通常与环回地址关联的全局可访问地址的主机前缀。即使满足上述条件，广告路由器也可以选择不设置此标志。如果设置了该标志且前缀长度不是主机前缀，则必须忽略该标志。当OSPFv2扩展前缀不透明LSA在区域之间传播时，该标志被保留。
Address Prefix For the address family IPv4 unicast, the prefix itself is encoded as a 32-bit value. The default route is represented by a prefix of length 0. Prefix encoding for other address families is beyond the scope of this specification.
地址前缀对于地址系列IPv4单播，前缀本身编码为32位值。默认路由由长度为0的前缀表示。其他地址族的前缀编码超出了本规范的范围。
If this TLV is advertised multiple times for the same prefix in the same OSPFv2 Extended Prefix Opaque LSA, only the first instance of the TLV is used by receiving OSPFv2 routers. This situation SHOULD be logged as an error.
如果针对同一OSPFv2扩展前缀不透明LSA中的同一前缀多次播发此TLV，则接收OSPFv2路由器仅使用TLV的第一个实例。这种情况应记录为错误。
If this TLV is advertised multiple times for the same prefix in different OSPFv2 Extended Prefix Opaque LSAs originated by the same OSPFv2 router, the OSPFv2 advertising router is re-originating OSPFv2 Extended Prefix Opaque LSAs for multiple prefixes and is most likely repacking Extended-Prefix-TLVs in OSPFv2 Extended Prefix Opaque LSAs. In this case, the Extended-Prefix-TLV in the OSPFv2 Extended Prefix Opaque LSA with the smallest Opaque ID is used by receiving OSPFv2 routers. This situation may be logged as a warning.
如果该TLV针对由同一OSPFv2路由器发起的不同OSPFv2扩展前缀不透明LSA中的同一前缀多次播发，则OSPFv2播发路由器将为多个前缀重新发起OSPFv2扩展前缀不透明LSA，并且极有可能在OSPFv2扩展前缀不透明LSA中重新打包扩展前缀TLV。在这种情况下，接收OSPFv2路由器使用具有最小不透明ID的OSPFv2扩展前缀不透明LSA中的扩展前缀TLV。这种情况可能被记录为警告。
It is RECOMMENDED that OSPFv2 routers advertising OSPFv2 Extended Prefix TLVs in different OSPFv2 Extended Prefix Opaque LSAs re-originate these LSAs in ascending order of Opaque ID to minimize the disruption.
建议在不同的OSPFv2扩展前缀不透明LSA中宣传OSPFv2扩展前缀TLV的OSPFv2路由器按照不透明ID的升序重新发起这些LSA，以尽量减少中断。
If this TLV is advertised multiple times for the same prefix in different OSPFv2 Extended Prefix Opaque LSAs originated by different OSPFv2 routers, the application using the information is required to determine which OSPFv2 Extended Prefix Opaque LSA is used. For example, the application could prefer the LSA providing the best path to the prefix.
如果针对不同OSPFv2路由器发起的不同OSPFv2扩展前缀不透明LSA中的相同前缀多次公布此TLV，则需要使用该信息的应用程序确定使用哪个OSPFv2扩展前缀不透明LSA。例如，应用程序可能希望LSA提供指向前缀的最佳路径。
This document creates a registry for OSPFv2 Extended Prefix sub-TLVs in Section 6.
本文件为第6节中的OSPFv2扩展前缀子TLV创建了一个注册表。
The OSPFv2 Extended Link Opaque LSA is used to advertise additional link attributes. Opaque LSAs are described in [OPAQUE].
OSPFv2扩展链路不透明LSA用于公布附加链路属性。不透明LSA在[不透明]中描述。
The OSPFv2 Extended Link Opaque LSA has an area flooding scope. Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a single router in an area.
OSPFv2扩展链路不透明LSA具有区域泛洪范围。多个OSPFv2扩展链路不透明LSA可由一个区域内的单个路由器播发。
The format of the OSPFv2 Extended Link Opaque LSA is as follows:
OSPFv2扩展链路不透明LSA的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv2 Extended Link Opaque LSA
OSPFv2扩展链路不透明LSA
The Opaque Type used by the OSPFv2 Extended Link Opaque LSA is 8. The LS Type is 10, indicating that the Opaque LSA flooding scope is area-local [OPAQUE]. The Opaque Type is used to differentiate the various types of OSPFv2 Opaque LSAs and is described in Section 3 of [OPAQUE]. The LSA Length field [OSPFV2] represents the total length (in octets) of the Opaque LSA, including the LSA header and all TLVs (including padding).
OSPFv2扩展链路不透明LSA使用的不透明类型为8。LS类型为10，表示不透明LSA泛洪范围为区域局部[不透明]。不透明类型用于区分各种类型的OSPFv2不透明LSA，并在[不透明]的第3节中描述。LSA长度字段[OSPFV2]表示不透明LSA的总长度（以八位字节为单位），包括LSA头和所有TLV（包括填充）。
The Opaque ID field is an arbitrary value used to maintain multiple OSPFv2 Extended Prefix Opaque LSAs. For OSPFv2 Extended Link Opaque LSAs, the Opaque ID has no semantic significance other than to differentiate OSPFv2 Extended Link Opaque LSAs originated by the same OSPFv2 router. If multiple OSPFv2 Extended Link Opaque LSAs include the same link, the attributes from the Opaque LSA with the lowest Opaque ID will be used.
不透明ID字段是用于维护多个OSPFv2扩展前缀不透明LSA的任意值。对于OSPFv2扩展链路不透明LSA，不透明ID除了用于区分由同一OSPFv2路由器发起的OSPFv2扩展链路不透明LSA之外，没有任何语义意义。如果多个OSPFv2扩展链路不透明LSA包含同一链路，将使用不透明ID最低的不透明LSA的属性。
The format of the TLVs within the body of the OSPFv2 Extended Link Opaque LSA is the same as described in Section 2.
OSPFv2扩展链路不透明LSA主体内TLV的格式与第2节所述相同。
The OSPFv2 Extended Link TLV is used to advertise various attributes of the link. It describes a single link and is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one OSPFv2 Extended Link TLV SHALL be advertised in each OSPFv2 Extended Link Opaque LSA, allowing for fine granularity changes in the topology.
OSPFv2扩展链路TLV用于公布链路的各种属性。它描述单个链路，由一组子TLV构成。子TLV没有订购要求。在每个OSPFv2扩展链路不透明LSA中仅应公布一个OSPFv2扩展链路TLV，以允许拓扑中的细粒度更改。
The OSPFv2 Extended Link TLV has following format:
OSPFv2扩展链路TLV具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| ... |
OSPFv2 Extended Link TLV
OSPFv2扩展链路TLV
Type The TLV type. The value is 1 for this TLV type.
键入TLV类型。此TLV类型的值为1。
Length Variable, dependent on sub-TLVs.
长度变量，取决于子TLV。
Link Type Link Type is defined in Section A.4.2 of [OSPFV2] and in the "OSPFv2 Router LSA Link Type (Value 1)" registry at <http://www.iana.org/assignments/ospfv2-parameters>. Specification of link types other than those defined will prevent correlation with existing OSPFv2 Router-LSA links and is beyond the scope this specification.
链接类型链接类型在[OSPFV2]的A.4.2节和“OSPFV2路由器LSA链接类型（值1）”注册表中定义<http://www.iana.org/assignments/ospfv2-parameters>. 除已定义的链路类型外，链路类型的规范将防止与现有OSPFv2路由器LSA链路相关，并且超出本规范的范围。
Link ID Link ID is defined in Section A.4.2 of [OSPFV2].
链路ID链路ID在[OSPFV2]第A.4.2节中定义。
Link Data Link Data is defined in Section A.4.2 of [OSPFV2].
链路数据链路数据在[OSPFV2]第A.4.2节中定义。
If this TLV is advertised multiple times in the same OSPFv2 Extended Link Opaque LSA, only the first instance of the TLV is used by receiving OSPFv2 routers. This situation SHOULD be logged as an error.
如果此TLV在同一OSPFv2扩展链路不透明LSA中多次播发，则接收OSPFv2路由器仅使用TLV的第一个实例。这种情况应记录为错误。
If this TLV is advertised multiple times for the same link in different OSPFv2 Extended Link Opaque LSAs originated by the same OSPFv2 router, the OSPFv2 Extended Link TLV in the OSPFv2 Extended Link Opaque LSA with the smallest Opaque ID is used by receiving OSPFv2 routers. This situation may be logged as a warning.
如果该TLV针对由同一OSPFv2路由器发起的不同OSPFv2扩展链路不透明LSA中的同一链路多次播发，则接收OSPFv2路由器将使用OSPFv2扩展链路不透明LSA中具有最小不透明ID的OSPFv2扩展链路TLV。这种情况可能被记录为警告。
It is RECOMMENDED that OSPFv2 routers advertising OSPFv2 Extended Link TLVs in different OSPFv2 Extended Link Opaque LSAs re-originate these LSAs in ascending order of Opaque ID to minimize the disruption.
建议在不同的OSPFv2扩展链路不透明LSA中宣传OSPFv2扩展链路TLV的OSPFv2路由器按照不透明ID的升序重新发起这些LSA，以尽量减少中断。
This document creates a registry for OSPFv2 Extended Link sub-TLVs in Section 6.
本文件为第6节中的OSPFv2扩展链路子TLV创建了一个注册表。
Since Opaque OSPFv2 LSAs are optional and backward compatible [OPAQUE], the extensions described herein are fully backward compatible. However, future OSPFv2 applications utilizing these extensions MUST address backward compatibility of the corresponding functionality.
由于不透明OSPFv2 LSA是可选的且向后兼容[不透明]，因此本文描述的扩展是完全向后兼容的。然而，未来使用这些扩展的OSPFv2应用程序必须解决相应功能的向后兼容性问题。
In general, new LSAs defined in this document are subject to the same security concerns as those described in [OSPFV2] and [OPAQUE].
一般而言，本文件中定义的新LSA受到与[OSPFV2]和[不透明]中所述相同的安全问题的影响。
OSPFv2 applications utilizing these OSPFv2 extensions must define the security considerations relating to those applications in the specifications corresponding to those applications.
使用这些OSPFv2扩展的OSPFv2应用程序必须在与这些应用程序对应的规范中定义与这些应用程序相关的安全注意事项。
Additionally, implementations must assure that malformed TLV and sub-TLV permutations are detected and do not provide a vulnerability for attackers to crash the OSPFv2 router or routing process. Malformed LSAs MUST NOT be stored in the Link State Database (LSDB), acknowledged, or reflooded. Reception of malformed LSAs SHOULD be counted and/or logged for further analysis. In this context, a malformed LSA is one that cannot be parsed due to a TLV or sub-TLV overrunning the end of the subsuming LSA, TLV, or sub-TLV or where there is data remaining to be parsed but the length of the remaining data is less than the size of a TLV header.
此外，实现必须确保检测到格式错误的TLV和子TLV排列，并且不会为攻击者提供使OSPFv2路由器或路由进程崩溃的漏洞。格式错误的LSA不得存储在链路状态数据库（LSDB）、已确认或重新加载中。应统计和/或记录接收到的错误LSA，以便进一步分析。在此上下文中，格式错误的LSA是由于TLV或子TLV溢出了子消费LSA、TLV或子TLV的末尾，或者存在要解析的剩余数据，但剩余数据的长度小于TLV标头的大小而无法解析的LSA。
This specification updates the "Opaque Link-State Advertisements (LSA) Option Types" registry with the following values:
本规范使用以下值更新“不透明链接状态播发（LSA）选项类型”注册表：
o 7 - OSPFv2 Extended Prefix Opaque LSA
o 7-OSPFv2扩展前缀不透明LSA
o 8 - OSPFv2 Extended Link Opaque LSA
o 8-OSPFv2扩展链路不透明LSA
This specification also creates five new registries:
本规范还创建了五个新的注册表：
o OSPFv2 Extended Prefix Opaque LSA TLVs
o OSPFv2扩展前缀不透明LSA TLV
o OSPFv2 Extended Prefix TLV Sub-TLVs
o OSPFv2扩展前缀TLV子TLV
o OSPFv2 Extended Prefix TLV Flags
o OSPFv2扩展前缀TLV标志
o OSPFv2 Extended Link Opaque LSA TLVs
o OSPFv2扩展链路不透明LSA TLV
o OSPFv2 Extended Link TLV Sub-TLVs
o OSPFv2扩展链路TLV子TLV
The "OSPFv2 Extend Prefix Opaque LSA TLVs" registry defines top-level TLVs for OSPFv2 Extended Prefix Opaque LSAs and has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval [RFC5226].
“OSPFv2扩展前缀不透明LSA TLV”注册表为OSPFv2扩展前缀不透明LSA定义顶级TLV，并已添加到“开放最短路径优先v2（OSPFv2）参数”注册表中。可通过IETF审查或IESG批准[RFC5226]分配新值。
The following initial values have been allocated:
已分配以下初始值：
o 0 - Reserved
o 0-保留
o 1 - OSPFv2 Extended Prefix TLV
o 1-OSPFv2扩展前缀TLV
Types in the range 32768-33023 are for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
32768-33023范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA considerations covering the range being assigned.
此时不分配33024-65535范围内的类型。在33024-65535范围内进行任何分配之前，必须有一个IETF规范，其中规定了涵盖所分配范围的IANA注意事项。
The "OSPFv2 Extended Prefix TLV Sub-TLVs" registry defines sub-TLVs at any level of nesting for OSPFv2 Extended Prefix TLVs and has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.
“OSPFv2扩展前缀TLV子TLV”注册表为OSPFv2扩展前缀TLV定义任何嵌套级别的子TLV，并已添加到“开放最短路径优先v2（OSPFv2）参数”注册表中。可通过IETF审查或IESG批准分配新值。
The following initial value has been allocated:
已分配以下初始值：
o 0 - Reserved
o 0-保留
Types in the range 32768-33023 are for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
32768-33023范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA considerations covering the range being assigned.
此时不分配33024-65535范围内的类型。在33024-65535范围内进行任何分配之前，必须有一个IETF规范，其中规定了涵盖所分配范围的IANA注意事项。
The "OSPFv2 Extended Prefix TLV Flags" registry defines the bits in the 8-bit OSPFv2 Extended Prefix TLV Flags (Section 2.1). This specification defines the A (0x80) and N (0x40) bits. This registry has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.
“OSPFv2扩展前缀TLV标志”注册表定义了8位OSPFv2扩展前缀TLV标志中的位（第2.1节）。本规范定义了A（0x80）和N（0x40）位。此注册表已添加到“开放最短路径优先v2（OSPFv2）参数”注册表中。可通过IETF审查或IESG批准分配新值。
The "OSPFv2 Extended Link Opaque LSA TLVs" registry defines top-level TLVs for OSPFv2 Extended Link Opaque LSAs and has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.
“OSPFv2扩展链路不透明LSA TLV”注册表为OSPFv2扩展链路不透明LSA定义顶级TLV，并已添加到“开放最短路径优先v2（OSPFv2）参数”注册表中。可通过IETF审查或IESG批准分配新值。
The following initial values have been allocated:
已分配以下初始值：
o 0 - Reserved
o 0-保留
o 1 - OSPFv2 Extended Link TLV
o 1-OSPFv2扩展链路TLV
Types in the range 32768-33023 are for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
32768-33023范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA considerations covering the range being assigned.
此时不分配33024-65535范围内的类型。在33024-65535范围内进行任何分配之前，必须有一个IETF规范，其中规定了涵盖所分配范围的IANA注意事项。
The "OSPFv2 Extended Link TLV Sub-TLVs" registry defines sub-TLVs at any level of nesting for OSPFv2 Extended Link TLVs and has been added to the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. New values can be allocated via IETF Review or IESG Approval.
“OSPFv2扩展链路TLV子TLV”注册表为OSPFv2扩展链路TLV定义任何嵌套级别的子TLV，并已添加到“开放最短路径优先v2（OSPFv2）参数”注册表中。可通过IETF审查或IESG批准分配新值。
The following initial value has been allocated:
已分配以下初始值：
o 0 - Reserved
o 0-保留
Types in the range 32768-33023 are for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
32768-33023范围内的类型用于实验用途；这些将不会在IANA注册，RFC不得提及。
Types in the range 33024-65535 are not to be assigned at this time. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA considerations covering the range being assigned.
此时不分配33024-65535范围内的类型。在33024-65535范围内进行任何分配之前，必须有一个IETF规范，其中规定了涵盖所分配范围的IANA注意事项。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, <http://www.rfc-editor.org/info/rfc5250>.
[不透明]Berger，L.，Bryskin，I.，Zinin，A.，和R.Coltun，“OSPF不透明LSA选项”，RFC 5250，DOI 10.17487/RFC5250，2008年7月<http://www.rfc-editor.org/info/rfc5250>.
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[OSPFV2]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<http://www.rfc-editor.org/info/rfc2328>.
[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[OSPFv3-EXTEND] Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 LSA Extendibility", Work in Progress, draft-ietf-ospf-ospfv3-lsa-extend-08, October 2015.
[OSPFv3扩展]Lindem，A.，Mirtorabi，S.，Roy，A.，和F.Baker，“OSPFv3 LSA可扩展性”，正在进行的工作，草稿-ietf-ospf-OSPFv3-LSA-EXTEND-082015年10月。
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, <http://www.rfc-editor.org/info/rfc3101>.
[RFC3101]Murphy，P.，“OSPF不那么短的区域（NSSA）选项”，RFC 3101，DOI 10.17487/RFC3101，2003年1月<http://www.rfc-editor.org/info/rfc3101>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[SEGMENT-ROUTING] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-05, June 2015.
[SEGMENT-ROUTING]Psenak，P.，Previdi，S.，Filsfils，C.，Gredler，H.，Shakir，R.，Henderickx，W.，和J.Tantsura，“用于段路由的OSPF扩展”，正在进行的工作，草案-ietf-OSPF-SEGMENT-ROUTING-Extensions-052015年6月。
Acknowledgements
致谢
We would like to thank Anton Smirnov for his contribution.
我们要感谢安东·斯米尔诺夫的贡献。
Thanks to Tony Przygienda for his review and comments.
感谢Tony Przygienda的评论和评论。
Thanks to Wim Henderickx, Greg Harkins, Peter Psenak, Eric Wu, Shraddha Hegde, and Csaba Mate for their responses to the implementation survey.
感谢Wim Henderickx、Greg Harkins、Peter Psenak、Eric Wu、Shraddha Hegde和Csaba Mate对实施调查的回复。
Thanks to Tom Petch and Chris Bowers for review and comments.
感谢Tom Petch和Chris Bowers的评论和评论。
Thanks to Alia Atlas and Alvaro Retana for their AD review and comments.
感谢Alia Atlas和Alvaro Retana的广告评论和评论。
Thanks to Carlos Pignataro and Ron Bonica for Operations Directorate review and comments.
感谢卡洛斯·皮格纳塔罗（Carlos Pignataro）和罗恩·博尼卡（Ron Bonica）对运营董事会的审查和评论。
Thanks to Suresh Krishnan for the Gen-ART review and comments.
感谢Suresh Krishnan对Gen ART的评论和评论。
Thanks to Ben Campbell, Kathleen Moriarty, and Barry Leiba for IESG review and comments.
感谢Ben Campbell、Kathleen Moriarty和Barry Leiba对IESG的评论和评论。
Authors' Addresses
作者地址
Peter Psenak Cisco Systems Apollo Business Center Mlynske nivy 43 Bratislava, 821 09 Slovakia Email: ppsenak@cisco.com
Peter Psenak思科系统阿波罗商业中心Mlynske nivy 43布拉迪斯拉发821 09斯洛伐克电子邮件：ppsenak@cisco.com
Hannes Gredler Independent Email: hannes@gredler.at
Hannes Gredler独立电子邮件：hannes@gredler.at
Rob Shakir Jive Communications, Inc. 1275 W 1600 N, Suite 100 Orem, UT 84057 United States Email: rjs@rob.sh
Rob Shakir Jive Communications，Inc.美国犹他州奥勒姆100号套房，邮编：1275 W 1600 N 84057电子邮件：rjs@rob.sh
Wim Henderickx Alcatel-Lucent Copernicuslaan Antwerp, 2018 94089 Belgium Email: wim.henderickx@alcatel-lucent.com
Wim Henderickx Alcatel-Lucent Copernicuslaan安特卫普，2018 94089比利时电子邮件：Wim。henderickx@alcatel-朗讯网
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States Email: jeff.tantsura@ericsson.com
Jeff Tantsura Ericsson加利福尼亚州圣何塞霍尔格大道300号，邮编95134美国电子邮件：Jeff。tantsura@ericsson.com
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States Email: acee@cisco.com
Acee Lindem Cisco Systems 301美国北卡罗来纳州米登霍尔大道卡里27513号电子邮件：acee@cisco.com