idnits 2.17.1 draft-huang-sfc-use-case-recursive-service-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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 (July 1, 2014) is 3558 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: January 1, 2015 Huawei 5 Peng He 6 Ciena 7 July 1, 2014 9 SFC Use Cases on Recursive Service Function Chaining 10 draft-huang-sfc-use-case-recursive-service-00.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 September 3, 2014. 35 Copyright Notice 37 Copyright (c) 2014 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. This document describes some 60 exemplary use cases that show the usage of recursive (e.g. nested) 61 service function chaining relationship. 63 Table of Contents 65 1. Introduction...................................................2 66 2. Conventions used in this document..............................3 67 3. Use Case.......................................................3 68 4. Analysis.......................................................6 69 5. IANA Considerations............................................6 70 6. Refernces......................................................7 72 1. Introduction 74 New services such as service function chaining (SFC) are becoming 75 popular with network function virtualization. Traditionally a 76 service chain consists of a set of dedicated network service boxes 77 such as firewall, load balancers, and application delivery 78 controllers that are concatenated together to support a specific 79 application. With a new service request, new devices must be 80 installed and interconnected in certain order. This can be a very 81 complex, time-consuming, and error-prone process, requiring careful 82 planning of topology changes and network outages and incurring high 83 OPEX. This situation is exacerbated when a tenant requires different 84 service sequences for different traffic flows or when multiple 85 tenants share the same underlying network. 87 Today's SFC takes a new approach built upon network function 88 virtualization (NFV). It involves the implementation of network 89 functions in software that can run on a range of industry standard 90 high volume servers, switches, and storage. Through NFV, service 91 providers can dynamically create a virtual environment for a 92 specific service chain and eliminate the dedicated hardware and 93 complex labor work for supporting a new service function chain 94 request. 96 One of the great potentials NFV can enable is the capability to 97 support recursive SFC service. A client of SFC service can resell 98 customized SFC services to its own user groups, where the client 99 becomes a service provider and its subscribed user groups become new 100 clients, without adding any dedicated hardware. This kind of 101 recursive (or nested) service relationship is quite common in daily 102 life. Big wholesalers can sell products to smaller wholesalers and 103 the smaller wholesalers then sell those products to other small 104 wholesalers or directly to end users. In telecom area, the Carriers' 105 Carriers concept is defined in RFC 4364[1], which comes from similar 106 idea. Forming recursive business relationship has been proven to be 107 a successful business model due to the flexibility and efficiency it 108 provides. The same arguments can also be applied to SFC service 109 providers. 111 A distinguished characteristic of recursive SFC service is that each 112 level of service provider has its own administrative authority built 113 over the virtual environment provided by the lower level, leading to 114 a hierarchy of administrative levels. This kind of hierarchical 115 structure poses both opportunities and challenges for service 116 providers. In a later section, a use case will be presented to 117 illustrate a specific application scenario. 119 2. Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC-2119. 125 In this document, these words will appear with that interpretation 126 only when in ALL CAPS. Lower case uses of these words are not to be 127 interpreted as carrying RFC-2119 significance. 129 3. Use Case 131 There are numerous use cases that recursive SFL service can be 132 applied to. A typical use case is described below. 134 Consider a scenario where Enterprise B outsources its enterprise 135 network to a datacenter operated by a cloud service provider A. This 136 type of scenario has been widely considered as one of the major 137 applications of cloud computing. It is believed that enterprises can 138 save their costs and improve their IT services by exploring the 139 elasticity and dynamic sharing nature of a datacenter environment. 140 Different enterprises typically have different requirements about 141 their outsourced enterprise networks in terms of topology and 142 service function. 144 Consider the case that Enterprise B requests its outsourced network 145 to have mesh topology with each node dedicated to a special service 146 function. After receiving the request from Enterprise B, Cloud 147 Provider A will create all requested virtual service function nodes 148 with a mesh topology out of its infrastructure. Provider A will also 149 need to assign an ID which is unique in his authority to identify 150 this mesh service function chain. 152 +-----+ 153 +---+Video| 154 +---+ +---+ +---+ | +-----+ 155 +---+SSL+--+--+DPI+--+--+ADC+---+ 156 | +---+ | +---+ | +---+ | +---+ 157 | +---------+ +---+Web| 158 | +---+ 159 | 160 +-+-+ +---+ +--+ +---+ 161 ---+NAT+---+WOC+---+LB+---+Web| 162 +-+-+ +---+ +--+ +---+ 163 | 164 | 165 | +---+ +---+ +--+ +---+ 166 +-----+SSL+---+WOC+---+LB+---+Web| 167 +---+ +---+ +--+ +---+ 169 Figure 1 : Service function chains created by Enterprise B. 171 Suppose initially Enterprise B wants to support two user groups. One 172 group includes all its employees. The other group is for visitors. 173 The two user groups have distinctive service function requirements. 174 Therefore Enterprise B has to create two SFCs out of its outsourced 175 enterprise network. The first service chain, designed for its 176 employees, will force traffic flows to go through NAT (Network 177 Address Translation), SSL (Secure Socket layer)/TLS (Transport Layer 178 Security), DPI (Deep Packet Inspection) if necessary, ADC 179 (Application Delivery Controller), and various servers as shown in 180 Fig.1. In the SFC, NAT, TLS, and DPI provide strong firewall service 181 while ADC conducts service routing and load balance. The second SFC, 182 designed for guest visitors, will go through NAT, WOC (Web 183 Optimization Control), LB (Load Balancer), and web servers as shown 184 in Fig.1. Here NAT provides limited firewall function with access 185 control. WOC and LB are designed to optimize server efficiency. 186 Enterprise B will create these two service chains as overlays over 187 its outsourced enterprise network. Because the underlying service 188 chain has a mesh topology with all different service function nodes, 189 Enterprise B can create the two service chains very fast with 190 minimal efforts. 192 Suppose Enterprise B later wants to add another user group for one 193 of its customers, called Customer C, it can do so easily by adding 194 another service chain which may include NAT, SSL/TLS, WOC, and LB as 195 shown in Fig.1. 197 Each user group is a tenant for Enterprise B. Therefore Enterprise B 198 needs to assign an ID for each tenant so that it can differentiate 199 traffic streams for the three different tenants. Each Id needs to be 200 unique for Enterprise B. 202 Customer C may be an enterprise that has many departments who want 203 to access the resources available at Enterprise B's network. 204 Customer C is given full control of the service chain created for 205 it. Customer C may then create a service chain and an ID for each 206 department that needs access. 208 +---+ +---+ +---+ 209 |SSL+---+WOC+----------+Web| SFC created by 210 +---+ +---+ +---+ Client C 211 : : : 212 : : : 213 +---+ +---+ +---+ +--+ +---+ 214 |NAT+---+SSL+---+WOC+---+LB+---+Web| SFC created by 215 +---+ +---+ +---+ +--+ +---+ Enterprise B 216 : : : : : 217 : : : : : 218 +---+ +---+ +---+ +--+ +---+ 219 |NAT| |SSL| |WOC| |LB| |Web| SFC created by Cloud 220 +---+ +---+ +---+ +--+ +---+ Provider A 221 | | | | | 222 +-------+-------+------+-------+ 224 Figure 2 : Recursive service function chain structure. 226 The above structure clearly leads to a recursive service 227 relationship as shown in Fig.2 where dot lines show mapping 228 relationship and dash lines are service chains (For clearness, only 229 one service chain is shown for each level.). Cloud Provider A 230 provides the first level SFC that includes a customized topology and 231 generic service function nodes. Enterprise B provides the second 232 level SFC which includes three customized SFCs. Customer C builds 233 the third level SFCs for several departments over the SFC created by 234 Enterprise B. As we mentioned before, this structure bears some 235 similarity to the Carriers' Carriers concept defined in RFC 4364[1]. 237 4. Analysis 239 One of the key issues introduced by the hierarchy of recursive SFC 240 relationship is the relationship between different levels. There are 241 two types of relationship that can be envisioned. The first one is 242 called opaque relationship where the lower level is agnostic of the 243 SFCs created by upper levels. Therefore all the service functions 244 created by an upper level will be implemented and enforced at the 245 upper level SFC modules while the lower level modules are completely 246 unaware. When traffic arrives at a lower level module, the module 247 processes the incoming traffic based on its service function 248 requirements and de-multiplexes the traffic to the right upper level 249 module using the ID it assigned. The lower level module does not 250 execute the service functions of upper level. The upper level 251 applies different service functions based on the IDs it assigned. In 252 this case, the upper level module does not have to be the same type 253 as the lower level module (e.g. the lower level may be a NAT 254 function while the upper level may be SSL function). But the upper 255 level module will be based on the output of lower level module. For 256 example, traffic that has been filtered by lower level cannot be 257 recovered by upper level. This is why it is called opaque. 259 The other type is transparent relationship where service functions 260 defined by upper level may require collaboration from lower level. 261 For example, Enterprise B may inform Cloud Provider A about the SFCs 262 it has created and ask Cloud Provider A to help implement flows 263 belonging to different SFCs. When traffic arrives at Cloud Provider 264 A, it will identify traffic flows using both the ID it assigned and 265 the ID assigned by upper level as a concatenated ID and then apply 266 associated service functions. The traffic stream will not be de- 267 multiplexed to upper level. In this case, upper level functions 268 inherit properties from lower level functions. They are also 269 constrained by the functions available from lower level. However the 270 upper level can create new properties such as new firewall rules as 271 long as it doesn't violate the constraint posed by the lower level. 272 Whenever service functions at lower level are changed, upper level 273 service functions will also be changed. However changes made to the 274 upper level may not apply to lower level. Fig.2 is an example of the 275 transparent relationship. 277 In both cases, the upper level and lower level represent different 278 authorities. Cloud Provider A decides the mesh service chain while 279 Enterprise B decides the three linear service chains for its three 280 tenants. This is key feature of recursive service function chaining. 281 In practice, a tenant is more likely to retain some functions as 282 opaque (e.g. encryption function) and some functions as transparent 283 (e.g. LB). 285 The above discussions show some special properties unique to 286 recursive service chain. It is necessary to investigate how these 287 properties can be supported using existing protocols, proposed SFC 288 mechanisms, various other mechanisms, or even new proposals. 290 5. IANA Considerations 292 It is recommended that IANA assign a port in UDP and another port 293 number in TCP to identify the existing of SFLs in Layer 5. The top 294 level SFL of a SFL stack can use all existing port number 295 assignments to identify various applications. 297 6. References 299 [1] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks 300 (VPNs)," IETF RFC 4364, February, 2006. 302 Authors' Addresses 304 Changcheng Huang 305 Department of Systems and Computer Engineering 306 Carleton University 307 1125 Colonel By Drive 308 Ottawa, ON K1S 5B6 309 Canada 310 Email: huang@sce.carleton.ca 312 Jiafeng Zhu 313 Huawei Technologies Inc 314 Santa Clara, CA 315 US 316 Email: Jiafeng.zhu@huawei.com 318 Peng He 319 Ciena Corp 320 Email: phe@ciena.com