Subject: RE: Few questions on L2TP..

From: Keyur Parikh <[email-masked]>
Date: Tue, 6 Mar 2001 11:29:38 -0500

My comments starting with >KRP

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Tuesday, March 06, 2001 2:17 AM
To: Andy Koscinski
Cc: Keyur Parikh; [email-masked]
Subject: Re: Few questions on L2TP..

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?   
        
   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).
>KRP - andy, I agree in theory it should work.
WMT:

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

>KRP May be you misunderstood the question.  The synchronization is between
the LAC and LNS for control channel and data session sequence number, not
between the control channel and individual data channel.

2. ZLBs are never used for data sequencing.
>KRP But ZLB does contain the Ns and Nr which can be used by the LAC to
derive its own sequence numbers.

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. 
KRP>
ok, now you are making assumptions on how the LNS implementation has
interpreted the RFC.  My point in all this is that why is there no support
in the RFC2661 for re-synching the control and data session sequence numbers
after such a condition.  This will also help avoid proprietary
implementation and make the protocol more robust.
        
       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.  

>KRP thanks for the draft info, I was not aware of this. From the RFC2661,
the only info returned from LNS in SLI message is ACCM, I could not find
anywhere in the RFC where the negotiated FCS or MRU is indicated to the LNS.

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). 

>KRP thanks, I will.
- Mark

---

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

Comments inline.

- Mark

>        and the tunnel would go down.

This could be dangerous. 

It seems that you are "probing" with a Hello message that you think is
invalid, and expecting the peer to send a ZLB ack in response and obtain
information from this. In the nominal case, this could work, but you
have to consider the edge conditions as well. You don't want to design
something that works "most" of the time, particularly when a failure can
bring down an entire tunnel with thousands of sessions within it.

- The Ns sequence space is a wrapping 16-bit value. It begins with 0,
but after that there is no signifigance to 0 other than it occurs again
some time in the future... Probably beyond your testing procedures so it
"looks" like this works fine. Think of choosing, say, 100 for your Ns
Hello probe and think about whether your method will always work. 

- The only way to be sure you are sending an Ns that will be dropped and
acknowledged is to send Ns equal to the last acknowledged packet for the
tunnel. However, I *think* your intended application prohibits this as
it is coming up after a "switchover" and has no sequence number state. 

- The Nr of zero in your probe could inadverdantly acknowledge
outstanding packets on the tunnel (packets that you have not recevied,
but your peer will think you have received).

- A peer does not have to respond to a Hello message with a ZLB. 

- Even if the Hello message does trigger a ZLB, a "real" control message
could be received before the ZLB is (packets may be reordered in
transit).

- Think about what happens if/when both sides try to sync with one
another.

There are no requirements for "timeouts" of states in L2TP. The L2TP
state machine very much depends on the reliable control channel beneath
it to deliver ALL packets. I see the possibililty for packets to be
erroneously acknowledged here, which places additional requirements on
the L2TP state machine.

> between the control channel and individual data channel.

You cannot rely on the data Nr to have anything valid in it. Anyway, all
you need to do to synchronize data packets after losing state is to pick
a number and start counting. The peer's window, timer, or whatever
sequence sanity checking it is performing will overflow and pickup with
the current sequence numbers.

> interpreted the RFC.  

Just giving interoperabilty advice. A good implementation is liberal in
what it accepts and strict in what it sends. 

I would be interested to know where in the RFC it suggests that a call
should be torn down if a data packet is received with sequence numbers
present or not. I would hope that it does not give this impression.

> My point in all this is that why is there no support

There is a fundamental assumption that all control packets will be
delivered reliably. Period. At first glance, this "resyncing" seems to
break this under some conditions. 

Again, there is no need to "resync" data messages.