The problem with logical analysis is that the world isn't necessarily logical. We mentioned Bay's possible acquisition by either Lucent or Nortel in our last issue. We thought (though that issue didn't say so) that Lucent would be the better deal. Naturally, Nortel did the deed.

The acquisition, and particularly its timing, portend great events in the data networking space. There will probably be other acquisitions, some logical and some less so, and possibly some sinkings of key players. As buyers of, or vendors in, the data networking market, you (our reader) have a vested interest in the future, and so we're going to try to lay it out for you.

Let's start with the merger itself. Bay is a strong enterprise player, primarily in the LAN space. It has recently been working to create a unified direction for all its data products, which would (if successful) pull through higher-margin WAN products into the enterprise space, and also promote its products to carriers.

Nortel is primarily a carrier WAN player, with some enterprise successes to throw in. They have an enterprise data group, recently formed, to which Bay will be added and which Bay CEO House will lead. There has not been any strong indication that the Nortel carrier and data people are on the same wavelength.

Our big concern about the merger is that Bay's strengths are in a part of the data market where Nortel has no particular record of success. The LAN market is becoming a channel marketing play, and Lucent was in fact one of Bay's channels. Can Nortel replace Lucent's contribution to Bay's sales? Can Nortel even run an enterprise organization? If House departs, the whole thing could fall apart.

We believe that Bay's willingness to sell out in the summer of 1998, before Lucent's restrictions on asset pooling would have likely made it a suitor, suggest that the firm did not believe it could sustain a strong profit record in the next couple of quarters. Bay management clearly also believed that the company could not remain strong in the future.

The most compelling thing the Bay acquisition suggests is that the entire second tier of the vendor space in the data marketplace isn't viable in an independent sense. Cisco, Nortel, and Lucent are the first tier. The second tier was led by Bay, and also includes 3Com, Ascend, Newbridge, and Cabletron. These firms are too big to be niche players, and the Bay acquisition suggests that even the best of those players wasn't good enough. At the low end of that tier, and thus possibly survivable as a niche player, are Xylan, GDC, and Fore.

For all the remaining second-tier players, the choices are:

• Shrink down to a niche player, small enough to be viable in market areas the big guys won't pursue too aggressively. Nobody seems to get little willingly, so we're of the view that this strategy happens by accident to some who try for other options (for others who try, the result is death).
• Pull off a near-miraculous repositioning into some new market area, one with enough revenue potential to permit continued growth. Frankly, we don't know of any.
• Get bought out. The Nortel acquisition will probably stimulate Lucent, Ericsson, Alcatel, Fujitsu, Samsung, and others to consider buying a second-tier firm.
• Merge with one or more of the second-tier remainder to try to put something massive together.
• Die off.

In our view, the greatest pressure will fall on the firms who have no strong WAN position, because WAN products are commanding better profit margins. Thus, Cabletron and 3Com are two firms to watch closely. 3Com has good distribution channels, but would have to endure at least three to five quarters of slow progress before lower LAN prices kick in true volume growth. Cabletron has no clear future options we can see.

Some kind of partnership or merger among these players (our fourth option of this section) would seem a logical step. 3Com and Newbridge had a marketing alliance for the Newbridge Carrier Scale Internetworking (CSI) activity, but that never seemed to get started, and CSI now seems positioned suicidally against MPLS. Making this relationship more than paper, or creating other merger combinations from among the second tier, will probably get considered by the players only when it's too late.

The players with more options are Ascend (the best candidate of the lot), Newbridge, Xylan, and Fore. Because all these vendors are potentially strong WAN plays (even Xylan, whose switches are forming the basis for some carrier transparent LAN services), all of them could sustain themselves long enough to either cut a good deal with a partner, or even build a better market niche that would sustain future growth.

But the only "niche play" that has any chance of developing into a really big market is the MPLS-dependent IP VPN market opportunity, with over $300 billion in total worldwide sales potential over the next 8 years. Only Ascend, of the WAN-oriented second tier, has any recognized and credible MPLS position, and even Ascend hasn't been able to really make that position appealing to the media.

The next year will tell the tale. It's likely that we'll see some major changes in this group of vendors (and their ownership) by then.

The big question now is who would buy a second-tier player, and for what reason. There are a number of scenarios that can be played out, but Lucent and the offshore telephone competitors figure in them all.

One obvious thing that could happen is for Lucent to counter the Nortel move by buying an enterprise player out of the second tier. Cabletron, whose products are distributed by Nortel, is mentioned as a possibility—there'd be a kind of irony to each of the big US telecom players buying each other's data partners. Ironic, but dumb in our view. If Lucent wanted a LAN player, it would seem they'd have encouraged Bay to hold out till the fall, when they could bid. Then again, we're trying to be logical here.

A better buy option for Lucent would be Ascend. Lucent could then suddenly be an incumbent in nearly every RBOC frame/cell network, a player in the ATM/IP market, and a real threat to Cisco's growth. Can Lucent cast off its "Not Invented Here" shackles and make this move? Frankly, we don't know.

There are already other people looking hard at Ascend, including (so it is rumored) Ericsson and Alcatel. The former is in particular need given the fact that its alliance with Bay and GDC on MPLS is likely to founder on the acquisition of Bay by Nortel.

Siemens is also said to be gunning for a partner, and there are rumors it would like to both buy Newbridge and buy Cabletron or 3Com. This would make more sense than some of the other acquisitions, but Siemens has never been strong in the US data market, and there is serious doubt whether the Teutonic mindset would adapt to the somewhat disorderly US marketplace.

In our view, an acquisition of second-tier players by either Ericsson or Alcatel could create a viable data player. It's possible that the complex Siemens multi-question might do the same. Lucent/Ascend would be a killer deal. The rest of the combinations would be unlikely to create any real market change.

The real risk here is for the major players. Cisco has yet to make a real transition to carrier-dominated data services, and so is vulnerable to successful exploitation of the carrier base (particularly the RBOCs) Nortel and Lucent. Real success by either one would make Cisco a perpetual also-ran.

Lucent has to see the Nortel move as pivotal. If they counter the move by trying to enter the LAN/enterprise market in greater strength, they'll be setting up a kind of phony war between themselves in an inconsequential space—the WAN market is going to the carriers in the long run. Failure in this phony war would be treated as failure, period, and would probably discredit the failed player overall. Thus, by fighting a battle with Nortel here, Lucent could lose a lot and probably not gain much even by winning.

The big risk for Nortel has already been taken. It's ominous that they announced a proprietary IP-over-ATM strategy recently, having just acquired Bay (whose MPLS announcement was the first from a big player). Not only does that take some heat off arch-competitor Newbridge, it seems to show that Nortel is determined to have its own view prevail in the IP market, which would be a disaster.

Stay tuned; more interesting things are coming.

Many technology advancements are driven by vendors who want to change the status quo. In the IP space, there is no more eager group than the ATM vendors, whose dreams of gigabucks arising from wholesale conversion of networking to ATM have been dashed in the late 1990s. In this last of our MPLS features, we're going to examine how MPLS relates to virtual circuit technology in general, and to ATM in particular.

One of the properties of label-linked MPLS routes is that they can be readily mapped to virtual circuits. In fact, that capability may prove to be one of the most important aspects of MPLS design.

There are two models one could presume for MPLS in a virtual circuit environment. One model says that the virtual circuit network appears as a kind of "MPLS black box" that exhibits MPLS properties at the edge, but not necessarily internally. The other is the more formalized MPLS model, in which virtual circuit devices exhibit uniform MPLS properties throughout the network.

The black box model of MPLS is the most generalized for vendors and users, but provides less assurance of multi-vendor interoperability. In this model, a network of virtual circuit devices is created using whatever topology and routing architecture the vendor finds convenient. At the edge, the network presents an MPLS interface and responds to MPLS LDP messages and labeled packets as though the network were a distributed MPLS node. The network may (and probably will) also present router functionality at the edge, accepting and generating topology updates using a protocol like RIP or OSPF. The "view" of itself it presents to those protocols is that of a single, multi-connected, device.

The formalized MPLS model of virtual circuit networking with MPLS requires that the virtual circuit nodes be MPLS-capable, and also be routing-capable to the extent that some model of route determination must be developed to provide steering of the LDP messages that create the label-linked routes. Since it is unlikely that the route-threading process will span only the virtual circuit portion of the network, it is likely that the route determination architecture of the virtual circuit network would have to be the same as that of the rest of the MPLS network.

Black-box MPLS, because it is based on ATM networking inside the vendor's cloud of devices, tends to retain a lot of connection-oriented properties. Both Ascend and Nortel, who have VPN-over-ATM strategies that could be (at least in Ascend's case) mapped to MPLS, create a kind of IP layer around a virtual circuit network core. This makes their VPNs behave like frame relay networks with router features added (which happens to be how buyers want VPNs to behave).

Formalized MPLS networks, because they make each ATM node behave like a router, tend to create VPNs that look more like router VPNs. We must note that this tendency isn't institutionalized in the design, just preferenced in the orientation.

In the black box virtual circuit model of MPLS, the first step is to establish the virtual circuit network as a virtual router for those protocols that MPLS will explicitly use (for LDP threading of routes, for example, or for reconnect or route gateway functions). We've talked about MPLS topology management and routing before, so all we need say here is that something has to route the "MPLS-equivalent virtual circuits" inside the black box of the network. It can be MPLS-related (as Ascend's IP Navigator), totally ATM-centric (PNNI) or something in between.

Whatever the strategy for route management and route determination, the process of threading an MPLS route through a black box implementation would be similar:

1. The LDP message would arrive at the black box edge node as a normal LDP message. If there is a route stack associated with it, a black box network would appear as a single node/entry in that stack.
2. The edge node would pop its entry off the stack (if necessary) and determine the edge node at which it supports the thread's next hop, either through stack processing or through address lookup.
3. The edge node would invoke an internal route threading (set up a virtual circuit) to that destination point, and forward the LDP message over it to that point. The internal identifier of this VC would be equated to the incoming label in a table at the source edge node, and to the destination label at the exit node, connecting the internal route thread to the external flow.
4. The exit edge point would emit the LDP message to its correct MPLS neighbor, using the exit label.

