これはToSフィールド（例：IPフレームのDifferentiated Servicesフィールド）の４パートからなるシリーズのパート5です。４パートのブログにパート５をつけるなんて冗談です。

 

パート１から４を読んでおいてください。

もう一度、わたしの最初のブログからWireShark キャプチャを書きます。

※    図

上の図のDifferentiated Servicesフィールドの一部である２つのECN (Explicit Congestion Notification) ビットに注意してください。それらはブログ３で1998年に書かれたRFC2474からの“現在は使われていない”ビットです。“現在は使われていない”（普通は:) 二つのビットはRFC3168で1998年に定義されました。

 

二つのECNビットは混雑状態を示すためにホストかルータに使われています。

  • ECN-Capable Transport (ECT) = 10 or 01
  • Not-ECN-Capable Transport (Not-ECT) = 00
  • Congestion Experienced (CE) = 11NOTE: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.

TCPとECNの操作

Wikipediaには書いてないのでいくつかの文を貼り付けておきます。

＜貼り付け開始＞

IPヘッダーのECNビットによると、TCPはTCPヘッダーで送信者が送る情報を減らすために送信者に信号を送るTCPヘッダーで二つのフラッグを使用します。これはECNエコーと下記で説明するCongestion Window Reduced (CWR)です。

TCPコネクションでのECNの使用はオプションです。ECNが使われるにはSYNとSYN－ACKセグメントの最適なオプションを取り入れることにより作られるコネクションで交する必要がある。ECNがTCPコネクションに関して取り決められると送信者はECN-capableコードポイントで全てのデータセグメントに印を付けます。これから起こる混在状態を検出するルータはECN-capableパケットに完全に落とすというよりもCongestion　Experienced コードポイントで印を付けることを選択します。

 

　Congestion　Experienced コードポイントでTCPセグメントを受信すると、TCPレシーバーがECNエコーフラッグセットでの確認を送信します。ECNエコービットはパッケトを落として混雑ウィンドウを減らす送信者へ混雑状況を提示します。Congestion Window Reduced コードポイントでセグメントを送ることで混雑表示を認識します。

＜貼り付けの終わり＞

写真を見ていると思います。もっと勉強したければ、ＲＦＣを読んで下さい。1981年まで保存されたビットを彼らが使っていて2001年にその使用方法を見つけたと想像してください。

それは先を読んでのことですか、それとも何？

よいビットは80年代初旬戻って保存されました。ＥＣＮエコーフラッグの設定をやめる時を決定するＴＣＰレシーバーを有効にするためにTCPヘッダー（ＣＷＲフラッグ）に二つ目の新しいフラッグを導入しました。

CWRフラッグはＴＣＰヘッダーのResearved フィールドのビット8に割り当てられます

 

上部はRFC793に定義されたTCPヘッダーのバイト14と13（ビットではない）の新しい定義です。2006年のRFC4774はECNに関して改善を試みていますが、このシリーズからの休暇が必要です。

最後に、ECNビットの表示をレポートしているScrutinizerｖ７のネットフローレポートはどのようにECNビットを表示するか下記を見てください。

ネットワークの混雑状況を示すためにネットフローのECNビットを使えないかなと考えています。　　　お読みいただきありがとうございました。