Service Function Chaining in Mobile Networks
Status draft-haeffner-sfc-use-case-mobility
IETF 89 London, 3 March 2014
Service Function Chaining WG
Walter Haeffner - walter.haeffner@vodafone.com, Jeff Napper - jenapper@cisco.com
Martin Stiemerling - mls.ietf@gmail.com, Diego R. Lopez - diego@tid.es
IETF 89 - London, UK - 3 March 2014
1
draft-haeffner-sfc-use-case-mobility
acknowledgement
We thank
Linda Dunbar
Ron Parker
Wim Hendericks
Alla Goldner
Dave Dolson
Peter Bosch
Praveen Muley
Carlos Correia, ......
for valuable comments
IETF 89 - London, UK - 3 March 2014
2
draft-haeffner-sfc-use-case-mobility
1 – context
Mobile network operators need to implement a complex array of single- (or few-) function
devices ( a.k.a. SFC) to control data traffic such that they can achieve their business goals.
per user
policy and charging
enforcement
PCRF
caches
3GPP Mobile Network
P-GW
DC
Appl.
• IPTV
• eMail
• VoIP
@
Appl.
• YouTube
• bing
• iTunes
> SFC <
protect network & privacy – FW, IDS, ACL, ...
optimize transport & payload – TCP Opt., Video Opt., ...
functions required for technical reasons – GC-NAT, DPI, LB, ...
merge signaling information into data flow - HTTP header enrichment, ...
network-based value added services – parental control, malware protection, ...
IETF 89 - London, UK - 3 March 2014
3
draft-haeffner-sfc-use-case-mobility
2 - objectives
 Understand importance of Service Function Chaining for
mobile network operators - Influence to their business
 Discuss Service Function Chains (SFC) in the context of mobile
network architectures – exemplary state of the art use cases
 Work out potential weaknesses in current environments and
derive operator requirements to support SFC WG objectives
 Compare with activities of other standard bodies, especially
clarify interaction between 3GPP and IETF SFC approach
 A possible dream SFC environment from an operator’s point
of view based on NFV, SDN, reflecting abstraction levels ....
IETF 89 - London, UK - 3 March 2014
4
draft-haeffner-sfc-use-case-mobility
3 – status draft
 Draft-00 issued 29 Jan. 2014
 Service chains supplement 3GPP policy and charging control architecture
 PCC and SFCs play a significant role in mobile service specifications
 SFCs often a sequence of “little” proprietary SFC implementations
 Therefore typically a hierarchy of inspections & classifications in place
 Discussed simple classification and flow steering schemes
 Sketched use case “video optimization” (L7) and “TCP optimization” (L4)
 Discussed weakness of current solutions and requirements to SFC WGs
 Draft-01 issued 14 Feb. 2014
 Added 3GPP R11 Traffic Detection Function (TDF) [3GPP TS.23.203]
 Allows for fine grained classification schemes and feedback to PCC
IETF 89 - London, UK - 3 March 2014
5
draft-haeffner-sfc-use-case-mobility
3 – status draft - basics of a video optimization SFC
Functional view of a model video optimizer SFC
classified
“video”
e.g. VoIP
P-GW
Crtl
DPI
DPI
DPI
LB
classified
“port 80”
classified
“web service”
Cache
Video
Video
Video
Opt.
Opt.
Opt.
LB
FW
NAT
@
“port 80 no video”
“non-port 80”
Draft-00 & draft-01 shows flow steering based on HTTP redirections
IETF 89 - London, UK - 3 March 2014
6
draft-haeffner-sfc-use-case-mobility
4 – outlook draft-02 to be published end of March
Discuss impact of re-classification and chains of value added services.
Load
Action/Forwarding
based on NW Load
PCRF
4G (LTE)
Video
SFC
GW
move
3G (UMTS)
RAT
RAT = 4G : opt .off
RAT = 3G : opt. on
VAS
Malware
Prevention
@
DPI
IETF 89 - London, UK - 3 March 2014
Port 80
@
7
draft-haeffner-sfc-use-case-mobility
5 – outlook draft-02 to be published end of March
Grown multi-vendor structures may become
very complex, inefficient, hard to understand and hard to manage
Video
Opt.
re-classify RAT
classified video
CRTL
DPI
Malware
Prev.
PCRF
classified port 80
P-GW
Web
APN
LB
DPI
Web
APN
LB
DPI
Web
APN
Video
Cache
classified port 80, non-video
FW
NAT
LB
@
classified
non-port 80
Analytics
Parental
Control
TCP
Opt.
vendor a
vendor b
vendor c
IETF 89 - London, UK - 3 March 2014
does not reflect wiring
and actual packet flow!
8
draft-haeffner-sfc-use-case-mobility
5 – Weaknesses and Requirements
Weaknesses in current deployments
 Per APN service chaining, in almost any case classification too coarse grained
 Means traffic often unnecessarily traverses a service function, no offloading
 Often ad hoc sequence of individual mini-chains, each with its own classification
 Results in multiple, individual DPI inspection systems, multiple LB batteries
 Is expensive, complex, inflexible, hard to modify/extend with reduced performance
Possible solutions
 Mobile network MUST exchange context with the IETF SFC classifier function
 SFC classifier MUST tag packets such that these enter only the SFs required
 Means bi- and unidirectional flows MUST be allowed
 Individual SFs MUST participate in multiple, different SFCs
 Creation/modification of SFCs including their branching rules SHOULD be done
in a simple to use SFC editor. Mapping onto the underlay MUST then be automatic.
IETF 89 - London, UK - 3 March 2014
9
draft-haeffner-sfc-use-case-mobility
6 – IETF SFC interactions with 3GPP PCC architecture
How to exchange 3GPP user & control plane metadata with IETF SFC?
Subscription Profile
Repository
Application
Functions
Sp
Online
Charging System
Rx
Sy
Metadata Exchange ?
PCRF
Gxx
BBERF
Access Network
Gateway
Gx
Gy
PCEF
IF
Sd
?
IETF
SFC-1
TDF
P-GW
IETF
SFC
Classifier
[DPI]
“3GPP Classifier”
3GPP PCC
Offline
Charging System
IETF
SFC-n
IETF SFC
BBERF: Bearer Binding and Event Reporting Function
IETF 89 - London, UK - 3 March 2014
10
draft-haeffner-sfc-use-case-mobility
7 – outlook draft-IETF 90
 Listed all use case classes required to verify universality
of SFC WG architecture and design paradigms for mobile.
 Isolate input to requirements and functional specifications.
 SFCs for fixed networks (xDSL, Cable) are typically a subset
of what is seen in mobile. List synergies w.r.t. FMC scenarios.
 Analyse requirements for the interaction between the 3GPP
and the IETF SFC classification schemes.
 Initiate a discussion to clarify how to proceed in case of
encrypted traffic (IETF 88 resolution).
IETF 89 - London, UK - 3 March 2014
11