RFC2269 日本語訳

Network Working Group                                      G. Armitage
Request for Comments: 2269                         Lucent Technologies
Category: Informational                                   January 1998

コメントを求めるワーキンググループG.アーミテージ要求をネットワークでつないでください: 2269年のルーセントテクノロジーズカテゴリ: 情報の1998年1月

             Using the MARS Model in non-ATM NBMA Networks

非気圧NBMAネットワークに火星モデルを使用します。

Status of this Memo

このMemoの状態

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

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

Abstract

要約

   Initially developed for IP over ATM, the RFC 2022 (MARS) model is
   also applicable to other NBMA networks that provide the equivalent of
   switched, point to multipoint connections. This short document is
   intended to state the obvious equivalences, and explain the less
   obvious implications. No changes to the MARS model per se are
   suggested or required. RFC 2022 is not required over NBMA networks
   that offer Ethernet-like group addressing functionality.

マルチポイント接続は、初めは、IPのためにATMの上で開発されています、また、RFC2022(火星)モデルも切り換えられることの同等物を提供する他のNBMAネットワークに適切であることを示します。 この短いドキュメントは、明白な等価性を述べて、それほど明白でない含意について説明することを意図します。 そういうものの火星モデルへの変化は、全く示されもしませんし、必要になりもしません。 RFC2022はイーサネットのようなグループ・アドレッシングの機能性を提供するNBMAネットワークに関して必要ではありません。

1. Introduction

1. 序論

   Most network layer models, like the one described in STD 5, RFC 1112
   [1] for IP multicasting, assume sources may send their packets to an
   abstract 'multicast group addresses'.  Link layer support for such an
   abstraction is assumed to exist, and is provided by technologies such
   as Ethernet.

STD5で説明されたもののようなほとんどのネットワーク層モデル(IPマルチキャスティングのためのRFC1112[1])が、ソースが抽象的な'マルチキャストグループアドレス'に彼らのパケットを送るかもしれないと仮定します。 そのような抽象化のリンクレイヤサポートを存在すると思って、イーサネットなどの技術で前提とします。

   Some NBMA networks (e.g. ATM using UNI3.0 or UNI3.1 signaling [4,5])
   do not support a multicast (or group) address abstraction. In these
   environments multicasting is typically supported through point to
   multipoint calls (or emulated with multiple point to point calls).
   The MARS model (RFC 2022) [2] was originally developed by the IP over
   ATM working group, and so uses ATM-centric descriptive language.  For
   completeness this memo explains how RFC 2022 can be applied to other
   NBMA technologies.

NBMAネットワーク(例えば、UNI3.0を使用するATMかUNI3.1シグナリング[4、5])の中にはマルチキャスト(分類する)がアドレス抽象化であるとサポートしないものもあります。 これらの環境で、マルチキャスティングはポイントを通して多点要求(または、複数のポイント・ツー・ポイントで、呼び出しを見習う)に通常サポートされます。 元々ATMワーキンググループの上でIPによって開発されたので、火星モデル(RFC2022)[2]はATM中心の描写的である言語を使用します。 完全性のために、このメモで、どう他のNBMA技術にRFC2022を適用できるかがわかります。

Armitage                     Informational                      [Page 1]

RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

非気圧NBMAのアーミテージ情報[1ページ]のRFC2269火星モデルは1998年1月をネットワークでつなぎます。

2.  RFC 2022's basic assumptions.

2. RFC2022の基本仮定。

   Section 3 of [2] describes the basic assumptions that the MARS model
   makes about the services available from the link layer network (using
   ATM as the specific case).  In summary these are:

[2]のセクション3は火星モデルがリンクレイヤネットワークから利用可能なサービスに関してする基本仮定について説明します(特定のケースとしてATMを使用して)。 概要では、これらは以下の通りです。

      The ATM model broadly describes an 'AAL User' as any entity that
      establishes and manages VCs and underlying AAL services to
      exchange data.  An IP over ATM interface is a form of 'AAL User'

ATMモデルはデータを交換するためにVCsと基本的なAALサービスを確立して、管理するどんな実体としても'AAL User'を広く記述します。 ATMインタフェースの上のIPは'AAL User'のフォームです。

      The most fundamental limitations of UNI 3.0/3.1's multicast
      support are:

UNI3.0/3.1のマルチキャストサポートの最も基本的な制限は以下の通りです。

         Only point to multipoint, unidirectional VCs may be
         established.

多点への唯一のポイントでは、単方向VCsは設立されるかもしれません。

         Only the root (source) node of a given VC may add or remove
         leaf nodes.

与えられたVCの根の(ソース)ノードだけが、葉のノードを加えるか、または取り除くかもしれません。

      Leaf nodes are identified by their unicast ATM addresses.

