Internetworking

Dr. Satish Anamalamudi,

Department of CSE
SRM University-AP
Network Address Translation
Private vs Public IP Addresses
Whatever connects directly into Internet must have
public (globally unique) IP address
There is a shortage of public IPv4 address
So Private IP addresses can be used within a
private network
Three address ranges are reserved for private
usage
10.0.0.0/8
172.16.0.0/16 to 172.31.0.0/16
192.168.0.0/24 to 192.168.255.0/24
A private IP is mapped to a Public IP, when the
machine has to access the Internet
 NAT

NAT (Network Address Translation) Maps Private

IPs to Public IPs
It is required because of shortage of IPv4 Address

H1 H2 H3 H4

H5
10.0.1.2 10.0.1.3 10.0.1.2 10.0.1.3
213.168.112.3
10.0.1.1 10.0.1.1
Private network 1 Private network 2
Internet
Router/NAT Router/NAT
128.195.4.119 128.143.71.21
• ARP(Address Resolution
Protocol)
 Types of Addresses in Internet
• Media Access Control (MAC) addresses :
▫ Associated with network interface card (NIC)
▫ 48 bits or 64 bits
• IP addresses for the network layer
▫ 32 bits for IPv4, and 128 bits for IPv6
▫ E.g., 123.4.56.7
• IP addresses + ports for the transport layer
▫ E.g., 123.4.56.7:80
• Domain names for the application/human
layer
▫ E.g., www.google.com
IP And MAC working together
•IP addresses are chosen by the local system
administrator to suit the local network

•Ethernet addresses are built into the interface

hardware by the manufacturer

•The two addresses bear absolutely no

relationship to one another (as we would expect
from the layering principles).

•But, IP address need MAC addresses!

• If not – We couldn’t use physical layer to
send IP packets: we won't know where a
particular IP packet should physically be
 ARP
Introduction
• ARP : Primarily used to translate IP addresses to
Ethernet MAC addresses.

• RARP : Primarily used to translate MAC addresses

to IP addresses.
Step by step operation of
ARP
• ARP broadcasts an ARP Request
packet that contains the target IP
address in an Ethernet frame with
destination address ff:ff:ff:ff:ff:ff (and
source its own Ethernet address)
• All hosts on the local network read
the frame
• The target host recognises the
request for its IP address
Step by step operation of
ARP
• The target sends an ARP Reply packet
containing its own Ethernet address
(the other hosts need do nothing)
• It knows the source's Ethernet address
as read from the request packet
• The source gets the reply and reads
out the target's Ethernet address
• It can now use that Ethernet address
to send IP packets
 ARP Cache
 For every outgoing packet sending ARP request and
waiting for responses is inefficient
 Requires more bandwidth
 Consumes Time
 ARP cache maintained at each node
 Size limit = 512 entries (timer).
 When “ARP reply” returns a MAC address, it is placed
in a ARP cache. When the next request comes in for
the same IP address, look first in the cache.
 Cache space is limited(drops after 20 min).
 RARP
(Reverse Address Resolution
Protocol)
DHCP Protocol
 What is DHCP ?
• Dynamic Host Configuration Protocol
– Used for dynamic allocation of IP addresses
• used for hosts that run only client applications
– Allows for host-specific configuration parameters to
be delivered from a DHCP server to a host
• DHCP can also be used to convey permanent IP
address assignments to hosts
– Server interfaces need permanent addresses
because clients need to be able to reach them
– Also, router interfaces should have permanent
addresses for stability of routing data
 Where is DHCP used?
• Since class B and class C address spaces have been
exhausted, service providers and enterprises use
dynamically allocated IP
– e.g., a cable modem service provider who has many
customers
• since not all customers are simultaneously on the Internet, a client
host dynamically obtains an address for a short period of time and
releases it for use by some other client address.

• DHCP can be used whether link to endpoint is “wired” or

“wireless”
 Relevance of DHCP to
wireless and mobile networking
• If an end host only runs the “client” ends of
applications
• e.g. a web browser, but not a web server
• e.g. Outlook to download email messages delivered to a PC
user’s incoming mail server, but not the mail server itself
• e.g. Windows PCs have ftp clients but not ftp servers
– you ftp into utopia, but do you typically ftp into your PC?
– Then, the end host can simply connect to the network
at any “point of attachment,” obtain a network address
and start receiving information
 Components
