Difference between revisions of "Project Proposals/NSH SFC"

Latest revision as of 19:30, 3 March 2016

Name

NSH-Based Service Function Chaining

Project Contact Name and Email

Jim Guichard <jguichar@cisco.com>

Joel Halpern <joel.halpern@ericsson.com>

Repository Name

NSH_SFC

Description

VPP provides a processing platform for highly effective software packet processing. One of the situations that can make use of this capability is service chaining and the processing of the NSH header in support of service chaining.

This Project aims to add the mechanisms to VPP to provide NSH based packet forwarding and to support service chaining applications (service functions) in a highly efficient fashion.

Scope

Support for NSH-based service chains in VPP data plane that fall within the packet processing aspects of fd.io scope. At a high level, the main aspects include:

• Processing of NSH encapsulated packets/frames in/out of the VPP switch.
  • Termination of transport encapsulation and identification of NSH encapsulation that follows.
  • Forwarding of packets/frames based upon NSH encapsulation.
    • To/from locally attached NSH-aware/NSH-unaware SFs & other SFFs.
    • Enabling VPP to generate the appropriate outer encapsulation for outgoing NSH encapsulated packets/frames.
• Support for classification of incoming packets/frames and redirecting into NSH encapsulated service function paths.
• Support for co-resident SF’s either embedded with, or taking advantage of, the local SFF forwarding logic.
• Appropriate forwarding of packets/frames when NSH-based service function paths are terminated at the VPP switch.
• Definition of an internally exposed control API to allow programability of NSH SFC.
• Hardware acceleration also is part of the scope provided it is done in way that the code stays vendor neutral (i.e. hardware acceleration code is used to implement generic interfaces that allow other vendors to have their implementation also).

These in turn give rise to a number of more detailed activities which fall within the scope of the project. The sublists are all the primary focus, but may be extended within the scope of the main bullet based on observed need and interest:

• Classification
  • VPP switch may receive packets/frames for classification into a service chain based upon a variety of policy mechanisms. Regardless, the result of this classification is an action to forward into an NSH-based service function path.
  • VPP switch classification may also produce metadata, based on a variety of local or remote data sources including the incoming packet/frame and various configured properties, to be added to the packet/frame along with the NSH header.
  • Ability to extract metadata from the received NSH packet as input to processing must be supported.

• Forwarding
  • VPP switch may receive NSH encapsulated packets/frames carried in a variety of different transports. The VPP switch needs to be able to decapsulate, process, and encapsulate using these formats, and may forward packets received on one transport encapsulation using a different transport encapsulation.
  • May receive specifically marked NSH packets that require local, punted or special processing.
  • Verification of the received NSH packet on a given service function path must be supported.
  • Forward based on SPI/SI lookup and determine <next-hop, transport, action>.
  • SPI/SI lookup must support multiple next-hops with metric to same next SF.
  • Must support SFC-proxy function
  • Discard of packets with SI indicating the chain is exhausted.

• Metadata support
  • Ability to add metadata to a packet prior to SPI/SI lookup.
  • Must support type-1 and type-2 metadata processing.

• Termination
  • Ability to terminate a service function path based upon SPI/SI lookup and forwarded packets/frames based upon termination action.

• Miscellaneous
  • Support NSH traceroute.
  • Support packet generation.
  • Statistics collection, where not covered by other aspects of VPP.

The project will collaborate with the VPP project to ensure architectural consistency. The project will collaborate with Honeycomb and related projects to enable the development of interfaces to configure and monitor the service chaining functionality.

Initial Committers

Keith Burns <krb@cisco.com>

Thomas Herbert <therbert@redhat.com>

Markus Magnusson <markus.magnusson@ericsson.com>

Håkan Jonsson <hakan.jonsson@ericsson.com>

Danny Zhou < danny.zhou@intel.com >

Ash Young <ashlee@wildernessvoice.com>

Vendor Neutral

It is intended and expected that this code will be fully vendor neutral, referring and relying on only standardize mechanisms and protocols.

Meets Board Policy (including IPR, being within Board defined Scope etc)

Meets board policy as expressed in Technical Community Charter and IP Policy