Kasim Net 3
Kasim Net 3
Kasim Net 3
Parts of OSI have influenced Internet protocol development, but none more than the abstract
model itself, documented in OSI 7498 and its various addenda. In this model, a networking
system is divided into layers. Within each layer, one or more entities implement its
functionality. Each entity interacts directly only with the layer immediately beneath it, and
provides facilities for use by the layer above it. Protocols enable an entity in one host to
interact with a corresponding entity at the same layer in a remote host.
The seven layers of the OSI Basic Reference Model are (from bottom to top):
The original Internet protocol specifications defined a four-level model, and protocols
designed around it (like TCP) have difficulty fitting neat ly into the seven-layer model. Most
newer designs use the seven-layer model.
The OSI Basic Reference Model has enjoyed a far greater acceptance than the OSI protocols
themselves. There are several reasons for this. OSI's committee-based design process bred
overgrown, unimaginative protocols that nobody ever accused of efficiency. Heavy European
dominance helped protect their investments in X.25 (CONS is basically X.25 for datagram
networks). Perhaps most importantly, X.25 data networks never caught people's imagination
like the Internet, which, with a strong history of free, downloadable protocol specifications,
has been loath to embrace yet another networking scheme where you have to pay to figure
how things work.
And why should we? OSI's biggest problem is that doesn't really offer anything new. The
strongest case for its implementation comes from its status as an "international standard", but
we already have a de facto international standard - the Internet. OSI protocols will be around,
but its most significant contribution is the philosophy of networking represented by its
layered model.
If the Internet community has to worry about anything, it's the danger of IETF turning into
another ISO - a big, overgrown standards organization run by committees, churning out
thousands of pages of rubbish, and dominated by big business players more interested in
preserving investments than advancing the state of the art.
The role of a network interface within the system is similar to that of a mounted block device.
A block device registers its features in the blk_dev array and other kernel structures, and it
then "transmits" and "receives" blocks on request, by means of its request function. Similarly,
a network interface must register itself in specific data structures in order to be invoked when
packets are exchanged with the outside world.
There are a few important differences between mounted disks and packet-delivery interfaces.
To begin with, a disk exists as a special file in the /dev directory, whereas a network interface
has no such entry point. The normal file operations (read, write, and so on) do not make sense
when applied to network interfaces, so it is not possible to apply the Unix "everything is a
file" approach to them. Thus, network interfaces exist in their own namespace and export a
different set of operations.
Although you may object that applications use the read and write system calls when using
sockets, those calls act on a software object that is distinct from the interface. Several
hundred sockets can be multiplexed on the same physical interface.
But the most important difference between the two is that block drivers operate only in
response to requests from the kernel, whereas network drivers receive packets
asynchronously from the outside. Thus, while a block driver is asked to send a buffer toward
the kernel, the network device asksto push incoming packets toward the kernel. The kernel
interface for network drivers is designed for this different mode of operation.
Network drivers also have to be prepared to support a number of administrative tasks, such as
setting addresses, modifying transmission parameters, and maintaining traffic and error
statistics. The API for network drivers reflects this need, and thus looks somewhat different
from the interfaces we have seen so far.
The network subsystem of the Linux kernel is designed to be completely protocol
independent. This applies to both networking protocols (IP versus IPX or other protocols) and
hardware protocols (Ethernet versus token ring, etc.). Interaction between a network driver
and the kernel proper deals with one network packet at a time; this allows protocol issues to
be hidden neatly from the driver and the physical transmission to be hidden from the
protocol.
When a driver module is loaded into a running kernel, it requests resources and offers
facilities; there's nothing new in that. And there's also nothing new in the way resources are
requested. The driver should probe for its device and its hardware location (I/O ports and IRQ
line). The way a network driver is registered by its module initialization function is different
from char and block drivers. Since there is no equivalent of major and minor numbers for
network interfaces, a network driver does not request such a number. Instead, the driver
inserts a data structure for each newly detected interface into a global list of network devices.
£