Subject: Re: AW: [L2tpext] result code for disconnect in the case of L2TP dial out

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 06 Feb 2003 16:43:59 +0100

[email-masked] wrote:
> Mark,
> 
> thank You for Your response. 
> 
> 
>>>What should we return, if 
>>>- the session is terminated because the L2TP session, which had 
>>>initiated it, was normally terminated by the dialin client?
>>
>>The dialin client may cause the LNS to disconnect by sending 
>>a PPP Terminate 
>>Request, or by "hanging up" the line to the LAC. The latter 
>>is a "loss of 
>>carrier" condition, result code 1, RFC3145 may be consulted 
>>for the former.
> 
> 
> However, in this case there is no dialin client, as it is dialout.
> There is a L2TP client who had initiated the dialout via L2TP. He 
> requests the RAS to disconnect the phone line session by closing 
> the L2TP session. So the carrier was not really lost, but actively 
> disconnected by the RAS as a reaction to a termination request by 
> the L2TP client. There appears to be no code for an intended disconnect 
> from the network side.

Perhaps a picture would be useful here for clarification. The typical dialout 
model is:

LNS --- LAC ---- Remote System

The Remote System is your PPP client, and L2TP is run between the LAC and LNS. 
I'm not sure where the L2TP client you refer to here is... Perhaps the Remote 
System??

In any case, typically the LNS initiates the dialout, and LAC makes the call to 
the Remote System. If the LNS then initiates a disconnect, I suspect most 
implementations still simply use "1 - Call disconnected due to loss of carrier" 
though "3 - Call disconnected for administrative reasons" might be a slightly 
better fit. I agree with you that the disconnect codes are a bit lacking here.

Hope this helps,

- Mark

> 
> 
>>>- or if even the corresponding tunnel was lost (in this 
>>
>>case we cannot
>>
>>>return anything however would like to store a local code 
>>
>>for diagnostics)? 
>>
>>This is subject to interpretation, but perhaps a result code 
>>of 2, pointing to 
>>an error code of of "1 - No control connection exists yet for 
>>this LAC-LNS"
> 
> 
> I aggree. That's probably the best applicable solution.
> 
> best regards
> 
> Andreas
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: W. Mark Townsley [mailto:[email-masked]]
>>Gesendet am: Dienstag, 21. Januar 2003 02:58
>>An: Waibel, Andreas
>>Cc: [email-masked]
>>Betreff: Re: [L2tpext] result code for disconnect in the case of L2TP
>>dialout
>>
>>
>>
>>[email-masked] wrote:
>>
>>>Colleagues,
>>>
>>>we are currently discussing a special L2TP dialout 
>>>implementation with a big RAS vendor. The szenario 
>>>includes dialout connection initated from a L2TP client.
>>>
>>>LT2P client --- l2TP tunnel switch --- dialout LAC ---> target 
>>> 
>>>Generally we found RFC 2661 well applicable, however
>>>now we have a problem with the CDN result codes:
>>> 
>>>     Defined Result Code values for the CDN message are:
>>>
>>>         0 - Reserved
>>>         1 - Call disconnected due to loss of carrier
>>>         2 - Call disconnected for the reason indicated
>>>             in error code
>>>         3 - Call disconnected for administrative reasons
>>>         4 - Call failed due to lack of appropriate facilities
>>>             being available (temporary condition)
>>>         5 - Call failed due to lack of appropriate facilities being
>>>             available (permanent condition)
>>>         6 - Invalid destination
>>>         7 - Call failed due to no carrier detected
>>>         8 - Call failed due to detection of a busy signal
>>>         9 - Call failed due to lack of a dial tone
>>>         10 - Call was not established within time allotted by LAC
>>>         11 - Call was connected but no appropriate framing was
>>>              detected
>>>
>>>What should we return, if 
>>>- the session is terminated because the L2TP session, which had 
>>>initiated it, was normally terminated by the dialin client?
>>
>>The dialin client may cause the LNS to disconnect by sending 
>>a PPP Terminate 
>>Request, or by "hanging up" the line to the LAC. The latter 
>>is a "loss of 
>>carrier" condition, result code 1, RFC3145 may be consulted 
>>for the former.
>>
>>
>>>- or if even the corresponding tunnel was lost (in this 
>>
>>case we cannot
>>
>>>return anything however would like to store a local code 
>>
>>for diagnostics)? 
>>
>>This is subject to interpretation, but perhaps a result code 
>>of 2, pointing to 
>>an error code of of "1 - No control connection exists yet for 
>>this LAC-LNS"
>>
>>
>>>thank You for Your advice!
>>>
>>>best regards
>>>
>>>Andreas 
>>>
>>>--------------------
>>>Andreas Waibel
>>>COLT Telecom GmbH
>>>Herriotstraße 4
>>>60528 Frankfurt am Main
>>>Tel.: ++49 69 56606 6570
>>>Fax: ++49 69 56606 6350
>>>email: [email-masked]
>>>
>>>_______________________________________________
>>>L2tpext mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/l2tpext
>>>
>>
>>
> _______________________________________________
> L2tpext mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/l2tpext
> 

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 06 Feb 2003 16:43:59 +0100

Hope this helps,

- Mark