Subject: updated text - rest of sec6

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 13 Oct 2005 08:34:41 -0400

More text for review from sec 6.3 to end of section 6. This section is
updated just to reflect the grammar updates - so nothing controversial.
The sections that needs to be stared at the most is the config message
followed by the table at the end (which needs to be validated against
each message). I have added an extra column to the table to be more
reflective of the grammar.

The two core LFBs and the heartbeat section remain outstanding in this
section. If i dont hear from Weiming by end of day, I will attack the HB
message followed by the core LFBS. We are getting there ... 

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Thu, 13 Oct 2005 22:51:47 +0800

Jamal,

attached is the update I tried for the HB message. Pls feel free to modify it.

Thank,
Weiming

---

From: Weiming Wang <[email-masked]>
Date: Thu, 13 Oct 2005 22:58:03 +0800

I don't know why the attached file does not appear. just resend it.

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

---

From: Weiming Wang <[email-masked]>
Date: Thu, 13 Oct 2005 23:05:56 +0800

I don't know what happened. Just post it inside then.

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, while the FE protocol LFB attribute
   ,the Heartbeat policy and parameters, defined in Section 6.2.1 defines
   how the Heartbeat Message should be used by CE or FE. This section only
   defines the Heartbeat Message data format.

   A little different from other protocol messages, a Heartbeat message is only
   composed of a common header, while the message body is always 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 'NoACK'
       or 'AlwyasACK'. when set to 'AlwaysACK', the HB Message is always
       expecitng a response from its receiver. For a HB Message, we define
       that its response still has the data format as a normal HB Message
       that is sent back by the original HB Message receiver. For a HB Message
       acting as a response, its ACK flag should alwways be set to 'NoACK',
       meaning no further response should be given for the message. The
       default behavior for the ACK flag is set to no response for the HB
       Message.  This happens when the ACK flag is set to values other than
       'NoACK' and 'AlwaysACK'.  The correlator field in the messge header
       MUST be set if a response is expected, so that a receiver can correlate
       the response correctly. The correlator field can be ignored if
       no response is expected. Also note that by the current Heartbeat policies
       defined' in Section 6.2.1, only CE can possibly send a HB Message with a
       response request.

   Message Body:
       The message body is empty for the Heartbeat Message.

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 13 Oct 2005 13:56:45 -0400

Thanks for the text Weiming. I have updated to read as follows:

---

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 is sent by a ForCES element periodically.  The
   parameterization and policy definition for heartbeats for an FE is
   managed as attributes of the FE protocol LFB, and can be set by CE
   via a config message.  The Heartbeat message is a little different
   from other protocol messages in that it is only composed of a common
   header, with the message body left empty.  Detailed description of
   the message is as below.

   Message Header:
       The Message Type in the message header is set to MessageType =
       'Heartbeat'.  Section 3.3.2 describes the HB mechanisms used.
       The ACK flag in the header can be set to 'NoACK' or 'AlwaysACK'
       when the HB is sent.  When set to 'AlwaysACK', the HB Message
       sender is always expecting a response from its receiver.  When a
       response is sent it is always an echo of the original message
       with reversed IDs and the ACK information set to 'NoACK'.  When
       not soliciting for response(default behavior), the ACK flag is
       set to 'NoACK' The correlator field in the HB message header must

       be set accordingly when a response is expected so that a receiver
       can correlate the response correctly.  The correlator field can
       be ignored if no response is expected.  Also note that by virtue
       of Heartbeat policies defined in Section 6.2.1 only CE can send a
       HB Message with a response request.

   Message Body:
-------------

I have also introduced a new section 3.3.2 with the following text:

----------------
3.3.2.  Heartbeating Mechanism

   Hearbeats between FEs and CEs are traffic sensitive.  A HB is sent
   only if no PL traffic is sent between the CE and FE within a
   configured interval.  This has the effect of reducing the amount of
   HB traffic in the case of busy PL periods.

   A HB can be sourced by either the CE or FE.  When sourced by the CE,
   a response can be requested (similar to the ICMP ping protocol).  The
   FE can only generate HBs in the case of being configured to do so by
   the CE.  Refer to Section 3.3.3 and Section 6.9 for details.
---------------

Please comment

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Fri, 14 Oct 2005 09:27:08 +0800

Jamal, that looks good to me.

Only one thing is, maybe it is better to mention the Section 6.2.1 Heartbeat
policy attribute in Section 3.3.2( Heartbeating Mechanism) as well.

cheers,
weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 13 Oct 2005 22:12:44 -0400

> policy attribute in Section 3.3.2( Heartbeating Mechanism) as well.

Weiming,

I actually meant to have 6.2.1 instead of 3.3.3 or do you mean i should
add 6.2.1 in addition ?

cheers,
jamal