idnits 2.17.1 draft-yang-i2nsf-nfv-architecture-02.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 16) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) 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.) -- The document date (June 29, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 121 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: December 2018 June 29, 2018 6 I2NSF on the NFV Reference Architecture 7 draft-yang-i2nsf-nfv-architecture-02.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 August 8 2018. 53 Copyright Notice 55 Copyright (c) 2018 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 ............................................. 7 77 2.4.1. Consumer-Facing Interface ......................... 7 78 2.4.2. NSF-Facing Interface .............................. 8 79 2.4.3. Registration Interface ............................ 8 80 3. I2NSF framework onto the NFV Reference Model(Alternative) ... 9 81 3.1. Security Controller ................................... 10 82 3.2. Developer's Mgmt System ............................... 10 83 3.3. Interfaces ............................................ 10 84 3.3.1. Consumer-Facing Interface ........................ 10 85 3.3.2. NSF-Facing Interface ............................. 11 86 3.3.3. Registration Interface ........................... 11 87 4. Multi-site Consideration ................................... 11 88 5. Use case - SFC Enabled I2NSF framework .................... 12 89 5.1. SFC Policy Manager .................................... 12 90 5.2. SFC Catalog Manager ................................... 13 91 5.3. Developer's Mgmt System ............................... 13 92 6. Security Considerations .................................... 14 93 7. IANA Considerations ........................................ 14 94 8. References ................................................. 14 95 8.1. Normative References .................................. 14 96 8.2. Informative References ................................ 15 98 1. Introduction 100 The goal of I2NSF is to define a set of software interfaces and 101 components for controlling and monitoring aspects of physical and 102 virtual NSFs, enabling clients to specify rules set. To enable I2NSF 103 environment, I2NSF framework not only considers physical 104 infrastructure but also considers the NFV environment since NSF may 105 be provided by virtualized infrastructure as a vnfs. Especially, 106 I2NSF applicability document [i2NSF-applicability] describes the 107 applicability of interface to Network Security Functions(I2NSF) to 108 network-based security services in NFV environment. Although it 109 explains how I2NSF provides security service in NFV environment, it 110 doesn't consider how I2NSF framework adopted onto the NFV reference 111 architecture. 113 Therefore, we explain the I2NSF framework adopted to NFV reference 114 architecture with each corresponding component. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC-2119 [RFC2119]. 122 This document uses the terminology described in [i2nsf- 123 framework],[i2nsf-terminology], [i2nsf-applicability], [etsi-gs-nfv- 124 003] and [nsf-triggered-steering]. 126 2. I2NSF framework onto the NFV Reference Model 128 The European Telecommunications Standards Institute (ETSI) defined 129 the components for the basic NFV architecture including the NFV 130 Infrastructure (NFVI), VNF Manager (VNFM), Virtualization 131 Infrastructure Manager (VIM), and NFV Orchestrator (NFVO). [etsi-gs- 132 nfv-003] NFVI provides the virtual resources, such as VM and virtual 133 network, used to create, update, and delete VNFs running 134 applications. VNFs are implemented through software virtualization 135 techniques running over the NFVI. 137 Virtualized Infrastructure Manager (VIM) has a function for 138 controlling and managing the NFVI compute, storage and network 139 resources, within one operator's infrastructure sub-domain. It also 140 collects and forwards performance measurements and events. 142 VNFM manages the VNF lifecycle. When a VNF is created, the VNFM 143 manages the VNF instance in the lifecycle, and the VNFM performs 144 several actions such as software update/modification, monitoring data 145 collection - a fault event in the VNF, and instance termination. 146 According to definition of ETSI, the VNFM is divided into Generic 147 VNFM and Specific VNFM. When the VNFs have their specific methods for 148 provisioning and lifecycle management, a specific VNFM required. 150 In the I2NSF framework [i2nsf-framework], they defined several 151 components such as NSF, Security controller and Developer's Mgmt 152 System. To adopt these components to the NFV reference architecture, 153 each component should be classified based on functionality. According 154 to component functionality, it would correspond to NFV reference 155 architecture components as Figure 1. 157 +-------------------------------------------+ | +--------------+ | 158 | OSS/BSS | | | NFV | | 159 +-------------------------------------------+ | | Orchestrator +-+ | 160 Consumer facing interface | +--+-----------+ | | 161 +-------------------------------------------+ | | | | 162 | +-----------------------------------+ | | | | | 163 | | Security Controller(EM) | | | | | | 164 | +-----------------+-----------------+ | | +--+---------+ | | 165 | | NSF-facing interface | |(a)-| Devloper's | | | 166 | +---+----+ +---+----+ +---+----+ | | | Mgmt(VNFM) | | | 167 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | +--+---------+ | | 168 | +---+----+ +---+----+ +---+----+ | | | | | 169 +------|-------------|-------------|--------+ | | | | 170 | | | | | | | 171 +------+-------------+-------------+--------+ | | | | 172 | NFV Infrastructure (NFVI) | | | | | 173 | +---------+ +---------+ +---------+ | | | | | 174 | | Virtual | | Virtual | | Virtual | | | | | | 175 | | Compute | | Storage | | Network | | | | | | 176 | +---------+ +---------+ +---------+ | | +--+-----+ | | 177 | +---------------------------------------+ | | | | | | 178 | | Virtualization Layer | |--|-| VIM(s) +-------- | 179 | +---------------------------------------+ | | | | | 180 | +---------------------------------------+ | | +--------+ | 181 | | +---------+ +---------+ +---------+ | | | | 182 | | | Compute | | Storage | | Network | | | | | 183 | | | hardware| | hardware| | hardware| | | | | 184 | | +---------+ +---------+ +---------+ | | | | 185 | | Hardware resources | | | NFV Management | 186 | +---------------------------------------+ | | and Orchestration | 187 +-------------------------------------------+ +--------------------+ 188 (a)= Registration interface 190 Figure 1. I2NSF architecture on NFV reference architecture 192 2.1. NSF 193 Network Security Function is one of the security service functions. 195 In the ETSI reference architecture, VNF(Virtual Network Function)is 196 the network functions which provide specific service. 198 Therefore, NSF corresponds to the VNF in NFV reference architecture. 200 2.2. Security Controller 202 According to I2NSF framework, the security controller has a role 203 which translate policy according to user's request and delivers low 204 level policy to NSFs(manages NSF). It also collects NSF capability 205 from developer's Mgmt System. Based on this information, the security 206 controller forwards policy to NSF. 208 In the NFV reference architecture, EM has a role that it may be aware 209 of virtualization and collaborate with the VNF Manager to perform 210 those functions that require exchanges of information regarding the 211 NFVI Resources associated with the VNF. EM performs typical 212 management functionality for one or several VNFs. 214 Therefore, the Security controller corresponds to Element management 215 since it should provide the function which controls NSF and policy. 216 In the case of a distributed security controller model, an interface 217 which is used to communicate between controllers should also be 218 considered. 220 2.3. Developer's Mgmt System 222 According to the definition of I2NSF Registration Interface, 223 Developer's Mgmt system registers NSF which can be provided by 224 specific vendor. Developer's Mgmt system also can be one of the 225 vendors too. 227 In the NFV reference architecture, VNFM manages the VNF lifecycle. It 228 also performs several actions such as software update, monitoring and 229 fault management. Generally, generic VNFM means that only one VNFM 230 handle all of the VNF in the NFV environment. However, if additional 231 VNFMs are required for management of specific VNFs, additional VFNMs 232 can be defined as specific VNFMs. 234 Therefore, if Developer's Mgmt System manages the NSF lifecycle, it 235 can logically correspond to a specific VNFM. 237 2.4. Interfaces 239 2.4.1. Consumer-Facing Interface 241 The Consumer-Facing Interface is an interface for communication 242 between the User and the Security Controller. It is used to enable 243 different users of a given I2NSF system to define, manage, and 244 monitor security policies for specific flows within an administrative 245 domain. 247 In the NFV reference architecture, OSS is Operational Support Systems 248 and BSS stands for Business Support Systems. OSS/BSS support the 249 system for users which relates to infra management such as billing, 250 order and metering. 251 Although an interface is not defined between User and EM in the NFV 252 reference architecture, Consumer-Facing interface can be deployed 253 between user and EM. 255 2.4.2. NSF-Facing Interface 257 The NSF-Facing Interface is an interface for communication between 258 Security Controller and NSF. It is used to specify and monitor flow- 259 based security policies enforced by one or more NSFs. 261 In the NFV reference architecture, Software Architecture (SWA)-4 262 Interface is defined. The interface SWA-4 is used by the EM to 263 communicate with a VNF. This management interface is used for the 264 runtime management of the VNF according to the Fulfillment, 265 Assurance, and Billing and FCAPS(Fault, Configuration, Accounting, 266 Performance, Security) network management models and frameworks. 268 Therefore, NSF-Facing Interface corresponds to the SWA-4 interface. 270 2.4.3. Registration Interface 272 Registration Interface is used to register NSF from Developer's Mgmt 273 System to the security controller. An NSF's capabilities can either 274 be pre-configured or retrieved dynamically through the I2NSF 275 Registration Interface. 277 Above, this document mentioned that, the Developer's Mgmt System 278 handles the NSF life cycle and this interface corresponds to Ve-Vnfm 279 which is defined in the NFV reference architecture. Ve-Vnfm is 280 defined as IFA008 in ETSI document. IFA008 composed of two 281 interfaces. One is Ve-Vnfm-em, another is Ve-Vnfm-VNF. 283 If security controller is deployed as an EM, then the 284 registration interface corresponds to Ve-Vnfm-em. 286 3. I2NSF framework onto the NFV Reference Model(Alternative) 288 In this chapter, we describe an alternative I2NSF architecture in the 289 NFV environment. As shown in Fig.2, Devloper's Mgmt system 290 corresponds to EM and the security controller can be configured as an 291 independent VNF to perform security controller functions. According 292 to this architecture, all of the interfaces can be adapted directly 293 without additional changes. 295 +-------------------------------------------+ | ---------------- | 296 | OSS/BSS | | | NFV | | 297 +-+-----------------------------------------+ | | Orchestrator +-+ | 298 |(C) | +--+-----------+ | | 299 +-|-----------------------------------------+ | | | | 300 | |+-----------------------------------+ | | | | | 301 | || Devloper's Mgmt (EM) | | | | | | 302 | |+------------------+----------------+ | | +--+---------+ | | 303 | | | (a) | | | | | | | | 304 | |+---+------+ +---+----+ +---+----+ | | | VNFM | | | 305 | +- Security | |NSF(VNF)| |NSF(VNF)| | | | | | | 306 | |controller| | | | | | | +--+---------+ | | 307 | +---+------+ +---+----+ +---+----+ | | | | | 308 +------|-------(b)----|------------|--------+ | | | | 309 +------+--------------+------------+--------+ | | | | 310 | NFV Infrastructure (NFVI) | | | | | 311 | +---------+ +---------+ +---------+ | | | | | 312 | | Virtual | | Virtual | | Virtual | | | | | | 313 | | Compute | | Storage | | Network | | | | | | 314 | +---------+ +---------+ +---------+ | | +--+-----+ | | 315 | +---------------------------------------+ | | | | | | 316 | | Virtualization Layer | |--|-| VIM(s) +-------- | 317 | +---------------------------------------+ | | | | | 318 | +---------------------------------------+ | | +--------+ | 319 | | +---------+ +---------+ +---------+ | | | | 320 | | | Compute | | Storage | | Network | | | | | 321 | | | hardware| | hardware| | hardware| | | | | 322 | | +---------+ +---------+ +---------+ | | | | 323 | | Hardware resources | | | NFV Management | 324 | +---------------------------------------+ | | and Orchestration | 325 +-------------------------------------------+ +--------------------+ 326 (a)= Registration interface, (b)= NSF-facing interface 327 (C)= Consumer-facing interface 328 Figure 2. I2NSF architecture on NFV reference architecture 330 3.1. Security Controller 332 According to I2NSF framework, the security controller has a role to 333 translate policy according to user's request and delivers low level 334 policy to NSFs(manages NSF). 336 Logically the security controller function corresponds to the EM, 337 however, from a deployment scenario the security controller can be 338 configured as an independent VNF to perform security controller 339 functions. In addition, Security controller should be able to 340 communicate with NSFs to manage the NSF. 342 3.2. Developer's Mgmt System 343 As defined in I2NSF, the Developer's Mgmt system registers NSF which 344 can be provided by specific vendor i.e. it can create the VNF and 345 manage it. 347 In the NFV reference architecture, Developer's Mgmt system may 348 correspond to EM. When general VNFM creates and manages the NSF, 349 Devloper's Mgmt system can be used as an EM to manage the specific 350 function for NSF. 352 3.3. Interfaces 354 3.3.1. Consumer-Facing Interface 355 The Consumer-Facing Interface is an interface for communication 356 between the User and the Security Controller. It is used to enable 357 different users of a given I2NSF system to define, manage, and 358 monitor security policies for specific flows within an administrative 359 domain. 361 In the NFV reference architecture, OSS is Operational Support Systems 362 and BSS stands for Business Support Systems. OSS/BSS support the 363 system for users which relates to infra management such as billing, 364 order and metering. 366 Although an interface is not defined between User and VNF in the NFV 367 reference architecture, the Consumer-Facing interface can be deployed 368 between user and VNF as illustrated in Fig.2. 370 3.3.2. NSF-Facing Interface 372 The NSF-Facing Interface is an interface for communication between 373 Security Controller and NSF. It is used to specify and monitor flow- 374 based security policies enforced by one or more NSFs. 375 As shown in Fig.2, NSF-Facing Interface is an interface for 376 communication between Security Controller and NSF. In this model, we 377 configured security controller as a VNF. 379 Therefore, the through the NSF-Facing interface, VNFs should be able 380 to communicate with each other (i.e. security controller to other 381 NSF). 383 3.3.3. Registration Interface 384 Registration Interface is used to register NSF from Developer's Mgmt 385 System to the security controller. An NSF's capabilities can either 386 be pre-configured or retrieved dynamically through the I2NSF 387 Registration Interface. 389 In the NFV reference architecture, Software Architecture (SWA)-4 390 Interface is defined. The interface SWA-4 is used by the EM to 391 communicate with a VNF. This management interface is used for the 392 runtime management of the VNF according to the Fulfillment, 393 Assurance, and Billing and FCAPS(Fault, Configuration, Accounting, 394 Performance, Security) network management models and frameworks. 396 As shown in Fig.2, Registration interface corresponds to the SWA-4. 397 In this model, security controller is configured as a VNF and 398 Devloper's Mgmt system corresponds to the EM. Therefore, SWA-4 can be 399 mapped to both functions logically. 401 4. Multi-site Consideration 403 In the above section, we described how the I2NSF framework is adopted 404 to NFV architecture in single-site. From a perspective of NFV, when 405 security functions are deployed it might be deployed at a single site 406 or multiple sites. 408 Basically, I2NSF framework only considers that a single Developer's 409 Mgmt system(VNFM) could manage all the NSFs. 411 As a perspective of ETSI reference architecture, when NSFs are 412 deployed at multi-site environment, Developer's Mgmt system(VNFM) 413 could manage all of the NSFs through a single Developer's Mgmt 414 system. Alternatively, it could manage the NSF through multiple 415 Developer's Mgmt systems. 416 I2NSF framework only considers a single security controller managing 417 all the NSFs in a domain. This implies that one security 418 controller(EM) should be located at one domain. 420 However, as a perspective of ETSI reference architecture, EM usually 421 located at each site and controls VNF which belongs to that site. 423 The I2NSF framework should consider security controller placement in 424 a multi-site environment, since there is a conflict between the I2NSF 425 framework and the ETSI NFV reference architecture regarding the 426 placement of security controller(EM). 428 5. Use case - SFC Enabled I2NSF framework 430 In the I2NSF WG, some documents mentioned use cases for cloud based 431 security with forwarding mechanism. Especially SFC enabled I2NSF 432 document [nsf-triggered-steering] showed the use case which used SFC 433 as a forwarding mechanism. In addition, it defined additional 434 components and extended functionality of components. Therefore, in 435 the following section, we explain the details of each component and 436 consider how it corresponds to the NFV reference architecture. 438 5.1. SFC Policy Manager 440 SFC policy manager is a part of the security controller. It is 441 responsible for interpreting a high level policy into a low-level SFC 442 policy, which is given by I2NSF client. It also handles delivery of 443 the interpreted policy to classifiers for security function chaining. 444 Moreover, it also generates an SF forwarding table and distributes 445 the forwarding information to SFF(s). 447 In the NFV reference architecture, MANO performs similar functions as 448 the SFC policy manager. More specifically the NFV orchestrator (NFVO) 449 performs on-boarding of new Network Service (NS), VNF-FG(forwarding 450 graph) and VNF Packages. In addition, it manages NS lifecycle 451 (including instantiation, scale-out/in, performance measurements, 452 event correlation and termination). 454 Therefore, SFC policy manager corresponds to NFVO. In addition, if 455 SFC policy manager is a part of Security controller, this function 456 should be separated from security controller. 458 5.2. SFC Catalog Manager 460 SFC catalog manger is a part of the security controller. It is 461 responsible for maintaining the information of every available SF 462 instance such as IP address, supported transport protocol, service 463 name, and load status. Moreover, it should respond to the queries for 464 available SF instances from SFC Policy Manager so as to help to 465 generate a forwarding table entry relevant to a given SFP. It also 466 request Developer's Management System to dynamically instantiate 467 supplementary SF instances to avoid service congestion or the 468 elimination of an existing SF instance to avoid resource waste. 470 In the NFV reference architecture, SFC catalog manager corresponds to 471 Element management since information which is related to VNF 472 capability is managed by EM. Moreover, this function is similar to 473 security controller as we explained earlier. 475 5.3. Developer's Mgmt System 477 In the SFC enabled document, the function of Developer's Mgmt system 478 is extended. Following the request message from SFC catalog manager, 479 it creates additional SF instances and eliminates some of the SF 480 instances. 482 As mentioned above, if Developer's Mgmt system manages the NSF's 483 lifecycle, it corresponds to a specific VNF Manager. VNF life cycle 484 management includes instantiating, creating, provisioning, scaling, 485 monitoring, and termination of VMs in a VNF instance. Therefore, the 486 Developer's Mgmt system corresponds to a specific VNF Manager. 488 However, for scaling performed at a network service level, the role 489 of Developer's Mgmt system should extend to the MANOManage and 490 orchestrator). 492 SFC catalog manger is a part of the security controller. It is 493 responsible for maintaining the information of every available SF 494 instance such as IP address, supported transport protocol, service 495 name, and load status. Moreover, it should respond to the queries for 496 available SF instances from SFC Policy Manager so as to help to 497 generate a forwarding table entry relevant to a given SFP. It also 498 request Developer's Management System to dynamically instantiate 499 supplementary SF instances to avoid service congestion or the 500 elimination of an existing SF instance to avoid resource waste. 502 In the NFV reference architecture, SFC catalog manager corresponds to 503 Element management since information which is related to VNF 504 capability is managed by EM. Moreover, this function is similar to 505 security controller as we explained earlier. 507 6. Security Considerations 509 N/A 510 7. IANA Considerations 512 This document has no IANA actions. 514 8. References 516 8.1. Normative References 517 [i2nsf-framework] 519 Lopez, D., Lopez, E., Dunbar, L.,Strassner, J., and R. 520 Kumar, "Framework for Interface to Network Security 521 Functions",draft-ietf-i2nsf-framework-07 (work in progress) 522 ,August 2017. 523 [i2nsf-terminology] 525 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 526 Birkholz, "Interface to Network Security Functions (I2NSF) 527 Terminology",draft-ietf-i2nsf-terminology-04 (work in 528 progress), July 2017. 530 [etsi-gs-nfv-003] 531 ETSI NFV ISG, "Network Functions Virtualisation (NFV); 532 Terminology for Main Concepts in NFV", ETSI GS NFV 002 533 V1.1.1 NFV 002, October 2013, 534 537 8.2. Informative References 539 [i2NSF-applicability] 541 J. Jeong., S. Hyun., T. Ahn., S. Hares., D. Lopez.,' 542 Applicability of Interfaces to Network Security Functions 543 to Network-Based Security Services',draft-ietf-i2nsf- 544 applicability-00(work in progress),October, 2017. 546 [nsf-triggered-steering] 548 Hyun, S., Jeong, J., Park, J., and S.Hares, "Service 549 Function Chaining-Enabled I2NSF Architecture",draft-hyun- 550 i2nsf-nsf-triggered-steering-03(work in progress), July 551 2017. 553 Authors' Addresses 555 Hyunsik Yang 556 Soongsil University 557 369, Sangdo-ro, Dongjak-gu, 558 Seoul 156-743, Korea 559 Email: yangun@dcn.ssu.ac.kr 561 Younghan Kim 562 Soongsil University 563 369, Sangdo-ro, Dongjak-gu, 564 Seoul 156-743, Korea 565 Email: younghak@ssu.ac.kr