RFC3569 日本語訳
3569 An Overview of Source-Specific Multicast (SSM). S. Bhattacharyya,Ed.. July 2003. (Format: TXT=29387 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Bhattacharyya, Ed. Request for Comments: 3569 Sprint Category: Informational July 2003
ワーキンググループS.Bhattacharyya、エドをネットワークでつないでください。コメントのために以下を要求してください。 3569年の短距離競走カテゴリ: 情報の2003年7月
An Overview of Source-Specific Multicast (SSM)
ソース特有のマルチキャストの概要(SSM)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(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.
このドキュメントの目的はSource特有のMulticast(SSM)と展開に関連する問題の概要を提供することです。 それは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.
このドキュメントは、PIM-SMとIGMP/MLDプロトコルを使用することでSource特有のMulticast(SSM)の概要にサービスとその展開を提供します。 SSMによって提供されたネットワーク層サービスはSSM送付先IPアドレス(G)によって特定された「チャンネル」です、そして、ソースのIPアドレスのS.An IPv4アドレスの範囲は使用のためにSSMサービスでIANAによって予約されました。 SSM目的地のアドレスの範囲はIPv6のために既に存在しています。 情報筋SはSSM送付先アドレスG.にIPデータグラムを送信します。A受信機は、チャンネル(ソース、Group)か(S、G)に加入することによって、これらのデータグラムを受けることができます。 チャンネル購読はIPv4のためのIGMPプロトコルのバージョン3とIPv6のためのMLDプロトコルのversion2によってサポートされます。 推進IPマルチキャストデータグラムのためのinterdomain木は、ソースSに根づいて、PIM Sparse Mode[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
このドキュメントはSource特有のMulticast(SSM)の規格であることを意図しません。 代わりに、目標はSSMにサービスを配布したがっていた人々のためのSSMとその利益のために序論として機能することです。 それはSSMとそれがどう相互ドメインマルチキャストの展開で直面していた多くの問題を解決するかに関する概要を提供します。 それは終わりホストとルータにプロトコルとアプリケーションへの変化について概説します。
Bhattacharyya Informational [Page 1] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[1ページ]のRFC3569 SSM2003年7月の概要
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をサポートするために。 また、マルチキャストサービスモデルがRFC1112によって定義されている相互運用性の問題について議論します。
This memo is a product of the Source-Specific Multicast (SSM) Working Group of the Internet Engineering Task Force.
このメモはインターネット・エンジニアリング・タスク・フォースのSource特有のMulticast(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"」、「必須NOT」、「必要であった」“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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アドレスによって特定された終わりホスト(または、ルータ)である、(224.0、.0、.0〜239.255、.255、IPv4のための.255) 終わりホストは、加わって、いつでも仲間から抜けるかもしれません、そして、制限が全く彼らの位置か番号にありません。 そのうえ、このモデルは任意に多くの送付者と共にマルチキャストグループをサポートします--どんな終わりホスト(または、ルータ)もホストグループに伝わるかもしれません、それがそのグループのメンバーでなくても。
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つのソースといろいろな受信機を持っています)。 EXPRESS[1]で以前の仕事からSSMを得ます。 アドレスの範囲232/8はIPv4での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
ソースによってフィルターにかけることのマルチキャスト(SFM): これは、ASMサービスモデルの異形であり、ASM(224.0.0.0-239.255.255.255)と同じアドレスの範囲を使用します。 それは以下のASMサービスモデルを広げています。 各「上側の層のプロトコルモジュール」は、現在データが特定のセットの源だけによるホストグループGに発信したよう要求できるか、またはデータがすべてのBUTからのソースの特定のセットをホストグループGに送ったよう要求できます。 IPv4のためのインターネットGroup Managementプロトコル(または、IGMPv3)[3]のバージョン3、およびIPv6のためのMulticast Listenerディスカバリー(または、MLDv2)[22]プロトコルのバージョン2はソースフィルタリングのサポートを提供します。 私たちは今後は、「SFMできる」とこれらの2つのプロトコルを呼ぶつもりです。 プロトコル(IGMPv1/IGMPv2とMLDv1)がサポートを提供しないこれらの以前のバージョン
Bhattacharyya Informational [Page 2] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[2ページ]のRFC3569 SSM2003年7月の概要
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」と呼ばれます。 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.
相互ドメインマルチキャストサービス(すなわち、ソースと受信機は異なったドメインにそこに位置している)は追加議定書を必要とします--MSDP[13]とMBGP[26]は最も一般的に使用されたものです。 RPは、他のドメインのRPsにマルチキャストソースを発表するのにMSDPプロトコルを使用します。 RPが、異なったドメインの情報筋が関心がある受信機がそれ自身のドメインにあるマルチキャストグループにデータを送っていると発見するとき、それはベースの木がそのソースに根づかせた最短パスソースに加わります。 そして、それはそれ自体に根づいているイントラドメイン共有された木を通してすべての関心がある受信機に受け取られたデータを再配付します。
Bhattacharyya Informational [Page 3] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[3ページ]のRFC3569 SSM2003年7月の概要
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)を合同でないユニキャストとマルチキャストルーティングがtopologiesであるとサポートして、その結果、それぞれのために、別々のルーティングが方針であると実装します。
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のための当座のソリューションとして提案されました。 しかしながら、登録されたAS単位でGLOPアドレスを割り当てます。ASはソースの数がマッピングに有効なAS番号を超えている場合で不十分です。 RFC3138は、ルーティング登録がRFC1930の個人的なASスペース[27]に対応するGLOPスペースからのマルチキャストアドレスを割り当てるのを許容するためにRFC2770について詳述します。 このスペースはEGLOP(拡張GLOP)アドレス空間と呼ばれます。 一般に、Multicast Address Allocation Architecture[14]などの提案されたより長い期間ソリューションは広範囲の展開には複雑過ぎるとして(マルチキャストアドレス配分のダイナミックな本質に関する)知覚されます。
B) Lack of Access control:
B) Accessコントロールの不足:
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サービスモデルでは、受信機は、それがどの特定のソースを受け取りたがっているかを指定できません。 どんなソースによるホストグループにも送られたデータを受信機に転送するでしょう。 伝わるマルチキャストグループアドレスをソースに割り当てるときさえ、そのうえ、それには他のどんなソースも同じアドレスを使用しない実施の方法が全くありません。 これはIPv6の場合にさえ当てはまります。(そこでは、アドレス衝突がアドレス空間のはるかに大きいサイズのためにそれほどありそうではありません)。
Bhattacharyya Informational [Page 4] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[4ページ]のRFC3569 SSM2003年7月の概要
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.
Source Specific Multicast(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は1ソースあたり1個のベースでチャンネルを定義します、すなわち、チャンネル(S1、G)はチャンネル(S2、G)と異なっています。そこでは、S1とS2がソースアドレスであり、GはSSM送付先アドレスです。 これで、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.Inコントラストだけによって送られたデータを受け取ると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はソースベースの推進木だけを必要とします。 これは共有された木のインフラストラクチャの必要性を排除します。 または、これが、PIM-SMについてRPベースが共有したどちらもインフラストラクチャを木に追い上げないのを含意する、MSDPプロトコルが必要です。 したがって、それを即座の展開に実行可能にして、SSMのためのマルチキャストルーティングインフラストラクチャの複雑さは低いです。 MBGPがASMとSSMにどう使用されるか違いが全くないことに注意してください。
Bhattacharyya Informational [Page 5] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[5ページ]のRFC3569 SSM2003年7月の概要
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
--------------------------------------------------------------
|
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
--------------------------------------------------------------
| IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
+-----------------+
|(source specific host report)
--------------------------------------------------------------
v
+-----------------+ Querier Router
| IGMPv3/MLDv2 | QUERIER
--------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING
+------------+ Designated Router
|
| (S,G) Join only
v
+-----------+ Backbone Router
| PIM-SSM |
+-----------+
|
| (S,G) Join only
V
-------------------------------------------------------------- IANAはIPv4 ADDRESS ALLOCATION FF3xのために232/8を割り当てました:、:IPv6のための/96-------------------------------------------------------------- | +に対して--------------+ セッションディレクトリ/ウェブページ| ソース、グループ| セッション記述-------------------------------------------------------------- ^ | 質問| | (S、G) | +に対して-----------------+ ホスト| SSM意識している装置| チャンネル発見-------------------------------------------------------------- | SSM意識している装置| SSM意識しているアプリケーション-------------------------------------------------------------- | IGMPv3/MLDv2| +を報告するIGMPv3/MLDv2ホスト-----------------+ |(ソースの特定のホストレポート) -------------------------------------------------------------- +に対して-----------------+ Querierルータ| IGMPv3/MLDv2| QUERIER-------------------------------------------------------------- | PIM-SSM| PIM-SSMルーティング+------------+ 代表ルータ| | (S、G) +だけに対して接合してください。-----------+ バックボーンルータ| PIM-SSM| +-----------+ | | (S、G) Vだけを接合してください。
Figure 1: SSM Framework: elements in end-to-end model
図1: SSMフレームワーク: 終わりから終わりへのモデルの要素
Bhattacharyya Informational [Page 6] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[6ページ]のRFC3569 SSM2003年7月の概要
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プロトコルを実行して、運用政策が提案されているネットワークに[9] どれがそれを推薦するかを含む232/8におけるグローバルなSSMの機能性を確実にするために、ルータはチャンネル加入者がいないネットワークの部分へのトラフィックを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範囲だけにつなぎます。 しかしながら、[5]で定義されるSSMサービスはこのアドレスの範囲だけで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.
- 受信アプリケーションは終わりホストの上のネットワーク層プロトコルモジュールにソースアドレスと送付先アドレスの両方を指定できなければなりません。
Bhattacharyya Informational [Page 7] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[7ページ]のRFC3569 SSM2003年7月の概要
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]で特定されます。 ホスト・オペレーティング・システムがSFMサービスモデルをサポートするように、[16]はお勧めのアプリケーションプログラミングインターフェースについて説明します。 SFMのために意図しますが、このインタフェースの部分集合はSSMをサポートするのに十分です。
6.4. IGMPv3/MLDv2 Host Reporting and Querier
6.4. IGMPv3/MLDv2ホスト報告とQuerier
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]で、終わりホストは送付先マルチキャストアドレスしか指定できません。 IGMPバージョン3[3]とMLDバージョン2[20]はSSMチャンネル・アドレスcを指定する能力を提供します。 これらのプロトコルは「ソースフィルタリング」をサポートします、すなわち、エンドシステムがデータ・パケットを受けることへの関心を示す能力は単にSPECIFICソースか、ALL BUTから何人かの特定のソースを追い出しました。 事実上、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ルータによって使用される、直接付属しているリンクの上にマルチキャストリスナーの存在を発見して、それらの隣接しているノードに興味深いマルチキャストアドレスを発見するMulticast Listenerディスカバリー(MLD)プロトコル。 MLDバージョン1は、IGMPv2から得られて、SSMサービスモデルに必要である能力をフィルターにかけるソースを提供しません。 IGMPv3が2が得られて、ソースフィルタリングの同じサポートを提供するMLDバージョン。 したがって、IGMPv3(または、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で最も重要な変化は以下の通りです。
Bhattacharyya Informational [Page 8] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[8ページ]のRFC3569 SSM2003年7月の概要
- 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が受信する、(S、G)はSSMアドレスの範囲のアドレスGに要求に参加して、それは(S、G)が接合して、まさか、a(*、G)が接合するaを開始しなければなりません。
- 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.
- ルータ(すなわち、直接付属しているホストがいないルータ)が伝播してはいけないバックボーン(*、G)はSSMアドレスの範囲のグループアドレスのために接合します。
- Rendezvous Points (RPs) MUST NOT accept PIM Register messages or
(*,G) Join messages in the SSM address range.
- ランデブーPoints(RPs)がPIM Registerメッセージを受け入れてはいけない、さもなければ、(*、G)はSSMアドレスの範囲にメッセージを接合します。
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].
完全なPIM-SMプロトコルの機能性の小さい部分集合だけがSSMサービスモデルをサポートするのに必要であることに注意してください。 この部分集合は明らかに[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つです、少なくとも予見できる未来に両方のモデルが使用されると予想されて。 SSMはSSMアドレスの範囲への唯一のサービスモデルです--この範囲のための正しいプロトコルのふるまいは[5]で指定されます。 非SSMアドレス(受信機は(*、G)を発行できる)が及ぶので、サービスモデルが提供されるASMはマルチキャストデータを受け取るという要求に参加します。 また、受信機が発行できる、(S、G)は非SSMアドレスの範囲に要求に参加します。 しかしながら、その場合、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.
別の相互運用性問題は、MSDPプロトコルが複数のドメイン中のマルチキャストソースを発見するのが関係があります。(プロトコルはPIM-SMランデブーポイント(RPs)の間で使用されます)。 MSDPがSSMに必要ではありませんが、ASMがサポートされるなら、必要です。 [9]はMSDPがネットワークがSSMサービスモデルをサポートする能力を妨げないのを確実にするのを助けるという操作上の推薦を指定します。 明確に、[9]は、RPsが受け入れてはいけませんし、起因してはいけませんし、また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)まで手伝うことができます。 しかしながら、保証を全く提供しません。
Bhattacharyya Informational [Page 9] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[9ページ]のRFC3569 SSM2003年7月の概要
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ボーエン、エド・クレス、ブライアン・ライルス、ティモシー・ロスコー、ヒューHolbrook、Isidor Kouvelas、トニーSpeakman、およびNidhi Bhaskarに感謝申し上げます。 Mujahidカーン、テッド・シーリ、トムPusateri、ビル・フェナー、ケビンAlmeroth、ブライアン・レヴィン、ブラッド・カイン、ヒューLaMaster、およびペッカ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.
[1] ホルブルック、H.、およびD.R.Cheriton、「IPマルチキャストは以下にチャネルを開設します」。 SIGCOMM1999の議事の「大規模な単独のソースアプリケーションのサポートを言い表してください。」
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
2236, November 1997.
[2] w.フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。
[3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
"Internet Group Management Protocol, Version 3.", RFC 3376,
October 2002.
[3] カイン、B.、デアリング、S.、Kouvelas、I.、およびA.Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC3376、10月2002日
[4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for
Source-Specific Multicast", Work In Progress.
[4] 「ソース特有のマルチキャストのためのIGMPv3を使用して、MLDv2」というホルブルック、H.、およびB.カインは進行中で働いています。
[5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
Work in Progress.
[5] 「IPのためのソース特有のマルチキャスト」というホルブルック、H.、およびB.カインは進行中で働いています。
[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.
[6]のデアリング、S.、およびD.Cheriton(「データグラム・ネットワークと拡張LANにおけるマルチキャストルート設定」、8(2): コンピュータシステムズ、85-110のACMトランザクション)は1990がそうするかもしれません。
[7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast
Routing", IEEE/ACM Transaction on Networking, pages 153-162,
April 1996.
[7] デアリング、S.他、「広い領域マルチキャストルート設定のためのPIMアーキテクチャ」、Networking、153-162ページ、1996年4月のIEEE/ACM Transaction。
[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.
[8]Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様」、RFC2362、1998年6月。
[9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress.
[9] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、処理中の作業。
Bhattacharyya Informational [Page 10] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[10ページ]のRFC3569 SSM2003年7月の概要
[10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent
Multicast - Dense Mode (PIM-DM): Protocol Specification
(Revised)", Work In Progress.
[10] アダムス、A.、ニコラス、J.、およびW.Siadek、「プロトコルの独立しているマルチキャスト--濃いモード(PIM-DM):、」 「プロトコル仕様(改訂される)」、処理中の作業。
[11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997.
[11]Ballardie、A.、「コアベースの木(CBT)のマルチキャストルート設定アーキテクチャ」、RFC2201、1997年9月。
[12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[12] マイヤー、D.、「AdminstrativelyはIPマルチキャストを見た」BCP23、RFC2365、1998年7月。
[13] Farinacci, D. et al., "Multicast Source Discovery Protocol",
Work In Progress.
[13] ファリナッチ、D.他、「マルチキャストソース発見プロトコル」、Work In Progress。
[14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
Address Allocation Architecture", RFC 2908, September 2000.
[14] ターレルとD.とハンドレーとM.とD.Estrin、「インターネットマルチキャストアドレス配分構造」、RFC2908、2000年9月。
[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.
[15] Diot、C.、レヴィン、B.、ライルス、B.、カセム、H.、D.Balensiefen、およびIEEEの「IPマルチキャストのための問題が修理する展開と構造」はマルチキャスト(2000年1月)に雑誌の増刊をネットワークでつなぎます。
[16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions
for Multicast Source Filters", Work in Progress.
[16] 「マルチキャストソースフィルタのためのソケットインタフェース拡大」というターレル、D.、フェナーB.、およびB.クインは進行中で働いています。
[17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53,
RFC 3180, September 2001.
[17] マイヤーとD.とP.Lothberg、「233/8インチ、BCP53、RFCに3180、2001年9月を記述するGLOP。」
[18] Levine, B. et al., "Consideration of Receiver Interest for IP
Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[18] レヴィン、B.他、「IPマルチキャスト配送に関する受信機関心の考慮」、IEEE Infocom、2000年3月のIn Proceedings。
[19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery for IPv6", RFC 2710, October 1999.
[19] デアリングとS.とフェナーとW.とB.ハーバーマン、「IPv6"、RFC2710、1999年10月のためのマルチキャストリスナー発見。」
[20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2)
for IPv6", Work In Progress.
[20] R.etビーダ、アル、「IPv6"、進行中の仕事のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
[21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast
Addresses", RFC 3306, August 1992.
[21] ハーバーマンとB.とD.ターレル、「ユニキャスト接頭語ベースのIPv6マルチキャストアドレス」、RFC3306、1992年8月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[22] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[23] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[23] ハーバーマン、B.、「IPv6マルチキャストアドレスのための配分ガイドライン」、RFC3307、2002年8月。
Bhattacharyya Informational [Page 11] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[11ページ]のRFC3569 SSM2003年7月の概観
[24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast
Routing -- Protocol Specification", RFC 2189, September 2001.
[24]Ballardie、A.、「コアベースの木(CBTバージョン2)のマルチキャストルート設定--仕様を議定書の中で述べる」RFC2189、2001年9月。
[25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[25] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000.
[26] ベイツ、T.、Rekhter、Y.、チャンドラ、R. and D.キャッツ、「BGP-4インチのためのMultiprotocol拡張子、RFC2858、2000年6月。」
[27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[27] マイヤー(D.)は「233/8インチ、RFC3138、2001年6月に課題を広げました」。
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.
[28] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
11. Contributors
11. 貢献者
Christophe Diot Intel EMail: christophe.diot@intel.com
クリストフDiotインテルEMail: christophe.diot@intel.com
Leonard Giuliano Juniper Networks EMail: lenny@juniper.net
レオナルドジュリアーノ杜松ネットワークはメールされます: lenny@juniper.net
Greg Shepherd Procket Networks EMail: shep@procket.com
グレッグ羊飼いProcketネットワークはメールされます: shep@procket.com
Robert Rockell Sprint EMail: rrockell@sprint.net
ロバートRockell短距離競走メール: rrockell@sprint.net
David Meyer Sprint EMail: dmm@1-4-5.net
デヴィッドマイヤー短距離競走メール: dmm@1-4-5.net
John Meylor Cisco Systems EMail: jmeylor@cisco.com
ジョンMeylorシスコシステムズEMail: jmeylor@cisco.com
Brian Haberman Caspian Networks EMail: bkhabs@nc.rr.com
ブライアン・ハーバーマンCaspianのネットワークはメールされます: bkhabs@nc.rr.com
Bhattacharyya Informational [Page 12] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[12ページ]のRFC3569 SSM2003年7月の概観
12. Editor's Address
12. エディタのアドレス
Supratik Bhattacharyya Sprint
Supratik Bhattacharyyaは全速力で走ります。
EMail: supratik@sprintlabs.com
メール: supratik@sprintlabs.com
Bhattacharyya Informational [Page 13] RFC 3569 An Overview of SSM July 2003
Bhattacharyyaの情報[13ページ]のRFC3569 SSM2003年7月の概観
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Bhattacharyya Informational [Page 14]
Bhattacharyya情報です。[14ページ]
一覧
スポンサーリンク
