Print this page
Try versioning as a new state
| Split |
Close |
| Expand all |
| Collapse all |
--- old/usr/src/lib/varpd/svp/common/libvarpd_svp_prot.h
+++ new/usr/src/lib/varpd/svp/common/libvarpd_svp_prot.h
1 1 /*
2 2 * This file and its contents are supplied under the terms of the
3 3 * Common Development and Distribution License ("CDDL"), version 1.0.
4 4 * You may only use this file in accordance with the terms of version
5 5 * 1.0 of the CDDL.
6 6 *
7 7 * A full copy of the text of the CDDL should have accompanied this
8 8 * source. A copy of the CDDL is also available via the Internet at
9 9 * http://www.illumos.org/license/CDDL.
10 10 */
11 11
12 12 /*
13 13 * Copyright 2018 Joyent, Inc.
14 14 */
15 15
16 16 #ifndef _LIBVARPD_SVP_PROT_H
17 17 #define _LIBVARPD_SVP_PROT_H
18 18
19 19 /*
20 20 * SVP protocol Definitions
21 21 */
22 22
23 23 #include <sys/types.h>
24 24 #include <inttypes.h>
25 25 #include <sys/ethernet.h>
26 26 #include <netinet/in.h>
27 27
28 28 #ifdef __cplusplus
29 29 extern "C" {
30 30 #endif
31 31
32 32 /*
33 33 * SDC VXLAN Protocol Definitions
34 34 */
35 35
36 36 #define SVP_VERSION_ONE 1
37 37 #define SVP_VERSION_TWO 2
38 38 /*
39 39 * Bump this to 2. Version 1 SVP is a subset of version 2, and can be
40 40 * determined using an SVP_R_PING as part of connection establishment.
41 41 * Version-2 specific changes will be highlighed (look for "v2").
42 42 */
43 43 #define SVP_CURRENT_VERSION SVP_VERSION_TWO
44 44
45 45 typedef struct svp_req {
46 46 uint16_t svp_ver;
47 47 uint16_t svp_op;
48 48 uint32_t svp_size;
49 49 uint32_t svp_id;
50 50 uint32_t svp_crc32;
51 51 } svp_req_t;
52 52
53 53 /*
54 54 * Unless specified, all message types function identically between v1 and v2
55 55 * of SVP.
56 56 */
|
↓ open down ↓ |
56 lines elided |
↑ open up ↑ |
57 57 typedef enum svp_op {
58 58 SVP_R_UNKNOWN = 0x00,
59 59 SVP_R_PING = 0x01,
60 60 SVP_R_PONG = 0x02,
61 61 SVP_R_VL2_REQ = 0x03,
62 62 SVP_R_VL2_ACK = 0x04,
63 63 SVP_R_VL3_REQ = 0x05,
64 64 SVP_R_VL3_ACK = 0x06,
65 65 SVP_R_BULK_REQ = 0x07,
66 66 SVP_R_BULK_ACK = 0x08,
67 - SVP_R_LOG_REQ = 0x09,
68 - SVP_R_LOG_ACK = 0x0A,
69 - SVP_R_LOG_RM = 0x0B, /* v2 introduces new log type */
70 - SVP_R_LOG_RM_ACK = 0x0C, /* See svp_log_route_t */
67 + SVP_R_LOG_REQ = 0x09, /* v2 introduces new log type */
68 + SVP_R_LOG_ACK = 0x0A, /* See svp_log_route_t */
69 + SVP_R_LOG_RM = 0x0B,
70 + SVP_R_LOG_RM_ACK = 0x0C,
71 71 SVP_R_SHOOTDOWN = 0x0D,
72 72 SVP_R_ROUTE_REQ = 0x0E, /* v2 only */
73 73 SVP_R_ROUTE_ACK = 0x0F /* v2 only */
74 74 } svp_op_t;
75 75
76 76 typedef enum svp_status {
77 77 SVP_S_OK = 0x00, /* Everything OK */
78 78 SVP_S_FATAL = 0x01, /* Fatal error, close connection */
79 79 SVP_S_NOTFOUND = 0x02, /* Entry not found */
80 80 SVP_S_BADL3TYPE = 0x03, /* Unknown svp_vl3_type_t */
81 81 SVP_S_BADBULK = 0x04 /* Unknown svp_bulk_type_t */
82 82 } svp_status_t;
83 83
84 84 /*
85 85 * A client issues the SVP_R_VL2_REQ whenever it needs to perform a VL2->UL3
86 86 * lookup. Requests have the following structure:
87 87 */
88 88 typedef struct svp_vl2_req {
89 89 uint8_t sl2r_mac[ETHERADDRL];
90 90 uint8_t sl2r_pad[2];
91 91 uint32_t sl2r_vnetid;
92 92 } svp_vl2_req_t;
93 93
94 94 /*
95 95 * This is the message a server uses to reply to the SVP_R_VL2_REQ. If the
96 96 * destination on the underlay is an IPv4 address, it should be encoded as an
97 97 * IPv4-mapped IPv6 address.
98 98 */
99 99 typedef struct svp_vl2_ack {
100 100 uint16_t sl2a_status;
101 101 uint16_t sl2a_port;
102 102 uint8_t sl2a_addr[16];
103 103 } svp_vl2_ack_t;
104 104
105 105
106 106 /*
107 107 * A client issues the SVP_R_VL3_REQ request whenever it needs to perform a
108 108 * VL3->VL2 lookup. Note, that this also implicitly performs a VL2->UL3 lookup
109 109 * as well. The sl3r_type member is used to indicate the kind of lookup type
110 110 * that we're performing, eg. is it a L3 or L2.
111 111 */
112 112 typedef enum svp_vl3_type {
113 113 SVP_VL3_IP = 0x01,
114 114 SVP_VL3_IPV6 = 0x02
115 115 } svp_vl3_type_t;
116 116
117 117 typedef struct svp_vl3_req {
118 118 uint8_t sl3r_ip[16];
119 119 uint32_t sl3r_type;
120 120 uint32_t sl3r_vnetid;
121 121 } svp_vl3_req_t;
122 122
123 123 /*
124 124 * This response, corresponding to the SVP_R_VL3_ACK, includes an answer to both
125 125 * the VL3->VL2 and the VL2->UL3 requests.
126 126 */
127 127 typedef struct svp_vl3_ack {
128 128 uint32_t sl3a_status;
129 129 uint8_t sl3a_mac[ETHERADDRL];
130 130 uint16_t sl3a_uport;
131 131 uint8_t sl3a_uip[16];
132 132 } svp_vl3_ack_t;
133 133
134 134 /*
135 135 * SVP_R_BULK_REQ requests a bulk dump of data. Currently we have two kinds of
136 136 * data tables that we need to dump: VL3->VL2 mappings and VL2->UL3 mappings.
137 137 * The kind that we want is indicated using the svbr_type member.
138 138 */
139 139 typedef enum svp_bulk_type {
140 140 SVP_BULK_VL2 = 0x01,
141 141 SVP_BULK_VL3 = 0x02
142 142 } svp_bulk_type_t;
143 143
144 144 typedef struct svp_bulk_req {
145 145 uint32_t svbr_type;
146 146 } svp_bulk_req_t;
147 147
148 148 /*
149 149 * When replying to a bulk request (SVP_R_BULK_ACK), data is streamed back
150 150 * across. The format of the data is currently undefined and as we work on the
151 151 * system, we'll get a better understanding of what this should look like. A
152 152 * client may need to stream such a request to disk, or the format will need to
153 153 * be in a streamable format that allows the client to construct data.
154 154 */
155 155 typedef struct svp_bulk_ack {
156 156 uint32_t svba_status;
157 157 uint32_t svba_type;
158 158 uint8_t svba_data[];
159 159 } svp_bulk_ack_t;
160 160
161 161 /*
162 162 * SVP_R_LOG_REQ requests a log entries from the specified log from the server.
163 163 * The total number of bytes that the user is ready to receive is in svlr_count.
164 164 * However, the server should not block for data if none is available and thus
165 165 * may return less than svlr_count bytes back. We identify the IP address of the
166 166 * underlay to use here explicitly.
167 167 */
168 168 typedef struct svp_log_req {
169 169 uint32_t svlr_count;
170 170 uint8_t svlr_ip[16];
171 171 } svp_log_req_t;
172 172
173 173 /*
174 174 * The server replies to a log request by sending a series of log entries.
175 175 * These log entries may be a mixture of both vl2 and vl3 records. The reply is
176 176 * a stream of bytes after the status message whose length is determined baseed
177 177 * on the header itself. Each entry begins with a uint32_t that describes its
178 178 * type and then is followed by the remaining data payload. The next entry
179 179 * follows immediately which again begins with the uint32_t word that describes
180 180 * what it should be.
181 181 */
182 182 typedef enum svp_log_type {
183 183 SVP_LOG_VL2 = 0x01,
184 184 SVP_LOG_VL3 = 0x02,
185 185 SVP_LOG_ROUTE = 0x03 /* v2 only */
186 186 } svp_log_type_t;
187 187
188 188 typedef struct svp_log_vl2 {
189 189 uint32_t svl2_type; /* Should be SVP_LOG_VL2 */
190 190 uint8_t svl2_id[16]; /* 16-byte UUID */
191 191 uint8_t svl2_mac[ETHERADDRL];
192 192 uint8_t svl2_pad[2];
193 193 uint32_t svl2_vnetid;
194 194 } svp_log_vl2_t;
195 195
196 196 typedef struct svp_log_vl3 {
197 197 uint32_t svl3_type; /* Should be SVP_LOG_VL3 */
198 198 uint8_t svl3_id[16]; /* 16-byte UUID */
199 199 uint8_t svl3_ip[16];
200 200 uint8_t svl3_pad[2];
201 201 uint16_t svl3_vlan;
202 202 uint32_t svl3_vnetid;
203 203 } svp_log_vl3_t;
204 204
205 205 /*
206 206 * This log entry only appears on v2 connections.
207 207 */
208 208 typedef struct svp_log_route {
209 209 uint32_t svlr_type; /* Should be SVP_LOG_ROUTE */
210 210 uint8_t svlr_id[16]; /* 16-byte UUID */
211 211 uint32_t svlr_src_vnetid; /* Source VXLAN vnetid. */
212 212 uint32_t svlr_dst_vnetid; /* Dest. VXLAN vnetid. */
213 213 uint32_t svlr_dcid; /* Remote/dest Data Center ID. */
214 214 uint8_t svlr_srcip[16]; /* Source IP address base. */
215 215 uint8_t svlr_dstip[16]; /* Destination IP address base. */
216 216 uint16_t svlr_dst_vlan; /* Source VLAN id. */
217 217 uint16_t svlr_src_vlan; /* Destination VLAN id. */
218 218 uint8_t svlr_src_prefixlen; /* Source IP prefix length. */
219 219 uint8_t svlr_dst_prefixlen; /* Dest. IP prefix length. */
220 220 uint16_t svlr_pad; /* So we can be aligned... */
221 221 } svp_log_route_t;
222 222
223 223 typedef struct svp_log_ack {
224 224 uint32_t svla_status;
225 225 uint8_t svla_data[];
226 226 } svp_log_ack_t;
227 227
228 228 /*
229 229 * SVP_R_LOG_RM is used after the client successfully processes a series of the
230 230 * log stream. It replies to tell the server that it can remove those IDs from
231 231 * processing. The IDs used are the same IDs that were in the individual
232 232 * SVP_R_LOG_ACK entries.
233 233 */
234 234 typedef struct svp_lrm_req {
235 235 uint32_t svrr_count;
236 236 uint8_t svrr_ids[];
237 237 } svp_lrm_req_t;
238 238
239 239 /*
240 240 * SVP_R_LOG_RM_ACK is used to indicate that a log entry has been successfully
241 241 * deleted and at this point it makes sense to go and ask for another
242 242 * SVP_R_LOG_REQ.
243 243 */
244 244 typedef struct svp_lrm_ack {
245 245 uint32_t svra_status;
246 246 } svp_lrm_ack_t;
247 247
248 248 /*
249 249 * A shootdown (SVP_R_SHOOTDOWN) is used by a CN to reply to another CN that it
250 250 * sent an invalid entry that could not be processed. This should be a
251 251 * relatively infrequent occurrence. Unlike the rest of the messages, there is
252 252 * no reply to it. It's a single request to try and help get us out there. When
253 253 * a node receives this, it will issue a conditional revocation ioctl, that
254 254 * removes the entry if and only if, it matches the IP. That way if we've
255 255 * already gotten an updated entry for this, we don't remove it again.
256 256 */
257 257 typedef struct svp_shootdown {
258 258 uint8_t svsd_mac[ETHERADDRL];
259 259 uint8_t svsd_pad[2];
260 260 uint32_t svsd_vnetid;
261 261 } svp_shootdown_t;
262 262
263 263 /*
264 264 * A route-request (SVP_R_ROUTE_REQ) queries the local SVP server to get a
265 265 * far-remote (i.e. another Triton Data Center, nee. SDC) SVP server for
266 266 * far-remote networks. Modern overlay modules will request IP destinations
267 267 * for remote-Triton networks, but they must know how to reach the
268 268 * remote-Triton SVP server.
269 269 *
270 270 * NOTE: SVP_R_ROUTE_{REQ,ACK} are only present in SVP v2.
271 271 */
272 272 typedef struct svp_route_req {
273 273 uint32_t srr_vnetid; /* Requester's vnet ID. */
274 274 uint16_t srr_vlan; /* Requester's VLAN ID. */
275 275 uint16_t srr_pad; /* Zero on xmit, ignore on receipt. */
276 276 uint8_t srr_srcip[16]; /* VL3 Source IP. */
277 277 uint8_t srr_dstip[16]; /* VL3 Destination IP. */
278 278 } svp_route_req_t;
279 279
280 280 /*
281 281 * The far-remote Triton Data Center will answer with the requisite information
282 282 * to send overlay packets to the appropriate far-remote CNs.
283 283 */
284 284 typedef struct svp_route_ack {
285 285 uint32_t sra_status; /* Status. */
286 286 uint32_t sra_dcid; /* Far-remote Data Center ID. */
287 287 uint32_t sra_vnetid; /* Far-remote vnet ID. */
288 288 uint16_t sra_vlan; /* Far-remote VLAN ID. */
289 289 uint16_t sra_port; /* Destination UL3 port. */
290 290 uint8_t sra_ip[16]; /* Destination UL3 address. */
291 291 uint8_t sra_srcmac[ETHERADDRL]; /* Far-remote VL2 source. */
292 292 uint8_t sra_dstmac[ETHERADDRL]; /* Far-remote VL2 dest. */
293 293 uint8_t sra_src_pfx; /* Far-remote VL3 source prefix */
294 294 uint8_t sra_dst_pfx; /* Far-remote VL3 dest. prefix */
295 295 } svp_route_ack_t;
296 296
297 297 #ifdef __cplusplus
298 298 }
299 299 #endif
300 300
301 301 #endif /* _LIBVARPD_SVP_PROT_H */
|
↓ open down ↓ |
221 lines elided |
↑ open up ↑ |
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX