RFC947 日本語訳

Network Working Group                                       Ken Lebowitz
Request for Comments: 947                                  David Mankins
                                                        BBN Laboratories
                                                               June 1985

コメントを求めるワーキンググループケンレボウィッツRequestをネットワークでつないでください: 947 デヴィッドマンキンズBBN研究所1985年6月

             Multi-network Broadcasting within the Internet

インターネットの中のマルチネットワーク放送

1. Status of this Memo

1. このMemoの状態

   This RFC describes the extension of a network's broadcast domain to
   include more than one physical network through the use of a broadcast
   packet repeater.

このRFCは、放送パケットリピータの使用で1つ以上の物理ネットワークを含むようにネットワークの放送ドメインの拡大について説明します。

   The following paper will present the problem of multi-network
   broadcasting and our motivation for solving this problem which is in
   the context of developing a distributed operating system.  We discuss
   different solutions to extending a broadcast domain and why we chose
   the one that has been implemented.  In addition, there is information
   on the implementation itself and some notes on its performance.

以下の紙は分配されたオペレーティングシステムを開発することの文脈にあるこの問題を解決することに関するマルチネットワーク放送と私たちの動機の問題を提示するでしょう。 私たちは放送ドメインと私たちが実装されたものを選んだ理由を広げるのと異なったソリューションについて議論します。 さらに、実装自体の情報と性能に関するいくつかの注があります。

   It is hoped that the ideas presented here will help people in the
   Internet who have applications which make use of broadcasting and
   have come up against the limitation of only being able to broadcast
   within a single network.

ここに提示された考えがインターネットの放送を利用するアプリケーションを持っている人々を助けて、ただ一つのネットワークの中で放送できるだけの制限に直面していたことが望まれています。

   The information presented here is accurate as of the date of
   publication but specific details, particularly those regarding our
   implementation, may change in the future.  Distribution of this memo
   is unlimited.

ここに提示された情報は公表の日付現在、正確ですが、特定の詳細(特に私たちの実装に関するそれら)は将来、変化するかもしれません。 このメモの分配は無制限です。

2. The Problem

2. 問題

   Communication between hosts on separate networks has been addressed
   largely through the use of Internet protocols and gateways. One
   aspect of internetwork communication that hasn't been solved in the
   Internet is extending broadcasting to encompass two or more networks.
   Broadcasting is an efficient way to send information to many hosts
   while only having to transmit a single packet.  Many of the current
   local area network (LAN) architectures directly support a broadcast
   mechanism.  Unfortunately, this broadcast mechanism has a shortcoming
   when it is used in networking environments which include multiple
   LANs connected by gateways such as in the DARPA Internet.  This
   shortcoming is that broadcasted packets are only received by hosts on
   the physical network on which the packet was broadcast.  As a result,
   any application which takes advantage of LAN broadcasting can only
   broadcast to those hosts on its physical network.

別々のネットワークのホストのコミュニケーションは主にインターネットプロトコルとゲートウェイの使用で扱われました。 インターネットで解決されていないインターネットワークコミュニケーションの1つの局面は2つ以上のネットワークを包含するように放送される広がりです。 放送は唯一である多くのホストに情報を送る単一のパケットを伝えなければならない効率的な方法です。 現在のローカル・エリア・ネットワーク(LAN)アーキテクチャの多くが直接放送メカニズムをサポートします。 それがDARPAインターネットなどのゲートウェイによって接続された複数のLANを含んでいるネットワーク環境で使用されるとき、残念ながら、この放送メカニズムには、短所があります。 この短所はbroadcastedパケットがパケットが放送された物理ネットワークにホストによって受け取られるだけであるということです。 その結果、LAN放送を利用するどんなアプリケーションも物理ネットワークでそれらのホストに放送されることができるだけです。

   We took advantage of broadcasting in developing the Cronus
   Distributed Operating System [1].  Cronus provides services and
   communication to processes distributed among a variety of different

私たちはクロノスDistributed Operating System[1]を開発する際に放送する利点を活用しました。 クロノスが分配されたプロセスへのサービスとコミュニケーションを提供する、様々である、相違

Lebowitz & Mankins                                              [Page 1]

レボウィッツとマンキンズ[1ページ]

RFC 947                                                        June 1985
Multi-network Broadcasting within the Internet

