Automatic Repeat Request Protocols
さて、これでようやく「フレーム」なるものに区切られて送信されたデータのエラー検知が可能となった。次に行なうことは、エラーを検知した際にどうするか、という問題である。とはいっても概念的にはやることは明快で、エラーが起こったデータを再送信するように要求するわけだ。だからAutomatic Repeat Request Protocolsと総称されており、異なるサービスに対して異なる方式が使われる。
・Connection oriented Serviceでは、最初に接続が確立されて、その後データが送信される。そしてそのデータ送信はError-Freeであることが要求される。したがって大変込み入った再送要求プロトコルが必要となる。
・Acknowledged Connectionless Serviceでは、送信側がＣＲＣを付与して送信、受信側はＣＲＣをチェックし（前述の通り）エラーがあればその旨Acknowledgeを返す。
・Unacknowledged connetionless service ：送信側はＣＲＣを付与して送信。受信側はＣＲＣをチェックし、エラーがあれば捨てる。（この場合は上位層でエラーのリカバリを行なうことになろうか）
さて、ここでは2番目のAcknowledged Connectionless serviceに対して、どのような再送信要求プロトコルが使われているかを見ていく。
（３ ）再送信要求プロトコル
方法その１）Positive and Negative Acknowledgement
アルゴリズムは以下の通り。考えうるもっとも素直な方法だ。
・AはＢにパケットを送り、Acknowledgementを待つ。
・ＢはAからパケットを受け取り、エラーをチェックする。エラーがなければパケットを受け入れ、PositiveなAcknowledgementを返す。もしエラーがあればパケットを捨ててNegative Acknowledgementを返す。
・ＡはPositive Acknowledgementを受け取れば次のパケットを送信する。Negative Acknowledgementを受信すれば同じパケットを送り直す。
さて、かくのごとくこの方法はシンプルで分かりやすい。しかし大きな問題が存在している。Ａから送られたパケットが（仮にそれにエラーがあるとしても）Ｂで受け取らればよいのだが、パケットが完全になくなってしまった場合はどうなるだろう。ＡはなくなったパケットのAcknowledgementをずっと待ちつづける。それがPositiveであろうがNegativeであろうが、とにかくAcknowledgementを受け取らないことには先に進めないのだ。そしてＢのほうは
「なぜＡはパケットを送ってこないのだろう」
と思いながらもこれまた延々と待つしかない。
方法その２）Positive Acknowledgement with Timeout
・ＡはＢにパケットを送り、Acknowledgementを待つ。
・Ｂはパケットを受け取り、エラーをチェックする。エラーがなければパケットを受け入れ、Positive Acknowledgementを返す。エラーがあればパケットを捨てる。（何も返さない）
・ＡがPositive Acknowledgementを受け取った場合は、次のパケットを送る。Acknowledgementを受け取らない場合にはＴの間待ってタイムアウトとし、最後に送ったのと同じパケットを送信する。
さて、今回はタイムアウトを設定しているから双方が「相手はなぜ何もいってこないのだろう」とデッドロックに陥ることはない。しかしながら厳然と問題は存在している。
・Acknowledgementがどこかに失われた場合、データを受け取る側は重複したデータをうけとることになる。そして受け取る側は仮に同じデータを２度受け取ったとしても、それが必要以上に重複しているのか、元々同じデータが２度送られるようになっていたのかは区別ができない。
・タイムアウトの時間が短すぎても同じ問題（重複したデータの受け取り）が発生する。したがってタイムアウト時間Ｔは少なくとも往復の伝送時間より長くなくてはいけない。
ということは次のパケットを送るまでに最悪それだけの間またなくてはならない可能性があるということだ。
方法その３）Positive Acknowledgement with Timeout and Sequence Number
・方法その２）と基本的には同じだが、全てのパケットおよびAcknowledgementにはシーケンス番号（通し番号のほうがわかりやすいだろうか）を付与する。
・データを受信する側は、同じシーケンス番号のパケットを受け取った場合破棄する。そしてNegtative Acknowledgementを返す。そうしないといつまでたっても同じパケットが送られてくることになる
この方法の問題は、シーケンス番号をいったいどこまでふるのか、ということである。無限に大きな番号が振れるわけでもなし、どこかで「また０からやりなおし」とすると、「おっと。この番号はうけとったぞ」といって破棄されても困る。
Stop-N-Wait(1 bit sliding window ) Protocol
・基本的には方法その３と同一だが、シーケンス番号は１ビットである。つまり０か１かだけだ。これだけで事が足りるのは送信待ちになっているパケットは多くても一つしかないからである。０を正常に受信した次に０がくれば、重複だから破棄。（０に対するAcknowledgeはきっとどこかに消えてしまったのだろう）１がくればめでたく受け入れて、今度は０がくるのを待つ、という寸法である。
さて、この方法ではちゃんとシーケンス番号が振られているから（必要以上に）重複したデータを受け入れる可能性はない。しかし送信側はPositive Acknowledgementを受け取ってから次のパケットを送信するから、エラーがほとんどないとしてもデータの送信レートは低くなってしまう。
Go-Back-N(Sliding Window) Protocol
・送信パケットはシーケンス番号がふられている。また送信側ステーションはＮのWindow（窓）を持つ。
・このWindow内にある一連のパケットは（もちろん順番に）送信される。この場合まだ受け取っていないAcknowledgeがあってもかまわず送信してしまう。
・送信側のステーションがＰ番目のパケットに対するAcknowledgementを受け取った場合、Ｐ番目及びそれより前に送信したパケットはすべて正常に受信されたものとみなす。そしてＰ＋１番目のパケットにWindowをずらす。
・タイムアウトが起こった場合、送信側のステーションは現在のWindow内の全てのパケットを再送信する。
・受信側の処理は基本的にStop-N-Waitと同じである。正常なパケットを受け取ればAcknowledgeを返す。また同じシーケンス番号を受け取れば破棄する。
ただし全ての正常に受信できたパケットに対してAcknowledgeを送信する必要はない。受け取った最後のパケットに対して送信すれば十分である。しかしAcknowledgeを返していないパケットがタイムアウトにならないように注意する必要がある。
この方式を用いると、Stop-N-Waitに対して連続してパケットが送信できるので、回線の使用効率はよくなる。しかしながら問題は厳然として存在している。
・Windowのサイズはいくつにすべきか？もし１であればそれはStop-N-Waitと同じになってしまい、回線効率は悪くなる。エラーが少ない状況ではWindowのサイズＮは、伝送遅れ（往復分）よりもＮ個パケットを送信する時間が同じか長いように選ぶべきだ。
・シーケンス番号はWindowの大きさよりも１以上大きい必要がある。これはなぜか？
次のような場合を考えてみよう。シーケンス番号を０−３にとる。そしてWindowの大きさも３とする。受信側はデータを受信しているが、全てのAcknowledgeが途中で失われたと。
すると受信側は
「おれは０から３までのデータをちゃんと受け取ったし、Acknowledgeも返した。となれば次ぎは新しい０がくるのをまつだけだ」
と考える。ところがデータは送ったもののぜんぜんAcknowledgeが返ってこないと思っている送信側ではこう考える。
「おれは０から３までデータを送ってやったが、Acknowledgeは一つも返ってこない。。。とうとう最初のデータ：０がタイムアウトになってしまった。しょうがない。最初と同じデータをもう一度送るか」
というわけでデータを送信する。このデータのシーケンス番号は０だが、内容は最初のものと同一だ。ところが受信側は、本来は新しい０番を待っているにもかからわず
「おお。０番がきた」
というだけで前と重複したデータを受け言えれてしまうわけである。
・送信側にバッファを持つ必要がある。（Windowの中のＮ個は必要であれば再送しなければならない。つまり送るそばから忘れるわけにはいかない）
・エラーレートが高い状況での通信には適していない。Acknowledgementが返ってこない場合、Windowの中にあるデータ全部を再送することが必要となる。場合によってはWindowの中のいくつかだけのデータが受信できなかったとしてもだ。Stop-N-Waitであれば、一つづつデータを送るから、そうした無駄な送信は起こらない。
Selective Repeat Protocol
・基本的にはGo-Back-Nと同様のWindow方式を用いる。
・送信側はAcknowledgementが時間切れとなったものだけを再送信する。
・受信側は必ずしもエラーなしに受信できたパケット（これは必ずしも連続した順番には並んでいない）を記録しておく。データを受け取って一連の連続した番号のパケットがそろったところで一番大きなシーケンス番号のAcknowledgeを返す。
この方式では先ほどのSlinding WindowのようにWindowないのデータをすべて送信するわけではないから、無駄に送信は行われない。しかし以下に示す問題は存在している。
・シーケンス番号の範囲は、最低でもWindowサイズの２倍は必要
・受信側にバッファが必要（送られてくるデータを記録しておく必要があるからだ）
ここまでの説明では「受信側」「送信側」と書いてきたが、実のところ双方がデータを送りあっている場合もありえるわけだ。この場合AcknowldgementをDataとPiggybackすることもできる。
さて、ここでいきなりでてきたPiggybackなる言葉だが、これはあちこちで目にするのだが、学校で習ったことはない。どうやらその意味するところは「相乗り」とかなんとかのようである。PiggyのPigはやはり豚なのだろうが、これがどうして「相乗り」の意味につながるのか今一つわからない。
由来はわからなくてもこの言葉が意味するところは以下のようである。つまり自分が受信したデータのAcknowledgeを返すのに、自分が送信しようとしているデータにくっつけて送信してもいいわけである。もっともタイミングによっては自分がAcknowledgementを返したいタイミングで送信するデータがないかもしれない。こうした場合にはAcknowledgement単独で送信する必要がある。
さて、本講義ではこの後に実際にどのようなスループットが見込めるのか、という計算を用いた説明が行なわれた。しかし今数式を見てみても私にはさっぱり記憶がよみがえらない、というわけであっさり省略してしまう。
具体例
さて、以上がだいたいDLC Ｌａｙｅｒまでの説明である。それではここで具体的な例について書いてみよう。IEEE LLC(IEEE 802.2)をとりあげ、ここまで話してきた内容（つまり各階層だが）が、どのような関係になっているかもまとめて記述してみることにする。
最初の２章でかなりくどいくらいに「ネットワークのプロトコルは階層構造になっている」と書いた。ここまで来てようやく所謂Ethernetにおいてフレームの構造がどのようになっているか。またプロトコルが階層構造とはどんなことかを書く事ができる。下の図をずっと見てほしい。
物理層：
PA : プリアンブル：10101010 10101010 10101010 10101010 10101010 10101010 10101010と送出．駆動回路の安定のための時間確保と受信側の同期化に使用される。
SFD : 開始デリミッタ：10101011と送出．これ以下がデータフレームであることの宣言
Data Frame： 内容はこのレベルでは何も問わない。実際にはMac Subylayerのフレームがはいる。
フレーム間ギャップ：次につづくフレームとの干渉を避けるための休止時間
MAC；
ここについては、前述してあるので詳細は省略
LLC層で；
DSAP（Destination Service Access Point）：１Byte,最初のビットがIndivudual/Groupの区別をあらわす。
SSAP（Source Service Access Point）：1 Byte, 最初のビットがCommmand/Responseの区別をあらわす。
Ctl：1Byteまたは2Byte,７ビットのシーケンス番号を振ることができる。
Information：ネットワーク層以上の上位層のデータが入る。
Padding：LLC層のデータユニットが46オクテットに達しないときには，46オクテットになるように0を埋め込む。
さて、細かい説明についてはよくわかっていないので、つっこまないでほしい。ここで書きたいことは、かくの通り各階層のプロトコルはフレームをもっており、それらが入れ子になっているということだ。
プロトコルが階層構造になっていると説明したときに「秘書が手紙を封筒に入れる」という比喩を用いたが、ここで上位層のフレーム：内容は下位のフレームの中に「手紙が封筒に入れられる」ように見ることができる。
さて、これで長々と続いたDLC layerの説明を終わる。次にはそれこそあまりネットワークなどという言葉に縁の無い生活を送っている人でも目にするTCP/IPの後ろ半分、IPが属するところのNetwork Layerについて記述する。