|
|
# High Level Design
|
|
|
|
|
|
This section covers the high level design of Bulk LeaseQuery (BLQ) for both DHPCv4 and DHCPv6, as described by [RFC 6926](https://www.rfc-editor.org/rfc/rfc6926) and [RFC 5460](https://www.rfc-editor.org/rfc/rfc5460.html) respectively. Please refer to and post comments on issue #2468.
|
|
|
This section covers the high level design of Bulk LeaseQuery (BLQ) for both DHPCv4 and DHCPv6, as described by [RFC 6926](https://www.rfc-editor.org/rfc/rfc6926) and [RFC 5460](https://www.rfc-editor.org/rfc/rfc5460.html) respectively. Please refer to and post comments on issue #2468.
|
|
|
|
|
|
## Overview
|
|
|
|
|
|
Bulk LeaseQuery support will be added to the existing LeaseQuery hook and anticipates future extension to support Active LeaseQuery (ALQ). In addition to the query types specific to Bulk LeaseQuery, requestors can all also for all of the query types provided under Basic LeaseQuery, therefore much of the query processing aspects of Basic LeaseQuery implementation will be reused, but will require refactoring to make it more broadly accessible.
|
|
|
Bulk LeaseQuery support will be added to the existing LeaseQuery hook and anticipates future extension to support Active LeaseQuery (ALQ). In addition to the query types specific to Bulk LeaseQuery, requestors can all also for all of the query types provided under Basic LeaseQuery, therefore much of the query processing aspects of Basic LeaseQuery implementation will be reused, but will require refactoring to make it more broadly accessible.
|
|
|
|
|
|
Running Bulk LeaseQuery will require Kea to be configured in MT mode. BLQ would have significant performance impacts on single-threaded configurations and thus it will not be supported. This should simplify the design as well as the implementation. The LeaseQuery hook library will verify the MT is enabled if BLQ is enabled.
|
|
|
|
... | ... | @@ -30,7 +30,7 @@ Unlike normal DHCP or our current REST API traffic, Bulk LeaseQuery is not a typ |
|
|
|
|
|
This design will treat inbound data as a stream of DHCP query requests, each with a unique XID, and where individual TCP packets are simple freight containers conveying them rather than the request half of a transaction. The same perspective will applied to the outbound responses, they will be a stream of bindings and status responses (e.g. LEASEQUERYDONE) each tagged with corresponding XID.
|
|
|
|
|
|
The design introduces a new class, LeaseQueryListener, which will support multiple, concurrent TCP connections, one connection per requester, one thread per connection. It will be very similar to and reuse much of the class hierarchy as CmdHttpListener, including TLS support. While a good deal the existing class hierarchy topped by CmdHttpListener can be used, at least as a model for the higher order functions, the HttpConnection::Transaction and the logic using it is not quite the right fit. It is intended to read a single HTTP request that generates a single HTTP response,though in theory, either can span multiple packets. The requisite functions will need to modified accordingly (e.g. doRead(), socketReadCallback()).
|
|
|
The design introduces a new class, LeaseQueryListener, which will support multiple, concurrent TCP connections, one connection per requester, one thread per connection. It will reuse (either by copy or maybe refactoring into base classes) much of the class hierarchy as CmdHttpListener, including TLS support. While a good deal the existing class hierarchy topped by CmdHttpListener can be used, at least as a model for the higher order functions, the HttpConnection::Transaction and the logic using it is not quite the right fit. It is intended to read a single HTTP request that generates a single HTTP response,though in theory, either can span multiple packets. The requisite functions will need to modified accordingly (e.g. doRead(), socketReadCallback()).
|
|
|
|
|
|
We can follow the pattern used by LeaseMgr::LeaseStatsQuery to create BulkLeaseQuery class. This class will will be used for starting a new bulk query and fetching its results. Each lease store will implement its own derivations, and in this way, isolate lease store specifics.
|
|
|
|
... | ... | @@ -389,6 +389,7 @@ if (last_sent < pool_end) { |
|
|
}
|
|
|
}
|
|
|
```
|
|
|
|
|
|
Note the above is intended to suggest a possible direction, producing the full set of free addresses is a more involved that depicted. The algorithm above would not produce entries for pools that have no allocated addresses. Those would need to be back-filled probably by tracking the pools that are fulfilled by the above algorithm and then producing free leases for all unrepresented pools.
|
|
|
|
|
|
There is also some questions as to how to treat host reservations for fixed addresses. Those that are in-pool but without a lease would be sent back as free by extrapolation. Technically accurate in terms of lease state but functionally it is only available to a single client. For out-of-pool addresses without leases, we would send back nothing without doing some sort of explicit search for them.
|
... | ... | @@ -587,6 +588,4 @@ A very preliminary task break down is shown below: |
|
|
3.1 Add callouts as needed
|
|
|
3.2 Extend configuration parsing
|
|
|
3.4 Instantiate LeaseQueryListener (when enabled)
|
|
|
```
|
|
|
|
|
|
|
|
|
``` |
|
|
\ No newline at end of file |