Network Based Services in Mobile Networks Context, Typical Use Cases, Problem Area, Requirements

1. Network Based Services in Mobile NetworksContext, Typical Use Cases, Problem Area, Requirements IETF 87 Berlin, 29 July 2013 BoF Meeting on Network Service Chaining (NSC) walter.haeffner@vodafone.com n.leymann@telekom.de IETF 87 - 29 July 2013

2. Context: Mobile Networks and Service PlatformsMajor Building Blocks of a LTE Service Platform LTE Control Plane HSS Home Subscriber System Policy& ChargingRulesFunction LTE Data Plane PDN: Packet Data Network MME PCRF Mobility Management Entity OperatorBased Services NetworkServices(SGi-LAN) SGi eNB Cell AggregationNetwork Backhaul Network S-GW P-GW eNodeB Internet ServingGateway PacketGateway • SG-interface is the 3GPP reference point between P-GW and Packet Data Network. • SGi protocol structure, data content, scope not specified (equal for Gi in 3G networks). • Operator based services like, VoLTE, Mail, Web, RCS-e/Joyn, SMS, MMS not in scope. • Scope here: network services like firewalls, DPI, performance enhancement proxiesfor videos, TCP optimization & header enrichment, NAT, load balancers, caching, etc. • This class of services takes care of managing network traffic and network policing. IETF 87 - 29 July 2013

3. Context: Principle of Typical Hard-Wired SGi-LAN ServicesCurrent Common Approach – Logical View on Typical Use Cases Web Service for Smartphone User P-GW @ LB WebProxy FW NAT APN Fixed-Mobile-Converged Enterprise Service Mobile Access RouterACL APN MPLS VPN Operator’s IMS offer Operator’s IMS (VoLTE) SBC APN Video Service APN: Access Point Name LB: Load BalancerFW: FirewallACL: Access Control List SBC: Session Boarder ControllerIMS: IP Multimedia SubsystemOTT: Over The Top OTT Video Service Video Optimizer FW APN Service related IP interface, VLAN IETF 87 - 29 July 2013

4. Problem: Hard-Wired SGi-LAN ServicesCurrent Common Approach – More Physical View on Typical SGi-LAN GWRouter PE Router to IMS to Internet IP BB TCP Optimizer HTTPOptimizer PE Router Router Performance EnhancementProxy (PEP) DPI LB/NAT Caches InternetFW/NAT RoamingFW Video Optimizer HTTPProxies • With deployment of additional value-added services increasing number of functions required in SGi-LAN. Some functions in dedicated devices, sometimes multiple functions in one box. • Due to fast service introduction cycles service chains emerge, growth & change evolutionary. • Very often static IP links, policy routing, VRFs etc. used to enforce required service sequence. • Results in steadily increasing, handcrafted complexity and decreased visibility of functional dependencies between service chains and underlying LAN topology. Means expensive OAM. • Practically impossible to implement automated service provisioning and delivery platform. SGi P-GW IETF 87 - 29 July 2013

5. Requirement: Simplicity, Flexibility, Speed, ExpandabilityVision: Service Chain Abstraction and Network Compilation • Create Service Function Topology • Define Branch Conditions graphs uni- orbidirectional 4 1 2 6 Compiler not yet invented creates Configuration for Service Chains Abstract service 1 3 5 Abstract link S1 (virtual) service engine Mediation Device (virtual) forwarding device S4 S1 S5 S2 S6 S3 • Preference for Telco Cloud • Forwarding Topologies for multiple service chains • Branching rules in services Physical Layer IETF 87 - 29 July 2013

6. Requirement: High Degree of Freedom in Chain CreationNetwork provides us with sufficient Metadata to differentiate Some metadata in P-GW state UE: terminal type (HTC one) IMSI (country, carrier, user) GTP Tunnel: eNB-ID time PCRF: user APN (service) QoS policy PCRF Gx P-GW PEP Load Probe GTP Tunnel SGi User Equipment (UE) Probes may deliver cell load,link loads, session loads etc. for real time network policing BGP-TE/LS • We may connect all relevant service functions with all relevant sources for metadata or • We may piggyback metadata information with the IP packets traversing a service chain. • Piggybacking metadata seems to be more straightforward than picking them out with DPI. IETF 87 - 29 July 2013

7. Summary: • Market dynamics accelerate need and demand for more services at an even faster rate. • With current approaches network service LANs and their service chains become more and more complex, error-prone, hard to manage and hard to extend. It’s a dead end street. • Vision is to decouple creation of service topologies and their internal branching conditions from the creation of the associated underlying packet forwarding (overlay) network. • Operators think in terms of an ordered sequences of network services (more precisely graphs) selected out of a service pool and define forking conditions in the service graphs based on metadata sets including user data, related service classes, type of user equipment in use, network conditions etc. • (Conditional) forwarding decisions done in a network service node may allow for more real time flexibility than more static service topology paths in an underlying network. • We would appreciate if IETF agrees to start a WG on Network Service Chaining analyzing requirements and specifying solutions also supporting virtualized service environments. IETF 87 - 29 July 2013