DEVNET-1175 OpenDaylight Service Function Chaining
Download as PPTX, PDF2 likes2,688 views
The document provides an overview of OpenDaylight and its implementation of Service Function Chaining (SFC), highlighting its architecture, components, and benefits for network service deployment. It emphasizes the use of YANG modeling language for creating models to automate network functions and improve operational efficiency. Additionally, it describes the various service functions, orchestration protocols, and the user interface for managing SFC configurations.
![SFC JSON Data
"service-function": [
{
"name": "SF5",
"sf-data-plane-locator": [
{
"name": "vxlan",
"ip": "10.0.1.43",
"port": 40001,
"transport": "service-
locator:vxlan-gpe",
"service-function-
forwarder": "SFF4"
}
],
"nsh-aware": true,
"rest-uri":
"http://10.0.1.43:5000",
"ip-mgmt-address":
"10.0.1.43",
"type": "service-function-
type:napt44"
}
"service-function-forwarder": [
{
"name": "SFF4",
"sff-data-plane-locator": [
{
"name": "eth0",
"data-plane-locator": {
"port": 4789,
"ip": "10.0.1.44",
"transport": "service-
locator:vxlan-gpe"
}
}
],
"rest-uri":
"http://10.0.1.44:5000",
"service-function-dictionary": [
{
"name": "SF5",
"type": "service-function-
type:napt44",
"sff-sf-data-plane-locator": {
"port": 40001,
"ip": "10.0.1.43",
"transport": "service-
locator:vxlan-gpe"
}
}
],
"ip-mgmt-address": "10.0.1.43",
}](https://image.slidesharecdn.com/r0skskurnowv3oqjdkya-signature-03d1a74432f99610b022a606b1d0abe1ff90e583b8c17520d994ad5be5eb1089-poli-150630212259-lva1-app6892/85/DEVNET-1175-OpenDaylight-Service-Function-Chaining-20-320.jpg)
![SFC JSON Data
"service-function-chain": [
{
"name": "SFC2",
"sfc-service-function": [
{
"name": "firewall-
abstract2",
"type": "service-function-
type:firewall",
"order": 0
},
{
"name": "napt44-
abstract2",
"type": "service-function-
type:napt44",
"order": 1
}
]
}
"service-function-path": [
{
"name": "Path-2-SFC2",
"service-chain-name":
"SFC2",
"symmetric": true
}](https://image.slidesharecdn.com/r0skskurnowv3oqjdkya-signature-03d1a74432f99610b022a606b1d0abe1ff90e583b8c17520d994ad5be5eb1089-poli-150630212259-lva1-app6892/85/DEVNET-1175-OpenDaylight-Service-Function-Chaining-21-320.jpg)
!["rendered-service-path": [
{
"name": "Path-2-SFC2",
"parent-service-function-path": "Path-2-SFC2",
"path-id": 9,
"service-chain-name": "SFC2",
"starting-index": 255,
"rendered-service-path-hop": [
{
"hop-number": 0,
"service-function-name": "SF4",
"service-function-forwarder": "SFF3",
"service_index": 255
},
{
"hop-number": 1,
"service-function-name": "SF5",
"service-function-forwarder": "SFF4",
"service_index": 254
}
]
}
Operational Data](https://image.slidesharecdn.com/r0skskurnowv3oqjdkya-signature-03d1a74432f99610b022a606b1d0abe1ff90e583b8c17520d994ad5be5eb1089-poli-150630212259-lva1-app6892/85/DEVNET-1175-OpenDaylight-Service-Function-Chaining-22-320.jpg)
More Related Content
Similar to DEVNET-1175 OpenDaylight Service Function Chaining (20)
More from Cisco DevNet (20)
DEVNET-1175 OpenDaylight Service Function Chaining
- 2. • OpenDaylight Overview • Service Function Chaining Overview • OpenDaylight Implementation Agenda
- 3. What is OpenDaylight • Multi-project • Multi-party • Open Source • Platform (not SDK)
- 4. Who is ODL – Corporate Version ODL Member Companies
- 5. 42(!) Projects in Lithium gbpmdsal lisp yangtools neutron persistence plugin2oc topoprocessing bgp sxp snmp didm alto opflex sdni openflow l2switch dlux vpn tsdr lacp nic pcmm ttp ovsdb vtn usc reservation iotdm autorelease tutorials defense4all documentation integration sfc builder capwap snmp4sdn netconf pcep restconf Kernel Protocol Plugins Applications Support
- 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
- 7. OpenDaylight: Open Source SDN Controller Controller Service Adaptation Layer Inventory Manager Base Network Functions Topology ExporterStatistics Manager Forwarding Rules Manager Topology ExporterTopology Exporter Inventory ManagerInventory Manager OpenFlow 1.0/1.3 BGP-LS PCEP Netconf Client OVSDB REST APIs ... Service Functions SFC ...Configuration Subsystem NETCONF LISP Network Devices Applications Network Applications Orchestration & Services Controller Platform Southbound Interfaces & Protocol Plugins
- 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
- 15. Yang Models • rendered-service-path.yang • service-function.yang • service-function-acl.yang • service-function-chain.yang • service-function-classifier.yang • service-function-description- monitor.yang • service-function-description- monitor-report.yang • service-function-forwarder.yang • service-function-forwarder- ovs.yang • service-function-path.yang • service-function-path- metadata.yang • service-function-type.yang • service-locator.yang
- 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
- 19. SFC Front End
- 20. SFC JSON Data "service-function": [ { "name": "SF5", "sf-data-plane-locator": [ { "name": "vxlan", "ip": "10.0.1.43", "port": 40001, "transport": "service- locator:vxlan-gpe", "service-function- forwarder": "SFF4" } ], "nsh-aware": true, "rest-uri": "http://10.0.1.43:5000", "ip-mgmt-address": "10.0.1.43", "type": "service-function- type:napt44" } "service-function-forwarder": [ { "name": "SFF4", "sff-data-plane-locator": [ { "name": "eth0", "data-plane-locator": { "port": 4789, "ip": "10.0.1.44", "transport": "service- locator:vxlan-gpe" } } ], "rest-uri": "http://10.0.1.44:5000", "service-function-dictionary": [ { "name": "SF5", "type": "service-function- type:napt44", "sff-sf-data-plane-locator": { "port": 40001, "ip": "10.0.1.43", "transport": "service- locator:vxlan-gpe" } } ], "ip-mgmt-address": "10.0.1.43", }
- 21. SFC JSON Data "service-function-chain": [ { "name": "SFC2", "sfc-service-function": [ { "name": "firewall- abstract2", "type": "service-function- type:firewall", "order": 0 }, { "name": "napt44- abstract2", "type": "service-function- type:napt44", "order": 1 } ] } "service-function-path": [ { "name": "Path-2-SFC2", "service-chain-name": "SFC2", "symmetric": true }
- 22. "rendered-service-path": [ { "name": "Path-2-SFC2", "parent-service-function-path": "Path-2-SFC2", "path-id": 9, "service-chain-name": "SFC2", "starting-index": 255, "rendered-service-path-hop": [ { "hop-number": 0, "service-function-name": "SF4", "service-function-forwarder": "SFF3", "service_index": 255 }, { "hop-number": 1, "service-function-name": "SF5", "service-function-forwarder": "SFF4", "service_index": 254 } ] } Operational Data
- 23. https://github.com/opendaylight/sfc https://wiki.opendaylight.org/view/Service_Function_ Chaining:Main https://wiki.opnfv.org/service_function_chaining References
- 24. Thank you.
Editor's Notes
- #18: 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)