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

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.