Print this page
Restore SVP_R_ROUTE_REQ, and all that goes with it.
Interpret sl3a_uport == 0 in SVP_R_VL3_ACK to indicate the VL3 IP is a next-hop router.
| 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 /* XXX KEBE SAYS -- we are not yet ready to bump this. */
39 39 #define SVP_CURRENT_VERSION SVP_VERSION_ONE
40 40
41 41 typedef struct svp_req {
42 42 uint16_t svp_ver;
43 43 uint16_t svp_op;
44 44 uint32_t svp_size;
45 45 uint32_t svp_id;
46 46 uint32_t svp_crc32;
47 47 } svp_req_t;
48 48
49 49 typedef enum svp_op {
50 50 SVP_R_UNKNOWN = 0x00,
51 51 SVP_R_PING = 0x01,
52 52 SVP_R_PONG = 0x02,
53 53 SVP_R_VL2_REQ = 0x03,
|
↓ open down ↓ |
53 lines elided |
↑ open up ↑ |
54 54 SVP_R_VL2_ACK = 0x04,
55 55 SVP_R_VL3_REQ = 0x05,
56 56 SVP_R_VL3_ACK = 0x06,
57 57 SVP_R_BULK_REQ = 0x07,
58 58 SVP_R_BULK_ACK = 0x08,
59 59 SVP_R_LOG_REQ = 0x09,
60 60 SVP_R_LOG_ACK = 0x0A,
61 61 SVP_R_LOG_RM = 0x0B,
62 62 SVP_R_LOG_RM_ACK = 0x0C,
63 63 SVP_R_SHOOTDOWN = 0x0D,
64 - SVP_R_REMOTE_VL3_REQ = 0x0E,
65 - SVP_R_REMOTE_VL3_ACK = 0x0F
64 + SVP_R_ROUTE_REQ = 0x0E,
65 + SVP_R_ROUTE_ACK = 0x0F
66 66 } svp_op_t;
67 67
68 68 typedef enum svp_status {
69 69 SVP_S_OK = 0x00, /* Everything OK */
70 70 SVP_S_FATAL = 0x01, /* Fatal error, close connection */
71 71 SVP_S_NOTFOUND = 0x02, /* Entry not found */
72 72 SVP_S_BADL3TYPE = 0x03, /* Unknown svp_vl3_type_t */
73 73 SVP_S_BADBULK = 0x04 /* Unknown svp_bulk_type_t */
74 74 } svp_status_t;
75 75
76 76 /*
77 - * A client issues the SVP_R_VL2_REQ whenever it needs to perform a VLS->UL3
77 + * A client issues the SVP_R_VL2_REQ whenever it needs to perform a VL2->UL3
78 78 * lookup. Requests have the following structure:
79 79 */
80 80 typedef struct svp_vl2_req {
81 81 uint8_t sl2r_mac[ETHERADDRL];
82 82 uint8_t sl2r_pad[2];
83 83 uint32_t sl2r_vnetid;
84 84 } svp_vl2_req_t;
85 85
86 86 /*
87 87 * This is the message a server uses to reply to the SVP_R_VL2_REQ. If the
88 88 * destination on the underlay is an IPv4 address, it should be encoded as an
89 89 * IPv4-mapped IPv6 address.
90 90 */
91 91 typedef struct svp_vl2_ack {
92 92 uint16_t sl2a_status;
93 93 uint16_t sl2a_port;
94 94 uint8_t sl2a_addr[16];
95 95 } svp_vl2_ack_t;
96 96
97 97
98 98 /*
99 99 * A client issues the SVP_R_VL3_REQ request whenever it needs to perform a
100 100 * VL3->VL2 lookup. Note, that this also implicitly performs a VL2->UL3 lookup
101 101 * as well. The sl3r_type member is used to indicate the kind of lookup type
102 102 * that we're performing, eg. is it a L3 or L2.
103 103 */
104 104 typedef enum svp_vl3_type {
105 105 SVP_VL3_IP = 0x01,
106 106 SVP_VL3_IPV6 = 0x02
107 107 } svp_vl3_type_t;
108 108
109 109 typedef struct svp_vl3_req {
110 110 uint8_t sl3r_ip[16];
111 111 uint32_t sl3r_type;
112 112 uint32_t sl3r_vnetid;
113 113 } svp_vl3_req_t;
114 114
115 115 /*
116 116 * This response, corresponding to the SVP_R_VL3_ACK, includes an answer to both
|
↓ open down ↓ |
29 lines elided |
↑ open up ↑ |
117 117 * the VL3->VL2 and the VL2->UL3 requests.
118 118 */
119 119 typedef struct svp_vl3_ack {
120 120 uint32_t sl3a_status;
121 121 uint8_t sl3a_mac[ETHERADDRL];
122 122 uint16_t sl3a_uport;
123 123 uint8_t sl3a_uip[16];
124 124 } svp_vl3_ack_t;
125 125
126 126 /*
127 - * A client issues the SVP_R_REMOTE_VL3_REQ for a far-remote (cross-DC) VL3 IP
128 - * address. The server may take longer because it may query cross-DC to get
129 - * the answer for our response.
130 - */
131 -typedef struct svp_rvl3_req {
132 - uint8_t srl3r_srcip[16];
133 - uint8_t srl3r_dstip[16];
134 - uint32_t srl3r_type; /* Same as SVP_R_VL3_REQ */
135 - uint32_t srl3r_vnetid;
136 - uint16_t srl3r_vlan;
137 - uint16_t srl3r_pad; /* XXX KEBE ASKS, necessary? */
138 -} svp_rvl3_req_t;
139 -
140 -/*
141 - * The remote-VL3 response contains more than the regular VL3 one, because
142 - * overlay needs to rewrite the MAC header completely.
143 - */
144 -typedef struct svp_rvl3_ack {
145 - uint32_t srl3a_status;
146 - uint8_t srl3a_dstmac[ETHERADDRL]; /* MAC of the target. */
147 - uint8_t srl3a_srcmac[ETHERADDRL]; /* MAC of the target's rtr */
148 - uint16_t srl3a_vlanid;
149 - uint16_t srl3a_uport;
150 - uint32_t srl3a_dcid; /* Remote Data Center ID. */
151 - uint8_t srl3a_uip[16];
152 -} svp_rvl3_ack_t;
153 -
154 -/*
155 127 * SVP_R_BULK_REQ requests a bulk dump of data. Currently we have two kinds of
156 128 * data tables that we need to dump: VL3->VL2 mappings and VL2->UL3 mappings.
157 129 * The kind that we want is indicated using the svbr_type member.
158 130 */
159 131 typedef enum svp_bulk_type {
160 132 SVP_BULK_VL2 = 0x01,
161 133 SVP_BULK_VL3 = 0x02
162 134 } svp_bulk_type_t;
163 135
164 136 typedef struct svp_bulk_req {
165 137 uint32_t svbr_type;
166 138 } svp_bulk_req_t;
167 139
168 140 /*
169 141 * When replying to a bulk request (SVP_R_BULK_ACK), data is streamed back
170 142 * across. The format of the data is currently undefined and as we work on the
171 143 * system, we'll get a better understanding of what this should look like. A
172 144 * client may need to stream such a request to disk, or the format will need to
173 145 * be in a streamable format that allows the client to construct data.
174 146 */
175 147 typedef struct svp_bulk_ack {
176 148 uint32_t svba_status;
177 149 uint32_t svba_type;
178 150 uint8_t svba_data[];
179 151 } svp_bulk_ack_t;
180 152
181 153 /*
182 154 * SVP_R_LOG_REQ requests a log entries from the specified log from the server.
183 155 * The total number of bytes that the user is ready to receive is in svlr_count.
184 156 * However, the server should not block for data if none is available and thus
185 157 * may return less than svlr_count bytes back. We identify the IP address of the
186 158 * underlay to use here explicitly.
187 159 */
188 160 typedef struct svp_log_req {
189 161 uint32_t svlr_count;
190 162 uint8_t svlr_ip[16];
191 163 } svp_log_req_t;
192 164
193 165 /*
194 166 * The server replies to a log request by sending a series of log entries.
195 167 * These log entries may be a mixture of both vl2 and vl3 records. The reply is
196 168 * a stream of bytes after the status message whose length is determined baseed
197 169 * on the header itself. Each entry begins with a uint32_t that describes its
198 170 * type and then is followed by the remaining data payload. The next entry
199 171 * follows immediately which again begins with the uint32_t word that describes
200 172 * what it should be.
201 173 */
202 174 typedef enum svp_log_type {
203 175 SVP_LOG_VL2 = 0x01,
204 176 SVP_LOG_VL3 = 0x02
205 177 } svp_log_type_t;
206 178
207 179 typedef struct svp_log_vl2 {
208 180 uint32_t svl2_type; /* Should be SVP_LOG_VL2 */
209 181 uint8_t svl2_id[16]; /* 16-byte UUID */
210 182 uint8_t svl2_mac[ETHERADDRL];
211 183 uint8_t svl2_pad[2];
212 184 uint32_t svl2_vnetid;
213 185 } svp_log_vl2_t;
214 186
215 187 typedef struct svp_log_vl3 {
216 188 uint32_t svl3_type; /* Should be SVP_LOG_VL3 */
217 189 uint8_t svl3_id[16]; /* 16-byte UUID */
218 190 uint8_t svl3_ip[16];
219 191 uint8_t svl3_pad[2];
220 192 uint16_t svl3_vlan;
221 193 uint32_t svl3_vnetid;
222 194 } svp_log_vl3_t;
223 195
224 196 typedef struct svp_log_ack {
225 197 uint32_t svla_status;
226 198 uint8_t svla_data[];
227 199 } svp_log_ack_t;
228 200
229 201 /*
230 202 * SVP_R_LOG_RM is used after the client successfully processes a series of the
231 203 * log stream. It replies to tell the server that it can remove those IDs from
232 204 * processing. The IDs used are the same IDs that were in the individual
233 205 * SVP_R_LOG_ACK entries.
234 206 */
235 207 typedef struct svp_lrm_req {
236 208 uint32_t svrr_count;
237 209 uint8_t svrr_ids[];
238 210 } svp_lrm_req_t;
239 211
240 212 /*
241 213 * SVP_R_LOG_RM_ACK is used to indicate that a log entry has been successfully
242 214 * deleted and at this point it makes sense to go and ask for another
243 215 * SVP_R_LOG_REQ.
244 216 */
245 217 typedef struct svp_lrm_ack {
246 218 uint32_t svra_status;
247 219 } svp_lrm_ack_t;
248 220
249 221 /*
250 222 * A shootdown (SVP_R_SHOOTDOWN) is used by a CN to reply to another CN that it
251 223 * sent an invalid entry that could not be processed. This should be a
252 224 * relatively infrequent occurrence. Unlike the rest of the messages, there is
253 225 * no reply to it. It's a single request to try and help get us out there. When
|
↓ open down ↓ |
89 lines elided |
↑ open up ↑ |
254 226 * a node receives this, it will issue a conditional revocation ioctl, that
255 227 * removes the entry if and only if, it matches the IP. That way if we've
256 228 * already gotten an updated entry for this, we don't remove it again.
257 229 */
258 230 typedef struct svp_shootdown {
259 231 uint8_t svsd_mac[ETHERADDRL];
260 232 uint8_t svsd_pad[2];
261 233 uint32_t svsd_vnetid;
262 234 } svp_shootdown_t;
263 235
236 +/*
237 + * A route-request (SVP_R_ROUTE_REQ) queries the local SVP server to get a
238 + * far-remote (i.e. another Triton Data Center, nee. SDC) SVP server for
239 + * far-remote networks. Modern overlay modules will request IP destinations
240 + * for remote-Triton networks, but they must know how to reach the
241 + * remote-Triton SVP server.
242 + */
243 +typedef struct svp_route_req {
244 + uint32_t srr_vnetid; /* Requester's vnet ID. */
245 + uint16_t srr_vlan; /* Requester's VLAN ID. */
246 + uint16_t srr_pad; /* Zero on xmit, ignore on receipt. */
247 + uint8_t srr_srcip[16]; /* VL3 Source IP. */
248 + uint8_t srr_dstip[16]; /* VL3 Destination IP. */
249 +} svp_route_req_t;
250 +
251 +/*
252 + * The far-remote Triton Data Center will answer with the requisite information
253 + * to send overlay packets to the appropriate far-remote CNs.
254 + */
255 +typedef struct svp_route_ack {
256 + uint32_t sra_status; /* Status. */
257 + uint32_t sra_dcid; /* Far-remote Data Center ID. */
258 + uint32_t sra_vnetid; /* Far-remote vnet ID. */
259 + uint16_t sra_vlan; /* Far-remote VLAN ID. */
260 + uint16_t sra_port; /* Destination UL3 port. */
261 + uint8_t sra_ip[16]; /* Destination UL3 address. */
262 + uint8_t sra_srcmac[ETHERADDRL]; /* Far-remote VL2 source. */
263 + uint8_t sra_dstmac[ETHERADDRL]; /* Far-remote VL2 dest. */
264 + uint8_t sra_src_pfx; /* Far-remote VL3 source prefix */
265 + uint8_t sra_dst_pfx; /* Far-remote VL3 dest. prefix */
266 +} svp_route_ack_t;
267 +
264 268 #ifdef __cplusplus
265 269 }
266 270 #endif
267 271
268 272 #endif /* _LIBVARPD_SVP_PROT_H */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX