Difference between revisions of "Project Proposals/GPE VPN"

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 == GPE-VPN...")
 
Line 3: Line 3:
  
 
== Name ==
 
== Name ==
−
GPE-VPN
+
Options: Programmable VPN / VPN / GPE-VPN / Overlay Manager ?
 +
 
 +
In the rest of this draft the name "Programmable VPN" is used for the project.
  
 
== Project Contact Name and Email ==
 
== Project Contact Name and Email ==
−
<!-- Name and email of the project contact -->
+
 
 +
Florin Coras <fcoras@cisco.com>
 +
Vina Ermagan <vermagan@cisco.com>
  
 
== Repository Name ==
 
== Repository Name ==
−
gpe_vpn
+
 
 +
<will be chosen depending on the name choice. pvpn (for programmable VPN?)>
  
 
== Description ==
 
== Description ==
−
<!-- Description of the work that will take place in this project -->
 
  
−
== Scope ==
+
=== Overview ===
−
<!-- 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:
+
Programmable VPN is project proposal for VPP to enable programmable Software Defined overlays. The Generic Protocol Encapsulation (GPE) [1] will be used as the main encapsulation format. GPE is effectively merging VXLAN and LISP [2] encapsulation in a single format that supports multi-protocol payloads.  
−
    - 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
+
−
-->
+
  
−
== Initial Committers ==
+
Programmable VPN uses an extended LISP-based map-assisted control plane to dynamically lookup forwarding policies on demand. This includes policies such as connectivity, encryption, traffic engineering and virtual topologies, access control, and service chaining.  An SDN controller-based mapping system is used to store and retrieve the mapping and forwarding policies.
−
<!-- 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.
+
  
−
-->
+
Programmable VPN data plane can be secured with IPsec based encryption.
  
−
== Vendor Neutral ==
+
Overlay tunnels, as well as cryptographic parameters, are provisioned on demand.  
−
<!--
+
−
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
+
=== Data Plane Operations ===
−
reasonably communicate functional information to the user.
+
  
−
Acceptable Examples:
+
Programmable VPN core data plane operations include:
−
Indicating the presence of particular hardware
+
−
Indicating drivers for particular hardware
+
−
Indicating integration with particular technologies.
+
  
−
Unacceptable Examples:
+
* Determining the location of the destination overlay endpoints, encapsulating data packets to the right destination location, and forwarding these packets onto the underlay network.
−
Use of vendor trademarks or product names purely for marketing purposes.
+
 
 +
* 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.
 +
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 ===
 +
 
 +
Programmable VPN will use the LISP map-request/map-reply protocol to dynamically lookup the mapping and forwarding policy resulting in the location of the next hop associated with this flow. This mapping information is then cached in the map cache for future use. Changes to the cached mappings are then pushed by the mapping system to VPP.
 +
 
 +
== Scope ==
 +
 
 +
Project scope includes data plane and control plane functions specified in the project description. This includes implementation of modules/nodes that enable dynamic encapsulation and de-capsulation of data packets starting with the GPE encapsulation format, the map cache, and the LISP control plane protocol 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.
 +
 
 +
== Initial Committers ==
 +
 
 +
<Committers list TBD>
 +
 +
== Vendor Neutral ==
 +
 
 +
This projects is vendor neutral and implements/uses open technologies and protocols such as GPE, LISP, IPSec, NSH.
  
−
Please describe any such issues here.
 
−
-->
 
 
== Meets Board Policy (including IPR, being within Board defined Scope etc) ==
 
== Meets Board Policy (including IPR, being within Board defined Scope etc) ==
  
 
Meets board policy as expressed in [https://fd.io/sites/cpstandard/files/pages/files/exhibit_c_-_fd.io_technical_community_charter.pdf Technical Community Charter] and [https://fd.io/sites/cpstandard/files/pages/files/exhibit_b_-_fd.io_ip_policy.pdf IP Policy]
 
Meets board policy as expressed in [https://fd.io/sites/cpstandard/files/pages/files/exhibit_c_-_fd.io_technical_community_charter.pdf Technical Community Charter] and [https://fd.io/sites/cpstandard/files/pages/files/exhibit_b_-_fd.io_ip_policy.pdf IP Policy]
 +
 +
== References ==
 +
[1] https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe
 +
[2] https://tools.ietf.org/html/rfc6830
 +
[3] https://tools.ietf.org/html/draft-ietf-sfc-nsh
 +
[4] https://tools.ietf.org/html/draft-ermagan-lisp-nsh

Revision as of 03:14, 27 February 2016


Name

Options: Programmable VPN / VPN / GPE-VPN / Overlay Manager ?

In the rest of this draft the name "Programmable VPN" is used for the project.

Project Contact Name and Email

Florin Coras <fcoras@cisco.com> Vina Ermagan <vermagan@cisco.com>

Repository Name

<will be chosen depending on the name choice. pvpn (for programmable VPN?)>

Description

Overview

Programmable VPN is project proposal for VPP to enable programmable Software Defined overlays. The Generic Protocol Encapsulation (GPE) [1] will be used as the main encapsulation format. GPE is effectively merging VXLAN and LISP [2] encapsulation in a single format that supports multi-protocol payloads.

Programmable VPN uses an extended LISP-based map-assisted control plane to dynamically lookup forwarding policies on demand. This includes policies such as connectivity, encryption, traffic engineering and virtual topologies, access control, and service chaining. An SDN controller-based mapping system is used to store and retrieve the mapping and forwarding policies.

Programmable VPN data plane can be secured with IPsec based encryption.

Overlay tunnels, as well as cryptographic parameters, are provisioned on demand.

Data Plane Operations

Programmable VPN 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.
  • 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. 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

Programmable VPN will use the LISP map-request/map-reply protocol to dynamically lookup the mapping and forwarding policy resulting in the location of the next hop associated with this flow. This mapping information is then cached in the map cache for future use. Changes to the cached mappings are then pushed by the mapping system to VPP.

Scope

Project scope includes data plane and control plane functions specified in the project description. This includes implementation of modules/nodes that enable dynamic encapsulation and de-capsulation of data packets starting with the GPE encapsulation format, the map cache, and the LISP control plane protocol 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.

Initial Committers

<Committers list TBD>

Vendor Neutral

This projects is vendor neutral and implements/uses open technologies and protocols such as GPE, LISP, IPSec, NSH.

Meets Board Policy (including IPR, being within Board defined Scope etc)

Meets board policy as expressed in Technical Community Charter and IP Policy

References

[1] https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe [2] https://tools.ietf.org/html/rfc6830 [3] https://tools.ietf.org/html/draft-ietf-sfc-nsh [4] https://tools.ietf.org/html/draft-ermagan-lisp-nsh

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