[Sis-dtn] IPN URI Scheme Service Numbers

Thu May 25 04:56:43 UTC 2023

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 <(443)%20778-7423> / (C) 443-690-8272 <(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 <(443)%20778-7423> / (F) 443-228-3839
> <(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
> > 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
>
>
> ------------------------------
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230525/814b31b3/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3995 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230525/814b31b3/attachment-0001.bin>