インターネットの中で放送されるRFC947 1985年6月のマルチネットワーク

   types of computer systems.  Cronus is built around logical clusters
   of hosts connected to one or more high-speed LANs.  Communication in
   Cronus is built upon the TCP and UDP protocols.  Cronus makes use of
   broadcasting for dynamically locating resources on other hosts and
   collecting status information from a collection of servers.  Since
   Cronus's broadcast capabilities are not intended to be limited to the
   boundaries of a single LAN, we needed to find some way to extend our
   broadcasting domain to include hosts on distant LANs in order to
   experiment with clusters that span several physical networks.  Cronus
   predominantly uses broadcasting to communicate with a subset of the
   hosts that actually receive the broadcasted message.  A multicast
   mechanism would be more appropriate, but was unavailable in some of
   our network implementations, so we chose broadcast for the initial
   implementation of Cronus utilities.

コンピュータ・システムクロノスのタイプは1つ以上の高速LANに接続されたホストの論理的なクラスタの周りに造られます。 クロノスのコミュニケーションはTCPとUDPプロトコルで築き上げられます。 クロノスはダイナミックに他のホストにリソースの場所を見つけて、サーバの収集から状態情報を集めるために放送することの使用をします。 以来クロノスsの放送能力によって単一のLANの境界に制限されることを意図しないで、私たちは、その長さのクラスタでいくつかの物理ネットワークを実験するために遠方のLANでホストを含むように私たちの放送ドメインを広げる何らかの方法を見つける必要がありました。 クロノスは、実際にbroadcastedメッセージを受け取るホストの部分集合で交信するのに放送を支配的に使用します。 マルチキャストメカニズムは、より適切でしょう、私たちのネットワーク実装のいくつかで入手できなかったのでクロノスユーティリティの初期の実装のために放送するのを除いて私たちが、選んだ。

3. Our Solution

3. 私たちのソリューション

   The technique we chose to experiment with the multi-network
   broadcasting problem can be described as a "broadcast repeater".  A
   broadcast repeater is a mechanism which transparently relays
   broadcast packets from one LAN to another, and may also forward
   broadcast packets to hosts on a network which doesn't support
   broadcasting at the link-level.  This mechanism provides flexibility
   while still taking advantage of the convenience of LAN broadcasts.

私たちがマルチネットワーク放送問題で実験するのを選んだテクニックを「放送リピータ」として記述できます。 放送リピータは、透過的に放送パケットをリレーする1つのLANから別のLANまでのメカニズムであり、また、リンク・レベルで放送をサポートしないネットワークで放送パケットをホストに送るかもしれません。 このメカニズムはまだLAN放送の便利を利用している間、柔軟性を提供します。

   Our broadcast repeater is a process on a network host which listens
   for broadcast packets.  These packets are picked up and
   retransmitted, using a simple repeater-to-repeater protocol, to one
   or more repeaters that are connected to distant LANs.  The repeater
   on the receiving end will rebroadcast the packet on its LAN,
   retaining the original packet's source address.  The broadcast
   repeater can be made very intelligent in its selection of messages to
   be forwarded.  We currently have the repeater forward only broadcast
   messages sent using the UDP ports used by Cronus, but messages may be
   selected using any field in the UDP or IP headers, or all IP-level
   broadcast messages may be forwarded.

私たちの放送リピータはネットワークホストの上の放送パケットの聞こうとするプロセスです。 これらのパケットは、拾われて、再送されます、リピータからリピータへの簡単なプロトコルを使用して、遠方のLANに接続される1つ以上のリピータに。 オリジナルのパケットのソースアドレスを保有して、リピータはLANで受ける側になってパケットを再放送するでしょう。 放送リピータを進められるべきメッセージの品揃えで非常に知的にすることができます。 私たちはリピータに現在、クロノスによって使用されたUDPポートが使用させられる同報メッセージだけを転送させますが、UDPかIPヘッダーのどんな分野も使用することでメッセージを選択するかもしれませんか、またはすべてのIP-レベル同報メッセージを転送するかもしれません。

4. Alternatives to the Broadcast Repeater

4. 放送リピータへの代替手段

   We explored a few alternatives before deciding on our technique to
   forward broadcast messages.  One of these methods was to put
   additional functions into the Internet gateways.  Gateways could
   listen at the link-level for broadcast packets and relay the packets
   to one or more gateways on distant LANs.  These gateways could then
   transmit the same packet onto their networks using the local
   network's link-level broadcast capability, if one is available.  All
   gateways participating in this scheme would have to maintain tables

