RFC2121 日本語訳

Network Working Group                                      G. Armitage
Request for Comments: 2121                                    Bellcore
Category: Informational                                     March 1997

コメントを求めるワーキンググループG.アーミテージ要求をネットワークでつないでください: 2121年のBellcoreカテゴリ: 情報の1997年3月

                   Issues affecting MARS Cluster Size

火星Cluster Sizeに影響する問題

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   IP multicast over ATM currently uses the MARS model [1] to manage the
   use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope
   of any given MARS services is the MARS Cluster - typically the same
   as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are
   usually architected with unicast routing and forwarding issues
   dictating the sizes of individual LISes. However, as IP multicast is
   deployed as a service, the size of a LIS will only be as big as a
   MARS Cluster can be. This document provides a qualitative look at the
   issues constraining a MARS Cluster's size, including the impact of VC
   limits in switches and NICs, geographical distribution of cluster
   members, and the use of VC Mesh or MCS modes to support multicast
   groups.

ATMの上のIPマルチキャストは、現在、ATM Pt-mpt SVCsのIPマルチキャストパケット推進の使用を管理するのに火星モデル[1]を使用します。 どんな与えられた火星サービスの範囲もCluster火星です--通常IPv4 Logical IP Subnet(LIS)と同じくらい。 通常、ユニキャストルーティングと推進問題が個々のLISesのサイズを決めていて、現在のIP/ATMネットワークはarchitectedされます。 しかしながら、IPマルチキャストがサービスとして配備されるとき、LISのサイズは単にCluster火星であることができるのと同じくらい大きいでしょう。 このドキュメントは火星Clusterのサイズを抑制する問題への質的な一見を提供します、マルチキャストグループを支持するためにスイッチとNICsでのVC限界の影響、クラスタメンバーの地域分布、およびVC MeshかMCSモードの使用を含んでいて。

1. Introduction

1. 序論

   A MARS Cluster is the set of IP/ATM interfaces that are willing to
   engage in direct, ATM level pt-mpt SVCs to perform IP multicast
   packet forwarding [1]. Each IP/ATM interface (a MARS Client) must
   keep state information regarding the ATM addresses of each leaf node
   (recipient) of each  pt-mpt SVC it has open. In  addition, each MARS
   Client receives MARS_JOIN and MARS_LEAVE messages from the MARS
   whenever there is a requirement that Clients around the Cluster need
   to update their pt-mpt SVCs for a given IP multicast group.

Cluster火星はIPマルチキャストパケット推進[1]を実行するのをダイレクトATMレベルPt-mpt SVCsに噛み合わせても構わないと思っているIP/ATMインタフェースのセットです。 それぞれのIP/ATMインタフェース(Client火星)は、状態がそれぞれのPt-mpt SVCのそれぞれの葉のノード(受取人)のATMアドレスを見なして、戸外を持っているという情報であることを保たなければなりません。 さらに、Clusterの周りのClientsが、与えられたIPマルチキャストグループのために彼らのPt-mpt SVCsをアップデートする必要があるという要件があるときはいつも、それぞれのClient火星は火星から火星_JOINと火星_LEAVEメッセージを受け取ります。

   The definition of Cluster 'size' can mean two things - the number of
   MARS Clients using a given MARS, and the geographic distribution of
   MARS Clients. The number of MARS Clients in a Cluster impacts on the
   amount of state information any given client may need to store while
   managing  outgoing  pt- mpt SVCs. It also impacts on the average rate
   of JOIN/LEAVE traffic that is propagated by the MARS on
   ClusterControlVC, and the number of pt-mpt VCs that may need
   modification each time a MARS_JOIN or MARS_LEAVE appears on
   ClusterControlVC.

Cluster'サイズ'の定義は2つのものを意味できます--与えられた火星を使用する火星Clientsの数、および火星Clientsの地理分布。 Clusterの火星Clientsの数にどんな与えられたクライアントも出発しているPt mpt SVCsを管理している間、格納する必要があるかもしれない州の情報の量で影響を与えます。 また、それにClusterControlVCで火星で伝播されるJOIN/LEAVE交通の平均相場、および_のLEAVEの火星_JOINか火星がClusterControlVCに現れるたびに変更を必要とするかもしれないPt-mpt VCsの数で影響を与えます。

Armitage                     Informational                      [Page 1]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[1ページ]RFC2121Issues

   The geographic distribution of clients affects the latency between a
   client issuing a MARS_JOIN, and it finally being added onto the pt-
   mpt VCs of the other MARS Clients transmitting to the specified
   multicast group. (This latency is made up of both the time to
   propagate the MARS_JOIN, and the delay in the underlying ATM cloud's
   reaction to the subsequent ADD_PARTY messages.)

クライアントの地理分布は_JOIN火星を発行するクライアントの間の潜在のふりをします、そして、指定されたマルチキャストに伝わるもう片方のClients火星のmpt VCsが分類すると最終的にPtに追加されます。 (この潜在はその後のADD_パーティメッセージへの基本的なATM雲の反応で_JOIN火星を伝播する時間と遅れの両方で作られます。)

   When architecting an IP/ATM network it is important to understand the
   worst case scaling limits applicable to your Clusters. This document
   provides a primarily qualitative look at the design choices that
   impose the most dramatic constraints on Cluster size. Since the focus
   is on worst-case scenarios, most of the analysis will assume
   multicast groups that are VC Mesh based and have all cluster members
   as sources and receivers. Engineering using the worst-case boundary
   conditions, then applying optimisations such as Multicast Servers
   (MCS), provides the Cluster with a margin of safety.  It is hoped
   that more detailed quantitative analysis of Cluster sizing limits
   will be prompted by this document.

