[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Heartbeats (was RE: keepalives)


Not that I really car either, but I thought the intention was for a 'poll'
to enable a client to detect when a head-end gateway had 'gone'. 

The poll from the head-end is not a 'keep-alive' in that it does not prevent
the SAs from going necessarily. 

The plan we have goes like this:

Client connects, and the head-end starts sending heart-beats. It continues
doing this until the gateway bounces, or the gateway determines the client
connection should be terminated - for whatever reason (e.g. idle timer).

Ideally, the client should spot a dead gateway and try to reconnect to the
same of secondary gateways.

Cheers, Steve.

-----Original Message-----
From: todd.glassey [mailto:todd.glassey@certifiedtime.com]
Sent: Thursday, December 02, 1999 6:13 PM
To: Tim Jenkins
Cc: 
Subject: Re: Heartbeats (was RE: keepalives)


Tim, FYI -
We use the term "heartbeat" in STime WG as a reference for the local
frequency source in the Host's timebase service model.

One of the things we are working on is secure timebase Steering vs. Jam
Setting  (ie. the maintaining of the clock accurately without violating the
"boundaries of the timebase's granularity" relative to UTC).  This requires
both a fixed reference point for the HOST Synchronization event and the
operations of the local oscillator and timebase BIOS service infrastructure.

I would rather see the term Keep-Alive used to refer to the process of
keeping the channel open and the session maintained, myself.

Todd Glassey

----- Original Message -----
From: "Tim Jenkins" <tjenkins@TimeStep.com>
To: "Jan Vilhuber" <vilhuber@cisco.com>
Cc: <ipsec@lists.tislabs.com>
Sent: Thursday, December 02, 1999 06:09 AM
Subject: Heartbeats (was RE: keepalives)


> Just a nit, but if we really mean heartbeat, can we call it that?
>
> A keep-alive to me is something that defeats the peer's inactivity
time-out
> detection mechanism, while a heartbeat is something that helps detect the
> health of the peer. And a heartbeat shouldn't defeat inactivity detection,
> either.
>
> ---
> Tim Jenkins                       TimeStep Corporation
> tjenkins@timestep.com          http://www.timestep.com
> (613) 599-3610 x4304               Fax: (613) 599-3617
>
>
>
> > -----Original Message-----
> > From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> > Sent: December 1, 1999 8:55 PM
> > To: Dan Harkins
> > Cc: ipsec@lists.tislabs.com
> > Subject: keepalives (was Re: IPSec SA DELETE in "dangling"
> > implementation)
> >
> >
> > On Wed, 1 Dec 1999, Dan Harkins wrote:
> > >   I think a nice generic keep alive function would be more useful to
> > > implement. Why doesn't someone write a draft on this subject?
> > >
> > I'm sort of working myself up to it, i.e. we're still
> > wondering internally
> > what's best.
> >
> > Problem I see is that there are several different scenarios
> > where different
> > types of keepalives will be necessary (i.e. a dial-up
> > scenario has different
> > requirements than a straight ethernet scenario; ethernet
> > scenario will be
> > more efficient and optimizable, but dial-up is not). Once I
> > get something
> > written up, I'll post it to the list, but I have my doubts
> > that we'll come up
> > with a single sanctioned mechanism. There'll likely be at
> > least two. It's
> > possible we can come up with one generic enough to be used in
> > both cases, but
> > I doubt it (I'm a pessimist).
> >
> > jan
> >  --
> > Jan Vilhuber
> > vilhuber@cisco.com
> > Cisco Systems, San Jose
> > (408) 527-0847
> >
> >