Subject: [Forces-protocol] Section 6 update

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 22 Oct 2004 01:35:49 -0700

Hi Robert, All

Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly used the text that Jamal sent out wherever applicable.

You can update sections 6.2, 6.4, 6.5 -> however, I would check with Weiming first as courtesy since he is working on these sections.

BTW, there were lots of things in the todo list I sent out...

Header Section - Jamal/Robert/Weiming?

Protocol LFB - Robert/Others?

FE LFB - Robert/Others?

CE LFB - ?

State Machine for Protocol - Ligang (taken)

Will you be working on any of these ??

Pls do let us know...I will start working on whatever hasn't been claimed by tomorrow morning my time.

Thanks

Hormuzd

________________________________

From: Robert Haas [mailto:[email-masked]] 
Sent: Friday, October 22, 2004 12:39 AM
To: Khosravi, Hormuzd M
Cc: Ligang Dong; [email-masked]; [email-masked]; [email-masked]; Weiming Wang; [email-masked]
Subject: Re: Applying changes to Section 6 (Protocol Messages)

Hormuzd,
Could you please pass the token on section 6 together with your latest version so I can start editing it ?
Thanks,
-Robert

Khosravi, Hormuzd M wrote:

Robert,

As I said, your note mostly looks...I have put some more comments below...

(It would help a lot if you start defining the FE, Protocol LFBs...)

________________________________

From: Robert Haas [mailto:[email-masked]] 

All: below is a rough list of changes and pending issues regarding section 6. Please review.

 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, this would be part of ProtocolLFB even if it is in this message] 

 6.1.2 How has the srcID=0 case been handled in the interop tests ? Is this really feasible ?  [Yes it worked fine during Interop] 

 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.  [Agreed it would be in some LFB, but not sure which LFB this would be part of...?] 

 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB.  [Sure, why dont you start defining some of these objects...then we can discuss more in detail] 

 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB.  [Yes, these messages will be part of Events or Config...we need to specify this] 

 6.7 HB remains as is.  [Agreed] 

In summary, we have the following operations defined for each message type ( I broke the table into 3 parts):
 [looks good!] 
OPERATION       APPLICABLE MESSAGE TYPES

                Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat

no operations
defined

                Query  Query-Resp  Config  Config-Resp
SET, DEL, UPDATE                     x          x
GET               x         x
EV_S, EV_U                           x          x

(for event subscribe/unsubscribe)

                Packet-Redir

PAYLOAD            x

                Event-Notif  Event-Notif-Resp
EVENT              x                x

Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ?  [These are all very different, lets leave them as is, its not necessary to have multiple operations in all messages] 

Regards,
-Robert

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 22 Oct 2004 17:09:27 +0800

Robert, 

Don't worry too much about the FE LFB and Protocol LFB, I think it can be fit it well in the sections.

Actually I can do something for Protocol LFB and FE LFB if you think possible.

Regards,
Weiming

----- Original Message ----- 
  From: Khosravi, Hormuzd M 
  To: Robert Haas 
  Cc: Ligang Dong ; [email-masked] ; [email-masked] ; [email-masked] ; Weiming Wang ; [email-masked] 
  Sent: Friday, October 22, 2004 4:35 PM
  Subject: Section 6 update

  Hi Robert, All

  Here you go.I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly used the text that Jamal sent out wherever applicable.

  BTW, there were lots of things in the todo list I sent out.

  FE LFB - Robert/Others?

  CE LFB - ?

  Pls do let us know.I will start working on whatever hasn't been claimed by tomorrow morning my time.

  Thanks

  Hormuzd

------------------------------------------------------------------------------

  Hormuzd,

  Robert,

------------------------------------------------------------------------------

  no operations
  defined

                  Packet-Redir

  PAYLOAD            x

  Regards,
  -Robert

---

From: Robert Haas <[email-masked]>
Date: Fri, 22 Oct 2004 11:28:09 +0200

Hi Hormuzd,
Yes, I will take care of the FE, CE, and Protocol LFBs.
In-line are some comments to your updates. Good job to you and Weiming. 
We still need to refine a few things. Please review and let me know.
-Robert

Khosravi, Hormuzd M wrote:

> 6. Protocol Messages
>
>The general structure of most messages is as follows in BNF format:
>
>PL level PDU : = MAINHDR<LFBselect>+ 
>LFBselect := LFBCLASSID LFBInstance <OPER>+
>OPER:= <OPERATION [<path-data>]*>+
>
>  
>
I think we should now make our terminology consistent and use "FE LFB" 
and "FE Protocol LFB" instead of Object or Managed Object. I know it 
will make Weiming unhappy, but I find it less confusing. The reason is 
that we treat regular LFBs and the FE Object and FE Protocol Object in 
the same manner in the protocol ("Everything is an LFB").

>- MAINHDR defines msg type, Target FE/CE ID etc.
>the MAINHDR also defines the content. As an example the content of
>a "config" message would be different from an "association" message.
>- LFBCLASSID is a 32 bit unique identifier per LFB class defined
>at class creation time.
>- LFBInstance is a 32 bit unique instance identifier of an LFB class
>- OPERATION is one of {ADD,DEL,etc.} depending on the message type
>
>The path-data identifies the exact element targeted.
>It may have zero or more data values associated.
>
>In summary this approach has the following characteristic:
>- there can be one or more LFB Class + InstanceId combo
>targeted in a message (batch)
>- There can one or more operation on an addressed LFB 
>classid+instanceid combo(batch) 
>- There can be one or more path targets per operation (batch)
>- paths may have zero or more data values associated (flexibility
>and operation specific)
>
>It should be noted that the above is optimized for the case of a
>a single classid+instance targeting. To target multiple instances
>within the same class, multiple LFBselect are needed. 
>
>
>6.1  Association Messages
>
>   The ForCES Association messages are used to establish and teardown
>   associations between FEs and CEs.
>
>6.1.1  Association Setup Message
>
>   This message is sent by the FE to the CE to setup a ForCES
>   association between them.  This message could also be used by CEs to
>   join a ForCES NE, however CE-to-CE communication is not covered by
>   this protocol.
>
>   Message transfer direction:
>      FE to CE
>   Message Header:
>      The Message Type in the header is set MessageType= 'Association
>      Setup'.  The ACK flag in the header is ignored, because the setup
>      message will always expect to get a response from the message
>      receiver (CE) whether the setup is successful or not.  The Src ID
>      (FE ID) may be set to O in the header which means that the FE
>      would like the CE to assign a FE ID for the FE in the setup
>      response message.
>   Message body:
>      The setup message body consists of LFBSelect & FE Name TLV, the format of
>      which is as follows:
>
>main hdr (eg type =  Association setup)
>     |
>     |
>     +--- T = LFBselect
>     |        |
>     |        +-- LFBCLASSID = FE object
>     |        |
>     |        |
>     |        +-- LFBInstance = 0x1
>     |        
>     +--- T = FENAME
>              |
>              +-- "myname"
>
>
>  
>
To me, FE Name is an attribute of the FE Protocol Object/LFB (not the FE 
Object/LFB) that can be advertised by the FE. Let's define a new "SHOW" 
operation for that purpose.

The message would therefore look like:

main hdr (eg type =  Association setup)
     |
     |
     +--- T = LFBselect
              |
              +-- LFBCLASSID = FE object
              |
              |
              +-- LFBInstance = 0x1

              |
              |
              +-- T = operation SHOW
                  |
                  +-- FE NAME (path target)

What do you think ? A better name than "SHOW" ?

>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        Type = LFB select      |               Length          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 LFB Class ID = FE Object                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        LFB Instance ID                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                                                               .
>       |                   FE Object LFB (including HBI, etc)          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        Type = FE Name         |               Length          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                                                               .
>       |                       FE Name string                          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                                Figure 8
>
>   Type (16 bits):
>      LFB Select.
>   Length (16 bits):
>      Length of the TLV including the T and L fields, in bytes.
>   FE Object LFB:
>      The FE parameters e.g. HBI will be exchanged with the CE using this LFB.
>  
>
>   FE Name String:
>      This is a variable length string which contains the FE name and
>      is encoded in a TLV.
>
>      Editorial Note:  In certain situations (such as use of multicast
>                       IDs), it might not be possible to make use of the
>                       procedure described above for the FE to
>                       dynamically obtain an ID from the CE.  Such
>                       situations need to be identified.
>
>6.1.2  Association Setup Response Message
>
>   This message is sent by the CE to the FE in response to the Setup
>   message.  It indicates to the FE whether the setup is successful or
>   not, i.e.  whether an association is established.
>
>   Message transfer direction:
>       CE to FE
>   Message Header:
>       The Message Type in the header is set MessageType= 'Setup
>       Response'.  The ACK flag in the header is always ignored, because
>       the setup response message will never expect to get any more
>       response from the message receiver (FE).  The Dst ID in the
>       header will be set to some FE ID value assigned by the CE if the
>       FE had requested that in the setup message (by SrcID = 0).
>   Message body:
>       The setup response message body consists of LFBSelect & Result TLV, the format
>       of which is as follows:
>
>
>main hdr (eg type =  Association setup response)
>     |
>     |
>     +--- T = LFBselect
>     |        |
>     |        +-- LFBCLASSID = FE object
>     |        |
>     |        |
>     |        +-- LFBInstance = 0x1
>     |        
>     +--- T = FEResult
>              |
>              +-- resultvalue
>
>
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        Type = LFB select      |               Length          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 LFB Class ID = FE Object                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        LFB Instance ID                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                                                               .
>       |                   FE Object LFB (including HBI, etc)          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |       Type = Result           |               Length          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Result                |              Reserved         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                                Figure 9
>
>   Type (16 bits):
>       LFB Select.
>   Length (16 bits):
>       Length of the TLV including the T and L fields, in bytes.
>   FE Object LFB:
>      The FE parameters e.g. HBI may be exchanged using this LFB.
>   Result (16 bits):
>       This indicates whether the setup msg was successful or whether
>       the FE request was rejected by the CE.
>
>6.1.3  Association Teardown Message
>
>   This message can be sent by the FE or CE to any ForCES element to end
>   its ForCES association with that element.
>
>   Message transfer direction:
>       CE to FE, or FE to CE (or CE to CE)
>   Message Header:
>       The Message Type in the header is set MessageType= "Asso.
>       Teardown".  The ACK flag in the header is always ignored,
>       because the teardown message will never expect to get any
>       response from the message receiver.
>   Message body:
>       The association teardown message body consists of LFBSelect & FEReason TLV, the
>       format of which is as follows:
>
>main hdr (eg type =  Association tear)
>     |
>     |
>     +--- T = LFBselect
>     |        |
>     |        +-- LFBCLASSID = FE object
>     |        |
>     |        |
>     |        +-- LFBInstance = 0x1
>     |        
>     +--- T = FEReason
>              |
>              +-- "myreason"
>
>
>
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |        Type = LFB select      |               Length          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 LFB Class ID = FE Object                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        LFB Instance ID                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                                                               .
>       |                   FE Object LFB (including HBI, etc)          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Type = T.reason       |               Length          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                   Reason                                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                               Figure 10
>
>   Type (16 bits):
>       LFB Select.
>   Length (16 bits):
>       Length of the TLV including the T and L fields, in bytes.
>   FE Object LFB:
>      The FE parameters may be exchanged using this LFB.
>   T.reason (32 bits):
>       This indicates the reason why the association is being
>       terminated.
>
>
>6.3  Configuration Messages
>
>   The ForCES Configuration messages are used by the CEs to configure
>   the FEs in a ForCES NE and report the results back to the CE.
>
>6.3.1  Config Message
>
>   This message is sent by the CE to the FE to configure FE or LFB
>   attributes.  This message is also used by the CE to subscribe/
>   unsubscribe to FE, LFB events.
>
>   Message transfer direction:
>       CE to FE
>   Message Header:
>       The Message Type in the header is set MessageType= 'Config'.  The
>       ACK flag in the header is can be used by the CE to turn off any
>       response from the FE.  The default behavior is to turn on the ACK
>       to get the config response from the FE.
>   Message body:
>       The Config message body consists of one or more TLVs, the format
>       of the TLVs/message is as follows:
>
>
>main hdr (eg type = config)
>     |
>     |
>     +--- T = LFBselect
>     |        |
>     |        +-- LFBCLASSID = target LFB class
>     |        |
>     |        |
>     |        +-- LFBInstance = target LFB instance 
>     |        |
>     |        |
>     |        +-- T = operation { ADD, DEL,  etc}
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        |        // under discussion
>     |        |
>     |        +-- T = operation { ADD, DEL,  etc}
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        |        // under discussion
>     |        |
>     |        +-- T = operation { ADD, DEL,  etc}
>     |        |   |
>     |        |   +--  // one or more path targets 
>     |        |        // under discussion
>     |        |
>
>
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |        Type = LFB select      |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          LFB Class ID                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        LFB Instance ID                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (ADD)    |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           Event Type          |           Reserved            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Config data                           |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (DEL)    |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |           Event Type          |             Reserved          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Config data                           |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                               Figure 16
>
>   Type (16 bits):
>       LFB Select.
>   Length (16 bits):
>       Length of the TLV including the T and L fields, in bytes.
>   LFB Class ID (16 bits):
>       This field uniquely recognizes the LFB class/type.
>   LFB Instance ID (16 bits):
>       This field uniquely identifies the LFB instance.
>
>   Type (16 bits):
>       The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE,
>       UNSUBSCRIBE, CANCEL.  The following Types are defined for this
>       TLV:
>       *   Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe
>           events
>   Length (16 bits):
>       Length of the TLV including the T and L fields, in bytes.
>   Event Type (16 bits):
>       For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field
>       will define the Events of interest.  Examples of Event Type
>       include, All Events, FE Events, LFB Events, Packets, Packet
>       Mirroring.
>  
>
I am not comfortable with these Event Type flags that appear for every 
operation (ADD, GET, DEL, etc) but are only used for EV_S and EV_U.

I propose to do this differently:

main hdr (eg type = config)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance 
     |        |
     |        |
     |        +-- T = operation = EV_S
     |        |   |
     |        |   +--  // one or more path targets (i.e., events to subscribe) 
     |        |        // under discussion

And define the following attributes in their respective LFB/Objects:
 - in each specific LFB (including the FE Object), an attribute for each 
event it can fire, and possibly an attribute for "AllLFBEvents" that can 
be subscribed to and corresponds to subscribing to all events of that 
LFB (model team should look at this).
I don't know what a "Packets", or "Packet Mirroring" event corresponds 
to. If this is a redirected packet, then we have already a special 
message type for it.

>   Config Data (variable length):
>       This will carry LFB specific data (<path>,single or Array LFB specific
>       entries).  The config data might itself be of the form of a TLV.
>
>*Note: FE Activate/Deactivate, Shutdown FE commands for State Maintenance will
>      be sent using Config messages.
> 
>
>6.3.2  Config Response Message
>
>   This message is sent by the FE to the CE in response to the Config
>   message.  It indicates whether the Config was successful or not on
>   the FE and also gives a detailed response regarding the configuration
>   result of each attribute.
>
>   Message transfer direction:
>       FE to CE
>   Message Header:
>       The Message Type in the header is set MessageType= 'Config
>       Response'.  The ACK flag in the header is always ignored, because
>       the config response message will never expect to get any more
>       response from the message receiver (CE).
>   Message body:
>       The Config response message body consists of one or more TLVs,
>       the format of the TLVs/message is as follows:
>
>
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |        Type = LFB select      |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          LFB Class ID                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        LFB Instance ID                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (ADD)    |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Overall Result            |           reserved            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Config Result                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    Type = Operations (DEL)    |               Length          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Overall Result            |           reserved            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                         Config Result                         |
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                               Figure 17
>
>   Type (16 bits):
>       LFB Select.
>   Length (16 bits):
>       Length of the TLV including the T and L fields, in bytes.
>   LFB Class ID (16 bits):
>       This field uniquely recognizes the LFB class/type.
>   LFB Instance ID (16 bits):
>       This field uniquely identifies the LFB instance.
>
>   Type (16 bits):
>       The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE,
>       UNSUBSCRIBE, CANCEL.  The following Types are defined for this
>       TLV:
>       *   Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe
>           events
>   Length (16 bits):
>       Length of the TLV including the T and L fields, in bytes.
>   Overall Result (16 bits):
>       This indicates the overall result of the config message, whether
>       it was successful or it failed.
>  
>
But you have multiple overall results in the same config message. This 
should be fixed.

>   Config Result (variable length):
>       This will carry LFB specific results (single or Array LFB
>       specific result entries).  The config result might itself be of
>       the form of a TLV.
>
>
>6.6. -> Remove this section
>
>  
>
and I will put the necessary things in the FE Object/LFB or FE Protocol 
Object/LFB.

>6.7  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
>   time interval to send the message is set by the Association Setup
>   Message described in Section 6.1.1.  A little different from other
>   protocol messages, a Heartbeat messge is only composed of a common
>   header, withe the message body left empty.  Detailed description of
>  
>
Typo above (withe).

>   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 SHOULD be set to
>       'NoACK', meaning no response from receiver(s) is expected by the
>       message sender.  Other values of the ACK flag will always be
>       ignored by the message receiver.
>   Message Body:
>       The message body is empty for the Heartbeat Message, so as to
>       grasp more efficiency for message transportation and processing.
>
>
>
>
>  
>

---

From: Robert Haas <[email-masked]>
Date: Fri, 22 Oct 2004 11:33:05 +0200

Weiming.
I suggest we make a  new section "FE LFB and FE Protocol LFB" just 
before Section 5 "Common Header", instead of leaving this to section 
3.3.2. This will reflect the importance of those two LFBs in the 
operation of the protocol.

I'll post my text when ready, please do the same, and we'll merge.

-Robert

Wang,Weiming wrote:

>     From: Khosravi, Hormuzd M <mailto:[email-masked]>
>     To: Robert Haas <mailto:[email-masked]>
>     Cc: Ligang Dong <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]> ; Weiming Wang
>     <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]>
>     Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7
>     (same). I have directly used the text that Jamal sent out wherever
>     applicable.
>
>     You can update sections 6.2, 6.4, 6.5 -> however, I would check
>     with Weiming first as courtesy since he is working on these sections.
>
>      
>
>     ------------------------------------------------------------------------
>
>     Could you please pass the token on section 6 together with your
>     latest version so I can start editing it ?
>     Thanks,
>     -Robert
>
>     ------------------------------------------------------------------------
>
>      6.1.1 Association: The CE could obtain the HBI with a
>     Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg
>     strcutrue, we have to remove HBI from the Assoc Setup msg. 
>     [Agreed, this would be part of ProtocolLFB even if it is in this
>     message] 
>
>      6.1.2 How has the srcID=0 case been handled in the interop tests
>     ? Is this really feasible ?  [Yes it worked fine during Interop] 
>
>      6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes
>     into the FEProtocolLFB.  [Agreed it would be in some LFB, but not
>     sure which LFB this would be part of...?] 
>
>      6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB.
>     Note that for the sake of symmetry, we should introduce a
>     CEProtocolLFB.  [Sure, why dont you start defining some of these
>     objects...then we can discuss more in detail] 
>
>      6.6 State Maintenance: FE Activate/Deactivate/Shutdown become
>     settable attributes in the FEProtocolLFB.  [Yes, these messages
>     will be part of Events or Config...we need to specify this] 
>
>     In summary, we have the following operations defined for each
>     message type ( I broke the table into 3 parts):
>      [looks good!] 
>     Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp),
>     we have each time only one operation. Looks a bit redundant. Ideas
>     ?  [These are all very different, lets leave them as is, its not
>     necessary to have multiple operations in all messages] 
>
>     Regards,
>     -Robert
>
>
>
>-- 
>
>Robert Haas
>
>phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha <http://www.zurich.ibm.com/%7Erha>
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 22 Oct 2004 18:44:19 +0800

