Internet Engineering Task Force (IETF) A. Lindem, Ed.
Request for Comments: 7770 N. Shen
Obsoletes: 4970 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Arktan
S. Shaffer
Akamai
February 2016
Internet Engineering Task Force (IETF) A. Lindem, Ed.
Request for Comments: 7770 N. Shen
Obsoletes: 4970 JP. Vasseur
Category: Standards Track Cisco Systems
ISSN: 2070-1721 R. Aggarwal
Arktan
S. Shaffer
Akamai
February 2016
Extensions to OSPF for Advertising Optional Router Capabilities
OSPF的扩展，用于宣传可选路由器功能
Abstract
摘要
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.
OSPFv2或OSPFv3路由域中的路由器了解其邻居和路由域中其他路由器的能力非常有用。本文档建议对OSPFv2和OSPFv3进行扩展，以宣传可选路由器功能。路由器信息（RI）链路状态通告（LSA）是为此目的定义的。在OSPFv2中，RI LSA将使用不透明的LSA类型ID实现。在OSPFv3中，RI LSA将使用唯一的LSA类型功能代码实现。在这两个协议中，RI LSA可以在任何定义的泛洪作用域（链路、区域或自治系统（AS））上公布。本文件通过提供修订的规范淘汰RFC 4970，该规范包括对RI LSA多个实例和功能能力TLV的广告支持。
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/rfc7770.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7770.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3
2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 4
2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4
2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 5
2.3. OSPF Router Information LSA TLV Format . . . . . . . . . 6
2.4. OSPF Router Informational Capabilities TLV . . . . . . . 6
2.5. Assigned OSPF Router Informational Capability Bits . . . 7
2.6. OSPF Router Functional Capabilities TLV . . . . . . . . . 8
2.7. Flooding Scope of the Router Information LSA . . . . . . 9
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 10
5.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 10
5.3. OSPF RI LSA TLV Type Assignment . . . . . . . . . . . . . 11
5.4. Registry for OSPF Router Informational Capability Bits . 12
5.5. Registry for OSPF Router Functional Capability Bits . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Summary of Changes from RFC 4970 . . . . . . . . . . . . 3
2. OSPF Router Information (RI) LSA . . . . . . . . . . . . . . 4
2.1. OSPFv2 Router Information (RI) Opaque LSA . . . . . . . . 4
2.2. OSPFv3 Router Information (RI) Opaque LSA . . . . . . . . 5
2.3. OSPF Router Information LSA TLV Format . . . . . . . . . 6
2.4. OSPF Router Informational Capabilities TLV . . . . . . . 6
2.5. Assigned OSPF Router Informational Capability Bits . . . 7
2.6. OSPF Router Functional Capabilities TLV . . . . . . . . . 8
2.7. Flooding Scope of the Router Information LSA . . . . . . 9
3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . . 10
5.2. OSPFv3 LSA Function Code Assignment . . . . . . . . . . . 10
5.3. OSPF RI LSA TLV Type Assignment . . . . . . . . . . . . . 11
5.4. Registry for OSPF Router Informational Capability Bits . 12
5.5. Registry for OSPF Router Functional Capability Bits . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFv3] routing domain to know the capabilities of their neighbors and other routers in the routing domain. This can be useful for both the advertisement and discovery of OSPFv2 and OSPFv3 capabilities. Throughout this document, OSPF will be used when the specification is applicable to both OSPFv2 and OSPFv3. Similarly, OSPFv2 or OSPFv3 will be used when the text is protocol specific.
OSPFv2[OSPF]或OSPFv3[OSPFv3]路由域中的路由器了解其邻居和路由域中其他路由器的能力非常有用。这对于OSPFv2和OSPFv3功能的发布和发现都很有用。在本文件中，当规范同时适用于OSPFv2和OSPFv3时，将使用OSPF。类似地，当文本特定于协议时，将使用OSPFv2或OSPFv3。
OSPF uses the options field in LSAs and hello packets to advertise optional router capabilities. In the case of OSPFv2, all the bits in this field have been allocated so additional optional capabilities cannot be advertised. This document describes extensions to OSPF to advertise these optional capabilities via Opaque LSAs in OSPFv2 and LSAs with a unique type in OSPFv3. For existing OSPF capabilities, backwards compatibility issues dictate that this advertisement is used primarily for informational purposes. For future OSPF extensions, this advertisement MAY be used as the sole mechanism for advertisement and discovery.
OSPF使用LSA和hello数据包中的选项字段来公布可选的路由器功能。在OSPFv2的情况下，此字段中的所有位都已分配，因此无法公布其他可选功能。本文档描述了OSPF的扩展，以通过OSPFv2中的不透明LSA和OSPFv3中具有唯一类型的LSA宣传这些可选功能。对于现有的OSPF功能，向后兼容性问题表明此公告主要用于信息目的。对于未来的OSPF扩展，此播发可以用作播发和发现的唯一机制。
This document obsoletes RFC 4970 by providing a revised specification including support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.
本文件通过提供修订后的规范（包括支持发布多个RI LSA实例和功能能力TLV），淘汰了RFC 4970。
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-KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-关键词]中所述进行解释。
This document includes the following changes from RFC 4970 [RFC4970]:
本文件包括对RFC 4970[RFC4970]的以下更改：
1. The main change is that an OSPF router will be able to advertise multiple instances of the OSPF Router Information LSA. This change permeates through much of the document.
1. 主要的变化是，OSPF路由器将能够公布OSPF路由器信息LSA的多个实例。这一变化贯穿了文件的大部分内容。
2. Additionally, Section 2.6 includes an additional TLV for functional capabilities. This is in contrast to the existing TLV that is used to advertise capabilities for informational purposes only.
2. 此外，第2.6节还包括功能能力的附加TLV。这与现有的TLV不同，TLV仅用于宣传功能以供参考。
3. The IANA allocation policy has been changed from "Standards Action" to "IETF Review" [IANA-GUIDE] for the following registries:
3. 对于以下注册中心，IANA分配政策已从“标准行动”更改为“IETF审查”[IANA-GUIDE]：
o OSPFv3 LSA Function Codes o OSPF Router Information (RI) TLVs o OSPF Router Informational Capability Bits o OSPF Router Functional Capability Bits
o OSPFv3 LSA功能代码o OSPF路由器信息（RI）TLVs o OSPF路由器信息能力位o OSPF路由器功能能力位
4. Finally, references have been updated for documents that have become RFCs and RFCs that have been obsoleted since the publication of RFC 4970.
4. 最后，更新了已成为RFC的文件和自RFC 4970出版以来已废弃的RFC的参考文献。
OSPFv2 routers will advertise a link scoped, area-scoped, or AS-scoped Opaque LSA [OPAQUE]. The OSPFv2 RI LSA has an Opaque type of 4 and the Opaque ID is the RI LSA Instance ID. The first Opaque ID, i.e., 0, SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV. RI LSA instances subsequent to the first can be used for information that doesn't fit in the first instance.
OSPFv2路由器将公布链路范围、区域范围或AS范围不透明LSA[不透明]。OSPFv2 RI LSA的不透明类型为4，不透明ID为RI LSA实例ID。第一个不透明ID（即0）应始终包含路由器信息能力TLV，如果公布，还应包含路由器功能能力TLV。第一个实例之后的RI LSA实例可用于不适合第一个实例的信息。
OSPFv2 routers will advertise a link-scoped, area-scoped, or AS-scoped Opaque LSA [OPAQUE]. The OSPFv2 Router Information LSA has an Opaque type of 4. The Opaque ID specifies the LSA Instance ID with the first instance always having an Instance ID of 0.
OSPFv2路由器将公布链路范围、区域范围或AS范围不透明LSA[不透明]。OSPFv2路由器信息LSA的不透明类型为4。不透明ID指定LSA实例ID，第一个实例的实例ID始终为0。
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 | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Opaque ID (Instance ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+d-+-+-+-+-+-+-+-+-+-+-+
| 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 | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | Opaque ID (Instance ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+d-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 1. OSPFv2 Router Information Opaque LSA
图1。OSPFv2路由器信息不透明LSA
The format of the TLVs within the body of an RI LSA is as defined in Section 2.3.
RI LSA主体内TLV的格式如第2.3节所述。
The OSPFv3 Router Information LSA has a function code of 12 while the S1/S2 bits are dependent on the desired flooding scope for the LSA. The U bit will be set indicating that the OSPFv3 RI LSA should be flooded even if it is not understood. The Link State ID (LSID) value for this LSA is the Instance ID. The first Instance ID, i.e., 0, SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV. OSPFv3 Router Information LSAs subsequent to the first can be used for information that doesn't fit in the first instance. OSPFv3 routers MAY advertise multiple RI LSAs per flooding scope.
OSPFv3路由器信息LSA的功能代码为12，而S1/S2位取决于LSA的期望泛洪范围。U位将被设置，指示即使无法理解OSPFv3 RI LSA，也应被淹没。此LSA的链路状态ID（LSID）值为实例ID。第一个实例ID（即0）应始终包含路由器信息能力TLV，如果公布，则包含路由器功能能力TLV。第一个实例之后的OSPFv3路由器信息LSA可用于不适合第一个实例的信息。OSPFv3路由器可根据泛洪范围播发多个RI 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 |1|S12| 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (Instance 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 |1|S12| 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (Instance ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
Figure 2. OSPFv3 Router Information LSA
图2。OSPFv3路由器信息LSA
The format of the TLVs within the body of an RI LSA is as defined in Section 2.3
RI LSA主体内TLV的格式如第2.3节所述
The format of the TLVs within the body of an RI LSA is the same as the format used by the Traffic Engineering Extensions to OSPF [TE]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is:
RI LSA主体内TLV的格式与OSPF[TE]的流量工程扩展使用的格式相同。LSA有效负载由一个或多个嵌套类型/长度/值（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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. TLV Format
图3。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 4-octet aligned. For example, a 1-octet 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 undefined bits. Unrecognized types are ignored.
长度字段以八位字节定义值部分的长度（因此，没有值部分的TLV的长度为0）。TLV填充为4-八位组对齐；长度字段中不包括填充（因此3个八位字节的值的长度为3，但TLV的总大小为8个八位字节）。嵌套TLV也是4-八位组对齐的。例如，一个1-octet值将把length字段设置为1，3个八位字节的填充将添加到TLV值部分的末尾。填充由未定义的位组成。将忽略无法识别的类型。
When a new Router Information LSA TLV is defined, the specification MUST explicitly state whether the TLV is applicable to OSPFv2 only, OSPFv3 only, or both OSPFv2 and OSPFv3.
定义新路由器信息LSA TLV时，规范必须明确说明TLV是否仅适用于OSPFv2、OSPFv3或OSPFv2和OSPFv3。
An OSPF router advertising an OSPF RI LSA MAY include the Router Informational Capabilities TLV. If included, it MUST be the first TLV in the first instance, i.e., Instance 0, of the OSPF RI LSA. Additionally, the TLV MUST accurately reflect the OSPF router's capabilities in the scope advertised. However, the informational capabilities advertised have no impact on OSPF protocol operation; they are advertised purely for informational purposes.
宣传OSPF RI LSA的OSPF路由器可以包括路由器信息能力TLV。如果包括，它必须是OSPF RI LSA的第一个实例（即实例0）中的第一个TLV。此外，TLV必须准确反映所宣传范围内OSPF路由器的能力。然而，宣传的信息能力对OSPF协议的运行没有影响；这些广告纯粹是为了提供信息。
The format of the Router Informational Capabilities TLV is as follows:
路由器信息功能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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Informational Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Informational Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A 16-bit field set to 1.
键入设置为1的16位字段。
Length A 16-bit field that indicates the length of the value portion in octets and will be a multiple of 4 octets dependent on the number of capabilities advertised. Initially, the length will be 4, denoting 4 octets of informational capability bits.
长度一个16位字段，以八位字节表示值部分的长度，是4个八位字节的倍数，具体取决于播发的功能数量。最初，长度为4，表示信息能力位的4个八位字节。
Value A variable-length sequence of capability bits rounded to a multiple of 4 octets padded with undefined bits. Initially, there are 4 octets of capability bits. Bits are numbered left to right starting with the most significant bit being bit 0.
值功能位的可变长度序列，舍入为4个八位字节的倍数，并填充未定义的位。最初，有4个八位字节的能力位。位从左到右编号，最高有效位为位0。
Figure 4. OSPF Router Informational Capabilities TLV
图4。OSPF路由器信息功能TLV
The Router Informational Capabilities TLV MAY be followed by optional TLVs that further specify a capability.
路由器信息能力TLV后面可能是进一步指定能力的可选TLV。
The following informational capability bits have been assigned:
已分配以下信息能力位：
Bit Capabilities
比特能力
0 OSPF graceful restart capable [GRACE]
1 OSPF graceful restart helper [GRACE]
2 OSPF Stub Router support [STUB]
3 OSPF Traffic Engineering support [TE]
4 OSPF point-to-point over LAN [P2PLAN]
5 OSPF Experimental TE [EXP-TE]
6-31 Unassigned (IETF Review)
0 OSPF graceful restart capable [GRACE]
1 OSPF graceful restart helper [GRACE]
2 OSPF Stub Router support [STUB]
3 OSPF Traffic Engineering support [TE]
4 OSPF point-to-point over LAN [P2PLAN]
5 OSPF Experimental TE [EXP-TE]
6-31 Unassigned (IETF Review)
Figure 5. OSPF Router Informational Capabilities Bits
图5。路由器信息能力
References for [GRACE], [STUB], [TE], [P2PLAN], and [EXP-TE] are included herein.
此处包括[GRACE]、[STUB]、[TE]、[P2PLAN]和[EXP-TE]的参考文献。
This specification also defines the Router Functional Capabilities TLV for advertisement in the OSPF Router Information LSA. An OSPF router advertising an OSPF RI LSA MAY include the Router Functional Capabilities TLV. If included, it MUST be the included in the first instance of the LSA. Additionally, the TLV MUST reflect the advertising OSPF router's actual functional capabilities since the information will be used to dictate OSPF protocol operation in the flooding scope of the containing OSPF RI LSA. If the TLV is not included or the length doesn't include the assigned OSPF functional capability bit, the corresponding OSPF functional capability is implicitly advertised as not being supported by the advertising OSPF router.
本规范还定义了用于在OSPF路由器信息LSA中发布的路由器功能能力TLV。宣传OSPF RI LSA的OSPF路由器可以包括路由器功能能力TLV。如果包含，则它必须包含在LSA的第一个实例中。此外，TLV必须反映广告OSPF路由器的实际功能能力，因为该信息将用于指示包含OSPF RI LSA的泛洪范围内的OSPF协议操作。如果不包括TLV或长度不包括分配的OSPF功能性能力位，则相应的OSPF功能性能力被隐式广告为不受广告OSPF路由器支持。
The format of the Router Functional Capabilities TLV is as follows:
路由器功能能力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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Functional Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Functional Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A 16-bit field set to 2.
键入设置为2的16位字段。
Length A 16-bit field that indicates the length of the value portion in octets and will be a multiple of 4 octets dependent on the number of capabilities advertised. Initially, the length will be 4, denoting 4 octets of informational capability bits.
长度一个16位字段，以八位字节表示值部分的长度，是4个八位字节的倍数，具体取决于播发的功能数量。最初，长度为4，表示信息能力位的4个八位字节。
Value A variable-length sequence of capability bits rounded to a multiple of 4 octets padded with undefined bits. Initially, there are 4 octets of capability bits. Bits are numbered left to right starting with the most significant bit being bit 0.
值功能位的可变长度序列，舍入为4个八位字节的倍数，并填充未定义的位。最初，有4个八位字节的能力位。位从左到右编号，最高有效位为位0。
Figure 6. OSPF Router Functional Capabilities TLV
图6。OSPF路由器功能TLV
The Router Functional Capabilities TLV MAY be followed by optional TLVs that further specify a capability. In contrast to the Router Informational Capabilities TLV, the OSPF extensions advertised in this TLV MAY be used by other OSPF routers to dictate protocol operation. The specifications for functional capabilities advertised in this TLV MUST describe protocol behavior and address backwards compatibility.
路由器功能能力TLV后面可能是进一步指定功能的可选TLV。与路由器信息能力TLV不同，在该TLV中公布的OSPF扩展可被其他OSPF路由器用于指示协议操作。本TLV中公布的功能功能规范必须描述协议行为并解决向后兼容性问题。
The flooding scope for a Router Information LSA is determined by the LSA type. For OSPFv2, a type 9 (link-scoped), type 10 (area-scoped), or type 11 (AS-scoped) Opaque LSA may be flooded. For OSPFv3, the S1 and S2 bits in the LSA type determine the flooding scope. If AS-wide flooding scope is chosen, the originating router should also advertise area-scoped LSA(s) into any attached Not-So-Stubby Area (NSSA) area(s). An OSPF router MAY advertise different capabilities when both NSSA area-scoped LSA(s) and an AS-scoped LSA are advertised. This allows functional capabilities to be limited in scope. For example, a router may be an area border router but only support traffic engineering (TE) in a subset of its attached areas.
路由器信息LSA的泛洪范围由LSA类型确定。对于OSPFv2，类型9（链路范围）、类型10（区域范围）或类型11（范围相同）不透明LSA可能被淹没。对于OSPFv3，LSA类型中的S1和S2位确定泛洪范围。如果选择宽泛洪范围，则发起路由器还应将区域范围的LSA播发到任何连接的非短截线区域（NSSA）区域。当NSSA区域作用域LSA和AS作用域LSA都被通告时，OSPF路由器可以通告不同的功能。这使得功能能力的范围受到限制。例如，路由器可以是区域边界路由器，但仅支持其连接区域的子集中的流量工程（TE）。
The choice of flooding scope is made by the advertising router and is a matter of local policy. The originating router MAY advertise multiple RI LSAs with the same Instance ID as long as the flooding scopes differ. TLV flooding-scope rules will be specified on a per-TLV basis and MUST be specified in the accompanying specifications for future Router Information LSA TLVs.
泛洪范围的选择由广告路由器决定，并由当地政策决定。只要泛洪作用域不同，发起路由器就可以通告具有相同实例ID的多个RI lsa。TLV泛洪范围规则将在每个TLV的基础上指定，并且必须在随附的规范中指定，以用于将来的路由器信息LSA TLV。
For backwards compatibility, previously advertised Router Information TLVs SHOULD continue to be advertised in the first instance, i.e., 0, of the Router Information LSA. If a Router Information TLV is advertised in multiple Router Information LSA instances and the multiple instance processing is not explicitly specified in the RFC defining that Router Information TLV, the Router Instance TLV in the Router Information LSA with the numerically smallest Instance ID will be used and subsequent instances will be ignored.
为了向后兼容，先前公布的路由器信息tlv应在路由器信息LSA的第一个实例（即0）中继续公布。如果在多个路由器信息LSA实例中公布路由器信息TLV，并且在定义该路由器信息TLV的RFC中未明确指定多实例处理，将使用路由器信息LSA中具有数字最小实例ID的路由器实例TLV，并忽略后续实例。
This document describes both a generic mechanism for advertising router capabilities and TLVs for advertising informational and functional capabilities. The capability TLVs are less critical than the topology information currently advertised by the base OSPF protocol. The security considerations for the generic mechanism are dependent on the future application and, as such, should be described as additional capabilities are proposed for advertisement. Security considerations for the base OSPF protocol are covered in [OSPF] and [OSPFv3].
本文档描述了用于宣传路由器功能的通用机制和用于宣传信息和功能功能的TLV。与基本OSPF协议当前公布的拓扑信息相比，TLV的能力不那么重要。通用机制的安全考虑因素取决于未来的应用，因此，应在建议发布附加功能时予以说明。[OSPF]和[OSPFv3]中介绍了基本OSPF协议的安全注意事项。
[RFC4970] defined the Router Information Opaque LSA as type 4 in the "Opaque Link-State Advertisements (LSA) Option Types" registry. IANA has updated the reference for that entry to point to this RFC.
[RFC4970]在“不透明链路状态播发（LSA）选项类型”注册表中将路由器信息不透明LSA定义为类型4。IANA已更新该条目的引用，以指向此RFC。
[RFC4970] created the registry for "OSPFv3 LSA Function Codes". IANA has updated the reference for that registry to point to this RFC. References within that registry to [RFC4970] have been updated to point to this RFC; references to other RFCs are unchanged.
[RFC4970]为“OSPFv3 LSA功能代码”创建了注册表。IANA已更新该注册表的引用以指向此RFC。该注册表中对[RFC4970]的引用已更新，以指向该RFC；对其他RFC的引用保持不变。
The definition and assignment policy has been updated as follows.
定义和分配政策已更新如下。
This registry is now comprised of the fields Value, LSA Function Code Name, and Reference. The OSPFv3 LSA function code is defined in Appendix A.4.2.1 of [OSPFv3]. Values 1-11 and 13-15 have already been assigned. The OSPFv3 LSA function code 12 has been assigned to the OSPFv3 Router Information (RI) LSA as defined herein.
该注册表现在由字段值、LSA函数代码名和引用组成。OSPFv3 LSA功能代码在[OSPFv3]的附录A.4.2.1中定义。已指定值1-11和13-15。已将OSPFv3 LSA功能代码12分配给如本文所定义的OSPFv3路由器信息（RI）LSA。
+-----------+-------------------------------------+
| Range | Assignment Policy |
+-----------+-------------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 16-255 | Unassigned (IETF Review) |
| | |
| 256-8175 | Reserved (No assignments) |
| | |
| 8176-8183 | Experimentation (No assignments) |
| | |
| 8184-8190 | Vendor Private Use (No assignments) |
| | |
| 8191 | Reserved (not to be assigned) |
+-----------+-------------------------------------+
+-----------+-------------------------------------+
| Range | Assignment Policy |
+-----------+-------------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 16-255 | Unassigned (IETF Review) |
| | |
| 256-8175 | Reserved (No assignments) |
| | |
| 8176-8183 | Experimentation (No assignments) |
| | |
| 8184-8190 | Vendor Private Use (No assignments) |
| | |
| 8191 | Reserved (not to be assigned) |
+-----------+-------------------------------------+
Figure 7. OSPFv3 LSA Function Codes
图7。OSPFv3 LSA功能代码
o The assignment policy for OSPFv3 LSA function codes in the range 16-255 has changed and are now assigned subject to IETF Review. New values are assigned through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG documents [IANA-GUIDE].
o 范围为16-255的OSPFv3 LSA功能代码的分配政策已更改，现根据IETF审查进行分配。新值通过RFC分配，RFC作为AD赞助文件或IETF工作组文件[IANA-GUIDE]通过IESG指导。
o OSPFv3 LSA function codes in the range 8176-8183 are for experimental use; these will not be registered with IANA and MUST NOT be mentioned by RFCs.
o 8176-8183范围内的OSPFv3 LSA功能代码用于实验用途；这些将不会在IANA注册，RFC不得提及。
o OSPFv3 LSAs with an LSA Function Code in the Vendor Private Use range 8184-8190 MUST include the Enterprise Code [ENTERPRISE-CODE] as the first 4 octets following the 20 octets of LSA header.
o LSA功能代码在供应商专用范围8184-8190的OSPFv3 LSA必须包括企业代码[Enterprise-Code]，作为LSA头20个八位字节后的前4个八位字节。
o If a new LSA Function Code is documented, the documentation MUST include the valid combinations of the U, S2, and S1 bits for the LSA. It SHOULD also describe how the Link State ID is to be assigned.
o 如果记录了新的LSA功能代码，则文件必须包括LSA的U、S2和S1位的有效组合。它还应该描述如何分配链路状态ID。
[RFC4970] created the registry for "OSPF Router Information (RI) TLVs". IANA has updated the reference for this registry to point to this RFC. References within that registry to [RFC4970] have been updated to point to this RFC; references to other RFCs are unchanged.
[RFC4970]为“OSPF路由器信息（RI）TLV”创建了注册表。IANA已更新此注册表的引用以指向此RFC。该注册表中对[RFC4970]的引用已更新，以指向该RFC；对其他RFC的引用保持不变。
The definition and assignment policy has been updated as follows.
定义和分配政策已更新如下。
The registry is now comprised of the fields Value, TLV Name, and Reference. Values 3-9 have already been assigned. Value 1 has been assigned to the Router Informational Capabilities TLV and value 2 has been assigned to the Router Functional Capabilities TLV as defined herein.
注册表现在由字段值、TLV名称和引用组成。已指定值3-9。值1已分配给路由器信息能力TLV，值2已分配给本文定义的路由器功能能力TLV。
+-------------+-----------------------------------+
| Range | Assignment Policy |
+-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 10-32767 | Unassigned (IETF Review) |
| | |
| 32768-32777 | Experimentation (No assignments) |
| | |
| 32778-65535 | Reserved (Not to be assigned) |
+-------------+-----------------------------------+
+-------------+-----------------------------------+
| Range | Assignment Policy |
+-------------+-----------------------------------+
| 0 | Reserved (not to be assigned) |
| | |
| 10-32767 | Unassigned (IETF Review) |
| | |
| 32768-32777 | Experimentation (No assignments) |
| | |
| 32778-65535 | Reserved (Not to be assigned) |
+-------------+-----------------------------------+
Figure 8. OSPF RI TLVs
图8。OSPF RI TLV
o Types in the range 10-32767 are to be assigned subject to IETF Review. New values are assigned through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG documents [IANA-GUIDE].
o 10-32767范围内的类型将根据IETF审查进行分配。新值通过RFC分配，RFC作为AD赞助文件或IETF工作组文件[IANA-GUIDE]通过IESG指导。
o Types in the range 32778-65535 are reserved and 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 cover the range being assigned.
o 32778-65535范围内的类型为保留类型，此时不进行分配。在此范围内进行任何分配之前，必须有一个标准跟踪RFC，指定涵盖所分配范围的IANA注意事项。
[RFC4970] created the registry for "OSPF Router Informational Capability Bits". IANA has updated the reference for this registry to point to this RFC. The definition and assignment policy has been updated as follows.
[RFC4970]为“OSPF路由器信息能力位”创建了注册表。IANA已更新此注册表的引用以指向此RFC。定义和分配政策已更新如下。
o This registry is now comprised of the fields Bit Number, Capability Name, and Reference.
o 该注册表现在由字段位号、功能名称和引用组成。
o The values are defined in Section 2.6. All Router Informational Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE].
o 这些值在第2.6节中定义。所有增加的路由器信息能力TLV将通过IETF审查[IANA-GUIDE]进行分配。
IANA has created a subregistry for "OSPF Router Functional Capability Bits" within the "Open Shortest Path First v2 (OSPFv2) Parameters" registry. This subregistry is comprised of the fields Bit Number, Capability Name, and Reference. Initially, the subregistry will be empty but will be available for future capabilities. All Router Functional Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE].
IANA在“开放最短路径优先v2（OSPFv2）参数”注册表中为“OSPF路由器功能位”创建了一个子区。该子区域由字段位号、功能名称和引用组成。最初，该分区域将是空的，但可用于未来的能力。所有增加的路由器功能能力TLV将通过IETF审查[IANA-GUIDE]进行分配。
[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>.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<http://www.rfc-editor.org/info/rfc2328>.
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[OSPFv3]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC-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>.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 2007, <http://www.rfc-editor.org/info/rfc4970>.
[RFC4970]Lindem，A.，Ed.，Shen，N.，Vasseur，JP.，Aggarwal，R.，和S.Shaffer，“用于宣传可选路由器功能的OSPF扩展”，RFC 4970，DOI 10.17487/RFC4970，2007年7月<http://www.rfc-editor.org/info/rfc4970>.
[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>.
[ENTERPRISE-CODE] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, <http://www.rfc-editor.org/info/rfc5612>.
[企业代码]Eronen，P.和D.Harrington，“文件使用的企业编号”，RFC 5612，DOI 10.17487/RFC5612，2009年8月<http://www.rfc-editor.org/info/rfc5612>.
[EXP-TE] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering", RFC 4973, DOI 10.17487/RFC4973, July 2007, <http://www.rfc-editor.org/info/rfc4973>.
[EXP-TE]Srisuresh，P.和P.Joseph，“OSPF xTE：交通工程OSPF的实验扩展”，RFC 4973，DOI 10.17487/RFC4973，2007年7月<http://www.rfc-editor.org/info/rfc4973>.
[GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003, <http://www.rfc-editor.org/info/rfc3623>.
[GRACE]Moy，J.，Pillay Esnault，P.，和A.Lindem，“OSPF的优雅重启”，RFC 3623，DOI 10.17487/RFC3623，2003年11月<http://www.rfc-editor.org/info/rfc3623>.
[IANA-GUIDE] 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>.
[IANA-GUIDE]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[P2PLAN] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, <http://www.rfc-editor.org/info/rfc5309>.
[P2PLAN]Shen，N.，Ed.，和A.Zinin，Ed.，“链路状态路由协议下局域网上的点对点操作”，RFC 5309，DOI 10.17487/RFC5309，2008年10月<http://www.rfc-editor.org/info/rfc5309>.
[STUB] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <http://www.rfc-editor.org/info/rfc6987>.
[STUB]Retana，A.，Nguyen，L.，Zinin，A.，White，R.，和D.McPherson，“OSPF存根路由器广告”，RFC 6987，DOI 10.17487/RFC6987，2013年9月<http://www.rfc-editor.org/info/rfc6987>.
Acknowledgments
致谢
The idea for this work grew out of a conversation with Andrew Partan and we thank him for his contribution. The authors thank Peter Psenak for his review and helpful comments on early draft versions of the document.
这项工作的想法来源于与安德鲁·帕坦（Andrew Partan）的对话，我们感谢他的贡献。作者感谢Peter Psenak对该文件早期草稿的审查和有益的评论。
Special thanks to Tom Petch for providing the updated IANA text in this document.
特别感谢Tom Petch在本文档中提供了最新的IANA文本。
Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian Farrel have been incorporated into later draft versions of this document.
Abhay Roy、Vishwas Manral、Vivek Dubey和Adrian Farrel的意见已纳入本文件的后续草案版本。
Thanks to Yingzhen Qu for acting as document shepherd.
感谢瞿英珍担任文献管理员。
Thanks to Chris Bowers, Alia Atlas, Shraddha Hegde, Dan Romascanu, and Victor Kuarsingh for review of this document.
感谢Chris Bowers、Alia Atlas、Shraddha Hegde、Dan Romascanu和Victor Kuarsingh对本文件的审阅。
Authors' Addresses
作者地址
Acee Lindem (editor) Cisco Systems 301 Midenhall Way Cary, NC 27513 United States
Acee Lindem（编辑）思科系统301美国北卡罗来纳州米登霍尔大道卡里27513号
Email: acee@cisco.com
Email: acee@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞市西塔斯曼大道225号思科系统公司沈乃明95134
Email: naiming@cisco.com
Email: naiming@cisco.com
Jean-Philippe Vasseur Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 United States
Jean-Philippe Vasseur Cisco Systems美国马萨诸塞州Boxborough马萨诸塞大道1414号01719
Email: jpv@cisco.com
Email: jpv@cisco.com
Rahul Aggarwal Arktan
拉胡尔·阿加瓦尔·阿尔坦
Email: raggarwa_1@yahoo.com
Email: raggarwa_1@yahoo.com
Scott Shaffer Akamai 8 Cambridge Center Cambridge, MA 02142 United States
Scott Shaffer Akamai 8剑桥中心美国马萨诸塞州剑桥02142
Email: sshaffer@akamai.com
Email: sshaffer@akamai.com