Your SlideShare is downloading. ×
0
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
LISP and NSH in Open vSwitch
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

LISP and NSH in Open vSwitch

3,303

Published on

These slides were presented at the 2013 Linux Plumbers Conference in New Orleans by myself and Vina Ermagan. We are doing work to enable LISP and NSH in Open vSwitch, and these slides gave some …

These slides were presented at the 2013 Linux Plumbers Conference in New Orleans by myself and Vina Ermagan. We are doing work to enable LISP and NSH in Open vSwitch, and these slides gave some background on both of these protocols as well as detail on what we've accomplished and future directions.

Published in: Technology, Education
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,303
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
180
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. LISP and NSH in Linux and Open vSwitch Vina Ermagan Lori Jakab Pritesh Kothari Kyle Mestery
  • 2. • Service Chaining Definition • LISP and Control Plane Service Chaining • Service Chaining in Data Plane : NSH • Problem statement • Work Completed • Next Steps
  • 3. • Service chaining is the broad term that describes delivering multiple services in a specific order – Decouples network topology and services – Supports dynamic insertion of services – Common model for all types of services • Composed of data plane (focus of this presentation) and control/policy planes – Control and policy planes: will vary based on environment and requirements. LISP control plane is one example. Area for innovation. – Data plane: common service header, shared between network platforms and services.
  • 4. Policy: - Traffic Engineering, - Service Chaining, - Load Balancing, etc. Data Plane: Encapsulation header to build a Multitenant Overlay Control Plane: Mapping of Overlay address Space to underlying physical Network + Policy VM VM VM VM VM App OS VM Database Open L3 Overlay Protocol (RFC 6830): - Decouple Network Control Plane from Data Plane - Provide Network Programmability - Control plane enables dynamic on demand tunneling
  • 5. • Enables a data plane hop by hop path via control plane ELP • L: Lookup bit indicating the Re-encap Hop’s address is an indirection and must be looked up in the mapping system. • P: Probe bit indicating the Re-encap Hop accepts reachability control messages. • S: Strict bit indicating the Re-encap Hop must be used. 00 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1 AFI = 16378 Rsvd1 Flags Type = 10 Rsvd2 Length AFI = x Rsvd3 L P S Re-encap Hop 1 AFI = x Rsvd3 L P S Re-encap Hop 2 LISP Mapping SystemNet Virtualization Edge Request RLOC for dest EID Response with ELP
  • 6. • N: The N-bit is the nonce-present bit. • L: The L-bit is the 'Locator-Status-Bits' field enabled • E: The E-bit is the echo-nonce-request bit. Used together with N=1 to test reachability • V: The V-bit is the Map-Version present bit. Used to indicate source and dest mapping version enabling mapping cache coherency • I: The I-bit is the Instance ID bit. Used for multi-tenancy and traffic segregation 00 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1 N L E V I - - - Nonce/Map-Version Instance ID/Locator-Status-Bits L2 Header L3 Header (protocol=17) UDP Header (port#=LISP) LISP IP Header Original Payload Endpoint ID: IP/MACRouting Locator
  • 7. • LISP Work Completed – Basic encap/decap support, flow based tunneling • Upstreamed to OVS, but not Linux – WireShark dissector support as of 1.10.x stable series – Command line support in ovs-vsctl • LISP Work Ongoing – Adding generic layer 3 tunneling support to OVS • pop_eth, push_eth, allowing a flow to be specified without an Ethernet header • Prerequisite for Linux upstreaming • ARP handling to add appropriate eth header in case of push_eth – Enable LISP-GPE – LISP control plane in OVS
  • 8. • Traffic Classifier – Determines what traffic requires services and forms the logical start of a service path. A traffic classifier imposes NSH header. • Service Path – A service path is the actual forwarding path used to realize a service chain. A service path identifier is carried in a NSH header. • Service Overlay – The network overlay used by the service path. NSH is overlay agnostic and can be used with existing DC overlays. • Context – Shared context, carried in a NSH header, enables network-service interaction and richer policy creation and enforcement. For example, classification from an edge device can be conveyed to a service.
  • 9. • Simple, fixed size header – 6 32 bits words: 2 word base header, 4 32 bit mandatory context (metadata) headers • Transport agnostic – VXLAN, LISP, NVGRE, MPLS, etc. • Context headers carry metadata along the service path – Significance determined by the control plane; – Innovate, create network value! 0 0 1 2 3 4 5 6 7 8 9 1 0 1 2 3 4 5 6 7 8 9 2 0 1 2 3 4 5 6 7 8 9 3 0 1 Base Header Base Header Context Header Context Header Context Header Context Header
  • 10. • O: OAM bit indicates packet is an OAM packet and must be punted • C: indicates that the context headers are in use and their allocation (if C = 0, all context values = 0, the headers are still present, just unused) • Protocol Type of the original packet payload • Service Index provides loop detection and location within the service chain. Can be used with a Service Path Identifier to derive unique value for forwarding • Service Path Identifier: identifier of a service path; used for service forwarding • Context Headers: packet metadata 00 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1 O C - - - - - - Protocol Type (16) Service Index (8) Service Path Identifier (24) - Network Platform Context Network Shared Context Service Platform Context Service Shared Context Original Packet Payload Base Header 1 Base Header 2 Context Header 1 Context Header 2 Context Header 3 Context Header 4
  • 11. • LISP has no mechanism to signal presence of a non-IP payload yet – Use UDP destination port to indicate Ethernet payload : draft-smith-lisp- layer2-03 – Addressed by new draft • http://www.ietf.org/id/draft-lewis-lisp-gpe-00.txt L2 Header L3 Header (protocol=17) UDP Header (port#=LISP) LISP NSH Original Payload Example: NSH + LISP 00 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 20 1 2 3 4 5 6 7 8 9 30 1 N L E V I P - - Nonce/Map-Version/Protocol-Type Instance ID/Locator-Status-Bits N,E,V bits are set to 0 when P=1
  • 12. • NSH headers are transport agnostic and can be used with any transport protocol • Support for overlay and underlay encapsulations – GRE, LISP, VXLAN, etc. • The outer encapsulation must indicate the presence of the NSH header – A new IEEE Ethertype will be allocated for NSH
  • 13. The state of service insertion …
  • 14. • Network services are ubiquitous – Firewall and load balancer are in almost every data center • Current state of the art is topology dependent – Very complex: VLAN-stitching, Policy Based Routing (PBR), etc. – Static: no dynamic, horizontal or vertical scaling, requires network changes • Service chaining is accomplished via hop-by-hop switching/routing changes • No way to share valuable information between the network and services, or between services • Data centers are evolving, with physical and virtual workloads and services – Primarily physical service insertion today • Services and service deployments must adapt to the hybrid and dynamic data centers • Service chains must span and converge these hybrid environments
  • 15. From To Physical Appliances Virtual Appliances Static services Dynamic services Separate domains: physical vs. virtual Seamless physical and virtual interoperability Hop-by-hop service deployment Chain of services Underlay networks Dynamic overlays Topological dependent insertion Insertion based on resources and scheduling No shared context Rich meta-data Policy based on VLANs Policy based on meta-data
  • 16. • Service chaining is the broad term that describes delivering multiple services in a specific order – Decouples network topology and services – Supports dynamic insertion of services – Common model for all types of services • Composed of data plane (focus of this presentation) and control/policy planes – Data plane: common service header, shared between network platforms and services. – Control and policy planes: will vary based on environment and requirements. Key area for innovation.
  • 17. Work we’ve done so far …
  • 18. • LISP Work Completed – Basic encap/decap support, flow based tunneling • Upstreamed to OVS, but not Linux – WireShark dissector support as of 1.10.x stable series – Command line support in ovs-vsctl • LISP Work Ongoing – Adding generic layer 3 tunneling support to OVS • pop_eth, push_eth, allowing a flow to be specified without an Ethernet header • Prerequisite for Linux upstreaming – Enable LISP-GPE
  • 19. • NSH Work Completed – Initial encap/decap prototype code finished • Works with the VXLAN code in upstream OVS – WireShark dissector code added • Helps in debugging NSH with VXLAN – Openflow support in OVS for flow matching on NSH Service Path ID (nsp). – Command line support in ovs-vsctl and ovs-ofctl for above flow matching. • NSH Work Ongoing – Move encap/decap code into the Linux kernel – Allow for stacking NSH with other overlay protocols (e.g. GRE and LISP)
  • 20. • Push out encap/decap code into github repository and send patches to ovs-dev mailing list • Add support for NSH service index to be allowed to be set using out_nsi=flow parameter. – Push this up into OVS • LISP is in the out-of-tree openvswitch kernel module – No standalone LISP tunneling support in Linux – LISP will be pushed to in-tree openvswitch module if layer 3 tunneling support generalized in OVS • Currently we push/pop Ethernet headers in the LISP code • LISP is seen as just another layer 2 port in OVS
  • 21. • Allow for an elastic, overlay based service network – NSH for services – GRE/LISP/VXLAN for the overlay network – Future unification of LISP and VxLAN via GPE drafts • Integration with OpenDaylight – Allow for programming of NSH information into OVS • Tie it all together with your elastic cloud platform – CloudStack – Eucalyptus – OpenStack
  • 22. • Upstreaming ? • GRE Support? • NSH directly over UDP and/or IP support? • Integration with OpenDaylight? • Next ? • LISP control plane support ?
  • 23. Questions?
  • 24. Backup Slides
  • 25. • VXLAN has no mechanism to signal presence of a non-Ethernet payload yet – Use UDP destination port to indicate new payload – Addressed by • http://www.ietf.org/id/draft-quinn-vxlan-gpe-00.txt L2 Header L3 Header (protocol=17) UDP Header (port#=0xnsh- vxlan) VXLAN NSH Svc Header (PT=0x6558) Original L2-Frame NSH + VXLAN using UDP port #
  • 26. • NVGRE has a protocol field to indicate payload type – 0x6558 is defined for Ethernet in NVGRE • NSH Ethertype carried in NVGRE – NSH protocol type is then indicate original payload type: IP or Ethernet L2 Header L3 Header (protocol=0x2F ) NVGRE Header (protocol=0xnsh) Svc Header (PT=0x0800) Original IPv4 Packet L2 Header L3 Header (protocol=0x2F ) NVGRE Header (protocol=0xnsh ) Svc Header (PT=0x6558) Original Ethernet Frame
  • 27. • In non-overlay topologies, native IP encapsulation can be used L2 Header L3 Header (protocol=17 ) UDP Header (port#=nsh) Svc Header (PT=0x6558) Original Ethernet Frame L2 Header L3 Header (protocol=17 ) UDP Header (port#=nsh) Svc Header (PT=0x0800) Original IPv4 Packet
  • 28. • The presence of metadata within an MPLS packet must be indicated in the encapsulation. – Generic Associated Channel (GAL) label [RFC5586] with label value 13 is utilized for this purpose. • The GAL label provides a method to identify that a packet contains an ”Metadata Channel Header (MCH)" followed by a non-service payload. – Draft-guichard-mpls-metadata-00 proposes an extension to [RFC5586] to allow the first nibble of the ACH to be set to 0000b indicating that Metadata follows.

×