Winter 2012 Master of Computer Application (MCA) Semester 6 MC0087 Internetworking with TCP/IP 4 Credits (60 Marks) 1.

1. What is fragmentation? Explain its significance When an IP datagram travels from one host to another, it can pass through different physical networks. Each physical network has a maximum frame size. This is called the maximum transmission unit (MTU). It limits the length of a datagram that can be placed in one physical frame. IP implements a process to fragment datagrams exceeding the MTU. The process creates a set of datagrams within the maximum size. The receiving host reassembles the original datagram. IP requires that each link support a minimum MTU of 68 octets. This is the sum of the maximum IP header length (60 octets) and the minimum possible length of data in a non-final fragment (8 octets). If any network provides a lower value than this, fragmentation and reassembly must be implemented in the network interface layer. This must be transparent to IP. IP implementations are not required to handle unfragmented datagrams larger than 576 bytes. In practice, most implementations will accommodate larger values. An unfragmented datagram has an all-zero fragmentation information field. That is, the more fragments flag bit is zero and the fragment offset is zero. The following steps fragment the datagram: 1. The DF flag bit is checked to see if fragmentation is allowed. If the bit is set, the datagram will be discarded and an ICMP error returned to the originator. 2. Based on the MTU value, the data field is split into two or more parts. All newly created data portions must have a length that is a multiple of 8 octets, with the exception of the last data portion. 3. Each data portion is placed in an IP datagram. The headers of these datagrams are minor modifications of the original: The more fragments flag bit is set in all fragments except the last. The fragment offset field in each is set to the location this data portion occupied in the original datagram, relative to the beginning of the original unfragmented datagram. The offset is measured in 8-octet units. If options were included in the original datagram, the high order bit of the option type byte determines if this information is copied to all fragment datagrams or only the first datagram. For example, source route options are copied in all fragments. The header length field of the new datagram is set. The total length field of the new datagram is set. The header checksum field is re-calculated. 4. Each of these fragmented datagrams is now forwarded as a normal IP datagram. IP handles each fragment independently. The fragments can traverse different routers to the intended destination. They can be subject to further fragmentation if they pass through networks specifying a smaller MTU. At the destination host, the data is reassembled into the original datagram. The identification field set by the sending host is used together with the source and destination IP addresses in the datagram. Fragmentation does not alter this field. In order to reassemble the fragments, the receiving host allocates a storage buffer when the first fragment arrives. The host also starts a timer. When subsequent fragments of the datagram arrive, the data is copied into the buffer storage at the location indicated by the fragment offset field. When all fragments have arrived, the complete original unfragmented datagram is restored. Processing continues as for unfragmented datagrams. If the timer is exceeded and fragments remain outstanding, the datagram is discarded. The initial value of this timer is called the IP datagram time to live (TTL) value. It is implementationdependent. Some implementations allow it to be configured. The netstat command can be used on some IP hosts to list the details of fragmentation.

2. Briefly discuss the functions of transport layer

Transport layer accepts data from session layer breaks it into packets and delivers these packets to the network layer. It is the responsibility of transport layer to guarantee successful arrival of data at the destination device. It provides an end-to-end dialog that is the transport layer at the source device directly communicates with transport layer at destination device. Message headers and control messages are used for this purpose. It separates the upper layers from the low level details of data transmission and makes sure an efficient delivery. OSI model provides connection-oriented service at transport layer. It is responsible for the determination of the type of service that is to be provided to the upper layer. Normally it transmits packets in the same order in which they are sent however it can also facilitate the transmission of isolated messages. There is no surety that these isolated messages are delivered to the destination devices in case of broadcast networks and they will be in the same order as were sent from the source. If the network layer do not provide adequate services for the data transmission. Data loss due to poor network management is handled by using transport layer. It checks for any packets that are lost or damaged along the way.

