[Sis-dtn] [EXTERNAL] Re: [EXT] RE: Telecon 20220728 - clarification

Tue Aug 2 17:17:52 UTC 2022

Sorry for being late to the discussions, but tying into to the region discussion and our “homework”/”what to do next” don’t forget there has been decent interest in providing a “multicast” concept/solution within DTN.

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of sburleig.sb--- via SIS-DTN
Sent: Friday, July 29, 2022 6:57 PM
To: Torgerson, J. Leigh (JPL-332C)[JPL Employee] <jordan.l.torgerson at jpl.nasa.gov>; 'Dr. Keith L Scott' <kscott at mitre.org>; Tomaso.deCola at dlr.de
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: Telecon 20220728 - clarification

Actually Vint too has objected to the IRR (now IRF) definition of “region” – he too tends to think of a region as something that has spatial scope rather just the nodes cited in a contact plan.  Maybe we need a new word for what I’ve been calling a “region”.  Maybe “sector.”  Or “ambit.”

Scott

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Torgerson, J. Leigh (US 332C) via SIS-DTN
Sent: Friday, July 29, 2022 3:18 PM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>; Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>
Cc: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: Telecon 20220728 - clarification

Hi folks,

Just as a matter of clarification, I must say that Scott Burleigh didn’t change the definition of a “region” per se – that erroneously attributes a change to Scott, who no-doubt always implicitly thought of a “region” being defined by a tractable Contact Plan that everyone shares. The concept of a region has been kicked around a lot at JPL between mission planners, network analysts, etc., and it (in my mind) was never something that was specifically defined as “the set of nodes that all share the same contact plan”, but that was the way it was defined for the creation of the Inter Regional Routing (IRR) ION software, which makes sense, and should be a great starting point for exploring how to manage expanding DTN networks in a scalable fashion.

We had conceived of a region being, say, something like a “Surface Operations Region”, where there would likely be a hybrid collection of routing methods (mobile routing over 5G, mesh networks on the surface, etc., all of which would interface with a lander with surface to Gateway relay capabilities using CGR, or into a Commercial Relay Satellite network that may or may not use CGR for internal relay s/c to relay s/c crosslink routing.

There are many many different possible topologies and methods, and only one word to describe them all – that the problem with language! Maybe Lunar Surface Ops is a Realm which contains a set of Regions (defined by their CGR plans or other routing plans) that may interconnect but are all owned by the same King. 😊

(all that being said, don’t even TRY to read the AMS spec at this point…)

Leigh

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FYI, attached is the presentation & discussion slides I used last May to present our DTN DNS ideas to the IPNSIG.  Lots of questions remain of course, and since Scott Burleigh has changed the definition of a “region” to be a collection of nodes that all have the same contact plan, some additional things have to be considered in the next to the last slide. In any case, this is what I’ve been working on to support an initial prototype of an AMMOS Mars DTN Relay network, as well as something to test out with both IPNSIG and the DEN if we can generate interest in re-awakening the DTN Readiness Program’s DTN Engineering Network.

Regards
Leigh

J. Leigh Torgerson
Space Communications Networking Architect
Protocol Technology Lab Manager
Communications Architectures & Research (332)
Jet Propulsion Laboratory
4800 Oak Grove Drive M/S: 238-420
Pasadena, CA 91109
Office: (818) 393-0695
Email: ltorgerson at jpl.nasa.gov<mailto:ltorgerson at jpl.nasa.gov>

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> on behalf of "Dr. Keith L Scott via SIS-DTN" <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Reply-To: "Scott, Keith L." <kscott at mitre.org<mailto:kscott at mitre.org>>
Date: Thursday, July 28, 2022 at 10:28 AM
To: "Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>" <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Cc: "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: [EXTERNAL] Re: [Sis-dtn] [EXT] RE: Telecon 20220728

Concur.  I *think* those will ‘fall out of’ the BPsec and NM discussions, but yes, we should ensure that we have a comprehensive architecture / plan that all hangs together.

                                --keith

From: Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de> <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Date: Thursday, July 28, 2022 at 12:13 PM
To: Dr. Keith L Scott <kscott at mitre.org<mailto:kscott at mitre.org>>
Cc: 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: [EXT] RE: Telecon 20220728
As to the “homework” “what to do next”, we should also address at some point the remarks made by Peter Shames also in relation to the considerations drawn in IOAG about the overall security framework in CCSDS and missing elements in DTN (i.e. those going beyond BPSEC). Specifically he pointed in a presentation shared in June to: “Key management and identity mechanisms need to be defined,
Secure network management framework for multi-agency interoperability needs to be defined”.

Tomaso

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Dr. Keith L Scott via SIS-DTN
Sent: Donnerstag, 28. Juli 2022 17:56
To: sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [Sis-dtn] Telecon 20220728

SIS-DTN

IETF DTN WG Meeting

CCSDS:

• Talked about our ‘requirements’ for auditing / accounting / reliability

• Plan forward: do work, ensure that IETF DTN WG is cognizant of it; coordinate as makes sense

Naming:

• I wasn’t able to make the second half of the DTN WG meeting where naming was discussed

• Apparently Airbus has some needs that aren’t well-met by ‘just’ an IPN Node #, looking for something more

• Scott proposed using ‘just’ IPN node numbers as the identification mechanism and developing ‘DNS-like’ and ‘whois-like’ services:

• DNS-like: transforms mnemonics into IPN node numbers

• whois-like: translates IPN node numbers into points-of-contact

• Need to secure both of these services (obviously)

LTP Orange:

Need use cases / metrics for when orange is a win.

• E.g. with a latency of xxx and an LTP segment loss rate of yyy, using the metrics: (total memory*time used by receiver, total memory*time used by transmitter) ...

If we can’t find a use case that is compelling, we shouldn’t include Orange (keep the protocol as simple as possible).

Jonathan’s bit ordering question

In RFC9171, things like the Bundle Processing Control Flags refer to the ‘least significant bit’.  Note that the BPCF is a bit field represented by a CBOR unsigned integer.  In the integer representation of the CBOR unsigned int, ‘least significant bit’ is unambiguous (It’s the bit that determines whether the integer is odd or even).

We don’t really care how the link layer might mangle things for transmission, so long as what is received is interpretable as (the same) CBOR unsigned integer, so the LSB makes sense.

Homework

• LTP Orange Question

• What to do next?  BPsec Green, NM (Blue, Green), LTP

Simon’s question about ADMs

We pushed a lot of things out of the BPv7 profile for expediency.  Many of those SHOULD be addressable via network management.  We should work a set of ADMs (e.g. BPv7, ION, LTPv2, ...) in concert with the ‘base’ NM protocol work as a sanity-check to ensure that the NM protocol will in fact support what we need.  Use these to address the issues we pushed out of the base CCSDS BPv7 profile.

There’s an (old) draft BP ADM here: https://datatracker.ietf.org/doc/draft-birrane-dtn-adm-bp/<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-birrane-dtn-adm-bp%2F__%3B!!PvBDto6Hs4WbVuu7!YBcwEKvxai6h74R_WFOq89JGPuwabmY9je1xfMHbcbWdT4w5bGba2JH_Mlr3N9pNHkPGEg%24&data=05%7C01%7Cjoshua.e.deaton%40nasa.gov%7Ca7d5dd26441b47b5074808da71be1023%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637947358384385414%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MEWoyI7tO9m37L%2BiPLXvLDTY2jGXWv2Ui4OXccWyEx4%3D&reserved=0> (thanks Sarah, for pointing this out).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220802/7f609604/attachment-0001.htm>