1. Introduction

Today, numerous sensitive, private and confidential data and information (e.g., healthy and financial records) transmitted through the Internet are vulnerable to all sorts of cyberattacks [1]. Hence, providing long-term security and integrity for data and communications is of utmost importance in the Internet era. Unfortunately, conventional cybersecurity framework will soon be under threat of powerful attack algorithms [2] and quantum computers [3]. Quantum key distribution (QKD) [4,5] is capable of distributing information-theoretically secure (ITS) secret keys for symmetric encryption between two legitimate parties, which is potential to maintain cybersecurity in the long-term. QKD promises to achieve unconditional security based on the principles of quantum physics (e.g., quantum no-cloning theorem [6,7]), where the legitimate parties can detect the presence of any illegitimate party who is trying to obtain the secret keys.

Experimental QKD has already been performed using the optical fiber [8], free space [9], and satellite [10]. Currently, fiber-based QKD systems have been commercialized [11–14]. In practice, several QKD networks have been deployed and demonstrated, e.g., SECOQC, Tokyo, and China’s Beijing-Shanghai QKD networks [4]. The potential applications of QKD involve enhancing the security of critical infrastructures in various fields (e.g., health, finance, and transport). One potential application arena for QKD is in institutions such as government and intelligence agencies or businesses with long-term strategic trade secrets that should be kept confidential, since QKD can be combined with existing symmetric-key cryptography to provide very long-term security. Another potential application arena for QKD is in closed electronic data interchange systems that are used for high value banking transactions, since QKD can be useful in safeguard financial transactions. Moreover, QKD could be ideal in other applications, where only users who are known and trusted can use QKD.

Since the cost and complexity of QKD network deployment are very high, it is difficult for each user (e.g., a financial institution) to deploy its dedicated QKD network. Accordingly, QKD as a service (QaaS) [15] becomes a promising pattern for future QKD networks. The QKD network deployment can be implemented independently of classical networks using dedicated fibers, or can be integrated with classical networks using a fraction of wavelength channels in existing fibers. Thanks to the pervasive fiber infrastructure for classical networks, combining QKD deployment onto existing classical networks becomes a very popular case and has been demonstrated in many field trials [16,17]. However, we consider that the operation for QKD networks in both of the two deployment approaches are independent of the classical networks. The QaaS concept is proposed for QKD network operation with an assumption that the QKD network deployment has been completed. Hence, the QaaS concept in this paper is used for an independent QKD only network, and the QaaS architecture and function will also occur for an independent QKD only network.

In a QKD network infrastructure, a number of secret keys can be constantly produced and each of them cannot be reused, where the secret-key rate (SKR) is precious since it is lower than 2 Mb/s over a 50 km standard optical fiber link for discrete-variable/continuous-variable QKD [18]. The SKR is defined as the generation of secret keys in bits per second, which has no relationship to many other types of network resources (e.g., bandwidth). The QaaS concept is that multiple users can apply for QKD services to obtain their required SKRs from the same QKD network infrastructure instead of deploying their dedicated QKD networks. Accordingly, how to provide efficient and flexible QaaS for fulfilling the SKR requirements of multiple users over a QKD network infrastructure becomes a new challenge.

Software defined networking (SDN) holds the potential of overcoming this challenge, which is able to add flexibility together with efficient QKD network management. The SDN technique facilitates holding a global perspective with a centralized control manner in dynamic and complicated QKD network circumstances. Recently, SDN technique has been introduced in QKD networks for quantum enabled service automation [19], time-sharing of QKD resources [20,21], QKD channel allocation [22,23], distributed denial of service (DDoS) mitigation [24], key on demand service provisioning [25], and multi-tenant provisioning [26,27]. On the other hand, QKD is able to be utilized to enhance the security of SDN platforms [28,29]. These recent studies have demonstrated the benefits of using SDN technique in QKD networks. As the scale of QKD networks expands, SDN technique is potential to be applied for QKD network control and management.

In this study, we reconsider the QKD network architecture from a holistic view, and use QaaS, SDN, and QKD to form the application plane, control plane, and infrastructure plane of a new SDN for QaaS (SDQaaS) framework, respectively. Our major contributions in this study are four-fold: 1) we propose a new framework of SDQaaS, in which the QaaS functions are developed in the SDN controller; 2) we present the protocol extension, intercommunication workflow, and routing and SKR assignment strategy for QaaS implementation in the SDQaaS framework; 3) we establish a SDQaaS experimental testbed, and the experimental results demonstrate the effectiveness and flexibility of our presented approaches (including the framework, protocol, strategy, and workflow) for QaaS over the QKD network; 4) we perform the numerical simulation, and the simulation results show the ways of increasing the success probability of QKD service requests.

The rest of this paper is structured as follows. The basic concepts and techniques for QaaS is introduced in Section 2. The SDQaaS framework is illustrated in Section 3. The protocol extension, intercommunication workflow, and routing and SKR assignment strategy for QaaS implementation in the SDQaaS framework are presented in Section 4. The experimental testbed and results are demonstrated in Section 5. The simulation results are analyzed in Section 6. Finally, Section 7 concludes this study.

2. Basic concepts and techniques for QaaS

This section introduces basic concepts and techniques for QaaS over the QKD network infrastructure, e.g., QKD protocols, QKD networking components, and function of QaaS.

2.1 QKD protocols

QKD enables two legitimate parties to share ITS symmetric secret keys using a quantum channel (QCh) and a public channel (PCh). The QCh is used to transmit the quantum bits (qubits) that are produced by encoding classical bits (i.e., raw keys) into quantum signals. The PCh is used to exchange the classical information for key sifting and distillation to obtain the final secure bits as secret keys [21]. QKD implementation mainly includes two options, i.e., discrete-variable QKD and continuous-variable QKD [4]. Currently, several QKD protocols have been invented, e.g., BB84 protocol [30] for discrete-variable QKD, and GG02 protocol [31] for continuous-variable QKD. Multiple vendors can develop their QKD systems on the basis of different QKD protocols. In this paper, our study focuses on the networking-layer issues of QKD and is not bound to any specific vendors’ QKD systems or QKD protocols.

2.2 QKD networking components

Due to the point-to-point nature of QKD and quantum no-cloning theorem, quantum repeater (i.e., a component which can forward qubits without cloning or measuring them) is still yet to be used in practical QKD networks [32]. As a compromising solution, a trusted repeater QKD network can be deployed based on present available technologies, which is commonly chosen for the deployment of existing QKD networks such as SECOQC, Tokyo, and China’s Beijing-Shanghai QKD networks [4]. Thus, we choose the trusted repeater QKD network in this study.

In practice, QKD nodes and links are required for QKD network deployment. A QKD link (QL) consists of a QCh and a PCh that can occupy different fibers or different wavelengths in the same fiber with wavelength division multiplexing (WDM) technique [21]. The QKD node in a trusted repeater QKD network can be classified into two categories, namely QKD user node (QUN) and trusted repeater node (TRN). A QUN acts as the end node that can be connected to the source or destination nodes of several users. The TRNs act as the intermediate nodes between two QUNs to achieve long distance end-to-end QKD. The network types for QaaS in this study are backbone network and metropolitan network. Access network is not considered in this paper. For example, China’s Beijing-Shanghai QKD backbone network connects four metropolitan networks (i.e., Beijing, Jinan, Hefei, and Shanghai), where the backbone network has 32 QUNs and TRNs in total, and each metropolitan network has more than 10 QUNs and TRNs in total [4].

The structure of a TRN or a QUN used in this paper is the same as the structure of a QKD node introduced in Ref [26], which is mainly composed of the QKD sender, QKD receiver, and secret-key server. A QKD sender is connected to a QKD receiver via a QL to realize point-to-point QKD for producing secret keys. A secret-key server can be used to store the secret keys produced by point-to-point QKD as well as relay the secret keys for end-to-end QKD. The QKD sender, QKD receiver, and secret-key server are enclosed within the security perimeter by using security infrastructure to assure that each QUN/TRN is trustable. Additionally, in a SDN scenario, the structure of a SDN-controlled QUN/TRN used in this paper is formed by a QUN/TRN and a SDN agent, which is illustrated in Ref [33]. Also, the connection of the QKD sender/receiver, secret-key server, SDN agent, and SDN controller can be found in Ref [33].

2.3 Function of QaaS

