|
|
|
Managing Multivendor Networks
  
- 6 -
Standards
The Need for Standards
ost computer manufacturers would rather not participate in standards organizations
or endorse any standards they did not develop. From the manufacturer's perspective,
little is to be gained (and much lost) from producing products conforming to external
standards; especially when these products might deviate from or conflict with the
manufacturer's own internal standards. However, if a manufacturer can set a de facto
standard, there is much to be gained. In other words, the issue is who is setting
which standards for whom.
The psychology behind the use of nonstandard interfaces is certainly older than
the computer industry--it is merely a different twist on the foot-in-the-door sales
approach. When used in the computer industry, however, this tactic takes on epic
proportions. First, you buy the basic system and a few user terminals. Then, you
add some more terminals and a few printers. As you expand, you add network devices
(modems, controllers, and so forth) to accommodate even more terminals and printers.
Eventually, you realize you have invested so much money in a single vendor that it
might no longer be economically feasible to consider any alternatives.
Fortunately, the economic impact of single-vendor sourcing has been diminished
by third-party companies. These companies provide compatible but often more economical
terminals, PCs, printers, disk drives, tape drives, and so forth. At the same time,
however, the compatibility of these third party products must remain so high that
they are not, in a technological sense, much different from the manufacturer's versions
of the same products. In other words, a third-party, 3270 -type terminal cannot
be dramatically different from an IBM 3270 terminal, or else it won't work.
In contrast, you can't buy a standard DEC VT220 terminal and plug it directly
into a standard IBM 3174 terminal controller. They simply weren't designed to be
interchangeable.
In the world of data communications, however, this story has a slightly different
twist. While it is understandable that hardware and software products from different
manufacturers cannot be interchanged like so many Lego blocks, most of the major
manufacturers eventually understood that they would have to be able to exchange information.
Because IBM took an early lead on the market, it became the focal point for the information
interchange. Any serious contender to the IBM throne has to exchange information
with IBM systems.
Beyond the realm of punched tape and punched cards, the first real means of data
exchange was via magnetic tape. On the negative side, this solution is inelegant,
is usually not well integrated with the mainstream applications, and requires operator
intervention. On the positive side, however, tape transport can accommodate a sizable
amount of data and does not require the permanent assignment of a systems analyst
(although this systems analyst is invariably required during the first few attempts
to define the required parameters on the tape load/unload commands).
Tape transport certainly has its limitations. For one thing, it is difficult to
move a tape across the country in a couple of hours. For another, because tapes are
a magnetic media, they are very susceptible to magnetic interference. Therefore,
tapes and travel mix about as well as oil and water.
To address the need for reliable and more timely transfer of information, data
communications-based alternatives were developed. The most popular and well-known
solution is Remote Job Entry (RJE) workstation emulation. Here, rather than relying
on tape transport, one machine emulates an IBM input or output device (each being
a part of an RJE workstation). To send data to an IBM system, the non-IBM system
emulates a remote card reader to transmit the data. To receive the data, the non-IBM
system emulates either a remote printer or remote card punch.
Of course, the core of this approach is the function of the RJE workstation. Without
the inception of that particular device (or set of devices), there would have been
nothing to emulate.
When IBM developed the RJE workstation, it was, in fact, addressing a shortcoming
in its own product line. Given the strategic and physical positioning of its mainframes
in central sites, IBM needed to accommodate large batches of information coming from
and going to remote satellite operations. To accommodate these remote sites, IBM
manufactured RJE workstations. These workstations were really a combination of devices
(a card reader, a card punch, a printer and a terminal, for example) but they were
handled as a single logical unit over a single data communications link.
For non-IBM manufacturers, this presented an ideal way of interfacing their systems
with IBM systems. Certainly their systems could emulate the different components
of an RJE work-station--a card reader when transmitting a file, a card punch when
receiving a file--and they could thus reliably exchange data in a real-time method.
This type of RJE emulation became so widespread that it became an industry-wide de
facto standard.
Furthermore, the popularity of emulating RJE became a standard that, in a sense,
transcended IBM. The most popular implementation of RJE emulation involved emulating
a 2780, a 3780, or both workstations. Because both workstations could, in fact, exchange
information with another workstation, 2780/3780 RJE emulation became an ideal mechanism
for exchanging information between any two systems--even if neither were an IBM system.
Standards Organizations
Although computer manufacturers would prefer that no standards be applied to them,
they have indeed come to realize that some standards are necessary. For example,
it is extremely convenient that most terminals use the same basic connector and that
the wiring within that connector uses specified voltages and tolerances. For one
thing, this agreement could prevent a possible explosion when a user plugs one type
of terminal into another type of connector. (For a real-life example of this, talk
to someone who has plugged an Apple laser printer set on the AppleTalk interface
into an IBM PC serial port.)
After computer manufacturers realized that they could not avoid standards, they
did the next best thing: Whenever possible, they started submitting their own standards
to the various standard organizations in hopes of gaining a competitive edge. For
example, IBM submitted its SDLC protocol to various organizations--it was subsequently
transformed and endorsed as HDLC (ISO standard), LAP-B (CCITT standard), and ADCCP
(ANSI standard). This is also an example of winning a battle but losing the war,
because SDLC, HDLC, LAP-B, and ADCCP are similar--but incompatible.
Still, this level of participation remains extremely important to computer manufacturers,
even when they do not always win a clear victory. By participating in the development
of emerging standards, they can add their two cents, look at what all their competitors
suggest, and most important, get feedback from the general scientific, and sometimes
user, communities. For the manufacturers, these benefits justify the price of admission
(even though they might secretly rather see the show close).
Standards organizations are often concerned about matters outside the somewhat
limited sphere of computers. In the international world, standards regulate radio,
telegraph, telephone and data communications within and between countries. In fact,
many standards organizations predate the invention of the modern computers. The International
Telecommunications Union (ITU), the parent organization of the Consultative Committee
for International Telegraph and Telephony (CCITT), for example, was founded by treaty
in 1865. Even within the more limited domain of the United States, some of the better-known
standards organizations develop standards that are far beyond the realm of data processing--for
example, ANSI also develops standards for ladders, car washes, and many other nondigital
industries.
Standard-producing organizations can be government-sponsored or independent. Standards
can be the by-product of computer-related associations in which the membership actively
defines and develops standards, or they can be the direct result of extensive and
intensive scientific research specifically aimed at developing a set of standards.
Then again, some organizations do not participate in the development of standards
at all but submit standards proposed by other organizations for broad approval.
There are thousands of organizations worldwide that participate, directly or indirectly,
in establishing standards for the computer and data communications industries. Six
of these organizations can be considered heavy hitters, capable of shaping the future
of data communications.
American National Standards Institute
(ANSI)
Although ANSI sponsors some research activities, it is primarily a clearinghouse
for other organizations that develop and submit standards. These organizations include
the Electronics Industries Association (EIA) and the Institute of Electrical and
Electronics Engineers (IEEE). ANSI was established in 1918 by a consortium of engineering
societies and government agencies, slowly evolving into its current structure. ANSI
is a nonprofit, independent organization that also serves as the U.S. representative
in the International Standards Organization (ISO). Like all of the larger standards
organizations, ANSI is divided into smaller subcommittees to focus on and study various
topics. One such committee of relative importance is the X.3 Standards Committee.
ANSI's X.3 Standards Committee is sponsored by the Computer and Business Equipment
Manufacturers Association (CBEMA). The scope of this committee is computer technology.
Technical Committees within the larger X.3 Standards Committee are appointed to focus
on areas of public data networks, transmission formats, and other computer related
topics.
International Telecommunications
Union (ITU)
ITU was established by treaty in 1865 to define standards in the emerging telecommunications
(that is, telegraph) industry. ITU was realigned into an agency underneath the United
Nations in 1947. Most technical topics within ITU are handled by two committees:
the Consultative Committee for International Radio (CCIR) and the Consultative Committee
for International Telegraph and Telephony (CCITT).
The CCITT's focus includes the areas of data communications, telematic services
(teletex, videotex, and facsimile), and Integrated Services Digital Networks (ISDN).
The CCITT is further divided into study groups that research standards within each
of those three key areas. Each study group works on its assigned topic for four years.
The CCITT has adopted and developed many standards, including the popular V.35 standard
for high-speed communications, but it is best known for the X.25 standard for public
data networks. The U.S. involvement with the CCITT is coordinated through the State
Department.
European Computer Manufacturers
Association (ECMA)
Established in 1961, ECMA voting membership is composed of European-based computer
manufacturers and has a nonvoting membership open to other parties that have marketing
or technical concerns about the European market. ECMA actively contributes to both
CCITT and ISO standards.
Electronic Industries Association
(EIA)
EIA is a trade organization founded in 1924. With respect to data communications,
EIA's prime concern is the interfacing of terminal, telecommunications and computer
equipment. Undoubtedly EIA's best known contribution to standards is the famous RS-232C
interface (although the group also engineered its replacement, the RS-449 interface).
EIA works closely with ANSI toward the development of standards; therefore, ANSI
quickly adopts many of the EIA recommendations as its own standards.
Institute of Electrical and Electronics
Engineers (IEEE)
The IEEE is an extremely large professional society in which members participate
in the development of standards that are forwarded to ANSI for approval. Like EIA,
the IEEE's relationship with ANSI is a direct path for standards to become adopted.
Specifically, the IEEE 802 series of standards (802.2, 802.3, 802.4 and 802.5) have
been adopted by many manufacturers, including HP (802.3) and IBM (802.5).
International Standards Organization
(ISO)
The ISO is a voluntary, independent organization founded in 1947 to find and define
international standards that could be agreed upon by a large number of countries.
The ISO's most significant contribution was the development of the Reference Model
for Open Systems Interconnect (OSI). The work for the OSI Reference Model began in
the late 1970s with the first drafts of the work appearing in the early 1980s. The
purpose of the model is to define a layered architecture for the development of future
standards.
The OSI Reference Model The OSI Reference Model is often seen
as a monolith much greater and far more awesome than intended by its creator, the
ISO. The OSI model is not a mandate for computer manufacturers to produce systems
that are of uniform design and use the same networking architecture. Instead, it
is a layered architecture for the design and implementation of standards that relate
to the interconnection of computer systems.
When the OSI model was introduced, compliance by the manufacturing community was
purely voluntary. The promises of OSI, however, were very attractive to the international
user community, so the private sector became a strong supporter of the OSI model.
Following suit, both the U.S. and United Kingdom governments have also backed the
OSI model through their respective Government OSI Profile (GOSIP) programs. With
both private and government sectors lined up behind the OSI Reference Model, the
computer manufacturers quickly stepped up to support OSI and its emerging standards.
Computer manufacturers generally have little direct experience or interest in
networks composed of systems from multiple vendors. It is of no great concern to
IBM engineers that IBM systems interface with those of Unisys. Nor do Digital executives
stay awake all night worrying about linking their systems to HP.
The user community, however, neither enjoys nor appreciates these constraints.
Their reality involves interfacing IBM systems with Digital systems, with HP systems,
with Sun systems, and so forth. The fact that most vendors offer interfaces to IBM
and UNIX-based systems as multivendor networking solutions is of little value or
solace to them.
So the promise of OSI is to bring forth standards that provide points of connectivity
among diverse systems. The OSI Reference Model should not, however, be thought of
as the ingredients for multivendor soup. Instead, it is the cookbook from which many
recipes can be selected, altered and tasted. Like most cookbooks, OSI represents
a blend of the old with the new. Many existing products and standards have been included
in the OSI architecture.
When the ISO began its work on the OSI model, it intended to define a layered
architecture to facilitate the development or definition of standards that relate
to the interfacing of open systems. An open system was defined as a system that elected
to participate in the standards. This work was carved into layers to first define
the working boundaries for the model and then enable separate small groups to work
on the issues specific to each layer.
Logistics notwithstanding, the layered approach of the OSI Reference Model also
relates to the historic view of data communications and networking and their relationships
to applications, terminals and users. For example, IBM's Systems Network Architecture
(SNA) is highly structured and layered in many aspects (consider the layered functions
of SNA's physical units, for example). Digital's network involves layering networking
services (DECnet) on top of transport services (Ethernet) to provide information
flow between applications and users. So in the most general of terms, the world of
networking lends itself to a layered dissection.
The OSI Reference Model is divided into seven layers. Each layer contains similar
functions and is as localized as possible. This localization enables layers to change
and evolve as new concepts and technology become available, without forcing changes
in its neighboring layers. In brief, these seven layers are (from bottom to top):
- Physical. The physical transmission media.
- Data Link. Low level data packaging and transmission.
- Network. Management of the routes available for data.
- Transport. Delivery and delivery acknowledgment.
- Session. Link management between applications.
- Presentation. Data conversions and transformations.
- Application. End-user and programming services.
Information flows from one system down the OSI layers, across the physical media,
and then back up the layers on the other system (see Figure 6.1). As it moves information
from one system to another, each OSI layer communicates with the corresponding OSI
layer on the other system. Please note, however, that although this peer-to-peer
communication between layers is often shown as direct links, the actual path for
the communications flows through the same layers. Each layer of the OSI model depends
on the lower layers to prepare or transport information from one open system to another
(see Figure 6.2).
FIG. 6.1 Information Flow Through OSI Layers
FIG. 6.2 Actual Communications Path
Another way to view the OSI Reference Model is to divide the seven layers into
the following three logical functions:
- Physical network. Both the Data Link Layer and the Physical Layer are
concerned with the movement of data between two points within the known network.
Data integrity at these layers ensures that no errors are introduced during the transmission
process--the concern is data content, not context.
- System to system. The Network, Transport, and Session Layers focus on
moving information from one open system to another. These layers ensure that the
correct data is delivered to the proper destination.
- End-user services. Both the Presentation and Application Layers provide
a range of services for the end user. These layers ensure that data is in the proper
format for the context (for example, making sure that an application screen is correct
for that user's actual terminal).
GOSIP Not willing or able to be left out of the standards match,
the U.S. government has thrown several hats in the ring. From an organizational perspective,
the government has two significant agencies that define the standards used in networking
and data processing.
The Federal Telecommunications Standard Committee (F T SC) develops
or adopts standards for the government's telecommunications needs in advisement to
the National Communications System (NCS). In defining these federal standards, the
F T SC works with CCITT, ISO, ANSI and EIA. In some cases existing standards
from these standards organizations are implemented directly, while in other cases
the standards are altered to meet the specific needs of the government.
The U.S. Department of Commerce, in the form of the National Bureau of Standards
(NBS), was given legal responsibility for the development of Federal Information
Processing Standards (FIPS) relating to the government's data processing activities.
Whereas the scope of the FTSC is confined to telecommunications, the scope of FIPS
is much broader. As with the FTSC, the NBS tries to work with existing standards,
especially the federal standards published by the FTSC.
The federal standards put forth by the FTSC are not mandates for all government
agencies. Federal agencies must conform to FIPS by virtue of the same law that brought
FIPS into creation. However, compliance need not be instantaneous; governmental entities
have time to plan and adapt.
Another major offspring from the U.S. Department of Commerce is the Government
Open Systems Interconnection Profile (GOSIP). In 1988, the National Institute of
Science and Technology (NIST) developed GOSIP as a subset of the OSI Reference Model
for the government. Once published, GOSIP then became a FIPS, thereby representing
a major commitment from the U.S. government to embrace parts of the OSI Reference
Model.
GOSIP was planned for implementation in two phases, the first phase taking effect
in 1990, the second scheduled for 1992 (see Table 6.1).
Table 6.1 GOSIP Phases
| Layer |
Name |
GOSIP Phase |
| 1 |
Physical |
Phase I: 802.3, 802.4, 802.5 |
| 2 |
Data Link |
Phase I: CSMA/CD, Token Ring, Token Bus |
| 3 |
Network |
Phase I: X.25, ISO 8473 (connectionless) Phase II: ISDN |
| 4 |
Transport |
Phase I: ISO 8073 (connection oriented) |
| 5 |
Session |
Phase I: ISO session (8327 and 9548) |
| 6 |
Presentation |
Phase I: ISO presentation (8823 and 9576) |
| 7 |
Application |
Phase I: X.400, FTAM Phase II: X.500, ODA, CMIP/CMIS, VT, RDB Access |
Provisions within GOSIP enable the government to continue to use and enhance TCP/IP-based
products that might not be OSI compliant in the strictest sense. Furthermore, exceptions
are granted to small expansions of existing networks as well as to situations in
which total compliance represents an economic hardship (or impossibility).
The U.S. Government is not alone in its GOSIP approach. The United Kingdom has
implemented a similar program and other governments are considering following suit.
These tactics, coupled with the growing maturity of the OSI Reference Model, are
laying the groundwork for practical and functional international OSI networks.
Since the implementation of GOSIP, however, U.S. government agencies have continued
to use other networking protocols besides OSI, most notably TCP/IP. The government
incorrectly expected GOSIP standards to displace proprietary protocols because of
OSI's status as an international standard. Although OSI was expected to be universally
implemented, GOSIP products have been slow to come to market, and have not been widely
accepted or deployed.
The Internet Protocol (IP) suite, on the other hand, has been widely accepted,
and products built on this standard have become widely used commodity products. In
addition, the Internet, which supports IP, has developed substantially since the
imposition of GOSIP; while there has been no such infrastructure developed for GOSIP
itself. Those OSI products that have become available are more expensive, and less
well integrated than comparable IP-based products.
In 1994, the Federal Internetworking Requirements Panel (FIRP) was established
by NIST to reassess the government's requirement for open systems networks and compliance
with the GOSIP standard. At that time, FIRP decided that no one protocol suite should
be imposed to meet all government requirements for internetworking, and that it would
be better to adopt the most effective solution in each of the different areas of
information technology; rather than requiring absolute compliance to one set of standards.
Although the reevaluation applies only to the federal government, it will ultimately
have an impact on American industry as well.
NOTE: The reevaluation of open systems networks applies only to
the United States; other countries' OSI requirements still stand at this time. n
Exchange of Standards
As you can see, organizations often adopt each other's standards. For example,
the EIA RS-232C standard was adopted by the CCITT as V.24 and V.28, and by ISO as
2110, and the IEEE 802.3 standard was adopted by ECMA as ECMA-80, 81 and 82, and
by ISO as 8802/3.
Good news and bad news intertwine in this exchange of standards. The good news
is that many different organizations with different origins and orientations can
communicate with one another and share information in an open, honest format. The
bad news is that, in many cases, a standard gets subtle changes by each organization
that adopts it; or one organization might subsequently update an adopted standard
while another organization might not. Thus, for example, an EIA standard might not
be 100 percent compatible with what appears to be the equivalent CCITT standard.
Table 6.2 shows which standards are being exchanged among organizations; Table
6.3 lists the names of these and other popular standards.
Table 6.2 Examples of Standards Exchange
| ISO |
CCITT |
ECMA |
ANSI |
EIA |
FTSC |
FIPS |
| 646 |
V.3 |
|
X3.4 |
|
|
1-1, 7, 15 |
| 1155 |
V.4, X.4 |
|
X3.15, X3.16 |
|
1010, 1011 |
16-1, 17-1 |
| 1177 |
V.4, X.4 |
|
X3.15, X3.16 |
|
1010, 1011 |
16-1, 17-1 |
| 1745 |
|
|
X3.28 |
|
|
|
| 2022 |
|
|
X3.41 |
|
|
35 |
| 2110 |
|
|
|
RS-232C |
|
|
| 2111 |
|
|
X3.28 |
|
|
|
| 2628 |
|
|
X3.28 |
|
|
|
| 2629 |
|
|
X3.28 |
|
|
|
| 3309 |
X.25, X.75 |
40 |
X3.66 |
|
1003 |
71 |
| 4335 |
X.25, X.75 |
49 |
X3.66 |
|
1003 |
71 |
| 4902 |
|
|
|
RS-449 |
|
|
|
X.20bis |
|
|
RS-232C |
|
|
|
X.2lbis |
|
|
RS-232C, RS-449 |
|
|
| 6159 |
X.25 |
60, 71 |
X3.66 |
|
1003 |
71 |
| 6256 |
X.25, X.75 |
60, 71 |
X3.66 |
|
1003 |
71 |
| 8802/2 |
|
|
(IEEE 802.2) |
|
|
|
| 8802/3 |
|
|
(IEEE 802.4) |
|
|
|
| 8802/4 |
|
|
(IEEE 802.4) |
|
|
|
| 8802/5 |
|
|
(IEEE 802.5) |
|
|
|
| 10020-21 |
X.400 |
|
|
|
|
|
| 9594 |
X.500 |
|
|
|
|
|
| 9594 |
V.22 |
|
|
|
1008 |
|
|
V.24 |
|
|
RS-232C, RS-449 |
|
|
|
V.26bis |
|
|
|
1005 |
|
|
V.27bis |
|
|
|
1006 |
|
|
V.27ter |
|
|
|
1006 |
|
|
V.29 |
|
|
|
1007 |
|
Table 6.3 Standards Descriptions
| ISO |
|
| 646 |
Seven-bit character set |
| 1155 |
Use of longitudinal parity for error detection |
| 1177 |
Structure for start/stop and synchronous transmission |
| 1745 |
Basic mode control procedures |
| 2022 |
Code extension techniques based on ISO 646 |
| 2110 |
25-pin DTE/DCE connector and pin assignments |
| 2111 |
Basic mode control procedures-code independent |
| 2628 |
Basic mode control procedures-complements |
| 2629 |
Basic mode control procedures-conversational |
| 3309 |
HDLC frame structure |
| 4335 |
HDLC elements of procedures |
| 4902 |
37-pin and 9-pin DTE/DCE connectors and pin assignments |
| 6159 |
HDLC unbalanced class of procedures |
| 6256 |
HDLC balanced class of procedures |
| 7498 |
OSI basic reference model |
| 7776 |
HDLC-X.25 LAPB-compatible DTE data link procedures |
| 7808 |
HDLC connectionless class of procedures |
| 7809 |
HDLC consolidation of classes of procedures |
| 8072 |
Transport Layer definitions |
| 8073 |
Transport Layer connection-oriented services |
| 8208 |
X.25 packet-level protocol |
| 8326/27 |
Session Layer connection-oriented services |
| 8348 |
Network Layer definitions |
| 8473 |
Network Layer connectionless services |
| 8571 |
File Transfer, Access and Management (FTAM) |
| 8602 |
Transport Layer connectionless services |
| 8613 |
Office Document Architecture (ODA) |
| 8632 |
Computer Graphics Metafile (CGM) |
| 8648 |
Network Layer internal organization |
| 8802/2 |
Class 1 logical link control |
| 8802/3 |
CSMA/CD |
| 8802/4 |
Token Bus |
| 8802/5 |
Token Ring |
| 8822/23 |
Presentation Layer connection-oriented services |
| 8832/33 |
Job transfer and manipulation |
| 8878 |
Use of X.25 as a connection-oriented service |
| 8879 |
Standard Generalized Markup Language (SGML) |
| 8886 |
Data Link Layer definitions |
| 9040 |
Virtual terminal services |
| 9314 |
Fiber Distributed Data Interface (FDDI) |
| 9548 |
Session Layer connectionless services |
| 9576 |
Presentation Layer connectionless services |
| 9594 |
Directory services |
| 9595/96 |
Network management (CMIS and CMIP) |
| 10020/21 |
Message-handling services |
| 10026 |
Distributed transaction processing |
| CCITT |
|
| V.3 |
International alphabet #5 |
| V.4 |
Structure for V.3 transmission over phone network |
| V.5 |
Standard synchronous signaling rates for dial-up lines |
| V.6 |
Standard synchronous signaling rates for leased lines |
| V.14 |
Asynchronous to synchronous conversion |
| V.21 |
300-bps modem for switched phone lines |
| V.22 |
1200-bps modem for switched and leased phone lines |
| V.22bis |
2400-bps modem for switched and leased phone lines |
| V.24 |
List of exchanges between DTE and DCE devices |
| V.25 |
Automatic calling/automatic answering equipment |
| V.26bis |
1200/2400-bps modem for switched phone lines |
| V.27bis |
2400/4800-bps modem for leased phone lines |
| V.27ter |
2400/4800-bps modem for switched phone lines |
| V.28 |
Electrical characteristics for unbalanced circuits |
| V.29 |
9600-bps modem for 4-wire leased phone lines |
| V.32 |
9600-bps modem for 2-wire switched phone lines |
| V.33 |
12,200- and 14,400-bps modem for leased phone lines |
| V.35 |
Device interface supporting rates up to 48 Kbps (no longer recommended) |
| V.42 |
Error detection and correction scheme for modems |
| V.42bis |
Data compression method for use with V.42 |
| V.100 |
Interconnection between public data networks and public switched telephone networks |
| V.110 |
ISDN terminal adaption |
| V.120 |
ISDN terminal adaption with statistical multiplexing |
| V.230 |
General data communications interface (layer 1) |
| X.1 |
Class of service in public data networks |
| X.2 |
Services and facilities in public data networks |
| X.3 |
Packet assembly/disassembly (PAD) facilities |
| X.4 |
Structure of V.3 transmission over public network |
| X.20 |
Interfacing devices using asynchronous transmission |
| X.20bis |
Use of DTE devices on public network via asynchronous modems |
| X.21 |
Interfacing devices using synchronous transmission |
| X.2lbis |
Use of DTE devices on public network via synchronous modems |
| X.25 |
Interfacing DTE and DCE devices over packet networks |
| X.28 |
Interface for start/stop device accessing a PAD |
| X.29 |
Exchange procedures for a PAD and a packet-mode DTE |
| X.75 |
Control and transfer between packet networks |
| X.400 |
Message handling services |
| X.500 |
Directory services |
| X.509 |
Authentication framework for X.500 |
| ECMA |
|
| 40 |
HDLC frame structure |
| 49 |
HDLC elements of procedures |
| 60 |
HDLC unbalanced class of procedures |
| 61 |
HDLC balanced class of procedures |
| 71 |
Transport protocol (for ISO/OSI layer 4) |
| 80-82 |
Physical and logical link control for CSMA/CD |
| 84 |
Data presentation protocol |
| 85 |
Virtual File Protocol (File transfer) |
| ANSI |
|
| X3.4 |
Information interchange code |
| X3.15 |
Bit sequencing for X3.4 in serial data streams |
| X3.16 |
Character and parity structure for X.34 transmissions |
| X3.28 |
Standard for the use of communication control characters |
| X3.41 |
Code extensions for the 7-bit V3.4 interchange code |
| X3.66 |
Advanced Data Communication Control Procedures (ADCCP) |
| X3.92 |
Data Encryption Algorithm |
| IEEE |
|
| 802.2 |
Data Link Layer |
| 802.3 |
CSMA/CD |
| 802.4 |
Token Bus |
| 802.5 |
Token Ring |
| 802.6 |
Metropolitan area networks |
| 802.7 |
Broadband local area networks |
| 802.9/802.10 |
Integrated LAN/MAN networks |
| 802.11 |
Wireless LAN Medium Access Control and Physical Layer specification |
| 802.12 |
100 Mbps (Fast Ethernet) |
| 1003 |
Portable operating systems (POSIX) |
| 1394 |
High Performance Serial Bus ("Firewire") |
| EIA |
|
| RS-232C |
Interfacing DTE and DCE devices via serial exchange |
| RS-449 |
37- and 9-pin DTE interfaces for serial exchange |
| FTSC |
|
| 1003 |
Synchronous data link control procedures (ADCCP) |
| 1005 |
Coding and modulation requirements for 2400-bps modems |
| 1006 |
Coding and modulation requirements for 4800-bps modems |
| 1007 |
Coding and modulation requirements for 9600-bps modems |
| 1008 |
Coding and modulation for 600/1200-bps modems |
| 1010 |
Bit sequencing of ANSI X3.4 for serial transmissions |
| 1011 |
Character/parity structure for ANSI X3.4 transmissions |
| 1015 |
Analog to digital conversion of voice by 2400 bps linear predictive coding |
| 1016 |
Analog to digital conversion of radio voice by 4800bps code excited linear prediction
(CELP) |
| 1026 |
Interoperability and security requirements for use of the Data Encyrption Standard
in the physical layer of data communications |
| 1027 |
Security requirements for equipment using the data encryption standard |
| 1028 |
Interoperability and security requirements for use of the Data Encryption Standard
with CCITT Group 3 facsimile equipment |
| 1045 |
High frequency radio automatic link establishment |
| 1046 |
Radio Automatic Networking |
| 1047 |
Radio automatic message delivery |
| 1048 |
Radio automatic networking to multiple-media |
| 1049 |
Radio automatic operation in stressed environment |
| 1052 |
Radio modems |
| 1101-1108 |
Land mobile radio |
| FIPS |
|
| 1-1 |
Code for information interchange |
| 7 |
Implementation of FIPS 1-1 and related standards |
| 15 |
Subsets of the 1-1 code for information interchange |
| 16-1 |
Bit sequencing of the 1-1 code for serial transmissions |
| 17-1 |
Character and parity structure for FIPS 1-1transmissions |
| 35 |
Code extension techniques using 7 or 8 bits |
| 71 |
Advanced Data Communication Control Procedures (ADCCP) |
| 81 |
Data Encryption Standard (DES) Modes of Operation |
Dramatic differences in standards were much more prevalent in the days before
the OSI Reference Model. In today's world, each organization dances around the same
OSI maypole, hoping to create a universal set of multifaceted standards. The fact
that a given standard at a given layer was created by one organization or another
becomes, for the most part, irrelevant--the ISO stamp of approval is the great equalizer.
Emerging Standards
New standards, and indeed, even new standards organizations are being created
at an accelerated pace. In addition, there is a growing trend among companies to
make informal alliances to create a de facto standard. Formalized or not, however,
a new standard must prove its vitality in an ever-changing marketplace before being
accepted by the user community.
Salutation Architecture
The Salutation Consortium, Inc.--whose members include IBM, Novell, and HP--is
planning to release a specification that will let devices identify and communicate
with each other. The consortium's middleware, Salutation Architecture, creates a
handshake between several different types of devices, such as faxes, printers, and
PCs. The consortium will release the specification to the developer community without
royalty or fees. The middleware fits within the operating system and defines a set
of APIs that applications are able to understand. It has discovery capability, so
it can identify devices, determine their capabilities, and communicate. The middleware
is similar in nature to Microsoft's Microsoft At Work, a project designed to connect
office equipment to PCs. Salutation Architecture is more network-oriented, however,
and At Work never took off.
SONET (synchronous optical network)
SONET is a high-speed transmission standard initially developed for fiber-optic
systems. It has since been adapted for microwave radio systems, for use in areas
where physical cabling is difficult.
Plug and Play Standard (Microsoft)
The Plug and Play standard is Microsoft's approach to multivendor compatibility.
Although it enables users to easily integrate peripherals from many vendors, it is
limited by its proprietary nature. However, the standard is supported by many vendors,
and is likely to become a de facto standard. Plug and Play has been built into the
Windows 95 operating system and enables PCs and peripherals from different vendors
to work together under the Microsoft environment. Under this paradigm, if a PC user
attaches a new peripheral, it can start working immediately. A Plug and Play hardware
device automatically sends information to the host about its basic services, what
it requires to operate, and which drivers it needs. The operating system software
will then automatically configure the device. The catch is, the peripheral must be
specifically designed for the standard.
Firewire (IEEE 1394)
This standard was designed to speed up LAN communications over high-speed serial
ports. It can function as a local device interface for ATM or Fast Ethernet, enabling
ATM to be routed to individual devices inexpensively. The standard might ultimately
provide the framework necessary for multimedia LAN applications, and is designed
to transport data at rates of up to 400 Mbps.
Common Desktop Environment (CDE)
There have been many attempts to unify a fractured U N I X market,
but only the Common Desktop Environment (CDE) has succeeded. Part of the Common Operating
System Environment (COSE) agreement, CDE establishes several common features across
all major U N I X implementations. CDE does not actually implement
any new technology; rather, it is a composite of bits and pieces of various U N I Xs
from HP, Sun Microsystems, and IBM.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
Profit and
Value from Information Technology