The transport layer ensures that messages are delivered error-free, in sequence, and with no losses or duplications. It relieves the higher layer protocols from any concern with the transfer of data between them and their peers. The size and complexity of a transport protocol depends on the type of service it can get from the network layer. For a reliable network layer with virtual circuit capability, a minimal transport layer is required. If the network layer is unreliable and/or only supports datagrams, the transport protocol should include extensive error detection and recovery. The transport layer provides: Message segmentation: accepts a message from the (session) layer above it, splits the message into smaller units (if not already small enough), and passes the smaller units down to the network layer. The transport layer at the destination station reassembles the message. Message acknowledgment: provides reliable end-to-end message delivery with acknowledgments. Message traffic control: tells the transmitting station to "back-off" when no message buffers are available. Session multiplexing: multiplexes several message streams, or sessions onto one logical link and keeps track of which messages belong to which sessions (see session layer). Typically, the transport layer can accept relatively large messages, but there are strict message size limits imposed by the network (or lower) layer. Consequently, the transport layer must break up the messages into smaller units, or frames, prepending a header to each frame. The transport layer header information must then include control information, such as message start and message end flags, to enable the transport layer on the other end to recognize message boundaries. In addition, if the lower layers do not maintain sequence, the transport header must contain sequence information to enable the transport layer on the receiving end to get the pieces back together in the right order before handing the received message up to the layer above. End-to-end layers Unlike the lower "subnet" layers whose protocol is between immediately adjacent nodes, the transport layer and the layers above are true "source to destination" or endto-end layers, and are not concerned with the details of the underlying communications facility. Transport layer software (and software above it) on the source station carries on a conversation with similar software on the destination station by using message headers and control messages.

3. What is CIDR? Explain Classless Inter-Domain Routing (CIDR) is a method for allocating IP addresses and routing Internet Protocol packets. The Internet Engineering Task Force introduced CIDR in 1993 to replace the previous addressing architecture of classful network design in the Internet. Their goal was to slow the growth of routing tables on routers across the Internet, and to help slow the rapid exhaustion of IPv4 addresses.[1][2]

IP addresses are described as consisting of two groups of bits in the address: the most significant part is the network address which identifies a whole network or subnet

and the least significant portion is the host identifier, which specifies a particular host interface on that network. This division is used as the basis of traffic routing between IP networks and for address allocation policies. Classful network design for IPv4 sized the network address as one or more 8-bit groups, resulting in the blocks of Class A, B, or C addresses. Classless Inter-Domain Routing allocates address space to Internet service providers and end users on any address bit boundary, instead of on 8-bit segments. In IPv6, however, the interface identifier has a fixed size of 64 bits by convention, and smaller subnets are never allocated to end users.

CIDR notation is a syntax of specifying IP addresses and their associated routing prefix. It appends to the address a slash character and the decimal number of leading bits of the routing prefix, e.g., 192.168.0.0/16 for IPv4, and 2001:db8::/32 for IPv6.

CIDR blocks CIDR is principally a bitwise, prefix-based standard for the interpretation of IP addresses. It facilitates routing by allowing blocks of addresses to be grouped into single routing table entries. These groups, commonly called CIDR blocks, share an initial sequence of bits in the binary representation of their IP addresses. IPv4 CIDR blocks are identified using a syntax similar to that of IPv4 addresses: a four-part dotted-decimal address, followed by a slash, then a number from 0 to 32: A.B.C.D/N. The dotted decimal portion is interpreted, like an IPv4 address, as a 32-bit binary number that has been broken into four octets. The number following the slash is the prefix length, the number of shared initial bits, counting from the most-significant bit of the address. When emphasizing only the size of a network, the address portion of the notation is usually omitted. Thus, a /20 is a CIDR block with an unspecified 20-bit prefix.

An IP address is part of a CIDR block, and is said to match the CIDR prefix if the initial N bits of the address and the CIDR prefix are the same. Thus, understanding CIDR requires that IP address be visualized in binary. Since the length of an IPv4 address has 32 bits, an N-bit CIDR prefix leaves 32-N bits unmatched, meaning that 232-N IPv4 addresses match a given N-bit CIDR prefix. Shorter CIDR prefixes match more addresses, while longer prefixes match fewer. An address can match multiple CIDR prefixes of different lengths.

