q Connection establishment (if connection-oriented) q Data transfer q Connection release (if conn-oriented) q Addressing the transport user

(1)

ETH Zürich PPS Internet-Praktikum Transportprotokolle – TCP – 1

The Transport Layer

End-to-End Protocols: UDP and TCP

Layered view of internetworking example

Transport protocol data

Transport service characterization

q

Connection establishment (if connection-oriented)

q

Data transfer

• Reliable (à TCP)

• Unreliable / best effort (à UDP) • Of normal data / prioritized data

• Flow control

• Congestion control

q

Connection release (if conn-oriented)

• By the user

• By the service provider, if problems arise

q

Addressing the transport user

• Who is that anyway?

q

Application programmer’s interface

Problems with connection establishment

t CR Timeout CC CR CC Conn. established ??? A B --> 3-way handshaking CR CR CC A B CR-Connect Request CC-Connect Confirmation Conn. released

(2)

Problems with data transfer

A B duplicate DT1 Timeout DT1 _? DT1 A B DT3 DT2 Sequence error ETH Zürich

Problems with connection release

DTn A B DTn+1 DR Connection released Loss of data ETH Zürich PPS Internet-Praktikum Transportprotokolle – TCP – 7

Connection establishment using the socket API

socket() bind() listen() accept() read() write() socket() connect() write() read() blocked Server-install Conn. established Data (request) Data (response) Handles request t Server Client ETH Zürich

Addressing application processes

Host Internet Router Physical network IP 3 4 UDP Proto=17

AP1 AP2 AP3

37

(3)

Assignment of port numbers

q

Asymmetric c/s model, realized by socket API

q

Passive entity binds to a specific port (bind())

q

Active entity sends a request or established a

connection to the port of the server (connect()).

q

Port numbers may be assigned statically to

applications: entries in a data base mapping ports to

applications (/etc/services).

q

“Well known ports” – globally co-ordinated.

q

Alternatively: dynamic assignment via a directory

service (local or distributed)

Well-known port numbers: /etc/services (extract)

# Note that it is presently the policy of IANA to assign a single well-known # port number for both TCP and UDP; hence, most entries here have two entries # even if the protocol doesn't support UDP operations.

# Updated from RFC 1700, “Assigned Numbers”

echo 7/tcp

echo 7/udp

discard 9/tcp sink null

discard 9/udp sink null

ftp-data 20/tcp

ftp 21/tcp

telnet 23/tcp

smtp 25/tcp mail

time 37/tcp timserver

time 37/udp timserver

nameserver 42/tcp name # IEN 116

whois 43/tcp nicname

domain 53/tcp nameserver # name-domain server

domain 53/udp nameserver

Co-ordination of globally assigned ports

q

Internet Assigned Numbers Authority (IANA,

http://www.iana.org/)

q

Responsible for the assignment of protocol parameters

and constants (port numbers, protocol numbers, ...)

q

Range of ports 0.. 1023: for global "well known" ports,

assigned by IANA

q

Range of ports 1024 .. 65535: Available for dynamic

allocation by processes or static allocation in a private

context

• Registration by IANA is optional

q

Current assignments see

general:

http://www.iana.org/numbers/

port numbers:

http://www.iana.org/assignments/port-numbers

User Datagram Protocol (UDP)

q Connectionless datagram service

• Added functionality (beyond IP datagram)

– application addressing using ports – Error checking

• No specific quality of service mechanisms

q Checksum computed over

• UDP header and payload

• pseudo-header, three fields from the IP header

– protocol number – source IP address – destination IP address – UDP length field (second time)

(4)

Transmission Control Protocol (TCP)

q

Connection-oriented

q

Full-duplex connection

q

Provides a “byte pipe”

• Unstructured byte stream

q

Sliding window protocol

q

Sequence numbers are byte numbers

q

Maximum window size is 2

16

_{bytes (may be}

scaled)

q

Sender window is variable, determined by the

minimum of

• Request of the receiver (receiver window size)

• Estimation of the network load (congestion window size, slow start algorithm)

ETH Zürich

Basic operation of TCP

q

TCP data units are variable length segments; segment

size set at connection setup

q

Each segment has a sequence number, which specifies

its position in the byte stream

q

Segments sent must be acknowledged with in a given

time (based on an adaptive estimation of the round trip

time (RTT))

q

Acknowledgements are sent with delay (appr. 200 ms)

q

Each segment has an end-to-end checksum; segments

with wrong checksum are ignored

q

The receiver sorts received segments according to their

sequence number; duplicates are ignored

Format of a TCP Segment

• Code Bits: URG, ACK, PSH, RST, SYN, FIN

• UrgPtr (urgent pointer): points to the end of urgent data in the packet

Options (variable) Data Checksum SrcPort DstPort HdrLen 0 Flags UrgPtr AdvertisedWindow SequenceNum Acknowledgment 0 4 10 16 31 ETH Zürich

Format of a TCP Segment

• Code Bits: URG, ACK, PSH, RST, SYN, FIN

• UrgPtr (urgent pointer): points to the end of urgent data in the packet

Options (variable) Data Checksum SrcPort DstPort HdrLen 0 Flags UrgPtr AdvertisedWindow SequenceNum Acknowledgment 0 4 10 16 31

(5)

Conn. establishment with 3-way handshaking

q

Initial sequence numbers are “randomly” chosen,

within bounds

q

3-way handshaking needed since IP is unreliable

Last Ack may contain data

Active participant (client)

Passive participant (server)

Sample problem scenarios

old duplicate old duplicate

old duplicate Is rejected ETH Zürich PPS Internet-Praktikum Transportprotokolle – TCP – 19

Release of a TCP connection

q Active entity (left) closes the connection with a segment with FIN flag set q No new data sent from the left, but data from the right entity are still

accepted and acknowledged

q 4-way handshake, each side is closed separately (TCP half close)

Send FIN seq=x recv. ACK Recv. FIN Send ACK x+1 Inform application

recv. FIN + ACK Send ACK y+1

send FIN, ACK x+1

recv. ACK

Finite state machine of

TCP

closed listen syn receiv. fin wait 1 fin wait 2 estab-lished closing timed wait syn sent close wait last ack timeout after 2 segment lifetimes begin anything / reset

passive open _close

active open / syn

send / syn syn / syn + ack

reset

syn / syn + ack

ack close / fin close / fin fin / ack ack / ack / fin / ack fin-ack / ack ack / close / timeout / reset fin / ack close / fin syn + ack / ack

Client

(6)

Finite state machine of

TCP

aus: D. Comer: Internetworking with TCP/IP, Volume 1, Prentice Hall, 1995, p. 220

closed listen syn receiv. fin wait 1 fin wait 2 estab-lished closing timed wait syn sent close wait last ack timeout after 2 segment lifetimes begin anything / reset

passive open _close

active open / syn

send / syn syn / syn + ack

reset

syn / syn + ack

ack close / fin close / fin fin / ack ack / ack / fin / ack fin-ack / ack ack / close / timeout / reset fin / ack close / fin syn + ack / ack

Server

ETH Zürich

Connections and connection end-points

A TCP connection is identified by a 4-tuple

• IP-address and port number of host A (A:P

_A

)

• IP-address and port number of host B (B:P

_B

)

à

More than one TCP-connection may be established

between the same two hosts

à

An IP packet belongs to a specific TCP connection

if the 4 values match and if the IP protocol field has

the value of TCP

Example

Host A (client machine) Host B (server machine) Daemon (tcp, *, 23) Server 1 (tcp, B, 23) Server 2 (tcp, B, 23) Client 1 (tcp, A:1055) Client 2 (tcp, A:1056) (tcp, A, 1055, B, 23) (tcp, A, 1056, B, 23) fork

mechanism of setting up two simultaneous TCP connections to the same