Subject: Re: [ANCP] ANCP message length field

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 30 May 2008 09:07:17 +0200

Hi Folks,
 
any comments, or preferences regarding the proposals? Since one of the
two identical Length fields is redundant, we have some options on
dealing with them... 
 
-Woj.

________________________________

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

	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. 

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

		Regards, 
		Woj. 

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