debiancdn

AWS, Content Delivery Network and Debian

日別アーカイブ: 2007/09/13

BS-5-10 グリッドコンピューティングを適用したディザスタリカバリシステムの一検討 東京電機大 国分さん

重要データのバックアップ手法:データを複数のPCに分散バックアップ

日刊工業新聞3月10日付けで実験が報道された。

重要データを回線速度に応じて分割データサイズを可変長にする。

Q:なぜ可変長なのか。グリッド速度におうじて数を増やすとかはどうか

A:今後の課題

Q:差分update方法についての考慮は?

A:まだ考えていない

BS-5-8 次世代IPネットワークにおけるコンテキストアウェアサービスのための分散キャッシュ管理方式 富士通 佐野さん

背景:RFIDやセンサもネットワークに接続される。コンテキストアウェアサービスが提供されようとしている。コンテキストは情報量は小さいが、非常に多くの数がやりとりされるようになる。その処理負荷が問題となる。ここでいうコンテキストは温度、照度などのセンサ情報。

スケールアップとスケールアウトではスケールアウトが重要。

サーバ負荷分散方式:負荷分散装置では同一のデータを複数で保持するのが無駄なので、キャッシュサーバによる負荷分散を考える。

提案するキャッシュ方式:ライフタイムを指定した参照要求に対して指定された周期でコンテキスト更新する。リアルタイム性を要求しない場合にのみ使う。キャッシュサーバを分散配置して、負荷分散も行う。その切り替えアルゴリズムがポイント。

Q:温度と冷蔵庫を結ぶサービスに社会ニーズがあるんですか?気象庁がやること以上のじゃ足りない根拠は?説得資料がほしい

Q:関西大学山本さん:グラフの解釈について10回やっても100%にならないのか

A:状況依存。このデータはランダムの場合。

BS-5-7 NGNの網サービスについて 宮口 NGNにOBNを移植できるかという話

OBN:クレジットカード利用基盤

OBNにみる企業IP網の特徴:

  • 企業はLANとLANの通信であって2端末だけではない、既存のLANや内部網を利用している、しかしながらNGNの計画は企業LAN向き新サービスはNGNの対象外に見える。
  • 閉域通信:ゴミ加入者がいない、認証は毎度はやらない
  • LAN内の複数コンピュータのみ通信相手に接続できる
  • 時間内処理:NGNだとエッジルータのフロー制御が必要じゃないか?こういうのを検討していない

OBN→NGN手順その一

  1. OBN周辺システム改造なし。IPアドレス変更なし
  2. 移植コスト負担なし
  3. アクセス回線認証、送信元とあて先アドレスの検査
  4. データ優先制御

ステップ2:LANにNGN電話を導入

OBN移植後の理想:NGN+閉域通信+エッジルータのフロー優先制御

NGN計画はマーケティング不足。電子マネーむけの調査すらしていない。

Q:DoSできないのはなんで

A:登録してるものしか通信できないようにエッジルータが動作しているから。NGNにはセキュリティ専門家がいない。

Q:なぜ全銀協ネットワークを公開しないか

A:減価償却すんでるドル箱を手放さない

Q:身元が特定されているのに認証後に攻撃することに意味があるのか

A:攻撃は可能。ゲートウェイののっとりをすればいいだけ。

なんだか言葉の定義がちがうような気はするがおもしろい視点。

BS-5-6 広帯域でセキュアな家庭LAN間接続を実現するVPN接続方式 NTTプラットフォーム研 水野

網の外からどのように使おうか、という発表。家庭LANにはDLNA,アクトビラいろいろある。インフラ的にもwlanやPLCなどでサポートできるようになってきた。今後は遠隔の家電同士の連携利用シーンのためにVPNニーズが増えてくる。しかし、一般家庭むけにはVPNの敷居はまだ高い。

家庭LAN間の課題

  • 利用者の希望どうりに簡単かつ確実につながらないといけない:相手の識別、固定IPで無い先への接続
  • 設定不備が家庭がやばくなる:信頼できる相手からの通信のみを許可
  • リッチリアルタイムアプリをインターネットを使うと品質が悪くなる恐れ:安定した広帯域確保。たとえばDLNAはLANの上を前提にしている

