Service Chaining overview (English) 2015/10/05

“Service Chaining”- Overview as of 2015/10/05 -

Service Chaining ~ Overview as of 2015/10/05

Kentaro Ebisawa | Twitter: @ebiken

1

• Objective of this document is to gather “Service Chaining” related information for below purposes.• Quickly go over current state of Service Chaining.• Reviewed as reference to documents, architecture diagrams and my current thoughts.

• “Service Chaining” is a technology area still rapidly evolving.• Many discussions about architectural design are ongoing.• Standardization of the reference architectures and protocols are still not finalized and could

change anytime. Refer to the original documents for the latest updates.

• Feedback is really appreciated.• Opinions mentioned in this document is as of today and could change in future after more input.

(maybe by input from you :-)• Information in this document could be not accurate as I wanted to be.• Pointing out any mistakes, different thoughts or additional information are welcomed.• Contact ebiken[at]gmail.com or twitter: @ebiken for any inputs and discussions.

Service Chaining ~ Overview as of 2015/10/05 2

about this slide deck

What is Service Chaining?Service Chaining


What is Service Chaining?

Service ChainingSteering of traffic flows through an ordered list of service functions.

Objective is to add elasticity by decupling it from network topology,

and achieve rapid deployment and glandular traffic steering.

Service Functions (Service Enablers)A function that is responsible for specific treatment of received packets.

A service function can act at various layers of a protocol stack.

e.g., at the network layer or other OSI layers. (from RFC7498)

(ex: NAT, antimalware, parental control, DDoS protection, load balancer etc.)


Where discussions are happening?Service Chaining


Where discussions are happening? 3GPP | IETF | ONF

3GPPTR 23.718: Architecture Enhancement for Flexible Mobile Service Steering

http://www.3gpp.org/DynaReport/23718.htm

• Enhancements required for 3GPP systems to provide flexible mobile service steering policies are discussed in the document.

• Topology and steering of flow among service functions (anything inside SGi-LAN) are Out of Scope and expected to be implemented by using effort of other Standardization Organization. (ex: IETF, ONF)

• Two Key Issues are discussed in the document.• Key Issue 1: Interface for provisioning of traffic steering policy.• Key Issue 2: Semantics of traffic steering policy.





Overview of LTE network

• eNB : enhanced NodeB, radio access part of the LTE system• S-GW : Serving Gateway, primary function is user plane mobility• P-GW : Packet Gateway, actual service creation point, terminates 3GPP

mobile network, interface to Packet Data Networks (PDN)• HSS : Home Subscriber Server (control plane element)• MME : Mobility Management Entity (control plane element)• PCRF : Policy and Charging Rule Function• PCEF : Policy and Charging Enforcement Function• SGi : Egress termination point of the mobile network. The internal data

structure not standardized by 3GPP.• TDF: Traffic Detection Function• SCTCF: Service Chain Traffic Controller Function

E-UTRAN

EPC

SGi-LAN

eNodeB

UE: User equipment (ex: tablets or smartphones)

MME S-GW

HSS

PCRF

P-GW

PCEF

Gx

SGi

Sd

St

Referenced from draft-ietf-sfc-use-case-mobility-04

SGi

SCTCFService Functions

Forwarding EntitiesClassifiersTDF

(Evolved Packet Core)

ExternalNetwork


Key Issue 1: Interface for provisioning of traffic steering policy

4 solutions are discussed for Key Issue 1


SolutionInterface and entity enhanced to signal the policy and mark packets for steering traffic.

1.1Leveraging of the existing PCC framework with Sd interface

Sd interface and PCRF, TDF

1.2Leveraging of the existing PCC framework with Gx interface

Gx interface and PCRF, PCEF/PGW

1.3 Dual-Classifier SolutionIntroducing TCFd, which is TCF for down stream traffic. (In addition to Solution 1.1, 1.2)

1.4 Service steering policy interfaceIntroducing St interface and SCTCF(*) residing in SGi-LAN. (In addition to Solution 1.1, 1.2, 1.3)

(*) SCTCF: Service Chain Traffic Controller Function



Key Issue 1: Interface for provisioning of traffic steering policy1.1 Leveraging of the existing PCC framework with Sd interface

TR 23.718: Architecture Enhancement for Flexible Mobile Service Steeringhttp://www.3gpp.org/DynaReport/23718.htm




Key Issue 1: Interface for provisioning of traffic steering policy1.2 Leveraging of the existing PCC framework with Gx interface





