5/23/05CS118/Spring051 Where we are in the big picture HTTP TCP IP Ethernet interface HTTP TCP IP...
-
Upload
dillon-rocks -
Category
Documents
-
view
224 -
download
1
Transcript of 5/23/05CS118/Spring051 Where we are in the big picture HTTP TCP IP Ethernet interface HTTP TCP IP...
5/23/05 CS118/Spring051
Where we are in the big picture
HTTP
TCP
IP
Ethernetinterface
HTTP
TCP
IP
Ethernetinterface
IP IP
Ethernetinterface
Ethernetinterface
SONETinterface
SONETinterface
host host
router router
HTTP message
TCP segment
IP packet IP packetIP packet
5/23/05 CS118/Spring052
R1
R2
R3 R4
sourcereplication
R1
R2
R3 R4
in-networkreplication
replicate
replicate
Broadcast Routing Goal: Deliver packets from a source to all other nodes Why letting source send to everyone not a good solution
the source may not know all the destination addresses Redundant transmission over links near the source
5/23/05 CS118/Spring053
In-network replication Flooding: when a node receives a broadcast packet, sends a
copy to all neighbors Problems: packet looping
Controlled flooding: node broadcast a packet if it hasn’t seen the same packet before Node must keep track of packet ids already seen
Reverse Path Forwarding (RPF): a node N forwards packet if it arrived on shortest path between N and source Make use of forwarding table of unicast routing
R1
R2
R3
R4
R5R6
R7
source
5/23/05 CS118/Spring054
A
B
G
DE
c
F
A
B
G
DE
c
F
(a) Broadcast initiated at A (b) Broadcast initiated at D
Spanning Tree First construct a spanning tree Nodes forward copies only along spanning tree
No redundant packets received by any node
All sources send data along the same tree
5/23/05 CS118/Spring055
A
B
G
DE
c
F
(a) Stepwise construction of spanning tree
A
B
G
DE
c
F
(b) Constructed spanning tree
Creating a center-based Spanning TreeFirst pick a center node (E in this example)Each node sends unicast join message towards
the center nodeMessage forwarded until it arrives at a node already
belonging to spanning tree
5/23/05 CS118/Spring056
Multicast RoutingGoal: build a tree to reach all members in a mcast group shared-tree: same tree used by all group members
minimal spanning tree (Steiner) center-based tree
source-based tree: one tree from each sender to receivers Each tree made of shortest paths to all mcast members 2 ways to build: link-state (MOSPF), RPF (DVMRP)
Shared tree Source-based trees
5/23/05 CS118/Spring057
Shared-Tree: Steiner Tree
Steiner Tree: minimum cost tree connecting all routers with attached group members
problem is NP-completeexcellent heuristics existsnot used in practice:
computational complexity Infeasible to get/keep information about entire
networkmonolithic: rerun whenever a router needs to
join/leave
5/23/05 CS118/Spring058
Center-based shared routing treeone router identified as “center” of treerouter with mcast member attached sends unicast
join-msg addressed to the center router join-msg processed by intermediate routers before
being forwarded towards center join-msg either hits existing tree branch for this
center, or arrives at centerpath taken by join-msg becomes new branch of tree
R1
R2
R3
R4
R5R6
R7
5/23/05 CS118/Spring059
R1
R2
R3
R4
R5
R6R7
router with attachedgroup member
router with no attachedgroup member
LEGEND
S: source
Building Shortest Path Tree: MOSPF OSPF: a link-state routing protocol
Each node maintains a complete network graph Use Dijkstra algorithm to compute the shortest path
MOSPF (Multicast OSPF)Carry multicast membership in link-state packetRouter computes shortest path tree for each source
5/23/05 CS118/Spring0510
Reverse Path Forwarding: example
• result is a source-specific reverse shortest path broadcast tree– may not be a good tree if link cost is asymmetric– It's a broadcast tree, reaching every node
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
datagram will be forwarded
LEGENDS: source
datagram will not be forwarded
5/23/05 CS118/Spring0511
R1
R2
R3
R4
R5
R6 R7
router with attachedgroup member
router with no attachedgroup member
prune message
LEGENDS: source
links with multicastforwarding
P
P
P
Trim Broadcast Tree to Mcast Tree by Pruning
no need to forward packets down branches which has no mcast group members
router with no downstream group members sends “prune” message upstreamRouters keep state regarding prune msgs
5/23/05 CS118/Spring0512
Distance-Vector Multicast Routing Protocol(DVMRP, specified in RFC1075)
DVMRP routers run RIP to build routing table Use reverse path forwarding to build source-based tree
initial datagram to mcast group floods everywhere via RPF Edge routers with no members send prune msg upstream
soft state: router periodically delete prune state Sender may have finished by then If not, downstream router prune again
routers can quickly graft to tree By canceling the prune state
R1
R2
R3
R4
R5
R6 R7
P
P
5/23/05 CS118/Spring0513
PIM: Protocol Independent Multicast
independent from underlying unicast routing algorithmEither get "next hop" information for each node from
the unicast forwarding table, orUse unicast routing to forward mcast join message
two different multicast distribution scenarios:Dense: group members densely packed, in “close”
proximity Sparse: # networks with group members small wrt to
the total # of interconnected networks, group members widely dispersed
5/23/05 CS118/Spring0514
Consequences of Sparse-Dense Dichotomy:
Dense group membership by
routers assumed until routers explicitly prune
data-driven construction on mcast tree (e.g., RPF)
Sparse no membership until
routers explicitly join receiver- driven
construction of mcast tree (e.g., center-based)
Implementation: flood-and-prune RPF similar to DVMRP but using info from underlying unicast protocol for RPF checking
5/23/05 CS118/Spring0515
PIM - Sparse Mode Build center-based shared tree router sends join msg to
rendezvous point (RP) intermediate routers update state
and forward join msgs
Data sources: unicast packets to RP, which
forwards down RP-rooted tree
RP can send stop msg to source if no receivers joined the group “no one is listening!”
R1
R2
R3
R4
R5
R6R7
join
join
join
all data multicastfrom rendezvouspoint
rendezvouspoint
5/23/05 CS118/Spring0516
hosts
routers
host-to-router protocol Internet Group Management Protocol
multicast routing protocols(MOSPF, DVMRP, PIM)
Components of the IP Multicast Architecture
IGMP operates between Router and local Hosts on the same network (e.g., Ethernet) Router queries local Hosts for mcast group membership info Hosts respond with membership reports
5/23/05 CS118/Spring0517
IP Multicast Address
Class D IP addresses:
in “dotted decimal” notation: 224.0.0.0 — 239.255.255.255
Two administrative categories: well-known multicast addresses, assigned by IANA (the rest) transient addresses, assigned & reclaimed dynamically
1 1 1 0 group ID
131.179.26.3818.4.157.100
5/23/05 CS118/Spring0518
How IGMP Works (I)
One router is elected the “querier” on each local/physical network
querier periodically sends Membership Query message to “all-systems group” (224.0.0.1) with TTL=1
Qrouters:
hosts:
5/23/05 CS118/Spring0519
Q
G G G G
How IGMP Works (II) On receipt, a host starts a random timer [0–10 sec] for each
multicast group it wants to join when a host’s timer for group G expires, it sends a Membership
Report to group G (TTL = 1) other members of G hear the report, stop their timers routers hear all reports
Normal case: only one report message per group is sent in response to a query
when a host first joins a group, it can send unsolicited reports immediately
5/23/05 CS118/Spring0520
Q
G G G G
How IGMP Works: Leaving a Multicast Group
host sends a Leave Group msg to group address G if it was the most recent host to report membership in that group
Upon receiving Leave Group msg: query router sends a few queries to group G with a small max-response-time if no Membership Report heard, stop data forwarding
5/23/05 CS118/Spring0521
IGMP message types IGMP Msg type Sent by Purpose
membership query: general router
membership query: specific router
membership report host
leave group host
query for current active multicast groups
query for specific m-cast group
host wants to join group
host leaves the group
IP header
5/23/05 CS118/Spring0522
applicationtransportnetwork
linkphysical
networklink
physical
M
M
M
M
Ht
HtHn
HtHnHl MHtHnHl
framephys. link
data linkprotocol
adapter card
Chapter 5: the Data Link Layer: overviewdata delivery between two physically connected
devices implementation of various link layer
technologies:Ethernet, hubs, bridges, IEEE 802.11 LANs, PPP
Address mapping between LAN and IP: ARP
5/23/05 CS118/Spring0523
Link Layer Services sending data over a physical link
1. bit encoding: transmitting sequence of 1’s and 0’s by signals2. Framing: defining the beginning & end of a data chunk3. bit error detection4. reliable transmission
MAC (Medium Access Control) addresses to identify source, destination nodes Different address, not IP address!
Channel access if shared medium e.g, Ethernet, wireless, etc.
Flow Control: pacing between sender and receivers implemented in “adapter” (e.g., PCMCIA card, Ethernet card) Link type: Half-duplex vs. full-duplex
5/23/05 CS118/Spring0524
data
Data FramingTerminology: for a block of data
at link layer: normally called a data frameat network layer: a packetat transport level: TCP segment; UDP datagram
A frame/packet has a header fieldoptionally there may be a trailer field too
Byte-Oriented Framing Protocol: delineate frame with a special bit sequence: 01111110
Q: What if the bit sequence 01111110 occurs in data stream?
5/23/05 CS118/Spring0525
Byte stuffing
Sender: adds (“stuffs”) extra < 01111110> byte after each apperance of < 01111110>
Receiver: single 01111110: flag byte two back-to-back 01111110 bytes: discard first
byte, continue data receptionstuffing changes the total length of data to be sent
5/23/05 CS118/Spring0526
Error DetectionEDC= Error Detection and Correction bits (redundancy)D = Data protected by error checking• Error detection not 100% reliable!
• protocol may miss some errors, though rarely• larger EDC field gives better detection and correction
5/23/05 CS118/Spring0527
Parity Checking
Single Bit Parity:Detect single bit errors
Two Dimensional Bit Parity:Detect and correct single bit errors
consider a data frame as a m n matrix
A parity bit for each row n-bit checksum,andA parity bit for each column m-bit checksum
5/23/05 CS118/Spring0528
Cyclic Redundancy Check (CRC)consider a data frame as a bit sequence M(x)
e.g. 10011010 M(x) = x7 + x4 + x3 + x1k-term polynomial has a degree of (k-1)
• e.g. 10011010 represents a 8-term polynomialuse a (r+1)-bit generator polynomial G(x) to
compute the checksum for M(x)sender makes the transmitted bit sequence dividable by
G(x) by appending r-bit remainder to M(x)receiver divides the received sequence by G(x)
M
M
5/23/05 CS118/Spring0529
How to compute CRC1. append r zero bits to M(x) to get xrM(x)
M(x) = 10011010 = x7 + x4 + x3 + x1, G(x) = 1101=x3 + x2 + 1, r = 3
then xrM(x) = x10 + x7 + x6 + x4 10011010000
2. divide xrM(x) by G(x)10011010000 / 1101 = 11111001, remainder 101
3. subtract the remainder from xrM(x) T(x), check-summed frame to be transmitted
xrM(x) / G(x) = Q(x), remainder R(x), T(x) = xrM(x) - R(x)In reality: just append R(x) to the end of data frame M(x) : 10011010 101Because: xrM(x) = shifting M(x) to the left by r bits, andfor XOR: r bits of 0's – R(x) = R(x)
At receiving end: if the received frame P(x) divisible by G(x), P(x)/G(x) = 0, P(X) considered error free
5/23/05 CS118/Spring0530
An example CRC computation
1101 100110100001101 1001 1101 1000 1101 1011 1101 1100 1101 1000 1101 101remainder
11111001
computation by sender computation by receiver
1101 100110101011101 1001 1101 1000 1101 1011 1101 1100 1101 1101 1101 0
11111001
5/23/05 CS118/Spring0531
Multiple Access protocols The problem: single shared communication channel, only
one node can send successfully at a time 3 broad classes:
Channel Partitioning• divide channel into smaller “pieces” (time slots, frequency band, code
modulation)• allocate piece to node for exclusive use
“Taking turns”• coordinate shared access to avoid collision
Random Access• Detect and resolve collisions
5/23/05 CS118/Spring0532
Channel Partitioning: TDMA and FDMA TDMA: Time Division Multiple Access
channel divided into N fixed length time slots, one per station each station takes turns to access channel unused slots go idle example: 6-station LAN, 1,3,4 send data, slots 2,5,6 idle
FDMA channel spectrum divided into frequency bands each station assigned fixed frequency band unused frequency bands go idle example: 6-station LAN, 1, 3, 4 send data, frequency bands 2,5,6 idle
frequ
ency
bands time
5/23/05 CS118/Spring0533
“Taking Turns” MAC protocols channel partitioning: commonalities
Share channel efficiently with constant, uniform loadBut inefficient with random, non-uniform load
• delay in channel access
• 1/N bandwidth allocated even if only 1 active node!
“taking turns” protocols: on-demand channel allocationPolling: master node asks slave nodes to transmit in turn
• Concerns: polling latency, single point of failure
Token passing
5/23/05 CS118/Spring0534
“Taking Turns” by Token Passing One token message passed from one node to next
sequentially whoever gets the token can send one data frame, then
passes token to next node A master station generates the token and monitors its
circulation concerns:
token overhead latency single point of failure (token)
5/23/05 CS118/Spring0535
Random Access protocols When node has packet to send
transmit at full channel data rate R. no a priori coordination among nodes
If two or more nodes transmitting at the same time “collision”
random access MAC protocol specifies: how to detect collisions how to recover from collisions
Examples of random access MAC protocols: ALOHA slotted ALOHA CSMA and CSMA/CD
5/23/05 CS118/Spring0536
ALOHA If a station has data to send: just send collision probability:
frame sent at t0 collide with other packets sent in [t0-1, t0+1]
P(success by given node) = P(node transmits) . P(no other node transmits in [t0-1,t0] .
P(no other node transmits in [t0,t0+1]
= p . (1-p)N-1 . (1-p)N-1
P(success by any node) = N p . (1-p) 2(N-1) choosing optimum p as n ∞ ...
= 1/(2e) = 0.18
5/23/05 CS118/Spring0537
Slotted Aloha
Assumptions:All frames the same size; clocks in all nodes are
synchronizedDivide time into equal size slots (= pkt trans.
time)If 2 or more nodes transmit in the same slot, all
nodes detect collision
5/23/05 CS118/Spring0538
Success (S), Collision (C), Empty (E) slots
Slotted AlohaOperations: When a node gets data to send, it transmits at beginning
of next slot If no collision, node can send new frame in next slot If collision: node retransmits frame in each subsequent
slots with probability p, until successful.
5/23/05 CS118/Spring0539
Slotted Aloha efficiencyQ: what is the max fraction of slots successful?
each node transmits in a slot with probability pprob. successful transmission S is
by a given node: S= p (1-p)(N-1)
by any of N nodes S = Prob (only one transmits) = N p (1-p)(N-1)
… choosing optimum p as n ∞ ...
= 1/e = 0.37At best: channeluse for useful transmissions 37%of time!
S =
thro
ughput
=
“goodput”
(
succ
ess
rate
)
G = offered load = N*p0.5 1.0 1.5 2.0
0.1
0.2
0.3
0.4
Pure Aloha
Slotted Aloha
5/23/05 CS118/Spring0540
CSMA: Carrier Sense Multiple Access listen before transmit If channel sensed idle: transmit If channel sensed busy, wait
p-persistent CSMA: when channel becomes idle, retry immediately with probability p
Non-persistent CSMA: retry after a random interval
collisions still possible: propagation delay two or more
nodes may send simultaneously Chance of collision goes up
with distance between nodes
To cut the loss early: CSMA/CD
5/23/05 CS118/Spring0541
CSMA/CD (Collision Detection) Collision Detection: compare
transmitted with received signals Abort collided transmissions
5/23/05 CS118/Spring0542
random access
ALOHA,slottedALOHA
CSMA/CD
Classification ofdifferent multiaccess protocols
Multiple data sources sharingthe same communication link
(Ethernet, FDDI, Appletalk, etc)
tokenpassing TDMApolling
Staticallocation
controlled access
adaptiveto demand
FDMA
CDMA
5/23/05 CS118/Spring0543
LAN Addresses and ARP32-bit IP address: network-layer address used to get IP packet to destination host
LAN (or MAC or physical) address: used to get frame from one interface to another physically
connected interface (same network) 48 bit MAC address (for most LANs) burned in the adapter ROM
Each adapter on LAN has a unique LAN address Broadcast address: FF-FF-FF-FF-FF-FF
5/23/05 CS118/Spring0544
LAN Address (more)
MAC address allocation administered by IEEE manufacturer buys portion of MAC address space (to
assure uniqueness) Analogy: (a) MAC address: like Social Security Number (b) IP address: like postal address MAC flat address => portability
can move LAN card from one LAN to another IP hierarchical address NOT portable
depends on network to which one attaches
5/23/05 CS118/Spring0545
Recall earlier routing discussion
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4 223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2223.1.3.1
223.1.3.27
A
BE
Node A sends IP packet to B:• look up network address of B, find B is on the same net as A• link layer send datagram to B inside link-layer frame
B’s MACaddr
A’s MACaddr
A’s IPaddr
B’s IPaddr
IP payload
datagramframe
frame source,dest address
datagram source,dest address
5/23/05 CS118/Spring0546
ARP: Address Resolution Protocol
Each IP node (Host, Router) on LAN has ARP table
ARP Table: IP/MAC address mappings for some LAN nodes
< IP address; MAC address; TTL>
TTL (Time To Live): time after which address mapping will be forgotten (typically 20 min)
Question: how to determineMAC address of Bgiven B’s IP address?
1A-2F-BB-76-09-AD
58-23-D7-FA-20-B0
0C-C4-11-6F-E3-98
71-65-F7-2B-08-53
LAN
237.196.7.23
237.196.7.78
237.196.7.14
237.196.7.88
5/23/05 CS118/Spring0547
ARP protocol A knows B's IP address, wants to learn B's MAC address A broadcasts ARP query pkt, containing B's IP address
Dest MAC address = FF-FF-FF-FF-FF-FF all machines on LAN receive ARP query
B receives ARP packet, replies to A with its (B's) physical layer address reply sent to A’s MAC address (unicast)
A caches (saves) IP-to-physical address pairs until information becomes old (times out) soft state: information that times out (goes away) unless refreshed
ARP is “plug-and-play”: nodes create their ARP tables without intervention from net
administrator
5/23/05 CS118/Spring0548
A creates IP packet with source A, destination B A uses ARP to get R’s physical layer address for 111.111.111.110 A creates Ethernet frame with R's MAC address as destination A’s data link layer sends the Ethernet frame R’s data link layer receives Ethernet frame R extracts IP datagram from Ethernet frame, sees it’s destined to B R uses ARP to get B’s physical layer address R creates frame containing A-to-B IP packet, sends to B
A
RB
Routing to another LAN
5/23/05 CS118/Spring0549
Ethernet first widely used LAN technology, dominant LAN today Kept up with speed race: 10 Mbps – 10 Gbps Bus topology popular through mid 90s Now star topology prevails Connection choices: hub or switch (more later)
hub orswitch
5/23/05 CS118/Spring0550
Schedule for next week
Makeup lecture: Monday 6/68:00-9:50AM, 5422BH6:00-7:50PM, 5419BH
Tuesday 6/7: regular class hoursWednesday 6/8: office hour cancelledThursday 6/9: no classSaturday 6/11:
Office hour: 10:00AM - 1:00PMFinal exam: 3:00-6:00PM, 2444BH
5/23/05 CS118/Spring0551
Ethernet Frame Structure
Sending adapter encapsulates IP datagram (or other network layer protocol packet) in Ethernet frame
Preamble: 7 bytes with pattern 10101010 followed by one byte with pattern
10101011 used to synchronize receiver, sender clock rates
Addresses: 6 bytes Type: indicates the higher layer protocol
IEEE802.3 changed the “type” field to “length”, defined a separate type field carried in the data part
CRC: checked at receiver, if error, drop the frame
46 – 1500 bytes
5/23/05 CS118/Spring0552
Ethernet Frame length limit All packets/frames have an upper bound on length Ethernet has a lower bound for reliable collision detection:
cable max length 2500m transceiver can send & listen at the same time
If the received data stream differs from the one transmitted collision
to detect collision: the sender must still be transmitting when garbled signal propagates back
minimum frame = 64bytes = 512bits, take 51 to transmit at 10Mbps
sec2.512 μ=delayP
secμ
BA
5/23/05 CS118/Spring0553
Ethernet MAC protocol: CSMA/CDA: sense channel, wait if necessary until it is idle
transmit and monitor the channel; If detect another transmission
then { abort and send jam signal;
update # collisions (n++); delay for K x 512bits trans timegoto A}
else {done with the frame; set #collisions to zero (n = 0)}
Jam Signal: make sure all other transmitters are aware of collision; 48 bits
Exponential Backoff algorithm: first collision (n=1): choose K from {0, 1} after second collision (n =2): choose K from {0, 1, 2, 3}… after 10 collisions (n=10), choose K from {0,1,2,3,4,…,1023}
5/23/05 CS118/Spring0554
CSMA/CD efficiency Tprop = max. propagation delay between 2 nodes in LAN
Ttrans = time to transmit a max-size frame
Efficiency goes to 1 as Tprop goes to 0
as Ttrans goes to infinity
Much better than ALOHA, but still decentralized, simple, and cheapBest effort data delivery
€
efficiency =1
1+ 5t prop / ttrans
5/23/05 CS118/Spring0555
DHCP client-server scenario
223.1.1.1
223.1.1.2
223.1.1.3
223.1.1.4 223.1.2.9
223.1.2.2
223.1.2.1
223.1.3.2223.1.3.1
223.1.3.27
DHCP server 223.1.2.5
DHCP server:
223.1.2.5
arriving client
time
DHCP discover
src : 0.0.0.0, 68 dest.: 255.255.255.255,67yiaddr: 0.0.0.0transaction ID: 654
DHCP offer
src: 223.1.2.5, 67 dest: 255.255.255.255, 68yiaddrr: 223.1.2.4transaction ID: 654Lifetime: 3600 secs
DHCP request
src: 0.0.0.0, 68 dest:: 255.255.255.255, 67yiaddrr: 223.1.2.4transaction ID: 655Lifetime: 3600 secs
DHCP ACK
src: 223.1.2.5, 67 dest: 255.255.255.255, 68yiaddrr: 223.1.2.4transaction ID: 655Lifetime: 3600 secs
arriving new host
5/23/05 CS118/Spring0556
DHCPrelay
Broadcast
Othernetworks
DHCPserver
host
Unicast to server
Either have a DHCP server on each network, or a DHCP-relay to forward request to server
A1 A2
broadcastSource=A1Dest. =A2broadcast
DHCP Relay & IP Tunneling
Put another IP header infront of the original packets,with Source=tunnel entry, Destination=tunnel exit
IP tunnel: