MPLSセッションに関する統計の収集

パケット損失と遅延を測定することの重要性

IPTVやモバイルビデオなど、帯域幅を消費するアプリケーションの台頭と、ビットあたりのコストを最小限に抑え、ビットあたりの価値を最大化しなければならないというプレッシャーにより、キャリアはトランスポートネットワークを回線ベースの技術からパケットベースの技術に移行することを余儀なくされています。MPLSは、広く成功を収めているコネクション指向のパケットトランスポート技術であり、パケットベースのトランスポートネットワークに最適です。

データネットワーク上に新しいアプリケーションが登場するにつれ、サービスプロバイダにとって、新しいアプリケーションの展開による影響を正確に予測することがますます重要になっています。ネットワーク内のネットワークパフォーマンスを理解し、モデル化することは、実装を成功させるための新しい世界のアプリケーションの導入に特に関連しています。パケットネットワークでは、パケットロスと遅延はパフォーマンスの最も基本的な指標の2つです。エンドツーエンドの測定に関しては、彼らの役割はさらに中心的なものになります。

ほとんどのエンドツーエンド ユーザー アプリケーションに属するトラフィックは、損失敏感(ファイル転送)、遅延敏感(音声またはビデオ アプリケーション)、またはその両方(インタラクティブ コンピューティング アプリケーション)のいずれかです。SLAは、サービスプロバイダネットワークにおけるカスタマートラフィックエクスペリエンスの損失と遅延に直接的または間接的に依存しているため、サービスプロバイダのサービスレベル契約(SLA)は、これらのネットワークパフォーマンスメトリックを測定および監視する能力に依存しています。

SLAのコンプライアンスを確保するために、サービスプロバイダは、パケットロス、一方向遅延と双方向遅延のパフォーマンスメトリック、および遅延変動やチャネルスループットなどの関連メトリックを測定および監視するためのツールを必要としています。この測定機能により、サービスプロバイダはネットワークのパフォーマンス特性に対する可視性が向上し、計画、トラブルシューティング、ネットワークパフォーマンス評価が容易になります。

パケットロス、遅延、スループットの定義

パケットネットワークでは、パケットロスと遅延はパフォーマンスの最も基本的な指標の2つです。

• Loss - パケット損失とは、1 つ以上の送信パケットが宛先に到着しないことです。パケット損失とは、混雑を管理するためにネットワークによってドロップされるデータのパケットを指します。

  データアプリケーションは、一般に時間に依存せず、ドロップされたパケットを再送信できるため、パケット損失に非常に耐性があります。ただし、ビデオ会議環境やVoIPなどの純粋な音声通信では、パケット損失によってジッターが発生する可能性があります。

• Delay - パケット遅延(遅延とも呼ばれます)とは、銅線、光ファイバー、電波などの伝送媒体の速度と、ルーターやモデムなどのデバイスによる転送の遅延に応じて、データパケットが特定のポイントから別のポイントに到達するのにかかる時間です。

  遅延が低いということは、ネットワーク効率が高いことを示します。

• Throughput - パケット遅延はアクションの開始から完了までの時間を測定し、スループット は特定の時間内に発生したアクションの総数です。

パケット損失と遅延測定メカニズム

パケット遅延とパケット損失は、ネットワークパフォーマンスの2つの基本的な尺度です。Junos OSは、関連する双方向MPLSのUHP(最終ホップポッピング)LSP(ラベルスイッチパス)上でパケットロスと遅延を測定するオンデマンドメカニズムを提供します。

オンデマンド遅延およびパケット損失測定メカニズムは、以下のCLIコマンドを使用して開始されます。

• monitor mpls loss rsvp—関連する双方向UHP LSPのオンデマンド損失測定を実行します。

• monitor mpls delay rsvp—関連する双方向UHP LSPのオンデマンド遅延測定を実行します。