CIDR is also used for IPv6 addresses and the syntax semantic is identical. A prefix length can range from 0 to 128, due to the larger number of bits in the address, however, by convention a subnet on broadcast MAC layer networks always has 64-bit host identifiers. Larger prefixes are rarely used even on point-to-point links. 4. What is congestion? Mention few algorithms to overcome congestion TCP is the popular transport protocol for best-effort trafc in Internet. However, TCP is not well-suited for many applications such as streaming multimedia, because TCP congestion control algorithms introduce large variations in the congestion window size (and corresponding large variations in the sending rate). Such variability in the sending rate is not acceptable to many multimedia applications. Hence, many multimedia applications are built over UDP and use no congestion control at all. The absence of congestion control in applications built over UDP may lead to congestion collapse on the Internet. In addition, the UDP ows may starve any competing TCP ows. To overcome these adverse effects, congestion control needs to be incorporated into all applications using the Internet, whether at the transport layer or provided by the application itself. Furthermore, the congestion control algorithms must be TCP-friendly, i.e. the TCP-friendly ows should not gain more throughput than competing TCP ows in the long run. Thus, in recent years, many researchers have focussed on developing TCP-friendly transport protocols which are suitable for many applications that currently use UDP. In this direction, IETF is currently working on developing a new protocol called, Datagram Congestion Control Protocol (DCCP), that provides an unreliable datagram service with congestion control. DCCP is designed to use any suitable TCP- friendly congestion control algorithm. With a multitude of TCP-friendly congestion control algo- rithms available, some important questions that need to be answered are: What are the strengths and weakness of the various TCP-friendly algorithms? Is there a single algorithm which is uniformly superior over other algorithms?. The rst step in answering these questions is to study the short-term and long-term behavior of these algorithms. Although the goal of all TCP-friendly algorithms is to emulate the behavior of TCP in the long term, these algorithms may have an adverse impact in the short-term on competing TCP ows. Since TCP-friendly algorithms are designed for smoother sending rates than TCP, these algorithms may react slowly to new connections that share a common bottleneck link. Such a slower response may have a deleterious effect on TCP ows. For example, a TCP connection suffering losses in its slow start phase may enter the congestion avoidance phase with a small window, and consequently obtain lesser throughput than other competing ows. Hence, it is clear that a detailed study is required on the short-term (transient)behavior of TCP-friendly ows in addition to their long-term behavior. In this paper, we study the transient behavior of three TCP-friendly congestion control algorithms: general AIMD congestion control, TFRC and binomial congestion control algorithm . Prior work has studied the transient behavior of these algorithms when RED queues are used at the bottleneck link. However, as droptail queues are still widely used in practice, in this paper we study the transient behavior of these algorithms with droptail queues. Past work has also identied certain unfairness of AIMD and binomial congestion control algorithms to TCP with droptail queues, but has not identied the reasons for this unfairness. In this paper, we analyze the reasons for this unfairness, and validate the analysis by simulations. The rest of the paper is organized as follows. In Section II, we briey overview the various TCP-friendly congestioncontrol algorithms proposed in literature. In Section III, we dene the transient behaviors studied in this paper, and analyze the

expected transient behaviors of the various TCP-friendly congestion control algorithms. Section IV analyzes in detail the reasons for unfairness of AIMD and binomial congestion control algorithms with droptail queues. We present our sim- ulation results in Section V, and we conclude in Section VI.

few algorithms to overcome congestion A. Transient behaviors evaluated in the paper B. Equation-Based Congestion Control Algorithm C. General AIMD-Based Congestion Control Algorithms D. Binomial Congestion Control Algorithm

5. Explain the following with respect to Transport Protocols:******************** a. User Datagram Protocol (UDP) b. Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) TCP is standard protocol with STD number 7. TCP is described by RFC 793- implementation that is not used exclusively for routing will include TCP. TCP provides considerably more facilities for applications than UDP. Specifically, this includes error recovery, flow control, and reliability TCP is a connection-oriented protocol, unlike UDP, which is connectionless. Most of the user application protocols, such as Telnet and FTP, use TCP . The two processes communicate with each other over a TCP connection Transmission Control Protocol. Its status is standard, and in practice, every TCP/IP (Inter-process Communication, or IPC), as shown in 5.4.1 TCP Concepts As noted earlier, the primary purpose of TCP is to provide a reliable logical circuit or connection service between pairs of processes. It does not assume reliability from the lower-level protocols (such as IP), so TCP can be characterized by the following facilities it provides for the applications using it. 1. Stream Data Transfer: From the applications viewpoint, TCP transfers a contiguous stream of bytes through the network. The application does not have to brother with chopping the data into basic blocks or datagrams. TCP does this by grouping the bytes into TCP segment, which are passed to the IP layer for transmission to the destination. Also, TCP itself decides how to segment the data, and it can forward the data at its own convenience. Sometimes, an application needs to be sure that all the data passed to TCP has actually been transmitted to the destination. For that reason, a push function is defined. It will push all remaining TCP segment still in storage to the destination host. The normal close connection function also pushes the data to the destination. 2. Reliability: TCP assigns a sequence number to each byte transmitted, and expects a positive acknowledgment (ACK) from the receiving TCP layer, If the ACK is not received within a timeout interval, the data is retransmitted. Because the data is transmitted in blocks (TCP segments) only the sequence number of the first data byte in the segment is sent to the destination host. The receiving TCP uses the sequence number to rearrange the segments when

