docGi-LAN Use Cases
download 
Report Transcription
Gi-LAN Use Cases
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 - [email protected], Jeff Napper - [email protected] Martin Stiemerling - [email protected], Diego R. Lopez - [email protected] 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
