Language
- English
- Deutsch
- Français
- Español
- Português
- Italiano
- ﺎﻠﻋﺮﺒﻳﺓ
- Türkçe
- 中文
- 한국어
- 日本語
- Indonesian
- Tiếng Việt
- Русский

IPTV solutions by NetUP

Logo

NetUP IPTVProbe

IPTVストリームモニタリング用オープンソースソフトウェア
ライセンス: GPL (GPLv2, GPLv3)

ソースコード - iptvprobe_v0.4.tbz2

IPTVProbeに関するご質問はNetUP IPTVフォーラムをご利用ください。

変更ログ

Version 0.4

定期的なデータベースクリーンアップ
プローブによる複数のマルチキャストストリームのモニタリング
iptvprobe_serverでのメモリリーク修正

注意!

Version 0.3

IGMPリクエスト処理と一時IGMPパラメーター表示を追加
コードクリーンアップ、一部バグ修正
プローブ使用のデータ交換プロトコルを最新バージョンで更新

Version 0.2

Aminet 110 (ppc)サポート追加

Version 0.1

初期リリース
ロストパケットコントロール機能を追加
UDPパケット受信速度の表示機能を追加

ネットワークのしくみ

プローブ(iptvprobe)とコレクター運用レイアウト

ソフトウェアの構築とインストール

ソフトウェアは下記の要素で構成されています:

コレクター - プローブから統計データを収集します。収集した統計データはデータベース(mysql)に保存されます。
プローブ - リモートで動作するアプリケーションです。IPパケットで受信した統計データはプローブで収集されコレクターに送信されます。プローブはLinuxカーネルモジュール(netup_netprobe.ko)とユーザーレベルソフトウェア(iptvprobe)で構成されています。
レポートシステム - 収集した統計データをビジュアル化するためのウェブスクリプトのセットです。

コレクターの構築と開始

コレクターの構築:

cd iptvprobe/userver/
cmake --debug-output . -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
make

データベースの作成:

mysqladmin create iptvprobe
mysql iptvprobe < db.sql

コレクターの開始:

./iptvprobe_server -l root -s 127.0.0.1

この例ではコレクターはローカルホスト上(127.0.0.1)にある'iptvprobe'データベースに統計データを書き込みます。

iptvprobeの構築

x86プラットフォーム用アプリケーションの構築:

cd iptvprobe/udaemon/
cmake --debug-output . -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
make

x86プラットフォーム用Linuxカーネルモジュールの構築:

cd iptvprobe/kmodule/
make

sh4プラットフォーム用 Linuxカーネルモジュールの構築(IP STB AmiNET 130):

cd iptvprobe/kmodule/
export CROSS_COMPILE=sh4-unknown-linux-gnu-
make ARCH=sh amino130

aminet130_bin/ ディレクトリには構築済みのLinuxカーネルモジュールとAmiNET 130 IP STB用のユーザーレベルアプリケーションが含まれます。

プローブの開始

Linuxカーネルモジュールのローディング:

cd iptvprobe/kmodule/
insmod netup_netprobe.ko hook_position=0

hook_positionパラメータ―はnetfilterのIPパケットフックポジションを指定します:

0 - すべての受信IPパケットを処理 (PREROUTING ポリシー) 1 - すべての送信IPパケットを処理 (POSTROUTING ポリシー)

クライアントのデバイス上でモジュールを実行する場合には、"0"の値を設定しなくてはなりません。 (IP STB AmiNET 130など) サーバー上でモジュールを実行してマルチキャストトラフィックを送信する場合は、"1"の値を設定しなくてはなりません。

netup_netprobe.koモジュールのロードが成功した場合は、/dev ファイルシステム内にノードを作成して、iptvpobeアプリケーションを開始する必要があります。 :

mknod /dev/iptvprobe c 61 0
cd iptvprobe/udaemon/
./iptvprobe -i 224.117.117.10 -s 10.1.4.242 -r 5 -p 7700

コマンドラインオプション:

-i モニタリング用マルチキャストアドレスを設定
-s コレクターのIPアドレスを設定
-p コレクターがプローブからの接続を許可するポートを設定
-r 実行識別子を設定

レポートサブシステム内で完全構築されたコマンドが見つかります。

レポートサブシステム

レポートサブシステムを実行するためには、iptvprobe/report_sys/ からすべてのウェブスクリプトを使用しているウェブサーバーにコピーする必要があります。:

cd iptvprobe/report_sys/
cp *.pl /var/www/localhost/cgi-bin/

正常動作にはperlとGDがインストールされている必要があります。

ウェブブラウザが以下のURLに向かうようにします:

http://address/cgi-bin/iptvprobe_runs.pl

"address"の部分はお使いのウェブサーバーのアドレスです。

スタートページにはプローブの実行リストがあります。:

"プローブ上の実行コマンド "の欄には、プローブ上で実行するために完全に構築されたコマンドが記載されています。

マルチキャストフローのグラフィック表示は "UDPタイムライン図" または "PCRアライバルインターバル" のリンクを使用して閲覧することができます。図には最後の約30秒が表示されます。

2つの例を実行しました。1つ目はAmiNET 130 IP STB上でシンプルなSOHOスイッチ経由でIGMPスヌーピングサポートなしで接続しています。２つ目はAmiNET 130 IP STB上でCisco catalystスイッチ経由でIGMPスヌーピングを使用して接続しています。１つ目の場合はIPパケットのロスが多く見られます。次の図は２つの例をビジュアル化したものです:

図の説明

最後の約15〜30秒はX軸に表示されています。

下記のパラメーターはY軸に表示されています:

100 msec以内に集まったIPパケットのカウント
100 msec以内に集まったbytes数
赤い線がロストしたIPパケットを示しています。図で山形に表示されるのは"IP packet ID"に不連続性が検出された場合です。 0の値はパケットロスが検出されなかったことを意味します。

データベースの説明

SQL テーブル	説明
実行	実行リスト、すべての実行は個別の番号で識別されます。
data_ip	プローブによって検出されたIPパケット。 IPパケットアライバルタイム (timestamp)はナノ秒で記録されます。パケットID (header_id) も記録されます。
data_ts	プローブによって検出されたMPEG伝送ストリーム (TS) パケット。以下の値が記録されます。: PID、PTS/DTS/PCR、カウンター値(cont_counter)
stat_bandwidth	統計データ

IGMPモニタリング

iptvprobe v0.3以降、 IP STBによって送受信されるIGMPリクエストをプローブでトラック可能な場合があります。グループを離れる直前の最後のグループパケットとグループに参加した直後の最初のパケットのタイムスタンプが記録されます。これらのデータはIGMPリクエストとスヌーピングを処理するネットワーク機器の性能を評価するのに使用されることもあります。

下記はプローブ用のAminet 130 IP STBとコレクター用のNetUP Middlewareの機能の例です。 Cisco Catalyst 3560はIGMPスヌーピングサポートのついた交換器として使用され、Cisco Catalyst C3550-12TはIGMPクエリアとして使用されています。

IP STBでTVチャンネルを切換えます。STBがマルチキャストグループ224.121.0.4を離脱して224.121.0.3.のグループに参加する旨のIGMPリクエストを送信します。これらのリクエストはプローブによって記録され、ウェブインターフェイス内でタイムスタンプと一緒に表示されます。

興味深い項目を青枠で囲んでいます。IGMPが224.121.0.4のマルチキャストグループの離脱リクエストした後にSTBが同グループに送信されたパケットを4996.2ミリ秒間受信しつづけていることが分かります。IGMPの224.121.0.3グループへの参加リクエストから最初のパケットを受信するまでの時差は80ミリ秒です。

IGMPリクエストのレベル上でのTVチャンネルの切換えのトータル時間は全体で92ミリ秒です。新しいチャンネルを選択してからTV画面に表示されるまでの実際の時差はバッファリング、オーディオ/ビデオシンクなどそれぞれパラメーターによって異なります。

また、それに加えてSTBは両方のマルチキャストグループから約5秒間パケットを受信することで帯域幅を無駄にしています。この無駄を避けるために交換器は即時離脱を設定しなければなりません。以下の通りに行います:

c3560(config)#ip igmp snooping vlan 1 immediate-leave

この方法で設定を行うと、交換器は必要のないグループのデータストリームを即座にスイッチオフします。結果は赤枠の中に表示されています。 "IGMPv2: Leave Group 224.121.0.11"の離脱リクエスト後にSTBが224.121.0.11のグループのパケットを受信していないことが分かります。つまり、どの瞬間もSTBは1つのチャンネルのパケットだけを受信しているのです

IGMPリクエストの一時パラメーターを正確に記録するために、ネットワークインターフェイスはSTB上でプローブを開始させる前に promisc方式に設定しなくてはなりません。:

# ifconfig eth0 promisc

課題リスト

ダイアグラムの改善(スケール、シフティングなど)
"PCRジッタ" ダイアグラム、その他のダイアグラム
各種IP STB用のプローブのバイナリー構築
ネットワーク管理用のプローブのアベイラビリティモニター