Discussing this topic can get complicated, depending on who you talk to. Most service providers now rely on a combination of their own transport network (on-net services) combined with additional circuits provided by 3rd party access vendors. These out of network Ethernet circuits are considered off-net, and having one of these circuits typically results in complex Ethernet transport that crosses multiple carrier boundaries. So maybe it’s not just complicated, but messy too!
It would be nice to have circuits clearly delineated, but there are many reasons service providers require off-net circuits. Some of the most common are:
- regional vs. national coverage
- an international footprint
- limited metro circuits
- data center demands
- customer requirements
Of those noted above, one of the most common reasons is data center requirements. Often you hear enterprises in one data center indicate a critical need for quality, guaranteed connectivity to their cloud services provider in a different data center. Because of this there are many times where the enterprise finds itself connecting via an off-net circuit supplied by an alternate access vendor in order to meet the data center requirement.
Over the last decade, alternate access providers providing these circuits to the service providers has been a big and lucrative business. Keep in mind, there can be a significant recurring monthly expense for these service providers. We all know in the provisioning space that service providers have many OSS tools to manage their own on-net circuits, but for anything that is off-net they have very limited visibility.
Here’s a recent example that illustrates my point:
One of our customer’s off-net circuits went down. At first, the service provider did not know it was out of service. It took forever to determine which segment of the transport network went down. We went through the customer’s services inventory data to know which access vendor was responsible for that transport circuit and we discovered that the information was wrong. We called the provider on their SLA, and it led us to ask questions such as: What penalties are not being covered under the current SLA structure? What about circuits that may no longer be in service but are still being billed, because there is no accurate mechanism to track off-net circuit inventory?
From an auditing perspective a lot of tier 1 service providers are generating upwards of 1000-1500 orders per month for off-net circuits. The way it works now is that it’s a highly manual process between the service provider and the alternate access provider. These orders often are fraught with errors, inaccurate provisioning data, delayed processes, so much so that it takes an average of 150 days to turn up an Ethernet circuit. The Ethernet product brings differing service definitions that need to be reconciled between Ethernet access vendors and the service provider. This adds further complexity to this problem.
Off-net inter-carrier Ethernet transport will continue to be a service needed going forward. As we are seeing with SD-WAN it will only get more complex, as these networks compound the challenge by introducing different network types and new applications and virtualized network functions. and operational systems need to be designed to handle that complexity.
This brings a new approach that transverses multiple carrier networks, and IP and next generation SDNs. The ability to derive off-net inventory data from a diverse set of data sources and types – excel, OSS, activation notices, for example, and then provide an accurate and complete view of all Ethernet assets – both off-net and on-net. Critical is the ability to manage SLA performance, with detailed fault sectionalization and factors in scheduled maintenance checks.
It’s important to get a handle on what’s really going on in your transport network from end to end. Understanding all the pieces throughout your network is key to providing this comprehensive actionable view across on-net and off-net circuits.