RFC1467 日本語訳

Network Working Group                                        C. Topolcic
Request for Comments: 1467                                          CNRI
Obsoletes: 1367                                              August 1993

Topolcicがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1467CNRIは以下を時代遅れにします。 1367 1993年8月

               Status of CIDR Deployment in the Internet

インターネットでのCIDR展開の状態

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.

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

Abstract

要約

   This document describes the current status of the development and
   deployment of CIDR technology into the Internet. This document
   replaces RFC 1367, which was a schedule for the deployment of IP
   address space management procedures to support route aggregation.
   Since all the milestones proposed in RFC 1367 except for the delivery
   and installation of CIDR software were met, it does not seem
   appropriate to issue an updated schedule. Rather, this document is
   intended to provide information about how this effort is proceeding,
   which may be of interest to the community.

このドキュメントは開発の現在の状態とCIDR技術の展開についてインターネットに説明します。 このドキュメントはRFC1367を取り替えます。(RFCはIPアドレス空間管理手順の展開がルート集合をサポートするスケジュールでした)。 CIDRソフトウェアの配送とインストール以外のRFC1367で提案されたすべての重大事件が満たされたので、アップデートされたスケジュールを発行するのは適切に思えません。 むしろ、このドキュメントがこの取り組み(共同体に興味があるかもしれない)がどう続くかの情報を提供することを意図します。

1. Background

1. バックグラウンド

   The Internet's exponential growth has led to a number of difficulties
   relating to the management of IP network numbers.  The administrative
   overhead of allocating ever increasing volumes of IP network numbers
   for global users has stressed the organizations that perform this
   function.  The volume of IP network numbers that are reachable
   through the Internet has taxed a number of routers' ability to manage
   their forwarding tables.  The poor utilization of allocated IP
   network numbers has threatened to deplete the Class A and Class B
   address space.

インターネットの急激な増加はIPネットワーク・ナンバーの管理に関連することにおける多くの苦労につながりました。 グローバルなユーザのIPネットワーク・ナンバーの量を増加に割り当てる管理オーバーヘッドはこの機能を実行する組織を強調しました。 インターネットを通して届いているIPネットワーク・ナンバーのボリュームはそれらの推進テーブルを管理するルータの能力の数に税をかけました。 割り当てられたIPネットワーク・ナンバーの不十分な利用は、Class AとClass Bアドレス空間を使い果たすと脅かしました。

   During the past few years, a consensus has emerged among the Internet
   community in favor of a number of mechanisms to relieve these
   problems for the mid-term.  These mechanisms are expected to be put
   into place in the short term and to provide relief for the mid-term.
   Fundamental changes to the Internet protocols to ensure the
   Internet's continued long term growth and well being are being
   explored and are expected to succeed the mid-term mechanisms.

過去数年間、コンセンサスは、多くのメカニズムを支持して中間試験のためにこれらの問題を救うためにインターネットコミュニティの中に現れています。 これらのメカニズムは、短期で場所に入れられて、中間試験への救援を提供すると予想されます。 インターネットの継続的な長期の成長と幸福を確実にするインターネットプロトコルへの根本的変化は、探検されていて、中期のメカニズムを引き継ぐと予想されます。

   The global Internet community have been cooperating closely in such
   forums as the IETF and its working groups, the IEPG, the NSF Regional
   Techs Meetings, INET, INTEROP, FNC, FEPG, and other assemblies in

世界的なインターネット共同体は中で密接にIETF、ワーキンググループ、IEPG、NSF Regional Techs Meetings、INET、INTEROP、FNC、FEPG、および他のアセンブリのようなフォーラムに協力しています。

Topolcic                                                        [Page 1]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[1ページ]RFC1467状態

   order to ensure the continued stable operation of the Internet.
   Recognizing the need for the mid-term mechanisms and receiving
   support from the Internet community, the US Federal Agencies proposed
   procedures to assist the deployment of these mid-term mechanisms.
   These procedures were originally described in RFC 1366 [1], which was
   recently made obsolete by RFC 1466 [2].  In October 1992, a schedule
   was proposed for the implementation of the procedures, described in
   RFC 1367 [3].

注文して、インターネットの継続的な安定稼働を確実にしてください。 中期のメカニズムの必要性を認識して、インターネットコミュニティからサポートを受けて、米国の連邦政府のAgenciesは、これらの中期のメカニズムの展開を促進するために手順を提案しました。これらの手順は元々、RFC1366[1]で説明されました。([1]は最近、RFC1466[2]によって時代遅れにされました)。 1992年10月に、スケジュールはRFC1367[3]で説明された手順の実装のために提案されました。

