![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
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.)> > > 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. |