• monitor mpls loss-delay rsvp—関連する双方向UHP LSPの損失と遅延の複合測定をオンデマンドで実行します。

遅延とパケット損失の測定メカニズムを開始するには、測定の種類やLSP名など、測定に必要なパラメータを入力する必要があります。パラメーターを受信すると、パフォーマンス監視データの概要が表示され、メカニズムが終了します。

パケット損失と遅延のメトリック

次のパフォーマンスメトリックは、オンデマンドのパケット損失と遅延メカニズムを使用して測定されます。

• 損失測定(パケットとオクテット)

• スループット測定(パケットとオクテット)

• 双方向チャネル遅延

• 往復遅延

• IPDV(Inter-Packet Delay Variation)

monitor mpls loss rsvpコマンドは損失とスループット測定を実行し、monitor mpls delay rsvpコマンドは双方向チャネル遅延、ラウンドトリップ遅延、およびIPDV測定を実行します。monitor mpls loss-delay rsvpコマンドは、損失と遅延の複合測定を実行し、上記のすべてのパフォーマンスメトリックを同時に測定します。

パケット損失と遅延測定の概念

以下の概念は、パケット損失と遅延の機能をよりよく理解するのに役立ちます。

• Querier—クエリアはイングレスプロバイダーエッジ(PE)のルーターであり、損失または遅延の測定に関するクエリメッセージを発信します。

• Responder—レスポンダは、クエリアからのクエリメッセージを受信して応答するエグレスPEルーターです。

• Associated bidirectional LSP—関連する双方向LSPは、両方のLSPエンドポイントの設定を通じて結ばれている(または相互に関連付けられる)2つの単方向LSPで構成されています。

  オンデマンドの損失と遅延の測定は、関連する双方向UHP LSPでのみ実行できます。

• Generic associated channel (G-Ach)—オンデマンド損失および遅延測定のパフォーマンス監視メッセージは、MPLS G-ACHを介してフローします。このタイプのチャネルは、帯域内応答のみをサポートし、帯域外または応答なしモードはサポートしません。

• Measurement point (MP) - MP は、測定の条件が記述される場所です。

  送信側のパケットロスに対する MP は、スイッチング ファブリックと送信インターフェイスの間で発生します。カウンタ値は、送信のためにキューに入れられる前に、ハードウェアの損失測定メッセージに刻印されます。

  受信側のパケット損失の MP は、受信インターフェイスとスイッチング ファブリックの間で発生します。MP は受信側で配布されます。さらに、送信インターフェイスが集約インターフェイスの場合、MPも分散されます。

• Query rate—クエリレートは、損失と遅延の測定のために送信された2つのクエリ間の間隔です。

  損失と遅延の測定メッセージはルーティングエンジンから発信されるため、複数のチャネルの高いクエリレートはルーティングエンジンに大きな負担をかけます。サポートされる最小クエリ間隔は 1 秒です。

  32ビットカウンターの場合、データトラフィックレートが非常に高い場合、カウンターがすぐに折り返される可能性があるため、クエリレートを高くする必要があります。損失測定に関係する 4 つの測定ポイントの場所すべてで 64 ビット カウンターが使用されている場合、クエリー レートは低くなる可能性があります。Junos OSは、64ビットカウンターのみをサポートしています。

• Traffic class—デフォルトでは、損失測定はチャネル全体でサポートされています。Junos OSは、トラフィッククラススコープのパケット損失測定もサポートしており、トラフィッククラスごとのデータトラフィック統計を維持するカウンターを作成する必要があります。

  トラフィッククラスごとのカウンターは、デフォルトでは作成されません。トラフィッククラススコープの損失測定を設定するには、[edit protocols mpls statistics]階層レベルでtraffic-class-statisticsステートメントを含めます。

  traffic-class-statisticsが設定されている場合、G-Ach上を流れる制御パケットは送受信カウンターにカウントされません。

  注:

  トラフィッククラス統計を有効または無効にすると、LSPのすべてのカウンター(集約カウンターとクラスごとのカウンター)がリセットされます。

