idnits 2.17.1 draft-long-nfvrg-nfv-decoupling-test-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 25, 2019) is 1764 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5440' is defined on line 279, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 nfvrg Y. Long 3 Internet-Draft Y. Song 4 Intended status: Informational Z. Tang 5 Expires: December 27, 2019 BII 6 June 25, 2019 8 The practice of NFV decoupling test 9 draft-long-nfvrg-nfv-decoupling-test-01 11 Abstract 13 This document mainly introduces the practice of NFV decoupling test. 14 Based on the product development situation of the current vendors, 15 the decoupling test is carried out between NFVI&VIM, VNFM&VNF and 16 NFVO. Through a series of tests to explore some of the problems 17 encountered in the current stage of NFV decoupling testing, provide 18 ideas for the subsequent development of NFV products. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 27, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Decoupling test of NFV . . . . . . . . . . . . . . . . . . . 4 57 3.1. Introduce of NFV decoupling test . . . . . . . . . . . . 4 58 3.2. NFV decoupling test architecture . . . . . . . . . . . . 5 59 4. Decoupling test of NFV . . . . . . . . . . . . . . . . . . . 5 60 5. Informative References . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 3GPP has adopted the R15 standard and the SBA (Service Based 66 Architecture) architecture, which further splits multiple NFs(Network 67 Functions) in the 5G core network into multiple NFS (Network Function 68 Service), each NFS has the characteristics of independent autonomy. 69 But the existence of multiple NFSs in the clouded NFV also brings 70 compatibility problems. Therefore, one of the key requirements of 71 the 5G core network for the clouded NFV platform is open. The cloud 72 platform needs to implement decoupling deployment and network 73 resource sharing, thus not only avoiding the lock-up of single- 74 vendors but also can build an open ecosystem based on open source 75 projects. 77 But, there are still many problems in the decoupling of the clouded 78 NFV platform. The interfaces of different vendors are not 79 standardized and are not unified, which makes it difficult for the 80 components of the NFV platform to properly connect and provide 81 complete services. According to the [ETSI_GS_NFV_002], it divides 82 the NFV into multiple modules as shown in Figure 1. 84 o Virtualized Network Function (VNF). 86 o Element Management (EM). 88 o NFV Infrastructure, including: Hardware and virtualized resources, 89 and Virtualization Layer. 91 o Virtualized Infrastructure Manager(s) (VIM). 93 o NFV Orchestrator. 95 o VNF Manager(s). 97 o Service, VNF and Infrastructure Description. Operations and 98 Business Support Systems (OSS/BSS). 100 +--------------------+ 101 +-------------------------------------------+ | +--------------+ | 102 | OSS/BSS | | | NFV | | 103 +-------------------------------------------+ | | Orchestrator +-+ | 104 | +--+-----------+ | | 105 +-------------------------------------------+ | | | | 106 | +-------+ +-------+ +-------+ | | | | | 107 | | EM 1 | | EM 2 | | EM 3 | | | | | | 108 | +---+---+ +---+---+ +---+---+ | | +--+---------+ | | 109 | | | | +----+ VNF | | | 110 | +---+---+ +---+---+ +---+---+ | | | manager(s) | | | 111 | | VNF 1 | | VNF 2 | | VNF 3 | | | +--+---------+ | | 112 | +---+---+ +---+---+ +---+---+ | | | | | 113 +------|-------------|-------------|--------+ | | | | 114 | | | | | | | 115 +------+-------------+-------------+--------+ | | | | 116 | NFV Infrastructure (NFVI) | | | | | 117 | +---------+ +---------+ +---------+ | | | | | 118 | | Virtual | | Virtual | | Virtual | | | | | | 119 | | Compute | | Storage | | Network | | | | | | 120 | +---------+ +---------+ +---------+ | | +--+-----+ | | 121 | +---------------------------------------+ | | | | | | 122 | | Virtualization Layer | |--|-| VIM(s) +-------+ | 123 | +---------------------------------------+ | | | | | 124 | +---------------------------------------+ | | +--------+ | 125 | | +---------+ +---------+ +---------+ | | | | 126 | | | Compute | | Storage | | Network | | | | | 127 | | | hardware| | hardware| | hardware| | | | | 128 | | +---------- +---------+ +---------+ | | | | 129 | | Hardware resources | | | NFV Management | 130 | +---------------------------------------+ | | and Orchestration | 131 +-------------------------------------------+ +--------------------+ 132 Figure 1: ETSI NFV architecture 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC8174]. 140 NFVI&VIM, NFV Infrastructure and VIM. 142 VNFM, VNF Manager. 144 NFVO, NFV Orchestrator. 146 3. Decoupling test of NFV 148 3.1. Introduce of NFV decoupling test 150 In the ETSI NFV architecture, there are corresponding interfaces 151 between each modules. There will be a problem of interface 152 compatibility between the components as shown in the figure 1. 153 Decoupling tests are required to ensure that the decoupled components 154 can be properly integrated. According to the current vendors' 155 development, the main decoupling are between NFVI&VIM, VNFM&VNF and 156 NFVO. 158 Operators will generally develop NFVO to ensure compatibility with 159 existing OSS/BSS, VNF vendors trend to better control VNF, so they 160 will provide VNFM with VNF, and the underlying virtualization 161 management VIM vendors will also provide self-developed or generic 162 x86 servers as a whole NFV resource pool cloud solution. Therefore, 163 the decoupling of clouded NFV is simplified to the following figure 164 2. 166 +--------------------+ 167 | | 168 | NFV Orchestrator +--+ 169 | | | 170 +----------+---------+ | 171 | | 172 +-------------------------------------------+ +----------+---------+ | 173 | +-------+ +-------+ +-------+ | | | | | 174 | | EM 1 | | EM 2 | | EM 3 | | | | | | 175 | +---+---+ +---+---+ +---+---+ | | +------+-----+ | | 176 | | | | +--|---| VNF | | | 177 | +---+---- +---+---+ +---+---+ | | | manager(s) | | | 178 | | VNF 1 | | VNF 2 | | VNF 3 | | | +------+-----+ | | 179 | +---+---+ +---+---+ +---+---+ | | | | | 180 +------|-------------|-------------|--------+ +----------|---------+ | 181 | | | 182 +--------------------+------------------------------------+---------+ | 183 | | | 184 | +-----------------------------------------------------------+ | | 185 | | NFVI&VIM(s) +---+--+ 186 | +-----------------------------------------------------------+ | 187 | | 188 +-------------------------------------------------------------------+ 189 Figure 2: Simplified NFV decoupling architecture 191 In addition, from the perspective of VNFM, the scheduling of VIM 192 resources is divided into direct mode and indirect mode. NFVO sends 193 messages to VNFM and VNFM operates VIM to allocate VNF resources is 194 direct mode. In contrast, the way NFVO directly operates the VIM to 195 allocate the resources required by the VNF is considered an indirect 196 mode. This causes NFVO must to support different VNFM operating 197 modes. 199 3.2. NFV decoupling test architecture 201 The NFV decoupling test practice selects NFVI&VIM, VNF&VNFM and NFVO 202 vendors for interoperability tests. The main test content is 203 functional testing, such as: VNF lifecycle management (VNFD onboard, 204 VNF instantiate, VNF scale in/out, VNF terminate), VNF self-healing, 205 VNF update, VNF error management. 207 The test specification and testcases are reference to ETSI's NFV 208 standard [ETSI_NFV_TST_002] and [ETSI_NFV_TST_007]. The operator C's 209 NFVO is used as the unified orchestration layer, the vendors F and 210 H's VNF&VNFM as network elements and VNF management, and the vendor 211 F's infrastructure is tested as the underlying virtualization 212 infrastructure. The decoupling test architecture is shown in figure 213 3. 215 +----------------+ 216 | Vendor +--+ 217 | C | | 218 +------+---------+ | 219 | | 220 +---------------+ +------+---------+ | 221 | Vendor +--+ Vendor | | 222 | H | | H | | 223 +------+--------+ +------+---------+ | 224 | | | 225 +------+------------------+---------+ | 226 | Vendor +--+ 227 | F | 228 +-----------------------------------+ 229 Figure 3: NFV decoupling test architecture 231 4. Decoupling test of NFV 233 The test results are shown in the following table 1. 235 +-------------------+----------+----------+ 236 | Testcases | Vendor F | Vendor H | 237 +-------------------+----------+----------+ 238 | Onboard | PASS | PASS | 239 | Instantiate | PASS | PASS | 240 | Scale in(manual) | PASS | PASS | 241 | Scale out(manual) | PASS | PASS | 242 | Terminate | PASS | PASS | 243 +-------------------+----------+----------+ 245 The test results show that under the ETSI NFV standards, the basic 246 interoperability tests such as VNF onboard, instantiate, manual scale 247 in/out and terminate, can be executed successfully, while the VNF 248 self-healing, VNF update, VNF error management are failed due to VNFM 249 and NFVO unconformable interface. The main reason is that the 250 closure of the VNF vendors and the data exchange format reported by 251 the state are inconsistent, usually only exchange data with their own 252 NFVO. This exclusivity makes it difficult for the vendor's VNFM&VNF 253 to communicate with the different NFVO vendors, especially some 254 advance features, this has led operators to develop a variety of ways 255 to obtain VNF status, and also encounter many compatibility issues 256 when integration multi-vendor VNFs and VNFMs. 258 5. Informative References 260 [ETSI_GS_NFV_002] 261 ETSI NFV ISG, "ETSI GS NFV 002: "Network Functions 262 Virtualisation (NFV); Architectural Framework"", December 263 2014, . 266 [ETSI_NFV_TST_002] 267 ETSI NFV ISG, "ETSI GS NFV-TST 002: "Network Functions 268 Virtualisation (NFV); Testing Methodology; Report on NFV 269 Interoperability Testing Methodology."", October 2016, 270 . 273 [ETSI_NFV_TST_007] 274 ETSI NFV ISG, "ETSI GR NFV-TST 007: "Testing; Guidelines 275 on Interoperability Testing for MANO."", August 2018, 276 . 279 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 280 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 281 DOI 10.17487/RFC5440, March 2009, 282 . 284 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 285 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 286 May 2017, . 288 Authors' Addresses 290 Yu Long 291 BII Group Holdings Ltd. 292 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China 293 Beijing 101111 294 P. R. China 296 Email: ylong@biigroup.cn 298 Yang Song 299 BII Group Holdings Ltd. 300 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China 301 Beijing 101111 302 P. R. China 304 Email: ysong@biigroup.cn 306 Zhijun Tang 307 BII Group Holdings Ltd. 308 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China 309 Beijing 101111 310 P. R. China 312 Email: zjtang@biigroup.cn