Jump to: navigation, search

Project Proposals:Service function chaining

Name

Service Function Chaining

(note: using naming convention from the IETF working group focused on service chaining: https://datatracker.ietf.org/wg/sfc/charter/)


Repo Name

sfc

Description

This OpenDaylight project provides a sfc function that resides within the controller platform and presents service chaining functionality to external user-centric applications via the ODL Northbound REST APIs. Using this ODL service, network operators may create, update, and delete service chains, as well as specify the exchange of opaque metadata with network and service nodes in a service path. When applicable, APIs will allow specification of the selection criteria to be used by the sfc function to determine the service path for traffic incident upon the chain.

Service chain: defines “intent” and is, in essence, a list of required service functions (e.g. FW → SLB → IPS)

Service path: instantiation of a service chain. Specific instances of a service type are selected and connectivity established between instances. (e.g. FW1@1.1.1.1 → SLB3@2.2.2.2 → IPS34@3.3.3.3)


Proposal fig1.jpg



The user-facing service chaining application will allow users to define: 1. Service chain 2. Service path


The definition -- chain or path -- is sent via REST API to the ODL service chaining service. The ODL service will in turn:

  • Create service paths given a list of service types (i.e. the service chaining app will request a chain):
The service chaining service will dynamically select the specific service instances required to satisfy the service chain requirements
  • Create service paths given a list of service instances (i.e. the service chaining app will request a path explicitly):
The service chaining service will receive a static list of service instances and will establish the necessary service path through those service instances
  • Return all service paths
The service chaining service will return a list of all active service paths
  • Return specific paths
The service chaining service will return the details for a specified path
  • Update or delete an existing service path
The service chaining service will update and/or delete an existing service path
  • Define/update (optional) metadata for delivery along service chain


Encapsulation and Transport:

  • Service chaining is transport independent, and as such will leverage available overlay transports (e.g. LISP)
  • Dataplane will be accomplished via so-called “SFC encapsulation” (as per the IETF WG effort). (an example of such an encap: http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/)
  • Required dataplane information will be represented in a data model
  • In both cases, the south-bound plugin will ensure “mapping” to require network and service node formats

Scope

  1. ODL service chaining service
  2. North-bound APIs
  3. South-bound interface to plugins
  4. Plugin changes needed to provision chains
  5. User focused service chaining application
  6. Classifier capability


Resources Committed (developers committed to working)

Reinaldo Penno (repenno@cisco.com)

Konstantin Blagov (kblagov@cisco.com)

Paul Quinn (paulq@cisco.com)

Ed Warnicke (eaw@cisco.com)

Gal Mainzer (GMainzer@Contextream.com)

David Goldberg (David.Goldberg@Contextream.com)

Kfir Yeshayahu (Kfir.Yeshayahu@Contextream.com)

Kiran Koushik Agrahara Sreenivasa(kkoushik@brocade.com)

Ryan Moats (rmoats@us.ibm.com)

Christopher Price (christopher.price@ericsson.com)

Vinayak Joshi (vinayak.joshi@ericsson.com)

Youcef Laribi (Youcef.Laribi@Citrix.com)

Initial Committers

Reinaldo Penno (repenno@cisco.com)

Konstantin Blagov (kblagov@cisco.com)

Paul Quinn (paulq@cisco.com)

Ed Warnicke (eaw@cisco.com)

Gal Mainzer (GMainzer@Contextream.com)

David Goldberg (David.Goldberg@Contextream.com)

Kfir Yeshayahu (Kfir.Yeshayahu@Contextream.com)

Kiran Koushik Agrahara Sreenivasa(kkoushik@brocade.com)

Ryan Moats (rmoats@us.ibm.com)

Christopher Price (christopher.price@ericsson.com)

Vinayak Joshi (vinayak.joshi@ericsson.com)

Youcef Laribi (Youcef.Laribi@Citrix.com)

Vendor Neutral

If this proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc. have been removed? Please specify.

This will be a new code base, not coming from existing code.


Meets Board Policy (including IPR)