[Sis-csi] The _other_ SCPS protocols (SP, NP, FP)

[Keith Scott]

All,
 
We spent time at the recent CCSDS meetings addressing interoperability and
capability issues with SCPS-TP.  In addition to the SCPS Transport Protocol
(SCPS-TP), there are three other protocols in the SCPS suite:
 
  SCPS Network Protocol (SCPS-NP)
(http://www.ccsds.org/CCSDS/documents/713x0b1.pdf)
  SCPS Security Protocol (SCPS-SP)
(http://www.ccsds.org/CCSDS/documents/713x5b1.pdf)
  SCPS File Protocol (SCPS-FP)
(http://www.ccsds.org/CCSDS/documents/717x0b1.pdf)
 
These protocols were approved as CCSDS Recommendations a little over five
years ago, and reviewing them falls under the Cislunar Space Internetworking
Working Group's charter.  Possible actions for these protocols include:
 
  o Approving the standards 'as-is' for another five years.
  o Updating / clarifying aspects of the specifications (as is being done
for the TP)
  o Retiring some or all of the standards
  o ...?
 
It is my personal belief that while there has not been as much commercial
interest in the above standards as there has been in the SCPS Transport
Protocol (SCPS-TP), they are still relevant for space use, at least for
certain mission sets.  Below is a brief reprise of the various protocols'
capabilities, comparisons with their Internet counterparts, and comments
about their continued applicability to CCSDS.
 
SCPS-NP
The SCPS Network Protocol allows for very compact representation of end
system addresses and groups of addresses (the latter via the path address
feature).  SCPS-NP also provides mechanisms for priority handling of
datagrams, as well as per-packet control of routing mechanisms.  Per-packet
routing control is used to signal that certain packets should be flooded to
improve reliability.  The smallest SCPS-NP header is 4 octets, significantly
smaller than IPv4's 20-byte header.  The main disadvantage of SCPS-NP is
that it is not bit-interoperable with IPv4/v6 --  SCPS-NP headers would have
to be translated into and out of IPv4/v6 to allow interoperation with an
IPv4/v6-based network.  Translating between SCPS-NP and IP is possible, with
the possible loss in IP of some of NP's capabilities such as the ability to
select different routing treatments as mentioned above.  Other differences
between SCPS-NP and IP include:
  1) SCPS-NP has a 8191-byte maximum packet size limit and no fragmentation
  2) SCPS-NP supports a maximum of 16 upper-layer (transport) protocols
  3) SCPS-NP supports 16 levels of precedence, independent of the IP TOS
field
  4) SCPS-NP's version of ICMP (SCMP) supports explicit signaling of
congestion, corruption, and link outage if such information can be acquired
from the link layer.
Its lower overhead and ability to signal per-packet routing options make
SCPS-NP an attractive alternative to straight IPv4 (IPv6) for
bandwidth-constrained missions.
 
SCPS-SP
SCPS-SP provides capabilities similar to IP Security (IPSEC) in the Internet
world.  The main differences between SCPS-SP and IPSEC are:
  1) SCPS-SP incurs two bytes of overhead per packet, whereas IPSEC requires
10
  2) SCPS-SP only allows one active security association per address pair,
while IPSEC allows multiple simultaneous SAs.
For some mission scenarios the overhead savings of SCPS-SP are probably not
worth the effort.  If the mission is pushing HDTV streams around at tens or
hundreds of Mbps, a few extra bytes for IPSEC will likely be tolerable.
Smaller, lower bandwidth missions might still be able to capitalize on the
savings.
  3) SCPS-SP does not provide replay protection, instead it relies on
transport sequence numbers.
Because of its lower overhead, SCPS-SP is still relevant to
bandwidth-constrained missions that require security services.
 
SCPS-FP
The SCPS File Protocol supports low-bandwidth file transfers.  The main
features of SCPS-FP that have NOT been implemented in modern FTP
implementations are:
  1) Record read, update
  2) Integrated file integrity checking
  3) Suppression of reply text
The ability to read and update pieces of a file without reading/sending the
entire file could be of significant benefit to bandwidth-constrained (or
asymmetric bandwidth) missions.
 
 
 
In short, SCPS-NP, SCPS-SP, and SCPS-FP provide bit-efficient services that
will be needed on future space missions.  While some missions will likely
have bandwidth to burn, others that are not so lucky will be able to reap
significant benefits from NP, SP, and FP.  For that reason I would suggest
that these protocols be reaffirmed as Recommendations within CCSDS.
 
Again, I invite discussion on any/all of the protocols.
 
 
Best Regards,
 
        --keith
 
 
 
 
Dr. Keith Scott
kscott at mitre.org
+1.703.883.6547
Chair, CCSDS Cislunar Space Internetworking Working Group
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20041130/0883a24e/attachment.html