SlideShare a Scribd company logo
1 of 28
Download to read offline
LISP and NSH
in Linux and Open vSwitch
Vina Ermagan
Lori Jakab
Pritesh Kothari
Kyle Mestery
• Service Chaining Definition
• LISP and Control Plane Service Chaining
• Service Chaining in Data Plane : NSH
• Problem statement
• Work Completed
• Next Steps
• 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.
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
• 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
• 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
• 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
• 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.
• 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
• 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
• 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
• 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
The state of service insertion …
• 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
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
• 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.
Work we’ve done so far …
• 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
• 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)
• 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
• 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
• Upstreaming ?
• GRE Support?
• NSH directly over UDP and/or IP support?
• Integration with OpenDaylight?
• Next ?
• LISP control plane support ?
Questions?
Backup Slides
• 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 #
• 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
• 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
• 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.

More Related Content

What's hot

Tech Tutorial by Vikram Dham: Let's build MPLS router using SDN
Tech Tutorial by Vikram Dham: Let's build MPLS router using SDNTech Tutorial by Vikram Dham: Let's build MPLS router using SDN
Tech Tutorial by Vikram Dham: Let's build MPLS router using SDNnvirters
 
Open stackdaykorea2016 wedge
Open stackdaykorea2016 wedgeOpen stackdaykorea2016 wedge
Open stackdaykorea2016 wedgeJunho Suh
 
Dynamic Service Chaining
Dynamic Service Chaining Dynamic Service Chaining
Dynamic Service Chaining Tail-f Systems
 
OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...
OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...
OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...Junho Suh
 
Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...
Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...
Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...nvirters
 
DPACC Acceleration Progress and Demonstration
DPACC Acceleration Progress and DemonstrationDPACC Acceleration Progress and Demonstration
DPACC Acceleration Progress and DemonstrationOPNFV
 
NFV Linaro Connect Keynote
NFV Linaro Connect KeynoteNFV Linaro Connect Keynote
NFV Linaro Connect KeynoteLinaro
 
Runos OpenFlow Controller (eng)
Runos OpenFlow Controller (eng)Runos OpenFlow Controller (eng)
Runos OpenFlow Controller (eng)Alexander Shalimov
 
OpenFlow tutorial
OpenFlow tutorialOpenFlow tutorial
OpenFlow tutorialopenflow
 
Accelerate Service Function Chaining Vertical Solution with DPDK
Accelerate Service Function Chaining Vertical Solution with DPDKAccelerate Service Function Chaining Vertical Solution with DPDK
Accelerate Service Function Chaining Vertical Solution with DPDKOPNFV
 
Bgpcep odl summit 2015
Bgpcep odl summit 2015Bgpcep odl summit 2015
Bgpcep odl summit 2015Giles Heron
 
SDN & NFV Introduction - Open Source Data Center Networking
SDN & NFV Introduction - Open Source Data Center NetworkingSDN & NFV Introduction - Open Source Data Center Networking
SDN & NFV Introduction - Open Source Data Center NetworkingThomas Graf
 
Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...
Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...
Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...Junho Suh
 
Accelerating SDN Applications with Open Source Network Overlays
Accelerating SDN Applications with Open Source Network OverlaysAccelerating SDN Applications with Open Source Network Overlays
Accelerating SDN Applications with Open Source Network OverlaysCumulus Networks
 
Openstack Neutron Insights
Openstack Neutron InsightsOpenstack Neutron Insights
Openstack Neutron InsightsAtul Pandey
 
Implementing IPv6 Segment Routing in the Linux kernel
Implementing IPv6 Segment Routing in the Linux kernelImplementing IPv6 Segment Routing in the Linux kernel
Implementing IPv6 Segment Routing in the Linux kernelOlivier Bonaventure
 
DEVNET-1006 Getting Started with OpenDayLight
DEVNET-1006	Getting Started with OpenDayLightDEVNET-1006	Getting Started with OpenDayLight
DEVNET-1006 Getting Started with OpenDayLightCisco DevNet
 

