RFC1222 日本語訳

Network Working Group                                         H-W. Braun
Request for Comments: 1222                San Diego Supercomputer Center
                                                              Y. Rekhter
                                         IBM T.J. Watson Research Center
                                                                May 1991

ワーキンググループH-Wをネットワークでつないでください。 コメントを求めるブラウン要求: 1222 サンディエゴスーパーコンピュータセンターY.Rekhter IBM T.J.ワトソン研究所1991年5月

               Advancing the NSFNET Routing Architecture

NSFNETルート設定構造を唱えます。

Status of this Memo

このMemoの状態

   This RFC suggests improvements in the NSFNET routing architecture to
   accommodate a more flexible interface to the Backbone clients.  This
   memo provides information for the Internet community.  It does not
   specify an Internet standard.  Distribution of this memo is
   unlimited.

このRFCは、よりフレキシブルなインタフェースをBackboneクライアントに収容するためにNSFNETルーティング構造における改良を勧めます。 このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Introduction

序論

   This memo describes the history of NSFNET Backbone routing and
   outlines two suggested phases for further evolution of the Backbone's
   routing interface.  The intent is to provide a more flexible
   interface for NSFNET Backbone service subscribers, by providing an
   attachment option that is simpler and lower-cost than the current
   one.

このメモは、NSFNET Backboneルーティングの歴史について説明して、Backboneのルーティングインタフェースの一層の発展のために2つの提案されたフェーズについて概説します。 意図はNSFNET Backboneサービス加入者によりフレキシブルなインタフェースを提供することです、現在のものよりさらに簡単な付属オプションと低い費用を提供することによって。

Acknowledgements

承認

   The authors would like to thank Scott Brim (Cornell University),
   Bilal Chinoy (Merit), Elise Gerich (Merit), Paul Love (SDSC), Steve
   Wolff (NSF), Bob Braden (ISI), and Joyce K. Reynolds (ISI) for their
   review and constructive comments.

作者は彼らのレビューと建設的なコメントについてスコットBrim(コーネル大学)、Bilal Chinoy(長所)、エリーズGerich(長所)、ポールLove(SDSC)、スティーブ・ヴォルフ(NSF)、ボブ・ブレーデン(ISI)、およびジョイス・K.レイノルズ(ISI)に感謝したがっています。

1. NSFNET Phase 1 Routing Architecture

1. NSFNETフェーズ1ルート設定構造

   In the first phase of the NSFNET Backbone, a 56Kbps infrastructure
   utilized routers based on Fuzzball software [2].  The Phase 1
   Backbone used the Hello Protocol for interior routing.  At the
   periphery of the Backbone, the client networks were typically
   connected by using a gatedaemon ("gated") interface to translate
   between the Backbone's Hello Protocol and the interior gateway
   protocol (IGP) of the mid-level network.

NSFNET Backboneの第1段階では、56KbpsインフラストラクチャはFuzzballソフトウェア[2]に基づくルータを利用しました。 Phase1Backboneは内部のルーティングにHelloプロトコルを使用しました。 Backboneの周辺では、クライアントネットワークが、中間レベルのネットワークのBackboneのHelloプロトコルと内部のゲートウェイプロトコル(IGP)の間で翻訳するのにgatedaemon(「外出を禁止される」)インタフェースを使用することによって、通常接続されました。

   Mid-level networks primarily used the Routing Information Protocol
   (RIP) [3] for their IGP.  The gatedaemon system acted as an interface
   between the Hello and RIP environments.  The overall appearance was
   that the Backbone, mid-level networks, and the campus networks formed
   a single routing system in which information was freely exchanged.

中間レベルのネットワークはそれらのIGPに主としてルーティング情報プロトコル(RIP)[3]を使用しました。 gatedaemonシステムはHelloとRIP環境とのインタフェースとして作動しました。 総合的な外観はBackbone、中間レベルのネットワーク、およびキャンパスネットワークが情報が自由に交換されたただ一つのルーティングシステムを形成したということでした。

Braun & Rekhter                                                 [Page 1]

RFC 1222       Advancing the NSFNET Routing Architecture        May 1991

NSFNETルート設定構造1991年5月に進むブラウンとRekhter[1ページ]RFC1222

   Network metrics were translated among the three network levels
   (backbone, mid-level networks, and campuses).

ネットワーク測定基準は3つのネットワークレベル(背骨、中間レベルのネットワーク、およびキャンパス)の中で翻訳されました。

   With the development of the gatedaemon, sites were able to introduce
   filtering based on IP network numbers.  This process was controlled
   by the staff at each individual site.

gatedaemonの開発で、サイトはIPネットワーク・ナンバーに基づくフィルタリングを導入できました。 この過程はそれぞれの個々のサイトでスタッフによって制御されました。

   Once specific network routes were learned, the infrastructure
   forwarded metric changes throughout the interconnected network. The
   end-result was that a metric fluctuation on one end of the
   interconnected network could permeate all the way to the other end,
   crossing multiple network administrations.  The frequency of metric
   fluctuations within the Backbone itself was further increased when
   event-driven updates (e.g., metric changes) were introduced.  Later,
   damping of the event driven updates lessened their frequency, but the
   overall routing environment still appeared to be quite unstable.

特定のネットワークルートがいったん学習されると、インフラストラクチャはメートル法の変化を相互接続ネットワークに送りました。 結末は相互接続ネットワークの片端におけるメートル法の変動がもう一方の端までのいっぱいに染みることができたということでした、複数のネットワーク運営に交差していて。 イベントドリブンアップデート(例えば、メートル法の変化)を導入したとき、Backbone自身の中のメートル法の変動の頻度をさらに増加させました。 その後、イベントドリブンアップデートの湿気はそれらの頻度を少なくしましたが、総合的なルーティング環境は十分不安定であるようにまだ見えていました。

   Given that only limited tools and protocols were available to
   engineer the flow of dynamic routing information, it was fairly easy
   for routing loops to form.  This was amplified as the topology became
   more fully connected without insulation of routing components from
   each other.

限られたツールとプロトコルだけがダイナミックルーティング情報の流れを設計するために利用可能であったなら、ルーティング輪が形成されるのは、かなり簡単でした。 トポロジーが互いからのルーティングコンポーネントの絶縁なしで、より完全に接続されるようになったとき、これは増幅されました。

   All six nodes of the Phase 1 Backbone were located at client sites,
   specifically NSF funded supercomputer centers.

Phase1Backboneのすべての6つのノードがクライアントサイトに位置して、明確にNSFはスーパーコンピュータセンターに資金を供給しました。

2. NSFNET Phase 2 Routing Architecture

2. NSFNETフェーズ2ルート設定構造

   The routing architecture for the second phase of the NSFNET Backbone,
   implemented on T1 (1.5Mbps) lines, focused on the lessons learned in
   the first NSFNET phase.  This resulted in a strong decoupling of the
   IGP environments of the backbone network and its attached clients
   [5].  Specifically, each of the administrative entities was able to
   use its own IGP in any way appropriate for the specific network.  The
   interface between the backbone network and its attached client was
   built by means of exterior routing, initially via the Exterior
   Gateway Protocol (EGP) [1,4].

T1(1.5Mbps)線の上で実行されたNSFNET Backboneの2番目のフェーズのためのルーティング構造は最初のNSFNETフェーズで学習されたレッスンに焦点を合わせました。 これは背骨ネットワークとその付属クライアント[5]のIGP環境の強いデカップリングをもたらしました。 明確に、それぞれの管理実体は何らかの方法で特定のネットワークに適切な状態でそれ自身のIGPを使用できました。 背骨ネットワークとその付属クライアントとのインタフェースは初めはExteriorゲートウェイプロトコル(EGP)[1、4]を通して掘られる外部によって造られました。

   EGP improved provided routing isolation in two ways.  First, EGP
   signals only up/down transitions for individual network numbers, not
   the fluctuations of metrics (with the exception of metric acceptance
   of local relevance to a single Nodal Switching System (NSS) only for
   inbound routing information, in the case of multiple EGP peers at a
   NSS).  Second, it allowed engineering of the dynamic distribution of
   routing information.  That is, primary, secondary, etc., paths can be
   determined, as long as dynamic externally learned routing information
   is available.  This allows creation of a spanning tree routing

EGPは2つの方法で提供されたルーティング孤立を改良しました。 まず最初に、EGPは測定基準の変動ではなく、個々のネットワーク・ナンバーのための/下に変遷(NSSの複数のEGP同輩のケースの中のインバウンド・ルーティング情報のためだけの独身のNodal Switching System(NSS)への地方の関連性のメートル法の承認を除いた)だけに合図します。 2番目に、それはルーティング情報のダイナミックな分配の工学を許容しました。 すなわち、第一の、そして、二次のなど、経路は決定できて、動力が外部的に学んだ限り、ルーティング情報は利用可能です。 これはスパニングツリールーティングの創造を許します。

