Part 1 Networking Review Goals r review key

Part 1: Networking Review Goals: r review key topics from intro networks course m m m Overview: r overview r error control r flow control equalize backgrounds r congestion control identify remedial work r routing ease into course r LANs r addressing r synthesis: m m “a day in the life” control timescales 1

What’s a network: “nuts and bolts” view r network edge: millions of end- system devices: m pc’s workstations, servers m PDA’s, phones, toasters running network apps r network core: routers, switches forwarding data m m router server workstation mobile local net regional net packets: packet switching calls: circuit switching r communication links m fiber, copper, radio, … company net 2

What’s a network protocol? r Means (algorithm) for exchanging information g in du r in d lle m “how” you send/receive stuff (actions) Format of data exchanged fi m cl a about “means” of exchanging information r shared (agreed upon, standardized) set of rules for communication ss ! r “understanding” between two (or more) entitites 3

What’s a protocol? a human protocol and a computer network protocol: Hi TCP connection req. Hi TCP connection reply. Got the time? Get http: //gaia. cs. umass. edu/index. htm 2: 00 time 4

What’s a protocol? human protocols: r “what’s the time? ” r “I have a question” r introductions … specific msgs sent … specific actions taken when msgs received, or other events network protocols: r machines rather than humans r all communication activity in Internet governed by protocols define format, order of msgs sent and received among network entities, and actions taken on msg transmission, receipt 5

A closer look at network structure: r network edge: applications and hosts r network core: m routers m network of networks r access networks, physical media: communication links 6

The network edge: r end systems (hosts): m run application programs m e. g. , WWW, email m at “edge of network” r client/server model m client host requests, receives service from server m e. g. , WWW client (browser)/ server; email client/server r peer-peer model: m host interaction symmetric m e. g. : Gnutella, Ka. Za. A 7

Network edge: connection-oriented service Goal: data transfer between end sys. r handshaking: setup (prepare for) data transfer ahead of time m m Hello, hello back human protocol set up “state” in two communicating hosts r TCP - Transmission Control Protocol m Internet’s connectionoriented service TCP service [RFC 793] r reliable, in-order byte- stream data transfer m loss: acknowledgements and retransmissions r flow control: m sender won’t overwhelm receiver r congestion control: m senders “slow down sending rate” when network congested 8

Network edge: connectionless service Goal: data transfer between end systems m same as before! r UDP - User Datagram Protocol [RFC 768]: Internet’s connectionless service m unreliable data transfer m no flow control m no congestion control App’s using TCP: r HTTP (WWW), FTP (file transfer), Telnet (remote login), SMTP (email) App’s using UDP: r streaming media, teleconferencing, Internet telephony 9

The Network Core r mesh of interconnected routers r the fundamental question: how is data transferred through net? m circuit switching: dedicated circuit per call: telephone net m packet-switching: data sent thru net in discrete “chunks” 10

Network Core: Circuit Switching End-end resources reserved for “call” r link bandwidth, switch capacity r dedicated resources: no sharing r circuit-like (guaranteed) performance r call setup required 11

Network Core: Packet Switching each end-end data stream divided into packets r user A, B packets share network resources r each packet uses full link bandwidth r resources used as needed, Bandwidth division into “pieces” Dedicated allocation Resource reservation resource contention: r aggregate resource demand can exceed amount available r congestion: packets queue, wait for link use r store and forward: packets move one hop at a time m transmit over link m wait turn at next link 12

Network core: routing Goal: move data among routers from source to dest. datagram packet network: circuit-switched network: m destination address determines m call allocated time slots next hop of bandwidth at each m routes may change during session link m analogy: driving, asking directions m fixed path (for call) m No notion of call state virtual circuit network: m packet carries tag, tag determines next hop m fixed path (for call) determined at call setup time m routers maintain little per-call state; resources not allocated m determined at call setup switches maintain lots of per call state (what? ): resource allocation 13

Packet switching vs circuit switching: why? r “reliability” – no congestion, in order data in circuit-switching r packet switching: better bandwidth use r state, resources: packet switching has less state ss ! cl a g fi lle d in r failure modes (routers/links down): m packet switching routing reconfigures sub-second timescale; m circuit-switching: more complex recovery – need to involve all (downstream) switches on path in m good: less control-plane processing resources along the way More dataplane (address lookup) processing du r m 14

Access networks and physical media Q: How to connection end systems to edge router? r residential access nets r institutional access networks (school, company) r mobile access networks Keep in mind: r bandwidth (bits per second) of access network? r shared or dedicated? 15

Example access net: home network Typical home network components: r ADSL or cable modem r router/firewall r Ethernet r wireless access point to/from cable headend cable modem router/ firewall Ethernet (switched) wireless laptops wireless access point 16

So we have seen “pieces” of network r edge, core, links r protocols How do we talk about “structure” of network and its architecture? r layered architecture m m m structure allows identification, relationship of complex system’s pieces: layered reference model for discussion layer N builds on services provided by layer N-1 Layer N provides service to layer N+1 r physical topology, interconnection 17

Internet protocol stack r application: supporting network applications m ftp, smtp, http application r transport: host-host data transfer m tcp, udp transport r network: routing of datagrams from network source to destination m ip, routing protocols r link: data transfer between neighboring network elements m link physical ppp, ethernet r physical: bits “on the wire” 18

Layering: logical communication E. g. : transport r take data from app r addressing, reliability check info to form “datagram” r send datagram to peer r wait for peer to ack receipt r analogy: post office data application transport network link physical ack data network link physical application transport network link physical data application transport network link physical 19

Layering: physical communication data application transport network link physical application transport network link physical data application transport network link physical 20

Internet structure: network of networks r roughly hierarchical r at center: “tier-1” ISPs (e. g. , UUNet, BBN/Genuity, Sprint, AT&T), national/international coverage m treat each other as equals Tier-1 providers interconnect (peer) privately Tier 1 ISP NAP Tier-1 providers also interconnect at public network access points (NAPs) Tier 1 ISP 21

Internet structure: network of networks r “Tier-2” ISPs: smaller (often regional) ISPs m Connect to one or more tier-1 ISPs, possibly other tier-2 ISPs Tier-2 ISP pays tier-1 ISP for connectivity to rest of Internet q tier-2 ISP is customer of tier-1 provider Tier-2 ISP Tier 1 ISP Tier-2 ISP NAP Tier 1 ISP Tier-2 ISPs also peer privately with each other, interconnect at NAP Tier-2 ISP 22

Internet structure: network of networks r “Tier-3” ISPs and local ISPs m last hop (“access”) network (closest to end systems) local ISP Local and tier 3 ISPs are customers of higher tier ISPs connecting them to rest of Internet Tier 3 ISP Tier-2 ISP local ISP Tier-2 ISP Tier 1 ISP Tier-2 ISP local ISP NAP Tier 1 ISP Tier-2 ISP local ISP 23

Internet structure: network of networks r a packet passes through many networks! local ISP Tier 3 ISP Tier-2 ISP local ISP Tier-2 ISP Tier 1 ISP Try a traceroute! Tier 1 ISP Tier-2 ISP local ISP NAP Tier 1 ISP Tier-2 ISP local ISP 24

Part 0: Networking Review Goals: r review key topics from intro networks course m m m Overview: r overview r error control r flow control equalize backgrounds r congestion control identify remedial work r routing ease into course r LANs r addressing r synthesis: m m “a day in the life” control timescales 25

Error control r reliable point-point communication m A generic problem: application-to-application, over path, over link r what’s the error model: m bits flipped in packet? m packets “lost? m packets delayed or reordered? 26

Bit level error detection EDC= Error Detection and Correction bits (redundancy) D = Data protected by error checking, may include header fields • Error detection not 100% reliable! • protocol may miss some errors, but rarely • larger EDC field yields better detection and correction 27

Parity Checking Single Bit Parity: Detect single bit errors Two Dimensional Bit Parity: Detect and correct single bit errors Much more powerful error detection/correction schemes: Cyclic Redundancy Check (CRC) 0 Simple form of forward error correction (FEC) 0 28

Internet checksum Goal: detect “errors” (e. g. , flipped bits) in transmitted segment (note: used at transport layer only) Sender: r treat segment contents as sequence of 16 -bit integers r checksum: addition (1’s complement sum) of segment contents r sender puts checksum value into UDP checksum field Receiver: r compute checksum of received segment r check if computed checksum equals checksum field value: m NO - error detected m YES - no error detected. But maybe errors nonetheless? 29

Recovering from lost packets r Why are packets lost: at end system, “within” network m m m Limited storage, discarded in congestion outages: eventually reroute around failure (~sec world’s recovery ties hopefully) worst acronym dropped at end system e. g. , on NIC r ARQ: automatic request repeat m sender puts sequence numbers on packets (why) m receiver positively or negatively acknowledges correct receipt of packet m sender starts (logical) timer for each packet, timeout and retransmits 30

Reference: section 3. 4 in K&R rdt 3. 0: channels with errors and loss Assumption: underlying channel can also lose packets (data or ACKs) m checksum, seq. #, ACKs, retransmissions will be of help, but not enough r Why seq #s m m detect reordering ACK, NAKing Detect missing packet Duplicate detection due to retransmissions Approach: sender waits “reasonable” amount of time for ACK r retransmits if no ACK received in this time r if pkt (or ACK) just delayed (not lost): m retransmission will be duplicate, but use of 0, 1 seq. #’s already handles this m receiver must specify seq # of pkt being ACKed r requires countdown timer 31

rdt 3. 0 sender rdt_send(data) sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) L rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt, 1) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || is. ACK(rcvpkt, 0) ) timeout udt_send(sndpkt) start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && is. ACK(rcvpkt, 0) stop_timer timeout udt_send(sndpkt) start_timer L Wait for ACK 0 Wait for call 0 from above L rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || is. ACK(rcvpkt, 1) ) Wait for ACK 1 Wait for call 1 from above rdt_send(data) rdt_rcv(rcvpkt) L sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer FSM specification of sender (details not important) 32

rdt 3. 0 in action 33

rdt 3. 0 in action 34

Part 0: Networking Review Goals: r review key topics from intro networks course m m m Overview: r overview r error control r flow control equalize backgrounds r congestion control identify remedial work r routing ease into course r LANs r addressing r synthesis: m m “a day in the life” control timescales 35

Flow Control (in TCP) flow control sender won’t overrun receiver’s buffers by transmitting too much, too fast receiver: explicitly informs sender of (dynamically changing) amount of free buffer space m Rcv. Window field in TCP segment sender: keeps the amount of transmitted, un. ACKed data less than most recently received Rcv. Window Rcv. Buffer = size or TCP Receive Buffer receiver buffering Rcv. Window = amount of spare room in Buffer 36

Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r different from flow control! r manifestations: m lost packets (buffer overflow at routers) m long delays (queueing in router buffers) r a top-10 problem! 37

Causes/costs of congestion: scenario 1 Host A r two senders, two receivers r one router, infinite buffers r no retransmission Host B lout lin : original data unlimited shared output link buffers r large delays when congested r maximum achievable throughput 38

Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet Host A lin : original data lout l'in : original data, plus retransmitted data Host B finite shared output link buffers 39

Causes/costs of congestion: scenario 2 = l (goodput) out in r “perfect” retransmission only when loss: r always: r l l = lout in retransmission of delayed (not lost) packet makes l in lout (than perfect case) for same larger “costs” of congestion: r more work (retrans) for given “goodput” r unneeded retransmissions: link carries multiple copies of pkt 40

Causes/costs of congestion: scenario 3 r four senders Q: what happens as l in and l increase ? r multihop paths in r timeout/retransmit Host A lin : original data lout l'in : original data, plus retransmitted data finite shared output link buffers Host B 41

Causes/costs of congestion: scenario 3 H o st A l o u t H o st B Another “cost” of congestion: r when packet dropped, any “upstream transmission capacity used for that packet wasted! 42

Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: r no explicit feedback from network r congestion inferred from end-system observed loss, delay r approach taken by TCP Network-assisted congestion control: r routers provide feedback to end systems m single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) m explicit rate sender should send at 43

Case study: ATM ABR congestion control ABR: available bit rate: r “elastic service” RM (resource management) cells: r if sender’s path r sent by sender, interspersed “underloaded”: m sender should use available bandwidth r if sender’s path congested: m sender throttled to minimum guaranteed rate with data cells r bits in RM cell set by switches (“network-assisted”) m NI bit: no increase in rate (mild congestion) m CI bit: congestion indication r RM cells returned to sender by receiver, with bits intact 44

Case study: ATM ABR congestion control r two-byte ER (explicit rate) field in RM cell m congested switch may lower ER value in cell m sender’ send rate thus minimum supportable rate on path r EFCI bit in data cells: set to 1 in congested switch m if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell 45

