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)

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 のイングレスおよびエグレスでデータ トラフィック統計が維持される必要があります。MXシリーズルーターがMPCとMICのみを使用している場合、データトラフィック統計を維持するためのカウンターは、デフォルトですべてのタイプのLSPのイングレスとUHP LSPのエグレスで作成されます。

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

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

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

  • G-Ach を経由しない制御パケットは、LSP イングレスではカウントされませんが、LSP エグレスではカウントされます。

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

    この制限を克服するには、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]フォーマットのみをサポートしています。ネットワーク時刻形式 (NTP) はサポートされていません。

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

パケット損失と遅延の測定機能

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

図 1: 基本的な双方向測定

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

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

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

これら 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が送信タイムスタンプ(T3)を追加し、ルーターAが受信タイムスタンプ(T4)を追加することで、メッセージをルーターBからルーターAに反映できます。

これら 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)

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

• 集合型イーサネットおよび集約型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