CHAPTER-V THE TCP/IP INTERNET ARCHITECTRUE The Internet architecture is of a layered design, which makes testing and future

development of Internet protocols easy. The architecture and major protocols of the Internet are controlled by the Internet Architecture Board (IAB). Internet architecture is illustrated in Figure 1. The Internet provides three sets of services. At the lowest level is a connectionless delivery service (network layer) called the Internet protocol (IP). The next level is the transport layer service. Multiple transport layer services use the IP service. The highest level is the application layer services. Layering of the services permits research and development on one without affecting the others. Application Layer Transport Layer Network Layer
Network N e.g., SMDS

Application 1 Transport 1

Application 2 Transport 2 Internet (IP)

Application N Transport N

Network 1 e.g., token ring

Network 2 e.g., Ethernet

Link / Physical Layers

Figure-1 Conceptual layering of Internet protocols. The physical/link layer (Network N in Figure 1) envelops the IP layer header and data. If the physical layer is an Ethernet LAN, the IP layer places its message (datagram) in the Ethernet (physical/link) frame data field. The transport layer places its message (segment) in the IP data field. The application layer places its data in the transport layer data field. With multiple transport layer and application layer protocols, what dictates how a particular combination of protocols is chosen? As will be detailed below, a field in the IP header designates which transport layer protocol will act on the IP datagram. Likewise, a field in the transport layer header designates which application layer program will act on the transport layer segment. An application program, based on its need for reliability and throughput, selects the appropriate transport layer protocol to use. Since the Internet only has one network-layer protocol (IP), going down the stack from a transport layer protocol does not involve a selection. The physical/link layer selected by the IP layer is dictated by an interface table associated with the IP address in the IP header. The original TCP/IP reference model consists of 4 layers, but is now viewed by some as a 5-layer model.

RTTC Hyderabad

Figure - 2 AN EXAMPLE OF THE TCP/IP INTERNET An example of the Internet may be presented by following the data flow for an application. For example, a user could make a service call to the File Transfer Protocol (FTP) client, which is representative of the other applications, to transfer a file to a remote storage. The service call contains information that enables the FTP client to construct an FTP descriptor of the type file and the destination host address. The description and user file (message) are given to the transport layer transmission control protocol (TCP). The TCP attaches a header to the FTP message that contains the source port number (identification of the user) and a destination port number (identification of the FTP server). TCP also memorizes these parameters in a memory-resident table to allow continuing operations between the FTP client and server by specifying only a name of the established association (connection). The TCP passes its header and the FTP message (the user file) to the IP for delivery to the destination host (specified by the FTP client) via the Ethernet LAN. The IP is central to the entire TCP/IP protocol suite, excepting some utilities that interface the physical layer directly. Whether the communication is local or network wide, the IP is used. The IP uses a memory-resident routing table to determine which physical interface should be used for the particular FTP message. The IP attaches its header (containing a specific, network wide IP address) to the TCP header (already attached to the TCP data, which is the FTP data) and passes it to the appropriate physical/link layer program (Ethernet in this scenario) for delivery to the host at the destination specified by the IP address in the IP header. The IP address (32 bits) is converted to an Ethernet address (48 bits) by the address resolution protocol (ARP) before the Ethernet driver constructs an Ethernet frame. The frame is broadcast on the bus as a unicast packet targeted at a single Ethernet address. While all device drivers on the Ethernet see the frame, only the device driver of the addressed host processes the frame and the others discard it. The process is reversed at the destination host. The Ethernet driver removes the Ethernet header and passes the remainder (frame data containing IP header, TCP header, and FTP message) to the destination IP. The destination IP removes the IP header and passes the IP data to the

RTTC Hyderabad

transport layer (TCP). TCP removes the TCP header and passes the message to the application layer program specified by the port number in the TCP header, which is FTP in our example. The major application programs have a fixed, unique port number called the well-known port number. The port number for FTP data is 20
Build Ethernet header Build IP header Build TCP header Call TCP TP TCP header IP header Call IP TCP header IP data TCP header Call Ethernet driver Transmit on bus

Ethernet header IP header

Ethernet data

Data FTP message (contains no header)

Data

Data

Data

TCP segment

IP datagram

Ethernet frame

Figure-3 Data flow using the FTP/TCP/ICP. Considering that multiple applications are busy building a queue of messages for TCP with only a few physical paths, the Internet is performing a statistical multiplexing function. Many messages sent from FTP to the same IP address should be delivered to different users (or programs), which is made possible by each user having a unique identifier in the TCP header. The unique identifiers (actually port numbers), in combination with IP addresses of the source and destination, form a connection. TCP/IP Network Layer Protocols The Internet protocol (IP) receives data directly from the Ethernet and functions on an architectural level equivalent to the network layer of the OSI reference model. The protocols ARP and RARP receive data directly from the Ethernet in the same manner as the IP. INTERNET PROTOCOL (IP) The IP provides a connectionless delivery system that is unreliable and on a best-effort basis. The IP specifies the basic unit of data transfer in a TCP/IP internet as the datagram. Datagrams may be delayed, lost, duplicated, delivered out of sequence, or intentionally fragmented, to permit a node with limited buffer space to handle the IP datagram. It is the responsibility of the IP to reassemble any fragmented datagrams. In some error situations, datagrams are silently discarded while in other situations, error messages are sent to the originators (via the ICMP, a utility protocol.) The IP specifications also define how to choose the initial path over which data will be sent, and defines a set of rules governing the unreliable datagram service.

RTTC Hyderabad

The datagram consists of a header and data. Figure-4 identifies each field of the header, and is followed by a description of each field. Header Length 4 Bit field The value represents the number of octets in the header divided by four, which makes it the number of 4-octet groups in the header. The header length is used as a pointer to the beginning of data. The header length is usually equal to 5, which defines the normal, 20-octet header without options. When options are used, padding may be required to make the total size of the header an even multiple of 4-octet groups. The range of value for the header length is 5 to 15. Version 4 Bit field All other values are reserved or unassigned. Although the range of values is 0 to 15, the value used by IP is 4. By means of this field, different versions of the IP could operate in the Internet. Type of Service 8 Bit field Specifies the precedence and priority of the IP datagram (see Figure-5). Bits +5, +6, and +7 make up the precedence field, with a range of 0 to 7. Zero is the normal precedence and 7 is reserved for network control. Most gateways presently ignore this field. The four bits (+1, +2, +3, and +4) define the priority field, which has the field range of 0 to 15. The four priorities presently assigned (the remaining 12 values are reserved) are: value 0 (the default, normal service), value 1 (minimize monetary cost), value 2 (maximize reliability), value 4 (maximize throughput), and value 8 (bit+4 equal to one, defines minimize delay option). These values are used by routers to select paths that accommodate the users request.

32 Bits

Version

IHL

Type of service

Total length D F M Fragment offset F

Identification Time to live Source address Destination address Protocol

Header checksum

Options (o or more words)

Bit Figure-4 IP-datagram format. order of transmission msb 7 6 5 4 3 Priority 25 24 23 22 21 2 1 Isb 0 0 20

Precedence

RTTC Hyderabad 7
2

26

Figure-5 Type-of-service field. Total Length 16 Bit field The total length field is used to identify the number of octets in the entire datagram. The field has 16 bits, and the range is between 0 and 65,535 octets. Since the datagram typically is contained in an Ethernet frame, the size usually will be less than 1,500 octets. Larger datagrams may be handled by some intermediate networks of the Internet but are segmented if a gateway of a network is unable to handle the larger size. IP specifications set a minimum size of 576 octets that must be handled by routers without fragmentation. Larger datagrams are subject to fragmentation. Identification 16 Bit field The value of the identification field is a sequential number assigned by the originating host. The numbers cycle between 0 and 65,535 which when combined with the originating host address makes it a unique number in the Internet. The number is used to aid in the assembling of a fragmented datagram. Fragment Offset 13 Bit field When the size of a datagram exceeds the maximum of an intermediate network, it is segmented by that network. The fragment offset represents the displacement (in increments of eight octets) of this segment form the beginning of the entire datagram. This is a 13-bit field and provides an offset to the proper location of this fragmented segment within the original datagram. Since the value represents groups of eight octets, the effective range of the offset is between 0 and 8191 octets. The resulting fragments are treated as complete datagrams, and remain that way until they reach the destination host where they are reassembled into the original datagram. Each fragment has the same header as the original header except for the fragment offset field, identification field, and the flags fields. Since the resulting datagrams may arrive out of order, these fields are used to assemble the collection of fragments into the original datagram. Flags 2 Bits The flag field contains two flags. The low-order bit (MF) of the flags fields is used to denote the last fragmented datagram when set to zero. That is, intermediate (not-last) datagrams have the bit set equal to one to denote more datagrams are to follow. The high-order bit (DF) of the flags field is set by an originating host to prevent fragmentation of the datagram. When this bit is set and the length of the datagram exceeds that of an intermediate network, the datagram is discarded by the intermediate network and an error message returned to the originating host via the ICMP. Time to Live (TTL) 8 Bit field

RTTC Hyderabad

It represents a count set by the originator, which the datagram can exist in the Internet before being discarded. Hence, a datagram may loop around an internet for a maximum of 28 1 or 255 before being discarded. The current recommended default TTL for the IP is 64. Since each gateway handling a datagram decrements the TTL by a minimum of one, the TTL can also represent a hop count. However, if the gateway holds the datagram for more than one second, then it decrements the TTL by the number of seconds held. The originator of the datagram is sent an error message via the ICMP when the datagram is discarded. Protocol 8 Bit field The protocol field is used to identify the next higher layer protocol using the IP. It will normally identify either the TCP (value equal to 6) or UDP (value equal to 17) transport layer, but may identify up to 255 different transport layer protocols. An upper layer protocol using the IP must have a unique protocol number. Checksum 16 Bit field The checksum provides assurance that the header has not been corrupted during transmission. The checksum includes all fields in the IP header, starting with the version number and ending with the octet immediately preceding the IP data field, which may be a pad field if the option field is present. The checksum includes the checksum field itself, which is set to zero for the calculation. The checksum represents the 16-bit, ones complement of the ones complement sum of all 16-bit groups in the header. An intermediate network (node or gateway) the changes a field in the IP header (e.g., time-tolive) must recompute the checksum before forwarding it. Users of the IP must provide their own data integrity, since the IP checksum is only for the header. Source Address 32 Bit field The source address field contains the network identifier and host identifier of the originator. Destination Address 32 Bit field The destination address field contains the network and identifier & Host identifier of the destination. Options variable field The presence of the options field is determined from the value of the header length field. If the header length is greater than five, at least one option is present. Although it is not required that a host set options, it must be able to accept and process options received in a datagram. The options field is variable in length. Each option declared begins with a single octet that defines that format of the remainder of the option. Padding variable field

RTTC Hyderabad

The pad field, when present, consists of 1 to 3 octets of zero, as required, to make the total number of octets in the header divisible by four. (The header length is in increments of 32-bit groups.) TCP/IP Transport Layer Protocols This session provides a description of the transport layer protocols, user datagram protocol (UDP), and transmission control protocol (TCP). The selection by an application program to use either UDP or TCP is based on the requirement for reliability, primarily. Some application layer protocols were designed to operate with either UDP or TCP. The selection by the IP of either the UDP or TCP is based on the protocol number in the IP header. Although ICMP and IGMP gain control as transport layer functions, they function as a utility to the network layer (IP). The TCP/IP designers used the protocols number in the IP header to demultiplex to distinct services. USER DATAGRAM PROTOCOL (UDP) The UDP provides application programs with a transaction oriented, single-shot datagram type service. The service is similar to the IP in that it is connectionless and unreliable. The UDP is simple, efficient and ideal for application programs such as TFTP and DNS. An IP address is used to direct the user datagram to a particular machine, and the destination port number in the UDP header is used to direct the UDP datagram (or user datagram) to a specific application process (queue) located at the IP address. The UDP header also contains a source port number that allows the receiving process to know how to respond to the user datagram. It effectively loads up one round with the entire, fixed-length message, aims it at the intended receiver (IP address and destination port number), fires one shot into the network, and ends. There is no acknowledgement, flow control, message continuation, or other sophisticated attributes offered by the TCP. The UDP operates at the transport layer and has a unique protocol number in the IP header (number 17). This enables the network layer IP software to pass the data portion of the IP datagram to the UDP software. The UDP uses the destination port number to direct the IP datagram (user datagram) to the appropriate process queue. The format of the UDP datagram is illustrated in Figure-6. Source/Destination Port Numbers 16 Bit field The source and destination port numbers in conjunction with the IP addresses define the end points of the single-shot communication. The source port number may be equal to zero if not Octet Octet + 0 Octet + only meaningful2within the context of+a3particular UDP Octet + used. The destination port number is 1 datagram and IP address. 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Source port Destination port

Message length

Checksum

UDP data

RTTC Hyderabad

Figure- 6 UDP datagram format. The source port number is a 16-bit field. The destination port number is also a 16-bit field. There are some fixed, preassigned port number used for services on the Internet for example, number 7 is used for the UDP echo server and number 69 is used for trivial file transfer (TFTP). These fixed, preassigned port numbers are referred to as well-known ports and controlled by the IANA. Length Field 16 Bit field The UDP message-length field is a 16-bit field that contains a count of the total number of octets in the user datagram, including the header. Hence, the minimum-size length field is 8. Checksum 16 Bit field Usage of the UDP checksum is optional, however the field must be set to zero when not used. Since the IP layer does not include the data portion of the IP datagram in its checksum (protocols the IP header only), UDP has its own checksum to provide data integrity. The UDP checksum is the 16-bit ones complement of the ones complement sum of the UDP header, UDP data, and some fields from the IP header.

TCP Segment Format

Source port

32 Bits Destination port

The TCP segment consists of a TCP header and data. The header portion of the TCP segment is relatively fixed number The only optional field is the options field, which may necessitate a pad Sequence in size. field to assure that the overall header length is a multiple of four-octet groups. The format of the TCP segment is illustrated in Figure-10. The following is a description of each of the fields in Acknowledgement number the TCP segment, and general characteristics of TCP associated with each field description.
U A TCP TCP R C header header Source/Destination Port Numbers K G length length P S H R S S Y T N F I N Window size

Each port number is an unsigned integer occupying 16 bits. Checksum Urgent pointer
Options (o or more32-bit words)

RTTC Hyderabad

Data (optional)

Figure - 10 TCP format. Sequence Numbers There are two sequence numbers in the TCP header. The first is the send sequence number (SSN). The SSN is a 32 bit unsigned integer. The entire data to be sent from one program to another is called a stream. If a stream is too large for a single TCP path segment (typical), it is broken up into smaller segments. The SSN of the first TCP segment identifies the first octet of the entire stream. Assume this value is n, which was established when the TCP connection was made. Then, the value of the SSN of the second TCP segment equals n + m, where m is the octet displacement within the total stream to the beginning of the second TCP segment. In general, the SSN is an octet pointer within the total stream to the first octet of the particular TCP segment. The value of the field cycles between 0 and (232 1). It provides each octet of a stream with a sequence number. Header length The header length is a 4-bit field. It contains an integer equal to the total number of octets in the TCP header, divided by four. That is, it represents the number of 4-octet groups in the header. The value of the header length field is typically equal to five unless the there are options. Since there may be options in the TCP header, the pad field is used to force the number of octets in the header equal to a multiple of four. There may be up to three octets in the pad field, each containing the value zero. Code Bits The purpose and content of the TCP segment is determined by the settings to the bits in the code bit field. URG bit The URG code bit and the urgent pointer provide the sending program with the ability to bypass the normal stream with urgent data. When the URG bit is set to one, the urgent pointer is used as an octet displacement from the sequence number of the segment to the last

RTTC Hyderabad

octet of urgent data. That is, the data following the urgent pointer is the routine or nonurgent data. When the URG bit is not equal to one, the urgent pointer is not used. ACK bit When the ACK bit is equal to one, the acknowledgement number is valid. This should always be the case after the connection is established. Code Bit Field Definitions Mnemonic Name URG ACK PSH RST SYN FIN Bit Number 5 4 3 2 1 0 Meaning If Bit Equal to One Urgent pointer field is valid Acknowledgement field is valid This segment requests a push Reset connection Synchronize sequence numbers Sender reached end of octet stream

PSH bit Although a transmit buffer may not be full, the sender may force it to be delivered. This procedure is often used with a TELNET hot-key entry to create single-octet segments, which is required by some applications. RST bit Setting the RST bit in a segment causes the connection to be aborted. All buffers associated with the connection are released and the entry in the TCB is deleted. SYN bit The SYN bit is set during connection establishment only to synchronize the sequence numbers. FIN bit The FIN bit is set during connection closing only. Window The window field is a 16-bit unsigned integer. The window field is used to advertise the available buffer size (in octets) of the sender to receive data. Options The option field permits the application program to negotiate, during connection set up, characteristics such as the maximum TCP segment size able to receive. Some future options may not be linked to connection setups. Ideally, the TCP segment size would be the maximum possible without causing fragmenting. If the option is not used, any segment size is allowed. The TCP maximum-segment-size option is illustrated in Figure 11.

RTTC Hyderabad

10

Octet + 0

Octet + 1

Octet + 2

Octet + 3

Isb msb Isb msb Isb Isb msb Isb 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

Option type = 2 Option length = 2 Maximum segment size

Figure 11 TCP maximum-segment-size option. Padding The padding field, when present, consists of one to three octets, each equal to zero, to force the length of the TCP header to be in multiples of four octets. If options are nor used, padding is not required. If options are used, padding may or may not be required. Checksum Since the IP layer does not include the data portion of the datagram in its checksum (protects the IP header only), TCP has its own checksum to provide data integrity. The checksum field of the TCP header is set to zero before the checksum calculations. The TCP checksum is the 16-bit ones complement of the ones complement sum of the TCP header, TCP data. Including fields from the IP datagram header in the checksum protects against misrouted TCP segments. If the computed checksum is zero, it is transmitted as all ones (the ones complement of zero).

RTTC Hyderabad

11