TCP Congestion Control r end-end control (no network assistance) r transmission rate limited by congestion window size, Congwin, over segments: Congwin 46

TCP congestion control: r “probing” for usable bandwidth: m m m ideally: transmit as fast as possible (Congwin as large as possible) without loss increase Congwin until loss (congestion) loss: decrease Congwin, then begin probing (increasing) again r two “phases” m slow start m congestion avoidance r important variables: m Congwin m threshold: defines threshold between two slow start phase, congestion control phase 47

TCP Slowstart Host A initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR Cong. Win > threshold) RTT Slowstart algorithm Host B one segme nt two segme nts four segme nts r exponential increase (per RTT) in window size (not so slow!) r loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP) time 48

TCP Congestion Avoidance: Tahoe TCP Tahoe Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart Numerous improvements: TCP Reno, SACK 49

Part 0: Networking Review Goals: r review key topics from intro networks course m m m Overview: r overview r error control r flow control equalize backgrounds r congestion control identify remedial work r routing (and network layer ease into course services) r LANs r addressing r synthesis: m m “a day in the life” control timescales 50

Network layer functions r transport packet from application transport network data link physical sending to receiving hosts r network layer protocols in every host, router three important functions: r path determination: route taken by packets from source we won’t to dest. Routing algorithms consider this r switching: move packets from router’s input to appropriate router output r call setup: some network architectures require router call setup along path before data flows network data link physical network data link physical application transport network data link physical our focus in 653 later 51

Network service model service abstraction Q: What service model for “channel” transporting packets from sender to receiver? r guaranteed bandwidth? r preservation of inter-packet timing (no jitter)? r loss-free delivery? r in-order delivery? r congestion feedback to sender? CRUCIAL question! The most important abstraction provided by network layer: ? ? ? virtual circuit or datagram? 52

Virtual circuits “source-to-dest path behaves much like telephone circuit” m m performance-wise network actions along source-to-dest path r call setup, teardown for each call before data can flow r each packet carries VC identifier (not destination host ID) r every router on source-dest path maintains “state” for each passing connection m transport-layer connection only involved two end systems r link, router resources (bandwidth, buffers) may be allocated to VC m to get circuit-like perf. 53

Virtual circuits: signaling protocols r used to setup, maintain teardown VC r used in ATM, frame-relay, X. 25 r not used in today’s Internet application transport 5. Data flow begins network 4. Call connected data link 1. Initiate call physical 6. Receive data application 3. Accept call transport 2. incoming call network data link physical 54

Datagram networks: the Internet model r no call setup at network layer r routers: no state about end-to-end connections m no network-level concept of “connection” r packets typically routed using destination host ID m packets between same source-dest pair may take different paths application transport network data link 1. Send data physical application transport 2. Receive data network data link physical 55

Datagram or VC network: why? Internet r data exchange among ATM r evolved from telephony computers r human conversation: m “elastic” service, no strict m strict timing, reliability timing requirements r “smart” end systems m need for guaranteed (computers) service m can adapt, perform r “dumb” end systems control, error recovery m telephones m simple inside network, m complexity inside complexity at “edge” network r many link types m different characteristics m uniform service difficult 56

Routing protocol 5 Goal: determine “good” path (sequence of routers) thru network from source to dest. Graph abstraction for routing algorithms: r graph nodes are routers r graph edges are physical links m link cost: delay, $ cost, or congestion level 2 A B 2 1 D 3 C 3 1 5 F 1 E 2 r “good” path: m typically means minimum cost path m other def’s possible 57

Routing: only two approaches used in practice Global: r all routers have complete topology, link cost info r “link state” algorithms: use Dijkstra’s algorithm to find shortest path from given router to all destinations Decentralized: r router knows physically-connected neighbors, link costs to neighbors r iterative process of computation, exchange of info with neighbors r “distance vector” algorithms r a ‘self-stabilizing algorithm’ (we’ll see these later) 58

Distance Vector Routing Algorithm iterative: r continues until no nodes exchange info. r self-terminating: no “signal” to stop asynchronous: r nodes need not exchange info/iterate in lock step! distributed: r each node communicates only with directly-attached neighbors Each node: wait for (change in local link cost of msg from neighbor) recompute distance table if least cost path to any dest has changed, notify neighbors 59

