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