RE: DOWN state

["Shahram Davari" <davari at broadcom.com>]

Hi Satayam,

 

Are you saying that the Jitter is calculated and applied per BFD packet? or it is calculated once per session and applied to all packets of that session?

For example can one packet of a BFD session be jittered by 10% and another one by 20%?

 

Thanks,

Shahram

---

From: Satyam Sinha [mailto:satyamsinha at live.com]
Sent: Friday, August 14, 2009 5:23 PM
To: Vishwas Manral; Shahram Davari
Cc: rtg-bfd at ietf.org
Subject: RE: DOWN state

Hi Shahram,

Comments inline....

> Date: Fri, 14 Aug 2009 16:42:36 -0700
> Subject: Re: DOWN state
> From: vishwas.ietf at gmail.com
> To: davari at broadcom.com
> CC: rtg-bfd at ietf.org
>
> Hi Saharam,
>
> On Fri, Aug 14, 2009 at 3:49 PM, Shahram Davari<davari at broadcom.com> wrote:
> > Hi,
> >
> > The based draft sys that if BFD Control packet is not received during any
> > Detection Interval then the local system will go to Down state.
> > I have two questions:
> >
> > 1) When can the local system transition out of Down state? Is it after
> > receiving the first BFD packet with State=DOWN or INIT? or a number of such
> > BFD packets are required? in other words is there a Hysteresis?
> No hysteresis is required as such.

Any hysteresis would actually be a violation of the "Section 6.2 BFD state-machine".

Down state means that the session is down (or has just been created.)
   A session remains in Down state until the remote system indicates
   that it agrees that the session is down by sending a BFD Control
   packet with the State field set to anything other than Up.

>
> > 2) Should the remote system apply  a sliding window for Detection Time or
> > fixed slotted windows that are not overlapped are acceptable?
> What does the window contain? (I understand you are trying to do
> something similar to TCP). Are you using a mechanism like that for
> echo packets?

From a transmit perspective, if you take into account jitter, one should have the timers as sliding window based. One should schedule the next transmit at last-transmit-time + tx-timer (jittered) instead of expected-last-transmit-time + tx-timer (jittered). The variance in the jitter alongwith slotted window usage between two transmits could cause the tx-time between two packets to be more than the tx-timer. When the multiplier=1, such a variance could make your session go down.

From a receive perspective you could do either. If you used slotted windows, you might see more than one packet in a slot but you are still guaranteed to see atleast one packet every slot.

Regards,

Satyam

---

Get your vacation photos on your phone! Click here.