このためにはセッション管理プロトコル(SIPみたいな)を使うのがよい

  • SIPサーバで名前解決、セッション管理。
  • ポートの動的開閉
  • インターネット上にSIPサーバがあれば十分か?:SIPで名前解決するだけでは、アドレス詐称や不安定な帯域に由来する問題は解決しない。接続先の認証認可、帯域保証の仕組みは別途用意する必要がある。

SIPを用いたVPN接続の既存技術としてm2m-x方式 http://www.uopf.org/ ではSIPを用いたP2P接続というのがある。商用SIP網があればSIP独自拡張は不要になるのでは?ということでNGNを活用しよう。電話番号をつかって接続できるかもしれないじゃないか。

提案:SIPダイアルアップシステム 電話する感覚で電話番号を指定して相手先にLAN間接続。電話番号をキーとしたGW装置がある。

特徴:接続認可と認証をゲートウェイに電話番号を付与した証明書を発行。IPSecパケットを他のメディアと同様に扱えるようにするためにUDPカプセリングされたESPパケット。RFC3948の方法を常に使う。結果として、SIPサーバを介したVPNトランスポートをおこなう。SDPのbで帯域も指定できる。

まとめ:NGNをつかうことで簡単に安全に!単名前解決のためにSIPをつかうだけではない。今後は試作品をつかって詳細な検証を。

Q:NS2002-140で発表しているので読んでほしい。

Q:DoS対策はどうなっている?SEが余計なアドレスをフィルタリングしないと攻撃される。そういう特許をかいてるので読んでほしい

BS-5-5 IMS/MMDにおける複数端末間動的サービス制御システム KDDI+モトローラ 今井さん@KDDI

オールIPにおけるサービス提供基盤技術要求が背景。ユーザの状況に応じて、固定網と移動網を自由にまたがりながら、継続的な利用を可能とするサービス制御基盤が必要。

セッションモビリティ技術:SIPによるものがよく言われるが、双方のユーザによる同時端末切り替えができない、遠隔からのセッション制御ができない。

要求項目

  1. ユーザ端末全ての能力情報を収集できないといけない
  2. セッション情報取得:リソース切り替えにあたりどのセッションをきりかえるか指定できないといけない
  3. 端末の利用可否の把握 availability
  4. ユーザ間サービスネゴシエーション:双方の状況
  5. 実際に切り替え

アプローチとして、SessionManagerとPresenceManagerを置く。SIP REFERをつかって実装した。Stateを保存している。

セッション情報管理:セッションマネージャはユーザ同士の通信ごとにセッション情報を管理している。リソース切り替え要求はREFERをつかって、XMLを乗っけてUEが通知。切り替え時はSMから端末の能力をSDPなしINVITEを使って確認、re-INVITEが送られる

プロトタイプ:

  • IMS/MMDコア:モトローラmotomini
  • クライアント:wlan携帯 E02SA上でBREWアプリ。プロファイル(自宅、屋外、自宅寝室。。。)を選択。テキストチャットと音声
  • プロトコル変換GW下のクライアント:ポリコム、ソフトフォンなど
  • 評価:切り替え時間は1.7秒くらい。音声通話しているところに、+映像をIPテレビなどでやったとき。音声はとぎれることなし。

まとめ:ユーザビリティ重要。セッションも一つのプレゼンス。

Q:おれ:capability取得は毎回やっているの?capabilityはPMにおいておけないのかな?

A:ねんのためやっているだけでなくてもOK

Q:座長:普通の端末がだめなのは?

A:端末のほうで状態をわかればOK.切り替え要求をする側はその機能をいれたクライアントが必要。今回はケータイ上に作ったけど、パソコン上にやってもいい。

Q:富士通研上野:セッション受け渡しをエンドユーザに簡単につかえるようにしないといけないよね。でもシーケンスはユーザに理解できないし、オープン化できますか

A:ウェブアクセスで切り替えをする、のが楽かも。でもどこまで現実的か。技術的には問題ないが、どのように公開するかが重要

Q:NEC谷:パーソナルエリアネットワークという似たのを持っている。SIPはe2eになってしまうのでネットワークとしてはまとめにくい?プライバシーの問題とかそういう問題はかんがえていますか。家には家でリソースの競合もある。子供がテレビ見てるとか。

