<<

. 38
( 132 .)



>>

Table 5.3 Subnet mask tradeoff
Subnet mask Bit pattern Subnets Hosts
255.255.0.0 11111111.11111111.00000000.00000000 0 65 534
255.255.192.0 11111111.11111111.11000000.00000000 2 16 382
255.255.224.0 11111111.11111111.11100000.00000000 6 8190
255.255.240.0 11111111.11111111.11110000.00000000 14 4094
255.255.248.0 11111111.11111111.11111000.00000000 30 2046
255.255.252.0 11111111.11111111.11111100.00000000 62 1022
255.255.254.0 11111111.11111111.11111110.00000000 126 510
255.255.192.0 11111111.11111111.11111111.00000000 254 254


different subnet masks to identify different subnetworks is referred to as variable-length
subnet masking (VLSNM).
Since there are only 126 class A network addresses these were originally allocated on
the Internet to only big organizations with very large internal networks. Class B addressing
allocates 14 bits to the network portion and therefore provides more networks at a cost to
host space (only 65 534 hosts per network). Class C networks have the smallest allocation
of hosts per network at only 254 but have the largest number available. Due to many
organizations having more than 254 hosts, demand for class B addresses has traditionally
been high. This has led to a depletion of the class B network address space and problems
¬nding suitable network address allocations for medium size organizations (more than 254
hosts). This problem and others will be ¬nally solved by the introduction of IPv6, which
uses 128 bits for each IP address and therefore provides an almost inexhaustible supply.
Class D addresses are for the support of multicasting. Class E addresses are reserved,
and thus far their use has not been standardized.
There are some special addresses that cannot be used. To take these exceptions into
account, the general formulas to compute the number of possible subnets and hosts using
a given subnet mask are:
Possible subnets = 2(number ’2
of masked bits)


Possible hosts = 2(number ’2
of unmasked bits)


Consider a class B network using the subnet mask of 255.255.240.0. This has 4 addi-
tional masked bits representing the value 240 and therefore the number of subnets =
24 ’ 2 = 14 and the number of hosts is = 212 ’ 2 = 4094.
Table 5.4 lists the addresses that have special signi¬cance within the IP protocol and
should not be used when assigning addresses.
In addition, the IETF has de¬ned the addresses shown in Table 5.5 for use internally in
private networks, and these are invalid on the Internet. An application of these addresses
is described in Section 5.6.6.


5.2.3 Address depletion and CIDR
Since IPv4 addresses are 32 bits long, this allows a theoretical maximum of 4 294 967 296
hosts to be addressed, as has been noted. The class structure introduced in the previous
5.2 IP PROTOCOL SUITE OVERVIEW 173


Table 5.4 IP addresses with special signi¬cance
Address Function
0.0.0.0 Refers to the default network
127.0.0.0 Reserved for loopback. Usually 127.0.0.1 is used to refer
to the local host. This address is used for testing
purposes
An address with all network bits = 0 Refers to ˜this™ network
An address with all host bits = 0 Refers to the network itself, e.g. the address 135.34.0.0
refers to network 135.34. This notation is used in
routing tables
A network or host address of all 1s Refers to ˜all™ hosts
255.255.255.255 (all 1s) Broadcast address


Table 5.5 Reusable private addresses
Class A 10.0.0.0
Class B 172.16.0.0“172.31.0.0
Class C 192.168.0.0“192.168.255.0


section reduces this host count to actually about 3.7 billion. In fact the address space is
depleted still further by the wasting of unused address space within the class B space.
For most organizations, a class A network with 16 million addresses is too big but
conversely a class C network with 254 hosts is too small.1 Therefore most organizations
would like a class B network address assigned. The implication of this is that an orga-
nization with 2000 hosts will be assigned a class B address with its 65 534 addresses,
even though this is far more than it requires. It will in fact have wasted 97% of its
allocated address space. The other problem is that there are only 16 383 class B network
address available. If every operator that asks for one is assigned one they will soon run
out. Another possibility is to assign eight class C addresses to the operator. This helps
in the address allocation problem but causes a problem on the Internet in terms of an
explosion in the size of routing tables. Now this organization will require eight entries in
each routing table instead of the one required for the class B allocation.
To allow multiple IP addresses (called address blocks) to be assigned without causing
the increase in routing table sizes, a new scheme called classless inter-domain routing
(CIDR) was devised (RFC 1519). With CIDR the network address is expressed as follows:

IP address/mask size

The IP address is expressed in the conventional dot decimal notation, for
example 175.6.0.0. The mask size that follows represents the number of bits in the network
portion of the address, i.e. the network part of the address that is to be used for routing.
This allows numbers of class C addresses to be blocked together for routing purposes.
For example, if an organization requires 1000 addresses, then it will be allocated four
blocks of class C (4 — 254) = 1016 addresses. This is known as supernetting. For CIDR

1
Known as the ˜Goldilocks™ problem.
174 IP APPLICATIONS FOR GPRS/UMTS


to work, these blocks must be contiguous. The operator can then be assigned the following
four class C addresses:

196.220.0.0, 196.220.1.0, 196.220.2.0 and 196.220.3.0
These can be written as 196.220.0.0/22, which will allow any packet on the Internet
with the same ¬rst 22 bits to be routed to this network. This will provide the operator
with 1016 host addresses but only add one entry to the routing tables within the Internet
(instead of four).
As a ¬nal note CIDR is merely intended as a stopgap until the widespread introduction
of IPv6 since the address size will be expanded to 128 bits, providing a vast address
space.


