Difference between revisions of "Project Proposals/GPE VPN"
From fd.io
Florin.coras (Talk | contribs) m (→Initial Committers) |
|||
| (24 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Project Proposal]] | [[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 --> | <!-- Please note: fd.io code is to be licensed under the Apache 2.0 license unless an exception is approved by the board --> | ||
== Name == | == Name == | ||
| − | + | <!-- The name of your project, for example Honeycomb BridgeDomain or NSH Advanced Features etc. --> | |
| − | + | Overlay Network Engine (ONE) | |
== Project Contact Name and Email == | == Project Contact Name and Email == | ||
| − | + | [mailto:fcoras@cisco.com Florin Coras], LF-ID: florin.coras | |
| − | + | ||
| + | [mailto:vermagan@cisco.com Vina Ermagan] | ||
== Repository Name == | == Repository Name == | ||
| − | < | + | <!-- Project Repository Name, should be: |
| + | i. Lower case | ||
| + | ii. Short | ||
| + | iii. Suitable for use as a C identifier | ||
| + | --> | ||
| + | |||
| + | Repository name will be: one | ||
== Description == | == Description == | ||
=== Overview === | === Overview === | ||
| − | |||
| − | + | Overlay Network Engine (ONE) is a project proposal for VPP to enable programmable dynamic Software Defined overlays. ONE uses an extended LISP-based map-assisted control plane to dynamically lookup overlay-to-underlay address mappings, as well as forwarding policies, on demand and as packets arrive. This includes policies such as connectivity, encryption, traffic engineering and virtual topologies, access control, and service chaining. The looked up mappings and forwarding policies are cached locally for a TTL period until they time out. The mapping and forwarding policy information is then used to encapsulate overlay packets towards their associated destinations or next hops. | |
| − | + | ONE can use and operate a variety of encapsulation formats for the overlay including GRE, VXLAN-GPE (Generic Protocol Extension) [1], which is effectively merging VXLAN and LISP [2] encapsulations in a single format that supports multi-protocol payloads, etc. The control plane can be used to fetch the encapsulation capabilities of a destination as part of its mapping and forwarding policies. | |
| − | + | An external open SDN controller will be used as the mapping system to store and provide the mapping and forwarding policies. | |
| + | |||
| + | ONE can use IPsec based encryption to secure the overlay if needed. Cryptographic parameters, can be provisioned on demand. | ||
=== Data Plane Operations === | === Data Plane Operations === | ||
| − | + | ONE core data plane operations include: | |
| − | * Determining the location of the destination overlay endpoints, encapsulating data packets to the right destination location, and forwarding these packets onto the underlay network. | + | * Determining the location of the destination overlay endpoints (by using control plane lookups), encapsulating data packets to the right destination location, and forwarding these packets onto the underlay network. |
* De-capsulating encapsulated packets and forwarding the packets towards their associated destinations in the overlay. | * De-capsulating encapsulated packets and forwarding the packets towards their associated destinations in the overlay. | ||
| − | To enable dynamic encapsulation a map cache is used that maps flows in the overlay to the location(s) (IP address in the underlay network) of the next hop, or the destination endpoint, depending on the mapping/forwarding policy defined in the mapping system. | + | To enable dynamic encapsulation a local map cache is used that maps flows in the overlay to the location(s) (IP address in the underlay network) of the next hop, or the destination endpoint, depending on the mapping/forwarding policy defined in the mapping system. |
The map cache would support generic mappings such that the programmable overlay services can be used by a variety of packets and protocols (e.g. L2, L3, NSH [3]) [4]. Multi-homing and load balancing as well as segmentation based on a VNI/IID will be supported. | The map cache would support generic mappings such that the programmable overlay services can be used by a variety of packets and protocols (e.g. L2, L3, NSH [3]) [4]. Multi-homing and load balancing as well as segmentation based on a VNI/IID will be supported. | ||
| Line 42: | Line 51: | ||
=== Control Plane Operations === | === Control Plane Operations === | ||
| − | + | ONE will use an extended LISP-based control plane to dynamically lookup the mapping and forwarding policy for overlay destinations, resulting in the location of the next hop associated with the flow in question. This mapping information is then cached in the map cache for future use. Changes/updates to the cached mappings may be pushed to VPP by the mapping system. | |
== Scope == | == Scope == | ||
| + | <!-- Project scope. The project scope should be well defined. It should be possible from the scope to crisply answer whether something belongs or not within the scope of this particular project. Scopes should not be overly broad. A Project scope must also lie within the overall scope set by the board for projects in fd.io: | ||
| + | - IO | ||
| + | – Hardware/vHardware <-> threads/cores | ||
| + | - Processing | ||
| + | - Classify | ||
| + | - Transform | ||
| + | - Prioritize | ||
| + | - Forward | ||
| + | - Terminate | ||
| + | - Management Agents | ||
| + | - Control/Manage IO/Processing | ||
| + | - Supporting Projects | ||
| + | - Testing/Tools/Infrastructure | ||
| + | - Integration with other systems | ||
| + | --> | ||
| − | Project scope | + | Project scope includes implementation of nodes that enable dynamic encapsulation and de-capsulation of data packets using different encapsulation formats, the map cache, and the LISP control plane for retrieval and update of the mapping and forwarding policies. The scope also includes integration with other components within VPP such as IPSec for encryption and NSH. |
| − | + | In more detail the scope will include: | |
| − | + | * Implementation of plugins/graph nodes to allow dynamic lookup and retrieval of mappings of network traffic to encapsulations for next hops (various encaps are supported and mapping system can determine the encap to use.) Various network traffic can be mapped, including L2, L3, NSH,... | |
| + | * Implementation of plugins/graph nodes to store/cache the retrieved mappings locally | ||
| + | * Implementation of plugins/graph nodes to carry out/apply the mappings for existing flows (match and encap) | ||
| + | * Implementation of plugins/graph nodes to allow integration with other components including IPSec for encryption and NSH for service chaining | ||
| + | * Exporting APIs over NETCONF - using Honeycomb or other means defined by fd.io | ||
| + | * Supporting tools, testing | ||
| + | |||
| + | == Initial Committers == | ||
| + | <!-- 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. | ||
| + | |||
| + | --> | ||
| + | |||
| + | * [mailto:fcoras@cisco.com Florin Coras], LF-ID: florin.coras | ||
| + | * [mailto:lojakab@cisco.com Lorand Jakab], LF-ID: lori | ||
| + | * [mailto:vermagan@cisco.com Vina Ermagan] | ||
| + | * [mailto:arnatal@ac.upc.edu Alberto Rodriguez Natal] | ||
| + | * [mailto:eaw@cisco.com Ed Warnicke] | ||
| + | |||
== Vendor Neutral == | == Vendor Neutral == | ||
| + | <!-- | ||
| + | The goal here is to capture the degree of vendor neutrality of the code. | ||
| + | The concerns are two fold: avoiding trademark issues, and maintaining openness. | ||
| + | |||
| + | For this reason, use of vendor names should be purely functional, and only if necessary to | ||
| + | reasonably communicate functional information to the user. | ||
| + | |||
| + | Acceptable Examples: | ||
| + | Indicating the presence of particular hardware | ||
| + | Indicating drivers for particular hardware | ||
| + | Indicating integration with particular technologies. | ||
| + | |||
| + | Unacceptable Examples: | ||
| + | Use of vendor trademarks or product names purely for marketing purposes. | ||
| + | |||
| + | Please describe any such issues here. | ||
| + | --> | ||
| − | This projects is vendor neutral and implements/uses open technologies and protocols such as GPE, LISP, IPSec, NSH. | + | This projects is vendor neutral and implements/uses open technologies and protocols such as GPE [1], LISP [2], IPSec, NSH [3]. |
== Meets Board Policy (including IPR, being within Board defined Scope etc) == | == Meets Board Policy (including IPR, being within Board defined Scope etc) == | ||
| Line 61: | Line 121: | ||
== References == | == References == | ||
| − | [1] https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe | + | *[1] https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe |
| − | [2] https://tools.ietf.org/html/rfc6830 | + | *[2] https://tools.ietf.org/html/rfc6830 |
| − | [3] https://tools.ietf.org/html/draft-ietf-sfc-nsh | + | *[3] https://tools.ietf.org/html/draft-ietf-sfc-nsh |
| − | [4] https://tools.ietf.org/html/draft-ermagan-lisp-nsh | + | *[4] https://tools.ietf.org/html/draft-ermagan-lisp-nsh |
Latest revision as of 19:42, 7 March 2016
Contents
Name
Overlay Network Engine (ONE)
Project Contact Name and Email
Florin Coras, LF-ID: florin.coras
Repository Name
Repository name will be: one
Description
Overview
Overlay Network Engine (ONE) is a project proposal for VPP to enable programmable dynamic Software Defined overlays. ONE uses an extended LISP-based map-assisted control plane to dynamically lookup overlay-to-underlay address mappings, as well as forwarding policies, on demand and as packets arrive. This includes policies such as connectivity, encryption, traffic engineering and virtual topologies, access control, and service chaining. The looked up mappings and forwarding policies are cached locally for a TTL period until they time out. The mapping and forwarding policy information is then used to encapsulate overlay packets towards their associated destinations or next hops.
ONE can use and operate a variety of encapsulation formats for the overlay including GRE, VXLAN-GPE (Generic Protocol Extension) [1], which is effectively merging VXLAN and LISP [2] encapsulations in a single format that supports multi-protocol payloads, etc. The control plane can be used to fetch the encapsulation capabilities of a destination as part of its mapping and forwarding policies.
An external open SDN controller will be used as the mapping system to store and provide the mapping and forwarding policies.
ONE can use IPsec based encryption to secure the overlay if needed. Cryptographic parameters, can be provisioned on demand.
Data Plane Operations
ONE core data plane operations include:
- Determining the location of the destination overlay endpoints (by using control plane lookups), encapsulating data packets to the right destination location, and forwarding these packets onto the underlay network.
- De-capsulating encapsulated packets and forwarding the packets towards their associated destinations in the overlay.
To enable dynamic encapsulation a local map cache is used that maps flows in the overlay to the location(s) (IP address in the underlay network) of the next hop, or the destination endpoint, depending on the mapping/forwarding policy defined in the mapping system. The map cache would support generic mappings such that the programmable overlay services can be used by a variety of packets and protocols (e.g. L2, L3, NSH [3]) [4]. Multi-homing and load balancing as well as segmentation based on a VNI/IID will be supported.
The map cache is populated on demand using the LISP[4] map-request/map-reply protocol.
Control Plane Operations
ONE will use an extended LISP-based control plane to dynamically lookup the mapping and forwarding policy for overlay destinations, resulting in the location of the next hop associated with the flow in question. This mapping information is then cached in the map cache for future use. Changes/updates to the cached mappings may be pushed to VPP by the mapping system.
Scope
Project scope includes implementation of nodes that enable dynamic encapsulation and de-capsulation of data packets using different encapsulation formats, the map cache, and the LISP control plane for retrieval and update of the mapping and forwarding policies. The scope also includes integration with other components within VPP such as IPSec for encryption and NSH.
In more detail the scope will include:
- Implementation of plugins/graph nodes to allow dynamic lookup and retrieval of mappings of network traffic to encapsulations for next hops (various encaps are supported and mapping system can determine the encap to use.) Various network traffic can be mapped, including L2, L3, NSH,...
- Implementation of plugins/graph nodes to store/cache the retrieved mappings locally
- Implementation of plugins/graph nodes to carry out/apply the mappings for existing flows (match and encap)
- Implementation of plugins/graph nodes to allow integration with other components including IPSec for encryption and NSH for service chaining
- Exporting APIs over NETCONF - using Honeycomb or other means defined by fd.io
- Supporting tools, testing
Initial Committers
- Florin Coras, LF-ID: florin.coras
- Lorand Jakab, LF-ID: lori
- Vina Ermagan
- Alberto Rodriguez Natal
- Ed Warnicke
Vendor Neutral
This projects is vendor neutral and implements/uses open technologies and protocols such as GPE [1], LISP [2], IPSec, NSH [3].
Meets Board Policy (including IPR, being within Board defined Scope etc)
Meets board policy as expressed in Technical Community Charter and IP Policy
