RFC1054 日本語訳
1054 Host extensions for IP multicasting. S.E. Deering. May 1988. (Format: TXT=45465 bytes) (Obsoletes RFC0988) (Obsoleted by RFC1112) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Deering Request for Comments: 1054 Stanford University Obsoletes: RFC 988 May 1988
コメントを求めるワーキンググループS.デアリングの要求をネットワークでつないでください: 1054 スタンフォード大学は以下を時代遅れにします。 RFC988 1988年5月
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 multicasting. It is proposed as a standard for IP multicasting in the Internet. This specification is a major revision of RFC-988; changes from RFC-988 are listed in an Appendix. Distribution of this memo is unlimited.
このメモはマルチキャスティングをサポートするのにインターネットプロトコル(IP)のホスト導入について必要である拡大を指定します。 それはインターネットのIPマルチキャスティングの規格として提案されます。 この仕様はRFC-988の主要な改正です。 RFC-988からの変化はAppendixに記載されています。 このメモの分配は無制限です。
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 intact 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. 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. Those IP multicast addresses that are not reserved for permanent groups are available for dynamic assignment to transient groups which exist only as long as they have members.
ホストグループは、永久的であるか、または一時的であるかもしれません。 永久的なグループには、よく知られて、行政上割り当てられたIPアドレスがあります。 それはグループの会員資格ではなく、永久的なアドレスです。 いつでも、永久的なグループには、どんな会員数、同等のゼロもあるかもしれません。 永久的なグループのために予約されないそれらのIPマルチキャストアドレスは単にそれらにメンバーがいる限り、存在する一時的なグループへのダイナミックな課題に利用可能です。
Internetwork forwarding of IP multicast datagrams is handled by "multicast routers" which may be co-resident with, or separate from, internet gateways. A host transmits an IP multicast datagram as a local network multicast which reaches all immediately-neighboring members of the destination host group. If the datagram has an IP time-to-live greater than 1, the multicast router(s) attached to the local network take responsibility for forwarding it towards all other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an
IPマルチキャストデータグラムのインターネットワーク推進がコレジデントであるかもしれない「マルチキャストルータ」によって扱われる、別々である、インターネットゲートウェイ。 ホストはあて先ホストグループのすべてのすぐに隣接しているメンバーに届く企業内情報通信網マルチキャストとしてIPマルチキャストデータグラムを送ります。 生きるIP時間がデータグラムで1よりすばらしくなるなら、企業内情報通信網に付けられたマルチキャストルータは目的地グループのメンバーがいる他のすべてのネットワークに向かってそれを送るのに責任を取ります。 それらの他の生きるIP時中に届いているメンバーネットワークに関して
Deering [Page 1] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[1ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
attached multicast router completes delivery by transmitting the datagram as a local multicast.
付属マルチキャストルータは、地方のマルチキャストとしてデータグラムを送ることによって、荷受けを完了します。
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 acting as multicast routers. The algorithms and protocols used within and between multicast routers are transparent to hosts and will be specified in separate documents. 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 described in section 4 of this memo.
このとき、すべてのIP実装がIPマルチキャスティングをサポートするという要件が全くありません。 レベル0 一般に、ホストはマルチキャスト活動で影響を受けなくなるでしょう。 唯一の例外が何人かのタイプの企業内情報通信網に起こります。そこでは、レベル1か2 ホストの存在がマルチキャストIPデータグラムの配達ミスに0人のホストを平らにさせるかもしれません。 それらの目的地アドレス・フィールドでのクラスD IPアドレスの存在は容易にそのようなデータグラムを特定できます。 それらはIPマルチキャスティングをサポートしないホストによって静かに捨てられるべきです。 クラスDアドレスはこのメモのセクション4で説明されます。
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 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 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
レベル2で、ホストは、加わって、グループをホストにやめて、IPデータグラムをホストグループに送ります。 それはホストの中でインターネットGroup Managementプロトコル(IGMP)の実装とIPと企業内情報通信網サービスインタフェースの拡大を必要とします。 このメモの以下のセクションのすべてがレベル2に適切です。
Deering [Page 2] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[2ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
implementations.
実装。
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. 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」があるものによって特定されます。 クラスE IPアドレス(すなわち、それらの高位4ビットとしての「1111」があるそれら)は将来のアドレッシング・モードのために予約されます。
In Internet standard "dotted decimal" notation, host group addresses range from 224.0.0.0 to 239.255.255.255. The address 224.0.0.0 is guaranteed not to be assigned to any group, and 224.0.0.1 is assigned to the permanent group of all IP hosts. This is used to address all multicast hosts on the directly connected network. There is no multicast address (or any other IP address) for all hosts on the total Internet. The addresses of other well-known, permanent groups are to be published in "Assigned Numbers".
インターネット標準「ドット付き10進法」記法で、ホストグループは、224.0からの範囲が.0であると.0〜239.255に扱います。.255 .255。 アドレス、224.0、.0、.0、どんなグループ、および224.0にも配属されないように、.1が割り当てられる.0がパーマに分類されるのがすべてのIPホストに保証されます。 これは、直接接続されたネットワークですべてのマルチキャストがホストであると扱うのに使用されます。 すべてのホストのためのマルチキャストアドレス(または、いかなる他のIPアドレスも)が全く総インターネットにありません。 他のよく知られて、永久的なグループのアドレスは「規定番号」で発行されることです。
Appendix II contains some background discussion of several issues related to host group addresses.
付録IIはホストグループアドレスに関連するいくつかの問題の何らかのバックグラウンド議論を含んでいます。
Deering [Page 3] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[3ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
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 1 multicasting, a host IP implementation must support the transmission of multicast IP datagrams. To support level 2 IP multicasting, a host must also support the reception of multicast IP datagrams. Each of these two new 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.
支持線1マルチキャスティングに、ホストIP実装はマルチキャストIPデータグラムのトランスミッションをサポートしなければなりません。また、支持線2IPマルチキャスティングに、ホストはマルチキャストIPデータグラムのレセプションをサポートしなければなりません。それぞれのこれらの2つの新種業務が下の別々のセクションで説明されます。 各サービスとして、拡大はIPサービスインタフェース、IPモジュール、企業内情報通信網サービスインタフェース、およびイーサネット企業内情報通信網モジュールに指定されます。 イーサネット以外の企業内情報通信網モジュールへの拡大は、簡潔に言及されますが、詳細に指定されません。
Deering [Page 4] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[4ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
6. SENDING MULTICAST IP DATAGRAMS
6. 送付マルチキャストIPデータグラム
6.1. Extensions to the IP Service Interface
6.1. IPサービスインタフェースへの拡大
Multicast IP datagrams are sent using the same "Send IP" operation used to send unicast IP datagrams; an upper-layer protocol module merely specifies an IP host group address, rather than an individual IP address, as the destination. However, a number of extensions may be necessary or desirable.
マルチキャストIPデータグラムに同じ操作が以前はよく送った「IPを送ってください」ユニキャストIPデータグラムを使用させます。 上側の層のプロトコルモジュールは目的地として単に個々のIPアドレスよりむしろIPホストグループアドレスを指定します。 しかしながら、多くの拡大が、必要であるか、または望ましいかもしれません。
First, the service interface should provide a way for the upper-layer protocol to specify the IP time-to-live of an outgoing multicast datagram, if such a capability does not already exist. If the upper-layer protocol chooses not to specify a time-to-live, it should default to 1 for all multicast IP datagrams, so that an explicit choice is required to multicast beyond a single network.
まず最初に、サービスインタフェースは上側の層のプロトコルが出発しているマルチキャストデータグラムについて生きるIP時間を指定する方法を提供するべきです、そのような能力が既に存在していないなら。 上側の層のプロトコルが、生きる時間を指定しないのを選ぶなら、すべてのマルチキャストIPデータグラムのために1をデフォルトとするべきです、明白な選択がただ一つのネットワークを超えてマルチキャストに必要であるように。
Second, for hosts that may be attached to more than one network, the service interface should provide a way for the upper-layer protocol to identify which network interface is be used for the multicast transmission. Only one interface is used for the initial transmission; multicast routers are responsible for forwarding to any other networks, if necessary. If the upper-layer protocol chooses not to identify an outgoing interface, a default interface should be used, preferably under the control of system management.
2番目に、1つ以上のネットワークに配属されるかもしれないホストのために、サービスインタフェースは上側の層のプロトコルがどのネットワーク・インターフェースがあることであるかをマルチキャスト送信において使用されていた状態で特定する方法を提供するべきです。 1つのインタフェースだけが初期のトランスミッションに使用されます。 必要なら、マルチキャストルータはいかなる他のネットワークへの推進にも原因となります。 上側の層のプロトコルが、外向的なインタフェースを特定しないのを選ぶなら、デフォルトインタフェースは使用されるべきです、望ましくはシステム管理のコントロールの下で。
Third (level 2 implementations only), for the case in which the host is itself a member of a group to which a datagram is being sent, the service interface should provide a way for the upper-layer protocol to inhibit local delivery of the datagram; by default, a copy of the datagram is looped back. This is a performance optimization for upper-layer protocols that restrict the membership of a group to one process per host (such as a routing protocol), or that handle loopback of group communication at a higher layer (such as a multicast transport protocol).
3(レベル2 実装専用)番目、ホストがそれ自体でデータグラムが送られるグループのメンバーである場合のために、サービスインタフェースは上側の層のプロトコルがデータグラムの地方の配送を抑制する方法を提供するべきです。 デフォルトで、データグラムのコピーは輪にし返されます。 これはグループの会員資格をホスト(ルーティング・プロトコルなどの)あたり1つのプロセスに制限するか、または、より高い層(マルチキャストトランスポート・プロトコルなどの)でグループコミュニケーションのループバックを扱う上側の層のプロトコルのためのパフォーマンスの最適化です。
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-目的地)
Deering [Page 5] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[5ページ]RFC1054はマルチキャスティング1988年5月に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, unless inhibited by the sender. (Level 2 implementations only.)
送付ホストがそれ自体で目的地グループのメンバーであるなら、地方の配送のために-逆で発信データグラムのコピーを輪にしなければなりません、送付者によって禁止されない場合。 (2つの実装だけを平らにしてください。)
A host group address should not be placed in the source address field or anywhere in a source routing option of an outgoing IP datagram.
ソースアドレス・フィールドか出発しているIPデータグラムのソースルーティングオプションで何処にもホストグループアドレスを置くべきではありません。
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 23-bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00 (hex). Because there are 28 significant bits in an IP host group address, more than one host group address may map to the same Ethernet multicast address.
IPホストグループアドレスはIP入賞するのによる下位の23ビットがイーサネットマルチキャストアドレス01-00-5E00-00-00(魔法をかける)の下位の23ビットに扱うイーサネットマルチキャストアドレスに写像されます。 重要な28ビットがIPホストにあるので、アドレスを分類してください、アドレスが同じイーサネットマルチキャストアドレスに写像するかもしれない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, may 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 may be mapped to a single local broadcast address (at the cost of increased overhead on all local hosts). For a point-to-point link joining two hosts (or a
直接マルチキャスティングをサポートするIEEE802.2規格に一致しているリングかバスなどの他のネットワークはマルチキャストIPデータグラムを送る目的のためのイーサネットとして同じように扱われるかもしれません。Experimentalイーサネットなどのマルチキャストではなく、サポートが放送するネットワークにおいて、すべてのIPホストグループアドレスがただ一つのローカル放送アドレス(すべてのローカル・ホストの上の増強されたオーバーヘッドの費用における)に写像されるかもしれません。 2人のホストに加わるポイントツーポイント接続、(a
Deering [Page 6] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[6ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
host and a multicast router), multicasts should be transmitted exactly like unicasts. For a store-and-forward network like the ARPANET or a public X.25 network, all IP host group addresses might be mapped to the well-known local address of an IP multicast router; a router 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サービスインタフェースへの拡大
Incoming multicast IP datagrams are received by upper-layer protocol modules using the same "Receive IP" operation as normal, unicast datagrams. Selection of a destination upper-layer protocol is based on the protocol field in the IP header, regardless of the destination IP address. However, before any datagrams destined to a particular group can be received, an upper-layer protocol must ask the IP module to join that group. Thus, the IP service interface must be extended to provide two new operations:
「IPを受けてください」という通常の同じ同じくらい操作を使用しながら、上側の層のプロトコルモジュールで入って来るマルチキャストIPデータグラムを受け取ります、ユニキャストデータグラム。目的地上側の層のプロトコルの選択はIPヘッダーのプロトコル分野に基づいています、送付先IPアドレスにかかわらず。 しかしながら、特定のグループに運命づけられたどんなデータグラムも受け取ることができる前に上側の層のプロトコルは、そのグループに加わるようにIPモジュールに頼まなければなりません。 したがって、2つの新しい操作を提供するためにIPサービスインタフェースを広げなければなりません:
JoinHostGroup ( group-address, interface )
JoinHostGroup(グループアドレス、インタフェース)
LeaveHostGroup ( group-address, interface )
LeaveHostGroup(グループアドレス、インタフェース)
The JoinHostGroup operation requests that this host become a member of the host group identified by "group-address" on the given network interface. The LeaveGroup operation requests that this host give up its membership in the host group identified by "group-address" on the given network interface. The interface argument may be omitted on hosts that may be attached to only one network. For hosts that may be attached to more than one network, the upper-layer protocol may choose to leave the interface unspecified, in which case the request will apply to the default interface for sending multicast datagrams (see section 6.1).
このホストが与えられたネットワークに関する「グループアドレス」によって特定されたホストグループのメンバーになるというJoinHostGroup操作要求は連結します。 このホストが与えられたネットワークに関する「グループアドレス」によって特定されたホストグループで会員資格をあきらめるというLeaveGroup操作要求は連結します。 インタフェース議論は1つのネットワークだけに配属されるかもしれないホストで省略されるかもしれません。 1つ以上のネットワークに配属されるかもしれないホストのために、上側の層のプロトコルは、インタフェースを不特定のままにするのを選ぶかもしれません、その場合、要求が送付マルチキャストデータグラムのためにデフォルトインタフェースに申し込まれるでしょう(セクション6.1を見てください)。
It is permissible to join the same group on more than one interface, in which case duplicate multicast datagrams may be received. It is also permissible for more than one upper-layer protocol to request membership in the same group.
1つ以上のインタフェースに関する同じグループに加わるのが許されている、その場合、写しマルチキャストデータグラムを受け取るかもしれません。 また、1つ以上の上側の層のプロトコルが同じグループで会員資格を要求するのも、許されています。
Both operations should return immediately (i.e., they are non- blocking operations), indicating success or failure. Either operation may fail due to an invalid group address or interface identifier. JoinHostGroup may fail due to lack of local resources. LeaveHostGroup may fail because the host does not belong to the given group on the given interface. LeaveHostGroup may succeed, but the membership persist, if more than one upper-layer protocol has requested membership in the same group.
成否を示して、両方の操作はすぐに(すなわち、それらはブロッキングの非操作である)、戻るべきです。 操作は無効のグループアドレスかインタフェース識別子のため失敗するかもしれません。 JoinHostGroupはローカル資源の不足のため失敗するかもしれません。 ホストが与えられたインタフェースに関する与えられたグループに属さないので、LeaveHostGroupは失敗するかもしれません。 LeaveHostGroupは成功するかもしれませんが、1つ以上の上側の層のプロトコルが同じグループで会員資格を要求したなら、会員資格は持続しています。
Deering [Page 7] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[7ページ]RFC1054はマルチキャスティング1988年5月に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 maintain a list of host group memberships associated with each network interface. An incoming datagram destined to one of those groups is processed exactly the same way as datagrams destined to one of the host's individual addresses.
マルチキャストIPデータグラムのレセプションをサポートするなら、ホストグループ会員資格のリストを各ネットワーク・インターフェースに関連しているのに維持するためにIPモジュールを広げなければなりません。 データグラムがずっとホストの個々のアドレスの1つに運命づけられて、それらのグループの1つに運命づけられた受信データグラムはまさに同じように処理されます。
Incoming datagrams destined to groups to which the host does not belong are discarded without generating any error report. 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. (These cases should occur only as a result of inadequate multicast address filtering in a local network module.)
どんなエラー・レポートも作らないで、ホストが属しないグループに運命づけられた受信データグラムは捨てられます。 データグラムがホストが異なったインタフェースだけで属するグループのために運命づけられた1つのネットワーク・インターフェースを通して届くなら1つ以上のネットワークに配属されるホストの上では、データグラムは静かに捨てられます。 (これらのケースは単に企業内情報通信網モジュールによる不十分なマルチキャストアドレスフィルタリングの結果、現れるはずです。)
An incoming datagram is not rejected for having an IP time-to-live of 1 (i.e., the time-to-live should not automatically be decremented on arriving datagrams that are not being forwarded). 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. 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.
受信データグラムは、1について生きるIP時間を持つために拒絶されません(生きるすなわち、時間は進められていない到着データグラムで自動的に減少するべきではありません)。 受信データグラムは、ソースアドレス・フィールドかソースルーティングオプションでどこでもIPホストグループアドレスを持つために拒絶されません。 ICMPエラーメッセージ(目的地Unreachable、Time Exceeded、Parameter Problem、Source Quench、またはRedirect)はIPホストグループに運命づけられたデータグラムに対応して決して生成されません。
The list of host group memberships is updated in response to JoinHostGroup and LeaveHostGroup requests from upper-layer protocols. Each membership should have an associated reference count or similar mechanism to handle multiple requests to join and leave the same group. On the first request to join and the last request to leave a group on a given interface, the local network module for that interface is notified, so that it may update its multicast reception filter (see section 7.3).
上側の層のプロトコルからのJoinHostGroupとLeaveHostGroup要求に対応してホストグループ会員資格のリストをアップデートします。 各会員資格には、同じグループに加わって、出るという複数の要求を扱う関連参照カウントか同様のメカニズムがあるべきです。 与えられたインタフェースに関するグループを出るという接合するという最初の要求と最後の要求のときに、そのインタフェースへの企業内情報通信網モジュールは通知されます、マルチキャストレセプションフィルタをアップデートできる(セクション7.3を見る)ように。
The IP module must also be extended to implement the IGMP protocol, specified in Appendix I. IGMP is used to keep neighboring multicast routers informed of the host group memberships present on a particular local network. To support IGMP, every level 2 host must join the "all-hosts" group (address 224.0.0.1) on each network interface at initialization time and must remain a member for as long as the host is active.
また、IGMPプロトコルを実装するためにIPモジュールを広げなければならなくて、Appendixで指定されて、I. IGMPは、ホストグループ会員資格において知識がある隣接しているマルチキャストルータを特定の企業内情報通信網に存在しているように保つのに使用されます。 IGMP、あらゆるレベル2をサポートするために、ホストが「オールホスト」グループに加わらなければならない、(アドレス、224.0、.0、.1、)、各ネットワークでは、ホストが活発である限り、メンバーは、初期化時に連結して、留まっていなければなりません。
(Datagrams addressed to the all-hosts group are recognized as a special case by the multicast routers and are never forwarded beyond a single network, regardless of their time-to-live. Thus, the all- hosts address may not be used as an internet-wide broadcast address. For the purpose of IGMP, membership in the all-hosts group is really necessary only while the host belongs to at least one other group.
オールホストグループに扱われたデータグラムを、特殊なものとしてマルチキャストルータで認識して、ただ一つのネットワークを超えて決して進めません、生きる彼らの時間にかかわらず。その結果、オールホストアドレスはインターネット全体の放送演説として使用されないかもしれません。(ホストは単に他の少なくとも1つのグループに属しますが、IGMPの目的に、オールホストグループにおける会員資格が本当に必要です。
Deering [Page 8] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[8ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
However, it is specified that the host shall remain a member of the all-hosts group at all times because (1) it is simpler, (2) the frequency of reception of unnecessary IGMP queries should be low enough that overhead is negligible, and (3) the all-hosts address may serve other routing-oriented purposes, such as advertising the presence of gateways or resolving local addresses.)
しかしながら、(1) それが、より簡単であるのでホストがいつもオールホストグループのメンバーのままで残るものとして、(2) 不要なIGMP質問のレセプションの頻度がオーバーヘッドが取るにたらないほど低いはずであり、(3) オールホストアドレスが広告などの他のルーティング指向の目的にゲートウェイかローカルのアドレスを決議する存在に役立つかもしれないと指定されます。)
7.3. Extensions to the Local Network Service Interface
7.3. 企業内情報通信網サービスインタフェースへの拡大
Incoming local network multicast packets are delivered to the IP module using the same "Receive Local" operation as local network unicast packets. To allow the IP module to tell the local network module which multicast packets to accept, the local network service interface is extended to provide two new operations:
入って来る企業内情報通信網マルチキャストパケットは、企業内情報通信網ユニキャストパケットと同じ「地方であることで、受信してください」操作を使用することでIPモジュールに提供されます。 IPモジュールが、どのマルチキャストパケットを受け入れたらよいかを企業内情報通信網モジュールに言うのを許容するなら、企業内情報通信網サービスインタフェースは2つの新しい操作を提供するために広げられます:
JoinLocalGroup ( group-address )
JoinLocalGroup(グループアドレス)
LeaveLocalGroup ( group-address )
LeaveLocalGroup(グループアドレス)
where "group-address" is an IP host group address. The JoinLocalGroup operation requests the local network module to accept and deliver up subsequently arriving packets destined to the given IP host group address. The LeaveLocalGroup operation requests the local network module to stop delivering up packets destined to the given IP host group address. The local network module is expected to map the IP host group addresses to local network addresses as required to update its multicast reception filter. Any local network module is free to ignore LeaveLocalGroup requests, and may deliver up packets destined to more addresses than just those specified in JoinLocalGroup requests, if it is unable to filter incoming packets adequately.
「グループアドレス」がIPホストであるところでは、アドレスを分類してください。 JoinLocalGroup操作は与えられたIPホストグループアドレスに運命づけられた次に到着しているパケットを受け入れて、引き渡すよう企業内情報通信網モジュールに要求します。 LeaveLocalGroup操作は、与えられたIPホストグループアドレスに運命づけられたパケットを引き渡すのを止めるよう企業内情報通信網モジュールに要求します。 企業内情報通信網モジュールがマルチキャストレセプションフィルタをアップデートするために必要に応じてIPホストグループアドレスを企業内情報通信網アドレスに写像すると予想されます。 どんな企業内情報通信網モジュールも、LeaveLocalGroup要求を無視するのにおいて自由であり、まさしくJoinLocalGroup要求で指定されたものより多くのアドレスに運命づけられたパケットを引き渡すかもしれません、適切に入って来るパケットをフィルターにかけることができないなら。
The local network module must not deliver up any multicast packets that were transmitted from that module; loopback of multicasts is handled at the IP layer or higher.
企業内情報通信網モジュールはそのモジュールから伝えられたどんなマルチキャストパケットも引き渡してはいけません。 マルチキャストのループバックはIP層においてより高く扱われます。
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 receives only those 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. Nevertheless, an implementation must be capable of
残念ながら、多くの現在のイーサネットインタフェースが認識するためにハードウェアを構成できるアドレスの数に小さい限界を持っています。 それにもかかわらず、実装はできなければなりません。
Deering [Page 9] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[9ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
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 point-to-point or store-and-forward networks, 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データグラムが企業内情報通信網ユニキャストとして届くので、企業内情報通信網モジュールへのどんな変化も必要であるべきではありません。
APPENDIX I. INTERNET GROUP MANAGEMENT PROTOCOL (IGMP)
付録I.インターネット集団経営プロトコル(IGMP)
The Internet Group Management Protocol (IGMP) is used by IP hosts to report their host group memberships to any immediately-neighboring multicast routers. IGMP is an asymmetric protocol and is specified here from the point of view of a host, rather than a multicast router. (IGMP may also be used, symmetrically or asymmetrically, between multicast routers. Such use is not specified here.)
インターネットGroup Managementプロトコル(IGMP)は、どんなすぐに隣接しているマルチキャストルータにも彼らのホストグループ会員資格を報告するのにIPホストによって使用されます。 IGMPは非対称のプロトコルであり、ここでマルチキャストルータよりむしろホストの観点から指定されます。 (また、IGMPはマルチキャストルータの間で対称か非対称的に使用されるかもしれません。 そのような使用はここで指定されません。)
Like ICMP, IGMP is a integral part of IP. It is required to be implemented 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 of concern to hosts 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Unused | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| タイプ| 未使用| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Deering [Page 10] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[10ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
Version
バージョン
This memo specifies version 1 of IGMP. Version 0 is specified
in RFC-988 and is now obsolete.
このメモはIGMPのバージョン1を指定します。 バージョン0は、RFC-988で指定されて、現在、時代遅れです。
Type
タイプ
There are two types of IGMP message of concern to hosts:
ホストにとって、重要なIGMPメッセージの2つのタイプがあります:
1 = Host Membership Query
2 = Host Membership Report
1 =ホスト会員資格質問2=ホスト会員資格レポート
Unused
未使用
Unused field, zeroed when sent, ignored when received.
受け取ると無視して、送ると合わせたゼロ未使用の分野。
Checksum
チェックサム
The checksum is the 16-bit one's complement of the one's
complement sum of the 8-octet IGMP message. For computing
the checksum, the checksum field is zeroed.
チェックサムは8八重奏のIGMPメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するのにおいて、チェックサム分野のゼロは合わせられています。
Group Address
グループアドレス
In a Host Membership Query message, the group address field
is zeroed when sent, ignored when received.
Host Membership Queryメッセージでは、受け取ると無視して、送ると、グループアドレス・フィールドのゼロを合わせます。
In a Host Membership Report message, the group address field
holds the IP host group address of the group being reported.
Host Membership Reportメッセージでは、グループアドレス・フィールドは報告されるグループのIPホストグループアドレスを保持します。
Informal Protocol Description
非公式のプロトコル記述
Multicast routers send Host Membership Query messages (hereinafter called Queries) to discover which host groups have members on their attached local networks. Queries are addressed to the all-hosts group (address 224.0.0.1), and carry an IP time-to-live of 1.
マルチキャストルータはどのホストグループにメンバーが彼らの付属企業内情報通信網にいるかを発見するメッセージ(以下に、Queriesと呼ばれる)をHost Membership Queryに送ります。 質問がオールホストグループに扱われる、(アドレス、224.0、.0、.1、)、1について生きるIP時間を運んでください。
Hosts respond to a Query by generating Host Membership Reports (hereinafter called Reports), reporting each host group to which they belong on the network interface from which the Query was received. In order to avoid an "implosion" of concurrent Reports and to reduce the total number of Reports transmitted, two techniques are used:
ホストはHost Membership Reports(以下に、Reportsと呼ばれる)を生成することによって、Queryに応じます、彼らがQueryが受け取られたネットワーク・インターフェースで属するそれぞれのホストグループを報告して。 同時発生のReportsの「内部破裂」を避けて、Reportsの総数を減少させるのは伝わって、2つのテクニックが使用されています:
1. When a host receives a Query, rather than sending Reports
immediately, it starts a report delay timer for each of its
group memberships on the network interface of the incoming
Query. Each timer is set to a different, randomly-chosen
value between zero and D seconds. When a timer expires, a
1. ホストがすぐにReportsを送るよりむしろQueryを受け取るとき、それはそれぞれのグループ会員資格のために入って来るQueryのネットワーク・インターフェースにレポートディレイタイマを始動します。 各タイマはゼロとD秒の間の異なって、手当たりしだいに選ばれた値へのセットです。 タイマが期限が切れると
Deering [Page 11] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[11ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
Report is generated for the corresponding host group. Thus,
Reports are spread out over a D second interval instead of
all occurring at once.
レポートは対応するホストグループのために作られます。 したがって、Reportsはすぐにすべて起こることの代わりにD2番目の間隔にわたって広げられます。
2. A Report is sent with an IP destination address equal to the
host group address being reported, and with an IP
time-to-live of 1, so that other members of the same group on
the same network can overhear the Report. If a host hears a
Report for a group to which it belongs on that network, the
host stops its own timer for that group and does not generate
a Report for that group. Thus, in the normal case, only one
Report will be generated for each group present on the
network, by the member host whose delay timer expires first.
Note that the multicast routers receive all IP multicast
datagrams, and therefore need not be addressed explicitly.
Further note that the routers need not know which hosts
belong to a group, only that at least one host belongs to a
group on a particular network.
2. 報告される、ホストグループアドレスと等しい受信者IPアドレス、および生きるIP時間と共に1についてReportを送ります、同じネットワークに関する同じグループの他のメンバーがReportを立ち聞きできるように。 ホストがそれがそのネットワークで属するグループに関してReportを聞くなら、ホストは、そのグループのためにそれ自身のタイマを止めて、そのグループのためにReportを生成しません。 したがって、正常な場合では、1Reportだけがネットワークの現在のそれぞれのグループのために生成されるでしょう、ディレイタイマが最初に期限が切れるメンバーホストで。 マルチキャストルータがすべてのIPマルチキャストデータグラムを受けて、したがって、明らかに扱われる必要はないことに注意してください。 ルータが、どのホストがグループに属すかを知る必要はなくて、少なくとも1人のホストが特定のネットワークに関するグループに属すだけであることにさらに注意してください。
There are two exceptions to the behavior described above. First, if a report delay timer is already running for a group membership when a Query is received, that timer is not reset to a new random value, but rather allowed to continue running with its current value. Second, a report delay timer is never set for a host's membership in the all- hosts group (224.0.0.1), and that membership is never reported.
上で説明された振舞いへの2つの例外があります。 まず最初に、Queryが受け取られているとき、レポートディレイタイマが既にグループ会員資格に立候補しているなら、そのタイマは、新しい無作為の値にリセットされませんが、現行価値と共にむしろ稼働し続けることができます。 2番目に、レポートディレイタイマが決してオールホストグループにおけるホストの会員資格のためのセットでない、(224.0 .0 .1) そして、会員資格は決して報告されません。
If a host uses a pseudo-random number generator to compute the reporting delays, one of the host's own individual IP address should be used as part of the seed for the generator, to reduce the chance of multiple hosts generating the same sequence of delays.
ホストが報告遅れを計算するのに疑似乱数生成器を使用するなら、ホストの自己の個々のIPアドレスの1つは、複数のホストが遅れの同じ系列を生成するという可能性を小さくするのにジェネレータのための種子の一部として使用されるべきです。
A host should confirm that a received Report has the same IP host group address in its IP destination field and its IGMP group address field, to ensure that the host's own Report is not cancelled by an erroneous received Report. A host should quietly discard any IGMP message of type other than Host Membership Query or Host Membership Report.
ホストは、容認されたReportがホストの自身のReportが誤った容認されたReportによって取り消されないのを保証するためにIPあて先フィールドとそのIGMPグループアドレス・フィールドに同じIPホストグループアドレスを持っていると確認するべきです。 ホストは静かにHost Membership QueryかHost Membership Report以外のタイプに関するどんなIGMPメッセージも捨てるべきです。
Multicast routers send Queries periodically to refresh their knowledge of memberships present on a particular network. If no Reports are received for a particular group after some number of Queries, the routers assume that that group has no local members and that they need not forward remotely-originated multicasts for that group onto the local network. Queries are normally sent infrequently (no more than once a minute) so as to keep the IGMP overhead on hosts and networks very low. However, when a multicast router starts up, it may issue several closely-space Queries in order to quickly build up its knowledge of local memberships.
マルチキャストルータは、特定のネットワークの現在の会員資格に関する彼らの知識をリフレッシュするために定期的にQueriesを送ります。 Queriesの何らかの数の後に特定のグループのためにReportsを全く受け取らないなら、ルータは、そのグループには地元会員が全くいないで、また彼らがどんな前進の離れて溯源されたマルチキャストも企業内情報通信網へのそのグループに必要としないと仮定します。 通常、ホストとネットワークのIGMPオーバーヘッドを非常に低く保つために質問をまれに(かつての1分だけ)送ります。 しかしながら、マルチキャストルータであるときに、上に、それが数個を発行するかもしれない始めは、急速に地方の会員資格に関する知識を確立するために密接にQueriesを区切ります。
Deering [Page 12] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[12ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
When a host joins a new group, it should immediately transmit a Report for that group, rather than waiting for a Query, in case it is the first member of that group on the network. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays. (A simple way to accomplish this is to act as if a Query had been received for that group only, setting the group's random report delay timer. The state transition diagram below illustrates this approach.)
ホストがすぐに新しいグループに加わるとき、そのグループのためにQueryを待っているよりむしろReportを伝えるべきです、それが第1代ネットワークに関するそのグループのメンバーであるといけないので。 なくされているか、または破損する初期のReportの可能性をカバーするために、それが少し遅れの後に一度か二度繰り返されるのは、お勧めです。 (これを達成する簡単な方法はまるでそのグループだけのためにQueryを受け取ったかのように行動することです、グループの無作為のレポートディレイタイマを設定して。 以下の状態遷移ダイヤグラムはこのアプローチを例証します。)
Note that, on a network with no multicast routers present, the only IGMP traffic is the one or more Reports sent whenever a host joins a new group.
唯一のIGMPトラフィックが存在しているマルチキャストルータのないネットワークのホストが新しいグループに加わるときはいつも、送られた1Reportsであることに注意してください。
State Transition Diagram
状態遷移ダイヤグラム
IGMP behavior is more formally specified by the state transition diagram below. A host may be in one of three possible states, with respect to any single IP host group on any single network interface:
IGMPの振舞いは以下の状態遷移ダイヤグラムで、より正式に指定されます。 ホストは3つの可能な州の1つにいるかもしれません、どんな単一のネットワーク・インターフェースに関するどんなただ一つのIPホストグループに関しても:
- Non-Member state, when the host does not belong to the group
on the interface. This is the initial state for all
memberships on all network interfaces; it requires no storage
in the host.
- ホストが属さないとき、非加盟国であり、インタフェースに関するグループに属してください。 これはすべてのネットワーク・インターフェースのすべての会員資格のための初期状態です。 それはホストでストレージを全く必要としません。
- Delaying Member state, when the host belongs to the group on
the interface and has a report delay timer running for that
membership.
- ホストがインタフェースに関するグループに属して、レポートディレイタイマをその会員資格に立候補させるとき、メンバー状態を遅らせます。
- Idle Member state, when the host belongs to the group on the
interface and does not have a report delay timer running for
that membership.
- メンバー状態を空費してください、ホストがインタフェースに関するグループに属して、レポートディレイタイマをその会員資格に立候補させないとき。
There are five significant events that can cause IGMP state transitions:
IGMPに状態遷移を引き起こす場合がある5回の重大な行事があります:
- "join group" occurs when the host decides to join the group on
the interface. It may occur only in the Non-Member state.
- ホストが、インタフェースに関するグループに加わると決めると、「グループに加わってください」は起こります。 それはNon-加盟国だけで起こるかもしれません。
- "leave group" occurs when the host decides to leave the group
on the interface. It may occur only in the Delaying Member
and Idle Member states.
- ホストが、インタフェースで仲間から抜けると決めると、「休暇は分類すること」が起こります。 それはDelayingメンバーとIdleメンバー州だけに起こるかもしれません。
- "query received" occurs when the host receives a valid IGMP
Host Membership Query message. To be valid, the Query message
must be at least 8 octets long and have a correct IGMP
checksum. A single Query applies to all memberships on the
interface from which the Query is received. It is ignored for
- ホストが有効なIGMP Host Membership Queryメッセージを受け取るとき、「質問は受信したこと」が起こります。 Queryメッセージは、長い間の少なくとも8つの八重奏であり、有効に、なるように正しいIGMPチェックサムを持たなければなりません。 独身のQueryはQueryが受け取られているインタフェースのすべての会員資格に適用します。 それは無視されます。
Deering [Page 13] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[13ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
memberships in the Non-Member or Delaying Member state.
Non-メンバーかDelayingメンバー状態の会員資格。
- "report received" occurs when the host receives a valid IGMP
Host Membership Report message. To be valid, the Report
message must be at least 8 octets long, have a correct IGMP
checksum, and contain the same IP host group address in its IP
destination field and its IGMP group address field. A Report
applies only to the membership in the group identified by the
Report, on the interface from which the Report is received.
It is ignored for memberships in the Non-Member or Idle Member
state.
- ホストが有効なIGMP Host Membership Reportメッセージを受け取るとき、「レポートは受信したこと」が起こります。 Reportメッセージは、IPあて先フィールドとそのIGMPグループアドレス・フィールドに長い間の少なくとも8つの八重奏であり、正しいIGMPチェックサムを持っていて、有効に、なるように同じIPホストグループアドレスを保管しなければなりません。 ReportはReportによって特定されたグループで会員資格だけに適用します、Reportが受け取られているインタフェースで。 それはNon-メンバーかIdleメンバー状態の会員資格のために無視されます。
- "timer expired" occurs when the report delay timer for the
group on the interface expires. It may occur only in the
Delaying Member state.
- インタフェースに関するグループのためのレポートディレイタイマが期限が切れると、「タイマは期限が切れたこと」が起こります。 それはDelayingメンバー状態だけに起こるかもしれません。
All other events, such as receiving invalid IGMP messages, or IGMP messages other than Query or Report, are ignored in all states.
QueryかReport以外の無効のIGMPメッセージ、またはIGMPメッセージを受け取ることなどの他のすべてのイベントがすべての州で無視されます。
There are three possible actions that may be taken in response to the above events:
上のイベントに対応して取られるかもしれない3つの可能な行動があります:
- "send report" for the group on the interface.
- インタフェースに関するグループのための「レポートを送ってください。」
- "start timer" for the group on the interface, using a random
delay value between 0 and D seconds.
- 無作為の遅れ値を0とD秒の間使用するインタフェースに関するグループのための「タイマを始動してください。」
- "stop timer" for the group on the interface.
- インタフェースに関するグループのための「タイマを止めてください。」
Deering [Page 14] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[14ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
In the following diagram, each state transition arc is labelled with the event that causes the transition, and, in parentheses, any actions taken during the transition.
以下のダイヤグラムで、それぞれの状態遷移アークはそして括弧(変遷の間に取られたどんな行動)で変遷を引き起こすイベントでラベルされます。
________________
| |
| |
| |
| |
--------->| Non-Member |<---------
| | | |
| | | |
| | | |
| |________________| |
| | |
| leave group | join group | leave group
| (stop timer) |(send report, |
| | start timer) |
________|________ | ________|________
| |<--------- | |
| | | |
| |<-------------------| |
| | query received | |
| Delaying Member | (start timer) | Idle Member |
| |------------------->| |
| | report received | |
| | (stop timer) | |
|_________________|------------------->|_________________|
timer expired
(send report)
________________ | | | | | | | | --------->| 非会員| <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|、|、|、|、|、| |________________| | | | | | グループを出てください。| グループに加わってください。| グループを出てください。| (停止タイマ) |(| | | レポート、スタートタイマを送ります) | ________|________ | ________|________ | | <、-、-、-、-、-、-、-、--、|、|、|、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 質問は受信されました。| | | メンバーを遅らせます。| (スタートタイマ) | 活動していないメンバー| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| レポートは受信されました。| | | | (停止タイマ) | | |_________________|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|_________________| タイマは期限が切れました。(レポートを送ります)
The all-hosts group (address 224.0.0.1) is handled as a special case. The host starts in Idle Member state for that group on every interface, never transitions to another state, and never sends a report for that group.
224.0を扱ってください。オールホストが分類する、(.0 .1は)特殊なものとして扱われます。 ホストは、あらゆるインタフェースに関するそのグループのためにIdleメンバー状態で始まって、別の状態に決して移行しないで、またそのグループのためにレポートを決して送りません。
Protocol Parameters
プロトコルパラメタ
The maximum report delay, D, is 10 seconds.
最大のレポート遅れ(D)は10秒です。
Deering [Page 15] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[15ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
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 routers do not need to maintain a list of individual members of each host group. For example, a multicast router 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 group source address may result in error reports being returned to all members of the group, not just the sender. In
しかしながら、インターネットワークの論理的なアドレシングのすべての問題を解決するのにホストグループアドレスを使用できません、“nearest"への配送やaの「最もロードされなかった」ネットワーク・インターフェースのようにマルチ、家へ帰り、ホスト。 その上、グループが実際に1人以上のホストを含むとデータグラムのソースアドレス・フィールドでグループアドレスを使用するのにおいて危険があります。 例えば、異なったソースアドレスを使用することでIPデータグラム再アセンブリアルゴリズムはすべてのホストに頼ります。 また、グループソースアドレスと共に送られたデータグラムの誤りは送付者だけではなく、グループのすべてのメンバーに返されるエラー・レポートをもたらすかもしれません。 コネ
Deering [Page 16] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[16ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
view of these hazards, this memo specifies the use of host group addresses only in the IP destination address field. However, it is recommended that datagrams with a group source address, or a group address as part of a source routing option, be accepted without complaint, thereby allowing other implementations to experiment with logical addressing applications of host group addresses.
これらの危険の視点、このメモは受信者IPアドレス分野だけでのホストグループアドレスの使用を指定します。 しかしながら、そのデータグラムはソースルーティングオプションの一部としてグループソースアドレス、またはグループアドレスでそれに推薦されます、苦情なしで受け入れられて、その結果、他の実装がホストグループアドレスの論理的なアドレシング応用を実験するのを許容します。
Allocation of Transient Host Group Addresses
一時的なホストグループアドレスの配分
This memo does not specify how transient group address are allocated. It is anticipated that different portions of the IP transient host group address space will be allocated using different techniques. For example, there may be a number of servers that can be contacted to acquire a new transient group address. Some higher-level protocols (such as VMTP, specified in RFC-1045) may generate higher- level transient "process group" or "entity group" addresses which are then algorithmically mapped to a subset of the IP transient host group addresses, similarly to the way that IP host group addresses are mapped to Ethernet multicast addresses. A portion of the IP group address space may be set aside for random allocation by applications that can tolerate occasional collisions with other multicast users, perhaps generating new addresses until a suitably "quiet" one is found.
このメモは、グループアドレスがどれくらい一時的であるかを割り当てた状態で指定しません。 IPの一時的なホストグループアドレス空間の異なった部分が異なったテクニックを使用することで割り当てられると予期されます。 例えば、新しい一時的なグループアドレスを習得するために連絡できる多くのサーバがあるかもしれません。 いくつかの上位レベル・プロトコル(RFC-1045で指定されたVMTPなどの)が、より高いレベルが次にalgorithmicallyに一時的なホストグループが同様にIPホストグループアドレスがイーサネットマルチキャストアドレスに写像される方法に演説するIPの部分集合に写像される一時的な「プロセスグループ」か「実体グループ」アドレスであると生成するかもしれません。 IPグループアドレス空間の部分は他のマルチキャストユーザとの時々の衝突を許容できるアプリケーションによる無作為の配分のためにかたわらに置かれるかもしれません、適当に「静かな」ものが見つけられるまで恐らく新しいアドレスを作って。
In general, a host cannot assume that datagrams sent to any host group address will reach only the intended hosts, or that datagrams received as a member of a transient host group are intended for the recipient. Misdelivery must be detected at a level above IP, using higher-level identifiers or authentication tokens. Information transmitted to a host group address should be encrypted or governed by administrative routing controls if the sender is concerned about unwanted listeners.
一般に、ホストは、どんなホストグループアドレスにも送られたデータグラムが意図しているホストだけに届くか、または一時的なホストグループのメンバーとして受け取られたデータグラムが受取人のために意図すると仮定できません。 よりハイレベルの識別子か認証トークンを使用して、IPの上にレベルで配達ミスを検出しなければなりません。 送付者が求められていないリスナーに関して心配しているなら、ホストグループアドレスに伝えられた情報は、管理ルーティングコントロールで暗号化されるべきであるか、または支配されるべきです。
APPENDIX III. CHANGES FROM RFC-988
付録III。 RFC-988からの変化
The IP multicast extensions specified in this memo are significantly different from those specified in RFC-988. Most of the changes are due to a shift of responsibility away from the multicast routers (called "multicast agents" in RFC-988) and onto the hosts. This new distribution of responsibility is consistent with the lightweight, soft-state gateway architecture of the Internet, and it allows the IP multicast services (in the same way as the IP unicast services) to be used among hosts on a single network when no router is up or present on the network. Thus, current single-network IP broadcast applications may be migrated to the use of IP multicast before multicast routers are widely available. The following changes are a consequence of this shift of responsibility:
このメモで指定されたIPマルチキャスト拡大はRFC-988で指定されたものとかなり異なっています。 変化の大部分はマルチキャストルータ(RFC-988に「マルチキャストエージェント」と呼ばれる)からの遠くとホストへの責任のシフトのためです。 責任のこの新しい分配はインターネットの軽量の、そして、柔らかい状態のゲートウェイアーキテクチャと一致していて、どんなルータもネットワークに上がらないで、また存在していないとき、それは、IPマルチキャストサービス(IPユニキャストサービスと同様に)がただ一つのネットワークでホストの中で利用されるのを許容します。 したがって、現在のただ一つのネットワークIP全面散布はわたられて、マルチキャストルータの前のIPマルチキャストの使用が広く利用可能であるということであるかもしれません。 以下の変化は責任のこのシフトの結果です:
Deering [Page 17] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[17ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
- Private hosts groups and access keys have been eliminated.
The multicast routers are no longer considered trustworthy
controllers of group membership; it is up to hosts and their
administrators to provide their own mechanisms to prevent
unwanted eavesdropping on group communication, perhaps by
using end-to-end encryption or by imposing restrictions on the
flow of IP multicast datagrams into and out of particular
administrative domains.
- 民間のホストグループとアクセスキーは排除されました。 マルチキャストルータはもうグループ会員資格の信頼できるコントローラであると考えられません。 グループコミュニケーションで求められていない盗聴を防ぐために恐らく終端間暗号化を使用するか、または制限をドメインの中と、そして、特定の管理ドメインからIPマルチキャストデータグラムの流れに課すことによってそれら自身のメカニズムを提供するのは、ホストと彼らの管理者次第です。
- The CreateHostGroup operation has been eliminated. The
responsibility for allocating transient host groups has been
moved from multicast routers to the hosts. See Appendix II
for a brief discussion of some ways in which hosts might do
their own transient group allocation.
- CreateHostGroup操作は省かれました。 一時的なホストグループを割り当てることへの責任はマルチキャストルータからホストまで動かされました。 ホストがそれら自身の一時的なグループ配分をするかもしれないいくつかの方法の簡潔な議論に関してAppendix IIを見てください。
- The JoinHostGroup and LeaveHostGroup operations have become
non-blocking, because it is no longer necessary to await
approval from a multicast router when changing membership. It
is also no longer possible for a host to have its membership
revoked by a multicast router.
- JoinHostGroupとLeaveHostGroup操作は非ブロッキングであるのになりました、会員資格を変えるとき、マルチキャストルータから承認を待つのがもう必要でないので。 また、ホストがマルチキャストルータで会員資格を取り消させるのももう可能ではありません。
- The IGMP protocol is substantially different from that in
RFC-988, reflecting the changed roles of hosts and multicast
routers.
- ホストとマルチキャストルータの変えられた役割を反映して、IGMPプロトコルはRFC-988でそれと実質的に異なっています。
- The new IGMP requires that there be an "all-hosts" group.
There is no longer a need for an "all-multicast-agents" group.
- 新しいIGMPは「オールホスト」がグループであったならそこでそれを必要とします。 もう、「オールマルチキャストエージェント」グループの必要がありません。
Other changes that are not related to the shift of responsibility are:
責任のシフトに関連しない他の変化は以下の通りです。
- The decision whether or not to loop back a multicast datagram
sent from a member of the destination group is now made at the
time the datagram is sent, rather than at the time the group
is joined. This gives the sender another degree of scope
control, beyond the IP time-to-live.
- グループが加わられる時代にというよりむしろデータグラムが送られる時代に今、目的地グループのメンバーから送られたマルチキャストデータグラムを輪にし返すかどうかという決定をします。 これは別の度合いの範囲支配力を送付者に生きるIP時間を超えたところまで与えます。
- The handling of IP time-to-live, and of multiple network
interfaces, has been more precisely specified.
- 生きるIP時間、および複数のネットワーク・インターフェースの取り扱いは、より正確に指定されました。
- Hosts are no longer allowed to place an IP host group address
in a source routing option.
- ホストはもうソースルーティングオプションにおけるIPホストグループアドレスを置くことができません。
- The AcceptAddress and RejectAddress operations at the local
network service interface have been renamed JoinLocalGroup and
LeaveLocalGroup to emphasize their semantic similarity to the
JoinHostGroup and LeaveHostGroup operations at the IP service
interface.
- 企業内情報通信網サービスインタフェースでのAcceptAddressとRejectAddress操作は、IPサービスインタフェースでのJoinHostGroupとLeaveHostGroup操作にそれらの意味類似性を強調するためにJoinLocalGroupとLeaveLocalGroupに改名されました。
Deering [Page 18] RFC 1054 Host Extensions for IP Multicasting May 1988
デアリング[18ページ]RFC1054はマルチキャスティング1988年5月にIPのために拡大を主催します。
- A new mapping algorithm for Ethernet multicast addresses has
been specified.
- イーサネットマルチキャストアドレスのための新しいマッピングアルゴリズムは指定されました。
- The organization of the memo has been changed somewhat, and a
state transition diagram has been added to the IGMP
specification.
- メモの組織をいくらか変えました、そして、状態遷移ダイヤグラムをIGMP仕様に追加しました。
Deering [Page 19]
デアリング[19ページ]
一覧
スポンサーリンク
