Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

CN - Unit4.1

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 50

Computer Network

(KCS-603)
Session 2020-21

Faculty: Tanvi Shree


Course: B.Tech 6th Semester
Department of Information Technology
LECTURE-13

Transport Layer
Transport Layer
The ultimate goal of the transport layer is to provide efficient,
reliable, and cost- effective service to its users, normally
processes in the application layer. To achieve this goal, the
transport layer makes use of the services provided by the network
layer. The hardware and/or software within the transport layer
that does the work is called the transport entity.
Transport Layer
• End to End Delivery
• Addressing
• Reliable Delivery:
– Error Control
– Sequence Control
– Loss Control
– Duplication Control
• Flow Control
• Multiplexing
Position of transport layer
Services Provided to the Upper Layers
The bottom four layers can be seen as the transport service
provider, whereas the upper layer(s) are the transport service
user.

To allow users to access the transport service, the transport


layer must provide some operations to application programs, that
is, a transport service interface. Each transport service has its own
interface.

The transport service is similar to the network service, but there


are also some important differences. The main difference is that
the network service is intended to model the service offered by
real networks, warts and all. Real networks can lose packets, so
the network service is generally unreliable. The (connection-
oriented) transport service, in contrast, is reliable.
PROCESS-TO-PROCESS DELIVERY

Process-to-process delivery
The transport layer is responsible for process-to- process
delivery—the delivery of a packet, part of a message, from
one process to another. Two processes communicate in a
client/server relationship.

Port numbers
IP addresses versus port numbers
The TCP Protocol
• Every byte on a TCP connection has its own 32-bit sequence
number.
• The sending and receiving TCP entities exchange data in the
form of segments. A TCP segment consists of a fixed 20-byte
header (plus an optional part) followed by zero or more data
bytes. The TCP software decides how big segments should be.

• Two limits restrict the segment size. First, each segment,


including the TCP header, must fit in the 65,515-byte IP
payload. Second, each network has a maximum transfer unit,
or MTU, and each segment must fit in the MTU
The TCP Protocol properties
• Connection oriented
• Full Duplex
• Piggybacking: Piggybacking is a process of attaching
acknowledgment with the data packet to be sent. It is an
efficient solution for reducing the bandwidth utilization of the
network.
• Bytestreaming: TCP is a byte-oriented protocol, which means
that the sender writes bytes into a TCP connection and the
receiver reads bytes out of the TCP connection.
• Error Control
• Flow Control
• Congestion Control
TCP segment format
• The Source port and Destination port fields identify the local
end points of the connection. A port plus its host's IP address
forms a 48-bit unique end point. The source and destination
end points together identify the connection.
• This connection identifier is called a 5 tuple because it consists
of five pieces of information: the protocol (TCP), source, IP and
source port, and destination IP and destination port.
• The Sequence number and Acknowledgement number fields
perform their usual functions. The latter specifies the next byte
expected, not the last byte correctly received. Both are 32 bits
long because every byte of data is numbered in a TCP stream.
• The TCP header length tells how many 32-bit words are
contained in the TCP header.
• Next comes a 6-bit field that is not used.
• URG is set to 1 if the Urgent pointer is in use. The Urgent
pointer is used to indicate a byte offset from the current
sequence number at which urgent data are to be found.

• The ACK bit is set to 1 to indicate that the Acknowledgement


number is valid.
• The PSH bit indicates PUSHed data. The receiver is hereby
kindly requested to deliver the data to the application upon
arrival and not buffer it until a full buffer has been received.

• The RST bit is used to abruptly reset a connection that has


become confused due to a host crash or some other reason.

• The SYN bit is used to establish connections. The connection


