Basic requirements of protocols

Messages are sent and received on communicating systems to establish communications. Protocols should
therefore specify rules governing the transmission. In general, much of the following should be addressed:
Data formats for data exchange. Digital message bit-strings are exchanged. The bit-strings are
divided in fields and each field carries information relevant to the protocol. Conceptually the bitstring is divided into two parts called the header area and the data area. The actual message is
stored in the data area, so the header area contains the fields with more relevance to the protocol.
Bit-strings longer than the maximum transmission unit (MTU) are divided in pieces of appropriate
size.
Address formats for data exchange. Addresses are used to identify both the sender and the
intended receiver(s). The addresses are stored in the header area of the bit-strings, allowing the
receivers to determine whether the bit-strings are intended for themselves and should be
processed or should be ignored. A connection between a sender and a receiver can be identified
using an address pair (sender address, receiver address). Usually some address values have special
meanings. An all-1s address could be taken to mean an addressing of all stations on the network, so
sending to this address would result in a broadcast on the local network. The rules describing the
meanings of the address value are collectively called an addressing scheme.
Address mapping. Sometimes protocols need to map addresses of one scheme on addresses of
another scheme. For instance to translate a logical IP address specified by the application to an
Ethernet hardware address. This is referred to as address mapping.
Routing. When systems are not directly connected, intermediary systems along the route to the
intended receiver(s) need to forward messages on behalf of the sender. On the Internet, the
networks are connected using routers. This way of connecting networks is called internetworking.
Detection of transmission errors is necessary on networks which cannot guarantee error-free
operation. In a common approach, CRCs of the data area are added to the end of packets, making it
possible for the receiver to detect differences caused by errors. The receiver rejects the packets on
CRC differences and arranges somehow for retransmission.
Acknowledgements of correct reception of packet are required for connection-oriented
communication. Acknowledgements are sent from receivers back to their respective senders.
Loss of information - timeouts and retries. Packets may be lost on the network or suffer from long
delays. To cope with this, under some protocols, a sender may expect an acknowledgement of
correct reception from the receiver within a certain amount of time. On timeouts, the sender must
assume the packet was not received and retransmit it. In case of a permanently broken link, the
retransmission has no effect so the number of retransmissions is limited. Exceeding the retry limit is
considered an error.
Direction of information flow needs to be addressed if transmissions can only occur in one
direction at a time as on half-duplex links. This is known as Media Access Control. Arrangements
have to be made to accommodate the case when two parties want to gain control at the same
time.
Sequence control. We have seen that long bit-strings are divided in pieces, and then sent on the
network individually. The pieces may get lost or delayed or take different routes to their destination
on some types of networks. As a result pieces may arrive out of sequence. Retransmissions can
result duplicate pieces. By marking the pieces with sequence information at the sender, the
receiver can determine what was lost or duplicated, ask for necessary retransmissions and
reassemble the original message.
Flow control is needed when the sender transmits faster than the receiver or intermediate network
equipment can process the transmissions. Flow control can be implemented by messaging from
receiver to sender.
Getting the data across a network is only part of the problem for a protocol. The data received has to be
evaluated in the context of the progress of the conversation, so a protocol has to specify rules describing
the context. These kinds of rules are said to express the syntax of the communications. Other rules

determine whether the data is meaningful for the context in which the exchange takes place. These kinds of
rules are said to express the semantics of the communications.
Following protocols are commonly and widely used in industry:

Transmission Control Protocol (TCP)

User Datagram Protocol (UDP)
Internet Control Message Protocol (ICMP)
Hypertext Transfer Protocol (HTTP)
Post Office Protocol (POP3)
File Transfer Protocol (FTP)
Internet Message Access Protocol (IMAP)
Transmission Control Protocol (TCP):
It resides at the transport layer. Web browsers use TCP when they connect to servers on the World Wide
Web, and it is used to deliver email and transfer files from one location to another. IP works by exchanging
pieces of information called packets. A packet is a sequence of octets and consists of a header followed by a
body. The header describes the packet's source, destination and control information. The body contains the
data IP is transmitting. .

TCP Header
Offse Oct
ts
et

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
Octe Bit
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
t

32

Sequence number

64

Acknowledgment number (if ACK set)

12

96

16

128

20
...

160
...

Source port

Data
offset

Destination port

Reserve N C E U A P R S F
W C R C S S Y I
d
S
0 0 0

R E G K H T N N

Checksum

Window Size
Urgent pointer (if URG set)