The only place where there's variability of function here is the middle. How the edge node knows the reachability of its neighbors is dependent on the topology approach taken in the black box network. Likewise, how the virtual circuit is set up and threaded depends on the connection and routing architecture of the black box network.

Processing a labeled packet is straightforward once a route has been established:

1. The labeled packet arrives at an MPLS source edge node, bearing an incoming label.
2. The source edge node would look the incoming label up in its table to identify the virtual circuit to which the label-linked route is associated.
3. The labeled packet would be shunted onto the indicated virtual circuit to the exit edge node.
4. At the exit edge node, the incoming label would be looked up on the exit label table. It would then be replaced by the exit label, and the packet forwarded according to MPLS exit rules.

Note that in this model, there is no structural linkage between a virtual circuit ID and an MPLS route label. The correlation is maintained in the edge nodes of the black box network. There is also no requirement that any discipline in particular be used to create the virtual circuit. This contrasts with the next option, the formalized MPLS integration with virtual circuit networks.

In general, we expect switch vendors to adopt a "black box" MPLS model. This is due in part to the fact that most will have routing and topology management functions already in place, designed for virtual circuit routing. Often these will provide better QoS-based routing than could be obtained by using a per-node MPLS formalism based on IP metrics. Another factor is the likelihood that switch vendors would want to differentiate themselves based on MPLS support features, something difficult to do if everyone slavishly adopts the same set of standards. Finally, switches (unlike routers) are not popularly expected to be box-by-box interoperable with one another; no X.25, frame, or ATM products are today, and no standards exist for interoperation at this level.

MPLS documents indicate that the VC ID of frame relay or ATM can be used as a label. This means that the MPLS procedures operate in every frame/cell node in parallel with or in place of standard frame/cell routing procedures. The process of call setup is displaced by the process of label-linked route setup, and the process of VC switching becomes the process of label switching.

To make this process work, the ATM or frame switch must first "watch" a particular VC for administrative traffic. This channel would be used to propagate the LDP message sets, to eliminate the need for the switch to examine the contents of transit label-linked routes.

An LDP threading process would have to work pretty much the same here as for an individual MPLS node. The "label", however, would be the VPI/VCI or DLCI of the frame or cell, so there would be no need to prepend an encapsulation header to contain it.

It is highly doubtful that virtual circuit identification based on globally significant VC identifiers would be useful with MPLS, given the fact that the number of label-linked routes that could be expected in a network could be massive. The next question would be whether the VCID would have to be node-significant, or could be assigned on a port basis.

As far as can be determined based on current documents, MPLS expects labels to be unique for a given node, though this assumption doesn't appear to be rooted in any specific requirement. Thus, it would appear that there are two ways the VCID could be handled:

1. An MPLS VC device could assign labels globally, meaning that the VCID address space would have to contain the total number of routes that pass through the node. This might be practical with ATM, which has a larger address space, but is not likely to work with frame relay, which is limited to less than a thousand VCIDs.
2. An MPLS VC device could assign a label exactly as it assigns a VCID now, meaning within a port. This would mean that the source port number would have to be concatenated with the VCID to create a unique label for lookup on a common label table, or that the label table would have to be maintained by port.

Logic seems to favor the latter approach, but it isn't completely clear whether abandoning the concept of a node-unique label is completely safe. Certainly, a label assigned by node/trunk more closely follows virtual circuit assignment practices today, and would likely be more compatible with current equipment design as a result.

Three issues appear to arise in any implementation of MPLS integrated with virtual circuit devices:

• How will the implementation handle VC merge procedures?
• How will the implementation handle multicast?
• Will the implementation support "default routing", meaning the handling of packets through normal routing table functions, not MPLS label switch procedures?

VC merge is a challenge for any ATM-based MPLS implementation because the normal model of ATM data encapsulation (AAL5) doesn't support merging the cell streams of two unlike information sources and recovering the original packets intact. It lacks a message/cell sequence number, for one thing, and for another, such a number would be useful only if we could assume that disparate sources could be expected to come up with message numbers that would be unique.

We should note that there is no necessary connection between VC merge and frame relay or ATM. In theory, any MPLS node could offer VC merge, but since the only thing that would be conserved in a non-frame/cell device is the number of labels, it isn't clear whether there is any benefit. The MPLS spec does call for VC merge in a generic sense, however, and most MPLS devices will probably offer it.

An alternative to a packet black box for VC merge in ATM networks is the use of virtual paths to aggregate routes. In this approach, a node sources a VP to each destination node. When label-linked routes merge at a node, the VCs are merged onto the VP that is associated with the destination. This process can create problems if the number of destination nodes are high, however.

Packet-merge black boxes may be necessary in any case. As it happens, the issue of multicasting also creates a potential packet-handling requirement. If MPLS is to support multicasting, it must replicate packets at each fork in the multicast tree, putting a copy on each outbound path. This could be done through normal VC point-to-multipoint procedures, but special management of the trees would be required.

The last issue, the handling of packets using standard Level 3 procedures, may also argue for packet-aware components in virtual circuit devices. That label route threading may be dependent on IP routing tables is a truth previously noted. It is also true that IP routing will be required to link an MPLS fabric of routes to a connectionless DMARK supporting a non-MPLS end user. Finally, it is likely that best-efforts IP services would be provided using standard IP routing even in a network with MPLS support available throughout.

As we've noted before, packet awareness in the last sense covered here could be provided either by making each node MPLS-packet-IP aware, or by creating a black box network that appeared as a virtual MPLS node. The other strategies, however, would require some explicit packet awareness in each ATM or frame relay node in order to be supported effectively. In the balance, we believe it is safe to assume that some form of IP awareness will be added to all frame/cell networks, and that a portion of this will probably be distributed to each node.

