ボンドグラフと熱伝導解析による EHA熱解析ツールの開発

Size: px

Start display at page:

Download "ボンドグラフと熱伝導解析による EHA熱解析ツールの開発"

るるみくぬぎ
5 years ago
Views:

1 計算機通信基礎 (9). インターネットの技術 01 年度九州工業大学大学院情報工学研究院塚本和也今日の授業の内容前回の授業の内容について. インターネットの技術.1 経路制御. 誤り制御. フロー制御と輻輳制御前回の授業内容についてインターネット上で用いられているネットワーク技術についてその特徴を解説する経路制御 : データグラム方式 ( とバーチャルサーキット方式 ) IP と IP アドレスクラス化サブネット化 NAT/NAPT 経路制御プロトコル IGP: 距離ベクトル型リンク状態型 EGP: パスベクトル型 (IGP) 境界 (EGP) IGP 前回小テスト解答例経路制御方式であるバーチャネルサーキットとデータグラム + ホップバイホップ通信の違いについてそれぞれ利点と欠点を明示した上で説明せよバーチャルサーキット : 利点 : 経路を事前に確立するため高い信頼性を提供可能輻輳の解消が速やかに可能欠点 : 経路確立までに登録が必要となるため時間がかかるの処理負荷が大きいデータグラム + ホップバイホップ通信 : 利点 : 迅速に通信開始可能の処理負荷が小さくスケーラビリティが高い欠点 : 遅延やパケット廃棄が発生し信頼性が低い輻輳の解消に時間がかかる前回小テスト解答例.. IP アドレスの使用用途及びそれによる効果と問題点についてそれぞれ説明せよまたその問題点を解決するための方法についても説明せよ IP アドレスの使用用途 : (1) ホスト ( 計算機 ) の識別 () 経路決定クラス化による効果経路制御を容易にした内の経路表のエントリ数を削減 ( スケーラビリティの向上 ) クラス化の問題点アドレスの利用効率が悪い ( ネットワーク規模に応じた柔軟な割当が不可 ) 問題点の解決方法 IPv6 アドレスの導入 ( アドレス空間拡大 ) プライベート IP アドレスの導入 (NAT 導入 ) プライベートネットワークサーバ+ NAT 機能インターネット前回小テスト解答例.. 経路制御プロトコルの種類について最初に説明した上でそれぞれのプロトコルの特徴や制御上の違いについて説明せよ経路制御プロトコルの種類は種類距離ベクトル型の RIP: 距離と方向による経路制御リンク状態型の OSPF: ネットワーク全体の接続状況を把握して経路制御パスベクトル型の BGP: 到達できるネットワークのリストを利用して経路制御制御上の違い RIP と OSPF:AS 内プロトコルネットワーク資源の有効利用が目的 BFP は AS 間プロトコル契約に基づく経路制御が目的 (IGP) 境界 (EGP) IGP 6 1

2 . 誤り制御インターネットにおける経路制御 (.1 節 ) 宛先ホストに正しくパケットを配送できない可能性 1. ビット誤り : パケットは到着したがビットが正しくない場合. パケット廃棄 : パケットがネットワーク内で廃棄されるネットワーク内ので輻輳が発生しバッファあふれが発生 ~ パケット誤り (packet error) と呼ぶ正確な通信を行うには 1. パケット誤りを検出 ( 誤り検出 ). その誤りを回復 ( 誤り回復 ) ~ 上記をまとめて誤り制御 (error control) と呼ぶ 7 (.) 誤り検出と誤り回復誤り検出機能回復機能は様々な層で行われている ( 一つの層だけで行われるのではない!) 誤り検出機能トランスポート, インターネット, データリンクの各プロトコルに備わっている各ヘッダにチェックサム, チェックシーケンスフィールドが存在送信側 : 計算した値をヘッダに格納受信側 : 受信情報を元に再度チェックサムを計算不一致の場合誤りを検出可能誤りを回復する機能は主にトランスポート層で実装 UDP 誤り回復機能を保持せず TCP 誤り回復機能を備える 8 (.) TCP の誤り検出と回復機能誤り検出 : TCP のヘッダ内の確認応答番号フィールドを用いる誤り回復 : 1. 受信側で行う場合 : 受信パケットを用いて誤りを検出しその誤りを訂正 (error correction) する ~ FEC (Forward Error Correction) 方式と呼ぶ冗長なデータが必要なため利用シーンが限られる. 送信側で行う場合 : 送信者から再度パケットを送信 ~ ARQ(Automatic Repeat request) 方式と呼ぶ誤り検出方法として種類が存在受信側からパケット誤りを陽に知らせる (Explicit 手法 ) 受信側から陽には知らせず送信側で推定 (Implicit 手法 ) 9 (.) Explicit 手法と Implicit 手法 Explicit 手法 ( パケット誤りを陽に通知 ) の実装例 ~ 選択的確認応答 (selective acknowledgement) 新しい TCP にオプションとして搭載し始められている Implicit 手法 ( パケット誤りを推定 ) の実装例 ~ 累積確認応答 (cumulative acknowledgement) 従来の TCP で広く用いられてきた正しく受信できたシーケンス番号の最大値のみを伝えるパケット誤りの判断の方法タイムアウト (timeout) 長い時間確認応答が戻ってこない ~ 重度の輻輳が発生したと判断重複確認応答 (duplicate acknowledgement: 重複 ) 確認応答は戻ってくるが一部欠損 ~ 軽度の輻輳が発生したと判断 10.(a) 受信側におけるビット誤り検出 1 ビット誤り雑音により, 送信したビット列の信号が正しく受信機に伝わらない場合を指す引き起こす原因は雑音 ( ノイズ ) と呼ばれる何らかのエネルギーによる雑音 ( 熱雑音 ) 他の伝送媒体との干渉によるもの ( クロストーク ) 電力線などからの雑音 ( スパイク雑音 ) 雑音から守るための手段導線で回りを被覆する同軸ケーブル雑音が小さく低いビット誤り光ファイバ ( 光通信 ) 一方で空気を介した通信 ( 無線通信 ) 雑音の影響を強く受けるため高いビット誤りが発生.(a) 受信側におけるビット誤り検出ビット誤りの検出送信側 : 冗長 (redundant) な情報を真のデータに付加して伝送受信側 : 受信情報に誤りが含まれているかを判断誤り検出可能な符号誤り検出符号インターネットで採用誤りを訂正可能な符号誤り訂正符号 IP,UDP,TCP: チェックサムフィールドにパリティチェック (parity check) 方式を採用奇数個のビット誤りは検出できるが偶数個のビット誤りは検出不可データリンク層 : CRC(Cyclic Redundancy check) 符号が使われている連続的 ( バーストと呼ぶ ) なビット誤りを高い確率で検出可能 KビットのFCS( フレームチェックシーケンス ) を用いると Kビット以下の誤りを完全に Kビット以上も高い確率で検出可能 1