IP/ATMネットワークをarchitectingするとき、最悪の場合があなたのClustersに適切な限界をスケーリングするのを理解しているのは重要です。 このドキュメントは最も劇的な規制をClusterサイズに課すデザイン選択への主として質的な一見を提供します。 焦点が最悪の事態のシナリオにあるので、分析の大部分はVC Meshであるマルチキャストグループには、ソースと受信機として、すべてのクラスタメンバーが基礎づけて、いると仮定するでしょう。 最悪の場合境界状態を使用する工学(Multicast Servers(MCS)などの当時の適用最適化)が安全範囲をClusterに提供します。 限界を大きさで分けるClusterの、より詳細な定量分析がこのドキュメントによってうながされることが望まれています。

   Section 2 comments on the VC state requirements of the MARS model,
   while Sections 3 and 4 identify the group change processing load and
   latency characteristics of a cluster as a function of its size.
   Section 5 looks at how Multicast Routers (both conventional and
   combination router/switch architectures) increase the scale of a
   multicast capable IP/ATM network. Finally, Section 6 discusses how
   the use of Multicast Servers (MCS) might impact on the worst case
   Cluster size limits.

VCのセクション2コメントは火星モデルの要件を述べます、セクション3と4はサイズの関数としてクラスタの集団変化処理荷重と潜在の特性を特定しますが。 Multicast Routers(ともに従来と組み合わせルータ/スイッチ構造)がマルチキャストできるIP/ATMネットワークのスケールをどう増加させるかにおけるセクション5面相。 最終的に、セクション6はMulticast Servers(MCS)の使用に最悪の場合Clusterサイズ限界のときにどう影響を与えるかもしれないかについて議論します。

2. VC state limitations.

2. VCは制限を述べます。

   Two characteristics of ATM NICs and switches will limit the number of
   members a Cluster may contain. They are:

ATM NICsとスイッチの2つの特性がClusterが含むかもしれない会員数を制限するでしょう。 それらは以下の通りです。

      The maximum number of VCs that can be originated from, or
      terminate on, a port (VCmax).

それが溯源されるか、または終わることができるVCs、ポート(VCmax)の最大数。

      The maximum number of leaf nodes supportable by a root node
      (LEAFmax).

根のノード(LEAFmax)で我慢できる葉のノードの最大数。

   We'll assume that the MARS node has similar VCmax and LEAFmax values
   as Cluster members.  VCmax affects the Cluster size because of the
   following:

私たちは、火星ノードにはClusterメンバーとして同様のVCmaxとLEAFmax値があると思うつもりです。 VCmaxは以下でClusterサイズに影響します:

      The MARS terminates a pt-pt control VC from each cluster member,
      and originates a VC for ClusterControlVC and ServerControlVC.

火星は、それぞれのクラスタメンバーからのPt PtコントロールVCを終えて、ClusterControlVCとServerControlVCのためにVCを溯源します。

Armitage                     Informational                      [Page 2]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[2ページ]RFC2121Issues

      When a multicast group is VC Mesh based, a group member terminates
      a VC from every sender to the group, per group.

マルチキャストグループが基づくVC Meshであるときに、グループのメンバーはすべての送付者からグループまでのVCを終えます、グループ単位で。

      When a multicast group is MCS based, the MCS terminates a VC from
      every sender to the group.

マルチキャストグループが基づくMCSであるときに、MCSはすべての送付者からグループまでのVCを終えます。

   LEAFmax affects the Cluster size because of the following:

LEAFmaxは以下でClusterサイズに影響します:

      ClusterControlVC from the MARS. It has a leaf node per cluster
      member (MARS Client).

火星からのClusterControlVC。 それには、クラスタメンバー(火星Client)あたり1つの葉のノードがあります。

      Packet forwarding SVCs out of each MARS Client for each IP
      multicast group being sent to. It has a leaf node for each group
      member when a group is VC Mesh based.

発信するそれぞれのIPマルチキャストグループのためのそれぞれのClient火星からのパケット推進SVCs。 グループが基づくVC Meshであるときに、それには、それぞれのグループのメンバーへの葉のノードがあります。

      Packet forwarding SVCs out of each MCS for each IP multicast group
      being sent to. It has a leaf node for each group member when a
      group is MCS based.

発信するそれぞれのIPマルチキャストグループのための各MCSからのパケット推進SVCs。 グループが基づくMCSであるときに、それには、それぞれのグループのメンバーへの葉のノードがあります。

   If we have N cluster members, and M multicast groups active (using VC
   Mesh mode, and densely populated - all receivers are senders), the
   following observations may be made:

私たちがNクラスタメンバー、およびMマルチキャストグループをアクティブにする、(VC Meshモードを使用して、密に居住されます--、すべての受信機が送付者である、)、以下の観測をするかもしれません:

      ClusterControlVC has N leaf nodes, so
            N <= LEAFmax.

ClusterControlVCにはN葉のノードがあるので、N<はLEAFmaxと等しいです。

      The MARS terminates a pt-pt VC from each cluster member, and
      originates ClusterControlVC and ServerControlVC, so
            (N+2) <= VCmax.

火星は、それぞれのクラスタメンバーからのPt Pt VCを終えて、ClusterControlVCとServerControlVCを溯源します、したがって(N+2)、<はVCmaxと等しいです。

      Each Cluster Member sources 1 VC per group, terminates (N-1) VC
      per group, originates a pt-pt VC to the MARS, and terminates 1 VC
      as a leaf on ClusterControlVC, so
            (M*N) + 2 <= VCmax.

それぞれのClusterメンバーが1グループあたり1VCの出典を明示して、グループ単位で(N-1)VCを終えて、Pt Pt VCを火星に溯源して、葉としてClusterControlVCで1VCを終えるので、(M*N)+2<はVCmaxと等しいです。

      The VC sourced by each Cluster member per group goes to all other
      cluster members, so
            (N-1) <= LEAFmax.

それぞれの1グループあたりのClusterメンバーによって出典を明示されたVCが他のすべてのクラスタメンバーに行くので、(N-1)<はLEAFmaxと等しいです。

Armitage                     Informational                      [Page 3]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[3ページ]RFC2121Issues

   Since all the above conditions must be simultaneously true, we can
   see that the most constraining requirement is either:

すべての上記の状態が同時に本当であるに違いないので、私たちは、要件を抑制する大部分がどちらかであることを見ることができます:

      (M*N) + 2 <= VCmax.

(M*N)+2<はVCmaxと等しいです。

   or

または

      N <= LEAFmax.

N<はLEAFmaxと等しいです。

   The limit involving VCmax is fundamentally controlled by the VC
   consumption of group members using a VC Mesh for data forwarding,
   rather than the termination of pt-pt control VCs on the MARS. (It is
   in practice going to be very dependent on the multicast group
   membership distributions within the cluster.)

VCmaxにかかわる限界は、火星におけるPt PtコントロールVCsの終了よりむしろデータ推進にVC Meshを使用しながら、グループのメンバーのVC消費で基本的に制御されます。 (クラスタの中のマルチキャストグループ会員資格配に非常に依存しているために、習慣の行くことでそれがあります。)

   The LEAFmax limit comes from ClusterControlVC, and is independent of
   the density of group members (or the ratios of senders to receivers)
   for active multicast groups within the cluster.

LEAFmax限界は、ClusterControlVCから来て、クラスタの中の活動的なマルチキャストグループにおいて、グループのメンバーの密度(または、送付者対受信機の比率)から独立しています。

   Under UNI 3.0/3.1 the most obvious limit on LEAFmax is 2^15 (the leaf
   node ID is 15 bits wide).  However, the signaling driver software for
   most ATM NICs may impose a limit much lower than this - a function of
   how much per-leaf node state information they need to store (and are
   capable of storing) for pt-mpt SVCs.

UNI3.0/3.1の下では、LEAFmaxで最も明白な限界は2^15(葉のノードIDは幅15ビットである)です。 しかしながら、ほとんどのATM NICsのためのシグナリングドライバソフトウェアはこれよりはるかに低い限界を課すかもしれません--Pt-mpt SVCsのための彼らが、どのくらいの1葉あたりのノード州の情報を格納する必要があるかに関する機能(そして、格納できます)。

   VCmax is constrained by the ATM NIC hardware (for available
   segmentation or reassembly instances), or by the VC capacity of the
   switch port that the NIC is attached to.  VCmax will be the smaller
   of the two.

VCmaxはATM NICハードウェア(利用可能な分割か再アセンブリ例のための)、またはNICが取り付けられるスイッチポートのVC容量によって抑制されます。 VCmaxは2で、より小さくなるでしょう。

   A MARS Client may impose its own state storage limitations, such that
   the combined memory consumption of a MARS Client and the ATM NIC's
   driver in a given host limits both LEAFmax and VCmax to values lower
   than the ATM NIC alone might have been able to support.

Client火星はそれ自身の州の格納制限を課すかもしれません、与えられたホストというClient火星とATM NICのドライバーの結合したメモリ消費がLEAFmaxとVCmaxの両方を支持するためにはATM NICだけができたかもしれないより低値に制限するように。

   It may be possible to work around LEAFmax limits by distributing the
   leaf nodes across multiple pt-mpt SVCs operating in parallel.
   However, such an approach requires further study, and doesn't solve
   the VCmax limitation associated with a node terminating too many VCs.

LEAFmax限界の周りで平行で作動しながら複数のPt-mpt SVCsの向こう側に葉のノードを配布することによって働いているのは可能であるかもしれません。 しかしながら、そのようなアプローチは、さらなる研究を必要として、あまりに多くのVCsを終えるノードに関連しているVCmax制限を解決しません。

   A related observation can also be made that the number of MARS
   Clients in a Cluster may be limited by the memory constraints of the
   MARS itself. It is required to keep state on all the groups that
   every one of its MARS Clients have joined. For a given memory limit,
   the maximum number of MARS Clients must drop if the average number of
   groups joined per Client rises. Depending on the level of group
   memberships, this limitation may be more severe than LEAFmax.

また、Clusterの火星Clientsの数が火星自体のメモリ規制で制限されるかもしれないという関連する観測をすることができます。 すべてのグループの状態を維持するために、Clients火星の皆が加わったのが必要です。 与えられたメモリ限界のために、グループの平均した数がClientの上昇単位で接合したなら、火星Clientsの最大数は低下しなければなりません。 グループ会員資格のレベルによって、この制限はLEAFmaxより厳しいかもしれません。

Armitage                     Informational                      [Page 4]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[4ページ]RFC2121Issues

3. Signaling load.

3. シグナリングはロードされます。

   In any given cluster there will be an 'ambient' level of
   MARS_JOIN/LEAVE activity. The dynamic characteristics of this
   activity will depend on the types of multicast applications running
   within the cluster. For a constant relative distribution of multicast
   applications we can assume that, as the number of MARS Clients in a
   given cluster rises, so does the ambient level of MARS_JOIN/LEAVE
   activity. This increases the average frequency with which the MARS
   processes and propagates MARS_JOIN/LEAVE messages.

どんな与えられたクラスタにも、'周囲'のレベルの火星_JOIN/LEAVE活動があるでしょう。 この活動の動特性はクラスタの中に走るマルチキャストアプリケーションのタイプに頼るでしょう。 マルチキャストアプリケーションの一定の相対的な分配のために、私たちはそれを仮定できます、与えられたクラスタの火星Clientsの数が火星_JOIN/LEAVE活動の環境レベルを上って、そうするとき。 これは火星が火星_JOIN/LEAVEメッセージを処理して、伝播する平均した頻度を増加させます。

   The existence of MARS_JOIN/LEAVE traffic also has a consequential
   impact on signaling activity at the ATM level (across the UNI and
   {P}NNI boundaries). For groups that are VC Mesh supported, each
   MARS_JOIN or MARS_LEAVE propagated on ClusterControlVC will result in
   an ADD_PARTY or DROP_PARTY message sent across the UNIs of all MARS
   Clients that are transmitting to a given group. As a cluster's
   membership increases, so does the average number of MARS Clients that
   trigger ATM signaling activity in response to MARS_JOIN/LEAVEs.

また、火星_JOIN/LEAVE交通の存在がATMレベルでゆゆしい影響力をシグナル伝達活性に持っている、(UNIとP NNI、境界) 支持されたVC Meshであるグループのために、ClusterControlVCで伝播されたそれぞれの_火星のLEAVEのJOINか火星_が与えられたグループに伝わっているすべてのClients火星のUNIsの向こう側に送られたADD_パーティかDROP_パーティメッセージをもたらすでしょう。 クラスタの会員資格が増加するのに従って、火星_JOIN/LEAVEsに対応してATMシグナル伝達活性の引き金となる火星Clientsの平均した数もそうします。

   The size of a cluster needs to be chosen to provide some level of
   containment to this ambient level of MARS and UNI/NNI signaling.

クラスタのサイズは、この環境レベルの火星とUNI/NNIシグナリングに何らかのレベルの封じ込めを提供するのに選ばれる必要があります。

   Some refinements to the MARS Client behaviour may also be explored to
   smooth out UNI signaling transients. MARS Clients are currently
   required to initiate revalidation of group memberships only when the
   Client next sends a packet to an invalidated group SVC. A Client
   could apply a similar algorithm to decide when it should issue
   ADD_PARTYs. For example, after seeing a MARS_JOIN, wait until it
   actually has a packet to send, send the packet, then initiate the
   ADD_PARTY. As a result actively transmitting Clients would update
   their SVCs sooner than intermittently transmitting Clients.

また、火星Clientのふるまいへのいくつかの気品が、UNIシグナリング過渡現象を取り除くために調査されるかもしれません。 次のClientが現在無効にされたグループSVCにパケットを送るときだけ、火星Clientsはグループ会員資格の再合法化を開始しなければなりません。 Clientは、それがいつADD_PARTYsを発行するべきであるかを決めるために同様のアルゴリズムを適用できました。 例えば、_JOIN火星を見た後に、実際に送るパケットを持つまで、待ってください、そして、パケットを送ってください、そして、次に、ADD_パーティを開始してください。 その結果活発にClientsを伝えると、彼らのSVCsは断続的にClientsを伝えるより早く、アップデートされるでしょう。

4. Group change latencies

4. 集団変化潜在

   The group change latency can be defined as the time it takes for all
   the senders to a group to have correctly updated their forwarding
   SVCs after a MARS_JOIN or MARS_LEAVE is received from the MARS. This
   is affected by both the number of Cluster members and the
   geographical distribution of Cluster members. (Groups that are MCS
   based create the lowest impact when new members join or leave, since
   only the MCS needs to update its forwarding SVC.) Under some
   circumstances, especially modelling or simulation environments, group
   change latencies within a cluster may be an important characteristic
   to control.

わざわざと火星から_のLEAVEの火星_JOINか火星を受け取った後にグループへのすべての送付者が正しくそれが彼らの推進SVCsをアップデートした集団変化潜在を定義できます。 これはClusterメンバーの数とClusterメンバーの地域分布の両方で影響を受けます。 (新しいメンバーが加わるか、またはいなくなるとき、基づくMCSであるグループは最も低い衝撃を作成します、MCSだけが、推進SVCをアップデートする必要があるので。) いくつかの事情、特にモデル化またはシミュレーション環境で、クラスタの中の集団変化潜在は制御する重要な特性であるかもしれません。

Armitage                     Informational                      [Page 5]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[5ページ]RFC2121Issues

   As noted in the previous section, the ADD_PARTY/DROP_PARTY signaling
   load created by membership changes in VC Mesh based groups goes up as
   the number of cluster members rises (assuming worst case scenario of
   each cluster member being a sender to the group). As the UNI load
   rises, the ATM network itself may start delivering slower processing
   of the requested events.

前項で注意されるように、クラスタメンバーの数が上昇するのに応じて(送付者であるそれぞれのクラスタメンバーの最悪の場合をグループに仮定します)、VC Meshのベースのグループにおける会員資格変化によって作成されたADD_パーティ/DROP_パーティシグナリング荷重は上がります。 UNI荷重が上昇するのに従って、ATMネットワーク自体は、要求された出来事の、より遅い処理を提供し始めるかもしれません。

   Wide geographic distribution of Cluster members also delays the
   propagation of MARS_JOIN/LEAVE and ATM UNI/NNI messages. The further
   apart various members are, the longer it takes for them to receive
   MARS_JOIN/LEAVE traffic on ClusterControlVC, and the longer it takes
   for the ATM network to react to ADD_PARTY and DROP_PARTY requests. If
   the long distance paths are populated by many ATM switches,
   propagation delays due to per-switch processing will add
   substantially to delays due to the speed of light.

また、Clusterメンバーの広い地理分布は火星_JOIN/LEAVEとATM UNI/NNIメッセージの伝播を遅らせます。 様々なメンバーが離れて遠ければ遠いほど、彼らがClusterControlVCにおける火星_JOIN/LEAVE交通を受けるにはかかって、より長くかかればかかるほど、ATMネットワークがADD_パーティとDROP_パーティ要求に反応するように、より長いです。 長距離の経路が多くのATMスイッチによって居住されると、1スイッチあたりの処理による伝播遅延は光速のため実質的に遅れに加えるでしょう。

   (Unfortunately, mechanisms for smoothing out the transient ATM
   signaling load described in section 3 have a consequence of
   increasing the group change latency, since the goal is for some of
   the senders to deliberately delay updating their forwarding SVCs.
   This is an area where the system architect needs to make a
   situation-specific trade-off.)

(残念ながら、セクション3で説明された一時的なATMシグナリング荷重を取り除くためのメカニズムには、集団変化潜在を高める結果があります、目標が何人かの送付者が、彼らの推進SVCsをアップデートするのを故意に遅らせることであるので。 これはシステム建築家が状況特有のトレードオフをする必要がある領域です。)

   It is not clear what affect the internal processing of the MARS
   itself has on group change latency, and how this might be impacted by
   cluster size.  A component of the MARS processing latency will depend
   on the specific database implementation and search algorithms as much
   as on the number of group members for the group being modified at any
   instant. Since the maximum number of group members for a given group
   is equal to the number of cluster members, there will be an indirect
   (even if small) relationship between worst case MARS processing
   latencies and cluster size.

火星自体の内部の処理に影響することが集団変化の上で潜在と、クラスタサイズでどうこれに影響を与えるかもしれないかをさせるのは、明確ではありません。 火星処理潜在のコンポーネントはどんな瞬間にも変更されるグループのために特定のデータベース実現と検索アルゴリズムにグループのメンバーの数と同じくらい非常によるでしょう。 与えられたグループのグループのメンバーの最大数がクラスタメンバーの数と等しいので、最悪の場合火星処理潜在とクラスタサイズとの間接的な(小さくても)関係があるでしょう。

5. Large IP/ATM networks using Mrouters

5. Mroutersを使用する大きいIP/ATMネットワーク

   Building a large scale, multicast capable IP over ATM network is a
   tradeoff between Cluster sizes and numbers of Mrouters. For a given
   number of hosts, the number of clusters goes up as individual
   clusters shrink. Since Mrouters are the topological intersections
   between clusters, the number of Mrouters rises as the size of
   individual clusters shrinks. (The actual number of Mrouters depends
   largely on the logical IP topology you choose to implement, since a
   single physical Mrouter may interconnect more than two Clusters at
   once.) It is a local deployment question as to what the optimal mix
   of Clusters and Mrouters will be.

ATMネットワークの上に大規模、マルチキャストにできるIPを建てるのは、MroutersのClusterサイズと数の間の見返りです。 与えられた数のホストに関しては、個々のクラスタが縮まるのに応じて、クラスタの数は上がります。 Mroutersがクラスタの間の位相的な交差点であるので、個々のクラスタのサイズが縮まるのに従って、Mroutersの数は上昇します。 (Mroutersの実数を主にあなたが実行するのを選ぶ論理的なIPトポロジーに依存します、独身の物理的なMrouterがすぐに2Clustersとインタコネクトするかもしれないので。) それはClustersとMroutersの最適のミックスが何になるかに関するローカルの展開問題です。

Armitage                     Informational                      [Page 6]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[6ページ]RFC2121Issues

   Currently two broad classes of Mrouters may be identified:

現在の、Mroutersの2つの広いクラスが特定されるかもしれません:

      Those that originate unique VCs into target Clusters, and
      forward/interleave data at the IP packet level (the Conventional
      Mrouter).

目標ClustersにユニークなVCsを由来して、IPパケットでフォワード/インタリーブデータを由来するものは(Conventional Mrouter)を平らにします。

      Those that originate unique VCs into target Clusters, but create
      internal, cell level 'cut through' paths between VCs from
      different Clusters (e.g. the Cell Switch Router).

目標ClustersにユニークなVCsを溯源しますが、''経路を通して切られて、異なったClusters(例えば、Cell Switch Router)からのVCsの間で内部のセルレベルを作成するもの。

   How these Mrouters establish and manage the associations of VCs to IP
   traffic flows is beyond the scope of this document.  However, it is
   worth looking briefly at their impact on VC consumption and ATM
   signaling load.

これらのMroutersがどうIP交通の流れにVCsの協会を設立して、経営するかはこのドキュメントの範囲を超えています。 しかしながら、VC消費とATMシグナリングへのそれらの影響がロードされるのを簡潔に見る価値があります。

5.1 Impact of the Conventional Mrouter

5.1 従来のMrouterの衝撃

   A conventional Mrouter acts as an aggregation point for both
   signaling and data plane loads. It hides host specific group
   membership changes in one cluster from senders within other clusters,
   and protects group members (receivers) in one cluster from having to
   be leaf nodes on SVCs from senders in other Clusters.

従来のMrouterはシグナリングとデータ飛行機荷重の両方のための集合ポイントとして機能します。 それは、他のクラスタの中に特定のグループ会員資格が1個のクラスタで送付者から変えるホストを隠して、1個のクラスタに送付者からの他のClustersのSVCsの上の葉のノードでなければならないのからグループのメンバー(受信機)を保護します。

   When acting as an ingress point into a cluster, a conventional
   Mrouter establishes a single forwarding SVC for IP packets.  This
   single SVC carries data from other clusters interleaved at the IP
   packet level. Only this single SVC needs to be modified in response
   to group memberships changes within the target cluster.  As a
   consequence, there is no need for sources in other clusters to be
   aware of, or react to, MARS_JOIN/LEAVE traffic in the target cluster.
   (The consequential UNI signaling load identified in section 3 is also
   localized within the target Cluster.)

イングレスポイントとしてクラスタに機能するとき、従来のMrouterはIPパケットのために独身の推進SVCを設立します。 この独身のSVCはIPパケット・レベルではさみ込まれた他のクラスタからデータを運びます。 この独身のSVCだけが、目標クラスタの中のグループ会員資格変化に対応して変更される必要があります。 結果として、目標クラスタで火星_JOIN/LEAVE交通に他のクラスタのソースが意識している必要が全くないか、または反応します。 (また、セクション3で特定されたゆゆしいUNIシグナリング荷重は目標Clusterの中で局所化されます。)

   MARS Clients within the target cluster also benefit from this data
   path aggregation because they terminate only one SVC from the Mrouter
   (per group), rather than multiple SVCs originating from actual
   senders in other Clusters.

また、彼らが他のClustersに実際の送付者から発する複数のSVCsよりむしろMrouter(1グループあたりの)からの1SVCだけを終えるので、目標クラスタの中の火星Clientsはこのデータ経路集合の利益を得ます。

   Conventional Mrouters help control the limiting factors described in
   sections 2, 3, and 4.  A hypothetical 10000 node Cluster could be
   broken into two 5000 node Clusters, or four 2500 node Clusters, etc,
   to reduce VC consumption. Or you might have 200 nodes of the overall
   10000 that are known to join and leave groups rapidly, whilst the
   other 9800 are fairly steady - so you deploy clusters of 200, 2500,
   2500, 2500, 2300 hosts respectively.

従来のMroutersは限定因子がセクション2、3、および4で説明したコントロールを助けます。 VC消費を抑えるために5000年の2ノードClusters、または2500年の4ノードClustersなどを10000ノードClusterに細かく分けることができたという仮言命題。 または、あなたには、急速にグループに加わって、出るのが知られている総合的な10000のものの200のノードがあるかもしれません、他の9800はかなり安定していますがあなたがそれぞれ200、2500、2500、2500、2300人のホストのクラスタを配備して。

Armitage                     Informational                      [Page 7]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[7ページ]RFC2121Issues

5.2. Impact of the Cell Switch Router (CSR).

5.2. セルスイッチルータ(CSR)の影響。

   Another class of Mrouter, the Cell Switch Router (CSR) attempts to
   utilize IP level flow information to dynamically manage the switching
   of data through the device below the IP level.  Once the CSR has
   identified a flow of IP traffic, and associated it with an inbound
   and outbound SVC, it begins to function as an ATM cell level device
   rather than a packet level device.