Options (if data offset > 5. Padded at the end with "0" bytes if necessary.)
...

Source port (16 bits)

Identifies the sending port
Destination port (16 bits)
Identifies the receiving port
Sequence number (32 bits)
Has a dual role:

If the SYN flag is set (1), then this is the initial sequence number. The sequence number of
the actual first data byte and the acknowledged number in the corresponding ACK are then
this sequence number plus 1.
If the SYN flag is clear (0), and then this is the accumulated sequence number of the first
data byte of this segment for the current session.
Acknowledgment number (32 bits)
If the ACK flag is set then the value of this field is the next sequence number that the receiver is
expecting. This acknowledges receipt of all prior bytes (if any). The first ACK sent by each end
acknowledges the other end's initial sequence number itself, but no data.

Data offset (4 bits)

Specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the
maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing
for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the
offset from the start of the TCP segment to the actual data.
Reserved (3 bits)
For future use and should be set to zero
Flags (9 bits) (aka Control bits)
Contains 9 1-bit flags

NS (1 bit) ECN-nonce concealment protection (added to header by RFC 3540).

CWR (1 bit) Congestion Window Reduced (CWR) flag is set by the sending host to indicate
that it received a TCP segment with the ECE flag set and had responded in congestion
control mechanism (added to header by RFC 3168).
ECE (1 bit) ECN-Echo indicates
If the SYN flag is set (1), that the TCP peer is ECN capable.
If the SYN flag is clear (0) that a packet with Congestion Experienced flag in IP header set is
received during normal transmission (added to header by RFC 3168).
URG (1 bit) indicates that the Urgent pointer field is significant
ACK (1 bit) indicates that the Acknowledgment field is significant. All packets after the
initial SYN packet sent by the client should have this flag set.
PSH (1 bit) Push function. Asks to push the buffered data to the receiving application.
RST (1 bit) Reset the connection
SYN (1 bit) Synchronize sequence numbers. Only the first packet sent from each end
should have this flag set. Some other flags change meaning based on this flag, and some are
only valid for when it is set, and others when it is clear.
FIN (1 bit) No more data from sender

Window size (16 bits)

The size of the receive window, which specifies the number of window size units (by default, bytes)
(beyond the sequence number in the acknowledgment field) that the sender of this segment is
currently willing to receive (see Flow control and Window Scaling)
Checksum (16 bits)
The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer (16 bits)
If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last
urgent data byte
Options (Variable 0320 bits, divisible by 32)
The length of this field is determined by the data offset field. Options have up to three fields:
Option-Kind (1 byte), Option-Length (1 byte), and Option-Data (variable). The Option-Kind field
indicates the type of option, and is the only field that is not optional. Depending on what kind of
option we are dealing with, the next two fields may be set: the Option-Length field indicates the
total length of the option, and the Option-Data field contains the value of the option, if applicable.
For example, an Option-Kind byte of 0x01 indicates that this is a No-Op option used only for
padding, and does not have an Option-Length or Option-Data byte following it. An Option-Kind byte
of 0 is the End of Options option, and is also only one byte. An Option-Kind byte of 0x02 indicates
that this is the Maximum Segment Size option, and will be followed by a byte specifying the length
of the MSS field (should be 0x04). Note that this length is the total length of the given options field,
including Option-Kind and Option-Length bytes. So while the MSS value is typically expressed in two
bytes, the length of the field will be 4 bytes (+2 bytes of kind and length). In short, an MSS option
field with a value of 0x05B4 will show up as (0x02 0x04 0x05B4) in the TCP options section.
Some options may only be sent when SYN is set; they are indicated below as [SYN]. Option-Kind and
standard lengths given as (Option-Kind, Option-Length).

0 (8 bits) End of options list

1 (8 bits) No operation (NOP, Padding) this may be used to align option fields on 32-bit
boundaries for better performance.
2,4,SS (32 bits) Maximum segment size (see maximum segment size) [SYN]
3,3,S (24 bits) Window scale (see window scaling for details) [SYN]
4,2 (16 bits) Selective Acknowledgement permitted. [SYN] (See selective acknowledgments
for details)[7]
5,N,BBBB,EEEE,... (variable bits, N is either 10, 18, 26, or 34)- Selective Acknowledgements
(SACK)[8] These first two bytes are followed by a list of 14 blocks being selectively
acknowledged, specified as 32-bit begin/end pointers.
8,10,TTTT,EEEE (80 bits)- Timestamp and echo of previous timestamp (see TCP timestamps
for details)[9]
14,3,S (24 bits) TCP Alternate Checksum Request. [SYN]
15,N,... (variable bits) TCP Alternate Checksum Data.

