Subscriber host identification through LUDB is performed upon the arrival of the incoming DHCP messages on both, the access and the network side, while the host instantiation and ESM string assignment is performed only during the processing of the DHCP ACK/Reply messages. In other words, if Python without the caching is used for subscriber host identification and classification (into the correct service class by means of deriving ESM strings), the DHCP options required for host identification must be present in all DHCP messages, even the ones sent by the DHCP servers. However, DHCP servers are not required to echo DHCP options sent by the clients and relay-agents. Consequently, the missing options from the server side would cause the subscriber host instantiation to fail.
To remedy this situation and cover all deployments models (even the ones where the DHCP options are not echoed back by the DHCP servers), a caching mechanism is introduced whereby the results of the Python processing on ingress access are locally stored in 7750 SR and 7450 ESS. This ensures that the information about the subscriber host is readily available when the DHCP packet from the DHCP server arrives. Furthermore, because we already have the cached information, no additional Python processing on the network ingress is needed.
The caching is performed in a DHCP Transaction Cache (DTC), which is accessible to Python and to the ESM module. Python writes the result of its processing to it and the Enhanced Subscriber Management (ESM) module within 7750 SR and 7450 ESS can access those results.
The cache entries are relatively short lived, with the lifetime of a DHCP transaction. DHCP transaction is defined as a pair of DHCP messages that have the same DHCP transaction ID number (<Discover, Offer>, <Request, Ack>, <Solicit, Advertise>, <Request, Reply>, <Renew, Ack>, and so on).