Mrouterのもう1人のクラス、IPを利用するCell Switch Router(CSR)試みはダイナミックにIPレベルの下における装置を通したデータの切り換えを管理するために流れ情報を平らにします。 CSRがいったんIP交通の流れを特定して、本国行きの、そして、外国行きのSVCにそれを関連づけると、それはパケット・レベル装置よりむしろATMセルレベル装置として機能し始めます。

   Even when operating in this mode the CSR isolates attached Clusters
   from each other's MARS_JOIN/LEAVE activities, in the same manner as a
   conventional Mrouter. This occurs because the CSR manages its
   forwarding SVCs just like a normal MARS Client - responding to
   MARS_JOIN/LEAVE messages within the target cluster by updating the
   pt-mpt trees rooted on its own ATM ports.

これで作動さえするとき、CSRが隔離するモードは互いの火星_JOIN/LEAVE活動からClustersを取り付けました、従来のMrouterと同じ方法で。 それ自身のATMポートに根づいているPt-mpt木をアップデートすることによって目標クラスタの中の火星_JOIN/LEAVEメッセージに応じて、CSRがまさしくClientの正常な火星のように推進SVCsを管理するので、これは起こります。

   However, since AAL5 AAL_SDUs cannot be interleaved at the cell level
   on a single SVC, a CSR cannot simultaneously perform cell level cut-
   through and aggregate the IP packet flows from multiple senders onto
   a single SVC into a target Cluster. As a result, the CSR must
   construct a separate forwarding SVC into a target cluster for each
   SVC it is a leaf of in a source Cluster (to to ensure that cells from
   individual sources are not interleaved prior to reaching the re-
   assembly engines of the group members in the target cluster).

しかしながら、セルレベルでAAL5 AAL_SDUsを独身のSVCにはさみ込むことができないので、CSRは目標Clusterへの独身のSVCに同時に、を通してセルレベルカットを実行して、複数の送付者からのIPパケット流れを集めることができません。 結果、CSRが別々の推進SVCを組み立てなければならないので、各SVCのための目標クラスタに、それがaが出典を明示するコネの葉である、Cluster、(目標クラスタでグループのメンバーの再アセンブリエンジンに達する前に個々のソースからのセルがはさみ込まれないのを保証する、)

   Interestingly, the UNI signaling load offered within the target
   Cluster by the CSR is potentially greater than that of a conventional
   Mrouter. If there are N senders in the source Cluster, the CSR will
   have built N identical pt-mpt SVCs out to the group members within
   the target Cluster. If a new MARS_JOIN is issued within the target
   Cluster, the CSR must issue N ADD_PARTYs to update the N SVCs into
   the target Cluster. (Under similar circumstances a conventional
   Mrouter would have issued only one ADD_PARTY for its single SVC into
   the target Cluster.)

目標Clusterの中でCSRによって提供されたUNIシグナリング荷重は従来のMrouterのものより潜在的におもしろく、大きいです。 ソースClusterにN送付者がいれば、CSRは目標Clusterの中のグループのメンバーにN同じPt-mpt SVCsを建て増ししてしまうでしょう。 _の新しいJOIN火星が目標Clusterの中で発行されるなら、CSRは、N SVCsを目標ClusterにアップデートするためにN ADD_PARTYsを発行しなければなりません。 (同様の状況で、従来のMrouterは独身のSVCのために1ADDだけの_パーティを目標Clusterに発行したでしょう。)

   Thus, without the ability to provide internal cut-through forwarding
   with AAL_SDU boundaries intact, the CSR only provides for the
   isolation of MARS_JOIN/LEAVE traffic within clusters. It cannot
   provide the data path aggregation of a conventional Mrouter.

したがって、AAL_SDU境界を内部の深く切っている推進に完全な状態で提供する能力がなければ、CSRはクラスタの中に火星_JOIN/LEAVE交通の孤立に備えるだけです。 それは従来のMrouterのデータ経路集合を提供できません。

Armitage                     Informational                      [Page 8]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[8ページ]RFC2121Issues

6. The impact of Multicast Servers (MCSs)

6. Multicast Serversの衝撃(MCSs)

   Since the focus of this document is on worst-case scenarios, most of
   the analysis has assumed multicast groups that are VC Mesh based and
   have all cluster members as sources and receivers. The impact of
   using an MCS to support a multicast group can be dramatic in the
   context of the group's resource consumption, but less so in the
   over-all context of cluster size limits.

このドキュメントの焦点が最悪の事態のシナリオにあるので、分析の大部分はVC Meshであるマルチキャストグループには、ソースと受信機として、すべてのクラスタメンバーが基礎づけて、いると仮定しました。 マルチキャストグループを支持するのにMCSを使用する衝撃は、グループのリソース消費の文脈で劇的ですが、クラスタサイズ限界の総合的な文脈では、よりそうであるはずがありません。

   The intra-cluster, per group impact of an MCS is somewhat analogous
   to the inter-cluster impact of a conventional Mrouter. The MCS
   aggregates the data flows (only 1 SVC terminates on each group
   member, independent of the number of senders), and isolates
   MARS_JOIN/LEAVE traffic (which is shifted to ServerControlVC rather
   than ClusterControlVC). The resulting UNI signaling traffic and load
   is reduced too, as only the forwarding SVC out of the MCS needs to be
   modified for every membership change in the MCS supported group.

イントラクラスタであり、MCSの衝撃はグループに従って従来のMrouterの相互クラスタ衝撃にいくらか類似しています。 MCSはデータフロー(1SVCだけがそれぞれのグループのメンバーで終わります、送付者の数の如何にかかわらず)に集めて、火星_JOIN/LEAVE交通(ClusterControlVCよりむしろServerControlVCに移行する)を隔離します。 MCSからの推進だけSVCが、あらゆる会員資格変化のために変更される必要があるのに従ってまた、減少するUNIがMCSで交通と負荷に合図する結果になるのはグループを支持しました。

   Deploying a mixture of MCS and VC Mesh based groups will certainly
   improve resource utilization. However, the actual extent of the
   improvements (and consequently how large the cluster can be made)
   will depend greatly on the dynamics of your typical applications and
   which characteristics from sections 2, 3, and 4 are your primary
   limitations.

