idnits 2.17.1 draft-ietf-sfc-use-case-mobility-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1100 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 9, 2015) is 3395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HSS' is mentioned on line 367, but not defined == Missing Reference: 'UE-C' is mentioned on line 293, but not defined == Missing Reference: 'S-GW-C' is mentioned on line 293, but not defined == Missing Reference: 'P-GW-C' is mentioned on line 293, but not defined == Missing Reference: 'UE-U' is mentioned on line 296, but not defined == Missing Reference: 'S-GW-U' is mentioned on line 296, but not defined == Missing Reference: 'P-GW-U' is mentioned on line 296, but not defined == Missing Reference: 'SGi-LAN' is mentioned on line 296, but not defined == Missing Reference: 'UE' is mentioned on line 312, but not defined == Missing Reference: 'P-GW' is mentioned on line 312, but not defined == Missing Reference: 'MME' is mentioned on line 367, but not defined == Missing Reference: 'PCRF' is mentioned on line 367, but not defined == Missing Reference: 'SFC 1' is mentioned on line 496, but not defined == Missing Reference: 'PCEF' is mentioned on line 496, but not defined == Missing Reference: 'TDF' is mentioned on line 498, but not defined == Missing Reference: 'SFC 3' is mentioned on line 498, but not defined == Missing Reference: 'Cache' is mentioned on line 554, but not defined Summary: 0 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining W. Haeffner 3 Internet-Draft Vodafone 4 Intended status: Informational J. Napper 5 Expires: July 13, 2015 Cisco Systems 6 M. Stiemerling 7 NEC 8 D. Lopez 9 Telefonica I+D 10 J. Uttaro 11 AT&T 12 January 9, 2015 14 Service Function Chaining Use Cases in Mobile Networks 15 draft-ietf-sfc-use-case-mobility-02 17 Abstract 19 This document provides some exemplary use cases for service function 20 chaining in mobile service provider networks. The objective of this 21 draft is not to cover all conceivable service chains in detail. 22 Rather, the intention is to localize and explain the application 23 domain of service chaining within mobile networks as far as it is 24 required to complement the problem statement 25 [ietf-sfc-problem-statement] and architecture framework 26 [ietf-sfc-arch] of the working group. 28 Service function chains typically reside in a LAN segment which links 29 the mobile access network to the actual application platforms located 30 in the carrier's datacenters or somewhere else in the Internet. 31 Service function chains (SFC) ensure a fair distribution of network 32 resources according to agreed service policies, enhance the 33 performance of service delivery or take care of security and privacy. 34 SFCs may also include Value Added Services (VAS). Commonly, SFCs are 35 typical middlebox services. 37 General considerations and specific use cases are presented in this 38 document to demonstrate the different technical requirements of these 39 goals for service function chaining in mobile service provider 40 networks. 42 The specification of service function chaining for mobile networks 43 must take into account an interaction between service function chains 44 and the 3GPP Policy and Charging Control (PCC) environment. 46 Requirements Language 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in [RFC2119]. 52 Status of This Memo 54 This Internet-Draft is submitted in full conformance with the 55 provisions of BCP 78 and BCP 79. 57 Internet-Drafts are working documents of the Internet Engineering 58 Task Force (IETF). Note that other groups may also distribute 59 working documents as Internet-Drafts. The list of current Internet- 60 Drafts is at http://datatracker.ietf.org/drafts/current/. 62 Internet-Drafts are draft documents valid for a maximum of six months 63 and may be updated, replaced, or obsoleted by other documents at any 64 time. It is inappropriate to use Internet-Drafts as reference 65 material or to cite them other than as "work in progress." 67 This Internet-Draft will expire on July 13, 2015. 69 Copyright Notice 71 Copyright (c) 2015 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of 81 the Trust Legal Provisions and are provided without warranty as 82 described in the Simplified BSD License. 84 Table of Contents 86 1. Introduction 87 1.1. Terminology and abbreviations 88 1.2. General scope of mobile service chains 89 1.3. General structure of end-to-end carrier networks 90 2. Mobile network overview 91 2.1. Building blocks of 3GPP mobile LTE networks 92 2.2. Overview of mobile service chains 93 2.3. The most common classification scheme 94 2.4. More sophisticated classification schemes 95 3. Example use cases specific to mobile networks 96 3.1. Service chain model for Internet HTTP services 97 3.1.1. Weaknesses of current approaches 98 3.2. Service chain for TCP optimization 99 3.2.1. Weaknesses of current approaches 100 3.3. HTTP header enrichment in mobile networks 101 4. Remarks on QoS in mobile networks 102 5. Weaknesses of current implementations 103 5.1. Granularity of the classification scheme 104 5.2. Service chain implementations 105 6. Operator requirements 106 6.1. Simplicity of service function chain instantiation 107 6.2. Extensions 108 6.3. Reflections on Metadata 109 6.4. Delimitations 110 7. Security Considerations 111 8. IANA Considerations 112 9. Acknowledgments 113 10. References 114 10.1. Normative References 115 10.2. Informative References 116 Authors' Addresses 118 1. Introduction 120 1.1. Terminology and abbreviations 122 Much of the terminology used in this document has been defined by the 123 3rd Generation Partnership Project (3GPP), which defines standards 124 for mobile service provider networks. Although a few terms are 125 defined here for convenience, further terms can be found in 126 [RFC6459]. 128 UE User equipment like tablets or smartphones 130 eNB enhanced NodeB, radio access part of the LTE system 132 S-GW Serving Gateway, primary function is user plane mobility 134 P-GW Packet Gateway, actual service creation point, terminates 3GPP 135 mobile network, interface to Packet Data Networks (PDN) 137 HSS Home Subscriber System (control plane element) 139 MME Mobility Management Entity (control plane element) 141 GTP GPRS (General Packet Radio Service) Tunnel Protocol 143 S-IP Source IP address 145 D-IP Destination IP address 147 IMSI The International Mobile Subscriber Identity that identifies a 148 mobile subscriber 150 (S)Gi Egress termination point of the mobile network (SGi in case of 151 LTE, Gi in case of UMTS/HSPA). The internal data structure of 152 this interface is not standardized by 3GPP 154 PCRF 3GPP standardized Policy and Charging Rules Function 156 PCEF Policy and Charging Enforcement Function 158 IDS Intrusion Detection System 160 FW Firewall 162 ACL Access Control List 164 PEP Performance Enhancement Proxy 166 1.2. General scope of mobile service chains 168 Mobile access networks terminate at a mobile service creation point 169 (Packet Gateway) typically located at the edge of an operator IP 170 backbone. From the user equipment (UE) up to the Packet Gateway 171 (P-GW) everything is fully standardized by the 3rd Generation 172 Partnership Project (3GPP) e.g., in [TS.23.401]. Within the mobile 173 network, the user payload is encapsulated in 3GPP specific tunnels 174 terminating eventually at the P-GW. In many cases application- 175 specific IP traffic is not directly exchanged between the original 176 mobile network, more specific the P-GW, and an application platform, 177 but will be forced to pass a set of service functions. Those 178 application platforms are, for instance, a web server environment, a 179 video platform, a social networking platform or some other multimedia 180 platform. Network operators use these service functions to 181 differentiate their services to their subscribers. Service function 182 chaining is thus integral to the business model of operators. 184 Important use cases classes for service function chains generally 185 include: 187 1. functions to protect the carrier network and the privacy of its 188 users(IDS, FW, ACL, encryption, decryption, etc.), 190 2. functions that ensure the contracted quality of experience using 191 e.g., performance enhancement proxies (PEP) like video 192 optimizers, TCP optimizers or functions guaranteeing fair service 193 delivery based on policy based QoS mechanisms, 195 3. functions like HTTP header enrichment that may be used to 196 identify and charge subscribers real time, 198 4. functions like CG-NAT/PAT, which are required solely for 199 technical reasons, and 201 5. functions like parental control or malware detection that may be 202 a cost option of a service offer. 204 1.3. General structure of end-to-end carrier networks 206 Although this memo is focused on the Service Function Chaining use 207 cases for mobile carrier networks, such as 3GPP- based ones, a number 208 of other, different carrier networks exists that share similarities 209 in the structure of the access networks and the service functions 210 with mobile networks. 212 Figure 1 shows a simplified schematic view of 4 different access 213 service networks to indicate similarities with respect to Service 214 Functions and their Chaining. These service networks consist of 215 access-specific user equipment, a dedicated access network, a related 216 service creation point and finally a (LAN) infrastructure hosting 217 Service Functions which eventually interconnect to application 218 platforms in the Internet or in the carrier's own datacenter (DC). 219 From top to down, there is a 3GPP mobile network terminating at the 220 P-GW, a xDSL network with its PPP tunnels terminating at a BNG 221 (Broadband Network Gateway), a FTTH network terminating at an OLT 222 (Optical Line Terminal) and finally a cable TV network terminating at 223 a CMTS (Cable Modem Termination System). 225 Access Service Functions (Categories) 226 Services +---------------------------+ 227 +--+ *~~~~~~~* +-----+ |+--1---+ +--2---+ +--3---+|| +---------+ 228 |UE|--| 3GGP |---| P-GW|--|| NAT | | MWD | | TCP || |Internal | 229 +--+ *~~~~~~~* +-----+ || . | | | | Opt. ||-|Appl. | 230 || FW | | Par. | | . || |Platforms| 231 +--+ *~~~~~~~* +-----+ || . | | Ctrl | | Video || |(e.g.IMS)| 232 |UE|--| xDSL |---| BNG |--|| LB | | . | | Opt. || +---------+ 233 +--+ *~~~~~~~* +-----+ || . | | LI | | . || 234 || DPI | | . | | Head. || 235 +--+ *~~~~~~~* +-----+ || . | | . | | Enr. || +---------+ 236 |UE|--| FTTH |---| OLT |--|| . | | | | . || | | 237 +--+ *~~~~~~~* +-----+ || . | | | | . || | | 238 || . | | | | ||-|Internet | 239 +--+ *~~~~~~~* +-----+ || | | | | || | | 240 |UE|--| CATV |---| CMTS|--|| | | | | || | | 241 +--+ *~~~~~~~* +-----+ |+------+ +------+ +-------+| +---------+ 242 +---------------------------+ 244 Figure 1: Various end-to-end carrier networks and service functions 245 sorted into categories 1, 2 and 3. 247 Category 1 of service functions like NAT or DPI may be used by all of 248 these service networks mainly just (but not exclusively) for 249 technical reasons. The same is true for category 2, Value Added 250 Services (VAS) like parental control, malware detection and 251 elimination (MWD) or Lawful Interception (LI). TCP optimization is 252 basically only seen in mobile networks only. The same may be true 253 for video optimizers or HTTP header enrichment; i.e., category 3 as a 254 rule mainly belongs to mobile networks only. 256 In our view, 3GPP-based mobile networks seem to have the largest 257 demand for service functions and service function chains. Service 258 Function Chains used in other access networks are very likely a 259 subset of what one can expect in 3GPP-based mobile networks. 261 Typical data center use cases are described in 262 [ietf-sfc-dc-use-cases]. Some technical aspects for the handling of 263 long-lived flows are discussed in 264 [ietf-sfc-long-lived-flow-use-cases]. 266 2. Mobile network overview 268 For simplicity we only describe service function chaining in the 269 context of LTE (Long Term Evolution) networks. But indeed our 270 service chaining model also applies to earlier generations of mobile 271 networks, such as purely UMTS-based mobile networks. 273 2.1. Building blocks of 3GPP mobile LTE networks 275 The major functional components of a LTE network are shown in 276 Figure 2 and include user equipment (UE) like smartphones or tablets, 277 the LTE radio unit named enhanced NodeB (eNB), the serving gateway 278 (S-GW) which together with the mobility management entity (MME) takes 279 care of mobility and the packet gateway (P-GW), which finally 280 terminates the actual mobile service. These elements are described 281 in detail in [TS.23.401]. Other important components are the home 282 subscriber system (HSS) and the policy and charging rule function 283 (PCRF), which are described in [TS.23.203]. The P-GW interface 284 towards the SGi-LAN is called the SGi-interface, which is described 285 in [TS.29.061]. Finally, the SGi-LAN is the home of service function 286 chains (SFC), which are not standardized by 3GPP. 288 +--------------------------------------------+ 289 | Control Plane (C) [HSS] | [OTT Appl. Platform] 290 | | | | 291 | +--------[MME] [PCRF]--+--------+ Internet 292 | | | | | | | 293 | [UE-C] -- [eNB-C] == [S-GW-C] == [P-GW-C] | | | 294 +=====|=========|==========|============|====+ +-----+----+-------+ 295 | | | | | | | | | | 296 | [UE-U] -- [eNB-U] == [S-GW-U] == [P-GW-U]-+--+----[SGi-LAN] | 297 | | | | | 298 | | | | | 299 | | | [Appl. Platform] | 300 | | | | 301 | User Plane (U) | | | 302 +--------------------------------------------+ +------------------+ 304 |<---------- 3GPP Mobile Network -------->| |<-- IP Backbone ->| 306 Figure 2 shows the end to end context including all major components 307 of a LTE network. The actual 3GPP mobile network includes the 308 elements from the user equipment [UE] to the packet gateway [P-GW]. 310 Figure 2: End to end context including all major components of a LTE 311 network. The actual 3GPP mobile network includes the elements from 312 the user equipment [UE] to the packet gateway [P-GW]. 314 The radio-based IP traffic between the UE and the eNB is encrypted 315 according 3GPP standards. Between eNB, S-GW and P-GW user IP packets 316 as well as control plane packets are encapsulated in 3GPP-specific 317 tunnels. In some mobile carrier networks the 3GPP-specific tunnels 318 between eNB and S-GW are even additionally IPSec-encrypted. More 319 precisely, IPSec originates/terminates at the eNB and on the other 320 side at an IPSec-GW often placed just in front of the S-GW. For more 321 details see [TS.29.281], [TS.29.274] and [TS.33.210]. 323 Service function chains act on user plane IP traffic only. But the 324 way these act on user traffic may depend on subscriber, service or 325 network specific control plane metadata. 327 2.2. Overview of mobile service chains 329 The original user IP packet, including the Source-IP-Address (S-IP) 330 of the UE and the Destination-IP-Address (D-IP) of the addressed 331 application platform, leaves the Packet Gateway from the mobile 332 network via the so-called Gi-interface (3G service, e.g., UMTS) 333 respectively SGi-interface (4G service, e.g., LTE). Between this 334 (S)Gi-interface and the actual application platform the user 335 generated upstream IP packets and the corresponding downstream IP 336 packets are typically forced to pass an ordered set of service 337 functions, loosely called a Service Function Chain (SFC). 339 The set of all available service functions (physical or virtualized) 340 which can be used to establish different Service Function Chains for 341 different services is often called a Gi-LAN for 2G/3G services and 342 SGi-LAN for 4G services. 344 The (S)Gi-interface towards the (S)Gi-LAN itself is discussed in 345 [TS.29.061], but service function chaining is not specified by 3GPP. 347 The (S)Gi-LAN service functions can use subscriber and service 348 related metadata delivered from the mobile control plane, such as the 349 PCRF, or from the user plane e.g., via HTTP Header Enrichment to 350 process the flows according to service related policies. Some 351 service functions may even use network performance data describing 352 the actual momentary state of a network segment. 354 In short, the (S)Gi-LAN service area is presently used by mobile 355 service providers to differentiate their services to their 356 subscribers and reflect the business model and of mobile operators. 358 For different applications (e.g., Appl. 1,2,3) upstream and 359 downstream user plane IP flows will be forced to pass a sequence of 360 service functions which is called a Service Function Chain specific 361 to a given application. In the simple example sketched in Figure 3, 362 the service chains for applications 1, 2 and 3 may be just classified 363 by a unique interface-ID of the egress P-GW interfaces where the 364 service chains for application 1, 2 and 3 are attached. 366 +------------------------------------------------------------------+ 367 | Control Plane Environment [HSS] [MME] [PCRF] [others] | 368 +------------------------------------------------|-----------------+ 369 +--------------------+ 370 +---------------------------|--------------------|-----------------+ 371 | User Plane Environment | | | 372 | | +------(S)Gi-LAN --+-----+ | 373 | | | | | 374 | | | +---[SF1]-[SF3]-[SF5]---[Appl. 1] | 375 | | | / | | 376 | [UE]---[eNB]===[S-GW]===[P-GW]-----[SF2]-[SF4]-[SF6]--------+ | 377 | | \ | | | 378 | | +---[SF7]-[SF8]-[SF9]-----+ | | 379 | | | | | | 380 | +------------------------+ | | | 381 | | | | 382 +----------------------------------------------------------|--|----+ 383 | | 384 OTT Internet Applications 385 | | 386 [Appl. 2] [Appl. 3] 388 Figure 3: Typical service chain topology. 390 Service functions typically observe, alter or even terminate and re- 391 establish application session flows between mobile user equipment and 392 application platforms. Control plane metadata supporting policy 393 based traffic handling may be linked to individual service functions 394 SFn. Because in Figure 3 the P-GW classifies service chains, we 395 consider the P-GW as a component of the service chaining environment. 396 However, more sophisticated classification schemes are possible and 397 discussed later. 399 Care must be taken in classifying and directing flows in different 400 directions (upstream versus downstream) or different flows from the 401 same subscriber when Service Functions observe or alter session 402 flows. Such functions can maintain local state that is necessary to 403 the correct functioning of session flows (e.g., non-transparent 404 proxies) or to enforcing the policies of the service provider (e.g., 405 fair-use policies). Such stateful service functions can require 406 steering both upstream and downstream directions of a flow through a 407 single service function instance (e.g., from a set of identical 408 service function instances deployed for scale) or for steering all 409 flows with a common criteria (e.g., belonging to the same subscriber) 410 through such a single service function instance. 412 2.3. The most common classification scheme 414 Mobile user equipment like smartphones, tablets or other mobile 415 devices address use Access Point Names (APNs) to address a service 416 network or service platform. APNs are DNS host names and comparable 417 to FQDN host names. While a FQDN refers to an Internet IP address, 418 an APN (loosely speaking) specifies a P-GW IP address. These APNs 419 are used to distinguish certain user groups and their traffic, e.g., 420 there can be an APN for a mobile service offered to the general 421 public while enterprise customers get their own APN. For APN details 422 see [TS.23.003]. 424 Operators often associate a designated VLAN-ID with an APN. A VLAN- 425 ID n then may classify the service function chain n (SFC n) related 426 to an application platform n (Appl. n), as shown in the following 427 Figure 4. 429 +----------+ 430 | | 431 | IF-1 O [APN 1 => VLAN-ID 1] ---- [SFC 1] ---- [Appl. 1] 432 | | 433 =====| P-GW O . . . . 434 | | 435 | IF-n O [APN n => VLAN-ID n] ---- [SFC n] ---- [Appl. n] 436 | | 437 +----------+ 439 Figure 4: Association of a service chain to an application platform. 441 Examples for an APN are, e.g.: 443 +------------+-----------------+ 444 | APN: | web.vodafone.de | 445 | User Name: | not required | 446 | Password: | not required | 447 +------------+-----------------+ 449 Table 1: Example APN for Vodafone Germany 451 +------------+------------------+ 452 | APN: | internet.telekom | 453 | User Name: | t-mobile | 454 | Password: | tm | 455 +------------+------------------+ 457 Table 2: Example APN for Deutsche Telekom/T-Mobile 459 2.4. More sophisticated classification schemes 461 More sophisticated classifications are feasible using metadata that 462 is UE related, subscriber and service related, as well as network 463 related metadata. Typical metadata and their sources are: 465 UE: terminal type (e.g., HTC one), IMSI (country, carrier, user) 467 GTP tunnel endpoint: eNB-Identifier, time, and many more 469 PCRF: subscriber info, APN (service name), QoS, policy rules 471 Mobile operator defined subscriber, service or network specific 472 policies are typically encoded in the 3GPP-based Policy and Charging 473 Rules Function (PCRF), see [TS.23.203]. For instance, a PCRF may 474 encode the rules that apply to pre-paid and post-paid users, users 475 with a classification of gold, silver, or bronze, or even as detailed 476 as describing rules that apply to "gold users, wishing to download a 477 video file, while these subscribers are subjected to a fair-usage 478 policy". It is up to the mobile service providers to encode the 479 precise mappings between its subscriber classes and the associated 480 service chains. 482 The Traffic Detection Function (TDF) is part of the 3GPP PCC (Policy 483 and Charging Architecture, [TS.23.203]). Such a TDF inspects the 484 user traffic after leaving the P-GW function (see Figure 4). The TDF 485 can be used to classify traffic originating from an APN into more 486 detailed services. This could be used to classify traffic into 487 different Service Functions. 489 +-------------------------+ 490 | PCRF | 491 +----+--------------+-----+ 492 | | 493 Gx-IF Sd-IF 494 | | 495 +----+-----+ +----+-----+ 496 ==========O [PCEF] | | O--------[SFC 1] ---- [Appl. 1] 497 | | | O--------[SFC 2] ---- [Appl. 2] 498 ==========O P-GW O---O [TDF] O--------[SFC 3] ---- [Appl. 3] 499 | | | O--------[SFC 4] ---- [Appl. 4] 500 ==========O | | O--------[SFC n] ---- [Appl. n] 501 +----------+ +----------+ 502 * * 503 3GPP Bearer SGi SGi 505 Figure 5: 3GPP Traffic Detection Function (TDF) for classification. 506 The Policy and Charging Enforcement Function (PCEF) enforces policies 507 received from the PCRF and, in the other direction, provides the PCRF 508 with subscriber and access information via Gx interface. 510 The TDF will typically observe the traffic on all layers. On 511 application start and stop the TDF provides feedback to the PCRF for 512 further actions to be taken on a particular flow. The PCRF can 513 request that the TDF apply application and detection controls to 514 application flows including charging and usage monitoring. The TDF 515 can also act without any interaction with the PCRF taking care of 516 gating (firewalling), traffic redirection, bandwidth management or 517 charging. 519 3. Example use cases specific to mobile networks 521 Because HTTP via TCP port 80 (or TCP port 443 for HTTPS) is by far 522 the most common Internet traffic class, we discuss two typical 523 examples of an associated service function chaining model in some 524 more detail. 526 The models presented below are simplified compared to real life 527 service function chain implementations because we do not discuss 528 differentiated traffic handling based on different subscriber- 529 specific service level agreements and price plans or even actual 530 network load conditions. 532 3.1. Service chain model for Internet HTTP services 534 With the increase of Internet traffic in mobile networks mobile 535 operators have started to introduce Performance Enhancement Proxies 536 (PEPs) to optimize network resource utilization. PEPs are more or 537 less integrated platforms that ensure the best possible Quality of 538 Experience (QoE). Their service functions include but are not 539 limited to Deep Packet Inspection (DPI), web and video optimizations, 540 subscriber and service policy controlled dynamic network adaption, 541 analytics and management support. 543 A simple service function chain model for mobile Internet upstream 544 and downstream traffic is shown in Figure 6 below. The function 545 chain includes Load Balancers (LB), which split HTTP over TCP port 80 546 away from the rest of the internet traffic. Beside basic web 547 content, this traffic class includes more and more video. To act on 548 this traffic type we force this traffic to pass Performance 549 Enhancement Proxies. The firewall function (FW) protects the carrier 550 network from the outside and Network Address Translation (NAT) maps 551 the private IP address space dedicated to user equipment to a public 552 IP address. 554 [Cache] 555 | 556 [P-GW]---[LB]-----------[PEP]--[LB]--[FW]---[NAT]---[Internet] 557 | HTTP:80 | 558 | | 559 | | 560 | non HTTP:80 | 561 +---------------------+ 563 Figure 6: Service function chain for HTTP traffic over TCP port 80. 565 The first application in this Service Chain example caches web 566 content to help reduce Round Trip Times (RTT) and therefore 567 contribute to improved web page load times. Optimizing RTT and 568 thereby improving Quality of Experience (QoE) is generally more 569 important for mobile service providers than reducing Internet peering 570 costs. Similar arguments hold for cached video content. We avoid 571 potential large jitter imported from the Internet. 573 An example for non HTTP:80 traffic in Figure 6 is UDP-encapsulated 574 IPsec traffic, which is dedicated to port 10000. Note that in a real 575 environment not only port 80 but for example additional traffic via 576 port 8080, 25 for SMTP, 110 for POP3 or 143 for IMAP may be forced to 577 pass a service chain. 579 A second application is video optimization. Video content from the 580 Internet may not fit to the size of mobile device displays or simply 581 would overload the mobile network when used natively. Therefore 582 mobile operators adapt internet-based video content to ensure the 583 best QoE. 585 Video content optimization very often is also an additional premium- 586 related component in service offers and price plans. 588 Our PEP environment for video optimization consists of three basic 589 service functions shown in Figure 7: a steering proxy which is able 590 to redirect HTTP traffic, a DPI-based controller which checks for 591 video content and an optimizer which transcodes videos to an 592 appropriate format on the fly in real time. 594 [PEP for video] ==>> [Steering Proxy]---[DPI Contr.]---[Optimizer] 596 Figure 7: Service functions required for video optimization. 598 In Figure 8 we show the detailed HTTP flows and their redirection in 599 some more detail. The intention here is to show every elementary 600 functional step in a chain as a separate physical or virtualized 601 item, but this state diagram must not necessarily reflect every 602 existing vendor-specific proprietary implementation. 604 Specifically, the Steering Proxy includes a TCP proxy and an ICAP 605 client which communicates with an ICAP server residing in the 606 controller function which is supported by a L7 DPI. 608 The video optimization process acts on the downstream flow only. 610 [UE]----[Steering Proxy]----[DPI Contr.]----[Optimizer]----[Content] 612 |-- HTTP GET ->|-------------- HTTP GET ----------------------->| 614 |<------------- HTTP Response -------------------| 616 |-- Is it Video? ->| 618 |<-- Video found --| 620 |<--- HTTP ----| 621 Redirect 623 |-- HTTP GET ->|-----HTTP GET ---------------->| 625 |-- HTTP GET -->| 626 Video 628 |<--- HTTP -----| 629 Response 630 Orig. Video 632 {Optimize} 634 |<------- HTTP Response --------| 635 Transcoded Video 637 |-- Is it Video? ->| 639 |<-- Video found --| 641 |<--- HTTP ----| 642 Response 643 Transcoded Video 645 Figure 8: Flow diagram between UE and video optimization PEP. 647 In such an application scenario one can have reclassification or off- 648 loading on the fly. 650 Assume a video streams within a 4G LTE radio cell. The video 651 optimizer would then apply a transcoding scheme appropriate to the 652 abilities of the 4G network. If one is now leaving the 4G cell and 653 entering a 3G radio cell, the network conditions will most probably 654 become different and the video optimizer has to use another 655 transcoding scheme to keep a certain QoE. This requires that the 656 video optimizer service function is aware of the Radio Access 657 Technology (RAT) in use. One may transfer RAT type from the P-GW (or 658 GGSN in case of 3G traffic) via an AAA Proxy to the service function 659 chain. The RAT information will then be embedded in an appropriate 660 Radius message. Other 3GPP steering mechanisms may apply as well. 662 If for example the 4G network has sufficient bandwidth, one could 663 also think of another, different use case. The rule could be that 664 only 3G video streams are forced to pass the video optimizer while 665 all 4G video traffic will be bypassed. 667 Additionally, network utilization information can be used to trigger 668 the behavior of the service function. The degree of video 669 compression applied could depend on the actual current network load. 671 Last but not least the behavior of the video optimizer service 672 function (or any other service function) could additionally depend on 673 the user-specific service contract (price plan, gold, silver, bronze) 674 or on individual on demand requests. 676 3.1.1. Weaknesses of current approaches 678 This use case model highlights the weakness of current service 679 deployments in the areas of traffic selection, reclassification, and 680 multi-vendor support. Traffic in this example is classified after 681 the P-GW and separated into separate flows based on whether it is (in 682 this example) TCP traffic destined to port 80. This classification 683 could be done by the load balancer (see Figure 6) if it initiates the 684 service chain selection, or the traffic can be reclassified at the 685 load balancer if the traffic is already embedded in a Service Chain 686 (e.g., when combined with other functions such as the TCP 687 optimization in the following use case). Multi-vendor support is 688 needed because every element in the use case can be provided by a 689 different vendor: load-balancer, HTTP proxy, firewall, and NAT. 691 3.2. Service chain for TCP optimization 693 The essential parameters influencing TCP behavior are latency, packet 694 loss and available throughput. 696 Content servers are mostly attached to fixed networks. These are 697 characterized by high bandwidth and low latency. On the other side, 698 Radio Access Networks (RANs) tend to have higher latency, packet 699 loss, and congestion. 701 The fixed network part will typically get a TCP Rx/Tx buffer size 702 different to that one on the radio network side, because buffer sizes 703 are typically set proportional to the latency (rule of thumb: 2x 704 latency x bandwidth). 706 TCP cannot handle such disparate end-to-end situations very well. 707 One way to mitigate this problem is to use split TCP. However, even 708 without congestion, packet losses on the mobile network side may 709 result in time outs and finally can cause the content server on the 710 fixed network side to stall. 712 Therefore mobile operators often use TCP optimization proxies in the 713 data path. These proxies monitor latency and throughput real-time 714 and dynamically optimize TCP parameters for each TCP connection to 715 ensure a better transmission behavior. 717 A rudimentary service chain setup for TCP optimization is shown in 718 Figure 9. Examples of non TCP flows are UDP/RTP voice or video 719 traffic. 721 [P-GW]---[LB]----------[TCP Opt.]---[LB]---[FW]---[NAT]---[Internet] 722 | TCP | 723 | | 724 | non-TCP | 725 +--------------------------+ 727 Figure 9: Optimizing TCP parameterization in a mobile network. 729 3.2.1. Weaknesses of current approaches 731 This use case highlights weaknesses of current service deployments in 732 the areas of traffic selection, reclassification, and multi-vendor 733 support as in the previous use case presented in Section 3.1. 735 3.3. HTTP header enrichment in mobile networks 737 In legacy mobile networks WAP (Wireless Application Protocol) 738 gateways mediated between traditional mobile phones and the Internet 739 translating HTML web content into a WML (Wireless Markup Language) 740 and vice versa. By functionality, WAP-GWs fit also in the SFC 741 category. 743 Traditionally WAP-GWs use HTTP header enrichment to insert subscriber 744 related data into WAP and HTTP request headers in real time. These 745 data were (are) used to identify and charge subscribers on third 746 party web sites. 748 Today 3G and 4G mobile networks HTTP header enrichment is done by the 749 GGSN/P-GW or a dedicated transparent HTTP optimizer as most of the 750 data traffic on a mobile network no longer passes a WAP-GW. 752 Information typically added to the header includes: 754 o Charging Characteristics 756 o Charging ID 758 o Subscriber ID 760 o GGSN or PGW IP address 762 o Serving Gateway Support Node (SGSN) or SGW IP address 764 o International Mobile Equipment Identity (IMEI) 766 o International Mobile Subscriber Identity (IMSI) 768 o Mobile Subscriber ISDN Number (MSISDN) 770 o UE IP address 772 4. Remarks on QoS in mobile networks 774 As indicated in Figure 3, service functions may be linked to the 775 control plane to take care of additional subscriber or service 776 related metadata. In many cases the source of metadata would be the 777 PCRF and the link would be a Gx or Diameter-based Sd interface. 778 Diameter is specified in [RFC6733] and Gx in [TS.29.212]. 780 Service functions within the SGi/Gi-LAN are less focused on the 781 explicit QoS steering of the actual mobile wireless network. QoS in 782 mobile networks is based on the 3GPP "Bearer" concept. A Bearer is 783 the essential traffic separation element enabling traffic separation 784 according to different QoS settings and represents the logical 785 transmission path between the User Equipment (UE) and the Packet 786 Gateway (P-GW). 788 5. Weaknesses of current implementations 790 In many operator environments every new service introduction can 791 result in a further dedicated (S)Gi-LAN service chain, because 792 service chaining has been deployed historically in an ad hoc manner. 794 It typically requires placement of new functions in the operator's 795 data center, changing the actual wiring to include any new or changed 796 service function, configuration of the functions and network 797 equipment, and finally testing of the new configuration to ensure 798 that everything has been properly setup. 800 5.1. Granularity of the classification scheme 802 Often the coarse grained classification according to APNs is not fine 803 enough to uniquely select a service function chain or a processing 804 scheme within a service function chain required to support the 805 typical user-, service- or network- related policies which the 806 operator likes to apply to a specific user plane flow. 808 It is very likely that an APN, such as shown in Section 2.3, is 809 carrying an extremely diverse set of user traffic. This can range 810 from HTTP web traffic to real-time traffic. 812 5.2. Service chain implementations 814 In many carrier networks service chain LANs grow incrementally 815 according product introductions or product modifications. This very 816 often ends in a mix of static IP links, policy based routing or 817 individual VRF implementations etc. to enforce the required sequence 818 of service functions. Major weak points seen in many carrier 819 networks are: 821 o Very static service chain instances, hard-wired on the network 822 layer leads to no flexibility with respect to reusing, adding, and 823 removing service nodes and reprogramming service chains. 825 o Evolutionary grown "handcrafted" connectivity models require high 826 complexity to manage or maintain. 828 o Basic implementation paradigm is based on APNs (that is service 829 types) only, which requires individual injections of context- 830 related metadata to obtain granularity down to user/service level. 832 o There is currently no natural (or standardized) information 833 exchange on network status between services and the network, 834 complicating management of network resources based on subscriber 835 profiles. 837 o It is currently practically impossible to implement an automated 838 service provisioning and delivery platform. 840 o Scaling up flows or service chains with service or subscriber 841 related metadata is extremely diffcult. 843 6. Operator requirements 845 Mobile operators use service function chains to enable and optimize 846 service delivery, offer network related customer services, optimize 847 network behavior or protect networks against attacks and ensure 848 privacy. Service function chains are essential to their business. 849 Without these, mobile operators are not able to deliver the necessary 850 and contracted Quality of Experience (QoE) or even certain products 851 to their customers. 853 6.1. Simplicity of service function chain instantiation 855 Because product development cycles are very fast in mobile markets, 856 mobile operators are asking for service chaining environments which 857 allow them to instantly create or modify service chains in a very 858 flexible and very simple way. The creation of service chains should 859 be embedded in the business and operation support layers of the 860 company and on an abstract functional level, independent of any 861 network underlay. No knowledge about internetworking technology 862 should be required at all. The mapping of the functional model of a 863 service chain onto the actual underlay network should be done by a 864 provisioning software package similar to that shown in Figure 10. 865 Details of the architecture and design are the subject of forthcoming 866 standards and proprietary implementation details. 868 +------------------------------------------------------------------+ 869 | Creation of an abstract service function chain | 870 +------------------------------------------------------------------+ 871 | 872 V 873 +------------------------------------------------------------------+ 874 | +----------------------------------------------------+ | 875 | | Service function chain compiler | | 876 | +----------------------------------------------------+ | 877 | | | 878 | V | 879 | +----------------------------------------------------+ | 880 | | Mediation device | | 881 | +----------------------------------------------------+ | 882 +------------------------------------------------------------------+ 883 | 884 V 885 +------------------------------------------------------------------+ 886 | Physical network underlay | 887 +------------------------------------------------------------------+ 889 Figure 10: Creation and provisioning system for service function 890 chains. 892 Service functions can be physical or virtualized. In the near future 893 the majority of mobile service functions will typically reside in the 894 local cloud computing environment of a mobile core location. 895 Nevertheless, first trials have shown that (virtualized) Service 896 Function interconnects via WAN links require careful latency 897 considerations. 899 Last but not least, any implementation must take into account that in 900 the migration phase a mixed infrastructure including virtual machines 901 and bare metal based systems must be supported. 903 6.2. Extensions 905 A service function chain should be generalized by a directed graph 906 where the vertices (nodes) represent an elementary service function. 907 This model allows branching conditions at the vertices. Branching in 908 a graph could then be triggered by typical 3GPP specified mobile 909 metadata (see Section 2.3) and allow for more sophisticated steering 910 methods in a service chain. Typically this data will be injected by 911 the mobile control plane, commonly by the PCRF via a Diameter-based 912 3GPP Sd interface. 914 Service chain behavior and output should additionally depend on 915 actual network conditions. For example, the selection of a video 916 compression format could depend on the actual load of the mobile 917 network segment a mobile user is attached to. That is to say that 918 classification of flows may allow very dynamic inputs while 919 specification of such inputs from a 3GPP network will need to be done 920 by 3GPP or another standards body. 922 Although necessary metadata can be obtained from the PCRF, to avoid 923 Diameter signaling storms in the (S)Gi-LAN, individual service 924 functions should probably not be attached individually to the control 925 plane. A mechanism where such metadata is carried by a metadata 926 header can reduce requests to the PCRF, provided these extensions do 927 not increase the original payload size too much. 929 6.3. Reflections on Metadata 931 At the moment we see just two types of metadata classes. Metadata 932 which are static and related to subscriber and service policies 933 residing typically in the control plane environment and dynamic 934 metadata, which may reflect time and location dependent status 935 somewhere in the network or other service platforms, e.g., load 936 conditions or relevant network technology indicators. It may be 937 useful to have proper interfaces to inject these metadata into the 938 Service Function Chain domain. 940 Summarized, metadata may by injected into individual Service Chain 941 Functions: 943 o asynchronously from the control plain environment by means of 944 individual standardized interfaces, 946 o synchrounously, piggypacked with the user IP packet: 948 * by means of a to-be-defined metadata header 950 * or carried with http header enrichements within the user 951 payload. 953 6.4. Delimitations 955 A clear separation between service chaining functionality and 3GPP 956 bearer handling is required. This may be subject of forthcoming 957 studies. 959 7. Security Considerations 961 Organizational security policies must apply to ensure the integrity 962 of the SFC environment. 964 8. IANA Considerations 966 This document has no actions for IANA. 968 9. Acknowledgments 970 We thank Peter Bosch, Carlos Correia, Dave Dolson, Linda Dunbar, Alla 971 Goldner, Wim Hendericks, Konstantin Livanos, Praveen Muley, Ron 972 Parker, and Nirav Salot for valuable discussions and contributions. 974 10. References 976 10.1. Normative References 978 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 979 Requirement Levels", BCP 14, RFC 2119, March 1997. 981 10.2. Informative References 983 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 984 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 985 Partnership Project (3GPP) Evolved Packet System (EPS)", 986 RFC 6459, January 2012. 988 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 989 "Diameter Base Protocol", RFC 6733, October 2012. 991 [TS.23.003] 992 "Numbering, addressing and identification", 3GPP TS 23.003 993 12.1.0, December 2013. 995 [TS.23.203] 996 "Policy and charging control architecture", 3GPP TS 23.203 997 12.3.0, December 2013. 999 [TS.23.401] 1000 "General Packet Radio Service (GPRS) enhancements for 1001 Evolved Universal Terrestrial Radio Access Network 1002 (E-UTRAN) access", 3GPP TS 23.401 12.3.0, December 2013. 1004 [TS.29.061] 1005 "Interworking between the Public Land Mobile Network 1006 (PLMN) supporting packet based services and Packet Data 1007 Networks (PDN)", 3GPP TS 29.061 12.4.0, December 2013. 1009 [TS.29.212] 1010 "Policy and Charging Control (PCC); Reference points", 1011 3GPP TS 29.212 13.0.0, January 2015. 1013 [TS.29.274] 1014 "3GPP Evolved Packet System (EPS); Evolved General Packet 1015 Radio Service (GPRS) Tunnelling Protocol for Control plane 1016 (GTPv2-C); Stage 3", 3GPP TS 29.274 12.3.0, December 2013. 1018 [TS.29.281] 1019 "General Packet Radio System (GPRS) Tunnelling Protocol 1020 User Plane (GTPv1-U)", 3GPP TS 29.281 11.6.0, March 2013. 1022 [TS.33.210] 1023 "3G security; Network Domain Security (NDS); IP network 1024 layer security", 3GPP TS 33.210 12.2.0, December 2012. 1026 [ietf-sfc-arch] 1027 and , "Service Function Chaining (SFC) Architecture", I-D 1028 draft-ietf-sfc-architecture-03 (work in progress), January 1029 2015. 1031 [ietf-sfc-dc-use-cases] 1032 , , , , and , "Service Function Chaining Use Cases In Data 1033 Centers", I-D draft-ietf-sfc-dc-use-cases-01 (work in 1034 progress), July 2014. 1036 [ietf-sfc-long-lived-flow-use-cases] 1037 , , , , and , "SFC Long-lived Flow Use Cases", I-D draft- 1038 ietf-sfc-long-lived-flow-use-cases-01 (work in progress), 1039 December 2014. 1041 [ietf-sfc-problem-statement] 1042 and , "Service Function Chaining Problem Statement", I-D 1043 draft-ietf-sfc-problem-statement-10 (work in progress), 1044 August 2014. 1046 Authors' Addresses 1048 Walter Haeffner 1049 Vodafone 1050 Vodafone D2 GmbH 1051 Ferdinand-Braun-Platz 1 1052 Duesseldorf 40549 1053 DE 1055 Phone: +49 (0)172 663 7184 1056 Email: walter.haeffner@vodafone.com 1058 Jeffrey Napper 1059 Cisco Systems 1060 Cisco Systems, Inc. 1061 Haarlerbergweg 13-19 1062 Amsterdam 1101 CH 1063 NL 1065 Email: jenapper@cisco.com 1067 Martin Stiemerling 1068 NEC 1069 NEC Europe Ltd. 1070 Kurfuersten-Anlage 36 1071 Heidelberg 69181 1072 DE 1074 Email: mls.ietf@gmail.com 1076 Diego R. Lopez 1077 Telefonica I+D 1078 Don Ramon de la Cruz, 82 1079 Madrid 28006 1080 ES 1082 Phone: +34 913 129 041 1083 Email: diego@tid.es 1085 Jim Uttaro 1086 AT&T 1087 200 South Laurel Ave 1088 Middletown, NJ 07748 1089 US 1091 Email: uttaro@att.com