アプリケーションの体験品質

アプリケーションの体験品質の概要

クラウド コンピューティング、モビリティ、Web ベースのアプリケーションが増え続け、ネットワークはアプリケーション レベルでトラフィックを識別して制御し、ユーザーに QoE(ユーザー エクスペリエンス品質)を提供するために各アプリケーション タイプを個別に処理する必要があります。アプリケーション固有の QoE(AppQoE)を確保するには、パフォーマンスや可用性を損なうことなくアプリケーション トラフィックの優先順位付け、分離、ルーティングを効果的に行う必要があります。

AppQoE は、2 つのアプリケーション セキュリティ サービス(アプリケーション識別(AppID)と高度なポリシーベースのルーティング(APBR)の機能を活用(または採用)します。AppIDを使用してネットワーク内の特定アプリケーションとAPBR(高度なポリシーベースのルーティング)を識別し、アプリケーショントラフィックがAPBRルール単位で送信されるルーティングインスタンスにSLAプロファイルを関連付け、特定のトラフィックのパスを指定します。

Software-Defined WAN(SD-WAN)の重要な要件の 1 つは、アンダーレイ ネットワーク パスの品質を測定し、結果に基づいて各パケットの配信に使用する最適なパスを決定する方法です。AppQoE は、ビジネスクリティカルな アプリケーションのパフォーマンスを監視し、そのスコアに基づいて、SLA(サービスレベル契約)で指定されたパフォーマンス要件を満たすために、そのアプリケーション トラフィックに最適なリンクを選択します。

APBR設定にSLAルールが存在すると、AppQoE機能がトリガーされます。SLA プロファイルが使用できない場合は、AppQoE をトリガーせずに APBR が機能します。

• サポートされている使用事例
• サポートされているSRX シリーズ デバイス

アプリケーションの体験品質のメリット

• アプリケーション トラフィックをリアルタイムに監視して、一貫した予測可能なサービス レベルを提供することで、コスト効率の高い QoE を実現します。

• 特定のトラフィック(動画トラフィックなど)の配信に SLA を保証することで、顧客の維持と満足度が向上します。AppQoE では、承認されたトラフィックが適切な優先度を受け取り、ユーザーに最高の体験品質を提供するために必要な帯域幅を確保します。

制限

セキュリティ デバイスへの AppQoE の実装には、以下の制限があります。

• 宛先へのルートは、インターフェースが異なってすべて、同じ設定、重み、メトリックが設定されている必要があります。すべてのルートは宛先の ECMP パスとして追加する必要があります。また、同じ転送テーブルの一部である必要があります。

• AppQoE SLA サービスは、2 つのセキュリティ デバイスエンドポイント(ブックエンド)間でのみサポートされています。エンドツーエンドのAppQoE SLAサービスはサポートされていません。

• AppQoE は、すべてのインターフェイスが同じゾーンに含されている場合にのみ適用できます。

• AppQoE は、リバース トラフィックには適用できません。

• AppQoE は、セッションの宛先の変更には影響を与えるされません。

• AppQoE は、IPv6/UDP プローブ カプセル化、GRES、シャーシ クラスター(ISSU、高可用性、デュアル CPE 高可用性、Z モード高可用性、論理システム)をサポートしていません。

• AppQoE は優先パス選択をサポートしていない。また、VRF(Transit Virtual Routing and Forwarding)はサポートされていません。

• AppQoE は、IPv6 データ パケットに対するパッシブ プロブリングをサポートしません。

• 非 WAN インターフェイスでは、UDP 宛先ポート 36000 で UDP パケットを破棄するために、入力ファイアウォール フィルタが必要です。

• SRX4600デバイスには、次の制限があります。

  • AppQoE サービス クラス設定CoS GRE(汎用ルーティング カプセル化)のプロトコル(プロトコル プロトコル)はサポートされていません。

  • パッシブ プローブの詳細は、短距離の各セッションでは使用できない場合があります。

  • シャーシ クラスタ モードでデバイスが動作している場合、Z ライン モードのトラフィック処理では、セッションの状態がセカンダリ ノードで同期されない可能性があります。

アプリケーションの体験品質の仕組み

AppQoEは、AppIDとAPBRの機能を利用して特定のアプリケーション/アプリケーショングループを識別し、アプリケーショントラフィックがAPBRルール単位で送信されるルーティングインスタンスにSLAプロファイルを関連付け、特定のトラフィックのパスを指定します。

AppQoE は、アプリケーションのパフォーマンスを監視し、スコアに基づいて、SLA(サービスレベル契約)で指定されたパフォーマンス要件を満たすために、そのアプリケーション トラフィックに最適なリンクを選択します。

• アプリケーションまたはアプリケーション グループの識別
• アプリケーションまたはアプリケーション グループのパスの指定
• アプリケーション トラフィック パスの選択

アプリケーションエクスペリエンスの質がアプリケーションのパフォーマンスをどのように測定するか

アプリケーションのパフォーマンスは、以下の指標によって決定されます。

• 遅延 : メディアの長さと距離に応じて、メディアを物理的に移動するために必要な時間(カバーする必要がある時間)

• RTT—送信元から宛先への転送に必要なラウンド トリップ時間(その逆)

• パケット損失—パケット ロスは、ホストによって送信された 100 パケットごとに失われたパケット数を反映します。

• ジッター:ジッターはパケットからパケットへの遅延の違いです。イングレス ジッター、エグレス ジッター、およびツーウェイ ジッターを指定して、リンクのパフォーマンスを評価できます。

AppQoE は、各リンクで RTT、ジッター、パケット ロスを監視し、スコアに基づいて、プライマリ リンクのパフォーマンスが SLA で指定された許容レベルを下回っている場合、アプリケーションを代替パスにシームレスに移動します。アプリケーション パフォーマンスの測定と監視は、アクティブなプローブとパッシブ プローブを使用して SLA 違反を検出し、その特定のアプリケーションの代替パスを選択して実行します。

AppQoE は、アプリケーション トラフィックを継続的に監視し、以下を実行してネットワークやデバイスの問題を特定することで、リアルタイム データを収集します。

• 設定済みのすべてのオーバーレイ リンクのパフォーマンスを監視する。

• パッシブ プローブ(アプリケーション データ パスとインライン)とアクティブ プローブ(特定のアプリケーション用の合成プローブ)を使用して、アプリケーションまたはアプリケーション グループのトラフィック パフォーマンスを監視します。

• 収集したすべてのパフォーマンス メトリックまたは分析用メタデータをログ コレクターに送信する。

• 特定のアプリケーションと特定のパフォーマンス メトリックを比較し、SLA 違反が発生した場合にアプリケーション トラフィックのパスを動的に変更します。

• 特定のアプリケーションまたはアプリケーション グループに対する柔軟な SLA メトリック設定をサポートします。

AppQoE では、複数の WAN リンクにわたるアプリケーション SLA を測定し、アプリケーション トラフィックを利用可能なリンク間のパス、つまり SLA 要件に最も応えるパスにマッピングします。

アプリケーション トラフィックを代替パスに切り替える

SLA 違反中に、アプリケーション トラフィックから別のルート(デバイスへのローカル)への切り替えを有効または無効にできます。ローカル ルート スイッチングが有効になっている場合は、アプリケーション トラフィックを別のルートに切り替え、SLA の監視とレポート機能も使用できます。SLA ルール設定でアプリケーション トラフィックを代替パスに切り替えるオプションが無効になっている場合でも、AppQoE は SLA 違反を解決します---たとえば、アプリケーション トラフィックを新しいパスに切り替えて、

ローカル ルート スイッチングが無効になっている場合は、SLA の監視とレポート機能のみを使用し、SLA 違反によりアプリケーション トラフィックを別のルートに切り替えるのが有効になります。

アプリケーション トラフィックが別のパスに切り替わると、SLA 違反の場合にアプリケーション トラフィックを別のパスに再び切り替えできない短い期間が発生します。この期間は、リンク上のトラフィックのフラッピングを回避するのに役立ちます。

アプリケーション パスの優先度と優先度のメリット

• アプリケーション トラフィックに最適なパスを柔軟に選択できます。

• SLA 要件(遅延およびジッター)を満たしながら、コスト効率に良い接続オプションを使用してアプリケーション トラフィックのルーティングを可能にします。

• 選択したアプリケーション パスの品質が低下した場合、動的パス スイッチングをサポートします。

パス選択メカニズム

アプリケーション トラフィックは、リンクの好みに基づいて、以下のように別々のリンクを通じてルーティングされます。

• AppQoE パス選択メカニズムには、SLA 要件を満たす特定の宛先への最適なパスのリストが含まれています。このリストから、AppQoE はユーザーが設定したリンク設定に一致するパスを選択します。

• このようなパスが複数ある場合、その中で最も優先度が高いパスが選択されます。

• 優先度またはリンク タイプの優先度が設定されていない場合は、ランダム パスまたはデフォルト パスが選択されます。

• SLA 要件を満たすリンクが使用できない場合は、最高の SLA スコアとリンク タイプの設定(厳密なアフィニティが設定されている場合)で使用可能な最適なリンクが選択されます。

• SLA 要件を満たすリンクが複数ある場合は、最も優先度の高いリンクが選択されます。

RTT およびジッターの無効な値のレポート

RTT およびジッターのデータを使用できない場合、無効な値の 0xFFFFFFFF で送信されたログ メッセージは、ログ コレクターによって無視できます。 表 2 は、 無効な RTT とジッターが送信された場合のシナリオを示しています。

APBRでのDSPサポート

APBR ルールで DSCP と動的アプリケーションの両方を設定する場合、トラフィックがルールで指定された条件すべてと一致するとルールが一致すると見なされます。APBR ルールに複数の DSCP 値が存在する場合、1 つの条件が一致すると、その値が一致すると見なされます。

APBRプロファイルには複数のルールを含め、各ルールにはさまざまな一致条件を設定できます。

APBRプロファイル内の複数のAPBRルールの場合、ルールルックアップでは次の優先順序が使用されます。

1. DSCP + 動的アプリケーションを使用したルール

2. 動的アプリケーションを使用したルール

3. DSCP 値を持つルール

Network Service Orchestrator は、外部サービス機能でアプリケーションを DSCP 値にマッピングし、同じ値をゲートウェイ ルーターでプロビジョニングして、DSCP を目的の SLA プロファイルにマッピングできます。

図 1 は、ゲートウェイ ルーターの使用事例において、DSCP 値とアプリケーション シグネチャーに基づいて受信トラフィックの SLA ベースのパス選択を AppQoE で実行するシナリオを示しています。

図 1:DSCP値とアプリケーションに基づくトラフィックのパス選択

DSCP 値に基づくトラフィックの場合、AppQoE は次のように動作します。

• LAN からゲートウェイ ルーターに入るトラフィックはすべて、アプリケーション識別を実行します。DPI がアプリケーションを識別するまで、システムはトラフィック ストリームをデフォルトの転送仮想ルーティングおよび転送(VRF)インスタンスに転送します。VRF には、VRF に関連付けられた送信インターフェイスが含まれています。

• Junos OS識別によってアプリケーションが識別され、アプリケーションが識別されると、その情報がアプリケーションシステムキャッシュ(ASC)に保存されます。

• システムは、DPI分類または ASCから利用可能なアプリケーション情報が引き続き確認されます。

• APBRメカニズムは、既知のアプリケーションシグネチャとDS DSCP値に基づいてセッションを分類し、ポリシーを使用してアプリケーションの最適なルートを識別します。APBR ポリシーによって、アプリケーション トラフィックが特定の VRF にマッピングされます。

• APBR設定にSLAルールが存在すると、AppQoE機能がトリガーされます。AppQoE では、アプリケーションまたは DSCP 値に基づいてトラフィックの SLA ベースのパス選択を実行します。

1 つの DSCP に、バンドルされた複数のアプリケーション カテゴリーが含まれています。アプリケーションカテゴリーは異なって、個々のアプリケーションのトラフィック パターン。このようなシナリオでは、パッシブ プローブを使用して違反を検知し、それをすべてのセッションに適用すると、誤検知や誤検知が発生する可能性があります。回避策として、DSCP ベースの SLA ルールを設定した場合に、パッシブ プロブリングを使用する必要はありません。アクティブなプローブは、トラフィックが転送される宛先パス グループに対して使用できます。

制限

ルート変更のネクストホップ ID が設定されている場合は、SLA 要件を満たす別のリンクが利用できる場合でも、既存のセッションは SLA 違反のリンクに残ります。ただし、この場合は新しいセッションは影響を受け、SLA 要件を満たすリンクを通してルーティングされます。

IPv6トラフィックのサポート

• リリース 21.3R1 Junos OS、AppQoE 設定で IPv6 アドレスを使用できます。このサポート内容は以下のとおりです。

  • オーバーレイ パス設定の IPv6 アドレス
  • IPv6アドレスを送信元および宛先アドレスとして使用したアクティブなプロビリングセッション。
  • クライアント側からのIPv4およびIPv6トラフィック
  • LAN側でのIPv4とIPv6のデュアルスタック
  • SaaS(Software as a Service)プロブリング用LAN側のIPv6アドレス。

    SaaS プロブリングの場合、IPv4 と IPv6 の相互運用性を実現するために、受信インターフェイスに IPv4 と IPv6 の両方のアドレスを設定してください。

• Junos OS リリース 21.4R1 から、AppQoE 構成のオーバーレイ ネットワークおよびアンダーレイ ネットワークに IPv4 と IPv6 のデュアル スタックを使用できます。