IPパケット内のソースIPと宛先IPの位置


7

イーサネットフレームヘッダーでは、明らかな理由により、宛先MAC(DMAC)が送信元MACの前に配置されます(ステーションはDMACに基づいて受け入れます)。しかし、IPヘッダーの宛先IP(DIP)とソースIP(SIP)で同じものが維持されないのはなぜですか?

DMACがSMACより先にあるイーサネットフレームとは異なり、SIPがIPフレームヘッダー内のDIPより先にあるのはなぜですか?


4
イーサネットの人たちは早い段階で「カットスルー」を想定していたと思います。IPでは、「ヘッダーチェックサム」はIPアドレスの前にあるため、「カットスルー」は実際には不可能ですが、IPアドレスが含まれているため、ヘッダーの値を決定する前にIPヘッダー全体を読み取る必要があります。このコンテキストでのヘッダーの順序は関係ありません。しかし、それでも疑問が残ります。なぜIPヘッダーは「カットスルー」に対応するように設計されていないのですか。そして答えはおそらく、それはその時点ではそれほど興味深い/重要ではなかったし、それが今日であるかどうかは議論の余地がある。
ytti 2013

2
@ytti:IPが「カットスルー」をサポートするとしたら、どのような改善がありますか?IPはめったに層2なしで使用されていません
BatchyX

2
イーサネットの場合、宛先を最初に設定したのは、当時ハブが大流行していたためであり、ホストがフレームが自分向けのものであるかどうかをホストが判断するのがより効率的になったためです。以前のバージョンのIPおよびTCPでは、最初に宛先アドレスがありました。それがv4で切り替えられた理由は本当の説明はありません。効率や速度がこれまでIPに重点を置いてきたとは思えません。
サンティーノ

@BatchyXはIPがL2で使用されている場合、L3ルーティングの決定を行う必要がある場合、フレーム設計のためにそれを「カットスルー」することはできません。私もそれについてあまり強く感じていません。たぶん、一部の人々はIPカットスルーの素晴らしいユースケースを持っています。
ytti 2013

何か回答がありましたか?もしそうなら、質問が永遠にポップアップし続けないように答えを受け入れ、答えを探します。または、独自の回答を提供して受け入れることもできます。
Ron Maupin

回答:


3

アイデアは、フレームがマルチキャストであるかどうかをできるだけ早く知ることでした。ネットワークバイトオーダーは設計で少しねじ込まれているため、最初のニブルではなく2番目にあります。


3
TokenRingはMACを左から右に送信するため、マルチキャストビットは8番目のビットではなく1番目のビットと見なされます。
ytti 2013
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.