0% found this document useful (0 votes)
21 views

2 TCP - Ip Ii

Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views

2 TCP - Ip Ii

Copyright
© © All Rights Reserved
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 42

Introduction to

TCP/IP II

7th edition
Jim Kurose, Keith Ross
Pearson/Addison Wesley
April 2016

- essentially adapted from Kurose and Ross


Introduction 1-1
application

transport

network

link

physical

Application Layer 2-2


Transport services and
protocols applicatio

 provide logical n
transport

communication between network


data link
app processes running on physical

lo
different hosts

gi
ca
 transport protocols run in

enl
end systems

d-
en
• send side: breaks app

d
tr
messages into

ans
segments, passes to

po
tr
network layer
• rcv side: reassembles applicatio
n
segments into transport
network
messages, passes to data link
physical
app layer
 more than one transport
protocol available to apps
• Internet: TCP and UDP
Transport Layer 3-3
Internet transport-layer
protocols
 reliable, in-order applicatio
n
transport
delivery (TCP) network
data link
network
• congestion control physical

lo
network data link

gi
data link physical
• flow control

ca
physical
network

l en
data link
• connection setup

d-
physical

en
 unreliable, network

d
data link

tr
unordered delivery:

a
physical

ns
network

po
UDP data link

r
physical

t
network
• no-frills extension of data link
physical
applicatio
n
“best-effort” IP network
data link transport
network
 services not
physical
data link
physical

available:
• delay guarantees
• bandwidth
guarantees Transport Layer 3-4
Sockets
• Application processes sends messages to (or receives
messages from) transport layer through socket.
• socket programming is for this purpose: socket.send(M)
and M=socket.recv()
process socket

application
P3

transport
network
link
physical

Transport Layer 3-5


Multiplexing/
demultiplexing
multiplexing at sender: demultiplexing at receiver:
handle data from use header info to deliver
multiple received segments to corre
sockets, add transport socket
header (later used for
demultiplexing)
process socket

application application
application
P3 P1 P2 P4

transport transport transport


network network network
link link link
physical physical physical

Host 1 Host 3

Host 2 Transport Layer 3-6


How demultiplexing works
 host receives IP datagrams 32 bits
• each datagram has source IP
address, destination IP address source port # dest port #
• each datagram carries one
transport-layer segment
• each segment has source, other header fields
destination port number
 host uses IP addresses & port
numbers to direct segment to application
appropriate socket
data
(payload)

TCP/UDP segment format

Transport Layer 3-7


UDP demultiplexing

 when host receives IP datagrams with same


UDP segment: dest. port #, but different
source IP addresses and/or
• checks destination port source port numbers will be
# in segment directed to same socket at
• directs UDP segment dest
• a UDP server (e.g., DNS) with
to socket with that port two clients is an example
#

3-8
UDP demux: example
application port
6428
application port P1
port
5775
application
P3 9157
P4

sport 6428 sport 6428


dport 9157 dport 5775

sport 9157 sport 5775


dport 6428 dport 6428

Transport Layer 3-9


TCP demux
 TCP socket  server host may
identified by 4- support many
tuple: simultaneous TCP
• source IP address sockets:
• source port number • each socket
• dest IP address identified by its own
4-tuple
• dest port number
 web servers have
 demux: receiver
different sockets for
uses all four values each connecting
to direct segment client
to appropriate
socket
Transport Layer 3-10
TCP demux: example
threaded server
IP: A IP: B IP: C
application
application P4 application
P1 P2 P3

sport 5775
sport 9175 dport 6428
dport 6428 s-ip: C
s-ip: A d-ip: B
d-ip: B
dport 6428
sport 5776
d-ip: B
s-ip: C
Transport Layer 3-11
UDP: User Datagram Protocol
[RFC 768]
 “no frills,” “bare bones”  UDP use:
transport protocol  streaming
 “best effort” service, multimedia apps
UDP segments may be: (loss tolerant, rate
• lost sensitive)
• delivered out-of-order  DNS
to app  SNMP
 connectionless:
 reliable transfer
• no handshaking
between UDP sender, over UDP:
receiver  add reliability at
• each UDP segment application layer
handled  application-specific
independently of error recovery!
others
Transport Layer 3-12
UDP: segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header

length checksum
why is there a UDP?
 no connection
application establishment (which
data can add delay)
(payload)  simple: no connection
state at sender,
receiver
 small header size
UDP segment format  no congestion control:
UDP can blast away as
fast as desired

Transport Layer 3-13


UDP checksum
Goal: detect “errors” (e.g., flipped bits) in
transmitted segment
sender: receiver:
 treat segment contents,  compute checksum of
including header fields, received segment
as sequence of 16-bit
integers  check if computed
 checksum: addition checksum equals
(one’s complement checksum field value:
sum) of segment • NO - error detected
contents
 sender puts checksum • YES - no error
value into UDP detected. But maybe
checksum field errors

Transport Layer 3-14


TCP: Overview RFCs: 793,1122,1323,
2018, 2581

 point-to-point:  full duplex data:


• bi-directional data
• one sender, one flow in same
receiver connection
 reliable, in-order byte • MSS: maximum
steam: segment size
• no “message  connection-oriented:
boundaries” • handshaking
(exchange of control
 pipelined: msgs) inits sender,
• TCP congestion and receiver state before
flow control set window data exchange
size  flow controlled:
• sender will not
overwhelm receiver
Transport Layer 3-15
TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

Transport Layer 3-16


seq. # and ACK #
sequence numbers:
• Initial seq # can be any
• Seq # (next packet) =seq# (current packet)+ #databytes
(current packet)
• nex seq# >current seq #.
• seq# can be used to recover the packet order.

Acknowledge number:
• ack_num=seq# of next packet expected
from other side source port # dest port #
• ack_num=502: sequence number
acknowledgement number
please send your packet with A rwnd
seq#=502. checksum urg pointer
• means packets with seq#<502 have
been received.

Transport Layer 3-17


TCP seq. numbers, ACKs
Host A Host B

User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80

simple telnet scenario

Transport Layer 3-18


timeout
• If a segment is not acked, then the
packet might be lost and so sender
needs to retransmit it.
 Sender needs to set a timeout (e.g., 5s).
After waiting for this length of time, he
needs to retransmit the segment.

Transport Layer 3-19


TCP: retransmission
scenarios
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data


timeo

timeo
ACK=100
ut

ut
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8


SendBase=100 bytes of data
SendBase=120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout


Transport Layer 3-20
TCP: retransmission
scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data


ACK=100
timeo

X
ut

ACK=120

Seq=120, 15 bytes of data

cumulative ACK
Transport Layer 3-21
TCP flow control
application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than
TCP
receiver is TCP
delivering code
(sender is
sending)
IP
flow control code
receiver controls sender,
so sender won’t overflow
receiver’s buffer by from sender
transmitting too much,
receiver protocol stack
too fast

Transport Layer 3-22


TCP flow control
 receiver puts free
buffer size rwnd in TCP to application process
header of receiver-to-
sender segments
RcvBuffer buffered data
• RcvBuffer=4096bytes
(typical default)
 If sender receives a rwnd free buffer space
packet with small
rwnd, it reduces the
sending speed. TCP segment payloads
 This guarantees
receive buffer will not receiver-side buffering
overflow

Transport Layer 3-23


TCP 3-way Handshake
Protocolclient state server state
Sock.connect((servName, servPort)) LISTEN

SYNSENT

SYN RCVD

ESTAB

ESTAB

x is random chosen by client


y is random chosen by server
TCP: closing a connection
client closes socket:
close(fd);
closing
Step 1: client sends FIN FIN
segment to server to close C-
> S direction
Step 2: server receives FIN,
replies with ACK and also ACK
closing
FIN to close the S->C
direction. FIN

Step 3: client receives FIN,


ACK
Timed wqit
replies with ACK and enters
timed-wait state. closed

Step 4: server receives FIN


and enter closed state.
closed
Transport Layer 3-25
application

transport

network

link

physical

Network Layer: Data Plane 4-26


Two network-layer
functions
network-layer functions:
forwarding: move packets from router’s
input to appropriate router output
routing: determine route taken by
packets from source to destination
• routing algorithms

Network Layer: Data Plane 4-27


Per-router control plane
Individual routing algorithm components in each and every
router interact in the control plane

Routing
Algorithm
control
plane

data
plane

values in arriving
packet header
0111 1
2
3

Network Layer: Control Plane 5-28


Router architecture overview
 high-level view of generic router architecture:

routing, management
routing control plane (software)
processor operates in millisecond
time frame
forwarding data plane
(hardware) operttes
in nanosecond
timeframe
high-seed
switching
fabric

router input ports router output ports

Network Layer: Data Plane 4-29


Input port functions
lookup,
link forwarding
line layer switch
termination protocol fabric
(receive)
queueing

physical layer:
bit-level reception decentralized switching:
data link layer:  destination-based forwarding: forward
e.g., Ethernet based only on destination IP address
(chapter 5) (traditional)
 generalized forwarding: forward based
on any set of header field values
 queuing: if datagrams arrive faster
than forwarding rate into switch fabric
• if queue is full, the arriving packet is
dropped.
Network Layer: Data Plane 4-30
Destination-based
forwarding
forwarding table
Destination IP Address Range Link Interface

11001000 00010111 00010000 00000000


through 0
11001000 00010111 00010111 11111111

11001000 00010111 00011000 00000000


through 1
11001000 00010111 00011000 11111111

11001000 00010111 00011001 00000000


through 2
11001000 00010111 00011111 11111111

otherwise 3

Network Layer: Data Plane 4-31


Longest prefix matching
longest prefix matching
when looking for forwarding table entry
for given destination address, use longest
address prefix that matches destination
address.
Destination IP Address Range Link interface
11001000 00010111 00010*** ********* 0
11001000 00010111 00011000 ********* 1
11001000 00010111 00011*** ********* 2
otherwise 3

