[要約] RFC 7046は、透過的なハイブリッドマルチキャストのための共通APIに関するものであり、ネットワーク上のマルチキャスト通信を効率的に管理するためのガイドラインを提供しています。目的は、異なるネットワーク環境でのマルチキャスト通信の一貫性を確保し、ネットワークのパフォーマンスを向上させることです。
Internet Research Task Force (IRTF) M. Waehlisch
Request for Comments: 7046 link-lab & FU Berlin
Category: Experimental T. Schmidt
ISSN: 2070-1721 HAW Hamburg
S. Venaas
Cisco Systems
December 2013
A Common API for Transparent Hybrid Multicast
透過ハイブリッドマルチキャストの共通API
Abstract
概要
Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current Multicast Domains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM) Research Group.
グループ通信サービスは、さまざまなプロトコルレイヤーでさまざまなフレーバーと技術的な実装に存在します。マルチキャストデータの配信は、利用可能な最下位のレイヤーで最も効率的に実行されますが、インターネット全体でのマルチキャストテクノロジーの異機種混在の展開ステータスには、実行時に適応型サービスバインディングが必要です。今日、あらゆる場所で実行され、同時にネットワークで利用可能な最も効率的なマルチキャストサービスを利用するアプリケーションを作成することは困難です。堅牢性の要件に直面している開発者は、アプリケーション自体によって提供される安定した上位層プロトコルを使用せざるを得ません。このドキュメントでは、アンダーレイとオーバーレイの透過的な通信に適しており、さまざまな種類のマルチキャストへのアクセスを許可する一般的なマルチキャストAPIについて説明します。マルチキャストURIを使用する抽象的な命名方式を提案し、さまざまな名前空間と配布テクノロジ間のマッピングメカニズムについて説明します。さらに、このドキュメントでは、インターネット全体で現在のマルチキャストドメインを相互接続するゲートウェイを構築するためのこのAPIのアプリケーションについて説明します。サービスミドルウェアを含むプログラミングインターフェイスの実装について報告します。このドキュメントは、Scalable Adaptive Multicast（SAM）Research Groupの製品です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Scalable Adaptive Multicast Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、Internet Research Task Force（IRTF）のScalable Adaptive Multicast Research Groupのコンセンサスを表しています。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7046.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7046で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Use Cases for the Common API ...............................6
1.2. Illustrative Examples ......................................7
1.2.1. Support of Multiple Underlying Technologies .........7
1.2.2. Support of Multi-Resolution Multicast ...............9
2. Terminology ....................................................10
3. Overview .......................................................10
3.1. Objectives and Reference Scenarios ........................10
3.2. Group Communication API and Protocol Stack ................12
3.3. Naming and Addressing .....................................14
3.4. Namespaces ................................................15
3.5. Name-to-Address Mapping ...................................15
3.5.1. Canonical Mapping ..................................16
3.5.2. Mapping at End Points ..............................16
3.5.3. Mapping at Inter-Domain Multicast Gateways .........16
3.6. A Note on Explicit Multicast (Xcast) ......................16
3.7. MTU Handling ..............................................17
4. Common Multicast API ...........................................18
4.1. Notation ..................................................18
4.2. URI Scheme Definition .....................................18
4.2.1. Syntax .............................................18
4.2.2. Semantic ...........................................19
4.2.3. Generic Namespaces .................................20
4.2.4. Application-Centric Namespaces .....................20
4.2.5. Future Namespaces ..................................20
4.3. Additional Abstract Data Types ............................21
4.3.1. Interface ..........................................21
4.3.2. Membership Events ..................................21
4.4. Group Management Calls ....................................22
4.4.1. Create .............................................22
4.4.2. Delete .............................................22
4.4.3. Join ...............................................22
4.4.4. Leave ..............................................23
4.4.5. Source Register ....................................23
4.4.6. Source Deregister ..................................23
4.5. Send and Receive Calls ....................................24
4.5.1. Send ...............................................24
4.5.2. Receive ............................................24
4.6. Socket Options ............................................25
4.6.1. Get Interfaces .....................................25
4.6.2. Add Interface ......................................25
4.6.3. Delete Interface ...................................26
4.6.4. Set TTL ............................................26
4.6.5. Get TTL ............................................26
4.6.6. Atomic Message Size ................................27
4.7. Service Calls .............................................27
4.7.1. Group Set ..........................................27
4.7.2. Neighbor Set .......................................28
4.7.3. Children Set .......................................28
4.7.4. Parent Set .........................................28
4.7.5. Designated Host ....................................29
4.7.6. Enable Membership Events ...........................29
4.7.7. Disable Membership Events ..........................30
4.7.8. Maximum Message Size ...............................30
5. Implementation .................................................30
6. IANA Considerations ............................................30
7. Security Considerations ........................................31
8. Acknowledgements ...............................................31
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................33
Appendix A. C Signatures ..........................................35
Appendix B. Use Case for the API ..................................37
Appendix C. Deployment Use Cases for Hybrid Multicast .............38
C.1. DVMRP ......................................................38
C.2. PIM-SM .....................................................38
C.3. PIM-SSM ....................................................39
C.4. BIDIR-PIM ..................................................40
Currently, group application programmers need to choose the distribution technology that the application will require at runtime. There is no common communication Interface that abstracts multicast transmission and subscriptions from the deployment state at runtime, nor has the use of DNS for Group Addresses been established. The standard multicast socket options [RFC3493] [RFC3678] are bound to an IP version by not distinguishing between the naming and addressing of multicast identifiers. Group communication, however,
現在、グループアプリケーションプログラマは、アプリケーションが実行時に必要とする配布テクノロジを選択する必要があります。実行時にデプロイメント状態からマルチキャスト送信とサブスクリプションを抽象化する共通の通信インターフェースはなく、グループアドレスにDNSを使用することも確立されていません。標準のマルチキャストソケットオプション[RFC3493] [RFC3678]は、マルチキャスト識別子の命名とアドレス指定を区別しないことにより、IPバージョンにバインドされています。ただし、グループコミュニケーション
o is commonly implemented in different flavors, such as any-source multicast (ASM) vs. source-specific multicast (SSM),
o エニーソースマルチキャスト（ASM）とソース固有のマルチキャスト（SSM）など、さまざまなフレーバーで一般的に実装されています。
o is commonly implemented on different layers (e.g., IP vs. application-layer multicast), and
o 通常、さまざまなレイヤーに実装されています（IPとアプリケーションレイヤーのマルチキャストなど）。
o may be based on different technologies on the same tier, as seen with IPv4 vs. IPv6.
o IPv4とIPv6で見られるように、同じ層の異なるテクノロジーに基づいている場合があります。
The objective of this document is to provide for programmers a universal access to group services.
このドキュメントの目的は、グループサービスへの普遍的なアクセスをプログラマーに提供することです。
Multicast application development should be decoupled from technological deployment throughout the infrastructure. It requires a common multicast API that offers calls to transmit and receive multicast data independent of the supporting layer and the underlying technological details. For inter-technology transmissions, a consistent view of multicast states is needed as well. This document describes an abstract group communication API and core functions necessary for transparent operations. Specific implementation guidelines with respect to operating systems or programming languages are out of scope for this document.
マルチキャストアプリケーションの開発は、インフラストラクチャ全体の技術的な展開から切り離す必要があります。これには、サポートレイヤーや基盤となる技術的な詳細に関係なく、マルチキャストデータを送受信するための呼び出しを提供する共通のマルチキャストAPIが必要です。テクノロジー間の送信では、マルチキャストの状態の一貫したビューも必要です。このドキュメントでは、透過的な操作に必要な抽象グループ通信APIとコア関数について説明します。オペレーティングシステムまたはプログラミング言語に関する特定の実装ガイドラインは、このドキュメントの範囲外です。
In contrast to the standard multicast socket Interface, the API introduced in this document abstracts naming from addressing. Using a multicast address in the current socket API predefines the corresponding routing layer. In this specification, the multicast name used for joining a group denotes an application-layer data stream that is identified by a multicast URI, independent of its binding to a specific distribution technology. Such a Group Name can be mapped to variable routing identifiers.
標準のマルチキャストソケットインターフェイスとは対照的に、このドキュメントで紹介するAPIは、アドレス指定から名前を抽象化します。現在のソケットAPIでマルチキャストアドレスを使用すると、対応するルーティングレイヤーが事前定義されます。この仕様では、グループに参加するために使用されるマルチキャスト名は、特定の配信技術へのバインディングとは関係なく、マルチキャストURIによって識別されるアプリケーション層のデータストリームを示します。このようなグループ名は、可変ルーティング識別子にマッピングできます。
The aim of this common API is twofold:
この共通APIの目的は2つあります。
o Enable any application programmer to implement group-oriented data communication independent of the underlying delivery mechanisms. In particular, allow for a late binding of group applications to multicast technologies that makes applications efficient but robust with respect to deployment aspects.
o すべてのアプリケーションプログラマが、基盤となる配信メカニズムに依存しないグループ指向のデータ通信を実装できるようにします。特に、グループアプリケーションをマルチキャストテクノロジーにレイトバインディングして、アプリケーションを効率的でありながら、展開の面で堅牢にすることができます。
o Allow for flexible namespace support in group addressing and thereby separate naming and addressing (or routing) schemes from the application design. This abstraction not only decouples programs from specific aspects of underlying protocols but may open application design to extend to specifically flavored group services.
o グループアドレッシングにおける柔軟な名前空間のサポートを可能にし、それによってアプリケーション設計から命名およびアドレッシング（またはルーティング）スキームを分離します。この抽象化は、プログラムを基礎となるプロトコルの特定の側面から切り離すだけでなく、アプリケーション設計を開いて、特別にフレーバー化されたグループサービスに拡張することもできます。
Multicast technologies may be of various peer-to-peer kinds, IPv4 or IPv6 network-layer multicast, or implemented by some other application service. Corresponding namespaces may be IP addresses or DNS naming, overlay hashes, or other application-layer group identifiers like <sip:*@peanuts.org>, but they can also be names independently defined by the applications. Common namespaces are introduced later in this document but follow an open concept suitable for further extensions.
マルチキャストテクノロジは、さまざまなピアツーピアの種類、IPv4またはIPv6ネットワーク層マルチキャスト、または他のアプリケーションサービスによって実装されます。対応する名前空間は、IPアドレスまたはDNSの名前付け、オーバーレイハッシュ、または<sip：* @ peanuts.org>のような他のアプリケーション層グループ識別子ですが、アプリケーションによって個別に定義された名前にすることもできます。共通の名前空間はこのドキュメントの後半で紹介されていますが、さらなる拡張に適したオープンコンセプトに従っています。
This document also discusses mapping mechanisms between different namespaces and forwarding technologies and proposes expressions of defaults for an intended binding. Additionally, the multicast API provides internal Interfaces to access current multicast states at the host. Multiple multicast protocols may run in parallel on a single host. These protocols may interact to provide a gateway function that bridges data between different domains. The usage of this API at gateways operating between current multicast instances throughout the Internet is described as well. Finally, a report on an implementation of the programming Interface, including service middleware, is presented.
このドキュメントでは、さまざまな名前空間と転送テクノロジー間のマッピングメカニズムについても説明し、目的のバインディングのデフォルトの表現を提案します。さらに、マルチキャストAPIは、ホストの現在のマルチキャスト状態にアクセスするための内部インターフェースを提供します。複数のマルチキャストプロトコルは、単一のホスト上で並行して実行できます。これらのプロトコルは相互に作用して、異なるドメイン間でデータをブリッジするゲートウェイ機能を提供します。インターネット全体の現在のマルチキャストインスタンス間で動作するゲートウェイでのこのAPIの使用についても説明します。最後に、サービスミドルウェアを含むプログラミングインターフェイスの実装に関するレポートが表示されます。
This document represents the consensus of the SAM Research Group. It has been reviewed by the Research Group members active in the specific area of work. In addition, this document has been comprehensively reviewed by people who are not "in" the Research Group but are experts in the area.
このドキュメントは、SAM Research Groupのコンセンサスを表しています。特定の分野で活動している研究グループのメンバーによってレビューされました。さらに、このドキュメントは、リサーチグループに所属していないが、その分野の専門家である人々によって包括的にレビューされています。
The following generic use cases can be identified; these use cases require an abstract common API for multicast services:
次の一般的な使用例を特定できます。これらのユースケースには、マルチキャストサービス用の抽象的な共通APIが必要です。
Application Programming Independent of Technologies: Application programmers are provided with group primitives that remain independent of multicast technologies and their deployment in target domains. Thus, for a given application, they can develop a program that will run in every deployment scenario. The use of Group Names in the form of abstract metadata types allows applications to remain namespace-agnostic in the sense that the resolution of namespaces and name-to-address mappings may be delegated to a system service at runtime. Complexity is thereby minimized, as developers need not care about how data is distributed in groups, while the system service can take advantage of extended information of the network environment as acquired at startup.
テクノロジーに依存しないアプリケーションプログラミング：アプリケーションプログラマーには、マルチキャストテクノロジーやターゲットドメインでの展開に依存しないグループプリミティブが提供されます。したがって、特定のアプリケーションについて、すべての展開シナリオで実行されるプログラムを開発できます。抽象メタデータタイプの形式でグループ名を使用すると、名前空間の解決と名前からアドレスへのマッピングが実行時にシステムサービスに委任される場合があるという意味で、アプリケーションは名前空間にとらわれないままで済みます。システムサービスは起動時に取得されるネットワーク環境の拡張情報を利用できる一方で、開発者はデータがグループでどのように分散されるかを気にする必要がないため、複雑さが最小限に抑えられます。
Global Identification of Groups: Groups can be identified independent of technological instantiations and beyond deployment domains. Taking advantage of the abstract naming, an application can thus match data received from different Interface technologies (e.g., IPv4, IPv6, and overlays) to belong to the same group. This not only increases flexibility -- an application may, for instance, combine heterogeneous multipath streams -- but also simplifies the design and implementation of gateways.
グループのグローバル識別：グループは、技術的なインスタンス化とは関係なく、展開ドメインを超えて識別できます。抽象命名を利用して、アプリケーションは、異なるグループテクノロジー（IPv4、IPv6、オーバーレイなど）から受信したデータを一致させて、同じグループに所属させることができます。これにより、柔軟性が高まるだけでなく（たとえば、アプリケーションが異種のマルチパスストリームを組み合わせる場合もある）、ゲートウェイの設計と実装も簡素化されます。
Uniform Access to Multicast Flavors: The URI naming scheme uniformly supports different flavors of group communication, such as any-source multicast and source-specific multicast, and selective broadcast, independent of their service instantiation. The traditional SSM model, for instance, can experience manifold support by directly mapping the multicast URI (i.e., "group@instantiation") to an (S,G) state on the IP layer, by first resolving S for a subsequent Group Address query, by transferring this process to any of the various source-specific overlay schemes, or by delegating to a plain replication server. The application programmer can invoke any of these underlying mechanisms with the same line of code.
マルチキャストフレーバーへの均一なアクセス：URIの名前付けスキームは、サービスのインスタンス化とは関係なく、任意のソースマルチキャストやソース固有のマルチキャスト、選択的なブロードキャストなど、グループ通信のさまざまなフレーバーを均一にサポートします。たとえば、従来のSSMモデルでは、最初にSを解決して後続のグループアドレスクエリを実行することにより、マルチキャストURI（つまり、「group @ instantiation」）をIPレイヤーの（S、G）状態に直接マッピングすることで、多様なサポートを体験できます。 、このプロセスをさまざまなソース固有のオーバーレイスキームのいずれかに転送するか、プレーンレプリケーションサーバーに委任します。アプリケーションプログラマは、同じコード行でこれらの基本的なメカニズムを呼び出すことができます。
Simplified Service Deployment through Generic Gateways: The common multicast API allows for an implementation of abstract gateway functions with mappings to specific technologies residing at the system level. Generic gateways may provide a simple bridging service and facilitate an inter-domain deployment of multicast.
汎用ゲートウェイを介した簡素化されたサービスの展開：共通のマルチキャストAPIにより、システムレベルに存在する特定のテクノロジーへのマッピングを備えた抽象的なゲートウェイ機能の実装が可能になります。汎用ゲートウェイは、単純なブリッジングサービスを提供し、マルチキャストのドメイン間展開を容易にする場合があります。
Mobility-Agnostic Group Communication: Group naming and management as foreseen in the common multicast API remain independent of locators. Naturally, applications stay unaware of any mobility-related address changes. Handover-initiated re-addressing is delegated to the mapping services at the system level and may be designed to smoothly interact with mobility management solutions provided at the network or transport layer (see [RFC5757] for mobility-related aspects).
モビリティにとらわれないグループ通信：一般的なマルチキャストAPIで予測されるグループの命名と管理は、ロケーターから独立しています。当然、アプリケーションはモビリティ関連のアドレス変更を認識しません。ハンドオーバーによって開始される再アドレッシングは、システムレベルでマッピングサービスに委任され、ネットワークまたはトランスポートレイヤーで提供されるモビリティ管理ソリューションとスムーズに対話するように設計できます（モビリティ関連の側面については[RFC5757]を参照）。
On a very high level, the common multicast API provides the application programmer with one single Interface to manage multicast content independent of the technology underneath. Considering the following simple example in Figure 1, a multicast source S is connected via IPv4 and IPv6. It distributes one flow of multicast content (e.g., a movie). Receivers are connected via IPv4/v6 and Overlay Multicast (OM), respectively.
非常に高いレベルでは、共通のマルチキャストAPIは、アプリケーションプログラマーに単一のインターフェースを提供し、その下にあるテクノロジーとは独立してマルチキャストコンテンツを管理します。図1の次の簡単な例を考えると、マルチキャストソースSはIPv4とIPv6を介して接続されています。マルチキャストコンテンツ（映画など）の1つのフローを配信します。レシーバーはそれぞれIPv4 / v6とオーバーレイマルチキャスト（OM）を介して接続されます。
+-------+ +-------+ +-------+
| S | | R1 | | R3 |
+-------+ +-------+ +-------+
v6| v4| |v4 |OM
| | / |
| ***| *** ***/ ** *** /*** *** ***
\* |* ** /** * * /* ** ** *
*\ \_______/_______*__v4__+-------+ * / *
*\ IPv4/v6 * | R2 |__OM__ *_/ Overlay Mcast *
* \_________________*__v6__+-------+ * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
Figure 1: Common Scenario: Source S Sends the Same Multicast Content via Different Technologies
図1：一般的なシナリオ：ソースSが異なるテクノロジーを介して同じマルチキャストコンテンツを送信する
Using the current BSD socket API, the application programmer needs to decide on the IP technologies at coding time. Additional distribution techniques, such as overlay multicast, must be individually integrated into the application. For each technology, the application programmer needs to create a separate socket and initiate a dedicated join or send. As the current socket API does not distinguish between Group Name and Group Address, the content will be delivered multiple times to the same receiver (cf. R2). Whenever the source distributes content via a technology that is not supported by the receivers or its Internet Service Provider (cf. R3), a gateway is required. Gateway functions rely on a coherent view of the Multicast Group states.
現在のBSDソケットAPIを使用して、アプリケーションプログラマーはコーディング時にIPテクノロジを決定する必要があります。オーバーレイマルチキャストなどの追加の配信技術は、アプリケーションに個別に統合する必要があります。各テクノロジーについて、アプリケーションプログラマーは個別のソケットを作成し、専用の結合または送信を開始する必要があります。現在のソケットAPIはグループ名とグループアドレスを区別しないため、コンテンツは同じ受信者に複数回配信されます（R2を参照）。ソースが受信者またはそのインターネットサービスプロバイダー（R3を参照）でサポートされていないテクノロジを介してコンテンツを配信する場合は常に、ゲートウェイが必要です。ゲートウェイ機能は、マルチキャストグループの状態の一貫したビューに依存しています。
The common multicast API simplifies programming of multicast applications, as it abstracts content distribution from specific technologies. In addition to calls that implement the receiving and sending of multicast data, the API provides service calls to grant access to internal multicast states at the host. The API description provided in this document defines a minimal set of programming Interfaces to the system components at the host to operate group communication. It is left to specific implementations to provide additional convenience functions for programmers.
共通のマルチキャストAPIは、特定のテクノロジーからコンテンツ配信を抽象化するため、マルチキャストアプリケーションのプログラミングを簡素化します。 APIは、マルチキャストデータの送受信を実装する呼び出しに加えて、ホストで内部マルチキャスト状態へのアクセスを許可するサービス呼び出しを提供します。このドキュメントで提供されるAPIの説明では、グループ通信を操作するためのホストのシステムコンポーネントへのプログラミングインターフェースの最小限のセットを定義しています。プログラマーに追加の便利な機能を提供するのは、特定の実装に任されています。
The implementation of content distribution for the example shown in Figure 1 may then look like:
図1に示す例のコンテンツ配信の実装は、次のようになります。
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Associate all available Interfaces
m.addInterface(getInterfaces());
//Subscribe to Multicast Group
m.join(URI("ham:opaque:news@cnn.com"));
//Send to Multicast Group
m.send(URI("ham:opaque:news@cnn.com"),message);
Send/receive example using the common multicast API
一般的なマルチキャストAPIを使用した送受信の例
The gateway function for R2 can be implemented by service calls that look like:
R2のゲートウェイ機能は、次のようなサービス呼び出しによって実装できます。
//Initialize multicast socket
MulticastSocket m = new MulticastSocket();
//Check (a) host is designated multicast node for this Interface
// (b) receivers exist
for all this.getInterfaces() {
if(designatedHost(this.interface) &&
childrenSet(this.interface,
URI("ham:opaque:news@cnn.com")) != NULL) {
m.addInterface(this.interface);
}
}
while(true) {
m.send(URI("ham:opaque:news@cnn.com"),message);
}
Gateway example using the common multicast API
一般的なマルチキャストAPIを使用したゲートウェイの例
Multi-resolution multicast adjusts the multicast stream to consider heterogeneous end devices. The multicast data (e.g., available by different compression levels) is typically announced using multiple multicast addresses that are unrelated to each other. Using the common API, multi-resolution multicast can be implemented transparently by an operator with the help of name-to-address mapping, or by systematic naming from a subscriber-centric perspective.
マルチレゾリューションマルチキャストは、マルチキャストストリームを調整して、異種のエンドデバイスを考慮します。マルチキャストデータ（さまざまな圧縮レベルで利用可能など）は、通常、互いに関連のない複数のマルチキャストアドレスを使用してアナウンスされます。共通APIを使用すると、オペレーターは名前からアドレスへのマッピングを利用して、またはサブスクライバー中心の観点から体系的に命名することにより、マルチ解像度マルチキャストを透過的に実装できます。
Operator-Centric: An operator deploys a domain-specific mapping. In this case, any multicast receiver (e.g., mobile or DSL user) subscribes to the same multicast name, which will be resolved locally to different multicast addresses. In this case, each Group Address represents a different level of data quality.
オペレーター中心：オペレーターはドメイン固有のマッピングをデプロイします。この場合、マルチキャストレシーバー（モバイルユーザーやDSLユーザーなど）は同じマルチキャスト名にサブスクライブします。これは、ローカルで異なるマルチキャストアドレスに解決されます。この場合、各グループアドレスは異なるレベルのデータ品質を表します。
Subscriber-Centric: In a subscriber-centric example, the multicast receiver chooses the quality in advance, based on a predefined naming syntax. Consider a layered video stream "blockbuster" available at different qualities Q_i, each of which consists of the base layer plus the sum of EL_j, j <= i enhancement layers. Each individual layer may then be accessible by a name "EL_j.Q_i.blockbuster", j <= i, while a specific quality aggregates the corresponding layers to "Q_i.blockbuster", and the full-size movie may be just called "blockbuster".
サブスクライバー中心：サブスクライバー中心の例では、マルチキャストレシーバーは、事前定義された命名構文に基づいて、品質を事前に選択します。さまざまな品質Q_iで利用可能なレイヤードビデオストリーム「ブロックバスター」を考えてみましょう。それぞれの品質は、ベースレイヤーとEL_j、j <= iエンハンスメントレイヤーの合計で構成されています。個々のレイヤーにはそれぞれ「EL_j.Q_i.blockbuster」、j <= iという名前でアクセスできますが、特定の品質では対応するレイヤーが「Q_i.blockbuster」に集約され、フルサイズの映画は単に「ブロックバスター」と呼ばれます。 」
This document uses the terminology as defined for the multicast protocols discussed in [RFC2710], [RFC3376], [RFC3810], [RFC4601], and [RFC4604]. In addition, the following terms will be used:
このドキュメントでは、[RFC2710]、[RFC3376]、[RFC3810]、[RFC4601]、および[RFC4604]で説明されているマルチキャストプロトコルに定義されている用語を使用します。さらに、次の用語が使用されます。
Group Address: A Group Address is a routing identifier. It represents a technological specifier and thus reflects the distribution technology in use. Multicast packet forwarding is based on this address.
グループアドレス：グループアドレスはルーティング識別子です。これは技術仕様を表しており、使用中の流通技術を反映しています。マルチキャストパケット転送は、このアドレスに基づいています。
Group Name: A Group Name is an application identifier used by applications to manage communication in a Multicast Group (e.g., join/leave and send/receive). The Group Name does not predefine any distribution technologies. Even if it syntactically corresponds to an address, it solely represents a logical identifier.
グループ名：グループ名は、マルチキャストグループでの通信を管理するためにアプリケーションで使用されるアプリケーション識別子です（例：参加/脱退、送信/受信）。グループ名は、配布テクノロジーを事前に定義するものではありません。構文的にアドレスに対応していても、論理的な識別子を表すだけです。
Multicast Namespace: A Multicast Namespace is a collection of designators (i.e., names or addresses) for groups that share a common syntax. Typical instances of namespaces are IPv4 or IPv6 multicast addresses, overlay group IDs, Group Names defined on the application layer (e.g., SIP or email), or some human-readable string.
マルチキャスト名前空間：マルチキャスト名前空間は、共通の構文を共有するグループの指定子（つまり、名前またはアドレス）のコレクションです。名前空間の一般的なインスタンスは、IPv4またはIPv6マルチキャストアドレス、オーバーレイグループID、アプリケーションレイヤーで定義されたグループ名（SIPや電子メールなど）、または人間が読める文字列です。
Interface: An Interface is a forwarding instance of a distribution technology on a given node, for example, the IP Interface 192.168.1.1 at an IPv4 host, or an overlay routing Interface.
インターフェース：インターフェースは、特定のノード上の配布テクノロジーの転送インスタンスです。たとえば、IPv4ホストのIPインターフェース192.168.1.1、またはオーバーレイルーティングインターフェースです。
Multicast Domain: A Multicast Domain hosts nodes and routers of a common, single multicast forwarding technology and is bound to a single namespace.
マルチキャストドメイン：マルチキャストドメインは、一般的な単一のマルチキャスト転送テクノロジのノードとルーターをホストし、単一の名前空間にバインドされます。
Inter-domain Multicast Gateway (IMG): An IMG is an entity that interconnects different Multicast Domains. Its objective is to forward data between these domains, e.g., between an IP layer and overlay multicast.
ドメイン間マルチキャストゲートウェイ（IMG）：IMGは、さまざまなマルチキャストドメインを相互接続するエンティティです。その目的は、IPレイヤーとオーバーレイマルチキャストの間など、これらのドメイン間でデータを転送することです。
The default use case addressed in this document targets applications that participate in a group by using some common identifier taken from some common namespace. This Group Name is typically learned at runtime from user interaction, such as the selection of an IPTV channel, or from dynamic session negotiations as used with the Session Initiation Protocol (SIP) [RFC3261] or Peer-to-Peer SIP (P2PSIP) [SIP-RELOAD], but may as well have been predefined for an application as a common Group Name. Technology-specific system functions then transparently map the Group Name to Group Addresses such that
このドキュメントで取り上げられているデフォルトの使用例は、いくつかの一般的な名前空間から取得したいくつかの一般的な識別子を使用して、グループに参加するアプリケーションを対象としています。このグループ名は通常、実行時にIPTVチャネルの選択などのユーザーインタラクションから、またはセッション開始プロトコル（SIP）[RFC3261]またはピアツーピアSIP（P2PSIP）で使用される動的セッションネゴシエーションから学習されます。 SIP-RELOAD]ですが、一般的なグループ名としてアプリケーションに事前定義されている場合もあります。テクノロジー固有のシステム関数は、グループ名をグループアドレスに透過的にマッピングします。
o programmers can process Group Names in their programs without the need to consider technological mappings that relate to designated deployments in target domains;
o プログラマーは、ターゲットドメイン内の指定されたデプロイメントに関連する技術的なマッピングを考慮する必要なく、プログラム内のグループ名を処理できます。
o applications can identify packets that belong to a logically named group, independent of the Interface technology used for sending and receiving packets; this shall also hold true for multicast gateways.
o アプリケーションは、パケットの送受信に使用されるインターフェース技術とは関係なく、論理的に名前が付けられたグループに属するパケットを識別できます。これは、マルチキャストゲートウェイにも当てはまります。
This document considers two reference scenarios that cover the following hybrid deployment cases displayed in Figure 2:
このドキュメントでは、図2に表示されている次のハイブリッド展開のケースをカバーする2つの参照シナリオについて検討します。
1. Multicast Domains running the same multicast technology but remaining isolated, possibly only connected by network-layer unicast.
1. 同じマルチキャストテクノロジを実行しているが分離されたままのマルチキャストドメイン。おそらくネットワーク層のユニキャストによってのみ接続されます。
2. Multicast Domains running different multicast technologies but hosting nodes that are members of the same Multicast Group.
2. 異なるマルチキャストテクノロジーを実行しているが、同じマルチキャストグループのメンバーであるノードをホストしているマルチキャストドメイン。
+-------+ +-------+
| Member| | Member|
| Foo | | G |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
* *
* Mcast Tech. A *
* *
* ** ** ** *
*** *** *** ***
+-------+ +-------+ |
| Member| | Member| +-------+
| G | | Foo | | IMG |
+-------+ +-------+ +-------+
| | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * +-------+ * *
* Mcast Tech. A * --| IMG |-- * Mcast Tech. B * +------+
* * +-------+ * * -|Member|
* ** ** ** * * ** ** ** * | G |
*** *** *** *** *** *** *** *** +------+
Figure 2: Reference Scenarios for Hybrid Multicast, Interconnecting Group Members from Isolated Homogeneous and Heterogeneous Domains
図2：孤立した同種ドメインと異種ドメインからグループメンバーを相互接続するハイブリッドマルチキャストの参照シナリオ
The group communication API abstracts the socket concept and consists of four parts. Two parts combine the essential communication functions, while the remaining two offer optional extensions for enhanced monitoring and management:
グループ通信APIは、ソケットの概念を抽象化し、4つの部分で構成されています。 2つの部分は基本的な通信機能を組み合わせ、残りの2つは拡張された監視と管理のためのオプションの拡張機能を提供します。
Group Management Calls: provide the minimal API to instantiate an abstract multicast socket and manage group membership;
グループ管理呼び出し：最小限のAPIを提供して、抽象マルチキャストソケットをインスタンス化し、グループメンバーシップを管理します。
Send/Receive Calls: provide the minimal API to send and receive multicast data in a technology-transparent fashion;
コールの送受信：テクノロジー透過的な方法でマルチキャストデータを送受信するための最小限のAPIを提供します。
Socket Options: provide extension calls for an explicit configuration of the multicast socket, such as setting hop limits or associated Interfaces;
ソケットオプション：ホップリミットや関連するインターフェイスの設定など、マルチキャストソケットの明示的な構成のための拡張呼び出しを提供します。
Service Calls: provide extension calls that grant access to internal multicast states of an Interface, such as the Multicast Groups under subscription or the multicast forwarding information base.
サービス呼び出し：サブスクリプション下のマルチキャストグループやマルチキャスト転送情報ベースなど、インターフェースの内部マルチキャスト状態へのアクセスを許可する拡張呼び出しを提供します。
Multicast applications that use the common API require assistance from a group communication stack. This protocol stack serves two needs:
共通APIを使用するマルチキャストアプリケーションには、グループ通信スタックの支援が必要です。このプロトコルスタックは2つのニーズに対応します。
o It provides system-level support to transfer the abstract functions of the common API, including namespace support, into protocol operations at Interfaces.
o ネームスペースのサポートを含む共通APIの抽象機能をインターフェイスのプロトコル操作に転送するためのシステムレベルのサポートを提供します。
o It provides group communication services across different multicast technologies at the local host.
o ローカルホストのさまざまなマルチキャストテクノロジー全体にグループ通信サービスを提供します。
A general initiation of a multicast communication in this setting proceeds as follows:
この設定でのマルチキャスト通信の一般的な開始は、次のように進行します。
1. An application opens an abstract multicast socket.
1. アプリケーションが抽象的なマルチキャストソケットを開きます。
2. The application subscribes to / leaves / (de)registers a group using a Group Name.
2. アプリケーションは、グループ名を使用してグループをサブスクライブ/脱退/（登録解除）します。
3. An intrinsic function of the stack maps the logical group ID (Group Name) to a technical group ID (Group Address). This function may make use of deployment-specific knowledge, such as available technologies and Group Address management in its domain.
3. スタックの組み込み関数は、論理グループID（グループ名）を技術グループID（グループアドレス）にマップします。この機能は、利用可能なテクノロジーやドメイン内のグループアドレス管理など、展開固有の知識を利用する場合があります。
4. Packet distribution proceeds to and from one or several multicast-enabled Interfaces.
4. パケット配信は、1つ以上のマルチキャスト対応インターフェースとの間で行われます。
The abstract multicast socket represents a group communication channel composed of one or multiple Interfaces. A socket may be created without explicit Interface association by the application, which leaves the choice of the underlying forwarding technology to the group communication stack. However, an application may also bind the socket to one or multiple dedicated Interfaces and therefore predefine the forwarding technology and the Multicast Namespace(s) of the Group Address(es).
抽象マルチキャストソケットは、1つまたは複数のインターフェイスで構成されるグループ通信チャネルを表します。ソケットは、アプリケーションによる明示的なインターフェイスの関連付けなしで作成できます。これにより、基盤となる転送テクノロジーの選択がグループ通信スタックに委ねられます。ただし、アプリケーションは、ソケットを1つまたは複数の専用インターフェースにバインドすることもできるため、転送技術とグループアドレスのマルチキャスト名前空間を事前定義します。
Applications are not required to maintain mapping states for Group Addresses. The group communication stack accounts for the mapping of the Group Name to the Group Address(es) and vice versa. Multicast data passed to the application will be augmented by the corresponding Group Name. Multiple multicast subscriptions thus can be conducted on a single multicast socket without the need for Group Name encoding on the application side.
アプリケーションは、グループアドレスのマッピング状態を維持する必要はありません。グループ通信スタックは、グループ名からグループアドレスへのマッピング、およびその逆を説明します。アプリケーションに渡されるマルチキャストデータは、対応するグループ名によって拡張されます。したがって、アプリケーション側でグループ名エンコーディングを必要とせずに、単一のマルチキャストソケットで複数のマルチキャストサブスクリプションを実行できます。
Hosts may support several multicast protocols. The group communication stack discovers available multicast-enabled Interfaces. It provides a minimal hybrid function that bridges data between different Interfaces and Multicast Domains. The details of service discovery are out of scope for this document.
ホストは複数のマルチキャストプロトコルをサポートする場合があります。グループ通信スタックは、使用可能なマルチキャスト対応インターフェースを検出します。異なるインターフェースとマルチキャストドメイン間でデータをブリッジする最小限のハイブリッド機能を提供します。サービス検出の詳細は、このドキュメントの範囲外です。
The extended multicast functions can be implemented by middleware, as conceptually presented in Figure 3.
図3に概念的に示されているように、拡張マルチキャスト機能はミドルウェアによって実装できます。
*-------* *-------*
| App 1 | | App 2 |
*-------* *-------*
| |
*---------------------* ---|
| Middleware | |
*---------------------* |
| | |
*---------* | |
| Overlay | | \ Group Communication
*---------* | / Stack
| | |
| | |
*---------------------* |
| Underlay | |
*---------------------* ---|
Figure 3: Architecture of a Group Communication Stack with Middleware Offering Uniform Access to Multicast in Underlay and Overlay
図3：アンダーレイとオーバーレイのマルチキャストへの均一なアクセスを提供するミドルウェアを備えたグループ通信スタックのアーキテクチャ
Applications use Group Names to identify groups. Names can uniquely determine a group in a global communication context and hide technological deployment for data distribution from the application. In contrast, multicast forwarding operates on Group Addresses. Even though both identifiers may be symbolically identical, they carry different meanings. They may also belong to different Multicast Namespaces. The namespace of a Group Address reflects a routing technology, while the namespace of a Group Name represents the context in which the application operates.
アプリケーションはグループ名を使用してグループを識別します。名前は、グローバルな通信コンテキストでグループを一意に決定し、アプリケーションからのデータ配布のための技術的な展開を隠すことができます。対照的に、マルチキャスト転送はグループアドレスで動作します。両方の識別子は象徴的に同一であっても、意味は異なります。また、異なるマルチキャスト名前空間に属している場合もあります。グループアドレスの名前空間はルーティングテクノロジーを反映し、グループ名の名前空間はアプリケーションが動作するコンテキストを表します。
URIs [RFC3986] are a common way to represent namespace-specific identifiers in applications in the form of an abstract metadata type. Throughout this document, all Group Names follow a URI notation using the syntax defined in Section 4.2. Examples are ham:ip:224.1.2.3:5000 for a canonical IPv4 ASM group at UDP port 5000 and ham:sip:news@cnn.com for application-specific naming with service instantiator and default port selection.
URI [RFC3986]は、抽象メタデータ型の形式でアプリケーションで名前空間固有の識別子を表す一般的な方法です。このドキュメント全体を通して、すべてのグループ名は、セクション4.2で定義された構文を使用したURI表記に従います。例は、UDPポート5000の正規IPv4 ASMグループの場合はham：ip：224.1.2.3：5000であり、サービスインスタンシエーターとデフォルトのポート選択を使用したアプリケーション固有の命名の場合はham：sip：news@cnn.comです。
An implementation of the group communication stack can provide convenience functions that detect the namespace of a Group Name or further optimize service instantiation. In practice, such a library would provide support for high-level data types to the application, similar to some versions of the current socket API (e.g., InetAddress in Java). Using this data type could implicitly determine the namespace. The details of automatic namespace identification or service handling are out of scope for this document.
グループ通信スタックの実装は、グループ名の名前空間を検出するか、サービスのインスタンス化をさらに最適化する便利な機能を提供できます。実際には、このようなライブラリは、現在のソケットAPIの一部のバージョン（JavaのInetAddressなど）と同様に、アプリケーションに高レベルのデータ型をサポートします。このデータ型を使用すると、暗黙的に名前空間を決定できます。自動名前空間識別またはサービス処理の詳細は、このドキュメントの範囲外です。
Namespace identifiers in URIs are placed in the scheme element and characterize syntax and semantics of the group identifier. They enable the use of convenience functions and high-level data types while processing URIs. When used in names, they may indicate an application context or may facilitate a default mapping and a recovery of names from addresses. When used in addresses, they characterize the group identifier's type.
URIの名前空間識別子は、scheme要素に配置され、グループ識別子の構文とセマンティクスを特徴付けます。 URIの処理中に、便利な関数と高レベルのデータ型を使用できます。名前で使用すると、アプリケーションコンテキストを示したり、デフォルトのマッピングやアドレスからの名前の回復を容易にしたりできます。アドレスで使用すると、グループ識別子のタイプを特徴付けます。
In compliance with the URI concept, namespace schemes can be added. Examples of schemes are generic (see Section 4.2.3) or inherited from applications (see Section 4.2.4).
URIの概念に準拠して、名前空間スキームを追加できます。スキームの例は、一般的なもの（セクション4.2.3を参照）またはアプリケーションから継承されたもの（セクション4.2.4を参照）です。
The multicast communication paradigm requires all group members to subscribe to the same Group Name, taken from a common Multicast Namespace, and to thereby identify the group in a technology-agnostic way. Following this common API, a sender correspondingly registers a Group Name prior to transmission.
マルチキャスト通信パラダイムでは、すべてのグループメンバーが、共通のマルチキャストネームスペースから取得した同じグループ名にサブスクライブし、テクノロジーにとらわれない方法でグループを識別する必要があります。この共通APIに従って、送信者は送信前に対応してグループ名を登録します。
At communication end points, Group Names require a mapping to Group Addresses prior to service instantiation at the Interfaces of the end points. Similarly, a mapping is needed at gateways to consistently translate between Group Addresses from different namespaces. Two requirements need to be met by a mapping function that translates between Multicast Names and Addresses:
通信エンドポイントでは、グループ名は、エンドポイントのインターフェイスでサービスをインスタンス化する前に、グループアドレスへのマッピングが必要です。同様に、異なるネームスペースのグループアドレス間で一貫して変換するには、ゲートウェイでマッピングが必要です。マルチキャスト名とアドレスの間を変換するマッピング関数が満たす必要のある2つの要件：
a. For a given Group Name, identify an Address that is appropriate for a local distribution instance.
a. 特定のグループ名について、ローカル配布インスタンスに適したアドレスを特定します。
b. For a given Group Address, invert the mapping to recover the Group Name.
b. 特定のグループアドレスについて、マッピングを反転させてグループ名を復元します。
In general, mappings can be complex and do not need to be invertible. A mapping can be realized by embedding smaller namespaces into larger namespaces or selecting an arbitrary, unused ID in a smaller target namespace. For example, it is not obvious how to map a large identifier space (e.g., IPv6) to a smaller, collision-prone set like IPv4 (see [MCAST-v4v6-FRAMEWORK], [MCAST-v4v6], and [RFC6219]). Mapping functions can be stateless in some contexts but may require states in others. The application of such functions depends on the cardinality of the namespaces, the structure of address spaces, and possible address collisions. However, some namespaces facilitate a canonical, invertible transformation to default address spaces.
一般に、マッピングは複雑になる可能性があり、可逆である必要はありません。マッピングは、小さいネームスペースを大きいネームスペースに埋め込むか、小さいターゲットネームスペースで任意の未使用のIDを選択することで実現できます。たとえば、大きな識別子スペース（IPv6など）を、IPv4などの衝突しやすい小さなセットにマップする方法は明らかではありません（[MCAST-v4v6-FRAMEWORK]、[MCAST-v4v6]、および[RFC6219]を参照）。 。マッピング関数は、状況によってはステートレスになる場合がありますが、状況によっては状態が必要になる場合があります。このような関数の適用は、名前空間のカーディナリティ、アドレス空間の構造、および起こり得るアドレスの衝突に依存します。ただし、一部の名前空間は、デフォルトのアドレススペースへの標準的な可逆変換を容易にします。
Some Multicast Namespaces defined in Section 3.4 can express a canonical default mapping. For example, ham:ip:224.1.2.3:5000 indicates the correspondence to 224.1.2.3 in the default IPv4 multicast address space at port 5000. This default mapping is bound to a technology and may not always be applicable, e.g., in the case of address collisions. Note that under canonical mapping, the multicast URI can be completely recovered from any data message received within this group.
セクション3.4で定義されている一部のマルチキャスト名前空間は、標準のデフォルトマッピングを表すことができます。たとえば、ham：ip：224.1.2.3：5000は、ポート5000のデフォルトIPv4マルチキャストアドレス空間の224.1.2.3への対応を示します。このデフォルトマッピングはテクノロジーにバインドされており、常に適用できるとは限りません。たとえば、アドレスの衝突。正規マッピングでは、このグループ内で受信したデータメッセージからマルチキャストURIを完全に回復できることに注意してください。
Multicast listeners or senders require a name-to-address conversion for all technologies they actively run in a group. Even though a mapping applies to the local Multicast Domain only, end points may need to learn a valid Group Address from neighboring nodes, e.g., from a gateway in the collision-prone IPv4 domain. Once set, an end point will always be aware of the name-to-address correspondence and thus can autonomously invert the mapping.
マルチキャストリスナーまたは送信者は、グループでアクティブに実行されるすべてのテクノロジーについて、名前からアドレスへの変換を必要とします。マッピングはローカルマルチキャストドメインのみに適用されますが、エンドポイントは、隣接ノードから、たとえば衝突しやすいIPv4ドメインのゲートウェイから有効なグループアドレスを学習する必要がある場合があります。いったん設定されると、エンドポイントは名前とアドレスの対応を常に認識しているため、マッピングを自律的に反転できます。
Multicast data may arrive at an IMG via one technology and request that the gateway re-address packets for another distribution system. At initial arrival, the IMG may not have explicit knowledge of the corresponding Multicast Group Name. To perform a consistent mapping, the Group Name needs to be acquired. It may have been distributed at source registration or may have been learned from a neighboring node, the details of which are beyond the scope of this document.
マルチキャストデータは、1つのテクノロジを介してIMGに到着し、ゲートウェイが別の配信システムのパケットのアドレスを変更するように要求する場合があります。最初の到着時に、IMGは対応するマルチキャストグループ名を明確に認識していない場合があります。一貫したマッピングを実行するには、グループ名を取得する必要があります。送信元の登録時に配布されたか、隣接ノードから学習された可能性があります。その詳細はこのドキュメントの範囲外です。
In Explicit Multicast (Xcast) [RFC5058], the multicast source explicitly predefines the receivers. From a conceptual perspective, Xcast is an additional distribution technology (i.e., a new technology-specific Interface) for this API. Xcast requires aggregated knowledge of receivers that is available at the origin of the distribution tree. The instantiation part of the Group Name may refer to such a management instance and tree root, which can be the source or some co-located processor.
明示的マルチキャスト（Xcast）[RFC5058]では、マルチキャストソースは受信者を明示的に事前定義します。概念的な観点から見ると、XcastはこのAPIの追加の配信テクノロジー（つまり、新しいテクノロジー固有のインターフェース）です。 Xcastは、配信ツリーの起点で利用できる受信機の集約された知識を必要とします。グループ名のインスタンス化の部分は、ソースまたは同じ場所に配置されたプロセッサである可能性がある、そのような管理インスタンスとツリールートを参照する場合があります。
An implementation of Xcast then requires a topology-dependent mapping of the Group Name to the set of subscribers. The defining details of this multi-destination mapping are out of scope for this document.
Xcastの実装では、サブスクライバーのセットへのグループ名のトポロジー依存のマッピングが必要です。この複数宛先マッピングの定義の詳細は、このドキュメントの範囲外です。
This API considers a multi-technology scenario in which different technologies may have different Maximum Transmission Unit (MTU) sizes. Even if the MTU size between two hosts has been determined, it may change over time, as initiated by either the network (e.g., path changes) or end hosts (e.g., Interface changes due to mobility).
このAPIは、テクノロジーごとに最大転送ユニット（MTU）サイズが異なるマルチテクノロジーシナリオを考慮します。 2つのホスト間のMTUサイズが決定されている場合でも、ネットワーク（パスの変更など）またはエンドホスト（モビリティによるインターフェースの変更など）によって開始されるため、時間の経過とともに変化する可能性があります。
The design of this API is based on the objective of robust communication and easy application development. MTU handling and the implementation of fragmentation are thus guided by the following observations:
このAPIの設計は、堅牢な通信と簡単なアプリケーション開発の目的に基づいています。したがって、MTUの処理と断片化の実装は、次の観察によって導かれます。
Application: Application programmers need a simple way to transmit packets in a technology-agnostic fashion. For this, it is convenient at the time of coding to rely on a transparent maximum amount of data that can be sent in one message from a socket. A regular program flow should not be distracted by querying and changing MTU sizes. Technically, the configuration of the maximum message size used by the application programmer may change and disrupt communication when (a) Interfaces are added or excluded or (b) the path MTU changes during transmission and thus disables the corresponding Interfaces.
アプリケーション：アプリケーションプログラマーは、テクノロジーにとらわれない方法でパケットを送信する簡単な方法を必要としています。このため、ソケットから1つのメッセージで送信できる透過的な最大量のデータに依存すると、コーディング時に便利です。通常のプログラムフローは、MTUサイズのクエリと変更によって邪魔されるべきではありません。技術的には、アプリケーションプログラマが使用する最大メッセージサイズの構成は、（a）インターフェイスが追加または除外されたとき、または（b）転送中にパスMTUが変更され、対応するインターフェイスが無効になったときに、通信を変更および中断する場合があります。
Middleware: Middleware situated between application and technology Interfaces ensures a general packet-handling capability, which in turn prevents the application programmer from implementing fragmentation. A uniform maximum message size that cannot be changed during runtime shall be guaranteed by the group communication stack (e.g., middleware). Otherwise, this would conflict with a technology-agnostic application.
ミドルウェア：アプリケーションインターフェースとテクノロジーインターフェースの間にあるミドルウェアは、一般的なパケット処理機能を保証し、アプリケーションプログラマーが断片化を実装するのを防ぎます。実行時に変更できない統一された最大メッセージサイズは、グループ通信スタック（ミドルウェアなど）によって保証されます。さもなければ、これは技術にとらわれないアプリケーションと衝突するでしょう。
Technology Interfaces: Fragmentation requirements depend on the technology in use. Hence, the (technology-bound) Interfaces need to cope with MTU sizes that may vary among Interfaces and along different paths.
テクノロジーインターフェイス：断片化の要件は、使用しているテクノロジーによって異なります。したがって、（テクノロジーにバインドされた）インターフェイスは、インターフェイス間およびパスごとに異なるMTUサイズに対処する必要があります。
The concept of this API also aims at guaranteeing a maximum message size for the application programmer, to thereby handle fragmentation at the Interface level, if needed. Nevertheless, the application programmer should be able to determine the technology-specific atomic message size to optimize data distribution, or for other reasons.
このAPIの概念は、アプリケーションプログラマーの最大メッセージサイズを保証し、必要に応じてインターフェイスレベルでフラグメンテーションを処理することも目的としています。それにもかかわらず、アプリケーションプログラマーは、テクノロジー固有のアトミックメッセージサイズを決定して、データの分散を最適化するか、その他の理由で使用できる必要があります。
The uniform maximum message size should take realistic values (e.g., following IP clients) to enable smooth and efficient services. A detailed selection scheme of MTU values is out of scope for this document.
均一で最大のメッセージサイズは、スムーズで効率的なサービスを実現するために、現実的な値（たとえば、IPクライアントに続く）を取る必要があります。 MTU値の詳細な選択スキームは、このドキュメントの範囲外です。
The following description of the common multicast API is expressed in pseudo-syntax. Variables that are passed to function calls are declared by "in", and return values are declared by "out". A list of elements is denoted by "<>". The pseudo-syntax assumes that lists include an attribute that represents the number of elements.
以下の一般的なマルチキャストAPIの説明は、疑似構文で表現されています。関数呼び出しに渡される変数は「in」によって宣言され、戻り値は「out」によって宣言されます。要素のリストは「<>」で示されます。疑似構文は、リストに要素の数を表す属性が含まれていることを前提としています。
The corresponding C signatures are defined in Appendix A.
対応するCシグネチャは、付録Aで定義されています。
Multicast Names and Multicast Addresses used in this API are represented by a URI scheme that is specified in the following subsections. A corresponding ham-URI denotes a multicast channel and may be dereferenced to retrieve data published to that channel.
このAPIで使用されるマルチキャスト名とマルチキャストアドレスは、次のサブセクションで指定されるURIスキームで表されます。対応するham-URIはマルチキャストチャネルを示し、そのチャネルにパブリッシュされたデータを取得するために逆参照される場合があります。
The syntax of the multicast URI is specified using the Augmented Backus-Naur Form (ABNF) [RFC5234] and is defined as follows:
マルチキャストURIの構文は、拡張バッカスナウアフォーム（ABNF）[RFC5234]を使用して指定され、次のように定義されます。
ham-URI = ham-scheme ":" namespace ":" group [ "@" instantiation ]
[ ":" port ] [ "/" sec-credentials ]
ham-scheme = "ham" ; hybrid adaptive multicast
namespace = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
group = "*" / 1*unreserved ; unreserved per [RFC3986]
instantiation = 1*unreserved ; unreserved per [RFC3986]
port = 1*DIGIT
sec-credentials = alg ";" val
alg = 1*unreserved ; unreserved per [RFC3986]
val = 1*unreserved ; unreserved per [RFC3986]
Percent-encoding is applied to distinguish between reserved and
unreserved assignments of the same character in the same ham-URI
component (cf. [RFC3986]).
The semantic of the different parts of the URI is defined as follows:
URIのさまざまな部分の意味は、次のように定義されます。
ham-scheme: refers to the specification of the assigned identifier "ham".
ham-scheme：割り当てられた識別子「ham」の仕様を指します。
namespace: takes the role of the Multicast Namespace. It defines the syntax of the group and instantiation part of the ham-URI. A basic syntax for these elements is specified in Section 4.2.1. The namespace may further restrict the syntax of designators. Example namespaces are described in Sections 4.2.3 and 4.2.4.
名前空間：マルチキャスト名前空間の役割を果たします。グループの構文とham-URIのインスタンス化部分を定義します。これらの要素の基本的な構文は、セクション4.2.1で指定されています。名前空間は、指定子の構文をさらに制限する場合があります。名前空間の例については、セクション4.2.3および4.2.4で説明しています。
group: uniquely identifies the group within the Multicast Namespace given in the namespace. The literal "*" represents all members of the Multicast Group.
group：名前空間で指定されたマルチキャスト名前空間内のグループを一意に識別します。リテラル「*」は、マルチキャストグループのすべてのメンバーを表します。
instantiation: identifies the entity that generates the instance of the group (e.g., a SIP domain or a source in SSM, a dedicated routing entity, or a named processor that accounts for the group communication), using syntax and semantics as defined by the namespace. This parameter is optional. Note that ambiguities (e.g., identical node addresses in multiple overlay instances) can be distinguished by ports.
インスタンス化：名前空間で定義されている構文とセマンティクスを使用して、グループのインスタンスを生成するエンティティ（SIPドメインまたはSSMのソース、専用ルーティングエンティティ、またはグループ通信を説明する名前付きプロセッサなど）を識別します。 。このパラメーターはオプションです。あいまいさ（複数のオーバーレイインスタンスでの同一ノードアドレスなど）はポートで区別できることに注意してください。
port: identifies a specific application at an instance of a group. This parameter is optional.
ポート：グループのインスタンスで特定のアプリケーションを識別します。このパラメーターはオプションです。
sec-credentials: used to implement security mechanisms (e.g., to authorize Multicast Group access or authenticate multicast operations). This parameter is optional. "alg" represents the security algorithm in use. "val" represents the actual value for Authentication, Authorization, and Accounting (AAA). Note that security credentials may carry a distinct technical meaning w.r.t. AAA schemes and may differ between group members. Hence, the sec-credentials are not considered part of the Group Name.
sec-credentials：セキュリティメカニズムを実装するために使用されます（たとえば、マルチキャストグループアクセスを承認したり、マルチキャスト操作を認証したりするため）。このパラメーターはオプションです。 「alg」は、使用中のセキュリティアルゴリズムを表します。 「val」は、Authentication、Authorization、およびAccounting（AAA）の実際の値を表します。セキュリティ認証情報には、明確な技術的意味がある場合があることに注意してください。 AAAスキームおよびグループメンバー間で異なる場合があります。したがって、sec-credentialsはグループ名の一部とは見なされません。
IP: This namespace is comprised of regular IP node naming, i.e., DNS names and addresses taken from any version of the Internet Protocol. The syntax of the group and instantiation follows the "host" definition in [RFC3986], Section 3.2.2. A processor dealing with the IP namespace is required to determine the syntax (DNS name, IP address, version) of the group and instantiation expression.
IP：この名前空間は、通常のIPノードの名前、つまり、任意のバージョンのインターネットプロトコルから取得したDNS名とアドレスで構成されます。グループとインスタンス化の構文は、[RFC3986]のセクション3.2.2の「ホスト」の定義に従います。グループとインスタンス化式の構文（DNS名、IPアドレス、バージョン）を決定するには、IP名前空間を処理するプロセッサーが必要です。
SHA-2: This namespace carries address strings compliant with SHA-2 hash digests. The syntax of the group and instantiation follows the "val" definition in [RFC6920], Section 3. A processor handling those strings is required to determine the length of the expressions and passes appropriate values directly to a corresponding overlay.
SHA-2：この名前空間は、SHA-2ハッシュダイジェストに準拠したアドレス文字列を伝達します。グループとインスタンス化の構文は、[RFC6920]、セクション3の「val」の定義に従います。式の長さを決定し、適切な値を対応するオーバーレイに直接渡すには、これらの文字列を処理するプロセッサが必要です。
Opaque: This namespace transparently carries strings without further syntactical information, meanings, or associated resolution mechanisms. The corresponding syntax for the group and instantiation part of the ham-URI is defined in Section 4.2.1.
不透明：この名前空間は、それ以上の構文情報、意味、または関連する解決メカニズムのない文字列を透過的に伝達します。 ham-URIのグループ化およびインスタンス化部分に対応する構文は、セクション4.2.1で定義されています。
SIP: The SIP namespace is an example of an application-layer scheme that bears inherent group functions (conferencing). SIP conference URIs may be directly exchanged and interpreted at the application, and mapped to Group Addresses at the system level to generate a corresponding Multicast Group. The syntax of the group and instantiation is represented by the "userinfo" component [RFC3261], Section 25.1.
SIP：SIP名前空間は、固有のグループ機能（会議）を担うアプリケーション層スキームの例です。 SIP会議URIは、アプリケーションで直接交換および解釈され、システムレベルでグループアドレスにマッピングされて、対応するマルチキャストグループを生成します。グループとインスタンス化の構文は、「userinfo」コンポーネント[RFC3261]、セクション25.1。で表されます。
RELOAD: This namespace covers address strings that are valid in a REsource LOcation And Discovery [RELOAD] overlay network. A processor handling those strings may pass these values directly to a corresponding overlay that may manage multicast distribution according to [RFC7019].
RELOAD：この名前空間は、REsource LOcation And Discovery [RELOAD]オーバーレイネットワークで有効なアドレス文字列をカバーします。これらの文字列を処理するプロセッサは、[RFC7019]に従ってマルチキャスト配信を管理できる対応するオーバーレイにこれらの値を直接渡すことができます。
The concept of the common multicast API allows for any namespace that complies with the superset syntax defined in Section 4.2.1. This document specifies a basic set of Multicast Namespaces in Sections 4.2.3 and 4.2.4. If additional namespaces are needed in the future, a registry for those namespaces should be created and should be defined in a future document. All namespaces defined in such a document should then also be assigned to the registry.
共通のマルチキャストAPIの概念により、セクション4.2.1で定義されたスーパーセット構文に準拠する名前空間が許可されます。このドキュメントでは、セクション4.2.3および4.2.4でマルチキャスト名前空間の基本セットを指定しています。将来的に追加の名前空間が必要になった場合は、それらの名前空間のレジストリを作成し、将来のドキュメントで定義する必要があります。このようなドキュメントで定義されているすべての名前空間もレジストリに割り当てる必要があります。
The Interface denotes the layer and instance on which the corresponding call takes effect. In agreement with [RFC3493], we identify an Interface by an identifier, which is a positive integer starting at 1.
インターフェイスは、対応する呼び出しが有効になるレイヤーとインスタンスを示します。 [RFC3493]と一致して、インターフェイスを識別子で識別します。識別子は1から始まる正の整数です。
Properties of an Interface are stored in the following data structure:
インターフェイスのプロパティは、次のデータ構造に格納されています。
struct ifProp {
UnsignedInt if_index; /* 1, 2, ... */
String *ifName; /* "eth0", "eth1:1", "lo", ... */
String *ifAddr; /* "1.2.3.4", "abc123", ... */
String *ifTech; /* "ip", "overlay", ... */
};
The following function retrieves all available Interfaces from the system:
次の関数は、システムからすべての使用可能なインターフェースを取得します。
getInterfaces(out Interface <ifs>);
It extends the functions for Interface identification as defined in [RFC3493], Section 4 and can be implemented by:
[RFC3493]のセクション4で定義されているインターフェース識別の機能を拡張し、次の方法で実装できます。
struct ifProp(out IfProp <ifsProps>);
A membership event is triggered by a multicast state change that is observed by the current node. It is related to a specific Group Name and may be receiver or source oriented.
メンバーシップイベントは、現在のノードによって監視されるマルチキャスト状態の変化によってトリガーされます。これは特定のグループ名に関連しており、受信者指向またはソース指向の場合があります。
eventType {
joinEvent;
leaveEvent;
newSourceEvent;
};
event {
EventType event;
Uri groupName;
Interface if;
};
An event will be created by the group communication stack and passed to applications that have registered for events.
イベントは、グループ通信スタックによって作成され、イベントに登録されているアプリケーションに渡されます。
The create call initiates a multicast socket and provides the application programmer with a corresponding handle. If no Interfaces will be assigned based on the call, the default Interface will be selected and associated with the socket. The call returns an error code in the case of failures, e.g., due to non-operational communication middleware.
create呼び出しは、マルチキャストソケットを開始し、アプリケーションプログラマーに対応するハンドルを提供します。呼び出しに基づいてインターフェースが割り当てられない場合、デフォルトのインターフェースが選択され、ソケットに関連付けられます。動作していない通信ミドルウェアなどが原因で障害が発生した場合、呼び出しはエラーコードを返します。
createMSocket(in Interface <ifs>,
out Socket s);
The ifs argument denotes a list of Interfaces (if_indexes) that will be associated with the multicast socket. This parameter is optional.
ifs引数は、マルチキャストソケットに関連付けられるインターフェース（if_indexes）のリストを示します。このパラメーターはオプションです。
On success, a multicast socket identifier is returned; otherwise, it is NULL.
成功すると、マルチキャストソケット識別子が返されます。それ以外の場合はNULLです。
The delete call removes the multicast socket.
delete呼び出しは、マルチキャストソケットを削除します。
deleteMSocket(in Socket s, out Int error);
deleteMSocket（ソケットs、アウトIntエラー）;
The s argument identifies the multicast socket for destruction.
s引数は、破棄するマルチキャストソケットを識別します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The join call initiates a subscription for the given Group Name. Depending on the Interfaces that are associated with the socket, this may result in an IGMP / Multicast Listener Discovery (MLD) report or overlay subscription, for example.
参加呼び出しは、指定されたグループ名のサブスクリプションを開始します。ソケットに関連付けられているインターフェースによっては、これにより、たとえばIGMP /マルチキャストリスナーディスカバリ（MLD）レポートまたはオーバーレイサブスクリプションが発生する場合があります。
join(in Socket s, in Uri groupName, out Int error);
join（Socket s、Uri groupName、out Intエラー）;
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The groupName argument identifies the group.
groupName引数はグループを識別します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The leave call results in an unsubscription for the given Group Name.
Leaveコールは、指定されたグループ名のサブスクリプションを解除します。
leave(in Socket s, in Uri groupName, out Int error);
leave（Socket s、Uri groupName、out Intエラー）;
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The groupName argument identifies the group.
groupName引数はグループを識別します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The srcRegister call registers a source for a group on all active Interfaces of the socket s. This call may assist group distribution in some technologies -- for example, the creation of sub-overlays -- or may facilitate a name-to-address mapping. Likewise, it may remain without effect in some multicast technologies.
srcRegister呼び出しは、ソケットsのすべてのアクティブなインターフェース上のグループのソースを登録します。この呼び出しは、一部のテクノロジー（たとえば、サブオーバーレイの作成）でのグループ配布を支援するか、または名前からアドレスへのマッピングを容易にします。同様に、一部のマルチキャストテクノロジーでは影響なしに残る場合があります。
srcRegister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The groupName argument identifies the Multicast Group to which a source intends to send data.
groupName引数は、ソースがデータを送信する予定のマルチキャストグループを識別します。
The ifs argument points to the list of Interface indexes for which the source registration failed. A NULL pointer is returned if the list is empty. This parameter is optional.
ifs引数は、ソース登録が失敗したインターフェイスインデックスのリストを指します。リストが空の場合、NULLポインタが返されます。このパラメーターはオプションです。
If source registration succeeded for all Interfaces associated with the socket, the out parameter error is 0; otherwise, -1 is returned.
ソケットに関連付けられたすべてのインターフェイスのソース登録が成功した場合、出力パラメーターエラーは0です。それ以外の場合は、-1が返されます。
The srcDeregister call indicates that a source no longer intends to send data to the Multicast Group. This call may remain without effect in some multicast technologies.
srcDeregister呼び出しは、ソースがマルチキャストグループにデータを送信する必要がなくなったことを示します。このコールは、一部のマルチキャストテクノロジーでは影響なしに残る場合があります。
srcDeregister(in Socket s, in Uri groupName,
out Interface <ifs>, out Int error);
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The groupName argument identifies the Multicast Group to which a source has stopped sending multicast data.
groupName引数は、ソースがマルチキャストデータの送信を停止したマルチキャストグループを識別します。
The ifs argument points to the list of Interfaces for which the source deregistration failed. A NULL pointer is returned if the list is empty.
ifs引数は、ソースの登録解除が失敗したインターフェースのリストを指します。リストが空の場合、NULLポインタが返されます。
If source deregistration succeeded for all Interfaces associated with the socket, the out parameter error is 0; otherwise, -1 is returned.
ソケットに関連付けられたすべてのインターフェイスのソース登録解除が成功した場合、出力パラメーターエラーは0です。それ以外の場合は、-1が返されます。
The send call passes multicast data destined for a Multicast Name from the application to the multicast socket.
送信呼び出しは、アプリケーションからマルチキャストソケットにマルチキャスト名宛てのマルチキャストデータを渡します。
It is worth noting that it is the choice of the programmer to send data via one socket per group or to use a single socket for multiple groups.
グループごとに1つのソケットを介してデータを送信するか、複数のグループに1つのソケットを使用するかは、プログラマーの選択であることは注目に値します。
send(in Socket s, in Uri groupName, in Size msgLen, in Msg msgBuf, out Int error);
send（ソケットs、URIグループ名、サイズmsgLen、メッセージmsgBuf、out Intエラー）;
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The groupName argument identifies the group to which data will be sent.
groupName引数は、データの送信先のグループを識別します。
The msgLen argument holds the length of the message to be sent.
msgLen引数は、送信されるメッセージの長さを保持します。
The msgBuf argument passes the multicast data to the multicast socket.
msgBuf引数は、マルチキャストデータをマルチキャストソケットに渡します。
On success, the out parameter error is 0; otherwise, -1 is returned. A message that is too long is indicated by an implementation-specific error code (e.g., EMSGSIZE in C).
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。長すぎるメッセージは、実装固有のエラーコード（CのEMSGSIZEなど）で示されます。
The receive call passes multicast data and the corresponding Group Name to the application. This may come in a blocking or non-blocking variant.
受信呼び出しは、マルチキャストデータと対応するグループ名をアプリケーションに渡します。これには、ブロッキングまたは非ブロッキングのバリエーションがあります。
It is worth noting that it is the choice of the programmer to receive data via one socket per group or to use a single socket for multiple groups.
グループごとに1つのソケットを介してデータを受信するか、複数のグループに1つのソケットを使用するかはプログラマーの選択であることは注目に値します。
receive(in Socket s, out Uri groupName, out Size msgLen, out Msg msgBuf, out Int error);
receive（ソケットs、out Uri groupName、outサイズmsgLen、out Msg msgBuf、out Intエラー）;
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The groupName argument identifies the Multicast Group for which data was received.
groupName引数は、データが受信されたマルチキャストグループを識別します。
The msgLen argument holds the length of the received message.
msgLen引数は、受信したメッセージの長さを保持します。
The msgBuf argument points to the payload of the received multicast data.
msgBuf引数は、受信したマルチキャストデータのペイロードを指します。
On success, the out parameter error is 0; otherwise, -1 is returned. A message that is too long is indicated by an implementation-specific error code (e.g., EMSGSIZE).
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。長すぎるメッセージは、実装固有のエラーコード（EMSGSIZEなど）で示されます。
The following calls configure an existing multicast socket.
次の呼び出しは、既存のマルチキャストソケットを構成します。
The getInterfaces call returns an array of all available multicast communication Interfaces associated with the multicast socket.
getInterfaces呼び出しは、マルチキャストソケットに関連付けられているすべての利用可能なマルチキャスト通信インターフェースの配列を返します。
getInterfaces(in Socket s,
out Interface <ifs>, out Int error);
The s argument identifies the multicast socket.
s引数は、マルチキャストソケットを識別します。
The ifs argument points to an array of Interface index identifiers.
ifs引数は、インターフェイスインデックス識別子の配列を指します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The addInterface call adds a distribution channel to the socket. This may be an overlay or underlay Interface, e.g., IPv6 or Distributed Hash Table (DHT). Multiple Interfaces of the same technology may be associated with the socket.
addInterface呼び出しは、ソケットに配布チャネルを追加します。これは、オーバーレイまたはアンダーレイインターフェース（IPv6や分散ハッシュテーブル（DHT）など）の場合があります。同じテクノロジーの複数のインターフェースをソケットに関連付けることができます。
addInterface(in Socket s, in Interface if, out Int error);
addInterface（ソケットs、インターフェイスif、out Intエラー）;
The s and if arguments identify a multicast socket and Interface, respectively.
sおよびif引数は、それぞれマルチキャストソケットおよびインターフェイスを識別します。
On success, the value 0 is returned; otherwise, -1 is returned.
成功すると、値0が返されます。それ以外の場合は、-1が返されます。
The delInterface call removes the Interface from the multicast socket.
delInterface呼び出しは、マルチキャストソケットからインターフェイスを削除します。
delInterface(in Socket s, Interface if, out Int error);
delInterface（ソケットs、インターフェイスif、out Intエラー）;
The s and if arguments identify a multicast socket and Interface, respectively.
sおよびif引数は、それぞれマルチキャストソケットおよびインターフェイスを識別します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The setTTL call configures the maximum hop count for the socket that a multicast message is allowed to traverse.
setTTL呼び出しは、マルチキャストメッセージが通過できるソケットの最大ホップカウントを構成します。
setTTL(in Socket s, in Int h, in Interface <ifs>, out Int error);
setTTL（ソケットs、Int h、インターフェイス<ifs>、out Intエラー）;
The s and h arguments identify a multicast socket and the maximum hop count, respectively.
s引数とh引数は、それぞれマルチキャストソケットと最大ホップカウントを識別します。
The ifs argument points to an array of Interface index identifiers. This parameter is optional.
ifs引数は、インターフェイスインデックス識別子の配列を指します。このパラメーターはオプションです。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The getTTL call returns the maximum hop count that a multicast message is allowed to traverse for the interface bound to the socket.
getTTL呼び出しは、マルチキャストメッセージがソケットにバインドされたインターフェースを通過できる最大ホップカウントを返します。
getTTL(in Socket s, in Interface if, out Int h, out Int error);
getTTL（ソケットs、インターフェイスの場合、out Int h、out Intエラー）;
The s argument identifies a multicast socket.
s引数は、マルチキャストソケットを識別します。
The if argument identifies an interface that is bound to socket s.
if引数は、ソケットsにバインドされているインターフェースを識別します。
The h argument holds the maximum number of hops associated with the interface.
h引数は、インターフェイスに関連付けられた最大ホップ数を保持します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The getAtomicMsgSize function returns the maximum message size that an application is allowed to transmit per socket at once without fragmentation. This value depends on the Interfaces associated with the socket in use and thus may change during runtime.
getAtomicMsgSize関数は、断片化せずにアプリケーションがソケットごとに一度に送信できる最大メッセージサイズを返します。この値は、使用中のソケットに関連付けられているインターフェイスに依存するため、実行時に変更される可能性があります。
getAtomicMsgSize(in Socket s, out Int return);
getAtomicMsgSize（Socket s、out Int return）;
On success, the function returns a positive value of appropriate message size; otherwise, -1 is returned.
成功すると、関数は適切なメッセージサイズの正の値を返します。それ以外の場合は、-1が返されます。
The groupSet call returns all Multicast Groups registered at a given Interface. This information can be provided by group management states or routing protocols. The return values distinguish between sender and listener states.
groupSet呼び出しは、特定のインターフェイスに登録されているすべてのマルチキャストグループを返します。この情報は、グループ管理状態またはルーティングプロトコルによって提供できます。戻り値は、送信者とリスナーの状態を区別します。
struct GroupSet {
Uri groupName; /* registered Multicast Group */
Int type; /* 0 = listener state, 1 = sender state,
2 = sender and listener state */
}
groupSet(in Interface if,
out GroupSet <groupSet>, out Int error);
The if argument identifies the Interface for which states are maintained.
if引数は、状態が維持されるインターフェイスを識別します。
The groupSet argument points to a list of group states.
groupSet引数は、グループ状態のリストを指します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The neighborSet function returns the set of neighboring nodes for a given Interface as seen by the multicast routing protocol.
neighborSet関数は、マルチキャストルーティングプロトコルから見た、特定のインターフェイスの隣接ノードのセットを返します。
neighborSet(in Interface if,
out Uri <neighborsAddresses>, out Int error);
The if argument identifies the Interface for which information regarding neighbors is requested.
if引数は、ネイバーに関する情報が要求されるインターフェイスを識別します。
The neighborsAddresses argument points to a list of neighboring nodes on a successful return.
neighborsAddresses引数は、正常終了時に隣接ノードのリストを指します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The childrenSet function returns the set of child nodes that receive multicast data from a specified Interface for a given group. For a common multicast router, this call retrieves the multicast forwarding information base per Interface.
childrenSet関数は、指定されたグループの指定されたインターフェイスからマルチキャストデータを受信する子ノードのセットを返します。一般的なマルチキャストルーターの場合、この呼び出しは、インターフェイスごとにマルチキャスト転送情報ベースを取得します。
childrenSet(in Interface if, in Uri groupName,
out Uri <childrenAddresses>, out Int error);
The if argument identifies the Interface for which information regarding children is requested.
if引数は、子に関する情報が要求されるインターフェースを識別します。
The groupName argument defines the Multicast Group for which distribution is considered.
groupName引数は、配信が考慮されるマルチキャストグループを定義します。
The childrenAddresses argument points to a list of neighboring nodes on a successful return.
childrenAddresses引数は、正常終了時に隣接ノードのリストを指します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The parentSet function returns the set of neighbors from which the current node receives multicast data at a given Interface for the specified group.
parentSet関数は、現在のノードが指定されたグループの特定のインターフェイスでマルチキャストデータを受信する近隣のセットを返します。
parentSet(in Interface if, in Uri groupName,
out Uri <parentsAddresses>, out Int error);
The if argument identifies the Interface for which information regarding parents is requested.
if引数は、親に関する情報が要求されるインターフェースを識別します。
The groupName argument defines the Multicast Group for which distribution is considered.
groupName引数は、配信が考慮されるマルチキャストグループを定義します。
The parentsAddresses argument points to a list of neighboring nodes on a successful return.
parentsAddresses引数は、正常に戻ると、隣接ノードのリストを指します。
On success, the out parameter error is 0; otherwise, -1 is returned.
成功した場合、出力パラメータエラーは0です。それ以外の場合は、-1が返されます。
The designatedHost function inquires about whether this host has the role of a designated forwarder (or querier), or not. Such information is provided by almost all multicast protocols to prevent packet duplication, if multiple multicast instances provide service on the same subnet.
指定ホスト関数は、このホストが指定フォワーダー（またはクエリア）の役割を持っているかどうかを問い合わせます。複数のマルチキャストインスタンスが同じサブネット上でサービスを提供する場合、パケットの重複を防ぐために、このような情報はほとんどすべてのマルチキャストプロトコルによって提供されます。
designatedHost(in Interface if, in Uri groupName out Int return);
specifiedHost（inインターフェースの場合、URIでgroupName out Int return）;
The if argument identifies the Interface for which information regarding designated forwarding is requested.
if引数は、指定された転送に関する情報が要求されるインターフェイスを識別します。
The groupName argument specifies the group for which the host may attain the role of designated forwarder.
groupName引数は、ホストが指定されたフォワーダの役割を果たし得るグループを指定します。
The function returns 1 if the host is a designated forwarder or querier. The return value -1 indicates an error. Otherwise, 0 is returned.
ホストが指定されたフォワーダーまたはクエリアである場合、関数は1を返します。戻り値-1はエラーを示します。それ以外の場合は、0が返されます。
The enableEvents function registers an application at the group communication stack to receive information about group changes. State changes are the result of new receiver subscriptions or leaves, as well as source changes. Upon receiving an event, the group service may obtain additional information from further service calls.
enableEvents関数は、グループ通信スタックにアプリケーションを登録して、グループの変更に関する情報を受け取ります。状態の変化は、ソースの変更だけでなく、新しいレシーバーのサブスクリプションまたはリーフの結果です。イベントを受信すると、グループサービスは追加のサービス呼び出しから追加情報を取得できます。
enableEvents();
enableEvents();
Calling this function, the stack starts to pass membership events to the application. Each event includes an event type identifier and a Group Name (cf. Section 4.3.2).
この関数を呼び出すと、スタックはメンバーシップイベントをアプリケーションに渡し始めます。各イベントには、イベントタイプ識別子とグループ名が含まれます（セクション4.3.2を参照）。
The multicast protocol does not have to support membership tracking in order to enable this feature. This function can also be implemented at the middleware layer.
この機能を有効にするために、マルチキャストプロトコルがメンバーシップ追跡をサポートする必要はありません。この機能は、ミドルウェア層で実装することもできます。
The disableEvents function deactivates the information about group state changes.
disableEvents関数は、グループの状態変更に関する情報を非アクティブ化します。
disableEvents();
disableEvents();
On success, the stack will not pass membership events to the application.
成功した場合、スタックはメンバーシップイベントをアプリケーションに渡しません。
The getMaxMsgSize function returns the maximum message size that an application is allowed to transmit per socket at once. This value is statically guaranteed by the group communication stack.
getMaxMsgSize関数は、アプリケーションがソケットごとに一度に送信できる最大メッセージサイズを返します。この値は、グループ通信スタックによって静的に保証されています。
getMaxMsgSize(out Int return);
getMaxMsgSize（out Int return）;
On success, the function returns a positive value of allowed message size; otherwise, -1 is returned.
成功すると、関数は許可されたメッセージサイズの正の値を返します。それ以外の場合は、-1が返されます。
A reference implementation of the Common API for Transparent Hybrid Multicast is available with the HAMcast stack [HAMcast-DEV] [GC2010] [LCN2012]. This open-source software supports the multicast API (C++ and Java library) for group application development, the middleware as a user space system service, and several multicast-technology modules. The middleware is implemented in C++.
透過ハイブリッドマルチキャストの共通APIのリファレンス実装は、HAMcastスタック[HAMcast-DEV] [GC2010] [LCN2012]で利用できます。このオープンソースソフトウェアは、グループアプリケーション開発用のマルチキャストAPI（C ++およびJavaライブラリ）、ユーザー空間システムサービスとしてのミドルウェア、およびいくつかのマルチキャストテクノロジーモジュールをサポートしています。ミドルウェアはC ++で実装されています。
This API is verified and adjusted based on the real-world experiences gathered in the HAMcast project, and by additional users of the stack.
このAPIは、HAMcastプロジェクトで収集された実際の経験に基づいて、およびスタックの追加ユーザーによって検証および調整されます。
This document specifies the "ham" URI scheme that has been registered by IANA as one of the "Provisional URI Schemes" according to [RFC4395].
このドキュメントは、[RFC4395]に従って「暫定URIスキーム」の1つとしてIANAによって登録された「ハム」URIスキームを指定します。
URI scheme name ham
URIスキーム名ham
Status provisional
暫定ステータス
URI scheme syntax See Section 4.2.1.
URIスキームの構文4.2.1項を参照してください。
URI scheme semantics See Section 4.2.2.
URIスキームのセマンティクスセクション4.2.2を参照してください。
Encoding See Section 4.2.1 considerations
エンコーディングセクション4.2.1の考慮事項を参照
Applications/protocols The scheme is used by multicast applications that use this URI to access multicast content. scheme name
アプリケーション/プロトコルこのスキームは、このURIを使用してマルチキャストコンテンツにアクセスするマルチキャストアプリケーションによって使用されます。スキーム名
Interoperability None considerations
相互運用性なし考慮事項
Security See Section 7. considerations
セキュリティセクション7を参照してください。
Contact Matthias Waehlisch, mw@link-lab.net
Matthias Waehlisch、mw @ link-lab.netにお問い合わせください
Author/Change IRTF controller
IRTFコントローラーの作成/変更
References As specified in this document.
このドキュメントで指定されているとおり。
This document does not introduce additional messages or novel protocol operations.
このドキュメントでは、追加のメッセージや斬新なプロトコル操作を紹介していません。
We would like to thank the HAMcast team at the HAW Hamburg -- Nora Berg, Gabriel Hege, Fabian Holler, Alexander Knauf, Sebastian Meiling, Sebastian Woelke, and Sebastian Zagaria -- for many fruitful discussions and for their continuous critical feedback while implementing the common multicast API and hybrid multicast middleware. Special thanks to Dominik Charousset of the HAMcast team for in-depth perspectives on the matter of code. We gratefully acknowledge WeeSan, Mario Kolberg, and John Buford for reviewing and their suggestions to improve the document. We would like to thank the Name-Based Socket BoF (in particular Dave Thaler) for clarifying insights into the question of meta-function calls. We thank Lisandro Zambenedetti Granville and Tony Li for very careful reviews of the pre-final versions of this document. Barry Leiba and Graham Klyne provided very constructive input to find a suitable URI scheme. They are gratefully acknowledged.
HAWハンブルクのHAMcastチーム-ノラバーグ、ガブリエルヘーゲ、ファビアンホラー、アレクサンダークナウフ、セバスチャンメイリング、セバスチャンウォルケ、セバスチャンザガリア-に多くの実りある議論と、一般的なマルチキャストAPIとハイブリッドマルチキャストミドルウェア。 HAMcastチームのDominik Charousset氏に、コードの問題について詳細な視点を提供していただき、ありがとうございます。ドキュメントを改善するためのレビューと提案について、WeeSan、Mario Kolberg、およびJohn Bufordに感謝します。メタ関数呼び出しの問題に対する洞察を明確にしてくれた名前ベースのソケットBoF（特にDave Thaler）に感謝します。このドキュメントの最終版より前のバージョンを非常に慎重にレビューしてくれたLisandro Zambenedetti GranvilleとTony Liに感謝します。 Barry LeibaとGraham Klyneは、適切なURIスキームを見つけるために非常に建設的な入力を提供しました。彼らは感謝して認められています。
This work is partially supported by the German Federal Ministry of Education and Research within the HAMcast project (see <http://hamcast.realmv6.org>), which is part of G-Lab.
この作業は、G-Labの一部であるHAMcastプロジェクト（<http://hamcast.realmv6.org>を参照）内のドイツ連邦教育研究省によって部分的にサポートされています。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075] Waitzman、D.、Partridge、C。、およびS. Deering、「Distance Vector Multicast Routing Protocol」、RFC 1075、1988年11月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、1999年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J.、and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 3493、2003年2月。
[RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", RFC 3678, January 2004.
[RFC3678] Thaler、D.、Fenner、B。、およびB. Quinn、「マルチキャストソースフィルターのソケットインターフェイス拡張」、RFC 3678、2004年1月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「Multicast Listener Discovery Version 2（MLDv2）for IPv6」、RFC 3810、2004年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T。、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 35、RFC 4395、2006年2月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H。、およびI. Kouvelas、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：Protocol Specification（Revised）」、RFC 4601、2006年8月。
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
[RFC4604] Holbrook、H.、Cain、B。、およびB. Haberman、「インターネットグループ管理プロトコルバージョン3（IGMPv3）およびソース固有のマルチキャスト用のマルチキャストリスナー検出プロトコルバージョン2（MLDv2）の使用」、RFC 4604、8月2006年
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015] Handley、M.、Kouvelas、I.、Speakman、T。、およびL. Vicisano、「Bidirectional Protocol Independent Multicast（BIDIR-PIM）」、RFC 5015、2007年10月。
[RFC5058] Boivie, R., Feldman, N., Imai, Y., Livens, W., and D. Ooms, "Explicit Multicast (Xcast) Concepts and Options", RFC 5058, November 2007.
[RFC5058] Boivie、R.、Feldman、N.、Imai、Y.、Livens、W。、およびD. Ooms、「Explicit Multicast（Xcast）Concepts and Options」、RFC 5058、2007年11月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, April 2013.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、2013年4月。
[AMT] Bumgardner, G., "Automatic Multicast Tunneling", Work in Progress, October 2013.
[AMT] Bumgardner、G。、「Automatic Multicast Tunneling」、Work in Progress、2013年10月。
[GC2010] Meiling, S., Charousset, D., Schmidt, T., and M. Waehlisch, "System-assisted Service Evolution for a Future Internet - The HAMcast Approach to Pervasive Multicast", Proc. IEEE GLOBECOM 2010 Workshops, MCS 2010, pp. 913-917, Piscataway, NJ, USA, IEEE Press, December 2010.
[GC2010] Meiling、S.、Charousset、D.、Schmidt、T。、およびM. Waehlisch、「将来のインターネットのためのシステム支援サービスの進化-普及型マルチキャストへのHAMcastアプローチ」、Proc。 IEEE GLOBECOM 2010 Workshops、MCS 2010、pp。913-917、Piscataway、NJ、USA、IEEE Press、December 2010。
[HAMcast-DEV] "HAMcast developers", <http://hamcast.realmv6.org/developers>.
[HAMcast-DEV]「HAMcast開発者」、<http://hamcast.realmv6.org/developers>。
[LCN2012] Meiling, S., Schmidt, T., and M. Waehlisch, "Large-Scale Measurement and Analysis of One-Way Delay in Hybrid Multicast Networks", Proc. 37th Annual IEEE Conference on Local Computer Networks (LCN 2012), Piscataway, NJ, USA, IEEE Press, October 2012.
[LCN2012] Meiling、S.、Schmidt、T。、およびM. Waehlisch、「ハイブリッドマルチキャストネットワークにおける一方向遅延の大規模測定と分析」、Proc。第37回ローカルコンピュータネットワークに関するIEEEカンファレンス（LCN 2012）、米国ニュージャージー州ピスカタウェイ、IEEEプレス、2012年10月。
[MCAST-v4v6] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", Work in Progress, December 2010.
[MCAST-v4v6] Venaas、S.、Asaeda、H.、SUZUKI、S.、and T. Fujisaki、 "An IPv4-IPv6 multicast translation"、Work in Progress、2010年12月。
[MCAST-v4v6-FRAMEWORK] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
[MCAST-v4v6-FRAMEWORK] Venaas、S.、Li、X.、C。Bao、「Framework for IPv4 / IPv6 Multicast Translation」、Work in Progress、2011年6月。
[RELOAD] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", Work in Progress, February 2013.
[RELOAD] Jennings、C.、Lowekamp、B.、Ed。、Rescorla、E.、Baset、S。、およびH. Schulzrinne、「REsource LOcation And Discovery（RELOAD）Base Protocol」、Work in Progress、2013年2月。
[RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey", RFC 5757, February 2010.
[RFC5757] Schmidt、T.、Waehlisch、M。、およびG. Fairhurst、「Mobile IP Version 6（MIPv6）：Multicast Mobility in Mobile IP Version 6（MIPv6）：Problem Statement and Brief Survey」、RFC 5757、2010年2月。
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, May 2011.
[RFC6219] Li、X.、Bao、C.、Chen、M.、Zhang、H。、およびJ. Wu、「IPv4 / IPv6共存のための中国教育研究ネットワーク（CERNET）IVI変換設計および導入移行」、RFC 6219、2011年5月。
[RFC7019] Buford, J. and M. Kolberg, "Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)", RFC 7019, September 2013.
[RFC7019] Buford、J。およびM. Kolberg、「LOcation And Discovery（RELOAD）を再ソースするためのアプリケーション層マルチキャスト拡張機能」、RFC 7019、2013年9月。
[SIP-RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for RELOAD", Work in Progress, July 2013.
[SIP-RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., Schulzrinne, H., and T. Schmidt, Ed., "A SIP Usage for RELOAD", Work in Progress, July 2013.
This section describes the C signatures of the common multicast API (Section 4).
このセクションでは、一般的なマルチキャストAPIのCシグネチャについて説明します（セクション4）。
int createMSocket(int* result, size_t num_ifs,
const uint32_t* ifs);
int deleteMSocket(int s);
int deleteMSocket（int s）;
int join(int msock, const char* group_uri);
int leave(int msock, const char* group_uri);
int srcRegister(int msock, const char* group_uri, size_t num_ifs, uint32_t* ifs);
int srcRegister（int msock、const char * group_uri、size_t num_ifs、uint32_t * ifs）;
int srcDeregister(int msock, const char* group_uri, size_t num_ifs, uint32_t* ifs);
int srcDeregister（int msock、const char * group_uri、size_t num_ifs、uint32_t * ifs）;
int send(int msock, const char* group_uri, size_t buf_len, const void* buf);
int send（int msock、const char * group_uri、size_t buf_len、const void * buf）;
int receive(int msock, const char* group_uri, size_t buf_len, void* buf);
int receive（int msock、const char * group_uri、size_t buf_len、void * buf）;
int getInterfaces(int msock,
size_t* num_ifs,
uint32_t** ifs);
int addInterface(int msock, uint32_t iface);
int addInterface（int msock、uint32_t iface）;
int delInterface(int msock, uint32_t iface);
int delInterface(int msock, uint32_t iface);
int setTTL(int msock, uint8_t value, size_t num_ifs, uint32_t* ifs);
int setTTL（int msock、uint8_t value、size_t num_ifs、uint32_t * ifs）;
int getTTL(int msock, uint8_t* result);
int getAtomicMsgSize(int msock);
int getAtomicMsgSize（int msock）;
typedef struct {
char* group_uri; /* registered mcast group */
int type; /* 0: listener state
1: sender state
2: sender and listener state */
}
GroupSet;
int groupSet(uint32_t iface,
size_t* num_groups,
GroupSet** groups);
int neighborSet(uint32_t iface,
const char* group_name,
size_t* num_neighbors,
char** neighbor_uris);
int childrenSet(uint32_t iface,
const char* group_name,
size_t* num_children,
char** children_uris);
int parentSet(uint32_t iface,
const char* group_name,
size_t* num_parents,
char** parents_uris);
int designatedHost(uint32_t iface, const char* group_name);
int specifiedHost（uint32_t iface、const char * group_name）;
typedef void (*MembershipEventCallback)
(int, /* event type */
uint32_t, /* Interface id */
const char*); /* group uri */
int registerEventCallback(MembershipEventCallback callback);
int registerEventCallback(MembershipEventCallback callback);
int enableEvents();
int enableEvents();
int disableEvents();
int disableEvents();
int getMaxMsgSize();
int getMaxMsgSize();
For the sake of readability, we demonstrate development of applications using the API based on a high-level Java-like syntax; we do not consider error handling.
読みやすくするために、高レベルのJavaのような構文に基づくAPIを使用したアプリケーションの開発を示します。エラー処理は考慮していません。
-- Application above middleware:
-ミドルウェア上のアプリケーション：
//Initialize multicast socket;
//the middleware selects all available Interfaces
MulticastSocket m = new MulticastSocket();
m.join(URI("ham:ip:224.1.2.3:5000"));
m.join(URI("ham:ip:[ff02:0:0:0:0:0:0:3]:6000"));
m.join(URI("ham:sip:news@cnn.com"));
-- Middleware:
-ミドルウェア：
join(URI mcAddress) {
//Select Interfaces in use
for all this.interfaces {
switch (interface.type) {
case "ipv6":
//... map logical ID to routing address
Inet6Address rtAddressIPv6 = new Inet6Address();
mapNametoAddress(mcAddress,rtAddressIPv6);
interface.join(rtAddressIPv6);
case "ipv4":
//... map logical ID to routing address
Inet4Address rtAddressIPv4 = new Inet4Address();
mapNametoAddress(mcAddress,rtAddressIPv4);
interface.join(rtAddressIPv4);
case "sip-session":
//... map logical ID to routing address
SIPAddress rtAddressSIP = new SIPAddress();
mapNametoAddress(mcAddress,rtAddressSIP);
interface.join(rtAddressSIP);
case "dht":
//... map logical ID to routing address
DHTAddress rtAddressDHT = new DHTAddress();
mapNametoAddress(mcAddress,rtAddressDHT);
interface.join(rtAddressDHT);
//...
}
}
}
This section describes the application of the defined API to implement an IMG.
このセクションでは、IMGを実装するための定義済みAPIのアプリケーションについて説明します。
The following procedure describes a transparent mapping of a DVMRP-based any-source multicast service to another many-to-many multicast technology, e.g., an overlay.
次の手順では、DVMRPベースの任意のソースマルチキャストサービスから、オーバーレイなどの別の多対多マルチキャストテクノロジーへの透過的なマッピングについて説明します。
An arbitrary Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] router will not be informed of new receivers but will learn about new sources immediately. The concept of DVMRP does not provide any central multicast instance. Thus, the IMG can be placed anywhere inside the multicast region, but the IMG requires a DVMRP neighbor connectivity. Thus, the group communication stack used by the IMG is enhanced by a DVMRP implementation. New sources in the underlay will be advertised based on the DVMRP flooding mechanism and received by the IMG. Based on this, the event "new_source_event" is created and passed to the application. The relay agent initiates a corresponding join in the native network and forwards the received source data towards the overlay routing protocol. Depending on the group states, the data will be distributed to overlay peers.
任意の距離ベクトルマルチキャストルーティングプロトコル（DVMRP）[RFC1075]ルーターは、新しい受信者に通知されませんが、新しいソースについてすぐに学習します。 DVMRPの概念は、中央マルチキャストインスタンスを提供しません。したがって、IMGはマルチキャスト領域内の任意の場所に配置できますが、IMGにはDVMRPネイバー接続が必要です。したがって、IMGによって使用されるグループ通信スタックは、DVMRP実装によって拡張されます。アンダーレイの新しいソースは、DVMRPフラッディングメカニズムに基づいてアドバタイズされ、IMGによって受信されます。これに基づいて、イベント「new_source_event」が作成され、アプリケーションに渡されます。リレーエージェントは、ネイティブネットワークで対応する結合を開始し、受信したソースデータをオーバーレイルーティングプロトコルに転送します。グループの状態に応じて、データはオーバーレイピアに配信されます。
DVMRP establishes source-specific multicast trees. Therefore, a graft message is only visible to DVMRP routers on the path from the new receiver subnet to the source, but in general not to an IMG. To overcome this problem, data of multicast senders in the overlay may become noticeable via the Source Register call, as well as by an IMG that initiates an all-group join in the overlay using the namespace extension of the API. Each IMG is initially required to forward the data received in the overlay to the underlay, independent of native multicast receivers. Subsequent prunes may limit unwanted data distribution thereafter.
DVMRP establishes source-specific multicast trees. Therefore, a graft message is only visible to DVMRP routers on the path from the new receiver subnet to the source, but in general not to an IMG. To overcome this problem, data of multicast senders in the overlay may become noticeable via the Source Register call, as well as by an IMG that initiates an all-group join in the overlay using the namespace extension of the API. Each IMG is initially required to forward the data received in the overlay to the underlay, independent of native multicast receivers. Subsequent prunes may limit unwanted data distribution thereafter.
The following procedure describes a transparent mapping of a PIM-SM-based any-source multicast service to another many-to-many multicast technology, e.g., an overlay.
次の手順では、PIM-SMベースの任意のソースマルチキャストサービスから、オーバーレイなどの別の多対多マルチキャストテクノロジーへの透過的なマッピングについて説明します。
The Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601] establishes rendezvous points (RPs). These entities receive listener subscriptions and source registering of a domain. For a continuous update, an IMG has to be co-located with an RP. Whenever PIM register messages are received, the IMG must signal internally a new multicast source using the event "new_source_event". Subsequently, the IMG joins the group and a shared tree between the RP and the sources will be established; this shared tree may change to a source-specific tree after PIM switches to phase three. Source traffic will be forwarded to the RP based on the IMG join, even if there are no further receivers in the native Multicast Domain. Designated routers of a PIM domain send receiver subscriptions towards the PIM-SM RP. The reception of such messages initiates the event "join_event" at the IMG, which initiates a join towards the overlay routing protocol. Overlay multicast data arriving at the IMG will then be transparently forwarded in the underlay network and distributed through the RP instance.
Protocol Independent Multicast-Sparse Mode（PIM-SM）[RFC4601]は、ランデブーポイント（RP）を確立します。これらのエンティティは、リスナーのサブスクリプションとドメインのソース登録を受け取ります。継続的な更新では、IMGをRPと同じ場所に配置する必要があります。 PIM登録メッセージを受信するたびに、IMGはイベント「new_source_event」を使用して新しいマルチキャストソースを内部的に通知する必要があります。その後、IMGがグループに参加し、RPとソース間の共有ツリーが確立されます。この共有ツリーは、PIMがフェーズ3に切り替わると、ソース固有のツリーに変わる場合があります。ソーストラフィックは、ネイティブマルチキャストドメインにレシーバがそれ以上ない場合でも、IMG加入に基づいてRPに転送されます。 PIMドメインの指定ルーターは、PIM-SM RPに向けて受信者サブスクリプションを送信します。このようなメッセージを受信すると、IMGでイベント「join_event」が開始され、オーバーレイルーティングプロトコルへの参加が開始されます。 IMGに到着したオーバーレイマルチキャストデータは、アンダーレイネットワークで透過的に転送され、RPインスタンスを通じて配信されます。
The following procedure describes a transparent mapping of a PIM-SSM-based source-specific multicast service to another one-to-many multicast technology, e.g., an overlay.
次の手順では、PIM-SSMベースの送信元固有のマルチキャストサービスから、オーバーレイなどの別の1対多のマルチキャストテクノロジーへの透過的なマッピングについて説明します。
PIM Source-Specific Multicast (PIM-SSM) is defined as part of PIM-SM and admits source-specific joins (S,G) according to the source-specific host group model [RFC4604]. A multicast distribution tree can be established without the assistance of a rendezvous point.
PIMソース固有マルチキャスト（PIM-SSM）はPIM-SMの一部として定義され、ソース固有のホストグループモデル[RFC4604]に従ってソース固有の結合（S、G）を許可します。ランデブーポイントの支援なしでマルチキャスト配信ツリーを確立できます。
Sources are not advertised within a PIM-SSM domain. Consequently, an IMG cannot anticipate the local join inside a sender domain and deliver a priori the multicast data to the overlay instance. If an IMG of a receiver domain initiates a group subscription via the overlay routing protocol, relaying multicast data fails, as data is not available at the overlay instance. The IMG instance of the receiver domain thus has to locate the IMG instance of the source domain to trigger the corresponding join. In agreement with the objectives of PIM-SSM, the signaling should not be flooded in the underlay and overlay.
ソースはPIM-SSMドメイン内でアドバタイズされません。その結果、IMGは送信者ドメイン内のローカル参加を予測できず、マルチキャストデータをオーバーレイインスタンスに演繹的に配信できません。受信側ドメインのIMGがオーバーレイルーティングプロトコルを介してグループサブスクリプションを開始すると、オーバーレイインスタンスでデータが利用できないため、マルチキャストデータの中継が失敗します。したがって、受信側ドメインのIMGインスタンスは、対応する参加をトリガーするためにソースドメインのIMGインスタンスを見つける必要があります。 PIM-SSMの目的と一致して、シグナリングはアンダーレイおよびオーバーレイでフラッディングされるべきではありません。
A solution can be to intercept the subscription at both source sites and receiver sites: To monitor multicast receiver subscriptions ("join_event" or "leave_event") in the underlay, the IMG is placed on the path towards the source, e.g., at a domain border router. This router intercepts join messages and extracts the unicast source address S, initializing an IMG-specific join to S via regular unicast. Multicast data arriving at the IMG of the sender domain can be distributed via the overlay. Discovering the IMG of a multicast sender domain may be implemented analogously to Automatic Multicast Tunneling [AMT] by anycast. Consequently, the source address S of the group (S,G) should be built based on an anycast prefix. The corresponding IMG anycast address for a source domain is then derived from the prefix of S.
A solution can be to intercept the subscription at both source sites and receiver sites: To monitor multicast receiver subscriptions ("join_event" or "leave_event") in the underlay, the IMG is placed on the path towards the source, e.g., at a domain border router. This router intercepts join messages and extracts the unicast source address S, initializing an IMG-specific join to S via regular unicast. Multicast data arriving at the IMG of the sender domain can be distributed via the overlay. Discovering the IMG of a multicast sender domain may be implemented analogously to Automatic Multicast Tunneling [AMT] by anycast. Consequently, the source address S of the group (S,G) should be built based on an anycast prefix. The corresponding IMG anycast address for a source domain is then derived from the prefix of S.
The following procedure describes a transparent mapping of a BIDIR-PIM-based any-source multicast service to another many-to-many multicast technology, e.g., an overlay.
次の手順では、BIDIR-PIMベースの任意のソースマルチキャストサービスから別の多対多のマルチキャストテクノロジー（オーバーレイなど）への透過的なマッピングについて説明します。
Bidirectional PIM [RFC5015] is a variant of PIM-SM. In contrast to PIM-SM, the protocol pre-establishes bidirectional shared trees per group, connecting multicast sources and receivers. The rendezvous points are virtualized in BIDIR-PIM as an address to identify on-tree directions (up and down). Routers with the best link towards the (virtualized) rendezvous point address are selected as designated forwarders for a link-local domain and represent the actual distribution tree. The IMG is to be placed at the RP link, where the rendezvous point address is located. As source data in either case will be transmitted to the RP link, the BIDIR-PIM instance of the IMG receives the data and can internally signal new senders towards the stack via the "new_source_event". The first receiver subscription for a new group within a BIDIR-PIM domain needs to be transmitted to the RP to establish the first branching point. Using the "join_event", an IMG will thereby be informed of group requests from its domain, which are then delegated to the overlay.
Bidirectional PIM [RFC5015] is a variant of PIM-SM. In contrast to PIM-SM, the protocol pre-establishes bidirectional shared trees per group, connecting multicast sources and receivers. The rendezvous points are virtualized in BIDIR-PIM as an address to identify on-tree directions (up and down). Routers with the best link towards the (virtualized) rendezvous point address are selected as designated forwarders for a link-local domain and represent the actual distribution tree. The IMG is to be placed at the RP link, where the rendezvous point address is located. As source data in either case will be transmitted to the RP link, the BIDIR-PIM instance of the IMG receives the data and can internally signal new senders towards the stack via the "new_source_event". The first receiver subscription for a new group within a BIDIR-PIM domain needs to be transmitted to the RP to establish the first branching point. Using the "join_event", an IMG will thereby be informed of group requests from its domain, which are then delegated to the overlay.
Authors' Addresses
著者のアドレス
Matthias Waehlisch link-lab & FU Berlin Hoenower Str. 35 Berlin 10318 Germany
Matthias Waehlischリンクラボ＆FUベルリンHoenower Str。 35ベルリン10318ドイツ
EMail: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
トーマスC.シュミットHAWハンブルグベルリントール7ハンブルク20099ドイツ
EMail: schmidt@informatik.haw-hamburg.de
URI: http://inet.cpt.haw-hamburg.de/members/schmidt
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
Stig Venaas Cisco Systems Tasman Drive San Jose、CA 95134 USA
EMail: stig@cisco.com