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

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

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

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

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

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

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

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

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

Core SFC Architecture Components

Core SFC Architecture Components

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

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

Network Service Header Format

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

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

NSH MD-type 1

NSH MD-type 2

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

NSH Actions

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

Service Path Forwarding with NSH Or localized resolution on an SFF

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 10.1.1.1 SFFa mapping: SPI=10 --> VXLAN-gpe, dst-ip: 10.1.1.1 Next SF is located at SFFc with multiple network locators for load distribution purposes: SFFb mapping: SPI=10 --> VXLAN-gpe, dst_ip:10.2.2.1, 10.2.2.2, 10.2.2.3, equal cost Next SF is located at SFFd with two paths to SFFc, one for redundancy: SFFc mapping: SPI=10 --> VXLAN-gpe, dst_ip:10.1.1.1 cost=10, 10.1.1.2, cost=20 It’s up to network operators to engineer overlay paths

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

Policy Enforcement with NSH

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

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"

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

NSH Encapsulation Examples

NSH Encapsulation Examples

Other drafts for NSH headers

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

Data Center Allocation Specifics

Data Center Allocation Specifics

Data Center Allocation Specifics

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

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

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

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