Feature Articles: Technological Development for Network Virtualization
Service Function Chaining Technology for Future Networks
Service function chaining enables various network functions to be used rapidly and flexibly. This article describes methods of implementing service function chaining technology and also presents use cases.
Keywords: SDN, NFV, service function chaining
As the development of network functions virtualisation* (NFV) technology continues in the future, network functions will become concentrated in datacenters and will be operated as a cloud service. This will make it easier to implement new network functions and will enable network function resources to be allocated flexibly on request and according to demand. We expect that NFV will lead to more advanced carrier networks. For example, network functions have conventionally been deployed in the network using dedicated equipment. This means that when services are added or software is updated, modifications must be made to every piece of equipment (Fig. 1(a)). In contrast, network functions are centralized in the cloud when NFV is used to virtualize network functions (Fig. 1(b)). This makes it possible to change or add network functions simply by updating the software on commercial-off-the-shelf (COTS) servers.
However, concentrating network functionality in the cloud means that user packets must be sent through the COTS servers in the cloud, where the network functions are located. Also, if individual users contract different services, each user uses different network functions, and consequently, routing per user or flow is required. The technology to control packet routing through the applicable network functions is called service function chaining technology.
2. Service function chaining use case
We consider the example of a content service provider (CSP) that provides a service to end users through a carrier network as a use case for service function chaining technology (Fig. 2). In the current network, the CSP must purchase, install, and configure customer-premises equipment (CPE) to connect to the carrier network as well as to other equipment such as a firewall to ensure security. However, with service function chaining technology, functions such as the CPE and firewall can be implemented in software and set on a carrier cloud, and the carrier can offer them as network services. As a result, the CSP can contract network services easily and immediately, simply by clicking a button on the service contract website. Thus, even if the CSP is under attack, it could immediately contract for security services and defend itself against the attack.
3. Service function chaining system
Some challenges arise in implementing service function chaining with existing Internet protocol (IP) network technology. Generally, when carrier and other large-scale networks use IP routing, routing is implemented based on aggregated network addresses to increase scalability. However, if user-based routing as in the previously described use case is implemented with IP routing, the network equipment must learn routing tables that contain a huge number of IP routes. This is impractical in terms of scalability. Therefore, a new routing method was necessary that was independent of the existing IP routing.
NTT Network Technology Laboratories has proposed a packet-labeling method to implement service function chaining technology. In this method, switches in the carrier network attach labels to each packet to identify network functions that the packets must pass through (Fig. 3). If a packet passes through multiple network functions, multiple labels are attached, and the order they must pass through the functions is indicated. Within the carrier network, routing is implemented according to the labels attached to a packet. A feature of this method is that information about service function chaining is attached to the packets themselves. Even as the user contract status dynamically changes, the control is only needed for the switches, so the method is highly scalable.
4. Prototype demonstration
To demonstrate service function chaining, we built a prototype using actual equipment based on the method described in the previous section (Fig. 4). The service function chaining prototype consists of switches, COTS servers handling the network functions, and a network controller. A service contract site was also prepared, enabling users to easily add or cancel services.
When a user subscribes to a service on the site, the information is passed to the network controller, and a flow entry on the switch is configured using the southbound API (application programming interface). The network controller consists of an application and a switch controller. The application computes the labels to be attached to packets using information about subscribers and network functions in the cloud. The switch controller receives the information on the labels from the application and generates flow entries to control the switches. In our prototype implementation, the controller and application were implemented on a platform called the Ryu SDN Framework, which was developed by the NTT Software Innovation Center.
Also, to apply the service function chaining on existing IP networks by adding minimal functionality, we used an overlay connection method in the prototype. IP tunneling is used to connect switches in the carrier network and virtual switches on the COTS servers. Packets with labels are transmitted through IP tunnels, so label processing is hidden from the core network, which minimizes the amount of equipment necessary for processing labels.
This environment enabled us to demonstrate that services can be provided to users more rapidly and with greater flexibility through use of service function chaining technology.
Various issues must be addressed in order to apply service function chaining on a real carrier network. We describe some of the issues that were identified in building the prototype described above.
5.1 Ensuring interoperability
There are currently no standard methods or protocol technologies for implementing service function chaining, so we developed original methods and used them to implement the prototype. This meant that existing network functions such as virtual appliances could not process the labels. Therefore, the virtual switches running on our COTS servers first removed the labels before packets were sent to the network function and then re-attached them after they returned from the network function. This implementation enabled us to use existing virtual appliances as-is, although we sacrificed some transmission performance due to the processes of attaching and removing labels. Fully introducing service function chaining on a carrier network would require securing the interoperability by standardizing the service function chaining technology, and making sure that virtual appliances from various companies support the protocols.
5.2 Ensuring scalability
An environment that fully incorporates NFV on a carrier network, where many network functions are running on COTS servers, would require many of these servers in order to process large amounts of traffic. Specifically, we assume that many servers would be operating for a virtual machine implementing a single network function. To implement service function chaining under such conditions, the labels would need to indicate not only the type of network function but also the virtual machine running the network function. Thus, in addition to multiple users, multiple virtual machines would need to be identified on the carrier network. As such, a method of implementing this processing without losing scalability is needed.
5.3 Improving the control plane system
An important factor with large-scale networks such as carrier networks is how information such as subscriber information and service function chaining labels will be managed in order to control the network and provide fine-grained services. In the method described above, subscriber and label information is managed centrally by the network controller and attached to packets in the form of labels, so servers in the cloud do not maintain any individual subscriber information. In this way, when a subscriber changes contract conditions, network function changes can be propagated quickly by simply changing the labels attached when packets enter the network, and without controlling the cloud at all.
However, the network controller has all of the information, so network controller performance and reliability are very important. It would not be feasible for a single network controller to manage and control a large-scale carrier network. Therefore, redundancy in the network controller—through scaling out or using distributed processing—must be considered. In these ways, the control-plane architecture will also need to be improved to satisfy the requirements of a carrier network.
6. Future prospects
Service function chaining is an important technology for future networks that can provide new services rapidly and with flexibility. However, it is currently still a concept-level technology, and various issues such as protocol standardization need to be resolved before it will be practical. Standardization of methods and protocols for implementing service function chaining are currently in progress by the Service Function Chaining Working Group of the Internet Engineering Task Force. At the NTT Network Technology Laboratories, we are working toward achieving a scalable technology that can be applied to a carrier network based on the knowledge gained from the methods introduced here and the prototype we have built. We are also working on related standardization activities.