idnits 2.17.1 draft-long-nfvrg-nfv-decoupling-test-03.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 (Jun 15, 2020) is 1409 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5440' is defined on line 278, 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 BII 5 Expires: December 17, 2020 Jun 15, 2020 7 The practice of NFV decoupling test 8 draft-long-nfvrg-nfv-decoupling-test-03 10 Abstract 12 This document mainly introduces the practice of NFV decoupling test. 13 Based on the product development situation of the current vendors, 14 the decoupling test is carried out between NFVI&VIM, VNFM&VNF and 15 NFVO. Through a series of tests to explore some of the problems 16 encountered in the current stage of NFV decoupling testing, provide 17 ideas for the subsequent development of NFV products. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 17, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Decoupling test of NFV . . . . . . . . . . . . . . . . . . . 4 56 3.1. Introduce of NFV decoupling test . . . . . . . . . . . . 4 57 3.2. NFV decoupling test architecture . . . . . . . . . . . . 5 58 4. Decoupling test of NFV . . . . . . . . . . . . . . . . . . . 5 59 5. Informative References . . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 3GPP has adopted the R15 standard and the SBA (Service Based 65 Architecture) architecture, which further splits multiple NFs(Network 66 Functions) in the 5G core network into multiple NFS (Network Function 67 Service), each NFS has the characteristics of independent autonomy. 68 But the existence of multiple NFSs in the clouded NFV also brings 69 compatibility problems. Therefore, one of the key requirements of 70 the 5G core network for the clouded NFV platform is open. The cloud 71 platform needs to implement decoupling deployment and network 72 resource sharing, thus not only avoiding the lock-up of single- 73 vendors but also can build an open ecosystem based on open source 74 projects. 76 But, there are still many problems in the decoupling of the NFV 77 platform. The interfaces of different vendors are not standardized 78 and are not unified, which makes it difficult for the components of 79 the NFV platform to properly connect and provide complete services. 80 According to the [ETSI_GS_NFV_002], it divides the NFV into multiple 81 modules as shown in Figure 1. 83 o Virtualized Network Function (VNF). 85 o Element Management (EM). 87 o NFV Infrastructure, including: Hardware and virtualized resources, 88 and Virtualization Layer. 90 o Virtualized Infrastructure Manager(s) (VIM). 92 o NFV Orchestrator. 94 o VNF Manager(s). 96 o Service, VNF and Infrastructure Description. Operations and 97 Business Support Systems (OSS/BSS). 99 +--------------------+ 100 +-------------------------------------------+ | +--------------+ | 101 | OSS/BSS | | | NFV | | 102 +-------------------------------------------+ | | Orchestrator +-+ | 103 | +--+-----------+ | | 104 +-------------------------------------------+ | | | | 105 | +-------+ +-------+ +-------+ | | | | | 106 | | EM 1 | | EM 2 | | EM 3 | | | | | | 107 | +---+---+ +---+---+ +---+---+ | | +--+---------+ | | 108 | | | | +----+ VNF | | | 109 | +---+---+ +---+---+ +---+---+ | | | manager(s) | | | 110 | | VNF 1 | | VNF 2 | | VNF 3 | | | +--+---------+ | | 111 | +---+---+ +---+---+ +---+---+ | | | | | 112 +------|-------------|-------------|--------+ | | | | 113 | | | | | | | 114 +------+-------------+-------------+--------+ | | | | 115 | NFV Infrastructure (NFVI) | | | | | 116 | +---------+ +---------+ +---------+ | | | | | 117 | | Virtual | | Virtual | | Virtual | | | | | | 118 | | Compute | | Storage | | Network | | | | | | 119 | +---------+ +---------+ +---------+ | | +--+-----+ | | 120 | +---------------------------------------+ | | | | | | 121 | | Virtualization Layer | |--|-| VIM(s) +-------+ | 122 | +---------------------------------------+ | | | | | 123 | +---------------------------------------+ | | +--------+ | 124 | | +---------+ +---------+ +---------+ | | | | 125 | | | Compute | | Storage | | Network | | | | | 126 | | | hardware| | hardware| | hardware| | | | | 127 | | +---------- +---------+ +---------+ | | | | 128 | | Hardware resources | | | NFV Management | 129 | +---------------------------------------+ | | and Orchestration | 130 +-------------------------------------------+ +--------------------+ 131 Figure 1: ETSI NFV architecture 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC8174]. 139 NFVI&VIM, NFV Infrastructure and VIM. 141 VNFM, VNF Manager. 143 NFVO, NFV Orchestrator. 145 3. Decoupling test of NFV 147 3.1. Introduce of NFV decoupling test 149 In the ETSI NFV architecture, there are corresponding interfaces 150 between each modules. There will be a problem of interface 151 compatibility between the components as shown in the figure 1. 152 Decoupling tests are required to ensure that the decoupled components 153 can be properly integrated. According to the current vendors' 154 development, the main decoupling are between NFVI&VIM, VNFM&VNF and 155 NFVO. 157 Operators will generally develop NFVO to ensure compatibility with 158 existing OSS/BSS, VNF vendors trend to better control VNF, so they 159 will provide VNFM with VNF, and the underlying virtualization 160 management VIM vendors will also provide self-developed or generic 161 x86 servers as a whole NFV resource pool cloud solution. Therefore, 162 the decoupling of clouded NFV is simplified to the following figure 163 2. 165 +--------------------+ 166 | | 167 | NFV Orchestrator +--+ 168 | | | 169 +----------+---------+ | 170 | | 171 +-------------------------------------------+ +----------+---------+ | 172 | +-------+ +-------+ +-------+ | | | | | 173 | | EM 1 | | EM 2 | | EM 3 | | | | | | 174 | +---+---+ +---+---+ +---+---+ | | +------+-----+ | | 175 | | | | +--|---| VNF | | | 176 | +---+---- +---+---+ +---+---+ | | | manager(s) | | | 177 | | VNF 1 | | VNF 2 | | VNF 3 | | | +------+-----+ | | 178 | +---+---+ +---+---+ +---+---+ | | | | | 179 +------|-------------|-------------|--------+ +----------|---------+ | 180 | | | 181 +--------------------+------------------------------------+---------+ | 182 | | | 183 | +-----------------------------------------------------------+ | | 184 | | NFVI&VIM(s) +---+--+ 185 | +-----------------------------------------------------------+ | 186 | | 187 +-------------------------------------------------------------------+ 188 Figure 2: Simplified NFV decoupling architecture 190 In addition, from the perspective of VNFM, the scheduling of VIM 191 resources is divided into direct mode and indirect mode. NFVO sends 192 messages to VNFM and VNFM operates VIM to allocate VNF resources is 193 direct mode. In contrast, the way NFVO directly operates the VIM to 194 allocate the resources required by the VNF is considered an indirect 195 mode. This causes NFVO must to support different VNFM operating 196 modes. 198 3.2. NFV decoupling test architecture 200 The NFV decoupling test practice selects NFVI&VIM, VNF&VNFM and NFVO 201 vendors for interoperability tests. The main test content is 202 functional testing, such as: VNF lifecycle management (VNFD onboard, 203 VNF instantiate, VNF scale in/out, VNF terminate), VNF self-healing, 204 VNF update, VNF error management. 206 The test specification and testcases are reference to ETSI's NFV 207 standard [ETSI_NFV_TST_002] and [ETSI_NFV_TST_007]. The operator C's 208 NFVO is used as the unified orchestration layer, the vendors F and 209 H's VNF&VNFM as network elements and VNF management, and the vendor 210 F's infrastructure is tested as the underlying virtualization 211 infrastructure. The decoupling test architecture is shown in figure 212 3. 214 +----------------+ 215 | Vendor +--+ 216 | C | | 217 +------+---------+ | 218 | | 219 +---------------+ +------+---------+ | 220 | Vendor +--+ Vendor | | 221 | H | | H | | 222 +------+--------+ +------+---------+ | 223 | | | 224 +------+------------------+---------+ | 225 | Vendor +--+ 226 | F | 227 +-----------------------------------+ 228 Figure 3: NFV decoupling test architecture 230 4. Decoupling test of NFV 232 The test results are shown in the following table 1. 234 +-------------------+----------+----------+ 235 | Testcases | Vendor F | Vendor H | 236 +-------------------+----------+----------+ 237 | Onboard | PASS | PASS | 238 | Instantiate | PASS | PASS | 239 | Scale in(manual) | PASS | PASS | 240 | Scale out(manual) | PASS | PASS | 241 | Terminate | PASS | PASS | 242 +-------------------+----------+----------+ 244 The test results show that under the ETSI NFV standards, the basic 245 interoperability tests such as VNF onboard, instantiate, manual scale 246 in/out and terminate, can be executed successfully, while the VNF 247 self-healing, VNF update, VNF error management are failed due to VNFM 248 and NFVO unconformable interface. The main reason is that the 249 closure of the VNF vendors and the data exchange format reported by 250 the state are inconsistent, usually only exchange data with their own 251 NFVO. This exclusivity makes it difficult for the vendor's VNFM&VNF 252 to communicate with the different NFVO vendors, especially some 253 advance features, this has led operators to develop a variety of ways 254 to obtain VNF status, and also encounter many compatibility issues 255 when integration multi-vendor VNFs and VNFMs. 257 5. Informative References 259 [ETSI_GS_NFV_002] 260 ETSI NFV ISG, "ETSI GS NFV 002: "Network Functions 261 Virtualisation (NFV); Architectural Framework"", December 262 2014, . 265 [ETSI_NFV_TST_002] 266 ETSI NFV ISG, "ETSI GS NFV-TST 002: "Network Functions 267 Virtualisation (NFV); Testing Methodology; Report on NFV 268 Interoperability Testing Methodology."", October 2016, 269 . 272 [ETSI_NFV_TST_007] 273 ETSI NFV ISG, "ETSI GR NFV-TST 007: "Testing; Guidelines 274 on Interoperability Testing for MANO."", August 2018, 275 . 278 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 279 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 280 DOI 10.17487/RFC5440, March 2009, 281 . 283 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 284 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 285 May 2017, . 287 Authors' Addresses 289 Yu Long 290 BII Group Holdings Ltd. 291 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China 292 Beijing 101111 293 P. R. China 295 Email: ylong@biigroup.cn 297 Yang Song 298 BII Group Holdings Ltd. 299 2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, China 300 Beijing 101111 301 P. R. China 303 Email: ysong@biigroup.cn