RFC2149 日本語訳

Network Working Group                                         R. Talpade
Request for Comments: 2149                                      M. Ammar
Category: Informational                  Georgia Institute of Technology
                                                                May 1997

Talpadeがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2149年のM.Ammarカテゴリ: 情報のジョージア工科大学1997年5月

     Multicast Server Architectures for MARS-based ATM multicasting

火星ベースのATMマルチキャスティングのためのマルチキャストServer Architectures

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

要約

   A mechanism to support the multicast needs of layer 3 protocols in
   general, and IP in particular, over UNI 3.0/3.1 based ATM networks
   has been described in RFC 2022.  Two basic approaches exist for the
   intra-subnet (intra-cluster) multicasting of IP packets.  One makes
   use of a mesh of point to multipoint VCs (the 'VC Mesh' approach),
   while the other uses a shared point to multipoint tree rooted on a
   Multicast Server (MCS). This memo provides details on the design and
   implementation of an MCS, building on the core mechanisms defined in
   RFC 2022.  It also provides a mechanism for using multiple MCSs per
   group for providing fault tolerance.  This approach can be used with
   RFC 2022 based MARS server and clients, without needing any change in
   their functionality.

UNI3.0/3.1に基づいているATMネットワークの上で層の一般に、3つのプロトコル、および特にIPのマルチキャストの必要性を支持するメカニズムはRFC2022で説明されます。 2つの基本的なアプローチがIPパケットのイントラサブネット(イントラクラスタ)マルチキャスティングのために存在しています。 1つは多点VCs('VC Mesh'アプローチ)にポイントのメッシュを利用します、もう片方がMulticast Server(MCS)に根づいている多点木に共有されたポイントを使用しますが。 このメモはMCSの設計と実装に関する詳細を明らかにします、RFC2022で定義されたコアメカニズムの上に建てて。 また、それは耐障害性を提供するのに複数の1グループあたりのMCSsを使用するのにメカニズムを提供します。 彼らの機能性におけるどんな変化も必要としないで、2022年のRFCのベースの火星サーバとクライアントと共にこのアプローチを使用できます。

1 Introduction

1つの序論

   A solution to the problem of mapping layer 3 multicast service over
   the connection-oriented ATM service provided by UNI 3.0/3.1, has been
   presented in [GA96].  A Multicast Address Resolution Server (MARS) is
   used to maintain a mapping of layer 3 group addresses to ATM
   addresses in that architecture.  It can be considered to be an
   extended analog of the ATM ARP Server introduced in RFC 1577
   ([ML93]).  Hosts in the ATM network use the MARS to resolve layer 3
   multicast addresses into corresponding lists of ATM addresses of
   group members.  Hosts keep the MARS informed when they need to join
   or leave a particular layer 3 group.

接続指向のATMサービスがUNI3.0/3.1で提供して、提示された層3のマルチキャストサービスオーバー[GA96]を写像するという問題の解決。 Multicast Address Resolution Server(火星)は、層3のグループアドレスに関するマッピングをその構造のATMアドレスに維持するのに使用されます。 RFC1577([ML93])で導入されたATM ARP Serverの拡張アナログであることは考えることができます。 ATMネットワークのホストは、グループのメンバーのATMアドレスの対応するリストに層3のマルチキャストアドレスに変えるのに火星を使用します。 ホストは、彼らが、いつ接合する必要であるかを火星を知らせ続けるか、または3グループを特定の層に残します。

   The MARS manages a "cluster" of ATM-attached endpoints.  A "cluster"
   is defined as

火星はATMが付属している終点の「クラスタ」を管理します。 「クラスタ」は定義されます。

   "The set of ATM interfaces choosing to participate in direct ATM
   connections to achieve multicasting of AALSDUs between themselves."

「自分たちの間のAALSDUsのマルチキャスティングを達成するためにダイレクトATM接続に参加するのを選びながら、ATMのセットは連結します。」

Talpade & Ammar              Informational                      [Page 1]

RFC 2149             Multicast Server Architectures             May 1997

