When you go to install a new wide-area network technology that involves the interaction of carrier trunks with your premises equipment, do you:

a) trust statements of compliance by all parties with the technology's open standards;

b) look to the carriers and equipment vendors involved to certify that each other party's specific service or gear works with theirs, or

c) do you own interoperability tests?

This question is very much alive when enterprises go to buy "SIP Trunking" services from carriers. These services essentially make VoIP full-featured for corporate on-net and off-net calling, and reduce or eliminate dedicated local and long distance trunks in favor of dynamic allocation of packetized voice streams over data networks such as MPLS real-time classes of service. To do so, SIP Trunking relies on a set of IP standards that tell carrier networks, PBXs and other gear how to interpret call set-up instructions, signaling and other commands.

But like many standards, the Session Initiation Protocol itself and the SIP Trunking methodology that derives from it can be subject to interpretation and options. That can make things dicey when you consider what it's replacing -- TDM voice trunks, often into mission-critical call centers with call-transfer feature functionality, PRIs, national enterprise dialing plans, and the like.

If anything, SIP is particularly prone to this standards-extension challenge. At one of my VoiceCon sessions on SIP trunking earlier this year, one of the panelists said he had done a word search of IETF RFC 3261, the main (though not only) SIP standards document. He found that the word "may" showed up 378 times in the document. So much for a "standard" telling everybody in the industry exactly what to do!

The decisions that each vendor makes around these SIP choices is critical to what the industry labels interoperability but really means the kind of feature transparency that enterprises must have. To bring it home to many corporate telecom managers, there are functions such as "SIP Refer" and "SIP Redirect" defined in the standard. If the implementation of these items doesn't emulate what call center managers have traditionally known as AT&T's Transfer Connect, Verizon's (previously MCI's) Take Back and Transfer, or Sprint's Agent Transfer, no amount of theoretical cost savings is going to be worth it for most enterprises.

When you go to investigate SIP Trunking and ask about this kind of interoperability, you're bound to hear about the SIPconnect certification process established since 2005 by the SIP Forum's IP PBX and Service Provider Interoperability Task Force. Any vendor's compliance with SIPconnect 1.0 or the emerging SIPconnect 1.1 guarantees a certain degree of out-of-the-box interoperability.

And certain specialized, CLEC-type carriers have built a business around SIPconnect. They go primarily to smaller businesses and tell them that their locations can probably go straight to SIP Trunking and full-featured (for them) VoIP even with a wide variety of telephone equipment, including many older TDM switches.

But for larger customers, Verizon and AT&T make a point of doing their own SIP interworking tests on IP PBXs and then publicly "certifying" specific key vendors such as Avaya, Cisco and Nortel on their flagship families of IP communications gear. They don't just rely on SIPconnect, partly because SIPconnect makes certain choices on SIP Trunking options that may not agree with some enterprise advanced features.

That's why, when you go to Verizon's page for IP Trunking Services, you'll see "fact sheets" and "solutions briefs" speaking to relationships they've established with Avaya, Nortel and others to bring SIP trunking to the market. These are really references to interoperability tests but speak to the importance attached to knowing that specific gear provides a match to a carrier's SIP Trunking implementations. (By the way, this will still be as key after Avaya completes its acquisition of Nortel, as these separate platforms remain widely deployed.) Some of these tests apparently took quite some time and a great deal of communication among the vendors away from the standards forums.

Even beyond that, the Verizon and AT&T panelists at my sessions have made the point that large customers can also come to their own labs to do their own tests. In this way, the ramp of SIP Trunking reminds me of the early days of MPLS, including in its original guise as IP-enabled frame relay, when customers felt they had to test older versions of Cisco IOS software releases to see if they would be supported over these new label-switching protocols.

Basically, the larger and more complex your organization, the more legwork is invariably involved with SIP Trunking, despite its roots as an IP standard. At some point the legwork factor will be reduced, especially if the service takes off in the marketplace, although there are plenty of signs that the major carriers would prefer to carefully manage this transition away from their traditional and profitable local trunking services. It's an arc we'll be following closely as the SIP Trunking story continues.

I'm in San Francisco for the fall version of the VoiceCon conference, which I regularly attend and speak at. Over the past two years, one topic in particular has ballooned in interest at the spring and fall VoiceCon meetings: SIP trunking. That's a service you can purchase from carriers that takes the Session Initiation Protocol now used for VoIP call set-up and other signaling functions, and rides it over specific data networking links such as MPLS or dedicated Internet.

