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

Management Briefing

The explosion in interest in “metro” networking has opened a number of issues that we’ll cover this month.  For many users, the paramount issue is the question of the role of the so-called “metro network”.  Do we use metro networks to support customer access, to support interconnection between access infrastructure and service infrastructure, or to provide services?

The economic issues that relate to metro networks will be covered in the next section of this issue.  Here, we’re going to focus on the question of the services that might be credible at the metro level, and how these services might be integrated into a corporate business plan.

Voice and data have had a kind of odd diametric tension with respect to the balance of local and long-haul interest.  Voice services are dominantly local, meaning that most calls are local in nature.  Data services, in contrast, have been predominantly inter-LATA in nature.  In fact, it’s the reality that data service is “long-distance” service that has been the greatest reason for the RBOCs’ wanting to be in the long-distance market.

This “data-equals-long-haul” paradigm poses a major problem for the metro players (carrier and equipment vendor).  The profit margins on local voice calling are very low (returns on capital average less than 19%), and buyer resistance to changing local voice service is very high, so giving away margins to attract customers is a rule in the marketplace.  If there’s no credible data role for metro networks, then margins on metro would likely be too low to justify further investment.

To many, the answer is “Internet access”, but access plays are another low-return business.  When a customer buys “access to…” something, they value the “something”, and will pay relatively little for the access part.  In fact, there’s strong indication that returns on capital for access networking are less than local voice (perhaps as low as 9% under competitive pressure).

What can be done, then, to create local data services?  If we can define such services, then metro networks have a specific mission in the service domain, and that mission could be hoped to provide support for basic profit margins.  If not, we’ve got a problem.

To create a “metro data service” one must do one of two things:

1.       Define a type of data service that is explicitly local or regional in nature, either because of its technology or because of buyer attitudes.

2.       Define a way to divide a national data service into national and local components, such that the fulfillment of the local part through specialized technology (and perhaps specialized carrier relationships) would make sense.

In the first category, we can see examples of both sub-types in today’s marketplace.  Transparent LAN is a service that’s “attitude-local”, and MMDS is a “technology-local” service.  Are either credible or interesting?

Transparent LAN has been around a long time, and it’s generally successful in both the US market and in Canada, though not spectacularly so.  TLAN (as it’s sometimes called) is essentially a LAN-bridge-over-WAN service.  In theory, it can be offered in a point-to-point or multi-point form, emulating a kind of Ethernet repeater in the former case, and a bridge-connected network in the latter.  There are TLAN services for virtually all LAN types, from Token Ring to gigabit Ethernet.

Historically, one of the big problems with TLAN service has been its cost.  Although LAN bridge users (there are still a few not retired) know that a bridged network can use any WAN speed, carriers who sell TLAN have traditionally sponsored the idea that only wire-speed interconnect is true transparent LAN.  This has made TLAN a fiber-based service, and generated a relatively high cost to users.

That may change if the RBOCs deploy TLAN over their ATM access networks.  Since the new RBOC plant will be based in part on fiber remotes and in part on APON, it’s possible that the fiber TLAN cost will decline.  It’s also possible that VDSL will enable regulated service providers to offer TLAN over copper, and that unregulated players would deploy direct Ethernet or Token Ring copper from their own remotes.

For the user, TLAN service looks like an extension to the company’s Level 2 LAN.  The key issue is the mechanism used to discover the virtual topology of the LAN.  A TLAN could in theory be truly transparent, with all sites appearing to be on a common LAN.  It could also emulate a bridge, in which case it would have to support the same bridge topology protocol (spanning tree, source route, or SRT) used by the sites on the TLAN.

Security is sometimes a concern with TLAN as well, though there have been no cases of TLAN security problems reported to us by users or providers.  A TLAN architecture based on carrier switches should employ something like the IEEE 802.1q VLAN protocol, which can be used to segregate users on a switch into what are effectively independent Level 2 networks.

In theory, TLAN could be run on a national or worldwide network, as long as the bridging protocols didn’t time out.  The MMDS type of service is local for technical reasons; a range of about 35 miles is typical.  MMDS could be used in conjunction with a metro network to build a large data service zone without relying on actual customer copper or fiber loop.

What’s not yet clear about MMDS is whether the resulting network would serve customer needs in both price and performance.  An MMDS service is typically priced competitively with cable models, but offers less bandwidth (300 kbps or so) per subscriber.  It’s not super-performing, in short.  It’s also possible that MMDS may be subject to more service interruptions from atmospheric or topological/geographic factors; very large scale MMDS isn’t available yet for examination of these issues.

What’s worse about MMDS is that it really doesn’t solve the service problem.  MMDS can be a feeder to a metro network, but MMDS is only an alternative access technology.  Thus, we still have to ask what MMDS is providing access to, and usually the answer is the Internet.  Cost pressure on Internet service is already intense, so it may be that MMDS won’t provide much of a benefit to the provider in supporting service margins.

A better set of long-term strategies might be derived from the second of our two “how-to-create-metro-service” options.  If public IP services are the way of the future, couldn’t we divide these services up into metro/regional and national?  Is a hierarchy of IP necessarily bad?

To a degree, IP networks naturally support a form of regionalization, in that hierarchical deployment of routers would tend to provide a way for local and regional traffic to be shunted off from edge to edge without moving all the way down into the core.  But to a degree, IP is regional-insensitive, because IP addressing isn’t hierarchical by location.  What’s the buzz here?

It’s possible that the new-generation “service POPs” or “service switches” may provide the answer here.  Such a product could be used to create VPNs based on a variety of transport options, including an option to recognize and exploit metro services and infrastructure.

It works like this; a new-gen service gateway product classifies traffic from a given user to divide out the VPN stuff.  If a VPN partner site is in the same metro region, the service gateway’s route selection policy could recognize this and pass traffic to a metro network.  That decision would presumably be made based on whether the metro network offered better cost/performance, or QoS options, than the national network did.

A second model would be to assume that the service carrier really built a hierarchical network, meaning that the carrier built out a metro data network and handed off traffic from that network to a national network if the destination was out of area.  While that is technically feasible, it would seem economically sensible only if there were enough distinctively metro traffic flows to justify the decision.

That’ s the real question, of course.  The viability of any metro network service is dependent on the existence of those “distinctly metro” applications.  TLAN doesn’t create those applications as much as recognize that where the applications exist, a different data interface may be viable.  Do these applications exist?

In today’s market, possibly not.  The largest use of TLAN today is multi-site metro networking for companies with multiple locations within a given city or region.  Since satellite sites of multi-site businesses make up about a quarter of all sites, it would seem that metro data might depend on intra-company metro traffic as a distinct source.

In tomorrow’s market, though, the answer is “metro maybe”.  E-Commerce has exposed some applications that are intrinsically metro, particularly applications that relate to manufacturing partnerships (the auto industry, for example).  These are, to date, insufficient to create a broad metro service opportunity, but we’re still exploring the useful boundaries of e-commerce, and that may change.

A tighter cooperation between e-commerce and brick-and-mortar retail could create a major metro market, because retailers would focus on customers who could access their stores.  Virtual reality shopping augmenting real physical shopping opens major possibilities, but ones we can’t yet validate.

In the Know

The difference between an “application” of something and a “justification” for something is that “application” means that it would work, and “justification” means you’d want to make it work.  What generates the “want” part is a financial benefit.

Metro fiber would “work”, so there’s certainly an application for fiber in the metro area.  The question is whether there is a justification for considering metro fiber independently of the two applications of fiber that are clearly valid/justified—access fiber and core fiber.  To answer the question, we need to define the two fiber categories we’re trying to differentiate “metro” fiber from.

What’s a Metro?

Hopefully, that’s simple.  “Access” fiber is fiber that has one end at the customer’s location, meaning that the fiber links a user site to a piece of network equipment.  We might also want to include in the category any fiber that’s used to link outside plant concentrators with the CO.  Hence, “access” fiber is fiber placed on the customer side of the CO.  “Core” fiber is fiber that links network core devices to each other.

These definitions make the problem of metro fiber a bit more clear.  We’ve defined access fiber in a topology sense (it’s outside a specific place in the network—toward the customer), and core fiber in a connection sense—it links a specific device type.  The implications of that are made clear when we ask “OK, what’s in the CO?”  If the answer is “a core device”, then access and core fiber are everything.  If the answer is “something we elect not to call a core device”, then there may be a band of network topology (starting at the CO and moving backward toward the edge of the core) that we could call the “metro zone” of the network.

In technical terms, what goes in the CO probably could be considered a core device.  In classical telephony, the Class 5 switch is the “edge of the core”.  In the new RBOC ATM network, it would certainly be true that the ATM switches in the COs would be the edge of the core.  Is there then no example where we might talk about “metro”?

Not exactly.  We can still justify the metro concept (at least as a zone of the network, if not as a truly differentiated market segment) in three ways.

Way number one is to assume that the network that provides for interconnection of the COs is different from the remainder of the network.  In the old PSTN model, this would be hard to do, since tandem/toll connections were made (and still are) through switches that look a lot like the edge switches.  In the new ATM model, though, it might be a different story.

Most of the RBOCs are talking (if somewhat circumspectly) about having their inter-office ATM infrastructure emulate a virtual tandem switch, a Class 4.  If this is the case, then it would be true that there would be a zone of the new ATM infrastructure that would be, at least voice-wise, exhibiting a special feature set.  Switches in this zone would have to be able to participate in the virtual tandem function, while those outside it would not.

Maybe so, but this doesn’t seem to justify having different fiber networks built to connect those switches.  ATM virtual tandem products are still ATM products at the transport layer.  We have to look further.

OK, way number two of differentiating the metro market is to look to the question of what the network hands off to.  As our previous pieces on RBOC ATM infrastructure show, the access network terminates in a service point of presence (SPOP).  If the SPOP is the edge of the core network, then there is no metro zone.  If, however, we can network SPOPs to create a network of SPOPs in a region or metro area, and then hand off to a core network (or networks) at one or more points in this network, we now have a “metro network” for real.

Or do we?  Isn’t it possible that the SPOP device would look a lot like a “core device”, making the fiber connections to it “core fiber”?  Before we explore this more difficult way of justifying metro, let’s look at our last option of differentiation.

Way number three of justifying a different metro zone is to assume that there is a specialized access network targeted at a subset of the public market, and that this access network bypasses the traditional infrastructure through some or all of its scope.  In effect, we’re saying that “metro” in this case includes both access and “pseudo-core” functions associated with a specific class of customers or services.

This, in fact, is the reason we talk about metro as a different network today.  Business access is often specialized—based on SONET and fiber rather than on copper.  Further, business access often involves private line service that links user sites by connecting each site to an interexchange POP, from which a long-haul connection then completes the linkage.  This IXC  POP is the analog of the SPOP in the service discussion above.  Since there are a limited number of IXC POPs in a metro area, network concentration and routing between customer and POP might well require a different sort of technology.  As we’ve said before, it does today; digital cross-connect or SONET add-drop functions provide routing for today’s leased-line services.

Making the POP-to-SPOP connection lets us examine the metro question on a single basis.  There is a metro network, conceptually, if the technology needed to provide POP/SPOP networking is different from the technology used either in plain old customer access, or within the long-haul network.

We can take this a step further, we think.  Electrical devices all tend to consume “fiber” in the same way—as a set of point-to-point pipes.  Thus, any “interior” nodal fiber would really be core fiber if the nodes were electrical.  In short, metro means optical networking must be used.  Optical networking means DWDM.

The DWDM Connection

Ah, to the heart at last!  The only real way that we could justify the concept of metro networking would be to develop a mission for DWDM in the metro area, a mission beyond simple capacity multiplication, so that optical nodes were substituted for electrical handling.  Metro fiber justification must be based on developing a real DWDM networking proposition that works in the metro space and is simply not a slimmed-down version of a DWDM core story.

If, in a metro area, we could develop the idea that DWDM could present options not necessarily valued in the same way as they might be valued in the access network or core, then we could safely say that metro (meaning metro DWDM) was useful, and that there was a true metro market niche.

One casualty of this approach would seem to be the plethora of “metro” vendors who don’t do DWDM.  However, the majority of these players are really misclassified access vendors.  It’s difficult to draw a clean line between access and outside plant networks and metro networks, especially when the service provider doing the deployment (a CLEC, for example) might not have a central office.  Lacking that clean access-to-metro boundary point, the two structures could blur together.

There’s no easy resolution to the dilemma of variable CLEC topology, other than one that’s semantic, so we propose one of those kinds.  We’ll define a product that includes both metro and access features as an access product.  That leaves us free to consider whether DWDM (which is pretty clearly not a populist play in the access market except in the PON/APON sense) could play in the metro market.

What might then create this kind of proposition?

The Role of the Dollar

Strictly speaking, our metro network would have to begin at the away-from-the-customer edge of the access network, which might be the CO or just a remote vault or hut somewhere.  It would have to provide connectivity between these points and multiple core handoff points, to create a “routing” function that would justify not thinking of the metro network as just a part of the access concentration process.  It would have to do this using DWDM optical routing.

On the surface, this seems to enable a bunch of metro players—in fact, virtually anyone who can do lambda-to-lambda routing at a fiber junction.  But there are economic factors that could narrow the range a bit.

The big financial issue with metro networks is the lower margins that could be expected on metro services.  Metro networks are clearly at least largely (if not entirely, see the previous section) access networks, in the sense that they connect the customer to a service point.  That tends to reduce user price tolerance.  Metro services, being short-haul in nature, also tend to be price sensitive.

OK, if metro networks are price sensitive, then they’re cost sensitive.  The paramount issue in validating a “metro” offering is whether the offering could be said to deliver a substantially lower cost per user than other options.  Specifically, a metro product could be valid if it would be significantly more cost effective than an “access fiber” or “core fiber” product pressed into a similar mission.

To apply this to the optical equipment space, we could say that what would distinguish a metro product would be its ability to control costs in multiple ways.  One way would be cheaper hardware.  A second way would be strategies to increase the number of customers the network could support.  A third would be direct support for some service features (something beyond featureless lambdas as the product).

Another issue in the metro product space is the issue of “who’s the buyer?”  The ILECs could clearly be candidates for metro technology in their inter-CO application.  But they’re embarked on a packet-based (ATM) modernization.  Thus, a SONET or IP-based product wouldn’t fit their program and probably couldn’t be sold to the ILECs on a large scale.  That would shrink the product’s market to the point where it might not be viable.

We want to make it clear here that it’s not that the RBOCs absolutely couldn’t buy DWDM that didn’t have an ATM/packet overlay.  Our interpretation of the FCC rules is that what’s inside the FCC 99-238-compliant cloud is shielded.  However, if the metro fiber product is TDM or naked lambda based, the ILEC would have to add electrical technology to create a regulatory buffer.  That would run the cost up.

There is also a chance that DWDM might be employed in conjunction with high-rate SONET feeds.  As we said in a previous issue (and repeat in our next section), the RBOCs could continue to deploy TDM where they felt that it created little or no wholesale risk.  Repeated T1 doesn’t create much risk.  SONET OC-48 may not either, because it doesn’t deploy a pervasive retail service at a low cost.

Product and Revenue Issues

Cost management in the product and benefit exploitation in the market must combine properly to support metro networking.  While metro products can certainly influence either of these issues, it’s important to note that not all metro strategies incorporate customer access, and that in all cases the cost of a metro network has to be considered to include the cost of getting on it.

The most efficient way to get customer access with a metro network is to put a metro node in the customer location, which means that there’s little incremental access cost that the metro carrier must bear.  The limit to this plan is the fact that most customers today couldn’t hope to justify fiber bandwidth.  Only about 45,000 single-company sites are credible high-bandwidth consumers, even in the long term.

