idnits 2.17.1 draft-lee-sfc-dynamic-instantiation-01.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 27, 2014) is 3462 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 345, but no explicit reference was found in the text == Unused Reference: 'I-D.ww-sfc-control-plane' is defined on line 356, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-02 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-10 == Outdated reference: A later version (-01) exists of draft-lee-nfvrg-resource-management-service-chain-00 == Outdated reference: A later version (-06) exists of draft-ww-sfc-control-plane-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service function Chaining S. Lee 3 Internet-Draft ETRI 4 Intended status: Informational S. Pack 5 Expires: April 30, 2015 KU 6 M-K. Shin 7 ETRI 8 E. Paik 9 KT 10 October 27, 2014 12 SFC dynamic instantiation 13 draft-lee-sfc-dynamic-instantiation-01 15 Abstract 17 This document describes a control plane architecture for dynamic 18 instantiation of service function chains which dynamically creates 19 and adapts service function paths to optimize performance of the 20 service function paths. This document further defines basic 21 operations for the dynamic instantiations; and performance metrics of 22 service function path components, i.e., service function instances 23 and forwarding links among service function forwarders for evaluation 24 of the service function path. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 30, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. SFC dynamic instantiation . . . . . . . . . . . . . . . . . . 4 63 4. Control plane architecture . . . . . . . . . . . . . . . . . 6 64 5. Operational procedures . . . . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The current service delivery model is bound to static topologies and 75 manually configured resources. This has motivated a more flexible 76 deployment model which orchestrates the service delivery separated 77 from the network. Service function chaining 78 [I-D.ietf-sfc-problem-statement] provides a new service deployment 79 model that delivers the traffic along the predefined logical paths of 80 service functions (SFs), called service function chains (SFCs) with 81 no regard of network topologies or transport mechanisms. 83 A SFC is determined by classification of target traffic based on 84 operator's policy. Since it is described with logical SFs, the 85 service function chain needs to be instantiated by selecting 86 instances of the SFs, which results in a service function path (SFP). 87 Performance of a SFP depends on the current state or attributes 88 (e.g., availability, topological location, and latency) of SFP 89 components (i.e., SF instances (SFIs) and forwarding links among SFFs 90 (SFLs)). Thus, the SFP performance may vary according to which SFIs 91 are selected at SFC instantiation; and it may also vary in time with 92 the state or attributes of the SFP components. 94 This document describes a control plane architecture for dynamic 95 instantiation of SFCs which dynamically creates and adapts SFPs to 96 optimize the SFP performance considering the current state and 97 attributes of SFIs and SFLs. This document further defines basic 98 operations for the dynamic instantiations and performance metrics of 99 SFP components for SFP evaluation. 101 2. Terminology 103 This document uses the following terms and most of them were 104 reproduced from [I-D.ietf-sfc-problem-statement] and 105 [I-D.ietf-sfc-architecture]. 107 o Classification: Locally instantiated policy and customer/network/ 108 service profile matching of traffic flows for identification of 109 appropriate outbound forwarding actions. 111 o Service Function Chain (SFC): A service function chain defines a 112 set of abstract service functions and ordering constraints that 113 must be applied to packets and/or frames selected as a result of 114 classification. The implied order may not be a linear progression 115 as the architecture allows for SFCs that copy to more than one 116 branch, and also allows for ere there is flexibility in the order 117 in which service functions need to be applied. The term service 118 chain is often used as shorthand for service function chain. 120 o Service Function (SF): A function that is responsible for specific 121 treatment of received packets. A Service Function can act at 122 various layers of a protocol stack (e.g., at the network layer or 123 other OSI layers). As a logical component, a Service Function can 124 be realized as a virtual element or be embedded in a physical 125 network element. One or multiple Service Functions can be 126 embedded in the same network element. Multiple occurrences of the 127 Service Function can exist in the same administrative domain. 129 o Service Function Instance (SFI): The instantiation of Service 130 Function that can be a virtual instance or be embedded in a 131 physical network element. One of multiple Service Functions can 132 be embedded in the same network element. Multiple instances of 133 the Service Function can be enabled in the same administrative 134 domain. 136 o Service Function Forwarder (SFF): A service function forwarder is 137 responsible for delivering traffic received from the network to 138 one or more connected service functions according to information 139 carried in the SFC encapsulation, as well as handling traffic 140 coming back from the SF. Additionally, a service function 141 forwarder is responsible for delivering traffic to a classifier 142 when needed and supported, mapping out traffic to another SFF (in 143 the same or different type of overlay), and terminating the SFP. 145 o Service Function Path (SFP): The SFP provides a level of 146 indirection between the fully abstract notion of service chain as 147 a sequence of abstract service functions to be delivered, and the 148 fully specified notion of exactly which SFF/SFs the packet will 149 visit when it actually traverses the network. By allowing the 150 control components to specify this level of indirection, the 151 operator may control the degree of SFF/SF selection authority that 152 is delegated to the network. 154 o Service Forwarding Link (SFL): An overlay link between two SFFs 155 over which the packet will visit SF along the SFP. 157 3. SFC dynamic instantiation 159 A service function chain is composed of one or more logical service 160 functions and it can be further instantiated with a SFP which 161 contains physical instances of the logical SFs. Since multiple 162 instances of a SF may be available, different sets of SFI (i.e., 163 SFPs) can be built per SFC. 165 For example in Figure 1, a SFC {SF1 -> SF2 -> SF3} selected for a 166 traffic flow can be further instantiated with two different SFPs: 167 SFP#1 {SF1_a -> SF2_a -> SF3_a} and SFP#2 {SF1_b -> SF2_b -> SF3_b} 168 by selecting one of multiple instances of the service functions. 170 +------+ +------+ +------+ 171 SFC | SF1 |-----------| SF2 |-----------| SF3 | 172 +------+ +------+ +------+ 174 +------+ +------+ +------+ 175 |SF1_a | |SF2_a | |SF3_a | 176 +------+ +------+ +------+ 177 SFP#1 | | | 178 ******** ******** ******** 179 * SFF *-----------* SFF *-----------* SFF * 180 ******** SFL ******** SFL ******** 181 SFP#2 | | | 182 +------+ +------+ +------+ 183 |SF1_b | |SF2_b | |SF3_b | 184 +------+ +------+ +------+ 186 Figure 1: SFC instantiation 188 Under this abstraction, a SFC can be constructed by the following 189 operations: 191 o Classification: One SFC is selected and identified by a 192 classification function according to the traffic steering policy 193 defined by the network operator. The policy just logically 194 defines which service functions must be applied to traffic flows 195 in a specific order. 197 o Re-classification (or branching): According to an intermediate 198 result of packet treatment, the current SFC can be updated by 199 adding or removing SFs, which results in creation of a new SFP. 201 o SFC instantiation: In order to define the physical forwarding 202 paths for the traffic, the SFC needs to be instantiated to a SFP 203 by selecting a specific instance of each service function that is 204 given in the SFC. The SFP can be updated by replacing one or more 205 conventional SF instances with the other ones at run-time. Note 206 that it does not cause change of a SF but change of a physical 207 instance of the same SF. 209 The SFC instantiation may be static or dynamic. In a static 210 instantiation, specific SF instances are pre-determined by network 211 operator's configuration or policy. The static instantiation may be 212 more convenient for network administrators because they can easily 213 expect the result and troubleshooting locations. However, since it 214 does not consider the current state and attribute of SFIs, the static 215 instantiation may create more vulnerable SFPs to state changes of the 216 SFIs such as failure or overload. 218 In a dynamic SFC instantiation, SFIs are selected according to their 219 states and attributes at time of demand, specifically at initial 220 classification or during intermediate traversal of the SFP. 222 o At classification: SF instances are selected to initially 223 construct a SFP before starting to forward the incoming traffic 224 flows 226 o At intermediate traversal: One or more SF instances are selected 227 and dynamically replaced during traversing the SFP to update the 228 SFP 230 The example use cases of SFC dynamic instantiation are as follows: 232 o SFP fail-over: re-construct a SFP with replacing the failed SFI 233 with new SFI selected 235 o End-to-end service optimization: construct or maintain a SFP with 236 a low stretch considering the topological locations of SFI and 237 properties (e.g., latency, bandwidth) of SFLs 239 o Traffic optimization: construct or maintain SFPs to localize the 240 traffic in the network considering load and administrative domains 241 of SFIs and SFLs. 243 o Load balancing: construct or maintain SFPs to distribute the load 244 of shared SFIs and SFLs. 246 For more details about the use cases, refer to 247 [I-D.lee-nfvrg-resource-management-service-chain]. 249 4. Control plane architecture 251 In order to instantiate a SFC dynamically according to the state and 252 attributes of SFP components, the following functional building 253 blocks are required in a SFC control plane architecture. 255 SFC instantiation 257 o Evaluate SFIs and SFLs based on the measurements obtained from SFP 258 component management building block 260 o Select SFIs to construct a SFP optimized according to the 261 evaluation results 263 o Enforce the constructed SFP for incoming traffic to the 264 classification node via interface-(a) 266 o Replace SFIs to update a SFP adapted to changes of state or 267 attributes of SFIs and SFLs 269 o Enforce the updated SFP for upcoming SFC traversal to SFFs via 270 interface-(b) 272 SFP component management 274 o Collect and monitor state and attributes of SFIs and SFLs via 275 interface-(d) and interface-(c), respectively 277 o Provide the collected state and attributes of SFIs and SFLs to SFC 278 instantiation building block for evaluation 280 #=================================================# 281 # # 282 # +---------------+ +---------------+ # 283 # ____| SFC |______| SFP component | # 284 # | | instantiation | | management | # 285 # | +---------------+ +---------------+ # 286 # | | ^ ^ # 287 #===|=============|=================|=====|=======# 288 | | | | 289 |(a) |(b) |(c) |(d) 290 | | | | 291 | | +------+ | +------+ 292 | | | SFI | | | SFI | 293 | | +------+ | +------+ 294 V V | | | 295 ******** ******** ******** 296 -* CLSF *-------* SFF *-----------* SFF *-------- 297 ******** ******** ******** 299 Figure 2: Control plane architecture for SFC dynamic instantiation 301 The state and attributes of SFP components for SFP evaluation can be 302 obtained via interface-(c) and interface-(d). Examples of the state 303 and attributes of SFP components are as follows: 305 o availability (or failure) of a SFI and a SFL 307 o a topological location of a SFI 309 o a utilization rate of a SFI 311 o a throughput of a SFI 313 o energy consumption of SFI 315 o bandwidth of a SFL 317 o latency of a SFL 319 5. Operational procedures 321 (TBD) 323 6. Security Considerations 325 (TBD) 327 7. IANA Considerations 329 (TBD) 331 8. References 333 8.1. Normative References 335 [I-D.ietf-sfc-architecture] 336 Halpern, J. and C. Pignataro, "Service Function Chaining 337 (SFC) Architecture", draft-ietf-sfc-architecture-02 (work 338 in progress), September 2014. 340 [I-D.ietf-sfc-problem-statement] 341 Quinn, P. and T. Nadeau, "Service Function Chaining 342 Problem Statement", draft-ietf-sfc-problem-statement-10 343 (work in progress), August 2014. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 8.2. Informative References 350 [I-D.lee-nfvrg-resource-management-service-chain] 351 Lee, S., Pack, S., Shin, M., and E. Paik, "Resource 352 Management for Dynamic Service Chain Adaptation", draft- 353 lee-nfvrg-resource-management-service-chain-00 (work in 354 progress), October 2014. 356 [I-D.ww-sfc-control-plane] 357 Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W. 358 Haeffner, "Service Function Chaining (SFC) Control Plane 359 Achitecture", draft-ww-sfc-control-plane-03 (work in 360 progress), September 2014. 362 Authors' Addresses 363 Seung-Ik Lee 364 ETRI 365 218 Gajeong-ro Yuseung-Gu 366 Daejeon 305-700 367 Korea 369 Phone: +82 42 860 1483 370 Email: seungiklee@etri.re.kr 372 Sangheon Pack 373 Korea University 374 145 Anam-ro, Seongbuk-gu 375 Seoul 136-701 376 Korea 378 Phone: +82 2 3290 4825 379 Email: shpack@etri.re.kr 381 Myung-Ki Shin 382 ETRI 383 218 Gajeong-ro Yuseung-Gu 384 Daejeon 305-700 385 Korea 387 Phone: +82 42 860 4847 388 Email: mkshin@etri.re.kr 390 EunKyoung Paik 391 KT 392 17 Woomyeon-dong, Seocho-gu 393 Seoul 137-792 394 Korea 396 Phone: +82 2 526 5233 397 Email: eun.paik@kt.com