## 3 Software-Defined Delay Tolerant Networking Architecture  
Given that the scaling of space DTN routing is still an active area of research, an SDN approach to managing scalability in space DTN networks is proposed. SDN is a technique used by network operators to manage their large networks in a scalable manner by dividing their networks into a control plane and data plane, and centralizing the control plane. The data plane consists of network routers that handle the task of forwarding data through the network; however, the routes and policies of this data forwarding are dictated by a centralized SDN controller. A benefit of this architecture is that it enables network operators to monitor and rapidly change the behavior of large portions of the network, assuming a control plane link exists. These are desirable qualities for a space DTN network operator that may want to change the behavior of their network as needed due to changing technical or political constraints. However, because SDN requires control plane links between the SDN controller and the nodes within the network, it is unclear how this can be applied to the DTN environment where links are inherently intermittent. There is previous work in applying SDN to DTN networks in a terrestrial military context in Last-Mile Tactical Edge Networking (TEN) [28]. This is a particular adaptation of SDN where any node within a local DTN network can become the SDN controller via an election algorithm. This solves the issue of each node maintaining a link to a SDN controller by making any node within a local network eligible to become an SDN controller. However, this architecture was designed for a terrestrial military context which has properties that may not be desirable for the space environment. Firstly, nodes in this last-mile TEN can be thought of as highly mobile drones in a harsh battlefield environment where there are several different types of data flows that require different levels of Quality of Service (QoS). For example, a live video feed is data that must never be stored and it is imperative that an SDN controller is available to ensure that this video feed has priority over other data. This highly dynamic and fast-paced environment are conditions that are not as relevant in the less dynamic space environment. Secondly, the ability for a controller to always be present is required in this environment to ensure that these QoS guarantees are always met, which may not be an important in a space network and too restrictive of a constraint. Lastly, a downside of this highly dynamic design is that the controller is not a constant device, which means that a network operator wishing to access the controller and change QoS policies would not be able to unless they can determine which device is the controller at any given moment. While this is not something needed for the Last-Mile TEN environment, the ability to have human intervention in network behavior is a desirable property for space networks which are more stable and subject to political and social constraints. The SDDTN approach we propose keeps the constraints of the space DTN environment in mind. In our SDDTN architecture, we approach the issue of having reliable links between the controller and network nodes by dividing the network into clusters. As shown in Figure 6 within each cluster is a single SDDTN cluster controller and several SDDTN nodes. Each SDDTN node should have all the behavior of a regular DTN node as specified by the BP specification, in addition to having a control plane link to its respective cluster controller. Through this link SDDTN nodes are able to report relevant network status updates to the cluster controller. Subsequently, using local neighborhood information from nodes within its cluster, the controller is able to make decisions and propagate these decisions (such as generating and sending contact plans) to the nodes within its cluster.