DOC PREVIEW
Berkeley ELENG 122 - Designing IP

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

11Designing IPEE 122: Intro to Communication NetworksFall 2006 (MW 4-5:30 in Donner 155)Vern PaxsonTAs: Dilip Antony Joseph and Sukun Kimhttp://inst.eecs.berkeley.edu/~ee122/Materials with thanks to Jennifer Rexford, Ion Stoicaand colleagues at Princeton and UC Berkeley2Announcements• Homework #2 out Wednesday rather than today– And due Oct 11 instead of Oct 4• We will likely shift the remaining homework dates• Reminder: Homework #1 due Wednesday3Goals of Today’s Lecture• Work through process of designing IP, theInternet’s (sole) network-layer protocol• Assess security implications of the design4Our Story So Far (Context)• The Internet uses packet-switching rather thancircuit-switching in order to– Achieve higher levels of utilization (we can use statisticalmultiplexing 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 partitionfunctionality into modules• The “internetworking layer” (or just network layer)forms the waist of the layering hourglass …5The Internet HourglassData LinkPhysicalApplicationsThe Hourglass ModelWaistThere is just one network-layer protocol, IP.The “narrow waist” facilitates interoperability.SMTP HTTP NTPDNSTCP UDPIPEthernet SONET 802.11TransportFiberCopper Radio6Our Story So Far (Context), Con’t• The End-to-End Principle guides us in where toplace functionality– If hosts can implement functionality correctly, implementit in a lower layer only as a performance enhancement– But do so only if it does not impose burden onapplications that do not require that functionality• The principle of Fate Sharing guides us to keepstate with the elements that rely on it, whenpossible27IP 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 ordersourcedestinationIP network8IP 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, accuratetransfer of data in order, in a timely fashion9IP 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 delay10Let’s Design IP• What does it mean to “design” a protocol?• Answer: specify the syntax of its messages andtheir meaning (semantics).– Syntax = elements in packet header, their types & layout representation– Semantics = interpretation of elements information• For IP, what fields do we need & why?11Information 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 endlesslycirculate– Fragmentation: what if the datagram is too large?IP Packet Structure4-bitVersion4-bitHeaderLength8-bitType of Service(TOS)16-bit Total Length (Bytes)16-bit Identification3-bitFlags13-bit Fragment Offset8-bit Time to Live (TTL)8-bit Protocol16-bit Header Checksum32-bit Source IP Address32-bit Destination IP AddressOptions (if any)Payload3IP Packet Structure4-bitVersion4-bitHeaderLength8-bitType of Service(TOS)16-bit Total Length (Bytes)16-bit Identification3-bitFlags13-bit Fragment Offset8-bit Time to Live (TTL)8-bit Protocol16-bit Header Checksum32-bit Source IP Address32-bit Destination IP AddressOptions (if any)Payload14IP 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 transferIP Packet Structure4-bitVersion4-bitHeaderLength8-bitType of Service(TOS)16-bit Total Length (Bytes)16-bit Identification3-bitFlags13-bit Fragment Offset8-bit Time to Live (TTL)8-bit Protocol16-bit Header Checksum32-bit Source IP Address32-bit Destination IP AddressOptions (if any)Payload16IP Packet Header Fields (Continued)• Total length (16 bits)– Number of bytes in the packet– Maximum size is 63,535 bytes (216 -1)– … though underlying links may impose smaller limits• Fragmentation: when forwarding a packet, anInternet 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 packetIP Packet Structure4-bitVersion4-bitHeaderLength8-bitType of Service(TOS)16-bit Total Length (Bytes)16-bit IdentificationRF/DF/MF13-bit Fragment Offset8-bit Time to Live (TTL)8-bit Protocol16-bit Header Checksum32-bit Source IP Address32-bit Destination IP AddressOptions (if any)Payload18Fragmentation, con’t• Identifier (16 bits): used to tell which fragmentsbelong together• Flags (3 bits):– Reserved (RF): unused bit (why “reserved”?)– Don’t Fragment (DF): instruct routers to not fragment thepacket even if it won’t fit Instead, they drop the packet and send back a “Too Large” ICMPcontrol message Forms the basis for “Path MTU Discovery”, covered later– More (MF): this


View Full Document

Berkeley ELENG 122 - Designing IP

Documents in this Course
Lecture 6

Lecture 6

22 pages

Wireless

Wireless

16 pages

Links

Links

21 pages

Ethernet

Ethernet

10 pages

routing

routing

11 pages

Links

Links

7 pages

Switches

Switches

30 pages

Multicast

Multicast

36 pages

Switches

Switches

18 pages

Security

Security

16 pages

Switches

Switches

18 pages

Lecture 1

Lecture 1

56 pages

OPNET

OPNET

5 pages

Lecture 4

Lecture 4

16 pages

Ethernet

Ethernet

65 pages

Models

Models

30 pages

TCP

TCP

16 pages

Wireless

Wireless

48 pages

Load more
Download Designing IP
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Designing IP and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Designing IP 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?