マルチキャスト - みる会図書館

1. UNIX MAGAZINE 2003年1月号

第 - ー 6 マルチキャスト配像応するために各地にキャッシュ・サーバーを設置するのでは、巨額の柑殳資が必要になり、サーバーの数か増えればそれだけ運用コストも増大します。これでは、ビジネスとして成り立ちません。ライフ酒己信があまり成功していない理由の 1 つでしよう。一方、ライプ配信ではなく、アーカイプされたコンテンツの配信に関しては、 CDN (Content Delivery Net- work) と呼はれる技術によって問題か解決されようとしています。 CDN では、キャッシュ・サーバーや糸各制御など、さまざまな技術を組み合わせて効率的に広帯域の配信ができるようにネットワークを言します。多くの企業が CDN の実現に取り組んでおり、技術の組合迂方は各社各様です。それでは、ライプ中継には CDN のような革辛廂勺な仕組みはないのでしようか ? ライプ中継では、同しデータを大阯のユーサーに同時に配信します。このような目的には、 IP ュニキャストよりも IP マルチキャストが適しています。 IP マルチキャストを使えば、 9 , 000 人のユーサーにテレビ施並みといわれる 8Mbps のビットレートの映像を邱赭己信しても、配信サーバー側に 8Mbps の回線を用意するだけですみます。また、 9 , 000 人を対象とした場合の配信サーバー側の負荷は、 1 人に配信する場合とまったく変わりません。 IP マルチキャストでは、サーバーから送信したデータが途中経路のルータで適切にコピーされ、受信者のいるネットワークに自動的に転送されていくため、配信サーバー自体への負荷は低くなります。 IP マルチキャストによるライプ配信であ川ま、理論 - ヒは 1 台の配信サーバーで無限大のユーサーに配信できます。まさにライフ配信にうってつけの技術ですが、 1 つ落し穴があります。 IP マルチキャストて配信するには、配信サーバーと受信者端末のあいだのルータが IP マルチキャストに対応している必要があるのです。 IPv4 ()P version 4 ) の世界では、 IP マルチキャストの仕オゞ IPv4 の仕様よりもあとで決まったことや、マルチキャスト糸響各制御ワ。ロトコルか研究段階だったことなどが景グし、一部の積極的なべンダーしか対応していないのカ躾情です。「なあーんだ。 IP マルチキャストは、絵に描いた餅か」と落胆することはありません。 IPv6 ()P version 6 ) で UNIX MAGAZINE 2003.1 は、 IP マルチキャスト ( 以下、、、 IPv6 マルチキャスト " と表記します ) カ材票準の仕様として採り入れられる方向にあります。大手のべンダーは IPv6 マルチキャストへの対応を表明していますし、すでに対応製品を出荷しているべンダーもあります。ただし、べンダーの対応をしっと待っているだけでは IPv6 マルチキャストの普及は望めません。コンテンツ提供者、 ISP 、ユーサー用端末のべンダーが、足並みを揃えて IPv6 マルチキャストの利用をイ眉止していく必要があります。以下に紹介する朝日放送の IPv6 マルチキャスト配信実験では、 IPv6 マルチキャストに積杣勺なべンダーの協力を得て、ライフ紀信サーバーから一殳ューサーの端末まで IPv6 マルチキャストを用いてライフ、映像を妾配信しました。コンテンツ提供者から端末べンダーまで、すべてがマルチキャストに対応することで、従来の技術では困難だった広帯域ライフ配信を面に実現できました。今回の実証実験では、 2002 年 8 月におこなわれた第 84 回全国咼校野球選手権大会を IPv6 マルチキャストを用いて中継しました。私たちは、この実験の目的として以下の 2 点を考えました。・実験ネットワークではなく、商用ネットワークの設備を使って IPv6 マルチキャスト配信ができることを実証する。朱な受信工竟を構すに、一勺なユーサー宅のネットワークへマルチキャスト配信する。 IP マルチキャスト技術に関する研究は IPv4 の時代から続けられており、もちろん、過去にもマルチキャスト配送実験が実施されています。それらと今回の実験の違いが上記の 2 点です。過去の多くの実験では、マルチキャストの醋医に実験専用のバックポーンを利用しています。これに対し、今回は実際に顧客のトラフィックが充れている商用ネットワークを使いました。マルチキャストによる配信サービスといっても、事業化を考えるならは、実験ネットワークではなく 4 P 6 マルチキャスト配信実験の目 181

2. UNIX MAGAZINE 2003年1月号

置 -4 6 マルチキャストを価運用に使っているネットワーク上で酒己信できなければ未がありません。これまで、マルチキャスト配信というと、しよせんは箱庭のなかでの実験ではと思っていた方も多いでしよう。この実証実験の結果をご覧になることで、マルチキャスト酉占医か次の段階へ進んでいることを実感していただければさいわいです。もう 1 つは、、、ラストワンマイル間題 " への 1 つの解答です。過去の多くの実験では、マルチキャストの配信先を特設展示場や研究室のネットワークに限定していました。一般家庭へは、マルチキャストによる情報の送信か不可能だったからです。しかし、いまではいわゆるプロードバンド・ルータを使って家庭内にネットワークを構築しているューサーもいます。通常、 IPv4 の安価な契約では IP アドレスを 1 つしかもらえません。そのため、多くのユーサーは家庭内ネットワークを構築する際に NAT (Network Address Trans- lator) を使います。そもそも、 IP マルチキャストは NAT を越えて利用できません。 NAT 竟で IP マルチキャストを実現するには、マルチキャストの制徊臑号を転送したり、グローバル・ネットワークとプライベート・ネットワークとのあいだで、マルチキャスト・バケットのヘッタ変換をおこないつつ中幻するといった、通常とは異なる IP マルチキャスト処理か必要になります。ところが、すくなくとも私たちの知るかぎりでは、そのような機能を実装しているプロードバンド・ルータはありません。その結果、マルチキャストを利用するサービスは登場す、サーピスがないためにルータベンダーも採用しないという悪循環になっています。一方、 IPv6 ではアドレス数に事実上制限がないため、家庭内でもグローバル・ネットワークを構築することがー勺な利用形態になると考えられます。家庭がグローバル・インターネットの一部となった場合、そこからマルチキャストを用いた送受信をしたいという要望が当然のように出てくるでしよう。現在、 IPv6 に対応したプロードハンド・ルータがいくつか登場していますが、残念ながらマルチキャストをサポートした製品はほとんどありません。しかし、 IPv6 では NAT か不要になるため、一殳のルータと同しく叫屯にマルチキャスト機能を実装するだけでよく、 IPv4 のように特別なことをする必要はありません。プロードバンド・ルータは、家庭とインターネットをつな 182 表 1 糸懿胸プロトコルと引ヒ方式 NTSC / コンポジット入力 ( 朝日放送 ) 映像 / 音声マルチキャスト PIM-SM 経路制御映像符号イヒ方式 MPEG 4 standard profile 映像 1Mbps 2Mbps ( 期間限定 ) 音声 128Kbps 表 2 剣こ使用した機材などバックポーン IIJ バックポーン (IIJ) バックポーン・ルータ IX5005 (NEC) 工ッジノレータ . 工 . ンコーーダ、マルチキャストピューア IX1010 (NEC) SEIL (IIJ) KAME OKI Media Encoder ( 沖電 0 OKI Media Server ( 沖電安 0 OKI Media Player ( 沖電気 ) ぐ要です。ここでマルチキャストが分断されてしまうと、 IPv4 のときと同しように、マルチキャストを置き去りにしたまま IPv6 のみか及するといったことになりかねません。今回の実証実験では、マルチキャストの受信に対応したプロードバンド・ルータや、 ( 万人向けといえるほど安くはありませんか ) 安価なルータを使い、ラストワンマイルのマルチキャスト化を実現しました。実験に用いた糸響各制御プロトコルと映像 / 音声の符号化方式を表 1 に、利用した機材を表 2 に示します。実験では、マルチキャストの経路制御として PIM-SM (Protocol lndependent MuIticast-Sparse Mode) を用いました。 PIM-SM はネットワーク上の 1 つのルータをランデブー・ポイントに設定し、ノードからの参加要求をいったんここで受理します。この方式にはマルチキャスト糸青報の構築が簡単になるという利点がありますが、ランテプー・ポイントに負荷か集中してしまいます。この欠点を克服した PIM-SSM (Source Specific ⅲー ticast) と呼ばれる経路制御肢術もあり、こちらはランデプー・ポイントを設ける必要がありません。ただし、末端のノードが PIM-SSM に必要な情報を提供する必要があります。技勺には、 PIM-SM よりもルータに負荷のかからない PIM-SSM を使ったほうがよいのですが、実験の時点では末端ノードで PIM-SSM に対応できる製品が験の概 UNIX MAGAZINE 2003.1

3. UNIX MAGAZINE 2003年1月号

- : 6 マルチキャスト配像なく、参加したユーザーが十数名程度ということもあり、 PIM-SM でも -- ト分と判断しました。映像 / 音声の符号化には MPEG 4 を利用しました。プロードバンド化が進み、一般ューザー向けの広帯域回線が安価になったとはいえ、高品質の映像 / 音声を生のまま流せるほど広くはありません。ストリーミングに対応した、高圧縮の符号化をおこなう必要があります。 Win- dows Media や RealVideo 、 QuickTime などの方式も検討しましたが、実験の時点では残念ながらどれも IPv6 に対応していませんでした。今回は、 IPv6 マルチキャストへの対応を積極的に進めている沖電気から、開発中の IPv6 マルチキャスト対応コードが組み込まれた MPEG 4 配信ソフトウェアとビューアを借用することにしました。配信帯域は、 1Mbps の映像に 128Kbps の音声です。最近でこそ 1Mbps のストリーミング・コンテンツも目にするようになりましたが、ほんの数年前までの感覚では考えられないほどの広帯域です。もっとも、現在でもハ lbps のストリームをユニキャストでライプ中継しようとすると、回糸 ) 費用だけで巨額になります。まして、数百人が同時に視聴することを考えると、サーバーの負荷は計り知れません。しかし、今回はマルチキャストによる配信なので、 1Mbps のストリームであってもネットワーク本で 1Mbps の帯域しか消費しません。なお、試験的に 2Mbps の映像も配信しましたが、こちらは鄲点の機器橢及では問題が多く、期間を限定した配信としました。実験では、全国に散在するユーサーにマルチキャストで配信するために IIJ の IPv6 バックポーンを利用しました ( 現在、 IIJ の IPv6 ノヾックポーンは IPv6 マルチキャストの運用をしていません ) 。今回は、 NEC の IX5005 を全国に配置し、そのあいだで IPv6 over IPv4 を用いて孑鬮以的に IPv6 マルチキャスト・バックポーンを構築しています。工ッジルータは、以下の 3 不鶤頁を利用しました。 1 つ目は NEC の IX1010 です。 IX1010 はマルチキャスト経路制御に対応していませんが、 MLD (MuIticast Listener Discovery) を中継することで擬似的にユーザ・ネットワークにマルチキャスト受信竟を提供します。今回の実験のように、ストリーム配信の受信に限定した用途であれは有効なガ去てす。 2 つ目は IIJ の SEIL です。製品版の SEIL はマルチ UNIX MAGAZINE 2003 ユキャスト経路制御をサポートしていませんが、今回は実験用に PIM-SM の糸響各制徊職能を組み込んだものを利用しています。 3 つ目は KAME です。いわゆる PC ルータとして、 PIM-SM による経路制御をおこないます。 SEIL と KAME はマルチキャスト経路制御に対応しているので、ユーザー・ネットワーク側からインターネットに向けてマルチキャストによる配信も可能です。ただし、今回は受信のみに利用しました。図 1 か実験ネットワークの構成です。中央に位置する 4 台の IX5005 で IPv6 マルチキャスト・ノヾックポーンを構成しています。各 IX5005 のあいだは、実際には IPv6 。 verIPv4 によるトンネルリンクて接続されています。各 IX5005 の下には、ユーザー・ネットワークが収容されます。ューサー・ネットワークの工ッジルータは、 IX1010 、 SEIL 、 KAME のいすれかを利用します。ユーザーの接続竟は、帯域がもっとも狭いところで ADSL による 1.5Mbps 接続、もっとも広いところで光ファイーによる 1()OMbps 接続です。ューサー・ネットワークには OKI Media Player をインストールした PC が設置され、朝日旒からマルチキャストで配信される中糸央像を受信・表示します。 OKI Media PIayer は Windows 2000 上てカく MPEG 4 ビューアで、 IPv4 ユニキャストおよび IPv4 マルチキャストに対応しています。今回の実験では、開発中の IPv6 マルチキャスト対応版をインストールしました。ューサーネットワークの環境に応して、それぞれのネットワークで 1 ~ 3 台の OKI Media PIayer か下力しています。図 1 の左 - ヒが、映像配信元となる朝日施の譓蒲です。朝日放送から NTSC 形式て提供される映像を OKI Me- dia Encoder に入力し、 MPEG 4 に変換します。変換された配信データは OKI Media Server に渡さオ L 、そこからマルチキャスト・アドレス宛に中幻されます (OKI Media Encoder と OKI Media Server は、どちらも Windows 2000 上でカきます ) 。 OKI Media Server から送信されたマルチキャスト・バケットは、各 IX5005 のマルチキャスト経路情報に従ってユーサー・ネットワー 183

4. UNIX MAGAZINE 2003年1月号

- : 6 マルチキャスト配像 Ⅸ 1010 Ⅸ 5005 Ⅸ 1010 Ⅸ 5005 Ⅸ 5005 ( 福岡 ) ( 札幌 ) 旧旧 v6 マルチキャスト・ / ヾックポーンクにされます。中張り付けて監視すればよいのですが、現実の運用を考え PIM-SM のランテフ。ー・ポイントは、大阪 IX5005 にるとなんらかの監視システムによる自動監視の仕組みが必設定しました。配信サーーと大反 IX5005 か直結されて要になります。今回は、実運用につなげるために、簡単ないるため、ここをランテフ。ー・ポイントに選ぶのがもっと自動濫視システムを構築しました。も効率的です。各 IX5005 、 SEIL 、 KAME で、 PIM- 今回の自動監視システムは、マルチキャスト配信か継続 SM によるマルチキャスト糸各制御をおこないました。しているかどうかを、配信サーバーを設置したネットワー図 1 では、工ッジルータとして IX1010 が多く使わクでモニターする仕組みになっています。配信先のマルチれています。 IX1010 は、 PIM-SM による糸響各制御はサキャスト・アドレスは事前に分かっているので、ネットワポートしていません。その代わり、 MLD プロキシーの機ークを流れるバケットを孑柑足し、配信アドレス宛のバケッ能を備えており、ユーザー・ネットワークに設置してあトの有無を調べれは、すくなくとも配信サーバーが通切なる OKI Media PIayer が送信する MLD ノヾケットを、アドレスにデータを送信しているかどうかは分かります。ー E 流ルータとなる IX5005 に中継します。つまり、 OKI 図 2 は、朝日放送に設置した配信サーバーのネットワー Media Player が MLD を用いて配信先となるマルチキャク構成を示したものです。配信に利用する OKI Media スト・アドレス宛に参加メッセージを送信すると、 IX1010 Encoder と OKI Media Server は、 Cisco の CataIyst が IX5005 に参加メッセージを送ります。これを受け取っ 3548 を経由して大阪 IX5005 に接続されています。なお、た IX5005 からは、 IX1010 がマルチキャストを受信して 1Mbps 用の配信機材が 1 台なのに対し、 2Mbps 用の配いる IPv6 ノードにみえるため、 IX1010 に対して必要な信機材が Encoder と Server の 2 台に分かれているのはマルチキャスト・バケットを転送します。そして、 IX1010 負荷を分散させるためで、技行勺には 1 台の場合と同様でがⅨ 5005 から送られてきたバケットをユーサー・ネッす。今回の実験では、この構成に SEIL を追加し、監視トワークに転送することで、 OKI Media Player に配信用の小型 PC として利用しました。 SEIL の基本システバケットが届きます。ムは NetBSD で、数は少ないもののネットワーク里のコマンドがインストールされています。今回は、 SEIL にログインして tcpdump を用いて配信用マルチキャスト・アドレス宛のバケットか流れているかを調べる Ruby スクリプトを作成し、これを定期的に実行することて配信が図 1 ネットワークの冓成中継映像朝日放送 OKI Media Encoder OKI Media Server 〇 OKI Media Player Ⅸ 1010 Ⅸ 1010 ・Ⅸ 1010 Ⅸ 1010 、Ⅸ 5005 ( 大阪 ) Ⅸ 1010 Ⅸ 1010 SEIL Ⅸ 1010 = = = = 運用監視体時間やお金がふんだんに使えるのであれば、人間を 1 日 184 UNIX MAGAZINE 2003.1

5. UNIX MAGAZINE 2003年1月号

- 6 マルチキャスト配価映像を配信したところ、 2Mbps の映像は 1Mbps のものこれらのトラフィックの合計は、理論上 2.156Mbps より明らかにプロックノイズカ斗釜減されていました。マル ( = 1 十 0.128 十 0.9 十 0.128 ) で、実際の結果とほば一致しチキャストの場合、配信データの帯域を広くとったときのます。なお、 0.9Mbps のストリームは実験ューザーに配サーバーや回線への負荷は、ユニキャストのときよりも小信するためのものではなく、テスト用のストリームです。さくてすみます。ですから、ノイズの間題は帯域を大きく catalyst から出力されるトラフィックの糸を収集するすることで鮹夬できると考えられます。際、ストリームごとに集計すれはよかったのですが、出力ライフ紀信の品質を評価する場合には、配信遅延の間題されるバケット本て計算してしまったため、グラフ表示は見過ごせません。今回の配イ訓央像は、 MPEG 4 を用いかやや分かりにくくなってしまいました。て符号化しています。遅延を測定するために、通常のテレ 2Mbps による配信開始後は、次の 2 つのストリームがピ施逶の映像と MPEG 4 によるインターネット配信の映流れることになります。像を並べて視聴してみたところ、 1 移程度の遅延しか発生映像 1Mbps/ 音声 128Kbps していませんでした。この程度であれは、ライフ信にも映像 2Mbps/ 音声 128Kbps ート分対応できます。こちらのトラフィックは、理論上 3.256Mbps ( = 1 十総・箚勺によい結果が出ましたが、間題もいくつカって 0.128 十 2 十 0.128 ) で、こちらも実測値とはは致します。います。上下のグラフを上交してもらえば分かるように、参カ睹最初の間題は、マノレチキャストをネ期できるユーサーの範囲か狭かったことです。今回はユーサー宅まてマルチキ数とトラフィックには相関関係がありません。これはマルャストを直接酉当しましたが、残念ながら IIJ の顧客に限チキャストで配信しているためです。これをユニキャストて酒己信しようとすると、今回の場合には、定されています。展昜や実験工竟などの箱庭的な環境からは一歩踏み出したとはいえ、最大規模といわれる 2 万数 1Mbpsx 1Mbps ストリームの受信者数千人以上のライフ信か実現できなけれは、本当にマルチ十 2Mbpsx 2Mbps ストリームの受信者数キャストがユニキャストの代わりになるとはいえません。の帯域が必要になったはすです。しかし、図 3 下に示しもう 1 つは著イ料の間題です。著イ料をイ描矍する方法たとおり、帯域の合計が平均 3Mbps 後半を超えることとして DRM (DigitaI Rights Management) カ甘是唱さはありませんでした。今回は参加者の合言カ十数名と少な 0 000 すたとえ参加者増えも果 0 = 同 = なれていますか : マルチキャストでの実装は難しく、今回は利用していません。しかし、これはライフ配信を有料で実ります。施する場合には避けて通れない譏題です。今後は、 DRM のイ督はみをもっ IPv6 マルチキャストて大規模な有科ライフ紀信かて、きるイ督はみを考える必要があるでしよう。最後になりましたが、今回の実験にご協力いただいた今回の実験のポイントは、システムの負荷と配信データ方々および参加者の皆さんに感謝いたします。この記事の品質です。が、大規模ライフ酒己信実現のための一助となればさいわい今回、配信サーバーの処理負荷は測定していませんが、です。トラフィック・グラフから分かるように、視聴者か増えて ( かたおか・くにお、しま・けいいち IIJ) も回線に負荷をかけすに配信することかできました。映像の品質については、動きカしい場面で MPEG 特有のプロックノイズか若下・ E しましたが、それ以外の場面では、テレピ放送の画面と並べないかぎり、インターネット配イ訓央像だとは気づかない稠隻の高い品質て配信できました。プロックノイズは帯域を大きくすることで軽減されます。今回、短時間ですが 1Mbps と 2Mbps で同しこ = = 二まとめと今後の課題 = 二 = 187 UNIX MAGAZINE 2003.1

