RFC988 日本語訳
0988 Host extensions for IP multicasting. S.E. Deering. July 1986. (Format: TXT=45220 bytes) (Obsoletes RFC0966) (Obsoleted by RFC1054, RFC1112) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. E. Deering
Request for Comments: 988 Stanford University
July 1986
コメントを求めるワーキンググループS.E.デアリングの要求をネットワークでつないでください: 988 スタンフォード大学1986年7月
Host Extensions for IP Multicasting
IPマルチキャスティングのためのホスト拡大
1. STATUS OF THIS MEMO
1. このメモの状態
This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here. Distribution of this memo is unlimited.
このメモはインターネットワークマルチキャスティングをサポートするのにインターネットプロトコル(IP)のホスト導入について必要である拡大を指定します。 この仕様は、ARPA-インターネットでRFC-966で与えられたそれに取って代わって、IPマルチキャスティングの提案されたプロトコル標準を構成します。 読者は動機と原理の議論のためにここで指定されたマルチキャスティング拡大の後ろにRFC-966に向けられます。 このメモの分配は無制限です。
2. INTRODUCTION
2. 序論
IP multicasting is defined as the transmission of an IP datagram to a "host group", a set of zero or more hosts identified by a single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same "best-efforts" reliability as regular unicast IP datagrams, i.e. the datagram is not guaranteed to arrive at all members of the destination group or in the same order relative to other datagrams.
IPマルチキャスティングは「ホストグループ」へのIPデータグラムのトランスミッションと定義されて、ゼロか以上のセットはただ一つの受信者IPアドレスによって特定されたホストです。 マルチキャストデータグラムは通常のユニキャストIPデータグラムとして同じ「最善の努力」の信頼性であて先ホストグループのすべてのメンバーに提供されます、すなわち、データグラムは、他のデータグラムに比例して目的地グループのすべてのメンバーにおいて、または、同次に到着するように保証されません。
The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group, but membership in a group may be restricted to only those hosts possessing a private access key. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it.
ホストグループの会員資格はダイナミックです。 すなわち、ホストは、いつでも、グループに加わって、出るかもしれません。 制限が全くホストグループにおける位置か会員数にありませんが、グループにおける会員資格は個人的なアクセスキーを持っているそれらのホストだけに制限されるかもしれません。 一度に、ホストは1つ以上のグループのメンバーであるかもしれません。 ホストはデータグラムをそれに送るグループのメンバーである必要はありません。
A host group may be permanent or transient. A permanent group has a well-known, administratively assigned IP address. It is the address, not the membership of the group, that is permanent; at any time a permanent group may have any number of members, even zero. A transient group, on the other hand, is assigned an address dynamically when the group is created, at the request of a host. A transient group ceases to exist, and its address becomes eligible for reassignment, when its membership drops to zero.
ホストグループは、永久的であるか、または一時的であるかもしれません。 永久的なグループには、よく知られて、行政上割り当てられたIPアドレスがあります。 それはグループの会員資格ではなく、永久的なアドレスです。 いつでも、永久的なグループには、どんな会員数、同等のゼロもあるかもしれません。 グループが創設されるとき、他方では、アドレスはダイナミックに一時的なグループに配属されます、ホストの依頼で。 一時的なグループは消滅します、そして、会員資格がゼロまで下がると、アドレスは再割当てに適任になります。
The creation of transient groups and the maintenance of group membership information is the responsibility of "multicast agents", entities that reside in internet gateways or other special-purpose hosts. There is at least one multicast agent directly attached to every IP network or subnetwork that supports IP multicasting. A host requests the creation of new groups, and joins or leaves existing groups, by exchanging messages with a neighboring agent.
一時的なグループの創設とグループ会員資格情報のメインテナンスは「マルチキャストエージェント」(インターネットゲートウェイか他の専用ホストにある実体)の責任です。 直接IPマルチキャスティングをサポートするあらゆるIPネットワークかサブネットワークに付けられた少なくとも1人のマルチキャストエージェントがいます。 ホストは、既存のグループを新しいグループの創設を要求して、加わるか、または出ます、隣接しているエージェントとメッセージを交換することによって。
Deering [Page 1]
デアリング[1ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
Multicast agents are also responsible for internetwork delivery of multicast IP datagrams. When sending a multicast IP datagram, a host transmits it to a local network multicast address which identifies all neighboring members of the destination host group. If the group has members on other networks, a multicast agent becomes an additional recipient of the local multicast and relays the datagram to agents on each of those other networks, via the internet gateway system. Finally, the agents on the other networks each transmit the datagram as a local multicast to their own neighboring members of the destination group.
また、マルチキャストエージェントもマルチキャストIPデータグラムのインターネットワーク配送に責任があります。マルチキャストIPデータグラムを送るとき、ホストはあて先ホストグループのすべての隣接しているメンバーを特定する企業内情報通信網マルチキャストアドレスにそれを伝えます。 グループにメンバーが他のネットワークにいるなら、マルチキャストエージェントは、地方のマルチキャストの追加受取人になって、それぞれのそれらの他のネットワークでエージェントにデータグラムをリレーします、インターネットゲートウェイシステムで。 最終的に、他のネットワークのエージェントは地方のマルチキャストとしてそれぞれそれら自身の目的地グループの隣接しているメンバーにデータグラムを送ります。
This memo specifies the extensions required of a host IP implementation to support IP multicasting, where a "host" is any internet host or gateway other than those serving as multicast agents. The algorithms and protocols used within and between multicast agents are transparent to non-agent hosts and will be specified in a separate document. This memo also does not specify how local network multicasting is accomplished for all types of network, although it does specify the required service interface to an arbitrary local network and gives an Ethernet specification as an example. Specifications for other types of network will be the subject of future memos.
このメモはIPマルチキャスティングをサポートするのにホストIP実装について必要である拡大を指定します、それらが役立つのを除いて、「ホスト」がマルチキャストエージェントとしてあらゆるインターネットホストやゲートウェイであるところで。 エージェント以内とマルチキャストエージェントの間で使用されるアルゴリズムとプロトコルは、非エージェントのホストにとって透明であり、別々のドキュメントで指定されるでしょう。 このメモも企業内情報通信網マルチキャスティングがすべてのタイプのネットワークのためにどう達成されるかを指定しません、必要なサービスインタフェースを任意の企業内情報通信網に指定して、例として仕様をイーサネットに与えますが。 他のタイプのネットワークのための仕様は将来のメモの対象になるでしょう。
3. LEVELS OF CONFORMANCE
3. 順応のレベル
There are three levels of conformance to this specification:
この仕様への順応の3つのレベルがあります:
Level 0: no support for IP multicasting.
レベル0: IPマルチキャスティングのサポートがありません。
There is, at this time, no requirement that all IP implementations
support IP multicasting. Level 0 hosts will, in general, be
unaffected by multicast activity. The only exception arises on
some types of local network, where the presence of level 1 or 2
hosts may cause misdelivery of multicast IP datagrams to level 0
hosts. Such datagrams can easily be identified by the presence of
a class D IP address in their destination address field; they
should be quietly discarded by hosts that do not support IP
multicasting. Class D addresses are defined in section 4 of this
memo.
このとき、すべてのIP実装がIPマルチキャスティングをサポートするという要件が全くありません。 レベル0 一般に、ホストはマルチキャスト活動で影響を受けなくなるでしょう。 唯一の例外が何人かのタイプの企業内情報通信網に起こります。そこでは、レベル1か2 ホストの存在がマルチキャストIPデータグラムの配達ミスに0人のホストを平らにさせるかもしれません。 それらの目的地アドレス・フィールドでのクラスD IPアドレスの存在は容易にそのようなデータグラムを特定できます。 それらはIPマルチキャスティングをサポートしないホストによって静かに捨てられるべきです。 クラスDアドレスはこのメモのセクション4で定義されます。
Deering [Page 2]
デアリング[2ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
Level 1: support for sending but not receiving multicast IP datagrams.
レベル1: マルチキャストを発信しますが、受けないように、IPがデータグラムであるとサポートしてください。
Level 1 allows a host to partake of some multicast-based services,
such as resource location or status reporting, but it does not
allow a host to create or join any host groups. An IP
implementation may be upgraded from level 0 to level 1 very easily
and with little new code. Only sections 4, 5, and 6 of this memo
are applicable to level 1 implementations.
ホストはレベル1でリソース位置か状態報告などのいくつかのマルチキャストベースのサービスを相伴できますが、それで、ホストは、どんなホストグループにも創設するか、または加わりません。 IP実装は非常に簡単と少ない新法でレベル0からレベル1までアップグレードするかもしれません。 このメモのセクション4、5、および6だけがレベル1 実装に適切です。
Level 2: full support for IP multicasting.
レベル2: IPマルチキャスティングの全面的な支援。
Level 2 allows a host to create, join and leave host groups, as
well as send IP datagrams to host groups. It requires
implementation of the Internet Group Management Protocol (IGMP)
and extension of the IP and local network service interfaces
within the host. All of the following sections of this memo are
applicable to level 2 implementations.
レベル2で、ホストは、ホストグループに創設して、加わって、出て、IPデータグラムをホストグループに送ります。 それはホストの中でインターネットGroup Managementプロトコル(IGMP)の実装とIPと企業内情報通信網サービスインタフェースの拡大を必要とします。 このメモの以下のセクションのすべてがレベル2 実装に適切です。
4. HOST GROUP ADDRESSES
4. ホストグループアドレス
Host groups are identified by class D IP addresses, i.e. those with "1110" as their high-order four bits. The remaining 28 bits are unstructured as far as hosts are concerned. The addresses of well-known, permanent groups are to be published in "Assigned Numbers". Class E IP addresses, i.e. those with "1111" as their high-order four bits, are reserved for future addressing modes.
ホストグループはすなわち、クラスD IPアドレス、それらの高位4ビットとしての「1110」があるものによって特定されます。 ホストに関する限り、残っている28ビットは不統一です。 よく知られて、永久的なグループのアドレスは「規定番号」で発行されることです。 クラスE IPアドレス(すなわち、それらの高位4ビットとしての「1111」があるそれら)は将来のアドレッシング・モードのために予約されます。
Appendix II contains some background discussion of several issues related to host group addresses.
付録IIはホストグループアドレスに関連するいくつかの問題の何らかのバックグラウンド議論を含んでいます。
Deering [Page 3]
デアリング[3ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
5. MODEL OF A HOST IP IMPLEMENTATION
5. ホストIP実装のモデル
The multicast extensions to a host IP implementation are specified in terms of the layered model illustrated below. In this model, ICMP and (for level 2 hosts) IGMP are considered to be implemented within the IP module, and the mapping of IP addresses to local network addresses is considered to be the responsibility of local network modules. This model is for expository purposes only, and should not be construed as constraining an actual implementation.
ホストIP実装へのマルチキャスト拡大は以下で例証された層にされたモデルで指定されます。 このモデルでは、IPモジュールの中でICMPと(レベル2 ホストのための)IGMPが実装されると考えられて、企業内情報通信網アドレスへのIPアドレスに関するマッピングは企業内情報通信網モジュールの責任であると考えられます。 このモデルは解説の目的だけのためにあって、実際の実装を抑制するのに理解するべきではありません。
| |
| Upper-Layer Protocol Modules |
|__________________________________________________________|
| | | 上側の層のプロトコルモジュール| |__________________________________________________________|
--------------------- IP Service Interface -----------------------
__________________________________________________________
| | | |
| | ICMP | IGMP |
| IP |______________|______________|
| Module |
| |
|__________________________________________________________|
--------------------- IPサービスインタフェース----------------------- __________________________________________________________ | | | | | | ICMP| IGMP| | IP|______________|______________| | モジュール| | | |__________________________________________________________|
---------------- Local Network Service Interface -----------------
__________________________________________________________
| | |
| Local | IP-to-local address mapping |
| Network | (e.g. ARP) |
| Modules |_____________________________|
| (e.g. Ethernet) |
| |
---------------- 企業内情報通信網サービスインタフェース----------------- __________________________________________________________ | | | | ローカル| IPからローカルアドレスへのマッピング| | ネットワーク| (例えば、ARP) | | モジュール|_____________________________| | (例えば、イーサネット) | | |
To support level 2 IP multicasting, a host IP implementation must provide three new services: (1) sending multicast IP datagrams, (2) receiving multicast IP datagrams, and (3) managing group membership. Only the first service need be provided in level 1 hosts. Each of these services is described in a separate section, below. For each service, extensions are specified for the IP service interface, the IP module, the local network service interface, and an Ethernet local network module. Extensions to local network modules other than Ethernet are mentioned briefly, but are not specified in detail.
支持線2IPマルチキャスティングに、ホストIP実装は3つの新種業務を提供しなければなりません: (1) (2) グループ会員資格を管理しながらマルチキャストIPデータグラム、および(3)を受けて、マルチキャストIPデータグラムを送ります。 レベル1 ホストにファーストサービスだけを提供しなければなりません。 それぞれのこれらのサービスは下の別々のセクションで説明されます。 各サービスとして、拡大はIPサービスインタフェース、IPモジュール、企業内情報通信網サービスインタフェース、およびイーサネット企業内情報通信網モジュールに指定されます。 イーサネット以外の企業内情報通信網モジュールへの拡大は、簡潔に言及されますが、詳細に指定されません。
Deering [Page 4]
デアリング[4ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
6. SENDING MULTICAST IP DATAGRAMS
6. 送付マルチキャストIPデータグラム
6.1. Extensions to the IP Service Interface
6.1. IPサービスインタフェースへの拡大
No change to the IP service interface is required to support the
sending of multicast IP datagrams. An upper-layer protocol module
merely specifies an IP host group destination, rather than an
individual IP destination, when it invokes the existing "Send IP"
operation.
IPサービスインタフェースへの変化は全くマルチキャストIPデータグラムの発信をサポートする必要はありません。上側の層のプロトコルモジュールは単に個々のIPの目的地よりむしろIPホストグループの目的地を指定します、「IPを送ってください」という既存の操作を呼び出すとき。
6.2. Extensions to the IP Module
6.2. IPモジュールへの拡大
To support the sending of multicast IP datagrams, the IP module
must be extended to recognize IP host group addresses when routing
outgoing datagrams. Most IP implementations include the following
logic:
マルチキャストIPデータグラムの発信をサポートするなら、発信データグラムを発送するとき、IPホストグループアドレスを認識するためにIPモジュールを広げなければなりません。ほとんどのIP実装が以下の論理を含んでいます:
if IP-destination is on the same local network,
send datagram locally to IP-destination
else
send datagram locally to GatewayTo(IP-destination)
IP-目的地が同じ企業内情報通信網にあるなら、ほかに局所的にIP-目的地にデータグラムを送ってください、局所的にデータグラムをGatewayToに送ってください。(IP-目的地)
To allow multicast transmissions, the routing logic must be
changed to:
マルチキャスト送信を許すなら、以下のことのためにルーティング論理を変えなければなりません。
if IP-destination is on the same local network
or IP-destination is a host group,
send datagram locally to IP-destination
else
send datagram locally to GatewayTo(IP-destination)
IP-目的地が同じ企業内情報通信網にあるか、IP-目的地がホストグループであるなら、ほかに局所的にIP-目的地にデータグラムを送ってください、局所的にデータグラムをGatewayToに送ってください。(IP-目的地)
If the sending host is itself a member of the destination group, a
copy of the outgoing datagram must be looped-back for local
delivery if and only if loopback was requested when the host
joined the group (see section 8.1). (This issue does not arise in
level 1 implementations.)
そして、送付ホストがそれ自体で目的地グループのメンバーであるなら、地方の配送のために-逆で発信データグラムのコピーを輪にしなければならない、ホストがグループに加わったとき(セクション8.1を見てください)、ループバックが要求された場合にだけ。 (この問題はレベル1 実装で起こりません。)
On hosts attached to more than one network, each multicast IP
datagram must be transmitted via one network interface only,
leaving it to the multicast agents to effect delivery to any other
required networks.
1つ以上のネットワークに配属されるホストの上では、マルチキャストエージェントに任せて、1つのネットワーク・インターフェースだけを通していかなる他の必要なネットワークへの効果配送にもそれぞれのマルチキャストIPデータグラムを送らなければなりません。
A host group address should not be placed in the source address
field of an outgoing IP datagram. A host group address may be
used in a source routing option as the last element only.
出発しているIPデータグラムのソースアドレス・フィールドにホストグループアドレスを置くべきではありません。 ホストグループアドレスは最後の要素だけとしてソースルーティングオプションに使用されるかもしれません。
It should be noted that a small IP time-to-live (TTL) value can
生きる小さいIP時間(TTL)値がそうすることができることに注意されるべきです。
Deering [Page 5]
デアリング[5ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
prevent delivery to some members of a destination group. Thus, a
large TTL value should be used to reach all members. Conversely,
a small TTL value can be used to advantage to reach only "nearby"
members of a widely-dispersed group. In clusters of low-delay
local area networks, the TTL field acts as a hop limit; thus, one
can perform expanding-ring searches by starting with a TTL of 1
and incrementing on each retransmission, up to some limit defined
by the diameter of the cluster.
目的地グループの何人かのメンバーに配送を防いでください。 したがって、大きいTTL値は、すべてのメンバーに届くのに使用されるべきです。 逆に、広く分散しているグループの「近い」メンバーだけに届く利点に小さいTTL値を使用できます。 いくつもの群れをなして低い遅れローカル・エリア・ネットワークでは、TTL分野はホップ限界として機能します。 したがって、1つは各「再-トランスミッション」での1と増加のTTLから始まることによって、拡張リング検索を実行できます、クラスタの直径によって定義された何らかの限界まで。
6.3. Extensions to the Local Network Service Interface
6.3. 企業内情報通信網サービスインタフェースへの拡大
No change to the local network service interface is required to
support the sending of multicast IP datagrams. The IP module
merely specifies an IP host group destination, rather than an
individual IP destination, when it invokes the existing "Send
Local" operation.
企業内情報通信網サービスインタフェースへの変化は全くマルチキャストIPデータグラムの発信をサポートする必要はありません。IPモジュールは単に個々のIPの目的地よりむしろIPホストグループの目的地を指定します、「地方で、発信してください」既存の操作を呼び出すとき。
6.4. Extensions to an Ethernet Local Network Module
6.4. イーサネット企業内情報通信網モジュールへの拡大
The Ethernet directly supports the sending of local multicast
packets by allowing multicast addresses in the destination field
of Ethernet packets. All that is needed to support the sending of
multicast IP datagrams is a procedure for mapping IP host group
addresses to Ethernet multicast addresses.
イーサネットは、イーサネットパケットのあて先フィールドにマルチキャストアドレスを許容することによって、直接地方のマルチキャストパケットの発信をサポートします。 マルチキャストIPデータグラムの発信をサポートするのに必要であるのは、IPホストグループアドレスをイーサネットマルチキャストアドレスに写像するための手順だけです。
An IP host group address is mapped to an Ethernet multicast
address by placing the low-order 28-bits of the IP address into
the low-order 28 bits of an Ethernet address. The high-order 20
bits of the Ethernet address are set to a well-known value, to be
published in "Assigned Numbers".
IPホストグループアドレスはIP入賞するのによる下位の28ビットがイーサネット・アドレスの下位の28ビットに扱うイーサネットマルチキャストアドレスに写像されます。 よく知られる値に「規定番号」でイーサネット・アドレスの高位20ビットが発行されるように設定されます。
[At time of publication of this memo, a block of Ethernet
multicast addresses with 28 unspecified bits had not yet been
obtained from the allocating authority. If such a block of
addresses cannot be obtained, an alternative mapping scheme will
be specified.]
[このメモの公表の時に、不特定の28ビットがある1ブロックのイーサネットマルチキャストアドレスは割り当て権威からまだ得られていませんでした。 1ブロックのそのようなアドレスを得ることができないと、代替のマッピング体系は指定されるでしょう。]
6.5. Extensions to Local Network Modules other than Ethernet
6.5. イーサネット以外のLocal Network Modulesへの拡大
Other networks that directly support multicasting, such as rings
or buses conforming to the IEEE 802.2 standard, can be handled the
same way as Ethernet for the purpose of sending multicast IP
datagrams. For a network that supports broadcast but not
multicast, such as the Experimental Ethernet, all IP host group
addresses can be mapped to a single local broadcast address (at
the cost of increased overhead on all local hosts). For a
point-to-point networks like the ARPANET or a public data network
マルチキャストIPデータグラムを送る目的のためのイーサネットとして同じように直接マルチキャスティングをサポートするIEEE802.2規格に一致しているリングかバスなどの他のネットワークは扱うことができます。Experimentalイーサネットなどのマルチキャストではなく、サポートが放送するネットワークにおいて、ただ一つのローカル放送アドレス(すべてのローカル・ホストの上の増強されたオーバーヘッドの費用における)にすべてのIPホストグループアドレスを写像できます。 ポイントツーポイントのために、ネットワークはアルパネットか公衆データネットワークが好きです。
Deering [Page 6]
デアリング[6ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
(X.25), all IP host group addresses might be mapped to the
well-known local address of an IP multicast agent; an agent on
such a network would take responsibility for completing multicast
delivery within the network as well as among networks.
(X.25)、すべてのIPホストグループアドレスがIPマルチキャストエージェントのよく知られるローカルアドレスに写像されるかもしれません。 そのようなネットワークのエージェントはネットワークの中でマルチキャスト配送を終了して、ネットワークに責任を取るでしょう。
7. RECEIVING MULTICAST IP DATAGRAMS
7. マルチキャストIPデータグラムを受けます。
7.1. Extensions to the IP Service Interface
7.1. IPサービスインタフェースへの拡大
No change to the IP service interface is required to support the
reception of multicast IP datagrams. Incoming multicast IP
datagrams are delivered to upper-layer protocol modules using the
same "Receive IP" operation as normal, unicast datagrams.
IPサービスインタフェースへの変化は全くマルチキャストIPデータグラムのレセプションをサポートする必要はありません。入って来るマルチキャストIPデータグラムは「IPを受けてください」という通常の同じ同じくらい操作を使用することで上側の層のプロトコルモジュールに提供されます、ユニキャストデータグラム。
7.2. Extensions to the IP Module
7.2. IPモジュールへの拡大
To support the reception of multicast IP datagrams, the IP module
must be extended to recognize the addresses of IP host groups to
which the host currently belongs, in addition to the host's
individual IP address(es). An incoming datagram destined to one
of those group addresses is processed exactly the same way as
datagrams destined to one of the host's individual addresses.
Incoming datagrams destined to groups to which the host does not
belong are discarded without generating any error report.
ホストが現在属するIPホストグループのアドレスを認識するためにIPモジュールを広げなければなりません、マルチキャストIPデータグラムのレセプションをサポートするならホストの個々のIPアドレス(es)に加えて。 データグラムがずっとホストの個々のアドレスの1つに運命づけられて、それらのグループアドレスの1つに運命づけられた受信データグラムはまさに同じように処理されます。 どんなエラー・レポートも作らないで、ホストが属しないグループに運命づけられた受信データグラムは捨てられます。
On hosts attached to more than one network, if a datagram arrives
via one network interface, destined for a group to which the host
belongs only on a different interface, the datagram is quietly
discarded. (This should occur only as a result of inadequate
multicast address filtering in the local network module.)
データグラムがホストが異なったインタフェースだけで属するグループのために運命づけられた1つのネットワーク・インターフェースを通して届くなら1つ以上のネットワークに配属されるホストの上では、データグラムは静かに捨てられます。 (これは単に企業内情報通信網モジュールによる不十分なマルチキャストアドレスフィルタリングの結果、起こるべきです。)
An incoming datagram is not rejected for having an IP host group
address in its source address field or anywhere in a source
routing option.
受信データグラムは、ソースアドレス・フィールドかソースルーティングオプションでどこでもIPホストグループアドレスを持つために拒絶されません。
An ICMP error message (Destination Unreachable, Time Exceeded,
Parameter Problem, Source Quench, or Redirect) is never generated
in response to a datagram destined to an IP host group.
ICMPエラーメッセージ(目的地Unreachable、Time Exceeded、Parameter Problem、Source Quench、またはRedirect)はIPホストグループに運命づけられたデータグラムに対応して決して生成されません。
7.3. Extensions to the Local Network Service Interface
7.3. 企業内情報通信網サービスインタフェースへの拡大
No change to the local network service interface is required to
support the reception of multicast IP datagrams. Incoming local
network packets, whether multicast or unicast, are delivered to
the IP module using the same "Receive Local" operation.
企業内情報通信網サービスインタフェースへの変化は全くマルチキャストIPデータグラムのレセプションをサポートする必要はありません。入って来る企業内情報通信網パケットは、マルチキャストかユニキャストであることにかかわらず同じ「地方であることで、受信してください」操作を使用することでIPモジュールに提供されます。
Deering [Page 7]
デアリング[7ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
7.4. Extensions to an Ethernet Local Network Module
7.4. イーサネット企業内情報通信網モジュールへの拡大
To support the reception of multicast IP datagrams, an Ethernet
module must be able to receive packets addressed to the Ethernet
multicast addresses that correspond to the host's IP host group
addresses. It is highly desirable to take advantage of any
address filtering capabilities that the Ethernet hardware
interface may have, so that the host only receives packets that
are destined to it.
マルチキャストIPデータグラムのレセプションをサポートするために、イーサネットモジュールはホストのIPホストグループアドレスに一致しているイーサネットマルチキャストアドレスに扱われたパケットを受けることができなければなりません。 イーサネットハードウェア・インタフェースが持っているかもしれない能力をフィルターにかけるどんなアドレスも利用するのは非常に望ましいです、ホストがそれに運命づけられているパケットを受けるだけであるように。
Unfortunately, many current Ethernet interfaces have a small limit
on the number of addresses that the hardware can be configured to
recognize. However, an implementation must be capable of
listening on an arbitrary number of Ethernet multicast addresses,
which may mean "opening up" the address filter to accept all
multicast packets during those periods when the number of
addresses exceeds the limit of the filter.
残念ながら、多くの現在のイーサネットインタフェースが認識するためにハードウェアを構成できるアドレスの数に小さい限界を持っています。 しかしながら、実装はイーサネットマルチキャストアドレスの特殊活字の数字で聴くことができなければなりません。(アドレスはアドレスの数がフィルタの限界を超えているそれらの期間、すべてのマルチキャストパケットを受け入れるためにアドレスフィルタを「開けること」を意味するかもしれません)。
For interfaces with inadequate hardware address filtering, it may
be desirable (for performance reasons) to perform Ethernet address
filtering within the software of the Ethernet module. This is not
mandatory, however, because the IP module performs its own
filtering based on IP destination addresses.
不十分なハードウェア・アドレスフィルタリングとのインタフェースに関しては、イーサネットモジュールのソフトウェアの中でイーサネット・アドレスフィルタリングを実行するのは望ましいかもしれません(性能理由による)。 IPモジュールが受信者IPアドレスに基づくそれ自身のフィルタリングを実行するので、しかしながら、これは義務的ではありません。
7.5. Extensions to Local Network Modules other than Ethernet
7.5. イーサネット以外のLocal Network Modulesへの拡大
Other multicast networks, such as IEEE 802.2 networks, can be
handled the same way as Ethernet for the purpose of receiving
multicast IP datagrams. For pure broadcast networks, such as the
Experimental Ethernet, all incoming broadcast packets can be
accepted and passed to the IP module for IP-level filtering. On a
point-to-point network, multicast IP datagrams will arrive as
local network unicasts, so no change to the local network module
should be necessary.
他のマルチキャストはIEEEなどのように802.2のネットワークをネットワークでつないで、マルチキャストIPデータグラムを受ける目的のためのイーサネットとして同じように扱うことができます。Experimentalイーサネットなどの純粋な放送網において、IP-レベルフィルタリングのためにすべての入って来る放送パケットをIPモジュールに受け入れられて、通過できます。 二地点間ネットワークでは、マルチキャストIPデータグラムが企業内情報通信網ユニキャストとして届くので、企業内情報通信網モジュールへのどんな変化も必要であるべきではありません。
Deering [Page 8]
デアリング[8ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
8. MANAGING GROUP MEMBERSHIP
8. グループ会員資格を管理します。
8.1. Extensions to the IP Service Interface
8.1. IPサービスインタフェースへの拡大
To allow upper-layer protocol modules to request that their host
create, join, or leave a host group, the IP service interface must
be extended to offer the following three new operations:
上側の層のプロトコルモジュールが、彼らのホストがホストグループ、IPサービスインタフェースを作成するか、加わるか、または残すよう要求するのを許容するのは以下の3つの新しい操作を提供するために拡張していなければなりません:
CreateGroup ( private, loopback )
--> outcome, group-address, access-key
CreateGroup(兵卒、ループバック)-->結果、グループアドレス、アクセスキー
The CreateGroup operation requests the creation of a new,
transient host group, with this host as its only member. The
"private" argument specifies if the group is to be private or
public. The "loopback" argument specifies whether or not
datagrams sent from this host to the group should be delivered
locally as well as to other member hosts. The "outcome" result
indicates whether the request is granted or denied. If it is
granted, a new 32-bit IP host group address is returned, along
with a 64-bit access key which is zero for public groups and
non-zero for private groups. The request may be denied due to
lack of response from a multicast agent, or lack of resources.
CreateGroup操作はこのホストと共に唯一のメンバーとして新しくて、一時的なホストグループの創設を要求します。 「個人的な」議論は、グループが個人的であるか、または公共であるつもりであるかを指定します。 「ループバック」議論は、このホストからグループに送られたデータグラムが他のメンバーホストに関して局所的にまた、提供されるべきであるかどうか指定します。 「結果」結果は、要求が承諾されるか、または否定されるかを示します。 それを与えるなら、新しい32ビットのIPホストグループアドレスを返します、公立のグループのためのゼロと民間のグループのための非ゼロである64ビットのアクセスキーと共に。 要求は無反応のためマルチキャストエージェント、または財源不足から否定されるかもしれません。
JoinGroup ( group-address, access-key, loopback ) --> outcome
JoinGroup(グループアドレス、アクセスキー、ループバック)-->結果
The JoinGroup operation requests that this host become a member of
the host group identified by "group-address", with the specified
access key. The "loopback" argument specifies whether or not
datagrams sent from this host to the group should be delivered
locally as well as to other member hosts. The "outcome" result
indicates whether the request is granted or denied. The request
may be denied due to lack of response from a multicast agent, lack
of resources, an invalid group address, an incorrect access key,
or already being a member.
JoinGroup操作は、このホストが「グループアドレス」によって特定されたホストグループのメンバーになるよう要求します、指定されたアクセスキーで。 「ループバック」議論は、このホストからグループに送られたデータグラムが他のメンバーホストに関して局所的にまた、提供されるべきであるかどうか指定します。 「結果」結果は、要求が承諾されるか、または否定されるかを示します。 要求は無反応のためマルチキャストエージェント、財源不足、無効のグループアドレス、不正確なアクセスキー、または既にメンバーであるのから否定されるかもしれません。
LeaveGroup ( group-address, access-key ) --> outcome
LeaveGroup(グループアドレス、アクセスキー)-->結果
The LeaveGroup operation requests that this host give up its
membership in the host group identified by "group-address", with
the specified access key. The "outcome" result indicates whether
the request is granted or denied. The request may be denied due
to an invalid group address, an incorrect access key, or not
currently being a member.
LeaveGroup操作は、このホストが「グループアドレス」によって特定されたホストグループで会員資格をあきらめるよう要求します、指定されたアクセスキーで。 「結果」結果は、要求が承諾されるか、または否定されるかを示します。 要求は無効のグループアドレス、不正確なアクセスキー、または現在でないときにメンバーであるため否定されるかもしれません。
Each of these operations may take up to a minute or more to
complete, depending on the number of IGMP retransmissions
それぞれのこれらの操作は完成する1分以上まで取るかもしれません、IGMP retransmissionsの数によって
Deering [Page 9]
デアリング[9ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
performed within the IP module, and time required for a multicast
agent to generate a reply. However, typical delays should be on
the order of a few seconds.
IPモジュール、およびマルチキャストエージェントが回答を生成するのに必要である時中に実行されます。 しかしながら、数秒の注文には典型的な遅れがあるべきです。
Besides the LeaveGroup operation, a host loses its membership in a
group whenever the host or its IP module crashes, or, in rare
circumstances, when a multicast agent revokes its membership. The
IP service interface should provide some means of informing an
upper-layer module when its membership has been revoked.
Membership may be revoked due to lack of resources, deallocation
of the group address, or the discovery of another host group using
the same group address with a different access key. (See Appendix
II for discussion of address recycling issues.)
LeaveGroup操作以外に、または、ホストかそのIPモジュールがまれな事情でダウンするときはいつも、ホストはグループで会員の資格を失います、マルチキャストエージェントが会員資格を取り消すとき。 IPサービスインタフェースは会員資格がいつ取り消されたかを上側の層のモジュールに知らせるいくつかの手段を提供するべきです。 会員資格は、リソースの不足、グループアドレスの反配分、または別のホストグループの発見のため異なったアクセスキーと共に同じグループアドレスを使用することで取り消されるかもしれません。 (アドレスリサイクル問題の議論に関してAppendix IIを見てください。)
It is important to observe that IP group membership is per-host,
rather than per-process. An IP service interface should not allow
multiple processes to invoke JoinGroup operations for the same
group as a way of achieving delivery to more than process. The IP
module delivers each incoming datagram, whether multicast or
unicast, to the single upper-layer protocol module identified by
the protocol field in the datagram's IP header; it is an
upper-layer issue whether or not to deliver incoming datagrams to
more than one process, perhaps using the concept of "process
groups" or "shared ports".
IPグループ会員資格がプロセスよりむしろホストであることを観測するのは重要です。 複数のプロセスはプロセス以上に配送を達成する方法と同じグループのためにIPサービスインタフェースでJoinGroup操作を呼び出すことができないはずです。 IPモジュールは各受信データグラムを提供します、マルチキャストかユニキャストであることにかかわらず、データグラムのIPヘッダーのプロトコル分野によって特定されたただ一つの上側の層のプロトコルモジュールに。 1つ以上のプロセスに受信データグラムを提供するかどうかが、上側の層の問題です、恐らく「プロセスグループ」か「共有されたポート」の概念を使用して。
8.2. Extensions to the IP Module
8.2. IPモジュールへの拡大
Within the IP module, the membership management operations are
supported by the Internet Group Management Protocol (IGMP),
specified in Appendix I. As well as having messages corresponding
to each of the operations specified above, IGMP also specifies a
"deadman timer" procedure whereby hosts periodically confirm their
memberships with the multicast agents.
IPモジュールの中では、メッセージを上で指定されたそれぞれの操作に対応するようにするとAppendix I.Asでよく指定されたインターネットGroup Managementプロトコル(IGMP)で会員資格管理操作は後押しされています、また、IGMPがマルチキャストエージェントと共にホストが定期的に彼らの会員資格を確認する「分銅タイマ」手順を指定します。
The IP module must maintain a data structure listing the IP
addresses of all host groups to which the host currently belongs,
along with each group's loopback policy, access key, and timer
variables. This data structure is used by the IP multicast
transmission service to know which outgoing datagrams to loop
back, and by the reception service to know which incoming
datagrams to accept. The purpose of IGMP and the management
interface operations is to maintain this data structure.
IPモジュールはホストが現在属するすべてのホストグループのIPアドレスを記載するデータ構造を維持しなければなりません、各グループのループバック方針、アクセスキー、およびタイマ変数と共に。 このデータ構造は、どの受信データグラムを受け入れたらよいかを知るために逆、およびレセプションサービスでどの発信データグラムを輪にしたらよいかを知るのにIPマルチキャストトランスミッションサービスで使用されます。 IGMPと管理インタフェース操作の目的はこのデータ構造を維持することです。
On hosts attached to more than one network, each membership is
associated with a particular network interface. On such a host
the management interface operations above may each require an
additional parameter specifying to which interface the create,
1つ以上のネットワークに配属されるホストでは、それぞれの会員資格は特定のネットワーク・インターフェースに関連しています。 そのようなホストの上では、上の管理インタフェース操作がそれぞれどのインタフェースに指定する追加パラメタを必要とするかもしれない、作成
Deering [Page 10]
デアリング[10ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
join, or leave request applies. The group membership data
structure must also be extended to associate an interface with
each membership. If a host joins the same host group on more than
one network interface, it can expect to receive multiple copies of
each datagram sent to that group.
接合するか、または適用します休暇が、要求する。 また、各会員資格とのインタフェースを関連づけるためにグループ会員資格データ構造を広げなければなりません。 ホストが1つ以上のネットワーク・インターフェースに関する同じホストグループに加わるなら、それは、そのグループに送られたそれぞれのデータグラムの複本を受けると予想できます。
8.3. Extensions to the Local Network Service Interface
8.3. 企業内情報通信網サービスインタフェースへの拡大
To allow an IP module to control what packets should be accepted
by the local network module, it is necessary to extend the local
network service interface with the following two new operations:
IPモジュールが、どんなパケットが企業内情報通信網モジュールで受け入れられるべきであるかを制御するのを許容するために、以下の2つの新しい操作との企業内情報通信網サービスインタフェースを広げるのが必要です:
AcceptAddress ( group-address )
AcceptAddress(グループアドレス)
RejectAddress ( group-address )
RejectAddress(グループアドレス)
where "group-address" is an IP host group address. The
AcceptAddress operation requests the local network module to
accept and deliver up subsequently arriving packets destined to
the local network address corresponding to "group-address". The
RejectAddress operation requests the local network module to stop
delivering up packets destined to the local network address
corresponding to "group-address".
「グループアドレス」がIPホストであるところでは、アドレスを分類してください。 AcceptAddress操作は「グループアドレス」に対応する企業内情報通信網アドレスに運命づけられた次に到着しているパケットを受け入れて、引き渡すよう企業内情報通信網モジュールに要求します。 RejectAddress操作は、「グループアドレス」に対応する企業内情報通信網アドレスに運命づけられたパケットを引き渡すのを止めるよう企業内情報通信網モジュールに要求します。
Any local network module is free to ignore RejectAddress requests,
and may deliver up packets destined to more addresses than just
those specified in AcceptAddress requests, if it is unable to
filter incoming packets adequately.
どんな企業内情報通信網モジュールも、RejectAddress要求を無視するのにおいて自由であり、まさしくAcceptAddress要求で指定されたものより多くのアドレスに運命づけられたパケットを引き渡すかもしれません、適切に入って来るパケットをフィルターにかけることができないなら。
8.4. Extensions to an Ethernet Local Network Module
8.4. イーサネット企業内情報通信網モジュールへの拡大
An Ethernet module responds to AcceptAddress operations by adding
the corresponding Ethernet multicast address to its acceptance
filter for incoming packets. A RejectAddress operation causes the
corresponding Ethernet address to be dropped from the filter. For
Ethernet interfaces with a limit on the number of addresses that
can be added to the filter, the Ethernet software module must
detect when that threshold is exceeded and open up the filter to
accept all multicast packets. It should also detect when the
number of addresses drops below the threshold and revert to
individual address filtering.
イーサネットモジュールは、入って来るパケットのために対応するイーサネットマルチキャストアドレスを承認フィルタに加えることによって、AcceptAddress操作に応じます。 RejectAddress操作で、フィルタから対応するイーサネット・アドレスを下げます。 フィルタに加えることができるアドレスの数における限界とのイーサネットインタフェースに関しては、イーサネットソフトウェア・モジュールは、その敷居がいつ超えられているかを検出して、すべてのマルチキャストパケットを受け入れるためにフィルタを開けなければなりません。 それは、また、アドレスの数がいつ敷居より下であるまで低下するかを検出して、個々のアドレスフィルタリングに戻るべきです。
8.5. Extensions to Local Network Modules other than Ethernet
8.5. イーサネット以外のLocal Network Modulesへの拡大
Other multicast networks, such as IEEE 802.2 networks, can be
handled the same way as Ethernet for the purpose of controlling
address filtering. For a pure broadcast network or a
他のマルチキャストはIEEEなどのように802.2のネットワークをネットワークでつないで、ずっと制御する目的のためのイーサネットがフィルタリングを扱うように同じように扱うことができます。 純粋な放送網かaのために
Deering [Page 11]
デアリング[11ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
point-to-point network, the AcceptAddress and RejectAddress
operations may have no effect; all incoming packets could be
passed to the IP module for IP-level filtering.
二地点間ネットワーク、AcceptAddress、およびRejectAddress操作は効き目がないかもしれません。 IP-レベルフィルタリングのためにすべての入って来るパケットをIPモジュールに通過できました。
Deering [Page 12]
デアリング[12ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
付録I.インターネット集団経営プロトコル(IGMP)
The Internet Group Management Protocol (IGMP) is used between IP hosts and their immediate neighbor multicast agents to support the creation of transient groups, the addition and deletion of members of a group, and the periodic confirmation of group membership. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast agent.
インターネットGroup Managementプロトコル(IGMP)は、一時的なグループの創設、グループのメンバーの追加と削除、およびグループ会員資格の周期的な確認をサポートするのにIPホストと彼らのすぐ隣の人マルチキャストエージェントの間で使用されます。 IGMPは非対称のプロトコルであり、ここでマルチキャストエージェントよりむしろホストの観点から指定されます。
Like ICMP, IGMP is a integral part of IP. It is required to be implemented in full by all hosts conforming to level 2 of the IP multicasting specification. IGMP messages are encapsulated in IP datagrams, with an IP protocol number of 2. All IGMP messages have the following format:
ICMPのように、IGMPはIPの不可欠の部分です。 IPマルチキャスティング仕様のレベル2に従うすべてのホストによってすべて実装されるのにそれが必要です。 IGMPメッセージはIPデータグラムで2のIPプロトコル番号でカプセル化されます。 すべてのIGMPメッセージには、以下の形式があります:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + アクセスキー+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
There are eight types of IGMP message:
IGMPメッセージの8つのタイプがあります:
1 = Create Group Request
2 = Create Group Reply
1 = =がグループ回答を作成するというグループ要求2を作成してください。
3 = Join Group Request
4 = Join Group Reply
3 = =がグループ回答に参加するというグループ要求4に参加してください。
5 = Leave Group Request
6 = Leave Group Reply
5 = グループ要求6=休暇をグループ回答に残してください。
7 = Confirm Group Request
8 = Confirm Group Reply
7 = グループ要求8=がグループ回答を確認すると確認してください。
Deering [Page 13]
デアリング[13ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
Code
コード
In a Create Group Request message, the code field indicates if the
new host group is to be public or private:
Create Group Requestメッセージでは、コード分野は、新しいホストグループが公共であるか、または個人的であるつもりであるかを示します:
0 = public
1 = private
0は公衆と1=個人的に等しいです。
In all other Request messages, the code field contains zero.
他のすべてのRequestメッセージでは、コード分野はゼロを含んでいます。
In a Reply message, the Code field specifies the outcome of the
request:
Replyメッセージでは、Code分野は要求の結果を指定します:
0 = request granted
1 = request denied, no resources
2 = request denied, invalid code
3 = request denied, invalid group address
4 = request denied, invalid access key
5 - 255 = request pending, retry in this many seconds
0=要求は=要求が否定した1を与えました、2=要求が否定しなかったリソース、全く3=要求が否定した無効のコード、4=要求が否定した無効のグループアドレス、未定の無効のアクセスキー5--255=要求、何秒もこれでの再試行
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.
チェックサムはIGMP Typeから始まるIGMPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するために、チェックサム分野はゼロであるべきです。
Identifier
識別子
In a Confirm Group Request message, the identifier field contains
zero.
Confirm Group Requestメッセージでは、識別子分野はゼロを含んでいます。
In all other Request messages, the identifier field contains a
value to distinguish the request from other requests by the same
host.
他のすべてのRequestメッセージでは、識別子分野は同じホストによる他の要求と要求を区別する値を含んでいます。
In a Reply message, the identifier field contains the same value
as in the corresponding Request message.
Replyメッセージでは、識別子分野は対応するRequestメッセージのように同じ値を含んでいます。
Deering [Page 14]
デアリング[14ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
Group Address
グループアドレス
In a Create Group Request message, the group address field
contains zero.
Create Group Requestメッセージでは、グループアドレス・フィールドはゼロを含んでいます。
In all other Request messages, the group address field contains a
host group address.
他のすべてのRequestメッセージでは、グループアドレス・フィールドはホストグループアドレスを含んでいます。
In a Create Group Reply message, the group address field contains
either a newly allocated host group address (if the request is
granted) or zero (if denied).
Create Group Replyメッセージでは、グループアドレス・フィールドは1のどちらかかゼロ新たに割り当てられたホストグループアドレス(要求が承諾されるなら)を含んでいます(否定されるなら)。
In all other Reply messages, the group address field contains the
same host group address as in the corresponding Request message.
他のReplyメッセージ、アドレス・フィールドが同じように含むすべてのグループでは、対応するRequestメッセージのようにグループアドレスをホスティングしてください。
Access Key
アクセスキー
In a Create Group Request message, the access key field contains
zero.
Create Group Requestメッセージでは、アクセスキー分野はゼロを含んでいます。
In all other Request messages, the access key field contains the
access key assigned to the host group identified in the Group
Address field (zero for public groups).
他のすべてのRequestメッセージでは、アクセスキー分野はGroup Address分野(公立のグループのためのゼロ)で特定されたホストグループに配属されたアクセスキーを含んでいます。
In a Create Group Reply message, the access key field contains
either a non-zero 64-bit number (if the request for a private
group is granted) or zero.
Create Group Replyメッセージでは、アクセスキー分野は1のどちらかかゼロ非ゼロの64ビットの番号(民間のグループを求める要求が承諾されるなら)を含んでいます。
In all other Reply messages, the access key field contains the
same access key as in the corresponding Request.
他のReplyメッセージ、分野が対応するRequestに同じアクセスキーを含むすべてのアクセスキーで。
Deering [Page 15]
デアリング[15ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
Protocol Rules
プロトコル規則
Request messages are sent only by hosts. Reply messages are sent
only by multicast agents. If a host receives an IGMP message of a
type other than the four Reply types specified above, the message
is discarded.
要求メッセージは単にホストによって送られます。 応答メッセージは単にマルチキャストエージェントによって送られます。 ホストが上で指定された4つのReplyタイプ以外のタイプに関するIGMPメッセージを受け取るなら、メッセージは捨てられます。
A Request message is sent with its IP destination field containing
the well-known address of the Multicast Agent Group. The IP
time-to-live field is initialized by the sender to 1, in order to
limit the scope of the request to immediate neighbor multicast
agents only. The IP source address field contains the individual
IP address of the sending host.
IPあて先フィールドがMulticastエージェントGroupのよく知られるアドレスを含んでいて、Requestメッセージを送ります。 IP生きる時間分野は送付者によって1に初期化されます、要求の範囲をすぐ隣の人マルチキャストエージェントだけに制限するために。 IPソースアドレス・フィールドは送付ホストの個々のIPアドレスを含んでいます。
A Reply message is sent only in response to a Request message.
Its IP destination address field contains the individual address
of the host that sent the corresponding Request. (A Confirm Group
Reply may also be sent to the host group address specified in its
corresponding Confirm Group Request.) The IP source address field
contains the individual IP address of the replying multicast
agent.
単にRequestメッセージに対応してReplyメッセージを送ります。 受信者IPアドレス分野は対応するRequestを送ったホストの個々のアドレスを含んでいます。 (また、対応するConfirm Group Requestで指定されたホストグループアドレスにConfirm Group Replyを送るかもしれません。) IPソースアドレス・フィールドは返答しているマルチキャストエージェントの個々のIPアドレスを含んでいます。
When a host sends a new Create Group, Join Group, or Leave Group
Request message, it supplies an arbitrary identifier that it has
not used within the last T0 seconds. (It is usually sufficient
just to increment the identifier for each new request.) The host
initializes a timer to T1 seconds and a retransmission counter to
zero. If a Reply message with a matching identifier is not
received before the timer expires, it is reset to T1 seconds and
the retransmission counter is incremented. If the counter is less
than N1, the host retransmits the Request message with the same
identifier. If the counter equals N1, the host gives up; if the
request was to create or join a group, it is deemed to have
failed; if the request was to leave a group, it is deemed to have
succeeded.
ホストが新しいCreate Group、Join Group、またはLeave Group Requestメッセージを送るとき、それは最後のT0秒以内に使用していない任意の識別子を提供します。 (通常、まさしくそれぞれの新しい要求のための識別子を増加するのは十分です。) ホストはT1秒と「再-トランスミッション」カウンタへのタイマをゼロに初期化します。 合っている識別子があるReplyメッセージが以前受け取られないなら、タイマは期限が切れます、そして、それはT1秒までリセットされます、そして、「再-トランスミッション」カウンタは増加されています。 カウンタがN1以下であるなら、ホストは同じ識別子でRequestメッセージを再送します。 カウンタがN1と等しいなら、ホストはあきらめます。 要求がグループに創設するか、または加わることであったなら、失敗したと考えられます。 要求がグループを出ることであったなら、成功したと考えられます。
If a "request pending" code is received in a matching reply to a
Create Group, Join Group, or Leave Group Request, the timer is
reset to the number of seconds specified by the code and the
retransmission counter is reset to zero. The new timer value
applies to one timeout interval only -- if the timer expires, it
is reset to T1 seconds, the counter is incremented, and the
request is retransmitted.
合っている回答で「要求未定」のコードをCreate Group、Join Group、またはLeave Group Requestに受け取るなら、コードによって指定された秒数にタイマをリセットします、そして、「再-トランスミッション」カウンタをゼロにリセットします。 タイマが期限が切れるなら、新しいタイマ値は1回のタイムアウト間隔だけに適用されます、そして、それはT1秒までリセットされます、そして、カウンタは増加されています、そして、要求は再送されます。
The first matching Reply to a Create Group, Join Group, or Leave
Group Request containing a "request granted" or "request denied"
code determines the outcome of the request. Any subsequent or
「承諾された要求」か「否定された要求」コードを含むCreate Group、Join Group、またはLeave Group Requestへの最初の合っているReplyは要求の結果を決定します。 またはいくらか、その後。
Deering [Page 16]
デアリング[16ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
non-matching Replies are discarded by the host. However, if a
host receives an affirmative Create Group Reply or Join Group
Reply that neither matches an outstanding Request nor contains the
address of a group to which the host belongs, the host should
immediately send a Leave Group Request for the unexpected group
address.
非合っているRepliesはホストによって捨てられます。 しかしながら、ホストが傑出しているRequestを合わせないで、またホストが属するグループのアドレスを含まない肯定的なCreate Group ReplyかJoin Group Replyを受け取るなら、ホストはすぐに、予期していなかったグループアドレスのためにLeave Group Requestを送るべきです。
A "request granted" reply to a Create Group Request implies that,
as well as the group being created, the requesting host is granted
membership in the group, i.e. there is no need to send a separate
Join Group Request.
Create Group Requestへの「承諾された要求」回答は、創設されるグループと同様に会員資格がグループで要求ホストに与えられるのを含意します、すなわち、別々のJoin Group Requestを送る必要は全くありません。
Confirm Group Request messages must be sent periodically by hosts
to inform the neighboring multicast agent(s) of the hosts'
continuing membership in the specified groups. If an agent does
not receive a Confirm Group Request message for a particular group
within an agent-defined interval, it stops delivering datagrams
destined to that group.
ホストがホストの継続する会員資格について指定されたグループで隣接しているマルチキャストエージェントに知らせるために定期的にGroup Requestメッセージを送らなければならないと確認してください。 エージェントがエージェントによって定義された間隔以内の特定のグループへのConfirm Group Requestメッセージを受け取らないなら、それは、そのグループに運命づけられたデータグラムを提供するのを止めます。
For each group to which it belongs, a host maintains a
confirmation timer and a variable t. The variable t is
initialized to T2 seconds. Whenever the host's request to create
or join a group is granted, and whenever the host either sends a
Confirm Group Request or receives a Confirm Group Reply with a
"request granted" code for the group, the host sets the group's
timer to a random number uniformly distributed between t and t +
T3 seconds. If the host receives a a Confirm Group Reply with a
"request pending" code, t is changed to the value of the code and
the timer is reset to a random number between the new t and t +
T3. The variable t retains its value until another "request
pending" code is received. Whenever the timer expires, the host
sends a Confirm Group Request.
それが属する各グループのために、ホストは確認タイマと変数tを維持します。 変数tはT2秒まで初期化されます。 グループに創設するか、または加わるというホストの要求が承諾されるときはいつも、グループのために「承諾された要求」コードでConfirm Group Requestを送るか、またはConfirm Group Replyを受け取るときはいつも、ホストは一様にtとt+T3秒の間に分配された乱数にグループのタイマを設定します。 ホストが「要求未定」のコードでConfirm Group Replyを受け取るなら、tはコードの値に変わります、そして、タイマは新しいtとt+T3の間の乱数にリセットされます。 別の「要求未定」のコードが受け取られているまで、変数tは値を保有します。 タイマが期限が切れるときはいつも、ホストはConfirm Group Requestを送ります。
Even if a host fails to receive Confirm Group Replies to its
Requests, it continues to consider itself a member of the group,
because it may still be able to receive multicast datagrams from
other hosts on the same local network. Only if a host receives a
"request denied" code in a Confirm Group Reply does it stop
sending Confirm Group Requests and consider its membership to be
revoked.
ホストがConfirm Group RepliesをRequestsに受け取らないでも、それ自体がグループのメンバーであると考え続けています、同じ企業内情報通信網に他のホストからマルチキャストデータグラムをまだ受け取ることができるかもしれないので。 ホストがConfirm Group Replyの「否定された要求」コードを受け取る場合にだけ、それは、Confirm Group Requestsを送るのを止めて、会員資格が取り消されると考えますか?
Multicast agents respond to Confirm Group Request messages by
sending Confirm Group Reply messages either to the individual
sender of the Request or to the host group address specified in
the Request. By sending back a Confirm Group Reply to all
neighboring members of a group, a multicast agent is able to reset
every member's timer with a single packet. The randomization of
マルチキャストエージェントは、Requestの個々の送付者、または、Requestで指定されたホストグループアドレスへのメッセージをConfirm Group Replyに送ることによって、Confirm Group Requestメッセージに応じます。 グループのすべての隣接しているメンバーにConfirm Group Replyを返送することによって、マルチキャストエージェントは単一のパケットですべてのメンバーのタイマをリセットできます。 無作為化
Deering [Page 17]
デアリング[17ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
the timers is intended to cause only the one member whose timer
expires first to send a Confirm Group Request, stimulating a Reply
to reset all the timers. The use of the "request pending" codes
allows the multicast agent to control the rate at which it
receives Confirm Group Requests.
タイマがタイマが最初に、Confirm Group Requestを送るために期限が切れる1人のメンバーだけを引き起こすことを意図します、すべてのタイマをリセットするためにReplyを刺激して。 「要求未定」のコードの使用で、マルチキャストエージェントはそれがConfirm Group Requestsを受けるレートを制御できます。
Protocol Timing Constants
プロトコルタイミング定数
The following timing constants are specified for IGMP. They are
subject to change as a result of operational experience.
以下のタイミング定数はIGMPに指定されます。 それらは運用経験の結果、変化を被りやすいです。
T0 = 300 seconds minimum recycle time for identifiers
T0=300秒最小限は識別子のための時間を再生します。
T1 = 2 seconds retrans. interval for Create/Join/Leave Requests
retrans Create/のための間隔がRequestsを接合するか、または残す2T1=秒
N1 = 5 tries retrans. limit for Create/Join/Leave Requests
N1=5はretransを試みます。RequestsをCreateのために制限するか、接合する、または残してください。
T2 = 15 seconds initial value for Confirm Request variable t
15T2=秒はConfirm Request変数tのために値に頭文字をつけます。
T3 = 15 seconds random range for Confirm Request variable t
Confirm Request変数tのためのT3=15秒の無作為の範囲
Deering [Page 18]
デアリング[18ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
APPENDIX II. HOST GROUP ADDRESS ISSUES
付録II。 ホストグループアドレス問題
This appendix is not part of the IP multicasting specification, but provides background discussion of several issues related to IP host group addresses.
この付録は、IPマルチキャスティング仕様の一部ではありませんが、IPホストグループアドレスに関連するいくつかの問題のバックグラウンド議論を提供します。
Group Address Binding
グループアドレス結合
The binding of IP host group addresses to physical hosts may be
considered a generalization of the binding of IP unicast
addresses. An IP unicast address is statically bound to a single
local network interface on a single IP network. An IP host group
address is dynamically bound to a set of local network interfaces
on a set of IP networks.
物理ホストへのIPホストグループアドレスの製本はIPユニキャストアドレスの製本の一般化であると考えられるかもしれません。 IPユニキャストアドレスはただ一つのIPネットワークで静的に単一の企業内情報通信網インタフェースに縛られます。 IPホストグループアドレスは1セットのIPネットワークでダイナミックに1セットの企業内情報通信網インタフェースに縛られます。
It is important to understand that an IP host group address is NOT
bound to a set of IP unicast addresses. The multicast agents do
not need to maintain a list of individual members of each host
group. For example, a multicast agent attached to an Ethernet
need associate only a single Ethernet multicast address with each
host group having local members, rather than a list of the
members' individual IP or Ethernet addresses.
IPホストグループアドレスが1セットのIPユニキャストアドレスに縛られないのを理解しているのは重要です。 マルチキャストエージェントはそれぞれのホストグループの個人会員のリストを維持する必要はありません。 例えば、イーサネットに付けられたマルチキャストエージェントはメンバーの個々のIPかイーサネット・アドレスのリストよりむしろ地元会員がいるそれぞれのホストグループにただ一つのイーサネットマルチキャストアドレスだけを関連づけなければなりません。
Group Addresses as Logical Addresses
論理アドレスとしてのグループアドレス
Host group addresses have been defined specifically for use in the
destination address field of multicast IP datagrams. However, the
fact that group addresses are location-independent (they are not
statically bound to a single network interface) suggests possible
uses as more general "logical addresses", both in the source as
well as the destination address field of datagrams. For example,
a mobile IP host might have a host group address as its only
identity, used as the source of datagrams it sends. Whenever the
mobile host moved from one network to another, it would join its
own group on the new network and depart from the group on the old
network. Other hosts communicating with the mobile one would deal
only with the group address and would be unaware of, and
unaffected by, the changing network location of the mobile host.
ホストグループアドレスは特にマルチキャストIPデータグラムの目的地アドレス・フィールドでの使用のために定義されました。しかしながら、グループアドレスが位置から独立しているという(それらは静的に単一のネットワーク・インターフェースに縛られません)事実は例えばモバイルIPホストがホストグループに唯一のアイデンティティとして扱わせるかもしれないより一般的な「論理アドレス」(データグラムの目的地アドレス・フィールドと同様にソースの両方)として可能な用途を示します、それが送るデータグラムの源として、使用されています。 モバイルホストが1つのネットワークから別のネットワークまで移行したときはいつも、それは、新しいネットワークでそれ自身のグループに加わって、古いネットワークでグループから出発するでしょう。 モバイルものとコミュニケートするのがアドレスはグループだけを取扱って、気づかなくて、影響を受けない他のホスト、変化はモバイルホストの位置をネットワークでつなぎます。
Host group addresses cannot, however, be used to solve all
problems of internetwork logical addressing, such as delivery to
the "nearest" or the "least loaded" network interface of a
multi-homed host. Furthermore, there are hazards in using group
addresses in the source address field of datagrams when the group
actually contains more than one host. For instance, the IP
datagram reassembly algorithm relies on every host using a
different source address. Also, errors in a datagram sent with a
しかしながら、インターネットワークの論理的なアドレシングのすべての問題を解決するのにホストグループアドレスを使用できません、“nearest"への配送やaの「最もロードされなかった」ネットワーク・インターフェースのようにマルチ、家へ帰り、ホスト。 その上、グループが実際に1人以上のホストを含むとデータグラムのソースアドレス・フィールドでグループアドレスを使用するのにおいて危険があります。 例えば、異なったソースアドレスを使用することでIPデータグラム再アセンブリアルゴリズムはすべてのホストに頼ります。 また、データグラムの誤りはaと共に発信しました。
Deering [Page 19]
デアリング[19ページ]
RFC 988 July 1986 Host Extensions for IP Multicasting
IPマルチキャスティングのためのRFC988 1986年7月ホスト拡大
group source address may result in error reports being returned to
all members of the group, not just the sender. In view of these
hazards, this memo specifies the use of host group addresses only
as destinations of datagrams, either in the destination address
field or as the last element of a source routing option. However,
it is recommended that datagrams with a group source address be
accepted without complaint, thereby allowing other implementations
to experiment with logical addressing applications of host group
addresses.
グループソースアドレスは送付者だけではなく、グループのすべてのメンバーに返されるエラー・レポートをもたらすかもしれません。 これらの危険から見て、このメモはデータグラムの目的地として、または、だけ目的地アドレス・フィールドかソースルーティングオプションの最後の原理としてホストグループアドレスの使用を指定します。 しかしながら、苦情なしでグループソースアドレスがあるデータグラムを受け入れるのはお勧めです、その結果、他の実装がホストグループアドレスの論理的なアドレシング応用を実験するのを許容します。
Recycling of Transient Host Group Addresses
一時的なホストグループアドレスの再生
Since host group addresses are of fixed, relatively small size,
transient group addresses must be recycled to satisfy continuing
requests for creation of new groups. The multicast agents make an
effort to ensure that a group has no members anywhere in the
internet before allocating its address to a new group. However,
under certain conditions of internetwork partitioning and
membership migration, it is impossible to guarantee unique
allocation of an address without seriously compromising the
availability and robustness of host groups. Furthermore, hosts
that are unaware that a particular group has ceased to exist may
send datagrams to it long after its address has been assigned to a
new group. Therefore, hosts should be prepared for the
possibility of misdelivery of multicast IP datagrams to unintended
hosts, even in private groups. Such misdelivery can only be
detected at a level above IP, using higher-level identifiers or
authentication tokens. (The access key of a private group might
be used in some applications as such an identifier.) Of course,
there are other threats to privacy of communication in the
internet, besides group address collision, such as untrustworthy
gateways or unsecured networks. End-to-end encryption is an
effective defense against such threats.
ホストグループアドレスが修理されて、比較的小さいサイズのものであるので、新しいグループの創設を求める継続する要求を満たすために一時的なグループアドレスを再生しなければなりません。 マルチキャストエージェントは、新しいグループにアドレスを割り当てる前に、グループにはメンバーが全くインターネットで何処にもいないのを保証するために取り組みを作ります。 しかしながら、インターネットワーク仕切りと会員資格移行のある状態の下で、真剣にホストグループの有用性と丈夫さに感染しないでアドレスのユニークな配分を保証するのは不可能です。 その上、アドレスが新しいグループに配属されたずっと後に特定のグループが消滅したのを気づかないホストはデータグラムをそれに送るかもしれません。 したがって、ホストはマルチキャストIPデータグラムの配達ミスの可能性のために故意でないホストに用意ができているべきです、民間のグループでさえ。 よりハイレベルの識別子か認証トークンを使用して、IPの上にレベルでそのような配達ミスを検出できるだけです。 (民間のグループのアクセスキーは使用目的によってはそのような識別子として使用されるかもしれません。) インターネットにはコミュニケーションのプライバシーへの他の脅威があります、グループアドレス衝突以外に、もちろん、信頼できないゲートウェイや非機密保護しているネットワークのように。 終端間暗号化はそのような脅威に対する効果的な防衛です。
Deering [Page 20]
デアリング[20ページ]
一覧
スポンサーリンク
