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

[Marc Blanchet]

FYI,
  The IETF DTN working group current charter has an item about a generic 
standard registry for service numbers, similar to the IP ports/services 
registry, where a service ID is identified for a specific service. I 
started the initial work while dtnrg 
(https://www.ietf.org/archive/id/draft-blanchet-dtnrg-bp-application-framework-01.txt). 
Obviously not the « what this deployed node has currently running 
which services », but more if I send a bundle to this specific service 
ID, then the sender is expecting that the receiver application stack 
will do appropriately. same as port 80 is expected to be http, 443 
https.

Marc.

On 28 Aug 2018, at 8:39, Scott, Keith L. 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
>
>
>
> The MITRE Corporation
>
> 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/


> _______________________________________________
> SSG mailing list
> SSG at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/ssg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20180828/e1e9a5de/attachment.html>