Before we get started, I would like to define some terms and set some ground rules. For the purposes of this book (and your professional life, I hope), a computer network can be defined as “two or more computers connected by some means through which they are capable of sharing information.” Don’t bother looking for that in an RFC because I just made it up, but it suits our needs just fine.
There are many types of networks: local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), campus area networks (CANs), Ethernet networks, Token Ring networks, Fiber Distributed Data Interface (FDDI) networks, Asynchronous Transfer Mode (ATM) networks, Frame Relay networks, T1 networks, DS3 networks, bridged networks, routed networks, and point-to-point networks, to name a few. If you’re old enough to remember the program Laplink, which allowed you to copy files from one computer to another over a special parallel port cable, you can consider that connection a network as well. It wasn’t very scalable (only two computers) or very fast, but it was a means of sending data from one computer to another via a connection.
Connection is an important concept. It’s what distinguishes a sneaker net, in which information is physically transferred from one computer to another via removable media, from a real network. When you slap a USB drive (does anyone still use floppy disks?) into a computer, there is no indication that the files came from another computer—there is no connection. A connection involves some sort of addressing or identification of the nodes on the network (even if it’s just master/slave or primary/secondary).
The machines on a network are often connected physically via cables. However, wireless networks, which are devoid of obvious physical connections, are connected through the use of radios. Each node on a wireless network has an address. Frames received on the wireless network have a specific source and destination, as with any network.
Networks are often distinguished by their reach. LANs, WANs, MANs, and CANs are all examples of network types defined by their areas of coverage. LANs are, as their name implies, local to something—usually a single building or floor. WANs cover broader areas, and are usually used to connect LANs. WANs can span the globe, and there’s nothing that says they couldn’t go farther. MANs are common in areas where technology like Metropolitan Area Ethernet is possible; they typically connect LANs within a given geographical region such as a city or town. A CAN is similar to a MAN, but is limited to a campus (a campus is usually defined as a group of buildings under the control of one entity, such as a college or a single company).
One could argue that the terms MAN and CAN can be interchanged and, in some cases, this is true (conversely, there are plenty of people out there who would argue that a CAN exists only in certain specific circumstances and that calling a CAN by any other name is madness). The difference is usually that in a campus environment, there will probably be conduits to allow direct physical connections between buildings, while running private fiber between buildings in a city is generally not possible. Usually, in a city, telecom providers are involved in delivering some sort of technology that allows connectivity through their networks.
MANs and CANs may, in fact, be WANs. The differences are often semantic. If two buildings are in a campus but are connected via Frame Relay, are they part of a WAN or part of a CAN? What if the Frame Relay is supplied as part of the campus infrastructure, and not through a telecom provider? Does that make a difference? If the campus is in a metropolitan area, can it be called a MAN?
Usually, a network’s designers start calling it by a certain description that sticks for the life of the network. If a team of consultants builds a WAN and refers to it in the documentation as a MAN, the company will probably call it a MAN for the duration of its existence.
Add into all of this the idea that LANs may be connected with a CAN, and CANs may be connected with a WAN, and you can see how confusing it can be, especially to the uninitiated.
The point here is that a lot of terms are thrown around in this industry, and not everyone uses them properly. Additionally, as in this case, the definitions may be nebulous; this, of course, leads to confusion.
You must be careful about the terminology you use. If the CIO calls the network a WAN, but the engineers call the network a CAN, you must either educate whoever is wrong or opt to communicate with each party using its own language. This issue is more common than you might think. In the case of MAN versus WAN versus CAN, beware of absolutes. In other areas of networking, the terms are more specific.
For our purposes, we will define these network types as follows:
A LAN is a network that is confined to a limited space, such as a building or floor. It uses short-range technologies such as Ethernet, Token Ring, and the like. A LAN is usually under the control of the company or entity that requires its use.
A WAN is a network that is used to connect LANs by way of a third-party provider. An example is a Frame Relay cloud (provided by a telecom provider) connecting corporate offices in New York, Boston, Los Angeles, and San Antonio.
A CAN is a network that connects LANs and/or buildings in a discrete area owned or controlled by a single entity. Because that single entity controls the environment, there may be underground conduits between the buildings that allow them to be connected by fiber. Examples include college campuses and industrial parks.
A MAN is a network that connects LANs and/or buildings in an area that is often larger than a campus. For example, a MAN might connect a company’s various offices within a metropolitan area via the services of a telecom provider. Again, be careful of absolutes. Many companies in Manhattan have buildings or data centers across the river in New Jersey. These New Jersey sites are considered to be in the New York metropolitan area, so they are part of the MAN, even though they are in a different state.
Terminology and language are like any protocol: be careful how you use the terms you throw around in your daily life, but don’t be pedantic to the point of annoying other people by telling them when and how they’re wrong. Instead, listen to those around you and help educate them. A willingness to share knowledge is what separates the average IT person from the good one.