1 Network Intent Composition (NIC) Developer Guide
2 ================================================
7 The Network Intent Composition (NIC) provides four features:
9 - odl-nic-core-hazelcast: Provides a distributed intent mapping
10 service, implemented using hazelcast, that stores metadata needed by
13 - odl-nic-core-mdsal: Provides an intent rest API to external
14 applications for CRUD operations on intents, conflict resolution and
15 event handling. Uses MD-SAL as backend.
17 - odl-nic-console: Provides a karaf CLI extension for intent CRUD
18 operations and mapping service operations.
20 - odl-nic-renderer-of - Generic OpenFlow Renderer.
22 - odl-nic-renderer-vtn - a feature that transforms an intent to a
23 network modification using the VTN project
25 - odl-nic-renderer-gbp - a feature that transforms an intent to a
26 network modification using the Group Policy project
28 - odl-nic-renderer-nemo - a feature that transforms an intent to a
29 network modification using the NEMO project
31 - odl-nic-listeners - adds support for event listening. (depends on:
34 - odl-nic-neutron-integration - allow integration with openstack
35 neutron to allow coexistence between existing neutron security rules
36 and intents pushed by ODL applications.
38 *Only a single renderer feature should be installed at a time for the
41 odl-nic-core-mdsal XOR odl-nic-core-hazelcast
42 ---------------------------------------------
44 This feature supplies the base models for the Network Intent Composition
45 (NIC) capability. This includes the definition of intent as well as the
46 configuration and operational data trees.
48 This feature only provides an information model. The interface for NIC
49 is to modify the information model via the configuraiton data tree,
50 which will trigger the renderer to make the appropriate changes in the
56 First you need to install one of the core installations:
57 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61 feature:install odl-nic-core-service-mdsal odl-nic-console
67 feature:install odl-nic-core-service-hazelcast odl-nic-console
74 feature:install odl-nic-listeners (will install odl-nic-renderer-of)
80 feature:install odl-nic-renderer-vtn
86 feature:install odl-nic-renderer-gbp
92 feature:install odl-nic-renderer-nemo
94 REST Supported operations
95 -------------------------
97 POST / PUT (configuration)
98 ~~~~~~~~~~~~~~~~~~~~~~~~~~
100 This operations create instances of an intent in the configuration data
101 tree and trigger the creation or modification of an intent.
103 GET (configuration / operational)
104 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
106 This operation lists all or fetches a single intent from the data tree.
108 DELETE (configuration)
109 ~~~~~~~~~~~~~~~~~~~~~~
111 This operation will cause an intent to be removed from the system and
112 trigger any configuration changes on the network rendered from this
113 intent to be removed.
115 odl-nic-cli user guide
116 ----------------------
118 This feature provides karaf console CLI command to manipulate the intent
119 data model. The CLI essentailly invokes the equivalent data operations.
124 Creates a new intent in the configuration data tree
131 Adds an intent to the controller.
133 Examples: --actions [ALLOW] --from <subject> --to <subject>
134 --actions [BLOCK] --from <subject>
141 Action to be performed.
142 -a / --actions BLOCK/ALLOW
143 (defaults to [BLOCK])
145 Display this help message
152 -f / --from <subject>
158 Removes an existing intent from the system
165 Removes an intent from the controller.
176 Lists all the intents in the system
183 Lists all intents in the controller.
186 intent:list [options]
190 List Configuration Data (optional).
191 -c / --config <ENTER>
193 Display this help message
198 Displays the details of a single intent
205 Shows detailed information about an intent.
216 List/Add/Delete current state from/to the mapping service.
223 List/Add/Delete current state from/to the mapping service.
228 Examples: --list, -l [ENTER], to retrieve all keys.
229 --add-key <key> [ENTER], to add a new key with empty contents.
230 --del-key <key> [ENTER], to remove a key with it's values."
231 --add-key <key> --value [<value 1>, <value 2>, ...] [ENTER],
232 to add a new key with some values (json format).
235 Display this help message
237 List values associated with a particular key.
238 -l / --filter <regular expression> [ENTER]
240 Adds a new key to the mapping service.
241 --add-key <key name> [ENTER]
243 Specifies which value should be added/delete from the mapping service.
244 --value "key=>value"... --value "key=>value" [ENTER]
247 Deletes a key from the mapping service.
248 --del-key <key name> [ENTER]
250 Sample Use case: MPLS
251 ---------------------
256 The scope of this use-case is to add MPLS intents between two MPLS
257 endpoints. The use-case tries to address the real-world scenario
258 illustrated in the diagram below:
260 .. figure:: ./images/nic/MPLS_VPN_Service_Diagram.png
261 :alt: MPLS VPN Service Diagram
263 MPLS VPN Service Diagram
265 where PE (Provider Edge) and P (Provider) switches are managed by
266 OpenDaylight. In NIC’s terminology the endpoints are the PE switches.
267 There could be many P switches between the PEs.
269 In order for NIC to recognize endpoints as MPLS endpoints, the user is
270 expected to add mapping information about the PE switches to NIC’s
271 mapping service to include the below properties:
273 1. MPLS Label to identify a PE
275 2. IPv4 Prefix for the customer site that are connected to a PE
277 3. Switch-Port: Ingress (or Egress) for source (or Destination) endpoint
278 of the source (or Destination) PE
280 An intent:add between two MPLS endpoints renders OpenFlow rules for: 1.
281 push/pop labels to the MPLS endpoint nodes after an IPv4 Prefix match.
282 2. forward to port rule after MPLS label match to all the switches that
283 form the shortest path between the endpoints (calculated using Dijkstra
286 Additionally, we have also added constraints to Intent model for
287 protection and failover mechanism to ensure end-to-end connectivity
288 between endpoints. By specifying these constraints to intent:add the
289 use-case aims to reduces the risk of connectivity failure due to a
290 single link or port down event on a forwarding device.
292 - Protection constraint: Constraint that requires an end-to-end
293 connectivity to be protected by providing redundant paths.
295 - Failover constraint: Constraint that specifies the type of failover
296 implementation. slow-reroute: Uses disjoint path calculation
297 algorithms like Suurballe to provide alternate end-to-end routes.
298 fast-reroute: Uses failure detection feature in hardware forwarding
299 device through OF group table features (Future plans) When no
300 constraint is requested by the user we default to offering a since
301 end-to-end route using Dijkstra shortest path.
306 1. Start Karaf and install related features:
310 feature:install odl-nic-core-service-mdsal odl-nic-core odl-nic-console odl-nic-listeners
311 feature:install odl-dlux-all odl-dlux-core odl-dlux-yangui odl-dlux-yangvisualizer
313 2. Start mininet topology and verify in DLUX Topology page for the nodes
318 mn --controller=remote,ip=$CONTROLLER_IP --custom ~/shortest_path.py --topo shortest_path --switch ovsk,protocols=OpenFlow13
323 from mininet.topo import Topo
324 from mininet.cli import CLI
325 from mininet.net import Mininet
326 from mininet.link import TCLink
327 from mininet.util import irange,dumpNodeConnections
328 from mininet.log import setLogLevel
332 class Fast_Failover_Demo_Topo(Topo):
337 # Initialize topology and default options
342 s1 = self.addSwitch('s1',dpid='0000000000000001')
343 s2a = self.addSwitch('s2a',dpid='000000000000002a')
344 s2b = self.addSwitch('s2b',dpid='000000000000002b')
345 s2c = self.addSwitch('s2c',dpid='000000000000002c')
346 s3 = self.addSwitch('s3',dpid='0000000000000003')
347 self.addLink(s1, s2a)
348 self.addLink(s1, s2b)
349 self.addLink(s2b, s2c)
350 self.addLink(s3, s2a)
351 self.addLink(s3, s2c)
352 host_1 = self.addHost('h1',ip='10.0.0.1',mac='10:00:00:00:00:01')
353 host_2 = self.addHost('h2',ip='10.0.0.2',mac='10:00:00:00:00:02')
354 self.addLink(host_1, s1)
355 self.addLink(host_2, s3)
359 topos = { 'shortest_path': ( lambda: Demo_Topo() ) }
361 3. Update the mapping service with required information
374 "inner-key": "ip_prefix",
375 "value": "10.0.0.1/32"
378 "inner-key": "mpls_label",
382 "inner-key": "switch_port",
383 "value": "openflow:1:1"
391 "inner-key": "ip_prefix",
392 "value": "10.0.0.2/32"
395 "inner-key": "mpls_label",
399 "inner-key": "switch_port",
400 "value": "openflow:3:1"
408 4. Create bidirectional Intents using Karaf command line or RestCONF:
414 intent:add -f uva -t eur -a ALLOW
415 intent:add -f eur -t uva -a ALLOW
417 5. Verify by running ovs-ofctl command on mininet if the flows were pushed
418 correctly to the nodes that form the shortest path.
424 ovs-ofctl -O OpenFlow13 dump-flows s1