request has SYN = 1 and ACK = 0. The connection reply does
bear an acknowledgement, however, so it has SYN = 1 and
ACK = 1.
• The FIN bit is used to release a connection. It specifies that
the sender has no more data to transmit.
• Flow control in TCP is handled using a variable-sized sliding
window. The Window size field tells how many bytes may be
sent starting at the byte acknowledged.
• A Checksum is also provided for extra reliability. It checksums
the header, the data, and a conceptual pseudo header in
exactly the same way as UDP.
• The Options field provides a way to add extra facilities not
covered by the regular header. Many options have been
defined and several are commonly used.
– A widely used option is the one that allows each host to specify the
MSS (Maximum Segment Size) it is willing to accept.
– The timestamp option carries a timestamp sent by the sender and
echoed by the receiver.
– The SACK (Selective ACKnowledgement) option lets a receiver tell a
sender the ranges of sequence numbers that it has received
What is a TCP port?
• The TCP port is a unique number assigned to different
applications. For example, if opened the email and games
applications on our computer; through email application, we
want to send the mail to the host, and through games
application, we want to play the online games. In order to do all
these tasks, different unique numbers are assigned to these
applications. Each protocol and address have a port known as a
port number. The TCP (Transmission Control Protocol) and UDP
(User Datagram Protocol) protocols mainly use the port
numbers.
• A port number is a unique identifier used with an IP address. A
port is a 16-bit unsigned integer, and the total number of ports
available in the TCP/IP model is 65,535 ports. Therefore, the
range of port numbers is 0 to 65535. In the case of TCP, the
zero-port number is reserved and cannot be used,
What is a TCP port?
• whereas, in UDP, the zero port is not available. IANA (Internet
Assigned Numbers Authority) is a standard body that assigns
the port numbers.
• 192.168.1.100: 7
• In the above case, 192.168.1.100 is an IP address, and 7 is a
port number.
Classification of port numbers
The port numbers are divided into three categories:
• Well-known ports
• Registered ports
• Dynamic ports
What is a TCP port?

Well-known ports
The range of well-known port is 0 to 1023. The well-known ports
are used with those protocols that serve common applications and
services such as HTTP (hypertext transfer protocol), IMAP
(Internet Message Access Protocol), SMTP (Simple Mail Transfer
Protocol), etc. For example, we want to visit some websites on an
internet; then, we use http protocol; the http is available with a port
number 80, which means that when we use http protocol with an
application then it gets port number 80. Similarly, with other
protocols such as SMTP, IMAP; well-known ports are defined. The
remaining port numbers are used for random applications.
What is a TCP port?
Registered ports
The range of registered port is 1024 to 49151. The registered
ports are used for the user processes. These processes are
individual applications rather than the common applications that
have a well-known port.
Dynamic ports
The range of dynamic port is 49152 to 65535. Another name of
the dynamic port is ephemeral ports. These port numbers are
assigned to the client application dynamically when a client
creates a connection. The dynamic port is identified when the
client initiates the connection, whereas the client knows the
well-known port prior to the connection. This port is not known
to the client when the client connects to the service.
TCP Connection Establishment
• Connections are established in TCP by means of the three-way
handshake. To establish a connection, one side(server) passively
waits for an incoming connection by executing the LISTEN and
ACCEPT primitives.
• The other side, say, the client, executes a CONNECT primitive,
specifying the IP address and port to which it wants to connect,
the maximum TCP segment size it is willing to accept, and
optionally some user data (e.g., a password). The CONNECT
primitive sends a TCP segment with the SYN bit on and ACK bit
off and waits for a response.
• When this segment arrives at the destination, the TCP entity
there checks to see if there is a process that has done a LISTEN
on the port given in the Destination port field. If not, it sends a
reply with the RST bit on to reject the connection.
UDP
• The User Datagram Protocol (UDP) is a transport layer
protocol defined for use with the IP network layer protocol. It is
defined by RFC 768 written by John Postel. It provides a best-
effort datagram service to an End System (IP host).

The service provided by UDP is an unreliable service that provides


no guarantees for delivery and no protection from
duplication.

The simplicity of UDP reduces the overhead from using the


protocol and the services may be adequate in many cases.

UDP provides a minimal, unreliable, best-effort, message-passing


transport to applications and upper- layer protocols
Introduction to UDP
The Internet protocol suite supports a connectionless transport protocol, UDP (User
Datagram Protocol).
The UDP header.

