idnits 2.17.1 draft-huang-sfc-use-case-recursive-service-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 date (January 13, 2015) is 3384 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Function Chaining C. Huang 2 Internet Draft Carleton University 3 Intended status: Informational Jiafeng Zhu 4 Expires: July 13, 2015 Huawei 5 Peng He 6 Ciena 7 January 13, 2015 9 SFC Use Cases on Recursive Services 10 draft-huang-sfc-use-case-recursive-service-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on July 13, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 Service function chaining (SFC) provides various services that can 53 be tailored to different requirements from diversified user groups, 54 where each user group forms a collective client that requires 55 similar service. SFC is typically deployed as a service overlay with 56 its own service topology on top of existing network topology. This 57 kind of virtualized structure naturally enables recursive service 58 relationship where a client may become a service provider and resell 59 SFC services to its own user groups. Alternatively, a client may 60 also choose to ask its service provider to provide a structured 61 service for its user groups. This document describes some exemplary 62 use cases that show the usage of recursive (e.g. nested) or 63 structured service function chaining relationship. 65 Table of Contents 67 1. Introduction ................................................ 2 68 2. Conventions used in this document ........................... 3 69 3. Use Case .................................................... 3 70 4. Analysis .................................................... 6 71 5. IANA Considerations ......................................... 6 72 6. Refernces ................................................... 8 74 1. Introduction 76 New services such as service function chaining (SFC) are becoming 77 popular with network function virtualization. Traditionally a 78 service chain consists of a set of dedicated network service boxes 79 such as firewall, load balancers, and application delivery 80 controllers that are concatenated together to support a specific 81 application. With a new service request, new devices must be 82 installed and interconnected in certain order. This can be a very 83 complex, time-consuming, and error-prone process, requiring careful 84 planning of topology changes and network outages and incurring high 85 OPEX. This situation is exacerbated when a tenant requires different 86 service sequences for different traffic flows or when multiple 87 tenants share the same underlying network. 89 Today's SFC takes a new approach built upon network function 90 virtualization (NFV). It involves the implementation of network 91 functions in software that can run on a range of industry standard 92 high volume servers, switches, and storage. Through NFV, service 93 providers can dynamically create a virtual environment for a 94 specific service chain and eliminate the dedicated hardware and 95 complex labor work for supporting a new service function chain 96 request. 98 One of the great potentials NFV can enable is the capability to 99 support recursive SFC service. A client of SFC service can resell 100 customized SFC services to its own user groups, where the client 101 becomes a service provider and its subscribed user groups become new 102 clients, without adding any dedicated hardware. This kind of 103 recursive (or nested) service relationship is quite common in daily 104 life. Big wholesalers can sell products to smaller wholesalers and 105 the smaller wholesalers then sell those products to other small 106 wholesalers or directly to end users. In telecom area, the Carriers' 107 Carriers concept is defined in RFC 4364[1], which comes from similar 108 idea. Forming recursive business relationship has been proven to be 109 a successful business model due to the flexibility and efficiency it 110 provides. The same arguments can also be applied to SFC service 111 providers. 113 A distinguished characteristic of recursive SFC service is that the 114 service provider at each level can have its own administrative 115 authority built over the virtual environment provided by the lower 116 level, leading to a hierarchy of administrative levels. This kind of 117 hierarchical structure poses both opportunities and challenges for 118 service providers. 120 While a service provider at each level can have its own 121 administrative authority, it can also choose to delegate its 122 authority to its service provider. In the simple case, all levels of 123 services will be delegated to one service provider, which will in 124 turn provide a structured service [2]. 126 In a later section, a use case will be presented to illustrate a 127 specific application scenario. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC-2119. 135 In this document, these words will appear with that interpretation 136 only when in ALL CAPS. Lower case uses of these words are not to be 137 interpreted as carrying RFC-2119 significance. 139 3. Use Case 141 There are numerous use cases that recursive SFC service can be 142 applied to. A typical use case is described below. 144 Consider a scenario where Enterprise B outsources its enterprise 145 network to a datacenter operated by a cloud service provider A. This 146 type of scenario has been widely considered as one of the major 147 applications of cloud computing. It is believed that enterprises can 148 save their costs and improve their IT services by exploring the 149 elasticity and dynamic sharing nature of a datacenter environment. 150 Different enterprises typically have different requirements about 151 their outsourced enterprise networks in terms of topology and 152 service function. 154 Consider the case that Enterprise B requests its outsourced network 155 to have mesh topology with each node dedicated to a special service 156 function. After receiving the request from Enterprise B, Cloud 157 Provider A will create all requested virtual service function nodes 158 with a mesh topology out of its infrastructure. Provider A will also 159 need to assign an ID which is unique in his authority to identify 160 this mesh service function chain. 162 +-----+ 163 +---+Video| 164 +---+ +---+ +---+ | +-----+ 165 +---+SSL+--+--+DPI+--+--+ADC+---+ 166 | +---+ | +---+ | +---+ | +---+ 167 | +---------+ +---+Web| 168 | +---+ 169 | 170 +-+-+ +---+ +--+ +---+ 171 ---+NAT+---+WOC+---+LB+---+Web| 172 +-+-+ +---+ +--+ +---+ 173 | 174 | 175 | +---+ +---+ +--+ +---+ 176 +-----+SSL+---+WOC+---+LB+---+Web| 177 +---+ +---+ +--+ +---+ 179 Figure 1 : Service function chains created by Enterprise B. 181 Suppose initially Enterprise B wants to support two user groups. One 182 group includes all its employees. The other group is for visitors 183 only. The two user groups have distinctive service function 184 requirements. Therefore Enterprise B has to create two SFCs out of 185 its outsourced enterprise network. The first service chain, designed 186 for its employees, will force traffic flows to go through NAT 187 (Network Address Translation), SSL (Secure Socket layer)/TLS 188 (Transport Layer Security), DPI (Deep Packet Inspection) if 189 necessary, ADC (Application Delivery Controller), and various 190 servers as shown in Fig.1. In this SFC, NAT, TLS, and DPI provide 191 strong firewall service while ADC conducts service routing and load 192 balance. The second SFC, designed for guest visitors, will go 193 through NAT, WOC (Web Optimization Control), LB (Load Balancer), and 194 web servers as shown in Fig.1. Here NAT provides limited firewall 195 function with access control. WOC and LB are designed to optimize 196 server efficiency. Enterprise B will create these two service chains 197 as overlays over its outsourced enterprise network. Because the 198 underlying service chain has a mesh topology with all different 199 service function nodes, Enterprise B can create the two service 200 chains very fast with minimal efforts. 202 Suppose Enterprise B later wants to add another user group for one 203 of its customers, called Customer C, it can do so easily by adding 204 another service chain which may include NAT, SSL/TLS, WOC, and LB as 205 shown in Fig.1. Each user group is a tenant for Enterprise B. 206 Therefore Enterprise B needs to assign an ID for each tenant so that 207 it can differentiate traffic streams for the three different 208 tenants. Each Id needs to be unique for Enterprise B. Customer C may 209 be an enterprise that has many departments who want to access the 210 resources available at Enterprise B's network. Customer C is given 211 full control of the service chain created for it. Customer C may 212 then create a service chain and an ID for each department that needs 213 access. 215 +---+ +--+ +---+ 216 |SSL+-----------+LB+---+Web| SFC created by 217 +---+ +--+ +---+ Client C 218 : : : 219 : : : 220 +---+ +---+ +---+ +--+ +---+ 221 |NAT+---+SSL+---+WOC+---+LB+---+Web| SFC created by 222 +---+ +---+ +---+ +--+ +---+ Enterprise B 223 : : : : : 224 : : : : : 225 +---+ +---+ +---+ +---+ +--+ +---+ 226 |DPI| |NAT| |SSL| |WOC| |LB| |Web| SFC created by Cloud 227 +---+ +---+ +---+ +---+ +--+ +---+ Provider A 228 | | | | | | 229 +--------+-------+-------+------+-------+ 231 Figure 2 : Recursive service function chain structure. 233 The above structure clearly leads to a recursive service 234 relationship as shown in Fig.2 where dot lines show mapping 235 relationship and dash lines are service chains (For clearness, only 236 one service chain is shown for each level.). Cloud Provider A 237 provides the first level SFC that includes a customized topology and 238 generic service function nodes. Enterprise B provides the second 239 level SFC which includes three customized SFCs. Customer C builds 240 the third level SFCs for several departments over the SFC created by 241 Enterprise B. As we mentioned before, this structure bears some 242 similarity to the Carriers' Carriers concept defined in RFC 4364[1]. 244 4. Analysis 246 One of the key issues introduced by the hierarchy of recursive SFC 247 relationship is the relationship between different levels. There are 248 three types of relationship that can be envisioned. The first one is 249 called independent relationship where the lower level is agnostic of 250 the SFCs created by upper levels. Therefore all the service 251 functions created by an upper level will be implemented and enforced 252 at the upper level SFC modules while the lower level modules are 253 completely unaware. When traffic arrives at a lower level module, 254 the module processes the incoming traffic based on its service 255 function requirements and de-multiplexes the traffic to the right 256 upper level module using the IDs it assigned. The lower level module 257 does not execute the service functions of upper level. The upper 258 level applies different service functions based on the IDs it 259 assigned. In this case, the upper level module does not have to be 260 the same type as the lower level module. Hence there could be a new 261 requirement for SFP header encapsulation, e.g., SFC header 262 'stacking', similar to MPLS label stacking or even Ethernet VLAN tag 263 stacking. A simple example is encryption/decryption service. The 264 lower level SFC contains the encryption/decryption service to 265 encrypt/decrypt the packet contents after the SFC header, the upper 266 level SFC(s) has to properly deal with the SFC header received from 267 the lower level, e.g., SFC header stacking might be worthy of 268 consideration. 270 The other type is opaque relationship where service functions 271 defined by upper level may require collaboration from lower level. 272 For example, Enterprise B may inform Cloud Provider A about some 273 service functions it needs and ask Cloud Provider A to help 274 implement those service functions. When traffic arrives at Cloud 275 Provider A, it will identify traffic flows using both the ID it 276 assigned and the ID assigned by upper level as a concatenated ID and 277 then apply associated service functions. The traffic stream will not 278 be delivered to upper level for those requested service functions. 279 In this case, upper level functions inherit properties from lower 280 level functions. They are also constrained by the functions 281 available from lower level. However the upper level can create new 282 properties such as new firewall rules as long as it doesn't violate 283 the constraint posed by the lower level. Whenever service functions 284 at lower level are changed, upper level service functions will also 285 be changed. However changes made to the upper level may not apply to 286 lower level. Fig.2 is an example of the opaque relationship. 288 In both cases, the upper level and lower level represent different 289 authorities. Cloud Provider A decides the mesh service chain while 290 Enterprise B decides the three linear service chains for its three 291 tenants. In reality, a tenant is more likely to retain some 292 functions as transparent (e.g. encryption function) and some 293 functions as opaque (e.g. LB). 295 Other than the two types mentioned above, it is also possible that 296 the Enterprise C delegates its administrative role to Enterprise B, 297 which in turn delegates its authority to Cloud Provider A. The 298 benefit of this single administrative domain approach is that 299 Enterprises B and C do not need to handle the administrative work. 300 However, both B and C need to disclose all information to A, forming 301 a transparent relationship. With transparent relationship, Cloud 302 Provider A has to implement all SFCs with a hierarchical structure 303 that satisfies the roles and responsibilities distributed according 304 to the organizational structure of Enterprises B and C [2]. This 305 kind of structured service is likely to become one of the SFC 306 deployment paradigms. 308 The above discussions show some special properties unique to 309 recursive service chain. It is necessary to investigate how these 310 properties can be supported using existing protocols, proposed SFC 311 mechanisms, various other mechanisms, or even new proposals. 313 5. IANA Considerations 315 It is recommended that IANA assign a port in UDP and another port 316 number in TCP to identify the existing of SFLs in Layer 5. The top 317 level SFL of a SFL stack can use all existing port number 318 assignments to identify various applications. 320 6. References 322 [1] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks 323 (VPNs)," IETF RFC 4364, February, 2006. 325 [2] R. Szabo, A. Csazzar, K. Pentikousis, M. Kind, and D. Daino, 326 "Unifying Carrier and Cloud Networks: Problem Sttatement and 327 Challenge," IETF draft, Oct. 2014. 329 < https://tools.ietf.org/html/draft-unify-nfvrg-challenges-00> 331 Authors' Addresses 333 Changcheng Huang 334 Department of Systems and Computer Engineering 335 Carleton University 336 1125 Colonel By Drive 337 Ottawa, ON K1S 5B6 338 Canada 339 Email: huang@sce.carleton.ca 341 Jiafeng Zhu 342 Huawei Technologies Inc 343 Santa Clara, CA 344 US 345 Email: Jiafeng.zhu@huawei.com 347 Peng He 348 Ciena Corp 349 Email: phe@ciena.com