Transportation Layer (1)
Download
Report
Transcript Transportation Layer (1)
Transportation Layer (1)
Transportation Layer
• Very similar to the data link layer.
– two hosts connected by a link or two hosts connected by a
network
• differences:
– When two hosts are connected by a link, packets will not
reorder or duplicate (if the sender sends only once). In
addition, packets will either get to the receiver or get lost.
– When two hosts are connected by a network, packets can
be duplicated, delayed, lost, reordered.
– Implication: The problems to be addressed in the transport
layer are very similar to those in the data link layer.
However, the solutions may be more complex.
• The transport layer issues: service interface,
addressing, connection management, error control,
flow control
• Service interface
– connection-oriented and connectionless.
– similar to the network layer. Why one more layer?
• network layer -- part of the communication subnet, run
by carrier. can't be changed.
• transport layer -- put one more layer on the hosts to get
the services needed
• potential problem: may do the same thing two times,
which can decrease the communication performance.
– Addressing
• Link: want to transfer data to Ethernet card 08.00.2b.2a.83.62
• Network: want to transfer data to IP host 128.2.222.85
• Transport: which entity you will try to address?
– want to talk to one process on host 128.2.222.85.
– what to do use? process ID? how many bits? What would
be the problem when using the pid as transport layer
identifier?
– Abstraction: port number
Connection management
• The problem is that network can delay, reorder,
lose packets
– Time-out/retransmission introduces duplicates of
data, acknowledgement, connect, close packets
• Worst case scenario: consider this bank transaction
example
–
–
–
–
(a) setup connection
(b) transfer $100
(c) close connection
all messages are delayed and replayed.
Solution 1
• assign a connection-id to each connection, the
receiver keeps track what connections have
been terminated.
– How many connection-ids to keep?
– What if receiver crashs and comes back again? It
forgets what connections have been established?
Choosing Unique Identifier
• On packet arrival: is it real or old?
– New connection request/release or an old one?
Remember that there is no restriction on reusing
the port number.
• Unique ID for each TPDU
– How to choose an identifier for each TPDU such
that it is impossible for other TPDU currently in
the network associated with this host to have the
same identifier.
Choosing Unique Identifier
• When a connection
is set up, choose a
initial sequence
number by taking
the lower bits of a
local clock.
• Each TPDU is given
a seq. number. With
each TPDU sent, the
seq. number
increases.
Choosing Unique Identifier
• The clock has
finite bits and
will wrap
around
These
TPDU May
still be
around
Choosing Unique Identifier
• There is a
maximum
lifetime (T) for a
TPDU.
• Forbidden
region. When
the clock is x,
don’t send
TPDUs with seq.
number from x
to x+2T.
Forbidden
region
2T
Connection setup -- Three-Way
Handshake
• Connection initiator (the client)
– Chooses unique seqno x and sends req-conn(x)
• Connection respondent (the server)
– Upon receiving req-conn(x)
• Chooses its own unique identifier, y
• Sends ack-conn(y,x)
• Upon receiving ack-conn(y,x), client responds
– With ack-conn(x+1,y)
Three-way handshake
Three-way handshake
Old message
client
Ignore or
reject
server
Threeway handshake
Old message
client
Ignore or
reject
server
Close a connection
• Reaching agreement: two approaches
– Abort: send close msg to peer, delete state info
• What if close() message lost?
– Graceful: send close msg, but before deleting state
• Wait for peer to acknowledge close()
• Problem solved?
– Can I decide to close, knowing that
• Other entity also agreed to close and knows that I will close
• Can two armies coordinate their attacks
– If communication is unreliable?
Two army problem