Subject: RE: (Reply) Question about session establishment

From: Vipin Jain <[email-masked]>
Date: Thu, 9 Nov 2000 00:34:11 -0800

If LAC waits for Ack from LNS, what would it do with the data packets LNS
might have sent before it sent ZLB Ack? Given the fact that ZLB Ack could be
delayed, where as ICCN isn't.
Assuming most of the times ICCN will get to LNS, it would be more efficient
to assume tunnel in established when ICCN is sent and not wait for ZLB Ack.

-- vipin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 08, 2000 11:34 PM
To: [email-masked]; [email-masked]
Subject: Re: (Reply) Question about session establishment

But if the ICCN was lost and need to be retransmitted, the LAC has entered
established
state but the LNS still hasn't. During the period of retransmitting ICCN,
data
packets
maybe send to LNS, how will LNS handle this data packets? because the
session in
LNS still hasn't established, so it maybe ignore these packets. Do you think
this case
isn't important?

No. The session FSM steps immediately to "established" after sending the
ICCN.

evan
-

[email-masked] wrote:
>
> Hi,
>
> The Session state moves to the Established state after receiving the ZLB
corresponding to the ICCN sent.
>
> Sudheer.
>
> Hello,
>
> I have a problem about L2tp, At page 60(section 7.4.1) in rfc2661, there
is a
> LAC Incoming Call States table, I want to ask is that when will the state
go
to
> established state? After sending ICCN or after sending ICCN and receiving
> acknowledgement correspond to this ICCN(e.g.a ZLB)?
>
> TIA
>
> ZZF

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 23 Nov 2000 23:28:05 -0500

In most cases, sending packets right away will do no harm.

However, the problem with NOT waiting is that, in a few identifiable
cases, dropping the first few packets sent to the LNS can be fairly
detrimental. This is an unfortunate reality due to the dropping of IPCP
options in retransmitted IPCP Conf Reqs of a very popular PPP
implementation. This unfortunate reality makes the first couple of IPCP
packets sent by this particular implementation very important.

If Proxy LCP is performed and no authentication negotiated at the LAC
(perhaps some previous authentication occurred, this is a default tunnel
endpoint, etc) then the PPP peer connected to the LAC will be sending
IPCP packets right away as it will not be waiting on an authentication
response from the LNS. If these IPCP packets are dropped due to the ICCN
not reaching the LNS beforehand, or the PPP state machine at the LNS has
not been initialized yet, then it could drop these very first, very
important IPCP packets from the popular yet misbehaving PPP
implementation described above. To handle this situation in a robust
manner, a well-informed PPP implementation at an LAC must queue these
IPCP packets as they arrive before the L2TP session is established.
Rather than force the LNS to do the same, it would be better to wait
until the ICCN is acknowledged if it is carrying Proxy LCP information
and no authentication was negotiated.

- Mark