葉のノードはそれらのユニキャストATMアドレスによって特定されます。

   Given this point to multipoint call service, the MARS document goes
   on to describe two architectures for emulating multipoint to
   multipoint IP multicasting - the VC Mesh, and the Multicast Server.
   In either case it was assumed that IP/ATM interfaces (whether in
   routers or hosts) are allowed to originate and manage outgoing point
   to multipoint calls without network operator intervention or manual
   provisioning.

多点呼び出しサービスへのこのポイントを考えて、火星ドキュメントは、多点IPマルチキャスティングに多点を見習うために2つのアーキテクチャについて説明し続けます--VC Mesh、およびMulticast Server、どちらの場合ではも、ネットワークオペレータ介入も手動の食糧を供給するのなしで多点呼び出しに出発しているポイントを溯源して、IP/ATMインタフェース(ルータかホストにかかわらず)が管理できると思われました。

   The MARS document also specifies that AAL5 be used for all SVCs,
   implying a requirement that the underlying link service supports the
   atomic exchange of PDUs.

また、火星ドキュメントは、AAL5がすべてのSVCsに使用されると指定します、基本的なリンクサービスがPDUsの原子交換をサポートするという要件を含意して。

3.  Generalising the MARS model.

3. 火星モデルを一般化します。

   Any NBMA service that offers an equivalent to (or superset of) the
   ATM point to multipoint call service can use the MARS model directly.
   It must be possible to transmit atomic data units bi-directionally
   with point to point calls, and unidirectionally (from root to leaves)
   on point to multipoint calls.

それが同等物を提供するどんなNBMAサービス、も(スーパーセット、)、多点呼び出しサービスへのATMポイントは直接火星モデルを使用できます。 原子データ単位ポイント・ツー・ポイントによる2方向の呼び出しを伝えて、ポイントの上で多点呼び出しに単方向は(根から葉まで)可能であるに違いありません。

   A MARS is an entity known by its NBMA address.

火星はNBMAアドレスによって知られていた実体です。

   A MARS Client is an entity known by its NBMA address.

Client火星はNBMAアドレスによって知られていた実体です。

   An MCS (where needed) is an entity known by its NBMA address.

MCS(必要であるところで)はNBMAアドレスによって知られていた実体です。

Armitage                     Informational                      [Page 2]

RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

非気圧NBMAのアーミテージ情報[2ページ]のRFC2269火星モデルは1998年1月をネットワークでつなぎます。

   The MARS control messages defined in sections 4 onwards of the MARS
   document are shown carrying ATM addresses.  Using different mar$afn
   (Address Family) values in the fixed header of MARS control messages
   allows MARS entities to indicate they are carrying other types of
   NBMA addresses (as done in NHRP [3]).  As for NHRP, the
   interpretation of the 'sub-address' fields shall be in the context of
   the address family selected (which means it will often simply be
   null).

火星ドキュメントについてセクション4で前方へ定義された火星コントロールメッセージはATMアドレスを運ぶのが示されます。 火星コントロールメッセージの固定ヘッダーのafn(アドレスFamily)値が他のタイプのNBMAアドレスを運ぶのを示すのを火星実体を許容する$を損なってください。使用異なる、(NHRP[3])でするように。 NHRPに関して、'サブアドレス'分野の解釈が選ばれたアドレスファミリー(それがしばしば単になるヌルであることを意味する)の文脈にあるものとします。

   In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to,
   they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context
   of whatever NBMA network you are deploying MARS.

中では、あなたがNBMAネットワークであっても何でも火星を配布しながら、IP、ATM.1、ATM.2、マッピングが参照される…、IP、NBMA.1、NBMA.2、…としてそれらが文脈で解釈されるかもしれないところにすべてケースに入れます。

   The MARS Cluster is defined in [2] as:

Cluster火星は[2]で以下と定義されます。

      The set of ATM interfaces chosing to participate in direct ATM
      connections to achieve multicasting of AAL_SDUs between
      themselves.

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

   It is trivial to observe that the cluster definition is independent
   of the underlying link layer technology. A revised definition
   becomes:

クラスタ定義が基本的なリンクレイヤ技術から独立しているのを観測するのは些細です。 改訂された定義はなります:

      The set of NBMA interfaces chosing to participate in direct NBMA
      connections to achieve multicasting of packets between themselves.

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

   The term 'Cluster Member' continues to refer to an endpoint that is
   currently using a specific MARS for multicast support.  The potential
   scope of a cluster may be the entire membership of a LIS, while the
   actual scope of a cluster depends on which LIS members are actually
   registered with the cluster's MARS at any given time.

