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

Robert Haas <rha@zurich.ibm.com> Sat, 23 October 2004 09:34 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 FAA11639 for <forces-protocol-web-archive@ietf.org>; Sat, 23 Oct 2004 05:34:44 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIVR-0001cn-UL for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 05:48:14 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLII7-0002QP-H4; Sat, 23 Oct 2004 05:34:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLIC8-0007v5-RV for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 05:28:18 -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 FAA11287 for <forces-protocol@ietf.org>; Sat, 23 Oct 2004 05:28:12 -0400 (EDT)
Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIP6-0001UP-Ph for forces-protocol@ietf.org; Sat, 23 Oct 2004 05:41:42 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9N9RGPJ530052; Sat, 23 Oct 2004 05:27:16 -0400
Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9N9REZZ142738; Sat, 23 Oct 2004 05:27:15 -0400
Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA70464; Sat, 23 Oct 2004 11:27:13 +0200
Message-ID: <417A23E6.7010504@zurich.ibm.com>
Date: Sat, 23 Oct 2004 11:27:02 +0200
From: Robert Haas <rha@zurich.ibm.com>
Organization: IBM Research Lab
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: avri@psg.com
References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com>
In-Reply-To: <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id i9N9RGPJ530052
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Content-Transfer-Encoding: quoted-printable
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, Weiming Wang <wmwang@mail.hzic.edu.cn>
Subject: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review.
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.0 (/)
X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48
Content-Transfer-Encoding: quoted-printable

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 ?

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.

-------------------------------------------------------------------------------------------------------------------
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.

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. 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.

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)
    Association Expiry Timer
    Heartbeat Interval
    Primary CE
    FE failover and restart policy
   

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


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:
  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 ?]

-- 
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