This tutorial will overview the OpenDaylight Service Function Chaining (SFC) architecture, implementation and operation. A description of the SFC components and the Network Service Header (NSH) will be presented. This talk will conclude with a step-by-step demonstration of SFC configuration and operation using the GUI and REST interfaces.
6. Core Tenets
• ODL is a platform (not an SDK)
• Develop, load and run applications
• Innovative, vibrant community
• Everyone is welcome
• “Sideways” extension
• Model driven
• YANG modeling language
• Auto generated APIs
• Common north-bound API, but many south-bound protocols
• REST/RESTCONF NB
• OF, NC/YANG, SNMP, etc. SB
8. Yangtools – What is Yang?
• Yang is a modeling language
• Text based
• Simple Compact
• Models semantics and data
organization
• Models can be ‘augmented’
• Can model:
• Config/Operational data as a tree
• RPCs
• Notifications
• Standard based (RFC 6020)
9. Yangtools – What does Yangtools do?
• Generates Java code from Yang
• Provides ‘codecs’ to convert
• Generated Java classes to DOM
• DOM to various formats
• XML
• JSON
• Etc
• ‘Codecs’ make possible
automatic:
• RESTCONF
• Netconf
• Other bindings (AMQP expected
this summer)
Java
code
xml
json
exi
10. Evolving Service Deployment
• Service functions are used in almost all networks
• Deployment techniques haven’t changed in over a decade!
• Require network configuration changes: VLANs, PBR
• Static: no dynamic, horizontal or vertical scaling, and requires network changes
• Operationally disjoint: no “whole stack” view or orchestration
• Major impediment to application deployment
• How long does it take to deploy a new application or service?
• How much of that is due to network services?
• Service Function Chaining changes all that!
• Embraces the transitions taking places all over the network
• Virtualization
• Programmatic interfaces
• Overlays
• Abstraction
11. SFC Architectural Principles
1. Topology independent
2. Transport independent
3. Simplifies provisioning and orchestration
4. Provide clear visibility and OAM to operators
5. Unburden the service functions
6. Centralized and distributed control plane support
7. Metadata support
12. Service Classifier
Determines which traffic requires service and forms the logical start of a
service path
Service Path
A service path is the actual forwarding path used to realize a service chain
Think of service chain as the “intent”; service path the actual instantiation of
the chain in the network
Service Function Forwarder (SFF)
Responsible for delivering traffic received from the network to one or more
connected service functions according to information carried in the network
service header as well as handling traffic coming back from the SF
Service Function Proxy
Component used to process network service headers on-behalf of an
attached SF
SFC Data Plane Components
13. Orchestration
Define service chains &
build service paths
Control / Policy Planes
Instantiate service chains
adhering to policy
Data Plane
Traffic steering & metadata
Services Function Chaining Primer
High-level Component Structure
Service Chaining
Orchestration
SF
(VM)
Servi
ce
(v)switch
Forwar
ding
Servi
ce
Servic
e
Classif
ier
SF
(Physical
)
Service1VLAN
Service
Function
Forwarder
(SFF)
Control
Plane
Policy Plane
SF
(VM)
Servi
ce
(v)switch
Forwar
ding
Servi
ce
SF
(Physical
)
Service1VLAN
Service
Function
Forwarder
(SFF)
Servic
e
Classif
ier
Network
Overlay +
Service Header
Service Header
14. ODL SFC implementation components
Provider
YANG Models
UI
Data Plane
Data store Listeners and Renderers
REST
Openflow
LISP
https://wiki.opendaylight.org/view/Service_Function_C
haining:Main
Opendaylight SFC Main Components
16. ODL SFC in essence a point to multipoint
architecture
SFC Provider manages all configuration information
provided by orchestration system or admin.
SFC Provider writes constructed Service Function
Paths and Rendered Service Path to the datastore
Protocol datastore listeners are notified of service
objects creation
These listeners will process RSP information and
communicate to their controlled southbound devices
Big Picture
17. Opendaylight SFC Architecture
SF SFF
SFC Provider
DataStore
SFP
Openflow
Listener
REST
Listener
LISP
Listener
1
2 3
4RSP
SF = Service Function
SFF = Service Function Forwarder
SFP = Service Function Path
RSP = Rendered Service Path
Opendaylight
Open vSwitch Python NSH
Switch
GUI REST
18. One stop shop for everything SFC
Provides graphical view and configuration of
Rendered Service Paths, Service Chains, Service
Functions, etc
Extremely easy to use
Makes configuration and repetitive tasks easy: uses
templates, allows copy & replicating configuration,
bulk edits, amongst others
UI has built-in diagnostics to tell if SFC components
are running, state, pull logs from ODL, amongst
others.
SFC-UI
Provider is equiv of main()
Datastore is idependent
Datastore send notifications
Listeners register to receive notifications (based on YANG tree) from datastore ALWAYS true
Notifications are internal: same YANG model but encoding: json or java object
Point to multi point:
Provider = point
Renders/listeners are multipoints
Providers gets something from UI or REST, pushed to datastore
The listener get notification, and act on them, independently
“A path was created, an SFF was created”
If SFF has OVS augmentation data in YANG (with data) the listener looks for it
Datastore: has it’s tree in the datastore
OVS listener: communicates write ovs listener writes to ovs db datastore
Ovsdbplugin, gets notification, then acts
OF uses API/RPC
REST listener
NC listener uses NC plugin, same as OVSDB BUT does not write to datastore, when it puts, SFC NC listener, sends NC command protocol plug and send to device
EACH listener acts in it’s own environment, optimizes as it should
Provider is the main entry point for ALL “external” access
REST, UI via REST and GBP RPC all use SAME YANG models
Different encoding (http vs java objects)