The ultimate hope of SIP trunking is that by purchasing a certain number of ports for concurrent calls based on a study of your peak voice traffic, and having the bandwidth for your VoIP dynamically allocated across your network, you can eliminate many if not all of the elements of traditional telephony that have remained in place under more rudimentary VoIP implementations. Among these are some of the stickiest in price in an otherwise deflationary industry: local telephone trunks and PRIs.

You may still have to pay what is in effect a toll for the switched end of a call (often the origination of a call to a contact center) as part of the SIP trunking package. But other pricing parts of the separate voice-network equation drop away, typically in favor of a voice-grade class of service on the MPLS network you may have installed anyway, and the potentially very scalable concurrent-call rate element.

While the interest in the service is real -- and justified, because SIP trunking is being sold and installed by a number of carriers -- it's fascinating to note the different perception of the broad user base and the carriers as to its practical availability.

I shared a panel today with Alla Reznik, Verizon's director of Global Advanced Voice Services, in which we discussed SIP Trunking and other services with moderator Eric Krapf, editor of NoJitter.com and long-time organizer of VoiceCon. Alla has served on my own VoiceCon panels in the past on the same subject, and she is one of the most conversant people on the subject. There's no question from her presentations that Verizon sees SIP trunking as a core offering in both national and, ultimately, international rollouts of integrated voice and data networks.

But in general discussion at VoiceCon, including in other sessions, it's clear that many users feel that the major carriers are holding back on them on SIP trunking. Account teams seem reluctant to bring it up, we repeatedly hear, and the first pass at asking about availability and pricing can be rocky.

Some of this is undoubtedly because many carrier reps really don't know much about the product. But the user perception is that as the main national enterprise carriers have merged back into combined local and long distance behemoths, they've become loath to present a product that may cannibalize the local telephony trunks from the old "RBOC" sides of their business.

Our experience at TC2 on this issue of re-monopolization is that there are two very different sides of the same coin. In the case of SIP trunking, the very fact that the two largest carriers have a huge installed base of local telephony to protect can actually be turned against them, if you play your cards right.

Sure, if you talk to a single carrier, and you ask in isolation to get a service that will wind up earning that carrier less money, you are likely to get the foot-dragging type of response that has bedeviled telecom users, in one way or the other, for decades.

But we are beginning to find that SIP trunking as an additional service is one of those tools that carriers in a competitive situation can positively employ to try to win your business. Say two carriers are bidding on a national data network that also prospectively can be used for voice and video. Now add the fact that if the user does go forward with convergence using the service, the losing bidder will not only lose the "long distance" business of that company, but also the local telephony part of that company's business in their native territory.

Now the need to protect an installed base is being leveraged against both carriers. So at least one of them may have to respond -- either with a competitive VoIP service that makes the other carrier lose their "POTS" business with no compensating new business, or with a better bid on the national network itself.

Clearly, many variables go into this kind of situation. In the real world, many enterprises are not willing to give up their local trunks because of issues surrounding E911 and diversity. But for some large enterprises, the greater number and uses of local trunks, T-1 access lines to long distance POPs, and high-capacity virtual LANs and WANs from SONET to Ethernet at numerous locations gives them a lot to play with. That means that even a partial elimination of local infrastructure that used to have to go to the incumbent carrier in each territory can have a big payoff.

This keen interest in SIP trunking provides a notable example of the "Jekyll and Hyde" carrier behavior that my colleague Ben Fox has discussed in his own NoJitter article, There Is Only One Sure Way To Get The Lowest Possible Telecom Prices. In fact, it's a multiplier effect: in this case, the tension between a legacy base and a next-generation service can swing in completely different directions depending on how competitively you are presenting yourself to the carriers.

We'll be watching to see how quickly the SIP trunking trend accelerates, and how well enterprises are effectively using competitive leverage to make it go. Even though many people in the big carriers don't want to acknowledge it, the carriers' businesses is changing, and if you're in a position to force them to realize it, you're probably doing something right. Getting yourself into that kind of position is what much of telecom procurement for the long run is all about.

The issue of universal service surcharges on MPLS services seems to be in a holding mode. The major carriers don't appear to have made the decision to generally pass along to customers the current 12.3% contribution factor (for the fourth quarter of 2009) on their interstate MPLS revenues.

That's despite a somewhat more explicit signal from the Federal Communications Commission earlier this year on the USF's applicability to MPLS as a basic telecommunications service, in the form of an instruction that added MPLS as an example of a reportable service on a key form submitted by the carriers to the FCC.

But that doesn't mean that you shouldn't be taking any action about it. For starters, remember the basic contracting principle that if you want to control your destiny on an unsettled issue, you have to address it explicitly in your contract.

That's because interstate telecommunications, while not tariffed, is still under a "Service Guide" regime under which carriers post language about all kinds of issues on their websites. As a result, if you say nothing in your contract about something that becomes relevant halfway through your term, the carriers have the right to default to their Service Guide language and apply it directly to you.

So seeking an explicit waiver of USF passthroughs on the specific MPLS service you buy (such as AT&T's AVPN or Verizon's Private IP) for the period of your contract is the only way to make sure you won't be slapped with the surcharge either now or sometime during your term. And now, as it happens, a recent move by Sprint has upped the ante on this issue.

Along with the other carriers, Sprint does not yet appear to be passing along the USF contribution factor generally to its MPLS customers. But, in Sprint's standard contract form, they've slipped in a key statement discovered by LB3's regulatory attorneys. The statement reads as follows (with emphasis in italics added):

"If the Federal Communications Commission requires Sprint to contribute to the Universal Service Fund based on interstate revenues derived from services that Sprint in good faith has treated as exempt, including but not limited to, information services, Sprint will invoice Customer the CUSC for such Services beginning on the date established by the FCC as the date such Services became subject to USF contributions."

The service in question here -- the one that Sprint "in good faith" treated as exempt from USF consideration -- is clearly MPLS. And this statement apparently allows Sprint not only to start charging USF on MPLS when it determines it can get away with it competitively, but to back-charge customers based on when it considers the FCC to have (basically) mandated it. Clearly that could be the period of time when the FCC began noting MPLS as an example of a basic telecommunications service, and thus could include all of this year.

So even if you can't get a contractual promise never to charge USF on MPLS in the future, it looks like it's important to get agreement that the carrier will not apply it retroactively. The issue is not going to remain in this holding mode forever. It's an item that should remain near the top of your list for discussion.

In case you haven't noticed, the federal universal service surcharge is now 12.9%. Think about that. Any interstate rate element that gets hit with the surcharge costs almost 13% more than it would otherwise. Conversely, any interstate rate element that doesn't get the surcharge costs correspondingly less. It's a big deal, and it's gotten bigger over time.

This being so, the prospect that carriers will begin charging USF on MPLS rate elements where they never have before is a major financial issue for business users. While always latent, this threat became much more tangible earlier this year when the FCC named MPLS as an example of a service whose revenues must be included in carrier reports on revenues directly subject to the surcharge.

I say "directly" for a reason. The carriers owe 12.9% of their reported interstate telecommunications revenue to universal service, period. Technically the number is a "contribution factor" that's established once a quarter and that's applied to the carrier's applicable revenues. But the USF surcharge that you pay is a pass-along from the carriers to you that nobody in the government actually mandates.

Often this is a distinction without any practical difference. At one extreme, interstate toll voice revenues on POTS lines invariably get the pass-along, as do (often counterintuitively to people new to the industry) dedicated access lines that sit within one state but are used principally to provide access to interstate services. At the other extreme, if a carrier provides you web hosting services, the value of the service never gets reported to the FCC by the carrier, because it's nothing like the kind of straight "telecommunications" (i.e., transport) service that USF applies to, so there's no extra cost for the carrier to pass along.

But sometimes there's a service where the distinction matters, and that's where we sit with MPLS. No carrier has to pass along a USF surcharge on MPLS ports and Class of Service rate elements. And the U.S. carriers, particularly AT&T and Verizon, are still battling for new business among new MPLS accounts (or defending their incumbent positions as customers leave legacy data services for MPLS). If either bids on an MPLS network with USF charged on ports and CoS packages, it runs the risk that its competitor won't do likewise, creating a material gap in the bids right off the bat.

And that, in fact, is our experience so far. Based on a number of proposals we've seen since the FCC flagged MPLS in its reporting instructions, it's clear that neither AT&T nor Verizon has made the decision to go ahead and actually charge USF on MPLS ports and CoS, although the associated interstate access lines used to reach the carriers' POPs do include the charge.

That's the good news, but things can get interesting once you get down to specific cases. Experienced telecom managers know that account teams have minds of their own, and sometimes they actually don't understand some of the more vexing issues in the industry.