The natural principle of QaaS is that of QKD network operator offering QKD network infrastructure and QKD services, while multiple users can apply for different QKD services to obtain their required SKRs from the same QKD network infrastructure. The function of QaaS is providing QKD services to fulfil the SKR requirements of multiple users over a QKD network infrastructure. An example of QaaS for fulfilling the SKR requirements of two users is illustrated in Fig. 1. We assume that QUN-A and QUN-C are located at two distant places. TRN-B is placed between QUN-A and QUN-C to realize long-distance end-to-end QKD. The point-to-point QKD is realized between QUN-A and TRN-B, and TRN-B and QUN-C, respectively, and then different SKRs can be produced on QL-a and QL-b.

 

Fig. 1 An example of QaaS for fulfilling the SKR requirements of two users.

Download Full Size | PDF

Upon a user (e.g., User-1 or User-2 in Fig. 1) requesting a QKD service to fulfill its SKR requirement between QUN-A and QUN-C, we first compute and select the QKD path between QUN-A and QUN-C. The selected QKD path is along the QUN-A, TRN-B, and QUN-C. Then, we query the required SKR of QKD service request for each user (e.g., 2 and 3 kb/s SKR requirements of QKD service requests for User-1 and User-2, respectively). Meanwhile, we search the available SKR on each QL (e.g., 8 and 7 kb/s on QL-a and QL-b, respectively) along the QKD path. The available SKR is a real-time value based on the QL condition, which can be obtained by the QUN and TRN reporting to the SDN controller in real time. If the available SKR can satisfy the SKR requirement of a QKD service request, we perform SKR selection (i.e., selecting the required SKR from the corresponding QL) for this QKD service request, otherwise this QKD service request is rejected.

After SKR selection is successfully accomplished, TRN-B uses the produced secret keys on QL-b (e.g., SKR_b-1 and SKR_b-2 for User-1 and User-2, respectively) to encrypt the produced secret keys on QL-a (e.g., SKR_a-1 and SKR_a-2 for User-1 and User-2, respectively). The SKR information (e.g., SKR_a-1, SKR_a-2, SKR_b-1, and SKR_b-2) can be stored in a database. Then, TRN-B relays the encrypted information to QUN-C. QUN-C can use the produced secret keys on QL-b to decrypt the corresponding encrypted information, and can share the produced secret keys on QL-a with QUN-A. Note that the produced secret keys based on SKR_a-1 and SKR_b-1 (or SKR_a-2 and SKR_b-2) should have the same secret-key size, due to the one-time pad algorithm [34] is used here for ITS encryption of secret keys. Finally, the produced secret keys based on SKR_a-1 (or SKR_a-2) are assigned to User-1 (or User-2).

In practice, the attainable SKR on each QL can be different and can be segmented into many small SKR slots. The SKR slot is defined as the minimum SKR unit that can accommodate the SKR requirement of a QKD service request [26]. As an example, a SKR slot is set to 1 kb/s in Fig. 1. In this study, we use the SKR sharing scheme proposed in Ref [26]. and consider a uniform SKR sharing, where the unit of a SKR slot is b/s and each SKR slot has the same size. Due to the secret keys provided for each user are different and the precise time synchronization is assumed in this study, no isolation is provided between two adjacent SKR slots and there is no interference between users in the time domain.

3. SDQaaS framework

To implement QaaS for multiple users over a QKD network, we introduce SDN technique for efficient QKD network control and management, and propose a new SDQaaS framework, as illustrated in Fig. 2. This SDQaaS framework is composed of three planes in a top-down order, i.e., application, control, and infrastructure planes. Different protocols (e.g., OpenFlow and NETCONF [35]) can be applied to implement the southbound interface between infrastructure plane and control plane, which is used to transmit control and configuration request/response messages (e.g., control and configure secret-key exchange, storage, relay, assignment, and destruction). In this study, we choose OpenFlow protocol (OFP) as the southbound interface protocol, and the feasibility of using OFP in a SDN-enabled QKD network has been experimentally verified [24,25]. We extend the OpenFlow Plugin and OpenFlow Java modules to implement the southbound interface. The northbound interface between application plane and control plane is implemented by RESTful API, which is used to transmit QKD service request/response messages. The request/response messages of QKD service creation, modification, and deletion are implemented using the POST, PUT, and DELETE methods of Hypertext Transfer Protocol (HTTP) [36], respectively. We elaborate the three planes in this SDQaaS framework as follows.

 

Fig. 2 The SDQaaS framework.

Download Full Size | PDF

