Network Working Group P. Psenak
Request for Comments: 4915 Cisco Systems
Category: Standards Track S. Mirtorabi
Force10 Networks
A. Roy
L. Nguyen
P. Pillay-Esnault
Cisco Systems
June 2007
Network Working Group P. Psenak
Request for Comments: 4915 Cisco Systems
Category: Standards Track S. Mirtorabi
Force10 Networks
A. Roy
L. Nguyen
P. Pillay-Esnault
Cisco Systems
June 2007
Multi-Topology (MT) Routing in OSPF
OSPF中的多拓扑（MT）路由
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi-Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology.
本文档描述了开放最短路径优先（OSPF）的扩展，以定义称为多拓扑（MTs）的独立IP拓扑。多拓扑扩展可用于计算单播流量、多播流量、基于灵活标准的不同服务类别的不同路径，或带内网络管理拓扑。
An optional extension to exclude selected links from the default topology is also described.
还介绍了从默认拓扑中排除选定链接的可选扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Differences between Multi-Topology and TOS-Based
Routing . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Base MT Functional Specifications . . . . . . . . . . . . . . 4
3.1. MT Area Boundary . . . . . . . . . . . . . . . . . . . . . 4
3.2. Adjacency for MTs . . . . . . . . . . . . . . . . . . . . 4
3.3. Sending OSPF Control Packets . . . . . . . . . . . . . . . 5
3.4. Advertising MT Adjacencies and the Corresponding IP
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Inter-Area and External Routing . . . . . . . . . . . 5
3.5. Flushing MT Information . . . . . . . . . . . . . . . . . 6
3.6. MT SPF Computation . . . . . . . . . . . . . . . . . . . . 6
3.7. MT-ID Values . . . . . . . . . . . . . . . . . . . . . . . 6
3.8. Forwarding in MT . . . . . . . . . . . . . . . . . . . . . 6
4. Default Topology Link Exclusion Functional Specifications . . 7
4.1. Exclusion of Links in the Default Topology . . . . . . . . 7
4.2. New Area Data Structure Parameter . . . . . . . . . . . . 7
4.3. Adjacency Formation with Link Exclusion Capability . . . . 8
4.4. OSPF Control Packets Transmission over Excluded Links . . 9
4.5. OSPF LSA Advertisement and SPF Computation for
Excluded Links . . . . . . . . . . . . . . . . . . . . . . 9
5. Interoperability between MT-Capable and Non-MT-Capable
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Demand Circuit Compatibility Considerations . . . . . . . 10
6. Migration from Non-MT-Area to MT-Area . . . . . . . . . . . . 10
7. MT Network Management Considerations . . . . . . . . . . . . . 11
7.1. Create Dedicated Management Topology to Include All
the Nodes . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Extend the Default Topology to All the Nodes . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Appendix B. OSPF Data Formats . . . . . . . . . . . . . . . . . . 13
B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 15
B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 16
B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 17
B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Differences between Multi-Topology and TOS-Based
Routing . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Base MT Functional Specifications . . . . . . . . . . . . . . 4
3.1. MT Area Boundary . . . . . . . . . . . . . . . . . . . . . 4
3.2. Adjacency for MTs . . . . . . . . . . . . . . . . . . . . 4
3.3. Sending OSPF Control Packets . . . . . . . . . . . . . . . 5
3.4. Advertising MT Adjacencies and the Corresponding IP
Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Inter-Area and External Routing . . . . . . . . . . . 5
3.5. Flushing MT Information . . . . . . . . . . . . . . . . . 6
3.6. MT SPF Computation . . . . . . . . . . . . . . . . . . . . 6
3.7. MT-ID Values . . . . . . . . . . . . . . . . . . . . . . . 6
3.8. Forwarding in MT . . . . . . . . . . . . . . . . . . . . . 6
4. Default Topology Link Exclusion Functional Specifications . . 7
4.1. Exclusion of Links in the Default Topology . . . . . . . . 7
4.2. New Area Data Structure Parameter . . . . . . . . . . . . 7
4.3. Adjacency Formation with Link Exclusion Capability . . . . 8
4.4. OSPF Control Packets Transmission over Excluded Links . . 9
4.5. OSPF LSA Advertisement and SPF Computation for
Excluded Links . . . . . . . . . . . . . . . . . . . . . . 9
5. Interoperability between MT-Capable and Non-MT-Capable
Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Demand Circuit Compatibility Considerations . . . . . . . 10
6. Migration from Non-MT-Area to MT-Area . . . . . . . . . . . . 10
7. MT Network Management Considerations . . . . . . . . . . . . . 11
7.1. Create Dedicated Management Topology to Include All
the Nodes . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Extend the Default Topology to All the Nodes . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Appendix B. OSPF Data Formats . . . . . . . . . . . . . . . . . . 13
B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 15
B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 16
B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 17
B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 18
OSPF uses a fixed packet format, therefore it is not easy to introduce any backward-compatible extensions. However, the OSPF specification [OSPF] introduced Type of Service (TOS) metric in an earlier specification [TOS-OSPF] in order to announce a different link cost based on TOS. TOS-based routing as described in [TOS-OSPF] was never deployed and was subsequently deprecated. [M-ISIS] describes a similar mechanism for ISIS.
OSPF使用固定的数据包格式，因此不容易引入任何向后兼容的扩展。然而，OSPF规范[OSPF]在早期规范[TOS-OSPF]中引入了服务类型（TOS）度量，以便根据TOS宣布不同的链路成本。[TOS-OSPF]中描述的基于TOS的路由从未部署，随后被弃用。[M-ISIS]描述了ISIS的类似机制。
We propose to reuse the TOS-based metric fields. They have been redefined and are used to advertise different topologies by advertising separate metrics for each of them.
我们建议重用基于TOS的度量字段。它们已被重新定义，并通过为每个拓扑发布单独的度量来发布不同的拓扑。
Multi-Topology routing differs from [TOS-OSPF] TOS-based routing in the following ways:
多拓扑路由与基于[TOS-OSPF]TOS的路由有以下不同：
1. With TOS routing [TOS-OSPF], the TOS or Diffserv Code Point (DSCP) in the IP header is mapped directly to the corresponding OSPF SPF calculation and routing table. This limits the number and definition of the topologies to the 16 TOS values specified in Section 12.3 of [TOS-OSPF]. With Multi-Topology routing, the classification of what type of traffic maps to which topology is not within the scope of this document.
1. 使用TOS路由[TOS-OSPF]，IP报头中的TOS或Diffserv代码点（DSCP）直接映射到相应的OSPF SPF计算和路由表。这将拓扑的数量和定义限制为[TOS-OSPF]第12.3节规定的16个TOS值。对于多拓扑路由，什么类型的流量映射到哪个拓扑的分类不在本文档的范围内。
2. With TOS routing [TOS-OSPF], traffic that is unreachable in the routing table associated with the corresponding TOS will revert to the TOS 0 routing table. With Multi-Topology routing, this is optional.
2. 使用TOS路由[TOS-OSPF]，在与相应TOS关联的路由表中无法访问的流量将恢复到TOS 0路由表。对于多拓扑路由，这是可选的。
3. With TOS routing [TOS-OSPF], individual links or prefixes could not be excluded from a topology. If the Link State Advertisement (LSA) options T-bit was set, all links or prefixes were either advertised explicitly or defaulted to the TOS 0 metric. With Multi-Topology routing, links or prefixes that are not advertised for a specific topology do not exist in that topology.
3. 使用TOS路由[TOS-OSPF]，不能从拓扑中排除单个链路或前缀。如果设置了链接状态播发（LSA）选项T位，则所有链接或前缀要么显式播发，要么默认为TOS 0度量。使用多拓扑路由时，该拓扑中不存在未为特定拓扑播发的链接或前缀。
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 [RFC-KEYWORDS].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC-关键词]中的描述进行解释。
We use the following terminology in this document:
我们在本文件中使用以下术语：
Non-MT router Routers that do not have the MT capability.
不具备MT功能的非MT路由器。
MT router Routers that have MT capability as described in this document.
具有本文件所述MT功能的MT路由器。
MT-ID Renamed TOS field in LSAs to represent Multi-Topology ID.
MT-ID重命名LSAs中的TOS字段以表示多拓扑ID。
Default topology Topology that is built using the TOS 0 metric (default metric).
使用TOS 0度量（默认度量）构建的默认拓扑。
MT topology Topology that is built using the corresponding MT-ID metric.
使用相应的MT-ID度量构建的MT拓扑。
MT Shorthand notation for MT topology.
MT拓扑的MT简写符号。
MT#0 topology Representation of TOS 0 metric in MT-ID format.
MT-ID格式的TOS 0度量的MT#0拓扑表示。
Non-MT-Area An area that contains only non-MT routers.
非MT区域仅包含非MT路由器的区域。
MT-Area An area that contains both non-MT routers and MT routers, or only MT routers.
MT区域包含非MT路由器和MT路由器或仅包含MT路由器的区域。
Each OSPF interface belongs to a single area, and all MTs sharing that link need to belong to the same area. Therefore, the area boundaries for all MTs are the same, but each MT's attachment to the area is independent.
每个OSPF接口属于单个区域，共享该链路的所有MTs都需要属于同一区域。因此，所有MT的区域边界相同，但每个MT与该区域的连接是独立的。
Each interface can be configured to belong to a set of topologies. A single adjacency is formed with neighbors on the interface even if the interface is configured to participate in multiple topologies. Furthermore, adjacency formation is independent of the topologies configured on the local interface and the neighboring router.
每个接口都可以配置为属于一组拓扑。即使将接口配置为参与多个拓扑，也会与接口上的邻居形成单个邻接。此外，邻接形成独立于在本地接口和相邻路由器上配置的拓扑。
Sending OSPF control packets is unchanged from [OSPF]. For OSPF control packets sent to the remote end of a virtual link, the transit area path MUST be composed of links participating in the default topology and the OSPF control packets MUST be forwarded using the default topology.
从[OSPF]发送OSPF控制数据包不变。对于发送到虚拟链路远端的OSPF控制数据包，传输区路径必须由参与默认拓扑的链路组成，并且必须使用默认拓扑转发OSPF控制数据包。
The TOS metric field is reused to advertise topology specific metric for links and prefixes belonging to that topology. The TOS field is redefined as MT-ID in the payload of Router, Summary, and Type-5 and Type-7 AS-external-LSAs (see Appendix B).
TOS度量字段被重用，用于为属于该拓扑的链接和前缀公布特定于拓扑的度量。TOS字段在路由器的有效负载中被重新定义为MT-ID，Summary，Type-5和Type-7被重新定义为外部LSA（参见附录B）。
MT-ID metrics in LSAs SHOULD be in ascending order of MT-ID. If an MT-ID exists in an LSA or router link multiple times, the metric in the first MT-ID instance MUST be used.
LSA中的MT-ID度量应按MT-ID的升序排列。如果LSA或路由器链路中多次存在MT-ID，则必须使用第一个MT-ID实例中的度量。
When a router establishes a FULL adjacency over a link that belongs to a set of MTs, it advertises the corresponding cost for each MT-ID.
当路由器在属于一组MT的链路上建立完全邻接时，它播发每个MT-ID的相应成本。
By default, all links are included in the default topology and all advertised prefixes belonging to the default topology will use the TOS 0 metric as in [OSPF].
默认情况下，所有链接都包含在默认拓扑中，属于默认拓扑的所有播发前缀将使用[OSPF]中的TOS 0度量。
Each MT has its own MT-ID metric field. When a link is not part of a given MT, the corresponding MT-ID metric is excluded from the LSA.
每个MT都有自己的MT-ID度量字段。当链路不是给定MT的一部分时，相应的MT-ID度量从LSA中排除。
The Network-LSA does not contain any MT information since the Designated Router (DR) is shared by all MTs. Hence, there is no change to the Network-LSA.
网络LSA不包含任何MT信息，因为指定的路由器（DR）由所有MT共享。因此，网络LSA没有变化。
In Summary-LSAs and Type-5 and Type-7 AS-external-LSAs, the TOS metric fields are redefined as MT-ID metric fields and are used to advertise prefix and router reachability in the corresponding topology.
总之，LSA和Type-5和Type-7作为外部LSA，TOS度量字段被重新定义为MT-ID度量字段，并用于在相应拓扑中公布前缀和路由器可达性。
When a router originates a Summary-LSA, or Type-5 or Type-7 AS-external-LSA that belongs to a set of MTs, it includes the corresponding cost for each MT-ID. By default, the prefix participates in the default topology and uses the TOS 0 metric for the default topology, similar to standard OSPF [OSPF].
当路由器作为属于一组MTs的外部LSA生成摘要LSA或Type-5或Type-7时，它包括每个MT-ID的相应成本。默认情况下，前缀参与默认拓扑并使用TOS 0度量作为默认拓扑，类似于标准OSPF[OSPF]。
Setting the P-bit in Type-7 AS-external-LSA is topology independent and pertains to all MT-ID advertised in the body of the LSA.
将Type-7中的P位设置为外部LSA是拓扑独立的，并且适用于LSA主体中公布的所有MT-ID。
When a certain link or prefix that existed or was reachable in a certain topology is no longer part of that topology or is unreachable in that topology, a new version of the LSA MUST be originated excluding metric information representing the link or prefix in that topology.
当在某个拓扑中存在或可访问的某个链路或前缀不再是该拓扑的一部分或在该拓扑中无法访问时，必须创建新版本的LSA，但不包括表示该拓扑中的链路或前缀的度量信息。
The MT metric in the Router-LSA can also be set to the maximum possible metric to enable the router to become a stub in a certain topology [STUB].
路由器LSA中的MT度量也可以设置为最大可能度量，以使路由器成为特定拓扑中的存根[stub]。
By considering MT-ID metrics in the LSAs, OSPF computes multiple topologies and finds paths to IP prefixes for each MT independently. A separate SPF will be computed for each MT-ID to find independent paths to IP prefixes.
通过考虑LSA中的MT-ID度量，OSPF计算多个拓扑并独立地为每个MT找到IP前缀的路径。将为每个MT-ID计算单独的SPF，以找到IP前缀的独立路径。
Network-LSAs are used by all topologies during the SPF computation. During the SPF for a given MT-ID, only the links and metrics for that MT-ID are considered. Entries in the Router Routing table are also MT-ID specific.
在SPF计算期间，所有拓扑都使用网络LSA。在给定MT-ID的SPF期间，仅考虑该MT-ID的链接和度量。路由器路由表中的条目也是特定于MT-ID的。
Since AS-External-LSAs use the high-order bit in the MT-ID field (E-bit) for the external metric-type, only MT-IDs in the 0 to 127 range are valid. The following MT-ID values are reserved:
由于外部LSA使用MT-ID字段中的高位（E位）作为外部度量类型，因此只有0到127范围内的MT ID有效。保留以下MT-ID值：
0 - Reserved for advertising the metric associated with the default topology (see Section 4.2) 1 - Reserved for advertising the metric associated with the default multicast topology 2 - Reserved for IPv4 in-band management purposes 3-31 - Reserved for assignments by IANA 32-127 - Reserved for development, experimental and proprietary features [RFC3692] 128-255 - Invalid and SHOULD be ignored
0-保留用于公布与默认拓扑关联的度量（请参见第4.2节）1-保留用于公布与默认多播拓扑关联的度量2-保留用于IPv4带内管理目的3-31-保留用于IANA 32-127的分配-保留用于开发、实验和专有功能[RFC3692]128-255-无效，应忽略
It is outside of the scope of this document to specify how the information in various topology specific forwarding structures are used during packet forwarding or how incoming packets are associated with the corresponding topology. For correct operation, both forwarding behavior and methods of associating incoming packets to a corresponding topology must be consistently applied in the network.
指定在数据包转发期间如何使用各种拓扑特定转发结构中的信息，或如何将传入数据包与相应拓扑关联，不在本文档的范围之内。为了正确操作，必须在网络中一致地应用转发行为和将传入数据包关联到相应拓扑的方法。
The Multi-Topologies imply that all the routers participate in the default topology. However, it can be useful to exclude some links from the default topology and reserve them for some specific classes of traffic.
多拓扑意味着所有路由器都参与默认拓扑。但是，从默认拓扑中排除某些链接并为某些特定类别的流量保留它们可能会很有用。
The Multi-Topologies extension for the default topology link or prefix exclusion is described in the following subsections.
以下小节介绍了默认拓扑链接或前缀排除的多拓扑扩展。
OSPF does not have the notion of an unreachable link. All links can have a maximum metric of 0xFFFF advertised in the Router-LSA. The link exclusion capability requires routers to ignore TOS 0 metrics in Router-LSAs in the default topology and to alternately use the MT-ID#0 metric to advertise the metric associated with the default topology. Hence, all routers within an area MUST agree on how the metric for the default topology will be advertised.
OSPF没有不可到达链路的概念。所有链路都可以在路由器LSA中通告0xFFFF的最大度量。链路排除功能要求路由器忽略默认拓扑中路由器LSA中的TOS 0度量，并交替使用MT-ID#0度量来公布与默认拓扑关联的度量。因此，一个区域内的所有路由器必须就如何公布默认拓扑的度量达成一致。
The unused T-bit is defined as the MT-bit in the option field in order to ensure that a Multi-Topology link-excluding capable router will only form an adjacency with another similarly configured router.
未使用的T位被定义为选项字段中的MT位，以确保排除有能力的路由器的多拓扑链路将仅与另一个类似配置的路由器形成邻接。
+---+---+---+---+---+---+---+---+
|DN |O |DC |EA |NP |MC |E |MT |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
|DN |O |DC |EA |NP |MC |E |MT |
+---+---+---+---+---+---+---+---+
Figure 1: OSPF Option Bits
图1:OSPF选项位
MT-bit: If DefaultExclusionCapability is enabled, the bit MUST be set in Hello packets and SHOULD be set in Database Description packet (see Section 4.2).
MT位：如果启用了DefaultExclutionCapability，则该位必须在Hello数据包中设置，并应在数据库描述数据包中设置（参见第4.2节）。
We define a new parameter in the Area Data Structure:
我们在区域数据结构中定义了一个新参数：
DefaultExclusionCapability This configurable parameter ensures that all routers in an area have this capability enabled before the default topology can be disabled on a router link in the area without causing backward-compatibility problems.
DefaultExclutionCapability此可配置参数确保在禁用该区域路由器链路上的默认拓扑之前，该区域中的所有路由器都已启用此功能，而不会导致向后兼容性问题。
When an area data structure is created, the DefaultExclusionCapability is disabled by default.
创建区域数据结构时，默认情况下禁用DefaultExclutionCapability。
If DefaultExclusionCapability is disabled:
如果禁用了DefaultExclutionCapability：
o The MT-bit MUST be cleared in Hello packets and SHOULD be cleared in Database Description packets.
o MT位必须在Hello数据包中清除，并且应该在数据库描述数据包中清除。
o If a link participates in a non-default topology, it is automatically included in the default topology to support backward compatibility between MT and non-MT routers. This is accomplished using the TOS 0 metric field as in [OSPF].
o 如果链路参与非默认拓扑，它将自动包含在默认拓扑中，以支持MT和非MT路由器之间的向后兼容性。这是使用[OSPF]中的TOS 0度量字段实现的。
If DefaultExclusionCapability is enabled:
如果启用了DefaultExclutionCapability：
o The MT-bit MUST be set in Hello packets and SHOULD be set in Database Description packets.
o MT位必须在Hello数据包中设置，并且应该在数据库描述数据包中设置。
o The router will only accept a Hello packet if the MT-bit is set (see Section 4.3).
o 如果设置了MT位，路由器将只接受Hello数据包（参见第4.3节）。
When DefaultExclusionCapability is set to enabled, a router is said to be operating in DefaultExclusionCapability mode.
当DefaultExclutionCapability设置为enabled时，路由器被称为在DefaultExclutionCapability模式下运行。
In order to have a smooth transition from a non-MT area to an MT-area, an MT router with DefaultExclusionCapability disabled will form adjacencies with non-MT routers and will include all links as part of the default topology.
为了从非MT区域平滑过渡到MT区域，禁用DefaultExclutionCapability的MT路由器将与非MT路由器形成邻接，并将所有链路作为默认拓扑的一部分。
A link may cease participating in the default topology if DefaultExclusionCapability is set to enabled. In this state, a router will only form adjacency with routers that set the MT-bit in their Hello packets. This will ensure that all routers have DefaultExclusionCapability enabled before the default topology can be disabled on a link.
如果DefaultExclutionCapability设置为enabled，则链路可能会停止参与默认拓扑。在此状态下，路由器将仅与在其Hello数据包中设置MT位的路由器形成邻接。这将确保在链路上禁用默认拓扑之前，所有路由器都已启用DefaultExclutionCapability。
Receiving OSPF Hello packets as defined in Section 10.5 of [OSPF] is modified as follows:
[OSPF]第10.5节中定义的接收OSPF Hello数据包修改如下：
o If the DefaultExclusionCapability in the Area Data structure is set to enabled, Hello packets are discarded if the received packet does not have the MT-bit set in the Header Options.
o 如果区域数据结构中的DefaultExclutionCapability设置为enabled，则如果接收的数据包没有在报头选项中设置MT位，则丢弃Hello数据包。
Receiving OSPF Database Description packets as defined in Section 10.6 of [OSPF] is unchanged. While packet options are validated in Hello packets, the only option checking performed for Database Description packets is ensuring that the options do not change during the database exchange process.
[OSPF]第10.6节中定义的接收OSPF数据库描述数据包不变。虽然在Hello数据包中验证数据包选项，但对数据库描述数据包执行的唯一选项检查是确保这些选项在数据库交换过程中不会更改。
If DefaultExclusionCapability is enabled, the default topology can be disabled on an interface. Disabling the default topology on an interface does not impact the installation of connected routes for the interface in the default topology. It only affects what a router advertises in its Router-LSA.
如果启用了DefaultExclutionCapability，则可以在接口上禁用默认拓扑。在接口上禁用默认拓扑不会影响在默认拓扑中为接口安装连接的路由。它只影响路由器在其路由器LSA中的广告内容。
This allows OSPF control packets to be sent and received over an interface even if the default topology is disabled on the interface.
这允许通过接口发送和接收OSPF控制数据包，即使在接口上禁用了默认拓扑。
When DefaultExclusionCapability is enabled and the link does not participate in the default topology, the MT-ID#0 metric is not advertised. The link's TOS 0 metric is ignored during the default topology SPF computation.
当启用DefaultExclutionCapability且链路不参与默认拓扑时，不会公布MT-ID#0度量。在默认拓扑SPF计算期间，将忽略链接的TOS 0度量。
When DefaultExclusionCapability is enabled and a link participates in the default topology, MT-ID#0 metric is used to advertise the metric associated with the default topology. The link's TOS 0 metric is ignored during the default topology SPF computation.
启用DefaultExclutionCapability且链接参与默认拓扑时，MT-ID#0度量用于公布与默认拓扑关联的度量。在默认拓扑SPF计算期间，将忽略链接的TOS 0度量。
Independent of the DefaultExclusionCapability, the TOS 0 metric is used for Summary-LSAs and Type-5 and Type-7 AS-external-LSAs.
TOS 0指标独立于DefaultExclutionCapability，用于汇总LSA，并将类型5和类型7用作外部LSA。
o If the prefix or router does not exist in the default topology, the TOS 0 metric is set to infinity (0xFFFFFF).
o 如果默认拓扑中不存在前缀或路由器，则TOS 0度量将设置为无穷大（0xFFFFFF）。
o If the prefix or router exists in the default topology, the TOS 0 metric is used to advertise the metric in the default topology.
o 如果默认拓扑中存在前缀或路由器，则TOS 0度量将用于在默认拓扑中公布该度量。
During the summary and external prefix calculation for the default topology, the TOS 0 metric is used for Summary-LSAs and Type-5 and Type-7 AS-external-LSAs.
在默认拓扑的摘要和外部前缀计算过程中，TOS 0度量用于摘要LSA以及类型5和类型7作为外部LSA。
The default metric field is mandatory in all LSAs (even when the metric value is 0). Even when a link or prefix does not exist in the default topology, a non-MT router will consider the zero value in the metric field as a valid metric and consider the link or prefix as part of the default topology.
默认度量字段在所有LSA中都是必需的（即使度量值为0）。即使在默认拓扑中不存在链接或前缀，非MT路由器将考虑度量域中的零值作为有效度量，并将链接或前缀考虑为默认拓扑的一部分。
In order to prevent the above problem, an MT-capable router will include all links as part of the default topology. If links need to be removed from the default topology, an MT-capable router must be configured in DefaultExclusionCapability mode. In this mode, routers
为了防止上述问题，支持MT的路由器将包括所有链路作为默认拓扑的一部分。如果需要从默认拓扑中删除链路，则必须在DefaultExclutionCapability模式下配置支持MT的路由器。在这种模式下，路由器
will ensure that all other routers in the area are in the DefaultExclusionCapability mode before considering the MT-ID#0 metric in the SPF calculation. Only then can the TOS 0 metric field in Router-LSAs be safely ignored during the default topology SPF computation.
在SPF计算中考虑MT-ID#0度量之前，将确保该区域中的所有其他路由器都处于DefaultExclutionCapability模式。只有这样，才能在默认拓扑SPF计算期间安全地忽略路由器LSA中的TOS 0度量字段。
Note that for any prefix or router to become reachable in a certain topology, a contiguous path inside that topology must exist between the calculating router and the destination prefix or router.
请注意，要使任何前缀或路由器在特定拓扑中成为可访问的，该拓扑中的连续路径必须存在于计算路由器和目标前缀或路由器之间。
A change to an area's DefaultExclusionCapability requires additional processing for area neighbors that are suppressing Hello packets as specified in "Extending OSPF to Support Demand Circuits" [DEMAND]. When the DefaultExclusionCapability for an area is changed, Hello suppression must be disabled for these neighbors for a period of RouterDeadInterval seconds. This implies that Hello packets are sent with the DC-bit clear as specified in Section 3.2.1 of [DEMAND] during this period. After RouterDeadInterval seconds, either the adjacency will be taken down due to rejection of Hello packets with a conflicting MT-bit or Hello suppression will be renegotiated.
如“扩展OSPF以支持按需电路”[Demand]中所述，更改区域的DefaultExclutionCapability需要对正在抑制Hello数据包的区域邻居进行额外处理。当某个区域的DefaultExclutionCapability发生更改时，必须为这些邻居禁用Hello抑制，持续时间为RouterDeadInterval秒。这意味着在此期间，按照[DEMAND]第3.2.1节的规定，发送Hello数据包时DC位清除。RouterDeadInterval秒后，由于拒绝具有冲突MT位的Hello数据包，邻接将被删除，或者Hello抑制将被重新协商。
Introducing MT-OSPF into a network can be done gradually to allow MT routers and non-MT routers to participate in the default topology while MT routers participate in other topologies.
可以逐步将MT-OSPF引入网络，以允许MT路由器和非MT路由器参与默认拓扑，而MT路由器参与其他拓扑。
If there is a requirement to exclude some links from the default topology in an area, all routers in the area MUST be in DefaultExclusionCapability mode. In this section, we describe the migration steps to consider while transitioning from a non-MT network to an MT network.
如果需要从某个区域的默认拓扑中排除某些链路，则该区域中的所有路由器必须处于DefaultExclutionCapability模式。在这一节中，我们描述了迁移的步骤，同时考虑从非MT网络到MT网络。
Consider a network with a backbone area and a set of non-backbone areas functioning in standard OSPF mode. We would like to migrate to an MT network either partially or completely.
考虑具有标准区域OSPF模式的骨干区域和一组非骨干区域的网络。我们希望部分或全部迁移到MT网络。
1. As required, part of an area is upgraded to be MT capable. The MT routers will interact with non-MT routers in the default topology and participate in other topologies as required.
1. 根据需要，部分区域升级为MT功能。MT路由器将与默认拓扑中的非MT路由器交互，并根据需要参与其他拓扑。
2. If a new non-backbone area is created for MT routers, it may be configured in DefaultExclusionCapability mode since there is no interaction required with non-MT routers. In this mode, the default topology can be excluded on links as required.
2. 如果为MT路由器创建了一个新的非主干区域，则可以在DefaultExclutionCapability模式下对其进行配置，因为不需要与非MT路由器进行交互。在此模式下，可以根据需要排除链接上的默认拓扑。
3. If there are several non-backbone areas where MT is being used, it is desirable that the backbone area first be upgraded to be MT capable so that inter-area routing is ensured for MT destinations in different areas.
3. 如果存在多个使用MT的非主干区域，则希望首先将主干区域升级为具有MT能力，以便确保不同区域中的MT目的地的区域间路由。
4. Gradually, the whole network can be made MT capable.
4. 整个网络可以逐渐实现。
Note that inter-area routing for the MT-area still depends on the backbone area. Therefore, if different areas configured for a given topology need to communicate, the backbone area also needs to be configured for this topology.
请注意，MT区域的区域间路由仍然取决于主干区域。因此，如果为给定拓扑配置的不同区域需要通信，则还需要为此拓扑配置主干区域。
When multiple OSPF topologies exist within a domain, some of the routers can be configured to participate in a subset of the MTs in the network. This section discusses some of the options we have to enable operations or the network management stations to access those routers.
当一个域中存在多个OSPF拓扑时，一些路由器可以配置为参与网络中的MTs子集。本节讨论我们必须启用操作或网络管理站来访问这些路由器的一些选项。
This approach is to set up a dedicated management topology or 'in-band' management topology. This 'mgmt' topology will include all the routers need to be managed. The computed routes in the topology will be installed into the 'mgmt' Routing Information Base (RIB). In the condition of the 'mgmt' topology uses a set of non-overlapping address space with the default topology, those 'mgmt' routes can also be optionally installed into the default RIB. The advantages of duplicate 'mgmt' routes in both RIBs include: the network management utilities on the system do not have to be modified to use specific RIB other than the default RIB; the 'mgmt' topology can share the same link with the default topology if so designed.
此方法用于设置专用管理拓扑或“带内”管理拓扑。此“管理”拓扑将包括需要管理的所有路由器。拓扑中的计算路由将安装到“管理”路由信息库（RIB）中。在“mgmt”拓扑使用一组与默认拓扑不重叠的地址空间的情况下，也可以选择将这些“mgmt”路由安装到默认RIB中。两个RIB中重复“管理”路由的优点包括：系统上的网络管理实用程序不必修改为使用默认RIB以外的特定RIB；“mgmt”拓扑可以与默认拓扑共享相同的链接（如果这样设计的话）。
Even in the case in which default topology is not used on some of the nodes in the IP forwarding, we may want to extend the default topology to those nodes for the purpose of network management. Operators SHOULD set a high cost on the links that belong to the extended portion of the default topology. This way, the IP data traffic will not be forwarded through those nodes during network topology changes.
即使在IP转发中的某些节点未使用默认拓扑的情况下，出于网络管理的目的，我们可能希望将默认拓扑扩展到这些节点。操作员应为属于默认拓扑扩展部分的链路设置高成本。这样，在网络拓扑更改期间，IP数据流量将不会通过这些节点转发。
This document does not raise any security issues that are not already covered in [OSPF].
本文件不涉及[OSPF]中未涉及的任何安全问题。
The T-bit as defined in [TOS-OSPF] for a router's TOS capability is redefined as the MT-bit in this document. IANA has assigned the MT-bit as defined in Section 4.1.
[TOS-OSPF]中定义的路由器TOS功能的T位在本文件中被重新定义为MT位。IANA已按照第4.1节的规定分配MT位。
Similarly, the TOS field for Router-LSAs, Summary-LSAs, and Type-5 and Type-7 AS-external-LSAs, as defined in [OSPF], is redefined as MT-ID in Section 3.7.
类似地，[OSPF]中定义的路由器LSA、汇总LSA以及作为外部LSA的5型和7型的TOS字段在第3.7节中重新定义为MT-ID。
IANA created a new registry, "OSPF Multi-Topology ID Values", with the assignments and registration policies listed in Section 3.7 of this document.
IANA创建了一个新的注册表“OSPF多拓扑ID值”，其分配和注册策略见本文件第3.7节。
[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[需求]Moy，J.，“扩展OSPF以支持需求电路”，RFC 1793，1995年4月。
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA]Murphy，P.，“OSPF不那么短的区域（NSSA）选项”，RFC3101，2003年1月。
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，RFC 23281998年4月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，RFC 3692，2004年1月。
[TOS-OSPF] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[TOS-OSPF]Moy，J.，“OSPF版本2”，RFC 1583，1994年3月。
[M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", Work in Progress, October 2005.
[M-ISIS]Przygienda，T.，Shen，N.，和N.Sheth，“M-ISIS:IS-IS中的多拓扑（MT）路由”，正在进行的工作，2005年10月。
[STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.
[STUB]Retana，A.，Nguyen，L.，White，R.，Zinin，A.，和D.McPherson，“OSPF存根路由器广告”，RFC 3137，2001年6月。
The authors would like to thank Scott Sturgess, Alvaro Retana, David Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their comments on the document. Special thanks to Acee Lindem for editing and to Tom Henderson for an extensive review during the OSPF Working Group last call.
作者感谢Scott Sturgess、Alvaro Retana、David Kushi、Yakov Rekhter、Tony Przygienda和Naiming Shen对该文件的评论。特别感谢Acee Lindem的编辑和Tom Henderson在OSPF工作组最后一次电话会议期间的广泛审查。
LSA content defined in [OSPF] is modified to introduce the MT-ID.
修改[OSPF]中定义的LSA内容以引入MT-ID。
Router-LSAs are the Type 1 LSAs. Each router in an area originates a router-LSA. The LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA. For details concerning the construction of router-LSAs, see Section 12.4.1 of [OSPF].
路由器LSA是类型1 LSA。一个区域中的每个路由器都发起一个路由器LSA。LSA描述路由器到该区域的链路（即接口）的状态和成本。必须在单个路由器LSA中描述该区域的所有路由器链接。有关路由器LSA构造的详细信息，请参见[OSPF]第12.4.1节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*|*|*|N|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # MT-ID | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*|*|*|N|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # MT-ID | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Figure 2: Router-LSA Format
图2：路由器LSA格式
Network-LSAs are the Type 2 LSAs. A network-LSA is originated for each broadcast and Non-Broadcast Multi-Access (NBMA) network in the area that supports two or more routers. The network-LSA is originated by the network's Designated Router. The LSA describes all routers attached to the network, including the Designated Router itself. The LSA's Link State ID field lists the IP interface address of the Designated Router.
网络LSA是类型2 LSA。为支持两个或多个路由器的区域中的每个广播和非广播多址（NBMA）网络发起网络LSA。网络LSA由网络的指定路由器发起。LSA描述连接到网络的所有路由器，包括指定的路由器本身。LSA的链路状态ID字段列出指定路由器的IP接口地址。
The distance from the network to all attached routers is zero. This is why metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 12.4.2 of [OSPF].
从网络到所有连接的路由器的距离为零。这就是为什么不需要在网络LSA中指定度量字段。有关网络LSA建设的详细信息，请参见[OSPF]第12.4.2节。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Figure 3: Network-LSA Format
图3：网络LSA格式
Note that network-LSA does not contain any MT-ID fields as the cost of the network to the attached routers is 0 and DR is shared by all topologies.
注意，网络LSA不包含任何MT-ID字段，因为连接路由器的网络成本为0，DR由所有拓扑共享。
Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by area border routers. Summary-LSAs describe inter-area destinations. For details concerning the construction of summary-LSAs, see Section 12.4.3 of [OSPF].
摘要LSA为3型和4型LSA。这些LSA由区域边界路由器发起。摘要LSA描述了区域间目的地。有关汇总LSA构建的详细信息，请参见[OSPF]第12.4.3节。
Type 3 summary-LSAs are used when the destination is an IP network. In this case the LSA's Link State ID field is an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E of [OSPF] for details). When the destination is an AS boundary router, a Type 4 summary-LSA is used, and the Link State ID field is the AS boundary router's OSPF Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 of [OSPF].) Other than the difference in the Link State ID field, the format of Type 3 and 4 summary-LSAs is identical.
当目标是IP网络时，使用类型3摘要LSA。在这种情况下，LSA的链路状态ID字段是IP网络号（如有必要，链路状态ID还可以设置一个或多个网络“主机”位；有关详细信息，请参阅[OSPF]的附录E）。当目的地是AS边界路由器时，使用类型4摘要LSA，链路状态ID字段是AS边界路由器的OSPF路由器ID（要了解为什么需要公布每个ASBR的位置，请参阅[OSPF]第16.4节），而不是链路状态ID字段中的差异，类型3和类型4汇总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 | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 3 or 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Summary-LSA Format
图4：概要LSA格式
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.3 of [OSPF].
与外部LSA相同的是5型LSA。这些LSA由AS边界路由器发起，并描述AS外部的目的地。有关AS外部LSA施工的详细信息，请参见[OSPF]第12.4.3节。
AS-external-LSAs usually describe a particular external destination. For these LSAs, the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E of [OSPF] for details). AS-external-LSAs are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0.
因为外部LSA通常描述特定的外部目的地。对于这些LSA，链路状态ID字段指定IP网络号（如有必要，链路状态ID还可以设置一个或多个网络“主机”位；有关详细信息，请参阅[OSPF]的附录E）。AS外部LSA也用于描述默认路由。当不存在到目的地的特定路线时，使用默认路线。描述默认路由时，链路状态ID始终设置为DefaultDestination（0.0.0.0），网络掩码设置为0.0.0.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 | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| 0 | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AS-External-LSA Format
图5：作为外部LSA格式
Type-7 AS-external-LSAs are originated by AS boundary routers local to an NSSA (Not-So-Stubby Area), and describe destinations external to the AS. The changes to Type-7 AS-external-LSAs are identical to those for AS-external-LSAs (Appendix A.4.5 of [OSPF]). For details concerning the construction of Type-7 AS-external-LSAs, see Section 2.4 of [NSSA].
第7类AS外部LSA由NSSA本地的AS边界路由器发起（并非如此短截区），并描述AS外部的目的地。7型AS外部LSA的变更与AS外部LSA的变更相同（OSPF附录A.4.5）。有关7型外部LSA构造的详细信息，请参见[NSSA]第2.4节。
Authors' Addresses
作者地址
Peter Psenak Cisco Systems Mlynske Nivy 43 821 09 Bratislava Slovakia
Peter Psenak Cisco Systems Mlynske Nivy 43 821 09斯洛伐克布拉迪斯拉发
EMail: ppsenak@cisco.com
EMail: ppsenak@cisco.com
Sina Mirtorabi Force10 Networks 1440 McCarthy Blvd Milpitas, CA 95035 USA
新浪Mirtorabi Force10 Networks美国加利福尼亚州米尔皮塔斯麦卡锡大道1440号，邮编95035
EMail: sina@force10networks.com
EMail: sina@force10networks.com
Abhay Roy Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134
EMail: akr@cisco.com
EMail: akr@cisco.com
Liem Nguyen Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Liem Nguyen Cisco Systems 170美国加利福尼亚州圣何塞西塔斯曼大道95134号
EMail: lhnguyen@cisco.com
EMail: lhnguyen@cisco.com
Padma Pillay-Esnault Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道170号帕德玛·皮莱·埃斯纳尔特思科系统公司，邮编95134
EMail: ppe@cisco.com
EMail: ppe@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。