RFC966 日本語訳
0966 Host groups: A multicast extension to the Internet Protocol. S.E.Deering, D.R. Cheriton. December 1985. (Format: TXT=59469 bytes) (Obsoleted by RFC0988) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. E. Deering
Request for Comments: 966 D. R. Cheriton
Stanford University
December 1985
コメントを求めるワーキンググループS.E.デアリングの要求をネットワークでつないでください: 966 D.R.Cheritonスタンフォード大学1985年12月
Host Groups:
A Multicast Extension to the Internet Protocol
グループをホスティングしてください: インターネットプロトコルへのマルチキャスト拡大
1. Status of this Memo
1. このMemoの状態
This RFC defines a model of service for Internet multicasting and proposes an extension to the Internet Protocol (IP) to support such a multicast service. Discussion and suggestions for improvements are requested. Distribution of this memo is unlimited.
このRFCは、インターネットマルチキャスティングのためにサービスのモデルを定義して、そのようなマルチキャストサービスをサポートするためにインターネットプロトコル(IP)に拡大を提案します。 改良のための議論と提案は要求されています。 このメモの分配は無制限です。
2. Acknowledgements
2. 承認
This memo was adapted from a paper [7] presented at the Ninth Data Communications Symposium. This work was sponsored in part by the Defense Advanced Research Projects Agency under contract N00039-83- K-0431 and National Science Foundation Grant DCR-83-52048.
このメモはNinth Data Communications Symposiumで寄贈された論文[7]から翻案されました。 この仕事は契約N00039-83K-0431と科学基金グラントDCR-83-52048の下で国防高等研究計画庁によって一部後援されました。
The Internet task force on end-to-end protocols, headed by Bob Braden, has provided valuable input in the development of the host group model.
終わらせる終わりのボブ・ブレーデンによって率いられたインターネット特別委員会プロトコルはホストグループモデルの進化における貴重な入力を提供しました。
3. Introduction
3. 序論
In this paper, we describe a model of multicast service we call host groups and propose this model as a way to support multicast in the DARPA Internet environment [14]. We argue that it is feasible to implement this facility as an extension of the existing "unicast" IP datagram model and mechanism.
この紙では、私たちは、マルチキャストサービスのモデルのために私たち呼び出しホストグループについて説明して、DARPAインターネット環境[14]におけるマルチキャストをサポートする方法としてこのモデルを提案します。 私たちは、既存の「ユニキャスト」IPデータグラムモデルとメカニズムの拡大としてこの施設を実装するのが可能であると主張します。
Multicast is the transmission of a datagram packet to a set of zero or more destination hosts in a network or internetwork, with a single address specifying the set of destination hosts. For example, hosts A, B, C and D may be associated with multicast address X. On transmission, a packet with destination address X is delivered with datagram reliability to hosts A, B, C and D.
マルチキャストは1セットのゼロへのデータグラムパケットのトランスミッションであるか、より多くの目的地がネットワークかインターネットワークでホストです、ただ一つのアドレスがあて先ホストのセットを指定していて。 例えば、ホストA、B、C、およびDはマルチキャストアドレスX.On送信(XがホストA、B、C、およびDへのデータグラムの信頼性で提供される送付先アドレスがあるパケット)に関連しているかもしれません。
Multicast has two primary uses, namely distributed binding and multi-destination delivery. As a binding mechanism, multicast is a robust and often more efficient alternative to the use of name servers for finding a particular object or service when a particular host address is not known. For example, in a distributed file system, all the file servers may be associated with one well-known multicast address. To bind a file name to a particular server, a client sends a query packet containing the file name to the file server multicast address, for delivery to all the file servers. The
マルチキャストには、2つのプライマリ用途、すなわち、分配された拘束力があってマルチ目的地の配送があります。 結合機構として、マルチキャストはネームサーバの特定のホスト・アドレスが知られていないと特定のオブジェクトかサービスを見つける使用への強健でしばしばより効率的な代替手段です。 例えば、分散ファイルシステムでは、すべてのファイルサーバーが1つのよく知られるマルチキャストアドレスに関連しているかもしれません。 特定のサーバにファイル名を縛るために、クライアントはファイルサーバーマルチキャストアドレスにファイル名を含む質問パケットを送ります、すべてのファイルサーバーへの配送のために。 The
Deering & Cheriton [Page 1]
デアリングとCheriton[1ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
server that recognizes the file name then responds to the client, allowing subsequent interaction directly with that server host. Even when name servers are employed, multicast can be used as the first step in the binding process, that is, finding a name server.
直接そのサーバー・ホストとのその後の相互作用を許容して、その時ファイル名を認識するサーバがクライアントに反応します。 ネームサーバが採用してさえいるとき、第一歩として拘束力があるプロセスでマルチキャストを使用できて、それはそうです、ネームサーバを見つけて。
Multi-destination delivery is useful to several applications, including:
マルチの目的地配送はいくつかのアプリケーション、包含の役に立ちます:
- distributed, replicated databases [6,9].
- 分配されて、模写されたデータベース[6、9]。
- conferencing [11].
- 会議[11]。
- distributed parallel computation, including distributed
gaming [2].
- 分配されたゲーミング[2]を含む分配された並列計算。
Ideally, multicast transmission to a set of hosts is not more complicated or expensive for the sender than transmission to a single host. Similarly, multicast transmission should not be more expensive for the networks and gateways than traversing the shortest path tree that connects the sending host to the hosts identified by the multicast address.
理想的に、送付者には、1セットのホストへのマルチキャスト送信は、トランスミッションより独身のホストに複雑でもなくて、また高価でもありません。 同様に、マルチキャスト送信はネットワークとゲートウェイの割にはマルチキャストアドレスによって特定されたホストの送付ホストに接する最短パス木を横断するより高価であるべきではありません。
Multicast, transmission to a set of hosts, is properly distinguished from broadcast, transmission to all hosts on a network or internetwork. Broadcast is not a generally useful facility since there are few reasons for communicating with all hosts.
マルチキャスト(1セットのホストへのトランスミッション)は放送(ネットワークかインターネットワークのすべてのホストへのトランスミッション)と適切に区別されます。 すべてのホストとコミュニケートする理由がわずかしかないので、放送は一般に役に立つ施設ではありません。
A variety of local network applications and systems make use of multicast. For instance, the V distributed system [8] uses network-level multicast for implementing efficient operations on groups of processes spanning multiple machines. Similar use is being made for replicated databases [6] and other distributed applications [4]. Providing multicast in the Internet environment would allow porting such local network distributed applications to the Internet, as well as making some existing Internet applications more robust and portable (by, for example, removing "wired-in" lists of addresses, such as gateway addresses).
さまざまな企業内情報通信網アプリケーションとシステムがマルチキャストを利用します。 例えば、V分散システム[8]は、複数のマシンにかかりながらプロセスのグループで効率的な操作を実装するのにネットワークレベルマルチキャストを使用します。 模写されたデータベース[6]と他の分配されたアプリケーション[4]のために同様の使用をしています。 インターネット環境にマルチキャストを提供するのに、いくつかの既存のインターネットアプリケーションをより強健で携帯用に(例えば、取り外すことによって、ゲートウェイアドレスなどのアドレスのリストを「接合する」)することと同様にインターネットにそのような企業内情報通信網の分配されたアプリケーションを移植するでしょう。
At present, an Internet application logically requiring multicast must send individually addressed packets to each recipient. There are two problems with this approach. Firstly, requiring the sending host to know the specific addresses of all the recipients defeats its use as a binding mechanism. For example, a diskless workstation needs on boot to determine the network address of a disk server and it is undesirable to "wire in" specific network addresses. With a multicast facility, the multicast address of the boot servers (or
現在のところ、マルチキャストを論理的に必要とするインターネットアプリケーションは個別に扱われたパケットを各受取人に送らなければなりません。 このアプローチに関する2つの問題があります。 まず第一に、送付ホストがすべての受取人の特定のアドレスを知るのが必要であるのが結合機構として使用を破ります。 例えば、ディスクレスワークステーションは、ブーツの上にディスクサーバのネットワーク・アドレスを決定する必要があります、そして、特定のネットワーク・アドレスが「接合」であることは望ましくありません。 またはマルチキャスト施設、ブート・サーバーのマルチキャストアドレス、(。
Deering & Cheriton [Page 2]
デアリングとCheriton[2ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
name servers that hold the addresses of the boot servers) can be well-known, allowing the workstation to transmit its initial queries to this address.
ブート・サーバーのアドレスを保持するネームサーバ) よく知られる場合があります、ワークステーションが初期の質問をこのアドレスに伝えるのを許容して。
Secondly, transmitting multiple copies of the same packet makes inefficient use of network bandwidth, gateway resources and sender resources. For instance, the same packet may repeatedly traverse the same network links and pass through the same gateways. Furthermore, the local network level cannot recognize multi-destination delivery to take advantage of multicast facilities that the underlying network technologies may provide. For example, local-area bus, ring, or radio networks, as well as satellite-based wide-area networks, can provide efficient multicast delivery directly. Besides using excessive communication resources, the use of multiple transmissions to effect multicast severely limits the amount of parallelism in transmission and processing that can be achieved compared to an integrated multicast facility.
第二に、複本の同じパケットを伝えると、ネットワーク回線容量、ゲートウェイリソース、および送付者の効率の悪い使用はリソースにします。 例えば、同じパケットは、繰り返して同じネットワークリンクを横断して、同じゲートウェイを通り抜けるかもしれません。 その上、企業内情報通信網レベルは、基本的なネットワーク技術が提供するかもしれないマルチキャスト施設を利用するためにマルチの目的地配送を認識できません。 例えば、局部バス(リングか、ラジオ放送網と、衛星ベースの広域ネットワーク)は、直接効率的なマルチキャスト配送を提供できます。 過度のコミュニケーションリソースを使用すること以外に、効果マルチキャストへの複駆動動力伝達装置の使用は厳しく統合マルチキャスト施設と比べて、達成できるトランスミッションと処理における、平行関係の量を制限します。
The next section describes the host group model of multicast service. Section 5 describes the extensions to IP to support the host group model. Section 6 discusses the implementation of multicast within the networks and gateways making up the Internet. Section 7 relates this model to other proposals. Finally, we conclude with remarks on our experimental prototype implementation of host groups and comments on future directions for investigation.
次のセクションはマルチキャストサービスのホストグループモデルについて説明します。 セクション5は、ホストグループモデルをサポートするために拡大についてIPに説明します。 セクション6は、インターネットを作りながら、ネットワークとゲートウェイの中でマルチキャストの実装について論じます。 セクション7は他の提案にこのモデルに関連します。 最終的に、私たちは私たちのホストグループの実験的なプロトタイプ実装に関する所見と調査のための将来の方向のコメントで締めくくります。
4. The Host Group Model
4. ホストグループモデル
The Internet architecture defines a name space of individual host addresses. The host group model extends that name space to include addresses of host groups. A host group is a set of zero or more Internet hosts <1>. When an IP packet is sent with a host group address as its destination, it is delivered with "best effort" datagram reliability to all members of that host group.
インターネットアーキテクチャは個々のホスト・アドレスの名前スペースを定義します。 ホストグループモデルは、ホストグループのアドレスを含むようにその名前スペースを広げています。 ホストグループは1セットのゼロであるか、より多くのインターネット・ホストが<1>です。 ホストグループアドレスと共に目的地としてIPパケットを送るとき、「ベストエフォート型」のデータグラムの信頼性でそのホストグループのすべてのメンバーにそれを提供します。
The sender need not be a member of the destination group. We refer to such a group as open, in contrast to a closed group where only members are allowed to send to the group. We chose to provide open groups because they are more flexible and more consistent as an extension of conventional unicast models (even though they may harder to implement).
送付者は目的地グループのメンバーである必要はありません。 私たちはメンバーだけがグループに発信できる封鎖グループと対照して同じくらい開いているそのようなグループを参照します。 私たちは、それらが従来のユニキャストモデルの拡大として、よりフレキシブルであって、より一貫しているので(彼らは道具により一生懸命そうするかもしれませんが)開放グループを提供するのを選びました。
Dynamic management of group membership provides flexible binding of Internet addresses to hosts. Hosts may join and leave groups over time. A host may also belong to more than one group at a time. Finally, a host may belong to no groups at times, during which that host is unreachable within the Internet architecture. In fact, a
グループ会員資格のダイナミックな経営者側はインターネット・アドレスの柔軟製本をホストに提供します。 ホストは、時間がたつにつれて、グループに加わって、出るかもしれません。 また、ホストは一度に1つ以上のグループに属すかもしれません。 最終的に、ホストは時にどんなグループにも属さないかもしれません。(そのホストは時の間、インターネットアーキテクチャの中で手が届きません)。 事実上、a
Deering & Cheriton [Page 3]
デアリングとCheriton[3ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
host need not have an individual Internet address at all. Some hosts may only be associated with multi-host group addresses. For instance, there may be no reason to contact an individual time server in the Internet, so time servers would not require individual addresses.
ホストには、全く個々のインターネット・アドレスがある必要はありません。 マルチホストグループアドレスに関連するだけであるホストもいるかもしれません。 例えば、インターネットで個々の時間サーバに連絡する理由が全くないかもしれないので、時間サーバは個々のアドレスを必要としないでしょう。
Internet addresses are dynamically allocated for transient groups, groups that often last only as long as the execution of a single distributed program. In addition, a range of host group identifiers is reserved for identifying permanent groups. One use of permanent host groups identifiers is for host groups with standard logical meanings such as "name server group", "boot server group", "Internet monitor group", etc.
一時的なグループ(単にシングルの実行がプログラムを広げた限り、しばしば持続するグループ)のためにダイナミックにインターネット・アドレスを割り当てます。 さらに、さまざまなホストグループ識別子が、永久的なグループを特定するために予約されます。 永久的なホストグループ識別子の1つの使用が「ネームサーバグループ」、「ブート・サーバーグループ」、「インターネットモニターグループ」などの標準の論理的な意味があるホストグループのためのものです。
In the current Internet architecture, addresses are bound to single hosts. The host group model generalizes the binding of Internet addresses to hosts by allowing one address to bind to multiple hosts on multiple networks, more than one address to be bound (in part) to one host, and the binding of an address to host to be dynamic, i.e. possible to be modified under application control. Within this more general model, the current architecture is supported as a special case, retaining its current semantics and implementation.
現在のインターネットアーキテクチャでは、アドレスは必ずホストを選抜するでしょう。 アプリケーション制御装置の下で変更されるために1つのアドレスが複数のネットワーク、ダイナミックであって、すなわち、可能になるようにホスティングするアドレスの1人のホスト、および結合に制限されている(一部)1つ以上のアドレスの複数のホストに付くのを許容することによって、ホストグループモデルはインターネット・アドレスの製本をホストに一般化します。 このより一般的なモデルの中では、その現在の意味論と実装を保有して、現在のアーキテクチャは特殊なものとしてサポートされます。
The following subsections provide further details of the model.
以下の小区分はモデルの詳細を提供します。
4.1. Host Group Management
4.1. ホスト集団経営
Dynamic binding of Internet addresses to hosts is managed by the
following three operations which are made available to clients of
the Internet Protocol <2>:
ホストへのインターネット・アドレスのダイナミックな製本はインターネットプロトコル<2>のクライアントにとって利用可能にされる以下の3つの操作で管理されます:
CreateGroup ( type ) --> outcome, group-address, access-key
CreateGroup(タイプする)-->結果、グループアドレス、アクセスキー
requests the creation of a new transient host group with the
invoking host as its only member. The type argument specifies
whether the group is restricted or unrestricted. A restricted
group restricts membership based on the access-key. Only hosts
presenting a valid host access-key are allowed to join. All
unrestricted host groups have a null access-key. outcome
indicates whether the request is approved or denied. If it is
approved, a new transient group address is returned in
group-address. access-key is the protection key (or password)
associated with the new group. This should fail only if there are
no free transient group addresses.
呼び出しがある新しい一時的なホストグループの創設が唯一のメンバーとして主催する要求。 タイプ議論は、グループが制限されているか、または無制限であるかを指定します。 制限されたグループはアクセスキーに基づく会員資格を制限します。 有効なホストアクセスキーを提示するホストだけが接合できます。 すべての無制限なホストグループには、ヌルアクセスキーがあります。結果は、要求が承認されるか、または否定されるかを示します。 それが承認しているなら、グループアドレスで新しい一時的なグループアドレスを返します。アクセスキーは新しいグループに関連している保護キー(または、パスワード)です。 どんな無料の一時的なグループアドレスもない場合にだけ、これは失敗するべきです。
JoinGroup ( group-address, access-key ) --> outcome
JoinGroup(グループアドレス、アクセスキー)-->結果
Deering & Cheriton [Page 4]
デアリングとCheriton[4ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
requests that the invoking host become a member of the identified
host group (permanent or transient). outcome indicates whether
the request is approved or denied. A request is denied if the
access key is invalid.
呼び出しが主催する要求は特定されたホストグループ(永久的であるか一時的な)のメンバーになります。結果は、要求が承認されるか、または否定されるかを示します。 アクセスキーが無効であるなら、要求は否定されます。
LeaveGroup ( group-address ) --> outcome
LeaveGroup(グループアドレス)-->結果
requests that the invoking host be dropped from membership in the
identified group (permanent or transient). outcome indicates
whether the request is approved or denied.
呼び出しているホストが会員資格から要求が承認されるか、または否定されることにかかわらず. 結果が示す特定されたグループ(永久的であるか一時的な)で下げられるよう要求します。
There is no operation to destroy a transient host group because a
transient host group is deemed to no longer exist when its
membership goes to zero.
会員資格がゼロまで行くとき、一時的なホストグループがもう存在しないと考えられるので一時的なホストグループを破壊するために、操作は全くありません。
Permanent host group addresses are allocated and published by
Internet administrators, in the same way as well-known TCP and UDP
port numbers. That is, they are published in future editions of
the "Assigned Numbers" document [17].
永久的なホストグループアドレスは、インターネット管理者によって割り当てられて、発表されます、よく知られるTCPとUDPが数を移植するのと同様に。 すなわち、それらは将来版を重ねるにあたって「規定番号」というドキュメント[17]について発行されます。
4.2. Packet Transmission
4.2. パケット伝送
Transmission of a packet in the host group model is controlled by
two parameters of scope, one being the destination internetwork
address and the other being the "distance" to the destination
host(s). In particular,
ホストグループモデルにおける、パケットのトランスミッションはあて先ホストにとって「距離」である範囲、送付先インターネットワークアドレスである1つ、およびもう片方の2つのパラメタによって制御されます。 特に
Send ( dest-address, source-address, data, distance )
発信してください。(dest-アドレス、ソースアドレス、データ、距離)
transmits the specified data in an internetwork datagram to the
host(s) identified by dest-address that are within the specified
distance. The destination address is thus similar to conventional
networks except that delivery may be to multiple hosts; the
distance parameter requires further discussion.
インターネットワークデータグラムでdest-アドレスによって特定された指定された距離の中にいるホストに指定されたデータを送ります。 その結果、複数のホストには配送があるかもしれないのを除いて、送付先アドレスは従来のネットワークと同様です。 距離パラメタはさらなる議論を必要とします。
Distance may be measured in several ways, including number of
network hops, time to deliver and what might be called
administrative distance. Administrative distance refers to the
distance between the administrations of two different networks.
For example, in a company the networks of the research group and
advanced development group might be considered quite close to each
other, networks of the corporate management more distant, and
networks of other companies much more distant. One may wish to
restrict a query to members within one's own administrative domain
because servers outside that domain may not be trusted.
Similarly, error reporting outside of an administrative domain may
not be productive and may in fact be confusing.
距離はいくつかの方法で測定されるかもしれません、ネットワークホップの数、配送する時間、および管理距離と呼ばれるかもしれないものを含んでいて。 管理距離は2つの異なったネットワークの政権の間の距離について言及します。 例えば、会社では、研究のネットワークが分類されて、高度な開発グループは、全く互いに閉鎖、企業経営のネットワークであると、より遠方で考えられるかもしれなくて、多くの以上を他の会社に遠方でネットワークでつなぎます。 そのドメインの外のサーバが信じられないかもしれないので、質問を自分自身の管理ドメインの中のメンバーに制限したがっているかもしれません。 同様に、管理ドメインの外で報告する誤りは、生産的でないかもしれなく、事実上、混乱させられているかもしれません。
Deering & Cheriton [Page 5]
デアリングとCheriton[5ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Besides limiting the scope of transmission, the distance parameter
can be used to control the scope of multicast as a binding
mechanism and to implement an expanding scope of search for a
desired service. For instance, to locate a name server familiar
with a given name, one might check with nearby name servers and
expand the distance (by incrementing the distance on
retransmission) to include more distant name servers until the
name is found.
トランスミッションの範囲を制限すること以外に、結合機構としてマルチキャストの範囲を制御して、必要なサービスの検索の拡張範囲を実装するのに距離パラメタを使用できます。 例えば、名に身近なネームサーバの場所を見つけるなら、ものは、名前が見つけられるまで、より遠方のネームサーバを含むように近いネームサーバに問い合わせて、距離を広くするかもしれません(「再-トランスミッション」の距離を増加することによって)。
To reach all members of a group, a sender specifies the maximum
value for the distance parameter. This maximum must exceed the
"diameter" of the Internet.
グループのすべてのメンバーに届くように、送付者は距離パラメタに最大値を指定します。 この最大はインターネットの「直径」を超えなければなりません。
Packet reception is the same as conventional architectures. That
is,
パケットレセプションは従来のアーキテクチャと同じです。 That is,
Receive () --> dest-address, source-address, data
受信、()-->dest-アドレス、ソースアドレス、データ
returns the next internetwork datagram that is, or has been,
received.
次のインターネットワークデータグラムを返すか、またはあって、受信しました。
4.3. Delivery Requirements
4.3. 配送要件
We identify several requirements for the packet delivery mechanism
that are essential to host groups being a useful and used
facility.
私たちはパケット排紙機構のための役に立って中古の施設であるホストグループに不可欠のいくつかの要件を特定します。
Firstly, given the predominance of broadcast local-area networks
and the locality of communication to individual networks, the
delivery mechanism must be able to exploit the hardware's
capability for very efficient multicast within a single local-area
network.
まず第一に、放送ローカル・エリア・ネットワークの優位と個々のネットワークへのコミュニケーションの場所を考えて、排紙機構は非常に効率的なマルチキャストのためにただ一つのローカル・エリア・ネットワークの中でハードウェアの能力を開発できなければなりません。
Secondly, the delivery mechanism must scale in sophistication to
efficient delivery across the Internet as it acquires high-speed
wide-area communication links and higher performance gateways.
The former are being provided by the introduction of high-speed
satellite channels and long-haul fiber optic links. The latter
are made feasible by the falling cost of memory and processing
power plus the increasing importance in controlling access to
relatively unprotected local network environments. A host group
delivery mechanism must be able to take advantage of these trends
as they materialize.
第二に、高速広い領域通信リンクと、より高い性能ゲートウェイを入手するとき、排紙機構はインターネットの向こう側に効率的な配送に洗練を計量しなければなりません。 高速衛星チャンネルと長期光ファイバーリンクの導入で前者を提供しています。 メモリ、処理能力、および増加する重要性の降下している費用で比較的保護のない企業内情報通信網環境へのアクセスを制御する際に後者を可能にします。 具体化するとき、ホストグループ排紙機構はこれらの傾向を利用できなければなりません。
Finally, the delivery mechanism must avoid "systematic errors" in
delivery to members of the host group. That is, a small number of
repeated transmissions must result in delivery to all group
最終的に、排紙機構は配送における「系統誤差」をホストグループのメンバーとして避けなければなりません。 すなわち、少ない数の繰り返されたトランスミッションがすべてのグループへの配送をもたらさなければなりません。
Deering & Cheriton [Page 6]
デアリングとCheriton[6ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
members within the specified distance, unless a member is
disconnected or has failed. We refer to this property as
coverage. In general, most reliable protocols make this basic
assumption for unicast delivery. It is important to guarantee
this assumption for multicast as well or else applications using
multicast may fail in unexpected ways when coverage is not
provided. For efficiency, the multicast delivery mechanism should
also avoid regularly delivering multiple copies of a packet to
individual hosts.
指定された遠方の中のメンバーメンバーが切断されるか、または失敗していない場合。 私たちはこの特性を適用範囲と呼びます。 一般に、ほとんどの信頼できるプロトコルがユニキャスト配送のためのこの基本仮定をします。 適用範囲が提供されないとき、マルチキャストを使用すると予期していなかった道が失敗されるかもしれないのをまた、マルチキャストかアプリケーションのためのこの仮定に保証するのは重要です。 また、効率のために、マルチキャスト排紙機構は、定期的にパケットの複本を個々のホストに提供するのを避けるべきです。
Failure notification is not viewed as an essential requirement,
given the datagram semantics of delivery. However, a host group
extension to IP should provide "hint"-level failure notification
as the natural extension of the failure notification for unicast.
配送のデータグラム意味論を考えて、失敗通知は必須の条件として見なされません。 しかしながら、IPへのホスト群拡大はユニキャストのための失敗通知の自然な拡大として「ヒント」レベル失敗通知を提供するべきです。
5. Extensions to IP
5. IPへの拡大
This section discusses the specific extensions to the DARPA Internet Protocol required to support the host group model. The extensions need be implemented only on those hosts that wish to join host groups or send to host groups; existing implementations are not affected by the proposed changes.
このセクションはインターネットプロトコルがホストグループモデルをサポートするのを必要としたDARPAに特定の拡大について論じます。 拡大はホストグループに加わりたいか、またはホストグループに発信したがっているそれらのホストだけの上で実装されなければなりません。 既存の実装は変更案で影響を受けません。
5.1. Group Addresses
5.1. グループアドレス
A portion of the 32-bit IP address space is reserved for host
group addresses. The range of group addresses is chosen to be
easily recognized and to not conflict with existing individual
addresses. Either Class A addresses with a distinguished
(currently unused) network number or Class D addresses (those
starting with 111) would be suitable. The range of group addresses
is further subdivided into a set of permanent group addresses and
a set of temporary group addresses.
32ビットのIPアドレス空間の部分はホストグループアドレスのために予約されます。 グループアドレスの範囲は、既存の個々のアドレスを容易に認識されて、衝突しないように選ばれています。 Aが顕著な(現在未使用の)ネットワーク・ナンバーで扱うClassかDが扱うClass(111から始まるもの)のどちらかが適当でしょう。 グループアドレスの範囲はさらに1セットの永久的なグループアドレスと1セットの一時的なグループアドレスに分筆されます。
Host group addresses may be used in the same way as individual
addresses in the source, destination, and options fields of IP
datagrams. An IP implementation adds to the list of its own
individual addresses, the addresses of all groups to which it
belongs. The source addresses of locally originated datagrams are
validated against the list, and incoming datagrams which are not
destined to an address on the list are discarded. The addresses
on the list change dynamically as IP users create, join and leave
groups.
個々のアドレスと同様に、ホストグループアドレスはIPデータグラムのソース、目的地、およびオプション分野で使用されるかもしれません。IP実装はそれ自身の個々のアドレスのリストに加えます、それが属するすべてのグループのアドレス。 局所的に溯源されたデータグラムのソースアドレスはリストに対して有効にされます、そして、リストでアドレスに運命づけられていない受信データグラムは捨てられます。 IPユーザがグループに創設して、加わって、出るのに応じて、リストの上のアドレスはダイナミックに変化します。
Deering & Cheriton [Page 7]
デアリングとCheriton[7ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
5.2. Group Management
5.2. 集団経営
To support the group management operations of CreateGroup,
JoinGroup and LeaveGroup, an IP module must interact with one or
more multicast agents which reside in neighbouring gateways or
other special-purpose hosts. These interaction are handled by an
Internet Group Management Protocol (IGMP) which, like ICMP [15],
is an integral part of the IP implementation. A proposed
specification for IGMP is given in Appendix I.
グループがCreateGroup、JoinGroup、およびLeaveGroupの管理操作であるとサポートするために、IPモジュールは1人以上のマルチキャストエージェントと共にどれが隣接しているゲートウェイに住んでいるか、そして、他の専用ホストに相互作用させなければなりません。 ICMP[15]のようにIP実装の不可欠の部分であるインターネットGroup Managementプロトコル(IGMP)によってこれらの相互作用は扱われます。 Appendix IでIGMPのための提案された仕様を与えます。
5.3. Multicast Delivery
5.3. マルチキャスト配送
In order to transmit a datagram destined to a host group, an IP
module must map the destination group address into a local network
address. As with individual IP addresses, the mapping algorithm
is local-network- specific. On networks that directly support
multicast, the IP host group address is mapped to a local network
multicast address that includes all local members of the host
group plus one or more multicast agents. For networks that do not
directly support multicast, the mapping may be to a more general
broadcast address, to a list of local unicast addresses, or
perhaps to the address of a single machine that handles
multi-destination relaying.
ホストグループに運命づけられたデータグラムを送るために、IPモジュールは送付先グループアドレスを企業内情報通信網アドレスに写像しなければなりません。 個々のIPアドレスのように、マッピングアルゴリズムはローカルのネットワーク特有です。 直接マルチキャストをサポートするネットワークでは、IPホストグループアドレスはホストグループのすべての地元会員と1人以上のマルチキャストエージェントを含んでいる企業内情報通信網マルチキャストアドレスに写像されます。 直接マルチキャストをサポートしないネットワークにおいて、より一般的な放送演説、または、ローカルのユニキャストアドレスのリスト、または、恐らくマルチの目的地リレーを扱う単一マシンのアドレスにマッピングがあるかもしれません。
5.4. Distance Control
5.4. 距離コントロール
The existing Time to Live field in the IP header can be used for
crude control over the delivery radius of multicast datagrams. To
provide finer-grain control, a new IP option is defined to specify
the maximum delivery distance in "administrative units", such as
"this network", "this department", "this company", "this country",
etc. The set of units and their encoding is to be determined.
マルチキャストデータグラムの配送半径の粗雑なコントロールにIPヘッダーのLive分野への既存のTimeを使用できます。よりすばらしい粒コントロールを提供するなら、新しいIPオプションは「行政単位」で最大の配送距離を指定するために定義されます、「このネットワーク」、「この部」、「同社」、「この国」などのように ユニットとそれらのコード化のセットは断固とすることになっています。
6. Implementation
6. 実装
In this section, we sketch a design for implementing the host group model within the Internet. This description of the design is given to further support the feasibility of the host group model as well as point out some of the problems yet to be addressed.
このセクションで、私たちは、インターネットの中でホストグループモデルを実装するためにデザインについてスケッチします。 さらにホストグループモデルに関する実現の可能性をサポートしていなくて、また扱われるためにまだ問題のいくつかを指摘していないようにデザインのこの記述を与えます。
Implementation of host groups involves implementing a binding mechanism (binding Internet addresses to zero or more hosts) and a packet delivery mechanism (delivering a packet to each host to which its destination address binds). This facility fits most naturally into the gateways of the Internet and the switching nodes of the constituent point-to-point networks (as opposed to separate machines) because multicast binding and delivery is a natural extension of the
ホストグループの実装は、結合機構が(ゼロか、より多くのホストへの拘束力があるインターネット・アドレス)とパケット排紙機構であると実装することを伴います(送付先アドレスが付く各ホストにパケットを提供して)。 この施設は最も自然にインターネットのゲートウェイとマルチキャスト結合と配送がa自然な拡大であるのでポイントツーポイントがネットワークでつなぐ(別々のマシンと対照的に)成分の切り換えノードに合います。
Deering & Cheriton [Page 8]
デアリングとCheriton[8ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
unicast binding and delivery (i.e. routing plus store-and-forward). That is, a multicast packet is routed and transmitted to multiple destinations, rather than to a single destination.
ユニキャスト結合と配送(すなわち、ルーティング、店、およびフォワード)。 すなわち、マルチキャストパケットは、単一の目的地にというよりむしろ複数の目的地に発送されて、送られます。
In the following description, we start with a basic, simple implementation that provides coverage and then refine this mechanism with various optimizations to improve efficiency of delivery and group management.
以下の記述では、私たちは、適用範囲を提供する基本的で、簡単な実装から始まって、次に、配送と集団経営の効率を高めるために様々な最適化でこのメカニズムを洗練します。
6.1. Basic Implementation
6.1. 基本的な実装
A host group defines a network group, which is the set of networks
containing current members of the host group. When a packet is
sent to a host group, a copy is delivered to each network in the
corresponding network group. Then, within each network, a copy is
delivered to each host belonging to the group.
ホストグループはネットワークグループを定義します。(それは、ホストグループの現在のメンバーを含むネットワークのセットです)。 ホストグループにパケットを送るとき、対応するネットワークグループで各ネットワークにコピーを提供します。 そして、各ネットワークの中では、コピーはグループに属す各ホストに提供されます。
To support such multicast delivery, every Internet gateway
maintains the following data structures:
そのようなマルチキャスト配送をサポートするために、あらゆるインターネット・ゲートウェイが以下のデータ構造を維持します:
- routing table: conventional Internet routing information,
including the distance and direction to the nearest gateway
on every network.
- 経路指定テーブル: あらゆるネットワークで最も近いゲートウェイへの距離と方向を含む従来のインターネット・ルーティング情報。
- network membership table: A set of records, one for every
currently existing host group. The network membership record
for a group lists the network group, i.e. the networks that
contain members of the group.
- 会員資格テーブルをネットワークでつないでください: 1セットの記録、各現在既存のホストグループあたり1つ。 グループのためのネットワーク会員資格記録はネットワークグループ、すなわち、グループのメンバーを含むネットワークを記載します。
- local host membership table: A set of records, one for each
host group that has members on directly attached networks.
Each local host membership record indicates the local hosts
that are members of the associated host group. For networks
that support multicast or broadcast, the record may contain
only the local network-specific multicast address used by the
group plus a count of local members. Otherwise, local group
members may be identified by a list of unicast addresses to
be used in the software implementation of multicast within
the network.
- ローカル・ホスト会員資格テーブル: 1セットの記録であり、オンにメンバーがいるそれぞれのホストグループあたり1つは直接ネットワークを付けました。 それぞれのローカル・ホスト会員資格記録は関連ホストグループのメンバーであるローカル・ホストを示します。 マルチキャストをサポートするか、または放送されるネットワークのために、記録は地元会員のグループとカウントで使用されるローカルのネットワーク特有のマルチキャストアドレスだけを含むかもしれません。 さもなければ、地域団体のメンバーはユニキャストアドレスのリストによって特定されて、ネットワークの中でマルチキャストのソフトウェア実行に使用されるかもしれません。
A host invokes the multicast delivery service by sending a
group-destined IP datagram to an immediate neighbour gateway (i.e.
a gateway that is directly attached to the same network as the
sending host). Upon receiving a group-destined datagram from a
directly attached network, a gateway looks up the network
membership record corresponding to the destination address of the
datagram. For each of the networks listed in the membership
ホストは、即座の隣人ゲートウェイ(すなわち、直接送付ホストと同じネットワークに取り付けられるゲートウェイ)にグループによって運命づけられたIPデータグラムを送ることによって、マルチキャストデリバリ・サービスを呼び出します。 直接付属しているネットワークからグループによって運命づけられたデータグラムを受けると、ゲートウェイはデータグラムの送付先アドレスに対応するネットワーク会員資格記録を調べます。 会員資格で記載されたそれぞれのネットワークのために
Deering & Cheriton [Page 9]
デアリングとCheriton[9ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
record, the gateway consults its routing table. If, according to
the routing table, a member network is directly attached, the
gateway transmits a copy of the datagram on that network, using
the network-specific multicast address allocated for the group on
that network. For a member network that is not directly attached
the gateway creates a copy of the datagram with an additional
inter-gateway header identifying the destination network. This
inter-gateway datagram is forwarded to the nearest gateway on the
destination network, using conventional store-and-forward routing
techniques. At the gateway on the destination network, the
datagram is stripped of its inter-gateway header and transmitted
to the group's multicast address on that network. The datagram is
dropped by the relaying gateways whenever it exceeds its distance
limit.
記録してください、そして、ゲートウェイは経路指定テーブルに相談します。 経路指定テーブルに従ってメンバーネットワークが直接付けられるなら、ゲートウェイはそのネットワークでデータグラムのコピーを伝えます、そのネットワークに関するグループのために割り当てられたネットワーク特有のマルチキャストアドレスを使用して。 直接付けられていないメンバーネットワークのために、ゲートウェイは追加相互ゲートウェイヘッダーが送信先ネットワークを特定しているデータグラムのコピーを作成します。 従来の店とフォワードルーティングのテクニックを使用して、この相互ゲートウェイデータグラムを送信先ネットワークで最も近いゲートウェイに送ります。 送信先ネットワークのゲートウェイでは、データグラムは、相互ゲートウェイヘッダーが奪い取られて、そのネットワークに関するグループのマルチキャストアドレスに送られます。 距離限界を超えているときはいつも、データグラムはリレーゲートウェイによって下げられます。
The network membership records and the network-specific multicast
structures are updated in response to group management requests
from hosts. A host sends a request to create, join, or leave a
group to an immediate neighbour gateway. If the host requests
creation of a group, a new network membership record is created by
the serving gateway and distributed to all other gateways. If the
host is the first on its network to join a group, or if the host
is the last on its network to leave a group, the group's network
membership record is updated in all gateways. The updates need
not be performed atomically at all gateways, due to the datagram
delivery semantics; hosts can tolerate misrouted and lost packets
caused by temporary gateway inconsistencies, as long as the
inconsistencies are resolved within normal host retransmission
periods. In this respect, the network membership data is similar
to the network reachability data maintained by conventional
routing algorithms, and can be handled by similar mechanisms.
ホストからの集団経営要求に対応してネットワーク会員資格記録とネットワーク特有のマルチキャスト構造をアップデートします。 ホストは即座の隣人ゲートウェイにグループを創設するか、加わるか、または出るという要求を送ります。 ホストがグループの創設を要求するなら、新しいネットワーク会員資格記録は、給仕ゲートウェイによって作成されて、他のすべてのゲートウェイに分配されます。 ホストが仲間に入るネットワークの1番目である、またはホストがグループを出るネットワークの最終であるなら、すべてのゲートウェイでグループのネットワーク会員資格記録をアップデートします。 アップデートはデータグラム配信意味論のためすべてのゲートウェイで原子論的に実行される必要はありません。 ホストは一時的なゲートウェイ矛盾で引き起こされたmisroutedされて無くなっているパケットを許容できます、矛盾が正常なホスト「再-トランスミッション」の期間以内に決議されている限り。 この点で、ネットワーク会員資格データは、従来のルーティング・アルゴリズムによって保守されたネットワーク可到達性データと同様であり、同様のメカニズムで扱うことができます。
In many cases, a host joins a group that already has members on
the same network, or leaves a group that has remaining members on
the same network. This is then a local matter between the hosts
and gateways on a single network: only the local host membership
table needs to be updated to include or exclude the host.
多くの場合、ホストはメンバーが同じネットワークに既にいるか、または同じネットワークで残っているメンバーがいるグループを出るグループに加わります。 次に、これはただ一つのネットワークのホストとゲートウェイの間の地域にかかわる事柄です: ローカル・ホスト会員資格テーブルだけが、ホストを含んでいるか、または除くためにアップデートする必要があります。
This basic implementation strategy meets the delivery requirements
stated at the end of Section 4. However, it is far from optimal,
in terms of either delivery efficiency or group management
overhead. Below, we discuss some further refinements to the basic
implementation.
この基本的な実装戦略はセクション4の終わりに述べられた配送必要条件を満たします。 しかしながら、それは配送効率か集団経営オーバーヘッドのどちらかで全く最適ではありません。 以下では、私たちがさらなるいくつかの気品について基本的な実装と議論します。
Deering & Cheriton [Page 10]
デアリングとCheriton[10ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
6.2. Multicast Routing Between Networks
6.2. ネットワークの間のマルチキャストルート設定
Multicast routing among the Internet gateways is similar to
store-and-forward routing in a point-to-point network. The main
difference is that the links between the nodes (gateways) can be a
mixture of broadcast and unicast-type networks with widely
different throughput and delay characteristics. In addition,
packets are addressed to networks rather than hosts (at the
gateway level).
インターネット・ゲートウェイの中のマルチキャストルーティングは、二地点間ネットワークでルーティングを保存して、進めるために同様です。 主な違いはノード(ゲートウェイ)の間のリンクがはなはだしく異なったスループットと遅れの特性がある放送とユニキャストタイプネットワークの混合物であるかもしれないということです。 さらに、パケットはホスト(ゲートウェイレベルにおける)よりむしろネットワークに扱われます。
We intend to use the extended reverse path forwarding algorithm of
Dalal and Metcalfe [10]. Although originally designed for
broadcast, it is a simple and efficient technique that can serve
well for multicast delivery if network membership records in each
gateway are augmented with information from neighbouring gateways.
This algorithm uses the source network identifier, rather than a
destination network identifier to make routing decisions. Since
the source address of a datagram may be a group address, it cannot
be used to identify the source network of the datagram; the first
gateway must add a header specifying the source network. This
approach minimizes redundant transmissions when multiple
destination networks are reachable across a common intergateway
link, a problem with the basic implementation described above.
私たちはDalalとメトカルフェ[10]の拡張逆の経路推進アルゴリズムを使用するつもりです。 元々放送のために設計されますが、それは各ゲートウェイでのネットワーク会員資格記録が隣接しているゲートウェイからの情報で増大するなら上手にマルチキャスト配送を満たすことができる簡単で効率的なテクニックです。 このアルゴリズムは、ルーティングを決定にするのに送信先ネットワーク識別子よりむしろソースネットワーク識別子を使用します。 データグラムのソースアドレスがグループアドレスであるかもしれないので、データグラムのソースネットワークを特定するのにそれを使用できません。 最初のゲートウェイはソースネットワークを指定するヘッダーを加えなければなりません。 複数の送信先ネットワークが一般的なintergatewayリンクの向こう側に届いているとき、このアプローチは余分なトランスミッションを最小にします、と基本的な実装に関する問題は上で説明しました。
Note that we eliminate from consideration techniques that fail to
deliver along the branches of the shortest delay tree rooted at
the source, such as Wall's center-based forwarding [16] because
this compromises the meaning of the multicast distance parameter
and detracts from multicast performance in general. We also
rejected the approach of having a multicast packet carry more than
one network identifier in its inter-gateway header to indicate
multiple destination networks because the resulting variable
length headers would cause buffering and fragmentation problems in
the gateways.
私たちが[16]これでマルチキャスト距離パラメタの意味に感染して、一般に、マルチキャスト性能が損なわれるのでソースに根づいている最も低い遅れ木のWallのセンターベースの推進などの枝に沿って配送しない考慮のテクニックから排泄することに注意してください。 また、私たちはマルチキャストパケットに結果として起こる可変長ヘッダーがゲートウェイでバッファリングと断片化に問題を引き起こすでしょう、したがって、複数の送信先ネットワークを示すために相互ゲートウェイヘッダーで1つ以上のネットワーク識別子を運ばせるアプローチを拒絶しました。
6.3. Multicasting Within Networks
6.3. ネットワークの中のマルチキャスティング
A simple optimization within a network is to have the sender use
the local multicast address of a host group for its initial
transmission. This allows the local host group members to receive
the transmission immediately along with the gateways (which must
now "eavesdrop" on all multicast transmissions). A gateway only
forwards the datagram if the destination host group includes
members on other networks. This scheme reduces the cost to reach
local group members to one packet transmission from two required
ネットワークの中の簡単な最適化は送付者に初期のトランスミッションにホストグループのローカルのマルチキャストアドレスを使用させることです。 これで、ローカル・ホストのグループのメンバーはすぐゲートウェイ(現在、すべてのマルチキャスト送信を「盗み聞かなければならない」)に伴うトランスミッションを受け取ることができます。 あて先ホストグループが他のネットワークのメンバーを含んでいる場合にだけ、ゲートウェイはデータグラムを進めます。 この体系は、2からの1つのパケット伝送へのメンバーが必要とした地域団体に達するように生産費を切り下げます。
Deering & Cheriton [Page 11]
デアリングとCheriton[11ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
in the basic implementation <3> so transmission to local members
is basically as efficient as the local multicast support provided
by the network.
基本的な実装に、地元会員へのトランスミッションが地方のマルチキャストサポートと基本的同じくらい効率的であることで、<3>はネットワークによって提供されました。
A similar opportunity for reducing packet traffic arises when a
datagram must traverse a network to get from one gateway to
another, and that network also holds members of the destination
group. Again, use of a network-specific multicast address which
includes member hosts plus gateways can achieve the desired
effect. However, in this case, hosts must be prepared to accept
datagrams that include an inter-gateway header or, alternatively,
every datagram must include a spare field in its header for use by
gateways in lieu of an additional inter-gateway header.
データグラムが別のものへの1門から得るネットワークを横断しなければならないとき、パケットトラフィックを減少させる同様の機会は起こります、そして、また、そのネットワークは目的地グループのメンバーを保持します。 一方、メンバーホストとゲートウェイを含んでいるネットワーク特有のマルチキャストアドレスの使用は期待される効果を発揮できます。 しかしながら、この場合、ホストが相互ゲートウェイヘッダーを含んでいるデータグラムを受け入れる用意ができていなければなりませんか、またはあるいはまた、あらゆるデータグラムが追加相互ゲートウェイヘッダーの代わりにゲートウェイのそばに使用のためのヘッダーの予備分野を含まなければなりません。
6.4. Distributing Membership Information
6.4. 会員資格情報を分配します。
A refinement to host group membership maintenance is to store the
host group membership record for a group only in those gateways
that are directly connected to member networks. Information about
other groups is cached in the gateway only while it is required to
route to those other groups. When a gateway receives a datagram
to be forwarded to a group for which it has no network membership
record (which can only happen if the gateway is not directly
connected to a member network), it takes the following action.
The gateway assumes temporarily that the destination group has
members on every network in the internetwork, except those
directly attached to the sending gateway, and routes the datagram
accordingly. In the inter-gateway header of the outgoing packet,
the gateway sets a bit indicating that it wishes to receive a copy
of the network membership record for the destination host group.
When such a datagram reaches a gateway on a member network, that
gateway sends a copy of the membership record back to the
requesting gateway and clears the copy request bit in the
datagram.
ホストグループ会員資格メインテナンスへの気品は直接メンバーネットワークに接続されるそれらのゲートウェイだけのグループのためのホストグループ会員資格記録を保存することです。 それが他のそれらにグループを発送するのに単に必要ですが、他のグループに関する情報はゲートウェイでキャッシュされます。 ゲートウェイがそれがネットワーク会員資格記録(ゲートウェイが直接メンバーネットワークに接続されない場合にだけ、起こることができる)を全く持っていないグループに送られるデータグラムを受けるとき、それは以下の行動を取ります。 ゲートウェイは、目的地グループが直接送付ゲートウェイに付けられたものを除いて、インターネットワークにはメンバーがあらゆるネットワークにいて、それに従って、データグラムを発送すると一時仮定します。 出発しているパケットの相互ゲートウェイヘッダーでは、あて先ホストグループのためのネットワーク会員資格記録のコピーを受け取りたがっているのを少し示しながら、ゲートウェイはセットします。 そのようなデータグラムがメンバーネットワークのゲートウェイに達すると、そのゲートウェイは、会員資格記録のコピーを要求ゲートウェイに送り返して、データグラムでコピー要求ビットをきれいにします。
Copies of network membership records sent to gateways outside of a
group's member networks are cached for use in subsequent
transmissions by those gateways. That raises the danger of a
stale cache entry leading to systematic delivery failures. To
counter that problem, the inter-gateway header contains a field
which is a hash value or checksum on the network membership record
used to route the datagram. Gateways on member networks compare
the checksum on incoming datagrams with their up-to-date records.
If the checksums don't match, an up-to-date copy of the record is
returned to the gateway with the bad record.
グループのメンバーネットワークの外でゲートウェイに送られたネットワーク会員資格記録のコピーはその後のトランスミッションにおける使用のためにそれらのゲートウェイによってキャッシュされます。 それは系統的な配信障害に通じる聞き古したキャッシュエントリーの危険を上げます。 その問題を打ち返すために、相互ゲートウェイヘッダーはデータグラムを発送するのに使用されるネットワーク会員資格記録にハッシュ値かチェックサムである分野を含んでいます。 メンバーネットワークのゲートウェイはそれらの最新の記録と受信データグラムの上のチェックサムを比べます。 チェックサムが合っていないなら、記録の最新のコピーを悪い記録があるゲートウェイに返します。
This caching strategy minimizes intergateway traffic for groups
このキャッシュ戦略はグループのためにintergatewayトラフィックを最小にします。
Deering & Cheriton [Page 12]
デアリングとCheriton[12ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
that are only used within one network or within the set of
networks on which members reside, the expected common cases.
Partial replication with caching also reduces the overhead for
network traffic to disseminate updates and keep all copies
consistent. Finally, it also reduces the total space required in
all the gateways to support a large number of host groups.
それは1つのネットワーク以内かメンバーが住んでいるネットワークのセットの中で使用されるだけです、予想されたよくある例。 また、ネットワークトラフィックがアップデートを広めて、すべての写しを一貫していることへ取っておくように、キャッシュによる部分的な模写はオーバーヘッドを下げます。 また、最終的に、それは多くのホストグループをサポートするのにすべてのゲートウェイで必要である総スペースを減少させます。
We have not addressed here the problem of maintaining up-to-date,
consistent network membership records within the set of gateways
connected to members of a group. This can be viewed as a
distributed database problem which has been well studied in other
contexts. The loose consistency requirements on network
membership records suggest that the techniques used in Grapevine
[3] might be useful for this application.
私たちはここでグループのメンバーに接続されたゲートウェイのセットの中で最新の、そして、一貫したネットワーク会員資格記録を保守するというその問題を訴えていません。 他の文脈でよく研究された分散データベース問題としてこれを見なすことができます。 ネットワーク会員資格記録に関するゆるい一貫性要件は、Grapevine[3]で使用されるテクニックがこのアプリケーションの役に立つかもしれないと示唆します。
7. Related Work
7. 関連仕事
The use of unreliable multicast by higher-level protocols and the implementation of multicast within various individual networks have been well-studied (see [7] for references and discussion). However, there is relatively little published work on the use or implementation of internetwork multicasting.
上位レベル・プロトコルによる頼り無いマルチキャストの使用と様々な個々のネットワークの中のマルチキャストの実装はよく研究されています(参照と議論のための[7]を見てください)。 しかしながら、インターネットワークマルチキャスティングの使用か実装に対する仕事は比較的少ししか発行されません。
Boggs, in his thesis [4], describes a number of distributed applications that are impossible or very awkward to support without the flexible binding nature of broadcast addressing. Although he recognizes that almost all of his applications would be best served by a multicast mechanism, he advocates the use of "directed broadcast" because it is easy to implement within many kinds of networks and can be extended across an internetwork without placing any new burden on internetwork gateways. In RFC-919 [13], Mogul proposes adopting directed broadcast for the DARPA Internet.
彼の論文[4]では、ボッグズは多くのブロードキャスト・アドレッシングの柔軟製本本質なしでサポートするために不可能であるか、または非常に厄介な分配されたアプリケーションについて説明します。 マルチキャストメカニズムで彼のアプリケーションのほとんどすべてに役立つと最も良い認めますが、どんな新しい負担もインターネットワークゲートウェイにかけないで、彼は、多くの種類のネットワークの中で実装するのが簡単であるので「指示された放送」の使用を支持して、インターネットワークの向こう側に広げることができます。 RFC-919[13]では、ムガール人は、DARPAインターネットのための指示された放送を採用するよう提案します。
Broadcasting has the undesirable side effect of delivering packets to more hosts than necessary, thus incurring overhead on uninvolved parties and possibly creating security problems. As more and more applications take advantage of broadcasting, the overhead on all hosts continues to rise. Clearly, broadcast does not scale up to a large internetwork. As an attempt to handle the scaling problem, directed broadcast is less attractive than true multicast because the set of hosts that can be reached by a single "send" operation is an artifact of the internetwork topology, rather than a grouping that is meaningful to the sender.
放送は配送パケットの望ましくない副作用を必要とするより多くのホストに持っています、その結果、無関心なパーティーでオーバーヘッドを被って、ことによると警備上の問題を作成して。ますます多くのアプリケーションが放送を利用するとき、すべてのホストの上のオーバーヘッドは、上昇し続けています。 明確に、放送は大きいインターネットワークまで比例しません。 スケーリング問題を扱う試みとして、「発信してください」というただ一つの操作で連絡できるホストのセットが送付者にとって、重要な組分けよりむしろインターネットワークトポロジーの人工物であるので、指示された放送は本当のマルチキャストほど魅力的ではありません。
In RFC-947 [12], Lebowitz and Mankins propose the use of broadcast
RFC-947[12]では、レボウィッツとマンキンズは放送の使用を提案します。
Deering & Cheriton [Page 13]
デアリングとCheriton[13ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
repeaters that pick up broadcast datagrams from one network and relay them to other networks for broadcast there. This technique is even less selective of its targets than Bogg's directed broadcast method.
回復するリピータは、1つのネットワークからデータグラムを放送して、放送のためにそこで他のネットワークにそれらをリレーします。 このテクニックはBoggの指示された放送メソッドほど目標で選択してさえいません。
Aguilar [1] suggests allowing an IP datagram to carry multiple destination addresses, which are used by the gateways to route the datagram to each recipient. Such a facility would alleviate some of the inefficiencies of sending individual datagrams to a group, but it would not be able to take advantage of local network multicast facilities. More seriously, Aguilar's scheme requires the sender to know the individual IP addresses of all members of the destination group and thus lacks the flexible binding nature of true multicast or broadcast.
アギラル[1]は、IPデータグラムがゲートウェイによって使用される、各受取人にデータグラムを発送する複数の送付先アドレスを運ぶのを許容するのを示します。 そのような施設は送付の個々のデータグラムのいくつかの非能率をグループに軽減するでしょうが、それは企業内情報通信網マルチキャスト施設を利用できないでしょう。 より真剣に、アギラルの体系は、その結果、送付者が目的地グループのすべてのメンバーの個々のIPアドレスを知って、本当のマルチキャストの柔軟製本本質を欠くか、または放送するのを必要とします。
8. Concluding Remarks
8. 結びの言葉
We have described a model of multicast communication for the Internet. As an extension of the existing Internet architecture, it views unicast communication and time-to-live constraints as special cases of the more general form of communication arising with multicast. We have argued that this model is implementable in the Internet and that it provides a powerful facility for a variety of applications. In some cases, it provides a facility that is required for certain applications to work in the Internet environment. In other cases, it provides a more efficient, robust and possibly more elegant way of implementing existing Internet applications.
私たちはインターネットのためのマルチキャストコミュニケーションのモデルについて説明しました。 既存のインターネットアーキテクチャの拡大として、それは、より一般的なフォームに関するコミュニケーションがマルチキャストで起こる特別なケースとしてユニキャストコミュニケーションと生きる時間規制を見なします。 私たちは、このモデルがインターネットで実装可能で、それが強力な施設をさまざまなアプリケーションに提供すると主張しました。 いくつかの場合、それはあるアプリケーションがインターネット環境で動作するのに必要である施設を提供します。 他の場合では、それは既存のインターネットがアプリケーションであると実装するより効率的で、強健でことによるとより上品な方法を提供します。
We are currently implementing a prototype host group facility as an extension of IP. For practical reasons, this prototype implements all group management functions and multicast routing outside of the Internet gateways, in special hosts called multicast agents, which are similar to the broadcast repeaters of Lebowitz and Mankins. The collection of multicast agents in effect provides a second gateway system on top of the existing Internet, for multicast purposes. The major costs of this separation are redundancy of routing tables between gateways and multicast agents and the increased delay and unreliability of extra hops in the delivery path. Much of the routing information in the multicast agents must be "wired-in" because they do not have access to the gateways' routing tables. However, this rudimentary implementation provides an environment for evaluating the interface to the multicast service and for investigating group management and multicast routing protocols for eventual use in the gateways. It also serves as a testbed for porting multicast-based distributed applications to the Internet.
私たちは現在、IPの拡大としてプロトタイプホストグループ施設を実装しています。 実際的な理由で、このプロトタイプは、インターネット・ゲートウェイの外ですべての集団経営が機能とマルチキャストルーティングであると実装します、レボウィッツとマンキンズの放送リピータと同様のマルチキャストエージェントと呼ばれる特別なホストで。 事実上、マルチキャストエージェントの収集は存在の上の2番目のゲートウェイシステムにインターネットを供給します、マルチキャスト目的のために。 この分離の主要なコストは、配送経路で、付加的なホップのゲートウェイとマルチキャストエージェントの間の経路指定テーブルの冗長と、増強された遅れと非信頼性です。 彼らがゲートウェイの経路指定テーブルに近づく手段を持っていないので、マルチキャストエージェントのルーティング情報の多くが「接合されなければなりません」。 しかしながら、この初歩的な実装はマルチキャストサービスにインタフェースを評価して、ゲートウェイでの最後の使用のために集団経営とマルチキャストルーティング・プロトコルを調査するのに環境を提供します。 また、それはマルチキャストベースの分配されたアプリケーションをインターネットに移植するためのテストベッドとして機能します。
For now, we are restricting group membership to local networks that already have a broadcast or multicast capability, such as the
当分、私たちはグループ会員資格を既に放送かマルチキャスト能力を持っている企業内情報通信網に制限しています、あれほどです。
Deering & Cheriton [Page 14]
デアリングとCheriton[14ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Ethernet. We feel that, in the future, any network that is to support hosts other than just gateways must have a multicast addressing mode. Efficient implementation of multicast within point-to-point or virtual circuit networks deserves investigation.
イーサネット。 私たちは、まさしくゲートウェイ以外のホストをサポートすることになっているどんなネットワークも未来にマルチキャストアドレッシング・モードを持たなければならないと感じます。 二地点間の、または、仮想の回路ネットワークの中のマルチキャストの効率的な実装は調査に値します。
A significant issue raised by the host group model is authentication and access control in the Internet. Gateways must control which hosts can create and join host groups, presumably making their decision based on the identity of the requestor (thus requiring authentication) and permissions (access control lists). This issue does not arise in conventional internetwork architectures because host addresses are administratively assigned with no notion of dynamic assignment and binding as provided by host groups. We believe that access control should be recognized as a proper and necessary function of gateways so as to protect the hosts of local networks from general internetwork activity. Thus, group access control can be subsumed as part of this more general mechanism, although more investigation of the general issue is called for.
ホストグループモデルによって提起された重要な問題は、インターネットでの認証とアクセスコントロールです。 ゲートウェイは、どのホストがホストグループを創設して、加わることができるかを制御しなければなりません、おそらく要請者(その結果、認証を必要とする)のアイデンティティに基づく彼らの決定と許容を(アクセスコントロールリスト)にして。 ホスト・アドレスはホストグループによって提供されるようにダイナミックな課題の概念なしで行政上割り当てられて拘束力があるので、この問題は従来のインターネットワークアーキテクチャで起こりません。 私たちは、アクセスコントロールが一般的なインターネットワーク活動から企業内情報通信網のホストを保護するためにゲートウェイの適切で必要な機能として認識されるべきであると信じています。 したがって、このより一般的なメカニズムの一部としてグループアクセスコントロールを包括できます、一般答弁の、より多くの調査が求められますが。
On a philosophical point, there has been considerable reluctance to make open use of multicast on local networks because it was network-specific and not provided across the Internet. We were originally of that school. However, we recognized that our "hidden" uses of multicast in the V distributed system were essential unless we resorted to dramatically poorer solutions - wired-in addresses. We also recognized, as described in this paper, that an adequate multicast facility for the Internet was feasible. As a consequence, we now argue that multicast is an important and basic facility to provide in local networks and internetworks. Higher levels of communication, including applications, should feel free to make use of this powerful facility. Networks and internetworks lacking multicast should be regarded as deficient relative to the future (and present) requirements of sophisticated distributed applications and communication systems.
哲学的なポイントの上に、ネットワーク特有であり、インターネットの向こう側に提供しなかったので企業内情報通信網におけるマルチキャストの開いている使用をするというかなりの不本意がありました。 私たちは元々その学校のものでした。 しかしながら、私たちは、V分散システムにおける、私たちのマルチキャストの「隠された」用途が私たちは、より貧しいソリューションに劇的に訴えました--接合しているアドレスでないなら不可欠であると認めました。 また、私たちは、この紙で説明されるようにインターネットへの適切なマルチキャスト施設が可能であると認めました。 結果として、私たちは、現在、マルチキャストが企業内情報通信網に提供する重要で基本的な施設とインターネットワークであると主張します。 アプリケーションを含むより高いレベルに関するコミュニケーションは遠慮なくこの強力な施設を利用するべきです。 マルチキャストを欠いているネットワークとインターネットワークは精巧な分配されたアプリケーションと通信系の将来的で(現在)の要件に比例して不十分であると見なされるべきです。
Deering & Cheriton [Page 15]
デアリングとCheriton[15ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Appendix I. Internet Group Management Protocol (IGMP)
付録I.インターネットグループ管理プロトコル(IGMP)
The Internet Group Management Protocol (IGMP) is used between IP hosts and their immediate neighbour multicast agents to support the allocation of temporary group addresses and the addition and deletion of members of a group.
インターネットGroup Managementプロトコル(IGMP)は、グループのメンバーの一時的なグループアドレスの配分、追加、および削除をサポートするのにIPホストと彼らの即座の隣人マルチキャストエージェントの間で使用されます。
Like ICMP, IGMP is a required part of all IP implementations. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. IGMP messages are formatted similarly to ICMP messages and the different IGMP message types are given values distinct from ICMP message types, so that both protocols may share common implementation modules or, perhaps, be merged into a single protocol.
ICMPのように、IGMPはすべてのIP実装の必要な部分です。 IGMPメッセージはIPデータグラムで2のIPプロトコル番号でカプセル化されます。 同様にICMPメッセージにIGMPメッセージをフォーマットします、そして、ICMPメッセージタイプと異なった値を異なったIGMPメッセージタイプに与えます、両方のプロトコルは一般的な実装モジュールを共有するか、または恐らくただ一つのプロトコルに合併できるように。
IGMP interactions take the form of request-response transactions. A request message is sent by hosts to the permanent group of all immediate neighbour multicast agents. Multicast agents reply to the IP source address of a request. If no reply is received within a (currently unspecified) timeout interval, a host retransmits its request, up to some (currently unspecified) maximum number of times. IGMP transactions are considered idempotent, so that multicast agents need not recognize and filter out duplicate requests nor buffer replies <4>.
IGMP相互作用は要求応答トランザクションの形を取ります。 要求メッセージはホストによってすべての即座の隣人マルチキャストエージェントの永久的なグループに送られます。 マルチキャストエージェントは要求のIPソースアドレスに答えます。 (現在、不特定)のタイムアウト間隔以内に回答を全く受け取らないなら、ホストは要求を再送します、何らかの(現在、不特定)の最大の回数まで。 IGMPトランザクションは考えられたベキ等元です、マルチキャストエージェントが写し要求を認めて、無視する必要はないようにバッファ回答は<4>です。
The IGMP message formats and procedures are defined below, in the style used in the ICMP specification.
IGMPメッセージ・フォーマットと手順は以下でICMP仕様で使用されるスタイルで定義されます。
Deering & Cheriton [Page 16]
デアリングとCheriton[16ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Create Group Request or Create Group Reply Message
グループ要求を作成するか、またはグループ応答メッセージを作成してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + アクセスキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP分野:
Addresses
アドレス
A Create Group Request message is sent with an individual IP
address of the sending host as its source, and the well-known
group address of the multicast agents as its destination.
ソースとしての送付ホストの個々のIPアドレス、およびマルチキャストエージェントのよく知られるグループアドレスと共に目的地としてCreate Group Requestメッセージを送ります。
The corresponding Create Group Reply is sent with those two
addresses reversed.
それらの2つのアドレスが逆にされている状態で、対応するCreate Group Replyを送ります。
IGMP Fields:
IGMP分野:
Type
タイプ
101 for Create Group Request
102 for Create Group Reply
101、グループ要求102を作成する、グループ回答を作成してください。
Code
コード
For a Create Group Request message, the Code field indicates if
the group is to be restricted:
Create Group Requestメッセージに関しては、Code分野は、グループが制限されるつもりであるかどうかを示します:
0 = unrestricted
1 = restricted
=が制限した無制限な0=1
For a Create Group Reply message, the Code field specifies the
outcome of the request:
Create Group Replyメッセージとして、Code分野は要求の結果を指定します:
0 = request approved
1 = request denied, no resources
1つの承認された=要求が否定した0=要求、リソースがありません。
Deering & Cheriton [Page 17]
デアリングとCheriton[17ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Checksum
チェックサム
The checksum is the 16-bit one's complement of the one's
complement sum of the IGMP message starting with the IGMP Type.
For computing the checksum, the checksum field should be zero.
This checksum may be replaced in the future.
チェックサムはIGMP Typeから始まるIGMPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するために、チェックサム分野はゼロであるべきです。 将来、このチェックサムを取り替えるかもしれません。
Identifier
識別子
An identifier to aid in matching Request and Reply messages.
合っているRequestとReplyメッセージで支援する識別子。
Sequence Number
一連番号
A sequence number to aid in matching Request and Reply
messages.
合っているRequestとReplyメッセージで支援する一連番号。
Group Address
グループアドレス
For a Create Group Request message, a value of 0.
Create Group Requestメッセージ、0の値のために。
For a Create Group Reply message, either a newly allocated
group address (if the request is approved) or a value of 0 (if
denied).
Create Group Replyメッセージ(新たに割り当てられたグループアドレス(要求が承認されているなら)か0の値(否定されるなら)のどちらか)のために。
Access Key
アクセスキー
For a Create Group Request message, a value of 0.
Create Group Requestメッセージ、0の値のために。
For a Create Group Reply message, either a pseudo-random 64-bit
number (if the request for a restricted group is approved) or
0.
Create Group Replyメッセージ(擬似ランダムの64ビットの番号(制限されたグループを求める要求が承認されているなら)か0のどちらか)のために。
Description
記述
A Create Group Request message is sent to the the group of
local multicast agents by a host wishing to allocate a new
temporary group.
Create Group Requestメッセージは新しい一時的なグループを割り当てたがっているホストによって地元のマルチキャストエージェントのグループに送られます。
If no Reply message is received within t seconds, the Request
is retransmitted. If no Reply is received after n
transmissions, the request is deemed to have failed.
t秒以内にReplyメッセージを全く受け取らないなら、Requestを再送します。 nトランスミッションの後にReplyを全く受け取らないなら、失敗したと要求を考えます。
The first Reply message to arrive, if any, specifies the
outcome of the request. The request may be denied because of
lack of resources (e.g. no table space in gateways or all
temporary addresses in use).
もしあれば到着する最初のReplyメッセージは要求の結果を指定します。 要求は財源不足(例えば、ゲートウェイでテーブルスペースがない使用中のすべての仮の住所)のために否定されるかもしれません。
Deering & Cheriton [Page 18]
デアリングとCheriton[18ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
If the request is approved, the requesting host is considered
to be the first and only current member of the new host group.
要求が承認されているなら、要求ホストは新しいホストグループの1番目の、そして、現在のメンバーだけであると考えられます。
The Identifier and Sequence Number fields are used to match the
Reply to the corresponding Request. The multicast agents may
choose to use these values to minimize the chance of allocating
more than one new group for a single request, for example when
a Reply is lost and a
IdentifierとSequence Number分野は、対応するRequestにReplyを合わせるのに使用されます。 マルチキャストエージェントは、例えば、Replyが無くなるときのただ一つの要求とaのために1つ以上の新しいグループを割り当てるという機会を最小にするのにこれらの値を使用するのを選ぶかもしれません。
Request is retransmitted. However, the multicast agents must
be prepared to recover temporary group addresses without
requiring explicit Leave Group Requests from all members; they
may choose simply to allocate a new address for every
retransmission and recover unused ones when needed <5>.
要求は再送されます。 しかしながら、マルチキャストエージェントはすべてのメンバーから明白なLeave Group Requestsを必要としないで一時的なグループアドレスを回復する用意ができていなければなりません。 彼らは、単にあらゆる「再-トランスミッション」のための新しいアドレスを割り当てて、必要な<5>であるときに未使用のものを回復するのを選ぶかもしれません。
Deering & Cheriton [Page 19]
デアリングとCheriton[19ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Join Group Request or Join Group Reply Message
グループ要求に参加するか、またはグループ応答メッセージを接合してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Key +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + アクセスキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP分野:
Addresses
アドレス
A Join Group Request message is sent with an individual IP
address of the sending host as its source, and the well-known
group address of the multicast agents as its destination.
ソースとしての送付ホストの個々のIPアドレス、およびマルチキャストエージェントのよく知られるグループアドレスと共に目的地としてJoin Group Requestメッセージを送ります。
The corresponding Join Group Reply is sent with those two
addresses reversed.
それらの2つのアドレスが逆にされている状態で、対応するJoin Group Replyを送ります。
IGMP Fields:
IGMP分野:
Type
タイプ
103 for Join Group Request
104 for Join Group Reply
103、グループ要求104に参加する、グループ回答に参加してください。
Code
コード
For a Join Group Request message, the Code field contains 0.
Join Group Requestメッセージに関しては、Code分野は0を含んでいます。
For a Join Group Reply message, the Code field specifies the
outcome of the request:
Join Group Replyメッセージとして、Code分野は要求の結果を指定します:
0 = request approved
1 = request denied, no resources
2 = request denied, invalid group address
3 = request denied, invalid access key
0は1つの承認された=要求が否定した要求と等しいです、2=要求が否定しなかったリソース、全く3=要求が否定した無効のグループアドレス、無効のアクセスキー
Deering & Cheriton [Page 20]
デアリングとCheriton[20ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Checksum
チェックサム
The checksum is the 16-bit one's complement of the one's
complement sum of the IGMP message starting with the IGMP Type.
For computing the checksum, the checksum field should be zero.
This checksum may be replaced in the future.
チェックサムはIGMP Typeから始まるIGMPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するために、チェックサム分野はゼロであるべきです。 将来、このチェックサムを取り替えるかもしれません。
Identifier
識別子
An identifier to aid in matching Request and Reply messages.
合っているRequestとReplyメッセージで支援する識別子。
Sequence Number
一連番号
A sequence number to aid in matching Request and Reply
messages.
合っているRequestとReplyメッセージで支援する一連番号。
Group Address
グループアドレス
For a Join Group Request message, a host group address.
Join Group Requestメッセージ、ホストグループアドレスのために。
For a Join Group Reply message, the same group address as in
the corresponding request.
Join Group Replyメッセージに関しては、同じくらいは対応する要求のようにアドレスを分類します。
Access Key
アクセスキー
For a Join Group Request message, the access key allocated when
the group was created (0 for unrestricted groups).
Join Group Requestメッセージに関しては、グループであるときに割り当てられたアクセスキーは作成されました(無制限なグループのための0)。
For a Join Group Reply message, the same access key as in the
corresponding request.
aに関しては、Join Group Replyは通信して、同じくらい中の同じアクセスキーは対応する要求です。
Description
記述
A Join Group Request message is sent to the the group of local
multicast agents by a host wishing to join a specified,
existing group. If no Reply message is received within t
seconds, the Request is retransmitted. If no reply is received
after n transmissions, the request is deemed to have failed.
Join Group Requestメッセージは指定されて、既存のグループに加わりたがっているホストによって地元のマルチキャストエージェントのグループに送られます。 t秒以内にReplyメッセージを全く受け取らないなら、Requestを再送します。 nトランスミッションの後に回答を全く受け取らないなら、失敗したと要求を考えます。
The first Reply message to arrive, if any, specifies the
outcome of the request. The request may be denied because of
an invalid access key, an invalid specified group address (e.g.
non-existent group) or lack of resources (e.g. no table space
in gateways).
もしあれば到着する最初のReplyメッセージは要求の結果を指定します。 要求は無効のアクセスキー、無効の指定されたグループアドレス(例えば、実在しないグループ)または財源不足(例えば、ゲートウェイでテーブルスペースがない)のために否定されるかもしれません。
The Identifier and Sequence Number fields are used to match the
Reply to the corresponding Request. If a multicast agent
IdentifierとSequence Number分野は、対応するRequestにReplyを合わせるのに使用されます。 マルチキャストエージェントです。
Deering & Cheriton [Page 21]
デアリングとCheriton[21ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
receives a request from a host to join a group to which it
already belongs, the agent approves the request, under the
assumption that the request was a retransmission for a lost
Reply.
仲間に入るそれが既に属するホストから、エージェントが無くなっているReplyのために要求が「再-トランスミッション」であったという仮定で要求を承認するという要求を受け取ります。
Deering & Cheriton [Page 22]
デアリングとCheriton[22ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Leave Group Request or Leave Group Reply Message
グループ要求を残すか、またはグループ応答メッセージを残してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
IP分野:
Addresses
アドレス
A Leave Group Request message is sent with an individual IP
address of the sending host as its source, and the well-known
group address of the multicast agents as its destination.
ソースとしての送付ホストの個々のIPアドレス、およびマルチキャストエージェントのよく知られるグループアドレスと共に目的地としてLeave Group Requestメッセージを送ります。
The corresponding Leave Group Reply is sent with those two
addresses reversed.
それらの2つのアドレスが逆にされている状態で、対応するLeave Group Replyを送ります。
IGMP Fields:
IGMP分野:
Type
タイプ
105 for Leave Group Request
106 for Leave Group Reply
105 休暇のために、休暇を求めるグループ要求106は回答を分類します。
Code
コード
For a Leave Group Request message, the Code field contains 0.
Leave Group Requestメッセージに関しては、Code分野は0を含んでいます。
For Leave Group Reply message, the Code field specifies the
outcome of the request:
Leave Group Replyメッセージとして、Code分野は要求の結果を指定します:
0 = request approved
2 = request denied, invalid group address
承認された2=要求が否定した0=要求、無効のグループアドレス
Checksum
チェックサム
The checksum is the 16-bit one's complement of the one's
complement sum of the IGMP message starting with the IGMP Type.
For computing the checksum, the checksum field should be zero.
This checksum may be replaced in the future.
チェックサムはIGMP Typeから始まるIGMPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するために、チェックサム分野はゼロであるべきです。 将来、このチェックサムを取り替えるかもしれません。
Deering & Cheriton [Page 23]
デアリングとCheriton[23ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Identifier
識別子
An identifier to aid in matching Request and Reply messages.
合っているRequestとReplyメッセージで支援する識別子。
Sequence Number
一連番号
A sequence number to aid in matching Request and Reply
messages.
合っているRequestとReplyメッセージで支援する一連番号。
Group Address
グループアドレス
For a Leave Group Request message, a host group address.
Leave Group Requestメッセージ、ホストグループアドレスのために。
For a Leave Group Reply message, the same group address as in
the corresponding request.
Leave Group Replyメッセージに関しては、同じくらいは対応する要求のようにアドレスを分類します。
Description
記述
A Leave Group Request message is sent to the the group of local
multicast agents by a host wishing to leave a specified,
existing group. If no Reply message is received within t
seconds, the Request is retransmitted. If no reply is received
after n transmissions, the request is deemed to have succeeded.
Leave Group Requestメッセージは指定されて、既存のグループを出たがっているホストによって地元のマルチキャストエージェントのグループに送られます。 t秒以内にReplyメッセージを全く受け取らないなら、Requestを再送します。 nトランスミッションの後に回答を全く受け取らないなら、成功したと要求を考えます。
The first Reply message to arrive, if any, specifies the
outcome of the request. The request may be denied only if the
specified group address is invalid (e.g. an individual rather
than a group address.)
もしあれば到着する最初のReplyメッセージは要求の結果を指定します。 指定されたグループアドレスが無効である場合にだけ、要求は否定されるかもしれません。(例えば、グループアドレスよりむしろ個人。)
The Identifier and Sequence Number fields are used to match the
Reply to the corresponding Request, as with other ICMP
transactions. If a multicast agent receives a request from a
host to leave a group to which it does not belong, the agent
approves the request, under the assumption that the request was
a retransmission for a lost Reply.
IdentifierとSequence Number分野は対応するRequestにReplyを合わせるのに使用されます、他のICMPトランザクションのように。 マルチキャストエージェントがそれが属しないグループを出るためにホストから要求を受け取るなら、エージェントは要求を承認します、要求が無くなっているReplyのための「再-トランスミッション」であったという仮定で。
Deering & Cheriton [Page 24]
デアリングとCheriton[24ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
Notes:
注意:
<1> In reality, Internet addresses (individual or group) are bound
to network interfaces or network attachment points, not the host
machines per se.
ほんとうは、インターネットが扱う1>(個人かグループ)が必ずネットワークでつなぐ<が連結するか、またはそういうもののホスト・マシンではなく、付着点をネットワークでつないでください。
<2> In this procedure call notation, the arguments for an operation
are listed in parentheses after the operation name, and the
returned values, if any, are listed after a --> symbol.
この手順呼び出し記法による<2>、操作のための議論は操作名の後に括弧に記載されます、そして、もしあれば戻り値は記載された後aです-->シンボル。
<3> One unicast transmission from sender to gateway and one
multicast transmission from gateway to local group members
送付者からの地域団体のメンバーへのゲートウェイからのゲートウェイと1つのマルチキャスト送信への<の3の>の1つのユニキャストの送信
<4> This protocol may eventually be replaced by a more general
reliable transaction protocol designed for this type of
client/server interaction, as suggested in RFC-955 [5].
結局これが議定書の中で述べる<4>をこのタイプのクライアント/サーバ相互作用のために設計されたより一般的な信頼できるトランザクションプロトコルに取り替えるかもしれません、RFC-955[5]に示されるように。
<5> Multicast agents can use an ICMP Echo message to determine if a
group has any current members. The Echo message should be
transmitted several times before deciding the group address is
no longer in use.
<5>マルチキャストエージェントはグループで何か現在のメンバーがいるかどうか決定するICMP Echoメッセージを使用できます。 グループアドレスについて決めるのがもう使用中にならない前にEchoメッセージは何度か送られるべきです。
Deering & Cheriton [Page 25]
デアリングとCheriton[25ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
References
参照
[1] L. Aguilar. Datagram Routing for Internet Multicasting. In ACM
SIGCOMM '84 Communications Architectures and Protocols, pages
58-63. ACM, June, 1984.
[1] L.アギラル。 インターネットマルチキャスティングのためのデータグラムルート設定。 ACM SIGCOMM84年Communications Architecturesとプロトコル、58-63ページで。 1984年6月のACM。
[2] E. J. Berglund and D. R. Cheriton. Amaze: A distributed
multi-player game program using the distributed V kernel. In
Proceedings of the Fourth International Conference on
Distributed Systems. IEEE, May, 1984.
[2] E.J.BerglundとD.R.Cheriton。 驚かせます: 分散Vカーネルを使用する分配されたマルチプレーヤーゲームプログラム。 分散システムIEEEにおける第4国際会議の議事、1984年5月に。
[3] A. D. Birrell et al. Grapevine: an exercise in distributed
computing. Communications of the ACM 25(4):260-274, April,
1982.
[3] A.D.ビレル他 ぶどうのツル: 分散コンピューティングにおける運動。 ACM 25(4)に関するコミュニケーション: 260-274と、1982年4月。
[4] D. R. Boggs. Internet Broadcasting. PhD thesis, Stanford
University, January, 1982.
[4] D.R.ボッグズ。 インターネット放送。 博士論文、スタンフォード大学、1982年1月。
[5] R. Braden. Towards a Transport Service for Transaction
Processing Applications. Technical Report RFC-919, SRI Network
Information Center, September, 1985.
[5] R.ブレーデン。 輸送に向かって、トランザクション処理のためにアプリケーションを供給してください。 技術報告書RFC-919、様のネットワーク情報センター、1985年9月。
[6] J-M. Chang. Simplifying Distributed Database Design by Using a
Broadcast Network. In SIGMOD '84. ACM, June, 1984.
[6]J-M。 チャン。 放送網を使用することによって、分散データベースデザインを簡素化します。 SIGMOD84年に。 1984年6月のACM。
[7] D. R. Cheriton and S. E. Deering. Host Groups: A Multicast
Extension for Datagram Internetworks. In Proceedings of the
Ninth Data Communications Symposium. ACM/IEEE, September, 1985.
[7] D.R.CheritonとS.E.デアリング。 グループをホスティングしてください: データグラムインターネットワークのためのマルチキャスト拡大。 第9データ通信シンポジウムの議事で。 1985年9月のACM/IEEE。
[8] D. R. Cheriton and W. Zwaenepoel. Distributed Process Groups in
the V Kernel. ACM Transactions on Computer Systems 3(3), May,
1985.
[8] D.R.CheritonとW.Zwaenepoel。 分配されたプロセスはVカーネルで分類されます。 1985年5月のコンピュータ・システム3(3)の上のACMトランザクション。
[9] F. Cristian et al. Atomic Broadcast: from simple message
diffusion to Byzantine agreement. In 15th International
Conference on Fault Tolerant Computing. , Ann Arbor, Michigan,
June, 1985.
[9] F.クリスチャン他 原子放送: 簡単なメッセージ拡散から込み入った協定まで。 フォルト・トレラントのコンピューティングに関する第15国際会議で。 , アナーバー(ミシガン)1985年6月。
[10] Y. K. Dalal and R. M. Metcalfe. Reverse Path Forwarding of
Broadcast Packets. Communications of the ACM 21(2):1040-1047,
December, 1978.
[10] Y.K.DalalとR.M.メトカルフェ。 放送パケットの経路推進を逆にしてください。 ACM 21(2)に関するコミュニケーション: 1040-1047と、1978年12月。
[11] H. Forsdick. MMCF: A Multi-Media Conferencing Facility.
personal communication.
[11] H.Forsdick。 MMCF: A Multi-メディアConferencing Facility個人的なコミュニケーション。
Deering & Cheriton [Page 26]
デアリングとCheriton[26ページ]
RFC 966 December 1985 Host Groups: A Multicast Extension to the Internet Protocol
RFC966 1985年12月のホストは分類します: インターネットプロトコルへのマルチキャスト拡大
[12] K. Lebowitz and D. Mankins. Multi-network Broadcasting within
the Internet.Technical Report RFC-947, SRI Network Information
Center, June, 1985.
[12] K.レボウィッツとD.マンキンズ。 1985年6月のInternet.Technical Report RFC-947、様のネットワークインフォメーション・センターの中のマルチネットワーク放送。
[13] J. Mogul. Broadcasting Internet Datagrams. Technical Report
RFC-919, SRI Network Information Center, October, 1984.
[13] J.ムガール人。 1984年10月にインターネットデータグラム技術報告書RFC-919、様のネットワークインフォメーション・センターを放送します。
[14] J. Postel. Internet Protocol. Technical Report RFC-791, SRI
Network Information Center, September, 1981.
[14] J.ポステル。 インターネットプロトコル。 技術報告書RFC-791、様のネットワーク情報センター、1981年9月。
[15] J. Postel. Internet Control Message Protocol. Technical Report
RFC-792, SRI Network Information Center, September, 1981.
[15] J.ポステル。 インターネット・コントロール・メッセージ・プロトコル。 技術報告書RFC-792、様のネットワーク情報センター、1981年9月。
[16] D. W, Wall. Mechanisms for Broadcast and Selective Broadcast.
Technical Report 190, Computer Systems Laboratory, Stanford
University, June, 1980.
[16] D.W、壁。 放送と選択している放送のためのメカニズム。 技術報告書190、コンピュータシステム研究所、スタンフォード大学、1980年6月。
[17] J. K. Reynolds and J. Postel. Assigned Numbers. Technical
Report RFC-960, SRI Network Information Center, September,
1981.
[17] J.K.レイノルズとJ.ポステル。 規定番号。 技術報告書RFC-960、様のネットワーク情報センター、1981年9月。
Deering & Cheriton [Page 27]
デアリングとCheriton[27ページ]
一覧
スポンサーリンク