Key Issue 1: Interface for provisioning of traffic steering policy1.3 Dual-Classifier Solution





Key Issue 1: Interface for provisioning of traffic steering policy1.4 Service steering policy interface




Key Issue 2: Semantics of traffic steering policyDescription of information exchanged to achieve traffic steering

• Traffic Steering Rule (TSR)• Identifies the service functions traffic needs to be steered for a given IP/subscriber

session.• Components of TSR:

• TSR-Name• Service-Description: Identifies a specific UE traffic. (ex: 5 tuples, application id)• Traffic-Steering-Policy-Identifier: reference to a pre-configured set of service functions.• Precedence: Priority order of the traffic steering policy.

• Interfaces used to provide TSR• Sd/Gx Interface (PCRF <> PCEF/TDF)• St Interface (PCRF <> SCTCF)


Refer to tables below for details of information included in each components of TSR* Sd/Gx : Table 6.2.1.1.2-1: Mapping of components of TSP to information over Sd/Gx interface* St : Table 6.2.1.3.1.1-1: The TS Rule Information


• Describing Service Chaining• [TR.22.808] Study on Flexible Mobile Service Steering (FMSS)• [TR.23.718] Architecture Enhancement for Flexible Mobile Service Steering

• Not directly but closely related.• [TS.23.203] Policy and charging control architecture• [TS.29.212] Policy and Charging Control (PCC); Reference points

• Good to read to understand 3GPP terms and technology.• [TR 21.905] Vocabulary for 3GPP Specifications• [TS.23.003] Numbering, addressing and identification• [TS.23.401] General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network

(E-UTRAN) access• [TS.29.061] Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and

Packet Data Networks (PDN)• About SGi-interface

• [TS.29.274] 3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3

• [TS.29.281] General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)


Other 3GPP documents related to Service ChainingTR: Technical ReportTS: Technical Specification


IETF : Service Function Chaining WGhttp://datatracker.ietf.org/wg/sfc/

• Defines a new encapsulation format (NSH) which includes:• Service Path ID which specifies the Service Function Path. • Service Index which is a sequence number of service functions.• Context Header and Metadata to pass context information between nodes.

• Also discussing / defining below in Internet-Drafts and RFCs.• Problem Statement and Use Cases.• Architectural building blocks and their relationships.• Control Plane Mechanisms and Manageability.

(*) NSH … Network Service Header


http://datatracker.ietf.org/wg/sfc/



https://datatracker.ietf.org/wg/sfc/documents/

Internet-Draft / RFC under SFC-WG

1. Read this first to get overview

3. Use Cases

2. Encap Format (NSH)

https://datatracker.ietf.org/wg/sfc/documents/



Roles defined in IETF SFC

Classifier Forwarder

Proxy

SFSF

SFSF

NSH Label aware SFs.

NSH Label un-aware SFs.Labeled

Not Labeled

Could be on same physical box or on different boxes / VMs.

Packet NSH

Packet

Use Case ModelsService Chaining


Use Case Models

• Document below describes use case model in Mobile environment.• “Service Function Chaining Use Cases in Mobile Networks”• draft-ietf-sfc-use-case-mobility-04

• Possible Service Functions discussed in the document.• Performance Enhancement Proxies (PEPs)• Deep Packet Inspection (DPI)• Web and Video optimizations• Subscriber and service policy controlled dynamic network adaption• Analytics and management support• TCP optimization• HTTP header enrichment


Use case model in Mobile environment

Use Case Models

• Classification Scheme• Classification at P-GW based on APN.

• Classification at PCEF and TDF.

• Typical metadata and their sources:• 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


Use case model in Mobile environment

PCEF : Policy and Charging Enforcement FunctionTDF : Traffic Detection FunctionPCRF : Policy and Charging Rules Function

https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/

https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/

Use Case Models

• Document below describes use case model in Mobile environment.• “Service Function Chaining Use Cases In Data Centers”• draft-ietf-sfc-dc-use-cases-03

• Possible Service Functions discussed in the document.• Firewalls (Edge, Segment and Application)• WAN and application acceleration• Deep Packet Inspection (DPI)

• Intrusion Detection and/or Prevention System (IDS/IPS)• Server Load Balancers, Application Delivery Controller (ADC)• NAT44 [RFC3022], NAT64 [RFC6146]• HOST_ID injection• HTTP Header Enrichment functions• TCP optimizer• Monitoring


