idnits 2.17.1 draft-yang-i2nsf-nfv-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Hyunsik Yang 2 Internet-Draft Younghan Kim 3 Intended status: Informational Soongsil University 4 Expires: April 2018 October 30, 20177 6 I2nsf on the NFV Reference Architecture 7 draft-yang-i2nsf-nfv-architecture-00.txt 9 Abstract 11 This document describes the adoption of i2nsf Framework onto the 12 Network Functions Virtualization (NFV) Reference Model. In this 13 document, we explain the i2nsf Framework adopted to NFV reference 14 architecture with each corresponding component. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may not be modified, 20 and derivative works of it may not be created, and it may not be 21 published except as an Internet-Draft. 23 This document may contain material from IETF Documents or IETF 24 Contributions published or made publicly available before November 25 10, 2008. The person(s) controlling the copyright in some of this 26 material may not have granted the IETF Trust the right to allow 27 modifications of such material outside the IETF Standards Process. 28 Without obtaining an adequate license from the person(s) controlling 29 the copyright in such materials, this document may not be modified 30 outside the IETF Standards Process, and derivative works of it may 31 not be created outside the IETF Standards Process, except to format 32 it for publication as an RFC or to translate it into languages other 33 than English. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. 43 It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 This Internet-Draft will expire on April 30 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with 63 respect to this document. Code Components extracted from this 64 document must include Simplified BSD License text as described in 65 Section 4.e of the Trust Legal Provisions and are provided 66 without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction ................................................ 4 71 1.1. Terminology ............................................ 4 72 2. I2NSF framework onto the NFV Reference Model ................ 4 73 2.1. NSF .................................................... 6 74 2.2. Security Controller..................................... 7 75 2.3. Developer's Mgmt System................................. 7 76 2.4. Interfaces ............................................. 8 77 2.4.1. Consumer-Facing Interface ......................... 8 78 2.4.2. NSF-Facing Interface............................... 8 79 2.4.3. Registration Interface............................. 8 80 3. Use case - SFC Enabled I2NSF framework ..................... 9 81 3.1. SFC Policy Manager...................................... 9 82 3.2. SFC Catalog Manager.................................... 10 83 3.3. Developer's Mgmt System................................ 10 84 4. Security Considerations..................................... 11 85 5. IANA Considerations ........................................ 11 86 6. References ................................................. 11 87 6.1. Normative References................................... 11 88 6.2. Informative References................................. 12 90 1. Introduction 92 The goal of I2NSF is to define a set of software interfaces and 93 components for controlling and monitoring aspects of physical and 94 virtual NSFs, enabling clients to specify rules set. To enable I2NSF 95 environment, I2NSF framework not only considers physical 96 infrastructure but also considers the NFV environment since NSF may 97 be provided by virtualized infrastructure as a vnfs. Especially, 98 I2NSF applicability document [i2nsf-applicability] describes the 99 applicability of interface to Network Security Functions to 100 network-based security services in NFV environment. Although it 101 explains how i2nsf provides security service in NFV environment, it 102 doesn't consider how i2nsf framework adopted onto the NFV reference 103 architecture. 105 Therefore, we explain the i2nsf framework adopted to NFV reference 106 architecture with each corresponding component. 108 1.1. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 This document uses the terminology described in [i2nsf-framework], 115 [i2nsf-terminology], [i2nsf-applicability],[etsi-gs-nfv-003] and 116 [nsf-triggered-steering]. 118 2. I2NSF framework onto the NFV Reference Model 120 The European Telecommunications Standards Institute (ETSI) defined 121 the components for the basic NFV architecture including the NFV 122 Infrastructure (NFVI), VNF Manager (VNFM), Virtualization 123 Infrastructure Manager (VIM), and NFV Orchestrator (NFVO). [etsi-gs- 124 nfv-003] NFVI provides the virtual resources, such as VM and virtual 125 network, used to create, update, and delete VNFs running 126 applications. VNFs are implemented through software virtualization 127 techniques running over the NFVI. 129 Virtualized Infrastructure Manager (VIM) has a function for 130 controlling and managing the NFVI compute, storage and network 131 resources, within one operator's infrastructure sub-domain. It also 132 collects and forwards performance measurements and events. 134 VNFM manages the VNF lifecycle. When a VNF is created, the VNFM 135 manages the VNF instance in the lifecycle, and the VNFM performs 136 several actions such as software update/modification, monitoring 137 data collection-a fault event in the VNF, and instance termination. 138 According to definition of ETSI, the VNFM is divided into Generic 139 VNFM and Specific VNFM. When the VNFs have their specific methods 140 for provisioning and lifecycle management, a specific VNFM required. 142 In the I2NSF framework [i2nsf-framework], they defined several 143 components such as NSF, Security controller and Developer's Mgmt 144 System. To adopt these components to the NFV reference architecture, 145 each component should be classified based on functionality. 146 According to component functionality, it would correspond to NFV 147 reference architecture components as Figure 1. 149 +-------------------------------------------+ | ---------------- | 150 | OSS/BSS | | | NFV | | 151 +-------------------------------------------+ | | Orchestrator +-- | 152 consumer interface | ---+------------ | | 153 +-------------------------------------------+ | | | | 154 | ------------------------------------- | | | | | 155 | | Security Controller(EM) | | | | | | 156 | ------------------+------------------ | | ---+---------- | | 157 | | NSF-facing interface | |(a)-| Devloper's | | | 158 | ----+---- ----+---- ----+---- | | | Mgmt(VNFM) | | | 159 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | ---+---------- | | 160 | ----+---- ----+---- ----+---- | | | | | 161 +------|-------------|-------------|--------+ | | | | 162 | | | | | | | 163 +------+-------------+-------------+--------+ | | | | 164 | NFV Infrastructure (NFVI) | | | | | 165 | ----------- ----------- ----------- | | | | | 166 | | Virtual | | Virtual | | Virtual | | | | | | 167 | | Compute | | Storage | | Network | | | | | | 168 | ----------- ----------- ----------- | | ---+------ | | 169 | +---------------------------------------+ | | | | | | 170 | | Virtualization Layer | |--|-| VIM(s) +-------- | 171 | +---------------------------------------+ | | | | | 172 | +---------------------------------------+ | | ---------- | 173 | | ----------- ----------- ----------- | | | | 174 | | | Compute | | Storage | | Network | | | | | 175 | | | hardware| | hardware| | hardware| | | | | 176 | | ----------- ----------- ----------- | | | | 177 | | Hardware resources | | | NFV Management | 178 | +---------------------------------------+ | | and Orchestration | 179 +-------------------------------------------+ +--------------------+ 180 (a)= Registration interface 182 Figure 1. I2NSF architecture on NFV reference architecture 184 2.1. NSF 186 Network Security Function is one of the security service functions. 188 In the ETSI reference architecture, VNF(Virtual Network Function)is 189 the network functions which provide specific service. 191 Therefore, NSF corresponds to the VNF in NFV reference architecture. 193 2.2. Security Controller 195 According to I2NSF framework, the security controller has a role 196 which translate policy according to user's request and delivers low 197 level policy to NSFs(manages NSF). It also collects NSF capability 198 from developer's Mgmt System. Based on this information, 199 the security controller forwards policy to NSF. 201 In the NFV reference architecture, EM has a role that it may be 202 aware of virtualization and collaborate with the VNF Manager to 203 perform those functions that require exchanges of information 204 regarding the NFVI Resources associated with the VNF. 205 EM performs typical management functionality for one or 206 several VNFs. 208 Therefore, the Security controller corresponds to Element management 209 since it should provide the function which controls NSF and policy. 210 In the case of a distributed security controller model, an interface 211 which is used to communicate between controllers should also be 212 considered. 214 2.3. Developer's Mgmt System 216 According to the definition of I2NSF Registration Interface, 217 Developer's Mgmt system registers NSF which can be provided by 218 specific vender. Developer's Mgmt system also can be one of the 219 venders too. 221 In the NFV reference architecture, VNFM manages the VNF lifecycle. 222 It also performs several actions such as software update, monitoring 223 and fault management. 224 Generally, generic VNFM means that only one VNFM 225 handle all of the VNF in the NFV environment. However, if additional 226 VNFMs are required for management of specific VNFs, additional VFNMs 227 can be defined as specific VNFMs. 229 Therefore, if Developer's Mgmt System manages the NSF lifecycle, it 230 can logically correspond to a specific VNFM. 232 2.4. Interfaces 234 2.4.1. Consumer-Facing Interface 236 The Consumer-Facing Interface is an interface for communication 237 between the User and the Security Controller. It is used to enable 238 different users of a given I2NSF system to define, manage, and 239 monitor security policies for specific flows within 240 an administrative domain. 242 In the NFV reference architecture, OSS is Operational Support 243 Systems and BSS stands for Business Support Systems. OSS/BSS support 244 the system which relates to infra management such as billing, order 245 and metering. 247 Although an interface is not defined between User and EM in the NFV 248 reference architecture, Consumer-Facing interface can be deployed 249 between user and EM. 251 2.4.2. NSF-Facing Interface 253 The NSF-Facing Interface is an interface for communication between 254 Security Controller and NSF. It is used to specify and monitor flow- 255 based security policies enforced by one or more NSFs. 257 In the NFV reference architecture, Software Architecture (SWA)-4 258 Interface is defined. The interface SWA-4 is used by the EM to 259 communicate with a VNF. This management interface is used for the 260 runtime management of the VNF according to the Fulfillment, 261 Assurance,and Billing and FCAPS(Fault, Configuration, Accounting, 262 Performance,Security) network management models and frameworks. 264 Therefore, NSF-Facing Interface corresponds to the SWA-4 interface. 266 2.4.3. Registration Interface 268 Registration Interface is used to register NSF from Developer's Mgmt 269 System to the security controller. An NSF's capabilities can either 270 be pre-configured or retrieved dynamically through the I 271 Registration Interface. 273 Above, this document mentioned that, the Developer's Mgmt System 274 handles the NSF life cycle and this interface corresponds to Ve-Vnfm 275 which is defined in the NFV reference architecture. Ve-Vnfm is 276 defined as IFA008 in ETSI document. 277 IFA008 composed of two interfaces. One is Ve-Vnfm-em, another is 278 Ve-Vnfm-VNF. If security controller is deployed as an EM, then the 279 registration interface corresponds to Ve-Vnfm-em. 281 3. Use case - SFC Enabled I2NSF framework 283 In the I2NSF WG, some documents mentioned use cases for cloud based 284 security with forwarding mechanism. Especially SFC enabled I2NSF 285 document [nsf-triggered-steering] showed the use case which used SFC 286 as a forwarding mechanism. In addition, it defined additional 287 components and extended functionality of components. Therefore, in 288 the following section, we explain the details of each component and 289 consider how it corresponds to the NFV reference architecture. 291 3.1. SFC Policy Manager 293 SFC policy manager is a part of the security controller. It is 294 responsible for interpreting a high level policy into a low-level 295 SFC policy, which is given by I2NSF client. It also handles delivery 296 of the interpreted policy to classifiers for security function 297 chaining. Moreover, it also generates an SF forwarding table and 298 distributes the forwarding information to SFF(s). 300 In the NFV reference architecture, MANO performs similar functions 301 as the SFC policy manager. 302 More specifically the NFV orchestrator(NFVO) performs on-boarding of 303 new Network Service (NS), VNF-FG(forwarding graph) and VNF Packages. 304 In addition, it manages NS lifecycle (including instantiation, 305 scale-out/in, performance measurements, event correlation and 306 termination). 308 Therefore, SFC policy manager corresponds to NFVO. In addition, if 309 SFC policy manager is a part of Security controller, this function 310 should be separated from security controller. 312 3.2. SFC Catalog Manager 314 SFC catalog manger is a part of the security controller. It is 315 responsible for maintaining the information of every available SF 316 instance such as IP address, supported transport protocol, service 317 name, and load status. Moreover, it should respond to the queries 318 for available SF instances from SFC Policy Manager so as to help to 319 generate a forwarding table entry relevant to a given SFP. It also 320 request Developer's Management System to dynamically instantiate 321 supplementary SF instances to avoid service congestion or the 322 elimination of an existing SF instance to avoid resource waste. 324 In the NFV reference architecture, SFC catalog manager corresponds 325 to Element management since information which is related to VNF 326 capability is managed by EM. Moreover, this function is similar to 327 security controller as we explained earlier. 329 3.3. Developer's Mgmt System 331 In the SFC enabled document, the function of Developer's Mgmt system 332 is extended. Following the request message from SFC catalog manager, 333 it creates additional SF instances and eliminates some of the SF 334 instances. 336 As mentioned above, if Developer's Mgmt system manages the NSF's 337 lifecycle, it corresponds to a specific VNF Manager. VNF life cycle 338 management includes instantiating, creating, provisioning, scaling, 339 monitoring, and termination of VMs in a VNF instance. Therefore, the 340 Developer's Mgmt system corresponds to a specific VNF Manager. 342 However, for scaling performed at a network service level, the role 343 of Developer's Mgmt system should extend to the MANOManage and 344 orchestrator). 346 SFC catalog manger is a part of the security controller. It is 347 responsible for maintaining the information of every available SF 348 instance such as IP address, supported transport protocol, service 349 name, and load status. Moreover, it should respond to the queries 350 for available SF instances from SFC Policy Manager so as to help to 351 generate a forwarding table entry relevant to a given SFP. It also 352 request Developer's Management System to dynamically instantiate 353 supplementary SF instances to avoid service congestion or the 354 elimination of an existing SF instance to avoid resource waste. 356 In the NFV reference architecture, SFC catalog manager corresponds 357 to Element management since information which is related to VNF 358 capability is managed by EM. Moreover, this function is similar to 359 security controller as we explained earlier. 361 4. Security Considerations 363 N/A 365 5. IANA Considerations 367 This document has no IANA actions. 369 6. References 371 6.1. Normative References 373 [RFC2119] 375 Bradner, S., "Key words for use in RFCs to 376 Indicate Requirement Levels", BCP 14, 377 RFC 2119, March 1997. 379 [i2nsf-framework] 381 Lopez, D., Lopez, E., Dunbar, L.,Strassner, J., and R. 382 Kumar, "Framework for Interface to Network Security 383 Functions",draft-ietf-i2nsf-framework-07 (work in progress) 384 ,August 2017. 386 [i2nsf-terminology] 388 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 389 Birkholz, "Interface to Network Security Functions (i2nsf) 390 Terminology",draft-ietf-i2nsf-terminology-04 (work in 391 progress), July 2017. 393 [etsi-gs-nfv-003] 395 ETSI NFV ISG, "Network Functions Virtualisation (NFV); 396 Terminology for Main Concepts in NFV", ETSI GS NFV 002 397 V1.1.1 NFV 002, October 2013, 398 401 6.2. Informative References 403 [i2nsf-applicability] 405 J. Jeong., S. Hyun., T. Ahn., S. Hares., D. Lopez.," 406 Applicability of Interfaces to Network Security Functions 407 to Network-Based Security Services",draft-ietf-i2nsf- 408 applicability-00(work in progress),October, 2017. 410 [nsf-triggered-steering] 412 Hyun, S., Jeong, J., Park, J., and S.Hares, "Service 413 Function Chaining-Enabled i2nsf Architecture",draft-hyun- 414 i2nsf-nsf-triggered-steering-03(work in progress), July 415 2017. 417 Authors' Addresses 419 Hyunsik Yang 420 Soongsil University 421 369, Sangdo-ro, Dongjak-gu, 422 Seoul 156-743, Korea 423 Email: yangun@dcn.ssu.ac.kr 425 Younghan Kim 426 Soongsil University 427 369, Sangdo-ro, Dongjak-gu, 428 Seoul 156-743, Korea 429 Email: younghak@ssu.ac.kr