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

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

Incorporating Weiming's, Jamal's 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 IDs will be part of the payload.

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)

TypeID: TBD, no consensus on whether it is needed or not

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 (see
below)

Issue# 3 Transport: unicast/multicast/broadcast:-
There was some consensus around this text to describe this issue...

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)

David provided some clarification to the group on this issue via his
email below...
https://www1.ietf.org/mail-archive/working-groups/forces-protocol/curren
t/msg00317.html
There seems to be consensus around the approaches outlined by David in
his email.

There was also 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

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

Thanks
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 14:16:03 -0500

Hormuzd,
Since you are putting a lot of effort in this; i am gonna respond.
My view is this should not be taking the time it is.
It doesnt gain us much in terms of moving forward.

I will do the write up for the HA piece next.

> LFB IDs will be part of the payload.

Did you mean LFB instance ID?

> TypeID: TBD, no consensus on whether it is needed or not

In issue 0 you talk about LFB typeID. This is the same thing, no?

Issues 2-5: I think that TML should be introduced first then you should
talk about TML satisfying those issues.
Infact i feel there is no point in mentioning any protocols by name
since its the TML thats responsible for delivering 2-5. Granted it may
want to use TCP - but thats just an example.

cheers,
jamal