Last two decade or so, at the time when manufacturing and service industries were embracing automation, Telecom took a different strategy instead. Many operators went through the various operating model from BPO (Business Process Outsourcing) to KPO (Knowledge Process Outsourcing). Its a puzzle, as a native tech industry, why Telecom failed to automate end to end service delivery chains?
The answer is quite shocking; especially for the network part, the failure for telecom automation is mainly due to Network Management practise within the industry. Following excerpt is from the book Network Programmability with YANG by Benoit Claise et at-
It is not impossible to use the CLI for management, but it is expensive and difficult, as the industry has noted well over the last three decades. In fact, this was identified as one of the main reasons why networking did not evolve as fast as the rest of the IT industry by the Stanford Clean Slate project, the foundation of the SDN movement.
As the industry moved on, the idea of Orchestration and SDN emerged to solve telecom automation puzzle. But, by the look of it, both Orchestration and SDN mean different things to different people -a perspective not so desirable if they intended for industry-wide adoption.
SDN had a dramatic twist. In earlier days, SDN strictly meant programming FIB (forwarding information base) on network nodes using OpenFlow. If you cannot program FIB, you don’t have SDN. But, soon it was realized that OpenFlow is impractical even for a network with modest size. Nowadays, the SDN means literally- Software-Defined Networking, which implies Network Programmability. In the current paradigm, an SDN controller is an NMS -Network Management System (not EMS -Element Management System) with FCAPS.
FCAPS is the acronym for Fault, Configuration, Accounting, Performance, Security. A legacy NMS doesn’t support all of these functions; as a result, an operator uses different tools/protocols to implement FCAPS, for example -CLI for configuration, SNMP for fault/performance, Netflow/IPFIX for accounting, RADIUS/TACACS for security. The biggest challenge for any NMS is configuration management. The CLI is highly proprietary, so it is next to impossible for a single NMS to manage configuration in a multivendor network.
Today, SDN is more about FCAPS than OpenFlow. In the new SDN era, CLI replaced with YANG and NETCONF, YANG as data-modelling language, while NETCONF is the southbound protocol that uses XML serialization. Telemetry becomes the new name for Fault, Performace, Accounting management. For security, NACM -Network Configuration Access Control, will do the same thing as RBAC (Role-Based Access Control). And both Telemetry and NACM are based on YANG/NETCONF.
SDN is IETF Automation; hence any IETF compliant NMS is an SDN. But does SDN also mean Orchestration? SDN surely is a network automation tool, but most likely, it is not an Orchestration tool.
MANO -Management and Orchestration, on the other hand, is an ETSI Automation. Orchestration often used in IT context with ETSI paradigm. There are significant differences between both SDO’s -i.e. between IETF vs ETSI.
FCAPS is the IETF way to do automation, while NFV is the ETSI way. Their different way of doing things requires interworking between SDN and Orchestration, i.e. they are not interchangeable. ETSI MANO emphasizes on the opensource endeavour. ETSI uses TOSCA (Topology and Orchestration Specification for Cloud Applications, an opensource project) as a data-modelling language -typically VNFD (VNF Descriptor) files are written in TOSCA. TOSCA is very different from YANG; while YANG is a blueprint-like; TOSCA, on the other hand, is template-like. So, it is improbable that we will see SDN (Network) and Orchestration (IT) on the same platform.
Even within the network domain, we see diversity between fixed and mobile. ETSI MANO automation is mandatory for 3GPP 5G SBA (Service-Based Architecture). 3GPP selected YAML for API language for SBA, which uses JSON data-serialization. In contrast, IETF standardized YANG API with XML serialization. Although like 3GPP, IETF support RESTful protocol (RESTCONF) instead of NETCONF; RESTCONF is not a robust southbound API as NETCONF. In SDN (as oppose to SBA), RESTCONF is more suitable northbound API (see Benoit Claise et at).
Finally, answering our first question -telecom automation is a long, tumultuous journey. It’s not that easy.