The average business office today consumes only about a megabit per second of access bandwidth.  While many have dreamed of business bandwidth explosions (“The Internet is driving business…”), the truth is that worker information needs tend to change only as a result of changes in business practices.  Technology may permit us to exploit networking in business, but it doesn’t demand that networking be exploited.  In fact, residential users with discretionary entertainment applications are more likely to have explosive increases in their bandwidth consumption than are business sites.

One way to address this problem has been to attempt to collectivize the smaller users through a focus on multi-tenant facilities.  A metro node could be placed in a multi-tenant building and the collective bandwidth of the entire facility would be available to justify the equipment and fiber.

While it’s true that shared tenancy makes the “average” business site more likely to be exploitable via direct metro fiber, it isn’t a slam dunk.  The cost of supporting an individual office must still be acceptable, and the average multi-tenant facility has only about 23 tenants.  If we assume that each has the “average” bandwidth consumption, their access cost is only about $6,500 per month.  That, of course, assumes that you get all of them, and that the access cost doesn’t fall too sharply with competition.  If we consider both these factors, revenue realization from an average building would drop to about $2,000 per month.

There’s also the problem that most shared-tenancy companies aren’t “average” in bandwidth cost.  Office buildings are replete with small firms who spend far less on access.  We don’t have good statistics on the distribution here, but it would appear that there may be only about 100,000 viable shared-tenancy locations to be addressed with metro fiber.  Added to the single-company sites, that could make the total metro service provider market something on the order of $3.4 billion per year, which isn’t peanuts but also isn’t an opportunity revolution in a total service market of about $200 billion.

Conclusion

We’ll say it again; we’re skeptical about the hype surrounding metro fiber, and the validity of the business case.  We believe there is a range of conditions under which a discrete metro market might be defined, and we believe that there may even be a vendor coming along that would meet those conditions.  What still must be determined is whether the service opportunity would permit a large deployment of equipment in this space.

We also need to continue to examine the role of the so-called “metro” network and the related role of fiber access.  For example, even though the value of access DWDM might be limited to PON/APON, could a metro network be used to collect APON feeds?  Similarly, the relationship between metro and core could be examined; might a metro lambda be handed off to the core?  The combination of both these points, which would create a kind of end-to-end lambda, is a fantasy of some of the media, but even fantasies sometimes come true eventually.

Over the summer, we expect to be able to discuss some specific vendor offerings in the “metro” space, either in groups or individually, to assess their value.  We’ve got to say that we’re very skeptical that there is broad support for the existence of a metro fiber market discrete from the ordinary access and core markets, and we’ll be looking to prove or disprove our inclination.

Strategies

In September of 1998, the FCC offered its first response to RBOC requests for guidance on how to shield new infrastructure investment from the wholesale provisions of the Telecom Act.  In 98-188, it proposed that a fully separate subsidiary would be free to offer at least the services the RBOCs weren’t incumbents in, and that the subsidiary would be shielded from wholesale requirements for those services.

When the FCC followed up this position with its revolutionary packet-infrastructure exemption (99-238), it effectively set the structure of the RBOC of the future.  It would consist of an ILEC element that would perform the “regulated” (meaning, effectively, “subject-to-wholesale”) functions of service provisioning and fulfillment, and an “Asub” or advanced services subsidiary element that would provide the high-value service creation features for services outside the ILEC’s incumbency.

It now appears that there are some “Asubs” forming, though it seems likely that their full size and nature won’t be revealed for some time.  Thus, we can at least begin to assess how these new organizations would work—with their incumbents and with the users.  Sorry, Internet readers!  The rest of this material is for subscribers only.

Down the Line

Next month, we'll talk more about the detailed plans of BANDI and ASI, at least to the extent that they're disclosed.  Please also note that the deadline for submission of VPN responses has passed, and no further VPN submissions will be accepted.  We will publish the full PDF file of VPN responses this summer, and it will be available for downloading from our main Netwatcher page.