Session ID: When a cache server is started, it generates a Session
ID to identify the instance of the cache and to bind it to the
sequence of Serial Numbers that cache instance will generate.
This allows the router to restart a failed session knowing that
the Serial Number it is using is commensurate with that of the
cache. If, at any time, either the router or the cache finds the
value of the session identifier is not the same as the other's,
they MUST completely drop the session and the router MUST flush
all data learned from that cache.
Should a cache erroneously reuse a Session ID so that a router
does not realize that the session has changed (old session ID and
new session ID have same numeric value), the router may become
confused as to the content of the cache. The time it takes the
router to discover it is confused will depend on whether the
Serial Numbers are also reused. If the Serial Numbers in the old
and new sessions are different enough, the cache will respond to
the router's Serial Query with a Cache Reset, which will solve the
problem. If, however, the Serial Numbers are close, the cache may
respond with a Cache Response, which may not be enough to bring
the router into sync. In such cases, it's likely but not certain
that the router will detect some discrepancy between the state
that the cache expects and its own state. For example, the Cache
Response may tell the router to drop a record that the router does
not hold, or may tell the router to add a record that the router
already has. In such cases, a router will detect the error and
reset the session. The one case in which the router may stay out
of sync is when nothing in the Cache Response contradicts any data
currently held by the router.
Using persistent storage for the session identifier or a clock-
based scheme for generating session identifiers should avoid the
risk of session identifier collisions.
The Session ID might be a pseudo-random value, a strictly
increasing value if the cache has reliable storage, etc.
Fort's session ID initialization is random, and serial always starts at zero. This isn't terrible; session collision is very unlikely, and even if it does happen, the router's serial will probably end up being larger than Fort's, which will trigger a reset.
But the collision probability could be reduced further by employing the RFC's suggested persistent storage scheme.
RFC 6810:
Fort's session ID initialization is random, and serial always starts at zero. This isn't terrible; session collision is very unlikely, and even if it does happen, the router's serial will probably end up being larger than Fort's, which will trigger a reset.
But the collision probability could be reduced further by employing the RFC's suggested persistent storage scheme.