Subject: Re: [Forces-protocol] Protocol Messages

From: [email-masked]
Date: Thu, 15 Apr 2004 23:49:12 +0800

Hi Hormuzd, Jamal, 

To be hornest, I think we have some different ideas on how protocol messages 
are arranged. The difference mainly lies in how detailedly we should categorize 
the messages. I more tend to categorize the messages in more details, seems 
Jamal likes less messages and Hormuzd is in the middle. Therefore, I kindly 
suggest that we all propose our original thoughts first, then we work together 
to summarize them. In this way, I think we may be not easy to leave behind 
something but easy to see if the final conclusion include everything. By 
discussion, we can also exclude things that we don't need. 

I'l first propose my idea (Hormuzd, pls believe I'm not pushing it, just for 
easy discussion) and then try to understand Hormuzd's proposal. 

My proposal is as:

1.  FE (Couase Layer)Management Messages

1.1  FE Join Request Message
1.2  FE Leave Request Message
1.3  FE Capability Query / Response Message
        including (inter) FE topology, etc. 
1.4  FE State Manipulate Message
        for FE Up, Down, Active, Inactive, etc. 
1.5  FE Attribute Manipulate Message
        for FE attribute add, modify, delete, query / response. FE attributes 
include FE couase layer attributes defined by FE model,  attributes for TML 
configurations, for DoS policies, graceful restart policies, etc. FE event 
subscirbe/unsubscibe can also be described as an FE attribute.
1.6  FE Event Report Message
        An FE heartbeat is treated as an FE event.

2. LFB Management Messages

2.1 LFB state Manipulate Message
        for LFB Up, Down, Active, Inactive, etc.
2.2 LFB Capability query / Response Message
        including LFB topology
2.3. LFB Attribute Manipulate Message
        including LFB attribute add, modify, delete, query/resp. , etc.
2.4  LFB event report message
2.5  LFB topology manipulate message
         for Datapath add, modify, delete, query/resp. , etc, including the 
operation on LFB topology. 
  
3. CE Informing Messages
3.1 CE Query request / Response Message
3.2 CE Event Report Message 
        (a CE heatbeat can be defined as a CE event)

4. Managed Object (MO) Management Messages
       MO Get/Set/Resp. Messages 
     (as Jamal said in the reply to Hormuzd's, we need to discuss more on if 
this is needed. My original thought to propose this in GRMP is actually from 
the Requirement and the Framework, where it is required that an MO in the FE 
side is better operated by CE even though the SNMP command first  arrives at 
the FE, that is, the FE should first redirect the SNMP command to CE then let 
CE to do the operation. If we do not like the messages, an alternative way is 
to define FE attribute for such operations, but I still have no idea how such 
attribute should be defined.)

5. Packet Redirection Messages

Pls see more comments in the lines followed.

Best regards,

Weiming

From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi at intel.com> 
Here is an initial list of protocol messages...
(I have tried to merge messages from all 3 protocols without adding too many 
messages)

1.Association Setup Messages
Join Request/Response
Leave Req/Resp

[Weiming] We need to discuss if a Join Response and a Leave Response Message 
here are necessary. The reasons are 
a. it means less, because a FE state maintaince message is still needed to be 
followed to let the FE change the state after the join/leave message;
b. it may result in join/leave flooding attack.

2. Capability Control Messages
Query Req/Resp (including FE, LFB Topology Query)
Capability Req/Resp

[Weiming] I don't see the difference between the two. 

Configuration Req/Resp
[Weiming] I'm not sure the contents for the message. Can you show how an FE 
attribute can be operated via this message?  And do you treat an FE attribute 
or a LFB attribute is also as capability? And moreover,  we also need to 
discuss how a LFB attribute is described here.  This issue is also related to 
which addressing format we are going to use.

3. Control Packet or Traffic Maintenance Messages
CP Redirect to CE
CP Forward to FE

4. Event Notification Messages
Event Register/De-register Req/Resp
[Weiming] We can use an FE attribute to describe such reg./de-reg. operation. 
[/Weiming]
Asynchronous FE Event (including DoS events)

5. Management Object or SNMP support Messages
MO Get/Set
MO Response

