RFC1482 日本語訳

Network Working Group                                   Mark Knopper
Request for Comments: 1482                      Steven J. Richardson
                                                        Merit/NSFNET
                                                           June 1993

ネットワークワーキンググループマークKnopperはコメントのために以下を要求します。 1482 スティーブンJ.リチャードソン長所/NSFNET1993年6月

    Aggregation Support in the NSFNET Policy-Based Routing Database

NSFNETの方針ベースのルート設定データベースにおける集合サポート

Status of this 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 plans for support of route aggregation, as
   specified in the descriptions of Classless Inter-Domain Routing
   (CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone Network
   Service.  Mechanisms for exchange of route aggregates between the
   backbone service and regional/midlevel networks are specified.
   Additionally, the memo proposes the implementation of an Aggregate
   Registry which can be used by network service providers to share
   information about the use of aggregation.  Finally, the operational
   impact of incorporating CIDR and aggregation is considered, including
   an analysis of how routing table size will be affected.  This impact
   analysis will be used to modify the deployment plan, if necessary, to
   maximize operational stability.

このドキュメントはルート集合のサポートのためのプランについて説明します、Classless Inter-ドメインルート設定(CIDR)[1]の記述とBGP-4プロトコル[2]で指定されるように、NSFNET Backbone Network Service。 背骨サービスと地方の、または、中間レベルのネットワークの間のルート集合の交換のためのメカニズムは指定されます。 さらに、メモはネットワークサービスプロバイダーが集合の使用の情報を共有するのに使用できるAggregate Registryの実現を提案します。 最終的に、CIDRと集合を組み込む操作上の衝撃は考えられます、経路指定テーブルサイズがどう影響を受けるかに関する分析を含んでいて。 このインパクト解析は、必要なら、操作上の安定性を最大にするように展開プランを変更するのに使用されるでしょう。

1. Introduction

1. 序論

   The Internet network service provider community and router vendors
   (as well as the IESG and various IETF working groups) have agreed
   that the time for deployment of route aggregation is upon us. This
   topic has been discussed in the BGP-D, NJM and ORAD working groups at
   several IETF meetings; it was a discussion topic of the NSFNET
   Regional Techs' Meetings in January and June, 1993; and it was also a
   topic of several meetings of the Federal Engineering Planning Group
   and Engineering and Operations Working Group of the Federal Network
   Council.

インターネット網サービスプロバイダー共同体とルータ業者(IESGと様々なIETFワーキンググループと同様に)は、ルート集合の展開のための時間が私たちにあるのに同意しました。 いくつかのIETFミーティングでBGP-D、NJM、およびORADワーキンググループでこの話題について議論しました。 1993年1月、6月にそれはNSFNET Regional TechsのMeetingsの議論話題でした。 そして、また、それは連邦政府のEngineering Planning GroupとEngineeringのいくつかのミーティングと連邦政府のNetwork CouncilのOperations作業部会の話題でした。

   All have generally agreed that Summer, 1993 is the time to enable
   BGP-4 and CIDR aggregation.  Each of the parties is responsible for
   its own aspect of CIDR implementation and practice. This memo
   describes Merit's plans for support of route aggregation on the
   NSFNET, and a proposal for implementing a database of aggregation
   information for use by network providers.

一般に、すべてがそのSummerに同意して、1993年はBGP-4とCIDR集合を有効にする時間です。 各人パーティーはそれ自身のCIDR実現と習慣の局面に責任があります。 このメモはNSFNETにおけるルート集合のサポートのためのMeritのプラン、およびネットワーク内の提供者で使用のための集合情報に関するデータベースを実行するための提案について説明します。

Knopper & Richardson                                            [Page 1]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[1ページ]RFC1482

2. Aggregation Support by the Backbone Service

2. 背骨サービスによる集合サポート

   The NSFNET backbone service includes a Policy-Based Routing Database
   system which currently holds the set of network numbers that are
   accepted by the backbone service with a list of Autonomous System
   numbers from which announcements of these network numbers are
   expected.  In order to implement CIDR, the database system will be
   modified to allow aggregation of routing information to be
   configured.

NSFNET背骨サービスは現在これらのネットワーク・ナンバーの発表が予想されるAutonomous System番号のリストで背骨サービスで受け入れられるネットワーク・ナンバーのセットを支えるベースのPolicyルート設定Databaseシステムを含んでいます。 CIDRを実行して、データベース・システムは、ルーティング情報の集合が構成されるのを許容するように変更されるでしょう。

   The NSFNET will (initially) not support de-aggregation on its
   outbound announcements. See section 2.3.

NSFNETは(初めは、)外国行きの発表の反-集合を支持しないでしょう。 セクション2.3を見てください。

2.1 Current Configuration Capabilities

2.1 現在の構成能力

2.1.1 Inbound Announcements

2.1.1 本国行きの発表

   An example of the way a network number is currently configured is as
   follows:

ネットワーク・ナンバーが現在構成される方法の例は以下の通りです:

         35      1:237   2:233   3:183   4:266   5:267  6:1225

35 1:237 2:233 3:183 4:266 5:267 6:1225

   This shows that network number 35 (ie. 35.0.0.0, a class A net
   number) is configured on the T3 backbone such that routing
   announcements are expected from up to 6 autonomous systems. The
   primary path is via AS 237, secondary is via AS 233, etc.

これはそのネットワーク・ナンバー35を示しています。(ie。 35.0.0.0 クラスのAネットの番号) T3背骨の上でAS233などで構成されます。

2.1.2 Outbound Announcements

2.1.2 外国行きの発表

   Currently the NSFNET database has a list of AS's or network numbers
   for each neighbor AS that are announced by the backbone to that AS.
   These announcements are specified currently by "announcetoAS"
   statements--which implement policies submitted by midlevels to
   Merit--and then included in the ANSnet router configuration files.
   There are two forms of these statements.  The first form uses the
   "norestrict" clause and indicates that all of the network numbers
   within each AS in the list should be announced to the neighbor
   midlevel AS. For example:

現在の、NSFNETデータベースは背骨によって発表されるそれぞれの隣人ASのASかネットワーク・ナンバーのリストをそのASに持っています。 これらの発表は、現在、「announcetoAS」という声明によって指定されて、次に、ANSnetルータ構成ファイルに含まれています。(声明はmidlevelsによってMeritに提出された政策を実施します)。 これらの声明の2つのフォームがあります。 最初のフォームは、"norestrict"節を使用して、リストの各ASの中のネットワーク・ナンバーのすべてが隣人の中間レベルのASに発表されるべきであるのを示します。 例えば:

         announcetoAS 42 norestrict ASlist 22 26 38 60 68

announcetoAS42norestrict ASlist22 26 38 60 68

   In this example, the NSFNET is configured to announce to neighboring
   midlevel AS 42, all networks in the routing table that were announced
   from AS's 22, 26, 38, 60 and 68.

この例では、NSFNETは、隣接している中間レベルのAS42(ASの22、26、38、60、および68から発表された経路指定テーブルのすべてのネットワーク)に知らせるために構成されます。

   If the "norestrict" keyword is changed to "restrict", this indicates
   that an explicit announce list of network numbers for the AS is
   specified in the configuration file. The NSFNET will only announce

「norestrictな」キーワードが「制限」に変わるなら、これがそれを示す、明白である、ASのネットワーク・ナンバーのリストが構成ファイルで指定されると発表してください。 NSFNETは発表するだけでしょう。

Knopper & Richardson                                            [Page 2]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[2ページ]RFC1482

   network numbers that were announced by the AS's in the list, *AND*
   which appear in the "restrict list" of network numbers submitted
   separately by the midlevel.

リストでASのものによって発表されたネットワーク・ナンバーであり、**とどれがネットワーク・ナンバーの「リストを制限してください」に現れるかは別々に中間レベルによって提出されました。

      For example,

例えば

         announcetoAS 42 restrict ASlist 22

announcetoAS42はASlist22を制限します。

         announce 192.135.237 <other info>

192.135に.237<他のインフォメーション>を発表してください。

   These statements mean that AS 42 only wishes to hear announcements
   from the backbone about the nets in AS 22 which are explicitly listed
   here (i.e., net 192.135.237).

これらの声明が、AS42がここに明らかに記載されているAS22のネットに関して背骨から発表を聞くだけでありたいことを意味する、(すなわち、ネット、192.135、.237、)

   It is also possible, when using the "restrict" keyword, to list
   specific "noannounce" lines. Those indicate that all of the networks
   listed in the routing table for the AS should be announced except
   those listed on the noannounce clauses.  (There is also a
   "noannouncetoAS" statement[4].)

また、特定の"noannounce"線を記載するのに「制限」キーワードを使用するとき、それも可能です。 ものは、noannounce節に記載されたものを除いて、ASのために経路指定テーブルに記載されたネットワークのすべてが発表されるべきであるのを示します。 (また、「noannouncetoAS」という声明[4]があります。)

2.2 New Configuration Features for Aggregation

2.2 集合のための新しい構成機能

   There will be three new capabilities for which the backbone service
   can be configured to support aggregation. The first two allow
   aggregates to be accepted and stored in the backbone routing tables
   based on announcements by the regional network (autonomous system or
   AS) peers.  The third allows the announcement of aggregates to the AS
   neighbor peers. The following sections give examples of the three
   features.

集合を支持するために背骨サービスを構成できる3つの新しい能力があるでしょう。 最初の2は、集合が発表に基づいている地域ネットワーク(自律システムかAS)の同輩の背骨経路指定テーブルに受け入れられて、格納されるのを許容します。 3番目はAS隣人同輩に集合の発表を許します。 以下のセクションは3つの特徴に関する例を出します。

   We use the notation <net-IP prefix-length> to describe an aggregate.
   This refers to the IP prefix "net-IP", with a mask which has
   "prefix-length" 1's as counted from the high-order end. For example,
   <192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [5].
   (The form using prefix-length rather than the mask is more compact.)

私たちは、集合について説明するのに記法<のネットのIP接頭語長さの>を使用します。 これは最左端から数えられるように「接頭語長さ」1を持っているマスクによる「ネットのIP」のIP接頭語を示します。 例えば、<192.64.128 17>は<192.64.128、255.255.128.0>[5]に同等です。 (マスクよりむしろ接頭語長さを使用するフォームはさらにコンパクトです。)

2.2.1 NSFNET accepts aggregates

2.2.1 NSFNETは集合を受け入れます。

   In this case the regional peer router is CIDR-capable (i.e., runs
   BGP-4) and the announcement comes into the backbone as an IP address
   prefix.

この場合、地方の同輩ルータはCIDRできます、そして、(すなわち、BGP-4を走らせます)発表はIPアドレス接頭語として背骨に入ります。

   To illustrate this in the spirit of sec. 2.1.1:

秒の精神でこれを例証するために 2.1.1:

         <192.64.128 17>         1:189 2:24 3:267

<192.64.128 17>1:189 2:24 3:267

   In this example, independent of the "class" of IP network number, an
   aggregate containing network addresses matching a pattern in which

この例では、IPネットワーク・ナンバーの「クラス」、aに合っているネットワーク・アドレスを含む集合の如何にかかわらず中でどれを型に基づいて作ってくださいか。

Knopper & Richardson                                            [Page 3]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[3ページ]RFC1482

   the first 17 bits match the prefix 192.64.128 will be accepted in
   announcements to the NSFNET service.  The primary path to
   destinations covered by the prefix is expected via AS 189, the
   secondary, via AS 24, etc.

接頭語192.64.128が受け入れられるNSFNETへの発表が調整する最初の17ビットのマッチ。 接頭語で覆われた目的地への第一の経路はAS189、二次を通してAS24などで予想されます。

2.2.2 NSFNET aggregates by proxy

2.2.2 NSFNETは代理人を通して集めます。

   The other method of incorporating CIDR aggregate announcements into
   the backbone routing tables is that of aggregation by proxy.  In this
   case, the backbone is configured to perform aggregation on behalf of
   a peer AS which is not configured to announce the aggregate to the
   backbone (i.e., an AS which does not connect to the backbone via a
   CIDR-capable peer).

CIDRの集合発表を背骨経路指定テーブルに組み入れるもう片方の方法は代理人を通して集合のものです。 この場合、背骨は、集合を背骨に発表するために構成されない同輩AS(すなわち、CIDR有能な同輩を通して背骨に接続しないAS)を代表して集合を実行するために構成されます。

   An example of this aggregation technique is:

この集合のテクニックに関する例は以下の通りです。

         proxy <192.64.128 17>     1:189  2:24  3:267
                 if  <192.64.192 24>
                 or  <192.64.129 24>
                 or  <192.64.167 24>

プロキシ<192.64.128 17>1:189 2:24 3:267、<192.64.192 24>、<192.64.129 24>または<192.64.167 24>です。

   (Note: the syntax used in this document is arbitrary and is only used
   to illustrate the method. The syntax to be used in actual routing
   requests is to be determined.)

(以下に注意してください。 本書では使用される構文は、任意であり、方法を例証するのに使用されるだけです。 実際のルーティング要求で使用されるべき構文は断固とすることです。)

   In this example, the aggregate <192.64.128 17> will be stored and
   propagated within the backbone as an aggregate under a set of
   conditions.  Initially, the GateD support will allow an "OR" list of
   conditions such that if one of the aggregates in the list matches the
   proxy aggregate will be stored[6].  For the case above, this means
   that, if any of the CIDR aggregates:

この例では、集合<192.64.128 17>は集合として背骨の中で状態のセットの下で格納されて、伝播されるでしょう。 初めは、GateDサポートは、リストの集合の1つが合っているとプロキシ集合が格納されるように、状態の「OR」リストを許容するでしょう。[6]。 ケースのために、CIDRのどれかが集めるなら、上では、これがそれを意味します:

         <192.64.192 24>
         <192.64.129 24>
         <192.64.167 24>

<192.64.192 24><192.64.129 24><192.64.167 24>。

   (which--under the current, class-based IP address system--are
   equivalent to the class C net numbers 192.64.192, 192.64.129, or
   192.64.167, respectively) is heard, the backbone router will act as
   though it heard the announcement of the single CIDR aggregate
   <192.64.128 17>.

または、(どれ、--、現在の、そして、クラスを拠点とするIPの下では、システム--クラスのCのネットの番号に同等であると記述してください192.64、.192、192.64 .129、192.64 .167 それぞれ)、聞かれて、まるで単一のCIDR集合<192.64.128 17>の発表を聞くかのように背骨ルータは行動するでしょう。

2.2.3 NSFNET announces aggregates

2.2.3 NSFNETは集合を発表します。

   The functionality of the current system, as outlined in sec. 2.1.2,
   above, will continue to exist once CIDR is implemented. The
   "norestrict" function (or its equivalent in the new software) will
   specify that all network reachability information received from a set

現在のシステムの機能性秒のときに概説されて、 2.1.2 上では、CIDRがいったん実行されると、ずっと存在するでしょう。 "norestrict"機能(または、新しいソフトウェアの同等物)は、すべてのネットワーク可到達性情報がセットから受信されたと指定するでしょう。

Knopper & Richardson                                            [Page 4]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[4ページ]RFC1482

   of Autonomous Systems, including any aggregates, will be announced.
   It should also be possible to use to the equivalents of the
   "restrict" keyword and the "announce" (or "noannounce") statement in
   order to limit the announcements of the aggregations within an AS to
   any desired subset.

どんな集合も含んでいて、Autonomous Systemsについて、発表されるでしょう。 また、それもASの中で集合の発表をどんな必要な部分集合にも制限するのに「制限」キーワードの同等物と「発表する」(または、"noannounce")という声明に使用するのにおいて可能であるべきです。

2.3 Specifically Unsupported Capabilities, Limits of Initial Deployment

2.3 明確にサポートされない能力、初期の展開の限界

   There are some aspects of aggregation which will specifically not be
   supported in the initial deployment of CIDR capabilities on the
   NSFNET backbone.  In particular, when the NSFNET service announces
   routes to midlevel peers, de-aggregation will not be performed [3].
   Therefore, a peer which needs to receive full routing information
   should run a protocol which supports CIDR (initially, BGP-4; later,
   IDRP). Peer networks using default routing will be able to reach
   networks that are part of aggregated routing information across the
   backbone (as in section 6.4 of [3]).

NSFNET背骨におけるCIDR能力の初期の展開で明確に支持されない集合のいくつかの局面があります。 反-集合はNSFNETサービスが事項中間レベルの同輩にルートを示すときに時実行されないでしょう。[3]。 したがって、完全なルーティング情報を受け取るそれの必要性がCIDRを支持するプロトコルを走らせるべきである同輩、(初めは、BGP-4; 後で、IDRP) デフォルトルーティングを使用する同輩ネットワークは背骨の向こう側に集められたルーティング情報の一部であるネットワークに達することができるでしょう。(セクション6.4の[3])のように。

3.  CIDR Aggregate Registry

3. CIDRの集合登録

   In discussions with network service providers, it has become apparent
   that there is a great need for sharing of aggregate information; this
   is necessary to fulfill the coordination referred to in sec. 2.3.
   Beyond the need to implement CIDR aggregation facilities in the
   NSFNET Policy-Based Routing Database (as described in section 2),
   there is a clear need to have a separate database which will allow
   aggregate information from any Autonomous System to be stored and
   made available for easy electronic retrieval. This information can be
   used for routing coordination and policy configuration in the larger,
   non-NSFNET-centric, inter-domain context.

ネットワークサービスプロバイダーとの議論では、集合情報を共有するすばらしい必要があるのは明らかになりました。 これが、秒のときに言及されたコーディネートを実現させるのに必要です。 2.3. ベースのNSFNET Policyルート設定Database(セクション2で説明されるように)でCIDR集合施設を実行する必要性を超えて、簡単な電子検索のためにどんなAutonomous Systemからの集合情報も格納して、利用可能にするのを許容する別々のデータベースを持つ明確な必要性はいます。 より大きいところのルーティングコーディネートと方針構成にこの情報を使用できる、非NSFNET中心、相互ドメイン文脈。

   One of the expected uses of such a database is to help determine, as
   CIDR matures, the granularity of aggregation of network reachability
   information with respect to policy.  The useful scope of aggregation
   is the subject of much discussion[5][7], and will be influenced by
   such considerations as how network number allocation has been
   handled, and whether the network provider has renumbered its client
   networks to conform to CIDR aggregation boundaries. Rules and issues
   regarding network number allocation with CIDR are discussed in [8]
   and [7].

そのようなデータベースの予想された用途の1つは方針に関してCIDRが熟すのでネットワーク可到達性情報の集合の粒状を決定するのを助けることです。 集合の役に立つ範囲は、多くの議論[5][7]の対象であり、ネットワーク・ナンバー配分がどのように扱われるか、そして、ネットワーク内の提供者がCIDR集合境界に従うためにクライアントネットワークに番号を付け替えさせたかどうかような問題によって影響を及ぼされるでしょう。 [8]と[7]でCIDRとのネットワーク・ナンバー配分に関する規則と問題について議論します。

   In order further these goals, Merit proposes to implement a "CIDR
   Aggregate Registry" to provide sharing of aggregate information for
   the Internet inter-domain routing community. Initially, this will be
   a simple database without much structure. It is not intended to hold
   only aggregates which are announced or accepted by the NSFNET
   service; rather, it should be a community registry that all will be
   invited to use and make use of.

これらの目標を促進するために、Meritは、インターネット相互ドメインルーティング共同体のための集合情報を共有しながら提供するために「CIDRの集合登録」を実行するよう提案します。 初めは、これは多くの構造なしで簡単なデータベースになるでしょう。 それがNSFNETサービスで発表されるか、または受け入れられる集合だけを保持することを意図しません。 むしろ、それはすべてが使用して、利用するよう誘われている共同体登録であるべきです。

Knopper & Richardson                                            [Page 5]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[5ページ]RFC1482

   The Aggregate Registry will consist of a list of aggregate
   announcement statements. Each statement consists of four types of
   information, along with contact information:

Aggregate Registryは集合発表声明のリストから成るでしょう。 各声明は問い合わせ先に伴う4つのタイプの情報から成ります:

      1) CIDR Aggregate: The aggregate identifier, consisting of a
      network number prefix and the prefix length. For example,
      <192.29.128 16>.

1) CIDRは集めます: 集合識別子、ネットワーク・ナンバー接頭語から成って、および接頭語の長さ。 例えば、<192.29.128 16>。

      2) Home AS: The source AS number for the aggregate. That is, the
      AS number of the network service provider that initially
      aggregates the network reachability information into the aggregate
      for announcement to its neighbors.

2) 以下として家へ帰ってください。 集合のソースAS番号。 すなわち、初めは隣人への発表のために集合へのネットワーク可到達性情報に集めるネットワークサービスプロバイダーのAS番号。

      3a) Announcing AS: An AS number that announces this aggregate to
      its neighbor AS's.

3a) 以下として発表すること。 これを発表するAS番号は隣人ASのものに集められます。

      3b) Neighbor AS list: A list of neighbor AS's to whom the
      aggregate will be announced by the AS named in 3a.

3b) 隣人ASは記載します: 集合が3aで指定されたASによって発表される隣人ASのリスト。

      4) Contact information: eg. e-mail address and name or NIC handle
      of the administrative and technical contacts for the source AS.

4) 問い合わせ先: ソースASの管理と技術連絡担当者の例えば、Eメールアドレスと名前かNICハンドル。

   Thus, a given aggregate is listed once as announced by its source AS.
   It may then be listed once again per transit AS which announces the
   aggregate downstream to its neighbors.  For example, the CIDR
   aggregate <199.29.128 16> could be listed as:

したがって、ソースASによって発表されるように与えられた集合は一度記載されています。 そして、それは川下で集合を隣人に発表するトランジットAS単位でもう一度記載されているかもしれません。 例えば、以下としてCIDRの集合<199.29.128 16>を記載できました。

          CIDR aggregate  home ann  neighbor
          (prefix-length) AS   AS   AS list         contacts
         -----------------------------------------------------------
         <199.29.128 16>  100  100  200 201 690     fred@nowhere.net
         <199.29.128 16>  100  690  266 267 1225... <contact info>
         <199.29.128 16>  100  200  297 372         <contact info>
         <199.29.128 16>  100  201  771 1262        <contact info>

CIDRの集合家のann隣人(接頭語長さ)AS AS ASリスト接触----------------------------------------------------------- <199.29.128 16>100 100 200 201 690 fred@nowhere.net 、lt;、199.29.128 16 >100 690 266 267 1225… <コンタクトインフォメーション><199.29.128 16>100 200 297 372<コンタクトインフォメーション><199.29.128 16>100 201 771 1262<コンタクトインフォメーション>。

         Note: This can be represented using the syntax used for objects
         in the RIPE-81 paper[9].

以下に注意してください。 RIPE-81紙[9]で物に使用される構文を使用することでこれを表すことができます。

   Here, AS 100 (the source AS) performs any aggregation and announces
   the CIDR aggregate <199.29.128 16> to neighbor ASs 200, 201, and 690.
   In turn, AS 200 announces this same aggregate to its neighbor ASs 297
   and 372; further lines show announcements of the given aggregate by
   AS 690 and AS 201.