• DHCP client: a host using DHCP to obtain
an IP address and other configuration
information
• DHCP server: a host that returns IP
addresses and other configuration
information
• BOOTP relay agents: host or router that
passes DHCP messages between DHCP
clients and DHCP servers
 Types of DHCP messages
• DHCPDISCOVER
• DHCPOFFER
• DHCPREQUEST
• DHCPACK
• DHCPNAK
• DHCPDECLINE
• DHCPRELEASE
• DHCPINFORM
 How does DHCP work?
• When a client needs to start up TCP/IP operations, it broadcasts a request
for address information.

• The DHCP server receives the request, assigns a new address for a
specific time period (called a lease period) and sends it to the client
together with the other required configuration information.

• This information is acknowledged by the client, and used to set up its

configuration.

• The DHCP server will not reallocate the address during the lease period
and will attempt to return the same address every time the client requests
an address.

• The client may extend its lease with subsequent requests, and may send a
message to the server before the lease expires telling it that it no longer
needs the address so it can be released and assigned to another client on
the network.
 DHCP procedures
• Obtaining a new address
• Reusing a previously allocated address
 Allocating new address
Server (not selected) Client Server (selected)
Sent on Ethernet DHCP DISC. DHCP DISC.
broadcast address

DHCPOF FER
FE R DHCPOF
Client selects
DHCP REQ.
Collects repliesDHCP REQ. configuration;
Also broadcast
in DCHP REQ
CK
DHCPA it accepts one
server’s offer
Initialization Complete (server identifier
option)
Graceful Shutdown
and implicitly
DHCPRELEASE reject rest
Discard lease
What happens if there is no DHCP server on a network and an IP host
connects to it with the “Obtain IP address automatically” option
selected?

If there is no DHCP server, and

no BOOTP relay agent, then no
IP address will be assigned and
hence host cannot
communicate;
In this case “Static Addressing”
needs to be used

In static addressing, the

following fields: Gateway, DNS
Configuration and IP Address
would have to be manually set
for a host to have connectivity
into the network.
Transport Layer
Types of data deliveries
 Transport services and protocols
• provide logical communication applicatio
n
between app processes transport
network
running on different hosts data link
physical

lo
• transport protocols run in end

gi
ca
systems

enl
d-
– send side: breaks app

en
messages into segments,

d
tr
a
passes to network layer

ns
po
– rcv side: reassembles

tr
segments into messages, applicatio
n
passes to app layer transport
network
• more than one transport data link
physical
protocol available to apps
– Internet: TCP and UDP

• network layer: logical communication between hosts

• transport layer: logical communication between processes
Figure 22.3 IP addresses versus port numbers
Internet transport-layer protocols
• reliable, in-order delivery applicatio
n
transport
(TCP) network
data link
network
– congestion control physical

lo
data link
network

gi
physical
data link
– flow control

ca
physical

l en
– connection setup

d-
en
network

d
data link

tr
a
physicalnetwork

ns
• unreliable, unordered data link

po
physical

rt
delivery: UDP network
data link
applicatio
physical network n
– No congestion control data link transport
physical network
– No flow control data link
physical
– No need for connection
setup
– Supports broadcast and
multicast 3-31
UDP: User Datagram Protocol [RFC 768]
• “best effort” service, UDP TCP – 20 bytes, UDP – 8 bytes
segments may be:
– lost
Why is there a UDP?
• no connection establishment
– delivered out of order to
(which can add delay)
app
• simple: no connection state
• connectionless:
at sender, receiver
– no handshaking between
• small segment header
UDP sender, receiver
• no congestion control: UDP
– each UDP segment
can blast away as fast as
handled independently of
desired
others
 UDP header format

32 bits

Length, in source port # dest port #

bytes of UDP length checksum
segment,
including
header

Application
data
(message)

UDP segment format

 UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment

Sender: Receiver:
• treat segment contents as • compute checksum of received
sequence of 16-bit integers segment
• checksum: addition (1’s • check if computed checksum
complement sum) of segment equals checksum field value:
contents – NO - error detected
• sender puts checksum value – YES - no error detected.
into UDP checksum field
 UDP checksum example:
