Review Of Concepts: Computer Networks. Introduction 1-2 Introduction Our goal: r get “feel” and terminology r more depth, detail later r approach: m use

Embed Size (px)

DESCRIPTION

Introduction 1-3 What’s the Internet r millions of connected computing devices: hosts = end systems m running network apps Home network Institutional network Mobile network Global ISP Regional ISP router PC server wireless laptop cellular handheld wired links access points  communication links  fiber, copper, radio, satellite  transmission rate = bandwidth  routers: forward packets (chunks of data)

Citation preview

Review Of Concepts: Computer Networks Introduction 1-2 Introduction Our goal: r get feel and terminology r more depth, detail later r approach: m use Internet as example Introduction 1-3 Whats the Internet r millions of connected computing devices: hosts = end systems m running network apps Home network Institutional network Mobile network Global ISP Regional ISP router PC server wireless laptop cellular handheld wired links access points communication links fiber, copper, radio, satellite transmission rate = bandwidth routers: forward packets (chunks of data) Introduction 1-4 Whats the Internet r protocols control sending, receiving of msgs m e.g., TCP, IP, HTTP, Skype, Ethernet r Internet: network of networks m loosely hierarchical m public Internet versus private intranet r Internet standards m RFC: Request for comments m IETF: Internet Engineering Task Force Home network Institutional network Mobile network Global ISP Regional ISP Introduction 1-5 Whats the Internet: a service view r communication infrastructure enables distributed applications: m Web, VoIP,, games, e-commerce, file sharing r communication services provided to apps: m reliable data delivery from source to destination m best effort (unreliable) data delivery Introduction 1-6 Whats a protocol? human protocols: r whats 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 protocols define format, order of msgs sent and received among network entities, and actions taken on msg transmission, receipt Introduction 1-7 Whats a protocol? a human protocol and a computer network protocol: Q: Other human protocols? Hi Got the time? 2:00 TCP connection request TCP connection response Gettime Introduction 1-8 A closer look at network structure: r network edge: applications and hosts access networks, physical media: wired, wireless communication links network core: interconnected routers network of networks Introduction 1-9 The network edge: r end systems (hosts): m run application programs m e.g. Web,m at edge of network client/server peer-peer client/server model client host requests, receives service from always-on server e.g. Web browser/server;client/server peer-peer model: minimal (or no) use of dedicated servers e.g. Skype, BitTorrent Introduction 1-10 Access networks and physical media Q: How to connect 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? Introduction 1-11 Company access: local area networks r company/univ local area network (LAN) connects end system to edge router r Ethernet: m 10 Mbs, 100Mbps, 1Gbps, 10Gbps Ethernet m modern configuration: end systems connect into Ethernet switch Introduction 1-12 Wireless access networks r shared wireless access network connects end system to router m via base station aka access point r wireless LANs: m b/g (WiFi): 11 or 54 Mbps r wider-area wireless access m provided by telco operator m ~1Mbps over cellular system (EVDO, HSDPA) m next up (?): WiMAX (10s Mbps) over wide area base station mobile hosts router Introduction 1-13 Home networks Typical home network components: r DSL or cable modem r router/firewall/NAT r Ethernet r wireless access point wireless access point wireless laptops router/ firewall cable modem to/from cable headend Ethernet Introduction 1-14 Physical Media r Bit: propagates between transmitter/rcvr pairs r physical link: what lies between transmitter & receiver r guided media: m signals propagate in solid media: copper, fiber, coax r unguided media: m signals propagate freely, e.g., radio Twisted Pair (TP) r two insulated copper wires m Category 3: traditional phone wires, 10 Mbps Ethernet m Category 5: 100Mbps Ethernet Introduction 1-15 Physical Media: coax, fiber Coaxial cable: r two concentric copper conductors r bidirectional r baseband: m single channel on cable m legacy Ethernet r broadband: m multiple channels on cable Fiber optic cable: glass fiber carrying light pulses, each pulse a bit high-speed operation: high-speed point-to-point transmission (e.g., 10s- 100s Gps) low error rate: repeaters spaced far apart ; immune to electromagnetic noise Introduction 1-16 Physical media: radio r signal carried in electromagnetic spectrum r no physical wire r bidirectional r propagation environment effects: m reflection m obstruction by objects m interference Radio link types: terrestrial microwave e.g. up to 45 Mbps channels LAN (e.g., Wifi) 11Mbps, 54 Mbps wide-area (e.g., cellular) 3G cellular: ~ 1 Mbps satellite Kbps to 45Mbps channel (or multiple smaller channels) 270 msec end-end delay geosynchronous versus low altitude Introduction 1-17 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 Introduction 1-18 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 Introduction 1-19 Network Core: Circuit Switching network resources (e.g., bandwidth) divided into pieces r pieces allocated to calls r resource piece idle if not used by owning call (no sharing) dividing link bandwidth into pieces frequency division time division Introduction 1-20 Circuit Switching: FDM and TDM FDM frequency time TDM frequency time 4 users Example: Introduction 1-21 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 resource contention: aggregate resource demand can exceed amount available congestion: packets queue, wait for link use store and forward: packets move one hop at a time Node receives complete packet before forwarding Introduction 1-22 Packet Switching: Statistical Multiplexing Sequence of A & B packets does not have fixed pattern, bandwidth shared on demand statistical multiplexing. TDM: each host gets same slot in revolving TDM frame. A B C 100 Mb/s Ethernet 1.5 Mb/s D E statistical multiplexing queue of packets waiting for output link Introduction 1-23 Packet-switching: store-and-forward r takes L/R seconds to transmit (push out) packet of L bits on to link at R bps r store and forward: entire packet must arrive at router before it can be transmitted on next link r delay = 3L/R (assuming zero propagation delay) Example: r L = 7.5 Mbits r R = 1.5 Mbps r transmission delay = 15 sec R R R L more on delay shortly Introduction 1-24 Internet structure: network of networks r roughly hierarchical r at center: tier-1 ISPs (e.g., Verizon, Sprint, AT&T, Cable and Wireless), national/international coverage m treat each other as equals Tier 1 ISP Tier-1 providers interconnect (peer) privately Introduction 1-25 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 1 ISP Tier-2 ISP Tier-2 ISP pays tier-1 ISP for connectivity to rest of Internet tier-2 ISP is customer of tier-1 provider Tier-2 ISPs also peer privately with each other. Introduction 1-26 Internet structure: network of networks r Tier-3 ISPs and local ISPs m last hop (access) network (closest to end systems) Tier 1 ISP Tier-2 ISP local ISP local ISP local ISP local ISP local ISP Tier 3 ISP local ISP local ISP local ISP Local and tier- 3 ISPs are customers of higher tier ISPs connecting them to rest of Internet Introduction 1-27 Internet structure: network of networks r a packet passes through many networks! Tier 1 ISP Tier-2 ISP local ISP local ISP local ISP local ISP local ISP Tier 3 ISP local ISP local ISP local ISP Introduction 1-28 How do loss and delay occur? packets queue in router buffers r packet arrival rate to link exceeds output link capacity r packets queue, wait for turn A B packet being transmitted (delay) packets queueing (delay) free (available) buffers: arriving packets dropped (loss) if no free buffers Introduction 1-29 Four sources of packet delay r 1. nodal processing: m check bit errors m determine output link A B propagation transmission nodal processing queueing 2. queueing time waiting at output link for transmission depends on congestion level of router Introduction 1-30 Delay in packet-switched networks 3. Transmission delay: r R=link bandwidth (bps) r L=packet length (bits) r time to send bits into link = L/R 4. Propagation delay: r d = length of physical link r s = propagation speed in medium (~2x10 8 m/sec) r propagation delay = d/s A B propagation transmission nodal processing queueing Note: s and R are very different quantities! Introduction 1-31 Nodal delay r d proc = processing delay m typically a few microsecs or less r d queue = queuing delay m depends on congestion r d trans = transmission delay m = L/R, significant for low-speed links r d prop = propagation delay m a few microsecs to hundreds of msecs Introduction 1-32 Protocol Layers Networks are complex! r many pieces: m hosts m routers m links of various media m applications m protocols m hardware, software Question: Is there any hope of organizing structure of network? Or at least our discussion of networks? Introduction 1-33 Organization of air travel r a series of steps ticket (purchase) baggage (check) gates (load) runway takeoff airplane routing ticket (complain) baggage (claim) gates (unload) runway landing airplane routing Introduction 1-34 ticket (purchase) baggage (check) gates (load) runway (takeoff) airplane routing departure airport arrival airport intermediate air-traffic control centers airplane routing ticket (complain) baggage (claim gates (unload) runway (land) airplane routing ticket baggage gate takeoff/landing airplane routing Layering of airline functionality Layers: each layer implements a service m via its own internal-layer actions m relying on services provided by layer below Introduction 1-35 Why layering? Dealing with complex systems: r explicit structure allows identification, relationship of complex systems pieces m layered reference model for discussion r modularization eases maintenance, updating of system m change of implementation of layers service transparent to rest of system m e.g., change in gate procedure doesnt affect rest of system r layering considered harmful? Introduction 1-36 Internet protocol stack r application: supporting network applications m FTP, SMTP, HTTP r transport: process-process data transfer m TCP, UDP r network: routing of datagrams from source to destination m IP, routing protocols r link: data transfer between neighboring network elements m PPP, Ethernet r physical: bits on the wire application transport network link physical Introduction 1-37 ISO/OSI reference model r presentation: allow applications to interpret meaning of data, e.g., encryption, compression, machine- specific conventions r session: synchronization, checkpointing, recovery of data exchange r Internet stack missing these layers! m these services, if needed, must be implemented in application m needed? application presentation session transport network link physical Introduction 1-38 source application transport network link physical HtHt HnHn M segment HtHt datagram destination application transport network link physical HtHt HnHn HlHl M HtHt HnHn M HtHt M M network link physical link physical HtHt HnHn HlHl M HtHt HnHn M HtHt HnHn M HtHt HnHn HlHl M router switch Encapsulation message M HtHt M HnHn frame DataLink Layer 5-39 The Data Link Layer Our goals: r understand principles behind data link layer services: m error detection, correction m sharing a broadcast channel: multiple access m link layer addressing m reliable data transfer, flow control 5: DataLink Layer 5-40 Link Layer: Introduction Some terminology: r hosts and routers are nodes r communication channels that connect adjacent nodes along communication path are links m wired links m wireless links m LANs r layer-2 packet is a frame, encapsulates datagram data-link layer has responsibility of transferring datagram from one node to adjacent node over a link 5: DataLink Layer 5-41 Link layer: context r datagram transferred by different link protocols over different links: m e.g., Ethernet on first link, frame relay on intermediate links, on last link r each link protocol provides different services m e.g., may or may not provide rdt over link transportation analogy r trip from Indore to Delhi m car: Indore to Dewas m train: Dewas to Bhopal m plane: Bhopal to Delhi r tourist = datagram r transport segment = communication link r transportation mode = link layer protocol r travel agent = routing algorithm 5: DataLink Layer 5-42 Link Layer Services r framing, link access: m encapsulate datagram into frame, adding header, trailer m channel access if shared medium m MAC addresses used in frame headers to identify source, dest different from IP address! r reliable delivery between adjacent nodes m seldom used on low bit-error link (fiber, some twisted pair) m wireless links: high error rates Q: why both link-level and end-end reliability? 5: DataLink Layer 5-43 Link Layer Services (more) r flow control: m pacing between adjacent sending and receiving nodes r error detection: m errors caused by signal attenuation, noise. m receiver detects presence of errors: signals sender for retransmission or drops frame r error correction: m receiver identifies and corrects bit error(s) without resorting to retransmission 5: DataLink Layer 5-44 Where is the link layer implemented? r in each and every host r link layer implemented in adaptor (aka network interface card NIC) m Ethernet card, PCMCI card, card m implements link, physical layer r attaches into hosts system buses r combination of hardware, software, firmware controller physical transmission cpu memory host bus (e.g., PCI) network adapter card host schematic application transport network link physical 5: DataLink Layer 5-45 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 otherwise 5: DataLink Layer 5-46 Multiple Access Links and Protocols Two types of links: r point-to-point m PPP for dial-up access m point-to-point link between Ethernet switch and host r broadcast (shared wire or medium) m old-fashioned Ethernet m wireless LAN shared wire (e.g., cabled Ethernet) shared RF (e.g., WiFi) shared RF (satellite) humans at a cocktail party (shared air, acoustical) 5: DataLink Layer 5-47 Multiple Access protocols r single shared broadcast channel r two or more simultaneous transmissions by nodes: interference m collision if node receives two or more signals at the same time multiple access protocol r distributed algorithm that determines how nodes share channel, i.e., determine when node can transmit r communication about channel sharing must use channel itself! 5: DataLink Layer 5-48 MAC Protocols: a taxonomy Three broad classes: r Channel Partitioning m divide channel into smaller pieces (time slots, frequency, code) m allocate piece to node for exclusive use r Random Access m channel not divided, allow collisions m recover from collisions r Taking turns m nodes take turns, but nodes with more to send can take longer turns 5: DataLink Layer 5-49 Channel Partitioning MAC protocols: TDMA TDMA: time division multiple access r access to channel in "rounds" r each station gets fixed length slot (length = pkt trans time) in each round r unused slots go idle r example: 6-station LAN, 1,3,4 have pkt, slots 2,5,6 idle slot frame 5: DataLink Layer 5-50 Channel Partitioning MAC protocols: FDMA FDMA: frequency division multiple access r channel spectrum divided into frequency bands r each station assigned fixed frequency band r unused transmission time in frequency bands go idle r example: 6-station LAN, 1,3,4 have pkt, frequency bands 2,5,6 idle frequency bands time FDM cable 5: DataLink Layer 5-51 Random Access Protocols r When node has packet to send m transmit at full channel data rate R. m no a priori coordination among nodes two or more transmitting nodes collision, r random access MAC protocol specifies: m how to detect collisions m how to recover from collisions (e.g., via delayed retransmissions) r Examples of random access MAC protocols: m slotted ALOHA m ALOHA m CSMA, CSMA/CD, CSMA/CA 5: DataLink Layer 5-52 Slotted ALOHA Assumptions: r all frames same size r time divided into equal size slots (time to transmit 1 frame) r nodes start to transmit only slot beginning r nodes are synchronized r if 2 or more nodes transmit in slot, all nodes detect collision Operation: r when node obtains fresh frame, transmits in next slot m if no collision: node can send new frame in next slot m if collision: node retransmits frame in each subsequent slot with prob. p until success 5: DataLink Layer 5-53 Slotted ALOHA Pros r single active node can continuously transmit at full rate of channel r highly decentralized: only slots in nodes need to be in sync r simple Cons r collisions, wasting slots r idle slots r nodes may be able to detect collision in less than time to transmit packet r clock synchronization 5: DataLink Layer 5-54 Slotted Aloha efficiency r suppose: N nodes with many frames to send, each transmits in slot with probability p r prob that given node has success in a slot = p(1-p) N-1 r prob that any node has a success = Np(1-p) N-1 r max efficiency: find p* that maximizes Np(1-p) N-1 r for many nodes, take limit of Np*(1-p*) N-1 as N goes to infinity, gives: Max efficiency = 1/e =.37 Efficiency : long-run fraction of successful slots (many nodes, all with many frames to send) At best: channel used for useful transmissions 37% of time! ! 5: DataLink Layer 5-55 Pure (unslotted) ALOHA r unslotted Aloha: simpler, no synchronization r when frame first arrives m transmit immediately r collision probability increases: m frame sent at t 0 collides with other frames sent in [t 0 -1,t 0 +1] 5: DataLink Layer 5-56 Pure Aloha efficiency P(success by given node) = P(node transmits). P(no other node transmits in [p 0 -1,p 0 ]. P(no other node transmits in [p 0 -1,p 0 ] = p. (1-p) N-1. (1-p) N-1 = p. (1-p) 2(N-1) choosing optimum p and then letting n -> infty... = 1/(2e) =.18 even worse than slotted Aloha! 5: DataLink Layer 5-57 CSMA (Carrier Sense Multiple Access) CSMA: listen before transmit: If channel sensed idle: transmit entire frame r If channel sensed busy, defer transmission r human analogy: dont interrupt others! 5: DataLink Layer 5-58 CSMA collisions collisions can still occur: propagation delay means two nodes may not hear each others transmission collision: entire packet transmission time wasted spatial layout of nodes note: role of distance & propagation delay in determining collision probability 5: DataLink Layer 5-59 CSMA/CD (Collision Detection) CSMA/CD: carrier sensing, deferral as in CSMA m collisions detected within short time m colliding transmissions aborted, reducing channel wastage r collision detection: m easy in wired LANs: measure signal strengths, compare transmitted, received signals m difficult in wireless LANs: received signal strength overwhelmed by local transmission strength r human analogy: the polite conversationalist 5: DataLink Layer 5-60 CSMA/CD collision detection 5: DataLink Layer 5-61 Taking Turns MAC protocols channel partitioning MAC protocols: m share channel efficiently and fairly at high load m inefficient at low load: delay in channel access, 1/N bandwidth allocated even if only 1 active node! Random access MAC protocols m efficient at low load: single node can fully utilize channel m high load: collision overhead taking turns protocols look for best of both worlds! 5: DataLink Layer 5-62 Taking Turns MAC protocols Polling: r master node invites slave nodes to transmit in turn r typically used with dumb slave devices r concerns: m polling overhead m latency m single point of failure (master) master slaves poll data 5: DataLink Layer 5-63 Taking Turns MAC protocols Token passing: r control token passed from one node to next sequentially. r token message r concerns: m token overhead m latency m single point of failure (token) T data (nothing to send) T 5: DataLink Layer 5-64 Summary of MAC protocols r channel partitioning, by time, frequency or code m Time Division, Frequency Division r random access (dynamic), m ALOHA, S-ALOHA, CSMA, CSMA/CD m carrier sensing: easy in some technologies (wire), hard in others (wireless) m CSMA/CD used in Ethernet m CSMA/CA used in r taking turns m polling from central site, token passing m Bluetooth, FDDI, IBM Token Ring 5: DataLink Layer 5-65 MAC Addresses and ARP r 32-bit IP address: m network-layer address m used to get datagram to destination IP subnet r MAC (or LAN or physical or Ethernet) address: m function: get frame from one interface to another physically-connected interface (same network) m 48 bit MAC address (for most LANs) burned in NIC ROM, also sometimes software settable 5: DataLink Layer 5-66 LAN Addresses and ARP Each adapter on LAN has unique LAN address Broadcast address = FF-FF-FF-FF-FF-FF = adapter 1A-2F-BB AD D7-FA-20-B0 0C-C4-11-6F-E F7-2B LAN (wired or wireless) 5: DataLink Layer 5-67 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 MAC flat address portability m can move LAN card from one LAN to another r IP hierarchical address NOT portable m address depends on IP subnet to which node is attached 5: DataLink Layer 5-68 ARP: Address Resolution Protocol r Each IP node (host, router) on LAN has ARP table r ARP table: IP/MAC address mappings for some LAN nodes m TTL (Time To Live): time after which address mapping will be forgotten (typically 20 min) Question: how to determine MAC address of B knowing Bs IP address? 1A-2F-BB AD D7-FA-20-B0 0C-C4-11-6F-E F7-2B LAN 5: DataLink Layer 5-69 ARP protocol: Same LAN (network) r A wants to send datagram to B, and Bs MAC address not in As ARP table. r A broadcasts ARP query packet, containing B's IP address m dest MAC address = FF- FF-FF-FF-FF-FF m all machines on LAN receive ARP query r B receives ARP packet, replies to A with its (B's) MAC address m frame sent to As MAC address (unicast) r A caches (saves) IP-to- MAC address pair in its ARP table until information becomes old (times out) m soft state: information that times out (goes away) unless refreshed r ARP is plug-and-play: m nodes create their ARP tables without intervention from net administrator Transport Layer 3-70 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-71 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-72 Principles of Reliable data transfer r important in app., transport, link layers r top-10 list of important networking topics! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Transport Layer 3-73 Reliable data transfer: getting started send side receive side rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer udt_send(): called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv(): called when packet arrives on rcv-side of channel deliver_data(): called by rdt to deliver data to upper Transport Layer 3-74 Rdt1.0: Stop and Wait Flow Control r underlying channel perfectly reliable m no bit errors m no loss of packets r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel Wait for call from above packet = make_pkt(data) udt_send(packet) rdt_send(data) extract (packet,data) deliver_data(data) Wait for call from below rdt_rcv(packet) sender receiver Transport Layer 3-75 Rdt2.0: Stop and Wait ARQ r underlying channel may flip bits in packet m checksum to detect bit errors r the question: how to recover from errors: m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK m negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NAK new mechanisms in rdt2.0 (beyond rdt1.0 ): m error detection m receiver feedback: control msgs (ACK,NAK) rcvr->sender Transport Layer 3-76 rdt2.0: FSM specification Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below sender receiver rdt_send(data) Transport Layer 3-77 rdt2.0: operation with no errors Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data) Transport Layer 3-78 rdt2.0: error scenario Wait for call from above snkpkt = make_pkt(data, checksum) udt_send(sndpkt) extract(rcvpkt,data) deliver_data(data) udt_send(ACK) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) rdt_rcv(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && isNAK(rcvpkt) udt_send(NAK) rdt_rcv(rcvpkt) && corrupt(rcvpkt) Wait for ACK or NAK Wait for call from below rdt_send(data) Transport Layer 3-79 rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesnt know what happened at receiver! r cant just retransmit: possible duplicate Handling duplicates: r sender retransmits current pkt if ACK/NAK garbled r sender adds sequence number to each pkt r receiver discards (doesnt deliver up) duplicate pkt Sender sends one packet, then waits for receiver response stop and wait Transport Layer 3-80 rdt2.1: sender, handles garbled ACK/NAKs Wait for call 0 from above sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) rdt_send(data) Wait for ACK or NAK 0 udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) udt_send(sndpkt) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isNAK(rcvpkt) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt) Wait for call 1 from above Wait for ACK or NAK 1 Transport Layer 3-81 rdt2.1: receiver, handles garbled ACK/NAKs Wait for 0 from below sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) Wait for 1 from below rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) rdt_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(ACK, chksum) udt_send(sndpkt) sndpkt = make_pkt(NAK, chksum) udt_send(sndpkt) Transport Layer 3-82 rdt2.1: discussion Sender: r seq # added to pkt r two seq. #s (0,1) will suffice. Why? r must check if received ACK/NAK corrupted r twice as many states m state must remember whether current pkt has 0 or 1 seq. # Receiver: r must check if received packet is duplicate m state indicates whether 0 or 1 is expected pkt seq # r note: receiver can not know if its last ACK/NAK received OK at sender Transport Layer 3-83 rdt3.0: Stop & Wait ARQ (complete) New assumption: underlying channel can also lose packets (data or ACKs) m checksum, seq. #, ACKs, retransmissions will be of help, but not enough 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 seq. #s already handles this m receiver must specify seq # of pkt being ACKed r requires countdown timer Transport Layer 3-84 rdt3.0 sender sndpkt = make_pkt(0, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) Wait for ACK0 rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,1) ) Wait for call 1 from above sndpkt = make_pkt(1, data, checksum) udt_send(sndpkt) start_timer rdt_send(data) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,0) rdt_rcv(rcvpkt) && ( corrupt(rcvpkt) || isACK(rcvpkt,0) ) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && isACK(rcvpkt,1) stop_timer udt_send(sndpkt) start_timer timeout udt_send(sndpkt) start_timer timeout rdt_rcv(rcvpkt) Wait for call 0from above Wait for ACK1 rdt_rcv(rcvpkt) Transport Layer 3-85 rdt3.0 in action Transport Layer 3-86 rdt3.0 in action Transport Layer 3-87 Performance of rdt3.0 r rdt3.0 works, but performance stinks r ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: m U sender : utilization fraction of time sender busy sending m 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link m network protocol limits use of physical resources! Transport Layer 3-88 rdt3.0: stop-and-wait operation first packet bit transmitted, t = 0 senderreceiver RTT last packet bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Transport Layer 3-89 Pipelined protocols Pipelining: sender allows multiple, in-flight, yet-to- be-acknowledged pkts m range of sequence numbers must be increased m buffering at sender and/or receiver r Two generic forms of pipelined protocols: go-Back-N, selective repeat Transport Layer 3-90 Pipelining: increased utilization first packet bit transmitted, t = 0 senderreceiver RTT last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK Increase utilization by a factor of 3! Transport Layer 3-91 Pipelining Protocols Go-back-N: big picture: r Sender can have up to N unacked packets in pipeline r Rcvr only sends cumulative acks m Doesnt ack packet if theres a gap r Sender has timer for oldest unacked packet m If timer expires, retransmit all unacked packets Selective Repeat: big pic r Sender can have up to N unacked packets in pipeline r Rcvr acks individual packets r Sender maintains timer for each unacked packet m When timer expires, retransmit only unack packet Transport Layer 3-92 Selective repeat: big picture r Sender can have up to N unacked packets in pipeline r Rcvr acks individual packets r Sender maintains timer for each unacked packet m When timer expires, retransmit only unack packet Transport Layer 3-93 Go-Back-N Sender: r k-bit seq # in pkt header r window of up to N, consecutive unacked pkts allowed r ACK(n): ACKs all pkts up to, including seq # n - cumulative ACK m may receive duplicate ACKs (see receiver) r timer for each in-flight pkt r timeout(n): retransmit pkt n and all higher seq # pkts in window Transport Layer 3-94 GBN: sender extended FSM Wait start_timer udt_send(sndpkt[base]) udt_send(sndpkt[base+1]) udt_send(sndpkt[nextseqnum-1]) timeout rdt_send(data) if (nextseqnum < base+N) { sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum) udt_send(sndpkt[nextseqnum]) if (base == nextseqnum) start_timer nextseqnum++ } else refuse_data(data) base = getacknum(rcvpkt)+1 If (base == nextseqnum) stop_timer else start_timer rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) base=1 nextseqnum=1 rdt_rcv(rcvpkt) && corrupt(rcvpkt) Transport Layer 3-95 GBN: receiver extended FSM ACK-only: always send ACK for correctly-received pkt with highest in-order seq # m may generate duplicate ACKs need only remember expectedseqnum r out-of-order pkt: m discard (dont buffer) -> no receiver buffering! m Re-ACK pkt with highest in-order seq # Wait udt_send(sndpkt) default rdt_rcv(rcvpkt) && notcurrupt(rcvpkt) && hasseqnum(rcvpkt,expectedseqnum) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(expectedseqnum,ACK,chksum) udt_send(sndpkt) expectedseqnum++ expectedseqnum=1 sndpkt = make_pkt(expectedseqnum,ACK,chksum) Transport Layer 3-96 GBN in action Transport Layer 3-97 Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts, as needed, for eventual in-order delivery to upper layer r sender only resends pkts for which ACK not received m sender timer for each unACKed pkt r sender window m N consecutive seq #s m again limits seq #s of sent, unACKed pkts Transport Layer 3-98 Selective repeat: sender, receiver windows Transport Layer 3-99 Selective repeat data from above : r if next available seq # in window, send pkt timeout(n): r resend pkt n, restart timer ACK(n) in [sendbase,sendbase+N]: r mark pkt n as received r if n smallest unACKed pkt, advance window base to next unACKed seq # sender pkt n in [rcvbase, rcvbase+N-1] r send ACK(n) r out-of-order: buffer r in-order: deliver (also deliver buffered, in-order pkts), advance window to next not-yet-received pkt pkt n in [rcvbase-N,rcvbase-1] r ACK(n) otherwise: r ignore receiver Transport Layer Selective repeat in action Network Layer Network Layer Our goals: r understand principles behind network layer services: m network layer service models m forwarding versus routing m how a router works m routing (path selection) m dealing with scale r instantiation, implementation in the Internet Network Layer Network layer r transport segment from sending to receiving host r on sending side encapsulates segments into datagrams r on rcving side, delivers segments to transport layer r network layer protocols in every host, router r router examines header fields in all IP datagrams passing through it application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical Network Layer Two Key Network-Layer Functions r forwarding: move packets from routers input to appropriate router output r routing: determine route taken by packets from source to dest. m routing algorithms analogy: r routing: process of planning trip from source to dest r forwarding: process of getting through single interchange Network Layer Network service model Q: What service model for channel transporting datagrams from sender to receiver? Example services for individual datagrams: r guaranteed delivery r guaranteed delivery with less than 40 msec delay Example services for a flow of datagrams: r in-order datagram delivery r guaranteed minimum bandwidth to flow r restrictions on changes in inter- packet spacing Network Layer Router Architecture Overview Two key router functions: r run routing algorithms/protocol (RIP, OSPF, BGP) r forwarding datagrams from incoming to outgoing link Network Layer The Internet Network layer forwarding table Host, router network layer functions: Routing protocols path selection RIP, OSPF, BGP IP protocol addressing conventions datagram format packet handling conventions ICMP protocol error reporting router signaling Transport layer: TCP, UDP Link layer physical layer Network layer Network Layer IP datagram format ver length 32 bits data (variable length, typically a TCP or UDP segment) 16-bit identifier header checksum time to live 32 bit source IP address IP protocol version number header length (bytes) max number remaining hops (decremented at each router) for fragmentation/ reassembly total datagram length (bytes) upper layer protocol to deliver payload to head. len type of service type of data flgs fragment offset upper layer 32 bit destination IP address Options (if any) E.g. timestamp, record route taken, specify list of routers to visit. how much overhead with TCP? r 20 bytes of TCP r 20 bytes of IP r = 40 bytes + app layer overhead Network Layer IP Fragmentation & Reassembly r network links have MTU (max.transfer size) - largest possible link-level frame. m different link types, different MTUs r large IP datagram divided (fragmented) within net m one datagram becomes several datagrams m reassembled only at final destination m IP header bits used to identify, order related fragments fragmentation: in: one large datagram out: 3 smaller datagrams reassembly Network Layer IP Fragmentation and Reassembly ID =x offset =0 fragflag =0 length =4000 ID =x offset =0 fragflag =1 length =1500 ID =x offset =185 fragflag =1 length =1500 ID =x offset =370 fragflag =0 length =1040 One large datagram becomes several smaller datagrams Example r 4000 byte datagram r MTU = 1500 bytes 1480 bytes in data field offset = 1480/8 Network Layer IP Addressing: introduction r IP address: 32-bit identifier for host, router interface r interface: connection between host/router and physical link m routers typically have multiple interfaces m host typically has one interface m IP addresses associated with each interface = Network Layer Subnets r IP address: m subnet part (high order bits) m host part (low order bits) r Whats a subnet ? m device interfaces with same subnet part of IP address m can physically reach each other without intervening router network consisting of 3 subnets subnet Network Layer Subnets / / /24 Recipe r To determine the subnets, detach each interface from its host or router, creating islands of isolated networks. Each isolated network is called a subnet. Subnet mask: /24 Network Layer Subnets How many? Network Layer IP addressing: CIDR CIDR: Classless InterDomain Routing m subnet portion of address of arbitrary length m address format: a.b.c.d/x, where x is # bits in subnet portion of address subnet part host part /23 Network Layer DHCP: Dynamic Host Configuration Protocol Goal: allow host to dynamically obtain its IP address from network server when it joins network Can renew its lease on address in use Allows reuse of addresses (only hold address while connected an on) Support for mobile users who want to join network (more shortly) DHCP overview: 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 Network Layer IP addresses: how to get one? Q: How does network get subnet part of IP addr? A: gets allocated portion of its provider ISPs address space ISP's block /20 Organization /23 Organization /23 Organization /23... .. . . Organization /23 Network Layer Hierarchical addressing: route aggregation Send me anything with addresses beginning /20 / / /23 Fly-By-Night-ISP Organization 0 Organization 7 Internet Organization 1 ISPs-R-Us Send me anything with addresses beginning /16 /23 Organization Hierarchical addressing allows efficient advertisement of routing information: Network Layer Hierarchical addressing: more specific routes ISPs-R-Us has a more specific route to Organization 1 Send me anything with addresses beginning /20 / / /23 Fly-By-Night-ISP Organization 0 Organization 7 Internet Organization 1 ISPs-R-Us Send me anything with addresses beginning /16 or /23 /23 Organization Network Layer IP addressing: the last word... Q: How does an ISP get block of addresses? A: ICANN: Internet Corporation for Assigned Names and Numbers m allocates addresses m manages DNS m assigns domain names, resolves disputes Network Layer NAT: Network Address Translation local network (e.g., home network) /24 rest of Internet Datagrams with source or destination in this network have /24 address for source, destination (as usual) All datagrams leaving local network have same single source NAT IP address: , different source port numbers Network Layer NAT: Network Address Translation r Motivation: local network uses just one IP address as far as outside world is concerned: m range of addresses not needed from ISP: just one IP address for all devices m can change addresses of devices in local network without notifying outside world m can change ISP without changing addresses of devices in local network m devices inside local net not explicitly addressable, visible by outside world (a security plus). Network Layer NAT: Network Address Translation Implementation: NAT router must: m outgoing datagrams: replace (source IP address, port #) of every outgoing datagram to (NAT IP address, new port #)... remote clients/servers will respond using (NAT IP address, new port #) as destination addr. m remember (in NAT translation table) every (source IP address, port #) to (NAT IP address, new port #) translation pair m incoming datagrams: replace (NAT IP address, new port #) in dest fields of every incoming datagram with corresponding (source IP address, port #) stored in NAT table Network Layer NAT: Network Address Translation S: , 3345 D: , : host sends datagram to , 80 NAT translation table WAN side addr LAN side addr , , 3345 S: , 80 D: , S: , 5001 D: , : NAT router changes datagram source addr from , 3345 to , 5001, updates table S: , 80 D: , : Reply arrives dest. address: , : NAT router changes datagram dest addr from , 5001 to , 3345 Network Layer Routing Algorithm classification Global or decentralized information? Global: r all routers have complete topology, link cost info r link state algorithms 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 Static or dynamic? Static: r routes change slowly over time Dynamic: r routes change more quickly m periodic update m in response to link cost changes Network Layer A Link-State Routing Algorithm Dijkstras algorithm r net topology, link costs known to all nodes m accomplished via link state broadcast m all nodes have same info r computes least cost paths from one node (source) to all other nodes m gives forwarding table for that node r iterative: after k iterations, know least cost path to k dest.s Notation: c(x,y): link cost from node x to y; = if not direct neighbors D(v): current value of cost of path from source to dest. v p(v): predecessor node along path from source to v N': set of nodes whose least cost path definitively known Network Layer Dijkstras algorithm: example Step N' u ux uxy uxyv uxyvw uxyvwz D(v),p(v) 2,u D(w),p(w) 5,u 4,x 3,y D(x),p(x) 1,u D(y),p(y) 2,x D(z),p(z) 4,y u y x wv z Network Layer Dijkstras algorithm: example (2) u y x wv z Resulting shortest-path tree from u: v x y w z (u,v) (u,x) destination link Resulting forwarding table in u: Network Layer Dijkstras algorithm, discussion Algorithm complexity: n nodes r each iteration: need to check all nodes, w, not in N r n(n+1)/2 comparisons: O(n 2 ) r more efficient implementations possible: O(nlogn) Oscillations possible: r e.g., link cost = amount of carried traffic A D C B 1 1+e e 0 e A D C B 2+e e 1 A D C B 0 2+e 1+e A D C B 2+e 0 e 0 1+e 1 initially recompute routing recompute Network Layer Distance Vector Algorithm Bellman-Ford Equation Define d x (y) := cost of least-cost path from x to y Then d x (y) = min {c(x,v) + d v (y) } where min is taken over all neighbors v of x v Network Layer Bellman-Ford example u y x wv z Clearly, d v (z) = 5, d x (z) = 3, d w (z) = 3 d u (z) = min { c(u,v) + d v (z), c(u,x) + d x (z), c(u,w) + d w (z) } = min {2 + 5, 1 + 3, 5 + 3} = 4 Node that achieves minimum is next hop in shortest path forwarding table B-F equation says: Network Layer Distance Vector Algorithm r D x (y) = estimate of least cost from x to y r Node x knows cost to each neighbor v: c(x,v) r Node x maintains distance vector D x = [D x (y): y N ] r Node x also maintains its neighbors distance vectors m For each neighbor v, x maintains D v = [D v (y): y N ] Network Layer Distance vector algorithm (4) Basic idea: r From time-to-time, each node sends its own distance vector estimate to neighbors r Asynchronous r When a node x receives new DV estimate from neighbor, it updates its own DV using B-F equation: D x (y) min v {c(x,v) + D v (y)} for each node y N Under minor, natural conditions, the estimate D x (y) converge to the actual least cost d x (y) Network Layer Distance Vector Algorithm (5) Iterative, asynchronous: each local iteration caused by: r local link cost change r DV update message from neighbor Distributed: r each node notifies neighbors only when its DV changes m neighbors then notify their neighbors if necessary wait for (change in local link cost or msg from neighbor) recompute estimates if DV to any dest has changed, notify neighbors Each node: Network Layer x y z x y z from cost to from x y z x y z 0 from cost to x y z x y z cost to x y z x y z 710 cost to time x z y node x table node y table node z table D x (y) = min{c(x,y) + D y (y), c(x,z) + D z (y)} = min{2+0, 7+1} = 2 D x (z) = min{c(x,y) + D y (z), c(x,z) + D z (z)} = min{2+1, 7+0} = 3 32 Network Layer x y z x y z from cost to from x y z x y z from cost to x y z x y z from cost to x y z x y z cost to x y z x y z from cost to x y z x y z from cost to x y z x y z from cost to x y z x y z from cost to x y z x y z 710 cost to time x z y node x table node y table node z table D x (y) = min{c(x,y) + D y (y), c(x,z) + D z (y)} = min{2+0, 7+1} = 2 D x (z) = min{c(x,y) + D y (z), c(x,z) + D z (z)} = min{2+1, 7+0} = 3 Network Layer Distance Vector: link cost changes Link cost changes: r node detects local link cost change r updates routing info, recalculates distance vector r if DV changes, notify neighbors good news travels fast x z y 1 At time t 0, y detects the link-cost change, updates its DV, and informs its neighbors. At time t 1, z receives the update from y and updates its table. It computes a new least cost to x and sends its neighbors its DV. At time t 2, y receives zs update and updates its distance table. ys least costs do not change and hence y does not send any message to z. Network Layer Distance Vector: link cost changes Link cost changes: r good news travels fast r bad news travels slow - count to infinity problem! r 44 iterations before algorithm stabilizes: see text Poisoned reverse: r If Z routes through Y to get to X : m Z tells Y its (Zs) distance to X is infinite (so Y wont route to X via Z) r will this completely solve count to infinity problem? x z y 60 Network Layer Comparison of LS and DV algorithms Message complexity r LS: with n nodes, E links, O(nE) msgs sent r DV: exchange between neighbors only m convergence time varies Speed of Convergence r LS: O(n 2 ) algorithm requires O(nE) msgs m may have oscillations r DV: convergence time varies m may be routing loops m count-to-infinity problem Robustness: what happens if router malfunctions? LS: m node can advertise incorrect link cost m each node computes only its own table DV: m DV node can advertise incorrect path cost m each nodes table used by others error propagate thru network Network Layer Hierarchical Routing r aggregate routers into regions, autonomous systems (AS) r routers in same AS run same routing protocol m intra-AS routing protocol m routers in different AS can run different intra- AS routing protocol Gateway router r Direct link to router in another AS Network Layer b 1d 3a 1c 2a AS3 AS1 AS2 1a 2c 2b 1b Intra-AS Routing algorithm Inter-AS Routing algorithm Forwarding table 3c Interconnected ASes r forwarding table configured by both intra- and inter-AS routing algorithm m intra-AS sets entries for internal dests m inter-AS & intra-As sets entries for external dests Network Layer b 1d 3a 1c 2a AS3 AS1 AS2 1a 2c 2b 1b 3c Inter-AS tasks r suppose router in AS1 receives datagram destined outside of AS1: m router should forward packet to gateway router, but which one? AS1 must: 1. learn which dests are reachable through AS2, which through AS3 2. propagate this reachability info to all routers in AS1 Job of inter-AS routing! Network Layer Intra-AS Routing r also known as Interior Gateway Protocols (IGP) r most common Intra-AS routing protocols: m RIP: Routing Information Protocol m OSPF: Open Shortest Path First m IGRP: Interior Gateway Routing Protocol (Cisco proprietary) Network Layer Internet inter-AS routing: BGP r BGP (Border Gateway Protocol): the de facto standard r BGP provides each AS a means to: 1. Obtain subnet reachability information from neighboring ASs. 2. Propagate reachability information to all AS- internal routers. 3. Determine good routes to subnets based on reachability information and policy. r allows subnet to advertise its existence to rest of Internet: I am here Network Layer Why different Intra- and Inter-AS routing ? Policy: r Inter-AS: admin wants control over how its traffic routed, who routes through its net. r Intra-AS: single admin, so no policy decisions needed Scale: r hierarchical routing saves table size, reduced update traffic Performance: r Intra-AS: can focus on performance r Inter-AS: policy may dominate over performance Network Layer R1 R2 R3R4 source duplication R1 R2 R3R4 in-network duplication duplicate creation/transmission duplicate Broadcast Routing r deliver packets from source to all other nodes r source duplication is inefficient: r source duplication: how does source determine recipient addresses? Network Layer In-network duplication r flooding: when node receives brdcst pckt, sends copy to all neighbors m Problems: cycles & broadcast storm r controlled flooding: node only brdcsts pkt if it hasnt brdcst same packet before m Node keeps track of pckt ids already brdcsted m Or reverse path forwarding (RPF): only forward pckt if it arrived on shortest path between node and source r spanning tree m No redundant packets received by any node Multicast Routing: Problem Statement r Goal: find a tree (or trees) connecting routers having local mcast group members m tree: not all paths between routers used m source-based: different tree from each sender to rcvrs m shared-tree: same tree used by all group members Shared tree Source-based trees Approaches for building mcast trees Approaches: r source-based tree: one tree per source m shortest path trees m reverse path forwarding r group-shared tree: group uses one tree m minimal spanning (Steiner) m center-based trees we first look at basic approaches, then specific protocols adopting these approaches Internet Multicasting Routing: DVMRP r DVMRP: distance vector multicast routing protocol, RFC1075 r flood and prune: reverse path forwarding, source-based tree m RPF tree based on DVMRPs own routing tables constructed by communicating DVMRP routers m no assumptions about underlying unicast m initial datagram to mcast group flooded everywhere via RPF m routers not wanting group: send upstream prune msgs PIM: Protocol Independent Multicast r not dependent on any specific underlying unicast routing algorithm (works with all) r two different multicast distribution scenarios : Dense: group members densely packed, in close proximity. bandwidth more plentiful Sparse: # networks with group members small wrt # interconnected networks group members widely dispersed bandwidth not plentiful Transport Layer Transport Layer Our goals: r understand principles behind transport layer services: m multiplexing/demultipl exing m reliable data transfer m flow control m congestion control r learn about transport layer protocols in the Internet: m UDP: connectionless transport m TCP: connection-oriented transport m TCP congestion control Transport Layer Transport services and protocols r provide logical communication between app processes running on different hosts r transport protocols run in end systems m send side: breaks app messages into segments, passes to network layer m rcv side: reassembles segments into messages, passes to app layer r more than one transport protocol available to apps m Internet: TCP and UDP application transport network data link physical application transport network data link physical logical end-end transport Transport Layer Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes m relies on, enhances, network layer services Household analogy: 12 kids sending letters to 12 kids r processes = kids r app messages = letters in envelopes r hosts = houses r transport protocol = Ann and Bill r network-layer protocol = postal service Transport Layer Internet transport-layer protocols r reliable, in-order delivery (TCP) m congestion control m flow control m connection setup r unreliable, unordered delivery: UDP m no-frills extension of best-effort IP r services not available: m delay guarantees m bandwidth guarantees application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical logical end-end transport Transport Layer Multiplexing/demultiplexing application transport network link physical P1 application transport network link physical application transport network link physical P2 P3 P4 P1 host 1 host 2 host 3 = process= socket delivering received segments to correct socket Demultiplexing at rcv host: gathering data from multiple sockets, enveloping data with header (later used for demultiplexing) Multiplexing at send host: Transport Layer How demultiplexing works r host receives IP datagrams m each datagram has source IP address, destination IP address m each datagram carries 1 transport-layer segment m each segment has source, destination port number r host uses IP addresses & port numbers to direct segment to appropriate socket source port #dest port # 32 bits application data (message) other header fields TCP/UDP segment format Transport Layer UDP: User Datagram Protocol [RFC 768] r no frills, bare bones Internet transport protocol r best effort service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired Transport Layer UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recovery! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header Transport Layer TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) inits sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver r point-to-point: m one sender, one receiver r reliable, in-order byte steam: m no message boundaries r pipelined: m TCP congestion and flow control set window size r send & receive buffers Transport Layer TCP segment structure source port # dest port # 32 bits application data (variable length) sequence number acknowledgement number Receive window Urg data pnter checksum F SR PAU head len not used Options (variable length) URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) # bytes rcvr willing to accept counting by bytes of data (not segments!) Internet checksum (as in UDP) Transport Layer TCP Connection Management TCP sender, receiver establish connection before exchanging data segments r initialize TCP variables: m seq. #s buffers, flow control info (e.g. RcvWindow ) r client: connection initiator r server: contacted by client Three way handshake: Step 1: client host sends TCP SYN segment to server m specifies initial seq # m no data Step 2: server host receives SYN, replies with SYNACK segment m server allocates buffers m specifies server initial seq. # Step 3: client receives SYNACK, replies with ACK segment, which may contain data Transport Layer TCP seq. #s and ACKs Seq. #s: m byte stream number of first byte in segments data ACKs: m seq # of next byte expected from other side m cumulative ACK Host A Host B Seq=42, ACK=79, data = C Seq=79, ACK=43, data = C Seq=43, ACK=80 User types C host ACKs receipt of echoed C host ACKs receipt of C, echoes back C time simple telnet scenario Transport Layer TCP Connection Management (cont.) Closing a connection: client closes socket Step 1: client end system sends TCP FIN control segment to server Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN. client FIN server ACK FIN close closed timed wait Transport Layer TCP Connection Management (cont.) Step 3: client receives FIN, replies with ACK. m Enters timed wait - will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed. Note: with small modification, can handle simultaneous FINs. client FIN server ACK FIN closing closed timed wait closed Transport Layer TCP Connection Management (cont) TCP client lifecycle TCP server lifecycle Transport Layer TCP reliable data transfer r TCP creates rdt service on top of IPs unreliable service r Pipelined segments r Cumulative acks r TCP uses single retransmission timer r Retransmissions are triggered by: m timeout events m duplicate acks r Initially consider simplified TCP sender: m ignore duplicate acks m ignore flow control, congestion control Transport Layer TCP sender events: data rcvd from app: r Create segment with seq # r seq # is byte-stream number of first data byte in segment r start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval timeout: r retransmit segment that caused timeout r restart timer Ack rcvd: r If acknowledges previously unacked segments m update what is known to be acked m start timer if there are outstanding segments Transport Layer TCP Flow Control r receive side of TCP connection has a receive buffer: r speed-matching service: matching the send rate to the receiving apps drain rate r app process may be slow at reading from buffer sender wont overflow receivers buffer by transmitting too much, too fast flow control Transport Layer TCP Flow control: how it works (Suppose TCP receiver discards out-of-order segments) spare room in buffer = RcvWindow = RcvBuffer-[LastByteRcvd - LastByteRead] Rcvr advertises spare room by including value of RcvWindow in segments Sender limits unACKed data to RcvWindow m guarantees receive buffer doesnt overflow Transport Layer 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! Transport Layer Causes/costs of congestion: scenario 1 r two senders, two receivers r one router, infinite buffers r no retransmission r large delays when congested r maximum achievable throughput unlimited shared output link buffers Host A in : original data Host B out Transport Layer Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data Transport Layer Causes/costs of congestion: scenario 3 r four senders r multihop paths r timeout/retransmit in Q: what happens as and increase ? in finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data Transport Layer 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 Two broad approaches towards congestion control: Transport Layer TCP congestion control: additive increase, multiplicative decrease r Approach: increase transmission rate (window size), probing for usable bandwidth, until loss occurs m additive increase: increase CongWin by 1 MSS every RTT until loss detected m multiplicative decrease: cut CongWin in half after loss time congestion window size Saw tooth behavior: probing for bandwidth Transport Layer TCP Congestion Control: details r sender limits transmission: LastByteSent-LastByteAcked CongWin r Roughly, CongWin is dynamic, function of perceived network congestion How does sender perceive congestion? r loss event = timeout or 3 duplicate acks TCP sender reduces rate ( CongWin ) after loss event three mechanisms: m AIMD m slow start m conservative after timeout events rate = CongWin RTT Bytes/sec Transport Layer Summary r principles behind transport layer services: m multiplexing, demultiplexing m reliable data transfer m flow control m congestion control r instantiation and implementation in the Internet m UDP m TCP 2: Application Layer 178 Application Layer Our goals: r conceptual, implementation aspects of network application protocols m transport-layer service models m client-server paradigm m peer-to-peer paradigm r learn about protocols by examining popular application-level protocols m HTTP m FTP m SMTP / POP3 / IMAP m DNS 2: Application Layer 179 Some network apps rr web r instant messaging r remote login r P2P file sharing r multi-user network games r streaming stored video clips r voice over IP r real-time video conferencing r grid computing 2: Application Layer 180 Creating a network app write programs that m run on (different) end systems m communicate over network m e.g., web server software communicates with browser software No need to write software for network-core devices m Network-core devices do not run user applications m applications on end systems allows for rapid app development, propagation application transport network data link physical application transport network data link physical application transport network data link physical 2: Application Layer 181 Application architectures r Client-server r Peer-to-peer (P2P) r Hybrid of client-server and P2P 2: Application Layer182 Client-server architecture server: m always-on host m permanent IP address m server farms for scaling clients: m communicate with server m may be intermittently connected m may have dynamic IP addresses m do not communicate directly with each other client/server 2: Application Layer183 Pure P2P architecture r no always-on server r arbitrary end systems directly communicate r peers are intermittently connected and change IP addresses Highly scalable but difficult to manage peer-peer 2: Application Layer 184 Hybrid of client-server and P2P Skype m voice-over-IP P2P application m centralized server: finding address of remote party: m client-client connection: direct (not through server) Instant messaging m chatting between two users is P2P m centralized service: client presence detection/location user registers its IP address with central server when it comes online user contacts central server to find IP addresses of buddies 2: Application Layer 185 Processes communicating Process: program running within a host. r within same host, two processes communicate using inter-process communication (defined by OS). r processes in different hosts communicate by exchanging messages Client process: process that initiates communication Server process: process that waits to be contacted rNote: applications with P2P architectures have client processes & server processes 2: Application Layer186 Sockets r process sends/receives messages to/from its socket r socket analogous to door m sending process shoves message out door m sending process relies on transport infrastructure on other side of door which brings message to socket at receiving process process TCP with buffers, variables socket host or server process TCP with buffers, variables socket host or server Internet controlled by OS controlled by app developer rAPI: (1) choice of transport protocol; (2) ability to fix a few parameters (lots more on this later) 2: Application Layer 187 Addressing processes r to receive messages, process must have identifier r host device has unique 32-bit IP address r Q: does IP address of host suffice for identifying the process? 2: Application Layer 188 Addressing processes r to receive messages, process must have identifier r host device has unique 32-bit IP address r Q: does IP address of host on which process runs suffice for identifying the process? m A: No, many processes can be running on same host r identifier includes both IP address and port numbers associated with process on host. r Example port numbers: m HTTP server: 80 m Mail server: 25 r to send HTTP message to gaia.cs.umass.edu web server: m IP address: m Port number: 80 r more shortly 2: Application Layer 189 App-layer protocol defines r Types of messages exchanged, m e.g., request, response r Message syntax: m what fields in messages & how fields are delineated r Message semantics m meaning of information in fields r Rules for when and how processes send & respond to messages Public-domain protocols: r defined in RFCs r allows for interoperability r e.g., HTTP, SMTP Proprietary protocols: r e.g., Skype 2: Application Layer 190 Web and HTTP First some jargon r Web page consists of objects r Object can be HTML file, JPEG image, Java applet, audio file, r Web page consists of base HTML-file which includes several referenced objects r Each object is addressable by a URL r Example URL:host name path name 2: Application Layer 191 HTTP overview HTTP: hypertext transfer protocol r Webs application layer protocol r client/server model m client: browser that requests, receives, displays Web objects m server: Web server sends objects in response to requests PC running Explorer Server running Apache Web server Mac running Navigator HTTP request HTTP response 2: Application Layer 192 HTTP overview (continued) Uses TCP: r client initiates TCP connection (creates socket) to server, port 80 r server accepts TCP connection from client r HTTP messages (application- layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server) r TCP connection closed HTTP is stateless r server maintains no information about past client requests Protocols that maintain state are complex! rpast history (state) must be maintained rif server/client crashes, their views of state may be inconsistent, must be reconciled aside 2: Application Layer 193 HTTP connections Nonpersistent HTTP r At most one object is sent over a TCP connection. Persistent HTTP r Multiple objects can be sent over single TCP connection between client and server. 2: Application Layer 194 Web caches (proxy server) r user sets browser: Web accesses via cache r browser sends all HTTP requests to cache m object in cache: cache returns object m else cache requests object from origin server, then returns object to client Goal: satisfy client request without involving origin server client Proxy server client HTTP request HTTP response HTTP request origin server origin server HTTP response 2: Application Layer 195 More about Web caching r cache acts as both client and server r typically cache is installed by ISP (university, company, residential ISP) Why Web caching? r reduce response time for client request r reduce traffic on an institutions access link. r Internet dense with caches: enables poor content providers to effectively deliver content (but so does P2P file sharing) 2: Application Layer 196 FTP: the file transfer protocol r transfer file to/from remote host r client/server model m client: side that initiates transfer (either to/from remote) m server: remote host r ftp: RFC 959 r ftp server: port 21 file transfer FTP server FTP user interface FTP client local file system remote file system user at host 2: Application Layer 197 FTP: separate control, data connections r FTP client contacts FTP server at port 21, TCP is transport protocol r client authorized over control connection r client browses remote directory by sending commands over control connection. r when server receives file transfer command, server opens 2 nd TCP connection (for file) to client r after transferring one file, server closes data connection. FTP client FTP server TCP control connection port 21 TCP data connection port 20 rserver opens another TCP data connection to transfer another file. rcontrol connection: out of band rFTP server maintains state: current directory, earlier authentication 2: Application Layer 198 Electronic Mail Three major components: r user agents r mail servers r simple mail transfer protocol: SMTP User Agent r a.k.a. mail reader r composing, editing, reading mail messages r e.g., Eudora, Outlook, elm, Mozilla Thunderbird r outgoing, incoming messages stored on server user mailbox outgoing message queue mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP 2: Application Layer 199 Electronic Mail: mail servers Mail Servers r mailbox contains incoming messages for user r message queue of outgoing (to be sent) mail messages r SMTP protocol between mail servers to sendmessages m client: sending mail server m server: receiving mail server mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP 2: Application Layer 200 Electronic Mail: SMTP [RFC 2821] r uses TCP to reliably transfermessage from client to server, port 25 r direct transfer: sending server to receiving server r three phases of transfer m handshaking (greeting) m transfer of messages m closure r command/response interaction m commands: ASCII text m response: status code and phrase r messages must be in 7-bit ASCII 2: Application Layer 201 Mail access protocols r SMTP: delivery/storage to receivers server r Mail access protocol: retrieval from server m POP: Post Office Protocol [RFC 1939] authorization (agent server) and download m IMAP: Internet Mail Access Protocol [RFC 1730] more features (more complex) manipulation of stored msgs on server m HTTP: gmail, Hotmail, Yahoo! Mail, etc. user agent senders mail server user agent SMTP access protocol receivers mail server 2: Application Layer 202 DNS: Domain Name System People: many identifiers: m SSN, name, passport # Internet hosts, routers: m IP address (32 bit) - used for addressing datagrams m name, e.g., ww.yahoo.com - used by humans Q: map between IP addresses and name ? Domain Name System: r distributed database implemented in hierarchy of many name servers r application-layer protocol host, routers, name servers to communicate to resolve names (address/name translation) m note: core Internet function, implemented as application-layer protocol m complexity at networks edge 2: Application Layer 203 DNS Why not centralize DNS? r single point of failure r traffic volume r distant centralized database r maintenance doesnt scale! DNS services r hostname to IP address translation r host aliasing m Canonical, alias names r mail server aliasing r load distribution m replicated Web servers: set of IP addresses for one canonical name 2: Application Layer204 Root DNS Servers com DNS servers org DNS serversedu DNS servers poly.edu DNS servers umass.edu DNS servers yahoo.com DNS servers amazon.com DNS servers pbs.org DNS servers Distributed, Hierarchical Database Client wants IP for1 st approx: r client queries a root server to find com DNS server r client queries com DNS server to get amazon.com DNS server r client queries amazon.com DNS server to get IP address for 2: Application Layer 205 DNS: Root name servers r contacted by local name server that can not resolve name r root name server: m contacts authoritative name server if name mapping not known m gets mapping m returns mapping to local name server 13 root name servers worldwide b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) i Autonomica, Stockholm (plus 28 other locations) k RIPE London (also 16 other locations) m WIDE Tokyo (also Seoul, Paris, SF) a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) 2: Application Layer 206 TLD and Authoritative Servers r Top-level domain (TLD) servers: m responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp. m Network Solutions maintains servers for com TLD m Educause for edu TLD r Authoritative DNS servers: m organizations DNS servers, providing authoritative hostname to IP mappings for organizations servers (e.g., Web, mail). m can be maintained by organization or service provider 2: Application Layer 207 Local Name Server r does not strictly belong to hierarchy r each ISP (residential ISP, company, university) has one. m also called default name server r when host makes DNS query, query is sent to its local DNS server m acts as proxy, forwards query into hierarchy 2: Application Layer 208 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server DNS name resolution example r Host at cis.poly.edu wants IP address for gaia.cs.umass.edu iterated query: rcontacted server replies with name of server to contact rI dont know this name, but ask this server 2: Application Layer 209 requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server 3 recursive query: rputs burden of name resolution on contacted name server rheavy load? DNS name resolution example 2: Application Layer 210 DNS: caching and updating records r once (any) name server learns mapping, it caches mapping m cache entries timeout (disappear) after some time m TLD servers typically cached in local name servers Thus root name servers not often visited r update/notify mechanisms under design by IETF m RFC 2136 m Network Management What is network management? r autonomous systems (aka network): 100s or 1000s of interacting hardware/software components r other complex systems requiring monitoring, control: m jet airplane m nuclear power plant m others? "Network management includes the deployment, integration and coordination of the hardware, software, and human elements to monitor, test, poll, configure, analyze, evaluate, and control the network and element resources to meet the real-time, operational performance, and Quality of Service requirements at a reasonable cost." Network Management Infrastructure for network management agent data agent data agent data agent data managed device managing entity data network management protocol definitions: managed devices contain managed objects whose data is gathered into a Management Information Base (MIB) managing entity Network Management Network Management standards OSI CMIP r Common Management Information Protocol r designed 1980s: the unifying net management standard r too slowly standardized SNMP: Simple Network Management Protocol r Internet roots (SGMP) r started simple r deployed, adopted rapidly r growth: size, complexity r currently: SNMP V3 r de facto network management standard Network Management SNMP overview: 4 key parts r Management information base (MIB): m distributed information store of network management data r Structure of Management Information (SMI): m data definition language for MIB objects r SNMP protocol m convey manager managed object info, commands r security, administration capabilities m major addition in SNMPv3 References r Top down Networking : Ross & Kurose r Computer Networks : Tannenbaum r Data & Computer Networks : Stallings r Computer Networks: Forouzon r TCP/IP Protocols: Forouzon Transport Layer 3-215 Thank you..!!! (But Network isnt over yet..)