Subject: [ANCP] ANCP message length field

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 22 Apr 2008 15:35:51 +0200

Hi Folks,

As part of our GSMP legacy we've inherited some base protocol header
fields that, for lack of a better word, are largely useless for ANCP. An
example of such a field are the dual message Length field deriving from
rfc3292 and rfc3293, both of which in ANCP carry the same value (it's
not at all clear why rfc3293 needed such a field, but that's a different
story). This is shown in more detail below in the form of an ANCP
header:

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Type (0x88-0C)         |           Length              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Vers  |  Sub  |MessageType    | Result|        Code           | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Partition ID  |            Transaction Identifier             | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |I|      SubMessage Number      |           Length              | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

RFC 3293 defines the first "Length" field to be:       This 2-byte
unsigned integer indicates the total length of the
      GSMP message only.  It does not include the 4-byte TLV header.

RFC 3292 defines the second "Length" field to be: Length of the GSMP
message including its header fields and
         defined GSMP message body.  The length of additional data
         appended to the end of the standard message SHOULD be included
         in the Length field.

It's thus quite clear that the two fields, in ANCP's case, carry the
same value and it appears reasonable to think of possible changes:.

Proposal 1. 
The "additional data" possibility is to be dropped. There appears to be
no reason to transmit non ANCP data in ANCP.

Proposal 2 - Option a.
Re-define the Sub-message Number and Length fields to convey really a
Sub-message Number and Sub-Message Length, and allow multiple commands
to be bundled under the same transaction header, which appears
interesting in the perspective of multicast control, and line
configuration use-cases. Backwards compatibility with existing
implementations could be maintained since currently all ANCP's
applications set the I flag to "0". Implementations supporting this
change, would most likely be required to send the so-far commonly
implemented Port-up/down and OAM "legacy" messages with the I flag set
to "1".

Proposal 2 Option b.
Instead of using the Sub-message number and 2nd Length fields, we define
these to be reserved fields of no use in ANCP.

Proposal 2 Option c.
Define the 1st Length field to be reserved fields of no use in ANCP,
using instead only the Sub Message and Length fields to stitch together
ANCP messages that go over 64kb boundary.

Proposal 2 Option d
Continue using both fields as today, but refine the Sub-message and
Length field to allow for messages over 64kb.

I solicit the WG's feedback regarding these proposed changes.

Regards,
Woj.
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 22 Apr 2008 18:08:40 +0200

Adding one note regarding the options for carrying PDUs exceeding 64kb.
Using other GSMP derived notions in proposal options 2a and 2b it would
be possible to set a "result" field flag to indicate the continuation of
a fregmented PDU, with the transaction identifier allowing the
possibility to stitch back together such a message. An implementation
would however have to pay close attention to this flag, and the fact
that overall legth of the message would be the sum of two (or more)
length fields.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
	Sent: 22 April 2008 15:36
	To: [email-masked]
	Subject: [ANCP] ANCP message length field

	Hi Folks, 

	As part of our GSMP legacy we've inherited some base protocol
header fields that, for lack of a better word, are largely useless for
ANCP. An example of such a field are the dual message Length field
deriving from rfc3292 and rfc3293, both of which in ANCP carry the same
value (it's not at all clear why rfc3293 needed such a field, but that's
a different story). This is shown in more detail below in the form of an
ANCP header:

	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
9 0 1 
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	     |        Type (0x88-0C)         |           Length
| 
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	     | Vers  |  Sub  |MessageType    | Result|        Code
| 
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	     | Partition ID  |            Transaction Identifier
| 
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
	     |I|      SubMessage Number      |           Length
| 

	RFC 3293 defines the first "Length" field to be:       This
2-byte unsigned integer indicates the total length of the 
	      GSMP message only.  It does not include the 4-byte TLV
header. 

	RFC 3292 defines the second "Length" field to be: Length of the
GSMP message including its header fields and 
	         defined GSMP message body.  The length of additional
data 
	         appended to the end of the standard message SHOULD be
included 
	         in the Length field. 

	It's thus quite clear that the two fields, in ANCP's case, carry
the same value and it appears reasonable to think of possible changes:.

	Proposal 1. 
	The "additional data" possibility is to be dropped. There
appears to be no reason to transmit non ANCP data in ANCP. 

	Proposal 2 - Option a. 
	Re-define the Sub-message Number and Length fields to convey
really a Sub-message Number and Sub-Message Length, and allow multiple
commands to be bundled under the same transaction header, which appears
interesting in the perspective of multicast control, and line
configuration use-cases. Backwards compatibility with existing
implementations could be maintained since currently all ANCP's
applications set the I flag to "0". Implementations supporting this
change, would most likely be required to send the so-far commonly
implemented Port-up/down and OAM "legacy" messages with the I flag set
to "1".

	Proposal 2 Option b. 
	Instead of using the Sub-message number and 2nd Length fields,
we define these to be reserved fields of no use in ANCP. 

	Proposal 2 Option c. 
	Define the 1st Length field to be reserved fields of no use in
ANCP, using instead only the Sub Message and Length fields to stitch
together ANCP messages that go over 64kb boundary.

	Proposal 2 Option d 
	Continue using both fields as today, but refine the Sub-message
and Length field to allow for messages over 64kb. 

	Regards, 
	Woj.