Abstract
Network function (NF) developers have traditionally prioritized performance when creating new packet processing capabilities. This was usually driven by a market demand for highly available solutions with differentiating features running at line rate, even at the expense of flexibility and tightly-coupled monolithic designs. Today, however, the market advantage is achieved by providing more features in shorter development cycles and quickly deploying them in different operating environments. In fact, network operators are increasingly adopting continuous software delivery practices as well as new architectural styles (e.g., microservices ) to decouple functionality and accelerate development. A key challenge in revisiting NF design is state management, which is usually highly optimized for a deployment by carefully selecting the underlying data store. Therefore, migrating to a data store that suits a different use case is time-consuming as it requires code refactoring and adaptation to new application programming interfaces, APIs. As a result, refactoring NF software for different environments can take up to months, reducing the pace at which new features and upgrades can be deployed in production networks. In this paper, we demonstrate experimentally that it is feasible to introduce an abstraction layer to decouple NF state management from the data store adopted while still approaching line-rate performance. We present FlexState , a state management system that exposes data store functionality as configuration options , which reduces code refactoring efforts. Experiments show that FlexState achieves significant flexibility in optimizing the state management, and accelerates deployment on new scenarios while preserving performance and scalability.
Highlights
Network functions (NFs), such as network address translators (NATs), load balancers or intrusion detection systems (IDS) are stateful
DOES OUR TESTBED SUPPORT LINE RATE? Answering this question is important because we want to make sure that the testbed we use for evaluating FlexStateis able to serve packets arriving at line rate
The systems that manage the state of network functions (NFs) are tightly coupled to the specific data store implemented internally, so NFs relying on the APIs of such systems are tied to the specific data store
Summary
Network functions (NFs), such as network address translators (NATs), load balancers or intrusion detection systems (IDS) are stateful For this reason, developers must deal with the inherent trade-off of maintaining a consistent state shared across packet flows manipulated by multiple NF instances while processing packets at line rate [1], [2]. A first step to overcome this challenge is to delegate the management of NFs state information to dedicated systems Such systems are designed and optimized for a specific set of requirements driven by conflicting needs, which determine the appropriate data store applicable to a specific use case. When deployed in production environments, NFs are expected to scale with the traffic load For this reason, there can be multiple NF instances acting on a packet flow, or sharing states across multiple flows concurrently. The per-flow state in a NAT NF contains the pair of IP addresses of a given TCP/UDP flow, while the cross-flow state includes the available IP addresses and port numbers that can be used for the translation
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