• Loss measurement mode—Junos OSオンデマンド損失測定のダイレクトモードをサポートし、推論モードはサポートしません。

  直接損失測定では、関連する双方向LSPの2つの単方向LSPのingressおよびegressでデータトラフィック統計を維持する必要があります。MXシリーズルーターがMPCとMICのみを使用している場合、すべてのタイプのLSPのingressとUHP LSPのegressで、データトラフィック統計を維持するためのカウンターがデフォルトで作成されます。

  ただし、損失測定の直接モードは、次の理由により完全に正確ではありません。

  • ハードウェアのパラレルフォワーディングの性質。

  • 集合型イーサネットインターフェイスなどのネットワーク内に等価コストマルチパス(ECMP)が存在すると、損失測定メッセージに対してデータパケットの順序が変更される可能性があります。

  • G-Ach上を流れない制御パケットは、LSP ingressではカウントされませんが、LSP egressではカウントされます。

  • DiffservがMPLSネットワークに実装されていて、損失測定スコープが完全なチャネルであり、トラフィッククラスのスコープではない場合、損失測定メッセージに対するデータトラフィックの並べ替え。

    この制限を克服するには、Diffservが実装されているときにトラフィッククラススコープの損失測定を実行します。

  注:

  直接モード損失測定は、LSP に関連するイングレスまたはエグレス インターフェイスが変更された場合に中断されやすくなります。

• Loss measurement synchronization - RFC 6374 のセクション 2.9.8 で指定された同期条件は、絶対的な意味では当てはまりません。ただし、損失測定カウンタはハードウェアに刻印されているため、同期条件を満たさないことによる誤差は比較的少ないです。これらの誤差は定量化する必要があります。

  LSPの送信または受信インターフェイスが集約インターフェイスの場合、インターフェイスが非集約インターフェイスの場合と比較して、より多くのエラーが発生します。いずれにせよ、損失測定カウンタはハードウェアに刻印されており、誤差を定量化する必要があります。

• Delay measurement accuracy—送信インターフェイスと受信インターフェイスが異なるパケット転送エンジン上にある場合、双方向遅延測定のためにこれらのパケット転送エンジンでクロックを同期させる必要があります。この条件は、オンデマンド遅延測定機能が実装されているプラットフォームに当てはまります。

  集約インターフェイスまたはECMPが存在する場合、遅延は潜在パスの1つだけ測定されます。

  遅延計算に損失と遅延を組み合わせたメッセージを使用すると、送信または受信インターフェイスが集約インターフェイスの場合など、場合によっては遅延測定メッセージを使用する場合と比べて、遅延の精度が低下します。

  遅延測定は常にトラフィッククラス単位で実行され、テスト後に測定の精度を定量化する必要があります。

• Timestamp format—Junos OS遅延測定メッセージを記録するためのIEEE 1588 PTP(Precision Time Protocol)[IEEE1588]形式のみをサポートします。Network Time Format(NTP)はサポートされていません。

• Operations, administration, and maintenance (OAM)-MPLS LSPのすべてのOAMメッセージがMPLS G-Achを経由することを示し、MPLSのパフォーマンス監視メッセージをMPLS G-Ach上で伝達できるようにするには、[edit protocols mpls label-switched-path lsp-name]階層レベルにoam mpls-tp-modeステートメントを含める必要があります。

パケット損失および遅延測定機能

図1は、パケット損失と遅延の双方向測定に使用する基本的な方法を示しています。双方向チャネルは、ルーターAとルーターBの2つのルーター間に存在します。時間的な基準点(T1、T2、T3、およびT4)は、ルーターAで行われる測定操作に関連付けられています。この操作は、ルーターAがルーターBにクエリメッセージを送信し、ルーターBが応答を送り返すことで構成されています。各参照ポイントは、クエリまたは応答メッセージのいずれかがチャネルを介して送受信された時点を示します。

