Difference between revisions of "Project Proposals/NSH SFC"

Revision as of 17:06, 22 February 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
• Supporting classification of incoming packets/frames and redirecting into NSH encapsulated service function paths
• Appropriate forwarding of packets/frames when NSH-based service function paths are terminated at the VPP switch

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 as described in https://datatracker.ietf.org/doc/draft-penno-sfc-trace/
  • Support packet generation as described in https://datatracker.ietf.org/doc/draft-penno-sfc-packet/
  • 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.

Release Plan

As the above scope is quite large, the first release will only address a subset of those items. The plan for the first release is to cover:

Initial Committers

Keith Burns <krb@cisco.com>

Thomas Herbert <therbert@redhat.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