5.2.4 Transmission control protocol (TCP)
The transmission control protocol (TCP) is designed to provide a reliable connection
between communicating hosts. This is a connection-oriented service but the underlying
internetworking protocol is the unreliable IP datagram service. To the hosts it appears that
they have a dedicated circuit whereas in reality it is based on a datagram service. TCP
not only guarantees the delivery of packets across the network, it also puts the stream of
packets back in the correct order at the receiving host. Each packet is checked for errors
by the application of a checksum that covers both the TCP header (Figure 5.4) and the
data payload. To guarantee the delivery of data TCP uses a technique called automatic
repeat request (ARQ). When packets are received at the destination an acknowledgement
is sent back to the source. If the acknowledgement is not received within a certain time
(retransmit timeout) the packet is sent again. To make sure that repeated packets are not
mistaken for new transmissions each new packet (not repeated) is marked with a unique

31
8
0 4 Number of bits
16


Source Port Destination Port

Sequence Number

Acknowledgement Number
UAPRSF
Data
RCSSYI
Reserved Window
Offset GKHTNN
Checksum Urgency Pointer

Optional part + padding (if necessary)

Upper Layer Data (eg http: get page request)


Figure 5.4 TCP header
5.2 IP PROTOCOL SUITE OVERVIEW 175


32-bit number called its sequence number. This number is also used to make sure that data
is received in the correct order. Also note that in the TCP header (see Figure 5.4) there
is a 32-bit acknowledgement number. This is used to match up each acknowledgement
with a block of transmitted data marked with a particular sequence number and length.
Apart from guaranteeing the sequenced ¬‚ow of data from sender to receiver, TCP also
handles issues such as ¬‚ow and congestion control. Flow control is used to allow a receiver
that is becoming overloaded with data to slow down a fast sender. The receiver sets a
window size that determines the maximum amount of data the sender can send. By setting
a window size of zero the receiver can stop the ¬‚ow of data entirely. Congestion control
protects the network itself from getting overloaded. With TCP it is assumed that packet
loss is due to congestion on the network. This is because a highly congested router will
lose packets due to buffer over¬‚ow. Every time TCP has to retransmit a packet it slows
down its transmission, assuming that the lost packet was due to congestion on the network.
Note that this technique does not make much sense for TCP running over a wireless link
since packet loss is likely due to interference on the link rather than congestion.
TCP is a connection-oriented protocol. Before sending data a connection must be made
with the remote host. The connection set up consists of three messages and is therefore
called a three-way handshake. This process is shown in Figure 5.5. The handshake serves
two basic purposes: ¬rst, ensuring that each end is ready to receive data and, second,
allowing each party to agree on the initial sequence numbers each end will expect to
receive.
Once the connection has been made data can be transferred in both directions between
the two hosts. When the hosts have ¬nished data transfer they terminate the connection.
In general terms clients initiate TCP connections and servers wait (or listen) for incoming
connections. This relationship is of particular signi¬cance when considering the use of
port numbers.
The TCP header starts with two 16-bit ¬elds called port numbers, which are used to
route data to a particular application or service (Figure 5.6). This technique is called port
multiplexing. The port numbers are needed because there can be many different software
applications using the IP connection to the network running on a particular machine (for
example email, web browsing, ¬le transfer). To handle these different streams of data each
application is allocated a particular port number that is used to route the packets within
the client or server device. Port numbers are allocated differently at the client and server
end of the connection. At the server end each service is de¬ned by a different well-known


Hi, my
ISN
ok to c is 123456
onnec
t?
Source Destination
6
12345
ISN is 23
your
Sure, 0
is 789
my ISN
Ok, yo
ur ISN
is 789
023
conne
cted


Figure 5.5 TCP three-way handshake
176 IP APPLICATIONS FOR GPRS/UMTS


Request source port=2095
Request dest port=80
Client Device
Web Server
www.company1.com
Request source port=80
Internet Request dest port=2095
Explorer
Request source port=2093
Request dest port=80 Web Server
Netscape TCP www.abc.org
Request source port=80
Request dest port=2093
eMail Request source port=2104
Mail Server
Request dest port=25

Request source port=25
Request dest port=2104

Figure 5.6 TCP port multiplexing


port number (for example decimal 80 for HTTP web access). When the client opens a
connection with the server the TCP software in the client will allocate a local port number
from its free list. It then sends a TCP connection request with a source port set to the
locally allocated port and the destination port set to the well-known port number. When
the server receives the connection request it sends back a connection con¬rm with the
source and destination ports reversed. This routes the con¬rm back to the originating appli-
cation. When the con¬rmation is received at the client it is acknowledged, completing the
three-way handshake. Figure 5.6 shows a client running three applications, two browsers
(Netscape and Internet Explorer) connected to different websites and an email client.
In summary, TCP provides a reliable connection stream between two end points on
the network. It controls the ¬‚ow of data to avoid receiver overrun (¬‚ow control) and
also protect against overloading the network (congestion control). TCP together with IP
provides a basic end-to-end reliable data transfer and for this reason the IP network service
is commonly referred to by the conjugation of these protocol acronyms, i.e. TCP/IP.



5.2.5 User datagram protocol (UDP)
TCP provides a very good service where reliability is paramount but is not generally
suitable when delay is critical. The problem occurs if a packet is lost and TCP retransmits
data: the retransmission takes time and this introduces delay into the overall transmission.
There are applications such as voice and video transfer where the occasional loss of data
is much less important than its timely delivery. For example, with voice if a single voice
sample is lost this may not be perceivable to the listener (or at worst be heard as a slight
click) whereas increased delay can result in the voice call being unusable.
For these reasons another protocol called UDP was developed (see Figure 5.7), which
provides the port numbering facility and error checking facilities of TCP with none of the
other services. UDP is often the preferred choice for delay-sensitive traf¬c since packets

<<

. 38
( 132 .)



>>