VL on Provisioning        Issue 93                January 2016

[NOTE:  Developments in network provisioning prompt this return to a former topic in the ViewsLetter.]

Finally, Automated Provisioning Gets Real

by William Flanagan, Publisher

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 not sustainable.
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:

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 to like?

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 within minutes.

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 vendors. 

Flanagan Consulting Can Help You

    We understand not only the technology of networks, but also
    the surrounding business processes:  procurement, bid
    preparation/analysis, statements of work, financial analysis,
    consensus building around a solution, white papers, and product
    Find out more:   call +1.703.242.8381  or email

Flanagan Consulting Supports Litigation Professionals
    Several associates are experienced in analysis of patents, trademarks,
    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 +1.703.855.0191

Responses to ViewsLetter and Subscriptions
    Mail is welcome when addressed to publisher@viewsletter.com.
    You may unsubscribe at any time here.

Special thanks for supporting ViewsLetter to www.Webtorials.com,
    your best source for communications tutorials and white papers.

Flanagan Consulting

Creative Network Solutions
From Desktop to Data Center

3800 Concorde Parkway, Suite 1500, Chantilly, Virginia 20151 USA
Ph:  +1.703.242.8381    Fx:  +1.703.242.8391

Flanagan Consulting is a Service Mark of W. A. Flanagan, Inc.

"Beware of false knowledge; it is more dangerous than ignorance."
                                       --George Bernard Shaw