Subject: Re: Closure needed please comment WAS(Re: Section 9: Heartbeat Messages

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 14 Oct 2005 11:17:07 +0800

Jamal,

When I check back the mail, I find the supposed changes on section 6.2.1 and
even for 6.9 Heartbeat Message have already been proposed before, only the text
seems was not included in the draft timely. I actually redid the HB message
yesterday , for I also forgot I had already done this.

Yours,
Weiming

----- Original Message -----
From: "Weiming Wang" <[email-masked]>

> ----- Original Message -----
> From: "Jamal Hadi Salim" <[email-masked]>
> >
> > Send me the text privately when ready and i will release it to the list.
>
> Jamal, I think it may be better for you to keep consistency with your XML file
> version maintainence by my sending you only the text instead of the XML. The
> text regarding the Heartbeat attributes in FEPO is just as below:
>
> Remove the following text in Section 6.2.1 on the FE Protocol Attributes
> paragraph:
>
> ---
>       *  Association Expiry Timer.  Defualt Value = 900 msec
>
>       *  Heartbeat Interval.  Defualt Value = 300 msec
> ---
> The reason to remove the Association Expiry Timer is, it can simply be
replaced
> by the 'CE heartbeat dead interval', I think. Any comments ?
>
> Substitute it with the following text:
>
> ---
> * Heartbeat policy and parameters, which includes fields as:
>
>   . CE heartbeat policy - This policy, along with the parameter 'CE Heartbeat
> Dead Interval (CE HDI)' as described below, actually tells the FE how to check
> the CE liveness. The policy values with its meanings are listed as below:
>
>          0(default) - This policy specifies that CE will send a Heartbeat
> Message to FE whenever CE reaches a time interval within which no any other
> messages were sent from CE to FE (Heartbeat generated in this way is sometimes
> called Piggybacking-Heartbeat). A CE HDI parameter as described below is
> associated with this policy. FE checks the CE being alive or dead just by
> checking if it has or has not received any message (including Heartbeat
Message
> itself) for the CE HDI period. Note that CE can freely choose the time
interval
> to send Heartbeat messages and don't have to let FE know the interval, but
> definitely, the time interval choosen must be smaller than the CE HDI
assigned.
>
>          1 - This policy specifies that CE will not send any Heartbeat Message
> to FE in any case. This actually means CE does not want to ask FE to check the
> CE liveness.
>
>          Others - reserved.
>
>    . FE heartbeat policy - This policy, along with the parameter 'FE Heartbeat
> Interval (FE HI)', tells FE how it should act so that the CE it has associated
> with can check the liveness of the FE based on the actions. The policy values
> and the meanings are:
>
>          0(default) - This policy actually specifies no extra action for FE on
> its heartbeat generation. As a result, to let CE check its liveness, the FE
may
> only just act by responding to CE whenever CE sends Heartbeat Request Message
> (also a normal HB message, only with whose ACK flag is set to AlwaysACK, see
> Section 6.9) with a Heartbeat Response Message (also a normal HB message, only
> with whose ACK flag is set to NoACK, see Section 6.9).
>
>          1 - This policy specifies that FE must actively send a Heartbeat
> Message if it reaches the time interval assigned by the FE HI followed, within
> which no any other messages were sent from FE to CE.
>
>          Others - Reserved.
>
>    . CE Heartbeat Dead Interval (CE HDI) - to tell FE the time interval the FE
> uses to check the CE liveness. If FE has not received any messages from CE for
> this time interval, FE may make a conclusion that the CE is dead or the
> association to the CE is lost.
>
>    . FE Heartbeat Interval (FE HI) - to command FE to use the interval for the
> FE Heartbeat Message generation. If set to 0, it means FE must choose a
default
> value. (Comments: Note that CE does not need to set heartbeat dead interval
for
> FE.)
>
> ---
>
> Because of the change with the ACK flag usage in Heartbeat Message, Section
6.9
> Heartbeat Message should also be changed. I propose the text as below:
>
> ---
> 6.9  Heartbeat Message
>
>    The Heartbeat (HB) Message is used for one ForCES element (FE or CE)
>    to asynchronously notify one or more other ForCES elements in the
>    same ForCES NE on its liveness.
>
>    A Heartbeat Message may be sent by CE or FE. The policies and the related
> parameters for CE or FE to generate and send Heartbeat Messages are defined as
> an attribute of FE protocol LFB, as described in Section 6.2.1 and also
formally
> defined in Appendix C.
>    A Heartbeat Message is, in its PDU, only composed of a common header, with
> the message body left empty. Detailed description of the message is as below.
>
>    Message Transfer Direction:
>        FE to CE, or CE to FE
>
>    Message Header:
>        The Message Type in the message header is set to MessageType =
> 'Heartbeat'.  The ACK flag in the header can be set to the value of 'NoACK' or
> 'AlwaysACK' as defined in Section 5.1. The default behavior for the ACK flag
> that is set to any other value is defined just as the behavior of 'NoACK'.
When
> set to 'NoACK', the message will not expect any response from the receiver.
When
> set to 'AlwaysACK', the Heartbeat Message is then called a Heartbeat Request
> Message, and will then expect a response from its receiver. There is no a
> specific Heartbeat Response Message defined. A normal Heartbeat Message will
act
> as a response to a Heartbeat Request Message by its correlator set to that of
> the responding Heartbeat Request Message and by its ACK flag always set to
> 'NoACK'. Current heartbeat policies as defined in Section 6.2.1 only allow a
> Heartbeat Request Message being sent from CE to FE rather than contrary.
>
>     Message Body:
>        The message body is empty for the Heartbeat Message.
>
> ---
>
> Thanks,
> Weiming