Given the southbound and northbound interfaces cannot know the real secret keys, the security of secret keys can be assured. In practice, there are several security attacks that arise along with SDN. A variety of classical [39,40] and quantum [28,29] defense techniques have been proposed to protect the SDN itself from security attacks. The security of SDN itself is not our focus in this study. As an example, by placing a QUN co-located with the SDN controller, and then connect it to each QUN on the infrastructure plane via the TRNs and QLs, the security of control channels can be enhanced using the secret keys.

4. QaaS implementation approaches

In this section, we present the protocol extension, intercommunication workflow, and routing and SKR assignment strategy for QaaS implementation in the SDQaaS framework. Note that the QaaS implementation approaches will occur for an independent QKD only network.

4.1 Protocol extension

In this study, we extend the standard OFP v1.3.0 [41] to enable QKD service creation, modification, and deletion, since the original OFP can only support packet switching in the electrical domain. Instead of extending the current OpenFlow messages (e.g., “PACKET_IN” and “FLOW_MOD”) [42], we add new messages attached to an OFP v1.3.0 header because it can be easily implemented in an ODL-based platform by using YANG tools [43]. The main structure of extended OFP messages for QKD service creation request and response, QKD service modification request and response, and QKD service deletion request and response are depicted in Figs. 3(a)–3(f), respectively. The OFP v1.3.0 header is composed of version, type, length, and xid. The version field indicates the OFP version being used. The type field indicates the type of the message. In this study, the message types of QKD service creation/modification/deletion request and response are configured as 32 and 33, respectively. The length field indicates the total length of the message. The xid (i.e., transaction ID) is a unique value used to match requests to responses.

 

Fig. 3 The extended OFP v1.3.0 messages for QKD service (a) creation request, (b) creation response, (c) modification request, (d) modification response, (e) deletion request, and (f) deletion response.

Download Full Size | PDF

Besides the OFP v1.3.0 header, we add 32 bits for QKD service ID to represent a QKD service and 32 bits for OF-QUN/OF-TRN ID to represent an OF-QUN/OF-TRN. Additionally, we add 32 bits for message function to show the different functions of extended OFP messages. For example, we use 0x0000FFFF, 0xFFFFFFFF, and 0xFFFF0000 to indicate the message functions of QKD service creation, modification, and deletion requests/responses, respectively. We also add 32 bits for both the input port and output port of each OF-QUN/OF-TRN along the QKD path of this QKD service. Specifically, we add 128 bits for SKR slot ID to describe the usage of 128 SKR slots (e.g., 1 is busy and 0 is free). Based on the number of attainable SKR slots on each QL, the number of bits for SKR slot ID can be changed. As shown in Figs. 3(a) and 3(c), the SKR slot usage after QKD service creation and modification can be different, since a user can request to modify its SKR requirement. Moreover, as illustrated in Figs. 3(b), 3(d), and 3(f), we add 32 bits for QKD service responses to indicate the status of QKD service creation/modification/deletion.

4.2 Intercommunication workflow

The intercommunication workflow among the three planes in SDQaaS framework needs to be designed to achieve QaaS. Initially, the SDN controller on the control plane configures all the OF-QUNs and OF-TRNs on the infrastructure plane to accomplish QKD network initialization. After TCP session, the SDN controller achieves OpenFlow handshake and keeps alive with each OF-QUN/OF-TRN. Then, the SDN controller initializes all the OF-QUNs/OF-TRNs and acquires the detailed information of each OF-QUN/OF-TRN. Based on the instructions from QKD network operator on the application plane, the SDN controller configures point-to-point QKD connections via connecting OF-QUNs to the corresponding OF-QUNs/OF-TRNs using QLs to constitute the QKD network. After the QKD network operates smoothly, the QKD network information (e.g., QKD network topology and SKR on each QL) will be automatically reported to the SDN controller.

After QKD network initialization, QKD network operator generates multiple QKD service requests according to the SKR requirements of different users, and sends these requests to the SDN controller. We consider that QaaS involves the creation, modification, and deletion of QKD services. The intercommunication workflow for successful QKD service creation is depicted in Fig. 4. Upon receiving a QKD service creation request, the SDN controller first computes and selects the QKD path between the source OF-QUN and destination OF-QUN. Then, SDN controller searches the real-time available SKR slots on each QL along the selected QKD path, and selects the required SKR slots. If the real-time available SKR slots are capable of satisfying the SKR requirement of this request, the SDN controller will configure source OF-QUN, intermediate OF-QUN(s)/OF-TRN(s), and destination OF-QUN along the QKD path to accomplish SKR slot assignment for QKD service creation. Otherwise this QKD service creation request will be rejected. The intermediate OF-QUN(s)/OF-TRN(s) along the selected QKD path can relay the secret keys for long-distance end-to-end QKD. After accomplishing SKR slot assignment for QKD service creation, a success response will be sent back to the QKD network operator.

 

Fig. 4 The intercommunication workflow for successful QKD service creation.

Download Full Size | PDF

In addition, when the SKR requirement of a user changes, the established QKD service for this user needs to modify its SKR requirement. Upon receiving a QKD service modification request, SDN controller first performs the steps 3 and 4 numbered in Fig. 4. If the real-time available SKR slots along the QKD path can satisfy the modified SKR requirement, SKR slot re-assignment (i.e., steps 5 to 10 numbered in Fig. 4) will be performed for QKD service modification. Otherwise the QKD service modification request will be rejected. Moreover, QKD network operator can request the deletion of a QKD service when the QKD service has expired (i.e., at the end time of QKD service request). Upon receiving a QKD service deletion request, SDN controller configures the OF-QUNs/OF-TRNs to stop assigning SKR slots to this QKD service, and deletes the information of this QKD service.

4.3 Routing and SKR assignment strategy

To present the routing and SKR assignment strategy, we first give the QKD network model and QKD service request model as follows. The QKD network topology is denoted by G(V_Q, V_T, E, K), where V_Q, V_T, E, and K denote the sets of OF-QUNs, OF-TRNs, QLs, and attainable SKR slots on each QL, respectively. We assume that the number of attainable SKR slots on each QL is the same, which is fixed to |K|. The set of incoming QKD service requests is denoted by R. We model a QKD service request as r(s_r, d_r, t_s, t_e, k_c, m, k_m), where s_r, d_r, t_s, and t_e denote the source OF-QUN, destination OF-QUN, start time, and end time of QKD service request r, respectively. The required number of SKR slots for QKD service (corresponding to r) creation is denoted by k_c. The number of times for the modification of QKD service (corresponding to r) within the holding time is denoted by m. The changed number of SKR slots for modifying QKD service (corresponding to r) each time is denoted by k_m. Note that the value of k_m can be positive or negative, since the required number of SKR slots for modifying QKD service each time can be increased or decreased.

The routing and SKR assignment strategy for QKD service creation and modification is illustrated in Fig. 5. The overall objective of this strategy is to accommodate the QKD service requests successfully for multiple users as many as possible over a QKD network. First, Dijkstra algorithm is utilized to compute and select the shortest QKD path between the source OF-QUN and destination OF-QUN of QKD service request, since the shortest QKD path is beneficial to reduce the required number of QLs and SKR slots for QKD service creation. The worse-case complexity of routing is O(|V_Q ∪V_T |²). Then, we search the real-time available SKR slots on each QL along the selected QKD path, which can be obtained by the OF-QUN and OF-TRN reporting to the SDN controller in real time. The resource module developed in the SDN controller is used to store and update point-to-point SKR information (including the attainable and real-time available SKRs) on each QL.

 

Fig. 5 The routing and SKR assignment strategy for QKD service creation and modification.

Download Full Size | PDF

If the SKR requirement of this QKD service creation can be satisfied, the first fit (FF) algorithm [21–23] will be utilized to select and assign the required SKR slots for QKD service creation, otherwise this QKD service request is rejected. The FF algorithm is chosen in this study due to its low complexity and small computation overhead [21]. Using FF algorithm, all the real-time available SKR slots are numbered, in which a SKR slot with small serial number is selected and assigned before a SKR slot with large serial number. In this study, we treat all the QKD service requests equally and process the QKD service requests one by one as time proceeds. This is reasonable since we assume that QKD service requests arrive dynamically and each of them cannot tolerate queuing delay. Also, if a concurrency situation occurs, the QKD service requests will be processed randomly. Moreover, SKR re-assignment is performed for QKD service modification. If the SKR requirement of this QKD service modification is satisfied within the holding time, FF algorithm is performed again to select and assign the required SKR slots for QKD service modification, otherwise this QKD service request is rejected.

5. Experimental testbed and results

5.1 Experimental testbed

