Announcements Homework 2 out Wednesday rather than today And due Oct 11 instead of Oct 4 Designing IP We will likely shift the remaining homework dates Reminder Homework 1 due Wednesday EE 122 Intro to Communication Networks Fall 2006 MW 4 5 30 in Donner 155 Vern Paxson TAs Dilip Antony Joseph and Sukun Kim http inst eecs berkeley edu ee122 Materials with thanks to Jennifer Rexford Ion Stoica and colleagues at Princeton and UC Berkeley 1 2 Goals of Today s Lecture Our Story So Far Context The Internet uses packet switching rather than circuit switching in order to Achieve higher levels of utilization we can use statistical multiplexing to more aggressively share network links Avoid state inside the network robust fail over Make interconnection between different parties easy minimal service promises Work through process of designing IP the Internet s sole network layer protocol Assess security implications of the design The Internet architecture uses layering to partition functionality into modules The internetworking layer or just network layer forms the waist of the layering hourglass 3 Our Story So Far Context Con t The Internet Hourglass SMTP HTTP DNS TCP UDP IP The End to End Principle guides us in where to place functionality Applications NTP If hosts can implement functionality correctly implement it in a lower layer only as a performance enhancement But do so only if it does not impose burden on applications that do not require that functionality Transport Waist Data Link Ethernet Copper SONET Fiber 802 11 Radio 4 Physical The Hourglass Model There is just one network layer protocol IP The narrow waist facilitates interoperability 5 The principle of Fate Sharing guides us to keep state with the elements that rely on it when possible 6 1 IP Service Best Effort Packet Delivery IP Service Model Why Best Effort Packet switching IP means never having to say you re sorry Divide messages into a sequence of packets Each packet datagram is dealt with individually Don t need to reserve bandwidth and memory Don t need to do error detection correction Don t need to remember from one packet to next Best effort delivery Easier to survive failures Packets may be lost Packets may be corrupted Packets may be delivered out of order source Transient disruptions are okay during failover but applications do want efficient accurate transfer of data in order in a timely fashion destination IP network 7 IP Service Best Effort Suffices 8 Let s Design IP No error detection or correction Higher level protocol can provide error checking What does it mean to design a protocol Successive packets may not follow the same path Answer specify the syntax of its messages and their meaning semantics Not a problem as long as packets reach the destination Packets can be delivered out of order Syntax elements in packet header their types layout Receiver can put packets back in order if necessary representation Semantics interpretation of elements Packets may be lost or arbitrarily delayed information Sender can send the packets again if desired No network congestion control beyond drop For IP what fields do we need why Sender can slow down in response to loss or delay 9 Information to Capture in IP Header 10 IP Packet Structure Addresses datagram destination source 4 bit 8 bit 4 bit Version Header Type of Service Length TOS Framing datagram length demux information 16 bit Identification Priority any special forwarding 8 bit Time to Live TTL Extensibility what if we need to tweak change IP 16 bit Total Length Bytes 3 bit Flags 8 bit Protocol 13 bit Fragment Offset 16 bit Header Checksum 32 bit Source IP Address 32 bit Destination IP Address Dealing with problems Integrity is the header what it s supposed to be Loop avoidance make sure packets don t endlessly circulate Fragmentation what if the datagram is too large Options if any Payload 11 2 IP Packet Header Fields IP Packet Structure 4 bit 8 bit 4 bit Version Header Type of Service Length TOS 3 bit Flags 16 bit Identification 8 bit Time to Live TTL Version number 4 bits 16 bit Total Length Bytes 8 bit Protocol 13 bit Fragment Offset 16 bit Header Checksum 32 bit Source IP Address 32 bit Destination IP Address Options if any Indicates the version of the IP protocol Necessary to know what other fields to expect Typically 4 for IPv4 and sometimes 6 for IPv6 Header length 4 bits Number of 32 bit words in the header Typically 5 for a 20 byte IPv4 header Can be more when IP options are used Type of Service 8 bits Allow packets to be treated differently based on needs E g low delay for audio high bandwidth for bulk transfer Payload 14 IP Packet Header Fields Continued IP Packet Structure Total length 16 bits 4 bit 8 bit 4 bit Version Header Type of Service Length TOS 3 bit Flags 16 bit Identification 8 bit Time to Live TTL 16 bit Total Length Bytes 8 bit Protocol 13 bit Fragment Offset 16 bit Header Checksum 32 bit Source IP Address 32 bit Destination IP Address Options if any Payload Fragmentation when forwarding a packet an Internet router can split it into multiple pieces fragments if too big for next hop link End host reassembles to recover original packet Fragmentation information 32 bits Packet identifier flags and fragment offset Supports dividing a large IP packet into fragments in case a link cannot handle a large IP packet 16 Fragmentation con t IP Packet Structure 4 bit 8 bit 4 bit Version Header Type of Service Length TOS 16 bit Total Length Bytes RF DF MF 16 bit Identification 8 bit Time to Live TTL Number of bytes in the packet Maximum size is 63 535 bytes 216 1 though underlying links may impose smaller limits 8 bit Protocol 13 bit Fragment Offset 16 bit Header Checksum 32 bit Source IP Address 32 bit Destination IP Address Options if any Payload Identifier 16 bits used to tell which fragments belong together Flags 3 bits Reserved RF unused bit why reserved Don t Fragment DF instruct routers to not fragment the packet even if it won t fit Instead they drop the packet and send back a Too Large ICMP control message Forms the basis for Path MTU Discovery covered later More MF this fragment is not the last one Offset 13 bits what part of datagram this fragment covers in 8 byte units Thus a fragment has either MF set or Offset 0 18 3 Example of Fragmentation Example of Fragmentation con t Suppose we have a 4 000 byte datagram sent from host 1 2 3 4 to host 3 4 5 6 Version Header Type of Service Length 4 0 5 Identification 56273 TTL 127 Datagram split into
View Full Document
Unlocking...