[Sis-dtn] IPN URI Scheme Service Numbers
Jonathan W
joe.nathan.wilmot at gmail.com
Thu May 25 05:22:09 UTC 2023
The DTN flight node developers already have a detailed list of fault
condition triggers and are working with network management folks to see
what might be standardized. We capture selected state, time, and source
EID of the problem bundle(s) and send an event message. Included is a
compression and/or filtering mechanism for faults that can occur
repeatedly so we don't flood.
These event messages can be acted on by local network management and are
stored to be sent to network management when a link is available.
Note this is a common pattern used by embedded flight systems.
Kind Regards,
Jonathan
Jonathan Wilmot
Vantage Systems, Inc
NASA/GSFC 580
On 5/25/2023 12:56 AM, Vint Cerf via SIS-DTN wrote:
> keep in mind that some of the real-time functions we found useful in
> the Internet may be less useful in the DTN because of uncertain and
> long delays for response - the resolution of a transient problem may
> get data too late to be useful. We might need to think through
> triggers in the bundle relay nodes that capture state when a problem
> arises and sends to a network management site.
>
> v
>
>
> On Thu, May 25, 2023 at 2:40 AM 구철회 via SIS-DTN
> <sis-dtn at mailman.ccsds.org> wrote:
>
> Hi, Ed.
>
> Here is my list for potential DTN services that I think would come
> someday.
>
> - BP ping
> - BP chat
> - CFDP
> - Video streaming
> - BP traceroute
> - BP HTTP
> - Network management protocol
>
> Best,
> Cheol
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 May 2023 02:29:11 +0000
> From: "Birrane, Edward J." <Edward.Birrane at jhuapl.edu>
> To: Felix Flentge <Felix.Flentge at esa.int>, "sis-dtn at mailman.ccsds.org"
> <sis-dtn at mailman.ccsds.org>
> Subject: Re: [Sis-dtn] IPN URI Scheme Service Numbers
> Message-ID: <8fbf017ec65a4ebc8f51e51b32955830 at jhuapl.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> I would encourage any observations on the need for standard
> service numbers (and that they are not port numbers) to be also
> made to the DTNWG mailing list. It would help inform the
> discussion that is occurring there.
>
> -Ed
>
> Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space
> Constellation Networking Supervisor, Embedded Applications Group
> Space Exploration Sector Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 <tel:(443)%20778-7423> / (C) 443-690-8272
> <tel:(443)%20690-8272>
>
>
> > -----Original Message-----
> > From: Felix Flentge <Felix.Flentge at esa.int>
> > Sent: Monday, May 22, 2023 11:50 AM
> > To: Birrane, Edward J. <Edward.Birrane at jhuapl.edu>; sis-
> > dtn at mailman.ccsds.org
> > Subject: [EXT] RE: IPN URI Scheme Service Numbers
> >
> > APL external email warning: Verify sender Felix.Flentge at esa.int
> before
> > clicking links or attachments
> >
> > Hi,
> >
> > Seems to be a very sensible proposal to me. For the more
> immediate future,
> > I assume that there will be only limited need for interoperable
> use of service
> > numbers (ie, an application of one agency communicating to an
> application
> > of another agency) and I would expect missions to pick the low
> service
> > numbers for their (private) M&C and payload needs anyway. What
> we might
> > want to agree on are service numbers used for network management and
> > diagnostic needs (e.g., bpecho).
> >
> > Regards,
> > Felix
> >
> > -----Original Message-----
> > From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of
> Birrane,
> > Edward J. via SIS-DTN
> > Sent: Monday, May 22, 2023 2:38 PM
> > To: sis-dtn at mailman.ccsds.org
> > Subject: [Sis-dtn] IPN URI Scheme Service Numbers
> >
> > WG,
> >
> > Last week at the SIS-DTN weekly meeting we had a good
> discussion on
> > allocation strategies for IPN service numbers.
> >
> > IIRC, there were three major areas of discussion related to
> these numbers:
> > encoding size, allocation policy, and registry ownership.
> >
> > The encoding size discussion noted that the CBOR encoding of
> service
> > numbers creates a very small allocation of 1-byte encodings
> (0-23), a small
> > allocation of 2-byte encodings (24-155), a moderate size
> allocation of 3-byte
> > encodings (256-65,535), and then 4+ byte encodings that give us the
> > remainder of the 64bit service number space.
> >
> > The allocation policy discussion noted that there was a good
> case for
> > "private use" service numbers for mission-specific use cases
> (commanding,
> > telemetry) that do not otherwise map to a standardized protocol.
> These
> > mission specific service numbers should not be standardized
> (they are
> > mission specific) and there should be some allowance for them in
> the small
> > encoding space since they will be used by missions often
> (perhaps most
> > often).
> >
> > The registry ownership discussion noted that IANA is creating
> (updating
> > really..) a registry for service numbers and should there be a
> SANA allocation
> > in that registry.
> >
> > At the end of the discussion the following proposal was put
> forward:
> >
> > 1 byte service numbers (1-23) will be private use .
> > 2 byte service numbers (24-255) will be expert review with a
> 64-id chunk
> > allocated to SANA.
> > 3 byte service numbers (256-65k) will be cut 1/3 private use,
> 1/3 IANA
> > managed and 1/3 IANA managed but given to SANA.
> > 4 byte will have a chunk of experimental.
> > 4+bytes is unassigned.
> >
> > This continues to be an area of active discussion in the IETF
> mailing list.
> > Some IETF participants are proposing that all service numbers be
> private-use
> > and there be no standard service numbers since service discovery
> is better
> > done today independent of port numbers. I disagree with this
> position -
> > service numbers are not port numbers - but that case needs to be
> made, for
> > those interested in following the discussion on the IETF mailing
> list.
> >
> > -Ed
> >
> > ---
> > Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space
> Constellation
> > Networking Supervisor, Embedded Applications Group Space Exploration
> > Sector Johns Hopkins Applied Physics Laboratory
> > (W) 443-778-7423 <tel:(443)%20778-7423> / (F) 443-228-3839
> <tel:(443)%20228-3839>
> >
> >
> >
> > _______________________________________________
> > SIS-DTN mailing list
> > SIS-DTN at mailman.ccsds.org
> >
> https://protect2.fireeye.com/v1/url?k=57fc07a6-08676dae-57f97628-ac1f6bdccbcc-48ad6278b81cd32f&q=1&e=b4259b40-80ac-4b4b-a14a-92c3072ae173&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn
> <https://protect2.fireeye.com/v1/url?k=57fc07a6-08676dae-57f97628-ac1f6bdccbcc-48ad6278b81cd32f&q=1&e=b4259b40-80ac-4b4b-a14a-92c3072ae173&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn>
> > This message is intended only for the recipient(s) named above.
> It may
> > contain proprietary information and/or protected content. Any
> > unauthorised disclosure, use, retention or dissemination is
> prohibited. If you
> > have received this e-mail in error, please notify the sender
> immediately. ESA
> > applies appropriate organisational measures to protect personal
> data, in case
> > of data privacy queries, please contact the ESA Data Protection
> Officer
> > (dpo at esa.int).
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://protect2.fireeye.com/v1/url?k=c23fcc3f-9da4a637-c23abdb1-ac1f6bdccbcc-506e8a5c82861025&q=1&e=b4259b40-80ac-4b4b-a14a-92c3072ae173&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn
> <https://protect2.fireeye.com/v1/url?k=c23fcc3f-9da4a637-c23abdb1-ac1f6bdccbcc-506e8a5c82861025&q=1&e=b4259b40-80ac-4b4b-a14a-92c3072ae173&u=https%3A%2F%2Fmailman.ccsds.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fsis-dtn>
>
>
> ------------------------------
>
> End of SIS-DTN Digest, Vol 143, Issue 37
> ****************************************
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230525/af666801/attachment-0001.htm>
More information about the SIS-DTN
mailing list