What's hot (20)

Tech Tutorial by Vikram Dham: Let's build MPLS router using SDN
Tech Tutorial by Vikram Dham: Let's build MPLS router using SDNTech Tutorial by Vikram Dham: Let's build MPLS router using SDN
Tech Tutorial by Vikram Dham: Let's build MPLS router using SDN
 
Open stackdaykorea2016 wedge
Open stackdaykorea2016 wedgeOpen stackdaykorea2016 wedge
Open stackdaykorea2016 wedge
 
Dynamic Service Chaining
Dynamic Service Chaining Dynamic Service Chaining
Dynamic Service Chaining
 
OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...
OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...
OCP Summit 2016 - Transforming Networks to All-IT Network with OCP and Open N...
 
Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...
Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...
Tech Talk by John Casey (CTO) CPLANE_NETWORKS : High Performance OpenStack Ne...
 
DPACC Acceleration Progress and Demonstration
DPACC Acceleration Progress and DemonstrationDPACC Acceleration Progress and Demonstration
DPACC Acceleration Progress and Demonstration
 
NFV Linaro Connect Keynote
NFV Linaro Connect KeynoteNFV Linaro Connect Keynote
NFV Linaro Connect Keynote
 
Runos OpenFlow Controller (eng)
Runos OpenFlow Controller (eng)Runos OpenFlow Controller (eng)
Runos OpenFlow Controller (eng)
 
SEGMENT Routing
SEGMENT RoutingSEGMENT Routing
SEGMENT Routing
 
OpenFlow tutorial
OpenFlow tutorialOpenFlow tutorial
OpenFlow tutorial
 
Accelerate Service Function Chaining Vertical Solution with DPDK
Accelerate Service Function Chaining Vertical Solution with DPDKAccelerate Service Function Chaining Vertical Solution with DPDK
Accelerate Service Function Chaining Vertical Solution with DPDK
 
Bgpcep odl summit 2015
Bgpcep odl summit 2015Bgpcep odl summit 2015
Bgpcep odl summit 2015
 
SDN & NFV Introduction - Open Source Data Center Networking
SDN & NFV Introduction - Open Source Data Center NetworkingSDN & NFV Introduction - Open Source Data Center Networking
SDN & NFV Introduction - Open Source Data Center Networking
 
Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...
Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...
Opensample: A Low-latency, Sampling-based Measurement Platform for Software D...
 
Accelerating SDN Applications with Open Source Network Overlays
Accelerating SDN Applications with Open Source Network OverlaysAccelerating SDN Applications with Open Source Network Overlays
Accelerating SDN Applications with Open Source Network Overlays
 
Openstack Neutron Insights
Openstack Neutron InsightsOpenstack Neutron Insights
Openstack Neutron Insights
 
Cumulus Linux 2.5.3
Cumulus Linux 2.5.3Cumulus Linux 2.5.3
Cumulus Linux 2.5.3
 
Implementing IPv6 Segment Routing in the Linux kernel
Implementing IPv6 Segment Routing in the Linux kernelImplementing IPv6 Segment Routing in the Linux kernel
Implementing IPv6 Segment Routing in the Linux kernel
 
DEVNET-1006 Getting Started with OpenDayLight
DEVNET-1006	Getting Started with OpenDayLightDEVNET-1006	Getting Started with OpenDayLight
DEVNET-1006 Getting Started with OpenDayLight
 
SDN Project PPT
SDN Project PPTSDN Project PPT
SDN Project PPT
 

Viewers also liked

Next Generation Network Management for Service Providers
Next Generation Network Management for Service ProvidersNext Generation Network Management for Service Providers
Next Generation Network Management for Service ProvidersCisco Service Provider
 
Summit 16: Service Function Chaining: Demo and Usage
Summit 16: Service Function Chaining: Demo and UsageSummit 16: Service Function Chaining: Demo and Usage
Summit 16: Service Function Chaining: Demo and UsageOPNFV
 
ONOS-Based VIM Implementation
ONOS-Based VIM ImplementationONOS-Based VIM Implementation
ONOS-Based VIM ImplementationOPNFV
 
Flowspec @ Bay Area Juniper User Group (BAJUG)
Flowspec @ Bay Area Juniper User Group (BAJUG)Flowspec @ Bay Area Juniper User Group (BAJUG)
Flowspec @ Bay Area Juniper User Group (BAJUG)Juniper Networks
 
Managing Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed Rawi
Managing Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed RawiManaging Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed Rawi
Managing Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed RawiMyNOG
 
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...Shuichi Ohkubo
 
DDoS Mitigation using BGP Flowspec
DDoS Mitigation using BGP Flowspec DDoS Mitigation using BGP Flowspec
DDoS Mitigation using BGP Flowspec APNIC
 
Protect your edge BGP security made simple
Protect your edge BGP security made simpleProtect your edge BGP security made simple
Protect your edge BGP security made simplePavel Odintsov
 
Keeping your rack cool
Keeping your rack cool Keeping your rack cool
Keeping your rack cool Pavel Odintsov
 
BGP Flowspec (RFC5575) Case study and Discussion
BGP Flowspec (RFC5575) Case study and DiscussionBGP Flowspec (RFC5575) Case study and Discussion
BGP Flowspec (RFC5575) Case study and DiscussionAPNIC
 
Triangle OpenStack Meetup
Triangle OpenStack MeetupTriangle OpenStack Meetup
Triangle OpenStack Meetupmestery
 
Dell SUSE Cloud Solution, Powered by OpenStack
Dell SUSE Cloud Solution, Powered by OpenStackDell SUSE Cloud Solution, Powered by OpenStack
Dell SUSE Cloud Solution, Powered by OpenStackKamesh Pemmaraju
 
Designing OpenStack Architectures
Designing OpenStack ArchitecturesDesigning OpenStack Architectures
Designing OpenStack ArchitecturesKamesh Pemmaraju
 
Open stack icehouse microsoftupdate
Open stack icehouse microsoftupdateOpen stack icehouse microsoftupdate
Open stack icehouse microsoftupdateKamesh Pemmaraju
 
vBrownBag OpenStack Networking Talk
vBrownBag OpenStack Networking TalkvBrownBag OpenStack Networking Talk
vBrownBag OpenStack Networking Talkmestery
 
OpenStack Neutron Liberty Updates
OpenStack Neutron Liberty UpdatesOpenStack Neutron Liberty Updates
OpenStack Neutron Liberty Updatesmestery
 
Dell openstack cloud with inktank ceph – large scale customer deployment
Dell openstack cloud with inktank ceph – large scale customer deploymentDell openstack cloud with inktank ceph – large scale customer deployment
Dell openstack cloud with inktank ceph – large scale customer deploymentKamesh Pemmaraju
 

Viewers also liked (20)

Next Generation Network Management for Service Providers
Next Generation Network Management for Service ProvidersNext Generation Network Management for Service Providers
Next Generation Network Management for Service Providers
 
Summit 16: Service Function Chaining: Demo and Usage
Summit 16: Service Function Chaining: Demo and UsageSummit 16: Service Function Chaining: Demo and Usage
Summit 16: Service Function Chaining: Demo and Usage
 
ONOS-Based VIM Implementation
ONOS-Based VIM ImplementationONOS-Based VIM Implementation
ONOS-Based VIM Implementation
 
Flowspec @ Bay Area Juniper User Group (BAJUG)
Flowspec @ Bay Area Juniper User Group (BAJUG)Flowspec @ Bay Area Juniper User Group (BAJUG)
Flowspec @ Bay Area Juniper User Group (BAJUG)
 
2015-ShowNet -DDoS/IX/BGPFlowspec/External
2015-ShowNet -DDoS/IX/BGPFlowspec/External2015-ShowNet -DDoS/IX/BGPFlowspec/External
2015-ShowNet -DDoS/IX/BGPFlowspec/External
 
