]>
Commit | Line | Data |
---|---|---|
bbd85e20 OD |
1 | Link State API Documentation |
2 | ============================ | |
3 | ||
4 | Introduction | |
5 | ------------ | |
6 | ||
7 | The Link State (LS) API aims to provide a set of structures and functions to | |
8 | build and manage a Traffic Engineering Database for the various FRR daemons. | |
9 | This API has been designed for several use cases: | |
10 | ||
11 | - BGP Link State (BGP-LS): where BGP protocol need to collect the link state | |
d764ffaf | 12 | information from the routing daemons (IS-IS and/or OSPF) to implement RFC7752 |
bbd85e20 OD |
13 | - Path Computation Element (PCE): where path computation algorithms are based |
14 | on Traffic Engineering Database | |
15 | - ReSerVation Protocol (RSVP): where signaling need to know the Traffic | |
16 | Engineering topology of the network in order to determine the path of | |
17 | RSVP tunnels | |
18 | ||
19 | Architecture | |
20 | ------------ | |
21 | ||
22 | The main requirements from the various uses cases are as follow: | |
23 | ||
24 | - Provides a set of data model and function to ease Link State information | |
25 | manipulation (storage, serialize, parse ...) | |
26 | - Ease and normalize Link State information exchange between FRR daemons | |
27 | - Provides database structure for Traffic Engineering Database (TED) | |
28 | ||
29 | To ease Link State understanding, FRR daemons have been classified into two | |
30 | categories: | |
31 | ||
32 | - **Consumer**: Daemons that consume Link State information e.g. BGPd | |
33 | - **Producer**: Daemons that are able to collect Link State information and | |
34 | send them to consumer daemons e.g. OSPFd IS-ISd | |
35 | ||
36 | Zebra daemon, and more precisely, the ZAPI message is used to convey the Link | |
37 | State information between *producer* and *consumer*, but, Zebra acts as a | |
38 | simple pass through and does not store any Link State information. A new ZAPI | |
39 | **Opaque** message has been design for that purpose. | |
40 | ||
41 | Each consumer and producer daemons are free to store or not Link State data and | |
42 | organise the information following the Traffic Engineering Database model | |
43 | provided by the API or any other data structure e.g. Hash, RB-tree ... | |
44 | ||
45 | Link State API | |
46 | -------------- | |
47 | ||
48 | This is the low level API that allows any daemons manipulate the Link State | |
49 | elements that are stored in the Link State Database. | |
50 | ||
51 | Data structures | |
52 | ^^^^^^^^^^^^^^^ | |
53 | ||
54 | 3 types of Link State structure have been defined: | |
55 | ||
936c12d7 | 56 | .. c:struct:: ls_node |
bbd85e20 OD |
57 | |
58 | that groups all information related to a node | |
59 | ||
936c12d7 | 60 | .. c:struct:: ls_attributes |
bbd85e20 OD |
61 | |
62 | that groups all information related to a link | |
63 | ||
936c12d7 | 64 | .. c:struct:: ls_prefix |
bbd85e20 OD |
65 | |
66 | that groups all information related to a prefix | |
67 | ||
68 | These 3 types of structures are those handled by BGP-LS (see RFC7752) and | |
69 | suitable to describe a Traffic Engineering topology. | |
70 | ||
71 | Each structure, in addition to the specific parameters, embed the node | |
72 | identifier which advertises the Link State and a bit mask as flags to | |
73 | indicates which parameters are valid i.e. for which the value is valid and | |
74 | corresponds to a Link State information conveyed by the routing protocol. | |
75 | ||
936c12d7 | 76 | .. c:struct:: ls_node_id |
bbd85e20 OD |
77 | |
78 | defines the Node identifier as router ID IPv4 address plus the area ID for | |
79 | OSPF or the ISO System ID plus the IS-IS level for IS-IS. | |
80 | ||
81 | Functions | |
82 | ^^^^^^^^^ | |
83 | ||
b0c0b433 OD |
84 | A set of functions is provided to create, delete and compare Link State |
85 | Node, Atribute and Prefix: | |
bbd85e20 OD |
86 | |
87 | .. c:function:: struct ls_node *ls_node_new(struct ls_node_id adv, struct in_addr router_id, struct in6_addr router6_id) | |
b0c0b433 OD |
88 | .. c:function:: struct ls_attributes *ls_attributes_new(struct ls_node_id adv, struct in_addr local, struct in6_addr local6, uint32_t local_id) |
89 | .. c:function:: struct ls_prefix *ls_prefix_new(struct ls_node_id adv, struct prefix p) | |
bbd85e20 | 90 | |
b0c0b433 OD |
91 | Create respectively a new Link State Node, Attribute or Prefix. |
92 | Structure is dynamically allocated. Link State Node ID (adv) is mandatory | |
93 | and: | |
bbd85e20 | 94 | |
b0c0b433 OD |
95 | - at least one of IPv4 or IPv6 must be provided for the router ID |
96 | (router_id or router6_id) for Node | |
97 | - at least one of local, local6 or local_id must be provided for Attribute | |
98 | - prefix is mandatory for Link State Prefix. | |
99 | ||
100 | .. c:function:: void ls_node_del(struct ls_node *node) | |
bbd85e20 | 101 | .. c:function:: void ls_attributes_del(struct ls_attributes *attr) |
b0c0b433 OD |
102 | .. c:function:: void ls_prefix_del(struct ls_prefix *pref) |
103 | ||
104 | Remove, respectively Link State Node, Attributes or Prefix. | |
105 | Data structure is freed. | |
106 | ||
107 | .. c:function:: void ls_attributes_srlg_del(struct ls_attributes *attr) | |
108 | ||
109 | Remove SRLGs attribute if defined. Data structure is freed. | |
110 | ||
111 | .. c:function:: int ls_node_same(struct ls_node *n1, struct ls_node *n2) | |
bbd85e20 | 112 | .. c:function:: int ls_attributes_same(struct ls_attributes *a1, struct ls_attributes *a2) |
b0c0b433 OD |
113 | .. c:function:: int ls_prefix_same(struct ls_prefix *p1, struct ls_prefix*p2) |
114 | ||
115 | Check, respectively if two Link State Nodes, Attributes or Prefix are equal. | |
116 | Note that these routines have the same return value sense as '==' (which is | |
117 | different from a comparison). | |
bbd85e20 | 118 | |
bbd85e20 OD |
119 | |
120 | Link State TED | |
121 | -------------- | |
122 | ||
123 | This is the high level API that provides functions to create, update, delete a | |
b0c0b433 | 124 | Link State Database to build a Traffic Engineering Database (TED). |
bbd85e20 OD |
125 | |
126 | Data Structures | |
127 | ^^^^^^^^^^^^^^^ | |
128 | ||
129 | The Traffic Engineering is modeled as a Graph in order to ease Path Computation | |
130 | algorithm implementation. Denoted **G(V, E)**, a graph is composed by a list of | |
131 | **Vertices (V)** which represents the network Node and a list of **Edges (E)** | |
132 | which represents Link. An additional list of **prefixes (P)** is also added and | |
133 | also attached to the *Vertex (V)* which advertise it. | |
134 | ||
135 | *Vertex (V)* contains the list of outgoing *Edges (E)* that connect this Vertex | |
136 | with its direct neighbors and the list of incoming *Edges (E)* that connect | |
137 | the direct neighbors to this Vertex. Indeed, the *Edge (E)* is unidirectional, | |
138 | thus, it is necessary to add 2 Edges to model a bidirectional relation between | |
139 | 2 Vertices. Finally, the *Vertex (V)* contains a pointer to the corresponding | |
140 | Link State Node. | |
141 | ||
142 | *Edge (E)* contains the source and destination Vertex that this Edge | |
143 | is connecting and a pointer to the corresponding Link State Attributes. | |
144 | ||
145 | A unique Key is used to identify both Vertices and Edges within the Graph. | |
146 | ||
147 | ||
148 | :: | |
149 | ||
150 | -------------- --------------------------- -------------- | |
151 | | Connected |---->| Connected Edge Va to Vb |--->| Connected | | |
152 | --->| Vertex | --------------------------- | Vertex |----> | |
153 | | | | | | |
154 | | - Key (Va) | | - Key (Vb) | | |
155 | <---| - Vertex | --------------------------- | - Vertex |<---- | |
156 | | |<----| Connected Edge Vb to Va |<---| | | |
157 | -------------- --------------------------- -------------- | |
158 | ||
159 | ||
160 | 4 data structures have been defined to implement the Graph model: | |
161 | ||
936c12d7 DL |
162 | .. c:struct:: ls_vertex |
163 | .. c:struct:: ls_edge | |
164 | .. c:struct:: ls_ted | |
165 | ||
166 | - :c:struct:`ls_prefix` | |
bbd85e20 | 167 | |
b0c0b433 OD |
168 | TED stores Vertex, Edge and Subnet elements with a RB Tree structure. |
169 | The Vertex key corresponds to the Router ID for OSPF and ISO System ID for | |
170 | IS-IS. The Edge key corresponds to the IPv4 address, the lowest 64 bits of | |
171 | the IPv6 address or the combination of the local & remote ID of the interface. | |
172 | The Subnet key corresponds to the Prefix address (v4 or v6). | |
bbd85e20 | 173 | |
b0c0b433 OD |
174 | An additional status for Vertex, Edge and Subnet allows to determine the state |
175 | of the element in the TED: UNSET, NEW, UPDATE, DELETE, SYNC, ORPHAN. Normal | |
176 | state is SYNC. NEW, UPDATE and DELETE are temporary state when element is | |
177 | processed. UNSET is normally never used and ORPHAN serves to identify elements | |
178 | that must be remove when TED is cleaning. | |
179 | ||
180 | Vertex, Edges and Subnets management functions | |
181 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
bbd85e20 OD |
182 | |
183 | .. c:function:: struct ls_vertex *ls_vertex_add(struct ls_ted *ted, struct ls_node *node) | |
b0c0b433 OD |
184 | .. c:function:: struct ls_edge *ls_edge_add(struct ls_ted *ted, struct ls_attributes *attributes) |
185 | .. c:function:: struct ls_subnet *ls_subnet_add(struct ls_ted *ted, struct ls_prefix *pref) | |
186 | ||
187 | Add, respectively new Vertex, Edge or Subnet to the Link State Datebase. | |
188 | Vertex, Edge or Subnet are created from, respectively the Link State Node, | |
189 | Attribute or Prefix structure. Data structure are dynamically allocated. | |
190 | ||
bbd85e20 | 191 | .. c:function:: struct ls_vertex *ls_vertex_update(struct ls_ted *ted, struct ls_node *node) |
b0c0b433 OD |
192 | .. c:function:: struct ls_edge *ls_edge_update(struct ls_ted *ted, struct ls_attributes *attributes) |
193 | .. c:function:: struct ls_subnet *ls_subnet_update(struct ls_ted *ted, struct ls_prefix *pref) | |
194 | ||
195 | Update, respectively Vertex, Edge or Subnet with, respectively the Link | |
196 | State Node, Attribute or Prefix. A new data structure is created if no one | |
197 | corresponds to the Link State Node, Attribute or Prefix. If element already | |
198 | exists in the TED, its associated Link State information is replaced by the | |
199 | new one if there are different and the old associated Link State information | |
200 | is deleted and memory freed. | |
201 | ||
bbd85e20 | 202 | .. c:function:: void ls_vertex_del(struct ls_ted *ted, struct ls_vertex *vertex) |
b0c0b433 OD |
203 | .. c:function:: void ls_vertex_del_all(struct ls_ted *ted, struct ls_vertex *vertex) |
204 | .. c:function:: void ls_edge_del(struct ls_ted *ted, struct ls_edge *edge) | |
205 | .. c:function:: void ls_edge_del_all(struct ls_ted *ted, struct ls_edge *edge) | |
206 | .. c:function:: void ls_subnet_del(struct ls_ted *ted, struct ls_subnet *subnet) | |
207 | .. c:function:: void ls_subnet_del_all(struct ls_ted *ted, struct ls_subnet *subnet) | |
208 | ||
209 | Delete, respectively Link State Vertex, Edge or Subnet. Data structure are | |
210 | freed but not the associated Link State information with the simple `_del()` | |
211 | form of the function while the `_del_all()` version freed also associated | |
212 | Link State information. TED is not modified if Vertex, Edge or Subnet is | |
213 | NULL or not found in the Data Base. Note that references between Vertices, | |
214 | Edges and Subnets are removed first. | |
215 | ||
bbd85e20 OD |
216 | .. c:function:: struct ls_vertex *ls_find_vertex_by_key(struct ls_ted *ted, const uint64_t key) |
217 | .. c:function:: struct ls_vertex *ls_find_vertex_by_id(struct ls_ted *ted, struct ls_node_id id) | |
bbd85e20 | 218 | |
b0c0b433 OD |
219 | Find Vertex in the TED by its unique key or its Link State Node ID. |
220 | Return Vertex if found, NULL otherwise. | |
221 | ||
bbd85e20 OD |
222 | .. c:function:: struct ls_edge *ls_find_edge_by_key(struct ls_ted *ted, const uint64_t key) |
223 | .. c:function:: struct ls_edge *ls_find_edge_by_source(struct ls_ted *ted, struct ls_attributes *attributes); | |
224 | .. c:function:: struct ls_edge *ls_find_edge_by_destination(struct ls_ted *ted, struct ls_attributes *attributes); | |
225 | ||
b0c0b433 OD |
226 | Find Edge in the Link State Data Base by its key, source or distination |
227 | (local IPv4 or IPv6 address or local ID) informations of the Link State | |
228 | Attributes. Return Edge if found, NULL otherwise. | |
229 | ||
bbd85e20 OD |
230 | .. c:function:: struct ls_subnet *ls_find_subnet(struct ls_ted *ted, const struct prefix prefix) |
231 | ||
b0c0b433 OD |
232 | Find Subnet in the Link State Data Base by its key, i.e. the associated |
233 | prefix. Return Subnet if found, NULL otherwise. | |
234 | ||
235 | .. c:function:: int ls_vertex_same(struct ls_vertex *v1, struct ls_vertex *v2) | |
236 | .. c:function:: int ls_edge_same(struct ls_edge *e1, struct ls_edge *e2) | |
237 | .. c:function:: int ls_subnet_same(struct ls_subnet *s1, struct ls_subnet *s2) | |
238 | ||
239 | Check, respectively if two Vertices, Edges or Subnets are equal. | |
240 | Note that these routines has the same return value sense as '==' | |
241 | (which is different from a comparison). | |
242 | ||
243 | ||
244 | TED management functions | |
245 | ^^^^^^^^^^^^^^^^^^^^^^^^ | |
246 | ||
247 | Some helpers functions have been also provided to ease TED management: | |
248 | ||
bbd85e20 | 249 | .. c:function:: struct ls_ted *ls_ted_new(const uint32_t key, char *name, uint32_t asn) |
b0c0b433 OD |
250 | |
251 | Create a new Link State Data Base. Key must be different from 0. | |
252 | Name could be NULL and AS number equal to 0 if unknown. | |
253 | ||
bbd85e20 | 254 | .. c:function:: void ls_ted_del(struct ls_ted *ted) |
b0c0b433 OD |
255 | .. c:function:: void ls_ted_del_all(struct ls_ted *ted) |
256 | ||
257 | Delete existing Link State Data Base. Vertices, Edges, and Subnets are not | |
258 | removed with ls_ted_del() function while they are with ls_ted_del_all(). | |
259 | ||
bbd85e20 | 260 | .. c:function:: void ls_connect_vertices(struct ls_vertex *src, struct ls_vertex *dst, struct ls_edge *edge) |
b0c0b433 OD |
261 | |
262 | Connect Source and Destination Vertices by given Edge. Only non NULL source | |
263 | and destination vertices are connected. | |
264 | ||
bbd85e20 OD |
265 | .. c:function:: void ls_connect(struct ls_vertex *vertex, struct ls_edge *edge, bool source) |
266 | .. c:function:: void ls_disconnect(struct ls_vertex *vertex, struct ls_edge *edge, bool source) | |
b0c0b433 OD |
267 | |
268 | Connect / Disconnect Link State Edge to the Link State Vertex which could be | |
269 | a Source (source = true) or a Destination (source = false) Vertex. | |
270 | ||
bbd85e20 OD |
271 | .. c:function:: void ls_disconnect_edge(struct ls_edge *edge) |
272 | ||
b0c0b433 OD |
273 | Disconnect Link State Edge from both Source and Destination Vertex. |
274 | Note that Edge is not removed but its status is marked as ORPHAN. | |
275 | ||
276 | .. c:function:: void ls_vertex_clean(struct ls_ted *ted, struct ls_vertex *vertex, struct zclient *zclient) | |
277 | ||
278 | Clean Vertex structure by removing all Edges and Subnets marked as ORPHAN | |
279 | from this vertex. Corresponding Link State Update message is sent if zclient | |
280 | parameter is not NULL. Note that associated Link State Attribute and Prefix | |
281 | are also removed and memory freed. | |
282 | ||
283 | .. c:function:: void ls_ted_clean(struct ls_ted *ted) | |
284 | ||
285 | Clean Link State Data Base by removing all Vertices, Edges and SubNets | |
286 | marked as ORPHAN. Note that associated Link State Node, Attributes and | |
287 | Prefix are removed too. | |
288 | ||
289 | .. c:function:: void ls_show_vertex(struct ls_vertex *vertex, struct vty *vty, struct json_object *json, bool verbose) | |
290 | .. c:function:: void ls_show_edge(struct ls_edeg *edge, struct vty *vty, struct json_object *json, bool verbose) | |
291 | .. c:function:: void ls_show_subnet(struct ls_subnet *subnet, struct vty *vty, struct json_object *json, bool verbose) | |
292 | .. c:function:: void ls_show_vertices(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose) | |
293 | .. c:function:: void ls_show_edges(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose) | |
294 | .. c:function:: void ls_show_subnets(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose) | |
295 | .. c:function:: void ls_show_ted(struct ls_ted *ted, struct vty *vty, struct json_object *json, bool verbose) | |
296 | ||
297 | Respectively, show Vertex, Edge, Subnet provided as parameter, all Vertices, | |
298 | all Edges, all Subnets and the whole TED if not specified. Output could be | |
299 | more detailed with verbose parameter for VTY output. If both JSON and VTY | |
300 | output are specified, JSON takes precedence over VTY. | |
301 | ||
302 | .. c:function:: void ls_dump_ted(struct ls_ted *ted) | |
303 | ||
304 | Dump TED information to the current logging output. | |
bbd85e20 OD |
305 | |
306 | Link State Messages | |
307 | ------------------- | |
308 | ||
309 | This part of the API provides functions and data structure to ease the | |
310 | communication between the *Producer* and *Consumer* daemons. | |
311 | ||
312 | Communications principles | |
313 | ^^^^^^^^^^^^^^^^^^^^^^^^^ | |
314 | ||
315 | Recent ZAPI Opaque Message is used to exchange Link State data between daemons. | |
316 | For that purpose, Link State API provides new functions to serialize and parse | |
317 | Link State information through the ZAPI Opaque message. A dedicated flag, | |
318 | named ZAPI_OPAQUE_FLAG_UNICAST, allows daemons to send a unicast or a multicast | |
319 | Opaque message and is used as follow for the Link State exchange: | |
320 | ||
321 | - Multicast: To send data update to all daemons that have subscribed to the | |
322 | Link State Update message | |
323 | - Unicast: To send initial Link State information from a particular daemon. All | |
324 | data are send only to the daemon that request Link State Synchronisatio | |
325 | ||
326 | Figure 1 below, illustrates the ZAPI Opaque message exchange between a | |
327 | *Producer* (an IGP like OSPF or IS-IS) and a *Consumer* (e.g. BGP). The | |
328 | message sequences are as follows: | |
329 | ||
330 | - First, both *Producer* and *Consumer* must register to their respective ZAPI | |
b0c0b433 OD |
331 | Opaque Message: **Link State Sync** for the *Producer* in order to receive |
332 | Database synchronisation request from a *Consumer*, **Link State Update** for | |
bbd85e20 OD |
333 | the *Consumer* in order to received any Link State update from a *Producer*. |
334 | These register messages are stored by Zebra to determine to which daemon it | |
335 | should redistribute the ZAPI messages it receives. | |
336 | - Then, the *Consumer* sends a **Link State Synchronistation** request with the | |
337 | Multicast method in order to receive the complete Link State Database from a | |
338 | *Producer*. ZEBRA daemon forwards this message to any *Producer* daemons that | |
339 | previously registered to this message. If no *Producer* has yet registered, | |
340 | the request is lost. Thus, if the *Consumer* receives no response whithin a | |
341 | given timer, it means that no *Producer* are available right now. So, the | |
342 | *Consumer* must send the same request until it receives a Link State Database | |
343 | Synchronistation message. This behaviour is necessary as we can't control in | |
344 | which order daemons are started. It is up to the *Consumer* daemon to fix the | |
345 | timeout and the number of retry. | |
346 | - When a *Producer* receives a **Link State Synchronisation** request, it | |
347 | starts sending all elements of its own Link State Database through the | |
348 | **Link State Database Synchronisation** message. These messages are send with | |
349 | the Unicast method to avoid flooding other daemons with these elements. ZEBRA | |
350 | layer ensures to forward the message to the right daemon. | |
351 | - When a *Producer* update its Link State Database, it automatically sends a | |
352 | **Link State Update** message with the Multicast method. In turn, ZEBRA | |
353 | daemon forwards the message to all *Consumer* daemons that previously | |
354 | registered to this message. if no daemon is registered, the message is lost. | |
355 | - A daemon could unregister from the ZAPI Opaque message registry at any time. | |
356 | In this case, the ZEBRA daemon stops to forward any messages it receives to | |
357 | this daemon, even if it was previously converns. | |
358 | ||
359 | :: | |
360 | ||
361 | IGP ZEBRA Consumer | |
362 | (OSPF/IS-IS) (ZAPI Opaque Thread) (e.g. BGP) | |
363 | | | | \ | |
364 | | | Register LS Update | | | |
365 | | |<----------------------------| Register Phase | |
366 | | | | | | |
367 | | | Request LS Sync | | | |
368 | | |<----------------------------| | | |
369 | : : : A | | |
370 | | Register LS Sync | | | | | |
371 | |----------------------------->| | | / | |
372 | : : : |TimeOut | |
373 | : : : | | |
374 | | | | | | |
375 | | | Request LS Sync | v \ | |
376 | | Request LS Sync |<----------------------------| | | |
377 | |<-----------------------------| | Synchronistation | |
b0c0b433 OD |
378 | | LS DB Update | | Phase |
379 | |----------------------------->| LS DB Update | | | |
bbd85e20 | 380 | | |---------------------------->| | |
b0c0b433 OD |
381 | | LS DB Update (cont'd) | | | |
382 | |----------------------------->| LS DB Update (cont'd) | | | |
bbd85e20 OD |
383 | | . |---------------------------->| | |
384 | | . | . | | | |
385 | | . | . | | | |
b0c0b433 OD |
386 | | LS DB Update (end) | . | | |
387 | |----------------------------->| LS DB Update (end) | | | |
bbd85e20 OD |
388 | | |---------------------------->| | |
389 | | | | / | |
390 | : : : | |
391 | : : : | |
b0c0b433 OD |
392 | | LS DB Update | | \ |
393 | |----------------------------->| LS DB Update | | | |
bbd85e20 OD |
394 | | |---------------------------->| Update Phase |
395 | | | | | | |
396 | : : : / | |
397 | : : : | |
398 | | | | \ | |
399 | | | Unregister LS Update | | | |
400 | | |<----------------------------| Deregister Phase | |
401 | | | | | | |
b0c0b433 | 402 | | LS DB Update | | | |
bbd85e20 OD |
403 | |----------------------------->| | | |
404 | | | | / | |
405 | | | | | |
406 | ||
407 | Figure 1: Link State messages exchange | |
408 | ||
409 | ||
410 | Data Structures | |
411 | ^^^^^^^^^^^^^^^ | |
412 | ||
413 | The Link State Message is defined to convey Link State parameters from | |
414 | the routing protocol (OSPF or IS-IS) to other daemons e.g. BGP. | |
415 | ||
936c12d7 | 416 | .. c:struct:: ls_message |
bbd85e20 OD |
417 | |
418 | The structure is composed of: | |
419 | ||
420 | - Event of the message: | |
421 | ||
422 | - Sync: Send the whole LS DB following a request | |
423 | - Add: Send the a new Link State element | |
424 | - Update: Send an update of an existing Link State element | |
425 | - Delete: Indicate that the given Link State element is removed | |
426 | ||
427 | - Type of Link State element: Node, Attribute or Prefix | |
428 | - Remote node id when known | |
429 | - Data: Node, Attributes or Prefix | |
430 | ||
431 | A Link State Message can carry only one Link State Element (Node, Attributes | |
432 | of Prefix) at once, and only one Link State Message is sent through ZAPI | |
433 | Opaque Link State type at once. | |
434 | ||
435 | Functions | |
436 | ^^^^^^^^^ | |
437 | ||
b0c0b433 OD |
438 | .. c:function:: int ls_register(struct zclient *zclient, bool server) |
439 | .. c:function:: int ls_unregister(struct zclient *zclient, bool server) | |
440 | ||
441 | Register / Unregister daemon to received ZAPI Link State Opaque messages. | |
442 | Server must be set to true for *Producer* and to false for *Consumer*. | |
443 | ||
444 | .. c:function:: int ls_request_sync(struct zclient *zclient) | |
445 | ||
446 | Request initial Synchronisation to collect the whole Link State Database. | |
447 | ||
bbd85e20 | 448 | .. c:function:: struct ls_message *ls_parse_msg(struct stream *s) |
b0c0b433 OD |
449 | |
450 | Parse Link State Message from stream. Used this function once receiving a | |
451 | new ZAPI Opaque message of type Link State. | |
452 | ||
453 | .. c:function:: void ls_delete_msg(struct ls_message *msg) | |
454 | ||
455 | Delete existing message. Data structure is freed. | |
456 | ||
bbd85e20 | 457 | .. c:function:: int ls_send_msg(struct zclient *zclient, struct ls_message *msg, struct zapi_opaque_reg_info *dst) |
b0c0b433 OD |
458 | |
459 | Send Link State Message as new ZAPI Opaque message of type Link State. | |
460 | If destination is not NULL, message is sent as Unicast otherwise it is | |
461 | broadcast to all registered daemon. | |
462 | ||
bbd85e20 OD |
463 | .. c:function:: struct ls_message *ls_vertex2msg(struct ls_message *msg, struct ls_vertex *vertex) |
464 | .. c:function:: struct ls_message *ls_edge2msg(struct ls_message *msg, struct ls_edge *edge) | |
465 | .. c:function:: struct ls_message *ls_subnet2msg(struct ls_message *msg, struct ls_subnet *subnet) | |
b0c0b433 OD |
466 | |
467 | Create respectively a new Link State Message from a Link State Vertex, Edge | |
468 | or Subnet. If Link State Message is NULL, a new data structure is | |
469 | dynamically allocated. Note that the Vertex, Edge and Subnet status is used | |
470 | to determine the corresponding Link State Message event: ADD, UPDATE, | |
471 | DELETE, SYNC. | |
472 | ||
473 | .. c:function:: int ls_msg2vertex(struct ls_ted *ted, struct ls_message *msg) | |
474 | .. c:function:: int ls_msg2edge(struct ls_ted *ted, struct ls_message *msg) | |
475 | .. c:function:: int ls_msg2subnet(struct ls_ted *ted, struct ls_message *msg) | |
476 | ||
477 | Convert Link State Message respectively in Vertex, Edge or Subnet and | |
478 | update the Link State Database accordingly to the message event: SYNC, ADD, | |
479 | UPDATE or DELETE. | |
480 | ||
481 | .. c:function:: struct ls_element *ls_msg2ted(struct ls_ted *ted, struct ls_message *msg, bool delete) | |
482 | .. c:function:: struct ls_element *ls_stream2ted(struct ls_ted *ted, struct ls_message *msg, bool delete) | |
483 | ||
484 | Convert Link State Message or Stream Buffer in a Link State element (Vertex, | |
485 | Edge or Subnet) and update the Link State Database accordingly to the | |
486 | message event: SYNC, ADD, UPDATE or DELETE. The function return the generic | |
487 | structure ls_element that point to the Vertex, Edge or Subnet which has been | |
488 | added, updated or synchronous in the database. Note that the delete boolean | |
489 | parameter governs the action for the DELETE action: true, Link State Element | |
490 | is removed from the database and NULL is return. If set to false, database | |
491 | is not updated and the function sets the Link State Element status to | |
492 | Delete and return the element for futur deletion by the calling function. | |
493 | ||
bbd85e20 OD |
494 | .. c:function:: int ls_sync_ted(struct ls_ted *ted, struct zclient *zclient, struct zapi_opaque_reg_info *dst) |
495 | ||
b0c0b433 OD |
496 | Send all the content of the Link State Data Base to the given destination. |
497 | Link State content is sent is this order: Vertices, Edges then Subnet. | |
498 | This function must be used when a daemon request a Link State Data Base | |
499 | Synchronization. |