3 IMPORTANT: This section assumes you have already downloaded the Karaf
4 distribution of OpenDaylight Helium and followed the
5 instructions in the Table Type Patterns section of the
6 Installation guide. If not, do that first.
10 Table Type Patterns are a specification developed by the
11 https://www.opennetworking.org/[Open Networking Foundation] to enable
12 the description and negotiation of subsets of the OpenFlow protocol.
13 This is particularly useful for hardware switches that support OpenFlow
14 as it enables the to describe what features they do (and thus also what
15 features they do not) support. More details can be found in the full
16 specification listed on the
17 https://www.opennetworking.org/sdn-resources/onf-specifications/openflow[OpenFlow
19 // for reasons that baffle me, I cannot link to:
20 // https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/OpenFlow%20Table%20Type%20Patterns%20v1.0.pdf
21 // it renders it as a link to a file ignoring the https part
23 ==== Support in Helium
24 In the Helium release, Table Type Patterns (TTPs) are exposed as a YANG
25 model for TTPs themselves which can be loaded into the MD-SAL Data
26 Store in three places:
27 // link to the MD-SAL Data Store docs?
29 . As one of a list of TTPs in the +opendaylight-ttps+ top-level
31 . Attached to a +node+ in the +opendaylight-inventory+ model as an
32 +active_ttp+ via the +ttp-capable-node+ augmentation.
33 . Attached to a +node+ in the +opendaylight-inventory+ model as one of
34 a list of +supported_ttps+ via the +ttp-capable-node+ augmentation.
35 // link to the inventory docs somehow?
37 Each of these points can be accessed either through the RESTCONF-based
38 REST APIs or via the Java interface to the MD-SAL Data Store. This
39 discussion will focus on the REST APIs.
42 ===============================
43 Developers who wish to use the Java interfaces are encouraged to to
44 first read and understand using the MD-SAL Data Store's APIs including
45 importing the appropriate bundles for to get models, dealing with
46 transactions, and constructing instance identifiers.
48 After that, it should be somewhat straightforward to translate the REST
49 API calls here into appropriate instance identifiers which can be used
50 in MD-SAL Data Store transactions.
51 ===============================
53 === Using The REST APIs
55 As stated above there are 3 locations where a Table Type Patter can be
56 placed into the MD-SAL Data Store. They correspond to 3 different REST
59 . +restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/+
60 . +restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:active_ttp/+
61 . +restconf/config/opendaylight-inventory:nodes/node/{id}/ttp-inventory-node:supported_ttps/+
64 ===============================
65 Typically, these URIs are running on the machine the controller is on
66 at port 8181. If you are on the same machine they can thus be accessed
67 at +http://localhost:8181/<uri>+
68 ===============================
70 ==== Setting REST HTTP Headers
74 The REST API calls require authentication by default. The default
75 method is to use basic auth with a user name and password of `admin'.
77 ===== Content-Type and Accept
79 RESTCONF supports both xml and json. This example focuses on JSON, but
80 xml can be used just as easily. When doing a PUT or POST be sure to
81 specify the appropriate +Conetnt-Type+ header: either
82 +application/json+ or +application/xml+.
84 When doing a GET be sure to specify the appropriate +Accept+ header:
85 again, either +application/json+ or +application/xml+.
89 The contents of a PUT or POST should be a OpenDaylight Table Type
90 Pattern. An example of one is provided below. The example can also be
91 found at https://git.opendaylight.org/gerrit/gitweb?p=ttp.git;a=blob;f=parser/sample-TTP-from-tests.ttp;h=45130949b25c6f86b750959d27d04ec2208935fb;hb=HEAD[+parser/sample-TTP-from-tests.ttp+ in the TTP git repository].
93 .Sample Table Type Pattern (json)
94 -----------------------------------------------------
96 "table-type-patterns": {
97 "table-type-pattern": [
101 "This TTP is not published for use by ONF. It is an example and for",
102 "illustrative purposes only.",
103 "If this TTP were published for use it would include",
104 "guidance as to any security considerations in this doc member."
108 "authority": "org.opennetworking.fawg",
109 "OF_protocol_version": "1.3.3",
113 "Example of a TTP supporting L2 (unicast, multicast, flooding), L3 (unicast only),",
121 "The VLAN ID of a locally attached L2 subnet on a Router."
123 "var": "<subnet_VID>"
127 "An OpenFlow group identifier (integer) identifying a group table entry",
128 "of the type indicated by the variable name"
130 "var": "<<group_entry_types/name>>"
136 "Flow entry notification Extension – notification of changes in flow entries"
142 "Group notifications Extension – notification of changes in group or meter entries"
150 "name": "ControllerMeterType",
154 "rate": "1000..10000",
160 "name": "TrafficMeter",
163 "type": "DSCP_REMARK",
164 "rate": "10000..500000",
169 "rate": "10000..500000",
177 "name": "ControllerMeter",
179 "type": "ControllerMeterType",
188 "name": "AllArpMeter",
190 "type": "ControllerMeterType",
202 "name": "ControlFrame",
206 "name": "IngressVLAN",
210 "name": "MacLearning",
222 "name": "ProtoFilter",
239 "name": "Showing-curt-how-this-works",
246 "Filters L2 control reserved destination addresses and",
247 "may forward control packets to the controller.",
248 "Directs all other packets to the Ingress VLAN table."
250 "name": "ControlFrame",
254 "This match/action pair allows for flow_mods that match on either",
255 "ETH_TYPE or ETH_DST (or both) and send the packet to the",
256 "controller, subject to metering."
258 "name": "Frame-To-Controller",
262 "match_type": "all_or_exact"
266 "match_type": "exact"
272 "This meter may be used to limit the rate of PACKET_IN frames",
273 "sent to the controller"
275 "instruction": "METER",
276 "meter_name": "ControllerMeter"
279 "instruction": "APPLY_ACTIONS",
290 "built_in_flow_mods": [
293 "Mandatory filtering of control frames with C-VLAN Bridge reserved DA."
295 "name": "Control-Frame-Filter",
300 "mask": "0xfffffffffff0",
301 "value": "0x0180C2000000"
307 "Mandatory miss flow_mod, sends packets to IngressVLAN table."
309 "name": "Non-Control-Frame",
313 "instruction": "GOTO_TABLE",
314 "table": "IngressVLAN"
321 "group_entry_types": [
324 "Output to a port, removing VLAN tag if needed.",
325 "Entry per port, plus entry per untagged VID per port."
327 "name": "EgressPort",
328 "group_type": "INDIRECT",
331 "name": "OutputTagged",
340 "name": "OutputUntagged",
353 "name": "OutputVIDTranslate",
356 "action": "SET_FIELD",
358 "value": "<local_vid>"
372 "This object contains just a few examples of flow paths, it is not",
373 "a comprehensive list of the flow paths required for this TTP. It is",
374 "intended that the flow paths array could include either a list of",
375 "required flow paths or a list of specific flow paths that are not",
376 "required (whichever is more concise or more useful."
456 -----------------------------------------------------
458 ==== Making a REST Call
460 In this example we'll do a PUT to install the sample TTP from above
461 into OpenDaylight and then retrieve it both as json and as xml. We'll
462 use the https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm[
463 Postman - REST Client] for Chrome in the examples, but any method of
464 accessing REST should work.
466 First, we'll fill in the basic information:
468 .Filling in URL, content, Content-Type and basic auth
469 image::ttp-screen1-basic-auth.png[width=500]
471 . Set the URL to +http://localhost:8181/restconf/config/onf-ttp:opendaylight-ttps/onf-ttp:table-type-patterns/+
472 . Set the action to +PUT+
474 . Set a header for +Content-Type+ to +application/json+
475 . Make sure the content is set to raw and
476 . Copy the sample TTP from above into the content
477 . Click the Basic Auth tab and
478 . Set the username and password to admin
479 . Click Refresh headers
481 .Refreshing basic auth headers
482 image::ttp-screen2-applied-basic-auth.png[width=500]
484 After clicking Refresh headers, we can see that a new header
485 (+Authorization+) has been created and this will allow us to
486 authenticate to make the rest call.
489 image::ttp-screen3-sent-put.png[width=500]
491 At this point, clicking send should result in a Status response of +200
492 OK+ indicating we've successfully PUT the TTP into OpenDaylight.
494 .Retrieving the TTP as json via a GET
495 image::ttp-screen4-get-json.png[width=500]
497 We can now retrieve the TTP by:
499 . Changing the action to +GET+
500 . Setting an +Accept+ header to +application/json+ and
503 .Retrieving the TTP as xml via a GET
504 image::ttp-screen5-get-xml.png[width=500]
506 The same process can retrieve the content as xml by setting the
507 +Accept+ header to +application/xml+.
511 ==== Differences between OpenDaylight TTP and ONF TTP
513 The OpenDaylight YANG specification for TTPs differs from the ONF's
514 specification in a few areas. These differences are due to limitations
515 in the subsets of JSON that YANG schemas can be used to describe.
517 * *+doc+ members must always be lists and cannot be just a string*
519 For example, this is not allowed:
522 "doc": "The VLAN ID of a locally attached L2 subnet on a Router."
528 "doc": ["The VLAN ID of a locally attached L2 subnet on a Router."]
532 * *+table_map+ formats differ*
534 In the ONF spec, the table_map looks like this
545 In the ODL TTP YANG definition, it would instead look like this:
549 { "name": "ControlFrame", "number": 0 },
550 { "name": "IngressVLAN", "number": 1 },
551 { "name": "MacLearning", "number": 2 },
552 { "name": "L2", "number": 3 },
557 * *Limited meta member keywords*
559 The meta member keywords (+all+, +one_or_more+, +zero_or_more+,
560 +exactly_one+, and +zero_or_one+) are allowed anywhere in a TTP
561 according to the ONF specification, but they are only allowed in
562 specific locations in the ODL YANG schema. Specifically:
564 .. +all+, +one_or_more+, and +zero_or_more+ are allowed in the +flow_mod_types+ member
565 .. +exactly_one+ and +zero_or_one+ are allowed in the +match_set+ and
566 +instruction_set+ members as well as in in lists of actions.
569 * *+flow_paths+ repeated table syntax differs*
571 In the ONF TTP specification, the ability to repeat a table in a path
572 traversal of the tables is done by having the table be a list
573 containing the table name as a string. Like this:
576 "flow_paths": ["path": ["table1", ["table2"] ] ]
579 In the ODL YANG schema this is instead represented by moving the square
580 brackets inside the string as follows:
583 flow_paths": ["path": ["table1", "[table2]" ] ]
587 * *+priority+ and +priority_rank+ must be strings and can't be numbers.
589 The +priority+ and +priority_rank+ members are allowed to be either
590 strings or numbers in the ONF specification, but must be strings in the
593 * *Empty lists must be omitted*
601 must instead be omitted from the TTP.
603 ==== Strictly Informational
605 At this point in time the only operations available with TTPs are
606 storing and retrieving TTPs from the data store in the three previously
609 Additional features that make use of and populate this information are
610 planned for future releases.
614 . Strings containing some special characters result in REST calls
615 returning a +400 Bad Request+ code. A string that contains both an
616 opening angle bracket (<) and a colon (:) with the angle bracket
617 appearing first is known to trigger this behavior.
619 For example this is known to break RESTCONF:
622 "var": "<<group_entry_types:name>>"
628 "var": "group_entry_types:name"
632 "var": "<<group_entry_types/name>>"