• Three packets of 16 bits • The 1’s complement of
each ‘r’ is:
– 0110011001100110 – 0011010100110101
– 0101010101010101 • at destination, the sum
– 0000111100001111 of four packets should
• adding the three, calling be:
it ‘r’: – 1111111111111111
– 1100101011001010 • If the packet is
• Send the four packets, damaged:
the original three and – 1111101111111111
1’s complement of ‘r’ to (zeros!!)
zeros!!
destination

Why provide for error checking? No guarantee that it is

provided in all of the links between source and destination
We need UDP checksum to check the end-to-end errors
TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

a p p lic a tio n a p p lic a tio n

w rite s d a ta re a d s d a ta
socket socket
door door
TCP TCP
s e n d b u ffe r re c e iv e b u ffe r
segm ent

• point-to-point (unicast): • reliable, in-order byte steam:

– one sender, one receiver – no “message boundaries”
• connection-oriented: • send & receive buffers
– handshaking (exchange of – buffer incoming & outgoing
control msgs) init’s sender, data
receiver state before data
exchange
• flow controlled:
– State resides only at the END – sender will not overwhelm
systems – Not a virtual circuit! receiver
• full duplex data: • congestion controlled:
– bi-directional data flow in same – sender will not overwhelm
connection (A->B & B->A in the network
same connection) Web browsing, email, file sharing, instant messaging, file
transfer, database access, proprietary business
– MSS: maximum segment size applications, some multimedia applications (at least for
control purposes), …
 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 pnter
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
 TCP Segment Fields
• Source/Destination port: 16 bit port • Window contains the number of bytes
number of the source/destination the receiver is willing to accept (for
• Sequence number of the first data flow control)
byte in this segment • Checksum for detecting errors in the
– Unless the SYN flag is set, in which TCP segment
case the sequence number is the Initial • Urgent pointer points to the sequence
Sequence Number (ISN)
number of the last byte of urgent data
• Acknowledgement number: in the segment
sequence number of the next data • Options: such as maximum segment
byte TCP expects to receive size, window scaling, selective
• Header Length: Size of header acknowledgement, …
(measured in 4 bytes)
• Reserved for future use
• Flags see next slide

39
 Typical TCP Transaction
Client Server
• A TCP Transaction
consists of 3 Phases
1. Connection Establishment
 Handshaking between
Connection Establishment
client and server

2. Reliable, In-Order Data

Reliable, In-Order Exchange
Data Exchange  Recover any lost data
through retransmissions
and ACKs

Connection Termination
3. Connection Termination
 Closing the connection

time time
 TCP Connection Establishment
• TCP sender, receiver establish “connection” before
exchanging data segments

• initialize TCP variables:

– seq. #s
– buffers, flow control info (e.g. RcvWindow)

• client: connection initiator

