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
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への中間システム）は、ポイントツーポイントリンクのためのリンク層で信頼性の高いプロトコルが必要です。ポイントツーポイントメディア上の隣接関係を確立するときその結果、3ウェイハンドシェイクを使用していません。本稿では、スリーウェイハンドシェイクのために提供するプロトコルに後方互換性拡張を定義します。これは、拡張をサポートしないシステムとの完全な相互運用が可能です。
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.
この拡張は、複数のルータベンダによって実装されています。この論文は、相互運用可能な実装は、他のベンダーによって構築されることを可能にするためにインターネットコミュニティに提供されます。
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
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.
ISISプロトコル[ISIS]は、ポイントツーポイントリンク上でISISの動作のためにISO 10589（セクション6.7.2）に記載されている特定の要件を前提とし、従って、ポイント - 上の隣接関係を確立する唯一の双方向ハンドシェイクを提供しますポイントツーポイントのリンク。ポイントツーポイントリンクのためのこれらのサブネットワークの要件が満たされていない場合、プロトコルが正しく動作しません。標準で定義された基本的なメカニズムは、それぞれの側は、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).
3つの障害モードが知られています。まず、リンクがダウンした場合、その後復帰した、またはシステムが再起動するの1、およびCSNPパケットが失われ、ネットワークは、リンクの両側でリンクを介して1セットのカット、リンク状態データベースを持っています（18時間まで）の完全なリンクステートプロトコルデータユニット（LSP）リフレッシュ期間に同期しません。
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).
二、より深刻な障害は、リンクが一方向のみに失敗した場合、障害が唯一のシステムのいずれかによって検出されることです。通常は2つのだけのシステムの一つは、そのリンクステートパケットに隣接を発表する、とSPFアルゴリズムは、このようにリンクを無視します。しかし、そこにシステム間の二つの平行リンクがあり、そのうちの一つが一方向に失敗した場合、SPFはまだ2つのシステム間の経路を計算し、故障に気付かないシステムは、中（失敗したリンクダウントラフィックを通過しようとします動作しない方向）。
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.
ここで提案された解決策は、信頼できない、ポイントツーポイントリンク上でプロトコルの正しい動作を保証します。スリーウェイハンドシェイクの問題に対する解決策の一環として、この方法は、ISIS [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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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ハロー（IIH）を受信していることを知っている場合のみに、システムが最大であると隣接関係を宣言できるように、各システムがその隣接三方状態を報告することを可能にする任意の機構を提供することによって行われますパケット。
The adjacency three-way state can be one of the following types:
隣接3ウェイ状態は、次のタイプのいずれかになります。
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.
このダウン初期のポイント・ツー・ポイントの隣接3ウェイ状態です。システムは、このポイントツーポイント回線上の3ウェイハンドシェイクオプションを含む任意の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.
システムの初期化は、近隣からの3ウェイハンドシェイクオプションを含む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.
このメカニズムによって報告される隣接三方状態は[ISIS] ISO 10589に記載されている隣接状態に等しいかまたは等しくありません。このメカニズムがサポートされている場合ISO 10589 [ISIS]、およびその三元状態で定義されるように、次に隣接は、2つの状態、その状態を有していてもよいです。例えば、ISO 10589によると、中間システムのHello（ISH）の領収書は、状態を初期化するに行くの隣接関係の原因となります。しかし、ISHの領収書は、3ウェイハンドシェイクオプションが含まれている隣人からIIHを受信するまでしっかりと下に残っている隣接の3ウェイ状態には影響を与えません。
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は、同じストリームが（1つのみの背面話すことができる）複数のシステムによって受信されている場合を検出するために報告されています。
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で使用したものとの差分情報が搬送される場所である（この溶液は、IIHに別のオプションを追加し、一方NLSPは、IIHヘッダ内の予約ビットのうちの2つを使用して）、そして隣人の存在システムIDおよび回路ID。システムはそれらを無視するようになっているので、理論的には、予約済みヘッダ・ビットを使用して、下位互換性があるべきです。しかし、このようなテストされていないメカニズムの使用は他のプロトコルでは、過去の問題につながっているとして、これは、危険なだったと感じられました。 IP [RFC1195]はまさにこれを行っているため、統合の展開は、IS-ISなどの新しいオプションコードは、他の一方で、正常に動作することが実証されています。
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.
様々なパケットで運ばれた8ビット回線IDフィールドによって制約として仕様は、256のインターフェイスの暗黙の限界を有しているが、です。適度に巧妙な実装では唯一の真の制約が256のLANインタフェースのことであり、そのことについては、システムが指定されているだけで256 LANインターフェイスがあることを実現しています。回路IDは、LSPの中にアドバタイズされる唯一の場所は、擬似ノード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はIIHのPDUにのみ表示され、唯一のリンクの他端に同一の変化を検出するために使用されるので、実装は、LANインタフェースとは独立しているように、ポイントツーポイント回線ID番号空間を処理しています。 256以上のポイント・ツー・ポイント・インタフェースは、複数のインターフェイス上で同じ回路IDを送信することによってサポートされています。その後の変化を検出することなく、システム上のインターフェース間のリンクを切り替えることが可能であろうので、これは、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
+-----------------------------------+
Adjacency Three-Way State The adjacency three-way state of the point-to-point adjacency. The following values are defined:
隣接スリーウェイポイントツーポイント隣接関係の国家隣接3ウェイ状態。次の値が定義されています。
0 - Up
1 - Initializing
2 - Down
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が知られている場合。このフィールドの長さは、「ポイントツーポイントハローPDU ISである」（[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.
このメカニズムをサポートする任意のシステムは、このオプションに隣接スリーウェイStateフィールドを含まなければなりません。 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]):
[ISIS]）のセクション8.2.2（「中間システムによってISH PDUを受信」の末尾に節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.
ダウンへのポイントツーポイントスリーウェイ隣接オプションの隣接スリーウェイStateフィールドで報告されるように状態を設定します。
Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.3 of [ISIS]):
[ISIS]）のセクション8.2.3（「ポイントツーポイントIIH PDUを送信」の末尾に節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で定義される）リンク上でその隣人との隣接関係の現在の3ウェイ状態は隣接スリーウェイStateフィールドに報告しなければなりません。隣接関係が存在しない場合、状態はダウンとして報告しなければなりません。
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が（隣接3ウェイ状態の初期化または最大で）知られている場合は、隣人のシステム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]):
セクション8.2.4.1.1、「スリーウェイハンドシェイク」、直前に「IIH PDUの処理」（[ISIS]のセクション8.2.4.2）を追加します：
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: 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.
隣接システムIDおよび近隣拡張ローカル回線IDフィールドは、ローカルシステムのものと一致する、または存在しない場合、セクション8.2.4.2に記載された手順は、以下の変更を追跡される：a）セクション8.2.4.2およびBにおいて、状態テーブル5、6、7、および8からのアクション「アップ」新しい隣接関係を作成するかもしれないが、隣接の3ウェイ状態がダウンされなければなりません。
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は、現在の隣接3ウェイ状態に基づいて、以下の新しい隣接関係の三方状態表で示されたアクションを実行しなければなりません。そしてオプションから受け取っ隣接スリーウェイステート値。 （どちらのフィールドは、これまで含まれている場合の手順が正しく動作していることに注意してください。これは、このオプションの以前のバージョンとの下位互換性を提供します。）
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.
新しいアクションが「ダウン」である場合には、adjacencyStateChange（ダウン）イベントは、「隣人を再起動」の理由で生成され、隣接関係が削除されるもの。
If the new action is "Initialize", no event is generated and the adjacency three-way state SHALL be set to "Initializing".
新しいアクションは、「初期化」されている場合、イベントが生成されず、隣接3ウェイ状態を「初期化」に設定されなければなりません。
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電子に従っている場合。
This document specifies IS-IS Option 240 (0xF0), which has already been allocated. See [RFC3359].
この文書では、すでに割り当てられているオプション240（0xF0が）、IS-ISを指定します。 [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]の細部の編集です。また、現在「2002」バージョンを参照するためにISP 10589参照を更新します。
Thanks to Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg, and Philip Christian for their contributions to the document.
文書への貢献のためのトニー・リー、ヘンクスミット、Naimingシェン、デイブ・ワード、ジェフLearman、レ・ギンズバーグ、そしてフィリップ・キリストに感謝します。
[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.
2002年、第2版、2002年、国際標準10589「接続モード・ネットワーク・サービス（ISO 8473）を提供するためのプロトコルと組み合わせて使用するための情報交換プロトコルをrouteingする中間システムイントラドメインへの中間システム」[ISIS] ISO、。
[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.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]カッツ、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]李、T.、およびR.アトキンソンは、 "IS-IS暗号認証"、RFC 5304、2008年10月。
Authors' Addresses
著者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
デイブ・カッツジュニパーネットワークスの1194 N.マチルダアベニュー。サニーベール、CA 94089 USA
Phone: +1-408-745-2073 EMail: dkatz@juniper.net
電話：+ 1-408-745-2073 Eメール：dkatz@juniper.net
Rajesh Saluja Tenet Technologies 30/31, 100 Feet Road, Madiwala Bangalore - 560 068 INDIA
ラジェッシュSalujaテネット・テクノロジーズ30/31、100フィートロード、Madiwalaバンガロール - 560 068 INDIA
Phone: +91 80 552 2215 EMail: rajesh.saluja@tenetindia.com
電話：+91 80 552 2215 Eメール：rajesh.saluja@tenetindia.com
Donald E. Eastlake 3rd Eastlake Enterprises 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第三イーストレイク企業155ビーバー通りミルフォード、MA 01757 USA
Phone: +1-508-634-2066 EMail: d3e3e3@gmail.com
電話：+ 1-508-634-2066 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。