Network Working Group D. Katz
Request for Comments: 5303 Juniper Networks
Obsoletes: 3373 R. Saluja
Category: Standards Track Tenet Technologies
D. Eastlake 3rd
Eastlake Enterprises
October 2008
Network Working Group D. Katz
Request for Comments: 5303 Juniper Networks
Obsoletes: 3373 R. Saluja
Category: Standards Track Tenet Technologies
D. Eastlake 3rd
Eastlake Enterprises
October 2008
Three-Way Handshake for IS-IS Point-to-Point Adjacencies
IS-IS点对点邻接的三向握手
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）。本备忘录的分发不受限制。
Abstract
摘要
The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
IS-IS路由协议（中间系统到中间系统，ISO 10589）要求在链路层为点到点链路提供可靠的协议。因此，在点到点媒体上建立邻接时，它不使用三向握手。本文定义了该协议的向后兼容扩展，该扩展提供了三向握手。它可以与不支持扩展的系统完全互操作。
Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router.
此外，该扩展允许在单个路由器上稳健地运行256个以上的点到点链路。
This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors.
此扩展已由多家路由器供应商实施；本文提供给Internet社区是为了允许其他供应商构建可互操作的实现。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of Extensions ..........................................3
2.1. Handshaking ................................................3
2.2. More than 256 Interfaces ...................................4
3. Details .........................................................5
3.1. Syntax .....................................................5
3.2. Elements of Procedure ......................................6
4. IANA Considerations .............................................8
5. Security Considerations .........................................9
6. Changes from RFC 3373 ...........................................9
7. Acknowledgements ................................................9
8. Normative References ............................................9
9. Informative References ..........................................9
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Overview of Extensions ..........................................3
2.1. Handshaking ................................................3
2.2. More than 256 Interfaces ...................................4
3. Details .........................................................5
3.1. Syntax .....................................................5
3.2. Elements of Procedure ......................................6
4. IANA Considerations .............................................8
5. Security Considerations .........................................9
6. Changes from RFC 3373 ...........................................9
7. Acknowledgements ................................................9
8. Normative References ............................................9
9. Informative References ..........................................9
The IS-IS protocol [ISIS] assumes certain requirements stated in ISO 10589 (section 6.7.2) for the operation of IS-IS over point-to-point links and hence provides only a two-way handshake when establishing adjacencies on point-to-point links. The protocol does not operate correctly if these subnetwork requirements for point-to-point links are not met. The basic mechanism defined in the standard is that each side declares the other side to be reachable if a Hello packet is heard from it. Once this occurs, each side then sends a Complete Sequence Number PDU (CSNP) to trigger database synchronization.
IS-IS协议[ISIS]假设ISO 10589（第6.7.2节）中规定了IS-IS在点到点链路上运行的某些要求，因此在点到点链路上建立邻接时仅提供双向握手。如果不满足这些点到点链路的子网要求，则协议无法正常运行。标准中定义的基本机制是，如果听到Hello数据包，每一方都声明另一方是可访问的。一旦发生这种情况，每一方都会发送一个完整的序列号PDU（CSNP）来触发数据库同步。
Three failure modes are known. First, if the link goes down and then comes back up, or one of the systems restarts, and the CSNP packet is lost, and the network has a cut set of one through the link, the link state databases on either side of the link will not synchronize for a full Link State Protocol Data Unit (LSP) refresh period (up to 18 hours).
已知三种故障模式。首先，如果链路断开然后又恢复，或者其中一个系统重新启动，并且CSNP数据包丢失，并且网络有一个通过链路的割集，则链路两侧的链路状态数据库在完整链路状态协议数据单元（LSP）刷新期内（最多18小时）将不会同步。
A second, more serious failure is that if the link fails in only one direction, the failure will only be detected by one of the systems. Normally only one of the two systems will announce the adjacency in its link state packets, and the SPF algorithm will thus ignore the link. However, if there are two parallel links between systems and one of them fails in one direction, SPF will still calculate paths between the two systems, and the system that does not notice the failure will attempt to pass traffic down the failed link (in the direction that does not work).
第二个更严重的故障是，如果链路仅在一个方向发生故障，则故障将仅由其中一个系统检测到。通常，两个系统中只有一个会在其链路状态数据包中宣布相邻关系，因此SPF算法将忽略该链路。但是，如果系统之间存在两个并行链路，且其中一个链路在一个方向上发生故障，SPF仍将计算两个系统之间的路径，并且未注意到故障的系统将尝试将流量沿故障链路（在不工作的方向）传递。
The third issue is that on some physical layers, the interconnectivity between endpoints can change without causing a
第三个问题是，在某些物理层上，端点之间的互连可能会发生变化，而不会导致错误
link-layer-down condition. In this case, a system may receive packets that are actually destined for a different system (or a different link on the same system). The receiving system may end up thinking that it has an adjacency with the remote system when in fact the remote system is adjacent with a third system.
链路层关闭条件。在这种情况下，系统可能会接收到实际目的地为不同系统（或同一系统上的不同链路）的数据包。接收系统可能最终认为它与远程系统相邻，而实际上远程系统与第三个系统相邻。
The solution proposed here ensures correct operation of the protocol over unreliable point-to-point links. As part of the solution to the three-way handshaking issue, a method is defined to remove the limitation of 255 point-to-point interfaces imposed by IS-IS [ISIS]. This method is more robust than the ad hoc methods currently in use.
本文提出的解决方案确保了协议在不可靠的点到点链路上的正确运行。作为三方握手问题解决方案的一部分，定义了一种方法，以消除is-is[ISIS]对255个点到点接口的限制。这种方法比目前使用的特别方法更健壮。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section provides a general overview of the three-way handshaking provided and how more than 256 interfaces are handled.
本节概述了所提供的三向握手以及如何处理256个以上的接口。
The intent is to provide a three-way handshake for point-to-point adjacency establishment in a backward-compatible fashion. This is done by providing an optional mechanism that allows each system to report its adjacency three-way state, thus allowing a system to only declare an adjacency to be up if it knows that the other system is receiving its IS-IS Hello (IIH) packets.
其目的是以向后兼容的方式为点对点邻接建立提供三向握手。这是通过提供一种可选机制来实现的，该机制允许每个系统报告其邻接三向状态，从而允许系统仅在知道另一个系统正在接收其is-is Hello（IIH）数据包时声明邻接已启动。
The adjacency three-way state can be one of the following types:
邻接三向状态可以是以下类型之一：
Down This is the initial point-to-point adjacency three-way state. The system has not received any IIH packet containing the three-way handshake option on this point-to-point circuit.
向下这是初始的点对点邻接三向状态。系统未在此点到点电路上收到任何包含三向握手选项的IIH数据包。
Initializing The system has received an IIH packet containing the three-way handshake option from a neighbor but does not know whether the neighbor is receiving its IIH packet.
初始化系统已从邻居接收到包含三向握手选项的IIH数据包，但不知道邻居是否正在接收其IIH数据包。
Up The system knows that the neighbor is receiving its IIH packets.
系统知道邻居正在接收其IIH数据包。
The adjacency three-way state that is reported by this mechanism is not equal or equivalent to the adjacency state that is described in ISO 10589 [ISIS]. If this mechanism is supported, then an adjacency may have two states, its state as defined in ISO 10589 [ISIS], and its three-way state. For example, according to ISO 10589, receipt of an Intermediate System Hello (ISH) will cause an adjacency to go to Initializing state; however, receipt of an ISH will have no effect on the three-way state of an adjacency, which remains firmly Down until it receives an IIH from a neighbor that contains the three-way handshaking option.
该机制报告的邻接三向状态不等于或等效于ISO 10589[ISIS]中描述的邻接状态。如果支持此机制，则邻接可能有两种状态，即ISO 10589[ISIS]中定义的状态和三向状态。例如，根据ISO 10589，接收中间系统Hello（ISH）将导致邻接进入初始化状态；但是，ISH的接收不会对邻接的三向状态产生影响，邻接状态会一直保持稳定，直到它从包含三向握手选项的邻居接收到IIH为止。
In addition, the neighbor's system ID and (newly defined) extended circuit ID are reported in order to detect the case where the same stream is being received by multiple systems (only one of which can talk back).
此外，报告邻居的系统ID和（新定义的）扩展电路ID，以便检测多个系统（其中只有一个可以回话）正在接收相同流的情况。
The mechanism is quite similar to the one defined in the Netware Link Services Protocol (NLSP) [NetLink], a variant of IS-IS used for routing Internetwork Packet Exchange (IPX) traffic. The difference between this mechanism and the one used in NLSP is the location where the information is carried (NLSP uses two of the reserved bits in the IIH header, whereas this solution adds a separate option to the IIH), and the presence of the neighbor's system ID and circuit ID. In theory, using the reserved header bits should be backward compatible, since systems are supposed to ignore them. However, it was felt that this was risky, as the use of untested mechanisms such as this have led to problems in the past in other protocols. New option codes, on the other hand, have been demonstrated to work properly, as the deployment of Integrated IS-IS for IP [RFC1195] has done exactly this.
该机制与Netware链路服务协议（NLSP）[NetLink]中定义的机制非常相似，它是is-is的一个变体，用于路由网络间数据包交换（IPX）流量。此机制与NLSP中使用的机制之间的区别在于信息的传输位置（NLSP使用IIH报头中的两个保留位，而此解决方案为IIH添加了一个单独的选项），以及邻居的系统ID和电路ID。理论上，使用保留的头比特应该是向后兼容的，因为系统应该忽略它们。然而，有人认为这是有风险的，因为使用这种未经测试的机制过去在其他议定书中导致了问题。另一方面，新的选项代码已被证明能正常工作，因为IP集成IS-IS[RFC1195]的部署正是这样做的。
The new mechanism only comes into play when the remote system includes the new option in its IIH packet; if the option is not present, it is assumed that the system does not support the new mechanism, and so the old procedures are used.
只有当远程系统在其IIH数据包中包含新选项时，新机制才会发挥作用；如果不存在该选项，则假定系统不支持新机制，因此使用旧程序。
The IS-IS specification has an implicit limit of 256 interfaces, as constrained by the eight-bit Circuit ID field carried in various packets. Moderately clever implementers have realized that the only true constraint is that of 256 LAN interfaces, and for that matter only 256 LAN interfaces for which a system is the Designated IS. This is because the only place that the circuit ID is advertised in LSPs is in the pseudo-node LSP ID.
IS-IS规范有256个接口的隐式限制，受各种数据包中携带的8位电路ID字段的限制。适度聪明的实现者已经意识到，唯一真正的约束是256个LAN接口，就这一点而言，只有256个LAN接口指定了一个系统。这是因为在LSP中通告电路ID的唯一位置是伪节点LSP ID。
Implementers have treated the point-to-point circuit ID number space as being independent from that of the LAN interfaces, since these circuit IDs appear only in IIH PDUs and are only used for detection of a change in identity at the other end of a link. More than 256 point-to-point interfaces have been supported by sending the same circuit ID on multiple interfaces. This reduces the robustness of the ID change detection algorithm, since it would then be possible to switch links between interfaces on a system without detecting the change.
实施者已将点到点电路ID编号空间视为独立于LAN接口的编号空间，因为这些电路ID仅出现在IIH PDU中，并且仅用于检测链路另一端的标识变化。通过在多个接口上发送相同的电路ID，支持超过256个点对点接口。这降低了ID更改检测算法的鲁棒性，因为这样就可以在系统上的接口之间切换链路而不检测更改。
Since the circuit ID is an integral part of the new handshaking mechanism, a backward-compatible mechanism for expanding the circuit ID number space is included in this specification.
由于电路ID是新握手机制的一个组成部分，因此本规范中包括用于扩展电路ID号空间的向后兼容机制。
The detailed syntax and procedures for this IS-IS option are given below.
下面给出了此IS-IS选项的详细语法和过程。
A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is defined:
定义了一种新的IS-IS选项类型“点对点三向邻接”：
Type - 0xF0 (decimal 240)
类型-0xF0（十进制240）
Length - total length of the value field (1 to 17 octets)
长度-值字段的总长度（1到17个八位字节）
Value -
No. of Octets
+-----------------------------------+
| Adjacency Three-Way State | 1
+-----------------------------------+
| Extended Local Circuit ID | 4
+-----------------------------------+
| Neighbor System ID | ID Length
+-----------------------------------+
| Neighbor Extended Local Circuit ID| 4
+-----------------------------------+
Value -
No. of Octets
+-----------------------------------+
| Adjacency Three-Way State | 1
+-----------------------------------+
| Extended Local Circuit ID | 4
+-----------------------------------+
| Neighbor System ID | ID Length
+-----------------------------------+
| Neighbor Extended Local Circuit ID| 4
+-----------------------------------+
Adjacency Three-Way State The adjacency three-way state of the point-to-point adjacency. The following values are defined:
邻接三向状态点对点邻接的邻接三向状态。定义了以下值：
0 - Up 1 - Initializing 2 - Down
0-向上1-初始化2-向下
Extended Local Circuit ID Unique ID assigned to this circuit when it is created by this Intermediate system.
扩展本地回路ID由此中间系统创建时分配给此回路的唯一ID。
Neighbor System ID System ID of neighboring Intermediate system if known. The length of this field is equal to "ID Length" of the IIH PDU described in "Point-to-point IS to IS hello PDU" (section 9.7 of [ISIS]).
相邻系统ID相邻中间系统的系统ID（如果已知）。该字段的长度等于“点到点即是hello PDU”（ISIS第9.7节）中描述的IIH PDU的“ID长度”。
Neighbor Extended Local Circuit ID Extended Local Circuit ID of the other end of the point-to-point adjacency if known.
相邻扩展局部电路ID点对点邻接另一端的扩展局部电路ID（如果已知）。
Any system that supports this mechanism SHALL include this option in its Point-to-Point IIH packets.
支持此机制的任何系统应在其点对点IIH数据包中包含此选项。
Any system that does not understand this option SHALL ignore it, and (of course) SHALL NOT include it in its own IIH packets.
任何不理解该选项的系统都应忽略该选项，并且（当然）不应将其包含在自己的IIH数据包中。
Any system that supports this mechanism MUST include the Adjacency Three-Way State field in this option. The other fields in this option SHOULD be included as explained below in section 3.2.
任何支持此机制的系统都必须在此选项中包含“邻接三向状态”字段。该选项中的其他字段应包括在第3.2节中，如下所述。
Any system that is able to process this option SHALL follow the procedures below.
任何能够处理该选项的系统应遵循以下程序。
The new handshake procedure is added to the IS-IS point-to-point IIH state machine after the PDU acceptance tests have been performed.
在执行PDU验收测试后，新的握手过程将添加到is-is点对点IIH状态机中。
Although the extended circuit ID is only used in the context of the three-way handshake, it is worth noting that it effectively protects against the unlikely event where a link is moved to another interface on a system that has the same local circuit ID, because the received PDUs will be ignored (via the checks defined below) and the existing adjacency will fail.
尽管扩展电路ID仅在三向握手的情况下使用，但值得注意的是，它有效地防止了链路移动到具有相同本地电路ID的系统上的另一接口的不太可能的事件，因为接收到的PDU将被忽略（通过以下定义的检查）现有的邻接将失效。
Add a clause e) to the end of "Receiving ISH PDUs by an intermediate system" (section 8.2.2 of [ISIS]):
在“通过中间系统接收ISH PDU”（第8.2.2节[ISIS]）的末尾添加第e）条：
Set the state to be reported in the Adjacency Three-Way State field of the Point-to-Point Three-Way Adjacency option to Down.
将“点对点三向邻接”选项的“邻接三向状态”字段中要报告的状态设置为“向下”。
Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.3 of [ISIS]):
在“发送点对点IIH PDU”（ISIS第8.2.3节）末尾添加第e）条：
The IS SHALL include the Point-to-Point Three-Way Adjacency option in the transmitted Point-to-Point IIH PDU. The current three-way state of the adjacency with its neighbor on the link (as defined in new section 8.2.4.1.1 introduced later in the document) SHALL be reported in the Adjacency Three-Way State field. If no adjacency exists, the state SHALL be reported as Down.
IS应包括传输点对点IIH PDU中的点对点三向邻接选项。应在“邻接三向状态”字段中报告与链路上相邻链路的当前三向邻接状态（定义见本文件后面介绍的新第8.2.4.1.1节）。如果不存在邻接，则状态应报告为“向下”。
The Extended Local Circuit ID field SHALL contain a value assigned by this IS when the circuit is created. This value SHALL be unique among all the circuits of this Intermediate System. The value is not necessarily related to that carried in the Local Circuit ID field of the IIH PDU.
扩展本地电路ID字段应包含在创建电路时由其指定的值。该值在该中间系统的所有电路中应是唯一的。该值不一定与IIH PDU的本地电路ID字段中携带的值相关。
If the system ID and Extended Local Circuit ID of the neighboring system are known (in adjacency three-way state Initializing or Up), the neighbor's system ID SHALL be reported in the Neighbor System ID field, and the neighbor's Extended Local Circuit ID SHALL be reported in the Neighbor Extended Local Circuit ID field.
如果相邻系统的系统ID和扩展本地电路ID已知（处于邻接三向状态初始化或向上），则应在邻居系统ID字段中报告邻居的系统ID，并在邻居扩展本地电路ID字段中报告邻居的扩展本地电路ID。
Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to "IIH PDU Processing" (section 8.2.4.2 of [ISIS]):
在“IIH PDU处理”（ISIS第8.2.4.2节）之前添加第8.2.4.1.1节“三方握手”：
A received Point-to-Point IIH PDU may or may not contain the Point-to-Point Three-Way Adjacency option. If it does not, the link is assumed to be functional in both directions, and the procedures described in section 8.2.4.2 are followed.
接收到的点对点IIH PDU可能包含也可能不包含点对点三向邻接选项。如果没有，则假定链路在两个方向上都起作用，并遵循第8.2.4.2节中描述的程序。
If the option is present and contains invalid Adjacency Three-Way State, the PDU SHALL be discarded and no further action is taken.
如果该选项存在且包含无效的邻接三向状态，则应丢弃PDU，且不采取进一步措施。
If the option with a valid Adjacency Three-Way State is present, the Neighbor System ID and Neighbor Extended Local Circuit ID fields, if present, SHALL be examined. If they are present, and the Neighbor System ID contained therein does not match the local system's ID, or the Neighbor Extended Local Circuit ID does not match the local system's extended circuit ID, the PDU SHALL be discarded and no further action is taken.
如果存在具有有效邻接三向状态的选项，则应检查相邻系统ID和相邻扩展本地电路ID字段（如果存在）。如果它们存在，并且其中包含的相邻系统ID与本地系统的ID不匹配，或者相邻扩展本地电路ID与本地系统的扩展电路ID不匹配，则应丢弃PDU，并且不采取进一步的措施。
If the Neighbor System ID and Neighbor Extended Local Circuit ID fields match those of the local system, or are not present, the procedures described in section 8.2.4.2 are followed with the following changes:
如果邻居系统ID和邻居扩展本地电路ID字段与本地系统的匹配或不存在，则按照第8.2.4.2节所述程序进行以下更改：
a) In section 8.2.4.2 a and b, the action "Up" from state tables 5, 6, 7, and 8 may create a new adjacency but the three-way state of the adjacency SHALL be Down.
a) 在第8.2.4.2节a和b中，状态表5、6、7和8中的动作“向上”可能会创建新的邻接，但邻接的三向状态应为向下。
b) If the action taken from section 8.2.4.2 a or b is "Up" or "Accept", the IS SHALL perform the action indicated by the new adjacency three-way state table below, based on the current adjacency three-way state and the received Adjacency Three-Way State value from the option. (Note that the procedure works properly if neither field is ever included. This provides backward compatibility to an earlier version of this option.)
b) 如果根据第8.2.4.2节a或b采取的措施为“向上”或“接受”，则is应根据当前邻接三向状态和从选项接收到的邻接三向状态值，执行以下新邻接三向状态表所示的措施。（请注意，如果两个字段都未包含，则该过程将正常工作。这将提供与此选项早期版本的向后兼容性。）
Received Adjacency Three-Way State
Down Initializing Up
--------------------------------------
Down | Initialize Up Down
|
Adj. Initializing | Initialize Up Up
Three- |
Way Up | Initialize Accept Accept
State |
|
Received Adjacency Three-Way State
Down Initializing Up
--------------------------------------
Down | Initialize Up Down
|
Adj. Initializing | Initialize Up Up
Three- |
Way Up | Initialize Accept Accept
State |
|
Adjacency Three-Way State Table
邻接三向状态表
If the new action is "Down", an adjacencyStateChange(Down) event is generated with the reason "Neighbor restarted" and the adjacency SHALL be deleted.
如果新操作为“关闭”，将生成一个邻接系统状态更改（关闭）事件，原因为“邻居重新启动”，并且应删除邻接。
If the new action is "Initialize", no event is generated and the adjacency three-way state SHALL be set to "Initializing".
如果新操作为“初始化”，则不会生成任何事件，相邻三向状态应设置为“初始化”。
If the new action is "Up", an adjacencyStateChange(Up) event is generated.
如果新操作为“向上”，将生成一个adjacencyStateChange（向上）事件。
c) Skip section 8.2.4.2 c and d.
c) 跳过第8.2.4.2节c和d。
d) If the new action is "Initialize", "Up", or "Accept", follow section 8.2.4.2 e.
d) 如果新操作为“初始化”、“启动”或“接受”，请遵循第8.2.4.2 e节。
This document specifies IS-IS Option 240 (0xF0), which has already been allocated. See [RFC3359].
本文件规定了IS-IS选项240（0xF0），该选项已分配。参见[RFC3359]。
This document raises no new security issues for IS-IS. IS-IS security may be used to secure the IS-IS messages discussed here. See [RFC5304].
本文档没有为IS-IS提出新的安全问题。IS-IS安全性可用于保护此处讨论的IS-IS消息。参见[RFC5304]。
This document is a minor edit of [RFC3373] with the intent of advancing it from Informational to Standards Track. It also updates the ISP 10589 reference to refer to the current "2002" version.
本文件是[RFC3373]的一个小版本，旨在将其从信息性轨道推进到标准轨道。它还更新了ISP 10589参考，以参考当前的“2002”版本。
Thanks to Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg, and Philip Christian for their contributions to the document.
感谢Tony Li、Henk Smit、Naiming Shen、Dave Ward、Jeff Learman、Les Ginsberg和Philip Christian对该文件的贡献。
[ISIS] ISO, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", International Standard 10589:2002, Second Edition, 2002.
[ISIS]ISO，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由信息交换协议（ISO 8473）”，国际标准10589:2002，第二版，2002年。
[NetLink] "Netware Link Services Protocol Specification, Version 1.0", Novell, Inc., February 1994.
[NetLink]“Netware链路服务协议规范，版本1.0”，Novell，Inc.，1994年2月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC 11951990年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies", RFC 3373, September 2002.
[RFC3373]Katz，D.和R.Saluja，“中间系统对中间系统（IS-IS）点对点邻接的三向握手”，RFC 3373，2002年9月。
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.
[RFC3359]Przygienda，T，“中间系统到中间系统中的保留类型、长度和值（TLV）码点”，RFC 3359，2002年8月。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, October 2008.
[RFC5304]Li，T.和R.Atkinson，“IS-IS加密认证”，RFC 5304，2008年10月。
Authors' Addresses
作者地址
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Dave Katz Juniper Networks美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
Phone: +1-408-745-2073
EMail: dkatz@juniper.net
Phone: +1-408-745-2073
EMail: dkatz@juniper.net
Rajesh Saluja Tenet Technologies 30/31, 100 Feet Road, Madiwala Bangalore - 560 068 INDIA
Rajesh Saluja Tenet Technologies 30/31，班加罗尔马迪瓦拉100英尺路-印度560068
Phone: +91 80 552 2215
EMail: rajesh.saluja@tenetindia.com
Phone: +91 80 552 2215
EMail: rajesh.saluja@tenetindia.com
Donald E. Eastlake 3rd Eastlake Enterprises 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake 3rd Eastlake Enterprises美国马萨诸塞州米尔福德海狸街155号01757
Phone: +1-508-634-2066
EMail: d3e3e3@gmail.com
Phone: +1-508-634-2066
EMail: d3e3e3@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.