NETWORK ALLOCATION VECTOR:

NETWORK ALLOCATION VECTOR:

If a channel is idle then a station sends the RTS. When a station sends an RTS frame it include the duration of time, it occupies the channel. Other station that needs the channel starts the timer called Network Allocation Vector (NAV), till which the station does not check the idleness of the channel. After NAV has expired, stations check the channel and if it free any one station sends its RTS.

IP

73 | P a g e CS6551 COMPUTER NETWORKS

What Is an Internetwork?

We use the term “internetwork,” or sometimes just “internet” with a lowercase i, to refer to an arbitrary collection of networks interconnected to provide some sort of host-to- host packet delivery service. For example, a corporation with many sites might construct a private internetwork by interconnecting the LANs at their different sites with point-to-point links leased from the phone company.

When we are talking about the widely used, global internetwork to which a large percentage of networks are now connected, we call it the “Internet” with a capital I.

Figure 3.2.1 shows an example internetwork. An internetwork is often referred to as a ―network of networks‖ because it is made up of lots of smaller networks. In this figure, we see Ethernets, an FDDI ring, and a point-to-point link. Each of these is a single-technology network.

Fig. 3.2.1 A simple internetwork. Hn = host; Rn = router.

Service Model

Using IP, we can provide a host-to-host service. The IP service model can be thought of as having two parts: an addressing scheme, which provides a way to identify all hosts in the internetwork, and a datagram (connectionless) model of data delivery.

This service model is sometimes called best effort (unreliable service) because, although IP makes every effort to deliver datagrams, it makes no guarantees.

Datagram Delivery

The IP datagram is fundamental to the Internet Protocol. A datagram is a type of packet that happens to be sent in a connectionless manner over a network. Every datagram carries enough information to let the network forward the packet to its correct destination; there is no need for any advance setup mechanism to tell the network what to do when the packet arrives. You just send it, and the network makes its best effort to get it to the desired destination. The ―best-effort‖

part means that if something goes wrong and the packet gets lost, corrupted, misdelivered, or in any way fails to reach its intended destination, the network does nothing—it made its best effort, and that is all it has to do. It does not make any attempt to recover from the failure. This is

The IP datagram, like most packets, consists of a header followed by a number of bytes of data.

The format of the header is shown in Figure 3.2.2

74 | P a g e CS6551 COMPUTER NETWORKS

IPv4 Packet Header

Version: The Version field specifies the version of IP. The current version of IP is 4, and it is sometimes called IPv4.

HLen : The next field, HLen, specifies the length of the header in 32-bit words. When there are no options, which is most of the time, the header is 5 words (20 bytes) long.

TOS : The 8-bit TOS (type of service) field has had a number of different definitions over the years, but its basic function is to allow packets to be treated differently based on application needs. For example, the TOS value might determine whether or not a packet should be placed in a special queue that receives low delay.

Length : The next 16 bits of the header contain the Length of the datagram, including the header. Unlike the HLen field, the Length field counts bytes rather than words. Thus, the maximum size of an IP datagram is 65,535 bytes. The physical network over which IP is running, however, may not support such long packets. For this reason, IP supports a fragmentation and reassembly process. The second word of the header contains information about fragmentation, and the details of its use are presented under ―Fragmentation and Reassembly‖ below.

TTL : Moving on to the third word of the header, the next byte is the TTL (time to live) field.

Its name reflects its historical meaning rather than the way it is commonly used today. The intent of the field is to catch packets that have been going around in routing loops and discard them, rather than let them consume resources indefinitely. Originally, TTL was set to a specific number of seconds that the packet would be allowed to live, and routers along the path would decrement this field until it reached 0. However, since it was rare for a packet to sit for as long as 1 second in a router, and routers did not all have access to a common clock, most routers just decremented the TTL by 1 as they forwarded the packet. Thus, it became more of a hop count than a timer, which is still a perfectly good way to catch packets that are stuck in routing loops. One subtlety is in the initial setting of this field by the sending host: Set it too high and packets could circulate rather a lot before getting dropped; set it too low and they may not reach their destination. The value 64 is the current default.

Ident : It allows the destination host to determine which datagram a newly arrived fragment belongs to. All the fragment of a datagram contain the same identification value

Flags : DF – Don‘t fragment, MF- More fragment Offset :Max 8192 fragment per datagram

Protocol : This field is simply a demultiplexing key that identifies the higher-level protocol to which this IP packet should be passed. There are values defined for TCP (6), UDP (17), and many other protocols that may sit above IP in the protocol graph.

Checksum : This field is calculated by considering the entire IP header as a sequence of 16-bit words, adding them up using ones complement arithmetic, and taking the ones complement of

75 | P a g e CS6551 COMPUTER NETWORKS

the result. Thus, if any bit in the header is corrupted in transit, the checksum will not contain the correct value upon receipt of the packet. Since a corrupted header may contain an error in the destination address—and, as a result, may have been misdelivered—it makes sense to discard any packet that fails the checksum. It should be noted that this type of checksum does not have the same strong error detection properties as a CRC, but it is much easier to calculate in software.

The last two required fields in the header are the SourceAddr and the DestinationAddr for the packet. The latter is the key to datagram delivery: Every packet contains a full address for its intended destination so that forwarding decisions can be made at each router. The source address is required to allow recipients to decide if they want to accept the packet and to enable them to reply.

Finally, there may be a number of options at the end of the header. The presence or absence of options may be determined by examining the header length (HLen) field. While options are used fairly rarely, a complete IP implementation must handle them all.

Fragmentation and Reassembly

One of the problems of providing a uniform host-to-host service model over a heterogeneous collection of networks is that each network technology tends to have its own idea of how large a packet can be. For example, an Ethernet can accept packets up to 1500 bytes long, while FDDI packets may be 4500 bytes long. This leaves two choices for the IP service model: make sure that all IP datagrams are small enough to fit inside one packet on any network technology, or provide a means by which packets can be fragmented and reassembled when they are too big to go over a given network technology.

The central idea here is that every network type has a maximum transmission unit (MTU), which is the largest IP datagram that it can carry in a frame. When a host sends an IP datagram, therefore, it can choose any size that it wants. A reasonable choice is the MTU of the network to which the host is directly attached. Then fragmentation will only be necessary if the path to the destination includes a network with a smaller MTU. Should the transport protocol that sits on top of IP give IP a packet larger than the local MTU, however, then the source host must fragment it.

Fragmentation typically occurs in a router when it receives a datagram that it wants to forward over a network that has an MTU that is smaller than the received datagram. To enable these fragments to be reassembled at the receiving host, they all carry the same identifier in the Ident field. This identifier is chosen by the sending host and is intended to be unique among all the datagrams that might arrive at the destination from this source over some reasonable time period.

Since all fragments of the original datagram contain this identifier, the reassembling host will be able to recognize those fragments that go together. Should all the fragments not arrive at the receiving host, the host gives up on the reassembly process and discards the fragments that did arrive. IP does not attempt to recover from missing fragments.

IP addressing methods

An IPv4 address is a 32-bit address that uniquely and universally defines the connection of a device (for example, a computer or a router) to the Internet.

An IP address is a 32 bit binary number usually represented as 4 decimal values, each representing 8 bits, in the range 0 to 255 (known as octets) separated by decimal points. This is known as "dotted decimal" notation. Figure 3.2.3 shows the binary and dotted decimal representation of the IP address 128.11.3.31.

76 | P a g e CS6551 COMPUTER NETWORKS

Figure 3.2.3: Binary and dotted decimal notation of IP address

There are three modes of addressing namely, cast, Multi-cast and Broad-cast addresses. Uni-Cast address is simply a send-to one addressing mode. Broad-Uni-Cast address is simply a send-to all addressing mode and cannot be used as source address. Multi-Cast is simply a send-to group addressing mode and can never be used as a source address.

Every IP address consists of two parts, one identifying the network and the other identifying the node. The Class of the address and the subnet mask determine which part belongs to the network address and which part belongs to the node address.

There are 5 different address classes namely A, B, C, D and E. It is possible to determine to which class a given IP address belong to by examining the most significant four bits of the IP address.

 Class A addresses begin with 0xxx, or 1 to 127 decimal.

 Class B addresses begin with 10xx, or 128 to 191 decimal.

 Class C addresses begin with 110x, or 192 to 223 decimal.

 Class D addresses begin with 1110, or 224 to 239 decimal.

 Class E addresses begin with 1111, or 240 to 255 decimal.

The class of the IP address determines the default number of bits used for the network identification and host identification within the network. The netid and the hostid bytes for all the classes are shown in the Figure 3.2.4.

Figure 3.2.4: netid and hostid bits

Figure 3.2.5: IP addresses : (a) Class A ; (b) Class B ; (c) Class C.

Class A networks have 7 bits for the network part and 24 bits for the host part.There can be only 126 ( 0 and 127 are reserved) Class A networks. Each of them can accommodate 2²⁴ -2 hosts.

Class A addresses were designed for large organizations with large number of hosts or routers

77 | P a g e CS6551 COMPUTER NETWORKS

attached to their network. Class B networks have 14 bits for the network part and16 bits for the host part. Class B networks can accommodate 65,534 hosts. Class B addresses were designed for midsize organizations that may have tens of thousands of hosts or routers attached to their networks. Class C networks have 8 bits for the network part and 21 bits for the host part. Class C networks can accommodate only 256 hosts. Class C addresses were designed for small organizations with a small number of hosts or routers attached to their network. There is just one block of Class D addresses, which is designed for multicasting. There is just one block of Class E addresses, which is designed for use as reserved addresses.