[Sea-sa] Rough minutes from SEA-SA Webex, SCCS-ARD topics, 6 Mar 23

Shames, Peter M (US 312B) peter.m.shames at jpl.nasa.gov
Tue Mar 7 01:02:35 UTC 2023 

Dear SEA-SA SCCS-ARD interest group,

We held a Webex on 6 Mar 23 to discuss the status of SCCS-ARD edits.  The focus was primarily on Section 5, Physical View, which is all about the kinds of Nodes that we define, where they are typically deployed, and what sorts of functions they are expected to implement.  We explicitly associate those functions with the protocols that are used, but the protocols, and the specific protocol stacks, are really described in depth in Chap 6, the Protocols View.

Attendees: Faramaz Davarian, Karl Vaden, Shelbun Cheng, Costin Radulescu, Robert Rovetto, Peter Shames

Chap 5, Planetary Space Link Terminal (PSTL) SSI section


  *   The SSI PSLT was a [Future] element in the original Magenta Book, largely because only SSI Stage 1 was supported by standards at that point and there is no PSLT role in Stage 1.
  *   For Stage 2 (a and/or b) there is the possibility of a PSLT, which may be deployed on the surface of the Moon or Mars as a comm relay asset.   The various Lunar Comm architecture diagrams that are floating around show such elements, that we would call a PSLT, in the form of a “Cell Tower”, or a Habitat, that provide relay functions.  See attached LunaNet Security diagram, especially pg 4.
  *   We discussed the allocated functions in a PSLT, which include all of the standard link layer functions (and protocols), and also the potential inclusion of the SOIS Wireless protocols, WiFi and 3GPP.
  *   As you can see from the diagram these PSLTs potentially have to include long haul protocols back to Earth (USLP, AOS) and Proximity (Prox-1) to Orbiters and relay spacecraft (or user spacecraft).  And they have to include a variety of “proximate” communications, including Prox-1 (out to 100K Km), 3GPP (out to 10 Km), and WiFi (out to 300 M).  These are all link layer protocols.
  *   The PSLT must also include either DTN protocols (including store and forward Bundle Agent functions), or IP protocols (only provides a real time routing function).
  *   The original [Future] PSLT requirement, which aligned with the understanding of the protocols documented prior to May 2015, suggested that both IP and DTN could be handled in the same infrastructure, with the addition of a weakly specified integration approach, as shown in the following requirements:

5.3.3.2.3 [Future] SSI PSLT nodes shall implement one or more CCSDS-compliant space internetworking functions (reference [IPS] or [DTN]) to process, store, and route IP or DTN data in the space link terminal.

5.3.3.2.9 SSI PSLT nodes shall implement CCSDS-compliant LTP PDU, DTN or IP encapsulation (references [9], [10], [14], [31], [46]) in the space link terminal.

