Re: [dtn] BPv7 CDDL and CBOR tagging

[Brian Sipos <[e-mail]>]

Rather than embedding more in email, I've uploaded a revised CDDL (minor typos with commas, and
named the crc-type values) to [1]. This should avoid any line/spacing/etc. issues with email text
transport.

[1]: https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/blob/develop/bpv7.cddl

On Wed, 2019-04-10 at 15:07 +0000, Burleigh, Scott C (312B) wrote:
> Brian, thanks, this is great!  I'll insert the revised CDDL and re-post.
> 
> I think "total application data unit length" was erroneously deleted from section 4.2.2 a couple
> of revs back, but it was restored as of version 13 (January).
> 
> Scott
> 
> -----Original Message-----
> From: Brian Sipos <[e-mail]> 
> Sent: Tuesday, April 9, 2019 7:18 PM
> To: Burleigh, Scott C (312B) <[e-mail]>; Carsten Bormann <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [dtn] BPv7 CDDL and CBOR tagging
> 
> Scott,
> At the bottom of this email is a full CDDL that captures both the encodings of extension /
> administrative data as well as the binding between extension data types and extension block
> numbers.
> I also added restrictions on CRC type code and CRC value data, and used the socket convention and
> the "-structure" convention from the pre-RFC CDDL draft.
> 
> I'll leave up to you to decide if this is an over-specialized use of CDDL. Using the reference
> "cddl" program to generate randomized data actually produces near-to-reasonable bundles to my eye,
> which is nice validation of the CDDL itself.
> 
> The reference program can be tested as in:
> $ gem install cddl
> $ cddl bpv7.cddl.txt generate
> [[7, 17174, 0, [2, [3026, 451]], [1, 0], [2, [535, 2091]], [4044, 2891], 1070, h'FCDD'], [8, 2593,
> 229, 2, h'190836', h'C4F3'], [7, 2533, 177, 2, h'820100', h'0504'], [8, 3239, 179, 2, h'1850'],
> [8, 398, 237, 2, h'183E', h'31261138'], [1, 0, 175, 0,
> h'8201848481F581F481F481F51901C6820166766F6C75707482190704190CDA',
> h'AFA5']]
> 
> One issue that I ran into when testing this: I used this CDDL to validate some test bundles which
> I had been generating separately to test the TCPCL agent. The original CDDL in the draft contains
> the field name "total-application-data-length" which also appears several times in the draft as
> "total application data unit length" in the statments.
> But I don't see that field listed in Section 4.2.2. Is there a missing field in that section, or
> is that field no longer present and the other text is inaccurate?
> 
> Thanks,
> Brian S.
> 
> On Tue, 2019-04-09 at 01:24 +0000, Burleigh, Scott C (312B) wrote:
> > Guys, please feel free to send me an updated CDDL expression of Bundle 
> > Protocol version 7; I will gladly include it in the document.
> > 
> > My one comment is that the type dtn-time is correctly defined as uint; 
> > it should NOT be changed to int, as negative values are not allowed.  
> > If you can spot an instance in the spec where dtn-time is 
> > characterized as a signed integer, please let me know and I will 
> > correct it.
> > 
> > Scott
> 
> start = bundle / #6.55799(bundle)
> 
> ; Times before 2000 are invalid
> dtn-time = uint
> 
> ; CRC enumerated type
> crc-type = 0 / 1 / 2
> ; Either 16-bit or 32-bit
> crc-value = (bstr .size 2) / (bstr .size 4)
> 
> creation-timestamp = [dtn-time, sequence: uint]
> 
> eid = $eid-choice .within eid-structure
> eid-structure = [
>   uri-code: uint,
>   SSP: any
> ]
> $eid-choice /= [
>   uri-code: 1,
>   SSP: (tstr / 0)
> ]
> $eid-choice /= [
>   uri-code: 2,
>   SSP: [
>     nodenum: uint,
>     servicenum: uint
>   ]
> ]
> 
> bundle-control-flags = uint .bits bundleflagbits bundleflagbits = &(
>   reserved: 15
>   reserved: 14
>   reserved: 13
>   bundle-deletion-status-reports-are-requested: 12
>   bundle-delivery-status-reports-are-requested: 11
>   bundle-forwarding-status-reports-are-requested: 10
>   reserved: 9
>   bundle-reception-status-reports-are-requested: 8
>   bundle-contains-a-Manifest-block: 7
>   status-time-is-requested-in-all-status-reports: 6
>   user-application-acknowledgement-is-requested: 5
>   reserved: 4
>   reserved: 3
>   bundle-must-not-be-fragmented: 2
>   payload-is-an-administrative-record: 1
>   bundle-is-a-fragment: 0
> )
> 
> block-control-flags = uint .bits blockflagbits blockflagbits = &(
>   reserved: 7
>   reserved: 6
>   reserved: 5
>   reserved: 4
>   bundle-must-be-deleted-if-block-cannot-be-processed: 3
>   status-report-must-be-transmitted-if-block-cannot-be-processed: 2
>   block-must-be-removed-from-bundle-if-it-cannot-be-processed: 1
>   block-must-be-replicated-in-every-fragment: 0
> )
> 
> bundle = [primary-block, *extension-block, payload-block]
> 
> primary-block = [
>   version: 7,
>   bundle-control-flags,
>   crc-type,
>   destination: eid,
>   source-node: eid,
>   report-to: eid,
>   creation-timestamp,
>   lifetime: uint,
>   ? (
>     fragment-offset: uint,
> ;    total-application-data-length: uint,
>   )
>   ? crc-value,
> ]
> 
> ; Abstract shared structure of all non-primary blocks canonical-block-structure = [
>   block-type-code: uint,
>   block-number: uint,
>   block-control-flags,
>   crc-type,
>   ; Each block type defines the content within the bytestring
>   block-type-specific-data,
>   ? crc-value
> ]
> block-type-specific-data = bstr / #6.24(bstr) ; Extension block type, which does not specialize
> any more than the code/number extension-block = $extension-block-structure .within canonical-
> block- structure $extension-block-structure = [
>   block-type-code: (uint .gt 1),
>   extension-block-number,
>   block-control-flags,
>   crc-type,
>   ($extension-block-data .within block-type-specific-data)
>   ? crc-value
> ]
> extension-block-number = (uint .ne 0)
> ; Payload block type
> payload-block = payload-block-structure .within canonical-block- structure payload-block-structure 
> = [
>   block-type-code: 1,
>   block-number: 0,
>   block-control-flags,
>   crc-type,
>   ($payload-block-data .within block-type-specific-data)
>   ? crc-value
> ]
> 
> ; Arbitrary payload data
> $payload-block-data /= bstr
> 
> 
> ; Administrative record as a payload data specialization $payload-block-data /= block-type-
> specific-data .cbor admin-record admin-record = $admin-record .within admin-record-structure
> admin-record-structure = [
>   record-type-code: uint,
>   record-content: any
> ]
> ; Only one defined record type
> $admin-record /= [1, status-record-content] status-record-content = [
>   bundle-status-information,
>   status-report-reason-code: uint,
>   source-node-eid: eid,
>   subject-creation-timestamp: creation-timestamp,
>   ? (
>     subject-payload-offset: uint,
>     subject-payload-length: uint
>   )
> ]
> bundle-status-information = [
>   reporting-node-received-bundle: status-info-content,
>   reporting-node-forwarded-bundle: status-info-content,
>   reporting-node-delivered-bundle: status-info-content,
>   reporting-node-deleted-bundle: status-info-content ] status-info-content = [
>   status-indicator: bool,
>   ? timestamp: dtn-time
> ]
> 
> ; Previous Node extension block
> $extension-block-structure /= [
>   block-type-code: 7,
>   extension-block-number,
>   block-control-flags,
>   crc-type,
>   (block-type-specific-data .cbor ext-data-previous-node)
>   ? crc-value
> ]
> ext-data-previous-node = eid
> 
> ; Bundle Age extension block
> $extension-block-structure /= [
>   block-type-code: 8,
>   extension-block-number,
>   block-control-flags,
>   crc-type,
>   (block-type-specific-data .cbor ext-data-bundle-age)
>   ? crc-value
> ]
> ext-data-bundle-age = uint
> 
> ; Hop Count extension block
> $extension-block-structure /= [
>   block-type-code: 9,
>   extension-block-number,
>   block-control-flags,
>   crc-type,
>   (block-type-specific-data .cbor ext-data-hop-count)
>   ? crc-value
> ]
> ext-data-hop-count = [
>   hop-limit: uint,
>   hop-count: uint
> ]
> 
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn