Copy Link
Add to Bookmark
Report
The Discordant Opposition Journal Issue 05 File 05
::::::::::::::::::::::::::::::::::::::::::::::::::::::::May/99
::: The Discordant Opposition Journal ::: Issue 5 - File 5 :::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:Protocols and Such:
Digital Avatar
The internet and all the glorious resources out there would have been
strictly prohibited (until a different solution came along) if TCP/IP
would not have been developed. This is really everything that makes it
work. Without it, connecting to other computers would be many, many
times more a task than it is.
Perhaps no organization has more complex networking requirements than
the U.S. Department of Defense. Simply enabling communication among
the wide variety of computers found in the various services is not
enough. DoD computers often need to communicate with contractors and
organizations that do defense-related research, such as universities.
Defense-related network components must be capable of withstanding
considerable damage so that the nation's defenses remain operable
during a disaster. TCP/IP enables such communication, regardless of
vendor or hardware differences, to occur. The fact that the DoD
initiated research into networking protocols (investigating the
technology now known as packet switching) is not surprising. In
fact, research on the protocols that eventually became the TCP/IP
protocol suite began in 1969.
There were several important goals for this research. These goals
are the foundation of TCP/IP.
Common Protocols;
The DoD required a common set of protocols (communications rules)
that could be specified for all networks. Common protocols would
greatly simplify the procurement process because the systems could
communicate with each other.
Interoperability;
If equipment from various vendors could interoperate, the system
development efficiency could be improved and competition among
vendors would be promoted.
Robust Communication;
A particularly dependable network standard was required to meet the
nation's defense needs. These protocols needed to provide reliable,
high-performance networking with the relatively primitive wide area
network technologies then available.
Ease of Reconfiguration;
Because the DoD depended on the network, reconfiguring the network
and adding and removing computers without disrupting communication
needed to be possible.
In 1968, the DoD Advanced Research Project Agency (then called DARPA,
but since renamed ARPA) initiated research into networks using the
technology now called packet switching the capability to address a
packet and move it to the destination through different networks. The
first experimental network connected four sites: the University of
California at Los Angeles (UCLA), the University of California at Santa
Barbara (UCSB), the University of Utah, and SRI International. Early
tests were encouraging, and additional sites were connected to the
network. The ARPAnet, as it came to be called, incorporated 20 hosts
by 1972.
NOTE: You will encounter the terms Internet and internet, and should
be aware of an important distinction between them. An internet (short
for internetwork) is any network comprised of multiple, interconnected
networks, normally within one company (also referred to as an intranet).
The Internet is the global internetwork that traces its lineage back to
the ARPAnet.
In 1986, groundwork was laid for the commercialization of the ARPAnet.
The ARPAnet backbone was dismantled, replaced by a network funded by
the National Science Foundation. NSFnet now functions as the Internet
backbone. The Advanced Network Services (ANS) manages the NSFnet. The
initial set of TCP/IP protocols was developed in the early '80s. These
protocols became the standard protocols for the ARPAnet in 1983. The
protocols gained popularity in the user community when TCP/IP was
incorporated into version 4.2 of the BSD (Berkeley Standard
Distribution) UNIX. The BSD version of UNIX is used widely in educational
and research institutions. It became the foundation of several commercial
UNIX implementations, including Sun's SunOS and Digital's Ultrix. Because
BSD UNIX established a relationship between TCP/IP and the UNIX operating
system, the vast majority of UNIX implementations now incorporate TCP/IP.
Many different people were involved in the development of the TCP/IP
protocol suite. This presented a need to facilitate the sharing of ideas.
A process did evolve that enabled everyone to comment on the proposed
definitions of the different standards. Basically, someone would draft
a standard and the document would be published for review. This became
the Request for Comments (RFC) process.
On its way to becoming a standard, a protocol passes through different
stages. The protocol starts as a Proposed Standard. It may be promoted
to a Draft Standard, and finally to a full-fledged Standard, an official
standard protocol for the Internet. At each stage, the protocol faces
review, debate, implementation, and testing. Proposed Standards, for
example, go through at least six months of review before they may be
promoted to a Draft Standard. In general, promoting a standard requires
two independent implementations of the protocol.
Obviously this process would break down if no one actually monitored it
and made decisions when required. The body that takes care of this for
the TCP/IP protocol is the Internet Activities Board (IAB). The IAB
coordinates design, engineering, and management of the Internet. The IAB
has two task forces: the Internet Engineering Task Force (IETF) and the
Internet Research Task Force (IRTF). Unlike other groups, the IAB is
made up of volunteers rather than the government, DoD, or a commercial
vendor.
Two organizations work with the IAB: the Federal Networking Council and
the Internet Society. The Federal Networking Council represents all
agencies of the United States federal government involved with the
Internet. The Internet Society is a public organization that takes its
membership from the entire Internet community. Both organizations
provide input on Internet policy and standards.
The IETF is responsible for specifying the Internet protocols and
architecture. By its own description, the IETF is not a traditional
standards organization, although many specifications produced become
standards. The IETF is made up of volunteers who meet three times a
year to fulfill the IETF mandate. The IETF has no membership. Anyone may
register for and attend meetings. The work of the IETF is organized into
various areas that change over time. The one consistent factor is the
IETF's role as the testing and implementation arm for TCP/IP growth and
development.
In recent years, new technologies have appeared rapidly on the Internet. A
case in point is the World Wide Web, which depends on the HyperText Transfer
Protocol (HTTP). The web and HTTP were in wide use long before RFC 1945
established an Internet standard for HTTP version 1.0. Increasingly,
evolution of the Internet is being led by network heavy hitters such as
Microsoft and Netscape. The slow standards process fails to satisfy vendors
who want to establish themselves as leaders on the Net.
The only other serious work that has been done comes from the International
Standards Organization in the form of the Open Systems Interconnection (OSI).
OSI is another set of protocols that provides a similar functionality to
TCP/IP. It was widely assumed that they would replace TCP/IP as the open
protocol solution, but this has not come to pass. One obstacle with the
OSI protocols is the fact that they are governed by international bodies,
which sometimes slows down the development process.
------
A Few Services and protocols associated with TCP/IP:
Telnet - A remote terminal emulation protocol that enables clients to log
on to remote hosts on the network.
FTP - A file transfer application that enables users to transfer files
between hosts. Stands for the File Transfer Protocol.
SNMP - Used to remotely manage network devices. Stands for the Simple Network
Management Protocol.
DNS - Provides meaningful names like achilles.mycorp.com for computers to
replace numerical addresses like 123.23.32.23. Stands for the Domain Name
System.
HTTP - This protocol, the core of the World Wide Web, facilitates retrieval
and transfer of documents. Stands for the HyperText Transfer Protocol.
------
To make TCP/IP work, each and every device on a TCP/IP network requires a
unique address. An IP address identifies the device to all the other devices
on the network. IP addresses are made up of two parts. The first part of an
IP address identifies your network ID. With the Internet spanning the entire
globe, every network or part of a network must have a unique ID. This ID is
used to route the information being sent to the correct network. The other
part of your IP address is the host ID, a unique number that identifies each
computer and device on your network that talks using TCP/IP.
A TCP/IP address is, simply put, a 32-bit binary number. Looking at an address
as 32 zeros or ones is difficult for humans, so we view the address as a dotted
decimal address in the following format: 198.53.147.153. Each of the four
numbers represents 8 bits of the address and is referred to as an octet.
Three main classes of addresses exist: Classes A, B, and C. The most obvious
difference between the three main types of addresses is the number of octets
used to identify the network ID.
Class A uses the first octet only; this leaves 24 bits (or three octets) to
identify the host. Class B uses the first two octets to identify the network,
leaving 16 bits (two octets) for the host. Class C uses three octets for the
network ID, leaving 8 bits (one octet) for the host.
Class A: 72.0.0.0
Class B: 112.34.0.0
Class C: 198.173.202.0
A couple of rules determine what you can and cannot use for addresses. Neither
the network ID nor the host ID can be represented by all 0's or by all 1's,
because each of these conditions has a special meaning.
Knowing that the first octet represents the first 8 bits of the address, and
by knowing the starting bits for the classes of addresses, you can see the
first octet ranges for the respective classes in the table below.
Note that Class A does not start with 00000000, since that network ID has a
special meaning, and does not end with 01111111 (decimal 127) since that is
reserved for loop back. Because the Class A addresses use only the first octet
to identify the network ID, there are a limited number of them (126; 127 is
reserved). Each of these 126 networks, however, can have many hosts on it: 2
to the 24th power (the remaining 24 bits) hosts minus two (the host IDs that
are all 0's and all 1's) equals 16,777,214 hosts on a single network.
Class B addresses use the first two octets. The first 2 bits, however, are
set to binary 10. This leaves 14 bits that can be used to identify the
network: 2 to the 14th possible combinations (6 bits in the first octet and
8 from the second) 16,384 network IDs (because the first two digits are 10,
you don't have to worry about an all 0's or all 1's host ID.)
Each of those network IDs has 16 bits left to identify the host or 65,534
hosts (2 to the 16th minus 2). Class C networks use three octets (or 24
bits) to identify the network. The first three bits, however, are always
110. This means that there are five bits in the first octet and eight in
each of the other two that can be used to uniquely identify the network
ID or 2 to the 21st possible networks (2,097,152) each of which has 8 bits
for hosts or 254 (2 to the 8th minus 2).
The TCP/IP model for networking has only four layers. Each layer covers
more functions. They are, Application, Transport, Internet, and Network
Access.
The Application layer in TCP/IP combines the functions of both the Application
and Presentation layers in the OSI model. The Application layer contains
various services (protocols) such as NNTP (Network News Transfer Protocol) or
SMTP (Simple Mail Transfer Protocol). The WinSock API is also in the
Application layer.
Just as in the OSI model, the Transport layer is the actual language of
the network. All requests use one of two different transport protocols
either TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).
The TCP/IP Internet layer replaces the Network layer in the OSI model. It
deals not only with finding other hosts (computers) on the same network,
but with routing information (in the form of packets) to other networks. The
TCP/IP Network Access layer replaces the Data Link layer. This layer handles
framing the data and transmitting it to the wire.
TCP/IP does not use computer names in its communications. Rather, it uses
the IP address of the host as the destination for the packet it will send.
This means that some method of turning \\comp1 (a NetBIOS computer name)
or www.microsoft.com (a host name) into an IP address must exist. Otherwise
you would have to memorize many different IP addresses.
Many different protocols can be located at the Application layer. All the
TCP/IP protocols (applications) and the NetBIOS services, however, rely on
the services of two main APIs: WinSock and NetBIOS over TCP/IP (NBT). Windows
Sockets (WinSock) provides socket-oriented services to the TCP/IP utilities
that can exist at the Application layer and also provides services to NetBIOS.
A socket combines a computer's host address with a port number designating a
service or application running on the computer. The port numbers serve as end
points for communication between the hosts.
The port numbers are not normally the same on both ends; services usually use
well-defined and well-known port numbers. These well-defined port numbers are
controlled and assigned by the Internet Assigned Numbers Authority. When you
start a service on your system, the service registers its assigned port number
in the system and anything that comes in for that port is sent to that service.
Using port numbers allows the WinSock interface and all the underlying layers
to ignore what the information is and to just move it from point to point.
Included in the information is the address, transport layer protocol (UDP or
TCP), and port number that sent the information; this information enables the
application to respond directly to that client running on the remote system.
The first 1,024 ports are reserved and are used only for services. Any port
number up to 65,536, however, is valid. To look at the whole process, the
service starts on the server and registers its port number (thereby monitoring
that port as shown here). On the other host, the client side application starts.
It also registers a port number that it will use (any available port above
1023). The client application can now start to send information to the server
by sending to the IP address, transport protocol, and port number. The server
then responds to the IP address, protocol, and port number from which it
received the information.
In this way, there is no reliance on computer names or other upper-level
information and absolutely no restriction on which port any particular service
can use. Windows NT uses NetBIOS when you work with its redirector and server
services (the base Application layer components of Microsoft networking). This
means that it requires the underlying protocol to handle requests in the forms
of NetBIOS commands.
You have just seen that the TCP/IP stack does not use names, nor does it register
each service with a name/number combination. On the surface, this would seem to
indicate that NT cannot use TCP/IP for a protocol; but, it does. To do this,
another layer has to be brought in that maps (or translates) the NetBIOS command
into a series of TCP/IP port numbers. This enables the NetBIOS to have a port
for transmitting and receiving data, establishing and releasing sessions, and
handling NetBIOS names all over TCP/IP.
Not surprisingly, the component that handles this function is called NBT or
NetBIOS over TCP/IP. It is responsible for the mapping of, and communications
between the NetBIOS interface and the various WinSock ports. This means that
all communications over TCP/IP must go through the WinSock interface. NBT has
also been referred to as
NetBT.
WinSock has to rely on the Transport layer to deal with data moving to and from
it. This is handled by the two Transport layer protocols: TCP and UDP. Computers
can have different types of conversations with each other. UDP (User Datagram
Protocol) provides no guarantee that the packets will get through. TCP
(Transmission Control Protocol), on the other hand, creates a session, and can
then guarantee delivery. TCP is used to provide a connection-oriented delivery
service for the higher-level protocols.
To do this, TCP must first establish a session with the remote communicating
host. It does this by means of a three-way handshake. First the host initiating
the communications sends a packet to the other host that contains information
about itself and a SYN (or synchronize flag) telling the other host that a
session is requested.
The other host receives this packet and responds with information about itself
the SYN flag and an ACK (acknowledgment) of the information that it received.
Finally the first host ACKs the information it received from the other, and a
session now exists between the two systems. At the end of the communication
session, a similar three-way handshake is used to drop the session with the
remote host.
This ensures that both of the hosts are through transmitting. It closes the
session cleanly. Compared to TCP, UDP is simple: The data from the upper-layer
protocol is encapsulated and sent. UDP is used to send and receive simple
messages; no session is required. The UDP protocol is used, for example, to
send and receive broadcast messages.
The Internet layer has four main protocols. These protocols work together to
provide a best-effort delivery service (guarantees are the responsibility of
TCP or higher-level applications). IP (Internet Protocol) needs only to know
which IP address to send the data to and the protocol on the other system
(TCP or UDP) that should receive it.
All devices that use TCP/IP have an Internet layer that includes the routers
that provide the backbone for communications across the network. The IP is
responsible for taking the packet and determining whether the packet is for
the local network. If not, the IP must find a route for the packet to the
destination network and eventually the destination host.
To understand how the IP determines whether a host is on the local network,
you must look at the subnet mask and what its function is. As you saw earlier,
the IP address that each host has is a combination of the network ID and the
host ID. The address itself is 32 bits long. A varying number of bits are
used to identify the network and the host.
The discussion here keeps the subnetting simple and works with the standard
subnet masks. In a later unit, you will look at using custom subnetting and
supernetting. A logical AND enables you to compare two binary numbers and
come up with a third that describes the state of the other numbers. What makes
it important is that you can use it with subnet masks to split an IP address
into a network ID and a host ID. Address Resolution Protocol (ARP) is now
used to determine the physical address of the destination host.
The physical or MAC (Media Access Control) address is used by network adapter
cards to communicate with other network adapter cards on the local network.
If the destination host is on a remote network, the MAC address of the router
is used. So ARP, using either its cache of resolved addresses or by broadcast,
finds the MAC address to send the packet to. In the case of a local machine,
this is the actual machine. In the case of a remote system, it is the router.
Remember that the router also has the IP layer and so it has ARP.
The router finds the MAC address or the host (or another router) on the other
network. You never receive the information about the other hosts MAC address;
it would be pointless.After ARP has the address, IP sends the packet to that
address. Sometimes, however, when talking to hosts on other networks, your
packet will have problems. When this happens, you receive notification. ICMP
is a diagnostics and messaging protocol used in the TCP/IP stack to enable
communications to continue.
ICMP handles such routine functions as PING. It also handles important issues
such as reporting unreachable networks. When you are considering a network
that spans the globe, you have to expect that problems connecting with
specific hosts will sometimes arise. A few protocols now in place help to
prevent this. Dynamic Routing is one that provides alternative routes if a
link goes down.
Since it may take a long time to try a lot of alternative routes, a time out
value is given to each packet on the Internet. The time out represents the
maximum number of hops that a packet can make. By default in Windows NT 4.0,
the Time To Live, or TTL, is 128 seconds. Each router decrements the TTL by
one for every second that the packet is in the router. If the TTL expires or
there is no route to the network you are trying to reach, you receive an ICMP
message (request timed out or destination host unreachable). This prevents
packets from circulating around the Internet forever, using up bandwidth
trying to find a route that may not exist.
ICMP also works to manage the flow of data on the Internet by directing
traffic. If your router becomes overloaded, for example, and is unable to keep
up, it might send a source quench message to your system. This tells your
system to stop sending for a while. Routers also send an ICMP message if they
detect that a better route to your destination is available. This would be an
ICMP redirect message, telling your system to use another router.
IGMP is the last of the protocols that reside in the lower layers of the
TCP/IP stack. IGMP handles sending and receiving when groups of computers
are involved. Sending to groups of computers is used to provide the systems
that receive the information with a live feed. This is multicasting, where
you get a straight pipe of data.
In multicasting, you send the information from your system to a special IP
address (a Class D address). You should remember that are Class A, B, and
C addresses. Class D, however, is only mentioned here; it is not valid as
a host IP address. When a system multicasts, it chooses an IP address (this
has to be unique on the network) and sends all the information to that
address. If you want to receive the information, you must tell your system
to listen for that address.
The problem is that your router does not know that it should listen for that
address, and the packets don't get into your network. IGMP tells your router
that you wish to listen to that address, enabling you to receive multicasts.
Just as in the OSI model, the Network Access layer is responsible for framing
packets of information for the underlying topology and transmitting the data
on the wire. The Network Access layer also grabs the frames off the network.
If they are for that MAC address or for broadcast/multicast, the Network
Access layer passes them up to the appropriate protocol.
There. Hope you have a little more background on the protocols and services
out there.
Peace|Out.
-----
: Digital Avatar :
: lambesis@gmx.net :
: http://damatrix.cjb.net :
