An ontology-based approach toward the configuration of heterogeneous network devices

Department of Computer Architecture Technical University of Catalonia (UPC) Doctoral Thesis An Ontology-Based Approach Toward the Configuration of Heterogeneous Network Devices Author: Anny Martinez Advisor: Dr. Marcelo Yannuzzi Co-advisor: Dr. Xavi Masip-Bruin A THESIS PRESENTED TO THE TECHNICAL UNIVERSITY OF CATALONIA IN FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR IN COMPUTER SCIENCE Barcelona, April 2015 -“Intelligence” is the art of good guessing.- H. Barlow TECHNICAL UNIVERSITY OF CATALONIA (UPC) Abstract Department of Computer Architecture Doctor in Computer Science An Ontology-Based Approach Toward the Configuration of Heterogeneous Network Devices by Anny Martinez Keywords: Networking;Semantics;Network Management;Future Internet;OntologyBased Information Extraction;Device Configuration;Command Line Interface;LISP; Addressing Scheme. Despite the numerous efforts of standardization, semantic issues remain in effect in many subfields of networking. The inability to exchange data unambiguously between information systems and human resources is an issue that hinders technology implementation, semantic interoperability, service deployment, network management, technology migration, among many others. In this thesis, we will approach the semantic issues in two critical subfields of networking, namely, network configuration management and network addressing architectures. The fact that makes the study in these areas rather appealing is that in both scenarios semantic issues have been around from the very early days of networking. However, as networks continue to grow in size and complexity current practices are becoming neither scalable nor practical. One of the most complex and essential tasks in network management is the configuration of network devices. The lack of comprehensive and standard means for modifying and controlling the configuration of network elements has led to the continuous and extended use of proprietary Command Line Interfaces (CLIs). Unfortunately, CLIs are generally both, device and vendor-specific. In the context of heterogeneous network infrastructures—i.e., networks typically composed of multiple devices from different vendors—the use of several CLIs raises serious Operation, Administration and Management (OAM) issues. Accordingly, network administrators are forced to gain specialized expertise and to continuously keep knowledge and skills up to date as new features, system upgrades or technologies appear. Overall, the utilization of proprietary mechanisms allows neither sharing knowledge consistently between vendors’ domains nor reusing configurations to achieve full automation of network configuration tasks— which are typically required in autonomic management. Due to this heterogeneity, CLIs typically provide a help feature which is in turn an useful source of knowledge to enable semantic interpretation of a vendor’s configuration space. The large amount of information a network administrator must learn and manage makes Information Extraction (IE) and other forms of natural language analysis of the Artificial Intelligence (AI) field key enablers for the network device configuration space. This thesis presents the design and implementation specification of the first Ontology-Based Information Extraction (OBIE) System from the CLI of network devices for the automation and abstraction of device configurations. Moreover, the so-called semantic overload of IP addresses—wherein addresses are both identifiers and locators of a node at the same time—is one of the main constraints over mobility of network hosts, multi-homing and scalability of the routing system. In light of this, numerous approaches have emerged in an effort to decouple the semantics of the network addressing scheme. In this thesis, we approach this issue from two perspectives, namely, a non-disruptive (i.e., evolutionary) solution to the current Internet and a clean-slate approach for Future Internet. In the first scenario, we analyze the Locator/Identifier Separation Protocol (LISP) as it is currently one of the strongest solutions to the semantic overload issue. However, its adoption is hindered by existing problems in the proposed mapping systems. Herein, we propose the LISP Redundancy Protocol (LRP) aimed to complement the LISP framework and strengthen feasibility of deployment, while at the same time, minimize mapping table size, latency time and maximize reachability in the network. In the second scenario, we explore TARIFA a Next Generation Internet architecture and introduce a novel service-centric addressing scheme which aims to overcome the issues related to routing and semantic overload of IP addresses. Acknowledgements This thesis would not have been possible without the inspiration and support of many people. I would like to begin by expressing my sincere gratitude to my Ph.D. advisors Dr. Marcelo Yannuzzi and Dr. Xavier Masip-Bruin for their valuable guidance, support and above all for becoming referents of professionalism in this journey. Their dedication, invaluable discussions and timely advices certainly made this work possible. Furthermore, I would like to extend my appreciation to Rafael Mulero for his commitment and collaboration in the implementation and demonstration of the work herein developed. Many thanks to my colleagues at CRAAX and NetIT with whom I had the pleasure of working over these past years. Moreover, I would like to thank the administrative staff at UPC for their support during the course of my thesis. Additionally, I would like to acknowledge Dr. Jorge L´opez-De Vergara for his valuable insights on my work and support in joint papers. Sincere thanks are extended to the members of my thesis committee Dr. Marilet De Andrade and Dr. Mario Nemirovsky, as well as internal reviewers, for their valuable time and dedication to the evaluation of my work. In the course of my thesis several organizations have been key supporters of my work. I would like to thank the TARIFA Project (i2CAT) and the European Commission through the ONE Project in the FP7 Program under contract number INFSO-ICT258300. I would also like to acknowledge the Spanish Ministry of Science and Innovation under contracts TEC2009-07041 and TEC2012-34682, the Catalan Government under contract 2009 SGR1508 and the Technical University of Catalonia (UPC). Finally, a very special thanks to my parents, my sister and most importantly, to Lorenzo for all their inspiring words, for believing in me even in the most difficult moments, and for always encouraging me to go a step further. Words cannot ever express my gratitude for their support and trust. Anny Mart´ınez, March 2015 vi Contents Abstract iv Acknowledgements vi List of Figures xii List of Tables xiv Abbreviations xvi I INTRODUCTION 1 1 Summary and Road Map 3 1.1 Motivations ................................... 3 1.1.1 Semantic Issues in Configuration Management ........... 4 1.1.2 Semantic Issues in Addressing Schemes ............... 5 1.2 Thesis Contributions .............................. 7 1.2.1 Semantic-Based Configuration Management ............. 7 1.2.2 Semantic-Based Addressing ...................... 8 1.3 Supporting Publications ............................ 9 1.4 Thesis Structure ................................ 11 II BACKGROUND 15 2 Carrier-Grade Network Management 17 2.1 Interoperability Issues in Multi-Layer and Multi-Vendor Carrier-Grade Networks .................................... 17 2.1.1 Multi-Layer Interoperability (MLI) Issues .............. 18 2.1.2 Multi-Vendor Interoperability (MVI) Issues ............. 22 2.1.2.1 The Semantic Problem in Network Device Configuration Management ......................... 25 2.2 Traditional Strategies to face the MLI and MVI Problem in Network Management .................................. 28 2.2.1 In-House Developments ........................ 29 2.2.2 IP over DWDM ............................. 29 viii Abbreviations AI Artificial Intelligence API Application Programming Interface AS Autonomous System BDM Balanced Distance Metric BRPC Backward Recursive Path Computation BFS Breadth First Search CAPEX CAPital EXpenditures CC Continuity Check CCV Common Communication Vehicle CLI Command Line Interface CMOS Complementary Metal-Oxide Semiconductor CV Connectivity Verification DHT Distributed Hash Table DNS Domain Name System DWDM Dense Wavelength-Division Multiplexing ECMP Equal Cost Multi-Path EICTA European Information & Ccommunications Technology Industry Association EID Endpoint IDentifier ETR Egress Tunnel Router FI Future Internet GATE General Arquitecture for Text Engineering GMPLS Generalized Multi-Protocol Label Switching HSRP Hot Standby Routing Protocol ICT Information and Communications Technology IE Information Extraction xvi IETF Internet Engineering Task Force IoT Internet ofThings IP Internet Protocol IP-NMS IP Network Management System IPoDWDM IP over DWDM ISP Internet Service Provider ITR Ingress Tunnel Router ITU International Telecommunication Union LCS Least Common Subsumer LISP Locator/Identifier Separation Protocol LMP Link Management Protocol LRP LISP Redundancy Protocol LSP Label Switched Path MIB Management Information Base MLI Multi-Layer Interoperability MLNM Multi-Layer Network Management MPLS Multi-Protocol Label Switching MPLS-TP Multi-Protocol Label Switching Transport Profile MPTCP Multi-Path Transport Control Protocol MTNM Multi-Technology Network Management MTOSI Multi-Technology Operation Systems Interface MVI Multi-Vendor Interoperability NFV Network Functions Virtualization NLP Natural Language Processing NMS Network Management System OAM&P Operation, Administration, Maintenance and Provisioning OBIE Ontology-Based Information Extraction OEO Optical-Electrical-Optical OF-CONFIG OpenFlow CONFIGuration Protocol OIF Optical Internetworking Forum OPEX OPerational EXpenditures OS Operating System OSI Open Systems Interface OSS Operations Support System OTN Optical Transport Network OVS Open VSwitch OWL Web Ontology Language OXC Optical Cross-Connect PA Provider-Aggregatable PCC Path Computation Client PCE Path Computation Element PCEP Path Computation Element Protocol PHP Penultimate Hop Popping PI Provider-Independent POS Part OfSpeach QoS Quality ofService RDF Resource Description Framework RFC Request For Comments RLOC Routing LOCator ROADM Reconfigurable Optical Add Drop Multiplexers SDH Synchronous Digital Hierarchy SDN Software Defined Networking SLA Service Level Agreement SNMP Simple Network Management Protocol SONET Synchronous Optical Networking SPF Shortest Path First SWRL Semantic Web Rule Language TE Traffic Engineering TED Traffic Engineering Database TMF Tele Management Forum T-MPLS Transport Multi-Protocol Label Switching T-NMS Transport Network Management System UNI User-Network Interface URL Uniform Resource Locator UUID Universally Unique IDentifier VNT Virtual Network Topology VNTM Virtual Network Topology Manager WSON Wavelength Switched Optical Networks XML EXtensible Markup Language XSD XML Schema To my parents and Lorenzo. . . xx Part I INTRODUCTION 1 Chapter 1 Summary and Road Map This introductory chapter provides a thorough description of the motivations and main contributions of this thesis. The rest of the chapter enumerates supporting publications to journals and conferences and concludes with an overview of the structure of this manuscript. 1.1 Motivations The exponential growth of both Internet traffic and digital information (big data) give no respite to the telecommunications industry and is visibly shortening the life-cycle of the technologies used for core networking. To cope with the traffic demand, the industry has primarily focused on the evolution of the data and control planes, and has rapidly made progress in both subjects. Accordingly, a variety of protocols and technologies have emerged at a very rapid pace, bringing along a complex set of new terminologies and conceptualizations, which in turn raise serious semantic issues. The semantic problems in the field of networking are related to the inability to understand and unambiguously interpret the meaning of domain concepts and protocol units for different purposes, for instance, implementation, management, information modeling, service deployment, etc. Overall, these problems derive either from: (i) the lack of absolute standards for the performance of network functions—which in turn lead to the use of proprietary solutions that typically raise serious interoperability issues in the context of heterogeneous environments; (ii) the lack of formal means for the specification of network protocols—a fact which unquestionably leads to ambiguity and incompleteness of conceptualizations; (iii) the intrinsic nature of an ever-changing domain flood of terminologies—wherein dissimilar concepts are often used interchangeably to refer 3 K. Campowsky, G. Giammatteo, G. Aristomenopoulos, S. Papavassiliou, T. Kuczynski, S. Zielinski, J. M. Seigneur, C. Ballester Lafuente, J. Johansson, X. MasipBruin, M. Caria, J. R. Ribeiro Junior, E. Salageanu, and J. Latanicki., “TEFIS: A Single Access Point for Conducting Multifaceted Experiments on Heterogeneous Test Facilities”, in Elsevier Computer Networks, Volume 63, Pages 147–172, 22 April 2014. 4. W. Ram´ırez, X. Masip-Bruin, M. Yannuzzi, R. Serral-Graci`a, A. Mart´ınez, M. S. Siddiqui., “A survey and taxonomy of ID/Locator Split Architectures”, in Elsevier Computer Networks, Volume 60, Pages 13-33, 26 February 2014. 5. R. Serral-Graci`a, M. Yannuzzi, E. Marin-Tordera, A. Mart´ınez, X. Masip-Bruin, “Metrics and QoE assessment in P2PTV applications”, in Int. J. Internet Protocol Technology, Vol. 7, No. 3, Pages 148-164, 2013. Conferences and Workshops 1. A. Mart´ınez, M. Yannuzzi, J.E. L´opez de Vergara, R. Serral-Graci`a, W. Ram´ırez. “An Ontology-Based Information Extraction System for bridging the configuration gap in hybrid SDN environments”, to be presented at 14th IFIP/IEEE International Symposium on Integrated Network Management (IM 2015), IFIP/IEEE IM 2015 Conference Proceedings and IEEE Xplore R , Ottawa, Canada, May, 2015. 2. A. Mart´ınez, M. Yannuzzi, R. Serral-Graci`a and W. Ram´ırez, “Ontology-Based Information Extraction from the Configuration Command Line of Network Routers”, presented at Second International Conference on Mining Intelligence and Knowledge Exploration (MIKE 2014), Lecture Notes in Artificial Intelligence (LNAI), Cork, Ireland, December, 2014. 3. W. Ram´ırez, X. Masip-Bruin, E. Marin-Tordera, M. Yannuzzi, A. Mart´ınez, S. S´anchez-L´opez, M.S. Siddiqui, and V. L´opez, “A Techno-Economic Study of Network Coding Protection Schemes”, presented at Globecom 2014 - Optical Networks and Systems Symposium (GC14 ONS), Austin, USA, December, 2014. 4. W. Ram´ırez, X. Masip-Bruin, E. Marin-Tordera, M. Yannuzzi, M.S. Siddiqui, A. Mart´ınez, and V. L´opez, “Improving Reliability in Multi-Layer Networks With Network Coding Protection”, presented at 18th International Conference on Optical Network Design and Modeling (ONDM 2014), Stockholm, Sweden, May 2014. 5. W. Ram´ırez, X. Masip-Bruin, M. Yannuzzi, D. Montero, A. Mart´ınez, and V. L´opez, “Network Coding-Based Protection Scheme for Elastic Optical Networks”, in 10th International Conference on Design of Reliable Communication Networks (DRCN 2014), Ghent, Belgium, April, 2014. 6. W. Ram´ırez, X. Masip-Bruin, E. Marin-Tordera, M. Yannuzzi, A. Mart´ınez, S. S´anchez-L´opez, and V. L´opez, “An Hybrid Prediction-based Routing Approach for Reducing Routing Inaccuracy in Optical Transport Networks”, in 19th European Conference on Networks And Optical Communications (NOC2014), Milan, Italy, June 2014. 7. R. Serral-Graci´a, A. Mart´ınez, E. Marin-Tordera, M. Yannuzzi, and X. MasipBruin, “Multi-Layer quality assessment framework for P2PTV applications,” presented in SaCoNeT ICC, Ottawa, Canada, June 2012. 8. A. Mart´ınez, X. Masip-Bruin, W. Ram´ırez, R. Serral-Graci´a, E. Marin-Tordera, and M. Yannuzzi, “Toward a New Addressing Scheme for a Service-Centric Internet,” presented in SaCoNeT ICC, Ottawa, Canada, June 2012. 9. A. Mart´ınez, W. Ram´ırez, M. Germ´an, R. Serral-Graci´a, E. Mar´ın-Tordera, M. Yannuzzi, and X. Masip-Bruin, “An Approach to a Fault Tolerance LISP Architecture,” in 9th International Conference on Wired/Wireless Internet Communications, WWIC 2011, Vilanova i la Geltr´u, Spain, June 15-17, 2011. Ongoing Publications 1. A. Mart´ınez, M. Yannuzzi, J.E. L´opez de Vergara, R. Serral-Graci`a, X. MasipBruin. “An Ontology-Based Information Extraction System for complementing network device configuration in the SDN future” (IM 2015 Invited Extension), to be submitted to IEEE Transactions on Network and Service Management (TNSM), April, 2015. 1.4 Thesis Structure This thesis is structured in five main parts. Next, we provide a brief description of the content and topics discussed along each chapter. PART I INTRODUCTION Chapter 1 provides an introduction to the work developed in this thesis, including motivations, contributions, supporting publications and thesis structure. PART II BACKGROUND Chapter 2 examines in detail the interoperability challenges of managing multi-layer and multi-vendor carrier-grade networks, and review the current trends and recent standards in the area, with strong focus on industrial advances. We cover the MultiTechnology Operations System Interface (MTOSI) as well as OpenFlow, and analyze their potential impact and reach. We also discuss some of the reasons why relevant carrier-grade management proposals have not been able to fulfill the requirements of Internet Service Providers (ISPs), and identify a set of features that might help pave the way to market for new management products. Chapter 3 provides insights on the most important limitations of the current Internet addressing architecture, with main focus on the semantic overload of IP-based addresses. Moreover, we review existing proposals of ID/Locator Split Architectures (ILSAs) and delve into the Locator/Identifier Separation Protocol (LISP), in an effort to analyze its major limitations. Chapter 4 provides a review of the fundamentals in the field of Ontologies and Information Extraction (IE) as potential enablers of semantic interoperability for domains where standards have failed to find path. PART III SEMANTIC-BASED CONFIGURATION MANAGEMENT Chapter 5 describes the Ontology-Based Information Extraction (OBIE) System from the Command-Line Interface (CLI) of network devices, by introducing the rationale supporting our system and then, describing the system’s architecture. Chapter 6 provides a comprehensive description of the Information Extraction algorithm, in an effort to understand how we enable automated interpretation of CLIs configuration capabilities. Chapter 7 describes the Command Retrieval algorithm which is responsible of performing the online functionality of our OBIE System. Chapter 8 presents the experimental framework along with the system’s validation results. We also conclude on the various versions of our IE algorithm—when carried out over the configuration spaces of several widely used routers—and provide results on the performance of our system over enhanced CLIs. PART IV SEMANTIC-BASED ADDRESSING Chapter 9 describes the proposed LISP Redundancy Protocol (LRP)—a control plane protocol for the LISP architecture—aimed to provide reachability and reliability in scenarios of failure. Chapter 10 presents a novel addressing scheme for a service-oriented Future Internet Architecture. Moreover, we assess performance by estimating reachability and limitations of the identification space. PART V CONCLUSIONS AND FUTURE WORK Chapter 11 summarizes the main conclusions of this thesis. Chapter 12 provides the author’s view on potential directions for extending the reach of the work developed in this thesis. Part II BACKGROUND 15 Chapter 2 Carrier-Grade Network Management This chapter aims to examine in detail the interoperability challenges of managing multilayer and multi-vendor carrier grade networks, and review the current trends and recent standards in the area, with strong focus on industrial advances. We cover the MultiTechnology Operations System Interface (MTOSI) as well as OpenFlow, and analyze their potential impact and reach. We also discuss some of the reasons why relevant carrier-grade management proposals have not been able to fulfill the requirements of Internet Service Providers (ISPs), and identify a set of features that might help pave the way to market for new management products. 2.1 Interoperability Issues in Multi-Layer and Multi-Vendor Carrier-Grade Networks Network management has been the subject of study and one of the central targets of the telecommunications industry since the earliest days of networking. However, the overall management of multi-layer infrastructures still remains an open field for research, primarily because of the scarce interoperability between Network Management Systems (NMSs). In the context of multi-layer networks, management interoperability issues arise mainly due to the heterogeneity of technologies (i.e., IP and Optical) and the diversity of device manufacturers, coupled with the absence of standardized and broadly accepted mechanisms that enable both cross-layer and intra-layer communication of NMSs. A clear proof of this situation is the complexity of current Operations Support Systems (OSS). OSSs were originally conceived as the elements bridging business logic for 17 service provision and network management, but in practice they have had to incorporate several layers of “Umbrella NMSs” (as described later in section 2.2.1) to provide a minimum degree of workflow automation. Cutting down OSS complexity is among the most important efficiency objectives of practically all telecom operators. The isolation between the IP and transport management ecosystems is exacerbated by the functional segmentation of standardization bodies, which are not necessarily working in the same direction. While, the Internet Engineering Task Force (IETF) is the organization playing a critical role in the scope of IP-driven network management standards [32], the International Telecommunication Union (ITU) [33], the Optical Internetworking Forum (OIF) [34], and the TeleManagement Forum (TMF) [35], are the most active organizations working toward the development of standards in the field of optical transport networks. In this section, we provide a detailed analysis on the Multi-Vendor Interoperability (MVI) and Multi-Layer Interoperability (MLI) issues for carrier-grade networks and outline the complexities that emerge as a result of the isolation of their management ecosystems. 2.1.1 Multi-Layer Interoperability (MLI) Issues The MLI issues between the IP and transport NMSs arise primarily due to the development of systems targeting individual network layer functions in the Open Systems Interconnection (OSI) model. While the use of the OSI model has ensured that the technological diversity in lower layers does not affect the operation of the upper layers, the lack of mechanisms for enabling coordinated management between them has led to the replication of critical functions. Restoration mechanisms are a clear example of the redundancy produced by independent (i.e., per-layer) management functions in multilayer settings, as they are featured by both layers to restore traffic onto alternate paths in case of failure. Indeed, the scarce efficiency for protecting and recovering multi-layer networks is the result of the absence of communication mechanisms between management ecosystems, which leads to the activation of restoration functions in individual layers IP/MPLS Layer Transport Layer 1 2 4 12 3 4 Trigger recovery at the Transport Layer Implies recovery at the IP/MPLS Layer Requires coordinated recovery. 3 Figure 2.1: Typical failure scenarios in multi-layer networks. based on the utilization of static time thresholds. In typical deployments, transport network restoration is attempted first, and restoration at the IP level is usually delayed by a static time threshold, which can lead to significant losses in case that restoration in the transport network fails [36]. Let us consider the example shown in Fig. 2.1, which summarizes the possible failure scenarios in a multi-layer network. Link and node failures at the transport layer (denoted as (1), and (2), respectively) can be typically recovered by the optical network without manual intervention, provided that the spare resources and capacity are sufficient for that end. A failure of a router (3), on the other hand, can be recovered by the IP/MultiProtocol Label Switching (MPLS) layer. However, whenever a failure occurs at the interconnect point (4)—i.e., when an inter-layer failure occurs—a coordinated strategy is required for safe and efficient recovery. It is worth mentioning that, currently, this coordination is not dynamically resolved; quite on the contrary, it is predefined and meticulously pre-configured during network planning cycles. Observe that for failures (3) and (4), if no backup router is available at the IP layer, the transport layer could reactively attempt to optically bypass the affected router. Unfortunately, the lack of cross-layer management mechanisms does not allow dynamic cross-layer recovery, which leads to an unnecessary duplication of resources and restoration mechanisms at both layers. Indeed, enabling communication between NMSs of different layers would derive in much more efficient restoration strategies, and could help alleviating in the future part of the duplicity in current carrier-grade protection schemes. Another important aspect is that the MLI issue also hinders the automation of multilayer tasks between the management ecosystems of the different network layers. Hence, only manual means are attainable for coordinating cross-layer operations. By manual means we refer to the human interactions between administrators in each network domain. To illustrate this, consider the multi-layer setting shown in Fig. 2.2. In practice, for setting up an IP service (e.g., the provision of IP links), the Planning or Sales Department must first issue a new service request to the IP Network Management Department (1), which in turn performs the corresponding actions to check for the availability of IP resources (2). If the required resources are available at the IP layer, then the administrator will issue a request to the Transport Network Management Department for the set up of new optical paths (3). It is worth highlighting that, as the IP and Transport networks are typically managed separately and independently, they require to comply with formalities and procedures for information exchange, a fact that often results in high provisioning timescales. Once the request is properly received by the Transport Network Management Department, meaning by this that the request satisfies all the requirements from both parts, the Transport Department completes a series of actions, including confirmation of available resources and their subsequent provisioning at the ensure performance, minimize downtime, support rollback in case of failures, enable device software management as well as collect configuration data. Notice that, in general, the term network configuration refers to the configuration of the network as a whole, for example, the deployment of a Virtual Private Network (VPN) service is a typical configuration task, usually expressed through high-level requirements which translate into low-level (individual) device configurations. Herein, our focus is on the configuration of network devices rather than the network as a whole. As previously stated, the lack of standard protocols for network device configuration makes network management increasingly complex for network administrators—particularly in the context of heterogeneous network infrastructures. In this context, the absence of standard protocols has prompted the use of proprietary mechanisms for the configuration of network devices. The Command-Line Interface (CLI) is in fact the preferred mechanism for network device configuration—near 95% of current network devices are configured through proprietary CLIs [12]. Despite its widespread use for configuration purposes, CLIs have numerous limitations, some of which we will briefly overview. Proprietary Protocol. The most significant limitation of CLIs is their proprietary nature, i.e., CLI-based configuration environments are not standard, and thus, are specific to each vendor. This is exacerbated by the fact that within each vendor’s space a CLI can also be specific to a device model or operating system version. This means that, the terminology, commands, configuration operations and related concepts can be dissimilar even among devices of a single vendor. In order to cope with the ever changing configuration environment, network administrators must develop advanced skills, gain specialized knowledge and continuously update to encompass the full range of devices available in the network market. Figure 2.4 depicts an extract of the CLI environment configure set interfaces <interface-name> unit <interface-unit-number> family inet address <source> commit exit Telnet 10.1.2.15 (a) Router Vendor: Juniper. enable configure terminal interface <interface_id> <slot number/port number> ip address <ip_address> <mask> no shutdown end Telnet 10.1.1.20 (b) Router Vendor: Cisco. Figure 2.4: CLI commands for the configuration of an access control list on two different router vendors. for two different vendors (Juniper and Cisco, respectively). From this figure we can observe that different sets of terminologies and commands are used by each vendor to refer to the same configuration operation, namely, configuration of an IP standard Access Control List (ACL). Notice that, not only commands differ syntactically but the granularity and arrangement of the hierarchy also differs among vendors. Lack of semantic interoperability. Furthermore, the foundations of the configuration problems are not restricted to syntactical differences, but most importantly, they extend to semantic dissimilarities between CLIs as well. Due to their proprietary nature, device vendors customize their CLIs as a way to unequivocally distinguish from their competitors (as shown in Fig. 2.4). This leads to definitions of the configuration space in their own terms. In some cases vendors set the hallmark by launching their own terminology, while in other cases their interpretation of the domain leads to misleading use of terms with respect to the common routing domain knowledge, or even overlapping meanings in relation to different terminologies with other vendor configuration spaces. The lack of common standards for the conceptualization of the routing domain has led to scenarios wherein the same terms are used to refer to different concepts or where different sets of terminologies have the same meaning. As CLIs were devised for human operators, in practice, this issue is addressed by featuring help descriptors which aim to resolve the semantics of the configuration domain by providing users with a concise natural language description of commands and variables. Generally, help descriptors are a way to narrow down to the common and shared conceptualizations of the domain of knowledge and guide users through the configuration process. In this context, help descriptors are unquestionably valuable resources for network administrators as a means to disambiguate the semantics of configuration commands. However, in the context of automated environments, there are no means for achieving interoperability at a semantic level. Human/User-driven. The CLI was ideally designed for user-driven operation, i.e., manual-based configuration. This explains its text-based interface and natural language help feature. Moreover, the heterogeneity of CLIs also hinders the automation of network configuration in multi-vendor networks. The only means to achieve automation to a certain extent relies on the use of configuration scripts, an approach that aims to simplify recurrent configuration tasks. However, scripting is neither scalable nor practical as network administrators must adjust and fine-tune their configurations for each system upgrade or network equipment purchase. For this reason, CLI-based configuration is rather challenging and mostly performed in a manual way. Manual-based configurations are likely undesired, not only because they are error-prone and increasingly complex, but mostly because they significantly increase OPEX. High Operational Expenditures. Performing network device configuration through CLI-based mechanisms entails high OPEX. Network device configuration is considered in fact the major contributor to OPEX for current telecom providers [12]. This stems from the fact that manual configuration is expensive. The delay in service provisioning naturally leads to increased costs, in addition to the costs that carry network outages whenever there are mistakes in the configuration process and the expenses required to continuously train network administrators in the configuration of each vendors’ space. Error-prone. Configuration errors can lead to network outages, performance degradation and increased OPEX [55]. CLI-based configurations are highly sensitive to errors due to their manual nature, and note that this can potentially affect other network devices or the network as a whole. According to the previous facts, the proprietary, user-driven and manual-based nature of CLI-based mechanisms make this technology an unsuitable solution to automate network device configuration in the context of heterogeneous networks. Overall, the issue with CLI-based mechanisms is the lack of semantic interoperability between configuration spaces. The means for semantically defining the configuration domain are solely expressed in the form of natural language textual resources targeting human network operators. 2.2 Traditional Strategies to face the MLI and MVI Problem in Network Management Initial efforts led by industry and academia to overcome the MLI and MVI problems in network management have put into practice several strategies. In-house developments, IP over Dense Wavelength-Division Multiplexing (IPoDWDM) [56], and control plane technologies [57,58], are some of the main solutions currently deployed by many large ISPs with the aim of simplifying the missing management functions in multi-layer and multi-vendor settings. Nevertheless, these developments either solve partial problems or target them in a temporal and local way, hindering the possibilities of becoming absolute trends in the field of multi-layer network management. Either way, they provide valuable foundations for: (i) providing basic support of missing management functions, (ii) envisioning new requirements for future approaches targeting interoperability and (iii) bringing to light the real needs of network operators as they evidence the existence of numerous interoperability problems. 2.2.1 In-House Developments As stated in the previous section, the choice of large telecommunication service providers to defeat mono-vendor settings is usually a business and market-driven decision, which has naturally led to heterogeneous network infrastructures. The problems arising from such inherent heterogeneity have resulted in the development of in-house applications, aimed to locally address the management limitations in multi-vendor and multi-layer settings (see Fig. 2.5). These platforms are developed as internal network management engines and are also known as Umbrella NMSs. They are custom-made and they are typically centralized solutions built to temporally address the specific needs of network administrators. They follow a Manager of Manager (MoM) architecture, an alternative that has always been available for network managers to “smooth” the limitations around existing management solutions. Umbrella NMSs lack of flexibility, efficiency or means for exchanging or enabling interoperability between layers in a multi-layer setting. They usually perform as central systems with no top-to-low layer communication or vice-versa. As shown in Fig. 2.5, these umbrella systems typically offer custom interfaces to existing NMSs developed in each network layer (A). In many other cases, the umbrella NMSs directly interact with the network elements (B) to avoid the complexity, the high costs and administrative delays that derive from requesting new functionalities to be developed over proprietary NMSs. This allows to achieve the required management functions at lower costs, reduced time-scales, and higher levels of customization. In-house developments are not efficient and have brought to light the inadequacies of current network management tools for targeting the problems that arise in the context of multi-layer settings. Umbrella NMSs are just an example that discloses the fact that current NMSs lag far behind the requirements faced in practice by network managers. 2.2.2 IP over DWDM IPoDWDM [59,60] is a solution for approaching the core network architecture in order to support the ever-increasing volume of IP traffic. This architecture proposes the convergence of IP and DWDM transport technology by integrating coloured transport interfaces directly in the IP routers and photonic switching into DWDM platforms. Integration of transponders onto routing platforms eliminates external layers of transponders between the IP and optical transport layers. The overall goal is to simplify the IP-NMS / OSS T-NMS / OSS IP Layer Transport Layer IP-NMS / OSS T-NMS / OSS A B A B Interaction with underlying NMS. Direct Interaction with Network Elements. A B A A Figure 2.5: Facing the interoperability issues with in-house developments. network while lowering costs. This integration highly contributes to capital and operational savings due to the reduction in the number of network elements, space occupation, and energy consumption. It also leads to simplification of the network by eliminating Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) boxes. Furthermore, it provides inherent protection capabilities, due to the knowledge shared between layers, as IP devices can monitor the optical path. However, the final goal for full multi-layer integration assumes support of the control plane to complete cross-layer network provisioning and monitoring—we will delve into these aspects in the following section. 2.2.3 Control Plane Technologies Several network device suppliers already provide Generalized Multi-Protocol Label Switching (GMPLS) support in their carrier-grade equipment (e.g., Huawei’s OptiX OSN 9800, Juniper’s M-series or Cisco’s CRS-1/3), and some carriers have even fostered the early adoption of this technology. For instance, the major operator in Japan, namely, NTT, has been a leading promoter of the GMPLS technology [61]. Despite these advances, technologies such as GMPLS are still not widely deployed in practice [62]. The true fact is that telecom providers are not under a big pressure for deploying GMPLS—at least not until the latter acquires more momentum. This means that, in the meanwhile, IPoDWDM solutions are restricted to scenarios where mainly manual transport paths are established, arising clear interoperability issues between layers. Indeed, the proprietary nature of most IPoDWDM solutions, conditions the network infrastructure in many cases to mono-vendor settings. Integrated management under this particular scenario would be restricted to end-to-end provisioning for a single-vendor solution. In addition, signal compatibility is also a limitation of these solutions, since standardization efforts are still required to ensure a perfect match between transponders and transport equipment. Accordingly, the value of these solutions is limited in scope to signal compatibility and interoperability constraints. The lack of standardization at the signal transmitted by the transponder is an important issue in the integration of transponders at the IP/MPLS cards [56]. There are some standardization efforts at the ITU G698.2 [63] to solve the problems of the so called “Black Link”. A Black Link is defined as a link where the transponders (source and destination) and the intermediate optical equipment may be from the same or from different vendors. This standard defines the signal parameters for the input and output interfaces in such network. There are two different kinds of wavelength connections: (1) “Friendly Wavelength” and (2) “Alien Wavelength”. A Friendly Wavelength is a lambda connection not created in the optical system, but it is known and managed by the optical management system. This Friendly Wavelength may be created by a router, but the optical management system exchanges information with the router to know the status of the connection. Usually this is done in mono-vendor solutions with virtual transponders from the optical management system point of view. On the other hand, an Alien Wavelength is a connection created outside the optical domain (e.g., from an IP Router), but it is not managed by the optical NMS, hence, the DWDM system has no early knowledge of signal parameters (e.g., bandwidth, wavelength). In such scenario, the optical management system is signaled to configure the intermediate OXCs, but it does not have information about the signal quality. Hence, intermediate integrated solutions open new issues such as the optical signal information exchange between the IP/MPLS and the optical management systems. Overall, IPoDWDM strategies have been driven by several device manufacturers (e.g., Cisco, Juniper and Alcatel-Lucent) setting the trend of next generation networks. Whether the management of a network with IP/WDM integration with coloured interfaces is simpler than todays network management is still an open issue, as most routers do not deal with transport specific issues and some problems are still open to resolution. 2.3 New Trends in Multi-Layer Network Management and Challenges Faced Aside from the strategies traditionally deployed by service providers to face the MLI and MVI problems, recently, new trends have emerged in the field of multi-layer network management. These solutions follow one of two lines. They either represent new ways of approaching the multi-layer network management problem [64,65] or they feature new emerging technologies [37,66], which demand new forms of interaction and pose different challenges from the management point of view. While service providers pursue new trends for targeting the convergence of IP and Optical layers, research efforts shall consider all the newly emerging challenges and complexities in order to enable interaction between layers at the highest level of abstraction. Thus, solutions within the scope of multi-layer network management should provide the flexibility for delivering true full systems not compromised to specific technologies. To this end, we present an analysis on new trends in the scope of multi-layer networks. We firstly introduce MPLS-TP a profile of MPLS for transport networks, then we comment on various solutions based on integrated NMSs for multi-layer networks, such as the solution developed by Cyan [64], and finally, we delve into hybrid solutions for achieving IP over Optical integration, e.g., Juniper’s PTX [37] or Huawei’s Hybrid MSTP OSN 7500 II [38]. 2.3.1 MPLS-Transport Profile (MPLS-TP) Multi-Protocol Label Switching Transport Profile (MPLS-TP) [65] has been built as a joint effort between ITU-T and IETF. Its goal is to extend and enhance the concepts of MPLS [67] and create a profile that can be used in the context of transport networks. MPLS-TP not only adds a set of extensions to MPLS, but also disables those capabilities neither required nor consistent with transport technologies. An example of such suppressed capabilities are Label Switched Path (LSP) merge [68], Penultimate Hop Popping (PHP) [69] and Equal Cost Multi Path (ECMP) [70]. These features are removed because they hinder the Operation, Administration and Maintenance (OAM) functions, which are mandatory for transport networks. For example, the PHP functionality, which consists on removing the label at the penultimate hop—i.e., before reaching its destination—would remove significant information required by OAM functions to work accurately. Another major difference between both technologies is that, unlike MPLS, MPLS-TP LSPs are bidirectional, therefore, the forward and backward LSPs follow the same path. This provides the ability to communicate back to the source if any problem is encountered, thus simplifying troubleshooting. In a nutshell, MPLS-TP aims to enable MPLS on transport networks, while keeping their operation as close as possible to already existing transport technologies (e.g., SDH/SONET networks). To this end, MPLS-TP—like is the case of most transport network platforms—is not constraint to conveying IP packets, meaning that, MPLS-TP functionality can be fully provided regardless of the packet-layer technology used. MPLS-TP has been designed to provide a rich set of control plane-independent OAM features. In MPLS-TP all OAM functionalities run inband, hence, OAM packets are sent over the same path of the user payload in the MPLS-TP forwarding plane to manage and monitor the transport network and the services being delivered. Some of the OAM features include, Continuity Check (CC), Connectivity Verification (CV), delay and loss measurements as well as fault notification. An overview of the MPLS-TP OAM framework can be found in [71]. In addition to OAM enhancements, MPLS-TP provides two modes of operation. Firstly, configuration of LSPs based on network management plane technologies, which are usually referred to as “static” configuration (i.e., not based on a dynamic control-plane), and secondly, dynamic provisioning based on control plane technologies (e.g., GMPLS). The main advantage of the former approach is that MPLS-TP networks can be managed through a centralized NMS as in traditional transport environments (e.g., in Reconfigurable Optical Add Drop Multiplexers - ROADM-based Optical Networks), which makes it quite appealing for network operators who are used to manage and provision their services in that way. The latter approach, suggests the use of the GMPLS control plane to provide automatic setup of MPLS-TP LSPs. For more details on MPLS-TP’s components and its technical specifications the reader is referred to [65,71,72,73,74]. In light of all this, MPLS-TP is foreseen as a technology to leverage traditional transport technology to support packet-based services in a more efficient way, while embracing the features of traditional transport environments (e.g., QoS, centralized operation, etc.). Over the recent years, network device manufacturers and network operators have progressively begun to provide support to standard-based MPLS-TP solutions (e.g., Cisco, Nokia Siemens Networks, ZTE, Verizon, Bharti Airtel, Huawei, Telecom Italia, China Mobile, etc. [75]), while early applications have already been discussed and deployed. Service Providers are considering the migration of traditional SDH/SONET networks to packet transport technology. Along this path, MPLS-TP appears to be a well-suited technology to overcome the inefficiency of these networks when transporting packets— basically due to constant bit rates even in the absence of traffic. Indeed, plans for deploying dynamic MPLS-TP over OTN/DWDM in Verizon’s core network were reported in [75]. The goal was to provide connectivity to edge services by interconnecting Ethernet and IP/MPLS domains through MPLS-TP. Furthermore, MPLS-TP has been considered a candidate for replacing Ethernet in the access network. Data plane compatibility between MPLS-TP and IP/MPLS could make interoperability with the backbone of large ISPs rather simple, while providing end-toend OAM. In this context, the selling point is that by deploying MPLS-TP—along with already existing deployments of IP/MPLS—ISPs will have simple and consistent ways of provisioning and managing their networks edge-to-edge. However, technical comparisons in 2012 between both technologies seem to favor Ethernet, claiming that MPLS-TP still lacks of maturity and security to yet dominate access networks [76]. If MPLS-TP is ready to replace Ethernet or other packet transport technologies in the access or the core network is yet to be seen. Overall, one of the driving forces of MPLS-TP is the possibility of deploying a unified MPLS strategy, wherein ISPs can use MPLS in its different flavors (i.e., IP/MPLS, MPLS-TP, etc.) from core to aggregation and access to improve end-to-end convergence. At the same time, the dual mode of operation of MPLS-TP brings flexibility into the design of transport networks as static configurations may be used while control plane technologies are not yet in place or required. However, the requirements in the scope of network management go beyond the provisioning functionality and instead require even more complex interactions (e.g., scheduling, alarm correlation, and self-healing, among others) to really address the key issues in multi-layer network management. 2.3.2 Integrated Multi-Layer Network Management Systems An integrated NMS for multi-layer networks has been for some time among the research interests of academics [77,78,79] and most recently launched by Cyan under the figure of Cyan’s Multi-Layer Management System (CyMS) [64]. The aim of these solutions is to provide a unified network management plane to effectively manage (i.e., configure, provision, monitor, etc.) multi-layer networks regardless of the technological differences. Early works such as [78] and [79] proposed an integrated NMS capable of providing multi-layer connectivity services based on the use of management functions supported by single layer control plane technologies—whenever available. This approach mainly focused on supporting basic configuration management functions to provide end-to-end IP connectivity derived from Service Level Agreements (SLAs). In addition, some of the same authors devised a policy-based architecture [80] supporting security policy definition, storage and enforcement. Moreover, the authors in [77] developed a prototype implementation of an integrated platform based on standard technologies, to address the issues of multi-layer network management. In that research initiative, the authors defined their own XML-based management information modeling language, adopted a new XML-based management protocol and developed mediation modules to interact with legacy protocols (e.g., SNMP). They also featured policy-based management capabilities while providing an open interface through which basic support to services was provided. That prototype was assessed under a simulation environment to prove support to multi-layer network optimization tasks, fault management and restoration functionality. Beyond the scope of research, Cyan has actually commercialized its product release of an integrated network management solution, namely, CyMS. CyMS provides a software solution for integrated three-dimensional view of the physical and logical connections in all network layers. It is adapted and designed to comply with TMF Multi-Technology Network Management (MTNM) and ITU G.800 principles [81]. Additionally, it features three-dimensional heat maps for enabling proactive network monitoring and control, while gradient-color coding indicates the existence of critical conditions—for instance, for anticipating future faults or service degradation. Indeed, CyMS provides enhanced functionalities for Cyan-compliant devices. However, its potential and dynamics is limited to its own optical gear. This proprietary solution is restricted in scope to multivendor environments, a fact that makes it an unsuitable solution in the context of most common and heterogeneous network deployments. The constrained multi-vendor reach also contributes to high costs of maintenance and updates due to new technologies or requirements. 2.3.3 Hybrid Node Several hybrid solutions drawn from industry and academia have emerged in the field of multi-layer networks [37,38,82,83]. The Juniper PTX converged supercore [37] unveiled on March 2011 is Juniper’s hybrid solution to multi-layer networks. Juniper’s PTX stands for “packet transport switch”, and, unlike the IPoDWDM solutions described earlier in Section 2.2, this hybrid approach takes integration a step further by combining optical and electronic technologies in a unique box. The combination of hardware and software to develop a single hybrid solution aims to provide integration of IP/MPLS and optical control and management planes. This integration allows to enable coordinated provisioning, planning and modeling, avoiding traditional duplication of management functions. This transport strategy assumes that IP and Optical layers will no longer be isolated ecosystems. In this sense, Juniper’s PTX points in the direction of an integrated approach for multi-layer network management. The convergence of packet/optical layers within a single platform derives in seamless integration of their control planes based on GMPLS technology and User-Network Interface (UNI+), which facilitates multi-layer provisioning, management and restoration. However, an integrated approach aligned to the foundations of Juniper’s PTX converged supercore has a number of limitations: (i) integration is constrained to a single vendor—at least with current available technology, hence not solving the MVI problem; (ii) it represents a disruptive approach which requires of new network infrastructures; and (iii) ISPs will of such computation, the NMS is able to request the VNTM to create a new connection. The interface to request a connection is not currently described or defined in any RFC (this is why we represent the interface between the NMS and the VNTM in Fig. 2.7 with an interrogation mark). In [84] a TMF standard interface is proposed, while authors in [92] propose the utilization of the PCEP protocol with a new message to suggest a new route to the VNTM, so the VNTM can decide, based on its policies, if creating the connection or not. Based on the previous definition of the VNTM, the virtual TE link creation is done from the source IP/MPLS router to the destination router. This means that the VNTM must have information not only about the lower layer, but also about the interlayer connections between the IP/MPLS routers and the OXCs. However, automatically building and accurately keeping updated the inter-layer connections remains an open issue. State-of-the-art protocols, such as the Link Management Protocol (LMP) [109], offer palliative solutions. This point-to-point protocol, defined by the IETF, is used by GMPLS devices to feature link discovery, i.e., determine data plane connectivity of network nodes to and from its neighbors. Link verification and fault isolation are also featured by this protocol to check on the status of links and to isolate faults that may occur, respectively [110]. Nevertheless, LMP is not widely used by ISPs mainly because current deployed multi-layer networks do not provide full integration of GMPLS technology. Actually, in practice most ISPs remain relaying on databases, most of which require human intervention for feeding and updating inter-layer topological data. In summary, the emergence of management subsystems was envisioned to simplify and partially fulfill a set of management functionalities that were not covered by existing PCE NMS VNTM LSR H1 LSR H2 LSR L1 LSR L2 LSR H3 LSR H4 PCEP ? Figure 2.7: Another example of a PCE/VNTM configuration with a VNTM entity embedded within the NMS. IP Layer Transport Layer IP + Optical Transport Transport Layer IP Layer IP-NMS Mediator (a) Integrated Network Management (b) Coordinated Network Management Integrated ML-NMS Integrated ML-NMS T-NMS Figure 2.8: Integrated vs. coordinated approaches for multi-layer network management. solutions. This makes mandatory to consider the integration and future requirements of third-party subsystems in multi-layer management infrastructures. 2.5 Future Trends in Multi-Layer Network Management 2.5.1 Coordination vs. Integration Integrated and coordinated approaches both offer a path for addressing current multilayer network management challenges. The integrated approach (cf. Fig. 2.8a) proposes to unify the two separate NMSs into a single entity, enabling management automation and reduction of OPEX. This figure shows two possible configurations. In the first one, the IP and Optical devices are part of separate layers—as in traditional multi-layer deployments—but their management planes are unified under a common NMS. In the second configuration, the IP and Optical equipment are integrated into a single box with a unified management plane. Examples of the former are the integrated control plane and management plane frameworks [64,77,78,79], and for the latter, the case of Juniper’s hybrid node [37]. Unfortunately, these approaches pose complex challenges both technically and operationally. For instance, multi-layer network management issues cannot be fully addressed by the integration of network control planes per-se, as they do not fulfill all management competencies. Therefore, under this scenario, the management planes of both layers would also require a level of integration; otherwise, cross-layer service management operations (i.e., provisioning, monitoring, alarm correlation, scheduling, etc.) will not be possible. Furthermore, the integration of network management systems aggregates a measure of disruption. More specifically, the integration of the IP Network Management System (IP-NMS) and Transport Network Management System (T-NMS) entails a change of perspective in current carriers’ practices, and therefore, a major investment must be done to acquire and adapt to the new management environment. The traditional separation between the IP and transport network layers has demonstrated significant resistance to such a game change, given its implications on the operational, functional and business strategies. Moreover, a successful network management integration can only be useful for a single domain, since domain administrators are reluctant to sharing performance information about their networks. In light of all these limitations, coordinated network approaches (cf. Fig. 2.8b) are positioned as reliable solutions for multi-layer network management. Coordination of cross-layer network operations can help not only to reduce operational and capital expenses, but also to significantly simplify operational processes and reduce administrative burdens. A coordinated approach is based on the idea of a mediator system (shown in Fig. 2.8b) capable of overcoming the barriers of protocol differences and network equipment heterogeneity. A mediator can address the MLI and MVI issues without requiring major changes in network practices or the technologies currently being used by network operators on both layers. Additionally, the coordinated approach can easily be adapted to meet future application demands, as its adoption does not cause any disruption to current network practices. One emerging initiative in this direction is the ONE Adapter [111], a solution for enabling interoperability in a coordinated fashion. The ONE adapter is based on a mediator model, which has been designed to operate between the IP/MPLS and the transport layer NMSs. It allows system automation and coordination of cross-layer network management functions. This initiative proposes a non-disruptive solution that only requires to interface with the IP-NMS and the T-NMS. Furthermore, it does not require changes ro current carriers’ practices. The ONE adapter is particularly useful for management actions such as coordinated self-healing, coordinated IP traffic offloading, and coordinated service provisioning. The ONE approach also allows coordination of network management functions in a multi-vendor environment, thus addressing the MVI problem as well. One of the key features in ONE is its ontology-driven nature, which enables syntactic adaptations based on shared semantic knowledge of different vendor spaces. Table 2.2 summarizes the advantages and drawbacks of coordinated versus integrated multi-layer network management. Approach Advantages Drawbacks Integrated •It reduces the management and operational costs. •It centralizes management tasks (single point of operation). •It provides overall view of the multilayer network infrastructure. •It requires big changes in the network structure and in current practices. •It is hard to adapt to meet future application demands. •It hardly deals with multi-vendor interoperability issues. •Its adoption disrupts the networks’ regular activities. •It is difficult to deploy. •It requires to be integrated in all layers. •It has high deployment costs. Coordinated •It requires neither big changes in the network structure nor in current operational practices and business workflows. •It can be easily adapted to any type of environment to meet the future application demand. •It can easily deal with the multivendor interoperability issues. •Its adaption does not disrupt the networks regular activities. •Its deployment is easy and needs only to be interfaced with the IP and the transport NMSs. •It allows functionalities, which do not exist in the control plane frameworks. •Its functions are domain and layer independent. •Cannot directly manage the networks nor it can make changes to the IP layer or the transport layer without the intervention of the NMSs at each layer. •Its normal workings depend on the responsiveness of third party systems (e.g., PCE) as well as the IP and the transport layer NMS. Table 2.2: Advantages and drawbacks of integrated vs. coordinated multi-layer network management solutions. 2.5.2 Enabling Technologies for Coordinated Approaches In addition to the numerous advantages and benefits that a coordinated approach can provide to address the MLI and MVI problems in the context of network management, we have identified a number of emerging technologies that can assist in the implementation of truly coordinated platforms. Beyond the scope of traditional mechanisms for network management, there are a number of technologies capable of enabling enhanced functionalities to this critical area of networking. MTOSI [46], NETCONF [10], semantic approaches and OpenFlow [112] are among the most relevant enablers for providing support to the field of multi-layer network management. Despite the fact that some of these technologies (e.g., semantic technologies and OpenFlow) were not initially designed for the purposes of network management, they have an interesting potential that can ease and address the management interoperability gap in multi-layer and multi-vendor settings. In this section, we will provide insights on the potential integration of these technologies in order to understand what makes them appealing for their applicability in the area of coordinated Multi-Layer Network Management (MLNM). It is worth highlighting that given the impact of OpenFlow, this technology will be further analyzed in Section 2.5.3 as part of the Software Defined Networking (SDN) umbrella. NETCONF To fill the existing gap in the configuration of IP network equipment, in early 2003 the IETF created a working group to define and develop a standard configuration protocol. The result of this effort is the Network Configuration Protocol (NETCONF), specified in [10] as an IETF standard. NETCONF was defined to cope with the needs of providing configuration state maintenance, transactional-safe operations across multiple devices, separation of configuration from operational data, concurrency, consistency, and support to multiple configurations, in a standard and easy way of use. This set of requirements gather the most remarkable characteristics of CLI-based mechanisms along with the desired features of network providers in the scope of configuration management [113]. Some of the key features of NETCONF are: (i) the ability to distinguish configuration data from operational data, i.e., variables that can be set by the administrator from statistics, alarms, notifications, etc.; (ii) support to transactions, meaning that, it ensures completion of configuration tasks—not only on a device basis but even, on a network basis—otherwise, rollback operations are automatically performed; (iii) transport protocol independence; (iv) support to configuration locking; and (v) filtering mechanisms that enable selected retrieval of configuration data [12]. Most importantly, NETCONF features automated ordering of operations, which means that the complexity of task sequence ordering is pushed from the operator’s side into the device. Its design is flexible and extensible enough to be implemented and deployed by all vendors. Note that this is not an advantage over other protocols, such as SNMP, but is a must if NETCONF intends to become a widely adopted standard. The complexities of SNMP and the proprietary nature of CLI-based mechanisms, have pushed toward the initial implementation of NETCONF in IP/MPLS vendor’s equipment (e.g., Juniper and Cisco) as a means to guarantee the performance of the configuration procedure. The inclusion of NETCONF will enable operators to deal in a standard and reliable way with multi-vendor infrastructures, significantly decreasing OPEX. However, as exposed earlier in Section 2.1.2, the definition of network management information within NETCONF raises clear interoperability issues that still represent an important limitation to its wide acceptance and deployment. Most recently, YANG [13]—the IETF’s proposal for a standard data model—has become the strongest candidate for the formal representation of network configuration management information. It provides well-defined abstractions of the network resources that can be configured or manipulated by a network administrator, including both devices and services. Currently, the IETF is working on the definition of standard YANG modules, to which vendors are expected to comply with in the future. To date, several internet-drafts have been introduced for the definition of the interface, IP, routing, SNMP and system management data models [114]. However, there is still a long path before NETCONF and YANG become mature technologies and established as the default standard for IP network management configuration. Though, the future of NETCONF and YANG is promising and the interest of network device vendors is growing, almost eight years after its initial proposal, CLI-based mechanisms continue to be the preferred way for configuring network devices. For this reason, and based on the fact that a solution is required for current network settings, we envision semantic technologies as a promising enabler for the integration of dissimilar protocols in the scope of network management. We proceed to briefly describe the potential of these technologies in the scope of a coordinated platform dealing with heterogeneous protocols. Semantic Adaptations Semantic adaptations serve as a promising approach for enabling future coordination of multi-layer management. When combined with current available technologies (e.g., ontologies, data mining, artificial intelligence, natural language processing, etc.), semantic approaches can provide the means for achieving true interoperability in the configuration management of multi-vendor environments. The benefits that semantic approaches can provide go beyond the scope of seamless device configuration, and can be devised for any other scope in which the existence of diverse protocols or mechanisms lead to heterogeneous scenarios. They provide an evolutionary solution to current MVI problems through an intelligent, flexible, and extensible approach. Semantic adaptations can thus improve and enhance the experience Common Communications Vehicle - TL1 SNMP SNMP SNMP Figure 2.9: MTOSI reference architecture example (adapted from “Framework DDP BA TMF518 FMW Version 1.2” [1]). of the final user, abstracting network managers from the particularities of each language or format, thereby removing the complexity that is left in the hands of operators (which is error-prone and highly restricts the level of automation of management tasks). Semantic technologies can be combined with machine learning techniques [115] to develop software agents capable of semantically and syntactically adapting configurations for easing tasks in multi-layer and multi-vendor environments. In the literature, several research efforts can be found aligned with the use of semantic technologies to address the problems inherent to the network management domain [116,117,118,119]. For example, in [117,118] H. Xui and D. Xiao consider the application of ontology languages to bring intelligence into the network management plane to enable automated configuration. Authors propose a general model in which three ontology-related languages are considered. They propose, firstly, the Ontology Web Language (OWL) [54] for modeling the domain knowledge, secondly, the Semantic Web Rule Language (SWRL) [120] to add behavior information—such as axioms and constraints—and finally, OWL-S [121]— a semantic markup language for Web Services—to automate the execution logic based on the use of Web-Services. In short, authors envision the use of Semantic Web Services for automation of network management and propose standardization of network management information on this basis. Moreover, in the work led by J. L´opez et al. in [119], authors thoroughly analyze and compare several management information definition languages on the basis of their semantic expressiveness. The goal is to integrate different management models based on ontological mapping and merging techniques to create a global management ontology encompassing a huge set of information models (e.g., Structure of Management Information version 2 - SMIv2, Managed Object Format / Common Information Model - MOF/CIM, etc.). Finally, A. K. Y. Wong et al. [116] proposed a generic ontology-driven solution to the interoperability problem in network management. In this approach, ontology concepts are matched based on the similarity measure obtained through a novel function developed by the authors. As seen, semantic technologies have already been considered in previous research studies to address the interoperability issues in network management as well as in many other fields (e.g., health care, product design, biomedicine, etc.). Nevertheless, there are still many open research lines that must be explored in order to exploit and properly use the resources offered by device manufacturers. MTOSI In the field of optical transport networks, MTOSI [46] has emerged with great force as a technology for enabling standard communication between multiple OSS (e.g., Element Management Systems, Network Management Systems, Service Activation Systems, Fault Management Systems, etc.), covering both service and resource management. This standard has been specified by the TeleManagement Forum (TMF) to provide a common interface to manage multi-technology networks. It is an XML/Web Service-based interface, that is independent from the underlying transport technology. MTOSI enables interoperability between the Service, Network and Element Management Layers of the Telecommunications Management Network (TMN) layering model. The general specifications of the interface maintain that MTOSI will be used between OSSs within the same administration [1]. Hence, it covers the interoperability requirements of current Service Providers which use multiple management systems to manage complex multi-vendor and multi-technology networks. To illustrate the MTOSI reference architecture let us consider the example shown in Fig. 2.9. This figure provides a view of the communication between different OSSs enabled through MTOSI at different levels. The interaction between the management systems is done over the Common Communication Vehicle (CCV). As depicted in the figure, in typical network settings (i.e., a multi-vendor scenario) a NMS—or other type of OSS—directly connected to the CCV can be at the same time managing underlying Element Management Systems (EMSs), which in turn manage network elements of a single vendor based on other management protocols (e.g., SNMP, TL1, CMIP, etc.). For this example, a Fault Management System providing an MTOSI-based interface can retrieve inventory from an Inventory OS to effectively fulfill its management functions. During the last few years, MTOSI seemed to become the future standard for enabling interoperability between OSSs in the transport layer. This web-based interface was positioned as a rather appealing technology for overcoming the limitations in the scope of network management. However, a change in perspective in the field has made MTOSI lose momentum and instead, attention has turned most recently to Software Defined Networking (SDN), a new emerging technology with the power for taking the management solution to the next level. SDN has become an increasingly popular concept whose potential certainly opens the field for research and innovation. For this reason, in the next section we will provide insights on SDNs capabilities and on the challenges from a management point of view. 2.5.3 Software Defined Networks (SDN) We could say that Software Defined Networking (SDN) is the current fulfillment of an old-time promise: providing the possibility of programmability of network functionalities, while offering a clear path for network management to follow the same direction of other Information Technology (IT) fields toward virtualization. The idea of a flexible real-time control of network functions has been considered several times in the past, with proposals ranging from the use of “programming packets” to transmit the desired behavior to network boxes, up to the implementation of adaptive control both in software and hardware. However, the combination of radical decoupling and open interfaces that constitutes the kernel of SDN is a novel proposal that has gained a strong momentum, especially, with the advent of a protocol that demonstrated the feasibility of this approach, and allowed the deployment of real-scale SDN-based networks: OpenFlow [112]. The complexity and lack of flexibility of standard network devices has made network experimentation and innovation highly difficult at all scales for academic researchers. Any change to the software embedded in each device had to be coordinated between vendors in order to make the distributed control algorithms interoperable. Therefore, evolving at the pace required by research and experimentation was extremely difficult. In this context, OpenFlow was born as a cornerstone. The first step was to develop the ability to program switches from a remote controller. Realizing that this implied external software-based control of the data plane, bypassing traditional L2 and L3 protocols and associated configurations, was a natural consequence. Software Defined Networking relies on two main assumptions. The first is a radical separation between the control and the data planes, located in two (most often physically) independent entities: the controller, in charge of the control plane, and the switches, responsible for the functions in the data plane. The choice of singular and plural in the definition above is completely intentional: although not required by the model, the obvious deployment consists of a single controller taking care of several switches in a certain realm. The second assumption is the availability of an open protocol between controllers and switches, allowing for a free combination of elements from different vendors to provide network functions, and of an open interface to the control plane, so the controller can be uniformly accessed by other components participating in the network, such as sources of network intelligence or applications in general. The most widely deployed SDN protocol, OpenFlow, is based on the definition of rules from the controller to be applied by the switches when receiving packets. Rules are fired by matching certain parts of the packets (or the path they arrive through), and contain actions to be applied to those packets, such as forwarding them to a certain path, making some changes to them, or even discarding them. In summary, in SDN control decisions are taken by a central element, while switching decisions are actually applied by distributed elements. A common protocol allows the controller to communicate its decisions to the switches. Having this central element translates into the possibility of abstracting the network into a single element, as it becomes the one in charge of the whole network behavior. Furthermore, the common protocol acts in a similar way to a processor instruction set controlling its registries, processing units and peripherals, and therefore the network becomes a programmable entity, suitable to be controlled in the same way as any other element in the whole computing infrastructure. A general architecture for SDN-based network management is proposed in [122] (shown in Fig. 2.10), where an SDN Mediator communicates with applications and services, and translates requests to the physical network components. This mediator relies on a database containing network topology and component information, and it is able to provide a fully virtualized view to applications and services. The mediator controls several processes: •Discovery. It enables the SDN users to discover and register to the Service Mediator. As a part of the discovery process, the SDN users may negotiate capabilities with the service mediator. •Provisioning. It allows the Service Mediator to provision the underlying network resources. While in principle the provisioning process should rely on OpenFlow, it is conceivable the use of other protocols to create or adjust traffic engineering connections. Obstacles Paths toward Solutions Lessons Learned Segmentation of Standardization Bodies •For instance, MPLS-TP [72]. Solutions to multi-layer issues require of standardization bodies behind each domain (i.e., IP and Optical) to be aligned and to develop joint efforts to generate fully-compliant requirements and solutions to both technology layers. An example to this, is the MPLSTP technology which begun as an ITU-T effort under the name of TMPLS. However, IETF—the developers of MPLS standards—determined a set of inconsistencies between T-MPLS and native MPLS. They requested to extend the IETF’s MPLS technologies to packet transport networks through the IETF Standards Process in a joint effort between both parties to consolidate a solution aligned to the IETF standards and fulfilling ITU-T requirements. High Operational and Capital Expenditures for managing Multi-Layer Settings •Network Functions Virtualization (NFV) [136] and Software Defined Networking (SDN) [122]. •IPoDWDM solutions integrate transponders directly into the IP routers enabling IP equipment to transmit ITU-compatible coloured wavelengths directly to the optical gear. IPoDWDM solutions claim to reduce costs generously due to simplification of the network, at the cost of moving lower layer complexities to the upper layer, since routers have never had to deal with wavelength issues. This is somehow debatable as an assertion of this type depends on many factors (e.g., is implementation-dependent). Anyway, newly emerging solutions require to lower OPEX and CAPEX while maintaining the simplicity of network operation. Moreover, featured virtualization functions are undoubtedly of huge interest for ISPs, and will potentially contribute to significantly lower costs (CAPEX), while the benefits that SDNs technologies bring along to the field of network management will impact on the OPEX. Table 2.3: Obstacles and pitfalls, paths toward solutions, and lessons learned for managing multi-layer and multi-vendor settings. Chapter 3 Internet Addressing This chapter aims to provide insights on the most prominent issues of the current Internet Addressing architecture and briefly introduce existing proposals on ID/Locator Split Architectures (ILSAs). 3.1 IP-Based Addressing Scheme Since the early days of networking, IP has been the absolute protocol supporting both routing and addressing on the Internet. Regardless of the well-known limitations of the current IP-based addressing scheme, the research community has put more attention in routing, with special focus in the inter-domain area rather than addressing [138] [139]. This research trend has actively promoted routing on top of addressing even with the awareness of the exhaustion of the IP addressing space [140]. Next, we will review the limitations of the current IP-based addressing scheme. 3.1.1 Limitations The current IP-based addressing scheme carries along a number of limitations which significantly hinder the deployment of new applications and services in the Internet. These limitations are mainly related to (i) the depletion and (ii) the semantic overload of IP addresses. The former is mainly motivated by a design limitation and refers to the availability of the addressing space—taking into consideration the fact that the current IPv4 address space has nearly reached its limits [140]. The later is motivated by the lack of decoupling of location and identification, i.e., the two-fold functionality of IP addresses which clearly imposes a burden on the current Internet routing system. Accordingly, 59 these issues have an important impact over (i) multihoming, (ii) traffic engineering, (iii) mobility and (iv) resilient communications. Multihoming is a common practice which significantly boosts the geometrical growth of the routing tables. This strategy is based on the notion of connecting a client (i.e., a computer or device) to more than one network, enabling fault tolerance capabilities and load balancing. In order to support multihoming, a site (i.e., an Autonomous System) obtains a Provider-Independent (PI) or Provider-Aggregatable (PA) prefix from its ISP, and further announces them through all its providers. PI and PA prefixes are blocks of IP addresses assigned by a Regional Internet Registry to a site. The main difference among them is that PA prefixes—unlike PI’s—cannot be reused in the case that a site changes ISP. A multihoming site using PI addresses allocates its prefixes in the forwarding and routing tables of each of its providers. Therefore, PI prefixes are not aggregated. In the case of PA prefixes, the Internet Provider of a site could aggregate the customer (site) advertisement into a shorter prefix, when advertising the prefix to other customers or peers. In practice, ISPs have to advertise less aggregated IP routing prefixes to the Internet and rely on traditional and problematic longest-prefix match route selection algorithm of BGP [138]. Regarding mobility, as users demand connectivity on the move, addresses change. This change of address leads to significant degradation of the communication’s quality or in the worst scenario service disruption. Notice that, even if an user changes of location, his identity remains the same. hence, while changes on the user location should be only reported to the routing layer, nowadays represent a change in the overall IP address. Despite efforts like Mobile IP—which aim to enable user mobility—the semantic overload remains an open issue. Moreover, resilient communications are also affected by the dual semantics of IP addresses. Consider for instance, a data center with a 1:1 protection scheme—with a set of primary and backup servers in different locations. In the case of failure of a primary server, the network layer will shift all traffic router to the failed server toward the backup server in place. This shift can certainly cause connection disruption. In an effort to overcome the issues stemmed from the current addressing scheme, the networking research community is currently exploring two different lines of work. The first represented by the path drawn by IPv6 and the second clean-slate architectures for network addressing. On the one hand, IPv6 has emerged as an evolutionary solution to the exhaustion of IP addresses. Nevertheless, the adoption and deployment of this technology is hindered by, (i) the operational expenses derived from migrating from IPv4 to IPv6—which requires of serious operational training of the networking staff in addition to firmware upgrades; and (ii) the potential disruptions of network services—which can significantly affect regular ongoing network operation. Furthermore, IPv6 carries with the same issues of semantic overloading. On the other hand, disruptive approaches to the current Internet Addressing scheme— such as that introduced in [31]—offer novel architectures explicitly designed to avoid the issues around IP addresses. Certainly, the risk of clean-slate solutions is related to the deployment of new technologies on top of an operational network–which will likely not allow compromising network connectivity. In light of this, a new line of research has emerged. This new line pursuits a new reference model, the so-called ID/Locator Split Architectures (ILSAs) aimed to decouple the semantics of IP addresses. A solution of this nature brought together with IPv6—or any other addressing scheme targeting the depletion of addresses—could certainly be a suitable solution to the current Internet Addressing problems. Next, we will provide a brief review of the concept of ILSAs and introduce a taxonomy for ILSA schemes. 3.2 ID/Locator Split Architectures (ILSA) The ID/Locator Split Architectures (ILSAs) paradigm has recently emerged as a reference model aimed to overcome the issues of the current Internet addressing scheme. The “ID/LOC” philosophy—earlier introduced by Chiappa in [141]—consists in decoupling the dual semantics of addresses, i.e., separating host location from identification. Under this new paradigm, identifiers are confined to the application layer, and locators to the network layer. Regarding the space of identifiers, its design faces two main challenges, namely, the identifier’s lifetime and format. On the one hand, the lifetime of an identifier [142] basically impacts the number of signaling messages required to update the ID-to-LOC mapping tables. The shorter the lifetime of an identifier, the greater the accuracy of the mapping information, but the larger the number of signaling messages. On the other hand, the format of an identifier can be either flat (i.e., primitive) or partitioned (i.e., descriptive) [143]. The former refers to identifiers lacking of semantics, i.e., no information can be inferred from its structure (e.g., UUIDs Universally Unique Identifiers [144]). On the contrary, partitioned identifiers do have a semantic structure and thus, are user-friendly (e.g., URLs Uniform Resource Locators [145]). With respect to the space of locators, the challenges are related to bind a location entity to both, network topology and support for topological aggregation in an effort to ease routing performance. Moreover, another relevant aspect in the design of an ILSA scheme is the mapping system. The fact that a single entity requires both, an identifier and a locator, translates into the imminent need of a system capable of mapping between IDs and LOCs. In the literature, several mapping systems have been proposed, however, they bring along pros and cons, which directly impact the overall performance of an ILSA scheme. Figure 3.1 introduces our proposed taxonomy for ILSA schemes. This classification shows the ID/LOC generation challenge for three set of schemes, namely, Network-based and Host-based, in addition to, the Control Plane Mapping System. Overall, networkbased schemes refer to those operating at the network level—typically on border routers, hence, no changes are required on the host level (i.e., end-nodes). LISP [20], Six/One [16] and GSE [19] are the most common and well-known schemes under this category. Network-based schemes can be further classified into, Map-Encap and Address-Rewriting schemes (cf., Fig. 3.1). The former category is based on the principle of tunneling— wherein packets are encapsulated to its destination. The later represents those schemes which operate in a similar way to the Network Address Translation (NAT) replacing a packet ID by a locator. Host-based schemes refer to those strictly operating at the host level (i.e., on the endpoints)—hence, no modifications are required at the network level. The main advantage of host-based schemes is that no costs of investment are required in the network. However, software updates are required—which is typically not attractive for software providers. HIP [17] and SHIM6 [15] are the best known examples of host-based schemes currently found in the literature. Another relevant conceptual difference among both schemes is that network-based are confined to a unique ID/LOC space, while host-based schemes have no restrictions on the uniqueness of the LOC or ID spaces. This feature ID/LOC Split Architectures Host-Based Mapping Systems Network-Based DistributedBased DHT-Based DNS-Based RoutingBased Address Rewriting Map-Encap •FIRMS •NERD •Memom et al. (2009) •Harwood et al. (2003) •LISP-TREE •Sirer et al. (2004) •LISP-ALT •LISP-EMACS •SIX/ONE •8+8 GSE •Nat66 •LISP •Ivip •eFIT •CRIO •IPVLX •HIP •SHIM6 •UIP •HRA •ILNP •Pan et al. (2010) •Kafle et al. (2010) •Martinez et al. (2012) Figure 3.1: Taxonomy of ILSA schemes. could be further exploited for scenarios wherein a two-fold location space could be convenient, for instance for global and local routing: or the case of a two-fold identification space, one for virtual objects and another for physical objects. As mentioned earlier, when it comes to the design of an ILSA scheme another high-level challenge is the mapping system, i.e., the bidirectional mapping between IDs and LOCs. In the case of host-based schemes a different level of mapping may be required, for instance, between the various identification or location schemes in place. Furthermore, some schemes handle the mapping system over the data plane, whereas most recent trend is to push the mapping system to the control plane architecture—i.e., completely decoupled from the data plane. The mapping systems are conceptually supported by different technological approaches, namely, Distributed Hash Tables (DHT), Domain Name System (DNS) or routing protocols. The preferred approach is of utter importance in the design of the mapping system as it will tend to inherit the problems of the underlying technology. 3.3 Locator/Identifier Separation Protocol (LISP) 3.3.1 Overview LISP uses IP-over-IP tunnels deployed between border routers located at different domains. The IP addresses allocated to the external interfaces of the border routers act as Routing Locator (RLOC) addresses for the end systems in the local domain. Since an AS usually groups several border routers, the local Endpoint Identifier (EID) addresses can be reached through multiple RLOC addresses. Hence, LISP separates the overall address space into two parts, where only addresses from the RLOC address space are assigned to the transit Internet. Therefore, only RLOC addresses are routable through the Internet, that is, EID addresses are considered routable only within their local domain. In addition, a number of scaling benefits would be realized by separating the current IP address into two different spaces; among them are: •Reduction of the routing table size in the Default Free Zone (DFZ). •More cost-effective multihoming for sites that connect to different service providers. •Easy renumbering when clients change providers. •Traffic engineering capabilities. •Mobility without address changing. The basic idea is that an EID represents an end-host IP address, while RLOCs represent the IP addresses where end hosts are located. At border routers EIDs are mapped into RLOCs, following a map-and-encap scheme, a basic mechanism of a LISP architecture. The scaling benefits arise when EID addresses are not routable through the Internet — only RLOC addresses are globally routable, allowing efficient aggregation of the RLOC address space. Recent studies show that LISP offers some key advantages. Data plane performance is described on the example shown in Figure 3.2. When the local end host S with EID address 190.1.1.1 wants to communicate with end host D with EID address 200.1.1.2 in a different domain, the following sequence of events occur in LISP: 1. The first step is the usual lookup of the destination address ED in the DNS. 2. Once ED is obtained, the packets sourced from ESource traverse the domain and reach one of the local border routers. In LISP the latter are referred to as Ingress Tunnel Routers (ITRs). 3. Since only RLOC addresses are globally routable, when an ITR receives packets toward ED, it queries the control plane to retrieve the EDestination-to-RLOC mapping. 4. After the ED-to-RLOC mapping resolution, the ITR encapsulates and tunnels packets between the local RLOC address (ITR address 3.3.3.2 in the example) and the RLOC address retrieved from the mapping system, the Egress Tunnel Router (ETR) address in LISP terminology (either 4.4.4.2 or 10.0.0.2 to ED depending on the mapping). 5. At the destination domain, the ETR decapsulates the packets received through the tunnel and forwards them to ED — which, as mentioned above, is locally routable within the domain. From the first packet received, the ETR caches a new entry, solving in this way the reverse mapping for the packets to be tunneled back from EDestination to ESource. Despite the benefits of deploying the LISP architecture, the proposals for the LISP control plane present major challenges. These challenges lie in the fact that since EIDs are not globally routable through the Internet, a mapping system is necessary between EIDs and RLOCs. LISP does not specify a mandatory mapping system, and as a consequence, different proposals can be found in the recent literature, such as ALT [15], NERD [16] or Map Server [17]. Besides, in [18] we introduced a new control plane for LISP; the new control plane presents an improvement on three aspects respect to the ITR ITR ITR Source Node Source 1 Source 2 Source 3 ETR ETR Map-and-Cap Provider #1 Provider #2 Provider #n Provider X Provider Y INTERNET Destination Node 10.0.0.2 9.9.9.2 5.5.5.2 3.3.3.2 Source EID:190.1.1.1 Destination EID:200.1.1.2 Provider EID prefix 190.0.0.0/20 Source RLOC 3.3.3.2 Destination RLOC 4.4.4.2 Source EID 190.1.1.1 Destination EID:200.1.1.2 Provider EID prefix 200.0.0.0/20 190.1.1.2200.1.1.2 Source RLOC 3.3.3.2 Destination RLOC 4.4.4.2 DNS entry. D abc.com A 200.1.1.2 5.0.0.0/20 3.3.3.0/20 X.X.X.X/N 9.0.0.0/20 10.0.0.0/20 Figure 3.2: LISP Fundamentals - Example [2]. existing solutions; (i) firstly, “First packets drop problem” when an ITR does not have a mapping for an EID-prefix; (ii) secondly, potential increase in the latency to start a communication due to the mapping resolution; and (iii) in order to avoid a two-way mapping resolution, the ITR is used as the local ETR for the packets sent from D to S. The latter introduces limitations in terms of inbound Traffic Engineering, especially, when outbound and inbound traffic policies do not match. Despite these improvements there are other issues relating to reachability and reliability that have not been resolved, such as those motivated by an inter-domain link failure. Chapter 4 Semantics and Information Extraction This chapter aims to review the fundamentals of Information Extraction (IE) and most importantly, of the sub-field of Ontology-Based Information Extraction (OBIE) in an effort to unveil the possibilities that this research field offers for automating the configuration of network devices based on Command Line Interfaces (CLIs). 4.1 Traditional Information Extraction (IE) Information Extraction (IE)—a form of natural language processing—aims to automatically identify relevant types of information (typically, entities and relations) from natural language text. Overall, IE does not attempt a comprehensive analysis of a complete document, but instead, to analyze relevant information—i.e., that of interest to an user or application—and thus, ignore other types of data. The main motivation is to obtain structured and machine-processable facts from an unstructured corpus for further analysis. Information Extraction systems have been extensively applied in many research domains wherein textual resources based on natural language are largely available. Consider for instance an Information Extraction system which takes the Web as source of knowledge to extract economic indicators, determine social trends, etc. Regarding the types of information that can be extracted, authors in [146] distinguish among, entities,mentions,descriptions,relations and events. The entity recognition task refers to the identification of information units in the text (e.g., names, organizations, expressions of time, etc.). Mentions are direct or indirect references to the same entities—this task typically involves coreference resolution. Description extraction task 66 enables the identification of descriptive information of an entity, relations unveil semantic associations between entities and finally, the event identification task—one of the most complex IE task—refers to events involving entities. Furthermore, the methods for Information Extraction range from rule-based (i.e., manual patterns) to statistical machine learning approaches. The former assumes that models for the IE process are manually formalized by a domain expert, while the later relies on supervised learning algorithms (e.g., support vector machine, maximum entropy, Hidden Markov models, conditional random fields, etc.). According to discussions led by authors in [147] though statistical methods are the most recent trend in IE, both pattern-based and statistical models co-exist and its suitability actually depends on the application and domain-specifics. 4.2 Ontologies and Information Extraction With the advent of the Semantic Web, ontologies have emerged as a new paradigm to formalize the knowledge and meaning of a given domain of interest. According to [148], an ontology is defined as “a formal and explicit specification of a shared conceptualization”. Overall, the use of ontologies enable (i) shared and common reference models of the domain’s knowledge, (ii) reuse of information across application domains, (iii) inference and context reasoning over information, and (iv) data disambiguation. In the field of Artificial Intelligence, most recent knowledge systems rely on ontologies to support the task of Information Extraction—this subfield of IE is best known as Ontology-Based Information Extraction (OBIE). The general notion of an OBIE System is that an ontology provides a predefined model of the information to be extracted. Accordingly, the OBIE system has the ability to link natural textual resources to formal semantic models. Authors in [3] define an OBIE System as “a system that processes unstructured or semi-structured natural language text through a mechanism guided by ontologies to extract certain types of information and presents the output using ontologies.” Overall, the design of an OBIE system poses two main challenges, (i) identifying entities from the ontology in natural language text and (ii) populating the domain ontology, which refers to extracting instances and property values from the text with respect to classes and properties of the domain ontology. According to the study led by authors in [3], the main characteristics of an OBIE System—and which consistently differentiate it from traditional IE—can be summarized as follows: •The system’s input is restricted to unstructured or semi-structured natural language text. Those systems using multimedia content (e.g., any combination of 5.1 The Rationale supporting the OBIE System One of the most relevant aspects of CLIs is that—because of its human (manual) oriented nature—it is largely based on textual resources. CLIs are often large and heterogeneous in content, structure and semantics. However, they provide explicit information— encoded in the form of natural language—aimed to help and guide network administrators in the manual use and interpretation of the configuration environment. Moreover, the hierarchical arrangement of the CLI carries implicit knowledge on the semantic relations between commands. Typically, commands in upper levels create the context for following subcommands, i.e., subsequent levels in the hierarchy are semantically related either because they become specifications or direct properties (attributes) of upper levels. Indeed—with the appropriate tools—this information, both explicit and implicit, could be automatically acquired and transformed into useful configuration knowledge. The notion of automatically extracting knowledge and semantics from already available textual resources has been a field of increased interest among researchers of many other domains—wherein digital information is largely available. Consider for instance, the extraction of information from the Web [158,159,160], newspapers [161], twitter [162], r´esum´es [163], medical records [164], etc., to enable numerous applications, such as, question-answering, decision support systems, word sense disambiguation, etc. In light of this, Information Extraction (IE)—a form of natural language analysis—positions as a promising research path to automatically find and retrieve relevant information from the CLI for configuration purposes. Furthermore, Ontology-Based Information Extraction (OBIE) [3]—a recently emerged sub-field of IE—which incorporates the use of a formal ontology can significantly help to improve the IE process. To the best of our knowledge, CLIs have never been explored from a semantic nor IE perspective in the network management arena. For more background knowledge on IE and OBIE please refer to Chapter 4. From a macro perspective, the design of an OBIE system poses two main challenges: (i) defining a formal knowledge model of the network device configuration domain (i.e., the domain ontology) and (ii) developing a learning approach for IE from the configuration Command-Line. Regarding the first challenge, we have created our own structured knowledge-base of the switch/router configuration space, which we have named, Ontology for Network Device Configuration (ONDC) [165] (cf., Section 5.3.2). ONDC formally specifies the most relevant concepts of the domain and integrates a lexicon of the networking vocabulary. In the context of our approach, this ontology provides a comprehensive and vendor-neutral coverage of the device configuration knowledge. Overall, concepts in the ontology conform to networking standards and well-known technical terminology, reflecting the knowledge of the networking domain regardless of vendors’ specifics. The main motivation for this, is that—apart from proprietary technologies— the vast majority of protocols and features to be set on a network device are common across multi-vendor platforms, otherwise, there would be no means to provide network interoperability. In light of this, configuration capabilities are just about the same for all devices, what essentially changes is the way in which vendors express this knowledge in their CLIs. The differences among CLI-based environments are basically determined by, (i) the granularity of the tree structure, (ii) the arrangement of commands in the hierarchy, (iii) the syntax—e.g., the use of different terminologies for expressing the same concepts—and (iv) the semantics—e.g., the use of the same terminologies for expressing different concepts (i.e., meaning). In light of all this, we require a solution capable of exploiting this information to unambiguously determine the semantics of each space. This leads us to the second challenge, that is, developing an approach for IE which allows to reconcile the differences between heterogeneous CLIs (cf., Chapter 6). Because of the differentiating features of CLIs, we developed a methodology which not only exploits the (explicit) knowledge given in the form of natural textual language, but moreover, we actually exploit the structure of the CLI itself, i.e., implicit knowledge. 5.2 Related Work Overall, in this section we will review related work in the field of network device configuration management. In Section 5.2.1, we will focus on the efforts led by industry and key standardization bodies toward seamless device configuration and briefly discuss on the reasons why initiatives such as NETCONF or OF-CONFIG have failed to fulfill the configuration needs of network administrators. In Section 5.2.2 we will discuss on semantic-based approaches toward configuration management. To this end, we first review approaches for device configuration in non-related networking domains and then those in the scope of networking. We clearly distinguish among efforts for network configuration as a whole and underlying configuration at the network element level. 5.2.1 The alternative path of Industry and Standardization Bodies toward seamless network device configuration As already mentioned, the seamless configuration of network devices is yet far from being accomplished in the networking domain. Based on the limitations of CLI-based mechanisms for the configuration of network devices—in the context of heterogeneous networks—telecom providers have raised their concerns regarding the need of a practical and scalable solution to this largely unsolved issue. The fact that this problem is still in force is mainly because, in the absence of standard mechanisms, vendor’s best interests have imposed. Indeed, proprietary approaches are an effective way of distinguishing from others and keep the lead in a such competitive market. Nevertheless, in the recent years operators’ interest for enabling interoperability in such contexts has pushed toward different lines of work. These efforts have emerged both from industry and standardization bodies. The Network Configuration Protocol (NETCONF) [10] is the most recent effort of the Internet Engineering Task Force (IETF) to develop a standard network configuration protocol. NETCONF aims to fill the gap in network device configuration by featuring state maintenance, concurrency, configuration locking, transactional-safe operations across multiple devices, automatic roll-back and operation ordering, distinction between configuration and operational data and consistency in a standard and practical way of use. The major limitation to the adoption of NETCONF is the lack of comprehensive and widely accepted data models, i.e., absence of standards for network management information definition (e.g., to formally specify interfaces, access-lists, ports, etc.). The lack of a data modeling language pushes the interoperability problem to a new level. Initially, several data models emerged as potential candidates for network management definition [51] [50] [52], but neither of them found a path in practice, either because of their increased complexity or lack of semantics. Other NETCONF implementations were built over proprietary data models which in turn raised clear interoperability issues. Most recently, YANG [13]—an IETF proposed standard—has become the most solid contribution for a common data model language for NETCONF. However, almost a decade later and in spite of initial implementations of NETCONF and YANG, only few YANG data models have found broad acceptance [14] and CLIs continue to be the preferred protocol for network device configuration among network administrators [12]. It is clear that there is still a long path before YANG and NETCONF truly become leading standards in the network configuration arena. Moreover, with network programmability in the spotlight, Software-Defined Networks (SDNs) have rapidly become a major trend in the ICT field. Telecom providers and device vendors concur that SDNs will lay down the foundation for next-generation networks, given their potential for achieving higher flexibility and openness while dramatically reducing costs. A paradigm shift of this nature can clearly transform network management practices, and pave the way for reaching the desired goal of network automation. The OpenFlow protocol [112], and most recently the OpenFlow Management and Configuration protocol (OF-CONFIG) [166], have become key components for controlling and managing SDNs. OpenFlow standardizes the interactions between an SDN controller and the switches under its control. However, it does not provide the functions that are required for configuring queues, ports, assigning IP addresses or any other configuration toward the device. The OF-CONFIG protocol was recently defined by the Open Networking Foundation (ONF) precisely to that end. A crucial part of the OFCONFIG specification is that the configurations are transported on NETCONF [10]— which as stated previously also provides mechanisms for the configuration of devices in traditional networks. Unfortunately, as NETCONF itself has not gained momentum yet, it remains to be seen if it will finally become the protocol of choice [11]. In [167] authors discuss on the potential benefits of SDN and OpenFlow to improve various aspects of network management. They suggest that these technologies cannot only ease configuration through software programmability instead of fixed set of commands but also benefit from centralized management. Undoubtedly, OpenFlow and SDNs are key to improve and ease overall network management [167]. However, its flow-oriented nature makes it unsuitable to resolve basic network management operations. This is the case for configurations targeting the router per se (e.g., setting user access rights, such as a user password, etc.) and not actually things going “through” the router—for which it would be indeed largely effective. Another relevant aspect is that SDN is certainly not necessary for all parts of the network [168]. Moreover, a full replacement of the underlying infrastructure is neither affordable nor feasible for many administrators, which indicates that SDNs will need to coexist and interact with traditional networks for several years. For this reason, hybrid approaches to SDN—a mix of SDN-enabled and traditional network devices—are positioned as strong candidates to ease the transition to new and more flexible network environments [169,170]. Accordingly, legacy infrastructures will continue to play a crucial role in the SDN future, and will likely give place to new challenges and opportunities in the management field. Although OpenFlow and the elementary configurations supported in OF-CONFIG can suffice for managing OpenFlow devices, network configuration tasks clearly entail much more than configuring flows. Consider for instance requirements such as the configuration of user-names and administrative privileges for authenticated access through CLIs, the configuration of a link-state routing protocol (e.g., OSPF), or a switching protocol (e.g. MPLS). Accordingly, the heterogeneity of hybrid SDNs will require of a flexible management model where configurations are not only performed on a per-flow basis. In a different line of work—aside from standards—industry has approached the device configuration issue by developing dedicated software agents as a means to force static mappings between commands of different configuration spaces. The downside of such approach is that it is not scalable in the context of dynamic environments and requires skillful development teams dedicated to update and maintain these static agents. Moreover, to overcome the complexities in network management [9] the research community has also explored the field of semantic technologies from Artificial Intelligence (AI) as a promising path to achieve interoperability in domains where standards have not succeeded. Next, we will review semantic-based research approaches in configuration management. 5.2.2 A semantic-based path toward seamless configuration management Device Configuration in non-related domains Configuration management is not restricted to networking devices and is in fact an essential task to many other domains, for example, the case of configuration in the scope of smart homes, manufacturing, e-commerce or service deployment. There is clear evidence on the use of ontologies and other semantic technologies to address the configuration issue in these domains [171] [172] [173] [174] [175] [176] [177]. It is clear that, due to the inherent differences and dissimilar requirements between domains the configuration issue is approached from different perspectives. Nevertheless, the overall aim is to automate the configuration process by using ontologies to formally represent the domain’s knowledge, as a means to support reasoning and enable reuse of shared conceptualizations. The research work led by authors in [171] [172] introduces a novel holistic system for intelligent Smart Home (SH) environments to support device auto-configuration and intelligent control under energy efficiency requirements. Their solution is based on an ontology framework, capable of providing efficient control logics and intelligent decision making. In addition, they develop a semantic extension to the standard Universal Plug and Play (UPnP) protocol to enable communication capabilities of intelligent devices in the context of SHs. In [173] authors develop a recommender system to support requirement elicitation in a product configuration system. They capture customer requirements represented in an OWL-ontology and assess consistency with respect to manufacturers’ specifications (constraints) represented in the Semantic Web Rule Language (SWRL). It also identifies mandatory requirements yet not specified by the customer and suggest them as a means to complete the configuration of the product. In a similar line of research, the work presented in [175] [176] [177] targets product configuration systems for e-commerce through ontology-based approaches. Moreover, in [174] authors introduce an ontology-based approach for a product configuration system in the e-business field. The aim is to identify customer requirements— expressed in natural language—and output the configuration design of the product that best meets his needs. Herein, three ontologies were developed to represent, (i) customer needs, (ii) product functionalities and (iii) product configuration. Finally, an ontology mapping approach and the use of a Bayesian Network enable automatic conversion between customer needs and product configuration. Indeed, the scope of configuration as targeted in the aforementioned research initiatives differs from the low-level aspect of the configuration issue in network device configuration. However, they unveil the potential of semantic technologies to reconcile the differences in configuration environments and support translation from custom requirements (in our case “custom” CLIs) to common shared foundations of the domain knowledge. Network Device Configuration In the networking domain, several initiatives have also explored the AI path to target network management [178,179,180,181,182,118,183,117]. Given the broad scope of network management and the numerous functions that it entails, many of these solutions approach different aspects of the problem; for example, the need to unify underlying network management data models [182], autonomic network management [117,118], integration of management data [180] or the issue of multi-vendor configuration management [178,179]. Next, we will survey the state-of-the-art in ontology-based network configuration management solutions. To this end, we classify semantic approaches into two groups, (i) ontology-based approaches to network configuration and (ii) ontologybased approaches to network device configuration. The former refers to solutions wherein configuration is devised for the network as a whole, while the later refers to semantic approaches targeting the device configuration issue. Ontology-based Network Configuration Approaches. The approaches grouped within this category abstract from the heterogeneity of device configurations and deal instead with the autonomic configuration of the network—at a higher level [184,118,117]. Overall, the aim of these approaches is to provide the network with self-management and context-awareness configuration capabilities. They propose— in different contexts—the use of semantic technologies to provide a smart environment in which configuration services are triggered whenever a network condition is given. To this end, they combine the use of the Ontology Web Language (OWL) and the Semantic Web Rule Language (SWRL) to model the management information and network behavior, respectively. SWRL enables rule integration into the ontology, so whenever a condition is fulfilled a service is automatically invoked and then executed. In the context of IP networks this service can be represented by a configuration script, which includes the CLI device-specific commands to the requested service. As can be seen, these works are restricted to static device configurations as underlying issues remain unsolved. This means that to ensure scalability and flexibility of their solutions, an approach to resolve device configuration heterogeneity is required. From academia, several works have emerged in an effort to integrate ontologies and other semantic technologies to achieve interoperability at the semantic level. Next, we will review the status of this research field. Ontology-based Network Device Configuration Approaches. Within this category we classify ontology-based approaches to the semantic interoperability problem in network device configuration management. In the work presented in [178], authors propose the use of ontologies to describe a NETCONF workflow. However, with the so-mentioned limitations of NETCONF this solution in neither scalable nor practical. Moreover, in the work presented in [179] authors introduce an ontologydriven approach to the semantic interoperability problem in network management and validate it for the case of multi-vendor router configuration. Their major contribution is a generic similarity-based ontology mapping strategy which can be seamlessly applied across the ITU-T Telecommunication Management Network (TMN) layer model. For validating the configuration use case they built vendor-specific ontologies (one per network vendor), wherein CLI commands where properly modeled and classified. They further applied the mapping strategy to a set of selected commands to assess the semantic match between both configuration spaces. Beyond the limitations of the similarity function and computational methods—pointed out by the authors in [179]—scalability of this approach is an issue, inasmuch as, ontologies for CLI environments are not given by vendors’ in advance. Thus, formal representations of the CLI knowledge must be manually built by domain experts—a task which is per se sufficiently complex and challenging—and continuously updated as new features, vendors or releases emerge. As if that was not enough, the ontology expert would require to gain expertise in the new CLI environment beforehand. The ideal scenario would be to assume that vendors handle ontologies in advance for every CLI, in a similar way as drivers are provided for every device. Nevertheless, this is a demanding requirement which is far from vendors’ roadmap. To the best of our knowledge there are no further efforts in this line. Nevertheless, we firmly believe that ideas from the ontology research arena can still be brought to the CLI configuration domain to achieve interoperability at the semantic level. The semantic interoperability problem in network configuration management requires a solution capable of adapting to the dynamics of current configuration environments in an easy and automated way. Despite of the numerous initiatives regarding the application of ontologies and AI-based techniques to approach network management, the exploitation of semantic technologies continues to be a research challenge. There are still many paths to be explored in order to benefit from such technologies. Moreover, none of these works have explored the field of OBIE as a means to enable interoperability in the network configuration domain. 5.3 The OBIE System Architecture Herein, we present the general architecture of an Ontology-Based Information Extraction (OBIE) System from the configuration command-line of network devices. Figure 5.1 depicts the general architecture of our system. Observe that it takes two inputs, namely, (i) the Command Line Interface (CLI)—as natively provided by vendors (i.e., unprocessed)—and (ii) the domain ontology (i.e., ONDC)—which has been specified by us and formally defines the knowledge of the network device configuration domain. Furthermore, the output of our system is a device-specific version of the target domain ontology, i.e., the ontology populated with instances of the configuration commands. These device-specific ontologies are further stored in a repository to enable potential functionalities to third-party applications, e.g., a Network Management System (NMS) requesting the commands for setting an interface IP address for dissimilar device models. Our system’s architecture is based on a modular design which accommodates several components into two functional blocks, namely, the offline (lower block) and the online (upper block) modes (cf., Fig. 5.1). The offline functionality is responsible for performing the semantic abstraction of multi-vendor (i.e., heterogeneous) configuration environments. Accordingly, the system’s intelligence lies within this mode. The Semantic Learning Engine (cf., Fig. 5.1)—which represents the core module of this functionality—carries the logic and algorithms for extracting and interpreting the information of the CLIs. In Chapter 6we will show how the semantic instantiation of commands is done by thoroughly describing our approach for IE from the CLI. Moreover, the online functionality provides a web-based interface through which users or third-party systems can retrieve semantic-based configurations for heterogeneous (i.e., dissimilar) network devices. In other words, this mode enables access to the semantic models generated in the offline mode, so external systems or applications can benefit from multi-vendor configuration abstraction. To illustrate the online functionality, Online Offline Figure 5.1: General Architecture of the OBIE System for the device configuration domain. consider a system or administrator that must perform the real deployment of an initial network planning strategy, which involves a high number of configurations across multiple devices from different vendors. A process of this nature, could make single requests to our system for each required configuration operation and this would retrieve the commands for each available device model. For instance, request the commands for setting the domain’s name for all available devices in the network. Overall, the offline and online modes aim to mitigate the efforts related to the configuration of devices in heterogeneous environments. The execution of both functionalities completes the configuration cycle, from the semantic definition of the configuration space to the automatic retrieval of commands, regardless of the underlying heterogeneity. 5.3.1 System Modules The basic architectural components of our system are, namely, (1) CLI Parser, (2) Ontology Manager, (3) Semantic Learning Engine, (4) Knowledge Repository, (5) Administration Controller, (6) Request Processor, and (7) Semantic Search Engine (cf. Fig. 5.1). Next, we will provide a detailed description of the main functionalities of each module. CLI Parser The CLI Parser provides the functions to breakdown the CLI into its structural parts, namely, commands (cmd) or variables (var) and help descriptors (hd) (cf., Fig. 5.2). Though all three structural elements are key to derive the semantics from the CLI, it is of utter importance to distinguish between each type, as only commands and variables are target of instantiation. The information provided in the help descriptors will serve to contextualize, disambiguate and identify relevant concepts—which will ultimately assist in the process of semantic instantiation. The fact that “helps” are aimed to guide network administrators on the manual use and interpretation of the CLI makes this information particularly meaningful to our system, as most likely it provides reference to common (standard) networking terminologies—instead of custom and vendor-related ones. All in all, the semantics provided by vendors must converge at some point to standard terminologies, otherwise, their solutions would be unattainable and impractical, and the learning curve expensive. In this sense, helps are with higher chance points of semantic convergence while commands are more likely subject to vendor customization. Although it is an irrefutable truth that networking-related terms can occasionally be misleading, even if helps do not explicitly provide a reference for disambiguation, the context—i.e., information in contiguous levels—can help determine a term’s sense. This feature will be further exploited in our learning approach described later in Chapter 6. The output of this stage is an XML Document which represents the CLI with distinction of its structural components. Figure 5.3 shows a simplified example of the generated XML Document. The XML document consists of a root element “CommandSet”. This element contains two different child elements, namely, “Variable” and “Command”. The “Variable” and “Command” elements contain the attributes, “exec”, which indicates if set protocols mpls hop-limit <hop-limit> cmd cmd cmd cmd var configuration statement set Set a parameter protocols Routing protocol configuration mpls Multiprotocol Label Switching options hop-limit Maximum allowed router hops <2..255> <hop-limit> Maximum allowed router hops <2..255> Help Descriptors (hd) Level0 Level1 Level2 Level3 Level4 Level0 Level1 Level2 Level3 Level4 Figure 5.2: Typical CLI structure. Start End Figure 6.1: Configuration Knowledge Extraction Algorithm (Stage I and II). 6.2 Stage I: Resource Identification 6.2.1 Data Pre-Processor The first component in the IE workflow is the Data Pre-Processor which combines shallow Natural Language Processing (NLP) tools for basic data pre-processing. Overall, Data Pre-processing includes the following resources, namely, (i) Part-Of-Speech (POS) Tagger, (ii) Tokenizer and (iii) Stemmer. The POS Tagger resource allows the identification of verb phrases from the CLI. Notice that in-depth POS analysis is far from being required as typical CLIs lack of grammar rules and verbosity. Accordingly, the information present in the CLI is likely to be short and concise—sometimes even insufficient to be self-explanatory. The lack of verbosity and proper grammar restricts the content of CLIs to (i) concepts (e.g., Level2and Level3in Fig. 6.2) and (ii) verb L0 L1 L2 L3 configure set interfaces <interface-name> unit <interface-unit-number> family inet address <source> configure Manipulate software configuration information set Set a parameter interfaces Interface configuration <interface-name> Interface name unit Logical interface <interface-unit-number> Logical unit number family Protocol family inet Ipv4 Parameters address Interface address/destination prefix <source> Interface address/destination prefix L4 L5 L6 L7 L8 L9 cmd var help Figure 6.2: Example of a router configuration statement. phrases (e.g., Level1in Fig. 6.2). This significantly simplifies the scope of the semantic search. Moreover, the number of configuration actions (i.e., operations) are finite and common across multi-vendor platforms, e.g., set, delete, add, merge, show, load, reset, etc. In our implementation, we have used the Stanford Log-linear POS Tagger [187] for this purpose. The next resource to be applied is the tokenizer which separates data into tokens for further processing. We have used the tokenization tool in the Apache OpenNLP library [188]. Notice that commands are typically expressed with single short suggestive keywords as to ease manual configuration. Nevertheless, in the context of CLIs, we can often find the use of hyphenated words to improve the expressiveness of a command—e.g., “source-port”, “source-class”, etc. In an effort to preserve the semantics of the CLI—in the context of our solution—hyphenated words account as single tokens. Moreover, we remove stop words, i.e., we filter irrelevant words from the CLI data, e.g., articles or prepositions. It is important to highlight the fact that, the number of stop words in our domain is not particularly significant, as commands and variables are single keywords and help descriptors are generally short and concise phrases with poor grammar. However, we have developed a custom list of stop words to avoid returning or processing unnecessary information. The final resource to complete the step of Data Pre-Processing is the Stemmer, which allows to reduce inflectional forms of a word to its common base form. We used the Stanford NLP stemmer (CoreNLP) [187]—which is based on the Porter stemming algorithm. Herein—as done by many search engines— words with the same stem are treated as synonyms. This will improve the performance of our system by increasing the probability of successful hits when performing lexical matching. 6.2.2 Lexical Matching The next step in the algorithm is to perform Lexical Matching, i.e., we make extractions with respect to particular components of the domain ontology. This strategy fits with the general notion that—overall, and despite CLIs heterogeneity—concepts must converge to well-known technical terminologies, otherwise, it becomes increasingly complex to achieve interoperability and moreover, stay competitive in an industry led by standards. Consider for instance, a device vendor using custom terminologies to refer to standard concepts of the networking domain, e.g., an IP address or a networking protocol (MPLS, DHCP, etc.). In such a context, the interpretation of CLIs becomes overly intricate, unless vendors provide mappings to standard terminologies. In light of all this, the notion of CLIs having to rely on technical (standard) terms—at least those likely to be referents in the field—makes lexical matching a feasible strategy to identify key concepts of the domain. Nevertheless, it is clear that in a field full of terminologies and ever-changing technologies, there is still space for syntactic and semantic ambiguity, as typically, vendors use different terms to refer to the same concepts or on the contrary, use the same terms to refer to different concepts. Consider the graph-based representation of the ontology (cf., Fig. 6.3 (a)), the lexical matching stage results in the activation or highlight of nodes and links of the Semantic Graph Gfor every identified entity in the CLI—the notion of “activated” nodes is depicted in Fig. 6.3 (b)). Notice that we admit both, partial and exact matching. If an exact match is found for a given term, partial matches are discarded. In the case for which a term matches several ontological concepts and these are taxonomically related, we hold the Least Common Subsumer (LCS), i.e., the most concrete taxonomic ancestor. In other words, we generalize in the absence of information. To illustrate this, consider Level2in our example. The CLI information for this level is “Interface Configuration”. Accordingly, candidate concepts (lexical matching) will be: hinterfacei,hethernet − interfacei,h100G−Interfacei,h10G−Interfacei, and hinterface −namei. From the ontological structure, we know that these concepts have a subsumption relationship. The hethernet −interfacei,h100G−Interfaceiand h10G−Interfaceiconcepts are subtypes of hinterfacei, while hinterface −nameiis an attribute (i.e., an ontological data property) of the latter. In the absence of information we select the LCS, i.e., we generalize to the hinterfaceiconcept. Moreover, if exclusive properties of a concept are discovered in subsequent levels, we can further select a specification of the concept. This functionality is performed by the inference stage of the Semantic Analysis. Notice that there are cases for which candidate concepts do not have a LCS. In these cases, concepts are considered disjoint, i.e., only one can accurately define the semantics of the given CLI term. Further clustering and semantic relatedness will aid in the disambiguation for these scenarios. To illustrate this case consider the following. For Level8in our example, the lack of verbosity in the CLI can generate ambiguity between the ontological concepts, hmac−addressiand hip−addressi. Although in principle we lack information to disambiguate between both concepts from a lexical perspective, we know in advance that only one can properly define the semantics of the given term. For this reason, we identify them as disjoint concepts and further semantic analysis will allow us to select the best candidate concept. It is important to realize that even if concepts are not identified by lexical matching, mainly because of the use of custom or dissimilar terminologies, while performing Semantic Analysis we can identify relevant concepts by inference. Therefore, we do not make limited use of the ontology—such as names of classes—moreover, we use the ontological structure to enhance our assessment. The Semantic Analysis stage can be further differentiated into, clustering, inference and semantic relatedness computation, as shown in Fig. 6.3. 6.2.3 Clustering and Inference In this step activated resources are grouped into semantic clusters (cf., Fig. 6.3(c) and 6.4). We form clusters between directly connected resources of adjacent levels (e.g., {C2, C3} ∈ G). If an activated resource is disconnected to other active concepts in the graph, it uniquely forms a cluster (e.g., {C1, C4} ∈ G). Notice that the notion of nodes being part of fully interconnected clusters is based on the premise that commands are arranged in the hierarchy by association—i.e., commands become more specific down in the tree structure. Accordingly, the concepts that derive from commands and variables in contiguous levels are expected to be semantically related to a certain extent—directly or not. Ideally, activated resources would form part of a single cluster (i.e., interconnected concepts), however, the degree to which entities are actually related will also depend on the granularity of the CLI—which varies for every vendor. For this reason, clustering is not sufficient and we require other means to measure (i.e., quantify) the degree to which concepts are semantically related, this is part of the relatedness computation stage, which will be described later in this section. Notice that we restrict clusters to non-disjoint nodes. This means that concepts that have been triggered by the same activation keywords necessarily belong to different clusters—even if they are directly connected—as they are (from a lexical perspective) equally likely candidates for the Clustering Inference Semantic Relatedness (a) (b) (c) (d) (e) Decision Maker (f) Lexical Matching Semantic Analysis Semantic Analysis Semantic Analysis Figure 6.3: Semantic Analysis: Step by Step Diagram. C1 C4 C3 C2 Activated Concept / Entity Concept / Entity Cn: nth Cluster C1 ⊕ C4 G G1 G2 Figure 6.4: General Notion of the Clustering Stage. same set of concepts. For instance, consider in Fig. 6.4 resources r2and r8to be candidate concepts for the same set of keywords. Accordingly, clusters C1and C4are disjoint, as only one can fairly represent the semantics of the given term(s) and thus, each belong to a different subgraph—i.e., valid combinations of non-disjoint clusters (e.g., G1 and G2). In further stages, semantic relatedness is computed over each subgraph in an effort to promote closest nodes (i.e., those with higher density) as the most suitable concepts for defining a given configuration statement. Furthermore, we perform semantic inference (cf., Fig. 6.5) as a means to derive knowledge that is not explicitly expressed in the CLI. To this end, we exploit the ontological structure and reason over the facts and axioms formally defined in the router/switch configuration domain ontology. The inference stage has a two-fold purpose. First, to discover potential concepts that were not identified in previous stages, either because of (i) the use of very dissimilar terminologies—i.e., use of a vocabulary which is not well aligned to the domain lexicon—or (ii) because of the granularity of the hierarchy. For instance, for less granular hierarchies, knowledge is most likely to be implicit and thus, concepts can fail to be identified. To illustrate the inference stage, consider the example shown in C1 C4 C3 C2’ C1 ⊕ C4 G Infered Concept / Entity P1 P2 P3 Figure 6.5: General Notion of the Inference Stage. Fig. 6.5. If we identify from the CLI the concepts “hadministrative −distancei” (r8), “hdestination −prefixi” (r5) and “hbandwidthi” (r15), we can infer from the equivalent axioms of the ontology that most likely we are referring to the concept “hroutei” (r9), for which these 3 concepts are exclusive properties. Based on this, we can further activate the inferred resource (r9) and build the semantics of the given configuration statement. The second purpose of this stage is to generalize or specify already active concepts by taking into account contextual information. Consider the following example, if the concept “hrouting−protocoli” has been identified for a given level of the hierarchy and we then identify the concept “hOSP F −areai”, we can infer that we are referring to the OSPF protocol—which is both a routing-protocol and exclusively related to the attribute “hOSP F −areai”. In any of both cases, if this stage results in the activation of a node by inference (e.g., r9in Fig. 6.5) we perform clustering once more to group nodes by direct association (e.g., C0 2in Fig. 6.5). 6.2.4 Semantic Relatedness The rationale of computing semantic relatedness between candidate concepts is to promote closest nodes. This is based on the premise that because CLIs are arranged by association, successive commands in the hierarchy are highly interrelated concepts of the domain. To exemplify this general notion, let us consider the example shown in Fig. 6.6, where the resources “MAC Address” in cluster CCand “IP Address” in cluster CBare candidates for the CLI term “address”. Observe that, both resources—and accordingly, the clusters to which they belong to—are disjoint, as only one ontological class is expected to accurately represent the semantics of the term. From a lexical perspective, the succinctness of the CLI (i.e., lack of information) is what actually leads to the ambiguity between both concepts. However, based on the contextual background, the concept “IP Address” seems to be a better candidate, as it is semantically related to a higher extent to concepts identified in adjacent levels (i.e., higher node density). Overall, relatedness will contribute to information extraction and the identification of potential outliers (command sense disambiguation)—i.e., picking the most suitable sense of the word and constraining the interpretation of terms in our system. In the context of our solution, we define relatedness (R) as a function that computes the strength of semantic association between a set of clusters {Ck} ∈ Gk. Notice that, in contrast to state of the art approaches, Ris not restricted to a given “pair” of concepts, but instead, extends to reflect the proximity in meaning of a “set” of concepts. Typical existing measures of relatedness based on ontologies exploit only taxonomic relations, accordingly, they are more a measure of similarity rather than relatedness. In light of this, our measure Ris computed by interpreting the paths between clusters, based on both taxonomic and non-taxonomic relations. In the next lines, we will explain in detail our relatedness measurement R. Let G(C, R) be a directed graph, where the vertex Crepresents a cluster ∈G, and the edge Rrepresents a relationship among two adjacent clusters (cf., Fig. 6.7). Let Gk⊆G represent a connected subgraph of G, and Ci kbe the ith cluster ∈Gk. As depicted in Fig. 6.7, the ontological class lwithin Ci kshall be denoted as cil k. Interface Protocol int Sub-Interface string IP MAC_Address … CA CB CC “activated” candidate resources “non-activated” domain resources Logical-Interface IP_Destination IP_Address IP_Prefix IP_Source CD … … Figure 6.6: The rationale behind the quantification of the Semantic Relatedness. Definition 2.The Semantic Relatedness (R) between the set of concepts ck∈Gk is a means to determine the degree to which candidate resources are associated by meaning. It is defined as the product of the density (d) and the Information Content (I) (cf., Equation 6.1). As the majority of approaches we consider semantic relatedness symmetric. R(Gk) = d(Gk)· I(Gk) (6.1) Next, we will formally define the components for the computation of semantic relatedness, namely, density (d) and Information Content (I). Definition 3.The graph interconnectivity which is captured under the notion of density (d) (cf., Equation 6.2) is computed as the relation between the number of active edges along the shortest path between any pair of clusters in graph Gk, and the total number of edges in those shortest paths (i.e., path length). d(Gk) = |Ck|−1 P i=1 |Ck| P j=i+1 [A(SP(Ci k,Cj k)) −1] |Ck|−1 P i=1 |Ck| P j=i+1 H(SP(Ci k,Cj k)) ≤1 (6.2) … Gk (Ck , Rk ) Ck 2 ck 41 ck 11 ck 12 ck 13 ck 14 ck 22 ck 21 ck 31 ck 32 Ck 4 Ck 3 Ck 1 SP x … ck 23 ck 24 ck 33 ck 15 Ck Rk i i Figure 6.7: An example of Semantic Relatedness. A(P) a function that returns the number of activated entities along a given path P. H(P) a function that returns the length of a given path P. SP(Ci k,Cj k) a function that returns the shortest path between a given pair of clusters. Let Ci kand Cj kbe a pair of clusters in Gk, and let P(cil k, cjp k) denote a path between a pair of entities cil k∈ Ci k, and cjp k∈ Cj k. The shortest path between two clusters is defined as SP(Ci k,Cj k) = min P(cil k, cjp k), ∀cil k, cjp kin clusters Ci k, and Cj k, respectively. The number of active edges is computed as the total number of activated entities along the path (A(P)−1). Recall that clusters are composed of activated entities only, thus, source and destination of any given path Pare always activated entities, hence the number of active edges is (A(P)−1). Notice that, similarly to the approach of Tsatsaronis et al. in [?] a path (P) can be a combination of different types of edges—including both taxonomic and non-taxonomic. However, we consider that relations are equally weighted. To illustrate this, consider the paths between the clusters C1 kand C3 kas shown in Fig. 6.7. In this case, the shortest path between any pair of entities (c1l k, c3p k), i.e., paths with source in cluster C1 kand termination in C3 k, or vice-versa, is SP(C1 k,C3 k) = [(c13 k, x),(x, c33 k)]. Now, let the function A(P) return the total number of “activated” entities (i.e., the ontological classes) in path P. In our example, A(SP(C1 k,C3 k)) = 2, which are c13 kand c33 k. The function H(P) in the denominator of (Eq.6.2) returns the total number of hops in path P. For instance, in the example shown in Fig. 6.7,H(SP(C1 k,C3 k)) = 2. Observe that when the clusters Ci kand Cj kare not adjacent, the shortest path can traverse other clusters. Hence, in a connected graph, the number of activated entities always satisfies A(SP(Ci k,Cj k)) ≥2. Definition 4.The Information Content (I) is a measure of the knowledge enclosed by a cluster (cf. Eq. 6.3). I(Gk) = |Ck| X i=1 |cil k| X l=1 til k.mil k.oil k(6.3) In formulae, we use til kto denote the total number of terms that trigger the activation of a domain entity cil k∈ Ci kin the semantic graph Gk. Moreover, mil kis a matching factor which represents the probability of an entity of being the asserted concept with respect to the total number of entities identified for the same set of terms. This coefficient takes the maximum value of “1” whenever a domain entity has been identified by perfect lexical match, or 1 (e+1) in all other cases, with ethe total number of entities also identified for the same terms. In the example shown in Fig. 6.6, e = 2 for the entities triggered by the term “address”, with equal probability from the information content perspective of being “IP Address”,“MAC Address”, or none of them. Finally, the oil kfactor is calculated by counting the frequency of occurrence of an entity for all levels, over the total number of occurrences of its exclusive disjoint candidate entities. After computing semantic relatedness for all set of candidate concepts (∀Gk), we select the set with maximum relatedness (cf., Eq. 6.4) as the most suitable set of resources representative of the CLIs knowledge. If semantic relatedness is the same for more than one set of clusters we compute out-degree as tie break. max kR(Gk) (6.4) It is worth mentioning that, even though at first sight our model might look a bit intricate, its computation is actually quite straightforward. The nature and hierarchical structure of CLIs typically yields a small number of interrelated clusters, and more importantly, as outlined in Fig. 5.1, this subsystem operates in offline mode, so the only and fundamental goal is the accuracy of the OBIE process. Indeed, the results that we present in Chapter 8confirm the strengths of our model and the approach herein proposed. Interface LAN Interface has_if_name string has_if_description … OP1 (set) OP2 (delete) OP3 (set) OP4 (set) OP5 (set) IP Address IPv6 Address IPv4 Address Bandwidth set interface <if-id> <if-description> Figure 6.8: An example Decision Maker Stage. means for evaluation of the system’s overall performance. For this reason, we computed augmented versions of traditional Precision, Recall and F-measure as defined by the same authors in [192] (cf., Equation 8.1). AP =BDM n+Spurious AR =BDM n+Missing AF =AP ·AR 0.5·(AP +AR)(8.1) In order to compute performance metrics, we manually built a gold standard for each configuration space. The gold standard represents a benchmark data set against which to compare the system’s output. It was created by a group of networking experts as a fully-compliant reference set of the most adequate semantic annotations from the domain ontology. We created a gold standard for each stage of our instantiation methodology, namely, one for the resource identification stage (Stage I) and another for the operation identification stage (Stage II). Results for Stage I are a measure of the ability of our system to extract information of networking resources from the CLI, while results for Stage II measure the ability of our system to derive and infer the configuration operations that commands in the CLI actually represent. The main motivation for reporting performance on both stages is to test the success of a two-fold approach for IE. We then compare extractions with respect to the gold standard and compute augmented performance metrics. 8.2 Performance Results In this section, we will report the performance results of our system. From now on, we will refer to the initial version of our IE algorithm (as earlier described in Chapter 6) as the Command Line Information Extraction (CLIE) Algorithm. Based on the observed results, we will later motivate algorithmic changes and investigate the impact on the performance of our system. 8.2.1 CLIE Algorithm The performance results of our system for the CLIE Algorithm are shown in Table 8.1. This table depicts the final percentage values for Augmented Precision (AP), Recall (AR) and F1-Measure (AF), as well as conventional values for the same metrics (P, R and F1) for both stages of our algorithm, separately. Overall, experimental results show that our system is capable of automatically extracting the semantics of the configuration environment from the CLI with high performance. The system achieves around 91% AP and 91% AR, which is near human-level performance. Augmented Traditional Stage I (%) Stage II (%) Stage I (%) Stage II (%) AP AR AF AP AR AF P R F P R F Juniper 83.7 93.4 88.3 94.0 94.0 94.0 80.6 90.0 85.0 89.9 89.9 89.9 Cisco 86.0 93.3 89.9 90.6 90.6 90.6 85.6 92.9 89.1 87.5 87.5 87.5 Quagga 88.0 86.6 87.3 88.1 87.9 88.0 87.2 85.8 86.5 83.0 82.8 82.9 Overall 85.9 91.0 88.4 90.8 90.8 90.8 84.5 89.6 87.0 86.8 86.7 86.7 Table 8.1: Performance Results OBIE Process (Augmented and Traditional): CLIE Algorithm. When comparing augmented values against traditional metrics of P, R and F1-Measure (cf., Table 8.1) we can confirm that our algorithm has the ability to approximate concepts whenever the information given in the CLI is not sufficient to unambiguously determine its semantics. However, the fact that both metrics do not significantly differ allow us to conclude that—in general terms—semantic categorization is highly asserted and not primarily dependent on approximations. Notice that with 91% of AP and AR achieved in a fully automated matter, near 9% of commands would not be adequately instantiated within their corresponding semantic categories. Nevertheless, considering that significant tedious work of mapping would be done and that we can have good suggestions produced by the system, it is reasonable to think of a human in the final loop of deployment. Indeed, a network administrator would have a significantly easier time verifying the remaining 9% of commands than navigating and semantically interpreting the entire hierarchy. Moreover, we identified an additional capability of our system in determining correspondence (i.e., consistency) between the facts expressed in the CLI and general networking knowledge—i.e., knowledge as reflected in the domain ontology (ONDC). An analysis of the experimental results show that whenever the CLI is inconsistent with respect to the networking literature—i.e., not strictly aligned to the domain knowledge—our system approximates (either by generalizing or specifying) to the nearest concept, wherein these assertions are true. To illustrate this, let us consider the following example. A given CLI arranges the “MPLS”-related commands under the “Routing Protocol” level of the hierarchy. However, it is a fact that in the literature MPLS is not actually considered a Routing Protocol. In light of this, although our system identifies the hRouting P rotocoliconcept in the early stage of lexical matching (as expected), in further stages of inference and clustering—i.e., when making associations between concepts in contiguous levels—it generalizes it to the hStandard P rotocoliconcept. The reason for this is that according to the ontology axioms, the hMP LSiconcept identified in subsequent levels is not of the type “Routing Protocol”. This means that, most likely hMP LSiand hRouting P rotocolicannot be at the same time candidates for the same configuration statement. Given that the taxonomic ancestor of hRouting P rotocoli, (i.e.,hStandard P rotocoli) is semantically related to hMP LSiwe perform concept generalization. Notice that this example is not actually a problem of miss-classification, but rather a problem derived from an inconsistency between the literature and the vendor’s interpretation of the domain’s knowledge. Thus, we can conclude that the generalization feature of our system can certainly help to identify and bridge the gap between the CLI information and the domain knowledge model, whenever inconsistencies take place. These exceptions are out of the scope of this work, and will be considered in future work. Furthermore, in an effort to assess the suitability of our design decisions, we developed potential improved versions of our IE algorithm by taking into account other variables in the decision process. The CLIE version of our IE algorithm computes semantic association between candidate concepts based on the relatedness measure (R) defined in Equation 6.1. One of the potential paths of enhancement that we performed—and which has been extensively explored in other research areas—was considering the ontology depth as a variable to the computation of semantic relatedness. The notion of including ontology depth as a new variable for semantic relatedness computation is gathered under the concept of the Depth Command Line Information Extraction D-CLIE Algorithm. 8.2.2 D-CLIE Algorithm Ontological depth is one of many variables considered in several state-of-the-art semantic relatedness metrics. It is based on the notion that deeper nodes in the taxonomy— i.e., more specific concepts—have stronger semantic association than higher (generic) concepts [156]. In light of this, we included a component to our relatedness measure which considers the relative depth of clusters (denoted as D) (cf., Eq. 8.2 and 8.3). This component is a relation of the sum of actual depths of a pair of clusters over the sum of the maximum depths. We refer to the version of our algorithm which considers ontology depth as a variable for relatedness computation as the Depth Command Line Information Extraction (D-CLIE) Algorithm. d0(Gk) = d(Gk)· |Ck|−1 X i=1 |Ck| X j=i+1 D(Ci,Cj) (8.2) D(Ci,Cj) = depth(Ci) + depth(Cj) max depth(Ci) + max depth(Cj)(8.3) depth(Cn) a function that returns the depth of a cluster as the depth of the deepest node in the cluster. max depth(Cn) a function that returns the maximum depth of a cluster computed as the deepest concept among all branches of the cluster. The performance results of our system for the D-CLIE Algorithm are depicted in Table 8.2. Notice that overall, the system’s performance is not affected by the inclusion of a new variable to our semantic relatedness measure—when metrics are compared to those obtained for the initial version of our algorithm (cf., Table 8.1). We believe that in the context of our approach, the consideration of ontology depth as a variable for semantic relatedness computation has no significant impact because of the generalization feature performed during lexical matching and the subsequent reasoning in the inference stage. Accordingly, concepts within a branch of the ontology (i.e., taxonomically related concepts) have already been pruned on this basis. As such, by the time we compute semantic relatedness, pairs of disjoint candidate concepts on a same taxonomy branch do not exist, therefore, ontology depth has no actual weight in the final scores. For this reason, we performed new experiments in which we removed the generalization and specialization features of our algorithm in order to do taxonomic pruning based on semantic relatedness measures which take into account depth (D-CLIE*Algorithm). The main motivation is to determine whether generalization and inference show better results for taxonomic pruning than a strategy of semantic relatedness computation based on ontology depth consideration. 8.2.3 D-CLIE*Algorithm The results of this experiment are shown in Table 8.3. Notice that, though the system’s performance does not dramatically decrease, it is certainly lower than the performance Stage 1 (%) Stage 2 (%) AP AR AF AP AR AF Juniper 83.7 93.4 88.3 94.0 94.0 94.0 Cisco 85.9 93.1 89.4 90.6 90.6 90.6 Quagga 89.0 86.6 87.3 88.1 87.9 88.0 Overall 85.9 90.9 88.3 90.8 90.8 90.8 Table 8.2: Performance Results OBIE Process: D-CLIE Algorithm. metrics obtained for the initial CLIE Algorithm (cf., Table 8.1). Accordingly, considering the ontology depth as the absolute criteria for taxonomic pruning of concepts does not improve the performance of the system. We strongly believe that ontology depth does not compensate to the same level to the performance of our generalization and reasoning features, basically because our decisions rely on the lexical knowledge obtained from the CLI in combination with ontological structure and relevant ontological facts, such as non-taxonomic relations. While ontology depth only takes a decision based on the taxonomy. In light of all this, we can definitely conclude on the suitability of our initial design premises as the system achieves the highest performance values for this scenario. D-CLIE* Stage I (%) Stage II (%) AP AR AF AP AR AF Juniper 75.4 89.1 81.7 89.2 89.2 89.2 Cisco 80.1 87.4 83.6 86.7 86.7 86.7 Quagga 84.0 81.6 82.8 85.0 84.8 84.9 Overall 79.8 86.0 82.8 86.8 86.8 86.8 Table 8.3: Performance Results OBIE Process: D-CLIE*Algorithm. 8.2.4 Tsatsaronis et al. Relatedness Metric In an effort to validate the suitability of a CLI feature-dependent metric, we replaced our own semantic relatedness measure with that proposed by authors in [193]. The main motivation is to assess the performance of our system when considering a non CLIdependent relatedness measure—still closely aligned to our research goals. Notice that, all other steps of our Information Extraction Algorithm, namely, data pre-processing, lexical matching, clustering, inference and decision making remain invariant for this validation scenario. Tsatsaronis et al. [193] propose a metric for semantic relatedness computation (cf., Eq. 8.4) in which the weighted path length and actual path depth between concepts in an ontological graph are considered. While path length is captured under the notion of compactness (cf., Eq. 8.5), path depth is captured under the concept of semantic path elaboration (spe) (cf., Eq. 8.6). Similar to our approach, authors consider both taxonomic and non-taxonomic relations, while giving different weights (w) to each type. The way in which path length and depth is computed certainly differs from our approach, but most importantly, there is no particular consideration of CLI-dependent features—which in our case is captured under the notion of the Information Content (IC) component. Equation 8.4 represents the Relatedness measure proposed by authors as the maximum product of compactness and spe given by any path between them. Notice that, among the types of relations described by authors in [193] we restricted types to the following, hypernym/hyponym (w= 0.61), part meronym/holonym (w= 0.0367) and attribute (w= 0.00414), with the same weight values considered by authors. R(c1, c2) = max(compactness(p(c1, c2)) ·spe(p(c1, c2)))(8.4) compactness(p(c1, c2)) = l Y i w(ei) (8.5) spe(p(c1, c2)) = l Y i 2·depth(c0 i)·depth(c0 i+1) depth(c0 i) + depth(c0 i+1)·1 depth(T)(8.6) The results of executing our IE algorithm with semantic relatedness based on the external metric proposed by Tsatsaronis et al. are shown in Table 8.4. Notice that overall, system’s performance drops 9% with respect to our initial proposed CLIE Algorithm— i.e., from 90.8% to 81.9% AF. This means that, considering CLI-related features in the computation of semantic relatedness does improve accuracy in semantic instantiation for the case of CLI environments. It is important to realize that semantic relatedness computation directly affects Stage I of our algorithm, for which performance drops in 10%, meaning that, the correct identification of CLI concepts decreases and directly impacts on the decision stage of our algorithm (i.e., Stage II). Tsatsaronis et al. Stage I (%) Stage II (%) AP AR AF AP AR AF Juniper 73.9 80.2 76.9 81.8 81.8 81.8 Cisco 76.2 79.9 78.0 83.6 83.6 83.6 Quagga 79.3 81.3 80.3 82.6 82.5 82.6 Overall 76.4 80.4 78.3 82.0 81.8 81.9 Table 8.4: Performance Results OBIE Process: Tsatsaronis et al. Relatedness Measure 8.3 Enhancing CLIs with Meta-Data The information provided in CLI-based environments frequently lacks of verbosity, a fact which can certainly lead to ambiguity or semantic incompleteness. In light of this, it seems reasonable to think that by enhancing CLIs with meta-data, configuration knowledge extraction could be improved. However, current CLIs are not editable and thus, there are no means to augment the semantics of the help feature. Based on this motivation, we will briefly describe an use case of the OPENER tool to enable potential edition of CLIs. 8.3.1 OPENER 8.3.1.1 In a Nutshell Software Defined Networking (SDN) offers endless opportunities for creative researchers and entrepreneurs, and confers greater agility to the networking industry to meet the flexibility and cost reductions that service providers are constantly seeking. This paradigm shift toward greater openness to the software industry is increasingly attracting researchers and developers, and it is fostering innovations in the networking arena at an astonishing speed. In spite of this, researchers with the capacity to devise really creative SDN applications lack a non-proprietary environment in which they can easily manage and experiment with their creations. This is especially the case when the targeted SDN applications have requirements that go beyond the OpenFlow philosophy. In this context, we introduce OPENER as a tool that offers an open and programmable environment that covers the entire life-cycle for managing the experimentation with out-of-the-box SDN applications. OPENER can be installed and used in a standalone fashion, providing the development, management, and execution environments facilitating the implementation, deployment, and testing of SDN applications beyond what non-proprietary solutions currently offer. Moreover, OPENER depends neither on specific SDN platforms nor on particular APIs and protocols, which makes it highly flexible for application developers. 8.3.1.2 The Configurable Helps Use Case One of the potential use cases of the OPENER platform is developing an SDN-based application to modify and enhance the CLIs help feature of Quagga Routers—a function which unfortunately is not provided at present by any vendor in the market. A solution of this nature would provide the functions to augment the semantics of CLIs help descriptors, and furthermore—in the context of our solution—allow us to analyze whether such strategy improves our systems performance or not, i.e., improve the ability to interpret and derive the semantics of CLI environments. If successful, we could derive information models for the CLI helps, and make recommendations to device vendors for restructuring and adding the proper semantics to their CLI helps. To tackle this limitation, we have seized the functionalities provided by OPENER. For this purpose, first, we made Quagga SDN-enabled, by implementing wrapper functions able to expose its internal functionalities, independently of OPENER. Then, we developed the SDN Technology-Dependent Abstraction (STDA) to bind the OPENER platform independent features to the particularities of our SDN-enabled Quagga. Finally, we developed an OPENER application that hooks itself to the core of the CommandLine system, overriding its default internal mechanisms through a callback, which decodes the original CLI helps and commands, and allows their modification. Using this approach, the system can always revert to legacy mode by removing these wrappers, leaving Quagga with its original features. This application enables the edition of the CLIs command help descriptors, and augmenting its semantics through the addition of meta-information. Figure 8.1 shows this application in action. It is built on top of the already available command-line user interface, and it enables a set of new CLI commands for creating, editing, appending, saving and retrieving new descriptions and meta-information to any existing command. The example shown in Fig. 8.1 illustrates how the help descriptor for the command “show ip” can be easily modified. Table 8.5 summarizes the CLI functions that have been developed on OPENER to endow the configuration environment with richer semantics for experimentation. Note that this use case aims at investigating and experimenting with functions that are far beyond the OpenFlow philosophy and its capabilities, though the use case is (a) Default help supplied by a Quagga router for the “show ip” command. (b) Modifying the help descriptor for the “show ip” command using the new commands devised “help create” and “help set”. (c) Example showing how to add Meta-Information (MI) to the “show ip” command using the new commands “metainfo create” and “metainfo set”. Figure 8.1: An SDN application on OPENER for endowing routers with configurable CLI helps. Command Description metainfo/help create The create command reserves space in memory to store a string enclosing the customized help description or metadata. It can handle any size of string of data. metainfo/help set The set command allows to set the meta-information or help description of a given command to the newly created string data. This command overwrites the content. metainfo/help append The append command allows to append new data to the help descriptor or meta-info of a given command. metainfo/help get The get command retrieves the information for a given command. metainfo clear The clear command removes the metainformation for a given command. help restore The restore command allows to recover the default help description for a given command. save metadata The save command stores the modified help to a file. load metadata The load command allows to open the custom help file to start editing or visualizing its content. This command is automatically executed when booting the Quagga daemon. Table 8.5: New commands on a Quagga’s CLI with OPENER implementation. still perfectly aligned with the overall SDN paradigm. The central issue is that, rather than targeting the flows through the router, this use case targets the router itself. This use case offers a clear example of OPENER’s potential for developing and managing non-flow based SDN applications. 8.3.2 Results With support of the developed OPENER application we enhanced Quagga’s CLI by adding additional meta-data to the help feature. This experiment demonstrates that the system’s performance improves as additional information is provided to the learning algorithm in the form of meta-data. It can be seen from Table 8.6, that AF reaches 95.9% for the case of enhanced CLIs which is greater than the best result reported for our IE Algorithm. Moreover, notice that if we enrich the semantics of the CLI by adding semantic annotations from the developed ontology (as meta-data), maximum performance of our system can be achieved. However, this strategy is not feasible in the short term, neither because this would require standardization efforts toward the router, which is currently a bottleneck in the computer system when compared with processing capacity. In an effort to minimize the mapping table size, the latency time, and hence, ensure the highest possible reachability, we propose the LISP Redundancy Protocol (LRP), which is inspired by the Cisco’s Hot Standby Routing Protocol (HSRP) [199]. This architectural approach essentially allows to configure two routers for mapping purposes, so in case of single-failure, the other can replace it—following a Master-Slave model. The contribution of LRP is to extend HSRP functionalities by creating different logical groups. In this scenario, border routers can be members of different groups, and the “key” difference between LRP and HSRP focuses on the fact that LRP enables a router to be Slave in a group and Master in another (cf., Fig. 9.1). By implementing this feature all routers can be in forwarding mode, hence overcoming the limitation present in [25], namely to avoid the need of replicating the entire mapping on all the border routers. In case of either a link or border router failure, the last one will interchange his mapping with the border router that is now responsible of handling the traffic in this logical group. In short, the main features offered by the LISP Redundancy Protocol are: •The xTRs can be clustered into different LRP groups or pairs. •The Mappings are pushed onto the LRP groups or pairs. Master LRP Group 1 Slave LRP Group 1 Master LRP Group 2 Slave LRP Group 2 Master LRP Group 1 Master LRP Group 2 Master LRP Group 3 . . . HSRP Group 1 HSRP Group 2 LRP Group 1 LRP Group 3 Slave LRP Group 1 Slave LRP Group 2 LRP Group 2 (a) HSRP Master/Slave Model (b) LRP Master/Slave Model Figure 9.1: Master/Slave Model HSRP vs. LRP. •All the xTRs in the group can carry traffic (active rather than standby). •No need for data-probes when the xTR does not have a mapping. Next, we consider different scenarios that may originate reachability and/or reliability problems and require solutions to be managed by the current proposed protocol. 9.2.1 Inter-domain link failure in an Ingress Tunnel Router (ITR) Next, we will discuss and describe the actions that are executed in order to solve an inter-domain link failure in the presence of LRP. In step 1 of Figure 9.2, the traffic is sent to the edge router (ITR1), which is responsible for encapsulating the traffic and send it through international links to the destination. When the international link fails (step 2) the ITR1 automatically detects this event and in real time forwards all the incoming traffic to the other ITR belonging to its LRP group (step 3). ITR2 has the correspondent mapping since it shares the LRP Group with ITR1 and now is in charge of encapsulating and sending this traffic to its destination (step 4). On the other hand, by means of the internal routing protocol (running in the AS), the failure of the international link is notified to update the routing tables and hence the traffic is rerouted (step 5). In time, the LISP Control Box (LCB) would be responsible for reconfiguring the mapping of the different ITRs with the purpose of load balancing the outbound traffic (step 6). Finally, the traffic is rerouted according to internal routing policy (step 7). In short, in this scenario our border architecture prevents packet loss and in particular the sending of data-probes. 9.2.2 Ingress Tunnel Router (ITR) failure or unexpected shutdown In the case that an Ingress Tunnel Router (ITR) fails or is shutdown, gigabits of data would be lost. To overcome this issue, the LISP Control Plane must converge to the Interior Gateway Protocol (IGP) running in the AS, in order to send back first gigabits of data-probes and after successful mapping, send data according to the normal procedure. The following describes the steps followed by the LRP to prevent any loss of data and to avoid sending data-probes. In step 1 in Fig. 9.3, the traffic is sent to the edge router (ITR1), which is responsible for encapsulating the traffic and send it through the international link to its destination. When ITR1 fails (step 2) the HSRP that runs between ITR2 and ITR1 converges, and automatically ITR2 assumes the role of Master of the LRP group and forwards all traffic that arrives (step 3) in real time. The convergence of HSRP is much faster than any IGP, such as Open Shortest Past First - Provider A Provider B 10.0.0.0/8 11.0.0.0/8 Greater Internet LRP Group LRP Group ITR 1 ITR 3 ITR 4 ASs S ITR 2 LCBs 1 2 3 4 56 7 •ITR1starts forwarding traffic to ITR2. •ITR2has ITR1’s mappings since they are in the same LRP Group. •With the existing proposals,if an interdomain link carrying gigabits of traffic fails →gigabits of data-probes will be generated. •Alternatively,using an LRP protocol no dataprobes are needed and traffic can be routed through the backup ITR.This comes at the cost of having the mappings in the LRP pair of ITRs. Figure 9.2: LRP: Inter-domain link failure. OSPF. In turn, the internal routing protocol that is running notifies the failure of ITR1 (step 4) to update the routing tables and hence allowing the traffic to be rerouted. On the other hand, the LISP Control Box (LCB) would be responsible for reconfiguring the mapping of the different ITRs to balance the outbound traffic load (step 5). Finally, the traffic is rerouted according to the IGP (step 6). In short, in this scenario our border architecture minimizes the packet loss and in particular the sending of data-probes. 9.2.3 Ingress Tunnel Router (ITR) Mapping Miss In this scenario, an action of Traffic Engineering or an internal failure (step 1 in Figure 9.4) makes the traffic to be rerouted. When the packet reaches a border router (step 2) that has no corresponding mapping, this router makes a broadcast to other LRP Groups of the packets that are arriving (step 3), and in turn, the LRP Group sends a Map-Request to the LCB (step 4) that is responsible for handling all mappings within an AS. A LCB (LISP Control Box) is an entity responsible of all mappings within an AS which might be a standalone device or run as an instance of a PCE. The LRP Group that owns the required mapping, sends it via unicast to the LRP Group responsible for these packages (requester) (step 5), and encapsulates and forwards the traffic. While traffic is derived from the LRP Group mapping holder (step 6), the LCB sends to the LRP Group who sent the Map-Request the mapping necessary to encapsulate the packages Provider A Provider B 10.0.0.0/8 11.0.0.0/8 Greater Internet LRP Group LRP Group ITR 1 ITR 3 ITR 4 ASsS ITR 2 LCBs 1 2 3 45 6 LRP reacts to the failure. ITR2 receives and forwards the traffic. Figure 9.3: ITR Failure. (step 7). Finally, the LRP Group can now encapsulate packets and, therefore, makes the package forwarding through the LISP data plane (step 8). In conclusion, in this scenario our border architecture prevents packet loss and in particular the sending of data-probes. LRP Group ASs S ITR 1 LCBs 1 2 3 6 IGP re-routing due, e.g., to an internal link/node failure or TE action LRP Group LRP Group ITR 2 ITR 3 ITR 4 ITR 5 ITR 6 4 3 5 6 8 7 Unicast Reply Traffic Map-Request Broadcast Figure 9.4: ITR has no mapping from EID-to-RLOC. Chapter 10 The Future Internet In this Chapter we describe the fundamentals of TARIFA, an approach for next generation networks and finally, introduce a novel addressing scheme for a service-oriented architecture. Network communications have rapidly evolved in the past years, this growth has led to numerous challenges, many of which remain unsolved or in other cases when solved, have derived in new issues, due mainly to inflexibility of the initial hierarchical layered model of current Internet architecture. In the past years, emerging of new applications, services, users growth, mobility requirements, among others, have become issues of high interest under the scope of many researchers on the Internet area. As a result of these efforts, research projects such as GENI [26], 4WARD [27], DONA [28], TRILOGY [29], or PSIRP [30] have been developed in order to discuss novel ideas and present novel network architectures. TARIFA [31] also figures as an initiative towards developing a clean slate Future Internet (FI) architecture, where the network paradigm is no longer based on the interconnection of machines/interfaces but on the interconnection of services/resources, an approach that seems to meet much better both present and future users requirements. TARIFA takes as basis a service-oriented paradigm for service provisioning in Future Internet, where communications can be composed on the fly and dynamically adapted by exploiting reusable components or services. A major concern, however, for making possible this shift of paradigm is the addressing scheme used in the Internet. In the past years, scalable routing and addressing architectures for the current Internet have become target of many research efforts. Concerns related to the scalability of the routing system and the impending exhaustion of the IPv4 address space have led to important proposals based on the “locator/identifier separation” [141]. 126 Multi-homing and traffic engineering represent two of the main factors contributing on routing tables exponential growth, due basically to IP addresses semantic overload. Current Internet combines two functions: location (point of attachment to the network, where) and identification (who), in other words, current IP addresses have dual semantics, identifiers and locators are under the same numeric space. Several approaches have been pursuit in order to solve these open technical issues, SHIM6, HIP, LISP are just a few to name. Several reports can be found in the literature claiming that the semantic overloading of IP addresses is hindering the progress toward the deployment of service-centric architectures [4]. In the context of Internet mobility this has serious and well-known scalability issues, hence avoiding this semantic overloading is a key objective while designing new addressing schemes. Taking these facts as basis, herein we present a novel addressing scheme which aims to overcome the addressed issues to yield several advantages, including improved scalability for the routing system, by dealing with the Internet routing table exponential growth. This scheme has been designed and evaluated as part of the TARIFA project [31]. 10.1 A Service-Centric Internet Architecture: TARIFA TARIFA [31] aims at defining a clean slate approach to a Future Internet architectural redesign, based on a role-based paradigm consisting of non-divisible, or atomic, functions. TARIFA architecture is service-oriented, enabling dynamic composition of services and its adaptation, taking into account context status and its variations. Thus, services become the fundamental functional components to be composed, taking into account the specific requirements of each communication and allowing to adapt them to fulfill context variations. Service-oriented approaches are foreseen to be suitable for providing seamless communications which allow to deal with heterogeneity and dynamic conditions of the network. The TARIFA approach proposes that network maintains context information by means of distributing it among network nodes. We take advantage of the distributed nature of this approach in order to achieve a high level of scalability and flexibility. Thus, context-awareness is enabled by making context information available to nodes in the Network. The TARIFA approach is service-oriented, as it allows to discover, combine and dynamically adapt the functional service blocks, according to context variations. Under this vision, we worked towards the proposal of a new addressing scheme oriented to the real requirements of a service-centric architecture. Next, we will introduce the main ideas of our proposal, followed by an analytical validation of the concepts herein introduced. 10.2 A Service-Centric Addressing Scheme 10.2.1 Overview In the context of the newly proposed Network architecture a new addressing scheme is proposed in order to suit the needs of reachability and overcome current issues related to routing and semantic overload of IP addresses. Our proposal relies on the separation of the space of locators and identifiers, due to the correspondence of this model to a serviceoriented approach, where mobility and service migration have quite high probability. Under this model, the generation of two clearly separated spaces (naming and location), allows us to introduce two new important concepts, namely, the TARIFA Identifier (from now on referred to as TID) which permits the unique identification of services and resources, regardless its actual location and the TARIFA location (from now on referred to as TLOC) which indicates the current location of the identified resource or service over the network. The main features of the proposed addressing scheme as listed as follow: 10.2.2 Naming Space As introduced previously, the naming space refers to the space of identification of services and resources available in the network. Under our model, TIDs are fixed length structures following a given hierarchy, which allows the unique global identification of services and/or resources. Our addressing scheme, does not assume any kind of restrictions over what can be identified, in other words, tangible (physical, e.g. PC, PDA, etc.) or intangible (virtual, e.g. files, services or applications) may have their own identifier. The generic format of a TID is shown in Figure 10.1. From the figure it is possible to distinguish three fixed size fields, namely: •Entity, this 64 bit field refers to the root entity instantiating a given service or resource. As in cur-rent citizen identification systems, where each citizen is identified through a unique number, our approach intends to assign a domain of identification to each citizen, organization, virtual group or enterprise, under which each entity will identify the set or subset of services and resources of its interest. Entity Service Resource 160 bits 64 bits 64 bits 32 bits 96 bits Figure 10.1: TID format and size for Service-Centric architecture. •Service, this 64 bit field allows to address all available services for a given entity, by this, one entity is capable of addressing a total of 264 services, which is actually the square of the current internet. •Resource, this 32 bit field allows to address all available resources for a given entity. A key feature of the proposed identification scheme is its two-fold purpose, on one side it serves to uniquely identify services or resources, and on the other side it provides com-posed identification, meaning that we can identify services related to a concrete resource (e.g. a printing service dependent of an specific printer). A TID is a 160 bit fixed length structure. Our proposal pushes towards fixed length identifiers as it has been proven to be the best alternative for hardware scalability, simplicity and cost-reduction. Current network hardware is especially designed to optimize forwarding tasks, for which fixed length is critical. On the other hand, transport networks are moving towards optical solutions, in this matter, variable length identifiers would imply major electronic processing which goes against the all-optical trend. Determining the fixed size of the proposed TID is an important challenge, as it must suit the complete space of identifiable objects. Based on the previous idea of providing a block of identifying space for entities to uniquely name services and resources under their own space, we must face a new challenge related to the number of entities that our space of identifiers shall be able to address. The answer boils down to overestimating the space to be addressed. To this end, we assume that today’s worldwide current population is around 7 x109, this implies that 33 bits would be required to address the complete world’s population. According to the United Nations Demographic Forecast [10] the population for 2300 is estimated to be around 8.97 billion, meaning that 34 bits would be enough to globe this figure. Taking in consideration that many other entities (enterprises, organizations, logical groups, governments) could be provided of a block of identifiers, a gap of 30 extra bits seems to be a suitable number. In this sense, 264 entities are addressable over a TARIFA Network. Then, each entity is able to address 296 objects, semantically differentiated in two fields: service (64 bits) and resource (32 bits). The main advantage of such a type of identification is that it allows automatic identification clustering, or aggregation. An important aspect to highlight from the proposed solution, is to make clear that for networks with no infrastructure and sensor networks composed of low capacity devices, these may internally be managed by the manufacturer assigned identifier, which would not be visible to the global network, but managed through an aggregation point ruled under the TARIFA identifying scheme which is actually visible out of its boundaries. In this sense, both schemes can coexist. TID’s express the binary or numeric representation of identifiers for services and resources over a TARIFA Network. But what actually seems as important, is to provide users with the capability of consuming already well-known services, and for this, knowledge on the desired service identifier is required. Since numeric representations and especially long formats do not provide friendly-human readable identifiers, we propose the existence of friendly names or TARIFA Friendly Name Identifier (TFNI ). ATFNI will provide users with the capability of reminding identifiers to well-known services and direct access or request of them. A TFNI will typically be a string-based identifier, following the same hierarchical structure proposed for TIDs, that is a triplet entity-service-resource. This means that all services under the same entity will share a common prefix, by them all being services of the same entity (e.g. companyA.videoServ, companyA.printServ, etc.). This new concept within the Project faces a new challenge, this is, there must exist a supporting system capable of solving TFNI into TIDs, this is the TARIFA Resolution Name System (TRNS) a concern left for future work. 10.2.3 Location Space The clear separation of the addressing space, allows the generation of a location space, referred to the position of identified services or resources in the Network. A TARIFA Locator (TLOC) is a fixed length structure reflecting the position of a resource or service in a binary/numeric format. Given the basis of the TARIFA Project [31], this is, a service-oriented approach, locators do not aim to be only pointers to physical objects, but to physical and virtual entities as well. This raises a new challenge related to mapping from identifiers to locators for virtual entities, this issue will be discussed further in the next section. As TIDs, the proposed TLOCs are globally unique, meaning they have representation over the entire scope of the Network. Our proposed model, provides flexibility regarding the location scheme, allowing the coexistence of different representations such as, flat scheme, hierarchical scheme or those based on geolocation, among many others. A fixed number of bits (8 bits) is reserved for indicating the location scheme. It is important to highlight Location Scheme Location Scheme Custom Field 96 bits 8 bits 88 bits Figure 10.2: TLOC format and size for Service-Centric architecture. that a subset of these 8 bits remain available for future options, such as security policies, QoS, etc. The remaining 88 bits are used for direct representation of the locator for the underlying scheme. In order to assure that a geolocation scheme under the proposed model will provide the precision and resolution required for a feasible addressing scheme, we proved that an 88 bit locator field provides high quality resolution. The total area of the planet’s surface is around Searth = 510.086 ∗109 m2. For a desired resolution of 1 mm2 (this means being able to locate objects as small as 1mm2above the Searth) 69 bits are needed, this is less than the 88 bits free for location assignment. With this number of bits a resolution in the order of nm2can be achieved, this is far away from a minimum feasible resolution. 10.2.4 ID/LOC Mapping With the separation of identifiers and locators in two different spaces, a new concern emerges, this refers to the need of a mechanism able to map identifiers to locators. Many approaches can be found in the recent literature dealing with such a mapping system [22][23][200]. The proposed identifier-to-locator mechanism within the context of a service-oriented network is based on DHTs. For this purpose, all Manager Elements in a TARIFA-compliant Network are part of a mapping overlay. These nodes form a Chord ring topology and are responsible of a group of (key, values) pairs, where keys are identifiers and values are locators. There are two main advantages in mapping to a DHT-based implementation. One is that this mapping system is fully decentralized. A second advantage is scalability (as demonstrated in [31]), this scheme experiences sublinear growth with the number of addressable nodes n, namely, log(n). The proposed mechanism was implemented in the framework of the TARIFA project in the form of a mapping overlay. An important aspect related to the mapping system in service-oriented network architectures, is the mapping of TIDs that identify virtual entities, as in current Internet this is not an issue. As such, we consider two potential lines of work for handling the previous concern: