Subject: Re: ForCES protocol analysis design team - Report out !

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 25 Mar 2004 13:23:06 -0800

Hi Robert,

Welcome back! Thanks for your comments.
My comments below...

Regards
Hormuzd
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Robert Haas

>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
>  
>
The format of such an ID needs to be ironed out. Here are some thoughts:

For instance, are we going to reserve a specific range for mcast IDs, 
such as in IPv4/v6 ? Shall we support anycast IDs, i.e., allow an FE to 
send a notification to any one CE of a group, the underlying protocol 
possibly choosing the least loaded CE, etc.

[HK] Yes the format does need to be ironed out and so does the length.
The IDs will be used to address a single FE/CE, groups or all FEs/CEs.
I believe they will be independent of the interconnect so whether it is
IPv4/v6, etc doesn't matter. Also, there was agreement that the FE ID
will
be assigned by the CE...I forgot to mention this.

>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.
>
It is good to be able to address elements by type, and not only by ID. 
This permits things such as: "send this route update from a given CE to 
all IPv4 routing LFBs in all FEs", therefore makes it very simple to 
configure.
[HK] Sure, I agree this will be a good to have feature. 
But how this is done is TBD for now.

>
>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
>
LFB Type ID seems a good candidate for an option header (see IPv6). More

candidates can be even added later.
[HK] I believe we would like to have a fixed length header, whether LFB
type
is part of it or not is TBD.

>Issue# 2 Multiple channels/connections:-
>There was a lot of discussion on this topic as well. There was
agreement
>on the fact that there MUST be a way to prioritize and separate Control
>and Data traffic. There was no clear consensus around mandating using
>separate channels or connections (better term) for Data and Control in
>order to provide this separation. There were reasons presented
regarding
>the ineffectiveness of separate connections to help during DoS attacks
>as well as the reasons for using reliable and unreliable connections
for
>Control and Data respectively. The use of separate
>transports/connections is TBD.
>Note: This issue will be further addressed in context with the TML 
>
What is the objective ? Do you want clients of the PL to specify the 
particular channel they want their message to be sent onto, or do you 
want the client of the PL to only specify the destination ID, and 
possibly a priority ? Or both ? is ForCES connection/channel-oriented or

not, from the client perspective ?

[HK] This is not from the clients of PL point of view, but from the PL
point of view. The PL might want some messages, namely data packets, to 
use an unreliable connection and all other control messages to use a
reliable connection. You can check out the archive for some of the
emails,
exchanged on this topic to get a better idea. Some useful links...
http://www1.ietf.org/mail-archive/working-groups/forces-protocol/current
/mail4.html
http://www1.ietf.org/mail-archive/working-groups/forces-protocol/current
/mail5.html
http://www1.ietf.org/mail-archive/working-groups/forces-protocol/current
/mail6.html