idnits 2.17.1 draft-lee-nfvrg-resource-management-service-chain-00.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 : ---------------------------------------------------------------------------- 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 date (October 23, 2014) is 3466 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 323, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-aldrin-sfc-oam-framework-00 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-02 == Outdated reference: A later version (-01) exists of draft-lee-sfc-dynamic-instantiation-00 == Outdated reference: A later version (-02) exists of draft-meng-sfc-chain-redundancy-00 == Outdated reference: A later version (-03) exists of draft-morton-bmwg-virtual-net-01 == Outdated reference: A later version (-06) exists of draft-ww-sfc-control-plane-03 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force (IRTF) S. Lee 3 Internet-Draft ETRI 4 Intended status: Informational S. Pack 5 Expires: April 26, 2015 KU 6 M-K. Shin 7 ETRI 8 E. Paik 9 KT 10 October 23, 2014 12 Resource Management for Dynamic Service Chain Adaptation 13 draft-lee-nfvrg-resource-management-service-chain-00 15 Abstract 17 This document specifies problem definition and use cases of dynamic 18 service chain adaptation for traffic optimization, failover, load 19 balancing, etc. It further describes design considerations and 20 relevant framework for the resource management capability that 21 dynamically creates and updates network forwarding paths (NFPs) 22 considering resource state of VNF instances. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 26, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Dynamic service chain adaptation . . . . . . . . . . . . . . 4 61 3.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Design considerations . . . . . . . . . . . . . . . . . . 6 63 3.3. Framework . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Related works in IETF SFC WG . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Network Functions Virtualisation (NFV) [ETSI-NFV-WHITE] offers a new 75 way to design, deploy and manage network services. The network 76 service can be composed of one or more network functions and NFV 77 relocates the network functions from dedicated hardware appliances to 78 generic servers, so they can run in software. Using these 79 virtualized network functions (VNFs), the network service can be 80 described by a service chain (or VNF forwarding graph; VNF-FG) which 81 defines an ordered sequence of VNFs for the composed service. The 82 VNF-FG can be instantiated by creating or selecting VNF instances and 83 virtual links (VLs) among them, which results in a network forwarding 84 path (NFP). 86 The performance or state of the NFP depends on the ones of VNF 87 instances and underlying NFVI resources. For example, if one of the 88 VNF instances in a NFP gets failed, the whole network service using 89 the NFP also gets failed. Thus, the VNF instances per NFP need to be 90 carefully selected at VNF-FG instantiation or dynamically replaced by 91 other VNF instances at run-time for better performance and 92 resilience. 94 This document specifies problem definition and use cases for dynamic 95 service chain adaptation for traffic optimization, failover, load 96 balancing, etc. It further describes design considerations and 97 relevant framework for the resource management capability that 98 dynamically creates and updates NFPs considering resource state of 99 VNF instances. 101 This document mainly focuses on the resource capability in the ETSI 102 NFV framework [ETSI-NFV-ARCH] but also studies its applicability to 103 the control plane of SFC architecture [I-D.ietf-sfc-architecture]. 105 2. Terminology 107 This document uses the following terms and most of them were 108 reproduced from [ETSI-NFV-TERM]. 110 o Network Functions (NF): A functional building block within a 111 network infrastructure, which has well-defined external interfaces 112 and a well-defined functional behavior. 114 o Network service: A composition of network functions and defined by 115 its functional and behavioural specification. 117 o NFV Framework: The totality of all entities, reference points, 118 information models and other constructs defined by the 119 specifications published by the ETSI ISG NFV. 121 o Virtualised Network Function (VNF): An implementation of an NF 122 that can be deployed on a Network Function Virtualisation 123 Infrastructure (NFVI). 125 o NFV Infrastructure (NFVI): The NFV-Infrastructure is the totality 126 of all hardware and software components which build up the 127 environment in which VNFs are deployed. 129 o NF Forwarding Graph: A graph of logical links connecting NF nodes 130 for the purpose of describing traffic flow between these network 131 functions. 133 o VNF Forwarding Graph (VNF-FG): A NF forwarding graph where at 134 least one node is a VNF. 136 o Virtual Link: A set of connection points along with the 137 connectivity relationship between them and any associated target 138 performance metrics (e.g. bandwidth, latency, QoS). The Virtual 139 Link can interconnect two or more entities (VNF components, VNFs, 140 or PNFs). 142 o Scaling: Ability to dynamically extend/reduce resources granted to 143 the Virtual Network Function (VNF) as needed. 145 3. Dynamic service chain adaptation 147 The goal of dynamic service chain adaptation is to optimize the 148 performance of network services. To meet this goal, NFPs of the 149 network services need to consider the state of NFV resources (such as 150 VNF instances or virtual links) at construction. The NFPs also need 151 to dynamically adapt to the changes of the resource state at run- 152 time, such as availability, load, and topological locations of VNF 153 instances. The adaptation of NFPs can be executed by monitoring the 154 resource state of VNF instances and VLs and replacing the original 155 VNF instances of the NFP with new VNF instances that constitute a NFP 156 with better performance. This functionality can be a part of 157 Orchestrator functional building block in the NFV framework 158 [ETSI-NFV-MANO] but it needs further study. 160 3.1. Use cases 162 There are several use cases of dynamic service chain adaptation: 163 fail-over, end-to-end service optimization, traffic optimization, 164 load balancing, energy efficiency, and so on. 166 Fail-over 168 When one of VNF instances in a NFP gets failed to run due to failure 169 of its VM or underlying network, the whole chain of network service 170 also gets failed. For service continuity, the failure of VNF 171 instance needs to be detected and the failed one needs to be replaced 172 with the other one which is available to use. Figure 1 presents an 173 example of the fail-over use case. A network service is defined as a 174 chain of VNF-A and VNF-B; and the service chain is instantiated with 175 VNF-A1 and VNF-B1 which are instances of VNF-A and VNF-B 176 respectively. In the meantime, failure of VNF-B1 is detected so that 177 VNF-B2 replaces the failed one for fail-over of the NFP. 179 +--------+ +--------+ 180 | VNF-B2 | #| VNF-B2 |### 181 +--------+ +--------+ +--------+ # +--------+ 182 ###| VNF-A1 | _|_ ###| VNF-A1 |# _|_ 183 +--------+ (___) +--------+ (___) 184 ___/ # / \ \ ___/ / \ 185 (___)+---#------+ + ===} (___)+----------+ + 186 # \ ___ / / \ ___ / 187 # (___) (___) 188 # | | 189 # +--------+ +--------+ 190 ######| VNF-B1 |### (failure)--> | VNF-B1 | 191 +--------+ +--------+ 193 ### NFP 195 Figure 1: A fail-over use case 197 End-to-end service optimization 199 Traffic for a network service traverses all of the VNF instances 200 given by a NFP before reaching a target end point. Thus, stretch of 201 the traffic route along a NFP may vary according to topological 202 locations of VNF instances and such stretch needs to be kept low to 203 make topological distance of two end points of the network service 204 short. This stretch can be managed by constructing or adapting the 205 NFP considering topological locations of the VNF instances. 207 Traffic optimization 209 A network operator may provide multiple network services with 210 different VNF-FGs and different flows of traffic traverse between 211 source and destination end-points along the VNF-FGs. For efficiency 212 of network management resource usage, the NFPs need to be built as to 213 localize the traffic flows or as to avoid bottleneck links shared by 214 multiple traffic flows. In this case, multiple NFV instances of 215 different NFPs need to be considered together at constructing a new 216 NFP or adapting one. 218 Load balancing 220 A single VNF instances may be shared by multiple traffic flows of the 221 same of different network services. In order to avoid bottleneck 222 points due to overloaded NFV instances, NFPs need to be constructed 223 or maintained to distribute workloads of the shared VNF instances. 225 Energy efficiency 226 Energy efficiency in the network is getting important to reduce 227 impact on the environment so that energy consumption of VNF instances 228 using VNFI resources (e.g., compute, storage, I/O) needs to be 229 considered at NFP construction or adaptation. For example, a NFP can 230 be constructed as to make traffic flows aggregated into a limited 231 number of VNF instances as much as its performance is preserved in a 232 certain level. 234 3.2. Design considerations 236 To support the aforementioned use cases, it is required to support 237 resource management capability which provides service chain (or NFP) 238 construction and adaptation by considering resource state or 239 attributes of VNF instances and virtual links among them. The 240 resource management operations for service chain construction and 241 adaptation can be divided into several sub-actions: 243 o Select a VNF instance 245 o Evaluate a VNF instance and a virtual link 247 o Replace a VNF instance to update a NFP 249 o Monitor attributes of a VNF instance and a virtual link 251 o Migrate a VNF instance to a different topological location 253 Note: While scaling-in/out or -up/down of VNF instances is an 254 essential action for NFV resource management, sub-actions with 255 scaling for service chain adaptation are still under study. 257 As listed above, VNF instances are selected or replaced according to 258 monitoring or evaluation results of performance metrics of the VNF 259 instances and virtual links. Studies about evaluation methodologies 260 and performance metrics for VNF instances and NFVI resources can be 261 found at [ETSI-NFV-PER001] [I-D.liu-bmwg-virtual-network-benchmark] 262 [I-D.morton-bmwg-virtual-net]. The performance metrics of VNF 263 instances and virtual links specific to service chain construction 264 and adaptation can be defined as follows: 266 o availability (or failure) of a VNF instance and a virtual link 268 o a topological location of a VNF instance 270 o a utilization rate of a VNF instance 272 o a throughput of a VNF instance 273 o energy consumption of VNF instance 275 o bandwidth of a virtual link 277 o latency of a virtual link 279 3.3. Framework 281 The resource management functionality for dynamic service chain 282 adaptation takes role of NFV orchestration with support of VNF 283 manager and Virtualised Infrastructure Manager (VIM) in the NFV 284 framework [ETSI-NFV-ARCH]. Detailed functional building block and 285 interfaces are still under study. 287 4. Related works in IETF SFC WG 289 IETF SFC WG provides a new service deployment model that delivers the 290 traffic along the predefined logical paths of service functions 291 (SFs), called service function chains (SFCs) with no regard of 292 network topologies or transport mechanisms. Basic concept of the 293 service function chaining is similar to VNF-FG where a network 294 service is composed of SFs and deployed by making traffic flows 295 traversed instances of the SFs in a pre-defined order. 297 There are several works in progress in IETF SFC WG for resource 298 management of service chaining. [I-D.ietf-sfc-architecture] defines 299 SFC control plane that selects specific SFs for a requested SFC, 300 either statically or dynamically but details are currently outside 301 the scope of the document. There are other works 302 [I-D.ww-sfc-control-plane] [I-D.lee-sfc-dynamic-instantiation] 303 [I-D.krishnan-sfc-oam-req-framework] [I-D.aldrin-sfc-oam-framework] 304 which define the control plane functionality for service function 305 chain construction and adaptation but details are still under study. 306 While [I-D.dunbar-sfc-fun-instances-restoration] and 307 [I-D.meng-sfc-chain-redundancy] provide detailed mechanisms of 308 service chain adaptation, they focus only on resilience or fail-over 309 of service function chains. 311 5. Security Considerations 313 TBD. 315 6. IANA Considerations 317 TBD. 319 7. References 321 7.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 7.2. Informative References 328 [ETSI-NFV-ARCH] 329 ETSI, "ETSI NFV Architectural Framework v1.1.1", October 330 2013. 332 [ETSI-NFV-MANO] 333 ETSI, "Network Function Virtualization (NFV) Management 334 and Orchestration V0.6.3", October 2014. 336 [ETSI-NFV-PER001] 337 ETSI, "Network Function Virtualization: Performance and 338 Portability Best Practices v1.1.1", June 2014. 340 [ETSI-NFV-TERM] 341 ETSI, "NFV Terminology for Main Concepts in NFV", October 342 2013. 344 [ETSI-NFV-WHITE] 345 ETSI, "NFV Whitepaper 2", October 2013. 347 [I-D.aldrin-sfc-oam-framework] 348 Aldrin, S., Pignataro, C., and N. Akiya, "Service Function 349 Chaining Operations, Administration and Maintenance 350 Framework", draft-aldrin-sfc-oam-framework-00 (work in 351 progress), July 2014. 353 [I-D.dunbar-sfc-fun-instances-restoration] 354 Dunbar, L. and A. Malis, "Framework for Service Function 355 Instances Restoration", draft-dunbar-sfc-fun-instances- 356 restoration-00 (work in progress), April 2014. 358 [I-D.ietf-sfc-architecture] 359 Halpern, J. and C. Pignataro, "Service Function Chaining 360 (SFC) Architecture", draft-ietf-sfc-architecture-02 (work 361 in progress), September 2014. 363 [I-D.krishnan-sfc-oam-req-framework] 364 ramki, r., Ghanwani, A., Gutierrez, P., Lopez, D., 365 Halpern, J., Kini, S., and A. Reid, "SFC OAM Requirements 366 and Framework", draft-krishnan-sfc-oam-req-framework-00 367 (work in progress), July 2014. 369 [I-D.lee-sfc-dynamic-instantiation] 370 Lee, S. and M. Shin, "SFC dynamic instantiation", draft- 371 lee-sfc-dynamic-instantiation-00 (work in progress), July 372 2014. 374 [I-D.liu-bmwg-virtual-network-benchmark] 375 Liu, V., Liu, D., Mandeville, B., Hickman, B., and G. 376 Zhang, "Benchmarking Methodology for Virtualization 377 Network Performance", draft-liu-bmwg-virtual-network- 378 benchmark-00 (work in progress), July 2014. 380 [I-D.meng-sfc-chain-redundancy] 381 Meng, W. and C. Wang, "Redundancy Mechanism for Service 382 Function Chains", draft-meng-sfc-chain-redundancy-00 (work 383 in progress), July 2014. 385 [I-D.morton-bmwg-virtual-net] 386 Morton, A., "Considerations for Benchmarking Virtual 387 Network Functions and Their Infrastructure", draft-morton- 388 bmwg-virtual-net-01 (work in progress), July 2014. 390 [I-D.ww-sfc-control-plane] 391 Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W. 392 Haeffner, "Service Function Chaining (SFC) Control Plane 393 Achitecture", draft-ww-sfc-control-plane-03 (work in 394 progress), September 2014. 396 Authors' Addresses 398 Seung-Ik Lee 399 ETRI 400 218 Gajeong-ro Yuseung-Gu 401 Daejeon 305-700 402 Korea 404 Phone: +82 42 860 1483 405 Email: seungiklee@etri.re.kr 406 Sangheon Pack 407 Korea University 408 145 Anam-ro, Seongbuk-gu 409 Seoul 136-701 410 Korea 412 Phone: +82 2 3290 4825 413 Email: shpack@etri.re.kr 415 Myung-Ki Shin 416 ETRI 417 218 Gajeong-ro Yuseung-Gu 418 Daejeon 305-700 419 Korea 421 Phone: +82 42 860 4847 422 Email: mkshin@etri.re.kr 424 EunKyoung Paik 425 KT 426 17 Woomyeon-dong, Seocho-gu 427 Seoul 137-792 428 Korea 430 Phone: +82 2 526 5233 431 Email: eun.paik@kt.com