Socket clientSocket = new Socket("hostname", port#);

• server: contacted by client

Socket connectionSocket = welcomeSocket.accept();
Connection Establishment (cont)
Host B
Three way Host A

handshake:
Connection
Step 1: client host sends TCP request
SYN
SYN segment to server , S eq
=42 host ACKs
– specifies a random initial and selects
seq # 3 its own
CK =4
– no data 79 , A initial seq #
q=
K , Se
Step 2: server host receives SYN, Y N+ AC
S
replies with SYNACK segment
host ACKs
– server allocates buffers ACK
, Seq
– specifies server initial seq. =43,
A CK=8
# 0

Step 3: client receives SYNACK, time time

replies with ACK segment,
which may contain data Three-way handshake
Connection Establishment (cont)
Host A Host B

Connection
request

SYN
Seq. #’s: , S eq
=42 host ACKs
– byte stream “number” of and selects
first byte in segment’s data 3 its own
CK =4
ACKs: 79 , A initial seq #
q=
K , Se
– seq # of next byte expected Y N+ AC
S
from other side
host ACKs
– cumulative ACK
ACK
, Seq
=43,
A CK=8
0

time time

Three-way handshake
 TCP Connection Termination
Closing a connection:
client closes socket: client server
clientSocket.close(); close
FIN
Step 1: client end system
sends TCP FIN control
segment to server
ACK DATA Data
Step 2: server receives FIN, ACK write
replies with ACK. Server
might send some buffered FIN

timed wait
but not sent data before close
ACK
closing the connection.
Server then sends FIN and
moves to Closing state. closed
Byte stream to TCP Segment
 …Emulated Using TCP
“Segments”
Host A
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

Segment sent when:

TCP Data 1. Segment full (Max Segment Size),
2. Not full, but times out, or
3. “Pushed” by application.

TCP Data
Host B
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

46
 Sequence Numbers
Host A
ISN (initial sequence number)

Sequence TCP
TCP Data
number = 1st HDR

byte ACK sequence

number = next
expected byte
TCP
TCP Data HDR
Host B

47
 TCP Segment
IP Data
TCP Data (segment) TCP Hdr IP Hdr

• IP packet
– No bigger than Maximum Transmission Unit (MTU)
– E.g., up to 1500 bytes on an Ethernet
• TCP packet
– IP packet with a TCP header and data inside
– TCP header is typically 20 bytes long
• TCP segment
– No more than Maximum Segment Size (MSS) bytes
–
48 E.g., up to 1460 consecutive bytes from the stream
 Flow control and Reliability
• Flow control (process-to-process): TCP makes sure that the sender does not cause
the receiver buffer to overflow
– By defining the amount of data that can be sent before receiving an acknowledgement
from the receiver (sliding – window protocols)
• Error control (process-to-process): entire message arrives at the receiving
transport layer without error, loss, duplication and in the same order they
were sent
– Error detection is done using checksum and correction by retransmission
– Implemented by a sliding window ARQ
– Every transmission of data is acknowledged by the receiver.
– Acknowledgements are cumulative.
– If the sender does not receive ACK within a specified amount of time, the sender
retransmits the data.
– Accepts out of order but does Not send negative acknowledgements,
– if a segment is not acknowledged before time-out, it is considered to be either
corrupted or lost and the sender will retransmit the segment only when it times-out
 TCP Flow Control
• receive side of TCP flow control
sender won’t
connection has a receive overflow
buffer: receiver’s buffer by
transmitting too
much,
too fast
• speed-matching
service: matching the
send rate to the
receiving app’s drain
rate
 app process may be
slow at reading from
buffer
Transport Layer 3-50
TCP Flow control: how it works
• Rcvr advertises spare
room by including value
of RcvWindow in
segments
• Sender limits unACKed
(Suppose TCP receiver data to RcvWindow
discards out-of-order – guarantees receive buffer
segments) doesn’t overflow
• spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]

Transport Layer 3-51

 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
Transport Layer 3-53
 Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R

Increase utilization
by a factor of 3!
3*L/ R .024
U = = = 0.0008
sender 30.008
RTT +L / R microsecon
ds
ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet: 3-54
 Pipelining Protocols
Go-back-N: big picture: Selective Repeat: big pic
• Sender can have up to N • Sender can have up to N
unacked packets in unacked packets in
pipeline pipeline
• Rcvr only sends • Rcvr acks individual
cumulative acks packets
– Doesn’t ack packet if • Sender maintains timer
there’s a gap for each unacked packet
• Sender has timer for – When timer expires,
oldest unacked packet retransmit only unack
– If timer expires, retransmit packet
all unacked packets

Transport Layer 3-55

 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)

Transport Layer 3-56

 Causes/costs of congestion

• one router, finite buffers

• sender retransmission of lost packet

Host A in : original data out

'in : original data, plus

retransmitted data

Host B finite shared output link

buffers

Transport Layer 3-57

 Approaches towards congestion control
Two broad approaches towards congestion control:

End-end congestion Network-assisted

control: congestion control:
• no explicit feedback from • routers provide feedback to
network end systems
• congestion inferred from – single bit indicating
end-system observed loss, congestion (ECN)
delay – explicit rate sender
• approach taken by TCP should send at

Transport Layer 3-58

 TCP Slow Start
• When connection begins,  When connection
CongWin = 1 MSS begins, increase rate
– Example: MSS = 500 bytes exponentially fast until
& RTT = 200 msec first loss event
– initial rate = 20 kbps
• available bandwidth may congestion
window

be >> MSS/RTT 24 K bytes

16 K bytes

8 K bytes

time

Transport Layer 3-59

 TCP Slow Start (more)
• When connection begins, Host A Host B
increase rate
one s e gm
exponentially until first ent

RTT
loss event:
two segm
– double CongWin every en ts
RTT
– done by incrementing
four segm
CongWin for every ACK ents
received
• Summary: initial rate is
slow but ramps up
exponentially fast time

Transport Layer 3-60

TCP additive increase