Subject: RE: [Forces-protocol] Issue 0: Application addressing

From: "Putzolu, David" <[email-masked]>
Date: Wed, 10 Mar 2004 17:16:41 -0800

So just to be clear, is the following what people are
proposing?  Or is this too much detail?

Structure of ForCES Message:
------------------
| ForCES Header  |  <- The FE daemon (FEd) receives this. 
|  ( includes    |     Includes stuff that must be in 
|      FEid )    |     every msg e.g. total message length.
|----------------|     
| ForCES Payload |  <- Elaborated below.
------------------
FEd processes this header, then payload (if present,
see below).  FEid may be used by Fed to choose a FE 
instance on a PFE (physical FE) that received the 
message. This could map to a process, a mezannine 
card, or whatever.  Or, if there is only a single FE
that could have received this message (i.e. FE is at
end of a unicast, L3/L2 addressed connection), maybe
FEd just validates FEid is expected value and
continues...

Structure of ForCES Payload:
------------------
| LFB Message    |  <- ForCES Payload is one or more messages
|----------------|     to LFBs. Many LFB messages may
|     ....       |     be bundled in a single ForCES message.
|----------------|     
| LFB Message    |  <- Elaborated below
------------------ 
Payload is 0 or more LFB messages. If 0 LFB messages then
ForCES header is the entire message.

Structure of LFB message:
------------------
| LFB Identifier |  <- Unique ID within the scope of a FE
|                |     telling FEd which LFB should be given
|----------------|     this LFB message.
| LFB Message Len|  <- Tells FEd how long this LFB message
|----------------|     is e.g. 16 bytes.
| LFB Message    |  <- 16 bytes of stuff to be handed to the
| Payload        |     identified LFB. After handing 16 bytes to 
------------------     LFB the FEd moves forward 16 bytes and 
processes next LFB message in same fashion until all done.  
The FEd does not care about the message internals (including 
message type), it just passes them on to LFBs.

Structure of example LFB message payload passed to LFB:
------------------
| LFB Command Typ|  <- Tells LFB what to do e.g. "Add Route"
|----------------|  
| LFB Command Val|  <- Body of command e.g. "prefix = 138.12.0.0,
|                |                           mask = 255.255.0.0,
------------------                           nexthop = 138.12.1.251"

Does the above seem OK?  Not trying to make up something new here,
just to put pictures to the words people have been sending :)

-David

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Deleganes, Ellen M
> Sent: Wednesday, March 10, 2004 5:04 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Forces-protocol] Issue 0: Application addressing
> 
> Jamal,
> 
> I think we are in agreement about the FE ID portion of the addressing
> and what it identifies (an FE instance). It also looks like 
> everyone is
> in agreement that a LFBID and LFBInstanceID are also needed for the
> protocol. Where there appears to be disagreement is whether the LFBID
> and LFBInstanceID belong in the common header or in the TLV.
> 
> I believe, like many others that LFB-related IDs (LFBID and
> LFBInstanceID) belong in the TLV and not the common header. 
> The primary
> reason is to allow one message to affect more than one LFB. 
> This is more
> reasonably handled in the TLV. 
> 
> If we are in agreement that the LFBID and LFBInstanceID are 
> part of the
> TLV, it seems like Issue 0 can be closed. Do others agree?
> 
> Regards,
> Ellen
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jamal Hadi Salim
> Sent: Wednesday, March 10, 2004 4:47 PM
> To: Deleganes, Ellen M
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Forces-protocol] Issue 0: Application addressing
> 
> On Wed, 2004-03-10 at 19:20, Deleganes, Ellen M wrote:
> > So if you have a proxy that is "fronting" for multiple FEs, 
> what does
> > the ID contain? 
> 
> I would think there would be a unique ID for each FE being addressed.
> Protocol doesnt care who is handling it; 
> 
> > If it is the ID of the proxy, how does the proxy know
> > which FE to configure? 
> > I think even in this case the ID should identify
> > the FE so the proxy knows which FE the CE wishes to configure.
> 
> Exactly. So message goes say to IP X which is a proxy; but destination
> ID refers uniquely to the FE.
> 
> >  If this
> > is the case FE ID seems to be appropriate nomenclature. 
> 
> So far we seem to be saying the address looks like:
> 
> ID:=FEID: LFBID: LFBInstanceID
> 
> So you are refering to that one portion of the ID i hope?
> in which case we may have no issues. 
> 
> > How the message gets to the proxy should be transparent to 
> the ForCES
> > protocol. 
> 
> It is.
> 
> > This can be handled by correctly addressing the message (or
> > putting into the right socket or whatever) at the 
> underlying transport
> > the proxy ID should not have to be part of the ForCES protocol. 
> 
> It is not. Nothing in the Forces header helps identify it as a proxy.
> 
> cheers,
> jamal
> 
> 
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 
> _______________________________________________
> Forces-protocol mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/forces-protocol
> 

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 10 Mar 2004 21:49:42 -0500

> Structure of ForCES Message:

Good description.
There will be messages that may terminate at the FEd 
(depending on implementation).
Example discussions with the CEd on capabilities, joining
the NE etc;

> Structure of ForCES Payload:

This is one of the two batching schemes, the other was:

------------------
| ForCES Header1 |  <- The FE daemon (FEd) receives this. 
|  ( includes    |     Includes stuff that must be in 
|      FEid )    |     every msg e.g. total message length.
|----------------|     
| ForCES Payload |  <- Elaborated below.
------------------
| ForCES Header2 |  <- The FE daemon (FEd) receives this. 
|  ( includes    |     Includes stuff that must be in 
|      FEid )    |     every msg e.g. total message length.
|----------------|     
| ForCES Payload |  <- Elaborated below.
------------------
.....
.....
..
------------------
| ForCES Headerx |  <- The FE daemon (FEd) receives this. 
|  ( includes    |     Includes stuff that must be in 
|      FEid )    |     every msg e.g. total message length.
|----------------|     
| ForCES Payload |  <- Elaborated below.
------------------

Of course thats all wrapped around a TCP or UDP, etc
PDU.

> Structure of LFB message:

Essentially above is a TLV.

> Structure of example LFB message payload passed to LFB:

You alos want to be able to blast tons of these add route commands in
one shot using an outer TLV of type "tons of route adds" and a bunch of
inner ones of type "add route".
I have seen an opionion expressed once that defines the values as TLVs
as well; i.e prefix is a type value being 138.12.0.0, mask is a type
with value of 255.255.0.0 , nexthop is a type of value 138.12.1.251.
The idea was proposed by Joel; his arguement which is sane is that
you could add a new TLV at any time and not have to rewrite the
body of the command.
I dont think this is a contentious issue at this point.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 11 Mar 2004 17:47:24 +0800

Hi David,

Some inline comments.

Cheers,
Weiming
----- Original Message -----
From: "Putzolu, David" <[email-masked]>
To: "Deleganes, Ellen M" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 11, 2004 9:16 AM
Subject: RE: [Forces-protocol] Issue 0: Application addressing

[Wang Re: The possible message types at the ForCES payload layer may not just
that of LFB Messages. They may be messages for FE coarse layer operations that
do not mean any LFBs, like FE event report, or may be CE event reports, etc. ]

[Wang Re: Because of the reason I mentioned above, the Type in the message TLV
will have global meaning in ForCES protocol, which means the Type should not
only include all LFB ID types but also Types like FE event report, FE
attributes, and even ACK type. This actually has brought another problem, the
Type space should be larger than space for LFB ID, which means 16bits Type space
is not enough.]

-David