Braun & Rekhter                                                 [Page 2]

RFC 1222       Advancing the NSFNET Routing Architecture        May 1991

NSFNETルート設定構造1991年5月に進むブラウンとRekhter[2ページ]RFC1222

   topology, satisfying the constraints of EGP.

EGPの規制を満たすトポロジー。

   The pre-engineering of routes is accomplished by means of a routing
   configuration database that is centrally controlled and created, with
   a subsequent distribution of individual configuration information to
   all the NSFNET Backbone nodes.  A computer controlled central system
   ensures the correctness of the database prior to its distribution to
   the nodes.

ルートのプレ工学は中心で制御されて、作成されるルーティング設定データベースによって達成されます、すべてのNSFNET Backboneノードへの個々の設定情報のその後の分配で。 コンピュータの制御主要なシステムは分配の前にデータベースの正当性をノードに確実にします。

   All nodes of the 1.5Mbps NSFNET Backbone (currently fourteen) are
   located at client sites, such as NSF funded supercomputer centers and
   mid-level network attachment points.

1.5Mbps NSFNET Backbone(現在の14)のすべてのノードがクライアントサイト(NSFがスーパーコンピュータセンターと中間レベルのネットワーク付着点に資金を供給したようなもの)に位置しています。

3. T3 Phase of the NSFNET Backbone

3. NSFNET背骨のT3フェーズ

   The T3 (45Mbps) phase of the NSFNET Backbone is implemented by means
   of a new architectural model, in which the principal communication
   nodes (core nodes) are co-located with major phone company switching
   facilities.  Those co-located nodes then form a two-dimensional
   networking infrastructure "cloud".  Individual sites are connected
   via exterior nodes (E-NSS) and typically have a single T3 access line
   to a core node (C-NSS).  That is, an exterior node is physically at
   the service subscriber site.

NSFNET BackboneのT3(45Mbps)フェーズは新しい建築モデルによって実行されます。そこでは、主要なコミュニケーションノード(コアノード)は主要な電話会社の切り換え施設で共同位置しています。 そして、それらの共同見つけられたノードは二次元ネットワークインフラストラクチャ「雲」を形成します。 個々のサイトは、外のノード(E- NSS)でつなげられて、コアノード(C-NSS)にただ一つのT3アクセス回線を通常持っています。 すなわち、外のノードは物理的にそうです。サービス加入者サイトで。

   With respect to routing, this structure is invisible to client sites,
   as the routing interface uses the same techniques as the T1 NSFNET
   Backbone.  The two backbones will remain independent infrastructures,
   overlaying each other and interconnected by exterior routing, and the
   T1 Backbone will eventually be phased out as a separate network.

ルーティングに関して、この構造はクライアントサイトに目に見えません、ルーティングインタフェースがT1 NSFNET Backboneと同じテクニックを使用するとき。 2つの背骨が、互いをかぶせて、独立しているインフラストラクチャのままで残って、外のルーティングで内部連絡しました、そして、T1 Backboneは結局、別々のネットワークとして段階的に廃止されるでしょう。

4. A Near-term Routing Alternative

4. 短期間ルート設定代替手段

   The experience with the T1/T3 NSFNET routing demonstrated clear
   advantages of this routing architecture in which the whole
   infrastructure is strongly compartmentalized.  Previous experience
   also showed that the architecture imposes certain obligations upon
   the attached client networks.  Among them is the requirement that a
   service subscriber must deploy its own routing protocol peer,
   participating in the IGP of the service subscriber and connected via
   a common subnet to the subscriber-site NSFNET node.  The router and
   the NSFNET Backbone exchange routing information via an EGP or BGP
   [7] session.

T1/T3 NSFNETルーティングの経験は全体のインフラストラクチャが強く分類されるこのルーティング構造の明らかに有利な立場を示しました。 また、以前の経験は、構造が付属クライアントネットワークに、ある義務を押しつけるのを示しました。 それらの中に、サービス加入者がサービス加入者のIGPに参加して、加入者サイトNSFNETノードへの一般的なサブネットで接されたそれ自身のルーティング・プロトコル同輩を配備しなければならないという要件があります。 ルータとNSFNET BackboneはEGPかBGP[7]セッションでルーティング情報を交換します。

   The drawbacks imposed by this requirement will become more obvious
   with the transition to the new architecture that is employed by the
   T3 phase of the NSFNET Backbone.  This will allow rapid expansion to
   many and smaller sites for which a very simple routing interface may
   be needed.

この要件によって課された欠点はNSFNET BackboneのT3フェーズによって使われる新しい構造への変遷で、より明白になるでしょう。 これは非常に簡単なルーティングインタフェースが必要であるかもしれない多くて、より小さいサイトに急速拡大を許容するでしょう。

Braun & Rekhter                                                 [Page 3]

RFC 1222       Advancing the NSFNET Routing Architecture        May 1991

NSFNETルート設定構造1991年5月に進むブラウンとRekhter[3ページ]RFC1222

   We strongly believe that separating the routing of the service
   subscriber from the NSFNET Backbone routing via some kind of EGP is
   the correct routing architecture.  However, it should not be
   necessary to translate this architecture into a requirement for each
   service subscriber to install and maintain additional equipment, or
   for the subscriber to deal with more complicated routing
   environments.  In other words, while maintaining that the concept of
   routing isolation is correct, we view the present implementation of
   the concept as more restrictive than necessary.

私たちは、ある種のEGPを通してNSFNET Backboneルーティングとサービス加入者のルーティングを切り離すのが、正しいルーティング構造であると強く信じています。 しかしながら、それぞれのサービス加入者が追加装備をインストールして、維持するか、または加入者が、より複雑なルーティング環境に対処するという要件にこの構造を翻訳するのは必要であるべきではありません。 言い換えれば、ルーティング孤立の概念が正しいと主張している間、私たちは、概念の現在の実現が必要とするより制限しているとみなします。

   An alternative implementation of this concept may be realized by
   separating the requirement for an EGP/BGP session, as the mechanism
   for exchanging routing information between the service subscriber
   network and the backbone, from the actual equipment that has to be
   deployed and maintained to support such a requirement.  The only
   essential requirement for routing isolation is the presence of two
   logical routing entities.  The first logical entity participates in
   the service subscriber's IGP, the second logical entity participates
   in the NSFNET Backbone IGP, and the two logical entities exchange
   information with each other by means of inter-domain mechanisms.  We
   suggest that these two logical entities could exist within a single
   physical entity.

この概念の代替の実現はEGP/BGPセッションのための要件を切り離すことによって、実現されるかもしれません、サービス加入者ネットワークと背骨の間でルーティング情報を交換するためのメカニズムとして、そのような要件を支持するために配備されて、維持されなければならない実際の設備から。 ルーティング孤立のための唯一の必須の条件は2つの論理的なルーティング実体の存在です。 最初の論理的な実体はサービス加入者のIGPに参加します、そして、2番目の論理的な実体はNSFNET Backbone IGPに参加します、そして、2つの論理的な実体が相互ドメインメカニズムによって互いと共に情報交換します。私たちは、これらの2つの論理的な実体がただ一つの物理的実体の中に存在できたことを提案します。

   In terms of implementation, this would be no different from a
   gatedaemon system interfacing with the previous 56Kbps NSFNET
   Backbone from the regional clients, except that we want to continue
   the strong routing and administrative control that decouple the two
   IGP domains.  Retaining an inter-domain mechanism (e.g., BGP) to
   connect the two IGP domains within the single physical entity allows
   the use of a well defined and understood interface.  At the same
   time, care must be taken in the implementation that the two daemons
   will not simultaneously interact with the system kernel in unwanted
   ways.

実現では、これは地方のクライアントから前の56Kbps NSFNET Backboneに連結するgatedaemonシステムと異なっていないでしょう、2つのIGPドメインの衝撃を吸収する強いルーティングと運営管理コントロールを続けたいと思うのを除いて。 ただ一つの物理的実体の中で2つのIGPドメインをつなげるために、相互ドメインメカニズム(例えば、BGP)を保有すると、よく定義されて、理解されているインタフェースの使用は許されます。 同時に、2つのデーモンが同時にシステムカーネルで求められていない方法で相互作用させない実現で注意しなければなりません。

   The possibility of interfacing two IGP domains within a single router
   has also been noted in [8].  For the NSFNET Backbone case, we propose
   in addition to retain strong firewalls between the IGP domains.  The
   IGP information would need to be tagged with exterior domain
   information at its entry into the other IGP.  It would also be
   important to allow distributed control of the configuration.  The
   NSFNET Backbone organization and the provider of the attached client
   network are each responsible for the integrity of their own routing
   information.

また、ただ一つのルータの中で2つのIGPドメインを連結する可能性は[8]に述べられました。 に加えてNSFNET Backboneケースのために、私たちが提案する、IGPドメインの間で堅固なファイアウォールを保有してください。 IGP情報は、外のドメイン情報がエントリーにある状態でもう片方のIGPにタグ付けをされる必要があるでしょう。 また、構成の分散制御を許容するのも重要でしょう。 付属クライアントネットワークのNSFNET Backbone組織とプロバイダーはそれぞれそれら自身のルーティング情報の保全に原因となります。

   An example implementation might be a single routing engine that
   executed two instances of routing daemons.  In the NSFNET Backbone
   case, one of the daemons would participate in the service
   subscriber's IGP, and the other would participate in the NSFNET

例の実現はルーティングデーモンの2つの例を実行した単一のルーティングエンジンであるかもしれません。 NSFNET Backbone場合では、デーモンの1つはサービス加入者のIGPに参加するでしょう、そして、もう片方がNSFNETに参加するでしょう。

Braun & Rekhter                                                 [Page 4]

RFC 1222       Advancing the NSFNET Routing Architecture        May 1991

NSFNETルート設定構造1991年5月に進むブラウンとRekhter[4ページ]RFC1222

   Backbone IGP.  These two instances could converse with each other by
   running EGP/BGP via a local loopback mechanism or internal IPC.  In
   the NSFNET Backbone implementation, the NSFNET T1 E-PSP or T3 E-NSS
   are UNIX machines, so the local loopback interface (lo0) of the UNIX
   operating system may be used.

背骨IGP。 これらの2つの例が、ローカルのループバックメカニズムか内部のIPCを通ってEGP/BGPを走らせることによって、互いと話すかもしれません。 NSFNET Backbone実現では、NSFNET T1E-PSPかT3E-NSSがUnixマシンであるので、Unixオペレーティングシステムの地方のループバックインタフェース(lo0)は使用されるかもしれません。

   Putting both entities into the same physical machine means that the
   E-PSP/E-NSS would participate in the regional IGP on its exterior
   interface.  We would still envision the Ethernet attachment to be the
   demarcation point for the administrative control and operational
   responsibility.  However, the regional client could provide the
   configuration information for the routing daemon that interfaced to
   the regional IGP, allowing the regional to continue to exercise
   control over the introduction of routing information into its IGP.

同じ物理的なマシンに両方の実体を入れるのは、E-PSP/E- NSSが外のインタフェースの地方のIGPに参加することを意味します。 私たちは、運営管理コントロールと操作上の責任のための画定ポイントになるようにまだイーサネット付属を思い描いているでしょう。 しかしながら、地方のクライアントは地方のIGPに連結したルーティングデーモンのための設定情報を提供できました、地方が、IGPへのルーティング情報の導入にコントロールを及ぼし続けているのを許容して。

5. Long-Term Alternatives

5. 長期の代替手段

   As technology employed by the NSFNET Backbone evolves, one may
   envision the demarcation line between the Backbone and the service
   subscribers moving in the direction of the "C-NSS cloud", so that the
   NSFNET IGP will be confined to the C-NSS, while the E-NSS will be a
   full participant in the IGP of the service subscriber.

NSFNET Backboneによって使われた技術が発展するとき、Backboneとサービス加入者の間の境界線が「C-NSS雲」の向きに動くのを思い描くかもしれません、NSFNET IGPがC-NSSに閉じ込められるように、E-NSSはサービス加入者のIGPの完全な関係者になるでしょうが。

   Clearly, one of the major prerequisites for such an evolution is the
   ability for operational management of the physical medium connecting
   a C-NSS with an E-NSS by two different administrative entities (i.e.,
   the NSFNET Backbone provider as well as the service subscriber).  It
   will also have to be manageable enough to be comparable in ease of
   use to an Ethernet interface, as a well-defined demarcation point.

明確に、そのような発展のための主要な前提条件の1つは2つの異なった管理実体(すなわち、サービス加入者と同様にNSFNET Backboneプロバイダー)でC-NSSをE-NSSに接続する物理的な媒体の運営管理のための能力です。 また、それは使いやすさでイーサネットインタフェースに匹敵できるくらい処理しやすくならなければならないでしょう、明確な画定ポイントとして。

   The evolution of the Point-to-Point Protocol, as well as a
   significantly enhanced capability for managing serial lines via
   standard network management protocols, will clearly help.  This may
   not be the complete answer, as a variety of equipment is used on
   serial lines, making it difficult to isolate a hardware problem.
   Similar issues may arise for future demarcation interfaces to
   Internet infrastructure (e.g., SMDS interfaces).

Pointからポイントへのプロトコルの発展、および標準のネットワーク管理プロトコルでシリアル・ラインを管理するためのかなり高められた能力は明確に助けるでしょう。 これは完全な答えでないかもしれません、さまざまな設備がシリアル・ラインの上で使用されるとき、ハードウェア問題を隔離するのを難しくして。 同様の問題はインターネット基盤(例えば、SMDSインタフェース)への将来の画定インタフェースに起こるかもしれません。

   In summary, there is an opportunity to simplify the management,
   administration, and exchange of routing information by collapsing the
   number of physical entities involved.

概要には、物理的実体の数を潰すのによる情報がかかわったルーティングの管理、管理、および交換を簡素化する機会があります。

6. References

6. 参照

   [1] Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
       904, BBN, April 1984.

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

   [2] Mills, D., and H-W. Braun, "The NSFNET Backbone Network", SIGCOMM

[2] 工場、D.、およびH-W。 ブラウン、「NSFNET背骨ネットワーク」、SIGCOMM

Braun & Rekhter                                                 [Page 5]

RFC 1222       Advancing the NSFNET Routing Architecture        May 1991

NSFNETルート設定構造1991年5月に進むブラウンとRekhter[5ページ]RFC1222

       1987, August 1987.

1987年8月の1987。

   [3] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
       University, June 1988.

[3] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、ラトガース大学、1988年6月。

   [4] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
       Backbone", RFC 1092, IBM T.J. Watson Research Center, February
       1989.

[4] Rekhter、Y.、「EGPと方針は新しいNSFNET背骨におけるルート設定を基礎づけました」、RFC1092、IBM T.J.ワトソン研究所、1989年2月。

   [5] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
       Merit/NSFNET, February 1989.

[5] ブラウン、H-W.、「NSFNETルート設定構造」、RFC1093、長所/NSFNET、1989年2月。

   [6] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
       Merit/NSFNET, June 1989.

[6] ブラウン、H-W.、「方針のベースのルート設定のモデル」、RFC1104、長所/NSFNET、1989年6月。

   [7] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol (BGP)",
       RFC 1163, cisco Systems, IBM T.J. Watson Research Center, June
       1990.

[7] ロッキード、K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル(BGP)」、RFC1163、コクチマスSystems、IBM T.J.ワトソン研究所(1990年6月)。

   [8] Almquist, P., "Requirements for Internet IP Routers", to be
       published as a RFC.

[8]Almquist、P.、「インターネットIPルータのための要件」、RFCとして発行されるために。

7.  Security Considerations

7. セキュリティ問題

   Security issues are not discussed in this memo.

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

8. Authors' Addresses

8. 作者のアドレス

   Hans-Werner Braun
   San Diego Supercomputer Center
   P.O. Box 85608
   La Jolla, CA 92186-9784

ハンス-ヴェルナーブラウンサンディエゴスーパーコンピュータセンター私書箱85608ラ・ホーヤ、カリフォルニア92186-9784

   Phone: (619) 534-5035
   Fax:   (619) 534-5113

以下に電話をしてください。 (619) 534-5035 Fax: (619) 534-5113

   EMail: HWB@SDSC.EDU

メール: HWB@SDSC.EDU

   Yakov Rekhter
   T.J. Watson Research Center
   IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY  10598

ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱218ヨークタウンの高さ、10598

   Phone: (914) 945-3896

以下に電話をしてください。 (914) 945-3896

   EMail: Yakov@Watson.IBM.COM

メール: Yakov@Watson.IBM.COM

Braun & Rekhter                                                 [Page 6]

ブラウンとRekhter[6ページ]