Subject: RE: Few questions on L2TP..

From: Andy Koscinski <[email-masked]>
Date: Mon, 5 Mar 2001 21:38:39 -0800

1) Since there is no protocol support to re-synchronize the tunnel and data
message sequence number -  
 how does the LAC go about recovering a tunnel and call session after a
switchover?   
 
 For tunnel control channel will the following work? 
 
andyk> in the standard rfc2661 it would not work, because the Ns and Nr
between the LAC and the LNS would not synchronize after the switch over
and the tunnel would go down.

        LAC                            LNS
                Hello (Ns =0 ,Nr=0)
           ------------------------------>
                ZLB (Ns=x,Nr =y)
            <-----------------------------
The LAC can then determine its state variables based on the ZLB. 
 
andyk> yes, in the above msg exchange, the LAC and the LNS could synchronize
their msg sequence counters  (and Amber Networks L2TP implementation does, 
which is an extension to the rfc2661).
 
For sessions, what happens if the switched in component at the LAC does not
set the sequence numbers, but the call was using sequence number prior to
failure. Will the LNS clear the call? 
 
andyk> the rfc 2661 requires LAC to continue including the sequence numbers,
but 
in my reading does not explicitly require the LNS to clear the call after
the LAC misbehaved?  
 
I think it would be better if the LAC or LNS could ask during the L2TP
session establishment
not to use payload msg sequencing (currently the LAC can only ask to use
payload msg sequencing).
-------------------------------------------------------------------- 
andy koscinski: ph. 510.687.5536; cell: 650.245.4452 
                        fax. 510.687.5210 
                        [email-masked] 
Amber Networks, Inc. 
48664 Milmont Dr. 
Fremont, CA 94538-7353 
www.ambernetworks.com 

2)Is there a another method for synchronizing the negotiated LCP options at
the LAC? is snooping the only alternative? 
 
regards,
keyur

Keyur Parikh
Megisto Systems, Inc.
Ph: 301-444-1723
email: [email-masked] <mailto:[email-masked]>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 06 Mar 2001 02:17:02 -0500

Apologies for the nasty formatting in converting all this HTML mess to
ASCII. Please see WMT for comments inline.

Thanks,

- Mark

1) Since there is no protocol support to re-synchronize the tunnel and
data message sequence number -  
   how does the LAC go about recovering a tunnel and call session after
a switchover?   

       andyk> in the standard rfc2661 it would not work, because the Ns
and Nr
       between the LAC and the LNS would not synchronize after the
switch over
       and the tunnel would go down.

               LAC                            LNS
                       Hello (Ns =0 ,Nr=0)
        
       andyk> yes, in the above msg exchange, the LAC and the LNS could
synchronize
       their msg sequence counters  (and Amber Networks L2TP
implementation does, 
       which is an extension to the rfc2661).

WMT:

1. The control messages and data messages have different sequence number
spaces, there is no need to synchronize them.

2. ZLBs are never used for data sequencing.

3. A Hello message can never have Ns of zero. 

4. On the data channel, Nr is always ignored. 

5. I assume by "switchover" you mean some sort of active failover
technique. This is, in fact, outside the scope of RFC2661. 
        
       For sessions, what happens if the switched in component at the
LAC does not set the sequence numbers, but the call was using sequence
number
       prior to failure. Will the LNS clear the call? 

WMT: Clearing the call would be very drastic, don't you think? Again, if
my "switched in" you mean active failover, this is still outside the
scope of the RFC. However, the LNS should be lenient of an LAC that
sends sequence numbers even when it should not. Think of sequence number
presence as we do with PFC and ACFC in PPP - you always have to check on
its presence even when you think you know what you should be getting.
You have to do this not only for misbehaving implementations, but for
race conditions as well. 
        
       andyk> the rfc 2661 requires LAC to continue including the
sequence numbers, but 
       in my reading does not explicitly require the LNS to clear the
call after the LAC misbehaved?  
        
       I think it would be better if the LAC or LNS could ask during the
L2TP session establishment
       not to use payload msg sequencing (currently the LAC can only ask
to use payload msg sequencing).

WMT: The LNS is under control of sequence numbers as, traditionally, it
is the side that knows whether they are necessary or not (it is
terminating the PPP session and knows whether a CP is being negotiated,
compression or encryption is active, what protocols are being carried,
etc.). Sequence number presense is not signalled on the control channel
as you need to be able to turn sequence numbers on and off in-band, it
may be "too late" if you have to wait on a control message.

This is clearly not the best design. It was hacked in as a comprimise to
get RFC2661 ratified without much change to all of the running code that
we had. C'est la vie.

If we still need to conquer sequencing at the L2TP level, what I
*really* really should exist, is a small, wrapping sequence number that
is present at all times on packets being sent. It can then be ignored or
attended to on the receiving side as necessary. In hardware, stuffing in
a simple value incremented for each packet is probably just as fast as
checking a bit to see if you need to put a sequence number or a zero in
place. Also, this eliminates all signalling on the subject.

This begs the question though, should we have a fixed header option that
could be negotiated up front? That would certainly be more hardware
friendly as well. Fixed headers are never easy for committees to decide
upon, but we could certainly try.

       2)Is there a another method for synchronizing the negotiated LCP
options at the LAC? is snooping the only alternative? 

WMT: Why would you ever need to snoop? I hope you did not get this idea
from RFC2661.

If you need to notify the LAC of negotiated options that occurred at the
LNS, you can do this for important things such as ACCM via the SLI
command in RFC2661. There is a draft
(draft-ietf-l2tpext-linkinfo-0x.txt) that defines a generic way to send
all LCP options within the SLI. Take a look, comments welcome. We'll
probably go last call on this one soon.  

There are some potentially tricky race conditions here as well, which I
tried to detail in the latest l2tpbis document. Check the archives for a
fairly lengthy discussion on the subject (search on ACCM or SLI and you
will probably find it). 

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 06 Mar 2001 02:45:11 -0500

> 3. A Hello message can never have Ns of zero.

I take that back, a Hello message may have an Ns of zero if it is the
65536th control message on the tunnel, and *perhaps* if you ZLB ack an
SCCRQ and send a Hello before an SCCRP (which would probably be a bad
idea). In general, very rarely.

- Mark