INTERNET
インターネット最新テクノロジー：第 40 回

IPマルチキャストは放送にブロードバンド時代のコンテンツインフラ

マルチキャスト配信技術

限りなく近い通信技術
現在、インターネットで利用されているIP
による通信は、サーバーとクライアントが一対一でデータの送受信を行う、ユニキャストと呼ばれる通信方法となっている。これに対して、1台のサーバーと多数のクライアントがCATVインターネットやADSLなど、日本でもブロードバンドインターネットの普及が進んでい同時に通信を行う形の通信をブロードキャスる。しかし、アクセスラインが高速になったとしても、そこに広帯域のコンテンツを配信

トと呼ぶ（1）。

するのは容易なことではない。ユーザーからのアクセスが殺到すれば、たちまちサーバーがブロードキャストによるコンテンツ配信のパンクしてしまうからだ。こうした問題の解決策として期待されているのが、IPマルチキャ

イメージは、テレビやラジオとよく似ている。

スト技術を用いたコンテンツ配信である。

送り手側は一方的にデータを送出し、受信者

福田 築 宇宙通信（株）（IPでは特定のアドレス）に合わせることで視は見たいときや聞きたいときにそのチャンネル聴できるようになる。
こうした点で、ブロードキャストはBSデータ放送などに使用されている放送型の配信と似ているが、放送型の配信は受信者（テレビ端末）を特定できないため「不特定多数」への配信となるのに対し、ブロードキャストではユーザーが特定できるため「特定多数」への配信となるところに違いがある。
ブロードキャストは、配信メディアが無線やLAN環境のようにシェアード（共有）メデ
ィアであれば簡単に構築できる。一方、インターネットは複数のLANがルーターで接続された複雑なネットワークであり、むやみにブロードキャストすると無駄なトラフィックでネットワークが溢れてしまう。このため、ルーター間では必要なところにだけデータが配信いへん難しい問題を抱えている。こうした問され、最終的な目的地のLAN 上だけでブロ題を解決すると期待されているのが、マルチードキャストされるような仕組みが必要となキャスト配信技術である。マルチキャスト配る。これを行うのがIP マルチキャストの枠組

では、900 万人とい信技術は、ネットワーク層におけるIP マルチみである。

う記録的なアクセス数を達成した。しかし、キャスト技術と、トランスポート層におけるルーター間のマルチキャストパケットをルーその一方であまりにアクセスが殺到したため、ストリーム配信プロトコルや、確実にデータティングするためのプロトコルは複数提案さ十分な品質で映像を届けることができなかっを送り届けることを保証するプロトコルなどれているが、現時点ではPIM（Protocolた点が指摘されている。このように現在のイから構成される。以下では、具体的にそれぞIndependent Multicast）が一般的に使用

ンターネットでは、ブロードバンドの時代にれの技術やプロトコルについて解説する。

されている。また、ルーターが自分の配下にマルチキャスト配信技術とは先日、MSNが行ったマドンナのインターネットライブ中継

Jump 01必要となる「ネットワークの効率的な使用」

Jump 01

madonna.msn.co.jpと「スケーラビリティーの確保」という、た376 INTERNET magazine 2001/2

マルチキャストを受信するユーザーがいるかどうかを認 識 するためにI G M P （ I n t e r n e t

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

Group Management Protocol）が使用さを再送要求するといったARQ との組み合われる。マルチキャストを受信するソフトはせや、これにさらにカルーセル方式を組み合

IGMP をLAN 上にブロードキャストすることわせることで信頼性を向上させている（3）。

で、上位のルーターにマルチキャストに参加一方、ストリーミングコンテンツを配信すする意思表示を行う。この信号を受け取ったるプロトコルは、アップル社のQuickTime、ルーターはさらに上位のルーターに信号を送Real Networks社などで採用されているRTP

信することでマルチキャストの配信ツリーが（RFC1889）や、マイクロソフト社のMMS構成される（2）。

IPマルチキャストにおけるパケットごとに送達確認を行う

ルーター

確実性は高いが、帯域の利用効率が悪くサーバーへの負荷も大きい

ルーター

ユニキャスト

データの信頼性確保

受信者と同数のストリームを送出する

TCP/IP における通信では、受信者側がきちんとデータを受け取っているかどうかを送
信 者 側 に通 知 する、 A R Q （ A u t o m a t i cRepeat Request）と呼ばれる仕組みを使っコンテンツサーバールーターている。しかし、マルチキャスト配信においクライアントては、大勢のユーザーに一斉同報する性格上、送達確認は行わない（送りっぱなし）

こうした確認を行うことは事実上不可能である。また、たとえばデータ放送や衛星回線のルーターがストリームを複製して送出する

マルチキャストルーター

受信者によらず1ストリームだけを送出

ように、戻り回線を利用しない通信の場合も、ARQの仕組みを使うことはできない。こうしたこともあって、IP マルチキャストではトランスポートプロトコルとしてパケットレベ

コンテンツサーバー

ルーター

ルでの送達確認を行わないUDP が使用される。送達確認を行わずに高信頼性を確保するためには、アプリケーションが独自にプロトコルを実装する必要がある。

確実性は低いが、帯域の利用効率は高くサーバーへの負荷も最小限

ルーター
クライアント1 ユニキャストとマルチキャストの違い

データ放送などでは非常に小さな文字情報
マルチキャスト配信のリクエストは、上位のルーターへと伝えられていく。
これにより、データはユーザーのいるルーターのみに流れる配信ツリーが構築される。などを送信することが多いので、カルーセル（回転木馬）方式を採用している。つまり、何回か同じデータを送りつづけることで信頼ルーター性を向上させる方式である。しかし、ある程度大きなファイルであればカルーセル方式では無駄が多くなってしまうため、効率を上げマルチキャストへの参加要請（IGMP）るための工夫が必要となる。デジタル衛星放マルチキャスト
データ送などでは、カルーセル方式に加えて、デー
タに冗長ビットを付加しておいて、少々パケルーター

ルーター

ルーター

ルーター

ルーター

ットが損失してもデータが回復されるようにFEC（Forward Error Correction）を使用している。大きなコンテンツを複数のセグメントに分割し、届かなかったセグメントだけ

2 マルチキャストの配信ツリー

インターネットマガジン／株式会社インプレスR&D

UDP（ユー・ディー・ピー／ User Datagram Protocol）：インターネットの標準プロトコルであるTCP/IPでは、トランスポート層（データ転送を行う部分）のプロトコルとしてTCPまたはUDPを用いる。UDPは誤り訂正や再送要求などの機能を持たないため、TCPに比べて信頼性は低いが、高速で効率の良いデータ転送が可能となる。
©1994-2007 Impress R&D

INTERNET magazine 2001/2377

が一般的に使用されている。RTPはアプリケ

ストとの親和性が高く、マルチキャスト配信ーションが使用するための基本的な枠組みだで必要となる高信頼性プロトコルをいち早くけが決められているプロトコルで、RTP 自体開発して使用してきたという実績があるから

2）ネットワークニュースの配信（NNTP）にはパケットが順番通りに届くことを保証すである。衛星通信を利用したIP マルチキャス

3）ブロードバンドコンテンツのキャッシュるなどの、何らかのQoSを保証する機構は備

トサービスの例としては、日本では宇宙通信わっていない。これらは、より下位のプロトのHitPops

コルにゆだねられている。RTP のパケットにMegaWave Select

1）映像・オーディオのストリーム（RTP/RTCP、MMS）

ストリームの場合は放送的にデータを送り、 N T T サテライトの出すため、高信頼性は要求されない。逆に、などが挙げられニュースやキャッシュの場合には、元のデーはシーケンス番号やタイムスタンプが押される（4）。ここでは、HitPops を例にマルチタファイルを復元するために高い信頼性が求ているので、アプリケーション側で何らかのキャストデータ配信技術がどのように利用さめられる。

制御を行うことが必要となる。

れているのかを説明する。

Jump 02

Jump 03

HitPops はブロードバンドインターネット

Jump 02www.hitpops.co.jp

Jump 03

www.megawave.ne.jp

においてコンテンツ提供者とエンドユーザー衛星を利用したマルチキャストはをつなぐプラットフォーム機能を提供するサコンテンツ配信に有利マルチキャスト配信技術のービスである。このサービスの中核をなすの標準化状況

大容量のコンテンツをインターネット上でが 、 Content Delivery and Distribution

多数のユーザーに伝送するためにはIP マルチNetwork（CDDN）である。CDDN は、ネIP マルチキャストのルーティングプロトコキャストが有効である。しかし、現状ではIP

ットワークのエッジ（CATV 局やADSL を提ルは、マルチキャスト配信のツリーを構築すマルチキャストに対応しているネットワークは供するプロバイダーの設備）に置かれたサーる際に異なる事業者間をまたいで接続するこ限られており、インターネットにすぐにそのまバーに対して、衛星により直接ブロードバンとになるが、その場合に困難な状況が生じやま流せるわけではない。現在、日本ではIIJやドコンテンツを配信し、オンデマンドコンテすい。異なる事業者間で相互にマルチキャス

UUNet などがマルチキャストサービスを行っンツであればキャッシュさせておく。これによトルーティングを行うためのプロトコルとしてているが、こうしたネットワークに接続しなり、500kbpsを超える高品質なストリーミン

は、 BGMP（ Border Gateway Multicast

ければ、IP マルチキャストのツリーには参加グを使用したウェブキャスト（インターネッ

Protocol）がIETF のドラフトとして策定さできない。

ト放送）や、コンテンツのダウンロードを瞬れ、日本においてはIIJ を中心とした非営利時に行うことが可能となる。

団体のJ/Splash

そこで登場するのが通信衛星である。もともと通信衛星はそのメディアとしての性格上ブロードキャスト環境であり、IP マルチキャJump 04

において実証試験が行われている。

HitPops は現時点ではプロトコルベースでストリーム配信においては、新しいエンコ次の3 サービスを提供している。

ーディング方式の採用、効果的なプレゼンテーションを行うための映像とウェブなどのアデータが正しく届いたかを確認

ユニキャストプリケーションの同期、といった機能拡張がデータ個々のアプリケーションで行われており、それぞれ標準を狙って激しい競争が行われている。

「データが正しく届いた」ことを通知（またはデータの再送要求）

ユーザー

コンテンツサーバー
誤り訂正符合マルチキャスト

データ

データ

マルチキャストにおける高信頼性データ配
信 技 術 に関 しては、 IETF において RMT

データが正しく届いたかを確認（ある程度のエラーは誤り訂正符号により自己修復）（Reliable Multicast Transport）ワーキン
ググループが設置され、高信頼性のデータ配どうしても回復できなかっ再送を要求すたデータのみる（戻り回線がある場合）

コンテンツサーバー

データ

信の枠組みが活発に議論されている。現在、RFC2887 と15 個のIETF ドラフトが提出さデータれている。基本的な議論の流れとしては、信同じデータを何回も送信することでエラーの発生率を下げる

頼性の要求はそれぞれのアプリケーションやユーザー使用するメディアにより多岐にわたるため1つ3 データの信頼性の仕組みのプロトコルでカバーできない。このため、共D

378 INTERNET magazine 2001/2

インターネットマガジン／株式会社インプレスR&D

QoS（キューオーエス／ Quality of Service）：ネットワークで、ある特定の通信を行うために帯域を確保して、一定の通信速度を保証する技術。音声や動画の配信、テレビ電話などの、通信の遅延が気になるサービスでは重要とされている。
©1994-2007 Impress R&D

通に利用できる非常に小さな範囲に限定されザーのPC へ直接届けることが可能となるとたモジュール（ブロック）のAPI を規定し、考えられる。ただし、現在のマルチキャスト

要求に応じてブロックを組み合わせればプロデータ配信の方法では、高信頼性を確保するトコルを構築できるようにすることを目的とのにARQを併用しているため、ユーザー数がしている。併せて、どのようにブロックを組増加するとユニキャストと同様にネットワー

み立てればプロトコルが構築できるのか、そのクの混雑が問題になる可能性がある。これは、組み合わせ例も提示されることになっている。

マルチキャスト配信技術が今後解決すべき課

本稿では、ALC（Asynchronous Layered題である。

Coding）を取り上げる。このプロトコルのさらに、高信頼性データ配信の仕組みをマ

目的は多数のユーザーにデータを確実に届け

ルチキャストだけでなくユニキャストにも応用るということであり、このためには、ネットワすることが期待できる。

