Download CS422: Intro to Network Class Review

CS422: INTRO TO
NETWORK
CLASS REVIEW
BY CHRISTOPHER I. G. LANCLOS
OUTLINE
• Chapter One
• Chapter Two
• Chapter Three
• Chapter Four
• Chapter Five
• Chapter Eight
• Announcements
CHAPTER ONE
Computer Networks and the Internet
INTERNET VIEW POINTS
• Nuts and Bolts View (Physical)
• Millions of connected computing devices:
• Host = end systems
• Running network applications
• Communication Links
• Fiber, copper, radio, satellite, transmission rate (bandwidth)
• Packet switches:
• Forward packets
• Routers and switches
INTERNET VIEW POINTS
• Nuts and Bolts View (Non-physical Components)
• A Network of Network
• Interconnected ISPs
• Protocols
• Control sending, receiving of messages
• TCP, IP, HTTP, Skype, 802.11
• Define format, order of messages sent and received among network entities, and actions taken on messages
transmission, receipt
• Internet standards
• RFC: Request for comments
• IETF: Internet Engineering Task Force
INTERNET VIEW POINTS
• A Service view
• Infrastructure that provides services to applications:
• Web,VoIP, email, games, e-commerce, social nets, …
• provides programming interface to apps
• hooks that allow sending and receiving app programs to “connect” to Internet
• provides service options, analogous to postal service
NETWORK STRUCTURE
• Network Edge
• Hosts: clients and servers
• Servers often in data centers
• Access Networks, Physical Media
• Wired, wireless communication links
• Network Core
• Interconnected routers
• Network of networks
ACCESS NETWORKS
• How to connect end systems to edge
router?
• residential access nets
• institutional access networks (school,
company)
• mobile access networks
• keep in mind:
• bandwidth (bits per second) of access
network?
• shared or dedicated?
• Access Networks:
•
•
•
•
DSL (Digital Subscriber Line)
Cable Network
Ethernet
Wireless
PHYSICAL MEDIA
• Physical Media
• bit: propagates between transmitter/receiver pairs
• physical link: what lies between transmitter & receiver
• guided media: signals propagate in solid media
• Fiber & Coax
• unguided media: signals propagate freely
• Radio (includes Wi-Fi, cellular and satellite)
NETWORK CORE
• Mesh of interconnected routers
• Packet-switching: hosts break application-layer messages into packets
• forward packets from one router to the next, across links on path from source to destination
• each packet transmitted at full link capacity
• store and forward: entire packet must arrive at router before it can be transmitted on next link
• Key Functions of Network Core
• routing: determines source-destination route taken by packets: routing algorithms
• forwarding: move packets from router’s input to appropriate router output
NETWORK CORE (ALTERNATIVE)
• Circuit Switching end-end resources allocated to, reserved for “call” between source &
destination:
• dedicated resources: no sharing
• circuit-like (guaranteed) performance
• circuit segment idle if not used by call (no sharing)
• Commonly used in traditional telephone networks
CIRCUIT SWITCHING: FDM VERSUS TDM
PACKET SWITCHING & CIRCUIT SWITCHING
• Packet switching allows more users to use network!
• Packet switching
• great for burst of data
• resource sharing
• simpler, no call setup
• excessive congestion possible: packet delay and loss
• protocols needed for reliable data transfer, congestion control
INTERNET STRUCTURE: NETWORK OF NETWORK
FOUR SOURCES OF PACKET DELAY
• dnodal = dproc + dqueue + dtrans + dprop
• dproc: nodal processing
• check bit errors
• determine output link
• typically < msec
• dqueue: queueing delay
• time waiting at output link for transmission
• depends on congestion level of router
FOUR SOURCES OF PACKET DELAY CONT.
• dnodal = dproc + dqueue + dtrans + dprop
• dtrans: transmission delay:
• L: packet length (bits)
• R: link bandwidth (bps)
• dtrans = L/R
• dprop: propagation delay:
• d: length of physical link
• s: propagation speed in medium (~2x108 m/sec)
• dprop = d/s
PACKET LOSS & THROUGHPUT
• Packet Loss
•
Queue (aka buffer) preceding link in buffer has finite capacity
•
Packet arriving to full queue dropped (aka lost)
•
Lost packet may be retransmitted by previous node, by source end system, or not at all
• Throughput rate (bits/time unit) at which bits transferred between sender/receiver
• instantaneous: rate at given point in time
• average: rate over longer period of time
• Bottleneck: link on end-end path that constrains end-end throughput
PROTOCOL LAYERS, SERVICE MODELS
• Application: supporting network applications
• FTP, SMTP, HTTP
• Transport: process-process data transfer
• TCP, UDP
• Network: routing of datagrams from source to destination
• IP, routing protocols
• Link: data transfer between neighboring network elements
• Ethernet, 802.111 (Wi-Fi), PPP
• Physical: bits “on the wire”
NETWORK SECURITY
• Field of network security:
• how bad guys can attack computer networks
• how we can defend networks against attacks
• how to design architectures that are immune to attacks
• Malware can get in host from:
• virus: self-replicating infection by receiving/executing object (e.g., e-mail attachment)
• worm: self-replicating infection by passively receiving object that gets itself executed
• Spyware malware can record keystrokes, web sites visited, upload info to collection site
• Infected host can be enrolled in botnet, used for spam. DDoS attacks, Packet Sniffing, IP spoofing
CHAPTER TWO
Application Layer
CLIENT-SERVER ARCHITECTURE
• Server:
• Always-on host
• Permanent IP address
• Data centers for scaling
• Clients:
• Communicate with server
• May be intermittently connected
• May have dynamic IP addresses
• Do not communicate directly with each other
P2P ARCHITECTURE
• No always-on server
• Arbitrary end systems directly communicate
• Peers request service from other peers, provide service in return to other peers
• Self scalability – new peers bring new service capacity, as well as new service demands
• Peers are intermittently connected and change IP addresses
• Complex management
PROCESSES COMMUNICATING
• process: program running within a host
• within same host, two processes communicate using inter-process communication (defined by
OS)
• processes in different hosts communicate by exchanging messages
• client process: process that initiates communication
• server process: process that waits to be contacted
• Applications with P2P architectures have client processes & server processes
SOCKETS
• Process sends/receives messages to/from its socket
• Socket analogous to door
• Sending process shoves message out door
• Sending process relies on transport infrastructure on other side of door to deliver message to
socket at receiving process
APP-LAYER PROTOCOL DEFINES
• Types of messages exchanged,
• e.g., request, response
• Message syntax:
• what fields in messages & how fields are
delineated
• Nessage semantics
• meaning of information in fields
• Rules for when and how processes send
& respond to messages
• Open protocols:
• defined in RFCs
• allows for interoperability
• e.g., HTTP, SMTP
• Proprietary protocols:
• e.g., Skype
TRANSPORT SERVICES
• data integrity
• some apps (e.g., file transfer, web transactions) require 100% reliable data transfer
• other apps (e.g., audio) can tolerate some loss
• timing
• some apps (e.g., Internet telephony, interactive games) require low delay to be “effective”
• throughput
• some apps (e.g., multimedia) require minimum amount of throughput to be “effective”
• other apps (“elastic apps”) make use of whatever throughput they get
• security
• encryption, data integrity, …
INTERNET TRANSPORT PROTOCOLS SERVICES
• TCP service:
• reliable transport between sending and
receiving process
• flow control: sender won’t overwhelm
receiver
• congestion control: throttle sender when
network overloaded
• does not provide: timing, minimum
throughput guarantee, security
• connection-oriented: setup required
between client and server processes
• UDP service:
• unreliable data transfer between sending
and receiving process
• does not provide: reliability, flow control,
congestion control, timing, throughput
guarantee, security, or connection setup,
SECURING TCP
• TCP & UDP
• no encryption
• clear text passwords sent into socket traverse Internet in clear text
• SSL
• provides encrypted TCP connection
• data integrity
• end-point authentication
• SSL is at app layer
• Apps use SSL libraries, which “talk” to TCP
• SSL socket API
• Clear text passwords sent into socket traverse Internet encrypted
COOKIES
• cookies and privacy:
• cookies permit sites to learn a lot about you
• you may supply name and e-mail to sites
• what cookies can be used for:
• authorization
• shopping carts
• recommendations
• user session state (Web e-mail)
• how to keep “state”:
• protocol endpoints: maintain state at sender/receiver over multiple transactions
• cookies: http messages carry state
WEB CACHES (PROXY SERVER)
•
Goal: satisfy client request without involving origin server
•
User sets browser: Web accesses via cache
•
Browser sends all HTTP requests to cache
•
Object in cache: cache returns object
•
Else cache requests object from origin server, then returns object to client
•
cache acts as both client and server
•
•
•
server for original requesting client
•
client to origin server
typically cache is installed by ISP (university, company, residential ISP)
Why Web caching?
•
reduce response time for client request
•
reduce traffic on an institution’s access link
•
Internet dense with caches: enables “poor” content providers to effectively deliver content (so too does P2P file sharing)
DNS: DOMAIN NAME SYSTEM
• Internet hosts, routers:
• IP address (32 bit) - used for addressing datagrams
• “name”, e.g., www.yahoo.com - used by humans
• Distributed database implemented in hierarchy of many name servers
• Application-layer protocol: hosts, name servers communicate to resolve names
(address/name translation)
• Note: core Internet function, implemented as application-layer protocol
• Complexity at network’s “edge”
DNS: SERVICES, STRUCTURE
• DNS services
• hostname to IP address translation
• host aliasing
•
canonical, alias names
• mail server aliasing
• load distribution
•
replicated Web servers: many IP addresses correspond to one name
• Why not centralize DNS? Doesn’t Scale
• single point of failure
• traffic volume
• distant centralized database
• maintenance
DNS: ROOT NAME SERVERS
• Contacted by local name server that can not resolve name
• Root name server:
• Contacts authoritative name server if name mapping not known
• Gets mapping
• Returns mapping to local name server
TLD, AUTHORITATIVE SERVERS
• top-level domain (TLD) servers:
• responsible for com, org, net, edu, aero, jobs, museums, and all top-level country domains, e.g.:
uk, fr, ca, jp
• Network Solutions maintains servers for .com TLD
• Education for .edu TLD
• authoritative DNS servers:
• organization’s own DNS server(s), providing authoritative hostname to IP mappings for
organization’s named hosts
• can be maintained by organization or service provider
LOCAL DNS NAME SERVER
• Does not strictly belong to hierarchy
• Each ISP (residential ISP, company, university) has one
• Also called “default name server”
• When host makes DNS query, query is sent to its local DNS server
• Has local cache of recent name-to-address translation pairs (but may be out of date!)
• Acts as proxy, forwards query into hierarchy
DNS NAME RESOLUTION EXAMPLE
• Iterated query:
• Contacted server replies with name of server to contact
• “I don’t know this name, but ask this server”
• Recursive query:
• Puts burden of name resolution on contacted name server
• Heavy load at upper levels of hierarchy?
ATTACKING DNS
• DDoS attacks
• Bombard root servers with traffic
• Not successful to date
• Traffic Filtering
• Local DNS servers cache IPs of TLD
servers, allowing root server bypass
• Bombard TLD servers
• Potentially more dangerous
• Redirect attacks
• Man-in-middle
• Intercept queries
• DNS poisoning
• Send bogus relies to DNS server, which
caches
• Exploit DNS for DDoS
• Send queries with spoofed source address:
target IP
• Requires amplification
PURE P2P ARCHITECTURE
• no always-on server
• arbitrary end systems directly communicate
• peers are intermittently connected and change IP addresses
• examples:
• file distribution (BitTorrent)
• Streaming (KanKan)
• VoIP (Skype)
DISTRIBUTED HASH TABLE (DHT)
• DHT: a distributed P2P database
• database has (key, value) pairs; examples:
• key: movie title; value: IP address
• Distribute the (key, value) pairs over the (millions of peers)
• a peer queries DHT with key
• DHT returns values that match the key
• peers can also insert (key, value) pairs
CHAPTER THREE
Transport Layer
TRANSPORT SERVICES AND PROTOCOLS
• Provide logical communication between app processes running on different hosts
• Transport protocols run in end systems
• Send side: breaks app messages into segments, passes to network layer
• Receiver side: reassembles segments into messages, passes to app layer
• More than one transport protocol available to apps
• Internet: TCP and UDP
TRANSPORT VS. NETWORK LAYER
• Network layer: logical communication between hosts
• Transport layer: logical communication between processes
• Relies on, enhances, network layer services
INTERNET TRANSPORT-LAYER PROTOCOLS
• Reliable, in-order delivery (TCP)
• congestion control
• flow control
• connection setup
• Unreliable, unordered delivery: UDP
• no-frills extension of “best-effort” IP
• Services not available:
• delay guarantees
• bandwidth guarantees
MULTIPLEXING & DEMULTIPLEXING
• Multiplexing
• Handle data from multiple sockets, add transport header (later used for demultiplexing)
• Demultiplexing
• use header info to deliver received segments to correct socket
HOW DEMULTIPLEXING WORKS
• Host receives IP datagrams
• each datagram has source IP address, destination IP address
• each datagram carries one transport-layer segment
• each segment has source, destination port number
• Host uses IP addresses & port numbers to direct segment to appropriate socket
CONNECTION-ORIENTED VS. CONNECTIONLESS
DEMUX
• TCP socket identified by 4-tuple:
• source IP address
• source port number
• dest IP address
• dest port number
• demux: receiver uses all four values to direct segment to appropriate socket
• when host receives UDP segment:
• checks destination port # in segment
• directs UDP segment to socket with that port #
• IP datagrams with same dest. port #, but different source IP addresses and/or source port numbers will be
directed to same socket at des
UDP: USER DATAGRAM PROTOCOL [RFC 768]
• connectionless:
• no handshaking between UDP sender, receiver
• each UDP segment handled independently of others
• UDP use:
• streaming multimedia apps (loss tolerant, rate sensitive)
• DNS
• SNMP
• reliable transfer over UDP:
• add reliability at application layer
• application-specific error recovery!
UDP: SEGMENT HEADER
• Why is there a UDP?
• no connection establishment (which can
add delay)
• simple: no connection state at sender,
receiver
• small header size
• no congestion control: UDP can blast
away as fast as desired
UDP CHECKSUM
• Goal: detect “errors” (e.g., flipped bits) in transmitted segment
• sender:
• treat segment contents, including header fields, as sequence of 16-bit integers
• checksum: addition (one’s complement sum) of segment contents
• sender puts checksum value into UDP checksum field
• receiver:
• compute checksum of received segment
• check if computed checksum equals checksum field value:
• NO - error detected
• YES - no error detected. But maybe errors nonetheless? More later ….
PIPELINED PROTOCOLS
• pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts
• range of sequence numbers must be increased
• buffering at sender and/or receiver
• two generic forms of pipelined protocols: go-Back-N, selective repeat
PIPELINED PROTOCOLS: OVERVIEW
• Go-back-N:
• sender can have up to N unacked packets in pipeline
• receiver only sends cumulative ack
• doesn’t ack packet if there’s a gap
• sender has timer for oldest unacked packet
• when timer expires, retransmit all unacked packets
• Selective Repeat:
• sender can have up to N unack’ed packets in pipeline
• rcvr sends individual ack for each packet
• sender maintains timer for each unacked packet
• when timer expires, retransmit only that unacked packet
TCP: OVERVIEW RFCS: 793,1122,1323, 2018, 2581
•
point-to-point:
•
•
reliable, in-order byte steam:
•
•
•
TCP congestion and flow control set window size
full duplex data:
•
bi-directional data flow in same connection
•
MSS: maximum segment size
connection-oriented:
•
•
no “message boundaries”
pipelined:
•
•
one sender, one receiver
handshaking (exchange of control msgs) inits sender, receiver state
before data exchange
flow controlled:
•
sender will not overwhelm receiver
TCP SEQ. & ACK.
• Sequence numbers:
• byte stream “number” of first byte in segment’s data
• Acknowledgements:
• seq # of next byte expected from other side
• cumulative ACK
• How receiver handles out-of-order segments
• TCP spec doesn’t say, - up to implementer
TCP RELIABLE DATA TRANSFER
• TCP creates rdt service on top of IP’s unreliable service
• pipelined segments
• cumulative acks
• single retransmission timer
• retransmissions triggered by:
• timeout events
• duplicate acks
TCP FLOW CONTROL
• receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too
much, too fast
• receiver “advertises” free buffer space by including rwnd value in TCP header of receiverto-sender segments
• RcvBuffer size set via socket options (typical default is 4096 bytes)
• many operating systems autoadjust RcvBuffer
• sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
• guarantees receive buffer will not overflow
CONNECTION MANAGEMENT
• Before exchanging data, sender/receiver “handshake”:
• Agree to establish connection (each knowing the other willing to establish connection)
• Agree on connection parameters
• TCP: closing a connection
• client, server each close their side of connection
• send TCP segment with FIN bit = 1
• respond to received FIN with ACK
• on receiving FIN, ACK can be combined with own FIN
• simultaneous FIN exchanges can be handled
PRINCIPLES OF CONGESTION CONTROL
• congestion:
• informally: “too many sources sending too much data too fast for network to handle”
• different from flow control!
• manifestations:
• lost packets (buffer overflow at routers)
• long delays (queueing in router buffers)
• a top-10 problem!
APPROACHES TOWARDS CONGESTION CONTROL
• two broad approaches towards congestion control:
• end-end congestion control:
• no explicit feedback from network
• congestion inferred from end-system observed loss, delay
• approach taken by TCP
• network-assisted congestion control:
• routers provide feedback to end systems
• single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM)
• explicit rate for sender to send at
CHAPTER FOUR
Network Layer
NETWORK LAYER
• transport segment from sending to receiving host
• on sending side encapsulates segments into datagrams
• on receiving side, delivers segments to transport layer
• network layer protocols in every host, router
• router examines header fields in all IP datagrams passing through it
TWO KEY NETWORK-LAYER FUNCTIONS
• forwarding: move packets from router’s input to appropriate router output
• routing: determine route taken by packets from source to dest.
• routing algorithms
• analogy:
• routing: process of planning trip from source to dest
• forwarding: process of getting through single interchange
CONNECTION SETUP
• 3rd important function in some network architectures:
• ATM, frame relay, X.25
• before datagrams flow, two end hosts and intervening routers establish virtual
connection
• routers get involved
• network vs transport layer connection service:
• network: between two hosts (may also involve intervening routers in case of VCs)
• transport: between two processes
NETWORK SERVICE MODEL
• Network layer service models:
CONNECTION, CONNECTION-LESS SERVICE
• datagram network provides network-layer connectionless service
• virtual-circuit network provides network-layer connection service
• analogous to TCP/UDP connection-oriented/connectionless transportlayer services, but:
• service: host-to-host
• no choice: network provides one or the other
• implementation: in network core
DATAGRAM OR VC NETWORK: WHY?
• Internet (datagram)
• data exchange among computers
• “elastic” service, no strict timing req.
• many link types
• different characteristics
• uniform service difficult
• “smart” end systems (computers)
• can adapt, perform control, error recovery
• simple inside network, complexity at
“edge”
• ATM (VC)
• evolved from telephony
• human conversation:
• strict timing, reliability requirements
• need for guaranteed service
• “dumb” end systems
• telephones
• complexity inside network
ROUTER ARCHITECTURE OVERVIEW
• two key router functions:
• run routing algorithms/protocol (RIP, OSPF, BGP)
• forwarding datagrams from incoming to outgoing link
• transfer packet from input buffer to appropriate output buffer
• switching rate: rate at which packets can be transfer from inputs to outputs
• often measured as multiple of input/output line rate
• N inputs: switching rate N times line rate desirable
• three types of switching fabrics: Memory, bus, crossbar
IP DATAGRAM FORMAT
IP FRAGMENTATION, REASSEMBLY
• network links have MTU (max.transfer size) - largest possible link-level frame
• different link types, different MTUs
• large IP datagram divided (“fragmented”) within net
• one datagram becomes several datagrams
• “reassembled” only at final destination
• IP header bits used to identify, order related fragments
IP ADDRESSING: INTRODUCTION
• IP address: 32-bit identifier for host, router interface
• interface: connection between host/router and physical link
• router’s typically have multiple interfaces
• host typically has one or two interfaces (e.g., wired Ethernet, wireless 802.11)
• IP addresses associated with each interface
223.1.1.1 = 11011111 00000001 00000001 00000001
223
1
1
1
SUBNETS
• IP address:
• subnet part - high order bits
• host part - low order bits
• what’s a subnet ?
• device interfaces with same subnet part of IP address
• can physically reach each other without intervening router
• recipe
• to determine the subnets, detach each interface from its host or router, creating islands of isolated
networks
• each isolated network is called a subnet
IP ADDRESSING: CIDR
• CIDR: Classless InterDomain Routing
• subnet portion of address of arbitrary length
• address format: a.b.c.d/x, where x is # bits in subnet portion of address
IP ADDRESSES: HOW TO GET ONE?
• Q: How does a host get IP address?
• hard-coded by system admin in a file
• Windows: control-panel->network->configuration->tcp/ip->properties
• UNIX: /etc/rc.config
• DHCP: Dynamic Host Configuration Protocol: dynamically get address from as server
• “plug-and-play”
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/“on”)
• support for mobile users who want to join network (more shortly)
• DHCP overview:
•
•
•
•
host broadcasts “DHCP discover” msg [optional]
DHCP server responds with “DHCP offer” msg [optional]
host requests IP address: “DHCP request” msg
DHCP server sends address: “DHCP ack” msg
DHCP: MORE THAN IP ADDRESSES
• DHCP can return more than just allocated IP address on subnet:
• address of first-hop router for client
• name and IP address of DNS sever
• network mask (indicating network versus host portion of address)
IP ADDRESSES: HOW TO GET ONE?
• how does network get subnet part of IP addr?
• gets allocated portion of its provider ISP’s address space
HIERARCHICAL ADDRESSING: ROUTE
AGGREGATION
• hierarchical addressing allows efficient advertisement of routing information:
ICMP: INTERNET CONTROL MESSAGE PROTOCOL
• used by hosts & routers to communicate network-level information
• error reporting: unreachable host, network, port, protocol
• echo request/reply (used by ping)
• network-layer “above” IP:
• ICMP msgs carried in IP datagrams
• ICMP message: type, code plus first 8 bytes of IP datagram causing error
ROUTING ALGORITHM CLASSIFICATION
• Q: global or decentralized information?
• global:
• all routers have complete topology, link cost info
• “link state” algorithms
• decentralized:
• router knows physically-connected neighbors, link costs to neighbors
• iterative process of computation, exchange of info with neighbors
• “distance vector” algorithms
ROUTING ALGORITHM CLASSIFICATION
• Q: static or dynamic?
• static:
• routes change slowly over time
• dynamic:
• routes change more quickly
• periodic update
• in response to link cost changes
ROUTING
• routing algorithms
• link state
• distance vector
• hierarchical routing
• routing in the Internet
• RIP
• OSPF
• BGP
CHAPTER FIVE
The Link Layer: Links, Access Networks, and LANs
LINK LAYER: INTRODUCTION
• terminology:
• hosts and routers: nodes
• communication channels that connect adjacent nodes along communication path: links
• wired links
• wireless links
• LANs
• layer-2 packet: frame, encapsulates datagram
• data-link layer has responsibility of transferring datagram from one node to physically adjacent
node over a link
LINK LAYER: CONTEXT
• datagram transferred by different link protocols over different links:
• e.g., Ethernet on first link, frame relay on intermediate links, 802.11 on last link
• each link protocol provides different services
• e.g., may or may not provide rdt over link
LINK LAYER SERVICES
• framing, link access:
• encapsulate datagram into frame, adding header, trailer
• channel access if shared medium
• “MAC” addresses used in frame headers to identify source, dest
• different from IP address!
• reliable delivery between adjacent nodes
• we learned how to do this already (chapter 3)!
• seldom used on low bit-error link (fiber, some twisted pair)
• wireless links: high error rates
• Q: why both link-level and end-end reliability?
LINK LAYER SERVICES
• flow control:
• pacing between adjacent sending and receiving nodes
• error detection:
• errors caused by signal attenuation, noise.
• receiver detects presence of errors:
• signals sender for retransmission or drops frame
• error correction:
• receiver identifies and corrects bit error(s) without resorting to retransmission
• half-duplex and full-duplex
• with half duplex, nodes at both ends of link can transmit, but not at same time
MULTIPLE ACCESS LINKS, PROTOCOLS
• two types of “links”:
• point-to-point
• PPP for dial-up access
• point-to-point link between Ethernet switch, host
• broadcast (shared wire or medium)
• old-fashioned Ethernet
• upstream HFC
• 802.11 wireless LAN
MULTIPLE ACCESS PROTOCOLS
• single shared broadcast channel
• two or more simultaneous transmissions by nodes: interference
• collision if node receives two or more signals at the same time
• multiple access protocol
• distributed algorithm that determines how nodes share channel, i.e., determine when node
can transmit
• communication about channel sharing must use channel itself!
• no out-of-band channel for coordination
SUMMARY OF MAC PROTOCOLS
• channel partitioning, by time, frequency or code
• Time Division, Frequency Division
• random access (dynamic),
• ALOHA, S-ALOHA, CSMA, CSMA/CD
• carrier sensing: easy in some technologies (wire), hard in others (wireless)
• CSMA/CD used in Ethernet
• CSMA/CA used in 802.11
• taking turns
• polling from central site, token passing
• Bluetooth, FDDI, token ring
A DAY IN THE LIFE: SCENARIO
5-89
DNS server
browser
Comcast network
68.80.0.0/13
school network
68.80.2.0/24
web page
web server
64.233.169.105
Google’s network
64.233.160.0/19
Link Layer
A DAY IN THE LIFE… CONNECTING TO
THE INTERNET
Link Layer
5-90
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP
connecting laptop needs to get its
own IP address, addr of first-hop
router, addr of DNS server: use
DHCP
DHCP

DHCP
DHCP
DHCP
DHCP
DHCP
UDP
IP
Eth
Phy
router
(runs DHCP)


DHCP request encapsulated
in UDP, encapsulated in IP,
encapsulated in 802.3
Ethernet
Ethernet frame broadcast
(dest: FFFFFFFFFFFF) on LAN,
received at router running
DHCP server
Ethernet demuxed to IP
demuxed, UDP demuxed to
DHCP
A DAY IN THE LIFE… CONNECTING TO
THE INTERNET
Link Layer
5-91
• DHCP server formulates
DHCP ACK containing client’s
IP address, IP address of firsthop router for client, name &
IP address of DNS server
DHCP
UDP
IP
Eth
Phy
DHCP
DHCP
DHCP
DHCP

DHCP
DHCP
DHCP
DHCP
DHCP
DHCP
UDP
IP
Eth
Phy
router
(runs DHCP)

encapsulation at DHCP
server, frame forwarded
(switch learning) through
LAN, demultiplexing at
client
DHCP client receives
DHCP ACK reply
Client now has IP address, knows name & addr of DNS
server, IP address of its first-hop router
A DAY IN THE LIFE… ARP (BEFORE DNS, BEFORE
HTTP)
Link Layer
5-92
DNS
DNS
DNS
ARP query
before sending HTTP request, need IP
address of www.google.com: DNS
DNS
UDP
IP
ARP
Eth
Phy