A:本当の情報家電(売っているテレビ)とかで動くのか。今は人に対してメッセージを与えている。OMAなどでも活用している。ある家電メーカーは自分のテレビでもやりたいという話があった。しかし複雑になってしまった。そんなわけでSTBあたりから攻めていこうと考えている。

BS-5-4 NGNにおけるセッションボーダーコントローラの検討 沖電気 千田さん

背景:沖はトリプルプレイIP化をやりたい。するとエッジに価値が集まると思う。そこでSBCに着目して開発をしている。NiCTの研究の初年度。

IMSの一部としてのSBC。IBCFとTrgw

相互接続にて望まれる機能仕様いろいろ。プロトコルリペア、トラスコーディング、トラフィックモニタ、QoS,NATトラバーサルなどなど。。合法的通信傍受機能(CALEA対応)

コーデック変換が重要:

SBC配備仮説と遅延問題:東京に集中していたら、伝送遅延がさけられない。沖縄ー東京ー沖縄の3000kmでは15msecかかる。VoIP端末間遅延の実測値が2003年にCIAJから出された資料では端末だけでも100msecくらいはすぐに行く。

システム構成:HAミドル+OS(CGL)+ATCAボード+ATCAシャシーで構成された沖共通プラットフォーム

ATCA-PFのメリット:装置単体におけるCG、マルチベンダと経済化、複数装置の収容可能、機能追加が容易で柔軟

HAミドルウェア:ハードウェア、ネットワーク二重化対応。運用中のファイル更新、ロールバック対応。コマンド一括投入。障害監視。トラフィック収集。CGL上で動作。

ATCAのインターフェースブレード:NP搭載。IXP2800(intel)、1G8本と1G2本。8G full-duplex。装置あたり80GBps。

ポートグループ:

NPUとCPU:NPUではパケット全数処理を前提としているからできる。低遅延化が主なねらい。

SBC適用領域:事業者内接続や、事業者間接続を想定。エンタープライズ利用者のエッジルータではない。

Q:Codecの範囲は?

A:音声と動画を考えていた。静止画も要求があれば考えたい。

Q:ボードはどこにささるのか

A:ATCA汎用ボードの一つ。CPUブレードとスイッチブレードではない。

Q:東京電機大の宮本:CGL機能?今の回線交換と同じレベルなのか SBCの装置速度とかはどうなっているのか絵の追加説明

A:montavistaを使っている。Asianuxへの切り替えも考えている。今は同じまでにはなっていない。 帯域の話だが、通常はroutingがあると、SWブレード(この速度は最大4G)を経由してしまう。折り返しの設定を外だしすることによって速度を上げている。たとえばcodecオプションボードを刺すとSWブレードを通ってしまう。が、極力そうならないようにしたい。

BS-5-3 NGNでの帯域保証自動設定方式 日立中研 沖田さん

ビジネス利用ではNGN適用によるリアルタイムトラフィックQoS保証が必要。ビジネストラフィックはNGN制御層への負荷増大を招くと考えている。そこで、制御層への負荷を抑えつつ、柔軟に対応可能な方法を考える

帯域事前割り当て方式利用のアプローチ:拠点収容数に基づく帯域の自動割り当て。

プレNGN:管理者による帯域固定割り当て。トラフィック増減に動的に対応できない。制御負荷は当然ほとんどない

NGN:動的割り当てでは、帯域セッションごとに割り当てていては制御負荷が高い。

帯域自動割り当て方式:

  • 必要となる帯域を予測し、設定
  • ネットワーク構成に基づく割り当て帯域の計算
  • 予測設定のタイミング

制御システムの構成:中心に管理サーバがいる。情報取得、帯域割り当て、設定更新という流れ。

設定アルゴリズム:接続先の収容端末数、平均占有帯域幅、階層調整係数、リンク帯域幅、許容占有率を考えてそのミニマムでI/Fごとの最低保証帯域幅が決まる。(よくわからん。。。)

拠点の数、規模で割り当てを決定することを提案。大規模企業網への適用ができるのではないか。