6. UNIX MAGAZINE 2003年1月号

3 マルチキャスト眠価図 3 言者数とトラフィックのキ物多 1 Mbps マルチキャスト参加者数 ( 200208 / 19 14 : 00 ~ 200208 / 21 15 : 00 ) 14 12 10 8 6 4 2 0 朝日放送から大阪Ⅸ 5005 へのトラフィック ( 2002 / 08 / 19 14 : 00 ~ 2002 / 08 / 21 15 : 00 ) 12 10 凖決勝凖決勝第 1 試合第 2 試合準々決勝決勝 8 休止時間休止時間 ( の dq > ) 4K 、ハ 4 工 2Mbps での配信開始 4 2 0 08 / 19 18 : 00 08 / 21 12 : 00 08 / 21 00 : 00 08 / 20 18 : 00 08 / 20 12 : 00 08 / 20 06 : 00 08 / 20 00 : 00 08 / 21 06 : 00 時刻 lyst 3548 から大阪 IX5005 ー充れたトラフィックです 2Mbps を混在させた配信を開始しています。 2Mbps での配信を始めるまでは、次の 2 つのストリー ( 単位は Mbps)0 さきほども述べたように、今回の実験では映像を 1Mbps と 2Mbps の 2 不頁の帯域で配信しまムを配信していました。した。ただし、 2Mbps での配信は安定しなかったため、映像 1Mbps/ 音声 128Kbps 期間を限定した配信となっています。図 3 下の中央に書映像 0.9Mbps / 音声 128Kbps いたように、 8 月 20 日の準決勝第 2 試合から 1Mbps/ 186 UNIX MAGAZINE 2003.1

