Subject: updated section 5 - please review

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 23 Sep 2005 13:43:27 -0400

Includes issues caught by Joel and Weiming as well as decisions on
correlator field.

I am attaching both a diff and the updated text.
For people who dont know how to read diffs - the most important thing to
observe in the diffs i send is the "+" indicates added lines and the
"-" indicates deleted lines.

cheers,
jamal
--- section5.txt	2005-09-20 11:59:59.000000000 -0400
+++ section5-update.txt	2005-09-23 13:39:04.000000000 -0400
@@ -1,3 +1,6 @@
+Internet-Draft                   ForCES                      August 2005
+
+
 5.  Message encapsulation
 
    All PL layer PDUs start with a common header [Section 5.1] followed
@@ -16,8 +19,7 @@
    |                        Destination ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Correlator                           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                        Sequence Number                        |
+   |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             Flags                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -43,9 +45,10 @@
 
    Source ID  (32 bit):
 
+   Dest ID (32 bit):
 
-
-
+       *   Each of the source and Dest IDs are 32 bit IDs which are
+           unique NE-wide and which recognize the termination points of

@@ -54,10 +57,6 @@
 Internet-Draft                   ForCES                      August 2005

-   Dest ID (32 bit):
-
-       *   Each of the source and Dest IDs are 32 bit IDs which are
-           unique NE-wide and which recognize the termination points of
            a ForCES PL message.
 
        *   IDs allow multi/broad/unicast addressing with the following
@@ -102,6 +101,10 @@
 
                I.  0b11 0xFFFFFFFE all FEs broadcast
 
+               J.  0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
+
+
+

@@ -110,9 +113,6 @@
 Internet-Draft                   ForCES                      August 2005

-               J.  0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
-
-
        *   Multicast or broadcast IDs are used to group endpoints (such
            as CEs and FES).  As an example one could group FEs in some
            functional group, by assigning a multicast ID.  Likewise,
@@ -124,21 +124,19 @@
            configuration process.  The list of IDs an FE owns or is part
            of are listed on the FE Object LFB.
 
-   Correlator (32 bits)
-       This field is used to correlate the ForCES Requests messages
-       (typically sent from CE to FE) with the corresponding Response
-       messages (typically sent from FE to CE).  The correlator is
-       handled transparently by the FE, i.e. for a particular Request
-       message it will assign the same correlator value in the
-       corresponding Response message.
-
+   Correlator (64 bits)
+       This field is set by the CE to correlate ForCES Requests messages
+       with the corresponding Response messages from the Fe.
+       Essentially it is a cookie.  The Correlator is handled
+       transparently by the FE, i.e. for a particular Request message it
+       will assign the same correlator value in the corresponding
+       Response message.  In the case where the message from the CE does
+       not elicit a response, this field may not be useful.
 
-   Sequence (32 bits)
-       Like the Correlator the Sequence is set by the CE and echoed back
-       by the FE.  The CE could use the combination of the Correlator
-       and Sequence to maintain transactional state although this is not
-       enforced and so the CE is free to use these 2 fields as it
-       pleases.
+       The Correlator field could be used in many ways by the CE.  For
+       example, the CE could split the Correlator into a 32-bit
+       transactional identifier and 32-bit message sequence identifier.
+       Another example a 64 bit pointer to a context block.
 
    Flags(32 bits):
        Identified so far:
@@ -152,10 +150,15 @@
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
        - ACK: ACK indicator(2 bit)
-           The ACK indicator flag is only used by a Config Message
-           sender to indicate the message receiver whether or not a
-           config response is required by the sender.  Note that all
-           other messages than Config Message MUST ignore this flag.
+           The ACK indicator flag is only used by the CE when sending a
+           Config Message(Section 6.5.1) or a HB message (Section 6.9)
+           to indicate to the message receiver whether or not a config
+           response is required by the sender.  Note that for all other
+           messages than Config Message this flag MUST be ignored.
+
+           The flag values are defined as below:
+
+

@@ -166,8 +169,6 @@
 Internet-Draft                   ForCES                      August 2005

-           The flag values are defined as below:
-
                'NoACK' (00) - to indicate the message receiver not to
                send any response message back to this message sender.
 
@@ -185,18 +186,19 @@
                'AlwaysACK' (11) - to indicate the message receiver to
                send a response message back in any case.
 
-           Note that in above definitions, success means a complete
-           execution without any failure of the message.  Anything else
-           than a complete successful execution is defined as a failure
-           for the message processing.  As a result, for the execution
-           modes (defined in Section 3.3.1.1) like execute-all-or-none,
-           execute-until-failure, and continue-execute-on-failure, if
-           any single operation among several operations in the same
-           message fails, it will be treated as a failure and result in
-           a response if the ACK indicator has been set to 'FailureACK'.
+           Note that in above definitions, the term success implies a
+           complete execution without any failure of the message.
+           Anything else than a complete successful execution is defined
+           as a failure for the message processing.  As a result, for
+           the execution modes (defined in Section 3.3.1.1) like
+           execute-all-or-none, execute-until-failure, and continue-
+           execute-on-failure, if any single operation among several
+           operations in the same message fails, it will be treated as a
+           failure and result in a response if the ACK indicator has
+           been set to 'FailureACK' or 'AlwaysACK'.
 