Hierarchical Routing Our routing review thus far - idealization r all routers identical r network “flat” … not true in practice scale: with 200 million destinations: r can’t store all dest’s in routing tables! r routing table exchange would swamp links! administrative autonomy r internet = network of networks r each network admin may want to control routing in its own network 60

Hierarchical Routing r aggregate routers into regions, “autonomous systems” (AS) r routers in same AS run same routing protocol m m “intra-AS” routing protocol routers in different AS can run different intra. AS routing protocol gateway routers r special routers in AS r run intra-AS routing protocol with all other routers in AS r also responsible for routing to destinations outside AS m run inter-AS routing protocol with other gateway routers 61

Intra-AS and Inter-AS routing C. b a C Gateways: B. a A. a b A. c d A a b c a c B b • perform inter-AS routing amongst themselves • perform intra-AS routers with other routers in their AS network layer inter-AS, intra-AS routing in gateway A. c link layer physical layer 62

Intra-AS and Inter-AS routing C. b a Host h 1 C b A. a a Inter-AS Internet: BGP routing B. a between A and B Host h 2 c A. c a b B d c b A Intra-AS routing within AS B Internet: OSPF, IS-IS, RIP 63

Addressing r What’s an address? m identifier that differentiates between me and someone else, and also helps route data to/from me r Real world examples of addressing? m mailing address m office #, floor, etc m different “levels of addressing” m Phone# 64

Addressing: network layer r IP address: 32 -bit identifier for host, router interface: connection between host, router and physical link m m m router’s typically have multiple interfaces host may have multiple interfaces IP addresses associated with interface, not host, router 223. 1. 1. 1 223. 1. 1. 2 223. 1. 1. 4 223. 1. 1. 3 223. 1. 2. 1 223. 1. 2. 9 223. 1. 3. 27 223. 1. 2. 2 223. 1. 1. 1 = 11011111 00000001 223 1 1 1 65

IP Addressing r IP address: m network part (high order bits) m host part (low order bits) r What’s a network ? (from IP address perspective) m device interfaces with same network part of IP address m can physically reach other without intervening router 223. 1. 1. 1 223. 1. 1. 2 223. 1. 1. 4 223. 1. 1. 3 223. 1. 2. 1 223. 1. 2. 9 223. 1. 3. 27 223. 1. 2. 2 LAN 223. 1. 3. 2 network consisting of 3 IP networks (for IP addresses starting with 223, first 24 bits are network address) 66

IP addresses: how to get one? Q: How does host get IP address? r hard-coded by system admin in a file m Wintel: control-panel->network->configuration->tcp/ip->properties m UNIX: /etc/rc. config r DHCP: Dynamic Host Configuration Protocol: dynamically get address: “plug-and-play” m host broadcasts “DHCP discover” msg m DHCP server responds with “DHCP offer” msg m host requests IP address: “DHCP request” msg m DHCP server sends address: “DHCP ack” msg 67

Part 0: Networking Review Goals: r review key topics from intro networks course m m m Overview: r overview r error control r flow control equalize backgrounds r congestion control identify remedial work r routing ease into course r LANs r addressing (cont. ) r synthesis: m m “a day in the life” control timescales 68

Link Layer: setting the context 69

Link Layer: setting the context r two physically connected devices: m host-router, router-router, host-host r unit of data: frame M Ht M Hn Ht M Hl Hn Ht M application transport network link physical data link protocol phys. link network link physical Hl Hn Ht M frame adapter card 70

Link Layer Services r Framing, link access: m encapsulate datagram into frame, adding header, trailer m implement channel access if shared medium (e. g. , Ethernet) m ‘physical addresses’ used in frame headers to identify source, dest • different from IP address! r reliable delivery between two physically connected devices r flow control r error detection/congestion 71

LAN Addresses and ARP 32 -bit IP address: r network-layer address r used to get datagram to destination network (recall IP network definition) LAN (or MAC or physical) address: r used to get frame from one interface to another physically-connected interface (same network) r 48 bit MAC address (for most LANs) burned in the adapter ROM r WHY MAC and Internet addresses separate? m m IP addresses depend on network that you’re on MAC address in hardware makes it faster 72

LAN Addresses Each adapter on LAN has unique LAN address LAN (or MAC or physical) address: r used to get datagram from one interface to another physicallyconnected interface (same network) r 48 bit MAC address (for most LANs) burned in the adapter ROM 73

LAN Address (more) r MAC address allocation administered by IEEE r manufacturer buys portion of MAC address space (to assure uniqueness) r Analogy: (a) MAC address: like Social Security Number (b) IP address: like postal address r MAC flat address => portability m can move LAN card from one LAN to another r IP hierarchical address NOT portable m depends on network to which one attaches 74

From IP to MAC addresses Starting at A, given IP datagram addressed to B: A 223. 1. 1. 1 223. 1. 2. 1 r look up net. address of B, find B on same net. as A r link layer send datagram to B inside link-layer frame source, dest address B’s MAC A’s MAC addr 223. 1. 1. 2 223. 1. 1. 4 223. 1. 2. 9 B 223. 1. 1. 3 datagram source, dest address A’s IP addr B’s IP addr 223. 1. 3. 27 223. 1. 2. 2 E 223. 1. 3. 2 IP payload datagram frame 75

ARP protocol r A knows B's IP address, wants to learn physical address of B r A broadcasts ARP query pkt, containing B's IP address m all machines on LAN receive ARP query r B receives ARP packet, replies to A with its (B's) physical layer address r A caches (saves) IP-to-physical address pairs until information becomes old (times out) m soft state: information that times out (goes away) unless refreshed 76

Part 0: Networking Review Goals: r review key topics from intro networks course m m m Overview: r overview r error control r flow control equalize backgrounds r congestion control identify remedial work r routing ease into course r LANs r addressing (cont. ) r synthesis: m m “a day in the life” control timescales 77

Synthesis: which protocols involved? www browser downloads page 78

Protocols involved in http GET r User types ina URL, what happens? r DNS: translate hostname to IP address m Via DHCP, source has IP address of DNS server (suppose DNS server is on same network segment) m Create DNS query, pass to UDP, create UDP segment containing DNS query, pass to IP on host m Look in routing table (DHCP gave me default router), recognize that DNS server is on same network. m Use ARP to determine MAC address of DNS server m Ethernet used to send frame to DNS server on physically connected “wire” (network segment, ethernet “cable”) m On DNS machine ethernet->IP->UDP. UDP looks at dest port #, sees it is DNS, passes DNS query to DNS application. (assume dns knows IP addresses of hostname in original URL - address found!) m DNS server sends UDP reply back to orginating machine 79

Protocols involved in http GET r So: browser now has IP address of GET destination server r Need to establish TCP connection to server, TCP connection establishment sends SYN packet (will get an SYNACK back, eventuallly…. ) m SYN packet down to network layer, with IP address of server. Since server destined “off my network”, SYN packet will need to go through router. m Look in routing table, see that destined off network, need to send to “default gateway” (to get off my net) m Use ARP to get MAC address of default gateway, create Ethernet frame with gateway MAC address, containing IP packet containing TCP segment, containing SYN m It is IMPORTANT to realize that while the Ethernet frame containing the IP datagram that contains the TCP SYN has as its destination address the MAC address of the router, the IP datagram (still) has as its destination address the IP address of the remote www server 80

Protocols involved in http GET r Router receives Ethernet frame (frame is addressed to router), looks at IP datagram and sees that IP datagram is not addressed to itself (IP datagram is addressed to server). So router knows that it must forward the IP datagram to the next hop router along the path to the eventual destination. r Router checks routing tables (table values populated using intra, r r r possibly inter-, domain routing protocols like OSPF, RIP, IS-IS, BGP (inter). Get IP address of next hop router. Router puts IP packets in Ethernet frame, Ethernet frame addressed to next hop router. MAC address of next hope router determined by ARP. Frame sent to next hop router. Network management shoehorn: arriving packets at interface cause SNMP MIB variable for # arriving IP datagrams to be incremented …. This forwarding continues until IP datagram contain TCP SYN eventually arrives at destination, gaia. cs. umass. edu (128. 119. 30) Up to IP, demultiplex from Ethernet to IP using Ethernet TYPE field to identify IP as upper layer protocol From IP to TCP using protocol field of IP datagram, SYN packet arrives at gaia TCP (FINALLY) 81

Protocols involved in http GET r So …. SYN has arrived at gaia. Gaia sends back SYNACK to intial sender r Gaia gets synack, ready to send data. r HTTP GET message now sent to gaia. cs. umass. edu in a TCP segment, in IP datagram, Ethernet frame, along hops to gaia. cs. umass. edu r GET arrives! REPLY formulated by http server … and sent 82