'クラスタメンバー'という用語は、現在マルチキャストサポートに特定の火星を使用している終点について言及し続けています。 クラスタの潜在的範囲はLISの全体の会員資格であるかもしれません、クラスタの実際の範囲がどのLISメンバーがその時々で実際にクラスタの火星に登録されるかによりますが。

   Section 3.4 of [2] provided a set of mneumonics for the signalling
   functions available to AAL Users. These mneumonics are then used in
   the remainder of [2] to indicate link layer events to which MARS
   entities might react. Recast from the perspective of an NBMA based
   MARS entity, the descriptions would now read:

[2]のセクション3.4はAAL Usersに利用可能な合図機能にmneumonicsの1セットを提供しました。 そして、これらのmneumonicsは、火星実体が反応するかもしれないリンクレイヤイベントを示すのに[2]の残りに使用されます。 ベースのNBMAの見解から火星実体を書き直してください、そして、記述は現在、読むでしょう:

      The following generic signalling functions are presumed to be
      available to local MARS entities:

以下のジェネリック合図機能はあえて地方の火星実体に利用可能です:

      L_CALL_RQ     Establish a pt-pt call to a specific endpoint.
      L_MULTI_RQ    Establish pt-mpt call to a specific endpoint.
      L_MULTI_ADD   Add new leaf node to previously established pt-mpt
                    call.
      L_MULTI_DROP  Remove specific leaf node from established pt-mpt
                    call.
      L_RELEASE     Release pt-pt call, or all Leaves of a pt-mpt call.

特定の終点へのL_CALL_RQ Establish a Pt Pt呼び出し。 特定の終点へのL_MULTI_RQ Establish Pt-mpt呼び出し。 以前にへのL_MULTI_ADD Add新葉ノードはPt-mpt呼び出しを確立しました。 確立したPt-mpt呼び出しからのL_MULTIの_のDROP Removeの特定の葉のノード。 L_RELEASE Release Pt Pt呼び出し、またはPt-mpt呼び出しのすべてのLeaves。

Armitage                     Informational                      [Page 3]

RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

非気圧NBMAのアーミテージ情報[3ページ]のRFC2269火星モデルは1998年1月をネットワークでつなぎます。

      The signalling exchanges and local information passed between MARS
      entity and NBMA signalling entity with these functions are outside
      the scope of this document.

このドキュメントの範囲の外に火星実体とNBMA合図実体の間をこれらの機能で流れる合図交換とローカルの情報があります。

      The following indications are assumed to be available to MARS
      entities, generated by by the local NBMA signalling entity:

以下の指摘は、地方のNBMA合図実体によって火星実体に利用可能であると思われて、生成されます:

      L_ACK           Succesful completion of a local request.
      L_REMOTE_CALL   A new call has been established to the MARS
                      entity.
      ERR_L_RQFAILED  A remote NBMA endpoint rejected an L_CALL_RQ,
                      L_MULTI_RQ, or L_MULTI_ADD.
      ERR_L_DROP      A remote NBMA endpoint dropped off an existing
                      call.
      ERR_L_RELEASE   An existing call was terminated.

ローカルの要求のL_ACK Succesful完成。 L_REMOTEの_のCALLのA新しい呼び出しは火星実体に確立されました。 ERR_L_のRQFAILEDのA遠く離れたNBMA終点はL_CALL_RQ、_L MULTI_RQ、または_L MULTI_ADDを拒絶しました。 ERR_L_のDROPのA遠く離れたNBMA終点は既存の呼び出しを降ろしました。 ERR_L_のRELEASE Anの既存の呼び出しは終えられました。

      The signalling exchanges and local information passed between MARS
      entity and NBMA signalling entity with these functions are outside
      the scope of this document.

このドキュメントの範囲の外に火星実体とNBMA合図実体の間をこれらの機能で流れる合図交換とローカルの情報があります。

4.  Open Issues.

4. 問題を開いてください。

   The trade offs between VC Mesh and Multicast Server modes may look
   quite different for each NBMA technology. This will be especially
   true in the area of VC (or equivalent) resource consumption in the
   NICs of hosts, routers, and endpoints supporting MARSs or MCSs. The
   use of VC mesh mode is most vulnerable to NBMA technologies that are
   signalling intensive or resource challenged.

VC MeshとMulticast Serverモードの間の取り引きoffsはそれぞれのNBMA技術において全く異なるように見えるかもしれません。 これは、MARSsかMCSsをサポートしながら、ホスト、ルータ、および終点のNICsでのVC(または、同等物)リソース消費の領域で特に本当になるでしょう。 VCメッシュモードの使用が徹底的に合図しているNBMA技術に最も被害を受け易いか、またはリソースは挑戦しました。

   Sizing of Clusters (and hence LISes) will also be affected by a given
   NBMA network's ability to support lots of pt-mpt calls.
   Additionally, you cannot have more members in a cluster than you can
   have leaf nodes on a pt-mpt call, without hacking the MARS model [6].