ここで、AS100(ソースAS)はどんな集合も実行して、CIDRの集合<199.29.128 16>を隣人ASs200、201、および690に発表します。 順番に、AS200は隣人ASs297と372にこの同じ集合を発表します。 さらなる線はAS690とAS201による与えられた集合の発表を示しています。

   Note that this registry reflects both the simple list of aggregates
   that are supported by the union of network providers, as well as
   information on inter-domain topology for the Internet.  Merit will
   implement procedures for registering any network provider's

この登録がネットワーク内の提供者の組合によってサポートされる集合に関する単純並びと相互ドメイントポロジーの情報の両方をインターネットに反映することに注意してください。 長所はどんなネットワーク内の提供者も登録するための手順を実行するでしょう。

Knopper & Richardson                                            [Page 6]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[6ページ]RFC1482

   aggregates in the Registry; for those CIDR aggregates carried over
   the NSFNET backbone, Merit will implement procedures for integrating
   this Registry with the process of updating the aggregate routing
   announcements.  Requests to update the information will be handled
   via e-mail or on-line registration tools.

Registryの集合。 NSFNET背骨の上まで運ばれたそれらのCIDR集合のために、Meritは集合ルーティング発表をアップデートする過程とこのRegistryを統合するための手順を実行するでしょう。 情報をアップデートするという要求はメールかオンライン登録ツールで扱われるでしょう。

