RFC3373 日本語訳
3373 Three-Way Handshake for Intermediate System to IntermediateSystem (IS-IS) Point-to-Point Adjacencies. D. Katz, R. Saluja. September 2002. (Format: TXT=19522 bytes) (Obsoleted by RFC5303) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Katz
Request for Comments: 3373 Juniper Networks, Inc.
Category: Informational R. Saluja
Tenet Technologies
September 2002
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 3373年の杜松はInc.カテゴリをネットワークでつなぎます: 情報のR.Saluja主義技術2002年9月
Three-Way Handshake for
Intermediate System to Intermediate System (IS-IS)
Point-to-Point Adjacencies
中間システムへの中間システムのための3方向ハンドシェイク、(-、)、二地点間隣接番組
Status of this Memo
この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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
The IS-IS routing protocol (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.
-、ルーティング・プロトコル(ISO10589)はリンクレイヤで信頼できるプロトコルをポイントツーポイント接続に必要とします。 ポイントからポイントへのメディアで隣接番組を確立するとき、その結果、それは3方向ハンドシェイクを使用しません。 この論文は後方コンパチブル拡大を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 as information to the Internet community in order to allow interoperable implementations to be built by other vendors.
この拡大は複数のルータ業者によって実行されました。 共同利用できる実現が他の業者によって組み込まれるのを許容するために情報としてこの紙をインターネットコミュニティに提供します。
1. Terms
1. 用語
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 BCP 14, RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119)で説明されるように本書では解釈されることであるべきです。
2. Introduction
2. 序論
The IS-IS protocol [1] 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
-、プロトコル[1]が、要件が操作のためにISO10589に(セクション6.7.2)を述べたのを確信していると仮定する、-、創業するとき、ポイントツーポイントの上でリンクして、したがって、両用握手だけを提供します。
Katz & Saluja Informational [Page 1] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[1ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
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.
ポイントツーポイント接続の上の隣接番組。 ポイントツーポイント接続のためのこれらのサブネットワーク必要条件が満たされないなら、プロトコルは正しく作動しません。 規格で定義された基本的機構はHelloパケットがそれから聞かれるならそれぞれの側が、反対側に届いていると宣言するということです。 一度、これは起こって、次に、それぞれの側は、データベース同期の引き金となるように、Complete Sequence Number 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 LSP refresh period (up to eighteen hours).
3つの故障モードが知られています。 まず最初に、リンクが落ちて、次に、上って来て戻るか、システムの1つが再開して、CSNPパケットが無くなって、またはネットワークがリンクを通して1つの切断集合の1つを持っているなら、リンクのどちらかの側面のデータベースが完全な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).
1秒(より重大な失敗)はリンクが一方向だけに失敗する場合にだけ、失敗がシステムの1つで検出されるということです。通常2台のシステムの唯一のひとりがリンク州のパケットで隣接番組を発表するでしょう、そして、その結果、SPFアルゴリズムは関連性を無視するでしょう。 しかしながら、システムの間には、2個の平行なリンクがあって、それらの1つが一方向に失敗すると、それでも、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.
3番目の問題はいくつかの物理的な層では、終点の間の相互接続性がリンク層がダウンしている状態を引き起こさないで変化できるということです。 この場合、システムは異系統(または、同じシステムの上の異なったリンク)のために実際に運命づけられているパケットを受けるかもしれません。 事実上、リモートシステムが結局3番目のシステムで隣接しているとき、受電方式は、それには隣接番組があるとリモートシステムと思うかもしれません。
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 [1]. This method is more robust than the ad hoc methods currently in use.
ここで提案された解決策は頼り無いポイントツーポイント接続の上でプロトコルの正しい操作を確実にします。 3者間のハンドシェイク問題の解決の一部と、方法が課された255の二地点間インタフェースの制限を取り除くために定義される、-、[1]。 この方法は現在使用中の臨時の方法より強健です。
3. Overview of Extensions
3. 拡大の概観
3.1 Handshaking
3.1 ハンドシェイク
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; this allows 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.
意図は後方のコンパチブルファッションへの二地点間隣接番組設立に3方向ハンドシェイクを提供することです。 各システムが隣接番組の3者間の状態を報告できる任意のメカニズムを提供することによって、これをします。 もう片方のシステムが受信されているのを知っている場合にだけシステムが、これで隣接番組が上がっていると宣言できる、それ、-、Hello(IIH)パケット。
Katz & Saluja Informational [Page 2] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[2ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
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.
下にThisは初期の二地点間隣接番組3者間の状態です。 システムはまだこの二地点間サーキットの上に3方向ハンドシェイクオプションを保管しているIIHパケットを受けていません。
Initializing
The system has received 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 [1]. If this mechanism is supported then an adjacency may have two states, its state as defined in ISO 10589 [1], and its three-way state. For example according to ISO 10589 [1] receipt of an 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.
このメカニズムによって報告される隣接番組の3者間の状態は、ISO10589[1]で説明される隣接番組状態に、等しくもなくて、また同等でもありません。 このメカニズムがサポートされるなら、隣接番組には、2つの州(ISO10589[1]、およびその3者間の状態で定義される状態)があるかもしれません。 例えば、ISO10589によると、隣接番組はISHの[1]領収書でInitializing状態に行くでしょう。 ISHの領収書はしっかり残っている隣接番組の3者間の状態でどのように効き目がなくても、それまでのDownが3者間のハンドシェイクオプションを含む隣人から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は、複数のシステム(それの1つしか返事をすることができない)によって同じ小川が受け取られているケースを検出するために報告されます。
The mechanism is quite similar to the one defined in the Netware Link Services Protocol (NLSP) [2], a variant of IS-IS used for routing 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 [3] has done exactly this.
メカニズムはNetware Link Servicesプロトコル(NLSP)[2]で定義されたものと全く同様です、異形、-、ルーティングIPX交通において、使用されています。 NLSPで使用されるこのメカニズムとものの違いは、情報が運ばれる(NLSPがIIHヘッダーで予約された2ビットを使用しますが、この解決策は別々のオプションをIIHに加えます)位置と、隣人のシステムIDとサーキットIDの存在です。 理論上、予約されたヘッダービットを使用するのが後方にあるべきです。互換性があるので、システムが思われるので、それらを無視してください。 しかしながら、これが危険であると感じられました、これなどの試されていないメカニズムの使用が過去に他のプロトコルで問題を引き起こしたとき。 他方では、新しいオプションコードは適切に働くために示されました、Integratedの展開として-、IPに関しては、[3]がちょうどこれをしました。
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パケットに新しいオプションを含んでいると、新しいメカニズムはプレーに入るだけです。 オプションが存在していないなら、システムが新しいメカニズムをサポートしないと思われて、古い手順は使用されています。
Katz & Saluja Informational [Page 3] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[3ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
3.2 More Than 256 Interfaces
3.2 256以上のインタフェース
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 implementors 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 pseudonode LSP ID.
-、仕様、様々なパケットで運ばれた8ビットのCircuit ID野原によって抑制されるように256のインタフェースの暗黙の限界を持っています。 適度に賢い作成者は、唯一の本当の規制が256のLANインタフェースのものと、さらに言えば、システムがDesignatedがあるということである256のLANインタフェースにすぎないとわかりました。 これによる唯一がそれを置くのでサーキットIDが中の広告に掲載されていて、LSPsがpseudonode LSP IDにあるということであるということです。
Implementors 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.
作成者は二地点間Circuit ID数のスペースをLANインタフェースのものから独立しているとして扱いました、これらのCircuit IDがIIH PDUsだけに現れて、リンクのもう一方の端のアイデンティティにおける変化の検出に使用されるだけであるので。 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.
Circuit IDが新しいハンドシェイクメカニズムの不可欠の部分であるので、サーキットID数のスペースを広げるための後方のコンパチブルメカニズムはこの仕様に含まれています。
4. Details
4. 詳細
4.1 Syntax
4.1構文
A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is defined:
A新しい、-、「二地点間3者間の隣接番組」というOptionタイプは定義されます:
x Type - 0xF0 (decimal 240)
x Length - total length of the value field (1 to 17 octets)
x 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
+-----------------------------------+
xタイプ--0xF0(10進240)x Length--値の分野(1〜17の八重奏)x Valueの全長--Octets+のNo.-----------------------------------+ | 隣接番組の3者間の状態| 1 +-----------------------------------+ | 拡張局部回線ID| 4 +-----------------------------------+ | 隣人System ID| IDの長さ+-----------------------------------+ | 隣人の拡張局部回線ID| 4 +-----------------------------------+
Katz & Saluja Informational [Page 4] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[4ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
Adjacency Three-Way State
The adjacency three-way state of the point-to-point adjacency. The
following values are defined:
隣接番組Three-道の州、二地点間隣接番組の隣接番組の3者間の状態。 以下の値は定義されます:
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.
それがこのIntermediateシステムによって作成されるときこのサーキットに割り当てられた拡張Local Circuit ID Unique ID。
Neighbor System ID
System ID of neighbor Intermediate system if known. The length of
this field is equal to "ID Length" of IIH PDU described in section
"Point-to-point IS to IS hello PDU" (section 9.7 of [1]).
知られているなら、隣人IntermediateシステムのSystem ID System IDを近所付き合いさせてください。 こんにちは、PDU。この分野の長さがセクションで説明されたIIH PDUの「IDの長さ」と等しい、「ポイントツーポイントがある、」 (セクション9.7の[1])。
Neighbor Extended Local Circuit ID
Extended Local Circuit ID of the other end of the point-to-point
adjacency if known.
知られるなら、もう片方の隣人Extended Local Circuit ID Extended Local Circuit IDは二地点間隣接番組を終わらせます。
Any system that supports this mechanism SHALL include this option in its Point-to-Point IIH packets.
このメカニズムSHALLを支持するどんなシステムもPointからポイントへのIIHパケットにこのオプションを含んでいます。
Any system that does not understand this option SHALL ignore it, and (of course) SHALL NOT include it in its own IIH packets.
このオプションSHALLを理解していないどんなシステムもそれを無視します、そして、(もちろん)SHALL NOTはそれ自身のIIHパケットにそれを含んでいます。
Any system that supports this mechanism MUST include Adjacency Three-Way State field in this option. The other fields in this option SHOULD be included as explained below in section 3.2.
このメカニズムをサポートするどんなシステムもこのオプションにAdjacency Three-道の州分野を含まなければなりません。 以下でセクション3.2で説明されるように含まれていて、もう片方がこのオプションでSHOULDをさばきます。
Any system that is able to process this option SHALL follow the procedures below.
SHALLが手順に従うこのオプションを処理できるどんなシステム。
4.2 Elements of Procedure
4.2 手順のElements
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受取り検査が実行された後にポイントツーポイント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, as the received PDUs will be ignored (via the checks defined below) and the existing adjacency will fail.
拡張サーキットIDは3方向ハンドシェイクの文脈で使用されるだけですが、リンクが同じ局部回線IDを持っているシステムの上で別のインタフェースに動かされるところで事実上、ありそうもない出来事から守ることに注意する価値があります、容認されたPDUsが無視されて(以下で定義されたチェックで)、既存の隣接番組が失敗するとき。
Katz & Saluja Informational [Page 5] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[5ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
Add a clause e) to the end of section "Receiving ISH PDUs by an intermediate system" (section 8.2.2 of [1]):
「中間システムはISH PDUsを受け」ながら、節e)をセクションの端に加えてください。([1])について8.2に.2を区分してください:
Set the state to be reported in the Adjacency Three-Way State
field of the Point-to-Point Three-Way Adjacency option to Down.
状態にPointからポイントへのThree-道のAdjacencyオプションのAdjacency Three-道の州分野でDownに報告されるように設定してください。
Add a clause e) to the end of section "Sending point-to-point IIH PDUs" (section 8.2.3 of [1]):
「ポイントツーポイントIIH PDUsを送り」ながら、節e)をセクションの端に加えてください。([1])について8.2に.3を区分してください:
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 SHALLはPointからポイントへの伝えられたIIH PDUのPointからポイントへのThree-道のAdjacencyオプションを含んでいます。 隣人がAdjacency Three-道の州分野でリンク(新しいセクション8.2.4で.1が後でドキュメントで導入した.1を定義するので)SHALLに関して報告されている隣接番組の現在の3者間の状態。 隣接番組はいいえなら存在していて、状態はSHALLです。Downとして、報告されます。
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.
Extended Local Circuit ID分野SHALLは割り当てられた値を含んでいます。これはサーキットが作成される時です。 これはSHALLを評価します。このIntermediate Systemのすべてのサーキットの中でユニークであってください。 値は必ずIIH PDUのLocal Circuit 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とExtended Local Circuit IDは知られています(隣接番組の3者間の州のInitializingかUpで)、隣人のシステムID SHALL。報告されたコネがNeighbor Extended Local Circuit ID分野であったならNeighbor System ID分野、および隣人のExtended Local Circuit ID SHALLで報告されてください。
Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to section "IIH PDU Processing" (section 8.2.4.2 of [1]):
セクション8.2.4を加えてください、.1、.1、すぐ「IIH PDU処理」というセクションの前の「3方向ハンドシェイク」、(セクション8.2 .4 .2 [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.
Pointからポイントへの容認されたIIH PDUはPointからポイントへのThree-道のAdjacencyオプションを含むかもしれません。 そうしないなら、リンクによるセクション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.
オプションは、存在していて、無効のAdjacency Three-道の州を含みます、PDU SHALL。これ以上捨てられないで、行動を取ります。
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.
存在しているなら、州がプレゼントと、Neighbor System IDとNeighbor Extended Local Circuit ID分野である有効なAdjacency Three-方法SHALLとのオプションであるなら、調べられてください。 それらが存在していて、そこに含まれたNeighbor System IDがローカルシステムのIDに合わないか、捨てられて、Neighbor Extended Local Circuit IDがローカルシステムが広げたどんなマッチにもサーキットID、PDU SHALLをしないで、またまたはさらなる行動を全く取らないなら。
Katz & Saluja Informational [Page 6] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[6ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
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
following changes:
Neighbor System IDとNeighbor Extended Local Circuit ID分野がローカルシステムのものを合わせないで、またプレゼント、変化に続く.2が続かれているセクション8.2.4で説明された手順でないなら:
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.2aとbでは、ステートテーブル5、6、7、および8からの動作“Up"は新しい隣接番組を作成するかもしれませんが、3者間は、隣接番組についてSHALLがDownであると述べます。
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.2aかbから取られた行動が“Up"か「受け入れてください」であるなら、IS SHALLは以下の新しい隣接番組3者間のステートテーブルによって示された動作を実行します、オプションからの現在の隣接番組3者間の状態と容認されたAdjacency Three-道の州価値に基づいて。 (どちらの分野もかつて含まれていないなら手順が適切に働くことに注意してください。 これはこのオプションの以前のバージョンに後方の互換性を提供します。)
Received Adjacency Three-Way State
Down Initializing Up
-------------------------------------------------
Down | Initialize Up Down
|
adj Initializing | Initialize Up Up
three |
-way Up | Initialize Accept Accept
state |
|
初期値設定の下側に上がっている容認された隣接番組3者間の州------------------------------------------------- 下に| 下に、初期化します。| adj Initializing| Up Up threeを初期化してください。| -道のUp| Accept Accept状態を初期化してください。| |
Adjacency Three-Way State Table
隣接番組の3者間のステートテーブル
If the new action is "Down", an adjacencyStateChange(Down)
event is generated with the reason "Neighbor restarted" and the
adjacency SHALL be deleted.
新しい動きが“Down"であるなら、「隣人は再開した」理由と隣接番組SHALLが削除されている状態で、adjacencyStateChange(Down)出来事は発生します。
If the new action is "Initialize", no event is generated and
the adjacency three-way state SHALL be set to "Initializing".
新しい動きが「初期化」、出来事が全く発生しないということであり、隣接番組の3者間の状態がSHALLであるなら、「初期値設定」に設定されてください。
If the new action is "Up", an adjacencyStateChange(Up)
event is generated.
新しい動きが“Up"であるなら、adjacencyStateChange(Up)出来事は発生します。
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) “Up"、新しい動きが「初期化」であるか「受け入れてください」、尾行セクション8.2.4.2がeであるなら。
Katz & Saluja Informational [Page 7] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[7ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
5. Security Considerations
5. セキュリティ問題
This document raises no new security issues for IS-IS.
このドキュメントがどんな新しい安全保障問題も提起しない、-
6. References
6. 参照
[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:1992.
[1] ISO、「Intermediateシステムへのプロトコルに関連したConnectionless-モードNetwork Service(ISO8473)を提供する使用のために情報交換プロトコルをrouteingする中間システム」、ISO/IEC、10589:1992
[2] "Netware Link Services Protocol Specification, Version 1.0",
Novell, Inc., February 1994.
[2] 「ネットウェアリンクサービスは1994年2月に仕様、バージョン1インチ、ノベルInc.について議定書の中で述べます」。
[3] Callon, R., "OSI IS-IS for IP and Dual Environment", RFC 1195,
December 1990.
[3]Callon、R.、「OSI、-、IPと二元的な環境、」、RFC1195、12月1990日
7. Acknowledgements
7. 承認
The authors would like to thank Tony Li, Henk Smit, Naiming Shen, Dave Ward, Jeff Learman, Les Ginsberg and Philip Christian for their contributions to this document.
作者はこのドキュメントへの彼らの貢献についてトニー・李、ヘンク・スミット、Naimingシン、デーヴ・ウォード、ジェフLearman、レス・ギンズバーグ、およびフィリップクリスチャンに感謝したがっています。
8. Authors' Addresses
8. 作者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089
デーヴキャッツJuniperは1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
Phone: (408) 745-2073 EMail: dkatz@juniper.net
以下に電話をしてください。 (408) 745-2073 メールしてください: dkatz@juniper.net
Rajesh Saluja Tenet Technologies 30/31, 100 Feet Road, Madiwala Bangalore - 560 068 INDIA
ラジェッシュSaluja主義技術30/31、100足の道路、Madiwalaバンガロール--560 068インド
Phone: +91 80 552 2215 EMail: rajesh.saluja@tenetindia.com
以下に電話をしてください。 +91 80 552 2215はメールされます: rajesh.saluja@tenetindia.com
Katz & Saluja Informational [Page 8] RFC 3373 Three-Way Handshake for IS-IS September 2002
キャッツとSalujaの情報[8ページ]のRFC3373 3方向ハンドシェイク、-、2002年9月
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Katz & Saluja Informational [Page 9]
キャッツとSaluja情報です。[9ページ]
一覧
スポンサーリンク