7. UNIX MAGAZINE 2003年1月号

図 2 酣言サーバー ( 朝日方 ) のネットワーク 1 Mbps 用配信機材 OKI Media Encoder OKI Media Server 2Mbps 用配信機材 OKI Media Encoder OKI Media Server 大阪Ⅸ 5005 へ SEIL 中継映像 CataIyst 3548 トラフィック・モニター継続しているかどうかを石忍しました。配信カ亭止していたら、運用担当者 ( 実験をおこなった私たち自身です ) にメールが送信されるイ督はみになっています。この監視システムを運用することで、すくなくともサーバー側の配信システム障害は自重加勺に検出できるようになりました。しかし、実際に運用してみると、サーバー側の障害だけ検出しても、完全には配信を保証できないことが分かりました。インターネットは、密につながった一枚岩のネットワークではなく、お互いか緩やかに接続されています。このようなシステムの場合、いったん配信サーから送出されたバケットか無事に目白也に到達するかどうかは、状兄により刻々と刻ヒします。ですから、たとえ配信サーバー側に間題がなくても、ビューアに映しだされた映像を見ると品質が劣化していたり、映っていないこともありえます。 ISP は、自社バックポーンの品質糸財寺を最優先します。 ISP にとっては当然のことですが、アプリケーションをからませて運用をおこなうと、いかに品質の糸財寺が大変かを身をもって知ることかて、きます。いったん旅立ったバケットの運命は天にまカるしかないという、インターネットでは当り前の事実を再認識させられました。 UNIX MAGAZINE 2003.1 14 時から 2002 年 8 月 21 日の 15 時までとなっていま表したグラフです。横軸はリで、 2002 年 8 月 19 日の図 3 は、中継終盤の受信者数とトラフィック窈隹移をす。これは、準々 1 刔劵か引刔劵の終了までの期間に相当し図 3 上のグラフ従軸は受信者数を表します。ただし、この、、受信者数 " は、各 IX5005 のマルチキャスト経路表から恥昇したマルチキャスト受信者数の合言 t です。したがって、かならすしも実際の受信者数と一致しているわけではなく、以下の点で現実とのすれカ吽します。・Ⅸ 5005 自身か受信者として数えられるたとえば、受信者が 1 人もいない状態から、東京 IX 5005 に接続しているユーザーが受信を開始すると、ます東京Ⅸ 5005 の受信者が 1 人増えます。その後、東京 IX5005 が躑友Ⅸ 5005 0 ンサット酉当医を依頼することで、大阪 IX5005 の受信者として東京 IX5005 が数えられることになります。本当は 1 人しか増えていないにもかかわらす、グラフ上は 2 人増えたようにみえます。ただし、この状態からさらに東京 IX5005 の受信者か増えても、東京Ⅸ 5005 の受信者数か増えるだけて大阪Ⅸ 5005 での受信者数は変化しません。末端のユーサー・ネットワークの受信者数が数えられバケットがマルチキャスト配信されるため、ユーザーネットワーク上に複数の受信者がいても、そのユーザ・ネットワークを収容している IX5005 では 1 人としか数えられません。図 3 下のグラフの縦軸は、朝日放送に設置した Cata- 185

