Subject: RE: [Forces-protocol] RE: Summary for issues 0-5

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 22 Mar 2004 13:01:20 -0800

Incorporating Jamal's latest comments...

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

Let me know if there are any others comments.
I will post this summary to the list by end of today (22nd),
unless I get any requests for changes.

Thanks again,
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 22 Mar 2004 16:16:04 -0500

Hormuzd,

You have a lot of verbage on #3 that i didnt thoroughly read. 
Overall looks good. So i would say its ready.

cheers,
jamal