idnits 2.17.1 draft-yang-i2nsf-nfv-architecture-03.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 18) 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: ' 7. 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: ' 8. 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 (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 122 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: April 2019 October 22, 2018 6 I2NSF on the NFV Reference Architecture 7 draft-yang-i2nsf-nfv-architecture-03.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. Initial configuration procedure in NFV Architecture......... 11 88 5. Multi-site Consideration ................................... 13 89 6. Use case - SFC Enabled I2NSF framework .................... 14 90 6.1. SFC Policy Manager .................................... 14 91 6.2. SFC Catalog Manager ................................... 14 92 6.3. Developer's Mgmt System ............................... 15 93 7. Security Considerations .................................... 15 94 8. IANA Considerations ........................................ 16 95 9. References ................................................. 16 96 9.1. Normative References .................................. 16 97 9.2. Informative References ................................ 16 99 1. Introduction 101 The goal of I2NSF is to define a set of software interfaces and 102 components for controlling and monitoring aspects of physical and 103 virtual NSFs, enabling clients to specify rules set. To enable I2NSF 104 environment, I2NSF framework not only considers physical 105 infrastructure but also considers the NFV environment since NSF may 106 be provided by virtualized infrastructure as a vnfs. Especially, 107 I2NSF applicability document [i2NSF-applicability] describes the 108 applicability of interface to Network Security Functions(I2NSF) to 109 network-based security services in NFV environment. Although it 110 explains how I2NSF provides security service in NFV environment, it 111 doesn't consider how I2NSF framework adopted onto the NFV reference 112 architecture. 114 Therefore, we explain the I2NSF framework adopted to NFV reference 115 architecture with each corresponding component. 117 1.1. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC-2119 [RFC2119]. 123 This document uses the terminology described in [i2nsf- 124 framework],[i2nsf-terminology], [i2nsf-applicability], [etsi-gs-nfv- 125 003] and [nsf-triggered-steering]. 127 2. I2NSF framework onto the NFV Reference Model 129 The European Telecommunications Standards Institute (ETSI) defined 130 the components for the basic NFV architecture including the NFV 131 Infrastructure (NFVI), VNF Manager (VNFM), Virtualization 132 Infrastructure Manager (VIM), and NFV Orchestrator (NFVO). [etsi-gs- 133 nfv-003] NFVI provides the virtual resources, such as VM and virtual 134 network, used to create, update, and delete VNFs running 135 applications. VNFs are implemented through software virtualization 136 techniques running over the NFVI. 138 Virtualized Infrastructure Manager (VIM) has a function for 139 controlling and managing the NFVI compute, storage and network 140 resources, within one operator's infrastructure sub-domain. It also 141 collects and forwards performance measurements and events. 143 VNFM manages the VNF lifecycle. When a VNF is created, the VNFM 144 manages the VNF instance in the lifecycle, and the VNFM performs 145 several actions such as software update/modification, monitoring data 146 collection - a fault event in the VNF, and instance termination. 147 According to definition of ETSI, the VNFM is divided into Generic 148 VNFM and Specific VNFM. When the VNFs have their specific methods for 149 provisioning and lifecycle management, a specific VNFM required. 151 In the I2NSF framework [i2nsf-framework], they defined several 152 components such as NSF, Security controller and Developer's Mgmt 153 System. To adopt these components to the NFV reference architecture, 154 each component should be classified based on functionality. According 155 to component functionality, it would correspond to NFV reference 156 architecture components as Figure 1. 158 +-------------------------------------------+ | +--------------+ | 159 | OSS/BSS | | | NFV | | 160 +-------------------------------------------+ | | Orchestrator +-+ | 161 Consumer facing interface | +--+-----------+ | | 162 +-------------------------------------------+ | | | | 163 | +-----------------------------------+ | | | | | 164 | | Security Controller(EM) | | | | | | 165 | +-----------------+-----------------+ | | +--+---------+ | | 166 | | NSF-facing interface | |(a)-| Devloper's | | | 167 | +---+----+ +---+----+ +---+----+ | | | Mgmt(VNFM) | | | 168 | |NSF(VNF)| |NSF(VNF)| |NSF(VNF)| | | +--+---------+ | | 169 | +---+----+ +---+----+ +---+----+ | | | | | 170 +------|-------------|-------------|--------+ | | | | 171 | | | | | | | 172 +------+-------------+-------------+--------+ | | | | 173 | NFV Infrastructure (NFVI) | | | | | 174 | +---------+ +---------+ +---------+ | | | | | 175 | | Virtual | | Virtual | | Virtual | | | | | | 176 | | Compute | | Storage | | Network | | | | | | 177 | +---------+ +---------+ +---------+ | | +--+-----+ | | 178 | +---------------------------------------+ | | | | | | 179 | | Virtualization Layer | |--|-| VIM(s) +-------- | 180 | +---------------------------------------+ | | | | | 181 | +---------------------------------------+ | | +--------+ | 182 | | +---------+ +---------+ +---------+ | | | | 183 | | | Compute | | Storage | | Network | | | | | 184 | | | hardware| | hardware| | hardware| | | | | 185 | | +---------+ +---------+ +---------+ | | | | 186 | | Hardware resources | | | NFV Management | 187 | +---------------------------------------+ | | and Orchestration | 188 +-------------------------------------------+ +--------------------+ 189 (a)= Registration interface 191 Figure 1. I2NSF architecture on NFV reference architecture 193 2.1. NSF 195 Network Security Function is one of the security service functions. 197 In the ETSI reference architecture, VNF(Virtual Network Function)is 198 the network functions which provide specific service. 200 Therefore, NSF corresponds to the VNF in NFV reference architecture. 202 2.2. Security Controller 204 According to I2NSF framework, the security controller has a role 205 which translate policy according to user's request and delivers low 206 level policy to NSFs(manages NSF). It also collects NSF capability 207 from developer's Mgmt System. Based on this information, the security 208 controller forwards policy to NSF. 210 In the NFV reference architecture, EM has a role that it may be aware 211 of virtualization and collaborate with the VNF Manager to perform 212 those functions that require exchanges of information regarding the 213 NFVI Resources associated with the VNF. EM performs typical 214 management functionality for one or several VNFs. 216 Therefore, the Security controller corresponds to Element management 217 since it should provide the function which controls NSF and policy. 218 In the case of a distributed security controller model, an interface 219 which is used to communicate between controllers should also be 220 considered. 222 2.3. Developer's Mgmt System 224 According to the definition of I2NSF Registration Interface, 225 Developer's Mgmt system registers NSF which can be provided by 226 specific vendor. Developer's Mgmt system also can be one of the 227 vendors too. 229 In the NFV reference architecture, VNFM manages the VNF lifecycle. It 230 also performs several actions such as software update, monitoring and 231 fault management. Generally, generic VNFM means that only one VNFM 232 handle all of the VNF in the NFV environment. However, if additional 233 VNFMs are required for management of specific VNFs, additional VFNMs 234 can be defined as specific VNFMs. 236 Therefore, if Developer's Mgmt System manages the NSF lifecycle, it 237 can logically correspond to a specific VNFM. 239 2.4. Interfaces 241 2.4.1. Consumer-Facing Interface 243 The Consumer-Facing Interface is an interface for communication 244 between the User and the Security Controller. It is used to enable 245 different users of a given I2NSF system to define, manage, and 246 monitor security policies for specific flows within an administrative 247 domain. 249 In the NFV reference architecture, OSS is Operational Support Systems 250 and BSS stands for Business Support Systems. OSS/BSS support the 251 system for users which relates to infra management such as billing, 252 order and metering. 253 Although an interface is not defined between User and EM in the NFV 254 reference architecture, Consumer-Facing interface can be deployed 255 between user and EM. 257 2.4.2. NSF-Facing Interface 259 The NSF-Facing Interface is an interface for communication between 260 Security Controller and NSF. It is used to specify and monitor flow- 261 based security policies enforced by one or more NSFs. 263 In the NFV reference architecture, Software Architecture (SWA)-4 264 Interface is defined. The interface SWA-4 is used by the EM to 265 communicate with a VNF. This management interface is used for the 266 runtime management of the VNF according to the Fulfillment, 267 Assurance, and Billing and FCAPS(Fault, Configuration, Accounting, 268 Performance, Security) network management models and frameworks. 270 Therefore, NSF-Facing Interface corresponds to the SWA-4 interface. 272 2.4.3. Registration Interface 274 Registration Interface is used to register NSF from Developer's Mgmt 275 System to the security controller. An NSF's capabilities can either 276 be pre-configured or retrieved dynamically through the I2NSF 277 Registration Interface. 279 Above, this document mentioned that, the Developer's Mgmt System 280 handles the NSF life cycle and this interface corresponds to Ve-Vnfm 281 which is defined in the NFV reference architecture. Ve-Vnfm is 282 defined as IFA008 in ETSI document. IFA008 composed of two 283 interfaces. One is Ve-Vnfm-em, another is Ve-Vnfm-VNF. 285 If security controller is deployed as an EM, then the 286 registration interface corresponds to Ve-Vnfm-em. 288 3. I2NSF framework onto the NFV Reference Model(Alternative) 290 In this chapter, we describe an alternative I2NSF architecture in the 291 NFV environment. As shown in Fig.2, Devloper's Mgmt system 292 corresponds to EM and the security controller can be configured as an 293 independent VNF to perform security controller functions. According 294 to this architecture, all of the interfaces can be adapted directly 295 without additional changes. 297 +-------------------------------------------+ | ---------------- | 298 | OSS/BSS | | | NFV | | 299 +-+-----------------------------------------+ | | Orchestrator +-+ | 300 |(C) | +--+-----------+ | | 301 +-|-----------------------------------------+ | | | | 302 | |+-----------------------------------+ | | | | | 303 | || Devloper's Mgmt (EM) | | | | | | 304 | |+------------------+----------------+ | | +--+---------+ | | 305 | | | (a) | | | | | | | | 306 | |+---+------+ +---+----+ +---+----+ | | | VNFM | | | 307 | +- Security | |NSF(VNF)| |NSF(VNF)| | | | | | | 308 | |controller| | | | | | | +--+---------+ | | 309 | +---+------+ +---+----+ +---+----+ | | | | | 310 +------|-------(b)----|------------|--------+ | | | | 311 +------+--------------+------------+--------+ | | | | 312 | NFV Infrastructure (NFVI) | | | | | 313 | +---------+ +---------+ +---------+ | | | | | 314 | | Virtual | | Virtual | | Virtual | | | | | | 315 | | Compute | | Storage | | Network | | | | | | 316 | +---------+ +---------+ +---------+ | | +--+-----+ | | 317 | +---------------------------------------+ | | | | | | 318 | | Virtualization Layer | |--|-| VIM(s) +-------- | 319 | +---------------------------------------+ | | | | | 320 | +---------------------------------------+ | | +--------+ | 321 | | +---------+ +---------+ +---------+ | | | | 322 | | | Compute | | Storage | | Network | | | | | 323 | | | hardware| | hardware| | hardware| | | | | 324 | | +---------+ +---------+ +---------+ | | | | 325 | | Hardware resources | | | NFV Management | 326 | +---------------------------------------+ | | and Orchestration | 327 +-------------------------------------------+ +--------------------+ 328 (a)= Registration interface, (b)= NSF-facing interface 329 (C)= Consumer-facing interface 330 Figure 2. I2NSF architecture on NFV reference architecture 332 3.1. Security Controller 334 According to I2NSF framework, the security controller has a role to 335 translate policy according to user's request and delivers low level 336 policy to NSFs(manages NSF). 338 Logically the security controller function corresponds to the EM, 339 however, from a deployment scenario the security controller can be 340 configured as an independent VNF to perform security controller 341 functions. In addition, Security controller should be able to 342 communicate with NSFs to manage the NSF. 344 3.2. Developer's Mgmt System 346 As defined in I2NSF, the Developer's Mgmt system registers NSF which 347 can be provided by specific vendor i.e. it can create the VNF and 348 manage it. 350 In the NFV reference architecture, Developer's Mgmt system may 351 correspond to EM. When general VNFM creates and manages the NSF, 352 Devloper's Mgmt system can be used as an EM to manage the specific 353 function for NSF. 355 3.3. Interfaces 357 3.3.1. Consumer-Facing Interface 359 The Consumer-Facing Interface is an interface for communication 360 between the User and the Security Controller. It is used to enable 361 different users of a given I2NSF system to define, manage, and 362 monitor security policies for specific flows within an administrative 363 domain. 365 In the NFV reference architecture, OSS is Operational Support Systems 366 and BSS stands for Business Support Systems. OSS/BSS support the 367 system for users which relates to infra management such as billing, 368 order and metering. 370 Although an interface is not defined between User and VNF in the NFV 371 reference architecture, the Consumer-Facing interface can be deployed 372 between user and VNF as illustrated in Fig.2. 374 3.3.2. NSF-Facing Interface 376 The NSF-Facing Interface is an interface for communication between 377 Security Controller and NSF. It is used to specify and monitor flow- 378 based security policies enforced by one or more NSFs. 379 As shown in Fig.2, NSF-Facing Interface is an interface for 380 communication between Security Controller and NSF. In this model, we 381 configured security controller as a VNF. 383 Therefore, the through the NSF-Facing interface, VNFs should be able 384 to communicate with each other (i.e. security controller to other 385 NSF). 387 3.3.3. Registration Interface 389 Registration Interface is used to register NSF from Developer's Mgmt 390 System to the security controller. An NSF's capabilities can either 391 be pre-configured or retrieved dynamically through the I2NSF 392 Registration Interface. 394 In the NFV reference architecture, Software Architecture (SWA)-4 395 Interface is defined. The interface SWA-4 is used by the EM to 396 communicate with a VNF. This management interface is used for the 397 runtime management of the VNF according to the Fulfillment, 398 Assurance, and Billing and FCAPS(Fault, Configuration, Accounting, 399 Performance, Security) network management models and frameworks. 401 As shown in Fig.2, Registration interface corresponds to the SWA-4. 402 In this model, security controller is configured as a VNF and 403 Devloper's Mgmt system corresponds to the EM. Therefore, SWA-4 can be 404 mapped to both functions logically. 406 4. Initial configuration procedure in NFV Architecture 408 This procedure is the initiation procedure of I2NSF in NFV 409 architecture. In the proposed architecture, the procedure is as 410 follows: When one vender wants to provide a security service, the 411 vender registers information which is related to a service such as 412 kinds of service functions and specification of service functions 413 to the Devloper's Mgmt system. The Devloper's Mgmt system forwards 414 it to the VNFM to provide image and Network service specifications. 415 It also registers same information to the Security Controller via 416 registration interface. 418 USER Security Devloper's VNFM NSF 419 controller Mgmt system 420 CASE 1 | | | | 421 |-NSF Creation->| | | | 422 | Request | | | | 423 | | | | | 424 | Check the NSF List | | | 425 | (NSF exist) | | | 426 | |-------NSF initial setting Request--------->| 427 | |<------NSF initial setting Response---------| 428 | | | | | 429 |<-NSF Creation-| | | | 430 | Response | | | | 431 | | | | | 432 CASE 2 | | | | 433 |-NSF Creation->| | | | 434 | Request | | | | 435 | | | | | 436 | Check the NSF List | | | 437 | (NSF doesn't exist) | | | 438 | | | | | 439 | |--NSF Creation-->| | | 440 | | Request | | | 441 | | Translation | | 442 | | |--NSF Creation->| | 443 | | | | NSF | 444 | | | |Creation | 445 | | |<-NSF Creation--| | 446 | | | Response | | 447 | | | | | 448 | | |----NSF ip----->| | 449 | | | Request | | 450 | | | | | 451 | | |<----NSF ip-----| | 452 | | | Response | | 453 | |<--NSF Creation--| | | 454 | | Response with IP| | | 455 | | | | | 456 | |-------NSF initial setting Request--------->| 457 | |<------NSF initial setting Response---------| 458 | | | | | 459 |<-NSF Creation-| | | | 460 | Response | | | | 462 Figure 3. Procedure of I2NSF architecture on NFV 464 When a user requests security service, the security controller checks 465 the NSF list in the controller. If NSF already exists in the same 466 domain, the security controller sends an initial setup request 467 message to the NSF directly. Upon receipt of a response message from 468 the NSF, the security controller then proceeds to forward an initial 469 setup response message to the user. 471 On the other hand, when a user requests for a security service, and 472 the NSF doesn't exist in the NSF list, the security controller sends 473 an NSF creation request message to Developer's Mgmt system. 474 The Developer's Mgmt system subsequently translates this message and 475 requests NSF creation from the VNFM. After NSF creation, 476 the Developer's Mgmt system requests for the ip address of the newly 477 created NSF for management purposes. The Developer's Mgmt system 478 then reports NSF creation to the security controller with the 479 accompanying ip address. The security controller will update the NSF 480 information and consequently process the request from the user. 482 5. Multi-site Consideration 484 In the above section, we described how the I2NSF framework is adopted 485 to NFV architecture in single-site. From a perspective of NFV, when 486 security functions are deployed it might be deployed at a single site 487 or multiple sites. 489 Basically, I2NSF framework only considers that a single Developer's 490 Mgmt system(VNFM) could manage all the NSFs. 491 As a perspective of ETSI reference architecture, when NSFs are 492 deployed at multi-site environment, Developer's Mgmt system(VNFM) 493 could manage all of the NSFs through a single Developer's Mgmt 494 system. Alternatively, it could manage the NSF through multiple 495 Developer's Mgmt systems. I2NSF framework only considers a single 496 security controller managing all the NSFs in a domain. This implies 497 that one security controller(EM) should be located at one domain. 499 However, as a perspective of ETSI reference architecture, EM usually 500 located at each site and controls VNF which belongs to that site. 501 The I2NSF framework should consider security controller placement in 502 a multi-site environment, since there is a conflict between the I2NSF 503 framework and the ETSI NFV reference architecture regarding the 504 placement of security controller(EM). 506 6. Use case - SFC Enabled I2NSF framework 508 In the I2NSF WG, some documents mentioned use cases for cloud based 509 security with forwarding mechanism. Especially SFC enabled I2NSF 510 document [nsf-triggered-steering] showed the use case which used SFC 511 as a forwarding mechanism. In addition, it defined additional 512 components and extended functionality of components. Therefore, in 513 the following section, we explain the details of each component and 514 consider how it corresponds to the NFV reference architecture. 516 6.1. SFC Policy Manager 518 SFC policy manager is a part of the security controller. It is 519 responsible for interpreting a high level policy into a low-level SFC 520 policy, which is given by I2NSF client. It also handles delivery of 521 the interpreted policy to classifiers for security function chaining. 522 Moreover, it also generates an SF forwarding table and distributes 523 the forwarding information to SFF(s). 525 In the NFV reference architecture, MANO performs similar functions as 526 the SFC policy manager. More specifically the NFV orchestrator (NFVO) 527 performs on-boarding of new Network Service (NS), VNF-FG(forwarding 528 graph) and VNF Packages. In addition, it manages NS lifecycle 529 (including instantiation, scale-out/in, performance measurements, 530 event correlation and termination). 532 Therefore, SFC policy manager corresponds to NFVO. In addition, if 533 SFC policy manager is a part of Security controller, this function 534 should be separated from security controller. 536 6.2. SFC Catalog Manager 538 SFC catalog manger is a part of the security controller. It is 539 responsible for maintaining the information of every available SF 540 instance such as IP address, supported transport protocol, service 541 name, and load status. Moreover, it should respond to the queries for 542 available SF instances from SFC Policy Manager so as to help to 543 generate a forwarding table entry relevant to a given SFP. It also 544 request Developer's Management System to dynamically instantiate 545 supplementary SF instances to avoid service congestion or the 546 elimination of an existing SF instance to avoid resource waste. 548 In the NFV reference architecture, SFC catalog manager corresponds to 549 Element management since information which is related to VNF 550 capability is managed by EM. Moreover, this function is similar to 551 security controller as we explained earlier. 553 6.3. Developer's Mgmt System 555 In the SFC enabled document, the function of Developer's Mgmt system 556 is extended. Following the request message from SFC catalog manager, 557 it creates additional SF instances and eliminates some of the SF 558 instances. 560 As mentioned above, if Developer's Mgmt system manages the NSF's 561 lifecycle, it corresponds to a specific VNF Manager. VNF life cycle 562 management includes instantiating, creating, provisioning, scaling, 563 monitoring, and termination of VMs in a VNF instance. Therefore, the 564 Developer's Mgmt system corresponds to a specific VNF Manager. 566 However, for scaling performed at a network service level, the role 567 of Developer's Mgmt system should extend to the MANOManage and 568 orchestrator). 570 SFC catalog manger is a part of the security controller. It is 571 responsible for maintaining the information of every available SF 572 instance such as IP address, supported transport protocol, service 573 name, and load status. Moreover, it should respond to the queries for 574 available SF instances from SFC Policy Manager so as to help to 575 generate a forwarding table entry relevant to a given SFP. It also 576 request Developer's Management System to dynamically instantiate 577 supplementary SF instances to avoid service congestion or the 578 elimination of an existing SF instance to avoid resource waste. 580 In the NFV reference architecture, SFC catalog manager corresponds to 581 Element management since information which is related to VNF 582 capability is managed by EM. Moreover, this function is similar to 583 security controller as we explained earlier. 585 7. Security Considerations 587 N/A 589 8. IANA Considerations 591 This document has no IANA actions. 593 9. References 595 9.1. Normative References 597 [i2nsf-framework] 598 Lopez, D., Lopez, E., Dunbar, L.,Strassner, J., and R. 599 Kumar, "Framework for Interface to Network Security 600 Functions",draft-ietf-i2nsf-framework-07 (work in progress) 601 ,August 2017. 603 [i2nsf-terminology] 604 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 605 Birkholz, "Interface to Network Security Functions (I2NSF) 606 Terminology",draft-ietf-i2nsf-terminology-04 (work in 607 progress), July 2017. 609 [etsi-gs-nfv-003] 610 ETSI NFV ISG, "Network Functions Virtualisation (NFV); 611 Terminology for Main Concepts in NFV", ETSI GS NFV 002 612 V1.1.1 NFV 002, October 2013, 613 616 9.2. Informative References 618 [i2NSF-applicability] 620 J. Jeong., S. Hyun., T. Ahn., S. Hares., D. Lopez.,' 621 Applicability of Interfaces to Network Security Functions 622 to Network-Based Security Services',draft-ietf-i2nsf- 623 applicability-00(work in progress),October, 2017. 625 [nsf-triggered-steering] 627 Hyun, S., Jeong, J., Park, J., and S.Hares, "Service 628 Function Chaining-Enabled I2NSF Architecture",draft-hyun- 629 i2nsf-nsf-triggered-steering-03(work in progress), July 630 2017. 632 Authors' Addresses 634 Hyunsik Yang 635 Soongsil University 636 369, Sangdo-ro, Dongjak-gu, 637 Seoul 156-743, Korea 638 Email: yangun@dcn.ssu.ac.kr 640 Younghan Kim 641 Soongsil University 642 369, Sangdo-ro, Dongjak-gu, 643 Seoul 156-743, Korea 644 Email: younghak@ssu.ac.kr