Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RM Ch03] Update Service Function Chaining 3.5.1 #2276

Closed
kumarsumangit opened this issue Feb 26, 2021 · 8 comments · Fixed by #2309, #2345 or #2319
Closed

[RM Ch03] Update Service Function Chaining 3.5.1 #2276

kumarsumangit opened this issue Feb 26, 2021 · 8 comments · Fixed by #2309, #2345 or #2319
Assignees
Labels
Kali Release Name for 1h2021 New
Projects

Comments

@kumarsumangit
Copy link
Collaborator

Update section 3.5.1 .. refer ra2 issue #2189

@pgoyal01 pgoyal01 added this to To do in RM via automation Feb 26, 2021
@pgoyal01
Copy link
Collaborator

@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
Copy link
Collaborator Author

kumarsumangit commented Mar 4, 2021

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.

SFC Architetcure-VNF

SFC Architetcure-CNF

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.
    SFC 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:

SFP chain

Policy for SFP Model, for example–

SFP Data model

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
Copy link
Collaborator

@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.

@walterkozlowski walterkozlowski moved this from To do to In Progress in RM Mar 8, 2021
@kumarsumangit
Copy link
Collaborator Author

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

@walterkozlowski
Copy link
Collaborator

walterkozlowski commented Mar 8, 2021 via email

@pgoyal01
Copy link
Collaborator

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

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

@walterkozlowski
Copy link
Collaborator

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
Copy link
Collaborator Author

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

@pgoyal01 pgoyal01 added the Kali Release Name for 1h2021 label Mar 26, 2021
@pgoyal01 pgoyal01 added this to the Kali - M1 - Release planning milestone Mar 26, 2021
RM automation moved this from In Progress to Done Mar 31, 2021
@kumarsumangit kumarsumangit linked a pull request Apr 7, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment