RE: session re-instatement
Title: session re-instatement
Section 5.3.5 [RFC3720] para 2 states:
The initiator session state MUST be FAILED (Section 7.3
Session State Diagrams) when the
initiator attempts a session reinstatement.
In your scenario the initiator violates this rule since
both are in state FREE (Q1).
The part of your question explores what happens at the
target if this scenario does occur.
The connection and session state machines for the target
show that the session begins life in the ACTIVE state (Q2) when the login phase
of the leading connection starts (S4). Once the leading connection transits (T5)
to LOGGED_IN (S5), the session performs the equivalent transit (N2) to
In your scenario, there are two new sessions in ACTIVE
state, racing towards LOGGED_IN. A sensible target implementation waits until a
connection makes the T5 transition (corresponding to the session's N2
transition) before enacting the session reinstatement action. Afterall, it
would be a shame to nuke a potentially viable session with a dodgy login
Some sort of implementation-specific mutual exclusion
mechanism must be used on the target to ensure only one party manipulates the
session state. Hence one connection reaches the T5 transition point and runs the
session reinstatement algorithm.
At this point the other session is in Q2 and its connection
is in S4 (albeit on the cusp of its transition). While not listed as a T7
reason, I'd think a resilient target would take that action on the connection.
The session would make the N9 transition (again, not explicitly listed as a
reason, but follows as a consequence of the T7
In other words, the first one to reach full feature phase
survives and the other gets trashed. Sound
Is there any text in RFC 3720 or the implementer's
guide that prevents an initiator from simultaneously logging-in on two
connections to the same target portal using the same InitiatorName, ISID, and
TSIH=0? If the logins were done sequentially, the second login would
re-instate the session created by the first login, but I can see how a target
might not do session re-instatement if the sessions are being created
Ips mailing list