Comments
Description
Transcript
QoSサーバのLSP設計手法
QoSサーバのLSP設計手法 磯山 和彦* 斎藤博幸* 長尾泰孝* * 吉田万貴子* NEC、NECネットワークス *ネットワークス開発研究所、 * *第二ネットワークソリューション事業部 2001/10/30 内容 • 背景、前提 • QoSコントロールアーキテクチャ • LSP設計手法 • 定量評価(トラヒック収容効率) • まとめ 2001/10/30 第10回ITRC総会・研究会 2 背景 • ＩＰ網の商業利用、ライフライン化 • アプリケーション、要求通信品質の多様化 • プロバイダ間の競争激化 • 付加サービスの必要 – QoSの保証 – ネットワークの効率運用 • QoSコントロールアーキテクチャの提案 2001/10/30 第10回ITRC総会・研究会 3 IP におけるQoSの制御方式 • QoS、リソース制御→Diffserv –エッジにおけるパケットのクラス分け –コアにおけるクラス単位のQoS制御 • 経路制御→MPLS – コネクション、パスの概念の導入 –経路制御による負荷分散、障害回避 • ネットワーク制御→Policy Server –ポリシールール(Condition→Action)のネットワーク制御 –オペレータによる管理の簡略化 2001/10/30 第10回ITRC総会・研究会 4 IP におけるQoSの制御の課題 • 分散制御 – オペレータによる管理が困難 – ネットワークワイドに整合のとれた情報保持が困難 → 複数パスを同時に最適化することができない。 • Diffserv、MPLS – 最適な経路、リソース割り当てとは？ → ネットワークの状態、アプリケーションの要求に基づいて最適なパラメータを計 算するメカニズムが必要。 • ポリシー制御 – オペレータが設定した固定的なポリシー → ネットワークの状態変化に応じたポリシーを提供する必要。 2001/10/30 第10回ITRC総会・研究会 5 前提 • ネットワーク：QoS管理型ネットワーク – ネットワークはオペレータにより管理 – 要求があったトラヒックに対してはQoS保証サービスを提供 • サービス：デマンド受け付け型サービス – SLAベース – QoS保証が必要なトラヒックは事前に要求(アプリケーションサーバ、GUI等から) – ベストエフォートトラヒックも混在→管理対象外 • ネットワークエレメント：Diffserv over MPLSをサポート – エッジ： トラヒックをDiffservクラス(BA)に振り分け、LSPにマッピング – コア： 2001/10/30 BA毎のリソース(バッファ、帯域等)割り当てによるQoS制御、 ラベルスイッチングによる経路制御 第10回ITRC総会・研究会 6 QoSコントロールアーキテクチャ Application （Ex. Call Agent） Operator •QoSサーバ – アプリケーション、オペレータからの QoS、経路要求を受け付け アプリケーション インタフェース Policy Server /NMS – QoS保証可能な最適経路、リソース 割り当ての計算 •ポリシーサーバ/NMS Directory – QoSサーバの求めた制御パラメータ、 ポリシーをNEに対して設定 Monitor ing Server QoS Server •ディレクトリサーバ – 制御サーバ群にてNW管理に必要と なる情報を格納し、一括管理 •モニタリングサーバ – トラヒック監視、ネットワークトレンド 解析、異常検出報告 Core Core Router Router Edge Router 2001/10/30 Core Core Router Router Core Core Router Router Edge Router 第10回ITRC総会・研究会 設計、制御、監視のサイクルを構成 7 集中制御による特徴 • ユーザ/アプリケーションとのインタフェース – QoSサーバがユーザのSLAやアプリケーションのQoS要求を取得。 • ユーザ/ネットワーク情報の管理の容易性 – 分散制御で必要な情報の分配、同期を行うメカニズムが不要。 • 新規サービス/ポリシー導入の容易性 – サーバのアップグレードで、多様なサービスや管理ポリシーを新たに定義可能。 • 大規模網への対処 – Diffservにより、QoSトラヒックとベストエフォートトラヒックのリソースを分離、限 られた量のQoSトラヒックのみを集中制御。 – トラヒックデマンドをアグリゲートしてQoSリソース要求。 →計算量をQoSサーバの見合ったものにすることが可能。 2001/10/30 第10回ITRC総会・研究会 8 リソース割り当て計算法 QoSサーバではデマンド受付から経路計算完了までの時間を短縮 するために、“経路設計”、“LSP設計”の二段階の設計を採用。 経路設計 デマンド受付前に、各Ingress-Egressエッジ間に、 あらかじめ複数の経路候補を計算、準備。 デマンド受付 LSP設計 デマンド受付後に、経路候補の中から最適な経路を選択し、 デマンドに対して経路上のリソースを割り当て。 NE設定 2001/10/30 第10回ITRC総会・研究会 9 QoSサーバ: ネットワークトポロジー画面 経路設計、ＬＳＰ設計のオプショナル属性を入力可能（リンクのコストなど） 2001/10/30 第10回ITRC総会・研究会 10 経路設計 • デマンド受付前に、各Ingress-Egressエッジ間にあらかじめ複数の 経路候補を計算し、準備。 • バックアップ経路の考慮 – 「単一ネットワーク機器障害発生時にも迂回可能な経路が存在すること」とい う制約条件のもとで経路候補を算出。 – 現用経路と迂回経路でペアを成すことで耐障害性を確保。 • QoSの考慮 – ホップ数、リンク容量、遅延などのメトリックの条件を満たす経路候補を選択。 – 複数経路を候補とすることによって、トラヒック負荷を分散。 – 設計時間の制約上、候補数を限定する場合、メトリックの上位から候補を限定。 2001/10/30 第10回ITRC総会・研究会 11 QoSサーバ： ＬＳＰ設計条件の入力画面 ＬＳＰ設計のための入力条件を指定 – Ｉｎｇｒｅｓｓ／Ｅｇｒｅｓｓ – ＤｉｆｆｓｅｒｖＱＯＳクラスと帯域（ＰＩＲ, ＣＩＲ） – 双方向・迂回ＬＳＰの有無など 2001/10/30 第10回ITRC総会・研究会 12 LSP設計 • デマンド受付後に、経路候補の中から最適な経路を選択 し、デマンドに対して経路上のリソースを割り当て。 • 整数計画法により最適化を行う。 • トラヒックデマンドの特性により、目的関数を選択、採用。 –遅延センシティブなトラヒックのためのLSP設計 • トラヒックを収容できる経路候補の中から、経路上のリンクの 遅延メトリックの合計が最小となる経路を選択。 • EF PHBとの組み合わせ。 –負荷分散を考慮したLSP設計 • すべてのリンクの負荷の中で最大の負荷が最小となるように、 経路を選択。 • AF PHBとの組み合わせ。 2001/10/30 第10回ITRC総会・研究会 13 LSP設計(続き) –負荷分散とコストを考慮したLSP設計 • 負荷分散とコストの双方のバランスを保ちながらトラヒックを収容するために、 サービスコスト関数を定義(右図)。 12 • AF PHBとの組み合わせ。 サービスコスト • サービスコストの合計が最小となる 10 ようにトラヒックを収容。 8 6 4 2 0 0 2001/10/30 0.2 第10回ITRC総会・研究会 0.4 0.6 負荷 0.8 1 14 QoSサーバ： 経路選択画面 ＬＳＰに最適な経路候補を選択（手動での選択も可能） 2001/10/30 第10回ITRC総会・研究会 15 QoSサーバ： 設計ＬＳＰの表示画面 現用ＬＳＰと迂回ＬＳＰをそれぞれ異なるカラーで表示 2001/10/30 第10回ITRC総会・研究会 16 LSP設計法の定量評価 • トラヒックデマンド – Ingress/Egressノードはランダムに選択。 – ただし、Ingress/Egress間のShortest Pathがn3-n4を渡るデマンドの確率は他の2倍。 – 1デマンドは一律に1Mbpsを要求。 e5 e4 n1 n4 e6 45M 45M e2 – 他の中継リンクは45Mbps。 155M n2 – 左右に渡る中継リンクの帯域は 155Mbps。 155M n6 e7 155M – アクセスリンクは常に収容可能。 e1 155M n8 e8 155M 15 5M n3 45M • ネットワークモデル(右図) n5 45M e3 n7 ネットワークモデル 2001/10/30 第10回ITRC総会・研究会 17 トラヒック収容方法 • 比較対象 – 提案方式：サービスコスト最小法 – 最短経路法(SPF)： 最短経路で収容可否を判断 – 帯域制約最短経路法(CSPF)： 収容するのに十分な帯域がないリンクを除外した中の最短経路で、 収容可否を判断 • 収容方法 – 1回の収容サイクルで10デマンドを受け付け。 – すべてのデマンドが収容できた場合収容成功。 → 帯域を割り当て済みとする。 2001/10/30 第10回ITRC総会・研究会 18 トラヒック収容効率 収容トラヒック [Mbps] 提案方式 800 帯域制約最短経路法 最短経路法 600 • 帯域制約最短経路法の場合、 1500Mbps要求された時点で、 下図赤線のリンク帯域が枯渇。 • 提案方式では各リンクを均等 に使用 400 e5 e4 e3 n5 n3 n4 e6 n2 200 n6 e7 e2 n1 0 0 2001/10/30 1000 2000 3000 [Mbps] 要求トラヒック 第10回ITRC総会・研究会 n7 n8 e1 e8 19 パスの平均ホップ数 収容デマンドの 最短パスのホップ数 実際の収容パス のホップ数 3.93 3.92 3.90 4.11 4.01 3.90 提案方式 帯域制約最短経路法 最短経路法 • 収容デマンドの最短経路のホップ数に大きな差がない。 • 帯域制約最短経路法は提案方式より短いホップ数のパスを多く採用。 • 提案方式は迂回路も採用。 • 帯域制約最短経路法はより早くボトルネックのリンクを消費。 2001/10/30 第10回ITRC総会・研究会 20 まとめ • QoSコントロールアーキテクチャにおいて、QoSサーバが最適 な経路を提供するための計算法を提案した。 – “経路設計”と“LSP設計”の二段階設計。 – LSP設計では整数計画法を採用。 – サービスの特性により目的関数を選択、採用。 • LSP設計法の定量評価を行った。 – 提案方式ではリンクのリソースを均等に使用。 – 従来方式に比べ、トラヒックの収容効率が高くなることが分かった。 2001/10/30 第10回ITRC総会・研究会 21