RFC1195 日本語訳
1195 Use of OSI IS-IS for routing in TCP/IP and dual environments.R.W. Callon. December 1990. (Format: TXT=187866, PS=362052 bytes) (Updated by RFC1349, RFC5302, RFC5304) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Working Group R. Callon
Request for Comments: 1195 Digital Equipment Corporation
December 1990
ワーキンググループR.Callonがコメントのために要求する働きをネットワークでつないでください: 1195 DEC1990年12月
Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
OSIの使用、-、TCP/IPにおけるルート設定と二元的な環境
Status of this Memo
このMemoの状態
This RFC specifies a protocol on the IAB Standards Track for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB Standards Trackでインターネットコミュニティにプロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
This RFC is available in both postscript and text versions. Where possible, use of the postscript version is recommended. For example, this text version may have figures which are less informative or missing.
このRFCは追伸とテキストバージョンの両方で利用可能です。 可能であるところでは、追伸バージョンの使用がお勧めです。 例えば、このテキストバージョンには、それほど有益でないか、または行方不明であることの数字があるかもしれません。
Abstract
要約
This RFC specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force.
このRFCは統合ルーティング・プロトコルを指定します、ベースである、OSI Intra-ドメイン、-、ルート設定プロトコル、OSIと同様にTCP/IPをサポートするのに内部のゲートウェイプロトコル(IGP)として使用されるかもしれない。 これは、ただ一つのルーティング・プロトコルが純粋なIP環境、純粋なOSI環境、および二元的な環境をサポートするのに使用されるのを許容します。 この仕様が開発された、-、インターネット・エンジニアリング・タスク・フォースのワーキンググループ。
The OSI IS-IS protocol has reached a mature state, and is ready for implementation and operational use. The most recent version of the OSI IS-IS protocol is contained in ISO DP 10589 [1]. The proposed standard for using IS-IS for support of TCP/IP will therefore make use of this version (with a minor bug correction, as discussed in Annex B). We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when available.
OSI IS存在、プロトコル、熟している状態に達して、実装と操作上の使用の準備ができています。 最新のバージョン、OSI IS存在、プロトコルはISO DP10589[1]に含まれています。 使用の提案された標準、-、したがって、TCP/IPのサポートには、このバージョンの造の使用を望んでください(小さい方のバグ修正Annex Bで議論するように)。 私たちが、その未来にこの提案された標準のバージョンが最終的な国際規格バージョンにアップグレードすると予想する、-、利用可能であるときに。
Comments should be sent to "isis@merit.edu".
" isis@merit.edu "にコメントを送るべきです。
Contents
コンテンツ
1 Introduction: Overview of the Protocol
1.1 What the Integrated IS-IS offers
1.2 Overview of the ISO IS-IS Protocol
1.3 Overview of the Integrated IS-IS
1.4 Support of Mixed Routing Domains
1つの序論: プロトコル1.1What Integratedの概要、-、1.2Overviewを提供する、ISO IS存在、Integratedのプロトコル1.3Overview、-、Mixedルート設定Domainsの1.4Support
Callon [Page 1] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[1ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
1.5 Advantages of Using Integrated IS-IS
使用の1.5の利点が統合された、-
2 Symbols and Abbreviations
2つのシンボルと略語
3 Subnetwork Independent Functions
3.1 Exchange of Routing Information
3.2 Hierarchical Abbreviation of IP Reachability Information
3.3 Addressing Routers in IS-IS Packets
3.4 External Links
3.5 Type of Service Routing
3.6 Multiple LSPs and SNPs
3.7 IP-Only Operation
3.8 Encapsulation
3.9 Authentication
3.10 Order of Preference of Routes / Dijkstra Computation
独立している機能3.1が交換する中でルータを扱うIP可到達性情報3.3の経路情報の3.2の階層的な略語の3サブネットワーク、-、外部のリンク3.5がタイプする複数のサービスルート設定3.6LSPsのパケット3.4とルート/ダイクストラComputationのSNPs3.7IPだけ操作3.8カプセル化3.9認証3.10よく使われる順
4 Subnetwork Dependent Functions
4.1 Link Demultiplexing
4.2 Multiple IP Addresses per Interface
4.3 LANs, Designated Routers, and Pseudonodes
4.4 Maintaining Router Adjacencies
4.5 Forwarding to Incompatible Routers
4 サブネットワークの依存する機能4.1は複数のIPがルータに指定されたインタフェース4.3のLAN単位で扱う逆多重化4.2とルータ隣接番組4.5推進を維持するPseudonodes4.4を両立しないルータにリンクします。
5 Structure and Encoding of PDUs
5.1 Overview of IS-IS PDUs
5.2 Overview of IP-Specific Information for IS-IS
5.3 Encoding of IP-Specific Fields in IS-IS PDUs
5がPDUs5.1概要を構造化して、コード化する、-、IP-特殊情報のPDUs5.2概要、-、5.3がコード化される、中のIP特有の分野、-、PDUs
6 Security Considerations
6 セキュリティ問題
7 Author's Address
7作者のアドレス
8 References
8つの参照箇所
A Inter-Domain Routing Protocol Information
A.1 Inter-Domain Information Type
A.2 Encoding
プロトコル情報A.1相互ドメイン情報タイプA.2コード化を発送する相互ドメイン
B Encoding of Sequence Number Packets
B.1 Level 1 Complete Sequence Numbers PDU
B.2 Level 2 Complete Sequence Numbers PDU
B.3 Level 1 Partial Sequence Numbers PDU
B.4 Level 2 Partial Sequence Numbers PDU
一連番号パケットB.1の平らな1の完全な一連番号PDU B.2の平らな2の完全な一連番号PDU B.3の平らな1の部分的な一連番号PDU B.4の平らな2の部分的な一連番号PDUのBコード化
C Dijkstra Calculation and Forwarding
C.1 SPF Algorithm for IP and Dual Use
C.2 Forwarding of IP packets
IPパケットのIPとDual Use C.2 ForwardingのためのCのダイクストラCalculationとForwarding C.1 SPF Algorithm
Callon [Page 2] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[2ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
D Use of the Authentication Field
D.1 Authentication Field in IS-IS packets
D.2 Authentication Type 1 - Simple Password
中のAuthentication Field D.1 Authentication FieldのD使用、-、パケットD.2 Authentication Type1--、簡単なPassword
E Interaction of the Integrated IS-IS with Brouters
E.1 The Problem
E.2 Possible Solutions
統合のE相互作用、-、ブルータE.1の問題のE.2の可能な解決
Figures
1 ISO Hierarchical Address Structure
2 An Example
3 Encoding of Variable Length Fields
数字1ISOの階層的なアドレスは可変長フィールドをコード化する例3あたり2を構造化します。
1 Introduction: Overview of the Protocol
1つの序論: プロトコルの概要
The TCP/IP protocol suite has been growing in importance as a multi- vendor communications architecture. With the anticipated emergence of OSI, we expect coexistence of TCP/IP and OSI to continue for an extended period of time. There is a critical need for routers to support both IP traffic and OSI traffic in parallel.
TCP/IPプロトコル群はマルチベンダーコミュニケーションアーキテクチャとして重みが増しています。 OSIの予期された出現で、私たちは、TCP/IPとOSIの共存が時間の長期間の間、続くと予想します。 ルータがIPトラフィックと平行なOSIトラフィックの両方をサポートするように、決定的な必要性があります。
There are two main methods that are available for routing protocols to support dual OSI and IP routers. One method, known as "Ships in the Night", makes use of completely independent routing protocols for each of the two protocol suites. This specification presents an alternate approach, which makes use of a single integrated protocol for interior routing (i.e., for calculating routes within a routing domain) for both protocol suites.
2つのルーティング・プロトコルが二元的なOSIとIPにルータをサポートするように利用可能な主なメソッドがあります。 「夜の船」として知られている1つのメソッドがそれぞれの2つのプロトコル群に完全に独立しているルーティング・プロトコルを利用します。 この仕様は代替のアプローチを提示します。(それは、内部のルーティング(すなわち、経路ドメインの中の計算のルートへの)にただ一つの統合プロトコルを両方のプロトコル群に利用します)。
This integrated protocol design is based on the OSI Intra-domain IS- IS routing protocol [1], with IP-specific functions added. This RFC is considered a companion to the OSI IS-IS Routing spec, and will only describe the required additional features.
この統合プロトコルデザインがOSI Intra-ドメインに基づいている、存在、IP-具体的な機能が加えられているプロトコル[1]を発送しています。 このRFCが仲間であると考えられる、OSI IS存在、ルート設定仕様、必要な付加的な機能について説明するだけでしょう。
By supporting both IP and OSI traffic, this integrated protocol design supports traffic to IP hosts, OSI end systems, and dual end systems. This approach is "integrated" in the sense that the IS-IS protocol can be used to support pure-IP environments, pure-OSI environments, and dual environments. In addition, this approach allows interconnection of dual (IP and OSI) routing domains with other dual domains, with IP-only domains, and with OSI-only domains.
IPとOSIトラフィック、デザインがIPホスト、OSIエンドシステム、およびシステムこのアプローチが意味で「統合している」二元的な終わりまでトラフィックをサポートするこの統合プロトコルの両方にそれをサポートする、-、プロトコル、純粋なIP環境、純粋なOSI環境、および二元的な環境をサポートするのに使用できます。 さらに、このアプローチは他の二元的なドメイン、IPだけドメイン、およびOSIだけドメインで二元的な(IPとOSI)経路ドメインのインタコネクトを許します。
The protocol specified here is based on the work of the IETF IS-IS working group.
ここで指定されたプロトコルが仕事に基づいている、IETF IS存在、ワーキンググループ。
1.1 What the Integrated IS-IS offers
1.1、何、Integrated、-、申し出
The integrated IS-IS provides a single routing protocol which will
統合、-、ただ一つのそうするルーティング・プロトコルを提供します。
Callon [Page 3] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[3ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
simultaneously provide an efficient routing protocol for TCP/IP, and for OSI. This design makes use of the OSI IS-IS routing protocol, augmented with IP-specific information. This design provides explicit support for IP subnetting, variable subnet masks, TOS-based routing, and external routing. There is provision for authentication information, including the use of passwords or other mechanisms. The precise form of authentication mechanisms (other than passwords) is outside of the scope of this document.
同時に、効率的なルーティング・プロトコルをTCP/IP、およびOSIに供給してください。 このデザインが利用する、OSI IS存在、ルーティング・プロトコル、IP-特殊情報で、増大しています。 このデザインはIPサブネッティングの明白なサポート、可変サブネットマスク、TOSベースのルーティング、および外部のルーティングを提供します。 認証情報への支給があります、パスワードか他のメカニズムの使用を含んでいて。正確なフォームの認証機構(パスワードを除いた)がこのドキュメントの範囲の外にあります。
Both OSI and IP packets are forwarded "as is" -- i.e., they are transmitted directly over the underlying link layer services without the need for mutual encapsulation. The integrated IS-IS is a dynamic routing protocol, based on the SPF (Dijkstra) routing algorithm.
「そのままで」OSIとIPパケットの両方を進めます--すなわち、それらは互いのカプセル化の必要性なしで基本的なリンクレイヤサービスの直接上に伝えられます。 統合、-、SPFに基づいたダイナミックルーティングプロトコル(ダイクストラ)はルーティング・アルゴリズムですか?
The protocol described in this specification allows for mixing of IP-only, OSI-only, and dual (IP and OSI) routers, as defined below.
この仕様で説明されたプロトコルは、IPだけ、OSIだけ、および二元的な(IPとOSI)ルータを混入すると考慮します、以下で定義されるように。
An IP-only IS-IS router (or "IP-only" router) is defined to be a router which: (i) Uses IS-IS as the routing protocol for IP, as specified in this report; and (ii) Does not otherwise support OSI protocols. For example, such routers would not be able to forward OSI CLNP packets.
IPだけ、-、ルータ(または、「IP唯一」のルータ)がルータになるように定義される、どれ、: (i) 用途、-、ルーティングとして、IPには、このレポートで指定されるように、議定書を作ってください。 そして、そうでなければ、(ii)はOSIにプロトコルをサポートしません。 例えば、そのようなルータはパケットをOSI CLNPに送ることができないでしょう。
An OSI-only router is defined to be a router which uses IS-IS as the routing protocol for OSI, as specified in [1]. Generally, OSI-only routers may be expected to conform to OSI standards, and may be implemented independent of this specification.
OSIだけルータがルータがどの用途であったかなら定義される、-、ルーティングとして、OSIのために議定書を作ってください、[1]で指定されるように。 一般に、OSIだけルータは、OSI規格に従うと予想されて、この仕様の如何にかかわらず実装されるかもしれません。
A dual IS-IS router (or "dual" router) is defined to be a router which uses IS-IS as a single integrated routing protocol for both IP and OSI, as specified in this report.
A二元的である、-、ルータ(または、「二元的な」ルータ)がルータがどの用途であったかなら定義される、-、シングルがルーティングを統合したように、このレポートのIPと指定されるとしてのOSIの両方のために議定書を作ってください。
This approach does not change the way that IP packets are handled. IP-only and dual routers are required to conform to the requirements of Internet Gateways [4]. The integrated IS-IS protocol described in this report outlines an Interior Gateway Protocol (IGP) which will provide routing within a TCP/IP routing domain (i.e., autonomous system). Other aspects of router functionality (e.g., operation of ICMP, ARP, EGP, etc.) are not affected by this proposal.
このアプローチはIPパケットが扱われる方法を変えません。 IPだけと二元的なルータが、インターネットGateways[4]の要件に従うのに必要です。 統合、-、このレポートで説明されたプロトコルはTCP/IP経路ドメイン(すなわち、自律システム)の中でルーティングを提供するInteriorゲートウェイプロトコル(IGP)について概説します。 ルータの機能性(例えば、ICMP、ARP、EGPなどの操作)の他の局面はこの提案で影響を受けません。
Similarly, this approach does not change the way that OSI packets are handled. There will be no change at all to the contents nor to the handling of ISO 8473 Data packets and Error Reports, nor to ISO 9542 Redirects and ES Hellos. ISO 9542 IS Hellos transmitted on LANs are similarly unchanged. ISO 9542 IS Hellos transmitted on point-to-point links are unchanged except for the addition of IP-related information. Similarly, other OSI packets (specifically those involved in the IS-IS intra-domain routing protocol) remain unchanged
同様に、このアプローチはOSIパケットが扱われる方法を変えません。 変化が全くコンテンツと、そして、ISO8473DataパケットとError Reportsの取り扱いと、そして、ISO9542RedirectsへのすべてとESハローズにないでしょう。 ISO9542はLANで伝えられたハローズが同様に変わりがないということです。 ISO9542はIP関連の情報の追加を除いて、ポイントツーポイント接続の上で伝えられたハローズが変わりがないということです。 同様である、他のOSIパケット、(明確にものが中でかかわった、-、変わりがない状態でプロトコル) 残りを発送するイントラドメイン
Callon [Page 4] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[4ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
except for the addition of IP-related information.
IP関連の情報の追加を除いて。
This approach makes use of the existing IS-IS packets, with IP- specific fields added. Specifically: (i) authentication information may be added to all IS-IS packets; (ii) the protocols supported by each router, as well as each router's IP addresses, are specified in ISO 9542 IS Hello, IS-IS Hello and Link State Packets; (iii) internally reachable IP addresses are specified in all Link State Packets; and (iv) externally reachable IP addresses, and external routing protocol information, may be specified in level 2 Link State Packets. The detailed encoding and interpretation of this in formation is specified in sections 3, 4, and 5 of this RFC.
このアプローチが利用する、存在、-、パケット、IPの特定の分野で、加えられます。 明確に: (i) 認証情報がすべてに加えられるかもしれない、-、パケット。 (ii) 各ルータによってサポートされたプロトコル、および各ルータのIPアドレスがISO9542で指定されているのが、Helloであるということである、-、HelloとLink州Packets。 (iii) 内部的に届いているIPアドレスはすべてのLink州Packetsで指定されます。 そして、(iv)外部的に届いているIPアドレス、および外部のルーティングプロトコル情報はレベル2Link州Packetsで指定されるかもしれません。 構成におけるこの詳細なコード化と解釈はこのRFCのセクション3、4、および5で指定されます。
The protocol described in this report may be used to provide routing
in an IP-only routing domain, in which all routers are IP-only.
Similarly, this protocol may be used to provide routing in a pure
dual domain, in which all routers are dual. Finally, this protocol
may be used to provide routing in a mixed domain, in which some
routers are IP-only, some routers are OSI-only, and some routers are
dual. The specific topological restrictions which apply in this
latter case are described in detail in section 1.4 ("Support of Mixed
Routing Domains"). The use of IS-IS for support of pure OSI domains
is specified in [1].
このレポートで説明されたプロトコルは、IPだけ経路ドメインにルーティングを提供するのに使用されるかもしれません。(そこでは、すべてのルータがIP専用です)。 同様に、このプロトコルは、すべてのルータがどれであるかで二元的な純粋な二元的なドメインにルーティングを提供するのに使用されるかもしれません。 最終的に、このプロトコルは複雑なドメインにルーティングを提供するのに使用されるかもしれません、そして、いくつかのルータがOSI専用です、そして、いくつかのルータはOSIです。そこでは、いくつかのルータがIP専用です。二元的。 セクション1.4(「Mixed経路ドメインのサポート」)でこの後者の場合で適用される特定の位相的な制限は詳細に説明されます。 使用、-、純粋なOSIドメインのサポートが[1]で指定されるので。
This protocol specification does not constrain which network management protocol(s) may be used to manage IS-IS-based routers. Management information bases (MIBs) for managing IP-only, OSI-only, and dual routers, compatible with CMIP, CMOT, and/or SNMP, are the subject of a separate, companion document [8].
仕様が抑制しないそれのネットワークマネージメントが(s)について議定書の中で述べるこのプロトコルが管理するのに使用されるかもしれない、存在ベースである、ルータ。 IPだけ、OSIだけ、および二元的なルータを経営するための管理情報ベース(MIBs)、CMIPと互換性があります、CMOT、そして/または、SNMPは別々の仲間ドキュメント[8]の対象です。
1.2 Overview of the ISO IS-IS Protocol
ISOの1.2概要、-、プロトコル
The IS-IS Routing Protocol has been developed in ISO to provide routing for pure OSI environments. In particular, IS-IS is designed to work in conjunction with ISO 8473 (The ISO Connectionless Network Layer Protocol [2]), and ISO 9542 (The ISO End System to Intermediate System Protocol [3]). This section briefly describes the manner in which IS-IS is used to support pure OSI environments. Enhancements for support of IP and dual environments are specified elsewhere in this report.
-、ルート設定プロトコル、ISOでは、純粋なOSI環境にルーティングを提供するために、開発されました。 特に、-、ISO8473に関連して働くように設計されている、(ISO Connectionless Network Layerプロトコル[2])、およびISO、9542 (Intermediate Systemプロトコル[3])へのISO End System。 このセクションが簡潔に方法を説明する、どれ、-、純粋なOSI環境をサポートするために、使用されるか。 IPのサポートのための増進と二元的な環境はこのレポートのほかの場所で指定されます。
In IS-IS, the network is partitioned into "routing domains". The boundaries of routing domains are defined by network management, by setting some links to be "exterior links". If a link is marked as "exterior", no IS-IS routing messages are sent on that link.
中、-、ネットワークは「経路ドメイン」に仕切られます。 ネットワークマネージメント、いくつかのリンクに「外のリンク」であるように設定することによって、経路ドメインの境界は定義されます。 リンクが「外であること」が示されるなら-、ルーティング・メッセージ、そのリンクに送ります。
Currently, ISO does not have a standard for inter-domain routing (i.e., for routing between separate autonomous routing domains).
現在、ISOには、相互ドメインルーティング(すなわち、別々の自治の経路ドメインの間のルーティングのための)の規格がありません。
Callon [Page 5] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[5ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Instead, manual configuration is used. The link is statically configured with the set of address prefixes reachable via that link, and with the method by which they can be reached (such as the DTE address to be dialed to reach that address, or the fact that the DTE address should be extracted from the IDP portion of the ISO address).
代わりに、手動の構成は使用されています。 そのリンクを通して届いているアドレス接頭語のセット、およびそれらに達することができるメソッド(そのアドレスに達するようにダイヤルされるべきDTEアドレス、またはDTEアドレスがISOアドレスのIDP部分から抜粋されるべきであるという事実などの)によってリンクは静的に構成されます。
OSI IS-IS routing makes use of two-level hierarchical routing. A routing domain is partitioned into areas. Level 1 routers know the topology in their area, including all routers and end systems in their area. However, level 1 routers do not know the identity of routers or destinations outside of their area. Level 1 routers forward all traffic for destinations outside of their area to a level 2 router in their area. Similarly, level 2 routers know the level 2 topology, and know which addresses are reachable via each level 2 router. However, level 2 routers do not need to know the topology within any level 1 area, except to the extent that a level 2 router may also be a level 1 router within a single area. Only level 2 routers can exchange data packets or routing information directly with external routers located outside of the routing domains.
OSI IS存在、ルーティングは2レベルの階層型ルーティングを利用します。 経路ドメインは領域に仕切られます。 レベル1 ルータはそれらの領域にすべてのルータとエンドシステムを含むそれらの領域でトポロジーを知っています。 しかしながら、レベル1 ルータはそれらの領域の外でルータか目的地のアイデンティティを知りません。 レベル1 ルータはそれらの領域の平らな2ルータへのそれらの領域の外ですべてのトラフィックを目的地に送ります。 同様に、レベル2 ルータは、レベル2トポロジーを知っていて、どのアドレスにそれぞれの平らな2ルータで届いているかを知っています。 しかしながら、レベル2 ルータは平らなどんな1つの領域の中でもトポロジーを知る必要はありません、また、平らな2ルータがただ一つの領域の中の平らな1つのルータであるかもしれないという範囲を除いて。 唯一のレベル2 ルータは直接経路ドメインの外に位置した外部のルータとデータ・パケットかルーティング情報を交換できます。
+----------------------+-------------------------------+
| IDP | DSP |
+----------------------+-------------------------------+
. . .
. . .
. . .
+-----+----------------+----------+--------------+-----+
| AFI | IDI | HO-DSP | ID | SEL |
+-----+----------------+----------+--------------+-----+
+----------------------+-------------------------------+ | IDP| DSP| +----------------------+-------------------------------+ . . . . . . . . . +-----+----------------+----------+--------------+-----+ | AFI| イディ| おーい、-、DSP| ID| SEL| +-----+----------------+----------+--------------+-----+
Figure 1 - ISO Hierarchical Address Structure
図1--ISOの階層的なアドレス構造
As illustrated in figure 1, ISO addresses are subdivided into the Initial Domain Part (IDP), and the Domain Specific Part (DSP). The IDP is the part which is standardized by ISO, and specifies the format and authority responsible for assigning the rest of the address. The DSP is assigned by whatever addressing authority is specified by the IDP. The DSP is further subdivided into a "High Order Part of DSP" (HO-DSP), a system identifier (ID), and an NSAP selector (SEL). The HO-DSP may use any format desired by the authority which is identified by the IDP. Together, the combination of [IDP, HO-DSP] identify both the routing domain and the area within the routing domain. The combination of [IDP,HO-DSP] may therefore be referred to as the "Area Address".
1図で例証されるように、ISOアドレスはInitial Domain Part(IDP)、およびDomain Specific Part(DSP)に細分されます。 IDPはISOによって標準化されて、アドレスの残りを割り当てるのに原因となる形式と権威を指定する部分です。 DSPはIDPによって指定されるどんなアドレシング権威によっても割り当てられます。 DSPはさらに「DSPの高位部分」(HO-DSP)、システム識別子(ID)、およびNSAPセレクタ(SEL)に細分されます。 HO-DSPはIDPによって特定される権威によって望まれていたどんな形式も使用するかもしれません。 一緒にいる、組み合わせ、[IDP、HO-DSP]は経路ドメインの中で経路ドメインと領域の両方を特定します。 [IDP、HO-DSP]の組み合わせは呼ぶかもしれません、したがって、「領域アドレス」と呼ばれてください。
Usually, all nodes in an area have the same area address. However, sometimes an area might have multiple addresses. Motivations for
通常、領域のすべてのノードには、同じ領域アドレスがあります。 しかしながら、領域には、時々、複数のアドレスがあるかもしれません。 動機
Callon [Page 6] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[6ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
allowing this are:
許容:
- It might be desirable to change the address of an area. The most
graceful way of changing an area from having address A to having
address B is to first allow it to have both addresses A and B, and
then after all nodes in the area have been modified to recognize
both addresses, then one by one the nodes can be modified to
"forget" address A.
- 領域のアドレスを変えるのは望ましいかもしれません。 アドレスBを持っていることによって領域を変える最も優雅な方法が最初にそれにはアドレスAとBの両方があるのを許容することであり、そして、その領域のすべてのノードが両方のアドレスを認識するように変更された後に次に、ひとつずつ、アドレスAを「忘れる」ようにノードは変更できます。
- It might be desirable to merge areas A and B into one area. The
method for accomplishing this is to, one by one, add knowledge of
address B into the A partition, and similarly add knowledge of
address A into the B partition.
- 領域AとBを1つの領域に合併するのは望ましいかもしれません。 これを達成するための方法は、アドレスBに関する知識をAパーティションにひとつずつ加えて、同様にアドレスAに関する知識をBパーティションに加えることです。
- It might be desirable to partition an area C into two areas, A
and B (where "A" might equal "C", in which case this example
becomes one of removing a portion of an area). This would be
accomplished by first introducing knowledge of address A into
the appropriate nodes (those destined to become area A), and
knowledge of address B into the appropriate nodes, and then one
by one removing knowledge of address C.
- AとB、領域Cを2つの領域に仕切るのは望ましいかもしれません(「A」は「C」と等しいかもしれなくその場合そこでこの例は領域の部分を取り除く1つになります)。 これは、適切なノード(領域Aになるように運命づけられたもの)へのアドレスA、およびアドレスBに関する知識について最初に知識を紹介することによって適切なノードに達成されて、次に、アドレスCに関する知識をひとつずつ取り除いているでしょう。
Since OSI addressing explicitly identifies the area, it is very easy for level 1 routers to identify packets going to destinations outside of their area, which need to be forwarded to level 2 routers.
OSIアドレシングが明らかに領域を特定するので、レベル1 ルータがそれらの領域の外に目的地に行くパケットを特定するのは、非常に簡単です。(パケットはレベル2 ルータに送られる必要があります)。
In IS-IS, there are two types of routers:
中、-、2つのタイプのルータがあります:
- Level 1 intermediate systems -- these nodes route based on the ID
portion of the ISO address. They route within an area. They
recognize, based on the destination address in a packet, whether
the destination is within the area. If so, they route towards
the destination. If not, they route to the nearest level 2 router.
- レベル1 中間システム--ルートがISOアドレスのID部分に基礎づけたこれらのノード。 彼らは領域を中に発送します。 彼らは目的地に基づいて領域の中に目的地があるか否かに関係なく、パケットでアドレスを認識します。 そうだとすれば、彼らは目的地に向かって発送します。 そうでなければ、彼らは2ルータを最も近いレベルに発送します。
- Level 2 intermediate systems -- these nodes route based on the area
address (i.e., on the combination of [IDP, HO-DSP]). They route
towards areas, without regard to the internal structure of an area.
A level 2 IS may also be a level 1 IS in one area.
- レベル2 中間システム--これらのノードは領域に基づいてアドレス(すなわち、[IDP、HO-DSP]の組み合わせでの)を発送します。 彼らは領域の内部の構造への尊敬なしで領域に向かって発送します。 A級試験2はまた、レベル1が1つの領域にあるということであるかもしれないということです。
A level 1 router will have the area portion of its address manually configured. It will refuse to become a neighbor with a node whose area addresses do not overlap its area addresses. However, if level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then the level 1 router will accept the other node as a neighbor.
A級試験1ルータで、手動でアドレスの領域の部分を構成するでしょう。 それは、領域アドレスが領域アドレスを重ね合わせないノードがある隣人になるのを拒否するでしょう。 しかしながら、レベル1 ルータには領域アドレスA、B、およびCがあって、隣人が領域アドレスBとDを持っていると、平らな1つのルータが隣人としてもう片方のノードを認めるでしょう。
A level 2 router will accept another level 2 router as a neighbor, regardless of area address. However, if the area addresses do not
A級試験2ルータは領域アドレスにかかわらず隣人として別の平らな2ルータを認めるでしょう。 しかしながら、領域であるなら、アドレスはそうしません。
Callon [Page 7] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[7ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
overlap, the link would be considered by both routers to be "level 2 only", and only level 2 LSPs would flow on the link. External links (to other routing domains) must be from level 2 routers.
リンクは両方のルータによって「レベル2専用」であると考えられるでしょう、そして、重なってください、そして、レベル2だけLSPsはリンクの上に流れるでしょう。 外部のリンク(他の経路ドメインへの)はレベル2 ルータから来ているに違いありません。
IS-IS provides an optional partition repair function. In the unlikely case that a level 1 area become partitioned, this function, if implemented, allows the partition to be repaired via use of level 2 routes.
-、任意のパーティション修理機能を提供します。 仕切られて、平らな1つの領域がなるありそうもない場合では、実行されるなら、この機能は、パーティションがレベル2 ルートの使用で修理されるのを許容します。
IS-IS requires that the set of level 2 routers be connected. Should the level 2 backbone become partitioned, there is no provision for use of level 1 links to repair a level 2 partition.
-、レベル2 ルータのセットが接続されるのが必要です。 平らな2背骨が仕切られるようになるなら、レベル1 レベル2が仕切る修理へのリンクの使用への支給が全くありません。
In unusual cases, a single level 2 router may lose connectivity to the level 2 backbone. In this case the level 2 router will indicate in its level 1 LSPs that it is not "attached", thereby allowing level 1 routers in the area to route traffic for outside of the domain to a different level 2 router. Level 1 routers therefore route traffic to destinations outside of their area only to level 2 routers which indicate in their level 1 LSPs that they are "attached".
珍しい場合では、ただ一つの平らな2ルータは平らな2背骨に接続性を失うかもしれません。 この場合、平らな2ルータは、平らな1LSPsでそれが「付属していないこと」を示すでしょう、その結果、レベル1 その領域のルータが異なった平らな2ルータにドメインの外部のための交通を発送するのを許容します。 レベル1 したがって、ルータはそれらの領域の外で交通を目的地に発送しますが、それらのレベルで「付けている」1LSPsを示す2つのルータを平らにします。
An end system may autoconfigure the area portion of its address by extracting the area portion of a neighboring router's address. If this is the case, then an endnode will always accept a router as a neighbor. Since the standard does not specify that the end system MUST autoconfigure its area address, an end system may be configured with an area address. In this case the end system would ignore router neighbors with non-matching area addresses.
エンドシステムは、隣接しているルータのアドレスの領域の部分を抽出することによって、アドレスの領域の部分を自動構成するかもしれません。 これがそうであるなら、endnodeは隣人としていつもルータを認めるでしょう。 規格が、エンドシステムが領域アドレスを自動構成しなければならないと指定しないので、エンドシステムは領域アドレスによって構成されるかもしれません。 この場合、エンドシステムは非合っている領域アドレスをもっているルータ隣人を無視するでしょう。
Special treatment is necessary for broadcast subnetworks, such as LANs. This solves two sets of issues: (i) In the absence of special treatment, each router on the subnetwork would announce a link to every other router on the subnetwork, resulting in n-squared links reported; (ii) Again, in the absence of special treatment, each router on the LAN would report the same identical list of end systems on the LAN, resulting in substantial duplication.
特別な処理がLANなどの放送サブネットワークに必要です。 これは2セットの問題を解決します: (i) 特別な処理がないとき、サブネットワークの上の各ルータはサブネットワークの上で他のあらゆるルータへのリンクを発表するでしょう、とnで二乗されたリンクへの結果になるのは報告しました。 (ii) 一方、特別な処理がないときLANに関する各ルータはLANに関してエンドシステムの同じ同じリストを報告するでしょう、かなりの複製をもたらして。
These problems are avoided by use of a "pseudonode", which represents the LAN. Each router on the LAN reports that it has a link to the pseudonode (rather than reporting a link to every other router on the LAN). One of the routers on the LAN is elected "designated router". The designated router then sends out an LSP on behalf of the pseudonode, reporting links to all of the routers on the LAN. This reduces the potential n-squared links to n links. In addition, only the pseudonode LSP includes the list of end systems on the LAN, thereby eliminating the potential duplication (for further information on designated routers and pseudonodes, see [1]).
これらの問題はLANを表す"pseudonode"の使用で避けられます。 LANに関する各ルータは、pseudonode(LANに関して他のあらゆるルータにリンクを報告するよりむしろ)にリンクを持っていると報告します。 LANのルータの1つは「代表ルータ」に選出されます。 代表ルータは次に、pseudonodeを代表してLSPを出します、LANに関してルータのすべてへのリンクを報告して。 これはnリンクへの潜在的nで二乗されたリンクを減少させます。 pseudonode LSPだけがLANのエンドシステムのリストを含んでいます、その結果、潜在的複製を排除します。(代表ルータとpseudonodesの詳細に関しては、[1])を見てください。
Callon [Page 8] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[8ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
The IS-IS provides for optional Quality of Service (QOS) routing, based on throughput (the default metric), delay, expense, or residual error probability. This is described in greater detail in section 3.5, and in [1].
-、スループットに基づいてService(QOS)ルーティングの任意のQualityに備える、(メートル法でデフォルトとしてください、)、遅れ、費用、または見逃し誤り確率。 これはセクション3.5、および[1]で詳細によりすばらしい説明されます。
1.3 Overview of the Integrated IS-IS
統合の1.3概観、-
The integrated IS-IS allows a single routing protocol to be used to route both IP and OSI packets. This implies that the same two-level hierarchy will be used for both IP and OSI routing. Each area will be specified to be either IP-only (only IP traffic can be routed in that particular area), OSI-only (only OSI traffic can be routed in that area), or dual (both IP and OSI traffic can be routed in the area).
統合、-、ただ一つのルーティング・プロトコルがIPとOSIパケットの両方を発送するのに使用されるのを許容します。 これは、同じ2レベルの階層構造がIPとOSIルーティングの両方に使用されるのを含意します。 各領域は、OSI唯一(その領域でOSI交通しか発送できない)の、または、二元的なIP(その特定の領域でIP交通しか発送できない)専用になるように指定されるでしょう(その領域でIPとOSI交通の両方を発送できます)。
This proposal does not allow for partial overlap of OSI and IP areas. For example, if one area is OSI-only, and an other area is IP-only, then it is not permissible to have some routers be in both areas. Similarly, a single backbone is used for the routing domain. There is no provision for independent OSI and IP backbones.
この提案はOSIとIP領域の部分的なオーバラップを考慮しません。 例えば、1つの領域がOSI専用であり、他の領域がIP専用であるなら、いくつかのルータを両方の領域にあるのは、許されていません。 同様に、ただ一つの背骨は経路ドメインに使用されます。 独立しているOSIとIP背骨への支給が全くありません。
Similarly, within an IP-only or dual area, the amount of knowledge maintained by routers about specific IP destinations will be as similar as possible as for OSI. For example, IP-capable level 1 routers will maintain the topology within the area, and will be able to route directly to IP destinations within the area. However, IP- capable level 1 routers will not maintain information about destinations outside of the area. Just as in normal OSI routing, traffic to destinations outside of the area will be forwarded to the nearest level 2 router. Since IP routes to subnets, rather than to specific end systems, IP routers will not need to keep nor distribute lists of IP host identifiers (note that routes to hosts can be announced by using a subnet mask of all ones).
同様に、IPだけか二元的な領域の中では、特定のIPの目的地に関してルータによって維持された知識量はできるだけOSIのように同様になるでしょう。 例えば、IPできるレベル1 ルータは領域の中でトポロジーを維持して、領域の中で直接IPに目的地を発送できるでしょう。 しかしながら、IPのできるレベル1ルータは領域の外で目的地の情報を保守しないでしょう。 ちょうど正常なOSIルーティングのように、領域における外の目的地への交通を最も近い平らな2ルータに送るでしょう。 特定のエンドシステムにというよりむしろサブネットへのIPルート以来、IPルータは、IPホスト識別子のリストを保って、分配する必要はないでしょう(すべてのもののサブネットマスクを使用することによってホストへのルートを発表できることに注意してください)。
The IP address structure allows networks to be partitioned into
subnets, and allows subnets to be recursively subdivided into smaller
subnets. However, it is undesireable to require any specific
relationship between IP subnet addresses and IS-IS areas. For
example, in many cases, the dual routers may be installed into
existing environments, which already have assigned IP and/or OSI
addresses. In addition, even if IP addresses are not already pre-
assigned, the address limitations of IP constrain what addresses may
be assigned. We therefore will not require any specific relationship
between IP addresses and the area structure. The IP addresses can be
assigned completely independently of the OSI addresses and IS-IS area
structure. As will be described in section 3.2 ("Hierarchical
Abbreviation of IP Reachability Information"), greater efficiency and
scaling of the routing algorithm can be achieved if there is some
correspondence between the IP address assignment structure and the
IPアドレス構造は、ネットワークがサブネットに仕切られるのを許容して、サブネットが、より小さいサブネットに再帰的に細分されるのを許容します。 そして、しかしながら、IPサブネットアドレスの間の特定の関係を必要とするのが「非-望-可能」である、-、領域。 多くの場合、例えば、二元的なルータは既存の環境にインストールされるかもしれません。(既に、環境はIP、そして/または、OSIにアドレスを割り当てました)。 さらに、IPアドレスが既にあらかじめも割り当てられないなら、IPのアドレス制限はアドレスが割り当てられるかもしれないことを抑制します。 したがって、私たちはIPアドレスと領域構造との少しの特定の関係も必要とするつもりではありません。 そして、完全にOSIアドレスの如何にかかわらずIPアドレスを割り当てることができる、-、領域構造。 そしてセクション3.2(「IP可到達性情報の階層的な略語」)で意志が説明されて、IPアドレス課題構造の間には、何らかの通信があればルーティング・アルゴリズムの、より大きい効率とスケーリングを達成できる。
Callon [Page 9] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[9ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
area structure.
領域構造。
Within an area, level 1 routers exchange link state packets which identify the IP addresses reachable by each router. Specifically, zero or more [IP address, subnet mask, metric] combinations may be included in each Link State Packet. Each level 1 router is manually configured with the [IP address, subnet mask, metric] combinations which are reachable on each interface. A level 1 router routes as follows:
領域の中では、レベル1 ルータ交換は各ルータで届いているIPアドレスを特定する州のパケットをリンクします。 明確に、ゼロか、より多くの[サブネットマスクの、そして、メートル法のIPアドレス]組み合わせがそれぞれのLink州Packetに含まれるかもしれません。 平らなそれぞれの1つのルータが各インタフェースで届いている[サブネットマスクの、そして、メートル法のIPアドレス]組み合わせによって手動で構成されます。 以下のA級試験1ルータルート:
- If a specified destination address matches an [IP address, subnet
mask, metric] reachable within the area, the packet is routed via
level 1 routing.
- 指定された送付先アドレスが合っている、[サブネットマスクの、そして、メートル法のIPアドレス] 領域の中で届きます、パケットはレベル1 ルーティングで発送されます。
- If a specified destination address does not match any [IP address,
subnet mask, metric] combination listed as reachable within the
area, the packet is routed towards the nearest level 2 router.
- 指定された送付先アドレスが領域の中で届くとして記載された少しの[サブネットマスクの、そして、メートル法のIPアドレス]組み合わせにも合っていないなら、パケットは最も近い平らな2ルータに向かって発送されます。
Flexible use of the limited IP address space is important in order to cope with the anticipated growth of IP environments. Thus an area (and by implication a routing domain) may simultaneously make use of a variety of different address masks for different subnets in the area (or domain). Generally, if a specified destination address matches more than one [IP address, subnet mask] pair, the more specific address is the one routed towards (the one with more "1" bits in the mask -- this is known as "best match" routing).
限られたIPアドレス空間のフレキシブルな使用は、IP環境の予期された成長に対処するために重要です。 したがって、領域(そして、含意による経路ドメイン)は同時に、領域(または、ドメイン)の異なったサブネットにさまざまな異なったアドレスマスクを利用するかもしれません。 指定された送付先アドレスが1[IPアドレス、サブネットマスク]組以上に合っているなら、一般に、より特定のアドレスが掘られたものである、(以上があるもの、「マスクの1インチのビット、--、これが「最も良いマッチ」ルーティングとして知られている)、」
Level 2 routers include in their level 2 LSPs a complete list of [IP address, subnet mask, metric] specifying all IP addresses reachable in their area. As described in section 3, this information may be obtained from a combination of the level 1 LSPs (obtained from level 1 routers in the same area), and/or by manual configuration. In addition, Level 2 routers may report external reachability information, corresponding to addresses which can be reached via routers in other routing domains (autonomous systems)
レベル2 ルータはそれらの平らな2LSPsに[サブネットマスクの、そして、メートル法のIPアドレス]それらの領域で届いているすべてのIPアドレスを指定する全リストを含んでいます。 セクション3で説明されるように、平らな1LSPs(レベル1 同じ領域のルータから、得る)の組み合わせ、手動の構成でこの情報を得るかもしれません。 さらに、Level2ルータは外部の可到達性情報を報告するかもしれません、他の経路ドメインのルータで達することができるアドレスに対応しています。(自律システム)
Default routes may be announced by use of a subnet mask containing all zeroes. Default routes should be used with great care, since they can result in "black holes". Default routes are permitted only at level 2 as external routes (i.e., included in the "IP External Reachability Information" field, as explained in sections 3 and 5). Default routes are not permitted at level 1.
デフォルトルートはすべてのゼロを含むサブネットマスクの使用で発表されるかもしれません。 「ブラックホール」をもたらすことができるので、デフォルトルートは細心の注意を払って使用されるべきです。 デフォルトルートは外部経路(すなわち、「IPの外部の可到達性情報」分野では、セクション3と5で説明されるように、含まれている)として単にレベル2で受入れられます。 デフォルトルートはレベル1で受入れられません。
The integrated IS-IS provides optional Type of Service (TOS) routing, through use of the QOS feature from IS-IS.
統合、-、QOSの特徴の使用によるService(TOS)ルーティングの任意のTypeを提供する、-
Callon [Page 10] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[10ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
1.4 Support of Mixed Routing Domains
1.4 Mixed経路ドメインのサポート
The integrated IS-IS proposal specifically allows for three types of routing domains:
統合、-、提案は明確に3つのタイプの経路ドメインを考慮します:
- Pure IP
- 純粋なIP
- Pure OSI
- 純粋なOSI
- Dual
- 二元的
In a pure IP routing domain, all routers must be IP-capable. IP-only routers may be freely mixed with dual routers. Some fields specifically related to OSI operation may be included by dual routers, and will be ignored by IP-only routers. Only IP traffic will be routed in an pure IP domain. Any OSI traffic may be discarded (except for the IS-IS packets necessary for operation of the routing protocol).
純粋なIP経路ドメインでは、すべてのルータがIPできなければなりません。 IPだけルータは自由に二元的なルータに混ぜられるかもしれません。 明確にOSI操作に関連するいくつかの分野が、二元的なルータによって含まれるかもしれなくて、IPだけルータによって無視されるでしょう。 IP交通だけが純粋なIPドメインで発送されるでしょう。 どんなOSI交通も捨てられるかもしれない、(-、パケット、ルーティング・プロトコルの操作に必要である、)
In a pure OSI routing domain, all routers must be OSI-capable. OSI- only routers may be freely mixed with dual routers. Some fields specifically related to IP operation may be included by dual routers, and will be ignored by OSI-only routers. Only OSI traffic will be routed in a pure OSI domain. Any IP traffic may be discarded.
純粋なOSI経路ドメインでは、すべてのルータがOSIできなければなりません。 OSI自由に二元的なルータにルータだけを混ぜてもよいです。 明確にIP操作に関連するいくつかの分野が、二元的なルータによって含まれるかもしれなくて、OSIだけルータによって無視されるでしょう。 OSI交通だけが純粋なOSIドメインで発送されるでしょう。 どんなIP交通も捨てられるかもしれません。
In a dual routing domain, IP-only, OSI-only, and dual routers may be mixed on a per-area basis. Specifically, each area may itself be defined to be pure IP, pure OSI, or dual.
二元的な経路ドメインでは、IPだけ、OSIだけ、および二元的なルータが地域制で複雑であるかもしれません。 明確に、各領域がそうするかもしれない、それ自体、純粋なOSIの、または、二元的な純粋なIPになるように、定義されてください。
In a pure IP area within a dual domain, IP-only and dual routers may be freely mixed. Only IP traffic can be routed by level 1 routing within a pure-IP area.
二元的なドメインの中の純粋なIP領域では、IPだけと二元的なルータが自由に複雑であるかもしれません。 純粋なIP領域の中で掘られるレベル1でIP交通しか発送できません。
In a pure-OSI area within a dual domain, OSI-only and dual routers may be freely mixed. Only OSI traffic can be routed by level 1 routing within a pure OSI area.
二元的なドメインの中の純粋なOSI領域では、OSIだけと二元的なルータが自由に複雑であるかもしれません。 純粋なOSI領域の中で掘られるレベル1でOSI交通しか発送できません。
In a dual area within a dual routing domain only dual routers may be used. Both IP and OSI traffic can be routed within a dual area.
二元的な経路ドメインの中の二元的な領域では、二元的なルータだけを使用してもよいです。 二元的な領域の中でIPとOSI交通の両方を発送できます。
Within a dual domain, if both IP and OSI traffic are to be routed between areas then all level 2 routers must be dual.
IPとOSI交通の両方が領域の間に発送されるつもりであるなら、二元的なドメインの中では、すべてのレベル2ルータがそうであるに違いありません。二元的。
1.5 Advantages of Using Integrated IS-IS
使用の1.5の利点が統合された、-
Use of the integrated IS-IS protocol, as a single protocol for routing both IP and OSI packets in a dual environment, has significant advantages over using separate protocols for
使用、統合、-、プロトコル、a二元的な環境でIPとOSIパケットの両方を発送するためのただ一つのプロトコルとして、別々のプロトコルを使用するより重要な利点を持っています。
Callon [Page 11] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[11ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
independently routing IP and OSI traffic.
独自に、IPとOSI交通を発送します。
An alternative approach is known as "Ships In the Night" (S.I.N.). With the S.I.N. approach, completely separate routing protocols are used for IP and for OSI. For example, OSPF [5] may be used for routing IP traffic, and IS-IS [1] may be used for routing OSI traffic. With S.I.N., the two routing protocols operate more or less independently. However, dual routers will need to implement both routing protocols, and therefore there will be some degree of competition for resources.
代替的アプローチは「夜の船」(S.I.N.)として知られています。 S.I.N.アプローチで、完全に別々のルーティング・プロトコルはIPとOSIに使用されます。 そして、例えば、OSPF[5]がルーティングIP交通に使用されるかもしれない、-、[1]はルーティングOSI交通に使用されるかもしれません。 S.I.N.で、2つのルーティング・プロトコルが多少独自に作動します。 しかしながら、二元的なルータは、両方のルーティング・プロトコルを実行する必要があるでしょう、そして、したがって、リソースの競争がいくらかのあるでしょう。
Note that S.I.N. and the integrated IS-IS approach are not really completely separate options. In particular, if the integrated IS-IS is used within a routing domain for routing of IP and OSI traffic, it is still possible to use other independent routing protocols for routing other protocol suites.
そして、そのS.I.N.に注意してください、統合、-、アプローチ、本当に完全に別々であるというわけではないオプションはそうです。 特に、統合、-、経路ドメインの中でIPとOSI交通のルーティングにおいて使用されていて、他のプロトコル群を発送するのに他の独立しているルーティング・プロトコルを使用するのはまだ可能です。
In the future, optional extensions to IS-IS may be defined for routing other common protocol suites. However, such future options are outside of the scope of this document. This section will compare integrated IS-IS and S.I.N. for routing of IP and OSI only.
将来的で、任意の拡大、-、他の一般的なプロトコル群を発送するために定義されるかもしれません。 しかしながら、そのような今後のオプションがこのドキュメントの範囲の外にあります。 このセクションが統合していた状態で比較される、-、そして、IPとOSIだけのルーティングのためのS.I.N.。
A primary advantage of the integrated IS-IS relates to the network management effort required. Since the integrated IS-IS provides a single routing protocol, within a single coordinated routing domain using a single backbone, this implies that there is less information to configure. This combined with a single coordinated MIB simplifies network management.
統合のプライマリ利点、-、必要であるネットワークマネージメント取り組みに関連します。 以来、統合、-、これがただ一つのバックボーンを使用するただ一つの連携経路ドメインの中で含意するあるただ一つのルーティング・プロトコルに構成するより少ない情報を提供します。 独身の連携MIBに結合されたこれはネットワークマネージメントを簡素化します。
Note that the operation of two routing protocols with the S.I.N. approach are not really independent, since they must share common resources. However, with the integrated IS-IS, the interactions are explicit, whereas with S.I.N., the interactions are implicit. Since the interactions are explicit, again it may be easier to manage and debug dual routers.
本当に独立者ではなく、一般的なリソースを共有しなければならなくて以来のS.I.N.アプローチによる2つのルーティング・プロトコルの操作がある注意。 しかしながら、統合、-、相互作用はS.I.N.に暗黙ですが、相互作用は明白です。 相互作用が明白であるので、一方、二元的なルータを管理して、デバッグするのは、より簡単であるかもしれません。
Another advantage of the integrated IS-IS is that, since it requires only one routing protocol, it uses fewer resources. In particular, less implementation resources are needed (since only one protocol needs to be implemented), less CPU and memory resources are used in the router (since only one protocol needs to be run), and less network resources are used (since only one set of routing packets need to be transmitted). Primarily this translates into a financial savings, since each of these three types of resources cost money. This implies that dual routers based on the integrated IS-IS should be less expensive to purchase and operate than dual routers based on S.I.N.
別の利点、統合、-、1つのルーティング・プロトコルだけを必要とするので、それは、より少ないリソースを使用します。 より少ない実装リソースが特に、必要です、そして、(1つのプロトコルだけが、実装される必要があるので)より少ないCPUとメモリリソースはルータに使用されます、そして、(1つのプロトコルだけが、実行される必要があるので)より少ないネットワーク資源が使用されています(1セットのルーティングパケットだけが、伝えられる必要があるので)。 主として、それぞれに関するこれらの3つのタイプに関するリソースが金がかかっているので、これは金融貯蓄に翻訳されます。 これが、そんなに二元的なルータを基づかせたのを含意する、オンである、統合、-、購入して、操作するために二元的なルータがI.NをS.に基礎づけたほど高価であるべきではありません。
Callon [Page 12] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[12ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Note that the operation of two routing protocols with the S.I.N. approach are not really independent, since they must share common resources. For example, if one routing protocol becomes unstable and starts to use excessive resources, the other protocol is likely to suffer. A bug in one protocol could crash the other. However, with the integrated IS-IS, the interactions are explicit and are defined into the protocol and software interactions. With S.I.N., the interactions are implicit.
本当に独立者ではなく、一般的なリソースを共有しなければならなくて以来のS.I.N.アプローチによる2つのルーティング・プロトコルの操作がある注意。 例えば、1つのルーティング・プロトコルが不安定になって、過度のリソースを使用し始めるなら、もう片方のプロトコルは苦しみそうです。 1つのプロトコルのバグはもう片方を墜落させるかもしれません。 しかしながら、統合、-、相互作用は、明白であり、プロトコルとソフトウェア相互作用と定義されます。 S.I.N.に、相互作用は暗黙です。
The use of a single integrated routing protocol similarly reduces the likely frequency of software upgrades. Specifically, if you have two different routing protocols in your router, then you have to upgrade the software any time EITHER of the protocols change. If you make use of a single integrated routing protocol, then software changes are still likely to be needed, but less frequently.
ただ一つの統合ルーティング・プロトコルの使用はソフトウェアの更新のありそうな頻度を同様に減少させます。 明確に、あなたのルータにおける2つの異なったルーティング・プロトコルがありましたら、あなたはプロトコル変化のソフトウェア時間のいずれもEITHERをアップグレードさせなければなりません。 しかし、あなたがただ一つの統合ルーティング・プロトコルを利用するなら、ソフトウェア変化はまだどんなより頻繁にも必要でありそうにはありません。
Finally, routing protocols have significant real time requirements. In IS-IS, these real time requirements have been explicitly specified. In other routing protocols, these requirements are implicit. However, in all routing protocols, there are real time guarantees which must be met in order to ensure correct operation. In general, it is difficult enough to ensure compliance with real time requirements in the implementation of a single real time system. With S.I.N., implementation of two semi-independent real-time protocols in a single device makes this more difficult.
最終的に、ルーティング・プロトコルには、重要なリアルタイムの要件があります。 中、-、これらのリアルタイムの要件は明らかに指定されました。 他のルーティング・プロトコルでは、これらの要件は暗黙です。 しかしながら、すべてのルーティング・プロトコルには、正しい操作を確実にするために迎えなければならないリアルタイムの保証があります。 一般に、それはただ一つのリアルタイムシステムの実装におけるリアルタイムの要件へのコンプライアンスを確実にすることができるくらい難しいです。 S.I.N.で、単一のデバイスの2つの準独立しているリアルタイムのプロトコルの実装で、この以上は難しくなります。
Note that both integrated IS-IS and S.I.N. allow for independence of external routes (for traffic from/to outside of the routing domain), and allow for independent assignment of OSI and TCP/IP addresses.
両方が統合されたことに注意してください、-、そして、N.が外部経路(/から経路ドメインの外部までのトラフィックのための)からの独立のために許容して、OSIとTCP/IPアドレスの独立している課題のために許容するS.I.。
2 Symbols and Abbreviations
2つのシンボルと略語
AA Administrative Authority
(a three octet field in the GOSIP version 2.0 NSAP
address format)
AA職務権限(GOSIPバージョン2.0NSAPアドレス形式の3八重奏分野)
AFI Authority and Format Identifier
(the first octet of all OSI NSAP addresses -- identifies
format of the rest of the address)
AFI権威と形式ID(すべてのOSI NSAPアドレスの最初の八重奏--、特定、アドレスの残りの形式)
CLNP Connection-Less Network Protocol
(ISO 8473, the OSI connectionless network layer protocol
-- very similar to IP)
CLNPのコネクションレスなネットワーク・プロトコル(ISO8473、IPと非常に同様のOSIコネクションレスなネットワーク層プロトコル)
DFI DSP Format Identifier
(a one octet field in the GOSIP version 2.0 NSAP address
format)
DFI DSP形式ID(GOSIPバージョン2.0NSAPアドレス形式の1つの八重奏分野)
Callon [Page 13] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[13ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
ES End System
(The OSI term for a host)
ESエンドシステム(ホストへのOSI用語)
ES-IS End System to Intermediate System Routeing Exchange
Protocol (ISO 9542 -- OSI protocol between routers
and end systems)
ES存在、中間システムRouteing交換プロトコルへのシステムを終わらせてください。(ISO9542--ルータとエンドシステムの間のOSIプロトコル)
ICD International Code Designator
(ISO standard for identifying organizations)
ICD国際規約指示子(組織を特定するISO規格)
IP Internetwork Protocol
(an Internet Standard Network Layer Protocol)
IPインターネットワークプロトコル(インターネットの標準のネットワーク層プロトコル)
IS Intermediate System
(The OSI term for a router)
中間システムです。(ルータのためのOSI用語)
IS-IS Intermediate System to Intermediate System Routeing
Exchange Protocol
(the ISO protocol for routing within a single
routing domain)
-、中間システムRouteing交換プロトコルへの中間システム(ただ一つの経路ドメインの中のルーティングのためのISOプロトコル)
IS-IS Hello An Hello packet defined by the IS-IS protocol
(a type of packet used by the IS-IS protocol)
-、Hello An Helloパケットが定義した、-、プロトコル(一種のパケットが使用した、-、プロトコル)
ISH An Hello packet defined by ISO 9542 (ES-IS protocol).
(not the same as IS-IS Hello)
ISH An HelloパケットがISO9542で定義した、(ES存在、プロトコル) (同じでない、-、Hello)
ISO International Organization for Standardization
(an international body which is authorized to write
standards of many kinds)
ISO国際標準化機構(多くの種類の規格を書くのが認可される国際機関)
LSP Link State Packet
(a type of packet used by the IS-IS protocol)
LSPリンク州のパケット(一種のパケットが使用した、-、プロトコル)
NLPID Network Layer Protocol ID
(A one-octet field identifying a network layer protocol)
NLPIDネットワーク層プロトコルID(ネットワーク層プロトコルを特定する1八重奏の分野)
NSAP Network Service Access Point
(a conceptual interface point at which the network
service is made available)
NSAPネットワークサービスアクセスポイント(ネットワーク・サービスが利用可能にされる概念的なインタフェースポイント)
SEL NSAP Selector
(the last octet of NSAP addresses, also called NSEL)
SEL NSAPセレクタ(NSAPアドレスの最後の八重奏また、NSELと呼ばれて、
OSI Open Systems Interconnection
(an international standard protocol architecture)
OSIオープン・システム・インターコネクション(世界規格プロトコルアーキテクチャ)
Callon [Page 14] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[14ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
RD Routing Domain
(the set of routers and end systems using a single
instance of a routing protocol such as IS-IS)
第経路ドメイン(ルーティング・プロトコルのただ一つのインスタンスを使用するルータとエンドシステムのセット、-、)
SNPA Subnetwork Point of Attachment
(a conceptual interface at which a subnetwork service
is provided)
SNPAサブネットワーク接着点(サブネットワークサービスが提供される概念的なインタフェース)
TCP Transmission Control Protocol
(an Internet Standard Transport Layer Protocol)
TCP通信制御プロトコル(インターネットの標準のトランスポート層プロトコル)
TCP/IP The protocol suite based on TCP, IP, and related
protocols (the Internet standard protocol
architecture)
プロトコル群がTCP、IP、および関連するプロトコルに基礎づけたTCP/IP(インターネット標準プロトコルアーキテクチャ)
3 Subnetwork Independent Functions
3 サブネットワークの独立している機能
3.1 Exchange of Routing Information
3.1 経路情報の交換
The exchange of routing information between routers makes use of the normal routing packet exchange as defined in the OSI IS-IS routing spec, with additional IP-specific information added to the IS-IS routing packets.
ルータの間のルーティング情報の交換が中で定義されるように通常のルーティングパケット交換を利用する、OSI IS存在、ルーティング仕様、加えられる追加IP-特殊情報、-、ルーティングパケット
The IS-IS protocol provides for the inclusion of variable length fields in all IS-IS packets. These fields are encoded using a "Code, Length, Value" triplet, where the code and length are encoded in one octet each, and the value has the length specified (from 0 to 254 octets). IS-IS requires that: "Any codes in a received PDU that are not recognised are ignored and passed through unchanged". This requirement applies to all routers implementing IS-IS, including OSI-only, IP-only, and dual routers. This allows IP-specific information to be encoded in a manner which OSI-only routers will ignore, and also allows OSI-specific information to be encoded in a manner which IP-only routers will ignore.
-、プロトコル、可変長フィールドの包含に中に備える、すべて、-、パケット これらの分野は「コード、長さ、値」三つ子を使用することでコード化されます、コードと長さがそれぞれ1つの八重奏でコード化されて、値で長さを指定するところで(0〜254の八重奏)。 -、以下のことが必要です。 「容認されたPDUの認識されない少しのコードも、変わりがない状態で無視されて、通り抜けます。」 この要件が実装しながらすべてのルータに適用する、-、OSIだけを含んでいるIPだけ、および二元的なルータ。 これは、IP-特殊情報がOSIだけルータが無視する方法でコード化されるのを許容して、また、OSI-特殊情報がIPだけルータが無視する方法でコード化されるのを許容します。
IP-capable (i.e., all IP-only and dual) routers need to know what network layer protocols are supported by other routers in their area. This information is made available by inclusion of a "protocols supported" field in all IS-IS Hello and Link State Packets. This field makes use of the NLPID (Network Layer Protocol Identifier), which is a one-octet value assigned by ISO to identify network level protocols. NLPID values have been assigned to ISO 8473 and to IP.
IPできる(すなわち、IP唯一の、そして、二元的な)ルータは、どんなネットワーク層プロトコルがそれらの領域で他のルータによってサポートされるかを知る必要があります。 すべてでの「サポートされたプロトコル」分野の包含でこの情報を利用可能にする、-、HelloとLink州Packets。 この分野はNLPID(ネットワークLayerプロトコルIdentifier)の使用をします。(それは、値がネットワークレベルを特定するためにISOで割り当てた1八重奏プロトコルです)。 NLPID値はISO8473と、そして、IPに配属されました。
IP-capable routers need to know the IP address of the adjacent interface of neighboring routers. This is required for sending ICMP redirects (when an IP-capable router sends an ICMP redirect to a host, it must include the IP address of the appropriate interface of
IPできるルータは、隣接しているルータの隣接しているインタフェースのIPアドレスを知る必要があります。 これがICMPが向け直す送付に必要である、(いつでは、IPできるルータはホストにとっての、再直接のICMPを送って、それは適切なインタフェースのIPアドレスを含まなければならないか。
Callon [Page 15] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[15ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
the correct next-hop router). This information is made available by inclusion of the IP interface address in the IS-IS Hello packets. Specifically, each IS-IS Hello packet contains the IP address(es) of the interface over which the Hello is transmitted. The IS-IS allows multiple IP addresses to be assigned to each physical interface.
正しい次のホップルータ) 中でIPインターフェース・アドレスの包含でこの情報を利用可能にする、-、Helloパケット 明確にそれぞれ、-、HelloパケットはHelloが伝えられるインタフェースのIPアドレス(es)を含んでいます。 -、複数のIPアドレスが各物理インターフェースに割り当てられるのを許容します。
In some cases, it will be useful for IP-capable routers to be able to determine an IP address(es) of all other routers at their level (i.e., for level 1 routers: all other routers in their area; for level 2 routers: all other level 2 routers in the routing domain). This is useful whenever an IP packet is to be sent to a router, such as for encapsulation or for transmission of network management packets. This information is made available by inclusion of IP address in LSPs. Specifically, each IS-IS LSP includes one or more IP addresses of the router which transmits the LSP. An IP-capable router is required to include at least one of its IP addresses in its LSPs, and may optionally include several or all of its IP addresses. Where a single router operates as both a level 1 and a level 2 router, it is required to include the same IP address(es) in its level 1 and level 2 LSPs.
いくつかの場合、IPできるルータがそれらのレベル(レベル2 ルータ: 他のレベル2 レベル1 ルータ: すなわち、それらの領域の他のすべてのルータ、経路ドメインのルータのための)で他のすべてのルータのIPアドレス(es)を決定できるのは、役に立ちます。 IPパケットがカプセル化やトランスミッションなどのルータに送られることになっているときはいつも、これはネットワークマネージメントパケットで役に立ちます。 LSPsでのIPアドレスの包含でこの情報を利用可能にします。 明確にそれぞれ、-、IS LSP、LSPを伝えるルータの1つ以上のIPアドレスを含んでいます。 IPできるルータは、少なくともLSPsのIPアドレスの1つを含むのが必要であり、任意にIPアドレスの数個かすべてを含むかもしれません。 ただ一つのルータがレベル1とレベルの両方として2ルータを操作するところでは、それが、レベル1とレベル2LSPsに同じIPアドレス(es)を含むのに必要です。
IP-capable routers need to know, for any given IP destination address, the correct route to that destination. Specifically, level 1 routers need to know what IP addresses are reachable from each level 1 router in their area. In addition, level 1 routers need to find level 2 routers (for traffic to IP addresses outside of their area). Level 2 routers need to know what IP addresses are reachable internally (either directly, or via level 1 routing) from other level 2 routers, and what addresses are reachable externally from other level 2 routers. All of this information is made available by inclusion of IP reachable address information in the Link State Packets.
IPできるルータは、どんな与えられた受信者IPアドレスでも正しいルートをその目的地に知る必要があります。 明確に、レベル1 ルータは、どんなIPアドレスにそれらの領域の平らなそれぞれの1つのルータから届いているかを知る必要があります。 さらに、レベル1 ルータは、レベル2 ルータを見つける必要があります(IPへのトラフィックがそれらの領域の外部を扱うので)。 レベル2 ルータは、どんなIPアドレスが他のレベル2 ルータから内部的に届いているか、そして、(直接かレベル1 ルーティングを通した)どんなアドレスに他のレベル2 ルータから外部的に届いているかを知る必要があります。 Link州PacketsでのIPの届いているアドレス情報の包含でこの情報のすべてを利用可能にします。
Internal (within the routing domain) and external (outside the domain) reachability information is announced separately in level 2 LSPs. Reachable IP addresses include a default metric, and may include multiple TOS-specific metrics. In general, for external routes, metrics may be of type "internal" (i.e., directly comparable with internal metrics) or of type "external" (i.e., not comparable with the internal metric). A route using internal metrics (i.e., either announced as "IP internal reachability information", or announced as "IP external reachability information" with an internal metric) is always preferred to a route using external metrics (i.e., announced as "IP external reachability information", with an external metric).
内部(経路ドメインの中の)の、そして、外部(ドメインの外の)の可到達性情報は別々にレベル2LSPsで発表されます。 届いているIPアドレスは、メートル法であることでデフォルトを含んでいて、複数のTOS特有の測定基準を含むかもしれません。 一般に、外部経路に、測定基準は「内部タイプ(すなわち、直接内部の測定基準に匹敵する)」か「外部タイプ(すなわち、匹敵しないメートル法である内部で)」のものであるかもしれません。 内部の測定基準(すなわち、「IPの内部の可到達性情報」として発表されるか、またはインターナルがメートル法で「IPの外部の可到達性情報」として発表される)を使用するルートは、ルートより外部の測定基準(すなわち、「IPの外部の可到達性情報」として、外部がメートル法で発表される)を使用することでいつも好まれます。
The detailed encoding of the IP-specific information included in routing packets is provided in section 5 (Structure and Encoding of
ルーティングパケットにIP-特殊情報を含む詳細なコード化をセクション5に提供する、(構造とEncoding
Callon [Page 16] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[16ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
PDUs).
PDUs)
3.2 Hierarchical Abbreviation of IP Reachability Information
3.2 IP可到達性情報の階層的な略語
Level 2 routers include in their level 2 LSPs a list of all [IP address, subnet mask, metric] combinations reachable in their area. In general, this information may be determined from the level 1 LSPs from all routers in the area. If we ignore resource constraints, then it would be permissible for a level 2 router to simply duplicate all [IP address, subnet mask, metric] entries from all level 1 routers in its area (with appropriate metric adjustment), for inclusion in its level 2 LSP. However, in order for hierarchical routing to scale to large routing domain sizes, it is highly desired to abbreviate the reachable address information.
レベル2 ルータはそれらの平らな2LSPsにそれらの領域で届いている組み合わせることのリストを含んでいます。 一般に、この情報はその領域のすべてのルータからの平らな1LSPsから決定しているかもしれません。 私たちがリソース規制を無視するなら、平らな2ルータが領域(適切なメートル法の調整を伴う)にレベル1 ルータからすべての[サブネットマスクの、そして、メートル法のIPアドレス]エントリーを単にコピーするのは、許されているでしょう、平らな2LSPでの包含のために。 コネは、階層型ルーティングのために大きい経路ドメインサイズに比例するようしかしながら、届いているアドレス情報を簡略化するのが非常に必要であるよう命令します。
This is accomplished by manual configuration of summary addresses. Each level 2 router may be configured with one or more [IP address, subnet mask, metric] entries for announcement in their level 2 LSPs.
これは概要アドレスの手動の構成によって達成されます。 それぞれの平らな2ルータはそれらの平らな2LSPsでの発表のために1つ以上[サブネットマスクの、そして、メートル法のIPアドレス]のエントリーによって構成されるかもしれません。
The set of reachable addresses obtained from level 1 LSPs is compared with the configured reachable addresses. Redundant information obtained from level 1 LSPs is not included in level 2 LSPs. Generally it is expected that the level 2 configured information will specify more inclusive addresses (corresponding to a subnet mask with fewer bits set to 1). This will therefore allow one configured address/submask pair (or a small number of such pairs) to hierarchically supercede the information corresponding to multiple entries in level 1 LSPs.
レベル1LSPsから得られた届いているアドレスのセットは構成された届いているアドレスにたとえられます。 レベル1LSPsから得られた余分な情報はレベル2LSPsに含まれていません。 一般に、レベル2が、情報が、より包括的なアドレス(1に設定されたより少ないビットがあるサブネットマスクに対応する)を指定するのを構成したと予想されます。 したがって、これで、ある構成されたアドレス/「副-マスク」組(または、そのような少ない数の組)が階層的でレベル1LSPsにおける多回入国に対応する情報をスーパー割譲できるでしょう。
The manually configured addresses are included in level 2 LSPs only if they correspond to at least one address which is reachable in the area. For manually configured level 2 addresses, the associated metric values to announce in level 2 LSPs are also manually configured. The configured addresses will supercede reachable address entries from level 1 LSPs based only on the IP address and subnet mask -- metric values are not considered when determining if a given configured address supercedes an address obtained from a level 1 LSP.
彼らが少なくとも1つのその領域で届いているアドレスに対応する場合にだけ、手動で構成されたアドレスはレベル2LSPsに含まれています。 また、手動で構成されたレベル2 アドレスにおいて、レベル2LSPsで発表する関連メートル法の数値は手動で構成されます。 構成されたアドレスはIPアドレスとサブネットマスクだけに基づくレベル1LSPsから届いているアドレスエントリーをスーパー割譲するでしょう--当然のことがアドレスがaレベル1LSPから入手したアドレスsupercedesを構成したかどうか決定するとき、メートル法の数値は考えられません。
Any address obtained from a level 1 LSP which is not superceded by the manually configured information is included in the level 2 LSPs. In this case, the metric value announced in the level 2 LSPs is calculated from the sum of the metric value announced in the corresponding level 1 LSP, plus the distance from the level 2 router to the appropriate level 1 router. Note: If this sum results in a metric value greater than 63 (the maximum value that can be reported in level 2 LSPs), then the value 63 must be used. Delay, expense, and error metrics (i.e., those TOS metrics other than the default metric) will be included only if (i) the level 2 router supports the specific
手動で構成された情報によってスーパー割譲されない平らな1LSPから得られたどんなアドレスも平らな2LSPsに含まれています。 この場合、メートル法の数値は、レベル2でLSPsが対応する平らな1LSPで発表されたメートル法の数値の合計、および平らな2ルータからの遠方から適正水準1ルータまで計算されると発表しました。 以下に注意してください。 この合計がメートル法の数値より多くの63(レベル2LSPsで報告できる最大値)をもたらすなら、値63を使用しなければなりません。 (i) 平らな2ルータが特定をサポートする場合にだけ、遅れ、費用、および誤り測定基準(すなわち、デフォルトを除いた、メートル法のそれらのTOS測定基準)は含まれるでしょう。
Callon [Page 17] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[17ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
TOS; (ii) the path from the level 2 router to the appropropriate level 1 router is made up of links which support the specific TOS; and (iii) the level 1 router which can reach the address directly also supports the specific TOS for this route, as indicated in its level 1 LSP.
TOS。 (ii) 平らな2ルータからappropropriateレベル1ルータまでの経路は特定のTOSをサポートするリンクで作られます。 そして、また、アドレスに達することができる(iii)1つの平らなルータが直接このルートに特定のTOSをサポートします、平らな1LSPにみられるように。
In general, the same [IP address, subnet mask] pair may be announced in level 1 LSPs sent by multiple level 1 routers in the same area. In this case (assuming the entry is not superceded by a manually configured entry), then only one such entry shall be included in the level 2 LSP. The metric value(s) announced in level 2 LSPs correspond to the minimum of the metric value(s) that would be calculated for each of the level 1 LSP entries.
一般に、同じ[IPアドレス、サブネットマスク]組はLSPsが同じ領域で倍数でレベル1 ルータを送ったレベル1で発表されるかもしれません。 そして、この場合(エントリーが手動で構成されたエントリーでスーパー割譲されないと仮定する)、そのようなエントリーの1つだけが平らな2LSPに含まれているものとします。 メートル法の数値は、レベル2でLSPsがそれぞれ予測される平らな1LSPエントリーのメートル法の数値の最小限に対応すると発表しました。
A level 2 router will have IP addresses which are directly reachable via its own interfaces. For purposes of inclusion of IP reachable address information in level 2 LSPs, these "directly reachable" addresses are treated exactly the same as addresses received in level 1 LSPs.
A級試験2ルータには、それ自身のインタフェースを通して直接届いているIPアドレスがあるでしょう。 レベル2LSPsでのIPの届いているアドレス情報の包含の目的のために、アドレスがレベル1LSPsで受信されたので、これらの「直接届いている」アドレスはまさに同じように扱われます。
Manually configured addresses may hierarchically supercede multiple level 1 reachable address entries. However, there may be some IP addresses which match the manually configured addresses, but which are not reachable via level 1 routing. If a level 2 router receives an IP packet whose IP address matches a manually configured address which it is including in its level 2 LSP, but which is not reachable via level 1 routing in the area, then the packet must be discarded. In this case, an error report may be returned (as specified in RFC 1009), with the reason for discard specifying destination unreachable.
手動で構成されたアドレスは階層的で複数の平らな1届いているアドレスエントリーをスーパー割譲するかもしれません。 しかしながら、いくつかの合わせていますが、レベル1 ルーティングで手動で構成されたアドレスに届いていないIPアドレスがあるかもしれません。 平らな2ルータがIPアドレスが合わせていますが、レベル1でその領域で掘りながらそれが平らな2LSPに含んでいる手動で構成されたアドレスに届いていないIPパケットを受けるなら、パケットを捨てなければなりません。 この場合、エラー・レポートは返された(RFC1009で指定されるように)指定している破棄の理由で目的地手が届かないかもしれません。
Figure 2 - An Example Routing Domain (not shown)
図2--例の経路ドメイン(目立ちません)
An example is illustrated in figure 2. Suppose that the network number for the entire routing domain is 17 (a class A network). Suppose each area is assigned a subnet number consisting of the next 8 bits. The area may be further subdivided by assigning the next eight bits to each LAN in the area, giving each a 24 bit subnet mask (counting the network and subnet fields). Finally 8 bits are left for the host field. Suppose that for a particular area (given subnet number 17.133) there are a number of IP capable level 1 routers announcing (in the special IP entry in their level 1 LSPs) subnets 17.133.5, 17.133.43, and 17.133.57.
例は例証されて、2が中で計算するということです。 全体の経路ドメインのネットワーク・ナンバーが17(クラスAネットワーク)であると仮定してください。 次の8ビットから成るサブネット番号が各領域に割り当てられると仮定してください。 領域は次のその領域の各LANあたり8ビットを割り当てることによって、さらに分筆されるかもしれません、24ビットのサブネットマスクをそれぞれに与えて(ネットワークとサブネット分野を数えて)。 最終的に8ビットはホスト分野に残されます。 特定の領域(サブネットNo.17.133を与える)には、サブネットを発表する(それらの平らな1LSPsの特別なIPエントリーで)多くのIPのできるレベル1ルータがあると仮定してください、17.133、.5、17.133、.43、および17.133、.57
Callon [Page 18] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[18ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Suppose that in this example, in order to save space in level 2 LSPs, the level 2 routers in this area are configured to announce subnet 17.133. Only this one address needs to be announced in level 2 LSPs. Thus if an IP packet comes along for an address in subnet 17.133.5, 17.133.43 or 17.133.57, then other level 2 routers, in other areas, will know to pass the traffic to this area.
レベル2のスペースがLSPs、レベル2であると保存して、この例では、この領域のルータがサブネット17.133を発表するために構成されると仮定してください。 この1つのアドレスだけが、レベル2LSPsで発表される必要があります。 その結果、IPパケットがサブネットにおけるアドレスのためにやって来るかどうか、17.133、.5、17.133 .43か他のレベル2 次に、.57、他の領域のルータがこの領域にトラフィックを向かわせるのを知っている17.133。
The inclusion of 17.133 in level 2 LSPs means that the three subnet addresses starting with 17.133 do not all have to be listed separately in level 2 LSPs.
レベル2LSPsでの17.133の包含は、17.133をきっかけにサブネットアドレスがすべて、そうしない3が別々にレベル2LSPsで記載されていなければならないことを意味します。
If any traffic comes along that is for an unreachable address such as 17.133.124.7, then level 2 routers in other areas in this particular domain will think that this area can handle this traffic, will forward traffic to level 2 routers in this area, which will have to discard this traffic.
何かトラフィックがやって来るなら、それは17.133などの手の届かないアドレスのためのものです。.124 .7 当時のレベル2 この特定のドメインの他の領域のルータは、このトラフィックを捨てなければならないこの領域の2つのルータを平らにするためにこの領域がこのトラフィックを扱うことができて、トラフィックを進めると思うでしょう。
Suppose that subnet number 17.133.125 was actually reachable via some other area, such as the lower right hand area. In this case, the level 2 router in the left area would be announcing (in its level 2 LSPs according to manually configured information) reachability to subnet 17.133. However, the level 2 router in the lower right area would be announcing (in its level 2 LSPs according to information taken from its received level 1 LSPs), reachability to subnet 17.133.125. Due to the use of best match routing, this works correctly. All traffic from other areas destined to subnet 17.133.125 would be sent to the level 2 router in the lower right area, and all other traffic to subnet 17.133 (i.e., traffic to any IP address starting with 17.133, but not starting with 17.133.125) would be sent to the level 2 router in the leftmost area.
そのサブネットが数であると仮定してください、17.133、.125、実際に右下の手の領域などのある他の領域を通って届きます。 この場合、左の領域の平らな2ルータはサブネット17.133に可到達性を発表しているでしょう(手動で構成された情報に従った平らな2LSPsで)。 しかしながら、右下の領域の平らな2ルータは発表しているでしょう(容認されたレベル1LSPsから取られた情報に従った平らな2LSPsで)、サブネットへの可到達性、17.133、.125 最も良いマッチルーティングの使用のため、これは正しく働いています。 右下の領域の平らな2ルータ、およびサブネット17.133への他のすべてのトラフィックに送るでしょう。他の領域からのすべてのトラフィックがサブネットに運命づけられた、17.133、.125、(すなわち、どんなIPへのトラフィックも17.133からの始めを扱う、始動しない、17.133、.125、)、一番左領域の平らな2ルータに送るでしょう。
3.3 Addressing Routers in IS-IS Packets
中でルータを扱う3.3、-、パケット
The IS-IS packet formats explicitly require that OSI-style addresses of routers appear in the IS-IS packets. For example, these addresses are used to determine area membership of routers. It is therefore necessary for all routers making use of the IS-IS protocol to have OSI style addresses assigned. For IP-only routers, these addresses will be used only in the operation of the IS-IS protocol, and are not used for any other purpose (such as the operation of EGP, ICMP, or other TCP/IP protocols).
-、パケット・フォーマットが明らかにルータのアドレスが現れるそのOSI-スタイルを必要とする、-、パケット 例えば、これらのアドレスは、ルータの領域会員資格を決定するのに使用されます。 したがって、それが使用をするすべてのルータに必要である、-、議定書を作って、OSIスタイルアドレスを割り当てさせてください。 IPだけルータに、これらのアドレスが操作だけに使用される、-、議定書を作って、いかなる他の目的(EGP、ICMP、または他のTCP/IPプロトコルの操作などの)にも使用されません。
For OSI-only and dual routers, assignment of NSAP addresses is straight forward, but is outside of the scope of this specification. Address assignment mechanisms are being set up by standards bodies which allow globally unique OSI NSAP addresses to be assigned. All OSI-only and dual routers may therefore make use of normal OSI addresses in the operation of the IS-IS protocol.
OSIだけと二元的なルータのために、NSAPアドレスの課題は、前方でまっすぐですが、この仕様の範囲の外にあります。 アドレス割当機構はグローバルにユニークなOSI NSAPアドレスが割り当てられるのを許容する標準化団体によってセットアップされています。 したがって、すべてのOSIだけと二元的なルータが操作における正常なOSIアドレスの使用をするかもしれない、-、議定書を作ってください。
Callon [Page 19] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[19ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
For IP-only routers, there are two ways in which NSAP addresses may be obtained for use with the IS-IS protocol.
IPだけルータのために、2つの方法がどのNSAPと共にアドレスを使用に得るかもしれないかである、-、議定書を作ってください。
1) For those environments in which OSI is being used, or in which it
is anticipated that OSI will be used in the future, it is
permissible to obtain NSAP address assignments in the normal
manner, assign normal NSAP addresses to IP-only routers, and use
these addresses in the operation of IS-IS. This approach is
recommended even for pure IP routing domains, as it will simplify
future migration from IP-only to dual operation.
1) OSIが使用されるか、またはどれについてOSIが将来使用されて、正常な方法でNSAPアドレス課題を得て、正常なNSAPアドレスをIPだけルータに割り当てて、操作にこれらのアドレスを使用するのが許されていると予期されるかでそうしているそれらの環境、- 純粋なIP経路ドメインにさえ、このアプローチはお勧めです、それがIPだけから双対演算まで将来の移行を簡素化する間。
2) In some cases, routers may have only TCP/IP addresses, and it may
be undesireable to have to go through the normal mechanisms for
assignment of NSAP addresses. Instead, an alternate mechanim is
provided below for algorithmically generating a valid OSI style
address from existing IP address and autonomous system number
assignments.
2) いくつかの場合、ルータには、TCP/IPアドレスしかないかもしれません、そして、NSAPアドレスの課題のために正常なメカニズムに直面しなければならないのは「非-望-可能」であるかもしれません。 代わりに、既存のIPアドレスと自律システム数の課題から有効なOSIがスタイルアドレスであるとalgorithmicallyに生成しながら、代替のmechanimは以下に備えられます。
Where desired, for IP-only routers, for use in IS-IS packet formats only, OSI-style addresses (compatible with the USA GOSIP version 2.0 NSAP address format [9]) may be derived as follows:
IPだけルータ、中の使用に必要であるところ、-、OSI-スタイルが扱うだけであるパケット・フォーマット、(コンパチブル、USA GOSIPバージョン2.0で、NSAPアドレス形式[9])は以下の通り引き出されるかもしれません:
AFI 1 octet value "47" (specifies ICD format)
AFI1八重奏は「47インチ」を評価します。(ICD形式を指定します)
ICD 2 octet value "00 05" (specifies Internet/Gosip)
ICD2八重奏価値、「00 5インチ」(インターネット/Gosipを指定します)
DFI 1 octet value "xx"
DFI1八重奏価値の"xx"
AA 3 octets value "xx xx xx" (specifies special
IP-only use of NSAPs)
AA3八重奏価値の"xx xx xx"(NSAPsの特別なIPだけ使用を指定します)
Reserved 2 octets must be "00 00"
予約された2つの八重奏がそうであるに違いない、「00 0インチ」
RD 2 octets contains autonomous system number
RD2八重奏は自律システム番号を含んでいます。
Area 2 octets must be assigned as described below
以下で説明されるように領域2八重奏を割り当てなければなりません。
ID 6 octets must be assigned as described below
以下で説明されるようにID6八重奏を割り当てなければなりません。
SEL 1 octet used as described below
以下で説明されるように使用されるSEL1八重奏
The AFI value of "47" and the ICD value of "00 05" specifies the Gosip Version 2.0 addressing format. The DFI number of "xx" and the AA of "xx xx xx" specify that this special NSAP address format is being used, solely for IS-IS packet formats in an IP-only environment. The reserved field must contain "00 00", as specified in GOSIP version 2.0.
AFIが評価する、「47インチとICDが評価する、「00 5インチがGosipバージョン2.0アドレス指定形式を指定する、」 "xx"のDFI番号と"xx xx xx"のAAが、この特別なNSAPアドレス形式が唯一使用されていると指定する、-、IPだけ環境におけるパケット・フォーマット。 予約された分野が含まなければならない、「00 GOSIPバージョン2.0で指定されるような0インチ
Callon [Page 20] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[20ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
The routing domain field contains the Autonomous System number. Strictly speaking, this is not necessary, since the IS-IS packets are exchanged within a single AS only. However, inclusion of the AS number in this address format will ensure correct operation in the event that routers from separate routing domains/ASs are incorrectly placed on the same link. The AS number in this context is used only for definition of unique NSAP addresses, and does not imply any coupling with exterior routing protocols.
経路ドメイン分野はAutonomous System番号を含んでいます。 厳密に言うと、これは以来必要でない、-、パケット、独身のASだけの中で交換します。 しかしながら、別々の経路ドメイン/ASsからのルータが不当に同じリンクに置かれると、このアドレス形式でのAS番号の包含は正しい操作を確実にするでしょう。 AS番号は、ユニークなNSAPアドレスの定義にだけこのような関係においては使用されて、外のルーティング・プロトコルでどんなカップリングも含意しません。
The Area field must be assigned by the authority responsible for the routing domain, such that each area in the routing domain must have a unique Area value.
経路ドメインに原因となる権威でArea分野を割り当てなければなりません、経路ドメインの各領域にはユニークなArea値がなければならないように。
The ID must be assigned by the authority responsible for the routing domain. The ID must be assigned such that every router in the routing domain has a unique value. It is recommended that one of the following methods is used:
経路ドメインに原因となる権威でIDを割り当てなければなりません。 経路ドメインのあらゆるルータにはユニークな値があるように、IDを割り当てなければなりません。 以下のメソッドの1つが使用されているのは、お勧めです:
1)use a unique IEEE 802 48 bit station ID
1) ユニークなIEEE802 48ビットのステーションIDを使用してください。
2)use the value hex "02 00" prepended to an IP address of the router.
2) 値の十六進法を使用してください。「02 0インチはルータのIPアドレスにprependedしました」。
IEEE 802 addresses, if used, must appear in IEEE canonical format.
使用されるなら、IEEE802アドレスはIEEEの正準な形式に現れなければなりません。
Since the IEEE 802 station IDs are assigned to be globally unique, use of these values clearly assures uniqueness in the area. Also, all assigned IEEE 802 station IDs have the global/local bit set to zero. Prepending the indicated pattern to the front of the IP address therefore assures that format (2) illustrated above cannot produce addresses which collide with format (1). Finally, to the extent that IP addresses are also globally unique, format (2) will produce unique IDs for routers.
IEEE802ステーションIDがグローバルに特有になるように割り当てられるので、これらの値の使用はその領域で明確にユニークさを保証します。 また、すべての割り当てられたIEEE802ステーションIDで、グローバルであるか地方のビットをゼロに設定します。 したがって、IPアドレスの前部に示されたパターンをPrependingするのは、上で例証された形式(2)が形式(1)と衝突するアドレスを製作できないことを保証します。 最終的に、また、IPアドレスもグローバルにユニークであるという範囲に、形式(2)はルータのための固有のIDを生産するでしょう。
The indicated hex value is specified in IEEE 802 canonical form [10]. In IEEE 802 addresses, the multicast bit is the least significant bit of the first byte. The global/local bit is the next least significant bit of the first byte. The indicated prefix therefore sets the global/local bit to 1, and all other bits in the first two octets to 0.
示された十六進法値はIEEE802標準形[10]で指定されます。 IEEE802アドレスでは、マルチキャストビットが最初のバイトの最下位ビットです。 グローバルであるか地方のビットは最初のバイトの次の最下位ビットです。 したがって、示された接頭語は1へのグローバルであるか地方のビット、および0への最初の2つの八重奏における他のすべてのビットを設定します。
Note that within an area, whether ISO addresses are configured into the routers through ISO address assignment, or whether the ISO-style address is generated directly from the AS number and IP address, all routers within an area must have the same high order part of address (AFI, ICD, DFI, AA, RD, and Area). This ISO-style address is used in IS-IS Hello messages and is the basis by which routers recognize whether neighbor nodes are in or out of their area.
ISOアドレスがISOアドレス課題でルータに構成されるか、またはISO-スタイルアドレスが直接AS番号とIPアドレスから作られることにかかわらず領域の中では、領域の中のすべてのルータがアドレス(AFI、ICD、DFI、AA、RD、およびArea)の同じ高位部分を持たなければならないことに注意してください。 このISO-スタイルアドレスが使用される、-、Helloメッセージ、中に隣人ノードがあるか否かに関係なく、ルータが認識するものかそれらの領域からの基礎はそうです。
Callon [Page 21] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[21ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
3.4 External Links
3.4 外部のリンク
External connectivity (i.e., communications with routers outside of the routing domain) is done only by level 2 routers. The ISO version of IS-IS allows external OSI routes to be reported as "reachable address prefixes" in level 2 LSPs. The integrated IS-IS also allows external IP reachable addresses (i.e., IP addresses reachable via inter-domain routing) to be reported in level 2 LSPs in the "IP external reachability information" field. External OSI and external IP routes are handled independently.
レベル2 ルータだけは外部の接続性(すなわち、経路ドメインの外のルータとのコミュニケーション)をします。 ISOバージョン、-、外部のOSIルートがレベル2LSPsの「届いているアドレス接頭語」として報告されるのを許容します。 統合、-、また、外部のIP届いているアドレス(すなわち、相互ドメインルーティングを通して届いているIPアドレス)が「IPの外部の可到達性情報」分野のレベル2LSPsで報告されるのを許容します。 外部のOSIと外部のIPルートは独自に扱われます。
The routes announced in IP external reachability information entries include all routes to outside of the routing domain. This includes routes learned from OSPF, EGP, RIP, or any other external protocol.
IPの外部の可到達性情報エントリーで発表されたルートは経路ドメインの外部にすべてのルートを含んでいます。 これはOSPF、EGP、RIP、またはいかなる他の外部のプロトコルからも学習されたルートを含んでいます。
External routes may make use of "internal" or "external" metrics. Internal metrics are comparable with the metrics used for internal routes. Thus in choosing between an internal route, and an external route using internal metrics, the metric values may be directly compared. In contrast, external metrics cannot be directly compared with internal metrics. Any route defined solely using internal metrics is always preferred to any route defined using external metrics. When an external route using external metrics must be used, the lowest value of the external metric is preferred regardless of the internal cost to reach the appropriate exit point.
外部経路は「内部」の、または、「外部」の測定基準を利用するかもしれません。 測定基準が内部のルートに使用されている状態で、内部の測定基準は匹敵しています。 したがって、内部のルート、および内部の測定基準を使用する外部経路を選ぶ際に、メートル法の数値は直接比較されるかもしれません。 対照的に、直接外部の測定基準を内部の測定基準にたとえることができません。 唯一内部の測定基準を使用することで定義されたどんなルートも外部の測定基準を使用することで定義されたどんなルートよりもいつも好まれます。 外部経路であるときに、外部の測定基準を使用するのを使用しなければなりません、外部の最も低い値、メートル法、内部の費用にかかわらず、適切なエキジットポイントに達するのが好ましいです。
It is useful, in the operation of external routing protocols, to provide a mechanism for border routers (i.e., routers in the same routing domain, which have the ability to route externally to other domains) to determine each other's existence, and to exchange external information (in a form understood only by the border routers themselves). This is made possible by inclusion of "inter-domain routing protocol information" fields in level 2 LSPs. The inter- domain routing protocol information field is not included in pseudonode LSPs.
それは、境界ルータ(すなわち、同じ経路ドメインの外部的に他のドメインに発送する能力を持っているルータ)が互いの存在を決定して、外部の情報(境界ルータ自体だけによって理解されていたフォームでの)を交換するためにメカニズムを提供するために外部のルーティング・プロトコルの操作で役に立ちます。 レベル2LSPsでの「相互ドメインルーティングプロトコル情報」分野の包含でこれを可能にします。 相互ドメインルーティング・プロトコル情報フィールドはpseudonode LSPsに含まれていません。
In general there may be multiple types of external inter-domain routing protocol information exchanged between border routers. The IS-IS therefore specifies that each occurance of the inter-domain routing protocol information field include a "type" field, which indicates the type of inter-domain routing protocol information enclosed. Values to be used in the type field will be specified in future versions of the "Assigned Numbers" RFC. Initial values for this field are specified in Annex A of this specification.
一般に、境界ルータの間で交換された複数のタイプの外部の相互ドメインルーティングプロトコル情報があるかもしれません。 -、したがって、相互ドメインルーティング・プロトコル情報フィールドの各occuranceが「タイプ」分野を含んでいると指定します。(分野は同封の相互ドメインルーティングプロトコル情報のタイプを示します)。 タイプ分野で使用されるべき値は「規定番号」RFCの将来のバージョンで指定されるでしょう。 この分野への初期の値はこの仕様のAnnex Aで指定されます。
Information contained in the inter-domain routing protocol information field will be carried in level 2 LSPs, and will therefore need to be stored by all level 2 routers in the domain. However, only
相互ドメインルーティング・プロトコル情報フィールドに保管されていた情報は、レベル2LSPsで運ばれて、したがって、そのドメインにレベル2 ルータによって保存される必要があるでしょう。 only
Callon [Page 22] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[22ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
those level 2 routers which are directly involved in external routing will use this information. In designing the use of this field, it is important to carefully consider the implications that this may have on storage requirements in level 2 routers (including those level 2 routers which are not directly involved in external routing).
直接外部のルーティングにかかわるそれらの平らな2つのルータがこの情報を使用するでしょう。 この分野の使用を設計するのにおいて、慎重に、これがレベル2 ルータにおけるストレージ要件に持っているかもしれない意味を考えるのは重要です(直接外部のルーティングにかかわらないそれらの平らな2つのルータを含んでいて)。
The protocols used to exchange routing information directly between border routers, and external routers (in other routing domains / autonomous systems) are outside of the scope of this specification.
プロトコルは以前は境界ルータの直接間でよくルーティング情報を交換していました、そして、外部のルータ(他の経路ドメイン/自律システムの)がこの仕様の範囲の外にあります。
3.5 Type of Service Routing
3.5 サービスルート設定のタイプ
The integrated IS-IS protocol provides IP Type of Service (TOS) routing, through use of the Quality of Service (QOS) feature of IS- IS. This allows for routing on the basis of throughput (the default metric), delay, expense, or residual error probability. Note than any particular packet may be routed on the basis of any one of these four metrics. Routing on the basis of general combinations of metrics is not supported.
統合、-、プロトコル、通じて掘るのが使用するService(QOS)の特徴のQualityのService(TOS)のIP Typeを提供する、存在、あります。 これが、スループットに基づいて掘ると考慮する、(メートル法でデフォルトとしてください、)、遅れ、費用、または見逃し誤り確率。 注意、どんな特定のパケットもこれらの4つの測定基準のどれかに基づいて発送されるかもしれないより。 測定基準の一般的な組み合わせに基づいたルート設定はサポートされません。
The support for TOS/QOS is optional. If a particular packet calls for a specific TOS, and the correct path from the source to destination is made up of routers all of which support that particular TOS, then the packet will be routed on the optimal path. However, if there is no path from the source to destination made up of routers which support that particular type of service, then the packet will be forwarded using the default metric instead. This allows for TOS service in those environments where it is needed, while still providing acceptable service in the case where an unsupported TOS is requested.
TOS/QOSのサポートは任意です。 特定のパケットが特定のTOSを求めて、正しいソースから目的地までの経路がそれのすべてがそれが特定のTOSであるとサポートするルータで作られると、パケットは最適経路で発送されるでしょう。 しかしながら、ソースからそれが特定のタイプのサービスであるとサポートするルータで作られた目的地まで経路が全くないと、代わりにデフォルトを使用するのをパケットにメートル法で送るでしょう。 これはそれがまだサポートされないTOSが要求されているケースの中に許容できるサービスを供給している間必要であるそれらの環境におけるTOSサービスを考慮します。
NOTE - IP does not have a cost TOS. There is therefore no mapping of IP TOS metrics which corresponds to the minimum cost metric.
注意--IPには、費用TOSがありません。 したがって、最低費用にメートル法で対応するIP TOS測定基準の写像がありません。
The IP TOS field is mapped onto the four available metrics as follows:
IP TOS分野は以下の4つの利用可能な測定基準に写像されます:
Bits 0-2 (Precedence): This field does not affect the route, but
rather may affect other aspects of packet
forwarding.
ビット0-2(先行): この分野は、ルートに影響しませんが、むしろパケット推進の他の局面に影響するかもしれません。
Bits 3 (Delay), 4 (Throughput) and 5 (Reliability):
ビット3(遅れ)、4(スループット)と5(信頼性):
000 (all normal) Use default metric
000(すべての標準)はメートル法でデフォルトを使用します。
100 (low delay) Use delay metric
100(低い遅れ)はメートル法で遅れを使用します。
010 (high throughput) Use default metric
010(高生産性)はメートル法でデフォルトを使用します。
Callon [Page 23] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[23ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
001 (high reliabiity) Use reliability metric
001(高いreliabiity)はメートル法で信頼性を使用します。
other Use default metric
他のUseはメートル法でデフォルトとします。
3.6 Multiple LSPs and SNPs
3.6 複数のLSPsとSNPs
In some cases, IS-IS packets (specifically Link State Packets and Complete Sequence Number Packets) may be too large to fit into one packet. The OSI IS-IS [1] allows for LSPs and CSNPs to be split into multiple packets. This is independent of ISO 8473 segmentation, and is also independent of IP fragmentation. Use of independent multiple packets has the advantages (with respect to segmentation or fragmentation) that: (i) when information in the IS-IS changes, only those packets effected need to be re-issued; (ii) when a single packet is received, it can be processed without the need to receive all other packets of the same type from the same router before beginning processing.
いくつかの場合で-、パケット(明確にLink州のPacketsとComplete Sequence Number Packets)は1つのパケットに収まることができないくらい大きいかもしれません。 OSI IS存在、[1]は、LSPsとCSNPsが複数のパケットに分割されるのを許容します。 これも、ISO8473分割から独立していて、また、IP断片化から独立しています。 独立者複数のパケットの使用には利点(分割か断片化に関する)がある、それ: (i) 中の情報である、-、変化であり、それらのパケットだけが再発行されるべき必要性を生じさせました。 (ii) 単一のパケットが受け取られているとき、処理し始める前に同じルータから同じタイプの他のすべてのパケットを受ける必要性なしでそれを処理できます。
The Integrated IS-IS makes use of the same multiple packet function,
as defined in [1]. IP-specific fields in IS-IS packets may be split
across multiple packets. As specified in section 5 ("Structure and
Encoding of PDUs"), some of the IP-specific fields (those which may
be fairly long) may be split into several occurences of the same
field, thereby allowing splitting of the fields across different
packets.
Integrated、-、[1]で定義されるように同じ複数のパケット機能を利用します。 中のIP特有の分野、-、パケットは複数のパケットの向こう側に分けられるかもしれません。 セクション5(「PDUsの構造とコード化」)で指定されるように、IP特有の分野(かなり長いかもしれないもの)のいくつかが同じ分野の数個のoccurencesに分けられるかもしれません、その結果、異なったパケットの向こう側に分野を分けるのを許容します。
Multiple LSPs from the same router are distinguished by LSP number. Generally, most variable length fields may occur in an LSP with any LSP number. Some specific variable length fields may be required to occur in LSP number 0. Except where explicitly stated otherwise, when an IS-IS router issues multiple LSPs, the IP-specific fields may occur in an LSP with any LSP number.
同じルータからの複数のLSPsがLSP番号によって区別されます。 一般に、ほとんどの可変長フィールドがLSPにどんなLSP番号でも起こるかもしれません。 いくつかの特定の可変長フィールドが、LSP No.0で起こるのに必要であるかもしれません。 別の方法で明らかに述べられたどこか、いつ、-、ルータ、複数の問題LSPs、IP特有の分野はLSPにどんなLSP番号でも起こるかもしれないか。
Complete Sequence Number Packets may be split into multiple packets, with the range to which each packet applies explicitly reported in the packet. Partial Sequence Number Packets are inherently partial, and so can easily be split into multiple packets if this is necessary. Again, where applicable, IP-specific fields may occur in any SNP.
完全なSequence Number Packetsは複数のパケットに分割されるかもしれません、各パケットがパケットで明らかに報告されていた状態で適用される範囲で。 これが必要であるなら、本来目がないので、容易に部分的なSequence Number Packetsを複数のパケットに分割されることができます。 一方、IP特有の分野はどんなSNPにも適切であるところでは、起こるかもしれません。
3.7 IP-Only Operation
3.7 IPだけ操作
For IP-only routers, the format for IS-IS packets remains unchanged. However, there are some variable length fields from the IS-IS packets that can be omitted. Specifically:
IPだけルータ、形式、-、パケットは変わりがありません。 しかしながら、いくつかの可変長フィールドがある、-、省略できるパケット。 明確に:
Callon [Page 24] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[24ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
IS-IS Hello Packets:
-、こんにちは、パケット:
- no change
- 変化がありません。
IS-IS Link State Packets:
-、州のパケットをリンクしてください:
- the "End Systems Neighbours" entries are omitted
- 「終わりのシステム隣人」エントリーは省略されます。
- the "Prefix Neighbours" entries are omitted
- 「Prefix Neighbours」エントリーは省略されます。
IS-IS Sequence Number Packets:
-、一連番号パケット:
- no change
- 変化がありません。
3.8 Encapsulation
3.8 カプセル化
Future versions of the Integated IS-IS may specify optional encapsulation mechanisms for partition repair, and for forwarding packets through incompatible routers (i.e., for forwarding OSI packets through IP-only routers, and forwarding IP packets through OSI-only routers). The details of encapsulation and decapsulation are for further study. Routers complying with the Integrated IS-IS are not required to implement encapsulation nor decapsulation.
将来のバージョン、Integated、-、パーティション修理と、両立しないルータ(すなわち、IPだけルータを通してOSIパケットを進めて、OSIだけルータを通して推進IPパケットを進めるための)を通してパケットを進めるのに任意のカプセル化メカニズムを指定するかもしれません。 さらなる研究にはカプセル化と被膜剥離術の詳細があります。 Integratedに従うルータ、-、カプセル化を実行するのが必要でない、または、被膜剥離術。
3.9 Authentication
3.9 認証
The authentication field allows each IS-IS packet to contain information used to authenticate the originator and/or contents of the packet. The authentication information contained in each packet is used to authenticate the entire packet, including OSI and IP parts. If a packet is received which contains invalid authentication information, then the entire packet is discarded. If an LSP or SNP is split into multiple packets (as described in section 3.6), then each is authenticated independently.
認証分野が許容する、それぞれ、-、パケット、情報を含むのは以前はよくパケットの創始者、そして/または、コンテンツを認証していました。 各パケットに含まれた認証情報は、OSIとIPの部品を含む全体のパケットを認証するのに使用されます。 パケットが受け取られているなら、(無効の認証情報を含んでいます)全体のパケットは捨てられます。 LSPかSNPが複数のパケットに分割されるなら(セクション3.6で説明されるように)、それぞれが独自に認証されます。
Use of the authentication field is optional. Routers are not required to be able to interpret authentication information. As with other fields in the integrated IS-IS, if a router does not implement authentication then it will ignore any authentication field that may be present in an IS-IS packet.
認証分野の使用は任意です。 ルータは、認証情報を解釈できるように必要ではありません。 中の他の分野、統合、-、ルータが認証を実行しないとそれが存在しているかもしれないどんな認証分野も無視する、-、パケット
Annex D specifies a proposed use of the authentication field.
別館Dは認証分野の提案された使用を指定します。
3.10 Order of Preference of Routes / Dijkstra Computation
3.10 ルート/ダイクストラComputationのよく使われる順
We define the term "IP reachability entry" to mean the combination of the [IP address, subnet mask]. The Dijkstra calculation must calculate routes to each distinct IP reachability entry. For the
私たちが「IP可到達性エントリー」という組み合わせを意味する用語を定義する、[IPアドレス、サブネットマスク。] ダイクストラの計算はそれぞれの異なったIP可到達性エントリーにルートを計算しなければなりません。 the
Callon [Page 25] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[25ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Dijkstra calculation, each IP reachability entry can be treated in much the same manner as an OSI end system. Naturally, each IP reachability entry is treated as distinct from any OSI end systems which may also be reachable in the same area or routing domain.
OSIエンドシステムへの似たり寄ったりの方法でダイクストラの計算、それぞれのIP可到達性エントリーを扱うことができます。 当然、それぞれのIP可到達性エントリーはどんなまた、同じ領域か経路ドメインで届くかもしれないOSIエンドシステムとも異なるとして扱われます。
For any particular IP reachability entry, this is the same as another entry if and only if: (i) the subnet masks are identical; and (ii) for each bit in the subnet mask which has the value "1", the IP address is identical. This can easily be tested by zeroing those bits in the IP address which correspond to a zero bit in the mask, and then treating the entry as a 64 bit quantity, and testing for equality between different 64 bit quantities. The actual calculation of routes to IP reachability entries is therefore no more complex than calculation of routes to OSI end systems (except for the replacement of a 48-bit test with a 64-bit test).
どんな特定のIP可到達性エントリーにも、これが別のエントリーと同じである、唯一、: (i) サブネットマスクは同じです。 そして、それぞれのための(ii)に値を持っているサブネットマスクで噛み付きました。「1インチ、IPアドレスは同じです」。 次に、IPアドレスのマスクでゼロ・ビットに対応するそれらのビットのゼロを合わせて、64ビットの量としてエントリーを扱って、64ビットの異なった量の間の平等がないかどうかテストすることによって、容易にこれをテストできます。 したがって、IP可到達性エントリーへのルートの実際の計算は複合体よりOSIエンドシステムへのルートの計算(64ビットのテストによる48ビットのテストの交換を除いて)です。
The Dijkstra computation does not take into consideration whether a router is IP-only, OSI-only, or dual. The topological restrictions specified in section 1.4 ensure that IP packets will only be sent via IP-capable routers, and OSI packets will only be sent via OSI-capable routers.
ダイクストラの計算はルータがOSI唯一の、または、二元的なIP専用であるか否かに関係なく、考慮を連れていきません。 セクション1.4で指定された位相的な制限は、IPできるルータでIPパケットを送るだけであり、OSIできるルータでOSIパケットを送るだけであるのを確実にします。
The Integrated IS-IS prefers routes within the area (via level 1 routing) whenever possible. If level 2 routes must be used, then routes within the routing domain (specifically, those routes using internal metrics) are prefered to routes outside of the routing domain (using external metrics).
Integrated、-、可能であるときはいつも、領域(レベル1 ルーティングを通した)の中でルートを好みます。 レベル2 ルートを使用しなければならないなら、経路ドメイン(明確に内部の測定基準を使用するそれらのルート)の中のルートは経路ドメインの外でルートにpreferedされます(外部の測定基準を使用して)。
The Integrated IS-IS protocol makes use of "best match" routing of IP packets. This implies that a particular destination address may match more than one entry in the forwarding database. If a particular IP packet has a destination address which matches two different IP reachability entries, then the entry who's mask contains the most "1" bits is preferred.
Integrated、-、プロトコルはIPパケットの「最も良いマッチ」ルーティングを利用します。 これは、特定の送付先アドレスが推進データベースにおける1つ以上のエントリーに合うかもしれないのを含意します。 2つの異なったIP可到達性エントリー、次にそうするエントリーに合っているa送付先アドレスが特定のIPパケットでマスクをかける、含有、「何1インチも、ビットは好まれます」最も多くの。
IP packets whose destination is a router are routed the same way as any other IP packet, by forwarding first to the appropriate subnet, and then forwarding on that subnet to the destination host (which just happens to be a router in this case). In particular, the IP forwarding database does not contain explicit routes to the individual "IP interface addresses" listed by each router in its LSP.
目的地がルータであるIPパケットはそのサブネットであて先ホスト(この場合ちょうどたまたまルータである)に最初に、適切なサブネットに転送するのによるいかなる他のIPパケットとも同じ道が発送されて、次に、推進を発送されます。 特に、IP推進データベースはLSPに各ルータによって記載された個々の「IPインターフェース・アドレス」に明白なルートを含んでいません。
However, host routes (routes with a subnet mask of all ones) may of course be included in the IP reachability entries, and will be handled in the same manner as other IP reachability entries.
しかしながら、ホストルート(すべてのもののサブネットマスクがあるルート)は、もちろんIP可到達性エントリーに含まれるかもしれなくて、他のIP可到達性エントリーと同じ方法で扱われるでしょう。
In order to ensure correct interoperation of different router implementations, it is necessary to specify the order of preference
異なったルータ実現の正しいinteroperationを確実にするために、よく使われる順を指定するのが必要です。
Callon [Page 26] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[26ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
of possible routes. For OSI destinations, this is outside of the scope of this report. For IP destinations, this is specified in section 3.10.1 and 3.10.2 below. Annex C specifies a detailed Dijkstra calculation and forwarding algorithm which is compatible with the order of preference of routes specified here.
可能なルートについて。 OSIの目的地に関しては、これはこのレポートの範囲の外にあります。 IPの目的地に関しては、これは指定されたコネセクション3.10.1であり、3.10は.2未満です。 別館Cは詳細なダイクストラの計算と推進アルゴリズムを指定します(ここで指定されるルートに関するよく使われる順と互換性があります)。
With IS-IS, if a route to a given destination is advertised, or a link between routers is advertised, then metric values associated with some or all of the specified TOS metric types may be associated with that destination or link. However, the default metric must always be available. Normally this ensures that if a route using any TOS metric is available, then a route using the default metric will also be available. The only exception to this is where the corresponding route using the default metric has a total cost (within the area, or within the level 2 backbone) greater than MaxPathMetric.
-、関連づけられた当時のメートル法の数値は、与えられた目的地へのルートの広告を出すか、またはルータの間のリンクを広告に掲載するなら指定されたTOSメートル法のタイプのいくつかかすべてにその目的地に関連しているか、またはリンクされるかもしれません。 しかしながら、デフォルトのメートル法の必須である、いつも利用可能であってください。 通常、これは、aがメートル法で使用しているいずれかTOSを発送するならそれが利用可能であることを確実にします、次に、ルートがデフォルトのメートル法の意志も使用して。利用可能であってください。 これへの唯一の例外が対応が使用を発送するところである、デフォルト、メートル法、総費用(領域、または、平らな2背骨の中の)をMaxPathMetricよりすばらしくします。
In determining the route to a particular destination for a specified TOS, only routes using either the requested TOS metric, or the default TOS metric, are considered.
aのための特定の目的地へのルートがメートル法でTOS、要求されたTOSを使用するルートだけを指定したことを決定するか、またはデフォルトTOSでメートル法である、考えられます。
3.10.1 Order of Preference of Routes In Level 1 Routing
3.10.1 レベル1 ルート設定におけるルートに関するよく使われる順
If a given destination is reachable within an area via a route using either the requested TOS or the default TOS, then the IS-IS will always make use of a path within the area (via level 1 routing), regardless of whether an alternate path exists outside of the area (via level 2 routing). In this case, routes within the area are selected as follows:
与えられた目的地が領域の中で次に要求されたTOSかデフォルトTOSのどちらかを使用するルートで届くかどうか、-、領域(レベル1 ルーティングを通した)の中でいつも経路を利用するでしょう、代替パスが領域(レベル2 ルーティングを通した)の外に存在しているかどうかにかかわらず。 この場合、領域の中のルートは以下の通り選択されます:
1) Amongst routes in the area, if the specified destination
address matches more than one [IP address, subnet mask] pair,
then the more specific address match (the one with more "1"
bits in the mask) is prefered.
1) 次に、その領域のルートの中で、より特定のアドレス一致、指定された送付先アドレスが1[IPアドレス、サブネットマスク]組以上を合わせるなら(以上があるもの、「マスクの1インチのビット)、preferedされる、」
2) Amongst routes in the area to equally specific address
matches, routes on which the requested TOS (if any) is
supported are always prefered to routes on which the
requested TOS is not supported.
2) 等しく特定のアドレス一致への領域のルートの中では、要求されたTOS(もしあれば)が支持されるルートはいつも要求されたTOSが支持されないルートにpreferedされます。
3) Amongst routes in the area of the same TOS to equally
specific address matches, the shortest routes are prefered.
For determination of the shortest path, if a route on which
the specified TOS is supported is available, then the
specified TOS metric is used, otherwise the default metric
is used. Amongst routes of equal cost, load splitting may
be performed as specified in [1].
3) 等しく特定のアドレス一致への同じTOSの領域のルートの中では、最も短いルートはpreferedされます。 最短パスの決断に、指定されたTOSが支持されるルートがaであるなら利用可能であり、その時が指定されたTOSである、メートル法、使用されている、そうでなければ、デフォルト、メートル法、使用されます。 等しい費用のルートの中では、負荷の分かれることは[1]で指定されるように実行されるかもしれません。
For a level 1 only router (i.e., a router which does not take part in
aレベル1 ルータだけ、(すなわち、参加しないルータ
Callon [Page 27] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[27ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
level 2 routing, or a level 2 router which is not "attached"), if a given destination is not reachable within an area, level 1 routing will always route to a level 2 router as follows:
レベル2 「付属していない」平らな2ルータ) ルーティング、またはルーティングがいつも以下の平らな2ルータに発送する平らな1与えられた目的地が領域の中で届かないなら:
1) Amongst routes in the area to attached level 2 routers,
routes on which the requested TOS (if any) is supported
are always prefered to routes on which the requested TOS
is not supported.
1) 付属レベル2 ルータへの領域のルートの中では、要求されたTOS(もしあれば)が支持されるルートはいつも要求されたTOSが支持されないルートにpreferedされます。
2) Amongst routes in the area of the same TOS to attached
level 2 routers, the shortest routes are prefered. For
determination of the shortest path, if a route on which
the specified TOS is supported is available, then the
specified TOS metric is used, otherwise the default
metric is used. Amongst routes of equal cost,
loadsplitting may be performed as specified in [1].
2) 付属レベル2 ルータへの同じTOSの領域のルートの中では、最も短いルートはpreferedされます。 最短パスの決断に、指定されたTOSが支持されるルートがaであるなら利用可能であり、その時が指定されたTOSである、メートル法、使用されている、そうでなければ、デフォルト、メートル法、使用されます。 等しい費用のルートの中では、loadsplittingは[1]で指定されるように実行されるかもしれません。
3.10.2 Order of Preference of Routes in Level 2 Routing
3.10.2 レベル2 ルート設定におけるルートに関するよく使われる順
For those level 2 routers which also take part in level 1 routing, routes learned via level 1 routing, using either the requested TOS or the default TOS, are always prefered to routes learned through level 2 routing. For destinations which are not reachable via level 1 routing, or for level 2 only routers (routers which do not take part in level 1 routing), then level 2 routes are selected as follows:
また、レベル1 ルーティングで参加するそれらの平らな2つのルータのために、ルートは、ルーティング、要求されたTOSを使用するか、またはデフォルトTOSがいつもレベル2 ルーティングで学習されたルートにpreferedされることをレベル1で学びました。 次に、レベル2 レベル1 ルーティングで届いていない目的地、またはルータ(レベル1 ルーティングで参加しないルータ)だけにおいて、レベル2 ルートは以下の通り選択されます:
1) Routes using internal metrics only are always preferred
to routes using external metrics.
1) 内部の測定基準だけを使用するルートは、ルートより外部の測定基準を使用することでいつも好まれます。
2) If a route using internal metrics only is available:
2) 内部の測定基準だけを使用するルートが利用可能であるなら:
a) If the specified destination address matches more
than one [IP address, subnet mask] pair, then the more
specific address match (i.e., the largest number of
"1"s present in the subnet mask) is prefered.
a) アドレス一致指定された1[IPアドレス、サブネットマスク]目的地組以上で、次に、より特定であるならマッチを記述してください、(すなわち、最多数、「サブネットマスクの現在の1"s)、preferedされる、」
b) Amongst routes with equally specific address matches
(i.e., an equal number of "1"s present in the subnet
mask), routes on which the requested TOS (if any) is
supported are always preferred to routes on which the
requested TOS is not supported.
b) 等しく特定のアドレス一致があるルート、(すなわち、等しい数、「サブネットマスクの現在の1"s)、要求されたTOS(もしあれば)が支持されるルートが要求されたTOSが支持されないルートよりいつも好まれる、」
c) Amongst routes of the same TOS with an equally specific
address matches, the shortest path is prefered. For
determination of the shortest path, if a route on which
the specified TOS is supported is available, then the
specified TOS metric is used, otherwise the default
metric is used. Amongst routes of equal cost,
c) 等しく特定のアドレスがあるTOSが合っている同じくらいのルートの中では、最短パスはpreferedされます。 最短パスの決断に、指定されたTOSが支持されるルートがaであるなら利用可能であり、その時が指定されたTOSである、メートル法、使用されている、そうでなければ、デフォルト、メートル法、使用されます。 等しい費用のルートの中で
Callon [Page 28] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[28ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
loadsplitting may be performed as specified in [1].
loadsplittingは[1]で指定されるように実行されるかもしれません。
NOTE: Internal routes (routes to destinations announced
in the "IP Internal Reachability Information" field),
and external routes using internal metrics (routes to
destinations announced in the "IP External Reachability
Information" field, with a metric of type "internal")
are treated identically for the purpose of the order of
preference of routes, and the Dijkstra calculation.
以下に注意してください。 インターナルは(「IPの内部の可到達性情報」分野で発表された目的地へのルート)を発送します、そして、内部の測定基準(目的地へのルートは「IPの外部の可到達性情報」分野で発表しました、タイプにおけるメートル法のaが「内部であること」で)を使用する外部経路はルートに関するよく使われる順の目的、およびダイクストラの計算のために同様に扱われます。
3) If a route using internal metrics only is not available,
but a route using external metrics is available:
3) 内部の測定基準だけを使用するルートが利用可能ではありませんが、外部の測定基準を使用するルートが利用可能であるなら:
a) If the specified destination address matches more than
one [IP address, subnet mask] pair, then the more
specific address match is prefered.
a) 指定された送付先アドレスが1[IPアドレス、サブネットマスク]組以上に合っているなら、より特定のアドレス一致はpreferedされます。
NOTE: For external routes, the subnet mask will normally
correspond precisely to the network number. This implies
that this test will always discover equal length matching
strings. However, this test is included to allow future
migration to more general handling of external addresses.
以下に注意してください。 外部経路のために、通常、サブネットマスクはまさにネットワーク・ナンバーに対応するでしょう。 これは、このテストが、いつも等しい長さがストリングに合っていると発見するのを含意します。 しかしながら、このテストは、外部アドレスの、より一般的な取り扱いに今後の移動を許すために含まれています。
b) Amongst routes with equally specific matches, routes on
which the requested TOS (if any) is supported are always
preferred to routes on which the requested TOS is not
supported. NOTE: for external routes, the route is
considered to support the requested TOS only if the
internal route to the appropriate border router
supports the requested TOS, and the external route
reported by the border router also supports the
requested TOS.
b) 等しく特定のマッチがあるルートの中では、要求されたTOS(もしあれば)がサポートされるルートは要求されたTOSがサポートされないルートよりいつも好まれます。 以下に注意してください。 外部経路に、適切な境界ルータへの内部のルートが要求されたTOSをサポートする場合にだけルートが要求されたTOSをサポートすると考えられて、また、境界ルータによって報告された外部経路は要求されたTOSをサポートします。
c) Amongst routes of the same TOS with an equal length
matching address string, the shortest path is prefered.
For determination of the shortest path:
c) 等しい長さの合っているアドレスストリングがある同じTOSのルートの中では、最短パスはpreferedされます。 最短パスの決断のために:
(i) Routes with a smaller announced external metric
are always prefered.
(i) より小さい発表された外部がメートル法であることでのルートはいつもpreferedされます。
(ii) Amongst routes with an equal external metric,
routes with a shorter internal metric are prefered.
Amongst routes of equal cost, loadsplitting may be
performed as specified in [1].
(ii) 等しい外部がメートル法であることでのルートの中では、より短いインターナルがメートル法であることでのルートはpreferedされます。 等しい費用のルートの中では、loadsplittingは[1]で指定されるように実行されるかもしれません。
For level 2 routers which are announcing manually configured summary addresses in their level 2 LSPs, in some cases there will exist IP addresses which match the manually configured addresses, but which do
いくつかの場合、レベル2 手動で構成された概要がそれらのレベル2でLSPsを扱う発表であるルータのために、手動で構成されたアドレスを合わせますが、合わせるIPアドレスは存在するでしょう。
Callon [Page 29] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[29ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
not match any addresses which are actually reachable via level 1 routing in the area. Generally, packets to such addresses are handled according to the following rules:
いずれも扱う実際にその領域で掘りながらレベル1で届いているマッチでない。 一般に、以下の規則に従って、そのようなアドレスへのパケットは扱われます:
1) If the specified destination is reachable via level 1 routing,
then according to the order of preference of routes specified
above, the packet will be delivered via level 1 routing.
1) 指定された目的地がそして、上で指定されたルートに関するよく使われる順によると、掘りながらレベル1で届くと、パケットはレベル1 ルーティングで提供されるでしょう。
2) If the specified destination is not reachable via level 1 routing,
but is reachable via 2 routing, and there are other level 2
routers which offer more desireable routes according to the
rules specified above (for example a route with a more specific
match, or a route with an equally specific match which supports
the correct TOS), then level 2 routing will forward the packet
according to the more desireable route.
2) 指定された目的地がレベル1 ルーティングで届きませんが、掘りながら2で届いていて、他のレベル2 (例えば、より特定のマッチがあるルート、または正しいTOSをサポートする等しく特定のマッチがあるルート)の上で指定された規則に従って、より「望-可能」なルートを提供するルータがあると、より「望-可能」なルートに応じて、レベル2 ルーティングはパケットを進めるでしょう。
3) If the specified destination is not reachable via level 1 routing,
and the manually configured summary address advertised by this
router (the router which has received the packet and is trying
to forward it) represents the most desireable route, then the
destination is unreachable and the packet must be discarded.
3) 指定された目的地がレベル1 ルーティングで届いていなくて、このルータ(パケットを受けて、それを進めようとしているルータ)によって広告に掲載された手動で構成された概要アドレスが最も「望-可能」なルートを表すなら、目的地は手が届きません、そして、パケットを捨てなければなりません。
4 Subnetwork Dependent Functions
4 サブネットワークの依存する機能
4.1 Link Demultiplexing
4.1 リンク逆多重化
Dual routers may receive a combination of OSI packets, and IP packets. It is necessary for the dual routers to be able to clearly and unambiguously distinguish the two protocol suites.
二元的なルータはOSIパケット、およびIPパケットの組み合わせを受け取るかもしれません。 二元的なルータが明確に、明白に2つのプロトコル群を区別できるのが必要です。
This problem is not unique to the integrated IS-IS routing protocol. In fact, this problem will occur in any multi-protocol environment. This problem is currently being worked on independently, and is outside of the scope of this specification.
この問題が統合にユニークでない、-、ルーティング・プロトコル。 事実上、この問題はどんなマルチプロトコル環境でも起こるでしょう。 この問題は、現在独自に働いていて、この仕様の範囲の外にあります。
In general, the link type is a configuration parameter. For example, whether to use PPP, HDLC, or some other point-to-point protocol over a point-to-point link would be configured. For any particular link type, a method must be defined for encapsulation of both OSI and IP packets. Definition of such methods for common link types is outside of the scope of this specification.
一般に、リンク型は設定パラメータです。 例えば、PPP、HDLCを使用するか、そして、ある他の二地点間プロトコルがポイントツーポイント接続の上で構成されるでしょう。 どんな特定のリンク型にとっても、OSIとIPパケットの両方のカプセル化のためにメソッドを定義しなければなりません。 一般的なリンク型のためのそのようなメソッドの定義がこの仕様の範囲の外にあります。
IP packets are encapsulated directly over the underlying link layer service, using the normal method for transmssion of IP packets over each type of link. Similarly OSI packets are encapsulated directly over the underlying link layer service, using the normal method for transmission of OSI packets over each type of link. Finally, note that IS-IS packets are encapsulated using the normal method for
IPパケットは基本的なリンクレイヤサービスの直接上でカプセルに入れられます、IPパケットのtransmssionにそれぞれのタイプのリンクの上に正常なメソッドを使用して。 同様に、OSIパケットは基本的なリンクレイヤサービスの直接上でカプセルに入れられます、OSIパケットのトランスミッションにそれぞれのタイプのリンクの上に正常なメソッドを使用して。 最終的に、それに注意してください、-、正常なメソッドを使用するのはパケットにカプセル化されます。
Callon [Page 30] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[30ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
transmission of OSI packets over any particular link type. This implies that all IS-IS routers, including IP-only routers, must be able to receive IS-IS packets using the normal encapsulation for OSI packets.
どんな特定のリンク型でのOSIパケットのトランスミッション。 これがそれを含意する、すべて、-、IPだけルータを含むルータが受信できなければならない、-、OSIパケットに正常なカプセル化を使用するパケット。
4.2 Multiple IP Addresses per Interface
4.2 複数の1インタフェースあたりのIPアドレス
The integrated IS-IS allows each router to have multiple IP addresses for each physical interface, up to the maximum number which may be contained in a single "IP Interface Address" field (i.e., up to a maximum of 63 addresses per interface). For example, where there are two logical subnets on the same LAN, the interface may have two IP addresses, one corresponding to each logical subnet. Each IS-IS Hello packet contains a list of IP addresses associated with the physical interface over which the Hello is transmitted.
統合、-、各ルータには各物理インターフェースへの複数のIPアドレスがただ一つの「IPインターフェース・アドレス」分野(すなわち、1インタフェースあたり最大63のアドレスまでの)に保管されるかもしれない最大数まであるのを許容します。 例えば、2つの論理的なサブネットが同じLANにあるところでは、1つが対応する場合、インタフェースはそれぞれの論理的なサブネットにIPが扱う2を持っているかもしれません。 それぞれ、-、HelloパケットはHelloが伝えられる物理インターフェースに関連しているIPアドレスのリストを含んでいます。
It is permissible to implement routers which conform to the Integrated IS-IS specification which restrict the number of IP addresses per interface. However, IP-capable routers must be able to interact correctly with other routers which assign multiple IP addresses per physical interface (up to the maximum of 63 addresses per interface).
Integratedに従うルータを実装するのが許されている、-、1インタフェースあたりのIPアドレスの数を制限する仕様。 しかしながら、IPできるルータは正しく(1インタフェースあたり63のアドレスの最大)を複数の1物理インターフェースあたりのIPアドレスに割り当てる他のルータと対話できなければなりません。
Where appropriate (for example, in some cases on point-to-point links), some interfaces may have no IP addresses assigned. In this case, the IS-IS Hello transmitted on that interface may omit the IP Interface Address field, or may include the IP Interface Address field with zero entries.
適切である(例えばいくつかの場合、ポイントツーポイント接続に関して)ところでは、いくつかのインタフェースで、IPアドレスを全く割り当てないかもしれません。 この場合、-、そのインタフェースで伝えられたHelloはIP Interface Address分野を省略するか、またはエントリーがないIP Interface Address分野を含むかもしれません。
4.3 LANs, Designated Routers, and Pseudonodes
4.3のLANルータ、およびPseudonodesに指定されて、
The maintenance of designated routers and pseudonodes is specified in [1], and is not changed by this proposal. In the case that IP-only and dual routers (or OSI-only and dual routers) are mixed on the same LAN in a pure IP area (or a pure OSI area, respectively), any router on the LAN may be elected designated router.
代表ルータとpseudonodesのメインテナンスは、[1]で指定されて、この提案で変えられません。 IPだけと二元的なルータ(または、OSIだけと二元的なルータ)が純粋なIP領域の同じLANで複雑である、(または、純粋なOSI領域、それぞれ)、LANに関するどんなルータも代表ルータに選出されるかもしれません。
However, there is a fundamental difference in the way that OSI and TCP/IP deal with LANs, and other broadcast subnetworks.
しかしながら、OSIとTCP/IPがLAN、および他の放送サブネットワークに対処する方法の基本的な違いがあります。
With OSI, the use of the ES-IS protocol (ISO 9542) allows the end systems and routers to automatically determine their connectivity, thereby allowing all end systems on the LAN to potentially route via any of the routers on the LAN.
OSI、使用、ES存在、プロトコル(ISO9542)でエンドシステムとルータは自動的にそれらの接続性を決定できます、その結果、LANのルータのどれかを通して潜在的に発送するLANにすべての終わりにシステムを許容します。
In contract, TCP/IP explictly assigns subnet identifiers to each local area network. In some cases, a single physical LAN could have multiple subnet identifiers assigned to it. In this case, end systems
契約では、TCP/IPはexplictlyに各ローカル・エリア・ネットワークにサブネット識別子を配属します。 いくつかの場合、ただ一つの物理的なLANで、複数のサブネット識別子をそれに割り当てるかもしれません。 この場合、システムを終わらせてください。
Callon [Page 31] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[31ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
(hosts) which have an address on one logical subnet are explicitly precluded from sending IP packets directly to a router whose address places it on a different logical subnet. Each router is manually configured to know which subnets it can reach on each interface. In the case that there are multiple logical subnets on the same LAN, each router can only exchange IP packets with those end systems which are on the same logical subnet. This implies that it is not sufficient for the pseudonode LSP to announce all subnets on the LAN (i.e., all [IP address, subnet mask] pairs reachable on the LAN).
(ホスト) 直接アドレスが異なった論理的なサブネットにそれを置くルータにIPパケットを送る論理的なサブネットが明らかに排除される1に関するアドレスを持っている。 各ルータは、それが各インタフェースでどのサブネットに達することができるかを知るために手動で構成されます。 複数の論理的なサブネットが同じLANにあって、各ルータは同じ論理的なサブネットにあるそれらのエンドシステムとIPパケットを交換できるだけです。 これは、pseudonode LSPがLAN(すなわち、LANで届いている組)ですべてのサブネットを発表するのが、十分でないことを含意します。
It is therefore necessary for each router to announce in its LSPs those subnets which it can reach on each interface, including interfaces to broadcast subnetworks such as LANs. The pseudonode LSP does not specify the IP addresses which are reachable on the LAN (i.e., does not contain the the IP reachability field).
したがって、各ルータがLSPsでそれが各インタフェースで達することができるそれらのサブネットを発表するのが必要です、LANなどのサブネットワークを放送するためにインタフェースを含んでいて。 pseudonode LSPはLAN(すなわち、IP可到達性分野を含んでいない)で届いているIPアドレスを指定しません。
As specified elsewhere (see the forthcoming update to the "Requirements of IP Gateways" [4]), routers may send ICMP redirects only if: (i) the IP packet is being forwarded over the same physical interface over which it arrived; and (ii) the source address of the forwarded IP packet, the IP address of this router's interface (as indicated by the source address of the ICMP redirect), and the IP address of the router to which the packet is being redirected (again, as indicated in the ICMP redirect) are all on the same IP subnet.
ほかの場所で指定される、(「IPゲートウェイの要件」[4])への今度のアップデートであり、ルータがICMPを送るかもしれないのを確実にしてください、向け直す、唯一、: (i) それが到着したのと同じ物理インターフェースの上にIPパケットを送っています。 ICMPにみられるようにそして、進められたIPパケットの(ii)ソースアドレス、このルータのインタフェースのIPアドレス(ICMPのソースアドレスによって再直接で示されるように)、およびパケットが向け直されているルータのIPアドレス、(再び、再直接、)、同じIPサブネットのすべてがそうです。
4.4 Maintaining Router Adjacencies
4.4 ルータ隣接番組を維持すること。
The IS-IS determines whether an adjacency is to be established between two routers using means which are independent of the IP interface addresses of the routers. Where multiple logical subnets occur on the same physical LAN, this potentially allows adjacencies to be brought up between two routers which share physical connectivity to each other, but which don't have a logical subnet in common. IP-capable IS-IS routers therefore must be able to forward IP packets over existing adjacencies to routers with which they share physical connectivity, even when the IP address of the adjacent interface of the neighboring router is on a different logical IP subnet.
-、2つのルータの間にルータのIPインターフェース・アドレスから独立している手段を使用することで設立される隣接番組がことであるか否かに関係なく、決定します。 複数の論理的なサブネットが同じ物理的なLANに起こるところでは、これは、隣接番組が物理的な接続性を互いに共有しますが、論理的なサブネットが共通でない2つのルータの間に持って来られるのを潜在的に許容します。 IPできる、-、したがって、ルータはそれらが物理的な接続性を共有するルータへの隣接番組を存在する上のIPパケットに送ることができなければなりません、隣接しているルータの隣接しているインタフェースのIPアドレスが異なった論理的なIPサブネットにありさえするときさえ。
For point-to-point links, IS-IS requires exchange of ISO 9542 ISHs, as the first step in establishing the link between routers. All IS-IS routers are therefore required to transmit and receive ISO 9542 ISH packets on point-to-point links.
ポイントツーポイント接続に-、第一歩としてルータの間のリンクを設立する際にISO9542ISHsの交換を必要とします。 すべて、-、したがって、ルータが、ポイントツーポイント接続の上でISO9542ISHパケットを送受信するのに必要です。
The "protocols supported" field (defined in section 5 below) must be present in all IS-IS Hello packets sent by dual and IP-only routers. If this field is missing, then it is assumed that the packet was transmitted by an OSI-only router. Similarly, those 9542 ISHs sent
「サポートされたプロトコル」分野(下のセクション5で、定義される)が全部で存在していなければならない、-、二元的によって送られたHelloパケットとIPだけルータ。 この分野がなくなるなら、パケットがOSIだけルータによって伝えられたと思われます。 同様に、それらの9542ISHsが発信しました。
Callon [Page 32] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[32ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
over point-to-point links, where there is (or may be) another IS-IS router at the other end of the point-to-point link, must also contains the "protocols supported" field. Note that if this field is mistakenly sent in a 9542 ISH where there is an ordinary OSI-only End System at the other end of the link, then (in accordance to ISO 9542) the End System is required to ignore the field and interpret the ISH correctly. It is therefore safe to always include this field in ISHs sent over point-to-point links.
ある(または、あるかもしれません)ポイントツーポイント接続の上、別のもの、-、ルータ、また、ポイントツーポイント接続のもう一方の端では、必須は「サポートされたプロトコル」分野を含んでいます。 この分野が誤ってそうなら普通のOSIだけEnd Systemがリンクのもう一方の端にある9542ISHを送った注意、そして(ISO9542との一致で)、End Systemは分野を無視して、正しくISHを解釈しなければなりません。 したがって、いつもポイントツーポイント接続の上に送られたISHsのこの分野を含んでいるのは安全です。
Dual routers must operate in a dual fashion on every link in the routing domain over which they are running IS-IS. Thus, the value of the "protocols supported" field must be identical on every link (i.e., for any one router running IS-IS, all of the Hellos and LSPs transmitted by it must contain the same "protocols supported" values).
二元的なルータが二元的なファッションでそれらが稼働する予定である経路ドメインのあらゆるリンクを作動させなければならない、- したがって、「サポートされたプロトコル」分野の値があらゆるリンクで同じであるに違いない、(すなわち、どんなルータ稼働、も-、ハローズとそれによって伝えられたLSPsのすべてが同じ「サポートされたプロトコル」値を含まなければならない、)
4.5 Forwarding to Incompatible Routers
4.5 両立しないルータへの推進
There may be times when a dual router has to forward an IP packet to an OSI-only router, or forward an OSI packet to an IP-only router. In this case the packet must be discarded. An error report may be transmitted, in accordance with the IP or ISO 8473 specification (respectively). The reason for discard specified in the error report should specify "destination host unreachable" (for IP), or "destination unreachable" (for OSI).
二元的なルータがIPパケットをOSIだけルータに送らなければならないか、またはOSIパケットをIPだけルータに送らなければならない回があるかもしれません。 この場合、パケットを捨てなければなりません。 エラー・レポートはIPかISO8473仕様(それぞれ)通りに伝えられるかもしれません。 エラー・レポートで指定された破棄の理由は「あて先ホスト手の届かなさ」(IPのための)か、または「目的地手が届きません、な」状態で(OSIのための)指定するべきです。
Similarly, due to errors, in some cases an IP-only router may have to forward an IP packet to an OSI-only router. Again, the packet must be discarded, as specified above. This may only occur if IP-only and OSI-only routers occur in the same area, which is a configuration error.
同様に、誤り、いくつかの場合IPだけルータはIPパケットをOSIだけルータに送らなければならないかもしれません。 一方、上で指定されるとしてパケットを捨てなければなりません。 IPだけとOSIだけルータが構成誤りであるのと同じ領域に起こる場合にだけ、これは起こるかもしれません。
5 Structure and Encoding of PDUs
5 PDUsの構造とコード化
This clause describes the additional packet fields for use of the ISO IS-IS Intra-Domain Routing protocol in pure IP and dual environments. Specifically, the same packet types are used as in IS-IS [1], and all fixed fields remain the same. Additional variable length fields are defined in this section.
この節が使用のための追加パケット分野について説明する、ISO IS存在、純粋なIPの、そして、二元的な環境におけるIntra-ドメインルート設定プロトコル。 明確に、同じパケットタイプが同じくらい中で使用される、-、[1]、および分野の残りが同じように固定されたすべて。 追加可変長フィールドはこのセクションで定義されます。
5.1 Overview of IS-IS PDUs
5.1概要、-、PDUs
The packets used in IS-IS routing protocol fall into three main classes: (i) Hello Packets; (ii) Link State Packets (LSPs); and (iii) Sequence Number Packets (SNPs).
パケットが中で使用した、-、3メインへのルーティング・プロトコル落下は属します: (i) こんにちは、パケット。 (ii) 州のパケット(LSPs)をリンクしてください。 そして、(iii)一連番号パケット(SNPs)。
Hello packets are used to initialize and maintain adjacencies between neighboring routers. There are three types of IS-IS Hello packets:
こんにちは、パケットはそうです。隣接しているルータの間の隣接番組を初期化して、維持するのにおいて、使用されています。 3つのタイプがある、-、Helloパケット:
Callon [Page 33] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[33ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
(i) "Level 1 LAN IS to IS Hello PDUs" are used by level 1 routers on broadcast LANs. (ii) "Level 2 LAN IS to IS Hello PDUs" are used by level 2 routers on broadcast LANs. (iii) "Point-to-Point IS to IS Hello PDUs" are used on non-broadcast media, such as point-to-point links, or general topology subnetworks.
「こんにちは、LANがあるレベル1はPDUsです」が使用される(i)は放送LANに1ルータを平らにします。 (ii) 「LANがあるレベル2はHello PDUsです」は放送LANでレベル2 ルータによって使用されます。 (iii) 「ポイントからポイントがある、Hello PDUsである、」 ポイントツーポイント接続、または一般的なトポロジーサブネットワークなどの非電波媒体では、使用されます。
On point-to-point links, the exchange of ISO 9542 ISHs (intermediate system Hellos) is used to initialize the link, and to allow each router to know if there is a router on the other end of the link, before IS-IS Hellos are exchanged. All routers implementing IS-IS (whether IP-only, OSI-only, or dual), if they have any interfaces on point-to-point links, must therefore be able to transmit ISO 9542 ISHs on their point-to-point links.
ポイントツーポイント接続の上では、ISO9542ISHs(中間システムハローズ)の交換はリンクを初期化して、ルータがリンクのもう一方の端にあるかを知るために各ルータを許容するのに使用されます、以前-、ハローズ、交換します。 すべてのルータが実装する、-、したがって、ポイントツーポイント接続の上に何かインタフェースを持っているなら、彼らのポイントツーポイント接続の上でISO9542ISHsを伝えることができなければなりません(IP唯一、OSI唯一、または二元的であることにかかわらず)。
Link State Packets (LSPs) are used to exchange link state information. There are two types of LSPs: (i) "Level 1 Link State PDUs" are transmitted by level 1 routers. (ii) "Level 2 Link State PDUs" are transmitted by level 2 routers. Note that level 2 routers will, in most cases, also be level 1 routers, and will therefore transmit both sorts of LSPs.
リンク州Packets(LSPs)は、リンク州の情報を交換するのに使用されます。 LSPsの2つのタイプがあります: (i) 「レベル1 Link州PDUs」はレベル1 ルータによって伝えられます。 (ii) 「レベル2 Link州PDUs」はレベル2 ルータによって伝えられます。 レベル2 ルータがレベル1 また、多くの場合ルータであり、したがって、LSPsの両方の種類を伝えることに注意してください。
Sequence number PDUs are used to ensure that neighboring routers have the same notion of what is the most recent LSP from each other router. The sequence number PDUs therefore serve a similar function to acknowledgement packets, but allow more efficient operation. There are four types of sequence number packets: (i) "Level 1 Complete Sequence Numbers PDU"; (ii) "Level 2 Complete Sequence Numbers PDU"; (iii) "Level 1 Partial Sequence Numbers PDU"; and (iv) "Level 2 Partial Sequence Numbers PDU". A partial sequence number packet lists the most recent sequence number of one or more LSPs, and operates much like an acknowlegement. A partial sequence number packet differs from an conventional acknowledgement in the sense that it may acknowlege multiple LSPs at once, and in the sense that it may act as a request for information. A complete sequence number packet contains the most recent sequence number of all LSPs in the database. A complete sequence number packet may therefore be used to ensure synchronization of the database between adjacent routers either periodically, or when a link first comes up.
一連番号PDUsは隣接しているルータには何に関する同じ考えがあるかを保証するのに使用されているのが、最新のLSPであるということです。互いからのルータ。 一連番号PDUsはしたがって、同様の機能を確認応答パケットに果たしますが、より効率的な操作を許します。 4つのタイプの一連番号パケットがあります: (i) 「レベル1 一連番号PDUを完成してください」。 (ii) 「レベル2 一連番号PDUを完成してください」。 (iii) 「レベル1 部分的な一連番号PDU」。 そして、(iv)「レベル2 部分的な一連番号PDU。」 部分的な一連番号パケットは、1LSPsの最新の一連番号を記載して、acknowlegementのように作動します。 部分的な一連番号パケットはすぐに、そして、および情報に関する要求として機能するかもしれないという意味におけるacknowlege倍数LSPsがそうするかもしれないという意味における従来の承認と異なっています。 完全な配列数のパケットはデータベースのすべてのLSPsの最新の一連番号を含んでいます。 したがって、完全な配列数のパケットは、定期的かリンクが最初に来るときに時隣接しているルータの間のデータベースの同期を確実にするのに使用されるかもしれません。
5.2 Overview of IP-Specific Information for IS-IS
IP-特殊情報の5.2概要、-
There are six new fields defined for the Integrated IS-IS: (i) "Protocols Supported"; (ii) "IP Interface Address"; (iii) "Authentication Information"; (iv) "IP Internal Reachability Information"; (v) "IP External Reachability Information"; and (vi) "Inter-Domain Routing Protocol Information".
Integratedのために定義された6つの新しい分野がある、-、: (i) 「サポートされたプロトコル」。 (ii) 「IPインターフェース・アドレス」。 (iii) 「認証情報」。 (iv) 「IPの内部の可到達性情報」。 (v) 「IPの外部の可到達性情報」。 そして、(vi)「相互ドメインルート設定プロトコル情報。」
The "Protocols Supported" field identifies the protocols which are
「サポートされたプロトコル」分野はそうするプロトコルを特定します。
Callon [Page 34] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[34ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
supported by each router. This field must be included in all IS-IS Hello packets and all LSPs with LSP number 0 transmitted by IP- capable routers. If this field is not included in an IS-IS Hello packet or an LSP with LSP number 0, it may be assumed that the packet was transmitted by an OSI-only router. The "Protocols Supported" field must also be included in ISO 9542 ISHs send by IP-capable routers over point-to-point links to other IS-IS routers.
各ルータで、サポートされます。 すべてにこの分野を含まなければならない、-、LSP No.0があるHelloパケットとすべてのLSPsがIPのできるルータで伝わりました。 または、この分野が中に含まれていない、-、Helloパケット、LSP No.0があるLSP、パケットがOSIだけルータによって伝えられたと思われるかもしれません。 また、9542ISHsがポイントツーポイント接続の上でIPできるルータで他に送るISOに「サポートされたプロトコル」分野を含まなければならない、-、ルータ。
The "IP Interface Address" is included in all IS-IS Hello packets and LSPs transmitted by IP-only and dual routers. In the Hello packets, this field occurs once only, and contains the IP address(es) of the interface on which the Hello packet is transmitted (up to a maximum of 63 IP addresses on each interface). If an IS-IS Hello is transmitted over an interface which does not have an IP address assigned, then this field may be omitted, or may be included with zero entries. In Link State Packets, this field contains a list of one or more IP addresses corresponding to one or more interfaces of the router which originates the LSP. Each IP-capable router must include this field in its LSPs. This field may occur multiple times in an LSP, and may occur in an LSP with any LSP number.
「IPインターフェース・アドレス」がすべてに含まれている、-、HelloパケットとLSPsはIPだけと二元的なルータで伝わりました。 Helloパケットでは、この分野は、いったん唯一と起こって、Helloパケットが伝えられるインタフェース(各インタフェースに関する最大最大63のIPアドレス)のIPアドレス(es)を含んでいます。 -、HelloがIPアドレスを割り当てないインタフェースの上に伝えられて、次に、この分野は、省略しないか、どんなエントリーでも含むことができません。 Link州Packetsでは、この分野はLSPを溯源するルータの1つ以上のインタフェースに対応する1つ以上のIPアドレスのリストを含んでいます。 それぞれのIPできるルータはLSPsのこの分野を含まなければなりません。 この分野は、LSPに複数の回起こって、LSPにどんなLSP番号でも起こるかもしれません。
The "Authentication Information" field is optional in all IS-IS PDUs. If used, it contains information used to authenticate the packet. All IS-IS packets (including 9542 IS Hellos) may be authenticated by use of this field.
「認証情報」分野が全部で任意である、-、PDUs。 使用されるなら、それはパケットを認証するのに使用される情報を含んでいます。 すべて、-、パケット(9542を含むのは、ハローズである)はこの分野の使用で認証されるかもしれません。
The "IP Internal Reachability Information" field may be present in all LSPs transmitted by IP-capable routers. If present, it identifies a list of zero or more [IP address, subnet mask, metrics] reachable by the router which originates the LSP. Each entry must contain a default metric, and may contain delay, expense, and error metrics. If an IP-capable router does not directly reach any IP addresses, then it may omit this field, or may include the field with zero [IP address, subnet mask, metrics] entries. If included in level 1 LSPs, this field includes only entries directly reachable by the router which originates the LSP, via one of its interfaces. If included in level 2 LSPs, this field includes only entries reachable by the router which originates the LSP, either via one of its interfaces, or indirectly via level 1 routing. This field may occur multiple times in an LSP, and may occur in an LSP with any LSP number.
「IPの内部の可到達性情報」分野はIPできるルータによって伝えられたすべてのLSPsに存在しているかもしれません。 存在しているなら、それはLSPを溯源するルータで届いた状態でゼロか以上[IPアドレス、サブネットマスク、測定基準]のリストを特定します。 各エントリーは、メートル法であることでデフォルトを含まなければならなくて、遅れ、費用、および誤り測定基準を含むかもしれません。 IPできるルータが直接少しのIPアドレスにも達しないなら、それは、この分野を省略するか、または[IPアドレス、サブネットマスク、測定基準]エントリーがない分野を含むかもしれません。 レベル1LSPsに含まれているなら、この分野はLSPを溯源するルータで直接届いているエントリーだけを含んでいます、インタフェースの1つを通して。 レベル2LSPsに含まれているなら、この分野はLSPを溯源するルータで届いているエントリーだけを含んでいます、レベル1 インタフェースの1つを通して間接的のどちらかにルーティングで。 この分野は、LSPに複数の回起こって、LSPにどんなLSP番号でも起こるかもしれません。
The "IP External Reachability Information" field may be present in level 2 LSPs transmitted by level 2 IP-capable routers. If present, it identifies a list of zero or more [IP address, subnet mask, metrics] entries reachable by the router which originates the level 2 LSP. Each entry must contain a default metric, and may contain delay, expense, and error metrics. Each entry may contain metrics of type "internal", or of type "external". If a level 2 router does not have
「IPの外部の可到達性情報」分野はレベル2 IPできるルータによって伝えられたレベル2LSPsで存在しているかもしれません。 存在しているなら、それはゼロか平らな2LSPを溯源するルータで届いているより多くの[IPアドレス、サブネットマスク、測定基準]エントリーのリストを特定します。 各エントリーは、メートル法であることでデフォルトを含まなければならなくて、遅れ、費用、および誤り測定基準を含むかもしれません。 各エントリーは「外部であること」の形で「内部タイプ」、またはタイプの測定基準を含むかもしれません。 ルータがそうしないレベル2がそうしたなら
Callon [Page 35] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[35ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
any external routes (via neighboring routers in other routing domains), when it may omit this field, or may include the field with zero entries. This field includes only entries reachable by the router which originates the LSP, via a direct link to an external router. This field may occur multiple times in a level 2 LSP, and may occur in an LSP with any LSP number.
どんな外部経路(他の経路ドメインの隣接しているルータを通した)、それがそうするかもしれないときにはこの分野を省略してください、またはエントリーがない分野を含むかもしれません。 この分野はLSPを溯源するルータで届いているエントリーだけを含んでいます、外部のルータへの直リンクで。 この分野は、平らな2LSPに複数の回起こって、LSPにどんなLSP番号でも起こるかもしれません。
The "Inter-Domain Routing Protocol Information" field may be present in level 2 LSPs transmitted by level 2 IP-capable routers. This field is transmitted for the convenience of the external routing protocol, and is not used by the IS-IS. For example, this may be used to allow border routers to find each other. This field may occur multiple times in a level 2 LSP, and may occur in an LSP with any LSP number.
「相互ドメインルーティング・プロトコル情報」分野はレベル2 IPできるルータによって伝えられたレベル2LSPsで存在しているかもしれません。 この野原が外部のルーティング・プロトコルの都合のために伝えられて、使用されない、- 例えば、これは、境界ルータが互いを見つけるのを許容するのに使用されるかもしれません。 この分野は、平らな2LSPに複数の回起こって、LSPにどんなLSP番号でも起こるかもしれません。
The DP 10589 version of the OSI IS-IS does not currently allow addition of TLV-encoded variable length fields to Sequence Number Packets. However, this is being corrected in future versions of 10589. In addition, this is expected to be the only correction to future versions of 10589 that is not backward-compatible with the DP version. The Integrated IS-IS therefore makes use of a corrected version of DP 10589, such that the encoding of SNPs has been fixed. The correct encoding of sequence number packets (as is expected to appear in future versions of ISO 10589) is given in Annex B of this specification.
DP10589バージョン、OSI IS存在、現在、TLVによってコード化された可変長フィールドの追加をSequence Number Packetsに許容しないでください。 しかしながら、これは10589の将来のバージョンで修正されています。 さらに、これは10589の将来のバージョンへの唯一のDPバージョンと後方の互換性がない修正であると予想されます。 Integrated、-、したがって、DP10589(SNPsのコード化が修理されたようなもの)の訂正版を利用します。 Annex Bで一連番号パケット(ISO10589の将来のバージョンに現れると予想されるとき)の正しいコード化にこの仕様を与えます。
All IP-specific information is encoded in IS-IS packets as variable length fields. All variable length fields in IS-IS are encoded as follows:
すべてのIP-特殊情報がコード化される、-、パケット、可変長フィールドとして。 すべての可変長が中でさばく、-、以下の通りコード化されます:
No. of Octets
+---------------------------+
| CODE | 1
+---------------------------+
| LENGTH | 1
+---------------------------+
| VALUE | LENGTH
+---------------------------+
八重奏+についていいえ---------------------------+ | コード| 1 +---------------------------+ | 長さ| 1 +---------------------------+ | 値| 長さ+---------------------------+
Figure 3 - Encoding of Variable Length Fields
図3--可変長フィールドのコード化
Any codes in a received PDU that are not recognised shall be ignored and, for those packets which are forwarded (specifically Link State Packets), passed on unchanged.
進められるそれらのパケット(明確にLink州Packets)のために、容認されたPDUの認識されない少しのコードも、変わりがない状態で無視されて、伝えられるものとします。
In general, an IS-IS PDU may contain multiple variable length fields, some of which contain OSI-specific information (specified in [1]) and some of which contain IP-specific information (specified below). Except where explicitly stated otherwise, these variable length
複数の可変長フィールドを含むかもしれません、OSI-特殊情報を含むもののいくつか。一般に、-、IS PDU、([1])といくつかでは、どれがIP-特殊情報を含むかについて指定されています(以下で指定された)。 そうでなければ、明らかに述べられているのを除いたこれらの可変長
Callon [Page 36] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[36ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
fields may occur in any order.
分野は順不同に起こるかもしれません。
5.3 Encoding of IP-Specific Fields in IS-IS PDUs
IP-詳細のコード化が中でさばく5.3、-、PDUs
This section specifies the detailed encoding of all IP-specific fields in IS-IS PDUs. Where a particular field may be present in more than one type of PDU, the field is repeated for each type of PDU to which it applies.
このセクションが中ですべてのIP特有の分野の詳細なコード化を指定する、-、PDUs。 特定の分野がPDUの1つ以上のタイプで存在しているかもしれないところでは、分野はそれが適用されるPDUの各タイプのために繰り返されます。
Bit and octet numbering is the same as in [1]. In particular, octets in a PDU are numbered starting from 1, in increasing order. Bits in an octet are numbered from 1 to 8, where bit 1 is the least significant bit and is pictured on the right. When consecutive octets are used to represent a number, the lower octet number has the most significant value.
噛み付かれて、八重奏付番は[1]と同じです。 増加するオーダーで1から始めて、PDUの八重奏は特に、番号付です。 八重奏におけるビットは、番号付の1〜8です。(そこでは、ビット1は、最下位ビットであり、右に描写されます)。 連続した八重奏が数を表すのに使用されるとき、下側の八重奏番号には、最も重要な値があります。
5.3.1 Level 1 LAN IS to IS Hello PDU
5.3.1 こんにちは、LANがあるレベル1はPDUです。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
7 プロトコルSupported--このIntermediate SystemがリレーできるNetwork LayerプロトコルのためのセットNetwork LayerプロトコルIdentifiers
x CODE - 129
x CODE--129
x LENGTH - total length of the value field (one octet per
protocol supported).
x LENGTH--値の分野(1サポートされたプロトコルあたり1つの八重奏)の全長。
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+---------------------------+
| NLPID | 1
+---------------------------+
: :
: :
|---------------------------|
| NLPID | 1
+---------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
x VALUE--データであるとサポートされたそれぞれのための1つの八重奏のNLPID(ISO/TR9577によって割り当てられるように)は議定書を作ります。 八重奏+についていいえ---------------------------+ | NLPID| 1 +---------------------------+ : : : : |---------------------------| | NLPID| 1 +---------------------------+NLPID--ISO/TR9577はNetwork LayerプロトコルIdentifierを登録しました。
7 IP Interface Address -- the IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
7 IP Interface Address--このPDUが伝えられることになっているSNPAに対応するインタフェースのIPアドレス(es)。
x CODE - 132
x CODE--132
x LENGTH - total length of the value field (four octets per address).
x LENGTH--値の分野(1アドレスあたり4つの八重奏)の全長。
Callon [Page 37] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[37ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
x VALUE--Octets+についていいえ----------------------------+ | IPアドレス| 4 +----------------------------+ : : : : +----------------------------+ | IPアドレス| 4 +----------------------------+IP ADDRESS--Interfaceの4八重奏IP Address。
7 Authentication Information -- Information used to authenticate the
PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field.
x LENGTH--値の分野の全長。
x VALUE - TBD.
x VALUE--TBD。
5.3.2 Level 2 LAN IS to IS Hello PDU
5.3.2 こんにちは、LANがあるレベル2はPDUです。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
7 プロトコルSupported--このIntermediate SystemがリレーできるNetwork LayerプロトコルのためのセットNetwork LayerプロトコルIdentifiers
x CODE - 129
x CODE--129
x LENGTH - total length of the value field (one octet per protocol
supported).
x LENGTH--値の分野(1サポートされたプロトコルあたり1つの八重奏)の全長。
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
x VALUE--データであるとサポートされたそれぞれのための1つの八重奏のNLPID(ISO/TR9577によって割り当てられるように)は議定書を作ります。 八重奏+についていいえ----------------------------+ | NLPID| 1 +----------------------------+ : : : : +----------------------------+ | NLPID| 1 +----------------------------+NLPID--ISO/TR9577はNetwork LayerプロトコルIdentifierを登録しました。
7 IP Interface Address -- The IP address(es) of the interface
7IP Interface Address--インタフェースのIPアドレス(es)
Callon [Page 38] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[38ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
corresponding to the SNPA over which this PDU is to be transmitted.
このPDUが伝えられることになっているSNPAに対応しています。
x CODE - 132
x CODE--132
x LENGTH - total length of the value field (four octets per address).
x LENGTH--値の分野(1アドレスあたり4つの八重奏)の全長。
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
x VALUE--Octets+についていいえ----------------------------+ | IPアドレス| 4 +----------------------------+ : : : : +----------------------------+ | IPアドレス| 4 +----------------------------+IP ADDRESS--Interfaceの4八重奏IP Address。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
5.3.3 Point-to-Point IS to IS Hello PDU
5.3.3 ポイントツーポイントがある、こんにちは、PDUです。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying
7 プロトコルSupported--このIntermediate SystemがリレーできるNetwork LayerプロトコルのためのセットNetwork LayerプロトコルIdentifiers
x CODE - 129
x CODE--129
x LENGTH - total length of the value field (one octet per protocol
supported).
x LENGTH--値の分野(1サポートされたプロトコルあたり1つの八重奏)の全長。
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
x VALUE--データであるとサポートされたそれぞれのための1つの八重奏のNLPID(ISO/TR9577によって割り当てられるように)は議定書を作ります。
Callon [Page 39] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[39ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
八重奏+についていいえ----------------------------+ | NLPID| 1 +----------------------------+ : : : : +----------------------------+ | NLPID| 1 +----------------------------+NLPID--ISO/TR9577はNetwork LayerプロトコルIdentifierを登録しました。
7 IP Interface Address -- The IP address(es) of the interface
corresponding to the SNPA over which this PDU is to be transmitted.
7 IP Interface Address--このPDUが伝えられることになっているSNPAに対応するインタフェースのIPアドレス(es)。
x CODE - 132
x CODE--132
x LENGTH - total length of the value field (four octets per address).
x LENGTH--値の分野(1アドレスあたり4つの八重奏)の全長。
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address of the Interface.
x VALUE--Octets+についていいえ----------------------------+ | IPアドレス| 4 +----------------------------+ : : : : +----------------------------+ | IPアドレス| 4 +----------------------------+IP ADDRESS--Interfaceの4八重奏IP Address。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
5.3.4 Level 1 Link State PDU
5.3.4 レベル1は州のPDUをリンクします。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
7 プロトコルSupported--このIntermediate SystemがリレーできるNetwork LayerプロトコルのためのセットNetwork LayerプロトコルIdentifiers。
This must appear once in LSP number 0.
これはLSP No.0に一度現れなければなりません。
Callon [Page 40] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[40ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
x CODE - 129
x CODE--129
x LENGTH - total length of the value field (one octet per protocol
supported).
x LENGTH--値の分野(1サポートされたプロトコルあたり1つの八重奏)の全長。
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for each
supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
x VALUE--データであるとサポートされたそれぞれのための1つの八重奏のNLPID(ISO/TR9577によって割り当てられるように)は議定書を作ります。 八重奏+についていいえ----------------------------+ | NLPID| 1 +----------------------------+ : : : : +----------------------------+ | NLPID| 1 +----------------------------+NLPID--ISO/TR9577はNetwork LayerプロトコルIdentifierを登録しました。
7 IP Interface Addresses -- The IP addresss of one or more interfaces
corresponding to the SNPAs enabled on this Intermediate system
(i.e., one or more IP addresses of this router).
7 IP Interface Addresses--SNPAsに対応する1つ以上のインタフェースのIP声明はこのIntermediateシステムの上で(すなわち、このルータの1つ以上のIPアドレス)を可能にしました。
This is permitted to appear multiple times, and in an LSP with
any LSP number.
これが複数の回、およびどんなLSP番号があるLSPにも現れることが許可されています。
x CODE - 132
x CODE--132
x LENGTH - total length of the value field (four octets per address).
x LENGTH--値の分野(1アドレスあたり4つの八重奏)の全長。
x VALUE -
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address
x VALUE--Octets+についていいえ----------------------------+ | IPアドレス| 4 +----------------------------+ : : : : +----------------------------+ | IPアドレス| 4 +----------------------------+IP ADDRESS--4八重奏IP Address
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
Callon [Page 41] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[41ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
x VALUE - TBD
x VALUE--TBD
7 IP Internal Reachability Information -- IP addresses within the
routing domain reachable directly via one or more interfaces on
this Intermediate system.
7 IP Internal Reachability情報--IPはこのIntermediateシステムの上で直接1以上を通して届いている経路ドメインの中でインタフェースを扱います。
This is permitted to appear multiple times, and in an LSP with any
LSP number. However, this field must not appear in pseudonode LSPs.
これが複数の回、およびどんなLSP番号があるLSPにも現れることが許可されています。 しかしながら、この野原はpseudonode LSPsに現れてはいけません。
x CODE - 128.
x CODE--128。
x LENGTH - a multiple of 12.
x LENGTH--12の倍数。
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
x VALUE--Octets+についていいえ----------------------------+ | 0 |I/E| メートル法で、デフォルトとしてください。| 1 +----------------------------+ | S| R| メートル法で、延着してください。| 1 +----------------------------+ | S| R| 費用メートル法です。| 1 +----------------------------+ | S| R| 誤りメートル法です。| 1 +----------------------------+ | IPアドレス| 4 +----------------------------+ | サブネットマスク| 4 +----------------------------+ : : : : +----------------------------+ | 0 |I/E| メートル法で、デフォルトとしてください。| 1 +----------------------------+ | S| R| メートル法で、延着してください。| 1 +----------------------------+ | S| R| 費用メートル法です。| 1 +----------------------------+ | S| R| 誤りメートル法です。| 1 +----------------------------+ | IPアドレス| 4 +----------------------------+ | サブネットマスク| 4 +----------------------------+
DEFAULT METRIC is the value of the default metric for the link
to the listed neighbor. Bit 8 of this field is reserved, and
must be set to zero on tranmission and ignored on reception.
Bit 7 of this field (marked I/E) indicates the metric type
DEFAULT METRICは記載された隣人へのリンクにおける、メートル法のデフォルトの値です。 この分野のビット8を予約されていて、tranmissionにゼロに設定されて、レセプションで無視しなければなりません。 この分野(I/Eであるとマークされる)のビット7はメートル法のタイプを示します。
Callon [Page 42] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[42ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
(internal or external) for all four TOS metrics, and must be
set to zero indicating internal metrics.
すべての4つのTOS測定基準、および必須における(内部か外部)、内部の測定基準を示さないのに設定されてください。
DELAY METRIC is the value of the delay metric for the link to the
listed neighbor. If this IS does not support this metric it shall
set the bit "S" to 1 to indicate that the metric is unsupported.
Bit 7 of this field is reserved, and must be set to zero on
transmission and ignored on reception.
DELAY METRICは記載された隣人へのリンクにおける、メートル法の遅れの値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
EXPENSE METRIC is the value of the expense metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set to
zero on transmission and ignored on reception.
EXPENSE METRICは記載された隣人へのリンクにおける、メートル法の費用の価値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
ERROR METRIC is the value of the error metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
ERROR METRICは記載された隣人へのリンクにおける、メートル法の誤りの値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
IP ADDRESS is a 4-octet Internet address
IP ADDRESSは4八重奏のインターネット・アドレスです。
SUBNET MASK is a 4 octet IP subnet mask.
SUBNET MASKは4八重奏IPサブネットマスクです。
5.3.5 Level 2 Link State PDU
5.3.5 レベル2は州のPDUをリンクします。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
7 プロトコルSupported--このIntermediate SystemがリレーできるNetwork LayerプロトコルのためのセットNetwork LayerプロトコルIdentifiers。
This must appear once in LSP number 0.
これはLSP No.0に一度現れなければなりません。
x CODE - 129
x CODE--129
x LENGTH - total length of the value field (one octet per
protocol supported).
x LENGTH--値の分野(1サポートされたプロトコルあたり1つの八重奏)の全長。
Callon [Page 43] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[43ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
x VALUE--データであるとサポートされたそれぞれのための1つの八重奏のNLPID(ISO/TR9577によって割り当てられるように)は議定書を作ります。 八重奏+についていいえ----------------------------+ | NLPID| 1 +----------------------------+ : : : : +----------------------------+ | NLPID| 1 +----------------------------+NLPID--ISO/TR9577はNetwork LayerプロトコルIdentifierを登録しました。
7 IP Interface Addresses -- The IP addresss of one or more interfaces
corresponding to the SNPAs enabled on this Intermediate system
(i.e., one or more IP addresses of this router).
7 IP Interface Addresses--SNPAsに対応する1つ以上のインタフェースのIP声明はこのIntermediateシステムの上で(すなわち、このルータの1つ以上のIPアドレス)を可能にしました。
This is permitted to appear multiple times, and in an LSP with
any LSP number. Where a router is both a level 1 and level 2 router,
it must include the same IP addresses in its level 1 and level 2 LSPs.
これが複数の回、およびどんなLSP番号があるLSPにも現れることが許可されています。 ルータがレベル2 レベル1とルータの両方であるところでは、それはレベル1とレベル2LSPsの同じIPアドレスを含まなければなりません。
x CODE - 132
x CODE--132
x LENGTH - total length of the value field (four octets per address).
x LENGTH--値の分野(1アドレスあたり4つの八重奏)の全長。
x VALUE-
No. of Octets
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
: :
: :
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
IP ADDRESS - 4 octet IP Address
x VALUE Octets+についていいえ----------------------------+ | IPアドレス| 4 +----------------------------+ : : : : +----------------------------+ | IPアドレス| 4 +----------------------------+IP ADDRESS--4八重奏IP Address
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
7 IP Internal Reachability Information -- IP addresses within the
routing domain reachable directly via one or more interfaces on
7 IP Internal Reachability情報--直接1を通して届いている経路ドメインか、より多くのインタフェースの中でオンなIPアドレス
Callon [Page 44] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[44ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
this Intermediate system.
このIntermediateシステム。
This is permitted to appear multiple times, and in an LSP with
any LSP number. However, this field must not appear in pseudonode
LSPs.
これが複数の回、およびどんなLSP番号があるLSPにも現れることが許可されています。 しかしながら、この野原はpseudonode LSPsに現れてはいけません。
x CODE - 128.
x CODE--128。
x LENGTH - a multiple of 12.
x LENGTH--12の倍数。
x VALUE -
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
x VALUE--Octets+についていいえ----------------------------+ | 0 |I/E| メートル法で、デフォルトとしてください。| 1 +----------------------------+ | S| R| メートル法で、延着してください。| 1 +----------------------------+ | S| R| 費用メートル法です。| 1 +----------------------------+ | S| R| 誤りメートル法です。| 1 +----------------------------+ | IPアドレス| 4 +----------------------------+ | サブネットマスク| 4 +----------------------------+ : : : : +----------------------------+ | 0 |I/E| メートル法で、デフォルトとしてください。| 1 +----------------------------+ | S| R| メートル法で、延着してください。| 1 +----------------------------+ | S| R| 費用メートル法です。| 1 +----------------------------+ | S| R| 誤りメートル法です。| 1 +----------------------------+ | IPアドレス| 4 +----------------------------+ | サブネットマスク| 4 +----------------------------+
DEFAULT METRIC is the value of the default metric for the link
to the listed neighbor. Bit 8 of this field is reserved, and must
be set to zero on transmission and ignored on reception. Bit 7
of this field indicates the metric type (internal or external)
for all four TOS metrics, and must be set to zero indicating
internal metrics.
DEFAULT METRICは記載された隣人へのリンクにおける、メートル法のデフォルトの値です。 この分野のビット8を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。 この分野のビット7をすべての4つのTOS測定基準における、(内部か外部)のメートル法のタイプを示して、内部の測定基準を示さないのに設定しなければなりません。
Callon [Page 45] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[45ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
DELAY METRIC is the value of the delay metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
DELAY METRICは記載された隣人へのリンクにおける、メートル法の遅れの値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
EXPENSE METRIC is the value of the expense metric for the link to
the listed neighbor. If this IS does not support this metric it
shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set
to zero on transmission and ignored on reception.
EXPENSE METRICは記載された隣人へのリンクにおける、メートル法の費用の価値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
ERROR METRIC is the value of the error metric for the link to the
listed neighbor. If this IS does not support this metric it shall
set the bit "S" to 1 to indicate that the metric is unsupported.
Bit 7 of this field is reserved, and must be set to zero on
transmission and ignored on reception.
ERROR METRICは記載された隣人へのリンクにおける、メートル法の誤りの値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
IP ADDRESS is a 4-octet Internet address
IP ADDRESSは4八重奏のインターネット・アドレスです。
SUBNET MASK is a 4 octet IP subnet mask.
SUBNET MASKは4八重奏IPサブネットマスクです。
7 IP External Reachability Information -- IP addresses outside the
routing domain reachable via interfaces on this Intermediate
system.
7 IP External Reachability情報--IPは、外でルーティングがこのIntermediateシステムの上のインタフェースを通して届いているドメインであると扱います。
This is permitted to appear multiple times, and in an LSP with
any LSP number. However, this field must not appear in pseudonode LSPs.
これが複数の回、およびどんなLSP番号があるLSPにも現れることが許可されています。 しかしながら、この野原はpseudonode LSPsに現れてはいけません。
x CODE - 130.
x CODE--130。
x LENGTH - a multiple of 12.
x LENGTH--12の倍数。
x VALUE -
x VALUE、-
Callon [Page 46] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[46ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
No. of Octets
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
: :
: :
+----------------------------+
| 0 |I/E| DEFAULT METRIC | 1
+----------------------------+
| S | R | DELAY METRIC | 1
+----------------------------+
| S | R | EXPENSE METRIC | 1
+----------------------------+
| S | R | ERROR METRIC | 1
+----------------------------+
| IP ADDRESS | 4
+----------------------------+
| SUBNET MASK | 4
+----------------------------+
八重奏+についていいえ----------------------------+ | 0 |I/E| メートル法で、デフォルトとしてください。| 1 +----------------------------+ | S| R| メートル法で、延着してください。| 1 +----------------------------+ | S| R| 費用メートル法です。| 1 +----------------------------+ | S| R| 誤りメートル法です。| 1 +----------------------------+ | IPアドレス| 4 +----------------------------+ | サブネットマスク| 4 +----------------------------+ : : : : +----------------------------+ | 0 |I/E| メートル法で、デフォルトとしてください。| 1 +----------------------------+ | S| R| メートル法で、延着してください。| 1 +----------------------------+ | S| R| 費用メートル法です。| 1 +----------------------------+ | S| R| 誤りメートル法です。| 1 +----------------------------+ | IPアドレス| 4 +----------------------------+ | サブネットマスク| 4 +----------------------------+
DEFAULT METRIC is the value of the default metric for the
path to the listed IP addresses. Bit 8 of this field is
reserved, and must be set to zero on transmission and ignored
on reception. Bit 7 of this field indicates the metric type
(internal or external) for all four TOS metrics, and may be
set to zero indicating internal metrics, or may be set to 1
indicating external metrics.
DEFAULT METRICは経路における、記載されたIPアドレスへのメートル法のデフォルトの値です。 この分野のビット8を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。 この分野のビット7は、すべての4つのTOS測定基準における、(内部か外部)のメートル法のタイプを示して、内部の測定基準を示さないのに設定されるか、または外部の測定基準を示す1に設定されるかもしれません。
DELAY METRIC is the value of the delay metric for the path
to the listed IP addresses. If this IS does not support this
metric it shall set the bit "S" to 1 to indicate that the metric
is unsupported. Bit 7 of this field is reserved, and must be
set to zero on transmission and ignored on reception.
DELAY METRICは経路における、記載されたIPアドレスへのメートル法の遅れの値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
EXPENSE METRIC is the value of the expense metric for the link
to the listed IP addresses. If this IS does not support this
metric it shall set the bit "S" to 1 to indicate that the metric
is unsupported. Bit 7 of this field is reserved, and must be
EXPENSE METRICは記載されたIPアドレスへのリンクにおける、メートル法の費用の価値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7は、予約されていて、あるに違いありません。
Callon [Page 47] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[47ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
set to zero on transmission and ignored on reception.
トランスミッションのときにゼロに設定されて、レセプションで無視されます。
ERROR METRIC is the value of the error metric for the link to
the listed IP addresses. If this IS does not support this metric
it shall set the bit "S" to 1 to indicate that the metric is
unsupported. Bit 7 of this field is reserved, and must be set to
zero on transmission and ignored on reception.
ERROR METRICは記載されたIPアドレスへのリンクにおける、メートル法の誤りの値です。 メートル法でこれをサポートしてください。これがそう、それは、1へのビット「S」にメートル法がサポートされないのを示すように設定するものとします。 この分野のビット7を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
IP ADDRESS is a 4-octet Internet address
IP ADDRESSは4八重奏のインターネット・アドレスです。
SUBNET MASK is a 4 octet IP subnet mask
SUBNET MASKは4八重奏IPサブネットマスクです。
7 Inter-Domain Routing Protocol Information -- Inter-domain routing
protocol information carried transparently through level 2 for
the convenience of any Inter-Domain protocol that may be running
in the boundary ISs.
7 相互Domainルート設定プロトコル情報--相互ドメインルーティングプロトコル情報はISs境界へ駆け込んでいるかもしれないどんなInter-ドメインプロトコルの都合のために透過的にレベル2を運び移しました。
This is permitted to appear multiple times, and in an LSP with
any LSP number.
これが複数の回、およびどんなLSP番号があるLSPにも現れることが許可されています。
x CODE - 131.
x CODE--131。
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE -
No. of Octets
+-------------------------------+
| Inter-Domain Information Type | 1
+-------------------------------+
| External Information | VARIABLE
+-------------------------------+
x VALUE--Octets+についていいえ-------------------------------+ | 相互ドメイン情報タイプ| 1 +-------------------------------+ | 外部の情報| 変数+-------------------------------+
INTER-DOMAIN INFORMATION TYPE indicates the type of the
external information which is encoded in the field.
INTER-DOMAIN INFORMATION TYPEはその分野でコード化される外部の情報のタイプを示します。
EXTERNAL INFORMATION contains inter-domain routing protocol
information, and is passed transparently by the IS-IS protocol.
EXTERNAL INFORMATIONが相互ドメインルーティングプロトコル情報を含んでいて、透過的に無視される、-、議定書を作ってください。
5.3.6 Level 1 Complete Sequence Numbers PDU
5.3.6 レベル1は一連番号PDUを完成します。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
Callon [Page 48] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[48ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
x VALUE - TBD
x VALUE--TBD
5.3.7 Level 2 Complete Sequence Numbers PDU
5.3.7 レベル2は一連番号PDUを完成します。
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
5.3.8 Level 1 Partial Sequence Numbers PDU
5.3.8 レベル1 部分的な一連番号PDU
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
5.3.9 Level 2 Partial Sequence Numbers PDU
5.3.9 レベル2 部分的な一連番号PDU
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
5.3.10 ISO 9542 ISH PDU
5.3.10 ISO9542ISH PDU
- Additional codes for IP support are:
- IPサポートのための追加コードは以下の通りです。
7 Protocols Supported -- the set Network Layer Protocol Identifiers
for Network Layer protocols that this Intermediate System is
capable of relaying.
7 プロトコルSupported--このIntermediate SystemがリレーできるNetwork LayerプロトコルのためのセットNetwork LayerプロトコルIdentifiers。
Callon [Page 49] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[49ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
This appears in ISO 9542 ISH PDUs transmitted on point-to-point
links.
これはポイントツーポイント接続の上で伝えられたISO9542ISH PDUsに現れます。
x CODE - 129
x CODE--129
x LENGTH - total length of the value field (one octet per
protocol supported).
x LENGTH--値の分野(1サポートされたプロトコルあたり1つの八重奏)の全長。
x VALUE - one octet NLPID (as assigned by ISO/TR 9577) for
each supported data protocol.
No. of Octets
+----------------------------+
| NLPID | 1
+----------------------------+
: :
: :
+----------------------------+
| NLPID | 1
+----------------------------+
NLPID - ISO/TR 9577 registered Network Layer Protocol Identifier.
x VALUE--データであるとサポートされたそれぞれのための1つの八重奏のNLPID(ISO/TR9577によって割り当てられるように)は議定書を作ります。 八重奏+についていいえ----------------------------+ | NLPID| 1 +----------------------------+ : : : : +----------------------------+ | NLPID| 1 +----------------------------+NLPID--ISO/TR9577はNetwork LayerプロトコルIdentifierを登録しました。
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE - TBD
x VALUE--TBD
6 Security Considerations
6 セキュリティ問題
The integrated IS-IS has a provision for carrying authentication information in all IS-IS packets. This is extensible to multiple authentication mechanisms. However, currently the only defined mechanism is a simple password, transmitted in the clear without encryption (see Annex D). The use of a simple password does not provide useful protection against intentional misbehavior. Rather, this should be thought of as a weak protection against accidental errors such as accidental mis-configuration. Definition of other authentication mechanisms is beyond the scope of this document.
統合、-、中まで認証情報を運ぶことへの支給を持っている、すべて、-、パケット これは複数の認証機構に広げることができます。しかしながら、現在の唯一の定義されたメカニズムが暗号化のない明確で伝えられた簡単なパスワード(Annex Dを見る)です。 簡単なパスワードの使用は意図的な不正行為に対する役に立つ保護を提供しません。 むしろ、これは偶然の誤構成などの偶然の誤りに対する弱い保護として考えられるべきです。 他の認証機構の定義はこのドキュメントの範囲を超えています。
Other aspects of security are not discussed in this document.
本書ではセキュリティの他の局面について議論しません。
Callon [Page 50] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[50ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
7 Author's Address
7作者のアドレス
Ross Callon
Digital Equipment Corporation
550 King Street, LKG 1-2/A19
Littleton, MA 01460-1289
508-486-5009
ロスCallon DEC550キング・ストリート、LKG1-2/A19リトルトン、MA01460-1289 508-486-5009
8 References
8つの参照箇所
[1] "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)", ISO DP 10589, February 1990.
[1] 「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Service(ISO8473)の使用のためのIntermediate System Intra-ドメインRouteing Exchangeプロトコルへの中間的System」、ISO DP10589(1990年2月)。
[2] "Protocol for Providing the Connectionless-Mode Network
Service", ISO 8473, March 1987.
[2] 「コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、ISO8473、1987年3月。
[3] "End System to Intermediate System Routeing Exchange Protocol
for Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service (ISO 8473)", ISO 9542,
March 1988.
[3]、「プロトコルに関連したコネクションレスなモードネットワーク・サービスを提供する使用の中間システムRouteing交換プロトコルへのシステムを終わらせてください、(ISO8473)、」、ISO9542(1988年3月)
[4] Braden,R., and Postel,J., "Requirements for Internet Gateways",
RFC 1009, June 1987.
1987年6月の[4] ブレーデン、R.とポステル、J.、「インターネットゲートウェイのための要件」RFC1009。
[5] Moy,J., "The OSPF Specification", RFC 1131, October 1989.
[5]Moy、J.、「OSPF仕様」、RFC1131、1989年10月。
[6] Postel,J., "Internetwork Protocol", RFC 791, September 1981.
[6] ポステル、J.、「インターネットワークプロトコル」、RFC791、1981年9月。
[7] Postel,J., "Internet Control Message Protocol", RFC 792,
September 1981.
[7] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、RFC792、1981年9月。
[8] "MIB for Use with the Extended OSI IS-IS in TCP/IP and Dual
Environments", forthcoming.
[8]、「使用のためのMIB、広げる、OSI IS存在、TCP/IPと二元的な環境、」 用意されています。
[9] GOSIP Advanced Requirements Group, "Government Open Systems
Interconnection Profile (GOSIP) Version 2.0 [Final Text]",
Federal Information Processing Standard, U.S. Department of
Commerce, National Institute of Standards and Technology,
Gaithersburg, MD, October 1990.
[9] GOSIPは要件グループ、「政府開放型システム間相互接続プロフィール(GOSIP)バージョン2.0[最終版の教科書]」、連邦情報処理基準、米国商務省を進めました、米国商務省標準技術局、ゲイザースバーグ(MD)1990年10月。
[10] "Standard for Local Area Networks and Metropolitan Area
Networks: Overview and Architecture of Network Standards",
IEEE Standard 802.1a-1990.
[10]、「ローカル・エリア・ネットワークとメトロポリタンエリアネットワークの規格:」 「ネットワーク規格の概要とアーキテクチャ」、IEEEの標準の802.1a-1990。
Callon [Page 51] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[51ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Annex A
Inter-Domain Routing Protocol Information
相互ドメインルート設定プロトコル情報を付加してください。
This annex specifies the contents and encoding of the Inter-Domain Routing Protocol Information (IDRPI) field. This annex is an integral part of the Integrated IS-IS specification. However, it is expected that this annex may be augmented or superceded by future efforts outside of the scope of the IS-IS specification.
この別館はInter-ドメインルート設定プロトコル情報(IDRPI)分野のコンテンツとコード化を指定します。 この別館がIntegratedの不可欠の部分である、-、仕様。 しかしながら、この別館が範囲の外で増大したかもしれないか、または将来の取り組みをスーパー割譲したと予想される、-、仕様
A.1 Inter-Domain Information Type
A.1相互ドメイン情報タイプ
As specified in sections 3.4 and 5.3, the IDRPI field consists of a one-octet inter-domain information type field, plus a variable external information field. This section specifies initial values for the inter-domain information type field. Other values for inter- domain information type will be assigned and maintained in future versions of the "Assigned Numbers" RFC.
セクション3.4と5.3で指定されるように、IDRPI分野は1八重奏の相互ドメイン情報タイプ分野、および可変外部の情報フィールドから成ります。 このセクションは相互ドメイン情報タイプ分野に初期の値を指定します。 相互ドメイン情報タイプのための他の値は、「規定番号」RFCの将来のバージョンで割り当てられて、維持されるでしょう。
The following types have been assigned:
以下のタイプは選任されました:
Type = 0 reserved
0が予約した=をタイプしてください。
Type = 1 local (uses routing-domain specific format)
地方で=1をタイプしてください。(経路ドメインの特定の形式を使用します)
Type = 2 AS Number Tag
数のタグとして=2をタイプしてください。
Type = 1 indicates that the inter-domain routing protocol information uses a format which is local to the routing domain.
タイプ=1は、相互ドメインルーティングプロトコル情報が経路ドメインに地方であることの形式を使用するのを示します。
Type = 2 indicates that the inter-domain routing protocol information includes autonomous system information used to tag IP external reachability information. In this case the inter-domain routing protocol information entry must include a single AS number, which is used to tag all subsequent External IP Reachability entries until the end of the LSP, or until the next occurence of the Inter-Domain Routing Protocol Information field.
タイプ=2は、相互ドメインルーティングプロトコル情報がIPの外部の可到達性情報にタグ付けをするのに使用される自律システム情報を含んでいるのを示します。 この場合、相互ドメインルーティング・プロトコル情報エントリーはただ一つのAS番号を含まなければなりません。(それは、LSPの端、またはInter-ドメインルート設定プロトコル情報分野の次のoccurenceまですべてのその後のExternal IP Reachabilityエントリーにタグ付けをするのに使用されます)。
A.2 Encoding
A.2コード化
As specified in section 5.3.5, the IDPRI entry is encoded as a variable length field, as follows:
セクション5.3.5で指定されるように、IDPRIエントリーは以下の通り可変長フィールドとしてコード化されます:
x CODE - 131
x CODE--131
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE -
x VALUE、-
Callon [Page 52] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[52ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
No. of Octets
+-------------------------------+
| Inter-Domain Information Type | 1
+-------------------------------+
| External Information | VARIABLE
+-------------------------------+
八重奏+についていいえ-------------------------------+ | 相互ドメイン情報タイプ| 1 +-------------------------------+ | 外部の情報| 変数+-------------------------------+
INTER-DOMAIN INFORMATION TYPE indicates the type of the
external information which is encoded in the field.
INTER-DOMAIN INFORMATION TYPEはその分野でコード化される外部の情報のタイプを示します。
EXTERNAL INFORMATION contains inter-domain routing protocol
information, and is passed transparently by the IS-IS protocol.
EXTERNAL INFORMATIONが相互ドメインルーティングプロトコル情報を含んでいて、透過的に無視される、-、議定書を作ってください。
The Inter-domain information type field indicates the type of information which is contained in the external information field, as follow:
Inter-ドメイン情報タイプ分野は続くとき外部の情報フィールドに保管されている情報の種類を示します:
Type = 0 is reserved (must not be sent, and must be ignored on receipt).
タイプ=0は予約されています(送られてはいけなくて、領収書の上で無視しなければなりません)。
Type = 1 indicates that the external information field contains information which follows a locally specified format.
タイプ=1は、外部の情報フィールドが局所的に指定された形式に続く情報を含むのを示します。
Type = 2 indicates that the external information field contains an autonomous system number tag, to be applied to subsequent IP external reachability information entries. In this case, this "inter-domain routing protocol information" entry must contain precisely one 2 octet AS number. The AS tag is associated with subsequent IP External Reachability entries, until the end of the LSP, or until the next occurence of the Inter-Domain Routing Protocol Information field. In this case, the VALUE contains the following:
タイプ=2は、外部の情報フィールドがその後のIP外部の可到達性情報エントリーに適用されるために自律システム数のタグを含むのを示します。 この場合、この「相互ドメインルーティングプロトコル情報」エントリーは正確に1つ2の八重奏AS番号を含まなければなりません。 ASタグはその後のIP External Reachabilityエントリー、LSPの端、またはInter-ドメインルート設定プロトコル情報分野の次のoccurenceまで関連しています。 この場合、VALUEは以下を含みます:
x VALUE -
No. of Octets
+---------------------------------+
| Inter-Domain Information Type=2 | 1
+---------------------------------+
| Autonomous System Number | 2
+---------------------------------+
x VALUE--Octets+についていいえ---------------------------------+ | 相互ドメイン情報タイプ=2| 1 +---------------------------------+ | 自律システム番号| 2 +---------------------------------+
Callon [Page 53] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[53ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Annex B
Encoding of Sequence Number Packets
一連番号パケットの別館Bコード化
The Integrated IS-IS protocol defined in this specification makes use of the ISO Draft Proposed standard for Intra-domain routing (ISO DP 10589 [1]) as the base routing protocol, upon which IP support may be added.
この仕様に基づき定義されたプロトコルはIntra-ドメインルーティングにおける、標準のISO Draft Proposedを利用します。Integrated、-、(ベースルーティング・プロトコルとしてのISO DP10589[1])。そこでは、IPサポートが加えられるかもしれません。
However, DP 10589 contains a bug regarding encoding of the variable length fields in Sequence Number Packets. In particular, DP 10589 encodes the variable length fields in SNPs in a manner which is not flexible (additional variable length fields cannot be defined for sequence number packets), and which is inconsistent with the encoding of the variable length fields in all other IS-IS and ES-IS packets.
しかしながら、DP10589はSequence Number Packetsでの可変長フィールドのコード化に関してバグを含んでいます。 特に、DP10589がフレキシブルでない、そして、(一連番号パケットのために追加可変長フィールドを定義できません)すべてでの可変長フィールドのコード化が他で矛盾した態度でSNPsの可変長フィールドをコード化する、-、ES存在、パケット。
The encoding of the variable length fields in SNPs is expected to be fixed in future versions of 10589. Also, this bug represents the only expected change to 10589 which cannot be made backward compatible with existing DP 10589 implementations. For these reasons, the current version of the Integrated IS-IS will use the anticipated future encoding of the variable length part of the SNPs. This should allow future versions of this specification to be compatible with implementations based on this specification.
10589の将来のバージョンでSNPsでの可変長フィールドのコード化が修理されると予想されます。 また、このバグは10589への後方に既存のDP10589実装と互換性があるようにすることができない唯一の予想された変更を表します。 これらの理由、Integratedの最新版、-、SNPsの可変長部分がコード化されながら、予期された未来を使用するでしょう。 これは、この仕様の将来のバージョンがこの仕様に基づく実装と互換性があるのを許容するべきです。
This annex specifies the encoding of SNPs, as amended to fix the encoding of variable length fields. This annex is an integral part of the Integrated IS-IS specification.
この別館は可変長フィールドのコード化を修理するために修正されるようにSNPsのコード化を指定します。 この別館がIntegratedの不可欠の部分である、-、仕様。
The encoding of SNPs for OSI-only use is shown in this section. For IP-only or Integrated use, the additional variable length fields specified in sections 5.3.6 through 5.3.9 are also applicable to SNPs.
OSIだけ使用のためのSNPsのコード化はこのセクションで示されます。 IPだけかIntegrated使用、分野がセクション5.3.6で指定した追加可変長、5.3、.9、また、SNPsに適切です。
Callon [Page 54] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[54ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
B.1 Level 1 Complete Sequence Numbers PDU
B.1レベル1 完全な配列数のPDU
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+--------------------------------+
| START LSP ID | 8
+--------------------------------+
| END LSP ID | 8
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+
八重奏+についていいえ--------------------------------+ | イントラドメインROUTEING| 1 | プロトコル識別子| +--------------------------------+ | 長さのインディケータ| 1 +--------------------------------+ | バージョン/プロトコルID EXT| 1 +--------------------------------+ | 予約されます。| 1 +--------------------------------+ | R| R| R| タイプ| 1 +--------------------------------+ | バージョン| 1 +--------------------------------+ | エコ| 1 +--------------------------------+ | ユーザエコ| 1 +--------------------------------+ | PDUの長さ| 2 +--------------------------------+ | ソースID| 7 +--------------------------------+ | LSP IDを始めてください。| 8 +--------------------------------+ | 終わりのLSP ID| 8 +================================+==================== | 可変長フィールド| 変数+--------------------------------+
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR--建築定数
- LENGTH INDICATOR - Header Length in octets (33.)
- LENGTH INDICATOR--八重奏におけるヘッダーLength(33.)
- VERSION/PROTOCOL ID EXTENSION - 1
- バージョン/プロトコルID拡大--1
- RESERVED - transmitted as 0, ignored on receipt
- RESERVED--領収書の上で無視された0として、伝えられます。
- TYPE (bits 1 through 5) - 24. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- (ビット1〜5)をタイプしてください--24。 注意ビット6、7、および8はReservedです。(そのReservedは、それらが0として伝えられて、領収書の上で無視されることを意味します)。
- VERSION - 1
- バージョン--1
- ECO - transmitted as zero, ignored on receipt
- ECO--領収書の上で無視されたゼロとして、伝えられます。
Callon [Page 55] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[55ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
- USER ECO - transmitted as zero, ignored on receipt
- USER ECO--領収書の上で無視されたゼロとして、伝えられます。
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- PDU LENGTH--ヘッダーを含む八重奏におけるこのPDUの全体のLength
- SOURCE ID - 7 octet ID of Intermediate System (with zero Circuit ID) generating this Sequence Numbers PDU.
- SOURCE ID--7 このSequence民数記PDUを生成するIntermediate System(Circuit IDでない)の八重奏ID。
- START LSP ID - 8 octet ID of first LSP in the range covered by this Complete Sequence Numbers PDU.
- START LSP ID--8 最初に、このComplete Sequence民数記PDUでカバーされた範囲のLSPの八重奏ID。
- END LSP ID - 8 octet ID of last LSP in the range covered by this Complete Sequence Numbers PDU.
- END LSP ID--8 このComplete Sequence民数記PDUでカバーされた範囲の最後のLSPの八重奏ID。
- VARIABLE LENGTH FIELDS - fields of the form:
- VARIABLE LENGTH FIELDS--フォームの分野:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
八重奏+についていいえ--------------------------------+ | コード| 1 +--------------------------------+ | 長さ| 1 +--------------------------------+ | 値| 長さ+--------------------------------+
Any codes in a received CSNP that are not recognised are ignored.
容認されたCSNPの認識されない少しのコードも無視されます。
Currently defined codes are:
現在定義されたコードは以下の通りです。
7 LSP Entries -- This may appear multiple times. The option fields,
if they appear more than once, shall appear sorted into ascending
LSPID order.
7LSP Entries--これは複数の回現れるかもしれません。 一度より多く見えるなら、オプション・フィールドはLSPIDが命令する上昇に分類されているように見えるものとします。
x CODE - 9
x CODE--9
x LENGTH - total length of the value field.
x LENGTH--値の分野の全長。
x VALUE - a list of LSP entries of the form:
x VALUE--形式のLSPエントリーのリスト:
Callon [Page 56] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[56ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
八重奏+についていいえ--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+ : : : : +--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
残っている生涯--LSPの7の残っている生涯。
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP ID--8 このエントリーが参照されるLSPの八重奏ID。
7 LSP SEQ NUMBER - Sequence number of LSP.
7 LSP SEQ NUMBER--LSPの一連番号。
7 CHECKSUM - Checksum reported in LSP.
7 CHECKSUM--チェックサムはLSPで報告しました。
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet).
エントリーはLSPIDが命令する上昇に分類されるものとします(LSPIDのLSP数の八重奏は最も重要でない八重奏です)。
Callon [Page 57] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[57ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
B.2 Level 2 Complete Sequence Numbers PDU
B.2レベル2 完全な配列数のPDU
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+--------------------------------+
| START LSP ID | 8
+--------------------------------+
| END LSP ID | 8
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+
八重奏+についていいえ--------------------------------+ | イントラドメインROUTEING| 1 | プロトコル識別子| +--------------------------------+ | 長さのインディケータ| 1 +--------------------------------+ | バージョン/プロトコルID EXT| 1 +--------------------------------+ | 予約されます。| 1 +--------------------------------+ | R| R| R| タイプ| 1 +--------------------------------+ | バージョン| 1 +--------------------------------+ | エコ| 1 +--------------------------------+ | ユーザエコ| 1 +--------------------------------+ | PDUの長さ| 2 +--------------------------------+ | ソースID| 7 +--------------------------------+ | LSP IDを始めてください。| 8 +--------------------------------+ | 終わりのLSP ID| 8 +================================+==================== | 可変長フィールド| 変数+--------------------------------+
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR--建築定数
- LENGTH INDICATOR - Header Length in octets (33.)
- LENGTH INDICATOR--八重奏におけるヘッダーLength(33.)
- VERSION/PROTOCOL ID EXTENSION - 1
- バージョン/プロトコルID拡大--1
- RESERVED - transmitted as 0, ignored on receipt
- RESERVED--領収書の上で無視された0として、伝えられます。
- TYPE (bits 1 through 5) - 25. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- (ビット1〜5)をタイプしてください--25。 注意ビット6、7、および8はReservedです。(そのReservedは、それらが0として伝えられて、領収書の上で無視されることを意味します)。
- VERSION - 1
- バージョン--1
- ECO - transmitted as zero, ignored on receipt
- ECO--領収書の上で無視されたゼロとして、伝えられます。
Callon [Page 58] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[58ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
- USER ECO - transmitted as zero, ignored on receipt
- USER ECO--領収書の上で無視されたゼロとして、伝えられます。
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- PDU LENGTH--ヘッダーを含む八重奏におけるこのPDUの全体のLength
- SOURCE ID - 7 octet ID of Intermediate System (with zero Circuit ID) generating this Sequence Numbers PDU.
- SOURCE ID--7 このSequence民数記PDUを発生させるIntermediate System(Circuit IDでない)の八重奏ID。
- START LSP ID - 8 octet ID of first LSP in the range covered by this Complete Sequence Numbers PDU.
- START LSP ID--8 最初に、このComplete Sequence民数記PDUでカバーされた範囲のLSPの八重奏ID。
- END LSP ID - 8 octet ID of last LSP in the range covered by this Complete Sequence Numbers PDU.
- END LSP ID--8 このComplete Sequence民数記PDUでカバーされた範囲の最後のLSPの八重奏ID。
- VARIABLE LENGTH FIELDS - fields of the form:
- VARIABLE LENGTH FIELDS--フォームの分野:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
八重奏+についていいえ--------------------------------+ | コード| 1 +--------------------------------+ | 長さ| 1 +--------------------------------+ | 値| 長さ+--------------------------------+
Any codes in a received CSNP that are not recognised are ignored.
容認されたCSNPの認識されない少しのコードも無視されます。
Currently defined codes are:
現在定義されたコードは以下の通りです。
7 LSP Entries -- this may appear multiple times. The option fields, if they appear more than once, shall appear sorted into ascending LSPID order.
7LSP Entries--これは複数の回現れるかもしれません。 一度より多く見えるなら、オプション・フィールドはLSPIDが命令する上昇に分類されているように見えるものとします。
x CODE - 9
x CODE--9
x LENGTH - total length of the value field.
x LENGTH--値の分野の全長。
x VALUE - a list of LSP entries of the form:
x VALUE--形式のLSPエントリーのリスト:
Callon [Page 59] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[59ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
八重奏+についていいえ--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+ : : : : +--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
残っている生涯--LSPの7の残っている生涯。
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP ID--8 このエントリーが参照されるLSPの八重奏ID。
7 LSP SEQ NUMBER - Sequence number of LSP.
7 LSP SEQ NUMBER--LSPの一連番号。
7 CHECKSUM - Checksum reported in LSP.
7 CHECKSUM--チェックサムはLSPで報告しました。
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet).
エントリーはLSPIDが命令する上昇に分類されるものとします(LSPIDのLSP数の八重奏は最も重要でない八重奏です)。
Callon [Page 60] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[60ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
B.3 Level 1 Partial Sequence Numbers PDU
B.3レベル1 部分的な一連番号PDU
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+
八重奏+についていいえ--------------------------------+ | イントラドメインROUTEING| 1 | プロトコル識別子| +--------------------------------+ | 長さのインディケータ| 1 +--------------------------------+ | バージョン/プロトコルID EXT| 1 +--------------------------------+ | 予約されます。| 1 +--------------------------------+ | R| R| R| タイプ| 1 +--------------------------------+ | バージョン| 1 +--------------------------------+ | エコ| 1 +--------------------------------+ | ユーザエコ| 1 +--------------------------------+ | PDUの長さ| 2 +--------------------------------+ | ソースID| 7 +================================+==================== | 可変長フィールド| 変数+--------------------------------+
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR--建築定数
- LENGTH INDICATOR - Header Length in octets (17.)
- LENGTH INDICATOR--八重奏におけるヘッダーLength(17.)
- VERSION/PROTOCOL ID EXTENSION - 1
- バージョン/プロトコルID拡大--1
- RESERVED - transmitted as 0, ignored on receipt
- RESERVED--領収書の上で無視された0として、伝えられます。
- TYPE (bits 1 through 5) 26. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- 26をタイプしてください(ビット1〜5)。 注意ビット6、7、および8はReservedです。(そのReservedは、それらが0として伝えられて、領収書の上で無視されることを意味します)。
- VERSION - 1
- バージョン--1
- ECO - transmitted as zero, ignored on receipt
- ECO--領収書の上で無視されたゼロとして、伝えられます。
- USER ECO - transmitted as zero, ignored on receipt
- USER ECO--領収書の上で無視されたゼロとして、伝えられます。
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- PDU LENGTH--ヘッダーを含む八重奏におけるこのPDUの全体のLength
- SOURCE ID - 7 octet ID of Intermediate system (with zero Circuit ID)
- SOURCE ID--Intermediateシステムの7八重奏ID(Circuit IDでない)
Callon [Page 61] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[61ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
generating this Sequence Numbers PDU.
このSequence民数記PDUを発生させます。
- VARIABLE LENGTH FIELDS - fields of the form:
- VARIABLE LENGTH FIELDS--フォームの分野:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
八重奏+についていいえ--------------------------------+ | コード| 1 +--------------------------------+ | 長さ| 1 +--------------------------------+ | 値| 長さ+--------------------------------+
Any codes in a received PSNP that are not recognised are ignored.
容認されたPSNPの認識されない少しのコードも無視されます。
Currently defined codes are:
現在定義されたコードは以下の通りです。
7 LSP Entries - this may appear multiple times. The option fields, if they appear more than once, shall appear sorted into ascending LSPID order.
7LSP Entries--これは複数の回現れるかもしれません。 一度より多く見えるなら、オプション・フィールドはLSPIDが命令する上昇に分類されているように見えるものとします。
x CODE - 9
x CODE--9
x LENGTH - total length of the value field.
x LENGTH--値の分野の全長。
Callon [Page 62] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[62ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
x VALUE - a list of LSP entries of the form:
x VALUE--形式のLSPエントリーのリスト:
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
八重奏+についていいえ--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+ : : : : +--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
残っている生涯--LSPの7の残っている生涯。
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP ID--8 このエントリーが参照されるLSPの八重奏ID。
7 LSP SEQ NUMBER - Sequence number of LSP.
7 LSP SEQ NUMBER--LSPの一連番号。
7 CHECKSUM - Checksum reported in LSP.
7 CHECKSUM--チェックサムはLSPで報告しました。
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet).
エントリーはLSPIDが命令する上昇に分類されるものとします(LSPIDのLSP数の八重奏は最も重要でない八重奏です)。
Callon [Page 63] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[63ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
B.4 Level 2 Partial Sequence Numbers PDU
B.4レベル2 部分的な一連番号PDU
No. of Octets
+--------------------------------+
| INTRA-DOMAIN ROUTEING | 1
| PROTOCOL DISCRIMINATOR |
+--------------------------------+
| LENGTH INDICATOR | 1
+--------------------------------+
| VERSION/PROTOCOL ID EXT | 1
+--------------------------------+
| RESERVED | 1
+--------------------------------+
| R | R | R | TYPE | 1
+--------------------------------+
| VERSION | 1
+--------------------------------+
| ECO | 1
+--------------------------------+
| USER ECO | 1
+--------------------------------+
| PDU LENGTH | 2
+--------------------------------+
| SOURCE ID | 7
+================================+====================
| VARIABLE LENGTH FIELDS | VARIABLE
+--------------------------------+
八重奏+についていいえ--------------------------------+ | イントラドメインROUTEING| 1 | プロトコル識別子| +--------------------------------+ | 長さのインディケータ| 1 +--------------------------------+ | バージョン/プロトコルID EXT| 1 +--------------------------------+ | 予約されます。| 1 +--------------------------------+ | R| R| R| タイプ| 1 +--------------------------------+ | バージョン| 1 +--------------------------------+ | エコ| 1 +--------------------------------+ | ユーザエコ| 1 +--------------------------------+ | PDUの長さ| 2 +--------------------------------+ | ソースID| 7 +================================+==================== | 可変長フィールド| 変数+--------------------------------+
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR - architectural constant
- INTRADOMAIN ROUTEING PROTOCOL DISCRIMINATOR--建築定数
- LENGTH INDICATOR - Header Length in octets (17.)
- LENGTH INDICATOR--八重奏におけるヘッダーLength(17.)
- VERSION/PROTOCOL ID EXTENSION - 1
- バージョン/プロトコルID拡大--1
- RESERVED - transmitted as 0, ignored on receipt
- RESERVED--領収書の上で無視された0として、伝えられます。
- TYPE (bits 1 through 5) - 27. Note bits 6, 7 and 8 are Reserved, which means they are transmitted as 0 and ignored on receipt.
- (ビット1〜5)をタイプしてください--27。 注意ビット6、7、および8はReservedです。(そのReservedは、それらが0として伝えられて、領収書の上で無視されることを意味します)。
- VERSION - 1
- バージョン--1
- ECO - transmitted as zero, ignored on receipt
- ECO--領収書の上で無視されたゼロとして、伝えられます。
- USER ECO - transmitted as zero, ignored on receipt
- USER ECO--領収書の上で無視されたゼロとして、伝えられます。
- PDU LENGTH - Entire Length of this PDU, in octets, including header
- PDU LENGTH--ヘッダーを含む八重奏におけるこのPDUの全体のLength
- SOURCE ID - 7 octet ID of Intermediate system (with zero Circuit ID)
- SOURCE ID--Intermediateシステムの7八重奏ID(Circuit IDでない)
Callon [Page 64] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[64ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
generating this Sequence Numbers PDU.
このSequence民数記PDUを発生させます。
- VARIABLE LENGTH FIELDS - fields of the form:
- VARIABLE LENGTH FIELDS--フォームの分野:
No. of Octets
+--------------------------------+
| CODE | 1
+--------------------------------+
| LENGTH | 1
+--------------------------------+
| VALUE | LENGTH
+--------------------------------+
八重奏+についていいえ--------------------------------+ | コード| 1 +--------------------------------+ | 長さ| 1 +--------------------------------+ | 値| 長さ+--------------------------------+
Any codes in a received PSNP that are not recognised are ignored.
容認されたPSNPの認識されない少しのコードも無視されます。
Currently defined codes are:
現在定義されたコードは以下の通りです。
7 LSP Entries -- this may appear multiple times. The option fields, if they appear more than once, shall appear sorted into ascending LSPID order.
7LSP Entries--これは複数の回現れるかもしれません。 一度より多く見えるなら、オプション・フィールドはLSPIDが命令する上昇に分類されているように見えるものとします。
x CODE - 9
x CODE--9
x LENGTH - total length of the value field.
x LENGTH--値の分野の全長。
x VALUE - a list of LSP entries of the form:
x VALUE--形式のLSPエントリーのリスト:
Callon [Page 65] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[65ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
No. of Octets
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
: :
: :
+--------------------------------+
| REMAINING LIFETIME | 2
+--------------------------------+
| LSP ID | 8
+--------------------------------+
| LSP SEQ NUMBER | 4
+--------------------------------+
| CHECKSUM | 2
+--------------------------------+
八重奏+についていいえ--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+ : : : : +--------------------------------+ | 残っている生涯| 2 +--------------------------------+ | LSP ID| 8 +--------------------------------+ | LSP SEQ番号| 4 +--------------------------------+ | チェックサム| 2 +--------------------------------+
7 REMAINING LIFETIME - Remaining Lifetime of LSP.
残っている生涯--LSPの7の残っている生涯。
7 LSP ID - 8 octet ID of the LSP to which this entry refers.
7 LSP ID--8 このエントリーが参照されるLSPの八重奏ID。
7 LSP SEQ NUMBER -Sequence number of LSP.
7 LSPのLSP SEQ NUMBER一連番号。
7 CHECKSUM - Checksum reported in LSP.
7 CHECKSUM--チェックサムはLSPで報告しました。
The entries shall be sorted into ascending LSPID order (the LSP number octet of the LSPID is the least significant octet).
エントリーはLSPIDが命令する上昇に分類されるものとします(LSPIDのLSP数の八重奏は最も重要でない八重奏です)。
Callon [Page 66] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[66ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Annex C
Dijkstra Calculation and Forwarding
別館Cダイクストラの計算と推進
Annex C.2 of ISO DP 10589 [1] specifies the SPF (Dikskstra) algorithm for calculating routes with the IS-IS routing protocol. This annex specifies modifications to the SPF algorithm for supporting IP and dual routing, and specifies a compatible method for forwarding IP packets. This will result in an order of preference of routes which is compatible with that specified in section 3.10.
ISO DP10589[1]の別館C.2が計算のルートへのSPF(Dikskstra)アルゴリズムを指定する、-、ルーティング・プロトコル この別館は、IPと二元的なルーティングを支持するのにSPFアルゴリズムへの変更を指定して、推進IPパケットにコンパチブル方法を指定します。 これはルートのセクション3.10で指定されるそれと互換性があるよく使われる順をもたらすでしょう。
This annex is included for informational purposes.
この別館は情報の目的のために含まれています。
C.1 SPF Algorithm for IP and Dual Use
IPのためのC.1 SPFアルゴリズムと二元的な使用
This section specifies an SPF Algorithm for calculating routes with the IS-IS routing protocol, for support of both TCP/IP and OSI. This is based on an extention to the algorithm specified in annex C.2 of ISO DP 10589 [1].
このセクションが計算のルートへのSPF Algorithmを指定する、-、ルーティング・プロトコル、TCP/IPとOSIの両方のサポートのために。 これはISO DP10589[1]の別館C.2で指定されたアルゴリズムへのextentionに基づいています。
An algorithm invented by Dijkstra known as shortest path first (SPF) is used as the basis for the route calculation. It has a computational complexity of the square of the number of nodes, which can be decreased to the number of links in the domain times the log of the number of nodes for sparse networks (networks which are not highly connected).
最初に最短パスとして知られていた状態でダイクストラによって発明されたアルゴリズム(SPF)はルート計算の基礎として使用されます。 それには、ノードの数の二乗の計算量があります、ドメイン回のリンクの数と減少できるもの。まばらなネットワーク(非常に接続されないネットワーク)のためのノードの数に関するログ。
A number of additional optimizations are possible:
多くの追加最適化が可能です:
1) If the routing metric is defined over a small finite field (as in
this standard), the factor of log n may be removed by using data
structures which maintain a separate list of systems for each value
of the metric rather than sorting the systems by logical distance.
1) ルーティング、メートル法であることは、小さい有限分野(この規格のように)にわたって定義されています、ログnの要素が論理的な距離に従ってソーティングよりむしろメートル法のそれぞれの値のシステムの別々のリストがシステムであることを支持するデータ構造を使用することによって取り除かれるかもしれないということです。
2) Updates can be performed incrementally without requiring a complete
recalculation. However, a full update must be done periodically to
ensure recovery from data corruption, and studies suggest that with
a very small number of link changes (perhaps 2) the expected
computation complexity of the incremental update exceeds the
complete recalculation. Thus, this annex specifies the algorithm
only for the full update.
2) 完全な再計算を必要としないで、アップデートを増加して実行できます。 しかしながら、データの汚染からの回復を確実にするために定期的に完全なアップデートを終わらなければなりません、そして、研究は非常に少ない数のリンク変化(恐らく2)に応じて、アップデート増加の予想された計算の複雑さが完全な再計算を超えているのを示します。 したがって、この別館は完全なアップデートのためだけのアルゴリズムを指定します。
3) If only End System LSP information has changed, it is not necessary
to re-compute the entire Dijkstra tree. If the proper data
structures are used, End Systems (including IP reachability
entries) may be attached and detached as leaves of the tree and
their forwarding information base entries altered as appropriate.
3) End System LSP情報だけが変化したなら、全体のダイクストラ木を再計算するのは必要ではありません。 適切なデータ構造が使用されているなら、木の葉と彼らの推進情報ベースエントリーが適宜変わったので、End Systems(IP可到達性エントリーを含んでいる)は取り付けられて、取り外されるかもしれません。
The original SPF algorithm does not support load splitting over
オリジナルのSPFアルゴリズムはサポート負荷の分かれないことをやり直します。
Callon [Page 67] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[67ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
multiple paths. The algorithm in this annex does permit load splitting by identifying a set of equal cost paths to each destination rather than a single least cost path.
複数の経路。 この別館のアルゴリズムは、ただ一つの最小費用経路よりむしろ各目的地に1セットの等しい費用経路を特定することによって、負荷の分かれることを可能にします。
C.1.1 Databases
C.1.1データベース
PATHS -- This represents an acyclic directed graph of shortest paths
from the system S performing the calculation. It is stored as a set
of triples of the form <N,d(N),{Adj(N)}>, where:
PATHS--これは、計算を実行しながら、システムSから最短パスの非循環の有向グラフを表します。 それがフォーム<Nの三重、d(N)の1セットとして格納されて、Adj(N)が>である、どこ:
N is a system identifier. In the level 1 algorithm, N is a
6 octet ID for OSI end systems, a 7 octet ID for routers, or
an 8 octet IP Internal Reachability Information entry. For a
router which is not a pseudonode, it is the 6 octet system ID,
with a 0 appended octet. For a pseudonode it is a true 7 octet
quantity, comprised of the 6 octet Designated Intermediate
System ID and the extra octet assigned by the Destinated Router.
The IP Internal Reachability Information entries consist of a
4 octet IP address plus a 4 octet subnet mask, and will always
be a leaf, i.e., "End System" in PATHS.
Nはシステム識別子です。 平らな1つのアルゴリズムで、Nは、OSIエンドシステムのための6八重奏ID、ルータのための7八重奏ID、または8八重奏IP Internal Reachability情報エントリーです。 pseudonodeでないルータのために、それは0の追加された八重奏がある6八重奏システムIDです。 pseudonodeに関しては、それはDesignated Intermediate System IDと余分な八重奏がDestinated Routerで割り当てた6八重奏から成る真の7八重奏量です。 IP Internal Reachability情報エントリーは、4八重奏IPアドレスと4八重奏サブネットマスクから成って、いつも葉、すなわち、PATHSの「エンドシステム」でしょう。
In the level 2 algorithm, N is either a 7 octet router or
pseudonode ID (as in the level 1 algorithm); a variable
length OSI address prefix; an 8 octet IP Internal Reachability
Information Entry, or an 8 octet IP External Reachability
Information entry. The variable length OSI address prefixes,
and 8 octet IP Reachability Information entries will always
be a leaf, i.e., "End System" in PATHS. As above, the IP
Reachability Information entries consist of an [IP address,
subnet mask] combination.
平らな2アルゴリズムで、Nは、7八重奏ルータかpseudonode ID(平らな1つのアルゴリズムのように)のどちらかです。 可変長OSIアドレス接頭語。 8八重奏IP Internal Reachability情報Entry、または8八重奏IP External Reachability情報エントリー。 可変長OSIは接頭語を記述します、そして、いつも8つの八重奏IP Reachability情報エントリーが葉、すなわち、PATHSの「エンドシステム」でしょう。 同じくらい上では、IP Reachability情報エントリーが[IPアドレス、サブネットマスク]組み合わせから成ります。
d(N) is N's distance from S (i.e., the total metric value
from N to S).
d(N)はS(すなわち、総NからSまでのメートル法の数値)からのNの距離です。
{Adj(N)} is a set of valid adjacencies that S may use for
forwarding to N.
Adj(N)はSが推進にNに使用するかもしれない1セットの有効な隣接番組です。
When a system is placed on PATHS, the path(s) designated by its position in the graph is guaranteed to be a shortest path.
システムがPATHSに関して課されるとき、グラフによる位置によって指定された経路は、最短パスになるように保証されます。
TENT -- This is a list of triples of the form <N,d(N),{Adj(N)}>,
where N, d(N), and {Adj(N)} are as defined above for PATHS.
TENT--d(N)、これはフォーム<Nの三重のリストであり、Adj(N)は>です、N、d(N)、およびAdj(N)がPATHSのために上で定義されるようにあるところで。
TENT can intuitively be thought of as a tentative placement
of a system in PATHS. In other words, the triple <N,x,{A}>
in TENT means that if N were placed in PATHS, d(N) would be x,
but N cannot be placed on PATHS until is is guaranteed that
no path shorter than x exists.
PATHSのシステムの一時的なプレースメントとしてTENTを直観的に考えることができます。 言い換えれば、三重の<N、x、TENTの>がNがPATHSに置かれるなら、d(N)がxですが、NをPATHSに置くことができないことを意味する、xより短いどんな経路も存在しないのが保証されます。
Callon [Page 68] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[68ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Similarly, the triple <N,x,{A,B}> in TENT means that if N
were placed in PATHS, then d(N) would be x via either
adjacency A or B.
<N、x、A、Bを3倍にしてください。同様である、TENTの>は、NがPATHSに置かれるならd(N)が隣接番組AかBのどちらかを通したxであることを意味します。
Note: It is suggested that the implementation maintain the database TENT as a set of list of triples of the form <*,Dist,*>, sorted by distance Dist. In addition, it is necessary to be able to process those systems which are pseudonodes before any non-pseudonodes at the same distance Dist.
以下に注意してください。 実現がフォーム<*の三重のリスト、Distの1セットとしてのTENT(*>)が距離Distで分類したデータベースを維持することが提案されます。 さらに、同じくらいのどんな非pseudonodesもDistを遠ざける前にpseudonodesであるそれらのシステムは処理できるのが必要です。
The 8 octet system identifiers which specify IP reachability entries must always be distinguishable from other system identifiers. As specified in section 3.10, two IP reachability entries which differ only in the subnet mask are still considered to be separate, and will therefore have distinct system identifiers N. The SPF algorithm will therefore calculate routes to each such entry, and the correct entry will be selected in the forwarding process.
IP可到達性エントリーを指定する8つの八重奏システム識別子が他のシステム識別子からいつも区別可能であるに違いありません。 サブネットマスクだけにおいて異なるIP可到達性エントリーは、セクション3.10、twoで指定されるように別々であるとまだ考えられていて、したがって、異なったシステム識別子N.を持つでしょう。したがって、SPFアルゴリズムはそのような各エントリーにルートを計算するでしょう、そして、正しいエントリーは推進の過程で選択されるでしょう。
C.1.2 Use of Metrics in the SPF Algorithm
SPFアルゴリズムにおける測定基準のC.1.2使用
Internal metrics are not comparable to external metrics. For external routes (routes to destinations outside of the routing domain), the cost d(N) of the path from N to S may include both internal and external metrics. d(N) may therefore be maintained as a two- dimensioned vector quantity (specifying internal and external metric values).
内部の測定基準は外部の測定基準に匹敵していません。 外部経路(経路ドメインの外部を目的地に発送する)に、NからSまでの経路の費用d(N)は内部の、そして、外部の両方の測定基準を含めるかもしれません。したがって、d(N)は2のdimensionedベクトル量として維持されるかもしれません(内部の、そして、外部のメートル法の数値を指定して)。
d(N) is initialized to [internal metric = 0, external metric = 0].
d(N)は[内部のメートル法の=0、外部のメートル法の=0]に初期化されます。
In incrementing d(N) by 1, if the internal metric value is less than the maximum value MaxPathMetric, then the internal metric value is incremented by one and the external metric value left unchanged; if the internal metric value is equal to the maximum value MaxPathMetric, then the internal metric value is set to 0 and the external metric value is incremented by 1. Note that this can be implemented in a straightforward manner by maintaining the external metric as the high order bits of the distance.
d(N)を1つ増加する際に、内部のメートル法の数値は内部のメートル法の数値が最大値MaxPathMetric以下であるなら1と変わりがない状態で残っている外部のメートル法の数値によって増加されます。 内部のメートル法の数値が最大値MaxPathMetricと等しいなら、内部のメートル法の数値は0に設定されます、そして、外部のメートル法の数値は1つ増加されます。 距離の高位のビットとしてメートル法に外部を維持することによって正直な態度でこれを実行できることに注意してください。
In the code of the algorithm below, the current path length is held in the variable "tentlength". This variable is a two-dimensional quantity tentlength=[internal metric, external metric], and is used for comparing the current path length with d(N) as described above. Tentlength is incremented in the same manner as d(N).
以下のアルゴリズムのコードでは、現在の経路の長さは可変"tentlength"に保持されます。 この変数は、二次元量のtentlength=[インターナルメートル法の、そして、外部メートル法の]であり、上で説明されるように現在の経路の長さをd(N)と比べるのに使用されます。 Tentlengthはd(N)と同じ方法で増加されます。
C.1.3 Overview of the Algorithm
アルゴリズムのC.1.3概観
The basic algorithm, which builds PATHS from scratch, starts out by putting the system doing the computation on PATHS (no shorter path to
基本的なアルゴリズム(最初から、PATHSを造る)がPATHSで計算しながらシステムを置きながら始める、(より短い経路がありません。
Callon [Page 69] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[69ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
SELF can possibly exist). TENT is then pre-loaded from the local adjacency database.
SELFが存在できる、) そして、TENTはローカルの隣接番組データベースからプレロードされます。
Note that a system is not placed on PATHS unless no shorter path to that system exists. When a system N is placed on PATHS, the path to each neighbor M of N, through N, is examined, as the path to N plus the link from N to M. If <M,*,*> is in PATHS, this new path will be longer, and thus ignored.
そのシステムへの、より短い経路がないのが存在していない場合システムがPATHSに関して課されないことに注意してください。 **システムNがPATHSに関して課されるとき、Nの各隣人Mへの経路はNを通して調べられます、NからM.If<MへのNへの経路とリンクとして>がPATHSにあって、この新しい経路は、より長く、このようにして無視されるでしょう。
If <M,*,*> is in TENT, and the new path is shorter, the old entry is
removed from TENT and the new path is placed in TENT. If the new path
is the same length as the one in TENT, then the set of potential
adjacencies {Adj(M)} is set to the union of the old set (in TENT) and
the new set {Adj(N)}. If M is not in TENT, then the path is added to
TENT.
**<M、>がTENTにあって、新しい経路が、より短いなら、古いエントリーはTENTから移されます、そして、新しい経路はTENTに置かれます。 新しい経路がTENTのものと同じ長さであるなら、潜在的隣接番組Adj(M)のセットは古いセット(TENTの)と新しいセットAdj(N)の組合に設定されます。 MがTENTにないなら、経路はTENTに加えられます。
Next the algorithm finds the triple <N,x,{Adj(N)}> in TENT, with
minimal x. Note: This is done efficiently because of the optimization
described above. When the list of triples for distance Dist is
exhausted, the algorithm then increments Dist until it finds a list
with a triple of the form <*,Dist,*>.
次に、アルゴリズムによって、TENTで最小量のxで三重の<N、x、Adj(N)が>であることがわかります。 以下に注意してください。 上で説明された最適化のために効率的にこれをします。 距離Distのための三重のリストが空になると、フォーム<*の三重でリストを見つけるまで、アルゴリズムはDistを増加します、Dist、*>。
N is placed in PATHS. We know that no path to N can be shorter than x at this point because all paths through systems already in PATHS have already been considered, and paths through systems in TENT still have to be greater than x because x is minimal in TENT.
NはPATHSに置かれます。 私たちは、Nへのどんな経路も既にPATHSのシステムを通したすべての経路が既に考えられて、TENTのシステムを通した経路がまだ考えられているのでxがTENTで最小限のでxよりすばらしくなるようにここのxより短いはずがないのを知っています。
When TENT is empty, PATHS is complete.
TENTが空であるときに、PATHSは完全です。
Note that external metrics can only occur in "IP External Reachability Information" entries, which correspond to a leaf (i.e., End System in PATHS). Any route utilizing an entry with an external metric will always be considered to be less desireable than any entry which uses an internal metric. This implies that in the addition of systems to PATHS, all systems reachable via internal routes are always added before any system reachable via external routes.
外部の測定基準が「IPの外部の可到達性情報」エントリーに起こることができるだけであることに注意してください。(エントリーは葉(すなわち、PATHSのEnd System)に対応します)。 外部がメートル法でエントリーを利用するどんなルートもメートル法でインターナルを使用するどんなエントリーよりも少ない「望-可能」であるといつも考えられるでしょう。 これは、PATHSへのシステムの添加では、内部のルートを通して届いているすべてのシステムが外部経路を通して届いているどんなシステムの前でもいつも加えられるのを含意します。
C.1.4 The Algorithm
C.1.4アルゴリズム
The Decision Process Algorithm must be run once for each supported routing metric (i.e., for each supported Type of Service). A level 1 router runs the algorithm using the level 1 LSP database to compute level 1 paths (for those level 1 routers which are not level 2 routers, this includes the path to the nearest attached level 2 router). Level 2 routers also separately run the algorithm using the level 2 LSP database to compute level 2 paths. IP-capable level 2 routers must keep level 2 internal IP routes separate from level 2 external IP routes.
Decision Process Algorithmをそれぞれが、掘るのをメートル法で支持した一度走らせなければなりません(すなわち、それぞれがServiceのTypeを支持したので)。 A級試験1ルータは、レベル1 経路を計算するのに1つの平らなLSPデータベースを使用することでアルゴリズムを走らせます(レベル2 ルータでないそれらの平らな1ルータのために、これは最も近い付属平らな2ルータに経路を含めます)。 レベル2 また、ルータは、別々にレベル2 経路を計算するのに平らな2LSPデータベースを使用することでアルゴリズムを走らせます。 IPできるレベル2 ルータは、レベル2がレベル2 外部のIPルートから別々の内部のIPルートであることを保たなければなりません。
Callon [Page 70] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[70ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Note that this implies that routers which are both level 1 and level 2 routers, and which support all four routing metrics, must run the SPF algorithm 8 times (assuming partition repair is not implemented).
これが、レベル2 レベル1とルータの両方であり、すべての4つのルーティング測定基準をサポートするルータがSPFアルゴリズムを8回走らせなければならないのを含意することに注意してください(パーティションが修理であると仮定するのは実行されません)。
If this system is a Level 2 Router which supports the partition repair optional function the Decision Process algorithm for computing Level 1 paths must be run twice for the default metric. This first execution is done to determine which of the area's manualAreaAddresses are reachable in this partition, and to elect a Partition Designated Level 2 Router for the partition. The partition Designated Level 2 Router will determine if the area is partitioned and will create virtual Level 1 links to the other Partition Designated Level 2 Routers in the area in order to repair the Level 1 partition. This is further described in section 7.2.10 of [1].
このシステムがパーティション修理任意の機能をサポートするLevel2Routerであるなら、デフォルトのためにメートル法でLevel1経路を計算するためのDecision Processアルゴリズムを二度走らせなければなりません。 この最初の威力は、領域のmanualAreaAddressesのどれがこのパーティションで届いているかを決定して、パーティションのためにPartition Designated Level2Routerを選ぶために発揮されます。 領域が仕切られて、仮想のLevel1を作成するなら、Designated Level2Routerが決定するパーティションは、Level1パーティションを修理するためにその領域の2Routersをもう片方のPartition Designated Levelにリンクします。 これは[1]についてセクション7.2.10でさらに説明されます。
The SPF algorithm specified here will calculate routes for both OSI and IP. In particular, routes are calculated to all system identifiers N, where N may specify an OSI End System, the OSI address of a router, or an IP reachability entry. In computing the forwarding database, it is an implementation specific issue whether the IP forwarding database is kept separately from the OSI forwarding database. Where appropriate, this annex will refer separately to entries in these two forwarding data bases. This is not meant to preclude any specific implementation method.
ここで指定されたSPFアルゴリズムはOSIとIPの両方のためにルートを計算するでしょう。 特に、ルートはすべてのシステム識別子Nに計算されます。そこでは、NがOSI End System、ルータのOSIアドレス、またはIP可到達性エントリーを指定するかもしれません。 推進データベースを計算するのにおいて、IP推進データベースが別々にOSI推進データベースから妨げられるか否かに関係なく、それは実現の特定の問題です。 適切であるところに、この別館は別々にこれらの2つの推進データベースの中でエントリーについて言及するでしょう。 これは少しの特定の実現方法も排除することになっていません。
OSI and IP use separate mechanisms to determine whether a packet is in the area (in particular, OSI makes use of area addresses, and IP determines that a destination is not in an area by looking in the level 1 forwarding database and determining that no entry exists for that destination within the area). The route to the nearest level 2 router will result in separate entries in the forwarding database for OSI and IP. For IP, the route to the nearest attached level 2 router may be entered in the forwarding database as a default route (i.e., a route with a subnet mask of all 0).
OSIとIPは、パケットがその領域にあるかを(特に、OSIが領域アドレスを利用します、そして、IPは目的地が領域にデータベースを転送して、エントリーが全く領域の中のその目的地に存在しないことを決定しながらレベル1の中を見ることによってないことを決定します)決定するのに別々のメカニズムを使用します。 最も近い平らな2ルータへのルートはOSIのための推進データベースとIPで別々のエントリーをもたらすでしょう。 IPに関しては、最も近い付属平らな2ルータへのルートはデフォルトルート(すなわち、すべての0のサブネットマスクがあるルート)として推進データベースに入れられるかもしれません。
One approach would be to put the results of each Dijkstra algorithm in a separate forwarding database. For a router which supports both level 1 and level 2 routing (including level 2 internal and level 2 external routes), and which supports all four types of service, this would result in twelve separate forwarding databases for IP. Implementations may choose to minimize the number of forwarding databases by combining the information from the multiple Dijkstra calculations into a single database per supported TOS. This is discussed in section C.2 below.
1つのアプローチはそれぞれのダイクストラアルゴリズムの結果を別々の推進データベースに入れるだろうことです。 レベル2 レベル1とルーティングの両方(レベル2 内部の、そして、平らな2個の外部経路を含んでいる)を支持して、すべての4つのタイプのサービスを支持するルータのために、これはIPのための12の別々の推進データベースをもたらすでしょう。 実現は、情報を複数のダイクストラの計算から支持されたTOSあたり1つのただ一つのデータベースに結合することによって推進データベースの数を最小にするのを選ぶかもしれません。 以下のセクションC.2でこれについて議論します。
The SPF algorithm specified in section C.2.3 of [1] is amended to appear as follows:
[1]のセクションC.2.3で指定されたSPFアルゴリズムは以下の通りに見えるために改正されます:
Callon [Page 71] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[71ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Step 0: Initialize TENT and PATHS to empty. Initialize tentlength to [internalmetric=0, externalmetric=0].
ステップ0: 空になるようにTENTとPATHSを初期化してください。 [internalmetric=0、externalmetric=0]にtentlengthを初期化してください。
(tentlength is the pathlength of elements in TENT that we are examining.)
(tentlengthは私たちが調べているTENTの要素のpathlengthです。)
1) Add <SELF,0,W> to PATHS, where W is a special value indicating
traffic to SELF is passed up to internal processes (rather than
forwarded).
1) <SELF、0を加えてください、PATHSへのW>、WがSELFへの交通が内部の過程(進められるよりむしろ)まで流れるのを示す特別な値であるところで。
2) Now pre-load TENT with the local adjacency database (Each
entry made to TENT must be marked as being either an End System
or a router to enable the check at the end of Step 2 to be made
correctly - Note that each local IP reachability entry is
included as an adjacency, and is marked as being an End System).
For each adjacency Adj(N) (including level 1 OSI Manual
Adjacencies, or level 2 OSI enabled reachable addresses, and
IP reachability entries) on enabled circuits, to system N of
SELF in state "Up" compute:
2) 今度は、ローカルの隣接番組データベースでTENTをプレロードしてください(TENTにされた各エントリーは正しくStep2の端でのチェックをするのを有効にするEnd Systemかルータのどちらかであるとして示されなければなりません--それぞれのローカルアイピー可到達性エントリーが隣接番組として含まれていて、End Systemであるとして示されることに注意してください)。 各隣接番組Adj(N)のために (レベル1 OSI Manual Adjacencies、または平らな2OSIの可能にされた届いているアドレス、およびIP可到達性エントリーを含んでいます) 可能にされたサーキットの上では、状態のSELFのシステムNに、“Up"は計算します:
d(N) = cost of the parent circuit of the adjacency (N),
obtained from metric.k , where k = one of {default metric,
delay metric, monetary metric, error metric}
d(N)はmetric.kから得られたkが1つと等しい隣接番組(N)の親サーキットの費用と等しいです。メートル法であって、遅れメートル法であって、通貨で、メートル法であって、誤りメートル法でデフォルトとします。
Adj(N) = the adjacency number of the adjacency to N
Adj(N)はNへの隣接番組の隣接番組番号と等しいです。
3) If a triple <N,x,{Adj(M)}> is in TENT, then:
3) Adj(M)、aは<N、xを3倍にします。次に、>がTENTにあります:
If x = d(N), then {Adj(M)} <--- {Adj(M)} U {Adj(N)}.
xはd(N)と等しく、次に、Adj(M)は<です。--- Adj(M)uのAdj(N)。
4) If N is a router or an OSI End System entry, and there are now
more adjacencies in {Adj(M)} than maximumPathSplits, then remove
excess adjacencies as described in Clause 7.2.7 of [1]. If N
is an IP Reachability Entry, then excess adjacencies may be
removed as desired. This will not effect the correctness of
routing, but may eliminate the determinism for IP routes (i.e.,
IP packets still follow optimal routes within an area, but
where multiple equally good routes exist, will not necessarily
follow precisely the route that any one particular router
would have anticipated).
4) NがルータかOSI End Systemエントリーであり、余分な隣接番組がClauseで説明されるようにmaximumPathSplitsより現在Adj(M)の隣接番組であり、次に、取り外される、7.2、.7、[1]について。 NがIP Reachability Entryであるなら、望まれているように余分な隣接番組を取り除くかもしれません。 これは、ルーティングの正当性に作用しませんが、IPルートに決定論を排除するかもしれません(すなわち、IPパケットは領域の中でまだ最適のルートに従っていますが、複数の等しく良いルートが存在するところに、必ず、正確にどんな特定のルータも予期したルートに従うというわけではないでしょう)。
5) If x < d(N), do nothing.
5) x<d(N)であるなら、何もしないでください。
6) If x > d(N), remove <N,x,{Adj(M)}> from TENT and add the triple
<N,d(N),{Adj(N)}>.
6) 三重の<N、d(N)、Adj(N)を加えてください。そして、Adj(M)、x>d(N)であるなら、<N、xを取り除いてください、TENTからの>、>。
7) If no triple <N,x,{Adj(M)}> is in TENT, then add <N,d(N),{Adj(N)}>
to TENT.
7) いいえ、三重の<N、x、Adj(M)。>がTENTにあって、d(N)、<Nはその時加えて、Adj(N)はTENTへの>です。
Callon [Page 72] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[72ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
8) Now add systems to which the local router does not have adjacencies,
but which are mentioned in neighboring pseudonode LSPs. The
adjacency for such systems is set to that of the designated router.
Note that this does not include IP reachability entries from
neighboring pseudonode LSPs. In particular, the pseudonode LSPs
do not include IP reachability entries.
8) 今度は、ローカルルータには隣接番組がありませんが、隣接しているpseudonode LSPsで言及されるシステムを加えてください。 そのようなシステムのための隣接番組は代表ルータのものに設定されます。 これが隣接しているpseudonode LSPsからのIP可到達性エントリーを含んでいないことに注意してください。 特に、pseudonode LSPsはIP可到達性エントリーを含んでいません。
9) For all broadcast circuits in state "On", find the pseudonode
LSP for that circuit (specifically, the LSP with number zero and
with the first 7 octets of LSPID equal to LnCircuitID for that
circuit, where n is 1 (for level 1 routing) or 2 (level 2
routing)). If it is present, for all the neighbors N reported in
all the LSPs of this pseudonode which do not exist in TENT add
an entry <N,d(N),{Adj(N)}> to TENT, where:
9) 州の“On"のすべての放送サーキットに関しては、そのサーキット(明確に数ゼロとnが1(レベル1 ルーティングのための)であるそのサーキットに、LnCircuitIDと等しいLSPIDの最初の7つの八重奏か2(レベル2 ルーティング)があるLSP)にpseudonode LSPを見つけてください。 それがそうなら、TENTに存在しないこのpseudonodeのすべてのLSPsで報告されたすべての隣人Nがエントリー<Nを加えるのでd(N)、Adj(N)にTENTへの>、どこを提示してくださいか:
d(N) = metric.k of the circuit.
Adj(N) = the adjacency number of the adjacency to the DR.
d(N)はサーキットのmetric.kと等しいです。 Adj(N)はDRへの隣接番組の隣接番組番号と等しいです。
10) Go to Step 2.
10) ステップ2に行ってください。
Step 1: Examine the zeroeth link state PDU of P, the system just placed on PATHS (i.e., the LSP with the same first 7 octets of LSPID as P, and LSP number zero).
ステップ1: P(PATHS(すなわち、PとしてのLSPID、およびLSP番号ゼロの同じ最初の7つの八重奏があるLSP)に関してただ課されるシステム)のzeroethリンク州のPDUを調べてください。
1) If this LSP is present, and the "Infinite Hippity Cost" bit is
clear, then for each LSP of P (i.e., all LSPs with the same
first 7 octets of LSPID and P, irrespective of the value of
LSP number) compute:
1) このLSPが存在していて、「無限のHippity費用」ビットが明確であるなら、P(LSPIDの同じ最初の7つの八重奏があるすなわちすべてのLSPsとLSP番号の値の如何にかかわらずP)の各LSPに関して、計算してください:
dist(P,N) = d(P) + metric.k(P,N)
dist(P、N)はd(P)+metric.kと等しいです。(P、N)
for each neighbor N (both End System and router) of the system P. If the "Infinite Hippity Cost" bit is set, only consider the End System neighbors of the system P. Note that the End Systems neighbors of the system P includes IP reachable address entries included in the LSPs from system P. Here, d(P) is the second element of the triple
LSPsは、システムP.HereからシステムPのEnd Systems隣人がIPの届いているアドレスエントリーを含むのを含んでいるシステムP.NoteのEnd System隣人であるとシステムP.If「無限のHippity費用」ビットの各隣人N(End Systemとルータの両方)が用意ができているので、d(P)が三重の2番目の要素であると考えるだけです。
<P,d(P),{Adj(P)}>
<P、d(P)Adj(P)、>。
and metric.k(P,N) is the cost of the link from P to N as reported in P's link state PDU.
そして、metric.k(P、N)はPのリンク州のPDUで報告されるようにPからNへのリンクの費用です。
2) If dist(P,N) > MaxPathMetric, then do nothing.
2) dist(P、N)です。 >MaxPathMetric、そして、何もしないでください。
3) If <N,d(N),{Adj(N)}> is in PATHS, then do nothing.
3) <N、d(N)、Adj(N)である、>がPATHSにあって、次に、何もしないでください。
Note: d(N) must be less than dist(P,N), or else N would not
have been put into PATHS. An additional sanity check may be
以下に注意してください。 d(N)はdist以下であるに違いありません(P、N)かNがPATHSに入れられていないでしょう。 追加健全度チェックはそうです。
Callon [Page 73] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[73ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
done here to ensure that d(N) is in fact less than dist(P,N)
ここで、事実上、d(N)がdist以下であることを保証するために、します。(P、N)
4) If a triple <N,x,{Adj(N)}> is in TENT, then:
4) Adj(N)、aは<N、xを3倍にします。次に、>がTENTにあります:
a) If x = dist(P,N), then {Adj(N)} <-- {Adj(N)} U {Adj(P)}.
a) =はxであるならdistされて(P、N)、次に、Adj(N)は<です。--Adj(N)uのAdj(P)。
b) If N is a router or an OSI end system, and there are now more
adjacencies in {Adj(N)} than maximumPath Splits, then remove
excess adjacencies, as described in clause 7.2.7 of [1]. For
IP Reachability Entries, excess adjacencies may be removed as
desired. This will not effect the correctness of routing, but
may eliminate the determinism for IP routes (i.e., IP packets
will still follow optimal routes within an area, but where
multiple equally good routes exist, will not necessarily follow
precisely the route that any one particular router would have
anticipated).
b) NがルータかOSIエンドシステムであり、より多くの隣接番組が現在maximumPath SplitsよりAdj(N)にあれば、余分な隣接番組を取り除いてください、節で説明されるように7.2、.7、[1]について。 IP Reachability Entriesに関しては、望まれているように余分な隣接番組を取り除くかもしれません。 これは、ルーティングの正当性に作用しませんが、IPルートに決定論を排除するかもしれません(それでも、すなわち、IPパケットは領域の中で最適のルートに従うでしょうが、複数の等しく良いルートが存在するところに、必ず、正確にどんな特定のルータも予期したルートに従うというわけではないでしょう)。
c) if x < dist(P,N), do nothing.
c) x<dist(P、N)であるなら、何もしないでください。
d) if x > dist(P,N), remove <N,x,{Adj(N)}> from TENT, and add
<N,dist(P,N),{Adj(P)}>
Adj(N)、d)がx>であるなら(P、N)をdistして、<N、xを取り除いてください、TENTからの>、<N、dist(P、N)を加えてください。Adj(P)、>。
5) if no triple <N,x,{Adj(N)}> is in TENT, then add
<N,dist(P,N),{Adj(P)}> to TENT.
いいえなら5)を<N、xを3倍にして、Adj(N)は>です。TENTにあって、<N、dist(P、N)はその時加えて、Adj(P)はTENTへの>です。
Step 2: If TENT is empty, stop. Else:
ステップ2: TENTが空であるなら、止まってください。 ほかに:
1) Find the element <P,x,{Adj(P)}>, with minimal x as follows:
1) 最小量のxは以下の通りで要素<P、x、Adj(P)が>であると確かめてください:
a) If an element <*,tentlength,*> remains in TENT in the list for
tentlength, choose that element. If there are more than one
elements in the list for tentlength, choose one of the elements
(if any) for a system which is a pseudonode in preference to one
for a non-pseudonode. If there are no more elements in the list
for tentlength, increment tentlength and repeat Step 2.
a) 要素<*、tentlength、*>がtentlengthのためのリストにTENTに留まるなら、その要素を選んでください。 tentlengthのためのリストに1つ以上の要素があれば、非pseudonodeのためのものに優先したpseudonodeであるシステムに(もしあれば)の要素の1つを選んでください。 tentlengthのためのリストにそれ以上の要素が全くなければ、tentlengthを増加してください、そして、Step2を繰り返してください。
b) Remove <P,tentlength,{Adj(P)}> from TENT.
b) <P、tentlength、Adj(P)を取り外してください。テントからの>。
c) Add <P,d(P),{Adj(P)}> to PATHS.
c) <P、d(P)、Adj(P)を加えてください。経路への>。
d) If this is the Level 2 Decision Process running, and the system
just added to PATHS listed itself as Partition Designated Level 2
Intermediate system, then additionally add <AREA.P,d(P),{Adj(P)}>
to PATHS, where AREA.P is the Network Entity Title of the other
end of the Virtual Link, obtained by taking the first AREA
listed in P's LSP and appending P's ID.
d) これがLevel2Decision Process走行であり、ただPATHSに加えられたシステムがPartition Designated Level2Intermediateシステムにそれ自体について記載したなら、さらに、<AREA.Pを加えてください、d(P)、Adj(P)。AREA.PがVirtual Linkのもう一方の端のNetwork Entity Titleであるところで最初のAREAで取ることによって入手されたPATHSへの>はPのLSPとPのIDを追加する際に記載しました。
e) If the system just added to PATHS was an end system, go to
e) ただ加えられたPATHSがエンドシステムであって、順調であったシステムです。
Callon [Page 74] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[74ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
step 2. Else go to Step 1.
2を踏んでください。 Step1へのほかの碁。
NOTE - In the level 2 context, the "End Systems" are the set of Reachable Address Prefixes (for OSI), the set of Area Addresses with zero cost (again, for OSI), plus the set of IP reachability entries (including both internal and external).
平らな2関係での注意、「エンドシステム」がReachable Address Prefixes(OSIのための)のセットであり、ゼロがあるArea Addressesのセットが費用である、(再び、OSI、)、IP可到達性エントリー(内部であって外部であることの形で両方を含んでいる)のセット
C.2 Forwarding of IP packets
IPパケットのC.2推進
The SPF algorithm specified in section C.1 may be used to calculate (logically) separate IP forwarding tables for each type of service, and for level 1, level 2 internal, and level 2 external routes. Section C.2.1 describes how to forward IP packets, based on these multiple forwarding databases. Section C.2.2 describes how the multiple forwarding databases can be combined into a single forwarding database per supported TOS.
セクションC.1で指定されたSPFアルゴリズムは、それぞれのタイプのサービス、およびレベル1のための(論理的に)別々のIP推進テーブルが2個の内部の外部経路、および平らな2個の外部経路を平らにすると見込むのに使用されるかもしれません。 セクションC.2.1はこれらの複数の推進データベースに基づいてIPパケットを進める方法を説明します。 セクションC.2.2はどう複数の推進データベースを結合できるかを支持されたTOSあたり1つのただ一つの推進データベースに説明します。
C.2.1 Basic Method for Forwarding IP packets
Forwarding IPパケットのためのC.2.1の基本的なMethod
For level 1-only routers:
1だけの平らなルータのために:
- Determine if the IP destination address matches any entry in the
level 1 forwarding table for the specified TOS.
- 受信者IPアドレスが何かレベル1における指定されたTOSのためにテーブルを進めるエントリーに合っているかどうか決定してください。
- Determine if the IP destination address matches any entry in the
level 1 forwarding table for the default TOS.
- 受信者IPアドレスが何かレベル1におけるデフォルトTOSのためにテーブルを進めるエントリーに合っているかどうか決定してください。
- If default TOS resulted in more specific entry, forward according
to default TOS.
- デフォルトTOSが、より特定のエントリーをもたらしたなら、デフォルトに従って、TOSを進めてください。
- If equally specific entries found, or specified TOS resulted in
more specific entry, forward according to specified TOS
- 等しく特定のエントリーが、より特定のエントリーに結果になって、指定されたTOSに従った前進のTOSを当たったか、または指定したなら
- If no entry was found (which includes no default route entry), then
destination is unreachable.
- エントリーが全く見つけられなかったなら(デフォルトルートエントリーを全く含んでいません)、目的地は手が届きません。
Note: For level 1 only routers, the route to the nearest attached level 2 router will be entered into the forwarding database as a default route (i.e., a route with a subnet mask which is all 0). Thus this last event (no entry found) can occur only if there is no attached level 2 router reachable in the area.
以下に注意してください。 レベル1 ルータだけにおいて、最も近い付属平らな2ルータへのルートはデフォルトルート(すなわち、すべて0であるサブネットマスクがあるルート)として推進データベースに入れられるでしょう。 したがって、レベル2 その領域で届いているルータが付けられない場合にだけ、この最後の出来事(見つけられなかったエントリー全く)は起こることができます。
For routers which are both level 1 and level 2 routers:
レベル2 レベル1とルータの両方であるルータのために:
- Determine if the IP destination address matches any entry in the
level 1 forwarding table for the specified TOS.
- 受信者IPアドレスが何かレベル1における指定されたTOSのためにテーブルを進めるエントリーに合っているかどうか決定してください。
- Determine if the IP destination address matches any entry in the
- 受信者IPアドレスが中で何かエントリーに合っているかどうか決定してください。
Callon [Page 75] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[75ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
level 1 forwarding table for the default TOS.
レベル1 デフォルトTOSのためにテーブルを進めます。
- If default TOS resulted in more specific entry (i.e., more bits in
the subnet mask take the value 1), forward according to default TOS.
- デフォルトTOSが、より特定のエントリーをもたらしたなら(すなわち、サブネットマスクの、より多くのビットが値1を取ります)、デフォルトに従って、TOSを進めてください。
- If equally specific entries found, or specified TOS resulted in
more specific entry, forward according to specified TOS
- 等しく特定のエントリーが、より特定のエントリーに結果になって、指定されたTOSに従った前進のTOSを当たったか、または指定したなら
- If no entry found:
- エントリーでないなら、以下を設立してください。
- Determine if the IP destination address matches any entry in the
level 2 internal forwarding table for the specified TOS.
- 指定されたTOSのために受信者IPアドレスが何か平らな2内部の推進テーブルのエントリーに合っているかどうか決定してください。
- Determine if the IP destination address matches any entry in the
level 2 internal forwarding table for the default TOS.
- デフォルトTOSのために受信者IPアドレスが何か平らな2内部の推進テーブルのエントリーに合っているかどうか決定してください。
- If default TOS resulted in more specific entry, forward according
to default TOS.
- デフォルトTOSが、より特定のエントリーをもたらしたなら、デフォルトに従って、TOSを進めてください。
- If equally specific entries found, or specified TOS resulted in
more specific entry, forward according to specified TOS
- 等しく特定のエントリーが、より特定のエントリーに結果になって、指定されたTOSに従った前進のTOSを当たったか、または指定したなら
- If no entry found:
- エントリーでないなら、以下を設立してください。
- Determine if the IP destination address matches any entry in the
level 2 external forwarding table for the specified TOS.
- 指定されたTOSのために受信者IPアドレスが何か平らな2外部の推進テーブルのエントリーに合っているかどうか決定してください。
- Determine if the IP destination address matches any entry in the
level 2 external forwarding table for the default TOS.
- デフォルトTOSのために受信者IPアドレスが何か平らな2外部の推進テーブルのエントリーに合っているかどうか決定してください。
- If default TOS resulted in more specific entry, forward according
to default TOS.
- デフォルトTOSが、より特定のエントリーをもたらしたなら、デフォルトに従って、TOSを進めてください。
- If equally specific entries found, or specified TOS resulted in
more specific entry, forward according to specified TOS
- 等しく特定のエントリーが、より特定のエントリーに結果になって、指定されたTOSに従った前進のTOSを当たったか、または指定したなら
- If no entry is found, then destination is unreachable
- エントリーが全く見つけられないなら、目的地は手が届きません。
For level 2-only routers, the above algorithm can be used, except since there is no level 1 forwarding database, the corresponding steps can be skipped.
平らな2だけルータのために、上のアルゴリズムを使用できて、レベル1 以来を除いて、データベースを転送してはいけなくて、対応するステップはサボることができます。
As discussed in section 3.10.2, for level 2 routers which are announcing manually configured summary addresses in their level 2 LSPs, in some cases there will exist IP addresses which match the manually configured addresses, but which do not match any addresses which are reachable via level 1 routing in the area. Packets to such addresses are handled according to the rules specified in section
いくつかの場合、レベル2 それらの平らな2LSPsの手動で構成された概要アドレスを発表しているルータのためにセクション3.10.2で議論するように、手動で構成されたアドレスを合わせますが、少しのその領域で掘りながらレベル1で届いているアドレスも合っていないIPアドレスが存在するでしょう。 セクションで指定された規則に従って、そのようなアドレスへのパケットは扱われます。
Callon [Page 76] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[76ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
3.10.2. This may be accomplished by adding the manually configured [IP address, subnet mask] entry to the level 2 forwarding database (for the appropriate TOS), with a special "next hop" address which specifies that packets for which this entry is selected are to be discarded. This will work correctly because more desireable entries (such as delivering the packet via level 1 routing to the correct destination, or a more specific level 2 route) will automatically take precedence according to the forwarding rules specified above. Less desireable routes (such as using a level 2 external route to the "default route" entry) are not possible because other level 2 routers will believe the summary addresses advertised by this router.
3.10.2. これはデータベース(適切なTOSのための)を転送するレベル2に手動で構成された[IPアドレス、サブネットマスク]エントリーを加えることによって、達成されるかもしれません、このエントリーが選択されるパケットが捨てられることになっていると指定する特別な「次のホップ」アドレスで。 上で指定された推進規則に従って、より「望-可能」なエントリー(レベル1を通したパケットに正しい目的地へのルーティングを届けるか、または2ルートをより特定のレベルに届けなどなどの)が自動的に優先するので、これは正しく働くでしょう。 他のレベル2 ルータがこのルータによって広告に掲載された概要アドレスを信じるので、より少ない「望-可能」ルート(「デフォルトルート」エントリーに平らな2外部経路を使用などなどの)は可能ではありません。
C.2.2 Reduction of IP Forwarding Databases
IP推進データベースのC.2.2減少
The multiple forwarding databases used in the basic forwarding method in section C.2.1 can be reduced, by combining the multiple databases into one database for each supported TOS.
それぞれがTOSを支持したので、複数のデータベースを1つのデータベースに結合することによって、セクションC.2.1の基本的な推進方法で使用される複数の推進データベースは減らすことができます。
For reduction of IP forwarding databases, it is assumed that for any two overlapping address entries, either the entries are identical, or one range contains the other. In other words, for any two [IP address, subnet mask] entries A and B, if there is at least one IP address which matches both entries, then either: (i) the two entries are identical; or (ii) entry A contains entry B (i.e., any IP address which matches entry B also matches entry A); or (iii) entry B contains entry A (any IP address which matches entry A also matches entry B).
IP推進データベースの減少において、どんな2つの重なっているアドレスエントリーにも、エントリーが同じであるか、または1つの範囲がもう片方を含むと思われます。 次に両方のエントリーに合っている少なくとも1つのIPアドレスがどんな2つ[IPアドレス、サブネットマスク]のエントリーAとB、言い換えればあればも: (i) 2つのエントリーが同じです。 または、(ii)エントリーAはエントリーBを含んでいます(また、エントリーBに合っているすなわちどんなIPアドレスもエントリーAに合っています)。 または、(iii)エントリーBはエントリーAを含んでいます(また、エントリーAに合っているどんなIPアドレスもエントリーBに合っています)。
Non-contiguous subnet masks can be configured to violate this assumption. For example, consider the two entries:
この仮定に違反するために非隣接のサブネットマスクを構成できます。 例えば、2つのエントリーを考えてください:
- A=[address="01010101 00000101 00000000 00000000",
mask="11111111 00001111 00000000 00000000"]
- =[=を記述してください、「01010101 00000101 00000000、0インチに、マスクが」 11111111 00001111 00000000と何0インチも等しい、]
- B=[address="01010101 01010000 00000000 00000000",
mask="11111111 11110000 00000000 00000000"]
- B=[=を記述してください、「01010101 01010000 00000000、0インチに、マスクが」 11111111 11110000 00000000と何0インチも等しい、]
In this case neither entry contains the other. Specifically;
この場合、どちらのエントリーももう片方を含みません。 明確に。
- there are IP addresses which match both A and B (e.g.,
"01010101 01010101 xxxxxxxx xxxxxxxx"),
- AとBの両方(例えば、「01010101 01010101xxxxxxxx xxxxxxxx」)に合っているIPアドレスがあります。
- there are IP addresses which match A but not B (e.g.,
"01010101 11110101 xxxxxxxx xxxxxxxx")
- Bではなく、Aに合っているIPアドレスがあります。(例えば、「01010101 11110101xxxxxxxx xxxxxxxx」)
- there are IP addresses which match B but not A (e.g.,
"01010101 01011111 xxxxxxxx xxxxxxxx").
- Aではなく、B(例えば、「01010101 01011111xxxxxxxx xxxxxxxx」)に合っているIPアドレスがあります。
Callon [Page 77] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[77ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
The reduction of the multiple forwarding databases for each TOS to a single database for each TOS is based on the use of "best match" routing, combined with reduction of the entries placed in the forwarding database in order to eliminate entries which are not to be selected (based on the order of preference of routes specified in section 3.10). The specific algorithm for creation of the IP forwarding database can be described as follows:
各TOSに、ただ一つのデータベースへの各TOSにおいて複数の推進データベースの減少は選択してはいけない(セクション3.10で指定されたルートに関するよく使われる順に基づいています)エントリーを排除するために推進データベースに置かれるエントリーの減少に結合された「最も良いマッチ」ルーティングの使用に基づいています。 以下の通りIP推進データベースの創造のための特定のアルゴリズムを説明できます:
1) Make use of the the Dijkstra algorithm described in section C.1 to
create separate forwarding databases for each supported TOS for
level 1 routes, level 2 internal routes, and level 2 external
routes. (Note that each entry in the forwarding database will
specify an [IP address, subnet mask] combination, as well as the
next hop router for IP packets which match that entry).
1) レベル1 ルート、レベル2 内部のルート、およびレベル2 外部経路にそれぞれの支持されたTOSのための別々の推進データベースを作成するためにセクションC.1で説明されたダイクストラアルゴリズムを利用してください。 (推進データベースにおける各エントリーが[IPアドレス、サブネットマスク]組み合わせ、および次のホップルータをそのエントリーに合っているIPパケットに指定することに注意します。)
2) For each level 1 route entry which has been placed in the level 1
IP forwarding database for a specific TOS, copy that entry into
the overall IP forwarding database for that TOS.
2) 特定のTOSのための1つの平らなIP推進データベースに置かれたそれぞれの1つの平らなルートエントリーには、そのTOSのための総合的なIP推進データベースにそのエントリーをコピーしてください。
3) For each route entry X which has been placed in the level 2 internal
IP forwarding database for a specific TOS, search for overlapping
entries in the level 1 IP forwarding database for the specific TOS,
and also for the default TOS:
3) 特定のTOSのための平らな2内部のIP推進データベースに置かれたそれぞれのルートエントリーXを特定のTOS、およびデフォルトTOSのために1つの平らなIP推進データベースにおけるもエントリーを重ね合わせるのを探してください:
a) If there is any overlapping entry Y in the level 1 forwarding
database (for the specfic TOS, or for the default TOS) such
that either (i) Y contains X; or (ii) Y is identically specific
to X; then ignore entry X.
a) エントリーYを重ね合わせるいずれもデータベース(specfic TOS、またはデフォルトTOSのための)にそのようなものを送そんなにのどちらかレベル1にある、(i) YはXを含んでいます。 または、(ii) Yは同様にXに特定です。 そして、エントリーXを無視してください。
b) Otherwise, copy entry X into the overall IP forwarding database
for the specific TOS.
b) さもなければ、特定のTOSのための総合的なIP推進データベースにエントリーXをコピーしてください。
4) For each route entry X which has been placed in the level 2
external IP forwarding database for a specific TOS, search for
overlapping entries in the level 1 IP forwarding database for
the specific TOS, and for the default TOS, and the level 2
internal IP forwarding database for the specific TOS, and for
the default TOS.
4) レベル2に外部であることの形で置かれたそれぞれのルートエントリーXに、IPが特定のTOSのためにデータベースを転送して、レベル1におけるエントリーを重ね合わせるのをIP推進データベースを特定のTOS、およびデフォルトTOSを探して、特定のTOS、およびデフォルトTOSのために平らな2内部のIP推進データベースを探してください。
a) If there is an overlapping entry Y such that either (i) Y
contains X; or (ii) Y is identically specific to X; then
ignore entry X.
a) 重なっているエントリーYがあれほどそんなにのどちらかある、(i) YはXを含んでいます。 または、(ii) Yは同様にXに特定です。 そして、エントリーXを無視してください。
b) Otherwise, copy entry X into the overall IP forwarding database
for the specific TOS.
b) さもなければ、特定のTOSのための総合的なIP推進データベースにエントリーXをコピーしてください。
This method will result in one forwarding database for each supported TOS. The forwarding of packets can then be simplified to be as follows:
この方法はそれぞれの支持されたTOSあたり1つの推進データベースをもたらすでしょう。 次に、以下の通りためにパケットの推進を簡素化できます:
Callon [Page 78] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[78ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
1) For IP packets which map to the default TOS metric (or to an
unsupported TOS metric), search the default TOS forwarding
database and select the entry which has the most specific match.
Forward the packet accordingly.
1) メートル法の、そして、(サポートされないTOSへのメートル法)のTOSをデフォルトに写像するIPパケットに関しては、デフォルトTOS推進データベースを捜してください、そして、最も特定のマッチを持っているエントリーを選択してください。 それに従って、パケットを進めてください。
2) For packets which map to a specific (non-default) TOS metric,
search the specific TOS forwarding database and select the entry
j which has the most specific match. Also search the default TOS
forwarding database and select the entry k which has the most
specific match. Forward the packet as follows:
2) (非デフォルト)を詳細に写像するパケットのために TOSメートル法であり、特定のTOS推進データベースを捜してください、そして、最も特定のマッチを持っているエントリーjを選択してください。 また、デフォルトTOS推進データベースを捜してください、そして、最も特定のマッチを持っているエントリーkを選択してください。 以下のパケットを進めてください:
a) If k is more specific than j, forward according to entry k
a) kがjより特定であって、エントリーkに従って前進しているなら
b) If j and k are equally specific, forward according to entry j
b) エントリーjに従って、jとkが等しく特定であって、前進しているなら
c) If j is more specific than k, forward according to entry j
c) jがkより特定であって、エントリーjに従って前進しているなら
Callon [Page 79] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[79ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Annex D
Use of the Authentication Field
認証分野の別館D使用
The use of the Authentication field is outside of the scope of this specification. However, there is a urgent need for simple error detection/authentication mechanisms (such as a simple password) to protect against certain types of errors. This annex therefore proposes a possible use of this field.
Authentication分野の使用がこの仕様の範囲の外にあります。 しかしながら、簡単な誤り検出/認証機構(簡単なパスワードなどの)が、あるタイプの誤りから守る緊急の必要があります。 したがって、この別館はこの分野の活用可能性を提案します。
This annex is included for informational purposes.
この別館は情報の目的のために含まれています。
D.1 Authentication Field in IS-IS packets
中のD.1認証Field、-、パケット
All IS-IS packets may optionally include the authentication field, as described in sections 3.9 and 5 of this specification. As described in section 5, the authentication field is encoded as a (Code, Length, Value) triplet. This annex proposes that the contents of the Value field consist of a one octet "Authentication Type" field, plus a variable length "Authentication Information" field. A specific value of the "Authentication Type" is assigned to passwords, transmitted in the clear without encryption. The authentication field is encoded as follows:
すべて、-、パケットはこの仕様のセクション3.9と5で説明されるように任意に認証分野を含むかもしれません。 セクション5で説明されるように、認証分野は(コード、Length、Value)三つ子としてコード化されます。 この別館は、Value分野の内容が1つの八重奏「認証タイプ」分野、および可変長「認証情報」分野から成るよう提案します。 「認証タイプ」の特定の値は暗号化のない明確で伝えられたパスワードに割り当てられます。 認証分野は以下の通りコード化されます:
7 Authentication Information -- Information used to authenticate
the PDU
7 認証情報--PDUを認証するのに使用される情報
x CODE - 133
x CODE--133
x LENGTH - total length of the value field
x LENGTH--値の分野の全長
x VALUE -
No. of Octets
+--------------------------------+
| Authentication Type | 1
+--------------------------------+
| Authentication Information | VARIABLE
+--------------------------------+
x VALUE--Octets+についていいえ--------------------------------+ | 認証タイプ| 1 +--------------------------------+ | 認証情報| 変数+--------------------------------+
The Authentication Type is assigned as follows:
Authentication Typeは以下の通り割り当てられます:
Type = 0 reserved
0が予約した=をタイプしてください。
Type = 1 simple password
タイプは1つの簡単なパスワードと等しいです。
Type > 1 reserved
1が予約した>をタイプしてください。
Callon [Page 80] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[80ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
D.2 Authentication Type 1 - Simple Password
D.2認証タイプ1--簡単なパスワード
Using this authentication type, a variable length password is passed in the clear (i.e., not encrypted) in the Authentication Information field.
この認証タイプを使用して、可変長パスワードはAuthentication情報分野で明確で通過されます(すなわち、暗号化されません)。
WARNING: The use of a simple password does not provide useful protection against intentional misbehavior. In particular, since the password is transmitted in the clear without encryption, it is easy for a hostile system to intercept the passwords, and to transmit authenticated packets. The use of simple passwords should be considered only as a weak protection against accidental errors such as accidental misconfiguration.
警告: 簡単なパスワードの使用は意図的な不正行為に対する役に立つ保護を提供しません。 パスワードが暗号化のない明確で伝えられるので敵軍のシステムがパスワードを傍受するのが、特に、簡単であり、伝わるのはパケットを認証しました。 簡単なパスワードの使用は偶然のmisconfigurationなどの偶然の誤りに対する弱い保護だけと考えられるべきです。
The password shall be configured on a per-link, per-area, and per- domain basis. Specifically, when this form of authentication is used:
そして、パスワードが1領域あたり1個のリンクの上に構成されるものとする、-、ドメイン基礎。 この形式の認証が明確に使用されているとき:
- IS-IS Hello and 9542 IS Hello packets shall contain the
per-link password
- -、Helloと9542はHelloパケットが1リンクあたりのパスワードを含むものとするということです。
- Level 1 Link State Packets shall contain the per-area password
- レベル1 Link州Packetsは1領域あたりのパスワードを含むものとします。
- Level 2 Link State Packets shall contain the per-domain password
- レベル2 Link州Packetsは1ドメインあたりのパスワードを含むものとします。
- Level 1 Sequence Number Packets shall contain the per-area password
- レベル1 Sequence Number Packetsは1領域あたりのパスワードを含むものとします。
- Level 2 Sequence Number Packets shall contain the per-domain
password
- レベル2 Sequence Number Packetsは1ドメインあたりのパスワードを含むものとします。
Also, each of these three passwords shall be configured with: (i) "Transmit Password", whose value is a single password, and (ii) "Receive Passwords", whose value is a set of passwords. The transmit password value is always transmitted. However, any password contained in the receive password set will be accepted on receipt. This method allows the graceful changing of passwords without temporary loss of connectivity.
また、それぞれに関するこれらの3つのパスワードが以下によって構成されるものとします。 (i) 「Passwordを伝えてください」、だれの値はただ一つのパスワードであるか、そして、および(ii)「パスワードを受け取ってください。」その値は1セットのパスワードです。 伝わってください。伝えられて、いつもパスワード値はそうです。 設定されて、パスワードを受け取ってください。しかしながら、どんなパスワードも中に含んだ、領収書で、受け入れるでしょう。 このメソッドは接続性の一時的な損失なしでパスワードの優雅な変化を許します。
For example, consider the case that an area has the configured area
password "OLDAREAPASSWORD". In this case, the per-area transmit
password value is set to OLDAREAPASSWORD, and the per-area receive
password value is set to {OLDAREAPASSWORD}. Suppose that it is
desired to change the per-area password to "NEWERPASSWORD". The
first step would be to manually configure all of the routers in the
area to set the per-area receive password value to {OLDAREAPASSWORD,
NEWERPASSWORD}. When this step is complete, then all routers in the
area will still be using the old password OLDAREAPASSWORD in their
level 1 LSPs and SNPs. However, they will also accept the alternate
password NEWERPASSWORD. The second step would be to configure the
例えば、ケースを考えてください。領域には、"OLDAREAPASSWORD"という構成された領域パスワードがあります。 パスワード値はOLDAREAPASSWORDに設定されます、そして、領域はパスワード値を受けます。この場合領域が伝わる、OLDAREAPASSWORDに設定されます。 1領域あたりのパスワードを"NEWERPASSWORD"に変えるのが必要であると仮定してください。 第一歩は領域を設定する領域のルータのすべてがパスワード値をOLDAREAPASSWORD、NEWERPASSWORDに受けるのを手動で構成するだろうことです。 このステップが完全であると、その領域のすべてのルータがそれらの平らな1LSPsとSNPsでまだ古いパスワードOLDAREAPASSWORDを使用しているでしょう。 しかしながら、また、彼らは代替のパスワードNEWERPASSWORDを受け入れるでしょう。 第2ステップは構成することになっているでしょう。
Callon [Page 81] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[81ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
routers in the area to set the per-area transmit password to
NEWERPASSWORD. When the second step is complete, then all routers
will be using the new value of the per-area password, but will accept
the old value as well. Finally, the third step is to change all
routers in the area to have the per-area receive password set to
{NEWERPASSWORD}.
領域を設定する領域のルータはパスワードをNEWERPASSWORDに伝えます。 第2ステップが完全であると、すべてのルータが、1領域あたりのパスワードの新しい値を使用しますが、また、古い値を受け入れるでしょう。 最終的に、第3ステップは領域にパスワードセットをNEWERPASSWORDに受けさせるようにその領域のすべてのルータを変えることです。
By configuring transmit and receive values for the passwords in this manner, it is possible to maintain continuous correct operation. For example, in the middle of the second step in the above example, some of the routers in the area will be transmitting level 1 LSPs and SNPs using the old password OLDAREAPASSWORD, and some will be transmitting level 1 LSPs and SNPs using the new password NEWERPASSWORD. However, during the second step of the transition all routers in the area will accept level 1 LSPs and SNPs using either password.
パスワードのためにこの様に値を送受信するように構成することによって、連続した正しい操作を維持するのは可能です。 例えば、上記の例における第2ステップの途中では、その領域のルータのいくつかが古いパスワードOLDAREAPASSWORDを使用することでレベル1のLSPsとSNPsを伝えるでしょう、そして、或るものは新しいパスワードNEWERPASSWORDを使用することでレベル1のLSPsとSNPsを伝えるでしょう。 しかしながら、変遷の第2ステップの間、その領域のすべてのルータが、どちらのパスワードも使用することでレベル1のLSPsとSNPsを受け入れるでしょう。
Callon [Page 82] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[82ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
Annex E
Interaction of the Integrated IS-IS with Brouters
統合のE相互作用を付加してください、-、ブルータ
A "brouter" is a device which operates an both a bridge and a router. One possible type of brouter acts as a router for IP traffic, and acts as a bridge for all other types of traffic.
「ブルータ」が作動するデバイスである、ブリッジとルータの両方。 1つの可能なタイプのブルータはIPトラフィックのためのルータ、および他のすべてのタイプのトラフィックのためのブリッジとしての行為として機能します。
Depending upon the manner in which a brouter is implemented, and depending upon the network topology, there is an obscure bug which can result from the interaction of the Integrated IS-IS protocol, and brouters. This appendix gives an example of the bug, and proposes a simple correction to the operation of brouters to correct the problem.
ブルータが実装される方法によって、ネットワーク形態によって、Integratedの相互作用から生じることができる不鮮明なバグがある、-、プロトコル、およびブルータ。 この付録は、問題を修正するためにブルータの操作にバグに関する例を出して、簡単な修正を提案します。
This annex is included for informational purposes.
この別館は情報の目的のために含まれています。
E.1 The Problem
E.1問題
Suppose that we have a brouter which treats IP packets as if it were a normal IP router, and which treats all other packets as if it is a bridge.
私たちがまるでそれが正常なIPルータであるかのようにIPパケットを扱って、まるでそれがブリッジであるかのように他のすべてのパケットを扱うブルータを持っていると仮定してください。
Suppose that two routers "X" and "Y" (which implement the integrated IS-IS protocol), two Ethernets, and a brouter B are all connected as follows:
2つのルータ「X」と「Y」(統合IS-ISプロトコルを実装する)、2つのイーサネット、およびブルータBが以下の通りすべて接続されると仮定してください:
| |
+----+---+ +----+---+
| Router | | Router |
| X | | Y |
+----+---+ +----+---+
| |
-----+------------+- -+------------+----
| |
+-+-----+-+
| Brouter |
| B |
+---------+
| | +----+---+ +----+---+ | ルータ| | ルータ| | X| | Y| +----+---+ +----+---+ | | -----+------------+- -+------------+---- | | +-+-----+-+ | ブルータ| | B| +---------+
Here suppose that X and Y are running the Integrated IS-IS protocol, and are both level 1 routers in the same area. Thus X and Y send IS- IS Hello packets on the LAN. These Hello packets are received and forwarded by the brouter (using normal bridge functions). Similarly, X and Y receive each other's IS-IS LSP packets. In this way, it appears to the Brouter that X and Y are exchanging OSI packets, and so they are forwarded using normal bridge functions. It appears to X
そのXとYであるなら走りがここの、Integratedである、-、議定書を作ってください、そして、同じ領域の両方の平らな1ルータは議定書を作ります。 したがって、XとYが発信する、存在、LANのHelloパケットはそうです。 ブルータはこれらのHelloパケットを受け取って、進めます(正常な架橋機能を使用して)。 同様に、XとYが受信される、互いである、-、IS LSP、パケット。 このように、Brouterにおいて、XとYがOSIパケットを交換しているのでそれらが正常な架橋機能を使用することで進められるように見えます。 それはXに見えます。
Callon [Page 83] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[83ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
and Y as if they are on the same LAN, and so they learn each others 48-bit Ethernet addresses and exchange routing information.
そして、Y、まるで彼らが同じLANにいるのでイーサネットが扱う他のものの各48ビットと交換ルーティング情報を学ぶかのように。
Now, suppose that X receives an IP packet, which it needs to forward via Y. Since X thinks that it and Y are on the same Ethernet, it just forwards the IP packet directly, using normal Ethernet encapsulation and using the 48-bit Ethernet address of Y as the destination address in the Ethernet header. Brouter B, when thinking as a bridge says: "this is an IP packet, I don't forward this as a bridge". Brouter B, when thinking like an IP router says: "this is an IP packet, I know how to forward IP packets. However, this is sent to an Ethernet address which is not me, thus I will ignore it". The result is that the IP packet does not get forwarded.
現在、そのXがSince Xがそれであると考えるY.を通して送るそれがそれが必要があるIPパケットを受けるか、そして、Yが同じイーサネットにあって、ただ直接IPパケットを進めます、正常なイーサネットカプセル化を使用して、送付先アドレスとしてイーサネットヘッダーでYの48ビットのイーサネット・アドレスを使用して。 ブリッジが言うように思うときのブルータB 「これがIPパケットである、私はブリッジとしてこれを進めません。」 IPルータのように思うのが言うときのブルータB 「これがIPパケットである、私はIPパケットを進める方法を知っています。」 「しかしながら、私でないイーサネット・アドレスにこれを送ります、その結果、私はそれを無視するつもりです。」 結果はIPパケットが進められないということです。
This problem relates directly to the fact that X and Y are exchanging OSI packets to determine the connectivity of the path between them, but then are trying to send IP packets over the path. Also, there is a device between X and Y on the path which treats OSI and IP packets differently.
この問題はXとYがそれらの間の経路の接続性を決定するためにOSIパケットを交換していますが、IPパケットを経路の上に送ろうとしているという直接事実に関連します。 また、経路のXとYの間のOSIとIPパケットを異なって扱うデバイスがあります。
Also note that this problem can also occur in more complex topologies, whenever a brouter is treating OSI and IP packets in a fundamentally different manner.
また、また、この問題が、より複雑なtopologiesに起こることができることに注意してください、ブルータが基本的に異なった方法でOSIとIPパケットを扱っているときはいつも。
E.2 Possible Solutions
E.2の可能なソリューション
E.2.1 More Sophisticated Brouter
E.2.1の、より洗練されたブルータ
One solution is that brouter B needs to be a little more sophisticated. In particular, it needs to use the following rules:
1つのソリューションはブルータBが、もう少し洗練されている必要があるということです。 以下の規則を使用するのが特に、必要です:
- For packets which are not IP packets, act as a bridge (this is the
same as before).
- IPパケットでないパケットに関しては、ブリッジとして、機能してください(これは従来と同様同じです)。
- For IP packets sent to an Ethernet broadcast or multicast address,
act as an IP router (this is also the same as before).
- イーサネット放送かマルチキャストアドレスに送られたIPパケットに関しては、IPルータとして、機能してください(また、これも従来と同様同じです)。
- For IP packets sent to my own Ethernet 48-bit address(es), act as
an IP router (this is also the same as before).
- 私自身のイーサネットの48ビットのアドレス(es)に送られたIPパケットに関しては、IPルータとして、機能してください(また、これも従来と同様同じです)。
- For IP packets sent to a single station 48-bit address which is not
one of my addresses, act at a bridge (THIS IS NEW).
- 私のアドレスの1つでないただ一つのステーション48ビットのアドレスに送られたIPパケットに関しては、ブリッジ(THIS IS NEW)で行動してください。
With this change, the IP packet transmitted from X to Y is forwarded by the brouter, acting as a bridge. This allows the Brouter and the multiprotocol routers to interoperate properly.
ブリッジとして機能して、この変化と共に、ブルータはXからYまで伝えられたIPパケットを進めます。 これで、Brouterと「マルチ-プロトコル」ルータは適切に共同利用します。
Callon [Page 84] RFC 1195 OSI ISIS for IP and Dual Environments December 1990
IPのためのCallon[84ページ]RFC1195オウシ・イシスと二元的な環境1990年12月
E.2.2 Dual Router / Brouter
E.2.2の二元的なルータ/ブルータ
An alternate solution would be for the Brouter to route both OSI and IP equally. If the Brouter used the integrated IS-IS for this purpose, then it could be part of the same routing domain and interoperate like any other dual router (except for the ability to bridge other protocol suites). If it used other protocols for routing OSI and IP, then it would need to be part of another routing domain, and could interoperate with integrated IS-IS routers like any other external router.
代替策はBrouterが等しくOSIとIPの両方を発送するだろうことです。 Brouterが使用した、統合、-、このために、次に、それは、同じ経路ドメインの一部であり、いかなる他の二元的なルータのようにも共同利用できました(他のプロトコルがスイートであるとブリッジする能力を除いて)。 ルーティングOSIとIPに他のプロトコルを使用したなら、それが別の経路ドメインの一部であることが必要であるだろう、共同利用できたその時が統合した、-、いかなる他の外部のルータのようなルータ。
Callon [Page 85]
Callon[85ページ]
一覧
スポンサーリンク
