[RM Ch03] Update Service Function Chaining 3.5.1

[kumarsumangit]

Update section 3.5.1 .. refer ra2 issue #2189

[pgoyal01]

@sukhdevkapur @walterkozlowski @TFredberg @qabpea Please review write-up in Issue #2189 -- I am suggesting that an abstracted version should be used to update the writeup in RM 3.5.1,

Please comment here and not in 2189. Thanks

[kumarsumangit]

Introduction Over the past few years, there has been a significant move towards decomposing network functions into smaller sub-functions that can be independently scaled and potentially reused across multiple network functions. A service chain allows composition of network functions by passing selected packets through multiple smaller services. In order to support this capability in a sustainable manner, there is a need to have the capability to model service chains as a high level abstraction. This is essential to ensure that the underlying connection setup, and (re-)direction of traffic flows can be performed in an automated manner. SFC can be visualized as Service function plane (consists of SFF, SFC, SF, SF proxy) over Service function overlay network. At a very high level, a service function plane is a directed acyclic graph with the composing network functions being the vertices. Service function chaining utilizes a service-specific overlay that creates the service topology. The service overlay provides service function connectivity, built "on top" of the existing network topology. In Overlay network, packets are routed based on networking principles as destination ip, next hop. However, in service overlay network, packets are routed based on policies unlike overlay network, again defined at Orchestrator level. This requires specific support at network level such as at CNI in CNF environment to provide such specific routing mechanism. Before Defining Service Function chain model , lets explore service function chaining architecture.

SFC Architecture Functional Components:- SFC can be visualized as made of these components which makes SFC possible.

1. SFC Orchestrator – High-level orchestrator for SF and link between MANO and SF.

2. SFC components for traffic steering in Service Plane. These are SDNC, SFF, SF & SF proxy.

3. SFC Renderer – creates and wires port for SF data path. In CNF Environment, CNI agent to wire Policy rules for SFC. It can deploy different techniques to stitch the wiring but provide the same functionality, for example l2xconn, srv6 , Segment routing etc.

4. VNF MANO – VNF (SF) Lifecycle Manager NFVO, VNFM, VIM .

5. CNF MANO- CNF DevOps Components, which are responsible for as SF LCM. For example cloudify, K8S, Ansible, etc.

Call flow- Service function Chaining call flow visualized logically as two steps as shown in figure below:

1. Creation of SFs a. SFC orchestrator creates the SFs with help of VNF MANO or CNF MANO. b. Attaches the SFC aware interfaces at SFs c. Booting up the SF configurations
2. Creation of SFP using the created SFs and associated interfaces. a. SFC orchestrator creates SFP with help of SDNC b. SDNC pushes the SFC traffic steering policies. c. SFC classifier Policy provided for SFP. Note- not shown in call flow.

For example, to create the SFC in container system shown as above. After creation of container, SFC interfaces created, identified by interface Ids and attached with the container. These interface IDs ae used to render SFP for given SFC. Once packets received on these SFP, policy driven packet steering performed to route packets to SF for processing.

A Service Function Path consists of: • A set of ports( in VNF environment) or interfaces ( in CNF environment) , that define the sequence of service functions • A set of flow classifiers that specify the classified traffic flows entering the chain.

If a SF involves a pair of ports/interfaces, the first port/interface acts as the ingress port/interface of the service function and the second port/interface acts as the egress port/interface. First port/interface of the first port/interface-pair is the head of the service chain. The second port/interface of the last port/interface-pair is the tail of the service chain. A bidirectional service chain would be composed of two unidirectional Port Chains.

For example, [{p1: p2}, {p3: p4}, {p5: p6}]/[{i1:i2},{i3:i4},{i5:i6}] represents:

Policy for SFP Model, for example–

Summary to RM relevance:- Relevance to RM-

1. Attaching SFC supporting Interfaces/Ports at Pod/vm using multi plugin/Port
2. Architecture support for SDN controller interfaces at Network/CNI
3. Configuring policy driven routes to steer traffic between these Ports/Interfaces via SDN controller . Out of scope of RM :- Note:- these are not exhaustive list.
4. How CNI/Network will support SFC using SRv6, mpls, NSH ?
5. How SDN controller will interact with Network/CNI for SFC policy?
6. How packets are classified for SFC?
7. How SFP is created from SFC design?

[walterkozlowski]

@kumarsumangit, could you please present the contents and ask for feedback at the RM meeting this Wednesday? I will assign 20 min Utes in the Agenda for it. Please confirm.

[kumarsumangit]

@walterkozlowski Sure, mark it confirm .. i will present the contents .. meanwhile i will update with some modification before meeting. Thanks

[walterkozlowski]

Thanks!

On Mon, 8 Mar 2021 at 9:59 pm, kumarsumangit notifications@github.com wrote:

@walterkozlowski https://github.com/walterkozlowski Sure, mark it confirm .. i will present the contents .. meanwhile i will update with some modification before meeting. Thanks

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cntt-n/CNTT/issues/2276#issuecomment-792674374, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMONQF4RHKAPRNQSFOJSDRLTCSU2PANCNFSM4YHXMGVA .

[pgoyal01]

Per @walterkozlowski suggestion to create 3 PRs, @kumarsumangit may I suggest the following PRs:

1. Introduction
2. Architecture
3. Call Flow and Summary

[walterkozlowski]

Agree with @pgoyal01. I would suggest having a good description of all abstract components of the SFC with examples relevant to RA-1 and to RA-2. This could be part of PR on Intro.

[kumarsumangit]

@pgoyal01 and @walterkozlowski Thanks for suggestion. Sure, will create 3 PRs as suggested.