Hi Robert,
  ----- Original Message ----- 
  From: Robert Haas 
  To: Wang,Weiming 
  Cc: Khosravi, Hormuzd M ; Ligang Dong ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Friday, October 22, 2004 5:33 PM
  Subject: Re: Section 6 update

  Weiming.
  I suggest we make a  new section "FE LFB and FE Protocol LFB" just before Section 5 "Common Header", instead of leaving this to section 3.3.2. 
  This will reflect the importance of those two LFBs in the operation of the protocol.
  [Weiming]I'm not objective to this, just a little worry if it may make the whoel text change too much(some cross references of section number). What I see more is if we need to add a sub section to detailedly define the attributes mentioned. Talking about this, one thing I'm not very sure of your idea is, do you think these attributes of LFBs (or even the whole LFB definition ) should be defined by our protocol or by FE model? I just see that there is some logical problem if it is defined by FE model.

  I'll post my text when ready, please do the same, and we'll merge.
  [Weiming]I think your current version has already done well and  made good summary on the issue. I'l be more interested in trying to input something based on your text. To join in, because as you know this part is one of that I'm most interested and I hope to have more exchange with you on this later.  We'v actually implemented such model in our testbed. 
  Best regards,
  Weiming

  -Robert

  Wang,Weiming wrote:

    Robert, 

    Regards,
    Weiming

    ----- Original Message ----- 
      From: Khosravi, Hormuzd M 
      To: Robert Haas 
      Cc: Ligang Dong ; [email-masked] ; [email-masked] ; [email-masked] ; Weiming Wang ; [email-masked] 
      Sent: Friday, October 22, 2004 4:35 PM
      Subject: Section 6 update

      Hi Robert, All

      FE LFB - Robert/Others?

      CE LFB - ?

      Thanks

      Hormuzd

--------------------------------------------------------------------------

      Hormuzd,

      Robert,

--------------------------------------------------------------------------

      no operations
      defined

                      Packet-Redir

      PAYLOAD            x

      Regards,
      -Robert

---

From: Jamal Hadi Salim <[email-masked]>
Date: 22 Oct 2004 07:05:59 -0400

Weiming/Robert,

Also dont forget to look at the overview section in the latest draft
posted by Avri. Theres a little refinement of the split of the two LFBs
(each in its own section).
As to what to do about the FE Object and FE Protocol object, My opinion
is we should define everything taht we think we will need. 
I would think the model team will take those needs and make sure its
part of the XML spec. Weiming, are you suggesting to do the xml from us?

cheers,
jamal

On Fri, 2004-10-22 at 06:44, Wang,Weiming wrote:
>         Cc: Khosravi, Hormuzd M ; Ligang Dong ; [email-masked] ;
>         [email-masked] ; [email-masked] ; [email-masked]
>         I suggest we make a  new section "FE LFB and FE Protocol LFB"
>         just before Section 5 "Common Header", instead of leaving this
>         to section 3.3.2. 
>         [Weiming]I'm not objective to this, just a little worry if it
>         may make the whoel text change too much(some cross references
>         of section number). What I see more is if we need to add a sub
>         section to detailedly define the attributes mentioned. Talking
>         about this, one thing I'm not very sure of your idea is, do
>         you think these attributes of LFBs (or even the whole LFB
>         definition ) should be defined by our protocol or by FE model?
>         I just see that there is some logical problem if it is defined
>         by FE model.
>         
>         [Weiming]I think your current version has already done well
>         and  made good summary on the issue. I'l be more interested in
>         trying to input something based on your text. To join
>         in, because as you know this part is one of that I'm most
>         interested and I hope to have more exchange with you on this
>         later.  We'v actually implemented such model in our testbed. 
>         Best regards,
>         Weiming
>         -Robert
>         
>         Wang,Weiming wrote:
>         
>         > Robert, 
>         >  
>         > Don't worry too much about the FE LFB and Protocol LFB, I
>         > think it can be fit it well in the sections.
>         >  
>         >         Cc: Ligang Dong ; [email-masked] ; [email-masked] ;
>         >         [email-masked] ; Weiming Wang ;
>         >         [email-masked]
>         >         Here you goI have updated sections 6.1, 6.3, 6.6
>         >         (remove), 6.7 (same). I have directly used the text
>         >         that Jamal sent out wherever applicable.
>         >         
>         >         You can update sections 6.2, 6.4, 6.5 -> however, I
>         >         would check with Weiming first as courtesy since he
>         >         is working on these sections.
>         >         
>         >          
>         >         
>         >         BTW, there were lots of things in the todo list I
>         >         sent out
>         >         
>         >          
>         >         
>         >         State Machine for Protocol  Ligang (taken)
>         >         
>         >          
>         >         
>         >         Pls do let us knowI will start working on whatever
>         >         hasnt been claimed by tomorrow morning my time.
>         >         
>         >          
>         >         
>         >         Thanks
>         >         
>         >         Hormuzd
>         >         
>         >          
>         >         
>         >                                   
>         >         ____________________________________________________
>         >         
>         >         Cc: Ligang Dong; [email-masked]; [email-masked];
>         >         [email-masked]; Weiming Wang;
>         >         [email-masked]
>         >         Could you please pass the token on section 6
>         >         together with your latest version so I can start
>         >         editing it ?
>         >         Thanks,
>         >         -Robert
>         >         
>         >         ____________________________________________________
>         >         
>         >         All: below is a rough list of changes and pending
>         >         issues regarding section 6. Please review.
>         >         
>         >          6.1.1 Association: The CE could obtain the HBI with
>         >         a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given
>         >         the new Assoc msg strcutrue, we have to remove HBI
>         >         from the Assoc Setup msg.  [Agreed, this would be
>         >         part of ProtocolLFB even if it is in this message] 
>         >         
>         >          6.1.2 How has the srcID=0 case been handled in the
>         >         interop tests ? Is this really feasible ?  [Yes it
>         >         worked fine during Interop] 
>         >         
>         >          6.2 Query: coarse FE info (inter/intra-FE topology,
>         >         etc) goes into the FEProtocolLFB.  [Agreed it would
>         >         be in some LFB, but not sure which LFB this would be
>         >         part of...?] 
>         >         
>         >          6.4: Events: coarse CE and FE events go into
>         >         CE/FEProtocolLFB. Note that for the sake of
>         >         symmetry, we should introduce a CEProtocolLFB. 
>         >         [Sure, why dont you start defining some of these
>         >          6.6 State Maintenance: FE
>         >         Activate/Deactivate/Shutdown become settable
>         >         attributes in the FEProtocolLFB.  [Yes, these
>         >         messages will be part of Events or Config...we need
>         >         to specify this] 
>         >         
>         >         In summary, we have the following operations defined
>         >         for each message type ( I broke the table into 3
>         >         parts):
>         >          [looks good!] 
>         >         Note that for Query(-Resp), Packet-Redir, and
>         >         Event-Notif(-Resp), we have each time only one
>         >         operation. Looks a bit redundant. Ideas ?  [These
>         >         are all very different, lets leave them as is, its
>         >         not necessary to have multiple operations in all
>         >         messages] 
>         >         
>         >         Regards,
>         >         -Robert
>         >         
>         >         
>         >         
>         >         
>         >         -- 
>         >         Robert Haas
> ______________________________________________________________________
>

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 22 Oct 2004 23:27:54 +0800

Hi Jamal, Robert,

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: [Forces-protocol] Re: Section 6 update

> part of the XML spec. Weiming, are you suggesting to do the xml from us?
[Weiming] Yes, but I'm not sure if it should be defined inside this protocol
text or just by another draft. I remember you also mentioned such thought
before. We actually have the same question on Redirect LFBs, anyway any LFB like
things that between FE model and protocol. Now it seems very popular to
summarize everything as LFB, I even think of TML layer as LFBs from PL layer,
but not sure.

cheers,
weiming
> >         >         hasnt been claimed by tomorrow morning my time.

--------------------------------------------------------------------------------

---

From: Jamal Hadi Salim <[email-masked]>
Date: 22 Oct 2004 12:55:20 -0400

> the same manner in the protocol ("Everything is an LFB").

I think we should use consitently the term FE object and FE Protocol
object going forward. I think "Managed object" is generic enough and
useful as well. It actually implies an attribute in my opinion. i.e
something within an LFB that can be targeted by a path.

> To me, FE Name is an attribute of the FE Protocol Object/LFB (not the
> FE Object/LFB) that can be advertised by the FE. 

Agreed. Its an attribute within the FE object LFB. And for that reason
the LFB selector should have a ADD operation with this attribute having
a path.

> Let's define a new "SHOW" operation for that purpose.

> What do you think ? A better name than "SHOW" ?

ADD? ;->

>  - in each specific LFB (including the FE Object), an attribute for
> each event it can fire, and possibly an attribute for "AllLFBEvents"
> that can be subscribed to and corresponds to subscribing to all events
> of that LFB (model team should look at this).

I agree with you.
Can we have a quick call to discuss just section 6? I hadnt paid
attention to it before, but its one of the most important we have.

cheers,
jamal