Provisioning Gets Real
by William Flanagan, Publisher
[NOTE: Developments in network provisioning prompt
this return to a former topic in the ViewsLetter.]
Recall the problem that prompted the first
ViewsLetter in 2002: how to provision data services in
the face of surging volume that by then had exceeded voice
traffic. The labor needed to "nail up" leased lines for data
was compared to switching voice calls on manual cord boards--clearly
Program control switches solved the problem for voice. Direct
dialing by the customer reaches almost any phone in the world in
seconds without help of an operator.
Dial-up services for data were tried. You could say Telex was
one, and X.25 allowed on-demand connections. Switched 56K and
T-1s had their moments. The Internet offered the ultimate
'dial up' flexibility, able to reach any host with access and an
entry in the global Domain Name System. Both Telex and X.25
were restricted to relatively few subscribers. The Internet
was open to cyber criminals. Enterprises wanted dial-up
flexibility with the privacy of leased lines.
Demand for private networks continued to grow. The data side
of the telco business worked to keep up by enhancing the
tools. However, provisioning remained at least in part a
manual function. Service providers adopted smarter software
for Operations and Support Services to create virtual circuits,
which helped with privacy, but typically within a silo such as frame
relay or MPLS. They still could take weeks to provision a new
site. Different systems addressed each layer of the
network: physical, optical, switching, routing.
Doing the same better and faster got us by for more than a
decade. Continued geometrical growth in Internet traffic is
breaking the old model for provisioning because it:
- is too slow--a new circuit can still take a month to set up.
- costs too much--the process requires trained and skilled
technicians to do routine work.
- makes for too many errors--humans, being human, make mistakes.
- duplicates functions--lack of coordination means redundancy
and alternate paths are often set up in more than one way, in
optical paths, packet switches, and routers.
There must be a better way, certainly for the billions of devices
expected on the Internet of Things. Today the telecom industry
calls it Software Defined Networking (SDN).
Defining SDN can't be done in a Tweet. Rather than attempt to
repeat the material, I refer you to Jim Metzler's reports
on SDN at Webtorials.com. Note that SDN is not the same
as Network Function Virtualization, a separate topic.
A commonly published statement says SDN "separates the control plane
from the data plane"--however that works. My preferred
definition of SDN focuses on centralized route finding and automatic
configuration of network elements based on policy, identity, and
permissions. That is, the switches and routers no longer need
to run routing protocols like Spanning Tree, Address Resolution
Protocol, or IS-IS. A central control computer makes those
calculations, then updates the forwarding tables in each network
element involved. The nodes forward packets in the core, and
may apply additional functions at the edge.
Removing route-finding from packet handlers reduces their CPU
loads. In turn, freed CPU cycles can increase packet
throughput and lower latency on the same hardware. What's not
But you can have more for your money. Step right up and look
at automatic network configuration. Shortest Path Bridging is
an IEEE standard (part of 802.1aq) that simplifies packet forwarding
in the core network. It operates at Layer 2, using MAC
addressing to make all switches at the provider edge (PE) of a
network logically "adjacent" to each other--sometimes called a
switch 'fabric'. The core switches need only one configuration
per topology change, performed automatically if the switches are
compatible (or under central control).
Previously the standards committees defined how to use the SPB
connections with a technique known as "MAC-in-MAC" (MiM)
encapsulation, typically performed by a router or switch at the edge
of the network. Most originating frames are Ethernet, which
include source and destination MAC addresses. Some device (PE
switch, concentrator switch, or user device) encapsulates such a
frame entering the network by adding another MAC header that will
get that frame across the core to the correct egress PE
switch. MiM simplifies and reduces the size of forwarding
tables in the core switches.
At the PE egress, the MiM frame loses its SPB MAC to emerge as the
original frame. Note that this is similar to a vLAN header
that creates virtual connections and networks, but with an address
space in the millions rather than the 4000 possible IDs for
vLANs. MiM doesn't require SDN as the switches can perform the
configuration of the core.
Wait--it gets better with SDN.
A Central Controller provides not only route finding based on link
and node status. In addition, the controller can hold
policies, user lists, permissions, and other factors to influence
how to handle connection requests. With a suitable software
client installed, any end device newly connected anywhere on the
network can look first for the controller and try to register.
Authorized devices recognized by the controller can be updated,
configured, and connected to permitted services--automatically and
That is, any stock device taken off the shelf (or drop shipped) in
factory default condition will take on its proper role in the
network when plugged in---with no manual configuration.
Of course there's a catch. Instead of configuring the device
itself or the switch/router it attaches to, configuration work is
done in the data center by entries in a data base. Nicer work
if you can get it.
SDN promises efficiencies, protection services, and speedier
provisioning for streaming media such as voice and
video. With a central controller filling the forwarding
tables in the core packet forwarding nodes, the form of the "MAC" or
"MiM" address is arbitrary. Today, vendors use full Ethernet
MAC addresses. Encapsulated frames also carry MAC, IP,
TCP/UDP, and probably other headers. This long set of headers
could be replaced with a shorter 'index' of 4 to 8 bytes that needs
to be unique only on a local data link. The smaller number of
octets per packet would be a very significant saving in bandwidth
for voice over IPv6 (small packet payloads every 20 ms) and helpful
for any streamed connection.
Future issues of VL will look in more detail at SPB, Provider
Backbone Bridging, and automated provisioning methods of
Flanagan Consulting Can Help You
We understand not only the technology of
networks, but also
the surrounding business processes:
preparation/analysis, statements of work,
consensus building around a solution, white
papers, and product
Find out more: call +1.703.242.8381
Flanagan Consulting Supports Litigation Professionals
Several associates are experienced in analysis of
contracts, and other intellectual property
related to IT and communications.
We have assisted attorneys preparing claims,
depositions, and testimony.
Queries to +1.703.855.0191.
Sponsor an Issue of ViewsLetter...
...to reach over 3400 interesting people in
Telecom and IT networks.
For details, call the Publisher at
Responses to ViewsLetter and Subscriptions
Mail is welcome when addressed to firstname.lastname@example.org.
You may unsubscribe at any time here.
Special thanks for supporting ViewsLetter to www.Webtorials.com,
your best source for communications tutorials and
Creative Network Solutions
From Desktop to Data Center
3800 Concorde Parkway,
Suite 1500, Chantilly, Virginia 20151 USA
Ph: +1.703.242.8381 Fx:
Flanagan Consulting is a Service
Mark of W. A. Flanagan, Inc.
false knowledge; it is more dangerous than ignorance."
--George Bernard Shaw