私たちは私たちのテクニックで同報メッセージを転送すると決める前に、いくつかの選択肢を探りました。 これらのメソッドの1つはインターネット・ゲートウェイに追加機能を入れることでした。 ゲートウェイは、放送パケットのためにリンク・レベルで聴いて、遠方のLANの1門以上にパケットをリレーするかもしれません。 次に、これらのゲートウェイは企業内情報通信網のリンク・レベル放送能力を使用することで同じパケットをそれらのネットワークに伝えるかもしれません、1つが利用可能であるなら。 この体系に参加するすべてのゲートウェイがテーブルを維持しなければならないでしょう。

Lebowitz & Mankins                                              [Page 2]

レボウィッツとマンキンズ[2ページ]

RFC 947                                                        June 1985
Multi-network Broadcasting within the Internet

インターネットの中で放送されるRFC947 1985年6月のマルチネットワーク

   of all other gateways which are to receive broadcasts.  If the
   recipient gateway was serving a network without a capacity to
   broadcast it could forward the messages directly to one or more
   designated hosts on its network but, again, it would require that
   tables be kept in the gateway.  Putting this sort of function into
   gateways was rejected for a number of reasons: (a) it would require
   extensions to the gateway control protocol to allow updating the
   lists gateways would have to maintain, (b) since not all messages
   (e.g., LAN address- resolution messages) need be forwarded, the need
   to control forwarding should be under the control of higher levels of
   the protocol than may be available to the gateways, (c) Cronus could
   be put into environments where the gateways may be provided by
   alternative vendors who may not implement broadcast propagation, (d)
   as a part of the underlying network, gateways are likely to be
   controlled by a different agency from that controlling the
   configuration of a Cronus system, adding bureaucratic complexity to
   reconfiguration.

他のすべてのゲートウェイでは、どれが受信されることになっているかは放送されます。 受取人ゲートウェイが放送する容量なしでネットワークに役立っているなら、ネットワークで直接1かさらに指定されたホストにメッセージを転送するかもしれないでしょうにが、一方、それは、テーブルがゲートウェイに保たれるのを必要とするでしょう。 この種類の関数をゲートウェイに入れるのは様々な意味で拒絶されました: (a) ゲートウェイが維持しなければならないリストをアップデートするのを許容するのがゲートウェイ制御プロトコルに拡大を必要とするでしょう、(b) すべてのメッセージ(例えば、LANは解決メッセージを扱う)を転送しなければならないというわけではないので推進を制御する必要がプロトコルのゲートウェイに利用可能であるかもしれないより高いレベルのコントロールの下にあるべきです; (c) ゲートウェイが(d) 基本的なネットワークの一部として、放送伝播を実装しないかもしれない代替のベンダーによってゲートウェイがクロノスシステムの構成を制御しながらそれと異なった政府機関によって制御されそうであるかどうかということであるかもしれない環境にクロノスを入れることができました、官僚の複雑さを再構成に加えて。

   Another idea which was rejected was to put broadcast functionality
   into the Cronus kernel.  The Cronus kernel is a process which runs on
   each host participating in Cronus, and has the task of routing all
   messages passed between Cronus processes.  The Cronus kernel is the
   only program in the Cronus system which directly uses broadcast
   capability (other parts of Cronus communicate using mechanisms
   provided by the kernel).  We could either entirely remove the Cronus
   kernel's dependence on broadcast, or add a mechanism for emulating
   broadcast using serially-transmitted messages when the underlying
   network does not provide a broadcast facility itself.  Either
   solution requires all Cronus kernel processes to know the addresses
   of all other participants in a Cronus system, which we view as an
   undesirable limit on configuration flexibility.  Also, this solution
   would be Cronus-specific, while the broadcast-repeater solution is
   applicable to other broadcast-based protocols.

拒絶された別の考えはクロノスカーネルに放送の機能性を入れることでした。 クロノスカーネルはクロノスに参加する各ホストで走って、クロノスプロセスの間ですべてのメッセージを発送するタスクを通過するプロセスです。 クロノスカーネルはクロノスシステムで直接放送能力を使用する唯一のプログラム(クロノスの他の部分はカーネルによって提供されたメカニズムを使用することで交信する)です。 基本的なネットワークが放送施設自体を提供しないとき、私たちは、放送へのクロノスカーネルの依存を完全に取り除くか、または放送使用を見習うためのメカニズムが順次メッセージを送ったと言い足すことができました。 どちらのソリューションも、クロノスシステムで他のすべての関係者のアドレスを知るためにすべてのクロノスカーネルプロセスを必要とします。(私たちは構成の柔軟性における望ましくない限界をシステムとみなします)。 また、このソリューションもクロノス特有でしょうが、放送リピータソリューションは他の放送ベースのプロトコルに適切です。

5. Implementation

5. 実装

   The broadcast repeater is implemented as two separate processes - the
   forwarder and the repeater.  The forwarder process waits for
   broadcast UDP packets to come across its local network which match
   one or more specific port numbers (or destination addresses).  When
   such a packet is found, it is encapsulated in a forwarder-repeater
   message sent to a repeater process on a foreign network.  The
   repeater then relays the forwarded packet onto its LAN using that
   network's link-level broadcast address in the packet's destination
   field, but preserving the source address from the original packet.

2がプロセスを切り離すとき、放送リピータは実装されます--混載業者とリピータ。 混載業者プロセスは、放送UDPパケットが企業内情報通信網を偶然見つけるのを待っています(1つ以上の特定のポートナンバー(または、送付先アドレス)に合っています)。 そのようなパケットが見つけられるとき、それは外国ネットワークでリピータプロセスに送られた混載業者リピータメッセージでカプセル化されます。 そして、リピータはパケットのあて先フィールドでそのネットワークのリンク・レベル放送演説を使用しますが、オリジナルのパケットからソースアドレスを保存するLANに進められたパケットをリレーします。

   When the forwarder process starts for the first time it reads a

混載業者プロセスが初めて始まるとき、それはaを読みます。

Lebowitz & Mankins                                              [Page 3]

レボウィッツとマンキンズ[3ページ]

RFC 947                                                        June 1985
Multi-network Broadcasting within the Internet

インターネットの中で放送されるRFC947 1985年6月のマルチネットワーク

   configuration file.  This file specifies the addresses of repeater
   processes, and selects which packets should be forwarded to each
   repeater process (different repeaters may select different sets of
   UDP packets).  The forwarder attempts to establish a TCP connection
   to each repeater listed in the configuration file.  If a TCP link to
   a repeater fails, the forwarder will periodically retry connecting to
   it.  Non-repeater hosts may also be listed in the configuration file.
   For these hosts the forwarder will simply replace the destination
   broadcast address in the UDP packet with the host's address and send
   this new datagram directly to the non-repeater host.

構成ファイル。 このファイルは、リピータプロセスのアドレスを指定して、どのパケットがそれぞれのリピータプロセスに送られるべきであるかを選択します(異なったリピータは異なったセットのUDPパケットを選択するかもしれません)。 混載業者は、構成ファイルに記載された各リピータにTCP接続を確立するのを試みます。 リピータへのTCPリンクが失敗すると、混載業者は、それに接続しながら、定期的に再試行するでしょう。 また、非リピータホストは構成ファイルに記載されているかもしれません。 これらのホストに関しては、混載業者は、UDPパケットで単に目的地放送演説をホストのアドレスに置き換えて、直接非リピータホストにこの新しいデータグラムを送るでしょう。

   If a repeater and a forwarder co-exist on the same LAN a problem may
   arise if the forwarder picks up packets which have been rebroadcast
   by the repeater.  As a precaution against rebroadcast of forwarded
   packets ("feedback" or "ringing"), the forwarder does not connect to
   any repeaters listed in its configuration file which are on the same
   network as the forwarder itself.  Also, to avoid a broadcast loop
   involving two LANs, each with a forwarder talking to a repeater on
   the other LAN, forwarders do not forward packets whose source address
   is not on the forwarder's LAN.

リピータと混載業者が同じLANに共存するなら、混載業者がリピータを再放送することであるパケットを拾うなら、問題は起こるかもしれません。 注意が再放送する、進められたパケット(「フィードバック」か「鳴る」)では、混載業者は構成ファイルに記載されたどんなリピータにも接続しません(混載業者自身と同じネットワークにあります)。 また、それぞれもう片方のLANに関してリピータと話す混載業者に2つのLANにかかわる放送輪を避けるために、混載業者はソースアドレスが混載業者のLANにないパケットを進めません。

6. Experience