UDP provides a way for applications to send encapsulated IP


datagrams and send them without having to establish a
connection. UDP is described in RFC 768.

UDP transmits segments consisting of an 8-byte header followed


by the payload. The two ports serve to identify the end points
within the source and destination machines. When a UDP
packet arrives, its payload is handed to the process attached to
the destination port.
The source port is primarily needed when a reply must be sent
back to the source. The UDP length field includes the 8-byte
header and the data.

UDP Checksum (A checksum to verify that the end to end data


has not been corrupted by routers or bridges in the network or
by the processing in an end system. The algorithm to compute
the checksum is the Standard Internet Checksum algorithm.
This allows the receiver to verify that it was the intended
destination of the packet, because it covers the IP addresses, port
numbers and protocol number, and it verifies that the packet is
not truncated or padded, because it covers the size field.
Therefore, this protects an application against receiving
corrupted payload data in place of, or in addition to, the data that
was sent. In the cases where this check is not required, the value
of 0x0000 is placed in this field, in which case the data is not
checked by the receiver.
initial connection protocol

Instead of every conceivable server listening at a well-known TSAP,


each machine that wishes to offer services to remote users has a
special process server that acts as a proxy for less heavily used
servers. It listens to a set of ports at the same time, waiting for a
connection request. This server is called inetd on UNIX system.
TCP Connection Management
There are three steps:
1. Connection establishment
2. Data Transfer
3. Connection Release
Connection Establishment
CR = Connection
Normal Procedure Request
H1 choses initial s# x

H2 replies

 ACKs x

 announce own s# y

H1replies

 ACKs y

 with 1st data segment


Connection Establishment
Abnormal situations
Delayed duplicate CR

 H2 sends ACK to H1
 H1 rejects X
 H2 knows it was tricked
 Worst case
• DD CR, old ACK floating
 H2 gets delayed CR, replies

 H1 rejects
X
 H2 gets old DATA, discards
X
• (z received instead of y)
Connection Release
 Easier than establish
 However, some pitfalls

 Asymmetric release
 the way telephone works

 1 party hangs up, con broken

 abrupt; may cause data loss

 better protocol needed


Connection Release
Four protocol scenarios for releasing
a connection. (a) Normal case of a three-
way
handshake. (b) final ACK lost.

6-14, a, b

Four protocol scenarios for releasing a connection.


(a) Normal case of a three-way handshake. (b) final
ACK lost.
Connection Release
Symmetric release
Each direction is released independently

Can receive data after sending DISCONNECT

H1: I am done, are you done too?

H2: I am done too, goodbye

Two-army problem: unreliable channel


Connection Release
 Two-army problem
 each blue army < white army, but together are
larger
 need to sync attack
 however, only com channel is the valley (unreliable)
 3-way handshake? B1 can’t know ACK arrived
 making 4-way handshake doesn’t help either
Attack? Attack?
• So now, the above picture represents the two army problems
while sending and receiving the data, actually, here the
synchronizations are there between Blue Army 1 and Blue
Army 2, which will attach White Army by synchronizations.
• But there were several issues that are raised when they
attack the white army like, how they will synchronize
together?
• The blue armies want to synchronize their attacks. However,
their only communication medium is to send messengers on
foot down into the valley, where they might be captured and
the message lost. (i.e., they have to use an unreliable
communication channel). The question is: Does a protocol
exist that allows the blue armies to win?
Suppose that the commander of blue army #1 sends a
message reading: ''I propose we attack at dawn on March 29.
How about it?'' Now suppose that the message arrives, the
commander of blue army #2 agrees, and his reply gets safely
back to blue army #1. Will the attack happen? Probably not,
because commander #2 does not know if his reply got
through.
If it did not, blue army #1 will not attack, so it would be foolish
for him to charge into battle. Now let us improve the protocol
by making it a three-way handshake. The initiator of the
original proposal must acknowledge the response. Assuming
no messages are lost, blue army #2 will get the
acknowledgement, but the commander of blue army #1 will
now hesitate. After all, he does not know if his
acknowledgement got through, and if it did not, he knows
that blue army #2 will not attack. We could now make a four-
way handshake protocol, but that does not help either.
Connection Release
 Let each side independently decide its done
 Easier to solve

Normal release sequence


 H1 send DR, start timer

 H2 responds with DR

 when H1 recv DR, release

 when H2 recv ACK, release

36
Connection Release

6-14, c,d

(c) Response lost. (d) Response lost and subsequent DRs


lost.
Three way handshaking
• The two army problems rises when intermediate nodes and connections need to established between two or more
servers, PC, and nodes while transferring the data with synchronized attack between the nodes.
Now understand the data transfer and delivery that follow two army problems.


Flow Control and Buffering

(a) Chained fixed-size buffers. (b) Chained variable-sized


buffers.
(c) One large circular buffer per connection.
• The optimum trade-off between source buffering and
destination buffering depends on the type of traffic carried by
the connection. For low-bandwidth bursty traffic, such as that
produced by an interactive terminal the sender must retain a
copy of the TPDU until it is acknowledged.

• On the other hand, for file transfer and other high-bandwidth


traffic, it is better if the receiver does dedicate a full window of
buffers, to allow the data to flow at maximum speed.

• Thus, for low-bandwidth bursty traffic, it is better to buffer at


the sender, and for high bandwidth smooth traffic, it is better
to buffer at the receiver.
Crash Recovery
The host & routers are subject to crash, recovery from these
crashes.
In case of Router Crash
The two transport entities must exchange information after
crash to determine which TPDU were received and which were not.
The crash can be recovered by transmitting the lost one’s .
Loss of a virtual ckt
If n/w layer provide connection oriented service then crash
of virtual ckt can be handled by establish a new virtual ckt.
Multiplexing

If only one network address is available on a host, all transport


connections on that machine have to use it. When a TPDU comes
in, some way is needed to tell which process to give it to. This
situation is called upward multiplexing.
Multiplexing
Multiplexing can also be useful in the transport layer for another
reason. Suppose, for example, that a subnet uses virtual circuits
internally and imposes a maximum data rate on each one. If a user
needs more bandwidth than one virtual circuit can provide, a way
out is to open multiple network connections and distribute the
traffic among them on a round-robin basis, called downward
multiplexing.
Multiplexing and de multiplexing

Dr. Prasanna Singh CN Unit-4


05/03/23 44
CSBS
Position of UDP, TCP, and SCTP in TCP/IP suite
Remote Procedure Call
Remote Procedure Call is a software communication protocol that one
program can use to request a service from a program located in
another computer on a network without having to understand the
network's details.
RPC is used to call other processes on the remote systems like a local
system. A procedure call is also sometimes known as a function call or
a subroutine call.
RPC uses the client-server model. The requesting program is
a client, and the service-providing program is the server. Like a local
procedure call, an RPC is a synchronous operation requiring the
requesting program to be suspended until the results of the remote
procedure are returned. However, the use of lightweight
processes or threads that share the same address space enables
multiple RPCs to be performed concurrently.
Working of Remote Procedure Call
The following steps take place during a RPC : 
1.A client invokes a client stub procedure, passing parameters in the
usual way. The client stub resides within the client’s own address
space. 
2.The client stub marshalls(pack) the parameters into a message.
Marshalling includes converting the representation of the parameters
into a standard format, and copying each parameter into the
message. 
3.The client stub passes the message to the transport layer, which
sends it to the remote server machine. 
4.On the server, the transport layer passes the message to a server
stub, which demarshalls(unpack) the parameters and calls the
desired server routine using the regular procedure call mechanism. 
Working of Remote Procedure Call

Working of Remote Procedure Call

5. When the server procedure completes, it returns to the server
stub (e.g., via a normal procedure call return), which marshalls the
return values into a message. The server stub then hands the message
to the transport layer. 
6.The transport layer sends the result message back to the
client transport layer, which hands the message back to the client stub. 
7.The client stub demarshalls the return parameters and
execution returns to the caller.

You might also like