Designing IP EE 122 Intro to Communication Networks Fall 2007 WF 4 5 30 in Cory 277 Vern Paxson TAs Lisa Fowler Daniel Killebrew Jorge Ortiz http inst eecs berkeley edu ee122 Materials with thanks to Jennifer Rexford Ion Stoica and colleagues at Princeton and UC Berkeley 1 Announcements Lisa away next Friday Section will be taught by Daniel Her office hours will be by appointment Daniel is taking over the Wednesday section Jorge is shifting to the new Monday section 2 1 Goals of Today s Lecture Work through process of designing IP the Internet s sole network layer protocol Assess security implications of the design 3 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 The Internet architecture uses layering to partition functionality into modules The internetworking layer or just network layer forms the waist of the layering hourglass 4 2 The Internet Hourglass SMTP HTTP DNS TCP Applications NTP UDP IP Transport Waist Data Link Ethernet Copper SONET Fiber 802 11 Radio Physical The Hourglass Model There is just one network layer protocol IP The narrow waist facilitates interoperability 5 Our Story So Far Context Con t The End to End Principle guides us in where to place functionality 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 The principle of Fate Sharing guides us to keep state with the elements that rely on it when possible 6 3 IP Service Best Effort Packet Delivery Packet switching Divide messages into a sequence of packets Each packet datagram is dealt with individually Best effort delivery Packets may be lost Packets may be corrupted Packets may be delivered out of order source destination IP network 7 IP Service Model Why Best Effort IP means never having to say you re sorry 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 Easier to survive failures Transient disruptions are okay during failover but applications do want efficient accurate transfer of data in order in a timely fashion 8 4 IP Service Best Effort Suffices No error detection or correction Higher level protocol can provide error checking Successive packets may not follow the same path Not a problem as long as packets reach the destination Packets can be delivered out of order Receiver can put packets back in order if necessary Packets may be lost or arbitrarily delayed Sender can send the packets again if desired No network congestion control beyond drop Sender can slow down in response to loss or delay 9 Let s Design IP What does it mean to design a protocol Answer specify the syntax of its messages and their meaning semantics Syntax elements in packet header their types layout o representation Semantics interpretation of elements o information For IP what fields do we need why 10 5 Information to Capture in IP Header Addresses datagram destination source Framing datagram length demux information Priority any special forwarding Extensibility what if we need to tweak change IP 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 11 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 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 6 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 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 IP Packet Header Fields Version number 4 bits 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 14 7 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 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 IP Packet Header Fields Continued Total length 16 bits Number of bytes in the packet Maximum size is 65 535 bytes 216 1 though underlying links may impose smaller limits 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 8 5 Minute Break Questions Before We Proceed 17 IP Packet Structure 4 bit 8 bit 4 bit Version Header Type of Service Length TOS RF DF MF 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 9 Fragmentation con t 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 o Instead they drop the packet and send back a Too Large ICMP control message o 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 19 Example of Fragmentation 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
View Full Document
Unlocking...