また、Clusters(そして、したがって、LISes)のサイズ処理は多くのPt-mpt呼び出しをサポートする与えられたNBMAネットワークの能力で影響を受けるでしょう。 さらに、あなたはひとかたまりになってあなたがPt-mpt呼び出しでの葉のノードを持つことができるより多くのメンバーを持つことができません、火星モデル[6]をハックしないで。

   On going developments in server synchronisation protocols for
   distributed RFC 2022 implementations are expected to be applicable to
   non-ATM NBMA networks.

分配されたRFCのためのサーバ連動プロトコルにおける現在の開発のときに、2022の実装が非ATM NBMAネットワークに適切であると予想されます。

   Quality of service considerations are outside the scope of this
   document. They will be very specific to each NBMA technology's
   capabilities. Related work is being pursued outside the ION Working
   Group.

このドキュメントの範囲の外にサービスの質問題があります。 それらはそれぞれのNBMA技術の能力に非常に特定になるでしょう。 関連仕事はION作業部会の外で追求されています。

   If the NBMA network offers some sort of native multipoint to
   multipoint service then use of the MARS model may not be optimal.
   Such situations require further analysis.

NBMAネットワークがある種の固有の多点を多点サービスに提供するなら、火星モデルの使用は最適でないかもしれません。 そのような状況はさらなる分析を必要とします。

Armitage                     Informational                      [Page 4]

RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

非気圧NBMAのアーミテージ情報[4ページ]のRFC2269火星モデルは1998年1月をネットワークでつなぎます。

Security Considerations

セキュリティ問題

   This memo is informational, and specifies no protocol for deployment.
   No specific non-ATM NBMA network technologies or security
   characteristics are discussed. Should enhancements to security be
   required, they shall be added as an extension to the base
   architecture in RFC 2022, or described in documents explicitly
   proposing use of RFC 2022 over specific NBMA technologies.

このメモは、情報であり、プロトコルを全く展開に指定しません。 どんな特定の非ATM NBMAネットワーク技術もセキュリティの特性も議論しません。 セキュリティへの増進が必要であるなら、それらは、拡大としてRFC2022でベースアーキテクチャに追加されるものとするか、または特定のNBMA技術の上で明らかにRFC2022の使用を提案するドキュメントで説明されるものとします。

Acknowledgments

承認

   This memo was substantially developed while the author was with Bell
   Communications Research (Bellcore).

作者がベルコミュニケーションズ・リサーチ(Bellcore)と共にいた間、このメモは実質的に開発されました。

Author's Address

作者のアドレス

   Grenville Armitage
   Bell Laboratories, Lucent Technologies.
   101 Crawfords Corner Rd,
   Holmdel, NJ, 07733
   USA

グレンビルアーミテージベル研究所、ルーセントテクノロジーズ。 101Crawfordsが追い詰める、Holmdel、ニュージャージー07733第米国

   EMail: gja@lucent.com

メール: gja@lucent.com

References

参照

   [1] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
   1112, Stanford University, August 1989.

[1] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。

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

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

   [3] Luciani, J., et. al., "NBMA Next Hop Resolution Protocol (NHRP)",
   Work in Progress.

et[3]Luciani、J.、アル、「次のNBMAは解決プロトコル(NHRP)を飛び越す」ProgressのWork。

   [4] ATM Forum, "ATM User-Network Interface Specification Version
   3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993.

[4] 気圧フォーラム、「気圧ユーザネットワーク・インターフェース仕様バージョン3インチ、イングルウッドがけ、ニュージャージー:」 1993年9月の新米のホール。

   [5] ATM Forum, "ATM User Network Interface (UNI) Specification
   Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs,
   NJ, June 1995.

[5] 気圧フォーラム、「気圧ユーザネットワーク・インターフェース(UNI)仕様バージョン3.1インチ、ISBN0-13-393828X、新米のホール、イングルウッドがけ、ニュージャージー、1995年6月。」

   [6] Armitage, G., "Issues affecting MARS Cluster Size", RFC 2121,
   March 1997.

[6] アーミテージ、G.、「火星Cluster Sizeに影響する問題」、RFC2121、1997年3月。

Armitage                     Informational                      [Page 5]

RFC 2269          MARS Model in non-ATM NBMA Networks       January 1998

非気圧NBMAのアーミテージ情報[5ページ]のRFC2269火星モデルは1998年1月をネットワークでつなぎます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Armitage                     Informational                      [Page 6]

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