(The remaining options are obsolete, experimental, not yet standardized, or unassigned)
Padding
The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit
boundary. The padding is composed of zeros

Universal Datagram Protocol (UDP):

UDP Header
Offset Octe
s
t

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Octet

Bit

Source port

Destination port

32

Length

Checksum

The UDP header consists of 4 fields, each of which is 2 bytes (16 bits). The use of the fields "Checksum" and
"Source port" is optional in IPv4 (pink background in table). In IPv6 only the source port is optional (see
below).
Source port number
This field identifies the sender's port when meaningful and should be assumed to be the port to
reply to if needed. If not used, then it should be zero. If the source host is the client, the port
number is likely to be an ephemeral port number. If the source host is the server, the port number
is likely to be a well-known port number.
Destination port number
This field identifies the receiver's port and is required. Similar to source port number, if the client is
the destination host then the port number will likely be an ephemeral port number and if the
destination host is the server then the port number will likely be a well-known port number
Length
A field that specifies the length in bytes of the UDP header and UDP data. The minimum length is 8
bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8
byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length
which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 8 byte UDP header 20
byte IP header).
In IPv6 Jumbo grams it is possible to have UDP packets of size greater than 65,535 bytes. This allows
for a maximum length value of 4,294,967,295 bytes (2^32 - 1) with 8 bytes representing the header
and 4,294,967,287 bytes for data.
Checksum

The checksum field is used for error-checking of the header and data. If no checksum is generated
by the transmitter, the field uses the value all-zeros. This field is not optional for IPv6
IPv4 Pseudo Header
When UDP runs over IPv4, the checksum is computed using a "pseudo header" that contain some of the
same information from the real IPv4 header. The pseudo header is not the real IPv4 header used to send an
IP packet; it is used only for the checksum calculation.
bits

07

8 15

16 23

Source address

32

Destination address

64

Zeros

24 31

Protocol

UDP length

96

Source Port

Destination Port

128

Length

Checksum

Data

160+

The source and destination addresses are those in the IPv4 header. The protocol is that for UDP (see List of
IP protocol numbers): 17 (0x11). The UDP length field is the length of the UDP header and data.
UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero.
IPv6 Pseudo Header
When UDP runs over IPv6, the checksum is mandatory. The method used to compute it is changed as
documented in RFC 2460:
Any transport or other upper-layer protocol that includes the addresses from the IP header in its
checksum computation must be modified for use over IPv6 to include the 128-bit IPv6 addresses.
When computing the checksum, again a pseudo header is used that mimics the real IPv6 header:
Offsets

Octet

Octet

Bit

07

8 15

16 23

24 31

32

64

Source address

12

96

16

128

20

160
Destination address

24

192

28

224

32

256

36

288

40

320

Source Port

Destination Port

44

352

Length

Checksum

48+

384+

Comparison of TCP and UDP Protocol:

Reliable
Ordered
Heavyweight
Streaming

UDP length
Zeros

Next Header

Data

Dear Manager,
TCS Pvt Ltd
Islamabad
Pakistan

As per PTMLs requirement, we are dispatching PTML vehicles registration number plate.

So please allow it to move from Ufone Tower Islamabad to Regional Office Faisalabad.

Regards

Asad Sawar Abbasi

Dated

________________________

_____________________

TO

Adil Nazir
PTML, Institute of Engineers Building, Zarghoon Road, Quetta Cantt
Quetta
03337831113

TO

Jahangir Rajper
PTML, C 8/7, Railway Housing Society Auto Bahan Road,
Hyderabad
03332600019

TO

M Adeel
Pak Telecom Mobile Ltd, 112-B, Gulberg II,
Lahore
03334050055

TO

Nasir Bukhari
PTML, Building No.2, Block No. 3, MSGPTCHS Moalimabad, Shaheed-e-Millat Road,
Karachi
03332100054

TO

Khalid Ishaq
PTML, 27-Chenab Market, Susan Road Madina Town,
Faisalabad
03336500024

From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th

From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th

From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th

From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th

From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th

From
Muneeb Hassan
15th Floor Ufone Tower Islamabad
03355800057
From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th

From
Muneeb Hassan
15 Floor Ufone Tower Islamabad
03355800057
th