8. UNIX MAGAZINE 2003年1月号

連載 /Cyber Kansai Project 写真 4 IPv6 マルチキャスト配信に使用したエンコータ写真 3 NetCache C2100 duction 、ガンマ補正などの調整かできます。中間ファイル ( 非 WÆAVI など ) を生成せすにプリプロセスをおこない、高画質でエンコードできるのは大きな利点です。ハードウェアで de-interlace をおこなうマシンはありますが、 StreamZ * はピクセル単位で動きに j 直しながらリアルタイムに補正するため、ライフ酒己信などの際にはきわめて有効なシステムだと思います。これまでの 64Kbps 程度の中継ではスコアなどの文字情報はほば判読不可能で、画質を損なわすに中継することは半はあきらめていたのですが、 StreamZ* の導入により、低ビットレートでも文字か読み取れるほどきれいに工大会期間中は、朝日放送にかかわるネットワークか増強ンコードされました。されます。そこで、これと並行して重の実証実験をおここの低ビットレート向けのコンテンツをより多くの人にないました。 1 直に見てもらうため、 Network Appliance7 からお借上記の DVTS over IPv6 イ云送実験では、朝日放送からりしたキャッシュ製品 NetCache C2100 ( 写真 3 ) を配東京・丸の内のショールームまで DV 映像を JGN (Japan 信システムとして利用しました。 C2100 は、 2U サイズで Gigabit Network)9 経由で伝送しました。 GbE クラスのストリーム配信能力をもつアプライアンス IIJ の協力を得て実施した IPv6 マルチキャスト配信実製品です。 7 台のディスクをよ曜内でき、 2U の本にもか験では、大阪、東京、オ LJP. 晃、福岡の 4 拠点を中心としたかわらす RAID 4 を実装しています。ディスクの活性保 IPv6 ネットワークを構築し、夫験参加者が IPv6 のトン守、アクセスログを含むキャッシュデータの一描像ディスネルを張るというガ去て配信帯域 1Mbps の MPEG 4 ラクの増設か容易といった、コンテンツを配信する側にはたイフ映像を配信しました。いへん便利な機能を備えています。また、多地点分散アーカイプ・システムに関する実験の一環として、ル、ト悼月日放送と協力して JGN 経由での DV この連載でも何回か紹介していますが、 NetCache シ素材伝送実験をおこないました。これまで、放送局間の素リーズは ReaIMedia や Windows Media 、 QuickTime をサポートしているため、 1 台で複数のメディアタイフ。や材交換はマイクロ波を用いておこなわれてきましたが、 IP 網を利用すれば双方向生のあるう靖攵アーカイプ・システムビットレートのコンテンツ配信がおこなえます。さらにの実現か期待できます。 Microsoft と RealNetworks の両社から Certification ( あかふし・ともひさ朝日放送、を受けているため、その未でも安じ、して使えます。おきもと・ただひさ NTT スマートコネクト ) ナローバンドで品質の矼 E 、配信の安定を図る一方で、新たな町絲目みもおこないました。朝日放送では、 IIJ の協力を得て MPEG 4 over IPv6 マルチキャスト配信実験や、 IPv6 普及・高度イ隹進協議会 8 向けの DVTS over 7 http://www.netapp ・ CO ・ jp/ 8 http://www.v6pc.jp/ IPv6 伝送実験など、 IPv6 関係の実証実験に限定したプロードバンド配信も実施しました。実証実験 9 http://www ・ jgn ・ tao ・ go ・ jp/ 193 UNIX MAGAZINE 2003.1

