RFC1371 日本語訳

1371 Choosing a Common IGP for the IP Internet. P. Gross. October 1992. (Format: TXT=18168 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                  P. Gross, Editor
Request for Comments: 1371                              IETF/IESG Chair
                                                           October 1992

コメントを求める総計のワーキンググループP.エディタ要求をネットワークでつないでください: 1371 IETF/IESG議長1992年10月

              Choosing a "Common IGP" for the IP Internet
                 (The IESG's Recommendation to the IAB)

IPインターネットへの「一般的なIGP」を選びます。(IABへのIESGの推薦)

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Special Note

特別な注意

   This document was originally prepared as an Internet Engineering
   Steering Group (IESG) recommendation to the Internet Architecture
   Board (IAB) in mid-summer 1991, reaching the current version by the
   date shown above.  Although the document is now somewhat dated (e.g.,
   CIDR and RIP II are not mentioned), the IESG felt it was important to
   publish this along with the recent OSPF Applicability Statement [11]
   to help establish context and motivation.

このドキュメントは真夏1991に元々インターネットEngineering Steering Group(IESG)推薦としてインターネット・アーキテクチャ委員会(IAB)に準備されました、上に示された日付までに最新版に達して。 ドキュメントは現在いくらか日付を入れられましたが(例えば、CIDRとRIP IIは言及されません)、IESGは、文脈と動機を確立するのを助けるために最近のOSPF Applicability Statement[11]と共にこれを発行するのが重要であると感じました。

Abstract

要約

   This memo presents motivation, rationale and other surrounding
   background information leading to the IESG's recommendation to the
   IAB for a single "common IGP" for the IP portions of the Internet.

このメモはインターネットのIP部分への単一の「一般的なIGP」のために動機、原理、およびIESGの推薦につながる他の周囲の基礎的な情報をIABに提示します。

   In this memo, the term "common IGP" is defined, the need for a common
   IGP is explained, the relation of this issue to other ongoing
   Internet Engineering Task Force (IETF) routing protocol development
   is provided, and the relation of this issue to the goal for multi-
   protocol integration in the Internet is explored.

このメモでは、用語「一般的なIGP」を定義します、そして、一般的なIGPの必要性について説明します、そして、他の進行中のインターネット・エンジニアリング・タスク・フォース(IETF)のルーティング・プロトコル開発へのこの問題の関係を提供します、そして、インターネットのマルチプロトコル統合の目標へのこの問題の関係について調査します。

   Finally, a specific IGP is recommended as the "common IGP" for IP
   portions of the Internet -- the Open Shortest Path First (OSPF)
   routing protocol.

最終的に、特定のIGPはインターネットのIP部分への「一般的なIGP」としてお勧めです--オープンShortest Path First(OSPF)ルーティング・プロトコル。

   The goal of this recommendation is for all vendors of Internet IP
   routers to make OSPF available as one of the IGP's provided with
   their routers.

この推薦の目標はインターネットIPルータのすべてのベンダーがIGPの1つによってそれらのルータに提供されたのでOSPFを利用可能にすることです。

IESG                                                            [Page 1]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[1ページ]RFC1371

Table of Contents

目次

   1. Background ....................................................  2
   2. Multiple Internet Standard Routing Protocols Possible .........  3
   3. A Common IGP ..................................................  3
   4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 3
   5. Commitment to Both IP and CLNP ................................  5
   6. Some History ..................................................  5
   7. IESG Recommendations ..........................................  6
   7.1 Regarding the Common IGP for the IP Internet .................  6
   7.2 Regarding Integrated IP/CLNP Routing .........................  7
   7.3 Limits of the Common IGP Recommendation ......................  7
   8. References ....................................................  8
   9. Security Considerations .......................................  9
   10. Author's Address .............................................  9

1. バックグラウンド… 2 2. 可能な複数のインターネット標準のルーティング・プロトコル… 3 3. 一般的なIGP… 3 4. マルチプロトコルトポロジーと統合IP/CLNPルート設定3 5の影響。 IPとCLNPの両方の委任… 5 6. 何らかの歴史… 5 7. IESG推薦… 6 7.1 IPインターネットへの一般的なIGPに関して… 6 7.2 関係はIP/CLNPルート設定を統合しました… 7 一般的なIGP推薦の7.3の限界… 7 8. 参照… 8 9. セキュリティ問題… 9 10. 作者のアドレス… 9

1. Background

1. バックグラウンド

   There is a pressing need for a high functionality non-proprietary
   "common" Interior Gateway Protocol (IGP) for the TCP/IP protocol
   family.  An IGP is the routing protocol used within a single
   administrative domain (commonly referred to as an "Autonomous System"
   (AS).

TCP/IPプロトコルファミリーに、高い機能性非独占である「一般的な」Interiorゲートウェイプロトコル(IGP)のための差し迫った必要性があります。 IGPはただ一つの管理ドメインの中で使用されたルーティング・プロトコルです。(一般的に「自律システム」(AS)と呼ばれます。

   By "common", we simply mean a protocol that is ubiquitously available
   from all router vendors (as in "in common").  Users and network
   operators have expressed a strong need for routers from different
   vendors to have the capablity to interoperate within an AS through
   use of a common IGP.

「一般的」で、私たちは単にすべてのルータベンダーから利用可能な遍在であるプロトコルを言っています(「一般的」のように)。 ユーザとネットワーク・オペレータは、ASの中に一般的なIGPの使用で共同利用するために異なったベンダーからのルータにはcapablityがある強い必要性を述べました。

   Note:  Routing between AS's is handled by a different type of routing
   protocol, called an "Exterior Gateway Protocol" ("an EGP", of which
   the Border Gateway Protocol [2] and "The Exterior Gateway Protocol"
   [3] are examples.)  The issues of routing between AS's using "an" EGP
   is not considered in this memo.

以下に注意してください。 ASのところの間のルート設定は「外のゲートウェイプロトコル」(ボーダ・ゲイトウェイ・プロトコル[2]と「外のゲートウェイプロトコル」[3]が例である「EGP」)と呼ばれる異なったタイプのルーティング・プロトコルによって扱われます。 ASが“an" EGPを使用することの間のルーティングの問題はこのメモで考えられません。

   There are two IGPs in the Internet standards track capable of routing
   IP traffic -- Open Shortest Path First (OSPF) [4] and Integrated IS-
   IS [5] (based on the OSI IS-IS). These two protocols are both modern
   "link state" routing protocols, based on the Dijkstra algorithm.
   There has been substantial interaction and cooperation among the
   engineers involved in each effort, and the protocols share some
   similar features.

に基づいて2IGPsがルーティングIPトラフィックができるインターネット標準化過程にあります--Shortest Path First(OSPF)[4]とIntegratedを開いてください、存在、[5]である、(OSI IS存在、) これらの2つのプロトコルがダイクストラアルゴリズムに基づいた両方の現代の「リンク状態」ルーティング・プロトコルです。 各取り組みにかかわる技術者の中にかなりの相互作用と協力がありました、そして、プロトコルはいくつかの同様の特徴を共有します。

   However, there are a number of technical design differences.  Most
   noteably, OSPF has been designed solely for support of the Internet
   Protocol (IP), while Integrated IS-IS has been designed to support
   both IP and the OSI Connectionless Network Layer Protocol (CLNP)

しかしながら、多くのテクニカル・デザイン差があります。 最もnoteablyに、OSPFは唯一インターネットプロトコル(IP)のサポートのために設計されています、Integratedである間-、両方がIPとOSI Connectionless Network Layerプロトコルであるとサポートするために、設計されています。(CLNP)

IESG                                                            [Page 2]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[2ページ]RFC1371

   simultaneously.

同時。

2. Multiple Internet Standard Routing Protocols Possible

2. 可能な複数のインターネット標準のルーティング・プロトコル

   The Internet architecture makes a distinction between "Interior
   Gateway Protocols (IGPs)" and "Exterior Gateway Protocols (EGPs)".
   IGPs are routing protocols used within an Autonomous System (AS), and
   EGPs are routing protocols used between different AS's.

インターネットアーキテクチャは「内部のゲートウェイプロトコル(IGPs)」と「外のゲートウェイプロトコル(EGPs)」の間で区別をします。 IGPs are routing protocols used within an Autonomous System (AS), and EGPs are routing protocols used between different AS's.

   Therefore, the Internet architecture supports the use and
   standardization of multiple IGP routing protocols.  For example, it
   is perfectly reasonable for one standard routing protocol to be used
   within one AS; while a second standard routing protocol is used
   within a second AS; at the same time that a non-standard proprietary
   routing protocol is used within a third AS.

したがって、インターネットアーキテクチャは複数のIGPルーティング・プロトコルの使用と標準化をサポートします。 例えば、1つの標準のルーティング・プロトコルが1ASの中で使用されるのは、完全に妥当です。 2番目の標準のルーティング・プロトコルは第2のASの中で使用されますが。 同じくらいでは、標準的でない独占ルーティングが議定書を作る時間は第3のASの中で費やされます。

   The primary purpose for making standards is to allow
   interoperability.  Setting a protocol standard in the Internet says,
   in effect, "if you wish to use this protocol, you should do it as
   specified in the standard so that you can interoperate with others
   who also wish to use this protocol."  It is important to understand
   that simply specifying a standard does not, by itself, designate a
   requirement to use the standard.  It is merely meant to allow
   interoperability among those who choose to follow the standard.

規格を作るためのプライマリ目的は相互運用性を許容することです。 「このプロトコルを使用するのがお望みでしたら、あなたはあなたがまた、このプロトコルを使用したがっている他のものと共に共同利用できるように規格で指定されるようにそれをするべきです。」と、事実上、インターネットにプロトコル標準をはめ込むのは言います。 単に規格を指定自体が規格を使用するという要件を指定しないのを理解しているのは重要です。 それは規格に続くのを選ぶ人の中に単に相互運用性を許容することになっています。

   Therefore, it is reasonable for both OSPF and Integrated IS-IS to be
   progressed through the Internet Standards process as appropriate
   (based on the criteria specified in [6]).  In addition, it is
   possible that other IGPs may be developed and standardized in the
   future.

インターネットStandardsを通して進行されるように、適宜処理してください。したがって、OSPFとIntegratedの両方に、それが妥当である、-、([6])で指定された評価基準に基づいています。 さらに、他のIGPsが将来開発されて、標準化されるのは、可能です。

3. A Common IGP

3. 一般的なIGP

   Although the Internet architecture allows for multiple standard IGP
   routing protocols, interoperability of router products from different
   vendors within a single AS would be greatly facilitated if a single
   "common" IGP were available from all router vendors.  Designating a
   single common IGP would have the goal of enabling multi-vendor router
   interoperation with a modern high functionality routing protocol.

インターネットアーキテクチャは平均物価標準IGPルーティング・プロトコルを考慮しますが、独身の「一般的な」IGPがすべてのルータベンダーから利用可能であるなら、独身のASの中の異なったベンダーからのルータ製品の相互運用性は大いに容易にされるでしょうに。 独身の一般的なIGPを指定するのにおいて、現代の高い機能性ルーティング・プロトコルでマルチベンダルータinteroperationを有効にするという目標があるでしょう。

   However, designating a common IGP does not mandate the use of that
   IGP, nor would it be meant to discourage the use of other IGPs in
   situations where there may be sound technical reasons to do so.

しかしながら、一般的なIGPを指定するのはそのIGPの使用を強制しません、そして、それはそうする論理的に正しい技術的な理由があるかもしれない状況における他のIGPsの使用に水をさしていることになっていないでしょう。

4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing

4. マルチプロトコルトポロジーと統合IP/CLNPルート設定の影響

   There are topology considerations which will affect the designation
   of a "common" Internet IGP.

「一般的な」インターネットIGPの名称に影響するトポロジー問題があります。

IESG                                                            [Page 3]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[3ページ]RFC1371

   The Internet requires support for a wide variety of protocol suites.
   If we consider only IP and OSI CLNP, then the Internet is expected to
   contain:

インターネットはさまざまなプロトコル群に支持を要します。 私たちがIPとOSI CLNPだけを考えるなら、インターネットが以下を含むと予想されます。

   1. Pure IP AS's (in which IP is used but OSI CLNP is not used);

1. 純粋なIP ASのもの(IPは使用されていますがそこでOSI CLNPは使用されていません)。

   2. Pure CLNP AS's (in which CLNP is used but IP is not used);

2. 純粋なCLNP ASのもの(CLNPは使用されていますがそこでIPは使用されていません)。

   3. Dual IP/CLNP ASs, with a common topology (i.e., all links and
      routers in the AS support IP and CLNP, and a single common
      topology is used for both protocol suites);

3. 一般的なトポロジーがある二元的なIP/CLNP ASs(すなわち、ASのすべてのリンクとルータはIPとCLNPをサポートします、そして、単一の一般的なトポロジーは両方のプロトコル群に使用されます)。

   4. Dual, overlapping IP/CLNP ASs with differing topologies (i.e.,
      some links are dual, while some are IP-only and some are
      CLNP-only, resulting in different topologies for IP routing and
      CLNP routing).

4. 異なったtopologies(すなわちいくつかのリンクによる二元的です、何かがそうであるのにもかかわらずの、IPだけと何かがCLNP専用であるということです、IPルーティングとCLNPルーティングのための異なったtopologiesをもたらして)と二元的で、重なっているIP/CLNP ASs。

   For (1), (i.e., a pure IP environment) any IGP capable of routing IP
   traffic could be used (e.g., OSPF or Integrated IS-IS).

(1)にルーティングIPトラフィックができるどんな(すなわち、純粋なIP環境)IGPも使用できた、(例えば、OSPFかIntegrated、-、)

   For (2), (i.e., a pure CLNP environment) any IGP capable of routing
   CLNP traffic could be used (e.g., OSI IS-IS or Integrated IS-IS).

(2)にルーティングCLNPトラフィックができるどんな(すなわち、純粋なCLNP環境)IGPも使用できた、(例えば、OSI IS存在、Integrated、-、)

   For (3), (i.e., routing environments in which both IP and CLNP are
   present in a common topology) there are two possibilities for managing
   routing:

(3)に関しては、そこの(すなわち、IPとCLNPの両方が一般的なトポロジーで現在であるルーティング環境)はルーティングを管理するための2つの可能性です:

   1. Separate routing protocols could be used for each supported
      protocol suite.  For example, OSPF may be used for calculating
      routes for IP traffic and OSI IS-IS may be used for calculating
      routes for OSI traffic.  Or Integrated IS-IS could be used for
      calculating routes for IP traffic and OSI IS-IS could be used
      for calculating routes for CLNP traffic.

1. プロトコル群であるとサポートされたそれぞれに別々のルーティング・プロトコルを使用できました。 例えば、OSPFがIPトラフィックのための計算のルートに使用されるかもしれない、OSI IS存在、OSIトラフィックのための計算のルートに使用されるかもしれません。 または、Integrated、-、IPトラフィックのための計算のルートに使用できた、OSI IS存在、CLNPトラフィックのための計算のルートに使用できました。

      This approach of using separate routing protocols and management
      for each supported protocol family has come to be known as "Ships
      in the Night" because the two routing protocols share the
      hardware/software resources of the router without ever actually
      interacting on a protocol level.

2つのルーティング・プロトコルが今までに実際にプロトコルレベルに相互作用しないでルータに関するハードウェア/ソフトウェア・リソースを共有するので、それぞれのサポートしているプロトコルファミリーに別々のルーティング・プロトコルと管理を使用するこのアプローチは「夜の船」として知られるようになりました。

   2. "Integrated routing" could be used, in which a single routing
      protocol is used for both IP and CLNP.  At this time, Integrated
      IS-IS is the only choice for "integrated routing".

2. 「統合ルーティング」(ただ一つのルーティング・プロトコルはIPとCLNPの両方に使用される)を使用できました。 このとき、Integrated、-、「統合ルーティング」のための唯一の選択はそうです。

   For (4), (i.e., routing environments in which both IP and CLNP are
   present but in an overlapping different topology) separate routing
   protocols are required for the IP and CLNP environments (i.e., "Ships
   in the Night").  This is equivalent to two separates cases of (1) and

(4)に関しては、(すなわち、存在していますが重なっている異なったトポロジーでIPとCLNPの両方ルーティング環境)別々のルーティング・プロトコルがIPとCLNP環境(すなわち、「夜の船」)に必要です。 そしてこれが(1)に関する2つのセパレーツケースに同等である。

IESG                                                            [Page 4]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[4ページ]RFC1371

   (2), but it is pointed out here as a separate case for completeness.

(2) それだけが完全性のための別件としてここに指されています。

5. Commitment to both IP and CLNP

5. IPとCLNPの両方の委任

   The IAB/IETF are committed to a timely introduction of OSI into the
   Internet.  In recognition of this commitment, the IETF has an entire
   area devoted to OSI integration.

IAB/IETFはインターネットへのOSIのタイムリーな導入に送られます。 この委任の認識では、IETFは全体の領域をOSI統合にささげさせます。

   However, while this introduction is taking place, it is essential
   that existing services based on IP be continued.  Furthermore, IESG
   also feels that even after more widespread introduction of CLNP, IP
   and CLNP will continue to coexist in the Internet for quite some
   time.  This view is consistent with the IAB goal of a multi-protocol
   Internet.

しかしながら、この序論が行われている間、IPに基づく既存のサービスが続けられているのは、不可欠です。 その上、また、CLNP、IP、およびCLNPの、より広範囲の導入が、長い間インターネットに共存し続けた後にさえIESGはそれを感じます。 この視点はマルチプロトコルインターネットのIAB目標と一致しています。

   Therefore, the IESG has a strong commitment to the continued support
   for IP throughout the Internet.  Maintenance of this IP support
   requires selection of a common IGP suitable for support of IP, and
   requires that this selection be based on operational experience.

したがって、IESGはインターネット中にIPの継続的なサポートの強い委任を持っています。 このIPサポートのメインテナンスは、IPのサポートに適した一般的なIGPの選択を必要として、この選択が運用経験に基づいているのを必要とします。

6. Some History

6. 何らかの歴史

   In February 1990, the IESG recommended that the question of
   designating a "common" IGP be postponed until more information was
   available from each protocol.  More than a year has now passed since
   the IESG's recommendation.  There have been significant advancements
   in specification, implementation, and operational experience with
   each protocol.  It is now reasonable to re-open the consideration of
   designating a "common IGP".

1990年2月に、IESGは、詳しい情報が各プロトコルから利用可能になるまで「一般的な」IGPを指定する問題が延期されることを勧めました。 IESGの推薦以来1年以上が今、経過しています。 それぞれのプロトコルの仕様、実装、および運用経験における重要な進出がありました。 「一般的なIGP」を指定する考慮を再開させるのは現在、妥当です。

   At the March 1991 meeting of the IETF, the IETF Routing Area Director
   presented a set of criteria for the advancement of routing protocols
   through the Internet standards process [6].  More information
   regarding the IAB Internet Standards process can be found in [1].

IETFの1991年3月のミーティングでは、IETFルート設定Areaディレクターはインターネット標準化過程[6]によるルーティング・プロトコルの振興のための1セットの評価基準を提示しました。 [1]でIABインターネットStandardsプロセスに関する詳しい情報を見つけることができます。

   Also, at the March 1991 meeting of the IETF, the OSPF Working Group
   requested that OSPF be considered for advancement to Draft Internet
   Standard.  The OSPF WG submitted four documents to the IETF to
   support its request:

また、IETFの1991年3月のミーティングでは、OSPF作業部会は、OSPFが前進のためにDraftインターネットStandardと考えられるよう要求しました。 OSPF WGは要求をサポートするために4通のドキュメントをIETFに提出しました:

   o a revised protocol specification to update [4];

o [4]をアップデートする改訂されたプロトコル仕様。

   o an SNMP Management Information Base (MIB);

o SNMP管理情報ベース(MIB)。

   o two technical reports giving a technical analysis and operational
     experience with OSPF.  These reports follow the format recommended
     in [6].

o OSPFのテクニカル分析を与える2つの技術報告書と運用経験。 これらのレポートは[6]のお勧めの形式に続きます。

IESG                                                            [Page 5]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[5ページ]RFC1371

   These four documents have now been published as [7, 8, 9, 10]
   respectively.

これらの4通のドキュメントが現在、[7、8、9、10]としてそれぞれ発表されました。

   In summary for OSPF:

OSPFのための概要で:

   o all features of OSPF have tested (although not all features have
     been used in operation),

o OSPFのすべての特徴がテストされました(すべての特徴が稼働中であり使用されるというわけではありませんでしたが)。

   o OSPF has been shown to operate well in several operational
     networks containing between 10 and 30 routers,

o OSPFは、10〜30のルータを含むいくつかの操作上のネットワークでよく作動するために見せられました。

   o interoperation among routers from multiple vendors has been
     demonstrated at organized "bakeoffs".

o 複数のベンダーからのルータの中のinteroperationは組織化された"bakeoffs"でデモをしました。

   In May 1991, the IAB approved the IETF/IESG recommendation to advance
   OSPF to Draft Internet Standard.

1991年5月に、IABはDraftインターネットStandardにOSPFを進めるというIETF/IESG推薦を承認しました。

   Integrated IS-IS, as specified in [5], is currently a Proposed
   Internet Standard.  In July 1991, the status of Integrated IS-IS is
   as follows:

統合、-、[5]で指定されるように、現在のProposedインターネットStandardは指定されます。 1991年7月、Integratedの状態、-、以下の通りです:

   o There are several separate implementations of integrated
     IS-IS under development,

o ある、数個が統合していた状態で実装を切り離す、-、開発中。

   o Integrated IS-IS has worked well in several multi-area operational
     networks, one containing between 20 and 30 routers,

o 統合、-、いくつかのマルチ領域の操作上のネットワークにおける井戸、20と30のルータの間のある含有を扱いました。

   o These recent operational results have not yet been fully
     documented.  Documentation, showing satisfaction of the criteria
     given in [6] for advancing routing protocols, will be submitted
     to the IESG when Integrated IS-IS is submitted for Draft Internet
     Standard status.

o これらの最近の操作上の結果はまだ完全に記録されるというわけではありませんでした。 Integratedであるときに、ルーティング・プロトコルを唱えるための[6]で与えられた評価基準の満足を示して、IESGにドキュメンテーションを提出する、-、DraftインターネットStandard状態に提出します。

7. IESG Recommendations

7. IESG推薦

7.1 Regarding the Common IGP for the IP Internet

7.1 IPインターネットへの一般的なIGPに関して

   Based on the available operational experience and the pressing need
   for a high functionality IGP for the IP protocol family, the IESG
   recommends that OSPF be designated as the common IGP for the IP
   portions of the Internet.  To help ensure that this IGP is available
   to all users, the IESG recommends that the IETF Router Requirements
   Working Group specify OSPF as "MUST IMPLEMENT" in the document
   "Requirements for Internet IP Routers".

利用可能な運用経験と高い機能性のための差し迫った必要性に基づいて、IPのためのIGPはファミリーについて議定書の中で述べて、IESGは、OSPFがインターネットのIP部分への一般的なIGPとして指定されることを勧めます。 すべてのユーザにとって、このIGPが利用可能であることを確実にするのを助けるために、IESGは、「インターネットIPルータのための要件」というドキュメントで「実装しなければならない」ときIETF Router Requirements作業部会がOSPFを指定することを勧めます。

IESG                                                            [Page 6]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[6ページ]RFC1371

7.2 Regarding Integrated Routing

7.2 統合ルート設定に関して

   As mentioned above, the IESG is commited to multiprotocol
   environments, and expects usage of OSI CLNP to increase in the
   Internet over time.

以上のように、IESGは、「マルチ-プロトコル」環境にcommitedされて、OSI CLNPの使用法が時間がたつにつれてインターネットを増やすと予想します。

   However, at this time, the IESG is not prepared to take a position
   regarding the preference of either "Ships in the Night" or Integrated
   routing for such mixed routing environments.  At this time, the
   "Ships in the Night" approach is most widely used in the Internet.
   Integrated routing has the potential advantage of reducing resource
   utilization.  However, additional operational experience is needed
   before any potential advantages can be fully evaluated.

しかしながら、このとき、IESGは、非常に複雑なルーティング環境のために「夜の船」かIntegratedルーティングのどちらかの好みを見なしながら、ポジションを持つように準備されません。 このとき、「夜の船」アプローチはインターネットで最も広く使用されます。 統合ルーティングには、リソース利用を抑える潜在的利点があります。 しかしながら、どんな潜在的利点も完全に評価できる前に追加運用経験が必要です。

   Therefore, the IESG wishes to encourage implementation of Integrated
   IS-IS so that a reasonable position can be determined based on
   operational experience.  All implementers of Integrated IS-IS are
   encouraged to coordinate their activity with the IETF IS-IS Working
   Group, which is actively collecting information on such experience.

したがって、IESGがIntegratedの実現を奨励したがっている、-、妥当な立場が運用経験に基づいて決定できるように。 Integratedのすべてのimplementers、-、彼らの活動を調整するよう奨励される、IETF IS存在、活発にそうである作業部会、そのような経験での情報集め。

7.3 Limits of the Recommendation

7.3 推薦の限界

   It is useful to recognize the limits of this recommendation.  This
   recommendation does not take a position on any of the following
   issues:

この推薦の限界を認識するのは役に立ちます。 この推薦は以下の問題のいずれでもポジションを持ちません:

   1. What IGP (if any) users should run inside an AS. Users are free to
      run any IGP they wish inside an AS.

1. IGP(もしあれば)ユーザがASの中で走らせるべきであるもの。 ユーザは彼らがASの中で願っているどんなIGPも自由に、走らせることができます。

   2. What IGP is technically superior, or has greater operational
      utility.

2. どんなIGPに、技術的に優れていますか、または、よりすばらしい操作上のユーティリティがありますか?

   3. What IGP any vendor should recommend to its users for any specific
      environment.

3. 何か業者が何か特定の環境でどんなIGPをユーザに推薦するべきですか?

   4. What IGP should be used within a CLNP-only environment.

4. どんなIGPがCLNPだけ環境の中で使用されるべきですか?

   Again, this recommendation is meant to designate one modern high
   functionality IGP that should be implemented by all vendors of
   routers for the IP portion of the Internet.  This will enable routers
   from vendors who follow this recommendation to interoperate within a
   single IP Autonomous System.

一方、この推薦はルータのすべての業者によってインターネットのIP部分に実行されるべきであるIGPに1つの現代の高い機能性を指定することになっています。 これは独身のIP Autonomous Systemの中に共同利用するというこの推薦の後をつける業者からルータを可能にするでしょう。

   It is not our intent to discourage the use of other routing protocols
   in situations where there may be sound technical reasons to do so.
   Therefore, developers of Internet routers are free to implement, and
   network operators are free to use, other Internet standard routing
   protocols, or proprietary non-Internet-standard routing protocols, as

そうする論理的に正しい技術的な理由があるかもしれない状況における他のルーティング・プロトコルの使用に水をさしているのは、私たちの意図ではありません。 したがって、インターネットルータの開発者は道具と、オペレータが無料で使用できるネットワークか、他のインターネット標準ルーティング・プロトコルか、独占非インターネット標準ルーティング・プロトコルに自由です。

IESG                                                            [Page 7]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[7ページ]RFC1371

   they wish.

彼らは願っています。

8.  References

8. 参照

   [1] Internet Activities Board, "The Internet Standards Process", RFC
       1310, IAB, March 1992.

[1] インターネット活動板、「インターネット標準化過程」、RFC1310、IAB、1992年3月。

   [2] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
       3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
       Corp., October 1991.

[2] ロッキード、K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP3)」、RFC1267、コクチマスSystems、T.J.ワトソン研究所、IBM社(1991年10月)。

   [3] Mills, D., "Exterior Gateway Protocol Formal Specification", STD
       18, RFC 904, UDEL, April 1984.

[3] 工場、D.、「外のゲートウェイプロトコル形式仕様」、STD18、RFC904、UDEL、1984年4月。

   [4] Moy, J., "OSPF Specification", RFC 1131 (Superceded by [7]),
       Proteon, October 1989.

[4]Moy、J.、「OSPF仕様」、RFC1131、(1989年10月の[7])、ProteonによるSuperceded。

   [5] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
       Environments", RFC 1195, DEC, December 1990.

[5]Callon、R.、「OSIの使用、-、TCP/IPにおけるルート設定と二元的な環境、」、RFC1195、12月、12月1990

   [6] Hinden, R., "Criteria for Standardizing Internet Routing
       Protocols", RFC 1264, BBN, October 1991.

[6]Hinden、R.、「インターネットルーティング・プロトコルを標準化する評価基準」、RFC1264、BBN、1991年10月。

   [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, July 1991.

[7]Moy、J.、「OSPF、バージョン2インチ、RFC1247、Proteon、1991インチ年7月。

   [8] Baker, F., and R. Coltun, "OSPF Version 2 Management Information
       Base", RFC 1253, ACC, Computer Science Center, August 1991.

[8] ベイカー、F.とR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1253、ACC、Computerサイエンス・センター1991年8月。

   [9] Moy, J., "Experience with the OSPF Protocol", RFC 1246, Proteon,
       July 1991.

Moy(J.)が「OSPFプロトコルで経験する」[9]、RFC1246、Proteon、1991年7月。

  [10] Moy, J., "OSPF Protocol Analysis", RFC 1245, Proteon, July 1991.

[10]Moy、J.、「OSPFプロトコル分析」、RFC1245、Proteon、1991年7月。

  [11] Internet Architecture Board, "Applicability Statement for OSPF",
       RFC 1370, IAB, October 1992.

[11]インターネット・アーキテクチャ委員会、「OSPFのための適用性証明」、RFC1370、IAB、1992年10月。

IESG                                                            [Page 8]

RFC 1371                Choosing a "Common IGP"             October 1992

「一般的なIGP」1992年10月に選ぶIESG[8ページ]RFC1371

9. Security Considerations

9. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

10. Author's Address

10. 作者のアドレス

   Phillip Gross, IESG Chair
   Advanced Network & Services
   100 Clearbrook Road
   Elmsford, NY

フィリップGross、IESGの議長の高度なネットワーク、およびサービス100Clearbrook Roadエルムスフォード(ニューヨーク)

   Phone: 914-789-5300
   EMail: pgross@ans.net

以下に電話をしてください。 914-789-5300 メールしてください: pgross@ans.net

IESG                                                            [Page 9]

IESG[9ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

横画面に固定する、縦画面に固定する(表示モードの固定)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る