Project Proposals/NSH SFC

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

There are multiple aspects to supporting service chaining and NSH in VPP. At a high level, these include:

• Processing of NSH packets in/out of the VPP switch
• Enabling VPP to generate the proper encapsulation for outgoing service chaining packets
• Supporting classification of incoming L2/L3 frames/packets being directed to service chains
• Generating proper L2/L3 frames/packets when NSH-based service function paths are terminated at the VPP switch

These all fall within the packet processing aspects of fd.io scope.

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 carried in a number of different transports; The switch needs to be able to decapsulate, process, and encapsulate using these formats:
  • 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 L2/L3 frames/packets for classification into a service chain based upon a variety of policy mechanisms:
  • Endpoint groups and subscriber policies
  • QoS
  • ACLs
  • interface
• VPP Switch classification may also produce metadata, based on a variety of local data sources including the incoming frame / packet and various configured properties, to be added to the frames/packets along with the NSH header:
  • VPN identification
  • Subscriber Identification
  • Service Class information
• May receive specifically marked NSH packets that require local or punted processing:
  • OAM
• As an important corollary the first bullet above, the VPP switch may forward packets received on one transport encapsulation using a different transport encapsulation; for example, received on VXLAN-GPE but sent on GRE
• Verification of the received NSH packet on a given RSP 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
• Must support both type-1 and type-2 metadata processing
  • Support for pre-configured metadata sets (DC, Mobility, GBP)
  • meaning it should not croak but be able to access inner packet based on skipping metadata - length in NSH base header
  • must be able to act upon both type-1 and type-2 metadata
    • for type-2 will likely be a subset of available TLVs
• 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
• 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:

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