Managing Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed Rawi
Managing Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed RawiManaging Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed Rawi
Managing Traffic Flows via BGP Flowspec by Mohd Izni Zuhdi Mohamed Rawi
 
BGP Monitoring Protocol
BGP Monitoring ProtocolBGP Monitoring Protocol
BGP Monitoring Protocol
 
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
2015.7.17 JANOG36 BGP Flowspec Interoperability Test @ Interop Tokyo 2015 Sho...
 
DDoS Mitigation using BGP Flowspec
DDoS Mitigation using BGP Flowspec DDoS Mitigation using BGP Flowspec
DDoS Mitigation using BGP Flowspec
 
Protect your edge BGP security made simple
Protect your edge BGP security made simpleProtect your edge BGP security made simple
Protect your edge BGP security made simple
 
Keeping your rack cool
Keeping your rack cool Keeping your rack cool
Keeping your rack cool
 
BGP Flowspec (RFC5575) Case study and Discussion
BGP Flowspec (RFC5575) Case study and DiscussionBGP Flowspec (RFC5575) Case study and Discussion
BGP Flowspec (RFC5575) Case study and Discussion
 
kamesh Videos
kamesh Videoskamesh Videos
kamesh Videos
 
Triangle OpenStack Meetup
Triangle OpenStack MeetupTriangle OpenStack Meetup
Triangle OpenStack Meetup
 
Dell SUSE Cloud Solution, Powered by OpenStack
Dell SUSE Cloud Solution, Powered by OpenStackDell SUSE Cloud Solution, Powered by OpenStack
Dell SUSE Cloud Solution, Powered by OpenStack
 
Designing OpenStack Architectures
Designing OpenStack ArchitecturesDesigning OpenStack Architectures
Designing OpenStack Architectures
 
Open stack icehouse microsoftupdate
Open stack icehouse microsoftupdateOpen stack icehouse microsoftupdate
Open stack icehouse microsoftupdate
 
vBrownBag OpenStack Networking Talk
vBrownBag OpenStack Networking TalkvBrownBag OpenStack Networking Talk
vBrownBag OpenStack Networking Talk
 
OpenStack Neutron Liberty Updates
OpenStack Neutron Liberty UpdatesOpenStack Neutron Liberty Updates
OpenStack Neutron Liberty Updates
 
Dell openstack cloud with inktank ceph – large scale customer deployment
Dell openstack cloud with inktank ceph – large scale customer deploymentDell openstack cloud with inktank ceph – large scale customer deployment
Dell openstack cloud with inktank ceph – large scale customer deployment
 

Similar to LISP and NSH in Open vSwitch

The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale NetworkThe Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale NetworkOpen Networking Summits
 
TechWiseTV Workshop: Segment Routing for the Datacenter
TechWiseTV Workshop: Segment Routing for the DatacenterTechWiseTV Workshop: Segment Routing for the Datacenter
TechWiseTV Workshop: Segment Routing for the DatacenterRobb Boyd
 
Open vSwitch Introduction
Open vSwitch IntroductionOpen vSwitch Introduction
Open vSwitch IntroductionHungWei Chiu
 
lect4_SDNbasic_openflow.pptx
lect4_SDNbasic_openflow.pptxlect4_SDNbasic_openflow.pptx
lect4_SDNbasic_openflow.pptxJesicaDcruz1
 
02 coms 525 tcpip - introduction to tcpip
02   coms 525 tcpip -  introduction to tcpip02   coms 525 tcpip -  introduction to tcpip
02 coms 525 tcpip - introduction to tcpipPalanivel Kuppusamy
 
Web technologies: recap on TCP-IP
Web technologies: recap on TCP-IPWeb technologies: recap on TCP-IP
Web technologies: recap on TCP-IPPiero Fraternali
 
OVN - Basics and deep dive
OVN - Basics and deep diveOVN - Basics and deep dive
OVN - Basics and deep diveTrinath Somanchi
 
Understanding i pv6 2
Understanding i pv6 2Understanding i pv6 2
Understanding i pv6 2srmanjuskp
 
Network architecure (3).pptx
Network architecure (3).pptxNetwork architecure (3).pptx
Network architecure (3).pptxKaythry P
 
Sept 2017 internetworking
Sept 2017   internetworkingSept 2017   internetworking
Sept 2017 internetworkingshahin raj
 
FD.io Vector Packet Processing (VPP)
FD.io Vector Packet Processing (VPP)FD.io Vector Packet Processing (VPP)
FD.io Vector Packet Processing (VPP)Kirill Tsym
 
FD.IO Vector Packet Processing
FD.IO Vector Packet ProcessingFD.IO Vector Packet Processing
FD.IO Vector Packet ProcessingKernel TLV
 
Introduction to OpenFlow
Introduction to OpenFlowIntroduction to OpenFlow
Introduction to OpenFlowJoel W. King
 
The hague rina-workshop-intro-eduard
The hague rina-workshop-intro-eduardThe hague rina-workshop-intro-eduard
The hague rina-workshop-intro-eduardICT PRISTINE
 
Supporting Virtualized Telco Applications with OpenStack
Supporting Virtualized Telco Applications with OpenStackSupporting Virtualized Telco Applications with OpenStack
Supporting Virtualized Telco Applications with OpenStackBruce Davie
 

Similar to LISP and NSH in Open vSwitch (20)

Link_NwkingforDevOps
Link_NwkingforDevOpsLink_NwkingforDevOps
Link_NwkingforDevOps
 
The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale NetworkThe Challenges of SDN/OpenFlow in an Operational and Large-scale Network
The Challenges of SDN/OpenFlow in an Operational and Large-scale Network
 
TechWiseTV Workshop: Segment Routing for the Datacenter
TechWiseTV Workshop: Segment Routing for the DatacenterTechWiseTV Workshop: Segment Routing for the Datacenter
TechWiseTV Workshop: Segment Routing for the Datacenter
 
Open vSwitch Introduction
Open vSwitch IntroductionOpen vSwitch Introduction
Open vSwitch Introduction
 
lect4_SDNbasic_openflow.pptx
lect4_SDNbasic_openflow.pptxlect4_SDNbasic_openflow.pptx
lect4_SDNbasic_openflow.pptx
 
MPLS Tutorial2
MPLS Tutorial2MPLS Tutorial2
MPLS Tutorial2
 
MPLS Tutorial
MPLS TutorialMPLS Tutorial
MPLS Tutorial
 
02 coms 525 tcpip - introduction to tcpip
02   coms 525 tcpip -  introduction to tcpip02   coms 525 tcpip -  introduction to tcpip
02 coms 525 tcpip - introduction to tcpip
 
Web technologies: recap on TCP-IP
Web technologies: recap on TCP-IPWeb technologies: recap on TCP-IP
Web technologies: recap on TCP-IP
 
OVN - Basics and deep dive
OVN - Basics and deep diveOVN - Basics and deep dive
OVN - Basics and deep dive
 
Understanding i pv6 2
Understanding i pv6 2Understanding i pv6 2
Understanding i pv6 2
 
Network architecure (3).pptx
Network architecure (3).pptxNetwork architecure (3).pptx
Network architecure (3).pptx
 
Raga_SDN_NSX_1
Raga_SDN_NSX_1Raga_SDN_NSX_1
Raga_SDN_NSX_1
 
ODP Presentation LinuxCon NA 2014
ODP Presentation LinuxCon NA 2014ODP Presentation LinuxCon NA 2014
ODP Presentation LinuxCon NA 2014
 
Sept 2017 internetworking
Sept 2017   internetworkingSept 2017   internetworking
Sept 2017 internetworking
 
FD.io Vector Packet Processing (VPP)
FD.io Vector Packet Processing (VPP)FD.io Vector Packet Processing (VPP)
FD.io Vector Packet Processing (VPP)
 
FD.IO Vector Packet Processing
FD.IO Vector Packet ProcessingFD.IO Vector Packet Processing
FD.IO Vector Packet Processing
 
Introduction to OpenFlow
Introduction to OpenFlowIntroduction to OpenFlow
Introduction to OpenFlow
 
The hague rina-workshop-intro-eduard
The hague rina-workshop-intro-eduardThe hague rina-workshop-intro-eduard
The hague rina-workshop-intro-eduard
 
Supporting Virtualized Telco Applications with OpenStack
Supporting Virtualized Telco Applications with OpenStackSupporting Virtualized Telco Applications with OpenStack
Supporting Virtualized Telco Applications with OpenStack
 

More from mestery

OVN: Scaleable Virtual Networking for Open vSwitch
OVN: Scaleable Virtual Networking for Open vSwitchOVN: Scaleable Virtual Networking for Open vSwitch
OVN: Scaleable Virtual Networking for Open vSwitchmestery
 
OpenStack Tokyo Summit Keynote Slides
OpenStack Tokyo Summit Keynote SlidesOpenStack Tokyo Summit Keynote Slides
OpenStack Tokyo Summit Keynote Slidesmestery
 
OpenStack Neutron: What's New In Kilo and a Look Toward Liberty
OpenStack Neutron: What's New In Kilo and a Look Toward LibertyOpenStack Neutron: What's New In Kilo and a Look Toward Liberty
OpenStack Neutron: What's New In Kilo and a Look Toward Libertymestery
 
OpenStack Neutron Tutorial
OpenStack Neutron TutorialOpenStack Neutron Tutorial
OpenStack Neutron Tutorialmestery
 
Group Based Policy: Open Source Policy in OpenDaylight and OpenStack Neutron
Group Based Policy: Open Source Policy in OpenDaylight and OpenStack NeutronGroup Based Policy: Open Source Policy in OpenDaylight and OpenStack Neutron
Group Based Policy: Open Source Policy in OpenDaylight and OpenStack Neutronmestery
 
Open Source Backends for OpenStack Neutron
Open Source Backends for OpenStack NeutronOpen Source Backends for OpenStack Neutron
Open Source Backends for OpenStack Neutronmestery
 
OpenStack and OpenDaylight Workshop: ONUG Spring 2014
OpenStack and OpenDaylight Workshop: ONUG Spring 2014OpenStack and OpenDaylight Workshop: ONUG Spring 2014
OpenStack and OpenDaylight Workshop: ONUG Spring 2014mestery
 
OpenDaylight Integration with OpenStack Neutron: A Tutorial
OpenDaylight Integration with OpenStack Neutron: A TutorialOpenDaylight Integration with OpenStack Neutron: A Tutorial
OpenDaylight Integration with OpenStack Neutron: A Tutorialmestery
 
Next Generation Network Developer Skills
Next Generation Network Developer SkillsNext Generation Network Developer Skills
Next Generation Network Developer Skillsmestery
 
Modular Layer 2 In OpenStack Neutron
Modular Layer 2 In OpenStack NeutronModular Layer 2 In OpenStack Neutron
Modular Layer 2 In OpenStack Neutronmestery
 
OpenStack: Why Is It Gaining So Much Traction?
OpenStack: Why Is It Gaining So Much Traction?OpenStack: Why Is It Gaining So Much Traction?
OpenStack: Why Is It Gaining So Much Traction?mestery
 
OpenStack Development Using devstack
OpenStack Development Using devstackOpenStack Development Using devstack
OpenStack Development Using devstackmestery
 
Open Source Cloud, Virtualization and Deployment Technologies
Open Source Cloud, Virtualization and Deployment TechnologiesOpen Source Cloud, Virtualization and Deployment Technologies
Open Source Cloud, Virtualization and Deployment Technologiesmestery
 

More from mestery (13)

OVN: Scaleable Virtual Networking for Open vSwitch
OVN: Scaleable Virtual Networking for Open vSwitchOVN: Scaleable Virtual Networking for Open vSwitch
OVN: Scaleable Virtual Networking for Open vSwitch
 
OpenStack Tokyo Summit Keynote Slides
OpenStack Tokyo Summit Keynote SlidesOpenStack Tokyo Summit Keynote Slides
OpenStack Tokyo Summit Keynote Slides
 
OpenStack Neutron: What's New In Kilo and a Look Toward Liberty
OpenStack Neutron: What's New In Kilo and a Look Toward LibertyOpenStack Neutron: What's New In Kilo and a Look Toward Liberty
OpenStack Neutron: What's New In Kilo and a Look Toward Liberty
 
OpenStack Neutron Tutorial
OpenStack Neutron TutorialOpenStack Neutron Tutorial
OpenStack Neutron Tutorial
 
Group Based Policy: Open Source Policy in OpenDaylight and OpenStack Neutron
Group Based Policy: Open Source Policy in OpenDaylight and OpenStack NeutronGroup Based Policy: Open Source Policy in OpenDaylight and OpenStack Neutron
Group Based Policy: Open Source Policy in OpenDaylight and OpenStack Neutron
 
Open Source Backends for OpenStack Neutron
Open Source Backends for OpenStack NeutronOpen Source Backends for OpenStack Neutron
Open Source Backends for OpenStack Neutron
 
OpenStack and OpenDaylight Workshop: ONUG Spring 2014
OpenStack and OpenDaylight Workshop: ONUG Spring 2014OpenStack and OpenDaylight Workshop: ONUG Spring 2014
OpenStack and OpenDaylight Workshop: ONUG Spring 2014
 
OpenDaylight Integration with OpenStack Neutron: A Tutorial
OpenDaylight Integration with OpenStack Neutron: A TutorialOpenDaylight Integration with OpenStack Neutron: A Tutorial
OpenDaylight Integration with OpenStack Neutron: A Tutorial
 
Next Generation Network Developer Skills
Next Generation Network Developer SkillsNext Generation Network Developer Skills
Next Generation Network Developer Skills
 
Modular Layer 2 In OpenStack Neutron
Modular Layer 2 In OpenStack NeutronModular Layer 2 In OpenStack Neutron
Modular Layer 2 In OpenStack Neutron
 
OpenStack: Why Is It Gaining So Much Traction?
OpenStack: Why Is It Gaining So Much Traction?OpenStack: Why Is It Gaining So Much Traction?
OpenStack: Why Is It Gaining So Much Traction?
 
OpenStack Development Using devstack
OpenStack Development Using devstackOpenStack Development Using devstack
OpenStack Development Using devstack
 
Open Source Cloud, Virtualization and Deployment Technologies
Open Source Cloud, Virtualization and Deployment TechnologiesOpen Source Cloud, Virtualization and Deployment Technologies
Open Source Cloud, Virtualization and Deployment Technologies
 

Recently uploaded

Dublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptxDublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptxKunal Gupta
 
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...Wes McKinney
 
Digital Tools & AI in Career Development
Digital Tools & AI in Career DevelopmentDigital Tools & AI in Career Development
Digital Tools & AI in Career DevelopmentMahmoud Rabie
 
Automation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions managementAutomation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions managementDianaGray10
 
QMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfQMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfROWELL MARQUINA
 
Genislab builds better products and faster go-to-market with Lean project man...
Genislab builds better products and faster go-to-market with Lean project man...Genislab builds better products and faster go-to-market with Lean project man...
Genislab builds better products and faster go-to-market with Lean project man...Farhan Tariq
 
WomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneWomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneUiPathCommunity
 
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdfHCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdfROWELL MARQUINA
 
Introduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptxIntroduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptxmprakaash5
 
Landscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfLandscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfAarwolf Industries LLC
 
Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!Memoori
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesBernd Ruecker
 
Glenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security ObservabilityGlenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security Observabilityitnewsafrica
 
