|
|
4. LAN Internetworking Technologies
|
|
 |
|
|
|
|
 |
From:
Understanding the Network
Author: Michael Martin
Publisher: New Riders
More Information
|
|
 |
 |
 |
In this chapter, we look at the three most prevalent LAN protocols: Ethernet,
Token Ring, and Fiber Distributed Data Interface (FDDI). Of
the three, Ethernet easily has the largest installation base, which continues
to expand into the foreseeable future. Token Ring and FDDI, although technically
more efficient, resilient, and complex than Ethernet, will more than likely
continue to lose market share. The total dominance of Ethernet in the LAN,
however, is a relatively recent phenomenon. Until the development of a 100Mbps
Ethernet or Fast Ethernet, it was accepted wisdom that Token Ring
and FDDI installations would one day outnumber Ethernet installs.
But, Fast and Gigabit Ethernet have relegated FDDI and Token Ring to
near “legacy” network status. Although their current institution
base will remain viable for at least the next few years, their long-term usefulness
is questionable. For this reason, this chapter is weighted toward Ethernet. Each of these protocols began as proprietary standards that were later
standardized by standards bodies. When these protocols were introduced into
the marketplace, it was common for both proprietary and standards-based versions
to be for sale and to be implemented. Today, only standards-based versions
of these products are available. In the interest of completeness, however,
both the proprietary and standards-based versions are discussed here when
relevant.
In 1980, the Institute of
Electrical and Electronic Engineers (IEEE) began work on the development of
LAN/MAN standards: IEEE project
802. Its charter was to develop a set of OSI-RM Layer 1 and Layer 2 protocol
standards for LANs and MANs. These standards specified the operational definitions
for a collection of logical interfaces that make up the transmission interface
that resides on OSI-RM Layers 1 and 2. Logical interfaces are needed so that different transmission protocols
can interact with one another in an efficient manner. Each logical interface
defines a “handoff” point that must be able to provide a specific
service. Establishment of such a point enables different transmission protocols
to hand off upper layer
protocol (ULP) data between them without corruption or additional interaction
with the ULP. As mentioned in our discussion of the OSI-RM, this point also
provides a basis for service enhancement or replacement without affecting
the communication process as a whole. To this end, the IEEE's standards development
focuses on distinct functional categories. These categories are as follows: -
General Architecture and InternetworkingThis category covers bridging,
switching, Layer 2 addressing, and management. These standards are developed
by the 802.1 subcommittee. The majority of these standards define how
OSI-RM Layer 2 transmission protocols will function in an operational
and implementation way.
-
Logical Link Control (LLC)LLC provides the software interface between
the Layer 2 transmission protocol and the Layer 3 networking protocol.
The LLC standard was developed by the 802.2 subcommittee. LLC is used
by all the IEEE standards-based protocols and several non-IEEE protocols.
It is classified as part of OSI Layer 2 functionality. Nevertheless, it
functions as a distinct service interface to manage the actual delivery
of data between end-stations. Data link (the term used to describe this
function with WAN protocols) or link control is provided differently,
depending on the transmission protocol, but the service's function is
the same regardless.
Media Access Control (MAC)MAC is responsible for the
data transmission frame format, data integrity checking, and managing station
access to the physical transmission medium (for example, collision detection
in the case of Ethernet). For each MAC protocol there is a separate 802 subcommittee.
Currently eight different IEEE subcommittees develop MAC standards for physical
media and wireless communication. In terms of the LAN, the 802.3 subcommittee
develops standards for Ethernet, and 802.5 develops standards for Token Ring.
The MAC subcommittee standards encompass both OSI-RM Layers 1 and 2 functionality.
The MAC service interface resides in Layer 2, and the PHY service interfacewhich
defines the signaling and encoding used to transmit the MAC interface framesresides
at Layer 1. The MAC protocol is often used to generalize the Layer 2 function
because it represents for the most part the common denominator between the
PHY and LLC service layers of the data transmission function. SecurityAll security issues and standards dealing with
the 802.x standards are developed by the 802.10 subcommittee.
The development and implementation of standards-based technologies assures
compatibility between networking products manufactured by different product
vendors. The standards development process is a collaborative effort between
the IEEE, networking product vendors, and other interested parties. Actually,
quite often, vendors develop proprietary implementations of technologies and
then offer them as a standard or as an addition to the existing standard.
When a new technology is developed, a new IEEE subcommittee is formed to codify
a standard. In the event that an innovation is made to an existing IEEE standard,
it is handled as a subcommittee's supplemental project. Each supplement is
assigned a one- or two-letter designator. For example, the IEEE standard for 100Mbps Fast Ethernet is 802.3u.
The IEEE standardization process usually takes a few years, so quite often,
there will be competing “proprietary” versions of the same base
technology in the marketplace. Although these technologies might provide the
same functionality, they are usually incompatible. For more information about
the IEEE 802 committee, you can check out their Web site at http://grouper.ieee.org/groups/802/index.html. In the discussion of the OSI-RM in Chapter 1, “Understanding
Networking Concepts,” the IEEE variation of the OSI-RM Layer
2 was also introduced. Under the IEEE/OSI variation, Layer 2 is split in half
so that the lower half is the media access layer. The media access layer controls
Layer 2 source and destination addressing, transmission signaling and encoding
(framing), and error and data flow control. The upper half of the IEEE/OSI
Layer 2 variation is the Logical Link Control (LLC) interface. The IEEE subcommittee 802.2
is responsible for the development of the LLC specification. The LLC layer
is used by the MACs (and some other protocols, such as FDDI) to provide an
interface between Layer 3 protocols and the Layer 2 MAC protocols. The LLC standard has two interfaces (see Figure
4.1). The first is theNetwork/ LLC interface, which defines the interface
between the LLC and the Layer 3 protocol. The second is the LLC/MAC interface,
which handles communication between the LLC and the MAC sublayer. These interfaces
allow the LLC to interpret and generate commands between the Layer 3 network
protocol and Layer 2 transmission protocol. This communication includes data
flow control, error detection and recovery, and the exchange of Layer 2 and
Layer 3 address information. Although the MAC is responsible for the transmission
of the Layer 3 data between end-stations, it is the responsibility of the
LLC to ensure that data is delivered to the “service” or application
for which it is intended. It accomplishes this through the use of Service
Access Points. The LLC data unit (LLC PDU) is generated by the LLC Layer 3 interface and appended with the
Layer 3 data, and both are encapsulated in the data portion of the MAC frame. The LLC protocol data header
consists of two parts. The first part is SAP information. The SAP is used
by the Layer 3 protocol to identify what service the data is associated with.
Two fields in the LLC header are used for this purpose: Destination Service Access Point (DSAP) and Source Service
Access Point (SSAP). The DSAP indicates the service protocol to which the
data in the LLC PDU belongs. The SSAP indicates the service protocol that
sent the data. These are the same value, as the source and destination protocols
must be the same in order to actually exchange data. The other part of the LLC header is the LLC control field, which indicates
the LLC type and service class that should be used to deliver the Layer 3
data. The LLC control messages are used to send messages about the transmission
of data between the source and destination end-stations. The LLC PDU is actually
the “data” contained in the data field of the transmission packet,
because the LLC PDU is used for both control messaging and the actual delivery
of the Layer 3 datagrams. Three types of LLC data delivery services exist. Figure 4.2 illustrates the LLC PDU format. The first LLC service, Type 1, provides unacknowledged connectionless data delivery.
Type 1 is a best-effort delivery
service. It offers no facilities for packet acknowledgement, flow control,
or error recovery. No logical connection is established between the source
and destination devices; rather, the source device sends the packet over a
shared channel, where all the connected devices see the packet, but only the
destination device accepts it. LLC Type 1 is the most commonly used LLC service,
because most protocol suites have a reliable Layer 4 (transport) protocol.
Type 1 LLC service is the fastest of all the LLC delivery services. LLC service Type 2 is a connection-oriented
data transmission. LLC 2 requires that a logical connection be established
between the source and destination devices. Data delivery still occurs over
a shared channel, however. The connection is established by the source host
when the first LLC PDU is sent. When it receives the LLC PDU, the destination
host responds with the control message “LLC PDU,” no data, just
a connection acknowledgement. When connection is established, data can be
sent until the connection is terminated. LLC command and LLC response LLC
PDUs are exchanged between the source and destination during the transmission
to acknowledge the delivery of data, establish flow control, and perform error
recovery if needed. The transmissions of certain Layer 3 protocols require
the use of LLC Type 2. The LLC Type 3 provides
acknowledged connectionless data delivery. LLC Type 3 provides facilities
for the establishment and termination of data delivery. However, it does not
provide for error recovery and uses a more primitive flow-control mechanism
than LLC Type 2. The LLC station service class is determined by its capability to support different
service types. All LLC stations can support class 1 service, which means they
can support LLC Type 1 delivery. LLC class 2 service supports Type 1 and Type
2 delivery. Class 3 supports LLC Type 1 and Type 3 delivery. Class 4 stations can support all LLC
service types.
|
|
|
|
|
|
 |
 |
Breaking News
|
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
OpenCable Architecture.
|
|
 |
 |
Just Published
|
Residential
Broadband, Second Edition
by George Abe
Introduces the topics surrounding high-speed networks
to the home. It is written for anyone seeking a broad-based familiarity
with the issues of residential broadband (RBB) including product
developers, engineers, network designers, business people, professionals
in legal and regulatory positions, and industry analysts.
|
|
 |
|

|