2. Milestones that have been met

2. 満たされた重大事件

   Most of the milestones of the proposed schedule were implemented on
   time. These milestones are shown below, essentially as they appear in
   [3], but with further comment where appropriate:

提案されたスケジュールの重大事件の大部分は定刻に実装されました。 これらの重大事件は適切であるところにコメントにもかかわらず、[3]に本質的には現れますが、さらなるコメントで示されます:

      1) 31 October 92:

1) 1992年10月31日:

         The following address allocation procedures were continued:

以下のアドレス配分手順は続けられていました:

         a) Initial set of criteria for selecting regional address
            registries were put into place, and requests from
            prospective regional registries were accepted by the
            IANA.

a) 地方のアドレス登録を選択するための始発の評価基準を場所に入れました、そして、IANAは将来の地方の登録からの要求を受け入れました。

            The Reseaux IP Europeens Network Coordination Centre
            (RIPE NCC) requested to become a regional registry.
            As per the addressing plan of RFC 1366, the RIPE NCC
            was given the block 194.0.0.0 to 195.255.255.255 to
            administer for the European Internet community. The RIPE
            NCC had previously and independently obtained the block
            193.0.0.0 to 193.255.255.255. Although this block had been
            allocated before RFC 1366, the RIPE NCC was able to manage
            it according to the guidelines in RFC 1366.

Europeens Network Coordination Centre(RIPE NCC)が地方の登録になるよう要求したReseaux IP。 RFC1366のアドレシングプランに従ってブロックをRIPE NCCに与えた、194.0、.0、.0、195.255 .255 .255 ヨーロッパのインターネットコミュニティのために管理するために。 RIPE NCCは以前に、独自に.0〜193.255にブロック193.0.0を得ました。.255 .255。 RFC1366の前にこのブロックを割り当てましたが、RFC1366のガイドラインによると、RIPE NCCはそれに対処できました。

         b) Class A network numbers were put on reserve for possible
            future use. The unreserved Class A numbers became very
            difficult to obtain.

b) クラスAネットワーク・ナンバーは可能な今後の使用のための蓄えに置かれました。 無遠慮なClass A番号は得るのが非常に難しくなりました。

         c) Class B network numbers were issued only when
            reasonably justified.  Whenever possible, a block of C's
            was issued rather than a B. The requirements for
            allocating a Class B became progressively more constrained
            until the date in step (3).

c) 合理的に正当化される場合にだけ、クラスBネットワーク・ナンバーは発行されました。 可能であるときはいつも、B.よりむしろ1ブロックのCのものを発行しました。Class Bを割り当てるための要件はステップ(3)でさらに次第に日付まで抑制されるようになりました。

Topolcic                                                        [Page 2]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[2ページ]RFC1467状態

         d) Class C network numbers were allocated according to the
            addressing plan of [1], now obsoleted by [2].  Allocation
            continued to be performed by the Internet Registry (IR)
            for regions of the world where an appropriate regional
            registry had not yet been designated by the IANA.

d) 現在[2]によって時代遅れにされている[1]のアドレシング計画通りにクラスCネットワーク・ナンバーを割り当てました。 配分は、インターネットRegistry(IR)によって適切な地方の登録がIANAによってまだ指定されていなかった世界の領域に実行され続けていました。

      2) 14 February 93:

2) 1993年2月14日:

         The schedule in [3] was re-evaluated, and there appeared to
         be no reason to readjust it, so it was continued as
         originally set out.

[3]でのスケジュールは再評価されて、それを再調整する理由が全くあるように見えなかったので、それは元々出されるように続けられていました。

      3) 15 April 93:

3) 1993年4月15日:

         a) The IR began to allocate all networks according to the
            addressing plan of [1], now obsoleted by [2], in
            appropriately sized blocks of Class C numbers.

a) 現在[2]によって時代遅れにされている[1]のアドレシング計画通りにIRは適切に大きさで分けられたブロックのClass C番号ですべてのネットワークを割り当て始めました。

         b) Class B network numbers became difficult to obtain,
            following the recommendation of the addressing plan and
            were only issued when justified.

