Network Working Group J. Parker, Ed.
Request for Comments: 3787 Axiowave Networks
Category: Informational May 2004
Network Working Group J. Parker, Ed.
Request for Comments: 3787 Axiowave Networks
Category: Informational May 2004
Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)
使用中间系统到中间系统（IS-IS）的互操作IP网络的建议
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice.
本文档讨论了RFC 1195中描述的用于路由IP流量的中间系统到中间系统（IS-IS）协议与当前部署的协议之间的一些差异。这些差异将作为一项服务来讨论，以帮助实现、测试和部署IS-IS协议来路由IP流量。附带文件描述了ISO 10589中描述的协议与当前实践之间的差异。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2
3. Unused Features . . . . . . . . . . . . . . . . . . . . . . . 2
4. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Migration from Narrow Metrics to Wide . . . . . . . . . . . . 4
6. Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 6
7. Attached Bit. . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Default Route . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Non-homogeneous Protocol Networks . . . . . . . . . . . . . . 8
10. Adjacency Creation and IP Interface Addressing. . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References. . . . . . . . . . . . . . . . . . 10
12.2. Informative References. . . . . . . . . . . . . . . . . 10
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 10
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 11
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 2
3. Unused Features . . . . . . . . . . . . . . . . . . . . . . . 2
4. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Migration from Narrow Metrics to Wide . . . . . . . . . . . . 4
6. Intermediate System Hello (ISH) PDU . . . . . . . . . . . . . 6
7. Attached Bit. . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Default Route . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Non-homogeneous Protocol Networks . . . . . . . . . . . . . . 8
10. Adjacency Creation and IP Interface Addressing. . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References. . . . . . . . . . . . . . . . . . 10
12.2. Informative References. . . . . . . . . . . . . . . . . 10
13. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 10
14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 11
Interior Gateway Protocols such as IS-IS are designed to provide timely information about the best routes in a routing domain. The original design of IS-IS, as described in ISO 10589 [1] has proved to be quite durable. However, a number of original design choices have been modified. This document describes some of the differences between the protocol as described in RFC 1195 [2] and the protocol that can be observed on the wire today. A companion document describes the differences between the protocol described in ISO 10589 and current practice [8].
内部网关协议（如IS-IS）旨在提供有关路由域中最佳路由的及时信息。ISO 10589[1]中所述的IS-IS的原始设计已证明相当耐用。然而，许多原始设计选择已被修改。本文件描述了RFC 1195[2]中描述的协议与目前可以在电线上观察到的协议之间的一些差异。附带文件描述了ISO 10589中描述的协议与当前实践[8]之间的差异。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as described in RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照RFC 2119[3]中的说明进行解释。
This document is the work of many people, and is the distillation of over a thousand mail messages. Thanks to Vishwas Manral, who pushed to create such a document. Thanks to Danny McPherson, the original editor, for kicking things off. Thanks to Mike Shand, for his work in creating the protocol, and his uncanny ability to remember what everything is for. Thanks to Micah Bartell and Philip Christian, who showed us how to document difference without displaying discord. Thanks to Les Ginsberg, Neal Castagnoli, Jeff Learman, and Dave Katz, who spent many hours educating the editor. Thanks to Radia Perlman, who is always ready to explain anything. Thanks to Satish Dattatri, who was tenacious in seeing things written up correctly, and to Bryan Boulton for his work on the IP adjacency issue. Thanks to Russ White, whose writing improved the treatment of every topic he touched. Thanks to Shankar Vemulapalli, who read several drafts with close attention. Thanks to Don Goodspeed, for his close reading of the text. Thanks to Michael Coyle for identifying the quotation from Jan L.A. van de Snepscheut. Thanks for Alex Zinin's ministrations behind the scenes. Thanks to Tony Li and Tony Przygienda, who kept us on track as the discussions veered into the weeds. And thanks to all those who have contributed, but whose names I have carelessly left from this list.
这份文件是许多人的作品，是一千多封邮件的精华。感谢Vishwas Manral，他推动创建了这样一个文档。感谢Danny McPherson，最初的编辑，让事情开始了。感谢迈克·尚德，感谢他在创建协议方面所做的工作，以及他记忆一切的神奇能力。感谢米卡·巴特尔和菲利普·克里斯蒂安，他们向我们展示了如何记录差异而不显示不一致。感谢Les Ginsberg、Neal Castagnoli、Jeff Learman和Dave Katz，他们花了很多时间教育编辑。感谢拉迪娅·帕尔曼，她随时准备解释一切。感谢萨蒂什·达塔特里（Satish Dattatri），他坚持不懈地看到事情写对了，也感谢布莱恩·博尔顿（Bryan Boulton）在IP邻接问题上所做的工作。多亏了罗斯·怀特，他的写作改进了他所触及的每一个话题的处理方式。感谢Shankar Vemulapalli，他仔细阅读了几份草稿。感谢唐·古德斯皮德，感谢他对课文的仔细阅读。感谢Michael Coyle确认了Jan L.A.van de Snepscheut的报价。感谢亚历克斯·齐宁在幕后的贡献。感谢Tony Li和Tony Przygienda，他们让我们在讨论进入尾声时保持了正轨。感谢所有做出贡献的人，但我不小心把他们的名字从名单上漏掉了。
Some features defined in RFC 1195 are not in current use.
RFC 1195中定义的某些功能当前未使用。
RFC 1195 defines an Inter-Domain Routing Protocol Information TLV, with code 131, designed to convey information transparently between boundary routers. TLV 131 is not used, and MUST be ignored if received.
RFC1195定义域间路由协议信息TLV，代码131，用于在边界路由器之间透明地传送信息。TLV 131未使用，如果收到，则必须忽略。
RFC 1195 defines an authentication TLV, code 133, which contains information used to authenticate the PDU. This TLV has been replaced by TLV 10, described in "IS-IS Cryptographic Authentication" [4]. TLV 133 is not used, and MUST be ignored.
RFC 1195定义了认证TLV，代码133，其中包含用于认证PDU的信息。该TLV已被TLV 10取代，如“IS-IS加密身份验证”[4]所述。TLV 133未使用，必须忽略。
To deal with transient problems that prevent an IS from storing all the LSPs it receives, ISO 10589 defines an LSP Database Overload condition in section 7.3.19. When an IS is in Database Overload condition, it sets a flag called the Overload Bit in the non-pseudonode LSP number Zero that it generates. Section 7.2.8.1 of ISO 10589 instructs other systems not to use the overloaded IS as a transit router. Since the overloaded IS does not have complete information, it may not be able to compute the right routes, and routing loops could develop. However, an overloaded router may be used to reach End Systems directly attached to the router, as it may provide the only path to an End System.
为了处理阻止IS存储其接收的所有LSP的瞬态问题，ISO 10589在第7.3.19节中定义了LSP数据库过载条件。当IS处于数据库过载状态时，它会在其生成的非伪节点LSP编号0中设置一个称为过载位的标志。ISO 10589第7.2.8.1节指示其他系统不要将过载的IS用作传输路由器。由于重载IS没有完整的信息，它可能无法计算正确的路由，路由循环可能会发展。然而，过载路由器可用于到达直接连接到路由器的终端系统，因为它可能提供到终端系统的唯一路径。
The ability to signal reduced knowledge is so useful that the meaning of this flag has been overloaded. In a Service Provider's network, when a router running BGP and IS-IS reboots, BGP might take more time to converge than IS-IS. Thus the router may drop traffic for destinations not yet learned via BGP. It is convenient to set the Overload Bit until BGP has converged, as described in "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance" [6].
表示减少的知识的能力非常有用，因此该标志的含义已经过多。在服务提供商的网络中，当运行BGP和IS-IS的路由器重新启动时，BGP可能需要比IS-IS更多的时间进行聚合。因此，路由器可能会丢弃尚未通过BGP学习的目的地的通信量。如“中间系统到中间系统（is-is）瞬态黑洞避免”[6]中所述，在BGP收敛之前设置过载位非常方便。
An implementation SHOULD use the Overload Bit to signal that it is not ready to accept transit traffic.
一个实现应该使用重载位来表示它还没有准备好接受中转流量。
An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored. This is also discussed in the companion document on ISO interoperability [8].
实现不应在其生成的伪节点LSP中设置重载位，并且应忽略在伪节点LSP中看到的重载位。关于ISO互操作性的配套文件[8]中也讨论了这一点。
RFC 1195 makes clear when describing the SPF algorithm for IP routers in section C.1.4 that directly connected IP subnetworks are reachable when an IS is overloaded.
RFC 1195在第C.1.4节中描述IP路由器的SPF算法时明确指出，当IS过载时，可以访问直接连接的IP子网。
Note that the End Systems neighbors of the system P includes IP reachable address entries included in the LSPs from system P.
注意，系统P的终端系统邻居包括来自系统P的lsp中包括的IP可访问地址条目。
When processing LSPs received from a router which has the Overload bit set in LSP number Zero, the receiving router SHOULD treat all IP reachability advertisements as directly connected and use them in its SPF computation.
当处理从LSP编号为0的路由器接收的LSP时，接收路由器应将所有IP可达性播发视为直接连接，并在其SPF计算中使用它们。
Since the IP prefixes that an overloaded router announces will be treated as directly attached, an overloaded router SHOULD take care in selecting which routes to advertise in the LSPs it generates.
由于过载路由器宣布的IP前缀将被视为直接连接，因此过载路由器应注意选择在其生成的LSP中播发哪些路由。
The IS-Neighbors TLV (TLV 2) as defined in ISO 10589 and the IP Reachability TLV (TLV 128/TLV 130) as defined in RFC 1195 provide a 6 bit metric for the default link metric to the listed neighbor. This metric has proved too limited. The Extended IS-Neighbors TLV (TLV 22) and the Extended IP Reachability TLV (TLV 135) are defined in "IS-IS extensions for Traffic Engineering" [5]. The Extended IS-Neighbors TLV (TLV 22) defines a 24 bit metric, and the Extended IP Reachability TLV (TLV 135) defines a 32 bit metric for IP Networks and Hosts.
ISO 10589中定义的IS邻居TLV（TLV 2）和RFC 1195中定义的IP可达性TLV（TLV 128/TLV 130）为所列邻居的默认链路度量提供6位度量。事实证明，这一指标过于有限。扩展IS邻居TLV（TLV 22）和扩展IP可达性TLV（TLV 135）在“IS-IS流量工程扩展”中定义[5]。扩展IS邻居TLV（TLV 22）定义了一个24位的度量，而扩展IP可达性TLV（TLV 135）定义了IP网络和主机的32位度量。
If not all devices in the IS-IS domain support wide metrics, narrow metrics MUST continue to be used. Once all devices in the network are able to support the new TLVs containing wide metrics, the network can be migrated to the new metric style, though care must be taken to avoid routing loops.
如果不是IS-IS域中的所有设备都支持宽度量，则必须继续使用窄度量。一旦网络中的所有设备都能够支持包含宽度量的新TLV，则可以将网络迁移到新的度量样式，但必须注意避免路由循环。
We make the following assumptions about the implementation:
我们对实施做出以下假设：
(1) Each system can generate and understand both narrow and wide metrics.
(1) 每个系统都可以生成并理解狭义和广义度量。
(2) The implementation can run the SPF algorithm on an LSP DB with instances of both metric styles.
(2) 该实现可以在具有两种度量样式的实例的LSPDB上运行SPF算法。
(3) If there are two metric styles for a link or IP prefix, it will pick one of them as the true cost for the link.
(3) 如果链接或IP前缀有两种度量样式，它将选择其中一种作为链接的真实成本。
To compare the different variants of the narrow metric with wide metrics, we need an algorithm that translates External and Internal narrow metrics into a common integer range. Since we have different computations for the L1 and L2 routes, we only need to map metrics from a single level.
为了比较窄度量和宽度量的不同变体，我们需要一种将外部和内部窄度量转换为公共整数范围的算法。因为我们对L1和L2路由有不同的计算，所以我们只需要从单个级别映射度量。
In RFC 1195 section 3.10.2, item 2c) states that the IP prefixes located in "IP External Reachability" with internal-metric and IP prefixes located in "IP Internal Reachability" with internal-metric have the same preference. As defined in "Domain-wide Prefix Distribution with Two-Level IS-IS", the Most Significant Bit on an L1 metric tells us if the route has been leaked down, but does not change the distance. Thus we will ignore the MSBit.
在RFC 1195第3.10.2节中，第2c）项规定，具有内部度量的“IP外部可达性”中的IP前缀和具有内部度量的“IP内部可达性”中的IP前缀具有相同的优先级。如“具有两级IS-IS的域范围前缀分布”中所定义，L1度量上的最高有效位告诉我们路由是否已泄漏，但不会改变距离。因此，我们将忽略MSBit。
We interpret the default metric as an 7 bit quantity. Metrics with the external bit set are interpreted as metrics in the range [64..127]. Metrics with the external bit clear are interpreted as metrics in the range [0..63].
我们将默认度量解释为7位量。具有外部位集的度量被解释为范围[64..127]内的度量。外部位清除的度量被解释为[0..63]范围内的度量。
To facilitate a smooth transition between the use of narrow metrics exclusively to the use of wide metrics exclusively, the following steps must be taken, in the order below.
为了促进狭义度量的使用与广义度量的使用之间的平稳过渡，必须按照以下顺序采取以下步骤。
(1) All routers advertise Narrow Metrics as defined in ISO 10589, and consider narrow metrics only in their SPF computation.
(1) 所有路由器都在ISO 10589中定义窄度量，并且仅在SPF计算中考虑窄度量。
(2) Each system is configured in turn to send wide metrics as well as narrow metrics. The two metrics for the same link or IP prefix SHOULD agree.
(2) 每个系统依次配置为发送宽度量和窄度量。同一链路或IP前缀的两个指标应该一致。
(3) When all systems are advertising wide metrics, make any changes necessary on each system to consider Wide Metrics during the SPF, and change MaxPathMetric to 0xFE000000.
(3) 当所有系统都是广告商度量时，对每个系统进行必要的更改，以便在SPF期间考虑广泛的度量，并将最大路径度量更改为0xFiFunm。
(4) Each system is configured in turn to stop advertising narrow metrics.
(4) 每个系统依次配置为停止广告。
(5) When the network is only using wide metrics, metrics on individual links may be rescaled to take advantage of the larger metric.
(5) 当网络仅使用宽度量时，可以重新调整单个链路上的度量以利用更大的度量。
The algorithm above assumes that the metrics are equal, and thus needs to make no assumption about which metric the SPF algorithm uses. This section describes the changes that should be made to the SPF algorithm when both Narrow and Wide metric styles should be considered. Using a common algorithm allows different implementations to compute the same distances independently, even if the wide and narrow metrics do not agree.
上述算法假设度量相等，因此不需要假设SPF算法使用哪种度量。本节描述了当同时考虑窄度量和宽度量样式时，应对SPF算法进行的更改。使用通用算法允许不同的实现独立地计算相同的距离，即使宽度量和窄度量不一致。
The standard SPF algorithm proceeds by comparing sums of link costs to obtain a minimal cost path. During transition, there will be more than one description of the same links. We resolve this by selecting the minimum metric for each link. This may give us a path with some links chosen due to a wide metric and some links chosen due to a narrow metric.
标准SPF算法通过比较链路成本之和来获得最小成本路径。在转换期间，相同链接将有多个描述。我们通过为每个链接选择最小度量来解决这个问题。这可能会为我们提供一条路径，其中一些链接是由于宽度量而选择的，而一些链接是由于窄度量而选择的。
The description below is more complex than the implementation needs to be: the implementation may simply select the minimal cost neighbor in TENT, discarding paths to destinations we have already reached, as described in ISO 10589.
下面的描述比实现需要的更复杂：实现可以简单地选择帐篷中成本最低的邻居，丢弃我们已经到达的目的地的路径，如ISO 10589所述。
The variables MaxPathMetric and MaxLinkMetric SHOULD retain the values defined in Table 2 of section 8 of ISO 10589.
变量MaxPathMetric和MaxLinkMetric应保留ISO 10589第8节表2中定义的值。
In C.2.5 Step 0 of the description of the SPF algorithm, section b)
在SPF算法说明的C.2.5步骤0中，第b节）
d(N) = cost of the parent circuit of the adjacency N
d（N）=邻接N的主电路的成本
If multiple styles of metric for the link are defined, the cost will be the minimum available cost for the circuit.
如果定义了链路的多种度量样式，则成本将是电路的最小可用成本。
In C.2.5 Step 0 of the description of the SPF algorithm, section i)
在SPF算法说明的C.2.5步骤0中，第一节）
d(N) = metric of the circuit
d（N）=电路的度量
If multiple styles of metric for the link are defined, the cost will be the minimum available cost for the circuit.
如果定义了链路的多种度量样式，则成本将是电路的最小可用成本。
In C.2.6 Step 1 of the description of the SPF algorithm, section a)
在SPF算法说明的C.2.6步骤1中，第a节）
dist(P,N) = d(P) + metric(P,N)
dist(P,N) = d(P) + metric(P,N)
If multiple styles of metric for the neighbor are defined, the cost will be the minimum available cost for the circuit.
如果为邻居定义了多种度量样式，则成本将是电路的最小可用成本。
The original intent of RFC 1195 was to provide a routing protocol capable of handling both CLNS and IPv4 reachability information. To allow CLNS Endstations (ES) to know that they are attached to a router, Intermediate Systems are required to send Intermediate System Hello PDUs (ISH) for End Stations when a point-to-point circuit comes up. Furthermore, an IS is not allowed to send Intermediate System to Intermediate System Hello PDUs (IIH) before receiving an ISH from a peer. This reduces routing protocol traffic on links with a single IS.
RFC1195的初衷是提供一种能够处理CLN和IPv4可达性信息的路由协议。为了让CLNS终端站（ES）知道它们连接到路由器，当出现点到点电路时，中间系统需要为终端站发送中间系统Hello PDU（ISH）。此外，在从对等方接收ISH之前，不允许将中间系统发送到中间系统Hello PDU（IIH）。这减少了具有单个IS的链路上的路由协议流量。
For this reason section 5.1 RFC 1195 states:
因此，RFC 1195第5.1节规定：
"On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links."
“在点到点链路上，ISO 9542 ISHs（中间系统Hellos）的交换用于初始化链路，并允许每个路由器在交换is-is Hellos之前知道链路另一端是否有路由器。所有实现is-is的路由器（无论是仅IP、仅OSI还是双IP），如果它们在点到点链路上有任何接口，则必须能够在点到点链路上传输ISO 9542 ISHs。”
Section 5.1 RFC 1195 reinforces the need to comply with section 8.2.4 of ISO 10589. However, in an IP Only environment, the original need for the ISH PDU is not present.
第5.1节RFC 1195强调了遵守ISO 10589第8.2.4节的必要性。但是，在纯IP环境中，不存在对ISH PDU的原始需求。
A multi-protocol IS that supports the attachment of CLNS ESs over Point to Point circuits must act in accordance with section 8.2.2 ISO 10589 when CLNS functionality is enabled.
支持通过点对点电路连接CLNS ESs的多协议必须在启用CLNS功能时按照第8.2.2节ISO 10589的规定执行。
An IP only implementation SHOULD issue an ISH PDU as described in section 8.2.3 of ISO 10589. This is to inter-operate with implementations which require an ISH to initiate the formation of an IS-IS adjacency.
仅IP实施应发布ISH PDU，如ISO 10589第8.2.3节所述。这是为了与需要ISH启动is-is邻接形成的实现进行交互操作。
An IP Only implementation may issue an IIH PDU when a point to point circuit transitions into an "Up" state to initiate the formation of an IS-IS adjacency, without sending an ISH PDU. However, this may not inter-operate with implementations which require an ISH for adjacency formation.
当点对点电路转变为“向上”状态以开始形成IS-IS邻接时，纯IP实现可以发出IIH PDU，而不发送ISH PDU。然而，这可能不会与需要ISH来形成邻接的实现相互作用。
An IS may issue an IIH PDU in response to the receipt of an IIH PDU in accordance with section 8.2.5.2 ISO 10589, even though it has not received an ISH PDU.
IS可根据第8.2.5.2 ISO 10589节的规定，在收到IIH PDU后发布IIH PDU，即使其尚未收到ISH PDU。
In section 7.2.9.2 of ISO 10589, an algorithm is described to determining when the attachedFlag should be set on an intermediate system. Some implementations also allow the attachedFlag to be set on Intermediate Systems routing IP traffic when there is a default route in the local routing table, or when some other state is reached that implies a connection to the rest of the network.
在ISO 10589第7.2.9.2节中，描述了一种算法，用于确定何时应在中间系统上设置attachedFlag。某些实现还允许在本地路由表中存在默认路由时，或当达到意味着连接到网络其余部分的某些其他状态时，在路由IP流量的中间系统上设置attachedFlag。
RFC 1195 states in section 1.3:
RFC 1195在第1.3节中规定：
Default routes are permitted only at level 2 as external routes (i.e., included in the "IP External Reachability Information" field, as explained in sections 3 and 5). Default routes are not permitted at level 1.
默认路由仅允许在第2级作为外部路由（即，包含在“IP外部可达性信息”字段中，如第3节和第5节所述）。1级不允许使用默认路线。
Because of the utility of the default route when dealing with other routing protocols and the ability to influence the exit point from an area, an implementation MAY generate default routes in Level 1.
由于默认路由在处理其他路由协议时的效用以及影响区域出口点的能力，实现可能会在级别1中生成默认路由。
RFC 1195 assumes that every deployment of IS-IS routers will support a homogeneous set of protocols. It anticipates OSI only, IP only, or dual OSI and IP routers. While it allows mixed areas with, for example, both pure IP and Dual IP and OSI routers, it allows only IP traffic in such domains, and OSI traffic only when pure OSI and Dual IP and OSI routers are present. Thus it provides only lowest common denominator routing.
RFC1195假设IS-IS路由器的每次部署都将支持一组同构的协议。它预期只有OSI、IP或双OSI和IP路由器。虽然它允许混合区域，例如纯IP和双IP及OSI路由器，但它仅允许此类域中的IP通信，并且仅当存在纯OSI和双IP及OSI路由器时才允许OSI通信。因此，它只提供最低公分母路由。
RFC 1195 also requires the inclusion of the Protocol Supported TLV with code 129 in IIH and ISH PDUs and in LSP number Zero. IP capable routers MUST generate a Protocol Supported TLV, and MUST include the IP protocol as a supported protocol. A router that does not include the Protocols Supported TLV may be assumed to be a pure OSI router and can be interpreted as implicitly "advertising" support for the OSI protocol.
RFC 1195还要求在IIH和ISH PDU以及LSP编号为零的LSP中包含代码为129的协议支持的TLV。具有IP能力的路由器必须生成协议支持的TLV，并且必须将IP协议作为支持的协议包含在内。不包括TLV支持的协议的路由器可以被假定为纯OSI路由器，并且可以被解释为对OSI协议的隐式“广告”支持。
The requirements of RFC 1195 are ample if networks adhere to this restriction. However, the behavior of mixed networks that do not follow these guidelines is not well defined.
如果网络遵守此限制，RFC 1195的要求就足够了。然而，不遵循这些准则的混合网络的行为并没有得到很好的定义。
The ITU-T requires that SONET/SDH equipment running the IS-IS protocol must not form an adjacency with a neighbour unless they share at least one network layer protocol in common. Unless this feature is present in every IS in the SONET or SDH DCN network the network may not function correctly. Implementors MAY include this feature if they wish to ensure interoperability with SONET and SDH DCN networks.
ITU-T要求运行IS-IS协议的SONET/SDH设备不得与邻居相邻，除非它们至少共享一个网络层协议。除非SONET或SDH DCN网络中的每个is中都存在此功能，否则网络可能无法正常工作。如果实施者希望确保与SONET和SDH DCN网络的互操作性，则可以包括此功能。
Definition of an interoperable strategy for resolving the problems that arise in non-homogeneous protocol networks remains incomplete. Members of the ITU are actively working on a proposal: see "Architecture and Specification of Data Communication Network", [7].
为解决非同构协议网络中出现的问题而定义的可互操作策略仍不完整。国际电联成员正在积极研究一项提案：见“数据通信网络的体系结构和规范”[7]。
RFC 1195 states that adjacencies are formed without regard to IP interface addressing. However, many current implementations refuse adjacencies based on interface addresses and related issues.
RFC1195指出，邻接的形成与IP接口寻址无关。然而，许多当前的实现拒绝基于接口地址和相关问题的邻接。
In section 4.2, RFC 1195 requires routers with IP interface addresses to advertise the addresses in an IP Interface Address TLV (132) carried in IIH PDUs. Some implementations will not interoperate with a neighbor router that does not include the IP Interface Address TLV. Further, some implementations will not form an adjacency on broadcast interfaces with a peer who does not share an interface address in some common IP subnetwork.
在第4.2节中，RFC 1195要求具有IP接口地址的路由器在IIH PDU中携带的IP接口地址TLV（132）中公布地址。某些实现不会与不包含IP接口地址TLV的邻居路由器进行互操作。此外，一些实现不会在广播接口上与在某些公共IP子网中不共享接口地址的对等方形成邻接。
If a LAN contains a mixture of implementations, some that form adjacencies with all neighbors and some that do not, care must be taken when assigning IP addresses. If not all routers in a LAN are on the same IP subnet, it is possible that DIS election may fail, leading to the election of multiple DISs on a LAN, or no DIS at all. Even if DIS election succeeds, black holes can result because the IS-IS LAN transitivity requirements of section 6.7.3 ISO 10589 are not met.
如果LAN包含多种实现，有些与所有邻居形成邻接，有些则不邻接，则在分配IP地址时必须小心。如果局域网中的路由器并非都在同一IP子网中，则可能会导致DIS选择失败，从而导致在局域网上选择多个DIS，或者根本没有DIS。即使取消选举成功，也可能导致黑洞，因为不符合ISO 10589第6.7.3节的IS-IS LAN传递性要求。
Unnumbered point to point links do not have IP interface addresses, though they may have other IP addresses assigned to the routers. The IP address assigned to two routers that are neighbors on an unnumbered point to point link do not need to be related. However, some implementations will not form an adjacency on numbered point to point links if the interface addresses of each endpoint are not in the same IP subnetwork. This means that care must be taken in assigning IP interface addresses in all networks.
未编号的点对点链路没有IP接口地址，尽管它们可能有分配给路由器的其他IP地址。分配给两个路由器的IP地址是无编号点对点链路上的邻居，不需要关联。但是，如果每个端点的接口地址不在同一IP子网中，则某些实现不会在编号的点到点链路上形成邻接。这意味着在所有网络中分配IP接口地址时必须小心。
For an implementation to interoperate in a such mixed environment, it MUST include an IP Interface address (TLV 132) in its IIH PDUs. The network administrator should ensure that there is a common IP subnet assigned to links with numbered interfaces, and that all routers on each link have a IP Interface Addresses belonging to the assigned subnet.
为了在这种混合环境中实现互操作，它必须在其IIH PDU中包含IP接口地址（TLV 132）。网络管理员应确保有一个公共IP子网分配给带有编号接口的链路，并且每个链路上的所有路由器都有一个属于分配子网的IP接口地址。
The clarifications in this document do not raise any new security concerns, as there is no change in the underlying protocol described in ISO 10589 [1] and RFC 1195 [2].
由于ISO 10589[1]和RFC 1195[2]中描述的基础协议没有变化，因此本文件中的澄清不会引起任何新的安全问题。
The document does make clear that TLV 133 has been deprecated and replaced with TLV 10.
该文件明确指出，TLV 133已被弃用，并被TLV 10取代。
[1] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002.
[1] ISO，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统路由信息交换协议（ISO 8473）”，ISO/IEC 10589:2002。
[2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195, December 1990.
[2] Callon，R.，“IP和双环境的OSI IS-IS”，RFC1195，1990年12月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 3567, July 2003.
[4] Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 3567，2003年7月。
[5] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, May 2004.
[5] Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 3784，2004年5月。
[6] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002.
[6] McPherson，D.，“中间系统对中间系统（IS-IS）瞬态黑洞回避”，RFC3277，2002年4月。
[7] ITU, "Architecture and Specification of Data Communication Network", ITU-T Recommendation G.7712/Y.1703, November 2001
[7] ITU，“数据通信网络的体系结构和规范”，ITU-T建议G.7712/Y.1703，2001年11月
[8] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, February 2004.
[8] Parker，J.，Ed.，“使用中间系统到中间系统（IS-IS）的互操作网络的建议”，RFC 3719，2004年2月。
Jeff Parker Axiowave Networks 200 Nickerson Road Marlborough, Mass 01752 USA
Jeff Parker Axiowave Networks美国马萨诸塞州马尔伯勒尼克森路200号01752
EMail: jparker@axiowave.com
EMail: jparker@axiowave.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。