From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 22 April 2008 18:09
To: ancp at ietf.org
Subject: Re: [ANCP] ANCP message length fieldAdding 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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 22 April 2008 15:36
To: ancp at ietf.org
Subject: [ANCP] ANCP message length fieldHi 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 ANCP at ietf.org https://www.ietf.org/mailman/listinfo/ancp