Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here. Copyright © 1999, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.

Management Briefing

It’s always tough to define the theme of a trade show, even when the show’s supposed to have one.  It’s particularly tough with N+I, whose sprawling disorder has become legendary.

The difficulties ease if one abandons the idea of a technology theme this year, and instead looks at what might be called the “attitude” theme.  Interop was the flagship event in a period of transition for IP.  The theme of Interop this year was “What does IP want to be when it grows up, and does it want to grow up anyway?”

On the one hand, there are many who cling to the idea that IP and “the Internet” are somehow going to be the harbinger of populism in public carrier services.  The evil empire of the RBOCs and PTTs will crumble before the righteous energy of the Internet crowd.  Right.  On the other hand, there are people who believe that transformation of the Internet, and in fact the whole IP process, is key to creating a future network that supports all applications well.

Truth, where it exists at all these days, is often found mid-way between extremes, but this may not be the case with the attitudes and directions on IP and the Internet.  Both camps seem bent on self-destruction as the alternative to getting their way, and both may succeed in their suicidal desires, taking their technology with them.

The IP-is-everything school has a keynote in the Interop issue of Network World, with Scott Bradner’s column.  Scott clearly believes that the IETF and the Internet community have to be left to develop public IP the way they see fit, and not be enslaved by the regulatory/governmental process.  This theme, not uncommon in academia, is carried forward by a host of vendors (usually smaller ones these days) who tout the use of the Internet and IP for all forms of public communications.  We have IP local loop players, IP Centrex players, IPsec VPN tunneling players, etc.  For reasons we’ll get into in a minute, this group lacks a central vendor figure, and so there is a little fuzziness in the rhetoric these days.

The contrary school seems to be equally unfocussed.  Some carriers are clearly burying their heads in the sand with respect to the evolution of public network services.  At the very least, the traditional RBOCs and IXCs seem to be using new-generation services as a clever press ploy while they maneuver in both a business merger and regulatory pressure sense to preserve the status quo.  Watching telecom reform, one might well conclude that Scott Bradner is right about regulation stifling progress.

One topic of the show that epitomizes the attitude conflict is IPv6.  There are vendors who believe that IPv6 is the salvation of the Internet and of IP public networking.  Others believe it will never be adopted.  Clearly the failure of the IETF to establish support for a key standard would be an indication that the IETF is losing ground.  3Com has proposed a “Realm-Specific Internet Protocol” or RSIP to alleviate current problems with IPv4, and this appears to be gaining support.  Is it an aid to transitioning to IPv6 or an indication that there won’t ever be a transition?

This is important because it’s clear that IPv4 can’t be the basis for universal multimedia networking worldwide.  Does the fact that the IP community can’t promote its own architecture for the future mean we couldn’t safely start a migration to universal IP?  Should we migrate anyway and trust the egg-heads?  Should we expect a regulatory body like the FCC to step in and mandate an architecture that would credibly fulfill the mission that the IP types appear to have set for themselves?  The IP community itself, torn between purism and commercialism, can’t converge on a viewpoint here.  Even Cisco, spiritual leader of IP, is waffling for opportunistic reasons.

The debate between Cisco and Nortel on PBXs is also interesting.  Cisco has made the stupid recommendation that users stop buying PBXs.  Nortel made the stupid comment that they’ll keep making them as long as Cisco keeps buying them (indicating that Cisco has them already, which is true).  That Cisco then said that they were not renewing PBX leases isn’t an answer to the real issue.  Cisco has to publicly back its own statements.

What is obscured here is the real issue, which is whether IP-based PBXs could offer any value relative to the current traditional ones.  IP isn’t automatically a good idea for voice or video, it’s just an option whose merits have to be examined relative to the costs, and merits, of other approaches.  This kind of dopey exchange between vendors is interesting for the media but useless to the real buyers,  because it fails to address the issues on which real purchases will be made.

Interop is an IP show, and IP is and has always been a kind of academic lake.  There are now powerful vendors trying to make billions on IP, and that means changing its role from something that was technically driven to something that would become somewhat a public utility.  We are not now, nor will we ever be, going to depend on non-regulated, elitist, processes to control what is an essential public service.  That’s a fact.  Most vendors, and most IP people recognize this.

