Hi Ken,
>> [1] The article said that Cisco has about 95% of the business in linking and routing SNA to TCP-IP and Bay Networks has the other 5%. [2] Do you happen to know how many Token Ring Networks are still around using SNA.
First, to answer [1] above, I can't speak to the actual numbers concerning who's in front by how much, and I suppose if I read IDG's stats they will be different from Forrester's who would be different from Yankee Group's etc.
Suffice it to say that CSCO has a commanding, if not an overwhelming, lead in the SNA to IP market, and Bay, while it has a robust alternative, has not been able to market their option as successfully. This has a downhill snowballing effect. Without heavy market penetration, there is less incentive and experience on which to build new options and feature sets. Therefore, they are relegated to a second ran, and their development and market awareness suffers accordingly.
Some reasons that also may account for this, aside from the herd like following that CSCO maintains at this time, is the fact that carriers such as MCI, along with some other vendors, have partnered with CSCO big time in promoting the IBM Channel IP solution on the WAN, actively displacing the traditional Model 3745 Front End Processor.
This newer means of extending SNA data across the wide area is also poised to begin replacing IBM channel-to-channel (at the main frame Bus & Tag cable and ESCON levels) over the WAN. Here, channel speeds of 45 Mbps and 155 Mbps are not uncommon, and IP is threatening to take a major piece of this sector, as well. (See my comment re: CNT Corp below.) But I digress...
To answer [2] above takes a little more doing, and some explanations. But first, an observation. About ten years ago I thought I had seen the last of SNA in this man's career, since there was a new age in networking abrewing called TCP/IP. Wrong.
One should not believe all one reads. SNA is extremely alive and well today in 1998, and there is no sign that it will be replaced anytime soon where it is still entrenched. In some places it is growing, astronomically, like in check imaging systems, and other mission critical apps such as data warehousing. But some of its major characteristics are changing, constantly, in a way to suggest that it is keeping pace with the changes in the environment around it. Such as its adaptation to IP.
Let me put these three networking principles...
(- SNA;
- Token Ring: "the LAN" protocol; and,
- Token Ring: "the SNA support protocol")
...in their proper perspectives, showing their deployments on a time line.
System Network Architecture, or SNA, actually preceded Token Ring by about a dozen years, or so. SNA was originally conceived and published as a "direction" document in 1974, and latter followed up with the status of Holy Scripture for Blue-ites, as a Six or Seven Layer protocol stack (usually, SNA is represented as a six layer stack, since, in its infinite ability to be proprietary and difficult at the time, Blue's tendency is to combine the physical and data link layers of the OSI Reference Model, which are Layers One and Two of the OSI RM, respectively.
The OSI Reference Model came about later on, during the Early Eighties, largely after some very bloody holy wars among the leading vendors, in large part due to IBM's posturing SNA as the standard, which never happened outside the walls of IBM shops. But the influence of Blue in this regard was felt very deeply then, with lasting implications to this day.
The two stacks (SNA and OSI) do not meet each other one for one, incidentally, as one would expect. This is because each layer's functions found in the SNA model take on a slightly different profile from those in the OSI model, with some layers performing more or less responsibilities than their counterpart's in the other model. But they are generally similar to one another in the end. A similar mismatching of layer functions and attributes can be found between the OSI and TCP/IP stacks, and in the proprietary stacks of DEC, and a host of others.
IBM's Token Ring, also known as the IEEE 803.5 protocol (now virtually one and the same, for all practical purposes) is a link layer (Layer 2) protocol that was conceived and refined mostly by IBM and a few other vendors in the mid-Eighties.
In its first incarnation, it was to be a pure-and-simple (er... better make that just pure) Local Area Network (LAN) protocol to combat the encroaching 802.3 thick- and thin- cable Ethernet (this predates unshielded twisted pair Ethernet), and the 802.4 MAP TOP Token Bus architectures.
Blue also needed to displace some of its own earlier attempts at LAN architectures which turned out to be very limited in capabilities, some of them embarrassing fiascos, because they were not very scaleable, and in some ways were using outdated coaxial and FDM technologies.
At that time IBM was still very reluctant to think about using LAN protocols to attach to their front end processors and other SNA physical unit (PU) devices. That was the job of coax based terminal cluster controllers, and IBM recognized that LANs threatened to cannibalize that model from the start.
It wasn't until Ethernet began making a considerable dent in SNA networking, through the use of desktop software that enabled 3270 terminal emulation to be accessed via PCs, that Big Blue decided to create Token Ring functionality in its local terminal cluster controllers (3274s, 3174s, and 3172s), and later, in their larger front end processors or FEPs (3745s).
Eventually, Token Ring Interface Cards, or TIC adapters, became an optional component in all SNA related network PUs and sub-architectures. And it can still be substituted by Ethernet NICs at the user's discretion in servers and other network nodes.
One thing that I have to say about SNA is that in terms of reliability and robustness, it is the closest thing the data world has to offer that can rival the reliability of the telephone industry's PSTN. Perhaps its reliability is a reflection of its maturity, and hence, its lack of volatility, from a tried and true perspective. Not a lot changes in SNA in comparison to the Internet, say.
But it is still the main workhorse that keeps mission critical applications, sometimes of unimaginable complexity, happening around the clock in major corporations, and its lack of visibility in the trade press, relative to the Internet, should in no way lead one to conclude that it is falling out of favor by the larger MIS organizations. In contrast, the Internet and its IP protocol are still, almost by definition, experiments in progress.
>> I understand that Token Ring networks with fiber-optic cable are capable of transferring data at very high speeds.<<
There is a 100 Mbps standard now, and there is talk of a Gigabit standard for TR. I don't know where that stands at this time, but Ethernet has achieved these already, and there's already talk about a 10 Gigabit standard for Ethernet. But some of TR's greatest advantages stem from attributes other than brute force speed. It is deterministic, it can be prioritized, and it has failover convergence capabilities built into it that Ethernet can only achieve through vendor specific proprietary means. But many of the determistic advantages of TR have been diluted in recent years by Ethernet's switching capabilities which render Ethernet more deterministic, too, in a way.
>Do you have an opinion as to how much of this old legacy hardware is going to be rendered obsolete by the cost of upgrading the equipment to become Y2K compliant. It would seem as though a lot of those old mainframes would have embedded silicon with a large upgrade expense to become Y2K compliant.<
That's a part of it. There is a continuing trend to go the way of Ethernet by enterprises, where they haven't already, and this fact has not been ignored by vendors. In some instances where Y2K bugs exist in TR gear, some vendors have elected to discontinue supporting their products, and discontinue development for new releases. This is a major problem, a major problem, when an enterprise backbone overlay for SNA is Token Ring dependent and there is no migration path, much less a remedy for the ills of Y2K bugs. One such vendor of Toekn Ring bridges is causing a number of top tier banks to go through hoops, forcing them to de-bridge their infrastructures virtually overnight, and go with a data link switching (DLsw) alternative, as a result of the vendor's recent disclosure to discontinue a product line that has been in use for the past ten years. <!?!>
With regard to additional Y2K matters, I don't have all of the implications at my fingertips as they may relate to SNA networking in the larger context, but if you email or PM me, I'll tap my staff for the answers, if they are important to you. We are in the midst of several very large Y2K network remediation projects, and as long as the information is not in any way proprietary, I'd be glad to share it with you.
>>Do you know of any other companies that have an SNA to TCP-IP gateway.<<
Yes. The traditional IBM "channel-to-channel" a.k.a. "host-to-host" or "mainframe-to-mainframe" application vendors who facilitate VTAM over wide area distances through spoofing techniques, are now finding it impossible to ignore IP. One such company is Computer Network Technologies, or CNT. They have recently modified their proprietary quasi-statistical/TDM-based devices, and now have devices that are able to deliver OC3c ATM and TCP/IP at T3 speeds, as well. The other vendors in this class are all following suit.
PM me if you have any specific telecomm-related Y2K questions and I'll see what we can do.
Regards, Frank C.
|
