|
|
|
Managing Multivendor Networks
  
- 10 -
TCP/IP
An Overview of TCP/IP
he TCP/IP network architecture distinctly influences how multiple vendor networks
are constructed and operated. The importance of TCP/IP in today's market is particularly
amazing when you consider that TCP/IP is a public domain architecture. Unlike
most private, commercially developed network architectures (for example, IBM's Systems
Network Architecture (SNA) or Digital's DECnet), TCP/IP was developed under the auspices
of the U.S. government. This development environment made TCP/IP an open network
because the TCP/IP architecture was not aligned with any particular vendor or machine
architecture.
A Brief History of TCP/IP
Just how did TCP/IP rise to such a level of importance? To fully understand this
you must go back to 1957--the year the Soviet Union launched Sputnik, the world's
first artificial satellite. When Sputnik went into orbit, President Eisenhower decided
that the United States needed to focus its efforts on meeting and exceeding Soviet
technology, so he created the Advanced Research Projects Agency (ARPA). The
purpose of ARPA was to conduct long-term research and development projects on behalf
of the U.S. government.
As the number of research projects handled by ARPA grew, so did the number of
researchers and sub-contractors, and the need to share resources. When computers
and computing devices became important research tools in the late 1960s, ARPA decided
to create a network that would enable ARPA researchers and sub-contractors to share
the growing number of computer systems. This network came to be known as ARPANET.
Originally, ARPANET used packet-switching technology that was the precursor to
the X.25 standard for packet-switching networks. Simple tools were created and deployed
to allow terminal access, file transfer, and simple mail--these tools exist today
under TCP/IP as Telnet, File Transfer Protocol (FTP), and the Simple Mail Transfer
Protocol (SMTP).
ARPANET use continued to grow steadily through the 1960s and into the 1970s. In
the 70s, however, the fledgling networking industry was going through significant
technology and design changes. On the technology front, the Ethernet LAN hit the
market, offering new levels of performance for local connections. In the same timeframe,
the X.25 standard was approved by the CCITT, creating a universal standard for packet-switching
networks.
On the design front, Xerox released its Xerox Networking Services (XNS) architecture.
Although XNS was not a commercial success, it was a major influence on the design
and im-plementation of Novell NetWare and IBM/Microsoft's LAN Manager. However, Xerox
was not alone in developing and offering formal network architectures--IBM
released its System Network Architecture, and Digital Equipment Corporation introduced
its Digital Network Architecture (DNA), better known as DECnet.
Given this backdrop of new network links and architectures, ARPA decided to adopt
TCP/IP as the standard network architecture for the ARPANET. ARPA saw TCP/IP
as a tool that would enable them to quickly embrace new technology (like Ethernet
and X.25) as it became available. As a result of ARPA's interest and investment,
most of the major TCP/IP protocols were developed and deployed by the end of the
1970s.
The use of TCP/IP in ARPANET proved so successful that ARPA issued a directive
for all ARPANET hosts to use TCP/IP by the mid-1980s. This directive is a milestone
in the history of TCP/IP, because it insured that any computer manufacturer who wanted
to sell equipment to ARPA had to support TCP/IP, regardless of what their "native"
network architecture happened to be. So, thanks to the U.S. government, some level
of TCP/IP has been implemented in virtually every mainstream computer system.
As the use of ARPANET continued to grow and prosper, the network underwent dramatic
changes in the 1980s. President Reagan renamed ARPA to Defense Advanced Research
Projects Agency (DARPA) and thus ARPANET became DARPANET. Military agencies became
uncomfortable with the amount of non-military activity occurring over DARPANET and
so they split off and formed their own network, named MILNET.
The beginning of the end of DARPANET occurred when the National Science Foundation
(NSF) formed a separate network for science and academic research in 1985. The network,
NSFnet, was modeled after DARPANET, and in the spirit of sharing, the two networks
were interconnected. Over the course of the late 1980s, NSFnet absorbed DARPANET
and became what we now know as the Internet (but that's another story).
More importantly, although ARPANET never made it into the 1990s, the network architecture
it gave birth to--TCP/IP--lived on and prospered. For years, TCP/IP was the protocol
suite of choice for UNIX networks. Then, in the 1990s, almost all of the major computer
and network manufacturers followed suit and incorporated support for TCP/IP into
their products.
For example, Microsoft now looks at TCP/IP as its protocol of choice for NT networks,
and IBM has migrated a number of connectivity services from SNA to TCP/IP. In short,
TCP/IP has established itself as the premier protocol suite for many corporate networks.
Core TCP/IP Protocols and Services
The TCP/IP network architecture is named after its two core protocols--the Transmission
Control Protocol (TCP) and the Internet Protocol (IP). In truth, these two protocols
are only the tip of the iceberg--when you start digging into a TCP/IP network, you
typically encounter dozens of lower-level service and utility protocols. In this
chapter, you will review a number of these protocols, starting with the following
core TCP/IP protocols:
- The Internet Protocol (IP). This protocol is responsible for the delivery
of messages between systems operating within the same network or operating in different
(but interconnected) networks. As part of this function, the Internet Protocol handles
all network-level addresses--for example, the Internet Protocol is ultimately responsible
for moving a message from a system at address "192.0.0.101" to a system
at address "192.0.0.102". (And that's also why these addresses are referred
to as Internet addresses or IP addresses.) The Internet Protocol is
a network-level protocol that acts as a carrier for transport-level protocols. The
two main protocols that operate at the transport level are TCP/IP and UDP.
- The Transmission Control Protocol (TCP/IP). This is a connection-oriented
protocol that guarantees end-to-end delivery. TCP is used as the primary transport
for the majority of the TCP/IP utilities.
- The User Datagram Protocol (UDP). This is a connectionless protocol that
does not guarantee end-to-end delivery. Because it is connectionless, UDP is faster
than TCP. UDP is typically used for real-time (client/server) program-to-program
applications or networking services that require the fastest possible response time.
TCP and UDP, in turn, carry application-oriented services (sometimes referred
to as application protocols). Although there are literally hundreds of services
that can run under the umbrella of TCP or UDP, the four major services are:
- Telnet. This service provides a means for a TCP/IP workstation or a terminal
attached to a TCP/IP host to access a second host system. Telnet will be discussed
in more detail later in this chapter.
- The File Transfer Protocol (FTP). This service enables the movement of
text and binary files between systems. FTP is a bulk file transfer service
that is unaware of field-level contents, although most FTP implementations have provisions
for ASCII/EBCDIC conversion. FTP can be used on an interactive or programmatic basis.
- The Simple Mail Transfer Protocol (SMTP). This service handles the routing
of mail in a TCP/IP network. Note that SMTP is a delivery service that does not communicate
directly with end users. The end-user side of mail is handled by a front-end program
that deals with the user-oriented mail issues (that is, composing, reading, forward,
filing, and so on).
- The Simple Network Management Protocol (SNMP). SNMP provides the framework
for systems to report problems, configuration information, and performance data to
a central network management location. Like SMTP, SNMP is not an end-user service--SNMP
reports its information to a central programs that analyzes the data and interacts
with an operator.
Figure 10.1 illustrates how these core protocols and services relate to one another.
And remember, these protocols and services are really just a sample of the entire
set of TCP/IP protocols and services. Later in this chapter we will look at additional
protocols and services commonly used in many TCP/IP networks.
FIG. 10.1 Relationship of Core Protocols and
Services in a TCP/IP Architecture
The TCP/IP Client/Server Model
Services such as Telnet, FTP, and SMTP follow the client/server model. This means
that a user initiating a service request uses client software and the request is
received by server software operating in the background of the target system. The
client/server model is certainly not new to the TCP/IP environment--in fact, the
entire architecture for TCP/IP is client/server oriented.
Under the TCP/IP client/server model, services are assigned sockets. Sockets
are logical ports associated with the TCP and UDP transport protocols. Programs can
attach to sockets in order to communicate with other partner programs. All of the
major TCP/IP protocols and applications services have defined socket numbers. For
example, Telnet uses TCP socket 23, FTP relies on TCP sockets 20 and 21, and SMTP
is assigned TCP socket 25.
When a client wants to establish a connection to its server counterpart, it initiates
either a TCP or UDP connection to the corresponding socket number on the target system.
For example, when you run the Telnet client and initiate a connection to a host,
the Telnet client requests a TCP connection to socket 23 on the target system. Figure
10.2 shows this basic connection architecture.
FIG. 10.2 Basic Connection Architecture in
a TCP/IP Client/Server Model
On the other side of the equation, when the server system receives a socket connection,
it normally starts a new copy of the server program to handle the new client connection.
The client and server then establish a new socket assignment they can use for the
duration of the connection. This approach enables multiple client/server conversations
to use the same socket number to initiate connections.
After the client and server programs have established a link to one another, they
can start interacting. In many cases, the initial interaction often involves negotiation
a process where the client and server module agree on what special functions or capabilities
will be available during the session. After negotiation is complete, the end-user
can begin using the service.
How exactly does a client system initiate a link to a server system? Under the
TCP/IP architecture, connections can be initiated using the IP name of the server
system or IP address of the server system. As explained in the following sections
of this chapter, the IP name and IP address define the network path that leads from
the client system to the server system.
TCP/IP Host Name Resolution
Every system in a TCP/IP network normally has both an IP name and an IP address.
These two variables work together to enable end-to-end connections between TCP/IP
hosts. Unfortunately, all TCP/IP hosts do not support the same methods and protocols
for assigning IP numbers and translating IP names into IP addresses. In this section
you will see the common methods used to resolve IP names into addresses--in the next
section you will take a closer look at IP addresses.
Before you get into the details of IP names, be aware of a little secret--you
don't really need to use IP names at all in a TCP/IP network. If you know the IP
address for every system you want to contact, you're all set. IP host names are merely
tools that assist your personal analog-based memory. For example, IP names free you
from having to remember that your production system is "192.0.0.1" and
your test system is "192.0.0.2"; instead you can assign them descriptive
names like "prod" and "test" (or cute names like "kirk"
and "spock").
Informal and Formal Names
If you are operating in the confines of a self-contained network (termed a domain),
you can reference another system using just its system name. On the other hand, if
you function in a large network where multiple domains are interconnected, a system
name must be expanded into an fully qualified IP name that follows the format:
<host name>.<domain name>.<type>
In this format, <host name> refers to the name of a specific system (for
example, kirk or spock) and <domain name> identifies the name
of the organization, institution, or enterprise network that the system belongs to
(for example, ieee, ibm, or netcom). Domain names can contain
multiple components. For example, as400.ibm and java.sun are both legitimate
domain names.
The final component, <type> classifies the type of business or organization
serviced by the domain. Some of the more common <type> values include:
- .gov government body (for example, whitehouse.gov)
- .edu educational institution (for example, msu.edu)
- .com any commercial institution (for example, ibm.com)
- .org organizations/standards bodies (for example, ieee.org)
For international access, <type> can be further broken down into multiple
components. For example, co.uk and co.nz refer to institutions in the
United Kingdom and New Zealand respectively.
Again, you often need to use the full IP name when you leave your domain; otherwise,
you can just use the system name. For example, if you want to send something from
kirk.trek.com to spock.trek.com, you can simply use the address spock.
If, however, you want to send from kirk.trek.com to xena.warrior.com,
you typically have to use the fully qualified name (in other words, xena.warrior.com).
In a network environment where you frequently work with multiple local domains you
can, in fact, set up a domain search list to look for a host name in a series of
domains.
Making the Address Translation
You can invoke all TCP/IP services using either the IP address or IP name of the
target system. For example, you can initiate a File Transfer Protocol (FTP)
session using either of the following two commands:
Assuming that the system named spock has an IP address of 192.0.0.2,
both of these commands accomplish exactly the same thing, but the first variation
is certainly easier to remember.
Because the underlying TCP/IP protocols can't do much with the system name, TCP/IP
services such as Telnet, FTP, SMTP, and others invoke a translation process that
converts the host name into its corresponding IP address. This translation occurs
"under the covers," so you never see it happening--you only see the results.
The first step in the translation process is to look up the host name in a host
table file stored on the originating (local) system. This file--normally named
hosts--is manually maintained, and it contains a list of system names and
the corresponding IP addresses for those systems. If the specified host name is present
in the local host table, the process is complete, and the IP address is returned
to the requesting service. That service then initiates activity over the network
using the IP address. If, however, the specified host is not present in the local
host table, the translation process will turn to one or more systems in the network
that have been designated as a name server.
A name server is a system on the network that maintains a database of host names
and their corresponding IP addresses. In a nutshell, a name server provides a way
of centralizing the information contained in various systems' host tables--name servers
were developed to eliminate the need for each system to download a single master
hosts file whenever a network change was made. Any given host name can appear in
both a name server database and in a local host table. However, using both host tables
and name servers creates a reasonable balance between speed and manageability.
On one hand, it is difficult and often unreasonable to try to maintain a current
list of all host names and IP addresses on every system in the network. On the other
hand, retrieving an IP address from a name server takes more time than retrieving
it from a local host table file. By using both approaches, individual system administrators
or users can maintain a short list of frequently accessed host names in the local
host table file so access to those hosts can proceed at best possible speed. The
IP address for less frequently accessed hosts can be retrieved over the network from
a name server.
Finally, note that whenever a system resolves a name into an IP address, it stores
the results in a memory cache. The memory cache is always consulted first for name-to-address
resolution. If an entry isn't in the cache, then the system uses the hosts file and/or
the name server to resolve the name. Memory cache speeds up the process of accessing
the same host over and over again, but the cache is lost whenever a system reboots.
Name Servers
TCP/IP often provides several different ways of performing the same task. Names
servers are no different. In today's TCP/IP market, you will run into three common
name server implementations:
- Domain Name Server (DNS). DNS is the most wide-spread implementation of
a name server--for example, DNS is the preferred name server implementation on the
Internet. DNS is a sophisticated implementation that even allows name servers to
contact one another in the event they cannot resolve a name in their own databases.
When most people say name server, they are referring to the DNS implementation.
- Network Information Service (NIS) (formerly called yellow pages or yp).
NIS was developed by Sun Microsystems as part of its TCP/IP network architecture.
Although there are plenty of technical differences between DNS and NIS, they can
be viewed as functionally identical (but not interoperable) solutions for the purpose
of this discussion.
- Windows Internet Naming Service (WINS). This is a relatively new service
that, despite the name, is not really used for native TCP/IP traffic. WINS is a facility
that allows NetBIOS-based host names to be resolved over TCP/IP. It is an important
component in Microsoft's implementation of native Windows networking services over
TCP/IP.
Interestingly enough, these name server implementations are not exclusive of one
another--a system can engage them as needed. For example, if an HP system can't resolve
a name via NIS, it may invoke DNS. Similarly, a Windows 95 or Windows NT system can
use both WINS and DNS to resolve names.
As you can see, IP names play an important role in TCP/IP networking because they
add structure to the network and they allow users to reference systems by easy-to-remember
names. Just remember, all IP names eventually get translated into IP addresses before
action can be taken.
IP Address Construction
Under the TCP/IP architecture, each system in a network is assigned a four byte
(32 bit) address, termed the IP address. Instead of representing these bytes
as hexadecimal values, however, they are normally represented using the format w.x.y.z,
where w, x, y, and z are replaced with a decimal number between 0 (hex 00) and 255
(hex FF). For example, 192.0.0.12 is a valid IP address.
This four-byte address is then further broken down into a network address and
a system address. For example, the IP address 192.0.0.12 identifies system
"12" within network "192.0.0". Similarly, IP address 128.10.20.12
identifies system "20.12" within network "128.10". The breakdown
of how many bytes are used for the network portion of the address and how many bytes
apply to the system is predetermined based on the class of the IP address.
There are three real address classes, and they are as follows:
- Class A. This class follows the format "network.host.host.host,"
with the network byte falling in the range between 0 and 127 (exclusive of 0 and
127), and the host bytes being greater than 0. For example, in the address "64.0.1.12",
"64" identifies the network and "0.1.12" identifies the host
system. In case you're wondering, "0" is not a legal network address and
"127" is used to define a "loopback" address within an IP host
system.
- Class B. This class follows the format "network.network.host.host,"
with the first (left-most) network byte falling in the range from 128 to 191 (including
128 and 191), and the host bytes being greater than 0. For example, in the address
"130.101.0.68", "130.101" identifies the network, and "0.68"
identifies the host system.
- Class C. This class follows the format "network.network.network.host,"
with the first network byte falling in the range from 192 to 223 (including 192 and
223), and the host bytes being greater than 0. For example, in the address "200.1.1.37",
"200.1.1" identifies the network, and "37" identifies the host
system. Class C is the most common implementation because it provides the greatest
flexibility for creating multiple networks.
NOTE: There is a fourth type of address--Class D. This virtual
address class is used for multi-cast addresses, which are intended for multiple systems
that possibly reside in different networks. Class D addresses have no network or
host components and addresses begin with a byte that falls in the range of 224 to
239 (including 224 and 239). n
Note that in all classes, you cannot assign "0" or "255" as
host numbers. These numbers are reserved for TCP/IP broadcast messages. As a general
rule, you can select whatever address class makes sense for the composition of your
enterprise-wide network. If you're going to hook up into the Internet, however, you
need to obtain approval for your class assignment and address range through your
local Internet access provider.
Assigning IP Addresses
Once you've determined and possibly registered the class and range of addresses
you are going to use, you can go about the business of configuring your systems.
All systems can be manually configured to use a specific IP address. Alternatively,
some systems (for example, PCs, Macintoshes, and UNIX systems) can dynamically set
their IP addresses using the services of an address server.
NOTE: You must take Internet access into consideration when
you develop your IP address plan. If you are never going to connect your network
to the Internet or if you are only going to connect through a proxy server (which
hides your internal IP addresses), then you can use whatever addresses you desire.
If, however, you are going to connect to the Internet using a conventional gateway
or router, then you must only use the IP addresses you registered.
n
Before you set up an IP address server, you must decide on which dynamic address
protocol you can (and want to) use. The three popular choices are the Reverse Address
Resolution Protocol (RARP), the boot protocol (bootp), or the Dynamic Host Configuration
Protocol (DHCP).
- RARP and boot. These two protocols were developed to handle diskless UNIX
workstations. When a system boots up using RARP or bootp, the system broadcasts its
LAN adapter address, and the address server returns an assigned IP address. In order
to use RARP or bootp, a network administrator must manually create and maintain a
file on an address server that maps specific LAN adapter addresses to specific IP
addresses. Bootp has the added capability of downloading additional configuration
information, such as the addresses of the name servers and gateways.
- DHCP . This protocol was developed as an alternative to bootp. Unlike
RARP and bootp, a DHCP address server does not need to be configured with the hardware
address of each and every system it will service. Instead, the DHCP server assigns
IP address from a pool of addresses. Therefore, when a system makes a DHCP
request, it will receive an IP address from the pool that may or may not be the same
IP address it used the last time. Like bootp, DHCP can also download additional configuration
information to the requesting system.
Although DHCP was developed as a general purpose TCP/IP protocol, its popularity
and use have soared because Microsoft has adopted DHCP as its preferred methodology
for IP address assignment in Windows 95 and Windows NT TCP/IP networks. Microsoft's
decision has, in turn, convinced a number of PC and Mac network software vendors
to introduce support for DHCP in their client software packages. And with Service
Pack 2 of NT Server 4.0, Microsoft broadened the scope of DHCP by enabling an NT-based
DHCP server to handle address assignment requests from bootp clients.
You can mix and match your IP assignment methodologies. Some systems, such as
AS/400s and dedicated servers, can have manually configured IP address. Other systems
can use bootp, and still other systems can use DHCP. The flexibility (and related
administrative complexities) are yours to choose.
IP and MAC Addresses
As important as IP addresses are (and they are very important), they are not the
only requirement for delivering a message to a system in a TCP/IP LAN environment.
IP addresses are logical addresses that operate above the level of the physical LAN
adapter address (the MAC address). In order for a system to have the opportunity
to examine the IP address in a message, that message must get past the LAN adapter.
Specifically, when a LAN adapter card sees a message on the LAN, it will only
look at the contents of the message under two circumstances:
- The message is a broadcast message for all systems in the LAN.
- The message contains the LAN adapter's address.
In both of these cases, the LAN adapter passes the message on to the operating
system so the operating system can determine what protocol the message applies to
(for example, TCP/IP, APPC, IPX, and so on). In the case of a TCP/IP message, the
receiving system will then verify the IP address contained in the message. If the
IP address doesn't match, it will, in most cases, be ignored.
TCP/IP networks could function by broadcasting every single message and forcing
all the systems to look at each message. As you can probably imagine, this would
create extra overhead on the systems because they all must examine every single TCP/IP
message. Thankfully, however, TCP/IP provides a protocol to discover the LAN adapter
address that corresponds to an IP address. That protocol is the Address Resolution
Protocol (ARP).
Here's how ARP works. The first time System A wants to send a message to System
B, it sends out a broadcast message using ARP. Because it is a broadcast message,
each system in the local LAN sees it. When System B sees the message, it finds its
own IP address in it, recognizes that it is a ARP request, and returns a message
to System A containing its LAN adapter address. From that point on, System A can
directly address System B using both its LAN adapter address and IP address.
Combining Name and Address Resolution
The IP name, IP address, and LAN adapter address come into play whenever you begin
communicating with a TCP/IP system. For example, when you initiate a Telnet connection
to a host, the following steps occur:
- 1. The IP name is translated into an IP address using a hosts file or a DNS/NIS/WINS
lookup.
2. The IP address indicates if the target system in the same LAN (in other words,
it has the same network address as the source system) or if the message needs to
be forwarded through one or more gateways (as explained in the next section of this
chapter).
3. Once the message reaches the LAN where the target system resides, the target system's
LAN adapter address is discovered via ARP. This discovery will be performed by the
source system if it is on the same LAN as the target system, or by the gateway servicing
the target system.
The beauty of TCP/IP is that these steps happen behind the scene. You simply enter
telnet <host name> or ftp <host name> and all of the underlying
services and protocols kick in to take you to your destination, wherever it happens
to be.
IP Routing
The network portion of an IP address determines which computers a system can connect
to without requiring the services of a router or gateway (TCP/IP networks generally
use the term gateway even though a TCP/IP gateway is really a router). Under
the TCP/IP architecture, two systems with different network assignments can only
communicate with one another through a gateway--even if they are located immediately
next to each other and connected to the same physical network.
A TCP/IP gateway can be a dedicated router or it can be a computer system that
also acts as a router. For example, you can configure an NT Server system to be a
gateway by adding the Multi-Protocol Routing (MPR) network service. MPR can
run concurrently with other network services (for example, file sharing, printer
sharing, or Web serving). Most UNIX systems can also provide gateway service (either
routed or gated) in addition to their normal application loads.
Regardless of what type of device it is, a gateway system maintains a table
of network addresses and a record of the physical connections associated with those
addresses. Therefore, when a gateway receives a request to forward a message, it
simply looks at the network address of the target system, finds the physical interface
associated with that network address, and forwards the message over that interface.
How does a system know when it needs to forward a message to a gateway? Whenever
a system goes to send a message to another system, it compares the network address
of the target system with its own network address. If the two are different, the
originating system must forward the message to a gateway.
Needless to say, each system must know what gateways are available for use. In
the easiest scenario, each system is configured with the address of a single default
gateway, and all cross-network messages are delivered to that gateway. That gateway
can, in turn, forward the message on to other gateways, but this additional routing
is not visible to the original system.
In more complex networks, multiple gateways might be available to service different
networks. For example, one gateway might be available for traffic to and from a business
partner's private TCP/IP network, and a second gateway might service general Internet
traffic. Although, you can configure all of the traffic to go to the default gateway
and let the default gateway handle re-routing the messages through another gateway,
this approach creates additional overhead, and it introduces a single point of failure.
Alternatively, you can configure routing information in each system that tells
it which gateway to use to reach what network. In this example, you tell the systems
to use the first traffic for messages explicitly addressed to the partner's network
and use the second gateway for all other traffic (the second gateway is the default
gateway).
As discussed previously in the "IP Address Construction" section of
this chapter, IP addresses fall into different classes that determine which portion
of the address is used for network identification and which portion is used for system
identification. The way that these classes are interpreted on each system is actually
handled through something called a sub-net mask.
A sub-net mask is a series of 1 and 0 bits that are logically "ANDed"
to the IP address of the target system in order to determine which address bits are
used for network identification. For example, the three common IP classes use the
following default sub-net masks:
- Class A: network.host.host.host Mask: 255.0.0.0
- Class B: network.network.host.host Mask: 255.255.0.0
- Class C: network.network.network.host Mask: 255.255.255.0
You can, however, extend a subnet mask to create network divisions that deviate
from the standard class assignments. For example, you could break a Class C network
into two additional subnets by extending the mask one more bit. Addresses with a
1 in that bit location would belong to a different subnet than addresses with a 0
in that bit location. The mask in this case would be: 255.255.255.128 (128 decimal
= 10000000 binary).
Extending subnets is frequently done in private networks that have outgrown their
original IP address assignments. Some Internet access providers also use this technique
to assign IP address ranges to their local customers.
Once a system has determined the network address of the target system using a
subnet mask, it can make the decision if that message needs to be routed through
a gateway and, if so, what gateway needs to handle the message.
Additional TCP/IP Protocols and
Services
As discussed earlier in this chapter, there are hundreds of protocols and services
associated with TCP/IP. So far in this chapter you have explored many of the most
essential--and most common--of these protocols and services. Chances are better than
average that you will run into additional protocols and services in any reasonable
size TCP/IP network.
From a networking perspective, some of the additional TCP/IP and TCP/IP-related
protocols and services you might encounter include the following.
- AnyNet and Data Link Switching (DLSw). These are tunneling protocols
used to transport SNA traffic through a TCP/IP network. In effect, both protocols
establish end-to-end SNA connections through a TCP/IP network.
- The Internet Control Message Protocol (ICMP). ICMP is responsible for
reporting link-level errors and routing information to TCP/IP systems.
- NetBIOS over TCP/IP (NBT). This is a protocol used by Microsoft to enable
NetBIOS/SMB services (for example, NT-based file and print serving) to operate over
a TCP/IP network.
- Routing Information Protocol (RIP) and Open Shortest Path First (OSPF).
Both of these are protocols used by TCP/IP gateways and routers to share route information
with one another. This is how gateways inform other gateways of the routes they are
responsible for.
- Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP).
These two protocols enable full-function access to TCP/IP networks over leased line
or dial-up connections. PPP was developed as a replacement for SLIP and offers both
performance and security advantages.
- Point-to-Point Tunneling Protocol (PPTP). PPTP is the general tunneling
service for virtually any LAN-based protocol. Microsoft's NT Server and NT Workstation
use PPTP to transport IPX, NetBEUI, and NBT traffic over TCP/IP links, enabling you,
in effect, to tunnel your local LAN traffic through any TCP/IP network (including
the Internet).
In addition to the network-related services, you might also run into the following
application and service-oriented protocols.
- Gopher. This is a service that lets you list, search, and browse text
files stored on a server.
- HyperText Transfer Protocol (HTTP). HTTP is the underlying protocol used
by World Wide Web (WWW) servers. HTTP provides a means of transferring files and
HyperText Markup Language (HTML) documents from a Web server to a Web browser.
- Internet Message Access Protocol 4 (IMAP4). IMAP4 for is a client/server
protocol for mail retrieval and management. Using IMAP4, a client-side mail program
can view or retrieve mail stored on an SMTP server. IMAP4 is more sophisticated than
POP3, which is described later.
- Internet Relay Chat (IRC). This service enables multiple clients to establish
a common link on a server so they can "chat" with one another in real-time
by typing information and reading the responses.
- Line Print Daemon/Line Print Requestor (LPD/LPR). LPD/LPR provides a means
to print a file from one system on a printer attached to another system. LPR is the
client-side of this service, and LPD is the server-side.
- Network File System (NFS). The NFS service provides a means of sharing
directories and files in a TCP/IP network. Two NFS follow-up services are also used
for this same purpose: the Andrew File System (AFS) and the Distributed File System
(DFS).
- Post Office Protocol 3 (POP3). POP3 is a mail-retrieval protocol that
lets a client-side mail program retrieve mail messages from a mail server and store
them locally. POP3 is often used by PC/Mac-based mail programs (for example, Eudora)
to download mail from an SMTP server.
TCP/IP Drawbacks
Most TCP/IP serviceprotocols operate using English-like commands. HTTP employs
commands such as GET, SEARCH, and LINK. Similarly, FTP uses basic directives such
as DIR, GET, and PUT. Even those protocols that don't use English commands still
rely on simple, byte-oriented command sequences and responses (for example, under
the Telnet protocol, option negotiation begins with the 255 250 command
sequence and ends with the 255 240 sequence).
Consider the following Simple Mail Transfer Protocol (SMTP) conversation that
sends a message from [email protected] to [email protected] via
the mail gateway gateway2.heaven.com:
| Client |
Server |
|
220 gateway2.heaven.com Sendmail ready |
| HELO mail.enck.com |
|
|
250 gateway2.heaven.com Hello mail.enck.com |
| MAIL From:[email protected] |
|
|
250 [email protected].. Sender ok |
| RCPT To:[email protected] |
|
|
250 [email protected].. Recipient ok |
| DATA |
|
|
354 Enter mail, end with "." alone |
| Dear Jim: |
|
| How are things in lizard land? |
|
| -- John |
|
|
250 Mail accepted |
| QUIT |
|
|
221 gateway2.heaven.com delivering mail |
It's important to note that the preceding conversation is not pseudocode; this
is how the SMTP protocol really operates. The SMTP client transmits the keyword HELO,
and the server does, indeed, reply 250. In fact, the entire SMTP protocol
consists of English-like commands and numerical responses. (Note that the exact phrasing
that follows each keyword might vary slightly from one machine to the next, but they
all follow the same general format.)
Basing TCP/IP service protocols on high-level commands and responses makes them
extremely easy to learn, easy to program, and easy to debug. Unfortunately, while
this approach makes life easier for programmers and protocol developers, it presents
significant headaches for network managers. In particular, there are three major
drawbacks:
- TCP/IP is not kind to network bandwidth. Since its inception, TCP/IP has
assumed it will have sufficient bandwidth at its disposal. Other network protocols
(for example, IBM SNA, Digital DECnet, Novell IPX) are more sensitive to the fact
that bandwidth is a valuable commodity that is hard to come by. These other protocols
use bit-oriented flags for commands and responses instead of TCP/IP's multiple-character
sequences.
- TCP/IP is open to view. Anyone with a network monitor can see everyone's
dirty laundry (so to speak). You could certainly argue that anyone with a network
monitor can see everything in the network anyway. But, with TCP/IP, you don't have
to work very hard; all the information is laid out bare. You don't even have to decode
bit-level flags as you do with SNA, DECnet, or IPX.
- TCP/IP makes it easy for humans to masquerade as protocols. Most of its
application-level protocols use sockets as a means of communication. Using Telnet,
for instance, you can attach to a specific socket and start manually typing in the
protocol. So a hacker can Telnet into an SMTP socket and type HELO, and so on. You'd
be surprised (and horrified) to learn what you can accomplish when you disguise yourself
as a protocol.
None of these drawbacks have slowed down the growth and acceptance of TCP/IP.
Nonetheless, they all raise issues that you should address during the design and
operation of any TCP/IP network. You need to watch your available bandwidth, control
who has access to network monitor software, and most importantly, keep close tabs
on who is accessing your TCP/IP servers and why.
Telnet and IBM Systems
In most TCP/IP environments, Telnet functions as an interactive, character-level
service. That means that when you type a character on the keyboard, the Telnet client
sends that character over the network to the Telnet server, which then passes the
character on to the application. Furthermore, Telnet was designed with the ASCII
character code in mind--Telnet clients assume they will be communicating with the
Telnet server using ASCII encoding.
Unfortunately, character-level operation and the use of the ASCII character set
are contrary to the way that IBM terminals function in mainframe, System/3X, and
AS/400 environments. In particular, IBM 3270 (mainframe) and 5250 (System/3X and
AS/400) terminal types use these alternate approaches:
- IBM terminals are oriented toward block-mode operation instead of character-mode
operation. In the IBM environment, information typed on the keyboard is stored locally
until an Enter key or function key is pressed. At that point the input data is transmitted
as a block of information. As shown in Figure 10.3, this is a stark contrast to character-mode
operation, where each key is transmitted over the network as it is being pressed.
- IBM terminals use the EBCIDC character code instead of the ASCII character code.
These two differences affect how IBM devices operate in the Telnet environment
from both the client and server perspective. For example, if an IBM terminal initiates
a Telnet client connection using VT100 emulation, the Telnet client must provide
EBCDIC to ASCII translation and provide terminal emulation for the following reasons:
- To translate display highlights.
- To translate function key operations.
- To compensate for the difference between block-mode and character-mode operations.
From a purely technical perspective, the EBCDIC/ASCII translation is a minor issue
while the terminal emulation issue is significantly more difficult (but certainly
not impossible).
Using an IBM mainframe, System/3X, or AS/400 as a Telnet server for VT100-style
traffic causes similar difficulties. As in the case of the client, the IBM Telnet
server must provide EBCDIC/ASCII translation and terminal emulation, but for the
server, terminal emulation means:
- Translating display highlights sequences into IBM highlight attributes.
- Translating keystrokes into standard IBM function keys (for example, PF1-PF24).
- Translating character-mode operations into block-mode operations.
FIG. 10.3 Character-Mode and Block-Mode Operations
The server side of IBM Telnet also has one other interesting consideration. Because
the IBM terminal environment is block-oriented and Telnet is traditionally character-oriented,
a lot of unnecessary traffic is generated on the network. As noted, the Telnet client
typically sends out characters as they are being typed. If these characters are going
to an IBM Telnet server, the server simply collects them until it receives a termination
key (for example, the Enter key) at which point it sends the block to the application.
From a networking perspective, the overhead of sending characters out one at a time
is much higher than the overhead of sending them out as a block (which is the traditional
IBM approach).
TN3270
In order to alleviate many of these concerns, IBM developed an IBM 3270 terminal
type for the Telnet environment. Released in 1988, the Telnet IBM 3270 terminal type
is a negotiated option between the Telnet server and client that addresses many of
the difficulties associated with Telnet and the IBM environment. These difficulties
are addressed by instilling greater awareness for the IBM environment into the Telnet
3270 client program. Some of the benefits of the IBM Telnet 3270 solution include:
- Support for block-mode operations. The Telnet 3270 client collects keystrokes
and forwards them on to the Telnet server as a block when a trigger key (for example,
Enter or a function key) is pressed.
- Flexible mapping for IBM 3270 keys. Keyboard mapping files enable terminal
keys to be mapped into IBM 3270 keys (including function keys) as desired.
- Translation of display attributes. The Telnet 3270 client translates IBM
field attributes into the appropriate highlight sequences for the client terminal.
- EBCDIC/ASCII translation. The Telnet 3270 client can translate and switch
between EBCDIC and ASCII character codes as needed.
These features work together to create a Telnet client environment that has the
look and feel of an IBM 3270 terminal. Thus, information can be entered into structured
display forms; the Tab key can be used to move from field to field; and incorrect
information entered into fields can be changed prior to transmission.
The Telnet 3270 solution can be used by ASCII terminals accessing IBM systems,
by IBM terminals accessing a UNIX systems, and by IBM terminals accessing IBM systems
over a TCP/IP network. Use of Telnet 3270 to accommodate ASCII terminal access is
by far the most popular scenario.
IBM 3270 support is typically included in a separate Telnet program--usually called
TN3270. This means it is not uncommon to find Telnet client environments that
feature multiple Telnet programs. For example, the IBM RS/6000 includes both Telnet
and TN3270 programs. The Telnet program negotiates for the current terminal type
while the TN3270 negotiates for the IBM 3270 terminal type.
NOTE: An enhanced version of TN3270 is also available. This version--termed
TN3270E--enables some addition 3270 features in the Telnet environment, the most
important feature being printer support. n
TN5250
When TCP/IP connectivity was first introduced to the IBM AS/400 environment, the
AS/400 supported Digital VT100 and IBM 3270 Telnet terminal types. Telnet access
using the VT100 terminal type posed exactly the same difficulties found in the mainframe
environment (for example, ASCII instead of EBCDIC and character-mode instead of block-mode),
so Telnet 3270 access seemed a more logical choice. Unfortunately, 3270 access into
the AS/400 had its own set of problems.
Telnet 3270 traffic going into the AS/400 goes through the exact same handling
routines applied to "real" IBM 3270 terminals attached to the AS/400. These
routines translate the 3270 data streams and function keys into 5250 data streams
and function keys, so application programs only "see" 5250 terminals. Because
3270 and 5250 terminals are not functionally identical, the translation process introduces
new considerations regarding keyboard support, data entry field handling, and screen
display attributes.
To address these considerations, IBM developed a definition for a new Telnet terminal
type: the Telnet 5250 terminal. Introduced in 1991, Telnet 5250 operation
provides all of the benefits of Telnet 3270 operation (for example, block-mode support,
EBCDIC/ASCII translation, and so on), and also addresses the limitations of the 3270-to-5250
translation process by making the Telnet client program aware of the unique characteristics
of the 5250 terminal. Thus, a Telnet 5250 client provides the following features
not found in a Telnet 3270 client:
- Support for 5250-specific keys. The Telnet 5250 client permits flexible
keyboard mapping like Telnet 3270 and also provide client-based emulation of the
"Roll Up", "Roll Down", "Field Exit", "Field +",
and "Field -", and other unique 5250 keys.
- Enforcement of numeric-only fields. The Telnet 5250 client recognizes
numeric data entry fields and restricts data access on a local basis.
- Support for the full range of highlight attributes. The Telnet 5250 client
provides direct translation between 5250 highlight attributes and the actual terminal
running the Telnet client program.
The enhancements available in the Telnet 5250 solution make it superior to Telnet
3270 for accessing an AS/400 via Telnet. As in the case of Telnet 3270 clients, IBM
5250 support is normally available as a separate client program, often called TN5250.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
