- Service chaining provides a common way to deliver multiple services in a specific order, decoupling network topology from services and enabling dynamic service insertion.
- It has both a data plane, using a common service header (NSH) to build service chains, and a control plane for policy and mapping overlay addresses to the physical network.
- Work has included implementing NSH encapsulation/decap in OVS and adding WireShark support, with ongoing work on LISP integration and control plane functionality.
Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...
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
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.
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.