3 .(b) 送信側におけるパケット誤り検出 1 送信側 : 受信側が.(a) の機能を用いて検出した誤りを把握 ( 推定 ) ~ パケット再送を決定するパケット誤り検出方法 : TCP セグメントのヘッダ内のシーケンス番号と確認応答番号を用いる送信側 : 送信するセグメントに連続するシーケンス番号を付与シーケンス番号はバイト単位でセグメントの先頭バイトを格納受信側 : 正しく受信したセグメントの次のシーケンス番号次のセグメントの先頭のバイト番号 ~ 累積確認応答と呼ばれる多くの TCP プロトコルがパケット誤りの検出に用いる 1.(b) 送信側におけるパケット誤り検出累積確認応答を用いて送信側でパケット誤りを検出する場合 7 番目のセグメントがネットワーク上で廃棄されると仮定送信側では 7 番の確認応答を複数受信する重複つの重複を受信するとセグメント廃棄と判断し, 廃棄パケットを再送 ~ 高速再送 (fast retransmit) と呼ぶ重複も返ってこないような場合, 重度の輻輳と判断再送タイムアウト時間 (Retransmission Time Out, RTO) の設定 ~ タイムアウト時間が経過してもを受信できない場合パケットを再送受信セグメント廃棄番号重複時間 1.(c) 誤り回復のための再送 TCPは送信側による再送 (ARQ 方式 ) により誤りを回復 ARQには種類 1. stop-and-wait ARQ 方式. Go-back-n ARQ 方式. selective ( 選択的 ) ARQ 方式現在のTCPで用いられている方式 : ~ Go-back-n と selective TCP TahoeとReno:Go-back-n Sオプション付きTCP:selective S(Selective ): 選択的確認応答 ~ 正しく受信できたブロックを複数個通知する事ができるブロックの間 ( ギャップ ) を廃棄パケットと判断可能廃棄パケット複数個のパケットを一度に再送可能 * TCPヘッダのオプションフィールド長の制限から最大再送可能数は決定 1 (.(c)) 誤り回復 :Stop-and-wait ARQ 送受信ホストは同時通信不可半二重通信 (half-duplex) 基本動作 : 送信側は直前に送信したパケットに対するを受信するまで次のパケットを送信できないが戻ってこない場合タイムアウトが発生しパケットを再送通信性能 : 1 パケットの伝送時間 /RTT 1RTT 時間内に 1 パケットしか送信できないため 00Byte のパケットを 1Mb/s で送信する場合伝送効率は 10% 程度 ~ 広域ネットワークに不向き短距離で遅いネットワークには利用可送信側受信側 6 無線 LAN で利用されている 16 (.(c)) 誤り回復 :Go-back-n ARQ 送受信ホストが同時に通信可能な全二重通信が重要基本動作受信側でパケット誤りを検出すると, それに対するは返さず, その後に正しく受信したパケットに対してを返す累積確認応答送信側でパケット誤りを検出し再送したパケット以降の全パケットを再送下図ではパケット 8~1 を既に受信しているが再度再送 ( 下図橙箱 ) ~ 受信側で誤り検出後の受信パケットの蓄積 / 順序制御が不要 ( 実装が容易 ) ~ stop-and-wait より効率がよい送信が可能 ( 通信性能が向上 ) 送信廃棄 (.(c)) 誤り回復 :Selective ARQ 基本動作受信側から送信するにおいて正しく受信したパケット範囲 ( ブロック ) を知らせる選択的確認応答 (Selective ) ブロックのギャップから誤りパケットを把握し再送実現に必要な機能 ( 受信側 ) 実装は困難 1. 廃棄パケット後に受信したパケットを蓄積するバッファを用意. アプリケーションに順序通りにパケットを渡すための制御送信 RTTが大きい場合または高速ネットワークで有効廃棄受信重複 17 受信 1~ 1~6 1~6 1~6 1~6 1~6 8 8,9 8~108~ 18

4 . フロー制御と輻輳制御ネットワークを介した通信を考えてみる 1. 相手ホストの処理能力の利用状況を考えず送信. 処理しきれずパケットが廃棄される. 再送が行われる. 再送パケットの増加により輻輳が発生する.(a) 輻輳の検出送信側で輻輳を検出するための手段は以下の種類 1. ネットワークからの明示的な輻輳通知 (explicit notation) を利用フレームリレー,ATM などで採用されているへの機能の追加実装が必要 ( 複雑な機構になる ) ~ 検討はされているが普及はしていない通信ホストの処理能力を考慮して送信することが必要フロー制御 (flow control) ネットワーク内の輻輳 (congestion) 解消のためのフロー制御も必要輻輳制御 (congestion control) 19. 送信側で輻輳発生を予測する (implicit notation) TCP ではパケット廃棄によって輻輳を判断パケット廃棄が発生するまで輻輳と判断できない ~ 輻輳の検出が遅れる可能性が高い 0.(b) フロー制御輻輳検出時にパケットの転送速度を低下それ以外は転送速度を増加 ~ フロー制御として種類存在 1. レ - ト制御 (rate control): 各で発生するバッファ待機パケット数を減少させるための制御 ~ 各が次に送信する際にパケットの送信間隔を制御次には自分以外に台が接続同時にパケットが到着する可能性がある送信速度を 1/ に低下させようインターネットでの実現は困難 1. 細かい時間単位 ( 制度の高いタイマ ) での制御が必要. 他のの出力レートを把握するのは不可能 1.(b) フロー制御. ウィンドウフロー制御 : TCP ではさらに緩やかなフロー制御を採用 ~ ある時間間隔内で連続して送信可能なデータ量を制御ある時間間隔往復伝搬遅延時間 (RTT) 連続送信可能なデータ量ウィンドウサイズ緩やかな制御によってパケットの連続送信が可能 ~ 実装が容易 ~ 通信性能が向上可能ウィンドウサイズの決定方法が重要.(b) フロー制御ウィンドウサイズの決定方法 : ~ 相手ホストの処理能力とネットワークの利用状況を考慮受信ホストが送信ホストに処理可能なデータ量を告知ウィンドウ (advertised window: awnd) ( バッファの残りサイズ ) を通知送信側はネットワーク内の輻輳状況に応じて輻輳ウィンドウ (congestion window: ) を変化させるウィンドウサイズ ( 送信量 ) = min (awnd, ) ( 基本的に awnd > 送信量はで決定される ) awnd ウィンドウ制御.(b) フロー制御送信パケットの内現在送信可能な領域をウィンドウで示すウィンドウの開始点とウィンドウサイズウィンドウサイズネットワーク内部に存在するパケット数の最大値ウィンドウサイズはネットワーク状態に応じて変化どのように変更するかを次スライドから説明を受信したパケット送信されたがを受信していないパケットの最大数ウィンドウ未送信パケット