図1では、ルーターAは、損失測定クエリメッセージをルーターBに送信することで、順方向および逆方向のチャネル上のパケット損失を測定するように手配できます。各フォワードおよびリバースメッセージには、時間T1より前にチャネルを介してルーターB(A_TxP)に送信されたパケット数が含まれています。

メッセージがルーター B に到達すると、2 つの値がメッセージに追加され、メッセージがルーター A に反映されます。2つの値は、時間T2より前にルーターA(B_RxP)からチャネル経由で受信したパケット数と、時間T3より前にルーターA(B_TxP)からチャネル経由で送信されたパケット数です。

応答がルーター A に到達すると、4 番目の値がメッセージに追加されます。これは、ルーター B(A_RxP)からチャネルを介して時間 T4 より前に受信したパケット数です。

これら4つのカウンタ値((A_TxP)、(B_RxP)、(B_TxP)、(A_RxP)により、ルーターAは目的の損失統計を計算できます。ルーターAの送信カウントとルーターBの受信カウント(またはその逆)は、最初のメッセージの時点で同期しない場合があるため、カウンターラップの影響を制限するために、損失はメッセージ間のデルタの形で計算されます。

メッセージLM[n-1]およびLM[n]でマークされた測定間隔内の送信損失(A_TxLoss[n-1,n])と受信損失(A_RxLoss[n-1,n])は、ルーターAによって次のように計算されます。

1. A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

2. A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])

算術演算はカウンターサイズをモジュロします。

ルーターAでルーターBへのチャネル上の遅延を測定するために、送信された瞬間を記録したタイムスタンプを含む遅延測定クエリーメッセージがルーターAからルーターBに送信されます。 図1では、タイムスタンプがT1に記録されています。

メッセージがルーター B に到達すると、タイムスタンプが追加され、メッセージを受信した瞬間(T2)を記録します。これで、ルーターBからルーターAにメッセージが反映され、ルーターBが送信タイムスタンプ(T3)を追加し、ルーターAが受信タイムスタンプ(T4)を追加します。

これら4つのタイムスタンプ(T1、T2、T3、T4)により、ルーターAは各方向の一方向遅延とチャネルの双方向遅延を計算できます。一方向の遅延計算では、ルーターAとBのクロックを同期させる必要があります。

この時点で、ルーターAは、チャネルに関連する双方向チャネル遅延と往復遅延を次のように計算できます。

1. 双方向チャネル遅延 = (T4 - T1) - (T3 - T2)

2. 往復遅延 = T4 - T1

パケット損失および遅延機能

Supported Features of Packet Loss and Delay

Junos OSは、オンデマンドの損失と遅延の測定で、以下の機能をサポートしています。

• 関連する双方向MPLSポイントツーポイントUHP LSPのみのパフォーマンス監視

• 損失測定

• スループット測定

• 双方向遅延測定(チャネル遅延とラウンドトリップ遅延)

• IPDV(Inter-Packet Delay Variation)

• ダイレクトモード損失測定

• 集合型イーサネットおよび集合型SONETインターフェイス

• マルチシャーシのサポート

• 64ビット互換

Unsupported Features of Packet Loss and Delay

Junos OSは、以下のオンデマンド損失および遅延測定機能をサポートしていません。

• 疑似配線の損失と遅延の測定(RFC 6374のセクション2.9.1)

• 一方向測定(RFC 6374のセクション2.6)

• 二者間測定(RFC 6374のセクション2.7)

• ループバックモードでの損失と遅延の測定(RFC 6374のセクション2.8)

• LSP エンドポイントから中間ノードへの損失と遅延の測定(RFC 6374 のセクション 2.9.5)

• 外部後処理(RFC 6374のセクション2.9.7)

• 推定モード損失測定(RFC 6374のセクション2.9.8)

• 事前対応モード

• 論理システム

• SNMP