b) クラスBネットワーク・ナンバーは、アドレシングプランの推薦に続いて、得るのが難しくなって、正当化されると、発行されただけです。

   Furthermore, throughout this time period, network service providers
   have requested blocks of network numbers from the Class C address
   space for the purpose of further allocating them to their clients.
   The network service providers were allocated such space by the RIPE
   NCC or the IR, acting for North America and the Pacific Rim. This
   process has started to distribute the function of address
   registration to a more regional level, closer to the end users. The
   process has operated as hoped for, with no major problems.

その上、この期間の間中、ネットワークサービスプロバイダーはさらに彼らを割り当てる目的のためのClass Cアドレス空間から彼らのクライアントまでブロックのネットワーク・ナンバーを要求しました。 RIPE NCCかIRでそのようなスペースをネットワークサービスプロバイダーに割り当てました、北アメリカと環太平洋地域の代理をして。 このプロセスはアドレス登録の機能をより地方のレベルに分配し始めました、エンドユーザにより近いです。 プロセスは大した問題なしで期待されるように作動しました。

3. Milestone that has not been met

3. 満たされていない重大事件

   The proposed schedule of [3] stated that 6 June 1993 was the date
   when an address aggregation mechanism would be generally available in
   the Internet. Although this target date was based on the plans as
   stated by the router vendors and was reasonable at the time the
   schedule in [3] was formulated, it has slipped.  Nevertheless, the
   continuation of that schedule has so far not added significantly to
   the problems of the Internet. The rest of this document looks at the
   current situation and what can be expected in the near future.

[3]の提案されたスケジュールは、1993年6月6日がインターネットの一般に、アドレス凝集機構が利用可能である日付であると述べました。 この目標期日は、ルータベンダーによる述べられるとしてのプランに基づいて、[3]でのスケジュールが定式化されたとき、妥当でしたが、それは滑りました。 それにもかかわらず、そのスケジュールの継続は今までのところ、インターネットの問題にかなり少ししかないです。 このドキュメントの残りは現在の状況と近い将来予想できるものを見ます。

4. Current status of address aggregation mechanisms in commercial
   routers

4. 商業ルータにおけるアドレス凝集機構の現在の状態

   Although RFCs 1366, 1466, and 1367 do not depend on any specific
   address aggregation technology, there is consensus in the Internet
   community to use Classless Inter-Domain Routing (CIDR) [4]. CIDR is

RFCs1366、1466、および1367はどんな特定のアドレス集合技術にもよりませんが、Classless Inter-ドメインルート設定(CIDR)[4]を使用するために、コンセンサスがインターネットコミュニティにあります。 CIDRはそうです。

Topolcic                                                        [Page 3]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[3ページ]RFC1467状態

   supported by BGP-4 and IDRP. Most router vendors are working on BGP-
   4, first, and there is a consensus to use BGP-4 to support the
   initial deployment of CIDR in the Internet.

BGP-4とIDRPによってサポートされます。 ほとんどのルータベンダーが最初にBGP4に取り組んでいる予定です、そして、インターネットでのCIDRの初期の展開をサポートするのにBGP-4を使用するコンセンサスがあります。

   The following paragraphs describe the implementation status and plans
   of software to support CIDR in various router vendors' products,
   listed in alphabetical order.  Some speculation is necessarily
   involved in deriving these projections.  See also the minutes of the
   July 1993 meeting of the BGP Deployment Working Group of the IETF
   [5].

以下のパラグラフはソフトウェアがアルファベット順に記載された様々なルータベンダーの製品の中にCIDRをサポートする実装状態と計画について説明します。 何らかの思惑が必ずこれらの映像を引き出すのにかかわります。 また、IETF[5]のBGP Deployment作業部会の1993年7月のミーティングの議事録に遭遇してください。

   3Com's BGP-4 code has been tested internally. They have code that
   accepts, forwards and manages aggregated routes properly, and they
   are ready to test it for interoperability with other vendors. They
   have yet to implement the code that forms the route aggregates. They
   expect to have Beta code done by September, and full release code
   shortly thereafter. The initial implementation will not support de-
   aggregation.  Their plans here are not yet formulated. They will
   support de-aggregation if necessary.

