Part 1: Transformation
[trans-fer-mey-shun]: n, A complete or major change in someone’s or something’s appearance, form, nature, etc.
Transformation is occurring in many facets of the Communication Service Provider’s (CSP’s) network, product offerings, service definitions and business operations. Software Defined Networking (SDN) and Network Function Virtualization (NFV) has been at the forefront as a catalyst for such transformation.
However, many parallel moving pieces are at work simultaneously bringing about such transformation. A change requires a catalyst, something to alter the current course. Today, we are seeing many catalysts driving the transformation in how CSP’s operate, including: 1) The movement from hardware to software, 2) the growing complexity of the back office, 3) software innovation based on open interfaces at every level.
The most basic catalyst is the movement from hardware to software. Long ago, we realized software was a much more viable solution to solving problems due to its dynamic, flexible, powerful and cost-effective nature. What previously took weeks to change in hardware, could now be changed in software in seconds. Once the industry shift to software was in motion, the skill set needed to follow. This is the area that is generational and has much room to evolve (more on this later).
As a hardware-centric environment was replaced with a software-enabled environment, the ecosystem was filled with vendor-proprietary software solutions. There was network programmability, but not very user friendly and not very open (think proprietary CLIs and a proliferation of custom management systems with siloed data). CSPs still needed many Network Engineers in the Operations staff to learn all the different vendor equipment interfaces, command sets and other Network Operations Center (NOC) staff to interact with the management systems for the network equipment. The back office has thus become a management behemoth with huge operational expense.
Thus, the next significant catalyst is the growing complexity of the back office. CSPs realize there is no effective way to scale operations with growing complexities of product offerings, service definitions and network infrastructure complexities. The traditional back office and network management methodologies must change.
Referring back to the generational software skill set that has been evolving. A new breed of ‘network engineers’ are emerging that are network computer scientists who understand that open source software, modeling data using standard data modeling languages, and creating standard interfaces so systems can communication over APIs are essential to transforming the back office. The concepts are driven from the basic web services technologies used to build the Web 2.0 internet. The ideas of opening up interfaces and sharing common data models across various systems is crucial to revolutionizing the legacy back office Operational Support Systems (OSS) systems and embracing the emergence of SDN/NFV.
One thing is certain: if this back office transformation does not occur, migration to SDN/NFV cannot effectively occur due to the complete software and programmability nature of SDN/NFV. Software concepts have now enabled products, services and workflows to be modeled using both protocol agnostic (e.g., Unified Modeling Language) and protocol specific modeling languages.
Which brings us to the third, and arguably most impactful, catalyst: Software innovation based on open interfaces at every level. At the implementation level, services modeled in UML can be transformed into protocol specific modeling languages such as JSON, XML Schema (XSD), YANG, Structure of Management Information (SMI), Web Services Description Language (WSDL), etc. Once the entire service is modeled into a protocol specific data modeling language, there is significant power and efficiencies realized in what can be done with the service model. Three examples illustrated below are:
1) A RESTful web services Application Programming Interface (API) call can be invoked to order a product offering, carrying the JSON service definition with the required service attributes inside the JSON payload file based on the JSON schema. This might be a minimal set of service attributes required to be specified by the subscriber when placing the order.
2) An internal order management system receiving the order might invoke a second RESTful web services call to a provisioning policy server but include many more service attributes in the JSON payload file required for provisioning the service. These additional service attributes might be sourced from the service model used to define the product catalog entry, as well as from other back office OSS systems.
3) The provisioning policy server may invoke NETCONF calls out into the network, to each network device participating in the service for the product offering in the order, where the NETCONF call contains the YANG data model representing the device level attributes needed for provisioning that specific node in the network. In this instance the NETCONF protocol is used since the network devices supported NETCONF as the network management protocol while the back office systems support RESTful web service interfaces.
In these scenarios (think open APIs across all layers of a CSP’s network management functions, from network layer logic up to business and application layer logic, as well as spanning all business process workflows), the traditional “CCNA skill set” network engineer skill set is bypassed and instead automated workflows are implemented in software running on commodity servers. This is how we can achieve the operational scalability, and in addition, a migration path to support SDN/NFV in the CSP network and operations.