Why, then, is a show like Interop seeming to be a conflict between two poles when most people realize there’s only one possible outcome?  Because a trade show isn’t about truth or reality, but about entertainment.  For every attendee who honestly wants to learn about the technology of the future, and base future buying decisions on that knowledge, there’s a hundred who want spectacle, and the majority rules.

Ironically, it’s the fact that the average buyer won’t really make intelligent choices that makes the question of “IETF versus FCC” a valid one.  A mass market can never be a smart market, so somebody has to decide on behalf of the masses—somebody smart who has their interests at heart.

That’s the heart of the Interop attitude theme.  Who will be in charge of the future?  Scientists have always believed that their understanding of the issues gave them a special right to decide on behalf of those without understanding.  Regulators and legislators have always believed that only those who are elected or appointed to a public trust can be trusted.  Both sides believe that the other has failed to meet its responsibilities.

Both sides are right, but it goes back to the issue of the attendees.  It’s true that a dumb market is a little one.  It’s also true that a mass market for IP networking will develop only if one side or the other manages to gain public confidence.  That’s why averaging the extremes of viewpoint isn’t useful; only one or the other can win—or neither.

That “neither” choice is the one that Nortel offered in their response to Cisco’s PBX statement.  It’s true that PBXs will be built as long as they’re bought.  It’s also true that they’ll be bought until someone figures out how to make a new technology for premises voice as respectable as the old.  Maybe the IETF is the answer.  Maybe the FCC is.  If neither succeeds, then IP fails too, and there will be PBXs for a generation to come.

The questions Interop posed were valid ones.  The only answer it offered was that maybe Interop isn’t the forum where we’ll get answers.  We’ve started to boycott trade shows because they’re increasingly Circus Maximus instead of forum for rational exchange.  Most vendors tell us they believe the same way, but dare not bow out of the shows because of how it would look.

In the Know

The question of what a VPN really is may be critical to the future of public networking.  In the previous issue (August, 1999), we developed a definition of a “real” IP VPN.   Now, based on it, we can review the ways in which this real VPN can be created.

There are already products on the market that can offer at least a valid claim to supporting “real” IP VPN services.  More will be arriving this fall and into next spring.  We propose to use the approaches we develop in this section to judge vendor approaches to VPN equipment and service provider approaches to VPN services.  In the last of our series on VPNs, we’ll look at some of those approaches in detail.

This month, we’re focusing on the theoretical models for real IP VPNs.  Our goal is to define the workable approaches so that anyone who wants to validate a particular VPN offering need only classify it according to these rules, and from that classification determine its strengths and limitations.

Strategies

Cisco and SNA have always had a kind of love-hate relationship.  On the one hand, the stubborn refusal of SNA users to adopt IP networking for their key applications has stymied Cisco sales efforts in many major accounts.  On the other hand, the conversion of SNA users to IP at this point in time would present Cisco with a windfall profit source at a time when enterprise networking is flagging in growth.

This summer, Cisco and IBM did a deal to transfer IBM’s network assets to Cisco.  This won’t include SNA technology, but it will still set the stage for Cisco to drive the last great protocol conversion effort most of us will see, the migration of the hold-out SNA traffic to IP.

Cisco, of course, isn’t naïve enough to think that simply buying up some IBM network assets will cause SNA buyers to leap into Cisco’s arms.  Almost concurrent with the announced deal was a Cisco announcement on SNA switching.  We’re going to look at that technology here, to determine whether Cisco has made a real advance in handling SNA traffic by IP devices.  If so, it’s paving the way for that last migration.  If not, it’s business as usual for SNA buyers—at least for now.

Cisco’s SNA Switching Services

Cisco’s SNA Switching Services (SNASw) is really an improvement on a concept that Cisco has been involved with for much of the 1990s.  IBM spawned the APPN Implementers’ Workshop (AIW) in the early part of the decade to provide some open-forum impetus to APPN, countering the populism of IP.  The concept probably didn’t do a lot for APPN, but it did advance the cause of Data Link Switching (DLSw), another technology that Cisco has used to support SNA applications on IP networks.

There are four major components to SNASw:

1.       A Branch Extender (BX) that uses a kind of “multi-personality” feature to simplify the support of attached SNA PU/LUs representing users and applications.

2.       An Enterprise Extender (EX) that offers HPR over IP to permit SNA hosts to communicate with remote devices using what looks like native SNA capabilities (HPR).

3.       Full support for IBM’s High-Performance Routing (HPR).

4.       Usability/Manageability enhancements.

The most useful and innovative concept in the release, as far as we can see, is the Branch Extender.  BX takes a significant step to simplify SNA/APPN networking, and it’s a good enough idea to save what might otherwise be a bland release.

In a normal APPN network, edge devices attach to an APPN End Node (EN), and the network’s routing core is made up of APPN Network Nodes (NNs).  NNs exchange topology data like routers do, and making every router in a TCP/IP network into a parallel NN would increase topology traffic considerably.

BX solves that problem by looking like an EN to upstream (toward the host) nodes like VTAM, and like an NN to downstream nodes like “real” ENs and the various pre-APPN PU types.

BX-compatible routers might be linked to the data center Token Ring LAN, exchanging traffic with VTAM, or with channel-attached Cisco routers.  The BX-to-VTAM connection provides APPN NN services to the distributed community of users.  In essence, the BX spoofs an EN that supports all of the real attached devices (which, of course, are attached via IP).  Other SNA resources are also attached as ENs, so the only other NN in the network would be a backup VTAM.

To real SNA EN devices or early PUs, the BX looks like an APPN/NN.  That means that these devices go to the BX for routing services (it, in turn, goes to VTAM’s NN).  Because EN devices don’t do topology updates, there are none required in the network at the SNA level.  TCP/IP topology updates continue as always, of course.

BX is generally run in the data center, either on channel-attached routers or other routers.  It has an almost client-server relationship with the host/client environment, meaning that it provides routing services (extended Bind support) to ENs and proxies ENs and PUs to VTAM even if it’s not directly in the data path.  This configuration can be useful when session activity is high enough to make performance of the virtual EN/NN an issue.

The Enterprise Extender offering is designed to make IP networks appear as SNA transport networks, using IBM’s HPR.  Cisco is now supporting full HPR capabilities, including flow control using IBM’s Adaptive Rate-Based congestion control (ARB).  If this feature functions as claimed and is implemented correctly, it should make an IP network deterministic in SNA terms, and it should also make it possible to transport SNA in “native mode”, meaning without making IP behavior visible at the SNA level.  IBM has specified HPR as compatible with “connectionless” transport, meaning datagram services.  This application is thus within the standard IBM approach.

Note: Those of you interested in more about HPR can find a tutorial in Netwatcher Volume 13 Number 6, which is the June, 1995, issue.  This issue is available at our standard per-issue price to subscribers only; sorry, it’s not posted on the Internet.

Managing this new environment is dualistic.  The SNASw node is an SNA node, and thus manageable from NetView.  In addition, Cisco is offering an SNMP-based management application called “SNAView” and an SNA topology tool called “Maps”, that shows how the SNA network is mapped onto the IP infrastructure.

SNAView offers SNA session tracing and trouble-shooting reflecting the IP-based structure of the real data flows.  Thus, it’s an important tool for managing the network for a user who decides on enterprise IP and still maintains native SNA applications.

Will This Change the Landscape?

There is no question that SNASw is an important step forward for users who currently build native SNA networks and hope to build IP private networks in the future.  With it, support of both TN3270 clients (SNA emulation via a TN3270 conversion) and native SNA clients (attached via DLSw+, which is Cisco’s version of DLSw, or via HPR/EX) is provided.  This hurdles the barrier of specialized SNA hardware.

What this won’t do is promote the rewriting of SNA applications for TCP/IP.  In fact, it might deter it by creating a stopgap measure that’s just effective enough at making SNA and IP coexist to lance the boil of user discontent, so to speak.

Nevertheless, this is an important development for Cisco and for SNA users who recognize the inevitable migration to IP applications and networks.

Down the Line

In future issues, we’ll consider the vendor implementations of VPNs, using the model we’ve devised in the August and September issues.    We’ll also be visiting some of the early implementations of XML-based voice systems this fall.