-           Also note that messages other than Config Message, whose
-           requirements for responses are described by the message
+           Also note that messages other than Config and HB Messages,
+           whose requirements for responses are described by the message
            definitions in Section 6, we summarise the default
            requirements of these messages and the expected responses
            below.  Detailed descriptions can be found in the individual
@@ -204,8 +206,8 @@
 
            +   Association Setup Message always expects a response.
 
-           +   Association Teardown Message, Packet Redirect Message,
-               and Heartbeat Message never expect responses.
+           +   Association Teardown Message, and Packet Redirect
+               Message, never expect responses.
 
            +   Query Message always expects a response.
 
@@ -217,6 +219,7 @@

+
 Doria (Ed.), et al.     Expires February 2, 2006               [Page 26]
 
 Internet-Draft                   ForCES                      August 2005
@@ -258,7 +261,7 @@

-5.2.  Type Length Value
+5.2.  Type Length Value(TLV) Structuring

@@ -309,8 +312,9 @@
 
    TLV values can be other TLVs.  This provides the benefits of protocol
    flexibility (being able to add new extensions by introducing new TLVs
-   when needed).  The nesting feature also allows easy mapping between
-   the XML LFB definitions to binary PL representation.
+   when needed).  The nesting feature also allows for an conceptual
+   optimization with the XML LFB definitions to binary PL representation
+   (reperesented by nested TLVs).
 
 5.2.2.  Scope of the T in TLV
 
@@ -325,10 +329,63 @@
    Length part of the ILV is also 32 bits to allow of the referenced
    data to be arbitrarily large in size.
 
-   Refer to Section 6.1.1.1.8 for discussions on usage of ILVs.

 Doria (Ed.), et al.     Expires February 2, 2006               [Page 28]
 
 Internet-Draft                   ForCES                      August 2005
+
+
+   It should be noted that the "I" values are of local scope and are
+   defined by the data declarations from the LFB definition.  Refer to
+   Section 6.1.1.1.8 for discussions on usage of ILVs.
+

---

From: Avri Doria <[email-masked]>
Date: Sun, 25 Sep 2005 17:55:59 +0200

Hi,

so if i understand, the correlator is now an opaque field with not  
even a sequence number being required.

i am concerned that this may interfere with interoperability of CE  
and FE systems from different vendors.  Additionally I thought that  
the sequence number would be needed for ordering multipart messages.

thanks
a.

On 23 sep 2005, at 19.43, Jamal Hadi Salim wrote:

> <sec5-diff.txt>
> <section5-update.txt>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 25 Sep 2005 13:03:42 -0400

You may have an interesting point with regard to the multi-message 
transactions.

With regard to interoperability, it should actually be easier with this 
approach.  The FE is required to always send the correlator it receives on 
a request back to the CE on the response.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 26 Sep 2005 08:18:43 -0400

> You may have an interesting point with regard to the multi-message 

The current text says:

"This field is set by the CE to correlate ForCES Requests messages
with the corresponding Response messages from the Fe."

That applies to Multipart messages as well i.e the corresponding request
to M of N messages is message M.
Do we need to be more explicit?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 Sep 2005 10:14:12 -0400

The question that occurred to me when I read Avri's note was "how does a 
receiver know it has received and processed all the messages in a 
transaction if they may come out of order and do not have a sequence number?

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 26 Sep 2005 11:06:46 -0400

> transaction if they may come out of order and do not have a sequence number?

My take on this:

- An atomic transaction is marked by a SOT, zero or more MOT and
terminated by EOT i.e. we have a beginning and ending. Nothing 
gets processed (executed is more fitting) until all are assembled and
only when the CE says so.
So ordering is not a big concern as long as reliability requirement is
met i.e TCP as a TML should be good enough.

- Anything that is not Atomic and sends multi-part messages should not
care about ordering.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 Sep 2005 12:08:53 -0400

The unanswered question though is how the received all the intermediate 
components.
If a middle and the end could be swapped, the receiver might try the 
transaction while missing a piece.

My guess is that transactional support will require a sequence number.
My current suggestion, if I have understood the problem properly, is that 
for a transaction, all requests within a transaction shall use the same 32 
bit correlator, and the sequence number applies within the 
transaction.  This also helps handle the case of two interleaved transactions.

For individual messages that are not part of a multi-message transaction, 
the sequence number should be treated as an additional correlator.

This gives up the 64 bit pointer for multi-message transaction.  (Which 
suggests that one would never try to use the 64 bit pointer directly.  Oh 
well.)

Yours,

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 26 Sep 2005 13:08:39 -0400

> transaction.  This also helps handle the case of two interleaved transactions.

Indeed - with a caveat:

Note that: ordering depends on the TML as well and in theory it is the
TMLs responsibility. No guarantees with TCP but I think TIPC and SCTP
both can guarantee ordering.

> the sequence number should be treated as an additional correlator.

We do state this as an example.
Do you think we need more text than whats already there?

> suggests that one would never try to use the 64 bit pointer directly.  Oh 

One could still add an extra TLV at the top level for this.
If you see the need for more text, let me know.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 26 Sep 2005 13:29:01 -0400

You do suggest the other alternative.  We could require that the TML 
provide in-order delivery.
This would not bother me personally, since I prefer TCP / SCTP, which do 
provide in-order delivery.

Yours,
Joel