Difference between revisions of "Project Proposals/NSH SFC"

Revision as of 19:58, 21 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:

• 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:
  • VXLAN-GPE
  • GRE
  • MPLS/Segment Routing
    • Whether controlled by conventional MPLS, MPLS-TP, Segment Routing, or other mechanisms
    • Potentially also including IPv6 Segment Routing
  • Ethernet
  • UDP
  • ..

• 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:
  • Endpoint groups and subscriber policies
  • QoS
  • ACLs
  • interface
  • ..

• 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:
  • VPN identification
  • Subscriber Identification
  • Service Class information
  • ..

• May receive specifically marked NSH packets that require local, punted or special processing:
  • OAM
  • Reverse path forwarding
  • ..

• Verification of the received NSH packet on a given service function path must be supported:
  • am i supposed to receive ‘path-id x’ ‘service index y’ from interface z

• Ability to extract metadata from the received NSH packet as input to processing must be supported
  • process within a particular VPN context
  • process based upon policy carried within the metadata
  • providing efficient support of service functions which consume and produce metadata

• Ability to add metadata to a packet prior to SPI/SI lookup
  • which VRF interface packet received on etc

• Forward based on SPI/SI lookup and determine <next-hop, transport, action>
  • where ‘action’ can be:
    • forward
    • modify metadata by adding, removing, or rewriting information
    • terminate service chaining with actions
      • remove NSH, extract metadata, etc
    • drop

• SPI/SI lookup must support multiple next-hops with metric to same next SF
  • multiple instances of the same SF for local traffic distribution using specific algorithm
    • round robin
    • proportionate splits
    • Flow stickiness

• Must support SFC-proxy function

• Must support type-1 metadata processing
  • support for pre-configured type-1 metadata sets (DC, Mobility, GBP)
• Must support type-2 metadata processing
  • meaning it should not croak but be able to access inner packet/frame based on skipping of the metadata using the length in NSH base header
  • may support type-2 TLV processing
    • for type-2 will likely be a subset of available TLVs

• 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:
  • Bytes and packets per RSP, SF, SFF.
  • Errors: NSH errors vs. VXLAN errors vs. IP errors
  • Metadata parsing errors
  • Metadata counters

• Discard of packets with SI indicating the chain is exhausted.

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

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