Subject: Re: Doubt regarding L2TP redundancy discussion

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 06 Nov 2001 10:52:25 -0500

> Jitender Arora wrote:
> 
> Hello ,
> 
>              I have a doubt regarding the L2TP redundancy discussion , which
> was going on the WWWGateway Mailing list .

I am not on this mailing list, but will try and respond to your questions below.
I have copied the IETF L2TP mailing list as this is the relevant forum for L2TP
protocol discussions.

> There were few suggestions how can we implement LAC , in which after failover
> all the Tunnels and the established sessions remain in the same state and
> calls should proceed normally .

As long as you can checkpoint enough state between your active and failover
nodes, then you can keep all sessions and tunnels up. Granted, for some state it
is more difficult... Specifically sequence number state on the control channel.

> 
>               As far as I understand from the RFC 2661 , if a tunnel is up and
> there is no data or control activity on this tunnel , it should remain up for
> (default) 60 seconds after which the hello message will be sent , so if we can
> ensure that the LAC failover can take place within 60 seconds then there
> should be no problem in keeping the tunnels up .
> 
>               For the sessions , if the session is in the process of being
> established , then the same message will be transmitted for about 4 times
> atleast ( 8 seconds , exponential backoff algo ) , so if we can make sure that
> the LAC failover takes place within this time period then we can even save the
> sessions which are in the process of being established , but if we can't make
> sure this thing then we might loose the sessions which are being established .
> All the sessions which are up , should not have any problem .

These are the defaults. However, most implementations have knobs that allow you
do adjust these parameters.

> 
>               Now the only thing which we need to resolve is that we should
> not loose the data packets , for which there is no provision in the RFC 2661 .
> Because there is no provision for the retransmission of the data packets . AS
> it is mentioned in the discussions that we can't use the Nr for the data
> packets , can't we come out with modifications in the RFC 2661 , which can
> help us in implementing the retransmission of the data packets as well , if
> the LNS and LAC decided to have the Redundancy inbuilt for the L2TP .

Data packets are unreliable by design. In general, there are a number of
negative side-effects you can run into when you have multiple layers providing
reliability on top of one another. Since L2TP essentially operates below Layer 2
for its tunneled packets, providing reliability here is probably not the best
place in typical situations. Better to leave this up to higher layer transports
to recover from. 

Granted, depending on the failover time, this may or may not be catastrophic to
the higher layer applications and connections. But queuing packets in L2TP and
checkpointing them to a failover node is probably not the best place to apply
the solution.

- Mark