Use case model in Data Center environment

Use Case Models

• Traffic and associated SFCs in Data Center are classified into two types.1. North-South Traffic / SFC.

• Originates from outside the data center.

• Typically associated with users at onsite, remote and VPN

• Traverse among Service Functions below.

2. West-East Traffic / SFC.• Traffic steered among servers inside Data Center to instantiate services.


Use case model in Data Center environment

ImplementationService Chaining


Service Chaining Implementation

1. Classify and forward based on existing protocol headers.• Fastest way to start Service Chaining deployment.• Pros: Could use existing OpenFlow switches.• Cons: Requires many rules. (hardware switches might not be capable)

2. Introduce new header, NSH.• Discussed as “Service Function Chaining (SFC)” in IETF SFC WG.• Pros: Requires less rules.• Cons: No production level implementation exists.• Cons: Service Function need to support it. (or use proxy)

• Mix of the above two could be used during transition phase.


Two ways to implement Service Chaining

Service Chaining Implementations

• Hardware based Forwarder / Proxy / Classifier.• Switches supporting OpenFlow are available from multiple vendors.

• However, most OpenFlow SWs lack flexibility of pipeline and scalability of flow rules.• No switch available supporting the new header discussed at IETF, NSH.

• Some vendors has POC implementation using NPU, but not shown public yet.

• Software based Forwarder / Proxy / Classifier.• VXLAN+NSH patch for OVS by Pritesh Kothari at Cisco.

• https://github.com/pritesh/ovs/tree/nsh-v8• https://www.ietf.org/proceedings/92/slides/slides-92-sfc-8.pdf

• Controller / Orchestrator• OpenDaylight

• https://wiki.opendaylight.org/view/Service_Function_Chaining:Main• Discussion to extending OpenFlow protocol to support NSH is ongoing.

• Service Function• None, as far as I’m aware of.


Available implementations as of 2015 Oct.

https://github.com/pritesh/ovs/tree/nsh-v8

https://www.ietf.org/proceedings/92/slides/slides-92-sfc-8.pdf

https://wiki.opendaylight.org/view/Service_Function_Chaining:Main

What do we need to move forward?Service Chaining


What do we need to move forward?

• Network ASIC needs to support flexible rules and more flow rules.

• Increase of TCAM size & programmable pipeline support is required.• Programmable pipeline is ready by Cavium XPliant.

• http://www.cavium.com/XPliant-Ethernet-Switch-Product-Family.html

• Maybe on Broadcom Tomahawk as well, but details not disclosed to public.

• No ASIC with large TCAM yet• 40+Mbit TCAM to support 100K+ rules with IPv6 + 5 tuple

• Many core servers with DPDK could improve performance significantly.• Open Data Plane (ODP) + ARM many core actively working.

• http://www.opendataplane.org/


Classifier + Forwarder (without NSH)

http://www.cavium.com/XPliant-Ethernet-Switch-Product-Family.html

http://www.opendataplane.org/


• High performance Hardware Switch supporting NSH as Forwarder.• Support of NSH is the only missing piece.

• Should be possible by next year using new ASICs already announced today.

• Classifier scale out• Software Scale out?

• Many classifier entities on VMs or Many Core Server.

• Good especially when parsing metadata in NSH is required.

• How to distribute among classifier entities need consideration to avoid re-ordering of packets in same flow.• ECMP hash based on source IP address, 5 tuple or both?


Classifier + Forwarder (with NSH)


• Proxy to Pop/Push NSH based on pre-defined rule• Hardware Switch with NSH support should have best cost/performance.

• Co-existing with Classifier / Forwarder might be possible and feasible.

• More feature rich Proxy• Using metadata info in NSH will require to keep state on Proxy.

• Software Scale Out design might be suited.

• Could be a place to inject new features still not thought of.


SFC (NSH) Proxy


Contact [email protected] or Twitter: @ebiken

• More study required on ideal architecture and transition plan.

• Phased approach would be required especially for enterprise datacenter use case.• Cannot replace all switches to support NSH at once.

• Need more POC and production implementation.• Switch using new Network ASIC or FPGA/NPU.

• Enhancements to Linux Kernel, Software Switch (OVS, Lagopus etc.)

• Many core SoC is also an option.


Interested for more discussions or hacking together?

mailto:[email protected]

Technology

Service Chaining overview (English) 2015/10/05