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

For reasons of space, no Management Briefing segment is being provided this month.  Subscribers will be reading two vendor responses to our VPN architecture proposals in the Strategies section.  That section is not available for Internet viewing.

In the Know

The general conception of the network of the future (meaning the one normally published) is of a network that is very “Internet-like”, meaning one based on Internet IP routing principles.  While this kind of network is very different from the model of the PSTN today, it’s at least a network whose framework is familiar to most.

The real network of the future, given the SBC and Bell Atlantic commitments we discussed in last month’s issue, is going to be very different.  In fact, the model of that future network may resemble the ITU’s model for the Global Information Infrastructure (GII) that we discussed in the October, 1998, issue (for those who were a subscriber then; this issue is also on the Internet).  ATM will serve as at least the access foundation of that network, and it will therefore also probably play a role in the transport (or interexchange) networks—at least in the near term.

Even those who believe in ATM today probably don’t believe in the vision of ATM as a service architecture.  We won’t have applications written to an ATM API, and we won’t even see any huge number of ATM-capable CPE devices (though we’ll probably see more than we do today).  This means that the services of today and of tomorrow must be created off this new network.  If we suppose that the transport or long-haul networks won’t necessarily be ATM-centric, we must also create some bridge between ATM and those transport networks that don’t adopt ATM.  In short, we’ve got a problem here.

The problem that our notion of ATM access creates is only one of the problems we have, as it happens.  Optical technology is deploying in larger amounts in the core and even in metro applications.  Since we don’t sell photons to users (even fiber-based ones demand an electrical payload), we must assume that there will be some overlay structure to the fiber to present a more service-like capability set.  Do we do ATM over fiber, or IP, or packets?  Do we frame fiber with SONET before we apply the payload (packet-over-SONET) or do we simply squirt packets over the fiber/electrical structure (“packet-over-photon”)?

Whatever the answer to this question may be, there’s also the question of what happens when DWDM enters the picture.  The Sycamore vision of a wave-switched network where virtual optical paths are created by binding traffic across fibers using lambda-level cross-connect introduces a style of optical networking that differs substantially from the point-to-point optics of the SONET age.  Notwithstanding the content of the lambdas, we still must consider how that lambda structure impacts networking at large, especially since we probably must expect that wave-switched fiber-to-fiber linkage won’t add much service intelligence due to the requirement to minimize handling.  When we eventually move to photonic switching between fiber strands, electrical processing will move from minimal to impossible.

Over time, we’ll need to consider all of these issues (and, of course, we will).  In the near term, it’s necessary that we lay out a framework of assumptions and topics to guide that consideration.  That’s the purpose of this section.

My Bits and Yours

Networks are a collective function, a service framework that achieves communication through the support of an inclusive membership strategy.  Your bits and mine share a network and move therein, which implies the service of transport.  Given common membership, a presumptive service of that network is the ability for us to exchange bits.  To do this, we must add to the simple transport mission of networking a facility to address users or end-points, and to route information based on the address system we choose.  Transport and routing.

The transport function of networking must address the question of cost efficiency.  One way to make it possible for users to communicate is to provide each user with a pipeline to each other user.  The arguments against this simple and elegant solution are grounded in economics and not in technology.  Because bandwidth isn’t free, we have to economize.  We therefore aggregate traffic to secure both transport economy of scale (big pipes have a lower unit cost of transport) and transport efficiency (packing bursty traffic onto a common trunk lets the peaks of one flow fill in the valleys of another, increasing the total utilization and thus constraining cost).

Aggregation implies convergence of traffic, hierarchical structuring of network elements.  Edges feed concentrators, which feed another layer of concentrators, and so forth through to the core of the network, from which the mirror structure diverges traffic to other edge points.  The need for addressing information is created by the fact that the user-to-user flow, having been aggregated for efficiency, must now be dispersed to the rightful destinations.  An address is a guide through the paths and layers from input to exit.

We have two strategies for the reconciliation of the aggregation and addressing missions represented in networks today.  One, the “switching” approach, lets communicating pairs of users establish paths between them (like those infinite user-to-user meshings) when the need exists.  In effect, they deal with the impracticality of our full mesh of network members by eliminating the paths between members who aren’t communicating.  Since most pairs of users won’t be communicating (now or ever), that makes the process more scalable.

In switched networks (connection-oriented networks is another term), the path is built to carry the data, which means that the association between data and path made at the entry point is all it takes to carry the data to the exit.  Aggregation simply combines a bunch of paths onto a common physical circuit, with each path retaining a logical independence of the others.  Put in frame relay terms, I assign a DLCI to a packet and inject it onto the network.  A series of nodes relates inbound DLCI and circuit to outbound DLCI and circuit, and the data is switched through without reference to content.  The set of in-out port/DLCI associations are built during the connection setup phase, where destination address is used to select the path that data will ultimately follow.

The other approach to networking, “routing”, takes a kind of opposite approach.  Instead of establishing paths which permit transport without content reference, and which use addressing only during the setup phase, routing assigns the destination address to each data element.  During the process of concentration, data elements from all manner of conversations are intermingled, and so at each point of route diversity (each point where there is more than one possible exit path), we must re-examine the address of each packet to determine where it’s supposed to go.

A point to make here is that the whole process, whichever mode of operation I pick, is justified by the need to aggregate and address.  Addressing is a kind of baseline requirement to support delivery, so we could say that the connection-mode wars arise out of the need to aggregate traffic.

Services

Sending something to somebody is nice, perhaps.  Nice, providing that they want something from you, that they are ready for it, that they know what it is, and so forth.  In other words, communication is valuable in the context of need, or the willingness to accept as a benefit the result of the communication.  A service, then, can be seen as a mechanism for establishing and maintaining a communications context.  A service effectively divides a “network” into a series of communities who agree on a given set of information exchange rules, and then lets them arbitrate their exchange of information based on their rule set.  In voice telephony, we establish a mode of communication (speech, or “noise” in an analog sound sense), an addressing strategy (the North American Numbering Plan), and a set of arcane buzzes, whirrs, and clicks that represent progress indicators.  Everybody knows the rules of this service, and thus everyone can consume it.  Create a new service rule set (the Internet), and you create another thing that people can consume.

If there’s only one service, we don’t have to worry much about network flexibility.  If there are multiple services, multiple networks might be an answer.  The problem is similar to the problem of the every-human-to-every-other path meshing; it’s efficiency.  Using a single network to support every service is more efficient (meaning, economical).

Well, a common network can support multiple services only if each of their rule sets can be created on the common network, or can be reconciled to a common rule set.  The IP or ATM bigots each propose the latter approach; creating an ATM or IP network and force-feeding all the service options into a set of rules compatible with the baseline rules of ATM or IP.  The multi-service proponents would say that the better approach would be to dumb down the features of the network to a minimal level and provide service-specific features or capabilities outside the transport plane.  If there’s any logic to the “dumb network” versus “smart network” debate, this is the substance of that logic.  We can’t have dumb networks in the sense of their interface to the customer, because service intelligence is what makes services consumable.  We can have a debate on how we get services.

Some Models

A service model would have to deal with three different issues; what the buyer wants, what the government wants, and what technology has to offer.  Where any one or more of these issues doesn’t apply, the remainder will set the market tone.

In the local exchange, regulatory policy and business practices have combined to create a clear preference for ATM.  While there will be millions who will argue the decision to deploy ATM on all manner of grounds, it’s a useless argument.  Regulatory/business interplay dominates the local exchange infrastructure decision, as the byplay that followed the Telecom Act has shown.

In the long-haul network, things aren’t as regulatory-obsessed.  The question, then, is how much the local exchange decision to move to ATM will impact long-haul networking.

One model, where the influence is great, can be called the “In-for-a-penny-ATM” model.  Here, the decision of the RBOCs to deploy local exchange ATM pulls ATM through strongly at the Interexchange level.  Clearly, it would be relatively easy to interface two ATM networks together, so it follows that it would be easier to provide end-to-end customer services if the whole network were ATM, including the interexchange piece.

This logic seems attractive, but if the access network of the RBOCs is to be largely “featureless”, then it seems likely that there will be a specific service agent sitting on that network to provide service features to users.  This gadget, which we’ve called a Service Point of Presence or SPOP in the past, would then presumably be linked to the transport network.

This is important for our architecture discussion because the SPOP would likely have to reassemble packets to provide service processing, at least for those information services that had distinct packet structures.  Given this reassembly, it would be very easy to pass packets to the transport network rather than to recreate cells.

A second model is the IP model, which says that as long as new-generation, forward-thinking (sic) carriers like Qwest and Level 3 are towing the IP line in the long-haul network, there is no reason not to simply extend IP architectures from the core, over the RBOC ATM access network, to the edge.  Thus, the subscriber still has an IP experience for voice and data.

The problem with this view is that it’s not at all clear how we’d justify creating an IP overlay on ATM, which is already voice-capable, in order to support voice.  This is particularly true given the fact that the RBOCs will have to wholesale voice-over-ATM capability.

The third model is the one we think might prevail.  In this model, the RBOCs deploy ATM in the access network, and ATM dominates in the network-to-user relationship.  ATM also dominates voice service provisioning because ATM local exchange connections will be available on a wholesale basis.  But service networks, which start at the SPOP and then develop inward to the core, are deployed using service-specific technology—including IP.

Where DWDM comes into this is in its ability to support transport of parallel services on common fiber with no significant loss of cost efficiency.  With transport bits falling in price, there’s no reason to assume that we’d accept any compromises in service efficiency to gain transport efficiency, and there is no question that forcing everything onto any common protocol would result in some loss of service efficiency.

If there’s any real convergence in this model, it’s likely to be convergence toward MPLS and label switching.  An MPLS LSP can carry IP packets, ATM cells, or whatever.  MPLS also has a very simple signaling protocol for LSP setup.  MPLS, in short, would seem compatible with everything except (possibly) pure TDM transport.

Conclusion

The access network is going ATM, period.  The need to provide generalized and useful services off an ATM-based access network will force carriers to adopt a SPOP model, where service-independent access connections from subscriber to SPOP are combined with SPOP-based (or SPOP-arbitrated) features to create the services users buy.  These SPOPs will encapsulate the transport network, and will thus permit transport architectures to develop without too much influence being exerted by the ATM commitment at the edge.

We say “too much” here for a good reason; if the pace of IP-specific service revenue growth is slow, then the value of having an IP infrastructure in the core will be slow to develop.  Voice over ATM at the edge would pull through voice over ATM in the core, and only the presence of other services with strong revenue potential would prevent the core from tilting in the ATM direction.

ISPs can’t provide the IP revenue growth needed.  Not only are they not growing all that dramatically in revenue, they aren’t the builders of core infrastructure, just as they aren’t the builders of the access network.  ISPs today create overlay networks, and if the thing that they overlay their networks on turns in the ATM direction, they will have to do so as well.

Strategies

The VPN series we ran recently ended with an invitation to vendors to submit their VPN approaches for review.  We’ve had some submissions, and we’re pleased to provide the first two in this issue.  Sorry, Internet readers; this is for subscribers only!

Down the Line

Next month is our Annual Technology Forecast issue and, as usual, won’t be published on the Internet at all.  In January, we’ll resume our vendor VPN submissions.