6. State Maintenance Messages (or HA related messages)
PE Up/Down
PE Active/InActive (equivalent to the "Move" command that Jamal described)
[Weiming] Seems PE includes FE and CE. I'm not sure if our protocol should take 
care of CE state or not? [/Weiming]

HeartBeat or Keep-alive
[Weiming] I strongly suggest not to explicitly define heartbeat as protocol 
messages, which may have a strong incline protocol users MUST use it.

7. Vendor Specific messages (Optional ?)
VS Request
VS Response
[Weiming] We need to discuss more on how Vendor Support is implemented.

-------------------------------------------------
This mail sent through HUCNIC Webmail system.

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: [email-masked]
Date: Thu, 15 Apr 2004 12:15:04 -0400

Hello All,

Comments/clarification are inline.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Jamal 
> Hadi Salim
> Sent: Wednesday, April 14, 2004 1:54 PM
> To: Khosravi, Hormuzd M
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Forces-protocol] Protocol Messages
> 
> 
> On Fri, 2004-04-09 at 18:20, Khosravi, Hormuzd M wrote:
> > (I have tried to merge messages from all 3 protocols without adding
> > too many messages)
> 
> We need to distinguish which is issued by PL and which by TML.
> 
> This is TML as i see it. i.e the PL never sees these messages.
> The TML MUST send events to the PL (to report the movement to 
> a new peer
> etc)

Not exactly, if you really see only PL only tells the TML where to which endpoint it has associate. 

> Terminates at TML

Not sure - please elborate.

> > Capability Req/Resp
> 
> Both TL and PML play a role.
> 
> The way i would see this is PL-TML interface will
> have the PL register its capabalities, then TML will
> advertise the capability.
> It should also be able to issue these messages as 

> 
> > Configuration Req/Resp
> 
> The real meat.
> TML "routes it" to the PL based on PID.

I think we may have to spell out clearly here.

> Would this be achieved by an LFB redirector at the FE->CE level?
> 
This is different from that. It is between CE and FE endpoints.

> We need to separate between events from TML->PL,
> and PL<->PL

Agree.

> Not sure i see this. Why are we mixing SNMP here?

Same question? 

> Dont understand this part. Are these commands or events?

These are events.

> > HeartBeat or Keep-alive
> 
> Probably two/three types. One for PL<->PL heartbeats another TML<->TML
> heartbeats and maybe TML<->PL

But if you consider PL-PL Heartbeat that includes TML to TML also. Why do we need
seperate TML to TML.

> I think we can have some codes that are "private" - the 
> problem is these
> values must be negotiated if we go that path.

Yes. This is a practice that's done in other protocols.
 
> 
> > Let me know what you guys think. Some of the terminology might be
> > different but the semantics are quite similar in all the protocols.

Yes.

> 
> Good start but theres a lot of details to be ironed out.
> I honestly wasnt thinking clearly after lunch while 
> responding to these
> messages, so i did not scrutinize your categories for message 
> breakdown.

To generalise almost all the messages are request and respone and some may be synchornous.
For events they are  asynhorons messages. We need to add section  how to deal with different 
errors and also the implication on the PL and TML layer.

Regards
Ramg
> I will later on think about it and see if i can add more or generalize
> some of them.
> 
> cheers,
> jamal 
> 
> 
> 
>

---

From: [email-masked]
Date: Thu, 15 Apr 2004 12:07:01 -0400

Hello Weiming,

IMHO, we need to know what are different types of information that are going to be exchanged between FE and CE endpoints and depending upon that it will become easiler to consolidate what goes in common header and what goes next level headers.

Regards
Ramg