ARP
ARP reply
Eth
Phy
router
(runs DHCP)


DNS query created, encapsulated in
UDP, encapsulated in IP,
encapsulated in Eth. To send frame
to router, need MAC address of
router interface: ARP
ARP query broadcast, received by
router, which replies with ARP
reply giving MAC address of
router interface
client now knows MAC address
of first hop router, so can now
send frame containing DNS
query
A DAY IN THE LIFE… USING DNS
Link Layer
DNS
5-93
DNS
DNS
DNS
DNS
DNS
DNS
UDP
IP
Eth
Phy
DNS
DNS
DNS
UDP
IP
Eth
Phy
DNS server
DNS
Comcast network
68.80.0.0/13
router
(runs DHCP)

IP datagram containing DNS
query forwarded via LAN
switch from client to 1st hop
router

IP datagram forwarded from
campus network into comcast
network, routed (tables created
by RIP, OSPF, IS-IS and/or BGP
routing protocols) to DNS server

demux’ed to DNS server
DNS server replies to client
with IP address of
www.google.com

A DAY IN THE LIFE…TCP CONNECTION CARRYING
HTTP
Link Layer
5-94
HTTP
HTTP
TCP
IP
Eth
Phy
SYNACK
SYN
SYNACK
SYN
SYNACK
SYN

router
(runs DHCP)
SYNACK
SYN
SYNACK
SYN
SYNACK
SYN
TCP
IP
Eth
Phy
web server
64.233.169.105



to send HTTP request,
client first opens TCP
socket to web server
TCP SYN segment (step 1 in 3way handshake) inter-domain
routed to web server
web server responds with TCP
SYNACK (step 2 in 3-way
handshake)
TCP connection established!
A DAY IN THE LIFE… HTTP REQUEST/REPLY
Link Layer
5-95
HTTP
HTTP
HTTP
TCP
IP
Eth
Phy
HTTP
HTTP
HTTP
HTTP
HTTP
HTTP

web page finally (!!!) displayed

HTTP
HTTP
HTTP
HTTP
HTTP
TCP
IP
Eth
Phy
web server
64.233.169.105
router
(runs DHCP)



HTTP request sent into
TCP socket
IP datagram containing HTTP
request routed to
www.google.com
web server responds with
HTTP reply (containing web
page)
IP datagram containing HTTP
reply routed back to client