4. Effects of CIDR on Operational Aspects of the Internet

4. インターネットの操作上の局面へのCIDRの効果

   The introduction of CIDR will clearly necessitate various changes
   beyond the introduction of new router software.  In particular, Merit
   and other network service providers will have to adjust tools,
   reports, and procedures as CIDR is implemented and evolved, and these
   changes will have to be coordinated in order to ensure a smooth
   transition to the CIDR-capable Internet.

CIDRの導入は明確に新しいルータソフトウェアの導入を超えて様々な変化を必要とするでしょう。 CIDRが実行されて、発展されて、これらの変化が調整されなければならないとき、特に、Meritと他のネットワークサービスプロバイダーは、CIDRできるインターネットにスムーズな移行を確実にするようにツール、レポート、および手順を調整しなければならないでしょう。

   While this document is by no means exhaustive, some of the areas
   affected are discussed briefly below; what is intended is to foster
   an awareness of some these changes, so as to initiate thinking about
   and planning for this transition.  While it is obvious that CIDR and
   policy routing imply greater coordination of many operational
   matters, it is not clear how profoundly this will affect the day-to-
   day running of the Internet.

このドキュメントが決して徹底的でない間、簡潔に以下で影響を受ける領域のいくつかについて議論します。 意図することはいくつかの認識を伸ばすために、これらが変化します、この変遷のために考えを開始して、計画していてことです。 CIDRと方針ルーティングが多くの操作上の件の、より大きいコーディネートを含意するのが、明白ですが、これがインターネットを走らせながら日から日に影響するのは、どれくらい深く明確でないか。

   (Note:  Aspects of the actual phased deployement of CIDR are covered
   in [3] and [10].)

(注意: CIDRの実際の段階的なdeployementの局面は[3]と[10]でカバーされています。)

4.1 NSFNET Configuration Files and Reports; Neighbor AS Configurations

4.1 NSFNET構成ファイルとレポート。 構成としての隣人

   The addition of CIDR capability to the NSFNET Policy-Based Routing
   Database, as outlined in sec. 2, will require the updating of at
   least the following reports which are currently produced by Merit
   (and available via anonymous FTP from nic.merit.edu):

ベースのNSFNET Policyルート設定DatabaseへのCIDR能力の添加秒のときに概説されて、 2 少なくとも以下の現在、Meritによって生産されて、(nic.merit.eduからの公開FTPを通して利用可能)であるレポートのアップデートを必要とするでしょう:

         ans_core.now  as-site.now  country.now net-comp.now  net-net.now
         net-ter.now   non-us.now

ans_core.now site.now country.nowとしてのネットのcomp.nowネットのnet.nowネットのter.now非us.now

   Any tools which access this information, such as the various clients
   or scripts released by Merit or developed by others, will have to be
   changed.

この情報にアクセスするMeritによって釈放されるか、または他のものによって開発された様々なクライアントかスクリプトなどのどんなツールも変えなければならないでしょう。

   However, the most striking change will be in the transition from
   rcp_routed to GateD; it is very different in important particulars,
   and follows different conceptual principles [11].

しかしながら、最も衝撃的な変化はGateDに発送されたrcp_から変遷で来ているでしょう。 それは、重要な子細において非常に異なって、異なった概念的な原則[11]に従います。

   Network providers which develop any part of their configuration files
   from parsing the NSFNET configuration files or reports *MUST* plan
   for these changes in order to help themselves and the Internet
   community achieve a smooth transition to CIDR.

NSFNET構成ファイルを分析するのからのそれらの構成ファイルのどんな部分も発生するプロバイダーか**が自分たちを助けるためにこれらの変化の計画を立てなければならなくて、インターネット共同体がスムーズな移行を達成するというレポートをCIDRにネットワークでつないでください。

Knopper & Richardson                                            [Page 7]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[7ページ]RFC1482

4.2 Routing and Administrative Policies

4.2 ルート設定と施政方針

   In this document, Merit has stated its commitment to supporting CIDR
   through both changing policies related to administering the NSFNET
   and developing a CIDR Aggregate Registry for the broader Internet
   community.

本書では、MeritはNSFNETを管理すると関連する方針を変えながら両方を通してCIDRを支持して、より広いインターネットコミュニティのためにCIDR Aggregate Registryを開発する委任を述べました。

   In addition to these changes, here are some of the other policies,
   administrative and routing, which must to be coodinated in order to
   achieve optimum benefits of CIDR:

これらの変化に加えて、他の方針のいくつかがここにあります、管理であり、掘って、どの必須のCIDRの最適な利益を達成するためにcoodinatedされたか:

      - policies of the InterNIC and of network service providers in
        assigning (CIDR) IP nets and blocks, as mentioned above;

- 上に言及されるようにIPネットとブロックを(CIDR)に割り当てることにおける、InterNICとネットワークサービスプロバイダーの方針。

      - policies of the various ASs in coordination of transit and other
        routing policies;

- トランジットと他のルーティング方針のコーディネートにおける様々なASsの方針。

      - policies of registration of new networks, from the InterNIC or
        network provider, through the CIDR Aggregate Registry, etc.;

- InterNICかネットワーク内の提供者からCIDR Aggregate Registryなどでの新しいネットワークの登録の方針。

      - policies related to coordination of routing changes;

- 方針はルーティング変化のコーディネートに関連しました。

      - coordination of routing policies, in general, to avoid new
        classes of routing problems due to new methods of routing.

- 一般に、ルーティングの新しい方法のため新しいクラスのルーティング問題を避けるために方針を発送するコーディネート。

4.3 Realtime Issues

4.3 リアルタイムで問題

   Issues which have not been examined in detail are:

詳細に調べられていない問題は以下の通りです。

      - debugging of routing/connectivity problems;

- ルーティング/接続性問題のデバッグ。

      - stability and other properties of routing under various
        scenarios of CIDR configuration and network topology;

- CIDR構成とネットワーク形態の様々なシナリオの下におけるルーティングの安定性と他の特性。

      - explicit specification of routing decision algorithms to avoid
        routing anomalies;

- 例外を発送するのを避けるルーティング決定アルゴリズムの明白な仕様。

      - increased network load due to packets traversing an AS, such as
        the NSFNET backbone, before being discarded due to addressing a
        "hole" in a CIDR aggregate.

- パケットによる増加するネットワーク負荷がNSFNET背骨などのASを横断して、CIDRの「穴」を記述するため捨てられる前に、集めてください。

4.4 Estimate of Reductions in Routing Tables

4.4 経路指定テーブルでの減少の見積り

   An argument in favor of the implementation CIDR is the effect which
   it should have upon the NSFNET and other routing tables [1] [5].  The
   burning question is: What is the magnitude of this effect?  In view
   of the various issues to be dealt with, this is an important
   consideration.

実現CIDRを支持して議論はそれがNSFNETと他の経路指定テーブル[1][5]に持つべきである効果です。 盛んに論じられている問題は以下の通りです。 この効果の大きさはどのくらいですか? 対処されるべき様々な問題から見て、これは重要な考慮すべき事柄です。

Knopper & Richardson                                            [Page 8]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[8ページ]RFC1482

   In terms of the immediate savings in reduction of the NSFNET backbone
   routing tables, if a set of aggregates were done all at once, a
   recent calculation--which might be characterized as an optimistic
   estimate using a pessimistic algorithm (it looks for the longest
   continuous block of addresses announced to the NSFNET backbone)--
   yields [12]:

NSFNET背骨経路指定テーブルの減少における即座の貯蓄で、一気に1セットの集合をしたなら、最近の計算は[12]をもたらします:(計算は、楽観値として悲観的なアルゴリズム(それはNSFNET背骨に発表されたアドレスの最も長い連続したブロックを探す)を使用することで特徴付けられるかもしれません)。

        861 size  2 saving  861 announcements
        286 size  4 saving  858 announcements
        117 size  8 saving  819 announcements
         67 size 16 saving 1005 announcements
         13 size 32 saving  403 announcements
          3 size 64 saving  189 announcements
       1347 total   saving 4135 announcements of 12348 (33%).