Nothing reflects the schism in MPLS viewpoint as much as the relationship between MPLS and ATM. Many will criticize vendors like Ascend who elect the black box strategy—"non-standard" is a label the press loves to apply to things—but there is good reason for ATM players to take this route. The IETF appears determined to promote the traffic management view of MPLS, and that view would compromise the service value-add that MPLS could bring. Since that service value-add is the key value proposition for adding ATM to IP networks, ATM vendors can't afford to let router-heads take it away.

The battle for the hearts and minds of the marketplace will start here, with the ATM/MPLS boundary. New players will find this the most attractive place to launch products, and older players will find it the border of their kingdom and thus the frontier to be defended.

Nobody's doing a great job of offense or defense yet, but we expect to see some changes over the summer, and certainly by the fall trade show cycle.

The market moves in hype cycles, as all our readers know, and one of the cycles that's underway today is the "SS7 support" cycle. Established vendors and startups alike are hunkering down on this venerable telephone protocol and looking for media and market validation.

One might think from the activity so far that "SS7" was a concrete and well-bounded feature set, so the term would carry an unambiguous promise of some sort. In fact, SS7 is a jumble of things supporting a host of missions, and the vendor announcements we've been reading may in fact be targeted at completely divergent market areas.

SS7 goes on terminal servers to support offloading Internet calls, right? No, it's a protocol needed for voice over IP. Wrong again, it's something CLECs will need in their voice switches. Or is it necessary for ATM networks of the future? We'll try to unravel the diverse SS7 strategies here.

SS7 was, no surprise, a successor to SS6, the low-speed telephone call signaling protocol that developed in the 1970s and was used for call completion in the voice network worldwide. The problem with the old system was performance and stability in the increasingly intelligent switching networks of the industrial world. SS7 solved that problem by creating an architected signaling network alongside the phone network.

In today's voice networks, SS7 creates a kind of subnetwork, with each network switch and intelligent component a "user", and with "Signaling Transfer Points" or STPs as nodes. This architecture is sometimes called "SS7", but it is more rightfully the Intelligent Network architecture (called "Advanced Intelligent Network", or AIN, by Bellcore in the US).

The protocol we call SS7 is modeled rather roughly along OSI lines. The Message Transfer Part (MTP) and Signaling Connection Control Part (SCCP) provide in combination what could roughly be called OSI Levels 1 through 4. Connection-oriented and connectionless services are provided here, and all of the other "parts" are "User Parts" or consumers of these services.

The User Parts of SS7 provide the interface for basic call signaling for analog, mobile phone, ISDN, and B-ISDN calls. These interface to the MTP and/or the SCCP for services.

Intelligent Network interchanges not directly associated with call handling are interfaced through a Transaction Capabilities Application Part (TCAP). TCAP provides a kind of session management function to control relationships among IN entities, though it is not considered an OSI Session Layer (Level 5) function.

What all this provides is a communications stack, and that's one source of the ambiguity with respect to SS7 support. To say one supports SS7 is to say that one's computer supports a protocol. So what does it do with that protocol? That's the obvious question, and the question that a simple statement of SS7 support doesn't answer.

SS7 is used to signal phone connections and build telephone applications. In both modes, there is a presumed set of SS7 signaling users ("Signaling Points" or SPs), and these users have specific missions in the service(s) being provided. For example, SS7 is used in 800 service to signal between a carrier switching office and a Service Control Point to ask that the 800 number be decoded to the "real" number to which it is mapped, so the call can be routed. This is a TCAP service. In Custom Local Access Special Services (CLASS) features like Automatic Callback and Calling Number Delivery, TCAP may again be used, but the basic call signaling features of the Telephone User Part or ISDN User Part are also used.

Vendors usually support SS7 applications by licensing or OEMing some SS7 software or platforms. Trillium, known for having software for every purpose, has a full-ranging SS7 software set and also fault-tolerant system support. HP and Compaq also have system/software platforms with SS7 capability. One of these sources usually provides the foundation components of vendor SS7 capabilities.

