Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review.

"Weiming Wang" <wmwang@mail.hzic.edu.cn> Sat, 23 October 2004 13:59 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27197 for <forces-protocol-web-archive@ietf.org>; Sat, 23 Oct 2004 09:59:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLMdj-0005um-Oj for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 10:13:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLMMx-0007Ey-Iu; Sat, 23 Oct 2004 09:55:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLMF8-000520-2B for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 09:47:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26658 for <forces-protocol@ietf.org>; Sat, 23 Oct 2004 09:47:34 -0400 (EDT)
Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLMRt-0005gE-PZ for forces-protocol@ietf.org; Sat, 23 Oct 2004 10:01:06 -0400
Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sat, 23 Oct 2004 22:05:22 +0800 (CST)
Received: from wwm1 (unverified [219.82.165.111]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id <B0000086520@mail.gsu.cn>; Sat, 23 Oct 2004 21:41:25 +0800
Message-ID: <005b01c4b907$242b1790$020aa8c0@wwm1>
From: "Weiming Wang" <wmwang@mail.hzic.edu.cn>
To: "Robert Haas" <rha@zurich.ibm.com>, <avri@psg.com>
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com>
Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review.
Date: Sat, 23 Oct 2004 21:49:20 +0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 0.3 (/)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>, ram.gopal@nokia.com, Ligang Dong <donglg@mail.hzic.edu.cn>, forces-protocol@ietf.org, hadi@znyx.com, Wang Weiming <wmwang@mail.hzic.edu.cn>
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f

Hi Robert,

A general comment is:
I think the difference and the sameness of the FE protocol LFB and FE LFB with
the general FE model LFBs should be specifically addressed.

I can see the sameness is:

1. a LFB class id and an instance id are used to address them.
2. contains attributes, capabilities and events that can be operated via
protocol messages.

I can see the difference is:

1. These LFBs will be lunched along the time the FE is started, before first
ForCES protocol message is sent or received, and whose status  should not be
allowed being changed by protocol messages then. Any status operation toward
these LFBs will result in operation error.
2. a defaut value for these LFB attributes are needed , and the instance IDs for
these LFBs are also predefined (I suppose LFBs defined by FE model, whose
instance is configured by PL msg). (you'v described this point)
3. These LFBs will be defined as black blocks that do not have any input or
output ports from FE LFB topology viewpoint.
4. Followed 3, these LFBs will then not be included in FE LFB topology.

can now only think of these, we may have more later.

Some more comments pls see inline for.

regards,
weiming

----- Original Message -----
From: "Robert Haas" <rha@zurich.ibm.com>

All,
Below is a new draft of the sections related to FE/Protocol LFBs. Please
review.

I will also try to add a table summarizing the operations allowed in
each type of PL message. I sent it in a previous message.

BTW, I find it a bit odd to have Query messages defined before Config
messages in Section "Protocol Messages". Does anyone mind changing the
order ?
[Weiming]It's ok to me, and I also see it's not very normal compared with other
systems. One difference with ForCES system is it' query message is first used
than config msg(query capability). Anyway, i agree to change.

Avri,
Please send the xml files once you have updated them. I'll then
incorporate my text below directly taking suggestions/comments into
account, unless you want to do it ;-)

BTW, we'll have to remove the State maintenance section and add a new
chapter for these LFBs (new xml file ?).

Regards,
-Robert


--------------------------------------------------------------------------------
-----------------------------------
We can remove sections 3.3.2 and 3.3.3, and replace them with a single
section that provides an overview of what these "special LFBs":

New section 3.3.2:

Whereas four key PL messages have a specific type assigned (Association
Setup, Response, and Teardown, as well as Heartbeat) mostly for
simplicity and monitoring reasons, all other PL messages follow the LFB
structure as this provides more flexibility for future enhancements. In
addition, this shows how the ForCES protocol itself can be controlled by
the very same type of structures (LFBs) as it uses to control functions
such as IP forwarding, filtering, etc.

To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB,
and CE LFB. These LFBs are detailed in Section XXX. An short description
is provided here:

The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The CE operates on this LFB to subscribe or
unsubscribe to Heartbeat messages, define the Heartbeat interval, or
discover which ForCES protocol version and which TMLs the FE supports.
The FE Protocol LFB also contains the various ForCES ID to be used:
unicast IDs and table of the PL multicast IDs the FE must be listening to.
[TBD: I don't think we need a CE Protocol LFB]

The FE LFB (referred to as "FE attributes" in the model draft) should
not be confused with the FE Protocol Object. The FE LFB is a logical
entity in each FE and contains attributes relative to the FE itself, and
not to the operation of the ForCES protocol between the CE and the FE.
Such attributes can be FEState (refer to model draft), vendor, etc. The
FE LFB contains in particular an table that maps a virtual LFB Instance
ID to one or more Instance IDs of LFBs in the FE.

The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical
entity in each CE and contains attributes relative to the CE itself, and
not to the operation of the ForCES protocol between the CE and the FE.
This LFB can be used to convey event notifications from a CE to FEs.
Some events may be sent by the CE without prior subscription by the FEs.

[Weiming]I just see some repeats here of this section with followed specific
section.

--------------------------------------------------------------------------------
-----------------------------------
The following section should be inserted just before the "Protocol
Messages" section. It provides the detail (in english, not xml) of the LFBs.

Chapter X: FE, CE, and Protocol LFBs.

The following LFBs are used to control the operation of the ForCES
protocol and interact with FEs and CEs.
[Weiming]I think more description include the difference and the sameness of
these LFBs with FE model LFBs) should be described here.

Section X.1 FE Protocol LFB

The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB can be manipulated
using the standard PL messages.
[Weiming]Except the LFB state operations.

The FE Protocol LFB Class ID is assigned
the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There
must always be one and only one instance of the FE Protocol LFB in an
FE. The values of the attributes in the FE Protocol LFB have pre-defined
default values that are specified here. Unless explicit changes are made
to these values using Config messages from the CE, these default values
MUST be used for the operation of the protocol.
[Weiming] do we need to tell which attributes whose value should be preset
default values?

The FE Protocol Object consists of the following elements:

FE Protocol events that can be subscribed/unsubscribed:
    FE heartbeat
    FE TML events (TBD)
 FE Protocol capabilities (read-only):
    Supported ForCES protocol version(s) by the FE
    Supported ForCES FE model(s) by the FE
    Some TML capability description(s)
  FE Protocol attributes (can be read and set):
    Current version of the ForCES protocol
    Current version of the FE model

    FE unicast ID(s) (list)
    FE multicast ID(s) (list)
[Weiming] Can these two be one attribute, only with two tables?

    Association Expiry Timer
    Heartbeat Interval
    Primary CE
    FE failover and restart policy
[Weiming] I suppose to and CE failover or  leave policy, because it is
important. It will tell what FE will do if it finds it can not connect to a CE
and get command from it. By using this plicy, CE can in advance tell the FE to
go inactive, totally go down, or just do whatever it can (graceful restart?) if
CE fails.

Section X.2

The FE LFB is a logical entity in each FE and contains attributes
relative to the FE itself, and not to the operation of the ForCES
protocol.  The FE LFB Class ID is assigned the value 0x2. The FE LFB
Instance ID is assigned the value 0x1. There must always be one and only
one instance of the FE LFB in an FE.

The FE LFB consists of the following elements:
 FE Events:
    FEAllEvents (subscribing to this corresponds to subscribing to all
events below)
    FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover)
    FE DoS alert
    FE capability change
  FE attributes:
    FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode
[Note: this replies the State Maintenance messages])
    MIID table (a list of virtual LFB Instance IDs that map to a list of
Instance IDs of LFBs in that FE [Refer to Zsolt's note])
    FE Behavior Exp. Timer
    HA Mode
    [the attributes below were previously under Query message]
    Inter-FE topology
    Intra-FE topology
[Weiming] although I'm not very sure of other's thoughts, I think the attribute
for FE DoS Protect policy should be needed.  This attribute will be transfered
to TML layer via something (API ?).

Section X.3

The CE LFB is a logical entity in each CE and contains attributes
relative to the CE itself, and not to the operation of the ForCES protocol.

The FE LFB consists of the following elements:
[Weiming] should be CE LFB?
  CE Events:
    CEAllEvents (subscribing to this corresponds to subscribing to all
events below) [Do we want to allow an FE to explicitely subscribe to CE
events ?]
    CEStatusChange (events that signal CE
Up/Down/Active/Inactive/Failover)  [Such events do not necessarily need
to be subscribed to, they can fire even without subscription and inform
the FE]

[TBD: what else do we need in the CE LFB ?]
[Weiming] I see the CE LFB may only have events attributes appearing to FEs. I
don't think CE attributes should be defined.
--
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha


_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol



_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol