NFV Service Chaining Challenges

Djamal Zeghlache, UMR 5157 CNRS Samovar, Télécom SudParis, Université Paris Saclay, France

 

Abstract- This letter presents a framework to automate the production of network services to address some of the challenges in the dynamic deployment of cloud and network services. A service management approach, using available open source components, a TOSCA extension for network services and a customized service function chaining module, is suggested for network service chaining.

Introduction

One of the challenges in software networks management is the design of an underlying framework to support and accelerate the production of applications and services by relying on Software Defined Networks (SDN), Network Function Virtualisation (NFV) and Cloud principles. Their success depends on the notion of abstraction and the availability of reliable service manager architectures fulfilling the agility, acceleration and automation requirements of next generation services.

The notion of abstraction is essential for agile services creation so that programmers consume an underlying service without knowing much about it other than its inputs, outputs and functionality. With abstraction, there are two types of creations. The first is the creation of the services themselves by assembling lower level services. The second is the generation of these lower level services, seen as abstractions (concepts or building blocks) by the higher level service. Agile services are created by first identifying and building the lower-level services upward from the resources. Once a catalog of these underlying services is defined and made available, high level service creation can use and assemble them into ‘‘services’’. A service is agile if the need to propagate changes in the low level services into the service definition is ideally eliminated or at least minimized. This means that requested service templates or workflows remain unaffected and unmodified by underlying changes. In the context of SDN, NFV and Cloud, this means that changes in real devices or virtual infrastructures (containers, networks and networking functions) have to be hidden from the service definition and workflows. Consequently, the provisioning of different abstractions and their deployment on different virtual platforms can vary (or can be altered) without changing the service and the way it is assembled or produced.

Figure 1. VNF-FG mapping on providers' infrastructures

A challenge, in NFV, that deserves special attention is the chaining of network services. Tenants can acquire, from providers, chained virtualized network functions and the means to steer and control their application and end users traffic flows. Figure 1 depicts a service function chain (SFC) or virtualized network function forwarding graph (VNF-FG) request with several VNFs and four application flows to steer into their respective forwarding paths 1 to 4. This is a good technical use case to derive appropriate agile services management architectures as it entails the description of network services (VNFs), their smart placement and the steering of their application flows through specified forwarding paths. VNF-FG establishment requires setting up of the containers or hosts of the VNFs themselves, their connectivity and the injection of rules to steer application flows into the desired forwarding paths. Designing a service management framework for VNF-FG can therefore fulfill most of the NFV needs and meet the requirements of network services chaining.

Service management in SDN and NFV

Service management in SDN and NFV is currently focused on the concept of orchestration to support service lifecycle management. The NFV Orchestrator in ETSI-NFV [1] is responsible for:

• Network Service (NS) lifecycle management (including instantiation, scale-out/in, performance measurements, event correlation, termination)
• Global resource management, validation and authorization of NFV Infrastructure (NFVI) resource requests
• Policy management for NS instances

NetCracker’s Service Orchestrator [2] enables end-to-end service provisioning for hybrid networks made of both virtualized SDN/NFV-based components and traditional network technologies. Other service life cycle management frameworks, such as ITILv3 [3] (Information Technology Infrastructure Library), that describe the life of an IT service (from planning and design to delivery and continuous improvement) are also used for IT lifecycle management. TOSCA (Topology and Orchestration Specification for Cloud Applications), from OASIS [4] [5] (Organization for the Advancement of Structured Information Standards), aims at enhancing the portability of cloud applications and services. TOSCA enables interoperable description of application and infrastructure cloud services independent of the suppliers creating the service, the cloud providers or the hosting technologies.

Despite these specifications, the merging of cloud, SDN and NFV in a cohesive system still requires further research and development. TOSCA addresses well cloud services and resources and their use to compose complex cloud services but network services are not part of its specification. There are no descriptors for networking services in TOSCA and no means to include virtualized network functions, their connectivity and chaining. There is a need to bridge and combine these domains by extending the service request descriptions to encompass cloud, network and control services.

Abstractions

One approach to provide abstractions for cloud and network services joint management is to extend the TOSCA data model with network services descriptors so it can also cover networking technologies. Current service descriptions and service templates that are likely to fulfill the agile service goal and can cover cloud, SDN and NFV are YAML [6], JSON and XML. YAML is the most expressive and more natural language for describing high level complex services when compared to XML and JSON.

In the current state of the art, the most appropriate and most expressive and extensible cloud service specification, to combine with YAML, seems to be TOSCA that uses a service specification framework (with service templates, languages and grammar) for cloud services. TOSCA defines key service templates and components for service description and service life cycle management:

• Topology Template: defines the structure of a service and consists of a set of Node templates that model the components of the workload and relationship templates that model the relations between the components
• Node Types and Relationship Types: describe the possible kinds of components and their relationships. These types allow defining lifecycle operations to implement the behavior “an orchestration engine” can invoke when instantiating a service template (e.g. a node type can provide lifecycle operations: ‘create instance’, ‘start’, ‘stop’...)
• Plans: defined in a Service Template, describe the management aspects of service instances, especially their creation and termination. Plans in TOSCA use existing workflow languages such as BPMN 2.0 or the BPEL 2.0. TOSCA recommends BPMN 2.0 to model management plans as it offers a standardized graphical rendering and does not force the workflow graph to be acyclic [7]. Plans are modeled by application developers or experienced operators [8]. TOSCA defines three types of management plans: build, modification, and termination plans

Figure 2: Service Life Cycle Management for SFC or VNF-FG services

TOSCA template extension

Figure 3 “block A” represents the original TOSCA grammar used for abstract representation of cloud applications. The topology template can be seen as a directed graph with Node Templates as vertices and Relationship Templates as edges connecting them. The Group Templates form sub-graphs of the Topology Template graph. The node template is an abstraction of the application or the user requested resource. The TOSCA data model, limited to cloud applications, has to be extended to support the representation of VNFs and their stitching to form a VNF service chain. A proposed extension of the TOSCA grammar and data model is depicted in blocks B and C of Figure 3.

Figure 3: Extended Tosca data model for NFV paradigm

In the ETSI-NFV standard and terminology, there are two types of graphs composing the network service descriptor [1] and these must be included in the TOSCA model (blocks B and C of Figure 3):

• The first one is the network connectivity topology (NCT) that specifies the VNF nodes that compose the global service and the connection between them using the virtual link (VL) concept. Each VL is connected to a VNF through the connection point (CP) which represents the VNF interface.
• The second type is the VNF Forwarding Graph (VNF-FG) established on top of the Network Connectivity Topology. The VNF-FG is composed of network forwarding paths (NFP) that are ordered lists of Connection Points forming a VNF chain.

The proposed TOSCA extension (block B of Figure 3) and the associated parser (see Figure 2) use the notion of node template by inheriting new nodes to represent the VNF, CP, VL and NFP components. The VNF node is characterized by the associated VM and the network function appliance that will be hosted on the VM. The network function appliance is represented as an artifact element in the TOSCA grammar. The VL represents the virtual link that interconnects the VNFs. To establish this connection, we use the new inherited relationship nodes to bind the CP to the VNF (the “virtualBindTo” relationship) and to link the CP to the VL (using the “VirtualLinkTo” relationship). The forwarding path (FP), inherited from the node template, is modeled as an ordered list of CPs forming a sequence of VNFs that will be traversed by packets or traffic flows. The FP is connected to CPs by the “ForwardsTo” relationship. Each VNF forwarding graph includes a list of FPs that are interdependent and have common characteristics (e.g. several FPs have the same source and destination IP addresses). For this reason, the VNF-FG is modeled as a Group and thus inherits from the Groups Template of the original TOSCA model. The proposed extension is used by the service life cycle management depicted in Figure 2 to ensure orchestration of both cloud and network services and the provisioning, instantiation and management of SFCs or VNF-FGs.

A SLC manager

Existing cloud resource orchestration frameworks like Cloudify and OpenStack Heat are mature enough for traditional cloud services (compute, memory, storage) but are unable to provide service function chaining [9][10] (SFC) across networked cloud infrastructures to multiple tenants in a B2B2C context. The architecture in Figure 2 takes advantage of existing Cloud orchestration and SDN management tools and introduces the 'missing pieces' and a service lifecycle (SLC) manager to support complex applications and enable service function chaining over cloud, SDN and NFV environments. The SLC manager invokes the cloud orchestrator to set up virtual resources acting as containers for user applications and virtualized network functions.

The SLC manager interacts also with the SDN controller to set up the required virtual network functions and the forwarding graphs. The key modules of the SLC manager are the:

• Tosca Parser: is an extended version of the basic Tosca parser so it can deal with both cloud and network resources.
• Decomposition Module: divides the resources into resources/services to be deployed by the Cloud Orchestrator and networking resources/chaining paths to be deployed by the SDN manager.
• Cloud Orchestration Translator: transforms requested Cloud resources to the template language of the Cloud Orchestrator (Cloudify or Heat).
• Cloud Resources Instantiation: communicates with the Cloud Orchestrator to instantiate the resources.
• SFC Manager: deals with networking and chaining demands by invoking the SDN controller to instantiate the resources.

The SLC Manager translates the NCT graph to the language used by the Cloud orchestrator (Cloudify blueprint, Heat Orchestration Template…). The SLC manager sends the created template to the cloud orchestrator to instantiate cloud resources. The VNF-FG, that defines the requested chains and their forwarding paths, is only deployed once the VMs are successfully instantiated by the cloud orchestrator and provided with addresses. The SFC manager deploys the VNF-FG by invoking the SDN controller that achieves the stitching of the VNFs (connecting the SFs more precisely). The proposed SFC manager depicted in Figure 2 interacts with the SFC module (an extension of ODL SFC module) to deploy the SFCs. The SFC manager deploys the SFs (VNFs); the SFFs (CPs); the SFCs (VNF-FGs) and the SFPs (FPs). These configurations are then sent by ODL to the VMs through the SFC agent.

