Subject: ForCES protocol analysis design team - Report out !

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 22 Mar 2004 17:29:44 -0800

Hi All,

Great news...There is consensus in the protocol analysis team that a
merged protocol proposal is possible !!

Here is a brief summary of all the protocol issues discussed by the team
so far...

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

-----
There was a general consensus about separation of the ForCES PL
(protocol layer) from the TML (Transport Mapping Layer) ala GSMP. The
link below provides a good explanation of these layers...
http://www.sstanamera.com/~forces/proto/ForCESLayered.htm
The issues 2-5 below will be satisfied by the TML.
-----
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 

Issue# 3 Transport: unicast/multicast/broadcast:-
The protocol team reached consensus that ForCES would define a
set of transport requirements that must be met by any transport
implementation.  These requirements include an assumption of
support for prioritized connections, a reliable, ordered
unicast delivery service, and a multicast delivery service
(details TBD).

The protocol team reached consensus that a set of concrete
transport mappings would be defined in order to achieve
interoperability on different transports.  An IP TML will
be defined that adheres to charter guidelines in regards to
use of a RFC2914-compliant transport, per AD feedback.  
Other non-IP TMLs will be defined as well.

There was some consensus around this text to describe the details...

All ForCES protocol implementations, MUST support a reliable, congestion
aware Unicast method of communication between the CEs and the FEs.
Furthermore, in case of IP this will be a TCP or SCTP connection between
the CE and FEs. In addition to this, in case of 'close proximity'
between the CEs and FEs And in case the interconnect between them
supports multicast, the CEs and FEs Must also establish reliable,
congestion aware Multicast connections. (The establishment and semantics
of these Multicast connections is negotiated during the
binding/capability discovery phase in the ForCES protocol or during
pre-association - TBD). For example, the CE and subset of FEs might
negotiate on establishing a Multicast connection for communication of
IPv4 LFB attributes. These reliable, congestion aware connections will
be used to communicate the control messages outlined in RFC 3654
(section 6, #6c). (For data messages such as those outlined in RFC 3654
(section 6, #6b), the ForCES protocol Must/Should also support an
un-reliable but congestion aware Unicast connection between the CE and
FEs.- TBD:issue# 2)

Issue# 4 Congestion control:-
General consensus was that Congestion Control (CC) is a MUST for the
protocol for all messages, whether Control or Data in order to meet the
basic scalability requirement. There was also some discussion around DoS
protection in context with CC, but this is still being discussed.
Note: This issue will be further addressed in context with TML

Issue# 5 Reliability:-
General consensus was that Reliability is a MUST for all control
messages. The separation of TML from PL has provided the team the
opportunity to make progress on the PL and defer the details of the TML
for now. This issue is also closely related to issue# 3 and both were
discussed in parallel to some extent.
Note: This issue will be further addressed in context with TML

In general, I think we made great progress in just a month !
Thanks to everyone who participated !

Regards
Hormuzd

---

From: Robert Haas <[email-masked]>
Date: Wed, 24 Mar 2004 19:45:07 +0100

See comments inline ...

>Semantics: Used to address a single, group or all CEs/FEs respectively
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.

>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.

>LFB TypeID: TBD, no consensus on whether it is needed or not in the
LFB Type ID seems a good candidate for an option header (see IPv6). More 
candidates can be even added later.

>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 ?

>pre-association - TBD).
I agree with the above provided that this does not mandate the use of an 
underlying reliable mcast transport only. Given the reliability 
guaranteed at the PL, this can hide a potential inherent unreliability 
of a particular transport.

> For example, the CE and subset of FEs might
seems that you imply multi-unicast here.

>Note: This issue will be further addressed in context with TML
It is indeed a MUST, but it is completely superfluous if there is only 1 
hop ... Do you see what I mean ?

>Note: This issue will be further addressed in context with TML
Regards,

-- 
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