ETSI GS NFV-INF 007-2014 Network Functions Virtualisation (NFV) Infrastructure Methodology to describe Interfaces and Abstractions (V1 1 1)《网络虚拟化技术 (NFV) 基础设施 接口描述方法和抽象 (V1 1 1)》.pdf

《ETSI GS NFV-INF 007-2014 Network Functions Virtualisation (NFV) Infrastructure Methodology to describe Interfaces and Abstractions (V1 1 1)《网络虚拟化技术 (NFV) 基础设施 接口描述方法和抽象 (V1 1 1)》.pdf》由会员分享，可在线阅读，更多相关《ETSI GS NFV-INF 007-2014 Network Functions Virtualisation (NFV) Infrastructure Methodology to describe Interfaces and Abstractions (V1 1 1)《网络虚拟化技术 (NFV) 基础设施 接口描述方法和抽象 (V1 1 1)》.pdf（30页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI GS NFV-INF 007 V1.1.1 (2014-10) Network Functions Virtualisation (NFV); Infrastructure; Methodology to describe Interfaces and Abstractions Disclaimer This document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry Specification Group (ISG) and represen

2、ts the 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-INF 007 V1.1.1 (2014-10) 2Reference DGS/NFV-INF007 Keywords interface, NFV ETSI 650 Route des Lucioles F-06921 Sophia Antipolis

3、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:/www.etsi.org The present document may be made ava

4、ilable 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 difference in contents between such versions and/or in print, the onl

5、y 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 change of status. Information on the current status of this and oth

6、er ETSI documents is available at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced or utilized in any form

7、 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 authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in a

8、ll media. European Telecommunications Standards Institute 2014. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTETMare Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organ

9、izational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS NFV-INF 007 V1.1.1 (2014-10) 3Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative

10、references 5g33 Definitions and abbreviations . 5g33.1 Definitions 5g33.2 Abbreviations . 6g34 Objectives . 6g34.1 Requirements 7g34.2 Standardizing Organizations 7g35 Architectural Principles w.r.t. Interfaces and Abstractions 7g35.1 System Composition using Functional Blocks . 8g35.1.1 Functional

11、Blocks as the Primary Specification Method 8g35.1.2 Interconnection of Functional Blocks . 9g35.1.3 Recursive Structure of Functional Blocks 9g35.1.4 General UML Diagram for Basic Functional Block Methodology . 10g35.2 Extension of Functional Block Methodology to Virtualisation 11g35.2.1 Virtualisat

12、ion: Virtual Interfaces and Container Interfaces 12g35.2.2 Virtual Functions and Host Functions 13g35.2.3 Recursive Virtualisation . 14g35.2.4 Configuration Lifespan, Operational Interfaces and Configuration Interfaces . 15g35.2.5 Mapping Between VFBs and HFBs 15g35.2.6 General UML Diagram for Exten

13、ded Functional Block Methodology 16g35.3 Describing and Specifying Interfaces and Abstractions . 18g35.3.1 Functional Blocks, Components, Abstractions and Interfaces 18g35.3.2 Specifying Organizations and Level of Detail 18g35.4 Types of Interfaces . 18g35.5 Interface Adaptation Mechanisms 19g35.6 N

14、aming and Versioning 22g35.7 Discovery of Initiators / Targets and Bootstrapping . 22g35.8 Security 22g35.9 Performance and Availability . 23g35.10 Error and Anomaly Handling . 23g35.11 Platform Independence and Portability 23g35.12 Level of Abstraction and Granularity of Interfaces 24g36 Illustrati

15、ve Examples 24g3Annex A (informative): Additional Potential Illustrative Examples . 27g3Annex B (informative): Authors Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web

16、server (http:/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 Web server) which are, or may be, or may bec

17、ome, 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“, “should not“, “may“, “may not“, “need“,

18、“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 ETSI GS NFV-INF 007 V1.

19、1.1 (2014-10) 51 Scope The present document describes how Network Functions Virtualisation (NFV) related interfaces and abstractions are to be derived and specified. It describes the concepts associated with these interfaces and abstractions. It covers the specification process / methodology in gene

20、ral. It presents a cross-cutting framework which covers compute, hypervisor and infrastructure network domains, also data, control and management planes. The present document does not specify all the interfaces and abstractions as these are covered by other documents, e.g. the NFV INF domain specifi

21、c documents. Examples of interfaces and abstractions are nevertheless supplied to illustrate the methodology. The present document does not provide any detailed specification but makes reference to specifications developed by other bodies and to potential specifications, which, in the opinion of the

22、 NFV ISG could be usefully developed by an appropriate standards development organization (SDO). Furthermore the NFV INF domain specific documents will not provide detailed specifications either. 2 References References are either specific (identified by date of publication and/or edition number or

23、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. Referenced documents which are not found to be publicly available in the expected location might be

24、 found at http:/docbox.etsi.org/Reference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. 2.1 Normative references The following referenced documents are necessary for the application of the present document.

25、Not applicable. 2.2 Informative references 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. Not applicable. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the prese

26、nt document, the following terms and definitions apply: unicode: unique, unified and universal encoding zeroconf: zero configuration networking ETSI ETSI GS NFV-INF 007 V1.1.1 (2014-10) 63.2 Abbreviations For the purposes of the present document, the following abbreviations apply: 3GPP 3rd Generatio

27、n Partnership Project ACL Access Control List API Application Programming Interface CLR Common Language Runtime CPU Central Processing Unit EJB Enterprise JavaBeansETSI European Telecommunications Standards Institute GS Group Specification HFB Host Functional Block IETF Internet Engineering Task For

28、ce ISG Industry Specification Group IT Information Technology ITU-T International Telecommunication Union Telecommunication Standardization Sector JIT Just In Time JSON JavaScript Object Notation MANO Management and Orchestration NFV Network Functions Virtualisation NIC Network Interface Card NPU Ne

29、twork Processing Unit OS Operating System OVS Open Virtual SwitchOVSDB Open Virtual Switch Database SATA Serial Advanced Technology Attachment SDN Software Defined Networking SDO Standards Development Organization SR-IOV Single Root I/O Virtualisation SSL Secure Sockets Layer TCP Transmission Contro

30、l Protocol UML Unified Modelling Language UTF Unicode Transformation Format VF Virtual Function VFB Virtualised Functional Block VM Virtual Machine VNF Virtual Network Function VNIC Virtual Network Interface Card VT Virtualisation Technology XML eXtensible Markup Language4 Objectives The three key f

31、eatures of the NFV approach are: 1) Separation of the software defining the network function from generic high volume hardware servers, storage devices and network switches. 2) Independent modularity of the software and hardware components. 3) Automated orchestration which will automate remote insta

32、llation and management of the virtual functions on the generic hardware. ETSI ETSI GS NFV-INF 007 V1.1.1 (2014-10) 74.1 Requirements The overall vision of Network Functions Virtualisation gives rise to the following overall requirements w.r.t. interfaces and abstractions: Each functional block or co

33、mponent shall be described as an abstraction, documenting the purpose and behaviour of the functional block or component, and as a set of interfaces to the abstraction. The interfaces and abstractions shall be documented at a sufficiently detailed level to permit standardizing organizations to creat

34、e specifications for these interfaces and abstractions. The NFV ISG is expected to liaise with standardizing organizations in order to ensure that such specifications are sufficiently detailed to enable interoperability between platforms and devices hosting Virtualised Network Functions that are off

35、ered by different vendors. The NFV ISG is expected to liaise with standardizing organizations in order to ensure that such specifications are decoupled from vendor-specific design and implementation choices within platforms and devices hosting Virtualised Network Functions. 4.2 Standardizing Organiz

36、ations The standardizing organizations that are responsible for creating detailed specifications of each interface and abstraction are listed in the overview document and in domain specific documents. Other organizations that define methodologies relevant to interfaces and abstractions include the O

37、bject Management Group (specifically for UML) and the International Council on Systems Engineering (specifically for Systems Engineering). 5 Architectural Principles w.r.t. Interfaces and Abstractions Many network systems, including those specified by 3GPP, IETF, and ITU-T, are specified using the p

38、rinciples of systems engineering. Each component of the overall system is specified as a functional block and the interactions between the functional blocks are specified as interfaces. This clause details the basic functional block based system composition methodology and extends it to cover the pr

39、ocess of virtualisation. The representation of functional blocks is part of the working methods of many industries as well as different disciplines and perspectives within those industries. As a result, there is not a clear common representation of functional blocks which is unambiguous across diffe

40、rent industries, disciplines, and perspectives. As tools that describe functional blocks are most often used by engineers for the design, development and construction of functional blocks, quite naturally, many tools give considerable emphasis to these phases of the functional block life cycle. For

41、example, in the construction phase, the reuse of common design features is especially important as reuse increases efficiency. Many tools therefore give considerable emphasis to the reuse of such features. In this case classification of functional blocks according to common design features is of con

42、siderable value and the natural starting point for describing functional blocks is the class. It is natural to start by representing a class of functional blocks which can be built using the same design. The class diagram can also contain hierarchy, for example an inheritance hierarchy, which can sh

43、ow increasing scope of design reuse at higher levels of the class hierarchy. However, when describing the operation of functional blocks, the individual instances of functional blocks and the way individual functional blocks interact with each other are important. In this case the natural starting p

44、oint is not the class but the individual instances. Classification and hierarchy of classification is much less relevant at the operations stage. More important is the way individual functional block instances are interconnected and interact. ETSI ETSI GS NFV-INF 007 V1.1.1 (2014-10) 8There are of c

45、ourse many other aspects to functional blocks which may be important to represent in different way. For example the nature of what is passed between functional blocks may be important to differentiate. In all information and network systems, it is information that is passed between the functional bl

46、ocks. However, even in this narrow category, in may be important to distinguish a continuous flow of information from discrete events. More general systems may pass fluid (pressure and flow), electricity (voltage and current), rotation (revs and torque), money, etc. The present document is concerned

47、 with the basic characteristics of information functional blocks. We can assume that all the parameters passed between functional blocks are information of one form or another. This clause considers some of the basic properties of information functional blocks. It focuses on the case where a functio

48、nal block such as a server or a network acts as a host functional block, hosting virtual functional blocks such as virtual machines and virtual networks. In this case, it is important to highlight the properties of functional blocks in operation and so all the discussion and diagrams in the present

49、document show functional block instances (and not classes of functional blocks) unless otherwise stated. 5.1 System Composition using Functional Blocks 5.1.1 Functional Blocks as the Primary Specification Method The great majority of specification of telecommunications systems specifies functional blocks using the methodology of systems engineering. A functional block is the basic unit of a system and its specification can and should be precise. A functional block, that is a single functional block instance, consists of: A set of input interfaces. State. A transf