この文書はRFC3569の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
Network Working Group S. Bhattacharyya, Ed. Request for Comments: 3569 Sprint Category: Informational July 2003 An Overview of Source-Specific Multicast (SSM) ソース特定のマルチキャスト(SSM)の概観 Status of this Memo この文書の状態 This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. このメモはインターネット共同体のための情報を供給します。これはインター ネット標準を指定しません。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 概要 The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. この文書の目的はソース特定マルチキャスト(SSM)の概観とその配置と 関係がある問題を供給することです。これはどのようにSSMサービスモデ ルがドメイン間のマルチキャスト実装で直面した挑戦を扱うか論じます、現 在のマルチキャストサービスモデルの展開と互換性問題のためのルーティン グプロトコルとアプリケーションの変更を必要としました。 1. Introduction 1. はじめに This document provides an overview of the Source-Specific Multicast (SSM) service and its deployment using the PIM-SM and IGMP/MLD protocols. The network layer service provided by SSM is a "channel", identified by an SSM destination IP address (G) and a source IP address S. An IPv4 address range has been reserved by IANA for use by the SSM service. An SSM destination address range already exists for IPv6. A source S transmits IP datagrams to an SSM destination address G. A receiver can receive these datagrams by subscribing to the channel (Source, Group) or (S,G). Channel subscription is supported by version 3 of the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. The interdomain tree for forwarding IP multicast datagrams is rooted at the source S, and is constructed using the PIM Sparse Mode [9] protocol. この文書はソース特定マルチキャスト(SSM)サービスと、PIM−SM とIGMP/MLDプロトコルを使う展開の概観を示します。SSMが供給 したネットワーク層サービスはSSM宛先IPアドレス(G)とソースIP アドレスSで識別された「チャネル」です。SSMサービスに使用するため のIPv4アドレスの範囲がIANAによって確保されました。SSM宛先 アドレス範囲がIPv6ですでに存在します。ソースSがSSM宛先アドレ スGにIPデータグラムを伝達します。受信者がチャネル(ソース、グルー プ)あるいは(S、G)に加入することによってこれらのデータグラムを受 け取ることができます。チャネル加入は、IPv4でIGMPプロトコルの バージョン3により、IPv6でMLDプロトコルのバージョン2により、 サポートされます。IPマルチキャストデータグラムを転送するためのドメ イン間の木はソースSを根とし、PIMまばらモード[9]プロトコルを使って 構築されます。 This document is not intended to be a standard for Source-Specific Multicast (SSM). Instead, its goal is to serve as an introduction to SSM and its benefits for anyone interested in deploying SSM services. It provides an overview of SSM and how it solves a number of problems faced in the deployment of inter-domain multicast. It outlines changes to protocols and applications both at end-hosts and routers for supporting SSM, with pointers to more detailed documents where appropriate. Issues of interoperability with the multicast service model defined by RFC 1112 are also discussed. この文書はソース特定マルチキャスト(SSM)の標準を意図しません。こ の目的はSSMサービスを配置することに興味を持った誰かのために、SS Mとその利益の紹介の役をすることです。これはSSMの概要を供給します、 そしてSSMが多くの問題を解く方法はドメイン間のマルチキャストの展開 のためです。これは、SSMをサポートするためのエンドホストとルータの プロトコルとアプリケーションに対する変更の概要を説明し、適切な場合は より詳細な文書を示します。RFC1112で定義されたマルチキャストサー ビスモデルとの互換性の問題も論じられます。 This memo is a product of the Source-Specific Multicast (SSM) Working Group of the Internet Engineering Task Force. この文書はインターネット技術タスクフォースのソース特定マルチキャスト (SSM)作業グループの成果です。 The keywords "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as defined in BCP 14, RFC 2119 [28]. この文書のキーワード"MUST""と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"とand "OPTIONAL"は BCP14、RFC2119[28]で定義されたように解釈されます。 2. Terminology 2. 専門用語 This section defines some terms that are used in the rest of this document: この章はこの文書で使われるいくつかの用語を定義します:。 Any-Source Multicast (ASM): This is the IP multicast service model defined in RFC 1112 [25]. An IP datagram is transmitted to a "host group", a set of zero or more end-hosts (or routers) identified by a single IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). End-hosts may join and leave the group any time, and there is no restriction on their location or number. Moreover, this model supports multicast groups with arbitrarily many senders - any end-host (or router) may transmit to a host group, even if it is not a member of that group. 任意ソースマルチキャスト(ASM):これはRFC1112[25]で定義 されるIPマルチキャストサービスモデルです。IPデータグラムが「ホ ストグループ」に伝達され、ゼロ個以上のエンドホスト(あるいはルータ) がひとつのIP宛先アドレスで識別されます(IPv4で224.0.0.0から 239.255.255.255 for IPv4)。エンドホストがいつでもグループに加入や 離脱ができ、そして場所や数の制限がありません。さらに、このモデルは 任意の多数の送信者をサポートします−任意のエンドホスト(あるいはルー タ)が、たとえそれがそのグループのメンバーではなくても、ホストグルー プに信号を送るかもしれません。 Source-Specific Multicast (SSM): This is the multicast service model defined in [5]. An IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G). SSM provides host applications with a "channel" abstraction, in which each channel has exactly one source and any number of receivers. SSM is derived from earlier work in EXPRESS [1]. The address range 232/8 has been assigned by IANA for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM services [21]. ソース特定マルチキャスト(SSM):これは[5]で定義されるマルチキャ ストサービスモデルです。IPデータグラムがソースSからSSM宛先ア ドレスGに伝達され、そして受信者がチャネル(S,G)に加入すること によってこのデータグラムを受け取ることができます。SSMはホストア プリケーションに抽象概念「チャネル」を提供し、各チャネルが正確に1 つのソースと任意の数の受信者を持っているます。SSMはEXPRESS[1]の 以前の仕事から得られます。IPv4のアドレス範囲232/8はSSMサービ スのためにIANAによって割り当てられました。IPv6のために、範 囲FF3x::/96はSSMサービスのために定義されます[21]。 Source-Filtered Multicast (SFM): This is a variant of the ASM service model, and uses the same address range as ASM (224.0.0.0-239.255.255.255). It extends the ASM service model as follows. Each "upper layer protocol module" can now request data sent to a host group G by only a specific set of sources, or can request data sent to host group G from all BUT a specific set of sources. Support for source filtering is provided by version 3 of the Internet Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6. We shall henceforth refer to these two protocols as "SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and MLDv1 - do not provide support for source-filtering, and are referred to as "non-SFM-capable". Note that while SFM is a different model than ASM from a receiver standpoint, there is no distinction between the two for a sender. ソースがフィルタしたマルチキャスト(SFM):これはASMサービス モデルの方言であり、そしてASMと同じアドレス範囲(224.0.0.0- 239.255.255.255)を用います。これは次のようにASMサービスモデル を拡張します。各「上位レイヤプロトコルモジュール」は、指定した特定 のソース集合からの、またはソースが指定した特定の集合を除くものかか らの、データをホストグループGへ送信するように求めることができます。 ソースによるフィルタは、IPv4ではインターネットグループ管理プロ トコルのバージョン3(あるいはIGMPv3)[3]で、または、IPv 6ではマルチキャストリスナディスカバリーのバージョン2(あるいはM LDv2)[22]プロトコルで、供給されます。我々はこれからはこれらの 2つのプロトコルが「SFM対応」と述べるでしょう。これらのプロトコ ルの初期のバージョン−IGMPv1とIGMPv2とMLDv1−はソー スによるフィルタのサポートを供給せず、そして「SFM非対応」と述べ ます。受信者から見て、SFMがASMと異なったモデルであるが、送信 者からは2つの間の区別がないことに注意してください。 For the purpose of this document, we treat the scoped multicast model of [12] to be a variant of ASM since it does not explicitly restrict the number of sources, but only requires that they be located within the scope zone of the group. この文書の目的のためにASMの方言として[12]の範囲を指定したマルチキャ ストモデルを扱います、というのは、これが明示的にソースの数を限定しな いが、グループの範囲地域の中でただそれらが位置していることを要求する からです。 3. The IGMP/PIM-SM/MSDP/MBGP Protocol Suite for ASM 3. ASMのためのIGMP/PIM−SM/MSDP/MBGPプロトコルひとそろい As of this writing, all multicast-capable networks support the ASM service model. One of the most common multicast protocol suites for supporting ASM consists of IGMP version 2 [2], PIM-SM [8,9], MSDP [13] and MBGP [26]. IGMPv2 is the most commonly used protocol for hosts to specify membership in a multicast group, and nearly all multicast routers support (at least) IGMPv2. In case of IPv6, MLDv1 [21] is the commonly used protocol. この著作の時点で、すべてのマルチキャスト対応のネットワークはASMサー ビスモデルをサポートします。ASMをサポートするための最も一般的なマ ルチキャストプロトコルの組合せの1つがIGMPバージョン2[2]とPIM −SM[8,9]とMSDP[13]とMBGP[26]です。IGMPv2はホストがマ ルチキャストグループメンバーシップを指定するために最も一般に使われる プロトコルで、そしてほとんどすべてのマルチキャストルータは(少なくと も)IGMPv2をサポートします。IPv6の場合に、MLDv1[21]は 一般に使用されるプロトコルです。 Although a number of protocols such as PIM-DM [10], CBT [24,11], DVMRP [6], etc. exist for building multicast tree among all receivers and sources in the same administrative domain, PIM-SM [8,9] is the most widely used protocol. PIM-SM builds a spanning multicast tree rooted at a core rendezvous point or RP for all group members within a single administrative domain. A 'first-hop' router adjacent to a multicast source sends the source's traffic to the RP for its domain. The RP forwards the data down the shared spanning tree to all interested receivers within the domain. PIM-SM also allows receivers to switch to a source-based shortest path tree. 同じ管理ドメイン内で全ての受信者と情報源の間のマルチキャスト木を作る ため、PIM−DM[10]やCBT[24,11]やDVMRP[6]のような多くのプ ロトコルが存在するが、PIM−SM[8,9]は最も広く使われたプロトコルで す。PIM−SMはひとつの管理領域内で、すべてのグループメンバのため のコア集合点またはRPを根とした広がったマルチキャスト木を作ります。 マルチキャスト情報源に隣接している「最初のホップ」のルータがそのドメ インのRPに情報源からのトラフィックを送ります。RPはドメインの中で すべての受信者が共有する木に沿ってデータを転送します。PIM−SMは 受信者がに情報源に最も近いパスの木に切り替えることを許します。 As of this writing, multicast end-hosts with SFM capabilities are not widely available. Hence a client can only specify interest in an entire host group and receives data sent from any source to this group. この著作の時点で、SFM能力を持つマルチキャストエンドホストは広く利 用可能ではありません。それ故クライアントがただ全部のホストグループに 対して受信を指定することができるだけで、そしてどの情報源がこのグルー プに送ったデータでも受け取ります。 Inter-domain multicast service (i.e., where sources and receivers are located in different domains) requires additional protocols - MSDP [13] and MBGP [26] are the most commonly used ones. An RP uses the MSDP protocol to announce multicast sources to RPs in other domains. When an RP discovers a source in a different domain transmitting data to a multicast group for which there are interested receivers in its own domain, it joins the shortest-path source based tree rooted at that source. It then redistributes the data received to all interested receivers via the intra-domain shared tree rooted at itself. ドメイン間のマルチキャストサービス(すなわち、情報源と受信者が異なっ たドメインに位置している場合)が追加のプロトコルを要求します−MSD P[13]とMBGP[26]が最も一般に使われます。他のドメインのRPにマル チキャスト情報源を通知するために、MSDPプロトコルはRPを使います。 RPが自分自身のドメインに受信者がいるマルチキャストグループにデータ を送っている異なったドメインの情報源を発見した時、RPは情報源を根と した最短パスの木に参加します。それからRPは自分自身を根としたドメイ ン内の共有木によってすべての受信者に受信データを再分配します。 MBGP defines extensions to the BGP protocol to support the advertisement of reachability information for multicast routes. This allows an autonomous system (AS) to support incongruent unicast and multicast routing topologies, and thus implement separate routing policies for each. MBGPはマルチキャスト経路の可到達性情報の広告をサポートするために BGPプロトコルへの拡張を定義します。これは自律システム(AS)にユ ニキャストとマルチキャストの同一でないルーティングトポロジーをサポー トを許し、それぞれのルーティングポリシーの実行を許します。 However, the last-hop routers of interested receivers may eventually switch to a shortest-path tree rooted at the source that is transmitting the data. しかしながら、受信者の最終ホップルータは結局はデータを伝達している情 報源を根とした最短パス木に切り替えてもよいです。 4. Problems with Current Architecture 4. 現在のアーキテクチャにおける問題 There are several deployment problems associated with current multicast architecture: 現在のマルチキャストアーキテクチャと結び付けられたいくつかの展開問題 があります: A) Address Allocation: A) アドレス割り当て: Address allocation is one of core deployment challenges posed by the ASM service model. The current multicast architecture does not provide a deployable solution to prevent address collisions among multiple applications. The problem is much less serious for IPv6 than for IPv4 since the size of the multicast address space is much larger. A static address allocation scheme, GLOP [17] has been proposed as an interim solution for IPv4; however, GLOP addresses are allocated per registered AS, which is inadequate in cases where the number of sources exceeds the AS numbers available for mapping. RFC 3138 expands on RFC 2770 to allow routing registries to assign multicast addresses from the GLOP space corresponding to the RFC 1930 private AS space [27]. This space is referred to as the EGLOP (Extended GLOP) address space. Proposed longer-term solutions such as the Multicast Address Allocation Architecture [14] are generally perceived as being too complex (with respect to the dynamic nature of multicast address allocation) for widespread deployment. アドレス割り当てはASMサービスモデルで発生する展開上の重要な 挑戦の1つです。現在のマルチキャストアーキテクチャは多数のアプ リケーション間でアドレス衝突を妨げる展開可能な解決策を供給しま せん。IPv6での問題は、マルチキャストアドレス空間の大きさが より大きいので、IPv4のより重大ではありません。静的アドレス 割当案、GLOP[17]が仮の解決策としてIPv4に対して提案され ました;しかしながら、GLOPアドレスが登録された自律システム 毎に割り当てられ、そしてこれは情報源の数がマッピング可能な自律 システム番号を超える場合に不適当です。RFC3138は、ルーティ ング登記所がRFC1930のプライベートAS空間[27]に対応した GLOP空間からマルチキャストアドレスを割り当てることを許すた めに、RFC2770を拡張します。この空間はEGLOP(拡張G LOP)アドレス空間と述べられます。マルチキャストアドレス割当 アーキテクチャ[14]のような提案されたより長期の解決策は、一般に 広範囲にわたる展開に対して(マルチキャストアドレス割当ての動的 な性質のために)あまりにも複雑であるものと見なされます。 B) Lack of Access control: B) アクセス制御の欠如: In the ASM service model, a receiver cannot specify which specific sources it would like to receive when it joins a given group. A receiver will be forwarded data sent to a host group by any source. Moreover, even when a source is allocated a multicast group address to transmit on, it has no way of enforcing that no other source will use the same address. This is true even in the case of IPv6, where address collisions are less likely due to the much larger size of the address space. ASMサービスモデルで、受信者が特定のグループに参加する時、ど の特定の情報源からの情報を受け取りたいか明示することができませ ん。受信者が、ホストグループに送られる、全ての情報源からのデー タを受取るでしょう。さらに、情報源が信号を送るべきマルチキャス トグループアドレスを割り当てられる時でさえ、他の情報源が同じア ドレスを使わないようにする方法を持っていません。アドレス空間が ずっとより大きいので、アドレス衝突はより少ないが、これはIPv 6の場合でも真実です。 C) Inefficient handling of well-known sources: C) 既知の情報源の非能率的な取り扱い: In cases where the address of the source is well known in advance of the receiver joining the group, and when the shortest forwarding path is the preferred forwarding mode, then shared tree mechanisms are not necessary. あらかじめグループに参加してい受信者が情報源のアドレスを知って いる場合と、最短転送パスが望ましい転送方法であるときに、共有木 メカニズムは必要ではありません。 5. Source Specific Multicast (SSM): Benefits and Requirements 5. ソース特定マルチキャスト(SSM):利益と条件 As mentioned before, the Source Specific Multicast (SSM) service model defines a "channel" identified by an (S,G) pair, where S is a source address and G is an SSM destination address. Channel subscriptions are described using an SFM-capable group management protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees are needed to implement this model. 前に述べた通り、ソース特定マルチキャスト(SSM)サービスモデルは、 Sを情報源アドレス、GをSSM宛先アドレスとしたとき、(S、G)対で 識別された「チャネル」を定義します。チャネル加入者がIGMPv3ある いはMLDv2のようなSFM対応のグループ管理プロトコルを使って記述 されます。ただソースベースの転送木だけがこのモデルを実行するために必 要とされます。 The SSM service model alleviates all of the deployment problems described earlier: SSMサービスモデルは前に記述された展開問題のすべてを軽減します: A) Address Allocation: SSM defines channels on a per-source basis, i.e., the channel (S1,G) is distinct from the channel (S2,G), where S1 and S2 are source addresses, and G is an SSM destination address. This averts the problem of global allocation of SSM destination addresses, and makes each source independently responsible for resolving address collisions for the various channels that it creates. A) アドレス割当て:SSMはソース毎にチャネルを定義します、すなわ ち、GをSSM宛先アドレス、S1とS2が異なるソースアドレスの 場合、チャネル(S1、G)はチャネル(S2、G)は異なっていま す。これはSSM宛先アドレスのグローバル割当て問題を避け、そし てそれぞれの情報源が様々なチャネルを作る際に独立にアドレス衝突 を解決する責任をもてます。 B) Access Control: SSM lends itself to an elegant solution to the access control problem. When a receiver subscribes to an (S,G) channel, it receives data sent only by the source S. In contrast, any host can transmit to an ASM host group. At the same time, when a sender picks a channel (S,G) to transmit on, it is automatically ensured that no other sender will be transmitting on the same channel (except in the case of malicious acts such as address spoofing). This makes it much harder to "spam" an SSM channel than an ASM multicast group. B) アクセス制御:SSMはアクセス制御問題に対する優雅な解決策を招 きます。受信者が(S、G)チャネルに参加する時、受信者は情報源 Sの送るデータだけを受け取ります。これと対照的に、どんなホスト でもASMホストグループに信号を送ることができます。同時に、送 信者が信号を送るべきチャネル(S、G)を選ぶ時、他の送信者が同 じチャネル上で送信しないであろうことは自動的に保証されます(ア ドレスなりすましのような悪意がある行為の場合は別です)。これは ASMマルチキャストグループよりSSMチャンネルを「スパム」す ることをずっともっと難しくします。 C) Handling of well-known sources: SSM requires only source-based forwarding trees; this eliminates the need for a shared tree infrastructure. This implies that neither the RP-based shared tree infrastructure of PIM-SM nor the MSDP protocol is required. Thus the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment. Note that there is no difference in how MBGP is used for ASM and SSM. C) 既知情報源の取り扱い:SSMはただ情報源ベースの転送木だけを必 要とします;これは共有木インフラの必要を排除します。これはPI M−SMのRPベースの共有木インフラとMSDPプロトコルのいず れも必要ないことを意味します。それでSSMのためのマルチキャス トルーティングインフラの複雑さは低く、展開即実行可能です。AS MとSSMのために使われるMBGPの使い方に違いがないことに注 意してください。 6. SSM Framework 6. SSMフレームワーク Figure 1 illustrates the elements in an end-to-end implementation framework for SSM: 図1がSSMのためのエンドエンド実装フレームワークの要素を示します: -------------------------------------------------------------- IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION FF3x::/96 for IPv6 IANAはIPv4に232/8を割当て アドレス割り当て IPv6にFF3x::/96を割当て -------------------------------------------------------------- | v +--------------+ session directory/web page | source,group | SESSION DESCRIPTION | | セッションディレクトリ/ウェブページ | | セッション記述 -------------------------------------------------------------- ^ | Query | | (S,G) | v +-----------------+ host | | ホスト | SSM-aware app | CHANNEL DISCOVERY | | チャンネル探索 -------------------------------------------------------------- | SSM-aware app | SSM-AWARE APPLICATION | | SSM対応アプリケーション -------------------------------------------------------------- | IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING | | IGMPv3/MLDv2ホスト報告 +-----------------+ |(source specific host report) |(ソース特定ホスト報告) -------------------------------------------------------------- v +-----------------+ Querier Router | | 質問者ルータ | IGMPv3/MLDv2 | QUERIER | | 質問者 -------------------------------------------------------------- | PIM-SSM | PIM-SSM ROUTING | | PIM−SSMルーチング +------------+ Designated Router | 指名ルータ | | (S,G) Join only v +-----------+ Backbone Router | PIM-SSM | バックボーンルータ +-----------+ | | (S,G) Join only V Figure 1: SSM Framework: elements in end-to-end model 図1:SSMフレームワーク:エンドエンドモデルでの要素 We now discuss the framework elements in detail: 我々は今フレームワーク要素の詳細を論じます: 6.1. Address Allocation 6.1. アドレス割当 For IPv4, the address range of 232/8 has been assigned by IANA for SSM. To ensure global SSM functionality in 232/8, including in networks where routers run non-SFM-capable protocols, operational policies are being proposed [9] which recommend that routers should not send SSM traffic to parts of the network that do not have channel subscribers. IPv4のために、232/8アドレス範囲はSSMのためにIANAによって割 り当てられました。非SFM対応のプロトコルを走らせるルーターのあるネッ トワークを含め、232/8でグローバルなSSM機能を保証するために、運用ポ リシーが提案され[9]、これはルーターがチャネル加入者を持っていないネッ トワークの一部にSSMトラフィックを送るべきではないことを勧めます。 Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 range. However, SSM service, as defined in [5], is available only in this address range for IPv4. IGMPv3/MLDv2が(S、G)結合をただ232/8の範囲だけに 制限しないことに注意してください。しかしながら、SSMサービスは、 [5]で定義されるように、IPv4でこのアドレス範囲でだけ可能です。 In case of IPv6, [23] has defined an extension to the addressing architecture to allow for unicast prefix-based multicast addresses. See RFC 3306 for details. IPv6の場合に、[23]がユニキャストにプレフィックスベースのマルチ キャストを割り当てるアドレスアーキテクチャの拡張を定義しました。詳 細はRFC3306を見てください。 6.2. Session Description and Channel Discovery 6.2. セッション記述とチャンネルディスカバリー An SSM receiver application must know both the SSM destination address G and the source address S before subscribing to a channel. Channel discovery is the responsibility of applications. This information can be made available in a number of ways, including via web pages, sessions announcement applications, etc. This is similar to what is used for ASM applications where a multicast session needs to be announced so that potential subscribers can know of the multicast group address, encoding schemes used, etc. In fact, the only additional piece of information that needs to be announced is the source address for the channel being advertised. However, the exact mechanisms for doing this is outside the scope of this framework document. SSM受信アプリケーションがチャネルに加入する前にSSM宛先アドレス GとソースアドレスSの両方を知っていなくてはなりません。チャンネル探 索はアプリケーションの責任です。この情報は、ウェブページやセッション 広告アプリケーションなど、多くの方法で利用可能です。これは、受信可能 性がある加入者がマルチキャストグループアドレスや使われたコーディング 方法などについて知ることができるように、マルチキャストセッションを知 らせる、ASMアプリケーションで使われるものに類似しています。実際は、 知らせる必要がある追加の情報は広告チャンネルのソースアドレスです。し かしながら、その正確なメカニズムは、このフレームワーク文書の範囲外で す。 6.3. SSM-Aware Applications 6.3. SSM対応アプリケーション There are two main issues in making multicast applications "SSM-aware": マルチキャストアプリケーションを「SSM対応」にすることに2つの主な 問題があります: - An application that wants to receive an SSM session must first discover the channel address in use. - SSMセッションの受信を望むアプリケーションが最初に使用するチャン ネルアドレスを発見しなくてはなりません。 - A receiving application must be able to specify both a source address and a destination address to the network layer protocol module on the end-host. - 受信アプリケーションがエンドホスト上のネットワーク層プロトコルモ ジュールにソースアドレスと宛先アドレスの両方を指定することができな ければなりません。 Specific API requirements are identified in [16]. [16] describes a recommended application programming interface for a host operating system to support the SFM service model. Although it is intended for SFM, a subset of this interface is sufficient for supporting SSM. 特定のAPIの要求条件が[16]で指定されます。[16]はホストオペレー ティング・システムがSFMサービスモデルをサポートするために推薦さ れたアプリケーション・プログラミング・インタフェースを記述します。 これがSFMのために意図されるが、このインタフェースの一部のサポー トだけでSSMに十分です。 6.4. IGMPv3/MLDv2 Host Reporting and Querier 6.4. IGMPv3/MLDv2ホスト報告と問合せ In order to use SSM service, an end-host must be able to specify a channel address, consisting of a source's unicast address and an SSM destination address. IGMP version 2 [3] and MLD version 1 [19] allows an end-host to specify only a destination multicast address. The ability to specify an SSM channel address c is provided by IGMP version 3 [3] and MLD version 2 [20]. These protocols support "source filtering", i.e., the ability of an end-system to express interest in receiving data packets sent only by SPECIFIC sources, or from ALL BUT some specific sources. In fact, IGMPv3 provides a superset of the capabilities required to realize the SSM service model. SSMサービスを使うためにエンドホストが、ソースのユニキャストアドレ スとSSM宛先アドレスから成り立つ、チャンネルアドレスを指定すること ができなければなりません。IGMPバージョン2[3]とMLDバージョン1 [19]だけがエンドホストに宛先マルチキャストアドレスの指定を許します。 SSMチャネルアドレスcを指定する能力はIGMPバージョン3[3]とML Dバージョン2[20]によって供給されます。これらのプロトコルは「ソース フィルター」、すなわち、エンドシステムが特定のソース又は特定のソース 以外のソースが送信したデータパケットを受信することに興味を示す能力、 をサポートします。実際、IGMPv3がSSMサービスモデルを実行する のに必要な能力の上位セットを供給します。 A detailed discussion of the use of IGMPv3 in the SSM destination address range is provided in [4]. SSM宛先アドレス範囲でのIGMPv3の使用の詳細な論議が[4]で供給さ れます。 The Multicast Listener Discovery (MLD) protocol used by an IPv6 router to discover the presence of multicast listeners on its directly attached links, and to discover the multicast addresses that are of interest to those neighboring nodes. MLD version 1 is derived from IGMPv2 and does not provide the source filtering capability required for the SSM service model. MLD version 2 is derived from, and provides the same support for source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6) provides a host with the ability to request the network for an SSM channel subscription. IPv6ルータで使用されるマルチキャスト受信者探索(MLD)プロトコ ルは、直接つながったリンク上のマルチキャスト受信者の存在を発見し、近 隣ノードが興味を示すマルチキャストアドレスを発見します。MLDバージョ ン1がIGMPv2に由来し、SSMサービスモデルのために必要とされる ソースフィルター能力を供給しません。MLDバージョン2がIGMPv3 に由来し、そして同じソースフィルターをサポートします。それでIGMP v3((あるいはIPv6でMLDv2)がSSMチャンネル受信をネット ワークに求める能力をホストに提供します。 6.5. PIM-SSM Routing 6.5. PIM SSMルーティング [9] provides guidelines for how a PIM-SM implementation should handle source-specific host reports as required by SSM. Earlier versions of the PIM protocol specifications did not describe how to do this. [9]は、PIM−SM実装が、SSMで必要な、ソース特定ホスト報告を処理 する方法の、ガイドラインを提供します。PIMプロトコル仕様書の以前の バージョンがこれをする方法を記述しませんでした。 The router requirements for operation in the SSM range are detailed in [5]. These rules are primarily concerned with preventing ASM-style behaviour in the SSM address range. In order to comply with [5] several changes to the PIM-SM protocol are required, as described in [9]. The most important changes in PIM-SM required for compliance with [5] are: SSMのためのルータの運用条件は[5]で記述されます。これらの規則は主に SSMアドレス範囲でASM様式の行動を妨げることに関わっています。[5] に従うために、PIM−SMプロトコルに対するいくつかの変更が、[9]で記 述されるように、必要とされます。[5]の順守に必要とされるPIM−SMの 最も重要な変更は以下です: - When a DR receives an (S,G) join request with the address G in the SSM address range, it MUST initiate a (S,G) join, and NEVER a (*,G) join. - DRがSSMアドレス範囲のアドレスGで(S,G)結合要請を受け取る時、 (S,G)結合を開始し(MUST)、(*,G)を開始してはなりません(NEVER)。 - Backbone routers (i.e., routers that do not have directly attached hosts) MUST NOT propagate (*,G) joins for group addresses in the SSM address range. - バックボーンルータ(すなわち、直接接続するホストを持たないルータ) がSSMアドレス範囲のグループアドレスで(*,G)の伝播をしてはなりま せん(MUST NOT)。 - Rendezvous Points (RPs) MUST NOT accept PIM Register messages or (*,G) Join messages in the SSM address range. - 待合せ場所(RP)はPIM登録メッセージあるいはSSMアドレス範囲 の(*,G)結合メッセージを受け入れてはなりません(MUST NOT)。 Note that only a small subset of the full PIM-SM protocol functionality is needed to support the SSM service model. This subset is explicitly documented in [9]. SSMサービスモデルをサポートするために、完全なPIM−SMプロトコ ル機能の一部だけが必要なことに注意してください。この一部の機能は[9]で 明示的に文書化されます。 7. Interoperability with Existing Multicast Service Models 7. 既存のマルチキャストサービスモデルとの互換性 Interoperability with ASM is one of the most important issues in moving to SSM deployment, since both models are expected to be used at least in the foreseeable future. SSM is the ONLY service model for the SSM address range - the correct protocol behaviour for this range is specified in [5]. The ASM service model will be offered for the non-SSM address range, where receivers can issue (*,G) join requests to receive multicast data. A receiver is also allowed to issue an (S,G) join request in the non-SSM address range; however, in that case there is no guarantee that it will receive service according to the SSM model. ASMとの互換性は、両方のモデルが少なくとも近い将来使われることを期 待されるから、SSM実装が展開される際に最も重要な問題の1つです。S SMはSSMアドレス範囲の唯一のサービスモデルです−この範囲の正しい プロトコル動作が[5]で指定されます。ASMサービスモデルはSSM以外の アドレス範囲で供給され、受信者はマルチキャストデータの受信に(*,G)加入 を要請します。受信者が非SSMのアドレス範囲で(S,G)結合要請を許されま す;しかしながら、このような場合SSMモデルに従ってサービスを受ける 保証がありません。 Another interoperability issue concerns the MSDP protocol, which is used between PIM-SM rendezvous points (RPs) to discover multicast sources across multiple domains. MSDP is not needed for SSM, but is needed if ASM is supported. [9] specifies operational recommendations to help ensure that MSDP does not interfere with the ability of a network to support the SSM service model. Specifically, [9] states that RPs must not accept, originate or forward MSDP SA messages for the SSM address range. もう1つの互換性問題はMSDPプロトコルに関係し、これは多数のドメイ ンでマルチキャストソースを発見するPIM−SM待合せ場所(RP)で使 われます。MSDPはSSMで必要とされませんが、ASMがサポートされ るなら必要とされます。[9]は、MSDPがネットワークのSSMサービスモ デルをサポートする能力を妨害しないことを保証するための、運用上の推薦 を指定します。特に、[9]はRPがSSMアドレス範囲でMSDPのSAメッ セージの受取りと生成と転送をしてはならないと明示します。 8. Security Considerations 8. セキュリティの考察 SSM does not introduce new security considerations for IP multicast. It can help in preventing denial-of-service attacks resulting from unwanted sources transmitting data to a multicast channel (S, G). However no guarantee is provided. SSMはIPマルチキャストに対する新しいセキュリティの懸念を生じませ ん。これはマルチキャストチャンネル(S, G)に望まれないソースがデータを 伝達したことに起因するサービス妨害攻撃を妨げることを助けます。しかし ながら、保証が供給されません。 9. Acknowledgments 9. 謝辞 We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Timothy Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi Bhaskar for participating in lengthy discussions and design work on SSM, and providing feedback on this document. Thanks are also due to Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth, Brian Levine, Brad Cain, Hugh LaMaster and Pekka Savola for their valuable insights and continuing support. 我々はSSMの長い論議とデザインの仕事に参加して、そしてこの文書に フィードバックを供給したことに対して、Gene BowenとEd KressとBryan LylesとTimothy RoscoeとHugh HolbrookとIsidor KouvelasとTony Speakman とNidhi Bhaskarに感謝します。貴重な洞察と継続するサポートのために同 じくMujahid KhanとTed SeelyとTom PusateriとBill FennerとKevin AlmerothとBrian LevineとBrad CainとHugh LaMasterとPekka Savolaに感謝 します。 10. References 10. 参考文献 10.1. Informative References 10.1. 有益な参考文献 [1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-Source Applications", In Proceedings of SIGCOMM 1999. [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3.", RFC 3376, October 2002. [4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for Source-Specific Multicast", Work In Progress. [5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress. [6] Deering, S. and D. Cheriton,"Multicast Routing in Datagram Networks and Extended LANs", ACM Transactions on Computer Systems, 8(2):85-110, May 1990. [7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast Routing", IEEE/ACM Transaction on Networking, pages 153-162, April 1996. [8] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work In Progress. [10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Work In Progress. [11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997. [12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [13] Farinacci, D. et al., "Multicast Source Discovery Protocol", Work In Progress. [14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000. [15] Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen, "Deployment Issues for the IP Multicast Service and Architecture", In IEEE Networks Magazine's Special Issue on Multicast, January, 2000. [16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress. [17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001. [18] Levine, B. et al., "Consideration of Receiver Interest for IP Multicast Delivery", In Proceedings of IEEE Infocom, March 2000. [19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999. [20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2) for IPv6", Work In Progress. [21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast Addresses", RFC 3306, August 1992. [22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [23] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002. [24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast Routing -- Protocol Specification", RFC 2189, September 2001. [25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. [27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001. 10.2. Normative References 10.2. 参照する参考文献 [28] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11. Contributors 11. 貢献者 Christophe Diot Intel EMail: christophe.diot@intel.com Leonard Giuliano Juniper Networks EMail: lenny@juniper.net Greg Shepherd Procket Networks EMail: shep@procket.com Robert Rockell Sprint EMail: rrockell@sprint.net David Meyer Sprint EMail: dmm@1-4-5.net John Meylor Cisco Systems EMail: jmeylor@cisco.com Brian Haberman Caspian Networks EMail: bkhabs@nc.rr.com 12. Editor's Address 12. 著者のアドレス Supratik Bhattacharyya Sprint EMail: supratik@sprintlabs.com 13. Full Copyright Statement 13. 著作権表示全文 Copyright (C) The Internet Society (2003). All Rights Reserved. 著作権(C)インターネット学会(2003)。すべての権利は保留される。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、 この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装 を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出 版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ ンターネット標準を開発する目的で必要な場合以外は、インターネット学会 や他のインターネット組織は著作権表示や参照を削除されるような変更がで きません、インターネット標準を開発する場合はインターネット標準化プロ セスで定義された著作権の手順に従われます。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. 上に与えられた限定された許可は永久で、インターネット学会やその後継者 や譲渡者によって無効にされません。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. RFCエディタ機能のための資金供給が現在インターネット学会によって 供給されます。