9. UNIX MAGAZINE 2003年1月号

2003 年 1 月 1 日発行 ( 毎月 1 回 1 日発行 ) 第 18 巻第 1 号通巻 195 号昭和 63 年 9 月 5 日第三種郵便物認可・トラブルが発生したら一応急処置ー・情報の収集と防止策の立て方・システムのトラブルとは何か饕 SO ねⅱ s トラカいシューティング 2002 年夏 : デ子園高校野球中継サイバー関西プロジェクト - ・ , start kernel() と setup arch() し inux のプートプロセスをみる Apache の導入と便利な使い方こけつまろびつリ N Ⅸ 簡易データベースの構築プロクラミング・テクニック X. 509 認証機構証明書の役割と入手方法 UNIX Communication N0tes 実験環境から実用化へー大規模 6 マルチキャスト配信・探索ーー逐次探索、審兵、ニ分探索ふ内挿探索 ~ ・クラスの定義、メソッド、オプジェクトー一一一一一一一・境としての J a プクラミング入門

10. UNIX MAGAZINE 2003年1月号

188 194 180 サイバー関西プロジェクト・甲子園 2002 インターフェイスの街角 WikiHeIp ・・・赤藤倫久、沖本忠久・・・増井俊之大規模旧 v6 マルチキャスト配信の実現に向けて・・・・・片岡邦夫、島慶ー News•• CoIumn 25 女子大生の放課後・・・・・・北川渉、伊藤そよか、笠藤麻里ワークステーションのおと・・・・・・坂下秀 142 NetNews 便り・・・・・・みるく 156 NEWS from jus Bookshe げ・・・読者アンケートのお知らせ・ Linux Update ・ " ・ " 宮地利幸、田淵貴昭 162 164 166 UNIX MAGAZINE vo い 8 # 1 2003 年 1 月号 ( 通巻 195 号 ) 2003 年 1 月 1 日発行発行所・株式会社アスキー〒 160-8584 東京都新宿区信濃町 34 JR 信濃町ビル出版営業部電話 03-5362-3300 発行人 / 小森哲郎・編集人 / 土屋信明・編集長 / 大久保讓治・ Edito 「・ s Network Address: unixmag@ascii. CO. jp ・編集 / 川崎通紀岸竜次久保田考長谷川光広・出版営業担当 / 遠藤剛三井善裕藤本典子佐々木直・出版広告担当 / 山本直吉郎桜山ちづる志摩和弘・生産管理担当 / 篠田敦禁転載◎ 2003 ASCII Corporation 1070301 印刷 / 東京書籍印刷株式会社 Printed in Japan