CASE STUDY:
Installing Electronic Mail, Internet Access, and TCP/IP on a
Small LAN
Gary Kessler
and Carol Monaghan
September 1994
An edited version of this
paper appeared with the title
"Case Study: Bonding With the Internet" in LAN
Magazine, December 1994.
Many articles have appeared in
many journals about using electronic mail and joining the
Internet. Certainly the joys of the information superhighway are
many. But, while deciding to get on the Internet may be a
no-brainer, actually getting connected is not for the squeamish.
Few articles have discussed specific issues about finding the
right access provider, selecting software, and the details of an
installation. This article is a case-study of how our small
company weaved a path from obtaining e-mail software for our LAN
to selecting an Internet service provider to selecting TCP/IP
software. We learned some things that are not normally (or loudly)
documented that we want to share with others. We even welcome
others to learn from our mistakes; no one has the time to make
them all themselves!
In the comments below, the only
products and services that we specifically mention by name are
those that we use in our production environment. The intent of
this article is to tell others what we saw and our decision
process, and not to imply a negative review of products and
services that we did not use.
Network Scenario
Hill Associates, Inc. (HAI) is a
telecommunications training, education, and consulting company
currently employing 48 people. We have our main office in
Colchester, Vermont, with a staff of 35 technical, production, and
administrative personnel. Our network in this office is an IEEE
802.3 10BASE-T LAN running Novell NetWare 3.12, comprising 21 PCs;
another 5 PCs run NetWare over ARCnet. At the time of the events
discussed here, the PC's processors ranged from 286s to 486s, some
running DOS and some running Windows, RAM quantity ranging from 1
to 8 MB, and hard drives ranging from none to 250 MB. In addition,
the PC-based LAN is shared with 10 Macintosh systems running
AppleTalk. HAI also has an office in Denver with a staff of 7, and
maintains single-person offices in Atlanta, Hawaii, New Jersey,
and Texas.
HAI's main line of business is
telecommunications training and education. As such, most of the
technical staff members are on the road 25-50% of the time. Most
are equipped with laptop PC or Mac computers for use on the road.
Travelers and staff members in the remote offices access the
Vermont LAN via dial-up to a Norton pcANYWHERE asynchronous
communications server.
Electronic Mail
In the summer of 1993, HAI
started to investigate e-mail software for our LAN in a new
building that was approximately a year old. We wanted e-mail for
the classical reason: to improve intra-corporate communication.
After reviewing the literature and talking with users, we narrowed
our search down to two candidate packages: a popular
office/workgroup package that was compatible with our word
processing system, which we will call System X, and Lotus
cc:Mail.
An international accounting firm
that is a large cc:Mail user has an office near our Colchester
location. At our request, they invited us to see the mail package
in a real setting. We were able to play with it and get some real
users' comments and feedback, all of which was good.
We paid serious attention to System
X because of the tremendous accolades that it had been
receiving in the trade press, and its compatibility and interface
similarity with our word processing software. Unfortunately, we
were unable to locate any users in our area that we could visit. A
local software dealer agreed to set up a small demonstration for
us with a 4-node LAN. We found that the System X package
worked well and we were impressed with the suite of applications
that were bundled with the software (calendar, memoing, project
management, "while you were out" messages, etc.). We
were so impressed that we bought this package.
In retrospect, being swayed by
the demo was an error. All of the nodes on the demonstration LAN
were 33-MHz 486DX-based PCs with at least 4MB RAM; industry trade
press articles used similar systems. Once System X was
installed on our equipment, we found uniformly poor performance of
the product. The user interface was great and its similarity to
the word processing package made use simple. However, it regularly
took 30 to 40 seconds on 286 and 386 systems for control to return
to the user after launching a message; this delay discouraged all
but the most hearty users. Furthermore, there was no way to
streamline the application to optimally use the small memory space
on some of our systems; those users that wanted nothing but e-mail
still had to load the entire software package and the program did
not seem to have an efficient overlay scheme even if using only a
single application.
The value of good and accessible
technical support also became apparent. The technical support from
System X's vendor, as with most companies, has a range of
technically knowledgeable people answering their telephone lines.
All were helpful and supportive, but suggestions ranged from
upgrading all of our computers so their software would work better
to obtaining a stand-alone mail server (which was supposedly not
necessary); advice from one person often contradicted advice from
someone else and/or the documentation. We learned very quickly
that if the technical support agent said "I think this will
work", we had to escalate the call to someone else.
A second important lesson for us
was that not all of our users wanted all of the features of the
package. Indeed, all wanted e-mail, but only a few wanted the
calendar option and none wanted anything else. Our error here,
then, was buying more than we needed.
We finally decided, with the help
of the software's manufacturer, that System X wasn't
suiting our needs nor satisfying our users. We returned the
product one week before the return deadline set by the
manufacturer; our dealer had already told us that the deadline had
passed. The lesson here: evaluate the software as quickly as
possible and don't be shy about complaining to the manufacturer if
necessary.
At this point, we re-examined
cc:Mail at the local accounting firm, going so far as taking one
of our 286 machines and running the cc:Mail software over their
LAN to ensure that it would work ok with our hardware platforms.
It did and we purchased it.
We experienced no major problems
installing the DOS, Windows, or Macintosh cc:Mail platform packs
or any of the user packs. All of the installs were
straight-forward and well documented. After setting up the basic
post office, creating the users for that post office was quite
simple. Cc:Mail provides a utility called directory services
(for use with either NetWare or Vines) which allows you to import
the user names. To use the directory services, you set up a
configuration file that provides the mapping between (in our case)
the NetWare bindery and the cc:Mail directory. For example, we set
up our configuration file so that our cc:Mail usernames were the
same as our NetWare login names. After creating our configuration
file, we simply ran NDS (NetWare Directory Service) and all of the
users were set up as cc:Mail users. Once the post office was fully
configured, the next step was to simply map our users to the
appropriate locations depending on their platforms. Once up and
running, all of our users were able to pick up the basics of the
package quickly and there were no complaints about performance.
Since we have a large population
of travelers, we found it necessary to setup the Remote portion of
cc:Mail. The DOS and Windows platform packs came with a program
called Dialin, which is also available for free from Lotus. Dialin
gives users the ability to dial in from the road and exchange mail
with the home post office. The users upload to the home post
office messages that they have created off-line and messages
waiting for them on the home post office are then downloaded to
their machine. Dialin requires a dedicated server on the LAN; we
are using a 286 with 1 MB of RAM and no hard drive, and we are
satisfied with its performance. Before setting up the dialin
server, and even before you purchase the modem that you will use,
you should download a file provided by Lotus called MODEMS.ZIP,
which lists most of the popular modems on the market and tells you
which will work with Dialin. It also gives you the command line
syntax for setting up Dialin and any needed modem initialization
strings. Initially, one drawback to Dialin was that it only
supported seeds up to 9600 bps; Version 5.1 of Dialin now supports
even higher speeds.
For the most part, our users are
impressed with the speed and efficiency of remote access although
cc:Mail Remote was not a very mature product when we first
purchased it. Initially, the only options for remote access were
for DOS or Macintosh platforms; running the DOS Remote software
from Windows sometimes resulted in system conflicts. When Lotus
introduced cc:Mail Mobile for Windows, we were quick to upgrade
from our DOS versions of remote access, and we have been quite
happy with the Windows mobile product. We also experienced some
problems with the early Macintosh remote product, most of which
were solved with the upgrade to cc:Mail Mobile for Macintosh.
The ongoing maintenance within
cc:Mail is also quite easy. Adding and deleting users, creating
mailing lists, setting up bulletin boards, and other housekeeping
functions are all accomplished using the Admin program, which is
clearly explained and documented in the manuals. Lotus recommends
that you run some utilities (Chkstat and Reclaim) on your post
office to reorganize the main database and user files, we have
found that running these utilities about once a month is adequate.
If the post office is in need of optimization and reorganization,
you will be informed of this when you run the Admin program. When
optimizing the post office, all users must be out of cc:Mail. The
length of time for this function depends upon the size of your
database and how much reorganization is required; on average, our
reorganization takes about 30 minutes.
Internet Access
Internet access is becoming such
a fact-of-life that many organizations don't even need a business
case for justifying the connection. HAI wanted access to the
Internet for several reasons. First, it would help enhance
communications with our customers. Second, it gives us access to
all of the network's information resources, allowing our
instructors, course developers, and account managers to keep
current on many topics of importance. Finally, we felt that being
a part of the Internet community was an important professional
responsibility for our company. Given all of this, how does a
company or an individual gain access to the network?
First, while access to the
Internet is noble, you need to examine the reasons for which you
are getting on the network. Is it just for electronic mail or do
you need access to Internet tools and utilities? Is the use for an
individual, a small group of users, or for a large organization?
Is the expected traffic volume sporadic or constant?
One piece of advice that we can
give is to examine all provider alternatives. Users typically do
not connect directly to the Internet, per se, but to a regional
(or national) Internet service provider. Traditionally, the only
economical way to gain access to the Internet was via the regional
provider in your area, of which there was usually one. But
800-number dial-up services and distance-insensitive wide area
network (WAN) technologies are providing users with new access
options through a larger number of providers than have been
available and/or affordable in the past.
Many of the introductory books
about the Internet list the service providers by regional
coverage. Be imaginative, however; some of the smaller access
providers offer comparable services as the larger providers at
much better prices, and may use a variety of WAN technologies to
provide access to users outside of their principle locality. In
some ways, the Internet access provider environment is much like
the long distance telephone carrier market ten years ago; there
were a few large long distance telephone companies and a lot of
small, aggressive start-ups.
There are a number of cost
elements to consider when making a connection to the Internet.
First, there is the cost of the service itself. Second, there is
the cost of the communications line to the service provider, which
may include a local loop charge from your local telephone company
and/or a charge from a long-distance carrier. Third, there is the
cost of the hardware on your site, which might range from a modem
for dial-up access to a router and data service unit (DSU) for
dedicated access. Finally, there is the cost of communications
software.
TABLE 1. Price
quotes made to Hill Associates for Internet access (dedicated
line).
PROVIDER SPEED MONTHLY INSTALLATION (CPE charges)
Netcom 56 kbps 868 $2,170 (Includes CPE)
Service W 19.2 kbps $ 943 $4,950 (Leased CPE)
56 kbps 1,364 $4,950 (Leased CPE)
Service X 56 kbps 1,390 $2,520 (CPE not included)
Service Y 19.2 kbps 760 $ 660 (CPE not included)
56 kbps 1,210 $ 750 (CPE not included)
Service Z 56 kbps 1,160 $1,065 (Includes CPE)
It is sometimes difficult to
compare the price of the services on an apples-to-apples basis
because the price elements that comprise service quotes vary so
much from provider to provider. In the quotations that we saw, one
service provider included the cost of the router and DSU into the
first six months of service; another provider required that we
lease the router and DSU from them for the length of the service
contract; a third assumed that we owned this equipment already.
Table 1 shows the wide range of price quotes that we received for
dedicated access, only to demonstrate the variability in pricing.
There are a couple of things to
think about if considering access to the Internet for e-mail.
First, be sure that your access provider offers a mail relay
service. Second, be sure that your local e-mail software supports
the Simple Mail Transfer Protocol (SMTP), the standard mail
protocol for the Internet and TCP/IP-based networks. Third, be
sure that your e-mail software supports something like the Post
Office Protocol (POP), or another similar protocol if your
provider requires it, if purchasing a dial-up service. POP or its
functional equivalent is necessary to store your outgoing e-mail
until you make the dial-up connection to your service provider's
mail relay host. POP will usually be available if you are using
SMTP-based e-mail (which cc:Mail, as an aside, is not).
There are a number of other
caveats if considering a dial-up service. First, be sure that the
provider has a local access telephone number. One of our
local service providers quoted us a very attractive price for
their 14.4-kbps dial-up service and later mentioned that
they had no dial-up ports in Vermont; all of our access would have
to be via a site in New Hampshire. Second, look carefully at the
schedule that describes the time-of-day that you are allowed to
use the service and the number of hours per month that are
included in the service fee. Most rate schedules encourage
non-peak use. This might be ok for e-mail applications,
which batch a number of messages together to exchange with the
mail relay host, but may not encourage your users to use the
Internet for real-time information gathering purposes. Know what
it is that you want to use the Internet for.
There are several criteria that
you can use to compare providers. We found that price,
interestingly enough, was one of the significant differentiators
(although we ranked it relatively low in importance) because most
Internet access service providers offer a similar set of services.
Check with as many other users as you can, particularly those that
access the provider you are evaluating in a similar fashion as
you, for similar applications. Some of the criteria are:
- What services are offered? Is
it just e-mail or is complete access to all Internet services
available? Is a mail relay service available? Is a NETNEWS
feed (aka Usenet or NNTP) available? Do they provide software?
- What kind of access is
provided: asynchronous dial-up, synchronous dial-up using
Serial Line Internet Protocol (SLIP) or Point-to-Point
Protocol (PPP), leased-line, frame relay, Switched
Multimegabit Data Service (SMDS), or other access? What speeds
are supported?
- Does the provider offer
complete 24-hour/7-day management, operations, monitoring, and
maintenance on the network and user access lines?
- Does the provider assist you
with, or perform, IP address and domain name registration? Do
they manage their own name servers and are they flexible?
- Does the provider help, or
perform, equipment setup? Who is responsible for detecting,
diagnosing, and correcting equipment problems?
- What kind of technical
support, hand-holding, and training is available? How much do
you need?
- What does the service cost?
Are there restrictions in use?
- What kind of security do I
need? What is available?
After evaluating the above
criteria, we selected Netcom as our Internet service provider.
Although cost was not our number one criteria, it became the
deciding factor since all six providers we investigated offered
roughly the same level of services. Through Netcom's arrangement
with WilTel, we access their node in San Jose, CA via a 56-kbps
frame relay permanent virtual circuit (PVC) service. Our monthly
costs include the price of the DS0 (56 kbps) local loop from NYNEX
(our local telephone company), the Netcom Internet access service,
and the WilTel frame relay PVC. In addition, Netcom's setup cost
included the router and DSU, as well as IP address/name
registration, router setup, and a couple of hours of telephone
technical support during installation (which actually only took
about 30 minutes of work on our part).
As an aside, we found it
interesting that our most cost-effective Internet access solution
had us connect to a network 3,000 miles away. It demonstrates
quite forcefully, however, how emerging wide-area network
services, such as frame relay, are indeed "shrinking"
the size of the network and enabling access to new alternatives.
Internet Mail Software
About a dozen people in our
company had different ways to access the Internet, none of which
were coordinated with our corporate e-mail. One anticipated
benefit of the Internet, then, was for us to have a single e-mail
system with which to send and receive internal and external
e-mail.
Internet e-mail requires use of
SMTP. We chose Lotus' cc:Mail-SMTP Gateway primarily because it
was the most cost-effective solution that we could locate. The
mail gateway works as follows. cc:Mail defines post offices
to store mail messages; the post office on our LAN is called
HILLBTV. When a user starts the cc:Mail application, their mail
box in the post office is examined and they are notified about any
waiting mail. When setting up the mail gateway, we defined a post
office called INTERNET for the storage of Internet mail. Mail
addressed to the INTERNET post office is stored in an outbox
on our LAN. The mail gateway periodically establishes an SMTP
connection with Netcom's mail relay host, uploads the mail from
the outbox, and downloads any waiting mail into an inbox on
our LAN. Messages in the inbox are then forwarded to the HILLBTV
post office for delivery to the end users on the LAN. This product
requires a dedicated PC to act as the SMTP Gateway server; we use
a 386SX-16 with a 20 MB hard drive for this purpose.
To set up the SMTP Gateway, the
documentation specifies that you have some information at hand,
such as the IP addresses of the local router, PC acting as the
SMTP gateway, and network's mail relay host. But we found a few
undocumented features.
First, Lotus' SMTP Gateway
installation can be very unforgiving. The inbox and outbox
directories must be specified for the program and the program will
not work unless those directories already exist; the program won't
create them automatically nor tell you they are missing, it just
won't work. Also, a file named HOSTS must be created, which
contains the systems' name, IP address, and alias; the program
failed when a host's alias name was missing, although this is an
optional parameter. Again, the program wouldn't accommodate
missing information nor tell us what or where the problem was, it
just didn't work.
Second, the network's mail relay
host name and IP address must be supplied to the SMTP gateway
software. We found this to be very inconvenient, largely because
Netcom preferred to tell us only the mail relay host name, but not
the address, so that they could move the mail relay function to a
different machine without having to notify us. If the SMTP gateway
software used the name resolution capabilities of the network
service, however, we would only have to supply the mail relay host
name; if the service provider later moves the mail relay server to
another host (which is likely), this change would occur
transparently to our software as long as the host name does not
change.
Third, the SMTPLINK address
translation capabilities helped resolve a number of user and host
naming issues. Our domain name is hill.com. During
installation, we were required to assign the SMTP Gateway a host
name; we chose mail. The SMTP gateway software
automatically adds the mail server's host name to the domain name
in outgoing mail, so that all mail comes from the host mail.hill.com.
The software also appends the originating post office name to the
username when a message is transferred from one post office to
another. Since user mail originates on the HILLBTV post office
before being transferred to the INTERNET post office, all of our
outgoing mail has the hillbtv post office name as part of
the username. Gary's Internet mail address, for example, is kumquat@hill.com;
outgoing mail would arrive to recipients, however, with a return
address of kumquat_at_hillbtv@mail.hill.com. This was a
major problem because it caused confusion as to how to reply to
messages.
The solution to this problem is
simple and documented, but not necessarily easy to find; in fact,
one person at Lotus' technical support told us that this
addressing pattern "just has to work that way." The SMTP
gateway uses a file called SMTP.ADR as an address translation
table if the file is present. Entries in this file map a
user's cc:Mail user name to an SMTP/Internet address. By mapping kumquat
(Gary's username on the LAN) to kumquat@hill.com, for
example, we were able to solve both of the problems listed above.
The network administrator must be sure that this file remains
up-to-date, but this information is relatively non-volatile once
it is entered.
Use of the SMTP.ADR file also
allowed some of our users to have an Internet address that is
different than their cc:Mail user name. Mark Fei, a member of our
technical staff in Denver, for example, has been using MarkFei
as his Internet name for a couple of years, while MAF is
his cc:Mail name. In the SMTP.ADR file, maf is mapped to markfei@hill.com
and no one has to learn any new addresses.
The address mapping capability
also allowed us to define some virtual users without having
to define new cc:Mail users. In particular, we defined a virtual
user named postmaster, a common name on the Internet, so
that any mail addressed to postmaster@hill.com will be
correctly directed to our network administrator (Carol). We also
defined a virtual user info so that general queries to info@hill.com
get forwarded to our company's special projects coordinator.
Choosing a logical user naming
structure is frequently an afterthought for organizations
attaching to the Internet, particularly for large organizations
that are combining several LANs with separate network
administrations. Many sites never had a logical naming structure
because of the way most naming schemes evolved. When a site first
puts in a LAN, the network manager will often let users choose any
login i.d. they want because they are the only one to see the
name. When e-mail is installed, most sites merely use the LAN
username as the e-mail address because that is simple, again
without much thought to a logical naming pattern since usernames
aren't seen outside of the network. By the time some sites attach
to the Internet, they may wish that they had a more clever name
structure for that people outside of the organization can easily
find users. The address mapping capabilities of the mail gateway,
then, offers a powerful tool so that a network administrator can
employ a logical naming scheme for external use and map it to the
possibly less logical scheme that is used internally. That is also
one of the reasons that we defined a postmaster virtual
user; it provides a relatively common address where outside users
can query us for internal addresses. (OF course, a finger daemon
that responds with a list of usernames would also be useful.)
There are other things to look
for in mail translation software. Among the most important is
support for standards. Obviously, all must support SMTP for use
with the Internet or any other TCP/IP-based network. In addition,
support for the Multipurpose Internet Mail Extensions (MIME) may
be important to your organization. Lotus' SMTP Gateway, for
example, does not support MIME and, although we would like that
feature, it has not yet been worth spending the extra money (in
our case, almost $1,000).
In fairness, it should be noted
that most of the "deficiencies" that we describe above
have been forwarded to Lotus and we have received positive
responses. The installation process is reportedly now much simpler
than before, MIME should be available soon, and we have been told
that name server support is under consideration.
However, we continue to
experience the ongoing problem of the SMTP Gateway server
periodically hanging. Interim releases of the software have helped
somewhat, but the problem is still not completely eliminated.
Lotus is aware of this problem, however, and they are working
towards a solution. Their latest version of the Gateway software
(version 2.03) is definitely better than the previous releases but
we still occasionally experience the problem.
TCP/IP Software
If you access the Internet for
more than just e-mail applications, your hosts will have to use
TCP/IP. We chose to install TCP/IP software on each LAN host
individually so that we retained flexibility for the traveler's
systems. We tested a number of different commercial TCP/IP
software packages on our LAN weeks before having the Internet
access in place, just to see which ones installed easily on our
PCs, provided the variety of utilities that we wanted, and worked
with the various hardware and software platforms that we had.
-------------- --------------
|Applications| |Applications|
-------------- --------------
| SPX | | TCP |
-------------- --------------
| IPX | | IP |
-------------- --------------
? ?
? ?
? ?
? ?
? ?
--------------
| MAC |
--------------
| PHY |
--------------
FIGURE 1. Simplified
Novell NetWare and TCP/IP protocol stacks over a LAN MAC/PHY.
Since the MAC will only see a single Network Layer protocol at a
time, one of the protocol stacks will be recognized while the
other stack is loaded.
There are a number of issues to
keep track of when obtaining communications software for hosts
already attached to a LAN, most of which are documented but
usually without any reason, motivation, or emphasis. First is the
matter of the common data link layer protocol interface that must
reside between the higher layer communications protocols and the
underlying LAN media access control (MAC) protocol. Consider a
Novell NetWare protocol stack, as shown in Figure 1, which
comprises the LAN MAC and Physical Layer (PHY) protocols, the
Internet Packet Exchange (IPX) protocol, the Sequenced Packet
Exchange (SPX) protocol, and higher layer applications. We need to
add TCP/IP functionality to this system so that it can access the
Internet, which means adding a parallel set of protocols. The
problem is that the LAN MAC is expecting to see only one Network
Layer protocol above it; namely, either IPX or IP. The potential
inconvenience is obvious; when you boot the system, you have to
choose which communications protocols you want loaded and you have
to re-boot to change communications stacks.
---------------------------
|Applications|Applications|
-------------+-------------
| SPX | TCP |
-------------+-------------
| IPX | IP |
---------------------------
| ODI/NDIS |
---------------------------
| MAC |
---------------------------
| PHY |
---------------------------
FIGURE 2. Simplified Novell
NetWare and TCP/IP protocol stacks co-existing over a LAN MAC/PHY
using a common data link protocol (ODI or NDIS).
There are a number of common
work-arounds to this problem. The most widely used is to implement
a "multi-protocol" data link protocol specification such
as Microsoft/3Com's Network Driver Interface Specification (NDIS)
or Novell's Open Data Link Interface (ODI), as shown in Figure 2.
The use of NDIS or ODI will allow multiple protocol stacks to
reside simultaneously in a single system. The caveat is to be sure
that your network operating system and TCP/IP software
product support the same data link specification.
A second related issue is to
properly configure the frame format used on your LAN, a
potentially thorny issue in IEEE 802.3/Ethernet environments. This
is necessary when TCP/IP has to co-exist with a native LAN
operating system because there must be some mechanism so that
destination stations can differentiate one protocol from another.
In our case, we are running
Novell NetWare over an IEEE 802.3 10BASE-T network. When reading
the documentation for all of the packages we examined, much
attention is paid to the LAN configuration file since that is
where frame types are specified. Common options include
ETHERNET_II, ETHERNET_802.3, and ETHERNET_SNAP. What do these
specifications mean?
Ethernet was the original
carrier sense multiple access with collision detection (CSMA/CD)
MAC scheme developed by Xerox in the 1970s and marketed in the
early 1980s by Digital, Intel, and Xerox (DIX). The latest version
of this standard is Ethernet II, so the frame type is designated
ETHERNET_II.
-------------------------------------------
Ethernet: |Preamble|DA|SA| Type | Information |FCS|
-------------------------------------------
-------------------------------------------
IEEE 802.3: |Preamble|DA|SA|Length|Information|PAD|FCS|
-------------------------------------------
DA: Destination Address FCS: Frame Check Sequence
SA: Source Address
FIGURE 3. Ethernet
and IEEE 802.3 frame formats.
The DIX Ethernet specification
was forwarded to the Institute for Electrical and Electronics
Engineers (IEEE) for standardization and was used as the basis for
the IEEE 802.3 CSMA/CD LAN standard. IEEE 802.3 frames are
indicated with an ETHERNET_802.3 type. The Ethernet and 802.3
frame formats differ, however (Figure 3); an Ethernet frame
carries a higher layer protocol Type indicator in the 2-octet
field preceding the Information field, while an IEEE 802.3 frame
carries a Length value in the same location.
These two protocols can co-exist
on the same LAN, although a station expecting an Ethernet frame
will not be able to properly interpret an IEEE 802.3 frame and
vice versa. But, how does a station know the difference,
particularly if it has to be able to accept both? The answer is
actually quite simple. In IEEE 802.3, the Length field indicates
how many octets of user data are in the Information field and will
contain a number between 0 and 1508. In Ethernet, this field
contains a protocol identifier; the values 2048 and 2054, for
example, refer to IP and the Address Resolution Protocol (ARP),
respectively. All possible protocol identifiers, in fact, have a
value above 1508 so that there is never any ambiguity.
Finally, the IEEE 802 and 802.2
standards define the Subnetwork Access Protocol (SNAP). SNAP is
another protocol layer that contains an explicit protocol
identifier field, allowing the use of multiple higher layer
protocols with a single LAN frame type. This protocol is with the
ETHERNET_SNAP type.
All of the TCP/IP software
packages that we investigated installed easily, with just a few
hangups. One package that we examined, for example, would not load
while Norton Desktop was installed (an undocumented feature).
Another package did not document that it automatically loaded with
ODI, if available, and was correctly installed even though it kept
asking for the location of the NDIS driver; although all we had to
do was provide any answer and it would boot correctly, we lost
several hours because of this.
Having the opportunity to play
with the software even in the absence of a live Internet link was
very valuable. In one case, we found a package that had to be
pre-configured with the destination host's directory format so
that the File Transfer Protocol (FTP) would work; we eliminated
this package from consideration because we found this requirement
to be rather onerous. Another had too few utilities and no true
Windows interface, so we eliminated that as well.
Once we got our Internet link, we
were left with two packages to examine and we eventually choose
FTP Software's PC/TCP. First, it supported all of the TCP/IP-based
utilities that we wanted, including FTP, Telnet, NSLOOKUP, NICNAME,
Ping, Finger, and Traceroute. Second, it supports both DOS and
Windows, a mandatory requirement since we had PCs running both.
Furthermore, the Windows graphical user interface is great but, in
our teaching environment, it is occasionally useful to show people
the detail of what is going on; the DOS applications allow us to
show the complexity that Windows hides. Finally, FTP Software has
a stated intent to support Windows 95.
One of the other differentiators
for PC-based TCP/IP packages is memory usage. The DOS-based
packages that we saw used Terminate-and-Stay Resident (TSR)
routines, which chew up base memory. The Windows applications
conserved memory by employing dynamic linked library (DLL)
implementations, but even there we saw big differences in the use
of memory. FTP's package is using a Virtual Device Driver (VxD)
implementation, which takes advantage of the 32-bit architecture
of later Intel processors and is in line for the true
multi-tasking that Windows 95 promises.
The discussion above focuses
primarily on software for the PCs. Finding TCP/IP software for the
Mac systems was actually easier; one of our staff members already
used Versatilities and was very pleased with it. It is inexpensive
(less than half a comparable PC-based package) and easy to
install.
We found that PC/TCP was among
the easiest and fastest software to install, despite what some
reviews have stated. The secret to installing any TCP/IP package
is to gather all of the necessary information before ever picking
up a disk. One critical item of information is the IP address
(and, possibly, host name) for the system on which TCP/IP is being
installed. IP addresses and host names must be administered
centrally within your organization. IP addresses comprise two
parts; a network number and a host number. A domain name and IP
network number will probably be obtained for you by your Internet
access provider (if you don't already have one), but you are
responsible for assigning IP host numbers and host names within
your domain. It is critical that host addresses and host names not
be duplicated within your network; furthermore, you don't want to
assign the host number 0 ("this network" address) or 255
(broadcast address) to any station on your network.
Other information must also be
supplied when the TCP/IP software is installed; exactly what will
depend upon those services that are available and the utilities
that are being implemented. Information to be supplied may include
the name and/or address of the network's domain name server(s),
your LAN's router, the network's mail server, the cookie
(quote-of-the-day) server, the time server, and the news server,
as well as the location of the finger server (daemon) and finger
information files. Many commercial TCP/IP packages allow users to
configure their own PC as an FTP or Telnet server; this opens a
potential security hole that network administrators must be aware
of. Password files must be very carefully created if you are
setting up any system as a server to the outside and firewall
protection may need to be configured into your router. Once you
have all of this information written down, installations are
usually pretty fast. We suggest that you keep a written record of
all parameters supplied for each system's software installation.
It is important to point out that
alternatives to commercial TCP/IP software packages are readily
available. A number of shareware TCP/IP protocol stacks are
available for PC, Mac, OS/2, and UNIX platforms. These stacks are
often just the TCP/IP protocols themselves, without a broad range
of utilities, simple user interface, or technical support, but
they may provide a viable, inexpensive alternative if you have
staff to install and support the software. Some of the newly
available Internet software packages provide only utilities
and an interface, assuming that you have an underlying TCP/IP
implementation. Using these packages with public domain TCP/IP
software may be another alternative.
One other comment is necessary
about TCP/IP software. It is possible to achieve better
performance if you tune the software. Tuning is accomplished by
adjusting a number of protocol parameters, notably the TCP
window size and the number of large buffers. It may at
first appear nerve-wracking to go through this process, but the
rewards are increased throughput and decreased frustration. Some
TCP/IP packages provide the tools for examining performance and
utilities to improve it.
The TCP window size is the
maximum number of octets that a TCP connection may transmit
without having to stop to wait for an acknowledgement. Ideally,
the TCP window size will be set as a multiple of the maximum
segment size (MSS), or the data portion of a LAN MAC frame. As an
example, an Ethernet, StarLAN, or IEEE 802.3 frame used with IP
will contain no more than 1,460 bytes of user data. We found that
the default window size was set to 2,048; with this setting we
were able to achieve a 26-kbps throughput when transferring a
sample 88 kilobyte (KB) file. By setting the window size to
various increments of the MSS, we found that a window equal to
three times the MSS (4,380 bytes) provided a throughput of 37 kbps
when transferring the same file, a 50% improvement.
The number of large buffers
parameter indicates how much buffer space is made available to
TCP/IP applications. The default setting was 5; we found that
increasing this to 6 allowed us to consistently achieve higher
throughput rates.
Finally, there is an emerging set
of TCP/IP-based utilities for searching the Internet for
information which are not available on most commercial TCP/IP
software packages. All of these tools are available, however, for
free on the Internet for a variety of hardware and software
platforms, including DOS, Windows, UNIX, OS/2, and the Macintosh.
Among the utilities to consider are:
- Archie:
Searches FTP
sites for files on a specified topic. More information about
Archie, including some client software, can be downloaded
using anonymous FTP from the "/pub/archie/"
directory at host "ftp.cs.widener.edu".
- Gopher:
Offers a
structured approach to searching and downloading data from
another site that provides a Gopher server. More information
about Gopher, including sources for client software, can be
found by downloading the file "/pub/usenet/news.answers/gopher-faq"
at the host "rtfm.mit.edu" using anonymous FTP.
- Mosaic: One of the most
popular World Wide Web (WWW) hypertext browsers. WWW sources
and additional information may be accessed via anonymous FTP
from the "/pub/WWW" directory at "info.cern.ch"
or the "/Web" directory at "ftp.ncsa.uiuc.edu".
Once you download any of these
utilities, be prepared to spend a little time learning how to use
them and a lot of time surfing the network.
Today's Status And Future Directions
This article is being written at
the end of the summer of 1994. Our network status at this time is:
- All of our PC systems have
been upgraded to 486 processors running Windows. Most of the
Macs are either Quadras or Powerbooks.
- After a year, cc:Mail remains
very popular and the remote access software has proven to be
quite stable. Once generally available, the staff started to
use e-mail voraciously and even the most reticent users
quickly got on board. The use of the package has done all of
the things that e-mail is supposed to do -- enhance
communication and decrease the amount of paper. Within a few
months, it became such a part of our communications that it
would be unthinkable to not have it available. In addition,
use of our voice-mail system dropped considerably.
- We got our connection to
Netcom in May of this year. The service has been excellent to
date. On those occasions when we have needed to communicate
with their network operations center, we usually use e-mail
and have a response within hours; one emergency necessitated
an early morning telephone call and the problem was resolved
within minutes.
- While we are generally pleased
with the cc:Mail-SMTP Gateway, we have found its performance
to be very uneven. It occasionally crashes for no apparent
reason or has difficultly connecting to the Netcom mail relay
and requires re-booting. We have received several patches to
the program from Lotus but are still awaiting a completely
stable version of the software, as well as MIME.
- We have been very happy with
the PC/TCP package which we have also been using May. FTP
Software has released several upgrades of their PC-based
package and all upgrades have installed smoothly. The Mac
users have been quite happy with the Versatilities package.
------- -------
|Modem| |Modem|
---+--- ---+---
| |
---+---- ----+---- ----------
-------- |Remote| |Asynch.| |cc:Mail-|
| File | | Mail | | Comm. | | SMTP |
|Server| |Server| |Server | |Gateway |
----+--- ----+--- ----+---- ----+-----
| | | |
=====================================
| | |
---+--- ---+--- ---+----
| PC | | MAC | |Router|
|Users| |Users| ---+----
------- ------- | ( )
--+-- WilTel ( )
|DSU|::::::::::::::::::::::::( NETCOM )
----- Frame ( )
Relay ( )
FIGURE 4. Current
Hill Associates LAN/Internet configuration (9/94).
The configuration of the HAI LAN
in Vermont is shown in Figure 4. We are probably not finished with
integrating TCP/IP and the Internet into our internal and external
communications strategy. In particular, there are two directions
in which we hope to proceed within the next year.
The first is to eliminate
asynchronous dial-up access to the LAN by replacing the pcANYWHERE
asynchronous communications server with a remote node LAN server.
In this way, our remote and traveling staff members can dial-up to
the LAN and have all of the capabilities as if they were directly
connected to the LAN, such as complete Internet access and access
to all LAN resources. With the local Windows interfaces that we
now employ, remote LAN node access will provide better performance
than the current asynchronous server.
A second planned enhancement is
to set up our file server with anonymous FTP capability for access
by our customers, students, and others. Adding FTP capability to
the NetWare server had meant a difficult, costly proposition; one
software vendor suggested that we replace NetWare with TCP/IP just
to accomplish this single function. Novell, however, has released
a product called FleX/IP, which will allow us to run FTP and
NetWare on the same server and accomplish what we want for a very
cost-effective price.
It remains to be seen how long
56-kbps access will keep our personnel happy.
Conclusion
This article has outlined a
communications enhancing migration that has occurred at our small
business. It is one that is similar to what other companies are
going through, or considering, for a number of business and
professional reasons. Our point in sharing our experience has been
to give others some general food for thought, as well as some
specific pointers.
Did we choose the best
possible solution? We believe so, based upon our criteria, our
needs, our installed base, and the available information at the
time. Have we listed all of the issues? Undoubtedly not. But
hopefully we've moved others forward on their learning process.
Author's Note, April 1996:
There is more to the story that
we hope to write up soon. In short:
- By the end of 1995, we had put
up a Web server, first using a shareware application for
Windows and then installing it on a Linux machine.
- We have not made any of our
LAN servers accessable via the Internet. To date, none of the
Internet servers run NetWare and none of the NetWare servers
run IP.
- The Mac version of cc:Mail has
never been up to par with the PC version in terms of
features, and that situation is not changing. In addition, we
have found the SMTP Gateway product to have bouts of
instability, where we might have to re-boot the system up to
ten times a day. It invariably crashes over the weekend. For
these reasons, and to cut down on long-distance telephone
calls to the remote mail server, we are investigating
abandoning proprietary e-mail in favor of an SMTP approach to
allow users to access their e-mail from the road via the
Internet. This is particularly attractive for our
international travelers.
- Our contract with Netcom and
WilTel (now LDDS WorldCom) was renewed earlier this year. We
have been very pleased with the services of both providers.
- We now have a frame relay
connection between our Vermont and Colorado offices, greatly
enhancing all forms of communication and resource sharing.
|
