IETF SFC active drafts PRESENTER: VU ANH VU

Content 1.Service Function Chaining Use Cases In Data Centers 2.Service Function Chaining Use Cases in Mobile Networks 3.Hierarchical Service Function Chaining 2

Service Function Chaining Use Cases in Data Centers 3

Data centers characteristic Data center topologies follow a hierarchical design with core, aggregation, access and virtual access layers of network devices Service nodes are often deployed at compute or virtual access layers as well as physical access layers In large scale networks, such as carrier networks, there are many data centers distributed across large geographies Deploying SFs at different points in the network to apply service functions to different types of traffic: Traffic originating and destined in data center Traffic originating at a location remote and destined in data center Traffic originating at a location remote and destined a location remote, but transiting through the DC 4

North-South Traffic Originates from outside the DC Typically associated with users Typically destined to applications or resources hosted in the DC Requires traffic be analyzed, application and users be identified, transactions be authorized, and at the same time security threats be mitigated or eliminated Various SFs are deployed in different SNs at various topological locations in the network. The SNs are selected based on the policy require for the specific use case 5

North-South Traffic Samples SFC-1. EdgeFW The simplest of use cases where a remote or mobile worker accesses a specific DC server Traffic comes into the data center on VPN and is terminated on the EdgeFW EdgeFW subjects the traffic to its policies, which may in turn select other service functions such as DPI, IPS/IDS, hosted on the EdgeFW or outside the EdgeFW and reachable via VLAN segments SFC-2. EdgeFW : ADC Traffic is destined to a data center application that is front-ended by an ADC ADC - virtual destination - based on local policy, which includes among other things predictors to select the real destination, determines the appropriate application instance ADCs are stateful and ensure the return traffic passes through them by performing source NAT 6

North-South Traffic Samples SFC-3. EdgeFW : ADC : AppFW The segment where the application server resides may be shared with other applications and resources AppFW segregate these applications and resources with required policies SFC-4. WOC : EdgeFW : ADC : AppFW Represents the use case where users at a branch office access the DC resources WOC treated traffic is subject to firewall policies, which may lead to the application of SFs such as protocol inspection, DPI, IDS/IPS and then forwarded to its virtual destination, the ADC SFC-5. WOC : EdgeFW : MON : ADC : AppFW Additional service - MON, is used to collect and analyze traffic entering and leaving the DC 7

East-West Traffic The predominant traffic in data centers today The key difference with east-west from the north-south traffic is in the kind of threats and the security: threat to this traffic comes from within the DC instead of outside ADCs, although shown as isolated SNs in each of the tiers, is often consolidated into a smaller number of ADC SNs shared among the different tiers Traffic traversing between the ADC and the selected server in each tier, is subject to monitoring and one or more application firewalls specializing in different kinds and aspects of threats 8

East-West Traffic Sample SFC-6. SegFW : ADC : MON : AppFW In a typical three tiered architecture, requests coming to a webserver trigger interaction with application servers, which in turn trigger interaction with the database servers Each of these tiers are deployed in their own segments or zones for isolation, optimization and security SegFW enforces the security policies between the tiers ADC provides the distribution, scale and resiliency to the applications AppFW protects and isolates traffic within the segment in addition to enforcing application specific security policies Monitoring service enables visibility into application traffic, used to maintain application performance levels 9

Multi-tenancy Multi-tenancy is relevant in both enterprise as well as service provider DCs Multi-tenant service delivery is achieved in two primary ways: SNs themselves are tenant aware - every SN is built to support multiple tenants. SN instances are dedicated for each tenant  In both cases, the SP manages the SNs To support multi-tenant aware service functions or SNs, traffic being serviced by a service function chain has to be identified by a tenant identifier It is typical of tenant assets to be deployed in an isolated layer2 or layer3 domain such as VLAN, VXLAN The SNs themselves maybe deployed in different domains => using the domain in which the SN is deployed is not an option 10

SFCs in data centers At a high level the SFCs can be broadly categorized into two types: Access SFCs: focused on servicing traffic entering and leaving the DC Application SFCs: focused on servicing traffic destined to applications Service providers deploy a single "Access SFC" and multiple "Application SFCs" for each tenant Enterprise data center operators on the other hand may not have a need for Access SFCs depending on the size and requirements of the enterprise 11

Inter-datacenter SFCs In carrier networks, operators may deploy multiple DCs geographically Each data center may host different types of service functions SFCs may span multiple data centers and enable operators to deploy services in a flexible and inexpensive way Inter-datacenter SFC must consider many design aspects, two important among them are : Handing over context data: Metadata sharing among SFC components enables many use cases and services Multiple classification points: In a large SFC domain containing multiple datacenters distributed over large geographies, classification of incoming traffic and outgoing traffic may happen at different points 12

Inter-datacenter SFCs with multiple SFC domains Services are provided by SFCs spanning multiple independent SFC domains SFC management is limited to each domain: Control plane is constrained to its SFC domain SFCs are fragmented and initiated in each SFC domain A method of forwarding packets between data centers is required. Simple to control and manage the SFC domain. However, it is difficult to hand over context data between data centers 13

Inter-datacenter SFC with single SFC domains Services are provided across multiple data centers, which are connected with virtualized paths and grouped into a single SFC domain Easy to hand over context data between data centers, but control of SFC domains becomes complex as integrated operation across multiple data centers is required 14

Service Function Chaining Use Cases in Mobile Networks 15

Mobile service chains Important use case classes for service function chains: functions to protect the carrier network and the privacy of its users(IDS, FW, ACL, encryption, decryption, etc.) functions that ensure the contracted quality of experience: video optimizers, TCP optimizers functions like HTTP header enrichment that may be used to identify and charge subscribers real time functions like Carrier Grade NAT (CG-NAT) and NAPT, which are required solely for technical reasons functions like parental control or malware detection that may be a cost option of a service offer 16

End-to-end carrier networks structure 17

Mobile network overview 18

Overview of mobile service chains Between this (S)Gi-interface and the actual application platform the user generated upstream IP packets and the corresponding downstream IP packets are typically forced to pass a Service Function Chain (S)Gi-LAN service area is presently used by mobile service providers to differentiate their services to their subscribers and reflect the business model of mobile operators 19

Most common classification scheme Operators often associate a designated Virtual LAN ID (VLAN-ID) with an APN. A VLAN-ID n then may classify the service function chain n (SFC n) related to an application platform n (Appl. n) 20 Mobile user equipment use Access Point Names (APNs) to address a service network or service platform

More sophisticated classification schemes More sophisticated classifications use metadata: UE: terminal type (e.g., vendor), IMSI (country, carrier, user) GTP tunnel endpoint: eNB- Identifier, time, and many more PCRF: subscriber info, APN (service name), QoS, policy rules 21

Example use cases Service chain model for Internet HTTP services Mobile operators have started to introduce Performance Enhancement Proxies (PEPs) to optimize network resource utilization: integrated platforms that ensure the best possible QoE Include: DPI, web and video optimizations, analytics and management support, etc Application: caches web content to help reduce Round Trip Times video optimization 22

Service chain for TCP optimization Content servers are mostly attached to fixed networks - characterized by high bandwidth and low latency. Radio Access Networks (RANs) tend to have higher latency, packet loss and congestion Mobile operators often use TCP optimization proxies in the data path These proxies monitor latency and throughput real-time and dynamically optimize TCP parameters for each TCP connection to ensure a better transmission behavior 23

HTTP header enrichment in mobile networks 3G and 4G mobile networks HTTP header enrichment is done by the Gateway GPRS Support Node (GGSN)/P-GW/TDF or a dedicated transparent HTTP optimizer Information typically added to the header includes: Charging Characteristics Charging ID Subscriber ID GGSN or PGW IP address Serving Gateway Support Node (SGSN) or SGW IP address International Mobile Equipment Identity (IMEI) International Mobile Subscriber Identity (IMSI) Mobile Subscriber ISDN Number (MSISDN) UE IP addres 24

Hierarchical Service Function Chaining 25

Hierarchical SFC 26 Allowing an SFC to be decomposed from a large-scale network into multiple domains Each domain is managed by an independent SFC manager Top-level service function paths carry packets from classifiers through a series of SFFs and sub-domains, with the operations within sub-domains being opaque to the higher levels

Hierarchical SFC benefits SFC across a large, geographically dispersed network comprised of millions of hosts and thousands of network forwarding elements, involving multiple operational teams (with varying functional responsibilities) Simplify the mechanisms of scaling in and scaling out service functions All of the complexities of load-balancing among multiple SFs can be handled within a sub- domain, under control of the classifier Allowing the higher-level domain to be oblivious to the existence of multiple SF instances 27

Top Level Top-level network domain includes SFC components distributed over a wide area: Classifiers (CFs) Service Function Forwarders (SFFs) Sub-domains Top-level service function paths carry packets from classifiers through a series of SFFs and sub-domains, with the operations within sub- domains being opaque to the higher level Packets are classified at the edge of the network to select the paths by which sub-domains are to be traversed 28

Lower Level Data packets entering the sub-domain are already encapsulated within SFC transport Each sub-domain intersects a subset of the total paths that are possible in the higher-level domain Each sub-domain to have a control- plane that can operate independently of the top-level control-plane. The sub-domain control-plane configures the classification and forwarding rules in the sub-domain 29

Internal Boundary Node IBN bridges packets between domains. It looks like an SF to the higher level, and looks like a classifier and end-of-chain to the lower level. An operator of a lower-level SF Domain may be aware of which high-level paths transit their domain, or they may wish to accept any paths IBN should be applying more granular traffic classification rules at the lower level than the traffic passed to it. This means that the number of SF Paths within the lower level is greater than the number of SF Paths arriving to the IBN 30

IBN Path Configuration When packets enter the sub-domain, the Service Path Identifier (SPI) and Service Index (SI) are re-marked according to the path selected by the classifier After exiting a path in the sub-domain, packets can be restored to an original upper- level SF path by these methods: Saving SPI and SI in transport-layer flow state Pushing SPI and SI into metadata Using unique lower-level paths per upper-level path coordinates. Nesting NSH headers, encapsulating the higher-level NSH headers within the lower-level NSH headers. 31

Gluing Levels Together The SPI or metadata on a packet received by the IBN may be used as input to reclassification and path selection within the lower-level domain Decrementing Service Index: IBN acts as a Service Function to the higher-level domain, it must decrement the Service Index in the NSH headers of the higher-level path Sub-domain Classifier: Within the sub-domain (referring to Figure 2), after the IBN removes higher-level encapsulation from incoming packets, it sends the packets to the classifier, which selects the encapsulation for the packet within the sub-domain 32

References 1. draft-ietf-sfc-dc-use-cases-04 - Service Function Chaining Use Cases In Data Centers draft-ietf-sfc-use-case-mobility-05 - Service Function Chaining Use Cases in Mobile Networks draft-dolson-sfc-hierarchical-05 - Hierarchical Service Function Chaining

34