Section 4.2 for a description of the keepalive mechanism.
HELLO messages are global to the control connection. The Session ID in a HELLO message MUST be 0. The following AVP MUST be present in the HELLO: Message Type The following AVP MAY be present in the HELLO: Random Vector Message Digest
The following AVPs MAY be present in the ICCN: Random Vector Message Digest L2-Specific Sublayer Data Sequencing Tx Connect Speed Rx Connect Speed Circuit Status
The following AVPs MAY be present in the OCCN: Random Vector Message Digest L2-Specific Sublayer Tx Connect Speed Rx Connect Speed Data Sequencing Circuit Status
The following AVP MAY be present in the WEN: Random Vector Message Digest Section 4.3 is not enabled.
The following AVPs MAY be present in the ACK message: Message Type Message Digest Section 6. Tables are defined for incoming call placement and outgoing call placement, as well as for initiation of the control connection itself. The state tables do not encode timeout and retransmission behavior, as this is handled in the underlying reliable control message delivery mechanism (see Section 4.2). Section 5.4.1) but that is unknown to the implementation, or (2) a control message that is received in the wrong state. Examples of malformed control messages include (1) a message that has an invalid value in its header, (2) a message that contains an AVP that is formatted incorrectly or whose value is out of range, and (3) a message that is missing a required AVP. A control message with a malformed header MUST be discarded. When possible, a malformed AVP should be treated as an unrecognized AVP (see Section 5.2). Thus, an attempt to inspect the M bit SHOULD be made to determine the importance of the malformed AVP, and thus, the severity of the malformation to the entire control message. If the M bit can be reasonably inspected within the malformed AVP and is determined to be set, then as with an unrecognized AVP, the associated session or control connection MUST be shut down. If the M bit is inspected and is found to be 0, the AVP MUST be ignored (assuming recovery from the AVP malformation is indeed possible). This policy must not be considered as a license to send malformed AVPs, but rather, as a guide towards how to handle an improperly formatted message if one is received. It is impossible to list all potential malformations of a given message and give advice for each. One example of a malformed AVP situation that should be recoverable
is if the Rx Connect Speed AVP is received with a length of 10 rather than 14, implying that the connect speed bits-per-second is being formatted in 4 octets rather than 8. If the AVP does not have its M bit set (as would typically be the case), this condition is not considered catastrophic. As such, the control message should be accepted as though the AVP were not present (though a local error message may be logged). In several cases in the following tables, a protocol message is sent, and then a "clean up" occurs. Note that, regardless of the initiator of the control connection destruction, the reliable delivery mechanism must be allowed to run (see Section 4.2) before destroying the control connection. This permits the control connection management messages to be reliably delivered to the peer. Appendix B.1 contains an example of lock-step control connection establishment. Section 5.4.3 for a description of this and its resolution. State Event Action New State ----- ----- ------ --------- idle Local open Send SCCRQ wait-ctl-reply request idle Receive SCCRQ, Send SCCRP wait-ctl-conn acceptable idle Receive SCCRQ, Send StopCCN, idle not acceptable clean up idle Receive SCCRP Send StopCCN, idle clean up idle Receive SCCCN Send StopCCN, idle clean up
wait-ctl-reply Receive SCCRP, Send SCCCN, established acceptable send control-conn open event to waiting sessions wait-ctl-reply Receive SCCRP, Send StopCCN, idle not acceptable clean up wait-ctl-reply Receive SCCRQ, Send SCCRP, wait-ctl-conn lose tie breaker, Clean up losing SCCRQ acceptable connection wait-ctl-reply Receive SCCRQ, Send StopCCN, idle lose tie breaker, Clean up losing SCCRQ unacceptable connection wait-ctl-reply Receive SCCRQ, Send StopCCN for wait-ctl-reply win tie breaker losing connection wait-ctl-reply Receive SCCCN Send StopCCN, idle clean up wait-ctl-conn Receive SCCCN, Send control-conn established acceptable open event to waiting sessions wait-ctl-conn Receive SCCCN, Send StopCCN, idle not acceptable clean up wait-ctl-conn Receive SCCRQ, Send StopCCN, idle SCCRP clean up established Local open Send control-conn established request open event to (new call) waiting sessions established Administrative Send StopCCN, idle control-conn clean up close event established Receive SCCRQ, Send StopCCN, idle SCCRP, SCCCN clean up idle, Receive StopCCN Clean up idle wait-ctl-reply, wait-ctl-conn, established
The states associated with an LCCE for control connection establishment are as follows: idle Both initiator and recipient start from this state. An initiator transmits an SCCRQ, while a recipient remains in the idle state until receiving an SCCRQ. wait-ctl-reply The originator checks to see if another connection has been requested from the same peer, and if so, handles the collision situation described in Section 5.4.3. wait-ctl-conn Awaiting an SCCCN. If the SCCCN is valid, the control connection is established; otherwise, it is torn down (sending a StopCCN with the proper result and/or error code). established An established connection may be terminated by either a local condition or the receipt of a StopCCN. In the event of a local termination, the originator MUST send a StopCCN and clean up the control connection. If the originator receives a StopCCN, it MUST also clean up the control connection.
Section 7.3.2) wait-reply Receive ICRQ, Send CDN wait-reply win tie breaker for losing session wait-reply Receive CDN, Clean up idle ICCN wait-reply Local close Send CDN, idle request clean up established Receive CDN Clean up idle established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up established Local close Send CDN, idle request clean up
The states associated with the ICRQ sender are as follows: idle The LCCE detects an incoming call on one of its interfaces (e.g., an analog PSTN line rings, or an ATM PVC is provisioned), or a local event occurs. The LCCE initiates its control connection establishment state machine and moves to a state waiting for confirmation of the existence of a control connection. wait-control-conn In this state, the session is waiting for either the control connection to be opened or for verification that the control connection is already open. Once an indication that the control connection has been opened is received, session control messages may be exchanged. The first of these messages is the ICRQ. wait-reply The ICRQ sender receives either (1) a CDN indicating the peer is not willing to accept the call (general error or do not accept) and moves back into the idle state, or (2) an ICRP indicating the call is accepted. In the latter case, the LCCE sends an ICCN and enters the established state. established Data is exchanged over the session. The call may be cleared by any of the following: + An event on the connected interface: The LCCE sends a CDN. + Receipt of a CDN: The LCCE cleans up, disconnecting the call. + A local reason: The LCCE sends a CDN.
wait-connect Receive ICCN, Send CDN, idle not acceptable clean up wait-connect Receive ICRQ, Send CDN, idle ICRP clean up idle, Receive CDN Clean up idle wait-connect, established wait-connect Local close Send CDN, idle established request clean up established Receive ICRQ, Send CDN, idle ICRP, ICCN clean up The states associated with the ICRQ recipient are as follows: idle An ICRQ is received. If the request is not acceptable, a CDN is sent back to the peer LCCE, and the local LCCE remains in the idle state. If the ICRQ is acceptable, an ICRP is sent. The session moves to the wait-connect state. wait-connect The local LCCE is waiting for an ICCN from the peer. Upon receipt of the ICCN, the local LCCE moves to established state. established The session is terminated either by sending a CDN or by receiving a CDN from the peer. Clean up follows on both sides regardless of the initiator.
Section 7.4.2) wait-reply Receive OCRQ, Send CDN wait-reply win tie breaker for losing session wait-connect Receive OCCN none established wait-connect Receive OCRQ, Send CDN, idle OCRP clean up idle, Receive CDN Clean up idle wait-reply, wait-connect, established established Receive OCRQ, Send CDN, idle OCRP, OCCN clean up wait-reply, Local close Send CDN, idle wait-connect, request clean up established
wait-control- Local close Clean up idle conn request The states associated with the OCRQ sender are as follows: idle, wait-control-conn When an outgoing call request is initiated, a control connection is created as described above, if not already present. Once the control connection is established, an OCRQ is sent to the LAC, and the session moves into the wait-reply state. wait-reply If a CDN is received, the session is cleaned up and returns to idle state. If an OCRP is received, the call is in progress, and the session moves to the wait-connect state. wait-connect If a CDN is received, the session is cleaned up and returns to idle state. If an OCCN is received, the call has succeeded, and the session may now exchange data. established If a CDN is received, the session is cleaned up and returns to idle state. Alternatively, if the LCCE chooses to terminate the session, it sends a CDN to the LAC, cleans up the session, and moves the session to idle state.
wait-cs-answer Receive OCRQ, Send CDN, idle OCRP, OCCN clean up established Receive OCRQ, Send CDN, idle OCRP, OCCN clean up wait-cs-answer, Receive CDN Clean up idle established wait-cs-answer, Local close Send CDN, idle established request clean up The states associated with the LAC for outgoing calls are as follows: idle If the OCRQ is received in error, respond with a CDN. Otherwise, place the call, send an OCRP, and move to the wait-cs-answer state. wait-cs-answer If the call is not completed or a timer expires while waiting for the call to complete, send a CDN with the appropriate error condition set, and go to idle state. If a circuit-switched connection is established, send an OCCN indicating success, and go to established state. established If the LAC receives a CDN from the peer, the call MUST be released via appropriate mechanisms, and the session cleaned up. If the call is disconnected because the circuit transitions to a "disconnected" or "down" state, the LAC MUST send a CDN to the peer and return to idle state.
the last session for that control connection is cleared. Others may choose to disconnect the control connection immediately after the last call on the control connection disconnects.