1. Network Based Services in Mobile Networks Context, 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 20131

2. Context: Mobile Networks and Service Platforms Major Building Blocks of a LTE Service Platform IETF 87 - 29 July 20132 HSS MME PCRF Cell Aggregation Network Backhaul Network Backhaul Network S-GW P-GW eNB Home Subscriber System Mobility Management Entity Serving Gateway Packet Gateway Policy & Charging Rules Function LTE Control Plane LTE Data Plane Network Services (SGi-LAN) Operator Based Services Internet eNodeB PDN: Packet Data Network SGi  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 proxies for videos, TCP optimization & header enrichment, NAT, load balancers, caching, etc.  This class of services takes care of managing network traffic and network policing.

3. Context: Principle of Typical Hard-Wired SGi-LAN Services Current Common Approach – Logical View on Typical Use Cases IETF 87 - 29 July 20133 @ MPLS VPN Operator’s IMS (VoLTE) OTT Video Service P-GW Web Service for Smartphone User Fixed-Mobile-Converged Enterprise Service APN LB Web Proxy FW NAT APN SBC APN Video Optimizer Video Optimizer FW Video Service Operator’s IMS offer APN Router ACL Mobile Access APN: Access Point Name LB: Load Balancer FW: Firewall ACL: Access Control List SBC: Session Boarder Controller IMS: IP Multimedia Subsystem OTT: Over The Top Service related IP interface, VLAN

4. Problem: Hard-Wired SGi-LAN Services Current Common Approach – More Physical View on Typical SGi-LAN IETF 87 - 29 July 20134  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. Router LB/NAT DPI P-GW SGi Roaming FW Internet FW/NAT HTTP Optimizer TCP Optimizer TCP Optimizer Video Optimizer Video Optimizer HTTP Proxies PE Router GW Router to IMS to Internet IP BB Performance Enhancement Proxy (PEP) Caches

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

6. Requirement: High Degree of Freedom in Chain Creation Network provides us with sufficient Metadata to differentiate IETF 87 - 29 July 20136 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 P-GW PCRF GTP Tunnel Load Probe Load Probe PEP SGi Gx User Equipment (UE) Probes may deliver cell load, link loads, session loads etc. for real time network policing  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. BGP-TE/LS

7. Summary: IETF 87 - 29 July 20137  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.