3ComのBGP-4コードは内部的にテストされました。 彼らには、適切に集められたルートを受け入れて、進めて、管理するコードがあります、そして、それらは他のベンダーと共に相互運用性がないかどうかそれをテストする準備ができています。 彼らはまだルート集合を形成するコードを実装していません。 彼らは、その後まもなく9月、および完全なリリースコードでBetaコードをさせると予想します。 初期の実装は反-集合をサポートしないでしょう。 ここのそれらのプランはまだ定式化されていません。 必要なら、彼らは反-集合をサポートするでしょう。

   ANS has a BGP-4 implementation that is being tested internally.  It
   is stable enough to begin testing for interoperability with other
   vendors' implementations.  Depending of the results of
   interoperability testing, this code could be deployed into the ANSNET
   by August.  This delay is primarily because some routers are running
   older code, and they all need to be upgraded to GATED before they can
   all support BGP-4 internally. So the ability to support CIDR looks
   like it is about one to two months away. This code will not support
   controlled de-aggregation, but de-aggregation will be supported if
   necessary.

ANSには、内部的にテストされているBGP-4実装があります。 それは相互運用性がないかどうか他のベンダーの実装でテストし始めるほど安定しています。 相互運用性がテストされるという結果をよって、8月までにこのコードをANSNETに配布することができました。 この遅れは主として、いくつかのルータが実行しているより古いコードであり、それらが皆、内部的にBGP-4をサポートすることができる前にGATEDにアップグレードする必要があるからです。 それで、CIDRをサポートする能力は、それがおよそ1〜2カ月後にあるように見えます。 このコードは制御反-集合をサポートしないでしょうが、必要なら、反-集合はサポートされるでしょう。

   BBN plans to complete it's development of BGP-4 by early Summer 1994.
   Initial plans are to implement both aggregation and controlled de-
   aggregation with an early release of the software.

前のSummer1994によるBGP-4の開発ですそれを完成するBBN計画が。 初期のプランはソフトウェアの早めのリリースで集合と制御反-集合の両方を実装することです。

   Cisco's BGP-4 implementation is under development at this time.
   There is pre-Beta code available for people to begin testing.  It is
   expected that the code will be stable sometime during the summer of
   1993 and will be made available for limited deployment at that time.
   This BGP-4 code will implement aggregation. It will not be part of
   the normal release cycle at this time.  It will be available in a
   special software release based on the 9.21 release. This initial
   BGP-4 code will not implement controlled de-aggregation, but Cisco
   plans on implementing de-aggregation.

シスコのBGP-4実装はこのとき、開発中です。 人々がテストし始めるように利用可能なプレBetaコードがあります。 コードをいつか、1993年夏の間、安定して、その時限られた展開のために利用可能にすると予想されます。 このBGP-4コードは集合を実装するでしょう。 このとき、それは正常なリリースサイクルの一部でなくなるでしょう。 それはリリースが9.21にリリースを基礎づけた特別なソフトウェアで利用可能になるでしょう。 この初期のBGP-4コードは制御反-集合を実装しないでしょうが、シスコは、反-集合を実装するのを計画します。

   Proteon's BGP-4 code has been tested internally. They are ready to
   test it for interoperability with other vendors. If this works out
   reasonably well, then it is reasonable to expect that they can start

ProteonのBGP-4コードは内部的にテストされました。 それらは他のベンダーと共に相互運用性がないかどうかそれをテストする準備ができています。 これが合理的に井戸を解決するなら、彼らが出発できると予想するのは妥当です。

Topolcic                                                        [Page 4]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[4ページ]RFC1467状態

   to deploy this as Beta code by August, with a target of full release
   in the fall. This initial implementation will not support aggregation
   or de-aggregation. Aggregation will be implemented soon thereafter,
   but their plans for de-aggregation are not yet formulated.  They will
   implement de-aggregation if necessary.

秋に8月までにBetaコードとして完全なリリースの目標でこれを配布するために。 この初期の実装は集合か反-集合をサポートしないでしょう。 集合はその後、すぐ、実装されるでしょうが、反-集合のためのそれらのプランはまだ定式化されていません。 必要なら、彼らは反-集合を実装するでしょう。

   Wellfleet is aiming at having beta code implementing BGP-4 roughly in
   early 1994. This code will include controlled de-aggregation.

Wellfleetは1994年前半におよそBGP-4を実装するベータコードを持っているのを目的としています。 このコードは制御反-集合を含むでしょう。

5. Rate of growth

5. 成長率

   MERIT periodically publishes the number of networks in the
   NSFNET/ANSNET policy routing database.  Analysis of this data
   suggests that the number of entries in this database is growing at
   approximately 8% per month, or doubling every nine or ten months [6].

