... | ... | @@ -21,7 +21,7 @@ The lease offered by the backend is available for allocation from the backend's |
|
|
|
|
|
# Backends Compatibility
|
|
|
|
|
|
The concepts described in this design will have to be implemented for different lease database backends. Due to the complexity of the allocation engine and variety of lease database backends supported by Kea, it is impractical to implement BALS for all backends at once or even within a single Kea release. The likely approach is to start with the Memfile backend, then MySQL and PostgreSQL. Support for BALS in Cassandra may never be added or will be added at the very end. Therefore, we must assume the coexistence of the BALS and the current lease selection strategy using the `IterativeAllocator`.
|
|
|
The concepts described in this design will have to be implemented for different lease database backends. Due to the complexity of the allocation engine and variety of lease database backends supported by Kea, it is impractical to implement BALS for all backends at once or even within a single Kea release. The likely approach is to start with the Memfile backend, then MySQL and PostgreSQL. Support for BALS in Cassandra may never be added or will be added at the very end. Therefore, we must assume the coexistence of the BALS and the current lease selection strategy using the `IterativeAllocator`.
|
|
|
|
|
|
In order to take advantage of the existing allocation engine code and keep the required changes at minimum, this design proposes that new allocator is created (in addition to the existing `IterativeAllocator`) which will support BALS. This allocator will be similar to the `IterativeAllocator`, but instead of walking over the addresses in the address pool it will make calls to the lease backend to get the next available address.
|
|
|
|
... | ... | @@ -53,7 +53,7 @@ The last 3 strategies will be provided by the BALS allocator, i.e. when any of t |
|
|
"lease-pre-allocation": false
|
|
|
},
|
|
|
{
|
|
|
"name": "ivy",
|
|
|
"name": "ivy",
|
|
|
}
|
|
|
]
|
|
|
}
|
... | ... | @@ -85,7 +85,7 @@ const uint8_t LEASE SELECTION_ALL = 0x07; |
|
|
|
|
|
The `preallocateLeases4` and `preallocateLeases6` functions are to be triggered upon the server's first configuration, reconfiguration or configuration update for individual address pools for which preallocation should take place. As a result, the backend specific implementations will create appropriate lease entries to mark those that are available.
|
|
|
|
|
|
The remaining functions are used by the allocation engine to get the next available lease of a given type for a given pool. The pool is specified as a pair of IP addresses denoting the beginning and the end of the pool.
|
|
|
The remaining functions are used by the allocation engine to get the next available lease of a given type for a given pool. The pool is specified as a pair of IP addresses denoting the beginning and the end of the pool.
|
|
|
|
|
|
The third argument is a counter of attempts made to get an available address for a given client/packet. It should be set to 0 upon the first attempt and incremented when the offered address is rejected by the allocation engine and another attempt is made.
|
|
|
|
... | ... | @@ -206,7 +206,7 @@ where `3221226082` is the integer representation of the last IP address returned |
|
|
This is the example order in which the addresses from the 192.0.2.10 to 192.0.2.100 are returned for such hashing algorithm:
|
|
|
|
|
|
```
|
|
|
address
|
|
|
address
|
|
|
-------------
|
|
|
192.0.2.71
|
|
|
192.0.2.91
|
... | ... | |