Network Working Group J. Parker, Ed.
Request for Comments: 3719 Axiowave Networks
Category: Informational February 2004
Network Working Group J. Parker, Ed.
Request for Comments: 3719 Axiowave Networks
Category: Informational February 2004
Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)
使用中间系统到中间系统（IS-IS）的互操作网络的建议
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 as described in ISO 10589 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. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic.
本文档讨论了ISO 10589中所述的中间系统到中间系统（IS-IS）协议与当前部署的协议之间的一些差异。这些差异将作为实现、测试和部署IS-IS协议的服务进行讨论。附带文档讨论了RFC1195中描述的协议与今天部署用于路由IP流量的协议之间的差异。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Constants That Are Variable . . . . . . . . . . . . . . . . . 2
3. Variables That Are Constant . . . . . . . . . . . . . . . . . 4
4. Alternative Metrics . . . . . . . . . . . . . . . . . . . . . 6
5. ReceiveLSPBufferSize. . . . . . . . . . . . . . . . . . . . . 6
6. Padding Hello PDUs. . . . . . . . . . . . . . . . . . . . . . 8
7. Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Purging Corrupted LSPs. . . . . . . . . . . . . . . . . . . . 10
9. Checking System ID in Received point-to-point IIH PDUs. . . . 10
10. Doppelganger LSPs . . . . . . . . . . . . . . . . . . . . . . 11
11. Generating a Complete Set of CSNPs. . . . . . . . . . . . . . 11
12. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
16. Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
17. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Constants That Are Variable . . . . . . . . . . . . . . . . . 2
3. Variables That Are Constant . . . . . . . . . . . . . . . . . 4
4. Alternative Metrics . . . . . . . . . . . . . . . . . . . . . 6
5. ReceiveLSPBufferSize. . . . . . . . . . . . . . . . . . . . . 6
6. Padding Hello PDUs. . . . . . . . . . . . . . . . . . . . . . 8
7. Zero Checksum . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Purging Corrupted LSPs. . . . . . . . . . . . . . . . . . . . 10
9. Checking System ID in Received point-to-point IIH PDUs. . . . 10
10. Doppelganger LSPs . . . . . . . . . . . . . . . . . . . . . . 11
11. Generating a Complete Set of CSNPs. . . . . . . . . . . . . . 11
12. Overload Bit. . . . . . . . . . . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
16. Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
17. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 15
In theory, there is no difference between theory and practice. But in practice, there is. Jan L.A. van de Snepscheut
在理论上，理论和实践没有区别。但在实践中，确实存在。简·L·A·范·德·斯奈普谢
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 addresses differences between the protocol described in ISO 10589 and the protocol that can be observed on the wire today. A companion document discusses differences between the protocol described in RFC 1195 [2] for routing IP traffic and current practice.
内部网关协议（如IS-IS）旨在提供有关路由域中最佳路由的及时信息。ISO 10589[1]中所述的IS-IS的原始设计已证明相当耐用。然而，许多原始设计选择已被修改。本文件阐述了ISO 10589中描述的协议与今天可以在电线上观察到的协议之间的差异。附带文档讨论了RFC 1195[2]中描述的路由IP流量协议与当前实践之间的差异。
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]中的说明进行解释。
Some parameters that were defined as constant in ISO 10589 are modified in practice. These include the following
ISO 10589中定义为常数的一些参数在实践中进行了修改。这些措施包括：
(1) MaxAge - the lifetime of a Link State PDU (LSP)
(1) MaxAge—链路状态PDU（LSP）的生存期
(2) ISISHoldingMultiplier - a parameter used to describe the generation of hello packets
(2) ISISHoldingMultiplier-用于描述hello数据包生成的参数
(3) ReceiveLSPBufferSize - discussed in a later section
(3) ReceiveLSPBufferSize-将在后面的部分中讨论
Each LSP contains a RemainingLifetime field which is initially set to the MaxAge value on the generating IS. The value stored in this field is decremented to mark the passage of time and the number of times it has been forwarded. When the value of a foreign LSP becomes 0, an IS initiates a purging process which will flush the LSP from the network. This ensures that corrupted or otherwise invalid LSPs do not remain in the network indefinitely. The rate at which LSPs are regenerated by the originating IS is determined by the value of maximumLSPGenerationInterval.
每个LSP都包含一个RemainingLifetime字段，该字段最初设置为生成is上的最大年龄值。此字段中存储的值将递减，以标记时间的流逝及其转发的次数。当外部LSP的值变为0时，IS启动清除过程，该过程将从网络中清除LSP。这可确保损坏或无效的LSP不会无限期地留在网络中。原始IS重新生成LSP的速率由MaximumLSPGGenerationInterval的值确定。
MaxAge is defined in ISO 10589 as an Architectural constant of 20 minutes, and it is recommended that maximumLSPGenerationInterval be set to 15 minutes. These times have proven to be too short in some networks, as they result in a steady flow of LSP updates even when nothing is changing. To reduce the rate of generation, some implementations allow these times to be set by the network operator.
ISO 10589将最大年龄定义为20分钟的建筑常数，建议将最大LSPGGenerationInterval设置为15分钟。事实证明，在某些网络中，这些时间太短，因为即使没有任何变化，它们也会导致LSP更新的稳定流。为了降低生成速率，一些实现允许网络运营商设置这些时间。
The relation between MaxAge and maximumLSPGenerationInterval is discussed in section 7.3.21 of ISO 10589. If MaxAge is smaller than maximumLSPGenerationInterval, then an LSP will expire before it is replaced. Further, as RemainingLifetime is decremented each time it is forwarded, an LSP far from its origin appears older and is removed sooner. To make sure that an LSP survives long enough to be replaced, MaxAge should exceed maximumLSPGenerationInterval by at least ZeroAgeLifetime + minimumLSPTransmissionInterval. The first term, ZeroAgeLifetime, is an estimate of how long it takes to flood an LSP through the network. The second term, minimumLSPTransmissionInterval, takes into account how long a router might delay before sending an LSP. The original recommendation was that MaxAge be at least 5 minutes larger than maximumLSPGenerationInterval, and that recommendation is still valid today.
ISO 10589第7.3.21节讨论了最大生成间隔和最大生成间隔之间的关系。如果MaxAge小于MaximumLSPGGenerationInterval，则LSP将在被替换之前过期。此外，由于每次转发时剩余寿命都会减少，因此远离其原点的LSP看起来更旧，并且删除得更快。为确保LSP能够存活足够长的时间以供更换，MaxAge应超过MaximumLSPGGenerationInterval至少零寿命+MinimumLSPTTransmissionInterval。第一项，ZeroAgeLifetime，是对LSP在网络中泛滥所需时间的估计。第二项，minimumLSPTransmissionInterval，考虑路由器在发送LSP之前可能延迟的时间。最初的建议是MaxAge至少比maximumLSPGenerationInterval大5分钟，该建议至今仍然有效。
An implementation MAY use a value of MaxAge that is greater than 1200 seconds. MaxAge SHOULD exceed maximumLSPGenerationInterval by at least 300 seconds. An implementation SHOULD NOT use its value of MaxAge to discard LSPs from peers, as discussed below.
实现可以使用大于1200秒的MaxAge值。MaxAge应超过MaximumLSPGGenerationInterval至少300秒。实现不应使用其MaxAge值从对等方丢弃LSP，如下所述。
An implementation is not required to coordinate the RemainingLifetime it assigns to LSPs to the RemainingLifetime values it accepts, and MUST ignore the following sentence from section 7.3.16.3. of ISO 10589.
实现不需要将分配给LSP的RemainingLifetime与其接受的RemainingLifetime值进行协调，并且必须忽略第7.3.16.3节中的以下句子。符合ISO 10589的要求。
"If the value of Remaining Lifetime [of the received LSP] is greater than MaxAge, the LSP shall be processed as if there were a checksum error."
“如果[接收到的LSP]的剩余寿命值大于MaxAge，则LSP的处理应如同存在校验和错误一样。”
An IS sends IS to IS Hello Protocol Data Units (IIHs) on a periodic basis over active circuits, allowing other attached routers to monitor their aliveness. The IIH includes a two byte field called the Holding Time which defines the time to live of an adjacency. If an IS does not receive a hello from an adjacent IS within this holding time, the adjacent IS is assumed to be no longer operational, and the adjacency is removed.
IS通过有源电路定期向IS Hello协议数据单元（IIH）发送IS，允许其他连接的路由器监控其有效性。IIH包含一个称为保持时间的两字节字段，该字段定义了邻接的生存时间。如果IS在该保持时间内未接收到来自相邻IS的问候，则假定相邻IS不再工作，并且删除相邻。
ISO 10589 defines ISISHoldingMultiplier to be 10, and states that the value of Holding Time should be ISISHoldingMultiplier multiplied by iSISHelloTimer for ordinary systems, and dRISISHelloTimer for a DIS. This implies that the neighbor must lose 10 IIHs before an adjacency times out.
ISO 10589将ISISHoldingMultiplier定义为10，并规定保持时间的值应为ISISHoldingMultiplier乘以普通系统的ISISHoldingMultiplier，再乘以DIS的Isishelotimer。这意味着邻居必须在邻接超时之前丢失10个IIH。
In practice, a value of 10 for the ISISHoldingMultiplier has proven to be too large. DECnet PhaseV defined two related values. The variable holdingMultiplier, with a default value of 3, was used for point-to-point IIHs, while the variable ISISHoldingMultiplier, with a default value of 10, was used for LAN IIHs. Most implementations today set the default ISISHoldingMultiplier to 3 for both circuit types.
事实证明，Isisholding乘数的值为10太大。DECnet PhaseV定义了两个相关值。默认值为3的变量Holding乘数用于点到点IIH，而默认值为10的变量Isisholding乘数用于LAN IIH。目前的大多数实现都将两种电路类型的默认Isisholding乘数设置为3。
Note that adjacent systems may use different values for Holding Time and will form an adjacency with non-symmetric hold times.
请注意，相邻系统可能使用不同的保持时间值，并将与非对称保持时间形成邻接。
An implementation MAY allow ISISHoldingMultiplier to be configurable. Values lower than 3 are unstable, and may cause adjacencies to flap.
一个实现可能允许ISISHoldingMultiplier是可配置的。小于3的值不稳定，可能会导致襟翼相邻。
Some values that were defined as variables in ISO 10589 do not vary in practice. These include
ISO 10589中定义为变量的一些值在实践中没有变化。其中包括
(1) ID Length - the length of the SystemID
(1) ID长度—SystemID的长度
(2) maximumAreaAddresses
(2) 最大面积地址
(3) Protocol Version
(3) 协议版本
The ID Length is a field carried in all PDUs. The ID Length defines the length of the System ID, and is allowed to take values from 0 to 8. A value of 0 is interpreted to define a length of 6 bytes. As suggested in B.1.1.3 of [1], it is easy to use an Ethernet MAC address to generate a unique 6 byte System ID. Since the SystemID only has significance within the IGP Domain, 6 bytes has proved to be easy to use and ample in practice. There are also new IS-IS Traffic Engineering TLVs which assume a 6 byte System ID. Choices for the ID length other than 6 are difficult to support today. Implementations may interoperate without being able to deal with System IDs of any length other than 6.
ID长度是所有PDU中携带的字段。ID长度定义系统ID的长度，允许取值范围为0到8。值0被解释为定义6字节的长度。如[1]的B.1.1.3所述，使用以太网MAC地址生成唯一的6字节系统ID是很容易的。由于SystemID仅在IGP域内具有重要意义，6字节已被证明是易于使用且在实践中足够的。还有新的IS-IS流量工程TLV，其假定系统ID为6字节。目前很难支持ID长度为6以外的选项。实现可以互操作，而不能处理除6以外的任何长度的系统ID。
An implementation MUST use an ID Length of 6, and MUST check the ID Length defined in the IS-IS PDUs it receives. If a router encounters a PDU with an ID Length different from 0 or 6, section 7.3.15.a.2
实现必须使用6的ID长度，并且必须检查它接收的IS-IS PDU中定义的ID长度。如果路由器遇到ID长度不同于0或6的PDU，请参见第7.3.15.a.2节
dictates that it MUST discard the PDU, and SHOULD generate an appropriate notification. ISO 10589 defines the notification iDFieldLengthMismatch, while the IS-IS MIB [7] defines the notification isisIDLenMismatch.
指示它必须丢弃PDU，并应生成适当的通知。ISO 10589定义了通知IDFieldLengthmatch，而IS-IS MIB[7]定义了通知ISISIDLengthmatch。
The value of maximumAreaAddresses is defined to be an integer between 1 and 254, and defines the number of synonymous Area Addresses that can be in use in an L1 area. This value is advertised in the header of each IS-IS PDU.
maximumAreaAddresses的值定义为1到254之间的整数，并定义了L1区域中可以使用的同义区域地址的数量。此值在每个is-is PDU的标头中公布。
Most deployed networks use one Area Address for an L1 area. When merging or splitting areas, a second address is required for seamless transition. The third area address was originally required to support DECnet PhaseIV addresses as well as OSI addresses during a transition.
大多数部署的网络使用一个区域地址作为L1区域。当合并或分割区域时，需要第二个地址进行无缝转换。第三个区域地址最初需要支持DECnet PhaseIV地址以及转换期间的OSI地址。
ISO 10589 requires that all Intermediate Systems in an area or domain use a consistent value for maximumAreaAddresses. Common practice is for an implementation to use the value 3. Therefore an implementation that only supports 3 can expect to interoperate successfully with other conformant systems.
ISO 10589要求一个区域或域中的所有中间系统使用一致的MaximumArea地址值。通常的做法是实现使用值3。因此，仅支持3的实现可以预期与其他符合性系统成功地互操作。
ISO 10589 specifies that an advertised value of 0 is treated as equivalent to 3, and that checking the value for consistency may be omitted if an implementation only supports the value 3.
ISO 10589规定，公布的值0被视为等同于3，如果实现仅支持值3，则可以省略检查值的一致性。
An implementation SHOULD use the value 3, and it SHOULD check the value advertised in IS-IS PDUs it receives. If a router receives a PDU with maximumAreaAddresses that is not 0 or 3, it MUST discard the PDU, as described in section 7.3.15.a.3, and it SHOULD generate an appropriate notification. ISO 10589 defines the notification maximumAreaAddressMismatch, while the IS-IS MIB [7] defines the notification isisMaxAreaAddressesMismatch.
实现应该使用值3，并且应该检查它接收的IS-IS PDU中公布的值。如果路由器接收到的PDU的maximumAreaAddresses不是0或3，则必须丢弃该PDU，如第7.3.15.a.3节所述，并应生成适当的通知。ISO 10589定义了通知MaximumAreaAddressMatch，而IS-IS MIB[7]定义了通知IsisMaxAreaAddressIsMatch。
IS-IS PDUs include two one-byte fields in the headers: "Version/Protocol ID Extension" and "Version".
IS-IS PDU在标题中包括两个单字节字段：“版本/协议ID扩展”和“版本”。
An implementation SHOULD set both fields to 1, and it SHOULD check the values of these fields in IS-IS PDUs it receives. If a router receives a PDU with a value other than 1 for either field, it MUST drop the packet, and SHOULD generate the isisVersionSkew notification.
实现应将这两个字段都设置为1，并应检查其接收的IS-IS PDU中这些字段的值。如果路由器接收到一个PDU的值不是1，则它必须丢弃该数据包，并应生成isisVersionSkew通知。
Section 7.2.2, ISO 10589 describes four metrics: Default Metric, Delay Metric, Expense Metric, and Error Metric. None but the Default Metric are used in deployed networks, and most implementations only consider the Default Metric. In ISO 10589, the most significant bit of the 8 bit metrics was the field S (Supported), used to define if the metric was meaningful.
ISO 10589第7.2.2节描述了四个度量：默认度量、延迟度量、费用度量和错误度量。除了默认度量之外，在部署的网络中使用的只有一个，并且大多数实现只考虑默认度量。在ISO 10589中，8位度量中的最高有效位是字段S（支持），用于定义度量是否有意义。
If this IS does not support this metric it shall set bit S to 1 to indicate that the metric is unsupported.
如果不支持该度量，则应将位S设置为1，以指示该度量不受支持。
The Supported bit was always 0 for the Default Metric, which must always be supported. However, RFC 2966 [5] uses this bit in the Default Metric to mark L1 routes that have been leaked from L1 to L2 and back down into L1 again.
默认度量值的支持位始终为0，必须始终支持该值。然而，RFC 2966[5]在默认度量中使用该位来标记从L1泄漏到L2并再次返回到L1的L1路由。
Implementations MUST generate the Default Metric when using narrow metrics, and SHOULD ignore the other three metrics when using narrow metrics. Implementations MUST assume that the Default Metric is supported, even if the S bit is set. RFC 2966 describes restrictions on leaking such routes learned from L1 into L2.
实现必须在使用窄度量时生成默认度量，并且在使用窄度量时应忽略其他三个度量。实现必须假设支持默认度量，即使设置了S位。RFC 2966描述了将从L1学到的路由泄漏到L2的限制。
Since IS-IS does not allow segmentation of protocol PDUs, Link State PDUs (LSPs) must be propagated without modification on all IS-IS enabled links throughout the area/domain. Thus it is essential to configure a maximum size that all routers can forward, receive, and store.
由于IS-IS不允许对协议PDU进行分段，因此链路状态PDU（LSP）必须在整个区域/域内的所有启用IS-IS的链路上传播，而无需修改。因此，必须配置所有路由器可以转发、接收和存储的最大大小。
This affects three aspects, which we discuss in turn:
这影响到三个方面，我们依次讨论：
(1) The largest LSP we can receive (ReceiveLSPBufferSize)
(1) 我们能收到的最大LSP（ReceiveLSPBufferSize）
(2) The size of the largest LSP we can generate (originatingL1LSPBufferSize and originatingL2LSPBufferSize)
(2) 我们可以生成的最大LSP的大小（Originating L1LSPBufferSize和Originating L2LSPBufferSize）
(3) Available Link MTU for supported Circuits (MTU). Note this often differs from the MTU available to IP clients.
(3) 支持电路（MTU）的可用链路MTU。注意：这通常不同于IP客户端可用的MTU。
ISO 10589 defines the architectural constant ReceiveLSPBufferSize with value 1492 bytes, and two private management parameters, originatingL1LSPBufferSize for level 1 PDUs and originatingL2LSPBufferSize for level 2 PDUs. The originating buffer
ISO 10589定义了体系结构常量ReceiveLSPBufferSize，其值为1492字节，以及两个专用管理参数，即级别1 PDU的originatingL1LSPBufferSize和级别2 PDU的originatingL2LSPBufferSize。原始缓冲区
size parameters define the maximum size of an LSP that a router can generate. ISO 10589 directs the implementor to treat a PDU larger than ReceiveLSPBufferSize as an error.
大小参数定义路由器可以生成的LSP的最大大小。ISO 10589指示实现者将大于ReceiveLSPBufferSize的PDU视为错误。
It is crucial that originatingL1LSPBufferSize <= ReceiveLSPBufferSize originatingL2LSPBufferSize <= ReceiveLSPBufferSize and that for all L1 links in the area originatingL1LSPBufferSize <= MTU and for all L2 links in the domain originatingL2LSPBufferSize <= MTU
发端L1LSPBufferSize<=ReceiveLSPBufferSize发端L2LSPBufferSize<=ReceiveLSPBufferSize以及对于发端L1LSPBufferSize<=MTU区域中的所有L1链路和域中的所有L2LSPBufferSize发端L2LSPBufferSize<=MTU至关重要
The original thought was that operators could decrease the originating Buffer size when dealing with smaller MTUs, but would not need to increase ReceiveLSPBufferSize beyond 1492.
最初的想法是，运营商在处理较小的MTU时可以减少原始缓冲区大小，但不需要将ReceiveLSPBufferSize增加到1492以上。
With the definition of new information to be advertised in LSPs, such as the Traffic Engineering TLVs, the limited space of the LSP database which may be generated by each router (256 * 1492 bytes at each level) has become an issue. Given that modern networks with MTUs larger than 1492 on all links are not uncommon, one method which can be used to expand the LSP database size is to allow values of ReceiveLSPBufferSize greater than 1492.
随着将在LSP（如流量工程TLV）中公布的新信息的定义，可能由每个路由器生成的LSP数据库的有限空间（每个级别256*1492字节）已成为一个问题。考虑到在所有链路上MTU大于1492的现代网络并不少见，可以用来扩展LSP数据库大小的一种方法是允许ReceiveLSPBufferSize的值大于1492。
Allowing ReceiveLSPBUfferSize to become a configurable parameter rather than an architectural constant must be done with care: if any system in the network does not support values larger than 1492 or one or more link MTUs used by IS-IS anywhere in the area/domain is smaller than the largest LSP which may be generated by any router, then full propagation of all LSPs may not be possible, resulting in routing loops and black holes.
允许ReceiveLSPBUfferSize成为一个可配置参数而不是一个体系结构常数必须小心：如果网络中的任何系统不支持大于1492的值，或者IS-IS在区域/域中任何位置使用的一个或多个链路MTU小于任何路由器可能生成的最大LSP，然后，所有LSP的完全传播可能不可能，从而导致路由循环和黑洞。
The steps below are recommended when changing ReceiveLSPBufferSize.
更改ReceiveLSPBufferSize时，建议执行以下步骤。
(1) Set the ReceiveLSPBufferSize to a consistent value throughout the network.
(1) 在整个网络中将ReceiveLSPBufferSize设置为一致的值。
(2) The implementation MUST not enable IS-IS on circuits which do not support an MTU at least as large as the originating BufferSize at the appropriate level.
(2) 在不支持至少与适当级别的原始缓冲区大小一样大的MTU的电路上，实现不得启用IS-IS。
(3) Include an originatingLSPBufferSize TLV when generating LSPs, introduced in section 9.8 of ISO 10589:2002 [1].
(3) 在生成LSP时包括原始LSPBufferSize TLV，如ISO 10589:2002[1]第9.8节所述。
(4) When receiving LSPs, check for an originatingLSPBufferSize TLV, and report the receipt of values larger than the local value of ReceiveLSPBufferSize through the defined Notifications and Alarms.
(4) 接收LSP时，检查是否存在原始LSPBufferSize TLV，并通过定义的通知和警报报告接收到的值大于ReceiveLSPBufferSize的本地值。
(5) Report the receipt of a PDU larger than the local ReceiveLSPBufferSize through the defined Notifications and Alarms.
(5) 通过定义的通知和警报报告接收到大于本地ReceiveLSPBufferSize的PDU。
(6) Do not discard large PDUs by default. Storing and processing them as normal PDUs may help maintain coherence in a misconfigured network.
(6) 默认情况下，不要丢弃大型PDU。将其作为普通PDU存储和处理可能有助于在配置错误的网络中保持一致性。
Steps 1 and 2 are enough by themselves, but the consequences of mismatch are serious enough and difficult enough to detect, that steps 3-6 are recommended to help track down and correct problems.
步骤1和2本身就足够了，但不匹配的后果非常严重，很难检测到，建议使用步骤3-6来帮助跟踪和纠正问题。
To prevent the establishment of adjacencies between systems which may not be able to successfully receive and propagate IS-IS PDUs due to inconsistent settings for originatingLSPBufferSize and ReceiveLSPBufferSize, section 8.2.3 of [1] requires padding on point-to-point links.
为了防止由于原始LSPBufferSize和ReceiveLSPBufferSize的设置不一致而无法成功接收和传播IS-IS PDU的系统之间建立邻接，[1]的第8.2.3节要求在点到点链路上进行填充。
On point-to-point links, the initial IIH is to be padded to the maximum of
在点对点链路上，初始IIH将被填充到最大值
(1) Link MTU
(1) 链接MTU
(2) originatingL1LSPBufferSize if the link is to be used for L1 traffic
(2) 如果链路将用于L1流量，则发起L1LSPBufferSize
(3) originatingL2LSPBufferSize if the link is to be used for L2 traffic
(3) 如果链路将用于L2通信，则初始化L2LSPBufferSize
In section 6.7.2 e) ISO 10589 assumes
在第6.7.2 e）节中，ISO 10589假设
Provision that failure to deliver a specific subnetwork SDU will result in the timely disconnection of the subnetwork connection in both directions and that this failure will be reported to both systems
规定未能交付特定子网SDU将导致在两个方向上及时断开子网连接，并且该故障将报告给两个系统
With this service provided by the link layer, the requirement that only the initial IIH be padded was sufficient to check the consistency of the MTU on the two sides. If the PDU was too big to be received, the link would be reset. However, link layer protocols in use on point-to-point circuits today often lack this service, and the initial padded PDU might be silently dropped without resetting the circuit. Therefore, the requirement that only the initial IIH be padded does not provide the guarantees anticipated in ISO 10589.
通过链路层提供的服务，仅填充初始IIH的要求足以检查两侧MTU的一致性。如果PDU太大而无法接收，则链路将重置。然而，目前在点到点电路上使用的链路层协议通常缺少这种服务，并且初始填充的PDU可能会在不重置电路的情况下被无声地丢弃。因此，仅填充初始IIH的要求不能提供ISO 10589中预期的保证。
If an implementation is using padding to detect problems, point-to-point IIH PDUs SHOULD be padded until the sender declares an adjacency on the link to be in state Up. If the implementation implements RFC 3373 [4], "Three-Way Handshake for IS-IS Point-to-Point Adjacencies" then this is when the three-way state is Up: if the implementation use the "classic" algorithm described in ISO 10589, this is when adjacencyState is Up. Transmission of padded IIH PDUs SHOULD be resumed whenever the adjacency is torn down, and SHOULD continue until the sender declares the adjacency to be in state Up again.
如果实现使用填充来检测问题，则应填充点对点IIH PDU，直到发送方声明链接上的邻接状态为Up。如果实现实现了RFC 3373[4]，“IS-IS点对点邻接的三向握手”，则这是三向状态启动时：如果实现使用ISO 10589中描述的“经典”算法，则这是邻接状态启动时。每当邻接被拆除时，应恢复填充IIH PDU的传输，并应继续传输，直到发送方宣布邻接再次处于启动状态。
If an implementation is using padding, and originatingL1LSPBUfferSize or originatingL2LSPBUfferSize is modified, adjacencies SHOULD be brought down and reestablished so the protection provided by padding IIH PDUs is performed consistent with the modified values.
如果一个实现正在使用填充，并且修改了OriginagingL1lspBufferSize或OriginagingL2lspBufferSize，则应减少并重新建立邻接，以便填充IIH PDU提供的保护与修改后的值一致。
Some implementations choose not to pad. Padding does not solve all problems of misconfigured systems. In particular, it does not provide a transitive relation. Assume that A, B, and C all pad IIH PDUs, that A and B can establish an adjacency, and that B and C can establish an adjacency. We still cannot conclude that A and C could establish an adjacency, if they were neighbors.
有些实现选择不填充。填充并不能解决配置错误的系统的所有问题。特别是，它不提供传递关系。假设A、B和C都是焊盘IIH PDU，A和B可以建立邻接，B和C可以建立邻接。如果A和C是邻居的话，我们仍然不能得出结论认为它们可以建立邻接关系。
The presence or absence of padding TLVs MUST NOT be one of the acceptance tests applied to a received IIH regardless of the state of the adjacency.
无论邻接状态如何，填充TLV的存在或不存在不得作为应用于接收IIH的验收测试之一。
A checksum of 0 is impossible if the checksum is computed according to the rules of ISO 8473 [8].
如果根据ISO 8473[8]的规则计算校验和，则校验和不可能为0。
ISO 10589, section 7.3.14.2(i), states:
ISO 10589第7.3.14.2（i）节规定：
A Link State PDU received with a zero checksum shall be treated as if the Remaining Lifetime were zero. The age, if not zero, shall be overwritten with zero.
使用零校验和接收的链路状态PDU应视为剩余寿命为零。如果年龄不为零，则应以零覆盖。
That is, ISO 10589 directs the receiver to purge the LSP. This has proved to be disruptive in practice. An implementation SHOULD treat all LSPs with a zero checksum and a non-zero remaining lifetime as if they had as checksum error. Such packets SHOULD be discarded.
也就是说，ISO 10589指示接收器清除LSP。事实证明，这在实践中具有破坏性。实现应该将校验和为零且剩余寿命非零的所有LSP视为校验和错误。这样的数据包应该被丢弃。
While ISO 10589 requires in section 7.3.14.2 e) that any LSP received with an invalid PDU checksum should be purged, this has been found to be disruptive. Most implementations today follow the revised specification, and simply drop the LSP.
虽然ISO 10589在第7.3.14.2 e）节中要求清除接收到的任何带有无效PDU校验和的LSP，但已发现这是破坏性的。今天的大多数实现都遵循修订后的规范，只需删除LSP即可。
In ISO 10589:2002 [1], Section 7.3.14.2, it states:
ISO 10589:2002[1]第7.3.14.2节规定：
(e) An Intermediate system receiving a Link State PDU with an incorrect LSP Checksum or with an invalid PDU syntax SHOULD
(e) 如果中间系统接收到链路状态PDU的LSP校验和不正确或PDU语法无效，则应
1) generate a corruptedLSPReceived circuit event,
1) 生成损坏的LSPrevived电路事件，
2) discard the PDU.
2) 丢弃PDU。
In section 8.2.4.2, ISO 10589 does not explicitly require comparison of the source ID of a received IIH with the neighbourSystemID associated with an existing adjacency on a point-to-point link.
在第8.2.4.2节中，ISO 10589未明确要求将接收到的IIH的源ID与与点到点链路上现有邻接相关的邻接系统EMID进行比较。
To address this omission, implementations receiving an IIH PDU on a point to point circuit with an established adjacency SHOULD check the Source ID field and compare that with the neighbourSystemID of the adjacency. If these differ, an implementation SHOULD delete the adjacency.
为了解决这一遗漏，在具有已建立邻接的点对点电路上接收IIH PDU的实现应检查源ID字段，并将其与邻接的邻居SystemID进行比较。如果它们不同，则实现应删除邻接。
Given that IIH PDUs as specified in ISO 10589 do not include a check-sum, it is possible that a corrupted IIH may falsely indicate a change in the neighbor's System ID. The required subnetwork guarantees for point-to-point links, as described in 6.7.2 g) 1) assume that undetected corrupted PDUs are very rare (one event per four years). A link with frequent errors that produce corrupted data could lead to flapping an adjacency. Inclusion of an optional checksum TLV as specified in "Optional Checksums in IS-IS" [6], may be used to detect such corruption. Hello packets carrying this TLV that are corrupted PDUs SHOULD be silently dropped, rather than dropping the adjacency.
鉴于ISO 10589中规定的IIH PDU不包括校验和，损坏的IIH可能会错误地指示邻居系统ID的变化。点到点链路所需的子网保证，如6.7.2 g）1）所述，假设未检测到的损坏PDU非常罕见（每四年发生一次事件）。频繁出错的链接会产生损坏的数据，这可能会导致相邻链接发生抖动。包括“IS-IS中的可选校验和”[6]中规定的可选校验和TLV可用于检测此类损坏。携带此TLV且PDU已损坏的Hello数据包应该被静默丢弃，而不是丢弃相邻数据包。
Some implementations have chosen to discard received IIHs where the source ID differs from the neighbourSystemID. This may prevent needless flapping caused by undetected PDU corruption. If an actual administrative change to the neighbor's system ID has occurred, using this strategy may require the existing adjacency to timeout before an adjacency with the new neighbor can be established. This is
一些实现选择丢弃接收到的IIH，其中源ID与邻居系统ID不同。这可以防止未检测到的PDU损坏导致不必要的拍打。如果邻居的系统ID发生了实际的管理更改，则使用此策略可能需要现有的邻接超时，然后才能建立与新邻居的邻接。这是
expedited if the neighbor resets the circuit as anticipated in 10589 after a System ID change, or resets the 3-way adjacency state, as anticipated in RFC 3373.
如果邻居在系统ID更改后按照10589中的预期重置电路，或按照RFC 3373中的预期重置3路邻接状态，则加速。
When an Intermediate System shuts down, it may leave old LSPs in the network. In the normal course of events, a rebooting system flushes out these old LSPs by reissuing those fragments with a higher sequence number, or by purging fragments that it is not currently generating.
当中间系统关闭时，它可能会在网络中留下旧的LSP。在正常的事件过程中，重新启动的系统通过重新发出具有更高序列号的片段或清除当前未生成的片段来清除这些旧LSP。
In the case where a received LSP or SNP entry and an LSP in the local database have the same LSP ID, same sequence number, non-zero remaining lifetimes, but different non-zero checksums, the rules defined in [1] cannot determine which of the two is "newer". In this case, an implementation may opt to perform an additional test as a tie breaker by comparing the checksums. Implementations that elect to use this method MUST consider the LSP/SNP entry with the higher checksum as newer. When comparing the checksums the checksum field is treated as a 16 bit unsigned integer in network byte order (i.e., most significant byte first).
在接收到的LSP或SNP条目和本地数据库中的LSP具有相同的LSP ID、相同的序列号、非零剩余寿命，但非零校验和不同的情况下，[1]中定义的规则无法确定两者中哪一个是“较新的”。在这种情况下，实现可以选择通过比较校验和来执行附加测试，作为连接断路器。选择使用此方法的实现必须考虑LSP／SNP条目，其中较高的校验和为较新的。比较校验和时，校验和字段被视为网络字节顺序的16位无符号整数（即，最高有效字节优先）。
The choice of higher checksum, rather than lower, while arbitrary, aligns with existing implementations and ensures compatibility.
选择较高的校验和，而不是较低的校验和，虽然是任意的，但与现有实现保持一致，并确保兼容性。
Note that a purged LSP (i.e., an LSP with remaining lifetime set to 0) is always considered newer than a non-purged copy of the same LSP.
请注意，已清除的LSP（即剩余生存期设置为0的LSP）始终被视为比同一LSP的未清除副本更新。
There are a number of cases in which a complete set of CSNPs must be generated. The DIS on a LAN, two IS's peering over a P2P link, and an IS helping another IS perform graceful restart must generate a complete set of CSNPs to assure consistent LSP Databases throughout. Section 7.3.15.3 of [1] defines a complete set of CSNPs to be:
在许多情况下，必须生成一套完整的CSNP。局域网上的DIS、两个IS在P2P链路上的对等以及一个IS帮助另一个IS执行优雅重启必须生成一套完整的CSNP，以确保整个LSP数据库的一致性。[1]第7.3.15.3节定义了一套完整的CSNPs：
"A complete set of CSNPs is a set whose Start LSPID and End LSPID ranges cover the complete possible range of LSPIDs. (i.e., there is no possible LSPID value which does not appear within the range of one of the CSNPs in the set). "
“一套完整的CSNPs是指其起始LSPID和结束LSPID范围涵盖完整可能的LSPID范围的集合。（即，没有可能的LSPID值不出现在集合中一个CSNPs的范围内）。”
Strict adherence to this definition is required to ensure the reliability of the update process. Deviation can lead to subtle and hard to detect defects. It is not sufficient to send a set of CSNPs which merely cover the range of LSPIDs which are in the local database. The set of CSNPs must cover the complete possible range of LSPIDs.
必须严格遵守此定义，以确保更新过程的可靠性。偏差可能导致细微且难以检测的缺陷。仅发送一组仅覆盖本地数据库中LSPID范围的CSNP是不够的。CSNP的集合必须涵盖LSPID的完整可能范围。
Consider the following example:
考虑下面的例子：
If the current Level 1 LSP database on a router consists of the following non pseudo-node LSPs:
如果路由器上的当前1级LSP数据库由以下非伪节点LSP组成：
From system 1111.1111.1111 LSPs numbered 0-89(59H) From system 2222.2222.2222 LSPs numbered 0-89(59H)
从编号为0-89（59H）的系统1111.1111.1111 LSP到编号为0-89（59H）的系统2222.2222 LSP
If the maximum size of a CSNP is 1492 bytes, then 90 CSNP entries can fit into a single CSNP PDU. The following set of CSNP start/end LSPIDs constitute a correctly formatted complete set:
如果CSNP的最大大小为1492字节，则90个CSNP条目可以装入单个CSNP PDU。以下一组CSNP开始/结束LSPID构成格式正确的完整集：
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A FFFF.FFFF.FFFF.FF-FF
开始LSPID结束LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.1111.00-5A FFFF.FFFF.FFFF-FF
The following are examples of incomplete sets of CSNPS:
以下是不完整的CSNP集合的示例：
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A 2222.2222.2222.00-59
开始LSPID结束LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 1111.1111.1111.00-5A 2222.2222.2222.00-59
The sequence above has a gap after the second entry.
上面的序列在第二个条目后有一个间隙。
Start LSPID End LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.2222.00-00 FFFF.FFFF.FFFF.FF-FF
开始LSPID结束LSPID 0000.0000.0000.00-00 1111.1111.1111.00-59 2222.2222.2222.00-00 FFFF.FFFF.FFFF-FF
The sequence above has a gap between the first and second entry.
上面的顺序在第一个条目和第二个条目之间有间隙。
Although it is legal to send a CSNP which contains no actual LSP entry TLVs, it should never be necessary to do so in order to conform to the specification.
虽然发送不包含实际LSP条目TLV的CSNP是合法的，但为了符合规范，不应该这样做。
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.
为了处理阻止IS存储其接收的所有LSP的瞬态问题，ISO 10589在第7.3.19节中定义了LSP数据库过载条件。当IS处于数据库过载状态时，它会在其生成的非伪节点LSP编号0中设置一个称为过载位的标志。ISO 10589第7.2.8.1节指示其他系统不要将过载的IS用作传输路由器。由于重载IS没有完整的信息，它可能无法计算正确的路由，路由循环可能会发展。
An overloaded router might become the DIS. An implementation SHOULD not set the Overload bit in PseudoNode LSPs that it generates, and Overload bits seen in PseudoNode LSPs SHOULD be ignored.
过载的路由器可能成为DIS。实现不应在其生成的伪节点LSP中设置重载位，并且应忽略在伪节点LSP中看到的重载位。
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].
由于ISO 10589[1]中描述的基础协议没有变化，因此本文件中的澄清不会引起任何新的安全问题。
[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] Katz, D. and Saluja, R., " Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, September 2002.
[4] Katz，D.和Saluja，R.，“中间系统到中间系统（IS-IS）点对点邻接的三向握手”，RFC 3373，2002年9月。
[5] Li, T., Przygienda, T. and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.
[5] Li，T.，Przygienda，T.和H.Smit，“具有两级IS-IS的域范围前缀分布”，RFC 2966，2000年10月。
[6] Koodli, R. and R. Ravikanth, "Optional Checksums in Intermediate System to Intermediate System (ISIS)", RFC 3358, August 2002.
[6] Koodli，R.和R.Ravikanth，“中间系统到中间系统（ISIS）中的可选校验和”，RFC 3358，2002年8月。
[7] Parker, J., "Management Information Base for IS-IS", Work in Progress, January 2004.
[7] Parker，J.，“IS-IS管理信息库”，进展中的工作，2004年1月。
[8] ITU, "Information technology - Protocol for providing the connectionless-mode network service", ISO/IEC 8473-1, 1998.
[8] ITU，“信息技术-提供无连接模式网络服务的协议”，ISO/IEC 8473-11998。
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. 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 Aravind Ravikumar, who pointed out that we should check Source ID on point-to-point IIH packets. 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，他们花了很多时间教育编辑。感谢拉迪娅·帕尔曼，她随时准备解释一切。多亏了萨蒂什·达塔特里，他坚韧不拔地把事情写对了。多亏了罗斯·怀特，他的写作改进了他所触及的每一个话题的处理方式。感谢Shankar Vemulapalli，他仔细阅读了几份草稿。感谢唐·古德斯皮德，感谢他对课文的仔细阅读。感谢Aravind Ravikumar，他指出我们应该检查点对点IIH数据包的源ID。感谢Michael Coyle确认了Jan L.A.van de Snepscheut的报价。感谢亚历克斯·齐宁在幕后的贡献。感谢Tony Li和Tony Przygienda，他们让我们在讨论进入尾声时保持了正轨。感谢所有做出贡献的人，但我不小心把他们的名字从名单上漏掉了。
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编辑功能的资金目前由互联网协会提供。