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ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SeaHouse (Sleipnir拡張機能)

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る