MERITは定期的にNSFNET/ANSNET方針ルーティングデータベースのネットワークの数を発行します。 このデータの分析は、このデータベースのエントリーの数が1カ月あたりおよそ8%で成長するか、または9カ月か10カ月[6]毎に倍増しているのを示します。

   Although there are currently over 13K networks in the NSFNET/ANSNET
   policy routing database, a number of them are not active. That is,
   they are not announced to the NSFNET/ANSNET Backbone. The 10K active
   network point was passed in late June. Assuming that the number of
   active networks continues to grow at the same rate as in the past, it
   can be projected that the 12K active network point will be reached
   sometime in approximately late September 1993 and that the 25K active
   network point will be reached sometime in mid-94 (two high water
   marks whose relevance will become apparent below).

現在、NSFNET/ANSNET方針ルーティングデータベースには13K以上のネットワークがありますが、それらの数はアクティブではありません。 すなわち、それらはNSFNET/ANSNET Backboneに発表されません。 10Kのアクティブなネットワークポイントは6月の下旬に通過されました。 活動的なネットワークの数が続くと過去に12Kのアクティブなネットワークポイントに9月の1993下旬のいつか、達して、25Kの活動的なネットワークが指すと予測できるのに従って同じ速度で育てる仮定するのに中間の94(関連性が以下で明らかになる2つの最高水位線)におけるいつか、達するでしょう。

   The NSFNET/ANSNET routing database includes only those networks that
   meet the NSF Acceptable Use Policy (AUP) or the ANSNET CO+RE AUP.
   There are a number of networks connected to the Internet that do not
   meet these criteria. Although they are not in the NSFNET/ANSNET
   routing database, they are in the forwarding tables of a number of
   network providers. Currently, the number of networks that are
   connected to other known service providers but are not in the
   NSFNET/ANSNET routing database is significantly smaller than (less
   than 25% of) the number that are in the NSFNET/ANSNET database. There
   is no estimate available for the rate of growth of the number of such
   non-NSFNET/ANSNET networks. It is assumed here that the growth rate
   of these networks is approximately the same as that of AUP networks
   in the NSFNET/ANSNET routing database.

NSFNET/ANSNETルーティングデータベースはNSF Acceptable Use Policy(AUP)かANSNET CO+RE AUPに会うそれらのネットワークだけを含んでいます。 これらの評価基準を満たさないインターネットに接続したネットワークの数があります。 NSFNET/ANSNETルーティングデータベースにいませんが、彼らは多くのネットワーク内の提供者の推進テーブルにいます。 現在他の知られているサービスプロバイダーに関連づけられますが、NSFNET/ANSNETルーティングデータベースにないネットワークの数がかなり少ない、(25%未満、)、NSFNET/ANSNETデータベースにある数。 そのような非NSFNET/ANSNETネットワークの数の成長率に有効などんな見積りもありません。 ここで、これらのネットワークの成長率がNSFNET/ANSNETルーティングデータベースでAUPネットワークのものとほとんど同じであると思われます。

   Analysis of the more than 13K networks in the NSFNET/ANSNET routing
   database, as well as the allocated but unconnected networks, suggests
   that CIDR deployment should have a significant impact on the number
   of forwarding table entries that any router needs to maintain, and
   its rate of growth.  However, an in-depth study was begun at the July
   1993 meeting of the BGP Deployment Working Group of the IETF [5] to
   (among other goals) evaluate the impact of CIDR on the growth rate of
   router forwarding tables.

NSFNET/ANSNETルーティングデータベース、および割り当てられましたが、無関係のネットワークにおける、13K以上のネットワークの分析は、CIDR展開がどんなルータも維持する必要があるテーブル項目、およびその成長率を進める数で重要な影響を与えるべきであると示唆します。 しかしながら、IETF[5]のBGP Deployment作業部会は、1993年7月にルータ推進テーブルの成長率でCIDRの影響を評価する(他の目標の中で)ために綿密な研究と会合され始めました。

Topolcic                                                        [Page 5]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[5ページ]RFC1467状態

6. Capacity of deployed networks

6. 配布しているネットワークの容量

   The following paragraphs describe the current occupancy of the
   forwarding tables of the routers of several transit network providers
   and their expected capacities and an estimate of the time when that
   capacity would be reached if the growth rate were to continue as
   today. This list is a subset of all relevant providers, but is
   considered approximately representative of the situation of other
   network providers. It is shown in alphabetical order.

以下のパラグラフはいくつかのトランジットネットワーク内の提供者と彼らの予想された能力のルータと成長率が今日として続くならその容量に達している時の見積りの推進テーブルの現在の占有について説明します。 このリストは、すべての関連プロバイダーの部分集合ですが、他のネットワーク内の提供者の状況をほとんど代表すると考えられます。 それはアルファベット順に示されます。

   ALTERNET nodes are Cisco routers, and currently carry approximately
   11K to 12K routes, both AUP and non-AUP. With their current
   configuration, they have enough memory so that they are expected to
   support up to approximately 35K routes.  If the rate at which the
   number of these routes is expected to grow is approximately the same
   as the rate that the NSFNET/ANSNET policy routing database is
   growing, then this number may be reached in late 1994.  However, if
   the growth rate continues unchecked, it is expected that the
   processing capacity of the routers will be surpassed before their
   memory is exhausted. It is expected that CIDR will be in place long
   before this point is reached.

ALTERNETノードは、シスコルータであり、現在、およそ11Kから12Kのルート、AUPと非AUPの両方を載せます。 それらの現在の構成によって、彼らには十分な記憶力があるので、彼らが、最大およそ35Kがルートであるとサポートすると予想されます。 これらのルートの数が成長すると予想されるレートがNSFNET/ANSNET方針ルーティングデータベースが育てているレートとほとんど同じであるなら、この数に1994年後半に達するかもしれません。 しかしながら、成長率が抑制されない状態で続くなら、彼らの記憶が疲れ果てている前にルータの処理容量が凌がれると予想されます。 このポイントに達しているずっと前にCIDRが適所にあると予想されます。

   All ANSNET routers have recently been upgraded to AIX 3.2. This
   version supports up to 12K networks.  These routers currently carry
   only the active networks in the NSFNET/ANSNET routing database.  It
   is anticipated that the next version of router code will be deployed
   before September 1993, the projected date for when there will be 12K
   active networks.  This version will support 25K active networks.
   Although there are no current plans for a version of router code that
   supports more than 25K networks, it is believed that CIDR will help
   this situation.

すべてのANSNETルータが最近、AIX3.2にアップグレードしました。 このバージョンは、最大12Kがネットワークであるとサポートします。 これらのルータは現在、NSFNET/ANSNETルーティングデータベースで活動的なネットワークだけを運びます。 ルータコードの次のバージョンが1993年9月(12Kの活動的なネットワークがある時の映し出された期日)以前配布されると予期されます。 このバージョンは、25Kが活動的なネットワークであるとサポートするでしょう。 25K以上がネットワークであるとサポートするルータコードのバージョンのためのどんな現在のプランもありませんが、CIDRがこの状況を助けると信じられています。

   EBONE nodes are Cisco routers. They currently carry approximately 10K
   to 11K routes. With their current configuration, they may be able to
   support approximately 40K routes. However, the number of paths may be
   very relevant. The memory required for the BGP table (rather than the
   forwarding table) is a function of the number of paths.  If a new
   transatlantic link were to be added, EBONE could receive all the
   North American routes through it. This would add a new set of paths.
   Each such transatlantic link would increase the memory required by
   approximately 20%. Due to the network topology between North America
   and Europe, new transatlantic links tend to result in new paths, and
   therefore significant memory requirements. It is very difficult to
   predict the addition of future transatlantic links because they
   result from business or political requirements, not bandwidth
   requirements.

EBONEノードはシスコルータです。 彼らは現在、およそ10Kから11Kのルートを運びます。 自分達の現在の構成で、彼らはおよそ40Kのルートを支えることができるかもしれません。 しかしながら、パスの数は非常に関連しているかもしれません。 BGPテーブル(推進テーブルよりむしろ)に必要であるメモリはパスの数の関数です。 新しい大西洋横断のリンクが加えられることになっているなら、EBONEはそれを通してすべての北米のルートを受けることができるでしょうに。 これは新しいセットの経路を加えるでしょう。 そのようなそれぞれの大西洋横断のリンクはおよそ20%によって必要とされたメモリを増加させるでしょう。 北アメリカとヨーロッパの間のネットワーク形態のため、新しい大西洋横断のリンクは新しい経路をもたらして、したがって、重要なメモリ要件をもたらす傾向があります。 帯域幅要件ではなく、ビジネスか政治上の要件から生じるので、将来の大西洋横断のリンクの添加を予測するのは非常に難しいです。

