NAME

  RestartModeE.seq - Handle a COOKIE ECHO when a TCB exists (Case E)


PURPOSE

  To check that if COOKIE ECHO chunk is received when a TCB exists in mode E
  then the endpoint silent discard the COOKIE-ECHO chunk.


SYNOPSIS

  ./RestartModeE.seq [-tooloption ...] -pkt ./RestartModeE.def
    -tooloption : v6eval tool option
  See Also: ../common/STD_PKT_COMMON.def
            ../common/SCTP_COMMON.def


PRE-TEST CONDITION

  Association not established between endpoint A and B. Also arrange the
  data in endpoint A such that upper layers send Associate primitive to
  startup an association with endpoint B.


TEST PROCEDURE

  Endpoint A                           Endpoint B                ULP
  (ESTABLISHED)                        (ESTABLISHED)
  INIT          ----------------->
                <-----------------      INIT-ACK
  COOKIE-ECHO   ----------------->
                <-----------------      COOKIE-ACK
                                         Communication Up ---------->
  INIT          ----------------->
                <-----------------      INIT-ACK
  COOKIE-ECHO   ----------------->      Silently discarded
  TEST DESCRIPTION:
  1. Try to send a COOKIE-ECHO message when a TCB exists from
     endpoint A to B.
  2. Check A: COOKIE-ECHO message is silently discarded.


NOTE

  None


REFERENCE

  RFC 4960
  5.2.4.  Handle a COOKIE ECHO when a TCB Exists
    5)  Refer to Table 2 to determine the correct action to be taken.
    +------------+------------+---------------+--------------+-------------+
    |  Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag|   Action/   |
    |            |            |               |              | Description |
    +------------+------------+---------------+--------------+-------------+
    |    X       |     X      |      M        |      M       |     (A)     |
    +------------+------------+---------------+--------------+-------------+
    |    M       |     X      |      A        |      A       |     (B)     |
    +------------+------------+---------------+--------------+-------------+
    |    M       |     0      |      A        |      A       |     (B)     |
    +------------+------------+---------------+--------------+-------------+
    |    X       |     M      |      0        |      0       |     (C)     |
    +------------+------------+---------------+--------------+-------------+
    |    M       |     M      |      A        |      A       |     (D)     |
    +======================================================================+
    |       Table 2: Handling of a COOKIE ECHO when a TCB Exists           |
    +======================================================================+
    Legend:
      X - Tag does not match the existing TCB.
      M - Tag matches the existing TCB.
      0 - No Tie-Tag in cookie (unknown).
      A - All cases, i.e., M, X, or 0.
    Note: For any case not shown in Table 2, the cookie should be
    silently discarded.
    Action
    A) In this case, the peer may have restarted.  When the endpoint
       recognizes this potential 'restart', the existing session is
       treated the same as if it received an ABORT followed by a new
       COOKIE ECHO with the following exceptions:
       -  Any SCTP DATA chunks MAY be retained (this is an
          implementation-specific option).
       -  A notification of RESTART SHOULD be sent to the ULP instead of
          a "COMMUNICATION LOST" notification.
       All the congestion control parameters (e.g., cwnd, ssthresh)
       related to this peer MUST be reset to their initial values (see
       Section 6.2.1).
       After this, the endpoint shall enter the ESTABLISHED state.
       If the endpoint is in the SHUTDOWN-ACK-SENT state and recognizes
       that the peer has restarted (Action A), it MUST NOT set up a new
       association but instead resend the SHUTDOWN ACK and send an ERROR
       chunk with a "Cookie Received While Shutting Down" error cause to
       its peer.
    B) In this case, both sides may be attempting to start an association
       at about the same time, but the peer endpoint started its INIT
       after responding to the local endpoint's INIT.  Thus, it may have
       picked a new Verification Tag, not being aware of the previous tag
       it had sent this endpoint.  The endpoint should stay in or enter
       the ESTABLISHED state, but it MUST update its peer's Verification
       Tag from the State Cookie, stop any init or cookie timers that may
       be running, and send a COOKIE ACK.
    C) In this case, the local endpoint's cookie has arrived late.
       Before it arrived, the local endpoint sent an INIT and received an
       INIT ACK and finally sent a COOKIE ECHO with the peer's same tag
       but a new tag of its own.  The cookie should be silently
       discarded.  The endpoint SHOULD NOT change states and should leave
       any timers running.
    D) When both local and remote tags match, the endpoint should enter
       the ESTABLISHED state, if it is in the COOKIE-ECHOED state.  It
       should stop any cookie timer that may be running and send a COOKIE
       ACK.
    Note: The "peer's Verification Tag" is the tag received in the
    Initiate Tag field of the INIT or INIT ACK chunk.