Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3931

Layer Two Tunneling Protocol - Version 3 (L2TPv3)

Pages: 94
Proposed Standard
Errata
Updated by:  5641
Part 4 of 5 – Pages 59 to 78
First   Prev   Next

Top   ToC   RFC3931 - Page 59   prevText

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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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   ToC   RFC3931 - 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 Section