idnits 2.17.1 draft-haeffner-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: ---------------------------------------------------------------------------- No issues found here. 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 (May 5, 2014) is 3643 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HSS' is mentioned on line 344, but not defined == Missing Reference: 'UE-C' is mentioned on line 275, but not defined == Missing Reference: 'S-GW-C' is mentioned on line 275, but not defined == Missing Reference: 'P-GW-C' is mentioned on line 275, but not defined == Missing Reference: 'UE-U' is mentioned on line 278, but not defined == Missing Reference: 'S-GW-U' is mentioned on line 278, but not defined == Missing Reference: 'P-GW-U' is mentioned on line 278, but not defined == Missing Reference: 'SGi-LAN' is mentioned on line 278, but not defined == Missing Reference: 'UE' is mentioned on line 294, but not defined == Missing Reference: 'P-GW' is mentioned on line 294, but not defined == Missing Reference: 'MME' is mentioned on line 344, but not defined == Missing Reference: 'PCRF' is mentioned on line 344, but not defined == Missing Reference: 'SFC 1' is mentioned on line 457, but not defined == Missing Reference: 'PCEF' is mentioned on line 457, but not defined == Missing Reference: 'TDF' is mentioned on line 457, but not defined == Missing Reference: 'Cache' is mentioned on line 512, but not defined == Missing Reference: '3GPP' is mentioned on line 734, but not defined Summary: 0 errors (**), 0 flaws (~~), 20 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: November 6, 2014 Cisco Systems 6 M. Stiemerling 7 NEC 8 D. Lopez 9 Telefonica I+D 10 J. Uttaro 11 AT&T 12 May 5, 2014 14 Service Function Chaining Use Cases in Mobile Networks 15 draft-haeffner-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 and framework statements 25 of the working group. 27 Service function chains typically reside in a LAN segment which links 28 the mobile access network to the actual application platforms located 29 in the carrier's datacenters or somewhere else in the Internet. 30 Service function chains ensure a fair distribution of network 31 resources according to agreed service policies, enhance the 32 performance of service delivery, take care of security and privacy or 33 support application and business support platforms. General 34 considerations and specific use cases are presented in this document 35 to demonstrate the different technical requirements of these goals 36 for service function chaining in mobile service provider networks. 38 The specification of service function chaining for mobile networks 39 must take into account an interaction between service function chains 40 and the 3GPP Policy and Charging Control (PCC) environment. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in [RFC2119]. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at http://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on November 6, 2014. 65 Copyright Notice 67 Copyright (c) 2014 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 1.1. Terminology and abbreviations . . . . . . . . . . . . . . 3 84 1.2. General scope of mobile service chains . . . . . . . . . 4 85 1.3. General structure of end-to-end carrier networks . . . . 5 86 2. Mobile network overview . . . . . . . . . . . . . . . . . . . 6 87 2.1. Building blocks of 3GPP mobile networks . . . . . . . . . 6 88 2.2. Overview of mobile service chains . . . . . . . . . . . . 7 89 2.3. The most common classification scheme . . . . . . . . . . 9 90 2.4. More sophisticated classification schemes . . . . . . . . 10 91 3. Example use cases specific to mobile networks . . . . . . . . 11 92 3.1. Service chain model for Internet HTTP services . . . . . 11 93 3.1.1. Weaknesses of current approaches . . . . . . . . . . 15 94 3.2. Service chain for TCP optimization . . . . . . . . . . . 15 95 3.2.1. Weaknesses of current approaches . . . . . . . . . . 16 97 3.3. HTTP header enrichment in mobile networks . . . . . . . . 16 98 4. Remarks on QoS in mobile networks . . . . . . . . . . . . . . 17 99 5. Weaknesses of current implementations . . . . . . . . . . . . 18 100 5.1. Granularity of the classification scheme . . . . . . . . 18 101 5.2. Service chain implementations . . . . . . . . . . . . . . 18 102 6. Operator requirements . . . . . . . . . . . . . . . . . . . . 19 103 6.1. Simplicity of service function chain instantiation . . . 19 104 6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 20 105 6.3. Delimitations . . . . . . . . . . . . . . . . . . . . . . 21 106 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 107 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 108 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 109 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 110 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 111 10.2. Informative References . . . . . . . . . . . . . . . . . 21 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 114 1. Introduction 116 1.1. Terminology and abbreviations 118 Much of the terminology used in this document has been defined by the 119 3rd Generation Partnership Project (3GPP), which defines standards 120 for mobile service provider networks. Although a few terms are 121 defined here for convenience, further terms can be found in 122 [RFC6459]. 124 UE User equipment like tablets or smartphones 126 eNB enhanced NodeB, radio access part of the LTE system 128 S-GW Serving Gateway, primary function is user plane mobility 130 P-GW Packet Gateway, actual service creation point, terminates 3GPP 131 mobile network, interface to Packet Data Networks (PDN) 133 HSS Home Subscriber System (control plane element) 135 MME Mobility Management Entity (control plane element) 137 GTP GPRS (General Packet Radio Service) Tunnel Protocol 139 S-IP Source IP address 141 D-IP Destination IP address 143 IMSI The International Mobile Subscriber Identity that identifies a 144 mobile subscriber 146 (S)Gi Egress termination point of the mobile network (SGi in case of 147 LTE, Gi in case of UMTS/HSPA). The internal data structure of 148 this interface is not standardized by 3GPP 150 PCRF 3GPP standardized Policy and Charging Rules Function 152 1.2. General scope of mobile service chains 154 Mobile access networks terminate at a mobile service creation point 155 (Packet Gateway) typically located at the edge of an operator IP 156 backbone. From the user equipment (UE) up to the Packet Gateway 157 (P-GW) everything is fully standardized by the 3rd Generation 158 Partnership Project (3GPP) e.g., in [TS.23.401]. Within the mobile 159 network, the user payload is encapsulated in 3GPP specific tunnels 160 terminating eventually at the P-GW. In many cases application- 161 specific IP traffic is not directly exchanged between the original 162 mobile network, more specific the P-GW, and an application platform, 163 but will be forced to pass a set of service functions. Those 164 application platforms are, for instance, a web server environment, a 165 video platform, a social networking platform or some other multimedia 166 platform. Network operators use these service functions to 167 differentiate their services to their subscribers. Service function 168 chaining is thus integral to the business model of operators. 170 Important use cases classes for service function chains generally 171 include: 173 1. functions to protect the carrier network and the privacy of its 174 users(IDS, FW, ACL, encryption, decryption, etc.), 176 2. functions that ensure the contracted quality of experience using 177 e.g., performance enhancement proxies (PEP) like video 178 optimizers, TCP optimizers or functions guaranteeing fair service 179 delivery based on policy based QoS mechanisms, 181 3. functions like HTTP header enrichment that may be used to 182 identify and charge subscribers real time, 184 4. functions like CG-NAT/PAT, which are required solely for 185 technical reasons, and 187 5. functions like parental control or malware detection that may be 188 a cost option of a service offer. 190 1.3. General structure of end-to-end carrier networks 192 Altough this memo is focused on the Service Function Chaining use 193 cases for mobile carrier networks, such as 3GPP- based ones, a number 194 of other, different carrier networks exists that share similarities 195 in the structure of the access networks and the service functions 196 with mobile networks. 198 Figure 1 shows 4 different carrier networks as examples to show 199 similarities with respect to Service Functions and their Chaining. 201 The service networks consist of access-specific user equipment, a 202 dedicated access network, a related service creation point and 203 finally a (LAN) infrastructure hosting Service Functions which 204 finally interconnect to application platforms in the Internet or in 205 the carrier's own datacenter (DC). 207 From top to down, there is a 3GPP mobile network terminating at the 208 P-GW, a xDSL network with its PPP tunnels terminating at a BNG 209 (Broadband Network Gateway), a FTTH network terminating at an OLT 210 (optical line terminal) and finally a cable TV network terminating at 211 a CMTS (cable modem termination system). 213 Access Service Functions (Categories) 214 Services +---------------------------+ 215 +--+ *~~~~~~~* +-----+ |+--1---+ +--2---+ +--3---+|| +---------+ 216 |UE|--| 3GGP |---| P-GW|--|| NAT | | MWD | | TCP || |Internal | 217 +--+ *~~~~~~~* +-----+ || . | | | | Opt. ||-|Appl. | 218 || FW | | Par. | | . || |Platforms| 219 +--+ *~~~~~~~* +-----+ || . | | Ctrl | | Video || |(e.g.IMS)| 220 |UE|--| xDSL |---| BNG |--|| LB | | . | | Opt. || +---------+ 221 +--+ *~~~~~~~* +-----+ || . | | LI | | . || 222 || DPI | | . | | Head. || 223 +--+ *~~~~~~~* +-----+ || . | | . | | Enr. || +---------+ 224 |UE|--| FTTH |---| OLT |--|| . | | | | . || | | 225 +--+ *~~~~~~~* +-----+ || . | | | | . ||-|Internet | 226 || . | | | | || | | 227 +--+ *~~~~~~~* +-----+ || | | | | || | | 228 |UE|--| CATV |---| CMTS|--|| | | | | || +---------+ 229 +--+ *~~~~~~~* +-----+ |+------+ +------+ +-------+| 230 +---------------------------+ 232 Figure 1: Various end-to-end carrier networks and service functions. 234 Category 1 of service functions like NAT or DPI may be used by all of 235 these service networks mainly just (but not exclusively) for 236 technical reasons. The same is true for category 2, value added 237 services (VAS) like parental control, malware detection and 238 elimination (MWD) or legal intercept (LI). TCP optimization is 239 basically seen in mobile networks only, the same may be true for 240 video optimizers or HTTP header enrichment, i.e., category 3 as a 241 rule mainly belongs to mobile networks only. 243 In our view, 3GPP-based mobile networks seem to have the largest 244 demand for service functions and service function chains. Service 245 Function Chains used in other access networks are very likely a 246 subset of what one can except in 3GPP-based mobile networks. 248 2. Mobile network overview 250 For simplicity we only describe service function chaining in the 251 context of LTE (Long Term Evolution) networks. But indeed our 252 service chaining model also applies to earlier generations of mobile 253 networks, such as purely UMTS-based mobile networks. 255 2.1. Building blocks of 3GPP mobile networks 257 The major functional components of a LTE network are shown in 258 Figure 2 and include user equipment (UE) like smartphones or tablets, 259 the LTE radio unit named enhanced NodeB (eNB), the serving gateway 260 (S-GW) which together with the mobility management entity (MME) takes 261 care of mobility and the packet gateway (P-GW), which finally 262 terminates the actual mobile service. These elements are described 263 in detail in [TS.23.401]. Other important components are the home 264 subscriber system (HSS) and the policy and charging rule function 265 (PCRF), which are described in [TS.23.203]. The P-GW interface 266 towards the SGi-LAN is called the SGi-interface, which is described 267 in [TS.29.061] and finally the SGi-LAN is the home of service 268 function chains (SFC), which are not standardized by 3GPP. 270 +--------------------------------------------+ 271 | Control Plane (C) [HSS] | [OTT Appl. Platform] 272 | | | | 273 | +--------[MME] [PCRF]--+--------+ Internet 274 | | | | | | | 275 | [UE-C] -- [eNB-C] == [S-GW-C] == [P-GW-C] | | | 276 +=====|=========|==========|============|====+ +-----+----+-------+ 277 | | | | | | | | | | 278 | [UE-U] -- [eNB-U] == [S-GW-U] == [P-GW-U]-+--+----[SGi-LAN] | 279 | | | | | 280 | | | | | 281 | | | [Appl. Platform] | 282 | | | | 283 | User Plane (U) | | | 284 +--------------------------------------------+ +--- IP Backbone --+ 286 |<----------- 3GPP Mobile Network ---------->| 288 Figure 2 shows the end to end context including all major components 289 of a LTE network. The actual 3GPP mobile network includes the 290 elements from the user equipment [UE] to the packet gateway [P-GW]. 292 Figure 2: End to end context including all major components of a LTE 293 network. The actual 3GPP mobile network includes the elements from 294 the user equipment [UE] to the packet gateway [P-GW]. 296 The radio-based IP traffic between the UE and the eNB is encrypted 297 according 3GPP standards. Between eNB, S-GW, P-GW user IP packets as 298 well as control plane packets are encapsulated in 3GPP-specific 299 tunnels. In some mobile carrier networks the 3GPP specific tunnels 300 between eNB and S-GW are even additionally IPSec-encrypted. For more 301 details see [TS.29.281] and [TS.29.274]. 303 Service function chains act on user plane IP traffic only. But the 304 way these act on user traffic may depend on subscriber, service or 305 network specific control plane metadata. 307 2.2. Overview of mobile service chains 309 The original user IP packet, including the Source-IP-Address (S-IP) 310 of the UE and the Destination-IP-Address (D-IP) of the addressed 311 application platform, leaves the Packet Gateway from the mobile 312 network via the so-called Gi-interface (3G service, e.g., UMTS) 313 respectively SGi-interface (4G service, e.g., LTE). Between this (S 314 )Gi-interface and the actual application platform the user generated 315 upstream IP packets and the corresponding downstream IP packets are 316 typically forced to pass an ordered set of service functions, loosely 317 called a service function chain (SFC). 319 The set of all available service functions (physical or virtualized) 320 which can be used to establish different service chains for different 321 services is often called a Gi-LAN for 2G/3G services and SGi-LAN for 322 4G services. 324 The (S)Gi-interface towards the (S)Gi-LAN itself is discussed in 325 [TS.29.061], but service function chaining is not specified by 3GPP. 327 The (S)Gi-LAN service functions can use subscriber and service 328 related metadata delivered from the mobile control plane, such as the 329 PCRF, to process the flows according to service related policies. 331 In short, the (S)Gi-LAN service area is presently used by mobile 332 service providers to differentiate their services to their 333 subscribers and reflect the business model and of mobile operators. 335 For different applications (e.g., Appl. 1,2,3) upstream and 336 downstream user plane IP flows will be forced to pass a sequence of 337 service functions which is called a service chain specific to a given 338 application. In the simple example sketched in Figure 3 the service 339 chains for applications 1, 2 and 3 may be just classified by a unique 340 interface-ID of the egress P-GW interfaces where the service chains 341 for application 1, 2 and 3 are attached. 343 +------------------------------------------------------------------+ 344 | Control Plane Environment [HSS] [MME] [PCRF] [others] | 345 +------------------------------------------------|-----------------+ 346 +--------------------+ 347 +---------------------------|--------------------|-----------------+ 348 | User Plane Environment | | | 349 | | +------(S)Gi-LAN --+-----+ | 350 | | | | | 351 | | | +---[SF1]-[SF3]-[SF5]---[Appl. 1] | 352 | | | / | | 353 | [UE]---[eNB]===[S-GW]===[P-GW]-----[SF2]-[SF4]-[SF6]--------+ | 354 | | \ | | | 355 | | +---[SF7]-[SF8]-[SF9]-----+ | | 356 | | | | | | 357 | +--------------------------+ | | | 358 | | | | 359 +----------------------------------------------------------|--|----+ 360 | | 361 OTT Internet Applications 362 | | 363 [Appl. 2] [Appl. 3] 365 Figure 3: Typical service chain topology. 367 Service functions typically observe, alter or even terminate and 368 reestablish application session flows between mobile user equipment 369 and application platforms. Control plane metadata supporting policy 370 based traffic handling may be linked to individual service functions 371 SFn. Because in Figure 3 the P-GW classifies service chains, we 372 consider the P-GW as a component of the service chaining environment. 374 2.3. The most common classification scheme 376 Mobile user equipment like smartphones, tablets or other mobile 377 devices address use Access Point Names (APNs) to address a service 378 network or service platform. APNs are DNS host names and comparable 379 to FQDN host names. While a FQDN refers to an Internet IP address, 380 an APN (loosely speaking) specifies a P-GW IP address. These APNs 381 are used to distinguish certain user groups and their traffic, e.g., 382 there can be an APN for a mobile service offered to the general 383 public while enterprise customers get their own APN. For APN details 384 see [TS.23.003]. 386 Operators often associate a designated VLAN-ID with an APN. A VLAN- 387 ID n then may classify the service function chain n (SFC n) related 388 to an application platform n (Appl. n), as shown in the following 389 Figure 4. 391 +----------+ 392 | | 393 | IF-1 O [APN 1 => VLAN-ID 1] ---- [SFC 1] ---- [Appl. 1] 394 | | 395 =====| P-GW O . . . . 396 | | 397 | IF-n O [APN n => VLAN-ID n] ---- [SFC n] ---- [Appl. n] 398 | | 399 +----------+ 401 Figure 4: Association of a service chain to an application platform. 403 Examples for an APN are, e.g.: 405 +------------+-----------------+ 406 | APN: | web.vodafone.de | 407 | User Name: | not required | 408 | Password: | not required | 409 +------------+-----------------+ 411 Table 1: Example APN for Vodafone Germany 412 +------------+------------------+ 413 | APN: | internet.telekom | 414 | User Name: | t-mobile | 415 | Password: | tm | 416 +------------+------------------+ 418 Table 2: Example APN for Deutsche Telekom/T-Mobile 420 2.4. More sophisticated classification schemes 422 More sophisticated classifications are feasible using metadata that 423 is UE related, subscriber and service related, as well as network 424 related metadata. Typical metadata and their sources are: 426 UE: terminal type (e.g., HTC one); IMSI (country, carrier, user); 428 GTP tunnel endpoint: eNB-Identifier; time; 430 PCRF: subscriber info; APN (service name); QoS; policy rules. 432 Mobile operator defined subscriber, service or network specific 433 policies are typically encoded in the 3GPP-based "policy and charging 434 rules function" (PCRF), see [TS.23.203]. For instance, a PCRF may 435 encode the rules that apply to pre-paid and post-paid users, users 436 with a classification of gold, silver, or bronze, or even as detailed 437 as describing rules that apply to "gold users, wishing to download a 438 video file, while these subscribers are subjected to a fair-usage 439 policy". It is up to the mobile service providers to encode the 440 precise mappings between its subscriber classes and the associated 441 service chains. 443 The Traffic Detection Function (TDF) is part of the 3GPP PCC (Policy 444 and Charging Architecture, [TS.23.203]). Such a TDF inspects the 445 user traffic after leaving the PGW (see Figure 4). The TDF can be 446 used to classify traffic originating from an APN into more detailed 447 services. This could be used to classify traffic into different 448 Service Functions. 450 +-------------------------+ 451 | PCRF | 452 +----+--------------+-----+ 453 | | 454 Gx-IF Sd-IF 455 | | 456 +----+-----+ +----+-----+ 457 ==========O [PCEF] | | [TDF] O--------[SFC 1] ---- [Appl. 1] 458 | | | O--------[SFC 2] ---- [Appl. 2] 459 ==========O P-GW O---O SGi-LAN O--------[SFC 3] ---- [Appl. 3] 460 | | | O--------[SFC 4] ---- [Appl. 4] 461 ==========O | | O--------[SFC n] ---- [Appl. n] 462 +----------+ +----------+ 463 * * 464 3GPP Bearer SGi SGi 466 Figure 5: 3GPP Traffic Detection Function (TDF) for classification. 468 The TDF will typically observe the traffic on all layers. On 469 application start and stop the TDF provides feedback to the PCRF for 470 further actions to be taken on a particular flow. The PCRF can 471 request that the TDF apply application and detection controls to 472 application flows including charging and usage monitoring. The TDF 473 can also act without any interaction with the PCRF taking care of 474 gating (firewalling), traffic redirection, bandwidth management or 475 charging. 477 3. Example use cases specific to mobile networks 479 Because HTTP via TCP port 80 (or TCP port 443 for HTTPS) is by far 480 the most common Internet traffic class, we discuss two typical 481 examples of an associated service function chaining model in some 482 more detail. 484 The models presented below are simplified compared to real life 485 service function chain implementations because we do not discuss 486 differentiated traffic handling based on different subscriber- 487 specific service level agreements and price plans or even actual 488 network load conditions. 490 3.1. Service chain model for Internet HTTP services 492 With the increase of Internet traffic in mobile networks mobile 493 operators have started to introduce Performance Enhancement Proxies 494 (PEPs) to optimize network resource utilization. PEPs are more or 495 less integrated platforms that ensure the best possible Quality of 496 Experience (QoE). Their service functions include but are not 497 limited to Deep Packet Inspection (DPI), web and video optimizations, 498 subscriber and service policy controlled dynamic network adaption, 499 analytics and management support. 501 A simple service function chain model for mobile Internet upstream 502 and downstream traffic is shown in Figure 6 below. The function 503 chain includes Load Balancers (LB), which split HTTP over TCP port 80 504 away from the rest of the internet traffic. Beside basic web 505 content, this traffic class includes more and more video. To act on 506 this traffic type we force this traffic to pass Performance 507 Enhancement Proxies. The firewall function (FW) protects the carrier 508 network from the outside and Network Address Translation (NAT) maps 509 the private IP address space dedicated to user equipment to a public 510 IP address. 512 [Cache] 513 | 514 [P-GW]---[LB]-----------[PEP]--[LB]--[FW]---[NAT]---[Internet] 515 | HTTP:80 | 516 | | 517 | | 518 | non HTTP:80 | 519 +---------------------+ 521 Figure 6: Service function chain for HTTP traffic over TCP port 80. 523 The first application in the service chain caches web content to help 524 reduce Round Trip Times (RTT) and therefore contribute to improved 525 web page load times. This is generally more important for mobile 526 service providers than reducing Internet peering costs. Similar 527 arguments hold for cached video content. We avoid potential large 528 jitter imported from the Internet. 530 An example for non HTTP:80 traffic in Figure 6 is UDP-encapsulated 531 IPsec traffic, which is dedicated to port 10000. Note that in a real 532 environment not only port 80 but for example additional traffic via 533 port 8080, 25 for SMTP, 110 for POP3 or 143 for IMAP may be forced to 534 pass a service chain. 536 A second application is video optimization. Video content from the 537 Internet may not fit in the size of mobile device displays or simply 538 would overload the mobile network when used natively. Therefore 539 mobile operators adapt internet-based video content to ensure the 540 best Quality of Experience. 542 Video content optimization very often is also an additional premium- 543 related component in service offers and price plans. 545 Our PEP environment for video optimization consists of three basic 546 service functions shown in Figure 7: a steering proxy which is able 547 to redirect HTTP traffic, a DPI-based controller which checks for 548 video content and an optimizer which transcodes videos to an 549 appropriate format on the fly in real time. 551 [PEP for video] ==>> [Steering Proxy]---[DPI Contr.]---[Optimizer] 553 Figure 7: Service functions required for video optimization. 555 In Figure 8 we show the detailed HTTP flows and their redirection in 556 some more detail. The intention here is to show every elementary 557 functional step in a chain as a separate physical or virtualized 558 item, but this state diagram must not necessarily reflect every 559 existing vendor-specific proprietary implementation. 561 [UE]----[Steering Proxy]----[DPI Contr.]----[Optimizer]----[Content] 563 |-- HTTP GET ->|-------------- HTTP GET ----------------------->| 565 |<------------- HTTP Response -------------------| 567 |-- Is it Video? ->| 569 |<-- Video found --| 571 |<--- HTTP ----| 572 Redirect 574 |-- HTTP GET ->|-----HTTP GET ---------------->| 576 |-- HTTP GET -->| 577 Video 579 |<--- HTTP -----| 580 Response 581 Orig. Video 583 {Optimize} 585 |<------- HTTP Response --------| 586 Transcoded Video 588 |-- Is it Video? ->| 590 |<-- Video found --| 592 |<--- HTTP ----| 593 Response 594 Transcoded Video 596 Figure 8: Flow diagram between UE and video optimization PEP. 598 In such an application scenario one can have reclassification or off- 599 loading on the fly. 601 Assume a video streams within a 4G LTE radio cell. The video 602 optimizer would then apply a transcoding scheme appropriate to the 603 abilities of the 4G network. If one is now leaving the 4G cell and 604 entering a 3G radio cell, the network conditions will most probably 605 become different and the video optimizer has to use another 606 transcoding scheme to keep a certain QoE. This requires that the 607 video optimizer service function is aware of the Radio Access 608 Technology (RAT) in use. One may transfer RAT type from the P-GW (or 609 GGSN in case of 3G traffic) via an AAA Proxy to the service function 610 chain. The RAT information will then be embedded in an appropriate 611 Radius message. Other 3GPP steering mechanisms may apply as well. 613 If for example the 4G network has sufficient bandwidth, one could 614 also think of another, different use case. The rule could be that 615 only 3G video streams are forced to pass the video optimizer while 616 all 4G video traffic will be bypassed. 618 Additionally, network utilization information can be used to trigger 619 the behavior of the service function. The degree of video 620 compression applied could depend on the actual current network load. 622 Last not least the behavior of the video optimizer service function 623 (or any other service function) could additionally depend on the 624 user-specific service contract (price plan, gold, silver, bronze) or 625 on individual on demand requests. 627 3.1.1. Weaknesses of current approaches 629 This use case model highlights the weakness of current service 630 deployments in the areas of traffic selection, reclassification, and 631 multi-vendor support. Traffic in this example is classified after 632 the P-GW and separated into separate flows based on whether it is (in 633 this example) TCP traffic destined to port 80. This classification 634 could be done by the load balancer if it initiates the service chain 635 selection, or the traffic can be reclassified at the load balancer if 636 it the traffic already embedded in a service chain (e.g., when 637 combined with other functions such as the TCP optimization in the 638 following use case). Multi-vendor support is needed because every 639 element in the use case can be provided by a different vendor: load- 640 balancer, http proxy, firewall, and NAT. 642 3.2. Service chain for TCP optimization 644 The essential parameters influencing TCP behavior are latency, packet 645 loss and available throughput. 647 Content servers are mostly attached to fixed networks. These are 648 characterized by high bandwidth and low latency. Therefore content 649 servers often experience large TCP window sizes. In fixed networks, 650 end-to-end TCP window size mismatches do not have that much negative 651 impact on data flows. 653 On the other hand, mobile networks show a different behavior. While 654 the (S)Gi-side of the network typically exhibits low latency, low 655 packet loss, high bandwidth and minimal congestion, the Radio Access 656 Network (RAN) tends to have higher latency, packet loss, and 657 congestion. Therefore mobile devices normally experience much 658 smaller TCP window sizes. 660 One way to mitigate these different environments, i.e., the LAN and 661 the mobile wireless part, is to use split TCP. However, this leads 662 to the case that the mobile wireless part can experience a different 663 TCP window size than the fixed LAN part. 665 In mobile networks, these TCP window size mismatches may result in 666 poor end-to-end throughput and bad user experience. 668 Therefore mobile operators very often use TCP optimization proxies in 669 the data path. These proxies monitor latency and throughput real- 670 time and dynamically optimize TCP parameters for each TCP connection 671 to ensure a better transmission behavior. 673 A rudimentary service chain setup for TCP optimization is shown in 674 Figure 9. Examples of non TCP flows are UDP/RTP voice or video 675 traffic. 677 [P-GW]---[LB]----------[TCP Opt.]---[LB]---[FW]---[NAT]---[Internet] 678 | TCP | 679 | | 680 | non-TCP | 681 +--------------------------+ 683 Figure 9: Optimizing TCP parameterization in a mobile network. 685 3.2.1. Weaknesses of current approaches 687 This use case highlights weaknesses of current service deployments in 688 the areas of traffic selection, reclassification, and multi-vendor 689 support as in the previous use case presented in Section 3.1. 691 3.3. HTTP header enrichment in mobile networks 693 In legacy mobile networks WAP (Wireless Application Protocol) 694 gateways mediated between traditional mobile phones and the Internet 695 translating HTML web content into a WML (Wireless Markup Language) 696 and vice versa. By functionality, WAP-GWs fit also in the SFC 697 category. 699 Traditionally WAP-GWs use HTTP header enrichment to insert subscriber 700 related datainto WAP and HTTP request headers in real time. These 701 data were (are) used to identify and charge subscribers on third 702 party web sites. 704 Of today 3G and 4G mobile networks HTTP header enrichment is done by 705 the GGSN/P-GW or a dedicated transparent HTTP optimizer as most of 706 the data traffic on a mobile network no longer passes a WAP-GW. 708 Information typically added to the header includes: 710 o Charging Characteristics 712 o Charging ID 714 o Subscriber ID 716 o GGSN or PGW IP address 718 o Serving Gateway Support Node (SGSN) or SGW IP address 720 o International Mobile Equipment Identity (IMEI) 722 o International Mobile Subscriber Identity (IMSI) 724 o Mobile Subscriber ISDN Number (MSISDN) 726 o UE IP address 728 4. Remarks on QoS in mobile networks 730 As indicated in Figure 3, service functions may be linked to the 731 control plane to take care of additional subscriber or service 732 related metadata. In many cases the source of metadata would be the 733 PCRF and the link would be a Gx or Diameter-based Sd interface. 734 Diameter is specified in [RFC6733] and Gx in [3GPP]. 736 Service functions within the SGi/Gi-LAN are less focused on the 737 explicit QoS steering of the actual mobile wireless network. QoS in 738 mobile networks is based on the 3GPP "Bearer" concept. A Bearer is 739 the essential traffic separation element enabling traffic separation 740 according different QoS settings and represents the logical 741 transmission path between the User Equipment (UE) and the Packet 742 Gateway (P-GW). 744 5. Weaknesses of current implementations 746 In many operator environments every new service introduction can 747 result in a further dedicated (S)Gi-LAN service chain, because 748 service chaining has been deployed historically in an ad hoc manner. 749 It typically requires placement of new functions in the operator's 750 data center, changing the actual wiring to include any new or change 751 service function, configuration of the functions and network 752 equipment, and finally testing of the new configuration to ensure 753 that everything has been properly setup. 755 5.1. Granularity of the classification scheme 757 Often the coarse grained classification according to APNs is not fine 758 enough to uniquely select a service function chain or a processing 759 scheme within a service function chain required to support the 760 typical user-, service- or network- related policies which the 761 operator likes to apply to a specific user plane flow. 763 It is very likely that an APN, such as shown in Section 2.3, is 764 carrying an extremely diverse set of user traffic. This can range 765 from HTTP web traffic to real-time traffic. 767 5.2. Service chain implementations 769 In many carrier networks service chain LANs grow incrementally 770 according product introductions or product modifications. This very 771 often ends in a mix of static IP links, policy based routing or 772 individual VRF implementations etc. to enforce the required sequence 773 of service functions. Major weak points seen in many carrier 774 networks are: 776 o Very static service chain instances, hard-wired on the network 777 layer leads to no flexibility with respect to reusing, adding, and 778 removing service nodes and reprogramming service chains. 780 o Evolutionary grown "handcrafted" connectivity models require high 781 complexity to manage or maintain. 783 o Basic implementation paradigm is based on APNs (that is service 784 types) only, which requires individual injections of context- 785 related metadata to obtain granularity down to user/service level. 787 o There is currently no natural (or standardized) information 788 exchange on network status between services and the network, 789 complicating management of network resources based on subscriber 790 profiles. 792 o It is currently practically impossible to implement an automated 793 service provisioning and delivery platform. 795 o Scaling up flows or service chains with service or subscriber 796 related metadata is extremely diffculty. 798 6. Operator requirements 800 Mobile operators use service function chains to enable and optimize 801 service delivery, offer network related customer services, optimize 802 network behavior or protect networks against attacks and ensure 803 privacy. Service function chains are essential to their business. 804 Without these, mobile operators are not able to deliver the necessary 805 and contracted Quality of Experience or even certain products to 806 their customers. 808 6.1. Simplicity of service function chain instantiation 810 Because product development cycles are very fast in mobile markets, 811 mobile operators are asking for service chaining environments which 812 allow them to instantly create or modify service chains in a very 813 flexible and very simple way. The creation of service chains should 814 be embedded in the business and operation support layers of the 815 company and on an abstract functional level, independent of any 816 network underlay. No knowledge about internetworking technology 817 should be required at all. The mapping of the functional model of a 818 service chain onto the actual underlay network should be done by a 819 provisioning software package similar to that shown in Figure 10. 820 Details of the architecture and design are the subject of forthcoming 821 standards and proprietary implementation details. 823 +------------------------------------------------------------------+ 824 | Creation of an abstract service function chain | 825 +------------------------------------------------------------------+ 826 | 827 V 828 +------------------------------------------------------------------+ 829 | +----------------------------------------------------+ | 830 | | Service function chain compiler | | 831 | +----------------------------------------------------+ | 832 | | | 833 | V | 834 | +----------------------------------------------------+ | 835 | | Mediation device | | 836 | +----------------------------------------------------+ | 837 +------------------------------------------------------------------+ 838 | 839 V 840 +------------------------------------------------------------------+ 841 | Physical network underlay | 842 +------------------------------------------------------------------+ 844 Figure 10: Creation and provisioning system for service function 845 chains. 847 Service functions can be physical or virtualized. In the near future 848 the majority of mobile service functions will typically reside in the 849 local cloud computing environment of a mobile core location. 850 Nevertheless, the architecture and design should allow and support 851 also remote service functions if applicable. 853 6.2. Extensions 855 A service function chain should be generalized by a directed graph 856 where the vertices (nodes) represent an elementary service function. 857 This model allows branching conditions at the vertices. Branching in 858 a graph could then be triggered by typical 3GPP specified mobile 859 metadata (see Section 2.3) and allow for more sophisticated steering 860 methods in a service chain. Typically this data will be injected by 861 the mobile control plane, commonly by the PCRF via a Diameter-based 862 3GPP Sd interface. 864 Service chain behavior and output should additionally depend on 865 actual network conditions. For example, the selection of a video 866 compression format could depend on the actual load of the mobile 867 network segment a mobile user is attached to. That is to say that 868 classification of flows may allow very dynamic inputs while 869 specification of such inputs from a 3GPP network will need to be done 870 by 3GPP or another standards body. 872 Although necessary metadata can be obtained from the PCRF, to avoid 873 Diameter signaling storms in the (S)Gi-LAN, individual service 874 functions should probably not be attached individually to the control 875 plane. A mechanism where such metadata is carried by a metadata 876 header can reduce requests to the PCRF, provided these extensions do 877 not increase the original payload size too much. 879 6.3. Delimitations 881 A clear separation between service chaining functionality and 3GPP 882 bearer handling is required. This may be subject of forthcoming 883 studies. 885 7. Security Considerations 887 TBD. 889 8. IANA Considerations 891 This document has no actions for IANA. 893 9. Acknowledgments 895 We thank Peter Bosch, Carlos Correia, Dave Dolson, Linda Dunbar, Alla 896 Goldner, Wim Hendericks, Konstantin Livanos, Praveen Muley, Ron 897 Parker, and Nirav Salot for valuable discussions and contributions. 899 10. References 901 10.1. Normative References 903 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 10.2. Informative References 908 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 909 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 910 Partnership Project (3GPP) Evolved Packet System (EPS)", 911 RFC 6459, January 2012. 913 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 914 "Diameter Base Protocol", RFC 6733, October 2012. 916 [TS.23.003] 917 "Numbering, addressing and identification", 3GPP TS 23.003 918 12.1.0, December 2013. 920 [TS.23.203] 921 "Policy and charging control architecture", 3GPP TS 23.203 922 12.3.0, December 2013. 924 [TS.23.401] 925 "General Packet Radio Service (GPRS) enhancements for 926 Evolved Universal Terrestrial Radio Access Network 927 (E-UTRAN) access", 3GPP TS 23.401 12.3.0, December 2013. 929 [TS.29.061] 930 "Interworking between the Public Land Mobile Network 931 (PLMN) supporting packet based services and Packet Data 932 Networks (PDN)", 3GPP TS 29.061 12.4.0, December 2013. 934 [TS.29.274] 935 "3GPP Evolved Packet System (EPS); Evolved General Packet 936 Radio Service (GPRS) Tunnelling Protocol for Control plane 937 (GTPv2-C); Stage 3", 3GPP TS 29.274 12.3.0, December 2013. 939 [TS.29.281] 940 "General Packet Radio System (GPRS) Tunnelling Protocol 941 User Plane (GTPv1-U)", 3GPP TS 29.281 11.6.0, March 2013. 943 Authors' Addresses 945 Walter Haeffner 946 Vodafone 947 Vodafone D2 GmbH 948 Ferdinand-Braun-Platz 1 949 Duesseldorf 40549 950 DE 952 Phone: +49 (0)172 663 7184 953 Email: walter.haeffner@vodafone.com 955 Jeffrey Napper 956 Cisco Systems 957 Cisco Systems, Inc. 958 Haarlerbergweg 13-19 959 Amsterdam 1101 CH 960 NL 962 Email: jenapper@cisco.com 963 Martin Stiemerling 964 NEC 965 NEC Europe Ltd. 966 Kurfuersten-Anlage 36 967 Heidelberg 69181 968 DE 970 Email: mls.ietf@gmail.com 972 Diego R. Lopez 973 Telefonica I+D 974 Don Ramon de la Cruz, 82 975 Madrid 28006 976 ES 978 Phone: +34 913 129 041 979 Email: diego@tid.es 981 Jim Uttaro 982 AT&T 983 200 South Laurel Ave 984 Middletown, NJ 07748 985 US 987 Email: uttaro@att.com