Q:NEC谷さん:トラフィック推定をトポロジからやっているだけのように見えるんですが推定が甘いんじゃ。どのくらいの呼がくるから重いのか、とかおしえてくれ

A:トレードオフです。完全な収容はできないけれど、簡易な形で提供できること自体には意味があると考える。サービス導入時にやるものなので運用時に最初の推定から外れることはわかっている。

Q:そんな二段がさねだったら意味ないんじゃ。具体的に何トランザクション/Secみたいな話はないのか

A:定性的に懸念しているだけの話。

Q:チェア:SIPサーバはもっと多いトランザクション処理しているので問題にならんのでは

Q:東工大飯田さん:フローアグリゲーションを1999年くらいでやっている。そのへんを参考したら?

こんなんでいいのかなあ。帯域の売買もあるとおもうし。TEもあると思うし。

BS-5-2 パスにそったシグナリングにもとづくQoS保証法の設計と試作 日立中研の金田さん

スケーラブルQoSの研究開発:総務省の次世代バックボーンに関する研究開発の一部(5年の2年目)。NGNではe2eだがとりあえずバックボーンについて。QoS保証をRSVPやNSLPにちかい(完全準拠は時間がなかったので簡単なもの)プロトコルで要求。フローとアプリケーションQoSのバックボーンでの集約。実際に模擬トラフィックをつかって実施。

方針:コアではDiffserv.コア網はオーバープロビジョンが前提。アクセス網ではIntServ.異なる要求を持つ多様なアプリをみな満足させるQoSが目標。(遅延、パケット損失、いろいろ。)

実験システム:コアノードにはGS4000をVLANで論理分割。エッジがGR2000B。voiscapeでトラフィック擬似発生。

ポリシーサーバがQoS要求を把握して、決定、配布する。セッション制御時の交渉にはSIPを使用。(今回の実験ではSIP/SDPは使っていない。まにあわなかった)

フローパスにそったQoS要求シグナリングの使用。端末からのQoS要求は

  • NGLP(両方)、
  • RSVP,NSLP(フローパス使用)、
  • フローパスを経由しないSIP,NSLP。

RSVPやNSLPにちかいものを開発。QoS要求は送信者が出す。

仕掛け:GR2000Bからルータ機能拡張するLinux箱にいったんながして戻すした。

QoS仕様記述はQoS-NSLPを基準にした。

  • RSVPはジッターがかけない
  • IETF NSIS WGで開発中のQoS-NSLP(QSPEC)を基準。

アウトソース型プロトコル。SCOPS(COPS-PRのようなもの)

トラフィックの種類は3GPPの4分類を利用。ITU-T Y.1541では8分類だが大体対応しているからOK

DiffservのQoSクラス(PHB*). EF, AF, DF.

会話はEFに。音声だけを入れる。動画をEFにいれると不当に圧迫されるため。

Diffservの制御はあたりまえのことをした:エッジノードでポリシング(危険水準フローを制限)、マーキング(PHBごとにDSCPきめ)、リマーキング。コアノードではキュー選択して、廃棄制御する。

エッジノードのポリシー:アプリQoSクラスからポリシーを決める。SDPをみてないので、会話クラスのうち指定帯域が一定値以下・以上で会話音声・会話映像クラスを切り替える。

コアノードのポリシー制御詳細

まとめ:アクセス網ではフロー制御、コア網ではフロー制御できた。SNSLPをポリシールーティングを使用して実装した。エッジノードにおけるポリシングやリマーキングのパラメタをQoS仕様から決定する方法を開発した。

Q:東工大飯田さん: SNSLPをどう変えた、つくったのか。NSLPの改善版として提案する気があるのか

A:提案するつもりはない。部分的にためすためにつくっただけ

Q:実用化へのハードルはどこでしょうか。本当にdeploymentできるのか。COPSサーバのアルゴリズムなどが重要なのでは

A:いまのところごく一部しかできていない。コアノードの制御では帯域の配分をしらべたけれども。

Q:モトローラの人: リップシンクなどがあるので映像音声同期は重要では

A:たしかにそうだが、それほど問題にはならないんでは?厳しいのが必要なら、音声クラスと同じとこにいれるように制御すれば。