idnits 2.17.1 draft-liu-sfc-use-cases-08.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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 17, 2014) is 3506 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-01 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-01 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Liu, Ed. 3 Internet-Draft H. Li 4 Intended status: Informational O. Huang 5 Expires: March 21, 2015 Huawei Technologies 6 M. Boucadair, Ed. 7 France Telecom 8 N. Leymann 9 Deutsche Telekom AG 10 Q. Fu 11 China Mobile 12 Q. Sun 13 China Telecom 14 C. Pham 15 Telstra Corporation 16 C. Huang 17 Carleton University 18 J. Zhu 19 Huawei Technologies 20 P. He 21 Ciena Corp 22 September 17, 2014 24 Service Function Chaining (SFC) General Use Cases 25 draft-liu-sfc-use-cases-08 27 Abstract 29 The delivery of value-added services relies on the invocation of 30 advanced Service Functions in a sequential order. This mechanism is 31 called Service Function Chaining (SFC). The set of involved Service 32 Functions and their order depends on the service context and other 33 deployment-specific considerations. 35 Having a single use case document eases the effort of deriving 36 requirements that are to be met by SFC solution(s). Moreover, it 37 allows to identify commonalities between the various use cases that 38 are of interest. This document presents a set of general use cases 39 of Service Function Chaining (SFC). 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on March 21, 2015. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Service Function Chaining Use Cases . . . . . . . . . . . . . 5 78 3.1. Service Function Chain in Fixed Broadband Networks . . . 5 79 3.2. Service Function Chain in Mobile Networks: Brief Overview 6 80 3.3. Common Service Chain Network: A Convergence Tool . . . . 7 81 3.4. Distributed Service Function Chain . . . . . . . . . . . 8 82 3.5. Service Function Chain in Data Center . . . . . . . . . . 9 83 3.6. Service Function Chain in Cloud CPE . . . . . . . . . . . 9 84 4. Abstraction of SFC in Different Deployment Scenarios . . . . 10 85 4.1. Per-service characteristic SFC . . . . . . . . . . . . . 11 86 4.2. Per-user/subscription requirement SFC . . . . . . . . . . 12 87 4.3. TE-Oriented SFC . . . . . . . . . . . . . . . . . . . . . 12 88 4.4. SFC for Bi-directional Flow . . . . . . . . . . . . . . . 12 89 4.5. SFC over Multiple Underlay Networks . . . . . . . . . . . 13 90 4.6. SFC over Service Path Forking . . . . . . . . . . . . . . 14 91 4.7. Recursive SFC . . . . . . . . . . . . . . . . . . . . . . 15 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 94 7. Informative References . . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 The delivery of Value-Added Services (VAS) relies on the invocation 100 of various Service Functions (SFs). Typically, the traffic is 101 forwarded through a set of Network Elements embedding Service 102 Functions, e.g.: 104 a. Direct a portion of the traffic to a Network Element for 105 monitoring and charging purposes. 107 b. Before sending traffic to DC servers, steer the traffic to cross 108 a load balancer to distribute the traffic load among several 109 links, Network Elements, etc. 111 c. Mobile network operators split mobile broadband traffic and steer 112 them along an offloading path. 114 d. Use a firewall to filter the traffic for IDS (Intrusion Detection 115 System)/IPS (Intrusion Protection System). 117 e. Use a security gateway to encrypt/decrypt the traffic. SSL 118 offloading function can also be enabled. 120 f. If the traffic has to traverse different networks supporting 121 distinct address families, for example IPv4/IPv6, direct the 122 traffic to a CGN (Carrier Grade NAT, [RFC6888][RFC6674]) or NAT64 123 [RFC6146]. 125 g. Some internal service platforms rely on implicit service 126 identification. Dedicated Service Functions are enabled to 127 enrich packets (e.g., HTTP header enrichment) with the identity 128 of the subscriber or the UE (User Equipment). 130 h. Operators offer VAS on a per subscription basis. It is desirable 131 to steer traffic only from the subscribers, who have subscribed 132 to VAS, to the relevant service platforms. 134 Having a single use case document eases the effort of deriving 135 requirements that are to be met by SFC solution(s). Moreover, it 136 allows to identify commonalities between the various use cases that 137 are of interest. This document describes some use cases of Service 138 Function Chaining (SFC). It is not the purpose of this document to 139 be exhaustive, but instead, we try to draw the set of deployments 140 context that are likely to see SFC solutions deployed. 142 For most of the use cases presented in this document: 144 o Instantiated SFC are driven by business and engineering needs. 146 o The amount of instantiated SFCs can vary in time, service 147 engineering objectives and service engineering choices. 149 o The amount of instantiated SFCs are policy-driven and are local to 150 each administrative entity. 152 o The technical characterization of each Service Function is not 153 frozen in time. A Service Function can be upgraded to support new 154 features or disable an existing feature, etc. 156 o Some stateful SFs (e.g., NAT or firewall) may need to treat both 157 outgoing and incoming packets. The design of SF Maps must take 158 into account such constraints, otherwise, the service may be 159 disturbed. The set of SFs that need to be invoked for both 160 direction is up to the responsibility of each administrative 161 entity operating an SFC-enabled domain. 163 o For subscription-based traffic steering, subscriber-awareness 164 capability is required. A UE is allocated a dynamic IPv4 address 165 and/or IPv6 prefix when attaching to a network. This IPv4 address 166 and/or IPv6 prefix can change from time to time. The requirement 167 is to be able to correlate an IPv4 address and/or IPv6 prefix to a 168 subscriber identity from that will be used to trigger the 169 invocation of some Service Functions. 171 o Some Service Functions may be in the same subnet; while others may 172 not. Service Functions are deployed directly on physical 173 hardware, as one or more Virtual Machines, or any combination 174 thereof. 176 2. Terminology 178 This document makes use of the terms defined in 179 [I-D.ietf-sfc-architecture]. 181 Service Flow: packets/frames with specific service characteristics 182 (e.g., packets matching a specific tuple of fields in the packet 183 header and/or data) or determined by some service-inferred policies 184 (such as access port and etc.). 186 Gi interface: 3GPP defines the Gi interface as the reference point 187 between the GGSN (Gateway GPRS Support Node) and an external PDN 188 (Packet Domain Network). This interface reference point is called 189 SGi in 4G networks (i.e., between the PDN Gateway (PGW) and an 190 external PDN)[RFC6459]. 192 3. Service Function Chaining Use Cases 194 Service Function Chains can be deployed in a diversity of scenarios 195 such as broadband networks, mobile networks, and DC center. This 196 section describes a set of scenarios for Service Function Chaining 197 deployment. Please note that for each SFC there is a corresponding 198 symmetrical reverse chain, so we added bidirectional links to each 199 SFC use case figure below. For those links that do not have a 200 directional mark, they are bidirectional by default. 202 3.1. Service Function Chain in Fixed Broadband Networks 204 In fixed broadband networks, users may be accessed into the network 205 via different technologies, which typically includes DSL, Ethernet 206 and PON. Whatever the access technology is, the architecture for 207 access and metro network is similarly comprised of Access Nodes (ANs) 208 and Broadband Network Gateways (BNGs), where the AN is usually a 209 device providing access to network for customers with variant access 210 technologies and the BNG is the first IP node and providing 211 subscriber authorization, authentication and accounting. 213 ------ 214 // \\ 215 +--------+ +------+ +---+ || || 216 |Customer|---|Access|----|BNG|-----------------------| Internet | 217 |Network | |Node | +---+ ^ ^ || || 218 +--------+ +------+ | | \\ // 219 V ----- v ------ 220 /// \\\ 221 || Service || 222 | Chain | 223 || Network || 224 \\\ /// 225 ----- 227 Service Function Chain in Fixed Broadband Networks 229 Figure 1: An example of Service Function Chain in Broadband Networks 231 Figure 1 illustrates a fixed broadband network with Service Chaining. 232 Service Chain Network is deployed behind BNG and before Internet. 233 The Service Function Chain in Figure 1 may include several Service 234 Functions to perform services such as DPI, NAT44, DS-Lite, NPTv6, 235 Parental control, Firewall, load balancer, Cache, etc. 237 The Broadband Forum (BBF) is developing a study document (SD-326) 238 about Flexible Service Chaining, whose scope includes identifying and 239 documenting use cases relevant to fixed broadband networks. Though 240 SD-326 is an internal project within BBF, the content related to use 241 cases has been communicated to IETF per the following Liaison 242 Statement: Broadband Forum Work on Flexible Service Chaining (SD-326) 243 (http://datatracker.ietf.org/liaison/1304/). As BBF is the leading 244 organization on fixed broadband network architectures, this liaison 245 will serve as reference for service chaining use cases applicable in 246 such fixed broadband context. Future liaison statements from BBF may 247 provide additional use cases, and will be referenced here as 248 appropriate. 250 3.2. Service Function Chain in Mobile Networks: Brief Overview 252 3GPP defines the Gi interface as the reference point between the GGSN 253 (Gateway GPRS Support Node) and an external PDN (Packet Domain 254 Network) [RFC6459]. This interface reference point is called SGi in 255 4G networks (i.e., between the PDN Gateway (PGW) and an external PDN) 256 [RFC6459]. Note, there is no standard specification of such 257 reference points (i.e., Gi and SGi) in terms of functions to be 258 located in that segment. 260 Note: The use cases do not include 3GPP release details. For more 261 information on the 3GPP releases detail, the reader may refer to 262 Section 6.2 of [RFC6459]. 264 Traffic is directed to/from Internet traversing one or more Service 265 Functions. Note, these Service Functions are called "enablers" by 266 some operators. One example of enabler function is a HTTP Header 267 Enrichment Function. There are also other VAS function such as 268 Parental Control or network-based Firewall. Subscribers can opt-in 269 and opt-out to these services anytime using a self-served portal or 270 by calling the Operator's customer service. 272 In light of current deployments, plenty of Service Functions are 273 enabled in the Gi Interface (e.g., DPI, billing and charging, TCP 274 optimization, web optimization, video optimization, header 275 enrichment, etc.). Some of these Service Functions are co-located on 276 the same device while others are enabled in standalone boxes. In 277 order to fulfill new business needs, especially to offer innovative 278 added-value services, the number of enabled Service Functions in the 279 Gi Interface is still growing. Some of these functions are not 280 needed to be invoked for all services/UEs, e.g.,: TCP optimization 281 function only for TCP flows, HTTP header enrichment only of HTTP 282 traffic, Video optimization function for video flows, IPv6 firewall + 283 NAT64 function for outgoing IPv6 packets, IPv4 firewall + NAT64 284 function for incoming IPv4 packets, etc.. 286 3GPP has defined Traffic Detection Function (TDF) which implements 287 DPI (detection) functionality along with enforcement and charging of 288 the corresponding detected applications [TS.23203]. TDF resides on 289 Gi/SGi interface. 291 Note: It was tempting to use TDF and DPI terms interchangeably, 292 but given the diversity of deployments involving DPI modules the 293 text uses DPI to refer to legacy deployments. The behavior of 294 such DPI modules is deployment-specific. 296 Several (S)Gi Interfaces can be deployed within the same PLMN (Public 297 Land Mobile Network). This depends mainly on the number of PDNs and 298 other factors. Each of these interfaces may involve a differentiated 299 set of Service Functions to be involved. 301 More details about SFC usage within Mobile Networks can be found in 302 [I-D.ietf-sfc-use-case-mobility]. 304 3.3. Common Service Chain Network: A Convergence Tool 306 From previous two use cases, we can see commonalities in service 307 chaining. Even though fixed and mobile broadband networks are 308 deployed separately, for integrated operators that running both 309 networks it is obviously beneficial to provide service chaining to 310 both networks from a common service chain network. 312 In addition to resource optimisation, a common service chain network 313 can also enable seamless service switchover from one network to the 314 other. For example, a customer is watching football game on his 315 mobile phone via 3G network. After he arrives home, he can switch 316 over to the WLAN on his home gateway, which is backhauled to the 317 network by Fiber To The Home (FTTH, a typical PON service), 100 Mbps 318 broadband access. In the case, it is easier to provide seamless 319 service from a common service chain network. 321 SFC can be used as a tool to better address convergence needs 322 (including adjust the service delivery to the access network 323 constraints or to the capabilities of connected devices). 325 --- 326 ///--------\\\ //- -\\ 327 || Fixed Access || +---+ / \ ------ 328 || Network ||---|BNG|---- | || // \\ 329 \\\--------/// +---+ | Service | || || 330 | Chain |----| Internet | 331 ///--------\\\ | Network | || || 332 || Mobile || +---+ | | \\ // 333 || Network ||---|PGW|----- \ / ------ 334 \\\--------/// +---+ \\- -// 335 --- 337 Figure 2: Common Service Chain Network 339 Figure 2 illustrates a common Service Chain Network is shared by both 340 fixed and mobile broadband networks. Such a common service chain 341 network can be deployed as consisting of only network nodes with 342 specific functions, or in a data center. In both cases, service 343 nodes, whether physical or virtual, are shared by both wireline and 344 wireless networks. Operators manage service chains universally for 345 both networks and traffic from both networks may go through the same 346 service chain. 348 3.4. Distributed Service Function Chain 350 Besides the deployment use cases listed above, a Service Function 351 Chain is not necessarily implemented in a single location but can 352 also be distributed crossing several portions of the network (e.g., 353 data centers) or even using a Service Function that is located at an 354 network element close to the customer (e.g. certain security 355 functions). 357 Multiple SFC-enabled domains can be enabled in the same 358 administrative domain. 360 For steering traffic to subscription-based Service Functions, the SFC 361 Classifier needs to understand which subscriber a flow belong to in 362 order to retrieve the service profile to apply to this flow. In some 363 contexts, it is not possible to identify in a permanent manner the 364 subscriber by the source IP address because that IP address may be 365 assigned dynamically. Out-of-band methods to correlate the source IP 366 address and a subscriber identifier may be needed in a given 367 administrative domain. The SFC Classifier can rely on pull or push 368 methods to correlate an IP address and/or IPv6 prefix to a subscriber 369 identity. Examples are querying the PCRF or receiving RADIUS 370 Accounting messages respectively. 372 For steering traffic to traffic management Service Functions such as 373 video optimisation platform, in mobile network, it is desirable to 374 perform optimisation on when required. That is when there is 375 congestion in the Radio cells. One option for the SFC Classifier to 376 have this congestion-awareness is for the network to provide this 377 information to the SFC Classifier, directly, or via an intermediate 378 actionable-intelligence function, which can combine other inputs or 379 policies. How those policies and feedback data are configured to the 380 SFC Classifier may be specific to each administrative domain. 382 3.5. Service Function Chain in Data Center 384 In DC (Data Center), like in broadband and mobile networks, Service 385 Function Chains may also be deployed to provide added-value services. 387 Figure 3 illustrates a possible scenario for Service Function Chain 388 in Data Center: SFs are located between the DC Router (access router) 389 and the Servers. From Servers to Internet, there are multiple 390 Service Functions such as IDS/IPS, FW, NAT lined up and a monolithic 391 SFC created for all incoming traffic. 393 *********************************************** 394 * +------+ * 395 * |Server+<+ * 396 * +------+ | * ------ 397 * | * // \\ 398 * +------+ | +-------+ +--+ +---+ +---------+ | | 399 * |Server+<+->|IDS/IPS+<->|FW+<->|NAT+<->|DC Router|<->+ Internet | 400 * +------+ | +-------+ +--+ +---+ +---------+ | | 401 * | * \\ // 402 * | * ------ 403 * ... <+ * 404 * * 405 * ... * 406 * * 407 * DC * 408 *********************************************** 410 Figure 3: Service Function Chain in Data Center 412 More details about Service Function Chain in Data Center can be found 413 in [I-D.ietf-sfc-dc-use-cases]. 415 3.6. Service Function Chain in Cloud CPE 417 Cloud CPE is one deployment scenario where the value-added service 418 functions are centralized (e.g., hosted in the network or cloud 419 side), leaving the subscriber side box with basic L2/L3 420 functionalities. In this scenario, all the value added services are 421 configured by subscribers and enabled in the network side. 423 Subscribers can define their own added value services. The Cloud CPE 424 will translate those services requests into chains of Service 425 Functions. Such architecture must support means to differentiate 426 subscribers and their traffic. 428 +------+ +------Cloud CPE-----+ 429 |L2-CPE|--+ | +---+ | 430 +------+ | | +--+ /|ACL|-- | +------------+ 431 ... |==Encapsulation==|---|FW|-- +---+ \__|_____| Internet | 432 +------+ | | +--+ \ / | +------------+ 433 |L2-CPE|--+ | +-----+ | 434 +------+ | |TCP-O| | 435 | +-----+ | 436 +--------------------+ 438 Figure 4: SFC in Cloud CPE 440 4. Abstraction of SFC in Different Deployment Scenarios 442 This section presents the SFC scenarios from a different angle, i.e., 443 the abstraction of SFC use cases in different deployment scenarios. 444 Each of the use case may belong to one or many of the categories 445 listed below: 447 +---------------------+-------------------------------------------+ 448 |Category | Description | 449 +---------------------+-------------------------------------------+ 450 |Per-service | Chain different Service Functions based | 451 |Characteristic SFC | on service/application characteristics | 452 +---------------------+-------------------------------------------+ 453 |Per-user/subscription| Chain different Service Functions based | 454 |SFC | on user requirements or subscription | 455 | | information. Note, this does not mean | 456 | | that millions of SFCs will be instantiated| 457 | | but SF classification is subscriber-aware.| 458 +---------------------+-------------------------------------------+ 459 |TE-Oriented SF | Chain different Service Functions for | 460 | | Traffic Engineering purposes. This may | 461 | | includes load, utilisation, planned | 462 | | maintenance, etc. | 463 +---------------------+-------------------------------------------+ 464 |Bi-directional Flow | Function path that contain bi-directional | 465 |SFC | Service Functions | 466 +---------------------+-------------------------------------------+ 467 |SFC over Multi- | Service Functions distributed over differ-| 468 |Underlay Networks | ent underlay networks | 469 +---------------------+-------------------------------------------+ 470 |SFC over Service | SFC that contains the paths for different | 471 |Functions Forking | service or applications | 472 +---------------------+-------------------------------------------+ 474 4.1. Per-service characteristic SFC 476 The traffic in a network is usually forwarded based on destination IP 477 or MAC addresses. In an operator's network, some Service Functions 478 are implemented, where traffic is steered through these Service 479 Functions in a certain sequence according to service characteristics 480 and objectives. 482 +---------------------------+ 483 +-------->|Service Function Chaining A 484 +------------+ | +---------------------------+ 485 ------->|Service |<-->| 486 |Classifier | | +---------------------------+ 487 +------------+ +-------->|Service Function Chaining B| 488 +---------------------------+ 490 Figure 5: General Service Function Chain 492 Traffic enters a SFC-enabled domain in a service classifier, which 493 identifies traffic and classifies it into service flows. Service 494 flows are forwarded on a per SF Map basis. 496 4.2. Per-user/subscription requirement SFC 498 In operator networks with user subscription information, it is 499 considered as a value added service to provide different subscribers 500 with differentiated services. Subscribers may subscribe different 501 services and the order handling at the operator side will translate 502 those subscription request into configuration operations so that the 503 service will be appropriately delivered to the subscribers. 504 Configuration operations include in particular the provisioning of 505 classification rules. 507 4.3. TE-Oriented SFC 509 TE-oriented SFC is required by operators in achieving flexible 510 service operating. For example, if certain paths are congested or 511 certain Service Functions are overloaded, SFC forwarding should be 512 inferred accordingly. 514 4.4. SFC for Bi-directional Flow 516 Some Service Functions, for example, NAT or TCP optimization, need to 517 handle bi-directional flows, while others SFs such as video 518 optimization don't need to handle bi-directional flows. 520 Due to IPv4 address exhaustion, more and more operators have deployed 521 or are about to deploy IPv6 transition technologies such as NAT64 522 [RFC6146]. The traffic traversing a NAT64 function may go through 523 different types of IP address domains. One key feature of this 524 scenario is that characteristics of packets before and after 525 processed by the service processing function are different, e.g., 526 from IPv6 to IPv4. The unpredictability of processed packets, due to 527 the algorithm in the Service Function, brings difficulties in 528 steering the traffic. 530 A variety of hosts can be connected to the same network: IPv4-only, 531 dual-stack, and IPv6-only. A differentiated forwarding path can be 532 envisaged for each of these hosts. In particular, DS hosts should 533 not be provided with a DNS64, and as such there traffic should not be 534 delivered to a NAT64 device. Means to guide such differentiated path 535 can be implemented at the host side; but may also be enabled in the 536 network side as well. 538 +---------+ +----------+ 539 ====>+ SF C + +----------+ | SF E |<==>+---+ 540 | +---------+<======>| SF |<======>+----------+ |INT| 541 +<=====================>| NAT |<======================>|NET| 542 +----------+ +---+ 544 Figure 6: Service Function Chain with NAT64 function 546 Figure 6 shows a specific example of Service Function Chain with NAT 547 function. Service flow1 is processed by SF(Service Function) C, NAT 548 and E sequentially. In this example, the SF NAT performs NAT64. As 549 a result, packets after processing by the SF NAT are in IPv4, which 550 is a different version of IP header from the packets before 551 processing. Service Function Chaining in this scenario should be 552 able to identify the flow even if it is changed after processed by 553 Service Functions. 555 4.5. SFC over Multiple Underlay Networks 557 Operators may need to deploy their networks with various types of 558 underlay technologies. Therefore, Service Function Chaining needs to 559 support different types of underlay networks. 561 +---------+ +----------+ +----------+ 562 ---+ SF A | | SF B | | SF C +--- 563 +----+----+ +---+-+----+ +-----+----+ 564 ^ ^ ^ ^ 565 | ------ | | ------ | 566 | // \\ | | // \\ | 567 | | Ethernet | v v | | | 568 +->+ network +--+ +--+ IP network +<-+ 569 | | | | 570 \\ // \\ // 571 ------ ------ 573 Figure 7: multiple underlay networks: Ethernet and IP 575 Figure 7 illustrates an example of Ethernet and IP network, very 576 common and easy for deployment based on existing network status, as 577 underlay networks. SF(Service Functions) A, B and C locate in 578 Ethernet and IP networks respectively. To build a Service Function 579 Chain of SF A, B and C, Service Function Chaining needs to support 580 steering traffic across Ethernet and IP underlay networks. 582 4.6. SFC over Service Path Forking 584 To enable service or content awareness, operators need DPI functions 585 to look into packets. When a DPI function is part of a Service 586 Function Chain, packets processed by the DPI function may be directed 587 to different paths according to result of DPI processing. That means 588 a forking service path. 590 In this use case, the switching SF is another classifier which need 591 to classify flow and shepherd them to different paths. 593 +---------+ +----------+ +----------+ 594 | | | | | | 595 -----| Firewall+<------>+ DPI +<------>+anti-virus|---- 596 | | | | | | 597 +---------+ +-----+----+ +----------+ 598 ^ 599 V 600 +-----+----+ 601 | | 602 | Parental | 603 | control | 604 +-----+----+ 605 | 606 V 608 Figure 8: a forking service path 610 Figure 8 shows the use case of a forking service path. Traffic first 611 goes through a firewall and then arrives at DPI function which 612 discerns virus risk. If a certain pre-configured pattern is matched, 613 the traffic is directed to an anti-virus function. 615 Such DPI function may fork out more than one path. 617 Service function sharing is sub-category of the service function 618 forking. Some carrier grade hardware box or Service Functions 619 running on high performance servers can be shared to support multiple 620 Service Function Chains. Following is an example. 622 SFC1 +---------+ +--------+ 623 ------->+---------+------->+--------+---> 624 SFC2 |Firewall | |Video | 625 ------->+-->+ | |Opt | 626 +---|-----+ +--------+ 627 | 628 v 629 +---+-----+ 630 | | | 631 |Parental | 632 |Control | 633 +---+-----+ 634 | 635 v 637 Figure 9: Two Service Function Chains share one Service Function 639 In Figure 9, there are three Service Functions, firewall, VideoOpt 640 and Parental Control, and two Service Functions Chains SFC1 and SFC2. 641 SFC1 serves broadband user group1 which subscribes to secure web 642 surfing and Internet video optimization, while SFC2 serves broadband 643 user group2 which subscribes to secure web surfing with parental 644 control. SF Firewall is shared by both Service Function Chains. 646 4.7. Recursive SFC 648 SFCs can be provided in a recursive manner. A Level 1 service 649 provider can sell SFC services to multiple clients. Each client can 650 further partition its SFC and serve as a Level 2 service provider to 651 sell differentiated SFCs to different clients. This process can 652 continue several iterations making recursive service a new business 653 model which is becoming popular today. 655 Consider a use case where an enterprise leases a virtual service 656 network from a data canter provider. The enterprise then creates two 657 service chains out of the virtual service network. The first service 658 chain, designed for its employees, will force traffic flows to go 659 through NAT, DPI, firewall, LB, and various servers. The second one, 660 designed for its customers, will only go through NAT and web servers. 661 Its customers can create specific websites for different departments 662 such as purchase department, service department, etc. 664 An important characteristic of recursive service is that each service 665 provider is a separate entity who owns the SFC it purchased from 666 lower level provider and who also decides the SFCs it creates for its 667 clients. 669 5. Security Considerations 671 This document does not define an architecture nor a protocol. It 672 focuses on listing use cases and typical Service Function examples. 673 Some of these functions are security-related. 675 SFC-related security considerations are discussed in 676 [I-D.ietf-sfc-architecture]. 678 6. Acknowledgements 680 Jie Hu and Zhen Cao contributed to an earlier version of this 681 document. 683 This document has benefited from reviews, suggestions, comments and 684 proposed text provided by the following members of the Service 685 Function Chaining Working Group(sfc WG), listed in alphabetical 686 order: David Binet, Hui Deng, Alla Goldner, Yuanlong Jiang, Jerome 687 Moisand, Lehong Niu, Ron Parker, and Lucy Yong. 689 7. Informative References 691 [I-D.ietf-sfc-architecture] 692 Halpern, J. and C. Pignataro, "Service Function Chaining 693 (SFC) Architecture", draft-ietf-sfc-architecture-01 (work 694 in progress), September 2014. 696 [I-D.ietf-sfc-dc-use-cases] 697 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 698 Homma, "Service Function Chaining Use Cases In Data 699 Centers", draft-ietf-sfc-dc-use-cases-01 (work in 700 progress), July 2014. 702 [I-D.ietf-sfc-use-case-mobility] 703 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 704 J. Uttaro, "Service Function Chaining Use Cases in Mobile 705 Networks", draft-ietf-sfc-use-case-mobility-01 (work in 706 progress), July 2014. 708 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 709 NAT64: Network Address and Protocol Translation from IPv6 710 Clients to IPv4 Servers", RFC 6146, April 2011. 712 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 713 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 714 Partnership Project (3GPP) Evolved Packet System (EPS)", 715 RFC 6459, January 2012. 717 [RFC6674] Brockners, F., Gundavelli, S., Speicher, S., and D. Ward, 718 "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674, 719 July 2012. 721 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 722 and H. Ashida, "Common Requirements for Carrier-Grade NATs 723 (CGNs)", BCP 127, RFC 6888, April 2013. 725 [TS.23203] 3GPP, "Policy and charging control architecture", December 726 2013. 728 Authors' Addresses 730 Will(Shucheng) Liu (editor) 731 Huawei Technologies 732 Bantian, Longgang District 733 Shenzhen 518129 734 P.R. China 736 Email: liushucheng@huawei.com 738 Hongyu Li 739 Huawei Technologies 740 Bantian, Longgang District 741 Shenzhen 518129 742 P.R. China 744 Email: hongyu.li@huawei.com 746 Oliver Huang 747 Huawei Technologies 748 Bantian, Longgang District 749 Shenzhen 518129 750 P.R. China 752 Email: oliver.huang@huawei.com 754 Mohamed Boucadair (editor) 755 France Telecom 756 Rennes 35000 757 France 759 Email: mohamed.boucadair@orange.com 760 Nicolai Leymann 761 Deutsche Telekom AG 763 Email: n.leymann@telekom.de 765 Qiao Fu 766 China Mobile 768 Email: fuqiao@chinamobile.com 770 Qiong Sun 771 China Telecom 772 No.118 Xizhimennei street, Xicheng District 773 Beijing 100035 774 P.R. China 776 Email: sunqiong@ctbri.com.cn 778 Chuong Pham 779 Telstra Corporation 780 Level 8, 18 Smith Street 781 Parramatta 2150 782 Australia 784 Email: Pham, Chuong D 786 Changcheng Huang 787 Carleton University 788 1125 Colonel By Drive 789 Ottawa ON K1S 5B6 790 Canada 792 Email: huang@sce.carleton.ca 794 Jiafeng Zhu 795 Huawei Technologies 796 Santa Clara,CA 797 US 799 Email: Jiafeng.zhu@huawei.com 800 Peng He 801 Ciena Corp 803 Email: phe@ciena.com