The SDQaaS experimental testbed is depicted in Fig. 6. We consider that there is only one QKD network operator in this testbed. Based on the received SKR requirements of different users, QKD network operator can generate and send multiple QKD service requests to SDN controller. The SDN controller is developed based on ODL controller platform. The northbound interface between QKD network operator and SDN controller is implemented with RESTful API and developed based on JavaScript Object Notation (JSON) to support HTTP. The QKD service creation, modification, and deletion request/response messages between QKD network operator and SDN controller are implemented using the POST, PUT, and DELETE methods of HTTP, respectively. The southbound interface between SDN controller and OF-QUNs/OF-TRNs is implemented and developed based on the extended OFP v1.3.0 messages as described in Section 4.1.

 

Fig. 6 The SDQaaS experimental testbed.

Download Full Size | PDF

The SKR on each QL can be different due to the different physical-layer conditions of QLs, which can be managed with the assist of the developed OFA and the resource module in SDN controller. Also, each QUN/TRN needs to open its control interface and data to the corresponding OFA. Then the OF-QUN and OF-TRN can report accurate real-time available SKRs to the SDN controller. Given the presented approaches for QaaS implementation are not bound to any specific vendors’ QKD systems or QKD protocols in this study, we develop Open vSwitch (OVS) [44] to serve as the OFA and the detailed information of each QUN/TRN is pre-stored in its connected OVS. We utilize an OVS to emulate the networking-layer function of a QUN/TRN, and then an OVS is referred as an OF-QUN/OF-TRN in this experimental testbed. Since there is no real QKD physical device in this testbed, the physical-layer issues are not considered and the physical-layer parameters (e.g., quantum bit error rate) cannot be measured. However, the protocol, strategy, and workflow are developed in this networking-layer experimental testbed and the networking-layer parameters (e.g., service latency) can be measured. We only focus on the networking-layer issues of QKD and demonstrate the benefits of our presented approaches for QaaS implementation.

In this testbed, we deploy six OF-QUNs and two OF-TRNs to constitute the QKD network, where eight virtual machines are installed and configured in IBM servers to function as OVS. In addition, one virtual machine is installed in IBM servers to launch the developed SDN controller. Figure 6 also uses distinct colors to indicate the unique IP and ID of each OF-QUN/OF-TRN as well as the unique IP of QKD network operator and SDN controller. We apply the Wireshark network protocol analyzer to capture and analyze the HTTP messages between QKD network operator and SDN controller as well as the OFP messages between SDN controller and OF-QUNs/OF-TRNs.

5.2 Experimental results

In the initial stage, SDN controller configures all the OF-QUNs/OF-TRNs based on the QKD network topology in Fig. 6 to accomplish QKD network initialization. The number of attainable SKR slots on each QL is fixed to 128 in this testbed. As an example, if the attainable SKR on each QL with fiber distance of 50.5 km is 1.2 Mb/s [45], a SKR slot is set to 9.375 kb/s. After QKD network initialization, QaaS is performed to fulfil the SKR requirements of different users. For a specified bidirectional QKD service request between OF-QUN₄ and OF-QUN₁, we demonstrate QKD service creation, modification, and deletion in the experimental testbed to verify our presented approaches for QaaS implementation. The overall intercommunication workflow for the creation, modification, and deletion of this QKD service is numbered in Fig. 6, where each step is detailed in Figs. 7–10. The selected bidirectional QKD path for this QKD service is along the OF-QUN₄, OF-QUN₂, OF-TRN₁, and OF-QUN₁, as depicted in Fig. 6.

 

Fig. 7 HTTP message capture of QKD service creation, modification, and deletion request/response between QKD network operator and SDN controller.

Download Full Size | PDF

 

Fig. 8 OFP message capture of QKD service creation (a) request and (b) response between SDN controller and OF-QUNs/OF-TRNs.

Download Full Size | PDF

 

Fig. 9 OFP message capture of QKD service modification (a) request and (b) response between SDN controller and OF-QUNs/OF-TRNs.

Download Full Size | PDF

 

Fig. 10 OFP message capture of QKD service deletion (a) request and (b) response between SDN controller and OF-QUNs/OF-TRNs.

Download Full Size | PDF

