[要約] RFC 2226は、ATMネットワーク上でのIPブロードキャストに関する標準化されたプロトコルを提案しています。このRFCの目的は、IPネットワーク上でのブロードキャスト通信を効率的かつ信頼性の高い方法で実現することです。
Network Working Group T. Smith
Request for Comments: 2226 IBM Corporation
Category: Standards Track G. Armitage
Lucent Technologies
October 1997
IP Broadcast over ATM Networks
ATMネットワーク上のIPブロードキャスト
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
Abstract
概要
This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group.
このメモは、IP over ATMワーキンググループによって開発されているIPマルチキャストサービスを使用して、IPブロードキャスト伝送をサポートする方法を説明しています。解決策は、ブロードキャストの問題をマルチキャストの特殊なケースとして扱うことを中心に展開され、サブネットまたはクラスター内のすべてのホストがグループのメンバーになります。
An understanding of the services provided by RFC 2022 is assumed.
RFC 2022によって提供されるサービスを理解していることを前提としています。
1. Introduction.
1. 前書き。
The IETF's first step in solving the problems of running IP over Asynchronous Transfer Mode (ATM) technology is described in RFC 1577 [1]. It provides for unicast communication between hosts and routers within Logical IP Subnets (LISs), and proposes a centralized ATM ARP Server which provides IP to ATM address resolution services to LIS members.
IP over Asynchronous Transfer Mode（ATM）テクノロジを実行する際の問題を解決するIETFの最初のステップは、RFC 1577 [1]で説明されています。論理IPサブネット（LIS）内のホストとルーター間のユニキャスト通信を提供し、LISメンバーにIPからATMへのアドレス解決サービスを提供する集中型ATM ARPサーバーを提案します。
Two classes of IP service were omitted - multicast and broadcast transmissions. Multicasting allows a single transmit operation to cause a packet to be received by multiple remote destinations.
IPサービスの2つのクラスが省略されました-マルチキャストおよびブロードキャスト送信。マルチキャストを使用すると、1回の送信操作でパケットを複数のリモート宛先に受信させることができます。
Broadcasting typically allows a single transmit operation to cause a packet to be received by all IP hosts that are members of a particular 'subnet'.
ブロードキャストでは、通常、単一の送信操作により、特定の「サブネット」のメンバーであるすべてのIPホストでパケットを受信できます。
To address the need for multicast support (represented by transmission to IP addresses in the Class D space), RFC 2022 ("Support for Multicast over UNI 3.0/3.1 based ATM Networks") [2] was created. This memo creates an analog of the RFC 1577 ARP Server - a new entity known as the MARS (Multicast Address Resolution Server). The MARS operates as a centralized registry and distribution mechanism for mappings between IP multicast addresses and groups of ATM unicast addresses. Host behavior is also defined for establishing and managing point to multipoint VCs, based on the information returned by the MARS, when hosts wish to transmit packets to a multicast group.
マルチキャストサポート（クラスDスペースのIPアドレスへの送信で表される）の必要性に対処するために、RFC 2022（「UNI 3.0 / 3.1ベースのATMネットワークでのマルチキャストのサポート」）[2]が作成されました。このメモは、RFC 1577 ARPサーバーの類似物、MARS（マルチキャストアドレス解決サーバー）として知られる新しいエンティティを作成します。 MARSは、IPマルチキャストアドレスとATMユニキャストアドレスのグループ間のマッピングのための集中型レジストリおよび配布メカニズムとして動作します。ホストの動作は、ホストがマルチキャストグループにパケットを送信するときに、MARSから返された情報に基づいて、ポイントツーマルチポイントVCを確立および管理するためにも定義されています。
This memo aims to show how RFC 2022 may be used to emulate IP broadcast within Logical IP Subnets. While the broadcast technique does not align itself well with the underlying point-to-point nature of ATM, clearly, some applications will still wish to use IP broadcasts. Client-server applications where the client searches for a server by sending out a broadcast is one scenario. Routing protocols, most notably RIP, are other examples.
このメモは、RFC 2022を使用して論理IPサブネット内のIPブロードキャストをエミュレートする方法を示すことを目的としています。ブロードキャスト技術は、ATMの基本的なポイントツーポイントの性質とうまく整合していませんが、一部のアプリケーションは依然としてIPブロードキャストの使用を希望しています。クライアントがブロードキャストを送信してサーバーを検索するクライアントサーバーアプリケーションは、1つのシナリオです。ルーティングプロトコル、特にRIPは他の例です。
2. Review of Unicast and Multicast.
2. ユニキャストとマルチキャストのレビュー。
Both the unicast and multicast cases take advantage of the point-to-point and point-to-multipoint capabilities defined in the ATM Forum UNI 3.1 document [4]. A unicast IP address has a single ATM level destination. Unicast transmissions occur over point to point Virtual Channels (VCs) between the source and destination. The ARP Server holds mappings between IP destination addresses and their associated ATM destination address. Hosts issue an ARP_REQUEST to the ARP Server when they wish to ascertain a particular mapping. The ARP Server replies with either an ARP_REPLY containing the ATM address of the destination, or an ARP_NAK when the ARP Server is unable to resolve the address. If the request is successful the host establishes a VC to the destination interface. This VC is then used to forward the first (and subsequent) packets to that particular IP destination. RFC 1577 describes in further detail how hosts are administratively grouped in to Logical IP Subnets (LISs), and how the ARP Server establishes the initial mappings for members of the LIS it serves.
ユニキャストとマルチキャストのどちらの場合も、ATMフォーラムUNI 3.1ドキュメント[4]で定義されているポイントツーポイントおよびポイントツーマルチポイント機能を利用します。ユニキャストIPアドレスには、ATMレベルの宛先が1つあります。ユニキャスト送信は、送信元と宛先の間でポイントツーポイントの仮想チャネル（VC）を介して行われます。 ARPサーバーは、IP宛先アドレスとそれに関連付けられたATM宛先アドレス間のマッピングを保持します。ホストは、特定のマッピングを確認するときに、ARPサーバーにARP_REQUESTを発行します。 ARPサーバーは、宛先のATMアドレスを含むARP_REPLY、またはARPサーバーがアドレスを解決できない場合はARP_NAKのいずれかで応答します。要求が成功すると、ホストは宛先インターフェイスへのVCを確立します。次に、このVCを使用して、最初の（および後続の）パケットをその特定のIP宛先に転送します。 RFC 1577は、ホストが管理上論理IPサブネット（LIS）にグループ化される方法、およびARPサーバーがサービスするLISのメンバーの初期マッピングを確立する方法をさらに詳しく説明しています。
The basic host behavior for multicasting is similar - the sender must establish and manage a point to multipoint VC whose leaf nodes are the group's actual members. Under UNI 3.1 these VCs can only be established and altered by the source (root) interface.
マルチキャストの基本的なホストの動作は同様です。送信側は、リーフノードがグループの実際のメンバーであるポイントツーマルチポイントVCを確立して管理する必要があります。 UNI 3.1では、これらのVCはソース（ルート）インターフェースによってのみ確立および変更できます。
The MARS is an evolution of the ARP Server model, and performs two key functions. The first function is the maintenance of a list of ATM addresses corresponding to the members for each group. This list is created by a host registration process which involves two messages - a MARS_JOIN which declares that a host wishes to join the specified group(s), and a MARS_LEAVE which indicates that a host wishes to leave the specified group(s).
MARSはARPサーバーモデルの進化形であり、2つの主要な機能を実行します。最初の機能は、各グループのメンバーに対応するATMアドレスのリストの保守です。このリストは、2つのメッセージを含むホスト登録プロセスによって作成されます。ホストが指定されたグループへの参加を希望していることを宣言するMARS_JOINと、ホストが指定されたグループからの離脱を希望していることを示すMARS_LEAVEです。
MARS_JOIN and MARS_LEAVE messages are also redistributed to all members of the group so that active senders may dynamically adjust their point to multipoint VCs accordingly.
MARS_JOINおよびMARS_LEAVEメッセージもグループのすべてのメンバーに再配布されるため、アクティブな送信者はポイントツーマルチポイントVCを動的に調整できます。
The other major function is the retrieval of group membership from MARS (analogous to the ARP Server providing unicast address mappings). When faced with the need to transmit an IP packet with a Class D destination address, a host issues a MARS_REQUEST to the MARS. If the group has members the MARS returns a MARS_MULTI (possibly in multiple segments) carrying a set of ATM addresses. The host then establishes an initial point to multipoint VC using these ATM addresses as the leaf nodes. If the MARS had no mapping it would return a MARS_NAK.
その他の主な機能は、MARSからのグループメンバーシップの取得です（ユニキャストアドレスマッピングを提供するARPサーバーに類似）。クラスDの宛先アドレスを持つIPパケットを送信する必要がある場合、ホストはMARS_REQUESTをMARSに発行します。グループにメンバーがいる場合、MARSは、ATMアドレスのセットを運ぶMARS_MULTI（おそらく複数のセグメントで）を返します。次に、ホストは、これらのATMアドレスをリーフノードとして使用して、初期のポイントツーマルチポイントVCを確立します。 MARSにマッピングがない場合、MARS_NAKが返されます。
(RFC 2022 also discusses how the MARS can arrange for Class D groups to be supported by either multicast servers, or meshes of point to multipoint VCs from host to host. However, from the host's perspective this is transparent, and is not central to this discussion of IP broadcast support.)
（RFC 2022では、MARSがクラスDグループをマルチキャストサーバー、またはホストからホストへのポイントツーマルチポイントVCのメッシュでサポートする方法についても説明しています。ただし、ホストの観点からは、これは透過的であり、これの中心ではありません。 IPブロードキャストサポートの説明）。
This memo describes how a host may utilize the registration and group management functions in an existing MARS based IP/ATM network to emulate IP broadcasts.
このメモは、ホストが既存のMARSベースのIP / ATMネットワークで登録およびグループ管理機能を利用してIPブロードキャストをエミュレートする方法を説明しています。
3. Broadcast as a special case of Multicast.
3. マルチキャストの特殊なケースとしてのブロードキャスト。
Many of the problems that occur when implementing a broadcast solution also occur in when implementing a multicast solution. In fact, broadcast may be considered a special case of multicast. That is, broadcast is a multicast group whose members include all members in the LIS.
ブロードキャストソリューションの実装時に発生する問題の多くは、マルチキャストソリューションの実装時にも発生します。実際、ブロードキャストはマルチキャストの特殊なケースと見なされる場合があります。つまり、ブロードキャストは、LISのすべてのメンバーを含むマルチキャストグループです。
There are two broadcast groups which this memo addresses:
このメモが対処する2つのブロードキャストグループがあります。
1) 255.255.255.255 - "All ones" broadcast
1）255.255.255.255-「すべて1」のブロードキャスト
2) x.z - CIDR-prefix (subnet) directed broadcast
2）x.z-CIDRプレフィックス（サブネット）ダイレクトブロードキャスト
Broadcast (1) is sometimes referred to as a limited broadcast to this physical network. Broadcast (2) can be thought of as the the broadcast for subnets or networks in the old paradigm. As described in [6] and [7], the notion of subnets and networks is being replaced with a more efficient utilization of the routing address space known as Classless Inter-Domain Routing. The CIDR-prefix (x) is the combination of IP address and subnet mask that denotes the subnet number. The host portion of the address (z) is all ones. One should note that while these broadcasts have different scopes at the IP or network layer, they have precisely the same scope at the link layer -- namely that all members of the LIS will receive a copy.
ブロードキャスト（1）は、この物理ネットワークへの制限付きブロードキャストと呼ばれることもあります。ブロードキャスト（2）は、古いパラダイムのサブネットまたはネットワークのブロードキャストと考えることができます。 [6]と[7]で説明されているように、サブネットとネットワークの概念は、クラスレスドメイン間ルーティングと呼ばれるルーティングアドレス空間のより効率的な利用に置き換えられています。 CIDRプレフィックス（x）は、IPアドレスとサブネット番号を示すサブネットマスクの組み合わせです。アドレス（z）のホスト部分はすべて1です。これらのブロードキャストのスコープはIPまたはネットワークレイヤーで異なりますが、リンクレイヤーでもスコープはまったく同じです。つまり、LISのすべてのメンバーがコピーを受信します。
These addresses may be used in two environments:
これらのアドレスは、次の2つの環境で使用できます。
o Broadcasting to all members of a given LIS where a priori knowledge of a host's IP address and subnet mask are known (e.g. the CIDR-prefix directed broadcast).
o ホストのIPアドレスとサブネットマスクに関する事前の知識がわかっている特定のLISのすべてのメンバーへのブロードキャスト（CIDRプレフィックスのダイレクトブロードキャストなど）。
o Broadcasting to all members of a physical network without knowledge of a host's IP address and subnet mask (e.g. the all ones broadcast).
o ホストのIPアドレスとサブネットマスクを知らずに、物理ネットワークのすべてのメンバーにブロードキャストする（たとえば、すべてのブロードキャスト）。
On a broadcast medium like Ethernet, these two environments result in the same physical destination. That is, all stations on that network will receive the broadcast even if they are on different logical subnets, or are non-IP stations. With ATM, this may not be the case. Because ATM is non-broadcast, a registration process must take place. And if there are stations that register to some broadcast groups, but not others, then the different broadcast groups will have different memberships. The notion of broadcast becomes inconsistent.
イーサネットなどのブロードキャストメディアでは、これら2つの環境は同じ物理的送信先になります。つまり、そのネットワーク上のすべてのステーションは、それらが異なる論理サブネット上にある場合、または非IPステーションであっても、ブロードキャストを受信します。 ATMでは、これは当てはまらない場合があります。 ATMは非ブロードキャストであるため、登録プロセスを実行する必要があります。また、一部の放送グループに登録され、他の放送グループには登録されていないステーションがある場合、放送グループごとにメンバーシップが異なります。放送の概念に一貫性がなくなります。
One case that requires the use of the all ones broadcast is that of the diskless boot, or bootp client, where the host boots up, and does not know its own IP address or subnet mask. Clearly, the host does not know which subnet it belongs to. So, to send a broadcast to its bootp server, the diskless workstation must use the group which contains no subnet information, i.e. the 255.255.255.255 broadcast group. Carrying the example a little further, the bootp server, after receiving the broadcast, can not send either a directed frame nor a subnet directed broadcast to respond to the diskless workstation. Instead, the bootp server must also use the 255.255.255.255 group to communicate with the client.
すべて1のブロードキャストを使用する必要がある1つのケースは、ホストが起動し、独自のIPアドレスまたはサブネットマスクを知らない、ディスクレスブートまたはbootpクライアントの場合です。明らかに、ホストはどのサブネットに属しているかがわかりません。したがって、bootpサーバーにブロードキャストを送信するには、ディスクレスワークステーションは、サブネット情報を含まないグループ、つまり255.255.255.255ブロードキャストグループを使用する必要があります。この例をもう少し進めると、bootpサーバーは、ブロードキャストを受信した後、ダイレクトフレームもサブネットダイレクトブロードキャストも送信せず、ディスクレスワークステーションに応答できません。代わりに、bootpサーバーはクライアントと通信するために255.255.255.255グループも使用する必要があります。
While the all ones broadcast is required at the IP layer, it also has relevance at the link layer when deciding which broadcast group to register with in MARS. In other words, a bootp client wishing to register for a link layer broadcast, can only register for 255.255.255.255 in the MARS address space because the client's subnet is unknown at the time. Given that some applications must use the all ones address in MARS for their broadcast group, and that we wish to minimize the number of broadcast groups used by LIS members, the all ones group in MARS MUST be used by all members of the LIS when registering to receive broadcast transmissions. The VCC used for transmitting any broadcast packet will be based on the members registered in the MARS under the 255.255.255.255 address position. This VCC will be referred to as the "broadcast channel" through the remainder of this memo.
すべて1のブロードキャストはIPレイヤーで必要ですが、MARSに登録するブロードキャストグループを決定するときにリンクレイヤーにも関連があります。つまり、リンクレイヤブロードキャストに登録するbootpクライアントは、クライアントのサブネットがその時点で不明であるため、MARSアドレス空間で255.255.255.255にしか登録できません。一部のアプリケーションは、MARSのall onesアドレスをブロードキャストグループに使用する必要があり、LISメンバーが使用するブロードキャストグループの数を最小限にしたい場合、MARSのall onesグループは、登録時にLISのすべてのメンバーが使用する必要がありますブロードキャスト送信を受信します。ブロードキャストパケットの送信に使用されるVCCは、255.255.255.255アドレス位置でMARSに登録されたメンバーに基づいています。このVCCは、このメモの残りの部分では「ブロードキャストチャネル」と呼ばれます。
4. The MARS role in broadcast.
4. 放送におけるMARSの役割。
Many solutions have been proposed, some of which are listed in Appendix A. This memo addresses a MARS solution which appears to do the best job of solving the broadcast problem.
多くのソリューションが提案されており、そのうちのいくつかは付録Aにリストされています。このメモは、ブロードキャストの問題を解決するのに最適なMARSソリューションを取り上げています。
There are a number of characteristics of the MARS architecture that should be kept intact. They include:
MARSアーキテクチャには、そのまま維持する必要のあるいくつかの特性があります。以下が含まれます：
o MARS contains no knowledge of subnet prefixes and subnet masks. Each group address registered with MARS is managed independently.
o MARSには、サブネットプレフィックスとサブネットマスクに関する知識はありません。 MARSに登録された各グループアドレスは、個別に管理されます。
o A MARS may only serve one LIS. This insures that the broadcast group 255.255.255.255 is joined by hosts from one LIS, keeping its scope bound to conventional interpretation.
o MARSは1つのLISのみを処理できます。これにより、ブロードキャストグループ255.255.255.255が1つのLISからのホストによって結合され、そのスコープが従来の解釈にバインドされたままになります。
o The Multicast Server (MCS) described in [2] may be used to service the broadcast groups defined in this memo without modification. The MCS will reduce the number of channels used by the network.
o [2]で説明されているマルチキャストサーバー（MCS）を使用して、このメモで定義されているブロードキャストグループに変更を加えることなくサービスを提供できます。 MCSは、ネットワークで使用されるチャネルの数を減らします。
The MARS needs no additional code or special algorithms to handle the resolution of IP broadcast addresses. It is simply a general database that holds {Protocol address, ATM.1, ATM.2, ... ATM.n} mappings, and imposes no constraints on the type and length of the 'Protocol address'. Whether the hosts view it as Class D or 'broadcast' (or even IP) is purely a host side issue.
MARSは、IPブロードキャストアドレスの解決を処理するために、追加のコードや特別なアルゴリズムを必要としません。これは、{プロトコルアドレス、ATM.1、ATM.2、... ATM.n}マッピングを保持する一般的なデータベースであり、「プロトコルアドレス」のタイプと長さに制約を課しません。ホストがそれをクラスDまたは「ブロードキャスト」（またはIP）と見なすかどうかは、純粋にホスト側の問題です。
It is likely that end points will want to use the IP broadcast emulation described here in order to support boot time location of the end point's IP address. This leads to the observation that the MARS should NOT expect to see both the IP source and ATM source address fields of the MARS_JOIN filled in. This is reasonable, since only the ATM source address is used when registering the end point as a group member.
エンドポイントは、エンドポイントのIPアドレスの起動時の場所をサポートするために、ここで説明するIPブロードキャストエミュレーションを使用する可能性があります。これにより、MARSは、MARS_JOINのIP送信元フィールドとATM送信元アドレスフィールドの両方が入力されることを期待してはならないという観察につながります。エンドポイントをグループメンバーとして登録するときに、ATM送信元アドレスのみが使用されるため、これは妥当です。
The MARS architecture is sufficient to insure the integrity of the broadcast group list without any modification.
MARSアーキテクチャは、変更することなくブロードキャストグループリストの整合性を保証するのに十分です。
5. Host Requirements for Broadcast.
5. ブロードキャストのホスト要件。
The following list of bullets describes additional characteristics of a MARS-compliant host. These characteristics are required to take advantage of the broadcast function.
次の箇条書きのリストは、MARS準拠ホストの追加の特性について説明しています。これらの特性は、ブロードキャスト機能を利用するために必要です。
o A host must register as a MARS client.
o ホストはMARSクライアントとして登録する必要があります。
o A host, soon after registration MUST issue a MARS_JOIN to the all ones broadcast address (i.e. 255.255.255.255) with the mar$flags.layer3grp reset.
o ホストは、登録直後に、mar $ flags.layer3grpをリセットして、MARS_JOINをすべて1のブロードキャストアドレス（つまり、255.255.255.255）に発行する必要があります。
o When transmitting packets, the host should map all IP layer broadcasts to the VCC (broadcast channel) created and maintained based on the all ones entry in MARS.
o パケットを送信するとき、ホストはすべてのIPレイヤーブロードキャストを、MARS内のすべて1のエントリに基づいて作成および維持されるVCC（ブロードキャストチャネル）にマップする必要があります。
o A host MUST monitor the MARS_JOIN/MARS_LEAVE messages for 255.255.255.255 to keep the broadcast channel current.
o ホストは、MARS_JOIN / MARS_LEAVEメッセージで255.255.255.255を監視して、ブロードキャストチャネルを最新に保つ必要があります。
o A broadcast channel should be torn down after a period of inactivity. The corresponding timeout period MAY be specified with a minimum value of one minute, and a RECOMMENDED default value of 20 minutes.
o ブロードキャストチャネルは、非アクティブ状態が一定期間続いた後に破棄する必要があります。対応するタイムアウト期間は、最小値1分、推奨されるデフォルト値20分で指定できます。
One should note that while every member participating in the broadcast MUST be a member of the all ones group, not all members will choose to transmit broadcast information. Some members will only elect to receive broadcast information passively. Therefore, in a LIS with n stations, there may be less than n channels terminated at each station for broadcast information. Further reductions may be gained by adding a Multicast Server (MCS) to the broadcast environment which could reduce the number of VCs to two (one incoming, one outgoing), or one for a station that only wishes to listen.
ブロードキャストに参加しているすべてのメンバーはオールワングループのメンバーである必要がありますが、すべてのメンバーがブロードキャスト情報の送信を選択するわけではないことに注意してください。一部のメンバーは、放送情報を受動的に受信することのみを選択します。したがって、nステーションのLISでは、ブロードキャスト情報のために各ステーションで終了するチャネルがn未満になる場合があります。マルチキャストサーバー（MCS）をブロードキャスト環境に追加すると、VCの数を2つ（1つは受信、1つは送信）、または1つだけを聴きたいステーション用に減らすことができるため、さらに削減できます。
It is well understood that broadcasting in this environment may tax the resources of the network and of the hosts that use it. Therefore, an implementer MAY choose to provide a mechanism for retracting the host's entry in the broadcast group after it has been established or prior to joining the group. The MARS_LEAVE is used to request withdrawal from the group if the host wishes to disable broadcast reception after it has joined the group. The default behavior SHALL be to join the all ones broadcast group in MARS.
この環境でのブロードキャストは、ネットワークとそれを使用するホストのリソースに負荷をかける可能性があることはよく理解されています。したがって、実装者は、ブロードキャストグループが確立された後、またはグループに参加する前に、ブロードキャストグループ内のホストのエントリを撤回するメカニズムを提供することを選択できます（MAY）。 MARS_LEAVEは、ホストがグループに参加した後でブロードキャストの受信を無効にする場合に、グループからの撤退を要求するために使用されます。デフォルトの動作は、MARSのAll Onesブロードキャストグループに参加する必要があります。
6. Implications of IP broadcast on ATM level resources.
6. ATMレベルのリソースに対するIPブロードキャストの影響。
RFC 2022 discusses some of the implications of large multicast groups on the allocation of ATM level resources, both within the network and within end station ATM interfaces.
RFC 2022は、ネットワーク内と端末のATMインターフェイス内の両方で、ATMレベルのリソースの割り当てに対する大規模なマルチキャストグループの影響のいくつかについて説明しています。
The default mechanism is for IP multicasting to be achieved using meshes of point to multipoint VCs, direct from source host to group members. Under certain circumstances system administrators may, in a manner completely transparent to end hosts, redirect multicast traffic through ATM level Multicast Servers (MCSs). This may be performed on an individual group basis.
デフォルトのメカニズムは、ソースホストからグループメンバーに直接向かうポイントツーマルチポイントVCのメッシュを使用してIPマルチキャストを実現することです。特定の状況下では、システム管理者は、エンドホストに対して完全に透過的な方法で、ATMレベルのマルチキャストサーバー（MCS）を介してマルチキャストトラフィックをリダイレクトできます。これは、個々のグループごとに実行できます。
It is sufficient to note here that the IP broadcast 'multicast group' will constitute the largest consumer of VCs within your ATM network when it is active. For this reason it will probably be the first multicast group to have one or more ATM MCSs assigned to support it. However, there is nothing unique about an MCS assigned to support IP broadcast traffic, so this will not be dealt with further in this memo. RFC 2022 contains further discussion on the possible application of multiple MCSs to provide fault-tolerant architectures.
ここで、IPブロードキャストの「マルチキャストグループ」がアクティブな場合、ATMネットワーク内のVCの最大のコンシューマーを構成することに注意してください。このため、おそらくそれをサポートするために割り当てられた1つ以上のATM MCSを持つ最初のマルチキャストグループになります。ただし、IPブロードキャストトラフィックをサポートするために割り当てられたMCSに固有のものはないため、このメモではこれについては扱いません。 RFC 2022には、フォールトトレラントアーキテクチャを提供するための複数のMCSの可能なアプリケーションに関する詳細な説明が含まれています。
7. Further discussion.
7. さらなる議論。
A point of discussion on the ip-atm forum revolved around "auto configuration" and "diskless boot". This memo describes a broadcast solution that requires the use of the MARS. Therefore, at a minimum, the ATM address of the MARS must be manually configured into a diskless workstation. Suggestions such as universal channel numbers, and universal ATM addresses have been proposed, however, no agreement has been reached.
ip-atmフォーラムでの議論のポイントは、「自動構成」と「ディスクレスブート」を中心に展開されました。このメモは、MARSの使用を必要とするブロードキャストソリューションについて説明しています。したがって、最低でも、MARSのATMアドレスをディスクレスワークステーションに手動で構成する必要があります。ユニバーサルチャネル番号やユニバーサルATMアドレスなどの提案が提案されていますが、合意には至っていません。
Another topic for discussion is multiprotocol support. MARS is designed for protocol independence. This memo specifically addresses the IP broadcast case, identifying which addresses are most effective in the IP address space. However, the principles apply to any layer 3 protocol. Further work should be performed to identify suitable addresses for other layer 3 protocols.
議論のもう1つのトピックは、マルチプロトコルのサポートです。 MARSはプロトコルに依存しないように設計されています。このメモは特にIPブロードキャストのケースに対処し、IPアドレス空間で最も効果的なアドレスを特定します。ただし、原則はどのレイヤー3プロトコルにも適用されます。他のレイヤ3プロトコルに適したアドレスを特定するには、さらに作業を行う必要があります。
Finally, there has been support voiced for a link layer broadcast that would be independent of the layer 3 protocol. Such a solution may provide a simpler set of rules through which broadcast applications may be used. In addition, some solutions also provide for more efficient use of VCCs.
最後に、レイヤー3プロトコルに依存しないリンクレイヤーブロードキャストのサポートがありました。このようなソリューションは、ブロードキャストアプリケーションを使用できるルールのよりシンプルなセットを提供します。さらに、いくつかのソリューションは、VCCのより効率的な使用を提供します。
Security Considerations
セキュリティに関する考慮事項
This memo addresses a specific use of the MARS architecture and components to provide the broadcast function. As such, the security implications are no greater or less than the implications of using any of the other multicast groups available in the multicast address range. Should enhancements to security be required, they would need to be added as an extension to the base architecture in RFC 2022.
このメモは、ブロードキャスト機能を提供するためのMARSアーキテクチャとコンポーネントの特定の使用法について説明しています。そのため、セキュリティへの影響は、マルチキャストアドレス範囲で使用可能な他のマルチキャストグループを使用する場合の影響と同じかそれ以上です。セキュリティの強化が必要な場合は、RFC 2022の基本アーキテクチャの拡張として追加する必要があります。
Acknowledgments
謝辞
The apparent simplicity of this memo owes a lot to the services provided in [2], which itself is the product of much discussion on the IETF's IP-ATM working group mailing list. Grenville Armitage worked on this document while at Bellcore.
このメモの見かけ上の単純さは、[2]で提供されるサービスに大きく起因しています。これは、IETFのIP-ATMワーキンググループメーリングリストでの多くの議論の産物です。グレンビルアーミテージは、ベルコアにいる間、この文書に取り組みました。
References
参考文献
[1] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, December 1993.
[1] Laubach、M。、「Classical IP and ARP over ATM」、RFC 1577、1993年12月。
[2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks", RFC 2022, November 1995.
[2] アーミテージ、G。、「UNI 3.0 / 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、1995年11月。
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[3] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.
[4] ATMフォーラム、「ATM User-Network Interface Specification Version 3.0」、Englewood Cliffs、NJ：Prentice Hall、1993年9月。
[5] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E. and A. Malis, "ATM Signaling Support for IP over ATM", RFC 1755, February 1995.
[5] Perez、M.、Liaw、F.、Grossman、D.、Mankin、A.、Hoffman、E。、およびA. Malis、「ATM Signaling Support for IP over ATM」、RFC 1755、1995年2月。
[6] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[6] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「Classless Inter-Domain Routing（CIDR）：a Address Assignment and Aggregation Strategy」、RFC 1519、1993年9月。
[7] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[7] ベイカー、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997.
[8] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード、BCP 14、RFC 2119、1997年3月。
Authors' Addresses
著者のアドレス
Timothy J. Smith Network Routing Systems, International Business Machines Corporation. N21/664 P.O.Box 12195 Research Triangle Park, NC 27709
Timothy J. Smithネットワークルーティングシステム、International Business Machines Corporation。 N21 / 664 P.O. Box 12195 Research Triangle Park、NC 27709
Phone: (919) 254-4723 EMail: tjsmith@vnet.ibm.com
電話：（919）254-4723メール：tjsmith@vnet.ibm.com
Grenville Armitage Bell Labs, Lucent Technologies. 101 Crawfords Corner Rd, Holmdel, NJ, 07733
グレンビルアーミテージベルラボ、ルーセントテクノロジー。 101 Crawfords Corner Rd、Holmdel、NJ、07733
EMail: gja@lucent.com
Throughout the development of this memo, there have been a number of alternatives explored and discarded for one reason or another. This appendix documents these alternatives and the reason that they were not chosen.
このメモの作成を通じて、いくつかの理由で調査され、破棄された代替案がいくつかあります。この付録では、これらの選択肢と、それらが選択されなかった理由について説明します。
A.1 ARP Server Broadcast Solutions.
A.1 ARPサーバーブロードキャストソリューション。
The ARP Server is a good candidate to support broadcasting. There is an ARP Server for every LIS. The ARP Server contains the entire LIS membership. These are fundamental ingredients for the broadcast function.
ARPサーバーは、ブロードキャストをサポートするのに適した候補です。すべてのLISにARPサーバーがあります。 ARPサーバーには、LISメンバーシップ全体が含まれています。これらは、ブロードキャスト機能の基本的な要素です。
A.1.1 Base Solution without modifications to ARP Server.
A.1.1 ARPサーバーに変更を加えない基本ソリューション。
One may choose as an existing starting point to use only what is available in RFC 1577. That is, a host can easily calculate the range of members in its LIS based on its own IP address and subnet mask. The host can then issue an ARP Request for every member of the LIS. With this information, the host can then set up point-to-point connections with all members, or can set up a point-to-multipoint connection to all members. There you have it, the poor man's broadcast.
RFC 1577で利用可能なものだけを使用する既存の開始点として選択できます。つまり、ホストは、独自のIPアドレスとサブネットマスクに基づいてLISのメンバーの範囲を簡単に計算できます。その後、ホストはLISのすべてのメンバーに対してARP要求を発行できます。ホストはこの情報を使用して、すべてのメンバーとのポイントツーポイント接続をセットアップするか、すべてのメンバーへのポイントツーマルチポイント接続をセットアップできます。そこに、貧しい人の放送があります。
While this solution is very straight forward, it suffers from a number of problems.
この解決策は非常に単純ですが、いくつかの問題があります。
o The load on the ARP Server is very large. If all stations on a LIS choose to implement broadcasting, the initial surge of ARP Requests will be huge. Some sort of slow start sequence would be needed.
o ARPサーバーの負荷が非常に大きい。 LIS上のすべてのステーションがブロードキャストの実装を選択した場合、ARP要求の初期の急増は巨大になります。ある種のスロースタートシーケンスが必要になります。
o The amount of resource required makes this a non-scalable solution. The authors believe that broadcasting will require an MCS to reduce the number of channel resources required to support each broadcast 'group'. Using the ARP Server in this manner does not allow an MCS to be transparently introduced. (Basic RFC1577 interfaces also do not implement the extended LLC/SNAP encapsulation required to safely use more than one MCS).
o 必要なリソースの量は、これを非スケーラブルなソリューションにします。著者は、放送では各放送「グループ」をサポートするために必要なチャネルリソースの数を減らすためにMCSが必要になると考えています。この方法でARPサーバーを使用すると、MCSを透過的に導入できません。 （基本的なRFC1577インターフェイスは、複数のMCSを安全に使用するために必要な拡張LLC / SNAPカプセル化も実装していません）。
o The diskless boot solution can not function in this environment because it may be unable to determine which subnet to which it belongs.
o ディスクレスブートソリューションは、所属するサブネットを判別できない可能性があるため、この環境では機能しません。
A.1.2 Enhanced ARP Server solution.
A.1.2 強化されたARPサーバーソリューション。
This solution is similar to the base solution except that it takes some of the (MARS) multicast solution and embeds it in the ARP Server. The first enhancement is to add the MARS_MULTI command to the set of opcodes that the ARP Server supports. This would allow a host to issue a single request, and to get back the list of members in one or more MARS_REPLY packets. Rather than have a registration mechanism, the ARP Server could simply use the list of members that have already been registered. When a request comes in for the subnet broadcast address, the ARP Server would aggregate the list, and send the results to the requester.
このソリューションは、（MARS）マルチキャストソリューションの一部を受け取り、それをARPサーバーに埋め込むことを除いて、基本ソリューションと似ています。最初の機能拡張は、MARP_MULTIコマンドを、ARPサーバーがサポートする一連のオペコードに追加することです。これにより、ホストは単一の要求を発行し、1つ以上のMARS_REPLYパケットでメンバーのリストを取得できます。 ARPサーバーは、登録メカニズムを持つのではなく、すでに登録されているメンバーのリストを使用するだけで済みます。サブネットブロードキャストアドレスに対する要求が着信すると、ARPサーバーはリストを集計し、結果を要求者に送信します。
This suffers from two drawbacks.
これには2つの欠点があります。
1) Scalability with regard to number of VCs is still an issue. One would eventually need to add in some sort of multicast server solution to the ARP Server.
1）VCの数に関するスケーラビリティはまだ問題です。最終的に、ある種のマルチキャストサーバーソリューションをARPサーバーに追加する必要があります。
2) The diskless boot scenario is still broken. There is no way for a station to perform a MARS_MULTI without first knowing its IP address and subnet mask.
2）ディスクレスブートのシナリオはまだ壊れています。ステーションが最初にIPアドレスとサブネットマスクを知らない限り、MARS_MULTIを実行する方法はありません。
The diskless boot problem could be solved by adding to the ARP Server a registration process where anyone could register to the 255.255.255.255 address. These changes would make the ARP Server look more and more like MARS.
ディスクレスブートの問題は、ARPサーバーに、誰でも255.255.255.255アドレスに登録できる登録プロセスを追加することで解決できます。これらの変更により、ARPサーバーはMARSにますます似たものになります。
A.2 MARS Solutions.
A.2 MARSソリューション。
If we wish to keep the ARP Server constant as described in RFC 1577, the alternative is to use the Multicast Address Resolution Server (MARS) described in [2].
RFC 1577で説明されているようにARPサーバーを一定に保ちたい場合は、[2]で説明されているマルチキャストアドレス解決サーバー（MARS）を使用することもできます。
MARS has three nice features for broadcasting.
MARSには、ブロードキャスト用の3つの優れた機能があります。
1) It has a generalized registration approach which allows for any address to have a group of entities registered. So, if the subnet address is not known, a host can register for an address that is known (e.g. 255.255.255.255).
1）一般的な登録アプローチを採用しているため、任意のアドレスでエンティティのグループを登録できます。そのため、サブネットアドレスが不明な場合、ホストは既知のアドレス（255.255.255.255など）に登録できます。
2) The command set allows for lists of members to be passed in a single MARS_MULTI packet. This reduces traffic.
2）コマンドセットでは、メンバーのリストを単一のMARS_MULTIパケットで渡すことができます。これにより、トラフィックが減少します。
3) MARS contains an architecture for dealing with the scalability issues. That is, Multicast Servers (MCSs) may be used to set up the point-to-multipoint channels and reduce the number of channels that a host needs to set up to one. Hosts wishing to broadcast will instead send the packet to the MCS who will then forward it to all members of the LIS.
3）MARSには、スケーラビリティの問題に対処するためのアーキテクチャが含まれています。つまり、マルチキャストサーバー（MCS）を使用して、ポイントツーマルチポイントチャネルをセットアップし、ホストがセットアップする必要があるチャネルの数を1つに減らすことができます。ブロードキャストを希望するホストは、代わりにパケットをMCSに送信し、MCSはパケットをLISのすべてのメンバーに転送します。
A.2.1. CIDR-prefix (Subnet) Broadcast solution.
A.2.1. Cedar-prefix（サブネット）ブロードキャストソリューション。
One of the earliest solutions was to simply state that broadcast support would be implemented by using a single multicast group in the class D address space -- namely, the CIDR-prefix (subnet) broadcast address group. All members of a LIS would be required to register to this address, and use it as required. A host wishing to use either the 255.255.255.255 broadcast, or the network broadcast addresses would internally map the VC to the subnet broadcast VC. The all ones and network broadcast addresses would exist on MARS, but would be unused.
初期の解決策の1つは、クラスDアドレス空間で単一のマルチキャストグループ、つまりCIDRプレフィックス（サブネット）ブロードキャストアドレスグループを使用してブロードキャストサポートを実装すると単純に述べることでした。 LISのすべてのメンバーは、このアドレスに登録し、必要に応じて使用する必要があります。 255.255.255.255ブロードキャストまたはネットワークブロードキャストアドレスのいずれかを使用したいホストは、内部的にVCをサブネットブロードキャストVCにマップします。すべて1とネットワークブロードキャストアドレスはMARSに存在しますが、使用されません。
The problem with this approach goes back to the diskless workstation problem. Because the workstation may not know which subnet it belongs to, it doesn't know which group to register with.
このアプローチの問題は、ディスクレスワークステーションの問題に戻ります。ワークステーションはどのサブネットに属しているかがわからない場合があるため、どのグループに登録するかわかりません。
This solution acknowledges that the diskless boot problem requires a generic address (one that does not contain CIDR-prefix (subnet) information) to register with and to use until subnet knowledge is known. In essence, all stations first register to the 255.255.255.255 group, then as they know their subnet information, they could optionally de-register from the all one's group and register to the CIDR-prefix (subnet) broadcast group.
このソリューションは、ディスクレスブートの問題が登録され、サブネットの知識がわかるまで使用するための汎用アドレス（CIDRプレフィックス（サブネット）情報を含まないアドレス）が必要であることを認めています。基本的に、すべてのステーションは最初に255.255.255.255グループに登録し、次にサブネット情報を知っているので、オプションですべてのステーションの登録を解除してCIDRプレフィックス（サブネット）ブロードキャストグループに登録できます。
This solution would appear to solve a couple of problems:
このソリューションは、いくつかの問題を解決するように見えます。
1) The bootp client can function if the server remains registered to the all one's group continuously.
1）サーバーが全員のグループに継続的に登録されている場合、bootpクライアントは機能します。
2) There will be less traffic using the all ones group because the preferred transactions will be on the subnet broadcast channel.
2）all onesグループを使用すると、優先トランザクションがサブネットブロードキャストチャネルで行われるため、トラフィックが少なくなります。
Unfortunately the first bullet contains a flaw. The server must continually be registered to two groups -- the all ones group and the subnet broadcast group. If this server has multiple processes that are running different IP applications, it may be difficult for the link layer to know which broadcast VC to use. If it always uses the all ones, then it will be missing members that have removed themselves from the all ones and have registered to the subnet broadcast. If it always uses the subnet broadcast group, the diskless boot scenario gets broken. While making the decision at the link layer may require additional control flows be built into the path, it may also require the rewriting of application software.
残念ながら、最初の箇条書きには欠陥が含まれています。サーバーは継続的に2つのグループに登録する必要があります-all onesグループとサブネットブロードキャストグループ。このサーバーに、異なるIPアプリケーションを実行している複数のプロセスがある場合、リンクレイヤーがどのブロードキャストVCを使用するかを知るのが難しい場合があります。常にすべて1を使用する場合、すべて1から自分自身を削除し、サブネットブロードキャストに登録したメンバーが失われます。常にサブネットブロードキャストグループを使用する場合、ディスクレスブートシナリオは機能しなくなります。リンク層での決定には、追加の制御フローをパスに組み込む必要がある場合がありますが、アプリケーションソフトウェアの書き換えも必要になる場合があります。
In some implementations, a simple constant is used to indicate to the link layer that this packet is to be transmitted to the broadcast "MAC" address. The assumption is that the physical network broadcast and the logical protocol broadcast are one and the same. As pointed out earlier, this is not the case with ATM. Therefore applications would need to specifically identify the subnet broadcast group address to take advantage of the smaller group.
いくつかの実装形態では、このパケットがブロードキャスト「MAC」アドレスに送信されることをリンク層に示すために、単純な定数が使用されます。物理ネットワークブロードキャストと論理プロトコルブロードキャストは同一であると想定されています。前に指摘したように、これはATMには当てはまりません。したがって、アプリケーションは、小さいグループを利用するために、サブネットブロードキャストグループアドレスを明確に識別する必要があります。
These problems could be solved in a number of ways, but it was thought that they added unnecessarily to the complexity of the broadcast solution.
これらの問題はさまざまな方法で解決できますが、ブロードキャストソリューションの複雑さが不必要に増大すると考えられていました。
Appendix B. Should MARS Be Limited to a Single LIS?
付録B. MARSは単一のLISに限定すべきですか？
RFC 2022 explicitly states that a network administrator MUST ensure that each LIS is served by a separate MARS, creating a one-to-one mapping between cluster and a unicast LIS. But, it also mentions that relaxation of this restriction MAY occur after future research warrants it. This appendix discusses some to the potential implications to broadcast should this restriction be removed.
RFC 2022は、ネットワーク管理者が各LISが個別のMARSによって処理されることを保証し、クラスターとユニキャストLIS間の1対1のマッピングを作成する必要があることを明示的に述べています。ただし、この制限の緩和は、将来の研究で保証された後に発生する可能性があることにも言及しています。この付録では、この制限を削除した場合のブロードキャストへの潜在的な影響について説明します。
The most obvious change would be that the notion of a cluster would span more than one LIS. Therefore, the broadcast group of 255.255.255.255 would contain members from more than one LIS.
最も明白な変更は、クラスターの概念が複数のLISにまたがることです。したがって、255.255.255.255のブロードキャストグループには、複数のLISからのメンバーが含まれます。
It also should be emphasized that the one LIS limitation is not a restriction of the MARS architecture. Rather, it is only enforced if an administrator chooses to do so.
1つのLIS制限がMARSアーキテクチャの制限ではないことも強調する必要があります。むしろ、管理者がそうすることを選択した場合にのみ強制されます。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物を作成したり、コピーしたり、公開したり、配布したりすることができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。