Berkeley COMPSCI 268 - Lecture 4 (TCP/IP Architecture)

Unformatted text preview:

CS 268: Lecture 4 (TCP/IP Architecture)The ProblemDeclared GoalThe ChallengePossible solutionsSolutionSlide 7Challenge 1: Different Address FormatsToday’s Address Format (IPv4)What About the Future ?Challenge 2: Different Packet SizesOther ChallengesServiceOriginal TCP/IP (Cerf & Kahn)Today’s TCP/IPIP HeaderTCP HeaderTCP Header (Cont)TCP Connection EstablishmentBack to the big pictureGoals (Clark’88)1. Survivability2. Types of Services3. Variety of NetworksOther GoalsOther Goals (Cont)What About the Future?Summary: Internet ArchitectureSummary: Minimalist ApproachAnnouncementCS 268: Lecture 4(TCP/IP Architecture)Ion StoicaFebruary 2, [email protected] 2The ProblemBefore Internet: different packet-switching networks (e.g., ARPANET, ARPA packet radio)-only nodes on the same network could [email protected] 3Declared Goal“…both economic and technical considerations lead us to prefer that the interface be as simple and reliable as possible and deal primarily with passing data between networks using different packet switching strategies”V. G. Cerf and R. E. Kahn, [email protected] 4The ChallengeShare resources of different packet switching networks  interconnect existing networks… but, packet switching networks differ widely-Different services •e.g., degree of reliability-Different interfaces •e.g., length of the packet that can be transmitted, address format-Different protocols•e.g., routing [email protected] 5Possible solutionsReengineer and develop one global packet switching network standard-Not economically feasibleHave every host implement the protocols of any network it wants to communicate with-Too complex, very high engineering [email protected] 6SolutionAdd an extra layer: internetworking layer-Hosts implement one higher-level protocol-Networks interconnected by nodes that run the same protocol-Provide the interface between the new protocol and every [email protected] [email protected] 8Challenge 1: Different Address FormatsMap one address format to another. Why not?Provide one common format-Map lower level addresses to common format Initially: -length: 24 bit -hierarchical -why hierarchical?Network TCP [email protected] 9Today’s Address Format (IPv4)Length: 32 bitsOrganization: hierarchicalNetworkHost0NetworkHost1NetworkHost17 241601 082114Class AClass BClass C1 1 128Class D 0 Multicast address1 1 1Class E 1 [email protected] 10What About the Future ?Internet is running out of addressesSolutions-Classless Inter Domain Routing (CIDR)-Network Address Translator (NATs)-Dynamic Address Assignments-…-IPv6Why not variable-sized [email protected] 11Challenge 2: Different Packet SizesDefine a maximum packet size over all networks. Why not?Implement fragmentation/re-assembly-Who is doing fragmentation?-Who is doing [email protected] 12Other ChallengesDelivery time (propagation time + queueing delay + link layer retransmissions?)Errors  require end-to-end reliabilityDifferent (routing) protocols  coordinate these [email protected] 13ServiceUnbounded but finite length messages-Byte streaming (what are the advantages?)Reliable and in-sequence deliveryFull duplexSolution: Transmission Control Protocol (TCP)[email protected] 14Original TCP/IP (Cerf & Kahn) No separation between transport (TCP) and network (IP) layersOne common header-Use ports to multiplex multiple TCP connections on the same hostByte-based sequence number (Why?)Flow control, but not congestion controlSource/Port Source/Port Window ACK Text3232 16 16 [email protected] 15Today’s TCP/IP Separate transport (TCP) and network (IP) layer (why?)-Split the common header in: TCP and UDP headers-Fragmentation reassembly done by IP Congestion control (see next lecture)[email protected] 16IP HeaderComments-HLen – header length only in 32-bit words (5 <= HLen <= 15)-TOS (Type of Service): now split in•Differentiated Service Field (6 bits)•remaining two bits used by ECN (Early Congestion Notification)-Length – the length of the entire datagram/segment; header + data-Flags: Don’t Fragment (DF) and More Fragments (MF)-Fragment offset – all fragments excepting last one contain multiples of 8 bytes-Header checksum - uses 1’s complement Version HLenTOS LengthIdentificationFragment offsetFlagsSource addressDestination addressTTL Protocol Header checksum04 8 16 19 31Options (variable)20 [email protected] 17TCP HeaderSequence number, acknowledgement, and advertised window – used by sliding-window based flow controlFlags:-SYN, FIN – establishing/terminating a TCP connection-ACK – set when Acknowledgement field is valid-URG – urgent data; Urgent Pointer says where non-urgent data starts-PUSH – don’t wait to fill segment-RESET – abort connectionSource portDestination portOptions (variable)Sequence numberAcknowledgementAdvertised windowChecksum Urgent pointerFlagsHdrLen0 4 10 16 [email protected] 18TCP Header (Cont)Checksum – 1’s complement and is computed over-TCP header-TCP data-Pseudo-header (from IP header)•Note: breaks the layering! Source addressDestination addressTCP Segment length0 Protocol (TCP)[email protected] 19TCP Connection EstablishmentThree-way handshake-Goal: agree on a set of parameters: the start sequence number for each side Client (initiator)ServerSYN, SeqNum = xSYN and ACK, SeqNum = y and Ack = x + 1ACK, Ack = y + 1Back to the big [email protected] 21Goals (Clark’88)0Connect existing networks-initially ARPANET and ARPA packet radio network1. Survivability-ensure communication service even in the presence of network and router failures 2. Support multiple types of services3. Must accommodate a variety of networks4. Allow distributed management5. Allow host attachment with a low level of effort6. Be cost effective7. Allow resource [email protected] 221. SurvivabilityContinue to operate even in the presence of network failures (e.g., link and router failures)-As long as the network is not partitioned, two endpoint should be able to communicate…moreover, any other failure (excepting network partition) should be transparent to endpoints Decision: maintain state only at end-points


View Full Document

Berkeley COMPSCI 268 - Lecture 4 (TCP/IP Architecture)

Documents in this Course
Lecture 8

Lecture 8

33 pages

L-17 P2P

L-17 P2P

50 pages

Multicast

Multicast

54 pages

Load more
Download Lecture 4 (TCP/IP Architecture)
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 Lecture 4 (TCP/IP Architecture) 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 Lecture 4 (TCP/IP Architecture) 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?