SDN Hub, profile picture
Uploaded bySDN Hub
PPTX, PDF34,991 views

OpenDaylight app development tutorial

This document serves as a tutorial for app development using OpenDaylight, emphasizing a model-driven approach with YANG modeling for state management. It discusses the architecture, including key components like data plane orchestration, southbound interfaces, and the handling of notifications and RPCs. The tutorial outlines new methodologies compared to previous versions, focusing on an integrated framework for building applications in a modular fashion with examples of code implementations.

Embed presentation

Downloaded 1,779 times
App Development Tutorial Srini Seetharaman srini.seetharaman@gmail.com August, 2015
2
OpenDaylight Consortium ► Heavy industry involvement and backing. ► Platinum and Gold members as of June 2016: ► Focused on having an open framework for building upon SDN/NFV innovations  Not limited to OpenFlow innovations, but in fact decoupled from it allowing the two to evolve independently 3
Other apps SDN Polytheism in OpenDaylight i.e., OpenDaylight embraces the full spectrum of choices 4 Data plane Orchestration Legacy control plane Data plane Orchestration Legacy control plane Controller Data plane Orchestration Applications Controller Risk NETCONF/YANG NETCONF/YANG, REST OpenFlow, P4OpenFlow, P4 Data plane Orchestration Controller OpenFlow, P4 NETCONF/YANG, REST Applications REST Legacy control plane OF Agent OF Agent OF Agent Purist-modelHybrid-model Solving only operational issue Backward-compatible
Lithium Release (June 2015) 5 Dlux UI Controller Platform Southbound Interfaces & Protocol Plugins OpenDaylight APIs (REST) Data Plane Elements (Virtual Switches, Physical Device Interfaces) VTN Coordinator Network Applications Orchestration & Services OpenStack Neutron OpenFlow Enabled Devices Devices with Proprietary control plane DDoS Protection OVSDB enabled devices Main difference from other OpenFlow-centric controller platforms SDNi Wrapper AAA – AuthN filter Base Network Service Functions Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …) OpenFlow 1.0 1.3 LISP Topology Mgr Stats Mgr Switch Mgr Host Tracker Flow Rules Mgr AAA LACP NETCONF BGPSNMP OVSDB PCEP GBP Service SFC TTP SNBI PCMM/ COPS OPFLEX GBP renderer OVSDB Neutron VTN Mgr Neutron Northbound L2 switch TSDR DOCSIS NIC Reservation TOPO ProcessingPersistenceVPN USC Manager LISP Service DIDM SDNI aggreg CAPWAP SXPHTTP ALTOUSCCoAP
Lithium: List of Projects (Total: 40) opflex* OpFlex protocol ovsdb OVSDB protocol and OpenStack integration packetcable PacketCable PCMM/COPS pss* Persistence Store Service plugin2oc Southbound plugin to the OpenContrail platform reservation* Dynamic Resource Reservation project sdninterfaceapp SDNi Cross-controller interface sfc Service Function Chaining snbi Secure Network Bootstrap Infrastructure snmp4sdn SNMP4SDN Plugin snmp* SNMP Southbound Plugin sxp* Source-Group Tag eXchange Protocol tcpmd5 TCP-MD5 Support library toolkit Quickstart Toolkit tpf* Topology Processing Framework tsdr* Time Series Data Repository ttp TTP Project usc* Unified Secure Channel vtn VTN (Virtual Tenant Network) yangtools YANG Tools Project keyword Description aaa AAA Project alto* Application-Layer Traffic Optimization bgpcep BGP/PCEP protocol library capwap* Control and Provisioning of Wireless Access Point controller OpenDaylight Controller defense4all Radware Defense4All didm* Device Identification and Drive Management discovery Discovery Service dlux OpenDaylight UI docs Documentation Project groupbasedpolicy Group Based Policy Plugin integration Integration Framework iotdm* IoT Data-centric Middleware l2switch Separate Layer 2 switching lacp* Link Aggregation Control Protocol lispflowmapping LISP Mapping Service nic* Network Intent Composition openflowjava OpenFlow Protocol Library openflowplugin OpenFlow Plugin *  New in Lithium release
What does it mean to program in ODL? 1. Get familiar with the Model-View-Control approach for app development in a modular fashion  YANG Model for data, RPC and notifications  RESTconf View generated automatically  Implementation in Java or Scala to handle data changes, notifications and RPC call backs 2. Get familiar with platform essentials (maven, config subsystem, dependencies) and useful tools 3. Learn about existing projects and reuse modules  No need to change code of other projects. Just link them as binary libraries 7 These are our goals for the hands-on part
What’s new in this tutorial? ► Old tutorials focused solely on:  OpenFlow based app development  API driven SAL that is similar in spirit to what ONOS uses  OSGi based activation ► New tutorial  Approaches app development from the perspective of YANG modeling since it is core to OpenDaylight  Model driven SAL (MD-SAL) for all state handling  Uses config subsystem for bundle activation 8
YANG modeling
YANG ► Data modeling language that is also the preferred configuration language for NETCONF protocol ► Further reads:  YANG introductory tutorial  RFC 6020 - YANG - A data modeling language for NETCONF module model1 { namespace "urn:model1"; prefix model1; yang-version 1; revision 2015-04-06 { description "Initial revision"; } grouping A { list B { key id; leaf id { type uint32; } leaf D { type uint32; } } } container C { uses A; } }
Module model1 Namespace “urn:model1” MD-SAL Data Access ► Model-driven SAL is the kernel of the OpenDaylight controller! ► It manages the contracts and state exchanges between every application. It does this adaptation by managing centralized state ► Takes in the YANG model at runtime and constructs the tree in the data store  For the YANG model in previous slide, here is the view of the root and its children 11 C B id=1 Leaf D Val=9 Leaf D Val=16 Leaf D Val=2 B id=2 B id=3 /restconf/config/model1:C /restconf/config/model1:C/B/3
MD-SAL Data Access (contd.) ► When the model is compiled with maven, you will see classes generated in Model1Data. java, B.java, and C.java ► InstanceIdentifier is used as a pointer to a child. Following points to the first child node in the figure ► ReadOnlyTransaction, and WriteTransaction are used to access the data store. ► Transaction can also be batched 12 InstanceIdentifier iid = InstanceIdentifier.builder(C.class) .child(B.class, new BKey((long)1)) .build(); B updatedB = new BBuilder().setD((long)19).build(); WriteTransaction modification = dataBroker.newWriteOnlyTransaction(); modification.merge(LogicalDataStoreType.CONFIGURATION, iid, updatedB, true); modification.submit();
YANG modeled data Store at the core 13 Karaf/OSGi App 2 Data model impl MD-SAL App 1 model data Possibly Policy, Possibly even Intents Devices or other external systems App1 Data model Impl 1 2 7 8 App 2 model data Class X Class Y 4 5 3 Config Subsystem RESTconf App 1 and 2 config data Config model 6 Config model Class Z JVM
Two types of data store ► For the same model, there are two types of data store maintained by MD-SAL  Config store: App developers typically use this to store user input and associated derived state for apps  Operational store: Typically used to keep transient ephemeral state ► Choice of store has implications on RESTconf and persistence  Config store is always kept persistent. There is control on how many replicas to keep  Operational store cannot be changed over RESTconf 14
YANG not restricted to Just Data Store ► Notifications:  Publish one or more notifications to registered listeners ► RPC:  Perform procedure call with input/output, without worrying about actual provider for that procedure 15
Using Notifications and RPCs ► Application developer usage for receiving notification and making RPC calls. ► Note: Whenever there is a change in the MD-SAL data store, you can receive a notification similar to the YANG defined notifications by implementing the DataChangeListener interface in a provider module 16 public class ConsumerImpl implements OpendaylightInventoryListener public ConsumerImpl(..) { notificationService.registerNotificationListener(this); this.salFlowService = rpcProviderRegistry.getRpcService(SalFlowService.class) } @Override public void onNodeUpdated(NodeUpdated nodeUpdated) { RemoveFlowInputBuilder flowBuilder = new RemoveFlowInputBuilder(); flowBuilder.setBarrier(true); flowBuilder.setNode(NodeUtils.createNodeRef(nodeUpdated.getId())); salFlowService.removeFlow(flowBuilder.build()); } }
Example of Learning Switch App (Uses Data + Notifications + RPC) 17
Poking into the basic platform
Java, Interface, Maven, OSGi, Karaf ► Java chosen as an enterprise-grade, cross-platform compatible language ► Java Interfaces are used for event listening, specifications and forming patterns ► Maven – build system for Java ► OSGi:  Allows dynamically loading bundles  Allows registering dependencies and services exported  For exchanging information across bundles ► Karaf: Light-weight Runtime for loading modules/bundles  OSGi based. Primary distribution mechanism for Helium 19 OSGi Framework (Equinox) Feature A SAL Feature B … Karaf
Running OpenDaylight Controller: Lithium release Typically we get started with the following $ wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/in tegration/distribution-karaf/0.3.0-Lithium/distribution-karaf-0.3.0- Lithium.zip $ unzip distribution-karaf-0.3.0-Lithium.zip $ cd distribution-karaf-0.3.0-Lithium $ ./bin/karaf opendaylight-user@root> feature:list (get all apps available) opendaylight-user@root> feature:install odl-dlux-core (install UI) opendaylight-user@root> feature:install odl-openflowplugin-all opendaylight-user@root> feature:install odl-l2switch-all opendaylight-user@root> bundle:list | grep Active Now your controller is ready to connect to switches and handle incoming flows. See UI at http://localhost:8181/index.html 20
REST APIs ► OpenDaylight has significant support for REST APIs ► Restconf allows for checking config and operational state  feature:install odl-restconf  http://localhost:8181/restconf/.... ► List of exposed Northbound APIs are autogenerated using swagger.  feature:install odl-mdsal-apidocs  http://localhost:8181/apidoc/explorer 21
ODL’s opendaylight-inventory.yang (Lithium) notification node-updated { status deprecated; leaf node-ref { type node-ref; } uses node; } notification node-connector-updated { status deprecated; leaf node-connector-ref { type node-connector-ref; } uses node-connector; } notification node-removed { status deprecated; leaf node-ref { type node-ref; } } notification node-connector-removed { status deprecated; leaf node-connector-ref { type node-connector-ref; } } } grouping node { leaf id { type node-id; } list "node-connector" { key "id"; uses node-connector; } } grouping node-connector { leaf id { type node-connector-id; } } container nodes { list node { key "id"; uses node; . . . } } module opendaylight-inventory { namespace "urn:opendaylight:inventory"; prefix inv; typedef node-id { type inet:uri; } typedef node-connector-id { type inet:uri; } typedef node-ref { type instance-identifier; } typedef node-connector-ref { type instance-identifier; } Augmentation made by OpenFlow plugin for storing: 1. All switch description 2. All OpenFlow features 3. All tables and its flows 4. All meters, groups 22
ODL’s Inventory Config Data Store http://localhost:8181/restconf/config/opendaylight-inventory:nodes 23
ODL’s network-topology.yang (Lithium) http://localhost:8181/restconf/operational/network-topology:network-topology 24 container network-topology { list topology { key "topology-id"; leaf topology-id { type inet:uri; } container topology-types { } list underlay-topology { key "topology-ref"; leaf topology-ref { type topology-ref; } } list node { key "node-id"; uses node-attributes; list termination-point { key "tp-id"; uses tp-attributes; } } list link { key "link-id"; uses link-attributes; } } } } grouping node-attributes { leaf node-id { type inet:uri; } list supporting-node { key "node-ref"; leaf node-ref { type node-ref; } } } grouping link-attributes { leaf link-id { type inet:uri; } container source { leaf source-node { mandatory true; type node-ref; } leaf source-tp { type tp-ref; } } container destination { leaf dest-node { mandatory true; type node-ref; } leaf dest-tp { type tp-ref; } } list supporting-link { key "link-ref"; leaf link-ref { type link-ref; } } } module network-topology { namespace "urn:TBD:params:xml:ns:yang:network-topology"; typedef topology-ref { type leafref { path "/network- topology/topology/inet:uri"; } } typedef node-ref { type leafref { path "/network- topology/topology/node/inet:uri"; } } typedef link-ref { type leafref { path "/network- topology/topology/link/inet:uri"; } } grouping tp-attributes { leaf tp-id { type inet:uri; } leaf-list tp-ref { type tp-ref; } }
Extension to models through Augments ► Unless specified otherwise, YANG models can be augmented in a new namespace to add extra data within an existing data model. ► For example, odl-l2-switch augments above inventory to store hosts learned 25 import opendaylight-inventory { prefix inv; revision-date 2013-08-19; } augment "/inv:nodes/inv:node/inv:node-connector" { ext:augment-identifier "address-capable-node-connector"; uses address-node-connector; } curl http://localhost:8080/restconf/operational/opendaylight- inventory:nodes/node/openflow:1/node-connector/openflow:1:1 { "node-connector": [ { "id": "openflow:1:1", "address-tracker:addresses": [ { "address-tracker:last-seen": 1404918398057, "address-tracker:ip": "10.0.0.1", "address-tracker:first-seen": 1404918392926, "address-tracker:mac": "f2:0c:dd:80:9f:f7" }] }] }
Code Design ► yangtools generates data model classes  Builders for generating immutable objects also generated  identity mapped to interfaces  All else are mapped to classes  Identity is the only one that allows inheritance ► Developers have to write the gateway adapters  Converting from one data model to another  Translating between a non-ODL source and ODL app https://wiki.opendaylight.org/view/YANG_Tools:YANG_to_Java_Mapping 26
Data Store Management ► Persistence  Everything that gets into a shard is stored in-memory and on the disk.  Restarting the controller will reconstitute the state of the shards from the persisted data. ► Clustering  Multiple controller instances can interwork and share state (for backup reasons rather than load-sharing)  One leader (writer) and multiple followers (read-only) where state consistency is achieved using RAFT algorithm ► Sharding  The big in-memory MD-SAL tree is broken up into a bunch of smaller sub-trees such that 1 model is 1 shard (e.g., inventory, topology and default). 27
Southbound Plugins: OpenFlow and NETCONF 28
OpenDaylight External Interfaces ► Southbound:  Built-in NETCONF client and BGP speaker to interact with legacy control planes and orchestrate them  Plugin for OpenFlow 1.0 and 1.3 support  Plugin for OVSDB that works with OVS schema (VTEP schema in future) ► Northbound:  REST and NETCONF for receiving intent data Controller platform OpenFlow OVSDB NETCONF BGP Network functions State mgmt App/ Logic Service intent and policy Device manager NETCONF REST Service models Device models
OpenFlow Southbound ► Programming a flow_mod  Make data transaction as an augmentation to ODL inventory ► Sending a packet_out  Craft packet data as modeled by YANG and make RPC call to transmit ► Receiving a packet_in  Register consumer for data receive notification ► Checking statistics and network changes  Check operational store of ODL inventory Your application OpenFlow Plugin OpenFlow Java Nicira Ext OF plugin Nicira Ext OF Java Datastore (1) (2) (3) Switch1 Switch2 Switch3
NETCONF Southbound To work with any NETCONF device, 1. Register device with netconf connector of ODL by providing the details of the netconf-enabled device IP, Username, Password, Port 2. Device supports ietf-netconf-monitoring? a) Yes - Controller automatically pulls in the device’s model b) No - Inject device’s model statically 3. ODL controller automatically mounts the netconf configs in the device to the controller data store. 4. The apps (both JVM apps and REST apps) are now ready to make read/write transaction to the device. 31
NETCONF based Multi-Vendor OSS August 2015 32 Orchestrator NETCONF Service models Device models OSS Engine CLI Models are vendor specific and still need vendor specific adapters in the orchestrator layer. This makes case for OpenConfig
Developing an App
Three main steps ► Step 1: Define the YANG model for the state ► Step 2: Activation using config subsystem  Each implementation has a YANG file defining its necessary MD-SAL dependencies and its namespace (See tapapp-impl.yang)  Each module has a config XML file that points to the implementation YANG file along with input to the config subsystem (See 50-tapapp-config.xml) ► Step 3: Implement the event handlers for all notifications and call backs  Provider: ► Module that is handles config data changes, receives RPC calls, or publishes notifications  Consumer: ► Module that makes RPC calls, listens to operational data changes, or listens to notifications
Example of Consumer ► Here is a consumer of OpenFlow inventory updates and flow programming 35 public class ConsumerImpl implements OpendaylightInventoryListener public ConsumerImpl(..) { notificationService.registerNotificationListener(this); this.salFlowService = rpcProviderRegistry.getRpcService(SalFlowService.class) } @Override public void onNodeUpdated(NodeUpdated nodeUpdated) { RemoveFlowInputBuilder flowBuilder = new RemoveFlowInputBuilder(); flowBuilder.setBarrier(true); flowBuilder.setNode(NodeUtils.createNodeRef(nodeUpdated.getId())); salFlowService.removeFlow(flowBuilder.build()); } }
► Since RPC calls typically use the thread of the caller, it is generally recommended to use executor threads to prevent blocking the caller thread. Example of Consumer (contd.) 36 private final ListeningExecutorService executor = MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(10)); @Override public void onNodeUpdated(NodeUpdated nodeUpdated) { final ListenableFuture<RpcResult<RemoveFlowOutput>> result = executor.submit( new Callable<RpcResult<RemoveFlowOutput>>() { public RpcResult<RemoveFlowOutput> call() { try { return salFlowService.removeFlow(flowBuilder.build()).get(); } catch (InterruptedException | ExecutionException e) { e.printStackTrace(); return null; } } }); Futures.addCallback(result, new FutureCallback<RpcResult<Void>>() { public void onSuccess(RpcResult<RemoveFlowOutput> result) { LOG.info(“Flow programming successful {}“, result.getResult()); } public void onFailure(Throwable error) { LOG.info(“Flow programming failed with error {}", error); }; }); } Submit Future to executor Register lean callbbacks
Example of a Provider ► Implement the auto-generated RPC interface and the datachangelistener 37 public class TutorialTapProvider implements AutoCloseable, DataChangeListener, TapService { public TutorialTapProvider(DataBroker dataBroker) { //Register data change listener dataBroker.registerDataChangeListener( LogicalDatastoreType.CONFIGURATION, rootIID, this, AsyncDataBroker.DataChangeScope.SUBTREE); //Register this class as RPC provider for create-tap call rpcProviderRegistry.addRpcImplementation(TapService.class, this); } @Override public void onDataChanged(AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> change) { // Iterate over any data changes ... } @Override public Future<RpcResult<CreateTapOutput>> createTap(CreateTapInput input) { // Parse the input and perform the tap creation operation ... } }
Let’s get familiar with SDN dev environment
Inside the Virtual Machine ► openvswitch: Virtual switch programmable using OpenFlow ► ovs-ofctl: Command-line utility for checking switch status and manually inserting flow entries.  Check supported commands in manual: $ man ovs-ofctl ► mininet: Network emulation platform  $sudo mn --topo single,3 --mac --switch ovsk --controller remote ► wireshark: Graphical tool for viewing packets with OF protocol plug-in  Start wireshark: $sudo wireshark  Start capture packets going through interface “lo” and Decode as OFP ► Multiple OpenFlow controllers with sample apps prepackaged  NOX, POX, Ryu, and OpenDayLight 39
Setup: Mininet-based topology 40 Controller port6633c0 OpenFlow Switch s1 ovs-ofctl (user space process) h3 10.0.0.3 h2 10.0.0.2 h1 10.0.0.1 virtual hosts loopback (127.0.0.1:6633) loopback (127.0.0.1:6634) s1-eth0 s1-eth1 s1-eth2 h1-eth0 h2-eth0 h3-eth0 Linux network namespaces veth pairs $ sudo mn --topo single,3 --mac --switch ovsk --controller remote 1-switch 3-hosts
ovs-vsctl and ovs-ofctl ► ovs-vsctl is used to check all the bridge configuration ► ovs-ofctl is used to check on the OpenFlow aspects and manage flows ► Before controller is started, execute the following # ovs-ofctl show s1 # ovs-ofctl dump-flows s1 mininet> h1 ping h2 # ovs-ofctl add-flow s1 in_port=1,actions=output:2 # ovs-ofctl add-flow s1 in_port=2,actions=output:1 # ovs-ofctl dump-flows s1 mininet> h1 ping h2 41 All ports of switch shown, but no flows installed. Ping fails because ARP cannot go through Ping works now!
For exercise 1 of programming OpenFlow rules using REST API opendaylight-user@root> feature:install odl-openflowplugin-all opendaylight-user@root> feature:install odl-restconf For exercise 2 of configuring NETCONF device opendaylight-user@root> feature:install odl-netconf-connector-all For enabling basic ping between mininet hosts using L2 Hub opendaylight-user@root> feature:install sdnhub-tutorial-learning-switch Running OpenDaylight Controller $ cd SDNHub_Opendaylight_Tutorial $ cd distribution/opendaylight-karaf/target/assembly/ $ ./bin/karaf clean opendaylight-user@root> feature:list (get all apps available) 42 sdnhub- tutorial -tapapp already installed Note: The tutorial project did not need all ODL libraries or source code
Running wireshark and Eclipse ► Wireshark helps investigate the OpenFlow messages exchanged between the switch and controller # wireshark & ► Eclipse is a popular IDE for developing Java applications. The VM already has Eclipse with maven integration $ eclipse & 43 Write code in Eclipse, but run Karaf with debug enabled in Linux terminal
Exercises: 1. Flow programming through REST API 2. Configure NETCONF devices from OpenDaylight 3. Writing a simple tap application that receives config through REST 4. Update learning switch application: a) Convert hub to switch b) MD-SAL transaction for MAC Table in learning switch 5. Combine tap and learning switch (Homework)
1. Flow Programming through REST ► It is possible to use RESTconf to send static flows to the controller. The REST input is based on the YANG model. For instance, post following 2 static flows. curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/opendaylight -inventory:nodes/node/openflow:1/flow-node- inventory:table/0/flow/Dummy_forward curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/opendaylight -inventory:nodes/node/openflow:1/flow-node- inventory:table/0/flow/Dummy_reverse <flow xmlns="urn:opendaylight:flow:inventory"> <id>Dummy_forward</id> <flow-name>Dummy_forward</flow-name> <table_id>0</table_id> <match> <in-port>1</in-port> </match> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>2</output-node-connector> </output-action> </action> </apply-actions> </instruction> </instructions> </flow> <flow xmlns="urn:opendaylight:flow:inventory"> <id>Dummy_reverse</id> <flow-name>Dummy_reverse</flow-name> <table_id>0</table_id> <match> <in-port>2</in-port> </match> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>
1. Flow Programming (contd.) ► Rules programmed on the switch leads to successful ping 46 $ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13 --controller remote mininet> h1 ping h2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. From 10.0.0.1 icmp_seq=1 Destination Host Unreachable From 10.0.0.1 icmp_seq=2 Destination Host Unreachable From 10.0.0.1 icmp_seq=3 Destination Host Unreachable From 10.0.0.1 icmp_seq=4 Destination Host Unreachable 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.409 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=0.070 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=0.099 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=0.127 ms --- 10.0.0.2 ping statistics --- 12 packets transmitted, 4 received, +8 errors, 66% packet loss, time 11078ms rtt min/avg/max/mdev = 0.070/0.176/0.409/0.136 ms, pipe 4 $ sudo ovs-ofctl dump-flows –OOpenFlow13 s1 OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=183.006s, table=0, n_packets=8, n_bytes=560, idle_timeout=300, hard_timeout=600, in_port=1 actions=output:2 cookie=0x0, duration=181.657s, table=0, n_packets=6, n_bytes=476, idle_timeout=300, hard_timeout=600, in_port=2 actions=output:1
2. NETCONF Exercise 47 router ospf 1 network 100.100.100.0 0.0.0.255 area 10 ! router bgp 1000 bgp router-id 10.10.1.1 neighbor 10.10.1.2 remote-as 2000 ! NETCONF-based orchestration <router xmlns="urn:sdnhub:odl:tutorial:router"> <ospf> <process-id>1</process-id> <networks> <subnet-ip>100.100.100.0/24</subnet-ip> <area-id>10</area-id> </networks> </ospf> <bgp> <as-number>1000</as-number> <router-id>10.10.1.1</router-id> <neighbors> <as-number>2000</as-number> <peer-ip>10.10.1.2</peer-ip> </neighbors> </bgp> </router>
2. NETCONF Exercise (contd.) - Demo Router YANG Model module router { yang-version 1; namespace "urn:sdnhub:odl:tutorial:router"; prefix router; description "Router configuration"; revision "2015-07-28" { description "Initial version."; } list interfaces { key id; leaf id { type string; } leaf ip-address { type string; } } container router { list ospf { key process-id; leaf process-id { type uint32; } list networks { key subnet-ip; leaf subnet-ip { type string; } leaf area-id { type uint32; } } } list bgp { key as-number; leaf as-number { type uint32; } leaf router-id { type string; } list neighbors { key as-number; leaf as-number { type uint32; } leaf peer-ip { type string; } } } } }
2. NETCONF Exercise (contd.) - Experimenting Using Netopeer Step 1: Spawn two emulated routers (i.e., netopeer server containers) $ cd SDNHub_Opendaylight_Tutorial/netconf-exercise $ ./spawn_router.sh router1 $ ./spawn_router.sh router2 Step 2: Register two netconf devices with OpenDaylight $ ./register_netconf_device.sh router1 172.17.0.1 $ ./register_netconf_device.sh router2 172.17.0.2 Step 3: Verify the two devices and its capabilities http://localhost:8181/restconf/operational/network- topology:network-topology/topology/topology-netconf/ August 2015 49
2. NETCONF Exercise (contd.) Step 4: Using RESTCONF, configure the two devices Step 5: Build an app that directly writes these configs to the datastore 50 curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/network- topology:network-topology/topology/topology- netconf/node/router1/yang-ext:mount/router:router <router xmlns="urn:sdnhub:odl:tutorial:router"> <ospf> <process-id>1</process-id> <networks> <subnet-ip>100.100.100.0/24</subnet-ip> <area-id>10</area-id> </networks> </ospf> <bgp> <as-number>1000</as-number> <router-id>10.10.1.1</router-id> <neighbors> <as-number>2000</as-number> <peer-ip>10.10.1.2</peer-ip> </neighbors> </bgp> </router> curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/network- topology:network-topology/topology/topology- netconf/node/router2/yang-ext:mount/router:router <router xmlns="urn:sdnhub:odl:tutorial:router"> <ospf> <process-id>1</process-id> <networks> <subnet-ip>100.100.200.0/24</subnet-ip> <area-id>10</area-id> </networks> </ospf> <bgp> <as-number>2000</as-number> <router-id>10.10.1.2</router-id> <neighbors> <as-number>1000</as-number> <peer-ip>10.10.1.1</peer-ip> </neighbors> </bgp> </router>
3. Tutorial Project Structure 51 TapApp Learning switch OpenFlow plugin Optional: Reuse Host Tracker MD-SAL DS Data plane TODO: Read/Write transaction from learning-switch { “node": [{ "id": 'openflow:2', "hosts": { "mac-addrress": 00:00:00:00:00:02, “attachment-point": 'openflow:2:2' } ]}} FLOW_MOD PACKET_IN/PACKET_OUT TODO: Process user tap config through RESTconf { "tap": [{ "id": "1", "node": "openflow:1", "sink-node-connector": [ "openflow:1:2" ], "src-node-connector": [ "openflow:1:1" ], "traffic-match": "HTTP" }] }
3. Tap Application ► Network traffic tap is an application that filters certain traffic coming from a source and sends it to a sink, based on proactively programmed OpenFlow rules ► Step 1: Build the data model… 52 typedef field-type { type enumeration { enum source; enum destination; enum both; } } typedef traffic-type { type enumeration { enum ARP; enum DNS; enum HTTP; enum HTTPS; enum TCP; enum UDP; enum DHCP; enum ICMP; } } container tap-spec { list tap { key "id"; leaf id { type string; } uses tap-grouping; } } grouping tap-grouping { leaf node { mandatory true; type leafref { path "/inv:nodes/inv:node/inv:id"; } } leaf-list src-node-connector { min-elements 1; type leafref { path "/inv:nodes/inv:node/inv:node-connector/inv:id"; } } leaf-list sink-node-connector { min-elements 1; type leafref { path "/inv:nodes/inv:node/inv:node-connector/inv:id"; } } container mac-address-match { leaf type { type field-type; } leaf value { type yang:mac-address; } } container ip-address-match { leaf type { type field-type; } leaf value { type inet:ipv4-prefix; } } leaf traffic-match { type traffic-type; } }
3. Tap Application (contd.) ► Step 2: Activation using config subsystem ► Step 3: Add event handler for data change to process any new tap config 53 public class TutorialTapProvider implements AutoCloseable, DataChangeListener { public TutorialTapProvider(DataBroker dataBroker) { //TODO 1: Register data change listener } @Override public void onDataChanged(AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> change) { // Iterate over any created nodes or interfaces for (Map.Entry<InstanceIdentifier<?>, DataObject> entry : change.getCreatedData().entrySet()) { DataObject dataObject = entry.getValue(); if (dataObject instanceof Tap) { //TODO 2: If tap configuration added, call programTap() } } // Iterate over any deleted nodes or interfaces Map<InstanceIdentifier<?>, DataObject> originalData = change.getOriginalData(); for (InstanceIdentifier<?> path : change.getRemovedPaths()) { DataObject dataObject = originalData.get(path); if (dataObject instanceof Tap) { //TODO 3: If tap configuration deleted, call removeTap() } } }
3. Tap Application (contd.) ► The goal of the tap provider application is to translate data from user input tap config to OpenFlowPlugin data ► OpenFlowPlugin in turn uses that data to program rules 54 { "id":"Tap_1SrcPort_openflow:1:1", "instructions":{ "instruction":[ { "apply-actions":{ "action":[ { "order":0, "output-action":{ "max-length":65535, "output-node-connector":"openflow:1:2" } } ] }, "order":0 } ] }, "match":{ "ethernet-match":{ "ethernet-type":{ "type":2048 } }, "in-port":"openflow:1:1", "ip-match":{ "ip-protocol":6 }, "tcp-destination-port":80 }, "table_id":0 } { "tap": [{ "id": "1", "node": "openflow:1", "sink-node-connector": [ "openflow:1:2" ], "src-node-connector": [ "openflow:1:1" ], "traffic-match": "HTTP" }] }
4a. Learning Switch ► The code in the VM handles “hub” implementation of the learning-switch  Any received packet-in is received through the PacketProcessingListener. onPacketReceived YANG Notification  Controller, then, performs a packet-out of this packet to all ports through a RPC call to PacketProcessingService.transmitPacket ► Your first task is to convert the code to build a learning switch that: 1. tracks where each MAC address is located. i.e., create a MAC table like follows: Map<String, NodeConnectorId> macTable = new HashMap <String, NodeConnectorId>(); 2. Insert flow rules to switch traffic based on the destination MAC address 55
4b. MAC Table of Learning Switch ► In code, you will see the Map data structure called macTable Map<String, NodeConnectorId> macTable = new HashMap <String, NodeConnectorId>(); ► Your second task:  Instead of using local data, store it in MD-SAL using GenericTransactionUtils.writeData() provided ► This will require writing a augmentation YANG model for defining a place to store it. I choose to store it within the opendaylight-inventory tree  Whenever lookup is performed, look into MD-SAL store using GenericTransactionUtils.readData() that is provided 56 augment /odl-inv:nodes/odl-inv:node { ext:augment-identifier "MacTable"; list hosts { leaf mac-address { type yang:mac-address; } leaf attachment-point { //I choose simple one type inet:uri; } } }
Coding time. Welcome to OpenDaylight programming! 57 http://sdnhub.org/tutorials/opendaylight

More Related Content

PPTX
Apache NiFi in the Hadoop Ecosystem
byDataWorks Summit/Hadoop Summit
 
PDF
Introduction to OpenDaylight & Application Development
byMichelle Holley
 
PDF
Tutorial on SDN and OpenFlow
byKingston Smiler
 
PDF
Server monitoring using grafana and prometheus
byCeline George
 
PPTX
12 factor app
byDmytro Panin
 
ODP
Openshift Container Platform
byDLT Solutions
 
PDF
Large scale overlay networks with ovn: problems and solutions
byHan Zhou
 
PDF
Cloud Monitoring tool Grafana
byDhrubaji Mandal ♛
 
Apache NiFi in the Hadoop Ecosystem
byDataWorks Summit/Hadoop Summit
 
Introduction to OpenDaylight & Application Development
byMichelle Holley
 
Tutorial on SDN and OpenFlow
byKingston Smiler
 
Server monitoring using grafana and prometheus
byCeline George
 
12 factor app
byDmytro Panin
 
Openshift Container Platform
byDLT Solutions
 
Large scale overlay networks with ovn: problems and solutions
byHan Zhou
 
Cloud Monitoring tool Grafana
byDhrubaji Mandal ♛
 

What's hot

PPT
OpenFlow tutorial
byopenflow
 
PPTX
Infrastructure as Code Presentation v5.pptx
byYASHSRIVASTAVA811639
 
PDF
Mininet Basics
byEueung Mulyana
 
PPTX
Meetup 23 - 02 - OVN - The future of networking in OpenStack
byVietnam Open Infrastructure User Group
 
PDF
Introduction to OpenStack
byEdureka!
 
PDF
Kubernetes Networking
byCJ Cullen
 
PDF
APIsecure 2023 - API orchestration: to build resilient applications, Cherish ...
byapidays
 
PPTX
Introduction to SDN: Software Defined Networking
byAnkita Mahajan
 
PPTX
Introducing OpenAPI Version 3.1
bySmartBear
 
PDF
apidays Paris 2022 - API design best practices, Ryan Clifford & Ros Bennis, F...
byapidays
 
PDF
Yang in OpenDaylight
byGunjan Patel
 
PDF
Open shift 4-update
bySaeidVarmazyar
 
PPTX
Opendaylight SDN Controller
bySumit Arora
 
PPTX
Splunk Overview
bySplunk
 
ODP
Kvm and libvirt
byplarsen67
 
PDF
Dataflow with Apache NiFi
byDataWorks Summit/Hadoop Summit
 
PDF
Real time stock processing with apache nifi, apache flink and apache kafka
byTimothy Spann
 
PPTX
OpenvSwitch Deep Dive
byrajdeep
 
PPTX
An Introduction to Confluent Cloud: Apache Kafka as a Service
byconfluent
 
PDF
Flutter Tutorial For Beginners | Edureka
byEdureka!
 
OpenFlow tutorial
byopenflow
 
Infrastructure as Code Presentation v5.pptx
byYASHSRIVASTAVA811639
 
Mininet Basics
byEueung Mulyana
 
Meetup 23 - 02 - OVN - The future of networking in OpenStack
byVietnam Open Infrastructure User Group
 
Introduction to OpenStack
byEdureka!
 
Kubernetes Networking
byCJ Cullen
 
APIsecure 2023 - API orchestration: to build resilient applications, Cherish ...
byapidays
 
Introduction to SDN: Software Defined Networking
byAnkita Mahajan
 
Introducing OpenAPI Version 3.1
bySmartBear
 
apidays Paris 2022 - API design best practices, Ryan Clifford & Ros Bennis, F...
byapidays
 
Yang in OpenDaylight
byGunjan Patel
 
Open shift 4-update
bySaeidVarmazyar
 
Opendaylight SDN Controller
bySumit Arora
 
Splunk Overview
bySplunk
 
Kvm and libvirt
byplarsen67
 
Dataflow with Apache NiFi
byDataWorks Summit/Hadoop Summit
 
Real time stock processing with apache nifi, apache flink and apache kafka
byTimothy Spann
 
OpenvSwitch Deep Dive
byrajdeep
 
An Introduction to Confluent Cloud: Apache Kafka as a Service
byconfluent
 
Flutter Tutorial For Beginners | Edureka
byEdureka!
 

Viewers also liked

PPTX
Management of medical emergencies in the dental practice
byKanika Manral
 
PDF
Diesel Product Development
byKaterina K.azia
 
PPTX
BUSINESS QUIZ -Round 1
bypradeep acharya
 
PDF
Web Trends to Watch in 2014
byDavid King
 
PDF
Environmental Impact Assessment (EIA) report on Rampal 1320MW coal-based powe...
byProbir Bidhan
 
PDF
10 Digital Hacks Every Marketer Should Know
byMark Fidelman
 
PPTX
PPT On Bridge Construction
byRobin Nirwal
 
PDF
Tweak Your Resume
byChiara Ojeda
 
PDF
5000 Sat Words With Definitions
byBrent Daigle, Ph.D.
 
PPT
The NEW Way to Win Friends & Influence People (social media in events)
byLara McCulloch-Carter
 
PDF
Principles and Practices in Continuous Deployment at Etsy
byMike Brittain
 
PDF
Thai tech startup ecosystem report 2017
byTechsauce Media
 
PDF
La casbah d'Alger
byMebarka Fekih
 
PPTX
Size exclusion chromatography
byMandvi Shandilya
 
PDF
Deep Learning through Examples
bySri Ambati
 
PPTX
Introduction to strategic management
byCentre for Social Initiative and Management
 
PPTX
4. heredity and evolution
byAbhay Goyal
 
PPTX
DepEd Order No. 47 s. 2014: CONSTITUTION AND BY - LAWS OF THE SUPREME PUPIL G...
byJared Ram Juezan
 
PPT
Gear Cutting Presentation for Polytechnic College Students of India
bykichu
 
PPTX
CES 2016 Recap: The Autonomous 4K VR 3D IoT Drone Awakens
byDavid Berkowitz
 
Management of medical emergencies in the dental practice
byKanika Manral
 
Diesel Product Development
byKaterina K.azia
 
BUSINESS QUIZ -Round 1
bypradeep acharya
 
Web Trends to Watch in 2014
byDavid King
 
Environmental Impact Assessment (EIA) report on Rampal 1320MW coal-based powe...
byProbir Bidhan
 
10 Digital Hacks Every Marketer Should Know
byMark Fidelman
 
PPT On Bridge Construction
byRobin Nirwal
 
Tweak Your Resume
byChiara Ojeda
 
5000 Sat Words With Definitions
byBrent Daigle, Ph.D.
 
The NEW Way to Win Friends & Influence People (social media in events)
byLara McCulloch-Carter
 
Principles and Practices in Continuous Deployment at Etsy
byMike Brittain
 
Thai tech startup ecosystem report 2017
byTechsauce Media
 
La casbah d'Alger
byMebarka Fekih
 
Size exclusion chromatography
byMandvi Shandilya
 
Deep Learning through Examples
bySri Ambati
 
Introduction to strategic management
byCentre for Social Initiative and Management
 
4. heredity and evolution
byAbhay Goyal
 
DepEd Order No. 47 s. 2014: CONSTITUTION AND BY - LAWS OF THE SUPREME PUPIL G...
byJared Ram Juezan
 
Gear Cutting Presentation for Polytechnic College Students of India
bykichu
 
CES 2016 Recap: The Autonomous 4K VR 3D IoT Drone Awakens
byDavid Berkowitz
 

Similar to OpenDaylight app development tutorial

PDF
Opendaylight overview
byPrateek Baharani
 
PDF
PLNOG15: The Power of the Open Standards SDN API’s - Mikael Holmberg
byPROIDEA
 
PDF
Current & Future Use-Cases of OpenDaylight
byabhijit2511
 
PPTX
DEVNET-1166 Open SDN Controller APIs
byCisco DevNet
 
PPTX
Introduction to the Helium release of OpenDaylight
bySDN Hub
 
PPTX
OpenDaylight and YANG
byCoreStack
 
PDF
Open Dayligth usando SDN-NFV
byOpen Networking Perú (Opennetsoft)
 
PDF
OpenDaylight SDN Controller - Introduction
byEueung Mulyana
 
PPTX
Collaborating with OpenDaylight for a Network-Enabled Cloud
byTesora
 
PDF
Software Defined Networking: The OpenDaylight Project
byGreat Wide Open
 
PPTX
DEVNET-1175 OpenDaylight Service Function Chaining
byCisco DevNet
 
PPT
Introduction to OpenDaylight and Hydrogen, Learnings from the Year, What's Ne...
byDavid Meyer
 
PPT
OpenDaylight nluug_november
byChristopher Price
 
PDF
Making Strongly-typed NETCONF Usable
byOpen Networking Summit
 
PPTX
Basavaraj H - Open Day light.pptx for sdn
bykovegam542
 
PDF
OpenConfig: collaborating to enable programmable network management
byAnees Shaikh
 
PDF
Augmenting Flow Operations and Feedback on the Model Driven MD_SAL Approach i...
byBrent Salisbury
 
PPTX
DEVNET-2005 Using the Cisco Open SDN Controller RESTCONF APIs
byCisco DevNet
 
PDF
State of the OpenDaylight Union
byOpen Networking Summit
 
PPTX
OpenDayLight (ODL) Project
byVahid Sadri
 
Opendaylight overview
byPrateek Baharani
 
PLNOG15: The Power of the Open Standards SDN API’s - Mikael Holmberg
byPROIDEA
 
Current & Future Use-Cases of OpenDaylight
byabhijit2511
 
DEVNET-1166 Open SDN Controller APIs
byCisco DevNet
 
Introduction to the Helium release of OpenDaylight
bySDN Hub
 
OpenDaylight and YANG
byCoreStack
 
Open Dayligth usando SDN-NFV
byOpen Networking Perú (Opennetsoft)
 
OpenDaylight SDN Controller - Introduction
byEueung Mulyana
 
Collaborating with OpenDaylight for a Network-Enabled Cloud
byTesora
 
Software Defined Networking: The OpenDaylight Project
byGreat Wide Open
 
DEVNET-1175 OpenDaylight Service Function Chaining
byCisco DevNet
 
Introduction to OpenDaylight and Hydrogen, Learnings from the Year, What's Ne...
byDavid Meyer
 
OpenDaylight nluug_november
byChristopher Price
 
Making Strongly-typed NETCONF Usable
byOpen Networking Summit
 
Basavaraj H - Open Day light.pptx for sdn
bykovegam542
 
OpenConfig: collaborating to enable programmable network management
byAnees Shaikh
 
Augmenting Flow Operations and Feedback on the Model Driven MD_SAL Approach i...
byBrent Salisbury
 
DEVNET-2005 Using the Cisco Open SDN Controller RESTCONF APIs
byCisco DevNet
 
State of the OpenDaylight Union
byOpen Networking Summit
 
OpenDayLight (ODL) Project
byVahid Sadri
 

Recently uploaded

PDF
Agentic AI Roadmap 2026: Mastering Autonomous AI Workflows and Systems
byAeafat Ahmed Mubin
 
PDF
Real-Time AI at Scale Masterclass: Feature Store at Scale
byScyllaDB
 
PDF
Certified AI-Empowered SAFe Release Train Engineer.pdf
byMarc Entsminger SPC6, RTE, SSM, SA, SDP
 
PPTX
Jisc Equipment Data Service Update Workshop 3 December 2025
byJisc
 
PDF
Real-Time AI at Scale Masterclass - Challenges of AI at Scale
byScyllaDB
 
PPTX
INSY_7213_Theme Sessions 47 & 48 Advanced databases.pptx
bystormzy56
 
PDF
Adapt.com Seed Fundraising Deck | The AI Computer for Business
byashley459565
 
PDF
How PayPal Account Verification Works – Complete Guide for Online Businesses
byjhdhj3989
 
PDF
Taxonomy Alignment for SDG Tagging - ASHA Case Study
byEnterprise Knowledge
 
PPTX
6G and Non-Terrestrial Networks (NTN) Testing.pptx
byXRComm
 
PDF
Quick Learn Laravel for Beginner from Zero to Survive
byiDev Semarang
 
PPTX
TechSprint WinterHack — Top 10 Teams Pitching Session we are excited for pit...
bybajpaitusharoffon678
 
PDF
Real-Time AI Masterclass: Vector Search at Scale
byScyllaDB
 
PPTX
The Lex Wire Precedent: A Technical Standard for Machine-Mediated Authority ...
byJeff Howell
 
PDF
Web3 - Applications and Architectures - History and Horizons
byGokul Alex
 
PDF
React Mastery: Visual Mental Models to Understand React Deeply
byThomas Gaye
 
PDF
"When every team does things "right", but together it turns into chaos", Yozh...
byFwdays
 
PDF
What Thema can do: Leveraging metadata to support the discoverability of Firs...
byBookNet Canada
 
PDF
Enterprise Data Services_ A Development Guide with Use Cases, Trends and Impl...
by2601harsh23
 
PDF
Bettersize | BeSEC Series Product Brochure
byBettersize Instruments
 
Agentic AI Roadmap 2026: Mastering Autonomous AI Workflows and Systems
byAeafat Ahmed Mubin
 
Real-Time AI at Scale Masterclass: Feature Store at Scale
byScyllaDB
 
Certified AI-Empowered SAFe Release Train Engineer.pdf
byMarc Entsminger SPC6, RTE, SSM, SA, SDP
 
Jisc Equipment Data Service Update Workshop 3 December 2025
byJisc
 
Real-Time AI at Scale Masterclass - Challenges of AI at Scale
byScyllaDB
 
INSY_7213_Theme Sessions 47 & 48 Advanced databases.pptx
bystormzy56
 
Adapt.com Seed Fundraising Deck | The AI Computer for Business
byashley459565
 
How PayPal Account Verification Works – Complete Guide for Online Businesses
byjhdhj3989
 
Taxonomy Alignment for SDG Tagging - ASHA Case Study
byEnterprise Knowledge
 
6G and Non-Terrestrial Networks (NTN) Testing.pptx
byXRComm
 
Quick Learn Laravel for Beginner from Zero to Survive
byiDev Semarang
 
TechSprint WinterHack — Top 10 Teams Pitching Session we are excited for pit...
bybajpaitusharoffon678
 
Real-Time AI Masterclass: Vector Search at Scale
byScyllaDB
 
The Lex Wire Precedent: A Technical Standard for Machine-Mediated Authority ...
byJeff Howell
 
Web3 - Applications and Architectures - History and Horizons
byGokul Alex
 
React Mastery: Visual Mental Models to Understand React Deeply
byThomas Gaye
 
"When every team does things "right", but together it turns into chaos", Yozh...
byFwdays
 
What Thema can do: Leveraging metadata to support the discoverability of Firs...
byBookNet Canada
 
Enterprise Data Services_ A Development Guide with Use Cases, Trends and Impl...
by2601harsh23
 
Bettersize | BeSEC Series Product Brochure
byBettersize Instruments
 

OpenDaylight app development tutorial

  • 1.
    App Development Tutorial SriniSeetharaman srini.seetharaman@gmail.com August, 2015
  • 2.
  • 3.
    OpenDaylight Consortium ► Heavyindustry involvement and backing. ► Platinum and Gold members as of June 2016: ► Focused on having an open framework for building upon SDN/NFV innovations  Not limited to OpenFlow innovations, but in fact decoupled from it allowing the two to evolve independently 3
  • 4.
    Other apps SDN Polytheism inOpenDaylight i.e., OpenDaylight embraces the full spectrum of choices 4 Data plane Orchestration Legacy control plane Data plane Orchestration Legacy control plane Controller Data plane Orchestration Applications Controller Risk NETCONF/YANG NETCONF/YANG, REST OpenFlow, P4OpenFlow, P4 Data plane Orchestration Controller OpenFlow, P4 NETCONF/YANG, REST Applications REST Legacy control plane OF Agent OF Agent OF Agent Purist-modelHybrid-model Solving only operational issue Backward-compatible
  • 5.
    Lithium Release (June2015) 5 Dlux UI Controller Platform Southbound Interfaces & Protocol Plugins OpenDaylight APIs (REST) Data Plane Elements (Virtual Switches, Physical Device Interfaces) VTN Coordinator Network Applications Orchestration & Services OpenStack Neutron OpenFlow Enabled Devices Devices with Proprietary control plane DDoS Protection OVSDB enabled devices Main difference from other OpenFlow-centric controller platforms SDNi Wrapper AAA – AuthN filter Base Network Service Functions Service Abstraction Layer (SAL) (plug-in mgr., capability abstractions, flow programming, inventory, …) OpenFlow 1.0 1.3 LISP Topology Mgr Stats Mgr Switch Mgr Host Tracker Flow Rules Mgr AAA LACP NETCONF BGPSNMP OVSDB PCEP GBP Service SFC TTP SNBI PCMM/ COPS OPFLEX GBP renderer OVSDB Neutron VTN Mgr Neutron Northbound L2 switch TSDR DOCSIS NIC Reservation TOPO ProcessingPersistenceVPN USC Manager LISP Service DIDM SDNI aggreg CAPWAP SXPHTTP ALTOUSCCoAP
  • 6.
    Lithium: List ofProjects (Total: 40) opflex* OpFlex protocol ovsdb OVSDB protocol and OpenStack integration packetcable PacketCable PCMM/COPS pss* Persistence Store Service plugin2oc Southbound plugin to the OpenContrail platform reservation* Dynamic Resource Reservation project sdninterfaceapp SDNi Cross-controller interface sfc Service Function Chaining snbi Secure Network Bootstrap Infrastructure snmp4sdn SNMP4SDN Plugin snmp* SNMP Southbound Plugin sxp* Source-Group Tag eXchange Protocol tcpmd5 TCP-MD5 Support library toolkit Quickstart Toolkit tpf* Topology Processing Framework tsdr* Time Series Data Repository ttp TTP Project usc* Unified Secure Channel vtn VTN (Virtual Tenant Network) yangtools YANG Tools Project keyword Description aaa AAA Project alto* Application-Layer Traffic Optimization bgpcep BGP/PCEP protocol library capwap* Control and Provisioning of Wireless Access Point controller OpenDaylight Controller defense4all Radware Defense4All didm* Device Identification and Drive Management discovery Discovery Service dlux OpenDaylight UI docs Documentation Project groupbasedpolicy Group Based Policy Plugin integration Integration Framework iotdm* IoT Data-centric Middleware l2switch Separate Layer 2 switching lacp* Link Aggregation Control Protocol lispflowmapping LISP Mapping Service nic* Network Intent Composition openflowjava OpenFlow Protocol Library openflowplugin OpenFlow Plugin *  New in Lithium release
  • 7.
    What does itmean to program in ODL? 1. Get familiar with the Model-View-Control approach for app development in a modular fashion  YANG Model for data, RPC and notifications  RESTconf View generated automatically  Implementation in Java or Scala to handle data changes, notifications and RPC call backs 2. Get familiar with platform essentials (maven, config subsystem, dependencies) and useful tools 3. Learn about existing projects and reuse modules  No need to change code of other projects. Just link them as binary libraries 7 These are our goals for the hands-on part
  • 8.
    What’s new inthis tutorial? ► Old tutorials focused solely on:  OpenFlow based app development  API driven SAL that is similar in spirit to what ONOS uses  OSGi based activation ► New tutorial  Approaches app development from the perspective of YANG modeling since it is core to OpenDaylight  Model driven SAL (MD-SAL) for all state handling  Uses config subsystem for bundle activation 8
  • 9.
  • 10.
    YANG ► Data modelinglanguage that is also the preferred configuration language for NETCONF protocol ► Further reads:  YANG introductory tutorial  RFC 6020 - YANG - A data modeling language for NETCONF module model1 { namespace "urn:model1"; prefix model1; yang-version 1; revision 2015-04-06 { description "Initial revision"; } grouping A { list B { key id; leaf id { type uint32; } leaf D { type uint32; } } } container C { uses A; } }
  • 11.
    Module model1 Namespace “urn:model1” MD-SALData Access ► Model-driven SAL is the kernel of the OpenDaylight controller! ► It manages the contracts and state exchanges between every application. It does this adaptation by managing centralized state ► Takes in the YANG model at runtime and constructs the tree in the data store  For the YANG model in previous slide, here is the view of the root and its children 11 C B id=1 Leaf D Val=9 Leaf D Val=16 Leaf D Val=2 B id=2 B id=3 /restconf/config/model1:C /restconf/config/model1:C/B/3
  • 12.
    MD-SAL Data Access(contd.) ► When the model is compiled with maven, you will see classes generated in Model1Data. java, B.java, and C.java ► InstanceIdentifier is used as a pointer to a child. Following points to the first child node in the figure ► ReadOnlyTransaction, and WriteTransaction are used to access the data store. ► Transaction can also be batched 12 InstanceIdentifier iid = InstanceIdentifier.builder(C.class) .child(B.class, new BKey((long)1)) .build(); B updatedB = new BBuilder().setD((long)19).build(); WriteTransaction modification = dataBroker.newWriteOnlyTransaction(); modification.merge(LogicalDataStoreType.CONFIGURATION, iid, updatedB, true); modification.submit();
  • 13.
    YANG modeled dataStore at the core 13 Karaf/OSGi App 2 Data model impl MD-SAL App 1 model data Possibly Policy, Possibly even Intents Devices or other external systems App1 Data model Impl 1 2 7 8 App 2 model data Class X Class Y 4 5 3 Config Subsystem RESTconf App 1 and 2 config data Config model 6 Config model Class Z JVM
  • 14.
    Two types ofdata store ► For the same model, there are two types of data store maintained by MD-SAL  Config store: App developers typically use this to store user input and associated derived state for apps  Operational store: Typically used to keep transient ephemeral state ► Choice of store has implications on RESTconf and persistence  Config store is always kept persistent. There is control on how many replicas to keep  Operational store cannot be changed over RESTconf 14
  • 15.
    YANG not restrictedto Just Data Store ► Notifications:  Publish one or more notifications to registered listeners ► RPC:  Perform procedure call with input/output, without worrying about actual provider for that procedure 15
  • 16.
    Using Notifications andRPCs ► Application developer usage for receiving notification and making RPC calls. ► Note: Whenever there is a change in the MD-SAL data store, you can receive a notification similar to the YANG defined notifications by implementing the DataChangeListener interface in a provider module 16 public class ConsumerImpl implements OpendaylightInventoryListener public ConsumerImpl(..) { notificationService.registerNotificationListener(this); this.salFlowService = rpcProviderRegistry.getRpcService(SalFlowService.class) } @Override public void onNodeUpdated(NodeUpdated nodeUpdated) { RemoveFlowInputBuilder flowBuilder = new RemoveFlowInputBuilder(); flowBuilder.setBarrier(true); flowBuilder.setNode(NodeUtils.createNodeRef(nodeUpdated.getId())); salFlowService.removeFlow(flowBuilder.build()); } }
  • 17.
    Example of LearningSwitch App (Uses Data + Notifications + RPC) 17
  • 18.
    Poking into thebasic platform
  • 19.
    Java, Interface, Maven,OSGi, Karaf ► Java chosen as an enterprise-grade, cross-platform compatible language ► Java Interfaces are used for event listening, specifications and forming patterns ► Maven – build system for Java ► OSGi:  Allows dynamically loading bundles  Allows registering dependencies and services exported  For exchanging information across bundles ► Karaf: Light-weight Runtime for loading modules/bundles  OSGi based. Primary distribution mechanism for Helium 19 OSGi Framework (Equinox) Feature A SAL Feature B … Karaf
  • 20.
    Running OpenDaylight Controller:Lithium release Typically we get started with the following $ wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/in tegration/distribution-karaf/0.3.0-Lithium/distribution-karaf-0.3.0- Lithium.zip $ unzip distribution-karaf-0.3.0-Lithium.zip $ cd distribution-karaf-0.3.0-Lithium $ ./bin/karaf opendaylight-user@root> feature:list (get all apps available) opendaylight-user@root> feature:install odl-dlux-core (install UI) opendaylight-user@root> feature:install odl-openflowplugin-all opendaylight-user@root> feature:install odl-l2switch-all opendaylight-user@root> bundle:list | grep Active Now your controller is ready to connect to switches and handle incoming flows. See UI at http://localhost:8181/index.html 20
  • 21.
    REST APIs ► OpenDaylighthas significant support for REST APIs ► Restconf allows for checking config and operational state  feature:install odl-restconf  http://localhost:8181/restconf/.... ► List of exposed Northbound APIs are autogenerated using swagger.  feature:install odl-mdsal-apidocs  http://localhost:8181/apidoc/explorer 21
  • 22.
    ODL’s opendaylight-inventory.yang (Lithium) notificationnode-updated { status deprecated; leaf node-ref { type node-ref; } uses node; } notification node-connector-updated { status deprecated; leaf node-connector-ref { type node-connector-ref; } uses node-connector; } notification node-removed { status deprecated; leaf node-ref { type node-ref; } } notification node-connector-removed { status deprecated; leaf node-connector-ref { type node-connector-ref; } } } grouping node { leaf id { type node-id; } list "node-connector" { key "id"; uses node-connector; } } grouping node-connector { leaf id { type node-connector-id; } } container nodes { list node { key "id"; uses node; . . . } } module opendaylight-inventory { namespace "urn:opendaylight:inventory"; prefix inv; typedef node-id { type inet:uri; } typedef node-connector-id { type inet:uri; } typedef node-ref { type instance-identifier; } typedef node-connector-ref { type instance-identifier; } Augmentation made by OpenFlow plugin for storing: 1. All switch description 2. All OpenFlow features 3. All tables and its flows 4. All meters, groups 22
  • 23.
    ODL’s Inventory ConfigData Store http://localhost:8181/restconf/config/opendaylight-inventory:nodes 23
  • 24.
    ODL’s network-topology.yang (Lithium) http://localhost:8181/restconf/operational/network-topology:network-topology 24 containernetwork-topology { list topology { key "topology-id"; leaf topology-id { type inet:uri; } container topology-types { } list underlay-topology { key "topology-ref"; leaf topology-ref { type topology-ref; } } list node { key "node-id"; uses node-attributes; list termination-point { key "tp-id"; uses tp-attributes; } } list link { key "link-id"; uses link-attributes; } } } } grouping node-attributes { leaf node-id { type inet:uri; } list supporting-node { key "node-ref"; leaf node-ref { type node-ref; } } } grouping link-attributes { leaf link-id { type inet:uri; } container source { leaf source-node { mandatory true; type node-ref; } leaf source-tp { type tp-ref; } } container destination { leaf dest-node { mandatory true; type node-ref; } leaf dest-tp { type tp-ref; } } list supporting-link { key "link-ref"; leaf link-ref { type link-ref; } } } module network-topology { namespace "urn:TBD:params:xml:ns:yang:network-topology"; typedef topology-ref { type leafref { path "/network- topology/topology/inet:uri"; } } typedef node-ref { type leafref { path "/network- topology/topology/node/inet:uri"; } } typedef link-ref { type leafref { path "/network- topology/topology/link/inet:uri"; } } grouping tp-attributes { leaf tp-id { type inet:uri; } leaf-list tp-ref { type tp-ref; } }
  • 25.
    Extension to modelsthrough Augments ► Unless specified otherwise, YANG models can be augmented in a new namespace to add extra data within an existing data model. ► For example, odl-l2-switch augments above inventory to store hosts learned 25 import opendaylight-inventory { prefix inv; revision-date 2013-08-19; } augment "/inv:nodes/inv:node/inv:node-connector" { ext:augment-identifier "address-capable-node-connector"; uses address-node-connector; } curl http://localhost:8080/restconf/operational/opendaylight- inventory:nodes/node/openflow:1/node-connector/openflow:1:1 { "node-connector": [ { "id": "openflow:1:1", "address-tracker:addresses": [ { "address-tracker:last-seen": 1404918398057, "address-tracker:ip": "10.0.0.1", "address-tracker:first-seen": 1404918392926, "address-tracker:mac": "f2:0c:dd:80:9f:f7" }] }] }
  • 26.
    Code Design ► yangtoolsgenerates data model classes  Builders for generating immutable objects also generated  identity mapped to interfaces  All else are mapped to classes  Identity is the only one that allows inheritance ► Developers have to write the gateway adapters  Converting from one data model to another  Translating between a non-ODL source and ODL app https://wiki.opendaylight.org/view/YANG_Tools:YANG_to_Java_Mapping 26
  • 27.
    Data Store Management ►Persistence  Everything that gets into a shard is stored in-memory and on the disk.  Restarting the controller will reconstitute the state of the shards from the persisted data. ► Clustering  Multiple controller instances can interwork and share state (for backup reasons rather than load-sharing)  One leader (writer) and multiple followers (read-only) where state consistency is achieved using RAFT algorithm ► Sharding  The big in-memory MD-SAL tree is broken up into a bunch of smaller sub-trees such that 1 model is 1 shard (e.g., inventory, topology and default). 27
  • 28.
  • 29.
    OpenDaylight External Interfaces ►Southbound:  Built-in NETCONF client and BGP speaker to interact with legacy control planes and orchestrate them  Plugin for OpenFlow 1.0 and 1.3 support  Plugin for OVSDB that works with OVS schema (VTEP schema in future) ► Northbound:  REST and NETCONF for receiving intent data Controller platform OpenFlow OVSDB NETCONF BGP Network functions State mgmt App/ Logic Service intent and policy Device manager NETCONF REST Service models Device models
  • 30.
    OpenFlow Southbound ► Programminga flow_mod  Make data transaction as an augmentation to ODL inventory ► Sending a packet_out  Craft packet data as modeled by YANG and make RPC call to transmit ► Receiving a packet_in  Register consumer for data receive notification ► Checking statistics and network changes  Check operational store of ODL inventory Your application OpenFlow Plugin OpenFlow Java Nicira Ext OF plugin Nicira Ext OF Java Datastore (1) (2) (3) Switch1 Switch2 Switch3
  • 31.
    NETCONF Southbound To workwith any NETCONF device, 1. Register device with netconf connector of ODL by providing the details of the netconf-enabled device IP, Username, Password, Port 2. Device supports ietf-netconf-monitoring? a) Yes - Controller automatically pulls in the device’s model b) No - Inject device’s model statically 3. ODL controller automatically mounts the netconf configs in the device to the controller data store. 4. The apps (both JVM apps and REST apps) are now ready to make read/write transaction to the device. 31
  • 32.
    NETCONF based Multi-VendorOSS August 2015 32 Orchestrator NETCONF Service models Device models OSS Engine CLI Models are vendor specific and still need vendor specific adapters in the orchestrator layer. This makes case for OpenConfig
  • 33.
  • 34.
    Three main steps ►Step 1: Define the YANG model for the state ► Step 2: Activation using config subsystem  Each implementation has a YANG file defining its necessary MD-SAL dependencies and its namespace (See tapapp-impl.yang)  Each module has a config XML file that points to the implementation YANG file along with input to the config subsystem (See 50-tapapp-config.xml) ► Step 3: Implement the event handlers for all notifications and call backs  Provider: ► Module that is handles config data changes, receives RPC calls, or publishes notifications  Consumer: ► Module that makes RPC calls, listens to operational data changes, or listens to notifications
  • 35.
    Example of Consumer ►Here is a consumer of OpenFlow inventory updates and flow programming 35 public class ConsumerImpl implements OpendaylightInventoryListener public ConsumerImpl(..) { notificationService.registerNotificationListener(this); this.salFlowService = rpcProviderRegistry.getRpcService(SalFlowService.class) } @Override public void onNodeUpdated(NodeUpdated nodeUpdated) { RemoveFlowInputBuilder flowBuilder = new RemoveFlowInputBuilder(); flowBuilder.setBarrier(true); flowBuilder.setNode(NodeUtils.createNodeRef(nodeUpdated.getId())); salFlowService.removeFlow(flowBuilder.build()); } }
  • 36.
    ► Since RPCcalls typically use the thread of the caller, it is generally recommended to use executor threads to prevent blocking the caller thread. Example of Consumer (contd.) 36 private final ListeningExecutorService executor = MoreExecutors.listeningDecorator(Executors.newFixedThreadPool(10)); @Override public void onNodeUpdated(NodeUpdated nodeUpdated) { final ListenableFuture<RpcResult<RemoveFlowOutput>> result = executor.submit( new Callable<RpcResult<RemoveFlowOutput>>() { public RpcResult<RemoveFlowOutput> call() { try { return salFlowService.removeFlow(flowBuilder.build()).get(); } catch (InterruptedException | ExecutionException e) { e.printStackTrace(); return null; } } }); Futures.addCallback(result, new FutureCallback<RpcResult<Void>>() { public void onSuccess(RpcResult<RemoveFlowOutput> result) { LOG.info(“Flow programming successful {}“, result.getResult()); } public void onFailure(Throwable error) { LOG.info(“Flow programming failed with error {}", error); }; }); } Submit Future to executor Register lean callbbacks
  • 37.
    Example of aProvider ► Implement the auto-generated RPC interface and the datachangelistener 37 public class TutorialTapProvider implements AutoCloseable, DataChangeListener, TapService { public TutorialTapProvider(DataBroker dataBroker) { //Register data change listener dataBroker.registerDataChangeListener( LogicalDatastoreType.CONFIGURATION, rootIID, this, AsyncDataBroker.DataChangeScope.SUBTREE); //Register this class as RPC provider for create-tap call rpcProviderRegistry.addRpcImplementation(TapService.class, this); } @Override public void onDataChanged(AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> change) { // Iterate over any data changes ... } @Override public Future<RpcResult<CreateTapOutput>> createTap(CreateTapInput input) { // Parse the input and perform the tap creation operation ... } }
  • 38.
    Let’s get familiarwith SDN dev environment
  • 39.
    Inside the VirtualMachine ► openvswitch: Virtual switch programmable using OpenFlow ► ovs-ofctl: Command-line utility for checking switch status and manually inserting flow entries.  Check supported commands in manual: $ man ovs-ofctl ► mininet: Network emulation platform  $sudo mn --topo single,3 --mac --switch ovsk --controller remote ► wireshark: Graphical tool for viewing packets with OF protocol plug-in  Start wireshark: $sudo wireshark  Start capture packets going through interface “lo” and Decode as OFP ► Multiple OpenFlow controllers with sample apps prepackaged  NOX, POX, Ryu, and OpenDayLight 39
  • 40.
    Setup: Mininet-based topology 40 Controller port6633c0 OpenFlowSwitch s1 ovs-ofctl (user space process) h3 10.0.0.3 h2 10.0.0.2 h1 10.0.0.1 virtual hosts loopback (127.0.0.1:6633) loopback (127.0.0.1:6634) s1-eth0 s1-eth1 s1-eth2 h1-eth0 h2-eth0 h3-eth0 Linux network namespaces veth pairs $ sudo mn --topo single,3 --mac --switch ovsk --controller remote 1-switch 3-hosts
  • 41.
    ovs-vsctl and ovs-ofctl ►ovs-vsctl is used to check all the bridge configuration ► ovs-ofctl is used to check on the OpenFlow aspects and manage flows ► Before controller is started, execute the following # ovs-ofctl show s1 # ovs-ofctl dump-flows s1 mininet> h1 ping h2 # ovs-ofctl add-flow s1 in_port=1,actions=output:2 # ovs-ofctl add-flow s1 in_port=2,actions=output:1 # ovs-ofctl dump-flows s1 mininet> h1 ping h2 41 All ports of switch shown, but no flows installed. Ping fails because ARP cannot go through Ping works now!
  • 42.
    For exercise 1of programming OpenFlow rules using REST API opendaylight-user@root> feature:install odl-openflowplugin-all opendaylight-user@root> feature:install odl-restconf For exercise 2 of configuring NETCONF device opendaylight-user@root> feature:install odl-netconf-connector-all For enabling basic ping between mininet hosts using L2 Hub opendaylight-user@root> feature:install sdnhub-tutorial-learning-switch Running OpenDaylight Controller $ cd SDNHub_Opendaylight_Tutorial $ cd distribution/opendaylight-karaf/target/assembly/ $ ./bin/karaf clean opendaylight-user@root> feature:list (get all apps available) 42 sdnhub- tutorial -tapapp already installed Note: The tutorial project did not need all ODL libraries or source code
  • 43.
    Running wireshark andEclipse ► Wireshark helps investigate the OpenFlow messages exchanged between the switch and controller # wireshark & ► Eclipse is a popular IDE for developing Java applications. The VM already has Eclipse with maven integration $ eclipse & 43 Write code in Eclipse, but run Karaf with debug enabled in Linux terminal
  • 44.
    Exercises: 1. Flow programmingthrough REST API 2. Configure NETCONF devices from OpenDaylight 3. Writing a simple tap application that receives config through REST 4. Update learning switch application: a) Convert hub to switch b) MD-SAL transaction for MAC Table in learning switch 5. Combine tap and learning switch (Homework)
  • 45.
    1. Flow Programmingthrough REST ► It is possible to use RESTconf to send static flows to the controller. The REST input is based on the YANG model. For instance, post following 2 static flows. curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/opendaylight -inventory:nodes/node/openflow:1/flow-node- inventory:table/0/flow/Dummy_forward curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/opendaylight -inventory:nodes/node/openflow:1/flow-node- inventory:table/0/flow/Dummy_reverse <flow xmlns="urn:opendaylight:flow:inventory"> <id>Dummy_forward</id> <flow-name>Dummy_forward</flow-name> <table_id>0</table_id> <match> <in-port>1</in-port> </match> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>2</output-node-connector> </output-action> </action> </apply-actions> </instruction> </instructions> </flow> <flow xmlns="urn:opendaylight:flow:inventory"> <id>Dummy_reverse</id> <flow-name>Dummy_reverse</flow-name> <table_id>0</table_id> <match> <in-port>2</in-port> </match> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> <output-action> <output-node-connector>1</output-node-connector> </output-action> </action> </apply-actions> </instruction> </instructions> </flow>
  • 46.
    1. Flow Programming(contd.) ► Rules programmed on the switch leads to successful ping 46 $ sudo mn --topo single,3 --mac --switch ovsk,protocols=OpenFlow13 --controller remote mininet> h1 ping h2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. From 10.0.0.1 icmp_seq=1 Destination Host Unreachable From 10.0.0.1 icmp_seq=2 Destination Host Unreachable From 10.0.0.1 icmp_seq=3 Destination Host Unreachable From 10.0.0.1 icmp_seq=4 Destination Host Unreachable 64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.409 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=64 time=0.070 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=64 time=0.099 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=64 time=0.127 ms --- 10.0.0.2 ping statistics --- 12 packets transmitted, 4 received, +8 errors, 66% packet loss, time 11078ms rtt min/avg/max/mdev = 0.070/0.176/0.409/0.136 ms, pipe 4 $ sudo ovs-ofctl dump-flows –OOpenFlow13 s1 OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=183.006s, table=0, n_packets=8, n_bytes=560, idle_timeout=300, hard_timeout=600, in_port=1 actions=output:2 cookie=0x0, duration=181.657s, table=0, n_packets=6, n_bytes=476, idle_timeout=300, hard_timeout=600, in_port=2 actions=output:1
  • 47.
    2. NETCONF Exercise 47 routerospf 1 network 100.100.100.0 0.0.0.255 area 10 ! router bgp 1000 bgp router-id 10.10.1.1 neighbor 10.10.1.2 remote-as 2000 ! NETCONF-based orchestration <router xmlns="urn:sdnhub:odl:tutorial:router"> <ospf> <process-id>1</process-id> <networks> <subnet-ip>100.100.100.0/24</subnet-ip> <area-id>10</area-id> </networks> </ospf> <bgp> <as-number>1000</as-number> <router-id>10.10.1.1</router-id> <neighbors> <as-number>2000</as-number> <peer-ip>10.10.1.2</peer-ip> </neighbors> </bgp> </router>
  • 48.
    2. NETCONF Exercise(contd.) - Demo Router YANG Model module router { yang-version 1; namespace "urn:sdnhub:odl:tutorial:router"; prefix router; description "Router configuration"; revision "2015-07-28" { description "Initial version."; } list interfaces { key id; leaf id { type string; } leaf ip-address { type string; } } container router { list ospf { key process-id; leaf process-id { type uint32; } list networks { key subnet-ip; leaf subnet-ip { type string; } leaf area-id { type uint32; } } } list bgp { key as-number; leaf as-number { type uint32; } leaf router-id { type string; } list neighbors { key as-number; leaf as-number { type uint32; } leaf peer-ip { type string; } } } } }
  • 49.
    2. NETCONF Exercise(contd.) - Experimenting Using Netopeer Step 1: Spawn two emulated routers (i.e., netopeer server containers) $ cd SDNHub_Opendaylight_Tutorial/netconf-exercise $ ./spawn_router.sh router1 $ ./spawn_router.sh router2 Step 2: Register two netconf devices with OpenDaylight $ ./register_netconf_device.sh router1 172.17.0.1 $ ./register_netconf_device.sh router2 172.17.0.2 Step 3: Verify the two devices and its capabilities http://localhost:8181/restconf/operational/network- topology:network-topology/topology/topology-netconf/ August 2015 49
  • 50.
    2. NETCONF Exercise(contd.) Step 4: Using RESTCONF, configure the two devices Step 5: Build an app that directly writes these configs to the datastore 50 curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/network- topology:network-topology/topology/topology- netconf/node/router1/yang-ext:mount/router:router <router xmlns="urn:sdnhub:odl:tutorial:router"> <ospf> <process-id>1</process-id> <networks> <subnet-ip>100.100.100.0/24</subnet-ip> <area-id>10</area-id> </networks> </ospf> <bgp> <as-number>1000</as-number> <router-id>10.10.1.1</router-id> <neighbors> <as-number>2000</as-number> <peer-ip>10.10.1.2</peer-ip> </neighbors> </bgp> </router> curl -X PUT –H “Content-Type: application/xml” http://localhost:8181/restconf/config/network- topology:network-topology/topology/topology- netconf/node/router2/yang-ext:mount/router:router <router xmlns="urn:sdnhub:odl:tutorial:router"> <ospf> <process-id>1</process-id> <networks> <subnet-ip>100.100.200.0/24</subnet-ip> <area-id>10</area-id> </networks> </ospf> <bgp> <as-number>2000</as-number> <router-id>10.10.1.2</router-id> <neighbors> <as-number>1000</as-number> <peer-ip>10.10.1.1</peer-ip> </neighbors> </bgp> </router>
  • 51.
    3. Tutorial ProjectStructure 51 TapApp Learning switch OpenFlow plugin Optional: Reuse Host Tracker MD-SAL DS Data plane TODO: Read/Write transaction from learning-switch { “node": [{ "id": 'openflow:2', "hosts": { "mac-addrress": 00:00:00:00:00:02, “attachment-point": 'openflow:2:2' } ]}} FLOW_MOD PACKET_IN/PACKET_OUT TODO: Process user tap config through RESTconf { "tap": [{ "id": "1", "node": "openflow:1", "sink-node-connector": [ "openflow:1:2" ], "src-node-connector": [ "openflow:1:1" ], "traffic-match": "HTTP" }] }
  • 52.
    3. Tap Application ►Network traffic tap is an application that filters certain traffic coming from a source and sends it to a sink, based on proactively programmed OpenFlow rules ► Step 1: Build the data model… 52 typedef field-type { type enumeration { enum source; enum destination; enum both; } } typedef traffic-type { type enumeration { enum ARP; enum DNS; enum HTTP; enum HTTPS; enum TCP; enum UDP; enum DHCP; enum ICMP; } } container tap-spec { list tap { key "id"; leaf id { type string; } uses tap-grouping; } } grouping tap-grouping { leaf node { mandatory true; type leafref { path "/inv:nodes/inv:node/inv:id"; } } leaf-list src-node-connector { min-elements 1; type leafref { path "/inv:nodes/inv:node/inv:node-connector/inv:id"; } } leaf-list sink-node-connector { min-elements 1; type leafref { path "/inv:nodes/inv:node/inv:node-connector/inv:id"; } } container mac-address-match { leaf type { type field-type; } leaf value { type yang:mac-address; } } container ip-address-match { leaf type { type field-type; } leaf value { type inet:ipv4-prefix; } } leaf traffic-match { type traffic-type; } }
  • 53.
    3. Tap Application(contd.) ► Step 2: Activation using config subsystem ► Step 3: Add event handler for data change to process any new tap config 53 public class TutorialTapProvider implements AutoCloseable, DataChangeListener { public TutorialTapProvider(DataBroker dataBroker) { //TODO 1: Register data change listener } @Override public void onDataChanged(AsyncDataChangeEvent<InstanceIdentifier<?>, DataObject> change) { // Iterate over any created nodes or interfaces for (Map.Entry<InstanceIdentifier<?>, DataObject> entry : change.getCreatedData().entrySet()) { DataObject dataObject = entry.getValue(); if (dataObject instanceof Tap) { //TODO 2: If tap configuration added, call programTap() } } // Iterate over any deleted nodes or interfaces Map<InstanceIdentifier<?>, DataObject> originalData = change.getOriginalData(); for (InstanceIdentifier<?> path : change.getRemovedPaths()) { DataObject dataObject = originalData.get(path); if (dataObject instanceof Tap) { //TODO 3: If tap configuration deleted, call removeTap() } } }
  • 54.
    3. Tap Application(contd.) ► The goal of the tap provider application is to translate data from user input tap config to OpenFlowPlugin data ► OpenFlowPlugin in turn uses that data to program rules 54 { "id":"Tap_1SrcPort_openflow:1:1", "instructions":{ "instruction":[ { "apply-actions":{ "action":[ { "order":0, "output-action":{ "max-length":65535, "output-node-connector":"openflow:1:2" } } ] }, "order":0 } ] }, "match":{ "ethernet-match":{ "ethernet-type":{ "type":2048 } }, "in-port":"openflow:1:1", "ip-match":{ "ip-protocol":6 }, "tcp-destination-port":80 }, "table_id":0 } { "tap": [{ "id": "1", "node": "openflow:1", "sink-node-connector": [ "openflow:1:2" ], "src-node-connector": [ "openflow:1:1" ], "traffic-match": "HTTP" }] }
  • 55.
    4a. Learning Switch ►The code in the VM handles “hub” implementation of the learning-switch  Any received packet-in is received through the PacketProcessingListener. onPacketReceived YANG Notification  Controller, then, performs a packet-out of this packet to all ports through a RPC call to PacketProcessingService.transmitPacket ► Your first task is to convert the code to build a learning switch that: 1. tracks where each MAC address is located. i.e., create a MAC table like follows: Map<String, NodeConnectorId> macTable = new HashMap <String, NodeConnectorId>(); 2. Insert flow rules to switch traffic based on the destination MAC address 55
  • 56.
    4b. MAC Tableof Learning Switch ► In code, you will see the Map data structure called macTable Map<String, NodeConnectorId> macTable = new HashMap <String, NodeConnectorId>(); ► Your second task:  Instead of using local data, store it in MD-SAL using GenericTransactionUtils.writeData() provided ► This will require writing a augmentation YANG model for defining a place to store it. I choose to store it within the opendaylight-inventory tree  Whenever lookup is performed, look into MD-SAL store using GenericTransactionUtils.readData() that is provided 56 augment /odl-inv:nodes/odl-inv:node { ext:augment-identifier "MacTable"; list hosts { leaf mac-address { type yang:mac-address; } leaf attachment-point { //I choose simple one type inet:uri; } } }
  • 57.
    Coding time. Welcome toOpenDaylight programming! 57 http://sdnhub.org/tutorials/opendaylight

Editor's Notes

  • #40 Bootstrap and setup VM should be done offline. Hands-on tutorial will includes: -- introduction to the tools -- start mininet OF network -- ovs-ofctl: checkout switch status, flow status, add flow, delete flow, etc. (ping test) --start OF ryu (do nothing): use wireshark to observe OF messages -- Ryu controller and applications.
  • #42 Bootstrap and setup VM should be done offline. Hands-on tutorial will includes: -- introduction to the tools -- start mininet OF network -- ovs-ofctl: checkout switch status, flow status, add flow, delete flow, etc. (ping test) -- start OF ryu (do nothing): use wireshark to observe OF messages -- Ryu controller and applications. Summays