Ascend is a good example of this. The company's recently announced "Ascend Signaling Gateway" is based on the HP "Open Call" platform for SS7, and provides MTP and ISUP (ISDN User Part) signaling between the gateway and the SS7 network. An enhanced form of Q.931 is then used to signal between the gateway and the MAX TNT RAS to provide some special options in Internet call termination.

Internet call termination is probably the first and best-known example of SS7 capabilities added to non-telephony devices. In standard Internet service, the ISP buys user trunks (T1/PRI, usually) and pays a standard user charge for these. No special signaling support is required beyond the normal modem answer or ISDN capabilities associated with remote access.

SS7 features allow an ISP to appear to the voice network as a local Class 5 central office switch. Instead of buying a PRI, the ISP gets interoffice trunks (usually for nothing, as part of an interconnect). Furthermore, the ISP is entitled (at least under current interpretations of the law) to something called "reciprocal compensation" or "mutual compensation" for each call-minute originated on the incumbent LEC and terminating on the ISP's pseudo-office. To get this treatment, the ISP must file for CLEC status (called by some "passive CLEC" because the ISP doesn't intend to originate calls at all) and support the SS7 ISUP signaling used between COs.

Obviously, the calling features required of a passive CLEC are minimal—pick up the phone, refuse a call because of facilities busy conditions, or maybe forward a call to another point. If the equipment vendor has more ambitious applications in mind, other features will be required.

A gateway between IP and the public network, or between ATM and the public network, would have to emulate a broader range of phone services. If the gateway had to provide end-user calling features like calling line ID or call waiting (CLASS features), then the SS7 gateway would have to emulate a full Class 5 end-office switch. If the gateway was supposed to provide IP-based toll (long-distance) services, Class 4 (tandem/toll) features would be required.

Because SS7 is a common-channel signaling protocol, all signaling between two entities is carried on a separate connection independent of the information flows. This allows vendors to build SS7 boxes that are separate devices from their primary equipment, as long as there's a way to get the signaling channel into that separate box and provide the signaling coordination between that box and the vendor gear.

Again, Ascend's ASG is a good example. The SS7 connection terminates on the HO Open Call box, while the calls terminate on the MAX TNT. The special Q.931 augmented signaling connection between the Open Call adjunct and the MAX TNT provides the latter with the information it needs (like which DS0 an incoming call is on).

The Ascend approach to SS7 is typical of the data vendors, and suitable to the passive CLEC role. All of the RAS players, from Ascend through Lucent/Livingston, to US Robotics/3Com, are certain to take an IP gateway approach that is dominated by near-term features for passive CLEC applications.

Key to the success of the adjunct approach is the segregation of SS7 processing from the interfaces used to transport information. A gateway product is really a duo; an SS7 adjunct and a main-path gateway that supports the information interface—usually to both the telephone network and to some specialized network like IP or ATM. The implication is that the adjunct isn't in the data path, and that's consistent with SS7 principles, under most situations.

Two situations may make independent SS7 processors a problem:

• The application requires active information conversion be performed at the gateway, as well as signal conversion. For example, if voice must be compressed and packetized, the gateway product would have to sit on the call path to provide this.
• The application uses in-band or per-interface signaling (analog DTMF or BRI D channel, for example), and the signaling needs to be injected into specific ports in conjunction with associated call or data streams.

Voice over IP or fax over IP could fall into this problem class, unless the main-path gateway we talked about had fax conversion and voice compression features on its port interfaces. If it had, there would be no need for the SS7 gateway to provide any additional information conversion.

But that's about the end of the simple stuff. The ATM switch vendors and router vendors will have to address the more complex issue of how SS7 plays in the linkage of non-POTS transport technology with telephony in general. A migration of today's network from switches, DACSs, and TDM to ATM or IP backbones would require that the backbone first look like a toll network built of Class 4s, and later perhaps as a full Class 5 network.