Conclusions

This letter presents a possible agile service management approach for cloud and networks services production using readily available open source platforms and software, a TOSCA extension for network services and a customized ODL SFC Manager module. The presented orchestration principles and framework are sufficiently generic to build future agile SFC life cycle management architectures.

Acknowledgment

The approach and architecture presented in this letter is the result of joint work with Imen Grida Ben Yahia from Orange Labs and Marouen Mechtri who master minded the concepts and implemented the framework. The original study received partial funding from Orange labs and the French FUI.

References

[1] ETSI GS NFV-MAN 001 http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf

[2] NetCracker Service Orchestrator, http://www.netcracker.com/

[3] OGC-V3-Intro: “The Official Introduction to ITIL Service Lifecycle” (TSO, 2007, Fifth edn. 2007)

[4] http://www.cloud-council.org/CSCC-Webinar-OASIS-TOSCA-Enabling-Application-Portability-in-the-Cloud-10-22-14.pdf

[5] http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.pdf

[6] http://yaml.org/spec/current

[7] Kopp, O., Martin, D., Wutke, D., Leymann, F.: The Difference Between Graph-Based and Block-Structured Business Process Modelling Languages. Enterprise Modelling and Information Systems 4 (1) (2009) 3–13

[8] Kopp, O., Binz, T., Breitenbücher, U., & Leymann, F. (2012). BPMN4TOSCA: A domain-specific language to model management plans for composite applications. In J. Mendling, & M. Weidlich (Eds.), Business process model and notation (Vol. 125 of Lecture Notes in Business Information Processing, pp. 38—52).

[9] Heat ‘OpenStack Orchestration service’, https://wiki.openstack.org/wiki/Heat

[10] Cloudify project. http://getcloudify.org/

 

---

 

Professor Djamal Zeghlache graduated from SMU in Dallas, Texas in 1987 with a Ph.D. in Electrical Engineering and joined the same year Cleveland State University as an Assistant Professor. In 1992 he joined the Networks and Services Department at Telecom SudParis of Institut Telecom where he currently acts as Professor and Head of the Wireless Networks and Multimedia Services Department. His current interests and research activities concern network architectures, protocols and interfaces to ensure smooth evolution towards loosely coupled future networks and cloud architectures. He is currently addressing optimization, deployment, control and configuration challenges in cloud, SDN and NFV environments and systems.

 

Editor:

Professor Shashikant Patil is a prominent educationist and Teacher. He is a renowned Engineer, researcher and scientist. He has received numerous accolades for his valuable contributions and achievements in education and research. Prof. Patil graduated Electronics Engineering from North Maharashtra University in 1997 and joined as a Lecturer in Government Polytechnic Mumbai in 1999. After completing his Masters in from Dr Babasaheb Ambedkar Technological University Lonere, he joined NMIMS and later on appointed as an Associate Professor and Head of the Department. He is currently serving as an Associate Editor, Editorial Board Member, Technical Advisory Board Member, Potential Peer Reviewer and Journal Referee on at least 50 Journals. He is also having an association with Elsevier Editorial Series, Taylor and Francis, SpringerLink Journals as a potential Peer Reviewer and Journal Referee. He is also associated with IEEE, ACM, CSI, ISTE, NHRDN, E4C and IETE as Professional member and nominated as an affiliate member on various committees of IEEE SPS and ComSoc. He has participated in 36 Teacher Training Programs/ Refresher courses like STTPs/ CEPs/QIPs/Conferences / Workshops in IITs and reputed institutes. A stickler for quality, team builder to the core and a natural motivator with perseverance and integrity. Commands excellent communication skills that have been honed through interacting with people at various levels. He is recipient of Best Researcher Award 2014 of SVKMs NMIMS Shirpur. In addition to this he had been nominated as IEEE Day 2015 Section Ambassador for region 10. Recently has been selected as a Member Executive Committee on IEEE CSI India Council as well as Core Team Member of Social Media and Online Content Management Team, Visibility Committee of IEEE SPS Society at International Level. He has published around 31 articles in various conferences and journals at National and International level. This year he has been selected as Regional Lead Ambassador for region 10 for IEEE Day 2015 event. He is also heading SVKMs NMIMS Bosch Centre of Excellence in Automation Technologies Shirpur Campus. He is member IEEE RFID Technical Council and SIG Member of IOT. His research interests are Signal Processing and Imaging. He is also heading SVKMs NMIMS Bosch Centre of Excellence in Automation Technologies Shirpur Campus. He is member IEEE RFID Technical Council and SIG Member of IOT. His research interests are Signal Processing and Imaging. He is also serving as an Associate Editor on IEEE RFID Journal; IEEE SDN Journal; IEEE RFID Steering Committee.