The QKD service creation is performed in steps 1 to 4, where the HTTP message capture of QKD service creation request (step 1) and response (step 4) between QKD network operator and SDN controller is shown in Fig. 7, and the OFP message capture of QKD service creation request (step 2) and response (step 3) between SDN controller and OF-QUNs/OF-TRNs is illustrated in Fig. 8. The OFP message capture in Figs. 8(a) and 8(b) can conform to the extended OFP v1.3.0 messages in Figs. 3(a) and 3(b), respectively. The detailed QKD service ID, OF-QUN/OF-TRN IP and ID, SDN controller IP, message function of QKD service creation, SKR slot usage, input port and output port of OF-QUNs/OF-TRNs along the selected bidirectional QKD path, and status of QKD service creation can be found in Fig. 8. After the successful creation of this QKD service, two SKR slots are selected from the real-time available SKR slots on each QL (i.e., QL₁, QL₂, and QL₃) along the selected bidirectional QKD path. The selected two SKR slots are assigned to satisfy the SKR requirement of QKD service creation.

Then, steps 5 to 8 achieve QKD service modification, since an established QKD service can modify its SKR requirement within the holding time. The steps 5 and 8 are the QKD service modification request and response between QKD network operator and SDN controller, respectively, whose HTTP message capture is shown in Fig. 7. The steps 6 and 7 are the QKD service modification request and response between SDN controller and OF-QUNs/OF-TRNs, respectively, whose OFP message capture is depicted in Fig. 9. The detailed OFP messages (including QKD service ID, OF-QUN/OF-TRN IP and ID, SDN controller IP, message function of QKD service modification, SKR slot usage, and status of QKD service modification) can be found in Figs. 9(a) and 9(b), which are able to conform to the extended OFP v1.3.0 messages in Figs. 3(c) and 3(d), respectively. After the successful QKD service modification, the SKR slot usage on each QL (i.e., QL₁, QL₂, and QL₃) along the selected bidirectional QKD path is modified to one SKR slot, due to the selected one SKR slot is re-assigned to satisfy the SKR requirement of QKD service modification.

Finally, QKD service deletion can be performed in steps 9 to 12 at the end time of QKD service request. The captured HTTP messages of QKD service deletion request (step 9) and response (step 12) between QKD network operator and SDN controller are depicted in Fig. 7. The captured OFP messages of QKD service deletion request (step 10) and response (step 11) between SDN controller and OF-QUNs/OF-TRNs are illustrated in Figs. 10(a) and 10(b), respectively. The detailed OFP messages in Figs. 10(a) and 10(b) consist of the detailed QKD service ID, OF-QUN/OF-TRN IP and ID, SDN controller IP, message function of QKD service deletion, and status of QKD service deletion, which are capable of following the extended OFP v1.3.0 messages in Figs. 3(e) and 3(f), respectively.

We also report the latencies of QKD service creation, modification, and deletion, as listed in Table 1. The QKD service creation/modification/deletion latency is the time interval during the QKD network operator sending out QKD service creation/modification/deletion request (i.e., step 1/5/9 in Fig. 7) and receiving QKD service creation/modification/deletion response (i.e., step 4/8/12 in Fig. 7). The bidirectional QKD service requests with different hop counts along their bidirectional QKD paths are triggered by the QKD network operator. The latencies for three QKD services with the same hop count are averaged to obtain the values in Table 1. The latencies of QKD service creation, modification, and deletion all increase with the hop count rising, because the number of OF-QUNs/OF-TRNs along the QKD path is increased. For a specified bidirectional QKD service, the creation latency is much longer than the modification latency, while the modification latency is a little longer than the deletion latency. The reason is that QKD service creation needs to select and configure a bidirectional QKD path between the source and destination OF-QUNs as well as perform SKR assignment, whereas QKD service modification only performs SKR re-assignment.

Table 1. QKD service creation, modification, and deletion latencies.

View Table

6. Simulation results and analysis

Besides the experimental testbed, simulation is performed to evaluate the performance of our presented approaches under a heavy traffic load scenario. We adopt NSFNET topology [28] in simulation, where 14 backbone nodes function as the OF-QUNs with a number of OF-TRNs placed in between. The point-to-point QKD process is accomplished before the arrival of QKD service requests, and we assume that the number of attainable SKR slots on each QL is the same. We consider that 50,000 QKD service requests are randomly generated between any pair of OF-QUNs following a Poisson process. The setups of s_r and d_r are randomly selected from the NSFNET topology. The setups of t_s and t_e follow a Poisson process. The setups of k_c, m, and k_m will be given and discussed below.

