idnits 2.17.1 draft-ietf-sfc-use-case-mobility-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7498]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 (April 13, 2016) is 2925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'HSS' is mentioned on line 388, but not defined == Missing Reference: 'UE-C' is mentioned on line 306, but not defined == Missing Reference: 'S-GW-C' is mentioned on line 306, but not defined == Missing Reference: 'P-GW-C' is mentioned on line 306, but not defined == Missing Reference: 'UE-U' is mentioned on line 309, but not defined == Missing Reference: 'S-GW-U' is mentioned on line 309, but not defined == Missing Reference: 'P-GW-U' is mentioned on line 309, but not defined == Missing Reference: 'SGi-LAN' is mentioned on line 309, but not defined == Missing Reference: 'UE' is mentioned on line 321, but not defined == Missing Reference: 'P-GW' is mentioned on line 321, but not defined == Missing Reference: 'MME' is mentioned on line 388, but not defined == Missing Reference: 'PCRF' is mentioned on line 388, but not defined == Missing Reference: 'SFC 1' is mentioned on line 538, but not defined == Missing Reference: 'PCEF' is mentioned on line 528, but not defined == Missing Reference: 'TDF' is mentioned on line 533, but not defined == Missing Reference: 'TSSF' is mentioned on line 538, but not defined == Missing Reference: 'Cache' is mentioned on line 608, but not defined Summary: 1 error (**), 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: October 15, 2016 Cisco Systems 6 M. Stiemerling 7 NEC 8 D. Lopez 9 Telefonica I+D 10 J. Uttaro 11 AT&T 12 April 13, 2016 14 Service Function Chaining Use Cases in Mobile Networks 15 draft-ietf-sfc-use-case-mobility-06 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 [RFC7498] and 25 architecture framework [ietf-sfc-arch] 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 (SFC) ensure a fair distribution of network 31 resources according to agreed service policies, enhance the 32 performance of service delivery or take care of security and privacy. 33 SFCs may also include Value Added Services (VAS). Commonly, SFCs are 34 typical middle box based services. 36 General considerations and specific use cases are presented in this 37 document to demonstrate the different technical requirements of these 38 goals for service function chaining in mobile service provider 39 networks. 41 The specification of service function chaining for mobile networks 42 must take into account an interaction between service function chains 43 and the 3GPP Policy and Charging Control (PCC) environment. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC2119]. 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on October 15, 2016. 68 Copyright Notice 70 Copyright (c) 2016 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Terminology and abbreviations . . . . . . . . . . . . . . 3 87 1.2. General scope of mobile service chains . . . . . . . . . 4 88 1.3. General structure of end-to-end carrier networks . . . . 5 89 2. Mobile network overview . . . . . . . . . . . . . . . . . . . 6 90 2.1. Building blocks of 3GPP mobile LTE networks . . . . . . . 7 91 2.2. Overview of mobile service chains . . . . . . . . . . . . 8 92 2.3. The most common classification scheme . . . . . . . . . . 10 93 2.4. More sophisticated classification schemes . . . . . . . . 11 94 3. Example use cases specific to mobile networks . . . . . . . . 13 95 3.1. Service chain model for Internet HTTP services . . . . . 13 96 3.1.1. Weaknesses of current approaches . . . . . . . . . . 16 97 3.2. Service chain for TCP optimization . . . . . . . . . . . 17 98 3.2.1. Weaknesses of current approaches . . . . . . . . . . 17 99 3.3. HTTP header enrichment in mobile networks . . . . . . . . 18 100 3.3.1. HTTP header enrichment in legacy mobile data networks 18 101 3.3.2. HTTP header enrichment in modern mobile data networks 18 102 3.3.3. HTTP header enrichment security condiderations . . . 18 103 4. Remarks on QoS in mobile networks . . . . . . . . . . . . . . 19 104 5. Weaknesses of current implementations . . . . . . . . . . . . 19 105 5.1. Granularity of the classification scheme . . . . . . . . 19 106 5.2. Service chain implementations . . . . . . . . . . . . . . 20 107 6. Operator requirements . . . . . . . . . . . . . . . . . . . . 20 108 6.1. Simplicity of service function chain instantiation . . . 20 109 6.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . 22 110 6.3. Reflections on Metadata . . . . . . . . . . . . . . . . . 22 111 6.4. Delimitations . . . . . . . . . . . . . . . . . . . . . . 23 112 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 113 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 114 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 23 117 10.2. Informative References . . . . . . . . . . . . . . . . . 24 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 120 1. Introduction 122 1.1. Terminology and abbreviations 124 Much of the terminology used in this document has been defined by the 125 3rd Generation Partnership Project (3GPP), which defines standards 126 for mobile service provider networks. Although a few terms are 127 defined here for convenience, further terms can be found in 128 [RFC6459]. 130 UE User equipment like tablets or smartphones 132 eNB enhanced NodeB, radio access part of the LTE system 134 S-GW Serving Gateway, primary function is user plane mobility 136 P-GW Packet Gateway, actual service creation point, terminates 3GPP 137 mobile network, interface to Packet Data Networks (PDN) 139 HSS Home Subscriber Server (control plane element) 140 MME Mobility Management Entity (control plane element) 142 GTP GPRS (General Packet Radio Service) Tunnel Protocol 144 S-IP Source IP address 146 D-IP Destination IP address 148 IMSI International Mobile Subscriber Identity that identifies a 149 mobile subscriber 151 (S)Gi Egress termination point of the mobile network (SGi in case of 152 LTE, Gi in case of UMTS/HSPA). The internal data structure of 153 this interface is not standardized by 3GPP 155 PCRF 3GPP standardized Policy and Charging Rules Function 157 PCEF Policy and Charging Enforcement Function 159 TDF Traffic Detection Function 161 TSSF Traffic Steering Support Function 163 IDS Intrusion Detection System 165 FW Firewall 167 ACL Access Control List 169 PEP Performance Enhancement Proxy 171 IMS IP Multimedia Subsystem 173 LI Lawful Interception 175 1.2. General scope of mobile service chains 177 Mobile access networks terminate at a mobile service creation point 178 (called Packet Gateway) typically located at the edge of an operator 179 IP backbone. From the user equipment (UE) up to the Packet Gateway 180 (P-GW) or, if deployed, the Traffic Detection Function (TDF) 181 everything is fully standardized by the 3rd Generation Partnership 182 Project (3GPP) e.g., in [TS.23.401] and in [TS.23.203]. Within the 183 mobile network, the user payload is encapsulated in 3GPP specific 184 tunnels terminating eventually at the P-GW. In many cases 185 application- specific IP traffic is not directly exchanged between 186 the original mobile network, more specifically the P-GW, and an 187 application platform, but will be forced to pass a set of service 188 functions. Those application platforms are, for instance, a web 189 server environment, a video platform, a social networking platform or 190 some other multimedia platform. Network operators use these service 191 functions to differentiate their services to their subscribers. 192 Service function chaining is thus integral to the business model of 193 operators. 195 Important use case classes for service function chains generally 196 include: 198 o functions to protect the carrier network and the privacy of its 199 users(IDS, FW, ACL, encryption, decryption, etc.), 201 o functions that ensure the contracted quality of experience using 202 e.g., performance enhancement proxies (PEP) like video optimizers, 203 TCP optimizers or functions guaranteeing fair service delivery 204 built upon policy based QoS mechanisms, 206 o functions like HTTP header enrichment that may be used to identify 207 and charge subscribers real time, 209 o functions like Carrier Grade NAT (CG-NAT) and NAPT, which are 210 required solely for technical reasons, and 212 o functions like parental control or malware detection that may be a 213 cost option of a service offer. 215 1.3. General structure of end-to-end carrier networks 217 Although this memo is focused on the Service Function Chaining use 218 cases for mobile carrier networks, such as 3GPP-based ones, a number 219 of other, different carrier networks exists that share similarities 220 in the structure of the access networks and the service functions 221 with mobile networks. 223 Figure 1 shows a simplified schematic view of 4 different access 224 service networks to indicate similarities with respect to Service 225 Functions and their Chaining. 227 These service networks consist of access-specific user equipment, a 228 dedicated access network, a related service creation point and 229 finally a (LAN) infrastructure hosting Service Functions which 230 eventually interconnect to application platforms in the Internet or 231 in the carrier's own datacenter (DC). From top to down, there is a 232 3GPP mobile network terminating at the P-GW (or TDF), an xDSL network 233 with its PPP tunnels terminating at a BNG (Broadband Network 234 Gateway), a FTTH network terminating at an OLT (Optical Line 235 Terminal) and finally a CATV (cable TV) network terminating at a CMTS 236 (Cable Modem Termination System). 238 Access Service Functions 239 Services +---------------------------+ 240 +--+ *~~~~~~~* +-----+ |+--1---+ +--2---+ +--3---+|| +---------+ 241 |UE|--| 3GGP |---| P-GW|--|| NAT | | MWD | | TCP || |Internal | 242 +--+ *~~~~~~~* +-----+ || . | | . | | Opt. ||-|Appl. | 243 || FW | | Par. | | . || |Platforms| 244 +--+ *~~~~~~~* +-----+ || . | | Ctrl | | Video || |(e.g.IMS)| 245 |UE|--| xDSL |---| BNG |--|| LB | | . | | Opt. || +---------+ 246 +--+ *~~~~~~~* +-----+ || . | | LI | | . || 247 || DPI | | . | | Head. || 248 +--+ *~~~~~~~* +-----+ || . | | . | | Enr. || +---------+ 249 |UE|--| FTTH |---| OLT |--|| . | | | | . || | | 250 +--+ *~~~~~~~* +-----+ || | | | | . || | | 251 || | | | | ||-|Internet | 252 +--+ *~~~~~~~* +-----+ || | | | | || | | 253 |UE|--| CATV |---| CMTS|--|| | | | | || | | 254 +--+ *~~~~~~~* +-----+ |+------+ +------+ +-------+| +---------+ 255 +---------------------------+ 257 Figure 1: Various end-to-end carrier networks and service functions 258 sorted into categories 1, 2 and 3. 260 Category 1 of service functions like NAT or DPI may be used by all of 261 these service networks mainly just (but not exclusively) for 262 technical reasons. The same is true for category 2, Value Added 263 Services (VAS) like parental control, malware detection and 264 elimination (MWD) or Lawful Interception (LI). TCP optimization is 265 basically seen in mobile networks only. The same may be true for 266 video optimizers or HTTP header enrichment; i.e., category 3 as a 267 rule mainly belongs to mobile networks only. 269 In our view, 3GPP-based mobile networks seem to have the largest 270 demand for service functions and service function chains. Service 271 Function Chains used in other access networks are very likely a 272 subset of what one can expect in 3GPP-based mobile networks. 274 Typical data center use cases are described in 275 [ietf-sfc-dc-use-cases]. 277 2. Mobile network overview 279 For simplicity we only describe service function chaining in the 280 context of LTE (Long Term Evolution) networks. But indeed our 281 service chaining model also applies to earlier generations of mobile 282 networks, such as purely UMTS-based mobile networks. 284 2.1. Building blocks of 3GPP mobile LTE networks 286 The major functional components of an LTE network are shown in 287 Figure 2 and include user equipment (UE) like smartphones or tablets, 288 the LTE radio unit named enhanced NodeB (eNB), the serving gateway 289 (S-GW) which together with the mobility management entity (MME) takes 290 care of mobility and the packet gateway (P-GW), which finally 291 terminates the actual mobile service. These elements are described 292 in detail in [TS.23.401]. Other important components are the home 293 subscriber system (HSS), the Policy and Charging Rule Function (PCRF) 294 and the optional components: the Traffic Detection Function (TDF) and 295 the Traffic Support Steering Function (TSSF), which are described in 296 [TS.23.203]. The P-GW interface towards the SGi-LAN is called the 297 SGi-interface, which is described in [TS.29.061]. The TDF resides on 298 this interface. Finally, the SGi-LAN is the home of service function 299 chains (SFC), which are not standardized by 3GPP. 301 +--------------------------------------------+ 302 | Control Plane (C) [HSS] | [OTT Appl. Platform] 303 | | | | 304 | +--------[MME] [PCRF]--+--------+ Internet 305 | | | | | | | 306 | [UE-C] -- [eNB-C] == [S-GW-C] == [P-GW-C] | | | 307 +=====|=========|==========|============|====+ +-----+----+-------+ 308 | | | | | | | | | | 309 | [UE-U] -- [eNB-U] == [S-GW-U] == [P-GW-U]-+--+----[SGi-LAN] | 310 | | | | | 311 | | | | | 312 | | | [Appl. Platform] | 313 | | | | 314 | User Plane (U) | | | 315 +--------------------------------------------+ +------------------+ 317 |<---------- 3GPP Mobile Network -------->| |<-- IP Backbone ->| 319 Figure 2: End to end context including all major components of an LTE 320 network. The actual 3GPP mobile network includes the elements from 321 the user equipment [UE] to the packet gateway [P-GW]. Labels ending 322 with -C denote control plane functionality and ending with -U user 323 plane functionality, respectively. Separation of control and user 324 plane is presented for a logical view and is not currently 325 standardized by 3GPP. 327 The radio-based IP traffic between the UE and the eNB is encrypted 328 according to 3GPP standards. Between eNB, S-GW and P-GW user IP 329 packets are encapsulated in 3GPP-specific tunnels. In some mobile 330 carrier networks the 3GPP-specific tunnels between eNB and S-GW are 331 even additionally IPSec-encrypted. More precisely, IPSec originates/ 332 terminates at the eNB and on the other side at an IPSec-GW often 333 placed just in front of the S-GW. For more details see [TS.29.281], 334 [TS.29.274] and [TS.33.210]. 336 Service function chains act on user plane IP traffic only. But the 337 way these act on user traffic may depend on subscriber, service or 338 network specific control plane metadata (see Section 2.4 for a 339 discussion of metadata in the context of this document). 341 2.2. Overview of mobile service chains 343 The original user IP packet, including the Source-IP-Address (S-IP) 344 of the UE and the Destination-IP-Address (D-IP) of the addressed 345 application platform (or any host in the Internet in general), leaves 346 the Packet Gateway from the mobile network via the so-called Gi- 347 interface (3G service, e.g., UMTS), respectively SGi-interface (4G 348 service, e.g., LTE). Between this (S)Gi-interface and the actual 349 application platform the user generated upstream IP packets and the 350 corresponding downstream IP packets are typically forced to pass an 351 ordered set of service functions, loosely called a Service Function 352 Chain (SFC). 354 The set of all available service functions (physical or virtualized) 355 which can be used to establish different Service Function Chains for 356 different services is often called a Gi-LAN for 2G/3G services and 357 SGi-LAN for 4G services. 359 The (S)Gi-interface towards the (S)Gi-LAN itself is discussed in 360 [TS.29.061], and service function chaining classification or traffic 361 steering is discussed in [TS.23.203]. 363 The (S)Gi-LAN service functions can use subscriber and service 364 related metadata delivered from the mobile control plane, such as the 365 PCRF, or from the user plane, e.g., via HTTP Header Enrichment to 366 process the flows according to service related policies. Some 367 service functions may even use network performance data describing 368 the actual momentary state of a network segment. 370 If a network operator utilizes HTTP Header Enrichment, care must be 371 taken that privacy is ensured by some mechanism especially when IP 372 service flows leave the operator's network towards a third party (see 373 Section 3.3.3). 375 In short, the (S)Gi-LAN service area is presently used by mobile 376 service providers to differentiate their services to their 377 subscribers and reflect the business model of mobile operators. 379 For different applications (e.g., Appl. 1,2,3) upstream and 380 downstream user plane IP flows will be forced to pass a sequence of 381 service functions which is called a Service Function Chain specific 382 to a given application. In the simple example sketched in Figure 3, 383 the service chains for applications 1, 2 and 3 may be just classified 384 by a unique interface-ID of the egress P-GW interfaces or TDF where 385 the service chains for application 1, 2 and 3 are attached. 387 +------------------------------------------------------------------+ 388 | Control Plane Environment [HSS] [MME] [PCRF] [others] | 389 +------------------------------------------------|-----------------+ 390 +--------------------+ 391 +---------------------------|--------------------|-----------------+ 392 | User Plane Environment | | | 393 | | /------(S)Gi-LAN --+-----\ | 394 | | | | | 395 | | | +---[SF1]-[SF3]-[SF5]---[Appl. 1] | 396 | | | / | | 397 | [UE]---[eNB]===[S-GW]===[P-GW/TDF]--[SF2]-[SF4]-[SF6]-------+ | 398 | | \ | | | 399 | | +---[SF7]-[SF8]-[SF9]-----+ | | 400 | | | | | | 401 | \------------------------/ | | | 402 | | | | 403 +----------------------------------------------------------|--|----+ 404 | | 405 OTT Internet Applications 406 | | 407 [Appl. 2] [Appl. 3] 409 Figure 3: Typical service chain topology. 411 Service functions typically observe, alter or even terminate and re- 412 establish application session flows between mobile user equipment and 413 application platforms. Control plane metadata supporting policy 414 based traffic handling may be linked to individual service functions 415 SFn. Because in Figure 3 the P-GW classifies service chains, we 416 consider the P-GW as a component of the service chaining environment. 417 However, more sophisticated classification schemes are possible and 418 discussed later. 420 Care must be taken in classifying and directing flows in different 421 directions (upstream versus downstream) or different flows from the 422 same subscriber when Service Functions observe or alter session 423 flows. Such functions can maintain local state that is necessary to 424 the correct functioning of session flows or to enforcing the policies 425 of the service provider (e.g., fair-use policies). Such stateful 426 service functions can require steering both upstream and downstream 427 directions of a flow through a single service function instance 428 (e.g., from a set of identical service function instances deployed 429 for scale) or for steering all flows with a common criteria (e.g., 430 belonging to the same subscriber) through such a single service 431 function instance. 433 2.3. The most common classification scheme 435 Mobile user equipment like smartphones, tablets or other mobile 436 devices use Access Point Names (APNs) to address a service network or 437 service platform. APNs are DNS host names comparable to FQDN (Fully 438 Qualified Domain Name) host names. While an FQDN refers to an 439 Internet IP address, an APN (loosely speaking) specifies a P-GW IP 440 address. These APNs are used to distinguish certain user groups and 441 their traffic, e.g., there can be an APN for a mobile service offered 442 to the general public while enterprise customers get their own APN. 443 For APN details see [TS.23.003]. 445 Operators often associate a designated Virtual LAN ID (VLAN-ID) with 446 an APN. A VLAN-ID n then may classify the service function chain n 447 (SFC n) related to an application platform n (Appl. n), as shown in 448 the following Figure 4. 450 +----------+ 451 | | 452 | IF-1 O [APN 1 => VLAN-ID 1] ---- [SFC 1] ---- [Appl. 1] 453 | | 454 =====| P-GW O . . . . 455 | | 456 | IF-n O [APN n => VLAN-ID n] ---- [SFC n] ---- [Appl. n] 457 | | 458 +----------+ 460 Figure 4: Association of a service chain to an application platform. 462 Examples for an APN are, e.g.: 464 +------------+-----------------+ 465 | APN: | web.vodafone.de | 466 | User Name: | not required | 467 | Password: | not required | 468 +------------+-----------------+ 470 Table 1: Example APN for Vodafone Germany 471 +------------+------------------+ 472 | APN: | internet.telekom | 473 | User Name: | t-mobile | 474 | Password: | tm | 475 +------------+------------------+ 477 Table 2: Example APN for Deutsche Telekom/T-Mobile 479 2.4. More sophisticated classification schemes 481 More sophisticated classifications are feasible using metadata that 482 is UE related, subscriber and service related, as well as network 483 related metadata. Typical metadata and their sources are: 485 UE: terminal type (e.g., vendor), IMSI (country, carrier, user) 487 GTP tunnel endpoint: eNB-Identifier, time, and many more 489 PCRF: subscriber info, APN (service name), QoS, policy rules 491 Mobile operator defined subscriber, service or network specific 492 policies are typically encoded in the 3GPP-based Policy and Charging 493 Rules Function (PCRF), see [TS.23.203]. For instance, a PCRF may 494 encode the rules that apply to pre-paid and post-paid users, users 495 with a classification of gold, silver, or bronze, or even as detailed 496 as describing rules that apply to "gold users, wishing to download a 497 video file, while these subscribers are subjected to a fair-usage 498 policy". It is up to the mobile service providers to encode the 499 precise mappings between its subscriber classes and the associated 500 service chains. 502 The Traffic Detection Function (TDF) is part of the 3GPP PCC (Policy 503 and Charging Control Architecture, [TS.23.203]) architecture. Such a 504 TDF, when deployed in the network, resides on the SGi interface, can 505 inspect the user traffic after leaving the P-GW function (see 506 Figure 4) and can maintain connections to the charging 507 infrastructure: Online Charging System (OCS) and Offline Charging 508 System (OFCS). The TDF can be used to classify traffic originating 509 from an APN into more detailed services. This can be used to 510 classify traffic into different Service Functions. 512 The Traffic Steering Support Function (TSSF) has also been defined 513 recently (since Rel. 13) as part of the 3GPP PCC architecture to 514 support classification of traffic into different Service Functions. 515 The TSSF does not have any connections into the charging 516 infrastructure (OFS or OFCS), but does maintain an interface (St) 517 into the PCRF. Over this interface, the PCRF can provision, modify 518 and remove classification rules for steering traffic into different 519 Service Functions. 521 +--------------------------+ 522 | PCRF | 523 +----+---------+-------+---+ 524 | | | 525 Gx-IF St-IF Sd-IF 526 | | | 527 +----+-----+ | | 528 ==========O [PCEF] O--------------------[SFC 1] ---- [Appl. 1] 529 | P-GW O--------------------[SFC 2] ---- [Appl. 2] 530 +----------+ | | 531 | | 532 +----------+ | +----+---+ 533 ==========O P-GW O------O [TDF] O----[SFC 1] ---- [Appl. 1] 534 | | | | O----[SFC 2] ---- [Appl. 2] 535 +----------+ | +--------+ 536 | 537 +----------+ ++-------+ 538 ==========O P-GW O--O [TSSF] O--------[SFC 1] ---- [Appl. 1] 539 | | | O--------[SFC 2] ---- [Appl. 2] 540 +----------+ +--------+ 541 * 542 3GPP Bearer SGi 544 Figure 5: 3GPP combined service chaining classification and steering 545 points. The Policy and Charging Enforcement Function (PCEF) and the 546 Traffic Detection Function (TDF) enforce policies received from the 547 PCRF and, in the other direction, the PCEF provides the PCRF with 548 subscriber and access information via Gx interface. The TSSF can 549 also be used by the PCRF over the St interface to steer traffic into 550 Service Functions. 552 In general, there are several possibilities to specify classification 553 and steering in mobile networks. Figure 5 demonstrates combined 554 classification and steering deployments. There are also separated 555 classification and steering deployments. 3GPP considers these 556 approaches: [TS.23.203]: 558 o Classification and steering by the P-GW alone with rules received 559 from Gx. 561 o Classification and steering by the TDF alone with rules received 562 from Sd. 564 o Classification and steering by the TSSF alone with rules received 565 from St. 567 o Initial classification by the P-GW (with rules received from Gx) 568 and steering by the TDF (with rules received from Sd). 570 o Initial classification by the TDF (with rules received from Sd) 571 and steering by the TSSF (with rules received from St interface). 573 3. Example use cases specific to mobile networks 575 HTTP via TCP port 80 (or TCP port 443 for HTTPS) is by far the most 576 common Internet traffic class. Therefore, we discuss two typical 577 examples of an associated service function chaining model in some 578 more detail. 580 The models presented below are simplified compared to real life 581 service function chain implementations because we do not discuss 582 differentiated traffic handling based on different subscriber- 583 specific service level agreements and price plans or even actual 584 network load conditions. 586 3.1. Service chain model for Internet HTTP services 588 With the increase of Internet traffic in mobile networks, mobile 589 operators have started to introduce Performance Enhancement Proxies 590 (PEPs) to optimize network resource utilization. PEPs are more or 591 less integrated platforms that ensure the best possible Quality of 592 Experience (QoE). Their service functions include but are not 593 limited to Deep Packet Inspection (DPI), web and video optimizations, 594 subscriber and service policy controlled dynamic network adaption, 595 analytics and management support. 597 A simple service function chain model for mobile Internet upstream 598 and downstream traffic is shown in Figure 6 below. The function 599 chain includes Load Balancers (LB), which split HTTP over TCP port 80 600 away from the rest of the Internet traffic. Beside basic web 601 content, this traffic class includes more and more video. To act on 602 this traffic type we force this traffic to pass Performance 603 Enhancement Proxies (PEPs). The firewall function (FW) protects the 604 carrier network from the outside and Network Address Translation 605 (NAT) maps the private IP address space dedicated to user equipment 606 to a public IP address. 608 [Cache] 609 | 610 [P-GW/TDF]---[LB]-------[PEP]--[LB]--[FW]---[NAT]---[Internet] 611 | HTTP:80 | 612 | | 613 | | 614 | non HTTP:80 | 615 +-----------------+ 617 Figure 6: Service function chain for HTTP traffic over TCP port 80. 619 The first application in this Service Chain example caches web 620 content to help reduce Round Trip Times (RTT) and therefore 621 contributes to improved web page load times. Optimizing RTT and 622 thereby improving Quality of Experience (QoE) is generally more 623 important for mobile service providers than reducing Internet peering 624 costs. Similar arguments hold for cached video content. We also 625 avoid potential large jitter imported from the Internet. 627 An example for non HTTP port 80 traffic in Figure 6 is UDP- 628 encapsulated IPsec traffic, which is dedicated to port 10000. Note 629 that in a real environment not only port 80 but for example 630 additional traffic via port 8080, 25 for SMTP, 110 for POP3 or 143 631 for IMAP may be forced to pass a service chain. 633 A second application is video optimization. Video content from the 634 Internet may not fit to the size of mobile device displays or simply 635 would overload the mobile network when used natively. Therefore 636 mobile operators adapt internet-based video content to ensure the 637 best QoE. 639 Video content optimization very often is also an additional premium- 640 related component in service offers and price plans. 642 A typical PEP environment for video optimization consists of three 643 basic service functions as shown in Figure 7: a steering proxy which 644 is able to redirect HTTP traffic, a DPI-based controller which checks 645 for video content and an optimizer which transcodes videos to an 646 appropriate format on the fly in real time. 648 [PEP for video] ==>> [Steering Proxy]---[DPI Contr.]---[Optimizer] 650 Figure 7: Service functions required for video optimization. 652 In Figure 8 we show one possible way for HTTP flows and their 653 redirection in some more detail. The intention here is to show every 654 elementary functional step in a chain as a separate physical or 655 virtualized item, but this state diagram does not necessarily reflect 656 every existing vendor-specific proprietary implementation. 658 Specifically, the Steering Proxy includes a TCP proxy and an ICAP 659 (Internet Content Adaptation Protocol) client which communicates with 660 an ICAP server residing in the controller function which is supported 661 by a L7 DPI. 663 The video optimization process acts on the downstream flow only. 665 [UE]----[Steering Proxy]----[DPI Contr.]----[Optimizer]----[Content] 667 |-- HTTP GET ->|-------------- HTTP GET ----------------------->| 669 |<------------- HTTP Response -------------------| 671 |-- Is it Video? ->| 673 |<-- Video found --| 675 |<--- HTTP ----| 676 Redirect 678 |-- HTTP GET ->|-----HTTP GET ---------------->| 680 |-- HTTP GET -->| 681 Video 683 |<--- HTTP -----| 684 Response 685 Orig. Video 687 {Optimize} 689 |<------- HTTP Response --------| 690 Transcoded Video 692 |-- Is it Video? ->| 694 |<-- Video found --| 696 |<--- HTTP ----| 697 Response 698 Transcoded Video 700 Figure 8: Flow diagram between UE and video optimization PEP. 702 In such an application scenario one may have reclassification or off- 703 loading on the fly. 705 Assume a video is streamed within a 4G LTE radio cell. The video 706 optimizer would then apply a transcoding scheme appropriate to the 707 abilities of the 4G network. If one is now leaving the 4G cell and 708 entering a 3G radio cell, the network conditions will most probably 709 become different and the video optimizer has to use another 710 transcoding scheme to keep a certain QoE. This requires that the 711 video optimizer service function is aware of the Radio Access 712 Technology (RAT) in use. One may transfer RAT type from the P-GW (or 713 Gateway GPRS Support Node (GGSN) in case of 3G traffic) via an 714 Authorization, Authentication and Accounting (AAA) Proxy to the 715 service function chain. The RAT information will then be embedded in 716 an appropriate Radius message. Other 3GPP steering mechanisms may 717 apply as well. 719 If for example the 4G network has sufficient bandwidth, one could 720 also think of another, different use case. The rule could be that 721 only 3G video streams are forced to pass the video optimizer while 722 all 4G video traffic will be bypassed. Bypassing certain Service 723 Functions is also known as off-loading. 725 Additionally, network utilization information can be used to trigger 726 the behavior of the service function. The degree of video 727 compression applied could depend on the actual current network load. 729 Last but not least the behavior of the video optimizer service 730 function (or any other service function) could additionally depend on 731 the user-specific service contract (price plan, gold, silver, bronze) 732 or on individual on demand requests. 734 3.1.1. Weaknesses of current approaches 736 This use case model highlights the weakness of current service 737 deployments in the areas of traffic selection, reclassification, and 738 multi-vendor support. Traffic in this example is classified after 739 the P-GW or TDF and separated into separate flows based on whether it 740 is (in this example) TCP traffic destined to port 80. This 741 classification could be done by the load balancer (see Figure 6), 742 possibly directed by a TSSF (not shown), if it initiates the service 743 chain selection, or the traffic can be reclassified at the load 744 balancer if the traffic is already embedded in a Service Chain (e.g., 745 when combined with other functions such as the TCP optimization in 746 the following use case). Multi-vendor support is needed because 747 every element in the use case can be provided by a different vendor: 748 load-balancer, HTTP proxy, firewall and NAT. 750 3.2. Service chain for TCP optimization 752 The essential parameters influencing TCP behavior are latency, packet 753 loss and available throughput. 755 Content servers are mostly attached to fixed networks. These are 756 characterized by high bandwidth and low latency. On the other side, 757 Radio Access Networks (RANs) tend to have higher latency, packet loss 758 and congestion. 760 The fixed network part will typically get a TCP Rx/Tx buffer size 761 different to that on the radio network side because buffer sizes are 762 typically set proportional to the latency (rule of thumb: 2 x latency 763 x bandwidth). 765 TCP cannot handle such disparate end-to-end situations very well. 766 One way to mitigate this problem is to use split TCP. However, even 767 without congestion, packet losses on the mobile network side may 768 result in time outs and finally cause the content server on the fixed 769 network side to stall. 771 Therefore mobile operators often use TCP optimization proxies in the 772 data path. These proxies monitor latency and throughput real-time 773 and dynamically optimize TCP parameters for each TCP connection to 774 ensure a better transmission behavior. 776 A rudimentary service chain setup for TCP optimization is shown in 777 Figure 9. Examples of non-TCP flows are UDP/RTP voice or video 778 traffic. 780 [P-GW]---[LB]----------[TCP Opt.]---[LB]---[FW]---[NAT]---[Internet] 781 | TCP | 782 | | 783 | non-TCP | 784 +--------------------------+ 786 Figure 9: Optimizing TCP parameterization in a mobile network. 788 3.2.1. Weaknesses of current approaches 790 This use case highlights weaknesses of current service deployments in 791 the areas of traffic selection, reclassification and multi-vendor 792 support as in the previous use case presented in Section 3.1. 794 3.3. HTTP header enrichment in mobile networks 796 3.3.1. HTTP header enrichment in legacy mobile data networks 798 In legacy mobile networks WAP (Wireless Application Protocol) 799 gateways mediated between traditional mobile phones and the Internet 800 translating HTML web content into a WML (Wireless Markup Language) 801 and vice versa. By functionality, WAP-GWs fit also in the SFC 802 category. 804 Traditionally WAP-GWs use HTTP header enrichment to insert subscriber 805 related data into WAP and HTTP request headers in real time. These 806 data were (are) used to identify and charge subscribers on third 807 party web sites. 809 3.3.2. HTTP header enrichment in modern mobile data networks 811 Today, in 3G and 4G mobile networks HTTP header enrichment is done by 812 the Gateway GPRS Support Node (GGSN)/P-GW/TDF or a dedicated 813 transparent HTTP optimizer as most of the data traffic on a mobile 814 network no longer passes a WAP-GW. 816 Information typically added to the header includes: 818 o Charging Characteristics 820 o Charging ID 822 o Subscriber ID 824 o GGSN or PGW IP address 826 o Serving Gateway Support Node (SGSN) or SGW IP address 828 o International Mobile Equipment Identity (IMEI) 830 o International Mobile Subscriber Identity (IMSI) 832 o Mobile Subscriber ISDN Number (MSISDN) 834 o UE IP address 836 3.3.3. HTTP header enrichment security condiderations 838 In today's networks HTTP header enrichment is commonly used across 839 operator and ISP boundaries. In such cases one must implement 840 security mechanisms, e.g., solutions which are based on a one-time, 841 session-based key exchanged between user equipment and third party 842 over the top (OTT) service platforms. 844 4. Remarks on QoS in mobile networks 846 As indicated in Figure 3, service functions may be linked to the 847 control plane to take care of additional subscriber or service 848 related metadata. In many cases the source of metadata would be the 849 PCRF and the link would be a Diameter-based Gx or Sd reference point. 850 Diameter is specified in [RFC6733], Gx/Sd in [TS.29.212] and St in 851 [TS.23.203]. 853 Service functions within the (S)Gi-LAN are less focused on the 854 explicit QoS steering of the actual mobile wireless network. QoS in 855 mobile networks is based on the 3GPP "Bearer" concept. A Bearer is 856 the essential traffic separation element enabling traffic separation 857 according to different QoS settings and represents the logical 858 transmission path between the User Equipment (UE) and the Packet 859 Gateway (P-GW). 861 5. Weaknesses of current implementations 863 In many operator environments every new service introduction can 864 result in a further dedicated (S)Gi-LAN service chain because service 865 chaining has been deployed historically in an ad hoc manner. 867 It typically requires placement of new functions in the operator's 868 data center, changing the actual wiring to include any new or changed 869 service function, configuration of the functions and network 870 equipment, and finally testing of the new configuration to ensure 871 that everything has been properly setup. 873 5.1. Granularity of the classification scheme 875 Often the coarse grained classification according to APNs is not fine 876 enough to uniquely select a service function chain or a processing 877 scheme within a service function chain required to support the 878 typical user-, service- or network- related policies which the 879 operator likes to apply to a specific user plane flow. 881 It is very likely that an APN, such as shown in Section 2.3, is 882 carrying an extremely diverse set of user traffic. This can range 883 from HTTP web traffic to real-time traffic. 885 5.2. Service chain implementations 887 In many carrier networks service chain LANs grow incrementally 888 according to product introductions or modifications. This very often 889 ends in a mix of static IP links, policy based routing or individual 890 VRF (Virtual Routing and Forwarding) implementations, etc. to enforce 891 the required sequence of service functions. Major weak points seen 892 in many carrier networks are: 894 o Very static service chain instances, hard-wired on the network 895 layer leads to no flexibility with respect to reusing, adding, and 896 removing service nodes and reprogramming service chains. 898 o Evolutionary grown "handcrafted" connectivity models require high 899 complexity to manage or maintain. 901 o Basic implementation paradigm is based on APNs (that is service 902 types) only, which requires individual injections of context- 903 related metadata to obtain granularity down to user/service level. 905 o There is currently no natural (or standardized) information 906 exchange on network status between services and the network, 907 complicating management of network resources based on subscriber 908 profiles. 910 o It is currently practically impossible to implement an automated 911 service provisioning and delivery platform. 913 o Scaling up flows or service chains with service or subscriber 914 related metadata is extremely difficult. 916 6. Operator requirements 918 Mobile operators use service function chains to enable and optimize 919 service delivery, offer network related customer services, optimize 920 network behavior or protect networks against attacks and ensure 921 privacy. Service function chains are essential to their business. 922 Without these, mobile operators are not able to deliver the necessary 923 and contracted Quality of Experience (QoE) or even certain products 924 to their customers. 926 6.1. Simplicity of service function chain instantiation 928 Because product development cycles are very fast in mobile markets, 929 mobile operators are asking for service chaining environments which 930 allow them to instantly create or modify service chains in a very 931 flexible and very simple way. The creation of service chains should 932 be embedded in the business and operation support layers of the 933 company and on an abstract functional level, independent of any 934 network underlay. No knowledge about internetworking technology 935 should be required at all. The mapping of the functional model of a 936 service chain onto the actual underlay network should be done by a 937 provisioning software package similar to that shown in Figure 10. 938 Details of the architecture and design are the subject of forthcoming 939 standards and proprietary implementation details. 941 +------------------------------------------------------------------+ 942 | Creation of an abstract service function chain | 943 +------------------------------------------------------------------+ 944 | 945 V 946 +------------------------------------------------------------------+ 947 | +----------------------------------------------------+ | 948 | | Service function chain compiler | | 949 | +----------------------------------------------------+ | 950 | | | 951 | V | 952 | +----------------------------------------------------+ | 953 | | Mediation device | | 954 | +----------------------------------------------------+ | 955 +------------------------------------------------------------------+ 956 | 957 V 958 +------------------------------------------------------------------+ 959 | Physical network underlay | 960 +------------------------------------------------------------------+ 962 Figure 10: Creation and provisioning system for service function 963 chains. 965 Service functions can be physical or virtualized. In the near future 966 the majority of mobile service functions will typically reside in the 967 local cloud computing environment of a mobile core location. 968 Nevertheless, first trials have shown that (virtualized) Service 969 Function interconnects via WAN links require careful latency 970 considerations. 972 Last but not least, any implementation must take into account that in 973 the migration phase a mixed infrastructure including virtual 974 machines, classical hardware "boxes" and bare metal based systems 975 (i.e., computes without using virtualization) must be supported. 977 6.2. Extensions 979 A service function chain should be generalized by a directed graph 980 where the vertices (nodes) represent an elementary service function. 981 This model allows branching conditions at the vertices. Branching in 982 a graph could then be triggered by typical 3GPP specified mobile 983 metadata (see Section 2.3) and allow for more sophisticated steering 984 methods in a service chain. Typically these data will be injected by 985 the mobile control plane, commonly but not exclusively by the PCRF 986 via a Diameter-based 3GPP Sd/St reference point. 988 Service chain behavior and output should additionally depend on 989 actual network conditions. For example, the selection of a video 990 compression format could depend on the actual load of the mobile 991 network segment a mobile user is attached to. That is to say that 992 classification of flows may allow very dynamic inputs while 993 specification of such inputs from a 3GPP network will need to be done 994 by 3GPP or another standards body. 996 Although necessary metadata can be obtained from the PCRF, to avoid 997 Diameter signaling storms in the (S)Gi-LAN, individual service 998 functions should probably not be attached individually to the control 999 plane. A mechanism where such metadata are carried by a metadata 1000 header can reduce requests to the PCRF, provided these extensions do 1001 not increase the original payload size too much. 1003 6.3. Reflections on Metadata 1005 At the moment we see just two types of metadata classes. Metadata 1006 which are static and related to subscriber and service policies 1007 typically reside in the control plane environment and dynamic 1008 metadata, which may reflect time and location dependent status 1009 somewhere in the network or other service platforms, e.g., load 1010 conditions or relevant network technology indicators. It may be 1011 useful to have proper interfaces to inject these metadata into the 1012 Service Function Chain domain. 1014 Summarized, metadata may by injected into individual Service Chain 1015 Functions: 1017 o asynchronously from the control plane environment by means of 1018 individual standardized interfaces, 1020 o synchronously, piggypacked with the user IP packet: 1022 * by means of a to-be-defined metadata header 1023 * or carried with http header enrichments within the user 1024 payload. 1026 6.4. Delimitations 1028 A clear separation between service chaining functionality and 3GPP 1029 bearer handling is required. This may be subject of forthcoming 1030 studies. 1032 7. Security Considerations 1034 Organizational security policies must apply to ensure the integrity 1035 of the SFC environment. 1037 SFC will very likely handle user traffic and user specific 1038 information in greater detail than the current service environments 1039 do today. This is reflected in the considerations of carrying more 1040 metadata through the service chains and the control systems of the 1041 service chains. This metadata will contain sensitive information 1042 about the user and the environment in which the user is situated. 1043 This will require proper considerations in the design, implementation 1044 and operations of such environments to preserve the privacy of the 1045 user and also the integrity of the provided metadata. 1047 8. IANA Considerations 1049 This document has no actions for IANA. 1051 9. Acknowledgments 1053 We thank Peter Bosch, Carlos Correia, Dave Dolson, Linda Dunbar, Alla 1054 Goldner, Wim Hendericks, Dirk von Hugo, Konstantin Livanos, Praveen 1055 Muley, Ron Parker, Nirav Salot and Takeshi Usui for valuable 1056 discussions and contributions. 1058 We especially thank Narseo Vallina Rodriguez (ICSI Berkeley 1059 University) for multiple discussions on HTTP header extensions and 1060 network security. 1062 10. References 1064 10.1. Normative References 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", BCP 14, RFC 2119, 1068 DOI 10.17487/RFC2119, March 1997, 1069 . 1071 10.2. Informative References 1073 [ietf-sfc-arch] 1074 Halpern, J. and C. Pignataro, "Service Function Chaining 1075 (SFC) Architecture", I-D draft-ietf-sfc-architecture-09 1076 (work in progress), June 2015. 1078 [ietf-sfc-dc-use-cases] 1079 Kumar, S., Tufail, M., Majee, S., Captari, C., and S. 1080 Homma, "Service Function Chaining Use Cases In Data 1081 Centers", I-D draft-ietf-sfc-dc-use-cases-03 (work in 1082 progress), July 2015. 1084 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 1085 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 1086 Partnership Project (3GPP) Evolved Packet System (EPS)", 1087 RFC 6459, DOI 10.17487/RFC6459, January 2012, 1088 . 1090 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 1091 Ed., "Diameter Base Protocol", RFC 6733, 1092 DOI 10.17487/RFC6733, October 2012, 1093 . 1095 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1096 Service Function Chaining", RFC 7498, 1097 DOI 10.17487/RFC7498, April 2015, 1098 . 1100 [TS.23.003] 1101 "Numbering, addressing and identification", 3GPP TS 23.003 1102 13.2.0, July 2015. 1104 [TS.23.203] 1105 "Policy and charging control architecture", 3GPP TS 23.203 1106 13.4.0, July 2015. 1108 [TS.23.401] 1109 "General Packet Radio Service (GPRS) enhancements for 1110 Evolved Universal Terrestrial Radio Access Network 1111 (E-UTRAN) access", 3GPP TS 23.401 13.3.0, July 2015. 1113 [TS.29.061] 1114 "Interworking between the Public Land Mobile Network 1115 (PLMN) supporting packet based services and Packet Data 1116 Networks (PDN)", 3GPP TS 29.061 13.0.0, March 2015. 1118 [TS.29.212] 1119 "Policy and Charging Control (PCC); Reference points", 1120 3GPP TS 29.212 13.2.0, July 2015. 1122 [TS.29.274] 1123 "3GPP Evolved Packet System (EPS); Evolved General Packet 1124 Radio Service (GPRS) Tunnelling Protocol for Control plane 1125 (GTPv2-C); Stage 3", 3GPP TS 29.274 13.2.0, July 2015. 1127 [TS.29.281] 1128 "General Packet Radio System (GPRS) Tunnelling Protocol 1129 User Plane (GTPv1-U)", 3GPP TS 29.281 12.1.0, January 1130 2015. 1132 [TS.33.210] 1133 "3G security; Network Domain Security (NDS); IP network 1134 layer security", 3GPP TS 33.210 12.2.0, December 2012. 1136 Authors' Addresses 1138 Walter Haeffner 1139 Vodafone 1140 Vodafone D2 GmbH 1141 Ferdinand-Braun-Platz 1 1142 Duesseldorf 40549 1143 DE 1145 Phone: +49 (0)172 663 7184 1146 Email: walter.haeffner@vodafone.com 1148 Jeffrey Napper 1149 Cisco Systems 1150 Cisco Systems, Inc. 1151 Haarlerbergweg 17-19 1152 Amsterdam 1101 CH 1153 NL 1155 Email: jenapper@cisco.com 1156 Martin Stiemerling 1157 NEC 1158 NEC Europe Ltd. 1159 Kurfuersten-Anlage 36 1160 Heidelberg 69181 1161 DE 1163 Email: mls.ietf@gmail.com 1165 Diego R. Lopez 1166 Telefonica I+D 1167 Don Ramon de la Cruz, 82 1168 Madrid 28006 1169 ES 1171 Phone: +34 913 129 041 1172 Email: diego@tid.es 1174 Jim Uttaro 1175 AT&T 1176 200 South Laurel Ave 1177 Middletown, NJ 07748 1178 US 1180 Email: uttaro@att.com