861 12348(33%)の4135の発表を救いながら189の発表に1347合計を救う3サイズ64を403の発表に節約する13サイズ32を1005の発表に節約する67サイズ16を819の発表に節約する117サイズ8を858の発表に節約する286サイズ4を861の発表に節約するサイズ2。

   Here, the first column represents the number of CIDR aggregates of
   the given "size," and shows the corresponding reduction in net
   announcements due to the adoption of this aggregate.  (A CIDR
   aggregate of "size <n>" is one which encompasses <n> class A, B, or C
   networks; the 67 "size 16" CIDR aggregates actually combine
   announcements for 16 separate networks into a single net aggregate.)
   It is unclear, at this time, whether or not the true savings would be
   of this magnitude, but the extended report provides a basis for
   discussion [12].

ここに、最初のコラムは、与えられた「サイズ」のCIDR集合の数を表して、この集合の採用によるネットの発表の対応する減少を示しています。 (「サイズ<n>」のCIDR集合が>のクラスA、B、またはCがネットワークでつなぐ<n ; 67を取り囲むものである、「ただ一つのネットへの16の別々のネットワークのための実際にコンバイン発表が集める16インチのサイズCIDR集合)。」 それは不明瞭です、本当の貯蓄がこの大きさのものでしょうが、拡張レポートが議論[12]の基礎を提供するか否かに関係なくこのとき。

   The other aspect of impact upon the routing tables, the reduction in
   the rate of growth (and the concomitant slowing of the rate of
   exhaustion of IP address space), is an entirely different matter.
   Simple calculations related to the rate of class B address space
   exhaustion indicate that CIDR-conformant policies of the InterNIC
   with respect to address assignment is helping [1].

経路指定テーブルへの影響のもう片方の局面(成長率の減少(そして、IPアドレス空間の疲労困憊の速度を遅くならせる共存))は完全に異なった問題です。 クラスBアドレス空間疲労困憊の速度に関連する簡単な計算は、アドレス課題に関するInterNICのCIDR-conformant方針が[1]を助けることであることを示します。

   Clearly, more detailed analysis is desirable in order to better
   understand the realistic gains of the CIDR deployment process, both
   initially and in the longer term.

明確に、より詳細な分析は、CIDR展開の過程(初めは、そして、より長い期間による両方)の現実的な獲得を理解するほうがよいために望ましいです。

5.  Conclusions and Next Steps

5. 結論と次のステップ

   Implementation of CIDR is underway, but there is still a fair amount
   of planning and discussion that is needed for a successful
   transition.  Merit is proposing specific functions for CIDR
   aggregation that will be supported by the NSFNET, as well as a CIDR
   Aggregate Registry that can serve as the basis for inter-domain
   routing coordination.

CIDRの実現は進行中ですが、公正な量の計画とうまくいっている変遷に必要である議論がまだあります。 長所はNSFNETによって支持されるCIDR集合のために具体的な機能を提案しています、相互ドメインルーティングコーディネートの基礎として機能できるCIDR Aggregate Registryと同様に。

   The Aggregate Registry will allow a set of tools to be developed that
   can facilitate the design of aggregation policy. A query tool to
   allow lookup of aggregation information for a given network or

Aggregate Registryは集合方針のデザインを容易にすることができる1セットの開発されるべきツールを許容するでしょう。 または与えられたネットワークのための集合情報のルックアップを許容する質問ツール。

Knopper & Richardson                                            [Page 9]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[9ページ]RFC1482

   aggregate would be very useful. Additional database functionality
   will also be desired for more powerful queries. It is specifically a
   goal to work with RIPE to make sure that the Merit and RIPE database
   approaches are compatible and allow interworking of tools. An AS
   topology database would be most useful in routing policy
   determination and coordination as well.

集合は非常に役に立つでしょう。 また、追加データベースの機能性は、より強力な質問のために望まれるでしょう。 MeritとRIPEデータベースアプローチは互換性があるのを確実にして、ツールが織り込むのを許容するためにRIPEと共に働くのは、明確に目標です。 ルーティング方針決断とまた、コーディネートでASトポロジーデータベースは最も役に立つでしょう。

   In addition to these areas, many other issues require further work in
   order to develop the operational framework necessary for the
   successful use of CIDR on the Internet. It is critical that the
   deployment of CIDR and related tools to preserve address and routing
   table space must not compromise the operational stability of the
   NSFNET and the wider Internet.

これらの領域に加えて、他の多くの問題が、インターネットにおけるCIDRのうまくいっている使用に必要な操作上の枠組みを開発するためにさらなる仕事を必要とします。 CIDR、アドレスを保存する関連する道具、および経路指定テーブルスペースの展開がNSFNETの操作上の安定性と、より広いインターネットで妥協してはいけないのは、批判的です。

6. Security Considerations

6. セキュリティ問題

      Security issues are not discussed in this document.

本書では安全保障問題について議論しません。

7. Acknowledgements

7. 承認

   The authors would like to acknowledge the following persons, whose
   comments and discussions have helped to shape this document:

作者は以下の人々を承認したがっています:(コメントと人々の議論はこのドキュメントを形成するのを助けました)。

         Dennis Ferguson, Advanced Network and Services, Inc.
         Jeffrey Honig, Cornell University
         William Manning, Rice University/SESQUINET
         The Merit Internet Engineering and Network Management
         Systems groups.