[1ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   In practice, a cluster is the set of endpoints that choose to use the
   same MARS to register their memberships and receive their updates
   from.

実際には、クラスタはそれらの会員資格を登録して、彼らのアップデートを受ける同じ火星を使用するのを選ぶ終点のセットです。

   A sender in the cluster has two options for multicasting data to the
   group members.  It can either get the list of ATM addresses
   constituting the group from the MARS, set up a point-to-multipoint
   virtual circuit (VC) with the group members as leaves, and then
   proceed to send data out on it.  Alternatively, the source can make
   use of a proxy Multicast Server (MCS).  The source transmits data to
   such an MCS, which in turn uses a point-to-multipoint VC to get the
   data to the group members.

クラスタの送付者はマルチキャスティングデータのための2つのオプションをグループのメンバーに持っています。 それは、ATMアドレスのリストに火星からグループを構成させて、グループのメンバーと共に葉としてポイントツーマルチポイントの仮想のサーキット(VC)をセットアップして、次に、それにデータを出しかけることができます。 あるいはまた、ソースはプロキシMulticast Server(MCS)を利用できます。 情報筋はそのようなMCSにデータを送ります。(順番に、MCSは、グループのメンバーにデータを届けるのにポイントツーマルチポイントVCを使用します)。

   The MCS approach has been briefly introduced in [GA96].  This memo
   presents a detailed description of MCS architecture and proposes a
   simple mechanism for supporting multiple MCSs for fault tolerance.
   We assume an understanding of the IP multicasting over UNI 3.0/3.1
   ATM network concepts described in [GA96], and access to it.  This
   document is organized as follows.  Section 2 presents interactions
   with the local UNI 3.0/3.1 signaling entity that are used later in
   the document and have been originally described in [GA96].  Section 3
   presents an MCS architecture, along with a description of its
   interactions with the MARS. Section 4 describes the working of an
   MCS. The possibility of using multiple MCSs for the same layer 3
   group, and the mechanism needed to support such usage, is described
   in section 5.  A comparison of the VC Mesh approach and the MCS
   approach is presented in Appendix A.

[GA96]で簡潔にMCSアプローチを導入しました。 このメモは、MCS構造の詳述を提示して、耐障害性のために複数のMCSsを支持するために簡単なメカニズムを提案します。 私たちは概念が[GA96]で説明したUNI3.0/3.1ATMネットワークの上のIPマルチキャスティングの理解、およびそれへのアクセスを仮定します。 このドキュメントは以下の通りまとめられます。 セクション2は後でドキュメントで使用されて、元々[GA96]で説明される地方のUNI3.0/3.1シグナリング実体との相互作用を提示します。 セクション3は火星との相互作用の記述に伴うMCS構造を提示します。 セクション4はMCSの働きについて説明します。 同じ層3のグループに複数のMCSsを使用する可能性、およびそのような用法を支持するのが必要であるメカニズムはセクション5で説明されます。 VC MeshアプローチとMCSアプローチの比較はAppendix Aに提示されます。

2 Interaction with the local UNI 3.0/3.1 signaling entity

地方のUNI3.0/3.1シグナリング実体との2相互作用

   The following generic signaling functions are presumed to be
   available to local AAL Users:

以下の一般的なシグナル伝達機能はあえて地方のAAL Usersに利用可能です:

   LCALL-RQ - Establish a unicast VC to a specific endpoint.
   LMULTI-RQ - Establish multicast VC to a specific endpoint.
   LMULTI-ADD - Add new leaf node to previously established VC.
   LMULTI-DROP - Remove specific leaf node from established VC.
   LRELEASE - Release unicast VC, or all Leaves of a multicast VC.

LCALL-RQ--特定の終点にユニキャストVCを設立してください。 LMULTI-RQ--特定の終点にマルチキャストVCを設立してください。 LMULTI-ADD--以前にへの新葉ノードがVCを設立したと言い足してください。 LMULTI-DROP--確立したVCから特定の葉のノードを取り除いてください。 LRELEASE--ユニキャストVC、またはマルチキャストVCのすべてのLeavesをリリースしてください。

   The following indications are assumed to be available to AAL Users,
   generated by by the local UNI 3.0/3.1 signaling entity:

以下の指摘は、地方のUNI3.0/3.1シグナリング実体でAAL Usersに利用可能であると思われて、発生します:

   LACK - Succesful completion of a local request.
   LREMOTE-CALL - A new VC has been established to the AAL User.
   ERRL-RQFAILED - A remote ATM endpoint rejected an LCALLRQ,
                         LMULTIRQ, or L-MULTIADD.
   ERRL-DROP - A remote ATM endpoint dropped off an existing VC.
   ERRL-RELEASE - An existing VC was terminated.

LACK--ローカルの要求のSuccesful完成。 LREMOTE-CALL--新しいVCはAAL Userに設立されました。 ERRL-RQFAILED--遠く離れたATM終点はLCALLRQ、LMULTIRQ、またはL-MULTIADDを拒絶しました。 ERRL-DROP--遠く離れたATM終点は既存のVCを降ろしました。 ERRL-RELEASE--既存のVCは終えられました。

Talpade & Ammar              Informational                      [Page 2]

RFC 2149             Multicast Server Architectures             May 1997

[2ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

3 MCS Architecture

3mc構造

   The MCS acts as a proxy server which multicasts data received from a
   source to the group members in the cluster.  All multicast sources
   transmitting to an MCS-based group send the data to the specified
   MCS. The MCS then forwards the data over a point to multipoint VC
   that it maintains to group members in the cluster.  Each multicast
   source thus maintains a single point-to-multipoint VC to the
   designated MCS for the group.  The designated MCS terminates one
   point-to-multipoint VC from each cluster member that is multicasting
   to the layer 3 group.  Each group member is the leaf of the point-
   to-multipoint VC originating from the MCS.

MCSはプロキシサーバとしてクラスタでソースからグループのメンバーまで受け取られたどのマルチキャストデータを機能させるか。 MCSを拠点とするグループに伝わるすべてのマルチキャスト情報筋が指定されたMCSにデータを送ります。 そして、MCSはそれがクラスタでメンバーを分類するために維持する多点VCへのポイントの上にデータを転送します。 その結果、それぞれのマルチキャストソースはグループのためにただ一つのポイントツーマルチポイントVCを指定されたMCSに維持します。 指定されたMCSはそれぞれのクラスタメンバーからの層3のグループへのマルチキャスティングである1つのポイントツーマルチポイントのVCを終えます。 それぞれのグループのメンバーは多点へのMCSから発するポイントVCの葉です。

   A brief introduction to possible MCS architectures has been presented
   in [GA96].  The main contribution of that document concerning the MCS
   approach is the specification of the MARS interaction with the MCS.
   The next section lists control messages exchanged by the MARS and
   MCS.

可能なMCS構造への簡潔な序論は[GA96]に提示されました。 MCSアプローチに関するそのドキュメントの主な貢献はMCSとの火星相互作用の仕様です。 次のセクションは火星とMCSによって交換されたコントロールメッセージをリストアップします。

3.1 Control Messages exchanged by the MCS and the MARS

3.1 MCSと火星で交換されたコントロールMessages

   The following control messages are exchanged by the MARS and the MCS.

以下のコントロールメッセージは火星とMCSによって交換されます。

   operation code                Control Message

命令コードControl Message

         1                       MARS_REQUEST
         2                       MARS_MULTI
         3                       MARS_MSERV
         6                       MARS_NAK
         7                       MARS_UNSERV
         8                       MARS_SJOIN
         9                       MARS_SLEAVE
        12                       MARS_REDIRECT_MAP

1 火星_要求2火星_マルチ3火星_MSERV6火星_NAK7火星_UNSERV8火星_SJOIN9火星_もつれ物12は_再直接の_地図を損ないます。

   MARSMSERV and MARS-UNSERV are identical in format to the MARSJOIN
   message.  MARSSJOIN and MARS-SLEAVE are also identical in format to
   MARSJOIN. As such, their formats and those of MARSREQUEST, MARS-
   MULTI, MARSNAK and MARSREDIRECT-MAP are described in [GA96].  Their
   usage is described in section 4.  All control messages are LLC/SNAP
   encapsulated as described in section 4.2 of [GA96].  (The "mar$"
   notation used in this document is borrowed from [GA96], and indicates
   a specific field in the control message.)  Data messages are
   reflected without any modification by the MCS.

MARSMSERVと火星-UNSERVは形式がMARSJOINメッセージと同じです。 また、MARSSJOINと火星-SLEAVEも形式がMARSJOINと同じです。 そういうものとして、火星のMARSREQUESTのそれらの形式ともの、MULTI、MARSNAK、およびMARSREDIRECT-MAPは[GA96]で説明されます。 それらの用法はセクション4で説明されます。 すべてのコントロールメッセージが[GA96]のセクション4.2で説明されるように要約されたLLC/SNAPです。 (記法が使用した「$を損なってください」は、[GA96]から本書では借りられて、コントロールメッセージで特定の野原を示します。) データメッセージは少しも変更なしでMCSによって反映されます。

Talpade & Ammar              Informational                      [Page 3]

RFC 2149             Multicast Server Architectures             May 1997

[3ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

3.2 Association with a layer 3 group

3.2 層3のグループとの協会

   The simplest MCS architecture involves taking incoming AALSDUs from
   the multicast sources and sending them out over the point-to-
   multipoint VC to the group members.  The MCS can service just one
   layer 3 group using this design, as it has no way of distinguishing
   between traffic destined for different groups.  So each layer 3 MCS-
   supported group will have its own designated MCS.

最も簡単なMCS構造は、ポイントから多点へのVCの上でマルチキャストソースから入って来るAALSDUsを取って、彼らを出すことをグループのメンバーに伴います。 このデザインを使用することでMCSはちょうど1つの層の3グループにサービスを提供できます、異なったグループのためにそれで交通を見分ける方法を全く運命づけていないとき。 それで、支持されたそれぞれの層3のMCSグループはそれ自身のものをMCSに指定させるでしょう。

   However it is desirable in the interests of saving resources to
   utilize the same MCS to support multiple groups.  This can be done by
   adding minimal layer 3 specific processing into the MCS. The MCS can
   now look inside the received AALSDUs and determine which layer 3
   group they are destined for.  A single instance of such an MCS could
   register its ATM address with the MARS for multiple layer 3 groups,
   and manage multiple point-to-multipoint VCs, one for each group.
   This capability is included in the MCS architecture, as is the
   capability of having multiple MCSs per group (section 5).

しかしながら、省資源のために、複数のグループを支持するのに同じMCSを利用するのは望ましいです。 最小量の層3の特定の処理をMCSに加えることによって、これができます。 MCSは、今、容認されたAALSDUsの中で見て、彼らがどの層3のグループに運命づけられているかを決定できます。 そのようなMCSのただ一つの例は、複数の層の3グループのためにATMアドレスを火星に登録して、複数のポイントツーマルチポイントVCs(各グループあたり1つ)に対処するかもしれません。 この能力は複数のグループ(セクション5)あたりのMCSsを持つ能力のようにMCS構造に含まれています。

4 Working of MCS

4 mcの働き

   An MCS MUST NOT share its ATM address with any other cluster member
   (MARS or otherwise).  However, it may share the same physical ATM
   interface (even with other MCSs or the MARS), provided that each
   logical entity has a different ATM address.  This section describes
   the working of MCS and its interactions with the MARS and other
   cluster members.

いかなる他のクラスタメンバーも(火星かそうではありません)でATMが記述するMCS MUST NOTシェア。 しかしながら、同じ物理的なATMインタフェース(他のMCSsか火星があっても)を共有するかもしれません、それぞれの論理的な実体に異なったATMアドレスがあれば。 このセクションは火星と他のクラスタメンバーとのMCSとその相互作用の働きについて説明します。

4.1 Usage of MARSMSERV and MARS-UNSERV

4.1 MARSMSERVと火星-UNSERVの使用法

4.1.1 Registration (and deregistration) with the MARS

4.1.1 火星との登録(そして、反登録)

   The ATM address of the MARS MUST be known to the MCS by out-of-band
   means at startup.  One possible approach for doing this is for the
   network administrator to specify the MARS address at command line
   while invoking the MCS. On startup, the MCS MUST open a point-to-
   point control VC (MARSVC) with the MARS. All traffic from the MCS to
   the MARS MUST be carried over the MARSVC. The MCS MUST register with
   the MARS using the MARS-MSERV message on startup.  To register, a
   MARSMSERV MUST be sent by the MCS to the MARS over the MARSVC. On
   receiving this MARS-MSERV, the MARS adds the MCS to the
   ServerControlVC. The ServerControlVC is maintained by the MARS with
   all MCSs as leaves, and is used to disseminate general control
   messages to all the MCSs.  The MCS MUST terminate this VC, and MUST
   expect a copy of the MCS registration MARSMSERV on the MARS-VC from
   the MARS.

バンドで出ている手段は始動でMCSにおいて火星のATMアドレスを知っていなければなりません。 これをするための1つの可能なアプローチはネットワーク管理者がMCSを呼び出している間、コマンドラインで火星アドレスを指定することです。 始動では、MCS MUSTは火星でポイントからポイントへのコントロールVC(MARSVC)を開きます。 すべてのMCSから火星までの交通をMARSVCの上まで運ばなければなりません。 MCS MUSTは、始動に関する火星-MSERVメッセージを使用することで火星とともに記名します。 a MARSMSERV MUST、登録してください。MCSによってMARSVCの上の火星に送られてください。 この火星-MSERVを受けると、火星はServerControlVCにMCSを加えます。 ServerControlVCはいなくなって、一般的なコントロールメッセージをすべてのMCSsに広めるのに使用されるすべてのMCSsと共に火星によって維持されます。 MCS MUSTはこのVCを終えて、火星-VCで火星からMCS登録MARSMSERVにコピーを予想しなければなりません。

Talpade & Ammar              Informational                      [Page 4]

RFC 2149             Multicast Server Architectures             May 1997

[4ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   An MCS can deregister by sending a MARSUNSERV to the MARS. A copy of
   this MARSUNSERV MUST be expected back from the MARS. The MCS will
   then be dropped from the ServerControlVC.

MCSはMARSUNSERVを火星に送るのによる「反-レジスタ」をそうすることができます。 AはこのMARSUNSERV MUSTをコピーします。火星から、予想されます。 そして、MCSはServerControlVCから落とされるでしょう。

   No protocol specific group addresses are included in MCS registration
   MARSMSERV and MARS-UNSERV. The mar$flags.register bit MUST be set,
   the mar$cmi field MUST be set to zero, the mar$flags.sequence field
   MUST be set to zero, the source ATM address MUST be included and a
   null source protocol address MAY be specified in these MARSMSERV and
   MARS-UNSERV. All other fields are set as described in section 5.2.1
   of [GA96] (the MCS can be considered to be a cluster member while
   reading that section).  It MUST keep retransmitting (section 4.1.3)
   the MARSMSERV/MARS-UNSERV over the MARSVC until it receives a copy
   back.

どんなプロトコルの特定のグループアドレスもMCS登録MARSMSERVと火星-UNSERVに含まれていません。 $flags.registerビットを損なってください。設定しなければならない、合わせてくださいcmi分野を設定しなければならないゼロ$を損なってください、合わせてくださいflags.sequence分野を設定しなければならないゼロ$を損なってください、そして、ソースATMアドレスを含まなければならなくて、aヌルソースプロトコルアドレスはこれらのMARSMSERVと火星-UNSERVで指定されてもよいです。 他のすべての分野が.1セクション5.2[GA96]で説明されるように設定されます(そのセクションを読んでいる間のクラスタメンバーであるとMCSを考えることができます)。 それはコピーを受け返すまで火星MARSMSERV/UNSERVをMARSVCの上に再送し(セクション4.1.3)続けなければなりません。

   In case of failure to open the MARSVC, or error on it, the
   reconnection procedure outlined in section 4.5.2 is to be followed.

MARSVCを開かないこと、またはそれにおける誤りの場合には、セクション4.5.2に概説された再接続手順は続かれることです。

4.1.2 Registration (and deregistration) of layer 3 groups

4.1.2 層3のグループの登録(そして、反登録)

   The MCS can register with the MARS to support particular group(s).
   To register groups X through Y, a MARSMSERV with a <min, max> pair of
   <X, Y> MUST be sent to the MARS. The MCS MUST expect a copy of the
   MARSMSERV back from the MARS. The retransmission strategy outlined in
   section 4.1.3 is to be followed if no copy is received.

MCSは、特定のグループを支持するために火星とともに記名することができます。 登録するために、グループXからY(<分があるMARSMSERV)は<Xの>組に最大限にして、Y>を火星に送らなければなりません。 MCS MUSTは火星からMARSMSERVにコピーを予想します。 セクション4.1.3に概説された「再-トランスミッション」戦略はどんなコピーも受け取られていないなら続かれることです。

   The MCS MUST similarly use MARSUNSERV if it wants to withdraw support
   for a specific layer 3 group.  A copy of the group MARSUNSERV MUST be
   received, failing which the retransmission strategy in section 4.1.3
   is to be followed.

特定の層3のグループのサポートを引き下がらせたいなら、MCS MUSTは同様にMARSUNSERVを使用します。 セクション4.1.3における「再-トランスミッション」戦略はグループMARSUNSERV MUSTのコピーを受け取って、どれに失敗して、続かれることです。

   The mar$flags.register bit MUST be reset and the mar$flags.sequence
   field MUST be set to zero in the group MARSMSERV and MARS-UNSERV. All
   other fields are set as described in section 5.2.1 of [GA96] (the MCS
   can be considered to be a cluster member when reading that section).

そして、損なう、flags.registerが噛み付いた$をリセットしなければならない、グループMARSMSERVと火星-UNSERVで合わせてくださいflags.sequence分野を設定しなければならないゼロ$を損なってください。 他のすべての分野が.1セクション5.2[GA96]で説明されるように設定されます(そのセクションを読むときのクラスタメンバーであるとMCSを考えることができます)。

4.1.3 Retransmission of MARSMSERV and MARS-UNSERV

4.1.3 MARSMSERVと火星-UNSERVのRetransmission

   Transient problems may cause loss of control messages.  The MCS needs
   to retransmit MARSMSERV/MARS-UNSERV at regular intervals when it does
   not receive a copy back from the MARS. This interval should be no
   shorter than 5 seconds, and a default value of 10 seconds is
   recommended.  A maximum of 5 retransmissions are permitted before a
   failure is logged.  This MUST be considered a MARS failure, which
   SHOULD result in the MARS reconnection mechanism described in section
   4.5.2.

過渡現象の問題は制御不能メッセージを引き起こすかもしれません。 MCSは、それが火星からコピーを受けない一定の間隔で、火星MARSMSERV/UNSERVを再送する必要があります。 この間隔は5秒より短いはずがありません、そして、10秒のデフォルト値はお勧めです。 失敗が登録される前に最大5個の「再-トランスミッション」が受入れられます。 火星失敗であるとこれを考えなければなりません。(火星再接続メカニズムのSHOULD結果はセクション4.5.2でそれについて説明しました)。

Talpade & Ammar              Informational                      [Page 5]

RFC 2149             Multicast Server Architectures             May 1997

[5ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   A "copy" is defined as a received message with the following fields
   matching the previously transmitted MARSMSERV/MARS-UNSERV:

以下の分野が以前に伝えられた火星MARSMSERV/UNSERVに合っていて、「コピー」は受信されたメッセージと定義されます:

   -  mar$op
   -  mar$flags.register
   -  mar$pnum
   -  Source ATM address
   -  first <min, max> pair

- $オプアートを損なってください--$flags.registerを損なってください--最大>組は$pnum--ソースATMアドレス--最初の<分を損なってください。

   In addition, a valid copy MUST have the following field values:

さらに、有効なコピーには、以下の分野値がなければなりません:

   -  mar$flags.punched = 0
   -  mar$flags.copy = 1

- flags.punched=0ドルを損なってください--flags.copy=1ドルを損なってください。

   If either of the above is not true, the message MUST be dropped
   without resetting of the MARSMSERV/MARS-UNSERV timer.  There MUST be
   only one MARSMSERV or MARS-UNSERV outstanding at a time.

上記のどちらかが本当でないなら、火星MARSMSERV/UNSERVタイマのリセットなしでメッセージを落とさなければなりません。 一度に未払いの1MARSMSERVか火星-UNSERVしかないに違いありません。

4.1.4 Processing of MARSMSERV and MARS-UNSERV

4.1.4 MARSMSERVと火星-UNSERVの処理

   The MARS transmits copies of group MARSMSERV and MARS-UNSERV on the
   ServerControlVC. So they are also received by MCSs other than the
   originating one.  This section discusses the processing of these
   messages by the other MCSs.

火星はServerControlVCでグループMARSMSERVと火星-UNSERVのコピーを伝えます。 それで、また、それらは由来しているもの以外のMCSsによって受け取られます。 このセクションは他のMCSsによるこれらのメッセージの処理について論じます。

   If a MARSMSERV is seen that refers to a layer 3 group not supported
   by the MCS, it MUST be used to track the Server Sequence Number
   (section 4.5.1) and then silently dropped.

MARSMSERVが見られるならそれが3グループがMCSで支えなかった層について言及して、それをServer Sequence Number(セクション4.5.1)を追跡するのに使用されて、次に、静かに落とさなければなりません。

   If a MARSMSERV is seen that refers to a layer 3 group supported by
   the MCS, the MCS learns of the existence of another MCS supporting
   the same group.  This possibility is incorporated (of multiple MCSs
   per group) in this version of the MCS approach and is discussed in
   section 5.

3グループがMCSで支えた層について言及するMARSMSERVが見られるなら、MCSは同じグループを支持する別のMCSの存在を知っています。 この可能性について、MCSアプローチのこのバージョンに組み込んで(複数の1グループあたりのMCSsの)、セクション5で議論します。

4.2 Usage of MARSREQUEST and MARS-MULTI

4.2 MARSREQUESTと火星マルチの用法

   As described in section 5.1, the MCS learns at startup whether it is
   an active or inactive MCS. After successful registration with the
   MARS, an MCS which has been designated as inactive for a particular
   group MUST NOT register to support that group with the MARS. It
   instead proceeds as in section 5.4.  The active MCS for a group also
   has to do some special processing, which we describe in that section.
   The rest of section 4 describes the working of a single active MCS,
   with section 5 describing the active MCSs actions for supporting
   multiple MCSs.

セクション5.1で説明されるように、MCSは、始動でそれがアクティブであるか不活発なMCSであるかどうか学びます。 火星とのうまくいっている登録の後に、特定のグループに不活発な状態で任じられたMCSは、火星でそのグループを支持するために登録してはいけません。 それは代わりにセクション5.4のように続きます。 グループのためのアクティブなMCSも何らかの特別な処理をしなければなりません。(私たちはそのセクションでそれについて説明します)。 セクション4の残りは独身のアクティブなMCSの働きについて説明します、セクション5が複数のMCSsを支持するための活発なMCSs行為について説明している状態で。

Talpade & Ammar              Informational                      [Page 6]

RFC 2149             Multicast Server Architectures             May 1997

[6ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   After the active MCS registers to support a layer 3 group, it uses
   MARSREQUEST and MARS-MULTI to obtain information about group
   membership from the MARS. These messages are also used during the
   revalidation phase (section 4.5) and when no outgoing VC exists for a
   received layer 3 packet (section 4.3).

アクティブなMCSが層3のグループを支持するために登録した後に、それは、火星からグループ会員資格の情報を得るのにMARSREQUESTと火星-MULTIを使用します。 また、これらのメッセージは再合法化フェーズ(セクション4.5)、どんな出発しているVCも容認された層3のパケット(セクション4.3)のために存在しないときに時使用されます。

   On registering to support a particular layer 3 group, the MCS MUST
   send a MARSREQUEST to the MARS. The mechanism to retrieve group
   membership and the format of MARSREQUEST and MARS-MULTI is described
   in section 5.1.1 and 5.1.2 of [GA96] respectively.  The MCS MUST use
   this mechanism for sending (and retransmitting) the MARSREQUEST and
   processing the returned MARSMULTI(/s).  The MARS-MULTI MUST be
   received correctly, and the MCS MUST use it to initialize its
   knowledge of group membership.

特定の層3のグループを支持するために登録すると、MCS MUSTはMARSREQUESTを火星に送ります。 グループ会員資格を検索するメカニズムとMARSREQUESTと火星-MULTIの形式は説明されたコネセクション5.1.1であり、5.1は.2[GA96]です。それぞれ。 MCS MUSTは、MARSREQUESTを送って(そして、再送します)、返されたMARSMULTI(/s)を処理するのにこのメカニズムを使用します。 火星-MULTI MUST、正しく受け取られていてください。そうすれば、MCS MUSTは、グループ会員資格に関する知識を初期化するのにそれを使用します。

   On successful reception of a MARSMULTI, the MCS MUST attempt to open
   the outgoing point-to-multipoint VC using the mechanism described in
   section 5.1.3 of [GA96], if any group members exist.  The MCS however
   MUST start transmitting data on this VC after it has opened it
   successfully with at least one of the group members as a leaf, and
   after it has attempted to add all the group members at least once.

MARSMULTIのうまくいっているレセプションでは、メカニズムを使用することで外向的なポイントツーマルチポイントVCを開くMCS MUST試みはセクション5.1で.3[GA96]について説明しました、どれかグループのメンバーが存在するなら。 しかしながら、少なくともグループのメンバーのひとりと共に葉としてそれを首尾よく開いた後、および少なくとも一度すべてのグループのメンバーを加えるのを試みた後にMCSは、データを送りこのVCを始めなければなりません。

4.3 Usage of outgoing point-to-multipoint VC

4.3 外向的なポイントツーマルチポイントVCの使用法

   Cluster members which are sources for MCS-supported layer 3 groups
   send (encapsulated) layer 3 packets to the designated MCSs.  An MCS,
   on receiving them from cluster members, has to send them out over the
   specific point-to-multipoint VC for that layer 3 group.  This VC is
   setup as described in the previous section.  However, it is possible
   that no group members currently exist, thus causing no VC to be
   setup.  So an MCS may have no outgoing VC to forward received layer 3
   packets on, in which case it MUST initiate the MARSREQUEST and MARS-
   MULTI sequence described in the previous section.  This new MARSMULTI
   could contain new members, whose MARSSJOINs may have been not
   received by the MCS (and the loss not detected due to absence of
   traffic on the ServerControlVC).

MCSによって支持された層3のグループが発信するので(要約されます)、ソースであるクラスタメンバーは3つのパケットを指定されたMCSsに層にします。 クラスタメンバーから彼らを受けるとき、MCSはその層3のグループのために特定のポイントツーマルチポイントVCの上に彼らを出さなければなりません。 このVCは前項で説明されるようにセットアップです。 しかしながら、どんなグループのメンバーも現在、存在して、その結果、どんなVCもセットアップでないことを引き起こすことがないのは可能です。 それで、MCSは3つのパケットを容認された層に送るどんな出発しているVCもオンに持っていないかもしれません、その場合、それが系列が前項で説明したMULTIのMARSREQUESTと火星を開始しなければなりません。 この新しいMARSMULTIはMARSSJOINsがMCS(そして、ServerControlVCにおける交通の欠如のため検出されなかった損失)によって受け取られていないかもしれない新しいメンバーを含むことができました。

   If an MCS learns that there are no group members (MARSNAK received
   from MARS), it MUST delay sending out a new MARSREQUEST for that
   group for a period no less than 5 seconds and no more than 10
   seconds.

MCSが、グループのメンバーが全くいないことを学ぶなら(MARSNAKは火星から受信しました)、それは、しばらくそのグループのために新しいMARSREQUESTを5秒未満のノー、そして10秒未満出すのを遅らせなければなりません。

   Layer 3 packets received from cluster members, while no outgoing
   point-to-multipoint VC exists for that group, MUST be silently
   dropped after following the guidelines in the previous paragraphs.
   This might result in some layer 3 packets being lost until the VC is
   setup.

前のパラグラフのガイドラインに従った後に、外向的なポイントツーマルチポイントがないVCがそのグループのために存在している間、静かにクラスタメンバーから受け取られた層3のパケットを落とさなければなりません。 これはVCがセットアップになるまで失われているいくつかの層の3パケットをもたらすかもしれません。

Talpade & Ammar              Informational                      [Page 7]

RFC 2149             Multicast Server Architectures             May 1997

[7ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   Each outgoing point-to-multipoint VC has a revalidate flag associated
   with it.  This flag MUST be checked whenever a layer 3 packet is sent
   out on that VC. No action is taken if it is not set.  If it is set,
   the packet is sent out, the revalidation procedure (section 4.5.3)
   MUST be initiated for this group, and the flag MUST be reset.

それぞれの外向的なポイントツーマルチポイントVCには、それに関連しているrevalidate旗があります。 層3のパケットをそのVCに出すときはいつも、この旗をチェックしなければなりません。 それを設定しないなら、行動を全く取りません。 それを設定するなら、パケットを出します、そして、このグループのために、再合法化手順(セクション4.5.3)に着手しなければなりません、そして、旗をリセットしなければなりません。

   In case of error on a point-to-multipoint VC, the MCS MUST initiate
   revalidation procedures for that VC as described in section 4.5.3.
   Once a point-to-multipoint VC has been setup for a particular layer 3
   group, the MCS MUST hold the VC open and mark it as the outgoing path
   for any subsequent layer 3 packets being sent for that group address.
   A point-to-multipoint VC MUST NOT have an activity timer associated
   with it.  It is to remain up at all times, unless the MCS explicitly
   stops supporting that layer 3 group, or no more leaves exist on the
   VC which causes it to be shut down.  The VC is kept up inspite of
   non-existent traffic to reduce the delay suffered by MCS supported
   groups.  If the VC were to be shut down on absence of traffic, the VC
   reestablishment procedure (needed when new traffic for the layer 3
   group appears) would further increase the initial delay, which can be
   potentially higher than the VC mesh approach anyway as two VCs need
   to be setup in the MCS case (one from source to MCS, second from MCS
   to group) as opposed to only one (from source to group) in the VC
   Mesh approach.  This approach of keeping the VC from the MCS open
   even in the absense of traffic is experimental.  A decision either
   way can only be made after gaining experience (either through
   implementation or simulation) about the implications of keeping the
   VC open.

ポイントツーマルチポイントVCにおける誤りの場合には、MCS MUSTはそのVCのためにセクション4.5.3で説明されるように再合法化手順に着手します。 かつてのVCが特定の層3のグループ、VCが開くMCS MUST保持のためのセットアップであり、そのグループアドレスのために送られるどんなその後の層3のパケットのためにも外向的な経路としてそれをマークするのをさせるポイントツーマルチポイント。 ポイントツーマルチポイントVC MUST NOTには、それに関連している活動タイマがあります。 いつも上がって、MCSが明らかに止まらない場合残るために、その層3を支えるのが分類されるか、またはそれ以上の葉がそれを止めさせるVCに存在しないということです。 VCによるMCSによって受けられた遅れを減少させる実在しない交通の維持された「不-悪意」がグループを支持したということです。 VCが交通の欠如のときに止められることになっているなら、VC再建手順(層3のグループのための新しい交通が現れるのが必要である)は初期の遅れをさらに増加させるでしょうに。(2VCsが、VC Meshアプローチにおける1(ソースからグループまでの)だけと対照的にMCS場合(ソースからMCSからグループに次ぐ2番目のMCSまでの1)におけるセットアップである必要があるとき、それは、VCメッシュアプローチより潜在的にとにかく高い場合があります)。 交通のabsenseでさえ開いているMCSからVCを妨げるこのアプローチは実験的です。 VCを開くように保つ含意に関して経験を積んだ(実現かシミュレーションで)後に、いずれにせよ決定をすることができるだけです。

   If the MCS supports multiple layer 3 groups, it MUST follow the
   procedure outlined in the four previous subsections for each group
   that it is an active MCS. Each incoming data AALSDU MUST be examined
   for determining its recipient group, before being forwarded onto the
   appropriate outgoing point-to-multipoint VC.

MCSが複数の層の3グループを支持するなら、それがアクティブなMCSであることは前の各グループあたり4つの小区分に概説された手順に従わなければなりません。 それぞれの受信データAALSDU MUST、受取人グループを決定するのがないかどうか調べられてください、適切な外向的なポイントツーマルチポイントVCに送る前に。

4.3.1 Group member dropping off a point-to-multipoint VC

4.3.1 ポイントツーマルチポイントVCを降ろすグループのメンバー

   AN ERRL-DROP may be received during the lifetime of a point-to-
   multipoint VC indicating that a leaf node has terminated its
   participation at the ATM level.  The ATM endpoint associated with the
   ERRL-DROP MUST be removed from the locally held set associated with
   the VC. The revalidate flag on the VC MUST be set after a random
   interval of 1 through 10 seconds.

ポイントから多点への葉のノードがATMレベルで参加を終えたのを示すVCの生涯AN ERRL-DROPを受け取るかもしれません。 VCに関連している局所的に保持されたセットから取り外されるERRL-DROP MUSTに関連しているATM終点。 revalidateは1〜10の無作為の間隔の後のセットが秒であったならVC MUSTで弛みます。

   If an ERRL-RELEASE is received for a VC, then the entire set is
   cleared and the VC considered to be completely shutdown.  A new VC
   for this layer 3 group will be established only on reception of new
   traffic for the group (as described in section 4.3).

VCのためにERRL-RELEASEを受け取るなら、全体のセットをきれいにしました、そして、VCは完全に閉鎖であると考えました。 この層3のグループのための新しいVCはグループのために新しい交通のレセプションだけに設立されるでしょう(セクション4.3で説明されるように)。

Talpade & Ammar              Informational                      [Page 8]

RFC 2149             Multicast Server Architectures             May 1997

[8ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

4.4 Processing of MARSSJOIN and MARS-SLEAVE

4.4 MARSSJOINと火星もつれ物の処理

   The MARS transmits equivalent MARSSJOIN/MARS-SLEAVE on the
   ServerControlVC when it receives MARSJOIN/MARS-LEAVE from cluster
   members.  The MCSs keep track of group membership updates through
   these messages.  The format of these messages are identical to
   MARSJOIN and MARS-LEAVE, which are described in section 5.2.1 of
   [GA96].  It is sufficient to note here that these messages carry the
   ATM address of the node joining/leaving the group(/s), the group(/s)
   being joined or left, and a Server Sequence Number from MARS.

クラスタメンバーから火星MARSJOIN/LEAVEを受けるとき、火星はServerControlVCで同等な火星MARSSJOIN/SLEAVEを伝えます。 MCSsはこれらのメッセージを通したグループ会員資格最新版の動向をおさえます。 これらのメッセージの形式はMARSJOINと火星-LEAVEと同じです。(LEAVEは.1セクション5.2[GA96]で説明されます)。 ここでグループを火星から(/s)、加わられるか、または残されるグループ(/s)、およびServer Sequence Numberに加わるか、または外して、これらのメッセージがノードのATMアドレスを運ぶことに注意するのは十分です。

   When a MARSSJOIN is seen which refers to (or encompasses) a layer 3
   group (or groups) supported by the MCS, the following action MUST be
   taken.  The new member's ATM address is extracted from the MARSSJOIN.
   An L-MULTIADD is issued for the new member for each of those referred
   groups which have an outgoing point-to-multipoint VC. An LMULTI-RQ is
   issued for the new member for each of those refered groups which have
   no outgoing VCs.

MARSSJOINがいつまで見られるか、(示されます)(取り囲む、)、3グループ(または、グループ)がMCSで支えた層、以下の行動を取らなければなりません。 新しいメンバーのATMアドレスはMARSSJOINから抜粋されます。 L-MULTIADDは外向的なポイントツーマルチポイントVCを持っているそれぞれのそれらの参照されたグループの新しいメンバーのために発行されます。 LMULTI-RQはどんな出発しているVCsも持っていないそれぞれのそれらのreferedグループの新しいメンバーのために発行されます。

   When a MARSSLEAVE is seen that refers to (or encompasses) a layer 3
   group (or groups) supported by the MCS, the following action MUST be
   taken.  The leaving member's ATM address is extracted.  An LMULTI-
   DROP is issued for the member for each of the refered groups which
   have an outgoing point-to-multipoint VC.

参照するMARSSLEAVEがいつまで見られるか、(取り囲む、)、3グループ(または、グループ)がMCSで支えた層、以下の行動を取らなければなりません。 いなくなっているメンバーのATMアドレスは抜粋されます。 LMULTI- DROPは外向的なポイントツーマルチポイントVCを持っているそれぞれのreferedグループのメンバーのために発行されます。

   There is a possibility of the above requests (LMULTI-RQ or LMULTIADD
   or LMULTI-DROP) failing.  The UNI 3.0/3.1 failure cause must be
   returned in the ERRL-RQFAILED signal from the local signaling entity
   to the AAL User.  If the failure cause is not 49 (Quality of Service
   unavailable), 51 (user cell rate not available - UNI 3.0), 37 (user
   cell rate not available - UNI 3.1), or 41 (Temporary failure), the
   endpoint's ATM address is dropped from the locally held view of the
   group by the MCS. Otherwise, the request MUST be re-attempted with
   increasing delay (initial value between 5 to 10 seconds, with delay
   value doubling after each attempt) until it either succeeds or the
   multipoint VC is released or a MARSSLEAVE is received for that group
   member.  If the VC is open, traffic on the VC MUST continue during
   these attempts.

失敗する上記の要求(LMULTI-RQ、LMULTIADDまたはLMULTI-DROP)の可能性があります。 ERRL-RQFAILED信号で地方のシグナリング実体からAAL UserまでUNI3.0/3.1失敗原因を返さなければなりません。 失敗原因が49(入手できないServiceの品質)でないなら、51(有効でないユーザセルレート--UNI3.0)、37(有効でないユーザセルレート--UNI3.1)、または41(一時障害)、終点のATMアドレスがMCSによるグループの局所的に保持された視点から落とされます。 さもなければ、成功するか、多点VCをリリースするか、またはそのグループのメンバーのためにMARSSLEAVEを受け取るまで、要求は増加で再試みられた遅れであるに違いありません(遅れ値が各試みの後に倍増している5〜10秒の間の初期の値)。 VCがそうなら、戸外、VC MUSTにおける交通はこれらの試みの間、続きます。

   MARSSJOIN and MARS-SLEAVE are processed differently if multiple MCSs
   share the members of the same layer 3 group (section 5.4).  MARSSJOIN
   and MARSSLEAVE that do not refer to (or encompass) supported groups
   MUST be used to track the Server Sequence Number (section 4.5.1), but
   are otherwise ignored.

複数のMCSsが同じ層3のグループ(セクション5.4)のメンバーを共有するなら、MARSSJOINと火星-SLEAVEは異なって処理されます。 参照しないMARSSJOINとMARSSLEAVE、(取り囲む、)、支持されたグループは、Server Sequence Number(セクション4.5.1)を追跡するのに使用しなければなりませんが、別の方法で無視されます。

Talpade & Ammar              Informational                      [Page 9]

RFC 2149             Multicast Server Architectures             May 1997

[9ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

4.5 Revalidation Procedures

4.5 Revalidation手順

   The MCS has to initiate revalidation procedures in case of certain
   failures or errors.

MCSはある失敗か誤りの場合に再合法化手順に着手しなければなりません。

4.5.1 Server Sequence Number

4.5.1 サーバ一連番号

   The MCS needs to track the Server Sequence Number (SSN) in the
   messages received on the ServerControlVC from the MARS. It is carried
   in the mar$msn of all messages (except MARSNAK) sent by the MARS to
   MCSs.  A jump in SSN implies that the MCS missed the previous
   message(/s) sent by the MARS. The MCS then sets the revalidate flag
   on all outgoing point-to-multipoint VCs after a random delay of
   between 1 and 10 seconds, to avoid all MCSs inundating the MARS
   simultaneously in case of a more general failure.

MCSは、ServerControlVCに火星から受け取られたメッセージでServer Sequence Number(SSN)を追跡する必要があります。 それが運ばれる、火星でMCSsに送られたすべてのメッセージ(MARSNAKを除いた)の$msnを損なってください。 SSNでのジャンプは、MCSが火星で送られた前のメッセージ(/s)を逃したのを含意します。 そして、MCSは、1〜10秒の無作為の遅れの後に同時により一般的な失敗の場合に火星を水浸しにするすべてのMCSsを避けるためにすべての外向的なポイントツーマルチポイントVCsの上にrevalidate旗を置きます。

   The only exception to the rule is if a sequence number is detected
   during the establishment of a new group's VC (i.e.  a MARSMULTI was
   correctly received, but its mar$msn indicated that some previous MARS
   traffic had been missed on ClusterControlVC). In this case every open
   VC, EXCEPT the one just being established, MUST have its revalidate
   flag set at some random interval between 1 and 10 seconds from the
   time the jump in SSN was detected.  (The VC being established is
   considered already validated in this case).

規則への唯一の例外は一連番号が新しいグループのVCの設立の間、検出されるかどうかということです。しかし、(正しくすなわち、MARSMULTIを受け取った、それ、ClusterControlVCで逃された状態でmsnが示した前の何らかの火星交通があった$を損なってください、) この場合、ただ確立されるもの以外のあらゆる開いているVCがrevalidate旗をSSNでのジャンプが検出された時からの1〜10秒のいくつかの無作為の間隔で、設定させなければなりません。 (設立されるVCはこの場合既に有効にされると考えられます。)

   Each MCS keeps its own 32 bit MCS Sequence Number (MSN) to track the
   SSN.  Whenever a message is received that carries a mar$msn field,
   the following processing is performed:

各MCSは、それ自身の32ビットがSSNを追跡するMCS Sequence Number(MSN)であることを保ちます。 桁上げaが$msn分野を損なうというメッセージが受信されているときはいつも、以下の処理は実行されます:

        Seq.diff = mar$msn - MSN

Seq.diff=は$msnを損ないます--、MSN

        mar$msn -> MSN

$msn->MSNを損なってください。

        (.... process MARS message ....)

(… . 加工処理した火星メッセージ…。)

        if ((Seq.diff != 1) && (Seq.diff != 0))
              then (.... revalidate group membership information ....)

(Seq.diff!=1)である、(Seq.diff!=0)その時(… . revalidateは会員資格情報を分類します…)

   The mar$msn value in an individual MARSMULTI is not used to update
   the MSN until all parts of the MARSMULTI (if > 1) have arrived.  (If
   the mar$msn changes during reception of a MARSMULTI series, the
   MARS-MULTI is discarded as described in section 5.1.1 of [GA96]).

MARSMULTI(>1であるなら)のすべての部分が到着するまでMSNをアップデートするのに使用されないmsnが個々のMARSMULTIで評価する$を損なってください。 (MARSMULTIシリーズ(.1セクション5.1[GA96)で説明されるように捨てられた火星-MULTI)のレセプションの間、$のmsn変化を損なってください。

   The MCS sets its MSN to zero on startup.  It gets the current value
   of SSN when it receives the copy of the registration MARSMSERV back
   from the MARS.

MCSは始動のゼロにMSNを設定します。 火星から登録MARSMSERVのコピーを受けるとき、それはSSNの現行価値を得ます。

Talpade & Ammar              Informational                     [Page 10]

RFC 2149             Multicast Server Architectures             May 1997

[10ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

4.5.2 Reconnecting to the MARS

4.5.2 火星に再接続すること。

   The MCSs are assumed to have been configured with the ATM address of
   at least one MARS at startup.  MCSs MAY choose to maintain a table of
   ATM addresses, each address representing alternative MARS which will
   be contacted in case of failure of the previous one.  This table is
   assumed to be ordered in descending order of preference.

始動の少なくとも1つの火星のATMアドレスによってMCSsが構成されたと思われます。 MCSsは、ATMアドレス(前のものの失敗の場合に連絡される代替の火星を表す各アドレス)のテーブルを維持するのを選ぶかもしれません。 このテーブルによって好みの降順で命令されると思われます。

   An MCS will decide that it has problems communicating with a MARS if:

MCSが、それには火星で交信することにおける問題があると決める、:

      * It fails to establish a point-to-point VC with the MARS.

* それは火星で二地点間VCを設立しません。

      * MARSREQUEST generates no response (no MARSMULTI or MARS-NAK
      returned).

* MARSREQUESTは応答を全く発生させません(どんなMARSMULTIも火星-NAKも戻りませんでした)。

      * ServerControlVC fails.

* ServerControlVCは失敗します。

      * MARSMSERV or MARSUNSERV do not result in their respective copies
      being
        received.

* MARSMSERVかMARSUNSERVが受け取られるそれらのそれぞれのコピーをもたらしません。

   (reconnection as in section 5.4 in [GA96], with MCS-specific actions
   used where needed).

([GA96]のセクション5.4、必要であるところで使用されるMCS特有の動作による再接続。)

4.5.3 Revalidating a point-to-multipoint VC

4.5.3 ポイントツーマルチポイントVCをRevalidatingすること。

   The revalidation flag associated with a point-to-multipoint VC is
   checked when a layer 3 packet is to be sent out on the VC.
   Revalidation procedures MUST be initiated for a point-to-multipoint
   VC that has its revalidate flag set when a layer 3 packet is being
   sent out on it.  Thus more active groups get revalidated faster than
   less active ones.  The revalidation process MUST NOT result in
   disruption of normal traffic on the VC being revalidated.

ポイントツーマルチポイントVCに関連している再合法化旗は層であるときに、チェックされて、3パケットがVCに出されることになっているということです。 それで層の3パケットを出しているときrevalidate旗を設定させるポイントツーマルチポイントVCのためにRevalidation手順に着手しなければなりません。 したがって、より活動的なグループはそれほどアクティブでないものより速く再有効にされます。 再合法化の過程は再有効にされるVCにおける通常の交通の分裂をもたらしてはいけません。

   The revalidation procedure is as follows.  The MCS reissues a
   MARSREQUEST for the VC being revalidated.  The returned set of
   members is compared with the locally held set; LMULTI-ADDs MUST be
   issued for new members, and LMULTI-DROPs MUST be issued for non-
   existent ones.  The revalidate flag MUST be reset for the VC.

再合法化手順は以下の通りです。 MCSは再有効にされるVCのためにMARSREQUESTを再発行します。 返されたセットのメンバーは局所的に保持されたセットと比較されます。 新しいメンバーのためにLMULTI-ADDsを発行しなければなりません、そして、非目下のもののためにLMULTI-DROPsを発行しなければなりません。 VCのためにrevalidate旗をリセットしなければなりません。

5 Multiple MCSs for a layer 3 group

5 層3のグループのための複数のMCSs

   Having a single MCS for a layer 3 group can cause it to become a
   single point of failure and a bottleneck for groups with large
   numbers of active senders.  It is thus desirable to introduce a level
   of fault tolerance by having multiple MCS per group.  Support for
   load sharing is not introduced in this document as to reduce the
   complexity of the protocol.

層のための独身のMCSを持っていて、それは多くの活発な送付者と共に3グループによって1ポイントの失敗とグループのためのボトルネックになることができます。 その結果、複数の1グループあたりのMCSを持っていることによって耐障害性のレベルを導入するのは望ましいです。 負荷分割法のサポートはプロトコルの複雑さを減少させるくらいには本書では導入されません。

Talpade & Ammar              Informational                     [Page 11]

RFC 2149             Multicast Server Architectures             May 1997

[11ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

5.1 Outline

5.1 アウトライン

   The protocol described in this document offers fault tolerance by
   using multiple MCSs for the same group.  This is achieved by having a
   standby MCS take over from a failed MCS which had been supporting the
   group.  The MCS currently supporting a group is refered to as the
   active MCS, while the one or more standby MCSs are refered to as
   inactive MCSs.  There is only one active MCS existing at any given
   instant for an MCS-supported group.  The protocol makes use of the
   HELLO messages as described in [LA96].

本書では説明されたプロトコルは、同じグループに複数のMCSsを使用することによって、耐障害性を提供します。 これは、MCSがグループを支持し続けていた失敗したMCSから引き継ぐ予備を持っていることによって、達成されます。 現在グループを支持するのがものである間、アクティブなMCSとしてreferedされるか、または、より多くの予備MCSsが不活発なMCSsとしてreferedされるMCS。 MCSによって支持されたグループのためのどんな与えられた瞬間にも存在する1アクティブなMCSしかありません。 プロトコルは[LA96]で説明されるようにHELLOメッセージを利用します。

   To reduce the complexity of the protocol, the following operational
   guidelines need to be followed.  These guidelines need to be enforced
   by out-of-band means which are not specified in this document and can
   be implementation dependent.

プロトコルの複雑さを減少させるために、以下の運用指針は、続かれる必要があります。 これらのガイドラインは、バンドの外による本書では指定されない実施された手段であることが必要であり、実現に依存している場合があります。

      * The set of (one or more) MCSs ("mcslist") that support a
        particular IP Multicast group is predetermined and fixed.  This
        set MUST be known to each MCS in the set at startup, and the
        ordering of MCSs in the set is the same for all MCSs in the set.
        An implementation of this would be to maintain the set of ATM
        addresses of the MCSs in a file, an identical copy of which is
        kept at each MCS in the set.

* 特定のIP Multicastグループを支持する(1以上)MCSs("mcslist")のセットは、予定されて、修理されています。 始動でセットで各MCSにおいてこのセットを知っていなければなりません、そして、セットにおけるすべてのMCSsに、セットにおける、MCSsの注文は同じです。 この実現はファイルでMCSsのATMアドレスのセットを維持するだろうことです。その同一の複製物はセットにおける各MCSに保たれます。

      * All MCSs in "mcslist" have to be started up together, with the
        first MCS in "mcslist" being the last to be started.

* "mcslist"のすべてのMCSsが、始められるために"mcslist"における最終である最初のMCSで一緒に立ち上げられなければなりません。

      * A failed MCS cannot be started up again.

* 再び失敗したMCSを立ち上げることができません。

5.2 Discussion of Multiple MCSs in operation

5.2 稼働中であるMultiple MCSsの議論

   An MCS on startup determines its position in the "mcslist".  If the
   MCS is not the first in "mcslist", it does not register for
   supporting the group with the MARS. If the MCS is first in the set,
   it does register to support the group.

始動でのMCSは"mcslist"で現在地を知っています。 MCSが"mcslist"で1番目でないなら、それは、火星でグループを支持するために登録されません。 セットにMCSが最初にあるなら、それは、グループを支持するために登録されます。

Talpade & Ammar              Informational                     [Page 12]

RFC 2149             Multicast Server Architectures             May 1997

[12ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   The first MCS thus becomes the active MCS and supports the group as
   described in section 4.  The active MCS also opens a point-to-
   multipoint VC (HelloVC) to the remaining MCSs in the set (the
   inactive MCSs).  It starts sending HELLO messages on this VC at a
   fixed interval (HelloInterval seconds).  The inactive MCSs maintain a
   timer to keep track of the last received HELLO message.  If an
   inactive MCS does not receive a message within HelloInterval*
   DeadFactor seconds (values of HelloInterval and DeadFactor are the
   same at all the MCSs), or if the HelloVC is closed, it assumes
   failure of the active MCS and attempts to elect a new one.  The
   election process is described in section 5.5.

最初のMCSはその結果、アクティブなMCSになって、セクション4で説明されるようにグループを支持します。 また、アクティブなMCSはセット(不活発なMCSs)でポイントから多点へのVC(HelloVC)を残っているMCSsに開きます。 それは固定間隔(HelloInterval秒)で、このVCでメッセージをHELLOに送り始めます。 不活発なMCSsは、最後の受信されたHELLOメッセージの動向をおさえるためにタイマを維持します。 不活発なMCSがHelloInterval*DeadFactor秒以内にメッセージを受け取らないか(HelloIntervalとDeadFactorの値はすべてのMCSsで同じです)、またはHelloVCが閉じられるなら、それは、アクティブなMCSの失敗を仮定して、新しいものを選出するのを試みます。 選挙の過程はセクション5.5で説明されます。

   If an MCS is elected as the new active one, it registers to support
   the group with the MARS. It also initiates the transmission of HELLO
   messages to the remaining inactive MCSs.

MCSが新しいアクティブな方として選出されるなら、それは、火星でグループを支持するために登録されます。 また、それは残っている不活発なMCSsにHELLOメッセージの伝達を開始します。

5.3 Inter-MCS control messages

5.3 相互MCSコントロールメッセージ

   The protocol uses HELLO messages in the heartbeat mechanism, and also
   during the election process.  The format of the HELLO message is
   based on that described in [LA96].  The Hello message type code is 5.

プロトコルは鼓動メカニズム、および選挙の過程の間も、HELLOメッセージを使用します。 HELLOメッセージの形式は[LA96]で説明されたそれに基づいています。 Helloメッセージタイプコードは5です。

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sender Len    |    Recvr Len  | State | Type  |    unused     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         HelloInterval         |          DeadFactor           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IP Multicast address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sender ATM address (variable length)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Receiver ATM address (variable length)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者レン| Recvrレン| 状態| タイプ| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval| DeadFactor| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Multicastアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者ATMアドレス(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機ATMアドレス(可変長)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sender Len
     This field holds the length in octets of the Sender ATM address.

レンThisがさばく送付者はSender ATMアドレスの八重奏における長さを保持します。

   Recvr Len
     This field holds the length in octets of the Receiver ATM
     address.

RecvrレンThis分野はReceiver ATMアドレスの八重奏における長さを保持します。

   State
     Currently two states: No-Op (0x00) and Elected (0x01).
     It is used by a candidate MCS to indicate if it was successfully
     elected.

州のCurrently two州: オプアートでなく(0×00)て選出されています(0×01)。 それは、それが首尾よく選出されたかどうかを示すのに候補MCSによって使用されます。

Talpade & Ammar              Informational                     [Page 13]

RFC 2149             Multicast Server Architectures             May 1997

[13ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   Type
     This is the code for the message type.

タイプThisはメッセージタイプのためのコードです。

   HelloInterval
     The hello interval advertises the time between sending of
     consecutive Hello Messages by an active MCS.  If the time between
     Hello messages exceeds the HelloInterval then the Hello is to be
     considered late by the inactive MCS.

HelloInterval、こんにちは、間隔は、間の時にアクティブなMCSで連続したHello Messagesを発信させながら、広告を出します。 Helloメッセージの間の時間がHelloIntervalを超えているなら、Helloは遅く、不活発なMCSによって考えられることになっています。

   DeadFactor
     This is a multiplier to the HelloInterval. If an inactive MCS
     does not receive a Hello message within the interval
     HelloInterval*DeadFactor from an active MCS that advertised
     the HelloInterval then the inactive MCS MUST consider the active
     one to have failed.

DeadFactor ThisはHelloIntervalへの乗数です。 不活発なMCSが間隔HelloInterval*DeadFactor中にHelloIntervalの広告を出したアクティブなMCSからHelloメッセージを受け取らないなら、不活発なMCS MUSTは、アクティブなものが失敗したと考えます。

   IP Multicast address
     This field is used to indicate the group to associate the HELLO
     message with. It is useful if MCSs can support more than one
     group.

ThisがさばくIP Multicastアドレスは、HELLOメッセージを関連づけるグループを示すのに使用されます。 MCSsが1つ以上のグループを支持できるなら、役に立ちます。

   Sender ATM address
     This is the protocol address of the server which is sending the
     Hello.

送付者ATMアドレスThisはHelloを送るサーバのプロトコルアドレスです。

   Receiver ATM address
     This is the protocol address of the server which is to Reply to
     the Hello.  If the sender does not know this address then the
     sender sets it to zero. (This happens in the HELLO messages sent
     from the active MCS to the inactive ones, as they are multicast
     and not sent to one specific receiver).

受信機ATMアドレスThisはHelloへのReplyにはあるサーバのプロトコルアドレスです。 送付者がこのアドレスを知らないなら、送付者はゼロにそれを設定します。 (これはそれらがマルチキャストであるのでアクティブなMCSから不活発なものに送られて、1台の特定の受信機に送られなかったHELLOメッセージは起こります。)

Talpade & Ammar              Informational                     [Page 14]

RFC 2149             Multicast Server Architectures             May 1997

[14ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

5.4 The Multiple MCS protocol

5.4 Multiple MCSプロトコル

   As is indicated in section 5.1, all the MCSs supporting the same IP
   Multicast group MUST be started up together.  The set of MCSs
   ("mcslist") MUST be specified to each MCS in the set at startup.
   After registering to support the group with the MARS, the first MCS
   in the set MUST open a point-to-multipoint VC (HelloVC) with the
   remaining MCSs in the "mcslist" as leaves, and thus assumes the role
   of active MCS. It MUST send HELLO messages HelloInterval seconds
   apart on this VC. The Hello message sent by the active MCS MUST have
   the Receiver Len set to zero, the State field set to "Elected", with
   the other fields appropriately set.  The Receiver ATM address field
   does not exist in this HELLO message.  The initial value of
   HelloInterval and DeadFactor MUST be the same at all MCSs at startup.
   The active MCS can choose to change these values by introducing the
   new value in the HELLO messages that are sent out.  The active MCS
   MUST support the group as described in section 4.

そのままで、セクション5.1で示されて、同じIP Multicastグループを支持するすべてのMCSsを一緒に立ち上げなければなりません。 始動でMCSs("mcslist")のセットをセットにおける各MCSに指定しなければなりません。 火星でグループを支持するために登録した後に、セットにおける最初のMCSは"mcslist"の残っているMCSsと共に葉としてポイントツーマルチポイントVC(HelloVC)を開かなければならなくて、その結果、アクティブなMCSの役割を引き受けます。 それはHELLOメッセージHelloInterval秒このVCで離れて発信しなければなりません。 アクティブなMCS MUSTによって送られたHelloメッセージでReceiverレンをゼロに用意ができさせます、「選出されること」に設定された州分野、適切に設定された他の分野で。 Receiver ATMアドレス・フィールドはこのHELLOメッセージに存在していません。 HelloIntervalとDeadFactorの初期の値は始動のすべてのMCSsで同じであるに違いありません。 アクティブなMCSは、出されるHELLOメッセージの新しい値を導入することによってこれらの値を変えるのを選ぶことができます。 アクティブなMCS MUSTはセクション4で説明されるようにグループを支持します。

   The other MCSs in "mcslist" determine the identity of the first MCS
   from the "mcslist".  They MUST NOT register to support the group with
   the MARS, and become inactive MCSs.  On startup, an inactive MCS
   expects HELLO messages from the active MCS. The inactive MCS MUST
   terminate the HelloVC.  A timer MUST be maintained, and if the
   inactive MCS does not receive HELLO message from the active one
   within a period HelloInterval*DeadFactor seconds, it assumes that the
   active MCS died, and initiates the election process as described in
   section 5.5.  If a HELLO message is received within this period, the
   inactive MCS does not initiate any further action, other than
   restarting the timer.  The inactive MCSs MUST set their values of
   HelloInterval and DeadFactor to those specified by the active MCS in
   the HELLO messages.

"mcslist"の他のMCSsは"mcslist"から最初のMCSのアイデンティティを決定します。 彼らは、火星でグループを支持して、不活発なMCSsになるように登録してはいけません。 始動では、不活発なMCSはアクティブなMCSからのHELLOメッセージを予想します。 不活発なMCS MUSTはHelloVCを終えます。 不活発なMCSが期間のHelloInterval*の中のアクティブなものからHELLOメッセージを受け取らないなら、タイマを主張しなければなりません。DeadFactor秒、それはアクティブなMCSが死んで、セクション5.5で説明される選挙の過程に着手すると仮定します。 この期間中にHELLOメッセージを受け取るなら、不活発なMCSは少しのさらなる動作も開始しません、タイマを再開するのを除いて。 不活発なMCSsはHELLOメッセージのアクティブなMCSによって指定されたものに彼らのHelloIntervalとDeadFactorの値を設定しなければなりません。

   In case of an MCS supporting multiple groups, it MUST register to
   support those groups for which it is the first MCS, and MUST NOT
   register for other groups.  A MARSMSERV with multiple <min, max>
   pairs may be used for registering multiple disjoint sets of groups.
   Support MUST be provided for the use of a single "mcslist" for more
   than one group.  This is intended to address the case wherein an MCS
   is intended to support multiple groups, with other MCSs acting as
   backups.  This subverts the need for using a different "mcslist" for
   each group being supported by the same set of MCSs.

複数のグループを支持するMCSの場合には、それは、それが最初のMCSであるそれらのグループを支持するために登録しなければならなくて、他のグループに登録してはいけません。 複数の<分があるMARSMSERVであり、組が倍数を示すのにおいて使用されているかもしれない最大>はグループのセットをばらばらにならせます。 単一の"mcslist"の1つ以上のグループの使用にサポートを提供しなければなりません。 これがMCSが複数のグループを支持することを意図するケースを記述することを意図します、他のMCSsがバックアップとして機能して。 これはMCSsの同じセットによって支持される各グループに異なった"mcslist"を使用する必要性を打倒します。

   On failure of the active MCS, a new MCS assumes its role as described
   in section 5.5.  In this case, the remaining inactive MCSs will
   expect HELLO messages from this new active MCS as described in the
   previous paragraph.

アクティブなMCSの失敗では、新しいMCSはセクション5.5で説明されるように役割を引き受けます。 この場合、残っている不活発なMCSsは前のパラグラフで説明されるようにこの新しいアクティブなMCSからのHELLOメッセージを予想するでしょう。

Talpade & Ammar              Informational                     [Page 15]

RFC 2149             Multicast Server Architectures             May 1997

[15ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

5.5 Failure handling

5.5 失敗取り扱い

5.5.1 Failure of active MCS

5.5.1 アクティブなMCSの失敗

   The failure of the active MCS is detected by the inactive MCSs if no
   HELLO message is received within an interval of
   HelloInterval*DeadFactor seconds, or if the HelloVC is closed.  In
   this case the next MCS in "mcslist" becomes the candidate MCS. It
   MUST open a point-to-multipoint VC to the remaining inactive MCSs
   (HelloVC) and send a HELLO message on it with the State field set to
   No-Op.  The rest of the message is formatted as described earlier.

HelloInterval*DeadFactor秒の間隔以内にHELLOメッセージを全く受け取らないか、またはHelloVCが閉じるなら、不活発なMCSsはアクティブなMCSの失敗を検出します。 この場合、"mcslist"の次のMCSは候補MCSになります。 それは、残っている不活発なMCSs(HelloVC)にポイントツーマルチポイントVCを開いて、オプアートがないのに設定された州分野と共にHELLOメッセージをそれに送らなければなりません。 メッセージの残りは、より早く説明されるようにフォーマットされます。

   On receiving a HELLO message from a candidate MCS, an inactive MCS
   MUST open a point-to-point VC to that candidate.  It MUST send a
   HELLO message back to it, with the Sender and Receiver fields
   appropriately set (not zero), and the State field being No-Op.  If a
   HELLO message is received by an inactive MCS from a non-candidate
   MCS, it is ignored.  If no HELLO message is received from the
   candidate with the State field set to "Elected" in HelloInterval
   seconds, the inactive MCS MUST retransmit the HELLO. If no HELLO
   message with State field set to "Elected" is received by the inactive
   MCSs within an interval of HelloInterval*DeadFactor seconds, the next
   MCS in "mcslist" is considered as the candidate MCS. Note that the
   values used for HelloInterval and DeadFactor in the election phase
   are the default ones.

受信のときに、候補MCSからのHELLOメッセージ、不活発なMCS MUSTはその候補に二地点間VCを開きます。 それはHELLOメッセージをそれに送り返さなければなりません、分野が適切に設定するSenderとReceiver(ゼロでない)にもかかわらず、どんな州分野存在オプアートでも、そうしません。 HELLOメッセージが不活発なMCSによって非候補MCSから受け取られるなら、それは無視されます。 州分野セットの候補からHelloInterval秒「選出される」までHELLOメッセージを全く受け取らないなら、不活発なMCS MUSTはHELLOを再送します。 「選出されること」に設定された州分野があるHELLOメッセージが全くHelloInterval*DeadFactor秒の間隔以内に不活発なMCSsによって受け取られないなら、"mcslist"の次のMCSは候補MCSであるとみなされます。 HelloIntervalとDeadFactorに選挙フェーズに使用される値がデフォルトであることに注意してください。もの。

   The candidate MCS MUST wait for a period of HelloInterval*DeadFactor
   seconds for receiving HELLO messages from inactive MCSs.  It MUST
   transmit HELLO messages with State field set to No-Op at
   HelloInterval seconds interval during this period.  If it receives
   messages from atleast half of the remaining inactive MCSs during this
   period, it considers itself elected and assumes the active MCS role.
   It then registers to support the group with the MARS, and starts
   sending HELLO messages at HelloInterval second intervals with State
   field set to "Elected" on the already existing HelloVC. The active
   MCS can then alter the HelloInterval and DeadFactor values if
   desired, and communicate the same to the inactive MCSs in the HELLO
   message.

候補MCS MUSTは、しばらく、不活発なMCSsからHELLOメッセージを受け取るのをHelloInterval*DeadFactor秒を待ちます。 それはこの期間、州分野セットでHelloInterval秒のオプアートがない間隔にHELLOメッセージを送らなければなりません。 この期間、残っている不活発なMCSsのatleast半分からメッセージを受け取るなら、それは、それ自体が選出されていると考えて、アクティブなMCSの役割を仮定します。 HelloInterval2番目の間隔を置いて、それは、州分野セットから既に既存のHelloVCで「選出されること」に次に、火星でグループを支持するために登録して、メッセージをHELLOに送り始めます。 アクティブなMCSは次に、望まれているならHelloIntervalとDeadFactor値を変更して、HELLOメッセージで同じように不活発なMCSsに伝えることができます。

5.5.2 Failure of inactive MCS

5.5.2 不活発なMCSの失敗

   If an inactive MCS drops off the HelloVC, the active MCS MUST attempt
   to add that MCS back to the VC for three attempts, spaced
   HelloInterval*DeadFactor seconds apart.  If even the third attempt
   fails, the inactive MCS is considered dead.

不活発なMCSが落ちるなら、HelloVC(3つの試みのためにそのMCSをVCに加えて戻す活発なMCS MUST試み)は何秒も離れてHelloInterval*DeadFactorを区切りました。 3番目の試みさえ失敗するなら、不活発なMCSは死んでいると考えられます。

Talpade & Ammar              Informational                     [Page 16]

RFC 2149             Multicast Server Architectures             May 1997

[16ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   An MCS, active or inactive, MUST NOT be started up once it has
   failed.  Failed MCSs can only be started up by manual intervention
   after shutting down all the MCSs, and restarting them together.

いったん失敗すると、アクティブであるか、または不活発なMCSを立ち上げてはいけません。 一緒にすべてのMCSsを止めて、彼らを再開した後に、手動の介入で失敗したMCSsを立ち上げることができるだけです。

5.6 Compatibility with future MARS and MCS versions

5.6 将来の火星とMCSバージョンとの互換性

   Future versions of MCSs can be expected to use an enhanced MARS for
   load sharing and fault tolerance ([TA96]).  The MCS architecture
   described in this document is compatible with the enhanced MARS and
   the future MCS versions.  This is because the active MCS is the only
   one which communicates with the MARS about the group.  Hence the
   active MCS will only be informed by the enhanced MARS about the
   subset of the group that it is to support.  Thus MCSs conforming to
   this document are compatible with [GA96] based MARS, as well as
   enhanced MARS.

MCSsの将来のバージョンが負荷分割法と耐障害性([TA96])に高められた火星を使用すると予想できます。 本書では説明されたMCS構造は高められた火星と将来のMCSバージョンと互換性があります。 これはアクティブなMCSが火星でグループに関して交信する唯一無二であるからです。 したがって、アクティブなMCSは高められた火星のそばでそれが支持することになっているグループの部分集合に関して知らされるだけでしょう。 したがって、このドキュメントに従うMCSsは[GA96]ベースの火星、および高められた火星と互換性があります。

6 Summary

6概要

   This document describes the architecture of an MCS. It also provides
   a mechanism for using multiple MCSs per group for providing fault
   tolerance.  This approach can be used with [GA96] based MARS server
   and clients, without needing any change in their functionality.  It
   uses the HELLO packet format as described in [LA96] for the heartbeat
   messages.

このドキュメントはMCSの構造について説明します。 また、それは耐障害性を提供するのに複数の1グループあたりのMCSsを使用するのにメカニズムを提供します。 彼らの機能性におけるどんな変化も必要としないで、[GA96]ベースの火星サーバとクライアントと共にこのアプローチを使用できます。 それは鼓動メッセージのために[LA96]で説明されるようにHELLOパケット・フォーマットを使用します。

7 Acknowledgements

7つの承認

   We would like to acknowledge Grenville Armitage (Bellcore) for
   reviewing the document and suggesting improvements towards
   simplifying the multiple MCS functionalities.  Discussion with Joel
   Halpern (Newbridge) helped clarify the multiple MCS problem.  Anthony
   Gallo (IBM RTP) pointed out security issues that are not adequately
   addressed in the current document.  Arvind Murching (Microsoft)
   flagged a potential show stopper in section 4.1.2.

複数のMCSの機能性を簡素化することに向かって、ドキュメントを再検討して、改良を示すために、グレンビルアーミテージ(Bellcore)を承認したいと思います。 ジョエル・アルペルン(Newbridge)との議論は、複数のMCS問題をはっきりさせるのを助けました。 アンソニー・ギャロ(IBM RTP)は現在のドキュメントに適切に記述されない安全保障問題を指摘しました。 アービンドMurching(マイクロソフト)はセクション4.1.2で潜在的名役者に旗を揚げさせました。

8 Authors' Address

8人の作者のアドレス

   Rajesh Talpade
   College of Computing
   Georgia Institute of Technology
   Atlanta, GA 30332-0280

ジョージア工科大学アトランタ、ジョージア30332-0280を計算するラジェッシュTalpade大学

   Phone: (404)-894-6737
   Email: taddy@cc.gatech.edu

以下に電話をしてください。 (404)-894-6737 メールしてください: taddy@cc.gatech.edu

Talpade & Ammar              Informational                     [Page 17]

RFC 2149             Multicast Server Architectures             May 1997

[17ページ]RFC2149マルチキャストサーバー・アーキテクチャ1997年5月の情報のTalpade&Ammar

   Mostafa H. Ammar
   College of Computing
   Georgia Institute of Technology
   Atlanta, GA 30332-0280

ジョージア工科大学アトランタ、ジョージア30332-0280を計算するMostafa H.Ammar大学

   Phone: (404)-894-3292
   Email:  ammar@cc.gatech.edu

以下に電話をしてください。 (404)-894-3292 メールしてください: ammar@cc.gatech.edu

9 References

9つの参照箇所

[GA96]   Armitage, G.J., "Support for Multicast over UNI 3.0/3.1 based
         ATM networks", RFC 2022, November 1996.

[GA96]アーミテージ、G.J.、「UNI3.0/3.1の上のMulticastのサポートはATMネットワークを基礎づけた」RFC2022、1996年11月。

[BK95]   Birman, A., Kandlur, D., Rubas, J., "An extension to the MARS
         model", Work in Progress.

[BK95] バーマン、A.、Kandlur、D.、Rubas、J.、「火星モデルへの拡大」、ProgressのWork。

[LM93]   Laubach, M., "Classical IP and ARP over ATM", RFC1577,
         Hewlett-Packard Laboratories, December 1993.

[LM93] Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、ヒューレット・パッカード研究所、12月1993

[LA96]   Luciani, J., G. Armitage, and J. Halpern, "Server Cache
         Synchronization Protocol (SCSP) - NBMA", Work in Progress.

[LA96]Luciani、J.、G.アーミテージ、およびJ.アルペルン、「サーバキャッシュ同期は(SCSP)について議定書の中で述べます--NBMA。」仕事進行中です。

[TA96]   Talpade, R., and Ammar, M.H., "Multiple MCS support using an
         enhanced version of the MARS server.", Work in Progress.

[TA96] 「複数のMCSが火星サーバの高められたバージョンを使用することで支持する」Talpade、R.とAmmar、M.H.、ProgressのWork。

Talpade & Ammar              Informational                     [Page 18]

Talpade&Ammar情報です。[18ページ]