1. Introduction

       Operability, maintainability, and network addressing issues in the legacy IPv4 networks are being investigated with the emergence of next-generation networking paradigms like software-defined networking (SDN) and Internet Protocol Version 6 (IPv6) ^[1]. The network addressing and routing issues are being undertaken by IPv6-enabled networking, while the operational complexities of the vertically integrated legacy network can be minimized by the implementation of SDN. IPv6 and the SDN are not backward-compatible, leading to complexities and challenges in the real-time migration of the legacy IPv4 networking system, which is currently operating world-wide. Network migration is inevitable for service providers, though there have been several challenges with migration from the technical, financial, as well as business perspectives ^[2]. The higher costs of network migration to replace or upgrade network devices, transformations in software systems and related services, along with a lack of skilled human resources to operate and maintain the newer networking systems are becoming the major hurdles of technology migration in service provider networks.

       Internet service provider (ISP) networks consist of multiple autonomous systems, and are generally heterogeneous in nature. Hence, multi-domain heterogeneous network migration planning is a challenge. The solution of IPv4 address depletion was devised more than three decades ago in the 1990s with the introduction of IPv6 addressing, also termed as “IP next generation (IPng)” ^[3]. However, the global IPv6 adoption rate is not satisfactory ^[4]; it has just crossed 25% adoption worldwide, while the adoption rate in developing countries is still below 1% ^[5]. The early stage of IPv6 network migration and the premature stage of SDN migration ^[2][5] in telecommunications (Telcos) and ISP networks indicate that sufficient efforts in the research and development of SDN and IPv6 network migration are needed. IPv6 and SDN are interrelated, because IPv6 deals with routing and addressing in the IP layer, while SDN deals with the controlling of the operations of the networking management layer. IPv6 avoids the IPv4 routing and addressing issues, while SDN avoids the management and controlling issues of legacy networks. These two networking paradigms, which are recognized in the network operation layer, are operated by service providers. Hence, in our previous works, we introduced a joint SDN and IPv6 network as an SDN-enabled IPv6 network called the software-defined IPv6 (SoDIP6) network, with its benefits and challenges for efficient migration planning ^[1][2][6]. Combining the features of IPv6 and SDN creates more robust networks. Those combined features ^[2] are more attractive for service providers for the timely migration of their legacy networks. For migration cost reduction with optimization of the capital and operational expenditures (CapEX and OpEX), the joint migration planning of SDN and the IPv6 network is beneficial for service providers ^[7].  

       Well-defined migration methods, progressive migration scenarios, sufficient applications, and protocol standards are supportive for ISPs to take decisions for IPv6 migration, but there is still a lack of standards and applications towards bringing SDN implementation in ISP networks close to reality. However different transition techniques have been defined; dual-stack IPv6 and hybrid SDN approach ^[8][9] are the more appropriate solutions for smooth and gradual transition to IPv6 and SDN. The evaluation of production standards under Hybrid SDN require deep investigation.

       With the implementation of multi-domain SoDIP6 networks for service providers, the controller placement problem during and after the migration is a major concern. Increasing the number of SDN switches during migration affects the controller capacity. To address the problem of increasing control traffic with the increase of SDN switches, a suitable approach is needed to locate the controller and add other controllers in the network for load balancing.

       In this article, we implement the incremental transition of a legacy network into a SoDIP6 network by performing experimental tests and simulations to measure the viability of the real production of an SDN-enabled IPv6 network in service provider networks by implementing Open Network Operating System (ONOS) and SDN-IP, the recently emerging robust networking platform for SDN migration. SDN-IP is an application developed and implemented over ONOS to integrate SDN and legacy networks in terms of routing and interoperability so that service providers can have a gradual migration by smoothly integrating SDN with the legacy networks. SDN-IP implements border gateway protocol (BGP) for communications among multiple autonomous systems (ASes), as with BGP implemented in legacy routing. BGP speakers help to establish the peering with external gateway routers by obtaining route information from the ONOS SDN controller. We propose a heuristic for the best ONOS controller location and routers migration in real time considering optimal path routing and optimal control path latency. Following are the major contributions of this work.

• A study on the viable implementation of multi-domain SoDIP6 networks is carried out.

• The incremental deployment of an SDN-enabled IPv6 network using ONOS/SDN-IP is implemented.

• A solution for controller placement based on control path latency is presented using a breadth-first router replacement (BFR) approach for router migration planning during the migration of carrier-grade service provider networks.

2. SDN-IP 

Figure 1. Architectural overview of Open Network Operating System (ONOS)/SDN-IP implementation.

       SDN-IP enables service providers to conduct the greenfield deployment of SDN in an AS, and communicates with legacy networks. Additionally, it treats the SDN network as an autonomous transit network so that multiple legacy networks attached to the SDN network can communicate with each other by translating BGP routes into ONOS application intent requests, while ONOS translates those intent requests into forwarding rules to deploy to the data plane devices to establish communication with external networks. The fair communication mechanisms developed between SDN switches and the legacy routers in the hybrid network enables the gradual migration of the legacy network into SDN. The network under migration as a whole becomes a hybrid network so that normal traffic and control traffic load balancing as well as failure handling during the migration have to be carefully designed. ONOS considers multiple instances, having its flexibility and scalability features in the distributed clustered environment, allowing multiple instances of SDN-IP and BGP speakers to consider efficient traffic load management. Increasing the number of SDN data plane devices during incremental deployment increases the control traffic between the controller and the SDN switches. Additionally, when attached with SDN switches, the legacy BGP routers reroute the BGP routing traffic to the SDN BGP speaker. During the migration, at some points, increasing SDN switches will increase internal BGP (iBGP) peers, leading to higher control traffic to the BGP speaker, which ultimately increases the intent calculation and flow-rule processing load of ONOS.

       From Table 1, it seems that ONOS/SDN-IP implementation in ISP network migration comes to reality. So, we can plan for smooth migration of legacy networks into SoDIP6 networks with the consideration of controller placement and traffic engineering. Hence, in this article, we consider shortest-path routers migration and identify the best location for controller placement with its instance creation for control traffic load balancing through the selection of median point router by implementing the ONOS/SDN-IP platform for network migration.

       Considering the smooth and incremental deployment of SDN,  we implemented an SDN-enabled IPv6 network using ONOS/SDN-IP to enable communications among multiple ASes in the SoDIP6 network environment, and proposed a heuristic to identify the proper location of the master ONOS controller by considering optimal path routing and the minimum control path latency (MCPL).