RFC5303 日本語訳
5303 Three-Way Handshake for IS-IS Point-to-Point Adjacencies. D.Katz, R. Saluja, D. Eastlake 3rd. October 2008. (Format: TXT=23203 bytes) (Obsoletes RFC3373) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループD.キャッツ要求をネットワークでつないでください: 5303の杜松ネットワークが以下を時代遅れにします。 3373年のR.Salujaカテゴリ: 規格は2008年のD.イーストレークイーストレークエンタープライズ10月3日に主義技術を追跡します。
Three-Way Handshake for IS-IS Point-to-Point Adjacencies
3方向ハンドシェイク、-、二地点間隣接番組
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
-、ルーティング・プロトコル(Intermediate System、ISO10589への中間的System)はリンクレイヤで信頼できるプロトコルをポイントツーポイント接続に必要とします。 二地点間メディアで隣接番組を確立するとき、その結果、それは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 to the Internet community in order to allow interoperable implementations to be built by other vendors.
この拡大は複数のルータ業者によって実行されました。 共同利用できる実現が他の業者によって組み込まれるのを許容するためにこの紙をインターネットコミュニティに提供します。
Katz, et al. Standards Track [Page 1] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[1ページ]-、2008年10月
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. 序論…2 1.1. 用語…3 2. 拡大の概観…3 2.1. ハンドシェイク…3 2.2. 256以上のインタフェース…4 3. 詳細…5 3.1. 構文…5 3.2. 手順のElements…6 4. IANA問題…8 5. セキュリティ問題…9 6. RFC3373からの変化…9 7. 承認…9 8. 標準の参照…9 9. 有益な参照…9
1. Introduction
1. 序論
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.
-、プロトコル[イシス]が、要件が操作のためにISO10589に(セクション6.7.2)を述べたのを確信していると仮定する、-、ポイントツーポイントの上では、ポイントツーポイント接続の上で隣接番組を確立するときの両用握手だけが、リンクして、したがって、提供されています。 ポイントツーポイント接続のためのこれらのサブネットワーク必要条件が満たされないなら、プロトコルは正しく作動しません。 規格で定義された基本的機構は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 Link State Protocol Data Unit (LSP) refresh period (up to 18 hours).
3つの故障モードが知られています。 まず最初に、リンクが落ちて、次に、上って来て戻るか、システムの1つが再開して、CSNPパケットが無くなって、またはネットワークがリンクを通して1つの切断集合の1つを持っているなら、リンクのどちらかの側面のデータベースが完全なLink州プロトコルData Unit(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).
2番目、より重大な失敗はリンクが一方向だけに失敗する場合にだけ、失敗がシステムの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
3番目の問題はいくつかの物理的な層では、終点の間の相互接続性がaを引き起こさないで変化できるということです。
Katz, et al. Standards Track [Page 2] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[2ページ]-、2008年10月
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番目のシステムで隣接しているとき、受電方式は、それには隣接番組があるとリモートシステムと思うかもしれません。
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.
ここで提案された解決策は頼り無いポイントツーポイント接続の上でプロトコルの正しい操作を確実にします。 3者間のハンドシェイク問題の解決の一部と、方法が課された255の二地点間インタフェースの制限を取り除くために定義される、-、[イシス。] この方法は現在使用中の臨時の方法より強健です。
1.1. Terminology
1.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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Overview of Extensions
2. 拡大の概観
This section provides a general overview of the three-way handshaking provided and how more than 256 interfaces are handled.
このセクションは提供された3者間のハンドシェイクと256以上のインタフェースがどう扱われるかの概要を提供します。
2.1. Handshaking
2.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, 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.
意図は後方コンパチブルファッションへの二地点間隣接番組設立に3方向ハンドシェイクを提供することです。 各システムが隣接番組の3者間の状態を報告できる任意のメカニズムを提供することによって、これをします、その結果、もう片方のシステムが受信されているのを知っているならシステムが、隣接番組が上がっていると宣言するだけであるのを許容する、それ、-、Hello(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.
下にThisは初期の二地点間隣接番組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パケットを受けるのを知っています。
Katz, et al. Standards Track [Page 3] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[3ページ]-、2008年10月
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.
このメカニズムによって報告される隣接番組の3者間の状態は、ISO10589[イシス]で説明される隣接番組状態に、等しくもなくて、また同等でもありません。 このメカニズムがサポートされるなら、隣接番組には、2つの州(ISO10589[イシス]、およびその3者間の状態で定義される状態)があるかもしれません。 例えば、ISO10589によると、隣接番組はIntermediate System Hello(ISH)の領収書でInitializing状態に行くでしょう。 しかしながら、ISHの領収書はしっかり残っている隣接番組ではそれまでのDownが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 Link Servicesプロトコル(NLSP)[NetLink]で定義されたものと全く同様です、異形、-、ルーティングInternetwork Packet Exchangeに、中古(IPX)の交通。 NLSPで使用されるこのメカニズムとものの違いは、情報が運ばれる(NLSPがIIHヘッダーで予約された2ビットを使用しますが、この解決策は別々のオプションをIIHに加えます)位置と、隣人のシステムIDとサーキットIDの存在です。 理論上、予約されたヘッダービットを使用するのが後方にあるべきです。互換性があるので、システムが思われるので、それらを無視してください。 しかしながら、これが危険であると感じられました、これなどの試されていないメカニズムの使用が過去に他のプロトコルで問題を引き起こしたとき。 他方では、新しいオプションコードは適切に働くために示されました、Integratedの展開として-、IPに関しては、[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パケットに新しいオプションを含んでいると、新しいメカニズムはプレーに入るだけです。 オプションが存在していないなら、システムが新しいメカニズムをサポートしないと思われて、古い手順は使用されています。
2.2. More than 256 Interfaces
2.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 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ビットのCircuit ID野原によって抑制されるように256のインタフェースの暗黙の限界を持っています。 適度に賢明なimplementersは、唯一の本当の規制が256のLANインタフェースのものと、さらに言えば、システムがDesignatedがあるということである256のLANインタフェースにすぎないとわかりました。 これによる唯一がそれを置くのでサーキットIDが中の広告に掲載されていて、LSPsが疑似ノードLSP IDにあるということであるということです。
Katz, et al. Standards Track [Page 4] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[4ページ]-、2008年10月
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.
Implementersは二地点間サーキットID数のスペースをLANインタフェースのものから独立しているとして扱いました、これらのサーキット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.
サーキットIDが新しいハンドシェイクメカニズムの不可欠の部分であるので、サーキットID数のスペースを広げるための後方コンパチブルメカニズムはこの仕様に含まれています。
3. Details
3. 詳細
The detailed syntax and procedures for this IS-IS option are given below.
これのための詳細な構文と手順、-、下をオプションに与えます。
3.1. Syntax
3.1. 構文
A new IS-IS Option type, "Point-to-Point Three-Way Adjacency", is defined:
A新しい、-、「二地点間3者間の隣接番組」というOptionタイプは定義されます:
Type - 0xF0 (decimal 240)
タイプ--0xF0(10進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
+-----------------------------------+
値--八重奏+についていいえ-----------------------------------+ | 隣接番組の3者間の状態| 1 +-----------------------------------+ | 拡張局部回線ID| 4 +-----------------------------------+ | 隣人System ID| IDの長さ+-----------------------------------+ | 隣人の拡張局部回線ID| 4 +-----------------------------------+
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)はダウンします。
Katz, et al. Standards Track [Page 5] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[5ページ]-、2008年10月
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 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]).
知られているならIntermediateシステムを近所付き合いさせる隣人System ID System ID。 この分野の長さが中で説明されたIIH PDUの「IDの長さ」と等しい、「ポイントツーポイントがある、」 こんにちは、PDUは([イシス]のセクション9.7)ですか?
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 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.
このメカニズムをサポートするどんなシステムもこのオプションにAdjacency Three-道の州分野を含まなければなりません。 以下でセクション3.2で説明されるように含まれていて、もう片方がこのオプションでSHOULDをさばきます。
Any system that is able to process this option SHALL follow the procedures below.
SHALLが手順に従うこのオプションを処理できるどんなシステム。
3.2. Elements of Procedure
3.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, because the received PDUs will be ignored (via the checks defined below) and the existing adjacency will fail.
拡張サーキットIDは3方向ハンドシェイクの文脈で使用されるだけですが、リンクが同じ局部回線IDを持っているシステムの上で別のインタフェースに動かされるところで事実上、ありそうもない出来事から守ることに注意する価値があります、容認されたPDUsが無視されて(以下で定義されたチェックで)、既存の隣接番組が失敗するので。
Add a clause e) to the end of "Receiving ISH PDUs by an intermediate system" (section 8.2.2 of [ISIS]):
「中間システムはISH PDUsを受けます」の終わり(.2セクション8.2[イシス])に節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.
状態にPointからポイントへのThree-道のAdjacencyオプションのAdjacency Three-道の州分野でDownに報告されるように設定してください。
Katz, et al. Standards Track [Page 6] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[6ページ]-、2008年10月
Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.3 of [ISIS]):
「送付ポイントツーポイントIIH PDUs」(.3セクション8.2[イシス])の終わりに節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 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 "IIH PDU Processing" (section 8.2.4.2 of [ISIS]):
セクション8.2.4を加えてください、.1、.1、すぐ「IIH PDU処理」の前の「3方向ハンドシェイク」、(セクション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.
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をしないで、またまたはさらなる行動を全く取らないなら。
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:
Neighbor System IDとNeighbor Extended Local Circuit IDであるなら、分野はローカルシステムのものに合っているか、またはプレゼント、.2が続かれているセクション8.2.4で説明された手順は以下の変化ではありません:
Katz, et al. Standards Track [Page 7] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[7ページ]-、2008年10月
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。 初期値設定| 3を上に初期化してください。| ずっと上がります。| 初期化、受諾、状態を受け入れてください。| |
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であるなら。
4. IANA Considerations
4. IANA問題
This document specifies IS-IS Option 240 (0xF0), which has already been allocated. See [RFC3359].
このドキュメントが指定する、-、Option240(0xF0)。(そのOptionは既に割り当てられました)。 [RFC3359]を見てください。
Katz, et al. Standards Track [Page 8] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[8ページ]-、2008年10月
5. Security Considerations
5. セキュリティ問題
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].
このドキュメントがどんな新しい安全保障問題も提起しない、- -、セキュリティが安全にするのにおいて使用されているかもしれない、-、ここで議論したメッセージ。 [RFC5304]を見てください。
6. Changes from RFC 3373
6. RFC3373からの変化
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.
このドキュメントはInformationalからStandards Trackまでそれを進める意図を伴う[RFC3373]の小さい方の編集です。 また、それは、現在の「2002」バージョンを示すためにISP10589参照をアップデートします。
7. Acknowledgements
7. 承認
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、レス・ギンズバーグ、およびフィリップクリスチャンをありがとうございます。
8. Normative References
8. 引用規格
[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.
[イシス]ISO、「Intermediate Systemイントラドメインrouteing情報交換への中間的Systemは使用のためにコネクションレスなモードネットワーク・サービス(ISO8473)を提供するためのプロトコルに関連して議定書を作ります」、国際規格。10589:2002 Second Edition、2002。
[NetLink] "Netware Link Services Protocol Specification, Version
1.0", Novell, Inc., February 1994.
[NetLink] 「ネットウェアリンクサービスは1994年2月に仕様、バージョン1インチ、ノベルInc.について議定書の中で述べます」。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
9. Informative References
9. 有益な参照
[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、「中間システムへの中間システムのための3方向ハンドシェイク、(-、)、ポイントへの隣接番組を指してください、」、RFC3373(2002年9月)
[RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV)
Codepoints in Intermediate System to Intermediate System",
RFC 3359, August 2002.
[RFC3359]Przygienda、2002年8月のT.、「控え目なタイプ、中間システムへの中間システムの長さと値(TLV)のCodepoints」RFC3359。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5304] 李、T.、およびR.アトキンソン、「-、暗号の認証、」、RFC5304、10月2008日
Katz, et al. Standards Track [Page 9] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[9ページ]-、2008年10月
Authors' Addresses
作者のアドレス
Dave Katz Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
デーヴキャッツJuniperは1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
Phone: +1-408-745-2073 EMail: dkatz@juniper.net
以下に電話をしてください。 +1-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
Donald E. Eastlake 3rd Eastlake Enterprises 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3イーストレークエンタープライズ155ビーバー通りMA01757ミルフォード(米国)
Phone: +1-508-634-2066 EMail: d3e3e3@gmail.com
以下に電話をしてください。 +1-508-634-2066 メールしてください: d3e3e3@gmail.com
Katz, et al. Standards Track [Page 10] RFC 5303 Three-Way Handshake for IS-IS October 2008
キャッツ、他 規格がRFC5303 3方向ハンドシェイクを追跡する、[10ページ]-、2008年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Katz, et al. Standards Track [Page 11]
キャッツ、他 標準化過程[11ページ]
一覧
スポンサーリンク
