Service Function Chaining Technology for Future Networks

Hiroyuki Kitada, Hisashi Kojima, Naoki Takaya,
and Masao Aihara

Abstract

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

1. Introduction

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.

Fig. 1. Routing required when network functions are virtualized on the cloud.

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.

*	The British spelling used by the European Telecommunications Standards Institute (ETSI)

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.

Fig. 2. Use case for CSP.

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.

Fig. 3. Service function chaining system.

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.

Fig. 4. Prototype implementation example.

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.

5. Issues

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.

	Hiroyuki Kitada Researcher, Network Architecture Project, NTT Network Technology Laboratories. He received the B.E. and M.S. in engineering from Shibaura Institute of Technology, Saitama, in 2008 and 2010, respectively. He joined NTT Service Integration Laboratories in 2010 and studied energy efficient network architecture. He is currently studying network virtualization technology such as SDN and NFV at NTT Network Technology Laboratories. He is a member of the Institute of Electronics, Information and Communication Engineers (IEICE) of Japan.
	Hisashi Kojima Senior Research Engineer, Network Technology Project, NTT Network Technology Laboratories. He received the B.E. and M.E. in information and communication engineering from Waseda University, Tokyo, in 1997 and 1999, respectively. In 1999, he joined NTT Network Service Systems Laboratories and studied IP/Optical network architecture including MPLS (Multi-Protocol Label Switching) and GMPLS (Generalized Multi-Protocol Label Switching) technologies. During 2006–2008, he was engaged in developing IP network architecture of NGN (Next Generation Network), especially in IP routing design. After that, he studied fixed and mobile convergence (FMC) network architecture at NTT Service Integration Laboratories (now NTT Network Technology Laboratories). His current interests include network virtualization technologies such as SDN and NFV, and network security. He is a member of IEICE of Japan. He received the Young Engineer Award from IEICE in 2005.
	Naoki Takaya Senior Research Engineer, Supervisor, Network Architecture Project, NTT Network Technology Laboratories. He joined NTT Network Service Systems Laboratories in 1995 and studied xDSL, high-speed ATM switching systems, and call agent systems for VoIP service. During 2003–2010, he studied ubiquitous network services, IP Multimedia Subsystem, and service delivery platform application architecture on FMC network environments at NTT Service Integration Laboratories. Since 2012, he has been studying network virtualization technologies such as NFV and SDN at NTT Network Technology Laboratories. He is a member of IEICE of Japan. He received the IEEE IMSAA award in 2010.
	Masao Aihara Senior Research Engineer, Supervisor, Network Technology Project, NTT Network Technology Laboratories. He received the B.E. and M.E. in electronic communication engineering from Waseda University, Tokyo, in 1989 and 1991, respectively. In 1991, he joined NTT Network Service Systems Laboratories and studied ATM switching software technologies and carrier-grade IP network architecture. During 2000–2011, he was engaged in developing the FLET’S HIKARI service at the R&D Center of NTT EAST. Since then, he has been studying the architecture of future networks at NTT Network Technology Laboratories. He is a member of IEICE of Japan.

↑ TOP