1. J. Halpern (Ericsson), C. Pignataro (Cisco)
Service Function Chaining (SFC) Architecture Request for Comments: 7665
J. Halpern (Ericsson), C. Pignataro (Cisco)
Presenter : Do Truong Xuan

2. Introduction The current service function deployment models
static, coupled to network topology and physical resources, greatly reducing or eliminating the ability of an operator to introduce new services or dynamically create service function chains

3. Scope The SFC architecture
topological independence from the underlying forwarding topology
packets are classified on ingress for handling by the required set of Service Functions. Packets may be reclassified as a result of this processing
independent of the planned usage of the network and deployment context, applicable to both fixed and mobile networks
is assumed to be applicable to a single network administrative domain

4. Assumptions no standard definition for SFs
no global or standard SF chaining logic
The chaining of SFs and the criteria to invoke them are specific to each administrative entity
Several SF chaining policies can be simultaneously applied within an administrative domain
The underlay is assumed to provide the necessary connectivity to interconnect the Service Function Forwarders
How to bind traffic to a given SF chain is policy-based

5. Definition of terms Network Service Classification Classifier
An offering provided by an operator that is delivered using one or more service functions
Classification
matching of traffic flows against policy for subsequent application of the required set of network service functions
Classifier
An element that performs Classification

6. Definition of terms Service Function Chain (SFC) Service Function (SF)
ordered set of abstract service functions
Service Function (SF)
responsible for specific treatment of received packets
Multiple occurrences of the service function can exist in the same administrative domain
SF may be SFC encapsulation aware or unaware

7. Definition of terms Service Function Forwarder (SFF) Metadata
responsible for forwarding traffic to one or more connected service functions according to information carried in the SFC encapsulation
Metadata
exchange context information between classifiers and SFs, and among SFs
Service Function Path (SFP)
exactly which SFF/SFs the packet will visit when it actually traverses the network

8. Definition of terms SFC Encapsulation Rendered Service Path SFC Proxy
Provide SFP ID
Carry metadata
Rendered Service Path
a specific sequence of SFFs and SFs
Take into account the locations of SFFs, SFs
SFC Proxy
Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function

9. Architecture principles
Topological independence
Plane separation
Classification
At any level of protocol stack
Shared Metadata
an external repository might provide user/subscriber information to a service chain classifier
Service definition independence
Not depend on details of SFs
Heterogeneous control/policy points
Any control mechanisms possible to populate forwarding tables or classification rules

10. Core SFC Architecture Components

11. Core SFC Architecture Components

12. Network Service Header draft-ietf-sfc-nsh-04

13. Network Service Header
NSH = SFC encapsulation
Service path information
Metadata
added by a Service Classifier
removed by the last SFF in the chain or by a SF that consumes the packet

14. Network Service Header Format

15. NSH Base Header
O bit: when set to 0x1 indicates that this packet is an operations and management (OAM) packet
C bit: Indicates that a critical metadata TLV is present
Length: total length
MD Type: two MD types(0x1 : Fixed length context header, 0x2: variable length context header)
Next Protocol: indicates the protocol type of the original packet

16. Service Path Header
Service Path Identifier (SPI): identifies a service path
Service Index (SI): provides location within the SFP
The first Classifier (i.e. at the boundary of the NSH domain)in the NSH Service Function Path, SHOULD set the SI to 255
Service index MUST be decremented by service functions or proxy nodes after performing required services

17. NSH MD-type 1

18. NSH MD-type 2

19. Optional Variable Length Metadata
TLV Class: describes the scope of the "Type" field. In some cases, the TLV Class will identify a specific vendor, in others, the TLV Class will identify specific standards body allocated types
If a receiver receives an encapsulated packet containing a TLV with the Critical bit set to 0x1 in the Type field and it does not understand how to process the Type, it MUST drop the packet

20. NSH Actions

21. Service Path Forwarding with NSH
Forwarding tables can be populated by control plane

22. Service Path Forwarding with NSH
Or localized resolution on an SFF

23. Mapping NSH to Network Overlay
the mapping of SPI to network topology  a single overlay path, or a more complex topology
Next SF is located at SFFb with locator SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip:
Next SF is located at SFFc with multiple network locators for load distribution purposes: SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip: , , , equal cost
Next SF is located at SFFd with two paths to SFFc, one for redundancy: SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip: cost=10, , cost=20
It’s up to network operators to engineer overlay paths

24. Policy Enforcement with NSH
This metadata may be derived from several sources
Network nodes/devices
network-centric information
External (to the network) systems
E.g. application creating traffic
Service functions
A classifier co-resident with Service Functions often perform very detailed classification at the app layer

25. Policy Enforcement with NSH

26. Updating/Augmenting Metadata
Initial classification returns the tenant information, a secondary classification (perhaps co-resident with DPI or SLB) may augment the tenant classification with application information

27. Updating Metadata
the initial classifier adds metadata that describes the traffic as "internet" but a security service function determines that the traffic is really "attack"

28. Service Path ID and Metadata
Metadata information may influence the service path selection
A given SPI can represent all or some of the metadata, and be updated based on metadata classification results

29. NSH Encapsulation Examples

30. NSH Encapsulation Examples

31. Other drafts for NSH headers

32. Network Service Header (NSH) Context Header Allocation (Data Center)

33. Data Center Allocation Specifics

34. Data Center Allocation Specifics

35. Data Center Allocation Specifics

36. NSH Context Header Allocation -- Broadband draft-napper-sfc-nsh-broadband-allocation-00

37. NSH Context Header Allocation -- Broadband draft-napper-sfc-nsh-broadband-allocation-00

38. NSH Context Header Allocation -- Broadband draft-napper-sfc-nsh-broadband-allocation-00

39. NSH Context Header Allocation -- Broadband draft-napper-sfc-nsh-broadband-allocation-00