Nippon Telegraph and Telephone Corp. (NTT) (Head Office, Chiyoda-ku, Tokyo; Hiroo Unoura, President and CEO), ALAXALA Networks Corp. (ALAXALA) (Head Office, Kawasaki-shi, Kanagawa; Ikuho Minamikawa, President and CEO), Hitachi, Ltd. (Hitachi) (Head Office, Chiyoda-ku, Tokyo; Toshiaki Higashihara, Representative Executive Officer and President and COO), Cisco Systems G.K. (Cisco) (Head Office, Minato-ku, Tokyo; Irving Tan, President), NEC Corp. (NEC) (Head Office, Minato-ku, Tokyo; Nobuhiro Endo, President), and Alcatel-Lucent Japan Ltd. (Alcatel-Lucent Japan) (Head Office, Shinagawa-ku, Tokyo; Nicolas Bouverot, President and CEO) have succeeded in the interoperability test of service function chaining, which is a packet forwarding method for service chaining; a technology to transfer packets to the appropriate service function in appropriate order. Service function chaining is currently being standardized in IETF*1 as a method for using a tag that identifies the network service.
A demonstration of interoperability is scheduled for "NTT R&D Forum 2015", which will be held at NTT Musashino R&D Center on February 19-20, 2015. In addition, this demonstration has been applied to NFV ISG*2, a part of the European standards organization ETSI*3, to be approved as a Proof of Concept.
1. Background and Purpose of Experiment
Network functions virtualisation (NFV) has received much attention in recent years and is being studied internationally. In NFV, functions related to network services (service functions) are implemented as software on a general purpose server.
To provide a flexible combination of virtualized service functions to the user, service chaining technology to forward packets to the appropriate service functions in the appropriate order is required. This technology has been actively discussed in IETF and other standards organizations.
NTT is comparing and analyzing multiple packet forwarding methods for achieving service chaining and has posted a draft of the analysis results to IETF SFC WG*4 in cooperation with Cisco and others.
Regarding service function chaining (SFC), which is a packet forwarding method for service chaining and currently being standardized in IETF, NTT and five vendors have prepared four components (Classifier, SFF, SFC Proxy and Controller), which are defined in SFC, and demonstrated the interoperability of SFC and verified the possibility of service chaining with SFC.
2. Features of SFC (Fig.)
In service chaining technology, a service chain is defined for a flow that is divided for each user and service. The service chain is formed by tying the service functions to be provided to the flow. The packets in the flow are transferred to the appropriate service functions along the service chain. SFC is a packet forwarding method in which a new tag identifying the types of service functions and the order of service functions applied to the flow is attached to the packets, and the packets are transferred based on the tag. The four components defined in SFC are as follows.
A Classifier is placed at the starting point of the service chain and determines the service to be applied to the flow. "Service" refers to the type of service functions and the order in which the flow passes through them. Then, the Classifier attaches a tag identifying the service to the packet. In this demonstration, the network service header (NSH) is used as the tag (SFC header). The NSH is being standardized in IETF.
• Service Function Forwarder (SFF)
A service function forwarder (SFF) placed in the network refers to the tag and determines the service function as a destination.
• SFC Proxy
An SFC proxy is placed between the SFF and SFC-unaware service function. Since the existing legacy service function is not compatible with SFC encapsulation, the SFC proxy is necessary for removing the SFC header just before the packet reaches the service function and is necessary for reattaching the SFC header just after the packet is output from the service function.
The controller manages the Classifier and SFF and updates these tables.
In SFC, it is possible to add and change the service functions to be provided to the flow by simply changing the tag. Chain branching according to the processing results of the service function can also be achieved. Furthermore, the number of entries in the routing table in the SFF requires only the number of combinations of types and order of service functions regardless of the number of flows to be controlled.
3. Participating Companies' Roles and Experimental Results
In this experiment, NTT and five vendors prepared four components (Classifier, SFF, SFC Proxy and Controller), which are defined in SFC, and verified the interoperability of SFC. Each company's role was as follows.
NTT: Providing SFF, SFC Proxy, and Controller
ALAXALA: Providing Classifier, SFF, and SFC Proxy
Hitachi: Providing Classifier, SFF, and SFC Proxy
Cisco: Providing Classifier, SFF, and SFC Proxy
NEC: Providing Classifier, SFF, and SFC Proxy
Alcatel-Lucent Japan: Providing Classifier
We also verified the change in the chain route by tag replacement and chain branching according to the processing results of the service function.
We will continue to contribute to the global spread and international standardization in cooperation with telecom carriers and vendors for the early use of service chaining technology. By service chaining using the optimal packet forwarding method, we aim to provide flexible network service in the future.
*1 IETF (Internet Engineering Task Force)
A standards organization that handles the standardization of technologies used in Internet communication.
*2 NFV ISG (Network Functions Virtualisation Industry Specification Group)
An organization established within ETSI by carriers in December 2012 to promote the study of network virtualization technologies for carriers.
*3 ETSI (European Telecommunications Standards Institute)
A standards organization that handles the standardization of telecommunication technologies in Europe.
*4 SFC WG (Service Function Chaining Working Group)
A group to study service chaining established at the IETF #88 meeting (November 2013). The first meeting was held at the IETF #89 meeting (March 2014).
The company names and other proper names in this document are trademarks or registered trademarks of the respective companies.