1、 ETSI GS NFV-IFA 002 V2.1.1 (2016-03) Network Functions Virtualisation (NFV); Acceleration Technologies; VNF Interfaces Specification Disclaimer The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry Specification Group (ISG) and represents th
2、e views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. GROUP SPECIFICATION ETSI ETSI GS NFV-IFA 002 V2.1.1 (2016-03) 2 Reference DGS/NFV-IFA002 Keywords acceleration, interoperability, NFV, NFVI, performance, portability ETSI
3、 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/
4、www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived dif
5、ference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or c
6、hange of status. Information on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSuppor
7、tStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorizat
8、ion of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are
9、Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS NFV-IFA 002 V2.1.1 (2016-03) 3 Contents Intellectual Property Rights 5g3Foreword . 5g3Modal verbs term
10、inology 5g31 Scope 6g32 References 6g32.1 Normative references . 6g32.2 Informative references 6g33 Definitions and abbreviations . 7g33.1 Definitions 7g33.2 Abbreviations . 8g34 Overview 9g34.1 Problem Statement . 9g34.1.1 VNF Acceleration goals 9g34.1.2 Network related acceleration 11g34.1.3 Stora
11、ge related acceleration 11g34.1.4 Algorithmic acceleration . 11g34.2 Software architecture 12g34.2.1 Overview 12g34.2.2 Acceleration model . 12g34.2.2.1 General 12g34.2.2.2 VNF aspects 13g34.2.2.3 Virtualisation Layer aspects 14g34.2.2.4 Intra-VNF acceleration 15g35 Abstract Interface functional req
12、uirements 17g35.1 Overview 17g35.2 Common Acceleration Virtualisation interface requirements 18g35.3 EPD Driver requirements . 18g35.4 Cryptography functional group 19g35.4.1 Overall requirements. 19g35.4.2 Operations requirements . 19g35.4.3 Crypto interface requirements. 20g35.4.4 Crypto driver re
13、quirements . 20g35.4.5 Management and monitoring requirements 20g35.5 IPSec offloading functional group 20g35.5.1 Overview 20g35.5.2 IPSec offloading interface requirements . 21g35.5.3 Operations requirements . 21g35.5.4 Management and monitoring requirements 21g35.6 TCP offloading functional group
14、21g35.6.1 TCP offloading interface requirements . 21g35.6.2 TCP offloading type requirements 22g35.7 Storage functional group 22g35.7.1 NVMe Over Fabric . 22g35.7.1.1 Overview . 22g35.7.1.2 Interface requirements . 22g35.8 Re-programmable computing functional group 22g35.8.1 Re-programmabe interface
15、 requirements 22g35.8.2 Operations requirements . 22g35.8.3 Management and monitoring requirements 23g35.9 Dynamic Optimization of Packet Flow Routing Functional Group . 23g35.9.1 DOPFR interface requirements . 23g35.9.2 Management and monitoring requirements 23g35.10 NAT offloading functional group
16、 . 23g35.10.1 Overview 23g3ETSI ETSI GS NFV-IFA 002 V2.1.1 (2016-03) 4 5.10.2 Overall requirements. 23g35.10.3 NAT offloading interface requirements 24g35.10.4 NAT offloading Operations requirements 24g35.10.5 Management and monitoring requirements 24g35.11 VXLAN offloading functional group . 24g35.
17、11.1 Overview 24g35.11.2 Overall requirements. 24g35.11.3 VXLAN offloading interface requirements 24g35.11.4 VXLAN offloading operations requirements 25g35.11.5 Management and monitoring requirements 25g35.12 Media functional group 25g35.12.1 Overview 25g35.12.2 Media overall requirements 25g35.12.3
18、 Media operations requirements . 25g35.12.4 Media interface requirements . 26g35.12.5 Management and monitoring requirements 26g3Annex A (informative): Authors Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Late
19、st updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI W
20、eb server) which are, or may be, or may become, essential to the present document. Foreword This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions Virtualisation (NFV). Modal verbs terminology In the present document “shall“, “shall not“, “should
21、“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI
22、 ETSI GS NFV-IFA 002 V2.1.1 (2016-03) 6 1 Scope The present document specifies requirements for a set of abstract interfaces enabling a VNF to leverage acceleration services from the infrastructure, regardless of their implementation. The present document also provides an acceleration architectural
23、model to support its deployment model. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest ve
24、rsion of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at https:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication
25、, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. 1 ETSI GS NFV 003: “Network Functions Virtualisation (NFV); Terminology for main concepts in NFV“. 2.2 Informative references References are either specific
26、 (identified by date of publication and/or edition number or version number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in
27、 this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 ETSI GS NFV-INF 003: “Network Fu
28、nctions Virtualisation (NFV); Infrastructure; Compute Domain“. i.2 ETSI GS NFV-SWA 001: “Network Functions Virtualisation (NFV); Virtual Network Functions Architecture“. i.3 ETSI GS NFV-IFA 003: “Network Functions Virtualisation (NFV); Acceleration Technologies; vSwitch Benchmarking and Acceleration
29、 Specification“. i.4 ETSI GS NFV-IFA 004: “Network Functions Virtualisation (NFV); Acceleration Technologies; Management aspects Specification“. i.5 NVM Express Inc: NVM Express 1.0e, NVM Express 1.1, NVM Express 1.2. NOTE: Available at http:/www.nvmexpress.org/specifications/. i.6 ETSI GS NFV-INF 0
30、05: “Network Functions Virtualisation (NFV);Infrastructure; Network Domain“. i.7 ETSI GS NFV-IFA 001: “Network Functions Virtualisation (NFV); Acceleration Technologies; Report on Acceleration Technologies a real-time OS is valued more for how quickly or how predictably it can respond than for the a
31、mount of work it can perform in a given period of time. software framework: abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software NOTE 1: A software framework is a universal, reusable sof
32、tware environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (A
33、PIs) that bring together all the different components to enable development of a project or solution. NOTE 2: Frameworks contain key distinguishing features that separate them from normal libraries: square4 Inversion of control: In a framework, unlike in libraries or normal user applications, the ov
34、erall programs flow of control is not dictated by the caller, but by the framework. square4 Default behaviour: A framework has a default behaviour. This default behaviour is some useful behaviour and not a series of no-ops. square4 Extensibility: A framework can be extended by the user usually by se
35、lective overriding or specialized by user code to provide specific functionality. square4 Non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting user-implemented extensions. In other words, users can extend the framework, but should not modify
36、its code. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 1 and the following apply. API Application Programming Interface Encrypt/Decrypt Encryption and Decryption Encap/Decap Encapsulation and DecapsulationEPD Extensible Para-virtualised Devic
37、e IRQ Interrupt ReQuest NAT Network Address Translation NUMA Non Uniform Memory Access NIC Network Interface Card RAM Random Access Memory SA Security Association SPD Security Policy Database UML Unified Modelling Language ETSI ETSI GS NFV-IFA 002 V2.1.1 (2016-03) 9 VA Virtual Accelerator VNI VXLAN
38、Network Identifier VTEP VXLAN Tunnel End Point VXLAN Virtual eXtensible Local Area Network 4 Overview 4.1 Problem Statement 4.1.1 VNF Acceleration goals The goals of the present document are: to identify common design patterns that enable an executable VNFC to leverage, at runtime, accelerators to m
39、eet their performance objectives; to describe how a VNF Provider might leverage those accelerators in an implementation independent way; and to define methods in which all aspects of the VNF (VNFC, VNFD, etc.) could be made independent from accelerator implementations. VNF providers have to mitigate
40、 two goals: VNFs might have constraints to perform their function within certain power consumption boundaries, CPU core count, PCI express slot usage and with good price/performance ratio; and VNFs should accommodate most if not all deployment possibilities. Use of accelerators can help meet the con
41、straints but can have an influence on deployment flexibility. VNF acceleration implementations will range from inflexible software that is tightly-coupled to specific software and hardware in the VNF and NFVI (see pass-through model as shown in figure 4.1.1-1), to highly flexible loosely-coupled sof
42、tware that uses common abstractions and interfaces (see abstracted model as shown in figure 4.1.1-2). Further it is understood that virtualisation and acceleration technologies will evolve. Pass-through deployments are expected to exist, and the present document does not intend to preclude any speci
43、fic acceleration architectures from NFV deployments. However, the focus of the present document is to define and promote abstracted models. It is desirable that the use of accelerators be implementation independent. There is a slight difference between “implementation independent executable VNFC“ an
44、d “implementation independent VNF“: An implementation independent executable VNFC is a software that can leverage a known set of accelerator implementations both in hardware and in software. The part of the VNFD that applies to this VNFC contains information elements that allow the NFV management an
45、d orchestration to find a compute node with the requested characteristics or hardware. Should a new hardware become available on the market, a VNF Provider willing to make use of it to accelerate a VNFC has to update its the VNFC image and the VNFD, the operator has to on-board the new VNF package a
46、nd redeploy it to make use of the new hardware. This was defined as the pass-through model in ETSI GS NFV-INF 003 i.1, clause 7.2.2. ETSI ETSI GS NFV-IFA 002 V2.1.1 (2016-03) 10 Figure 4.1.1-1: Pass-through model An implementation independent VNF is a VNF that makes no assumption whatsoever on the u
47、nderlying NFVI. Its VNFD does not contain any accelerator specific information elements. Should a new hardware become available on the market, the operator will update its NFVI to allow the VNF to make use of the new hardware. An implementation independent VNF is thus based on implementation indepen
48、dent VNF software that makes use of a functional abstraction of an accelerator supported by an adaptation layer in the NFVI. This model is close to the abstracted model defined in ETSI GS NFV-INF 003 i.1, clause 7.2.2. Figure 4.1.1-2: Abstracted model NOTE 1: An implementation independent executable
49、 VNFC allows for VNF deployment in both hypervisor based and non-hypervisor based environments. The latter configuration is outside the scope of the present document. Live migration of such hardware independent accelerated VNF may be possible if any associated acceleration state information required can also be migrated. NOTE 2: Live migration from a compute node with accelerator to a compute node without accelerator or with a different accelerator is allowed (in particular to cope with emergency response situations). ETSI ETSI GS NFV-I