6. 経験

   To date, the broadcast repeater has been implemented on the VAX
   running 4.2 BSD UNIX operating system with BBN's networking software
   and has proven to work quite well for our purposes.  Our current
   configuration includes two Ethernets which are physically separated
   by two other LANs.  For the past few months the broadcast repeater
   has successfully extended our broadcast domain to include both
   Ethernets even though messages between the two networks must pass
   through at least two gateways.  We were forced to add a special
   capability to the BBN TCP/IP implementation which allows privileged
   processes to send out IP packets with another host's source address.

これまで、放送リピータは、VAXの実行している4.2BSD UnixオペレーティングシステムでBBNのネットワークソフトウェアで実装されて、私たちの目的にかなりうまくいくと判明しました。 私たちの現在の構成は他の2つのLANによって物理的に切り離される2Ethernetsを含んでいます。 過去数カ月、放送リピータは、2つのネットワークの間のメッセージが少なくとも2門を通り抜けなければなりませんが、両方のEthernetsを含むように首尾よく私たちの放送ドメインを広げています。 私たちは別のホストのソースアドレスでやむを得ず特権があるプロセスがIPパケットを出すことができるBBN TCP/IPインプリメンテーションへの特別な能力を加えました。

   The repeater imposes a fair amount of overhead on the shared hosts
   that currently support it due to the necessity of waking the
   forwarder process on all UDP packets which arrive at the host, since
   the decision to reject a packet is made by user-level software,
   rather than in the network protocol drivers.  One solution to this
   problem would be to implement the packet filtering in the system
   kernel (leaving the configuration management and rebroadcast
   mechanism in user code) as has been done by Stanford/CMU in a UNIX
   packet filter they have developed.  As an alternative we are planning
   to rehost the implementation of the repeater function as a
   specialized network service provided by a microcomputer based

リピータは現在ホストに到着するすべてのUDPパケットの上で混載業者プロセスを起こすという必要性のためそれをサポートする共有されたホストに公正な量のオーバーヘッドを課します、ネットワーク・プロトコルドライバーでというよりむしろユーザレベルソフトウェアで、パケットを拒絶するという決定をするので。 ユーザでメカニズムを再放送してください。そして、この問題への1つの解決がシステムカーネルにおけるパケットフィルタリングを実装するだろうことである、(構成管理を残す、コード) 彼らが開発したUNIXパケットフィルタでスタンフォード/米カーネギーメロン大学によって行われたように。 代替手段として、私たちはベースのマイクロコンピュータによって提供された専門化しているネットワーク・サービスとしてリピータ機能の実装を「再-ホスト」に計画しています。

Lebowitz & Mankins                                              [Page 4]

レボウィッツとマンキンズ[4ページ]

RFC 947                                                        June 1985
Multi-network Broadcasting within the Internet

インターネットの中で放送されるRFC947 1985年6月のマルチネットワーク

   real-time system which is already part of our Cronus configuration.
   Such a machine is better suited to the task since scheduling overhead
   is much less for them than it is on a multi-user timesharing system.

既に私たちのクロノス構成の一部であるリアルタイムのシステム。 それらには、スケジューリングオーバーヘッドがそれよりはるかにマルチユーザ時分割システムの上で少ないので、そのようなマシンはタスクに合うほうがよいです。

7. Reference

7. 参照

   [1]  "Cronus, A Distributed Operating System: Phase 1 Final Report",
        R. Schantz, R. Thomas, R. Gurwitz, G. Bono, M. Dean,
        K. Lebowitz, K.  Schroder, M. Barrow and R. Sands, Technical
        Report No. 5885, Bolt Beranek and Newman, Inc., January 1985.
        The Cronus project is supported by the Rome Air Development
        Center.

[1] 「クロノス、Aはオペレーティングシステムを分配しました」。 「フェーズ1つの最終報告書」、R.Schantz、R.トーマス、R.Gurwitz、G.ボーノ、M.ディーン、K.レボウィッツ、K.シュローダー、M.手押し車、およびR.砂浜(技術報告書No.5885)はBeranekとニューマンInc.(1985年1月)をボルトで締めます。 クロノスプロジェクトはローム航空開発センターによってサポートされます。

8. Editors Note

8. エディターズ注意

   Also see RFCs 919 and 940 on this topic.

また、この話題のRFCs919と940を見てください。

Lebowitz & Mankins                                              [Page 5]

レボウィッツとマンキンズ[5ページ]