ライス大学/SESQUINET Meritインターネットのデニスファーガソン、Advanced Network、Services Inc.ジェフリー・ホニッグ、コーネル大学のウィリアム・マニング、Engineering、およびNetwork Management Systemsは分類します。

8. Authors' Addresses

8. 作者のアドレス

   Knopper, Mark A.
   Merit Network, Inc.
   1071 Beal Ave.
   Ann Arbor, MI  48109-2103

Knopper、マークA.はネットワークInc.1071ビールAveに値します。 アナーバー、MI48109-2103

   e-mail: mak@merit.edu
   phone:  (313) 763-6061
   fax:    (313) 747-3745

メール: mak@merit.edu 電話: (313) 763-6061 ファックスで以下を送ってください。 (313) 747-3745

   Richardson, Steven J.
   Merit Network, Inc.
   1071 Beal Ave.
   Ann Arbor, MI  48109-2103

リチャードソン、スティーブンJ.はネットワークInc.1071ビールAveに値します。 アナーバー、MI48109-2103

   e-mail: sjr@merit.edu
   phone:  (313) 747-4813
   fax:    (313) 747-3745

メール: sjr@merit.edu 電話: (313) 747-4813 ファックスで以下を送ってください。 (313) 747-3745

Knopper & Richardson                                           [Page 10]

RFC 1482              Routing Aggregation Support              July 1993

集合サポート1993年7月に掘るKnopperとリチャードソン[10ページ]RFC1482

9. References

9. 参照

   [1]  Fuller, V., Li, T., Yu, J., and Varadhan, K., "Supernetting: an
        Address Assignment and Aggregation Strategy", RFC1338, Update,
        Work in Progress, June 1992.

[1] フラーとV.と李とT.とユー、J.とVaradhan、K.、「スーパーネッティング:」 「アドレス課題と集合戦略」(RFC1338、アップデート)は進歩、1992年6月に働いています。

   [2]  Rekhter, Y., and Li, T., "A Border Gateway Protocol 4", Work In
        Progress, April 1993.

[2] Rekhter、Y.と李、T.、「ボーダ・ゲイトウェイ・プロトコル4インチ、処理中の作業、1993年4月。」

   [3]  Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11
        March 93", Work in Progress, March 1993.

[3] C.、「1993年3月11日のBGP-4/CIDR調整会議の注意」というTopolcicは進歩、1993年3月に働いています。

   [4]  Villamizer, C., in a document describing rcp_routed.conf options
        and syntax, May, 1993.

[4]Villamizer、ドキュメントのrcp_routed.confオプションについて説明するC.と構文、1993年5月。

   [5]  Syntax used in Ford, P., Rekhter, Y., Braun, H-W., "Improving
        the Routing and Addressing of IP", IEEE Network, pp. 10-15, May
        1993.

[5] 構文はフォード、P.、RekhterでIEEE Network、Y.、ブラウン、H-W.が「IPのルート設定とアドレシングを改良すること」でのページを使用しました。 10-15と、1993年5月。

   [6]  Ferguson, D., private correspondence, March, 1993.

[6] ファーガソン、D.、私信、1993年3月。

   [7]  Rekhter, Y., and Li, T., "An Architecture for IP Address
        Allocation with CIDR", Work in Progress, February, 1993.

1993年2月の[7] Rekhter、Y.と李、T.、「CIDRとのIPアドレス配分のための構造」処理中の作業。

   [8]  Gerich, E., "Guidelines for Management of IP Address Space",
        RFC1466, May 1993.

[8] Gerich(E.、「IP管理アドレス空間のためのガイドライン」、RFC1466)は1993がそうするかもしれません。

   [9]  Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., and
        Terpstra, M., "Representation of IP Routing Policies in the RIPE
        Database" (ripe-81), Work in Progress, February, 1993.

[9] ベイツ、T.、J-M.とKarrenbergとD.とLothberg、P.とテルプストラ、M.、「熟しているデータベースにおける、IPルート設定方針の表現」(熟している81)というJouanigotは進行中(1993年2月)で働いています。

   [10] Rekhter, Y., and Topolcic, C., "Exchanging Routing Information
        Across Provider/Subscriber Boundaries in the CIDR Environment",
        Work in Progress, April 1993.

[10] 「CIDR環境におけるプロバイダー/加入者境界の向こう側に経路情報を交換し」て、Rekhter、Y.、およびTopolcic、C.は進行中(1993年4月)で働いています。

   [11] Fedor, M., Honig, J., Coltun, R., Ferguson, D., "gated-
        config(5)" manpage, from the "gated-R3_0Beta_2" distribution, 7
        October 1992.

「_の2インチの外出を禁止されたR3_0Betaの分配、1992年10月7日」からの[11] ヒョードル(M.、ホニッグ、J.、Coltun、R.、ファーガソン、D.)が「コンフィグ(5)に外出を禁止した」というmanpage。

   [12] Johnson, D., analysis available via anonymous FTP from
        merit.edu:/pub/nsfnet/cidr/auto-aggregates, June 1993.

[12] ジョンソン、D.、/pub/nsfnet/cidr/auto-集合、1993年merit.eduからの公開FTP:6月を通して利用可能な分析。

   [13] Topolcic, C., "Schedule for IP Address Space Management
        Guidelines", RFC1367, October, 1993.

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

Knopper & Richardson                                           [Page 11]

Knopperとリチャードソン[11ページ]