Potential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsPotential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsRavi Sanghani
 
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...itnewsafrica
 
Testing tools and AI - ideas what to try with some tool examples
Testing tools and AI - ideas what to try with some tool examplesTesting tools and AI - ideas what to try with some tool examples
Testing tools and AI - ideas what to try with some tool examplesKari Kakkonen
 
Decarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityDecarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityIES VE
 
Which standard is best for your content?
Which standard is best for your content?Which standard is best for your content?
Which standard is best for your content?Rustici Software
 
Dynamical Context introduction word sensibility orientation
Dynamical Context introduction word sensibility orientationDynamical Context introduction word sensibility orientation
Dynamical Context introduction word sensibility orientationBuild Intuit
 
Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Hiroshi SHIBATA
 

Recently uploaded (20)

Dublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptxDublin_mulesoft_meetup_API_specifications.pptx
Dublin_mulesoft_meetup_API_specifications.pptx
 
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
The Future Roadmap for the Composable Data Stack - Wes McKinney - Data Counci...
 
Digital Tools & AI in Career Development
Digital Tools & AI in Career DevelopmentDigital Tools & AI in Career Development
Digital Tools & AI in Career Development
 
Automation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions managementAutomation Ops Series: Session 3 - Solutions management
Automation Ops Series: Session 3 - Solutions management
 
QMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdfQMMS Lesson 2 - Using MS Excel Formula.pdf
QMMS Lesson 2 - Using MS Excel Formula.pdf
 
Genislab builds better products and faster go-to-market with Lean project man...
Genislab builds better products and faster go-to-market with Lean project man...Genislab builds better products and faster go-to-market with Lean project man...
Genislab builds better products and faster go-to-market with Lean project man...
 
WomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyoneWomenInAutomation2024: AI and Automation for eveyone
WomenInAutomation2024: AI and Automation for eveyone
 
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdfHCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
HCI Lesson 1 - Introduction to Human-Computer Interaction.pdf
 
Introduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptxIntroduction-to-Wazuh-and-its-integration.pptx
Introduction-to-Wazuh-and-its-integration.pptx
 
Landscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdfLandscape Catalogue 2024 Australia-1.pdf
Landscape Catalogue 2024 Australia-1.pdf
 
Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!Laying the Data Foundations for Artificial Intelligence!
Laying the Data Foundations for Artificial Intelligence!
 
QCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architecturesQCon London: Mastering long-running processes in modern architectures
QCon London: Mastering long-running processes in modern architectures
 
Glenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security ObservabilityGlenn Lazarus- Why Your Observability Strategy Needs Security Observability
Glenn Lazarus- Why Your Observability Strategy Needs Security Observability
 
Potential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and InsightsPotential of AI (Generative AI) in Business: Learnings and Insights
Potential of AI (Generative AI) in Business: Learnings and Insights
 
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...Abdul Kader Baba- Managing Cybersecurity Risks  and Compliance Requirements i...
Abdul Kader Baba- Managing Cybersecurity Risks and Compliance Requirements i...
 
Testing tools and AI - ideas what to try with some tool examples
Testing tools and AI - ideas what to try with some tool examplesTesting tools and AI - ideas what to try with some tool examples
Testing tools and AI - ideas what to try with some tool examples
 
Decarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a realityDecarbonising Buildings: Making a net-zero built environment a reality
Decarbonising Buildings: Making a net-zero built environment a reality
 
Which standard is best for your content?
Which standard is best for your content?Which standard is best for your content?
Which standard is best for your content?
 
Dynamical Context introduction word sensibility orientation
Dynamical Context introduction word sensibility orientationDynamical Context introduction word sensibility orientation
Dynamical Context introduction word sensibility orientation
 
Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024Long journey of Ruby standard library at RubyConf AU 2024
Long journey of Ruby standard library at RubyConf AU 2024
 

LISP and NSH in Open vSwitch

  • 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 ?
  • 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.