5.3.3.2.14 [Future] SSI PSLT shall implement protocol and PDU conversion and bridging functions in the relay asset (reference [D7], [D24]).

  *   In working our way through these drafty SSI (IP and/or DTN) requirements, and the currently understood PSLT functions, it has become clear that we really need to treat IP and DTN as separate kinds of networks, with separate semantics, and with specific “bridging functions” in the PSLT.
  *   We had a lengthy discussion of the very real differences in the semantics of the “Internet Protocol Suite” (IPS) vs the DTN Protocol Suite (DPS).
     *   IPS assumes continuous, end-to-end connectivity.  TCP provides once only, in order, without omission, delivery of streams of IP datagrams in a low latency environment.  Low round trip light-time delays (RTLT < 1 sec) are assumed and are “baked into” the protocols.
     *   The core structural element of IPS is an IP router that operates in real time to route IP Datagrams.
     *   IPS also depends upon a core set of ancillary protocols that are often not mentioned (Domain Name Service (DNS), routing protocols, inter-system routing protocols, management protocols, security and key management protocols, are among the key ones).
     *   IPS supports use of chatty protocols like HTTPS and SMTP, as well as streaming protocols that we all rely upon, such as voice, video, and streaming movies from NetFlix.
     *   The Internet is composed of a set of Autonomous Systems.
        *   The Internet<https://www.cloudflare.com/learning/network-layer/how-does-the-internet-work/> is a network of networks, and Autonomous Systems are the big networks that make up the Internet. More specifically, an autonomous system (AS) is a large network or group of networks that has a unified routing<https://www.cloudflare.com/learning/network-layer/what-is-routing/> policy. Every computer or device that connects to the Internet is connected to an AS.
        *   Every AS controls a specific set of IP addresses, just as every town's post office is responsible for delivering mail to all the addresses within that town. The range of IP addresses that a given AS has control over is called their "IP address space."
        *   All of the Address Spaces for all of the interconnected AS are managed locally, but coordinated globally.
     *   DPS assumes dis-continuous, end-to-end (hop by hop) connectivity.  BP provides delivery of streams of DTN Bundles in a high latency, disconnected, environment.  High round trip light-time delays are assumed and are “baked into” the protocols, as is the ability to handle disruption.
     *   The core structural element of DPS is a Bundle Agent that operates a store and forward bundle delivery service.
     *   DPS also depends upon a core set of ancillary protocols that are often not mentioned, and are largely not yet standardized (a “DTN Domain Name Service (DDNS)” and node/endpoint identities), DTN routing protocols (SABR exists but no routing update), inter-system routing protocols (non-existent), management protocols (ADM in IETF drafts only), security and key management protocols (BPSec, but not yet key management), are among the key ones.
     *   DPS does not support use of chatty protocols, it uses bundle protocol (hop-by-hop, store & forward) and also streaming protocol (experimental) for voice & data where a contemporaneous link exists end-to-end.
     *   The DPS does not (yet) document the notion of Autonomous Systems nor of separate, managed, Address Spaces, but it is now developing the concepts of DTN namespaces.  Since DTN names (node IDs and endpoint IDs) use URI’s and there are not (yet) registries documenting which specific nodes are assigned, nor where they are, nor how they can be accessed, routing and paths are not (yet) clearly specified.



     *   IPS can be deployed in any closely connected environment, with short RTLT and low latency.  Any such deployment of an “autonomous system” that is sufficiently remote from the Internet will need its own locally managed address space, its own routing, its own DNS, and its own identity management & policies.  And it will need the means to coordinate IP addresses with the terrestrial Internet, even though it is disconnected from it.



     *   DPS can be deployed in any continuously (or occasionally) connected environment.  Any such deployment of a “DTN autonomous system” that is sufficiently remote from the Internet will a coordinated address space, coordinated routing, coordinated DNS, and coordinated identity management & policies.  And it will need the means to coordinate DTN entities, addresses, and identities with the terrestrial Internet, even though it is frequently disconnected from it.



  *   After discussion we arrived at this sort of formulation for the different kinds of PSLT that might be needed.
     *   An IP PSLT may be deployed and may service as a routing node for the local IP Internet.  It may use only IP within the local network.  It (or some ancillary node that is reachable) will have to support: routing, DNS, identity registration & management, and network management and policies within the local network (AS).
     *   An IP PSLT will provide support for standard IP services within the local Autonomous System.
     *   Any node that is not directly reachable by some combination of continuously connected links will only be reachable via a DTN protocol translating gateway, see next…
     *   An IP PSLT may provide protocol translating gateway services (TBS) for a specific subset of IPS protocols & services that are amenable to such treatment.  These protocols and services are likely to include: email gateway, file delivery gateway, streaming voice and video file delivery gateway, some sort of DNS and identity update service, and possibly some sort of web service bulk update gateway (configured for local AS proxies) … this last part seems like a stretch.
     *   These protocol translating gateway services will have to do something like:
        *   Terminate each of the IP-based services within the remote AS
        *   Package the protocol PDUs and data into a file
        *   Add meta-data about the intended destination on Earth
        *   And ship the file and meta-data, via DTN, to a paired protocol translating gateway on Earth
     *   The paired protocol translating gateway services on Earth will have to do something like:
        *   Accept the file and meta-data, via DTN, from a paired protocol translating gateway on the remote planet
        *   Access the meta-data about the intended destination on Earth
        *   “Reconstitute” the protocol PDUs and data from the file
        *   Send the data to the specified IP address on Earth using the specified IP-based services within the Earth AS
     *   Where protocol translating gateway services are in use at a PSLT we assume that a corresponding paired gateway will be available at the servicing ESLT, or at a node that is reachable by DTN protocols.



     *   An SSI Stage 2 PSLT may be deployed and may service as a routing node for the local DPS Internet.  It may use only DTN protocols within the local network and remotely.  It (or some ancillary node that is reachable) will have to support local and off-planet: DTN routing, DTN DNS, DTN identity registration & management, and DTN network management and policies within the local network (AS).
     *   An SSI Stage 2 PSLT will provide support for standard DTN services within the local Autonomous System and provide support to remote systems, using DTN delay tolerant store & forward protocols.
     *   Any node that is reachable by some combination of continuous or intermittent links may be reached by DTN protocols.
     *   An SSI PSLT may also provide protocol translating gateway services (TBS) for a specific subset of IPS protocols & services that are amenable to such treatment.  These protocols and services are likely to include: email gateway, file delivery gateway, streaming voice and video file delivery gateway, some sort of DNS and identity update service, and possibly some sort of web service bulk update gateway (configured for local AS proxies) … this last part seems like a stretch.



     *   An SSI PSLT may support all of the functions of an IP PSLT as well as all of the functions of an SSI PSLT.



  *   We also reviewed, briefly, the IOAG Collaborative Security draft materials (pg 3 in particular) which documents the published (green), not yet fully specced (orange) and missing (red) DTN security and network management functions.  This was relevant to understand the functions needed in an SSI PSLT and to understand what must be added to make DTN Stage 2 a complete interoperable reality.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20230307/29be57ed/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LunaNet Securty IGCA Stage 1-ps.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 5455877 bytes
Desc: LunaNet Securty IGCA Stage 1-ps.pptx
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20230307/29be57ed/attachment-0002.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS Collaborative Security WG 21022023.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 541387 bytes
Desc: CCSDS Collaborative Security WG 21022023.pptx
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20230307/29be57ed/attachment-0003.pptx>

More information about the SEA-SA mailing list