Topolcic                                                        [Page 6]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[6ページ]RFC1467状態

   ESNET uses Cisco routers. However, it is already in trouble, but not
   because of the size of the forwarding tables. The problem is its need
   to maintain considerable configuration information describing which
   networks it should or should not accept from its neighbors, and the
   fact that this information must be stored in a non-volatile memory of
   limited size. CIDR aggregation is expected to help this problem.
   Also, ESNET plans to deploy BGP-4 and CIDR only after it is in a full
   release, so does not plan to participate in the initial BGP-4
   deployment. ESNET will upgrade their nodes to Cisco CSC-4's in the
   meantime.

ESNETはシスコルータを使用します。 しかしながら、それは、既に困ったことになりますが、推進テーブルのサイズで困ったことになるというわけではありません。 問題はそれがどのネットワークを受け入れるべきであるか、または隣人から受け入れるべきでないかを説明するかなりの設定情報、および限られたサイズに関する非揮発性メモリーにこの情報を格納しなければならないという事実を維持するその必要性です。 CIDR集合がこの問題を助けると予想されます。 また、それが完全なリリースにあった後にだけBGP-4とCIDRを配備するのを計画しているので、ESNETは、初期のBGP-4展開に参加するのを計画していません。 ESNETは差し当たりシスコCSC-4のものに彼らのノードをアップグレードさせるでしょう。

   All SPRINTLINK and ICM nodes have recently been upgraded to Cisco
   CSC-4 routers with 16MB of memory. They will carry full routing,
   including not only the routes that the NSFNET/ANSNET carries, but
   also routes to networks that do not comply with the NSF or CO+RE
   AUPs. The SPRINT routers currently carry approximately 11K to 12K
   routes, and it is expected that they will be able to support up to
   approximately 25K routes, as currently configured. The 25K announced
   network point may be reached in approximately mid-1994. Again, it is
   expected that CIDR deployment will have a significant impact on this
   growth rate, well before this time.

すべてのSPRINTLINKとICMノードは最近、16MBのメモリでシスコCSC-4ルータにアップグレードしました。 彼らは完全なルーティングを運ぶでしょう、NSFかCO+RE AUPsに従わないネットワークにNSFNET/ANSNETが運ぶルートだけではなく、ルートも含めて。 スプリントルータは現在およそ11Kから12Kのルートを運びます、そして、ルートをおよそ25Kまで支えることができると予想されます、現在構成されているとして。 25Kは、ネットワークポイントに1994年中頃頃に達するかもしれないと発表しました。 一方、CIDR展開がよく今回以前重要な影響をこの成長率に与えると予想されます。

7. Acknowledgements

7. 承認

   This report contains information from a number of sources, including
   vendors, operators, researchers, and organizations that foster
   cooperation in the Internet community. Specific organizations include
   the Intercontinental Engineering and Planning Group (IEPG), the BGP-4
   Deployment Working Group of the IETF, the Federal Networking Council
   (FNC), and the FNC Engineering and Planning Group (FEPG). Specific
   individuals include, in alphabetical order, Arun Arunkumar, Tony
   Bates, Mary Byrne, Bob Collet, Mike Craren, Dennis Ferguson, Tony
   Hain, Elise Gerich, Mark Knopper, John Krawczyk, Tony Li, Peter
   Lothberg, Andrew Partan, Gary Rucinski, Frank Solensky, and Jessica
   Yu. This report would not have been possible without the willingness
   of these people to make their information public for the good of the
   community.

このレポートは多くのソースからの情報を含んでいます、インターネットコミュニティへの協力を伸ばす業者、オペレータ、研究者、および組織を含んでいて。 特定の組織はIntercontinental Engineering、Planning Group(IEPG)、IETFのBGP-4 Deployment作業部会、連邦ネットワーキング協議会(FNC)、FNC Engineering、およびPlanning Group(FEPG)を含んでいます。 特定の個人はアルファベット順でアルンArunkumar、トニー・ベイツ、メアリ・バーン、ボブCollet、マイクCraren、デニスファーガソン、トニー・ハイン、エリーズGerich、マークKnopper、ジョンKrawczyk、トニー・李、ピーターLothberg、アンドリューPartan、ゲーリーRucinski、フランクSolensky、およびジェシカ・ユーを入れます。 このレポートはこれらの人々が彼らの情報を共同体の利益に公共にする意欲なしで可能でなかったでしょう。

8. References

8. 参照

   [1] Gerich, E., "Guidelines for Management of IP Address Space",
       RFC 1366, Merit, October 1992.

[1]Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1366)が1992年10月に値するE.。

   [2] Gerich, E., "Guidelines for Management of IP Address Space",
       RFC 1466, Merit, May 1993.

[2]Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1466)が1993年5月に値するE.。

   [3] Topolcic, C., "Schedule for IP Address Space Management
       Guidelines", RFC 1367, CNRI, October 1992.

Topolcic(C.)が「IPアドレス空間管理ガイドラインのために計画をする」[3]、RFC1367、CNRI、1992年10月。

Topolcic                                                        [Page 7]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[7ページ]RFC1467状態

   [4] Fuller, V. et al, "Classless Inter-Domain Routing (CIDR): an
       Address Assignment and Aggregation Strategy", working draft
       obsoleting RFC 1338, BARRNet, February 1993.

[4] フラー、V.他、「以下を掘る(CIDR)階級のない相互ドメイン」 「BARRNet、概要版がRFC1338を時代遅れにする2月1993日Address AssignmentとAggregation Strategy」

   [5] Yu, J., "Minutes of the BGP Deployment Working Group
       (BGPDEPL)", MERIT, July 1993.

ユー、J.、「BGP展開作業部会(BGPDEPL)の議事録」が1993年7月に値する[5]。

   [6] Solensky, F., Internet Growth Charts, "big-internet" mailing
       list, munnari.oz.au:big-internet/nsf-netnumbers-<yymm>.ps

[6]Solensky、F.、インターネットGrowth Charts、「大きいインターネット」メーリングリスト、munnari.oz.Au: nsf-netnumbers大きいインターネット/<yymm>.ps

9. Other relevant documents

9. 他の関連ドキュメント

       Huitema, C., "IAB Recommendation for an Intermediate Strategy
       to Address the Issue of Scaling", RFC 1481, Internet
       Architecture Board, July 1993.

Huitema、C.、「中間的戦略がスケーリングの問題を記述するというIAB推薦」、RFC1481、インターネット・アーキテクチャ委員会(1993年7月)

       Knopper, M., "Minutes of the NSFNET Regional Techs Meeting",
       working draft, MERIT, June 1993.

Knopper、M.、「NSFNETの地方の技術者ミーティングの議事録」、概要版、MERIT、1993年6月。

       Knopper, M., and Richardson, S., " Aggregation Support in the
       NSFNET Policy-Based Routing Database", RFC 1482, MERIT, June
       1993.

「NSFNETの方針ベースのルート設定データベースにおける集合サポート」、RFC1482が1993年6月に値するKnopper、M.とリチャードソン、S.。

       Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11
       March 93", working draft, CNRI, March 1993.

Topolcic、C.、「1993年3月11日のBGP-4/CIDR調整会議の注意」、概要版、CNRI、1993年3月。

       Rekhter, Y., and Topolcic, C., "Exchanging Routing Information
       Across Provider/Subscriber Boundaries in the CIDR Environment",
       working draft, IBM Corp., CNRI, April 1993.

C. Rekhter、Y.、およびTopolcic、概要版、IBM社、「CIDR環境におけるプロバイダー/加入者境界の向こう側に経路情報を交換する」CNRI(1993年4月)。

       Rekhter, Y., and Li, T., "An Architecture for IP Address
       Allocation with CIDR", working draft, IBM Corp., cisco Systems,
       February 1993.

Rekhter、Y.、および李、T.、「CIDRとのIPアドレス配分のための構造」、概要版、IBM社、コクチマスSystems(1993年2月)。

       Gross, P., and P. Almquist, "IESG Deliberations on Routing and
       Addressing", RFC 1380, IESG, November 1992.

グロス、P.、およびP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」、RFC1380、IESG、1992年11月。

Topolcic                                                        [Page 8]

RFC 1467       Status of CIDR Deployment in the Internet     August 1993

インターネット1993年8月のCIDR展開のTopolcic[8ページ]RFC1467状態

10. Security Considerations

10. セキュリティ問題

   Security issues are not discussed in this memo.

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

11. Author's Address

11. 作者のアドレス

   Claudio Topolcic
   Corporation for National Research Initiatives
   895 Preston White Drive, Suite 100
   Reston, VA  22091

レストン、Suite100ヴァージニア 国家の研究イニシアチブ895のプレストンの白いドライブ、22091へのクラウディオTopolcic社

   Phone: (703) 620-8990
   EMail: topolcic@CNRI.Reston.VA.US

以下に電話をしてください。 (703) 620-8990 メールしてください: topolcic@CNRI.Reston.VA.US

Topolcic                                                        [Page 9]

Topolcic[9ページ]