MTNS: MultiTransport Networking Service

Customers

XO Communications introduced MultiTransport Networking Service (MTNS) in 2003 as a way to connect enterprise sites across a single MPLS-enabled IP backbone even when those sites used different access technologies. The initial service focused on Frame Relay-to-Frame Relay and Ethernet-to-Ethernet wide-area-network connectivity, with a roadmap for class-of-service controls and broader protocol interoperability.

The idea was timely. Many enterprises still had dependable Frame Relay circuits, private-line connections, and ATM-era access at important locations, while newer branches, data centers, and Internet-facing services were moving to Ethernet and IP. A service such as MTNS let a provider absorb some of that protocol complexity inside its core instead of forcing every customer site to migrate at the same time.

What MTNS Promised

At launch, MTNS was positioned around four practical goals:

Transport continuity: keep existing WAN access in service while introducing newer Ethernet options where they made sense.
Unified provider core: carry customer traffic over an MPLS-enabled IP backbone rather than maintaining separate service islands for each legacy protocol.
Migration without a cliff: allow a company to update sites gradually, matching access choices to geography, building availability, bandwidth needs, and budget.
Service differentiation: prepare for class-of-service features so voice, transactional applications, bulk data, and interactive traffic could receive different treatment.

That combination explains why MTNS mattered. It was less about inventing a new access protocol than about giving customers an operational bridge between older private networking and the IP/MPLS service model that came to dominate enterprise WANs.

How MPLS Changed Private WANs

Multiprotocol Label Switching gave carriers a flexible way to steer traffic across a shared backbone while preserving customer separation and service policy. Instead of building a distinct overlay for every customer protocol, a provider could use labels and provider-edge routing to deliver Layer 3 VPNs, Layer 2 pseudowires, Ethernet services, traffic engineering, and quality-of-service behavior from a common packet infrastructure.

For enterprise buyers, this changed the conversation. The old question was often which circuit technology to order at every site. The newer question became what service behavior was needed: any-to-any IP reachability, Layer 2 adjacency, hub-and-spoke isolation, voice prioritization, disaster-recovery paths, or data-center interconnect. The access circuit still mattered, but the service contract increasingly described reachability, classes, latency, availability, and handoff type.

Frame Relay, Ethernet, and the Migration Path

Frame Relay was efficient and widely deployed for branch connectivity, but it reflected an era of lower bandwidths and more static application patterns. Ethernet access offered a more familiar LAN handoff, easier speed upgrades, and better alignment with IP routers, firewalls, voice gateways, and later cloud edge devices. MTNS sat in the middle of that change: it let a customer keep sites that still depended on Frame Relay while adding Ethernet where facilities and economics allowed.

The same pattern appeared across the industry. MPLS VPNs became the common managed-WAN answer for enterprises that wanted predictable private connectivity. Metro Ethernet and Carrier Ethernet services made Ethernet handoffs normal outside the campus. VPLS and pseudowire services helped emulate Layer 2 circuits across MPLS networks. Later, EVPN improved Ethernet VPN control-plane behavior and became important in both service-provider networks and data-center fabrics.

What Changed After 2003

XO continued to build IP and Ethernet services after MTNS. In 2017, Verizon completed its acquisition of XO Communications' fiber business, adding metro fiber density and network reach to Verizon's portfolio. That makes MTNS historically useful as an example of the managed-service transition that preceded today's enterprise networking mix: MPLS VPN, Ethernet private line, broadband Internet, LTE and 5G backup, SD-WAN overlays, direct cloud connections, and security service edge controls.

The service vocabulary also changed. Customers now hear less about Frame Relay migration and more about hybrid WAN, application-aware routing, cloud on-ramps, zero-trust access, SASE, and service assurance. Even so, the core MTNS problem is still recognizable: connect sites that do not all look alike, protect important traffic, make migrations incremental, and hide as much carrier-network complexity as possible from the customer edge.

Modern Equivalents

A current MTNS-like design would usually be assembled from several pieces rather than sold as a single legacy-migration service:

MPLS Layer 3 VPN: still useful for predictable private routing, regulated environments, and sites where a managed provider service is preferred.
Carrier Ethernet: common for data-center, campus, metro, and high-bandwidth enterprise access where an Ethernet handoff is the simplest operational model.
EVPN and VPLS: used when Layer 2 extension, multi-homing, or Ethernet VPN control-plane features are required.
SD-WAN: overlays MPLS, broadband, DIA, wireless, and other underlays with centralized policy and application-aware path selection.
Direct cloud connectivity: links enterprise WANs to public-cloud regions and SaaS ecosystems without forcing all traffic through a traditional data center.
SASE and security service edge: move policy enforcement closer to users, branches, applications, and cloud services.

Design Lessons That Still Apply

MTNS is a reminder that WAN modernization is usually a staged operating problem, not a one-time technology swap. The right design accounts for access availability, application sensitivity, routing policy, encryption needs, service-level agreements, cost, monitoring, and the skills of the team that will run the network after deployment.

Several lessons remain useful:

Do not migrate every site the same way if the sites have different traffic, risk, and access options.
Make the handoff simple for the customer edge whenever possible; complexity belongs in repeatable provider or platform operations.
Define traffic classes by application need rather than by habit.
Plan coexistence carefully, because old and new WAN services often run side by side for years.
Measure the experience users care about, not just whether circuits are administratively up.

In 2003, MTNS gave XO a story for bridging Frame Relay and Ethernet across an MPLS core. In 2026, the same architectural instinct shows up in hybrid WAN and cloud networking: abstract the transport, preserve choice at the edge, and make the network easier to evolve without breaking the applications that depend on it.