A performance metric, namely success probability of QKD service requests (defined as the ratio of the total accepted QKD service requests to the total incoming QKD service requests), is used for performance evaluation. Also, the success probability can be counted by the blocking probability, since the sum of success probability and blocking probability is equal to 1. A QKD service request will be rejected/blocked for two reasons, i.e., SKR assignment failure and SKR re-assignment failure, which can be isolated during the QKD service creation and modification. In addition, our simulation is based on a loss system (i.e., Erlang B system [46]), where queuing is typically not assumed. The arrival rate and departure rate of QKD service requests in this loss system can determine the value of traffic load, since the traffic load is defined as the ratio of the arrival rate to the departure rate of QKD service requests. The simulation is repeated 100 times to obtain the average value for each data point.

Figures 11(a) and 11(b) show the results of success probability of QKD service requests versus traffic load with different |K| and k_c, respectively, where we fix k_c ∈ [4,8] in Fig. 11(a) and |K| = 120 in Fig. 11(b). Moreover, QKD service modification is not considered in Fig. 11, i.e., the number of times for QKD service modification is set to 0 (m = 0). It can be observed that the success probability of QKD service requests gradually declines with the traffic load rising. The reason is that the increase of traffic load will increase the arrival rate or decrease the departure rate of QKD service requests, which can increase the holding time (determined by t_s and t_e) of some QKD service requests. From Fig. 11(a) we can find that the success probability of QKD service requests rises when the number of attainable SKR slots on each QL (i.e., |K|) grows, since the total available SKR slots are increased. As illustrated in Fig. 11(b), the success probability of QKD service requests decreases as the range of SKR slot requirements for QKD service creation (i.e., k_c) expands, which results from the increased total SKR slot requirements. Thus, in order to accommodate QKD services as many as possible with the available SKR slots, the success probability of QKD service requests can be increased via reducing the range of k_c or increasing the value of |K|. However, we need to lower the flexibility of SKR slot requirements for QKD service creation, or sacrifice more cost for producing higher SKR over the QKD network.

 

Fig. 11 The success probability of QKD service requests versus traffic load with different (a) |K| and (b) k_c.

Download Full Size | PDF

The results of success probability of QKD service requests versus traffic load with different m and k_m are plotted in Figs. 12(a) and 12(b), respectively. We assume that the QKD service modification time is evenly located between the start time and end time of QKD service request according to the number of times for QKD service modification. In Fig. 12, the value of k_c is distributed within [4,8]. We also fix |K| = 144 and k_m = 1 in Fig. 12(a) as well as |K| = 132 and m = 1 in Fig. 12(b). From Fig. 12(a) we can see the success probability of QKD service requests decreases with the increase of the number of times for QKD service modification (i.e., m). This is because the value of k_m is positive and the required number of SKR slots for modifying QKD service each time is increased. As depicted in Fig. 12(b), the success probability of QKD service requests rises as the changed number of SKR slots for modifying QKD service each time (k_m) reduces, due to the required number of SKR slots for modifying QKD service each time is decreased. As an example, all the QKD service requests can be successfully accepted when the traffic load is 125 Erlang, |K| = 132, k_c ∈ [4,8], m = 1, and k_m = −2. Therefore, the success probability of QKD service requests can be increased via decreasing the values of m and k_m when the value of k_m is positive, or increasing the value of m and reducing the value of k_m when the value of k_m is negative. That is, the SKR slot requirements should be gradually reduced with the modification of QKD service.

 

Fig. 12 The success probability of QKD service requests versus traffic load with different (a) m and (b) k_m.

Download Full Size | PDF

7. Conclusion

This study introduces SDN technique to achieve efficient and flexible QaaS as well as proposes a new framework of SDQaaS. We consider that QaaS involves the creation, modification, and deletion of QKD services. The protocol extension, intercommunication workflow, and routing and SKR assignment strategy are presented for QaaS implementation in SDQaaS framework. A SDQaaS experimental testbed is established, and experimental results show the effectiveness and flexibility of our presented approaches for QaaS over the QKD network. Also, numerical simulation is performed, and simulation results verify that the success probability of QKD service requests can be increased via lowering the flexibility of SKR requirements for QKD service creation, sacrificing more cost to produce higher SKR over the QKD network, or gradually reducing SKR requirements with the modification of QKD service. For the future work, we will further demonstrate several use cases in the SDQaaS framework.