> [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: Thursday, April 15, 2004 11:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Hi Hormuzd, Jamal, and all,
> 
> When I finished reply on the protocol messages, I realized 
> that we may not 
> start from this firstly, instead, we should start with the 
> protocol common 
> header at first, because the ideas between us are highly 
> related to what 
> protocol common header should be, e.g., whether the header 
> contains the LFB ID 
> or not.
> 
> Therefore, I suggest to discuss the header first or at the 
> same time with the 
> message discussion. 
> 
> BR
> Weiming
> 
> Quoting Jamal Hadi Salim <[email-masked]>:
> 
> > The TML MUST send events to the PL (to report the movement 
> to a new peer
> > etc)
> > 
> > Terminates at TML.
> > messages, so i did not scrutinize your categories for 
> message breakdown.

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 15 Apr 2004 19:08:40 -0700

Weiming,

I am fine with having discussion on common header in parallel with
protocol messages. I think we resolved most of it except the LFB Type
ID.

regards
Hormuzd

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]

When I finished reply on the protocol messages, I realized that we may
not 
start from this firstly, instead, we should start with the protocol
common 
header at first, because the ideas between us are highly related to what

protocol common header should be, e.g., whether the header contains the
LFB ID 
or not.

Therefore, I suggest to discuss the header first or at the same time
with the 
message discussion. 

BR
Weiming

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 16 Apr 2004 13:19:09 -0700

Here is the header summary that we had published...

Issue# 0 IDs in the header:-
There was a lot of discussion on this topic regarding the naming,
semantics, length of these IDs.
The result was as follows...
Naming: CE ID, FE ID
Semantics: Used to address a single, group or all CEs/FEs respectively
Length: 16-32 bits...TBD

Another issue we reached agreement on was using LFB Type ID, LFB
Instance ID in combination of FE ID for addressing LFBs on the FE. The
LFB Instance ID will be part of the payload. The LFB Type ID location,
whether it is part of header or payload is TBD.

Issue# 1 Header/Encoding:-
Here are the fields in the common header that there was consensus around
IDs: as summarized in issue 0
Version/sub-ver: 4 bits
Sequence No. : 32 bits
Length : 16 bits
Command Type : 8 bits (semantics - TBD)
Flags: 16 bits, including 1-3 bits for Priority. (The semantics/length
of Flags and Priority fields is TBD)
LFB TypeID: TBD, no consensus on whether it is needed or not in the
header
-------------

As you can see, there were very few TBDs, the main one was regarding LFB
Type ID.
I believe most folks agreed that we don't need it in the common header,
but there were different views as well so we can have a discussion on
this.

I will also continue the discussion on Protocol messages, I think that's
also important and will help clarify our direction further.

Regards
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

Can we start with the header and where we left off?
I am trying my best not to respond to any of the other messages
because i think it is important to start with the header.
Hormuzd or maybe it was Weiming i thought in the early days had capturd
these details. If not i can compile.

cheers,
jamal

---

From: [email-masked]
Date: Mon, 19 Apr 2004 10:04:26 -0400

Hello All,

Comments are inline.

> [mailto:[email-masked]]On Behalf Of ext Khosravi,
> Hormuzd M
> Sent: Friday, April 16, 2004 4:19 PM
> To: [email-masked]; Weiming Wang
> Cc: [email-masked]
> Subject: RE: [Forces-protocol] Protocol Messages
> 
> 

<RamG>
Sorry for raising questions - during this topic discussion - my email system had problems.
What is the reason for having the LFB ID being in the common header, if we support command
bundling there will be more than one LFB ID getting affecting by that opreations. When a  CE sends
a message, the receipt FE will parse the sub-header (or next header) depending upon the message type
and act accordingly.
<RamG> 

> IDs: as summarized in issue 0
ok.

> Length : 16 bits 

<RamG>
Length in dword.
<RamG>

> Command Type : 8 bits (semantics - TBD)

<RamG>
We need to list the number of messages, classify them logically and then split it.
For example, startup messages, operational messages, configuration messages, etc.
These messages were discussed in earlier threads of emails.
<RamG>

> of Flags and Priority fields is TBD)

<RamG>
Let us list out fields we require...
- Priority 
- Command Building 
- Two phase commit
- 

Please add the information and then we can filter how to incorporate these.
<RamG>

> LFB TypeID: TBD, no consensus on whether it is needed or not in the

<RamG>
See my above explanation.  In some scnerio it may be ok but in general we can move it to sub header.
CE talks to FE endpoints and FE endpoint knows how to decoded the sub header and pass it on to 
LFB blocks.
<RamG>

Regards
Ramg