COMPUTER NETWORKS

UNIT – 5
SYLLABUS: The Transport Layer: Transport layer protocols: Introduction-services-
port number-User
data gram protocol-User datagram-UDP services-UDP applications-Transmission control
protocol: TCP
services- TCP features- Segment- A TCP connection- windows in TCP- flow control-
Error control,
Congestion control in TCP.
Application Layer - World Wide Web: HTTP, Electronic mail-Architecture- web based
mail- email
security- TELENET-local versus remote Logging-Domain Name System: Name Space, DNS
in Internet
- Resolution-Caching- Resource Records- DNS messages- Registrars-security of DNS
Name Servers,
SNMP.
5.1 Transport layer services:
5.1.1 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.
The data link layer is responsible for delivery of frames between two neighboring
nodes over a
link. This is called node-to-node delivery. The network layer is responsible for
delivery of datagrams
between two hosts. This is called host-to-host delivery. Communication on the
Internet is not defined as
the exchange of data between two nodes or between two hosts. Real communication
takes place between
two processes (application programs). We need process-to-process delivery. However,
at any moment,
several processes may be running on the source host and several on the destination
host. To complete the
delivery, we need a mechanism to deliver data from one of these processes running
on the source host to
the corresponding process running on the destination host.
5.1.2 PORT NUMBERS:
At the network layer, we need an IP address to choose one host among millions. A
datagram in the
network layer needs a destination IP address for delivery and a source IP address
for the destination's
reply.
At the transport layer, we need a transport layer address, called a port number, to
choose among
multiple processes running on the destination host. The destination port number is
needed for delivery;
the source port number is needed for the reply.
In the Internet model, the port numbers are 16-bit integers between 0 and 65,535.
The client
program defines itself with a port number, chosen randomly by the transport layer
software running on
the client host. This is the ephemeral port number.
Socket Addresses
Process-to-process delivery needs two identifiers, IP address and the port number,
at each end to
make a connection. The combination of an IP address and a port number is called a
socket address. The
client socket address defines the client process uniquely just as the server socket
address defines the server
process uniquely.
A transport layer protocol needs a pair of socket addresses: the client socket
address and the server
socket address. These four pieces of information are part of the IP header and the
transport layer protocol
header. The IP header contains the IP addresses; the UDP or TCP header contains the
port numbers.
5.1.3 MULTIPLEXING AND DEMULTIPLEXING
Multiplexing
At the sender site, there may be several processes that need to send packets.
However, there is only
one transport layer protocol at any time. This is a many-to-one relationship and
requires multiplexing. The
protocol accepts messages from different processes, differentiated by their
assigned port numbers. After
adding the header, the transport layer passes the packet to the network layer.
Demultiplexing
At the receiver site, the relationship is one-to-many and requires demultiplexing.
The transport
layer receives datagrams from the network layer. After error checking and dropping
of the header, the
transport layer delivers each message to the appropriate process based on the port
number.
5.1.4 CONNECTIONLESS VERSUS CONNECTION-ORIENTED SERVICE
A transport layer protocol can either be connectionless or connection-oriented.
Connectionless Service
In a connectionless service, the packets are sent from one party to another with no
need for
connection establishment or connection release. The packets are not numbered; they
may be delayed
or lost or may arrive out of sequence. There is no acknowledgment either. We will
see shortly that one
of the transport layer protocols in the Internet model, UDP, is connectionless.
Connection Oriented Service
In a connection-oriented service, a connection is first established between the
sender and the
receiver. Data are transferred. At the end, the connection is released. We will see
shortly that TCP and
SCTP are connection-oriented protocols.
5.1.5 RELIABLE VERSUS UNRELIABLE
The transport layer service can be reliable or unreliable. If the application layer
program needs
reliability, we use a reliable transport layer protocol by implementing flow and
error control at the
transport layer. This means a slower and more complex service. On the other hand,
if the application
program does not need reliability because it uses its own flow and error control
mechanism or it needs
fast service or the nature of the service does not demand flow and error control
(real-time applications),
then an unreliable protocol can be used.
In the Internet, there are three common different transport layer protocols, as we
have already
mentioned. UDP is connectionless and unreliable; TCP and SCTP are connection
oriented and reliable.
These three can respond to the demands of the application layer programs.
5.2 USER DATAGRAM PROTOCOL (UDP)
The User Datagram Protocol (UDP) is called a connectionless, unreliable transport
protocol. It
does not add anything to the services of IP except to provide process-to-process
communication
instead of host-to-host communication. Also, it performs very limited error
checking.
5.2.1 Well-Known Ports for UDP
Below table shows some well-known port numbers used by UDP. Some port numbers can
be used
by both UDP and TCP.
5.2.2 User Datagram
UDP packets, called user datagrams, have a fixed-size header of 8 bytes. Below
Figure shows the
format of a user datagram.
The fields are as follows:
‹ Source port number. This is the port number used by the process running on the
source host. It is 16
bits long, which means that the port number can range from 0 to 65,535. If the
source host is the client
(a client sending a request), the port number, in most cases, is an ephemeral port
number requested by
the process and chosen by the UDP software running on the source host. If the
source host is the server
(a server Sending a response), the port number, in most cases, is a well-known port
number.
‹ Destination port number. This is the port number used by the process running on
the destination
host. It is also 16 bits long. If the destination host is the server (a client
sending a request), the port
number, in most cases, is a well-known port number. If the destination host is the
client (a server
sending a response), the port number, in most cases, is an ephemeral port number.
In this case, the
server copies the ephemeral port number it has received in the request packet.
‹ Length. This is a 16-bit field that defines the total length of the user
datagram, header plus data. The
16 bits can define a total length of 0 to 65,535 bytes. However, the total length
needs to be much less
because a UDP user datagram is stored in an IP datagram with a total length of
65,535 bytes.
‹ Checksum. This field is used to detect errors over the entire user datagram
(header plus data). The
checksum is discussed next.
5.2.3 UDP Operation (Services)
UDP uses concepts common to the transport layer. These concepts will be discussed
here briefly, and
then expanded in the next section on the TCP protocol.
1. Connectionless Services
As mentioned previously, UDP provides a connectionless service. This means that
each user
datagram sent by UDP is an independent datagram. There is no relationship between
the different user
datagrams even if they are coming from the same source process and going to the
same destination
program. The user datagrams are not numbered. Also, there is no connection
establishment and no
connection termination, as is the case for TCP. This means that each user datagram
can travel on a
different path.
2. Flow and Error Control
UDP is a very simple, unreliable transport protocol. There is no flow control and
hence no window
mechanism. The receiver may overflow with incoming messages. There is no error
control mechanism
in UDP except for the checksum. This means that the sender does not know if a
message has been lost
or duplicated. When the receiver detects an error through the checksum, the user
datagram is silently
discarded. The lack of flow control and error control means that the process using
UDP should provide
these mechanisms.
3. Encapsulation and Decapsulation
To send a message from one process to another, the UDP protocol encapsulates and
decapsulates
messages in an IP datagram.
4. Queuing
We have talked about ports without discussing the actual implementation of them.
InUDP,
queues are associated with ports.
At the client site, when a process starts, it requests a port number from the
operating system. Some
implementations create both an incoming and an outgoing queue associated with each
process. Other
implementations create only an incoming queue associated with each process.
Note that even if a process wants to communicate with multiple processes, it
obtains only one port
number and eventually one outgoing and one incoming queue. The queues opened by the
client are, in
most cases, identified by ephemeral port numbers. The queues function as long as
the process is
running. When the process terminates, the queues are destroyed.
The client process can send messages to the outgoing queue by using the source port
number
specified in the request. UDP removes the messages one by one and, after adding the
UDP header,
delivers them to IP. An outgoing queue can overflow. If this happens, the operating
system can ask the
client process to wait before sending any more messages.
5.2.4 UDP applications
The following lists some uses of the UDP protocol:
‹ UDP is suitable for a process that requires simple request-response communication
with little
concern for flow and error control. It is not usually used for a process such as
FTP that needs
to send bulk data.
‹ UDP is suitable for a process with internal flow and error control mechanisms.
For example,
the Trivial File Transfer Protocol (TFTP) process includes flow and error control.
It can easily
use UDP.
‹ UDP is a suitable transport protocol for multicasting. Multicasting capability is
embedded in
the UDP software but not in the TCP software.
‹ UDP is used for management processes such as SNMP.
‹ UDP is used for some route updating protocols such as Routing Information
Protocol (RIP).
The Web page is stored at the server. Each time a client request arrives, the
corresponding
document is sent to the client. To improve efficiency, servers normally store
requested files in a cache
in memory; memory is faster to access than disk.
5.4.4 Uniform Resource Locator
A client that wants to access a Web page needs the address. To facilitate the
access of documents
distributed throughout the world, HTTP uses locators. The uniform resource locator
(URL) is a
standard for specifying any kind of information on the Internet. The URL defines
four things: protocol,
host computer, port, and path
The protocol is the client/server program used to retrieve the document. Many
different protocols
can retrieve a document; among them are FTP or HTTP. The most common today is HTTP.
The host is the computer on which the information is located, although the name of
the computer
can be an alias. Web pages are usually stored in computers, and computers are given
alias names that
usually begin with the characters "www". This is not mandatory, however, as the
host can be any name
given to the computer that hosts the Web page.
The URL can optionally contain the port number of the server. If the port is
included, it is inserted
between the host and the path, and it is separated from the host by a colon.
Path is the pathname of the file where the information is located. Note that the
path can itself
contain slashes that, in the UNIX operating system, separate the directories from
the subdirectories
and files.
5.5 HYPERTEXT TRANSFER PROTOCOL (HTTP)
The Hypertext Transfer Protocol (HTTP) is a protocol used mainly to access data on
the World
Wide Web. HTTP functions as a combination of FTP and SMTP. HTTP uses the services
of TCP on
well-known port 80.
5.5.1 HTTP Transaction
Below figure illustrates the HTTP transaction between the client and server.
Although HTTP uses
the services of TCP, HTTP itself is a stateless protocol. The client initializes
the transaction by sending
a request message. The server replies by sending a response.
5.5.2 HTTP Messages
The formats of the request and response messages are similar; both are shown in
below figure. A
request message consists of a request line, a header, and sometimes a body. A
response message
consists of a status line, a header, and sometimes a body.
Request and Status Lines. The first line in a request message is called a request
line; the first line in
the response message is called the status line. There is one common field, as shown
in below figure.
Request type. This field is used in the request message. In version 1.1 of HTTP,
several request types
are defined. The request type is categorized into methods as defined in below
table.
URL. The uniform resource locator (URL) is a standard for specifying any kind of
information
on the Internet..
Version. The most current version of HTTP is 1.1.
Status code. This field is used in the response message. The status code field is
similar to those
in the FTP and the SMTP protocols. It consists of three digits. Whereas the codes
in the 100
range are only informational, the codes in the 200 range indicate a successful
request.
Status phrase. This field is used in the response message. It explains the status
code in text form.
Header The header exchanges additional information between the client and the
server. For example,
the client can request that the document be sent in a special format, or the server
can send extra
information about the document. The header can consist of one or more header lines.
Each header line
has a header name, a colon, a space, and a header value.
A header line belongs to one of four categories: general header, request header,
response header,
and entity header.
General header The general header gives general information about the message and
can be
present in both a request and a response. Below table lists some general headers
with their
descriptions.
Request header The request header can be present only in a request message. It
specifies the
client's configuration and the client's preferred document format. See below Table
for a list of some
request headers and their descriptions.
Response header The response header can be present only in a response message. It
specifies the
server's configuration and special information about the request. See below Table
for a list of some
response headers with their descriptions.
Entity header The entity header gives information about the body of the document.
Although it
is mostly present in response messages, some request messages, such as POST or PUT
methods,
that contain a body also use this type of header. See below Table for a list of
some entity headers
and their descriptions.
5.6 ELECTRONIC MAIL
One of the most popular Internet services is electronic mail (e-mail). At the
beginning of the
Internet era, the messages sent by electronic mail were short and consisted of text
only; they let people
exchange quick memos. Today, electronic mail is much more complex. It allows a
message to include
text, audio, and video. It also allows one message to be sent to one or more
recipients.
5.6.1 Architecture
1. First Scenario
In the first scenario, the sender and the receiver of the e-mail are users (or
application programs)
on the same system; they are directly connected to a shared system. The
administrator has created one
mailbox for each user where the received messages are stored. A mailbox is part of
a local hard drive,
a special file with permission restrictions. Only the owner of the mailbox has
access to it. When Alice,
a user, needs to send a message to Bob, another user, Alice runs a user agent (UA)
program to prepare
the message and store it in Bob's mailbox. The message has the sender and recipient
mailbox addresses
(names of files). Bob can retrieve and read the contents of his mailbox at his
convenience, using a user
agent.
2. Second Scenario
In the second scenario, the sender and the receiver of the e-mail are users (or
application programs)
on two different systems. The message needs to be sent over the Internet. Here we
need user agents
(UAs) and message transfer agents (MTAs).
Alice needs to use a user agent program to send her message to the system at her
own site. The
system (sometimes called the mail server) at her site uses a queue to store
messages waiting to be sent.
Bob also needs a user agent program to retrieve messages stored in the mailbox of
the system at his
site. The message, however, needs to be sent through the Internet from Alice's site
to Bob's site. Here
two message transfer agents are needed: one 'client and one server. Like most
client/server programs
on the Internet, the server needs to run all the time because it does not know when
a client will ask for
a connection. The client, on the other hand, can be alerted by the system when
there is a message in
the queue to be sent.
3. Third Scenario
In the third scenario, Bob, as in the second scenario, is directly connected to his
system. Alice,
however, is separated from her system. Either Alice is connected to the system via
a point-to-point
WAN, such as a dial-up modem, a DSL, or a cable modem; or she is connected to a LAN
in an
organization that uses one mail server for handling e-mails-all users need to send
their messages to
this mail server.
Alice still needs a user agent to prepare her message. She then needs to send the
message through
the LAN or WAN. This can be done through a pair of message transfer agents (client
and server).
Whenever Alice has a message to send, she calls the user agent which, in tum, calls
the MTA client.
The MTA client establishes a connection with the MTA server on the system, which is
running all the
time. The system at Alice's site queues all messages received. It then uses an MTA
client to send the
messages to the system at Bob's site; the system receives the message and stores it
in Bob's mailbox.
At his convenience, Bob uses his user agent to retrieve the message and reads it.
Note that we need
two pairs of MTA client/server programs.
4. Fourth Scenario
In the fourth and most common scenario, Bob is also connected to his mail server by
a WAN or a
LAN. After the message has arrived at Bob's mail server, Bob needs to retrieve it.
Here, we need
another set of client/server agents, which we call message access agents (MAAs).
Bob uses an MAA
client to retrieve his messages. The client sends a request to the MAA server,
which is running all the
time, and requests the transfer of the messages.
There are two important points here. First, Bob cannot bypass the mail server and
use the MTA
server directly. To use MTA server directly, Bob would need to run the MTA server
all the time
because he does not know when a message will arrive. This implies that Bob must
keep his computer
on all the time if he is connected to his system through a LAN. If he is connected
through a-WAN, he
must keep the connection up all the time. Neither of these situations is feasible
today.
Second, note that Bob needs another pair of client/server programs: message access
programs. This
is so because an MTA client/server program is a push program: the client pushes the
message to the
server. Bob needs a pull program. The client needs to pull the message from the
server.