With either ATM or IP "tandem networks", the key issue is the features provided by the ATM voice cards or the IP voice interface. If voice compression is offered, and if a special signaling channel can be used to control an entire trunk's worth of DS0s, the same SS7 adjunct approach used by vendors like Ascend would work. That, in fact, is what Ascend appears to be planning to do in its extensions to the ASG product to support voice calling, etc.

In all likelihood, the ATM and IP voice gateways would have to be designed especially for this kind of application, and tuned to work in conjunction with the SS7 adjunct via a custom protocol (again, Ascend's Q.931+ approach is an example). All of the voice ports that made up the carrier trunk associated with a given SS7 partner would have to be synchronized in a signal handling sense to slave off the SS7 adjunct processor that supported the signal connection to that partner.

There are other approaches, obviously. Voice vendors, including Summa Four, provide a more switch-centric solution (since they make switches). The fact that these products are telephone switches alters not only their SS7 strategy but also their market positioning.

For switch vendors, it's necessary to emphasize call handling, and so these vendors tend to adopt the "active CLEC" model, where an ISP provides voice telephony services as a part of an integrated service offering, and requires not only the ability to terminate ILEC data calls on the RAS, but also the ability to manage calls among the ISP's subscribers, and calls from that base outward into the ILEC or IXC world.

This creates a more stringent SS7 requirement, usually one with something approaching full Class 5 features. It has also generally meant that the vendors have integrated their SS7 handling into their product or created a customized and tightly coupled adjunct.

The switch vendors also often provide features to customize their SS7 implementation, including APIs and even message gateways between SS7 and other more conventional data architectures, like TCP/IP. This flexibility is necessary because many switch vendors go after customized elements of the AIN market, which often uses switches to front-end things like voice-mail systems.

The most generalized approach would be to take as an input both the DS0s associated with a telephone network partner switch and the SS7 channel that supported that relationship, and process both data and signaling as the application requires. So far, none of the SS7 approaches have been conceptualized as SS7 products from the ground up, so this general approach is yet to be taken. Such a product would have to be very flexible in the SS7 sense, meaning it could take on any of the User Part or AIN identities freely. It would also have to provide options for the format conversion associated with call handling on multi-structured transport networks like telephony/ATM/IP. In all, a sophisticated and modular product would be required.

It's likely that the passive CLEC role won't last forever. Reciprocal compensation was really intended to encourage local exchange competition, not subsidize ISPs. Simply filing for CLEC status may not qualify somebody for reciprocal comp in the future. In addition, there are some who believe that Internet calls, intended as they are to provide access to out-of-area resources, aren't local calls at all and thus aren't subject to the reciprocal comp rules. A Texas arbitrator ruled that way earlier this year, but the full Texas PUC overruled it. They did say they'd plan to revisit the issue of the value of the reciprocal comp, though.

If the passive CLEC role phases out, the ISPs will need to offer real voice services in order to consume SS7 gateway products of any sort. Thus, the products will all start to evolve into a real voice direction. It may start with VoIP, but we think that won't last, and the ISPs will really have to offer interconnect of circuit-mode voice with the ILEC and with IXCs. That would suggest that the products now targeted at making RASs look like Class 5 switches won't be sufficient in the future.

Whether the SS7 implementations of the future will be based on voice switch products, or on a completely new class of product targeted at the specific SS7 mission will be decided only when the full range of vendor offerings has appeared. With all the changes in this space, convergence may take a year or more, so we'll keep you posted on developments.

Our next issue will talk about DWDM's role in the future of networking, and also the concept of "VPNOSSs" for future data networks.

We're collecting MPLS information from various vendors now, and we plan to incorporate this in our carrier-scale ATM switch review later this year. We'll also provide some information on non-ATM-switch MPLS plays.

CIMI Corporation will be publishing an extensive VPN/MPLS white paper covering all aspects of the VPN market opportunity and the critical role that MPLS will play. We expect this will be available in August. Contact us for preliminary information.

Access the index of CIMI Corporation's recent newsletters.