Difference between revisions of "Project Proposals/NSH SFC"

From fd.io
Jump to: navigation, search
(Created page with "Category:Project Proposal <!-- Please note: fd.io code is to be licensed under the Apache 2.0 license unless an exception is approved by the board --> == Name == NSH-Base...")
 
(→‎Scope)
 
(13 intermediate revisions by 2 users not shown)
Line 7: Line 7:
 
== Project Contact Name and Email ==
 
== Project Contact Name and Email ==
 
Jim Guichard <jguichar@cisco.com>
 
Jim Guichard <jguichar@cisco.com>
 +
 
Joel Halpern <joel.halpern@ericsson.com>
 
Joel Halpern <joel.halpern@ericsson.com>
  
Line 18: Line 19:
  
 
== Scope ==
 
== Scope ==
−
There are multiple aspects to supporting service chaining and NSH in VPP.  At a high level, these include:
+
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 packets in/out of the VPP switch
+
* Processing of NSH encapsulated packets/frames in/out of the VPP switch.
−
* Enabling VPP to generate the proper encapsulation for outgoing service chaining packets
+
** Termination of transport encapsulation and identification of NSH encapsulation that follows.
−
* Supporting classification of incoming L2/L3 frames/packets being directed to service chains
+
** Forwarding of packets/frames based upon NSH encapsulation.
−
* Generating proper L2/L3 frames/packets when NSH RSPs are terminated at the VPP switch
+
*** 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 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:
  
−
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.
  
−
* 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:
+
* Forwarding
−
** VXLAN-GPE
+
** 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.
−
** GRE
+
** May receive specifically marked NSH packets that require local, punted or special processing.
−
** MPLS/Segment Routing
+
** Verification of the received NSH packet on a given service function path must be supported.
−
*** Whether controlled by conventional MPLS, MPLS-TP, Segment Routing, or other mechanisms
+
** Forward based on SPI/SI lookup and determine <next-hop, transport, action>.
−
*** Potentially also including IPv6 Segment Routing
+
** SPI/SI lookup must support multiple next-hops with metric to same next SF.
−
** Ethernet
+
** Must support SFC-proxy function
−
** UDP
+
** Discard of packets with SI indicating the chain is exhausted.
−
* 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
+
* Metadata support
−
** QoS
+
** Ability to add metadata to a packet prior to SPI/SI lookup.
−
** ACLs
+
** Must support type-1 and type-2 metadata processing.
−
** 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:
+
* Termination
−
** VPN identification
+
** Ability to terminate a service function path based upon SPI/SI lookup and forwarded packets/frames based upon termination action.
−
** Subscriber Identification
+
 
−
** Service Class information
+
* Miscellaneous
−
* May receive specifically marked NSH packets that require local or punted processing:
+
** Support NSH traceroute.
−
** OAM
+
** Support packet generation.
−
* 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
+
** Statistics collection, where not covered by other aspects of VPP.
−
* 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.
 
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>
  
−
== Release Plan ==
+
Thomas Herbert <therbert@redhat.com>
−
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:
+
  
 +
Markus Magnusson <markus.magnusson@ericsson.com>
  
 +
Håkan Jonsson <hakan.jonsson@ericsson.com>
  
−
== Initial Committers ==
+
Danny Zhou < danny.zhou@intel.com >
−
<!-- A list of the name/email/IRC nick of the initial project committers
+
−
+
−
IMPORTANT:  Committers should be people who will actually write code, being a committer is an actual commitment of time. Please also note that committerness is an individual trait.  If a committer changes employers, they remain a committer.  New committers arise via meritocracy after the project is created, this typically involves some time of establishing history of meritocractic code contribution to the project..  Therefore, it is crucial that a committer is committed to ongoing work on the project in the longer term, not just short term.  For more information on how committers are added after project creation see:
+
−
https://fd.io/sites/cpstandard/files/pages/files/exhibit_c_-_fd.io_technical_community_charter.pdf section 3.2.2.1.
+
  
−
-->
+
Ash Young <ashlee@wildernessvoice.com>
  
 
== Vendor Neutral ==
 
== Vendor Neutral ==

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

Retrieved from "https://wiki.fd.io/index.php?title=Project_Proposals/NSH_SFC&oldid=529"