they arrive out of order and to eliminate duplicate segments. 3. Flow Control: The receiving TCP, when sending ACK back to sender, also indicates to the sender the number of bytes it can receive(beyond the last received TCP segment)without causing overrun and overflow in its internal buffers. This is sent in the ACK in the form of the highest sequence number it can receive without problems. This mechanism is also referred to as a window-mechanism, and we discuss it in more detail later in this chapter. 4. Multiplexing: Achieved through the uses of ports, just as with UDP. 5. Logical Connections: The reliability and flow control mechanisms described here require that TCP initializes and maintains certain status information for each data stream. The combination of this status, including sockets, sequence number, and window sizes, is called the logical connection. Each connection is uniquely identified by the pair of sockets used by the sending and receiving processes. 6. Full Duplex: TCP provides for concurrent data streams in both directions.

User Data Protocol (UDP) UDP is suitable for purposes where error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system.[2] If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.

UDP (User Datagram Protocol) is a simple OSI transport layer protocol for client/server network applications based on Internet Protocol (IP). UDP is the main alternative to TCP and one of the oldest network protocols in existence, introduced in 1980. UDP is often used in videoconferencing applications or computer games specially tuned for real-time performance. To achieve higher performance, the protocol allows individual packets to be dropped (with no retries) and UDP packets to be received in a different order than they were sent as dictated by the application.

UDP Datagrams UDP network traffic is organized in the form of datagrams. A datagram comprises one message unit. The first eight (8) bytes of a datagram contain header information and the remaining bytes contain message data.

A UDP datagram header consists of four (4) fields of two bytes each:

source port number destination port number datagram size checksum

UDP port numbers allow different applications to maintain their own channels for data similar to TCP. UDP port headers are two bytes long; therefore, valid UDP port numbers range from 0 to 65535. The UDP datagram size is a count of the total number of bytes contained in header and data sections. As the header length is a fixed size, this field effectively tracks the length of the variable-sized data portion (sometimes called payload). The size of datagrams varies depending on the operating environment but has a maximum of 65535 bytes. UDP checksums protect message data from tampering. The checksum value represents an encoding of the datagram data calculated first by the sender and later by the receiver. Should an individual datagram be tampered with or get corrupted during transmission, the UDP protocol detects a checksum calculation mismatch.

A number of UDP's attributes make it especially suited for certain applications.

It is transaction-oriented, suitable for simple query-response protocols such as the Domain Name System or the Network Time Protocol. It provides datagrams, suitable for modeling other protocols such as in IP tunneling or Remote Procedure Call and the Network File System. It is simple, suitable for bootstrapping or other purposes without a full protocol stack, such as the DHCP and Trivial File Transfer Protocol. It is stateless, suitable for very large numbers of clients, such as in streaming media applications for example IPTV The lack of retransmission delays makes it suitable for real-time applications such as Voice over IP, online games, and many protocols built on top of the Real Time Streaming Protocol. Works well in unidirectional communication, suitable for broadcast information such as in many kinds of service discovery and shared information such as broadcast time or Routing Information Protocol

6. With diagram explain the components of a VoIP networking system.

Components of a VoIP Network

Many companies have dumped their traditional phone systems for VoIP or Voice over Internet Protocol systems. VoIP allows phone calls to be made over the Internet. VoIP benefits companies by allowing them to streamline voice and data network management. Network engineers only have to focus on designing, managing and repairing a single network. There are a lot of components that go into making a successful VoIP network. Network Devices

Network devices are the building blocks to creating a VoIP network. These devices include hardware and software applications. Some of the hardware devices the company will need are switches, computers, PDAs (Personal Digital Assistants) and VoIP phones. Software applications the company must have include a program that manages all of the network devices and one that routes and forwards calls.

IP Network

The IP network manages all of the connections between these devices. An IP network works differently from that of a traditional phone system. Traditional phone systems use circuit-switch technology, which involves setting up a connection between two network devices before they can start transmitting data. With an IP network, however, data is converted into packets and is compressed. Once the data reaches its destination, it is then uncompressed. Voice signals are much more difficult to transport over an IP network than data. This is because voice must not only be compressed, but digitized. Analog technology is signals that move in continuous waves. Digital technology, on the other hand, is signals that move in pulses. When the voice data arrives at a traditional phone, it must be uncompressed and restored as speech that the caller can understand. These must all be done without any delays. Otherwise, the conversations can be garbled or distorted.

o
Media Gateways

Media gateways create the interface between the company's telephone network and the VoIP network. They are responsible for making sure the voice data transports over the IP network smoothly. These systems usually handle large quantities of digital circuits. Some of the functions that media gateways handle are call detection, call originations and creating voice packets. Media gateways also convert voice from analog to digital.