RFC 2269 - Using the MARS Model in non-ATM NBMA Networks 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2269
タイトル : RFC 2269 - 非ATM NBMAネットワークでのMARSモデルの使用
翻訳編集 : 自動生成

[要約] RFC 2269は、非ATM NBMAネットワークでMARSモデルを使用するためのガイドラインです。このRFCの目的は、非ATMネットワークでのMARSモデルの適用方法を提供することです。

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

Using the MARS Model in non-ATM NBMA Networks

非ATM NBMAネットワークでのMARSモデルの使用

Status of this 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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。

著作権表示

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 over ATM用に最初に開発されたRFC 2022（MARS）モデルは、スイッチドポイントツーマルチポイント接続と同等の機能を提供する他のNBMAネットワークにも適用できます。この短い文書は、明白な同等性を述べ、それほど明白ではない意味を説明することを目的としています。 MARSモデル自体への変更は、推奨も要求もされていません。 RFC 2022は、イーサネットのようなグループアドレス指定機能を提供する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.

STD 5、RFC 1112 [1]で説明されているIPマルチキャストのようなほとんどのネットワークレイヤーモデルは、ソースがパケットを抽象的な「マルチキャストグループアドレス」に送信できると想定しています。このような抽象化のためのリンク層サポートは存在すると想定され、イーサネットなどのテクノロジーによって提供されます。

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またはUNI3.1シグナリングを使用するATM [4、5]など）は、マルチキャスト（またはグループ）アドレスの抽象化をサポートしていません。これらの環境では、マルチキャストは通常、ポイントツーマルチポイントコールを通じてサポートされます（または複数のポイントツーポイントコールでエミュレートされます）。 MARSモデル（RFC 2022）[2]は、もともとIP over ATMワーキンググループによって開発されたため、ATM中心の記述言語を使用しています。完全を期すために、このメモではRFC 2022を他のNBMAテクノロジーに適用する方法を説明しています。

2. RFC 2022's basic assumptions.

2. RFC 2022の基本的な前提。

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は、MARSモデルがリンクレイヤーネットワークから利用可能なサービスについて（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モデルは、「AALユーザー」を、VCと基盤となるAALサービスを確立および管理してデータを交換する任意のエンティティとして大まかに説明しています。 IP over ATMインターフェースは「AALユーザー」の一形態です。

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

UNI 3.0 / 3.1のマルチキャストサポートの最も基本的な制限は次のとおりです。

Only point to multipoint, unidirectional VCs may be established.

ポイントツーマルチポイントの単方向VCのみを確立できます。

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.

このポイントツーマルチポイントコールサービスの場合、MARSドキュメントでは、マルチポイントツーマルチポイントIPマルチキャストをエミュレートするための2つのアーキテクチャ、VCメッシュとマルチキャストサーバーについて説明します。どちらの場合でも、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.

MARSドキュメントでは、すべてのSVCにAAL5を使用することも指定されており、基礎となるリンクサービスがPDUのアトミックな交換をサポートする必要があることを意味しています。

3. Generalising the MARS model.

3. MARSモデルの一般化。

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.

ATMポイントツーマルチポイントコールサービスと同等（またはそのスーパーセット）を提供するNBMAサービスは、MARSモデルを直接使用できます。アトミックデータユニットは、ポイントツーポイントコールでは双方向に送信でき、ポイントツーマルチポイントコールでは一方向に（ルートからリーフへ）送信できる必要があります。

A MARS is an entity known by its NBMA address.

MARSは、NBMAアドレスによって認識されるエンティティです。

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

MARSクライアントは、NBMAアドレスで認識されるエンティティです。

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

MCS（必要な場合）は、NBMAアドレスで認識されるエンティティです。

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).

MARSドキュメントのセクション4以降で定義されたMARS制御メッセージは、ATMアドレスを伝達するものとして示されています。 MARS制御メッセージの固定ヘッダーで異なるmar $ afn（アドレスファミリ）値を使用すると、MARSエンティティは他のタイプのNBMAアドレスを運ぶことを示すことができます（NHRP [3]で行われるように）。 NHRPに関しては、「サブアドレス」フィールドの解釈は、選択されたアドレスファミリのコンテキストで行われます（これは、多くの場合、単にnullになることを意味します）。

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.

{IP、ATM.1、ATM.2、...}マッピングが参照されるすべてのケースで、それらはすべてのNBMAのコンテキストで{IP、NBMA.1、NBMA.2、...}として解釈される場合がありますMARSを展開するネットワーク。

The MARS Cluster is defined in [2] as:

MARSクラスターは、[2]で次のように定義されています。

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

それらの間のすべてのSDUのマルチキャストを実現するために、直接ATM接続に参加することを選択するATMインターフェイスのセット。

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接続に参加して、それらの間でパケットのマルチキャストを実現することを選択します。

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.

「クラスターメンバー」という用語は、マルチキャストサポートのために特定のMARSを現在使用しているエンドポイントを引き続き指します。クラスターの潜在的なスコープはLISのメンバーシップ全体である可能性がありますが、クラスターの実際のスコープは、どのLISメンバーが実際にクラスターのMARSに実際に登録されているかによって異なります。

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ユーザーが利用できる信号機能に一連のニューモニクスを提供しました。これらのニューモニクスは、残りの[2]で使用され、MARSエンティティが反応する可能性のあるリンク層イベントを示します。 NBMAベースのMARSエンティティの観点からリキャストすると、説明は次のようになります。

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

次の一般的なシグナリング機能は、ローカルMARSエンティティで使用できると想定されています。

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特定のエンドポイントへのpt-ptコールを確立します。 L_MULTI_RQ特定のエンドポイントへのpt-mpt呼び出しを確立します。 L_MULTI_ADD以前に確立されたpt-mpt呼び出しに新しいリーフノードを追加します。 L_MULTI_DROP確立されたpt-mpt呼び出しから特定のリーフノードを削除します。 L_RELEASE pt-pt呼び出し、またはpt-mpt呼び出しのすべてのLeaveを解放します。

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

これらの機能を持つMARSエンティティとNBMAシグナリングエンティティの間で渡されるシグナリング交換とローカル情報は、このドキュメントの範囲外です。

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

次の指示は、ローカルのNBMAシグナリングエンティティによって生成されたMARSエンティティで使用できると想定されています。

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ローカル要求の正常終了。 L_REMOTE_CALL MARSエンティティへの新しいコールが確立されました。 ERR_L_RQFAILEDリモートNBMAエンドポイントがL_CALL_RQ、L_MULTI_RQ、またはL_MULTI_ADDを拒否しました。 ERR_L_DROPリモートNBMAエンドポイントが既存の通話を切断しました。 ERR_L_RELEASE既存の通話が終了しました。

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

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メッシュモードとマルチキャストサーバーモードのトレードオフは、NBMAテクノロジーごとにかなり異なって見える場合があります。これは、ホスト、ルーター、およびMARSまたはMCSをサポートするエンドポイントのNICにおける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].

クラスター（したがってLIS）のサイジングも、多数のpt-mpt呼び出しをサポートする特定のNBMAネットワークの機能の影響を受けます。さらに、MARSモデルをハックせずに、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ネットワークが何らかのネイティブマルチポイントツーマルチポイントサービスを提供している場合、MARSモデルの使用は最適ではない可能性があります。このような状況では、さらに分析が必要です。

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ネットワークテクノロジーやセキュリティ特性については説明していません。セキュリティの強化が必要な場合は、RFC 2022の基本アーキテクチャの拡張として追加するか、特定のNBMAテクノロジでのRFC 2022の使用を明示的に提案するドキュメントに記述します。

Acknowledgments

謝辞

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

このメモは、著者がベルコミュニケーションリサーチ（ベルコア）に在籍していた間に大幅に作成されました。

Author's Address

著者のアドレス

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

グレンビルアーミテージベル研究所、ルーセントテクノロジー。 101 Crawfords Corner Rd、Holmdel、NJ、07733 USA

   EMail: gja@lucent.com

References

参考文献

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

[1] Deering、S。、「IPマルチキャストのホスト拡張機能」、STD 5、RFC 1112、スタンフォード大学、1989年8月。

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

[2] アーミテージ、G。、「UNI 3.0 / 3.1ベースのATMネットワーク上のマルチキャストのサポート」、RFC 2022、1996年11月。

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

[3] ルチアーニ、J。らその他、「NBMA Next Hop Resolution Protocol（NHRP）」、Work in Progress。

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

[4] ATMフォーラム、「ATM User-Network Interface Specification Version 3.0」、Englewood Cliffs、NJ：Prentice Hall、1993年9月。

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

[5] ATMフォーラム、「ATM User Network Interface（UNI）Specification Version 3.1」、ISBN 0-13-393828-X、Prentice Hall、Englewood Cliffs、NJ、1995年6月。

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

[6] アーミテージ、G。、「MARSクラスターサイズに影響する問題」、RFC 2121、1997年3月。

Full Copyright Statement

完全な著作権表示

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.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

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.

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。