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