So we've seen initial drafts of proposals that do include the surcharge on ports and CoS, only to have account managers come back and say they've made a mistake and resubmit them without the surcharge. Of course, they've only done so after we or our clients have said back to them, in effect, "Really?" It's not hard to imagine that some account managers think they read or heard that USF is now mandated on MPLS and acted accordingly, without realizing the adverse competitive implications of what they were doing.

So your task as an end-user on this issue is basically to be diligent. If, as a matter of policy, carriers are holding back on imposing USF on MPLS-specific elements, you don't want to be the chump who winds up paying it first.

Active communication and comprehension is key here, too. The regulatory attorneys at LB3 remind us that these types of issues tend to operate along a continuum rather than in black and white. Even before this year's FCC reporting change that explicitly mentioned MPLS revenues, nobody was stopping the carriers from determining that MPLS was the type of transport service that fits into the USF scheme, much as frame relay was determined to be in the late 1990s after a period of exclusion. Conversely, carriers sometimes made the competitive choice not to charge USF on those very frame relay ports and PVCs if they were linked to an ATM port on the other end via frame-to-ATM interworking.

Moreover, there there is an open proceeding at the FCC to further address the MPLS USF issue, which may change the status quo in the future, so end users should keep an eye on it. Verizon, in particular, has been issuing a standard statement in its bid responses saying that the whole matter is "under review by Verizon Business and other service providers" and that it will "notify customers" if it believes the charge needs to be imposed.

Don't get me wrong: The FCC's specific listing of MPLS as a surcharge-eligible service for the carriers' USF contributions already makes it more likely that USF pass-alongs on MPLS are coming. But there's no reason to let your carrier jump the gun on instituting this surcharge on you, especially in competitive bids, just because it's a complex issue and account teams may not know how to handle it. This is one case where staying on your toes and helping your carriers understand something about their own industry is very much to your advantage.

As I write this, it takes $1.43 to buy 1 Euro, or put another way, the dollar is worth 0.69 euros. So tell me: Will the value of the dollar strengthen later this year, or weaken further?

That's okay, I don't know either.

But here's what I do know: If you have any global business, somebody in your company does care what the answer is. Or, more precisely, somebody cares whether the answer is going to have a material impact on your company's results, particularly if your stock is publicly traded.

Like the value of everything else -- stocks, bonds, real estate, oil, you name it -- the value of currencies has swung wildly and is likely to continue doing so. And if this prospect creates a material risk of variable results, then it's something that your financial shop has to make known in its disclosures.

That's why you, as a telecom professional, have to be keenly aware of the way your suppliers view this issue. I'm not talking so much about who's going to "profit" in terms of speculation about currencies going up or down. I'm talking about who's going to take the risk in the first place. Depending on how international carrier services are structured, the carrier could be taking the risk of currency fluctuation (and thus, in theory, the potential reward). Or it could be pushing the risk off on you.

Example: If you're a U.S.-based multinational corporation, and you negotiate a cost in U.S. dollars for international rate elements (such as ports and class-of-service packages for MPLS services), then you have a predictable dollar cost for the monthly recurring charge (MRC) of that element for the life of the contract. In theory, if the dollar strengthens and you could have paid the same rate element in a cheaper local currency, you could have "made money." But you don't know whether that's what your company wants. They may not want the risk of such variability, either as a matter of corporate philosophy or because of disclosure issues.

Now here's the kicker: The actual service you buy may not give you this choice, at least not easily. MPLS and its evolving platforms over the past few years, especially at AT&T, provide a great example of this.

You could pair up competing MPLS services from AT&T and Verizon Business in a competitive procurement and find that the default billers for the two are in conflict -- one wants to bill everything back to the U.S. in USD, and one wants to bill most of the foreign rate elements locally in local currency. Even odder, two MPLS service platforms at the same carrier may approach this issue from two completely opposite default billing assumptions -- you know, due to "product house" issues, as we've seen forever in the telecom industry.

Wrestling with this issue so that two competing offers you receive carry the same characteristic -- USD billing throughout or local billing in local currency wherever possible -- is a technical matter that may be subject to negotiation. But the far more important factor is what happens at the front end in your procurement planning. In our experience, currency issues are a critical, almost emotional, factor in the surrounding "baggage" that enterprises bring to the procurement process. When senior management finds that a supplier who's been down-selected cannot comply with the currency-risk requirements that they believed would be taken care of in a purchasing process, it can be one of those "oh boy" last-minute issues that scuttles a good deal, wastes all your invested time, and gives your shop a reputation for inability to move away from incumbent carriers and services. In short, a real leverage-killer.

