[Sis-dtn] Proposed registry (and registry changes) to address BP operations in CCSDS.

Tue Aug 28 13:06:02 UTC 2018

Interesting point. In the Internet space, we ended up with "well-known
ports" as a way of registering standard services.
Not every host runs all services (ie has an active process servicing a
particular port or, for that matter, protocol).
Connection attempts to unserved ports get rejected. Connection attempts to
unserved protocols, ditto (I think).

Registration would not be a guarantee of service but might avoid useless
attempts to reach a particular EID with any particular port or protocol.

Changes to service support would need to be registered - a procedural
detail we would likely need to instantiate along with a sort of manual of
operations for BP - if BP operation becomes widespread, we should be asking
ourselves how the operational aspects will scale and what infrastructure we
will need to achieve that.

v

On Tue, Aug 28, 2018 at 8:39 AM, Scott, Keith L. <kscott at mitre.org> wrote:

> Greetings,
>
>
>
> Peter Shames noted that while there are registries for SANA CBHE Node and
> Service numbers that will allow us to deconflict node EIDs and have a
> uniform interpretation of the service numbers, there is nothing that says
> WHICH services are running at WHICH node, OR anything that associates BP
> Nodes (in our case identified by CBHE Node IDs) and the services they’re
> running with ‘Sites’ (using the Service and Site Aperture Registry
> definition) such as ground stations, spacecraft, etc.  This kind of
> information, while not technically required to make BP work, is part of the
> administration/operation of the network, and would be expected to change
> infrequently (and so at least feasible to maintain in a registry).
>
>
>
> The desire is for the DTN WG to identify changes / augmentations to the
> SANA registries to provide the information above.  The attached Registry
> Management Policy deck includes an overview of the Service Site & Aperture
> structure on slides 21—23.
>
>
>
> I propose the following strawman for discussion:
>
>
>
> Change the Network Services under Site Service Info on slide 22 to be a ‘mayInclude
> (0..*) – i.e. allow for possibly multiple network services.  This would
> allow sites that have multiple BP routers, which I’ll admit might be
> unusual but certainly possible.
>
>
>
> Define a BP_Network_Service element (registry) that is a logical subclass
> of the Network_Services listed on slide 22 as:
>
> ·         *CBHE Node #,* the CBHE Node Number of the BP Node, hyperlinked
> to the node number allocation range in the CBHE Node Number Registry
>
> ·         *POC*: a link to the appropriate SANA registry entry for who to
> talk to about connecting with this node (e.g. routing through it) [Could be
> a person or an organization?]
>
> ·         *List of CBHE Service #s*: A list of CBHE service numbers that
> can be expected to be running on the node (e.g. CFDP) – hyperlinked to
> their corresponding entries in the CBHE Service # registry.
>
> ·         *List of convergence layers and their information*: so for
> example, if the node is running a TCPCL on IP address 10.1.2.3:1234, a
> UDP CL on port address 10.1.2.6:5678, and an LTP/Encap CL on virtual
> channel 3, those would be listed.
>
> o   Maybe listing the VC isn’t appropriate here?  That’s more a function
> of the mission configuration (e.g. each mission could use a different VC
> even if all share the same aperture and site, I think)
>
> o   I’d vote for the CL info being a free text field with a convention
> for entries like TCP:1234:4556 rather than trying to generate a whole
> sub-structure for CL entries – thoughts?
>
>
>
> Somebody should probably also define an IP_Network_Service element.  That
> may fall to us as well but could pretty much mirror the BP one (but without
> CL info).
>
>
>
> Thoughts on this?
>
>
>
>
>
>                                                 v/r,
>
>
>
>                                                 --keith
>
>
>
>
>
> *Dr. Keith Scott
>                                                       Office:
> +1.703.983.6547*
>
> *Chief Engineer, Communications Network Engineering & Analysis
>  Fax:      +1.703.983.7142*
>
> *Advanced Data Transport Capability Area
> Lead                                             Email:  kscott at mitre.org
> <kscott at mitre.org>*
>
>
>
> *The MITRE Corporation* <http://www.mitre.org/>
>
> *M/S J500*
>
> *7515 Colshire Drive*
>
> *McLean, VA 22102*
>
>
>
> *MITRE self-signs its own certificates.  Information about the MITRE PKI
> Certificate Chain is available from https://www.mitre.org/tech/mii/pki/
> <https://www.mitre.org/tech/mii/pki/>*
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
>

-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20180828/52522da5/attachment.html>