5 .(c) TCP における動的なウィンドウサイズ制御 1RTT 毎にウィンドウサイズで規定された量のパケットを連続して送信ウィンドウサイズを推定した輻輳状態に応じて 1RTT 毎に動的に変化させるパケット廃棄がなく, 全てのパケットのが返ってくる場合 : ~ 次の RTT の輻輳ウィンドウサイズを増加パケット廃棄を検出した場合 : ~ 輻輳が発生したと判断し輻輳を回避するためにウィンドウサイズを減少ウィンドウサイズの増減をどのように行うか?.(c) TCP における動的なウィンドウサイズ制御 TCP が通過する経路を他の TCP も共有する 1 つの TCP が利用可能な回線容量 ( 帯域 bandwidth) を知ることは極めて困難となるネットワーク内で競合する他の TCP の情報を把握できない : : TCP は試行錯誤してウィンドウサイズを大きくしたり小さくしながら他の TCP と帯域を共有輻輳を検出した場合急激にウィンドウサイズを小さくする輻輳が生じない場合利用可能な帯域まで早く到達するために早くウィンドウサイズを大きくしたい ( でも輻輳は避けたい ) TCP Tahoe と Reno を例にウィンドウサイズの変化方法を説明 6 (.(c)) 動的なウィンドウサイズ変更 : 増加 (1) 増加時 ( パケット廃棄が生じない場合 ): ウィンドウサイズの制御につのモード : ~ スロースタートモードと輻輳回避モードモード切替は閾値 (ssthresh) を用いる動作概要スロースタートモード ssthresh (Slow Start Threshold) 1 つの毎に =+1 1RTT でが倍に増加輻輳回避モード > ssthresh 1RTT 毎に =+1 1RTT でが 1 増加スロースタート輻輳回避 ssthresh 1 送信受信 7 (.(c)) 動的なウィンドウサイズ変更 : 減少 () 減少タイムアウトまたは重複によってセグメントの廃棄を検出すると ssthreth = / に更新 Cwnd も減少させる Tahoe = 1 Reno タイムアウト発生 : = 1 重複発生時 : = / ( 廃棄セグメントの再送が成功するまでの限定処理 ) 高速リカバリー (fast recovery) と呼ぶ 8.(c) 動的なウィンドウサイズ変更 1.(c) 動的なウィンドウサイズ変更 TCP Tahoe におけるの変化スロースタートモード 16 Ssthresh 輻輳回避モード更新 Ssthresh TCP Reno におけるの変化スロースタートモード 16 Ssthresh 輻輳回避モード更新 Ssthresh= 輻輳回避モード高速リカバリー時間 [RTT] 時間 [RTT] ネットワーク資源を複数の TCP で公平に効率よく共用する 0

6 今日のまとめ誤り制御とフロー制御技術を紹介した誤りはビット誤りとパケット廃棄の種類誤り制御誤り検出技術 : データリンクインターネットトランスポート層誤り回復技術 : トランスポート層 (TCP) Go-back-n ARQ 及び選択的 ARQ が利用されているフロー制御相手ホストの処理能力を考慮フロー制御ネットワークの利用状況を考慮輻輳制御 TCP のフロー制御ウィンドウフロー制御次回講義 : 章インターネットの始まりと発展 1 6

Microsoft PowerPoint - chapter6_2013.ppt [互換モード]

Microsoft PowerPoint - chapter6_2013.ppt [互換モード] 6. 6 データリンク層, トランスポート層における誤り制御 6 章誤り制御電子情報工学科 3 年前期ネットワークアーキテクチャ情報科学センター / ネットワークデザイン研究センター福田豊誤り制御データリンク層トランスポート層データリンク層 HDLC イーサネットトランスポート層 TCP アプリケーション層トランスポート層インターネット層データリンク層物理層 TCP/IP protocol