MCSとVC Meshのベースのグループの混合物を配備すると、確かに、リソース利用は改良されるでしょう。 しかしながら、改良の実際の範囲はセクション2、3、および4からのあなたの主用途とどの特性があなたの第一の制限であるかに関する力学に大いに依存するでしょう(そして、作られていて、その結果、クラスタはどれくらい大きい場合がありますか)。

   For example, if VCmax or LEAFmax (section 2) are primary limitations,
   one must keep in mind that each MCS itself suffers the same NIC
   limits as the MARS and MARS Clients. Even though using an MCS
   dramatically reduces the number of VCs per MARS Client per group,
   each MCS still needs to terminate 1 SVC per sender - potentially up
   to 1 SVC from each Cluster member.  (This may become 1 SVC per member
   per group if the MCS supports multiple groups simultaneously.)

例えば、VCmaxかLEAFmax(セクション2)が第一の制限であるなら、各MCS自身がClientsの火星と火星と同じNIC限界を受けるのを覚えておかなければなりません。 使用しますが、MCSはグループ単位で火星ClientあたりのVCsの数を劇的に減少させます、MCSが1送付者あたり1SVCを終えるためにまだ必要とするそれぞれ--それぞれのClusterメンバーからの潜在的に最大1SVC。 (MCSが同時に複数のグループを支持するなら、これはグループ単位で1メンバーあたり1SVCになるかもしれません。)

   Assume we have a Cluster where every group is MCS based, each MCS
   supports only one group, and both VCmax and LEAFmax apply equally to
   MCS nodes as MARS and MARS Clients nodes.  If we have N cluster
   members, M groups, and all receivers are senders for a given MCS
   supported group, the following observations may be made:

各MCSは1つのグループだけを支持します、そして、私たちがあらゆるグループが基づくMCSであるClusterを持っていると仮定してください、そして、VCmaxとLEAFmaxの両方が火星と火星Clientsノードとして等しくMCSノードに申し込まれます。 私たちにはNクラスタメンバーがいて、Mが分類されて、すべての受信機による与えられたMCSのための送付者がグループを支持したということであるなら、以下の観測をするかもしれません:

      Each MCS forwarding SVC has N leaf nodes, so
            N <= LEAFmax.

それぞれのMCS推進SVCにはN葉のノードがあるので、N<はLEAFmaxと等しいです。

      Each MCS terminates an SVC from N senders, originates 1 SVC
      forwarding path, originates a pt-pt control SVC to the MARS, and
      terminates 1 SVC as a leaf on ServerControlVC, so
            N + 3 <= VCmax.

各MCSがN送付者からのSVCを終えて、1つのSVC推進経路を溯源して、Pt PtコントロールSVCを火星に溯源して、葉としてServerControlVCで1SVCを終えるので、N+3<はVCmaxと等しいです。

Armitage                     Informational                      [Page 9]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[9ページ]RFC2121Issues

      MARS ClusterControlVC has N leaf nodes, so
            N <= LEAFmax.

火星ClusterControlVCにはN葉のノードがあるので、N<はLEAFmaxと等しいです。

      MARS ServerControlVC has M leaf nodes, so
            M <= LEAFmax.

火星ServerControlVCにはM葉のノードがあるので、M<はLEAFmaxと等しいです。

      The MARS terminates a pt-pt VC from each cluster member, a pt-pt
      VC from each MCS, originates ClusterControlVC, and originates
      ServerControlVC, so
            N + M + 2 <= VCmax.

火星が各MCSからのそれぞれのクラスタメンバーからのPt Pt VC、Pt Pt VCを終えて、ClusterControlVCを溯源して、ServerControlVCを溯源するので、N+M+2<はVCmaxと等しいです。

      Each Cluster Member sources 1 VC per group, terminates 1 VC per
      group, originates a pt-pt VC to the MARS, and terminates 1 VC as a
      leaf on ClusterControlVC, so
            2*M + 2 <= VCmax.

それぞれのClusterメンバーが1グループあたり1VCの出典を明示して、1グループあたり1VCを終えて、Pt Pt VCを火星に溯源して、葉としてClusterControlVCで1VCを終えるので、2*M+2<はVCmaxと等しいです。

   Since all the above conditions must be simultaneously true, we can
   see that the most constraining requirements are:

すべての上記の状態が同時に本当であるに違いないので、私たちは、要件を抑制する大部分が以下の通りであることを見ることができます。

      N + M + 2 <= VCmax (if M <= N)

N+M+2<はVCmaxと等しいです。(M<がNと等しいなら)

      2*M + 2 <= VCmax (if M >= N)
   or
      N <= LEAFmax.

2*M+2<がVCmaxと等しいです(M>がNと等しいなら)、またはN<はLEAFmaxと等しいです。

   (Assuming that in general M+2 > 3, so the VCmax constraint at each
   MCS is not a limiting factor.)

(一般に、それを仮定して、M+2>3によって各MCSでのVCmax規制は限定因子ではありません。)

   We can get a feel for the relative impacts of VC Mesh groups vs MCS
   based groups by considering a cluster where M1 represents the number
   of VC Mesh based groups, and M2 represents the number of MCS based
   groups. Again we assume worst case group density (all N cluster
   members are group members, all receivers are also senders).

M1がVC Meshの数を表すクラスタがグループを基礎づけたと考えることによって、私たちはMCSのベースのグループに対してVC Meshグループの相対的な影響の感じを得ることができます、そして、M2はMCSのベースのグループの数を表します。 一方、私たちは最悪の場合グループ密度を帯びます(すべてのNクラスタメンバーがグループのメンバーである、また、すべての受信機が送付者です)。

   As noted in section 2, the VCmax constraint in VC Mesh mode comes
   from each MARS Client, and is:

セクション2で注意されるように、VC MeshモードにおけるVCmax規制は、それぞれのClient火星から来て、以下の通りです。

      N*M1 <= VCmax - 2

N*M1<=VCmax--2

   For the MCS case we have two scenarios, M2 <= N and M2 >= N.

MCSケースのために、私たちは2つのシナリオ、M2<=N、およびM2>がNとの等しさにします。

   If M2 <= N we can see the VC consumption by VC Mesh based groups will
   become the applicable constraint on cluster size N when:

M2<がNと等しいなら私たちが、VC MeshのベースのグループによるVC消費がクラスタサイズNで適切な規制になるのを見ることができる、いつ:

      N + M2 <= N*M1
   i.e.
      M1 >= 1 + (M2/N)

N+M2<はN*M1と等しいです、すなわち、M1>が1+と等しいです。(M2/N)

Armitage                     Informational                     [Page 10]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[10ページ]RFC2121Issues

   Thus, if there is more than 1 VC Mesh based group, and less MCS based
   groups than cluster members (M2 < N), the constraint on cluster size
   is dictated by the VC Mesh characteristics: N*M1 <= VCmax - 2. (If M2
   == N, then there may be 2 VC Mesh based groups before the VC Mesh
   characteristics are the dictating factor.)

したがって、1つ以上のVC Meshのベースのグループ、およびクラスタメンバー(M2<N)より少ないMCSのベースのグループがあれば、クラスタサイズにおける規制はVC Meshの特性によって書き取られます: N*M1<はVCmaxと等しいです--2。 (M2=Nであるなら、VC Meshの特性が筆記要素になる前に2つのVC Meshのベースのグループがあるかもしれません。)

   Now, if M2 > N (more MCS based groups, and hence MCSes, than cluster
   members) the calculation is more complex since in this case VCmax at
   the MARS Client is the limiting parameter for both VC Mesh and MCS
   cases. The limit becomes:

現在、計算は、M2>Nである(より多くのMCSはグループを基礎づけて、したがって、MCSesを基礎づけました、メンバーを群生させるより)ならこの場合Client火星のVCmaxがVC MeshとMCSケースの両方のための制限パラメタであるので、より複雑です。 限界はなります:

      N*M1 + 2*M2 <= VCmax - 2

N*M1+2*M2<=VCmax--2

   However, on face value this is an odd situation anyway, since it
   implies more MCS entities than hosts or router interfaces into the
   cluster (given the assumption of one group per MCS).

しかしながら、額面では、これはとにかく奇妙な状況です、クラスタ(1MCSあたり1つのグループの仮定を与える)にホストかルータインタフェースより多くのMCS実体を含意するので。

   The impact of MCS entities that simultaneously support multiple
   groups is left for future study.

同時に複数のグループを支持するMCS実体の影響は今後の研究に発たれます。

7. Open Issues

7. 未解決の問題

   There is a wide range of qualitative analysis that can be extracted
   from typical MARS deployment scenarios. This document does not
   attempt to develop any numerical models for VC consumptions, end to
   end latencies, etc.

典型的な火星展開シナリオから抜粋できるさまざまな定性分析があります。 このドキュメントは、VC肺病、潜在を終わらせる終わりなどのためにどんな数値モデルも開発するのを試みません。

8. Conclusion

8. 結論

   This document has provided a high level, qualitative overview of the
   parameters affecting the size of MARS Clusters.  Limitations on the
   number of leaf nodes a pt-mpt SVC may support, sizes of the MARS
   database, propagation delays of MARS and UNI messages, and the
   frequency of MARS and UNI control messages are all identified as
   issues that will constrain Clusters.  Conventional Mrouters are
   identified as useful aggregators of IP multicast traffic and
   signaling information.  Cell Switch Routers are noted to offer only
   some of the aggregation attributes of conventional Mrouters.  Large
   scale IP multicasting over ATM requires a combination of Mrouters and
   appropriately sized MARS Clusters. Finally, it has been shown that in
   a simple cluster where there are less MCS based groups than cluster
   members, two or more VC Mesh based groups are sufficient to render
   the use of Multicast Servers irrelevant to the worst case cluster
   size limit.

このドキュメントは火星Clustersのサイズに影響するパラメタの高い平らで、質的な概観を提供しました。 Pt-mpt SVCがサポートするかもしれない葉のノードの数、火星データベースのサイズ、火星とUNIメッセージの伝播遅延、および火星とUNIコントロールメッセージの頻度における制限はClustersを抑制する問題としてすべて特定されます。 従来のMroutersはIPマルチキャスト交通の役に立つアグリゲータとして特定されて、情報に合図しています。 セルSwitch Routersは、従来のMroutersの集合属性のいくつかだけを提供するために注意されます。 ATMの上の大規模IPマルチキャスティングはMroutersと適切に大きさで分けられた火星Clustersの組み合わせを必要とします。 最終的に、それは2つ以上のVC Meshのベースのグループのクラスタメンバーより少ないMulticast Serversの使用を最悪の場合クラスタサイズ限界と無関係にするために十分なMCSベースのグループがある簡単なクラスタにそれに示されました。

Armitage                     Informational                     [Page 11]

RFC 2121           Issues affecting MARS Cluster Size         March 1997

1997年3月に火星Cluster Sizeに影響するアーミテージInformational[11ページ]RFC2121Issues

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Acknowledgments

承認

   Thanks must go to Rajesh Talpade (Georgia Tech) for specific input on
   aspects of the VC Mesh vs MCS tradeoffs, and Joel Halpern (Newbridge)
   for general input on the document's focus.

感謝は特定の入力のためのVC Mesh対MCS見返りの局面のラジェッシュTalpade(ジョージア工科大)、および一般的な入力のためのドキュメントの焦点のジョエル・アルペルン(Newbridge)のものにならなければなりません。

Author's Address

作者のアドレス

   Grenville Armitage
   Bellcore, 445 South Street
   Morristown, NJ, 07960
   USA

グレンビルアーミテージBellcore、445のSouth通りモリスタウン(ニュージャージー)07960米国

   EMail: gja@thumper.bellcore.com
   Phone +1 201 829 2635

メール: gja@thumper.bellcore.com 電話+1 201 829 2635

References

参照

   [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
   Networks.", Bellcore, RFC 2022, November 1996.

[1] アーミテージ、G.が「Multicastのために、UNIの上で3.0/3.1ベースのATM Networksを支持する」、Bellcore、RFC2022、11月1996日

Armitage                     Informational                     [Page 12]

アーミテージInformationalです。[12ページ]