ークの信頼性や、たとえば突然停電したとい

TCP の効率は「回線の帯域×RTT」に従った受信者側の状況によらないことが望ましって悪くなる。今後、光ファイバーが家庭にい。ALC では、まず、受信側が勝手に（非引かれるようなことになれば、帯域は増えて同期に）チャンネルに参加したり（TUNE-もTCP の効率が悪いため、その帯域を十分IN）抜けたり（DROP-OUT）することがでに使い切ることができないという状況が生じきる仕組み（TIDO モデル）を提供する。こかねない。UDPベースの高信頼性データ配信

れにより、受信側がなんらかの理由でダウンの仕組みを取り入れると、符号化の効率にもロードが中断されても、チャンネルが存続し依存するが、効率良くデータ配信を行うことていれば、再度そのチャンネルに参加し、必が可能となると予想される。

要なパケットをダウンロードすればデータをまるごと復元することが可能となる。また、受信側が複数のチャンネルを受信できるようになっているため、同じコンテンツを複数のチャンネルに分けて送信することができる。これにより、ネットワークが輻輳している場合は1つのチャンネルだけ、良いときには複数のチャンネルを受信するといったことが可能となる。現時点ではALCのAPI実装としてマイクロソフト社のF-castがあるが、商用サポーCATV局トは行われていない。
Jump 04

ブロードバンド
コンテンツ

通信衛星

www.iijnet.or.jp/ipmulticast/jsplash/

コンテンツサーバー（子）マルチキャスト配信技術のユーザー

ブロードバンド
コンテンツ

応用範囲と今後の課題

インターネット

マルチキャスト配信技術の標準化や商用化
ADSLプロバイダー

はいまだ道半ばであるが、非常にホットな技

コンテンツサーバー（親）術開発分野であり、その応用範囲は広い。まブロードバンド向けの大容量コンテンツを、通信衛星を使ってCATVやADSLのプロバイダーのサーバーに送る。

コンテンツサーバー（子）た、ハードディスクの低廉化や、デジタルコンテンツにおける著作権保護の仕組みの標準

ユーザー
コンテンツは各プロバイダーにおかれたサーバーからユーザーに配信される。

4 衛星を利用したコンテンツのマルチキャスト配信化が進めば、コンテンツは何百万というユー`

インターネットマガジン／株式会社インプレスR&D

RTT（アール・ティー・ティー／ Round-Trip Time）：1 つのパケットが送信元から宛先まで行き、再び戻ってくるまでにかかる時間のこと。宛先でそのパケットを処理して、応答のパケットを返すまでの時間も含まれている。
©1994-2007 Impress R&D

INTERNET magazine 2001/2379

［インターネットマガジン バックナンバーアーカイブ］ ご利用上の注意
この PDF ファイルは、株式会社インプレス R&D（株式会社インプレスから分割）が 1994 年～2006 年まで発行した月刊誌『インターネットマガジン』の誌面を PDF 化し、「インターネットマガジン バックナンバーアーカイブ」として以下のウェブサイト「All-in-One INTERNET magazine 2.0」で公開しているものです。

http://i.impressRD.jp/bn
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
z 記載されている内容（技術解説、URL、団体・企業名、商品名、価格、プレゼント募集、アンケートなど）は発行当時のものです。
z 収録されている内容は著作権法上の保護を受けています。著作権はそれぞれの記事の著作者（執筆者、写真の撮影者、イラストの作成者、編集部など）が保持しています。
z 著作者から許諾が得られなかった著作物は収録されていない場合があります。
z このファイルやその内容を改変したり、商用を目的として再利用することはできません。あくまで個人や企業の非商用利用での閲覧、複製、送信に限られます。
z 収録されている内容を何らかの媒体に引用としてご利用する際は、出典として媒体名および月号、該当ページ番号、発行元（株式会社インプレス R&D）、コピーライトなどの情報をご明記ください。
z オリジナルの雑誌の発行時点では、株式会社インプレス R&D（当時は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが、すべての情報が完全に正確であることは保証できません。このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

このファイルに関するお問い合わせ先
All-in-One INTERNET magazine 編集部
im-info@impress.co.jp
Copyright © 1994-2007 Impress R&D, an Impress Group company. All rights reserved.