examples:
DA: 11001000 00010111 00010110 10100001 which interface?
DA: 11001000 00010111 00011000 10101010 which interface?
Network Layer: Data Plane 4-32
Switching via memory
first generation routers:
 traditional computers with switching under
direct control of CPU
 packet copied to system’s memory

input output
port memory port
(e.g., (e.g.,
Ethernet) Ethernet)

system bus

Network Layer: Data Plane 4-33


Output ports

datagram
switch buffer link
fabric layer line
protocol termination
queueing (send)

 buffering (or a queue) required when


datagrams via switching is faster than the
outgoing transmission
 Packet will be dropped if the queue is full.

Network Layer: Data Plane 4-34


IP datagram format
IP protocol version 32 bits total datagram
header length type of length (bytes)
ver head. length
(bytes) len service for
“type” of data fragment fragmentation/
16-bit identifier flgs
offset reassembly
router decreases it by 1; time to upper header
drop packet if it is 0. live layer checksum
32 bit source IP address
32 bit destination IP address
upper layer protocol
in the payload options (if any) e.g. timestamp

how much overhead? data


 20 bytes of TCP (variable length,
 20 bytes of IP
typically a TCP
 = 40 bytes + app
or UDP segment)
layer overhead

Network Layer: Data Plane 4-35


IP fragmentation,
reassembly
 network links have
MTU (max transfer
size)
fragmentation:


• vary on link types in: one large datagram
 large IP datagram out: 3 smaller datagrams
divided
(“fragmented”) within
net
reassembly
• one datagram
becomes several
datagrams
• “reassembled” only …
at final destination
• IP header bits used
to identify, order
related fragments
Network Layer: Data Plane 4-36
IP addressing: introduction
223.1.1.1
 IP address: 32-bit
identifier for host, 223.1.2.1

router interface 223.1.1.2


 interface: 223.1.1.4 223.1.2.9

connection between
host/router and 223.1.1.3
223.1.3.27

physical channel 223.1.2.2

• router’s typically have


multiple interfaces
• host typically has one 223.1.3.1 223.1.3.2
or two interfaces (e.g.,
wired Ethernet,
wireless 802.11)
 IP addresses 223.1.1.1 = 11011111 00000001 00000001 00000001
associated with each
interface 223 1 1 1

Network Layer: Data Plane 4-37


Subnets
 IP address: 223.1.1.1
• subnet part - high
order bits 223.1.1.2 223.1.2.1
223.1.1.4 223.1.2.9
• host part - low
order bits 223.1.2.2
 what’s a subnet ? 223.1.1.3 223.1.3.27

• device interfaces subnet


with same subnet
223.1.3.2
part of IP address 223.1.3.1
• can physically
reach each other
without intervening network consisting of 3 subnets
router

Network Layer: Data Plane 4-38


Subnets
223.1.1.0/24
223.1.2.0/24
recipe 223.1.1.1

 to determine the 223.1.1.2 223.1.2.1


subnets, detach 223.1.1.4 223.1.2.9

each interface 223.1.2.2


from its host or 223.1.1.3 223.1.3.27

router, creating subnet


islands of isolated
networks 223.1.3.1 223.1.3.2

 each isolated
network is called 223.1.3.0/24
a subnet
subnet mask: /24
Network Layer: Data Plane 4-39
DHCP: Dynamic Host Configuration
Protocol
goal: allow host to dynamically obtain its IP address
from network server when it joins network

Network Layer: Data Plane 4-40


DHCP client-server
scenario
DHCP
223.1.1.0/24
server
223.1.1.1 223.1.2.1

223.1.1.2 arriving DHCP


223.1.1.4 223.1.2.9
client needs
address in this
223.1.3.27
223.1.2.2 network
223.1.1.3

223.1.2.0/24

223.1.3.1 223.1.3.2

223.1.3.0/24
Network Layer: Data Plane 4-41
DHCP client-server
scenario
DHCP server: 223.1.2.5 DHCP discover arriving
client
src : 0.0.0.0, 68
Broadcast: is there a
dest.: 255.255.255.255,67
DHCP server
yiaddr: 0.0.0.0out
transaction
there?ID: 654

DHCP offer
src: 223.1.2.5, 67
Broadcast: I’m a DHCP
dest: 255.255.255.255, 68
server! Here’s an IP
yiaddrr: 223.1.2.4
transaction ID: 654
address you can use
lifetime: 3600 secs
DHCP request
src: 0.0.0.0, 68
dest:: 255.255.255.255, 67
Broadcast: OK. I’ll
yiaddrr: 223.1.2.4
take that IPID:address!
transaction 655
lifetime: 3600 secs

DHCP ACK
src: 223.1.2.5, 67
dest: 255.255.255.255,
Broadcast: 68
OK. You’ve
yiaddrr: 223.1.2.4
gottransaction
that IPID:address!
655
lifetime: 3600 secs
Network Layer: Data Plane 4-42

You might also like