Subject: [Forces-protocol] Protocol Messages

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 9 Apr 2004 15:20:25 -0700

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
 
2. Capability Control Messages
Query Req/Resp (including FE, LFB Topology Query)
Capability Req/Resp
Configuration Req/Resp
 
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
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)
HeartBeat or Keep-alive
 
7. Vendor Specific messages (Optional ?)
VS Request
VS Response
 
Let me know what you guys think. Some of the terminology might be
different but the semantics are quite similar in all the protocols.

Regards
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Apr 2004 13:53:49 -0400

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.

> 1.Association Setup Messages

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)

> Query Req/Resp (including FE, LFB Topology Query)

Terminates at TML.

> 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.
 
> 3. Control Packet or Traffic Maintenance Messages

Would this be achieved by an LFB redirector at the FE->CE level?

> Asynchronous FE Event (including DoS events)

We need to separate between events from TML->PL,
and PL<->PL
 
> 5. Management Object or SNMP support Messages

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

> PE Active/InActive (equivalent to the "Move" command that Jamal

Dont understand this part. Are these commands or events?

> HeartBeat or Keep-alive

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

> 7. Vendor Specific messages (Optional ?)

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

> different but the semantics are quite similar in all the protocols.

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.
I will later on think about it and see if i can add more or generalize
some of them.

cheers,
jamal 

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

---

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

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

> I will later on think about it and see if i can add more or generalize

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