tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3931

 
 
 

Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Part 4 of 5, p. 59 to 78
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 59 
6.  Control Connection Protocol Specification

   The following control messages are used to establish, maintain, and
   tear down L2TP control connections.  All data packets are sent in
   network order (high-order octets first).  Any "reserved" or "empty"
   fields MUST be sent as 0 values to allow for protocol extensibility.

   The exchanges in which these messages are involved are outlined in
   Section 3.3.

Top      Up      ToC       Page 60 
6.1.  Start-Control-Connection-Request (SCCRQ)

   Start-Control-Connection-Request (SCCRQ) is a control message used to
   initiate a control connection between two LCCEs.  It is sent by
   either the LAC or the LNS to begin the control connection
   establishment process.

   The following AVPs MUST be present in the SCCRQ:

      Message Type
      Host Name
      Router ID
      Assigned Control Connection ID
      Pseudowire Capabilities List

   The following AVPs MAY be present in the SCCRQ:

      Random Vector
      Control Message Authentication Nonce
      Message Digest
      Control Connection Tie Breaker
      Vendor Name
      Receive Window Size
      Preferred Language

6.2.  Start-Control-Connection-Reply (SCCRP)

   Start-Control-Connection-Reply (SCCRP) is the control message sent in
   reply to a received SCCRQ message.  The SCCRP is used to indicate
   that the SCCRQ was accepted and that establishment of the control
   connection should continue.

   The following AVPs MUST be present in the SCCRP:

      Message Type
      Host Name
      Router ID
      Assigned Control Connection ID
      Pseudowire Capabilities List

   The following AVPs MAY be present in the SCCRP:

      Random Vector
      Control Message Authentication Nonce
      Message Digest
      Vendor Name
      Receive Window Size
      Preferred Language

Top      Up      ToC       Page 61 
6.3.  Start-Control-Connection-Connected (SCCCN)

   Start-Control-Connection-Connected (SCCCN) is the control message
   sent in reply to an SCCRP.  The SCCCN completes the control
   connection establishment process.

   The following AVP MUST be present in the SCCCN:

      Message Type

   The following AVP MAY be present in the SCCCN:

      Random Vector
      Message Digest

6.4.  Stop-Control-Connection-Notification (StopCCN)

   Stop-Control-Connection-Notification (StopCCN) is the control message
   sent by either LCCE to inform its peer that the control connection is
   being shut down and that the control connection should be closed.  In
   addition, all active sessions are implicitly cleared (without sending
   any explicit session control messages).  The reason for issuing this
   request is indicated in the Result Code AVP.  There is no explicit
   reply to the message, only the implicit ACK that is received by the
   reliable control message delivery layer.

   The following AVPs MUST be present in the StopCCN:

      Message Type
      Result Code

   The following AVPs MAY be present in the StopCCN:

      Random Vector
      Message Digest
      Assigned Control Connection ID

   Note that the Assigned Control Connection ID MUST be present if the
   StopCCN is sent after an SCCRQ or SCCRP message has been sent.

6.5.  Hello (HELLO)

   The Hello (HELLO) message is an L2TP control message sent by either
   peer of a control connection.  This control message is used as a
   "keepalive" for the control connection.  See Section 4.2 for a
   description of the keepalive mechanism.

Top      Up      ToC       Page 62 
   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

6.6.  Incoming-Call-Request (ICRQ)

   Incoming-Call-Request (ICRQ) is the control message sent by an LCCE
   to a peer when an incoming call is detected (although the ICRQ may
   also be sent as a result of a local event).  It is the first in a
   three-message exchange used for establishing a session via an L2TP
   control connection.

   The ICRQ is used to indicate that a session is to be established
   between an LCCE and a peer.  The sender of an ICRQ provides the peer
   with parameter information for the session.  However, the sender
   makes no demands about how the session is terminated at the peer
   (i.e., whether the L2 traffic is processed locally, forwarded, etc.).

   The following AVPs MUST be present in the ICRQ:

      Message Type
      Local Session ID
      Remote Session ID
      Serial Number
      Pseudowire Type
      Remote End ID
      Circuit Status

   The following AVPs MAY be present in the ICRQ:

      Random Vector
      Message Digest
      Assigned Cookie
      Session Tie Breaker
      L2-Specific Sublayer
      Data Sequencing
      Tx Connect Speed
      Rx Connect Speed
      Physical Channel ID

Top      Up      ToC       Page 63 
6.7.  Incoming-Call-Reply (ICRP)

   Incoming-Call-Reply (ICRP) is the control message sent by an LCCE in
   response to a received ICRQ.  It is the second in the three-message
   exchange used for establishing sessions within an L2TP control
   connection.

   The ICRP is used to indicate that the ICRQ was successful and that
   the peer should establish (i.e., answer) the incoming call if it has
   not already done so.  It also allows the sender to indicate specific
   parameters about the L2TP session.

   The following AVPs MUST be present in the ICRP:

      Message Type
      Local Session ID
      Remote Session ID
      Circuit Status

   The following AVPs MAY be present in the ICRP:

      Random Vector
      Message Digest
      Assigned Cookie
      L2-Specific Sublayer
      Data Sequencing
      Tx Connect Speed
      Rx Connect Speed
      Physical Channel ID

6.8.  Incoming-Call-Connected (ICCN)

   Incoming-Call-Connected (ICCN) is the control message sent by the
   LCCE that originally sent an ICRQ upon receiving an ICRP from its
   peer.  It is the final message in the three-message exchange used for
   establishing L2TP sessions.

   The ICCN is used to indicate that the ICRP was accepted, that the
   call has been established, and that the L2TP session should move to
   the established state.  It also allows the sender to indicate
   specific parameters about the established call (parameters that may
   not have been available at the time the ICRQ was issued).

   The following AVPs MUST be present in the ICCN:

      Message Type
      Local Session ID
      Remote Session ID

Top      Up      ToC       Page 64 
   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

6.9.  Outgoing-Call-Request (OCRQ)

   Outgoing-Call-Request (OCRQ) is the control message sent by an LCCE
   to an LAC to indicate that an outbound call at the LAC is to be
   established based on specific destination information sent in this
   message.  It is the first in a three-message exchange used for
   establishing a session and placing a call on behalf of the initiating
   LCCE.

   Note that a call may be any L2 connection requiring well-known
   destination information to be sent from an LCCE to an LAC.  This call
   could be a dialup connection to the PSTN, an SVC connection, the IP
   address of another LCCE, or any other destination dictated by the
   sender of this message.

   The following AVPs MUST be present in the OCRQ:

      Message Type
      Local Session ID
      Remote Session ID
      Serial Number
      Pseudowire Type
      Remote End ID
      Circuit Status

   The following AVPs MAY be present in the OCRQ:

      Random Vector
      Message Digest
      Assigned Cookie
      Tx Connect Speed
      Rx Connect Speed
      Session Tie Breaker
      L2-Specific Sublayer
      Data Sequencing

Top      Up      ToC       Page 65 
6.10.  Outgoing-Call-Reply (OCRP)

   Outgoing-Call-Reply (OCRP) is the control message sent by an LAC to
   an LCCE in response to a received OCRQ.  It is the second in a
   three-message exchange used for establishing a session within an L2TP
   control connection.

   OCRP is used to indicate that the LAC has been able to attempt the
   outbound call.  The message returns any relevant parameters regarding
   the call attempt.  Data MUST NOT be forwarded until the OCCN is
   received, which indicates that the call has been placed.

   The following AVPs MUST be present in the OCRP:

      Message Type
      Local Session ID
      Remote Session ID
      Circuit Status

   The following AVPs MAY be present in the OCRP:

      Random Vector
      Message Digest
      Assigned Cookie
      L2-Specific Sublayer
      Tx Connect Speed
      Rx Connect Speed
      Data Sequencing
      Physical Channel ID

6.11.  Outgoing-Call-Connected (OCCN)

   Outgoing-Call-Connected (OCCN) is the control message sent by an LAC
   to another LCCE after the OCRP and after the outgoing call has been
   completed.  It is the final message in a three-message exchange used
   for establishing a session.

   OCCN is used to indicate that the result of a requested outgoing call
   was successful.  It also provides information to the LCCE who
   requested the call about the particular parameters obtained after the
   call was established.

   The following AVPs MUST be present in the OCCN:

      Message Type
      Local Session ID
      Remote Session ID

Top      Up      ToC       Page 66 
   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

6.12.  Call-Disconnect-Notify (CDN)

   The Call-Disconnect-Notify (CDN) is a control message sent by an LCCE
   to request disconnection of a specific session.  Its purpose is to
   inform the peer of the disconnection and the reason for the
   disconnection.  The peer MUST clean up any resources, and does not
   send back any indication of success or failure for such cleanup.

   The following AVPs MUST be present in the CDN:

      Message Type
      Result Code
      Local Session ID
      Remote Session ID

   The following AVP MAY be present in the CDN:

      Random Vector
      Message Digest

6.13.  WAN-Error-Notify (WEN)

   The WAN-Error-Notify (WEN) is a control message sent from an LAC to
   an LNS to indicate WAN error conditions.  The counters in this
   message are cumulative.  This message should only be sent when an
   error occurs, and not more than once every 60 seconds.  The counters
   are reset when a new call is established.

   The following AVPs MUST be present in the WEN:

      Message Type
      Local Session ID
      Remote Session ID
      Circuit Errors

Top      Up      ToC       Page 67 
   The following AVP MAY be present in the WEN:

      Random Vector
      Message Digest

6.14.  Set-Link-Info (SLI)

   The Set-Link-Info control message is sent by an LCCE to convey link
   or circuit status change information regarding the circuit associated
   with this L2TP session.  For example, if PPP renegotiates LCP at an
   LNS or between an LAC and a Remote System, or if a forwarded Frame
   Relay VC transitions to Active or Inactive at an LAC, an SLI message
   SHOULD be sent to indicate this event.  Precise details of when the
   SLI is sent, what PW type-specific AVPs must be present, and how
   those AVPs should be interpreted by the receiving peer are outside
   the scope of this document.  These details should be described in the
   associated pseudowire-specific documents that require use of this
   message.

   The following AVPs MUST be present in the SLI:

      Message Type
      Local Session ID
      Remote Session ID

   The following AVPs MAY be present in the SLI:

      Random Vector
      Message Digest
      Circuit Status

6.15.  Explicit-Acknowledgement (ACK)

   The Explicit Acknowledgement (ACK) message is used only to
   acknowledge receipt of a message or messages on the control
   connection (e.g., for purposes of updating Ns and Nr values).
   Receipt of this message does not trigger an event for the L2TP
   protocol state machine.

   A message received without any AVPs (including the Message Type AVP),
   is referred to as a Zero Length Body (ZLB) message, and serves the
   same function as the Explicit Acknowledgement.  ZLB messages are only
   permitted when Control Message Authentication defined in Section 4.3
   is not enabled.

Top      Up      ToC       Page 68 
   The following AVPs MAY be present in the ACK message:

      Message Type
      Message Digest

7.  Control Connection State Machines

   The state tables defined in this section govern the exchange of
   control messages defined in 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).

7.1.  Malformed AVPs and Control Messages

   Receipt of an invalid or unrecoverable malformed control message
   SHOULD be logged appropriately and the control connection cleared to
   ensure recovery to a known state.  The control connection may then be
   restarted by the initiator.

   An invalid control message is defined as (1) a message that contains
   a Message Type marked as mandatory (see 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

Top      Up      ToC       Page 69 
   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.

7.2.  Control Connection States

   The L2TP control connection protocol is not distinguishable between
   the two LCCEs but is distinguishable between the originator and
   receiver.  The originating peer is the one that first initiates
   establishment of the control connection.  (In a tie breaker
   situation, this is the winner of the tie.)  Since either the LAC or
   the LNS can be the originator, a collision can occur.  See the
   Control Connection Tie Breaker AVP in 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

Top      Up      ToC       Page 70 
   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

Top      Up      ToC       Page 71 
   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.

7.3.  Incoming Calls

   An ICRQ is generated by an LCCE, typically in response to an incoming
   call or a local event.  Once the LCCE sends the ICRQ, it waits for a
   response from the peer.  However, it may choose to postpone
   establishment of the call (e.g., answering the call, bringing up the
   circuit) until the peer has indicated with an ICRP that it will
   accept the call.  The peer may choose not to accept the call if, for
   instance, there are insufficient resources to handle an additional
   session.

   If the peer chooses to accept the call, it responds with an ICRP.
   When the local LCCE receives the ICRP, it attempts to establish the
   call.  A final call connected message, the ICCN, is sent from the
   local LCCE to the peer to indicate that the call states for both
   LCCEs should enter the established state.  If the call is terminated
   before the peer can accept it, a CDN is sent by the local LCCE to
   indicate this condition.

   When a call transitions to a "disconnected" or "down" state, the call
   is cleared normally, and the local LCCE sends a CDN.  Similarly, if
   the peer wishes to clear a call, it sends a CDN and cleans up its
   session.

Top      Up      ToC       Page 72 
7.3.1.  ICRQ Sender States

   State           Event              Action           New State
   -----           -----              ------           ---------

   idle            Call signal or     Initiate local   wait-control-conn
                   ready to receive   control-conn
                   incoming conn      open

   idle            Receive ICCN,      Clean up         idle
                   ICRP, CDN

   wait-control-   Bearer line drop   Clean up         idle
   conn            or local close
                   request

   wait-control-   control-conn-open  Send ICRQ        wait-reply
   conn

   wait-reply      Receive ICRP,      Send ICCN        established
                   acceptable

   wait-reply      Receive ICRP,      Send CDN,        idle
                   Not acceptable     clean up

   wait-reply      Receive ICRQ,      Process as       idle
                   lose tie breaker   ICRQ Recipient
                                      (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

Top      Up      ToC       Page 73 
   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.

7.3.2.  ICRQ Recipient States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Receive ICRQ,      Send ICRP         wait-connect
                   acceptable

   idle            Receive ICRQ,      Send CDN,         idle
                   not acceptable     clean up

   idle            Receive ICRP       Send CDN          idle
                                      clean up

   idle            Receive ICCN       Clean up          idle

   wait-connect    Receive ICCN,      Prepare for       established
                   acceptable         data

Top      Up      ToC       Page 74 
   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.

7.4.  Outgoing Calls

   Outgoing calls instruct an LAC to place a call.  There are three
   messages for outgoing calls: OCRQ, OCRP, and OCCN.  An LCCE first
   sends an OCRQ to an LAC to request an outgoing call.  The LAC MUST
   respond to the OCRQ with an OCRP once it determines that the proper
   facilities exist to place the call and that the call is
   administratively authorized.  Once the outbound call is connected,
   the LAC sends an OCCN to the peer indicating the final result of the
   call attempt.

Top      Up      ToC       Page 75 
7.4.1.  OCRQ Sender States

   State          Event              Action            New State
   -----          -----              ------            ---------
   idle           Local open         Initiate local    wait-control-conn
                  request            control-conn-open

   idle           Receive OCCN,      Clean up          idle
                  OCRP

   wait-control-  control-conn-open  Send OCRQ         wait-reply
   conn

   wait-reply     Receive OCRP,      none              wait-connect
                  acceptable

   wait-reply     Receive OCRP,      Send CDN,         idle
                  not acceptable     clean up

   wait-reply     Receive OCCN       Send CDN,         idle
                                     clean up

   wait-reply     Receive OCRQ,      Process as        idle
                  lose tie breaker   OCRQ Recipient
                                     (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

Top      Up      ToC       Page 76 
   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.

7.4.2.  OCRQ Recipient (LAC) States

   State           Event              Action            New State
   -----           -----              ------            ---------
   idle            Receive OCRQ,      Send OCRP,        wait-cs-answer
                   acceptable         Place call

   idle            Receive OCRQ,      Send CDN,         idle
                   not acceptable     clean up

   idle            Receive OCRP       Send CDN,         idle
                                      clean up

   idle            Receive OCCN,      Clean up          idle
                   CDN

   wait-cs-answer  Call placement     Send OCCN         established
                   successful

   wait-cs-answer  Call placement     Send CDN,         idle
                   failed             clean up

Top      Up      ToC       Page 77 
   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.

7.5.  Termination of a Control Connection

   The termination of a control connection consists of either peer
   issuing a StopCCN.  The sender of this message SHOULD wait a full
   control message retransmission cycle (e.g., 1 + 2 + 4 + 8 ...
   seconds) for the acknowledgment of this message before releasing the
   control information associated with the control connection.  The
   recipient of this message should send an acknowledgment of the
   message to the peer, then release the associated control information.

   When to release a control connection is an implementation issue and
   is not specified in this document.  A particular implementation may
   use whatever policy is appropriate for determining when to release a
   control connection.  Some implementations may leave a control
   connection open for a period of time or perhaps indefinitely after

Top      Up      ToC       Page 78 
   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.



(page 78 continued on part 5)

Next RFC Part