The current strong divide between applications and the network control plane is desirable for many reasons; but a downside is that the network is kept in the dark regarding the ultimate purposes and intentions of applications and, as a result, is unable to optimize for these. An alternative approach, explored in this paper, is for applications to declare to the network their abstract intents and assumptions; e.g. "this is a Tweet", or "this application will run within a local domain". Such an enriched semantic has the potential to enable the network better to fulfill application intent, while also helping optimize network resource usage across applications. We refer to this approach as 'intent driven networking' (IDN), and we sketch an incrementally-deployable design to serve as a stepping stone towards a practical realization of the IDN concept within today's Internet.
Other relevant efforts include: yanc @cite_7 , an abstraction in Linux to facilitate network control logic to be written in any language; FlowOS @cite_20 , a programming model to capture and process Internet flows; NOSIX @cite_13 , an abstraction layer to enable portable deployments; and P4 @cite_14 , a language to configure switches to process packets and match header fields.
@cite_14 @cite_20 @cite_13 @cite_7
2166195138 2063470101 1994926493 2017639917
Rather than creating yet another network controller which provides a framework in a specific (potentially new) programming language and runs as a monolithic application, in this paper we extend an existing operating system and leverage its software ecosystem in order to serve as a practical SDN controller. This paper introduces yanc, a controller platform for software-defined networks which exposes the network configuration and state as a file system, enabling user and system applications to interact through standard file I O, and to easily take advantage of the tools available on the host operating system. In yanc, network applications are separate processes, are provided by multiple sources, and may be written in any language. Applications benefit from common and powerful technologies such as the virtual file system (VFS) layer, which we leverage to layer a distributed file system on top of, and Linux namespaces, which we use to isolate applications with different views (e.g., slices). In this paper we present the goals and design of yanc. Our initial prototype is built with the FUSE file system in user space on Linux and has been demonstrated with a simple static flow pusher application. Effectively, we are making Linux the network operating system. In spite of the standardization of the OpenFlow API, it is very difficult to write an SDN controller application that is portable (i.e., guarantees correct packet processing over a wide range of switches) and achieves good performance (i.e., fully leverages switch capabilities). This is because the switch landscape is fundamentally diverse in performance, feature set and supported APIs. We propose to address this challenge via a lightweight portability layer that acts as a rendezvous point between the requirements of controller application and the vendor knowledge of switch implementations. Above, applications specify rules in virtual flow tables annotated with semantic intents and expectations. Below, vendor specific drivers map them to optimized switch-specific rule sets. NOSIX represents a first step towards achieving both portability and good performance across a diverse set of switches. P4 is a high-level language for programming protocol-independent packet processors. P4 works in conjunction with SDN control protocols like OpenFlow. In its current form, OpenFlow explicitly specifies protocol headers on which it operates. This set has grown from 12 to 41 fields in a few years, increasing the complexity of the specification while still not providing the flexibility to add new headers. In this paper we propose P4 as a strawman proposal for how OpenFlow should evolve in the future. We have three goals: (1) Reconfigurability in the field: Programmers should be able to change the way switches process packets once they are deployed. (2) Protocol independence: Switches should not be tied to any specific network protocols. (3) Target independence: Programmers should be able to describe packet-processing functionality independently of the specifics of the underlying hardware. As an example, we describe how to use P4 to configure a switch to add a new hierarchical label. Starting from the seminal work of Volpano and Smith, there has been growing evidence that type systems may be used to enforce confidentiality of programs through non-interference. However, most type systems operate on high-level languages and calculi, and ''low-level languages have not received much attention in studies of secure information flow'' (Sabelfeld and Myers, [Language-based information-flow security. IEEE Journal on Selected Areas in Communications 2003; 21:5-19]). Therefore, we introduce an information flow type system for a low-level language featuring jumps and calls, and show that the type system enforces termination-insensitive non-interference. Furthermore, information flow type systems for low-level languages should appropriately relate to their counterparts for high-level languages. Therefore, we introduce a compiler from a high-level imperative programming language to our low-level language, and show that the compiler preserves information flow types.