[Sis-dtn] Re: [dtn] high level summary

[Scott, Keith L.]

Good points.  We should probably go over these at some point on Thursday…

—keith

From: "Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>" <Jeremy.Mayer at dlr.de<mailto:Jeremy.Mayer at dlr.de>>
Date: Monday, April 4, 2016 at 5:46 PM
To: "Scott, Keith L." <kscott at mitre.org<mailto:kscott at mitre.org>>, "sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: RE: [dtn] high level summary

Just to keep it at the forefront of the SIS-DTN hivemind, the “significant changes from RFC5050” section of BPBis is listed below. Items which may cause an issue or should otherwise be noted are bolded.

12. Significant Changes from RFC 5050

   Points on which this draft significantly differs from RFC 5050
   include the following:
     . Clarify the difference between transmission and forwarding.
     . Amplify discussion of custody transfer.  Move current custodian
        to an extension block, of which there can be multiple
        occurrences (possible support for the MITRE idea of multiple
        concurrent custodians, from several years ago); define that
        block in this specification.
     . Introduce the concept of "node ID" as functionally distinct
        from endpoint ID, while having the same syntax. JPM: We’ll need to check our use of Node ID Vs. endpoint ID in documents
     . Restructure primary block, making it immutable.  Add optional
        CRC.
     . Add optional CRCs to non-primary blocks.
     . Add block ID number to canonical block format (to support
        streamlined BSP).
     . Add bundle age extension block, defined in this specification.
     . Add previous node extension block, defined in this
        specification.
     . Add flow label extension block, *not* defined in this
        specification.
     . Add manifest extension block, *not* defined in this
        specification.
     . Add hop count extension block, defined in this specification.
     . Clean up a conflict between fragmentation and custody transfer
        that Ed Birrane pointed out.
     .Remove representation specifications from the document, making
        the protocol specification representation-neutral.

In addition, please note that class of service has been removed from BPBis, which causes a few issues: First, it (sort-of) flies afoul of section 3.3 of the BP Blue Book: Conformant implementations of the CCSDS Bundle Protocol shall implement the ‘Extended Class of Service (ECOS)’ block defined in annex C”. While the Extended Class of Service block as it is defined in the annex can be added to a BPBis-based implementation, it isn’t extending anything. The idea from IETF is that a new document will be created which defines a representation-agnostic CoS implementation.

Second, in section 4.3.5, the “class-of-service parameter” is specified, which is no longer in the BP primary block. These changes will also create a change to Annex F: BP Managed Information. In F2.2, there’s a table of bundle state information which must be collected. In that list, we specify that the collection of bundle counts for bulk, normal, and expedited priorities is mandated. If I were to implement a BPBis system today, there would be no way to collect these values.

Thanks,
Jeremy
From: sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> [mailto:sis-dtn-bounces at mailman.ccsds.org] On Behalf Of Scott, Keith L.
Sent: Montag, 4. April 2016 23:10
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] FW: [dtn] high level summary

I highlighted the bpbis going to last call in what’s below.  This will essentially complete the IETF update to BP so the time to ensure that the new protocol is compatible with what we envision for the future of CCSDS (I think it is, but encourage a vigorous review) is now.

—keith

[thanks to Marc for the notes!]

---------- Forwarded message ----------
From: Marc Blanchet <marc.blanchet at viagenie.ca<mailto:marc.blanchet at viagenie.ca>>
Date: Mon, Apr 4, 2016 at 3:53 PM
Subject: Re: [dtn] high level summary
To: DTN WG <dtn at ietf.org<mailto:dtn at ietf.org>>
Cc: dtn-chairs at ietf.org<mailto:dtn-chairs at ietf.org>


hello,
 while we will be publishing meeting notes, I thought that it would be useful for people to get a high-level super short summary of next steps following today’s meeting. Specially given the difficulties with the audio we had. Obviously, nuances are not detailed here.

Hope this is useful.

Marc.

====
Summary of next steps following today’s meeting

bpbis: start a 4 weeks wg last call around April 18th
bpsec: possibly move CMS to a separate doc. Ed to start a thread on ML. Need to talk to CCSDS about needs.
pkdn: we need to work on a requirement document, including assumptions, separating typical pki requirements with the ones that are specific or influenced by a dtn environment. Most likely need to be discussed with pkix experts.
ama: publish new version of requirements. start a discussion with OPS
ip neighbour: need to step back and write a more generic neighbour/local services discovery architecture document.
static routing: need addressing before. need editors for addressing.

_______________________________________________
dtn mailing list
dtn at ietf.org<mailto:dtn at ietf.org>
https://www.ietf.org/mailman/listinfo/dtn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20160404/2f7731f9/attachment.html>