3.7.4 Metadata
CATENAE does not support the delivery of metadata to the network functions. For instance, a user’s wireless link quality information has to be delivered to the network functions that may need it, e.g., transcoders, using out-of-bound channels. Other solutions support metadata delivery requiring modifications to the VNFs [45,48].
3.8 Conclusion
We presented CATENAE, a SFC system for the SGi-LAN. CATENAE can be de-ployed on legacy infrastructures, introducing effective SFC without paying the over-heads of additional packet header fields, but still scaling to provide fine-grained poli-cies for millions of network flows. Given that service function chain configurations are performed proactively and do not require any dynamic action on the data plane, the only CATENAE’s throughput bottlenecks are in the classifiers used to classify upstream and downstream traffic. We presented both an architectural solution and a technological solution to address the two cases, respectively. For the upstream di-rection, we ensure only upstream traffic is handled by the upstream classifier. Given that upstream traffic typically contributes just the 10% of the overall system work-load, this allows us to support the traffic growth expected in the mid-term using a state of the art software switch as classifier. For the downstream direction, instead, we presented HSwitch, a hybrid software/hardware classifier based on commodity SDN switches. HSwitch caches the heavier flows in its hardware layer, while the software layer guarantees the possibility to install the big number of flows required to support the CATENAE’s traffic steering method.
CATENAE lacks some advanced features provided by related work, e.g., support
Chapter 3 Single-domain Service Function Chains 58
for network functions’ metadata. However, the lack of such features is traded with the possibility of deploying the system today, on legacy infrastructures. In effect, our design experience shows that those desired features may be still lacking in other system’s components as well. For example, network functions do not support meta-data exchange yet. Thus, CATENAE provides support for service function chaining with today’s technologies, while the mentioned advanced features could be eventu-ally introduced as the legacy infrastructure gradueventu-ally evolves, when they are actueventu-ally needed.
As a final remark, our experience suggests that a design tailored to the problem can help in solving issues that otherwise would require much more expensive solu-tions. Notice that, in the past, highly-specialized solutions in networking were not considered economically convenient. Traditionally, a network operator would buy an expensive hardware box, which was required to support a number of different deployment scenarios, since its monolithic design would not allow for modifications.
Today, we have to observe that the landscape is considerably changed with the introduction of software-based networks. In fact, the “swiss-knife” solution is not required anymore since the solution now runs on a programmable infrastructure.
That is, the solution is not a monolithic design that cannot be changed anymore, instead, it can evolve overtime to meet the changing requirements and constraints.
Chapter 4
Internet-wide Service Function Chains
4.1 Introduction
Since the early stage, the research community has been mainly focused on Single-domain SFCs. Mobile networks and DC networks are the most notable use-cases in such problem space. Their constraints, technical specifications, and requirements, have steered the Single-domain SFC solutions of the research community. At high-level, we can characterize single-domain SFC systems as follows:
I Full visibility of the network topology where the NFs are deployed;
II Full control of the underlying network topology i.e., they assume to have the ability to make changes to the network infrastructure, for instance with SDN;
III SFC enforced transparently to users’ traffic i.e., users are SFC-unaware.
The full visibility and control of the underlying network topology properties orig-inate from the fact that NFs provider and consumer are represented by the same stakeholder in the main use cases (e.g., mobile network, DC network). In fact, Mo-bile Network Operators (MNOs) and DC operators represent the entity defining the SFC, and at the same time, enforcing it. Further, in single-domain SFCs users are generally SFC-unaware because the NFs are introduced by the content server and/or the infrastructure operator (e.g., MNO, DC), and do not provide any explicit service to the clients.
Chapter 4 Internet-wide Service Function Chains 60
We argue that the above-mentioned assumptions are hindering the wide adoption of SFC techniques in more diverse scenarios. Therefore, in this chapter, we explore the more general case of Internet-wide SFCs, in which multiple stakeholders are involved in the SFC provisioning, and the NFs are not constrained within a single domain and are rather distributed in the network. Several SFC systems, that respect the proposed definition of Internet-wide SFC, have been proposed by the research community [35–37,77]. Such solutions enable to distribute the NFs in the network, without any particular constraint. Further, they do not require any change to the network control plane, as they use plain IP routing to steer the users’ traffic through the SFC. As follows, each NF is identified in the network by its IP address i.e., a SFC instance is identified by a set of IP addresses.
On the other hand, the mentioned internet-wide solutions share a similar as-pect, that in our opinion, limits their the wide deployment in the network. In fact, [35–37,77] assume that the client – which is the entity initializing the connection establishment – is aware of the NFs’ IP address prior the connection establishment.
Likewise, they consider the NFs’ IP address discovery as an orthogonal problem to the SFC provisioning. Currently, and to the best of our knowledge, there is no prior work available on how to approach the SFC resolution problem, and which are the challenges involved when dealing with real-world deployments of a SFC Resolution process.
In this chapter, we first envision, in the current Internet landscape, the Domain Name System (DNS) system to be a candidate for the SFC Resolution process. In fact, for each client’s request, it selects a serving node, among a pool of service instances, based on multiple properties e.g., network location, availability, etc. Fur-ther, it returns to the client the IP address of the selected instance, which is then used by the client to initiate the end-to-end connection – as required by [35–37,77].
61 4.1 Introduction
Nonetheless, the current DNS resolution process is optimized for standard end-to-end connections. In fact, it assumes that the domain name to resolve represents the communication’s end-host e.g., content server. Whereas when dealing with SFCs, the resolution of the server’s domain name represents only one case. Thus, it includes the resolution of the domain names associated with the NFs composing the SFC.
And in such cases, the serving instance has to be selected based on the client’s location – as with the standard DNS – as well as on the next hop within the SFC.
However, no prior work is available how to approach the SFC Resolution process in the current Internet architecture, likewise, the efficiency of the current DNS system when dealing with SFCs.
4.1.1 Contributions
In Section4.2we introduce DNS background information, important for a thorough comprehension of the design choice implemented in the following sections. In Sec-tion4.3 we formulate theSFC Resolution in detail, highlighting the properties and the challenges that a SFC Resolution process show in practice. In Section4.4, we present the possible SFC Resolution strategies and their inefficiencies, when imple-mented with the current DNS architecture. So, in Section 4.5 we present a Col-laborative SFC Resolution process. Two DNS extensions are proposed enabling to share minimal information among multiple and independent providers. They enable to enhance the instance selection for each NF provider, allowing close-to-optimum results as proved in Section4.6. We present related work in Section4.7and conclude the chapter in Section4.8.
Chapter 4 Internet-wide Service Function Chains 62