It doesn't have to be this way. If currency matters are crucial, they should be described qualitatively and teed up quantitatively from the beginning in your RFP or other procurement process. Then, even if account teams think their default billing systems aren't geared correctly, they're the ones motivated to take the risk to "work the issue" to win the deal. When it comes to all the items that you should review with senior management at the beginning of your procurement process, this one is just about at the top of the list, so make sure to put it there.

Some enterprise network managers truly aren't interested in voice and data convergence. They might not admit it at trade show cocktail parties, but they aren't. Then again, these are the people who probably don't go to trade shows.

This position has merit. Circuit-switched voice works. Toll price-downs have been available year after year. Cost bubbles on mildly value-added services, such as reservationless teleconferencing, have been popped (only a few telecom buyers haven't gotten the word that the premium for this service is very small). Moves/adds/changes on standard telephony are manageable in many companies, despite the advantage that IP telephony provides in this area. Extended apps like call center agents in individual remote locations are cool, but not worth the risk in certain conservative corporate environments, and for reasons other than the technology.

Many telecom professionals are also very wrapped up in issues surrounding the coverage their executives will get over mobile networks nationally and globally. They don't have the time right now to worry about call (or video) quality over fixed-line voice-over-IP. We ourselves at TC2 never promote VoIP for its own sake to clients, and we encourage people to deal with rigorously tested offerings.

So, in 2009, when it comes to procuring network services, can you ignore VoIP, integrated networks and convergence? The answer is: No, you can't.

The most-cited example of this is the PBX market. IP PBXs are rapidly supplanting traditional PBXs in the new-equipment market. Simple examination of the market research indicates you're putting yourself out to pasture if you invest in a purely traditional voice switch, inviting near-term obsolescene in parts and support. Believe me, the market researcher par excellence in this field, veteran consultant Allan Sulkin, is as skeptical of unproven trends as they come, and in the past has warned users away from half-baked technologies that were destined to flounder. But Al's comprehensive annual voice CPE survey for the folks at VoiceCon and NoJitter.com now clearly shows what you need to be thinking about in a new voice equipment buy, and it's IP by a mile.

Still, for many, PBX buys are a once-a-decade (or less) event. The same phenomenon manifests itself in a somewhat different way in the transport network services arena, and you may have to understand it on a more pressing basis than for your voice equipment.

On the surface, IP/MPLS services are "data headliners." You buy them because you want today's generation of WAN connectivity -- or are essentially forced to it by your supplier's policies or pricing signals. No one today makes you run voice over these networks, and most MPLS procurements include a request to the same vendors to bid standard toll voice elements as part of a full competitive telecom refresh.

But unlike past generations of data services that formed some kind of "virtually private" carrier-cloud alternative to private-line networks, the very structure of MPLS rate elements does force you to make a specific determination on your current and projected packet-voice practices. You can't just wave the issue away.

AT&T's current key unmanaged MPLS service, called AVPN, and Verizon's, called Private IP or simply "PIP," have slightly different ways of handling this. The very fact that AVPN and PIP have non-parallel mechanisms actually adds to the pressure to project your voice or other delay-sensitive apps into the intermediate term. They may be different mechanisms, but they're both "Class of Service" rate elements -- the very name of which implies a concern for packet-based application performance ranging from "best efforts" Internet browsing to jitter-intolerant voice. That's as opposed to frame relay's "Committed Information Rate" measurement of simply a raw bandwidth reservation across the cloud against competing users.

In a nutshell, AVPN offers a range of CoS packages defined as high or low levels of "multimedia" or "critical data" oriented priorities, and you have to pick pre-determined "profiles" that allocate the port bandwidth by percentage somewhere in this range. PIP's mechanism appears on first blush to be a more binary selection -- you specify whether or not you want a "gold" level of CoS service (called "Gold CARs" after the legacy MCI's use of the term "Committed Access Rate" in early MPLS services).

But in fact, even the choice of a Gold CAR for a particular PIP network site then requires you to specify the precise amount of bandwidth you want for this real-time CoS, which could be 10%, or 20%, or 40% of the full port, representing your expectation of the proportion of traffic that will require this real-time/voice throughput. Significantly, you can't be inconsistent in the way that you present this to AT&T, Verizon and others, and in comparing bids you need to understand where the service definitions of the two services match up. In fact, this may be the biggest challenge in MPLS deal analysis, and you may find it difficult to confidently choose an MPLS service unless you're sure you've poured your application requirements correctly into each proposal.

I know there's a lot of acronyms to deal with here. But the bottom line is that from now on, carrier network services are going to be defined directly around the issue of application performance, in a world where "application" inherently means the entire range of voice, video and data transmissions. Whether you actually run any given application over the network is your choice. But when you buy the service, its potential to run all those applications is key to understanding the service pricing across the range of your bidders' offerings.

The more you are prepared internally with your VoIP roadmap, the better off you'll be in your "data" procurements -- because it's all a network to your suppliers, and the industry as a whole.

Do you pay a universal service surcharge when you buy a carrier data service? The history of whether you do or not has been as strange as it gets. And it's about to take another turn.

The bottom line right now is that MPLS services are coming fully under the surcharge regime as a result of a key FCC move. That's going to raise costs for many users, but it also provides a new opportunity for users to really understand surcharges and how to plan for them.

To grasp enterprise data services' relationship to the universal service issue, and what's going on now with MPLS, it's best to keep two things in mind. The first is that big changes in what users pay seem to come when generational changes in technology become mainstream in the marketplace, not when the technology itself changes.

The governing rule has always been that provision of an interstate "telecommunications" or "basic" service is one on which carriers must pay into the universal service fund, and the provision of an "enhanced" or "information" service is one on which they don't. So, is MPLS a basic or enhanced service? Years ago, the same question was asked about frame relay. Somehow -- magically -- frame relay was considered an enhanced service until the mid to late 1990s, when it was ruled a basic service.

Did frame relay itself change? No. What changed is that frame relay became heavily used. Not to include it under universal service would have significantly lowered the amount of funds available for the various purposes of the universal service subsidy. So, after about 1997, frame relay became a basic service on which users could expect to pay an extra 10% or so.

That's what's happening to MPLS now. A recent FCC release instructs carriers to include their MPLS revenues in the 2008 USF filing they must make on April 1. It wasn't clear before whether they had to include MPLS, and most didn't. Owing more as a result, carriers are going to want to recover the money from their customers.

And that brings me to the second thing to remember. Despite the millions, or tens of millions, of dollars that your enterprise may have paid out in USF surcharges over the years, the surcharge has never been federally mandated on you, as a business user. The government doesn't make you liable for AT&T or Verizon's quarterly USF expense, no matter how much the carriers lead you to think that's the case. But you have to pay it if your contract with the carrier or its Service Guide states that you pay the fee.

But does it really have to be that way? Here's where things get a little interesting. Before the FCC's latest move, carriers had been taking different approaches to including some form of USF charge on their MPLS invoices. Those carriers that had already imposed a USF pass-through for MPLS had not necessarily applied it to all of their MPLS services. For example, some imposed it on access charges but not port charges.

And the truth is, there have sometimes been "seams" into which customers have been able to place themselves in order to pay less in USF charges on data services. Right before MPLS became popular, many of the nation's big companies were buying not pure frame relay, but a service called FRASI -- Frame to ATM Service Interworking. AT&T in particular tended not to charge a USF pass-through on FRASI customers, more or less officially reasoning that since one end of each connection was ATM -- which, unlike frame relay, was never ruled a "basic service" -- it would not impose the charge. But the larger reason was that AT&T wanted to win big frame/ATM deals vs. rivals by charging less money, and that was a good thing.

So surcharges can ultimately be a deal question. If you're not in the process of doing a deal, and you are an MPLS customer, the (harsh) reality is that your costs are probably going up soon, because your carrier will be paying more and will want to get it back from you. If you are doing a competitive deal, there is now a greater premium than ever on getting hard answers in your RFP as to what surcharges each bidder passes along on what services and why -- not least because the USF surcharge itself is also going up to 11.3% of applicable revenues on April 1.

We've reached the same critical-mass "break point" on MPLS now that we reached on frame relay in the late 1990s -- when the government feels a previously uncertain service must be counted in the carrier revenues to keep their universal service cash flow going. And while that means that customer costs in general will be up as well, for you specifically as a seeker of competitive offers, that also means that surcharges -- just like other rate elements such as access, ports, and class-of-service packages -- need to be compared straight up in new bids.